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

[Behcet Sarikaya <[e-mail]>]

Hi Basavaraj,

Please see inline.

On Fri, Jul 27, 2012 at 12:08 PM,  <[e-mail]> wrote:
> 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.
>

Sorry, I could not see any reference to the binding cache in Sec. 3.2.2 :-).
Maybe you meant Sec. 3.2.1?

It seems that Sec. 3.2.1 is ignoring the problem in binding cache
management from RFC 5213, i.e. each entry corresponds to a different
mobility session and therefore independent, i.e. the analogy here is
the binding cache entry for another MN. Without changing this first,
how can you talk about flow mobility in PMIP?

OTOH, Section 5.1 comes close, it adopts MIP6 MCoA approach, i.e.
binding cache entries for the same MN are treated in an integral way,
not representing different mobility sessions.

The problem of independent binding cache entries for different
interfaces of MN seems to be ignored except somewhat in Section 5.1.

That even though draft-sarikaya-netext-fb-support-extensions was an
input document to the design team.

Regards,

Behcet