Hi Thomas, Thanks for your answers. Please, note some additional comments following yours:
-----Mensaje original----- De: Thomas C. Schmidt [mailto:[email protected]] Enviado el: jueves, 26 de julio de 2012 1:44 Para: LUIS MIGUEL CONTRERAS MURILLO CC: [email protected] Asunto: Re: [multimob] Comments on draft-ietf-multimob-pmipv6-source-01 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 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? 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. [Luis>>] Let me explain how I see this. Consider that PIM is enabled in the interface of the bidirectional tunnel in both MAG and LMA. In the case of PIM-SM, the MAG will send a unicast PIM Register towards the RP, which will be located in the home network (otherwise we would be dealing with PIM inter-domain issues). That unicast message will be naturally forwarded by the bidirectional tunnel, as any other unicast communication, towards the LMA to reach the RP in home network. Once registered, the multicast content will be sent in unicast fashion to the RP, through the LMA. In case of PIM-SSM, or in case there is a transition from shared-tree to source-based tree, the PIM source-specific join from the designated router in home domain will arrive to the LMA. Once the LMA delivers that join to the MAG, through the bidirectional tunnel, the MAG will set-up the multicast state on the tunnel interface, and will deliver the multicast flow towards the LMA. > 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). > The single uplink scenario, which btw. introduces other problems, is described in Section 4.2 and draft-ietf-multimob-pmipv6-ropt is referenced there. So I think this is perfectly o.k. up to the point that performance considerations are still missing in Section 4. They will be added. [Luis>>] Section 4 is related to Direct Multicast Routing. My question is about the situation where no direct routing happens, but the multicast source in a PMIPv6 domain distributes its traffic to the Internet through its home network. In that case, if you directly apply RFC6224 solution you can find the problem you mention (up and down routing of the same multicast traffic, when MN listeners reside in the same PMIPv6 domain as the source, but they are bound to distinct MLD proxy instance). You, later on your draft, propose a solution for this through the introduction of the MLD proxy with multiple upstream interfaces. Ok, that's fine, but note that today other possibilities can be applied. As WG document I feel this should be also covered, without detriment of other new options, to be defined and completed. > 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? > I don't really get the point here: I cannot see a reasonable way to deploy a set of proxy instances plus a PIM-SM routing daemon on the same MAG (this in particular, since the interaction of the different routing engines would be unclear). In other words: The base solution defines a complete set of forwarding rules that comply to the PMIP topology. What should a PIM routing engine do in addition? The use case you may head at is a different set of filter rules of group or source addresses that lead to a heterogeneous treatment. This subject is addressed in Section 5. [Luis>>] Sorry Thomas, probably the comment was not well described. Let me elaborate a bit more. When you are introducing the direct routing case, section 4, you state that it can happen with MLD proxy instances deployed at MAG. So, no PIM by now. With this in mind, attending to figure 3, the LMAs will be devoted only for unicast traffic, and multicast traffic will come from the PMIPv6 domain. So, base solution (remote routing) and direct routing are exclusive, right?, because no dynamic mechanism to swap from one case to the other is envisage (my question was if you are considering some kind of mechanism to do that). > 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. > I guess, there are two answers to this questions: 1. draft-ietf-multimob-pmipv6-source is compatible with the two scenarios "meant" in draft-ietf-multimob-pmipv6-ropt, namely a single proxy uplink to a single multicast router (name it MTMA, if you desire), and a direct multicast routing in the access. [Luis>>] Right, I see base solution source mobility is compatible with base solution listener mobility (RFC6224), and direct routing source mobility is compatible with direct routing listener mobility. It can also be compatible with tunnel convergence optimization due to MTMA, despite this is not described yet in your draft (does not fit in section 3 because no mention is done to tunnel convergence optimization, nor fit in section 4 because of direct routing, so no remote). What seems to not be possible is to have listeners receiving remote content together with some sources injecting directly (with MLD proxy functionality at MAG) into the PMIPv6 domain. A way of doing that is the use of the MLD proxy with multiple upstream interfaces. My concern here is he following. In a PMIPv6 domain (or in general in any network) there will be more listeners than sources. If the way of deploying a source for a certain content restricts the way the listeners consume a variety of some other contents, both local (if locally available) and remote, then it is not practical at all. In my opinion, a particular case (the optimization for the local delivery of a MN/source) should be accommodated to the more general case (the reception of the content by MN/listeners, locally if the source is local, remotely if the source is remote). 2. draft-ietf-multimob-pmipv6-ropt lacks conciseness on how things actually are intended to work. I should remind at my quick review during Cebit 2012 (March 6th) with a few severe comments that have not been addressed in the current update. [Luis>>] Touchez!! Not sure if this is an answer to the question, but anyway you are right, we have to work out a better structured document, and address of course all the comments coming from the WG, as the document is not ours exclusively, but part of the WG outcomes. > 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? > I guess no. The failure in reasoning is that there is no single LMA. [Luis>>] Right, but being the MN in a PMIPv6 domain it will be associated to only one LMA, which will advertise its HNPs to the rest of the Internet. Then the MN/source becomes reachable through that LMA. As the LMA and the MAG maintains the bidirectional tunnel, I deduce this is then the shortest path, I suppose. > 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. [Luis>>] Let me explain better. As I understand, you are considering the multiple upstream proxy as a way of avoiding those loops. Those loops are originated by the fact of having several MLD proxy instances per MAG, and those distinct instances are needed because the multicast traffic can be injected by different LMAs. To face this issue you propose multi-upstream MLD proxies as an artifact that permits to communicate a single MLD proxy instance with any LMA in the domain, and all the MN in the MAG can directly receive the traffic injected by any MN acting as a multicast source, at the cost of defining additional rules and complicating the MAG. On the other hand you have another solution to reach the same goal: the MTMA approach, where one anchor routes all the multicast traffic, and inherently only one MLD proxy instance is required in the MAG. No additional rules, no additional complexity at MAG. And, of course, no tunnel convergence issues. I'm not against the multiple upstream proxy solution. I just want to highlight other solutions for the same problem, and I think it is fair to mention them, especially if they exist, are documented, and are part of the outcomes of the working group. > 10/ Also regarding the multiple upstream interface proxy, as we foresee > in the work being done in draft-ietf-multimob-pmipv6-ropt, ... draft-ietf-multimob-pmipv6-ropt is coined as an informational document that is supposed to explain two rather simple things at a MAG: *the deployment of a single multicast router uplink, as well as *dynamic multicast routing. There is no way to deal with variable upstream selections etc. [Luis>>] Sorry Thomas, this does not answer the question. Should I assume that multiple upstream interfaces proposal is just applicable for the base solution case, exclusively? Is that the idea you handle? (this is linked to my comment number 7) > 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? If you open multiple redundant paths, you need to apply a routing logic that 1. is loop-free 2. ensures (or fosters at least) traffic uniqueness Those are the reasons to treat these interfaces not as equal, but in a preference hierarchy. [Luis>>] I understand your statement, but that was no the question. The question is why do you classify as preferred the peering links instead of the ones pointing to the LMAs? Let me repeat the rationale of this comment. Since the source address of the MN is one address of the home domain, the MAG is not able to determine if the MN/source is actually connected to the PMIPv6 domain or it is placed on the home network, so there is no way for the MAG to distinguish if the best route is through another MAG or through the LMA. Cheers, Thomas [Luis>>] Best regards, Luis > > _______________________________________________ > multimob mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/multimob > 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
