Subject: [netlmm] FW: I-D Action:draft-muhanna-netlmm-grekey-option-04.txt

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 8 Jul 2008 11:07:21 -0500

Hello All,

Please find the latest revision of the GRE Key Option draft. 
All the issues that was brought during the ml discussion has been
addressed.
Please take a look and let us know if you have any comment or concern.

Thanks for your review and comments!

Regards,
Ahmad

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, July 08, 2008 11:00 AM
To: [email-masked]
Subject: I-D Action:draft-muhanna-netlmm-grekey-option-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : GRE Key Option for Proxy Mobile IPv6
	Author(s)       : A. Muhanna, et al.
	Filename        : draft-muhanna-netlmm-grekey-option-04.txt
	Pages           : 14
	Date            : 2008-07-08

The Proxy Mobile IPv6 base specification and Proxy Mobile IPv6 support
for IPv4 allow the mobile node's IPv4 and IPv6 traffic between the local
mobility anchor and the mobile access gateway to be tunneled using IPv6
or IPv4 encapsulation headers.  These encapsulation modes do not offer
the tunnel end-points the required semantics to expose a service
identifier that can be used to identify traffic for a certain
classification, such as for supporting mobile nodes that are using
overlapping private IPv4 addressing.  The extension defined in this
document allow the mobile access gateway and the local mobility anchor
to negotiate GRE encapsulation mode and exchange the GRE keys for
marking the flows, so that differential processing can be applied by the
tunnel peers over those flows.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-muhanna-netlmm-grekey-option-0
4.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 8 Jul 2008 13:56:08 -0400

Hi Ahmad,

I quickly glanced through the document. 

In version 02 of the document, there was an option for the LMA to reject
GRE encapsulation if the LMA determines that it is not required. 

   o  Upon receiving a Proxy Binding Update message with the GRE Key
      Identifier Option, the local mobility anchor, if it determines
      that overlapping private IPv4 addressing is not in use, MUST send
      the Proxy Binding Acknowledgement message to the mobile access
      gateway with the status code success without including the GRE Key
      Identifier option.

This seems to have been removed in version 04. why? In version 04, there
seems to be no option for the LMA to indicate that GRE encapsulation is
not required for a particular PMIPv6 session.

In version 04, you have introduced the following.

   o  If the received Proxy Binding Update message does not contain the
      GRE Encapsulation Option, and if the local mobility anchor
      determines that GRE encapsulation is required, e.g., overlapping
      IPv4 private addressing is in use, LMA local policy, the local
      mobility anchor MUST reject the request, and MUST send the Proxy
      Binding Acknowledgement message to the mobile access gateway with
      the status code TBA2, indicating that GRE encapsulation is
      required.

What if the MAG does not support GRE encapsulation? What does the MAG
do? Is this an error condition? There must be a way for the MAG to force
the LMA to proceed without GRE encapsulation. There is nothing about
this in the MAG Considerations section.

In section 5.2, you have

   o  Upon the successful process of a Proxy Binding Update message with
      the GRE Encapsulation Option with the downlink GRE key included in
      the GRE Key Identifier field, the local mobility anchor MUST
      include the GRE Encapsulation option with the downlink and uplink
      GRE keys in the GRE Key Identifier field when responding with a
      successful PBA message.  When GRE Key Identifier field carries the
      downlink and uplink GRE keys, the first key is always set to the
      downlink GRE key.

Why does the LMA have to include the downlink key in the Proxy BAck
message? The downlink key was sent by the MAG to the LMA in the Proxy
BU. Is this for allowing the LMA to modify the downlink key? Not clear.

Vijay

> From: Ahmad Muhanna [mailto:[email-masked]] 
> Sent: Tuesday, July 08, 2008 9:07 AM
> To: [email-masked]
> Cc: Suresh Krishnan; Chowdhury, Kuntal; Julien Laganier; 
> Vijay Devarapalli; Basavaraj Patil
> Subject: FW: I-D Action:draft-muhanna-netlmm-grekey-option-04.txt
> 
>  
> Hello All,
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 8 Jul 2008 13:20:23 -0500

Hi Vijay,

Thanks for the quick review. Please see inline.

Regards,
Ahmad

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Tuesday, July 08, 2008 12:56 PM
> To: Muhanna, Ahmad (RICH1:2H10); [email-masked]
> Basavaraj Patil
> Subject: RE: I-D Action:draft-muhanna-netlmm-grekey-option-04.txt
> 
> Hi Ahmad,
> 
> In version 02 of the document, there was an option for the 
> LMA to reject GRE encapsulation if the LMA determines that it 
> is not required. 
> 
> This seems to have been removed in version 04. why? In 
> version 04, there seems to be no option for the LMA to 
> indicate that GRE encapsulation is not required for a 
> particular PMIPv6 session.

[Ahmad]
You are right, but that was not intentional. I assume you would be okay
to make that logic valid not for only IPv4 addressing is NOT in use, but
also we can add LMA local policy, for example.

> What if the MAG does not support GRE encapsulation? What does 
> the MAG do? Is this an error condition? There must be a way 
> for the MAG to force the LMA to proceed without GRE 
> encapsulation. There is nothing about this in the MAG 
> Considerations section.

[Ahmad]
But the assignment of the IPv4 address, for example, belongs to the LMA
and it should have the upper hand to force GRE encapsulation for such
scenario. Otherwise, how would the LMA send traffic to the MAG while
being ensured that differentiation of the overlapping traffics is
possible at the MAG and the LMA. I mean, if GRE is not supported,
something else must be supported and as long as we are defining only GRE
encapsulation here, then we need to force this.

Am I making sense?

> Why does the LMA have to include the downlink key in the 
> Proxy BAck message? The downlink key was sent by the MAG to 
> the LMA in the Proxy BU. Is this for allowing the LMA to 
> modify the downlink key? Not clear.

[Ahmad]
I actually do not feel strongly on this one. However, I believe that
including the pair of GRE keys back in the PBA would always provide
another assurance of the assigned pair of GRE keys. That is all. But I
did not mean for the LMA to be able to modify the downlink key. If that
is needed we need to clearly define the logic.

> > Cc: Suresh Krishnan; Chowdhury, Kuntal; Julien Laganier; Vijay 
> > Devarapalli; Basavaraj Patil
> > for IPv4 allow the mobile node's IPv4 and IPv6 traffic between the 
> > local mobility anchor and the mobile access gateway to be tunneled 
> > using IPv6 or IPv4 encapsulation headers.  These 
> encapsulation modes 
> > do not offer the tunnel end-points the required semantics 
> to expose a 
> > service identifier that can be used to identify traffic for 
> a certain 
> > marking the flows, so that differential processing can be 
> applied by 
> > the tunnel peers over those flows.
> >

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 8 Jul 2008 15:14:19 -0400

Hi Ahmad,

> also we can add LMA local policy, for example.

Right. In fact I had suggested that it shouldn't be based only on the
use of private IPv4 address in my earlier review. In an previous email I
wrote.

This paragraph assumes that GRE encapsulation is used only if there is 
overlapping IPv4 address space. I believe GRE encapsulation is used for 
other reasons also (for identifying flows for example) in 3GPP. I 
suggest removing this status code. Or at least explain in more detail 
when the LMA might think GRE encapsulation is unnecessary.

> encapsulation here, then we need to force this.

No. My question was not about the MAG not wanting to use GRE
encapsulation. It was about the MAG not supporting GRE encapsulation.
The LMA has no option but to fall back to IP-in-IP tunneling. Don't know
how to address this, though. 

The MAG probably wouldn't understand the new binding ack status code
TBA2 either. :)

BTW, we need a name for TBA2. Perhaps "GRE Encapsulation Required".

> is needed we need to clearly define the logic.

My preference would be for the LMA to include only the uplink GRE key in
the Proxy BAck.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 8 Jul 2008 15:03:18 -0500

Hi Vijay,

> > You are right, but that was not intentional. I assume you would be 
> > okay to make that logic valid not for only IPv4 addressing 
> is NOT in 
> > use, but also we can add LMA local policy, for example.
> 
> Right. In fact I had suggested that it shouldn't be based 
> only on the use of private IPv4 address in my earlier review. 
> In an previous email I wrote.

[Ahmad]
No problem, will add this one according to this discussion. Hopefully as
a wg doc, after IETF72 :)

> 
> This paragraph assumes that GRE encapsulation is used only if 
> there is overlapping IPv4 address space. I believe GRE 
> encapsulation is used for other reasons also (for identifying 
> flows for example) in 3GPP. I suggest removing this status 
> code. Or at least explain in more detail when the LMA might 
> think GRE encapsulation is unnecessary.
> 
> > 
> > [Ahmad]
> > But the assignment of the IPv4 address, for example, belongs to the 
> > LMA and it should have the upper hand to force GRE 
> encapsulation for 
> > such scenario. Otherwise, how would the LMA send traffic to the MAG 
> > while being ensured that differentiation of the overlapping 
> traffics 
> > is possible at the MAG and the LMA. I mean, if GRE is not 
> supported, 
> > something else must be supported and as long as we are 
> defining only 
> > GRE encapsulation here, then we need to force this.
> > 
> > Am I making sense?
> 
> The LMA has no option but to fall back to IP-in-IP tunneling. 
> Don't know how to address this, though. 
> 
{Ahmad]
Hmmm ... I see what you are saying.

Let us separate the two issues:
1. If the user session requires an IPv4 address assignment which
according to LMA configuration, local policy, etc., requires an IPv4
overlapping, there is no way for the LMA to fall back to IP-in-IP. The
session needs to be aborted. 

2. How to handle the situation when the MAG does not support GRE
encapsulation.
2.1. May be one solution is to mandate that MAG always include the GRE
Encapsulation option and to be used to indicate that the MAG support GRE
encapsulation. Absence of this option, means that MAG does not support
GRE key.

2.2. Another option which was debated before as "not good", is to use a
separate flag in the PBU:-(

2.3. Allow the LMA to reject the PBU with an admin prohibited and then
include a cause value option in the PBA to indicate the exact failure
cause. BUT this does not communicate clearly the cause of rejection to
the MAG. 

Also, we may need to have this as one of the issues that needs to be
addressed during the Netlmm meeting.

> BTW, we need a name for TBA2. Perhaps "GRE Encapsulation Required".

[Ahmad]
Do you mean whenever we refer to TBA2 to use "GRE Encapsulation
Required" instead or to change the name from "GRE Encapsulation and GRE
Key Identifier option required" to "GRE Encapsulation Required"?

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 8 Jul 2008 18:11:50 -0400

> 1. If the user session requires an Ivy address assignment which
> according to LMA configuration, local policy, etc., requires an Ivy

Agree. This needs to be addressed as part of deployments. 

> separate flag in the PBU:-(

I would prefer 2.1 over 2.2. But how does the LMA differentiate between
a MAG that is indicating support for GRE encapsulation from a MAG that
wants to use GRE encapsulation for a particular PMIPv6 session?

> addressed during the Netlmm meeting.

Ok.

> Key Identifier option required" to "GRE Encapsulation Required"?

Right now, there is no phrase in the draft for status code "TBA2". 
Section 5.2 says

I guess we should use "GRE Encapsulation required" for TBA2.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 8 Jul 2008 17:23:28 -0700 (PDT)

> not required for a particular PMIPv6 session.

Agree. This should be generic and the LMA can allow/disallow
the GRE encap mode based on various considerations and including
IPv4 support.

> this in the MAG Considerations section.

You mean LMA does not support. Resend the BU with no GRE Encap option.

> BU. Is this for allowing the LMA to modify the downlink key? Not clear.

No strong reason. But, its better to echo options, useful for diagnostics
..etc.

Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 9 Jul 2008 12:53:09 -0500

Hi Vijay,
Sorry for the late reply. Please see inline.

> Sent: Tuesday, July 08, 2008 5:12 PM

[Ahmad]
Probably if we understand how this will be addressed as part of
deployment, it would help in answering the next question.

> > Encapsulation option and to be used to indicate that the 
> MAG support 
> > GRE encapsulation. Absence of this option, means that MAG does not 
> > support GRE key.
> > 
> > 2.2. Another option which was debated before as "not good", 
> is to use 
> > a separate flag in the PBU:-(
> 
> I would prefer 2.1 over 2.2. But how does the LMA 
> differentiate between a MAG that is indicating support for 
> GRE encapsulation from a MAG that wants to use GRE 
> encapsulation for a particular PMIPv6 session?

[Ahmad]

I believe the answer for the deployment issue above should take care of
this one. 
Just to clarify, I believe what we have should work without the mandate
for including the GRE option all the time. 

Let me try this: in the case when the MAG receive "GRE Encapsulation
Required", there are two cases:
1. If the MAG support GRE encapsulation, everything is fine and it sends
another PBU with GRE option.
2. If the MAG does not support GRE encapsulation, there is a deployment
problem and the MAG need log the event.

IMO, a separate indication of the MAG support of GRE encapsulation does
not have any improvement on what we have currently.

Do not you think?

> > Required" instead or to change the name from "GRE Encapsulation and 
> > GRE Key Identifier option required" to "GRE Encapsulation Required"?
> 

[Ahmad]
Thx. Will take care of it.

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 9 Jul 2008 13:58:35 -0400

> not have any improvement on what we have currently.

I think we should fallback to IP-in-IP encapsulation. It shouldn't
result in the mobile node not getting any service just because the MAG
does not support GRE encapsulation and the LMA wants the MAG to use GRE
encapsulation.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 9 Jul 2008 11:06:42 -0700 (PDT)

> does not support GRE encapsulation and the LMA wants the MAG to use GRE

If the request is for GRE encap mode, if LMA cant support it, it should
return an error code. Same as in 3344. If the MAG determines it can
use other mode, it can resend the request with out the GRE key extension.
Any ways, for a given LMA-MAG pair, this will happen just once in most
cases.

Sri

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 9 Jul 2008 14:15:19 -0400

Sri,

> Any ways, for a given LMA-MAG pair, this will happen just once in most

I think you missed much of the discussion. We are talking about the case
where the MAG does not support GRE encapsulation and does not include
the GRE encapsulation option in the Proxy BU (because it can't). The LMA
thinks that GRE encapsulation is required for the PMIPv6 session,
perhaps because it is going to allocate a private IPv4 address for the
mobile node. So it rejects the PBU with status code "GRE Encapsulation
is required". What does the MAG do now?

I was suggesting falling back to IP-in-IP. We must provide a mechanism
for this.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 9 Jul 2008 11:21:30 -0700 (PDT)

Vijay,

> I was suggesting falling back to IP-in-IP. We must provide a mechanism

Agree. Thanks for the clarification. We can leave it with the note that
the MAG can choose to request other mode. Is that not sufficient ? We
dont need to mandate a specific method. MAG has the option to request
other modes.

Sri

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 9 Jul 2008 14:22:17 -0400

One more thing...
 
> is required". What does the MAG do now?

The MAG would not even understand the "GRE Encapsulation is required"
status code, since it lacks support for GRE encapsulation with PMIPv6.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 9 Jul 2008 11:30:20 -0700 (PDT)

> status code, since it lacks support for GRE encapsulation with PMIPv6.

There is a deadlock there. LMA can only support GRE and MAG does not
even understand what is GRE. Can we design around this ? Future proof
for all types of error codes ? There is a clear incompatibility here.
An administrative action is required, log the error.

Sri

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 9 Jul 2008 14:34:08 -0400

> dont need to mandate a specific method. MAG has the option to request

Yes, but this time, the LMA MUST agree to IP-in-IP encapsulation. It
cannot insist on GRE encapsulation. 

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 9 Jul 2008 14:06:23 -0500

> > 1. If the MAG support GRE encapsulation, everything is fine and it 
> > sends another PBU with GRE option.
> > 2. If the MAG does not support GRE encapsulation, there is a 
> > deployment problem and the MAG need log the event.
> > 
> > IMO, a separate indication of the MAG support of GRE encapsulation 
> > does not have any improvement on what we have currently.
> > 
> > Do not you think?
> 
> I think we should fallback to IP-in-IP encapsulation. It 
> shouldn't result in the mobile node not getting any service 
> just because the MAG does not support GRE encapsulation and 
> the LMA wants the MAG to use GRE encapsulation.

[Ahmad]
But in that case, there is nothing the MAG can do. It is the LMA which
dictate this behavior.
In other words, I do not see the indication of the MAG supporting GRE
encapsulation help in this case.