Re: [Mipshop] transient binding draft update

["Ahmad Muhanna" <amuhanna at nortel.com>]

> -----Original Message-----
> From: mipshop-bounces at ietf.org 
> [mailto:mipshop-bounces at ietf.org] On Behalf Of Vijay Devarapalli
> Sent: Friday, September 04, 2009 12:55 AM
> To: Marco Liebsch; Mipshop
> Subject: Re: [Mipshop] transient binding draft update
> 
> Hi Marco,
> 
> On 9/1/09 1:56 AM, "Marco Liebsch" wrote:
> 
> > *  Added note about static implementation specific approach 
> and reference
> >    to Appendix B to the Introduction.
> >
> >    "..Some implementation specific solutions, such as 
> static configuration
> >    and introducing some delays, may help to reduce some 
> issues addressed
> >    in this draft, which is discussed in Appendix B.  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."
> 
> Both "static configuration" and "some delays" are vague. Can 
> we replace the above with the following?
> 
>    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. 
[Ahmad]
I am sure Marco will answer to this too, but let me jump in for a
second. This is not correct. It seems to me that there is something
missing in here! Probably misunderstanding of the usecases that tBCE
draft is trying to address. Please see more comments below.

> 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.
> 
> > * revised last two paragraphs of appendix B.1
> >
> >    "...Allowing the LMA to forward the received uplink 
> traffic from the nMAG
> >    to the Internet while the MN BCE points to the pCoA hosted at the
> >    pMAG 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's routing entry based on an unsecured 
> data traffic
> >    packet coming from the nMAG.
> 
> The "static configuration" at the LMA actually starts 
> accepting uplink packets from the nMAG only after receiving a 
> PBU from nMAG. 
[Ahmad]
This actually may explain why you insist on the text above under the
previous paragraph. It is very interesting! First of all, is this a new
usecase that you would like the transient BCE draft to address?! IMO, it
is a little late but we can consider that if we understand the usecase. 

Though, it will be helpful, if you take us through the details of this
usecase and what you are trying to optimize and achieve by using the
tBCE in here. Also, whether it is a new addition on top of RFC5213?


> What the "static configuration" enables is for 
> the LMA to receive uplink packets from the pMAG for a short 
> duration even through the BCE points to the nMAG. So can we 
> re-word the above accordingly?
> 
> I won't have email access until next Wednesday. If you agree 
> with the above two changes, please go ahead and submit a 
> revised draft.
> 
> Vijay
> 
> 
> >
> >    Therefore, this case can not be addressed by any statically
> >    configured information on the LMA.  On the contrary, a secure
> >    signaling using Transient Binding option as detailed in 
> this draft is
> >    required to create a transient state for the mobile node 
> BCE at the
> >    LMA.  This transient state will allow a temporary 
> routing entry of
> >    the mobile node to point to the nMAG Proxy-CoA."
> > 
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Mipshop mailing list
> > Mipshop at ietf.org
> > https://www.ietf.org/mailman/listinfo/mipshop
> 
> 
> 
>