Subject: [multimob] PMIPv6 extension for multicast

From: Hitoshi Asaeda <[email-masked]>
Date: Sat, 16 Jul 2011 01:32:44 +0900 (JST)

Hello folks,

We revised our PMIPv6 extension draft as follows:

http://tools.ietf.org/html/draft-asaeda-multimob-pmip6-extension-06

This draft specifies the scenario in which both LMA and MAG act as
PIM-SM routers. This draft addresses the tunnel convergence problem
and provides seamless handover. It defines Proxy Binding Update and
Proxy Binding Acknowledgement messages with multicast extension.

Comments welcome.

Regards,
--
Hitoshi Asaeda

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 19 Jul 2011 11:03:13 +0900 (JST)

Hi folks,

> Proxy Binding Acknowledgement messages with multicast extension.

I'd like to summarize the points this document focuses on.

This document addresses the tunnel convergence problem by an RPF
lookup algorithm. Although the approach is straightforward, this
condition assumes both MAG and LMA act as PIM-SM routers.
In addition, only enabling PIM-SM on MAG and LMA does not provide
mobility. Therefore this document also provides handover mechanisms by
adopting the standard PBU/PBA messages with multicast extension or
using Policy Store maintaining subscribing multicast channel list.

Note that, to simplyfy the protocol extension, this document does not
provide any "fast" handover mechanism, such as link-layer specific
mechanisms (e.g. scan in WLAN), prediction for movement, data
pre-forwarding, and so on.
The proposed mechanism aims to be flexible and general; it could
cooperate with other fast handover mechanism. As one of the examples,
this document refers the idea of CXTP with multicast extension (*1)
and illustrates the scenario to cooperate with it.
(*1) draft-vonhugo-multimob-cxtp-extension-00.txt

Thank you for your attention.

Regards,
--
Hitoshi Asaeda

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 19 Jul 2011 08:12:05 -0700 (PDT)

> condition assumes both MAG and LMA act as PIM-SM routers.

In Section 3.2 you have:

The MAG selects only one upstream link for a multicast channel by the    Reverse 
Path Forwarding (RPF) algorithm even if the MAG has    established multiple 
M-Tunnels to LMAs.  This does not cause the    tunnel convergence problem, 
because duplicate packets are not    forwarded to the MAG.This means that MAG 
does not send any new joins to the same group upstream, right?
I agree that it would solve the problem but does it create new problems, like 
what happens if the member MN leaves the group and no more data can be received 
while other MNs possibly wanted to continue.

> (*1) draft-vonhugo-multimob-cxtp-extension-00.txt

I am confused here.
If we use draft-vonhugo-multimob-cxtp-extension then the handover in Section 8 
would not be needed? Is the technique in draft-vonhugo-multimob-cxtp-extension 

stand alone and would achieve fast handover by itself or not?

Regards,

Behcet

---

From: Hitoshi Asaeda <[email-masked]>
Date: Wed, 20 Jul 2011 10:57:41 +0900 (JST)

Hi Behcet,

> The MAG selects only one upstream link for a multicast channel by
> the Reverse Path Forwarding (RPF) algorithm even if the MAG has
> established multiple  M-Tunnels to LMAs.  This does not cause the
> tunnel convergence problem, because duplicate packets are not
> forwarded to the MAG. This means that MAG does not send any new
> joins to the same group upstream, right?

Right.

> I agree that it would solve the problem but does it create new
> problems, like what happens if the member MN leaves the group and no
> more data can be received while other MNs possibly wanted to continue.

MAG maintains the membership state with MLD.
It is mentioned in section 6 and section 8.1.
For instance, section 8.1 says;

  "If p-MAG thinks that the moving mobile node is the last member of
   multicast channel(s), p-MAG confirms it by sending IGMP/MLD query.
   After the confirmation, p-MAG leaves the channel(s) by sending the
   PIM Prune message to its upstream router."

Well, IGMP is not relevant here, so I'll remove the word "IGMP" from
this sentence in the revised version, though.

> If we use draft-vonhugo-multimob-cxtp-extension then the handover in
> Section 8 would not be needed? Is the technique in
> draft-vonhugo-multimob-cxtp-extension stand alone and would achieve
> fast handover by itself or not?

Our draft proposes three possible ways for handover; 1) Policy Profile,
2) PBU-M/PBA-M, and 3) CXTP extension. Either one can be used.
And the above CXTP draft is a stand alone solution as it potentially
also works with other approaches.

Regards,
--
Hitoshi Asaeda

---

From: "Shuai Gao" <[email-masked]>
Date: Wed, 20 Jul 2011 15:36:54 +0800

Hi, Hitoshi,

	 In your draft, it's mentioned that the MAG sends PIM Join message to its neighboring router (upstream router).  And the upstream link is selected by the RPF algorithm. That is, the upstream router is dependent on the network topology?  If the upstream router is not a LMA, you choose a direct and native routing. Is this same as the solution proposed by sijeon in draft-sijeon-multimob-direct-routing-pmip6-01?  
	And if the upstream router is the LMA, the M-tunnel is generated and used for mulicast transmission.  Actualy, the LMA is also a direct neighbor of the MAG in this scenario.  I don't understand the necessity of the M-tunnel.  The direct routing  does not work in this scenario?  Or the M-tunnel is used for other purposes, like fast handover?

Regards,

Shuai Gao

======= 2011-07-19 10:03:57 您在来信中写道：=======

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

= = = = = = = = = = = = = = = = = = = =

　　　　　　　　致
礼！

Shuai Gao
National Engineering Lab for Next Generation Internet Interconnection Devices
Beijing Jiaotong University
Beijing, China, 100044
[email-masked]
2011-07-20

---

From: Hitoshi Asaeda <[email-masked]>
Date: Wed, 20 Jul 2011 17:32:25 +0900 (JST)

Hi Shuai,

> 	 In your draft, it's mentioned that the MAG sends PIM Join
> message to its neighboring router (upstream router).  And the
> upstream link is selected by the RPF algorithm. That is, the
> upstream router is dependent on the network topology?

Yes, correct.

>  If the
> upstream router is not a LMA, you choose a direct and native
> routing. Is this same as the solution proposed by sijeon in
> draft-sijeon-multimob-direct-routing-pmip6-01?  

I've just taken a very quick look at this draft.
It seems that the proposal is to provide local routing with the MLD
proxy function on MAG and a dedicated multicast router. The dedicated
multicast router is always MAG's upstream router in this solution.

The approach is different from ours.
In our proposal, the PIM-SM routing function is enabled on both LMA and
MAG. Upstream routers are selected according to the topology. When MAG
selects LMA as the upstream router for some multicast channel, MAG
sends PIM Join/Prune via M-Tunnel. When MAG selects an adjacent
multicast router (i.e. not a foreign LMA) as the upstream router, MAG
sends PIM Join/Prune natively.

> 	And if the upstream router is the LMA, the M-tunnel is
> generated and used for mulicast transmission.  Actualy, the LMA is
> also a direct neighbor of the MAG in this scenario.  I don't
> understand the necessity of the M-tunnel.  The direct routing  does
> not work in this scenario?  Or the M-tunnel is used for other
> purposes, like fast handover?

I cannot understand the statement, "the LMA is also a direct neighbor
of the MAG in this scenario".
M-Tunnel is a virtual (i.e. tunnel) link. It is used to make LMA as an
MAG's neighbor router in the routing protocol.

For direct routing (I assume the condition for direct routing and
local routing is same), M-Tunnel won't be used, because MAG will
recognize the neighbor router, which is not an LMA, without M-Tunnel.

M-Tunnel is not relevant to handover.
Whether multicast extension is included or not, PBU/PBA messages are
transmitted in the regular PMIPv6 procedure (defined in RFC5213).

Regards,
--
Hitoshi Asaeda

---

From: "Shuai Gao" <[email-masked]>
Date: Wed, 20 Jul 2011 18:00:05 +0800

HI, Hitoshi,

======= 2011-07-20 16:32:29 您在来信中写道：=======

>sends PIM Join/Prune natively.

Maybe sijeon is more eligible to discuss this. 
>MAG's neighbor router in the routing protocol.

Here, I am concerned that how the LMA becomes the upstream router.  I think that the LMA is connected with the MAG directly if the LMA are selected as the upstream router by the RPF algorithm.   If not, the LMA becomes the upstream router when the MAG has not neighbor router that does supports PIM-SM? 

　　　　　　　　致
礼！

Shuai Gao

---

From: Hitoshi Asaeda <[email-masked]>
Date: Wed, 20 Jul 2011 19:25:23 +0900 (JST)

> Here, I am concerned that how the LMA becomes the upstream router.
> I think that the LMA is connected with the MAG directly if the LMA
> are selected as the upstream router by the RPF algorithm.   If not,
> the LMA becomes the upstream router when the MAG has not neighbor
> router that does supports PIM-SM? 

Still I cannot understand what point you are concerned.

But let me assume that your concern is related to the sequence of
M-Tunnel establishment and PIM neighbor discovery.

If M-Tunnel is not established between LMA and MAG, MAG cannot
discover LMA as one of the PIM neighbor routers according to multicast
channel subscription requests given by its downstream nodes (i.e. MNs).
Therefore M-Tunnel must be set up between LMA and MAG prior to PIM
neighbor discovery.

This is mentioned in section 4 such as;

  "M-Tunnel is established between PIM-SM capable LMA and MAG.  It is
   established in a bootstrap phase of MAG (without detecting a
   multicast channel subscription request from a mobile node) and kept
   while the MAG is running."

Hope this helps.

Regards,
--
Hitoshi Asaeda

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 20 Jul 2011 09:26:33 -0700 (PDT)

Hi Hitoshi,
If PIM-SM at the MAG and LMA does not require any protocol extensions, then I 
think this piece of your draft becomes an alternative to the base solution.

So this could have been a better "base" solution. Why then we did not consider 
it maybe about a year ago?

Regards,

Behcet

---

From: Hitoshi Asaeda <[email-masked]>
Date: Fri, 22 Jul 2011 02:07:07 +0900 (JST)

Hi Behcet,

> If PIM-SM at the MAG and LMA does not require any protocol
> extensions, then I think this piece of your draft becomes an
> alternative to the base solution.
> So this could have been a better "base" solution. Why then we did
> not consider it maybe about a year ago?

I believe that the combination of the routing protocol and mobility
support is required for the best solution. And the combination is
descrived in the single document. If the combination includes some
extension, then the proposal should be categorized as the extension.
This is the situation we have considered and presented in this draft.

The point we need to discuss for the further step is whether this
draft had better (again) split into two drafts or not; one is the
different base solution whose title would be "PMIPv6 multicast support
with PIM-SM and M-Tunnel", and the other is the extension proposal,
"(P)BU/(P)BA extension for multicast handover".

Please discuss it in the meeting.
I'll follow the decision made by the group.

Regards,
--
Hitoshi Asaeda

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 21 Jul 2011 11:35:31 -0700 (PDT)

Hi Hitoshi,
  Please split the draft into two (one informational one standard track) as soon 
as IETF draft submissions open up.
I have a concern about M-Tunnel. How is it different than MAG-LMA tunnel or
the upstream tunnel to the LMA as RFC 6224 calls it? 

Regards,

Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 21 Jul 2011 12:53:05 -0700 (PDT)

a little bit of correction. If you want your draft to be considered as a 
solution to the tunnel convergence problem, it could be standards track.

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Sun, 24 Jul 2011 12:24:42 -0400

Hi Hitoshi, hi all,

we worked through your revised draft and have the following feedback:

For the general, the draft seems to rephrase operations of GRE 
tunneling, PIM and MLD in your own words which leaves unclear, what 
actually is the standard protocol behavior (defined elsewhere), and what 
is particular for your proposal. Understanding is also hindered by 
observations that are correct, but unrelated to the specific subject, 
and also statements that are incorrect.

In detail, we extracted the following contributions:

   1.) Your proposal only addresses SSM (without ever mentioning this)
   2.) You span a full mesh of M-tunnels between all MAGs and all LMAs 
(in addition to PMIP tunnels)
   3.) You deploy PIM-SSM on all MAGs and all LMAs

Since this scenario experiences the routing convergence problem 
described in http://tools.ietf.org/html/rfc5757#section-2.2.2 (which you 
should reference, btw.), you define

   4.) Some additional smoothing procedures for handover

Did we understand this correctly?

Our comments on this:

Ad 1.): It is legitimate to define solutions solely for SSM, but this 
should be mentioned right away (in title and abstract).

Ad 2.): A mesh of permanent tunnels appears pretty ugly. In a large PMIP 
deployment, you will end up with hundreds to thousands of 
multicast-induced tunnels at a single LMA. This raises severe scaling & 
complexity issues, but most likely will be unfeasible for cross-domain 
PMIP deployments. As these tunnels are static and beyond the control of 
the PMIP prefix management, there may be issues arising for unicast 
routing, as well.

Ad 3.): PIM-SSM should transparently work on such a dense router mesh. 
However, multicast routes (selected from RPF) may not turn out to be as 
described in your draft. After an MN joins (S,G), its MAG selects the 
upstream according to the unicast route to S. What will this be? Most 
likely, S is completely "unrelated" to the MN and to its LMA, so the 
route to S may go wherever the (unicast) routing table of the local MAG 
points to. In many cases this will be default.

In addition, once MN1 has established service of (S,G) at a MAG, a newly 
arriving MN2 will inherit this service (which is efficient). Now, if MN1 
detaches, MN2 will continue to be served on the same route as MN1 did. 
In the (unlikely) case that MN1 had been subscribed to a "home service" 
(via its LMA, as suggested in your draft), MN2 continues to consume the 
"home service" of MN1, even though MN1 is gone.

This leads to a picture which is complicated, disadvantageous in 
policy-based conditions (btw. conflicts with your policy-store solution) 
and contradicts the PMIP service model.

As an intermediate summary: If we understood correctly, up until this 
point you have defined only a deployment scenario, but no new protocol 
operations or semantic. So this could simply be activated based on the 
protocols available today ... but may lead to a quite unexpected outcome ;)

Ad 4.): The scenario so far adapts to mobility via the PIM-SSM routing 
dynamics, which may be too slow for smooth handoffs. That's why you 
define three protocol extensions for smoothing the handover process for 
multicast (isolated from unicast handover management).

Comments on this:

  * Policy Profile: Your policy is acquired from LMA (after a regular 
PMIP handover). This is actually the long path & slow procedure, so I 
don't expect much acceleration here ... in particular, you cannot be 
faster than unicast (slow) handover. Also: this policy management 
conflicts with the routing scenario mentioned above.

  * Extended Proxy Binding Update: This I actually cannot understand. 
You inform the nMAG of multicast subscriptions prior to handover ... so 
you do a predictive handover, but you don't define any prediction 
mechanism. I cannot see how this works ...

  * CXTP: This context transfer is de-synchronized from the unicast 
handover, which does not really help in handover acceleration (cannot be 
faster than unicast, complicates a synchronization later ...).

CXTP handover may be interesting in the cases discussed after Prague (a 
new broadcast access link is selected solely for multicast reception 
...). We believe its not the most suitable approach here.

So far for the feedback - did we miss(s/s/ -understand) something?

Best regards,

Thomas & Matthias

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °

---

From: Hitoshi Asaeda <[email-masked]>
Date: Mon, 25 Jul 2011 14:16:03 +0900 (JST)

Thomas,Matthias

> actually is the standard protocol behavior (defined elsewhere), and
> what is particular for your proposal. Understanding is also hindered
> by observations that are correct, but unrelated to the specific
> subject, and also statements that are incorrect.

I was supprised that you almost misunderstood the document.
Please carefully read the document and related RFCs.

>   1.) Your proposal only addresses SSM (without ever mentioning this)

Not true. ASM is also supported.

>   (in addition to PMIP tunnels)

Not correct. Full mesh tunnel is not required.

>   3.) You deploy PIM-SSM on all MAGs and all LMAs

Not PIM-SSM, but PIM-SM, as the ducument explains.

> described in http://tools.ietf.org/html/rfc5757#section-2.2.2 (which
> you should reference, btw.), you define
> 

This is correct.

> Did we understand this correctly?

Unfortunately, you did not understand the document.
I give you answer in detail as follows.

> should be mentioned right away (in title and abstract).

It supports both ASM and SSM.
I don't understand why you believe it is only for SSM.
Your mistake comes because I use the words, "multicast channel" or
"subscription", in the document? If so, I would add the following
terminology in the terminology section;
"This document supports both Any-Source Multicast and Source-Specific
Multicast [SSM]. Nevertheless, regardless of whether a host specifies
source address(es) with multicast address, we use "multicast channel"
for multicast service identification and "subscription" for procedure
to listen multicast channel.

This terminology explanation resolves your misunderstanding?

> Ad 2.): A mesh of permanent tunnels appears pretty ugly. In a large
> PMIP deployment, you will end up with hundreds to thousands of
> multicast-induced tunnels at a single LMA. This raises severe scaling
> & complexity issues, but most likely will be unfeasible for
> cross-domain PMIP deployments. As these tunnels are static and beyond
> the control of the PMIP prefix management, there may be issues arising
> for unicast routing, as well.

Mesh connection is not the requirement. I don't understand why you
believe mesh is the requirement.
The number of M-Tunnels MAG configures will be usually the same as
that of the number of LMAs the MAG communicates with PBU/PBA.

> Ad 3.): PIM-SSM should transparently work on such a dense router
> mesh. However, multicast routes (selected from RPF) may not turn out
> to be as described in your draft. After an MN joins (S,G), its MAG
> selects the upstream according to the unicast route to S. What will
> this be? Most likely, S is completely "unrelated" to the MN and to its
> LMA, so the route to S may go wherever the (unicast) routing table of
> the local MAG points to. In many cases this will be default.

Both ASM and SSM are supported.
Moreover, your claim is very strange. You are saying PIM is disabled
on the upstream interface selected by an RPF. But PIM selects an
upstream interface only from its PIM neigohbors.

> In addition, once MN1 has established service of (S,G) at a MAG, a
> newly arriving MN2 will inherit this service (which is
> efficient). Now, if MN1 detaches, MN2 will continue to be served on
> the same route as MN1 did. In the (unlikely) case that MN1 had been
> subscribed to a "home service" (via its LMA, as suggested in your
> draft), MN2 continues to consume the "home service" of MN1, even
> though MN1 is gone.

Selecting a single incoming interface solves the tunnel convergence
problem. Allowing multiple incoming interfaces leads the tunnel
convergence problem. That's all.

> policy-based conditions (btw. conflicts with your policy-store
> solution) and contradicts the PMIP service model.

Ditto.
And information kept in policy profile is independent on the upstream
interface selection. So no conflict.

> protocols available today ... but may lead to a quite unexpected

I think most of your claimes are incorrect.

> define three protocol extensions for smoothing the handover process
> for multicast (isolated from unicast handover management).

Whether we use PIM-SM (not PIM-SSM) or MLD proxy (i.e. rfc6224), slow
handover will be happen, because no handover mechanism is provided in
these standard protocols. Therefore we would propose three possible
mechanisms for handover. Operators would select either one according
to their implementations, configuration, or policy.

> Comments on this:
> 
>  * Policy Profile: Your policy is acquired from LMA (after a regular PMIP
>  * handover). This is actually the long path & slow procedure, so I don't
>  * expect much acceleration here ... in particular, you cannot be faster
>  * than unicast (slow) handover. Also: this policy management conflicts
>  * with the routing scenario mentioned above.

Regarding the access to policy profile, there is no difference from
rfc5213. See Fig.3 in rfc5213.
Only the multicast information kept in policy profile is newly defined
in this document.

>  * Extended Proxy Binding Update: This I actually cannot understand. You
>  * inform the nMAG of multicast subscriptions prior to handover ... so
>  * you do a predictive handover, but you don't define any prediction
>  * mechanism. I cannot see how this works ...

No prediction provided in the PBU/PBA extension approach. The PBU/PBA
procedure sequences are also not changed from rfc5213.
Only the multicast subscription information exchanged with PBU/PBA is
newly defined in this document.

>  * handover, which does not really help in handover acceleration (cannot
>  * be faster than unicast, complicates a synchronization later ...).
> 
> CXTP handover may be interesting in the cases discussed after Prague
> (a new broadcast access link is selected solely for multicast
> reception ...). We believe its not the most suitable approach here.

The detail specification is described in Dirk's draft. Our draft
raises that solution as one of the candidate mechanisms.

> So far for the feedback - did we miss(s/s/ -understand) something?

In summary, I cannot find any important discussion that should be
addressed in the revised draft from your comments, except
terminology.

Regards,
--
Hitoshi Asaeda

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Mon, 25 Jul 2011 08:11:13 -0400

Hi Hitoshi,

before going into all the other details:

  Your draft describes (S,G) joins, only, and refers to and RPF 
interface selection w.r.t. S.

  To me, this is SSM with PIM-SSM.

  ASM with PIM-SM would perform an (*,G) join and the interface 
selection would follow the direction of a per group configured RP.

Let's first clarify what your draft *intends* to talk about.

Thomas

On 25.07.2011 01:16, Hitoshi Asaeda wrote:
>>   * handover). This is actually the long path&  slow procedure, so I don't

--

---

From: Hitoshi Asaeda <[email-masked]>
Date: Mon, 25 Jul 2011 21:57:32 +0900 (JST)

Thomas,

>  interface selection w.r.t. S.

Figure 2 illustrates the MLD report message transmission for (S,G)
join invoked by MNs.

>  selection would follow the direction of a per group configured RP.

The draft says an RPF lookup for PIM-SM. This explanation does not
eliminate ASM.

> Let's first clarify what your draft *intends* to talk about.

Again, the proposal supports both ASM and SSM.
--
Hitoshi Asaeda

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 25 Jul 2011 10:23:30 -0700 (PDT)

If MAG is deciding then there is only one choice, the LMA to which the MN is 
associated.
Isn't this why you talk about M-tunnel?

Behcet

> Again, the proposal supports both ASM and SSM.
PMIP
> >>>   *  Extended Proxy Binding Update: This I actually cannot understand.  
You

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Mon, 25 Jul 2011 13:41:18 -0400

Hi Hitoshi,

> Again, the proposal supports both ASM and SSM.

O.k., I guess this should be clarified in the writing. Also it is
unclear why the draft puts MLDv2 as a requirement.

Now following your answers and the presentation/discussion in the group,
the following seems to be clarified:

 * You span static tunnels between all LMA-MAG pairs that are in the
deployment scenario you consider. (This is what we called a mesh, but
mesh is only a word.) In typical cases, you will add some hundreds of
multicast-initiated tunnel end points to a single LMA ...

 * These M-tunnels are not used for PMIP unicast routing. Normally, they
shouldn't be used for the non-PMIP unicast routing either. So if you
just activate PIM-SM on the MAGs and LMAs, these tunnels will *not* be
used for multicast routing, as well (remember: RPF uses inverse unicast
routes).

 * If you plainly activate PIM-SM, the routing will follow the non-PMIP
unicast routing scheme deployed in the operator network. This is a
matter of individual deployment (not specified in PMIP or elsewhere) and
would most likely result in a straight-forward local routing solution
that ignores PMIP and the M-tunnels.

 * What you might do (but this is not described in your draft):
configure a separate PIM routing (MFIBs) that do use the tunnels.
However, this approach does not seem to have an obvious solution, since
multicast routing follows (S,G) or (*,G) states, i.e., builds up on
group addresses and sources, but PMIP (in particular: home
subscriptions) is build upon MN <-> LMA bindings. There seems to be no
obvious relation between a Group Channel and an LMA/MN, unless there is
a multicast address scheme that associates G <-> LMA.

I guess we got the core of your draft right now, correct?

Best regards,

Thomas

--

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Mon, 25 Jul 2011 13:57:20 -0400

Hi Behcet,

> If MAG is deciding then there is only one choice, the LMA to which the MN is

According to the draft, MAG runs PIM-SM. So PIM will decide according to 
its MFIB. Normally, this is derived from unicast routing - but as Stig 
pointed out in the meeting - one can configure an MFIB independent of 
the unicast routing.

The more important problem here seems the PMIP routing behavior. As 
clarified in the discussion with Alexandru and Raj, PMIP routing does 
not work like "ordinary unicast routing". Depending on the MNs source 
ID, the default route is chosen to point to the appropriate MAG <-> LMA 
tunnel - a behavior which is outside the regular IP routing (and cannot 
be expressed in the standard routing table, I suppose). In particular, 
it's hard to imagine how a (modified) PIM protocol could interact with 
this irregular PMIP routing. If you just deployed a PIM daemon on a MAG, 
PMIP would most likely remain invisible to PIM and - as said earlier - 
PIM would plainly interact with the provider-internal basic unicast 
routing layer.

Best regards,

Thomas

--

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 25 Jul 2011 11:02:51 -0700 (PDT)

Hi Thomas,
  In case of 6224, we defined a proxy instance for each LMA for upstream 
transmission.
Maybe PIM-SM draft should define something similar that is compatible with 
PIM-SM, like a specific MFIB that you mentioned in your previous mail.
Since we allow protocol extensions, it should be OK.

Behcet

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Mon, 25 Jul 2011 14:31:27 -0400

Hi Behcet,

>    In case of 6224, we defined a proxy instance for each LMA for upstream

Yes, and that saves us from the need to interact with PMIP routing 
(except for the configuration of the proxy instance).

> Since we allow protocol extensions, it should be OK.

Yes, that could be done from a general point of view. The problem seems, 
it is not clear how to do this reasonably and how to end up with 
something better than the base solution.

The (quite complex) PIM protocol allows for dynamic routing between 
various interfaces etc. I've no idea what actually would happen, if one 
changes PIM MFIBs externally triggered by PMIP handover operations. This 
sounds adventurous to me.

I guess, we have to ask the PIM chair for a wise opinion on that :-)

Best regards,

Thomas

On 25.07.2011 14:02, Behcet Sarikaya wrote:
>> ID, the default route is  chosen to point to the appropriate MAG<->  LMA

--

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 26 Jul 2011 17:53:32 +0900 (JST)

Thomas,

> unclear why the draft puts MLDv2 as a requirement.

PIM-SM is a multicast routing protocol providing router-to-router
communication.
MLDv2 is a protocol providing host-to-router communication.

It is very obvious that "multicast router" usually supports both
communications, but if it is better to describe this condition in the
document, I'll add some text in it.

> multicast-initiated tunnel end points to a single LMA ...

As I said, it is not necessary to create static M-Tunnels to all
LMA-MAG pairs. How many M-tunnels is set up is operators decision; it
would be same to or less than the number of association between
LMA-MAG. It can be adjusted by operators.

> used for multicast routing, as well (remember: RPF uses inverse unicast

Ok, now I understand your thought.
PIM-SM uses MRIB for RPF lookup. The MRIB could be same of the unicast
routing table, or could be provided by a separate routing protocol.
It seems that the current draft only mentions that MRIB is provided by
a separate routing protocol implicitly. But it is true that only using
a single unicast routing protocol can work with PIM-SM.

If only the regular unicast routing table is used for MRIB, the
regular IPv6-IPv6 tunnel for PMIPv6 is used. If operators want to
populate routes for specific multicast channels over M-Tunnel into
MRIB, M-Tunnel is used. As well, if a separate routing protocol is
used for MRIB, M-Tunnel is used.

Does this make sense?
I'll describe these conditions and the relation between MRIB and
M-Tunnel in the revised version. Thanks.

> that ignores PMIP and the M-tunnels.

As you see now, PIM-SM uses MRIB which could be taken from the unicast
routing table or a separate routing protocol. M-Tunnel contributes to
providing the path toward (*,G) or (S,G) without dependency of unicast
route in PMIPv6, if prefered.
BTW, specifying how MRIB is constructed in a network is out of scope
of this document because it is in general multicast operational schema.
But of couese, if it's useful, I'll add some text about MRIB
consideration in PMIPv6 in the revised draft.

> configure a separate PIM routing (MFIBs) that do use the tunnels.

Above answers your question?

> a multicast address scheme that associates G <-> LMA.

Multicast routing is established with (*,G) or (S,G). No receiver
involvement. What is your concern?

Regards,
--
Hitoshi Asaeda

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 26 Jul 2011 18:12:19 +0900 (JST)

Hi,

> According to the draft, MAG runs PIM-SM. So PIM will decide according
> to its MFIB. Normally, this is derived from unicast routing - but as
> Stig pointed out in the meeting - one can configure an MFIB
> independent of the unicast routing.

Right. PIM-SM works with MRIB, and MRIB is organized from unicast
routing protocol or separate protocol.
(BTW, you have been saying MFIB, but I expect MRIB is correct in your
contexts.)

> ID, the default route is chosen to point to the appropriate MAG <->
> LMA tunnel - a behavior which is outside the regular IP routing (and
> cannot be expressed in the standard routing table, I suppose). In
> particular, it's hard to imagine how a (modified) PIM protocol could
> interact with this irregular PMIP routing.

Yes. PMIPv6 may be unlike ordinal unicast routing protocol.
Separating RIB and MRIB is already the standard behavior in many
routing protocols. PIM-SM just refers to MRIB derived from RIB
organized for PMIPv6.
I don't imagine any problem, if PIM-SM is implemented along with the
RFC correctly.

> If you just deployed a PIM
> daemon on a MAG, PMIP would most likely remain invisible to PIM and -
> as said earlier - PIM would plainly interact with the
> provider-internal basic unicast routing layer.

PMIPv6 itself does not need to communicate with PIM-SM, if PMIPv6
organizes RIB correctly.

Regards,
--
Hitoshi Asaeda

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 26 Jul 2011 07:57:07 -0700 (PDT)

> used for MRIB, M-Tunnel is used.

So, use PMIP tunnel normally,
establish M-tunnel for additional connections like for local routing.
Is this what you are saying?

I suggest clear explanation of how PIM-SM will avoid the tunnel convergence 
problem in case regular PMIP tunnel is used.

Thanks,

Behcet

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Tue, 26 Jul 2011 11:21:46 -0400

Hi Hitoshi,

please see my answers inline (marked with Thomas>):

> MLDv2 is a protocol providing host-to-router communication.

Thomas> Sure, but PIM-SM (ASM) works fine with MLDv1. So I don't see a 
reason to exclude it.

> LMA-MAG. It can be adjusted by operators.

Thomas> Well, your solution builds on this M x N tunnel mesh. Of course, 
an operator can choose not to deploy it :-)

> routing table, or could be provided by a separate routing protocol.

Thomas> What other routing protocols than for unicast routing do you 
have in mind?

Anyway, PIM-SM commonly uses the underlying unicast routing protocol 
(except for inter-domain routing). If you don't use this, you need to 
provide a mechanism that explores the topology independently and 
provides a consistent view on (join/prune) routes all over the network.

You can provide MRIBs manually (thats like in the early days of the 
Internet), but if you define an alternate unicast routing protocol for 
building the MRIB, the world gets really complicated.

> a separate routing protocol implicitly.

Thomas> I did not see any mentioning of this.

> regular IPv6-IPv6 tunnel for PMIPv6 is used.

Thomas> I guess it's not: as mentioned earlier, PMIP routing does not 
work like ordinary unicast routing, but with source-dependent flapping 
of routing tables. I don't think PIM could live with this.

> If operators want to

Thomas> In general, yes. One can populate the M-tunnels with specific 
MRIBs. My problem with this idea is that I don't see any reasonable way 
to do this - because these routes will be permanent and cannot flip with 
the Mobile Subscriber that initiates the multicast forwarding.

Cheers,

Thomas

--

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Tue, 26 Jul 2011 11:31:45 -0400

Hi,

> (BTW, you have been saying MFIB, but I expect MRIB is correct in your
Thomas> pardon, this is BGP language. In PIM, (M)FIB = (M)RIB ... so no 
need to distinguish.

>> ID, the default route is chosen to point to the appropriate MAG<->

Thomas> As mentioned above: the problem is PMIP routing. You cannot 
express PMIP routing within a standard-conformal PIM MRIB.

There is an open request to the PIM WG chair whether he can imagine any 
way to introduce a PMIP-type routing table flapping into PIM-SM :-)

> PMIPv6 itself does not need to communicate with PIM-SM, if PMIPv6

Thomas> The problem is: it cannot "organize RIB correctly". And 
implementations most likely will not use standard-type RIBs.

Cheers,

Thomas

--

---

From: Hitoshi Asaeda <[email-masked]>
Date: Fri, 29 Jul 2011 11:54:22 +0900 (JST)

Hi Thomas,

I said again, the proposal supports both ASM and SSM. Not only ASM,
not only SSM.

> Thomas> pardon, this is BGP language. In PIM, (M)FIB = (M)RIB ... so
> no need to distinguish.

Not true. MRIB and MFIB are different in PIM-SM.
But, ok, it's not important in this discussion.

It may be possible that MAG would forward MN's packets to associated
LMAs without RIB. But in the general PMIPv6 implementation, MAG has a
routing table, and the routing table is maintained by IGP or
statically configured. In case of IGP, LMA injects aggregated prefixes
into IGP LMA and MAG speaks. This is our assumption.

I will ask to vendors and operators whether my assumption is correct
or not for the general PMIPv6 implementation. But imagine what happens
if routing table is not installed on MAG? How direct routing can be
implemented without a routing table? In PMIPv6 domain, there are many
routers or nodes other than LMA and MAG, and LMA and MAG would need to
communicate them not for mobile nodes in some cases. MAG should have a
routing table.

Thomas> There is an open request to the PIM WG chair whether he can
imagine any way to introduce a PMIP-type routing table flapping into
PIM-SM :-)

What is "PMIP-type routing table"? I cannot imagine PIM WG needs to do
something for our proposal at this moment.

> implementations most likely will not use standard-type RIBs.

Why do you insist this? What is your source?
I cannot find any statement about this in rfc5213.

Regards,
--
Hitoshi Asaeda

---

From: <[email-masked]>
Date: Fri, 29 Jul 2011 09:51:48 +0200

Hi,

> communicate them not for mobile nodes in some cases. MAG should have a

In our current PMIP implementation, MAG and LMA are mobility functions
supported by routers, as such, they both have routing table. Besides,
quoting RFC5213:

"The mobile access gateway is a function that typically runs on an
access router."

Moreover, when implementing localized routing, MAG MUST acts as routers.
Quting draft-ietf-netext-pmip-lr):

"packets are routed between the MAGs locally, without traversing the
LMA."

Anyway, I think that assuming MAG corresponds to realistic deployment
models. Actually, PMIPv6 is mainly foreseen for 3GPP/non-3GPP mobility
management (i.e. S2a/S2b interfaces in 3GPP/EPC architecture) where
non-3GPP MAGs are current access routers with additional mobility
capabilities. In other words, in real life, a MAG is not just a MAG,
it's also an access router in charge of managing non-mobile host with
standard routing mechanism.

My two cents,
Pierrick

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Fri, 29 Jul 2011 14:22:24 -0400

Hi Pierrick, Hitoshi,

there are actually two different subjects mixed here. This confuses the 
points:

  1) MAG is an Access*Router* - of course (I was arguing this here and 
in another thread). It has ordinary routing capabilities in the access 
network. Nobody objects this, so I fully agree with your statement, 
Pierrick.

  2) PMIP mobility routing, however, works differently and is *not* the 
regular access routing function you describe. Quoting from RFC5213:
      "On receiving a packet from a mobile node connected to its access
       link, to a destination that is not directly connected, the packet
       MUST be forwarded to the local mobility anchor through the bi-
       directional tunnel established between itself and the mobile
       node's local mobility anchor. "

This means: Depending on the identity of the MN (i.e. the source address 
/ incoming interface), the default route at the MAG is chosen to be MN's 
LMA. This is *not* regular IP routing and cannot be expressed in a 
standard routing table (but in the PMIP binding tables).

As repeated over and over again: When you deploy PIM-SM on a MAG without 
a dedicated MRIB, you will just use the regular IP unicast routing in 
the access network for JOIN/LEAVE operations and multicast will simply 
ignore the PMIP mobility management (as well as the M-tunnels).

In the converse, you cannot define a persistent MRIB for PIM that 
reflects PMIP mobility management, as PMIP unicast routes depend on the 
source address of the MN (and in addition changes with handovers).

That's all I'm trying to clarify since Sunday :-(

Thomas

--

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 29 Jul 2011 11:40:46 -0700 (PDT)

Hi Thomas,
  In RFC 6224 Section 4.2, you describe that a proxy instance is selected: 

The MAG decides on    the mapping of downstream links to a proxy instance (and 
hence an    upstream link to an LMA) based on the regular Binding Update List as    
maintained by PMIPv6 standard operations why do you think that something similar 
can not be achieved with PIM-SM?

Regards,

Behcet

>  1) MAG is an Access*Router* - of course  (I was arguing this here and in 
>another thread). It has ordinary routing  capabilities in the access network. 
>Nobody objects this, so I fully agree with  your statement, Pierrick.
> 
>  2) PMIP mobility routing, however, works  differently and is *not* the regular 
>access routing function you describe.  Quoting from RFC5213:
> This means: Depending on the identity of the MN  (i.e. the source address / 
>incoming interface), the default route at the MAG is  chosen to be MN's LMA. 
>This is *not* regular IP routing and cannot be expressed  in a standard routing 
>table (but in the PMIP binding tables).
> 
> As repeated  over and over again: When you deploy PIM-SM on a MAG without a 
>dedicated MRIB,  you will just use the regular IP unicast routing in the access 
>network for  JOIN/LEAVE operations and multicast will simply ignore the PMIP 
>mobility  management (as well as the M-tunnels).
> 
> In the converse, you cannot define  a persistent MRIB for PIM that reflects 
>PMIP mobility management, as PMIP  unicast routes depend on the source address 
>of the MN (and in addition changes  with handovers).
>

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Fri, 29 Jul 2011 17:32:12 -0400

Hi Behcet,

this is because PIM is running only in a single instance (hard to 
imagine how different PIM instances could coexist).

While in 6224 the forwarding logic (Proxy instance) is selected 
according to the LMA-binding (collect all MNs that belong to one LMA), 
PIM just sees links/interfaces and a single routing table (MRIB). 
Routing rules that follow PMIP bindings would need to be expressed in 
this routing table ... and I cannot imagine how that should work.

Maybe someone else can - but up until now nobody has revealed an approach.

Best regards,

Thomas

--

---

From: Hitoshi Asaeda <[email-masked]>
Date: Sat, 30 Jul 2011 12:09:39 +0900 (JST)

Hi Thomas,

>  network. Nobody objects this, so I fully agree with your statement,

Right. This means MAG has a routing table.

>       node's local mobility anchor. "

"Packets MUST be forwarded to the LMA through the bi-directional
tunnel established between MAG and the mobile node's LMA"

Yes, it's true for unicast! But this does not say anything about a
situation where MAG does not have a routing table.
Is this the reason that you insist MAG does not have a routing table?

> This means: Depending on the identity of the MN (i.e. the source
> address / incoming interface), the default route at the MAG is chosen
> to be MN's LMA. This is *not* regular IP routing and cannot be
> expressed in a standard routing table (but in the PMIP binding
> tables).

I think this interpretation is not correct.

> As repeated over and over again: When you deploy PIM-SM on a MAG
> without a dedicated MRIB, you will just use the regular IP unicast
> routing in the access network for JOIN/LEAVE operations and multicast
> will simply ignore the PMIP mobility management (as well as the
> M-tunnels).

I don't deny that PIM-SM needs MRIB (which would be populated from a
unicast routing table) to work.
I said your assumption that MAG does not have a routing table seems to
be unreasonable (or maybe incorrect) for me.
So I'm asking where is your source (i.e. description) of your
assumption, because I cannot find such description anywhere.
(IMO, above quote from rfc5213 does not say "MAG does not have a
routing table in general".)

> reflects PMIP mobility management, as PMIP unicast routes depend on
> the source address of the MN (and in addition changes with handovers).
> 

Take care.
Regards,
--
Hitoshi Asaeda

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Sat, 30 Jul 2011 08:02:33 -0400

Hi Hitoshi,

I don't think we're getting anywhere:

  1.) I never claimed (nor insisted) that MAG does *not have* a routing 
table.
      (All I'm saying is: you misinterpret this routing table at the MAG)

  2.) It is my impression that you are not sufficiently familiar with 
PMIP routing/forwarding. I suggest you discuss this with the PMIP 
experts (as you don't believe me anyway).

Best regards,

Thomas

--

---

From: Hitoshi Asaeda <[email-masked]>
Date: Sun, 31 Jul 2011 02:02:18 +0900 (JST)

Thomas,

>      (All I'm saying is: you misinterpret this routing table at the MAG)

Ok, I should not say, "not have a routing table", but should precisely
say "not have a standard type RIB".

Your thought is; "MAG does not have a standard type RIB".
And my thought is opposite; "MAG has a standard type RIB (which could
be used by PIM-SM)".

>  experts (as you don't believe me anyway).

Be calm...

If you were the expert, you could explain precisely why PIM routing
protocol cannot work on MAG.

We can ask to netext ML, but at first I want to know why you insist
MAG does not have a standard type RIB and what is your source about
your thought.
If someone explains Thomas's claim about no standard RIB on MAG, or if
someone tells us what is the correct answer, I'd appreciate your help.

Thank you for all.
Regards,
--
Hitoshi Asaeda

---

From: Sri Gundavelli <[email-masked]>
Date: Sat, 30 Jul 2011 18:10:29 -0700

Guys:

My input on this thread. Not to take any sides in this heated discussion,
but what I believe we covered in the base specs.

1. LMA is a IP layer-3 router and so is the home agent as specified in
RFC-3775. LMA is a feature extension to MIPv6 home agent. See Section 5.0 in
RFC-5213. Also, the section 7.1 of RFC-3775, regarding Router Advertisement
messages from the home agent, and also DHAAD related considerations.

   "The local mobility anchor MUST support the home agent function as
   defined in [RFC3775] and the extensions defined in this
   specification.  A home agent with these modifications and enhanced
   capabilities for supporting the Proxy Mobile IPv6 protocol is
   referred to as a local mobility anchor."

2. MAG is a IP layer-3 router. Refer to 6.9.3 of RFC-5213.
 
   "In Proxy Mobile IPv6, the mobile access gateway is the IPv6 default-
   router for the mobile node on the access link."

3.  MAG is hosting MN's HNP on the access link. It injects a connected route
into the routing table. However, this route is not redistributed beyond the
MAG. When the MAG receives a packet from the tunnel, after decap, the packet
is forwarded on the MN-AR link. It needs to check the route table, however,
implementations may do it other ways too without using routing tables, but
intercepting every packet and checking the BUL table. But, for all practical
purposes, MAG has a standard IP unicast RIB.

4. LMA is hosting the mobile node's home network prefixes. It is the anchor
point for mobile node's sessions; it is the entry point for the mobile
node's data traffic. LMA injects an aggregated routing prefix into IGP, so a
CN's IP packets to MN always reach the LMA. The injected aggregated routing
prefix is redistributed into IGP. LMA has a standard IP unicast RIB and
that's 

5. LMA function is hosted on LTE PDN gateway. It is a layer-3 IP router, and
all known commercial implementation including cisco's mobile gateways
confirm to this. MAG is a hosted on a access edge gateway such as WLAN edge
router, WiMAX ASN Gateway, 3GPP2 HSS Gateway, they all are standard IP
routers, with standard IP RIB.

6. I will not talk on multicast RIB, I know, you guys will argue that the
base specs did not cover this topic sufficiently and which is true. But, I
will say, LMA/MAG are standard IP routers, and there is no reason to believe
they cannot support "standard" multicast RIB/functions, if not PMIP related
multicast extensions. All most all the specs implicitly assume this fact.

Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Sat, 30 Jul 2011 20:02:54 -0700

I missed one other aspect on MAG handles the uplink packets.

- Any IP packet from the mobile node using the source address (IPv4 HoA, or
an address from any of the prefix IPv6 HNP), the MAG forwards the packets
through the MAG-LMA tunnel.  This is PBR (Policy Based Routing). A next hop
determination based on a source L2/L3, dest L2/L3, DSCP or other parameters
in the packet. Is this a standard RIB behavior ? May not be per the legacy
assumption we have about RIB or on how routing works. But, at the same time,
this decision logic can be very well be present in a RIB. At the end of the
day these can be elements in the Routing Information Base. I do not believe
we have a IETF RFC definition on the exact RIB structure, but I believe this
is just a variant of advanced IP forwarding behavior.

Sri

---

From: Hitoshi Asaeda <[email-masked]>
Date: Sun, 31 Jul 2011 13:06:56 +0900 (JST)

Hi Sri,

> multicast extensions. All most all the specs implicitly assume this fact.

Thank you very much for your precise explanation.

I continue our draft work based on the current direction.
I know there are some ambiguities in our current draft, so we will
revise it soon to improve the quality.

Regards,
--
Hitoshi Asaeda

---

From: Hitoshi Asaeda <[email-masked]>
Date: Sun, 31 Jul 2011 13:16:12 +0900 (JST)

Sri,

> assumption we have about RIB or on how routing works. 

This PBR behavior does not affect anything for receiver mobility with
PIM-SM.
For sender mobility with PIM-SM, this PBR assumes that multicast
packets sourced by MNs go through LMA. If this is the policy in
PMIPv6, then PIM-SM just follows the decision. I would say, this is
the case where PBR injects policy in the standard RIB (and PIM-SM
could adopt the policy in its MRIB).

> But, at the same time,

I agree.

Regards,
--
Hitoshi Asaeda

---

From: "Luis M. Contreras" <[email-masked]>
Date: Sun, 31 Jul 2011 14:42:18 +0200

Hi all,

I think that the Thomas concerns yet apply.

The MAG maintains of course a RIB. Any device will be reachable by whatever
interface except through the multicast tunnel with LMA because there is no
routing information propagation through the tunnel.

If the MAG sends out a PIM join message through the tunnel interface to the
LMA, once the LMA forwards the multicast flow to the MAG by using the
tunnel, the MAG will implement RPF checking, and as consequence, the MAG
will discard the multicast traffic because the source of that multicast
traffic is not reachable through the multicast tunnel.

I think this is the point Thomas highlights.

A way to overcome this issue is advanced in section 4 of
draft-zuniga-multimob-smspmip-06, where PIM is enabled only on the MAG's
tunnel interface to the MTMA (i.e., the entity anchoring the multicast tree
in the PMIPv6 domain). This has to be complemented with a multicast static
route pointing to the tunnel to pass the RPF checking.

An scenario where PIM routing is generally enabled in the MAG will need more
complicated configuration, I guess, if we want some coexistence of muticast
traffic coming from the LMA and from the other MAG interfaces. Without an in
depth analysis, I think that in case the PIM routing is generally enabled in
the MAG, all the PIM messaging will follow other interfaces different to the
tunnel interface to the LMA, because either the RP in the ASM case, or the
source in the SSM case, can be reached by the MAG through other interfaces
distinct to the tunnels towards the LMAs. If we force the PIM messages to go
to the LMA, then the multicast forwarding will fail due to the RPF check.

Best regards,

Luis
2011/7/31 Hitoshi Asaeda <[email-masked]>

---

From: Hitoshi Asaeda <[email-masked]>
Date: Mon, 01 Aug 2011 00:29:24 +0900 (JST)

Hi Luis,

> traffic is not reachable through the multicast tunnel.

This is a different topic from the discussion about standard RIB.
Your point is that M-Tunnel is not recognized in RIB. So if MRIB just
copies from RIB, then M-Tunnel will be ignored.
It is true, but it is Ok.

M-Tunnel will be only used for special mroutes (which are independent
from unicast routes) being injected into MRIB. 
When operators want to configure a special mroute, which is not the
same unicast route for the destination, then they may use M-Tunnel to
configure the independent mroute. And the configured mroute (using
M-Tunnel) will be injected into MRIB.
In other words, if operators do not need to distinguish RIB and MRIB for
multicast forwarding at all, they don't need to configure M-Tunnel for
mroutes. PIM-SM just uses the standard RIB as its MRIB in this case.

Providing functionality to distinguish RIB and MRIB is the requirement
for the use of PIM-SM, I think. And M-Tunnel could be used for
configuring special mroute being injected into MRIB. However, if people
confuse, I will remove this optional tunnel from the revised draft.

> route pointing to the tunnel to pass the RPF checking.

When operators use the regular IPv6-IPv6 tunnel as the link for
LMA-MAG connection in PIM-SM, PIM-SM simply can adopt the regular
tunnel as the upstream link. And, even if MAG connects to multiple
LMAs via multiple IPv6-IPv6 tunnels, PIM-SM selects an upstream
interface for the (*,G) or (S,G) with the RFP algorithm.

> complicated configuration, I guess,

To me, PIM-SM is much simpler than MLD proxy configuration.
MLD proxy definitively requires to configure the upstream interface.
If MAG may associate multiple LMAs, MAG must install the same number
of MLD proxy instances and configure each upstream interface. If MAG
needs to communicate other multicast routers, let's say, for direct
route, then it also installs the other MLD proxy instance and
configure the upstream interface for it independently.

Well, I feel your "multicast LMA" solution is simple and good. I don't
deny it. But I'd say I like PIM-SM solution more, because it is more
generally appricable. And it is in fact simpler. If operators install
PIM-SM on MAG, then MAG can select upstream interfaces for any (S,G)
and (*,G) thanks to the RPF.

> if we want some coexistence of muticast

Please read above.
If operators don't need to distinguish RIB and MRIB, then no need to
configure special tunnel.

Regards,
--
Hitoshi Asaeda