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

[Frank Xia <[e-mail]>]

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.

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.
> > >>
> > >>
> > >>
> > >
> >
> >
>
>