Hi Sergio, I wasn't implying that you were proposing a solution. I just meant that using the word module was perhaps not appropriate for drafting the requirement. Having said that, if you believe there is some wording to that we can propose to reflect your thinking in a clear requirement, please suggest it.
Regards, Juan Carlos > -----Original Message----- > From: Sérgio Figueiredo [mailto:[email protected]] > Sent: Monday, November 12, 2012 6:46 PM > To: Zuniga, Juan Carlos > Cc: [email protected] > Subject: Re: [DMM] Multicast requirements > > Hi Juan Carlos, > > Don't get me wrong. Although I use the word "module" I'm not referring > to solution details. What I was referring to was to the optional > deployment of (at least) multicast discovery / routing protocols, which > this requirement keeps as is if I understood it correctly. > > Cheers, > Sérgio > > On 11/12/2012 11:20 PM, Zuniga, Juan Carlos wrote: > > Hi Sergio, > > > >> -----Original Message----- > >> From: [email protected] [mailto:[email protected]] On Behalf > Of > >> Sérgio Figueiredo > >> Sent: Monday, November 12, 2012 6:10 PM > >> To: [email protected] > >> Subject: Re: [DMM] 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. > > [JCZ] Good. We don't have time much time for religious battles, so > better to propose text soon and get the requirements finalized. > >>> 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. > >> > > [JCZ] I agree. However, talking about "modules" seems to me getting > into the solution space, which should not be done in the requirements. > >> 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? > >> > > [JCZ] I don't have one and I believe it is up to the solution > proponents to write one in case they do not support multicast. If they > do, a justification would not be needed. The reason for using SHOULD is > to allow for people that believe this is not needed to still bring > their proposals forward, but giving the reasoning why they believe this > is not needed. > > > > Regards, > > > > Juan Carlos > >> 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 > >> _______________________________________________ > >> dmm mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
