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

From: <[email-masked]>
Date: Mon, 23 Jul 2012 17:11:12 +0000

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.

-Raj

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 23 Jul 2012 15:03:37 -0500

Hi Basavaraj,

> 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

---

From: <[email-masked]>
Date: Wed, 25 Jul 2012 21:40:49 +0000

Hi Behcet,

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

>draft-sarikaya-netext-fb-support-extensions-02 should be normative

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 26 Jul 2012 14:06:49 -0500

Hi Basavaraj,

> 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

---

From: <[email-masked]>
Date: Fri, 27 Jul 2012 17:08:05 +0000

Inline: 

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

>handled it is impossible to do any flow mobility among multiple

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

>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

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 27 Jul 2012 13:35:51 -0500

Hi Basavaraj,

Please see inline.

> 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