Subject: [MEXT] About the flow binding charter item

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 20 May 2009 15:04:37 +0200

Hi,

There seems to be some discrepancies about the MEXT charter item
regarding the work on flow bindings.
Since the charter is the guide for our work, it would be important to
clarify it, so we can have a unified interpretation of the charter.
Please note that what it is in the charter is not cast in stone, but
it seems to reflect previous consensus and we need good reasons to
change it.

So, the current charter item about flow bindings reads:

- A "Flow/binding policies exchange" solution for an exchange of
policies from the mobile host/router to the Home Agent and from the
Home Agent to the mobile host/router influencing the choice of the
Care-of Address and Home Agent address. The solution involves two
specifications, one for the policy format and another for its
transport [both Standard Track].

The first problem with this text is the use and interpretation of the
word policy. Since the policy word may have a broad interpretation.
it would be important to make the charter more explicit about the
expected work. We understand that it is the WG consensus that what
need to be exchanged is a solution for the exchange of flow binding
rules.

So, we understand that it would be more explicit to replace the usage
of the expression Flow/binding policies exchange by Flow Binding
rules exchange. Would that reflect with the WG interpretation?

Second, the current charter item explicitly mentions that the
proposed approach must support sending flow binding information from
the MN to the HA and also from the HA to the MN. Moreover, the
current charter talks about influencing not only the selection of the
CoA but also the selection of the HA address. However, our current WG
document does not supports sending information from the HA and it
does not cover the possibility of influencing the HA address. So, one
possible interpretation of the charter would be that the MN sends
flow binding information to influence the CoA selection and the HA
sends flow binding information to influence the HA address selection.
Other interpretation is that both the MN and the HA send information
regarding both the HA address and the CoA selection.

So, we would like that the WG express their opinion on both items
mentioned above:

1- whether we should replace Flow/binding policies exchange by Flow
Binding rules exchange in the charter

2- whether the information should be sent from the MN to the HA only
or it should also be sent from the HA to the MN and if the
information exchanged in each direction should affect the CoA and/or
the HA address.

Regards, Julien and marcelo

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 20 May 2009 23:19:43 +1000

> regarding both the HA address and the CoA selection.

=> I just noticed the but about influencing the HA address selection
actually. I don't even know what that means or why it's there.

> Binding rules exchange in the charter

=> Agree.

> information exchanged in each direction should affect the CoA and/or

=> As a charter, I don't think it needs to describe how something should be
solved. It should talk about _what_ needs to be solved, i.e. The problem and
not how to solve it. So I would say "exchange filter rules between the
mobile node and HA". Implicit in that statement is the use of MIP, which
should be non-controversial given the WG's role.

Hesham

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

---

From: Thierry Ernst <[email-masked]>
Date: Wed, 20 May 2009 15:21:51 +0200

Dear Marcelo,

Let me reply since this part of the MEXT charter was taken from MonAmi6 
charter which Nicolas and I wrote with the help of other people 
(including ADs).
> rules exchange. Would that reflect with the WG interpretation?
Yes.
At the time there was no controversy when using the former wording.
> Binding rules exchange in the charter
Yes.
> information exchanged in each direction should affect the CoA and/or
I would recommend to rephrase the question in 2.a and 2.b

2.a.: Unidirectional exchange or bidirectional ?

In MonAmi6 times, we definitely wanted to have a bidirectional exchange 
of rules and I think we should stick to it. It will be required in some 
usage scenarios.

2.b. Affect CoA only, and/or HA address ?

and we wanted to influence the choice of the HoA too though this was not 
agreed for setting up MonAmi6 as a group so this was rephrased and HA 
address appeared instead, as a compromise. I wish we keep the 
possibility to influence the choice of the HA address.

Now, this said, the current drafts may or may not address all of these 
(they may not if this would bring them to square one as we need these 
draft to be published), but these shall be kept in the charter, definitely.

Regards,
Thierry

---

From: [email-masked] (Arnaud Ebalard)
Date: Wed, 20 May 2009 15:35:06 +0200

Hi,

> Binding rules exchange in the charter

Maybe it would be easier to define both terms before asking for an
opinion. I think the whole discussion started because people did not
agree on the definitions of "policy" and "rule".

> information exchanged in each direction should affect the CoA and/or

I don't see any specific scenario in which it would be useful for the HA
to influence the MN on flow binding. So I am in favour of keeping
current focus on the MN to HA side. The reverse direction could be
treated in external documents and if there are useful use cases and
momentum, that scenario could be reconsidered later.

For the HA@ question, I don't see what you have in mind. Usually, the MN
has a single address for the HA. Are you considering the ability for the
HA to be accessible at various addresses by the MN? If that is the case,
I think working on the flow binding betwenn CoAs (and possibly HoA via
RO bypass case) is the thing to do.

Cheers,

a+

---

From: [email-masked] (Arnaud Ebalard)
Date: Wed, 20 May 2009 15:44:55 +0200

Hi Thierry,

Thierry Ernst <[email-masked]> writes:

> In MonAmi6 times, we definitely wanted to have a bidirectional
> exchange of rules and I think we should stick to it. It will be
> required in some usage scenarios.

Can you quickly describe those scenarios.

> and we wanted to influence the choice of the HoA too though this was
> not agreed for setting up MonAmi6 as a group so this was rephrased and
> HA address appeared instead, as a compromise. I wish we keep the

When you say "influence the choice of the HoA", you mean provide the
ability for the MN using the flow binding solution with a CN to have
traffic routed to the HoA instead of some CoA, i.e. bypass RO. Or sth
else? 

Cheers,

a+

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 20 May 2009 15:45:24 +0200

> agree on the definitions of "policy" and "rule".
are you suggesting we include a definition of policy or rule in the charter?
I am not sure this is the best approach.
What i would like to to have some words in the charter that are non 
controversial (in their interpretation)
I was thinking that policy was a controversial word (with multiple 
interpretations) while rule wasn't, hence the proposal to change it.

> For the HA@ question, I don't see what you have in mind. 
i don't have anything in mind (really, it is pure vacuum lately)

I am just refering to the charter as it is currently written and i want 
to understand where the WG stands on these topics.
so feel free to make any interpretation and explain what you think makes 
sense. Let's see if we can reach a common understanding of what is the 
work that we should do. that is the basic goal here.

Regards, marcelo

> Usually, the MN

---

From: [email-masked] (Arnaud Ebalard)
Date: Wed, 20 May 2009 15:54:14 +0200

Hello,

> are you suggesting we include a definition of policy or rule in the

no, just provide the definitions of both words on the list and then
decide based on those.

> i don't have anything in mind (really, it is pure vacuum lately)

;-)

> I am just refering to the charter as it is currently written and i
> want to understand where the WG stands on these topics.
> so feel free to make any interpretation and explain what you think
> makes sense. Let's see if we can reach a common understanding of what
> is the work that we should do. that is the basic goal here.

Based on previous comments from Thierry, the "HA address" thing needs to
be clarified.

Cheers,

a+

---

From: George Tsirtsis <[email-masked]>
Date: Wed, 20 May 2009 15:05:29 +0100

2009/5/20 Thierry Ernst <[email-masked]>:
> charter which Nicolas and I wrote with the help of other people (including
> ADs).
>>
>>
> In MonAmi6 times, we definitely wanted to have a bidirectional exchange of
> rules and I think we should stick to it. It will be required in some usage
> scenarios.
>

GT> What scenarios are you referring to? All the practical scenarios I
am aware of use broad guidelines from the network to the end node
(802.21, ANDSF etc) and they do not try to micromanage the MN. I
thought this became part of MIPSHOP.

> 2.b. Affect CoA only, and/or HA address ?

GT> Could someone elaborate on the "HA address" part? what is this all about?

> address appeared instead, as a compromise. I wish we keep the possibility to
> influence the choice of the HA address.
>
> Now, this said, the current drafts may or may not address all of these (they
> may not if this would bring them to square one as we need these draft to be
> published), but these shall be kept in the charter, definitely.
>
> Regards,
> Thierry
>>

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 21 May 2009 00:12:54 +1000

> GT> Could someone elaborate on the "HA address" part? what is this all about?

=> Historically monami6 was trying to allow for multihoming of both HoA and
CoA. There was no concensus/IESG approval for such WG in paris but everyone
agreed that we can start with CoA multihoming but do an analsysis doc for
both. 
I assume this "left-over" wording about HA address selection is a really bad
attempt to preserve something from the multiple HoA sceanrio. But I think
it's at best confusing to have such text and when you actually try to read
this sentence and see what it means you discover it makes no sense at all.

Hesham

---

From: George Tsirtsis <[email-masked]>
Date: Wed, 20 May 2009 15:15:27 +0100

But is this about multiple HoAs belonging to a given MN, on the same HA?

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 21 May 2009 00:18:53 +1000

> But is this about multiple HoAs belonging to a given MN, on the same HA?

=> same or different HA. That was the initial discussion. But as I said, in
Paris it was agreed that monami6 will only work on PS docs for CoA
multihoming. 

Hesham

>>>> (they

---

From: Frank Xia <[email-masked]>
Date: Wed, 20 May 2009 09:43:54 -0500

Hi Marcelo

> information exchanged in each direction should affect the CoA and/or

IMHO, we should define operation from HA to MN.

A very simple analogy,  there is "Binding Revocation
for IPv6 Mobility", and I think there are the same reasons
to have ""Flow Binding Revocation for IPv6 Mobility"

In 3GPP network, operators  always tend to control
the networks.

We have some details in our draft
http://tools.ietf.org/id/draft-xia-mext-ha-init-flow-binding-00.txt.

BR
Frank

----- Original Message ----- 
From: "marcelo bagnulo braun" <[email-masked]>
To: "mext" <[email-masked]>
Cc: "Jari Arkko" <[email-masked]>; "Julien Laganier" 
<[email-masked]>
Sent: Wednesday, May 20, 2009 8:04 AM
Subject: [MEXT] About the flow binding charter item

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 21 May 2009 02:13:44 +1000

> to have ""Flow Binding Revocation for IPv6 Mobility"

=> There is nothing in common between a binding revocation message which
tells the MN that it needs to remove a binding maintained by the sender (the
HA), and a message that tells the MN to use a particular address for one or
more flows where the HA knows nothing about the conditions of the interface
associated with such address. I don't understand how one can draw the
analogy above. In one case the HA knows everything there is to know, in the
other the HA knows nothing.

> http://tools.ietf.org/id/draft-xia-mext-ha-init-flow-binding-00.txt.

=> It's not about creating messages, it's how they would be used. Creating
messages is easy. 

Hesham

---

From: Nicolas Montavont <[email-masked]>
Date: Wed, 20 May 2009 18:19:14 +0200

Hi,

> IMHO, we should define operation from HA to MN.

I disagree: the HA has no way to know about which address is allocated  
to which interface.
For me, Flow Binding in MIPv6 should only define the final mapping of  
flows on current CoAs. How these policies are set up is out of scope  
of MIPv6. If the HA (or more probably some other entity in the  
network) wants to install rules on the interface usage of a mobile  
node, it can use another protocol that has no reason to be part of  
MIPv6.

Nicolas

> ----- Original Message ----- From: "marcelo bagnulo braun" <[email-masked] 
> >
> Cc: "Jari Arkko" <[email-masked]>; "Julien Laganier" <[email-masked] 
> >

---

From: Nicolas Montavont <[email-masked]>
Date: Wed, 20 May 2009 18:37:02 +0200

> Binding rules exchange in the charter

Yes - this is a good idea

> information exchanged in each direction should affect the CoA and/or

Unidirectional from the MN to the HA.

As far as I remember the HA address thing was the situation where your  
HA is multihomed and reachable through multiple addresses. As we may  
want to implement a selection algorithm for one end of the tunnel (the  
CoA), it seems natural to also provide means to select the other end  
of the tunnel, ie, the selection of the HA address. I am not sure  
though that we need a MIPv6 specific mechanism to indicate which HA  
address to use.

Nicolas

---

From: Frank Xia <[email-masked]>
Date: Wed, 20 May 2009 12:12:13 -0500

Hi Nicolas

Does this make sense?

MN installs a flow binding to HA, and
HA  revokes the flow binding later because
of acounting, mainteance and other reasons.

BR
Frank

----- Original Message ----- 
From: "Nicolas Montavont" <[email-masked]>
To: "Frank Xia" <[email-masked]>
Cc: "marcelo bagnulo braun" <[email-masked]>; "mext" <[email-masked]>; 
"Julien Laganier" <[email-masked]>; "Jari Arkko" 
<[email-masked]>
Sent: Wednesday, May 20, 2009 11:19 AM
Subject: Re: [MEXT] About the flow binding charter item

> I disagree: the HA has no way to know about which address is allocated  to 
> which interface.
> flows on current CoAs. How these policies are set up is out of scope  of 
> MIPv6. If the HA (or more probably some other entity in the  network) 
> wants to install rules on the interface usage of a mobile  node, it can 
> use another protocol that has no reason to be part of  MIPv6.
>
> Nicolas
>
>>
>>
>> <[email-masked]
>> >

---

From: Frank Xia <[email-masked]>
Date: Wed, 20 May 2009 12:21:14 -0500

Hi Hesham

Please see my inline response...

BR
Frank

----- Original Message ----- 
From: "Hesham Soliman" <[email-masked]>
To: "Frank Xia" <[email-masked]>; "marcelo bagnulo braun" 
<[email-masked]>; "mext" <[email-masked]>
Cc: "Julien Laganier" <[email-masked]>; "Jari Arkko" 
<[email-masked]>
Sent: Wednesday, May 20, 2009 11:13 AM
Subject: Re: [MEXT] About the flow binding charter item

> other the HA knows nothing.

Frank=>I am sorry because I am the one draw the analogy :-)
Just I said before, HA can run Flow Binding based on
previous  MN flow binding operation. HA initiated operation
is just complimentary to your draft which is  MN initiated.

> => It's not about creating messages, it's how they would be used. Creating
Frank=>You are right.   However,  BU/BA solution is tied to
MN->HA way operation which seems to have some limitation
in some scenario I tried to explain.

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 20 May 2009 15:56:41 -0700

Hi Marcelo,

> Binding rules exchange in the charter

agree

> information exchanged in each direction should affect the CoA and/or

I want to support both direction.
There is a case where an operator wants to install rules to MN.

The FID option is a mobility option and should be carried by other MH  
message.
Ex. If FID option can be carried in generic notification message, we  
can easily support both directions.
I don't see much difficulty to support both direction. We just relax  
to use other MH message to carry FID options.

btw, There is other reason that I want to decouple FID from BU.

-  Updating two different status (binding and flow rules) by single  
message can optimize the # of signaling in some sense.
   However, even if only one of status change, the other status must  
be updated, too.
   Even though binding information is unchanged, MN need to send BU to  
refresh the rules.
   If MN changes the rules frequently, HA overhead might be increased.

regards,
ryuji

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 21 May 2009 09:08:26 +1000

> is just complimentary to your draft which is  MN initiated.

=> But in the email you're referring to you were talking about the HA
revoking a flow binding. That's already possible today with the binding
revocation message. Rejecting/revoking something is different from
initiating the installation of a filter rule.

Hesham

---

From: Frank Xia <[email-masked]>
Date: Wed, 20 May 2009 18:19:40 -0500

Hi Ryuji

Here is my comment on your comments

Full two-way flow binding operation is not necessary.
E.g, it seems to be unnecessary for CN to initiate flow
binding operation to MN

BR
Frank

----- Original Message ----- 
From: "Ryuji Wakikawa" <[email-masked]>
To: "marcelo bagnulo braun" <[email-masked]>
Cc: "Julien Laganier" <[email-masked]>; "Jari Arkko" 
<[email-masked]>; "mext" <[email-masked]>
Sent: Wednesday, May 20, 2009 5:56 PM
Subject: Re: [MEXT] About the flow binding charter item

> Ex. If FID option can be carried in generic notification message, we  can 
> easily support both directions.
> I don't see much difficulty to support both direction. We just relax  to 
> use other MH message to carry FID options.
>
>   However, even if only one of status change, the other status must  be 
> updated, too.

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 20 May 2009 16:22:07 -0700

Hi Frank

I meant flow binding operation from HA to MN.

ryuji

On 2009/05/20, at 16:19, Frank Xia wrote:

> ----- Original Message ----- From: "Ryuji Wakikawa" <[email-masked] 
> >
> Cc: "Julien Laganier" <[email-masked]>; "Jari  
> Arkko" <[email-masked]>; "mext" <[email-masked]>
>> The FID option is a mobility option and should be carried by other  
>> MH message.
>> Ex. If FID option can be carried in generic notification message,  
>> we  can easily support both directions.
>> I don't see much difficulty to support both direction. We just  
>> relax  to use other MH message to carry FID options.
>>
>>  Even though binding information is unchanged, MN need to send BU  
>> to refresh the rules.

---

From: Frank Xia <[email-masked]>
Date: Wed, 20 May 2009 18:26:26 -0500

Hi Hesham

Please check my reply..

BR
Frank
----- Original Message ----- 
From: "Hesham Soliman" <[email-masked]>
To: "Frank Xia" <[email-masked]>; "marcelo bagnulo braun" 
<[email-masked]>; "mext" <[email-masked]>
Cc: "Julien Laganier" <[email-masked]>; "Jari Arkko" 
<[email-masked]>
Sent: Wednesday, May 20, 2009 6:08 PM
Subject: Re: [MEXT] About the flow binding charter item

> initiating the installation of a filter rule.
Frank=>Binding revocation  message does not support
flow operation. Please check.   Flow binding revocation is
a typical use case I figured out.  Surely, I will investigate
more on other use cases regarding installation of a rule.

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 21 May 2009 10:26:49 +1000

> flow operation. Please check.

=> It doesn't matter, you can easily extend it if that's what you want to
do. My point is that this is different from installing filters in the MN by
the HA.

Hesham

Flow binding revocation is

---

From: Yungui Wang <[email-masked]>
Date: Thu, 21 May 2009 09:03:59 +0800

Hello

> Binding rules exchange in the charter

Agree.

> or it should also be sent from the HA to the MN 

Support two-direction. I do think it is useful for HA initiating flow
binding. 
For example, when HA receives indication of link layer overload/failure, 
it can initiate flow binding to handoff MN's flows from one CoA to another.

B.R.
Yungui

> and if the

---

From: "Koojana Kuladinithi" <[email-masked]>
Date: Thu, 21 May 2009 22:59:09 +0200

Hi

>Binding rules exchange in the charter

Agree

>information exchanged in each direction should affect the CoA and/or

Are there any convincing scenarios, where HA can take a decision on behalf
of the MN? This leads to address several issues such as how does HA know
about the status of the interfaces of the MN, whether HA has the right to
enforce the rules without informing the MN, what is the negotiation to
handle conflicting rules and so on. 

I am not sure whether we should extend MIPv6 to handle above issues.

Regards

Koojana

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 22 May 2009 08:58:48 -0700 (PDT)

Hi Marcelo,
  Pls see my choices below.

Regards,

Behcet

----- Original Message ----
From: marcelo bagnulo braun <marcelo@it..uc3m.es>
To: mext <[email-masked]>
Cc: Jari Arkko <[email-masked]>; Julien Laganier <[email-masked]>
Sent: Wednesday, May 20, 2009 8:04:37 AM
Subject: [MEXT] About the flow binding charter item

Hi,

[behcet] Agreed.

[behcet] I think that the information should be sent both ways. We have currently two drafts one on each, so we progress both of them.
Regarding CoA and or the HA address, some people said HA address was supposed to be the HoA.
I think both drafts are only using CoA. So we should probably go with the CoA.

---

From: Nicolas Montavont <[email-masked]>
Date: Wed, 27 May 2009 17:02:34 +0200

Hi Frank,

> of acounting, mainteance and other reasons.

As said in previous emails in this thread, yes, this is a valid use  
case IMHO.
In the current specification, the HA can refuse to install a flow  
binding when a MN sends a BU with flow binding options. We might need  
to define a way for the HA to cancel a flow binding at anytime. But  
again, this is different from the HA installing rules for the MN.

Nicolas

>
>
> BR
> Frank
>
> ----- Original Message ----- From: "Nicolas Montavont" <[email-masked] 
> >
> Cc: "marcelo bagnulo braun" <[email-masked]>; "mext" <[email-masked] 
> >; "Julien Laganier" <[email-masked]>; "Jari  
> Arkko" <[email-masked]>
>> I disagree: the HA has no way to know about which address is  
>> allocated  to which interface.
>> For me, Flow Binding in MIPv6 should only define the final mapping  
>> of flows on current CoAs. How these policies are set up is out of  
>> scope  of MIPv6. If the HA (or more probably some other entity in  
>> the  network) wants to install rules on the interface usage of a  
>> mobile  node, it can use another protocol that has no reason to be  
>> part of  MIPv6.
>>
>> Nicolas
>>
>>>
>>>

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Wed, 27 May 2009 16:25:55 -0700

Hi Marcelo,

Sorry for the late input due to vacation (yes, we have some vacation also in US :-)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> marcelo bagnulo braun
> Sent: Wednesday, May 20, 2009 6:05 AM
> To: mext
> Cc: Jari Arkko; Julien Laganier

Agree

>From a protocol point of view it would be easy to allow both but from an architectural point of view we need to understand if that makes sense. As already commented there is no other entity in the picture which knows about the current application running in the terminal, the accesses available to the terminal and their status and characteristics, the resources available to the terminal than the terminal itself. The HA cannot know any of those elements which are needed to make a consistent flow routing decision. For this reason I think it should be unidirectional from the MN to HA.

What the network can provide are pseudo-static information about how to use different accesses when they are available based on the environment. This kind of information is usually provided as configuration information and should not be carried over Mobile IP (e.g. OMA-DM is a more suitable protocol to configure such kind of policies in the terminal)

Thanks
Gerardo

---

From: Julien Laganier <[email-masked]>
Date: Thu, 28 May 2009 12:48:22 +0200

Hello,

<with my co-chair hat firmly off>

On Thu, May 28, 2009 at 1:25 AM, Giaretta, Gerardo
<[email-masked]> wrote:
> [...]

+1

> What the network can provide are pseudo-static information about how to use different accesses when they are available based on the environment. This kind of information is usually provided as conf…

I agree with everything Gerardo said above, so no point in repeating
it. I'd like to add one point which in my view is key to this
discussion:

Functionally, the goal of the flow binding mechanism is to bind a
specific flow onto an access whose characteristics  (availability,
bandwidth, RTT, packet loss, etc. etc.) matches best the requirements
of this flow under the constraint of the current MN situation (e.g.
characteristics of the other accesses)

However here in the MEXT WG we are specifying a flow binding mechanism
for Mobile IPv6, and thus the flow binding rules are specified in
terms of CoA choice for a given flow -- they are NOT specified in
terms of which access to choose.

Now on the MN side choosing a CoA equals choosing an access, because
the MN knows onto which access a given CoA is configured. Thus, having
the MN establishing flow binding rules satisfies the goal of the flow
binding mechanism.

But if you look on the HA side, the HA has no idea onto which access
is a given CoA configured. Thus, having the HA establishing flow
binding rules DOES NOT satisfies the goal of the flow binding
mechanism, and is thus essentially useless.

Thus if someone is interested in having the network being in control
of the flow binding mechanism, that can't be done in terms of ruling a
specific CoA choice for a given flow, and thus that is unrelated to
MIPv6, and by derivation to MEXT. I don't know which place would be
more appropriate to tackle that issue, Gerardo mentionned OMA-DM, but
I can also see MIF addressing that sort of issue once they have
concluded the problem space analysis.

Thanks.

--julien