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
_______________________________________________
multimob mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/multimob
