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

[Xiangsong Cui <[e-mail]>]

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: Monday, August 03, 2009 4:47 PM
Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00



On Aug 3, 2009, at 10:38 AM, Xiangsong Cui wrote:

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

In grekey-draft scope because, the LMA needs to know the connection id
already when receiving the PBU. The MAG needs to include a connection
id in the PBU. Downlink key is not really good for this purpose.

[Xiangsong] Where do you get the requirement of "know the connection id
already when receiving the PBU"? Is it base on your solution?
In my understanding, the requirement should be
"can identify the connection among multiple PDN connections"
and GRE key option can meet the requirement well.


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

You impact BCE lookup. That is one main reason why to bring this stuff
to IETF in the first place. If it were completely protocol agnostic,
we would have kept it inside 3GPP.

[Xiangsong] Comparing to simple PMIP, the GRE key option do impact BCE
lookup, but if the LMA support GRE key option, all work well, what is
the trouble? Your connection id option do also impact BCE lookup,
they are same essentially.


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

And? I don't see the point as I wrote that text in the draft ;) I
should probably clarify that the quoted text means mapping of e.g.
some radio level "bearer" to some identity value used as connection id.

[Xiangsong] This more and more like a game.

In general, do you mean when we have already had a RFC, which says
"GRE keys can be used for marking the downlink and uplink traffic ",
we additionally need another document, which says
"define a new option to be used for identifying conncetion" ?

Xiangsong



Jouni

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