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

["Ahmad Muhanna" <amuhanna at nortel.com>]

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.

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

Thanks again.

Regards,
Ahmad

> 
> Regards,
> --
> Hidetoshi
>