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

[Xiangsong Cui <[e-mail]>]

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
for different direction. MAG and LMA know well both uplink and
downlink after the registration.

> Obviously, the MAG does not know the uplink GRE key when  sending a PBU 
> during the initial attach or after a handover.. so you  would lack the 
> "identifier" in the MAG in some situations.
I don't know in which situation the identifier would be lacking.
If you refer to handover, I think the GRE Key may also be a part
of the context, as connection-id does.


> If we were  to use the downlink key, according to the GRE key draft it is 
> not  guaranteed that the downlink remains the same between inter-MAG 
> handover.
The same problem with connection-id, if you use connection-id, can
you guarantee that the connection-id is always same?
Inter-MAG handover is the common issue for all identifiers.

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

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

I see many messages recently on the issue of expansion to protocol.

For example (Suresh and Vijay, I supposed you permit me to cite your words),

http://www.ietf.org/proceedings/75/slides/mext-0.ppt, slide 7,
Suresh says:
"There have been several extensions to CMIPv6;
.
But, there is no cohesive mobility architecture that holds these extensions 
together;
.
This causes a lot of confusion and incompatible implementations"

http://www.ietf.org/mail-archive/web/netext/current/msg00729.html,
Vijay says:
"One option would be to re-use the HA
Switch Message from RFC 5142 and carry the redirect mobility option in this
message. This would avoid defining a new message."

http://www.ietf.org/mail-archive/web/netext/current/msg00739.html,
Vijay also says:
It would be a bad idea to have two different sets of
mechanisms.

I'm also in the position, if we can re-use some mechanisms,
we need NO expansion, so the protocols may be more simple.

Regards

Xiangsong



----- Original Message ----- 
From: "jouni korhonen" <[e-mail]>
To: "Xiangsong Cui" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Thursday, July 30, 2009 11:49 PM
Subject: Re: [netext] Comments on I-D: draft-wolfner-netext-pmip6-connid-00


> Hi Xiangsong,
>
> On Jul 30, 2009, at 12:58 PM, Xiangsong Cui wrote:
>
>> Hello Raj and Jouni,
>>
>> I have a question about the draft.
>>
>> Firstly, I agree the requirement of multiple PDN connections
>> to the same APN.
>>
>> IMO, the major idea of this draft is as mentioned in the draft:
>>
>> The combination of MN-Identifier + Service Selection +
>> Connection Identifier can uniquely identify mobility sessions even if
>> the selected service on each mobility session for the same MN-
>> Identifier are the same.
>>
>> It recall me to another draft, "draft-ietf-netlmm-grekey- option-09.txt".
>> In the GREKEY draft, it says:
>>  This specification defines the GRE Key option to be used for the
>>  negotiation of GRE encapsulation mode and exchange of the uplink and
>>  downlink GRE keys.  The negotiated downlink and uplink GRE keys can
>>  be used for marking the downlink and uplink traffic for a specific
>>  mobility session.
>>
>> The connid draft is used to identify a certain session among
>> multiple sessions, while the grekey draft is used to identify a
>> certain link/flow in the tunnel between the MAG and the LMA.
>>
>> When I look at figure 1 in the grekey draft, it seems similar for the
>> both cases, because we just need to identify a connection, and the
>> connection may be a session or a flow.
>>
>> So I have the question:
>> if we expand the meaning of GRE Key option, without protocol  expansion,
>> can we use the combination "MN-Identifier + Service Selection + GRE  key"
>> to identify the connections to the same APN?
>
> There are few reasons. First, which GRE key to use? Uplink or  downlink? 
> Obviously, the MAG does not know the uplink GRE key when  sending a PBU 
> during the initial attach or after a handover.. so you  would lack the 
> "identifier" in the MAG in some situations. If we were  to use the 
> downlink key, according to the GRE key draft it is not  guaranteed that 
> the downlink remains the same between inter-MAG  handover.
>
> 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.
>
> Third, overloading the function of the GRE key option does not sound a 
> good idea in general, even if it were possible.
>
> Cheers,
> Jouni
>
>
>
>
>
>>
>> Regards
>>
>> Xiangsong
>>
>> ----- Original Message ----- From: <[e-mail]>
>> To: <[e-mail]>
>> Sent: Thursday, July 16, 2009 5:33 AM
>> Subject: [netext] Comments on I-D: draft-wolfner-netext-pmip6- connid-00
>>
>>
>>>
>>>
>>> Hello,
>>>
>>> A few questions/comments related to the proposal to add a connection
>>> identifier to the PMIP6 signaling and BCE:
>>>
>>> 1. Each of the PDN bearers will have a unique prefix assigned to it  by
>>>  the LMA, right? Even though the MN-ID remains the same the LMA will
>>>  have to create multiple BCEs for the MN. The scenario is equivalent
>>>  to the MN attaching via different interfaces thru the same MAG/LMA
>>>  pair.
>>>
>>> 2. The I-D says that the mechanism by which the MAG figures out that
>>>  a new bi-directional tunnel is needed to be established (and a new
>>>  prefix obtained) is out of scope. In certain networks you are
>>>  obtaining this information from L2 and is used by the MAG. Current
>>>  RFC5213 lacks the ability by which an MN (which is already attached
>>>  via an interface) can request dynamically a new prefix to be
>>>  assigned to it for the same interface. The connection ID would be
>>>  useful if we were to also specify how the MN can request an
>>>  additional prefix via an interface that is already attached and has
>>>  been assigned a prefix from a MAG/LMA pair.
>>>  It might be useful to explain how L2s can provide such indications  in 
>>> an
>>> appendix.
>>>
>>> 3. In the case of HO the target MAG will not be aware of the CID
>>>  unless there a context transfer mechanism between the MAGs. Please
>>>  note the I-D draft-ietf-mipshop-pfmipv6-08.txt which proposes
>>>  context transfer capability between MAGs.
>>>
>>> 4. If each PDN bearer is assigned a unique prefix, can you not use  the
>>>  HNP assigned as the CID?
>>>
>>> I do agree with the need to support the ability by which multiple
>>> mobility sessions to the same LMA (via the same MAG) from a single
>>> interface is needed. This is applicable in EPC and other networks
>>> which use PMIP6.
>>>
>>> -Raj
>>>
>>> _______________________________________________
>>> netext mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netext
>>
>
> _______________________________________________
> netext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext