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

[<[e-mail]>]

Hi Behcet,

On 7/23/12 3:03 PM, "ext Behcet Sarikaya" <[e-mail]> wrote:

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

I get that.. But my point is this is not needed in the context of flow
mobility for PMIP6.

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

I don¹t see a shortcoming in the WG I-D in terms of solving the problem of
flow switching.
Please elaborate what you see as an issue and a scenario that you believe
cannot be achieved as per the current WG I-D.

-Raj

>
>Hope this clarifies.
>
>Behcet