Re: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6

[Hidetoshi Yokota <yokota at kddilabs.jp>]

Hi Ahmad,

Thanks for your revised text proposal below, which looks just fine.
We'll incorporate it into the next revision.

Regards,
-- 
Hidetoshi

Ahmad Muhanna wrote:
> Hi Hidetoshi,
> Please see inline.
> 
> Regards, 
> Ahmad
> 
>>>> -----Original Message-----
>>>>>> -----Original Message-----
>>>>>> From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp]
>>>>>>>> -----Original Message-----
>>>>>>>> From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp]
>>>>>>>> Sent: Thursday, September 17, 2009 4:48 PM
>>>>>>>> To: Muhanna, Ahmad (RICH1:2H10)
>>>>>>>> Cc: Mipshop; draft-ietf-mipshop-pfmipv6 at tools.ietf.org;
>>>> Jari Arkko
>>>>>>>> Subject: Re: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6
>>>>>>>>
>>>>>>>> Hi Ahmad,
>>>>>>>>
>>>>>>>> Here is the proposed revision:
>>>>>>>>
>>>>>>>> In Section 4.2:
>>>>>>>>       [... message with the same sequence number.] The 
>> necessary
>>>>>>>>    information MUST be transferred in the HI/HAck messages to
>>>>>>>>    distinguish MN's packets for forwarding in advance or
>>>>>> at this time.
>>>>>>>>    Such information includes the MN ID and/or GRE key(s).  
>>>>>> Typically,
>>>>>>>>    the NMAG selects the GRE key for the downlink packets
>>>>>> and the PMAG
>>>>>>>>    selects that for the uplink packets.  Each key is 
>> conveyed in 
>>>>>>>> either
>>>>>>>>    the HI or HAck message separately when GRE Key Option
>>>>>> [GREKEY] is
>>>>>>>>    used. [For the downlink ...]
>>>>>>>>
>>>>>>> [Ahmad]
>>>>>>> In addition to what Vijay mentioned with respect to
>>>>>> Typically (which
>>>>>>> should be removed), I believe the draft needs to be 
>> clear on the 
>>>>>>> mechanism that is used for exchanging the GRE keys. 
>> When you say 
>>>>>>> "...when the GRE Key Option [GREKEY] is used." What happens
>>>>>> if the GRE
>>>>>>> key option is NOT used. Is there another mechanism?
>>>>>> As an alternative way, Vendor-Specific Mobility Option
>>>> could be used. 
>>>>>> As you pointed out, the restriction introduced by GRE Key
>>>> Option is
>>>>>> that it can convey only one key in one message. If
>>>> multiple keys need
>>>>>> to be conveyed at one time for some reason, this
>>>> alternative solution
>>>>>> could be used. Should that also be in the document?
>>>>> [Ahmad]
>>>>> Honestly, I do not care. However, there MUST be a default 
>> mechanism 
>>>>> that MUST be clearly described in this draft and MUST be
>>>> supported for
>>>>> Interoperability. That choice being GRE Key option or VS
>>>> MO, it does
>>>>> not matter as long as the default mechanism is clearlu 
>> defined. Is 
>>>>> that a reasonable request?
>>>> I just want this document to cover as many use cases as 
>> possible. A 
>>>> default mechanism should be GRE Key Option.
>>>> Thinking it over and in the case of Vendor-specific 
>> Mobility Option, 
>>>> it would be necessary to define the whole message format 
>> internally, 
>>>> which may be beyond the scope of this document. Thus, it would be 
>>>> better to describe only the use of GRE Key Option in the document.
>>> [Ahmad]
>>> Good. Hope we get some text as clear as this objective.
>>>> Regarding the rest of your questions below, if GRE keys 
>> are not used 
>>>> between the LMA and MAG (on the PMIPv6 tunnel), the flow should be 
>>>> identifiable by the HNP, correct?
>>> [Ahmad]
>>> Sure. For the sake of this specific detail, that is fine.
>>>
>>>> In this
>>>> case, GRE keys are not mandatory on the inter-MAG tunnel. 
>> At the same 
>>>> time, this spec does not mention any other encapsulation mechanism.
>>> [Ahmad]
>>> Hmmm... I am not sure how to interpret this because, there is some 
>>> text under 4.1. which talks about all kind of tunneling that is 
>>> currently being supported between the MAG and the LMA, but for the 
>>> sake of this specific issue, let us continue.
>> Sorry that my explanation was not clear. I was talking about 
>> any new or undefined encapsulation mechanism. All the 
>> mechanisms described in
>> RFC5213 should be supported on the inter-MAG tunneling as well.
> [Ahmad]
> That is fine. 
> I believe the other thread touch on this topic in detail and we can
> follow up on this using that thread.
> 
>>>> Based on the above observations, the following paragraph 
>> is proposed:
>>>> -----
>>>> The necessary information MUST be transferred in the 
>> HI/HAck messages 
>>>> to distinguish MN's packets for forwarding in advance or at this 
>>>> time. Such information includes the HNP (or IPv4-MN-HoA) 
>> and/or GRE 
>>>> keys. Regarding the GRE key selection, the NMAG selects 
>> the GRE key 
>>>> for the downlink packets and the PMAG selects that for the uplink 
>>>> packets.
>>>> Each key is conveyed in either the HI or HAck message 
>> separately with 
>>>> GRE Key Option [GREKEY].
>>>> -----
>>>>
>>>> How about it?
>>> What about tweaking this a little for clarity:
>>>
>>> "
>>>    The necessary information MUST be transferred in the HI/HAck 
>>> messages to
>>>    distinguish MN's packets for forwarding in advance or at 
>> this time.
>>>    Such information includes the HNP (or IPv4-MN-HoA) 
>> and/or GRE key(s).
>>> In
>>>    the case of GRE tunneling with GRE keys being used, the NMAG 
>>> selects the GRE
>>>    key for the downlink packets and the PMAG selects the 
>> GRE key for 
>>> the uplink
>>>    packets. These GRE keys are exchanged using the GRE Key 
>> option as 
>>> described
>>>    in [GREKEY] where the DL GRE Key is communicated in the 
>> HI message 
>>> while
>>>    the UL GRE key is sent in the HAck message.
>>> " 
>> The very last part "where the DL GRE Key is communicated in 
>> the HI message while the UL GRE key is sent in the HAck 
>> message" has a bit of problem since the HI/HAck messages are 
>> allowed to be sent by either the PMAG or NMAG depending on 
>> the fast handover mode (i.e., depending on which side 
>> initiates the procedure). All the other part looks fine.
> 
> [Ahmad]
> That is a valid point. 
> I had the reactive mode in mind when I wrote the above paragraph, we can
> modify it as follows:
> 
> "
>    The necessary information MUST be transferred in the HI/HAck messages
> to
>    distinguish MN's packets for forwarding in advance or at this time.
>    Such information includes the HNP (or IPv4-MN-HoA) and/or GRE key(s).
> In
>    the case of GRE tunneling with GRE keys being used, for each mobility
>    session, the NMAG selects the GRE key for the downlink packets and
> the 
>    PMAG selects the GRE key for the uplink packets. These GRE keys are 
>    exchanged between the PMAG and the NMAG using the GRE Key option as 
>    described in [GREKEY], e.g., In the case of the reactive mode, the DL
> 
>    GRE key is communicated in the HI message while the UL GRE key is
> sent 
>    in the HAck message.
> " 
> 
>> Regards,
>> --
>> Hidetoshi
> 
> 
>