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

[Hidetoshi Yokota <yokota at kddilabs.jp>]

Hi Ahmad,

Please see inline:

Ahmad Muhanna wrote:
> Hi Hidetoshi,
> Thanks; 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.

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

Regards,
-- 
Hidetoshi

> Thanks again.
> 
> Regards,
> Ahmad
> 
>> Regards,
>> --
>> Hidetoshi
>>
> 
> 
>