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

[jouni korhonen <[e-mail]>]

Hi Xiangsong,

On Aug 2, 2009, at 5:08 AM, cuixiangsong 00111037 wrote:

[snip]

>
> Now let's consider how can we use GRE key to achieve this requirement.

I already said that uplink key could be an usable connection id as a  
*value*, if other conditions match.

>
> I assume the MAG and the LMA both support GRE key option and
> connection feature.

Point one, we don't want to mandate GRE keys.. even if those in  
practice would be there. From draft-wolfner-* point of view, GRE keys  
are/can be "lower layer" information. However, specifically saying the  
connection id is *the* GRE key, is not what we want. There is  
absolutely no need to bind this draft to grekey-draft.

>
> Firstly, when MAG sends PBU message to LMA, the MAG creats a down
> link GRE key and maps the down link GRE key to the connection
> originated from MN. The MAG includes the GRE key option in the PBU
> as specified in grekey-draft, and also includes a Service Selection
> Mobility Option as speified in RFC5149.

As said, a PBU can only have the downlink key as per grekey-draft and  
downlink key as-is is not enough.

>
> Secondly, when the LMA receives the PBU message from the MAG,
> the LMA deals the message and the options as specified in existing
> documents. After the LMA creats BCE and a uplink GRE key, the LMA
> caches the MN-id, Service Selection, downlink GRE key and uplink
> GRE key in the BCE and also associates both the downlink GRE key
> and the uplink GRE key with the PDN connection. The LMA responds
> PBA message to the MAG, with the uplink GRE key option included.

As said, for signaling uplink GRE key in a PBU you would need  
something beyond grekey-draft.


>
> Thirdly, when the MAG receives the PBA from the LMA, the MAG caches
> the uplink GRE key and associates both the downlink GRE key and
> uplink GRE key with the connection to MN. The MN also knows well
> the MN id and the Service Selection.

See above.

[snip]


> That means, both the LMA and the MAG can use the GRE keys included in
> the GRE header to identify the data packet, or identify the traffic  
> flow.
>
> So, the connection is iedntified by the combination of "MN id + GRE  
> key
> + Service Selection(i.e. APN)". In fact, the connection is  
> fractionized,
> the direction from LMA to MAG is identified by "MN id + downlink GRE  
> key
> + APN" while the direction from MAG to LMA is identified by "MN id +
> uplink GRE key + APN". Each connection may be identified exactly.
>
>
> As to the handover, grekey-draft says, in section 3.3.2,
> " In this case, the new mobile access gateway may
>   either pick a new downlink GRE key or use the downlink GRE key that
>   was used by the previous mobile access gateway for the same binding.
>   For the new mobile access gateway to know the downlink GRE key used
>   by the previous mobile access gateway, it may require transfer of
>   context from the previous mobile access gateway to the new mobile
>   access gateway during a handoff.  Such mechanisms are out-of-scope
>   for this specification."
>
> This is for the downlink GRE key, and for the uplink GRE key, the
> grekey draft says:
>
> " If the local mobility anchor successfully processes a handoff-
>   triggered Binding Lifetime Extension Proxy Binding Update message
>   which contains a GRE key option with a downlink GRE key included,  
> the
>   local mobility anchor MUST return the same uplink GRE key that was
>   exchanged with the previous mobile access gateway for the same
>   mobility session in the GRE key option in a successful Proxy Binding
>   Acknowledgement."
>
>
> Above all, I think we can use the GRE key option to achieve the
> requirement of "multiple PDN connections to the same APN".
>
> Is it right or usable?

I think you are still missing the point here. You would still need a  
new option in a PBU, and document the behavior in the LMA and the MAG,  
even if the GRE uplink key were used as the connection id value. This  
is what draft-wolfner is aiming to..

Cheers,
	Jouni



>
>
> Regards
>
> Xiangsong
>
> ===============================================================
> ----- 原邮件 -----
> 发件人: jouni korhonen <[e-mail]>
> 日期: 星期五, 七月 31日, 2009 下午9:39
> 主题: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6- 
> connid-00
> 收件人: Xiangsong Cui <[e-mail]>
> 抄送: [e-mail], [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]
>>>
>>
>>
>>>
>>
>> _______________________________________________
>> netext mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netext
>>
> <c00111037.vcf>