Subject: [multimob] Comments on draft-ietf-multimob-pmipv6-source-01

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Tue, 24 Jul 2012 19:52:52 +0200

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-masked]

________________________________
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

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Thu, 26 Jul 2012 01:44:01 +0200

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.

>
> 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?.
>

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.

> 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.

> 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.
>

This section discusses the efficiency of the distribution system, which 
is actually pretty good ... even though the section concentrates on the 
critical part. Maybe we should put more emphasis on the positive side ...

In any case: the category is named efficiency, no matter how good or bad 
it is.

> 5/ Also in section 3.2.5, the second bullet can be removed if the MTMA

see above.

> 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.

> 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.

  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.

> 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.

> 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.

> 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.

>
> 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.

Section 5.1 is work in progress and not finished ... as indicated by the 
TODOs.

> 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?
>

Yes, as stated explicitly:

   "Such peering interfaces can be configured - as a direct
    link or a bidirectional tunnel - between any two proxy instances
    (locally deployed as in [RFC6224] or remotely)"

> 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.

Cheers,

Thomas

>
> _______________________________________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multimob
>

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Fri, 27 Jul 2012 10:22:29 +0200

Hi Thomas,

Thanks for your answers. Please, note some additional comments following yours:

-----Mensaje original-----
De: Thomas C. Schmidt [mailto:[email-masked]]
Enviado el: jueves, 26 de julio de 2012 1:44
Para: LUIS MIGUEL CONTRERAS MURILLO
CC: [email-masked]
Asunto: Re: [multimob] Comments on draft-ietf-multimob-pmipv6-source-01

Hi Luis,

On 24.07.2012 19:52, LUIS MIGUEL CONTRERAS MURILLO wrote:

> 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

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.

[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.

[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).

[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).

[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.

[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.

T

[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.

[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)

  1. is loop-free

[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