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

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 2 Oct 2009 07:31:54 -0500

Hi Hidetoshi,

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

Cheers!

Regards,
Ahmad

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Muhanna, Ahmad 
> (RICH1:2H10)
> Sent: Sunday, September 27, 2009 3:26 AM
> To: Hidetoshi Yokota
> Cc: Mipshop; [email-masked]
> Subject: Re: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6
> 
> Hi Hidetoshi,
> Thanks for your responses. 
> I think we have enough common ground to enable us move 
> forward, and I believe your next revision will hopefully has 
> all the needed clarifications. Looking forward to read your 
> next revision.
> 
> Thanks again!
> Just one comment inline.
> 
> Regards,
> Ahmad
> 
> > -----Original Message-----
> > From: Hidetoshi Yokota [mailto:[email-masked]]
> > Sent: Sunday, September 27, 2009 1:30 AM
> > To: Muhanna, Ahmad (RICH1:2H10)
> > Cc: Mipshop; [email-masked]
> > Subject: Re: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6
> > 
> > Hi Ahmad,
> > 
> > Sorry, but we should have answered your questions much earlier.
> > 
> > Ahmad Muhanna wrote:
> > > Hi Hidetoshi,
> > > 
> > > Thanks for your thoughts on this. 
> > > I expected a little more serious ones:), but please see
> > some more of
> > > the same thoughts inline! :)
> > 
> > I'm always serious ;-). Please see inline:
> [Ahmad]
> Agreed!
> 
> > 
> > > Regards,
> > > Ahmad
> > >> -----Original Message-----
> > >> From: Hidetoshi Yokota [mailto:[email-masked]]
> > >> Sent: Tuesday, September 22, 2009 6:20 AM
> > >> To: Muhanna, Ahmad (RICH1:2H10)
> > >> Cc: Mipshop; [email-masked]
> > >> Subject: Re: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6
> > >>
> > >> Hi Ahmad,
> > >>
> > >> Thanks for your detailed thoughts. Below, we try to answer your 
> > >> questions as best we can.
> > >>
> > >> Ahmad Muhanna wrote:
> > >>> Hi Hidetoshi,
> > >>>
> > >>> Looking one more time into the draft I found the 
> following under 
> > >>> section
> > >>> 4.1:
> > >>>
> > >>> "
> > >>>    The encapsulation type for these user packets SHOULD
> > >> follow that used
> > >>>    in the tunnel between the LMA and MAG (IPv6-in-IPv6 as
> > >> specified in
> > >>>    [RFC2473], IPv6-in-IPv4, IPv6-in-IPv4-UDP as specified in
> > >>>    [IPv4PMIPv6], TLV-header UDP tunneling as specified in
> > >> [GREKEY] or
> > >>>    any new method defined in the future).
> > >>> "
> > >> The intention here is that the inter-MAG tunnel should 
> support all 
> > >> the encapsulation types that are mentioned in RFC5213.
> > > [Ahmad]
> > > Well, whatever it is this document supports, it needs to
> > make it clear
> > > and ensure that it works. My question is the following: Does this 
> > > document support ONLY IPv6-in-IPv6 tunneling between the
> > MAG and the
> > > LMA? or it also supports the different tunneling that the 
> document 
> > > claims to support as quoted above?
> > 
> > The above tunneling types are supported.
> > 
> > > If it only supports IPv6-in-IPv6, this document MUST 
> document that 
> > > clearly. On the other hand, if it supports the above listed
> > tunneling
> > > protocols, it MUST document how forwarding these packets over the 
> > > inter-MAG tunnel works.
> > 
> > Ok. We will add the header format and mapping rules in the document.
> > 
> > >>> IMO, this is a very broad statement that underestimates its
> > >> content. 
> > >>> It is way underspecified how these tunneling protocols will
> > >> be used to
> > >>> successfully map the traffic from the MAG-LMA tunnel to
> > the MAG-MAG
> > >>> tunnel. In this regard, I have the following questions:
> > >>>
> > >>> 1. Is it documented any where how this mapping would work
> > >> for all of
> > >>> these tunneling/encapsulation mechanisms?
> > >> It seems that the mapping of these flows is rather 
> implementation 
> > >> specific. Is there anything that should be considered in
> > addition to
> > >> RFC5568?
> > > 
> > > [Ahmad]
> > > Of course. I guess you need to get out of the mode that
> > this document
> > > is nothing but few tweaks to make FMIP6 works for PMIPv6. 
> > In RFC5568,
> > > it clearly assumes that protocol is used for fast 
> handover when IP 
> > > Mobility based on MIP6 as described in RFC3775. In that 
> sense, only
> > > IPv6-in-IPv6 is assumed.
> > 
> > The motivation, basic concept and fast handover mechanisms are the 
> > same as those of RFC5568, which I believe is the major part of this 
> > document.
> > In terms of encapsulation methods, I admit that we should add more 
> > explanations.
> > 
> > > Again, the above claim of supporting all these tunneling 
> mechanisms 
> > > should either be removed and clearly document that this
> > protocol works
> > > ONLY when the tunneling between the MAG and LMA is 
> IPv6-in-IPv6 or 
> > > explain how they will work.....
> > > 
> > >>> 2. Is the tunneling mode (between the PMAG and the LMA) 
> > >>> negotiated/communicated between the PMAG-MAGs?
> > >> If the tunneling mode is determined between the LMA and
> > PMAG, which
> > >> is in the scope of RFC5213, that of the inter-MAG tunnel should 
> > >> follow it.
> > >> It is also assumed that the same type of tunneling will be used 
> > >> between the LMA and NMAG.
> > > 
> > > [Ahmad]
> > > Sure, but your document claim that it supports all of these
> > tunneling
> > > mechanisms (as per the quoted text from section 4.1) and at
> > the same
> > > time documents nothing about how these should work across the 
> > > inter-MAG tunnel.
> > 
> > I see. We will update the document adding the statement 
> that the same 
> > tunneling mechanism as that between the LMA and MAG should 
> be used for 
> > the inter-MAG tunnel.
> > 
> > >>> 3. If the tunneling between the PMAG-LMA is
> > >> IPv6-in-IPv4-UDP, Does it
> > >>> mean the tunneling between the PMAG-NMAG is also going to
> > >> use the same
> > >>> encapsulation?
> > >> Yes, that is the basic idea.
> > > [Ahmad]
> > > Good. Then How that should work?
> > > Is there anything in your document which specify that? I am
> > all ears,
> > > just point me to the text.
> > 
> > The document will be updated as stated above.
> > 
> > >>> 4. If the UDP tunneling between the two MAGs is not needed,
> > >> what kind
> > >>> of tunneling will be used between the two MAGs to correctly
> > >> map the MN
> > >>> traffic and successfully deliver it to the MN?
> > >> That mode has not been considered. It will be possible,
> > but is there
> > >> any reason that a different type of tunneling should be used?
> > > 
> > > [Ahmad]
> > > I am not suggesting to use a different tunneling mechanism
> > between the
> > > PMAG and the NMAG; However, You are saying that, e.g., 
> > > IPv6-in-IPv4-UDP is naturally extended over the PMAG-NMAG tunnel 
> > > without saying how it should work. That what I was 
> speculating that 
> > > you probably use a specific tunneling, of course, other
> > than IPv6-in-IPv6 to make it work.
> > > 
> > > So, again, if PMAG-NMAG interface does support all these 
> tunneling 
> > > mechanisms, then we need to know how it works? That is all.
> > 
> > When, for example, IPv6-in-IPv4-UDP is decided to be used 
> between the 
> > LMA and MAG, it should be configured to behave like that a 
> priori. The 
> > same principle is applied. It should be configured on both 
> MAGs that 
> > the same tunneling mechanism is used. There is no 
> sophisticated method 
> > here.
> > 
> > If there is something to be considered, that will be the UDP port 
> > number for this tunneling. As far as it is configured correctly on 
> > both MAGs, any number can be used, but it may save some operational 
> > task by assigning a specific number. In the case of 
> > <draft-ietf-netlmm-pmip6-ipv4-support>, the port number assigned for
> > RFC5555 (DSMIPv6) is used. A new number could be assigned for the 
> > inter-MAG tunnel likewise, but I'm totally open about it.
> > 
> > >>> 5. Do these tunneling mechanisms include plain GRE
> > >> Encapsulation with
> > >>> GRE keys or only GRE with TLV-header UDP tunneling?
> > >> <draft-ietf-netlmm-grekey-option> supports both modes, so
> > >> PFMIPv6 should also support them.
> > > [Ahmad]
> > > That is a clear answer. Thanks.
> > > Could you please make sure that your document clarify and clearly 
> > > document it.
> > 
> > The document will be updated clarifying the above.
> > 
> > >>> 5.1. If plain GRE encapsulation with keys is used, then the
> > >> document
> > >>> needs to clearly specify if there are two sets of GRE
> > keys for the
> > >>> same mobility session or only one set? i.e., GRE Keys 
> between the 
> > >>> PMAG-LMA, GRE Keys for PMAG-NMAG or one set is used. It is
> > >> not clear
> > >>> in the current document.
> > >> PFMIPv6 describes only GRE keys for the inter-MAG tunnel
> > (PMAG-NMAG),
> > >> which I think is clarified in Section 4.2. As far as GRE
> > Key Option
> > >> is used, it is difficult to transport multiple sets of 
> keys at one 
> > >> time.
> > > [Ahmad]
> > > Well,
> > > 1. It is not clarified nor clear under section 4.2. but, 
> could you 
> > > please point me to the text you are talking about?
> > 
> > I think the new text for that part, which we are discussing 
> in another 
> > thread, will make it clear.
> > 
> > > 2. As far as of multiple GRE keys exchange, currently that is a 
> > > limitation of the PMIPv6 protocol. Right? Then, when you
> > need multiple
> > > GRE keys, how these GRE keys are communicated? Is that 
> explained in 
> > > the document?
> > 
> > I guess you are talking about multiple bindings. According 
> to Section
> > 3.1 of <draft-ietf-netlmm-grekey-option>, GRE Key Option 
> handles only 
> > an individual flow. This capability will be inherited in PFMIPv6 as 
> > far as this option is used.
> > If
> > multiple bindings need to be handled, multiple HI/HAck 
> exchanges will 
> > occur. We will update the document by clarifying that one HI/HAck 
> > exchange handles an individual flow.
> > 
> > >>> 5.2. same question as in 4, if there is GRE with TLV-header UDP 
> > >>> tunneling between the PMAG and the LMA, Is that needed
> > between the
> > >>> PMAG-NMAG? If NOT, what encapsulation mechanism is being
> > >> used and how
> > >>> is the mapping works?
> > >> The working assumption is "yes".
> > > [Ahmad]
> > > That is a huge CLAIM that is NOT backed by any technical 
> data! How 
> > > that should work? Can you document that some where in the 
> > > specification? If it is already document, please point me
> > to the text.
> > 
> > By the same token, is there any technical data that the above 
> > assumption  could deteriorate the overall performance or something?
> > Anyway, this is not mandatory and the operator can choose whatever 
> > method they want as far as it is configured on both MAGs.
> > 
> > One potentially beneficial capability would be that if the HI/HAck 
> > messages have "T" flag as defined in 
> > <draft-ietf-netlmm-grekey-option>,
> > it will become able to follow the tunneling renegotiation 
> between the 
> > LMA and MAG. I don't know how much this happens, though...
> 
> > 
> > >>> 6. Is the assumption here that the NMAG and the PMAG have
> > the same
> > >>> transport with the LMA?
> > >> For the sake of simplicity, the answer should be "yes".
> > >> If not, the network between MAGs should provide the transparent 
> > >> environment (e.g., by another tunneling).
> > >>
> > >>> 7. with respect to "any new method defined in the future" 
> > >> what is the
> > >>> constraints on this statement? It seems to me an
> > >> overstatement of the
> > >>> capabilities of this protocol and an underestimate of 
> the future 
> > >>> tunneling mechanism. May be you need to make sure that the
> > >> wording is
> > >>> correct by having some conditional restrictions.
> > >> The intention here is that if a new tunneling mechanism is
> > specified
> > >> for  PMIPv6, PFMIPv6 should also support it. If this is
> > too vague, it
> > >> could be removed.
> > > [Ahmad]
> > > Sure, please remove it. Unless, you propose a dynamic tunneling 
> > > mechanism that is forward compatible and capable to 
> address future 
> > > tunneling between the PMAG and LMA.
> > 
> > Ok.
> > 
> > >>> In addition,
> > >>> ============
> > >>> IMO and based on a quick review of this draft, I find it
> > very vague
> > >>> and does not have the details for an Interoperable
> > >> protocol. I believe
> > >>> the draft SHOULD CLEARLY address the following points:
> > >>>
> > >>> Decide whether it needs to specify/support a single tunneling 
> > >>> encapsulation mechanism between the PMAG-NMAG or more than one.
> > >>>
> > >>>
> > >>> SINGLE tunneling and encapsulation mechanism between PMAG-NMAG:
> > >>> ===============================================================
> > >>> 1. This *protocol* needs to specify the exact details 
> of how this 
> > >>> tunneling mechanism is dynamically established to address
> > >> the nature
> > >>> of the problem being address in this *handover optimization
> > >> protocol*.
> > >>
> > >> The nature of the specification and its performance is based on 
> > >> RFC5568.
> > > [Ahmad]
> > > That is part of the problem not to be sited here as a supporting 
> > > argument!
> > > As I said earlier, RFC5568 assumes that there is always
> > IPv6-in-IPv6
> > > tunneling between the mobile node and the home agent. In 
> the case of
> > > PMIPv6 that assumption is INVALID.
> > > 
> > >> Whether the establishment of the tunneling mechanism is 
> dynamic or 
> > >> static is operation-specific.
> > > [Ahmad]
> > > That is NOT true. This document is supposedly offering a
> > fast handover
> > > mechanism for PMIPv6 which dynamically does (implicitly or
> > explicitly)
> > > negotiates tunneling between the MAG and the LMA. So, how a
> > statically
> > > configured tunnel between the PMAG and the NMAG tunnels a
> > mobile node
> > > traffics when the mobile node traffic between the PMAG and
> > LMA for the
> > > same mobile node was dynamically negotiated?
> > 
> > The tunnel between the LMA and MAG for a mobile node will be 
> > dynamically established, but the tunneling method should be 
> determined 
> > in advance.
> > The only exception is the TLV-header negotiation with the T-flag.
> > 
> > Although the operator usually knows whether the TLV-header 
> should be 
> > used or not in advance, it may be beneficial to define the 
> same flag 
> > in the HI and HAck messages as well.
> > 
> > > 
> > >>> 1.1. for example, if GRE with Keys is being used, then 
> it MUST be 
> > >>> clear how the GRE keys are exchanged between the PMAG-NMGA,
> > >> similar to PMIPv6.
> > >>
> > >> The current text proposal for Section 4.2 tries to clarify it 
> > >> regarding who selects the key and how it is transferred.
> > > [Ahmad]
> > > Hmmm.. Tries to clarify ... I guess we need a clear
> > specification that
> > > documents an Interoperable solution. We can not just propose a 
> > > standard track document that is some what clear in the mind
> > of some. Right?
> > 
> > Again, the new text, which we are discussing in another 
> thread, will 
> > make it clear enough, right?
> > 
> > >>> 2. How the chosen PMAG-NMAG tunneling protocol is able to
> > interwork
> > >>> with all tunneling mechanisms that are currently supported
> > >> by PMIPv6,
> > >>> e.g., IPv6-in-IPv6, IPv6-in-IPv4, IPv6-in-IPv4 UDP, etc. 
> > >> between the
> > >>> PMAG-LMA as is being claimed under section 4.2 of this draft.
> > >> Basically, it is supposed that the same tunneling 
> protocol as that 
> > >> between the LMA and MAG is used. The tunneling type
> > between the LMA
> > >> and MAG should be determined in advance.
> > > [Ahmad]
> > > I guess this answer is more confusing .... One time you
> > said that the
> > > tunnel can be static and can be dynamic. Now, you just said
> > that the
> > > tunnel should be STATIC? I mean what is it? It needs
> > clarification......
> > 
> > The tunnel between the LMA and MAG is dynamically 
> established, but the 
> > tunneling type should be determined in advance.
> > At this point, there is no specification that enables the tunneling 
> > type negotiation between the LMA and MAG, so from the 
> perspective of 
> > IETF standards, the tunneling type should be determined in advance 
> > (with the exception of T-flag). As a side note, Frank, Suresh and I 
> > are proposing a draft that makes this negotiation possible, 
> but it is 
> > still an individual one.
> > 
> > > 
> > >>> 3. This *protocol* needs to clearly specify how the
> > >> different mobility
> > >>> sessions are being mapped between the PMAG-LMA tunneling to the 
> > >>> PMAG-NMAG tunneling? Somewhat similar to 2 above.
> > >> The basic mechanism is the same as in RFC5568. 
> > > [Ahmad]
> > > Again, in the case of RFC5568 it is straight forward. Only
> > > IPv6-in-IPv6 is supported as per RFC3775. Not the case for PMIPv6.
> > > 
> > >> If a GRE
> > >> tunnel further differentiates the session, the GRE key
> > will be used.
> > > [Ahmad]
> > > Good. Which GRE Key then?
> > > 1. Is that a statically configured GRE key?
> > 
> > Possible, but less flexible.
> > 
> > > 2. Is it the same set of GRE keys between the PMAG and LMA?
> > 
> > Possible, but less likely. Need to investigate the risk of 
> collisions 
> > and others.
> > 
> > > 3. If none of the above, how these GRE keys are generated and 
> > > exchanged between the PMAG and the NMAG?
> > 
> > By the HI/HAck exchange, which is most assumed in the 
> document. Again, 
> > the new text in another thread will make it clear.
> > 
> > >>> Multiple Tunneling and encapsulation mechanisms between the
> > >> PMAG-NMAG:
> > >> 
> > 
> =====================================================================
> > >> =
> > >>> If the choice as being claimed under section 4.1, is to
> > >> support all of
> > >>> the current tunneling mechanisms between PMAG-LMA on the
> > PMAG-NMAG
> > >>> interface, then the protocol needs to address the following:
> > >>>
> > >>> 1. Provide a good analysis why that option is the best
> > option? What
> > >>> are the advantages and the disadvantages?
> > >> I think that is the most workable solution. 
> > > {Ahmad]
> > > What do you have to technically back up this statement. 
> > Otherwise, it
> > > is just another statement.
> > 
> > If GRE keys are used on the PMIPv6 tunnel, they are also 
> needed on the 
> > inter-MAG tunnel to distinguish each flow. If the transport network 
> > between MAGs is IPv4, IPv4 tunneling is needed. If there is a NAT 
> > between the MAGs, then UDP tunneling will be needed. In a nutshell, 
> > all the issues discussed for PMIPv6 could happen for the inter-MAG 
> > tunnel.
> > Eventually, the same types of tunneling mechanisms will be needed.
> > 
> > >> Since the
> > >> tunneling mechanism selected for the PMIPv6 tunnel is 
> supported by 
> > >> both the PMAG and NMAG, no extra capability is required for the 
> > >> inter-MAG tunnel.
> > > [Ahmad]
> > > OK. I am not disputing that the PMAG and the NMAG 
> supports the same 
> > > sets of tunneling mechanisms or not. It is more of which
> > tunnel to use
> > > for which mobile node session and what parameter is 
> needed for this 
> > > inter-MAG tunnel to correctly tunnel the mobile node traffic and 
> > > deliver it to the end of the tunnel in a non ambiguous way.
> > > 
> > > For example:
> > > Tunneling Case 1:
> > > =================
> > > 1. PMAG and the LMA negotiates the GRE encapsulation and
> > the GRE keys
> > > using the PBU and PBA for each applicable mobility session.
> > > 2. It is very well understood that both the PMAG and the
> > NMAG support
> > > GRE tunneling with GRE keys + GRE keys exchange using
> > PMIPv6 signaling
> > > with the LMA.
> > > 3. Now: for the inter-MAG tunnel and for the same 
> mobility session, 
> > > how GRE tunneling and GRE keys are negotiated between the 
> PMAG and 
> > > NMAG? Of course, using HI and HAck, right?
> > > 4. Okay, we need the exact details for this specific case.
> > 
> > The above case is mostly what the spec tries to express. Only the 
> > other thing is that the PMAG and LMA do not negotiate 
> whether the GRE 
> > encapsulation is used or not, but it's already been configured that 
> > way, right? Is there any negotiation mechanism between them in 
> > RFC5213?
> > 
> > > Tunneling Case 2:
> > > =================
> > > 1. Let us assume IPv6-in-IPv4 UDP is used for MN1. Okay 2. That 
> > > tunneling is implicitly negotiated between the PMAG and LMA
> > during the
> > > PBU/PBA exchange, right?
> > > 3. How that is negotiated between the PMAG and the NMAG? We
> > need the
> > > details..
> > 
> > I don't think there is any tunneling mode negotiation mechanism in 
> > RFC5213. I may miss something, but if there is such a 
> mechanism, we'll 
> > need to incorporate it in the PFMIPv6 spec...
> > 
> > > And so on....
> > > 
> > >> Also, I don't see any specific reason to use a special tunneling 
> > >> mechanism for the inter-MAG tunnel.
> > > [Ahmad]
> > > Good. This means you would use the same tunneling between
> > the PMAG and
> > > LMA over inter-MAG tunneling. In this case, we need the 
> details for 
> > > negotiating that tunneling mechanism between the PMAG and 
> the NMAG.
> > 
> > The assumption here is that the LMA, PMAG and NMAG know the 
> tunneling 
> > mechanism for PMIPv6 tunneling (LMA-PMAG and LMA-NMAG), and 
> the same 
> > mechanism is used for the inter-MAG tunnel.
> > 
> > >>> 2. How this *protocol* dynamically negotiates the tunneling
> > >> mechanism
> > >>> type?
> > >> If the tunneling mechanism between the LMA and MAG is
> > determined in
> > >> advance, the same mechanism is used for the inter-MAG
> > tunnel. So, it
> > >> is not on-demand and no negotiation is assumed. If the tunneling 
> > >> mechanism between the LMA and MAG is determined on demand,
> > then that
> > >> is a different story...
> > > 
> > > [Ahmad]
> > > Well, what do you mean? The tunneling between the PMAG and
> > the LMA is
> > > NOT on demand?
> > > I believe IPv4 support for PMIPv6 and GRE key for PMIPv6
> > drafts will
> > > be helpful in answering this question.
> > 
> > The tunnel establishment is done on-demand, but the encapsulation 
> > mechanism should be determined in advance.
> > Necessary parameters such as GRE keys for GRE encapsulation are 
> > exchanged between the LMA and MAG, but whether GRE encapsulation is 
> > used or IPv6-in-IPv4-UDP is used should be configured, I think. In 
> > actual operations, such things are usually configured by hand or 
> > something.
> > 
> > Anyway, what can be done by GRE Key Option should also be available 
> > for
> > PFMIPv6 (since the same option is used).
> > 
> > >>> 3. How that should work, for example if the tunneling mechanism 
> > >>> between the PMAG-LMA is IPv6 in IPv4 UDP, how that
> > >> tunneling will be
> > >>> extended to go over the PMAG-NMAG interface and how it is
> > >> supposed to work.
> > >>
> > >> In this case, both the PMAG and NMAG should be dual-stack
> > and the IP
> > >> addresses in the IPv4 outer header are those of the PMAG 
> and NMAG. 
> > >> IPv6 inner header should be kept intact.
> > >>
> > > 
> > > Okay..... Then if the NMAG sends the first packet over the
> > NMAG-PMAG
> > > tunnel! Which encapsulation mechanism is going to use to
> > encapsulate
> > > that packet?
> > 
> > If the tunneling mechanism is IPv6-in-IPv4-UDP, the same 
> mechanism is 
> > used.
> > 
> > > Also, Do you agree that there is a specific reason for 
> the traffic 
> > > between the PMAG and the LMA to be IPv6-in-IPv4-UDP. Right? That 
> > > reason may NOT be VALID between the PMAG and the NMAG. Right?
> > > Then why to use the same tunneling here? Just out of curiosity!
> > 
> > The simplest reason is that this assumption is simplest. 
> > Again, this is not mandatory and if both MAGs are configured to use 
> > the same tunneling mechanism, that will be fine.
> > However, you may need extra care. For example, suppose you 
> decide to 
> > use IPv6-in-IPv6 tunneling for the inter-MAG tunnel permanently. If 
> > the tunnel between the MAG and LMA used GRE encapsulation with GRE 
> > keys, it would not work...
> > 
> > >>> Finally, the draft could have some restrictions and define the 
> > >>> PMAG-NMAG tunneling/encapsulation mechanism and could
> > >> define a set of
> > >>> PMAG-LMA tunneling mechanism that are being
> > >> supported/interwork over
> > >>> the PMAG-NMAG tunneling/encapsulation.
> > >> What kind of restrictions do you foresee? Do you also have any 
> > >> specific mechanism for the inter-MAG tunnel in mind?
> > > [Ahmad]
> > > I guess, you need to answer many of the above comments
> > before we talk
> > > about this. A clear understanding of this tunneling is
> > needed and I do
> > > not see it documented in this draft.
> > > 
> > > BTW: Under section 4, this specification says:
> > > 
> > > "
> > >    In order to further improve the performance during the
> > handover, the
> > >    PFMIPv6 protocol in this document specifies a
> > bi-directional tunnel
> > >    between the Previous MAG (PMAG) and the New MAG (NMAG) 
> to tunnel
> > >    packets meant for the mobile node.  
> > > "
> > > 
> > > Which bi-directional tunnel? Where? What are the details?
> > 
> > Of course, that is the inter-MAG tunnel between the PMAG 
> and NMAG. The 
> > details are described in Section 4, which may not be 
> detailed enough 
> > from your viewpoint...
> > 
> > >>> One more note: I found defining and describing a protocol
> > >> based on a
> > >>> call flow, is not the most easy to follow. But, that could
> > >> just be me.
> > >>
> > >> What do you think could improve the readability of the document?
> > > [Ahmad]
> > > Quite some of them... But I gave up after a while....
> > 
> > I asked a wrong question...:-)  But please don't give up.
> > 
> > Regards,
> > --
> > Hidetoshi
> > 
> > >> Regards,
> > >> --
> > >> Hidetoshi
> > >>
> > >>> Regards,
> > >>> Ahmad
> > >>>  
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: [email-masked]
> > >>>> [mailto:[email-masked]] On Behalf Of Muhanna, Ahmad
> > >>>> (RICH1:2H10)
> > >>>> Sent: Thursday, September 17, 2009 9:23 PM
> > >>>> To: Hidetoshi Yokota
> > >>>> Cc: Mipshop; [email-masked]
> > >>>> Subject: Re: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6
> > >>>>
> > >>>> Hi Hidetoshi,
> > >>>> Please see inline.
> > >>>>
> > >>>> Regards,
> > >>>> Ahmad
> > >>>>
> > >>>>> -----Original Message-----
> > >>>>> From: Hidetoshi Yokota [mailto:[email-masked]]
> > >>>>> Sent: Thursday, September 17, 2009 4:48 PM
> > >>>>> To: Muhanna, Ahmad (RICH1:2H10)
> > >>>>> Cc: Mipshop; [email-masked];
> > 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:[email-masked]]
> > >>>>>>> Sent: Monday, September 14, 2009 7:37 AM
> > >>>>>>> To: Muhanna, Ahmad (RICH1:2H10)
> > >>>>>>> Cc: Mipshop; [email-masked];
> > >>>> 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: [email-masked] 
> > >>>>>>>>> [mailto:[email-masked]] On Behalf Of
> > >> Hidetoshi Yokota
> > >>>>>>>>> Sent: Wednesday, September 02, 2009 11:12 PM
> > >>>>>>>>> To: Jari Arkko
> > >>>>>>>>> Cc: Mipshop; [email-masked]
> > >>>>>>>>> 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
> > >>>>>>>>>> [email-masked]
> > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/mipshop
> > >>>>>>>>> _______________________________________________
> > >>>>>>>>> Mipshop mailing list
> > >>>>>>>>> [email-masked]
> > >>>>>>>>> https://www.ietf.org/mailman/listinfo/mipshop
> > >>>>>>>>>
> > >>>>>>
> > >>>>> --
> > >>>>> Hidetoshi Yokota
> > >>>>>
> > >>>>> Mobile Network Lab
> > >>>>> KDDI R&D Laboratories, Inc.
> > >>>>> e-mail:[email-masked]
> > >>>>>
> > >>>>>
> > >>>> _______________________________________________
> > >>>> Mipshop mailing list
> > >>>> [email-masked]
> > >>>> https://www.ietf.org/mailman/listinfo/mipshop
> > >>>>
> > >>>
> > >>>
> > >>
> > > 
> > > 
> > > 
> > 
> > 
> _______________________________________________
> Mipshop mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mipshop
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 15 Oct 2009 09:24:58 -0500

Forwarding to the mailing list!

-----Original Message-----
From: Hidetoshi Yokota [mailto:[email-masked]] 
Sent: Tuesday, October 13, 2009 8:20 AM
To: Muhanna, Ahmad (RICH1:2H10)
Cc: Vijay Devarapalli; Hidetoshi Yokota
Subject: Re: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6

Hi Ahmad,

I see that you really want to include Option 3, which is a dynamic
tunnel-type negotiation and which is the gap between us... Let me make
sure one thing. In the case of the fast handover protocol, there is no
second HI/HAck exchange for determining the tunnel-type, which otherwise
would cause an unexpected delay. So, if the PMAG sends the PBU with the
GRE Key option and receives the PBA with some error status or without
the GRE Key option, then the PMAG selects IPv6-in-IPv6 for the user data
tunneling. This seems to be a "speculative" negotiation and is that
acceptable for you?

Assuming the above is ok, I would then propose two recommendations: one
is a static configuration (Options 1+2) and the other is a dynamic
negotiation (Option 3). In the former case, one type of tunneling
(IPv6-in-IPv6 or GRE or others) is statically configured, which
obviously has some limitations at the expense of simplicity. In the
latter case, the PMAG determines the tunnel-type per session, which
gives more flexibility, but the negotiation procedure must be specified
for interoperability.

Are we getting closer or still far apart?

Regards,
-- 
Hidetoshi

Ahmad Muhanna wrote:
> Hi Hidetoshi,
> It seems that we are back to square one. But, it does not hurt to
> capture the possible solutions that I suggested earlier.
> 
> OPTION No. 1:
> ===========
> Inter-MAG tunnel type can be statically configured with NO change on
the
> MAG. i.e., no new functionality added. If that is the option, then the
> draft needs to capture the limitation of this choice and define what
> encapsulation would work and what would not work. In other words, make
> some recommendation, kind of.
> This option means the draft will define, for example, if IP6-in-IP6 is
> used for inter-MAG tunnel, then the draft will say that ONLY
IP6-in-IP6
> will be supported between the MAG and the LMA. Then repeat the same
for
> all types of encapsulation...
> 
> 
> OPTION No. 2:
> ===========
> Define a specific type of encapsulation, for example, GRE
encapsulation
> with keys. Then the draft needs to define what kind of enhancement the
> MAG needs to have to map the traffic of all types of encapsulation
> between the MAG and the LMA to the GRE tunnel with keys over the
> inter-MAG tunnel. This also requires a sane GRE keys exchange between
> the PMAG and NMAG. If there is any limitation, it needs to be
specified.
> 
> 
> OPTION No. 3:
> ===========
> Dynamic negotiation of the per-mobility session tunnel type between
the
> PMAG and NMAG using HI/HAck messages. This is the most appropriate
> solution, IMO. There could be some exceptions that needs to be
> documented and some difficulties that need to be addressed.
> 
> Any option used, the traffic needs to be exchanged between the NMAG
and
> PMAG without any ambiguity in order to have a meaningful fast handoff
> mechanism. Otherwise, there is no point of having the whole thing to
> start with.
> 
> Hope this will help.
> Cheers!
> 
> Regards,
> Ahmad
>  
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 15 Oct 2009 09:30:10 -0500

FYI

-----Original Message-----
From: Muhanna, Ahmad (RICH1:2H10) 
Sent: Wednesday, October 14, 2009 12:50 AM
To: 'Hidetoshi Yokota'
Cc: Vijay Devarapalli
Subject: RE: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6

Hi Hidetoshi,
I am responding to your original email and this one here. Please see
inline.

Regards,
Ahmad
> Sent: Tuesday, October 13, 2009 8:22 PM
> >> negotiation (Option 3). 
[Ahmad]
They seem fine with me. Please see below.

> >> In the former case, one type of tunneling
> >> obviously has some limitations at the expense of simplicity. 
[Ahmad]
I am fine to include this option AS LONG AS THE LIMITATION IS CAPTURED
in the draft somewhere.

>>> In the
[Ahmad]
That should be fine with me too.

> >> Are we getting closer or still far apart?
[Ahmad]
YES.
Let us follow on this. Hopefully we are not going to go back and
renegotiate this proposal again! :)

> >>> Inter-MAG tunnel type can be statically configured with NO 
> >> change on the
> >>> used for inter-MAG tunnel, then the draft will say that 
> >> ONLY IP6-in-IP6
> >>> will be supported between the MAG and the LMA. Then repeat 
> >> the same for
> >>> the PMAG and NMAG. If there is any limitation, it needs to 
> >> be specified.
> >>>
> >>> OPTION No. 3:
> >>> ===========
> >>> Dynamic negotiation of the per-mobility session tunnel type 
> >> between the
> >>> Any option used, the traffic needs to be exchanged between 
> >> the NMAG and