Subject: [netlmm] I-D Action:draft-ietf-netlmm-grekey-option-01.txt

From: [email-masked]
Date: Tue, 7 Oct 2008 20:45:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network-based Localized Mobility Management Working Group of the IETF.

	Title           : GRE Key Option for Proxy Mobile IPv6
	Author(s)       : A. Muhanna, et al.
	Filename        : draft-ietf-netlmm-grekey-option-01.txt
	Pages           : 16
	Date            : 2008-10-07

This document defines a new Mobility Option for allowing the mobile
access gateway and the local mobility anchor to negotiate GRE
encapsulation mode and exchange the downlink and uplink GRE keys
which are used for marking the downlink and uplink traffic that
belong to a specific mobile node session or a specific flow.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netlmm-grekey-option-01.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: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 7 Oct 2008 22:48:01 -0500

Hi Jonne/All,

We have submitted a new revision of the GRE draft to address your
comments and one more as listed below:

1. Jonne comments related to the Abstract
 
2. Jonne comment related to the "GRE Encapsulation NOT supported" to
address the case when LMA does not support GRE encapsulation, a
successful processing of PBU by ignoring the GRE Key option and
returning a successful PBA without GRE Key option is an indication the
LMA does not support GRE Key Option.
  
3. Fix the logic for the following two status code" GRE KEY OPTION
REQUIRED (more than 128)" and "GRE KEY OPTION NOT REQUIRED (less than
128)".

Thanks for your review and comments!

Regards,
Ahmad

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Tuesday, October 07, 2008 10:45 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [netlmm] I-D Action:draft-ietf-netlmm-grekey-option-01.txt
> 
> This draft is a work item of the Network-based Localized 
> Mobility Management Working Group of the IETF.
> 
> 
> This document defines a new Mobility Option for allowing the 
> mobile access gateway and the local mobility anchor to 
> negotiate GRE encapsulation mode and exchange the downlink 
> and uplink GRE keys which are used for marking the downlink 
> and uplink traffic that belong to a specific mobile node 
> session or a specific flow.
> 
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
>

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 8 Oct 2008 15:07:41 -0400

Hi Ahmad,

The changes look good. One minor change. Modify the abstract from 

to 

   This document defines an extension to Proxy Mobile IPv6 to allow 
   the mobile access gateway and the local mobility anchor to 
   negotiate GRE encapsulation mode for tunneling mobile node traffic.
   It also defines extensions to exchange the downlink and uplink GRE 
   keys which are then used for marking the downlink and uplink traffic 
   that belongs to a specific mobile node session or a specific flow.

Vijay

Ahmad Muhanna wrote:
>> [mailto:[email-masked]] On Behalf Of
>> [email-masked] Sent: Tuesday, October 07, 2008 10:45 PM
Pages    
>> 	: 16 Date            : 2008-10-07

---

From: Wang Yungui <[email-masked]>
Date: Thu, 09 Oct 2008 15:09:28 +0800

Hello Ahmad,

I have some questions about the GRE encapsulation mode negotiation.

Question 1, Is 'the GRE encapsulation mode negotiation' mandatory or 
optional if this spec is supported?

Question 2, In section 3.2 GRE Encapsulation Support, it is described that 
the GRE encapsulation mode is negotiated without GRE key exchange. It 
implies this PBU is not valid if the GRE key is required. It seems that one 
RTT is always wasted for a specific mobile node. Does it?

Question 3, As described in section 4.2,
"
o  If the mobile access gateway sent a Proxy Binding Update message
      without the GRE Key option, but the received Proxy Binding
      Acknowledgement has the Status Code <GRE KEY OPTION REQUIRED>,
      indicating that the GRE encapsulation and GRE key is required, the
      mobile access gateway SHOULD resend the Proxy Binding Update
      message with the GRE Key option.  ...
",
If the LMA does not support GRE Encapsulation in the MAG's memory,
a) does the MAG need to re-negotiate the GRE Encapsulation mode (as section 
3.2 described) before resending the PBU with GRE key option? and,
b) could the MAG include the GRE Key option in the subsequent PBU message on 
behalf of other MNs?

Thanks.

B.R.
Yungui

----- Original Message ----- 
From: "Ahmad Muhanna" <[email-masked]>
To: <[email-masked]>; "Soininen Jonne (NSN FI/Espoo)" 
<[email-masked]>
Sent: Wednesday, October 08, 2008 11:48 AM
Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-grekey-option-01.txt

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 9 Oct 2008 09:12:00 -0500

Hi Yungui,
Please see inline.

Regards,
Ahmad

> From: Wang Yungui [mailto:[email-masked]] 
> Sent: Thursday, October 09, 2008 2:09 AM
> To: Muhanna, Ahmad (RICH1:2H10); [email-masked]; Soininen 
> Jonne (NSN FI/Espoo)
> Subject: Re: [netlmm] I-D 
> Action:draft-ietf-netlmm-grekey-option-01.txt
> 
> Hello Ahmad,
> 
> Question 1, Is 'the GRE encapsulation mode negotiation' 
> mandatory or optional if this spec is supported?

[Ahmad]
The default for this specification is to negotiate dynamic GRE keys and
GRE encapsulation. There was an argument on the mailing list that if the
MAG has an indication that dynamic GRE keys is NOT required, e.g.
statically configured GRE key, in this case, the MAG will negotiate the
GRE encapsulation without GRE keys included.

As far as mandatory vs. optional, If LMA and MAG support the GRE Key
Option logic per this specification, why it would not support the logic
for GRE Key option with length field is set to "2"?

> 
> Question 2, In section 3.2 GRE Encapsulation Support, it is 
> described that the GRE encapsulation mode is negotiated 
> without GRE key exchange. It implies this PBU is not valid if 
> the GRE key is required. It seems that one RTT is always 
> wasted for a specific mobile node. Does it?

[Ahmad]
Again, the MAG sends the GRE key option without a GRE key included ONLY
when it has some indication locally that dynamic GRE keys are NOT
required. If the MAG does not have any indication then the default is to
negotiate GRE encapsulation and GRE keys by including the downlink GRE
Key.

If the MAG sends a PBU with GRE Key option without the downlink GRE key
included and the LMA finds out that dynamic GRE keys is REQUIRED, then
it is an error scenario and I do not see any problem with that.

> 
> Question 3, As described in section 4.2, "
[Ahmad]
What does this mean?

> b) could the MAG include the GRE Key option in the subsequent 
> PBU message on behalf of other MNs?
> 
> Thanks.
> 
> B.R.
> Yungui
> 
> Subject: Re: [netlmm] I-D 
> Action:draft-ietf-netlmm-grekey-option-01.txt
> 
> 
> > Hi Jonne/All,
> >

---

From: Wang Yungui <[email-masked]>
Date: Fri, 10 Oct 2008 10:21:55 +0800

Hello Ahmad,

Thanks. Please see inline.

B.R.
Yungui

----- Original Message ----- 
From: "Ahmad Muhanna" <[email-masked]>
To: "Wang Yungui" <[email-masked]>; <[email-masked]>; "Soininen Jonne 
(NSN FI/Espoo)" <[email-masked]>
Sent: Thursday, October 09, 2008 10:12 PM
Subject: RE: [netlmm] I-D Action:draft-ietf-netlmm-grekey-option-01.txt

Hi Yungui,
Please see inline.

Regards,
Ahmad

[Ahmad]

[Yungui]: In my understanding, this draft is applied for the dynamic
GRE keys only. If the MAG is indicated that dynamic GRE keys
is NOT required, then none of GRE encapsulation mode negotiation
is required as well. (For the static GRE tunnel, the peers are aware
of each other)
So, the GRE encapsulation mode negotiation should be following with
the GRE key exchange in a couple of PBU/PBA between the peers.

As far as mandatory vs. optional, If LMA and MAG support the GRE Key
Option logic per this specification, why it would not support the logic
for GRE Key option with length field is set to "2"?
[Yungui]: See above, it is not required.

[Ahmad]
[Yungui]: See above, only the later is needed in case of the dynamic GRE
keys exchange.

[Yungui]: There is no problem in this error scenario. See above, I just 
don't think
the static GRE tunnel need to perform the GRE encapsulation mode 
negotiation.

> 3.2 described) before resending the PBU with GRE key option? and,
[Ahmad]
What does this mean?
[Yungui] In this case, the PBU without GRE key option is obvious not
the re-registration message. So, I think, the premise of this case is,
1) The MAG and the LMA don't negotate the GRE Encapsulation mode
at before
due to the MAG decide not to use GRE (or other reasons). Or,
2) The MAG and the LMA has negotiated the GRE Encapsulation mode,
but the LMA had indicated 'not support GRE Encapsulation mode' to the
MAG in some certain situation.
Under this background, 'The PBA with <GRE KEY OPTION REQUIRED>'
is for the special MN only, or for all the subsequent MNs? How does
the MAG differentiate that? Thanks.

B.R.
Yungui

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 9 Oct 2008 22:54:30 -0500

Hi Yungui,

> The default for this specification is to negotiate dynamic 
> GRE keys and GRE encapsulation. There was an argument on the 
> mailing list that if the MAG has an indication that dynamic 
> GRE keys is NOT required, e.g.
> statically configured GRE key, in this case, the MAG will 
> negotiate the GRE encapsulation without GRE keys included.
> 
> [Yungui]: In my understanding, this draft is applied for the 
> dynamic GRE keys only. If the MAG is indicated that dynamic 
> GRE keys is NOT required, then none of GRE encapsulation mode 
> negotiation is required as well. 
[Ahmad]
This has been discussed on the mailing list already and the draft
reflects the consensus of that discussion. 

On the other hand, If the MAG does not support the GRE encapsulation
mode negotiation, then there will never be a problem. The MAG can always
include the GRE Key option with the downlink GRE Key included and that
will never have any IOT problem.

Basically to be precise, let me put it this way: it is definitely
optional to implement on the MAG but mandatory to support on the LMA.

> (For the static GRE tunnel, 
> the peers are aware of each other) So, the GRE encapsulation 
> mode negotiation should be following with the GRE key 
> exchange in a couple of PBU/PBA between the peers.
> 
> As far as mandatory vs. optional, If LMA and MAG support the 
> GRE Key Option logic per this specification, why it would not 
> support the logic for GRE Key option with length field is set to "2"?
> described 
> > that the GRE encapsulation mode is negotiated without GRE key 
> > exchange. It implies this PBU is not valid if the GRE key 
> is required. 
> > It seems that one RTT is always wasted for a specific mobile node. 
> > Does it?
> 
> [Ahmad]
> Again, the MAG sends the GRE key option without a GRE key 
> included ONLY when it has some indication locally that 
> dynamic GRE keys are NOT required. If the MAG does not have 
> any indication then the default is to negotiate GRE 
> encapsulation and GRE keys by including the downlink GRE Key.
> [Yungui]: See above, only the later is needed in case of the 
> dynamic GRE keys exchange.
> 
> If the MAG sends a PBU with GRE Key option without the 
> downlink GRE key included and the LMA finds out that dynamic 
> GRE keys is REQUIRED, then it is an error scenario and I do 
> not see any problem with that.
> 
> [Yungui]: There is no problem in this error scenario. See 
> above, I just don't think the static GRE tunnel need to 
> perform the GRE encapsulation mode negotiation.
> 
> >

[Ahmad]
Let me try to answer the question based on what I understood from your
description.
At anytime, the MAG receive a PBA with status code <GRE KEY OPTION
REQUIRED>, it means that GRE encapsulation and GRE key is required for
this specific mobile node. On the other hand, at anytime the MAG receive
a PBA from an LMA with this status code, it is very safe for the MAG to
assume that this LMA support GRE Key option as per this specification.

Hope this answers your question.

---

From: Shi Xiaoyan <[email-masked]>
Date: Fri, 10 Oct 2008 15:07:37 +0800

Hi Ahmad，

In Section 4.2, I think the PBA with a status code and without GRE option
indicates that LMA do not support GRE Encapsulation.  Should there emphasize
"without GRE option"?

   o  If the mobile access gateway included the GRE Key option in the
      Proxy Binding Update for a specific mobile node and the local
      mobility anchor accepts the Proxy Binding Update by sending a
      Proxy Binding Acknowledgement with a status code <SUCCESS> or any
      status code that is less than 128 other than <GRE KEY OPTION NOT
      REQUIRED>, the mobile access gateway MUST consider that the local
      mobility anchor does not support GRE Key option as per this
      specification.  The mobile access gateway SHOULD NOT include the
      GRE Key option in any subsequent Proxy Binding Update message that
      is sent to that LMA.

Regards,
Xiaoyan

> [mailto:[email-masked]] On Behalf Of Ahmad Muhanna
> To: [email-masked]; Soininen Jonne (NSN FI/Espoo)
> We have submitted a new revision of the GRE draft to address 
> your comments and one more as listed below:
> 
> 2. Jonne comment related to the "GRE Encapsulation NOT 
> supported" to address the case when LMA does not support GRE 
> encapsulation, a successful processing of PBU by ignoring the 
> GRE Key option and returning a successful PBA without GRE Key 
> option is an indication the LMA does not support GRE Key Option.
>   
> 3. Fix the logic for the following two status code" GRE KEY 
> OPTION REQUIRED (more than 128)" and "GRE KEY OPTION NOT 
> REQUIRED (less than 128)".
> 
> > encapsulation mode and exchange the downlink and uplink GRE 
> keys which 
> > are used for marking the downlink and uplink traffic that 
> belong to a 
> > specific mobile node session or a specific flow.
> >

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 10 Oct 2008 06:00:20 -0500

Thanks Xiaoyan for spotting this. 
Yes, I agree that was the intention and it should have been clearly emphasized.
We will fix it!

Regards,
Ahmad

> From: Shi Xiaoyan [mailto:[email-masked]] 
> Sent: Friday, October 10, 2008 2:08 AM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: 'tanshiyong'; [email-masked]
> Subject: RE: [netlmm] I-D 
> In Section 4.2, I think the PBA with a status code and 
> without GRE option indicates that LMA do not support GRE 
> Encapsulation.  Should there emphasize "without GRE option"?
> 
> supported" to 
> > > Subject: [netlmm] I-D 
> > > A New Internet-Draft is available from the on-line 
> Internet-Drafts 
> > > directories.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 10 Oct 2008 07:46:12 -0500

Hi Yungui,
Please keep netlmm ml informed. I added the list.

> 
> The question 3 described a new use case which I re-write it 
> from viewpoint of the LMA as below.
> i) The MAG and the LMA do support GRE encapsulation.
> ii) The MAG does not decide to use GRE.  (so it doesn't 
> negotiate GRE encapsulation too)
> iii) But the LMA may decide to use GRE option for this 
> special MN, OR for all the subsequent MNs.
> 
> Do you think whether this case is allowed?
> 
> Here is the problem: the Status Code <GRE KEY OPTION 
> REQUIRED> is not enough to indicate two options.

[Ahmad]
Hmmm... If we go that route, I am not sure how the MAG would know which
GRE tunnel to use for this mobile node without a local indication to
start with? And if the MAG had that indication, it would added the GRE
Key option with the length field is set to "2". To me this is a case of
misconfiguration similar to the case when LMA support GRE and the MAG
does not.

But probably a generic full negotiation of the GRE encapsulation mode is
what you are asking for here. 
If people on the list agree, then we can define another error code <GRE
ENCAPSULATION W/O KEYS REQUIRED>

> 
> Do you get it? That's my question.
[Ahmad]
Finally!

---

From: Wang Yungui <[email-masked]>
Date: Sat, 11 Oct 2008 09:33:20 +0800

Hi Ahmad,

>ENCAPSULATION W/O KEYS REQUIRED>

[Yungui] For a general draft, the full negotiation procedure is appreciated.
I think it is valuable to add above new error code in this draft.

B.R.
Yungui

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 13 Oct 2008 14:29:07 -0400

Hi Ahmad, Xiaoyan

If the LMA sent the status <GRE KEY OPTION NOT REQUIRED> in the proxy binding ack, it means that the LMA does support GRE encapsulation, but it thinks GRE encapsulation is not required for a particular mobility session. I think the paragraph

should be replaced by

   o  If the mobile access gateway included the GRE Key option in the
      Proxy Binding Update for a specific mobile node and the local
      mobility anchor accepts the Proxy Binding Update by sending a
      Proxy Binding Acknowledgement with a status code <SUCCESS>, 
      but without the GRE Key option, then the mobile access gateway 
      MUST consider that the local mobility anchor does not support GRE 
      Key option as per this specification.  The mobile access gateway 
      SHOULD NOT include the GRE Key option in any subsequent 
      Proxy Binding Update message that is sent to that LMA.

Vijay

[email-masked] wrote:
> Yes, I agree that was the intention and it should have been clearly
> emphasized. We will fix it!
> 
> Regards,
> Ahmad
> 
> 
>>       Proxy Binding Acknowledgement with a status code <SUCCESS> or
>>       any status code that is less than 128 other than <GRE KEY
>>       OPTION NOT REQUIRED>, the mobile access gateway MUST consider
>> that 
>> the local
>>       specification.  The mobile access gateway SHOULD NOT include
>>       the GRE Key option in any subsequent Proxy Binding Update
>>       message that is sent to that LMA.
>> 
>> Regards,
>> Xiaoyan
>> 
>> 
>> 
>>> returning a successful PBA without GRE Key option is an indication
>>> the LMA does not support GRE Key Option.
>>> 
>>> REQUIRED (more than 128)" and "GRE KEY OPTION NOT REQUIRED (less
>>> than 128)". 
>>> 
>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>> directories. This draft is a work item of the Network-based
>>>> Localized Mobility Management Working Group of the IETF.
>>>> 
>>>> 
>>>> 	Filename        : draft-ietf-netlmm-grekey-option-01.txt 	Pages  
>>>> 	: 16 Date            : 2008-10-07
>>>>

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 13 Oct 2008 14:35:39 -0400

Hi Ahmad, Yungui,

I went through this tread. I couldn't figure out what problem you are
trying to solve. It looks like there was some offline discussion. Can
you summarize again, what the problem is?

Vijay 

> Sent: Friday, October 10, 2008 5:46 AM
> To: Wang Yungui
> Cc: [email-masked]

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 13 Oct 2008 14:37:54 -0400

Yungui,

> the MAG differentiate that? Thanks.

The status code <GRE KEY OPTION REQUIRED> applies to a particular
mobility session. It does not indicate that GRE encapsulation is
required for all subsequent mobility sessions setup.

Vijay

---

From: Wang Yungui <[email-masked]>
Date: Tue, 14 Oct 2008 12:44:03 +0800

Hi Vijay,

Do you think how the LMA can indicate that GRE encapsulation
is required for all subsequent mobility sessions setup if
needed? I can't get it from this draft. So I think it is
necessary to add new code <GRE ENCAPSULATION W/O KEYS
REQUIRED> as Ahmad mentioned.

B.R.
Yungui

----- Original Message ----- 
From: "Vijay Devarapalli" <[email-masked]>
To: "Wang Yungui" <[email-masked]>; "Ahmad Muhanna"
<[email-masked]>; <[email-masked]>; "Soininen Jonne
(NSN FI/Espoo)" <[email-masked]>
Sent: Tuesday, October 14, 2008 2:37 AM
Subject: RE: [netlmm] I-D
Action:draft-ietf-netlmm-grekey-option-01.txt

Yungui,

> the MAG differentiate that? Thanks.

The status code <GRE KEY OPTION REQUIRED> applies to a
particular
mobility session. It does not indicate that GRE
encapsulation is
required for all subsequent mobility sessions setup.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 14 Oct 2008 12:59:35 -0500

Hi Vijay,

I do not recall any offlist discussion, but in one incident, I noticed
that Yungui was replying back to me without the list. That when I added
the list.

My understanding is the following:

If we allowed the GRE encapsulation mode ONLY to be negotiated by the
MAG, i.e. by including the GRE Key option with length field is set to 2,
why not allowing that mode whenever needed by the LMA.

Basically, if the MAG does not include the GRE Key option and the LMA
needs just GRE encapsulation without keys for this mobile node, the
error code "GRE KEY Option REQUIRED" is not explicit enough because it
means that both the GRE encapsulation mode and the GRE key is needed.
What Yungui was asking is why not allow another error code which allows
the LMA to reject the BU and indicates that "GRE ENCAPSULATION W/O Keys"
is required.

As I stated before the MAG needs to know which GRE tunnel to use and if
that indication is available to the MAG to start with, then the MAG
should have included the GRE Key option with length field is set to 2 to
start with. However, I personally feel that it is not a bad idea to
include this error code as long as people on the list agree with its
need and use.

Hope this captures the whole background. 

Regards,
Ahmad

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Monday, October 13, 2008 1:36 PM
> To: Muhanna, Ahmad (RICH1:2H10); Wang Yungui
> Cc: [email-masked]
> I went through this tread. I couldn't figure out what problem 
> you are trying to solve. It looks like there was some offline 
> discussion. Can you summarize again, what the problem is?
> 
> Vijay 
> 
> > > The question 3 described a new use case which I re-write it from 
> > > viewpoint of the LMA as below.
> > > ii) The MAG does not decide to use GRE.  (so it doesn't negotiate 
> > > GRE encapsulation too)
> > Hmmm... If we go that route, I am not sure how the MAG would know 
> > which GRE tunnel to use for this mobile node without a local 
> > indication to start with? And if the MAG had that 
> indication, it would 
> > added the GRE Key option with the length field is set to "2". To me 
> > this is a case of misconfiguration similar to the case when LMA 
> > support GRE and the MAG does not.
> > 
> > But probably a generic full negotiation of the GRE 
> encapsulation mode 
> > is what you are asking for here.
> > If people on the list agree, then we can define another error code 
> > <GRE ENCAPSULATION W/O KEYS REQUIRED>
> > 
> > >

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 14 Oct 2008 13:12:29 -0500

Hi Vijay,

That was the intention from my reply to Xiaoyan, however, I was thinking that there could be other options in the BU which indicate the support of other functionalities. Let us assume option X (I do not have an example ready now) When the LMA receives the BU with GRE Key Option and option X, LMA will ignore the GRE Key option because it does not support GRE but will process option X.

If processing option X does produce a code which is NOT <SUCCESS> but it is still less that 128, what the MAG would conclude regarding the LMA support of the GRE option? 

I thought including the following text would address the above case:
"or any status code that is less than 128 other than <GRE KEY OPTION NOT REQUIRED>"

Regards,
Ahmad

> Sent: Monday, October 13, 2008 1:29 PM
> To: Muhanna, Ahmad (RICH1:2H10); Shi Xiaoyan
> Cc: [email-masked]
> If the LMA sent the status <GRE KEY OPTION NOT REQUIRED> in 
> the proxy binding ack, it means that the LMA does support GRE 
> encapsulation, but it thinks GRE encapsulation is not 
> required for a particular mobility session. I think the paragraph
> 
> >> In Section 4.2, I think the PBA with a status code and without GRE 
> >> option indicates that LMA do not support GRE 
> Encapsulation.  Should 
> >> that the local
> >>>> 	Filename        : 
> draft-ietf-netlmm-grekey-option-01.txt 	Pages  
> >>>> 	: 16 Date            : 2008-10-07
> >>>>

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 14 Oct 2008 22:03:01 -0700

On 10/13/08 9:44 PM, "Wang Yungui" <[email-masked]> wrote:

> needed? 

But why do you need this? It is probably some sort of mis-configuration on
the MAG, if the MAG thinks GRE encapsulation is not required and the LMA
keeps saying GRE encapsulation is required for each mobility session setup.

Lets keep it simple, please.

Vijay

I can't get it from this draft. So I think it is

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 14 Oct 2008 22:14:03 -0700

Hi Ahmad,

> the LMA to reject the BU and indicates that "GRE ENCAPSULATION W/O Keys"

If the GRE keys are not exchanged in the PBU/PBACK, then I assume they are
configured on the MAG and the LMA for use with a particular mobility
session. If that's the case, the MAG would already know that it has to use
the pre-configured GRE keys when the LMA sends the status code "GRE KEY
OPTION REQUIRED". Why do you need a new status code that says "GRE
ENCAPSULATION REQUIRED W/O Keys"?

> include this error code as long as people on the list agree with its

Seems unnecessary to me.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 14 Oct 2008 22:18:14 -0700

On 10/14/08 11:12 AM, "Ahmad Muhanna" <[email-masked]> wrote:

> Hi Vijay,
> 
> That was the intention from my reply to Xiaoyan, however, I was thinking that
> there could be other options in the BU which indicate the support of other
> functionalities. Let us assume option X (I do not have an example ready now)
> When the LMA receives the BU with GRE Key Option and option X, LMA will ignore
> the GRE Key option because it does not support GRE but will process option X.
> 
> If processing option X does produce a code which is NOT <SUCCESS> but it is
> still less that 128, what the MAG would conclude regarding the LMA support of
> the GRE option? 
> 

Ok, how about the following?

   o  If the mobile access gateway included the GRE Key option in the
      Proxy Binding Update for a specific mobile node and the local
      mobility anchor accepts the Proxy Binding Update by sending a
      Proxy Binding Acknowledgement with a success status code (less than
      128), but without the GRE Key option, then the mobile access gateway
      MUST consider that the local mobility anchor does not support GRE Key
      option as per this specification.  The mobile access gateway SHOULD
      NOT include the GRE Key option in any subsequent Proxy Binding Update
      message that is sent to that LMA.

Vijay

---

From: Wang Yungui <[email-masked]>
Date: Wed, 15 Oct 2008 15:26:46 +0800

Hi Vijay

I also hope it is simple, and hope it can cover all the
cases.

In my mind, the entire GRE encap mode negotiation procedure
can be removed/reworded in this draft.As a general mobility
option, if it is not supported by peer, it will be ignored
and skipped as described in RFC3775 (section 6.2.1).
Therefore, whether the GRE option is included in the
corresponding message has indicated that the peer's
capability.
Of course, there are two special cases,
static/dynamic GRE encap mode and GRE key exchange,
required to be negotiated. However,
we can design the GRE option carefully, such as the
reserved bit can be used to do that. I am appreciated
with authors' works on this draft, so I wouldn't suggest
to re-design the entire GRE option.

In the end, I think, the full negotiation procedure is
considerable, and may be useful. The above case may be a
misconfiguration as you said. If it happens, don't you wish
this draft can point it out?
I can't enumerate all the cases. Here I just give
another use case described in the draft, "If the LMA
receives a handoff-triggered Binding Lifetime Extension PBU
message without the GRE key option for a BCE that is using
GRE keys and GRE encapsulation, the LMA MUST reject the
Proxy Binding Update by sending a Proxy Binding
Acknowledgement message with the status field is set to <GRE
KEY OPTION REQUIRED> as defined in Section 6.2.",
if this PBU message is the first message that the MAG sent,
the LMA may tell the MAG that GRE encapsulation is required
for each mobility session setup.
Thanks.

B.R.
Yungui

----- Original Message ----- 
From: "Vijay Devarapalli" <[email-masked]>
To: "Wang Yungui" <[email-masked]>; "Ahmad Muhanna"
Sent: Wednesday, October 15, 2008 1:03 PM

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 15 Oct 2008 23:47:15 -0500

Hi Vijay,

> > That was the intention from my reply to Xiaoyan, however, I was 
> > thinking that there could be other options in the BU which indicate 
> > the support of other functionalities. Let us assume option 
> X (I do not 
> > have an example ready now) When the LMA receives the BU 
> with GRE Key 
> > Option and option X, LMA will ignore the GRE Key option 
> because it does not support GRE but will process option X.
> > 
> > If processing option X does produce a code which is NOT 
> <SUCCESS> but 
> > it is still less that 128, what the MAG would conclude 
> regarding the 
> > LMA support of the GRE option?
> > 
> > "or any status code that is less than 128 other than <GRE 
> KEY OPTION 
> > NOT
> > REQUIRED>"
> 

[Ahmad]
Yes, that should work, but let us remember error code "GRE KEY OPTION NOT REQUIRED" is less than 128 and we need to list it as an exception.
What about tweaking what you just said a little as follows:

   o  If the mobile access gateway included the GRE Key option in the
      Proxy Binding Update for a specific mobile node and the local
      mobility anchor accepts the Proxy Binding Update by sending a
      Proxy Binding Acknowledgement with a success status code (less
      than 128) other than <GRE KEY OPTION NOT REQUIRED>, but without
      the GRE Key option, then the mobile access gateway MUST consider
      that the local mobility anchor does not support GRE Key option as
      per this specification.  The mobile access gateway SHOULD NOT
      include the GRE Key option in any subsequent Proxy Binding Update
      message that is sent to that LMA.

Regards,
Ahmad
> >> If the LMA sent the status <GRE KEY OPTION NOT REQUIRED> 
> in the proxy 
> >> binding ack, it means that the LMA does support GRE encapsulation, 
> >> but it thinks GRE encapsulation is not required for a particular 
> >> mobility session. I think the paragraph
> >> 
> >> any
> >>       GRE Key option in any subsequent Proxy Binding 
> Update message 
> >> that
> >>       is sent to that LMA.
> >> 
> >> should be replaced by
> >> 
> >>       MUST consider that the local mobility anchor does 
> not support 
> >> GRE
> without GRE

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 15 Oct 2008 23:51:16 -0500

Hi Vijay

> > MAG, i.e. by including the GRE Key option with length field 
> is set to 
> > 2, why not allowing that mode whenever needed by the LMA.
> > 
> > What Yungui was asking is why not allow another error code which 
> > allows the LMA to reject the BU and indicates that "GRE 
> ENCAPSULATION W/O Keys"
> > is required.
> 
> If the GRE keys are not exchanged in the PBU/PBACK, then I 
> assume they are configured on the MAG and the LMA for use 
> with a particular mobility session. If that's the case, the 
> MAG would already know that it has to use the pre-configured 
> GRE keys when the LMA sends the status code "GRE KEY OPTION 
> REQUIRED". Why do you need a new status code that says "GRE 

[Ahmad]
I agree. That what I was trying to explain. 
The MAG should know that it needs to negotiate GRE encapsulation mode in
the first place and include GRE Key Option with length field is set to 2
in the first place.

> 
> > As I stated before the MAG needs to know which GRE tunnel 
> to use and 
> > if that indication is available to the MAG to start with, 
> then the MAG 
> > should have included the GRE Key option with length field 
> is set to 2 
> > to start with. However, I personally feel that it is not a 
> bad idea to

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 15 Oct 2008 21:57:16 -0700

On 10/15/08 9:47 PM, "Ahmad Muhanna" <[email-masked]> wrote:

> Yes, that should work, but let us remember error code "GRE KEY OPTION NOT
> REQUIRED" is less than 128 and we need to list it as an exception.

Fine with me.

Vijay

---

From: Wang Yungui <[email-masked]>
Date: Thu, 16 Oct 2008 14:25:51 +0800

Hello Ahmad

I don't think it works well.
As your previous example, if two successful status
codes <less than 128> need to be responded back to
the MAG, how does the LMA select the just one?
Once the status code <GRE KEY OPTION NOT REQUIRED> is
covered by another status code, then the MAG may
misunderstand it.

Maybe you don't see my last mail, in which I have
mentioned another way: if something in the GRE key
option needs to be negotiated between two peers,
the reserved BIT in GRE key option can be used.

For example, four BITs is used to deal with
GRE key option involved negotiation/exchange
cases, <GRE KEY OPTION W/O REQUIRED> and
<GRE ENCAP W/O KEY REQUIRED>.
And GRE ENCAP NOT SUPPORTED is implicitly indicated
by the successful PBA without GRE key option when the
requested PBU is carried with a GRE key option.

B.R.
Yungui

----- Original Message ----- 
From: "Ahmad Muhanna" <[email-masked]>
To: "Vijay Devarapalli" <[email-masked]>; "Shi Xiaoyan"
<[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, October 16, 2008 12:47 PM
Subject: Re: [netlmm] I-D
Action:draft-ietf-netlmm-grekey-option-01.txt

> Yes, that should work, but let us remember error code "GRE KEY
> OPTION NOT REQUIRED" is less than 128 and we need to list it as an
> exception.
>> >>       REQUIRED>, the mobile access gateway MUST consider that
>> >> the
>> >> local

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 16 Oct 2008 14:24:22 -0500

Hello yungui,

As I mentioned before, theoretically, I feel that adding this error code
may be needed and that why I wanted to hear from people on the list, but
until now, you did not clearly describe the use case in order to help in
agreeing with you that there is a usecase that needs to be addressed. I
believe if the usecase is clear, then there should not be a problem in
adding the error code.

Please let us remember, the initial intention of this draft is to allow
the dynamic GRE key exchange between the MAG and LMA. So, please explain
your usecase clearly in a way that explain what the MAG and LMA supports
(statically configured GRE tunnel or tunnels, how the MAG would know
which GRE tunnel to use in the case of static GRE tunnel, does the MAG
support a mix of dynamic GRE key exchange (for certain MNs) and
statically configured tunnels for others (or for the same MN), etc.).
Hopefully that will make the case clear and adding such code will be
much easier.

Regards,
Ahmad

> Sent: Thursday, October 16, 2008 1:26 AM
> To: Muhanna, Ahmad (RICH1:2H10); Vijay Devarapalli; Shi Xiaoyan
> Cc: [email-masked]
> As your previous example, if two successful status codes 
> <less than 128> need to be responded back to the MAG, how 
> does the LMA select the just one?
> Once the status code <GRE KEY OPTION NOT REQUIRED> is covered 
> by another status code, then the MAG may misunderstand it.
> 
> Maybe you don't see my last mail, in which I have mentioned 
> another way: if something in the GRE key option needs to be 
> negotiated between two peers, the reserved BIT in GRE key 
> option can be used.
> 
> For example, four BITs is used to deal with GRE key option 
> involved negotiation/exchange cases, <GRE KEY OPTION W/O 
> REQUIRED> and <GRE ENCAP W/O KEY REQUIRED>.
> And GRE ENCAP NOT SUPPORTED is implicitly indicated by the 
> successful PBA without GRE key option when the requested PBU 
> is carried with a GRE key option.
> 
> 
> B.R.
> Yungui
>