Subject: [netext] Alternate Tunnel Source Address for LMA and Home Agent

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 11 May 2012 14:40:13 -0700

Hello folks,

I have submitted draft-perkins-netext-hatunaddr-00.txt.  I hope that 
there will be interest in the [netext] working group for this proposal.

-- 
Regards,
Charlie P.

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 11 May 2012 16:00:57 -0700

Hi Charlie,

Thanks for sharing the document. Currently, we do have the support for the following:

- Alternate Care-of Address mobility option for a mobile node to register IPv6 reachability address for the data path termination
- We have the Alternate IPv4 Care-of Address mobility option for a mobile node to register a IPv4 reachability address for the data path termination

This essentially, allows the MAG to achieve register different IP addresses for control and data plane termination.  However, the gaps exists on the LMA, there are no semantics to deliver a different data path address. So, your proposal fixes this gap and that's great.  But, I've some comments.

1. Its unclear if the option can be used for both IPv4 and IPv6 tunnel end point registration. To be consistent with Alternate (IPv6) Care-of address and  Alternate IPv4 Care-of Address options, its better to define one more option. You may want to define a new option

2. The spec is not clear on how this option is used with Binding Revocation and other messages. You may want to add some clarifications on the usage

3. Please add a reference to RFC-6463 on the Alt IPv4 Care-of address option

4. The draft is bit ambitious :), it seems to be extending Mobile IPv4 as well. I'm not sure, if we ever mixed Mobile IPv4 and Mobile IPv6/PMIPv6 extensions in a single spec

5. Finally, it will be very useful, if we can have some thing in Appendix, that shows how MAG and LMA can use different IP address end points for control and data plane traffic.

Thanks for writing this up and finally posting it in MEXT.  Long back there used to be a guy, Vijay D., he wanted to write this up for long time :)

Regards
Sri

On May 11, 2012, at 2:40 PM, Charles E. Perkins wrote:

> 
> Hello folks,
> 
> I have submitted draft-perkins-netext-hatunaddr-00.txt.  I hope that there will be interest in the [netext] working group for this proposal.
> 
> -- 
> Regards,
> Charlie P.
> 
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 15 May 2012 13:17:08 -0500

Hi Charlie,

I think that this draft belongs to dmm WG. I don't understand what is
the relevance of your content with Netext which deals with PMIPv6.

Regards,

Behcet

On Fri, May 11, 2012 at 4:40 PM, Charles E. Perkins
<[email-masked]> wrote:
>
> Hello folks,
>
> I have submitted draft-perkins-netext-hatunaddr-00.txt.  I hope that there
> will be interest in the [netext] working group for this proposal.
>
> --
> Regards,
> Charlie P.
>

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 17 May 2012 17:00:43 -0700

Behcet: 

This is related to the Alternate CoA option that we have for the MAG; the same option for LMA. What Charlie is proposing is a PMIPv6 protocol option for allowing the LMA to register a different IP address for the tunnel end-point, different from the destination IP address in the PBU. It is a mobility option over PMIPv6 control plane with LMA/MAG operational specification.  The WG is already pathetically slow (we all can take the blame) in defining new extensions, we bake the specs for years, now if we argue about these minor extensions, it does not help the guys who are bringing contributions.

Sri

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 17 May 2012 20:59:57 -0700

> 1. Its unclear if the option can be used for both IPv4 and IPv6 tunnel end point registration. To be consistent with Alternate (IPv6) Care-of address and  Alternate IPv4 Care-of Address options, it…

Do you mean that the LMA might instruct the IPv6 mobile node to tunnel 
data to an IPv4 address?
Yes, I think this would require another option.  I'll include this feature.

> 2. The spec is not clear on how this option is used with Binding Revocation and other messages. You may want to add some clarifications on the usage

Well, I would expect that if the binding is revoked, then the data plane 
tunnel is no longer useful either.
In this case, the option would not be useful with the Binding Revocation 
message.

If, on the other hand, the Binding Revocation message were issued to the 
MN including the
Alternate Tunnel Source Address option, it could be interpreted as 
instruction for the mobile
node to refer to using the LMA address as the IP address of home agent 
data plane tunnel
endpoint.  I'm not sure anyone would want that, and it's not a 
completely natural interpretation.
But it's within the realm of imagination.  What do you suggest?

If the document is accepted as a working group document, I'll provide 
more detailed
descriptions about other possible messages from the LMA (or Home Agent).

> 3. Please add a reference to RFC-6463 on the Alt IPv4 Care-of address option

Check.  I can also include text about it from your email.

> 4. The draft is bit ambitious :), it seems to be extending Mobile IPv4 as well. I'm not sure, if we ever mixed Mobile IPv4 and Mobile IPv6/PMIPv6 extensions in a single spec

I think there is a precedent for this -- at least I know I've written up 
such documents before.
But I'm open to suggestion about it.

> 5. Finally, it will be very useful, if we can have some thing in Appendix, that shows how MAG and LMA can use different IP address end points for control and data plane traffic.

Do you mean a flow diagram?   Is it really unclear enough to need ASCII art?
O.K.,  I'll do it if the working group adopts the document.

Regards,
Charlie P.

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 17 May 2012 21:50:36 -0700

Charlie:

On May 17, 2012, at 8:59 PM, Charles E. Perkins wrote:

> Do you mean that the LMA might instruct the IPv6 mobile node to tunnel data to an IPv4 address?

Since,  we do support both IPv4 [RFC5844] and IPv6 transport [RFC5213] for PMIPv6, we need both the variants of Alt-Tunnel-Source option

> Well, I would expect that if the binding is revoked, then the data plane tunnel is no longer useful either.
> In this case, the option would not be useful with the Binding Revocation message.
> 

I intended to say, we need more text on where the option is relevant and where its not relevant. I agree, its not relevant for BRI/BRA.

> If, on the other hand, the Binding Revocation message were issued to the MN including the
> Alternate Tunnel Source Address option, it could be interpreted as instruction for the mobile
> node to refer to using the LMA address as the IP address of home agent data plane tunnel
> endpoint.  I'm not sure anyone would want that, and it's not a completely natural interpretation.
> If the document is accepted as a working group document, I'll provide more detailed

Ok

> I think there is a precedent for this -- at least I know I've written up such documents before.

IMO, we should just keep this to MIPv6/PMIPv6.  If its needed for MIPv4, its worth publishing a new document

> O.K.,  I'll do it if the working group adopts the document.

Once this gap is fixed, per this spec, we can enable MAG and LMA both negotiate a different end points. Earlier, with Alt-CoA we just allowed the MAG to do that. 

Sri

---

From: jouni korhonen <[email-masked]>
Date: Fri, 18 May 2012 08:34:58 +0300

Charlie,

It was not entirely clear to me how this option would be different
from RFC6463 and its Redirect Mobility Option, which also allows
you to move bind LMA to a different address than the PBU was originally
sent to? How would these two co-exists?

- Jouni

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 18 May 2012 09:55:26 -0500

> sent to? How would these two co-exists?

Absolutely.

This was what I intended to write in reply to Sri and noticed that
Jouni already wrote it.

This option may look OK syntactically in PMIP but we can not find any
useful semantics other that redirect.

Folks, please wake up and realize that PMIPv6 NOT = MIPv6.

Having another entity called MN makes huge difference.

Behcet

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 18 May 2012 08:55:56 -0700

This is a good comment and this discussion is needed. The difference I see is the following:

In RFC 6463, both in the collocated and non-collocated model, the LMA is able to provide the Redirect Mobility option, with a different IP address so the MAG can establish tunnel to that target IP address. Sure, the tunnel end point is now moved, but so did the control end point. The subsequent PBU is also required to be sent to the same target IP address. So, in affect we have relocated the session (both control and use plane) to that target IP address. We are never truly allowed the scenario where the PBU/PBA can always be sent to a different IP than the tunnel end point. 

I'm sure, we could have fixed that option to be bit more generic and addressed this issue. Either way, we need to make sure both the options coexist properly.

    [MAG]   [rfLMA]  [r2LMA]
      |        |        |
   1) |--PBU-->|        | LMA assignment takes place in rfLMA.
      |        |        |
   2) |        | ~ ~ ~ >|\
      |        |        | + BCE gets created in r2LMA.
   3) |        |<~ ~ ~ ~|/
      |        |        |
   4) |<--PBA--|        | PBA contains r2LMA information.
      |        |        |
      |<=====data======>|
      |        |        |
   5) |-------PBU------>| Lifetime extension,
   6) |<------PBA-------| de-registration, etc.
      |        |        |

Regards
Sri

---

From: Jouni <[email-masked]>
Date: Sat, 19 May 2012 11:59:22 +0300

Sri,

On May 18, 2012, at 6:55 PM, Sri Gundavelli wrote:

> In RFC 6463, both in the collocated and non-collocated model, the LMA is able to provide the Redirect Mobility option, with a different IP address so the MAG can establish tunnel to that target IP address. Sure, the tunnel end point is now moved, but so did the control end point. The subsequent PBU is also required to be sent to the same 

Sure, because this is the model PMIP was designed for.. AltTSA is a
bigger architectural change to whole PMIP IMHO, not just another
mobility option.

> target IP address. So, in affect we have relocated the session (both control and use plane) to that target IP address. We are never truly allowed the scenario where the PBU/PBA can always be sent to a different IP than the tunnel end point. 

Honestly, if we want GTP, lets go for GTP ;)

Another big question I have is whether AltTSA allows for changing the
tunnel  endpoint for an already established mobility session? Keeping
in mind that this particular feature was a big no-no when RFC6463 was
done and therefore not particularly endorsed by RFC6463. I would love
to errata/bis RFC6463 for midsession changes of LMA address.. 

> I'm sure, we could have fixed that option to be bit more generic and addressed this issue. Either way, we need to

Yes, that could have been "easy" to add to RFC6463 if we would have
decided at that time having combined CP+AP is not the way forward.

>  make sure both the options coexist properly.

Or alternatively bis RFC6463 to relax some language it has now..?

- Jouni

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 21 May 2012 19:05:11 -0700

Hi Jouni:

The approach of registering different transport end points is a semantic that is already present in the (Proxy) Mobile IPv6 architectures. You allow the MAG to register those different transport end points, or you allow the LMA to do the same is not radically different. If this semantic is present in Protocol - X, or Protocol - Y is orthogonal to the core point. To me 3GPP is one access technology, while it is a dominant access architecture, but what we are enabling in this working group or the work applicability statement does not mandate 3GPP as the target access. I cannot take some Protocol-X and deploy it in an access architecture that has nothing to do with 3GPP.

To the technical comment on the co-existence of the option with 6463 Redirect option, its just a relay mode, if the rfLMA receives from the r2LMA is the AltTSA is what can be passed down to the MAG. But, from this discussion, it is clear we need to think bit more about the option coexistence. 

> Or alternatively bis RFC6463 to relax some language it has now..?

We can certainly leverage the Redirect option and extend this for this use-case, but that is more about the semantics related to option definition. We still need this text on the use-case.

Regards
Sri

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 22 May 2012 10:27:06 -0500

> Honestly, if we want GTP, lets go for GTP ;)

I guess Sri is talking about MME+ SGW + PGW for PMIP.
I agree with Jouni and say to Sri that you are dreaming :-).

Behcet

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 22 May 2012 15:52:25 -0700

Hello Jouni et al.,

On 5/19/2012 1:59 AM, Jouni wrote:
>                  ...............                   AltTSA is a

The point of AltTSA is to enable split control and data plane.  Judging 
from modern
mobility management infrastructures, that is a good thing.   I'm hoping 
that the
working group would be willing to agree -- or if not, perhaps explain 
why keeping
the control plane and data plane together is still the right approach 
going forward.

> Honestly, if we want GTP, lets go for GTP ;)

I am happy to resubmit my draft to do that.  I think it is a very good idea.

> to errata/bis RFC6463 for midsession changes of LMA address..

This is easy to do, but from the perspective of separation of control 
and data
plane looks more like a failover scheme rather than the basic requirement.
Even so, I'd be happy to see it supported as part of AltTSA.

-- 
Regards,
Charlie P.

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 22 May 2012 16:36:29 -0700

> I agree with Jouni and say to Sri that you are dreaming :-).

:) Right. One of us is smoking some bad stuff, and I just realized I don't smoke :)

Sri

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 22 May 2012 17:42:40 -0700

Hello Behcet,

On 5/22/2012 8:27 AM, Behcet Sarikaya wrote:
> On Sat, May 19, 2012 at 3:59 AM, Jouni<[email-masked]>  wrote:
>>

I didn't arrive at that conclusion from Sri's email.  And, as I've 
mentioned, anyway I think it would be wise to enable GTP as a choice for 
encapsulation between HA and CoA [e.g., LMA and MAG].

But MME and SGW and PGW are LTE functional entities; nevertheless PMIP 
is already specified for SGW and PGW.  It turns out that one can nearly 
do MME for PMIP also if you are willing to split control and data plane.

I have shown architectural diagrams that exhibit the "special case" that 
you identify under certain restrictive assumptions and additional 
(orthogonal) LTE-required reference points.

I don't think it's irrational to try to identify the gaps between 
IETF-based mobility management and 3GPP-based mobility management.

-- 
Regards,
Charlie P.