Subject: [netlmm] WG Last Call notice: draft-ietf-netlmm-grekey-option (second last call)

From: "Soininen Jonne (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 07 Jan 2009 17:48:01 +0200

<chair hat on>
Everybody,

As the first last-call didn't pass due to the lack of comments, we would 
like to start the second last-call on draft-ietf-netlmm-grekey-option. 
The last call is as follows:

Draft: draft-ietf-netlmm-grekey-option-02.txt
Start: 7.1.2009
End: 21.1.2009 (EOB PST)

Please, if you haven't done so, read the draft. If you have read, 
comment, and at least acknowledge your ok.

Vidya & Jonne
<chair hat off>
_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 09 Jan 2009 17:02:10 -0500

Hi Chairs,
   I have read the current version of this draft and I think it is ready 
to be progressed.

Cheers
Suresh

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 12 Jan 2009 14:12:33 -0800 (PST)

Hi Jonne,
  I read this draft and have a few editorial comments. Like Jouni I have no problem with the technical content.
  
3.3.1
GRE encapsulation is needed and GRE keys is
   required,
s/keys is/keys are
3.3.2
respected BCE
the word respected is used 3 times in this section. It is not clear what is meant? Is it referring to the three additional fields in the BCE that the draft adds (like in field A, field B and field C, respectively)? Make it clear this way otherwise remove the "respected".
5.2
After successfully processes a Proxy Binding Update message with
s/processes/processing
If after receiving Proxy Binding Update message with the GRE Key
      option and successfully processes 
s/processes/processing
6.
This section defines an extension to the Mobile IPv6 [RFC3775]
   protocol messages. 
I suggest deleting this sentence.
6.1
GRE Key Identifier

Why not use GRE Key? RFC 2890 calls it a Key. It is the GRE Key.

Regards,

Behcet

________________________________
From: Soininen Jonne (NSN - FI/Espoo) <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: Wednesday, January 7, 2009 9:48:01 AM
Subject: [netlmm] WG Last Call notice: draft-ietf-netlmm-grekey-option (second last call)

<chair hat on>
Everybody,

As the first last-call didn't pass due to the lack of comments, we would like to start the second last-call on draft-ietf-netlmm-grekey-option. The last call is as follows:

Please, if you haven't done so, read the draft. If you have read, comment, and at least acknowledge your ok.

Vidya & Jonne
<chair hat off>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 13 Jan 2009 10:03:02 -0600

Hi Behcet,
Thanks for the review. Please see comments inline.

Regards, 
Ahmad

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Behcet Sarikaya
	Sent: Monday, January 12, 2009 4:13 PM
	To: Soininen Jonne (NSN - FI/Espoo); [email-masked]
	Subject: Re: [netlmm] WG Last Call notice:
draft-ietf-netlmm-grekey-option(second last call)

	Hi Jonne,
	  I read this draft and have a few editorial comments. Like
Jouni I have no problem with the technical content.
	3.3.1
	GRE encapsulation is needed and GRE keys is
	   required,
	s/keys is/keys are 
	[Ahmad]
	ok.
	 
	3.3.2
	respected BCE
	the word respected is used 3 times in this section. It is not
clear what is meant? Is it referring to the three additional fields in
the BCE that the draft adds (like in field A, field B and field C,
respectively)? Make it clear this way otherwise remove the "respected". 
	 
	[Ahmad]
	will remove it. thx. 
	5.2
	 
	[Ahmad]
	ok.

	[Ahmad]
	ok.
	 
	6.
	 
	[Ahmad]
	We discussed that earlier on the ml and the consensus was to
have an explicit reference to RFC3775.
	 
	6.1
	GRE Key Identifier

	[Ahmad]
	GRE Key is what carried in the GRE Key Identifier.
	 
	Regards,
	 
	Behcet

	From: Soininen Jonne (NSN - FI/Espoo) <[email-masked]>
	To: "[email-masked]" <[email-masked]>
	Sent: Wednesday, January 7, 2009 9:48:01 AM
	Subject: [netlmm] WG Last Call notice:
draft-ietf-netlmm-grekey-option (second last call)
	
	<chair hat on>
	Everybody,
	
	As the first last-call didn't pass due to the lack of comments,
we would like to start the second last-call on
draft-ietf-netlmm-grekey-option. The last call is as follows:

	Please, if you haven't done so, read the draft. If you have
read, comment, and at least acknowledge your ok.
	
	Vidya & Jonne
	<chair hat off>

---

From: "Premec, Domagoj" <[email-masked]>
Date: Thu, 15 Jan 2009 15:15:03 +0100

Hi,

I have read the document and I think it is ready to move forward. Please find some additional comments/observations below...

The spec doesn't say anything about the granularity of the GRE keys. Considering the example from the section 3.1, the key granularity can be per operator domain and a total of two GRE key pairs would suffice to cover that scenario. It should also be noted that this spec does not allow to distinguish between different flows of the same MN, i.e. the sub-MN key granularity is not possible. IMO a paragraph discussing the levels of GRE key granularity and their applicability would be useful. 

section 3.3.2
>  [...] 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.

I thought that the BU completely overwrites the BCE, and if something is not in the BU then it is removed from the BCE. Maybe a rational for the above recommendation could be provided, are there any detrimental effects if this is not followed?

Is there anything to be said about NATs and GRE encapsulation?

domagoj

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Soininen Jonne 
> (NSN - FI/Espoo)
> Sent: 07. sijecanj 2009 16:48
> To: [email-masked]
> As the first last-call didn't pass due to the lack of 
> comments, we would like to start the second last-call on

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 15 Jan 2009 16:43:40 -0600

Hi Domagoj,
Please see comments inline.

Regards,
Ahmad

> From: Premec, Domagoj [mailto:[email-masked]] 
> Sent: Thursday, January 15, 2009 8:15 AM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: [email-masked]
> Subject: RE: [netlmm] WG Last Call notice: 
> I have read the document and I think it is ready to move 
> forward. Please find some additional comments/observations below...
> 
> The spec doesn't say anything about the granularity of the 
> GRE keys. Considering the example from the section 3.1, the 
> key granularity can be per operator domain and a total of two 
> GRE key pairs would suffice to cover that scenario. 
[Ahmad]
True, but per IPv4 address.

> It should 
> also be noted that this spec does not allow to distinguish 
> between different flows of the same MN, i.e. the sub-MN key 
> granularity is not possible. 
[Ahmad]
It does as long as each have a different BCE. For example, the same MN
can access different PDN connections and still have a different GRE key
per connection. In general, the example in section 3.1. describes how
the GRE key will be used to differentiates between flows for different
IPv4 addresses. 

> IMO a paragraph discussing the 
> levels of GRE key granularity and their applicability would 
> be useful. 

[Ahmad]
The granularity we have always assumed is: downlink GRE key (allocated
by the MAG) is unique per MAG-LMA pair while uplink GRE key (allocated
by the LMA) in unique per LMA. Are you saying that we need to document
that somewhere?

> I thought that the BU completely overwrites the BCE, and if 
> something is not in the BU then it is removed from the BCE. 
> Maybe a rational for the above recommendation could be 
> provided, are there any detrimental effects if this is not followed?

[Ahmad]
Initially, I was in favor of including the GRE key option in all PBU,
initial, re-registration, and de-registration. However, the wg consensus
was to mandate the GRE key option in the initial PBU (of course if
needed) and the re-registration in case of change of the pCoA, i.e.
during handoff.

The argument used during that discussion is that the GRE key is valid
for the mobile node session until it is torn down. That is why some
people believe it is not necessary to be included in the re-registration
PBU. i.e., we were not able to come up with a usecase that requires the
GRE key to be included in the re-registration PBU, except in the case of
handoff. 

However, in the case that the MAG includes the GRE option in the
re-registration PBU, then the LMA will process the PBU normally and
update the BCE with the received GRE key. This means that it is possible
for the MAG to include a different GRE key in the re-registration PBU
different than the one sent in the initial PBU.

> Is there anything to be said about NATs and GRE encapsulation?
[Ahmad]
Very good question!
I believe that nothing special that is needed here on the top of what in
DSMIP6 and PMIPv6 support IPv4. That why nothing was mentioned about NAT
and associated GRE encapsulation. However, with the recent discussion on
MEXT about DSMIP6 and related GRE and TLV, I believe it will depend on
the decision made on MEXT DSMIP6 discussion. If the decision is to
remove the GRE encapsulation related text from DSMIP6, then this
document will be a good candidate for such text. 

> > [mailto:[email-masked]] On Behalf Of Soininen Jonne (NSN - 
> > FI/Espoo)
> > As the first last-call didn't pass due to the lack of comments, we 
> > would like to start the second last-call on