Subject: Re: [netlmm] Last call notice: draft-ietf-netlmm-grekey-option

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 05 Jan 2009 18:23:33 -0800

Hi Jonne,

Soininen Jonne (NSN FI/Espoo) wrote:
> <chair hat on>
> Everybody,
> 
> Hereby we would like to start the last-call on
> draft-ietf-netlmm-grekey-option. The last call is as follows:
> 
> Draft: draft-ietf-netlmm-grekey-option-02.txt
> Start: 8.12.2008
> End: 22.12.2008 (EOB PST)
> 
> Please, if you haven't done so, read the draft. If you have read, comment,
> and at least acknowledge your ok.

This review is coming late. The document is mostly ok. I have a few 
minor comments as described below. They should be addressed before the 
document is sent to the IESG.

>    Downlink Traffic
> 
>       The traffic in the tunnel between the local mobility anchor and
>       the mobile access gateway, heading towards the mobile access
>       gateway and tunneled at the local mobility anchor.  This traffic
>       is also called forward direction traffic.
> 
>    Uplink Traffic
> 
>       The traffic in the tunnel between the mobile access gateway and
>       the local mobility anchor, heading towards the local mobility
>       anchor and tunneled at the mobile access gateway.  This traffic is
>       also called reverse direction traffic.

The terms "forward direction traffic" and "reverse direction traffic" 
are not used anywhere else in the document. Suggest remove the last 
sentences in the two paragraphs above.

In section 3.2, re-write the following

>    To request GRE encapsulation support without exchanging the GRE keys,
>    the mobile access gateway MUST include the GRE Key option in the
>    Proxy Binding Update message sent to the local mobility anchor.  The
>    mobile access gateway MUST set the length field of the GRE Key option
>    to 2 octets.

>    If the local mobility anchor supports GRE encapsulation and after
>    successfully processes the Proxy Binding Update, the LMA sends a
>    Proxy Binding Acknowledgement and MUST include the GRE Key option
>    with the length field set to 2 octets.

as

    To request GRE encapsulation support, the mobile access gateway MUST
    include the GRE Key option in the Proxy Binding Update message sent
    to the local mobility anchor.  In case, the mobile access gateway
    wants to use GRE encapsulation without the GRE keys, it MUST NOT
    include the GRE Key Identifier in the option.

    If the local mobility anchor supports GRE encapsulation and the Proxy
    Binding Update processing is successful, the LMA sends a Proxy
    Binding Acknowledgement with the GRE Key option. If GRE encapsulation
    is being used without the GRE keys, the LMA MUST NOT include the GRE
    Key Identifier in the GRE option.

There is no need to refer to the length field here, since section 6.1 
talks about when to set the length to '6' and when to set it to '2'.

In section 3.3.1

>    When the mobile access gateway determines, based on, e.g., private
>    IPv4 address support [RFC1918], the MAG local policy, or the MAG-LMA
>    peer agreement, that GRE encapsulation is needed and GRE keys is
>    required, the mobile access gateway MUST include the GRE Key option
>    in the initial Proxy Binding Update message sent to the local
>    mobility anchor.

s/... and GRE keys is required/... and GRE keys are required/

In the same section

>    After successfully processes the initial Proxy Binding Update and

Should be "After successfully processing the ..."

The last paragraph of section 3.3.2 is very confusing. I couldn't parse it.

>    If the LMA receives a no handoff Binding Lifetime extension Proxy
>    Binding Update message with the GRE key option and the downlink GRE
>    key included from the same MAG that is currently hosting the
>    respected binding current pCoA, the LMA MUST NOT reject the Proxy
>    Binding Update because of the GRE key option being included in a
>    binding reregistration Proxy Binding Update message.  In this case,
>    the LMA processes the Proxy Binding Update normally and if the
>    included downlink GRE key is different than the one saved in the
>    respected BCE, the LMA MUST update the BCE with the new downlink GRE
>    key.

Suggest re-writing it as

   Typically, the MAG does not include the GRE Key Option in a Proxy
   Binding Update message sent to refresh an existing binding. However,
   if the LMA receives a Proxy Binding Update from the current MAG to
   extend the existing binding, and the Proxy Binding Update messages
   contains the GRE Key option and the downlink GRE Key identifier, it
   MUST NOT reject the Proxy Binding Update message. In this case,
   the LMA processes the Proxy Binding Update normally and if the
   included downlink GRE key is different than the one saved in the
   respected BCE, the LMA MUST update the BCE with the new downlink GRE
   key.

In section 4.2, replace the following

>    o  If the MAG has successfully negotiated and exchanged the initial
>       GRE keys with the LMA for a specific binding, the MAG SHOULD NOT
>       include the GRE Key option in the de-registration Proxy Binding
>       Update.

with

    o  The MAG SHOULD NOT include the GRE Key option in the
       de-registration Proxy Binding Update.

In section 5.2

>    o  After successfully processes a Proxy Binding Update message with

Should be "After successfully processing a ..."

In section 6

> 6.  Message Formats
> 
>    This section defines an extension to the Mobile IPv6 [RFC3775]
>    protocol messages.  The use of GRE Key option for supporting GRE
>    tunneling and GRE Key exchange for Proxy Mobile IPv6 is defined in
>    this document.

Delete the above paragraph since the paragraph that follows in section 
6.1 basically says the same.

Vijay

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

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 6 Jan 2009 09:54:55 -0600

Hi Vijay,
Please see comments inline.

Regards,
Ahmad

> > Please, if you haven't done so, read the draft. If you have read, 
> > comment, and at least acknowledge your ok.
> 
> This review is coming late. The document is mostly ok. I have 
> a few minor comments as described below. They should be 
> addressed before the document is sent to the IESG.
> 
> >    Downlink Traffic
> > 
> are not used anywhere else in the document. Suggest remove 
> the last sentences in the two paragraphs above.

[Ahmad]
If you recall, initially we were using these terms instead of downlink
and uplink. We agreed to use the most popular terms and at the same time
keep a reference to the replaced terms because some SDO is using them. I
believe there is no harm in keeping them:)

> There is no need to refer to the length field here, since 
> section 6.1 talks about when to set the length to '6' and 
> when to set it to '2'.

[Ahmad]
Fine with me.

> s/... and GRE keys is required/... and GRE keys are required/
[Ahmad]
Ok.

> Should be "After successfully processing the ..."

[Ahmad]
Ok. Thx.

>    respected BCE, the LMA MUST update the BCE with the new 

[Ahmad]
Sure. Looks fine to me.

>        de-registration Proxy Binding Update.
[Ahmad]
Well, in the case that GRE keys were never negotiated, the MAG MUST NOT
include the GRE key option in the de-registration. I believe the
clarification "If" clause is needed, but I am not going to dies for
keeping it:)

> Should be "After successfully processing a ..."
[Ahmad]
Ok. Thx.

> 6.1 basically says the same.

[Ahmad]
We discussed this before and agreed to keep it in order to ensure that
this option is an extension to RFC3775.

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 06 Jan 2009 10:51:33 -0800

Hi Ahmad,

> believe there is no harm in keeping them:)

Which SDO is using these terms? I just checked the 3GPP documents. They 
don't. Even if they do, I am sure the SDOs specs will be quickly fixed, 
unless they have already been published.

> this option is an extension to RFC3775.

Well, the paragraph that follows in section 6.1 says the same thing. It 
looks like redundant text.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 6 Jan 2009 13:59:05 -0600

Hi Vijay,

> > and uplink. We agreed to use the most popular terms and at the same 
> > time keep a reference to the replaced terms because some 
> SDO is using 
> > them. I believe there is no harm in keeping them:)
> 
> Which SDO is using these terms? I just checked the 3GPP 
> documents. They don't. Even if they do, I am sure the SDOs 
> specs will be quickly fixed, unless they have already been published.
>
[Ahmad] 
3GPP2 has been using these terminologies "reverse and forward" for a
long time.

Regards,
Ahmad
 
> Well, the paragraph that follows in section 6.1 says the same 
> thing. It looks like redundant text.

[Ahmad]
It may be, but people wanted to make the reference to RFC3775 explicit.
If you have a better suggestion we could consider that:)

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 6 Jan 2009 17:33:30 -0500

> 3GPP2 has been using these terminologies "reverse and forward" for a

Ok, lets keep them then.

Vijay

---

From: Yungui Wang <[email-masked]>
Date: Thu, 08 Jan 2009 15:53:04 +0800

Hi Ahmad,

The section 3.3.2 seems a bit complex for part of content is described the 
same as the initial PBU and some certain case may have been omitted. For 
example, at below paragraph,
"
   ...
   If the LMA receives handoff-triggered Binding Lifetime Extension
   Proxy Binding Update 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.
"
In a certain case, when the new MAG doesn't support GRE key option (implicitly 
known from the non-handoff binding update at before), I think, the LMA can directly 
accept this binding update without GRE encapsulation. 

So, proposed that a simple description is enough for the total section.
"
3.3.2.  GRE Key Exchange During Binding Re-registration

   In general, the MAG sends a Proxy Binding Update message to refresh 
   an existing binding which may or may not include the GRE Key Option.
   If the LMA receives a lifetime extension PBU message contains the GRE 
   Key option and the downlink GRE Key identifier, it MUST process the 
   PBU normally and if the included downlink GRE key is different than 
   the one saved in the respected BCE, the LMA MUST update the BCE 
   with the new downlink GRE key.

   However, if there is a handover, the new MAG and the LMA MUST operate 
   the GRE key option in the lifetime extension PBU as in the initial PBU 
   described in the section 3.3.1.
"

B.R.
Yungui

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 9 Jan 2009 09:31:47 -0600

Hi Yungui,
Thanks for reviewing the draft and your comment. 
Please see inline.

Regards, 
Ahmad

________________________________

	From: Yungui Wang [mailto:[email-masked]] 
	Sent: Thursday, January 08, 2009 1:53 AM
	To: Muhanna, Ahmad (RICH1:2H10)
	Cc: [email-masked]; Vijay Devarapalli
	Subject: Re: [netlmm] Last call notice:
draft-ietf-netlmm-grekey-option

	Hi Ahmad,
	 
	The section 3.3.2 seems a bit complex for part of content is
described the 
	same as the initial PBU and some certain case may have been
omitted. For 
	example, at below paragraph,
	"
	   ...
	   If the LMA receives handoff-triggered Binding Lifetime
Extension
	   Proxy Binding Update 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.
	"
	In a certain case, when the new MAG doesn't support GRE key
option (implicitly 
	known from the non-handoff binding update at before), I think,
the LMA can directly 
	accept this binding update without GRE encapsulation.  
	 
	[Ahmad]
	well, the fact that GRE keys have been negotiated and in use, it
needs to continue with GRE keys after handoff. What about if the GRE
keys are used for IPv4 overlapping? things will not work. 
	 
	So, proposed that a simple description is enough for the total
section.
	"
	3.3.2.  GRE Key Exchange During Binding Re-registration
	 
	   In general, the MAG sends a Proxy Binding Update message to
refresh 
	   an existing binding which may or may not include the GRE Key
Option.
	   If the LMA receives a lifetime extension PBU message contains
the GRE 
	   Key option and the downlink GRE Key identifier, it MUST
process the 
	   PBU normally and if the included downlink GRE key is
different than 
	   the one saved in the respected BCE, the LMA MUST update the
BCE 
	   with the new downlink GRE key.
	 
	   However, if there is a handover, the new MAG and the LMA MUST
operate 
	   the GRE key option in the lifetime extension PBU as in the
initial PBU 
	   described in the section 3.3.1.
	" 
	 
	[Ahmad]
	Please see the above comment. 
	The current text is the consensus of the wg after a very long
discussion and IMO, it should be changed only if there is a technical
issue.
	 
	B.R.
	Yungui

---

From: "jouni korhonen" <[email-masked]>
Date: Mon, 12 Jan 2009 14:12:07 +0200

Hi,

This is slightly lengthy review.. I do not have many, if any, real technical
comments as I think that part is now OK and the document is ready from
technical point of view. My comments are marked with [JiK]:

1.  Introduction

  The base Proxy Mobile IPv6 specification [RFC5213] and Proxy Mobile
  IPv6 support for IPv4 [ID-PMIP6-IPv4] allow the use of IPv6 and IPv4
  encapsulation modes [RFC2473] , [RFC2003] for the tunneled traffic

[JiK] s/[RFC2473] , [RFC2003]/[RFC2473][RFC2003]

  between the local mobility anchor and the mobile access gateway.

[JiK] Introduce the (LMA) and (MAG) acronyms here as they are used
     later in the draft.

  There are scenarios where these encapsulation modes are not
  sufficient to uniquely identify the destination of packets of a
  specific flow.  Thus, there is a need for an encapsulation mode with
  richer semantics.  The Generic Routing Encapsulation [RFC2784] and

[JiK] Introduce (GRE) as the acronym is used later in the draft.

  the Key extension as defined in [RFC2890], has the required semantics
  to allow such distinction for use in Proxy Mobile IPv6.

  This document defines the GRE Key option to be used for the
  negotiation of GRE encapsulation mode and the exchange of the uplink
  and downlink GRE keys.  The negotiated downlink and uplink GRE keys
  can be used for marking the downlink and uplink traffic for a
  specific mobile node session or a specific flow.

[JiK] "mobile node session".. I cannot find the definition for this
     neither in this draft or in RFC5213. I would suggest using
     something else that can be found in RFC5213 or the give a
     definition in Section 2.

2.2.  Terminology

  All the general mobility related terminology and abbreviations are to
  be interpreted as defined in Mobile IPv6 specification [RFC3775] and
  Proxy Mobile IPv6 specification [RFC5213].  The following terms are
  used in this document.

  Downlink Traffic

  Uplink Traffic

[JiK] Any specific reason to keep the "forward" and "reverse" direction
     traffic terms? They are not used anywhere in the rest of the
     draft. I would suggest removing them.

  Downlink GRE Key

     The GRE key is assigned by the mobile access gateway and used by
     the local mobility anchor to mark the downlink traffic which

[JiK] Section 3.1 uses term "downlink payload packet".. for the
     consistency I would suggest using the same term here.

     belongs to a specific mobile node session or flow as described in
     this document.

[JiK] The "mobile node session" again.

  Uplink GRE Key

     The GRE key is assigned by the local mobility anchor and used by
     the mobile access gateway to mark the uplink traffic which belongs
     to a specific mobile node session or flow as described in this
     document.

[JiK] Same comments are for the Downlink GRE Key.

3.1.  GRE Encapsulation Overview

  Using the GRE Key option defined in this specification, the mobile

[JiK] The draft uses both 'document' or 'specification' when referencing
itself.
      Use either of them.

  access gateway and the local mobility anchor can negotiate GRE
  encapsulation mode and exchange the GRE keys for marking the downlink
  and uplink traffic.

[JiK] Later in this section "uplink payload packet" etc are used. In general
      I found several terms saying about the same throughout the draft.
E.g.,
      uplink traffic, uplink payload packet, data packet, traffic flow,
      tunneled packet etc. I would suggest aligning the terminology. For
      example when talking about tunneled traffic I would suggest using
      term "uplink/downlink payload packets". I won't list places for the
      rest of the draft as they are so many.

[JiK] I would also like to state is somewhere more clearly that it is
      the "user traffic" that gets encapsulated inside the GRE headers
      and then tunneled inside the PMIP tunnel. It is there in the draft
      but imho could be said more clearly at the beginning of the draft.

  [snip]

  The LMA and the MAG will be able to distinguish each mobile node

[JiK] First uses of the LMA and the MAG. In general the draft uses
      names expanded and as acronyms inconsistently.. even using
      both conventions in the same sentence. I won't list them from
      now on as they are so many. Those should be change to be
      consistent.

  flow(s) based on the GRE key present in the GRE header of the
  tunneled packet, and route them accordingly.

3.3.  GRE Key Exchange Mechanism

  The following subsections describe how the mobile access gateway and
  the local mobility anchor exchange downlink and uplink GRE keys using
  proxy mobile IPv6 registration procedure.

[JiK] s/proxy mobile/Proxy Mobile

3.3.1.  Initial GRE Key Exchange

  mobility anchor.  The mobile access gateway MUST include the downlink

[JiK] The above is a rather long sentence. I would break it into smaller
      ones.

  GRE key in the GRE Key Identifier field of the GRE Key option.

[JiK] "After successfullt processes"..? who? Suggest rewriting
      "After the LMA has successfully processed.."

  accepting the downlink GRE key, the LMA MUST include the GRE Key
  option with the uplink GRE key in the GRE Key Identifier field when
  sending a successful Proxy Binding Acknowledgement to the MAG.

[JiK] This is rather complex one sentence paragraph. Suggest rewriting
      the whole paragraph:

 "After the LMA has successfully processed the initial Proxy Binding
  Update and accepted the downlink GRE key, the LMA sends a Binding
  Acknowledgement indicating a success to the MAG. The Binding
  Acknowledgement MUST include the GRE Key option with the uplink GRE
  Key in the GRE Key Identifier field.
 "

  If the MAG has successfully negotiated and exchanged the initial GRE
  keys with the LMA for a specific binding, the MAG SHOULD NOT include
  the GRE Key option with the downlink GRE key in the Proxy Binding
  Update which is used for requesting a Binding Lifetime Extension.

  However, during inter-MAG handoff and if the new mobile access
  gateway determines, based on, e.g., private IPv4 address support, the
  MAG local policy, the MAG-LMA peer agreement, or an indication during
  the handoff process, that GRE encapsulation and GRE key exchange is
  required, the new mobile access gateway MUST include the GRE key
  option with the downlink GRE key in the Proxy Binding Update which is
  used for requesting an after handoff Binding Lifetime extension.  In

[JiK] The above sentence is very long and thus hard to understand.
      I would suggest rewriting it. For example:

 "However, during inter-MAG handoff the new MAG MUST include the GRE
  key option with the downlink GRE key in the Proxy Binding Update if
  the GRE encapsulation and the GRE key exchange is required. The new
  MAG determines the GRE requirement e.g., based on private IPv4 address
  support, the MAG local policy, the MAG-LMA peer agreement, or an
  indication during the handoff process."

  this case, the new MAG may either pick a new downlink GRE key or use
  the downlink GRE key that was used by the previous MAG for the same
  binding.  For the new MAG to know the downlink GRE key used by the
  previous MAG, it may require transfer of context from the previous
  MAG to the new MAG during a handover.  Such mechanisms are out-of-
  scope for this document.

[JiK] Up to this point 'handoff' has been used. In the above paragraph
      'handover' is used instead.

  If the LMA successfully processes a handoff-triggered Binding
  Lifetime Extension Proxy Binding Update message which contains a GRE
  key option with a downlink GRE key included, the LMA MUST return the
  same uplink GRE key that was exchanged with the previous MAG and is
  saved in the respected BCE.

[JiK] Expand BCE on the first use. Also the sentence is a size of one
      paragraph.

[JiK] One sentence paragraph again.

[JiK] ".. a no handoff Binding.." A bit strange way to say this.
      Consider a better way of saying. However, I don't have a
      better wording in my mind now.

[JiK] Expand pCoA on the first use.

4.1.  Extensions to the Conceptual Data Structure

  Every mobile access gateway maintains a Binding Update List entry for

[JiK] BCE is already used in other places of the draft. Why not using
      Binding Update List (BUL) as well?

  each currently attached mobile node, as explained in Section 6.1 of
  the Proxy Mobile IPv6 specification [RFC5213].  To support this
  specification, the conceptual Binding Update List entry data
  structure must be extended with the following three new additional
  fields.

  o  A flag indicating whether GRE encapsulation is enabled for the
     mobile node's traffic flows.

  o  The Downlink GRE Key used in the GRE encapsulation header of the
     tunneled packet from the local mobility anchor to the mobile
     access gateway that is destined to the mobile node.  This GRE Key
     is generated by the MAG and communicated to the LMA in the GRE Key
     option in the Proxy Binding Update message.

[JiK] MAG and Mobile Access Gateway used interchangeably.

  o  The Uplink GRE Key used in the GRE encapsulation header of the
     tunneled packet from the mobile access gateway to the local

[JiK] tunneled payload packet?

     mobility anchor that is originating from the mobile node.  This
     GRE Key is obtained from the GRE Key Identifier field of the GRE
     Key option present in the received Proxy Binding Acknowledgement
     message sent by the LMA as specified in this document.

4.2.  Operational Summary

  o  If the MAG determines that GRE encapsulation and GRE key is
     required, the MAG MUST include the GRE Key option with the
     downlink GRE key in the GRE Key Identifier field in the Proxy
     Binding Update message that is sent by the mobile access gateway
     to the local mobility anchor.

[JiK] MAG and Mobile Access Gateway used interchangeably.

  o  After receiving a successful Proxy Binding Acknowledgment message
     with the GRE Key option which includes the uplink GRE key, the
     mobile access gateway MUST update the related three fields in the
     mobile node Binding Update List entry described in Section 4.1.
     Additionally, the MAG MUST use the assigned uplink GRE Key for
     tunneling all the traffic originating from the mobile node before
     forwarding the tunneled traffic to the LMA.

[JiK] tunneling all the payload packets originating..? Also
      MAG and Mobile Access Gateway used interchangeably.

  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.

[JiK] LMA and local mobility anchor used interchangeably.

  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 MAG does not support the
     GRE Key option, the MAG MAY log the event and possibly raise an
     alarm to indicate a possible misconfiguration.

[JiK] MAG and Mobile Access Gateway used interchangeably....

[snip]

5.2.  Operational Summary

[JiK] "After the LMA has successfully processed a Proxy Binding..."

     the GRE Key option which includes a downlink GRE key in the GRE
     Key Identifier field for Initial GRE Key exchange as in
     Section 3.3.1, the local mobility anchor MUST include the GRE Key
     option with the uplink GRE key in the GRE Key Identifier field
     when responding with a successful Proxy Binding Acknowledgement
     message.

  o  If the GRE tunneling is negotiated and the downlink and uplink GRE
     keys have been exchanged between the mobile access gateway and the
     local mobility anchor for a specific binding, the local mobility
     anchor MUST use the negotiated downlink GRE key in the GRE header
     of every packet that is destined to the mobile node of this
     specific binding over the GRE tunnel to the mobile access gateway.

[JiK] "..of every tunneled payload packet that is.." ?

  o  If the received Proxy Binding Update message does not contain the
     GRE Key option, and if the local mobility anchor determines that
     GRE encapsulation and GRE key is required, e.g., overlapping IPv4
     private addressing is in use, LMA local policy or LMA-MAG peer
     policy, the local mobility anchor MUST reject the request and send
     the Proxy Binding Acknowledgement message to the mobile access
     gateway with the status code <GRE KEY OPTION REQUIRED> as defined
     in Section 6.2, indicating that GRE encapsulation and GRE key is
     required.

[JiK] "..that GRE encapsulation and GRE key are required." ?

  o  If after receiving Proxy Binding Update message with the GRE Key
     option and successfully processes the Proxy Binding Update, the
     local mobility anchor determines that GRE encapsulation and key
     exchange is not required for this specific binding, e.g., private

[JiK] "..exchange are not.." ?

     IPv4 addressing is not in use, the LMA MUST send a Proxy Binding
     Acknowledgement message to the MAG with the status code <GRE KEY
     OPTION NOT REQUIRED>.  The local mobility anchor MUST NOT include
     the GRE Key option.

[JiK] "The local LMA MUST NOT include the GRE Key option in that Proxy
      Binding Acknowledgement." ?

[snip]

  o  On receiving a packet from the tunnel with the GRE encapsulation
     header, the local mobility anchor MUST use the GRE Key present in
     the GRE extension header to determine the necessary special
     processing for the data packet, e.g., lookup the mobile node's
     home gateway address, determine any special processing or
     treatment for the data packet flow, then remove the encapsulation
     header before forwarding the packet.

[JiK] "data packet"? How about using "payload packet" etc?

[snip]

  GRE Key Identifier

     32-bit field containing the Downlink or the Uplink GRE Key. This

[JiK] s/Downlink or the Uplink/downlink or the uplink

     field is present in the GRE Key option only if the GRE keys are
     being exchanged using the Proxy Binding Update and Proxy Binding
     Acknowledgement messages.

[JiK] Maybe it could be said again here that who puts and allocates
      uplink & downlink keys?

That's all for now.

Cheers,
       Jouni

On Tue, Dec 23, 2008 at 4:11 PM, Soininen Jonne (NSN - FI/Espoo) <
[email-masked]> wrote:
> Hello everybody,
>
> the last call time ended yesterday. It seems that there is no single mail
on
> the list on this last call. So, this WGLC is a failure. I will start a new
> last call after the holidays as this might have been missed due to the
> discussions on IPv4 support and the holiday preparations...
>
> Cheers,
>
> Jonne.
> ext Soininen Jonne (NSN FI/Espoo) wrote:
>>
>> <chair hat on>
>> Everybody,
>>
comment,
>> Vidya & Jonne
>> <chair hat off>

---

From: Yungui Wang <[email-masked]>
Date: Tue, 13 Jan 2009 12:01:31 +0800

Hi Ahmad,

There is an example case which may be deployed in the future network in my image. 
(3GPP) pMAG ====<GRE>======= LMA
                                                            //
(DSL) nMAG ====<MPLS>======
When a user moves from the pMAG to the nMAG, the negotiated GRE key may have 
to be changed into MPLS label. Therefore, the blow consideration seems to be useful. 
Thanks!

B.R.
Yungui
  ----- Original Message ----- 
  From: Ahmad Muhanna 
  To: Yungui Wang 
  Cc: [email-masked] ; Vijay Devarapalli 
  Sent: Friday, January 09, 2009 11:31 PM
  Subject: RE: [netlmm] Last call notice: draft-ietf-netlmm-grekey-option

  Hi Yungui,

----------------------------------------------------------------------------
    From: Yungui Wang [mailto:[email-masked]] 
    Sent: Thursday, January 08, 2009 1:53 AM
    To: Muhanna, Ahmad (RICH1:2H10)
    Cc: [email-masked]; Vijay Devarapalli
    Subject: Re: [netlmm] Last call notice: draft-ietf-netlmm-grekey-option

    Hi Ahmad,

    [Ahmad]
    well, the fact that GRE keys have been negotiated and in use, it needs to continue with GRE keys after handoff. What about if the GRE keys are used for IPv4 overlapping? things will not work. 

    [Ahmad]
    Please see the above comment. 
    The current text is the consensus of the wg after a very long discussion and IMO, it should be changed only if there is a technical issue.

    B.R.
    Yungui

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 15 Jan 2009 23:29:32 -0600

Hello Yungui,
Sorry for the late response.
 
In this scenario, the LMA is aware/configured that MPLS label is used to
differentiate between different flows with nMAG. In this case, what
about the following text which should address your concern:
 
   If the LMA receives handoff-triggered Binding Lifetime Extension
   Proxy Binding Update 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 the LMA is preconfigured to use a
different mechanism 
   other than GRE encapsulation with the nMAG which sent the
handoff-triggered 
   Binding Lifetime Extension Proxy Binding Update, the LMA MAY accept
the 
   PBU and if successfully processed return a successful PBA without the
GRE 
   Key option. In this case, mapping between the current GRE keys and
the other 
   mechanism identifiers or labels is outside the scope of this
specification.
 
would this work?

Regards, 
Ahmad 

	Sent: Monday, January 12, 2009 10:02 PM

	Hi Ahmad,
	 
	There is an example case which may be deployed in the future
network in my image.  
	(3GPP) pMAG ====<GRE>======= LMA
	                                                            //
	(DSL) nMAG ====<MPLS>======
	When a user moves from the pMAG to the nMAG, the negotiated GRE
key may have 
	to be changed into MPLS label. Therefore, the blow consideration
seems to be useful. 
	Thanks!
	 
	B.R.
	Yungui

		----- Original Message ----- 
		From: Ahmad Muhanna <mailto:[email-masked]>  
		To: Yungui Wang <mailto:[email-masked]>  
		Cc: [email-masked] ; Vijay Devarapalli
<mailto:[email-masked]>  
		Sent: Friday, January 09, 2009 11:31 PM
		Subject: RE: [netlmm] Last call notice:
draft-ietf-netlmm-grekey-option

		Hi Yungui,

		Regards, 
		Ahmad

			Hi Ahmad,
			 
			The section 3.3.2 seems a bit complex for part
of content is described the 
			same as the initial PBU and some certain case
may have been omitted. For 
			example, at below paragraph,
			"
			   ...
			   If the LMA receives handoff-triggered Binding
Lifetime Extension
			   Proxy Binding Update 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.
			"
			In a certain case, when the new MAG doesn't
support GRE key option (implicitly 
			known from the non-handoff binding update at
before), I think, the LMA can directly 
			accept this binding update without GRE
encapsulation.  
			 
			[Ahmad]
			well, the fact that GRE keys have been
negotiated and in use, it needs to continue with GRE keys after handoff.
What about if the GRE keys are used for IPv4 overlapping? things will
not work. 
			 
			So, proposed that a simple description is enough
for the total section.
			"
			3.3.2.  GRE Key Exchange During Binding
Re-registration
			 
			   In general, the MAG sends a Proxy Binding
Update message to refresh 
			   an existing binding which may or may not
include the GRE Key Option.
			   If the LMA receives a lifetime extension PBU
message contains the GRE 
			   Key option and the downlink GRE Key
identifier, it MUST process the 
			   PBU normally and if the included downlink GRE
key is different than 
			   the one saved in the respected BCE, the LMA
MUST update the BCE 
			   with the new downlink GRE key.
			 
			   However, if there is a handover, the new MAG
and the LMA MUST operate 
			   the GRE key option in the lifetime extension
PBU as in the initial PBU 
			   described in the section 3.3.1.
			" 
			 
			[Ahmad]
			Please see the above comment. 
			The current text is the consensus of the wg
after a very long discussion and IMO, it should be changed only if there
is a technical issue.
			 
			B.R.
			Yungui

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 26 Jan 2009 23:19:38 -0600

Hello Yungui,
 
You are the only one interested in this issue but I never heard back
from you.
Are you okay with the proposed text?
 
I have not heard from anyone else and if you are no longer interested in
this, I will leave this out and not include it in the next updated draft
version.

Regards, 
Ahmad 

	From: Muhanna, Ahmad (RICH1:2H10) 
	Sent: Thursday, January 15, 2009 11:30 PM
	To: 'Yungui Wang'
	Cc: [email-masked]'; 'Vijay Devarapalli'
	Subject: RE: [netlmm] Last call notice:
draft-ietf-netlmm-grekey-option

	Hello Yungui,
	 
	In this scenario, the LMA is aware/configured that MPLS label is
used to differentiate between different flows with nMAG. In this case,
what about the following text which should address your concern:

	   If the LMA receives handoff-triggered Binding Lifetime
Extension
	   Proxy Binding Update 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 the LMA is preconfigured to use a
different mechanism 
	   other than GRE encapsulation with the nMAG which sent the
handoff-triggered 
	   Binding Lifetime Extension Proxy Binding Update, the LMA MAY
accept the 
	   PBU and if successfully processed return a successful PBA
without the GRE 
	   Key option. In this case, mapping between the current GRE
keys and the other 
	   mechanism identifiers or labels is outside the scope of this
specification.
	 
	would this work?

	Regards, 
	Ahmad 

		Hi Ahmad,
		 
		There is an example case which may be deployed in the
future network in my image.  
		(3GPP) pMAG ====<GRE>======= LMA
	
//
		(DSL) nMAG ====<MPLS>======
		When a user moves from the pMAG to the nMAG, the
negotiated GRE key may have 
		to be changed into MPLS label. Therefore, the blow
consideration seems to be useful. 
		Thanks!
		 
		B.R.
		Yungui

			----- Original Message ----- 

			Hi Yungui,

			Please see inline.

			Regards, 
			Ahmad

				From: Yungui Wang
[mailto:[email-masked]] 

				Hi Ahmad,
				 
				The section 3.3.2 seems a bit complex
for part of content is described the 
				same as the initial PBU and some certain
case may have been omitted. For 
				example, at below paragraph,
				"
				   ...
				   If the LMA receives handoff-triggered
Binding Lifetime Extension
				   Proxy Binding Update 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.
				"
				In a certain case, when the new MAG
doesn't support GRE key option (implicitly 
				known from the non-handoff binding
update at before), I think, the LMA can directly 
				accept this binding update without GRE
encapsulation.  
				 
				[Ahmad]
				 
				So, proposed that a simple description
is enough for the total section.
				"
				3.3.2.  GRE Key Exchange During Binding
Re-registration
				 
				   In general, the MAG sends a Proxy
Binding Update message to refresh 
				   an existing binding which may or may
not include the GRE Key Option.
				   If the LMA receives a lifetime
extension PBU message contains the GRE 
				   Key option and the downlink GRE Key
identifier, it MUST process the 
				   PBU normally and if the included
downlink GRE key is different than 
				   the one saved in the respected BCE,
the LMA MUST update the BCE 
				   with the new downlink GRE key.
				 
				   However, if there is a handover, the
new MAG and the LMA MUST operate 
				   the GRE key option in the lifetime
extension PBU as in the initial PBU 
				   described in the section 3.3.1.
				" 
				 
				[Ahmad]
				Please see the above comment. 
				The current text is the consensus of the
wg after a very long discussion and IMO, it should be changed only if
there is a technical issue.
				 
				B.R.
				Yungui

---

From: [email-masked]
Date: Wed, 28 Jan 2009 13:29:49 +0800

Hello Ahmad,

Sorry for late response. The proposed text is fine with me. Thanks!

B.R.
Yungui 

----- Original Message -----
From: Ahmad Muhanna <[email-masked]>
Date: Tuesday, January 27, 2009 1:21 pm
Subject: RE: [netlmm] Last call notice: draft-ietf-netlmm-grekey-option
To: Ahmad Muhanna <[email-masked]>, Yungui Wang <[email-masked]>
Cc: [email-masked], Vijay Devarapalli <[email-masked]>, Frank Xia <[email-masked]>, Behcet Sarikaya <[email-masked]>

> this, I will leave this out and not include it in the next updated 
> draftversion.
> 
> Regards, 
> Ahmad 
> 
> 
> 
> 
>           mechanism identifiers or labels is outside the scope of 
> thisspecification.
>         
> 	would this work?
> 
> 	Regards, 
> 	Ahmad 
> 
>         
> 
> 
>                                   If the LMA receives handoff-
> triggeredBinding Lifetime Extension
>                                   Proxy Binding Update message 
> withoutthe GRE key option for a BCE
> negotiated and in use, it needs to continue with GRE keys after 
> handoff.What about if the GRE keys are used for IPv4 overlapping? 
> things will
> not work. 
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 28 Jan 2009 02:54:29 -0600

Thanks Yungui.
Will publish the draft soon.

Regards,
Ahmad

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, January 27, 2009 11:30 PM
> Cc: [email-masked]; Vijay Devarapalli; Frank Xia; Behcet Sarikaya
> Subject: Re: RE: [netlmm] Last call notice: 
> Cc: [email-masked], Vijay Devarapalli <[email-masked]>, 
> Frank Xia <[email-masked]>, Behcet Sarikaya 
> <[email-masked]>
> 
> > Hello Yungui,
> > 
> > I have not heard from anyone else and if you are no longer 
> interested 
> > in this, I will leave this out and not include it in the 
> next updated 
> > draftversion.
> > 
> > Regards,
> > Ahmad
> > 
> > 
> > 
> > 
> > 	In this scenario, the LMA is aware/configured that MPLS 
> label is used 
> > to differentiate between different flows with nMAG. In this 
> case, what 
> >           Proxy Binding Update message without the GRE key 
> option for 
> > a BCE
> >        	When a user moves from the pMAG to the nMAG, 
> the negotiated 
> > GRE key may have
> >                        	So, proposed that a simple 
> description is 
> > enough for the total section.
> >                        	"
> > after a very long discussion and IMO, it should be changed only if

---

From: "Soininen, Jonne (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 28 Jan 2009 12:24:04 +0200

Excellent,

I'm looking forward to see the new version!

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia Siemens Networks

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

---

From: Conny Larsson <[email-masked]>
Date: Fri, 30 Jan 2009 08:33:35 +0100

Hi Ahmad,

I have read draft-ietf-netlmm-grekey-option-03 and I believe you have 
done a good work and it looks fine to me. However, I have one question. 
You are writing on several places that the LMA and MAG are negotiating 
GRE encapsulation mode. What does this mean? If you add the GRE option 
then you have support for GRE, with or without GRE keys. Is the presence 
(or not) of GRE keys the GRE encapsulation mode you are referring to or 
is it something else.

Regards
Conny

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 30 Jan 2009 01:42:14 -0600

Hi Conny,

There was a long discussion on the mailing list regarding this issue,
There was a usecase where the MAG and the LMA would like to
negotiate/use GRE Encapsulation only without dynamically exchanging
downlink and uplink GRE keys. In other words, there could be some static
GRE keys to be used.

So, the inclusion of the GRE Key option with the length field is set to
2 or in other words without the downlink GRE Key in the GRE Key
Identifier means that the MAG is requesting the negotiation of the GRE
encapsulation mode only. This also means that the LMA will not return
the uplink GRE key in the PBA.

I hope this background help in clarifying your question.

Regards,
Ahmad

> From: Conny Larsson [mailto:[email-masked]] 
> Sent: Friday, January 30, 2009 1:34 AM
> Cc: [email-masked]
> I have read draft-ietf-netlmm-grekey-option-03 and I believe 
> you have done a good work and it looks fine to me. However, I 
> have one question. 
> You are writing on several places that the LMA and MAG are 
> negotiating GRE encapsulation mode. What does this mean? If 
> you add the GRE option then you have support for GRE, with or 
> without GRE keys. Is the presence (or not) of GRE keys the 
> GRE encapsulation mode you are referring to or is it something else.
> 
> Regards
> Conny
> 
>

---

From: Conny Larsson <[email-masked]>
Date: Fri, 30 Jan 2009 11:36:12 +0100

Hi Ahmad,

Thanks for your response. Yes it helps to clarify.

Regards
Conny