Subject: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 8 Dec 2011 14:53:29 -0600

Hello all,
  There was consensus on the tunnel convergence solution draft in Taipei.
 This mail is to confirm the consensus.

This document can be found at:
http://tools.ietf.org/id/draft-zuniga-multimob-pmipv6-ropt-01.txt

This mail starts a WG adoption call on this draft.

The intended status for this document is proposed standard.
If adopted, the draft will be named:

draft-ietf-multimob-pmipv6-tunnel-convergence.

Please your comments by December 15, 2011.

Chairs

---

From: Hitoshi Asaeda <[email-masked]>
Date: Fri, 09 Dec 2011 09:31:48 +0900 (JST)

Behcet,

> Please your comments by December 15, 2011.

I don't think there was any consensus about adoption of this draft at
the last meeting.

We've proposed the tunnel convergence problem solution draft;
draft-asaeda-multimob-pmip6-extension-07

Why you eliminate the discussions in the meeting and the chance to
discuss in the mailing list?

Before explaining the thoughts about draft-zuniga draft, I'd make you
understand the situation of our draft.

1. I think Thomas always misunderstands the point. MAG is a router and
   has its own RIB. PIM can use its RIB and can copy it to its MRIB.
   When we need to define dedicate multicast routes, we can configure
   the ones. We do not need PMIPv6-based policy routing for RPF check.
   After the last meeting I understand Thomas's misinterpretation
   comes from this. I will clearly emntion it in the revised version.

2. My -06 draft defines GRE type M-Tunnel to define MAG's upstream IF
   to distinguish the regular IPv6 tunnel. But according to the previous
   discussion in the ML, we eliminate the way to distinguish unicast
   and multicast tunnels to make the story simple in -07 draft.
   But I recognized this elimination was not always correct, because
   we cannot assume that a unocast route toward sources outside of
   PMIPv6 domain defined in MAG's RIB always goes through the regular
   IPv6 tunnel. Therefore GRE type M-Tunnel will be recalled from -06
   to the revision -08.

3. One important discussion missing in -06 is the way to select a single
   M-Tunnel when multiple M-Tunnels are configured for the same (S,G)
   or (*,G). This can be addressed in the revised draft, too.

For your question, I don't think
draft-zuniga-multimob-pmipv6-ropt-01.txt should be adopted now.

Regards,
--
Hitoshi Asaeda

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Fri, 09 Dec 2011 00:33:39 -0600

Hi Hitoshi,

>     has its own RIB. PIM can use its RIB and can copy it to its MRIB.

No, MAG's RIB doesn't reflect PMIP routing and the proposed implications 
are a simple mistake.

Hitoshi, I spent half the summer trying to explain to you how PMIP 
routing works - you wouldn't listen and I gave up.

Then Sri stepped in and explained the same thing again: The MAG performs 
policy-based routing according to policy filters, not according to a 
regular RIB.

Again in Taipei, Sri explained PMIP routing and I guess (almost) 
everybody in the room understood his words.

So, if you still argue on the issue, please argue against the PMIP 
authors, not against me. I have no iron in the fire, here, and only 
tried to mediate ...

Cheers,

Thomas
-- 

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: Fri, 09 Dec 2011 16:06:37 +0900 (JST)

> No, MAG's RIB doesn't reflect PMIP routing and the proposed
> implications are a simple mistake.

Sure. MAG's RIB doesn't need to reflect PMIP *unicast* routing.
I said again and again, MAG's RIB is constructed independently and PIM
can use the MAG's RIB for its RPF check. PIM does not use PMIP's
policy route for MNs for its RPF check. And if PIM doesn't want to use
MAG's RIB for some multicast channels, then independent M-Tunnel can
be configured as their upstream IF into its MRIB.

> routing works - you wouldn't listen and I gave up.

Good! So could you kindly keep silent for a while?
Then we can communicate well and go forward.

> Then Sri stepped in and explained the same thing again: The MAG
> performs policy-based routing according to policy filters, not
> according to a regular RIB.

He said about unicast routes for MNs. PMIP's policy routing is the
one. He did not say anything about PIM's RPF check and admitted MAG
has its own RIB. And I've been saying MAG's RIB can be used as PIM for
*PRF check*.

Sri, if I'm wrong, please tell me.

> everybody in the room understood his words.

Yes, he was correct. He explained that PMIP is policy based routing
for sending unicast packets to MNs. It is unicast communication for
MNs. Multicast is completely different.

> authors, not against me. I have no iron in the fire, here, and only

I only explain the truth in my sense. I've never argued against
reasonable comments.

I'm waiting for reasonable comments. Sri?

Regards,
--
Hitoshi Asaeda

---

From: Hitoshi Asaeda <[email-masked]>
Date: Fri, 09 Dec 2011 18:42:34 +0900 (JST)

Thomas,

> according to a regular RIB.

Then we should ask you one thing.
Why your source mobility draft introduces PIM-SM and Bidir PIM on MAG?

In Section 5, your source mobility draft says;

  "a multicast routing protocol such as PIM-SM [RFC4601] or BIDIR-PIM
   [RFC5015] deployed at the MAGs."

It constitutes a contradiction with your all statements.

I hope this WG goes in the right direction.

Regards,
--
Hitoshi Asaeda

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Fri, 09 Dec 2011 12:10:31 -0600

Hitoshi,

>     [RFC5015] deployed at the MAGs."

We are considering the direct mcast routing deployment (not following 
PMIP) - for receivers, this is the solution of Seil. There is no problem 
with it.

Your proposal under debate is: Use PIM-SM on PMIP tunnels and in 
concordance with PMIP routing, which is a completely different story.

However, to resolve the debate, there is a very simple reality-check:

  For a basic PMIP scenario (MAG with 2 LMA uplinks and MNs associated 
to either LMA), please just write down *one* PIM-SM multicast routing 
table that accounts for PMIP routing and works for all MNs attached to 
the MAG.

  If you can do so correctly, you have proved that your approach is 
feasible.

Thanks,

Thomas

--

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 9 Dec 2011 17:07:43 -0600

Hi Hitoshi,

Please see inline.

Regards,

Behcet

>>  This mail is to confirm the consensus.

Yes, there was. Please check the minutes.

> draft-asaeda-multimob-pmip6-extension-07
Your draft and draft-zuniga present totally different approaches. They
do not overlap with each other.

> discuss in the mailing list?

Who said so? Your draft is still up for discussion. I already saw some
comments on it in the list. So you should be happy.

>   or (*,G). This can be addressed in the revised draft, too.

The above has nothing to do with draft-zuniga so we can not take it as
a technical comment. Sorry.

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Fri, 09 Dec 2011 17:59:12 -0600

Hi all,

some feedback:

  In general, I support adopting this document as a WG item - it 
presents two valid deployment scenarios. But I guess, the intended 
status should be informational, as this is just presenting deployment 
advice (I know, currently the document does more ...).

  We've been discussing the two solutions (Multicast-Tunnelendpoint, 
direct routing) for quite a while and we should come to conclusions ... 
on the current document I only had a very brief look (apologies!).

  Here are three comments:

  1.) On the quick run, I cannot see what Section 3.5  "PMIPv6 
enhancements" really is needed for. I know, I should re-read this (no 
time now), still the MTM approach should work without protocol 
modifications, I guess.

  2.) There should be a section / solution on IPv4 compatibility 
(including address collisions ...) as needed for PMIPv6.

  3.) The direct routing section (4) is still rather superficial. It 
should explain in detail how to deploy protocols, e.g., PIM-SM in the 
presence of these PMIP tunnels ... just to avoid the confusion that has 
been evident on this list since Quebec ;) .

That's only for a quick feedback,

Thomas

On 08.12.2011 14:53, Behcet Sarikaya wrote:
> _______________________________________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multimob

--

---

From: Hitoshi Asaeda <[email-masked]>
Date: Sat, 10 Dec 2011 10:14:30 +0900 (JST)

Thomas,

> PMIP) - for receivers, this is the solution of Seil. There is no
> problem with it.

Ok, so you now admit MAG has its own RIB and PIM can use it, where
this is my basic assumption. That's a relief.

> concordance with PMIP routing, which is a completely different story.

No, it's not true.
Our solution does not need to conform to PMIP *unicast* routing *to
MNs*.
To construct multicast routing tree, knowing unicast route to each
receiver is not necessary. Only multicast routers need to understand
the interface toward sources. It's the way the regular multicast
routing does.

>  If you can do so correctly, you have proved that your approach is

Oh, finally you understand the point. Good!
Yes, it is mentioned in our working plan to address it in my
yesterday's mail.

Regards,
--
Hitoshi Asaeda

---

From: seil jeon <[email-masked]>
Date: Sat, 10 Dec 2011 17:08:12 +0900

Hi Thomas,

Thanks for your valuable comments from your busy schedule.

Please see inline.

Best Regards,

Seil Jeon

2011/12/10 Thomas C. Schmidt <[email-masked]>

> Hi all,
>
> some feedback:
>
>  In general, I support adopting this document as a WG item - it presents
> two valid deployment scenarios. But I guess, the intended status should be
> informational, as this is just presenting deployment advice (I know,
> currently the document does more ...).
>
>  We've been discussing the two solutions (Multicast-Tunnelendpoint, direct
> routing) for quite a while and we should come to conclusions ... on the
> current document I only had a very brief look (apologies!).
>
>  Here are three comments:
>
> enhancements" really is needed for. I know, I should re-read this (no time
> now), still the MTM approach should work without protocol modifications, I
> guess.
>

=> Maybe, Zuniga needs to talk about it.

>
>  2.) There should be a section / solution on IPv4 compatibility (including
> address collisions ...) as needed for PMIPv6.
>
=> We'll check what kinds of considerations including address
collisions for IPv4 support with Zuniga.

>  3.) The direct routing section (4) is still rather superficial. It should
> explain in detail how to deploy protocols, e.g., PIM-SM in the presence of
> these PMIP tunnels ... just to avoid the confusion that has been evident on
> this list since Quebec ;).
>
=> In next version, the operations of MAG and MN will be updated.
Additional considerations will be added.

>> http://tools.ietf.org/id/**draft-zuniga-multimob-pmipv6-**ropt-01.txt<http://tools.ietf.org/id/draft-zuniga-multimob-pmipv6-ropt-01.txt>
>>
>> draft-ietf-multimob-pmipv6-**tunnel-convergence.
>>
>> ______________________________**_________________
>> multimob mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/multimob<https://www.ietf.org/mailman/listinfo/multimob>
>>
>
> --
>
> ° http://www.informatik.haw-**hamburg.de/~schmidt<http://www.informatik.haw-hamburg.de/~schmidt>   Fax: +49-40-42875-8409 °
>  ______________________________**_________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/multimob<https://www.ietf.org/mailman/listinfo/multimob>
>

---

From: seil jeon <[email-masked]>
Date: Sat, 10 Dec 2011 17:15:53 +0900

Hi Thomas, Hitoshi,

This discussion has been continuing repeatedly.

Please check my understanding is correct from the dicussion between Thomas
and Hitoshi.

When the MAG is connected with other PIM-SM router not over LMA, there's no
problem. PIM-SM establishes multicast routing path using RPF algorithm
through reflecting MAG's RIB.

But when the MAG is connected with several LMAs including PIM-SM, MRIB
SHOULD get information from PMIP routing table but "MAG's RIB doesn't
reflect PMIP routing" (Thomas and Hitoshi agreed it).

So, Thomas, you think that this does not solve tunnel convergence problem.

Is it clear? Thomas

>  For a basic PMIP scenario (MAG with 2 LMA uplinks and MNs associated to
> either LMA), please just write down *one* PIM-SM multicast routing table
> that accounts for PMIP routing and works for all MNs attached to the MAG.
>

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Sat, 10 Dec 2011 10:33:15 -0600

Hi Seil,

> reflect PMIP routing" (Thomas and Hitoshi agreed it).

the "problem" that causes these repeated errors in reasoning here on the 
list is the following (quoting Sri):

   1. PMIP routing is not ordinary routing, but policy-based.
      This means, it is not based on the destination address, but
      on policy filters, in this case *source* addresses.

   2. The consequence is: You cannot write PMIP routing rules in a 
regular routing table.

   3. Because you cannot write PMIP routing in *one* normal RIB, you 
also cannot built a (PIM-SM) MRIB from it.
      (And this is the reality-check for Hitoshi: he will see that he 
cannot write an MRIB in this case ...).

In general, there is no big deal about this. The fuzz is only that 
draft-asaeda-multimob-pmip6-extension-07 is built upon an error from 
misunderstanding PMIP routing ...

Your problem of draft 
http://tools.ietf.org/id/draft-zuniga-multimob-pmipv6-ropt-01.txt is a 
different one. You need to describe deployment of direct routing (e.g, 
PIM) at a MAG that runs PMIP routing (including tunnel interfaces) and 
normal routing in the access network (the non-PMIP case). You should 
explain this in your draft so well that readers can understand and 
successfully deploy. In the current version you just say "turn on PIM" 
... and that's not all, I guess.

Best,

Thomas

> 2011/12/10 Thomas C. Schmidt <[email-masked]
> <mailto:[email-masked]>>
>
>     Hitoshi,
>
>
>     We are considering the direct mcast routing deployment (not
>     following PMIP) - for receivers, this is the solution of Seil. There
>     is no problem with it.
>
>       For a basic PMIP scenario (MAG with 2 LMA uplinks and MNs
>     associated to either LMA), please just write down *one* PIM-SM
>     multicast routing table that accounts for PMIP routing and works for
>     all MNs attached to the MAG.
>
>     ° http://www.informatik.haw-__hamburg.de/~schmidt
>     <http://www.informatik.haw-hamburg.de/~schmidt>    Fax:
>     +49-40-42875-8409 °
>
>     _________________________________________________
>     multimob mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/multimob
>     <https://www.ietf.org/mailman/listinfo/multimob>
>
>
>
>

--

---

From: "Rahman, Akbar" <[email-masked]>
Date: Sun, 11 Dec 2011 15:39:41 -0500

Hi Bechet,

I agree that there was good consensus on
draft-zuniga-multimob-pmipv6-ropt during the IETF meeting in Taipei.  So
I support adopting this document as a WG I-D.

Akbar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Behcet Sarikaya
Sent: Thursday, December 08, 2011 3:53 PM
To: [email-masked]
Subject: [multimob] WG adoption call on
draft-zuniga-multimob-pmipv6-ropt

Hello all,
  There was consensus on the tunnel convergence solution draft in
Taipei.
 This mail is to confirm the consensus.

Chairs

---

From: Hitoshi Asaeda <[email-masked]>
Date: Mon, 12 Dec 2011 14:59:31 +0900 (JST)

Behcet and others,

> Yes, there was. Please check the minutes.

Hmm, I didn't notice at all..

> do not overlap with each other.

Right. They are totally different.

> comments on it in the list. So you should be happy.

It is not important whose draft is adopted.
Showing technical feasibility and contributions to communities is all
that really matters for WGs.

Ok, let's move on the discussion for draft-zuniga.

Maybe draft-zuniga has some value as it can escape from the tunnel
convergence problem.
Briefly, the approach requires that MAG attaches *one*
multicast-dedicate LMA (MTMA, the draft calls) and always uses it,
instead of the regular rfc5312 based LMAs, for all external multicast
streams.
According to this fact, it does not provide protocol improvement and
is not optimized (as all are done by operation), but simply proposes a
multicast service model for PMIPv6 to escape from the tunnel
convergence problem.

If people agree on the adoption, it's Ok. But I cannot find the reason
that it is proposed standard. Informational would fit to the current
approach if adopted.

Regards,
--
Hitoshi Asaeda

---

From: Hitoshi Asaeda <[email-masked]>
Date: Mon, 12 Dec 2011 15:21:22 +0900 (JST)

Hi Seil,

> This discussion has been continuing repeatedly.

It'd be better to move on more fundamental discussion, though..

> through reflecting MAG's RIB.

Whether routing "over LMA" or not is not precise.

> reflect PMIP routing" (Thomas and Hitoshi agreed it).

Not very precise.
PIM-SM does not need to use PMIP policy routing at all.
Some MRIB entries are copied from MAG's RIB, other MRIB entries are
separately configured if needed. The MRIB entries may use M-Tunnel
established between MAG and LMA.

Regards,
--
Hitoshi Asaeda

---

From: Hitoshi Asaeda <[email-masked]>
Date: Mon, 12 Dec 2011 15:25:57 +0900 (JST)

> the "problem" that causes these repeated errors in reasoning here on
> the list is the following (quoting Sri):
> 

For multicast tree construction, knowing receiver's address is not
necessary for PIM. PIM only needs to recognize an upstream interface
toward sources or RP. Therefore PMIP policy routing for MNs is *not
needed* for MAG enabling PIM.

>   2. The consequence is: You cannot write PMIP routing rules in a

We don't need it.

>   3. Because you cannot write PMIP routing in *one* normal RIB, you also
>   cannot built a (PIM-SM) MRIB from it.
>      (And this is the reality-check for Hitoshi: he will see that he cannot
>      write an MRIB in this case ...).

Not we *cannot*. It is *not needed*.

Regards,
--
Hitoshi Asaeda

---

From: "Shuai Gao" <[email-masked]>
Date: Mon, 12 Dec 2011 15:44:34 +0800

Hi Hitoshi,
	Let me express my understanding for the discussed problem recently.  
	In your draft, a LMA or an adjacent router is chosen as an upstream router. And you mentioned that the upsteam router is selected by the Reverse Path Forwarding (RPF) algorithm (section 3.2), which may not work actually.   I assume that your RPF algorithm here is performed to find an upstream router to the RP or specific router.  Is it right? If so, I'm afraid that the LMA will have no chance to be chosen as the upstream router by the RPF, because PMIP routing is policy-based routing  at the MAG for specific mobile sources rather than other routers.   That's the problem concerned by the folks here, I think. 

	 Hope to help you.

Shuai
======= 2011-12-12 14:26:02 您在来信中写道：=======

>Not we *cannot*. It is *not needed*.

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

　　　　　　　　致
礼！

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

---

From: Hitoshi Asaeda <[email-masked]>
Date: Mon, 12 Dec 2011 17:00:40 +0900 (JST)

Hi Shuai,

> 	In your draft, a LMA or an adjacent router is chosen as an
> 	upstream router. And you mentioned that the upsteam router is
> 	selected by the Reverse Path Forwarding (RPF) algorithm
> 	(section 3.2), which may not work actually.   I assume that
> 	your RPF algorithm here is performed to find an upstream
> 	router to the RP or specific router.  Is it right? If so, I'm
> 	afraid that the LMA will have no chance to be chosen as the
> 	upstream router by the RPF, because PMIP routing is
> 	policy-based routing  at the MAG for specific mobile sources
> 	rather than other routers.   That's the problem concerned by
> 	the folks here, I think. 

If LMA is not selected as the upstream router for some multicast
channel, then operator configures M-Tunnel established between MAG and
LMA and adds the routes using that M-Tunnel for appropriate group
prefix of source prefix (i.e. into MRIB). This is what I'm saying.

(One appology is that I eliminated GRE type M-Tunnel from -06, and -07
draft does not mention it. That change was for eliminating the
complexity, but it was not correct. If you hence confuse that point,
I'd apologige.)

Regards,
--
Hitoshi Asaeda

---

From: seil jeon <[email-masked]>
Date: Mon, 12 Dec 2011 17:06:41 +0900

Hi Thomas,

Please see inline.

Regards,

Seil Jeon

2011/12/11 Thomas C. Schmidt <[email-masked]>

>  2. The consequence is: You cannot write PMIP routing rules in a regular
> routing table.
>
In general, there is no big deal about this. The fuzz is only that
draft-asaeda-multimob-pmip6-**extension-07 is built upon an error from
misunderstanding PMIP routing ...
=> My intention was to clarify the differences between you and Hitoshi.
Now, I think the issue is getting more clear.

Your problem of draft http://tools.ietf.org/id/**
draft-zuniga-multimob-pmipv6-**ropt-01.txt<http://tools.ietf.org/id/draft-zuniga-multimob-pmipv6-ropt-01.txt>is
a different one. You need to describe deployment of direct routing
(e.g,
PIM) at a MAG that runs PMIP routing (including tunnel interfaces) and
normal routing in the access network (the non-PMIP case). You should
explain this in your draft so well that readers can understand and
successfully deploy. In the current version you just say "turn on PIM" ...
and that's not all, I guess.

 => Yes, definitely. As I told it in the previous list, it will be added
explicitly and arrange two solutions with consistence of written style.

> Best,
>
> Thomas
>
>  2011/12/10 Thomas C. Schmidt <[email-masked]**hamburg.de<[email-masked]>
>> <mailto:schmidt@informatik.**haw-hamburg.de<[email-masked]>>>
>>
>>
>>
>>    Hitoshi,
>>
>>
>>    ° http://www.informatik.haw-__**hamburg.de/~schmidt<http://www.informatik.haw-__hamburg.de/~schmidt>
>>    <http://www.informatik.haw-**hamburg.de/~schmidt<http://www.informatik.haw-hamburg.de/~schmidt>>
>>    Fax:
>>    +49-40-42875-8409 °
>>
>>    ______________________________**___________________
>>    multimob mailing list
>>    https://www.ietf.org/mailman/_**_listinfo/multimob<https://www.ietf.org/mailman/__listinfo/multimob>
>>    <https://www.ietf.org/mailman/**listinfo/multimob<https://www.ietf.org/mailman/listinfo/multimob>>
>>
>>
>>
>>
>>
>>

---

From: "Shuai Gao" <[email-masked]>
Date: Mon, 12 Dec 2011 17:28:36 +0800

Hi Hitoshi,

Please see my comments inline.	

======= 2011-12-12 16:00:45 您在来信中写道：=======

>prefix of source prefix (i.e. into MRIB). This is what I'm saying.

So your solution is adding special policy-based multicast routing at the MAG?  It looks ok, but may be
complex. You should clarify this and call for more discussions on its feasibility. 

　　　　　　　　致
礼！

Shuai Gao

---

From: Hitoshi Asaeda <[email-masked]>
Date: Mon, 12 Dec 2011 18:36:01 +0900 (JST)

> complex. You should clarify this and call for more discussions on

Well, I don't know this is "special policy-based" routing.
Because separating RIB and MRIB is very common.
One possible complexity is that we need to provide an upstream router
selection mechanism for the case that multiple LMAs having different
M-Tunnels could become an upstream router for the same prefix.
It is not mentioned in -07 but it will be addressed in the revised
draft.

Regards,
--
Hitoshi Asaeda

---

From: Stig Venaas <[email-masked]>
Date: Mon, 12 Dec 2011 12:24:26 -0800

Regarding PMIP routing and PIM and MRIB etc. It seems to me that there
is pretty much agreement on how this works. I still would like to say
how I believe it works and what could be done.

For PIM (and most multicast routing in general) RPF is essential and
that is achieved using a routing table (MRIB). This MRIB is in many
cases identical to the unicast RIB, but it need not be.

Now since PMIP uses policy routing (you cannot tell where a packet
should be forwarded just by its destination address), you cannot align
PIM with PMIP using a single RIB.

However, there are implementations that support multiple RIBs. That
is multiple VRFs, see e.g. RFC 4364 section 3. In that case, each
interface on a router would belong to a VRF (a default VRF if
nothing in particular is configured), or some specific other VRF.

I won't say for sure, but I think it should be possible to match
PMIP routing and PIM on the MAG by having one VRF per LMA, where
the MAG-LMA tunnel and each MAG-MN links (for the MNs belonging
to that LMA). You might compare this to our base approach with
multiple proxy instances. I think the per LMA VRF table would
basically have a default route pointing to the MAG-LMA tunnel,
and then a directly connected route per MAG-MN link.

Does that look correct? Anyone see any issues with that?

Stig

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Tue, 13 Dec 2011 02:38:22 +0100

Hi Stig,

> PIM with PMIP using a single RIB.

Bonne - well said.

> nothing in particular is configured), or some specific other VRF.

Oho ... this is really strong stuff. Let me try to rephrase to make sure 
I get you right:

  1. You are considering plain unicast routing here.

  2. You use the property of PtP-Links in PMIP: Because there is only a 
single IP address behind a downstream interface of a MAG, you regard 
this interface as a proxy of the MN / MN's IP address.

  3. Considering a MAG as a Provider Edge (PE) router with downstream 
links as "Pseudo-VPN" endpoints, you adopt the option of RFC 4364 to 
assign a VPN Routing and Forwarding tables to each downstream, thereby 
turning the common filter(policy)-based routing into an interface-based 
VRF ... which indeed brings us back into the context of ordinary routing 
tables.

  4. As a result, you have a unicast router with per-interface RIBs.
     Then the forwarding at a MAG looks as follows:

      For data sent from an MN, the VRF at its connecting interface is 
used which essentially has a default route to the corresponding MAG-LMA 
tunnel.

      For data sent to an MN, no special routing tables are actually 
required, as a default table actually should know all the downstream 
routes to the MNs. However, you could add a dedicated VRF at the LMA-MAG 
tunnel that only contains those downstream routes for MNs belonging to 
the LMA. This is redundant, but should not do harm.

   All together you end up with a VRF that corresponds to something like 
a proxy instance in the base solution ...

This is unicast - but for multicast, the bigger question would be: Can 
PIM-SM work with a collection of interface-bound RIBs? This would mean 
that (*,G)/(S,G) tree states could overlap at a single router (that has 
to maintain multiple trees for the same group but different interfaces 
...) How could this be handled by PIM??

I would at least deduce, that PIM would loose its tree optimization 
properties and duplicate data would arrive ... just as in the base 
solution - do you agree or am I ignoring something?

Cheers,

Thomas

--

---

From: Stig Venaas <[email-masked]>
Date: Tue, 13 Dec 2011 09:43:07 -0800

Please see inline

> 1. You are considering plain unicast routing here.

Basically this applies to VPNs, both unicast and multicast.

> VRF ... which indeed brings us back into the context of ordinary routing

Talking about VPNs in general, each interface belongs to a VRF. And I
believe each MN link also would belong to a VRF when making use of this.

> For data sent from an MN, the VRF at its connecting interface is used
> which essentially has a default route to the corresponding MAG-LMA tunnel.
>
> For data sent to an MN, no special routing tables are actually required,
> as a default table actually should know all the downstream routes to the
> MNs. However, you could add a dedicated VRF at the LMA-MAG tunnel that
> only contains those downstream routes for MNs belonging to the LMA. This
> is redundant, but should not do harm.
>
> All together you end up with a VRF that corresponds to something like a
> proxy instance in the base solution ...
>
>

The PIM state is also per VRF. So if you get (S,G)-joins on two
different interfaces, belonging to two different VRFs, you will have
two (S,G) entries, even if the S and G addresses are the same. Also
the RPF interfaces for the two (S,G)s will be different.

> solution - do you agree or am I ignoring something?

Yes, it becomes exactly like the base solution.

You just cannot have it two ways though. I mean, either you want
multicast to be according to the PMIP routing, or you choose
multicast to be something else. If you want for a given (S,G) to
have a single tree (independent of which MNs join), then I think
a single MRIB would be fine.

Stig

---

From: Hitoshi Asaeda <[email-masked]>
Date: Wed, 14 Dec 2011 14:52:30 +0900 (JST)

Hi Stig,

> how I believe it works and what could be done.

Right.

> cases identical to the unicast RIB, but it need not be.

Exactly.

> PIM with PMIP using a single RIB.

It seems that people have been confused.
As I said many times, it is *not necessary* to incorporate PMIP's
unicast policy route into MAG's RIB, in my proposal.

> Does that look correct? Anyone see any issues with that?

I think your proposal is also interesting in some condition. But
multiple RIBs are not always required.
I don't start discussing what kind of situation multiple RIBs are
needed with PIM, because it gives another confusion. But if we do RPF
solely based on the source address (or RP address) rather than which
MN it is, then a single RIB (and a sigle MRIB) should work.

PIM on MAG only needs to resolve upstream interfaces when it receives
MLD join from MNs. In other words, PMIP unicast policy route is not
needed for RPF check.
MAG has its RIB. This RIB does not have any entry for MNs' prefixes.
It's Ok. It doesn't affect anything for forwarding multicast packets
received at MAG, because MNs are directly attached to MAG with P2P
link and they can send MLD joins to the MAG directly. And MAG
recognizes the receivers (and OIFs) and forwards packets to the MAG's
OIFs.

Again, if PIM on MAG can resolve RPF, it can just send PIM join toward
source or RP and forward packets to directly attached MNs who have
requested join.

Do you agree, Stig?

Regards,
--
Hitoshi Asaeda

---

From: <[email-masked]>
Date: Thu, 15 Dec 2011 14:32:31 +0100

Dear all,
AFAIU the draft does provide a base solution to tunnel convergence problem in multimob and I agree to forward the merged document as WG document.

Some comments for discussion (though not sure whether already posed on the list):

It surely should be obvious that different MNs at same MAG may be connected to different LMAs or MTMAs but since it cannot be shown in Figs. 2 and 3 perhaps it should be mentioned explicitly - due to mobility it will happen anyway and later on in Fig. 4 it is included.

Introduction of hybrid H-LMA is only applied to N:1 scenario. Do you exclude the 1:N case because here the scenario with several H-LMAs doesn't differ much from the base protocol with combined unicast/multicast LMAs (and thus does not solve the tunnel convergence problem)? Perhaps this could be elaborated a bit.

In sect. 3 in Figs. 5/6 PBU/PBA exchange is the first reaction of MAG on MN attachment which seems to be reasonable, whereas in section 4 the flow chart Fig. 10 proposes to do PBU/PBA after MLD query. Shouldn't this be changed since otherways also the dynamic decision of MAG on local or remote routing based on 'PBU/PBA signaling (which) can be used to carry the profile information ...' as mentioned in 5.1 cannot be applied?

Furthermore I am not sure whether in 4.2.2 for MAG as MR the expression 'as described in chapter 3' would fit since ch.3 describes the PMIP-based MAG-MTMA operation and does not cover multicast routing (but perhaps that touches the routing table discussion I did not understand completely).

Finally I wonder whether due to possible dynamic configuration of MAG as MR according to PIM not additional security concerns are introduced so that in ch. 6. also PIM RFCs should be included?

Thanks and best regards

Dirk

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Behcet Sarikaya
Gesendet: Donnerstag, 8. Dezember 2011 21:53
An: [email-masked]
Betreff: [multimob] WG adoption call on draft-zuniga-multimob-pmipv6-ropt

Hello all,

Chairs

---

From: Stig Venaas <[email-masked]>
Date: Wed, 21 Dec 2011 11:21:50 -0800

> MN it is, then a single RIB (and a sigle MRIB) should work.

Yes. If we don't attempt to have multicast routing correspond to PMIP
routing (such as routing based on MN and not just source), then a
single RIB might be sufficient. If the routing is solely on the source
address, then a single RIB is fine.

An interesting topic might be what kind of policies do we think are
useful and how to get the RIB populated to achieve this.

Is it OK to solely use the source address?

> MLD join from MNs. In other words, PMIP unicast policy route is not

If RPF is just based on the source address, then a single RIB is fine.

> source or RP and forward packets to directly attached MNs who have

Agree. Except, if the MNs are sources, then you may need RIB entries for
the MNs prefixes to allow for directed connected check (see email I just
sent in response to Aaron's question).

Stig

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Wed, 21 Dec 2011 22:17:37 +0100

Hi Stig,

please see inline ...

> Is it OK to solely use the source address?

If we do so, then we are in the case of plain "direct routing" as 
basically supported by Seil. Direct routing can of course be built on 
some uplink tunnel as pointed out in RFC 6224 - however, this solution 
is disjoint from any support by 'home services' as is the typical PMIP 
picture.

So I believe, you rose the right point when asking about policies: There 
are two common policies in mobility (in particular in PMIP):  (i) home 
network support, and (ii) visited network support.

(ii) is direct routing and easy to achieve with PIM.
(i) basically corresponds to PMIP routing and does not go well with PIM 
(as previously discussed).

IMO it is quite hard to think of any reasonable policy that is somehow 
mixed.

> If RPF is just based on the source address, then a single RIB is fine.

However, if RPF is bound to the source address, then upstream signaling 
for MLD join must comply to the unique route that is used for RPF-check 
in the downstream. Thus PMIP unicast policy route cannot be used on the 
upstream signaling.

> sent in response to Aaron's question).

Yes, mobile sources is sort of the other side of the coin ;)

Cheers,

Thomas
--

---

From: Hitoshi Asaeda <[email-masked]>
Date: Thu, 22 Dec 2011 15:07:09 +0900 (JST)

Hi Stig,

> Is it OK to solely use the source address?

Not only source address, but also source prefix(es).
When MAG won't use unicast routes (i.e. RIB) for RPF check for outside
sources (or outside source prefixes), it uses M-tunnel set up between
LMA and MAG, and incorporates the multicast routes with the M-tunnel
for the sources (or source prefixes) into its MRIB.

> If RPF is just based on the source address, then a single RIB is fine.

Source prefix, too.

> sent in response to Aaron's question).

Whether the link is a physical or logicai is not the matter. It's an
implementation issue.
MAG just recognizes the *directly attached* MNs.
Only the problem for source mobility is "detour", because MNs'
prefixes are advertised from LMA.
It would be possible to provide some optimized way to address
"detour", but it does not mean "a single RIB does not work for source
mobility in PIM".

Regards,
--
Hitoshi Asaeda

---

From: <[email-masked]>
Date: Thu, 22 Dec 2011 14:58:14 +0100

Hi,

> network support, and (ii) visited network support.

I can understand what is home network vs. visited network with MIP, but
not with PMIP. The basic of PMIP is that the MN is roaming across its
home network across the whole PMIP domain. Each MAG emulates the home
network for the MN which remains unaware of the mobility, in other
words, the MN plays with only one prefix: the Home network prefix; while
a MIP client has to deal with two IP: the home address and the
care-of-address. With PMIP, there is no distinction between visited and
home network, we could say that PMIP brings a moving home network
support...

Pierrick

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Thu, 22 Dec 2011 15:58:26 +0100

Hi Pierrick,

no reason for confusion, the picture is simple.

First of all, the statement was a general one, but translated to PMIP it 
distinguishes the cases (i) "data flow via the LMA" and (ii) "local data 
flow at the MAG". From the policy perspective, this is independent of 
the IP prefix the MN sees.

In the case of a single-operator PMIP domain, you may simple think about 
(ii) as a route optimization. However, if PMIP is operated across 
operators, then data services (in particular multicast) may differ and 
the provisioning really follows a (different) provider policy.

The distinction of these two cases has of course strong implications in 
routing. If we want to provide (i) - like the base solution does - then 
we need to follow the association of MN <-> LMA, i.e., perform PMIP 
routing.
On the contrary, if mcast data is brought (somehow) directly to the MAG, 
i.e. independent of the MNs that subscribe, then we can use regular IP 
routing, either shortest path or by some manually provisioned routing 
table.

The question I extracted from Stigs writing was: "Is there any other 
reasonable policy that can be implemented in a single RIB ?" ... and 
this appears as a good, challenging question to me.

Do you have any idea on this?

Best wishes,

Thomas

--

---

From: <[email-masked]>
Date: Fri, 23 Dec 2011 23:39:47 +0100

Hi,

> -----Message d'origine-----
> De : Thomas C. Schmidt [mailto:[email-masked]]
> Envoyé : jeudi 22 décembre 2011 15:58
> À : SEITE Pierrick RD-RESA-REN
> Cc : [email-masked]; [email-masked]
> Objet : Re: [multimob] WG adoption call on draft-zuniga-multimob-
> pmipv6-ropt
> 
> Hi Pierrick,
> 
> flow at the MAG". 

Ok, I see. I agree this is a valid use-case. Actually, this is the scenario we're addressing in draft-asade-multimob-pmip6-extension-07

>From the policy perspective, this is independent of

> routing, either shortest path or by some manually provisioned routing

Again, I think we agree on the scenario and my understanding is that PIM capable MAG could meet this requirement.

> Do you have any idea on this?

I didn't read all messages regarding this topic and I may miss the point but, according to discussions and Stig's message, it seems that PIM can be used on the MAG. If I remember well, the question was to know if a RIB can be used on the MAG. Actually, MAG is a mobility function usually implemented on a router, so with a RIB. Regarding our use-case the MAG has two upstream interfaces (i.e. the tunnel to the LMA and the regular interface) that can be used to send PIM messages. Then, depending on the source to reach, PIM messages can be sent either via the LMA or "locally". I'm not a multicast expert, but I guess, this is a current behavior for a multiple interfaces PIM router.  

Best regards,
Pierrick

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Sat, 24 Dec 2011 00:10:43 +0100

Hi Pierrick,

> Ok, I see. I agree this is a valid use-case. Actually, this is the scenario we're addressing in draft-asade-multimob-pmip6-extension-07

You speak about use-case (ii)? In the current versions of the draft, 
mcast signaling is explained to follow MN <-> LMA binding (see for 
example "Figure 2: MLD Report Messages Transmission") and this is 
use-case (i).

>> we need to follow the association of MN<->  LMA, i.e., perform PMIP
>> routing.

Yes, this is fine - but this is the solution Seil is proposing.

> I didn't read all messages regarding this topic and I may miss the point but, according to discussions and Stig's message, it seems that PIM can be used on the MAG.

Yes, of course it can.

> If I remember well, the question was to know if a RIB can be used on the MAG. Actually, MAG is a mobility function usually implemented on a router, so with a RIB.

Yes, it's regular RIB is for the management.

> Regarding our use-case the MAG has two upstream interfaces (i.e. the tunnel to the LMA and the regular interface) that can be used to send PIM messages.

Normally, the MAG has many potential upstream interfaces, one for each 
LMA (the tunnels), and possibly one or several local interfaces for 
management and intra-provider purposes.

> Then, depending on the source to reach, PIM messages can be sent either via the LMA or "locally". I'm not a multicast expert, but I guess, this is a current behavior for a multiple interfaces PIM router.

Sources here are remote multicast senders or Rendezvous Points. For each 
of these "multicast originators"  a unique route in the RIB is required. 
This could be an LMA-tunnel interface, meaning that all multicast 
traffic from that source flows via this particular LMA for all MNs 
(including those *not* associated with this particular LMA). This could 
also be a local route ... and this is the local routing option (case (ii)).

Using a particular LMA for upstream (independent of the MN) is in the 
area of "mixed use-cases", and I guess that's what Stig asked about.

Why should a particular LMA (possibly from a different provider) serve 
MNs that are in no relation to it?

What is a reasonable rule to select LMAs according to multicast originators?

What happens, if unicast handover management actually terminates the 
tunnel-relationship to this LMA, while other (unrelated) mobile 
receivers persist?

Those questions seem difficult to answer to me ... and that's the 
background for asking about reasonable ideas or concepts of "mixed 
policies" ... currently, I don't see any.

Best wishes,

Thomas

--

---

From: <[email-masked]>
Date: Sat, 24 Dec 2011 17:27:27 +0100

Hi Thomas,

Good, it seems that we are all in agreement now: PIM on MAG works. 

So, I'd suggest to document that behavior, then we could address related issues like policy provisioning, interaction with unicast mobility management, and so on. Just a suggestion to move forward... step by step.  

Regarding documents we have on the table, I was referring to Hitoshi's draft because it was the first to tackle the issue and I didn't read more recent proposals, so maybe you're right: Seil's draft is going in the same direction. Anyway, it's good... we have enough materials to move forward.

Best regards and happy Cristmas.
Pierrick

> Envoyé : samedi 24 décembre 2011 00:11
> Cc : [email-masked]
> >> First of all, the statement was a general one, but translated to
> PMIP
> >> it
> >> flow at the MAG's ".
> > Ok, I see. I agree this is a valid use-case. Actually, this is the
> scenario we're addressing in draft-asade-multimob-pmip6-extension-07
> 
> > Again, I think we agree on the scenario and my understanding is that
> PIM capable MAG could meet this requirement.
> >
> 
> > I didn't read all messages regarding this topic and I may miss the
> point but, according to discussions and Stig's message, it seems that
> PIM can be used on the MAG.
> 
> Yes, of course it can.
> 
> > If I remember well, the question was to know if a RIB can be used on
> the MAG. Actually, MAG is a mobility function usually implemented on a
> router, so with a RIB.
> 
> > Regarding our use-case the MAG has two upstream interfaces (i.e. the
> tunnel to the LMA and the regular interface) that can be used to send
> PIM messages.
> 
> > Then, depending on the source to reach, PIM messages can be sent
> either via the LMA or "locally". I'm not a multicast expert, but I
> guess, this is a current behavior for a multiple interfaces PIM router.
> 
> >> ° Hamburg University of Applied Sciences                   Berliner
> Tor
> >> 7 °
> >> ° http://www.haw-hamburg.de/inet                   Fon: +49-40-
> 42875-
> >> 8452 °
> >> ° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-
> 42875-
> >> 8409 °

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Mon, 26 Dec 2011 23:07:39 +0100

Hi all,

Some comments below (on last Thomas' mail) thinking on PIM solution on MAG, and focusing on  draft-zuniga-multimob-pmipv6-ropt.
----------------------------------------

Using a particular LMA for upstream (independent of the MN) is in the area of "mixed use-cases", and I guess that's what Stig asked about.

[Luis>>] This is the role played by either the MTMA or the H-LMA in draft-zuniga-multimob-pmipv6-ropt

Why should a particular LMA (possibly from a different provider) serve MNs that are in no relation to it?

[Luis>>] If there is a certain common content (created by a certain content originator, and distributed by using the same IP destination address) subscribed by different MNs associated with distinct LMAs, it makes sense to distribute only once for all those MNs independently of the LMA which they are associated to, instead of doing it in parallel multiple times. Such unique distribution should use an entity common to all of them, the so called MTMA (or the H-LMA).

[Luis>>] If the multicast originators (I guess you mean multicast sources) are homed in different networks, we could think in an scenario where different MTMAs (or H-LMAs) exists, one per multicast source home, in such a way that the MNs demanding to be served by a certain multicast source are pointed towards the tunnel connecting to the corresponding MTMA (e.g., by the use of static multicast route configuration).

What happens, if unicast handover management actually terminates the tunnel-relationship to this LMA, while other (unrelated) mobile receivers persist?

[Luis>>] The MTMA tunnel is set up / tear down for multicast traffic. However, the case you mention is applicable to the H-LMA case. Due that the tunnel is used for both unicast and multicast, the tunnel lifetime should be conditioned by the existence of unicast and multicast users, so this issue has to be considered definitely.

Those questions seem difficult to answer to me ... and that's the background for asking about reasonable ideas or concepts of "mixed policies" ... currently, I don't see any.

[Luis>>] I hope this could be considered a reasonable input for you.
Thanks, best regards,

Luis

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: Tue, 27 Dec 2011 12:11:38 +0100

Hello Luis,

> Some comments below (on last Thomas' mail) thinking on PIM solution on MAG, and focusing on  draft-zuniga-multimob-pmipv6-ropt.

I'm not sure about this, it rather seems that the term "*-LMA" is 
confusing here (as discussed earlier). The LMA is a PMIP unicast entity 
that provides home agent services (including handover management) for 
its associated MNs. Your solution is a tunnel-endpoint that serves 
multicast streams, sometimes referred to as "head-end".

Just to be clear: I'm not objecting the solution, but just question the 
name for the tunnel endpoint.

> [Luis>>] If there is a certain common content (created by a certain content originator, and distributed by using the same IP destination address) subscribed by different MNs associated with distinc…

The previous discussion was referring to the business model: If the 
multicast head-end were an LMA for some MN from provider X, it would be 
indeed questionable why this LMA should serve other MNs from provider Y 
that have no association with it. However, since I understand your 
head-end not to act as an LMA, this argument does not apply. The 
head-end could be provided by someone (a local operator, some dedicated 
multicast service provider, ...) independent of the home association of 
MNs.

Anyhow, I guess Behcet is right: in the previous discussion, we have 
been mixing considerations of two drafts by accident. The majority of 
the exchanged arguments do not apply to 
draft-zuniga-multimob-pmipv6-ropt (except for avoiding the pitfalls in 
deploying PIM as mentioned above).

So we should keep things separate.

Best wishes,

Thomas

--