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

From: "Ahmad Muhanna" <[email-masked]>
Date: Sun, 26 Apr 2009 19:58:34 -0500

Hi, 

We submitted a new revision of the GRE key draft which addresses all the
comments we received during the IESG Discuss and one offline comment
which addresses an overlook of the LMA behavior with respect to the
inclusion of uplink GRE key in the PBA when receiving a re-registration
PBU. We just added some text to capture the obvious.

Please let us know if you have any comments.

Regards,
Ahmad

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Sunday, April 26, 2009 7:45 PM
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-netlmm-grekey-option-07.txt 

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-07.txt
	Pages           : 24
	Date            : 2009-04-26

This specification defines a new Mobility Option for allowing the Mobile
Access Gateway and the Local Mobility Anchor to negotiate GRE (Generic
Routing Encapsulation) encapsulation mode and exchange the downlink and
uplink GRE keys which are used for marking the downlink and uplink
traffic that belong to a specific mobility session.  In addition, the
same mobility option can be used to negotiate the GRE encapsulation mode
without exchanging the GRE keys.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netlmm-grekey-option-07.t
xt

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.

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 27 Apr 2009 17:55:45 -0400

Hi Ahmad,

In an earlier discussion on the NETLMM mailing list, we concluded that
the LMA should include the uplink GRE key in the proxy binding ack only
if the proxy binding update was sent for an initial registration or due
to a handover. It shouldn't include it for binding refresh. Version 7
has some new text in section 3.3.2 changing the LMA behavior.

   If the mobile access gateway has successfully negotiated and
   exchanged the initial GRE keys with the local mobility anchor for a
   specific mobile node binding, the mobile access gateway MUST include
   the GRE Key option with the downlink GRE key in the Proxy Binding
   Update which is used for requesting a Binding Lifetime Extension.  In
   this case, if the local mobility anchor successfully processes the
   Proxy Binding Update message, the local mobility anchor MUST return
   the same uplink GRE key that was exchanged with the mobile access
   gateway for the same mobility session in the GRE key option in a
   successful Proxy Binding Acknowledgement message.

Why was this change done? 
 
Vijay

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ahmad Muhanna
> Sent: Sunday, April 26, 2009 5:59 PM
> To: [email-masked]
> Subject: [netlmm] FW: I-D 
> Action:draft-ietf-netlmm-grekey-option-07.txt
> 
> 
> Hi, 
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 27 Apr 2009 17:03:11 -0500

Hi Vijay,

We received an offline comments about this point saying: why there is a
requirement on the LMA to return the same uplink GRE key if the LMA
receives a handoff-triggered Binding lifetime extension BUT there is not
the same for regular Binding Lifetime extension.

I thought that is the understanding and did not feel that is a problem.
That actually the offline comment that I mentioned in my email.

Do you see any problem?

Regards,
Ahmad Muhanna

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Monday, April 27, 2009 4:56 PM
> To: Muhanna, Ahmad (RICH1:2H10); [email-masked]
> Subject: RE: [netlmm] FW: I-D 
> In an earlier discussion on the NETLMM mailing list, we 
> concluded that the LMA should include the uplink GRE key in 
> the proxy binding ack only if the proxy binding update was 
> sent for an initial registration or due to a handover. It 
> shouldn't include it for binding refresh. Version 7 has some 
> new text in section 3.3.2 changing the LMA behavior.
> 
> > We submitted a new revision of the GRE key draft which 
> addresses all 
> > the comments we received during the IESG Discuss and one offline 
> > comment which addresses an overlook of the LMA behavior 
> with respect 
> > to the inclusion of uplink GRE key in the PBA when receiving a 
> > re-registration PBU. We just added some text to capture the obvious.
> > 
> > This specification defines a new Mobility Option for allowing the 
> > Mobile Access Gateway and the Local Mobility Anchor to 
> negotiate GRE 
> > (Generic Routing Encapsulation) encapsulation mode and exchange the 
> > downlink and uplink GRE keys which are used for marking the 
> downlink 
> > and uplink traffic that belong to a specific mobility session.  In 
> > addition, the same mobility option can be used to negotiate the GRE 
> > encapsulation mode without exchanging the GRE keys.
> >

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 27 Apr 2009 15:47:13 -0700

Ahmad Muhanna wrote:
> receives a handoff-triggered Binding lifetime extension 

There are two parts to this. After a handover, the downlink GRE key can 
change. The uplink GRE key remains the same. So we had to add some text 
that said the same uplink GRE key is sent to the new MAG. The new MAG 
might not be aware of the uplink GRE key to use after the handover. So 
the LMA needs to send the uplink GRE key in the proxy binding ack.

> BUT there is not

Because in the earlier discussions, we concluded that there is no need 
for the LMA to include the same GRE key again. The uplink GRE key is 
already present in the binding update list entry on the MAG.

> That actually the offline comment that I mentioned in my email.

Well, it is unnecessary. And it goes against the earlier conclusion we 
had after a long discussion on the mailing list.

Vijay

---

From: Joel Hortelius <[email-masked]>
Date: Tue, 28 Apr 2009 08:46:07 +0000

Why treat this option differently than the rest of the negotiations in
MIP6? 
Pretty much all options are always provided with the current
information, which keeps it simple and straightforward. I really don't
understand the reasoning as to why the uplink key suddenly should be
omitted. 

It seems to be to be a needless introduction of complexity, requiring
state checks regarding what information should be provided. What if a
MAG reboots - should either heartbeat be a MUST or should the draft
define what indicators should require the uplink key?

Regards,
Joel Hortelius.

On Mon, 2009-04-27 at 15:47 -0700, Vijay Devarapalli wrote:
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netlmm
>

---

From: Joel Hortelius <[email-masked]>
Date: Tue, 28 Apr 2009 13:05:51 +0000

Well, I gather I had better correct myself. The issue I wrestled with in
earlier drafts wasn't the MAG rebooting, it was the LMA - in which case
a re-registration request did not provide enough information to restore
the transport between LMA/MAG,Mobile Node. In those cases the LMA ended
up doing IP6IP6 tunneling since no GRE options were provided, and the
MAG/Mobile Node went GRE since it believed the LMA already had the
required information.

/J.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 28 Apr 2009 07:23:12 -0500

Hi Vijay,

> 
> Ahmad Muhanna wrote:
> > Hi Vijay,
> > 
> > We received an offline comments about this point saying: 
> why there is 
> > a requirement on the LMA to return the same uplink GRE key 
> if the LMA 
> There are two parts to this. After a handover, the downlink 
> GRE key can change. The uplink GRE key remains the same. So 
> we had to add some text that said the same uplink GRE key is 
> sent to the new MAG. The new MAG might not be aware of the 
> uplink GRE key to use after the handover. So the LMA needs to 
> send the uplink GRE key in the proxy binding ack.
> 
> > BUT there is not
> Because in the earlier discussions, we concluded that there 
> is no need for the LMA to include the same GRE key again. The 
> uplink GRE key is already present in the binding update list 
> entry on the MAG.
> 
[Ahmad]
Yes. I remember that earlier discussion. But, that earlier discussion
also concluded that we do not need to include the GRE option in
re-registration too. However, during the resolution/discussion of the AD
review, the agreement was that we need to include the GRE option in
re-registration, handoff-triggered or not. Then, the offline comment
made sense.

Now, we always send the downlink GRE key in the PBU for Binding lifetime
extension. We only document the case of handoff-triggered in the
specification w.r.t. the LMA returning the same uplink GRE key. Why not
be consistent and document the re-registration case. 

> Well, it is unnecessary. And it goes against the earlier 
> conclusion we had after a long discussion on the mailing list.

[Ahmad]
I believe as mentioned above it makes sense to document it; otherwise,
it gives the wrong impression to the implementer. Why that was left out?
Was there a valid/good reason? Etc.....

Regards,
Ahmad

> >> In an earlier discussion on the NETLMM mailing list, we concluded 
> >> that the LMA should include the uplink GRE key in the 
> proxy binding 
> >> ack only if the proxy binding update was sent for an initial 
> >> registration or due to a handover. It shouldn't include it for 
> >> binding refresh. Version 7 has some new text in section 3.3.2 
> >> changing the LMA behavior.
> >>
> >>    Update which is used for requesting a Binding Lifetime 
> Extension.  
> >> In

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Tue, 28 Apr 2009 16:52:17 -0400

Hi,

> 
> Now, we always send the downlink GRE key in the PBU for 
> Binding lifetime extension. We only document the case of 
> handoff-triggered in the specification w.r.t. the LMA 
> returning the same uplink GRE key. Why not be consistent and 
> document the re-registration case. 

If we are going to include the downlink key in PBU for re-registration,
I would also like to include the uplink key in PBA. AFAIK, it does not
break anything and avoids being weird (even though we may have reasons
for it).

-Rajeev

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 28 Apr 2009 16:33:47 -0700

Hi Ahmad,

> be consistent and document the re-registration case.

It is not about being consistent. If there is a handover, the new MAG does
know what GRE key to use when it tunnels the packet to the LMA. So the LMA
MUST include the uplink GRE key in the proxy binding ack sent after a
handover. But for re-registration, the LMA does not have to include the
uplink GRE key in the proxy binding ack. So I don't follow the consistency
argument.

Can you also explain what in the AD review led to the MAG including the
downlink GRE key in the proxy BUs sent for re-registrations?

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 28 Apr 2009 16:36:09 -0700

Hi Rajeev,

> break anything and avoids being weird (even though we may have reasons

I would argue that for re-registrations, neither the downlink nor uplink GRE
keys need to be included in the PBU and PBACK. Its not clear what was
discussed during the AD and IESG review.

Vijay

---

From: Yungui Wang <[email-masked]>
Date: Wed, 29 Apr 2009 08:56:09 +0800

Hello

> [mailto:[email-masked]] On Behalf Of Vijay Devarapalli
> Sent: Wednesday, April 29, 2009 7:36 AM
> To: Koodli, Rajeev; [email-masked]
> Subject: Re: [netlmm] FW: I-D 
> keys need to be included in the PBU and PBACK. 

Generally, I agree with your logic. However, LMA may lost MN's downlink 
GRE key (e.g. LMA reboot as Joel Hortelius mentioned).  If re-registration
message don't carry downlink key, then LMA has to return PBA with
<GRE KEY OPTION REQUIRED> to recovery GRE key. 
This brings twice RTT(round trip time). 
On the other side, GRE key option is 8 BYTE and re-reg is not so 
frequently sent, that's, it does not bring big consumption.
Therefore, in a word, current text is okey. 

B.R.
Yungui

> Its not clear what was

---

From: Yungui Wang <[email-masked]>
Date: Wed, 29 Apr 2009 09:07:33 +0800

Hello 

In the draft, there are multiple paragraphs mentioned 'LMA MUST 
return the same uplink GRE key...'. I am not sure why it emphasizes
the word 'same'. Normally, the LMA will return the same uplink GRE 
key during re-registration. However, in some certain cases, the LMA 
may re-number GRE key (such as reboot, etc.). Thus, 'same' should 
be deleted.

B.R.
Yungui 

> Sent: Monday, April 27, 2009 8:59 AM
> To: [email-masked]
> addresses all the

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 28 Apr 2009 20:53:50 -0500

Hmmmmm... Interesting ...
What kind of reboot is the one you have in mind which only cause the
loss of the uplink GRE key?
May be it is better to understand the scenario you have in mind before
we start looking into recommendations and opinions......

Regards,
Ahmad

> From: Yungui Wang [mailto:[email-masked]] 
> Sent: Tuesday, April 28, 2009 8:08 PM
> In the draft, there are multiple paragraphs mentioned 'LMA 
> MUST return the same uplink GRE key...'. I am not sure why it 
> emphasizes the word 'same'. Normally, the LMA will return the 
> same uplink GRE key during re-registration. However, in some 
> certain cases, the LMA may re-number GRE key (such as reboot, 
> etc.). Thus, 'same' should be deleted.
> 
> B.R.
> Yungui 
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 28 Apr 2009 21:26:45 -0500

Hi Vijay

> > re-registration too. However, during the 
> resolution/discussion of the 
> > AD review, the agreement was that we need to include the 
> GRE option in 
> > Now, we always send the downlink GRE key in the PBU for Binding 
> > lifetime extension. We only document the case of 
> handoff-triggered in 
> > the specification w.r.t. the LMA returning the same uplink GRE key. 
> > Why not be consistent and document the re-registration case.
> 
> It is not about being consistent. If there is a handover, the 
> new MAG does know what GRE key to use when it tunnels the 
> packet to the LMA. So the LMA MUST include the uplink GRE key 
> in the proxy binding ack sent after a handover. But for 
> re-registration, the LMA does not have to include the uplink 
> GRE key in the proxy binding ack. So I don't follow the 
> consistency argument.
[Ahmad]
I believe, simplicity or call it consistency is the key here. 

IMO, since handoff-triggered Binding Lifetime extension PBU requires the
MAG to include the downlink GRE key in the PBU and the LMA to include
the uplink GRE key in the PBA, I believe there is no reason to handle
non-handoff re-registration PBU any differently at the LMA. It is
simpler to include the downlink GRE key option in all re-registration
PBU and uplink GRE key in all corresponding PBA.

The question, though, what do we gain if we allow different
handling/treatment for handoff-triggered Binding Life time extension PBU
vs. regular Binding lifetime extension PBU?

> 
> Can you also explain what in the AD review led to the MAG 
> including the downlink GRE key in the proxy BUs sent for 
> re-registrations?
> 
> Vijay
> 
> > 
> conclusion 
> >> we had after a long discussion on the mailing list.
> > 
> > [Ahmad]
> concluded

---

From: Yungui Wang <[email-masked]>
Date: Wed, 29 Apr 2009 10:49:37 +0800

It is just an example. Maybe I-D 'LMA redirection' described
case could be for your information. However, re-numbering
GRE key may be possible.

On the other side, why doesn't the draft emphasize that
'MAG MUST carry the same downlink GRE key...' during
re-registration? :)

B.R.
Yungui 

> From: Ahmad Muhanna [mailto:[email-masked]] 
> Sent: Wednesday, April 29, 2009 9:54 AM
> To: [email-masked]; [email-masked]

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 28 Apr 2009 22:44:53 -0700

Hi Yungui,

> This brings twice RTT(round trip time).

LMA reboot is an even more rare event. Having an additional round trip is
not a big concern in case the LMA reboots. If you are using the Heartbeat
Mechanism, then you can avoid even this additional round trip.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 29 Apr 2009 01:32:35 -0500

Inline.

> Sent: Tuesday, April 28, 2009 9:50 PM
> case could be for your information. 
[Ahmad]
Okay.. Is it GRE renumbering or LMA reboot or LMA redirection ... By the
time we get to the scenario you have in mind we have a long list of
different terms and high level description of things that you somehow
assume they are synonymous:)

> However, re-numbering GRE 
> key may be possible.
> 
> On the other side, why doesn't the draft emphasize that 'MAG 
> MUST carry the same downlink GRE key...' during re-registration? :)

[Ahmad]
Well.. You seem to think that these two cases are alike:)
At any point of time, if the MAG decides to change the MN session
downlink GRE key, it could send a PBU and negotiate a new GRE keys? Can
the LMA do the same?

In my mind, the case of LMA reboot, assuming that the LMA lost the state
of the MN BCE, there is an out of synch state between the LMA and the
MAG anyway. I believe from the LMA prospective, the case probably falls
under the initial registration rather than re-registration. We need to
minimize loss of traffic by NOT introducing a loose requirement which
allows NOT an implementation to change the uplink GRE without paying
attention to the fact that MAY cause some serious loss of traffic.

> > > may re-number GRE key (such as reboot, etc.). Thus, 
> 'same' should be 
> > > deleted.
> > > 
> > > B.R.
> > > Yungui
> > >

---

From: Joel Hortelius <[email-masked]>
Date: Wed, 29 Apr 2009 15:45:16 +0000

Hi Vijay;

> Mechanism, then you can avoid even this additional round trip.

The problem here is that if the LMA accepts both GRE and IP6IP6
tunneling - there's no way for the LMA to know which the MAG/Mobile Node
actually wants. If the MAG/Mobile Node wants GRE, the LMA will still go
IP6IP6 since there's no GRE included, resulting in both LMA and MAG
believing they're properly setup, while in truth the transport is
invalid.

/J.