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

From: [email-masked]
Date: Mon, 25 Aug 2008 11:15:02 -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-00.txt
	Pages           : 15
	Date            : 2008-08-24

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 tunnel peers can
process individual flows differently.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netlmm-grekey-option-00.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: Mon, 25 Aug 2008 13:42:18 -0500

Hello Folks,

The 00 revision of the GRE Key Option for PMIPv6 wg document has
been published.  In this revision the following comments have been
addressed.  Please take a look and let us know if you have any
comments or if we missed anything. 

many thanks in advance for your review and comments.

Here is a list of the addressed comments:

1.  Addressed all of Charlie's detailed comments.

2.  Addressed the case of the missing text regarding the LMA
    capability to send a successful PBA when GRE encapsulation is NOT
    needed, i.e. without including the GRE Key option in the PBA.

3.  Captured the consensus regarding the handling of GRE Key Exchange
    During Binding Re-registration and De-registration.

4.  Restrict only the uplink GRE key in the GRE Key option in the
    PBA.

5.  Ensured that the use of GRE Key option is an extension to RFC3775
    and its use is not restricted to IPv4 private address usecase. 

6.  Finally, added some text to address the error case when the MAG
    does not support GRE encapsulation while the LMA requires such
    capability for that specific binding. 

Regards,
Ahmad

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Monday, August 25, 2008 1:15 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [netlmm] I-D Action:draft-ietf-netlmm-grekey-option-00.txt
> 
> This draft is a work item of the Network-based Localized 
> Mobility Management Working Group of the IETF.
> 
> 
> 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 tunnel peers can process individual flows differently.
> 
> 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: Mon, 25 Aug 2008 16:43:14 -0400

Hi Ahmad,

A couple of minor comments. In section 3.3.2, you have the following
text.

   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 MAG 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 this
   case, the downlink GRE key may be identical to the downlink GRE key
   that the previous MAG has exchanged with the LMA for the same
   binding. 

It is not clear what the last sentence is trying to say. If there is a
transfer of context from the previous MAG to the new MAG, then the
downlink GRE key would be the same. Otherwise, it is going to be
different. The new MAG would pick a new downlink GRE key.
 
There are a few instances of "an after handoff Binding Lifetime
Extension PBU message". It should be replaced by "handoff-triggered
Binding Lifetime Extension PBU message". The phrase "an after handoff...
" is not clear. It could be at any time after the handover, not
immediately after the handover :)

Looks good otherwise.

Vijay

> From: Ahmad Muhanna [mailto:[email-masked]] 
> Sent: Monday, August 25, 2008 11:42 AM
> To: [email-masked]
> Cc: Vijay Devarapalli; Charles E. Perkins; Julien Laganier; 
> Basavaraj Patil
> Subject: RE: [netlmm] I-D 
> Action:draft-ietf-netlmm-grekey-option-00.txt
> 
> 
> Hello Folks,
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 25 Aug 2008 15:55:45 -0500

Hi Vijay,

Thanks for the quick review and comments! 
Please see inline.

Regards,
Ahmad

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Monday, August 25, 2008 3:43 PM
> To: Muhanna, Ahmad (RICH1:2H10); [email-masked]
> Cc: Charles E. Perkins; Julien Laganier; Basavaraj Patil
> A couple of minor comments. In section 3.3.2, you have the 
> following text.
> 
> It is not clear what the last sentence is trying to say. If 
> there is a transfer of context from the previous MAG to the 
> new MAG, then the downlink GRE key would be the same. 
> Otherwise, it is going to be different. The new MAG would 
> pick a new downlink GRE key.

[Ahmad]
Actually the intention was to capture the case you just mentioned and
the case when the next MAG picks a downlink GRE key that happens to be
the same GRE key that the previous MAG was using. All what the above
sentence is trying to say that these cases are possible and the LMA
needs to make a note of. In other words, the LMA does not necessarily
need to expect the downlink GRE key to be different upon inter-MAG
handoff.

>  
> There are a few instances of "an after handoff Binding 
> Lifetime Extension PBU message". It should be replaced by 
> "handoff-triggered Binding Lifetime Extension PBU message". 
> The phrase "an after handoff...
> " is not clear. It could be at any time after the handover, 
> not immediately after the handover :)

[Ahmad]
No problem. Your suggestion sounds better!

> Looks good otherwise.

[Ahmad]
Thanks!

> Basavaraj 
> > Patil
> > The 00 revision of the GRE Key Option for PMIPv6 wg 
> document has been 
> > published.  In this revision the following comments have been 
> > > Subject: [netlmm] I-D 
> > > A New Internet-Draft is available from the on-line 
> Internet-Drafts 
> > > directories.
> > > 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 
> > > 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 tunnel peers can process individual flows differently.
> > >

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 25 Aug 2008 17:12:21 -0400

Hi Ahmad,
 
> need to expect the downlink GRE key to be different upon inter-MAG

Ok. I suggest slight re-wording of the text, then. Replace

   In this

with

   In 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.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 25 Aug 2008 16:30:53 -0500

Hi Vijay.

>    are out-of-scope for this document.

[Ahmad]
Looks good. Thanks!