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

From: <[email-masked]>
Date: Wed, 2 Mar 2011 17:04:01 +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: Sri Gundavelli <[email-masked]>
Date: Wed, 02 Mar 2011 09:17:09 -0800

Raj:

Thanks for the meeting minutes.

Can you comment on the AD inputs w.r.t bundling every flow mobility feature
in a single spec, vs multiple document deliverables. Specifically, the scope
of the current work and if it must be in a single document.

Thanks
Sri

On 3/2/11 9:04 AM, "[email-masked]" <[email-masked]>
wrote:

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

---

From: <[email-masked]>
Date: Wed, 2 Mar 2011 18:03:24 +0000

Hi Sri,

We did not discuss the idea of single vs multiple documents for flow mobility.
As you can see from the ongoing discussion, there are concerns about the viability of flow mobility as a feature in a PMIP6 deployment.
These need to be addressed before we can even consider whether a single document or multiple documents are needed to specify the feature.

-Raj

From: ext Sri Gundavelli [mailto:[email-masked]]
Sent: Wednesday, March 02, 2011 11:17 AM
To: Patil Basavaraj (Nokia-MS/Dallas); [email-masked]
Cc: Jari Arkko
Subject: Re: [netext] Update on flow mobility following discussion with ADs

Raj:

Can you comment on the AD inputs w.r.t bundling every flow mobility feature in a single spec, vs multiple document deliverables. Specifically, the scope of the current work and if it must be in a single document.

Thanks
Sri

On 3/2/11 9:04 AM, "[email-masked]" <[email-masked]> wrote:

   Other options?

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

---

From: Jari Arkko <[email-masked]>
Date: Wed, 02 Mar 2011 21:49:24 +0200

Sri:

What Basavaraj said. I don't think the number of specifications is a big 
concern either now or later. Split the documents the way you like. Lets 
discuss functionality, robustness, assumptions instead -- those are 
important.

(And of course, splitting to different specifications should not be 
misused to hide a technical omission or a problem.)

Jari

---

From: "Stefano Faccin" <[email-masked]>
Date: Wed, 2 Mar 2011 13:51:25 -0600

Raj,

Thanks for the notes. There is one aspect that concerns me, and is
related to :

"2. There is no plan or expectation that there would be a way for the

"

Personally I am concerned about this. What is the usefulness in netext
providing an "alternative" IP flow mobility solution that provides only
a subset of the functionality of a host-based solution. Deployments of
such so called alternative would provide a limited services with respect
to deployments of the host-based solution. Why would anybody want to
step back in time? 

As for:

"The preference is to develop

"

I can understand the point, but I have a question. As an example, 3GPP
(that can be one of the potential customers and that we can surely not
disregard) has been very keen in indicating that the user (whether it be
the actual human being using the MN or e.g. the enterprise owning the
MN) has priority wrt the policies defined by the operator. This is
because in several scenarios the user may have preference for certain
accesses (e.g. the enterprise WiFi) that are not provided by the
operator for certain services (e.g. access to the enterprise resources).
In such case, 3GPP has recognized the need to allow the user to have
precedence. If the solution designed by netext is based solely on
network policies and decisions, I am afraid we would have a solution
that does not allow valid scenarios that have been identified by one of
the potential customers for the solution.

Cheers,

Stefano Faccin

Standards Manager

Research In Motion Corporation 
5000 Riverside Drive 
Building 6, Brazos East, Ste. 100

Irving, Texas 75039 USA 
Office: (972) 910 3451  

Internal: 820.63451

 : (510) 230 8422

www.rim.com
<outbind://28-00000000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D41
49BF16E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E000000
6F1BEA0000/www.rim.com> ; www.blackberry.com
<outbind://28-00000000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D41
49BF16E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E000000
6F1BEA0000/www.blackberry.com>  

  <http://www.blackberry.com/> 

P Consider the environment before printing.

From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Wednesday, March 02, 2011 9:04 AM
To: [email-masked]
Subject: [netext] Update on flow mobility following discussion with ADs

March 1st:

   Other options?

-Raj

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 02 Mar 2011 12:11:10 -0800

Hi Jari:

Thanks for your response.

Sure, technical correctness of the spec is more important than the
document(s) structure management.

> misused to hide a technical omission or a problem.)

On the contrary, I think we are discussing many features, mixing all the
issues and without being able to differentiate between a real technical
issue in the base feature, vs. a technical issue in some other requirement
which is of interest to few folks.

I hope and I'm certain, Basavaraj will structure the documents and put a
proper context around the discussions and disagreements.

Regards
Sri

---

From: <[email-masked]>
Date: Wed, 2 Mar 2011 20:32:02 +0000

Hi Stefano,

Inline below:

From: ext Stefano Faccin <[email-masked]<mailto:[email-masked]>>
Date: Wed, 2 Mar 2011 13:51:25 -0600
To: Patil Basavaraj <[email-masked]<mailto:[email-masked]>>, Netext <[email-masked]<mailto:[email-masked]>>
Subject: RE: [netext] Update on flow mobility following discussion with ADs

Raj,
Thanks for the notes. There is one aspect that concerns me, and is related to :

“2. There is no plan or expectation that there would be a way for the
”

Personally I am concerned about this. What is the usefulness in netext providing an “alternative” IP flow mobility solution that provides only a subset of the functionality of a host-based solution. Deployments of such so called alternative would provide a limited services with respect to deployments of the host-based solution. Why would anybody want to step back in time?

Raj> I would not consider PMIP6 based flow mobility as an alternative to the host based solution that is specified in RFCs 6088/9. The type of mobility capability in a deployment can vary. The PMIP6 based flow mobility would be applicable in deployments which leverage network based mobility. Whether the functionality provided by this capability is sufficient, is a conscientious decision that will be made by the operator. It is a matter of choice and what I am saying is that the scope of this work is NOT intended to provide the same set of capabilities that exist in the host based flow mobility solution.

As for:

“The preference is to develop
   a flow mobility solution that works with policies and signaling
   that is network centric (i.e MAG/LMA entities).
”
I can understand the point, but I have a question. As an example, 3GPP (that can be one of the potential customers and that we can surely not disregard) has been very keen in indicating that the user (whether it be the actual human being using the MN or e.g. the enterprise owning the MN) has priority wrt the policies defined by the operator. This is because in several scenarios the user may have preference for certain accesses (e.g. the enterprise WiFi) that are not provided by the operator for certain services (e.g. access to the enterprise resources). In such case, 3GPP has recognized the need to allow the user to have precedence. If the solution designed by netext is based solely on network policies and decisions, I am afraid we would have a solution that does not allow valid scenarios that have been identified by one of the potential customers for the solution.

Raj> A network centric flow-mobility solution may not be able to address all the scenarios that 3GPP is considering. But a subset of those may be dealt with via this feature. As long as the document is clear about what is in scope and possibly documenting some of the limitations as well, it would be useful to specify it. There could be other types of networks that could use such a solution as well.

-Raj

Cheers,
Stefano Faccin

Standards Manager
Research In Motion Corporation
5000 Riverside Drive
Building 6, Brazos East, Ste. 100
Irving, Texas 75039 USA
Office: (972) 910 3451
Internal: 820.63451
[Untitled-1]: (510) 230 8422
www.rim.com<outbind://28-00000000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D4149BF16E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000/www.rim.com>; www.blackberry.com<outbind://28-00000000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D4149BF16E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000/www.blackberry.com>

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Wednesday, March 02, 2011 9:04 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [netext] Update on flow mobility following discussion with ADs

   Other options?

-Raj

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 02 Mar 2011 12:39:06 -0800

> discuss functionality, robustness, assumptions instead -- those are

I agree that the spec should be robust, and should work under conditions
assuming existing & new L2 signaling, as well as under conditions when new
L2 signaling is unavailable.

It's a question of whether we agree that LMA-MAG signaling could also be
used in addition to relying only on L2 signaling for flow mobility.

> misused to hide a technical omission or a problem.)

I would focus on getting a protocol that works under different cases and not
just under continued reliance on (existing and new) L2 signaling. (I am not
referring to new IP signaling between MN and MAG).

-Rajeev

---

From: Julien Laganier <[email-masked]>
Date: Thu, 3 Mar 2011 11:44:32 -0800

Hi Rajeev,

> L2 signaling is unavailable.

I have expressed doubts about the feasibility of a robust flow
mobility / inter-access handover solution that relies on existing,
unmodified L2 signaling (this is discussed in a different thread.) We
should not sacrifice correctness and robustness for the sake of
working around unmodified L2 signaling. As I've said earlier, one of
the potential customer for this (3GPP) owns two L2 that are used to
access their system (PMIP based S5 for 3GPP accesses, and PMIP based
S2b for no-3GPP accesses.)

> used in addition to relying only on L2 signaling for flow mobility.

At this stage the question is rather, is it possible to provide a
correct and robust system without modified L2 signaling. If it is,
then we can go ahead with the question you laid above. Would you
agree?

> referring to new IP signaling between MN and MAG).

See above. The focus you propose is only appropriate insofar we've
come up with a positive answer to the question I asked above, and that
we' re discussing with Carlos, Hesham, et al.

--julien

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 03 Mar 2011 21:40:19 -0800

Hi Julien,

I don't believe I suggested sacrificing correctness and robustness; in fact,
I suggested robustness of protocol operation to cover all cases.

More to the point, I think relying _only_ on extended L2 signaling is one of
the cases the protocol needs to cover. We need to include the case when
either new L2 signaling is unavailable or is not considered reliable.

I am proposing an inclusive approach for providing flow mobility when the
desired aspects of L2 signaling are available (HI=Flow Mobility) _and_
consider the case when we they are not available (HI=Unknown). I should be
able to move flows across interfaces regardless of whether the LMA maintains
a single session or multiple sessions (all created according to the baseline
PMIP6 model).

Making use of 3GPP as a customer is great, but I do not want to be limited
only to it.

Thanks,

-Rajeev

---

From: Julien Laganier <[email-masked]>
Date: Fri, 4 Mar 2011 11:29:46 -0800

Hi Rajeev,

I've been under the impression that correctness is only achievable to
the extent that the network offers flow-mobility / inter-access
handoffs only to the MN that indicates their support for the feature
(e.g., via the logical interface construct, or any other.) If that
holds, since the MN can' t indicate this at layer 3, this has to be
done at layer 2, thus you need this extended L2 signaling in all
cases.

Am I missing something?

--julien

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Fri, 4 Mar 2011 14:59:10 -0500

Julien,

Capability discovery can be achieved by layer-2, 3 or even 7. The
current charter restriction is specifically about no MN-ntwk PMIP
signalling, and layer-2 signalling is outside the scope.

Hence, I think it is fair to design a PMIP flow mobility solution with
the following assumptions:

1) MN capabilities are known,
2) possible existence of layer-2 signalling to provide hints (HI=Flow
Mobility),
3) and possible non-existence of layer-2 signalling to provide hints
(HI=Unknown)

Cheers,

Juan Carlos

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Julien Laganier
> Sent: March 4, 2011 2:30 PM
> To: Rajeev Koodli
> Cc: [email-masked]; [email-masked]
> Subject: Re: [netext] Update on flow mobility following discussion
with
> ADs
> > More to the point, I think relying _only_ on extended L2 signaling
is
> one of
> > I am proposing an inclusive approach for providing flow mobility
when
> the
> >>>> What Basavaraj said. I don't think the number of specifications
is
> a big
> >>>> concern either now or later. Split the documents the way you
like.
> Lets

---

From: Julien Laganier <[email-masked]>
Date: Fri, 4 Mar 2011 15:58:31 -0800

Juan Carlos,

> signalling, and layer-2 signalling is outside the scope.

We assume that a L2 construct (logical interface) isolates the
unmodified IP stack from the underlying diversity of physical
interfaces. From this point of view it seems fair that the L2
signaling is in charge of signaling the capabilities of the MN (and
this has been done in 3GPP.) Of course the layer 2 signaling
definition is out-of-scope of this group, but as it's been done in
5213 where reasonable assumptions were made on what the L2 signaling
has to provide (attach triggers, MNID, and possibly handoff
indicator), for this flow mobility work item we're certainly in a
position to make the assumption that flow mobility requires capability
support indication and intent to do flow mobility vs. inter-access
handoff. Actually, we have no choice if we want a working system (see
point at the end of this note.)

The IP layer is unmodified and the charter forbids this group to
define a layer 3 MN-network signaling.

I don't know how a layer 7 would know anything about the capability of
the network stack to hide to the IP layer the underlying physical
interfaces...

> 1) MN capabilities are known,

by magic?

> 3) and possible non-existence of layer-2 signalling to provide hints

in 5213 HI=unknown leads the network to not provide inter-access
handoffs because it could break connectivity at a legacy host. I don'
t see how we can depart from that and thus if HI= unknown no flow
mobility should be offered to the host, only basic 5213 model where
each interface of host has its own PMIPv6 session. If you offer flow
mobility when the network does not reliably know the capability of the
host you risk breaking that host thus the protocol extension would
have no correctness...

--julien