Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc

["MELIA, TELEMACO (TELEMACO)" <[e-mail]>]

Stefano, all,

I believe the authors of the draft never intended to replicate all the features of the client based approach.

In addition to this I fail to see why we should spend so much time in discussing the WLAN ESSID issue. Of course we can debate about trusted/untrusted access but I think this is orthogonal to the PMIP flow mobility discussion. If not can you please explain?

telemaco
________________________________
De : [e-mail] [mailto:[e-mail]] De la part de Stefano Faccin
Envoyé : vendredi 4 février 2011 00:02
À : Sri Gundavelli; Giaretta, Gerardo; stefano faccin
Cc : [e-mail]; [e-mail]
Objet : Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc

Sri,
I am glad to hear that you also think that the network-based flow mobility solution cannot intrinsically provide all the features of the client-based approach.

I am also glad that you hear that access selection solutions in place today are sci-fi. Why do you believe that an operator that wants e.g. to move the voice traffic and video streaming to the WLAN APs it deploys (because it can offload them and can control QoS) may not want to move the same flows to a WLAN in a hotel where the user will get an awful user experience? Another example: policies may be configured by an enterprise in the device so that the enterprise will allow the MN to direct some traffic on certain WLAN APs (e.g. the one the enterprise deploys) but not on other WLAN APs. I think the per-access network scenarios are indeed more than realistic. Perhaps we're trying to oversimplify the scenarios just to fit the solution in them?

Stefano Faccin

Standards Manager
Research In Motion Corporation
5000 Riverside Drive
Building 6, Brazos East, Ste. 100
Irving, Texas 75039 USA
Office: [phone]
Internal: 820.63451
[cid:image001.jpg@01CBC458.F5EE4370]: [phone]
www.rim.com<outbind://28-00000000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D4149BF16E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000/www.rim.com>; www.blackberry.com<outbind://28-00000000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D4149BF16E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000/www.blackberry.com>



[cid:image003.jpg@01CBC458.F5EE4370]<http://www.blackberry.com/>

P Consider the environment before printing.

From: Sri Gundavelli [mailto:[e-mail]]
Sent: Thursday, February 03, 2011 2:56 PM
To: Stefano Faccin; Giaretta, Gerardo; stefano faccin
Cc: [e-mail]; [e-mail]
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc

Hi Stefano,

My point on the synchronized policy assumption still remains, as I've noted in the other thread.

Therefore, if we want to provide a protocol for network based flow mobility to provide an alternative to existing solutions, we need to provide a solution that realistically provides the same functionality.

I will probably take a defensive stand on this. As I've stated before, I do not believe network-based mobility approaches can match client based approaches 1:1, in every aspect. Its simply not possible, specially when we don't have the needed MN-AR interface argument, for carrying Attachment Preferences. But, most of the features that are practical from deployment perspective (unlike some of the complex flow mobility scenarios, complexity in the order of science fiction moves :)), every thing else can be achieved over network-based approaches, with out any MN-AR interface. Hence, my argument to keep the specs simple

As as for simplified policies versus what current solutions already provide (e.g. per access network policy and not just per access technology), why should we go ahead with a solution that brings us back in time wrt what we can provide to users and operators? Please note that even today (and not just future releases of 3GPP or future IETF protocols) there are deployment scenarios where the decisions to choose or not whether to route traffic over a certain WLAN is based on the specific WLAN (e.g. SSID) and not just on the fact that the MN is connected to WLAN.

To large part, in the context of trusted non-3GPP access, basic flow mobility functions can be supported. We can break this down and bring some of the aspects around network ownership, cost parameters and tie the flow policy rules to it. But, I don't think the goal is to support all such features.



Regards
Sri



On 2/3/11 2:22 PM, "Stefano Faccin" <[e-mail]> wrote:
Hi Sri,
I need to agree with the Gerardo. You are making an assumption that is incorrect.Synchronizing policies between the MN and the LMA is not an easy and scalable solution. I understand synchronizing policies between a MN and a policy server that is the only repository for a given MN (i.e. one MN has its policy in a single policy server). Assuming that all the LMAs in a network that the MN can be connected to have synchronized policies with the MN is clearly not realistic.

As as for simplified policies versus what current solutions already provide (e.g. per access network policy and not just per access technology), why should we go ahead with a solution that brings us back in time wrt what we can provide to users and operators? Please note that even today (and not just future releases of 3GPP or future IETF protocols) there are deployment scenarios where the decisions to choose or not whether to route traffic over a certain WLAN is based on the specific WLAN (e.g. SSID) and not just on the fact that the MN is connected to WLAN.

Therefore, if we want to provide a protocol for network based flow mobility to provide an alternative to existing solutions, we need to provide a solution that realistically provides the same functionality.

Cheers,

Stefano Faccin Standards ManagerResearch In Motion Corporation
5000 Riverside Drive
Building 6, Brazos East, Ste. 100Irving, Texas 75039 USA
Office: [phone]  Internal: 820.63451[cid:image001.jpg@01CBC458.F5EE4370]: [phone]www.rim.com <outbind://28-00000000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D4149BF16E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000/www.rim.com> ; www.blackberry.com <outbind://28-00000000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D4149BF16E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000/www.blackberry.com>
[cid:image003.jpg@01CBC458.F5EE4370]<http://www.blackberry.com/>

P Consider the environment before printing.


From: [e-mail] [mailto:[e-mail]] On Behalf Of Giaretta, Gerardo
Sent: Wednesday, February 02, 2011 9:14 PM
To: Sri Gundavelli; stefano faccin
Cc: [e-mail]; [e-mail]
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc

Hi Sri,

There is no implicit assumption of synchronized policies. A basic example that shows that there is no assumption is the following: ANDSF policies may be based also on location of the UE. For example the UE should prefer WLAN only in a given location. When the UE is attached over WLAN there is no way for the PDNGW/HA to verify the location of the UE and therefore to verify UE actions based on policies.

The assumption on synchronization of policies is only applicable to this draft and I think it is a wrong one.

Cheers
Gerardo


From: [e-mail] [mailto:[e-mail]] On Behalf Of Sri Gundavelli
Sent: Wednesday, February 02, 2011 6:50 PM
To: stefano faccin
Cc: [e-mail]; [e-mail]
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc

Hi Stefano,

One comment.

Agree with you there is no ANDSF interface to the network node, but the assumption of synchronized policies between the ANDSF server and the PDN GW/HA is there, implicitly IMO. With out this assumption, I do not know, how the HA can ever validate the flow mobility options received in the BU. If the operator requires any control on enforcing a flow policy rule, the PDN GW/HA needs to have synchronized policies, without which its always the client decision. I'm not sure, operators in 3GPP would like that :)

No doubt, the lack of MN-AR interface is surely an issue for supporting complex flow policies. I realize the issues and I agree with you. But, the assumption of synchronized policies can offer some solution with some configuration requirement on the HA (assuming there are no other issues). There are also the proposals on flow mirroring on the UE ..., requiring no flow policies. I've not evaluated this, however. Folks can comment on this.

It is also to be noted, for some of the scenarios such, there is no flow policy interface needed. We can identify what scenarios create any configuration limitations on the HA and which one's do not . As I've noted earlier, this is surely an open issue, that we need to discuss in the WG.



Regards
Sri







On 2/2/11 9:08 AM, "stefano faccin" <[e-mail]> wrote:
Sri,
thanks for the reply. Can you clarify in which system or scenario ANDSF is available to network entities as well? There is no such availability in 3GPP, and making such information available would require considerable architectural changes, therefore the applicability of this solution to what seems to be the only realistic scenario hinges on 3GPP making considerable architectural changes. I would therefore not be so hastily concluding that the ANDSF information is available to the LMA and underestimate what it would really take to make the solution applicable.

If we cannot guarantee that there is at least one realistic solution to have the MNa nd LMA in synch, how do we expect that this solution is applicable at all? In 3GPP there is no need to have such implicit assumption, be cause 1) the MN is provided policies explicitly through the ANDSF, and 2) it is the MN and only the MN that makes IP flow mobility decisions and communicates them explicitly (with well defined signalling) to the LMA, and therefore no magic is needed. There is no need in 3GPP to have the ANDSF and PDN GW policies synchronized, since the PDN GW does not use such policies.

Sri, in the end it is a matter of whether we develop a solution that will rely on some unknown magic to be deployed, or a solution that we know can be deployed in at least one way because there are solutions to what I consider major open issues.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 9:06 PM, Sri Gundavelli <[e-mail]> wrote:
Hi Stefano,

Thanks for the discussion.

As you say, the ANDSF policies are allowing the MN a.) to make the right network attachment decision and b.) make the access selection on a flow basis. This same policy that is present in the ANDSF server, is available for the network nodes as well. I'm not sure, with out this assumption the solution can work for all currently listed cases. We clearly need the MN and the LMA to be in synch with respect to the configured policy. How, that is done, I guess we will not try to know.  I thought even in 3GPP, this is the implied assumption ? But, this is for you to clarify. Not specifically for IFOM where UE and PDN GW/HA are negotiating the flow policies, but generally that the PDN GW and the ANDSF policy server will have synchronized policies. The MAG and the LMA have the ability to carry this flow policy information in signaling messages and influence the access selection. The policy is a opaque object, with extensible formats, when carried in the signaling plane, should allow the LMA/MAG to apply those access policies, while assuming MN is following the same rules. These policies can surely reflect the specific WLAN access/operator specific rule. I'm surely with you, the lack of MN-AR interface is surely an issue and I see that. But, we need to understand, what are the limitations with the approach of  out of band policy interfaces and what will be the solution limitations. If we need to tie the flow movement at the prefix granularity and rely on the natural ND interface in the form of RA PIO option, more like PDN offload in MAPCON, or at the granularity of a flow level, is open for discussion. I want to simplify this draft for sure, we can surely discuss each of these issues on the WG draft.


Regards
Sri






On 2/1/11 8:29 PM, "stefano faccin" <[e-mail] <http://[e-mail]> > wrote:
Sri,
thanks for the reply.

I'd like to comment on the "the flow policy decisions need not be based on the specific WLAN network". Does it mean, as I believe it does, that the current solution would not allow an operator deploying such solution to decide to route flows over a specific WLAN or not depending on which specific WLAN the MN is connected to? E.g. the operator or the entity in control of the decisions for the routing may want to direct certain traffic always over WLANs that the operator deploys, and instead route only some of the traffic over WLANs of roaming partners or of the MN user home. How does this solution support that scenario if the LMA is not told specifically which WLAN the MN is connected to? From a deployment point of view, I do not believe we can afford to leave out this scenario. Please note that the establishment of a security relationship between the MN and the MAG, and a specific MAG identity, cannot guarantee that the LMA knows which specific WLAN access network the MN is connected to. Assuming that would severely restrict the deployment scenarios.

As for the MN and the LMA being magically in synch, I am very concerned about a "glass ball" solution. You mention ANDSF defined by 3GPP as a solution for this "out of band" delivery of policy. Fair enough, however there is an issue with that. ANDSF is designed specific to be a MN-centric solution where policies are provisioned in the MN and the MN decides which network technologies and access networks it needs to connect to, under what conditions, and which IP traffic needs to be routed on such accesses. No IP point of attachment in the network (i.e. the PDN GW in 3GPP that is the LMA in PMIPv6) is aware under any conditions of such policy. Therefore, even if in order to apply this solution to 3GPP we wanted to use ANDSF, ANDSF would unfortunately not provide a solution unless the MN can communicate to the MAG and the LMA the decisions the MN has taken based on the ANDSF policies.

I believe the key point here is that we need to understand how the solution can be realistically applied to a real scenario, and that we need to ensure that important and realistic deployment scenarios are not excluded by the solution.

Cheers,
Stefano

On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli <[e-mail] <http://[e-mail]> > wrote:
Hi Stefano:

These are valid points and some good comments. Let me share my thoughts.

Carlo's draft is not assuming any new MN-AR interface. Its going with the assumption there is established policy on the mobile and on the LMA, which allows the mobile to select the access network at a flow level granularity, without requiring any explicit signaling between the MAG and the MN. To large part this is all about out of band policy interface, such as ANDSF, towards the UE, leading to the assumption that magically the MN and the LMA are in sync with respect to flow policies, access selection and they will make the right forwarding decision. Secondly, the flow policy decisions need not be based on the specific WLAN network, but it is implicitly driven by the MAG - LMA security relation, where the MAG attachment to the WLAN network transitively allows the LMA to make the flow policy decisions based on the MAG identity. If the WLAN network is not trusted, there is truly no MAG in that network, where the LMA shares a security relation with that node.

There are still some open issues on this draft that needs to be discussed in the WG.  On the approaches to allow more a flow aggregate movement, that is a discussion point. There are issues that we need to discuss, supporting split link model, or eliminating some favorite brand of signaling message (FMA) and riding on PBU/PBA and just with one FMI trigger, and on the aspects around MN applying the flow policies by flow mirroring. We have no agreement on those issues yet.

Its just a base draft, for further discussion and resolving those issues. But, hope that is not a stopper for base draft selection.


Sri






On 2/1/11 6:39 PM, "stefano faccin" <[e-mail] <http://[e-mail]>  <http://[e-mail]> > wrote:
Raj,
thanks for the email.

I need to apologize in advance if my questions have already been answered before (though I cannot find a conclusive answer anywhere).

I think that a protocol that is developed in NETEXT (or other groups) should have at least a potential realistic scenario for applicability.

In terms of applicability, though it is not part of the protocol definition per se, unless there are solutions in place for either the host to indicate to the network where the flows should be routed or for the LMA to receive somehow from somewhere some policies, the solution cannot really provide flow mobility since there is no way to decide which flows are routed where. If we are thinking about a host-based solution, I have not yet seen a solution as to how the host can indicate to the MAG and ultimately to the MAG which flows should be routed on each access. If we are relying on modifications of layer 2 protocols, aren't we defining a solution that works only with some technologies (since for other access technologies it is rather unrealistic to modify L2 for IP flow mobility purposes)? If we are thinking of an LMA-based solution, can we hear of at least one example of a real-life scenario where the LMA would receive such policies, and how such delivery would happen? Also, should there be a solution to have policies in the LMA, how does the LMA actually decide to route flows on one access or the other? E.g., if some flows need to be routed on certain WLAN networks, but shall not be routed on other WLAN networks, how does the LMA know which specific WLAN network the host is connected to? Perhaps I missed the ability for the MAG to know e.g. the WLAN SSID and provide it to the LMA, in which case I would appreciate if somebody could highlight to me where that is defined.

I think that, though not integral to the protocol specification, understanding what framework the protocol would/needs to fit in is rather important.

Cheers,
Stefano


On Tue, Feb 1, 2011 at 3:47 PM,  <[e-mail] <http://[e-mail]>  <http://[e-mail]> > wrote:

Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously at
IETFs 78 and 79.
This is a consensus call for adopting this I-D:
draft-bernardos-netext-pmipv6-flowmob-02
as the working group document.
I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt

The consensus call will expire on Feb 15th, 2011. Please indicate your
support or concerns in adopting this I-D as the WG baseline document on
the mailing list.

Please note that this I-D will serve as the baseline in the WG and will be
developed further based on input and feedback from WG members.

-Basavaraj

_______________________________________________
netext mailing list
[e-mail] <http://[e-mail]>  <http://[e-mail]>
https://www.ietf.org/mailman/listinfo/netext



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