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

From: Hidetoshi Yokota <[email-masked]>
Date: Thu, 03 Sep 2009 13:12:18 +0900

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

---

From: Jari Arkko <[email-masked]>
Date: Thu, 03 Sep 2009 12:44:14 +0300

The new version looks good to me, thanks. Please submit it to the 
directories.

Jari

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 8 Sep 2009 12:34:56 -0500

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
of these keys are based on the GRE keys for PMIPv6 draft (section
6.2.6).

It seems to me that there should be more text to define which keys
exchange in the HI and which in the HaCK

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.

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?

Sorry for this comment to be so late but hope that you have the chance
to take a look at it.

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,
> 
> >>> Option defined in RFC4283 
> <http://tools.ietf.org/html/rfc4283>) and

---

From: Hidetoshi Yokota <[email-masked]>
Date: Mon, 14 Sep 2009 21:37:10 +0900

Hi Ahmad,

Thanks for your comment. I'm glad to hear an opinion from a GRE key
expert. Please see inline:

> 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

Correct.

> exchange in the HI and which in the HaCK

If the above assumption works, I would like to add more text along that
line.

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

> 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

That's ok. The draft is under the review process. Your comment is highly
appreciated.

Regards,
-- 
Hidetoshi

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 14 Sep 2009 08:12:56 -0500

Hi Hidetoshi,

> 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
> Thanks for your comment. I'm glad to hear an opinion from a 
> GRE key expert. Please see inline:
> 
> Ahmad Muhanna wrote:
> > Hi Hidetoshi,
> > 
> > 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.
> 
> 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?
> 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.
> 
> That's ok. The draft is under the review process. Your 
> comment is highly appreciated.
> 
> Regards,
> --
> Hidetoshi
> 
> 
> > Thanks!
> > 
> > Regards,
> > Ahmad
> >  
> >

---

From: Hidetoshi Yokota <[email-masked]>
Date: Fri, 18 Sep 2009 06:47:51 +0900

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

If the above description is acceptable, I will submit the revised
version by the end of the week.

Regards,
-- 
Hidetoshi

-- 
Hidetoshi Yokota

Mobile Network Lab
KDDI R&D Laboratories, Inc.
e-mail:[email-masked]

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 17 Sep 2009 18:01:30 -0400

Can we remove the word "Typically"? It is always the nMAG that selects
the downlink GRE key and pMAG that selects the uplink GRE key. Right?

Vijay

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Hidetoshi Yokota
> Sent: Thursday, September 17, 2009 2:48 PM
> To: Ahmad Muhanna
> > 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

---

From: Hidetoshi Yokota <[email-masked]>
Date: Fri, 18 Sep 2009 10:53:53 +0900

Hi Vijay,

> the downlink GRE key and pMAG that selects the uplink GRE key. Right?

Yes, as far as the flows in the current draft are concerned. "Typically"
will be removed from the revised text. Hope no one will freak out...

Thanks for your comment,
-- 
Hidetoshi

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 17 Sep 2009 21:22:32 -0500

Hi Hidetoshi,
Please see inline.

Regards,
Ahmad

> Sent: Thursday, September 17, 2009 4:48 PM
[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,
> > 
> >> 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.
> >>
> >> If the above assumption works, I would like to add more text along 
> >> that line.
> > [Ahmad]
> > if you can publish an updated version before the end of the week. 
> > Thanks in advance!
> > 
> >> 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.
> >  
> >> It would be more problematic that the NAR determines the both keys 
> >> and I would rather like to avoid it.
> >>
> >> That's ok. The draft is under the review process. Your comment is 
> >> highly appreciated.
> >>
> >> Regards,
> >> --
> >> Hidetoshi
> >>
> >>
> >>> Thanks!
> >>>
> >>> Regards,
> >>> Ahmad
> >>>  
> >>>
> >>>> revised part is explained item by item. If there is no 
> outstanding 
> >>>> issue there, we will upload it shortly.
> >>>>
> >>>>    typical network interface that the MN could be 
> assumed to have 
> >>>> is one
> >>>>    changes or not and the MN can identify which 
> interface should be 
> >>>> used
> >>>>>>> If the new router's interface is configured to respond to 
> >>>>>>> queries sent to link-layer addresses than its
> >>>> own (e.g.,
> >>>>>>> At least one mobility option MUST uniquely identify 
> the target 
> >>>>>>> MN (e.g., the Mobile Node
> >> Identifier
> >>>>>>> the transferred context MUST be for one MN per message.
> >>>>>>>   
> >>>>>>> If a default set of context information is defined and always 
> >>>>>>> sufficient, this option is not mandatory.  This
> >>>> option is more
> >>>>    The default context information to request is the 
> Home Network 
> >>>> Prefix
> >>>>    the MN in a timely manner via e.g. the lower layer 
> signaling, it 
> >>>> will
> >>>> 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
> >>>>>>>

---

From: Hidetoshi Yokota <[email-masked]>
Date: Fri, 18 Sep 2009 23:04:09 +0900

Hi Ahmad,

> key option is NOT used. Is there another mechanism?

As an alternative way, Vendor-Specific Mobility Option could be used. As
you pointed out, the restriction introduced by GRE Key Option is that it
can convey only one key in one message. If multiple keys need to be
conveyed at one time for some reason, this alternative solution could be
used. Should that also be in the document?

> Also, you replaced the **HoA of the MN** with the **MN ID**. What is the

Since the MN ID is the required option, I thought I fixed it there, but
maybe the HNP will also be needed.

> And how this should work NOW while you have ".. and/or GRE Keys"?

If the HNP (or IPv4-MN-HoA) is transferred, would that be sufficient?

Regards,
-- 
Hidetoshi

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Sat, 19 Sep 2009 03:32:58 -0500

Hi Hidetoshi,
Please see inline.

Regards,
Ahmad

> As an alternative way, Vendor-Specific Mobility Option could 
> be used. As you pointed out, the restriction introduced by 
> GRE Key Option is that it can convey only one key in one 
> message. If multiple keys need to be conveyed at one time for 
> some reason, this alternative solution could be used. Should 
> that also be in the document?

[Ahmad]
Honestly, I do not care. However, there MUST be a default mechanism that
MUST be clearly described in this draft and MUST be supported for
Interoperability. That choice being GRE Key option or VS MO, it does not
matter as long as the default mechanism is clearlu defined. Is that a
reasonable request?

> > 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?
> 
> Since the MN ID is the required option, I thought I fixed it 
> there, but maybe the HNP will also be needed.

[Ahmad]
Well, the question is why and/or GRE keys?
If the GRE Keys are NOT included what is the tunneling mechanism that is
being used. This is sort of vague and NOT clearly defined. I find it
hard to follow what the draft is proposing and the details of the
protocol.

> If the HNP (or IPv4-MN-HoA) is transferred, would that be sufficient?
[Ahmad]
It depends on the encapsulation mechanism that is being used. My
understanding is the following: If it is optional to exchange GRE keys
between the PMAG and NMAG, then it means that there is another type of
encapsulation/tunneling mechanism. Right? Could be GRE without keys,
etc..
What is it? How it works to map all sessions, etc. These details are
missing in the draft, but it could be only me.

Regards,
Ahmad

> >>>>>>    its default router.  The new router should respond 
> to the NUD 
> >>>>>> probe,

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Sat, 19 Sep 2009 03:24:39 -0500

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

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? 
2. Is the tunneling mode (between the PMAG and the LMA)
negotiated/communicated between the PMAG-MAGs?
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?
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?
5. Do these tunneling mechanisms include plain GRE Encapsulation with
GRE keys or only GRE with TLV-header UDP tunneling?
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.
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?

6. Is the assumption here that the NMAG and the PMAG have the same
transport with the LMA?
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. 

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

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?
2. How this *protocol* dynamically negotiates the tunneling mechanism
type?
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.

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.

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.

Regards,
Ahmad

> [mailto:[email-masked]] On Behalf Of Muhanna, Ahmad 
> (RICH1:2H10)
> Sent: Thursday, September 17, 2009 9:23 PM
> To: Hidetoshi Yokota
> 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?

---

From: Hidetoshi Yokota <[email-masked]>
Date: Tue, 22 Sep 2009 08:51:47 +0900

Hi Ahmad,

Please see inline:

> matter as long as the default mechanism is clearlu defined. Is that a

I just want this document to cover as many use cases as possible. A
default mechanism should be GRE Key Option. Thinking it over and in the
case of Vendor-specific Mobility Option, it would be necessary to define
the whole message format internally, which may be beyond the scope of
this document. Thus, it would be better to describe only the use of GRE
Key Option in the document.

Regarding the rest of your questions below, if GRE keys are not used
between the LMA and MAG (on the PMIPv6 tunnel), the flow should be
identifiable by the HNP, correct? In this case, GRE keys are not
mandatory on the inter-MAG tunnel. At the same time, this spec does not
mention any other encapsulation mechanism.

Based on the above observations, the following paragraph is proposed:

-----
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 HNP (or IPv4-MN-HoA) and/or GRE keys. Regarding
the GRE key selection, 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 with GRE Key Option
[GREKEY].
-----

How about it?

Regards,
-- 
Hidetoshi

>> tunnel and

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 21 Sep 2009 19:50:51 -0500

Hi Hidetoshi,
Thanks; Please see inline.

Regards,
Ahmad

> >> As an alternative way, Vendor-Specific Mobility Option 
> could be used. 
> >> As you pointed out, the restriction introduced by GRE Key 
> Option is 
> >> that it can convey only one key in one message. If 
> multiple keys need 
> >> to be conveyed at one time for some reason, this 
> alternative solution 
> >> could be used. Should that also be in the document?
> > 
> > [Ahmad]
> > Honestly, I do not care. However, there MUST be a default mechanism 
> > that MUST be clearly described in this draft and MUST be 
> supported for 
> > Interoperability. That choice being GRE Key option or VS 
> MO, it does 
> > not matter as long as the default mechanism is clearlu defined. Is 
> > that a reasonable request?
> 
> I just want this document to cover as many use cases as 
> possible. A default mechanism should be GRE Key Option. 
> Thinking it over and in the case of Vendor-specific Mobility 
> Option, it would be necessary to define the whole message 
> format internally, which may be beyond the scope of this 
> document. Thus, it would be better to describe only the use 
> of GRE Key Option in the document.
[Ahmad]
Good. Hope we get some text as clear as this objective.
> 
> Regarding the rest of your questions below, if GRE keys are 
> not used between the LMA and MAG (on the PMIPv6 tunnel), the 
> flow should be identifiable by the HNP, correct? 
[Ahmad]
Sure. For the sake of this specific detail, that is fine.

> In this 
> case, GRE keys are not mandatory on the inter-MAG tunnel. At 
> the same time, this spec does not mention any other 
> encapsulation mechanism.
[Ahmad]
Hmmm... I am not sure how to interpret this because, there is some text
under 4.1. which talks about all kind of tunneling that is currently
being supported between the MAG and the LMA, but for the sake of this
specific issue, let us continue.

> 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 HNP 
> (or IPv4-MN-HoA) and/or GRE keys. Regarding the GRE key 
> selection, 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 with GRE Key Option [GREKEY].
> -----
> 
> How about it?

What about tweaking this a little for clarity:

"
   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 HNP (or IPv4-MN-HoA) and/or GRE key(s).
In
   the case of GRE tunneling with GRE keys being used, the NMAG selects
the GRE
   key for the downlink packets and the PMAG selects the GRE key for the
uplink
   packets. These GRE keys are exchanged using the GRE Key option as
described
   in [GREKEY] where the DL GRE Key is communicated in the HI message
while
   the UL GRE key is sent in the HAck message.
" 

Thanks again.

Regards,
Ahmad

---

From: Hidetoshi Yokota <[email-masked]>
Date: Tue, 22 Sep 2009 22:20:25 +0900

Hi Ahmad,

Thanks for your detailed thoughts. Below, we try to answer your
questions as best we can.

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

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

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

> mean the tunneling between the PMAG-NMAG is also going to use the same

Yes, that is the basic idea.

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

> GRE keys or only GRE with TLV-header UDP tunneling?

<draft-ietf-netlmm-grekey-option> supports both modes, so PFMIPv6 should
also support them.

> GRE Keys for PMAG-NMAG or one set is used. It is not clear in the

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.

> PMAG-NMAG? If NOT, what encapsulation mechanism is being used and how is

The working assumption is "yes".

> 6. Is the assumption here that the NMAG and the PMAG have the same

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

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

> In addition,

The nature of the specification and its performance is based on RFC5568.
Whether the establishment of the tunneling mechanism is dynamic or
static is operation-specific.

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

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

> PMAG-NMAG tunneling? Somewhat similar to 2 above.

The basic mechanism is the same as in RFC5568. If a GRE tunnel further
differentiates the session, the GRE key will be used.

> Multiple Tunneling and encapsulation mechanisms between the PMAG-NMAG:

I think that is the most workable solution. 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.
Also, I don't see any specific reason to use a special tunneling
mechanism for the inter-MAG tunnel.

> 2. How this *protocol* dynamically negotiates the tunneling mechanism

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

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

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

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

Regards,
-- 
Hidetoshi

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 23 Sep 2009 00:58:00 -0500

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
> Sent: Tuesday, September 22, 2009 6:20 AM
> Thanks for your detailed thoughts. Below, we try to answer 
> your questions as best we can.
> 
> Ahmad Muhanna wrote:
> > Hi Hidetoshi,
> > 
> 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 
> 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.....

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

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

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

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

> > PMAG-NMAG? If NOT, what encapsulation mechanism is being 
> used and how 
> > is the mapping works?
> 
[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.

> If not, the network between MAGs should provide the 
> transparent environment (e.g., by another tunneling).
> 
> 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:
> > 
> > tunneling mechanism is dynamically established to address 
> the nature 
> > of the problem being address in this *handover optimization 
> protocol*.
> 
[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......

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

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

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

> What do you think could improve the readability of the document?
[Ahmad]
Quite some of them... But I gave up after a while....

> >> "...when the GRE Key Option [GREKEY] is used." What happens if the 
> >> GRE key option is NOT used. Is there another mechanism?
> >>

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Wed, 23 Sep 2009 12:47:57 -0400

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

> From: Ahmad Muhanna [mailto:[email-masked]] 
> Sent: Tuesday, September 22, 2009 10:58 PM
> To: Hidetoshi Yokota
> Subject: RE: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6
> 
> Hi Hidetoshi,
> 
> I expected a little more serious ones:), but please see some 
> more of the same thoughts inline! :)
> 
> Regards,
> Ahmad
> support all the 
> 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.
> 
> > 
> 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.....
> 
> > 
> > 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.
> 
> > 
> Is there anything in your document which specify that? I am 
> all ears, just point me to the text.
> 
> > 
> 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.
> 
> > 
> Could you please make sure that your document clarify and 
> clearly document it.
> 
> > 
> (PMAG-NMAG), 
> 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?
> 
> > 
> 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.
> 
> > 
> 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,
> > > ============
> 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
> 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 
> 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?
> 
> > 
> > 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......
> 
> 
> > 
> 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
> 3. If none of the above, how these GRE keys are generated and 
> exchanged between the PMAG and the NMAG?
> 
> > 
> 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?
> 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....
> 
> 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.
> 
> > 
> > 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.
>  
> > 
> > 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?
> > 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.
> 
> > >>>    selects that for the uplink packets.  Each key is 
> conveyed in 
> > >>> either
> > >>>>>>>>> instance, Section 5 talks about some 
> configuration issues. 
> > >>>>>>> These should
> > >>>>>>>    functionality on the LMA and the MN running in 
> the PMIPv6 
> > >>>>>>> domain.  A
> > >>>>>>>    with the cellular network, where the network 
> controls the 
> > >>>>>>> movement of
> respond to 
> > >>>>>>>              Identifier MUST be contained in the 
> Mobile Node 
> > >>>>>>> Identifier
> > >>>>>>>              Option.
> > >>>>>>> ---------
> > >>>>>>>
> > >>>>>>>> Added "Previous Care-of Address" and "New Care-of 
> Address". 
> > >>>>>>> Will read
> > >>>>>>>>>>           |(MN ID, Old AP ID) |     (MN ID, Old 
> AP ID)    
> > >>>>>>>  |        |
> > >>>>>>>>> Old AP ID? AN ID? AR ID?

---

From: Hidetoshi Yokota <[email-masked]>
Date: Thu, 24 Sep 2009 11:19:04 +0900

Hi Ahmad,

Please see inline:

> specific issue, let us continue.

Sorry that my explanation was not clear. I was talking about any new or
undefined encapsulation mechanism. All the mechanisms described in
RFC5213 should be supported on the inter-MAG tunneling as well.

>    the UL GRE key is sent in the HAck message.

The very last part "where the DL GRE Key is communicated in the HI
message while the UL GRE key is sent in the HAck message" has a bit of
problem since the HI/HAck messages are allowed to be sent by either the
PMAG or NMAG depending on the fast handover mode (i.e., depending on
which side initiates the procedure). All the other part looks fine.

Regards,
-- 
Hidetoshi

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 24 Sep 2009 00:35:12 -0500

Hi Hidetoshi,
Please see inline.

Regards, 
Ahmad

> possible. A 
> >> default mechanism should be GRE Key Option.
> >> Thinking it over and in the case of Vendor-specific 
> Mobility Option, 
> >> it would be necessary to define the whole message format 
> internally, 
> >> which may be beyond the scope of this document. Thus, it would be 
> >> better to describe only the use of GRE Key Option in the document.
> > [Ahmad]
> >> identifiable by the HNP, correct?
> > [Ahmad]
> >> case, GRE keys are not mandatory on the inter-MAG tunnel. 
> At the same 
> >> time, this spec does not mention any other encapsulation mechanism.
> > [Ahmad]
> > Hmmm... I am not sure how to interpret this because, there is some 
> > text under 4.1. which talks about all kind of tunneling that is 
> > currently being supported between the MAG and the LMA, but for the 
> > sake of this specific issue, let us continue.
> 
> Sorry that my explanation was not clear. I was talking about 
> any new or undefined encapsulation mechanism. All the 
> mechanisms described in
[Ahmad]
That is fine. 
I believe the other thread touch on this topic in detail and we can
follow up on this using that thread.

> >> to distinguish MN's packets for forwarding in advance or at this 
> >> time. Such information includes the HNP (or IPv4-MN-HoA) 
> and/or GRE 
> >> keys. Regarding the GRE key selection, the NMAG selects 
> the GRE key 
> >> for the downlink packets and the PMAG selects that for the uplink 
> >> packets.
> > messages to
> >    the case of GRE tunneling with GRE keys being used, the NMAG 
> > selects the GRE
> >    key for the downlink packets and the PMAG selects the 
> GRE key for 
> > the uplink
> The very last part "where the DL GRE Key is communicated in 
> the HI message while the UL GRE key is sent in the HAck 
> message" has a bit of problem since the HI/HAck messages are 
> allowed to be sent by either the PMAG or NMAG depending on 
> the fast handover mode (i.e., depending on which side 
> initiates the procedure). All the other part looks fine.

[Ahmad]
That is a valid point. 
I had the reactive mode in mind when I wrote the above paragraph, we can
modify it as follows:

"
   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 HNP (or IPv4-MN-HoA) and/or GRE key(s).
In
   the case of GRE tunneling with GRE keys being used, for each mobility
   session, the NMAG selects the GRE key for the downlink packets and
the 
   PMAG selects the GRE key for the uplink packets. These GRE keys are 
   exchanged between the PMAG and the NMAG using the GRE Key option as 
   described in [GREKEY], e.g., In the case of the reactive mode, the DL

   GRE key is communicated in the HI message while the UL GRE key is
sent 
   in the HAck message.
"

---

From: Hidetoshi Yokota <[email-masked]>
Date: Thu, 24 Sep 2009 17:28:56 +0900

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:
> 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 [email-masked] -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you.
> 
> 
>

---

From: Frank Xia <[email-masked]>
Date: Thu, 24 Sep 2009 09:18:09 -0500

Hi  Ahmad, Hidetoshi, and Rajeev

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

BR
Frank

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

>> 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 [email-masked] -- and destroy all 
>> copies of this message and any attachments without reading or disclosing 
>> their contents. Thank you.
>>
>>
>>
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 24 Sep 2009 09:28:29 -0500

Hi Hidetoshi,

If you want to try to understand my concern, please answer all the
comments. That is the best way to conclude a technical discussion. A
summary always reflects one person's views, understanding and ability to
summarize issues. Other issues may get lost in the middle. 

On the other hand, please come up with a text to address all of the
points I raised. That is fine.  

However, I want to emphasize that this *protocol* is to provide a FAST
HANDOVER which allows a registered active PMIPv6 mobility session (just
for the sake of simplification) to continue sending and receiving data
traffic with no *significant* interruption while moving from PMAG to
NMAG (referring to MAGs only for simplicity).

May be the following *analogy* will help simplify and explain what this
protocol is supposed to do:
PMIPv6 is a mechanism which offers IP layer mobility for any mobile
node. This protocol (PMIPv6) involves a control part which makes sure
the anchor point is tracking the latest current location of the mobile
node + It also offers a very DETAILED mechanism on how data is routed
and delivered from and to the mobile node current location. This
includes defining the needed encapsulation for all usecases. Thanks God
that part is already done for you on the PMIPv6 leg (if I may say)
MAG-LMA tunnel. NOW: this *protocol* is supposed to route and deliver
the PMIPv6 mobility session traffic from and to the mobile node over a
new interface PMAG-NMAG, dynamically.

In other words, this *protocol* is absolutely NOT about moving the
mobile node session content from the PMAG to the NMAG. EXACTLY the same
way PMIPv6 is NOT ONLY about keeping track of the location of the mobile
node point of attachment at the anchor point. Right?

Hope this helps explain the expected outcome and objective of this
protocol!

Just a reminder, as the encapsulation mechanism is done dynamically over
the MAG-LMA leg, it is REQUIRED for this protocol to offer a detailed
mechanism on how dynamically and without any *ambiguity* it is able to
deliver the *mobility session* traffic from and to the mobile node over
NMAG-PMAG interface.

Regards,
Ahmad

> Sent: Thursday, September 24, 2009 1:29 AM
> To: Koodli, Rajeev
> 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.
> > 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
> > 
> > 
> >> I expected a little more serious ones:), but please see 
> some more of 
> >> the same thoughts inline! :)
> >>
> >> Regards,
> >> 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?
> >>
> >> 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.
> >>
> 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.....
> >>
> >>> in the scope of RFC5213, that of the inter-MAG tunnel 
> should follow 
> >>> it.
> >> 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 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.
> >>
> >> limitation of the PMIPv6 protocol. Right? Then, when you need 
> >> multiple GRE keys, how these GRE keys are communicated?
> >> 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.
> >>
> >> IPv6-in-IPv6 tunneling between the mobile node and the 
> home agent. In 
> >> the case of
> (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?
> >>
> >>
> >> 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?
> >>
> supported by 
> 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:
> >> =================
> >> GRE tunneling with GRE keys + GRE keys exchange using
> session, 
> >> how GRE tunneling and GRE keys are negotiated between the PMAG and 
> >> NMAG? Of course, using HI and HAck, right?
> >> That tunneling is implicitly negotiated between the PMAG and LMA 
> >> 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.
> >>
> determined in 
> the LMA is 
> NMAG-PMAG 
> >> 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?
> >> about this. A clear understanding of this tunneling is 
> needed and I 
> >> do not see it documented in this draft.
> >>
> >>    In order to further improve the performance during the 
> handover, 
> >> the
> >>>>>>>>>>>>>         indicates a MN handover.  While this 
> signaling is
> >>>>>>>>>> dependent on
> >>>>>>>>>>>> New terms PCoA and NCoA... there's probably more 
> undefined
> >>>>>>>>>> terms in the
> >>>>>>>>>>>> document, please check!
> > 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 [email-masked] -- and destroy all 
> copies of this message and any attachments without reading or 
> disclosing their contents. Thank you.
> > 
> > 
> > 
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 24 Sep 2009 09:31:03 -0500

Hi Frank,
Please see my latest response to Hidetoshi.

Regards,
Ahmad

> From: Frank Xia [mailto:[email-masked]] 
> Sent: Thursday, September 24, 2009 7:18 AM
> To: Hidetoshi Yokota; Koodli, Rajeev; Muhanna, Ahmad (RICH1:2H10)
> I have followed the discussion, and agreed with Rajeev's proposal.
> 
> BR
> Frank
> 
> questions and 
> >> 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.
> >>
> >> 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
> >>
> >>
> >>>>> Looking one more time into the draft I found the 
> following under 
> >>>>> section
> >>>>> 4.1:
> >>>>>
> >>>>> "
> >>> clearly. On the other hand, if it supports the above listed 
> >>> tunneling protocols, it MUST document how forwarding 
> these packets 
> implementation 
> >>> 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.
> >>>
> >>> IPv6-in-IPv6 or explain how they will work.....
> >>>
> >>> Is there anything in your document which specify that? I am all 
> >>> ears, just point me to the text.
> >>>
> tunneling 
> could you 
> data! How 
> home agent. 
> >>> In the case of
> >>> 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?
> >>>
> >>>
> >>> 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......
> >>>
> >>>
> >>> OK. I am not disputing that the PMAG and the NMAG 
> supports the same 
> >>> 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.
> >>> 3. Now: for the inter-MAG tunnel and for the same 
> mobility session, 
> >>> Well, what do you mean? The tunneling between the PMAG 
> and the LMA 
> >>> is NOT on demand?
> >>> 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.
> >>>
> >>>>>>>>>>>> Appreciate your detailed review. The editorial 
> corrections
> >>>>>>>>>>> are mostly
> >>>>>>>>>>>> at any given time. This is a tougher situation 
> in terms of
> >>>>>>>>>>> packet loss
> >>>>>>>>>>>> and delay.
> >>>>>>>>>>>>
> >>>>>>>>>>>> We will add a new section for manageability 
> considerations
> >>>>>>>>>>> to clarify
> >>>>>>>>>>>> I think your observation is correct... I'll 
> check with the
> >>>>>>>>>>> other authors
> >>>>>>>>>>>>> I would like the required options to be 
> specified in more
> >>>>>>>>>>> detail. Which
> >>>>>>>>>>>>>>         resolve the NMAG and the new access 
> point or the
> >>>>>>>>>>> base station to
> >>>>>>>>>>>>> New terms PCoA and NCoA... there's probably 
> more undefined
> >>>>>>>>>>> terms in the
> >>>>>>>>>>>>> document, please check!
> 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 
> >> [email-masked] -- and destroy all copies of this 
> >> message and any attachments without reading or disclosing

---

From: Frank Xia <[email-masked]>
Date: Thu, 24 Sep 2009 10:51:15 -0500

Hi Ahmad

I thought Hidetoshi had a good summary of
you comments.  Could you give me a brief
information of your concerns? because I have
similar understanding as Hidetoshi.

BR
Frank

----- Original Message ----- 
From: "Ahmad Muhanna" <[email-masked]>
To: "Frank Xia" <[email-masked]>; "Hidetoshi Yokota" 
<[email-masked]>
Cc: "Mipshop" <[email-masked]>; 
<[email-masked]>
Sent: Thursday, September 24, 2009 9:31 AM
Subject: RE: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6

Hi Frank,

Regards,
Ahmad

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 24 Sep 2009 10:53:53 -0500

Hi Frank,
It is confusing.. 
You just said in your earlier email that you have been following the
discussion! :) 
Probably the best way for you is to go and look it over.

Regards,
Ahmad

> Sent: Thursday, September 24, 2009 8:51 AM
> To: Muhanna, Ahmad (RICH1:2H10); Hidetoshi Yokota
> I thought Hidetoshi had a good summary of you comments.  
> Could you give me a brief information of your concerns? 
> because I have similar understanding as Hidetoshi.
> 
> BR
> Frank
> 
> transparent 
> > >>>> The nature of the specification and its performance is 
> based on 
> > >>>> RFC5568.
> > >>> [Ahmad]
> supporting 
> specification 
> > >>>>>>>>>> In GRE keys for PMIPv6 draft, downlink GRE key 
> is included
> > >>>>>>>>> in the PBU
> > >>>>>>>>>> Sorry for this comment to be so late but hope 
> that you have
> > >>>>>>>>> the chance
> > >>>>>>>>>> to take a look at it.
> > >>>>>>>>>>> Thanks for your patience. The attached revised 
> document is
> > >>>>>>>>> supposed to
> > >>>>>>>>>>> reflect the rest of your comments. Please also 
> see inline,
> > >>>>>>>>> where the
> > >>>>>>>>>>>> technical comments, only the policies for the 
> correction
> > >>>>>>>>>>> are listed for
> > >>>>>>>>>>>>> I have reviewed this document. It was 
> generally in good
> > >>>>>>>>>>> shape and easy
> > >>>>>>>>>>>>> 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.
> > >>>>>>>>>>>> where the network basically controls the 
> movement of the
> > >>>>>>>>>>> MN. Different
> > >>>>>>>>>>>> and 3.9G) or different radio access systems. 
> Any type of
> > >>>>>>>>> IP address
> > >>>>>>>>>>>> must be preserved before and after the 
> handover. PFMIPv6
> > >>>>>>>>>>> should be able
> > >>>>>>>>>>>>> be mentioned, and there should be a 
> description of what
> > >>>>>>>>>>> the operator
> > >>>>>>>>>>>>> Is this according to RFC 5213? I seem to 
> recall that RFC
> > >>>>>>>>>>> 5213 operated
> > >>>>>>>>>>>    whether link-layer addresses are used 
> between a MN and
> > >>>>>>>>> its access
> > >>>>>>>>>>>    [RFC4861], after attaching to a new link, 
> probing the 
> > >>>>>>>>>>> reachability of
> > >>>>>>>>>>>    should allow the MN to continue to send 
> uplink packets
> > >>>>>>>>> while it is
> > >>>>>>>>>>>    performing NUD.
> > >>>>>>>>>>> ----------------
> > >>>>>>>>>>>
> > >>>>>>>>>>>>>> message in the corresponding mobility 
> option(s) (e.g.,
> > >>>>>>>>>>> HNP, LMAA or
> > >>>>>>>>>>>> Node Link-layer Identifier Option MUST also be 
> requested.
> > >>>>>>>>>>> With these two
> > >>>>>>>>>>>    Option.  If the Mobile Node link-layer is 
> available and
> > >>>>>>>>> used, the
> > >>>>>>>>>>>>>>         A generic signaling message, sent 
> from the P-AN
> > >>>>>>>>>>> to the PMAG that
> > >>>>>>>>>>>>>>         which the MN is moving to.  The 
> details of this
> > >>>>>>>>>>> message are
> > >>>>>>>>>>>>> beginning to explain what assumptions there 
> exist about
> > >>>>>>>>>>> lower layer
> > >>>>>>>>>>>>> functionality.
> > >>>>>>>>>>>> functionality to trigger to send the HI. A new 
> paragraph
> > >>>>>>>>>>> will be added
> > >>>>>>>>>>>> to clarify it.
> > >>>>>>>>>>> -------------
> > >>>>>>>>>>>    mobility agents, compared to the baseline 
> specification
> > >>>>>>>>> of PMIPv6.
> > >>>>>>>>>>>   [...]
> > >>>>>>>>>>> -------------
> > >>>>>>>>>>>
> > >>>>>>>>>>>>>>    address that is used by the MN is MN-HoA. 
>  Hence the
> > >>>>>>>>>>> PAR forwards
> > >>>>>>>>>>>> Added the unabbreviated form "Mobile Node's 
> Home Address"
> > >>>>>>>>> before it.
> > >>>>>>>>>>>>>>         The access network to which the MN 
> is attached
> > >>>>>>>>>>> after handover.
> > >>>>>>>>>>>>>>         flag set and include the MN ID, the 
> MN-HNP, the
> > >>>>>>>>>>> MN-IID and the
> > >>>>>>>>>>>>>>    between the PCoA and NCoA to forward 
> packets for the
> > >>>>>>>>>>> MN to the NAR,

---

From: Frank Xia <[email-masked]>
Date: Thu, 24 Sep 2009 11:01:22 -0500

Hi Ahmad

Sorry not studying every words from you,
even though I have followed the thread.

If  I can bother you give me some different brief
information other than Hidetoshi's summary,
you are appreciated.

Let's try to be more constructive.

BR
Frank

----- Original Message ----- 
From: "Ahmad Muhanna" <[email-masked]>
To: "Frank Xia" <[email-masked]>; "Hidetoshi Yokota" 
<[email-masked]>
Cc: "Mipshop" <[email-masked]>; 
<[email-masked]>
Sent: Thursday, September 24, 2009 10:53 AM
Subject: RE: [Mipshop] AD review of draft-ietf-mipshop-pfmipv6

Hi Frank,
It is confusing..

Regards,
Ahmad

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 24 Sep 2009 11:10:58 -0500

> Sorry not studying every words from you, even though I have 
> followed the thread.
> 
> If  I can bother you give me some different brief information 
> other than Hidetoshi's summary, you are appreciated.
> 
[Ahmad]
That's fine, but it is not healthy to repeat the whole thing over again.
Sorry, if you are interested you should go back and read the whole
thing.

Regards,
Ahmad
> You just said in your earlier email that you have been 
> following the discussion! :) Probably the best way for you is 
> to go and look it over.
> 
> Regards,
> Ahmad
> 
> 
> > > >>>>>>>    distinguish MN's packets for forwarding in 
> advance or at
> > > >>>>>> this time.
> > > >>>>>>>>> Thanks for your comment. I'm glad to hear an 
> opinion from
> > > >>>>>>> a GRE key
> > > >>>>>>>>>> from the NAR to PAR in the HI (section 4.2). 
> Is that the
> > > >>>>>>> case? This
> > > >>>>>>>>>> and the uplink GRE key in included in the PBA. 
> They never
> > > >>>>>>>>> exist in the
> > > >>>>>>>>>>> [Apologize if you received it twice. Since 
> the size just
> > > >>>>>>>>> exceeded the
> > > >>>>>>>>>>>> done and the revised version is attached to 
> this mail.
> > > >>>>>>>>> Regarding the
> > > >>>>>>>>>>>> now. The complete correction will be posted 
> as soon as
> > > >>>>>>>>>>> possible. Please
> > > >>>>>>>>>>>>> to read. I did find a number of issues 
> though. Please
> > > >>>>>>>>>>> discuss them with
> > > >>>>>>>>>>>>> unmodified host, what kind of interfaces 
> exist on the
> > > >>>>>>> host, what
> > > >>>>>>>>>>>> types of interfaces could be involved such 
> as different
> > > >>>>>>>>>>> generations (3G
> > > >>>>>>>>>>>> could be assigned (IPv4/v6 or 
> global/private), but the
> > > >>>>>>>>>>> assigned address
> > > >>>>>>>>>>>    mode, where only one interface is active 
> at any given
> > > >>>>>>> time.  The
> > > >>>>>>>>>>>    assigned IP address is preserved whether 
> the physical
> > > >>>>>>> interface
> > > >>>>>>>>>>>>>> set to promiscuous mode), then it can 
> respond to the
> > > >>>>>>> NUD probe,
> > > >>>>>>>>>>>    The protocol specified in this document is 
> applicable
> > > >>>>>>>>> regardless of
> > > >>>>>>>>>>>    Advertisement, which is common in the 
> PMIPv6 domain.
> > > >>>>>>>>>>> Implementations
> > > >>>>>>>>>>>> The required option should be the MN 
> Identifier in the
> > > >>>>>>> Mobile Node
> > > >>>>>>>>>>>> Identifier Option.
> > > >>>>>>>>>>>>>> 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
> > > >>>>>>>>>>>> The default context information to request 
> is the Home
> > > >>>>>>>>>>> Network Prefix
> > > >>>>>>>>>>> used, the Mobile
> > > >>>>>>>>>>>    Mobile Node Link-layer Identifier Option 
> MUST also be
> > > >>>>>>> requested.
> > > >>>>>>>>>>> ----------
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>>> Editorial:
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>    HO-Initiate:
> > > >>>>>>>>>>>    If the MAGs can be informed of the 
> detachment and/or
> > > >>>>>>>>> attachment of
> > > >>>>>>>>>>>>>>    as MN's NAI, Home Network Prefix (HNP), 
> IPv4 Home
> > > >>>>>>>>> Address, are
> > > >>>>>>>>>>>>> New term NAI...

---

From: Hidetoshi Yokota <[email-masked]>
Date: Sun, 27 Sep 2009 15:29:56 +0900

Hi Ahmad,

Sorry, but we should have answered your questions much earlier.

> claims to support as quoted above?

The above tunneling types are supported.

> protocols, it MUST document how forwarding these packets over the

Ok. We will add the header format and mapping rules in the document.

> based on MIP6 as described in RFC3775. In that sense, only IPv6-in-IPv6

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.

> time documents nothing about how these should work across the inter-MAG

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.

> just point me to the text.

The document will be updated as stated above.

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

> Could you please make sure that your document clarify and clearly

The document will be updated clarifying the above.

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

> GRE keys, how these GRE keys are communicated? Is that explained in the

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.

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

> tunneling between the PMAG and LMA.

Ok.

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

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

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

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

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

> What do you have to technically back up this statement. Otherwise, it is

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.

> it to the end of the tunnel in a non ambiguous way.

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:

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

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

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

> tunnel! Which encapsulation mechanism is going to use to encapsulate

If the tunneling mechanism is IPv6-in-IPv4-UDP, the same mechanism is used.

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

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

> Quite some of them... But I gave up after a while....

I asked a wrong question...:-)  But please don't give up.

Regards,
-- 
Hidetoshi

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Sun, 27 Sep 2009 03:25:55 -0500

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

> Sent: Sunday, September 27, 2009 1:30 AM
[Ahmad]
Agreed!

> >> The intention here is that the inter-MAG tunnel should support all 
> >> the encapsulation types that are mentioned in RFC5213.
> > [Ahmad]
> > 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.
> 
> >> 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.
> > 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.
> 
> >> That mode has not been considered. It will be possible, 
> but is there 
> > PMAG and the NMAG; However, You are saying that, e.g., 
> > 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.
> > 
> 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.
> 
> >> 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,
> I think the new text for that part, which we are discussing 
> in another thread, will make it clear.
> 
> > GRE keys, how these GRE keys are communicated? Is that explained in 
> > the document?
> 
> 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.
> 
> > 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...

> >> for  PMIPv6, PFMIPv6 should also support it. If this is 
> too vague, it 
> >> could be removed.
> > [Ahmad]
> The tunnel between the LMA and MAG for a mobile node will be 
> dynamically established, but the tunneling method should be 
> determined in advance.
> 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.
> 
> > 
> 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?
> 
> 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.
> 
> > 
> Possible, but less likely. Need to investigate the risk of 
> collisions and others.
> 
> By the HI/HAck exchange, which is most assumed in the 
> document. Again, the new text in another thread will make it clear.
> 
> 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.
> > 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 
> > 3. Now: for the inter-MAG tunnel and for the same mobility session, 
> 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?
> need the 
> 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....
> > 
> 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.
> 
> 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.
> 
> > 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?
> 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...
> 
> needed and I do 
> handover, the
> 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...
>

---

From: Hidetoshi Yokota <[email-masked]>
Date: Tue, 29 Sep 2009 11:50:58 +0900

Hi Ahmad,

Thanks for your revised text proposal below, which looks just fine.
We'll incorporate it into the next revision.

Regards,
-- 
Hidetoshi