Subject: [netext] Update on flow mobility feature following discussion with ADs

From: <[email-masked]>
Date: Wed, 2 Mar 2011 16:56:44 +0000

Just wanted to provide an update regarding the ongoing work on flow
mobility for PMIP6 and my discussion with our ADs (Jari and Ralph) on
March 1st:

I have apprised our ADs about the state of the ongoing discussion on
flow mobility. One of the concerns about the ongoing work on flow
mobility was related to the logical interface feature. Flow mobility
depends on the existence of a logical interface on the host. The WG
has not addressed the concerns related to the logical interface I-D,
that were raised at the previous WG meetings. Emphasised that we
should get the logical interface spec done soon since it is a
fundamental dependency for flow mobility.

Regarding the current scope of the flow mobility work and the I-D
which is now in consensus call, there are a few issues that need to be
resolved. A few points below:

1. Flow mobility in the context of Proxy MIP6 is not analogous to the
   solution that has been developed for host based MIP6. The
   featureset and capabilities developed in Netext does not have to
   mirror, parallel or be equivalent to that of RFCs 6088/9.

2. There is no plan or expectation that there would be a way for the
   MN/host to do signaling related to flow mobility with a MAG at
   layer 3. Layer 2 is an option but obviously this requires such
   enhancements to be done in other SDOs. The preference is to develop
   a flow mobility solution that works with policies and signaling
   that is network centric (i.e MAG/LMA entities).

3. One of the major concerns raised on the mailing list is related to
   how flow mobility would work when an MN attaches to a wifi access
   and the LMA switches a flow(s) to the MAG serving the MN via that
   wifi. The MN has no way of indicating to the LMA if the wifi access
   is congested or for the MAG to indicate to the LMA about the state
   of the MNs attachment to the AP. Packets forwarded by the LMA to
   the MN via the wifi-MAG could be sent into a void.
   Without a solution for the above scenario, flow mobility would not
   be robust. Some clear answers are needed here.

   One option is that flow mobility for PMIP6 is applicable only in
   those access networks wherein the access network elements are aware
   of the state of the MNs connection and congestion state. The MAG
   can use this information to signal to an LMA attachment state and
   potentially cause flows to be switched to an alternative MAG. It
   may be okay to have specific statements about the limitations of
   flow mobility for PMIP6 documented as a sort of disclaimer.

   Other options?

4. The WG is free to extend the PMIP6 signaling between MAG/LMA to
   accomplish flow mobility.

5. And lastly the question about who is the customer for this work at
   this time is irrelevant. We have had this discussion during the
   chartering phase and there is no reason to revisit it.

If I have missed any other significant (show-stopper) concern
regarding the flow mobility feature, please do raise them.

-Raj

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 03 Mar 2011 11:37:06 +1100

Hi Raj, 

>    mirror, parallel or be equivalent to that of RFCs 6088/9.

=> So can you please define what you mean by flow mobility? Because this
term was only used to mean "moving flows from one interface to another" and
was connected to 6088. If there is something else that you plan to do then
lets define it and based on that decide whether it's the same thing or not.

Hesham

> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

---

From: <[email-masked]>
Date: Thu, 3 Mar 2011 04:00:33 +0000

Hi Hesham,

>lets define it and based on that decide whether it's the same thing

Flow mobility in the context of Proxy MIP6 is the switching of a flow
by the LMA from MAGx to MAGy when the MN is attached to the LMA via multiple
interfaces through different MAGs. The LMA makes the decision to move
a flow based on some policy. Unlike MIP6 flow mobility where the MN
signals to the HA flow switching, the PMIP6 based flow mobility has no
MN involvement. 
Do you have a better term to describe this functionality.

Also note that there is a possibility that the MN could do some sort
of L2 signaling with the access network w.r.t flow mobility in which
case the solution starts looking similar to the one defined in
6088. The L2 signaling is of course out of IETF scope and would have
to be specified for specific link types in the relevant SDOs. 

-Raj

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 03 Mar 2011 15:24:17 +1100

> Do you have a better term to describe this functionality.

=> No I don't have a better definition. That definition though is
functionaly identical to 6088's assumption. I gathered from your notes that
netext might do a subset of features, hence my question about the
definition. 
My (and others') argument is that the policy would be flawed if it didn't
include the MN's input. If that input happens to be on L2 it is still very
limited as to what it can be.

Hence, since it doesn't look like such policy will be defined by IETF, I
think the solution is more likely to be harmful because it can be
inadvertently miused. Please note that a bad or a wrong policy here would
affect all MN's in a domain, which is obviously not the case in MIPv6.

Hesham

---

From: <[email-masked]>
Date: Thu, 3 Mar 2011 04:36:37 +0000

>limited as to what it can be.

Agree. The limitation arises from the inability of the MN to do the
sort of signaling that is possible in MIP6. Hence you would not have
the same degree of control in terms of switching flows or the
granularity in the case of PMIP6. At least this is IMO (chair hat
off). I think the authors of the I-D may have additional
opinions. I have some degree of skepticism about what can really be
achieved at L2 since it is not easy to change existing link specs. 

>affect all MN's in a domain, which is obviously not the case in

Policy that is used to switch a flow by the LMA can be configured
locally (LMA), obtained via some interface to policy engines, etc. So
yes, we are not specifying the actual policy itself. Misconfiguring
policies will no doubt affect a larger set of MNs when compared to the
equivalent in MIP6 based flow mobility where the impact would be to a
single MN. But these are the tradeoffs. The I-D could document such
issues in order to ensure that anyone using such a system would be
aware of the pitfalls. 

-Raj

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 03 Mar 2011 15:59:37 +1100

> achieved at L2 since it is not easy to change existing link specs.

=> Right. So given that, I think we need to have a clear scope of what can
be done.

> issues in order to ensure that anyone using such a system would be

=> Hmm, the problem isn't misconfiguration, The problem is configuring
things correctly :). I mean when you buy a car that has a mx speed of 300
km/hr but a bad suspension you shouldn't be going very fast on a winding
road even if the claimed speed is achievable.

My point is that you'll advertise a certain feature that you can't actually
guarantee unless you explicitly restrict the scenarios it supports. I don't
know how you intend to do that though. But if you do, I suggest you don't
call it flow mobility because it's false advertising given the precedence in
6088 and 6089. It needs to be given a name that indicates its limitation so
its clear to the users.

Hesham