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