[netext] Update on flow mobility following discussion with ADs

[<[e-mail]>]

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