Subject: [netlmm] A question about GRE-key draft

From: "Soininen Jonne (NSN FI/Espoo)" <[email-masked]>
Date: Mon, 15 Sep 2008 15:05:38 +0300

Hello everybody,

I read the gre-key draft through. It seems that the spec starts to be in
pretty good shape. However, I have a couple of questions just for my own
clarification.

1) Not supporting GRE-keys
The spec says that if the LMA doesn't support GRE-keys the LMA must reject
the PBU as specified in this spec. However, I don't think this spec can give
much guidance on implementations that don't support this spec.

I would assume that the PBU would be rejected in the general fashion that
all non-supported extensions are rejected. Am I missing something?

2) Just a personal feeling about the abstract: I don't think the abstract
should tell why this extension to PMIP was specified, but what it does. So
rather than starting to tell what PMIP6 does and doesn't do, the abstract
should just state what this spec brings. The background why this has been
done can then be in the introduction.

Cheers,

Jonne.
-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34
E-mail: [email-masked]

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

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 15 Sep 2008 08:17:53 -0500

Hi Jonne,

Thanks for the review and comments. Please see inline.

Regards,
Ahmad

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Soininen Jonne 
> (NSN FI/Espoo)
> Sent: Monday, September 15, 2008 7:06 AM
> To: [email-masked]
> Subject: [netlmm] A question about GRE-key draft
> 
> Hello everybody,
> 
> I read the gre-key draft through. It seems that the spec 
> starts to be in pretty good shape. However, I have a couple 
> of questions just for my own clarification.
> 
> The spec says that if the LMA doesn't support GRE-keys the 
> LMA must reject the PBU as specified in this spec. However, I 
> don't think this spec can give much guidance on 
> implementations that don't support this spec.
> 
> I would assume that the PBU would be rejected in the general 
> fashion that all non-supported extensions are rejected. Am I 
> missing something?

[Ahmad]
The following are the three incidents that are related to your comment.
If I missed something, please let me know.

Under section 3.2:
==================
   However, If the local mobility anchor does not support GRE
   encapsulation, the LMA MUST reject the Proxy Binding Update by
   sending a Proxy Binding Acknowledgement message with the status field
   is set to <IANA-TBA1> as defined in Section 6.2.

Under Section 4.2:
==================
   o  For a given mobile node, if the local mobility anchor rejects the
      Proxy Binding Update by sending a Proxy Binding Acknowledgement
      with the status code <IANA-TBA1> (GRE Encapsulation NOT
      supported), the mobile access gateway MUST NOT include the GRE Key
      Option in the subsequent Proxy Binding Update messages that are
      sent to that LMA.

Under section 5.2:
==================
   o  Upon receiving a Proxy Binding Update message with the GRE Key
      Option and if the local mobility anchor does not support GRE
      encapsulation mode, the LMA MUST send a Proxy Binding
      Acknowledgement message to the MAG with a status code <IANA-TBA1>
      as defined in Section 6.2.

Hmmm... I agree with you, this sounds as if we are making new
requirements for the existing LMA which does not support GRE
encapsulation as per this draft.

Let me ask if anyone see a problem if we remove these three paragraphs
and eventually error code <IANA-TBA1> "GRE Encapsulation NOT Supported"
?

> 
> 2) Just a personal feeling about the abstract: I don't think 
> the abstract should tell why this extension to PMIP was 
> specified, but what it does. So rather than starting to tell 
> what PMIP6 does and doesn't do, the abstract should just 
> state what this spec brings. The background why this has been 
[Ahmad]
You are right. Will fix it.

Regards,
Ahmad

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 24 Sep 2008 18:44:02 -0400

Hi Ahmad,

>       Acknowledgement message to the MAG with a status code
>       <IANA-TBA1> as defined in Section 6.2.
> 
> 
> and eventually error code <IANA-TBA1> "GRE Encapsulation NOT
> Supported" ?

If the LMA does not implement draft-ietf-netlmm-grekey-option-00.txt,
then it would actually skip processing the GRE Key Option, since it
wouldn't understand the mobility option. The MAG would automatically
know that the LMA does not support GRE encapsulation when it does not
see the GRE key option in the proxy binding ack from the LMA. Therefore,
there is no need for the status code "GRE Encapsulation not supported".

BTW, there is no status code for "GRE Encapsulation not supported" in
section 6.2. That section has the following two status codes.

   TBA1: GRE Encapsulation not required.

   TBA2: GRE Encapsulation and GRE Key option required.

I believe the above two status codes are required.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 24 Sep 2008 19:13:30 -0500

Hi Vijay,

> Subject: RE: [netlmm] A question about GRE-key draft
> 
> Hi Ahmad,
> 
> 
> then it would actually skip processing the GRE Key Option, 
> since it wouldn't understand the mobility option. The MAG 
> would automatically know that the LMA does not support GRE 
> encapsulation when it does not see the GRE key option in the 
> proxy binding ack from the LMA. Therefore, there is no need 
> for the status code "GRE Encapsulation not supported".

[Ahmad]
Hmmmm... I believe that originally we had the two error codes as you
pointed out below but later on we decide to replace TBA1 with "GRE
Encapsulation NOT Supported". On the other hand, we used the logic that
you just mentioned above to allow the LMA to indicate that "GRE
Encapsulation NOT Required" while sending a successful PBA.

Here the current text under section 4.2:

"
   o  If the mobile access gateway sent a Proxy Binding Update message
      with the GRE Key Option and the downlink GRE key included and
      received a successful PBA message without the GRE key option, the
      mobile access gateway MUST consider that GRE encapsulation and GRE
      keys is not required for this specific binding.  The MAG follows
      the Proxy Mobile IPv6 specification [RFC5213] for the handling of
      uplink and downlink traffic for this mobile node binding.
"
Please see more below.

> 
> BTW, there is no status code for "GRE Encapsulation not 
> supported" in section 6.2. That section has the following two 
> status codes.
> 

[Ahmad]
Okay, now in order to address the "GRE NOT supported and the GRE NOT
Required, what about the following:

1. We use the above logic to indicate that the LMA does NOT support GRE
encapsulation.
2. We continue to use status code "GRE Encapsulation NOT Required" BUT
mandate that this status code MUST be less than 128.
3. Continue to use "GRE Encapsulation and GRE Key Mobility Option
Required" as is.

What do you think?

Regards,
Ahmad

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 24 Sep 2008 21:06:29 -0400

Ahmad Muhanna wrote:
>       keys is not required for this specific binding.

The above is wrong. It should say 

      keys are not supported by the LMA.

If the LMA supports GRE encapsulation, it would not ignore the GRE Key
Option in the Proxy Binding Update. If the LMA thinks GRE encapsulation
should not be used for a specific binding, it indicates with "GRE
Encapsulation not required" status code in the Proxy Binding Ack.

>> supported" in section 6.2. That section has the following two status
>> codes. 
>> 

Ok.

> mandate that this status code MUST be less than 128.

So you are making it a successful binding but without the GRE
encapsulation? It works for me.

> 3. Continue to use "GRE Encapsulation and GRE Key Mobility Option

Ok. Sounds good.

Vijay

---

From: Wang Yungui <[email-masked]>
Date: Thu, 25 Sep 2008 10:46:49 +0800

Hi Vijay, Ahmad Muhanna

Sorry for plunging in. Ahmad Muhanna's statement seems
to sound more reasonable, I think.
The GRE key is an uni-directional tunnel ID. In some
cases, there maybe has downlink or uplink flow only.
So that the LMA does not always respond back the MAG
with the GRE key option, and vice versa. That's, w/o
GRE Key option in a PBU/PBA(successful) is not enough
to be considered that this option is supported or not by peer.
Perhaps some other explicited mechanism should be
further studied for the capability negotiation of the GRE
key option.

Regards,
Yungui Wang

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 25 Sep 2008 03:31:55 -0500

Hi Vijay,

Seems that we are in agreement. I will update the draft accordingly.

Regards,
Ahmad

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Thursday, September 25, 2008 3:06 AM
> To: Muhanna, Ahmad (RICH1:2H10); Soininen Jonne (NSN 
> FI/Espoo); [email-masked]
> since it 
> >> see the GRE key option in the proxy binding ack from the LMA. 
> >> Therefore, there is no need for the status code "GRE Encapsulation 
> >> not supported".
> > 
> > [Ahmad]
> > Encapsulation NOT Supported". On the other hand, we used the logic 
> > that you just mentioned above to allow the LMA to indicate 
> that "GRE 
> >       mobile access gateway MUST consider that GRE 
> encapsulation and 
> > GRE
> If the LMA supports GRE encapsulation, it would not ignore 
> the GRE Key Option in the Proxy Binding Update. If the LMA 
> thinks GRE encapsulation should not be used for a specific 
> binding, it indicates with "GRE Encapsulation not required" 
> status code in the Proxy Binding Ack.
> 
> supported" in

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 25 Sep 2008 03:31:12 -0500

Hi Yungui,

Well, I used this text to highlight what in the draft, however, If you
read through the rest of reply to Vijay, I agree this logic should be
used to indicate that the GRE Encapsulation is NOT supported.

The draft already mandates the return of the GRE Key Option in
successful PBA, if this functionality is supported. I do not see the
need for addressing the scenario of negotiating downlink GRE key only.
Any implementation which have that kind of scenario, can always return a
dummy uplink key for example.

Regards,
Ahmad

> From: Wang Yungui [mailto:[email-masked]] 
> Sent: Thursday, September 25, 2008 4:47 AM
> To: Vijay Devarapalli; Muhanna, Ahmad (RICH1:2H10); Soininen 
> Jonne (NSN FI/Espoo); [email-masked]
> Subject: Re: [netlmm] A question about GRE-key draft
> 
> Hi Vijay, Ahmad Muhanna
> 
> Sorry for plunging in. Ahmad Muhanna's statement seems to 
> sound more reasonable, I think.
> The GRE key is an uni-directional tunnel ID. In some cases, 
> there maybe has downlink or uplink flow only.
> So that the LMA does not always respond back the MAG with the 
> GRE key option, and vice versa. That's, w/o GRE Key option in 
> a PBU/PBA(successful) is not enough to be considered that 
> this option is supported or not by peer.
> Perhaps some other explicited mechanism should be further 
> studied for the capability negotiation of the GRE key option.
> 
> Regards,
> Yungui Wang
> 
> >>       received a successful PBA message without the GRE 
> key option, 
> >> the
> encapsulation and GRE
> the GRE Key 
> > Option in the Proxy Binding Update. If the LMA thinks GRE 
> > encapsulation should not be used for a specific binding, it 
> indicates 
> > with "GRE Encapsulation not required" status code in the 
> Proxy Binding Ack.
> >
> 
> 
> 
>