Re: Multicast requirements

Hi Juan Carlos,

this all sounds very abstract and more from an administrative point of view.

Point is (and relevant arguments always have an understanding of the 
solution space) that some routing scenarios are easy to accomodate 
multicast and others aren't.

My major point was: If DMM picks a solution, people should just think 
wider (including multicast) and then there is no need to come up with 
weirdo type of "solutions" in Multimob that are only justified by 
unicast solutions being ignorant of other use cases.

In other words: Rather be clever than smart.

Cheers,

Thomas

On 12.11.2012 23:51, Zuniga, Juan Carlos wrote:
> I believe the purpose of the discussion was to propose some requirement
> text for draft-ietf-dmm-requirements, rather than getting in the
> solution space. I propose the following:
>
>
> Requirement: DMM solutions SHOULD support multicast services. In case
> the solution
>            does not address multicast, a justification MUST be provided
> for the
>            omission of multicast from the solution.
>
> Motivation: The purpose of this requirement is to encourage people to
>            consider the impacts of running multicast services in a DMM
> environment
>            from the beginning of the development, thereby avoiding the
> need to
>            make protocol extensions in the future to support this kind of
>            functionality.
>
>
> Regards,
>
> Juan Carlos
>
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]] On Behalf Of
>> Thomas C. Schmidt
>> Sent: Monday, November 12, 2012 5:06 PM
>> To: Peter McCann
>> Cc: Stig Venaas; Behcet Sarikaya; [email protected]
>> Subject: Re: [DMM] Multicast requirements
>>
>> Hi Pete,
>>
>> things would be simple, if topology were as described.
>>
>> Let's wait what dmm is birthing out ... and continue discussion then.
>> In
>> any case, complex and incompatible "grand new schemes" do not appear
> to
>> make much sense.
>>
>> Cheers,
>>
>> Thomas
>>
>> On 12.11.2012 22:53, Peter McCann wrote:
>>> In the DMM case my assumption is that the anchor points are closer
>>> to the access routers and therefore are very likely to be in the
> same
>>> administrative domain.  In these cases, joining the multicast group
>>> directly from the access router gives you the same access to the
> same
>>> multicast streams and so tunneling the multicast packets won't be
>>> necessary.
>>>
>>> -Pete
>>>
>>> Thomas C. Schmidt wrote:
>>>> Dear Pete,
>>>>
>>>> multicast mobility management is a route adaptation problem. As in
>> the
>>>> unicast case, mobility can only be treated by routing dynamics in
>>>> trivial cases (re-connect of a tunnel, re-association with next
>> hop).
>>>> Otherwise it is unwise to delegate mobility adaptation to routing
>>>> protocols (-> OSPF, BGP ...).
>>>>
>>>> Accordingly, if DMM distributes mobility operations, handover
>>>> management should foresee easy interconnects to previous
>> distribution
>>>> trees - both for receivers and for mobile multicast sources.
>>>>
>>>> I guess, if DMM people are careful, this is not a world-class item
>> and
>>>> can be treated along the lines of unicast solutions - an isolated
>>>> multicast protocol treatment (as has been previously proposed from
>>>> MULTIMOB folks) seems inappropriate. In core PMIP, multicast
>> treatment
>>>> has turned out to work out simply (-> RFC6224).
>>>>
>>>> Thus my argument: talk to the multicast guys before adopting a
>>>> solution ... and make the rest an easy game.
>>>>
>>>> Cheers,
>>>>
>>>> Thomas
>>>>
>>>> On 12.11.2012 21:39, Peter McCann wrote:
>>>>> jouni korhonen wrote:
>>>>>> Folks,
>>>>>>
>>>>>> This mail is to kick off the discussion on multicast
>> requirement(s)
>>>>>> for the draft-ietf-dmm-requirements-02 document. I hope we can
>> nail
>>>>>> down the essential multicast requirement(s) as soon as possible.
>>>>>
>>>>> To me, multicast in a DMM environment means joining multicast
>> groups
>>>>> directly from access routers.  It means re-joining the multicast
>> tree
>>>>> from a new access router after handover.  I would hope that we can
>> use
>>>>> existing MLD protocols between the MN and its first hop AR to
>>>>> accomplish this.
>>>>>
>>>>> -Pete
>>>>>
>>>>> _______________________________________________
>>>>> dmm mailing list
>>>>> [email protected]
>>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>>>
>>>>
>>>
>>>
>>>
>> _______________________________________________
>> dmm mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/dmm