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

[Frank Xia <[e-mail]>]

Hi Ahmad

I thought Hidetoshi had a good summary of
you comments.  Could you give me a brief
information of your concerns? because I have
similar understanding as Hidetoshi.

BR
Frank

----- Original Message ----- 
From: "Ahmad Muhanna" <[e-mail]>
To: "Frank Xia" <[e-mail]>; "Hidetoshi Yokota" 
<[e-mail]>
Cc: "Mipshop" <[e-mail]>; 
<[e-mail]>
Sent: Thursday, September 24, 2009 9:31 AM
Subject: RE: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6


Hi Frank,
Please see my latest response to Hidetoshi.

Regards,
Ahmad


> -----Original Message-----
> From: Frank Xia [mailto:[e-mail]]
> Sent: Thursday, September 24, 2009 7:18 AM
> To: Hidetoshi Yokota; Koodli, Rajeev; Muhanna, Ahmad (RICH1:2H10)
> Cc: Mipshop; [e-mail]
> Subject: Re: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6
>
> Hi  Ahmad, Hidetoshi, and Rajeev
>
> I have followed the discussion, and agreed with Rajeev's proposal.
>
> BR
> Frank
>
> ----- Original Message -----
> From: "Hidetoshi Yokota" <[e-mail]>
> To: "Koodli, Rajeev" <[e-mail]>
> Cc: "Mipshop" <[e-mail]>;
> <[e-mail]>
> Sent: Thursday, September 24, 2009 3:28 AM
> Subject: Re: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6
>
>
> > Hi Rajeev and Ahmad,
> >
> > Thanks Rajeev for your input. It seems that all of the
> questions and
> > ambiguity pointed out by Ahmad lead to one issue: PMIPv6 defines
> > multiple encapsulation methods; therefore the inter-MAG tunnel must
> > specify which method should be used. If Rajeev's input is
> acceptable.
> > I'll come up with some text along that line.
> >
> > Regards,
> > --
> > Hidetoshi
> >
> > Koodli, Rajeev wrote:
> >>
> >> Hi Ahmad,
> >>
> >> Let me see if I could understand your concern.
> >>
> >> RFC 5568 assumes that tunneling is IPv6-in-IPv6 based on RFC 3775.
> >> So, it does not need to specify how/which encapsulation
> mode is used.
> >>
> >> PFMIP6, on the other hand, is for PMIP6 which does support
> multiple
> >> encapsulation modes. Hence, PFMIP6 needs to specify how/which
> >> encapsulation mode is used. Is this right?
> >>
> >> If so, here is my input. PFMIP6 must state what
> encapsulation modes
> >> MUST be supported. The encapsulation modes should be configurable.
> >> Which particular mode is used is dependent on the particular
> >> deployment. There must be text stating that deployments MUST
> >> configure the encapsulation modes on MAGs to be the same,
> and it is
> >> recommended to use the same encapsulation modes as in MAG-LMA
> >> communication whenever feasible for operational uniformity. If the
> >> deployments fail to configure the encapsulation modes to
> be the same
> >> across all MAGs, then the protocol will not work correctly.
> >>
> >> How does this sound?
> >>
> >> Regards,
> >>
> >> -Rajeev
> >>
> >>
> >>> -----Original Message-----
> >>> From: Ahmad Muhanna [mailto:[e-mail]]
> >>> Sent: Tuesday, September 22, 2009 10:58 PM
> >>> To: Hidetoshi Yokota
> >>> Cc: Mipshop; [e-mail]
> >>> Subject: RE: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6
> >>>
> >>> Hi Hidetoshi,
> >>>
> >>> Thanks for your thoughts on this.
> >>> I expected a little more serious ones:), but please see
> some more of
> >>> the same thoughts inline! :)
> >>>
> >>> Regards,
> >>> Ahmad
> >>>> -----Original Message-----
> >>>> From: Hidetoshi Yokota [mailto:[e-mail]]
> >>>> Sent: Tuesday, September 22, 2009 6:20 AM
> >>>> To: Muhanna, Ahmad (RICH1:2H10)
> >>>> Cc: Mipshop; [e-mail]
> >>>> Subject: Re: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6
> >>>>
> >>>> Hi Ahmad,
> >>>>
> >>>> Thanks for your detailed thoughts. Below, we try to answer your
> >>>> questions as best we can.
> >>>>
> >>>> Ahmad Muhanna wrote:
> >>>>> Hi Hidetoshi,
> >>>>>
> >>>>> Looking one more time into the draft I found the
> following under
> >>>>> section
> >>>>> 4.1:
> >>>>>
> >>>>> "
> >>>>>    The encapsulation type for these user packets SHOULD
> >>>> follow that used
> >>>>>    in the tunnel between the LMA and MAG (IPv6-in-IPv6 as
> >>>> specified in
> >>>>>    [RFC2473], IPv6-in-IPv4, IPv6-in-IPv4-UDP as specified in
> >>>>>    [IPv4PMIPv6], TLV-header UDP tunneling as specified in
> >>>> [GREKEY] or
> >>>>>    any new method defined in the future).
> >>>>> "
> >>>> The intention here is that the inter-MAG tunnel should
> >>> support all the
> >>>> encapsulation types that are mentioned in RFC5213.
> >>> [Ahmad]
> >>> Well, whatever it is this document supports, it needs to make it
> >>> clear and ensure that it works. My question is the
> >>> following: Does this document support ONLY IPv6-in-IPv6 tunneling
> >>> between the MAG and the LMA? or it also supports the different
> >>> tunneling that the document claims to support as quoted above?
> >>>
> >>> If it only supports IPv6-in-IPv6, this document MUST
> document that
> >>> clearly. On the other hand, if it supports the above listed
> >>> tunneling protocols, it MUST document how forwarding
> these packets
> >>> over the inter-MAG tunnel works.
> >>>
> >>>>> IMO, this is a very broad statement that underestimates its
> >>>> content.
> >>>>> It is way underspecified how these tunneling protocols will
> >>>> be used to
> >>>>> successfully map the traffic from the MAG-LMA tunnel to
> >>> the MAG-MAG
> >>>>> tunnel. In this regard, I have the following questions:
> >>>>>
> >>>>> 1. Is it documented any where how this mapping would work
> >>>> for all of
> >>>>> these tunneling/encapsulation mechanisms?
> >>>> It seems that the mapping of these flows is rather
> implementation
> >>>> specific. Is there anything that should be considered in
> >>> addition to
> >>>> RFC5568?
> >>> [Ahmad]
> >>> Of course. I guess you need to get out of the mode that this
> >>> document is nothing but few tweaks to make FMIP6 works
> for PMIPv6.
> >>> In RFC5568, it clearly assumes that protocol is used for fast
> >>> handover when IP Mobility based on MIP6 as described in
> RFC3775. In
> >>> that sense, only IPv6-in-IPv6 is assumed.
> >>>
> >>> Again, the above claim of supporting all these tunneling
> mechanisms
> >>> should either be removed and clearly document that this protocol
> >>> works ONLY when the tunneling between the MAG and LMA is
> >>> IPv6-in-IPv6 or explain how they will work.....
> >>>
> >>>>> 2. Is the tunneling mode (between the PMAG and the LMA)
> >>>>> negotiated/communicated between the PMAG-MAGs?
> >>>> If the tunneling mode is determined between the LMA and
> >>> PMAG, which is
> >>>> in the scope of RFC5213, that of the inter-MAG tunnel
> should follow
> >>>> it.
> >>>> It is also assumed that the same type of tunneling will be used
> >>>> between the LMA and NMAG.
> >>> [Ahmad]
> >>> Sure, but your document claim that it supports all of these
> >>> tunneling mechanisms (as per the quoted text from section
> >>> 4.1) and at the same time documents nothing about how
> these should
> >>> work across the inter-MAG tunnel.
> >>>
> >>>>> 3. If the tunneling between the PMAG-LMA is
> >>>> IPv6-in-IPv4-UDP, Does it
> >>>>> mean the tunneling between the PMAG-NMAG is also going to
> >>>> use the same
> >>>>> encapsulation?
> >>>> Yes, that is the basic idea.
> >>> [Ahmad]
> >>> Good. Then How that should work?
> >>> Is there anything in your document which specify that? I am all
> >>> ears, just point me to the text.
> >>>
> >>>>> 4. If the UDP tunneling between the two MAGs is not needed,
> >>>> what kind
> >>>>> of tunneling will be used between the two MAGs to correctly
> >>>> map the MN
> >>>>> traffic and successfully deliver it to the MN?
> >>>> That mode has not been considered. It will be possible, but
> >>> is there
> >>>> any reason that a different type of tunneling should be used?
> >>> [Ahmad]
> >>> I am not suggesting to use a different tunneling
> mechanism between
> >>> the PMAG and the NMAG; However, You are saying that, e.g.,
> >>> IPv6-in-IPv4-UDP is naturally extended over the PMAG-NMAG tunnel
> >>> without saying how it should work. That what I was
> speculating that
> >>> you probably use a specific tunneling, of course, other than
> >>> IPv6-in-IPv6 to make it work.
> >>>
> >>> So, again, if PMAG-NMAG interface does support all these
> tunneling
> >>> mechanisms, then we need to know how it works? That is all.
> >>>
> >>>>> 5. Do these tunneling mechanisms include plain GRE
> >>>> Encapsulation with
> >>>>> GRE keys or only GRE with TLV-header UDP tunneling?
> >>>> <draft-ietf-netlmm-grekey-option> supports both modes, so
> >>>> PFMIPv6 should also support them.
> >>> [Ahmad]
> >>> That is a clear answer. Thanks.
> >>> Could you please make sure that your document clarify and clearly
> >>> document it.
> >>>
> >>>>> 5.1. If plain GRE encapsulation with keys is used, then the
> >>>> document
> >>>>> needs to clearly specify if there are two sets of GRE
> >>> keys for the
> >>>>> same mobility session or only one set? i.e., GRE Keys
> between the
> >>>>> PMAG-LMA, GRE Keys for PMAG-NMAG or one set is used. It is
> >>>> not clear
> >>>>> in the current document.
> >>>> PFMIPv6 describes only GRE keys for the inter-MAG tunnel
> >>> (PMAG-NMAG),
> >>>> which I think is clarified in Section 4.2. As far as GRE
> >>> Key Option is
> >>>> used, it is difficult to transport multiple sets of keys at
> >>> one time.
> >>> [Ahmad]
> >>> Well,
> >>> 1. It is not clarified nor clear under section 4.2. but,
> could you
> >>> please point me to the text you are talking about?
> >>> 2. As far as of multiple GRE keys exchange, currently that is a
> >>> limitation of the PMIPv6 protocol. Right? Then, when you need
> >>> multiple GRE keys, how these GRE keys are communicated?
> >>> Is that explained in the document?
> >>>
> >>>>> 5.2. same question as in 4, if there is GRE with TLV-header UDP
> >>>>> tunneling between the PMAG and the LMA, Is that needed
> >>> between the
> >>>>> PMAG-NMAG? If NOT, what encapsulation mechanism is being
> >>>> used and how
> >>>>> is the mapping works?
> >>>> The working assumption is "yes".
> >>> [Ahmad]
> >>> That is a huge CLAIM that is NOT backed by any technical
> data! How
> >>> that should work? Can you document that some where in the
> >>> specification? If it is already document, please point me to the
> >>> text.
> >>>
> >>>>> 6. Is the assumption here that the NMAG and the PMAG have
> >>> the same
> >>>>> transport with the LMA?
> >>>> For the sake of simplicity, the answer should be "yes".
> >>>> If not, the network between MAGs should provide the transparent
> >>>> environment (e.g., by another tunneling).
> >>>>
> >>>>> 7. with respect to "any new method defined in the future"
> >>>> what is the
> >>>>> constraints on this statement? It seems to me an
> >>>> overstatement of the
> >>>>> capabilities of this protocol and an underestimate of
> the future
> >>>>> tunneling mechanism. May be you need to make sure that the
> >>>> wording is
> >>>>> correct by having some conditional restrictions.
> >>>> The intention here is that if a new tunneling mechanism is
> >>> specified
> >>>> for  PMIPv6, PFMIPv6 should also support it. If this is too
> >>> vague, it
> >>>> could be removed.
> >>> [Ahmad]
> >>> Sure, please remove it. Unless, you propose a dynamic tunneling
> >>> mechanism that is forward compatible and capable to
> address future
> >>> tunneling between the PMAG and LMA.
> >>>
> >>>>> In addition,
> >>>>> ============
> >>>>> IMO and based on a quick review of this draft, I find it
> >>> very vague
> >>>>> and does not have the details for an Interoperable
> >>>> protocol. I believe
> >>>>> the draft SHOULD CLEARLY address the following points:
> >>>>>
> >>>>> Decide whether it needs to specify/support a single tunneling
> >>>>> encapsulation mechanism between the PMAG-NMAG or more than one.
> >>>>>
> >>>>>
> >>>>> SINGLE tunneling and encapsulation mechanism between PMAG-NMAG:
> >>>>> ===============================================================
> >>>>> 1. This *protocol* needs to specify the exact details
> of how this
> >>>>> tunneling mechanism is dynamically established to address
> >>>> the nature
> >>>>> of the problem being address in this *handover optimization
> >>>> protocol*.
> >>>>
> >>>> The nature of the specification and its performance is based on
> >>>> RFC5568.
> >>> [Ahmad]
> >>> That is part of the problem not to be sited here as a supporting
> >>> argument!
> >>> As I said earlier, RFC5568 assumes that there is always
> >>> IPv6-in-IPv6 tunneling between the mobile node and the
> home agent.
> >>> In the case of
> >>> PMIPv6 that assumption is INVALID.
> >>>
> >>>> Whether the establishment of the tunneling mechanism is
> dynamic or
> >>>> static is operation-specific.
> >>> [Ahmad]
> >>> That is NOT true. This document is supposedly offering a fast
> >>> handover mechanism for PMIPv6 which dynamically does
> (implicitly or
> >>> explicitly) negotiates tunneling between the MAG and the LMA. So,
> >>> how a statically configured tunnel between the PMAG and the NMAG
> >>> tunnels a mobile node traffics when the mobile node
> traffic between
> >>> the PMAG and LMA for the same mobile node was dynamically
> >>> negotiated?
> >>>
> >>>
> >>>>> 1.1. for example, if GRE with Keys is being used, then
> it MUST be
> >>>>> clear how the GRE keys are exchanged between the PMAG-NMGA,
> >>>> similar to PMIPv6.
> >>>>
> >>>> The current text proposal for Section 4.2 tries to clarify it
> >>>> regarding who selects the key and how it is transferred.
> >>> [Ahmad]
> >>> Hmmm.. Tries to clarify ... I guess we need a clear specification
> >>> that documents an Interoperable solution. We can not just
> propose a
> >>> standard track document that is some what clear in the
> mind of some.
> >>> Right?
> >>>
> >>>>> 2. How the chosen PMAG-NMAG tunneling protocol is able to
> >>> interwork
> >>>>> with all tunneling mechanisms that are currently supported
> >>>> by PMIPv6,
> >>>>> e.g., IPv6-in-IPv6, IPv6-in-IPv4, IPv6-in-IPv4 UDP, etc.
> >>>> between the
> >>>>> PMAG-LMA as is being claimed under section 4.2 of this draft.
> >>>> Basically, it is supposed that the same tunneling
> protocol as that
> >>>> between the LMA and MAG is used. The tunneling type
> between the LMA
> >>>> and MAG should be determined in advance.
> >>> [Ahmad]
> >>> I guess this answer is more confusing .... One time you said that
> >>> the tunnel can be static and can be dynamic. Now, you
> just said that
> >>> the tunnel should be STATIC? I mean what is it? It needs
> >>> clarification......
> >>>
> >>>
> >>>>> 3. This *protocol* needs to clearly specify how the
> >>>> different mobility
> >>>>> sessions are being mapped between the PMAG-LMA tunneling to the
> >>>>> PMAG-NMAG tunneling? Somewhat similar to 2 above.
> >>>> The basic mechanism is the same as in RFC5568.
> >>> [Ahmad]
> >>> Again, in the case of RFC5568 it is straight forward. Only
> >>> IPv6-in-IPv6 is supported as per RFC3775. Not the case for PMIPv6.
> >>>
> >>>> If a GRE
> >>>> tunnel further differentiates the session, the GRE key
> will be used.
> >>> [Ahmad]
> >>> Good. Which GRE Key then?
> >>> 1. Is that a statically configured GRE key?
> >>> 2. Is it the same set of GRE keys between the PMAG and LMA?
> >>> 3. If none of the above, how these GRE keys are generated and
> >>> exchanged between the PMAG and the NMAG?
> >>>
> >>>>> Multiple Tunneling and encapsulation mechanisms between the
> >>>> PMAG-NMAG:
> >>>
> ====================================================================
> >>> ==
> >>>>> If the choice as being claimed under section 4.1, is to
> >>>> support all of
> >>>>> the current tunneling mechanisms between PMAG-LMA on the
> >>> PMAG-NMAG
> >>>>> interface, then the protocol needs to address the following:
> >>>>>
> >>>>> 1. Provide a good analysis why that option is the best
> >>> option? What
> >>>>> are the advantages and the disadvantages?
> >>>> I think that is the most workable solution.
> >>> {Ahmad]
> >>> What do you have to technically back up this statement.
> >>> Otherwise, it is just another statement.
> >>>
> >>>> Since the
> >>>> tunneling mechanism selected for the PMIPv6 tunnel is
> supported by
> >>>> both the PMAG and NMAG, no extra capability is required for the
> >>>> inter-MAG tunnel.
> >>> [Ahmad]
> >>> OK. I am not disputing that the PMAG and the NMAG
> supports the same
> >>> sets of tunneling mechanisms or not. It is more of which
> tunnel to
> >>> use for which mobile node session and what parameter is
> needed for
> >>> this inter-MAG tunnel to correctly tunnel the mobile node traffic
> >>> and deliver it to the end of the tunnel in a non ambiguous way.
> >>>
> >>> For example:
> >>> Tunneling Case 1:
> >>> =================
> >>> 1. PMAG and the LMA negotiates the GRE encapsulation and the GRE
> >>> keys using the PBU and PBA for each applicable mobility session.
> >>> 2. It is very well understood that both the PMAG and the NMAG
> >>> support GRE tunneling with GRE keys + GRE keys exchange using
> >>> PMIPv6 signaling with the LMA.
> >>> 3. Now: for the inter-MAG tunnel and for the same
> mobility session,
> >>> how GRE tunneling and GRE keys are negotiated between the
> PMAG and
> >>> NMAG? Of course, using HI and HAck, right?
> >>> 4. Okay, we need the exact details for this specific case.
> >>>
> >>> Tunneling Case 2:
> >>> =================
> >>> 1. Let us assume IPv6-in-IPv4 UDP is used for MN1. Okay 2.
> >>> That tunneling is implicitly negotiated between the PMAG and LMA
> >>> during the PBU/PBA exchange, right?
> >>> 3. How that is negotiated between the PMAG and the NMAG?
> We need the
> >>> details..
> >>>
> >>> And so on....
> >>>
> >>>> Also, I don't see any specific reason to use a special tunneling
> >>>> mechanism for the inter-MAG tunnel.
> >>> [Ahmad]
> >>> Good. This means you would use the same tunneling between
> the PMAG
> >>> and LMA over inter-MAG tunneling. In this case, we need
> the details
> >>> for negotiating that tunneling mechanism between the PMAG and the
> >>> NMAG.
> >>>
> >>>>> 2. How this *protocol* dynamically negotiates the tunneling
> >>>> mechanism
> >>>>> type?
> >>>> If the tunneling mechanism between the LMA and MAG is
> determined in
> >>>> advance, the same mechanism is used for the inter-MAG
> >>> tunnel. So, it
> >>>> is not on-demand and no negotiation is assumed. If the tunneling
> >>>> mechanism between the LMA and MAG is determined on demand,
> >>> then that
> >>>> is a different story...
> >>> [Ahmad]
> >>> Well, what do you mean? The tunneling between the PMAG
> and the LMA
> >>> is NOT on demand?
> >>> I believe IPv4 support for PMIPv6 and GRE key for PMIPv6
> drafts will
> >>> be helpful in answering this question.
> >>>
> >>>>> 3. How that should work, for example if the tunneling mechanism
> >>>>> between the PMAG-LMA is IPv6 in IPv4 UDP, how that
> >>>> tunneling will be
> >>>>> extended to go over the PMAG-NMAG interface and how it is
> >>>> supposed to work.
> >>>>
> >>>> In this case, both the PMAG and NMAG should be dual-stack
> >>> and the IP
> >>>> addresses in the IPv4 outer header are those of the PMAG
> and NMAG.
> >>>> IPv6 inner header should be kept intact.
> >>>>
> >>> Okay..... Then if the NMAG sends the first packet over
> the NMAG-PMAG
> >>> tunnel! Which encapsulation mechanism is going to use to
> encapsulate
> >>> that packet?
> >>>
> >>> Also, Do you agree that there is a specific reason for
> the traffic
> >>> between the PMAG and the LMA to be IPv6-in-IPv4-UDP.
> >>> Right? That reason may NOT be VALID between the PMAG and
> the NMAG.
> >>> Right?
> >>> Then why to use the same tunneling here? Just out of curiosity!
> >>>
> >>>>> Finally, the draft could have some restrictions and define the
> >>>>> PMAG-NMAG tunneling/encapsulation mechanism and could
> >>>> define a set of
> >>>>> PMAG-LMA tunneling mechanism that are being
> >>>> supported/interwork over
> >>>>> the PMAG-NMAG tunneling/encapsulation.
> >>>> What kind of restrictions do you foresee? Do you also have any
> >>>> specific mechanism for the inter-MAG tunnel in mind?
> >>> [Ahmad]
> >>> I guess, you need to answer many of the above comments before we
> >>> talk about this. A clear understanding of this tunneling
> is needed
> >>> and I do not see it documented in this draft.
> >>>
> >>> BTW: Under section 4, this specification says:
> >>>
> >>> "
> >>>    In order to further improve the performance during the
> handover,
> >>> the
> >>>    PFMIPv6 protocol in this document specifies a
> bi-directional tunnel
> >>>    between the Previous MAG (PMAG) and the New MAG (NMAG)
> to tunnel
> >>>    packets meant for the mobile node.
> >>> "
> >>>
> >>> Which bi-directional tunnel? Where? What are the details?
> >>>
> >>>>> One more note: I found defining and describing a protocol
> >>>> based on a
> >>>>> call flow, is not the most easy to follow. But, that could
> >>>> just be me.
> >>>>
> >>>> What do you think could improve the readability of the document?
> >>> [Ahmad]
> >>> Quite some of them... But I gave up after a while....
> >>>
> >>>> Regards,
> >>>> --
> >>>> Hidetoshi
> >>>>
> >>>>> Regards,
> >>>>> Ahmad
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: [e-mail]
> >>>>>> [mailto:[e-mail]] On Behalf Of Muhanna, Ahmad
> >>>>>> (RICH1:2H10)
> >>>>>> Sent: Thursday, September 17, 2009 9:23 PM
> >>>>>> To: Hidetoshi Yokota
> >>>>>> Cc: Mipshop; [e-mail]
> >>>>>> Subject: Re: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6
> >>>>>>
> >>>>>> Hi Hidetoshi,
> >>>>>> Please see inline.
> >>>>>>
> >>>>>> Regards,
> >>>>>> Ahmad
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Hidetoshi Yokota [mailto:[e-mail]]
> >>>>>>> Sent: Thursday, September 17, 2009 4:48 PM
> >>>>>>> To: Muhanna, Ahmad (RICH1:2H10)
> >>>>>>> Cc: Mipshop; [e-mail];
> >>> 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?
> >>>>>>
> >>>>>> Since the GRE keys are necessary to establish the lateral
> >>>> tunnel and
> >>>>>> identify the MN traffic, the draft must specify a default
> >>>> mechanism.
> >>>>>> Other mechanisms can be used or specified some where else
> >>>> if needed,
> >>>>>> but we need a default one here. Right?
> >>>>>>
> >>>>>> Also, you replaced the **HoA of the MN** with the **MN ID**.
> >>>>>> What is the reason for this change?
> >>>>>> And how this should work NOW while you have ".. and/or
> GRE Keys"?
> >>>>>>
> >>>>>>> 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:[e-mail]]
> >>>>>>>>> Sent: Monday, September 14, 2009 7:37 AM
> >>>>>>>>> To: Muhanna, Ahmad (RICH1:2H10)
> >>>>>>>>> Cc: Mipshop; [e-mail];
> >>>>>> 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: [e-mail]
> >>>>>>>>>>> [mailto:[e-mail]] On Behalf Of
> >>>> Hidetoshi Yokota
> >>>>>>>>>>> Sent: Wednesday, September 02, 2009 11:12 PM
> >>>>>>>>>>> To: Jari Arkko
> >>>>>>>>>>> Cc: Mipshop; [e-mail]
> >>>>>>>>>>> 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
> >>>>>>>>>>>> [e-mail]
> >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mipshop
> >>>>>>>>>>> _______________________________________________
> >>>>>>>>>>> Mipshop mailing list
> >>>>>>>>>>> [e-mail]
> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mipshop
> >>>>>>>>>>>
> >>>>>>>>
> >>>>>>> --
> >>>>>>> Hidetoshi Yokota
> >>>>>>>
> >>>>>>> Mobile Network Lab
> >>>>>>> KDDI R&D Laboratories, Inc.
> >>>>>>> e-mail:[e-mail]
> >>>>>>>
> >>>>>>>
> >>>>>> _______________________________________________
> >>>>>> Mipshop mailing list
> >>>>>> [e-mail]
> >>>>>> https://www.ietf.org/mailman/listinfo/mipshop
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>
> >>
> >> This email and any attachments may contain legally
> privileged and/or
> >> confidential information of Starent Networks, Corp. and is
> intended
> >> only for the individual or entity named in the message.  The
> >> information transmitted may not be used to create or change any
> >> contractual obligations of Starent Networks, Corp.  Any review,
> >> retransmission, dissemination or other use of, or taking of any
> >> action in reliance upon this e-mail and its attachments by
> persons or
> >> entities other than the intended recipient is prohibited.
> If you are
> >> not the intended recipient, please notify the sender
> immediately -- 
> >> by replying to this message or by sending an email to
> >> [e-mail] -- and destroy all copies of this
> >> message and any attachments without reading or disclosing
> their contents. Thank you.
> >>
> >>
> >>
> >
>
>