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

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

Hi Hidetoshi,
Thanks for your responses. 
I think we have enough common ground to enable us move forward, and I
believe your next revision will hopefully has all the needed
clarifications. Looking forward to read your next revision.

Thanks again!
Just one comment inline.

Regards,
Ahmad

> -----Original Message-----
> From: Hidetoshi Yokota [mailto:[e-mail]] 
> Sent: Sunday, September 27, 2009 1:30 AM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: Mipshop; [e-mail]
> Subject: Re: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6
> 
> Hi Ahmad,
> 
> Sorry, but we should have answered your questions much earlier.
> 
> Ahmad Muhanna wrote:
> > Hi Hidetoshi,
> > 
> > Thanks for your thoughts on this. 
> > I expected a little more serious ones:), but please see 
> some more of 
> > the same thoughts inline! :)
> 
> I'm always serious ;-). Please see inline:
[Ahmad]
Agreed!

> 
> > Regards,
> > Ahmad
> >> -----Original Message-----
> >> From: Hidetoshi Yokota [mailto:[e-mail]]
> >> Sent: Tuesday, September 22, 2009 6:20 AM
> >> To: Muhanna, Ahmad (RICH1:2H10)
> >> Cc: Mipshop; [e-mail]
> >> Subject: Re: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6
> >>
> >> Hi Ahmad,
> >>
> >> Thanks for your detailed thoughts. Below, we try to answer your 
> >> questions as best we can.
> >>
> >> Ahmad Muhanna wrote:
> >>> Hi Hidetoshi,
> >>>
> >>> Looking one more time into the draft I found the following under 
> >>> section
> >>> 4.1:
> >>>
> >>> "
> >>>    The encapsulation type for these user packets SHOULD
> >> follow that used
> >>>    in the tunnel between the LMA and MAG (IPv6-in-IPv6 as
> >> specified in
> >>>    [RFC2473], IPv6-in-IPv4, IPv6-in-IPv4-UDP as specified in
> >>>    [IPv4PMIPv6], TLV-header UDP tunneling as specified in
> >> [GREKEY] or
> >>>    any new method defined in the future).
> >>> "
> >> The intention here is that the inter-MAG tunnel should support all 
> >> the encapsulation types that are mentioned in RFC5213.
> > [Ahmad]
> > Well, whatever it is this document supports, it needs to 
> make it clear 
> > and ensure that it works. My question is the following: Does this 
> > document support ONLY IPv6-in-IPv6 tunneling between the 
> MAG and the 
> > LMA? or it also supports the different tunneling that the document 
> > claims to support as quoted above?
> 
> The above tunneling types are supported.
> 
> > If it only supports IPv6-in-IPv6, this document MUST document that 
> > clearly. On the other hand, if it supports the above listed 
> tunneling 
> > protocols, it MUST document how forwarding these packets over the 
> > inter-MAG tunnel works.
> 
> Ok. We will add the header format and mapping rules in the document.
> 
> >>> IMO, this is a very broad statement that underestimates its
> >> content. 
> >>> It is way underspecified how these tunneling protocols will
> >> be used to
> >>> successfully map the traffic from the MAG-LMA tunnel to 
> the MAG-MAG 
> >>> tunnel. In this regard, I have the following questions:
> >>>
> >>> 1. Is it documented any where how this mapping would work
> >> for all of
> >>> these tunneling/encapsulation mechanisms?
> >> It seems that the mapping of these flows is rather implementation 
> >> specific. Is there anything that should be considered in 
> addition to 
> >> RFC5568?
> > 
> > [Ahmad]
> > Of course. I guess you need to get out of the mode that 
> this document 
> > is nothing but few tweaks to make FMIP6 works for PMIPv6. 
> In RFC5568, 
> > it clearly assumes that protocol is used for fast handover when IP 
> > Mobility based on MIP6 as described in RFC3775. In that sense, only 
> > IPv6-in-IPv6 is assumed.
> 
> The motivation, basic concept and fast handover mechanisms 
> are the same as those of RFC5568, which I believe is the 
> major part of this document.
> In terms of encapsulation methods, I admit that we should add 
> more explanations.
> 
> > Again, the above claim of supporting all these tunneling mechanisms 
> > should either be removed and clearly document that this 
> protocol works 
> > ONLY when the tunneling between the MAG and LMA is IPv6-in-IPv6 or 
> > explain how they will work.....
> > 
> >>> 2. Is the tunneling mode (between the PMAG and the LMA) 
> >>> negotiated/communicated between the PMAG-MAGs?
> >> If the tunneling mode is determined between the LMA and 
> PMAG, which 
> >> is in the scope of RFC5213, that of the inter-MAG tunnel should 
> >> follow it.
> >> It is also assumed that the same type of tunneling will be used 
> >> between the LMA and NMAG.
> > 
> > [Ahmad]
> > Sure, but your document claim that it supports all of these 
> tunneling 
> > mechanisms (as per the quoted text from section 4.1) and at 
> the same 
> > time documents nothing about how these should work across the 
> > inter-MAG tunnel.
> 
> I see. We will update the document adding the statement that 
> the same tunneling mechanism as that between the LMA and MAG 
> should be used for the inter-MAG tunnel.
> 
> >>> 3. If the tunneling between the PMAG-LMA is
> >> IPv6-in-IPv4-UDP, Does it
> >>> mean the tunneling between the PMAG-NMAG is also going to
> >> use the same
> >>> encapsulation?
> >> Yes, that is the basic idea.
> > [Ahmad]
> > Good. Then How that should work?
> > Is there anything in your document which specify that? I am 
> all ears, 
> > just point me to the text.
> 
> The document will be updated as stated above.
> 
> >>> 4. If the UDP tunneling between the two MAGs is not needed,
> >> what kind
> >>> of tunneling will be used between the two MAGs to correctly
> >> map the MN
> >>> traffic and successfully deliver it to the MN?
> >> That mode has not been considered. It will be possible, 
> but is there 
> >> any reason that a different type of tunneling should be used?
> > 
> > [Ahmad]
> > I am not suggesting to use a different tunneling mechanism 
> between the 
> > PMAG and the NMAG; However, You are saying that, e.g., 
> > IPv6-in-IPv4-UDP is naturally extended over the PMAG-NMAG tunnel 
> > without saying how it should work. That what I was speculating that 
> > you probably use a specific tunneling, of course, other 
> than IPv6-in-IPv6 to make it work.
> > 
> > So, again, if PMAG-NMAG interface does support all these tunneling 
> > mechanisms, then we need to know how it works? That is all.
> 
> When, for example, IPv6-in-IPv4-UDP is decided to be used 
> between the LMA and MAG, it should be configured to behave 
> like that a priori. The same principle is applied. It should 
> be configured on both MAGs that the same tunneling mechanism 
> is used. There is no sophisticated method here.
> 
> If there is something to be considered, that will be the UDP 
> port number for this tunneling. As far as it is configured 
> correctly on both MAGs, any number can be used, but it may 
> save some operational task by assigning a specific number. In 
> the case of <draft-ietf-netlmm-pmip6-ipv4-support>, the port 
> number assigned for
> RFC5555 (DSMIPv6) is used. A new number could be assigned for 
> the inter-MAG tunnel likewise, but I'm totally open about it.
> 
> >>> 5. Do these tunneling mechanisms include plain GRE
> >> Encapsulation with
> >>> GRE keys or only GRE with TLV-header UDP tunneling?
> >> <draft-ietf-netlmm-grekey-option> supports both modes, so
> >> PFMIPv6 should also support them.
> > [Ahmad]
> > That is a clear answer. Thanks.
> > Could you please make sure that your document clarify and clearly 
> > document it.
> 
> The document will be updated clarifying the above.
> 
> >>> 5.1. If plain GRE encapsulation with keys is used, then the
> >> document
> >>> needs to clearly specify if there are two sets of GRE 
> keys for the 
> >>> same mobility session or only one set? i.e., GRE Keys between the 
> >>> PMAG-LMA, GRE Keys for PMAG-NMAG or one set is used. It is
> >> not clear
> >>> in the current document.
> >> PFMIPv6 describes only GRE keys for the inter-MAG tunnel 
> (PMAG-NMAG), 
> >> which I think is clarified in Section 4.2. As far as GRE 
> Key Option 
> >> is used, it is difficult to transport multiple sets of keys at one 
> >> time.
> > [Ahmad]
> > Well,
> > 1. It is not clarified nor clear under section 4.2. but, could you 
> > please point me to the text you are talking about?
> 
> I think the new text for that part, which we are discussing 
> in another thread, will make it clear.
> 
> > 2. As far as of multiple GRE keys exchange, currently that is a 
> > limitation of the PMIPv6 protocol. Right? Then, when you 
> need multiple 
> > GRE keys, how these GRE keys are communicated? Is that explained in 
> > the document?
> 
> I guess you are talking about multiple bindings. According to Section
> 3.1 of <draft-ietf-netlmm-grekey-option>, GRE Key Option 
> handles only an individual flow. This capability will be 
> inherited in PFMIPv6 as far as this option is used. 
> If 
> multiple bindings need to be handled, multiple HI/HAck 
> exchanges will occur. We will update the document by 
> clarifying that one HI/HAck exchange handles an individual flow.
> 
> >>> 5.2. same question as in 4, if there is GRE with TLV-header UDP 
> >>> tunneling between the PMAG and the LMA, Is that needed 
> between the 
> >>> PMAG-NMAG? If NOT, what encapsulation mechanism is being
> >> used and how
> >>> is the mapping works?
> >> The working assumption is "yes".
> > [Ahmad]
> > That is a huge CLAIM that is NOT backed by any technical data! How 
> > that should work? Can you document that some where in the 
> > specification? If it is already document, please point me 
> to the text.
> 
> By the same token, is there any technical data that the above 
> assumption  could deteriorate the overall performance or 
> something? 
> Anyway, this is not mandatory and the operator can 
> choose whatever method they want as far as it is configured 
> on both MAGs.
> 
> One potentially beneficial capability would be that if the 
> HI/HAck messages have "T" flag as defined in 
> <draft-ietf-netlmm-grekey-option>,
> it will become able to follow the tunneling renegotiation 
> between the LMA and MAG. I don't know how much this happens, though...

> 
> >>> 6. Is the assumption here that the NMAG and the PMAG have 
> the same 
> >>> transport with the LMA?
> >> For the sake of simplicity, the answer should be "yes".
> >> If not, the network between MAGs should provide the transparent 
> >> environment (e.g., by another tunneling).
> >>
> >>> 7. with respect to "any new method defined in the future" 
> >> what is the
> >>> constraints on this statement? It seems to me an
> >> overstatement of the
> >>> capabilities of this protocol and an underestimate of the future 
> >>> tunneling mechanism. May be you need to make sure that the
> >> wording is
> >>> correct by having some conditional restrictions.
> >> The intention here is that if a new tunneling mechanism is 
> specified 
> >> for  PMIPv6, PFMIPv6 should also support it. If this is 
> too vague, it 
> >> could be removed.
> > [Ahmad]
> > Sure, please remove it. Unless, you propose a dynamic tunneling 
> > mechanism that is forward compatible and capable to address future 
> > tunneling between the PMAG and LMA.
> 
> Ok.
> 
> >>> In addition,
> >>> ============
> >>> IMO and based on a quick review of this draft, I find it 
> very vague 
> >>> and does not have the details for an Interoperable
> >> protocol. I believe
> >>> the draft SHOULD CLEARLY address the following points:
> >>>
> >>> Decide whether it needs to specify/support a single tunneling 
> >>> encapsulation mechanism between the PMAG-NMAG or more than one.
> >>>
> >>>
> >>> SINGLE tunneling and encapsulation mechanism between PMAG-NMAG:
> >>> ===============================================================
> >>> 1. This *protocol* needs to specify the exact details of how this 
> >>> tunneling mechanism is dynamically established to address
> >> the nature
> >>> of the problem being address in this *handover optimization
> >> protocol*.
> >>
> >> The nature of the specification and its performance is based on 
> >> RFC5568.
> > [Ahmad]
> > That is part of the problem not to be sited here as a supporting 
> > argument!
> > As I said earlier, RFC5568 assumes that there is always 
> IPv6-in-IPv6 
> > tunneling between the mobile node and the home agent. In the case of
> > PMIPv6 that assumption is INVALID.
> > 
> >> Whether the establishment of the tunneling mechanism is dynamic or 
> >> static is operation-specific.
> > [Ahmad]
> > That is NOT true. This document is supposedly offering a 
> fast handover 
> > mechanism for PMIPv6 which dynamically does (implicitly or 
> explicitly) 
> > negotiates tunneling between the MAG and the LMA. So, how a 
> statically 
> > configured tunnel between the PMAG and the NMAG tunnels a 
> mobile node 
> > traffics when the mobile node traffic between the PMAG and 
> LMA for the 
> > same mobile node was dynamically negotiated?
> 
> The tunnel between the LMA and MAG for a mobile node will be 
> dynamically established, but the tunneling method should be 
> determined in advance.
> The only exception is the TLV-header negotiation with the T-flag.
> 
> Although the operator usually knows whether the TLV-header 
> should be used or not in advance, it may be beneficial to 
> define the same flag in the HI and HAck messages as well.
> 
> > 
> >>> 1.1. for example, if GRE with Keys is being used, then it MUST be 
> >>> clear how the GRE keys are exchanged between the PMAG-NMGA,
> >> similar to PMIPv6.
> >>
> >> The current text proposal for Section 4.2 tries to clarify it 
> >> regarding who selects the key and how it is transferred.
> > [Ahmad]
> > Hmmm.. Tries to clarify ... I guess we need a clear 
> specification that 
> > documents an Interoperable solution. We can not just propose a 
> > standard track document that is some what clear in the mind 
> of some. Right?
> 
> Again, the new text, which we are discussing in another 
> thread, will make it clear enough, right?
> 
> >>> 2. How the chosen PMAG-NMAG tunneling protocol is able to 
> interwork 
> >>> with all tunneling mechanisms that are currently supported
> >> by PMIPv6,
> >>> e.g., IPv6-in-IPv6, IPv6-in-IPv4, IPv6-in-IPv4 UDP, etc. 
> >> between the
> >>> PMAG-LMA as is being claimed under section 4.2 of this draft.
> >> Basically, it is supposed that the same tunneling protocol as that 
> >> between the LMA and MAG is used. The tunneling type 
> between the LMA 
> >> and MAG should be determined in advance.
> > [Ahmad]
> > I guess this answer is more confusing .... One time you 
> said that the 
> > tunnel can be static and can be dynamic. Now, you just said 
> that the 
> > tunnel should be STATIC? I mean what is it? It needs 
> clarification......
> 
> The tunnel between the LMA and MAG is dynamically 
> established, but the tunneling type should be determined in 
> advance. 
> At this point, there is no specification that 
> enables the tunneling type negotiation between the LMA and 
> MAG, so from the perspective of IETF standards, 
> the tunneling 
> type should be determined in advance (with the exception of 
> T-flag). As a side note, Frank, Suresh and I are proposing a 
> draft that makes this negotiation possible, but it is still 
> an individual one.
> 
> > 
> >>> 3. This *protocol* needs to clearly specify how the
> >> different mobility
> >>> sessions are being mapped between the PMAG-LMA tunneling to the 
> >>> PMAG-NMAG tunneling? Somewhat similar to 2 above.
> >> The basic mechanism is the same as in RFC5568. 
> > [Ahmad]
> > Again, in the case of RFC5568 it is straight forward. Only 
> > IPv6-in-IPv6 is supported as per RFC3775. Not the case for PMIPv6.
> > 
> >> If a GRE
> >> tunnel further differentiates the session, the GRE key 
> will be used.
> > [Ahmad]
> > Good. Which GRE Key then?
> > 1. Is that a statically configured GRE key?
> 
> Possible, but less flexible.
> 
> > 2. Is it the same set of GRE keys between the PMAG and LMA?
> 
> Possible, but less likely. Need to investigate the risk of 
> collisions and others.
> 
> > 3. If none of the above, how these GRE keys are generated and 
> > exchanged between the PMAG and the NMAG?
> 
> By the HI/HAck exchange, which is most assumed in the 
> document. Again, the new text in another thread will make it clear.
> 
> >>> Multiple Tunneling and encapsulation mechanisms between the
> >> PMAG-NMAG:
> >> 
> =====================================================================
> >> =
> >>> If the choice as being claimed under section 4.1, is to
> >> support all of
> >>> the current tunneling mechanisms between PMAG-LMA on the 
> PMAG-NMAG 
> >>> interface, then the protocol needs to address the following:
> >>>
> >>> 1. Provide a good analysis why that option is the best 
> option? What 
> >>> are the advantages and the disadvantages?
> >> I think that is the most workable solution. 
> > {Ahmad]
> > What do you have to technically back up this statement. 
> Otherwise, it 
> > is just another statement.
> 
> If GRE keys are used on the PMIPv6 tunnel, they are also 
> needed on the inter-MAG tunnel to distinguish each flow. If 
> the transport network between MAGs is IPv4, IPv4 tunneling is 
> needed. If there is a NAT between the MAGs, then UDP 
> tunneling will be needed. In a nutshell, all the issues 
> discussed for PMIPv6 could happen for the inter-MAG tunnel.
> Eventually, the same types of tunneling mechanisms will be needed.
> 
> >> Since the
> >> tunneling mechanism selected for the PMIPv6 tunnel is supported by 
> >> both the PMAG and NMAG, no extra capability is required for the 
> >> inter-MAG tunnel.
> > [Ahmad]
> > OK. I am not disputing that the PMAG and the NMAG supports the same 
> > sets of tunneling mechanisms or not. It is more of which 
> tunnel to use 
> > for which mobile node session and what parameter is needed for this 
> > inter-MAG tunnel to correctly tunnel the mobile node traffic and 
> > deliver it to the end of the tunnel in a non ambiguous way.
> > 
> > For example:
> > Tunneling Case 1:
> > =================
> > 1. PMAG and the LMA negotiates the GRE encapsulation and 
> the GRE keys 
> > using the PBU and PBA for each applicable mobility session.
> > 2. It is very well understood that both the PMAG and the 
> NMAG support 
> > GRE tunneling with GRE keys + GRE keys exchange using 
> PMIPv6 signaling 
> > with the LMA.
> > 3. Now: for the inter-MAG tunnel and for the same mobility session, 
> > how GRE tunneling and GRE keys are negotiated between the PMAG and 
> > NMAG? Of course, using HI and HAck, right?
> > 4. Okay, we need the exact details for this specific case.
> 
> The above case is mostly what the spec tries to express. Only 
> the other thing is that the PMAG and LMA do not negotiate 
> whether the GRE encapsulation is used or not, but it's 
> already been configured that way, right? Is there any 
> negotiation mechanism between them in RFC5213?
> 
> > Tunneling Case 2:
> > =================
> > 1. Let us assume IPv6-in-IPv4 UDP is used for MN1. Okay 2. That 
> > tunneling is implicitly negotiated between the PMAG and LMA 
> during the 
> > PBU/PBA exchange, right?
> > 3. How that is negotiated between the PMAG and the NMAG? We 
> need the 
> > details..
> 
> I don't think there is any tunneling mode negotiation 
> mechanism in RFC5213. I may miss something, but if there is 
> such a mechanism, we'll need to incorporate it in the PFMIPv6 spec...
> 
> > And so on....
> > 
> >> Also, I don't see any specific reason to use a special tunneling 
> >> mechanism for the inter-MAG tunnel.
> > [Ahmad]
> > Good. This means you would use the same tunneling between 
> the PMAG and 
> > LMA over inter-MAG tunneling. In this case, we need the details for 
> > negotiating that tunneling mechanism between the PMAG and the NMAG.
> 
> The assumption here is that the LMA, PMAG and NMAG know the 
> tunneling mechanism for PMIPv6 tunneling (LMA-PMAG and 
> LMA-NMAG), and the same mechanism is used for the inter-MAG tunnel.
> 
> >>> 2. How this *protocol* dynamically negotiates the tunneling
> >> mechanism
> >>> type?
> >> If the tunneling mechanism between the LMA and MAG is 
> determined in 
> >> advance, the same mechanism is used for the inter-MAG 
> tunnel. So, it 
> >> is not on-demand and no negotiation is assumed. If the tunneling 
> >> mechanism between the LMA and MAG is determined on demand, 
> then that 
> >> is a different story...
> > 
> > [Ahmad]
> > Well, what do you mean? The tunneling between the PMAG and 
> the LMA is 
> > NOT on demand?
> > I believe IPv4 support for PMIPv6 and GRE key for PMIPv6 
> drafts will 
> > be helpful in answering this question.
> 
> The tunnel establishment is done on-demand, but the 
> encapsulation mechanism should be determined in advance. 
> Necessary parameters such as GRE keys for GRE encapsulation 
> are exchanged between the LMA and MAG, but whether GRE 
> encapsulation is used or IPv6-in-IPv4-UDP is used should be 
> configured, I think. In actual operations, such things are 
> usually configured by hand or something.
> 
> Anyway, what can be done by GRE Key Option should also be 
> available for
> PFMIPv6 (since the same option is used).
> 
> >>> 3. How that should work, for example if the tunneling mechanism 
> >>> between the PMAG-LMA is IPv6 in IPv4 UDP, how that
> >> tunneling will be
> >>> extended to go over the PMAG-NMAG interface and how it is
> >> supposed to work.
> >>
> >> In this case, both the PMAG and NMAG should be dual-stack 
> and the IP 
> >> addresses in the IPv4 outer header are those of the PMAG and NMAG. 
> >> IPv6 inner header should be kept intact.
> >>
> > 
> > Okay..... Then if the NMAG sends the first packet over the 
> NMAG-PMAG 
> > tunnel! Which encapsulation mechanism is going to use to 
> encapsulate 
> > that packet?
> 
> If the tunneling mechanism is IPv6-in-IPv4-UDP, the same 
> mechanism is used.
> 
> > Also, Do you agree that there is a specific reason for the traffic 
> > between the PMAG and the LMA to be IPv6-in-IPv4-UDP. Right? That 
> > reason may NOT be VALID between the PMAG and the NMAG. Right?
> > Then why to use the same tunneling here? Just out of curiosity!
> 
> The simplest reason is that this assumption is simplest. 
> Again, this is not mandatory and if both MAGs are configured 
> to use the same tunneling mechanism, that will be fine. 
> However, you may need extra care. For example, suppose you 
> decide to use IPv6-in-IPv6 tunneling for the inter-MAG tunnel 
> permanently. If the tunnel between the MAG and LMA used GRE 
> encapsulation with GRE keys, it would not work...
> 
> >>> Finally, the draft could have some restrictions and define the 
> >>> PMAG-NMAG tunneling/encapsulation mechanism and could
> >> define a set of
> >>> PMAG-LMA tunneling mechanism that are being
> >> supported/interwork over
> >>> the PMAG-NMAG tunneling/encapsulation.
> >> What kind of restrictions do you foresee? Do you also have any 
> >> specific mechanism for the inter-MAG tunnel in mind?
> > [Ahmad]
> > I guess, you need to answer many of the above comments 
> before we talk 
> > about this. A clear understanding of this tunneling is 
> needed and I do 
> > not see it documented in this draft.
> > 
> > BTW: Under section 4, this specification says:
> > 
> > "
> >    In order to further improve the performance during the 
> handover, the
> >    PFMIPv6 protocol in this document specifies a 
> bi-directional tunnel
> >    between the Previous MAG (PMAG) and the New MAG (NMAG) to tunnel
> >    packets meant for the mobile node.  
> > "
> > 
> > Which bi-directional tunnel? Where? What are the details?
> 
> Of course, that is the inter-MAG tunnel between the PMAG and 
> NMAG. The details are described in Section 4, which may not 
> be detailed enough from your viewpoint...
> 
> >>> One more note: I found defining and describing a protocol
> >> based on a
> >>> call flow, is not the most easy to follow. But, that could
> >> just be me.
> >>
> >> What do you think could improve the readability of the document?
> > [Ahmad]
> > Quite some of them... But I gave up after a while....
> 
> I asked a wrong question...:-)  But please don't give up.
> 
> Regards,
> --
> Hidetoshi
> 
> >> Regards,
> >> --
> >> Hidetoshi
> >>
> >>> Regards,
> >>> Ahmad
> >>>  
> >>>
> >>>> -----Original Message-----
> >>>> From: [e-mail]
> >>>> [mailto:[e-mail]] On Behalf Of Muhanna, Ahmad
> >>>> (RICH1:2H10)
> >>>> Sent: Thursday, September 17, 2009 9:23 PM
> >>>> To: Hidetoshi Yokota
> >>>> Cc: Mipshop; [e-mail]
> >>>> Subject: Re: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6
> >>>>
> >>>> Hi Hidetoshi,
> >>>> Please see inline.
> >>>>
> >>>> Regards,
> >>>> Ahmad
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Hidetoshi Yokota [mailto:[e-mail]]
> >>>>> Sent: Thursday, September 17, 2009 4:48 PM
> >>>>> To: Muhanna, Ahmad (RICH1:2H10)
> >>>>> Cc: Mipshop; [e-mail]; 
> Jari Arkko
> >>>>> Subject: Re: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6
> >>>>>
> >>>>> Hi Ahmad,
> >>>>>
> >>>>> Here is the proposed revision:
> >>>>>
> >>>>> In Section 4.2:
> >>>>>       [... message with the same sequence number.] The necessary
> >>>>>    information MUST be transferred in the HI/HAck messages to
> >>>>>    distinguish MN's packets for forwarding in advance or at
> >>>> this time.
> >>>>>    Such information includes the MN ID and/or GRE key(s).  
> >>>> Typically,
> >>>>>    the NMAG selects the GRE key for the downlink packets
> >>>> and the PMAG
> >>>>>    selects that for the uplink packets.  Each key is 
> conveyed in 
> >>>>> either
> >>>>>    the HI or HAck message separately when GRE Key Option
> >> [GREKEY] is
> >>>>>    used. [For the downlink ...]
> >>>>>
> >>>> [Ahmad]
> >>>> In addition to what Vijay mentioned with respect to
> >> Typically (which
> >>>> should be removed), I believe the draft needs to be clear on the 
> >>>> mechanism that is used for exchanging the GRE keys. When you say 
> >>>> "...when the GRE Key Option [GREKEY] is used." What 
> happens if the 
> >>>> GRE key option is NOT used. Is there another mechanism?
> >>>>
> >>>> Since the GRE keys are necessary to establish the lateral
> >> tunnel and
> >>>> identify the MN traffic, the draft must specify a default
> >> mechanism.
> >>>> Other mechanisms can be used or specified some where else
> >> if needed,
> >>>> but we need a default one here. Right?
> >>>>
> >>>> Also, you replaced the **HoA of the MN** with the **MN ID**. 
> >>>> What is the reason for this change?
> >>>> And how this should work NOW while you have ".. and/or GRE Keys"?
> >>>>
> >>>>> If the above description is acceptable, I will submit 
> the revised 
> >>>>> version by the end of the week.
> >>>>>
> >>>>> Regards,
> >>>>> --
> >>>>> Hidetoshi
> >>>>>
> >>>>> Ahmad Muhanna wrote:
> >>>>>> Hi Hidetoshi,
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Hidetoshi Yokota [mailto:[e-mail]]
> >>>>>>> Sent: Monday, September 14, 2009 7:37 AM
> >>>>>>> To: Muhanna, Ahmad (RICH1:2H10)
> >>>>>>> Cc: Mipshop; [e-mail];
> >>>> Jari Arkko
> >>>>>>> Subject: Re: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6
> >>>>>>>
> >>>>>>> Hi Ahmad,
> >>>>>>>
> >>>>>>> Thanks for your comment. I'm glad to hear an opinion from
> >>>>> a GRE key
> >>>>>>> expert. Please see inline:
> >>>>>>>
> >>>>>>> Ahmad Muhanna wrote:
> >>>>>>>> Hi Hidetoshi,
> >>>>>>>>
> >>>>>>>> I just have one quick comment and question.
> >>>>>>>>
> >>>>>>>> Reading the draft, it seems to me that the GRE keys are
> >>>>>>> somehow sent
> >>>>>>>> from the NAR to PAR in the HI (section 4.2). Is that the
> >>>>> case? This
> >>>>>>>> means both the DL and UP GRE keys for the bilateral
> >>>>> tunnels between
> >>>>>>>> the two AR(s). Is my understanding correct? It also
> >>>>>>> mentions that the
> >>>>>>>> format
> >>>>>>> In terms of the GRE keys for the bilateral tunnel, 
> the working 
> >>>>>>> assumption is that the DL key is selected by the NAR and
> >>>>> the UL key
> >>>>>>> is selected by the PAR. Depending on the fast handover
> >>>> mode, those
> >>>>>>> keys are transferred to the other MAG via either the 
> HI or Hack.
> >>>>>>>
> >>>>>>>> of these keys are based on the GRE keys for PMIPv6
> >>>> draft (section
> >>>>>>>> 6.2.6).
> >>>>>>> Correct.
> >>>>>>>
> >>>>>>>> It seems to me that there should be more text to define
> >>>>> which keys
> >>>>>>>> exchange in the HI and which in the HaCK
> >>>>>>> If the above assumption works, I would like to add more
> >>>> text along
> >>>>>>> that line.
> >>>>>> [Ahmad]
> >>>>>> That is great. Please add some clarification text to
> >>>>> clearly indicate
> >>>>>> that only one key in the HI and the other in the HACK.
> >>>>>> Since some specification in 3GPP2 depends on this draft, I
> >>>>> appreciate
> >>>>>> if you can publish an updated version before the end of
> >> the week. 
> >>>>>> Thanks in advance!
> >>>>>>
> >>>>>>>> If both keys are exchanged in the same HI, How these 
> keys are 
> >>>>>>>> identified at the pAR?
> >>>>>>>> In GRE keys for PMIPv6 draft, downlink GRE key is included
> >>>>>>> in the PBU
> >>>>>>>> and the uplink GRE key in included in the PBA. They never
> >>>>>>> exist in the
> >>>>>>>> same message and that way there is no confusing.
> >>>>>>> So far, each key is conveyed by either the HI or HAck. 
> >>>>>>> However, I haven't explored all of the possibilities. 
> >> If you can
> >>>>>>> think of any case that two keys must be conveyed in one
> >> message,
> >>>>>>> please let me know.
> >>>>>> [Ahmad]
> >>>>>> I do not see any reason for this case (one key per
> >>>> message) not to
> >>>>>> work for all implementation.
> >>>>>>  
> >>>>>>>> In addition, DL and UP GRE keys are generated by NAR and
> >>>>>>> sent inside
> >>>>>>>> the HI, my question: Is there any specific reason for
> >>>> the NAR to
> >>>>>>>> specify both GRE keys for the bilateral tunnels?
> >>>>>>> It would be more problematic that the NAR determines the
> >>>> both keys
> >>>>>>> and I would rather like to avoid it.
> >>>>>>>
> >>>>>>>> Sorry for this comment to be so late but hope that you have
> >>>>>>> the chance
> >>>>>>>> to take a look at it.
> >>>>>>> That's ok. The draft is under the review process. Your
> >>>> comment is
> >>>>>>> highly appreciated.
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> --
> >>>>>>> Hidetoshi
> >>>>>>>
> >>>>>>>
> >>>>>>>> Thanks!
> >>>>>>>>
> >>>>>>>> Regards,
> >>>>>>>> Ahmad
> >>>>>>>>  
> >>>>>>>>
> >>>>>>>>> -----Original Message-----
> >>>>>>>>> From: [e-mail] 
> >>>>>>>>> [mailto:[e-mail]] On Behalf Of
> >> Hidetoshi Yokota
> >>>>>>>>> Sent: Wednesday, September 02, 2009 11:12 PM
> >>>>>>>>> To: Jari Arkko
> >>>>>>>>> Cc: Mipshop; [e-mail]
> >>>>>>>>> Subject: Re: [Mipshop] AD review of 
> draft-ietf-mipshop-pfmipv6
> >>>>>>>>>
> >>>>>>>>> Hi Jari,
> >>>>>>>>>
> >>>>>>>>> Thanks for your patience. The attached revised document is
> >>>>>>> supposed to
> >>>>>>>>> reflect the rest of your comments. Please also see inline,
> >>>>>>> where the
> >>>>>>>>> revised part is explained item by item. If there is no
> >>>>> outstanding
> >>>>>>>>> issue there, we will upload it shortly.
> >>>>>>>>>
> >>>>>>>>> [Apologize if you received it twice. Since the size just
> >>>>>>> exceeded the
> >>>>>>>>> limit of this ML, this mail is reposted without the
> >>>> attachment.]
> >>>>>>>>> Hidetoshi Yokota wrote:
> >>>>>>>>>> Hi Jari,
> >>>>>>>>>>
> >>>>>>>>>> Appreciate your detailed review. The editorial corrections
> >>>>>>>>> are mostly
> >>>>>>>>>> done and the revised version is attached to this mail. 
> >>>>>>> Regarding the
> >>>>>>>>>> technical comments, only the policies for the correction
> >>>>>>>>> are listed for
> >>>>>>>>>> now. The complete correction will be posted as soon as
> >>>>>>>>> possible. Please
> >>>>>>>>>> see inline for the responses to your questions and 
> comments:
> >>>>>>>>>>
> >>>>>>>>>> Jari Arkko wrote:
> >>>>>>>>>>> I have reviewed this document. It was generally in good
> >>>>>>>>> shape and easy
> >>>>>>>>>>> to read. I did find a number of issues though. Please
> >>>>>>>>> discuss them with
> >>>>>>>>>>> me on this thread and/or revise the draft accordingly.
> >>>>>>>>>>>
> >>>>>>>>>>> Technical:
> >>>>>>>>>>>
> >>>>>>>>>>> I do not understand the IP host aspects of the
> >>>>> handover. For an
> >>>>>>>>>>> unmodified host, what kind of interfaces exist on the
> >>>>> host, what
> >>>>>>>>>>> addresses they have, and at what time are interfaces
> >>>>>>>>> removed or added? 
> >>>>>>>>>>> Is this exactly the same as in RFC 5213, or does PFMIPv6
> >>>>>>>>> introduce some
> >>>>>>>>>>> change here?
> >>>>>>>>>> The basic principle would be that this specification does
> >>>>>>>>> not require
> >>>>>>>>>> any additional IP-level function to the MN running in the
> >>>>>>>>> PMIPv6 domain.
> >>>>>>>>>> This MN should therefore be the same as defined in RFC5213.
> >>>>>>>>>>
> >>>>>>>>>> A typical network interface would be one with the
> >>>>>>> cellular network,
> >>>>>>>>>> where the network basically controls the movement of the
> >>>>>>>>> MN. Different
> >>>>>>>>>> types of interfaces could be involved such as different
> >>>>>>>>> generations (3G
> >>>>>>>>>> and 3.9G) or different radio access systems. Any type of
> >>>>>>> IP address
> >>>>>>>>>> could be assigned (IPv4/v6 or global/private), but the
> >>>>>>>>> assigned address
> >>>>>>>>>> must be preserved before and after the handover. PFMIPv6
> >>>>>>>>> should be able
> >>>>>>>>>> to handle the single radio situation, where only one
> >>>>>>>>> interface is active
> >>>>>>>>>> at any given time. This is a tougher situation in terms of
> >>>>>>>>> packet loss
> >>>>>>>>>> and delay.
> >>>>>>>>>>
> >>>>>>>>>>> I would like to see a new section on manageability
> >>>>>>>>> considerations. For
> >>>>>>>>>>> instance, Section 5 talks about some 
> configuration issues. 
> >>>>>>>>> These should
> >>>>>>>>>>> be mentioned, and there should be a description of what
> >>>>>>>>> the operator
> >>>>>>>>>>> needs to configure in order to set up a PFMIPv6 network.
> >>>>>>>>>> We will add a new section for manageability considerations
> >>>>>>>>> to clarify
> >>>>>>>>>> the above and to reflect your suggestion.
> >>>>>>>>> A new subsection is added in Section 5 describing the
> >>>>>>> above aspects:
> >>>>>>>>> -------------------
> >>>>>>>>> 5.  PMIPv6-related Fast Handover Issues
> >>>>>>>>>
> >>>>>>>>> 5.1.  Manageability Considerations
> >>>>>>>>>
> >>>>>>>>>    This specification does not require any 
> additional IP-level
> >>>>>>>>>    functionality on the LMA and the MN running in 
> the PMIPv6 
> >>>>>>>>> domain.  A
> >>>>>>>>>    typical network interface that the MN could be
> >>>>> assumed to have
> >>>>>>>>> is one
> >>>>>>>>>    with the cellular network, where the network 
> controls the 
> >>>>>>>>> movement of
> >>>>>>>>>    the MN.  Different types of interfaces could be
> >>>>> involved such as
> >>>>>>>>>    different generations (3G and 3.9G) or different
> >>>> radio access
> >>>>>>>>>    systems.  This specification supports a MN with the
> >>>>> single radio
> >>>>>>>>>    mode, where only one interface is active at any given
> >>>>> time.  The
> >>>>>>>>>    assigned IP address is preserved whether the physical
> >>>>> interface
> >>>>>>>>>    changes or not and the MN can identify which
> >>>>> interface should be
> >>>>>>>>> used
> >>>>>>>>>    if there are multiple ones.
> >>>>>>>>> --------------------
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>> If the new router's interface is configured to 
> respond to 
> >>>>>>>>>>>> queries sent to link-layer addresses than its
> >>>>>>>>> own (e.g.,
> >>>>>>>>>>>> set to promiscuous mode), then it can respond to the
> >>>>> NUD probe,
> >>>>>>>>>>>> providing its link-layer address in the 
> solicited Neighbor 
> >>>>>>>>>>>> Advertisement.
> >>>>>>>>>>> Is this according to RFC 5213? I seem to recall that RFC
> >>>>>>>>> 5213 operated
> >>>>>>>>>>> on the same link layer addresses.
> >>>>>>>>>> I think your observation is correct... I'll check with the
> >>>>>>>>> other authors
> >>>>>>>>>> to see if it is ok to rewrite it.
> >>>>>>>>> The new text doesn't mention the promiscuous mode and
> >>>>>>> emphasizes the
> >>>>>>>>> common link-layer address among all MAGs in the 
> PMIPv6 domain:
> >>>>>>>>>
> >>>>>>>>> ---------------
> >>>>>>>>> 5.2.  Expedited Packet Transmission
> >>>>>>>>>
> >>>>>>>>>    [...]
> >>>>>>>>>
> >>>>>>>>>    The protocol specified in this document is applicable
> >>>>>>> regardless of
> >>>>>>>>>    whether link-layer addresses are used between a MN and
> >>>>>>> its access
> >>>>>>>>>    router.  A MN should be able to continue sending
> >>>>> packets on the
> >>>>>>>>>    uplink even when it changes link.  When link-layer
> >>>>> addresses are
> >>>>>>>>>    used, the MN performs Neighbor Unreachability
> >>>> Detection (NUD)
> >>>>>>>>>    [RFC4861], after attaching to a new link, probing the 
> >>>>>>>>> reachability of
> >>>>>>>>>    its default router.  The new router should respond
> >>>> to the NUD
> >>>>>>>>> probe,
> >>>>>>>>>    providing its link-layer address in the 
> solicited Neighbor
> >>>>>>>>>    Advertisement, which is common in the PMIPv6 domain.  
> >>>>>>>>> Implementations
> >>>>>>>>>    should allow the MN to continue to send uplink packets
> >>>>>>> while it is
> >>>>>>>>>    performing NUD.
> >>>>>>>>> ----------------
> >>>>>>>>>
> >>>>>>>>>>>> At least one mobility option MUST uniquely identify
> >>>>> the target
> >>>>>>>>>>>> MN (e.g., the Mobile Node
> >>>>>>> Identifier
> >>>>>>>>>>>> Option defined in RFC4283
> >>>>>>>>> <http://tools.ietf.org/html/rfc4283>) and
> >>>>>>>>>>>> the transferred context MUST be for one MN per message.
> >>>>>>>>>>>>   
> >>>>>>>>>>> I would like the required options to be specified in more
> >>>>>>>>> detail. Which
> >>>>>>>>>>> identity options are sufficient to satisfy the MUST?
> >>>>>>>>>> The required option should be the MN Identifier in the
> >>>>> Mobile Node
> >>>>>>>>>> Identifier Option.
> >>>>>>>>> The above description is added in Section 6.1.1:
> >>>>>>>>>
> >>>>>>>>> ---------
> >>>>>>>>>    Requested option
> >>>>>>>>>              In order to uniquely identify the target
> >>>> MN, the MN
> >>>>>>>>>              Identifier MUST be contained in the 
> Mobile Node 
> >>>>>>>>> Identifier
> >>>>>>>>>              Option.
> >>>>>>>>> ---------
> >>>>>>>>>
> >>>>>>>>>>>> If a default set of context information is defined
> >>>> and always
> >>>>>>>>>>>> sufficient, this option is not mandatory.  This
> >>>>>>>>> option is more
> >>>>>>>>>>>> useful to retrieve additional or dynamically
> >>>> selected context
> >>>>>>>>>>>> information.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Context Request Option is typically used for the
> >>>>> reactive (NAR-
> >>>>>>>>>>>> initiated) fast handover mode to retrieve the context
> >>>>>>> information
> >>>>>>>>>>>> from the PAR.  When this option is included in the HI
> >>>>>>> message, all
> >>>>>>>>>>>> the requested context information SHOULD be included
> >>>>> in the HAck
> >>>>>>>>>>>> message in the corresponding mobility option(s) (e.g.,
> >>>>>>>>> HNP, LMAA or
> >>>>>>>>>>>> MN-IID mobility options).
> >>>>>>>>>>>>   
> >>>>>>>>>>> Please specify what the default set of context
> >>>>>>> information is, by
> >>>>>>>>>>> listing the required options when the CRO is not present.
> >>>>>>>>>> The default context information to request is the Home
> >>>>>>>>> Network Prefix
> >>>>>>>>>> Option. If the Mobile Node link-layer is available and
> >>>>>>>>> used, the Mobile
> >>>>>>>>>> Node Link-layer Identifier Option MUST also be requested. 
> >>>>>>>>> With these two
> >>>>>>>>>> options and the MN identifier, the NMAG can
> >> construct the PBU.
> >>>>>>>>> The above description is added in Section 6.2.1:
> >>>>>>>>>
> >>>>>>>>> ----------
> >>>>>>>>>    The default context information to request is the
> >>>>> Home Network
> >>>>>>>>> Prefix
> >>>>>>>>>    Option.  If the Mobile Node link-layer is available and
> >>>>>>> used, the
> >>>>>>>>>    Mobile Node Link-layer Identifier Option MUST also be
> >>>>> requested.
> >>>>>>>>> ----------
> >>>>>>>>>
> >>>>>>>>>>> Editorial:
> >>>>>>>>>>>
> >>>>>>>>>>>>    HO-Initiate:
> >>>>>>>>>>>>         A generic signaling message, sent from the P-AN
> >>>>>>>>> to the PMAG that
> >>>>>>>>>>>>         indicates a MN handover.  While this signaling is
> >>>>>>>>> dependent on
> >>>>>>>>>>>>         the access technology, it is assumed that
> >>>>>>>>> HO-Initiate can carry
> >>>>>>>>>>>>         the information to identify the MN and to
> >>>>>>> assist the PMAG
> >>>>>>>>>>>>         resolve the NMAG and the new access point or the
> >>>>>>>>> base station to
> >>>>>>>>>>>>         which the MN is moving to.  The details of this
> >>>>>>>>> message are
> >>>>>>>>>>>>         outside the scope of this document.
> >>>>>>>>>>>>
> >>>>>>>>>>>> 4. Proxy-based FMIPv6 Protocol Overview
> >>>>>>>>>>> Section 4 would probably benefit from an additional
> >>>>>>>>> paragraph at the
> >>>>>>>>>>> beginning to explain what assumptions there exist about
> >>>>>>>>> lower layer
> >>>>>>>>>>> functionality.
> >>>>>>>>>> Yes, the predictive fast handover relies on the 
> lower layer 
> >>>>>>>>>> functionality to trigger to send the HI. A new paragraph
> >>>>>>>>> will be added
> >>>>>>>>>> to clarify it.
> >>>>>>>>> -------------
> >>>>>>>>> 4.  Proxy-based FMIPv6 Protocol Overview
> >>>>>>>>>
> >>>>>>>>>    If the MAGs can be informed of the detachment and/or
> >>>>>>> attachment of
> >>>>>>>>>    the MN in a timely manner via e.g. the lower layer
> >>>>> signaling, it
> >>>>>>>>> will
> >>>>>>>>>    become possible to optimize the handover procedure,
> >>>>>>> which involves
> >>>>>>>>>    establishing a connection on the new link and
> >>>>> signaling between
> >>>>>>>>>    mobility agents, compared to the baseline specification
> >>>>>>> of PMIPv6.
> >>>>>>>>>   [...]
> >>>>>>>>> -------------
> >>>>>>>>>
> >>>>>>>>> All the other corrections pointed out below have also been 
> >>>>>>>>> reflected in the revised document.
> >>>>>>>>>
> >>>>>>>>> Regards,
> >>>>>>>>> --
> >>>>>>>>> Hidetoshi
> >>>>>>>>>
> >>>>>>>>>>>> A new flag 'P' is defined for the HI and HAck 
> messages to 
> >>>>>>>>>>>> distinguish from those in [RFC5268bis
> >>>>>>>>>>>>
> >>>>>>>>> 
> <http://tools.ietf.org/html/draft-ietf-mipshop-pfmipv6-08#ref-
> >>>>>>>>> RFC5268bis>]
> >>>>>>>>>>>> and thus MUST
> >>>>>>>>>>>> be set in the entire document.
> >>>>>>>>>>>>   
> >>>>>>>>>>> This would be more readable as " ... those in
> >>>>>>>>> [RFC5268bis]. This flag
> >>>>>>>>>>> MUST be ..."
> >>>>>>>>>> Revised.
> >>>>>>>>>>
> >>>>>>>>>>>>    and the NAR creates a proxy NCE to receive those
> >>>>>>>>> packets for the NCoA
> >>>>>>>>>>> The term NCE has not been introduced at this stage yet.
> >>>>>>>>>> Spelled out as "Neighbor Cache Entry".
> >>>>>>>>>>
> >>>>>>>>>>>>    address that is used by the MN is MN-HoA.  Hence the
> >>>>>>>>> PAR forwards
> >>>>>>>>>>> The term MN-HOA has not been introduced before.
> >>>>>>>>>> Added the unabbreviated form "Mobile Node's Home Address" 
> >>>>>>> before it.
> >>>>>>>>>>>>         The access network to which the MN is attached
> >>>>>>>>> after handover.
> >>>>>>>>>>> New term MN, not introduced before.
> >>>>>>>>>>>
> >>>>>>>>>> Added "Mobile Node" before it.
> >>>>>>>>>>
> >>>>>>>>>>>> specifies forwarding when the MN uses HoA as its
> >>>>> on-link address
> >>>>>>>>>>> New term HoA...
> >>>>>>>>>> Changed to "Home Address".
> >>>>>>>>>>
> >>>>>>>>>>>>    as MN's NAI, Home Network Prefix (HNP), IPv4 Home
> >>>>>>> Address, are
> >>>>>>>>>>> New term NAI...
> >>>>>>>>>> Added "Network Access Identifier" before it.
> >>>>>>>>>>
> >>>>>>>>>>>>         flag set and include the MN ID, the MN-HNP, the
> >>>>>>>>> MN-IID and the
> >>>>>>>>>>> New terms MN-HNP and MN-IID (or at least they do not
> >>>>>>>>> appear in their
> >>>>>>>>>>> MN-XXX form before this point).
> >>>>>>>>>> Modified "MN-HNP" to "HNP" for consistency.
> >>>>>>>>>>
> >>>>>>>>>>>>         Inner destination address: HNP or IPv4-MN-HoA
> >>>>>>>>>>> IPv4-MN-HoA not defined earlier...
> >>>>>>>>>> Added "Mobile Node's IPv4 Home" before it.
> >>>>>>>>>>
> >>>>>>>>>>>>    between the PCoA and NCoA to forward packets for the
> >>>>>>>>> MN to the NAR,
> >>>>>>>>>>> New terms PCoA and NCoA... there's probably more undefined
> >>>>>>>>> terms in the
> >>>>>>>>>>> document, please check!
> >>>>>>>>>> Added "Previous Care-of Address" and "New Care-of 
> Address". 
> >>>>>>>>> Will read
> >>>>>>>>>> through it to see if there is any other undefined acronym.
> >>>>>>>>>>
> >>>>>>>>>>>>    In (i),
> >>>>>>>>>>> In Step (i),
> >>>>>>>>>> Revised including other parts.
> >>>>>>>>>>
> >>>>>>>>>>>>           |(MN ID, Old AP ID) |     (MN ID, Old 
> AP ID)    
> >>>>>>>>>  |        |
> >>>>>>>>>>> Old AP ID? AN ID? AR ID?
> >>>>>>>>>> AP ID stands for "Access Point Identifier", which is
> >>>>>>>>> defined in RFC5568.
> >>>>>>>>>> Added the unabbreviated form and citation.
> >>>>>>>>>>
> >>>>>>>>>> The rest of the part will be revised soon.
> >>>>>>>>>>
> >>>>>>>>>> Regards,
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>> 
> --------------------------------------------------------------
> >>>>>>>>> ----------
> >>>>>>>>>> _______________________________________________
> >>>>>>>>>> Mipshop mailing list
> >>>>>>>>>> [e-mail]
> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/mipshop
> >>>>>>>>> _______________________________________________
> >>>>>>>>> Mipshop mailing list
> >>>>>>>>> [e-mail]
> >>>>>>>>> https://www.ietf.org/mailman/listinfo/mipshop
> >>>>>>>>>
> >>>>>>
> >>>>> --
> >>>>> Hidetoshi Yokota
> >>>>>
> >>>>> Mobile Network Lab
> >>>>> KDDI R&D Laboratories, Inc.
> >>>>> e-mail:[e-mail]
> >>>>>
> >>>>>
> >>>> _______________________________________________
> >>>> Mipshop mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/mipshop
> >>>>
> >>>
> >>>
> >>
> > 
> > 
> > 
> 
>