Dear Thomas, Shuai, Hong-Ke and Matthias, Please, find here below a number of comments on draft-ietf-multimob-pmipv6-source-01. These comments are the result of a fresh reading of the draft, so possibly some of them can be naïve questions or even have been previously discussed on the mailing list. My apologies in advance.
Here are the comments. 1/ The draft presents two main scenarios of source mobility. The first one tries to fit the source mobility in the base solution (multicast routing through the home network), while the second one deals with the direct multicast routing in the PMIPv6 domain. In the first case you only consider the MAG having MLD proxy functionality only, while in the second case you relax this by considering the case where the MAG is a multicast router. 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? In the former case, I suggest to include this possibility (I don't know if as part of the base solution or as another case). In the latter case I wonder why the MAG cannot be a multicast router connected to the LMA (through the bidirectional tunnel) to deliver the multicast traffic via the home network. 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 will send the multicast data independently of the reception of an MLD Query. I can understand, according to your proposal, that the MLD Query/Report sequence is needed to configure the MLD proxy instance at MAG2, but it is not needed for MN2 to deliver the multicast traffic (but it is needed for MAG2 to forward this traffic, from MAG2 to LMA). Is this correct?. 3/ Along the base solution you described several times that the presence of different MLD proxies associated to distinct LMAs produces some inefficiencies, because the traffic has to go up to the LMA for going down again to the MAG in order to be delivered to a distinct MLD proxy in the MAG. However this can be solved if the MTMA approach in draft-ietf-multimob-pmipv6-ropt is taken into account. Under that approach all the MNs are served by the same anchor, and all are attached to the same MLD proxy instance. So, I would suggest to include explicitly a reference to that option (in fact, the other option in draft-ietf-multimob-pmipv6-ropt, is already considered in your draft, so this is not disruptive). 4/ Section 3.2.5 is entitled "Efficiency ..." when actually deals with efficiency issues or inefficiencies. I suggest to change the title in that sense. 5/ Also in section 3.2.5, the second bullet can be removed if the MTMA approach is mentioned. 6/ According to the description you provide for the direct routing case, it seems that the base case and the direct routing case are exclusive, that is, they cannot coexist simultaneously in the domain. The direct routing case imposes a set of requirements that make not possible to live with the base solution at the same time. In my opinion this is an strong requirement because a probable case is one where there are sources residing both at the home network and the PMIPv6 domain. Are you considering the coexistence of remote and direct cases simultaneously for next versions? 7/ In section 4.2, linked to figure 3.a and 3.b, the MAGs (MLD proxy) upstreams are connected to a multicast infrastructure in the PMIPv6 domain, reserving the LMAs only for unicast traffic. If so, there is no option of supporting multicast listeners as defined in RFC6224, nor in draft-ietf-multimob-pmipv6-ropt, where both direct and remote multicast service co-exist. This scenarios are not compatible with multicast listener support, from my point of view. 8/ In section 4.3.3, if the LMA plays the role of RP is then possible to obtain the shortest path (through the bidirectional tunnel), isn't it? 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. 10/ Also regarding the multiple upstream interface proxy, as we foresee in the work being done in draft-ietf-multimob-pmipv6-ropt, this could be an option for dynamically allow the direct vs remote routing for the multicast listener case (with one upstream pointing to the remote source, while other to the local one). I think it is worthy to explore also this in the case of multicast source mobility. If you want I could collaborate on this. 11/ Regarding section 5.1.1, it is not clear to me if the initial paragraph is actually an extension proposal or just a description text. I mean, you are talking there about forwarding multicast data to all downstream links (with active subscriptions) of an MLD proxy once one source is attached to another downstream interface. Is this actually an extension? I mention this because in pag. 7 you are considering this as a fact, referring RFC4605, where actually there is a mention to sender support but it is not clearly stated that the traffic is delivered to the rest of downstream interfaces. Please, could you clarify this? 12/ In section 5.2 you talk about MLD proxy peering. While the description refers to MLD proxies living in distinct MAGs, I suppose this could be also applicable to proxies resident in the same MAG, couldn't be? 13/ In section 5.2.2 you mention that the peering upstream interfaces have to be considered as preferred interfaces. What is the reason for that? I assume you are considering that the delivery between MAGs is more efficient than the routing between LMA and MAG. But this could be true if you are sure that the source is in the same domain where the listener is attached to. However, due that the source address is one address of the home domain, you are not actually able to determine if the source is connected to the PMIPv6 domain or to the home network, so you cannot distinguish if the best route is through another MAG or through the LMA. Do you agree? Thanks in advance for your answers, Best regards, Luis _____________________________ Luis M. Contreras Technology / Global CTO / Telefónica Efficiency Projects / Telefónica I+D Don Ramón de la Cruz 82-84 28006 Madrid España / Spain [email protected] ________________________________ 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
