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

["Ahmad Muhanna" <[e-mail]>]

Hi Hidetoshi,

As per our phone conversation, you will be publishing a new revision to
address the technical details and the options for establishing the
inter-MAG bidirectional tunnel. As I mentioned before, looking forward
for your update.

Cheers!

Regards,
Ahmad
 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Muhanna, Ahmad 
> (RICH1:2H10)
> Sent: Sunday, September 27, 2009 3:26 AM
> To: Hidetoshi Yokota
> Cc: Mipshop; [e-mail]
> Subject: Re: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6
> 
> Hi Hidetoshi,
> Thanks for your responses. 
> I think we have enough common ground to enable us move 
> forward, and I believe your next revision will hopefully has 
> all the needed clarifications. Looking forward to read your 
> next revision.
> 
> Thanks again!
> Just one comment inline.
> 
> Regards,
> Ahmad
> 
> > -----Original Message-----
> > From: Hidetoshi Yokota [mailto:[e-mail]]
> > Sent: Sunday, September 27, 2009 1:30 AM
> > To: Muhanna, Ahmad (RICH1:2H10)
> > Cc: Mipshop; [e-mail]
> > Subject: Re: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6
> > 
> > Hi Ahmad,
> > 
> > Sorry, but we should have answered your questions much earlier.
> > 
> > Ahmad Muhanna wrote:
> > > 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! :)
> > 
> > I'm always serious ;-). Please see inline:
> [Ahmad]
> Agreed!
> 
> > 
> > > 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?
> > 
> > The above tunneling types are supported.
> > 
> > > 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.
> > 
> > Ok. We will add the header format and mapping rules in the document.
> > 
> > >>> 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.
> > 
> > The motivation, basic concept and fast handover mechanisms are the 
> > same as those of RFC5568, which I believe is the major part of this 
> > document.
> > In terms of encapsulation methods, I admit that we should add more 
> > explanations.
> > 
> > > 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.
> > 
> > I see. We will update the document adding the statement 
> that the same 
> > tunneling mechanism as that between the LMA and MAG should 
> be used for 
> > 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.
> > 
> > The document will be updated as stated above.
> > 
> > >>> 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.
> > 
> > When, for example, IPv6-in-IPv4-UDP is decided to be used 
> between the 
> > LMA and MAG, it should be configured to behave like that a 
> priori. The 
> > same principle is applied. It should be configured on both 
> MAGs that 
> > the same tunneling mechanism is used. There is no 
> sophisticated method 
> > here.
> > 
> > If there is something to be considered, that will be the UDP port 
> > number for this tunneling. As far as it is configured correctly on 
> > both MAGs, any number can be used, but it may save some operational 
> > task by assigning a specific number. In the case of 
> > <draft-ietf-netlmm-pmip6-ipv4-support>, the port number assigned for
> > RFC5555 (DSMIPv6) is used. A new number could be assigned for the 
> > inter-MAG tunnel likewise, but I'm totally open about it.
> > 
> > >>> 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.
> > 
> > The document will be updated clarifying the above.
> > 
> > >>> 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?
> > 
> > I think the new text for that part, which we are discussing 
> in another 
> > thread, will make it clear.
> > 
> > > 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?
> > 
> > I guess you are talking about multiple bindings. According 
> to Section
> > 3.1 of <draft-ietf-netlmm-grekey-option>, GRE Key Option 
> handles only 
> > an individual flow. This capability will be inherited in PFMIPv6 as 
> > far as this option is used.
> > If
> > multiple bindings need to be handled, multiple HI/HAck 
> exchanges will 
> > occur. We will update the document by clarifying that one HI/HAck 
> > exchange handles an individual flow.
> > 
> > >>> 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.
> > 
> > By the same token, is there any technical data that the above 
> > assumption  could deteriorate the overall performance or something?
> > Anyway, this is not mandatory and the operator can choose whatever 
> > method they want as far as it is configured on both MAGs.
> > 
> > One potentially beneficial capability would be that if the HI/HAck 
> > messages have "T" flag as defined in 
> > <draft-ietf-netlmm-grekey-option>,
> > it will become able to follow the tunneling renegotiation 
> between the 
> > LMA and MAG. I don't know how much this happens, though...
> 
> > 
> > >>> 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.
> > 
> > Ok.
> > 
> > >>> 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?
> > 
> > The tunnel between the LMA and MAG for a mobile node will be 
> > dynamically established, but the tunneling method should be 
> determined 
> > in advance.
> > The only exception is the TLV-header negotiation with the T-flag.
> > 
> > Although the operator usually knows whether the TLV-header 
> should be 
> > used or not in advance, it may be beneficial to define the 
> same flag 
> > in the HI and HAck messages as well.
> > 
> > > 
> > >>> 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?
> > 
> > Again, the new text, which we are discussing in another 
> thread, will 
> > make it clear enough, 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......
> > 
> > The tunnel between the LMA and MAG is dynamically 
> established, but the 
> > tunneling type should be determined in advance.
> > At this point, there is no specification that enables the tunneling 
> > type negotiation between the LMA and MAG, so from the 
> perspective of 
> > IETF standards, the tunneling type should be determined in advance 
> > (with the exception of T-flag). As a side note, Frank, Suresh and I 
> > are proposing a draft that makes this negotiation possible, 
> but it is 
> > still an individual one.
> > 
> > > 
> > >>> 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?
> > 
> > Possible, but less flexible.
> > 
> > > 2. Is it the same set of GRE keys between the PMAG and LMA?
> > 
> > Possible, but less likely. Need to investigate the risk of 
> collisions 
> > and others.
> > 
> > > 3. If none of the above, how these GRE keys are generated and 
> > > exchanged between the PMAG and the NMAG?
> > 
> > By the HI/HAck exchange, which is most assumed in the 
> document. Again, 
> > the new text in another thread will make it clear.
> > 
> > >>> 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.
> > 
> > If GRE keys are used on the PMIPv6 tunnel, they are also 
> needed on the 
> > inter-MAG tunnel to distinguish each flow. If the transport network 
> > between MAGs is IPv4, IPv4 tunneling is needed. If there is a NAT 
> > between the MAGs, then UDP tunneling will be needed. In a nutshell, 
> > all the issues discussed for PMIPv6 could happen for the inter-MAG 
> > tunnel.
> > Eventually, the same types of tunneling mechanisms will be needed.
> > 
> > >> 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.
> > 
> > The above case is mostly what the spec tries to express. Only the 
> > other thing is that the PMAG and LMA do not negotiate 
> whether the GRE 
> > encapsulation is used or not, but it's already been configured that 
> > way, right? Is there any negotiation mechanism between them in 
> > RFC5213?
> > 
> > > 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..
> > 
> > I don't think there is any tunneling mode negotiation mechanism in 
> > RFC5213. I may miss something, but if there is such a 
> mechanism, we'll 
> > need to incorporate it in the PFMIPv6 spec...
> > 
> > > 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.
> > 
> > The assumption here is that the LMA, PMAG and NMAG know the 
> tunneling 
> > mechanism for PMIPv6 tunneling (LMA-PMAG and LMA-NMAG), and 
> the same 
> > mechanism is used for the inter-MAG tunnel.
> > 
> > >>> 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.
> > 
> > The tunnel establishment is done on-demand, but the encapsulation 
> > mechanism should be determined in advance.
> > Necessary parameters such as GRE keys for GRE encapsulation are 
> > exchanged between the LMA and MAG, but whether GRE encapsulation is 
> > used or IPv6-in-IPv4-UDP is used should be configured, I think. In 
> > actual operations, such things are usually configured by hand or 
> > something.
> > 
> > Anyway, what can be done by GRE Key Option should also be available 
> > for
> > PFMIPv6 (since the same option is used).
> > 
> > >>> 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?
> > 
> > If the tunneling mechanism is IPv6-in-IPv4-UDP, the same 
> mechanism is 
> > used.
> > 
> > > 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!
> > 
> > The simplest reason is that this assumption is simplest. 
> > Again, this is not mandatory and if both MAGs are configured to use 
> > the same tunneling mechanism, that will be fine.
> > However, you may need extra care. For example, suppose you 
> decide to 
> > use IPv6-in-IPv6 tunneling for the inter-MAG tunnel permanently. If 
> > the tunnel between the MAG and LMA used GRE encapsulation with GRE 
> > keys, it would not work...
> > 
> > >>> 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?
> > 
> > Of course, that is the inter-MAG tunnel between the PMAG 
> and NMAG. The 
> > details are described in Section 4, which may not be 
> detailed enough 
> > from your viewpoint...
> > 
> > >>> 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....
> > 
> > I asked a wrong question...:-)  But please don't give up.
> > 
> > Regards,
> > --
> > Hidetoshi
> > 
> > >> 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
> > >>>>
> > >>>
> > >>>
> > >>
> > > 
> > > 
> > > 
> > 
> > 
> _______________________________________________
> Mipshop mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mipshop
>