Thanks Shuai for your clarifications. Just one comment about your answer about the Query message in figure 2. I think we are all on the same page. What I would suggest is to depict in a more clear way that the MLD Query, needed basically to determine the multicast listener nature of the MN, run in parallel with the fact of delivering multicast traffic if the MN acts as a source. As it is depicted now, as a sequential flow, can be a little bit confusing.
Thanks again, Best regards, Luis -----Mensaje original----- De: Shuai Gao [mailto:[email protected]] Enviado el: jueves, 26 de julio de 2012 12:05 Para: Thomas C. Schmidt; LUIS MIGUEL CONTRERAS MURILLO CC: multimob Asunto: Re: Re: [multimob] Fwd: New Version Notification fordraft-ietf-multimob-pmipv6-source-01.txt Hi Luis, Thanks for your comments. I'd like to make some supplements inline on base of Thomas's answers. ======= 2012-07-26 07:44:09 您在来信中写道：======= >Hi Luis, > >many thanks for your comments, please see answers inline: > >On 24.07.2012 19:52, LUIS MIGUEL CONTRERAS MURILLO wrote: > >> 1/ The draft presents two main scenarios of source mobility. ... >>The question is: Do you not consider the MAG as multicast router for >>the base solution just because the functionality defined for the MAGs >>in RFC6224 is MLD proxy, or actually you are not considering the MAG >>as multicast router as an option to deliver multicast traffic through >>the home network via the LMA? > >SEction 3 only refers to the base solution (aka RFC 6224). Full >multicast routing functions at MAGs are the topic of Section 4. > >On the contrary, if the MAG is a multicast router (using an unmodified >multicast routing protocol like some sort of PIM), then multicast data >distribution follows the forwarding states implemented by join and >leave operations (the TIB or MFIB). > >The solution you envision ("multicast router ... to deliver multicast >traffic through the home network via the LMA") would require static, >exclusive, source-specific forwarding states for all groups in the MFIB. >That's not how (dynamic) multicast routing works. Actually, as a multicast router (PIM-SM), the MAG delivers the mutlicast traffic through the home network via the LMA only after the RP or the DRs of receivers initiate source-specific Join, which cases are described in section 4.3.3 and 4.3.4. > >> >> 2/ In figure 2, just after MLD proxy configuration statement, you >> depict the sequence MLD Query (from MAG2 to MN2), Mcast Data (from >> MN2 to MAG2). I think it is a bit confusing. As far as I understand, the MN2 >> ... >> >Figure 2 adapts the call-flow of the base solution. The MLD Query is >needed to establish appropriate multicast listener states at the MAG >after a handover. > >You are right that the Query is not needed for the source to send >multicast data. It is also unnecessary for forwarding traffic to the >LMA. We can remove it. The Query is not needed. However, it's difficult to discriminate whether the newly attached MN is a multicast listener or source according to current protocol. To be compatible with RFC 6224, the Query can be kept here, I think. Of course, the Query should not be sent if the MAG definitely knows the newly MN is a multicast source. >> 9/ In section 5.1 you introduce the multiple upstream interface proxy >> idea as a way of eliminating routing loops, needing additional rules and >> process for it. In my opinion, the MTMA concept is a simpler way of >> having the same results. >> >T >Gee no! - the multiple upstream proxy is a way to attach to multiple >LMAs/PIM Routers from a single proxy instance. This bears the strong >risk of routing loops ... so any solution must assure to avoid those. > The multiple upstream interface proxy can help address local routing optimization problem by deploying single proxy instance with multiple upstream interfaces. Regarding the routing loops and redundant traffic problem, we are working on this and will add corresponding detail scheme to avoid it in next version. > Thanks Shuai Shuai Gao National Engineering Lab for Next Generation Internet Interconnection Devices Beijing Jiaotong University Beijing, China, 100044 [email protected] 2012-07-26 Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at http://www.tid.es/ES/PAGINAS/disclaimer.aspx _______________________________________________ multimob mailing list [email protected] https://www.ietf.org/mailman/listinfo/multimob
