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

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

Yes, it would help.

telemaco

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


Hi,

I am asking if you could show how the propagation of SSID/ULI from the MN is considered reliable enough for the network to act on. That would help us understand what we need to do here to address your "flag".

Thanks,

-Rajeev



On 2/3/11 2:43 PM, "Giaretta, Gerardo" <[e-mail]> wrote:
Hi Rajeev,

Not sure I understand what you are asking me. My comment was mainly referred to synchronization of policies which is an assumption not correct in my opinion.

Based on the current policy model adopted by 3GPP, the only way I can think of to make the system working is to replicate the behavior of RFC 6089 where the MN initiates the flow movement.

The assumption on synchronization of policies may however be considered acceptable in other SDOs or even in 3GPP in future. I am just raising an applicability flag to the group (actually the flag was initially raised by Stefano :))

Gerardo


From: Rajeev Koodli [mailto:[e-mail]]
Sent: Thursday, February 03, 2011 2:51 PM
To: Giaretta, Gerardo; 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 Gerardo,

Okay, so let's agree that the current version of the draft does not have SSID/ULI propagation to the LMA.

Do you care to suggest how the network deems such an information from the MN trustworthy?

I am sure you agree if we could have good input, we could design protocols accordingly.
You will also probably agree that's much better than just arguing about "it does not work in today's 3GPP deployment".

Regards,

-Rajeev


On 2/2/11 9:13 PM, "Giaretta, Gerardo" <[e-mail]> wrote:
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



________________________________

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