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

From: <[email-masked]>
Date: Tue, 1 Feb 2011 23:47:03 +0000

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

---

From: stefano faccin <[email-masked]>
Date: Tue, 1 Feb 2011 18:39:31 -0800

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, <[email-masked]> wrote:

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

-- 
Stefano M. Faccin
==================
May the Force be with you

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 01 Feb 2011 19:43:29 -0800

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" <[email-masked]> wrote:

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

---

From: stefano faccin <[email-masked]>
Date: Tue, 1 Feb 2011 20:29:15 -0800

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 <[email-masked]> wrote:

> Carlo’s draft is not assuming any new MN-AR interface. Its going with the
> the MAG – LMA security relation, where the MAG attachment to the WLAN
> 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
> I think that a protocol that is developed in NETEXT (or other groups)
> should have at least a potential realistic scenario for applicability.
>

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 01 Feb 2011 21:06:01 -0800

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" <[email-masked]> 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
> 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.
> 
>> 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.
>> 
>> 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.
>> 
>> On 2/1/11 6:39 PM, "stefano faccin" <[email-masked]
>> <http://[email-masked]> > wrote:
>> 
>>> Raj,
>>> thanks for the email.
>>> 
>>> On Tue, Feb 1, 2011 at 3:47 PM,  <[email-masked]
>>> <http://[email-masked]> > wrote:
>>>> 
>>>> Hello,
>>>> 
>>>> [email-masked] <http://[email-masked]>

---

From: <[email-masked]>
Date: Wed, 2 Feb 2011 17:45:58 +0100

Hi,

I've one concern about this I-D. Section 3.2 describes three mobility scenarios. The second one is about different set of prefixes per interface and focus on mobility triggered by L2 attachment. This scenario is quite confusing... I mean, obviously L2 attachment is a trigger for mobility but it is not specific to the scenario where MAGs manage different sets of prefixes; L2 attachment could also trigger mobility when prefix is shared between interface. Anyway, this text is about trigger for mobility and should be out of the scope of this draft. Besides, text after figure 4 clearly says that trigger and handover decision making is out of scope; I can't agree more.

So, even if -02 improved, I think this draft should be clarified again by focusing on basic flow mobility operations, i.e. scenario 1 and 3 of section 3.2. In my understanding these operations are: the LMA maintains a collection of BCE and controls mobility, i.e. decides how to use these BCEs. To perform handover, i.e. apply LMA decision, we have two scenarios: 1) move flow or 2) move HNP. Additionally, when MAGs use different sets of prefixes, we need piece of protocol between LMA and MAGs, or PMIP behaviour modification, to allow the new MAG updating its routing state. 

BR,
Pierrick

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part
> de [email-masked]
> Envoyé : mercredi 2 février 2011 00:47
> À : [email-masked]
> Objet : [netext] Consensus call to adopt I-D: draft-bernardos-netext-
> pmipv6-flowmob as WG doc
> 
> 
> Hello,
>

---

From: stefano faccin <[email-masked]>
Date: Wed, 2 Feb 2011 09:08:38 -0800

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 <[email-masked]> wrote:

> for the network nodes as well. I’m not sure, with out this assumption the
> WLAN access/operator specific rule. I’m surely with you, the lack of MN-AR
> On 2/1/11 6:39 PM, "stefano faccin" <[email-masked] <
> http://[email-masked]> > wrote:
>
> Raj,
> thanks for the email.
>
> On Tue, Feb 1, 2011 at 3:47 PM,  <[email-masked] <
> http://[email-masked]> > wrote:
>
>
> Hello,
>

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 02 Feb 2011 09:55:13 -0800

Hi Stefano,

Thanks for your input.

I expect the LMA interacting with PCRF for policy rules specific to the
subscriber for different RAT types.
You are right that the LMA does not know the SSID the mobile is connected
to. It¹s not clear if the MAG can get that from the MN either without
additional signaling. However, the LMA knows that the MN is connected to
WLAN; so it can apply the policy at the RAT type level. Are you thinking of
the MN connecting to more than one WLAN network (and each of those
connections coming back to the LMA)? If so, please explain the scenario.

Regards,

-Rajeev

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 02 Feb 2011 18:38:08 +0100

Hi Pierrick,

Thanks for your comments. See some of mine below.

On Wed, 2011-02-02 at 17:45 +0100, [email-masked]
wrote:
> Hi,
> 
> I've one concern about this I-D. Section 3.2 describes three mobility
> scenarios. The second one is about different set of prefixes per
> interface and focus on mobility triggered by L2 attachment. This
> scenario is quite confusing... I mean, obviously L2 attachment is a
> trigger for mobility but it is not specific to the scenario where MAGs
> manage different sets of prefixes; L2 attachment could also trigger
> mobility when prefix is shared between interface. Anyway, this text is

Agree. The point is that when the same prefix(es) is shared between
interfaces, there is no need for any signaling for the LMA to perform
flow mobility, while for the case of different prefixes we need (at
least to ensure that the routing state at the MAG is correct). That's
the reason we structure the draft in this way, though I agree it can be
improved.

>  about trigger for mobility and should be out of the scope of this
> draft. Besides, text after figure 4 clearly says that trigger and
> handover decision making is out of scope; I can't agree more.
> 
> So, even if -02 improved, I think this draft should be clarified again
> by focusing on basic flow mobility operations, i.e. scenario 1 and 3
> of section 3.2. In my understanding these operations are: the LMA
> maintains a collection of BCE and controls mobility, i.e. decides how
> to use these BCEs. To perform handover, i.e. apply LMA decision, we
> have two scenarios: 1) move flow or 2) move HNP. Additionally, when
> MAGs use different sets of prefixes, we need piece of protocol between
> LMA and MAGs, or PMIP behaviour modification, to allow the new MAG
> updating its routing state. 

Right, and the draft basically include some procedures to do so. We are
aware that there are some alternative/redundant mechanisms described in
the current draft. We wanted to have feedback from the WG on which ones
should be adopted and further refined.

Carlos

-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67

---

From: stefano faccin <[email-masked]>
Date: Wed, 2 Feb 2011 09:56:42 -0800

Hello rajeev,
the use of PCRF is an interesting suggestion. However, unfortunately, PCRF
does not contain any policies or information that will tell the LMA what are
the policies to be used for decisions of IP flow mobility. This is not part
of current PCC functionality, and there is no work ongoing or planned to
extend PCC in such way. Therefore, the applicability of the solution in this
draft would hinge on hypotetical future solutions and not on a current
solution for the open issues, which brings us back to my point that we are
defining a solution with open issues for which there is not a single
realistic solution out there, thus making this draft not applicable to a
real scenario.

I am not thinking of the UE connecting to more than one WLAN at the same
time, but the UE being able to connect to different WLANs (one at a time)
because the UE is e.g. provisioned with a list of SSIDs or the UE discovers
a hotspot somewhere. I am talking about the scenario where the UE is capable
to connect to WLAN, but the operator has different policies wrt which WLAN
the UE should use or not.

If you have followed the work in 3GPP, it is clear that operators have
interest in applying policies not only at RAT level, but also at access
network level (please see how ANDSF was defined and why). I guess we can all
agree that an operator deploying PMIP-based mobility may be interested in
having policies that allow traffic on the WLAN the operator owns or that
belongs to a roaming partner, while not allowing traffic on WLAN of other
operators for which it might need to pay an extra fee or where e.g. no QoS
can be guaranteed. That means that the entity deciding whether traffic needs
to be routed on WLAN or not cannot just consider "WLAN is available", but
"WLAN SSIDx is available", so that the decision can be based on the operator
preferences as to which WLAN certain traffic needs to be routed on.

If the draft allows decisions to be made only at the RAT level, then we have
an issue because we are defining a solution that should be applicable to
3GPP but does not meet the deployment scenarios of interest. In other words,
if we want to make this solution applicable e.g. to 3GPP, we need to be able
to provide the same functionality available today in 3GPP with other
solution in order to satisfy the use cases supported by 3GPP, and not step
backwards in terms of what can be supported.

Cheers,

Stefano

On Wed, Feb 2, 2011 at 9:55 AM, Rajeev Koodli <[email-masked]> wrote:

> to. It’s not clear if the MAG can get that from the MN either without

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 02 Feb 2011 10:44:30 -0800

Hi Stefano,

You make two interesting points: First, the defined solution should be
useful for 3GPP deployments. Second, if it¹s not defined today in 3GPP, it¹s
not useful.

I tend to agree with you on the first  3GPP is a big potential customer.
I cannot agree with your second point.

There are multiple ways I could envision policy on the LMA. Locally
configured policy is one (which we use today in deployments) that does not
need Gx interaction. Gx extensions can be proposed in the future. I hope you
are not suggesting that these are not feasible choices.

For the MN (IETF term for UE) to even connect to the MAG via WLAN today, you
need an IPsec termination point (ePDG). If the operator pre-configures the
list of SSIDs or there is some out-of-band mechanism to inform the MN which
SSID is ³white-listed², then I expect the MN to decide when to connect to
the ePDG and hence the MAG. At this point, the MN is already on the WLAN the
operator cares about I presume.
There is no easy way for the network (LMA, MAG) to know what SSID the MN is
connected to  the network has to either trust the software on the MN or the
WLAN infrastructure has to provide the SSID information to the network.

-Rajeev

On 2/2/11 9:56 AM, "stefano faccin" <[email-masked]> wrote:

> the policies to be used for decisions of IP flow mobility. This is not part of
> current PCC functionality, and there is no work ongoing or planned to extend
> PCC in such way. Therefore, the applicability of the solution in this draft
> would hinge on hypotetical future solutions and not on a current solution for
> the open issues, which brings us back to my point that we are defining a
> solution with open issues for which there is not a single realistic solution
> out there, thus making this draft not applicable to a real scenario.
> 
> I am not thinking of the UE connecting to more than one WLAN at the same time,
> but the UE being able to connect to different WLANs (one at a time) because
> the UE is e.g. provisioned with a list of SSIDs or the UE discovers a hotspot
> somewhere. I am talking about the scenario where the UE is capable to connect
> to WLAN, but the operator has different policies wrt which WLAN the UE should
> use or not.
> 
> operators for which it might need to pay an extra fee or where e.g. no QoS can
> be guaranteed. That means that the entity deciding whether traffic needs to be
> routed on WLAN or not cannot just consider "WLAN is available", but "WLAN
> SSIDx is available", so that the decision can be based on the operator
> an issue because we are defining a solution that should be applicable to 3GPP
> but does not meet the deployment scenarios of interest. In other words, if we
> want to make this solution applicable e.g. to 3GPP, we need to be able to
> provide the same functionality available today in 3GPP with other solution in
> order to satisfy the use cases supported by 3GPP, and not step backwards in
> terms of what can be supported.
> 
> Cheers,
> 
> Stefano
> 
>> You are right that the LMA does not know the SSID the mobile is connected to.
>> It¹s not clear if the MAG can get that from the MN either without additional
>> signaling. However, the LMA knows that the MN is connected to WLAN; so it can
>> apply the policy at the RAT type level. Are you thinking of the MN connecting
>> to more than one WLAN network (and each of those connections coming back to
>> the LMA)? If so, please explain the scenario.
>> 
>> Regards,
>> 
>> -Rajeev
>> 
>> 
>> 
>>

---

From: stefano faccin <[email-masked]>
Date: Wed, 2 Feb 2011 10:50:11 -0800

Raj,
thanks for the reply.

If the LMA has statically configured policies, how do we ensure that the MN
has the same policies? That would mean implicitly assuming that the policies
provisioned to the MN by the ANDSF "always" match what has been set in the
LMA, which I think it is unrealistic because the policies change over time,
and every time you need to update all the LMAs, which has a considerable
operational cost. Instead, if we leave the MN to make the choice, there are
easy and well specified mechanisms that allow the provisioning of policies
in the MN and for the MN to make such decision and communicate it to the
network, so that the network can

As for extensions to Gx, I am not stating that in theory one could extend
Gx. However, at present such solution does not exists, and without it, I do
not see how the draft is applicable to 3GPP that is at present the only
potential customer identified (I guess I did not see any other identified?)

Even assuming that Gx could be modified, the issue of the per-access network
granularity remains. Even if the LMA has the right policies in place, the
LMA has no way of knowing exactly what access network of a specific access
technology (e.g. which SSID for WLAN0 the MN is connecting to.

I cannot agree with your assumption below that if the MN connects to an SSID
it is because the operator is OK with routing traffic on that SSID, and that
we should just "trust the software on the MN". There are two aspects to
consider:
1) whether it is OK for certain traffic to be routed at all over a certain
access access network of a specific access technology
2) how different traffic should be routed over different access networks of
different access technologies

Regarding these two points, the issue is whether the operator wants to allow
traffic e.g. over a certain SSID or not. So, in that case, it is obvious as
you say that if the MN has connected to an SSID configured by the operator
in the MN, then traffic could be allowed over that SSID. However, we need to
consider that 3GPP allows the decision of which WLAN the MN can connect to
based on user preferences. This means that my MN can e.g. connect to my home
WLAN (which is not controlled necessarily by the operator and whose SSID the
operator does not know) or to a coffee shop WLAN, even if the device does
not have those SSID configured. Those are typical examples of untrusted WLAN
access networks. Therefore, in such cases, just because the MN has connected
to a WLAN SSID, does not mean that the operator wants to route certain
traffic over that SSID just because the policy says "route traffic X over
WLAN".

That brings us to a solution that, if applied to 3GPP, provides less
functionality than what is available and has been specified today, so back
to my point above.

Unfortunately, there is no solution I am aware of that allows the WLAN
network to indicate to the MAG/LMA the specific SSID (and as you say, there
is no easy solution for that). Due to this and the points above about policy
provisioning, it means that the applicability of this solution to a real
case like 3GPP depends on the feasibility of extending policy mechanisms in
3GPP, and the ability to have a solution where the WLAN network provides the
SSID information to the MAG/LMA. Moreover, the provisioning of such SSID is
not in the scope of IETF, but not even of 3GPP (since the interface between
the WLAN AP and the ePDG is not defined), thus I wonder how this could be
defined at all (I am afraid of asking what magic should happen here). So,
now we have two big dependencies.

In general, I am also wondering if there is a customer that has asked us to
define this solution. I am not aware of any but I may have missed that.

Cheers,
Stefano

On Wed, Feb 2, 2011 at 10:44 AM, Rajeev Koodli <[email-masked]> wrote:

> useful for 3GPP deployments. Second, if it’s not defined *today* in 3GPP,
> it’s not useful.
>
> I tend to agree with you on the first – 3GPP is a big potential customer.
> For the MN (IETF term for UE) to even connect to the MAG via WLAN today,
> you need an IPsec termination point (ePDG). If the operator pre-configures
> the list of SSIDs or there is some out-of-band mechanism to inform the MN
> which SSID is “white-listed”, then I expect the MN to decide when to connect
> to the ePDG and hence the MAG. At this point, the MN is already on the WLAN
> the operator cares about I presume.
> connected to – the network has to either trust the software on the MN or the
> If the draft allows decisions to be made only at the RAT level, then we
> have an issue because we are defining a solution that should be applicable
> to 3GPP but does not meet the deployment scenarios of interest. In other
> words, if we want to make this solution applicable e.g. to 3GPP, we need to
> be able to provide the same functionality available today in 3GPP with other

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 02 Feb 2011 11:28:22 -0800

Stefano,

Regardless of how the policy is configured on the LMA, there is a
consistency of the rules which needs to be ensured regardless. Whatever the
entity (OMA-DM?!) is that configures the policy has to ensure such a
consistency.

We can debate about how policy interaction works, but that¹s another topic.
I would note that there are choices here (modulo respective pros and cons).

I didn¹t suggest that an operator should just trust the software on a MN,
although I suspect some device vendors might argue for their robustness
(surprise?). 

I would frame the WLAN access problem as whether the access is considered
trusted or not. Accordingly, you apply the policy.

-Rajeev

On 2/2/11 10:50 AM, "stefano faccin" <[email-masked]> wrote:

> easy and well specified mechanisms that allow the provisioning of policies in
> the MN and for the MN to make such decision and communicate it to the network,
> so that the network can
> 
> As for extensions to Gx, I am not stating that in theory one could extend Gx.
> However, at present such solution does not exists, and without it, I do not
> see how the draft is applicable to 3GPP that is at present the only potential
> customer identified (I guess I did not see any other identified?) 
> 
> granularity remains. Even if the LMA has the right policies in place, the LMA
> has no way of knowing exactly what access network of a specific access
> you say that if the MN has connected to an SSID configured by the operator in
> the MN, then traffic could be allowed over that SSID. However, we need to
> operator does not know) or to a coffee shop WLAN, even if the device does not
> have those SSID configured. Those are typical examples of untrusted WLAN
> to a WLAN SSID, does not mean that the operator wants to route certain traffic
> over that SSID just because the policy says "route traffic X over WLAN". 
> 
> functionality than what is available and has been specified today, so back to
> my point above.
> 
> Unfortunately, there is no solution I am aware of that allows the WLAN network
> to indicate to the MAG/LMA the specific SSID (and as you say, there is no easy
> solution for that). Due to this and the points above about policy
> provisioning, it means that the applicability of this solution to a real case
> like 3GPP depends on the feasibility of extending policy mechanisms in 3GPP,
> and the ability to have a solution where the WLAN network provides the SSID
> information to the MAG/LMA. Moreover, the provisioning of such SSID is not in
> the scope of IETF, but not even of 3GPP (since the interface between the WLAN
> AP and the ePDG is not defined), thus I wonder how this could be defined at
> all (I am afraid of asking what magic should happen here). So, now we have two
> big dependencies.
> 
>> You make two interesting points: First, the defined solution should be useful
>> for 3GPP deployments. Second, if it¹s not defined today in 3GPP, it¹s not
>> useful.
>> 
>> SSID is ³white-listed², then I expect the MN to decide when to connect to the
>> ePDG and hence the MAG. At this point, the MN is already on the WLAN the
>> On 2/2/11 9:56 AM, "stefano faccin" <[email-masked]
>>> On Wed, Feb 2, 2011 at 9:55 AM, Rajeev Koodli <[email-masked]
>>> <http://[email-masked]> > wrote:
>>>> 
>>>> Hi Stefano,
>>>> 
>>>> Thanks for your input.
>>>> 
>>>> <http://[email-masked]>  <http://[email-masked]> > wrote:
>>>> 
>>>>> Raj,
>>>>> thanks for the email.
>>>>> 
>>>>> 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.
>>>>> 
>>>>> <http://[email-masked]>  <http://[email-masked]> >
>>>>> wrote:
>>>>>> 
>>>>>> Hello,
>>>>>> 
>>>>>> [email-masked] <http://[email-masked]>  <http://[email-masked]>

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 02 Feb 2011 11:46:27 -0800

Hi Gerardo,

* my point is that someone/something is configuring the policy on the MN
which needs to be in sync with the MN¹s partner, i.e., the network. If this
is not the case, please let me know.
* The last I heard, PMIP6 is applicable on the eHRPD (trusted non-3GPP
network). Also, 33.402 does not specify whether a particular type of access
network (such as WLAN) is considered trusted or untrusted (although a
majority of the WLAN access could be considered untrusted today).

-Rajeev

On 2/2/11 11:16 AM, "Giaretta, Gerardo" <[email-masked]> wrote:

> Hi Rajeev,
>  
> A couple of considerations on this:
>  
> -         This draft assumes there is consistency in the rules. This is a new
> requirement for the system architecture where this solution will be applied.
> There is no this requirement for other solutions already adopted by IETF and
> 3GPP. In my view this seems a fairly important issue.
> 
> -         The routing decisions based on WLAN SSID are different from
> trusted/untrusted. Note also that PMIPv6 cannot be used in trusted networks so
> it is not clear at all what you are referring to.
> 
>  
> Gerardo 
>  
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Rajeev Koodli
> Sent: Wednesday, February 02, 2011 11:28 AM
> To: stefano faccin
> Cc: [email-masked]; [email-masked]
> Subject: Re: [netext] Consensus call to adopt I-D:
> draft-bernardos-netext-pmipv6-flowmob as WG doc
>  
> 
> Stefano,
> 
> Regardless of how the policy is configured on the LMA, there is a consistency
> of the rules which needs to be ensured regardless. Whatever the entity
> (OMA-DM?!) is that configures the policy has to ensure such a consistency.
> 
> We can debate about how policy interaction works, but that¹s another topic. I
> would note that there are choices here (modulo respective pros and cons).
> 
> There are multiple ways I could envision policy on the LMA. Locally configured
> policy is one (which we use today in deployments) that does not need Gx
> interaction. Gx extensions can be proposed in the future. I hope you are not
> suggesting that these are not feasible choices.
>

---

From: stefano faccin <[email-masked]>
Date: Wed, 2 Feb 2011 11:28:22 -0800

Rajeev,

I am not sure what you refer to when you talk about consistency of the
policies. In solutions currently adopted, the policies are managed by a
network entity (ANDSF) that has no relationship with the LMA, and provided
to the MN, thus the ANDSF can easily ensure that the MN has the correct
policies. There is no need for further consistency since no other entity
needs to know or use such policies. As Gerardo says, requiring such
consistency is a considerable change to the system and a requirement that
has not been discussed before. I would actually consider this an open issue
with the current draft.

I think robustness or trusting the software here has no relevance. What is
relevant is the fact that just because a MN has selected a specific WLAN
SSID, it does not mean that the LMA can safely assume that certain traffic
can be carried above that specific WLAN just because (1) it is WLAN and (2)
the operator has configured the preferred SSIDs in the MN. As I said, the
user can select other SSIDs, as in current specified solutions.

Whether WLAN is trusted or not is another matter orthogonal to this
discussion. An operator may deploy WLAN APs that it owns but, due to e.g.
the fact that the same operator does not control the interconnection between
the AP and its own core network (as it will happen often), the operator
decides to consider that access untrusted and therefore require the use of
an ePDG. Therefore, just because the MN uses one of the SSIDs configured by
the operator as preferred, does not mean that the access is considered
trusted.

Cheers,
Stefano

On Wed, Feb 2, 2011 at 11:16 AM, Giaretta, Gerardo <[email-masked]>wrote:

> -          This draft assumes there is consistency in the rules. This is a
> new requirement for the system architecture where this solution will be
> applied. There is no this requirement for other solutions already adopted by
> IETF and 3GPP. In my view this seems a fairly important issue.
>
> trusted/untrusted. Note also that PMIPv6 cannot be used in trusted networks
> so it is not clear at all what you are referring to.
>
>
>
> Gerardo
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Rajeev Koodli
> *Sent:* Wednesday, February 02, 2011 11:28 AM
> *To:* stefano faccin
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [netext] Consensus call to adopt I-D:
> We can debate about how policy interaction works, but that’s another topic.
> I didn’t suggest that an operator should just trust the software on a MN,
> Even assuming that Gx could be modified, the issue of the per-access
> network granularity remains. Even if the LMA has the right policies in
> place, the LMA has no way of knowing exactly what access network of a
> specific access technology (e.g. which SSID for WLAN0 the MN is connecting
> to.
>
> I cannot agree with your assumption below that if the MN connects to an
> SSID it is because the operator is OK with routing traffic on that SSID, and
> that we should just "trust the software on the MN". There are two aspects to
> consider:
> Regarding these two points, the issue is whether the operator wants to
> allow traffic e.g. over a certain SSID or not. So, in that case, it is
> obvious as you say that if the MN has connected to an SSID configured by the
> operator in the MN, then traffic could be allowed over that SSID. However,
> we need to consider that 3GPP allows the decision of which WLAN the MN can
> connect to based on user preferences. This means that my MN can e.g. connect
> to my home WLAN (which is not controlled necessarily by the operator and
> whose SSID the operator does not know) or to a coffee shop WLAN, even if the
> device does not have those SSID configured. Those are typical examples of
> untrusted WLAN access networks. Therefore, in such cases, just because the
> MN has connected to a WLAN SSID, does not mean that the operator wants to
> route certain traffic over that SSID just because the policy says "route
> traffic X over WLAN".
>
> On 2/2/11 9:56 AM, "stefano faccin" <[email-masked] <
> On Wed, Feb 2, 2011 at 9:55 AM, Rajeev Koodli <[email-masked] <
> http://[email-masked]> > wrote:
>
>
> Hi Stefano,
>
> Thanks for your input.
>
> http://[email-masked]>  <http://[email-masked]> > wrote:
>
> Raj,
> thanks for the email.
>
> http://[email-masked]>  <http://[email-masked]> >
> wrote:
>
>
> Hello,
>

---

From: stefano faccin <[email-masked]>
Date: Wed, 2 Feb 2011 11:40:40 -0800

Sorry, I forgot to reply to the whole list.
Cheers,
Stefano

On Wed, Feb 2, 2011 at 11:29 AM, stefano faccin <[email-masked]>wrote:

> Hi Rajeev,
> in current solution the policy is in sync, since it is the ANDSF (the
> network counterpart of the MN for the policy) that configures it in the MN.
> That does not mean that the LMA has such policy.
>
> Cheers,
> Stefano
>
>
> On Wed, Feb 2, 2011 at 11:46 AM, Rajeev Koodli <[email-masked]> wrote:
>
>>
>> Hi Gerardo,
>>
>>
>>    - my point is that someone/something is configuring the policy on the
>>    MN which needs to be in sync with the MN’s partner, i.e., the network. If
>>    this is not the case, please let me know.
>>    - The last I heard, PMIP6 is applicable on the eHRPD (trusted non-3GPP
>> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
>> *On Behalf Of *Rajeev Koodli
>> We can debate about how policy interaction works, but that’s another
>> topic. I would note that there are choices here (modulo respective pros and
>> cons).
>>
>> If the LMA has statically configured policies, how do we ensure that the
>> MN has the same policies? That would mean implicitly assuming that the
>> policies provisioned to the MN by the ANDSF "always" match what has been set
>> in the LMA, which I think it is unrealistic because the policies change over
>> time, and every time you need to update all the LMAs, which has a
>> considerable operational cost. Instead, if we leave the MN to make the
>> choice, there are easy and well specified mechanisms that allow the
>> provisioning of policies in the MN and for the MN to make such decision and
>> communicate it to the network, so that the network can
>>
>> 2) how different traffic should be routed over different access networks
>> of different access technologies
>>
>> In general, I am also wondering if there is a customer that has asked us
>> to define this solution. I am not aware of any but I may have missed that.
>>
>> Cheers,
>> Stefano
>>
>> There is no easy way for the network (LMA, MAG) to know what SSID the MN
>> is connected to – the network has to either trust the software on the MN or
>> the WLAN infrastructure has to provide the SSID information to the network.
>>
>> -Rajeev
>>
>>
>>
>> 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

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 02 Feb 2011 12:02:49 -0800

We might be speaking of related but slightly different things here.
I am referring to how the traffic is managed at the LMA, which needs to know
how to route traffic over which interface.
I am calling this ³policy². If the LMA has no idea about this (because it is
not specified yet in 3GPP), we need to specify it.

I agree that selecting a particular SSID does not imply ³safety² - I
mentioned the issue of reliably knowing which WLAN network the MN is
attached to. What solutions do exist today?

What you describe below about an operator deploying its own AP but not
owning the interconnection defaults to one of the two cases again  its
either considered trusted or not. I do agree that the distinction between
the operator¹s own (trusted) WLAN and the operator¹s roaming partner
(trusted) WLAN is useful; I just don¹t know how you would determine this
based on the (un)reliability of SSID.

-Rajeev

On 2/2/11 11:28 AM, "stefano faccin" <[email-masked]> wrote:

> network entity (ANDSF) that has no relationship with the LMA, and provided to
> the MN, thus the ANDSF can easily ensure that the MN has the correct policies.
> There is no need for further consistency since no other entity needs to know
> or use such policies. As Gerardo says, requiring such consistency is a
> considerable change to the system and a requirement that has not been
> discussed before. I would actually consider this an open issue with the
> current draft.
> 
> relevant is the fact that just because a MN has selected a specific WLAN SSID,
> it does not mean that the LMA can safely assume that certain traffic can be
> carried above that specific WLAN just because (1) it is WLAN and (2) the
> operator has configured the preferred SSIDs in the MN. As I said, the user can
> select other SSIDs, as in current specified solutions.
> 
> discussion. An operator may deploy WLAN APs that it owns but, due to e.g. the
> fact that the same operator does not control the interconnection between the
> AP and its own core network (as it will happen often), the operator decides to
> consider that access untrusted and therefore require the use of an ePDG.
> Therefore, just because the MN uses one of the SSIDs configured by the
> operator as preferred, does not mean that the access is considered trusted.
> 
> Cheers,
> Stefano 
> 
>> On 2/2/11 10:50 AM, "stefano faccin" <[email-masked]
>> the MN and for the MN to make such decision and communicate it to the
>> all (I am afraid of asking what magic should happen here). So, now we have
>> two big dependencies.
>> 
>> On Wed, Feb 2, 2011 at 10:44 AM, Rajeev Koodli <[email-masked]
>> realistic solution out there, thus making this draft not applicable to a real
>> scenario.
>> 
>> because the UE is e.g. provisioned with a list of SSIDs or the UE discovers a
>> hotspot somewhere. I am talking about the scenario where the UE is capable to
>> connect to WLAN, but the operator has different policies wrt which WLAN the
>> UE should use or not.
>> 
>> <http://[email-masked]>  <http://[email-masked]> > wrote:
>> 
>> Hi Stefano,
>> 
>> Thanks for your input.
>> 
>> <http://[email-masked]>  <http://[email-masked]>
>> 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
>> 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
>> <http://[email-masked]>  <http://[email-masked]>
>>  <http://[email-masked]>

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Wed, 2 Feb 2011 14:56:58 -0500

Stefano,

As much as I agree with most of your points about the problem from the
3GPP architecture point of view, I think that there is more than one
solution.

We are assuming of course that what we have is a scenario where both
networks are in the same PMIP domain and IP flow mobility is then
possible. You point out that there are no means to convey policies to
the LMA or MAG. However, there are means to convey these policies to the
MN as it is already defined in 3GPP for the client-based IP flow
mobility case (i.e. ANDSF). Hence, one different solution could be to
let the MN apply the policy by moving the flow and make the MAG and LMA
"react" to the IP flow change assuming that the flow change was made
according to the policy being applied at the mobile.

I would see this scenario equivalent to the one specified in 3GPP from
the point of view of node's responsibilities, don't you think?

Jc

From: [email-masked] [mailto:[email-masked]] On Behalf
Of stefano faccin
Sent: February 2, 2011 2:41 PM
To: Rajeev Koodli; [email-masked]
Subject: Re: [netext] Consensus call to adopt I-D:
draft-bernardos-netext-pmipv6-flowmob as WG doc

On Wed, Feb 2, 2011 at 11:29 AM, stefano faccin <[email-masked]>
wrote:

Hi Rajeev,
in current solution the policy is in sync, since it is the ANDSF (the
network counterpart of the MN for the policy) that configures it in the
MN. That does not mean that the LMA has such policy. 

Cheers,
Stefano

On Wed, Feb 2, 2011 at 11:46 AM, Rajeev Koodli <[email-masked]>
wrote:

Hi Gerardo,

*	my point is that someone/something is configuring the policy on
the MN which needs to be in sync with the MN's partner, i.e., the
network. If this is not the case, please let me know. 
*	The last I heard, PMIP6 is applicable on the eHRPD (trusted
non-3GPP network). Also, 33.402 does not specify whether a particular
type of access network (such as WLAN) is considered trusted or untrusted
(although a majority of the WLAN access could be considered untrusted
today). 

-Rajeev

	Hi Rajeev,

	-         This draft assumes there is consistency in the rules.
This is a new requirement for the system architecture where this
solution will be applied. There is no this requirement for other
solutions already adopted by IETF and 3GPP. In my view this seems a
fairly important issue.
	
	-         The routing decisions based on WLAN SSID are different
from trusted/untrusted. Note also that PMIPv6 cannot be used in trusted
networks so it is not clear at all what you are referring to.

	Gerardo 

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Rajeev Koodli
	Sent: Wednesday, February 02, 2011 11:28 AM
	To: stefano faccin
	Cc: [email-masked]; [email-masked]
	Subject: Re: [netext] Consensus call to adopt I-D:
draft-bernardos-netext-pmipv6-flowmob as WG doc

	Stefano,
	
	Regardless of how the policy is configured on the LMA, there is
a consistency of the rules which needs to be ensured regardless.
Whatever the entity (OMA-DM?!) is that configures the policy has to
ensure such a consistency.
	
	We can debate about how policy interaction works, but that's
another topic. I would note that there are choices here (modulo
respective pros and cons).
	
	I didn't suggest that an operator should just trust the software
on a MN, although I suspect some device vendors might argue for their
robustness (surprise?). 
	
	I would frame the WLAN access problem as whether the access is
considered trusted or not. Accordingly, you apply the policy.
	
	-Rajeev

	On 2/2/11 10:50 AM, "stefano faccin" <[email-masked]>
wrote:
	Raj,
	thanks for the reply.
	
	If the LMA has statically configured policies, how do we ensure
that the MN has the same policies? That would mean implicitly assuming
that the policies provisioned to the MN by the ANDSF "always" match what
has been set in the LMA, which I think it is unrealistic because the
policies change over time, and every time you need to update all the
LMAs, which has a considerable operational cost. Instead, if we leave
the MN to make the choice, there are easy and well specified mechanisms
that allow the provisioning of policies in the MN and for the MN to make
such decision and communicate it to the network, so that the network can

	As for extensions to Gx, I am not stating that in theory one
could extend Gx. However, at present such solution does not exists, and
without it, I do not see how the draft is applicable to 3GPP that is at
present the only potential customer identified (I guess I did not see
any other identified?)  
	
	Even assuming that Gx could be modified, the issue of the
per-access network granularity remains. Even if the LMA has the right
policies in place, the LMA has no way of knowing exactly what access
network of a specific access technology (e.g. which SSID for WLAN0 the
MN is connecting to. 
	
	I cannot agree with your assumption below that if the MN
connects to an SSID it is because the operator is OK with routing
traffic on that SSID, and that we should just "trust the software on the
MN". There are two aspects to consider:
	1) whether it is OK for certain traffic to be routed at all over
a certain access access network of a specific access technology
	2) how different traffic should be routed over different access
networks of different access technologies
	
	Regarding these two points, the issue is whether the operator
wants to allow traffic e.g. over a certain SSID or not. So, in that
case, it is obvious as you say that if the MN has connected to an SSID
configured by the operator in the MN, then traffic could be allowed over
that SSID. However, we need to consider that 3GPP allows the decision of
which WLAN the MN can connect to based on user preferences. This means
that my MN can e.g. connect to my home WLAN (which is not controlled
necessarily by the operator and whose SSID the operator does not know)
or to a coffee shop WLAN, even if the device does not have those SSID
configured. Those are typical examples of untrusted WLAN access
networks. Therefore, in such cases, just because the MN has connected to
a WLAN SSID, does not mean that the operator wants to route certain
traffic over that SSID just because the policy says "route traffic X
over WLAN". 
	
	That brings us to a solution that, if applied to 3GPP, provides
less functionality than what is available and has been specified today,
so back to my point above.
	
	Unfortunately, there is no solution I am aware of that allows
the WLAN network to indicate to the MAG/LMA the specific SSID (and as
you say, there is no easy solution for that). Due to this and the points
above about policy provisioning, it means that the applicability of this
solution to a real case like 3GPP depends on the feasibility of
extending policy mechanisms in 3GPP, and the ability to have a solution
where the WLAN network provides the SSID information to the MAG/LMA.
Moreover, the provisioning of such SSID is not in the scope of IETF, but
not even of 3GPP (since the interface between the WLAN AP and the ePDG
is not defined), thus I wonder how this could be defined at all (I am
afraid of asking what magic should happen here). So, now we have two big
dependencies. 
	
	In general, I am also wondering if there is a customer that has
asked us to define this solution. I am not aware of any but I may have
missed that.
	
	Cheers,
	Stefano
	
	On Wed, Feb 2, 2011 at 10:44 AM, Rajeev Koodli
<[email-masked]> wrote:
	
	Hi Stefano,
	
	You make two interesting points: First, the defined solution
should be useful for 3GPP deployments. Second, if it's not defined today
in 3GPP, it's not useful.
	
	I tend to agree with you on the first - 3GPP is a big potential
customer. 
	I cannot agree with your second point.
	
	There are multiple ways I could envision policy on the LMA.
Locally configured policy is one (which we use today in deployments)
that does not need Gx interaction. Gx extensions can be proposed in the
future. I hope you are not suggesting that these are not feasible
choices.
	
	For the MN (IETF term for UE) to even connect to the MAG via
WLAN today, you need an IPsec termination point (ePDG). If the operator
pre-configures the list of SSIDs or there is some out-of-band mechanism
to inform the MN which SSID is "white-listed", then I expect the MN to
decide when to connect to the ePDG and hence the MAG. At this point, the
MN is already on the WLAN the operator cares about I presume. 
	There is no easy way for the network (LMA, MAG) to know what
SSID the MN is connected to - the network has to either trust the
software on the MN or the WLAN infrastructure has to provide the SSID
information to the network. 
	
	-Rajeev

	On 2/2/11 9:56 AM, "stefano faccin" <[email-masked]
<http://[email-masked]> > wrote:
	Hello rajeev,
	the use of PCRF is an interesting suggestion. However,
unfortunately, PCRF does not contain any policies or information that
will tell the LMA what are the policies to be used for decisions of IP
flow mobility. This is not part of current PCC functionality, and there
is no work ongoing or planned to extend PCC in such way. Therefore, the
applicability of the solution in this draft would hinge on hypotetical
future solutions and not on a current solution for the open issues,
which brings us back to my point that we are defining a solution with
open issues for which there is not a single realistic solution out
there, thus making this draft not applicable to a real scenario.
	
	I am not thinking of the UE connecting to more than one WLAN at
the same time, but the UE being able to connect to different WLANs (one
at a time) because the UE is e.g. provisioned with a list of SSIDs or
the UE discovers a hotspot somewhere. I am talking about the scenario
where the UE is capable to connect to WLAN, but the operator has
different policies wrt which WLAN the UE should use or not.
	
	If you have followed the work in 3GPP, it is clear that
operators have interest in applying policies not only at RAT level, but
also at access network level (please see how ANDSF was defined and why).
I guess we can all agree that an operator deploying PMIP-based mobility
may be interested in having policies that allow traffic on the WLAN the
operator owns or that belongs to a roaming partner, while not allowing
traffic on WLAN of other operators for which it might need to pay an
extra fee or where e.g. no QoS can be guaranteed. That means that the
entity deciding whether traffic needs to be routed on WLAN or not cannot
just consider "WLAN is available", but "WLAN SSIDx is available", so
that the decision can be based on the operator preferences as to which
WLAN certain traffic needs to be routed on. 
	
	If the draft allows decisions to be made only at the RAT level,
then we have an issue because we are defining a solution that should be
applicable to 3GPP but does not meet the deployment scenarios of
interest. In other words, if we want to make this solution applicable
e.g. to 3GPP, we need to be able to provide the same functionality
available today in 3GPP with other solution in order to satisfy the use
cases supported by 3GPP, and not step backwards in terms of what can be
supported.
	
	Cheers,
	
	Stefano

	Hi Stefano,
	
	Thanks for your input.
	
	I expect the LMA interacting with PCRF for policy rules specific
to the subscriber for different RAT types.
	You are right that the LMA does not know the SSID the mobile is
connected to. It's not clear if the MAG can get that from the MN either
without additional signaling. However, the LMA knows that the MN is
connected to WLAN; so it can apply the policy at the RAT type level. Are
you thinking of the MN connecting to more than one WLAN network (and
each of those connections coming back to the LMA)? If so, please explain
the scenario.
	
	Regards,
	
	-Rajeev

	
	
	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

	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

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Wed, 2 Feb 2011 15:37:35 -0500

Hi Stefano,

Thanks for the response (you forgot to copy the list again ;). 

What I had in mind was what they call Basic solution in the document, in
which the same set of prefixes are assigned to different interfaces (or
MAGs). In this case the MN can decide (based on policies) to change the
flow and send packets over a new interface. The MAG would forward the
packet with no problem and upon receiving this packet the LMA would
implicitly know that the MN has performed a flow movement (again, based
on policies). At this point the LMA would just need to change its
routing table accordingly and start sending packets for this flow over
the new interface (similar rule to the one already specified for the
mobile).

I see this as a lightweight solution to the problem you pointed out that
could easily be added to the document.

Jc

From: stefano faccin [mailto:[email-masked]] 
Sent: February 2, 2011 3:11 PM
To: Zuniga, Juan Carlos
Subject: Re: [netext] Consensus call to adopt I-D:
draft-bernardos-netext-pmipv6-flowmob as WG doc

Hi JC,

As you say in 3GPP for the MN-based model this has been solved. However,
if we want to apply a similar solution, we go back to the argument that
it would require the MN to be able to communicate the decisions to the
MAG/LMA but, as we discussed previously, we don't have a solution for
that. This means that applying this protocol with a model similar to the
one currently specified in IETF and 3GPP requires the definition of a
solution that does not yet exist (at Layer 3 or at Layer 2). I am
concerned about developing only some pieces of a solution.

Alternatively, as you say the MAG reacts. However, it is not clear to me
that the current draft describes how that happens.

Cheers,
Stefano

On Wed, Feb 2, 2011 at 11:56 AM, Zuniga, Juan Carlos
<[email-masked]> wrote:

Stefano,

Jc

Hi Rajeev,

Cheers,
Stefano

Hi Gerardo,

-Rajeev

	Hi Rajeev,

	

	Gerardo 

	Stefano,

	

	-Rajeev

	

	

	
	Cheers,
	Stefano

	Hi Stefano,

	

	-Rajeev

	

	
	Cheers,
	
	Stefano

	Hi Stefano,
	
	Thanks for your input.

	Regards,
	
	-Rajeev

	

	

	Cheers,
	Stefano

	Hello,

	
	
	-Basavaraj

---

From: stefano faccin <[email-masked]>
Date: Wed, 2 Feb 2011 14:26:28 -0800

Hello JC,
thanks for acknowledging that there is indeed an issue with the current
draft.

For my clarification, how would the "MAG forward the packet with no
problem"? I am not sure I am understanding what the sequence of steps would
be.

Also, I guess that as you say the solution is not included in the current
draft, which means modifying the protocol that we have in the current draft.

Cheers,
Stefano

On Wed, Feb 2, 2011 at 12:37 PM, Zuniga, Juan Carlos <
[email-masked]> wrote:

> MAGs). In this case the MN can decide (based on policies) to change the flow
> and send packets over a new interface. The MAG would forward the packet with
> no problem and upon receiving this packet the LMA would implicitly know that
> the MN has performed a flow movement (again, based on policies). At this
> point the LMA would just need to change its routing table accordingly and
> start sending packets for this flow over the new interface (similar rule to
> the one already specified for the mobile).
>
>
>
> *From:* stefano faccin [mailto:[email-masked]]
> *Sent:* February 2, 2011 3:11 PM
> *To:* Zuniga, Juan Carlos
>
> As you say in 3GPP for the MN-based model this has been solved. However, if
> we want to apply a similar solution, we go back to the argument that it
> would require the MN to be able to communicate the decisions to the MAG/LMA
> but, as we discussed previously, we don't have a solution for that. This
> means that applying this protocol with a model similar to the one currently
> specified in IETF and 3GPP requires the definition of a solution that does
> not yet exist (at Layer 3 or at Layer 2). I am concerned about developing
> only some pieces of a solution.
>
> On Wed, Feb 2, 2011 at 11:56 AM, Zuniga, Juan Carlos <
> [email-masked]> wrote:
>
> Stefano,
>
>
>
> As much as I agree with most of your points about the problem from the 3GPP
> architecture point of view, I think that there is more than one solution.
>
>
>
> networks are in the same PMIP domain and IP flow mobility is then possible.
> You point out that there are no means to convey policies to the LMA or MAG.
> However, there are means to convey these policies to the MN as it is already
> defined in 3GPP for the client-based IP flow mobility case (i.e. ANDSF).
> Hence, one different solution could be to let the MN apply the policy by
> moving the flow and make the MAG and LMA “react” to the IP flow change
> assuming that the flow change was made according to the policy being applied
> at the mobile.
>
>
>
> I would see this scenario equivalent to the one specified in 3GPP from the
> point of view of node’s responsibilities, don’t you think?
>
>
>
> Jc
>
>
>
>
>
> Behalf Of *stefano faccin
> *Sent:* February 2, 2011 2:41 PM
> *To:* Rajeev Koodli; [email-masked]
>
>

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 02 Feb 2011 23:52:34 +0100

Hi Stefano,

Thanks for the comments on the draft. Two comments from my side:

- Regarding the comment about the potential realistic scenario for
applicability, this is not an issue of this solution (or any other), if
it is an issue at all. We are chartered to work on protocol extensions
for flow mobility without introducing any changes to the IP stack of the
MN. IMHO all your comments on this regard relates to the charter itself,
not this draft.

- Regarding the comments about the "lack of support from 3GPP", I
acknowledge that 3GPP is an important potential customer, but as far as
I know, we are not chartered to come up with a 3GPP-only solution, and I
think it's fair to design a solution that works under certain
assumptions, as long as those assumptions cannot realistically be met in
a particular network deployment. I think it's fair to expect that 3GPP
may need to add also extensions to make this solution work in their
architecture.

Thanks,

Carlos

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 2 Feb 2011 14:54:18 -0800 (PST)

Hi Stefano,
  This draft addresses:      
IP Flow Mobility and Seamless Offload (IFOM) on S2a and S2b interfaces.
As we already have a solution (in RFC 6088 and 6089) for s2c, this document aims 

to address the missing part.

The issues you raised are out of scope for the document.

Regards,

Behcet

>Hello JC,
>thanks for acknowledging that there is indeed an issue with the current draft. 
>
>For my clarification, how would the "MAG forward the packet with no problem"? I 

>am not sure I am understanding what the sequence of steps would be. 
>
>
>Also, I guess that as you say the solution is not included in the current draft, 
>
>which means modifying the protocol that we have in the current draft.
>
>Cheers,
>Stefano
>
>
>On Wed, Feb 2, 2011 at 12:37 PM, Zuniga, Juan Carlos 
>>What I had in mind was what they call Basic solution in the document, in which 

>>the same set of prefixes are assigned to different interfaces (or MAGs). In this 
>>
>>case the MN can decide (based on policies) to change the flow and send packets 

>>over a new interface. The MAG would forward the packet with no problem and upon 
>
>>receiving this packet the LMA would implicitly know that the MN has performed a 
>
>>flow movement (again, based on policies). At this point the LMA would just need 
>
>>to change its routing table accordingly and start sending packets for this flow 
>
>>over the new interface (similar rule to the one already specified for the 
>>mobile).
>> 
>>I see this as a lightweight solution to the problem you pointed out that could 

>>easily be added to the document.
>> 
>>Jc
>> 
>> 
>> 
>>From:stefano faccin [mailto:[email-masked]] 
>>As you say in 3GPP for the MN-based model this has been solved. However, if we 

>>want to apply a similar solution, we go back to the argument that it would 
>>require the MN to be able to communicate the decisions to the MAG/LMA but, as we 
>>
>>discussed previously, we don't have a solution for that. This means that 
>>applying this protocol with a model similar to the one currently specified in 
>>IETF and 3GPP requires the definition of a solution that does not yet exist (at 
>
>>Layer 3 or at Layer 2). I am concerned about developing only some pieces of a 
>>solution.
>>
>>Alternatively, as you say the MAG reacts. However, it is not clear to me that 
>>the current draft describes how that happens.
>>
>>Cheers,
>>Stefano
>>We are assuming of course that what we have is a scenario where both networks 
>>are in the same PMIP domain and IP flow mobility is then possible. You point out 
>>
>>that there are no means to convey policies to the LMA or MAG. However, there are 
>>
>>means to convey these policies to the MN as it is already defined in 3GPP for 
>>the client-based IP flow mobility case (i.e. ANDSF). Hence, one different 
>>solution could be to let the MN apply the policy by moving the flow and make the 
>>
>>MAG and LMA “react” to the IP flow change assuming that the flow change was made 
>>
>>I would see this scenario equivalent to the one specified in 3GPP from the point 
>>
>>of view of node’s responsibilities, don’t you think?
>> 
>>Jc
>> 
>> 
>>From:[email-masked] [mailto:[email-masked]] On Behalf Of 
>>stefano faccin
>>On Wed, Feb 2, 2011 at 11:29 AM, stefano faccin <[email-masked]> wrote:
>>Hi Rajeev,
>>in current solution the policy is in sync, since it is the ANDSF (the network 
>>counterpart of the MN for the policy) that configures it in the MN. That does 
>>not mean that the LMA has such policy. 
>>
>>
>>Cheers,
>>Stefano
>> 
>>which needs to be in      sync with the MN’s partner, i.e., the network. If this 
>>

>>>From:[email-masked] [mailto:[email-masked]] On Behalf Of 
>>>Rajeev Koodli
>>>Regardless of how the policy is configured on the LMA, there is a consistency of 
>>>
>>>the rules which needs to be ensured regardless. Whatever the entity (OMA-DM?!) 
>
>>>is that configures the policy has to ensure such a consistency.
>>>
>>>We can debate about how policy interaction works, but that’s another topic. I 

>>>If the LMA has statically configured policies, how do we ensure that the MN has 
>>
>>>the same policies? That would mean implicitly assuming that the policies 
>>>provisioned to the MN by the ANDSF "always" match what has been set in the LMA, 
>>
>>>which I think it is unrealistic because the policies change over time, and every 
>>>
>>>time you need to update all the LMAs, which has a considerable operational cost. 
>>>
>>>Instead, if we leave the MN to make the choice, there are easy and well 
>>>specified mechanisms that allow the provisioning of policies in the MN and for 
>
>>>the MN to make such decision and communicate it to the network, so that the 
>>>network can 
>>>
>>>

>>>However, at present such solution does not exists, and without it, I do not see 
>>
>>>how the draft is applicable to 3GPP that is at present the only potential 

>>>I cannot agree with your assumption below that if the MN connects to an SSID it 
>>
>>>is because the operator is OK with routing traffic on that SSID, and that we 
>>>should just "trust the software on the MN". There are two aspects to 
consider:
>>>traffic e.g. over a certain SSID or not. So, in that case, it is obvious as you 
>>
>>>say that if the MN has connected to an SSID configured by the operator in the 

>>>MN, then traffic could be allowed over that SSID. However, we need to consider 
>
>>>that 3GPP allows the decision of which WLAN the MN can connect to based on user 
>>
>>>preferences. This means that my MN can e.g. connect to my home WLAN (which is 

>>>not controlled necessarily by the operator and whose SSID the operator does not 
>>
>>>know) or to a coffee shop WLAN, even if the device does not have those SSID 
>>>configured. Those are typical examples of untrusted WLAN access networks. 
>>>Therefore, in such cases, just because the MN has connected to a WLAN SSID, does 
>>>
>>>not mean that the operator wants to route certain traffic over that SSID just 

>>>because the policy says "route traffic X over WLAN". 
>>>
>>>
>>>functionality than what is available and has been specified today, so back to my 
>>>
>>>point above.
>>>
>>>solution for that). Due to this and the points above about policy provisioning, 
>>
>>>it means that the applicability of this solution to a real case like 3GPP 
>>>depends on the feasibility of extending policy mechanisms in 3GPP, and the 
>>>ability to have a solution where the WLAN network provides the SSID information 
>>
>>>to the MAG/LMA. Moreover, the provisioning of such SSID is not in the scope of 
>
>>>IETF, but not even of 3GPP (since the interface between the WLAN AP and the ePDG 
>>>
>>>is not defined), thus I wonder how this could be defined at all (I am afraid of 
>>
>>>asking what magic should happen here). So, now we have two big dependencies. 
>>>
>>>

>>>for 3GPP deployments. Second, if it’s not defined today in 3GPP, it’s not 
>>>useful.
>>>
>>>need an IPsec termination point (ePDG). If the operator pre-configures the list 
>>
>>>of SSIDs or there is some out-of-band mechanism to inform the MN which SSID is 
>
>>>“white-listed”, then I expect the MN to decide when to connect to the ePDG and 
>
>>>hence the MAG. At this point, the MN is already on the WLAN the operator cares 
>
>>>about I presume. 
>>>
>>>the use of PCRF is an interesting suggestion. However, unfortunately, PCRF does 
>>
>>>not contain any policies or information that will tell the LMA what are the 
>>>policies to be used for decisions of IP flow mobility. This is not part of 
>>>current PCC functionality, and there is no work ongoing or planned to extend PCC 
>>>
>>>in such way. Therefore, the applicability of the solution in this draft would 

>>>hinge on hypotetical future solutions and not on a current solution for the open 
>>>
>>>issues, which brings us back to my point that we are defining a solution with 

>>>open issues for which there is not a single realistic solution out there, thus 
>
>>>making this draft not applicable to a real scenario.
>>>
>>>but the UE being able to connect to different WLANs (one at a time) because the 
>>
>>>UE is e.g. provisioned with a list of SSIDs or the UE discovers a hotspot 
>>>somewhere. I am talking about the scenario where the UE is capable to connect to 
>>>
>>>WLAN, but the operator has different policies wrt which WLAN the UE should use 
>
>>>or not.
>>>
>>>If you have followed the work in 3GPP, it is clear that operators have interest 
>>
>>>in applying policies not only at RAT level, but also at access network level 
>>>(please see how ANDSF was defined and why). I guess we can all agree that an 
>>>operator deploying PMIP-based mobility may be interested in having policies that 
>>>
>>>allow traffic on the WLAN the operator owns or that belongs to a roaming 
>>>partner, while not allowing traffic on WLAN of other operators for which it 
>>>might need to pay an extra fee or where e.g. no QoS can be guaranteed. That 
>>>means that the entity deciding whether traffic needs to be routed on WLAN or not 
>>>
>>>cannot just consider "WLAN is available", but "WLAN SSIDx is available", so that 
>>>
>>>the decision can be based on the operator preferences as to which WLAN certain 
>
>>>traffic needs to be routed on. 
>>>
>>>
>>>If the draft allows decisions to be made only at the RAT level, then we have an 
>>
>>>issue because we are defining a solution that should be applicable to 3GPP but 
>
>>>does not meet the deployment scenarios of interest. In other words, if we want 
>
>>>to make this solution applicable e.g. to 3GPP, we need to be able to provide the 
>>>
>>>same functionality available today in 3GPP with other solution in order to 
>>>satisfy the use cases supported by 3GPP, and not step backwards in terms of what 
>>>
>>>can be supported.
>>>
>>>Cheers,
>>>
>>>Stefano
>>>

>>>It’s not clear if the MAG can get that from the MN either without additional 

>>>apply the policy at the RAT type level. Are you thinking of the MN connecting to 
>>>
>>>more than one WLAN network (and each of those connections coming back to the 
>>>LMA)? If so, please explain the scenario.
>>>
>>>Regards,
>>>
>>>-Rajeev
>>>
>>>
>>>
>>>
>>>I need to apologize in advance if my questions have already been answered before 
>>>
>>>(though I cannot find a conclusive answer anywhere).
>>>
>>>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

---

From: Julien Laganier <[email-masked]>
Date: Wed, 2 Feb 2011 15:06:34 -0800

Raj,

As with the other draft (logical interface), I have raised a number of
issues with this draft that in my humble opinion have not been addressed
adequately, and thus at this stage I believe that asking for adoption is
premature. In other words, I'd like the issues that I've raised to be
addressed by the authors before I feel comfortable having an opinion on
whether or not this draft is a good basis to progress the flow mobility
extensions.

Thank you for your consideration,

--julien

---

From: stefano faccin <[email-masked]>
Date: Wed, 2 Feb 2011 15:18:33 -0800

Hello Carlos,
unfortunately I beg to disagree. Indeed we are chartered to do this work,
but at the same time developing a protocol that due to technical limitations
cannot be adopted in realistic scenarios seems a fruitless effort.

I would also beg to disagree that 3GPP will have to modify their
architecture to allow this solution to work. I believe that, if 3GPP is to
be a customer, the protocol must be developed to fit the need of the
customer, not the other way around.

Cheers,
Stefano

2011/2/2 Carlos Jesús Bernardos Cano <[email-masked]>

> flow
> 3GPP
> possible.
> the
> MN.
> topic.
> considered
> connected
> answered
> definition
> which
> rather
> > > http://[email-masked]>  <http://[email-masked]>
> >
> > > wrote:
> > >
> > > Hello,
> > >

---

From: stefano faccin <[email-masked]>
Date: Wed, 2 Feb 2011 15:21:57 -0800

Behcet,
thanks for the reminder that we are indeed targeting 3GPP and specific
interfaces as our customer. Indeed if a working solution that fits the
framework of S2a and S2b is designed, it could be used at the discretion of
3GPP. However, if "a missing part" needs to be provided, I believe the
technical issues I raise are indeed in the scope and need to be addressed in
order to make the protocol applicable to the customer. Expecting to define a
solution that does not fit the customer and throwing the protocol over the
fence to them to fix their part to make the protocol work does not sound
like a good design approach to me.

Cheers,
Stefano

On Wed, Feb 2, 2011 at 2:54 PM, Behcet Sarikaya <[email-masked]>wrote:

> problem"? I
> draft,
> could
> if we
> that
> networks
> the point
> >>From:[email-masked] <[email-masked]> [mailto:
> [email-masked]] On Behalf Of
> >>stefano faccin
> network
> >>    * my point is that      someone/something is configuring the policy
> on the
> >>MN
> >>
> non-3GPP
> >>>From:[email-masked] <[email-masked]> [mailto:
> [email-masked]] On Behalf Of
> >>>Rajeev Koodli
> consistency of
> topic. I
> MN has
> network
> SSID it
> allow
> networks.
> network
> provisioning,
> afraid of
> to
> useful
> configured
> you
> is
> there, thus
> time,
> interest
> have an
> connected to.
> answered before
> should
> definition per
> aren't we
> understanding

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Thu, 03 Feb 2011 00:23:57 +0100

Hi Julien,

Can you please summarize the issues you raised? As far as I recall, your
main concern was about the scenario in which the prefix(es) is not
shared between all the physical interfaces of the MN, correct me if I'm
wrong. In regards to this, as I think we answered, there are a number of
scenarios that people expressed interest about that requires to support
it. Current draft support this and the shared-prefix scenario. If the WG
reaches a consensus in removing the non-shared prefix scenario, we are
happy to do it, but my understanding was that not all the WG had that
opinion (at that time, at least).

Thanks,

Carlos

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Thu, 03 Feb 2011 00:26:31 +0100

> customer, not the other way around.

True, if the requirements are such that allow a solution to be
developed. Having IP-unmodified MNs and not being able to assume that
the network and the MN have a mean to keep their policies in sync (which
is not based on IP signaling from the MN) is a blocking situation, IMHO.

Carlos

---

From: Julien Laganier <[email-masked]>
Date: Wed, 2 Feb 2011 15:45:04 -0800

Hi Carlos,

Thank you for your answer.The two issues I've raised earlier were:

1. there is no need to support multiple addressing models. All scenarios can
be supported by a single addressing model in which each PMIPv6 session maps
to a set of prefixes that are equally accessible through the set of physical
interfaces attached to that PMIPv6 session. This allows all scenarios,
including one in which two prefix sets are available through different
physical interfaces set. I understand that the WG has been divided on that
question but that does not constitute a mandate to include everyone's wish
list  in a standard specification. Thus unless someone can come up with
a rebuttal of my argument on why single addressing model (prefix-set per
interface-set) satisfies all scenarios, e.g., by pointing out a scenario in
which it does not, that should be the only addressing model supported in
that spec.

2. there is no need to convey traffic selectors between the MAG and the LMA.
The LMA forwards downlink packets as per the network-based policy, and the
uplink packets to the Internet. The MAG forwards downlink packets to the MN,
and uplink packets to the LMA. End of the story. As above, unless someone
comes up with a rebuttal of why that is not sufficient to address the
scenario we're concerned with (network-based flow mobility), the traffic
selectors shall be removed from the specification.

Best,

--julien

---

From: Julien Laganier <[email-masked]>
Date: Wed, 2 Feb 2011 15:53:05 -0800

Hi Rajeev,

I understand that the MN takes a decision as per the policy and the context.
It seems to me that consistency of policy rules between the MN and LMA does
not ensure that the LMA knows what decision the MN took because the LMA does
not necessarily knows the context in which the MN is. If so, isn't there a
potential disconnect between routing decision at the LMA and the MN?

Best,

--julien

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 2 Feb 2011 16:13:20 -0800

Hi Julien,

Inline ..

From: [email-masked] [mailto:[email-masked]] On Behalf Of Julien Laganier
Sent: Wednesday, February 02, 2011 3:45 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc

Hi Carlos,

1. there is no need to support multiple addressing models. All scenarios can be supported by a single addressing model in which each PMIPv6 session maps to a set of prefixes that are equally accessible through the set of physical interfaces attached to that PMIPv6 session. This allows all scenarios, including one in which two prefix sets are available through different physical interfaces set. I understand that the WG has been divided on that question but that does not constitute a mandate to include everyone's wish list  in a standard specification. Thus unless someone can come up with a rebuttal of my argument on why single addressing model (prefix-set per interface-set) satisfies all scenarios, e.g., by pointing out a scenario in which it does not, that should be the only addressing model supported in that spec.

[Sri] I guess, this goes back to our last discussion in this list. We allow the hosting of multiple prefixes on an IPv6 link and the base RFC-5213 allows the same. You agreed and your comments on to take the approach of session management, as supposed to addressing models. Now, we allow the ability to move a full/partial set of prefixes to a different interface, and optionally allow the sharing of prefixes across links. This is one issue to discuss the shared link approach and see how to capture the final text. The text can be updated once we decide the scenarios that we support. This also probably ties to the policy interface to MN. Lets take this as an open issue.

2. there is no need to convey traffic selectors between the MAG and the LMA. The LMA forwards downlink packets as per the network-based policy, and the uplink packets to the Internet. The MAG forwards downlink packets to the MN, and uplink packets to the LMA. End of the story. As above, unless someone comes up with a rebuttal of why that is not sufficient to address the scenario we're concerned with (network-based flow mobility), the traffic selectors shall be removed from the specification.

[Sri] I tend to agree. The MAG does not have ability to convey flow level info over ND interface. At the end of the day, the MAG is hosting a set of prefixes on a link and that's all. So, the traffic selectors are not needed from the mobility perspective, but if we look at this as exchange of policy, we can allow them optionally. But,  I'm fine to get rid of this entirely, but allowing this exchange is not undesirable either.

Regards

Sri

Best,

--julien 

Hi Julien,

Thanks,

Carlos

--

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 2 Feb 2011 18:23:24 -0800 (PST)

Hi Stefano,

>interfaces as our customer. Indeed if a working solution that fits the framework 
>
>of S2a and S2b is designed, it could be used at the discretion of 3GPP. However, 
>
>if "a missing part" needs to be provided, I believe the technical issues I raise 
>
>are indeed in the scope and need to be addressed in order to make the protocol 
>applicable to the customer. Expecting to define a solution that does not fit the 
>
>customer and throwing the protocol over the fence to them to fix their part to 
>make the protocol work does not sound like a good design approach to me.

If you can suggest some text that will address the above, I am sure the editor 
will be happy to incorporate that in the next version.

Regards,

Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 2 Feb 2011 18:38:00 -0800 (PST)

> 
>[Sri] I tend to agree. The MAG does not have ability to convey flow level info 
>over ND interface. At the end of the day, the MAG is hosting a set of prefixes 
>on a link and that’s all. So, the traffic selectors are not needed from the 
>mobility perspective, but if we look at this as exchange of policy, we can allow 
>
>them optionally. But,  I’m fine to get rid of this entirely, 

>but allowing this 
>exchange is not undesirable either.

Agreed.

Behcet

---

From: "Stefano Faccin" <[email-masked]>
Date: Wed, 2 Feb 2011 20:48:49 -0600

Behcet, 
I'd be very happy if I had a solution for the issues raised. Not having one on my side should not mean the issues do not exist, though.
Cheers,
Stefano

Stefano M. Faccin

Standards Manager
Research In Motion
122 West John Carpenter Parkway
Irving, TX 75039
Internal: 820 63451
Desk: +1 972 910 3451
BlackBerry: +1 510 230 8422
[email-masked]
Time zone: PST (GMT -8)

----- Original Message -----
From: Behcet Sarikaya [mailto:[email-masked]]
Sent: Wednesday, February 02, 2011 08:23 PM
To: stefano faccin <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc

Hi Stefano,

Regards,

Behcet

---------------------------------------------------------------------
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 Feb 2011 18:50:20 -0800

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" <[email-masked]> wrote:

> 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.
> 
> 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
>> 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
>> 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" <[email-masked]
>>> On Tue, Feb 1, 2011 at 7:43 PM, Sri Gundavelli <[email-masked]
>>> <http://[email-masked]> > wrote:
>>>> Hi Stefano:
>>>> 
>>>> 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

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Thu, 3 Feb 2011 05:13:34 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Sri Gundavelli
Sent: Wednesday, February 02, 2011 6:50 PM
To: stefano faccin
Cc: [email-masked]; [email-masked]
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" <[email-masked]> 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

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" <[email-masked] <http://[email-masked]> > 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 <[email-masked] <http://[email-masked]> > wrote:
Hi Stefano:

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" <[email-masked] <http://[email-masked]>  <http://[email-masked]> > 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,  <[email-masked] <http://[email-masked]>  <http://[email-masked]> > wrote:

Hello,

-Basavaraj

---

From: "Stefano Faccin" <[email-masked]>
Date: Thu, 3 Feb 2011 01:05:11 -0600

Hello Sri,
From a point of view of applicability of the solution, I must agree with Gerardo that assuming synchronization of policies is an issue of this solution since it comes with a set of restrictions on how the solution can be applied.
Cheers,
Stefano

Stefano 
Stefano M. Faccin 

Standards Manager 
Research In Motion 

From: Giaretta, Gerardo [mailto:[email-masked]] 
Sent: Wednesday, February 02, 2011 11:13 PM
To: Sri Gundavelli <[email-masked]>; stefano faccin <[email-masked]> 
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]> 
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc 

Hi Sri,

Cheers

Gerardo

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

Sri,

Cheers,
Stefano

Hi Stefano,

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

Sri,
thanks for the reply.

Cheers,
Stefano

Hi Stefano:

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.

Sri

Raj,
thanks for the email.

Cheers,
Stefano

Hello,

I-D: http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt <http://www.ietf.org/id/draft-bernardos-netext-pmipv6-flowmob-02.txt> 

-Basavaraj

---

From: "MELIA, TELEMACO (TELEMACO)" <[email-masked]>
Date: Thu, 3 Feb 2011 11:07:40 +0100

Hello Stefano,

I guess what JC means by "MAG forward the packet with no problem" is that upon network attachment the MAG has the required routing states to properly process packet forwarding.

As for your second comment we do not need to modify current specifications. The authors during the offline discussions agreed on the fact that the LMA can receive multiple triggers and act upon these triggers to perform flow mobility (i.e. the act of routing a flow on a different network access). The mechanism JC suggest is another way of sending implicit triggers to the LMA. We can of course update the text on LMA behaviour but I do not think we really need to update the specifications. Rajeev commented along the same lines in earlier mails.

telemaco
________________________________
De : [email-masked] [mailto:[email-masked]] De la part de stefano faccin
Envoyé : mercredi 2 février 2011 23:26
À : Zuniga, Juan Carlos
Cc : [email-masked]
Objet : Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc

Hello JC,

For my clarification, how would the "MAG forward the packet with no problem"? I am not sure I am understanding what the sequence of steps would be.

Also, I guess that as you say the solution is not included in the current draft, which means modifying the protocol that we have in the current draft.

Cheers,
Stefano
On Wed, Feb 2, 2011 at 12:37 PM, Zuniga, Juan Carlos <[email-masked]<mailto:[email-masked]>> wrote:
Hi Stefano,

What I had in mind was what they call Basic solution in the document, in which the same set of prefixes are assigned to different interfaces (or MAGs). In this case the MN can decide (based on policies) to change the flow and send packets over a new interface. The MAG would forward the packet with no problem and upon receiving this packet the LMA would implicitly know that the MN has performed a flow movement (again, based on policies). At this point the LMA would just need to change its routing table accordingly and start sending packets for this flow over the new interface (similar rule to the one already specified for the mobile).

I see this as a lightweight solution to the problem you pointed out that could easily be added to the document.

Jc

From: stefano faccin [mailto:[email-masked]<mailto:[email-masked]>]
Sent: February 2, 2011 3:11 PM
To: Zuniga, Juan Carlos

Hi JC,

As you say in 3GPP for the MN-based model this has been solved. However, if we want to apply a similar solution, we go back to the argument that it would require the MN to be able to communicate the decisions to the MAG/LMA but, as we discussed previously, we don't have a solution for that. This means that applying this protocol with a model similar to the one currently specified in IETF and 3GPP requires the definition of a solution that does not yet exist (at Layer 3 or at Layer 2). I am concerned about developing only some pieces of a solution.

Alternatively, as you say the MAG reacts. However, it is not clear to me that the current draft describes how that happens.

Cheers,
Stefano
On Wed, Feb 2, 2011 at 11:56 AM, Zuniga, Juan Carlos <[email-masked]<mailto:[email-masked]>> wrote:
Stefano,

As much as I agree with most of your points about the problem from the 3GPP architecture point of view, I think that there is more than one solution.

We are assuming of course that what we have is a scenario where both networks are in the same PMIP domain and IP flow mobility is then possible. You point out that there are no means to convey policies to the LMA or MAG. However, there are means to convey these policies to the MN as it is already defined in 3GPP for the client-based IP flow mobility case (i.e. ANDSF). Hence, one different solution could be to let the MN apply the policy by moving the flow and make the MAG and LMA "react" to the IP flow change assuming that the flow change was made according to the policy being applied at the mobile.

I would see this scenario equivalent to the one specified in 3GPP from the point of view of node's responsibilities, don't you think?

Jc

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of stefano faccin
Sent: February 2, 2011 2:41 PM
To: Rajeev Koodli; [email-masked]<mailto:[email-masked]>

Sorry, I forgot to reply to the whole list.
Cheers,
Stefano
On Wed, Feb 2, 2011 at 11:29 AM, stefano faccin <[email-masked]<mailto:[email-masked]>> wrote:
Hi Rajeev,
in current solution the policy is in sync, since it is the ANDSF (the network counterpart of the MN for the policy) that configures it in the MN. That does not mean that the LMA has such policy.

Cheers,
Stefano

On Wed, Feb 2, 2011 at 11:46 AM, Rajeev Koodli <[email-masked]<mailto:[email-masked]>> wrote:

Hi Gerardo,

 *   my point is that someone/something is configuring the policy on the MN which needs to be in sync with the MN's partner, i.e., the network. If this is not the case, please let me know.
 *   The last I heard, PMIP6 is applicable on the eHRPD (trusted non-3GPP network). Also, 33.402 does not specify whether a particular type of access network (such as WLAN) is considered trusted or untrusted (although a majority of the WLAN access could be considered untrusted today).

-Rajeev

On 2/2/11 11:16 AM, "Giaretta, Gerardo" <[email-masked]<http://[email-masked]>> wrote:
Hi Rajeev,

-         This draft assumes there is consistency in the rules. This is a new requirement for the system architecture where this solution will be applied. There is no this requirement for other solutions already adopted by IETF and 3GPP. In my view this seems a fairly important issue.

-         The routing decisions based on WLAN SSID are different from trusted/untrusted. Note also that PMIPv6 cannot be used in trusted networks so it is not clear at all what you are referring to.

Gerardo

From: [email-masked]<http://[email-masked]> [mailto:[email-masked]] On Behalf Of Rajeev Koodli
Sent: Wednesday, February 02, 2011 11:28 AM
To: stefano faccin
Cc: [email-masked]<http://[email-masked]>; [email-masked]<http://[email-masked]>
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc

Stefano,

Regardless of how the policy is configured on the LMA, there is a consistency of the rules which needs to be ensured regardless. Whatever the entity (OMA-DM?!) is that configures the policy has to ensure such a consistency.

We can debate about how policy interaction works, but that's another topic. I would note that there are choices here (modulo respective pros and cons).

I didn't suggest that an operator should just trust the software on a MN, although I suspect some device vendors might argue for their robustness (surprise?).

I would frame the WLAN access problem as whether the access is considered trusted or not. Accordingly, you apply the policy.

-Rajeev

On 2/2/11 10:50 AM, "stefano faccin" <[email-masked]<http://[email-masked]>> wrote:
Raj,
thanks for the reply.

If the LMA has statically configured policies, how do we ensure that the MN has the same policies? That would mean implicitly assuming that the policies provisioned to the MN by the ANDSF "always" match what has been set in the LMA, which I think it is unrealistic because the policies change over time, and every time you need to update all the LMAs, which has a considerable operational cost. Instead, if we leave the MN to make the choice, there are easy and well specified mechanisms that allow the provisioning of policies in the MN and for the MN to make such decision and communicate it to the network, so that the network can

As for extensions to Gx, I am not stating that in theory one could extend Gx. However, at present such solution does not exists, and without it, I do not see how the draft is applicable to 3GPP that is at present the only potential customer identified (I guess I did not see any other identified?)

Even assuming that Gx could be modified, the issue of the per-access network granularity remains. Even if the LMA has the right policies in place, the LMA has no way of knowing exactly what access network of a specific access technology (e.g. which SSID for WLAN0 the MN is connecting to.

I cannot agree with your assumption below that if the MN connects to an SSID it is because the operator is OK with routing traffic on that SSID, and that we should just "trust the software on the MN". There are two aspects to consider:
1) whether it is OK for certain traffic to be routed at all over a certain access access network of a specific access technology
2) how different traffic should be routed over different access networks of different access technologies

Regarding these two points, the issue is whether the operator wants to allow traffic e.g. over a certain SSID or not. So, in that case, it is obvious as you say that if the MN has connected to an SSID configured by the operator in the MN, then traffic could be allowed over that SSID. However, we need to consider that 3GPP allows the decision of which WLAN the MN can connect to based on user preferences. This means that my MN can e.g. connect to my home WLAN (which is not controlled necessarily by the operator and whose SSID the operator does not know) or to a coffee shop WLAN, even if the device does not have those SSID configured. Those are typical examples of untrusted WLAN access networks. Therefore, in such cases, just because the MN has connected to a WLAN SSID, does not mean that the operator wants to route certain traffic over that SSID just because the policy says "route traffic X over WLAN".

That brings us to a solution that, if applied to 3GPP, provides less functionality than what is available and has been specified today, so back to my point above.

Unfortunately, there is no solution I am aware of that allows the WLAN network to indicate to the MAG/LMA the specific SSID (and as you say, there is no easy solution for that). Due to this and the points above about policy provisioning, it means that the applicability of this solution to a real case like 3GPP depends on the feasibility of extending policy mechanisms in 3GPP, and the ability to have a solution where the WLAN network provides the SSID information to the MAG/LMA. Moreover, the provisioning of such SSID is not in the scope of IETF, but not even of 3GPP (since the interface between the WLAN AP and the ePDG is not defined), thus I wonder how this could be defined at all (I am afraid of asking what magic should happen here). So, now we have two big dependencies.

In general, I am also wondering if there is a customer that has asked us to define this solution. I am not aware of any but I may have missed that.

Cheers,
Stefano

On Wed, Feb 2, 2011 at 10:44 AM, Rajeev Koodli <[email-masked]<http://[email-masked]>> wrote:

Hi Stefano,

You make two interesting points: First, the defined solution should be useful for 3GPP deployments. Second, if it's not defined today in 3GPP, it's not useful.

I tend to agree with you on the first - 3GPP is a big potential customer.
I cannot agree with your second point.

There are multiple ways I could envision policy on the LMA. Locally configured policy is one (which we use today in deployments) that does not need Gx interaction. Gx extensions can be proposed in the future. I hope you are not suggesting that these are not feasible choices.

For the MN (IETF term for UE) to even connect to the MAG via WLAN today, you need an IPsec termination point (ePDG). If the operator pre-configures the list of SSIDs or there is some out-of-band mechanism to inform the MN which SSID is "white-listed", then I expect the MN to decide when to connect to the ePDG and hence the MAG. At this point, the MN is already on the WLAN the operator cares about I presume.
There is no easy way for the network (LMA, MAG) to know what SSID the MN is connected to - the network has to either trust the software on the MN or the WLAN infrastructure has to provide the SSID information to the network.

-Rajeev

On 2/2/11 9:56 AM, "stefano faccin" <[email-masked]<http://[email-masked]> <http://[email-masked]> > wrote:
Hello rajeev,
the use of PCRF is an interesting suggestion. However, unfortunately, PCRF does not contain any policies or information that will tell the LMA what are the policies to be used for decisions of IP flow mobility. This is not part of current PCC functionality, and there is no work ongoing or planned to extend PCC in such way. Therefore, the applicability of the solution in this draft would hinge on hypotetical future solutions and not on a current solution for the open issues, which brings us back to my point that we are defining a solution with open issues for which there is not a single realistic solution out there, thus making this draft not applicable to a real scenario.

I am not thinking of the UE connecting to more than one WLAN at the same time, but the UE being able to connect to different WLANs (one at a time) because the UE is e.g. provisioned with a list of SSIDs or the UE discovers a hotspot somewhere. I am talking about the scenario where the UE is capable to connect to WLAN, but the operator has different policies wrt which WLAN the UE should use or not.

If you have followed the work in 3GPP, it is clear that operators have interest in applying policies not only at RAT level, but also at access network level (please see how ANDSF was defined and why). I guess we can all agree that an operator deploying PMIP-based mobility may be interested in having policies that allow traffic on the WLAN the operator owns or that belongs to a roaming partner, while not allowing traffic on WLAN of other operators for which it might need to pay an extra fee or where e.g. no QoS can be guaranteed. That means that the entity deciding whether traffic needs to be routed on WLAN or not cannot just consider "WLAN is available", but "WLAN SSIDx is available", so that the decision can be based on the operator preferences as to which WLAN certain traffic needs to be routed on.

If the draft allows decisions to be made only at the RAT level, then we have an issue because we are defining a solution that should be applicable to 3GPP but does not meet the deployment scenarios of interest. In other words, if we want to make this solution applicable e.g. to 3GPP, we need to be able to provide the same functionality available today in 3GPP with other solution in order to satisfy the use cases supported by 3GPP, and not step backwards in terms of what can be supported.

Cheers,

Stefano

On Wed, Feb 2, 2011 at 9:55 AM, Rajeev Koodli <[email-masked]<http://[email-masked]> <http://[email-masked]> > wrote:

Hi Stefano,

Thanks for your input.

I expect the LMA interacting with PCRF for policy rules specific to the subscriber for different RAT types.
You are right that the LMA does not know the SSID the mobile is connected to. It's not clear if the MAG can get that from the MN either without additional signaling. However, the LMA knows that the MN is connected to WLAN; so it can apply the policy at the RAT type level. Are you thinking of the MN connecting to more than one WLAN network (and each of those connections coming back to the LMA)? If so, please explain the scenario.

Regards,

-Rajeev

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

Cheers,
Stefano

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

Hello,

-Basavaraj

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

---

From: "MELIA, TELEMACO (TELEMACO)" <[email-masked]>
Date: Thu, 3 Feb 2011 11:09:54 +0100

Hello,

Tend to agree on Sri's comment.

telemcao

---

From: <[email-masked]>
Date: Thu, 3 Feb 2011 16:35:59 +0100

Hello,

This is an interesting discussion, thanks for bringing the ANDSF issues on the table. Effectively, mobility control, i.e. access selection, is a key point for an operator. From an operator point of view, criteria for selection is not only RAT type or SSID; we can imagine plenty of other criteria. Different mobility control models can be envisaged such as Network controlled or terminal controlled and so on... For sure, in PMIP context, policies synchronization can be an issue and how decision made on the terminal can interact with network managed mobility should be discussed. But, I don't think draft-bernardos should go in this space. I think, we should clearly distinguish mobility functions. IMHO, draft-bernardos should not be expected to deal with selection management, or mobility triggers, but only on the handover execution. In other words, the draft should assume that handover decision has been made (how decision is made is out of scope) and, then, only focus on mechanism allowing the LMA to transfer flow(s). Although related, mobility decision management, e.g. policy based, should be discussed in a separated thread.

BR,

Pierrick

De : [email-masked] [mailto:[email-masked]] De la part de Stefano Faccin
Envoyé : jeudi 3 février 2011 08:05
À : [email-masked]; [email-masked]; [email-masked]
Cc : [email-masked]; [email-masked]
Objet : Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc

Hello Sri,
Cheers,
Stefano

Stefano 
Stefano M. Faccin 

Standards Manager 
Research In Motion 

Hi Sri,

Cheers

Gerardo

Hi Stefano,

One comment.

Regards
Sri

Sri,

Cheers,
Stefano

Hi Stefano,

Regards
Sri

Sri,
thanks for the reply.

Cheers,
Stefano

Hi Stefano:

Sri

Raj,
thanks for the email.

Cheers,
Stefano

Hello,

-Basavaraj

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 3 Feb 2011 08:19:08 -0800 (PST)

Hi Pierrick,

>Hello,
> 
>This is an interesting discussion, thanks for bringing the ANDSF issues on the 
>table. Effectively, mobility control, i.e. access selection, is a key point for 

>an operator. From an operator point of view, criteria for selection is not only 

>RAT type or SSID; we can imagine plenty of other criteria. Different mobility 
>control models can be envisaged such as Network controlled or terminal 
>controlled and so on... For sure, in PMIP context, policies synchronization can 

>be an issue and how decision made on the terminal can interact with network 
>managed mobility should be discussed. But, I don't think draft-bernardos should 

>go in this space. I think, we should clearly distinguish mobility functions. 
>IMHO, draft-bernardos should not be expected to deal with selection management, 

>or mobility triggers, 

+ 1

> but only on the handover execution. In other words, the 
>draft should assume that handover decision has been made (how decision is made 
>is out of scope) and, then, only focus on mechanism allowing the LMA to transfer 
>
>flow(s). Although related, mobility decision management, e.g. policy based, 
>should be discussed in a separated thread.

Why do you say flow mobility should be tied only to handover?
Handovers may happen in the same technology not necessarily requiring any flow 
mobility.
If it is an inter technology handover then flow mobility may be required.

draft-bernardos makes it as if flow = prefix. Why? Maybe because of what you 
said above. In fact flow >= prefix. And flow mobility >= handover. Flow mobility 
may not necessarily be tied to handover. There are all sorts of cases. 

Flow mobility's basic assumption is availability of simultaneously active 
interfaces. Defining an abstract flow mobility protocol would fit to all those 
cases, IMHO.

Regards,

Behcet

---

From: Julien Laganier <[email-masked]>
Date: Thu, 3 Feb 2011 10:52:43 -0800

Hi Sri,

Please see inline:

> [Sri] I guess, this goes back to our last discussion in this list. We allow the hosting of multiple prefixes on an IPv6 link and the base RFC-5213 allows the same. You agreed and your comments on t…

Adopting a solution draft before we have decided what scenarios we
want to support with solution sounds a bit like putting the cart
before the horse.

In the addressing model I outlined: at PMIPv6 session creation a set
of prefixes is assigned the mobile node's session. Then physical
interfaces can attach to / detach from this session. A single mobile
node can also have multiple sessions (say 2) in parallel, associated
with distinct set of prefixes, which results in the ability for the
prefixes set to move across interfaces fully or partially as the
interfaces are attached to / detached from the session. So all
scenarios are supported in this simple addressing model which also has
a minimal deviation from the basic 5213 model.

If you think this model places unreasonable limitations on what
scenarios can be supported, please explain how and why.

>From my perspective the way forward is to revise the individual draft
submission to document this addressing model only, after which we know
what we are asked to adopt as a WG item.

> [Sri] I tend to agree. The MAG does not have ability to convey flow level info over ND interface. At the end of the day, the MAG is hosting a set of prefixes on a link and that’s all. So, the traffic selectors are not needed from the mobility perspective, but if we look at this as exchange of policy, we can allow them optionally. But,  I’m fine to get rid of this entirely, but allowing this exchange is not undesirable either.
>

As you rightfully note, "the traffic selectors are not needed from the
mobility perspective." Thus, since PMIPv6 is not a policy exchange
protocol (or did it stand for Policy and Mobility for IPv6 ;-) they
are undesirable, should not be allowed optionally, and should be
getting rid of entirely :-)

Best,

--julien

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 03 Feb 2011 13:10:52 -0800

Hi Julien,

> a minimal deviation from the basic 5213 model.

If I understand this correctly, the LMA has a set of prefixes (which are
pre-assigned on *some* attach) which remain constant, but the physical
interfaces come and go. This is another way to look at the problem, agree.

I think this scenario is covered in the draft (perhaps not necessarily with
the same thinking as yours) where the LMA is free to allocate whatever and
any number of the prefix(es) it wishes to assign on any attach.
So, if the LMA chooses to move a flow from one MAG to another, it need not
perform any signaling.

What this does not provide me is the flexibility, for instance, of providing
a prefix *when* I want to provide it, and assigning a prefix based on what
the physical interface the MN is attached to (so that I could route traffic
differently at the LMA if I so choose). I also would like to be able to
offer a prefix and revoke it based on TOD triggers. I do not *have* to
pre-assign my prefixes in anticipation of *potential* flow mobility.

Regards,

-Rajeev

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 03 Feb 2011 13:50:37 -0800

Hi Julien,

Thanks for your response, please see inline.

On 2/3/11 10:52 AM, "Julien Laganier" <[email-masked]> wrote:

>> Julien Laganier
>> which it does not, that should be the only addressing model supported in that
>> spec.
>> 
>> 
>> 
>> [Sri] I guess, this goes back to our last discussion in this list. We allow
>> the hosting of multiple prefixes on an IPv6 link and the base RFC-5213 allows
>> the same. You agreed and your comments on to take the approach of session
>> management, as supposed to addressing models. Now, we allow the ability to
>> move a full/partial set of prefixes to a different interface, and optionally
>> allow the sharing of prefixes across links. This is one issue to discuss the
>> shared link approach and see how to capture the final text. The text can be
>> updated once we decide the scenarios that we support. This also probably ties
>> to the policy interface to MN. Lets take this as an open issue.
> 

This way of structuring makes sense. Having the ability to create one more
mobility sessions with distinct set of prefixes and bind those prefixes
uniquely to individual interfaces associated to the mobility session, and
have the ability to move the session objects between interfaces (as in
5213), and/or have the ability to move partial/full set of prefixes between
those session objects, or between interfaces part of the session object.
Very much close to what is in base spec. This covers the cases I'm looking
for and should keep simple ND requirements on the access link. Its still a
simple hosted IPv6 link. We just need to make sure, the signaling semantics
are clearly presented and have access technology type awareness in the state
change decisions. In general, I agree, this presentation approach should
greatly clarify things.

>> [Sri] I tend to agree. The MAG does not have ability to convey flow level
>> info over ND interface. At the end of the day, the MAG is hosting a set of
>> prefixes on a link and that¹s all. So, the traffic selectors are not needed
>> from the mobility perspective, but if we look at this as exchange of policy,
>> we can allow them optionally. But,  I¹m fine to get rid of this entirely, but
>> allowing this exchange is not undesirable either.
>> 
> 

Works for me. No traffic spec in the protocol signaling is fine with me.

Regards
Sri

---

From: "Stefano Faccin" <[email-masked]>
Date: Thu, 3 Feb 2011 16:22:14 -0600

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 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 Giaretta, Gerardo
Sent: Wednesday, February 02, 2011 9:14 PM
To: Sri Gundavelli; stefano faccin
Cc: [email-masked]; [email-masked]
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

Of Sri Gundavelli

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

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 <[email-masked]>
wrote:

Hi Stefano,

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" <[email-masked] <
http://[email-masked]> > 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 <[email-masked] <
http://[email-masked]> > wrote:

Hi Stefano:

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

Raj,
thanks for the email.

Cheers,
Stefano

Hello,

We have discussed the flow mobility solutions for Proxy MIP6 previously
at
IETFs 78 and 79.

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

---

From: "Stefano Faccin" <[email-masked]>
Date: Thu, 3 Feb 2011 16:26:18 -0600

Pierrick,

Thanks for the comments. I can agree on discussing the issues some of us raised separately. If we want to discuss the key elements that make this draft applicable separately, then I guess that we should wait to adopt this draft until those key issues are solved, otherwise we risk to adopt a solution that is not applicable to anything.

Cheers,

Stefano Faccin

Standards Manager

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

Internal: 820.63451

 : (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]] 
Sent: Thursday, February 03, 2011 7:36 AM
To: Stefano Faccin; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc

Hello,

BR,

Pierrick

Hello Sri,
Cheers,
Stefano

Stefano 
Stefano M. Faccin 

Standards Manager 
Research In Motion 

Hi Sri,

Cheers

Gerardo

Hi Stefano,

One comment.

Regards
Sri

Sri,

Cheers,
Stefano

Hi Stefano,

Regards
Sri

Sri,
thanks for the reply.

Cheers,
Stefano

Hi Stefano:

Sri

Raj,
thanks for the email.

Cheers,
Stefano

Hello,

-Basavaraj

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 03 Feb 2011 14:51:17 -0800

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" <[email-masked]> 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.
>  
> Sri Gundavelli
> 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 :)
> 
> 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
> 
> 
> 
> 
> 
> 
> 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.
> 
> Its just a base draft, for further discussion and resolving those issues. But,
> hope that is not a stopper for base draft selection.
>  
> 
> Sri
> 
> 
> 
> 
> 
>

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Thu, 3 Feb 2011 22:43:49 +0000

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:[email-masked]]
Sent: Thursday, February 03, 2011 2:51 PM
To: Giaretta, Gerardo; Sri Gundavelli; stefano faccin
Cc: [email-masked]; [email-masked]
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

Cheers
Gerardo

Hi Stefano,

One comment.

Regards
Sri

Cheers,
Stefano

Regards
Sri

Cheers,
Stefano

Sri

Cheers,
Stefano

Hello,

-Basavaraj

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 03 Feb 2011 14:54:41 -0800

Hi Gerardo,

Sure, for supporting the specific scenario, the draft is making that
assumption. This does come at a cost for the operator having to ensure
synchronized policies between the ANDSF server and the PDN GW. But, my
question still remains, how in IFOM, a PDN GW can ever authorize and
establish the flow policies requested by the UE. It needs the access to same
policy that the operator configured on the ANDSF server. Else, its all in
the mercy of the UE with no network side validation. There can be all the
needed information elements, around UE location, or network attachment in
the protocol signaling, directly from the UE in IFOM, but fundamentally the
PDN GW needs access to the same policy. I do agree, this assumption is an
administrative overhead.

Regards
Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 03 Feb 2011 14:55:41 -0800

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" <[email-masked]> wrote:

> 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: (972) 910 3451  Internal: 820.63451: (510) 230 8422www.rim.com
> <outbind://28-00000000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D4149BF16
> E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000/w
> ww.rim.com> ; www.blackberry.com
> <outbind://28-00000000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D4149BF16
> E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000/w
> ww.blackberry.com>
> Giaretta, Gerardo
> 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: "Giaretta, Gerardo" <[email-masked]>
Date: Thu, 3 Feb 2011 23:00:05 +0000

Hi Sri,

Conformance tests can be used to make sure the UE behaves accordingly. So no need for the PDN GW to perform any validation.

Cheers
Gerardo

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

Hi Gerardo,

Sure, for supporting the specific scenario, the draft is making that assumption. This does come at a cost for the operator having to ensure synchronized policies between the ANDSF server and the PDN GW. But, my question still remains, how in IFOM, a PDN GW can ever authorize and establish the flow policies requested by the UE. It needs the access to same policy that the operator configured on the ANDSF server. Else, its all in the mercy of the UE with no network side validation. There can be all the needed information elements, around UE location, or network attachment in the protocol signaling, directly from the UE in IFOM, but fundamentally the PDN GW needs access to the same policy. I do agree, this assumption is an administrative overhead.

Regards
Sri

Cheers
Gerardo

Hi Stefano,

One comment.

Regards
Sri

Cheers,
Stefano

Regards
Sri

Cheers,
Stefano

Sri

Cheers,
Stefano

Hello,

-Basavaraj

---

From: "Stefano Faccin" <[email-masked]>
Date: Thu, 3 Feb 2011 17:01:30 -0600

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

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

Internal: 820.63451

 : (510) 230 8422

www.rim.com

From: Sri Gundavelli [mailto:[email-masked]] 
Sent: Thursday, February 03, 2011 2:56 PM
To: Stefano Faccin; Giaretta, Gerardo; stefano faccin
Cc: [email-masked]; [email-masked]
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.

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 

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

Hi Sri,

 
Cheers,

Hi Sri,

 
Cheers
Gerardo

Hi Stefano,

One comment.

Regards
Sri

Cheers,
Stefano

Regards
Sri

Cheers,
Stefano

Sri

Cheers,
Stefano

Hello,

-Basavaraj

 
--------------------------------------------------------------------- 
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: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 04 Feb 2011 00:09:15 +0100

Hi Julien,

Please, see inline below.

> what we are asked to adopt as a WG item.

I fail to see here how current draft deviates from your proposal. I
think it does this. Prefix models are just a way of presenting potential
use case deployments and the solution adapts to all scenarios presented
in the draft.

> getting rid of entirely :-)

You are right in that TS are not required from the mobility perspective.
They are optional in the draft and not even considered as the default
case. They were included because some people expressed in the mailing
lists that were required for some scenarios. Therefore, I'm fine
removing them if there is consensus for doing so.

Carlos

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 04 Feb 2011 00:09:17 +0100

Hi Behcet,

> may not necessarily be tied to handover. There are all sorts of cases. 
Why do you say we make it as if flow = prefix? In my understanding we
consider any granularity of flow mobility.

Thanks,

Carlos

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 04 Feb 2011 00:09:19 +0100

+1

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 03 Feb 2011 15:25:34 -0800

Hi Stefano,

Sure. Closing the discussion, client-based vs network-based discussion. If
there is wide-spread adoption of DSMIPv6 stack on all the operating systems,
we would not have needed any specification work. So, the model of client
based model is fine, if we can solve the adoption issue.

We need classification of the traffic based on some very high level
parameters, to most part, the base information elements around access
technology is sufficient. I¹ve this set of Internet flows, which should
break off when WLAN access is available. If any operator requires more
complex policies, sure, they have the IFOM option and I agree with you, it
can offer the solution. But, the goal of the spec is to support base set of
features.

Regards
Sri

On 2/3/11 3:01 PM, "Stefano Faccin" <[email-masked]> wrote:

> 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?
>  
> My point on the synchronized policy assumption still remains, as I¹ve noted in
> the other thread.
> 
> 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
>  
> 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
> 
> 
>

---

From: Julien Laganier <[email-masked]>
Date: Thu, 3 Feb 2011 15:27:11 -0800

HI Rajeev,

> interfaces come and go. This is another way to look at the problem, agree.

Ok.

> So, if the LMA chooses to move a flow from one MAG to another, it need not

Right.

> pre-assign my prefixes in anticipation of *potential* flow mobility.

It does provide you with this flexibility. Whenever you want to offer
a new prefix (set) over a physical interface (set) you simply
bootstrap a new PMIPv6 session for that new prefix (set) over the
physical interface (set.) If you want to revoke it because it's COB
you can certainly tear down that session.

All in all, a very simple model that allows all scenarios to be covered.

I would suggest that we concentrate on devising the simplest
addressing model and signaling framework, and move the scenarios in an
annex.

--julien

---

From: "Stefano Faccin" <[email-masked]>
Date: Thu, 3 Feb 2011 17:34:19 -0600

Sri,

I cannot agree less on the fact that "the base information elements
around access technology is sufficient." I have indicated clear examples
that are already in use today for devices to choose whether to route
traffic over WLAN or not (i.e. based on the specific SSID). I guess we
do not want to design a solution to be deployed in the future that
provides less functionality and restricts the scenarios? You may want to
look at the work in MIF WG where the current practices document
indicates how multiple interfaces are used in current scenarios.

I think that unless we solve the open issues and make this solution
applicable to real scenarios, it is not possible to adopt the draft.

Stefano Faccin

Standards Manager

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

Internal: 820.63451

 : (510) 230 8422

www.rim.com

Sent: Thursday, February 03, 2011 3:26 PM

Hi Stefano,

Sure. Closing the discussion, client-based vs network-based discussion.
If there is wide-spread adoption of DSMIPv6 stack on all the operating
systems, we would not have needed any specification work. So, the model
of client based model is fine, if we can solve the adoption issue. 

We need classification of the traffic based on some very high level
parameters, to most part, the base information elements around access
technology is sufficient. I've this set of Internet flows, which should
break off when WLAN access is available. If any operator requires more
complex policies, sure, they have the IFOM option and I agree with you,
it can offer the solution. But, the goal of the spec is to support base
set of features.

Regards
Sri

Sri,

Hi Stefano,

 

Regards
Sri

 
 
Cheers,

Hi Sri,

 
Cheers
Gerardo

Hi Stefano,

One comment.

Regards
Sri

Cheers,
Stefano

Regards
Sri

Cheers,
Stefano

Sri

Cheers,
Stefano

Hello,

-Basavaraj

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 03 Feb 2011 16:00:16 -0800

Hi,

> you can certainly tear down that session.

If it does, we are probably talking about the same thing, which is good :-)

Help me understand then with this scenario: The MN attaches on if0, gets
prefix p0. The MN attaches on if1, the LMA assigns the p1. At some point
later, the LMA chooses to move some flows from if0 to if1. How do I do this
without being forced to allocate both p0 and p1 on if1 at the time of attach
(on if1)? 

Thanks,

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 03 Feb 2011 16:02:05 -0800

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" <[email-masked]> 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 J)
>  
> Gerardo
>  
>

---

From: Julien Laganier <[email-masked]>
Date: Thu, 3 Feb 2011 15:49:35 -0800

Hi Rajeev,

> If it does, we are probably talking about the same thing, which is good :-)

Let's see :-)

I'm breaking down your scenario below in steps, and adding below each
step what action would happen in my model:

> prefix p0.

New PMIPv6 session S0 is created with prefix set = {p0} over interface set {if0}

> The MN attaches on if1, the LMA assigns the p1.

New PMIPv6 session S1 is created with prefix set = {p1} over interface set {if1}

> At some point later, the LMA chooses to move some flows from if0 to if1.

Interface if1 is added to existing PMIPv6 session S0 which has prefix
set = {p0} now extended over interface set {if0, if1}

> How do I do this without being forced to allocate both p0 and p1 on if1 at the time of attach
> (on if1)?

By following the steps above? :-)

--julien

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 03 Feb 2011 16:22:30 -0800

> set = {p0} now extended over interface set {if0, if1}

I would insert that the LMA also informs the MAG hosting p1 to accept p0.

> By following the steps above? :-)

Cool. This is what is in the draft, but presented differently.
We could always make it better.

-Rajeev

---

From: Julien Laganier <[email-masked]>
Date: Thu, 3 Feb 2011 16:05:48 -0800

Hi Carlos,

Please see inline (I'm cutting thru the past messages for brevity)

2011/2/3 Carlos Jesús Bernardos Cano <[email-masked]>:
>> [...]

I am sorry if this sounds blunt but -- To me the current draft
digresses on details of (non normative) scenarios and has useless
signaling for traffic selectors, yet it fails to explain the basics of
what is the PMIPv6 flow mobility session made of and how it is
maintained... I am proposing to make this crystal clear: A PMIPv6
session has a prefix set, and member physical interfaces set that can
be attached/detached. If we agree on this, let's write it upfront in
the spec and then defining the protocol is probably simple. As to
scenarios, they should to annex, they are not normative. What' s
normative is how do I create and tear down a PMI{Pv6 session. What is
the addressing model for a session. How do I attach/detach interfaces
from sessions. This is it. And it's not done IMHO.

[...]

> removing them if there is consensus for doing so.

This seems backward.

I do not believe that we need to have consensus to remove them.

What we need to have them in a working group draft is consensus that
there's a valid usecase that requires them, which I haven't seen so
far.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Thu, 3 Feb 2011 16:12:01 -0800

> I would insert that the LMA also informs the MAG hosting p1 to accept p0.

Why would the LMA need to tell the MAG?

> Cool. This is what is in the draft, but presented differently.

As per my note to Carlos, the draft doesn't do a good job at
explaining the session model, and contains useless stuff that should
be removed before I can consider making a decision on endorsing it or
not.

> We could always make it better.

So let's do it and adopt the better version!

--julien

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 04 Feb 2011 01:27:25 +0100

Hi Julien,

> I am sorry if this sounds blunt but -- To me the current draft

Don't be sorry, I'm trying to understand what are the differences in
what you have in mind and what it is in the draft. I think we are not as
far as you may think.

> digresses on details of (non normative) scenarios and has useless

I thought including scenarios to explain the basic operation of the
protocol is not forbidden. There are other specs that do that. Anyway,
this is not a major issue, they could be moved to an annex as you
mention, they are just scenarios aimed at supporting the explanation of
the operation, nothing else.

> signaling for traffic selectors, yet it fails to explain the basics of

As I mentioned in another e-mail, I'm fine removing the signalling for
TS. Let's leave them out of the discussion for the time being (default
mode of operation do not include it)

> be attached/detached. If we agree on this, let's write it upfront in

In my understanding, this is exactly what the draft does with the
flowmob state at the LMA. This conceptual data structure contains BID,
TS pairs, associating a flow (defined by a TS; default granularity is
prefix, which perfectly matches what you proposes) with a BID (i.e. a
mobility session in PMIPv6).

> the spec and then defining the protocol is probably simple. As to

Yes, it is indeed.

> there's a valid usecase that requires them, which I haven't seen so

You are probably right. Let me try to recap previous discussions:

You and now Sri don't think there is a usecase for this.
Rajeev and Telemaco think otherwise.

Probably I'm missing other opinions, I just want to trigger discussion
on this, though it'd probably better if we do it in a separate thread.

Carlos

P.S. Please, do not think I'm in favor of keeping TS in the signaling. I
just want to reflect in the draft the approach which the WG has reached
consensus on.

---

From: Tran Minh Trung <[email-masked]>
Date: Fri, 4 Feb 2011 12:04:11 +0900

Hi Julien and Raij, Sri, Carlos and all,

Sorry for jumping in the middle.
It is holiday time in some Asia country now ^^.

Back to the discussion on use-case scenarios.
I agree with Julien that we do not need to discuss about different
use-cases scenarios.

What we need to do is extending PMIPv6 to support flow mobility, not
extending PMIPv6 to support different use-cases scenarios.

Let's start from the basic scenario (new prefix(es) for a new
attachment) of the PMIPv6 and then extend it to support flow mobility.

The question now is that is the right model for supporting flow mobility?

IMHO, the flowing model is the right one, which reflects both Julien
comments and what we have in the current draft.

(1) A sigle mobile node has multiple sessions
(2) Each session is associated with a distinct set of prefixes.
(3) Interfaces are attached to/de-attached from the session.
(4) Each interface can be attached to multiple session at a time.

There is one question left from the discussion between Julien and
Rajeev is that:
Should LMA need to tell the MAG about new prefix(es) of the session
that the interface attach to?.

My answer is YES!.
The MAG needs to know which prefixes are newly assigned to a MN
attachment to send RA.
Without this step, how can the MN know the right attachment to send a packet?

Happy Lunar New Year!
Regards,
TrungTM

---

From: Tran Minh Trung <[email-masked]>
Date: Fri, 4 Feb 2011 12:10:24 +0900

Hi Julien, Rajeev, Sri, Carlos and all,

The question now is that what the right model for supporting flow mobility is.

IMHO, the flowing model is the right one. It reflects both Julien
comments and what we have in the current draft.

My answer is YES!.

Happy Lunar New Year!
Regards,
TrungTM

-- 
Ph.D., Senior Member
Electronics and Telecommunications Research Institute
Standards Research Center
161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA
Tel : +82-42-860-1132,   Fax : +82-42-861-5404

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 3 Feb 2011 19:38:00 -0800

Hi Tran,

Julien's comment, as I understand, is to simplify the text, by taking
the approach of building semantics around updating a mobility session.
Keeping the relation between a mobility session, sub-interface set,
prefix association to sub-interfaces, operations around moving the
sub-interface(s) between mobility sessions, or prefix set between
mobility sessions, or between sub-interfaces of a mobility session.
There is no loss of functionality with respect to what is in the draft
today, or with respect to what the base RFC-5213 supports. Instead of
text mixing addressing models, flow policies and other things, the
structure can be really improved with this approach. Off course, this
does not take away any open issues on the shared prefix model, or on the
policy availability requirements on the UE for supporting some cases.

Now, to your question, if LMA will send the prefixes tied to an
interface, yes, we are not changing the base MAG behavior on how its
hosting prefixes on an access link. It will receive prefixes in the PBA
and it will host the prefixes on the access link, by sending RA
messages. We are not changing the IPv6 link model. Now, if end up
supporting the approach where the prefix is shared across links, we need
to resolve Gerardo's/Stefano's comments on policy assumptions on the MN.
We need to distinguish this from other cases and have the needed text
around any issues.

Lets allow these discussions for some time, and summarize it carefully.
Lets make sure, we are on the same page, before we write up the summary.

Regards
Sri

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Tran Minh Trung
Sent: Thursday, February 03, 2011 7:04 PM
To: Julien Laganier
Cc: [email-masked]; [email-masked]
Subject: Re: [netext] Consensus call to adopt I-D:
draft-bernardos-netext-pmipv6-flowmob as WG doc

The question now is that is the right model for supporting flow
mobility?

My answer is YES!.
The MAG needs to know which prefixes are newly assigned to a MN
attachment to send RA.
Without this step, how can the MN know the right attachment to send a
packet?

Happy Lunar New Year!
Regards,
TrungTM

---

From: Tran Minh Trung <[email-masked]>
Date: Fri, 4 Feb 2011 12:58:18 +0900

Hi Sri and Julien,

Please see my comments inline.

>> what we are asked to adopt as a WG item.

<TrungTM>

I would like to summarize the session model as following:

The item #4 is necessary for supporting full flow mobility.

> Works for me. No traffic spec in the protocol signaling is fine with me.

It works for me also. I agree that the LMA dose not need to send
traffic selectors to the MAG.

Regards,
TrungTM

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 03 Feb 2011 20:22:49 -0800

> Without this step, how can the MN know the right attachment to send a packet?

The LMA needs to provide the prefix info to the MAG. This can be either in
PBA or in FMI (if not provided in PBA).

Regards,

-Rajeev

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 03 Feb 2011 20:24:04 -0800

Hi Gerardo/Stefano:

Not sure, if that is sufficient and how it fits into the current trend
towards supporting open client systems. We don¹t have to agree on this. IMO,
this in some form translates to an implicit assumption, of HA having access
to some policy, at least in some deployments, where the device qualification
is not sufficient. In any case, where ever this is required, this is an
administrative over ahead.

Regards
Sri

On 2/3/11 3:00 PM, "Giaretta, Gerardo" <[email-masked]> wrote:

> Hi Sri,
>  
> Conformance tests can be used to make sure the UE behaves accordingly. So no
> need for the PDN GW to perform any validation.
>  
> Cheers
> Gerardo 
>  
> 
> question still remains, how in IFOM, a PDN GW can ever authorize and establish
> the flow policies requested by the UE. It needs the access to same policy that
> the operator configured on the ANDSF server. Else, its all in the mercy of the
> UE with no network side validation. There can be all the needed information
> elements, around UE location, or network attachment in the protocol signaling,
> directly from the UE in IFOM, but fundamentally the PDN GW needs access to the
> same policy. I do agree, this assumption is an administrative overhead.
> 
> 
> Regards
> Sri 
> 
> 
>

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 03 Feb 2011 21:14:32 -0800

Hi Pierrick:

I agree with lot of points.

* Yes, its all about handover execution. This is the key point. A PBU
message from the MN can be the first step towards activating the handover
process. Or a FMI trigger from the LMA, may itself be the pre-trigger for
PBU message from the MAG. At the end of the day, the LMA applies the policy
and provides the set of prefixes to the MAG. MAG will continue to behave as
in 5213. The decision logic, or the granularity of the policy rule
applicability on the LMA can be out of scope
* Policy synchronization is an issue, for the case where the UE¹s forwarding
decision is based on the policy and not based on the ND messages from the
attached interface. It is very well may be that, we have the same issue for
IFOM as well, IMO, but that¹s beside the point for now.  The policy
activation on the UE, and the associated issues should be discussed in this
context and as needed.
* This draft should not deal with flow policies, how they are applied and
what granularity can be out of scope, IMO. These policies need not be
carried in PMIP signaling place, unless we have MN-AR interface
* I¹m not clear on the policy management though, before we say, it can be
separate thread. The whole approach seems to be out of band at this point
and not sure what can be specified on the PMIP signaling plane with respect
to policy. 

Regards
Sri

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

> table. Effectively, mobility control, i.e. access selection, is a key point
> for an operator. From an operator point of view, criteria for selection is not
> only RAT type or SSID; we can imagine plenty of other criteria. Different
> mobility control models can be envisaged such as Network controlled or
> terminal controlled and so on... For sure, in PMIP context, policies
> synchronization can be an issue and how decision made on the terminal can
> interact with network managed mobility should be discussed. But, I don't think
> draft-bernardos should go in this space. I think, we should clearly
> distinguish mobility functions. IMHO, draft-bernardos should not be expected
> to deal with selection management, or mobility triggers, but only on the
> handover execution. In other words, the draft should assume that handover
> decision has been made (how decision is made is out of scope) and, then, only
> focus on mechanism allowing the LMA to transfer flow(s). Although related,
> mobility decision management, e.g. policy based, should be discussed in a
> separated thread.
>  
> BR,
> Pierrick
>  
>  
> 
> 
> Objet : Re: [netext] Consensus call to adopt
> I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc
>  
> Hello Sri,
> From a point of view of applicability of the solution, I must agree with
> Gerardo that assuming synchronization of policies is an issue of this solution
> since it comes with a set of restrictions on how the solution can be applied.
> Cheers,
> Stefano
> 
> Stefano 
> Stefano M. Faccin
> 
> Standards Manager
> Research In Motion

---

From: "MELIA, TELEMACO (TELEMACO)" <[email-masked]>
Date: Fri, 4 Feb 2011 10:49:08 +0100

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 : [email-masked] [mailto:[email-masked]] De la part de Stefano Faccin
Envoyé : vendredi 4 février 2011 00:02
À : Sri Gundavelli; Giaretta, Gerardo; stefano faccin
Cc : [email-masked]; [email-masked]
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: (972) 910 3451
Internal: 820.63451
: (510) 230 8422
www.rim.com<outbind://28-00000000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D4149BF16E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000/www.rim.com>; www.blackberry.com<outbind://28-00000000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D4149BF16E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000/www.blackberry.com>

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" <[email-masked]> 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: (972) 910 3451  Internal: 820.63451: (510) 230 8422www.rim.com <outbind://28-00000000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D4149BF16E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000/www.rim.com> ; www.blackberry.com <outbind://28-00000000119E3389DDC5E04593E90FB1332A08C10700A3F06753D40D4149BF16E42EA30259AB000001B7908B0000F7B50AB5B4E11B4C80529AAB2313EF3E0000006F1BEA0000/www.blackberry.com>
<http://www.blackberry.com/>

From: [email-masked] [mailto:[email-masked]] On Behalf Of Giaretta, Gerardo

Hi Sri,

Cheers
Gerardo

Hi Stefano,

One comment.

Regards
Sri

Cheers,
Stefano

Regards
Sri

Cheers,
Stefano

Sri

Cheers,
Stefano

Hello,

-Basavaraj

---

From: "MELIA, TELEMACO (TELEMACO)" <[email-masked]>
Date: Fri, 4 Feb 2011 10:56:56 +0100

Yes, it would help.

telemaco

________________________________
De : [email-masked] [mailto:[email-masked]] De la part de Rajeev Koodli
Envoyé : vendredi 4 février 2011 01:02
À : Giaretta, Gerardo; Sri Gundavelli; stefano faccin
Cc : [email-masked]; [email-masked]
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

Gerardo

Hi Gerardo,

Regards,

-Rajeev

Cheers
Gerardo

Hi Stefano,

One comment.

Regards
Sri

Cheers,
Stefano

Regards
Sri

Cheers,
Stefano

Sri

Cheers,
Stefano

Hello,

-Basavaraj

---

From: "MELIA, TELEMACO (TELEMACO)" <[email-masked]>
Date: Fri, 4 Feb 2011 11:10:31 +0100

Packet forwarding?

telemaco

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Fri, 4 Feb 2011 11:34:46 -0500

Sri, Pierrick, Carlos, all,

Please see inline:

From: [email-masked] [mailto:[email-masked]] On Behalf Of Sri Gundavelli
Sent: February 4, 2011 12:15 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc

Hi Pierrick:

*	Yes, its all about handover execution. This is the key point. A PBU message from the MN can be the first step towards activating the handover process. Or a FMI trigger from the LMA, may itself be the pre-trigger for PBU message from the MAG. At the end of the day, the LMA applies the policy and provides the set of prefixes to the MAG. MAG will continue to behave as in 5213. The decision logic, or the granularity of the policy rule applicability on the LMA can be out of scope 

[JCZ] I would add the case in which the prefixes are pre-assigned and the flow movement is started from the MN by simply sending packets to the new interface "for instance" based on MN policies. This case would require no MN/MAG/LMA signaling and would satisfy the 3GPP/ANDSF concerns that have been raised without defining any policy management, network selection, etc in this draft. 

We just need to state in the draft that, if the LMA starts receiving packets over a different interface, it would understand this as an implicit IP Flow mobility change. In this case, the LMA should start using the same interface on which the uplink packets were received for subsequent downlink packets.

*	Policy synchronization is an issue, for the case where the UE's forwarding decision is based on the policy and not based on the ND messages from the attached interface. It is very well may be that, we have the same issue for IFOM as well, IMO, but that's beside the point for now.  The policy activation on the UE, and the associated issues should be discussed in this context and as needed. 
*	This draft should not deal with flow policies, how they are applied and what granularity can be out of scope, IMO. These policies need not be carried in PMIP signaling place, unless we have MN-AR interface 
*	I'm not clear on the policy management though, before we say, it can be separate thread. The whole approach seems to be out of band at this point and not sure what can be specified on the PMIP signaling plane with respect to policy. 

[JCZ] For these last three points, I agree with Pierrick that this draft should concentrate on the PMIP flow movement and not on the policy management.

To me clarifying all the above points and cleaning up the wording and scenarios order would make the draft good enough for group's adoption.

Regards
Sri

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

Hello,

BR,
Pierrick

Hello Sri,
Cheers,
Stefano

Stefano 
Stefano M. Faccin 

Standards Manager 
Research In Motion 

Hi Sri,

 
Cheers
Gerardo

Hi Stefano,

One comment.

Regards
Sri

Cheers,
Stefano

Regards
Sri

Cheers,
Stefano

Sri

Cheers,
Stefano

Hello,

-Basavaraj

---

From: Julien Laganier <[email-masked]>
Date: Fri, 4 Feb 2011 10:14:03 -0800

>> Why would the LMA need to tell the MAG?

So the requirement is that a MAG knows the prefix set of the MN's
sessions. This can be done at session creation and does not need to be
(re)done at flow movement.

--julien

---

From: "Stefano Faccin" <[email-masked]>
Date: Fri, 4 Feb 2011 12:14:50 -0600

Telemaco,

I apologize if I fail to make my point.

I am just trying to see how this solution can get applied to a realistic case. I guess we want to design a protocol that solves issues and provides a tool for realistic use cases, I hope? If so, my point is that we have open issues on how this protocol will be used in those cases. Now, we also want to develop a protocol that has a customer, correct? Not just have an academic exercise, correct? If so, it has been said previously on this ML that 3GPP is the biggest potential customer for this work (if there are others I must have missed the emails indicating what other customers are out there). So, if we want to make this applicable to 3GPP, it means it will go in future releases of 3GPP, obviously. Which means it needs to support what is already supported in current releases, otherwise you are proposing a solution that steps backwards in time in terms of what it can support.

As for the use cases I have provided (i.e. per access network versus per access technology), I have not heard any real use case confuting the relevance of the use cases, but just what this protocol cannot do to support them, which concerns me. 

Cheers,

Stefano Faccin

Standards Manager

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

Internal: 820.63451

 : (510) 230 8422

From: MELIA, TELEMACO (TELEMACO) [mailto:[email-masked]] 
Sent: Friday, February 04, 2011 1:49 AM
To: Stefano Faccin; Sri Gundavelli; Giaretta, Gerardo; stefano faccin
Cc: [email-masked]; [email-masked]
Subject: RE: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc

Stefano, all,

telemaco

Sri,

Stefano Faccin

Standards Manager

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

Internal: 820.63451

: (510) 230 8422

Hi Stefano,

 

Regards
Sri

Hi Sri,

 
Cheers,

Hi Sri,

 
Cheers
Gerardo

Hi Stefano,

One comment.

Regards
Sri

Cheers,
Stefano

Regards
Sri

Cheers,
Stefano

Sri

Cheers,
Stefano

Hello,

-Basavaraj

---

From: Julien Laganier <[email-masked]>
Date: Fri, 4 Feb 2011 10:16:24 -0800

> PBA or in FMI (if not provided in PBA).

The LMA can provide the prefix to the MAG at session creation, i.e.,
in the PBU. This information does not need to be (re)conveyed at flow
movement.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Fri, 4 Feb 2011 10:15:07 -0800

Hi Tran,

I think you and I agree on this.

--julien

---

From: "Stefano Faccin" <[email-masked]>
Date: Fri, 4 Feb 2011 12:16:35 -0600

Sri,

I guess we need to agree to disagree. There is no such assumption in
3GPP (if there is a reference to where it is captured would be useful)
on the fact that the HA has the same policies that the UE has. 

I do not agree it is an administrative overhead, sorry.

Cheers,

Stefano Faccin

Standards Manager

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

Internal: 820.63451

 : (510) 230 8422

www.rim.com

Sent: Thursday, February 03, 2011 8:24 PM

Hi Gerardo/Stefano:

Not sure, if that is sufficient and how it fits into the current trend
towards supporting open client systems. We don't have to agree on this.
IMO, this in some form translates to an implicit assumption, of HA
having access to some policy, at least in some deployments, where the
device qualification is not sufficient. In any case, where ever this is
required, this is an administrative over ahead.

Regards
Sri

Hi Sri,
 
Conformance tests can be used to make sure the UE behaves accordingly.
So no need for the PDN GW to perform any validation.
 
Cheers
Gerardo 

Hi Gerardo,

Sure, for supporting the specific scenario, the draft is making that
assumption. This does come at a cost for the operator having to ensure
synchronized policies between the ANDSF server and the PDN GW. But, my
question still remains, how in IFOM, a PDN GW can ever authorize and
establish the flow policies requested by the UE. It needs the access to
same policy that the operator configured on the ANDSF server. Else, its
all in the mercy of the UE with no network side validation. There can be
all the needed information elements, around UE location, or network
attachment in the protocol signaling, directly from the UE in IFOM, but
fundamentally the PDN GW needs access to the same policy. I do agree,
this assumption is an administrative overhead.

Regards
Sri 

 
 
Cheers
Gerardo

Hi Stefano,

One comment.

Regards
Sri

Cheers,
Stefano

Regards
Sri

Cheers,
Stefano

Sri

Cheers,
Stefano

Hello,

-Basavaraj

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 04 Feb 2011 10:40:30 -0800

> in the PBU. This information does not need to be (re)conveyed at flow

If it was conveyed in PBA, surely you don't reconvey.
If the prefix was not conveyed in PBA (as in the example we discussed
y'day), you provide it in FMI.

-Rajeev

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 04 Feb 2011 10:32:39 -0800

Hi Stefano,

Ok. I don¹t have a reference to the 3GPP specs, that such assumption is
explicitly stated. I¹m simply not clear, on the HA decision logic on when to
accept/reject the flow policies in the request, or about trusting the
policies sent by the UE, unless it has access to the same. Fair enough, we
can leave it with this note.

Regards
Sri

On 2/4/11 10:16 AM, "Stefano Faccin" <[email-masked]> wrote:

> Sri,
> I guess we need to agree to disagree. There is no such assumption in 3GPP (if
> there is a reference to where it is captured would be useful) on the fact that
> the HA has the same policies that the UE has.
>  
> Not sure, if that is sufficient and how it fits into the current trend towards
> supporting open client systems. We don¹t have to agree on this. IMO, this in
> some form translates to an implicit assumption, of HA having access to some
> policy, at least in some deployments, where the device qualification is not
> sufficient. In any case, where ever this is required, this is an

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 04 Feb 2011 10:47:10 -0800

Hi Juan Carlos,

Please see inline ...

On 2/4/11 8:34 AM, "Zuniga, Juan Carlos"
<[email-masked]> wrote:

> Subject: Re: [netext] Consensus call to adopt
> * Yes, its all about handover execution. This is the key point. A PBU message
> from the MN can be the first step towards activating the handover process. Or
> a FMI trigger from the LMA, may itself be the pre-trigger for PBU message from
> the MAG. At the end of the day, the LMA applies the policy and provides the
> set of prefixes to the MAG. MAG will continue to behave as in 5213. The
> decision logic, or the granularity of the policy rule applicability on the LMA
> can be out of scope
> [JCZ] I would add the case in which the prefixes are pre-assigned and the flow
> movement is started from the MN by simply sending packets to the new interface
> ³for instance² based on MN policies. This case would require no MN/MAG/LMA
> signaling and would satisfy the 3GPP/ANDSF concerns that have been raised
> without defining any policy management, network selection, etc in this draft.
> We just need to state in the draft that, if the LMA starts receiving packets
> over a different interface, it would understand this as an implicit IP Flow
> mobility change. In this case, the LMA should start using the same interface
> on which the uplink packets were received for subsequent downlink packets.
> 
> [Sri] If I followed this correctly, I¹m just not sure about the triggers on
> the UE end, as when it will use a prefix, received over on RA on one
> interface, and decide to move it to a different interface. Even if the out of
> band policy assumption is there, the triggers are critical, IMO. If this is
> about flow mirroring with no out of band policy interface, not sure, on the
> functional requirements on the UE for such case. DPI ?
> 
> 
> IFOM as well, IMO, but that¹s beside the point for now.  The policy activation
> on the UE, and the associated issues should be discussed in this context and
> as needed. 
> * This draft should not deal with flow policies, how they are applied and what
> granularity can be out of scope, IMO. These policies need not be carried in
> PMIP signaling place, unless we have MN-AR interface
> separate thread. The whole approach seems to be out of band at this point and
> not sure what can be specified on the PMIP signaling plane with respect to
> policy. 
> [JCZ] For these last three points, I agree with Pierrick that this draft
> should concentrate on the PMIP flow movement and not on the policy management.
> To me clarifying all the above points and cleaning up the wording and
> scenarios order would make the draft good enough for group¹s adoption.
> 
> [Sri] Agree. The draft appears to touch lot of aspects. In reality, if we get
> rid of flow templates from signaling, only deal with the approach of carrying
> prefixes as in base spec, with the assumptions on out of band flow policy
> interfaces, will simplify lot of things, will leave specific issues to deal
> with.
> 
>  
> 
> Regards
> Sri
> 
> 
> 
> 
> 
> 
>

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Fri, 4 Feb 2011 14:55:18 -0500

Hi Sri,

Some explanation below:

From: Sri Gundavelli [mailto:[email-masked]] 
Sent: February 4, 2011 1:47 PM
To: Zuniga, Juan Carlos; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc

Hi Juan Carlos,

Please see inline ...

On 2/4/11 8:34 AM, "Zuniga, Juan Carlos" <[email-masked]> wrote:

Please see inline:

Hi Pierrick:

[Sri] If I followed this correctly, I'm just not sure about the triggers on the UE end, as when it will use a prefix, received over on RA on one interface, and decide to move it to a different interface. Even if the out of band policy assumption is there, the triggers are critical, IMO. If this is about flow mirroring with no out of band policy interface, not sure, on the functional requirements on the UE for such case. DPI ? 

[JCZ] The case when different prefixes are used on different interfaces is a different one, and it is still valid. I'm assuming here what is mentioned in section 3.2 of the document, when the LMA "assigns a common prefix (or set of prefixes) to the different physical interfaces attached to the domain, then all the MAGs have already all the routing knowledge required to forward packets to the mobile node, and the LMA does not need to perform any kind of signaling in order to move flows across the different physical interfaces." 

All I'm saying is that in this configuration the MN could take the lead and move the flow, based "for example" on an ANDSF policy rule stating that a certain flow or application should use certain access (e.g. when the access becomes available, or goes away) . Since the prefix has already been assigned, this can be done with no extra signaling. No need to dig too deep in the definition of how the trigger happens, as that is out of scope. The only thing we need to specify is the requirement on the LMA to mirror packets on the DL. 

[Sri] Agree. The draft appears to touch lot of aspects. In reality, if we get rid of flow templates from signaling, only deal with the approach of carrying prefixes as in base spec, with the assumptions on out of band flow policy interfaces, will simplify lot of things, will leave specific issues to deal with.

Regards
Sri

 
BR,
Pierrick

Hello Sri,
Cheers,
Stefano

Stefano 
Stefano M. Faccin 

Standards Manager 
Research In Motion 

Hi Sri,

 
Cheers
Gerardo

Hi Stefano,

One comment.

Regards
Sri

Cheers,
Stefano

Regards
Sri

Cheers,
Stefano

Sri

Cheers,
Stefano

Hello,

-Basavaraj

---

From: Julien Laganier <[email-masked]>
Date: Fri, 4 Feb 2011 12:56:48 -0800

Hi Sri,

I just want to react to one of your comment which I'm quoting below:

On Fri, Feb 4, 2011 at 10:47 AM, Sri Gundavelli <[email-masked]> wrote:
>
> [...]
> [Sri] If I followed this correctly, I’m just not sure about the triggers on
> interface, and decide to move it to a different interface. Even if the out
> of band policy assumption is there, the triggers are critical, IMO. If this
> is about flow mirroring with no out of band policy interface, not sure, on
> the functional requirements on the UE for such case. DPI ?

This WG needs not to be concerned with triggers on the UE end, however
critical they might be.

When this effort started we all agreed the IP layer is unmodified, and
whatever magic is required, it happens below IP, and thus is out of
scope for this WG.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Fri, 4 Feb 2011 12:59:27 -0800

> y'day), you provide it in FMI.

IMO the prefix can always be conveyed in the PBA that is received in
response to the PBU attaching an interface to a PMIPv6 flow mobility
session.

--julien

---

From: <[email-masked]>
Date: Fri, 4 Feb 2011 21:29:47 +0000

>whatever magic is required, it happens below IP, and thus is out of

Correct. 
There is no expectation of changes on the UE at the IP layer. Or for that
matter any MN-AR(MAG) signaling at the IP layer.
The only assumption regarding flow mobility is the existence of the
logical interface on the MN.

-Raj

---

From: Tran Minh Trung <[email-masked]>
Date: Sat, 5 Feb 2011 07:26:19 +0900

> response to the PBU attaching an interface to a PMIPv6 flow mobility

If so, how does MAG know when the interface is attached to a new
mobility session to send PBU to the LMA?.

It may need a new trigger message sent from LMA to MAG or the LMA can
send prefix in FMI message whenever it attaches an interface to a new
mobility session as described in the draft.

Regards,
TrungTM

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Sat, 05 Feb 2011 16:41:48 +0100

Dear Trung,

Current draft already does this. No need to change it, just to rewrite
some parts so it is more clear and to remove some optional features that
are not required.

Thanks,

Carlos

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Sat, 05 Feb 2011 16:41:51 +0100

> in the PBU. This information does not need to be (re)conveyed at flow

If different prefixes are assigned for different sessions, and we want
to move flows across interfaces, we need some kind of signaling to make
the MAG aware of the prefixes. It cannot be done at session creation,
since not all the interfaces necessarily attach simultaneously,

Carlos

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Sat, 05 Feb 2011 16:41:54 +0100

> response to the PBU attaching an interface to a PMIPv6 flow mobility

What about the following scenario:

MN has two interfaces: if1 and if2. if1 attaches to MAG1, a mobility
session is created, pref1 is delegated. Some point in time later, if2
attaches to MAG2, new mobility sesison created, pref2 is delegated.
flowX addressed to pref2 wants to be moved to if1. In this case we need
some signaling from LMA to MAG1 that cannot be conveted in PBA.

Carlos

---

From: Julien Laganier <[email-masked]>
Date: Sun, 6 Feb 2011 10:11:54 -0800

> some signaling from LMA to MAG1 that cannot be conveted in PBA.

If flow X addresssed to pref2 wants to be moved to if1, first thing to
do is to attach the if1 to the session corresponding to pref2, so MAG1
sends a PBU, and LMA sends back a PBA with the prefix set of the
session (pref2.)

Then at flow movement no prefix to be sent, no?

--julien

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Sun, 06 Feb 2011 19:38:21 +0100

Hi Julien,

> sends a PBU, and LMA sends back a PBA with the prefix set of the

if1 was previously attached to MAG1 (and LMA delegated pref1). How can
MAG1 know when LMA wants to move flow X to if1 (to send a PBU)? Some
signaling is needed there.

Kind Regards,

Carlos

---

From: Julien Laganier <[email-masked]>
Date: Sun, 6 Feb 2011 10:56:30 -0800

Hi Carlos,

> signaling is needed there.

if1 was attached to MAG1 and had session S1 with prefix pref1. When
if2 is attached to MAG2, if a different prefix pref2 is allocated,
that is a different session S2. LMA cannot move a flow from session S2
to a MAG that isn't part of that session. So first thing to do after
S2 is created, if there's a desire to move flows across other MAGs, is
to attach other interfaces to the session, i.e., MAG1 sends a PBU to
attach if1 to S2, too (althout if1 is also attached to session S1.)

--julien

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Sun, 06 Feb 2011 20:14:56 +0100

Hi Julien,

> S2 is created, if there's a desire to move flows across other MAGs, is

Right, our draft uses FMI signalling to add if1 to the session (we use
the flowmob cache structure of this purpose). We are discussing about
two ways of doing exactly the same thing. However, in yours, you need
the MAG to take the initiative, while ours also supports the LMA
initiate the flow movement.

Carlos

---

From: Julien Laganier <[email-masked]>
Date: Mon, 7 Feb 2011 12:43:57 -0800

Hi Carlos,

> initiate the flow movement.

You seem to be conflating session management and flow movement.

In my approach, session management is MAG initiated, as it has been in
the past with PMIPv6. Once a session exists across an interface set,
flow movement can be LMA-initiated at any time from one interface in
the set to another.

I do not see a reason to depart from RFC 5213 and allow the LMA to
initiate session management (except for purposes of revocation but
that is supported already.)

--julien

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 07 Feb 2011 22:52:54 +0100

Hi Julien,

> that is supported already.)

I see the reason to add it in order to support the scenarios I mentioned
in my example. Those cannot be supported with RFC5213 model, as they
require first the MAG to send a PBU. We need either new signaling from
the LMA to the MAG to make the MAG aware of the required prefixes to
support flow mobility, or a trigger from the LMA to the MAG, so the MAG
can send a PBU and then follow your model.

Carlos

---

From: Julien Laganier <[email-masked]>
Date: Mon, 7 Feb 2011 15:56:33 -0800

Hi Carlos,

> can send a PBU and then follow your model.

In the systems I know the MAG is the entity that creates attaches a MN
interface to a session and therefore I do not understand why you would
need the LMA to attach an interface to a session. The LMA has no
interface with the interface... That's a MAG duty.

In which system is the scenario you're outlining useful?

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 07 Feb 2011 16:31:18 -0800

> that is supported already.)

Thank you.

I cannot emphasize more than this. We are not looking at flow management as
an extended state of BCE entry, rather as some thing new. BCE state is
different and flow mobility state is different. We want to define our own
brand of messages. 

MAG is responsible for creating the session state and the request for flow
mobility is carried right in that PBU message. The trigger from LMA to MAG
is needed when policy changes and that is when it can send an FMI trigger.
No need for FMA, session management is always initiated by MAG.

The trigger in 99.99% of the times is coming from MAG. MN brings up an
interface/pulls down an interface and that triggers the LMA to apply a flow
policy rules. But, the MAG sending a PBU is the trigger for flow mobility.
LMA in most cases is learning the triggers from MAG, which is attached to
MN, except for reasons of policy change, where there is a need to send a
trigger to MAG to send a PBU and that is FMI message.

Hope we can get some sense into this draft.

Sri

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 08 Feb 2011 01:56:24 +0100

Hi Julien,

> In which system is the scenario you're outlining useful?

I must be really bad at explaining this...

Lets consider the following scenario:

- MN attaches if1 to MAG1. As a result, if1 is attached to the session
with MAG1. Pref1::/64 is delegated to if1.

- Later on, MN attaches if2 to MAG2. As a result if2 is attached to the
session with MAG2. Pref2::/64 is delegated to if2.

(nothing new so far, no flow mobility)

- Some point in time later, LMA wants to move a flow X, addressed to
pref2::/64 to if1. MAG1 cannot send a PBU at that particular moment (how
can it know it has to?) to make MAG1 attach if1 to session with pref2.
Therefore, we need some signaling, initiated by the LMA, to make that
flow movement happen.

How can this scenario be supported with your approach? I fail to see it.

Thanks,

Carlos

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 08 Feb 2011 01:57:12 +0100

> trigger to MAG to send a PBU and that is FMI message.

So we need to support both cases, agree?

Carlos

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 07 Feb 2011 17:26:31 -0800

Right.

The LMA adding a prefix to an existing session should be supported. It's not
very different from a router advertising a new prefix on an interface to its
host. 

I might still be missing something here..
 
MAG initiates a new session at attach. To me, this is a new session at LMA
with its own prefix (p1 on if1 in my previous example). You can argue that
at the time of attach, the LMA *can* assign all available prefix(es). That's
option A). As I have mentioned earlier, I would like to be able to assign a
prefix (e.g., p1) for the new session at attach, and add a different prefix
(e.g., p0) at any time. This is option B). I don't want to be forced to do
only A). 

-Rajeev

---

From: Tran Minh Trung <[email-masked]>
Date: Tue, 8 Feb 2011 10:08:13 +0900

Hi Carlos and Julien,

> How can this scenario be supported with your approach? I fail to see it.

I think you still mis-understand Julien solution.

Let's see the following scenario:

Step1: if1 is attached to MAG1, session 1 is created:

          Session1: [Pref1, MAG1, IF1]

Step2: if2 is attached to MAG2, session 2 is created:

         Session2: [Pref2, MAG2, IF2]

If we amuse that the MAG2 knows that IF2 and IF1 are hidden by a
logical interface to support flow mobility -> MAGs send PBU messages
to attaches IF1 to S2 and IF2 to S1. Then two sessions are updated as
follow:

         Session1: [Pref1, MAG1, IF1, IF2]
         Session2: [Pref2, MAG2, IF2, IF1]

After that flow can be moved freely without extra signaling messages
in any-cases (eg. policy changes)

My question to Julien is that: How can MAG1 know that Session 2 is
created to attach IF1 to S2 in advance?

Regards,
TrungTM

---

From: Julien Laganier <[email-masked]>
Date: Mon, 7 Feb 2011 17:14:00 -0800

Hi Carlos,

> How can this scenario be supported with your approach? I fail to see it.

This scenario can't be supported without if1 being part of session2
where the pref2 belongs. So what's needed is that if1 be attached to
session2 such that flows bound to prefix2 can move between if1 and
if2. As I've indicated to you in the systems I am familiar with the
MAG is the entity that creates session, which results in this
scenario:

- MN attaches if1 to session1. As a result, MAG1 signals to LMA that
if1 is attached to the session1. Pref1::/64 is delegated to session1.

- Later on MN wants another session. As a result, MAG1 signals to LMA
that if1 is attached to the session2. Pref2::/64 is delegated to
session2.

- Later on MN attaches if2 to session2. As a result, MAG2 signals to
LMA that if2 is attached to the session2. Pref2::/64 is now valid over
both if1 and if2 for session2.

- Some point in time later, LMA wants to move a flow X, addressed to
pref2::/64 to if1. It does so :-)

That works well. Where is the system that requires supporting the
scenario you outlined that can't be supported through the nominal RFC
5213 model?

--julien

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 07 Feb 2011 17:32:56 -0800

> response to the PBU attaching an interface to a PMIPv6 flow mobility

I think I see an attach as an independent session at the LMA. This is not a
departure from the existing PMIP6 model. The session can have whatever
prefix, policy, accounting and so on. For our purposes here, I would like to
be able to add/refresh/delete any arbitrary prefix (which is valid on some
other attach/session) without being forced to assign that/those prefix(es)
only at the time of attach.

-Rajeev

---

From: Julien Laganier <[email-masked]>
Date: Mon, 7 Feb 2011 17:18:47 -0800

> I might still be missing something here..

I don't know why this should be supported... It is not supported in
RFC 5213 and has nothing to do with flow mobility. I have shown how
one can do flow mobility without this capability. What substantiates
the claim that this should be supported?

> (e.g., p0) at any time. This is option B). I don't want to be forced to do

I don't understand how adding different prefix at any time is related
to flow mobility, and I also don't know where an hypothetical
requirement to support this comes from. Can you enlighten us?

--julien

---

From: Julien Laganier <[email-masked]>
Date: Mon, 7 Feb 2011 17:22:42 -0800

Hi Tran,

> created to attach IF1 to S2 in advance?

I think the question is backward. The real question should be, if
there's an intent that flows bound to prefix2 be able to move between
if1 and if2, why on earth would session 2 be created without if1
attached to it? I see no reason.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Mon, 7 Feb 2011 17:26:54 -0800

> only at the time of attach.

Interfaces are attached to session. The flow mobility requires more
than one interface to be attached to a session. The session has
whatever prefix policy accounting color taste smell.

The fact that you want to add/refresh/delete prefixes has nothing to
do with flow mobility and is an inherent limitation of the RFC 5213
model. I see no reason to depart from that in the context of extending
the protocol to support mobility, nor I am aware of any system
architecture that would require this capability.

If this is something really important, the WG can be rechartered to
work on a different extension that would allow adding/removing
prefixes from existing PMIPv6 sessions.

--julien

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 07 Feb 2011 17:54:45 -0800

> the claim that this should be supported?

Hmm.. I hope we are not making a requirement here that if something is not
supported in RFC 5213, it should not be worked on here.
Also, I don't think we are required to accept a single solution because it
fits some pre-existing model; we are working to add new functions within
some reasonable bounds which we all can agree on.

Of course if the LMA assigns all prefixes at the time of a new attach, there
is nothing do; this is already in the ID. And, I am okay with it.
I am not okay with that being the only choice.

> to flow mobility,

If the LMA does not add a prefix and signal to the MAG (which can then
advertise the signaled prefix in an RA to the MN), how can I get prefix p0
(valid on if0) to be valid on if1? NOTE: MAG didn't receive p0 on MN's
attach on if1.

> and I also don't know where an hypothetical

Which hypothetical requirement?

I don't want to assign p0 to if1 at attach. I want to be able to assign p0
to if1 when I need to. Doesn't sound hypothetical to me. Just an operational
choice.

-Rajeev

---

From: Julien Laganier <[email-masked]>
Date: Mon, 7 Feb 2011 17:51:17 -0800

> some reasonable bounds which we all can agree on.

Technically speaking dynamic prefix management is a different feature
from flow mobility, thus if specified it should go in a different spec
so that one can implement RFC 5213 with dynamic prefix management but
without flow mobility.

On a more procedural note, I hope we can all agree that there is
indeed a charter that details what we are working on and that we are
not packing arbitrary features that are not listed as deliverables
into the protocol. We are chartered to do PMIPv6 flow mobility, not
dynamic prefix management for PMIPv6.

> I am not okay with that being the only choice.

Then explain to us who is the customer for PMIPv6 dynamic prefix
management, and convince the community that this is important enough
for this WG to be rechartered to do it. This is how the IETF work, WG
are being rechartered all the time.

>> and I also don't know where an hypothetical requirement to support
> > this comes from. Can you enlighten us?
>

That of doing dynamic prefix management for PMIPv6. It's not clear
that 3GPP needs a feature like that. Who needs it then?

> to if1 when I need to. Doesn't sound hypothetical to me. Just an operational

We discuss whether or not it's operational, but actually it is only
possible via a function that is different from flow mobility, which I
call dynamic prefix management, that hasn't been part of the original
PMIPv6 model. It's not because you want something that it belongs to
the flow mobility specification.

--julien

---

From: Tran Minh Trung <[email-masked]>
Date: Tue, 8 Feb 2011 10:51:52 +0900

On Tue, Feb 8, 2011 at 10:41 AM, Julien Laganier <[email-masked]> wrote:
> On Mon, Feb 7, 2011 at 5:30 PM, Tran Minh Trung <[email-masked]> wrote:
>> On Tue, Feb 8, 2011 at 10:22 AM, Julien Laganier <[email-masked]> wrote:
>>> Hi Tran,
>>>
>> How can you create session 2 with IF1 without informing MAG1 about prefix2?
>> I think the attachment is completed only when MAG1 is received PBA
>> message including Prefix2. But it needs PBU messages from MAG1 first.
>
> Right so this what you do. If you want a session2 that allows to move
> flows between if1 and if2, you attach both if1 and if2 to session2
> when the interfaces are brought up.
>
>> I sill do not understand how MAG1 can initiate PBU message to attach
>> IF1 to session2.
>
> IF1 is brought up. There is a desire to have session2 encompassing
> this interface. So, MAG1 sends a PBU to attach IF1 to session2. What
> is complicated?
>

In the above scenario, the session 2 is created only after the IF2 is
attached to MAG2. We can not attach IF1 to session 2 when it dose not
exist.

Is that right?

Regards,
TrungTM

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 08 Feb 2011 02:53:18 +0100

Hi Julien,

> that if1 is attached to the session2. Pref2::/64 is delegated to

How does the MN express that "desire of another session"? Besides, how
does the MN knows that it'd require that session, before even
considering attaching the second interface if2?

With current RFC5213, I don't know how two different mobility sessions
referring to the same interface of the MN can be created. I see how
different prefixes can belong to the same mobility sessions, though. Are
you already referring here to an extension to current PMIPv6?

> both if1 and if2 for session2.

MN cannot really "attach" anything, it is unaware of PMIPv6 operations
(at least its IP stack).

How could the MAGs know what interfaces should be added to which
sessions? I'm really sorry that I still don't get your point, but in
your reasoning it seems that events just occur in the right order to
support flow mobility, but in reality MAGs do not know about all the
interfaces a MN has, which ones are attached to the same PMIPv6 domain,
and so on and so forth. Flow mobility should be controlled by the LMA,
which is the only entity that can understand triggers (PBUs can be used
as triggers as well) and "add" interfaces to mobility sessions.

Thanks,

Carlos

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 08 Feb 2011 02:53:24 +0100

Hi Julien,

> attached to it? I see no reason.

Because the MAGs are not aware in advance of how the LMA wants to move
flows, nor about how many interfaces the MN has attached to the same
domain. Only the LMA knows that.

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 07 Feb 2011 18:15:03 -0800

If flow mobility has nothing do with prefix management, I am lost.
Or, I am being forced to accept a model as the only way to do flow mobility,
which I cannot.

> whatever prefix policy accounting color taste smell.

Session is created upon attach which can happen when a MN attaches to an
interface. "Interfaces are attached to a session" is right, there is ATT in
the BCE (and PBU); so is the prefix assigned assigned to the session.

> model. 

See previous note. If I cannot add a prefix (which is not valid on an
interface), I don't know how I can move a flow (Carlos has shown this
scenario as well).

> I see no reason to depart from that in the context of extending

Okay, see your position. I see it differently. I don't need to be bound by
some "presumed implementation model" of PMIP6 and limit myself *only* to a
prefix assignment model you are imagining.

> prefixes from existing PMIPv6 sessions.

Huh.. What in the current charter forces us not to have the LMA
add/refresh/delete a prefix on-demand?

-Rajeev

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 08 Feb 2011 03:00:08 +0100

Hi Julien,

> dynamic prefix management for PMIPv6.

I'm sorry, but solution described in our draft (of course you may like
it or not, we can agree/disagree on its technical approach, etc.) is
perfectly within the scope of the charter. It is not fair you consider
it out of scope.

Thanks,

Carlos

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 07 Feb 2011 18:33:42 -0800

> so that one can implement RFC 5213 with dynamic prefix management but

You can call it what you want, but that's the scenario I would like to be
supported. Just because some folks have some implementation assumptions in
RFC 5213 does not mean that we cannot do something different here.

> dynamic prefix management for PMIPv6.

To me this is not technical discussion. I see it perfectly under the current
charter, and frankly not interested in this discussion.

> are being rechartered all the time.

I didn't call it "PMIPv6 dynamic prefix management", you did.
I see it no different from the overall network-based flow mobility problem
we are working on.

> the flow mobility specification.

We can call it whatever. I don't see how *flow mobility* can be done for the
scenarios I (and Carlos, Trung) have been referring to.
And, just because RFC 5213 has certain limitation (on when a prefix is
assigned), doesn't mean that we cannot extend it.

-Rajeev

---

From: Julien Laganier <[email-masked]>
Date: Mon, 7 Feb 2011 20:24:45 -0800

2011/2/7 Carlos Jesús Bernardos Cano <[email-masked]>:
> How does the MN express that "desire of another session"?

L2 triggers. As per RFC 5213.

> Besides, how does the MN knows that it'd require that session, before even

The trigger to session2 creation is not attachment of a second
interface, it's the will of having a different session from the one
that existed in the first place, session1 aka default session. If
there will be flows in session2 that will need to get on if1 or if2 at
some point, you can simply create session2 whenever the first
interface in the set is brought up. Conversely, you can tear down the
session whenever both interfaces are down. Not sure what is so
complex.

> you already referring here to an extension to current PMIPv6?

Yes. You define a session as a set of prefixes that are valid over a
set of interfaces. This is the only thing that you need to do to
support flow mobility, no need for FMI/FMA and LMA initiated
signaling.

> MN cannot really "attach" anything, it is unaware of PMIPv6 operations

Right, layer 3 of the MN is unaware. Layer 2 (virtual interfaces etc.)
is, otherwise none of that can possibly work.

> sessions?

A MAG attaches interfaces to session based on the policy profile or L2
triggers. If neither the policy profile nor L2 triggers says anything
about multiple session, then I guess the MAG simply attaches whatever
interfaces comes up to the only session that the MN has. We do not
need to make this more complicated than needed to be.

> I'm really sorry that I still don't get your point, but in
> and so on and so forth.

In reality MAG doesn't need to know about all the interfaces the MN
has. MAG simply need to knows what interface should be attached to
which session. It knows this via L2 triggers or policy profile.

> Flow mobility should be controlled by the LMA,

Interface being attached to a session is controlled by the MAG which
is the only entity that knows that an interface is actually attached.
Flow mobility decision can be taken entirely at LMA and the MAG needs
not to know.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Mon, 7 Feb 2011 20:37:33 -0800

> If flow mobility has nothing do with prefix management, I am lost.

No reason to be lost: Prefix management is how do I get prefix for the
MN. Flow mobility is how to I move flows across interfaces. The two
needs not to be intertwined together, as I've shown in my other notes.
E.g., I can do flow mobility without adding/deleting prefixes from
sessions, and vice versa.

> Or, I am being forced to accept a model as the only way to do flow mobility,

Quoting RFC 1958: "3.2 If there are several ways of doing the same
thing, choose one." Is this something you can't accept?

> the BCE (and PBU); so is the prefix assigned assigned to the session.

Haven't said something different. Session has prefix set, and interface set.

> interface), I don't know how I can move a flow (Carlos has shown this

You add the interface to the session, then you can move the flow to
that interface...

> prefix assignment model you are imagining.

It's not an implementation model, it is a protocol model, and it's not
imaginary. Implementation has nothing to do with this.

There's no reason to extend prefix assignment model to do flow
mobility unless you can point me out in which real world context your
scenario actually happens.

Absent that, the only imaginary thing is your scenario.

> add/refresh/delete a prefix on-demand?

Engineering is about finding a solution to a problem. Adding/deleting
prefix on-demand is not a solution to flow mobility. I've shown you
how to do flow mobility without this capability.

Now a different engineering problem would be: how to add/delete
prefixes to a PMIPv6 session, and that would be useful for e.g.
renumbering. This is a different problem that we haven't been
chartered to work on.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Mon, 7 Feb 2011 20:40:41 -0800

> perfectly within the scope of the charter. It is not fair you consider

You are mixing dynamic prefix management with flow mobility into one
protocol extensions where they are not required to.

Can you point me to a real world usecase where you actually need to
add/delete prefixes to do prefix management? I read 3GPP specs but I
don't know where this is needed. Is this needed somewhere else?

--julien

---

From: Julien Laganier <[email-masked]>
Date: Mon, 7 Feb 2011 20:44:56 -0800

> RFC 5213 does not mean that we cannot do something different here.

There are no implementations assumptions, there's a protocol function
that exists and you haven't made a convincing argument about why it
needs to be extended with adding/removing prefixes to support flow
mobility. Real world examples please.

[...]

> I didn't call it "PMIPv6 dynamic prefix management", you did.

I indeed did, because this is what it is.

> I see it no different from the overall network-based flow mobility problem

It is different. It's a renumbering function that does not exist, is
not required for flow mobility, and would be useful for non-flow
mobility RFC 5213.

> assigned), doesn't mean that we cannot extend it.

Your scenario doesn't happen in the real world. What is the usecase
you're addressing?!

--julien

---

From: Tran Minh Trung <[email-masked]>
Date: Tue, 8 Feb 2011 14:03:53 +0900

On Tue, Feb 8, 2011 at 1:12 PM, Julien Laganier <[email-masked]> wrote:
> On Mon, Feb 7, 2011 at 5:51 PM, Tran Minh Trung <[email-masked]> wrote:
> If session2 will at some point requires having flow sent to if1, why
> can't session2 be created when if1 brought up?
>

Because the MAG1 can not know all prefix(es) that will be assigned to
the sessions that will be created in the future.

In the above example, MAG1 can not know that prefix2 will be assigned
to session 2 when the IF2 is up.

Regards,
TrungTM

---

From: Julien Laganier <[email-masked]>
Date: Mon, 7 Feb 2011 21:10:27 -0800

> to session 2 when the IF2 is up.

All I'm saying is, if at some point flows from session2 have to go on
interface1, you create session2 when interface1 or interface2 comes
up, whichever happens first.

--julien

---

From: Tran Minh Trung <[email-masked]>
Date: Tue, 8 Feb 2011 15:26:43 +0900

> up, whichever happens first.

Well, I have simpler questions.

A new session can be created at any time, right?

Now, assume that session N is created when interface1,2 are already working.
How to attach both interface 1 and 2 to the new session N?

IMHO, when a new session is created for an interface, we need
signaling messages to attach another working interfaces in the set to
that new session.

Thank you,
TrungTM

---

From: Julien Laganier <[email-masked]>
Date: Mon, 7 Feb 2011 23:11:33 -0800

> How to attach both interface 1 and 2 to the new session N?

L2 triggers, or policy profile update triggers both MAG1 and MAG2 to
send PBU to attach if1 and if2 to a new session N.

--julien

---

From: Tran Minh Trung <[email-masked]>
Date: Tue, 8 Feb 2011 16:26:02 +0900

> send PBU to attach if1 and if2 to a new session N.

Did you mean that the LMA sends L2 triggers to both MAG1 and MAG2?

I am not sure it is valid assumption or not since creating a new
session is occurred at L3 and it is L3 Job.

I prefer to use extra signaling messages between LMA and MAGs as
FMI/FMA in the current draft, or using HUR/HUA messages as pro-active
signaling messages described in
https://datatracker.ietf.org/doc/draft-trung-netext-flow-mobility-support/?include_text=1

Regards,
TrungTM

---

From: "MELIA, TELEMACO (TELEMACO)" <[email-masked]>
Date: Tue, 8 Feb 2011 11:55:26 +0100

Carlos

Exactly, in the charter we say sequentially or simultaneously.
We need to cover both cases.

telemaco

---

From: "Youn-Hee Han" <[email-masked]>
Date: Tue, 8 Feb 2011 20:00:29 +0900

Hi Julien,

> Of Julien Laganier
> Sent: Tuesday, February 08, 2011 1:38 PM
> To: Rajeev Koodli

Yes, I agree with you. Flow mobility is how to move flows across interface.
So, I thought that it would be better to define "a flow" exactly in netext
WG prior to discuss flow mobility management. As the definition of "a flow",
all I can think is a five-tuple plus something. If we assume that it is
correct, I think that flow mobility and prefix addition are inevitably tied.
As you know, RFC5213 (and IPv6 protocol spec) already allow to assign
multiple prefixes across multiple interfaces of an MN. Yes, I also agree
with you that in real-world (3GPP), there may be no need to assign multiple
prefixes into an MN. (if somebody knows its necessity, please tell me when
it should happen). So, flow mobility can be done without adding prefixes.
However, different interfaces are allowed to be assigned different prefixes
by RFC 5213 and IPv6 spec. We can't expect what kind of prefixes an MAG
advertises. Therefore, sometimes, we need prefix addition to move a flow to
a new interface of which MAG does not yet advertise the prefix of the flow
being moved. 

(snip...)

> >> I see no reason to depart from that in the context of extending the
> >> protocol to support mobility, nor I am aware of any system
> > Okay, see your position. I see it differently. I don't need to be
> > bound by some "presumed implementation model" of PMIP6 and limit
> > myself *only* to a prefix assignment model you are imagining.
> 
> There's no reason to extend prefix assignment model to do flow mobility
> unless you can point me out in which real world context your scenario
> actually happens.

As I insisted in the old mail, I agree with Julien in this regard. Current
draft allows too much space regarding the prefix allocation model (unique,
shared, and hybrid). When a flow should be moved to a new interface and the
prefix which the flow uses is not yet advertised by the new MAG, just inform
the prefix to the MAG and thus make it advertise the prefix and setup the
tunnel based on the new prefix. That's all!. If the prefix is already
advertised by the MAG, there is nothing to do and just move the flow. This
behaviors are very natural one when we want to support IP-level mobility.

> prefix on-demand is not a solution to flow mobility. I've shown you how
> to do flow mobility without this capability.

>From the viewpoint of protocol, I think that at least, prefix addition to an
interface is a necessary function to support flow mobility, as I explained
above. But, it does not mean prefix addition should happen always whenever
flow mobility occurs. It is sometimes needed. 

> Now a different engineering problem would be: how to add/delete prefixes
> to a PMIPv6 session, and that would be useful for e.g.
> renumbering. This is a different problem that we haven't been chartered
> to work on.

Prefix addition is just prefix addition. IMHO, renumbering is closer to
prefix change. We just harness that function to support IP-level mobility.

Youn-Hee

---

From: "MELIA, TELEMACO (TELEMACO)" <[email-masked]>
Date: Tue, 8 Feb 2011 12:22:50 +0100

Hi Stefano,

We agree that the solution has to have a customer, no need to convince me. All what I am saying is that there are other methods to solve the ESSID issue, for instance considering WIFI as trusted access. As you are well aware some vendors are already offering solutions.
In my opinion this is orthogonal to the current discussions on the list.

My 2 cents
telemaco

________________________________
De : Stefano Faccin [mailto:[email-masked]]
Envoyé : vendredi 4 février 2011 19:15
À : MELIA, TELEMACO (TELEMACO); Sri Gundavelli; Giaretta, Gerardo; stefano faccin
Cc : [email-masked]; [email-masked]
Objet : RE: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc

Telemaco,

Stefano Faccin

Standards Manager

Stefano, all,

telemaco

Sri,

Stefano Faccin

Standards Manager

Hi Stefano,

Regards
Sri

Cheers,

Hi Sri,

Cheers
Gerardo

Hi Stefano,

One comment.

Regards
Sri

Cheers,
Stefano

Regards
Sri

Cheers,
Stefano

Sri

Cheers,
Stefano

Hello,

-Basavaraj

---

From: <[email-masked]>
Date: Tue, 8 Feb 2011 17:25:21 +0100

Hi,

Going through this long thread :-), it seems we could agree on the following (just a tentative to summarize):

Sessions should be created/updated with all available interfaces. Rewriting Tran's example: when the MN attaches to MAG1 via If1, the LMA creates session 1:

Then, if the MN attaches to MAG2 via If2, the LMA creates session 2 with both If1 and If2. The LMA also updates session 1 with If2: 

MAG2 receives prefixes 1 and 2 in PBA but MAG1 is not sending PBU. So, if the LMA wants to move flow with Pref2 from if2 to If1, the LMA needs to provide Pref2 to MAG1. Also, the LMA should be able to create new sessions with already up interfaces, e.g. if1 and if2. To address both issues, PBU from MAG1 could be triggered (triggering is to be clarified) or we could define LMA/MAG specific L3 signalling (FMI/FMA).

My 2 cents,
Pierrick

> de Youn-Hee Han
> Envoyé : mardi 8 février 2011 12:00
> À : 'Julien Laganier'; 'Rajeev Koodli'

---

From: Julien Laganier <[email-masked]>
Date: Tue, 8 Feb 2011 13:41:31 -0800

> Did you mean that the LMA sends L2 triggers to both MAG1 and MAG2?

No. I meant the L2 or a policy profile update triggers both MAG1 and
MAG2 to attach interface1 and interface2 to session2 by sending a PBU.

> session is occurred at L3 and it is L3 Job.

See above.

> https://datatracker.ietf.org/doc/draft-trung-netext-flow-mobility-support/?include_text=1

Well this is your preference but in the systems that use PMIPv6 I am
familiar with (3GPP), the session (PDN connection) is always created
by the MAG (SGW / ePDG), upon L2 trigger (attach, additional PDN
connectivity.)

Nobody has been able to point me out a real world scenario in which
the LMA unilateraly decides to create a session...

--julien

--julien

---

From: Julien Laganier <[email-masked]>
Date: Tue, 8 Feb 2011 13:46:12 -0800

> since not all the interfaces necessarily attach simultaneously,

I should have written "The LMA can provide the prefix to the MAG at
the time when the interface is attached to that session by the MAG,
i.e., by including the prefix in the PBA that replies to the PBU
attaching the interface."

Also as I said to Tran, in the systems that use PMIPv6 I am
familiar with (3GPP), the session (PDN connection) is always created
by the MAG (SGW / ePDG), upon L2 trigger (attach, additional PDN
connectivity.)

What is a real world scenario in which the LMA unilateraly decides to
create a session? Who needs that? What problem does it solve? etc.
etc.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Tue, 8 Feb 2011 13:55:32 -0800

Hi Youn-Hee,

On Tue, Feb 8, 2011 at 3:00 AM, Youn-Hee Han <[email-masked]> wrote:
> multiple prefixes across multiple interfaces of an MN.

I know this, but in 5213 the LMA doesn't unilaterally decide to create
a new session with a different prefix et. What is documented in 5213
is a way by which the LMA avoids the same session to be used across
different interfaces unless the MAG explicitley requested for that to
happen via setting the Handoff Indicator to "handoff across different
interfaces.

So the entity that decides if multiple session are created is the MAG,
based on L2 triggers or policy profile.

>                                                                                                Yes, I also agree

So we don't need any of the additional complexity (LMA to MAG
signaling) unless there is a real world usecase for it. Who needs an
LMA to unilaterally create sessions? What problem does it solve?

> by RFC 5213 and IPv6 spec.

They are not allowed to be assigned different prefixes. They are
required to be assigned different prefixes and session based on the
MAG being unable to determine whether the host supports handoffs
across interfaces (thanks to virtual interface) or not. This is to
avoid a legacy host to break down. This is not the same as saying the
LMA can decide to have multiple sessions.

Please review the multihoming discussion we had on the netlmm list at
the time of RFC5213 work.

>                                             We can't expect what kind of prefixes an MAG

No you don't, unless you have a real world use case.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Tue, 8 Feb 2011 14:18:40 -0800

Hi Pierrick,

I am going to intertwine the steps in your scenario below with the
missing pieces of the big picture so that we are not doing an academic
exercise but focusing on the real world:

1. when the MN first attaches with if1 to a network, MAG1 requests
attachment of if1 to a session1 by sending a PBU to LMA

2. because the MN add no session1 previously, the LMA creates session
1 and allocates a prefix for it. The prefix is sent back to MAG1 in
the PBA:

          Session1: [Pref1, MAG1-IF1]

3. then, if the MN attaches with if2 to another network, but does not
request this interface be attached to a distinct session, MAG2
requests attachemnt of If2 to session1 by sending a PBU to LMA

4. Because the MN already has session 1, the LMA updates session1 with
if2, and send the pref1 back to MAG2 in the PBA:

         Session1: [Pref1, MAG1-IF1, MAG2-IF2]

5. Creation of a new session 2 for if2 is requested by either of MN
requests via L2 triggers, or a change in policy profile. As a result,
MAG2 requests attachment of if2 to session2 by sending a PBU to LMA.

6. because the MN add no session2 previously, the LMA creates session
2 and allocates a prefix for it. The prefix pref2 is sent back to MAG2
in the PBA:

          Session2: [Pref2, MAG2-IF2]

7. Flow2 starts over if2 with prefix2.

8. Attachment of if1 to session2 is requested by either of MN requests
via L2 triggers, or a change in policy profile. As a result, MAG1
requests attachment of if1 to session2 by sending a PBU to LMA.

9. Because the MN already has session 2, the LMA updates session2 with if1:

         Session2: [Pref2, MAG2-IF2, MAG1-IF1]

10. At any point, the LMA decides to move Flow2 between two interfaces
of session 2, and it does so.

That's all that needed. It maps perfectly to 3GPP. If you have in mind
a different system in whcih that doesn't map, please let me know.

--julien

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 09 Feb 2011 00:37:05 +0100

Hi Pierrick,

Thanks for the summary. I agree with your summarized view.

Carlos

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 09 Feb 2011 00:37:13 +0100

Hi Julien,

> protocol extensions where they are not required to.

Whether they are required or not depends on the assumptions of the
scenario.

> don't know where this is needed. Is this needed somewhere else?

Can you point me a scenario which cannot be supported with our approach
(which requires less L2 triggers to be in place)?

Carlos

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 09 Feb 2011 00:37:16 +0100

Hi Julien,

I agree with all your points below, in the sense that it's true that
flow mobility could be enabled by relying on all those L2 triggers.
Where I disagree is why we need to do so if we can do it without putting
those strong requirements. I understand relying on L2 when it is that or
modifying the IP stack of the MN, but not in any other case. Besides,
the modifications we propose are fairly simplex.

Carlos

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 08 Feb 2011 17:12:34 -0800

Hello Pierrick,

Someone had to do this to make progress :-)

I largely agree, please see below:

On 2/8/11 8:25 AM, "[email-masked]"

> Sessions should be created/updated with all available interfaces. Rewriting
> Tran's example: when the MN attaches to MAG1 via If1, the LMA creates session
> 1:
> 
> Then, if the MN attaches to MAG2 via If2, the LMA creates session 2 with both
> If1 and If2. The LMA also updates session 1 with If2:
> 
> MAG2 receives prefixes 1 and 2 in PBA

This is fine with me, i.e., LMA sending Pref2 and Pref1 at this time.
As I have stated before, I should also be able to *not* send Pref1 to MAG2
at this time (attach), i.e., send it whenever LMA wants.

> but MAG1 is not sending PBU. So, if the
> LMA wants to move flow with Pref2 from if2 to If1, the LMA needs to provide
> Pref2 to MAG1. Also, the LMA should be able to create new sessions with
> already up interfaces, e.g. if1 and if2. To address both issues, PBU from MAG1
> could be triggered (triggering is to be clarified) or we could define LMA/MAG
> specific L3 signalling (FMI/FMA).
> 

I would like LMA-initiated signaling (FMI/FMA) for this (i.e., signaling to
MAG1 with Pref2) as well as for the above (i.e., being able to signal MAG2
with Pref1) *whenever* the LMA wants.

Thanks,

-Rajeev

---

From: Julien Laganier <[email-masked]>
Date: Tue, 8 Feb 2011 17:15:25 -0800

Hi Carlos,

> Hi Julien,

[snip.]

> Whether they are required or not depends on the assumptions of the

Yes. And I'm saying that the scenario you assume doesn't address a
real-world usecase.

> (which requires less L2 triggers to be in place)?

This is backward.

It's not the role of a standard organization to pack in a standard
specification a feature on the ground that it doesn't prevent to
support scenario X.

On the contrary we should deliver specification that are solving real
world problems.

Now I've been asking for a couple of days already what is the
real-world usecase from which stems the pressing need to support
addition/deletion of prefixes on one hand, and LMA deciding
unilaterally to attach an existing session to another of the MN's
interface on the other hand.

So far I haven't got ANY answer besides statement that "this is
needed", or "I want it".

Should I take this state of affair as a confession that there's indeed
no real usecase?

--julien

---

From: Julien Laganier <[email-masked]>
Date: Tue, 8 Feb 2011 17:21:35 -0800

Hi Carlos,

I am glad to see you agree with me :-)

You're actually proving my point.

To run any of the flow mobility stuff on a host, you will need either
layer 2 to hide the dissimilar interfaces (virtual interface thing),
in which case you do have L2 triggers, or to modify the layer 3, which
this WG is explicitly prevented from doing assuming that's even
possible.

So you need layer 2. And that is actually exactly how netext could get
chartered to work on flow mobility, because we assumed layer 2 would
be there to help with all the stuff we're not allowed to do at layer
3.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Tue, 8 Feb 2011 17:25:41 -0800

Hello Rajeev,

What would actually really helps all of us to make progress is that
instead of telling what you'd like, as in

> with Pref1) *whenever* the LMA wants.

you'd rather tell us why this is needed, by whom, and where... I've
been asking the same question over and over but nobody writes down an
answer to this in this thread.

Absent that, will I be forced to conclude that this needed by no-one?

--julien

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 08 Feb 2011 18:19:16 -0800

Hi Youn-Hee,

> correct, I think that flow mobility and prefix addition are inevitably tied.

Exactly! 

> a new interface of which MAG does not yet advertise the prefix of the flow

Check. I need to be able to support this, without being forced to always
assign prefix(es) before-hand.

> When a flow should be moved to a new interface and the

In violent agreement here, not that it's the first time.
I have stated the above multiple times.

Right.

> prefix change. We just harness that function to support IP-level mobility.

Yup.

-Rajeev

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 09 Feb 2011 03:12:33 +0100

Hi Julien,

> be there to help with all the stuff we're not allowed to do at layer

Exactly, you need layer 2 to help with all the stuff we are not allowed
to do at layer 3, _but_ not to do things that we don't need to do at the
MN, and can be trivially done with LMA-MAG signaling without putting
strong requirements on the layer 2.

The signaling we define in our draft (or variations around that) allows
to support all the scenarios that have been mentioned so far, and does
not break any PMIPv6 concept -- just extends it. It does not require
complex layer 2 triggers/policies to be in place and it's therefore more
layer-2 agnostic. Still, you prefers to go for the "lets redo MIP at
layer-2", and I keep failing to see why

Carlos

---

From: Julien Laganier <[email-masked]>
Date: Tue, 8 Feb 2011 18:19:44 -0800

Hi Carlos,

> layer-2", and I keep failing to see why

PMIPv6 as per RFC5213 doesn't work without L2 triggers, so there's no
value in extending PMIPv6 to spare relying on L2 triggers that are
required anyway.

--julien

--julien

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 08 Feb 2011 18:51:03 -0800

Hi Julien,

> instead of telling what you'd like, as in

It would also help if you didn't generalize your reservation to what I am
stating as in "..helps *all* of us..".

I see you have a model in mind (which is pretty close to what is in the
draft already), which is fine. I fail to see why you are restricted to that
alone. But, perhaps that's less fruitful to delve into now.

> answer to this in this thread.

I have mentioned why I need it a few times. 1) I am not required to assign
all the applicable prefixes at the time of attach *in anticipation* of
*potential* flow mobility. I will assign a relevant prefix *if and when* I
need to move a flow over. It makes no sense for me to be *forced* to assign
all the prefixes at the time of attach (just because it is aligned with
legacy RFC 5213 "model"). 2) I want to assign a prefix based on policy
triggers, including the TOD rules. I want to move certain type of traffic
over to a different interface based on peak hour bulk stats, the volume of
traffic the user is consuming at a particular instance, the amount of quota
left and so on. I want to be able to refresh the lifetime of that prefix and
revoke it back to its "natural interface" when I want.

I want to be able to offer this for my customers.

> Absent that, will I be forced to conclude that this needed by no-one?

If I don't need something that does not imply the rest don't either! :-)

-Rajeev

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 09 Feb 2011 03:37:34 +0100

Hi Julien,

> value in extending PMIPv6 to spare relying on L2 triggers that are

L2 triggers are supported, but you are proposing more complex L2
triggers than required today for PMIPv6 as per RFC5213. Why should we
move all the functionality to external L2 triggers if we can do it at
the IETF (making the solution expect less from the Layer-2 technology
used by the MN)? Again, we are not talking about signaling/functionality
that modifies MN behavior, but just a new message between LMA-MAG minor
modifications on the state machines, so we are perfectly fine with the
charter.

Carlos

---

From: Julien Laganier <[email-masked]>
Date: Tue, 8 Feb 2011 18:42:21 -0800

> L2 triggers are supported, but you are proposing more complex L2

s/supported/required/

> triggers than required today for PMIPv6 as per RFC5213.

the trigger is exactly the same, it's "attach interface X to session
Y", where in RFC 5213 a session is defined as a tuple of MNID and
prefix set. We do not need more.

>                                                                                     Why should we
> used by the MN)?

I don't see where the scheme I am advocating expects more from L2
compared to a vanilla RFC 5213 model. The L2 trigger is the same.

--julien

>                                Again, we are not talking about signaling/functionality

---

From: Tran Minh Trung <[email-masked]>
Date: Wed, 9 Feb 2011 11:49:37 +0900

Hi Julien,

Let me show a real case for the scenario that we are discussing bellow:

The network policy is changed and the LMA decides to move flow 2 from
IF2 to IF1 before MAG1 received L2 trigger from the MN (say before
step #8)
In that case, the LMA should signal MAG1 to send PBU to attach IF1 to
session 2.

Without signaling from LMA how can you do in this case? Just wait
until receiving L2 trigger from the MN?

---

From: Julien Laganier <[email-masked]>
Date: Tue, 8 Feb 2011 18:53:47 -0800

Changing the policy on the network side alone isn't sufficient. You'd
have to change the policy on the host, too (e.g., using ADNSF in 3GPP)
which will trigger the MN to attach IF1 to session 2.

This is the system view picture which seems we're missing in this discussion.

--julien

---

From: Tran Minh Trung <[email-masked]>
Date: Wed, 9 Feb 2011 11:57:51 +0900

Since we are proposing network-based flow mobility, I think that it
must be transparent to the MN.
if not the network-based solution is similar as client-based one.

Regards,
TrungTM

---

From: Julien Laganier <[email-masked]>
Date: Tue, 8 Feb 2011 19:00:56 -0800

Network based flow mobility cannot be entirely transparent to the MN.
It can be made transparent to the *IP layer* on the MN, but at minimum
the layer 2 will have to change to decide where to send uplink
packets.

This is a fact.

I am sorry if that means that the network-based solution is
functionally equivalent to the client based and only differ in terms
of the placement of the functions in various layer, but I cannot help
it.

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 08 Feb 2011 19:03:36 -0800

Hi Tran:

Policy change is not a general case, it is a special case. It can indeed
take affect after a lapse of time. Either way, the trigger from LMA to MAG
is one option, I'm still not convinced why I'd need FMA. The trigger should
force the MAG to send a PBU and per RFC-5213, it should get a set of
prefixes that its hosting on the access link. This essentially, forces the
approach of session state creation at the request of the MAG. If policy
change is a valid case, a simple trigger is sufficient.

Regards
Sri

On 2/8/11 6:49 PM, "Tran Minh Trung" <[email-masked]> wrote:

>>> Tran's example: when the MN attaches to MAG1 via If1, the LMA creates
>>> session 1:
>>> 
>>> Then, if the MN attaches to MAG2 via If2, the LMA creates session 2 with
>>> both If1 and If2. The LMA also updates session 1 with If2:
>>> 
>>> MAG2 receives prefixes 1 and 2 in PBA but MAG1 is not sending PBU. So, if
>>> the LMA wants to move flow with Pref2 from if2 to If1, the LMA needs to
>>> provide Pref2 to MAG1. Also, the LMA should be able to create new sessions
>>> with already up interfaces, e.g. if1 and if2. To address both issues, PBU
>>> from MAG1 could be triggered (triggering is to be clarified) or we could
>>> define LMA/MAG specific L3 signalling (FMI/FMA).
>>> 
>>> My 2 cents,
>>> Pierrick
>>>

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 08 Feb 2011 19:06:08 -0800

> So we need to support both cases, agree?

Both cases ? Do you agree, a simple FMI trigger is sufficient ?

Sri

---

From: Julien Laganier <[email-masked]>
Date: Tue, 8 Feb 2011 19:07:17 -0800

Hi Rajeev,

> stating as in "..helps *all* of us..".

I simply wanted to say that since I see no usecase to justify the type
of features you'd like to have in, having a usecase outlined would
help this discussion to converge, which seems to be helpful to people
on this mailing list. There was certainly no intent to say that my
reservations are shared by the whole working group.

That being said,

> need to move a flow over.

In 3GPP, the prefix is assigned when the PDN connection is created,
and is then unchanged for the reminder of the lifetime of this PDN
connection.

So in your own words: You are not required to assign all the
applicable prefixes at the time of attach *in anticipation* of
*potential* flow mobility. You will assign the relevant prefix *if and
when* I you need a PDN connection.

If you have another target system than 3GPP, what is it?

>                           It makes no sense for me to be *forced* to assign
> legacy RFC 5213 "model").

Assigning all the prefixes at time of attaches isn't a requirement for
flow mobility. You can very well have a single prefix and do flow
mobility across multiple interfaces.

                                              2) I want to assign a
prefix based on policy
> triggers, including the TOD rules.

I don't see how useful it is to assign prefixes based on time of day.
I understand you might want to move flows based on time of day, but as
I said above, you can already move flows with a single prefix when the
time is good for you.

                                                             I want to
move certain type of traffic
> left and so on.

All capabilities that are perfectly available without juggling with
multiple prefixes, as above.

>                                 I want to be able to refresh the lifetime of that prefix and

This is renumbering - a different interface. I also don't know what a
natural interface is when prefixes are assigned from withing an
overlay...

> I want to be able to offer this for my customers.

Most of which you can, as I stated above, independently of prefix juggling...

> If I don't need something that does not imply the rest don't either! :-)

Can they speak up then? :-)

--julien

---

From: "Mohana Jeyatharan" <[email-masked]>
Date: Wed, 9 Feb 2011 11:09:10 +0800

Hi Trung,

The MAG getting some triggers from MN is not the same as Client based flow mobility mobility. Sessions are moved and created based on MAG to LMA signaling (as in the current draft).  Anyway, the draft-bernados has text that MAG can get such information from MN.  Although an explicit statement such as L2 is not mentioned.

Again as Julien pointed out, RFC 5213 also assumes such L2 signaling. 

BR,
Mohana

> Sent: Wednesday, February 09, 2011 10:58 AM
> To: Julien Laganier
> Since we are proposing network-based flow mobility, I think that it must be
> transparent to the MN.
> >> step #8) In that case, the LMA should signal MAG1 to send PBU to
> >> attach IF1 to session 2.
> >>
> >>> missing pieces of the big picture so that we are not doing an
> >>> academic exercise but focusing on the real world:
> >>>
> >>> 3. then, if the MN attaches with if2 to another network, but does
> >>> not request this interface be attached to a distinct session, MAG2
> >>> 4. Because the MN already has session 1, the LMA updates session1
> >>> with if2, and send the pref1 back to MAG2 in the PBA:
> >>>
> >>> 2 and allocates a prefix for it. The prefix pref2 is sent back to
> >>> MAG2 in the PBA:
> >>>
> >>> 8. Attachment of if1 to session2 is requested by either of MN
> >>> requests via L2 triggers, or a change in policy profile. As a
> >>> result, MAG1 requests attachment of if1 to session2 by sending a PBU to
> LMA.
> >>>
> >>> 10. At any point, the LMA decides to move Flow2 between two
> >>> interfaces of session 2, and it does so.
> >>>
> >>> That's all that needed. It maps perfectly to 3GPP. If you have in
> >>> mind a different system in whcih that doesn't map, please let me know.
> >>>
> >>> --julien
> >>>
> >>>> Going through this long thread :-), it seems we could agree on the
> following (just a tentative to summarize):
> >>>>
> >>>> Sessions should be created/updated with all available interfaces.
> Rewriting Tran's example: when the MN attaches to MAG1 via If1, the LMA
> creates session 1:
> >>>>
> >>>> Then, if the MN attaches to MAG2 via If2, the LMA creates session 2
> with both If1 and If2. The LMA also updates session 1 with If2:
> >>>>
> >>>> MAG2 receives prefixes 1 and 2 in PBA but MAG1 is not sending PBU.
> So, if the LMA wants to move flow with Pref2 from if2 to If1, the LMA needs
> to provide Pref2 to MAG1. Also, the LMA should be able to create new
> sessions with already up interfaces, e.g. if1 and if2. To address both issues,
> PBU from MAG1 could be triggered (triggering is to be clarified) or we could
> >>>>> De : [email-masked] [mailto:[email-masked]] De
> >>>>> la part de Youn-Hee Han Envoyé : mardi 8 février 2011 12:00 À :
> >>>>> 'Julien Laganier'; 'Rajeev Koodli'
> >>>>> Cc : [email-masked]; [email-masked] Objet : Re:
> >>>>> [netext] Consensus call to adopt I-D:draft-bernardos-netext-
> >>>>> pmipv6-flowmob as WG doc
> >>>>>
> >>>>> Hi Julien,
> >>>>>
> >>>>> > On Behalf Of Julien Laganier
> >>>>> > draft-bernardos- netext-pmipv6-flowmob as WG doc
> >>>>> >
> >>>>> > No reason to be lost: Prefix management is how do I get prefix
> >>>>> > for the MN. Flow mobility is how to I move flows across
> >>>>> > interfaces. The two needs not to be intertwined together, as I've
> shown in my other notes.
> >>>>> > E.g., I can do flow mobility without adding/deleting prefixes
> >>>>> > from sessions, and vice versa.
> >>>>>
> >>>>> So, I thought that it would be better to define "a flow" exactly
> >>>>> in netext WG prior to discuss flow mobility management. As the
> >>>>> definition of "a flow", all I can think is a five-tuple plus
> >>>>> something. If we assume that it is correct, I think that flow
> >>>>> mobility and prefix addition are inevitably tied.
> >>>>> As you know, RFC5213 (and IPv6 protocol spec) already allow to
> >>>>> assign multiple prefixes across multiple interfaces of an MN. Yes,
> >>>>> I also agree with you that in real-world (3GPP), there may be no
> >>>>> need to assign multiple prefixes into an MN. (if somebody knows
> >>>>> its necessity, please tell me when it should happen). So, flow
> >>>>> mobility can be done without adding prefixes.
> >>>>> However, different interfaces are allowed to be assigned different
> >>>>> prefixes by RFC 5213 and IPv6 spec. We can't expect what kind of
> >>>>> prefixes an MAG advertises. Therefore, sometimes, we need prefix
> >>>>> addition to move a flow to a new interface of which MAG does not
> >>>>> yet advertise the prefix of the flow being moved.
> >>>>>
> >>>>> (snip...)
> >>>>>
> >>>>> > >> I see no reason to depart from that in the context of
> >>>>> > >> extending the protocol to support mobility, nor I am aware of
> >>>>> > >> any system architecture that would require this capability.
> >>>>> > >
> >>>>> > > Okay, see your position. I see it differently. I don't need to
> >>>>> > > be bound by some "presumed implementation model" of PMIP6
> and
> >>>>> > > limit myself *only* to a prefix assignment model you are
> imagining.
> >>>>> >
> >>>>> > It's not an implementation model, it is a protocol model, and
> >>>>> > it's not imaginary. Implementation has nothing to do with this.
> >>>>> >
> >>>>> > mobility unless you can point me out in which real world context
> >>>>> > your scenario actually happens.
> >>>>>
> >>>>> As I insisted in the old mail, I agree with Julien in this regard.
> >>>>> Current draft allows too much space regarding the prefix
> >>>>> allocation model (unique, shared, and hybrid). When a flow should
> >>>>> be moved to a new interface and the prefix which the flow uses is
> >>>>> not yet advertised by the new MAG, just inform the prefix to the
> >>>>> MAG and thus make it advertise the prefix and setup the tunnel
> >>>>> based on the new prefix. That's all!. If the prefix is already
> >>>>> advertised by the MAG, there is nothing to do and just move the
> >>>>> flow. This behaviors are very natural one when we want to support
> IP-level mobility.
> >>>>>
> >>>>> > >> If this is something really important, the WG can be
> >>>>> > >> rechartered to work on a different extension that would allow
> >>>>> > >> adding/removing prefixes from existing PMIPv6 sessions.
> >>>>> > >
> >>>>> > > Huh.. What in the current charter forces us not to have the
> >>>>> > > LMA add/refresh/delete a prefix on-demand?
> >>>>> >
> >>>>> > Engineering is about finding a solution to a problem.
> >>>>> > Adding/deleting prefix on-demand is not a solution to flow
> >>>>> > mobility. I've shown you how to do flow mobility without this
> capability.
> >>>>>
> >>>>> From the viewpoint of protocol, I think that at least, prefix
> >>>>> addition to an interface is a necessary function to support flow
> >>>>> mobility, as I explained above. But, it does not mean prefix
> >>>>> addition should happen always whenever flow mobility occurs. It is
> >>>>> sometimes needed.
> >>>>>
> >>>>> Prefix addition is just prefix addition. IMHO, renumbering is
> >>>>> closer to prefix change. We just harness that function to support IP-
> level mobility.
> >>>>>
> >>>>> Youn-Hee
> >>>>>
> >> Electronics and Telecommunications Research Institute Standards
> >> Research Center
> >> 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel :
> >> +82-42-860-1132,   Fax : +82-42-861-5404
> >>
> >
> 
> 
> 
> --
> Ph.D., Senior Member
> Electronics and Telecommunications Research Institute Standards Research
> Center
> 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA Tel : +82-42-860-
> 1132,   Fax : +82-42-861-5404

---

From: Tran Minh Trung <[email-masked]>
Date: Wed, 9 Feb 2011 12:10:51 +0900

> the layer 2 will have to change to decide where to send uplink

Did we agreed that the logical interface can send uplink packets
following the path that down-link packets received?.
The key purpose of network-based solution is minimize the involvement of the MN.
IMHO, both vendors and network operator prefer that way.

Regards,
TrungTM

>>>>>>> prefixes

---

From: Tran Minh Trung <[email-masked]>
Date: Wed, 9 Feb 2011 12:13:30 +0900

Hi Sri,

If all of us are agree that it is not a general case and we can ignore
it then I think the Julien's solution is sufficient.

I am going out for lunch now.

Talk to you later.
Regards,
TrungTM

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Wed, 9 Feb 2011 06:24:37 +0000

For my clarification: L2 trigger from MN is the first thing that is received by the MAG when the MN attaches. This is for example when DHCP is performed in WLAN, when the IPsec tunnel is established with ePDG or when the LTE or eHRPD attach is completed. If that is the case, what is the reason to send packets to a MAG before the L2 trigger is received, i.e. before the MN is actually connected to the MAG?

Thanks
Gerardo 

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Tran Minh Trung
> Sent: Tuesday, February 08, 2011 6:50 PM
> To: Julien Laganier
> with
> MAG2
> requests
> mind
> So, if the LMA wants to move flow with Pref2 from if2 to If1, the LMA
> needs to provide Pref2 to MAG1. Also, the LMA should be able to create
> new sessions with already up interfaces, e.g. if1 and if2. To address
> both issues, PBU from MAG1 could be triggered (triggering is to be
> clarified) or we could define LMA/MAG specific L3 signalling (FMI/FMA).
> >>
> >> My 2 cents,
> >> Pierrick
> >>
> >>> Objet : Re: [netext] Consensus call to adopt I-D:draft-bernardos-
> netext-
> >>> pmipv6-flowmob as WG doc
> >>>
> >>> Hi Julien,
> >>>
> >>> > Subject: Re: [netext] Consensus call to adopt I-D: draft-
> bernardos-
> >>> > netext-pmipv6-flowmob as WG doc
> >>> >
> for the
> >>> WG prior to discuss flow mobility management. As the definition of
> "a
> >>> flow",
> >>> correct, I think that flow mobility and prefix addition are
> inevitably
> >>> tied.
> assign
> >>> advertises. Therefore, sometimes, we need prefix addition to move a
> flow
> >>> to
> extending the
> it's not
> mobility
> Current
> >>> shared, and hybrid). When a flow should be moved to a new interface
> and
> >>> the
> >>> prefix which the flow uses is not yet advertised by the new MAG,
> just
> >>> inform
> flow. This
> rechartered to
> Adding/deleting
> addition to
> >>> an
> chartered
> closer to

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Wed, 9 Feb 2011 06:33:41 +0000

Hi all,

I am starting a new thread to understand the use case this draft is trying to solve when referring to multiple prefixes. I think there has been some discussion already in the list but I did not get a good understanding of the rationale. 

My understanding is that the goal of the draft is to define a flow mobility solution for PMIP. This implies that a given PMIP session is shared across multiple interfaces and some IP flows belonging to that session are sent over one interface and some others over another interface. This is equivalent to the RFC6089: IP flows which are tied to the same HoA/HNP can be sent over one CoA/BID or another CoA/BID.

Is this the correct understanding of the goals of the I-D? Is this a common understanding of the term Flow Mobility?

If this is the case, then I don't understand why the draft is introducing text about the LMA creating a different session. Is this needed for Flow Mobility? If so, for which scenario?

Going back to Pierrick's example:

when the MN attaches to MAG1 via If1, the LMA creates session 1:

Then, if the MN attaches to MAG2 via If2, there is no reason for the LMA to create session 2. The LMA just needs to update session 1 with If2: 

In this way MAG/LMA/MN can send over IF2 a TCP connection which earlier was sent over IF1. This is Flow Mobility. 

Thanks
Gerardo

---

From: Tran Minh Trung <[email-masked]>
Date: Wed, 9 Feb 2011 17:04:59 +0900

Hi Gerardo,

> For my clarification: L2 trigger from MN is the first thing that is received by the MAG when the MN attaches. This is for example when DHCP is performed in WLAN, when the IPsec tunnel is establishe…

In the discussed scenario, the network policy is changed when the MN
is connecting to the MAG1 and MAG2 via IF1 and IF2 respectively.

It is a real case, we should find a solution to support it.

Now I can see two ways:

(1) The network send message to request the MN to update with new
policy. After that the MN sends trigger to MAG1 to attach IF1 to
session 2.

For example in 3GPP,  ANDSF can send SMS to UE via S14 interface to
request UE (MN) to update it policy. (Push model)

(2) Network sends signal to MAG1 directly to request MAG1 to attach
IF1 to session 2.

I prefer the second solution since the first one can delay the flow
mobility. Why we need to wait until the MN's profile is updated ?. The
logical interface can help the MN to send packet to the same path that
it receives packet from.

Regards,
TrungTM
Regards,
TrungTM

>> Behalf

---

From: Tran Minh Trung <[email-masked]>
Date: Wed, 9 Feb 2011 17:45:47 +0900

> Is this the correct understanding of the goals of the I-D? Is this a common understanding of the term Flow Mobility?

Yes you are right.

> Then, if the MN attaches to MAG2 via If2, there is no reason for the LMA to create session 2. The LMA just needs to update session 1 with If2:

We just follow the basic operation of the RFC5213 that a new prefix
will be assigned to new attachment.

Then we extend it to support flow mobility by allowing interfaces to
be attached to multiple sessions.

> In this way MAG/LMA/MN can send over IF2 a TCP connection which earlier was sent over IF1. This is Flow Mobility.

It only works for the flows in the session1. However session 2,3..n
can be created at anytime in the future. We have to attach all working
interfaces in the set to a new session whenever it is created.

Regards,
TrungTM

---

From: <[email-masked]>
Date: Wed, 9 Feb 2011 10:05:16 +0100

> de Tran Minh Trung
> Envoyé : mercredi 9 février 2011 09:46
> À : Giaretta, Gerardo
> Cc : [email-masked]
> Objet : Re: [netext] Multiple prefixes indraft-bernardos-netext-pmipv6-
> flowmob
> 
> > I am starting a new thread to understand the use case this draft is
> trying to solve when referring to multiple prefixes. I think there has
> been some discussion already in the list but I did not get a good
> understanding of the rationale.
> >
> > My understanding is that the goal of the draft is to define a flow
> mobility solution for PMIP. This implies that a given PMIP session is
> shared across multiple interfaces and some IP flows belonging to that
> session are sent over one interface and some others over another interface.
> This is equivalent to the RFC6089: IP flows which are tied to the same
> HoA/HNP can be sent over one CoA/BID or another CoA/BID.
> >
> > Is this the correct understanding of the goals of the I-D? Is this a
> common understanding of the term Flow Mobility?
> >
> 
> Yes you are right.
> 
> > If this is the case, then I don't understand why the draft is
> introducing text about the LMA creating a different session. Is this
> needed for Flow Mobility? If so, for which scenario?
> >
> > Then, if the MN attaches to MAG2 via If2, there is no reason for the LMA
> to create session 2. The LMA just needs to update session 1 with If2:
> >
> 
> > In this way MAG/LMA/MN can send over IF2 a TCP connection which earlier
> was sent over IF1. This is Flow Mobility.
> >
> 

IMU, the current draft allows different sessions with same prefix, e.g:

Session1: [Pref1, MAG1, IF1, IF2]
Session2: [Pref1, MAG2, IF1, IF2]

Right?

---

From: <[email-masked]>
Date: Wed, 9 Feb 2011 13:29:53 +0100

Hi,

My only concern is on step 8, Please see inline.

Pierrick

> De : Julien Laganier [mailto:[email-masked]]
> Envoyé : mardi 8 février 2011 23:19
> À : SEITE Pierrick RD-RESA-REN
> Cc : [email-masked]; [email-masked]; [email-masked];
> [email-masked]

But the MN is already attached to MAG1 via If1. So, without being too 3GPP specific, what kind of L2 triggers can be used?

To be more generic, I think that, for this case (attach a working interface to a new session), we could have LMA/MAG signalling, maybe as an option? The use-case I have in mind is a short-term deployment of PMIP IP flow mobility over WiFi and 3GPP networks. Because, it is a short term deployment, I have to use legacy 3G network (i.e. without LTE or inter-systems mobility mechanisms); so the 3G network must be agnostic of PMIP support and I can't rely on L2 to trigger PMIP.

> > MAG2 receives prefixes 1 and 2 in PBA but MAG1 is not sending PBU. So,
> if the LMA wants to move flow with Pref2 from if2 to If1, the LMA needs to
> how
> >> From the viewpoint of protocol, I think that at least, prefix addition
> to
> >> an

---

From: "MELIA, TELEMACO (TELEMACO)" <[email-masked]>
Date: Wed, 9 Feb 2011 16:17:41 +0100

But why we cannot design a model where we can dynamically group sessions?
Mobile operators have been fighting hard in the past years the disconnection between ARPU and associated cost per users (in other words costs increase but revenues continue to fall). Data explosion is one of the reasons for such disconnection.
I believe that network operators would be eager to learn about innovating technologies to reduce costs expenditures. The work we are pushing with this ID falls exactly in this category. Restricting to the legacy PMIPv6 model is a limitation.

I would be glad to hear opinions from other (different) voices.

telemaco

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Julien Laganier
Envoyé : mercredi 9 février 2011 03:20
À : [email-masked]
Cc : [email-masked]; [email-masked]
Objet : Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc

Hi Carlos,

--julien

--julien

---

From: "MELIA, TELEMACO (TELEMACO)" <[email-masked]>
Date: Wed, 9 Feb 2011 16:35:14 +0100

Why? If the terminal is connected and radio coverage is ok it also means it is ready to receive traffic on any of the interfaces right? Up the LMA to route flows.

telemaco

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Julien Laganier
Envoyé : mercredi 9 février 2011 03:54
À : Tran Minh Trung
Cc : [email-masked]; [email-masked]
Objet : Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 09 Feb 2011 08:19:54 -0800

I do not believe we are chartered to make fundamental model changes. We are
not departing from RFC-5213, in how sessions are established, the functional
role of the MAG, the proxy model, or any basic changes. If the functional
requirement is about enabling LMA to detect a policy change and to force
that change in the sessions, we need to discuss about that trigger. If that
trigger is from LMA, or an L2 event is one discussion point. But, eventually
that trigger should allow a MAG to send a PBU and that should allow the LMA
to update the BCE states and return the hosted prefixes in the PBA. Lets not
discuss about "legacy PMIPv6", and that we are defining a new protocol. I've
not heard such comments during chartering of this work and I believe we do
need such fundamental changes to solve this flow mobility problem.

Sri

On 2/9/11 7:17 AM, "MELIA, TELEMACO (TELEMACO)"
<[email-masked]> wrote:

> Mobile operators have been fighting hard in the past years the disconnection
> between ARPU and associated cost per users (in other words costs increase but
> revenues continue to fall). Data explosion is one of the reasons for such
> disconnection.
> I believe that network operators would be eager to learn about innovating
> technologies to reduce costs expenditures. The work we are pushing with this
> ID falls exactly in this category. Restricting to the legacy PMIPv6 model is a
> limitation.
> 
> Objet : Re: [netext] Consensus call to adopt I-D:

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 09 Feb 2011 09:15:15 -0800

> following the path that down-link packets received?.

I thought we did, a while back.

> IMHO, both vendors and network operator prefer that way.

I tend to agree.

-Rajeev

>>>>>>> if the LMA wants to move flow with Pref2 from if2 to If1, the LMA needs
>>>>>>> sessions with already up interfaces, e.g. if1 and if2. To address both
>>>>>>> issues, PBU from MAG1 could be triggered (triggering is to be clarified)
>>>>>>> or we could define LMA/MAG specific L3 signalling (FMI/FMA).
>>>>>>> 
>>>>>>> My 2 cents,
>>>>>>> Pierrick
>>>>>>>

---

From: "Stefano Faccin" <[email-masked]>
Date: Wed, 9 Feb 2011 11:08:12 -0600

Telemaco,
All that you say is good, apart from one detail. I do not believe that here in IETF we should be talking about ARPU and costs and so on. We are just not capable of evaluating them. If indeed as you say this solution were the magic answer to operator issues, I am sure operators in 3GPP would have shown a bigger interest in it. My previous question on whether we have an open and declared customer for this solution (i.e. that clearly stated this is needed) is still unanswered, so perhaps there isn't indeed such an interest in this magic 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; www.blackberry.com 

 Consider the environment before printing.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of MELIA, TELEMACO (TELEMACO)
Sent: Wednesday, February 09, 2011 7:18 AM
To: Julien Laganier; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc

telemaco

-----Message d'origine-----

Hi Carlos,

--julien

--julien

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 09 Feb 2011 09:31:29 -0800

We can argue about what is "general case" and what is not. IMO, it's not for
us to decide, let the marketplace make that call.

As protocol designers, I would like to ensure that we provide the necessary
tools to address the problems, rather than debate "who wants to play
oracle".

1. I just don't see why anyone should be forced assign all prefixes
proactively. Parsimonious protocol design has its place - LMA should be able
to assign prefixes on-demand, when necessary. And, not clump stuff (all
prefixes) under the guise of legacy RFC 5213 design, which BTW, feel free to
do if you so choose; but just don't make it the only way.

2. FMI is the message to inform the MAG to add a new prefix to BUL, and to
advertise the new prefix in RA, just as it should. FMA is a response to FMI,
saying I got the message with the disposition of the Status code. Simple,
like other stuff we have in Netext, e.g., Localized Routing. This will do
the job for the case. Why do I need PBU/PBA again? Other than to
(wastefully) satisfy some vague "PMIP6 model", I don't see anything else.
This is not protocol design, it's continued adherence to bad design
decisions.

-Rajeev

On 2/8/11 7:13 PM, "Tran Minh Trung" <[email-masked]> wrote:

>>>>> Rewriting

---

From: "Stefano Faccin" <[email-masked]>
Date: Wed, 9 Feb 2011 11:14:06 -0600

Telemaco,
At the risk of sounding awfully repetitive, I must disagree on the " it is ready to receive traffic on any of the interfaces right". Especially because you are implying "any traffic". Once again, the current solution does not support the scenarios currently supported in 3GPP were the decision on IP flow routing can be based on the specific access network (e.g. SSID) wrt access technology. I still have not heard an answer on why we think it would be worth proposing a solution that gives less functionality than what is out there and does not meet real use case scenarios like the ones I described before. I also have not heard anybody demonstrating me that the use cases I raised are real and very current. 

Cheers,

Stefano Faccin

Standards Manager

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of MELIA, TELEMACO (TELEMACO)
Sent: Wednesday, February 09, 2011 7:35 AM
To: Julien Laganier; Tran Minh Trung
Cc: [email-masked]; [email-masked]
Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc

telemaco

-----Message d'origine-----

--julien

---

From: <[email-masked]>
Date: Wed, 9 Feb 2011 17:19:14 +0000

Stefano,

Lets not talk about ARPU or other aspects of operator issues which are IMO
not really helping this discussion.

But regarding the question of whether there is an open and declared
customer, I don’t know if the WG really needs to answer that.
The point is that we have defined a network based mobility protocol
(RFC5213) in the IETF. There is a community of people in the WG which
believes that extending the protocol to support flow mobility will address
some scenarios and use cases. The applicability  of such a feature in 3GPP
architectures is to some extent open.
I think we should be doing the work and specifying the solution.
Understanding the use cases for the feature is good. But I think we do not
have to go overboard in terms of verifying the customer existence or
interest.

-Raj

On 2/9/11 11:08 AM, "ext Stefano Faccin" <[email-masked]> wrote:

>Telemaco,
>All that you say is good, apart from one detail. I do not believe that
>here in IETF we should be talking about ARPU and costs and so on. We are
>just not capable of evaluating them. If indeed as you say this solution
>were the magic answer to operator issues, I am sure operators in 3GPP
>would have shown a bigger interest in it. My previous question on whether
>we have an open and declared customer for this solution (i.e. that
>clearly stated this is needed) is still unanswered, so perhaps there
>isn't indeed such an interest in this magic solution?
>Cheers,
>Stefano Faccin
>
>Standards Manager
>Of MELIA, TELEMACO (TELEMACO)
>Mobile operators have been fighting hard in the past years the
>disconnection between ARPU and associated cost per users (in other words
>costs increase but revenues continue to fall). Data explosion is one of
>the reasons for such disconnection.
>technologies to reduce costs expenditures. The work we are pushing with
>this ID falls exactly in this category. Restricting to the legacy PMIPv6
>model is a limitation.
>
>de Julien Laganier

---

From: "Stefano Faccin" <[email-masked]>
Date: Wed, 9 Feb 2011 11:22:12 -0600

Raj,
Fine with not talking about ARPU (that's exactly what I said below).

As for the customer, I could live with what you say. However, I believe we need to address use cases that would allow the solution to be usable by a customer that is already adopting an alternative solution. If what Netext produces cannot provide the same service, why would a customer have any interest in adopting t? To provide less service to the MNs?

Cheers, 

Stefano Faccin

Standards Manager

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, February 09, 2011 9:19 AM
To: Stefano Faccin; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [netext] Consensus call to adopt I-D: draft-bernardos-netext-pmipv6-flowmob as WG doc

Stefano,

-Raj

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Wed, 9 Feb 2011 12:44:23 -0500

+1

I support the idea from Pierrick and Raj to stop going in circles with religious arguments and concentrate on the solution at hand, which responds to what the WG is chartered to do.

> Behalf Of [email-masked]
> Sent: February 9, 2011 12:19 PM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Cc: [email-masked]

---

From: "MELIA, TELEMACO (TELEMACO)" <[email-masked]>
Date: Wed, 9 Feb 2011 18:53:08 +0100

Stefano,

At the risk of sounding extremely repetitive I believe the authors at different stages did answer the questions posed from the audience. To void endless discussions I'd leave the chairs to cut the line...

telemaco

-----Message d'origine-----
De : Stefano Faccin [mailto:[email-masked]] 
Envoyé : mercredi 9 février 2011 18:14
À : MELIA, TELEMACO (TELEMACO); Julien Laganier; Tran Minh Trung
Cc : [email-masked]; [email-masked]
Objet : RE: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc

Telemaco,

Cheers,

Stefano Faccin

Standards Manager

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of MELIA, TELEMACO (TELEMACO)
Sent: Wednesday, February 09, 2011 7:35 AM
To: Julien Laganier; Tran Minh Trung
Cc: [email-masked]; [email-masked]
Subject: Re: [netext] Consensus call to adopt I-D:draft-bernardos-netext-pmipv6-flowmob as WG doc

telemaco

-----Message d'origine-----

--julien

---

From: Julien Laganier <[email-masked]>
Date: Wed, 9 Feb 2011 10:07:29 -0800

Pierrick:

> Session2: [Pref1, MAG2, IF1, IF2]

In the nominal RFC 5213 model, a PMIPv6 session is defined as a prefix
set, a MAG where the MN is attached, and an interface used by the MN
to attach (i.e., ATT and LLID.)

 Session1: [{Pref_11,..., Pref_1p}, (MAG1, IF1)]
 Session2: [{Pref_21,..., Pref_2q}, (MAG2, IF2)]

In flow mobility extension, I am proposing that we generalize this
definition to allow for multiple attachment, as it's IMO the only
_required_ extension to support flow mobility:

 Session1: [{Pref_11,..., Pref_1p}, {(MAG1, IF1), (MAG2, IF2)}]
 Session2: [{Pref_21,..., Pref_2q}, {(MAG2, IF2)}]

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 09 Feb 2011 10:11:42 -0800

We want the LMA to dynamically add prefixes, pick a prefix based on the hour
of the day, or based on the weather, create sessions unilaterally and also
reboot the MN at its mercy. We can assume the LMA some how knows and is in
communication with the oracle that has all the interfaces in place from the
radio network, and has all the needed heuristics in place which tells as
when to make all the state changes. Sure, we can define any thing we want,
but we cannot completely ignore the target system architecture. Each
requirement has to have some meaningful use-case with general consensus to
do that work and the charter has to reflect that.

To support this wish list, we can assume the mobile node has all the needed
framework in place. It can mirror flows, it knows when to switch flows, it
has an understanding of the completion of the network side signaling. Still
its a simple mobile node, unmodified, but it is DPI enabled, which tracks
what flows are coming what interfaces, so it can mirror. Who is building
this UE ?

We don't have to be restricted with the RFC-5213 signaling. If its needed or
not, we should define a new signaling plane. One message interface from LMA
to MAG and the other from MAG to LMA. We will define new sets of messages,
new options, new number space and the MAG implementations will have two sets
of timers and an advanced state machine. All of this to support a remote
case of policy change. This is an impact to the implementations.

We can do all of this, but before we make fundamental changes to the
protocol that was discussed for over a period of two years and with
industry-wide participation, we cannot allow it be undone in WG which has
(7) people participation, with a single tone enforcing decisions, with
unilateral wish list, backed by no framework that supports such requirements
in any target system architecture.

Finally, if we are talking about fundamental changes to the signaling model,
it should be reflected in the charter. The AD needs to approve. As many
pointed out, all the basic flow mobility functional requirements can be met,
without "updating the legacy 5213 model". If the goal is to update that
legacy model, we should start with a new protocol.

Sri

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 09 Feb 2011 20:31:41 +0100

Hi Sri,

> Both cases ? Do you agree, a simple FMI trigger is sufficient ?

Both cases meaning trigger from MAG in PBU or LMA-initiated FMI/FMA.
Whether its FMI/FMA or FMI/PBU/PBA is a very minor detail in this
discussion (at this stage)

Carlos

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 09 Feb 2011 11:40:12 -0800

Hi Carlos:

> discussion (at this stage)

Sure. The need for the trigger is the first issue to be resolved.

Sri

---

From: Julien Laganier <[email-masked]>
Date: Wed, 9 Feb 2011 11:39:49 -0800

Sri:

Well said. I couldn't agree more.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Wed, 9 Feb 2011 11:44:20 -0800

Telemaco:

> We need to cover both cases.

If we're about to do exegesis on our charter, let's get it done right.

Exactly Not: The charter says sequentially or simulateously w.r.t.
attachment, to cover the case of inter-technology handoffs (MN
attaching to network with one interface instead of another, sequential
attachment) and flow mobility (MN attaching simultaneously with more
than one interface.)

--julien

---

From: Julien Laganier <[email-masked]>
Date: Wed, 9 Feb 2011 11:50:36 -0800

Hi Pierrick,

Please see my anwer inline below:

> But the MN is already attached to MAG1 via If1. So, without being too 3GPP specific, what kind of L2 triggers can be used?

Being 3GPP specific: Additional PDN Connectivity Request.

Without being 3GPP specific, a L2 trigger requesting creation of an
additional session.

> To be more generic, I think that, for this case (attach a working interface to a new session), we could have LMA/MAG signalling, maybe as an option? The use-case I have in mind is a short-term depl…

If you have no L2 trigger you cannot even use RFC5213 PMIP as the MAG
has no way to detect a MN attached and initiate PBU towards LMA.

If your "3G network must be agnostic of PMIP support", PMIP is a no
go. (you could use MIPv6, it works well over an unmodified 3G network
as it is a full overlay.)

--julien

---

From: Julien Laganier <[email-masked]>
Date: Wed, 9 Feb 2011 11:58:52 -0800

Telemaco,

> I would be glad to hear opinions from other (different) voices.

It could indeed be interesting to hear from network operators that are
eager to learn about innovating technologies to reduce costs
expenditures :-)

I however don't understand what is the relation between an
hypothetical eagerness to learn about innovating technologies to
reduce costs expenditures on one hand, and the design of a flow
mobility extension for PMIPv6 on the other hand. Neither with ARPU,
revenue, and data explosion.

Can we stay focused on technical discussions that in-scope for this ML please?

--julien

---

From: Julien Laganier <[email-masked]>
Date: Wed, 9 Feb 2011 12:05:25 -0800

Telemaco:

You prove my point. To your "Why?", I answer -- Because:

Q: How does the LMA knows the terminal is connected?
A: Because the MAG sent a PBU based on an L2 trigger.

Q: How does the LMA knows coverage is OK?
A: It has no clue. WiFi could be terrible and the MN still attached to it.

Q: How does the LMA know the terminal is ready to receive traffic on
any interfaces?
A: It doesn't know, unless all prefixes of the prefix set associated
to a session are made available through all of the interface. Which is
incidentally exactly the model I am advocating for since the beginning
of this discussion on the basis that it is the only thing needed for
flow mobility.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Wed, 9 Feb 2011 12:11:57 -0800

> I thought we did, a while back.

I don't think we did agree on this. To start with there are a number
of situations where the logical interfaces can match uplink packets
with downlink packets from a same flow.

>> IMHO, both vendors and network operator prefer that way.

It's all nice to hear your guys opinion on what operators preferences
are but that is pretty useless in this discussion unless said operator
speak up for themselves.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Wed, 9 Feb 2011 12:13:39 -0800

Raj,

I'd go a bit further than you did below and say that IMHO
"Understanding the use cases for the feature is a requirement."

--julien

---

From: Julien Laganier <[email-masked]>
Date: Wed, 9 Feb 2011 12:15:47 -0800

Juan-Carlos -

I am a bit puzzled by your statement below. Which arguments in this
discussion do you consider as religious?

Thanks,

--julien

---

From: Julien Laganier <[email-masked]>
Date: Wed, 9 Feb 2011 12:25:30 -0800

Telemaco,

At the risk of sounding extremely repetitive too :)

I believe I have not obtained satisfactory answers to my question on
why is the usecase that necessitates addition of prefixes to sessions
is of any relevance in the completing a work item for the flow
mobility deliverable. I have also see other people questioning other
aspects of the usecase.

On the other hand, I've been offering an extension to the PMIPv6
session model that is minimal yet provides the feature of moving flow
between accesses. And there again there was no convincing rebuttal
other than the fact that it doesn't solve the usecase that we don't
know why it is important, except a bunch of individuals insist that
they want it.

IMHO, "cutting the line" and "void[ing] endless discussions" won't
help to resolve the above two issues I have.

Answering them would, FWIW.

--julien

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 09 Feb 2011 12:51:03 -0800

Hi,

I am beginning to think I must be really missing something..
Or, this is turning out to be running in circles.

General comment: 3GPP is good source of input, we should use it. However, if
something is not there in 3GPP today, that cannot be held against proposals
here. 

> when* I you need a PDN connection.

No.
You assign the prefix relevant for that interface. On if0, p0. On if1, p1. I
am saying that I am not required to assign p0 to if1 at attach. I will
provide p0 if I need to, when I need to, using IP signaling this group
capable of producing.

> If you have another target system than 3GPP, what is it?

See above comment.

> mobility across multiple interfaces.

So, how can I move a flow belonging to p0 onto if1 without the LMA first
informing the MAG? I don't want any L2 hand-waving. I have an eerie feeling
that I have asked this more than I should..sigh.

> 2) I want to assign a prefix based on policy triggers, including the TOD
rules.
> I said above, you can already move flows with a single prefix when the

If I want to move flows, I need to ensure that the corresponding prefix is
valid on the target interface. That's the extent of "assigning" prefixes
on-demand. See also Youn-Hee's e-mail earlier.

I don't have anything else to say on this.

Thanks,

-Rajeev

> 
>> I want to move certain type of traffic

---

From: Julien Laganier <[email-masked]>
Date: Wed, 9 Feb 2011 12:42:39 -0800

Hi Rajeev,

> Or, this is turning out to be running in circles.

FWIW the feeling is shared.

> something is not there in 3GPP today, that cannot be held against proposals

I've been using 3GPP as example of usecase because it is real and out
there. I am happy to hear about any usecase that necessitates the sort
of features you've been advocating.

> provide p0 if I need to, when I need to, using IP signaling this group

You are starting my making up a requirement on how you assign prefixes
to interface which has nothing to do with the feature of providing
flow mobility.

Once you have allocated p0 to the _MN_, and p1 to the _MN_ the cost of
having those avalaible on all interfaces of a session (if0 and if1) is
the same as having them segregated on if0 and if1.

The segregation of prefixes to interfaces is also not useful in terms
of providing flow mobility -- one can do flow mobility with both p0
and p1 being available to interfaces of the session, if0 and if1.

So what is it that justifies this requirement, in the context of
extending PMIP to support flow mobility?

[...]
> that I have asked this more than I should..sigh.

See above. Prefixes don't need to be segregated to interfaces. They
only be need to segregated to sessions.

> on-demand. See also Youn-Hee's e-mail earlier.

No you don't need to ensure that the corresponding prefix is valid on
the target interface. Why would you?!

> I don't have anything else to say on this.

I do: Please answer my questions.

--julien

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Wed, 9 Feb 2011 22:23:35 +0000

Hi,

Please see inline

> From: Tran Minh Trung [mailto:[email-masked]]
> Sent: Wednesday, February 09, 2011 12:46 AM
> To: Giaretta, Gerardo
> Cc: [email-masked]
> Subject: Re: [netext] Multiple prefixes in draft-bernardos-netext-
> pmipv6-flowmob
> 
> session are sent over one interface and some others over another
> interface. This is equivalent to the RFC6089: IP flows which are tied
> to the same HoA/HNP can be sent over one CoA/BID or another CoA/BID.
> >

Good at least we agree on the definition.

> > Then, if the MN attaches to MAG2 via If2, there is no reason for the
> LMA to create session 2. The LMA just needs to update session 1 with
> If2:
> >
> 

RFC5213 does not assign a NEW prefix but A prefix when there is an attachment. If there is the handover indication in the PBU for example the same prefix is attached. Given that flow mobility is a particular type of handover, there is no need to assign a new prefix for flow mobility purposes.

> > In this way MAG/LMA/MN can send over IF2 a TCP connection which
> earlier was sent over IF1. This is Flow Mobility.
> >
> 

Flow mobility is not about creating new sessions based on the definition you just agreed. 

Gerardo

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Wed, 9 Feb 2011 22:29:25 +0000

I don't understand what this has to do with flow mobility

Gerardo 

> Behalf Of Rajeev Koodli
> Sent: Wednesday, February 09, 2011 9:31 AM
> To: Tran Minh Trung; Sri Gundavelli
> >>> On Wed, Feb 9, 2011 at 7:18 AM, Julien Laganier
> <[email-masked]>
> >>> wrote:
> >>>> Hi Pierrick,
> >>>>
> not
> result,
> la part
> >>>>>> Objet : Re: [netext] Consensus call to adopt I-D:draft-
> bernardos-netext-
> >>>>>> pmipv6-flowmob as WG doc
> >>>>>>
> >>>>>> Hi Julien,
> >>>>>>
> in
> >>>>>> netext
> >>>>>> WG prior to discuss flow mobility management. As the definition
> of "a
> >>>>>> flow",
> >>>>>> with you that in real-world (3GPP), there may be no need to
> assign
> >>>>>> multiple
> >>>>>> prefixes into an MN. (if somebody knows its necessity, please
> tell me
> >>>>>> when
> >>>>>> advertises. Therefore, sometimes, we need prefix addition to
> move a flow
> >>>>>> to
> >>>>>> a new interface of which MAG does not yet advertise the prefix
> of the
> >>>>>> flow
> >>>>>> being moved.
> >>>>>>
> >>>>>> (snip...)
> >>>>>>
> >>>>>> draft allows too much space regarding the prefix allocation
> model
> >>>>>> (unique,
> >>>>>> shared, and hybrid). When a flow should be moved to a new
> interface and
> >>>>>> the
> flow.
> >>>>>> This
> >>>>>> above. But, it does not mean prefix addition should happen
> always
> >>>>>> whenever

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Wed, 9 Feb 2011 22:33:18 +0000

Solution focuses on assigning multiple prefixes on demand based on some magic knowledge of the LMA and this has nothing to do with the WG is chartered to do.

Also, I don't like that everytime there are comments on PMIP there are people claiming the comments are not technical but religious. I have read many technical comments from people from different companies in this thread

Gerardo 

> Behalf Of Zuniga, Juan Carlos
> Sent: Wednesday, February 09, 2011 9:44 AM
> To: [email-masked]; [email-masked]; telemaco.melia@alcatel-
> lucent.com; [email-masked]; [email-masked]
> Cc: [email-masked]
> I support the idea from Pierrick and Raj to stop going in circles with
> religious arguments and concentrate on the solution at hand, which
> responds to what the WG is chartered to do.
> 
> 
> > Lets not talk about ARPU or other aspects of operator issues which
> are
> > IMO
> > Understanding the use cases for the feature is good. But I think we
> do
> > not
> > >>> So you need layer 2. And that is actually exactly how netext
> could
> > get
> > >> to do at layer 3, _but_ not to do things that we don't need to do
> at
> > the
> > >> complex layer 2 triggers/policies to be in place and it's
> therefore
> > more

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Wed, 9 Feb 2011 22:36:15 +0000

> Behalf Of Julien Laganier
> Sent: Wednesday, February 09, 2011 11:51 AM
> To: [email-masked]
> > But the MN is already attached to MAG1 via If1. So, without being too
> 3GPP specific, what kind of L2 triggers can be used?
> 
> > To be more generic, I think that, for this case (attach a working
> interface to a new session), we could have LMA/MAG signalling, maybe as
> an option? The use-case I have in mind is a short-term deployment of
> PMIP IP flow mobility over WiFi and 3GPP networks. Because, it is a
> short term deployment, I have to use legacy 3G network (i.e. without
> LTE or inter-systems mobility mechanisms); so the 3G network must be
> agnostic of PMIP support and I can't rely on L2 to trigger PMIP.
> 

And it is also RFC and specified by 3GPP Release 8 with the spec being asked by a French operator :-)

Gerardo

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Wed, 9 Feb 2011 23:14:26 +0000

How does the LMA know the channel conditions of each radio? 

How does the LMA know the radio coverage? 

How does the LMA know the application requirements of the apps running in the UE? What happens if an app bind() to a radio? 

How does the LMA know to not move the corresponding flow?

I can add more when I have answers on these fundamental questions.

Gerardo 

> Behalf Of MELIA, TELEMACO (TELEMACO)
> Why? If the terminal is connected and radio coverage is ok it also
> means it is ready to receive traffic on any of the interfaces right? Up
> the LMA to route flows.
> 
> telemaco
> 
> <[email-masked]> wrote:
> >> Hi Pierrick,
> >>
> in netext
> >>>> advertises. Therefore, sometimes, we need prefix addition to move
> a flow
> >>>> to

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 09 Feb 2011 16:08:03 -0800

Hello Folks,

Protocols evolve in IETF, that's just how it goes. It's not a criticism of
the previous design per se. The same goes for PMIPv6 here.

To be very clear, what's being proposed is not to undo something, but add
new functionality, without affecting the baseline functionality.

OTOH, if the claim here is that two years of design could not be worked on
AND 7 people on this list cannot possibly do anything to evolve it, that's
news to me, in IETF.

-Rajeev

On 2/9/11 11:39 AM, "Julien Laganier" <[email-masked]> wrote:

>>>>                                 I want to be able to refresh the lifetime
>>>> of
>>>> that prefix and

---

From: Tran Minh Trung <[email-masked]>
Date: Thu, 10 Feb 2011 09:41:26 +0900

Hi Gerardo,

> RFC5213 does not assign a NEW prefix but A prefix when there is an attachment. If there is the handover indication in the PBU for example the same prefix is attached. Given that flow mobility is a…

RFC5213 do assign a NEW prefix to a NEW attachment if there is an
existing attachment as IF1 in the example (Please check session 5.4.
Multihoming Support)

The necessary extension is that if interfaces are in the same set then
to support flow mobility we should enable them to share sessions.

> Flow mobility is not about creating new sessions based on the definition you just agreed.

New session can be created at any time (due to L2 triggers or policy
profile change as Julien said or network policy is changed as I
mentioned)
We should attach all working interfaces in the set to that new session
to allow flows can be moved across interfaces.

Is that right?

Regards,
TrungTM

---

From: Tran Minh Trung <[email-masked]>
Date: Thu, 10 Feb 2011 10:03:28 +0900

>  Session2: [{Pref_21,..., Pref_2q}, {(MAG2, IF2)}]

The session in current draft is:

Session1: [{Pref_11,..., Pref_1p,Pref_21,..., Pref_2q}, {(MAG1, IF1)}]
Session2: [{Pref_21,..., Pref_2q,Pref_11,..., Pref_1p}, {(MAG2, IF2)}]

Julien adds interface, while we add prefix(es) to session.
Both of them has the same function is to allow prefix(es) to be shared
across interface.

Should we waste time to debate on it to select one?

Regards,
TrungTM

---

From: Julien Laganier <[email-masked]>
Date: Wed, 9 Feb 2011 17:12:35 -0800

> existing attachment as IF1 in the example (Please check session 5.4.

It only does so to the extent that the MAG does not know if the MN
supports inter-interface handover, and that was for the sake of
avoinding breaking IP connectivity on such hosts.

If the host does supports inter-interface handover, MAG sets
corresponding HI value, and SAME prefix is used for NEW attachment.

Following these same guidelines, if the host supports logical
interface for flow mobility, MAG sets corresdponding HI value (attach
interface to flow mobility session), and SAME prefix is used for NEW
attachment.

> to support flow mobility we should enable them to share sessions.

The necessary extension is simply a new HI value to attach an
interface to a session, and a new HI value to detach an interface to a
session.

Nothing complicated.

--julien

---

From: Tran Minh Trung <[email-masked]>
Date: Thu, 10 Feb 2011 11:13:16 +0900

> corresponding HI value, and SAME prefix is used for NEW attachment.

I just want to emphasize here is that RFC5213 dose not support that.
We need to extend it as your suggestion.

> interface to a session, and a new HI value to detach an interface to a

Julien, I think your solution and the solution in the draft have the
same function and result.

No big different. Both of them are Ok.
Let me analyze it again as following:

1. Your solution: Adding interface to session

2. Solution in current draft: Adding prefix to session

Both of them have the same function is to allow prefix(es) to be shared
across interface.

Is that right?

Now, if IF1 detaches from network.
Your solution removes IF from session 1 while or solution remove session 1.
Other flows on IF2 are kept continue.

That's all, they have same function and result. There is no big different!.

Hope we can agree on this and save our time :-).

Regards,
TrungTM

---

From: Julien Laganier <[email-masked]>
Date: Wed, 9 Feb 2011 18:31:24 -0800

Tran,

On Wed, Feb 9, 2011 at 6:13 PM, Tran Minh Trung <[email-masked]> wrote:
>>> On Thu, Feb 10, 2011 at 7:23 AM, Giaretta, Gerardo wrote:
>>>> Tran Minh Trung wrote
>>>>>

Right. And that is exactly what I've been repeating over and over...

No.

My solution allows flow mobility at the cost of two new HI values.

The solution in the draft allows flow mobility plus a bunch of other
things that have nothing to do with flow mobility, at the cost of new
messages, new state machines etc.

> Both of them have the same function is to allow prefix(es) to be shared

I would say #1 allows flow mobility by sharing sessions (and
corresponding prefix set) across interfaces, while #2 allows for
things that unrelated to flow mobility at the cost of added
complexity.

Let me now follow the KISS principle: Keep It Simple, Stupid!

Then I pick #1. There are no good reasons to go for #2 unless a clear
case is made why #1 is required. Note: You can't say we need different
prefixes on different interfaces and therefore flow mobility needs to
allow different prefix on different interfaces. It's not even
tautologic!

> That's all, they have same function and result. There is no big different!.

The function differs. The result differ. #1 is simple flow mobility,
#2 is flow mobility bloated with something that nobody needs for flow
mobility.

> Hope we can agree on this and save our time :-).

By all means! Hope you will agree with applying KISS principle and pick #1 :-)

--julien

---

From: Tran Minh Trung <[email-masked]>
Date: Thu, 10 Feb 2011 12:03:39 +0900

[Snip.]

> things that unrelated to flow mobility at the cost of added

Can the session defined in #2 support flow mobility?
The answer is clearly Yes.

Now how to do it: We can use HI as your suggestion.

> case is made why #1 is required.

There is a key reason for me to prefer the solution #2.

The RFC5213 maintains separate session for each interface (Please see
5.4.  Multihoming Support, item 1). It dose not maintain one session
for multiple interfaces.

Solution #2 does the same as RFC5213, while solution#1 maintains
session for each set of prefix. It is not original session definition
of RFC5213, right?

However I think solution #1 also Ok since it gives the same result.

>Note: You can't say we need different

What are something that you are refer to?

> By all means! Hope you will agree with applying KISS principle and pick #1 :-)

I like KISS principle also :-).
For me both two session definitions above are ok.
I can see only one point different between your solution and current
draft's solution is signaling between LMA and MAG.

You prefer to use L2 triggers and policy profile update to trigger
MAGs to send PBU message while the current draft prefers to allow LMA
to send trigger to MAG.

The question here is that which one is better and best-match with the
real system.
That's point we need to discuss more, especially the case that network
policy is changed.

Regards,
TrungTM

---

From: Julien Laganier <[email-masked]>
Date: Wed, 9 Feb 2011 22:45:12 -0800

> 5.4.  Multihoming Support, item 1). It dose not maintain one session

RFC 5213 only maintains different session for different interfaces if
the MAG doesn't know if the host supports inter-interface handovers
and thus doesn't set the HI indicator to "handoff between different
interfaces." If the MAG knows that the host supports inter-interface
handovers, it sets the HI indicator to "handoff between different
interfaces." and the same session is changed from one interface to
another.

> session for each set of prefix. It is not original session definition

Solution #2 artificially generalizes the case where RFC 5213 MAG
doesn't know if the host supports inter-interface handovers to the
flow mobility case where we know that the host supports
inter-interface handovers since it has the logical interface! This
doesn't make sense.

> However I think solution #1 also Ok since it gives the same result.

So you agree #1 is Ok.

> What are something that you are refer to?

Artificially binds prefixes to interfaces, thus introducing the need
to update the prefix-interface mapping. This is not needed for flow
mobility, as proven by the fact that solution #1 works ok without
binding prefixes to interfaces.

> MAGs to send PBU message while the current draft prefers to allow LMA

L2 triggers are needed anyway for PMIP thus it makes no sense to try
to do without them.

> The question here is that which one is better and best-match with the

The only real system I know is 3GPP and it has L2 triggers. Otherwise
PMIP doesn't work.

> That's point we need to discuss more, especially the case that network

I think everything has been said on why #2 brings nothing more than
#1, including the case where network policy is changed.

--julien

---

From: Tran Minh Trung <[email-masked]>
Date: Thu, 10 Feb 2011 17:07:38 +0900

> inter-interface handovers since it has the logical interface! This

Ok I agree. If the network knows that the MN can support
inter-interface handovers then multiple interfaces can be managed by a
session.

> The only real system I know is 3GPP and it has L2 triggers. Otherwise

I agree. One more thing is that in 3GPP when the network policy change
the ANDSF can send SMS to UE to
update policy to UE (MN) via S14 interface using push model.

> #1, including the case where network policy is changed.

Julien, I think we are almost on the same page now :-)
Thank you for your discussion.

Regards,
TrungTM

---

From: <[email-masked]>
Date: Thu, 10 Feb 2011 09:41:25 +0100

> Envoyé : mercredi 9 février 2011 19:07
> Cc : [email-masked]; [email-masked]; [email-masked]
> >> On Wed, Feb 9, 2011 at 3:33 PM, Giaretta, Gerardo
> <[email-masked]>
> >> wrote:
> >> > Hi all,
> >> >
> interface.
> LMA
> earlier

Agreed

---

From: <[email-masked]>
Date: Thu, 10 Feb 2011 09:50:45 +0100

Hi,

> Envoyé : mercredi 9 février 2011 20:51
> interface to a new session), we could have LMA/MAG signalling, maybe as an
> option? The use-case I have in mind is a short-term deployment of PMIP IP
> flow mobility over WiFi and 3GPP networks. Because, it is a short term
> deployment, I have to use legacy 3G network (i.e. without LTE or inter-
> systems mobility mechanisms); so the 3G network must be agnostic of PMIP
> support and I can't rely on L2 to trigger PMIP.
> 

Actually, we can't leverage on 3GPP L2 specific trigger but, of course, we still have RS/RA between MAG and MN.

---

From: Julien Laganier <[email-masked]>
Date: Thu, 10 Feb 2011 07:21:12 -0800

Tran,

Thanks for the discussion as well. Glad I could eventually convey my
point to you.

Best,

--julien

---

From: Julien Laganier <[email-masked]>
Date: Thu, 10 Feb 2011 07:36:27 -0800

> Actually, we can't leverage on 3GPP L2 specific trigger but, of course, we still have RS/RA between MAG and MN.

Agree you can't list specific 3GPP triggers, except maybe as example
of what L2 triggers could be (might be a good idea actually.) On the
other hand you can actually leverage on *generic*  L2 triggers, just
explain what they are. I believe we only need two: "MN attaches
interfaces to session" , and " MN detaches interface from session."
There used to be an MN-AR interface drafts that listed the triggers
used by RFC 5213, but in the end it was abandoned as RFC 5213 did a
good job at describing the L2 triggers it relied on, i.e., attach, and
detach, see quotes below:

   1.   After detecting a new mobile node on its access link, the mobile
        access gateway MUST identify the mobile node and acquire its MN-
        Identifier.

[...]

   The specific detection mechanism of the loss of a visiting mobile
   node on the connected link is specific to the access link between the
   mobile node and the mobile access gateway and is outside the scope of
   this document.  Typically, there are various link-layer-specific
   events specific to each access technology that the mobile access
   gateway can depend on for detecting the node loss.  In general, the
   mobile access gateway can depend on one or more of the following
   methods for the detection presence of the mobile node on the
   connected link:

   o  Link-layer event specific to the access technology

   o  Session termination event on point-to-point link types

   o  IPv6 Neighbor Unreachability Detection event from IPv6 stack

   o  Notification event from the local mobility anchor

[...]

   When a mobile node enters a Proxy Mobile IPv6 domain and attaches to
   an access network, the mobile access gateway on the access link
   detects the attachment of the mobile node and completes the binding
   registration with the mobile node's local mobility anchor.

RS seems not like a good trigger because it does not give the MAG the
session information, the MNID, etc.

--julien

---

From: Tran Minh Trung <[email-masked]>
Date: Fri, 11 Feb 2011 10:21:58 +0900

[Snip.]
> interfaces to session" , and " MN detaches interface from session."

IMO, It would be better to say that:
MN attaches to/detaches from MAGs. MAGs attach/detach MN's attachments
to/from session.

Regards,
TrungTM

---

From: Hesham Soliman <[email-masked]>
Date: Sun, 13 Feb 2011 02:08:19 +1100

Yes but another piece of news about IETF is that you need to respond to
technical discussions. You are not responding to the key points raised by
Julien in his last email. I've been silently following this "debate" and
it's frustrating to see people talking past each other.

Hesham