Subject: [netext] Scope of Prefixes in Flow Mobility

From: Rajeev Koodli <[email-masked]>
Date: Tue, 03 Aug 2010 10:37:08 -0700

Hello Carlos, All, 

We had some good discussion on the prefix model for the flow mobility work.
I have tried to capture the scenarios in the following text. Let¹s work
towards incorporating this into the draft.

X. Prefix Model

Flow mobility assumes simultaneous access to more than one network, in
a contrast to a typical handover where connectivity to a physical
medium is relinquished, and is re-established with another.
There are multiple prefix models under which a flow mobility protocol needs
to work:

1. At the time of a new attachment, the MN obtains a new prefix or a
new set of prefixes. This is the default behavior with RFC 5213.

2. At the time of a new attachment, the MN obtains the same prefix or
the same set of prefixes as already assigned to an existing
session.  This is not the default behavior in RFC 5213, and the LMA
needs to be able to provide the same assignment even for the
simultaneous attachment (as opposed to the handover scenario only).

3. At the time of a new attachment, the MN obtains a combination of
prefix(es) in use and new prefix(es). This is a hybrid of the above
two scenarios. The local policy determines whether the new prefix is
exclusive to the new attachment or it can be assigned to an existing
attachment as well.

Among the above, scenario 2 needs extensions to RFC 5213 signaling at
the time of a new attachment. Subsequently, no further signaling may
be necessary between the LMA and the MAG. The scenario 1 requires
flow mobility signaling whenever the LMA determines the need for
relocating flows between the different attachments. The scenario 3
requires flow mobility signaling whenever the LMA
determines the need for relocating flows for the new prefix(es) which are
not shared across attachments.
In all the scenarios, a prefix has to  be valid on the
concerned MAGs in order for flow mobility to work. Furthermore, each
MAG MUST advertise to the MN the all the prefixes received from the LMA.

---

From: Tran Minh Trung <[email-masked]>
Date: Wed, 4 Aug 2010 15:38:26 +0900

Dear Rajeev,

Should we assume that the LMA is aware of the logical interface at the MN?.
If not, how LMA can differentiate which physical interfaces are hidden
by the same logical interface?
If LMA can not recognize which physical interfaces are hidden by the
same logical interface then it is impossible to assign prefix(es)
exactly to different attachments.

In case we assume that the LMA is aware of the logical interface at
the MN, then it is easy to enable LMA to assign the same prefix(es) to
all attachments of the logical interface.

Thank you very much for making it more clear.
Regards,
TrungTM

On Wed, Aug 4, 2010 at 2:37 AM, Rajeev Koodli <[email-masked]> wrote:
> I have tried to capture the scenarios in the following text. Let’s work
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext
>
>

-- 
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: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 04 Aug 2010 14:58:17 +0200

Hi,

I think the LMA should know if the MN supports the logical interface
(how it finds out, it is out of the scope, can be on the user profile).
For those MNs that support the logical interface, the LMA can group the
interfaces that belong to the same logical interface by just grouping
all the interfaces that share the same MN-ID (and possible, depending on
what the logical interface document specifies, same LL-ID). I don't
think we need more than this.

Thanks,

Carlos

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

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 04 Aug 2010 15:02:35 +0200

Hi Rajeev,

Some comments below...

On Tue, 2010-08-03 at 10:37 -0700, Rajeev Koodli wrote:
> 
> Hello Carlos, All, 
> 
> We had some good discussion on the prefix model for the flow mobility
> work. I have tried to capture the scenarios in the following text.
> Let’s work towards incorporating this into the draft. 
> 
> 
> X. Prefix Model
> 
> There are multiple prefix models under which a flow mobility protocol
> needs to work:
> 
> determines the need for relocating flows for the new prefix(es) which
> are not shared across attachments.

Agree. Regarding this LMA-MAG signalling (when required), do we really
need to signal the whole flow filter to the MAG or we just need to let
the MAG know about the MN's prefixes that are also reachable on that
interface? Current draft follows the former approach, but I'd like to
discuss if it would be simpler the latter.

> MAG MUST advertise to the MN the all the prefixes received from the

Do we really need to advertise all the prefixes in model 1? I'd say no,
as the logical interface takes care of making all prefixes visible to
the logical interface (regardless of from what physical interface
prefixes are received) and the LMA forwards packets to the right MAG
(which needs to be aware of all the prefixes, via the LMA-MAG
signaling). Comments?

Thanks,

Carlos

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 04 Aug 2010 10:39:55 -0700

Hi,

I am still trying to understand what will not work if we don't make this
assumption..

There are two parts here, which I outlined as 2) & 3) below.

Signaling extension in Binding Update to inform the LMA to support same
prefix assignment. This can be another value assignment for the HI field.
When this value is set, the LMA knows that it can assign the same
prefix(es). This is scenario 2 below.

However, the LMA may choose to assign the same prefix(es) as well as new
prefix(es) if it so chooses based on the ATT field. This would be scenario 3
below. 

So, why do we need to know anything more than this?

Thanks,

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 04 Aug 2010 10:45:20 -0700

> discuss if it would be simpler the latter.

I don't think there is any difference in terms of signaling. The same
message can carry the granularity of a flow filter or a wildcard prefix.
Both formats should be supported IMO.

> (which needs to be aware of all the prefixes, via the LMA-MAG

The logical interface could make the packet available. But, how does
Neighbor Discovery work for the prefix if it is not advertised?

-Rajeev

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 04 Aug 2010 11:00:06 -0700

> discuss if it would be simpler the latter.

We do not have to carry the flow filters, when moving the entire prefix to a
new interface, it can be implicitly conveyed. Mohana's draft covered this
case.

Going back to the basics, in RFC-5213, we specified support for Multihoming
and session handoff between interfaces. The main gap is essentially the
partial flow handoff (allowing the flows associated with a prefix, as a
group to the new interface) and the case of specific flow movement across
interfaces requiring shared prefix model.

Moving flows associated to a common prefix, in the absence of MN-AR triggers
is a cleaner approach, as the RA movement across interfaces provides the
hint. 

The case of specific flow movement, in the absence of triggers is some thing
we need to put more thought on. The approach should ensure it does not
introduce any issues due to split link model. The issues Julien raised in
the WG meeting are valid and we need to address them.

Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 04 Aug 2010 11:06:11 -0700

Hi Tran:

The network should not be aware of the virtual interface configuration on
the host. That is an internal property of the host. From the network point
of view and specifically from the ND perspective, an IP host with the
virtual interface configuration should not be seen as a host with some
special properties.

Regards
Sri

---

From: Tran Minh Trung <[email-masked]>
Date: Thu, 5 Aug 2010 10:52:46 +0900

> think we need more than this.

Carlos: How do you think about the following comments from Sri:

---

From: Tran Minh Trung <[email-masked]>
Date: Thu, 5 Aug 2010 11:09:53 +0900

Hi Rajeev,

Please see my comments inline:

> prefix(es). This is scenario 2 below.

How can we set the value of HI exactly?.  Without signaling from the
MN, I think it is not easy.
Let's assume that we can set the value of HI exactly. Then if the MN
uses 2 logical interfaces to hide two different sub-interface paths,
how can LMA differentiate them by just depending on HI?

> prefix(es) if it so chooses based on the ATT field. This would be scenario 3

I think just ATT is not enough. The MN can be equipped with 2
interfaces using the same ATT and they can be hidden by different
logical interface.

> So, why do we need to know anything more than this?

PS: I can not find the scenario 2,3 that you mentioned. Are they the
scenarios in your previous email?

Regards,
TrungTM

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 04 Aug 2010 19:29:25 -0700

> MN, I think it is not easy.

This is how you handle handovers today in RFC 5213. Somehow the MAG is
supposed to set it to handover. So, what we are doing here is no worse.

> how can LMA differentiate them by just depending on HI?

I am confused. Two logical interfaces?
In general, the LMA cannot make decisions based on whether or not the MN
supports logical interface or how many of those are supported etc..

> interfaces using the same ATT and they can be hidden by different

The LMA has to make prefix assignment based on what is provided in the PBU.
If there are two different interfaces with the same ATT, you don't signal
those two interfaces to the LMA in Binding Update. Besides, it is not clear
why you would assign different prefixes to different interfaces which use
the same ATT.

> scenarios in your previous email?

Yes, it is the proposed text on Prefix Model.

-Rajeev

---

From: Tran Minh Trung <[email-masked]>
Date: Thu, 5 Aug 2010 12:13:59 +0900

> supposed to set it to handover. So, what we are doing here is no worse.

Ok, I see. We can do the same as Handover.
Dose everyone agree that?.
It is somehow the same as we assume that the network aware of the MN
using logical interface.

> supports logical interface or how many of those are supported etc..

For example: The MN is configured with 2 logical interfaces LGI1, LGI2.
The LGI1 hides  IF1, IF2. The  LGI2 hides IF3,IF4.
With this configuration, the flow mobility can be performed only
between IF1 and IF2 or between IF3 and IF4.
Can the LMA be aware of that by using just HI?. If it is not, then how
LMA can know which prefix(es) can be assigned the same to which
attachments of IFs.

For simplicity, we can assume that each MN uses only one LGI to hide
all physical interfaces.
But I wonder whether it is Ok assumption.

> why you would assign different prefixes to different interfaces which use

Please refer to the above example with IF1 and IF3 using the same ATT.

Regards,
TrungTM

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 04 Aug 2010 20:18:59 -0700

>> prefix(es) if it so chooses based on the ATT field. This would be scenario 3

Right. We assume the network provides the handover hints. We do not have the
MN-AR interface at this point. When we were writing the base spec, the MN-AR
interface was factored into the design. Julien was working on this and some
where we lost track of this critical interface.

http://tools.ietf.org/html/draft-ietf-netlmm-mn-ar-if-03

We need to revive this at some point. I was hoping Telemaco/Carlos/Juan
Carlos will revive this in for different SDO architectures, at least that
was our understanding.

http://ietfreport.isoc.org/idref/draft-melia-netext-3gpp-mn-ar-if/

Ideally, the handover hints will come from that interface. If we build this
interface, eventually, the mobile node can express the handover preferences
and flow-path preference. This will allow us to cleanly support the shared
prefix scenario.

Sri

---

From: "MELIA, TELEMACO (TELEMACO)" <[email-masked]>
Date: Thu, 5 Aug 2010 11:09:16 +0200

Hi all,

Let me share few thoughts with you.

I think that the flow mobility feature can be regarded as a service to which mobile customers subscribe.
This can be a flag in  the mobile node's profile (section 6.2 of RFC 5213). I suggest to extend the mandatory fields by adding the flow mobility service.
The LMA will be receiving a PBU with the necessary information and can take the decision on whether to assign multiple prefixes or the same across different access networks. The presence of the flow mobility bit implicitely triggers the extended prefix assignment algorithm.
The LMA will not be aware of the logical interface but knows that the MN can handle flow mobility.

Now, about filters vs. prefix only configured in the MAG for flow mobility. I think we should be flexible and allow both to be transferred to the MAG. This allows the MAG to understand flows if required (else routing is only possible via IP addreses).

telemaco 
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Sri Gundavelli [[email-masked]]
Sent: Thursday, August 05, 2010 5:18 AM
To: Tran Minh Trung
Cc: [email-masked]
Subject: Re: [netext] Scope of Prefixes in Flow Mobility

Sri

---

From: Hidetoshi Yokota <[email-masked]>
Date: Thu, 05 Aug 2010 18:56:34 +0900

Hi Tran and all,

(2010/08/05 12:13), Tran Minh Trung wrote:
> On Thu, Aug 5, 2010 at 11:29 AM, Rajeev Koodli<[email-masked]>  wrote:
>>
>>
>>
>> On 8/4/10 7:09 PM, "Tran Minh Trung"<[email-masked]>  wrote:
>>
>>>>

I agree. This kind of issue has been long discussed and one way is 
out-of-band signaling (supposed to be handled in MN-AR draft) and 
another way is user profile, so to speak. There may be others.

> But I wonder whether it is Ok assumption.

Things are getting complexed... Now, the MN can have multiple logical 
interfaces. If this is the case, just prohibit flow mobility between 
difference logical interfaces such as between IF1 and IF3. This is 
equivalent to non-support of logical interface. This just doesn't work 
and nobody who is rational enough would complain...

Let's try to make it as simple as possible in order to get consensus 
more easily please...
-- 
Hidetoshi

>>>> On 8/3/10 11:38 PM, "Tran Minh Trung"<[email-masked]>  wrote:
>>>>
>>>>> Dear Rajeev,
>>>>>
>>>>> On Wed, Aug 4, 2010 at 2:37 AM, Rajeev Koodli<[email-masked]>  wrote:
>>>>>>
>>>>>> Hello Carlos, All,
>>>>>>

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Thu, 5 Aug 2010 09:39:16 -0400

Sri, Tran Minh,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Sri Gundavelli
> Sent: Wednesday, August 04, 2010 11:19 PM
> To: Tran Minh Trung
> Cc: [email-masked]
> >> However, the LMA may choose to assign the same prefix(es) as well
as
> new

Indeed, the HO or Flow Mobility hints can come from L2 or L2.5 and they
can be sent either to the MAG or even better to the LMA. We have some
text regarding these in
http://tools.ietf.org/html/draft-melia-netext-logical-interface-support-
01, but it still needs to be cleared out.

The next version should provide a better picture of the way the system
should work.

Jc

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Thu, 5 Aug 2010 09:58:33 -0400

Hidetoshi,

> Behalf Of Hidetoshi Yokota
> Sent: Thursday, August 05, 2010 5:57 AM
> To: [email-masked]

I agree 100% with your statement about the usage of the multiple logical interfaces. 
We should include some wording about it in the next revision, just to make sure that rationality prevails ;)

> as new

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Thu, 05 Aug 2010 16:51:32 +0200

> Let's try to make it as simple as possible in order to get consensus 

+1

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Thu, 05 Aug 2010 16:51:49 +0200

> The LMA will not be aware of the logical interface but knows that the MN can handle flow mobility.

Fully agree on this.

Carlos

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 05 Aug 2010 08:35:25 -0700

> The LMA will be receiving a PBU with the necessary information and can take
> the decision on whether to assign multiple prefixes or the same across
> different access networks.

(Couple of slides attached)

The above approach will always will result in a single prefix allocation
across interfaces, which is not desirable. If the feature is active, we
start with one prefix on a interface and start sharing on the other
interface. Couple of points:

1.) For each new interface attachment, always allocate a new prefix, or set
of prefixes, just as in 5213.
2.) However, if the flow policy requires an existing active flow on a
different interface to be relocated to the new interface, the approach of
prefix sharing across interfaces can be considered.

As I said yesterday (please see the attached slides), we have 4 scenarios.
Scenario-1 and Scenario-2 are covered in 5213. Now, we have scenario-3,
moving all the flows associated with a prefix (i.e. Using the source address
from the same prefix) i.e. Mohana's draft, to a new interface. This is
almost like Sceanario-1, we have proper indicators.

The other scenario, which I never liked is scenario-4, requiring shared
prefixes across interfaces. But, scenario-4 and scenario-2 should not be
seen as mutually exclusive. In other words, its not always multihoming vs
prefix sharing, but rather its always multihoming, but some flows that had
to moved to different interface (determined by policy), even if they are
using a prefix from the prev interface, we need to share so those flows can
be relocated. Assuming new flows will pick up the right source
address/interface selection and eventually keeping the prefixes to the
respective interfaces.

Sri

On 8/5/10 2:09 AM, "MELIA, TELEMACO (TELEMACO)"
<[email-masked]> wrote:

> This can be a flag in  the mobile node's profile (section 6.2 of RFC 5213). I
> suggest to extend the mandatory fields by adding the flow mobility service.
> The LMA will be receiving a PBU with the necessary information and can take
> the decision on whether to assign multiple prefixes or the same across
> different access networks. The presence of the flow mobility bit implicitely
> triggers the extended prefix assignment algorithm.
> Now, about filters vs. prefix only configured in the MAG for flow mobility. I
> think we should be flexible and allow both to be transferred to the MAG. This
> allows the MAG to understand flows if required (else routing is only possible
> via IP addreses).
> 
> telemaco 
>>>>> work.
>>>>> needs

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Thu, 05 Aug 2010 17:40:52 +0200

> Carlos: How do you think about the following comments from Sri:

I agree with him. The network (as Telemaco mentioned in another e-mail)
should know that the MN is able to handle flow mobility (i.e. flows
moved from one interface to another). It does not need to know the
specifics of how the MN supports that (logical interface is one way, but
there might be others). This is what I meant when I said that the
network should be aware (we have to avoid the case for what the LMA
start moving flows to a terminal that just simply does not support
that).

Carlos

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Thu, 05 Aug 2010 17:47:39 +0200

Hi Sri,

I've always seen Scenario 3 as a sub-case of scenario 4 (the granularity
is per-prefix, not per 5-tuple flow). Question: for scenario 4: do we
really need the MAGs to advertise all the prefixes to the MN? I think it
is not really required if the MN uses the logical interface concept. The
only requirement is that the MAG knows how to route the prefixes (e.g.,
know that P2 is reachable through the same p2p interface where P1 is
reachable, without really advertising P2 on that interface).

Kind Regards,

Carlos

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 05 Aug 2010 09:06:08 -0700

Hi Carlos:

In the absence of triggers from MN, on flow path preferences, it makes a
world of difference in solution simplicity terms, between the two. We should
support both. 

(Question: for scenario 4:)

Its a good question. The mobile node may bridge all interfaces and may end
up configuring them on the virtual interface, or not. But, from the network
perspective, preserving multihoming properties can handle both the cases
properly.

Sri

---

From: <[email-masked]>
Date: Thu, 5 Aug 2010 18:07:29 +0200

The idea of multiple logical interfaces on a host is a bit strange. I don't
see a good reason for this approach at the present time.

-Raj

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 05 Aug 2010 09:10:56 -0700

Agree !!

>>> Let's try to make it as simple as possible in order to get consensus
netext mailing
> list
[email-masked]

---

From: "MELIA, TELEMACO (TELEMACO)" <[email-masked]>
Date: Fri, 6 Aug 2010 10:09:20 +0200

+ 1

telemaco
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Sri Gundavelli [[email-masked]]
Sent: Thursday, August 05, 2010 6:10 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [netext] Scope of Prefixes in Flow Mobility

Agree !!

netext mailing
[email-masked]

---

From: Yuri Ismailov <[email-masked]>
Date: Fri, 6 Aug 2010 10:13:21 +0200

+10 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of MELIA, TELEMACO (TELEMACO)
Sent: Friday, August 06, 2010 10:09 AM
To: Sri Gundavelli; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [netext] Scope of Prefixes in Flow Mobility

+ 1

telemaco

Agree !!

On 8/5/10 9:07 AM, "[email-masked]" <[email-masked]>
wrote:

>
> The idea of multiple logical interfaces on a host is a bit strange. I 
> don't see a good reason for this approach at the present time.
>
> -Raj
>
>
>>>>>>> Signaling extension in Binding Update to inform the LMA to 
>>>>>>> support
>>> same
>>>>>>> prefix assignment. This can be another value assignment for the 
>>>>>>> HI
>>> field.
>>>>>>> When this value is set, the LMA knows that it can assign the 
>>>>>>> same prefix(es). This is scenario 2 below.
>>>>>>>
>>>>>>
>>>>> This is how you handle handovers today in RFC 5213. Somehow the 
>>>>> MAG
>>> is
>>>> It is somehow the same as we assume that the network aware of the 
>>>> MN using logical interface.
>>>
>>>> For simplicity, we can assume that each MN uses only one LGI to 
>>>> hide all physical interfaces.
>>> Things are getting complexed... Now, the MN can have multiple 
>>> logical interfaces. If this is the case, just prohibit flow mobility 
>>> between difference logical interfaces such as between IF1 and IF3. 
>>> This is equivalent to non-support of logical interface. This just 
>>> doesn't work and nobody who is rational enough would complain...
>>
>>
>>>>>>> prefix(es) if it so chooses based on the ATT field. This would 
>>>>>>> be
>>> scenario 3
>>>>>>> below.
>>>>>>>
>>>>>>
>>>>>>>> If LMA can not recognize which physical interfaces are hidden 
>>>>>>>> by
>>> the
>>>>>>>> same logical interface then it is impossible to assign 
>>>>>>>> prefix(es) exactly to different attachments.
>>>>>>>>
>>>>>>>> In case we assume that the LMA is aware of the logical 
>>>>>>>> interface
>>> at
>>>>>>>> On Wed, Aug 4, 2010 at 2:37 AM, Rajeev 
>>>>>>>> Koodli<[email-masked]>
>>> wrote:
>>>>>>>>>
>>>>>>>>> Hello Carlos, All,
>>>>>>>>>
>>>>>>>>> 1. At the time of a new attachment, the MN obtains a new 
>>>>>>>>> prefix
>>> or a
>>>>>>>>> session.  This is not the default behavior in RFC 5213, and 
>>>>>>>>> the
>>> LMA
>>>>>>>>> 3. At the time of a new attachment, the MN obtains a 
>>>>>>>>> combination
>>> of
>>>>>>>>> the time of a new attachment. Subsequently, no further 
>>>>>>>>> signaling
>>> may
>>>>>>>>> flow mobility signaling whenever the LMA determines the need 
>>>>>>>>> for relocating flows between the different attachments. The 
>>>>>>>>> scenario
>>> 3
>>>>>>>>> requires flow mobility signaling whenever the LMA determines 
>>>>>>>>> the need for relocating flows for the new prefix(es)
>>> which are
>>>>>>>>> concerned MAGs in order for flow mobility to work. 
>>>>>>>>> Furthermore,
>>> each
>>>>>>>>> MAG MUST advertise to the MN the all the prefixes received 
>>>>>>>>> from
>>> the LMA.
>>>>>>>>>
>>>>>>>>>
netext mailing
[email-masked]

---

From: Tran Minh Trung <[email-masked]>
Date: Fri, 6 Aug 2010 17:17:57 +0900

I also agree!

As I mentioned in the previous email, for simplicity we can assume
that the MN uses single logical interface to hide all physical
interfaces.
If everybody agree with this assumption then we do not have to worry
about the case that I pointed out.

Regards,
TrungTM

---

From: Tran Minh Trung <[email-masked]>
Date: Fri, 6 Aug 2010 17:38:43 +0900

Hi Sri, Telemaco

>> different access networks.

I agree with Telemaco.

> across interfaces, which is not desirable.

Sri, what do you mean that is is not desirable?
It is exactly the share-prefix model that I mentioned.
If we can modify the LMA/MAG operation to support it then all off 4
scenarios can coexist.

Regards.
TrungTM

> If the feature is active, we

---

From: Tran Minh Trung <[email-masked]>
Date: Fri, 6 Aug 2010 18:02:26 +0900

Hi Carlos,

>> > (how it finds out, it is out of the scope, can be on the user profile).

Your statement was different from Sri: "The network should not be
aware of the virtual interface configuration on the host"
We need consensus on that issue.

Currently I agree with the way that MAG uses HI to inform LMA that it
can assign the same prefix(es). (@Rajeev)
We can assume that the MAG can set HI exactly the same as handoff case.
The MN-MAG interface document or our logical interface I-D can be
extended to explain how MAG can do that.

Regards,
TrungTM

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 06 Aug 2010 11:08:23 +0200

Also agree.

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 06 Aug 2010 11:10:10 +0200

> We need consensus on that issue.

Not, it is not. That's why I clarified.

> extended to explain how MAG can do that.

We need to work on the details about how to extend RFC5213 to support
the shared prefix scenario.

Carlos

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 06 Aug 2010 16:56:52 +0200

Hi Sri,

> world of difference in solution simplicity terms, between the two. We should

Of course we should support both. My point is that we can have a
solution that naturally support both, without really needing to make a
distinction per-scenario.

Carlos

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 6 Aug 2010 13:32:49 -0700 (PDT)

>
>From: Rajeev Koodli <[email-masked]>
>To: "[email-masked]" <[email-masked]>
>Sent: Tue, August 3, 2010 12:37:08 PM
>Subject: [netext] Scope of Prefixes in Flow Mobility
>
>Scope of Prefixes in Flow Mobility 
>Hello Carlos, All, 
>
>We had some good discussion on the prefix model for the flow mobility work. I 
>have tried to capture the scenarios in the following text. Let’s work towards 
>incorporating this into the draft. 
>
>
>
>X. Prefix Model
>
>There are multiple prefix models under which a flow mobility protocol needs to 
>work:
>
>determines the need for relocating flows for the new prefix(es) which are not 
>shared across attachments.

I think we should ask ourselves why Mobile IPv6 does not have this problem?
From there we can come up with a simplest solution, that's what has been done in 

http://tools.ietf.org/html/draft-sarikaya-netext-fb-support-extensions-00

Regards,

Behcet

---

From: "Youn-Hee Han" <[email-masked]>
Date: Tue, 10 Aug 2010 23:08:13 +0900

Hello Reajeev (and all),

You mentioned the three prefix models in a previous mail as follows:

Do you think that 1) an LMA must always use just one model among the three?

Otherwise, 2) LMA can use any model at any time of MN's new attachment?

IMHO, 2) seems to be right. 

Frankly speaking, I am not still sure when LMA should allocate a new prefix 
to the new interface and when LMA should allocate the same prefix to it. 

Could you clarify it?

If the decision criterion is related to a kind of dynamic one, 2) is right.

What I want to say is that we don't need to concern about LMA's prefix 
allocation model when designing our flow mobility scheme.

Instead, we just need to specify "a flow mobility signaling should happen 
whenever the LMA determines the need for relocating flows for the new
prefix(es)

which are not shared across attachments" which you mentioned in the previous
mail.

Youn-Hee Han

Rajeev wrote:

X. Prefix Model

---

From: "Youn-Hee Han" <[email-masked]>
Date: Wed, 11 Aug 2010 02:02:45 +0900

Hello Rajeev (and all),

Please let me clarify what I am saying. 

We can still keep to use "Unique Prefix Model" according to RFC5213 

when designing the flow mobility.

More specifically, 

At the time of a new interface's attachment, 1) LMA will allocate a new
prefix to the 
new interface according to RFC5213 if it determines that it is not needed to
move 
any existing flow(s) to the new interface. 

2) However, if LMA determines to move an existing flow(s) to the new
interface, 
it should allocate to the new interface the same HNP as the flow's HNP.

I don't think the above rules violate the RFC5213's prefix allocation
policy.

In the above,

1) is the case of attachment over a new interface and 

2) is the case of a kind of handover. 

Youn-Hee Han

From: Youn-Hee Han [mailto:[email-masked]] 
Sent: Tuesday, August 10, 2010 11:08 PM
To: 'Rajeev Koodli'; [email-masked]'
Subject: RE: [netext] Scope of Prefixes in Flow Mobility

Hello Reajeev (and all),

Could you clarify it?

Youn-Hee Han

Rajeev wrote:

X. Prefix Model

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 16 Aug 2010 14:01:09 -0700

Hi Youn-Hee Han,

On 8/10/10 7:08 AM, "Youn-Hee Han" <[email-masked]> wrote:

> Otherwise, 2) LMA can use any model at any time of MN¹s new attachment?
>  
> Rajeev:> I meant 2) - any one of the models is possible at the time of
> attachment.
> 
>  
> Rajeev:> It is up to the policy at the LMA.
>  
> Rajeev:> I don¹t know what you mean by dynamic one, but 2) above provides the
> flexibility.
> 
>  
> What I want to say is that we don¹t need to concern about LMA¹s prefix
> Instead, we just need to specify ³a flow mobility signaling should happen
> which are not shared across attachments² which you mentioned in the previous
> mail.
> 
> Rajeev:> The intent is not to specify any particular prefix allocation model,
> but to simply enlist them.
> I agree that we need to provide the signaling whenever LMA decides to perform
> flow mobility for prefixes which are not already shared across attchments.
> 
> Thanks,
> 
> -Rajeev
> 
>  
> Youn-Hee Han
>  
> Rajeev wrote:
> 
> 
> X. Prefix Model
>

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 19 Aug 2010 14:45:55 -0700

Hi Rajeev,

> I have tried to capture the scenarios in the following text. Let's work towards 
> There are multiple prefix models under which a flow mobility protocol needs to work:
>

I am finding your characterization of this as the default behavior misleading.

In RFC 5213, this is the default behavior only for an unmodified host that does not support inter-access handover, nor flow mobility. That behavior was specified to avoid that an unmodified host that does NOT support inter-access handover ends-up with the same prefix advertized to two different interfaces because that could break such hosts. 

In the context of this work item, and in contrast to the above, we do assume that the host supports inter-access handover and flow mobility thanks to the use of a below-IP mechanism, e.g., the logical interface. 

Thus what the default behavior is for an unmodified host that supports neither inter-access handovers nor flow mobility is irrelevant to the design of a protocol extension providing inter-access handover and flow mobility. 

That being said, I am open to discuss whether or not we want to support assignment of additional prefixes to a mobile node at the time of a new attachment.

> simultaneous attachment (as opposed to the handover scenario only). 

Same comment as above on what is default behavior in the context of a host that does not support inter-access mobility.

>From the perspective of the mobile node, at the time of new attachment it does not matter whether a prefix is new or was already in use. What matters is which prefixes it is going to use in the future.

>From that point of view I see your scenarios 1, 2, and 3, as a single flow mobility scenario. In addition, there is the possible feature of adding new prefixes to an existing flow mobility session. That seems orthogonal to the flow mobility session per se, as the feature could also happen for inter-access or intra-access handovers as well.

> the time of a new attachment. 

I think I agree that we'd need a new indication in the PBU to signal that this is not an intra- or inter-access handoff (i.e., the session is moved from one MAG to another) but addition of an access to an existing session. 

>                           Subsequently, no further signaling may
> relocating flows between the different attachments.

I slightly disagree. What you call Scenario 1 and which I call "addition of a prefix" feature would require signaling to inform prior MAGs about the new prefix being assigned. I however do not see invocation of this feature as necessarily synchronous with bring up of a new access and/or flow mobility decision at the LMA.

>                                                The scenario 3
> determines the need for relocating flows for the new prefix(es) which are not shared 
> across attachments.

As above, what you call scenario 3 is just another manifestation of the "addition of a prefix" feature. Similar to above, it would require signaling that is not necessarily synchronous with bring-up of a new access and/or flow mobility decision at the LMA.

> concerned MAGs in order for flow mobility to work. 

I think that in all scenarios, all prefixes are valid across all MAGs. That is the minimal requirements that we need to support flow mobility across MAGs/accesses. Thus there's only one scenario.

>                                              Furthermore, each

That seems fine. We do have to work out the details of the interactions with neighbor discovery though.

--julien

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 19 Aug 2010 14:57:37 -0700

> Both formats should be supported IMO.

As I've written in another note I believe the only requirements we have to support flow mobility is that all MAGs are aware of the set of prefixes assigned to the mobile node. That allows a MAG to appropriately forwards packets of flows between the mobile node and the LMA.

I do not understand why the MAG would need to know about specific flow filters.

> Neighbor Discovery work for the prefix if it is not advertised?

I am not sure about the details of how this is going to work but one thing to keep in mind is that neighbor discovery executes at the IP layer, that is, above the logical interface. That is, as long as the IP layer sees all prefixes being advertized on the logical interface it seems we are fine. That does not necessarily imply that all prefixes have to be announced though each interface -- there might be another reason that requires this though, I just don't see it right now.

--julien

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 19 Aug 2010 15:45:02 -0700

Hi Telemaco,

One quick comment below:

MELIA, TELEMACO wrote:
> This can be a flag in  the mobile node's profile (section 6.2 of RFC
> 5213). I suggest to extend the mandatory fields by adding the flow
> mobility service.
> The LMA will be receiving a PBU with the necessary information and can
> take the decision on whether to assign multiple prefixes or the same
> across different access networks. The presence of the flow mobility bit
> implicitely triggers the extended prefix assignment algorithm.
> Now, about filters vs. prefix only configured in the MAG for flow
> mobility. I think we should be flexible and allow both to be
> transferred to the MAG. This allows the MAG to understand flows if
> required (else routing is only possible via IP addreses).

The key point in your sentence above is "if required." 

So far I haven't seen a convincing argument as to why we'd need to signal traffic flow filters in a network-based design. In this situation, I do not know why "we should be flexible"...

(Regarding routing, it seems that the MAG is able to route packets appropriately from and to the mobile node as long as it is aware of the mobile node's prefixes.)

--julien

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 19 Aug 2010 16:18:16 -0700

Hi Hidetoshi - 

Pls. see one comment below:

Hidetoshi Yokota
> Let's try to make it as simple as possible in order to get consensus

Agree. As simple as possible is: all prefixes assigned to the mobile node are signaled to the mobile node's MAG. Then LMA can decides where to route flow. This is the minimum requirement for network-based flow mobility.

--julien
 
> >>>> as new prefix(es) if it so chooses based on the ATT field. This would be
> >>>> scenario 3 below.
> >>>>
> >>>

---

From: "Youn-Hee Han" <[email-masked]>
Date: Fri, 20 Aug 2010 11:22:07 +0900

Hi Julien and all,

> Agree. As simple as possible is: all prefixes assigned to the mobile node
> are signaled to the mobile node's MAG. Then LMA can decides where to route
> flow. This is the minimum requirement for network-based flow mobility.
> 
> --julien

As I wrote in the previous mails, I also agree with Julien. 
I'd like to rephrase his comments as follows 

"All prefixes assigned to an MN are signaled to the *all* MAGs which serve the MN.
Then, LMA can decides where to route each flow. This is the minimum requirement
for the network-based flow mobility." I like this.

But, there is still an issue relevant to the signaling. 
It can be called "Proactive vs. Reactive Signaling."

"Proactive Signaling" means that when LMA assigns a new prefix to MN via an MAG, 
it proactively signals the prefix to the other all MAGs. "Reactive Signaling" 
means that LMA signals the new prefix to another (not all) MAG only when a flow 
is needed to be moved to the MAG which has not the prefix.

Which strategy should we select? or... We support both?

Youn-Hee Han

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 19 Aug 2010 20:09:56 -0700

This is the essence of what I have been saying:

1. LMA can assign whatever prefix it chooses upon each attachment
(already-assigned prefix, a new one, a combination of the two)
2. For flow mobility to work, the prefix has to be valid on the
corresponding MAG
3. It is up to the LMA to decide when to signal the prefix (if it is not
already valid on the MAG in question) - my statement "whenever the LMA
decides.." in the text I proposed.

So, to answer your question (Reactive vs. Proactive): leave it to the LMA.
But, we do need to document the implications of *when* we signal the prefix
to MAGs; e.g., signaling as soon as the MN is assigned a new prefix vs.
on-demand. 
 
The remaining question in my mind is what is the requirement for a MAG when
it learns a new prefix? It should advertize it in the RA for ND to work
correctly? Are we okay without it? Not sure..

-Rajeev

---

From: "MELIA, TELEMACO (TELEMACO)" <[email-masked]>
Date: Fri, 20 Aug 2010 15:51:49 +0200

Hi Julien,

Please see below.
Telemaco

Hi Telemaco,

One quick comment below:

TELE: In EV-DO, the MAG (PDSN/HSGW) already receives the 5-tuples and does filtering and throttling based on policy. We should therefore let the MAG communicate to the LMA if specific flows cannot be accommodated.

TELE: this is right, but I would not be in favor of a solution that initializes all the prefixes at attachment time. This is why the cases that Rajeev explored in his previous post make sense to me. Considering that FMI/FMA signaling is required with the above statement I do not see any problem is allowing the MAG to know run time additional prefixes to be routed. 

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 20 Aug 2010 07:36:02 -0700

> TELE: In EV-DO, the MAG (PDSN/HSGW) already receives the 5-tuples and does filtering and throttling based on policy. We should therefore let the MAG communicate to the LMA if specific flows cannot…

In the absence of MN-AR interface, the need for the MAG providing the flow filters to LMA is not critical. There is an assumption,  the MAG learns those  flow policies from some service layer, that the LMA can also learn. Its a fair point. 

But, assuming the MN-AR interface layer evolves (say a given SDO architecture implemented some link-layer specific interface, such as the netlmm's MN-AR interface), in that scenario the mobile node has the capability to hint the MAG on the flow policies and the same can be carried to the LMA. So, its allowing that flexibility. Since, the TF spec work is largely leveraged from MEXT, it just additional option can be carried between the LMA and MAG. 

Sri

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 20 Aug 2010 10:36:18 -0700

Hi Sri,

Some comments below -

Sri Gundavelli wrote: 
> > across different access networks.
> 
> The above approach will always will result in a single prefix
> allocation across interfaces, which is not desirable. If the feature is
> active, we start with one prefix on a interface and start sharing on
> the other interface. Couple of points:
> 
> 1.) For each new interface attachment, always allocate a new prefix, or
> set of prefixes, just as in 5213.
> different interface to be relocated to the new interface, the approach
> of prefix sharing across interfaces can be considered.
> 
> moving all the flows associated with a prefix (i.e. Using the source
> address from the same prefix) i.e. Mohana's draft, to a new interface.
> This is almost like Sceanario-1, we have proper indicators.
> 
> prefixes across interfaces. But, scenario-4 and scenario-2 should not
> be seen as mutually exclusive. In other words, its not always
> multihoming vs prefix sharing, but rather its always multihoming, but
> some flows that had to moved to different interface (determined by
> policy), even if they are using a prefix from the prev interface, we
> need to share so those flows can be relocated. Assuming new flows will
> pick up the right source address/interface selection and eventually
> keeping the prefixes to the respective interfaces.

If you have, as you put it, "some flows that had to moved to different interface, even if they are using a prefix from the prev interface", it means that a prefix is no longer bound to a unique interface since flows from/to that prefix can show up on a difference interface.

Thus it is the case that prefixes are decorrelated from interfaces, which naturally lead to a per-MN prefix set that are equally available on all accesses/interfaces.

That does not preclude being able to assign additional prefixes when additional accesses are brought up, although I'd like to understand better the motivation behind such a feature. As I said this was primarily introduced to avoid issues involved with an unmodified host being multihomed, but we do no longer have to care about this since the host is isolated from the issues thanks to a below-IP logical interface.

--julien

> > I think that the flow mobility feature can be regarded as a service
> to
> > which mobile customers subscribe.
> > across different access networks. The presence of the flow mobility
> > bit implicitely triggers the extended prefix assignment algorithm.
> >>> prefix(es) if it so chooses based on the ATT field. This would be
> >>> scenario 3 below.
> >>>
> >
> > Right. We assume the network provides the handover hints. We do not
> > have the MN-AR interface at this point. When we were writing the base
> > spec, the MN-AR interface was factored into the design. Julien was
> > working on this and some where we lost track of this critical
> interface.
> >
> > We need to revive this at some point. I was hoping
> > Telemaco/Carlos/Juan Carlos will revive this in for different SDO
> > architectures, at least that was our understanding.
> >
> > Ideally, the handover hints will come from that interface. If we
> build
> > this interface, eventually, the mobile node can express the handover
> > preferences and flow-path preference. This will allow us to cleanly
> > support the shared prefix scenario.
> >
> >
> >
> > Sri
> >
> >
> >
> >
> >
> >
> >
> >
> >>> I am still trying to understand what will not work if we don't make
> >>> this assumption..
> >>>
> >>> Signaling extension in Binding Update to inform the LMA to support
> >>> same prefix assignment. This can be another value assignment for
> the HI field.
> >>> prefix(es) if it so chooses based on the ATT field. This would be
> >>> scenario 3 below.
> >>>
> >>
> >>>> If not, how LMA can differentiate which physical interfaces are
> >>>> hidden by the same logical interface?
> >>>> If LMA can not recognize which physical interfaces are hidden by
> >>>> the same logical interface then it is impossible to assign
> >>>> the MN, then it is easy to enable LMA to assign the same
> prefix(es)
> >>>> to all attachments of the logical interface.
> >>>>
> >>>>> I have tried to capture the scenarios in the following text.
> Let¹s
> >>>>> work towards incorporating this into the draft.
> >>>>>
> >>>>>
> >>>>> X. Prefix Model
> >>>>>
> >>>>> Flow mobility assumes simultaneous access to more than one
> >>>>> network, in a contrast to a typical handover where connectivity
> to
> >>>>> a physical medium is relinquished, and is re-established with
> another.
> >>>>> 1. At the time of a new attachment, the MN obtains a new prefix
> or
> >>>>> a new set of prefixes. This is the default behavior with RFC 5213.
> >>>>>
> >>>>> 2. At the time of a new attachment, the MN obtains the same
> prefix
> >>>>> or the same set of prefixes as already assigned to an existing
> >>>>> session.  This is not the default behavior in RFC 5213, and the
> >>>>> LMA needs to be able to provide the same assignment even for the
> >>>>> prefix(es) in use and new prefix(es). This is a hybrid of the
> >>>>> above two scenarios. The local policy determines whether the new
> >>>>> prefix is exclusive to the new attachment or it can be assigned
> to
> >>>>> an existing attachment as well.
> >>>>>
> >>>>> Among the above, scenario 2 needs extensions to RFC 5213
> signaling
> >>>>> at the time of a new attachment. Subsequently, no further
> >>>>> signaling may be necessary between the LMA and the MAG. The
> >>>>> scenario 1 requires flow mobility signaling whenever the LMA
> >>>>> determines the need for relocating flows between the different
> >>>>> attachments. The scenario 3 requires flow mobility signaling
> >>>>> whenever the LMA determines the need for relocating flows for the
> >>>>> new prefix(es) which are not shared across attachments.
> >>>>> In all the scenarios, a prefix has to  be valid on the concerned
> >>>>> MAGs in order for flow mobility to work. Furthermore, each MAG
> >>>>> MUST advertise to the MN the all the prefixes received from the
> LMA.
> >>>>>
> >>>>>

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 20 Aug 2010 10:39:27 -0700

Hi Carlos,

I am unsure yet whether or not there is a requirement to advertize all prefixes on all interfaces. 

This is the reason why I have commented during the working group meeting that the logical interface draft shall shows why neighbor discovery works fine for an IP stack on top of the logical interface. That being done, we'd hopefully have an answer to your question.

--julien

> Behalf Of Carlos Jesús Bernardos Cano
> Sent: Thursday, August 05, 2010 8:48 AM
> To: Sri Gundavelli
> Cc: [email-masked]; [email-masked]; Minh Trung
> I've always seen Scenario 3 as a sub-case of scenario 4 (the
> granularity is per-prefix, not per 5-tuple flow). Question: for
> scenario 4: do we really need the MAGs to advertise all the prefixes to
> the MN? I think it is not really required if the MN uses the logical
> interface concept. The only requirement is that the MAG knows how to
> route the prefixes (e.g., know that P2 is reachable through the same
> p2p interface where P1 is reachable, without really advertising P2 on
> that interface).
> 
> Kind Regards,
> 
> Carlos
> 
> > > The LMA will be receiving a PBU with the necessary information and
> > > can take the decision on whether to assign multiple prefixes or the
> > > same across different access networks.
> >
> > allocation across interfaces, which is not desirable. If the feature
> > is active, we start with one prefix on a interface and start sharing
> > on the other interface. Couple of points:
> >
> > 1.) For each new interface attachment, always allocate a new prefix,
> > or set of prefixes, just as in 5213.
> > Scenario-1 and Scenario-2 are covered in 5213. Now, we have
> > scenario-3, moving all the flows associated with a prefix (i.e. Using
> > the source address from the same prefix) i.e. Mohana's draft, to a
> new
> > interface. This is almost like Sceanario-1, we have proper indicators.
> >
> > The other scenario, which I never liked is scenario-4, requiring
> > shared prefixes across interfaces. But, scenario-4 and scenario-2
> > should not be seen as mutually exclusive. In other words, its not
> > always multihoming vs prefix sharing, but rather its always
> > multihoming, but some flows that had to moved to different interface
> > (determined by policy), even if they are using a prefix from the prev
> > interface, we need to share so those flows can be relocated. Assuming
> > new flows will pick up the right source address/interface selection
> > and eventually keeping the prefixes to the respective interfaces.
> >
> >
> > Sri
> >
> >
> >
> >
> >
> >
> >
> > > to which mobile customers subscribe.
> > > The LMA will be receiving a PBU with the necessary information and
> > > can take the decision on whether to assign multiple prefixes or the
> > > same across different access networks. The presence of the flow
> > > mobility bit implicitely triggers the extended prefix assignment
> algorithm.
> > > From: [email-masked] [[email-masked]] On Behalf
> Of
> > > Sri Gundavelli [[email-masked]]
> > > have the MN-AR interface at this point. When we were writing the
> > > base spec, the MN-AR interface was factored into the design. Julien
> > > was working on this and some where we lost track of this critical
> interface.
> > >
> > > build this interface, eventually, the mobile node can express the
> > > handover preferences and flow-path preference. This will allow us
> to
> > > cleanly support the shared prefix scenario.
> > >
> > >
> > >
> > > Sri
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >>> I am still trying to understand what will not work if we don't
> > >>> make this assumption..
> > >>>
> > >> How can we set the value of HI exactly?.  Without signaling from
> > >> the MN, I think it is not easy.
> > >> Let's assume that we can set the value of HI exactly. Then if the
> > >> MN uses 2 logical interfaces to hide two different sub-interface
> > >> paths, how can LMA differentiate them by just depending on HI?
> > >>
> > >> PS: I can not find the scenario 2,3 that you mentioned. Are they
> > >> the scenarios in your previous email?
> > >>
> > >> Regards,
> > >> TrungTM
> > >>
> > >>
> > >>>
> > >>>> In case we assume that the LMA is aware of the logical interface
> > >>>> at the MN, then it is easy to enable LMA to assign the same
> > >>>> prefix(es) to all attachments of the logical interface.
> > >>>>
> > >>>>> Let¹s work towards incorporating this into the draft.
> > >>>>>
> > >>>>>
> > >>>>> X. Prefix Model
> > >>>>>
> > >>>>> to a physical medium is relinquished, and is re-established
> with another.
> > >>>>> or a new set of prefixes. This is the default behavior with RFC
> 5213.
> > >>>>>
> > >>>>> prefix or the same set of prefixes as already assigned to an
> > >>>>> existing session.  This is not the default behavior in RFC 5213,
> > >>>>> and the LMA needs to be able to provide the same assignment
> even
> > >>>>> for the simultaneous attachment (as opposed to the handover
> scenario only).
> > >>>>>
> > >>>>> to an existing attachment as well.
> > >>>>>
> > >>>>> signaling at the time of a new attachment. Subsequently, no
> > >>>>> further signaling may be necessary between the LMA and the MAG.
> > >>>>> The scenario 1 requires flow mobility signaling whenever the
> LMA
> > >>>>> whenever the LMA determines the need for relocating flows for
> > >>>>> the new prefix(es) which are not shared across attachments.
> concerned

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 20 Aug 2010 10:42:30 -0700

Multiple logical interfaces would exist on the mobile node if it has multiple simultaneous sessions. For example, the mobile node could have simultaneous sessions at different LMAs.

--julien 

> Behalf Of [email-masked]
> Sent: Thursday, August 05, 2010 9:07 AM
> To: [email-masked]; [email-masked];
> [email-masked]
> >> MN
> logical
> > I agree 100% with your statement about the usage of the multiple
> logical
> > interfaces.
> > We should include some wording about it in the next revision, just to
> make
> > sure that rationality prevails ;)
> >
> >
> >>
> >> prefix(es) to
> >> Let¹s work
> >> network, in
> >> prefix or
> >> above
> >> signaling at
> for
> >>>>>>>> relocating flows between the different attachments. The
> scenario
> >> 3
> >>>>>>>> determines the need for relocating flows for the new
> prefix(es)
> >> which are

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 20 Aug 2010 11:03:22 -0700

Hi Telemaco,

Please see below -

TELEMACO (TELEMACO) wrote:
> So far I haven't seen a convincing argument as to why we'd need to
> signal traffic flow filters in a network-based design. In this
> situation, I do not know why "we should be flexible"... 
> 
> TELE: In EV-DO, the MAG (PDSN/HSGW) already receives the 5-tuples and
> does filtering and throttling based on policy. We should therefore let
> the MAG communicate to the LMA if specific flows cannot be accommodated.

EV-DO is an air interface. How does that relate to the protocol a MAG speaks with an LMA?
 
> (Regarding routing, it seems that the MAG is able to route packets
> appropriately from and to the mobile node as long as it is aware of the
> mobile node's prefixes.)
> 
> TELE: this is right, but I would not be in favor of a solution that
> initializes all the prefixes at attachment time. This is why the cases
> that Rajeev explored in his previous post make sense to me. Considering
> that FMI/FMA signaling is required with the above statement I do not
> see any problem is allowing the MAG to know run time additional
> prefixes to be routed.

As I've said earlier, whether or not there is a possibility to add additional prefixes later is orthogonal to 1) whether or not prefixes are bound to (set of) interfaces as opposed to MN-wide, and 2) whether there's a need to send a traffic selector to achieve flow mobility. 

Adding additional prefixes later is something that I am willing to consider, though I'd like to understand better the motivation.

--julien

> > have the
> > MN-AR interface at this point. When we were writing the base spec,
> the
> > MN-AR
> > interface was factored into the design. Julien was working on this
> and
> > some
> Telemaco/Carlos/Juan
> > this
> > this
> > >>> Should we assume that the LMA is aware of the logical interface
> at
> > the MN?.
> > work
> network,
> > in
> > a
> > >>>> two scenarios. The local policy determines whether the new
> prefix
> > is

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 20 Aug 2010 11:14:11 -0700

Sri Gundavelli wrote: 
> > Julien Laganier wrote:
> In the absence of MN-AR interface, the need for the MAG providing the
> flow filters to LMA is not critical. There is an assumption,  the MAG
> learns those  flow policies from some service layer, that the LMA can
> also learn. Its a fair point.

Good to hear.
 
> But, assuming the MN-AR interface layer evolves (say a given SDO
> architecture implemented some link-layer specific interface, such as
> the netlmm's MN-AR interface), in that scenario the mobile node has the
> capability to hint the MAG on the flow policies and the same can be
> carried to the LMA. So, its allowing that flexibility. Since, the TF
> spec work is largely leveraged from MEXT, it just additional option can
> be carried between the LMA and MAG.

That would be specific to this given SDO architecture and not applicable to the Internet at large. Thus the IETF is not likely to be an appropriate place to specify those extensions. If a given SDO has a will to extend PMIPv6 with mechanisms specifics to their link layer(s), it is that SDO which has the expertise and knowledge necessary to achieve its goals and thus the work is best carried upon there. One SDO is already using extensions to PMIPv6 to achieve its SDO-specific goals:

<http://www.quintillion.co.jp/3GPP/Specs/29282-810.pdf>

--julien