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

["Vijay Devarapalli" <vijay at wichorus.com>]

Can we remove the word "Typically"? It is always the nMAG that selects
the downlink GRE key and pMAG that selects the uplink GRE key. Right?

Vijay

> -----Original Message-----
> From: mipshop-bounces at ietf.org [mailto:mipshop-bounces at ietf.org] On
> Behalf Of Hidetoshi Yokota
> Sent: Thursday, September 17, 2009 2:48 PM
> To: Ahmad Muhanna
> Cc: Mipshop; draft-ietf-mipshop-pfmipv6 at tools.ietf.org
> 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 ...]
> 
> If the above description is acceptable, I will submit the revised
> version by the end of the week.
> 
> Regards,
> --
> Hidetoshi
> 
> Ahmad Muhanna wrote:
> > Hi Hidetoshi,
> >
> >> -----Original Message-----
> >> From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp]
> >> Sent: Monday, September 14, 2009 7:37 AM
> >> 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,
> >>
> >> Thanks for your comment. I'm glad to hear an opinion from a
> >> GRE key expert. Please see inline:
> >>
> >> Ahmad Muhanna wrote:
> >>> Hi Hidetoshi,
> >>>
> >>> I just have one quick comment and question.
> >>>
> >>> Reading the draft, it seems to me that the GRE keys are
> >> somehow sent
> >>> from the NAR to PAR in the HI (section 4.2). Is that the case?
This
> >>> means both the DL and UP GRE keys for the bilateral tunnels
between
> >>> the two AR(s). Is my understanding correct? It also
> >> mentions that the
> >>> format
> >> In terms of the GRE keys for the bilateral tunnel, the
> >> working assumption is that the DL key is selected by the NAR
> >> and the UL key is selected by the PAR. Depending on the fast
> >> handover mode, those keys are transferred to the other MAG
> >> via either the HI or Hack.
> >>
> >>> of these keys are based on the GRE keys for PMIPv6 draft (section
> >>> 6.2.6).
> >> Correct.
> >>
> >>> It seems to me that there should be more text to define which keys
> >>> exchange in the HI and which in the HaCK
> >> If the above assumption works, I would like to add more text
> >> along that line.
> > [Ahmad]
> > That is great. Please add some clarification text to clearly
indicate
> > that only one key in the HI and the other in the HACK.
> > Since some specification in 3GPP2 depends on this draft, I
appreciate
> if
> > you can publish an updated version before the end of the week.
Thanks
> in
> > advance!
> >
> >>> If both keys are exchanged in the same HI, How these keys are
> >>> identified at the pAR?
> >>> In GRE keys for PMIPv6 draft, downlink GRE key is included
> >> in the PBU
> >>> and the uplink GRE key in included in the PBA. They never
> >> exist in the
> >>> same message and that way there is no confusing.
> >> So far, each key is conveyed by either the HI or HAck.
> >> However, I haven't explored all of the possibilities. If you
> >> can think of any case that two keys must be conveyed in one
> >> message, please let me know.
> >
> > [Ahmad]
> > I do not see any reason for this case (one key per message) not to
> work
> > for all implementation.
> >
> >>> In addition, DL and UP GRE keys are generated by NAR and
> >> sent inside
> >>> the HI, my question: Is there any specific reason for the NAR to
> >>> specify both GRE keys for the bilateral tunnels?
> >> It would be more problematic that the NAR determines the both
> >> keys and I would rather like to avoid it.
> >>
> >>> Sorry for this comment to be so late but hope that you have
> >> the chance
> >>> to take a look at it.
> >> That's ok. The draft is under the review process. Your
> >> comment is highly appreciated.
> >>
> >> Regards,
> >> --
> >> Hidetoshi
> >>
> >>
> >>> Thanks!
> >>>
> >>> Regards,
> >>> Ahmad
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: mipshop-bounces at ietf.org
> >>>> [mailto:mipshop-bounces at ietf.org] On Behalf Of Hidetoshi Yokota
> >>>> Sent: Wednesday, September 02, 2009 11:12 PM
> >>>> To: Jari Arkko
> >>>> Cc: Mipshop; draft-ietf-mipshop-pfmipv6 at tools.ietf.org
> >>>> Subject: Re: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6
> >>>>
> >>>> Hi Jari,
> >>>>
> >>>> Thanks for your patience. The attached revised document is
> >> supposed to
> >>>> reflect the rest of your comments. Please also see inline,
> >> where the
> >>>> revised part is explained item by item. If there is no
> >>>> outstanding issue
> >>>> there, we will upload it shortly.
> >>>>
> >>>> [Apologize if you received it twice. Since the size just
> >> exceeded the
> >>>> limit of this ML, this mail is reposted without the attachment.]
> >>>>
> >>>> Hidetoshi Yokota wrote:
> >>>>> Hi Jari,
> >>>>>
> >>>>> Appreciate your detailed review. The editorial corrections
> >>>> are mostly
> >>>>> done and the revised version is attached to this mail.
> >> Regarding the
> >>>>> technical comments, only the policies for the correction
> >>>> are listed for
> >>>>> now. The complete correction will be posted as soon as
> >>>> possible. Please
> >>>>> see inline for the responses to your questions and comments:
> >>>>>
> >>>>> Jari Arkko wrote:
> >>>>>> I have reviewed this document. It was generally in good
> >>>> shape and easy
> >>>>>> to read. I did find a number of issues though. Please
> >>>> discuss them with
> >>>>>> me on this thread and/or revise the draft accordingly.
> >>>>>>
> >>>>>> Technical:
> >>>>>>
> >>>>>> I do not understand the IP host aspects of the handover. For an
> >>>>>> unmodified host, what kind of interfaces exist on the host,
what
> >>>>>> addresses they have, and at what time are interfaces
> >>>> removed or added?
> >>>>>> Is this exactly the same as in RFC 5213, or does PFMIPv6
> >>>> introduce some
> >>>>>> change here?
> >>>>> The basic principle would be that this specification does
> >>>> not require
> >>>>> any additional IP-level function to the MN running in the
> >>>> PMIPv6 domain.
> >>>>> This MN should therefore be the same as defined in RFC5213.
> >>>>>
> >>>>> A typical network interface would be one with the
> >> cellular network,
> >>>>> where the network basically controls the movement of the
> >>>> MN. Different
> >>>>> types of interfaces could be involved such as different
> >>>> generations (3G
> >>>>> and 3.9G) or different radio access systems. Any type of
> >> IP address
> >>>>> could be assigned (IPv4/v6 or global/private), but the
> >>>> assigned address
> >>>>> must be preserved before and after the handover. PFMIPv6
> >>>> should be able
> >>>>> to handle the single radio situation, where only one
> >>>> interface is active
> >>>>> at any given time. This is a tougher situation in terms of
> >>>> packet loss
> >>>>> and delay.
> >>>>>
> >>>>>> I would like to see a new section on manageability
> >>>> considerations. For
> >>>>>> instance, Section 5 talks about some configuration issues.
> >>>> These should
> >>>>>> be mentioned, and there should be a description of what
> >>>> the operator
> >>>>>> needs to configure in order to set up a PFMIPv6 network.
> >>>>> We will add a new section for manageability considerations
> >>>> to clarify
> >>>>> the above and to reflect your suggestion.
> >>>> A new subsection is added in Section 5 describing the
> >> above aspects:
> >>>> -------------------
> >>>> 5.  PMIPv6-related Fast Handover Issues
> >>>>
> >>>> 5.1.  Manageability Considerations
> >>>>
> >>>>    This specification does not require any additional IP-level
> >>>>    functionality on the LMA and the MN running in the PMIPv6
> >>>> domain.  A
> >>>>    typical network interface that the MN could be assumed to
> >>>> have is one
> >>>>    with the cellular network, where the network controls the
> >>>> movement of
> >>>>    the MN.  Different types of interfaces could be involved such
> as
> >>>>    different generations (3G and 3.9G) or different radio access
> >>>>    systems.  This specification supports a MN with the single
> radio
> >>>>    mode, where only one interface is active at any given time.
> The
> >>>>    assigned IP address is preserved whether the physical
interface
> >>>>    changes or not and the MN can identify which interface
> >>>> should be used
> >>>>    if there are multiple ones.
> >>>> --------------------
> >>>>
> >>>>
> >>>>>>> If the new router's interface is configured to
> >>>>>>> respond to queries sent to link-layer addresses than its
> >>>> own (e.g.,
> >>>>>>> set to promiscuous mode), then it can respond to the NUD
probe,
> >>>>>>> providing its link-layer address in the solicited Neighbor
> >>>>>>> Advertisement.
> >>>>>> Is this according to RFC 5213? I seem to recall that RFC
> >>>> 5213 operated
> >>>>>> on the same link layer addresses.
> >>>>> I think your observation is correct... I'll check with the
> >>>> other authors
> >>>>> to see if it is ok to rewrite it.
> >>>> The new text doesn't mention the promiscuous mode and
> >> emphasizes the
> >>>> common link-layer address among all MAGs in the PMIPv6 domain:
> >>>>
> >>>> ---------------
> >>>> 5.2.  Expedited Packet Transmission
> >>>>
> >>>>    [...]
> >>>>
> >>>>    The protocol specified in this document is applicable
> >> regardless of
> >>>>    whether link-layer addresses are used between a MN and
> >> its access
> >>>>    router.  A MN should be able to continue sending packets on
the
> >>>>    uplink even when it changes link.  When link-layer addresses
> are
> >>>>    used, the MN performs Neighbor Unreachability Detection (NUD)
> >>>>    [RFC4861], after attaching to a new link, probing the
> >>>> reachability of
> >>>>    its default router.  The new router should respond to the
> >>>> NUD probe,
> >>>>    providing its link-layer address in the solicited Neighbor
> >>>>    Advertisement, which is common in the PMIPv6 domain.
> >>>> Implementations
> >>>>    should allow the MN to continue to send uplink packets
> >> while it is
> >>>>    performing NUD.
> >>>> ----------------
> >>>>
> >>>>>>> At least one mobility option MUST
> >>>>>>> uniquely identify the target MN (e.g., the Mobile Node
> >> Identifier
> >>>>>>> Option defined in RFC4283
> >>>> <http://tools.ietf.org/html/rfc4283>) and
> >>>>>>> the transferred context MUST be for
> >>>>>>> one MN per message.
> >>>>>>>
> >>>>>> I would like the required options to be specified in more
> >>>> detail. Which
> >>>>>> identity options are sufficient to satisfy the MUST?
> >>>>> The required option should be the MN Identifier in the Mobile
> Node
> >>>>> Identifier Option.
> >>>> The above description is added in Section 6.1.1:
> >>>>
> >>>> ---------
> >>>>    Requested option
> >>>>              In order to uniquely identify the target MN, the MN
> >>>>              Identifier MUST be contained in the Mobile Node
> >>>> Identifier
> >>>>              Option.
> >>>> ---------
> >>>>
> >>>>>>> If a default set of context information is defined and
> >>>>>>> always sufficient, this option is not mandatory.  This
> >>>> option is more
> >>>>>>> useful to retrieve additional or dynamically selected context
> >>>>>>> information.
> >>>>>>>
> >>>>>>> Context Request Option is typically used for the reactive
(NAR-
> >>>>>>> initiated) fast handover mode to retrieve the context
> >> information
> >>>>>>> from the PAR.  When this option is included in the HI
> >> message, all
> >>>>>>> the requested context information SHOULD be included in the
> HAck
> >>>>>>> message in the corresponding mobility option(s) (e.g.,
> >>>> HNP, LMAA or
> >>>>>>> MN-IID mobility options).
> >>>>>>>
> >>>>>> Please specify what the default set of context
> >> information is, by
> >>>>>> listing the required options when the CRO is not present.
> >>>>> The default context information to request is the Home
> >>>> Network Prefix
> >>>>> Option. If the Mobile Node link-layer is available and
> >>>> used, the Mobile
> >>>>> Node Link-layer Identifier Option MUST also be requested.
> >>>> With these two
> >>>>> options and the MN identifier, the NMAG can construct the PBU.
> >>>> The above description is added in Section 6.2.1:
> >>>>
> >>>> ----------
> >>>>    The default context information to request is the Home
> >>>> Network Prefix
> >>>>    Option.  If the Mobile Node link-layer is available and
> >> used, the
> >>>>    Mobile Node Link-layer Identifier Option MUST also be
> requested.
> >>>> ----------
> >>>>
> >>>>>> Editorial:
> >>>>>>
> >>>>>>>    HO-Initiate:
> >>>>>>>         A generic signaling message, sent from the P-AN
> >>>> to the PMAG that
> >>>>>>>         indicates a MN handover.  While this signaling is
> >>>> dependent on
> >>>>>>>         the access technology, it is assumed that
> >>>> HO-Initiate can carry
> >>>>>>>         the information to identify the MN and to
> >> assist the PMAG
> >>>>>>>         resolve the NMAG and the new access point or the
> >>>> base station to
> >>>>>>>         which the MN is moving to.  The details of this
> >>>> message are
> >>>>>>>         outside the scope of this document.
> >>>>>>>
> >>>>>>> 4. Proxy-based FMIPv6 Protocol Overview
> >>>>>> Section 4 would probably benefit from an additional
> >>>> paragraph at the
> >>>>>> beginning to explain what assumptions there exist about
> >>>> lower layer
> >>>>>> functionality.
> >>>>> Yes, the predictive fast handover relies on the lower layer
> >>>>> functionality to trigger to send the HI. A new paragraph
> >>>> will be added
> >>>>> to clarify it.
> >>>> -------------
> >>>> 4.  Proxy-based FMIPv6 Protocol Overview
> >>>>
> >>>>    If the MAGs can be informed of the detachment and/or
> >> attachment of
> >>>>    the MN in a timely manner via e.g. the lower layer
> >>>> signaling, it will
> >>>>    become possible to optimize the handover procedure,
> >> which involves
> >>>>    establishing a connection on the new link and signaling
between
> >>>>    mobility agents, compared to the baseline specification
> >> of PMIPv6.
> >>>>   [...]
> >>>> -------------
> >>>>
> >>>> All the other corrections pointed out below have also been
> >>>> reflected in
> >>>> the revised document.
> >>>>
> >>>> Regards,
> >>>> --
> >>>> Hidetoshi
> >>>>
> >>>>>>> A new flag 'P' is defined for the HI and
> >>>>>>> HAck messages to distinguish from those in [RFC5268bis
> >>>>>>>
> >>>> <http://tools.ietf.org/html/draft-ietf-mipshop-pfmipv6-08#ref-
> >>>> RFC5268bis>]
> >>>>>>> and thus MUST
> >>>>>>> be set in the entire document.
> >>>>>>>
> >>>>>> This would be more readable as " ... those in
> >>>> [RFC5268bis]. This flag
> >>>>>> MUST be ..."
> >>>>> Revised.
> >>>>>
> >>>>>>>    and the NAR creates a proxy NCE to receive those
> >>>> packets for the NCoA
> >>>>>> The term NCE has not been introduced at this stage yet.
> >>>>> Spelled out as "Neighbor Cache Entry".
> >>>>>
> >>>>>>>    address that is used by the MN is MN-HoA.  Hence the
> >>>> PAR forwards
> >>>>>> The term MN-HOA has not been introduced before.
> >>>>> Added the unabbreviated form "Mobile Node's Home Address"
> >> before it.
> >>>>>>>         The access network to which the MN is attached
> >>>> after handover.
> >>>>>> New term MN, not introduced before.
> >>>>>>
> >>>>> Added "Mobile Node" before it.
> >>>>>
> >>>>>>> specifies forwarding when the MN uses HoA as its on-link
> address
> >>>>>> New term HoA...
> >>>>> Changed to "Home Address".
> >>>>>
> >>>>>>>    as MN's NAI, Home Network Prefix (HNP), IPv4 Home
> >> Address, are
> >>>>>> New term NAI...
> >>>>> Added "Network Access Identifier" before it.
> >>>>>
> >>>>>>>         flag set and include the MN ID, the MN-HNP, the
> >>>> MN-IID and the
> >>>>>> New terms MN-HNP and MN-IID (or at least they do not
> >>>> appear in their
> >>>>>> MN-XXX form before this point).
> >>>>> Modified "MN-HNP" to "HNP" for consistency.
> >>>>>
> >>>>>>>         Inner destination address: HNP or IPv4-MN-HoA
> >>>>>> IPv4-MN-HoA not defined earlier...
> >>>>> Added "Mobile Node's IPv4 Home" before it.
> >>>>>
> >>>>>>>    between the PCoA and NCoA to forward packets for the
> >>>> MN to the NAR,
> >>>>>> New terms PCoA and NCoA... there's probably more undefined
> >>>> terms in the
> >>>>>> document, please check!
> >>>>> Added "Previous Care-of Address" and "New Care-of Address".
> >>>> Will read
> >>>>> through it to see if there is any other undefined acronym.
> >>>>>
> >>>>>>>    In (i),
> >>>>>> In Step (i),
> >>>>> Revised including other parts.
> >>>>>
> >>>>>>>           |(MN ID, Old AP ID) |     (MN ID, Old AP ID)
> >>>>  |        |
> >>>>>> Old AP ID? AN ID? AR ID?
> >>>>> AP ID stands for "Access Point Identifier", which is
> >>>> defined in RFC5568.
> >>>>> Added the unabbreviated form and citation.
> >>>>>
> >>>>> The rest of the part will be revised soon.
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>>
> >>>>>
> >>>> --------------------------------------------------------------
> >>>> ----------
> >>>>> _______________________________________________
> >>>>> Mipshop mailing list
> >>>>> Mipshop at ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/mipshop
> >>>> _______________________________________________
> >>>> Mipshop mailing list
> >>>> Mipshop at ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/mipshop
> >>>>
> >>>
> >>>
> >>
> >
> >
> >
> 
> --
> Hidetoshi Yokota
> 
> Mobile Network Lab
> KDDI R&D Laboratories, Inc.
> e-mail:yokota at kddilabs.jp
> 
> _______________________________________________
> Mipshop mailing list
> Mipshop at ietf.org
> https://www.ietf.org/mailman/listinfo/mipshop