Re: [netext] Comments on I-D: draft-sarikaya-netext-fb-support-extensions

[Behcet Sarikaya <[e-mail]>]

Hi Basavaraj,

On Mon, Jul 23, 2012 at 12:11 PM,  <[e-mail]> wrote:
>
> A few comments:
>
> 1. I am not convinced with the problem statement specified in the I-D. The
> WG flow-mobility I-D (draft-ietf-netext-pmipv6-flowmob) is intended to
> provide a solution that is similar (albeit without UE interaction) to what
> exists for MIP6.
>
> 2. If the UE is assigned different HNPs to its interfaces as a result of
> connecting via more than one interface, the current assumption is that
> there is no switching of flows between those interfaces. The only case
> where we enable flow mobility is when the UE has a single HNP assigned to
> it but connected via multiple interfaces (possible via the use of
> logical-interface at the UE).
>
> 3. The I-D does not explain how flow switching would work if the MN has
> different HNPs assigned to its interfaces.The extensions to PMIP6
> signaling with the new flags to support flow mobility can wait until you
> have a clear explanation for the same.

The problem that my I-D addresses is better explained in (from 3rd
paragraph of Section 3, a little bit annotated):

In base Proxy Mobile IPv6, i.e. RFC 5213, LMA treats each interface
independently of
   the other interface(s) MN may have and tries to provide mobility
   support for each interface.  LMA does not manage bindings from
   different interfaces of the mobile node in an integrated fashion.  So
   LMA can not be in control of moving the flows in between interfaces.

So a binding cache management similar to RFC 5648, i.e. the MCoA work
in MIPv6 is needed and this is what my I-D comes up with.

Reading Carlos' I-D, version 04, he comes close to it, but specific
modifications to the binding cache are not spelled out and they should
be using draft-sarikaya-netext-fb-support-extensions-02 or
draft-sarikaya-netext-fb-support-extensions-02 should be normative
reference.

Hope this clarifies.

Behcet