Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00

[jouni korhonen <[e-mail]>]

Lets first resolve whether the GRE keys are usable in the first place.  
Then we can return to the rest of the discussion. Some more stuff  
inline.

On Jul 31, 2009, at 1:00 PM, Xiangsong Cui wrote:

> Hi Jouni,
> Please see inline.
>
> Regards/Xiangsong
>
>
> ----- Original Message ----- From: "jouni korhonen" <[e-mail] 
> >
> To: "Xiangsong Cui" <[e-mail]>
> Cc: <[e-mail]>; <[e-mail]>
> Sent: Friday, July 31, 2009 5:16 PM
> Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6- 
> connid-00
>
>
>> Hi,
>> On Jul 31, 2009, at 7:11 AM, Xiangsong Cui wrote:
>>> Hi Jouni,
>>>
>>> Thank you for your response.
>>>
>>>> There are few reasons. First, which GRE key to use? Uplink or    
>>>> downlink?
>>> I think Uplink and downlink may be used to identify the connection
>> Uh.. so you would use combination of both keys simultaneously?
>
> Yes, I think GRE Key is designed for this manner.

I am a bit confused. Do you mean using 64-bit identifier made of both  
uplink & downlink GRE keys?

Anyway, downlink GRE keys are no good in general as they may change  
during handovers. If there is context transfer between MAGs it still  
does not solve the downlink key issue. One would need to start  
coordinating downlink key space between MAGs, which is a new  
requirement.

The Uplink GRE key would be an usable connection Id, assuming MAGs can  
do a context transfer, the exception mentioned in Section 3.3.2 of  
draft-ietf-netlmm-grekey-option does not happen and that GRE is used  
in the first place. However, the GRE key option in a PBU contains only  
the downlink key. This means, you need something beyond draft-ietf- 
netlmm-grekey-option to send the uplink GRE key in the PBU (if the  
uplink GRE key were used as the connection Id).

[snap]

>>>>
>>>> Second, the use of GRE keys and GRE tunneling is optional in   
>>>> PMIP6.  Well, so is Service Selection too but I would avoid   
>>>> building  additional dependencies between different documents if   
>>>> just possible.
>>> Yes, GRE Key is an optional option. I think an optional option is  
>>> used
>>> for a optional feature is reasonable
>> The less the better. I.e. if I can choose between two optional   
>> features versus three optional features, I would go for two.
>>>
>>>>
>>>> Third, overloading the function of the GRE key option does not   
>>>> sound a good idea in general, even if it were possible.
>>> If it works well, why not take it as the solution?
>> Overloading existing semantics is always a bad practice.
> Yes, I agree it is a trouble.
> But if the overloading is in the acceptable scope, IMO, we need  
> balance the impact of  overloading and introducing a new expansion.
> It is the motivation behind my original question.

You would still need a document that describes how the GRE keys are  
used to extend the BCE lookup, how they are used with RFC5149, and how  
to indicate to the LMA that the GRE keys are used in this special  
overloaded way etc. If you go down this road, what is the benefit of  
it over defining a new option specifically made for connection  
identifier purpose? At the end, the connection identifier content can  
be anything that is a stable identifier within the system where this  
extension is being used.. be that a GRE key or not.

Cheers,
	Jouni


>
>> I'll skip the rest as I don't see how they relate to this discussion.
>> Cheers,
>> Jouni
> [snip]
>


>