Subject: [netlmm] Comments on draft-muhanna-netlmm-grekey-option-02.txt

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 23 Jun 2008 17:31:17 -0700

Hello,

I read through draft-muhanna-netlmm-grekey-option and have a few 
comments. Mostly minor. A couple of major ones.

>    The Proxy Mobile IPv6 base specification defined in [PMIP6-ID] allows
>    the mobile node's IPv4 and IPv6 traffic between the local mobility
>    anchor and the mobile access gateway to be tunneled using IPv6, IPv4
>    or IPv4-UDP encapsulation headers.  These encapsulation modes do not
>    offer semantics for the tunnel end-points 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 extensions defined in this

s/IPv4 addressing/IPv4 addresses/

>    document allow the mobile access gateway and the local mobility
>    anchor to negotiate GRE encapsulation mode and along with the GRE

s/mode and along/mode, along/

>    symmetric key or asymmetric keys for marking the flows, so that
>    differential processing can be applied by the tunnel peers over those
>    flows.

>    The base Proxy Mobile IPv6 specification allows the use of IPv6, IPv4
>    or IPv4-UDP encapsulation modes for the tunneled traffic between the
>    local mobility anchor and the mobile access gateway.  There are
>    scenarios where these encapsulation modes are not sufficient and
>    there is a need for an encapsulation mode with richer semantics.  The
>    Generic Routing Encapsulation [RFC-2784] and coupled with the Key and

s/and coupled/coupled

>    Sequence Number extension [RFC-2890], has the required semantics for

required semantics for what? The entire paragraph is a bit vague since 
it first claims that there is a need for an encapsulation mode with 
richer semantics and then concludes that GRE encapsulation has the 
required semantics. There is nothing about what the semantics are.

>    Forward Direction 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.
> 
>    Reverse Direction 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.

Would it make sense to use downlink and uplink traffic? I found it hard 
to read the text later on in the draft where the "forward traffic" and 
"reverse traffic" terminology is used. Not a big deal, though.

>    Using the extension defined in this specification, the mobile access
>    gateway and the local mobility anchor can negotiate GRE encapsulation
>    mode along with the GRE keys for marking the forward and reverse
>    traffics.

s/traffics/traffic

>    o  Upon receiving a Proxy Binding Update message with the GRE Key
>       Identifier Option, 

The GRE Key Identifier Option is mentioned for the first time here. 
There should be a paragraph earlier on that describes the use of the GRE 
Key Identifier Option to carry the necessary GRE keys in the Proxy BU 
and Proxy BAck.

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

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

>    For requesting the GRE Tunneling support, the mobile access gateway
>    MUST include the GRE Key Identifier Option in the Proxy Binding
>    Update message sent to the local mobility anchor.  In case the mobile
>    access gateway local policy requires the MAG to generate the forward
>    direction GRE key, the MAG must include the forward key in the GRE
>    key Identifier Option.  

Ok.

> Optionally, the MAG may set the GRE key
>    Identifier field in the GRE key Identifier Option to zero to indicate
>    that the MAG will accept either symmetric or asymmetric GRE keys as
>    specified by the LMA.  

You probably need a sentence before this to say that in case the MAG 
wants the LMA to generate the keys, it does not include a key generated 
at the MAG locally. Instead it sets to the key to either '0' or all '1's.

> In the case the MAG requires the LMA to
>    specify two asymmetric keys, the MAG will set the GRE Key Identifier
>    field in the GRE Key Identifier option to all-ones.  In the case of
>    symmetric keys, the LMA must return one single key in the GRE Key
>    Identifier option.  However, in the case of asymmetric GRE keys, the
>    LMA must send two GRE keys in the GRE Key Identifier option, with the
>    first key being the forward direction key and the second is the
>    reverse direction key.  In the latter case, the GRE Key Identifier
>    option length MUST be set to 10.

I don't see symmetric/asymmetric keys described in RFC 2890. I guess 
they are defined in this document for the first time. If so, it might be 
a good idea to describe what they mean very early on in the document.

>    Every mobile access gateway maintains a Binding Update List for each
>    currently attached mobile node, as explained in Section 6.2 of the
>    base Proxy Mobile IPv6 specification [PMIP6-SPEC].  

The MAG maintains a binding update list entry per mobile node, not a 
binding update list per mobile node. This paragraph needs to be re-written.

>       If the
>       MAG includes the forward key in the GRE Key Identifier Option, the
>       local mobility anchor must use this key to identify the mobile
>       node's traffic encapsulated in a GRE header as specified in the
>       GRE specification [RFC-2784] and using the GRE Key and Sequence
>       Number extension [RFC-2890] with the assigned GRE key.

I couldn't parse this sentence. I couldn't come up with alternate text, 
since I couldn't figure out what is being said in this paragraph.

>    [RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
>    IPv6 Specification", RFC 2473, December 1998.

This is not referenced anywhere in the document.

>    [RFC-3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
>    Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents",
>    RFC 3776, June 2004.

This reference is not relevant to this document.

>    [RFC-4303] Kent, S. "IP Encapsulating Security Protocol (ESP)", RFC
>    4303, December 2005.

This one is not relevant either.

>    [RFC-2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
>    IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
> 
>    [RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
>    (IPv6) Specification", RFC 2460, December 1998.
> 
>    [RFC-3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
>    August 2002.
> 
>    [RFC-4301] Kent, S. and Atkinson, R., "Security Architecture for the
>    Internet Protocol", RFC 4301, December 2005.
> 
>    [MIP4-GREKEY-SPEC] Yegani, P. et.al, "GRE Key Extension for Mobile
>    IPv4", draft-yegani-gre-key-extension-02.txt (Work in progress),
>    September 2007.

None of the five references above are used in the document. :)

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

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 24 Jun 2008 08:57:58 -0500

Hi Vijay,

My apologies, I guess it is due to update this draft ASAP. I will. 
Please see further responses inline.

Regards,
Ahmad

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Monday, June 23, 2008 7:31 PM
> To: Muhanna, Ahmad (RICH1:2H10); Khalil, Mohamed 
> (RICH2:2S20); Sri Gundavelli; [email-masked]; [email-masked]
> Subject: Comments on draft-muhanna-netlmm-grekey-option-02.txt
> 
> Hello,
> 
> I read through draft-muhanna-netlmm-grekey-option and have a 
> few comments. Mostly minor. A couple of major ones.
> 
> >    Generic Routing Encapsulation [RFC-2784] and coupled 
> with the Key 
> > and
> 
> s/and coupled/coupled
> 
> required semantics for what? The entire paragraph is a bit 
> vague since it first claims that there is a need for an 
> encapsulation mode with richer semantics and then concludes 
> that GRE encapsulation has the required semantics. There is 
> nothing about what the semantics are.
[Ahmad]
Will take care of this one.

> Would it make sense to use downlink and uplink traffic? I 
> found it hard to read the text later on in the draft where 
> the "forward traffic" and "reverse traffic" terminology is 
> used. Not a big deal, though.
> 
> There should be a paragraph earlier on that describes the use 
> of the GRE Key Identifier Option to carry the necessary GRE 
> keys in the Proxy BU and Proxy BAck.
[Ahmad]
Agree.
> This paragraph assumes that GRE encapsulation is used only if 
> there is overlapping IPv4 address space. I believe GRE 
> encapsulation is used for other reasons also (for identifying 
> flows for example) in 3GPP. I suggest removing this status 
> code. Or at least explain in more detail when the LMA might 
> think GRE encapsulation is unnecessary.

[Ahmad]
Absolutely. will take care of this too.

> You probably need a sentence before this to say that in case 
> the MAG wants the LMA to generate the keys, it does not 
> include a key generated at the MAG locally. Instead it sets 
> to the key to either '0' or all '1's.

[Ahmad]
So far, all the feedback we received was to simplify this mechanism and
allow the MAG to always generate downlink GRE key and the LMA the
uplink. Do you see a need to keep the option on the LMA generating both
keys?
 
> I don't see symmetric/asymmetric keys described in RFC 2890. 
> I guess they are defined in this document for the first time. 
> If so, it might be a good idea to describe what they mean 
> very early on in the document.

[Ahmad]
Yes, if we keep both, then we will.
> The MAG maintains a binding update list entry per mobile 
> node, not a binding update list per mobile node. This 
> paragraph needs to be re-written.

[Ahmad]
Sure.
> I couldn't parse this sentence. I couldn't come up with 
> alternate text, since I couldn't figure out what is being 
> said in this paragraph.

[Ahmad]
I guess what we are trying to say that the negotiated GRE key will be
used for distinguishing the user traffic. Will make sure that the
correct meaning is reflected. 
> None of the five references above are used in the document. :)

[Ahmad]
Will fix it. Thanks!

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 24 Jun 2008 08:18:09 -0700 (PDT)

Hi Julien,

>
> Also, shouldn't the Binding Cache Entry data structure on the LMA be extended 
> as well?
>

Yes, we need to extend BCE and BUL entries. We missed it for BCE. Will be
fixed.

Thanks
Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 24 Jun 2008 10:18:47 -0500

Hello Julien.
Please see inline.

Regards,
Ahmad

> From: julien laganier [mailto:[email-masked]] On 
> Behalf Of Julien Laganier
> Sent: Tuesday, June 24, 2008 10:11 AM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: Vijay Devarapalli; Khalil, Mohamed (RICH2:2S20); Sri 
> Gundavelli; [email-masked]; [email-masked]
> Subject: Re: [netlmm] Comments on 
> draft-muhanna-netlmm-grekey-option-02.txt
> 
> Hello Ahmad,
> 
> One more comment from my side below.
> 
> --julien
> 
> > 5.1. Extensions to the Conceptual Data Structure
> > 
> > 
> >    base Proxy Mobile IPv6 specification [PMIP6-SPEC].  The Binding
> >    Update List is a conceptual data structure, described in 
> Section 11.1
> >    of the Mobile IPv6 base specification [RFC-3775].  For supporting
> >    this specification, the conceptual Binding Update List 
> data structure
> >    must be extended with the following two new additional 
> fields related
> >    to bi-directional GRE Key identifiers used for tagging the mobile
> >    node's tunneled traffic.
> 
> Isn't that three fields below - reverse key, forward key, and 
> the flag?

[Ahmad]
You are correct. But probably we can use the fields for Reverse and
Forward GRE keys as an indication for GRE encapsulation being enabled
and that will eliminate the flag field. What do you think?

> 
> Also, shouldn't the Binding Cache Entry data structure on the 
> LMA be extended as well?

[Ahmad]
Agreed.

> 
> >    o  A flag indicating whether GRE encapsulation is enabled for the
> >       mobile node's traffic flows.
> > 
> >    o  The Reverse GRE Key Identifier used in the GRE encapsulation
> >       header of the tunneled packet from the mobile access 
> gateway to
> >       the local mobility anchor and that is originating 
> from the mobile
> >       node.  This GRE Key identifier is obtained from the GRE Key
> >       Identifier Option present in the received Proxy Binding
> >       Acknowledgement message sent by the local mobility anchor as
> >       specified in this document.
> > 
> >    o  The Forward GRE Key Identifier used in the GRE encapsulation
> >       header of the tunneled packet from the local mobility 
> anchor to
> >       the mobile access gateway and that is destined to the 
> mobile node.
> >       This GRE Key identifier may be a locally configured key or as
> >       specified by the LMA as per this specification.  This key
> >       identifier may be the same as the reverse direction 
> key used for
> >       the outgoing flows from the mobile access gateway to the local
> >       mobility anchor.
> 
> 
> 
> Ahmad Muhanna wrote:
> > Hi Vijay,
> > 
> >> To: Muhanna, Ahmad (RICH1:2H10); Khalil, Mohamed (RICH2:2S20); Sri 
> >> Gundavelli; [email-masked]; [email-masked]
> >>>    overlapping private IPv4 addressing.  The extensions 
> defined in 
> >>> this
> >>>    Sequence Number extension [RFC-2890], has the required 
> semantics 
> >>> for
> >> required semantics for what? The entire paragraph is a bit vague 
> >> since it first claims that there is a need for an 
> encapsulation mode 
> >> with richer semantics and then concludes that GRE 
> encapsulation has 
> >> the required semantics. There is nothing about what the semantics 
> >> are.
> > [Ahmad]
> >> Would it make sense to use downlink and uplink traffic? I found it 
> >> hard to read the text later on in the draft where the "forward 
> >> traffic" and "reverse traffic" terminology is used. Not a 
> big deal, 
> >> though.
> >>
> >> There should be a paragraph earlier on that describes the 
> use of the 
> >> GRE Key Identifier Option to carry the necessary GRE keys in the 
> >> Proxy BU and Proxy BAck.
> > [Ahmad]
> > Agree.
> >> This paragraph assumes that GRE encapsulation is used only 
> if there 
> >> is overlapping IPv4 address space. I believe GRE encapsulation is 
> >> used for other reasons also (for identifying flows for example) in 
> >> 3GPP. I suggest removing this status code. Or at least explain in 
> >> more detail when the LMA might think GRE encapsulation is 
> >> unnecessary.
> > 
> > [Ahmad]
> >> wants the LMA to generate the keys, it does not include a key 
> >> generated at the MAG locally. Instead it sets to the key to either 
> >> '0' or all '1's.
> > 
> > [Ahmad]
> > So far, all the feedback we received was to simplify this mechanism 
> > and allow the MAG to always generate downlink GRE key and 
> the LMA the 
> > uplink. Do you see a need to keep the option on the LMA generating 
> > both keys?
> >  
> node, not a 
> >> I couldn't parse this sentence. I couldn't come up with alternate 
> >> text, since I couldn't figure out what is being said in this 
> >> paragraph.
> > 
> > [Ahmad]

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 24 Jun 2008 10:31:19 -0500

> 
> Ahmad Muhanna wrote:
> > Hello Julien.
> > Please see inline.
> 
> Same here,
> 
> >>> For supporting this specification, the conceptual Binding Update 
> >>> List data structure must be extended with the following two new 
> >>> additional fields related to bi-directional GRE Key 
> identifiers used 
> >>> for tagging the mobile node's tunneled traffic.
> >>
> >> Isn't that three fields below - reverse key, forward key, and the 
> >> flag?
> > 
> > [Ahmad]
> To do that it seems you'd need to define a special GRE key 
> value that is never used on the wire and used to indicate 
> absence of GRE tunneling when present in the data structure field...

[Ahmad]
I see your point. I guess leaving the flag would be cleaner then. 
Thx.

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 24 Jun 2008 08:33:14 -0700 (PDT)

Vijay,

On Mon, 23 Jun 2008, Vijay Devarapalli wrote:

> required semantics for what? The entire paragraph is a bit vague since it 
> first claims that there is a need for an encapsulation mode with richer 
> semantics and then concludes that GRE encapsulation has the required 
> semantics. There is nothing about what the semantics are.
>

- Base PMIP defines IPv6-in-IPv6 encap only mode
- We need to notify the peer for other identifiers in the data path
- 2890 gives the capability for carrying a GRE key
- Hence, the case for requiring GRE.

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

Agree, this is just one use case. It can be enabled for other reasons.

>
> The MAG maintains a binding update list entry per mobile node, not a binding 
> update list per mobile node. This paragraph needs to be re-written.
>

Remember the discussion on, if MAG needs to maintain BUL table per mobile
node or a BUL entry per mobile ? Earlier versions of the base draft were
referring to BUL table per mobile. This is still reflecting that. It
should be fixed.

> This one is not relevant either.

It is relevant here. We are talking about a new encap mode. This has a
bearing on how the message is protected. Any case, once the draft is
cleaned up, it should have the right references.

Sri

---

From: Julien Laganier <[email-masked]>
Date: Tue, 24 Jun 2008 18:02:46 +0200

Hello Ahmad,

--julien

>    Update List is a conceptual data structure, described in Section 11.1
>    this specification, the conceptual Binding Update List data structure
>    must be extended with the following two new additional fields related

Isn't that three fields below - reverse key, forward key, and the flag?

Also, shouldn't the Binding Cache Entry data structure on the LMA be
extended as well?

>       header of the tunneled packet from the mobile access gateway to
>       the local mobility anchor and that is originating from the mobile
>       header of the tunneled packet from the local mobility anchor to
>       the mobile access gateway and that is destined to the mobile node.
>       identifier may be the same as the reverse direction key used for

---

From: Julien Laganier <[email-masked]>
Date: Tue, 24 Jun 2008 18:03:04 +0200

Same here,

>>> For supporting this specification, the conceptual Binding Update List 
>>> data structure must be extended with the following two new additional 
>>> fields related to bi-directional GRE Key identifiers used for tagging the mobile
>>> node's tunneled traffic.
>>

To do that it seems you'd need to define a special GRE key value that is
never used on the wire and used to indicate absence of GRE tunneling
when present in the data structure field...

--julien

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 24 Jun 2008 12:24:13 -0400

Hi Ahmad,

Looks like we have agreement on most of the comments I sent.

> > traffic" and "reverse traffic" terminology is used. Not a big deal, 
> > though.

Any comments on this one?

> > generated at the MAG locally. Instead it sets to the key to 
> either '0' 
> > or all '1's.
> 
> [Ahmad]
> So far, all the feedback we received was to simplify this 
> mechanism and allow the MAG to always generate downlink GRE 
> key and the LMA the uplink. Do you see a need to keep the 
> option on the LMA generating both keys?

I like this simplification. Much better than having to negotiate between
"symmetric" and "asymmetric" keys. 

Vijay

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 24 Jun 2008 12:27:23 -0400

Ahmad, Julien,

> You are correct. But probably we can use the fields for 
> Reverse and Forward GRE keys as an indication for GRE 
> encapsulation being enabled and that will eliminate the flag 
> field. What do you think?

This would be internal to the MAG and the LMA implementations. It does
not matter how the MAG or the LMA keep track of whether GRE
encapsulation is being used. This flag shouldn't be mentioned in the
draft.

Vijay

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 24 Jun 2008 12:34:14 -0400

> vague since 

I don't folllow the above logic. :)

I know why some SDOs need GRE encapsulation. What is missing in the
draft is some text that explains the motivation for specifying GRE
encapsulation with PMIPv6.

> It is relevant here. We are talking about a new encap mode. 
> This has a bearing on how the message is protected. Any case, 
> once the draft is cleaned up, it should have the right references.

There is nothing the draft currently about using ESP header with GRE
encapsulation. Are you planning to specify this? Anyway, RFC 4303 is not
referenced anywhere in the document currently.

Vijay

---

From: Julien Laganier <[email-masked]>
Date: Tue, 24 Jun 2008 18:36:35 +0200

> "symmetric" and "asymmetric" keys. 

+1

--julien

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 24 Jun 2008 11:37:03 -0500

Hi Vijay,

> The Binding
> This would be internal to the MAG and the LMA 
> implementations. It does not matter how the MAG or the LMA 
> keep track of whether GRE encapsulation is being used. This 
> flag shouldn't be mentioned in the draft.

[Ahmad]
Personally, I am fine with not mentioning this flag.

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 24 Jun 2008 09:42:16 -0700 (PDT)

> encapsulation with PMIPv6.

I dont know why SDO's need it. But we need to provide a way for the
tunnel peers to identify the flows, when the source address in the
encapsulated packet is not unique. SDO's would need it for many other
reasons. Lets stick to the overlapping IP address example for IETF
relevance and that motivation should be sufficient. Will check and
rephrase .., if needed.

> referenced anywhere in the document currently.

If we introduce a new encap mode, we need to talk about the protection
as well. We need to do that. When we wrote the initial draft, it was
more a place holder and it was more than a year back. We need to fix
this now. Thanks for the comments.

Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 24 Jun 2008 11:44:26 -0500

Hi Vijay,
Inline please.

> Sent: Tuesday, June 24, 2008 11:24 AM
> Subject: RE: Comments on draft-muhanna-netlmm-grekey-option-02.txt
> 
> Hi Ahmad,
> 
> found it 

[Ahmad]
Hmmm I am fine either way. However, it seems to me that people have
already used the term Forward GRE key and Reverse GRE key in other
documents. In this case, I would slightly prefer leaving these
definitions and try to point that Forward Direction Traffic is "downlink
traffic" and similarly about Reverse Direction Traffic.

What about the following:

      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 referenced as downlink 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 referenced as uplink traffic.

>       gateway and tunneled at the local mobility anchor. This traffic
could be referred to as 

> I like this simplification. Much better than having to 
> negotiate between "symmetric" and "asymmetric" keys. 

[Ahmad]
It seems thus far that all feedback points to this option. Will update
the draft accordingly.

---

From: Julien Laganier <[email-masked]>
Date: Tue, 24 Jun 2008 19:04:53 +0200

Hello Ahmad,

My two cents below:

> traffic" and similarly about Reverse Direction Traffic.

FWIW, I'm always confused by those and usually end up going to the draft 
to read the definition. OTOH downlink and uplink are crystal clear to me...

The stage 2 (architecture) document describing how PMIPv6 is used in 
3GPP (3GPP TS 23.402) talks about downlink and uplink GRE keys and it is 
thus very clear to me. Then in the stage 3 (protocols) document 
describing how PMIPv6 is used in 3GPP (3GPP TS 29.275) it talks about 
forward and reverse keys, and there I get quite confused, although I'm 
reading that spec quite a lot.

But, maybe that's just me :)

--julien

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 24 Jun 2008 12:13:20 -0500

Hello Julien,

Please see inline.

Regards,
Ahmad

> > definitions and try to point that Forward Direction Traffic is 
> > "downlink traffic" and similarly about Reverse Direction Traffic.
> 
> FWIW, I'm always confused by those and usually end up going 
> to the draft to read the definition. OTOH downlink and uplink 
> are crystal clear to me...
> 
> The stage 2 (architecture) document describing how PMIPv6 is 
> used in 3GPP (3GPP TS 23.402) talks about downlink and uplink 
> GRE keys and it is thus very clear to me. Then in the stage 3 
> (protocols) document describing how PMIPv6 is used in 3GPP 
> (3GPP TS 29.275) it talks about forward and reverse keys, and 
> there I get quite confused, although I'm reading that spec 
> quite a lot.
> 

[Ahmad]
I do not think that you are alone here. I always need to pause for a
second. I agree downlink and uplink is much simpler and resonates in a
much simpler way. OTOH, you are more involved with stage 3 3GPP text (TS
29.275) than I do, If you feel that should not be a problem, we can use
downlink and uplink.

What do you think?

---

From: Julien Laganier <[email-masked]>
Date: Tue, 24 Jun 2008 19:18:25 +0200

Ahmad,

My answer below:

> 29.275) than I do, If you feel that should not be a problem, we can use

I think we can use uplink and downlink - Internet Drafts are work in 
progress, thus changes can and will happen. A document that makes 
normative references to a work in progress I-D is also work in progress 
and thus will simply be updated as a result of changes made in that draft.

--julien

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 24 Jun 2008 12:22:23 -0500

Thanks Julien!

Will use uplink and downlink, what about the following:

   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 referenced as 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 referenced as reverse direction traffic.

Regards,
Ahmad

> Sent: Tuesday, June 24, 2008 12:18 PM
> Cc: [email-masked]
> >> FWIW, I'm always confused by those and usually end up going to the 
> >> draft to read the definition. OTOH downlink and uplink are crystal 
> >> clear to me...
> >>
> >> 3GPP (3GPP TS 23.402) talks about downlink and uplink GRE 
> keys and it 
> >> is thus very clear to me. Then in the stage 3
> (3GPP TS 
> >> 29.275) it talks about forward and reverse keys, and there I get 
> >> quite confused, although I'm reading that spec quite a lot.
> >>
> > much simpler way. OTOH, you are more involved with stage 3 
> 3GPP text 
> > (TS
> > 29.275) than I do, If you feel that should not be a problem, we can 
> > use downlink and uplink.
> > 
> > What do you think?
> 
> I think we can use uplink and downlink - Internet Drafts are 
> work in progress, thus changes can and will happen. A 
> document that makes normative references to a work in 
> progress I-D is also work in progress and thus will simply be 
> updated as a result of changes made in that draft.
> 
> --julien
>

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 24 Jun 2008 10:34:12 -0700 (PDT)

>      is also referenced as forward direction traffic.

Suggested rewrite:

The traffic in the tunnel between the local mobility anchor and
the mobile access gateway, heading towards the mobile access
gateway. This traffic is also referenced as forward direction traffic.

- Where else can it get tunelled if its heading towards MAG, can skip
the LMA tunneling part.

Sri

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 24 Jun 2008 13:49:32 -0400

> relevance and that motivation should be sufficient. Will check and

I think it is *ok* to describe use cases like flow identification,
SDO-specific requirements, etc., in addition to overlapping address
space in this document. It might help later in the IETF process (IETF
last call, IESG overview, etc..) where folks look for motivation for any
work.

Vijay

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 24 Jun 2008 13:51:50 -0400

Hi Ahmad, 

>       is also referenced as reverse direction traffic.

Looks good to me. You need to make this change in many places in the
draft.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 24 Jun 2008 12:52:43 -0500

Hi Vijay.
Yes, will do.

Regards,
Ahmad

> Sent: Tuesday, June 24, 2008 12:52 PM
> To: Muhanna, Ahmad (RICH1:2H10); Julien Laganier
> Cc: [email-masked]
> Subject: RE: [netlmm] Comments on 
> This traffic 
> This traffic 
> Looks good to me. You need to make this change in many places 
> in the draft.
> 
> Vijay
>

---

From: Julien Laganier <[email-masked]>
Date: Tue, 24 Jun 2008 17:11:25 +0200

Hello Ahmad,

--julien

---

From: Julien Laganier <[email-masked]>
Date: Tue, 24 Jun 2008 17:25:43 +0200

Same here,

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 25 Jun 2008 09:45:14 -0700 (PDT)

On Tue, 24 Jun 2008, Julien Laganier wrote:

> never used on the wire and used to indicate absence of GRE tunneling when 
> present in the data structure field...
>

This is a good point. I was saying the same to Ahmad yesterday. There are
two things here:

- Request for GRE Encap Mode, which has no bearing on the keys
- The exchange of the keys

We cannot use the presence of the key for overloading both. We should have
a request bit, either in the PBU or as an option.

Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 25 Jun 2008 11:57:56 -0500

> value that 
> > is never used on the wire and used to indicate absence of GRE 
> > tunneling when present in the data structure field...
> >
> 
> This is a good point. I was saying the same to Ahmad 
> yesterday. There are two things here:
> 
> We cannot use the presence of the key for overloading both. 
> We should have a request bit, either in the PBU or as an option.

[Ahmad]
Hi Sri,

I thought that these were two different things. 
But why we can not use the presence of the GRE Key option in PBU for GRE
encapsulation as it is already captured in the draft?

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 25 Jun 2008 10:05:23 -0700 (PDT)

Ahmad,

Presence of the key to request both, we are overloading its use. For
cases such as out-of-band key negotiation, still requiring GRE encap
mode, will not work without another indicator. It will be useful to
have both the indicators.

Sri

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 25 Jun 2008 13:20:14 -0400

> a request bit, either in the PBU or as an option.

The presence of the GRE key option is an implicit request for GRE
encapsulation. Why would we need a flag?

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 25 Jun 2008 10:25:26 -0700 (PDT)

> encapsulation. Why would we need a flag?

We cannot mandate on the key requirement for using GRE encap. These
are two different requests. Most vendors have support for hardware
based support for GRE encap. The lack of presence of a request flag
should not hinder them from using this encap mode when there is no
key in use. Its very useful to allow them request the encap mode
alone.

Sri

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 25 Jun 2008 13:33:12 -0400

> have both the indicators.

Ok, got it. In that case, lets extend the option. Lets *not* reserve a
new 
flag for this. Flags are scarce. 

We can re-define the mobility option to carry a request for GRE 
encapsulation as well as a field for carrying the GRE key. We don't have
to 
change the message format though. See below.

Rename "GRE Key Identifier Option" to "GRE Encapsulation Option".

And then

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Type     |   Length      |           Reserved            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      GRE Key Identifier                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      GRE Encapsulation Option (TBA by IANA). The presence of this
option
      indicates that GRE encapsulation is being requested.

   Length

      8-bit unsigned integer indicating the length in octets of the
      option, excluding the type and length fields. If the Length field
      is set to 2, it indicates that the GRE keys are not being carried
      in the option. If the length is set to '6', it indicates the 
      presence of the GRE key in the mobility option.

   Reserved

      This field is unused.  It MUST be initialized to zero by the
sender 
      and MUST be ignored by the receiver.

   GRE Key Identifier

      32-bit field containing the GRE Key Identifier. This field is 
      present in the mobility option only if the GRE keys are being 
      exchanged using the Proxy Binding Update and Proxy Binding 
      Acknowledgement messages.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 25 Jun 2008 10:39:37 -0700 (PDT)

This should work.

Thanks
Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 25 Jun 2008 12:44:13 -0500

> Ok, got it. In that case, lets extend the option. Lets *not* 
> reserve a new flag for this. Flags are scarce. 
> 
> We can re-define the mobility option to carry a request for 
> GRE encapsulation as well as a field for carrying the GRE 
> key. We don't have to change the message format though. See below.
> 
>       |                      GRE Key Identifier               
>         |
>       GRE Encapsulation Option (TBA by IANA). The presence of 
> this option
>       This field is unused.  It MUST be initialized to zero 
> by the sender 

[Ahmad]
Vijay,

I see what you are saying. 
In that case, defining a subtype field will give more flexibility to
indicate clearly what is requested.

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 25 Jun 2008 10:48:40 -0700 (PDT)

Sure. Two changes:

- The option name change as Vijay suggested, "GRE Encapsulation 
Requestion"  Option or ..some thing like that.

- A flag in the reserved space that indicates that keys are present or
not present.

Sri

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 25 Jun 2008 14:11:45 -0400

> indicate clearly what is requested.

I will wait for your revised text that describes what the subtype field
is supposed to indicate. I am also fine with Sri's suggestion of using a
flag in the reserved space in the GRE encapsulation mobility option.

Vijay

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 25 Jun 2008 13:13:16 -0500

Sri,

> - A flag in the reserved space that indicates that keys are present or

Why do you need a flag? I thought Vijay stated that the length value would
indiate the presence or absence of keys.

-Raj

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 25 Jun 2008 11:16:00 -0700 (PDT)

Raj,

Flag in the option itself, not in PBU message. Either way as long
as the indicators are there, that should be fine.

Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 25 Jun 2008 17:14:12 -0500

> I will wait for your revised text that describes what the 
> subtype field is supposed to indicate. I am also fine with 
> Sri's suggestion of using a flag in the reserved space in the 
> GRE encapsulation mobility option.

[Ahmad]
No problem.