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

[Frank Xia <[e-mail]>]

Hi  Ahmad, Hidetoshi, and Rajeev

I have followed the discussion, and agreed
with Rajeev's proposal.

BR
Frank

----- Original Message ----- 
From: "Hidetoshi Yokota" <[e-mail]>
To: "Koodli, Rajeev" <[e-mail]>
Cc: "Mipshop" <[e-mail]>; 
<[e-mail]>
Sent: Thursday, September 24, 2009 3:28 AM
Subject: Re: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6


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