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

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

> -----Original Message-----
> From: Frank Xia [mailto:[e-mail]] 
> Subject: Re: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6
> 
> Hi Ahmad
> 
> Sorry not studying every words from you, even though I have 
> followed the thread.
> 
> If  I can bother you give me some different brief information 
> other than Hidetoshi's summary, you are appreciated.
> 
> Let's try to be more constructive.
[Ahmad]
That's fine, but it is not healthy to repeat the whole thing over again.
Sorry, if you are interested you should go back and read the whole
thing.

Regards,
Ahmad
> 
> 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 10:53 AM
> Subject: RE: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6
> 
> 
> Hi Frank,
> It is confusing..
> You just said in your earlier email that you have been 
> following the discussion! :) Probably the best way for you is 
> to go and look it over.
> 
> Regards,
> Ahmad
> 
> 
> > -----Original Message-----
> > From: Frank Xia [mailto:[e-mail]]
> > Sent: Thursday, September 24, 2009 8:51 AM
> > To: Muhanna, Ahmad (RICH1:2H10); Hidetoshi Yokota
> > Cc: Mipshop; [e-mail]
> > Subject: Re: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6
> >
> > 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.
> > > >>
> > > >>
> > > >>
> > > >
> > >
> > >
> >
> > 
> 
>