Subject: Re: [netlmm] Some questions on draft-muhanna-netlmm-grekey-option-04

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 13 Aug 2008 07:37:59 -0500

Hi Mohana,
Please see inline.

Regards,
Ahmad

> -----Original Message-----
> From: Mohana Jeyatharan [mailto:[email-masked]] 
> Sent: Wednesday, August 13, 2008 4:00 AM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: [email-masked]
> Subject: Some questions on draft-muhanna-netlmm-grekey-option-04
> 
> Hi Ahmad,
> 
> I have a few question in the latest version of your draft.
> 
> (1)In section 3.2 you have a mechanism for GRE key support 
> verification mechanism and then in section

[Ahmad]
The intention of this section to allow GRE encapsulation/tunneling
negotiation in the case when the GRE keys are not being exchanged.

> 3.3 have the mechanims where the GRE keys are sent in PBU. 
> Why such differentiation and what is the benefit. I think in 
> v03 you did not have such separation?

[Ahmad]
There was some discussion on the ml and some people would like to have
this flexibility. The logic was to avoid GRE tunneling negotiation
implicitly using the presence of the GRE keys. 
> 
> (2)In section 3.3.2 it is mentioned that dereg must have GRE 
> key option.
> But, in the body of the text in section 3.3.2 it says
> 
> "In the case that the deregistration PBU does not
>    include the GRE encapsulation option and the corresponding mobile
>    node session has been assigned downlink and uplink GRE 
> keys, the LMA
>    will follow the same process in cleaning the associated resources
>    including the GRE keys."
> 
> Sorry I am not very clear with this.
[Ahmad]
I see what you are saying, but the intention here is to mandate on the
MAG the inclusion of the GREkey during de-registration. However, if the
LMA receive a valid de-registration PBU from the MAG, i.e., secure
following all the rules in PMIPv6 spec and the LMA is able to correctly
identify the MN BCE, the LMA will process the de-registration normally
and clear the BCE. In that case, the GRE keys will be deleted and
consequently the LMA could possibly assign these keys to a different
sessions. So the MAG needs to be aware of that.

Do you have a proposal for a better text?

> 
> (3)Can you exchnage multipe GRE keys. It seems the drfat is 
> resticting to down link key in PBU and down link and up-link 
> key in PBA. I think it should be better to have more keys to 
> perform flow specific processing.
> Or do you think such a need is not necessary?

[Ahmad]
Of course, I agree that need is real. However, the GRE key exchange
should be associated with another identifier in order to make sure that
both the MAG and the LMA are in sync with respect to which key should be
used for which identifier. It follows the current logic in PMIPv6 base
protocol of one PBU means a single registration.
In case of multiple registration support in the same PBU, the
clarification would actually make sense there as long as the draft is
flexible enough to not restrict that functionality.

> 
> (4)If GRE key is exchnaged, I remember it mentioned that it 
> must be used in sending data packet encapsulation. Why should 
> it be so. May be for some flows such GRE sematics may not be 
> necessary. Or are you targetting you IPv4 private address 
> based scenario.

[Ahmad]
The intention is not to restrict the use of GRE keys with IPv4 address
overlap usecase. If you point me to the specific text, we will fix it.

> 
> Sorry, I just read the and I had such queries. 

[Ahmad]
Thanks for your review and comments.

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

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 13 Aug 2008 14:29:37 -0400

Hi Ahmad, 

> sessions. So the MAG needs to be aware of that.

Why do you need to mandate including the GRE keys in the de-registration
PBU? The mobility sessions (as it is called in RFC 5213) is going to be
deleted anyway. The GRE key does not identify the session. It is still
the MN-ID, HNP, etc.. 

I also don't see a case where the MAG would be using different GRE keys
for the same PMIPv6 mobility session. 

Vijay

---

From: "Mohana Jeyatharan" <[email-masked]>
Date: Thu, 14 Aug 2008 09:30:34 +0800

Hi Ahmad,

Pls see reply in-line.

BR,
Mohana 

> From: Ahmad Muhanna [mailto:[email-masked]] 
> Sent: Wednesday, August 13, 2008 8:38 PM
> To: Mohana Jeyatharan
> Cc: [email-masked]
> Subject: RE: Some questions on draft-muhanna-netlmm-grekey-option-04
> 
> Hi Mohana,
> Please see inline.
> 
> Regards,
> Ahmad
>  
> 
> The intention of this section to allow GRE 
> encapsulation/tunneling negotiation in the case when the GRE 
> keys are not being exchanged.
> 
> There was some discussion on the ml and some people would 
> like to have this flexibility. The logic was to avoid GRE 
> tunneling negotiation implicitly using the presence of the GRE keys. 
> > 

[Mohana] OK, may be there is a valid reason.

> > (2)In section 3.3.2 it is mentioned that dereg must have GRE key 
> > option.
> >    node session has been assigned downlink and uplink GRE keys, the 
> > LMA
> I see what you are saying, but the intention here is to 
> mandate on the MAG the inclusion of the GREkey during 
> de-registration. However, if the LMA receive a valid 
> de-registration PBU from the MAG, i.e., secure following all 
> the rules in PMIPv6 spec and the LMA is able to correctly 
> identify the MN BCE, the LMA will process the de-registration 
> normally and clear the BCE. In that case, the GRE keys will 
> be deleted and consequently the LMA could possibly assign 
> these keys to a different sessions. So the MAG needs to be 
> aware of that.
> 
[Mohana] Well, I am not saying that the text is not written correctly.
It was a bit confusing when you said GRE key must be sent in dereg and
then giving the flexibility of normal processing without the GRE keys.
I think Vijay has also mentioned about this. Perhaps as you have
explained,
if you think to remove session GRE keys are not important, then no need
to have a very strict MUST.

> resticting 
> > to down link key in PBU and down link and up-link key in 
> PBA. I think 
> > it should be better to have more keys to perform flow specific 
> > processing.
> Of course, I agree that need is real. However, the GRE key 
> exchange should be associated with another identifier in 
> order to make sure that both the MAG and the LMA are in sync 
> with respect to which key should be used for which 
> identifier. It follows the current logic in PMIPv6 base 
> clarification would actually make sense there as long as the 
> draft is flexible enough to not restrict that functionality.
> 
> > 

[Mohana] Well, I cannot particlulary think of a very good use case.
But, since TS 23.402 is giving importance in GRE keys, I was wondering
any flow specific QoS
Montiroing or measurements may be in mind. So, that is why I asked this
question.
I think I saw Vijay's mail and if your'll feel there is currently no
need then I am fine with
it as well.
> > (4)If GRE key is exchnaged, I remember it mentioned that it must be 
> > used in sending data packet encapsulation. Why should it be 
> so. May be 
> > for some flows such GRE sematics may not be necessary. Or are you 
> > targetting you IPv4 private address based scenario.
> 
> [Ahmad]
> The intention is not to restrict the use of GRE keys with 
> IPv4 address overlap usecase. If you point me to the specific 
> text, we will fix it.

[Mohana] Section 5.2, bullet 3
> Thanks for your review and comments.
[Mohana] no problem.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Sun, 17 Aug 2008 17:46:32 -0500

Hi Mohana,
Sorry for the late reply. Took few of days off:)
Please see rely inline.

Regards,
Ahmad

> > > From: Mohana Jeyatharan 
> [mailto:[email-masked]]
> like to have 
> keys, the 

[Ahmad]
Sure. We can make the inclusion of the GRE key option in the
de-registration optional. That should take care of your concern and also
Vijay seems to have a comment on that too.

> But, since TS 23.402 is giving importance in GRE keys, I was wondering

[Ahmad]
AFAIK TS23.402 is using out-of-bound signaling for QoS and I do not
think GRE keys is used for QoS purpose.

> [Mohana] Section 5.2, bullet 3

[Ahmad]
Hmmm.. I do not see that bullet specific to IPv4 address overlap case
unless I am missing something.
Could you please elaborate a little more how this bullet is specific to
IPv4 address overlap.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Sun, 17 Aug 2008 18:32:10 -0500

Hi Vijay.

> mandate on the 
> > following all the rules in PMIPv6 spec and the LMA is able to 
> > correctly identify the MN BCE, the LMA will process the 
> > de-registration normally and clear the BCE. In that case, 
> the GRE keys 
> > will be deleted and consequently the LMA could possibly 
> assign these 
> > keys to a different sessions. So the MAG needs to be aware of that.
> 
> Why do you need to mandate including the GRE keys in the 
> de-registration PBU? The mobility sessions (as it is called 
> in RFC 5213) is going to be deleted anyway. The GRE key does 
> not identify the session. It is still the MN-ID, HNP, etc.. 

[Ahmad]
I agree. We will make it optional for the MAG to include in the
de-registration PBU.

Best Regards,
Ahmad

> 
> I also don't see a case where the MAG would be using 
> different GRE keys for the same PMIPv6 mobility session. 
> 
> Vijay
>

---

From: "Mohana Jeyatharan" <[email-masked]>
Date: Mon, 18 Aug 2008 08:34:29 +0800

Hi Ahmad,

Pls see reply in-line.

BR,
Mohana 

> Sent: Monday, August 18, 2008 6:47 AM
> To: Mohana Jeyatharan
> Cc: [email-masked]
> Sorry for the late reply. Took few of days off:) Please see 
> rely inline.
> 
> Regards,
> Ahmad
>  
> 
> > > 
> encapsulation/tunneling 
> mandate on 
> > > the MAG the inclusion of the GREkey during 
> de-registration. However, 
> > > if the LMA receive a valid de-registration PBU from the 
> MAG, i.e., 
> > > secure following all the rules in PMIPv6 spec and the LMA 
> is able to 
> > > de-registration normally and clear the BCE. In that case, the GRE 
> > > keys will be deleted and consequently the LMA could 
> possibly assign 
> > > these keys to a different sessions. So the MAG needs to 
> be aware of 
> > > that.
> > > 
> > explained, if you think to remove session GRE keys are not 
> important, 
> > then no need to have a very strict MUST.
> 
> [Ahmad]
> de-registration optional. That should take care of your 
> concern and also Vijay seems to have a comment on that too.
> 
> > 
> > > > 
> > > should be associated with another identifier in order to 
> make sure 
> > > that both the MAG and the LMA are in sync with respect to 
> which key 
> > > should be used for which identifier. It follows the 
> current logic in 
> > > PMIPv6 base protocol of one PBU means a single registration.
> > > clarification would actually make sense there as long as 
> the draft 
> > > is flexible enough to not restrict that functionality.
> > > 
> > > > 
> > 
> AFAIK TS23.402 is using out-of-bound signaling for QoS and I 
> do not think GRE keys is used for QoS purpose.

[Mohana] Yes, you are right. They are (3GPP) using PCRF entity to
perform out of band
Band QoS for PMIP. But, incase, inband is considered....Well, my main
concern was I was 
trying hard to think of other scenarios where the GRE keys can be used,
other than the one you have highlighted in the draft. That is all.

> 
> > Montiroing or measurements may be in mind. So, that is why I asked 
> > this question.
> > need then I am fine with it as well.
> > > IPv4 address overlap usecase. If you point me to the 
> specific text, 
> > > we will fix it.
> > 
> Hmmm.. I do not see that bullet specific to IPv4 address 
> overlap case unless I am missing something.

[Mohana] Ok, so if you restict GRE keys for IPv4 address overlap case,
then they must be used when tunneling packets. Understand...

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 18 Aug 2008 14:50:13 -0400

Hi Ahmad,

> I agree. We will make it optional for the MAG to include in the

Can't we simplify it by saying GRE keys are only included in the initial
PBU/PBAck? Why keep it optional for the MAG to include the GRE key in
the PBU for de-registration?

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 18 Aug 2008 12:01:26 -0700 (PDT)

> the PBU for de-registration?

I do not think we should disallow this completely. If this not
needed in dereg, optional tag will be fine. In cases, where
this may be needed, let them send the key in all messages.

Sri

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 18 Aug 2008 12:24:07 -0700

Hello Sri,

> this may be needed, let them send the key in all messages.

Can you say more about the cases where this is needed?

Regards,
Charlie P.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 18 Aug 2008 14:29:26 -0500

> Can't we simplify it by saying GRE keys are only included in 
> the initial PBU/PBAck? Why keep it optional for the MAG to 
> include the GRE key in the PBU for de-registration?

[Ahmad]
Hi Vijay,

I do not see any problem in making it optional. 
If a MAG implementation would include it that is fine and the LAMA
implementation has the option to process it or even ignore it.

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 18 Aug 2008 12:33:55 -0700 (PDT)

Hi Charlie,

> Can you say more about the cases where this is needed?

I do not have usecases to point out as where this would be needed.
We wrote the GRE draft for two primary reasons, over-lapping address
case and the 3GPP use-case. Clearly, the mechanism is open for
other usecases. Since, we are certain we dont need the key to be
carried in dereg messages for the currently known usecases, we can
certainly make this optional. But, I'm not sure why this  should be
explicitly disallowed.

GRE key is allowing the peers to set a context and once the context
is set, it is reasonable to expect it to be passed in subsequent
messages.

Thanks
Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 18 Aug 2008 14:35:58 -0500

Hi Charlie,

I was thinking that in the case that the same MN-ID (NAI) is used for
registering multiple PDN connections where each connection is assigned a
GRE key, It will be useful to send a de-registration which include the
MN-ID and the GRE key associated with that connection. Also, if bulk
registration is supported, bulk de-registration for specific connections
but not all is also possible. In that case, including the GRE key would
be helpful too.

Regards,
Ahmad

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Charles E. Perkins
> Sent: Monday, August 18, 2008 2:24 PM
> To: Sri Gundavelli
> Cc: [email-masked]
> Subject: Re: [netlmm] Some questions on 
> draft-muhanna-netlmm-grekey-option-04
> 
> 
> Hello Sri,
> 
> Sri Gundavelli wrote:
> >
> >>
> >> Can't we simplify it by saying GRE keys are only included in the 
> >> initial PBU/PBAck? Why keep it optional for the MAG to include the 
> >> GRE key in the PBU for de-registration?
> >>
> >
> > I do not think we should disallow this completely. If this 
> not needed 
> > in dereg, optional tag will be fine. In cases, where this may be 
> > needed, let them send the key in all messages.
>

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 18 Aug 2008 15:13:53 -0500

Inline:

> this may be needed, let them send the key in all messages.

If it is not needed, why even have it as optional. I see no reason for
having the keys in the dereg message. In what case is it needed?

-Raj

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 18 Aug 2008 13:20:47 -0700 (PDT)

> having the keys in the dereg message. In what case is it needed?

Any issue do you forsee if this is made optional ? Given that the
mechanism is open for other usecases.

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 18 Aug 2008 15:44:53 -0500

Sri,

> mechanism is open for other usecases.

If the usecase is clear, I am fine it being optional. But in the absence of
a valid usecase it is hard to just add yet another attribute.

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 18 Aug 2008 14:01:29 -0700 (PDT)

Hi Raj:

> a valid usecase it is hard to just add yet another attribute.

If there is a good reason to restrict the option usage for
only some messages, its perfectly fine. But, if we are not
aware of any potential issues that this may cause by making
this optional, I dont see why we should be so conservative.
After all its an option, its a context object returned by the
LMA, let the option be passed when needed. Given that there
will be other usecases where this option might be needed.

The option cannot be possibly misused, if carried in a dereg
message. It allocated for that session. Why require an RFC
update, if its required in some other scenario.

Sri

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 18 Aug 2008 16:13:39 -0500

Hi Sri,

Option foo is also useful in the future and hence should be included in the
message. It does no harm to the protocol itself.
The usecase for foo is unclear at the present time... But someone will come
up with a need for it at some point in time and by including it already in
the spec, we will make it easier for the unknown future usecase.

-Raj

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 18 Aug 2008 14:23:56 -0700 (PDT)

Hi Raj,

> the spec, we will make it easier for the unknown future usecase.

Sure. But, we are not talking option foo. We are talking about a
context object that we allocated for a given session and we are
talking about that option usage in the signaling messages associated
to that session. It is up to the usecase how that option gets used.
In a specific usecase, the option itself may be used as the
key and may certainly require that to be carried in all messages and
in some messages, it may not be needed and hence can be dropped.
We can certainly apply all the restrictions as we want, with one use
case in mind, but that wont help all usecases. May be we can apply a
usage warning on the option that it MUST NOT be used for any other
purpose, other than for usecase "foo".

Sri

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 18 Aug 2008 14:23:58 -0700

Hello Sri,

I have to register my disagreement with your basic point here.

Sri Gundavelli wrote:
>
>     ................ But, if we are not

This goes against long-standing practice in the IETF.
Features without justification are not permissible in
protocol specifications.  Heck, even features _with_
justification are often expunged -- much to my
chagrin in the case of RFC3775.
> update, if its required in some other scenario.

Well, we didn't run out of RFC numbers yet.  More to the point,
when the actual use case surfaces, usually at that time we have
enough information to make a more appropriate specification for
the use of the optional feature.

Otherwise, one has to answer lots of questions:
- What if the GRE key does not match any existing one, but
    the deregistration is otherwise valid?
    Ans: new error code?  reject?  accept with new acceptance code?
            crash & burn  (well, O.K., this is not a good answer)?

- How is the optional feature configured?  tested?

- What if the LMA magically expects the optional feature, but
    gets a perfectly valid deregistration without the GRE keys,
    and one set of GRE keys had been exchanged?

I am sure there are other issues that would need resolution
along the same lines as these.

Regards,
Charlie P.

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 18 Aug 2008 17:24:23 -0400

Hi Ahmad,

Each PDN connection (or a mobility session as it is called in RFC 5213)
gets a different IP address. Therefore, the IP address can be used by
the MAG to indicate which particular mobility session is being refreshed
or deleted. So, do you still need the GRE key in the de-registration
PBU?

Vijay

> [mailto:[email-masked]] On Behalf Of Ahmad Muhanna
> Sent: Monday, August 18, 2008 12:36 PM
> To: Charles E. Perkins; Sri Gundavelli
> Cc: [email-masked]

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 18 Aug 2008 17:29:41 -0400

Sri,

This is kind of vague. You are talking about a future use-case, which
none of us have a clue about. We either have a use-case for including
the GRE key in every PBU or we don't. There is no such thing as, "lets
leave it in because someone may invent a use-case for it...". 

Future extensions can specify changes to the GRE key handling, if
required.

Vijay 

> From: Sri Gundavelli [mailto:[email-masked]] 
> To: Basavaraj Patil
> Cc: Vijay Devarapalli; Mohana Jeyatharan; [email-masked]

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 18 Aug 2008 14:38:38 -0700 (PDT)

Hi Charlie,

> I have to register my disagreement with your basic point here.

I see that, no disagreement there :)

> chagrin in the case of RFC3775.

Have we applied such restriction on Mobile Node Identifier option
(RFC-4283) ? I dont see its value in Rereg or Dereg messages,
once the association to HoA is notified.

Allowing a context to be carried in signaling messages, the same
context that is allowed for that session, is not any where close
to enabling new *hidden* features. I certainly agree, we should
not allow relaxed langauge in specs as means to allow new
features. But, I disagree this is the intent or possibly some
one can misuse it that way. I'd love to learn how that could be
achieved in this case.

I wish I knew what feature we the authors plan to enable by
making the option usage "optional" in a dereg message.

Sri

---

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

> once the association to HoA is notified.

RFC 4283 does not require this. It says

   In any case, it should be noted that as the identifier option is only
   needed on the first registration at the home agent and subsequent
   registrations can use the home address, the window of privacy
   vulnerability in this document is reduced as compared to [RFC3775].

However, I think it is a good idea to include the MN-ID option in all
PBUs. For example, many implementations use the NAI to load balance the
sessions across multiple application blades in a chassis. The home
address is not present in the first message. It will be hard to figure
out which application blade is hosting the session state for a
particular mobile node without this identifier.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 18 Aug 2008 14:58:13 -0700 (PDT)

> particular mobile node without this identifier.

Thank you !

Why cant some other implementation use the GRE key the same way ?
This is the exact reason why I prefer to allow the GRE key to be
allowed to be carried in all messages. You have seen the value of
MN-Id in some case, that none of the specs ever talked and you have
used it nicely and without harming the protocol. Why this load
balancing should not be disallowed ? Should we tighten 4283 and
diallow this usage ? :) Same logic for GRE key.

Sri

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 18 Aug 2008 18:03:23 -0400

> Why cant some other implementation use the GRE key the same way ?

Huh... Because it cannot be guaranteed to be unique. Two different MAGs
can use overlapping GRE key space.

> diallow this usage ? :) Same logic for GRE key.

If you want to load balance using GRE keys, best of luck!! :)

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 18 Aug 2008 15:07:37 -0700 (PDT)

> can use overlapping GRE key space.

The NAI spec is not written for this purpose. The point is, your
implementation is using a context object for lookup/processing it
certain way. The GRE key can be used the same way, for some other
lookup and hence its a good idea to be allowed in all messages.

Sri

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 18 Aug 2008 17:11:30 -0500

Sri,

If you cannot explain how the optional GRE key is used, I don't see any
reason to include it. When someone has a good reason for it, they can extend
the protocol. There is nothing that expressly prevents it at such time in
the future.

-Raj

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 18 Aug 2008 18:13:26 -0400

> certain way. 

RFC 4283 specifies an identity for a particular mobile node that does
not change across subnet movements. Using that identity for load
balancing is a perfectly valid scenario. In fact, I am sure most
implementations do this.

> The GRE key can be used the same way, for some other

Since the beginning of this thread, I have been asking for a concrete
use-case, not some vague imaginary one.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 18 Aug 2008 15:16:13 -0700 (PDT)

Hi Raj,

> the protocol. There is nothing that expressly prevents it at such time in

I disagree. Vijay provided a usecase for NAI option and I believe
the GRE key can be used in a similar way or other implementation
specific manner.

Thanks
Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 18 Aug 2008 15:19:20 -0700 (PDT)

> balancing is a perfectly valid scenario. In fact, I am sure most

But, the identity is not needed once the HoA is present. As the
relation between the two parameters is bound after the initial
registration.

Lets leave the thread with this disagreement. I will let others
comment. If the WG does not see its need, fine with me.

Thanks
Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 18 Aug 2008 17:54:09 -0500

Hi All,

Wow! I did not expect all of this email exchange for this tiny issue:)
I want to make sure that we all agree that the inclusion of GRE key in
re-registration is mandatory. 
However, people seems to have disagreement on the inclusion of the GRE
option in de-registration PBU.

We also, need to remember that there is nothing in the GRE draft which
suggest that the GRE key is used for identifying BCEs or the BCE lookup
in the way MN-ID is used. The best that could be indirectly understood
is that the downlink GRE key is unique per a MAG-LMA pair while the
uplink is unique per an LMA/HA.

Regards,
Ahmad

> [mailto:[email-masked]] On Behalf Of Sri Gundavelli
> Sent: Monday, August 18, 2008 5:19 PM
> To: Vijay Devarapalli
> Cc: [email-masked]
> But, the identity is not needed once the HoA is present. As 
> the relation between the two parameters is bound after the 
> initial registration.
> 
> Lets leave the thread with this disagreement. I will let 
> others comment. If the WG does not see its need, fine with me.
> 
> Thanks
> Sri
>

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 18 Aug 2008 19:01:08 -0400

Hi Ahmad,

> option in de-registration PBU.

The initial email was only about the de-registration PBU. But now we are
talking about both the refresh and de-registration PBU. 

IMO, we don't need to include the GRE key in the refresh PBU either.

> uplink is unique per an LMA/HA.

Right.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 18 Aug 2008 18:03:01 -0500

Hi Vijay,

> The initial email was only about the de-registration PBU. But 
> now we are talking about both the refresh and de-registration PBU. 
> 

[Ahmad]
But re-registration after a handoff, the inclusion of GRE option is a
MUST. No?

> > suggest that the GRE key is used for identifying BCEs or the BCE 
> > lookup in the way MN-ID is used. The best that could be indirectly 
> > understood is that the downlink GRE key is unique per a 
> MAG-LMA pair 
> > while the uplink is unique per an LMA/HA.
> 
> Right.
> 
> Vijay
> 
> > 
> > Regards,
> > Ahmad
> >  
> >

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 18 Aug 2008 16:04:28 -0700 (PDT)

> IMO, we don't need to include the GRE key in the refresh PBU either.

What if the key changes at the MAG, still we should not carry it in rereg 
?

Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 18 Aug 2008 18:19:53 -0500

Hi Vijay,

> Each PDN connection (or a mobility session as it is called in 
> RFC 5213) gets a different IP address. 

[Ahmad]
Currently that is true. 
However, if we ever support secondary and primary PDP connections, then
all of those PDP connections may possibly end up having the same IP
address/HNP. But we can ignore this one for now:)

> Therefore, the IP 
> address can be used by the MAG to indicate which particular 
> mobility session is being refreshed or deleted. So, do you 
> still need the GRE key in the de-registration PBU?

[Ahmad]
I agree. According to RFC3775 and RFC5213, the BCE is identified without
the need for the GRE key. This means that the GRE key is not needed.
But, I still believe that there is no harm of including it in the
de-registration, but I am fine if the group decides that it is not
needed. 

<as a side note>, if the GRE key needs to be used for the BCE lookup, it
should be the uplink GRE key which is unique per LMA/HA rather than
downlink GRE key which is unique per MAG-LMA pair, but that is quite a
stretch from the original GRE key draft objective, especially after
symmetric GRE keys have been disallowed:)

Best Regards,
Ahmad

> > registering multiple PDN connections where each connection 
> is assigned 
> > a GRE key, It will be useful to send a de-registration 
> which include 
> > the MN-ID and the GRE key associated with that connection. Also, if 
> > bulk registration is supported, bulk de-registration for specific 
> > connections but not all is also possible. In that case, 
> including the 
> > GRE key would be helpful too.
> > 
> > Regards,
> > Ahmad
> >  
> >

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 18 Aug 2008 19:26:00 -0400

> But re-registration after a handoff, the inclusion of GRE option is a

The initial PBU from every MAG should of course include it. So the
inclusion of the GRE key option would coincide with the change of Proxy
CoA.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 18 Aug 2008 18:31:36 -0500

> The initial PBU from every MAG should of course include it. 
> So the inclusion of the GRE key option would coincide with 
> the change of Proxy CoA.

[Ahmad]
But the downlink GRE key lifetime is tied to the lifetime of the BCE and
it is only valid during that period of time. If the MAG decides to send
a PBU to refresh the BCE lifetime, it needs to include the GRE key. I
believe Charlie mentioned the same thing in one of his comments; i.e.
inclusion of GRE key in re-registration is granted if the GRE key
lifetime is tied to the BCE lifetime.

Best Regards,
Ahmad

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 18 Aug 2008 16:42:36 -0700

Hi Ahmad,

Ahmad Muhanna wrote:
> it is only valid during that period of time. 

Is it? Do we have a concept called the GRE Key lifetime? I thought the 
MAG allocates a GRE key and uses it for the entire duration of the 
mobility session. Once the mobility session is torn down, the key is 
released. The GRE key allocation by itself does not have a timer 
associated with it.

 > If the MAG decides to send

If we do tie the GRE key lifetime to binding lifetime, then we need to 
send it in refresh PBU. But the thing I don't understand is why do we 
have to associate a lifetime with the GRE key to begin with? You just 
use the next available one. If the session is torn down, it is released.

Can't we assume that as long the mobile node is attached to a particular 
MAG, the GRE key does not change for a particular mobility session (or 
the PDN connection)?

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 19 Aug 2008 08:02:03 -0500

Hi Vijay,

> the change 
> >> of Proxy CoA.
> > But the downlink GRE key lifetime is tied to the lifetime 
> of the BCE 
> > and it is only valid during that period of time.
> 
> Is it? Do we have a concept called the GRE Key lifetime? I 
> thought the MAG allocates a GRE key and uses it for the 
> entire duration of the mobility session. Once the mobility 
> session is torn down, the key is released. The GRE key 
> allocation by itself does not have a timer associated with it.

[Ahmad]
Yes.
In this case, GRE key is dynamically negotiated and it is expected to be
valid for a specific time, exactly like the HNP, IP address, etc.
Otherwise, why do we have a session lifetime. In my mind, It is no
different than the IP address, HNP, etc. 

> If we do tie the GRE key lifetime to binding lifetime, then 
> we need to send it in refresh PBU. But the thing I don't 
> understand is why do we have to associate a lifetime with the 
> GRE key to begin with? You just use the next available one. 
> If the session is torn down, it is released.

[Ahmad]
Sure, you always can use the next available GRE key.

The bottom line is, if we do not associate a lifetime with the GRE keys,
we end up with a 4.295 Billion statically allocated GRE keys. Well, we
will run out of these fast and very quickly:)

> 
> Can't we assume that as long the mobile node is attached to a 
> particular MAG, the GRE key does not change for a particular 
> mobility session (or the PDN connection)?
> 
> Vijay
> 
> > 
> > Best Regards,
> > Ahmad
> > 
> > 
> >> Vijay
> >>

---

From: Julien Laganier <[email-masked]>
Date: Tue, 19 Aug 2008 15:28:33 +0200

Hi Vijay,

I think it makes sense to adopt the following simple protocol design:

- A downlink (resp. uplink) GRE key is valid as long as the binding 
cache entry for which it was allocated remains valid, unless a new 
downlink (resp. uplink) GRE key is sent in a PBU (resp. PBA) by the MAG 
(resp. LMA), in which case the old downlink (resp. uplink) GRE key can 
be returned to the available pool of downlink (resp. uplink) GRE keys on 
the MAG (resp. LMA).

- When GRE encapsulation is in use, all PBUs are PBAs MUST contain the 
GRE key option expect those for binding deregistration.

What do you think?

--julien

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 19 Aug 2008 07:17:58 -0700

Hi Julien,

> GRE key option expect those for binding deregistration.

I prefer a solution where the downlink GRE key is included in the PBU only
if it is being changed. The initial PBU and the first PBU sent by a MAG
after a handover would always include the GRE key, of course. I think this
is simpler.

Vijay

---

From: Julien Laganier <[email-masked]>
Date: Tue, 19 Aug 2008 16:22:34 +0200

> after a handover would always include the GRE key, of course. I think this

I am fine with the GRE key being sent only when it is changed, but I 
don't think we should differentiate b/w downlink and uplink. And the key 
to remain valid unless a new one is sent in a PBU or a PBA.

--julien

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 19 Aug 2008 07:27:29 -0700

> to remain valid unless a new one is sent in a PBU or a PBA.

Agree. The same would apply to the uplink GRE key and the PBA message.

Vijay

---

From: "Premec, Domagoj" <[email-masked]>
Date: Tue, 19 Aug 2008 16:29:04 +0200

> - A downlink (resp. uplink) GRE key is valid as long as the 
> binding cache entry for which it was allocated remains valid, 

GRE keys may not always be associated with a single BCE, one example is when GRE is used to support overlapping private IPv4 addresses, there would be one key pair per IPv4 domain. We should formulate this carefully so that per-domain static GRE keys are possible.

domagoj

> [mailto:[email-masked]] On Behalf Of Julien Laganier
> Sent: 19. kolovoz 2008 15:29
> To: Vijay Devarapalli
> Cc: [email-masked]
> - A downlink (resp. uplink) GRE key is valid as long as the 
> binding cache entry for which it was allocated remains valid, 
> unless a new downlink (resp. uplink) GRE key is sent in a PBU 
> (resp. PBA) by the MAG (resp. LMA), in which case the old 
> downlink (resp. uplink) GRE key can be returned to the 
> available pool of downlink (resp. uplink) GRE keys on the MAG 
> (resp. LMA).
> 
> - When GRE encapsulation is in use, all PBUs are PBAs MUST 
> contain the GRE key option expect those for binding deregistration.
> 
> What do you think?
> 
> --julien
> 
> Vijay Devarapalli wrote:
> > 
> >> [Ahmad]
> thought the 
> we need to 
> > particular MAG, the GRE key does not change for a 
> particular mobility 
> > session (or the PDN connection)?
> 
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 19 Aug 2008 10:13:15 -0500

Hi Julien and Vijay,

> >>> downlink (resp. uplink) GRE key is sent in a PBU (resp. 
> PBA) by the 
> >>> MAG (resp. LMA), in which case the old downlink (resp. 
> uplink) GRE 
> >>> key can be returned to the available pool of downlink 
> (resp. uplink) 
> >>> GRE keys on the MAG (resp. LMA).
> >>> 
> >>> - When GRE encapsulation is in use, all PBUs are PBAs 
> MUST contain 
> >>> the GRE key option expect those for binding deregistration.
> >>> 
> >>> What do you think?
> >> 
> >> I prefer a solution where the downlink GRE key is included 
> in the PBU 
> >> only if it is being changed. The initial PBU and the first 
> PBU sent 
> >> by a MAG after a handover would always include the GRE key, of 
> >> course. I think this is simpler.
> > 
> > don't think we should differentiate b/w downlink and 
> uplink. And the 
> > key to remain valid unless a new one is sent in a PBU or a PBA.
> 

[Ahmad]
This is what I understood from what you are agreeing ion guys. Correct
me if I am wrong.

I. MAG is allowed to change the downlink GRE key by including the GRE
option in the PBU:

1.1. The LMA update the BCE accordingly and return the same old uplink
GRE key.
1.2. The LMA update the BCE accordingly and return a new uplink GRE key
in PBA for the MAG to update the MN binding.

Okay, what about if the LMA would like to update the uplink GRE key upon
BCE lifetime expiry?

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 19 Aug 2008 10:16:58 -0500

Hi Domagoj,

> > cache entry for which it was allocated remains valid,
> 
> GRE keys may not always be associated with a single BCE, one 
> example is when GRE is used to support overlapping private 
> IPv4 addresses, there would be one key pair per IPv4 domain. 
> We should formulate this carefully so that per-domain static 
> GRE keys are possible.

[Ahmad]
Good point. 
However, that should be left for implementation to take care of.
The MAG should not dynamically allocate a downlink GRE key that
conflicts with any statically configured GRE keys. The LMA should do the
same.

We can capture some text with that meaning in the draft. What do you
think?

> > downlink (resp. uplink) GRE key is sent in a PBU (resp. PBA) by the 
> uplink) GRE key 
> > can be returned to the available pool of downlink (resp. 
> uplink) GRE 
> > keys on the MAG (resp. LMA).
> > 
> contain the

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 19 Aug 2008 09:09:49 -0700 (PDT)

> GRE keys may not always be associated with a single BCE, one example is when GRE is used to support overlapping private IPv4 addresses, there would be one key pair per IPv4 domain. We should formul…

I agree. The key allocation or the usage is upto the deployment.
The spec will be flexible to support all the type of key usages.

Sri

---

From: Julien Laganier <[email-masked]>
Date: Tue, 19 Aug 2008 18:53:34 +0200

Domagoj,

It should be left up to the party sending a GRE key how it allocates it, 
it's a local matter as it's the only entity receiving packets 
encapsulated with that key. From that perspective I don't see any 
concerns with static GRE key allocation in some deployments.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Tue, 19 Aug 2008 18:50:52 +0200

> Agree. The same would apply to the uplink GRE key and the PBA message.

That was what I had in mind as well. Any endpoint can change the GRE key 
by sending a new one in a PBU or PBA. The other end should consider the 
new key as the key for the BCE, but probably still accept packets sent 
on the old key for a while to catch inflights packets (those sent before 
the new GRE key is established on the sending side and that arrive after 
the new GRE key has been configured on the receiving side)

--julien

---

From: Julien Laganier <[email-masked]>
Date: Tue, 19 Aug 2008 19:03:42 +0200

Hi Ahmad,

Ahmad Muhanna wrote:
>> unless a new 

Yes.

> Okay, what about if the LMA would like to update the uplink GRE key upon

Not sure I get that one, if the BCE lifetime expires, the BCE expires 
and no GRE key is needed anyway.

If the BCE hasn't expired yet, the MAG will refresh the lifetime with 
PBU, and there I think the LMA can send a new uplink key in the PBA sent 
in return.

--julien

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 19 Aug 2008 12:09:02 -0500

Hi Julien,
> > 1.2. The LMA update the BCE accordingly and return a new uplink GRE 
> > key in PBA for the MAG to update the MN binding.
> 
> Yes.
> 
> > Okay, what about if the LMA would like to update the uplink GRE key 
> > upon BCE lifetime expiry?
> 
> Not sure I get that one, if the BCE lifetime expires, the BCE 
> expires and no GRE key is needed anyway.
>
[Ahmad]
sure, if no PBU received.
 
> If the BCE hasn't expired yet, the MAG will refresh the 
> lifetime with PBU, and there I think the LMA can send a new 
> uplink key in the PBA sent in return.

[Ahmad]
Yes, this one what I was looking for. 
If the LMA is allowed to include a new uplink GRE key in the PBA, then I
believe the MAG should include the downlink GRE key option in all
re-registration PBU.

---

From: Julien Laganier <[email-masked]>
Date: Tue, 19 Aug 2008 19:22:10 +0200

> believe the MAG should include the downlink GRE key option in all

Not sure I follow. What should it be? The LMA does not necessarily need 
to receive the unchanged downlink GRE key when it wants to change the 
downlink one...

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 19 Aug 2008 10:35:19 -0700 (PDT)

>>> upon BCE lifetime expiry?

The life of the GRE key is valid as long as the BCE exists.
There should not be a concept of key life time. As other
also commented.

Its not required that the key must be present in the reregs,
in order for the key life to be extended. Update to BCE
will extend the life of all resources part of that BCE,
including addresses and keys.

Key can be present only if there is a change in the key.
(no reason to disallow its presence either if no change).
How the old key needs to be handled during the transient
period requires some thought.

Looking at the discussion, with the initial comments from
some that the key must be present only in the initial
PBU, later its presence in all initial PBU's after handoff,
now we see its need in all re-regs (no handoff).

This leaves just the dereg messages. So, I guess we will
find one more usecase and till then we can argue to force
not to include it in that message. Raj: We are find usecases
for option foo :)

Sri

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 19 Aug 2008 11:13:08 -0700

Hello Sri,

I'd like to offer another model of operation
that makes more sense to me.

I think the binding messages are supposed to
manage the BCEs, which have lifetimes.

I think the GRE keys are supposed to identify
the GRE tunnel which carries traffic in service
of an authenticated BCE.

As long as the BCE is valid (i.e., registration
current and all that), the GRE tunnel resources
are needed and should not be deallocated.

If a BCE is created, and GRE keys supplied,
then a GRE tunnel, if not already available for the
purpose and indexed by the given GRE key,
should be created to carry the traffic.

In this model, as long as the BCE is periodically
refreshed using PBU/PBA, then the tunnel remains
live and does not need to be torn down and recreated.

Thus, there is no need for GRE key lifetime, and
no need for re-registrations to carry new or old
keys.

Regards,
Charlie P.

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 19 Aug 2008 11:51:23 -0700 (PDT)

Hi Charlie,

Thanks. One comment.

We should have the ability to change the keys during the
session and without tearing down the session. Thats the 3GPP
usecase. Also, not sure if we should look at the GRE tunnel as
a tunnel for a specific key. We can certainly keep the tunnel
and still change the key. Its a flow identifier from the perspective
of the GRE Key and Seq Number extension spec. It requires key
presence in some signaling messages, if we want to change the
keys.

Regards
Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 19 Aug 2008 16:50:06 -0500

> usecase. 
[Ahmad]
I am not against allowing the GRE key to be changed, but it will be
helpful to point us to where that 3GPP requirement is captured?

> Also, not sure if we should look at the GRE tunnel 
> as a tunnel for a specific key. We can certainly keep the 
> tunnel and still change the key. 
[Ahmad]
I am not sure what does this mean:)
In the context of this draft and its usecase, keeping the tunnel without
a GRE key makes no sense to me. 

> > I'd like to offer another model of operation that makes 
> more sense to 
> > me.
> >
> > I think the binding messages are supposed to manage the BCEs, which 
> > have lifetimes.
> >
> > I think the GRE keys are supposed to identify the GRE tunnel which 
> > carries traffic in service of an authenticated BCE.
> >
> > As long as the BCE is valid (i.e., registration current and 
> all that), 
> > the GRE tunnel resources are needed and should not be deallocated.
> >
> > If a BCE is created, and GRE keys supplied, then a GRE 
> tunnel, if not 
> > already available for the purpose and indexed by the given GRE key, 
> > In this model, as long as the BCE is periodically refreshed using 
> > PBU/PBA, then the tunnel remains live and does not need to be torn 
> > down and recreated.
> >
> > Thus, there is no need for GRE key lifetime, and no need for 
> > re-registrations to carry new or old keys.
> >
> > Regards,
> > Charlie P.
> >
> >
> >
> > Sri Gundavelli wrote:
> >> 
> >> 
> >> 
> >> > > 
> >> > > >  Okay, what about if the LMA would like to update the uplink 
> >> > > > GRE key  upon BCE lifetime expiry?
> >> > > 
> >> 
> >>
> >>  There should not be a concept of key life time. As other  also 
> >> commented.
> >>
> >>  Its not required that the key must be present in the reregs,  in 
> >> order for the key life to be extended. Update to BCE  will 
> extend the 
> >> life of all resources part of that BCE,  including addresses and 
> >> keys.
> >>
> >>  How the old key needs to be handled during the transient  period 
> >> requires some thought.
> >>
>  some that 
> >> the key must be present only in the initial  PBU, later 
> its presence 
> >> in all initial PBU's after handoff,  now we see its need in all 
> >> re-regs (no handoff).
> >>
> find one 
> >> more usecase and till then we can argue to force  not to 
> include it 
> >> in that message. Raj: We are find usecases  for option foo :)
> >> 
> >>
> >>  Sri
> >>

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 19 Aug 2008 15:08:27 -0700 (PDT)

> helpful to point us to where that 3GPP requirement is captured?

Ok. If this is not required in 3GPP, I'm fine as well. As
I understood, at handoff the key associated with a session
may change. If this assumption is incorrect, we can remove
it.

> a GRE key makes no sense to me.

This is in response to Charlie's other suggestion of creating a
tunnel with a given GRE key, and keeping it till termination.

Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 19 Aug 2008 17:18:38 -0500

> session and 
> >> without tearing down the session. Thats the 3GPP usecase.
> >>
> > [Ahmad]
> Ok. If this is not required in 3GPP, I'm fine as well. As I 
> understood, at handoff the key associated with a session may 
> change. If this assumption is incorrect, we can remove it.

[Ahmad]
Of course, this is a MUST have functionality for the draft. Sorry, I
thought you meant GRE key change without handoff:)
I would also say that since we removed the option of symmetric GRE key,
this functionality MUST be supported, otherwise, we have a problem:)
 
> 
> 
> 
> >> Also, not sure if we should look at the GRE tunnel as a 
> tunnel for a 
> >> specific key. We can certainly keep the tunnel and still 
> change the 
> >> key.
> > [Ahmad]
> > In the context of this draft and its usecase, keeping the tunnel 
> > without a GRE key makes no sense to me.
> >
> 
> This is in response to Charlie's other suggestion of creating 
> a tunnel with a given GRE key, and keeping it till termination.
> 
> Sri
> 
> 
> 
> 
> >>
> >> Regards
> >> Sri
> >>
> >>
> >>
> >>>>>>>  Okay, what about if the LMA would like to update the 
> uplink GRE 
> >>>>>>> key  upon BCE lifetime expiry?
> >>>>>>
> >>>>
> >>>>

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 19 Aug 2008 15:24:47 -0700 (PDT)

> this functionality MUST be supported, otherwise, we have a problem:)

No problem. This was my comment for Charlie's proposal .. that
approach logically sounds good. Just that we cant change the
key once a PMIP session is setup....

Sri

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 19 Aug 2008 15:38:26 -0700

Hello Sri,

A short comment:

>    ...   This was my comment for Charlie's proposal .. that

My suggestion should not be interpreted this way.
In fact, even on a live tunnel, the keys could be
changed as needed.   And since the tunnels are
pretty much virtual resources, we have a lot of
flexibility about how we manage them.

I just wanted to offer what I considered to be a
simple yet effective model of operation, so we could
more easily think about the requirements for the
protocol for managing that operation.

I'm leaving town for several days, but I'll try to
rejoin the discussion next week.

Regards,
Charlie P.

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 19 Aug 2008 16:11:30 -0700 (PDT)

Hi Charlie,

> My suggestion should not be interpreted this way.

Ok. Will follow up on this.

> rejoin the discussion next week.

Sure.

Thanks
Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 19 Aug 2008 19:07:25 -0500

> > thought you meant GRE key change without handoff:) I would also say 
> > that since we removed the option of symmetric GRE key, this 
> > functionality MUST be supported, otherwise, we have a problem:)
> >
> 
> No problem. This was my comment for Charlie's proposal .. 
[Ahmad]
Well, I am not sure if this usecase is applicable to the model that
Charlie proposed. My reading of Charlie proposal is that GRE keys do not
be included in the re-registration PBU/PBA, after they have been
exchanged during initial PBU/PBA, to update the same GRE tunnel. My
reading is that the proposal was talking about the same GRE tunnel which
means that handoff case is not included in that proposal. Because, very
simply, after handoff the GRE tunnel is NO longer the same GRE tunnel.
We have a new GRE tunnel between the Target MAG and the LMA with end
points of Target pCoA and LMAA. That is why the target MAG MUST include
the GRE key option with its own downlink GRE key in its initial PBU,
which is viewed at the LMA as a re-registration but in fact it is an
initial one; especially we are talking about Proxy MIP6 not client MIP6.
Incidentally, the downlink GRE key picked by the target MAG could be the
same as the downlink GRE key that was used by the source MAG.

BTW: that also contributed to my initial confusion when you mentioned
3GPP requirement, because in my mind handoff is more of an initial GRE
key exchange than re-registration:)

Cheers!

> that approach logically sounds good. Just that we cant change 
> the key once a PMIP session is setup....
> 
> Sri
> 
>

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 19 Aug 2008 19:26:53 -0700 (PDT)

> initial one; especially we are talking about Proxy MIP6 not client MIP6.

Ok, I agree with this interpretation. The use of term of initial
registration implied its new BCE/session creation. I thought, we
were using the terms, rereg (no handoff) or rereg (after handoff)
and so I'm not sure how the initial-reg implied a rereg after
handoff. Any case, we are on the same page.

Talking to Vijay offline and from this, we can conclude:

The presence of key is mandatory during a) initial key setup b)
during key refresh, i.e at the time of handoff, or tunnel setup
at the new MAG as Charlie pointed out.

If key is present even during rereg (no handoff) i.e when there
is no key refresh, LMA will not treat this as an error.  In other
words its not a protocol violation to include the key, when
there is no key change. If there is no issue with this from you
as well, we can close this.

Thanks
Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 19 Aug 2008 22:13:42 -0500

> > points of Target pCoA and LMAA. That is why the target MAG MUST 
> > include the GRE key option with its own downlink GRE key in its 
> > initial PBU, which is viewed at the LMA as a re-registration but in 
> > fact it is an initial one; especially we are talking about 
> Proxy MIP6 not client MIP6.
> 
> Ok, I agree with this interpretation. The use of term of 
> initial registration implied its new BCE/session creation. I 
> thought, we were using the terms, rereg (no handoff) or rereg 
> (after handoff) and so I'm not sure how the initial-reg 
> implied a rereg after handoff. Any case, we are on the same page.
> 
> The presence of key is mandatory during a) initial key setup 
> b) during key refresh, i.e at the time of handoff, or tunnel 
> setup at the new MAG as Charlie pointed out.
> 
> If key is present even during rereg (no handoff) i.e when 
> there is no key refresh, LMA will not treat this as an error. 
>  In other words its not a protocol violation to include the 
> key, when there is no key change. If there is no issue with 
> this from you as well, we can close this.

[Ahmad]
Thanks Sri!
This is fine with me too.