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

[Behcet Sarikaya <[e-mail]>]

Hi Basavaraj,

On Wed, Jul 25, 2012 at 4:40 PM,  <[e-mail]> wrote:
>
> 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.

This is from RFC 5213, Sec. 5.4 on multihoming support:

When a mobile node connects to a Proxy Mobile IPv6 domain through
      multiple interfaces for simultaneous access, the local mobility
      anchor MUST allocate a mobility session for each of the attached
      interfaces.  Each mobility session should be managed under a
      separate Binding Cache entry and with its own lifetime.


This is the problem. Without modifying the way mobility sessions are
handled it is impossible to do any flow mobility among multiple
interfaces.

draft-sarikaya-netext-fb-support-extensions-02 offers a solution and
to my knowledge the only solution to this problem.

Maybe I should explain the problem better in the next version of my draft.

In fact some implementers contacted me offline and then said the first
thing they did was to implement
draft-sarikaya-netext-fb-support-extensions-02 and then
draft-ietf-netext-pmipv6-flowmob.
I hope this clarifies and nevertheless, thanks for your comments.

Regards,

Behcet