Re: Multicast requirements

Hi Juan Carlos,

On 11/12/2012 10:51 PM, 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.
We're inline here.

> 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.
This requirement paves the way for the ones I'm reviewing with Seil, and 
keeps IP multicast position, i.e. as a "module" that may or not be 
included by operators.

Although the motivation is clear, this seems as a light requirement to 
be achieved, in the sense that it can be easily transposed. Do you have 
in mind what is a valid "justification" for not addressing multicast?

BR,
Sérgio
>
> 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
> _______________________________________________
> dmm mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dmm