Re: [Mipshop] Review of Transient Binding Spec

[Marco Liebsch <liebsch at nw.neclab.eu>]

Hi Vijay,

Vijay Devarapalli wrote:
> 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.
>   
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.

> 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.
>   
well, if you propose to write that by implementation "The problem .... 
can be achieved...",
maybe you're right that this makes the problem worse.


> On 8/18/09 1:13 AM, "Marco Liebsch" wrote:
>
>   
> > 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.
> >     
>
> 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.
>   
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



> Vijay
>
>