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

[Xiangsong Cui <[e-mail]>]

Hi Jouni,

> As said, a PBU can only have the downlink key as per grekey-draft and 
> downlink key as-is is not enough.
[...snip...]
> As said, for signaling uplink GRE key in a PBU you would need  something 
> beyond grekey-draft.

Why do you exclude PBA message?
The MAG and the LMA can learn both the downlink key and the uplink key
by PBU/PBA exchange.



> 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..

I don't think so.

As I said in the previous mail, GRE key option can already meet the
protocol requirement, we don't need any more option for this feature.

As to the behavior in the MAG and the LMA, it is mainly about the
mapping management, I don't think it is in the protocol scope.
I also think you would agree me on this point, because in the draft
"draft-wolfner-netext-pmip6-connid-00.txt", it says:

"  How the MAG maps connections originated from the
   MN to connection identifiers is out of scope of this specification."


Regards

Xiangsong


----- Original Message ----- 
From: "jouni korhonen" <[e-mail]>
To: "cuixiangsong 00111037" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Monday, August 03, 2009 3:00 PM
Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00



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>