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

[<[e-mail]>]

Inline: 

On 7/26/12 2:06 PM, "ext Behcet Sarikaya" <[e-mail]> wrote:

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

You keep tossing these snippets of text and references and hoping that it
explains the question. It does not.

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


I disagree. If you look at Scenario 2 in Sec 3.2.2 of the WG I-D
(draft-ietf-netext-pmipv6-flowmob-04.txt), you will see the binding cache
details. 
Hence I do not see what specific problem your I-D is solving.

-Raj


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

I would prefer that you explain the problem on the ML first.

-Raj

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