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

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

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