Subject: [Mipshop] Review of Transient Binding Spec

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 7 Aug 2009 14:21:15 -0400

Hello,

I reviewed draft-ietf-mipshop-transient-bce-pmipv6-03 and have a few 
comments. The document is very well written and is mostly ok, but there 
are few comments that should be addressed before the document is sent to 
the IESG.

>    This document specifies a mechanism which enhances Proxy Mobile IPv6
>    protocol signaling to support the creation of a transient binding
>    cache entry which is used to optimize the performance of dual radio
>    and active single radio handover.  This mechanism is applicable to

What is "active single radio handover"?

>  The transient
>    BCE extension, as specified in this document, increases handover
>    performance (optimized packet loss and forwarding delay) experienced
>    by MNs, which have multiple network interfaces implemented while
>    handing over from one interface to the other and for single radio
>    MNs, which build on available radio layer forwarding mechanisms,
>    hence re-use existing active handover techniques.

I suggest splitting up the above sentence to describe dual radio and 
single radio handovers separately, since the above sentence seems to 
indicate separate techniques depending on whether it is a single radio 
or dual radio handover.

>    its nMAG.  A transient binding on the LMA can be controlled remotely,
>    such as from a MAG, 

I wouldn't call the MAG modifying the transient binding as "controlled 
remotely". MAGs always have a role in modifying the binding cache entires.

>    by means of signaling or by local information and
>    local events.  Local information and events can for example derive
>    from states or state changes of local database or cache entries (e.g.
>    about the used radio technology or the connection status, etc.),
>    whereas such information may also be under control of external
>    functions (e.g. radio controller or AAA server).  

I read the above sentence multiple times, but couldn't figure out what 
the local information and local events mean. What exactly is the above 
trying to say?

Do we have the following three cases? 1. MAG modifying the transient 
BCEs, 2. some local events or information at the LMA modifying the 
transient BCEs and 3) the AAA servers or some other external function 
modifying the transient BCE.

> 3.  Analysis of the Problem Space
> 
>    This section summarizes the analysis of the handover problem space
>    for inter-technology handover as well as intra-technology handover
>    when using the PMIPv6 protocol as in [RFC5213].
> 
> 3.1.  Handover using a single interface
> 
>    In some active handover scenarios, it is necessary to prepare the
>    handover target MAG prior to the completion of the link layer

This was called nMAG elsewhere in the document. Now you are calling it 
"handover target MAG" or "target MAG". Please pick one.

> 3.2.1.  Issues with downlink traffic
> 
>    Delay of availability of an MN's network interface can be caused by
>    certain protocol operations that the MN needs to perform to configure
>    its new interface and these operations can take time.  In order to
>    complete the address auto-configuration on its new interface, the MN
>    needs to send a router solicitation and awaits a router
>    advertisement.  Upon receiving a router advertisement from the new
>    MAG, the MN can complete its address configuration and perform
>    Duplicate Address Detection (DAD) [RFC4862] on the new interface.
>    Only then the MN's new interface is ready to receive packets.
> 
>    Address configuration can take more than a second to complete.  If
>    the LMA has already switched the mobile node tunnel to point to the
>    nMAG and started forwarding data packets for the MN to the nMAG
>    during this time, these data packets may get delayed or lost because
>    the MN's new interface is not yet ready to receive data.  However,
>    delaying the PBU, which is sent from the new MAG to the LMA after the
>    MN's new interface has attached to the network, is not possible, as
>    the new MAG retrieves configuration data for the MN from the LMA in
>    the PBA.  With host-based mobility protocols, such as Mobile IPv6
>    [RFC3775], MNs can easily control when a binding is updated.  This is
>    different for network-based mobility management, where hosts are not
>    involved in IP mobility management [RFC4831]

Please delete the last two sentences. It is a repeat and does not really 
add anything to the paragraph. The previous sentences already establish 
the fact that you need the PBU/PBA exchange for prefix information and 
once the prefix information is received, the MN sets up the new link. So 
there is a period where downlink packets come to the nMAG and could get 
dropped.

>    The aforementioned problem is exemplarily illustrated in Figure 1,

Drop "exemplarily". :)

>    In case an access technology needs the MN's IP address or HNP to set
>    up a radio bearer between an MN's IF2 and the network infrastructure,
>    the responsible network component might have to wait until the nMAG
>    has received the associated information from the LMA in the Proxy
>    Binding Acknowledgment.  

Is this really the case? Does the radio network need the MN's IP address 
or HNP?

Delay in forwarding packets from the nMAG to
>    the MN's IF2 depends now on the latency in setting up the radio
>    bearer.
> 
>    A similar problem can occur in case the set up of a required security
>    association between the MN's IF2 and the network takes time and such
>    set up can be performed only after the MN's IP address or HNP is
>    available on the nMAG.

Same question as above.

> 3.2.2.  Issues with uplink traffic
> 
>    In case of an inter-technology handover between two interfaces the MN
>    may be able to maintain connectivity on IF1 while it is completing
>    address configuration on IF2.  Such handover mechanism is called
>    make-before-break and can avoid UL packet loss in client based Mobile
>    IP.  However, in a PMIPv6 domain the attachment of the MN on IF2 will
>    cause the nMAG to send a PBU to the LMA which will cause the LMA to
>    update the BCE for this mobility session of the MN.  According to
>    section 5.3.5 of the PMIPv6 base specification [RFC5213], the LMA
>    will drop all subsequent packets being forwarded by the MN's pMAG due
>    to the updated BCE, which refers now to the nMAG as Proxy-CoA.  Thus
>    make-before-break handover is currently not supported by PMIPv6.

I would delete the last sentence. There could be LMA implementations 
that accept uplink packets from both old MAG and new MAG for a short 
while when there is a handover. I don't believe LMAs will strictly start 
dropping packets from the old MAG. So it might be better to rephrase as 
"this MAY be an issue".

>    A further issue for uplink packets arises from differences in the
>    time of travel between nMAG and LMA in comparison with the time of
>    travel between pMAG and LMA.  Even if the MN stops sending packets on
>    IF1 before the PBU is sent (i.e. before it attaches IF2 to nMAG),
>    uplink packets from pMAG may arrive at the LMA after the LMA has
>    received the PBU from nMAG.  Such situation can in particular occur
>    when the MN's previous link has a high delay (e.g. a GSM link) and is
>    slow compared to the handover target link.  This characteristic is
>    exemplarily illustrated in Figure 2.

Too many adjectives. :)

> 3.3.  Demand for a common solution

Please rephrase as "Need for a common solution".

>    To reduce the risk of packet loss, some settings on an MN could be
>    chosen appropriately to speed up the process of network interface
>    configuration.  Also tuning some network parameters, such as
>    increasing the buffer capacity on MAG components, could improve the
>    handover performance.  However, some network characteristics, such as
>    access link delay or bearer setup latency, cannot be easily fine
>    tuned to suit a particular handover scenario.  Thus, a common
>    solution which dynamically controls and enhances this handover
>    complexity using a simple extension to the PMIPv6 base protocol is
>    extremely preferred.

I would delete "extremely".

>    This document specifies transient BCEs as an extension to the PMIPv6
>    protocol.  Set up and configuration of a transient BCE can be
>    performed by means of standard PMIPv6 signaling messages between the
>    MAG and the LMA component using a new Transient Binding mobility
>    option.  

Since there is a new mobility option, I wouldn't call it "standard 
PMIPv6". More like "modified PMIPv6".

>    The use of a transient BCE during an MN's handover splits into an
>    initiation phase and an activation phase.  Figure 3 illustrates the
>    procedure to enter and activate a transient BCE during an MN's
>    handover.  As a result of the MN's attachment at the nMAG, the first
>    PBU from the MN's nMAG can perform configuration of a transient BCE
>    at the LMA and the nMAG by including a Transient Binding option

Isn't the existing BCE modified to become a transient BCE?

>    Decision to use an optional activation state -  The LMA is a suitable
>       entity to decide about the use of an optional activation state, as
>       the LMA has the knowledge about the MN's previous and new access
>       technology.  

I guess you are talking about the ATT mobility option. The ATT field is 
just a string. I guess you are making an assumption that the LMA knows 
how that particular radio technology behaves and how long it would take 
for the MN to setup the link based on this string. Perhaps this should 
be pointed out.

>                                 +----------------+              Before
>           PBU(nMAG) & PBA(LMA)  |    Active      |              Handover
>         +-----------------------|                |              --------
>         |                       |  pMAG [Dl,Ul]  |                   .
>         |                       *----------------*                   .
>         |                               |                            .
>         |                               |                            V
>         |               PBU(nMAG, Topt) | PBU(nMAG) & PBA(LMA, Topt) .
>         |                               |                            .
>         |                               |                            .
>         |                               V                      Handover
>         |                           __________                 Procedure
>         |                          /   LMA    \                      .
>         |               _________ /  selects   \ _________           .
>         |            No|          \ activation /          |Yes       .
>         |              |           \____?_____/           |          .
>         |              |                                  |          V
>         |              V                                  V          .
>         |       +--------------+                  +--------------+   .
>         |       | Transient-L  |                  | Transient-LA |   .
>         |       |              |                  |              |   .
>         |       | pMAG [Dl,Ul] |          +-------| pMAG [Dl,Ul] |   .
>         |       | nMAG [Ul]    |          |       | nMAG [Ul]    |   .
>         |       +--------------+          |       +--------------+   .
>         |              |                  |               |
>         |              |       PBU(pMAG,  |     PBU(nMAG) | TIMEOUT_1
>         |              |       lifetime=0)|               |          .
>         |              |                  |               V          .
>         |              |                  |       +--------------+   .
>         |              |                  |       | Transient-A  |   .
>         |    PBU(nMAG) | TIMEOUT_1        |       |              |   .
>         |              |                  |       | nMAG [Dl,Ul] |   .
>         |              |PBU(pMAG,         |       | pMAG [Ul]    |   .
>         |              | lifetime=0)      |       +--------------+   .
>         |              |                  |               |
>         |              |                  |   PBU(pMAG,   | TIMEOUT_2
>         |              |                  |    lifetime=0)|          .
>         |              |                  |               |          V
>         |              |                  |               |    -------
>         |              |                  |               |    Handover
>         |              |                  |               V    Complete
>         |              |                  |        +--------------+
>         |              |                  +------->|    Active    |
>         |              +-------------------------->|              |
>         +----------------------------------------->| nMAG [Dl,Ul] |
>                                                    +--------------+
> 
>      Figure 4: Possible transient forwarding states during a handover.

I liked this a lot. It explains the protocol and state transitions very 
clearly.

> 4.5.  MAG operation
> 
>    In case of a handover, the MN's nMAG may decide to control the MN's
>    handover at the LMA to perform a late path switch according to the
>    transient BCE procedure.  In such case, the nMAG includes a Transient
>    Binding option in the PBU message it sends to the MN's LMA.  In the
>    current version of the specification, the nMAG MUST set the L-flag to
>    1 if the Transient Binding option is included in the PBU.

Replace the last two sentences with

    In such case, the nMAG includes the Transient Binding Option in the
    PBU and sets the L-flag to 1 to indicate late path switch.

The current text is confusing.

>    policy.  If the lifetime value in the Transient Binding option
>    exceeds the lifetime value associated with the PBU message, the LMA
>    MUST reduce the lifetime of the transient BCE to a value smaller than
>    the registration lifetime value in the PBU message. 

>    the lifetime.  If the lifetime value in the Transient Binding option
>    exceeds the lifetime value associated with the PBU message, the LMA
>    MUST reduce the lifetime of the transient BCE to a value smaller than
>    the registration lifetime value in the PBU message.

The text related to reducing the lifetime for the transient binding 
appears twice in section 4.6.1.

>    In any case where the LMA finds the L-flag of the received Transient
>    Binding option set to 1, but the lifetime field of the Transient
>    Binding option is set to 0, the LMA MUST ignore the Transient Binding
>    option and process the PBU according to [RFC5213].  After the PBU has
>    been processed successfully, the LMA sends back a PBA with the status
>    field set to PBU_ACCEPTED_TB_IGNORED_SETTINGSMISMATCH.

Why is this wrong? Why can't the MAG let the LMA decide on the lifetime  ?

> 4.7.  MN operation
> 
>    Operation of the MN to support handover and choosing appropriate
>    settings for a transient BCE is out of scope of this specification.

I don't understand this? The whole transient binding is transparent to 
the MN. What settings should be configured on the MN? The address on the 
MN does not change. At some point during the handover, it starts sending 
uplink packets to the nMAG instead of the pMAG. And at some point during 
the handover, the downlink packets that were flowing from the pMAG will 
start flowing from the nMAG.

>    It is further out of the scope of this document how the MN can
>    perform address configuration of the same IP address for two
>    simultaneously attached interface.

On this point to RFC 5213 and say that this document does not assume any 
special behavior apart for what is expected in RFC 5213.

>    The format of the Transient Binding option is as follows.
> 
> 
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |    Type       |     Length    | Reserved    |L|   Lifetime    |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
>    Type: Identifies the Transient Binding option.  To be assigned by
>    IANA.
> 
>    Length: 8-bit unsigned integer indicating the length of the option in
>    octets, excluding the Type and the Length fields.  This field MUST be
>    set to 2.
> 
>    L-Flag: Indicates that the LMA applies late path switch according to
>    the transient BCE state.  If the L-flag is set to 1, the LMA
>    continues to forward downlink packets towards the pMAG.  Different
>    setting of the L-Flag may be for future use.
> 
>    Lifetime: Maximum lifetime of a Transient-L state in multiple of
>    100ms.

This gives a max of 12.7 seconds. Is that sufficient? Just curious.

I haven't reviewed Appendix B yet. Appendix A looks good.

Vijay

---

From: Marco Liebsch <[email-masked]>
Date: Mon, 10 Aug 2009 18:37:47 +0200

Hi Vijay,

thanks a lot for your review and your valuable comments.
We'll incorporate your comments into an update and will address
comments, which have a question mark behind, by means of clarifying text.
Please find also some feedback inline.

marco

> What is "active single radio handover"?
Here we refer to the use of tBCE to benefit from existing radio 
technology specific
forwarding between radio access networks, as used in 3GPP. This happens 
below
MAG level. We propose to replace with the following text:

"This document specifies a mechanism which enhances Proxy Mobile
IPv6 protocol signaling to support the creation of a transient
binding cache entry which is used to optimize the performance
of dual radio handover, as well as single radio handover in
case radio access specific forwarding between radio access
networks is available."

> indicate separate techniques depending on whether it is a single radio 
Good point. We'll split the description.

> remotely". MAGs always have a role in modifying the binding cache entires.
True. Better to say: "MAGs can establish settings of a transient binding 
on the LMA by means of
signaling..." ?

> modifying the transient BCE.
well, actually two cases. 1. MAG modifies the tBCE. 2. LMA takes the 
decision.
According to comments we received some time ago, we wanted to clarify 
how the
LMA could find out when and how to use tBCE. One example was a local event,
which could be a timer to terminate the transient state. Local 
information means, for
example, entries from the BCE, such as ATT. Further, information can be 
retrieved
from or pushed by a AAA or a radio controller. However, as impact from other
network entities (e.g. AAA) is out of scope, such external control will 
turn into
an "event" on the LMA (e.g when the AAA message is received).

But we'll try to find better text.

> "handover target MAG" or "target MAG". Please pick one.
True. We'll keep it consistent.

> there is a period where downlink packets come to the nMAG and could get 
Ok.

>>    The aforementioned problem is exemplarily illustrated in Figure 1,
Ok.

> Is this really the case? Does the radio network need the MN's IP address 
HNP is needed on the nMAG. For example a packet data gateway, serving as 
MAG,
needs the HNP to bind it to an IPsec connection with the MN. In 3GPP, 
it's the LMA
providing the HNP to the MAG before a radio bearer is being set up.If no 
CTX exists,
the LMA provides the HNP. And according to the standard, the LMA is the 
entity
providing the HNP.

>>    set up can be performed only after the MN's IP address or HNP is
Hope it's clarified with the reply to the comment before.

> dropping packets from the old MAG. So it might be better to rephrase as 
ok.

>>    exemplarily illustrated in Figure 2.

Even though I like them very much, I'll remove some of them ;-)

> Please rephrase as "Need for a common solution".
Good.

> I would delete "extremely".
Ok.

> PMIPv6". More like "modified PMIPv6".
is "extended" acceptable? It's not a modification, but we add a new 
option. So, we extend the
standard format.

> Isn't the existing BCE modified to become a transient BCE?
Yes. It should not be read as the PBU creates a new BCE. Will try to 
find better words.

> for the MN to setup the link based on this string. Perhaps this should 
Our point here was that rather the LMA is suitable to take this 
decision, as it knows about
technologies behind both MAGs (pMAG and nMAG). We see in particular 
benefit from
the activation state in case of dual-radio handover, hence it could be 
sufficient that the
LMA identifies this. The actual lifetime of the activation state is a 
default value.

If you propose that the default value is modified according to the 
technology details, well, this is not
what the spec describes, even though this could be done and may be 
implementation specific.
So, we did not talk about this. But we'll consider you proposal for 
clarification in the revision.

> I liked this a lot. It explains the protocol and state transitions very 
Good :-)

> The current text is confusing.
Ok.

> appears twice in section 4.6.1.
Ok, we'll revise this.

> Why is this wrong? Why can't the MAG let the LMA decide on the lifetime  ?

Yes, LMA could adjust, but this was rather meant to be a limitation policy.
If nMAG does not provide a timeframe, LMA is without a clue. Semantically,
lifetime 0 means *terminate* the transient state instataneously, i.e. treat
this as a normal binding update. This is what the status field reflects.
Theoretically, the protocol could specify a special rule that lifetime 0
means LMA is to specify what lifetime to use. We had no intention to do this
and we received comments some time ago to take this decision out of the LMA.

> start flowing from the nMAG.
This referred to potential future extensions where MNs could provide a 
hint about the
nature of an attachment to the AR/MAG. This info could be taken on the 
nMAG to
chose appropriate settings for the TBoption. But I agree that we better 
take this out
of the specification, as it's not important for the current protocol.

> special behavior apart for what is expected in RFC 5213.
I don't think RFC5213 assumes MBB. Maybe we should take out the MN 
considerations
section completely.

> This gives a max of 12.7 seconds. Is that sufficient? Just curious.
Hmm, actually we have 8 bit (1 Byte) for the Lifetime. This gives us max 
25.6 seconds, which
should be ok for a handover. Or am I missing something?

Thanks,
marco

> _______________________________________________
> Mipshop mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mipshop
>

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Mon, 10 Aug 2009 21:51:14 -0400

Hi Vijay, All,

I have reviewd the draft. 

It is generally well-written. I do have several comments. 

First, the draft scope. It is claimed that it handles intra-technology
(i.e., single radio) handovers. But, the draft is primarily about
multi-interface handovers. There is a sub-section 3.1, but the focus is
mostly on multi-interface handovers (I do have several comments on 3.1
below). So, I suggest the scope to clearly state that the draft is
primarily about multi-radio handovers. 

Second, there are three main parts in this ID: 1) handling uplink
packets at the LMA during transition from one i/f to another, 2)
handling downlink packets arriving at the nMAG and, 3) forwarding
packets to pMAG (and when to switch path).

Is 2) applicable only in scenarios where address configuration at the MN
takes longer than PBU/PBA signaling? If not, what other scenarios are
there? For 3), there is still an issue with in-transit packets being
sent towards old Proxy-CoA when the LMA changes path to the nMAG. These
packets can only be forwarded if there is some form of forwarding from
pMAG to nMAG; this needs to be mentioned. And, for 1), folks have
mentioned multiple times that LMA internal mechanisms can handle this;
although there is some good discussion in Appendix B (parts of which I
don't agree with), I am missing is a clear Applicability Statement in
the main part of the ID, perhaps following the Introduction.

My suggested text: 

X. Applicability
   
   There can be packet loss at the LMA when the BCE is updated with a
   new Proxy-CoA address and in-transit packets continue to arrive
   with old Proxy-CoA address. This can be handled internally at an
   LMA as implementation-dependent mechanism, e.g., by accepting
   packets for both Proxy-CoA addresses for a short period of
   time. However, some deployments may prefer an explicit signaling
   mechanism to avoid packet loss at LMA. In such cases, the protocol
   specified here is applicable.

   Similarly, there can be packet loss in the downlink when the PMIP6
   signaling and MN-internal mechanisms, such as address
   auto-configuration, cannot be synchronized. As compared to MIP6, a
   MN is not in charge of initiating Binding Update based on its
   interface readiness. This can cause packets to arrive at the new
   MAG when the MN may not have completed its address
   configuration. In such cases, packet loss can occur if the new MAG
   is unable to buffer incoming packets, especially on links where
   address resolution [RFC4861] takes place. The protocol specified in
   this document provides a better control of sequencing of events
   when it is desirable to avoid packet loss in the downlink. 

   The detailed comparison of static configuration versus the protocol
   specified in this document are specified in Appendix B. 
 
More comments.. (Sorry cut and paste makes it look longer)

Section 1:

   "In case the LMA prematurely
   forwards packets towards the mobile node's new interface, some
   packets may get lost or experience major packet delay."

RKo> It is not clear why LMA would prematurely forward packets. Under
   what conditions does PBU reach LMA when the interface on the MN is
   not set up? This unfolds only later where there can be PBU/PBA
   signaling ahead of address configuration.

Section 2.2

 o  Activation of a Transient Binding Cache Entry.  Initiates leaving
      the transient state of a Binding Cache Entry to become active.

RKo> You mean Transient to Active transition? The word Activation is in
general confusing..

   "In some active handover scenarios, it is necessary to prepare the
   handover target MAG prior to the completion of the link layer
   handover procedures.  Packets sent by the LMA to the target MAG
   before the completion of the link layer handover procedure will be
   lost or need to be buffered."

RKo> The normal sequence of operation is that the link-layer comes up,
   followed by the IP-layer signaling. If you mean this is not the
   case above, it helps to explain what you mean.

 " In some systems, the target MAG will be the recipient of uplink
   traffic prior to the completion of the procedure that would result in
   the PBU/PBA handshake.  These packets cannot be forwarded to the
LMA."

RKo> please explain why the packets cannot be forwarded to the LMA. Is
   it because the target MAG does not know about the LMA? LMA's BCE
   has not been updated yet? 

"During an intra-technology handover, some of the MN's uplink traffic
   may still be in transit through the pMAG.  Currently and as per
   PMIPv6 base protocol [RFC5213], the LMA forwards the MN's uplink
   traffic received from a tunnel only as long as the source IP address
   of the MN's uplink traffic matches the IP address of the mobile
   node's registered Proxy-CoA in the associated BCE.  As a result,
   packets received at the LMA from the MN's pMAG after the LMA has
   already switched the tunnel to point to the nMAG will be dropped."

RKo> This is a general problem with MIP6 and *MIP6 protocols.
Please see draft-mitsuya-keep-old-bc-00.txt and reference the document
   (as I have mentioned previously). We have discussed how this could be
handled 
as an implementation matter at the LMA.

Section 3.2

  "According to
   the PMIPv6 base protocol [RFC5213], the Access Authentication and the
   Proxy Binding Update (PBU) are triggered in the access network by the
   radio attach procedure, transparently for the MN.  In addition, a
   delay for the MN's new interface's address configuration is not
   considered in the handover procedure.  As a consequence, the
   immediate update of the MN's BCE after the PBU from the MN's nMAG has
   been received at the LMA impacts the performance of the MN's downlink
   traffic as well as its uplink traffic.  Performance aspects of
   downlink as well as uplink traffic during a handover between
   interfaces are analyzed in the subsequent subsections."

RKo> I am still struggling to see why nMAG would prematurely send PBU
to LMA without completing the link-layer and access authentication
procedures.

3.2.1

 In order to
                                           ^^^^ wait for 

 "Upon receiving a router advertisement from the new
   MAG, the MN can complete its address configuration and perform
   Duplicate Address Detection (DAD) [RFC4862] on the new interface.
   Only then the MN's new interface is ready to receive packets."

RKo> DAD may not be performed on all links, especially on links of
interest here.

   "Address configuration can take more than a second to complete.  If
   the LMA has already switched the mobile node tunnel to point to the
   nMAG and started forwarding data packets for the MN to the nMAG
   during this time, these data packets may get delayed or lost because
   the MN's new interface is not yet ready to receive data." 

RKo> Well, this is not fully drawn out. The packets that arrive at the
   nMAG will trigger ND on links where address resolution is
   necessary. The nMAG typically buffers the incoming packets until
   address resolution completes on such links. The size of the buffer is
   implementation-dependent. So, it is not entirely accurate to say
   that arriving packets will be lost.

    "However,
   delaying the PBU, which is sent from the new MAG to the LMA after the
   MN's new interface has attached to the network, is not possible, as
   the new MAG retrieves configuration data for the MN from the LMA
in.."

RKo> explain or reference what you mean by configuration data. Since
  nMAG already went to the LMA, it should have enough information
   about the MN already. Please differentiate this from what else that
   the nMAG needs from LMA which forces the PBU to be sent earlier.

RKo> I see below that HNP is such a parameter. Without HNP, the MN can
   still continue to use the previously assigned HNP, right? From MN's
   point of view, if it thinks that it's on the same default router,
   it continues to use the assigned/advertised prefix unless NUD
   [rfc4861] fails. For this, the MN needs to receive the RA from same
link-local 
   address as before. 

 "In case an access technology needs the MN's IP address or HNP to set
   up a radio bearer between an MN's IF2 and the network infrastructure,
   the responsible network component might have to wait until the nMAG
   has received the associated information from the LMA in the Proxy
   Binding Acknowledgment.  Delay in forwarding packets from the nMAG to
   the MN's IF2 depends now on the latency in setting up the radio
   bearer."

RKo> It is a bit strange that nMAG can determine LMA's address as well
as possibly MN-ID (e.g., MN-NAI) through some means but not complete
the access authentication.. Such scenarios need to be justified
clearly. 

3.2.2

"According to
   section 5.3.5 of the PMIPv6 base specification [RFC5213], the LMA
   will drop all subsequent packets being forwarded by the MN's pMAG due
   to the updated BCE, which refers now to the nMAG as Proxy-CoA.  Thus
   make-before-break handover is currently not supported by PMIPv6."

RKo> This is not unique to PMIP (As I mentioned earlier). The
   in-transit packets from PCoA will be dropped at the HA when the BCE
   is updated with NCoA. So, implementations must be able to handle
   this. 

4.1

 " During the transient state, the LMA accepts uplink packets from both
   MAGs, the pMAG and the nMAG, for forwarding.  To benefit from the
   still available downlink path from pMAG to MN, the LMA forwards
   downlink packets towards the pMAG until the transient BCE gets
   activated.  Such downlink forwarding characteristic is denoted as
   'Late path switch' (L). "

RKo> You mean by "activated" above, the transient BCE is no longer
   used? Because, I would expect the LMA to keep forwarding to the
   pMAG until it has a confirmed binding for nMAG. This would be the
   normal mode of operation, and if it is called 'Late path switch' in
   *MIP6, that's a cool phrase we have not used yet.

 "This specification considers an optional state during the activation
   of a transient BCE with a late path switch, which keeps the pMAG for
   some more time as forwarding entry in the transient BCE, solely to
   ensure forwarding of delayed uplink packets from the pMAG."
 
RKo> Late path switch previously refered to downlink packets.. Here it
   is 'solely' for delayed uplink packets?

B.1

 "Allowing the LMA to forward the received uplink traffic from the nMAG
   to the Internet is a violation of all mobility protocols which.."
                         ^^^^^^ ??

 "..require secure signaling exchange between the nMAG and the LMA
before
   forwarding such traffic to the Internet.  Otherwise, the LMA will be
   modifying the mobile node routing entry based on an unsecured data
   traffic packet coming from the nMAG."

RKo> This is not accurate. One can expect security association between
nMAG and LMA, and that can suffice for the LMA to accept uplink
packets from the nMAG. The above description needs to be reworded.  
Perhaps to something like "in deployments where pre-existing trust
between the nMAG and the LMA is not sufficient for the LMA to forward
uplink packets without first receiving the PBU from the nMAG, this
protocol provides a mechanism which can be useful."

   Therefore, this case can not be addressed by any statically
   configured information on the LMA.  

Rko> I do not agree.

B.2

However, using a statically configured information MAY not address
   all handoff circumstances over all types of access networks.

Rko> Why?

B.3.  Late Switching of Downlink Traffic to nMAG

   One main use case of transient bindings is the late switching of
   downlink traffic routing at the LMA.  This allows to perform IP
   mobility protocol signaling between nMAG and LMA independently of the
   link layer connectivity, e.g. for interfaces with time consuming link
   setup procedure or for a make-before-break handover between
   interfaces.

   LMA behaviour according to [RFC5213] does not allow for late path
   switching.  LMA according to [RFC5213] can only act upon the Handover
   Indicator and has no information on the time of completion of link
   layer setup.  Even if an LMA implementation would be configured to
   delay the path switching by a fixed time, which would violate
   [RFC5213], this would not lead to smooth handover performance but
   would even add latency to the handover.  Only additional signaling as
   provided by this document provides the information that late
   switching is applicable and enables a synchronization of the handover
   sequence, .i.e. the switching is adapted both to the finalization of
   the link between mobile terminal and nMAG and to the release of the
   link between mobile terminal and pMAG, whatever comes first.  Secure
   and stable handover performance is achieved.

RKo> well, late switching can also be addressed by extending the
buffering at the MAG. This should be pointed out here.

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 10 Aug 2009 21:45:01 -0700

Hi Marco,

> case radio access specific forwarding between radio access

Perhaps the following is sufficient for the abstract.

  This document specifies a mechanism which enhances Proxy Mobile
  IPv6 protocol signaling to support the creation of a transient
  binding cache entry which is used to optimize the performance
  of dual radio handover, as well as single radio handover.

You anyway talk about the details later on.
   
> True. Better to say: "MAGs can establish settings of a transient binding

That's fine.
   
> But we'll try to find better text.

Please do.

> the LMA provides the HNP. And according to the standard, the LMA is the

The text I quoted above talks about "the responsible network component" that
seems to be separate from the nMAG. What is this?

> option. So, we extend the

"extended" is fine.

> LMA identifies this. The actual lifetime of the activation state is a

Unless the MAG supplies the ATT mobility option, how can the LMA know what
access technology the MAG is attached to?

> clarification in the revision.

No, I was not proposing that. Just asking if there is an implicit assumption
here that the LMA knows what access technologies the MN is handing between.

> and we received comments some time ago to take this decision out of the LMA.

Ok, its fine then.
  
> of the specification, as it's not important for the current protocol.

Please do that.

Ok.

Vijay

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 12 Aug 2009 18:25:08 +0200

Hi Rajeev,

thanks for your review. Please see some clarifying feedback to
your questions inline.

marco

> primarily about multi-radio handovers. 
The applicability to single-radio handover is clearly described. The 
protocol
is the same. So why should the protocol specification then limit to single
radio handover?

> packets to pMAG (and when to switch path).
I don't see three parts, but maybe you refer to the problem statement 
section.

> there?
delay due to radio bearer setup, as covered by the problem statement

>  For 3), there is still an issue with in-transit packets being
> pMAG to nMAG; this needs to be mentioned.
this is only a problem in case of single radio handover, where we focus 
applicability
to radio technologies, which provide such forwarding. You don't need 
forwarding between
MAGs, but forwarding between radio access networks (level below MAGs) is 
sufficient.
Such use case is described in A.1.

>  And, for 1), folks have
thath's why we included a stement about implementation-specific solutions
in the appendix.

> the main part of the ID, perhaps following the Introduction.
We cannot assume the existence of such implementation specifics, as they
are not part of the standard. As tehy are also not part of this 
protocol, I feel that it's
more suitable to have this statement in the appendix.

>    specified here is applicable.
That's what B.2 decribes.

>    address resolution [RFC4861] takes place.
This description is covered in the problem statement...

>  The protocol specified in
..and this is part of the protocol sepcification section. I don't see an 
advantage to
repeat these things in an additional paragraph.

>    signaling ahead of address configuration.
PBU/PBA is used to retrieve the HNP from the LMA. So, nMAG can send the
RtAdv with the prefix to the MN after that step. And the MN can perform 
address
configuration only after having receive dthe HNP. That's where the order 
comes from.

> RKo> You mean Transient to Active transition? The word Activation is in
The term has been introduced at the beginning and in the terms section. 
If you know what's behind,
it should be clear throughout the document. We prefer having a short 
description of this state change
rather than writing always about transition between state A and state 
B... Did not receive complaints
so far.

>    case above, it helps to explain what you mean.
Yes, good point. Maybe we need to add 1-2 more sentences here and maybe
also a reference to radios where this problem appears. Or we refer to 
the use
case A1, where we have more text about this.

>    has not been updated yet? 
Yes, same as above, maybe we have to spend a bit more text about this 
issue to
allow understanding.

> as an implementation matter at the LMA.
Yes. And Appendix B.2 describes this. However, the protocol has this feature
implicit. So, no need to implement this as separate mechanism.

> to LMA without completing the link-layer and access authentication
Maybe a misunderstanding, but the text does not say that the nMAG sends 
the PBU before
completing link-layer and access authentication. Let me check again.

>    needs to send a router solicitation and awaits a router
Ok, thanks for the proposal.

> RKo> DAD may not be performed on all links, especially on links of
True, so we could include "may" here, as there is still the possibility that
DAD will or has to be performed. Just for curiosity: What are links of 
interest?

>    that arriving packets will be lost.
depends on the bitrate of the data stream. ND buffer has a default size 
of 3.
We evaluated this even with larger buffer sizes and the packet loss was very
large... even without DAD...And even if you go for huge buffers (costs?)
the MN still suffers from jitter.

> RKo> explain or reference what you mean by configuration data.
The HNP

>  Since
>    about the MN already.
Not sure what you mean with "the nMAG went to the LMA". Text talks about the
first PBU for the MN of interest. Information comes to the nMAG with the 
PBA.

>  Please differentiate this from what else that
Not sure the MN really thinks. You can implement a lot on the MN, true. 
But according to the
standard, it's still the LMA that assigns the HNP. The MN should wait 
for the assigned HNP
before setting up an IP address on the MN's new interface.

> the access authentication.. Such scenarios need to be justified
the text does not describe an issue with access authentication. It 
refers to the
delay caused by setting up the radio bearer.

>    is updated with NCoA. So, implementations must be able to handle
Yes, they could and we say that clearly in the Appendix. But as said, 
there is no
need as it comes with the transient BCE extension.

>    *MIP6, that's a cool phrase we have not used yet.
Activation as we introduced in the spec means: "Initiates leaving the 
transient state of a
Binding Cache Entry to become active." Normal operation would be to 
switch the path
after the PBU/PBA handshake, which causes the problems we describe in 
the beginning
of the document. That's why the protocol spec allows delaying the path 
switch.
That's where "Lats path switch" comes from. If you find it's a cool 
term, even better. More
important is that it's clear what's behind.

>    is 'solely' for delayed uplink packets?
The pMAG is entered as Proxy-CoA in the MN's BCE. It's used for uplink 
and/or downlink.
If you want to forward packets (in either direction), the entry must be 
there. Hence, in the
section you refer to it's meant for uplink packets.

> protocol provides a mechanism which can be useful."
Will think about it..

>    all handoff circumstances over all types of access networks.
Static configuration is always vague. How to dimension? The described 
protocol
solves this issue and keeps the state as along as it's needed.

> buffering at the MAG. This should be pointed out here. 
Please see above and in the problem statement.

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 12 Aug 2009 18:45:20 +0200

Hi Vijay,

> You anyway talk about the details later on.
Ok, done.

> seems to be separate from the nMAG. What is this?
Ok, got it. We thought about a component, which may be separate from the 
MAG,
for example to set up a radio bearer. I agree that this is confusing and 
not relevant here
if the function is on the MAG or somewhere else. Will re-phrase the 
sentence.

> access technology the MAG is attached to?
Relevant is to detect inter-technology handover, and that could be done 
based on
the ATT option, HI option or other means, including administrative 
configuration
on the LMA in association with each MAG. That could be sufficient for 
taking the
decision to use the activation state. If the LMA needs to know details 
about the
radio technologies behind (well, better 'below') a MAG, the ATT option helps
or even administrative configuration on the LMA.

> here that the LMA knows what access technologies the MN is handing between.
Ok, we can add an example how to find this information on the LMA.

Thanks,
marco

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 12 Aug 2009 14:01:28 -0700

Hi Rajeev,

>    [rfc4861] fails. For this, the MN needs to receive the RA from same

The nMAG might need to talk to the LMA, through PBU and PBACK, to figure 
out which link local address to use for the router advertisement.

Vijay

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Wed, 12 Aug 2009 17:05:44 -0400

Hi,

> >     link-local address as before. 
> 
> The nMAG might need to talk to the LMA, through PBU and 
> PBACK, to figure out which link local address to use for the 
> router advertisement.
> 

Even when the link-local address for the MAG is pre-configured? Probably
not..

-Rajeev

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 12 Aug 2009 14:07:54 -0700

Hi Marco,

> B... Did not receive complaints

I also found the term "activating a transient BCE" very confusing. It is 
hard to interpret it to mean that the transient BCE is becoming a normal 
BCE. But since you had this in the terminology section, I didn't 
complain. :)

But if you can find some better text, it would be great. One option 
would be rephrase "activating a transient BCE"  to "converting the 
transient BCE to active BCE" throughout the text. I leave it up to you.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 12 Aug 2009 14:11:28 -0700

> Even when the link-local address for the MAG is pre-configured? Probably

Thats why I used "might" in my email. :) the PMIPv6 specs do talk about 
both options, pre-configuring the link local address on all MAGs and 
storing the link local address on the LMA with each MAG fetching it from 
the LMA.

FWIW, I think pre-configuration is going to be painful, especially when 
the PMIPv6 domain spans multiple access technologies or multiple 
administrative domains. The second option, where the link local address 
is stored on the LMA, is more practical, I think.

Vijay

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Wed, 12 Aug 2009 17:18:53 -0400

> storing the link local address on the LMA with each MAG 

Yes.

> is stored on the LMA, is more practical, I think.

It can be both ways.. You do have to configure a lot of things, and
configuring the link-local address of each of your MAGs from CLI may be
okay.

Back to my comment, the current description is incomplete. In
deployments where the MAG link-local address is pre-configured, I don't
see why the nMAG is going to the LMA.. I know it is described to fetch
HNP, but from handover point of view, it is sufficient that the MN gets
an RA from the "same" router (i.e., from the same link-local address).
Am I missing anything here?

-Rajeev

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Wed, 12 Aug 2009 18:08:40 -0400

Hi Marco,

A concern is the lack of proper description of the applicability of this
protocol. 
Whereas Appendix B is good, I would like to see a clear statement about
what problem this protocol addresses and where it is applicable.

Please see below..

>> So, I suggest the scope to clearly state that 
>> the draft is primarily about multi-radio handovers.
>>   
> The applicability to single-radio handover is clearly 
> described. The protocol is the same. So why should the 
> protocol specification then limit to single radio handover?
> 

My point is to state that the primary focus is multi-radio, but also
indicate that it may be applicable to single-radio handovers.

Most part of the draft deals with multiple interfaces. There is a
relatively small section on single-radio handovers, and I do not think
that it is comprehensive.

> I don't see three parts, but maybe you refer to the problem 
> statement section.

Hmm.. I wasn't referring to any particular section but a high-level
summary of the protocol.
If it does more than this please state.

> 
> > Is 2) applicable only in scenarios where address configuration at
the 
> > MN takes longer than PBU/PBA signaling? If not, what other scenarios

> > are there?

If there is delay due to radio bearer set up, why is the MAG sending PBU
prematurely?
Perhaps you have answer below..
 
> >  For 3), there is still an issue with in-transit packets being sent 
> > towards old Proxy-CoA when the LMA changes path to the nMAG. These 
> this is only a problem in case of single radio handover, 
> where we focus applicability to radio technologies, which 
> provide such forwarding. You don't need forwarding between 
> MAGs, but forwarding between radio access networks (level 
> below MAGs) is sufficient.

I would at least state this when you first mention how in-transit
packets are handled, and refer to Appendix for the details.

> thath's why we included a stement about 
> implementation-specific solutions in the appendix.

I would like to have a clear statement in the main part of the draft.
We discussed this at the SFO meeting. 

> We cannot assume the existence of such implementation 
> specifics, as they are not part of the standard. As tehy are 
> also not part of this protocol, I feel that it's more 
> suitable to have this statement in the appendix.
> 

Well, there are people here saying this is feasible! Appendix is good,
but the main part of the ID must have a clear statement. When there are
folks who believe that implementation may be sufficient, it needs to be
properly represented.

> That's what B.2 decribes.

Okay, but I would like to see it upfront.

> ..and this is part of the protocol sepcification section. I 
> don't see an advantage to repeat these things in an 
> additional paragraph.
> 

I am asking for a brief section following the Introduction. Not whether
Appendix is good enough or not (for which I have provided separate set
of comments).

> PBU/PBA is used to retrieve the HNP from the LMA. So, nMAG 
> can send the RtAdv with the prefix to the MN after that step. 
> And the MN can perform address configuration only after 
> having receive dthe HNP. That's where the order comes from.
> 

As I pointed out elsewhere, you don't need HNP. The MN only needs to
know it is on the same router for handover purposes. The way it is
currently defined, it looks like the order described is the way it is
supposed to work, which I am questioning.

> > RKo> You mean Transient to Active transition? The word Activation is

> > RKo> in general confusing..
> >   
> it should be clear throughout the document. We prefer having 
> a short description of this state change rather than writing 
> always about transition between state A and state B... Did 
> not receive complaints so far.
> 

Well, you have at least Vijay now on the confusing side. It is up to you
if you would like to improve the readability..

> Yes, good point. Maybe we need to add 1-2 more sentences here 
> and maybe also a reference to radios where this problem 
> appears. Or we refer to the use case A1, where we have more 
> text about this.

Ok, I would like to see this..

> Yes, same as above, maybe we have to spend a bit more text 
> about this issue to allow understanding.

Ok.

> >    (as I have mentioned previously). We have discussed how this
could 
> > be handled as an implementation matter at the LMA.
> >   
> Yes. And Appendix B.2 describes this. However, the protocol 
> has this feature implicit. So, no need to implement this as 
> separate mechanism.
> 

I don't follow.. Are you saying that to handle the uplink packet loss at
LMA, we have to implement this protocol? I hope not.. I am agreeing to
this document assuming that the scope is clearly defined. 

Are you agreeing to reference the ID above?

> > Section 3.2
[snip]
> Maybe a misunderstanding, but the text does not say that the 
> nMAG sends the PBU before completing link-layer and access 
> authentication. Let me check again.

Please do so.

> True, so we could include "may" here, as there is still the 
> possibility that DAD will or has to be performed. Just for 
> curiosity: What are links of interest?

Well, you should include ".. The MN can configure address configuration
and perform DAD if necessary.."

P-P links are not using DAD. 

> depends on the bitrate of the data stream. ND buffer has a 
> default size of 3.
> We evaluated this even with larger buffer sizes and the 
> packet loss was very large... even without DAD...And even if 
> you go for huge buffers (costs?) the MN still suffers from jitter.

How many packets arrive from LMA is a function of how soon you send PBU
to the LMA.

You need to be clear about this. There are loose ends here: why is the
PBU being sent in advance? The reason quoted (i.e., retrive HNP) is not
clear to me; it is perhaps sufficient to get an RA from the same
link-local address of the router.

> Not sure the MN really thinks. 

:-) Not in the AI sense of course.

> You can implement a lot on the MN, true. 
> But according to the
> standard, it's still the LMA that assigns the HNP. The MN 
> should wait for the assigned HNP before setting up an IP 
> address on the MN's new interface.

I am not referring to anything specific to a MN that's not a standard.

All I am saying is that it can assign the same prefix it already has
since it does not detect a change of router.

> the text does not describe an issue with access 
> authentication. It refers to the delay caused by setting up 
> the radio bearer.
> 

Okay. However, you still did not explain why the "acces technology"
needs HNP.

[snip]
> Yes, they could and we say that clearly in the Appendix. But 
> as said, there is no need as it comes with the transient BCE 
> extension.
> 

This is where I am having a problem I think. I know I can do this
without transient BCE.
You seem to be saying: "may be but you don't have to". That's a good
seeling point, but we are beyond that now, don't you think? :-)

> > B.1
[snip]
> > protocol provides a mechanism which can be useful."

Okay, I would like to see this clearly mentioned.

> Please see above and in the problem statement.

Well, I would like to see better description of 

A) why there is premature update of PBU at the LMA.
B) why HNP is necessary and not an RA from the same link-local address
C) why the radio bearer set up takes more time while PBU is already sent
out.

Thanks,

-Rajeev

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 17 Aug 2009 06:35:08 -0500

Hi,
inline.

Regards,
Ahmad

> It is generally well-written. 
[Ahmad]
Hmm..... That's good.

> I do have several comments. 
> 
> First, the draft scope. It is claimed that it handles 
> intra-technology (i.e., single radio) handovers. But, the 
> draft is primarily about multi-interface handovers. There is 
> a sub-section 3.1, but the focus is mostly on multi-interface 
> handovers (I do have several comments on 3.1 below). So, I 
> suggest the scope to clearly state that the draft is 

[Ahmad]
I think the scope of this draft and work item have been discussed many
times and agreed upon. Let us move on.

> 
> Second, there are three main parts in this ID: 1) handling 
> uplink packets at the LMA during transition from one i/f to 
> another, 
> 2) handling downlink packets arriving at the nMAG 
> and, 3) forwarding packets to pMAG (and when to switch path).
> 
[Ahmad]
See Marco response.

> Is 2) applicable only in scenarios where address 
> configuration at the MN takes longer than PBU/PBA signaling? 
> If not, what other scenarios are there? For 3), there is 
> still an issue with in-transit packets being sent towards old 
> Proxy-CoA when the LMA changes path to the nMAG. These 
> packets can only be forwarded if there is some form of 
> forwarding from pMAG to nMAG; this needs to be mentioned. 
> And, for 1), folks have mentioned multiple times that LMA 
> internal mechanisms can handle this; although there is some 
> good discussion in Appendix B (parts of which I don't agree 
> with), I am missing is a clear Applicability Statement in the 
> main part of the ID, perhaps following the Introduction.
> 
> My suggested text: 
> 
> X. Applicability
>    

[Ahmad]
We have discussed this many times and if you still do not understand any
specifics, you always can seek clarification to what you do not
understand. IMO, this is nothing but a waste of time and a recipe for
delaying this draft which is NOT acceptable. Appendix B clearly captures
the applicability of the usecases of this draft. If you have anything to
improve this appendix, you are welcome to provide your CLEAR COMMENTS.
Second, if you have a problem understanding the difference between the
different cases, you probably can refer to the many times this have been
discussed on the mailing list. The last one, my clarification response
to Vijay's clear comments on Appendix B.

>    specified in this document are specified in Appendix B. 
[Ahmad]
Please see Marco's responses.
  
>    case above, it helps to explain what you mean.
[Ahmad]
May be you can understand this more if you think of what PFMIP does in
preparing the lateral tunnel between MAGs. Instead, this case do the
preparation with the LMA directly. May be looking/reading at some of the
referenced documentation in the draft where this case is relevant would
help.

>    the PBU/PBA handshake.  These packets cannot be forwarded 
> to the LMA."
> 

[Ahmad]
This is a basic principle in all IP mobility protocols that is mentioned
in the second paragraph of the Introduction. We felt that there is no
need to mention this again as it is obvious, however, if it is NOT clear
to the community, we can repeat the same text here.

>    (as I have mentioned previously). We have discussed how 
> this could be handled as an implementation matter at the LMA.
>
[Ahmad]
Your comments is confusing. Every time you use this mentioning
differently! Your previous mentioning reference all cases. You now,
refer to your mentioning under this case. We mentioned and documented
several times that we have NO problem with that for this case. This is
already documented under Appendix B. 

The main thing: Initially all of this was part of the document body and
based on the wg feedback, we moved it to the Appendix.

> to LMA without completing the link-layer and access 
> authentication procedures.
[Ahmad]
Where does it say that the nMAG will send a prematurely PBU?

>    the new MAG retrieves configuration data for the MN from 
> the LMA in.."
> 
>    [rfc4861] fails. For this, the MN needs to receive the RA 
> from same link-local 
>    address as before. 
> 
> 
> as possibly MN-ID (e.g., MN-NAI) through some means but not 
> complete the access authentication.. Such scenarios need to 
> be justified clearly. 
> 
> 3.2.2
> 
> "According to
[Ahmad]
This funny.
On one hand, you mentioned that this can be addressed via some static
configuration. NOW: you say that application should be able to handle
this. Which point you want to make? Also, everyone knows that
application can handle missing packets, but, I thought that optimized
handover is for application that delay/(missing packets) sensitive.

>  "..require secure signaling exchange between the nMAG and 
> the LMA before
> nMAG and LMA, and that can suffice for the LMA to accept 
> uplink packets from the nMAG. 
[Ahmad]
That is WRONG understanding! MAY be you need to read what has been
posted on this mailing list before. Also, Where is that DOCUMENTED? Or
that your own understanding and interpretation? If that is the case,
there is no problem, we can move forward. I suggest that you revisit
your understanding of IP mobility concepts and the REQUIRED security
between the MAG and LMA for PMIPv6.

> The above description needs to 
> be reworded.  
> Perhaps to something like "in deployments where pre-existing 
> trust between the nMAG and the LMA is not sufficient for the 
> LMA to forward uplink packets without first receiving the PBU 
> from the nMAG, this protocol provides a mechanism which can 
> be useful."

[Ahmad]
NO. That is NOT Correct. We go with the default Security between the MAG
and the LMA as per RFC5213. MAY be you have different deployments in
MIND, that is the exception and we do NOT need to document that here.

>    configured information on the LMA.

[Ahmad]
See above. I guess that is your opinion which I believe is false.

>    all handoff circumstances over all types of access networks.

[Ahmad]
You NEED to READ!

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 17 Aug 2009 14:16:24 -0700

Hi Ahmad,

Lets keep the discussion just technical please. I am sure there is a better
way to respond than just saying "you don't understand" or you need to read".

Lets try to come up with some text that says that the problem can be solved
with implementation specific mechanisms at the LMA and buffering at the nMAG
when the L2 is not setup. But this document proposes a mechanism that
addresses the problem better.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 17 Aug 2009 17:39:12 -0500

Hi Vijay,
Sorry! as you said should stick with the technical discussion.

Please see inline.

Regards,
Ahmad

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Monday, August 17, 2009 4:16 PM
> To: Muhanna, Ahmad (RICH1:2H10); Koodli, Rajeev; [email-masked]
> Cc: [email-masked]
> Subject: Re: [Mipshop] Review of Transient Binding Spec
> 
> Hi Ahmad,
> 
> Lets keep the discussion just technical please. I am sure 
> there is a better way to respond than just saying "you don't 
> understand" or you need to read".
> 
> Lets try to come up with some text that says that the problem 
> can be solved with implementation specific mechanisms at the 
> LMA 
[Ahmad]
There are two folds to this problem, uplink traffic coming from pMAG as
I confirmed on your latest email can be addressed via a static
configuration. Receiving uplink traffic from the nMAG before a PBU can
not be addressed via a static configuration. So some text to accurately
reflect both cases is fine with us, I believe.

> and buffering at the nMAG when the L2 is not setup. But 
> this document proposes a mechanism that addresses the problem better.
> 
> Vijay
> 
>

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 18 Aug 2009 10:13:07 +0200

Hi Vijay,

> addresses the problem better.
But this is what we extensively discuss in the appendix. What we could 
do is add a reference to
the appendix in the introduction. But what you propose is confusing: If 
you write that the problem can
be solved with implementation specific mechanisms, then you pretend that 
"the problem is solved",
which is not true. And then you cannot write that this protocol 
addresses the problem better. Such
statement is confusing to any reader. The pretty much detailed 
evaluation "protocol vs. static
configuration" is in the draft. Cannot remember any spec who does this. 
So, we addressed a WG
member's comment to include this. I think we can move forward.

If we need to add a reference to the appendix in the introduction, I 
would not say that static implementation
can solve "the" problem. Some issues from the problem space may be 
addressed, but with a 'one solution
for all situations' approach. The drawback of such static approach is 
discussed in the appendix. So, a reference
should be ok.

The document will be RFC Experimental first. Folks can implement and can get
convinced about the benefit:complexity-ratio. I do not see any value in 
adding a misleading note to the
spec that folks should not implement this as you may solve it by static 
implementation.

marco

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 18 Aug 2009 12:09:29 +0200

Hi Vijay,

ok, no problem, I can change this, even though we use the term 
throughout the document.
Will be in the update .

marco

Vijay Devarapalli schrieb:
>> The term has been introduced at the beginning and in the terms 
>> section. If you know what's behind,
> I also found the term "activating a transient BCE" very confusing. It 
> is hard to interpret it to mean that the transient BCE is becoming a 
> normal BCE. But since you had this in the terminology section, I 
> didn't complain. :)
>

---

From: Marco Liebsch <[email-masked]>
Date: Tue, 18 Aug 2009 12:16:58 +0200

Koodli, Rajeev schrieb:
>  
>
>   
>>> Even when the link-local address for the MAG is pre-configured?
>>>       
> Probably
>   
>>> not..
>>>       
not if the interface changes and needs configuration, this includes 
reception of
the HNP, which comes from the LMA. We could add a note and examples of
configuration parameters, which are retrieved from the LMA.

marco

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 19 Aug 2009 22:13:55 -0700

Hi Marco,

This is not about FMIPv6. You can always setup a tunnel between the two MAGs
for forwarding packets. Think S103 interface in the 3GPP architecture. In
addition in turn on buffering on the nMAG if the LMA forwards the packets
and the MN has not attached yet at L2. And you can definitely configure an
LMA to receiving uplink packets from the pMAG and nMAG for a short duration
during a handover. 

All this can be achieved without using FMIPv6 or PFMIPv6.

Why would the following text reduce the value of the transient binding cache
extension?

   The problem that the transient binding cache mechanism is trying to
   address can also be achieved through implementation-specific mechanisms
   on the LMA, such a configuration on the LMA to accept uplink packets
   both from the pMAG and the nMAG during a handover and through buffering
   at the nMAG when the downlink packets starting arriving at the nMAG and
   the L2 link between the MN and nMAG is not setup yet. However, dynamic
   solutions by means of the proposed extension in this document is needed
   to optimize the performance for a variety of handover situations and
   different radio characteristics. See Appendix B for a more detailed
   discussion on this.

> spec that folks should not implement this as you may solve it by static

On the contrary, I don't see the above text misleading a reader. It only
says that there are other options (which is true), but the protocol
extension as specified in the draft make sense. For a detailed discussion,
see the appendix.

Vijay

---

From: Marco Liebsch <[email-masked]>
Date: Thu, 20 Aug 2009 10:28:02 +0200

Hi Vijay,

> All this can be achieved without using FMIPv6 or PFMIPv6.
So, you set up the tunnel by hand? Anyway, we never said that other 
handover solutions
should not be used as they're not beneficial, but we said, that not in 
any case you can
assume that the two MAGs can set up a tunnel by means of secure signaling.
Also here, transient binding has some advantages.

>    different radio characteristics. See Appendix B for a more detailed
well, if you propose to write that by implementation "The problem .... 
can be achieved...",
maybe you're right that this makes the problem worse.

> extension as specified in the draft make sense. For a detailed discussion,
The text is misleading and pretends that the problem can be solved by
static configuration. Yes, there are other options, which address some of
the problems we talk about, at the costs of configuration complexity and
having a "one solution for all handover situations" approach, which results
in possibly even worse performance. This does not solve the problem. And
this is what the proposed text says. No protocol specification starts 
this way.
Any fast handover mechanism for IP mobility could solve the problem
with less signaling if you , for example, administratively set up a list of
globally adjacent ARs and N-cast packets during a handover phase...
No protocol would write this, as it deviates from the original idea.
The current version of the draft covers an analysis of the
drawbacks with solving the handover problems with static configuration.
This has been added to address a comment we received. We should proceed
now. If really more text needs to be added to the Introduction, we propose
the following for the update:

"Some implementation specific solutions, such as static configuration
and introducing some delays, may help to reduce some issues addressed in
this draft, see Appendix B. However, dynamic solutions by means of the
proposed protocol operation is needed to optimize the performance for a
variety of handover situations and different radio characteristics."

marco

---

From: Marco Liebsch <[email-masked]>
Date: Thu, 20 Aug 2009 11:52:04 +0200

Vijay, Rajeev,

just to avoid further comments after having changed this. You proposed

 >But if you can find some better text, it would be great. One option 
would be
 >rephrase "activating a transient BCE"  to "converting the transient 
BCE to active BCE"
 >throughout the text. I leave it up to you.

"active BCE" is not a common term as well. But if you think this is 
sufficiently understood
we adopt this. We could also introduce the term "active BCE" as regular 
BCE according to
RFC5213. But then I don't see a big difference to introducing "activation"..

marco

Marco Liebsch wrote:
>>> rather than writing always about transition between state A and 
>>> state B... Did not receive complaints
>>> so far.
>>

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Mon, 24 Aug 2009 04:12:18 -0400

Hi Marco,

Rajeev:> Agree with Vijay.

Rajeev:> Well,  it is meant to say the "..solution to the problem can be achieved..", right?

Rajeev:> implementations at LMA and nMAG can address the problems. It is fair to argue that there are benefits by having a protocol such as this. However, it is necessary to state what is feasible without the protocol.

Rajeev:> I don't recall anyone bringing this up.. We could have discussed it.

Rajeev:> The text above talks about advanatages/disadvantages. I would go with Vijay's proposed text. 
Besides, it is not clear to say it is "..needed" for an Exp protocol. 
 
-Rajeev

marco

---

From: Marco Liebsch <[email-masked]>
Date: Mon, 24 Aug 2009 13:46:29 +0200

Hi Rajeev,

> Rajeev:> Well,  it is meant to say the "..solution to the problem can be achieved..", right?
I read this differently.

> Rajeev:> implementations at LMA and nMAG can address the problems. It is fair to argue that there are benefits by having a protocol such as this. However, it is necessary to state what is feasible…
This is exactly what the proposed text below says: "Implementation 
specific solutions can address the problems".
But I revised again based on your comment below (please see below)

> Rajeev:> I don't recall anyone bringing this up.. We could have discussed it.
Possibly it has not been brought up because nobody expects such text in 
a protocol solution.
But it's the same here: It addresses the problem, but does not solve all 
problems as the
protocol does.

> Besides, it is not clear to say it is "..needed" for an Exp protocol. 
Ok, will revise again. But since you point to the status Expeimental: 
Even more weird to add such
confusing text in the core part of a specification. As you said, it's 
experimental. Folks
can implement and evaluate it. If there are alternative approaches, such 
as playing with
implementation specifics and static configuration, well, folks can do 
and compare.
Alternative solutions and their performance, this is usually what 
conference papers
write about..

Ok, here is the revised proposal:

"Some implementation specific solutions, such as static configuration
and introducing some delays, may help to reduce some issues addressed in
this draft, see Appendix B. However, a dynamic solution by means of the
proposed protocol operation helps to optimize the performance for a
variety of handover situations and different radio characteristics."

marco