Subject: [MEXT] Call for adoptation of draft-larsson-mext-flow-distribution-rules

From: Conny Larsson <[email-masked]>
Date: Tue, 14 Apr 2009 17:35:30 +0200

Hi,

This is a request to the MEXT working group to adopt 
draft-larsson-mext-flow-distribution-rules to cover the charter item:

(A.3) Use of multiple interfaces.
...
Deliverables related to this include
- 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 status of the working group is that we have a draft 
(http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-12) for 
registration of multiple care-of addresses to one home address.
There exist one draft 
(http://tools.ietf.org/html/draft-ietf-mext-flow-binding-01) for 
transport of the rules that decides how each flow is sent over the 
available network interfaces.

What is currently missing is the part that defines the rules. 
draft-larsson-mext-flow-distribution-rules defines a rule language that 
can be used for this. The document can be found at:

http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules-02

Please express your opinion on whether this should become a WG document.

Regards
Conny

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 14 Apr 2009 17:45:56 +0200

People are of course to comment on this mail, but by no means this is a 
call for adoption of this document since, to the best of my knowledge, 
issuing the call for adoption of a WG document is prerogative of the WG 
chairs

Regards, marcelo

Conny Larsson escribió:
> draft-larsson-mext-flow-distribution-rules defines a rule language 
> that can be used for this. The document can be found at:
>

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 14 Apr 2009 11:56:17 -0400

Hi Marcelo,

I would like you (chairs) to issue the call for adaptation:-)

This document has been discussed as an alternate mechanism of flow  
bindings.
It basically provides flows description rules and very useful in some  
scenarios.

regards,
ryuji

On 2009/04/14, at 11:45, marcelo bagnulo braun wrote:

> People are of course to comment on this mail, but by no means this  
> is a call for adoption of this document since, to the best of my  
> knowledge, issuing the call for adoption of a WG document is  
> prerogative of the WG chairs
>
> Regards, marcelo
>
>
> Conny Larsson escribió:
>> Hi,
>>
>> This is a request to the MEXT working group to adopt draft-larsson- 
>> mext-flow-distribution-rules to cover the charter item:
>>
>> The status of the working group is that we have a draft (http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-12 
>> ) for registration of multiple care-of addresses to one home address.
>> There exist one draft (http://tools.ietf.org/html/draft-ietf-mext-flow-binding-01 
>> ) for transport of the rules that decides how each flow is sent  
>> over the available network interfaces.
>>
>> What is currently missing is the part that defines the rules. draft- 
>> larsson-mext-flow-distribution-rules defines a rule language that  
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 14 Apr 2009 18:06:48 +0200

We have several documents that need to progress. Let us figure out what 
is the right order to handle the different calls and we will issue them.
Regards, marcelo

Ryuji Wakikawa escribió:
>> People are of course to comment on this mail, but by no means this is 
>> a call for adoption of this document since, to the best of my

---

From: George Tsirtsis <[email-masked]>
Date: Tue, 14 Apr 2009 17:08:47 +0100

Hi Conny,

Good to see you are resurrecting this draft. I think we need this as
one of the alternatives. We also need a binary version which I will be
working on with others after I am done updating the Flow Bindings
draft.

Thanks
George

On Tue, Apr 14, 2009 at 4:35 PM, Conny Larsson
<[email-masked]> wrote:
> (http://tools.ietf.org/html/draft-ietf-mext-flow-binding-01) for transport
> of the rules that decides how each flow is sent over the available network
> interfaces.
>
> draft-larsson-mext-flow-distribution-rules defines a rule language that can
> be used for this. The document can be found at:
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 14 Apr 2009 18:12:28 +0200

> working on with others after I am done updating the Flow Bindings

could you expand on this?
I mean, are you saying that we need two ways of describing flows?

Regards, marcelo

---

From: George Tsirtsis <[email-masked]>
Date: Tue, 14 Apr 2009 17:31:41 +0100

Hi Marcelo,

In the Monami6 days, the Flow Bindings draft used to include a binary
Flow Descriptor as part of the FID option.
This was basically a typical fixed length binary format defining a
classifier filterm including source and destination addresses,
protocol number, port numbers, Flow ID, and IPSEC SPI, if I do not
forget something; both IPv4 and IPv6 can be supported with this.

Some people, however, thought that more flexible FDs should be allowed
and Conny's draft describes a text based format which is clearly more
flexible but also more verbose.

At the time, the WG decided that the FD format should be taken out of
the Flow Bindings draft. I am not sure I like that but this is indeed
what happened.
So, now the Flow Bindings draft allows for different FD formats, but
it does not define any of them.

As a minimum, IMO the protocol should define one format as the default
that all implementations MUST support, so that we can have
interoperable implementations.
IMO this should be the binary format which is the most compact and
will work for most of the cases anyway. I do not care too much if this
is defined in the same or on a separate (albeit tightly coupled)
drafts.

It is also ok with me to have other optional formats (like Conny's)
for more advanced use cases.

I hope this helps

George

 Tue, Apr 14, 2009 at 5:12 PM, marcelo bagnulo braun <[email-masked]> wrote:
>>> transport
>>> can

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 14 Apr 2009 18:35:56 +0200

i wonder if we need the advanced features at this point
I mean, we are just defining this, wouldn't make sense to wait and see 
if with the basic procedure is enough and do the extnesions later? Or is 
the basic mechanism so limited that is not enough to handle simple basic 
scenarios? If that is the case, does it makes sense to even define it?

Bottom line, we need strong reasons to do things in multiple different 
ways. Unless clear reasons are described, i fail to see why we should 
standardize multiple approaches

Regards, marcelo

---

From: Conny Larsson <[email-masked]>
Date: Tue, 14 Apr 2009 21:23:46 +0200

Hi Marcelo,

Right. I was not sure about the procedure. The purpose of the mail is to 
get some feedback so that we know how to progress the draft.

So, please comment on the draft and do not pay any attention "to the 
Call for adaptation" stuff. Marcelo and Julien will take care of that if 
we come that far :-) .

/Conny

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 15 Apr 2009 11:13:03 +1100

> This document has been discussed as an alternate mechanism of flow

=> It is not alternate to flow bindings it's complementary.

Hesham

>>> (http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-12
>>> (http://tools.ietf.org/html/draft-ietf-mext-flow-binding-01

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 15 Apr 2009 11:24:07 +1100

The binary description that George referred to covered the majority of use
cases but it doesn't cover, for instance, a filter on the 75th byte in the
packet. Draft-larsson covers those cases and is more generic.
The problem with doing things sequentially is that there are different types
of use cases that can occur from day 1 simultaneously. Use scenarios are not
going to go from basic to advanced over time, they can start with advanced
from day 1 sometimes.

So, the safest option is to go with draft-larsson. But, the counter opinion
here is that I'll be very surprised if organisations like 3GPP who already
have binary filters (and love binary encoding) would want text encoding
because they will likely feel that it's wasteful.

It seems like both are needed but if you have to make something wait, I'd
make the binary stuff wait till someone asks for it. It was in older
versions of the draft and it would be very simple of us to take that out and
put it in a separate draft.

Hesham

> i wonder if we need the advanced features at this point
I mean, we are just
> defining this, wouldn't make sense to wait and see 
if with the basic
> procedure is enough and do the extnesions later? Or is 
the basic mechanism so
> limited that is not enough to handle simple basic 
scenarios? If that is the
> case, does it makes sense to even define it?

Bottom line, we need strong
> reasons to do things in multiple different 
ways. Unless clear reasons are
> described, i fail to see why we should 
standardize multiple
> approaches

Regards, marcelo

George Tsirtsis escribió:
> Hi Marcelo,
>
> In
> the Monami6 days, the Flow Bindings draft used to include a binary
> Flow
> So, now the Flow Bindings
> draft allows for different FD formats, but
>>> Hi
> Conny,
>> I mean, are
> you saying that we need two ways of describing flows?
>>
>> Regards,
> marcelo
>>
>>     
>>> Thanks
>>> George
>>>
>>>> There
> exist one draft
>>>> of the rules that decides how each flow is sent over the
> available
>>>> network
>>>> interfaces.
>>>>

MEXT mailing
> list
[email-masked]

---

From: Xiangsong Cui <[email-masked]>
Date: Wed, 15 Apr 2009 12:13:40 +0800

Hi Larsson,

I think it is a good idea, I have some comments as following:

Firstly, I think it is better to provide a state diagram 
for the connection manager since it relates to the exchange 
and negotiation on flow binding. Maybe the state diagram 
looks like:
                   +---------+                        
                   |  Idle   |------------------------
                   |         |<--                     \
                   +---------+   \                    |  
                        ^         \                   | sending out flow   
                    ??? |          \                  | binding request   
                    ----|           \                 |------------------
                        |            \                |
                        |             \               |
                        |              |              v
              +-------------------+    |       +-------------+
              |     change flow    |    |       |flow binding |  
              |  binding pending  |    |       |   pending   |
              +-------------------+    |       +-------------+
                        ^       |      |              |
    sending out change  |       |      |              |receiving flow
      binding request   |    ?? |      |???           |binding response
     ------------------ |   ----|      |----          |--------------
                        |       |      |              |
                        |       |      |              |
                        |       v      |              |
                         \    +---------------+      /
                          \---| flow binding  |<----/
                              +---------------+

Secondly, there are some inter-operation problems, I think.
For example, when the node, which is multihomed, received the 
command from user to begin some flow with the peer, the node 
do not know whether the peer support the capability. If the 
node use interface A to send packets, while the packets from 
peer maybe come through interface B, how to avoid it happen? 
If the node firstly exchange the information with the peer 
and begin flow later, how about the delay during the procedure?
Or we do not care the issues?
Another example, if the node want to change the flow binding 
from interface A to interface B, when should the node begin to 
send packet through interface B? After sending the request or 
after receiving the response?

I think the solution need more detailed statement.

Regards

Xiangsong

华为技术有限公司  

地址：深圳市龙岗区坂田华为基地 邮编：518129
http://www.huawei.com
-------------------------------------------------------------------------------------------------------------------------------------
本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, which 
is intended only for the person or entity whose address is listed above. Any use of the 
information contained herein in any way (including, but not limited to, total or partial 
disclosure, reproduction, or dissemination) by persons other than the intended 
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by 
phone or email immediately and delete it!

  ----- Original Message ----- 
  From: Conny Larsson 
  To: mext ; marcelo bagnulo ; [email-masked] 
  Sent: Tuesday, April 14, 2009 11:35 PM
  Subject: [MEXT] Call for adoptation ofdraft-larsson-mext-flow-distribution-rules

  Hi,

  Regards
  Conny

---

From: George Tsirtsis <[email-masked]>
Date: Wed, 15 Apr 2009 09:49:13 +0100

Hi Hesham,

I think in fact the binary mechanism can easily be much more flexible
if we want to.

All we have to do it to allow for matching to an "Offset" + "Number of
bytes". The Offset would be a pointer to X number of bytes from the
beginning of the IP header, and then the Number of Bytes, would be the
field that you are trying to match.
This has been used by classifiers for long time now (e.g., Linux, look
for U32 Selector).

In that case, the fixed binary format can cover most of the cases and
also provide a mechanism for matching anything else in the packet,
which makes this really powerful.

Having said that, while I agree with Marcelo that we should only
define what we need, there is little harm in defining additional
optional Flow Description formats, as long as it is clear what is
actually required for interop vs what is optional.

Thoughts?
George

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 15 Apr 2009 11:05:47 +0200

George Tsirtsis escribió:
> optional Flow Description formats,

here is disagree

there is harm and it is in term of energy of the WG and in term of the 
effectiveness of a standard.

as people may have noticed, we do have a problem finding reviews for 
some documents (other documents otoh, get plenty of reviews)
So, i am concerned to disipate energy through multiple documents, and i 
preffer to concentrate the enrgey in a single proposal

the other harm is that having two standards for the same function is 
clearly less optimal than having only one, i guess people will not argue 
against that

(i do understand that the path of less resistance is to get all the 
solutions approved and published, but if we do that, standards are 
meaningless, so i guess it is the chairs role to make that resistance)

So, my take in the general case, is that by default we make only one 
standard for a given function

Which one, it is up to the WG to decide

regards, marcelo

>  as long as it is clear what is
>>>>> Good to see you are resurrecting this draft. I think we need
>>>>>           
>>> this as
>>>       
>>>>> one of the alternatives. We also need a binary version which I
>>>>>           
>>> will be
>>>       
>>>>> working on with others after I am done updating the Flow
>>>>>           
>>> Bindings
>>>       
>>>>> draft.
>>>>>
>>>>>
>>>>>           
>>>>> On Tue, Apr 14, 2009 at 4:35
>>>>>           
>>> PM, Conny Larsson
>>>       
>>>>>> Deliverables
>>> related to this include
>>>>>> - 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
>>>       
>>>>>> The status of the working
>>>>>>             
>>> group is that we have a draft
>>>       
>>>>>> What is currently missing is
>>>>>>             
>>> the part that defines the rules.
>>>       
>>>>>>> Please express your opinion on whether this should become a WG
>>>>>>>               
>>> document.
>>>       
>>>>>> Regards
>>>>>> Conny
>>>>>>
>>>>>>
>>>>>>

---

From: George Tsirtsis <[email-masked]>
Date: Wed, 15 Apr 2009 10:12:15 +0100

OK Marcelo, I see.

I said I am not against multiple solutions in this case because they
are not in direct competition with each other.

I see your point regarding reviews, however, which is a separate issue.

George

On Wed, Apr 15, 2009 at 10:05 AM, marcelo bagnulo braun
<[email-masked]> wrote:
> as people may have noticed, we do have a problem finding reviews for some
> documents (other documents otoh, get plenty of reviews)
> the other harm is that having two standards for the same function is clearly
> less optimal than having only one, i guess people will not argue against
> that
>
>>>> that

---

From: Xiangsong Cui <[email-masked]>
Date: Wed, 15 Apr 2009 17:32:00 +0800

Hi,

> preffer to concentrate the enrgey in a single proposal

=====> I came to IETF recently and I volunteer to works in Work Group.
       I will try to do the job better. :)

regards

Xiangsong

华为技术有限公司  

  ----- Original Message ----- 
  From: marcelo bagnulo braun 
  To: George Tsirtsis 
  Cc: mext ; [email-masked] 
  Sent: Wednesday, April 15, 2009 5:05 PM
  Subject: Re: [MEXT] Call for adoptation ofdraft-larsson-mext-flow-distribution-rules

  here is disagree

  regards, marcelo

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 15 Apr 2009 13:10:29 +0300

In the AAA space we have been working on two formats:

* One format used the ipfw BSD packet filter syntax. See, for example,
IPFilterRule in http://www.rfc-editor.org/rfc/rfc3588.txt.

* A format that is more aligned with the Diameter AVP syntax, see
http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-11.txt

We had discussions about other ideas, including the ability to carry
something like the code understandable for a BPF virtual machine right away.
This would lead to the most compact representation and very likely to the
best performance. 

We did pick the latter because folks didn't really understood how it would
work. Nobody in the DIME group has done such detailed work with packet
filters implementations.   

Ciao
Hannes

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of George Tsirtsis
>Sent: 15 April, 2009 11:49
>To: Hesham Soliman
>Cc: [email-masked]; mext
>Subject: Re: [MEXT] Call for adoptation 
>ofdraft-larsson-mext-flow-distribution-rules
>
>Hi Hesham,
>
>I think in fact the binary mechanism can easily be much more 
>flexible if we want to.
>
>All we have to do it to allow for matching to an "Offset" + 
>"Number of bytes". The Offset would be a pointer to X number 
>of bytes from the beginning of the IP header, and then the 
>Number of Bytes, would be the field that you are trying to match.
>This has been used by classifiers for long time now (e.g., 
>Linux, look for U32 Selector).
>
>In that case, the fixed binary format can cover most of the 
>cases and also provide a mechanism for matching anything else 
>in the packet, which makes this really powerful.
>
>Having said that, while I agree with Marcelo that we should 
>only define what we need, there is little harm in defining 
>additional optional Flow Description formats, as long as it is 
>clear what is actually required for interop vs what is optional.
>
>Thoughts?
>George
>
>> The binary description that George referred to covered the 
>majority of 
>> use cases but it doesn't cover, for instance, a filter on the 75th 
>> byte in the packet. Draft-larsson covers those cases and is 
>more generic.
>> The problem with doing things sequentially is that there are 
>different 
>> types of use cases that can occur from day 1 simultaneously. Use 
>> scenarios are not going to go from basic to advanced over time, they 
>> can start with advanced from day 1 sometimes.
>>
>> So, the safest option is to go with draft-larsson. But, the counter 
>> opinion here is that I'll be very surprised if organisations 
>like 3GPP 
>> who already have binary filters (and love binary encoding) 
>would want 
>> text encoding because they will likely feel that it's wasteful.
>>
>> It seems like both are needed but if you have to make 
>something wait, 
>> I'd make the binary stuff wait till someone asks for it. It was in 
>> older versions of the draft and it would be very simple of 
>us to take 
>> that out and put it in a separate draft.
>>
>> Hesham
>>
>>
>>> Some people, however, thought that more flexible FDs should be 
>>> allowed and Conny's draft describes a text based format which is 
>>> clearly more flexible but also more verbose.
>>>
>>> draft allows for different FD formats, but it does not 
>define any of 
>>> them.
>>>
>>> As a minimum, IMO the protocol should define one format as the 
>>> default that all implementations MUST support, so that we can have
>>>
>>> will work for most of the cases anyway. I do not care too much if 
>>> this is defined in the same or on a separate (albeit tightly
>>> coupled)
>>> drafts.
>>>

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 16 Apr 2009 01:19:28 -0400

Hi Marcelo,

When we have discussed flow management, there are two approaches (one  
is flow binding).
The other approach is to install flow filters statically at the HA and  
MN and switch them according to binding cache.

Let's say MN and HA are statically configured with these three filters  
set. According to binding cache database,
each node switch the filter.

BID1 only -> filter1
BID1 and BID2 -> filter2
BID2 only -> filter3

Flow binding has advantages on dynamic updates, but, on the other  
hand, some operators (let's say KDDI) prefer using
more stable filter. The operator ships the terminal with pre-defined  
filter rules. The dynamic management leads certain overhead, too.
That' why we have this Conny's document.
AFAIK, this document does not specify any transport mechanism, but  
define only syntax of filters.

Of course, you might use SSL, HTTPs, even flow binding (as George  
said), and any other mechanism to exchange these filters (if you want  
dynamic filters exchange).
To define a general filter syntax is very useful. This can be  
targetted to informational or experimental RFC.

thanks
ryuji

On 2009/04/14, at 12:35, marcelo bagnulo braun wrote:

> I mean, we are just defining this, wouldn't make sense to wait and  
> see if with the basic procedure is enough and do the extnesions  
> later? Or is the basic mechanism so limited that is not enough to  
> handle simple basic scenarios? If that is the case, does it makes  
> sense to even define it?
>
> Bottom line, we need strong reasons to do things in multiple  
> different ways. Unless clear reasons are described, i fail to see  
> why we should standardize multiple approaches
>
> Regards, marcelo
>
>
>
>> allowed
>> default
>> this
>> Tue, Apr 14, 2009 at 5:12 PM, marcelo bagnulo braun <[email-masked] 
>> > wrote:
>>

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 16 Apr 2009 01:22:51 -0400

Hi George,

> it does not define any of them.

Ok, I didn't know this change. The current flow binding document  
haven't followed this decision yet?!

regards,
ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 16 Apr 2009 01:31:11 -0400

Hi Hannes,

I think what we have discussed now in MEXT is a bit similar to this  
case.

The Conny's draft is originally inspired from IPFW, which is most used  
filter description and stable.
The operator has certain experiences of using IPFW with operational  
knowhow (for different purpose than multihoming, firewall setting etc).

Since Conny's draft does not define transport mechanisms, we will not  
have two "protocols" to do same things.
We will have just multiple filter syntax.

regards,
ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 16 Apr 2009 01:36:03 -0400

Hi Marcelo,

I agree with you that the WG interests are hard to control. I had some  
experience of that;-p

Regarding this document, it introduces filter's syntax based on  
existing syntax set and is small document.

You can probably start call for adaptation and see how many people is  
interested in this document.
Just suggestion;-)

ryuji

On 2009/04/15, at 5:05, marcelo bagnulo braun wrote:

> there is harm and it is in term of energy of the WG and in term of  
> the effectiveness of a standard.
>
> So, i am concerned to disipate energy through multiple documents,  
> and i preffer to concentrate the enrgey in a single proposal
>
> clearly less optimal than having only one, i guess people will not  
> argue against that
>
>>> majority of use
>>> different types

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 16 Apr 2009 18:06:06 +0200

now i am lost, i understood that we had two ways to dynamically confgure 
filters, binary and conny's draft and that's what we were discussing... 
didn't thought that it was static versus dynamic configuration of 
filters...so what is it?

Ryuji Wakikawa escribió:
>> different ways. Unless clear reasons are described, i fail to see why 
>> we should standardize multiple approaches
>>
>> Regards, marcelo
>>
>>
>>

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 16 Apr 2009 14:04:23 -0400

Hi Marcelo,

Well, you are not lost, but I was actually lost.
After reading the spec, they changed the draft a lot since I  
contributed to..
I asked Tasaka (KDDI guy) to explain the position of this draft.

thanks
ryuji

On 2009/04/16, at 12:06, marcelo bagnulo braun wrote:

> now i am lost, i understood that we had two ways to dynamically  
> confgure filters, binary and conny's draft and that's what we were  
> discussing... didn't thought that it was static versus dynamic  
> configuration of filters...so what is it?
>
>
> Ryuji Wakikawa escribió:
>> Hi Marcelo,
>>
>> When we have discussed flow management, there are two approaches  
>> (one is flow binding).
>> The other approach is to install flow filters statically at the HA  
>> and MN and switch them according to binding cache.
>>
>> Let's say MN and HA are statically configured with these three  
>> filters set. According to binding cache database,
>> more stable filter. The operator ships the terminal with pre- 
>> defined filter rules. The dynamic management leads certain  
>> overhead, too.
>> said), and any other mechanism to exchange these filters (if you  
>> want dynamic filters exchange).

---

From: Kazuyuki Tasaka <[email-masked]>
Date: Fri, 17 Apr 2009 04:06:40 +0900

Hi Marcelo and Ryuji,

Conny's document only defines generic rule language as a mean to
define and perform per flow path selection for a multi-homed node.
I think this document can provide static and dynamic configuration of
filters.
Flow filters are installed statically at the HA and MN. On the other
hands, in case of dynamic configuration, this document depends on
the transport protocol (e.g. flow bindings) to exchange flow filters
with other nodes . But the transport protocol is outside the scope of
this document and generic rule languages to statically and dynamically
configure are difined.

Regards, tasaka.

Ryuji Wakikawa Wrote:
> After reading the spec, they changed the draft a lot since I contributed 
> to..

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 16 Apr 2009 21:18:58 +0200

Right, i understand that the transport of these rules is done using 
draft-ietf-mext-flow-binding, right?

so what we need to agree next is what encoding we use to specify a flow, 
either the one or larson draft or the binary encoding (or maybe both, 
but strong reasons would be needed for that imho)

Kazuyuki Tasaka escribió:
>>>> more stable filter. The operator ships the terminal with 
>>>> pre-defined filter rules. The dynamic management leads certain 
>>>> overhead, too.

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 16 Apr 2009 15:26:12 -0400

Hi Marcelo and Tasaka,

> draft-ietf-mext-flow-binding, right?

The flow binding is just one of transport protocol to carry the rules.

This document deals with rules syntax and is independent from the flow  
binding.
Anyone can pick any transport protocol to exchange these rules or can  
install the filters with out any dynamic exchange.

regards,
ryuji

> so what we need to agree next is what encoding we use to specify a  
> flow, either the one or larson draft or the binary encoding (or  
> maybe both, but strong reasons would be needed for that imho)
>
>
>>>> confgure filters, binary and conny's draft and that's what we  
>>>> were discussing... didn't thought that it was static versus  
>>>> dynamic configuration of filters...so what is it?
>>>>
>>>>
>>>> Ryuji Wakikawa escribió:
>>>>> Hi Marcelo,
>>>>>
>>>>> The other approach is to install flow filters statically at the  
>>>>> HA and MN and switch them according to binding cache.
>>>>>
>>>>> Flow binding has advantages on dynamic updates, but, on the  
>>>>> other hand, some operators (let's say KDDI) prefer using
>>>>> AFAIK, this document does not specify any transport mechanism,  
>>>>> but define only syntax of filters.
>>>>>
>>>>> Of course, you might use SSL, HTTPs, even flow binding (as  
>>>>> George said), and any other mechanism to exchange these filters  
>>>>> (if you want dynamic filters exchange).
>>>>>> I mean, we are just defining this, wouldn't make sense to wait  
>>>>>> and see if with the basic procedure is enough and do the  
>>>>>> extnesions later? Or is the basic mechanism so limited that is  
>>>>>> not enough to handle simple basic scenarios? If that is the  
>>>>>> different ways. Unless clear reasons are described, i fail to  
>>>>>> see why we should standardize multiple approaches
>>>>>>
>>>>>> Regards, marcelo
>>>>>>
>>>>>>
>>>>>>

---

From: George Tsirtsis <[email-masked]>
Date: Thu, 16 Apr 2009 20:33:15 +0100

Ryuji,

I know we have been saying this for a while now but I am not sure to
what extend it holds water. If you want an out of band mechanism for
controlling filters in a box there are specific protocols for that
kind of thing e.g., MIDCOM, and they define the whole thing, including
encoding and transport.

As I said before, I am not against having multiple flow description
necodings for Flow Bindings, but the generality argument is a bit of a
stretch IMHO.

Regards
George

On Thu, Apr 16, 2009 at 8:26 PM, Ryuji Wakikawa
<[email-masked]> wrote:
>> either the one or larson draft or the binary encoding (or maybe both, but
>> strong reasons would be needed for that imho)
>>
>>
>>>>> discussing... didn't thought that it was static versus dynamic configuration
>>>>> of filters...so what is it?
>>>>>
>>>>>
>>>>> Ryuji Wakikawa escribió:
>>>>>>
>>>>>> Hi Marcelo,
>>>>>>
>>>>>>> see if with the basic procedure is enough and do the extnesions later? Or is
>>>>>>> different ways. Unless clear reasons are described, i fail to see why we
>>>>>>> should standardize multiple approaches
>>>>>>>
>>>>>>> Regards, marcelo
>>>>>>>
>>>>>>>
>>>>>>>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 16 Apr 2009 21:38:39 +0200

> install the filters with out any dynamic exchange.
right

>> flow, either the one or larson draft or the binary encoding (or maybe 
>> both, but strong reasons would be needed for that imho)
>>
>>

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 17 Apr 2009 10:33:40 +1100

> Hi Marcelo and Ryuji,

Conny's document only defines generic rule language as
> a mean to
I
> think this document can provide static and dynamic configuration
> of
filters.
Flow filters are installed statically at the HA and MN.

=> Which drafts are you talking about? Are you talkig about this WG's
documents and charter or something that you would like to have? None of this
is in the WG docs or charter. We don't have static rules and draft-larsson
is not about filter installation, that's done in the flow bindings draft.

I find this thread very confusing, please read the drafts in question!

Hesham

On the 
> other
> transport protocol (e.g. flow bindings) to exchange flow filters
with other
> nodes . But the transport protocol is outside the scope of
this document and
> generic rule languages to statically and dynamically
configure are
> difined.

Regards, tasaka.

Ryuji Wakikawa Wrote:
>> Ryuji Wakikawa
> escribió:
>>> The other approach is
> to install flow filters statically at the HA 
>>> and MN and switch them
>>> Flow binding has
> advantages on dynamic updates, but, on the other 
>>> hand, some operators
>>> AFAIK,
> this document does not specify any transport mechanism, but 
>>> define only
> syntax of filters.
>>>
>>> To define a general
> filter syntax is very useful. This can be 
> reasons to do things in multiple 
>>>> George Tsirtsis
> escribió:
>>>>> So, now the
> Flow Bindings draft allows for different FD formats, but
>>>>> it does not
> define any of them.
>>>>>
>>>>> IMO this should be the
> binary format which is the most compact and
>>>>> will work for most of the
> cases anyway. I do not care too much if this
>>>>> It is also ok
> with me to have other optional formats (like Conny's)
>>>>> for more advanced
> use cases.
>>>>>
>>>>> I hope this helps
>>>>>
>>>>> George
>>>>>
>>>>> Tue,
> Apr 14, 2009 at 5:12 PM, marcelo bagnulo braun 
>>>>> <[email-masked]>
> wrote:
>>>>>
>>>>>> could you
> expand on this?
>>>>>>>> draft-larsson-mext-flow-distribution-rules to cover the charter
> 
>>>>>>>> item:
>>>>>>>>
>>>>>>>> - 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
>>>>>>>> What is
> currently missing is the part that defines the rules.
>>>>>>>>

_________________________________
> ______________
MEXT mailing
[email-masked]

---

From: Kazuyuki Tasaka <[email-masked]>
Date: Fri, 17 Apr 2009 13:42:10 +0900

Hi Hesham,

> is not about filter installation, that's done in the flow bindings draft.

I taked about the position of draft-larsson.
But, there was a lack of talk.
This is one use case of filter rules defined in draft-larsson.
For example, when some operators prefer using more stable filter,
operator ships the terminal with pre-defined filter rules.

Regards, tasaka.

---

From: Ryuji Wakikawa <[email-masked]>
Date: Fri, 17 Apr 2009 00:50:19 -0400

Hi George,

I mean once we define a common syntax, operator can pick any transport  
mechanism as they wish.
The transport mechanism will not be discussed in MEXT.
Well if they statically configure the filters,  we don't need any  
transport mechanism:-)

regards,
ryuij

On 2009/04/16, at 15:33, George Tsirtsis wrote:

>>> flow,
>>>>> contributed
>>>>>> were
>>>>>>> filters
>>>>>>> defined
>>>>>>>>> and Conny's draft describes a text based format which is  
>>>>>>>>> clearly
>>>>>>>>> more
>>>>>>>>> At the time, the WG decided that the FD format should be  
>>>>>>>>> taken out
>>>>>>>>> of
>>>>>>>>>>> Good to see you are resurrecting this draft. I think we  
>>>>>>>>>>> need this
>>>>>>>>>>> as
>>>>>>>>>>>> policies from the mobile host/router to the Home Agent  
>>>>>>>>>>>> and from
>>>>>>>>>>>> the
>>>>>>>>>>>> )
>>>>>>>>>>>> for

---

From: Ryuji Wakikawa <[email-masked]>
Date: Fri, 17 Apr 2009 00:53:36 -0400

> documents and charter or something that you would like to have? None  

Conny's draft.

The Charter clearly mentioned the policy format.

> is not about filter installation, that's done in the flow bindings  

If it is static, we need neither a transport protocol nor dynamic  
installation .
As you pointed out, the Conny's draft is not discussed any alternative  
transport mechanism.

regards,
ryuji

>> need this as

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 17 Apr 2009 14:54:01 +1100

> operator ships the terminal with pre-defined filter rules.

=> I don't think it makes sense for someone to have predefined filters
because the interface selection, by nature, is a dynamic and iterative
process. Anyway, people can do what they like in their networks but the
discussion in this WG, based on it's charter, is related to producing two
docs:
1. Flow bindings. This is a WG draft
2. Filter description. Draft-larsson does that

So please be clear in the discussion on whether you want to add a new
charter item or you're discussing the current drafts, because the current
drafts don't do what you're talking about and it's confusing to have this
discussion on a thread about the current drafts.

Hesham

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 17 Apr 2009 14:57:15 +1100

>> documents and charter or something that you would like to have? None

=> It doesn't talk about static and dynamic, and it shouldn't! It's about
filter descriptions.

> transport [both Standard Track].

=> Yes I read it.

> As you pointed out, the Conny's draft is not discussed any alternative

=> Exactly, so can we please keep this thread about the drafts in question
instead of losing track by adding unrelated topics? If you want to
statically define things (very strange but it's up to you) that's fine, but
this is not what we're doing in this WG.

Hesham

---

From: Ryuji Wakikawa <[email-masked]>
Date: Fri, 17 Apr 2009 01:04:51 -0400

> this is not what we're doing in this WG.

There is use-case and one operator shows their interests, even though  
you feel it's  strange.

What we have discussed here is the need of this document.
Why not discussing the use case of this document?  It's related to the  
topic.
This discussion will help to see certain motivation to have separate  
document for filters syntax.

ryuji

>>>>>>>> This was basically a typical fixed length binary format  
>>>>>>>> defining
>>>> a

---

From: Kazuyuki Tasaka <[email-masked]>
Date: Fri, 17 Apr 2009 14:09:19 +0900

Hi Hesham,

> discussion on a thread about the current drafts.

I'm one of authors of draft-larsson. I don't talk about
a new charter item and want discuss filter descriptions of
the current drafts.

Regards, tasaka

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 17 Apr 2009 15:18:18 +1100

> Why not discussing the use case of this document?  It's related to the

=> What is the impact of the scenario you want to support on this doc
(draft-larsson)? I mean is there anything that needs to be changed in the
draft for this?
I find it confusing because you started off saying that this document is an
alternate solution to flow bindings, which is not true according to the
charter, then you said nothing needs to be done in MEXT to support your
scenario. So why are we having this discussion on this thread?

> document for filters syntax.

=> It's 2 years late to have this discussion then! We agreed on a separate
draft (draft-larsson) 2 years ago....

Hesham

---

From: Ryuji Wakikawa <[email-masked]>
Date: Fri, 17 Apr 2009 01:32:20 -0400

> (draft-larsson)? I mean is there anything that needs to be changed  

actually none.

> scenario. So why are we having this discussion on this thread?

I stated why I support this document.

> draft (draft-larsson) 2 years ago....

But unfortunately this document it not yet WG document in these two  
years.
MEXT should work on this item if we have agreement !

ryuji

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 17 Apr 2009 15:50:02 +1100

>> (draft-larsson)? I mean is there anything that needs to be changed

=> great, that's why I was confused about the reason of this discussion.

> But unfortunately this document it not yet WG document in these two

=> Ah, that's because the document expired and was not re-submitted with the
changes we agreed on and therefore it's hard to make it a WG doc.

Hesham

---

From: Conny Larsson <[email-masked]>
Date: Fri, 17 Apr 2009 09:37:13 +0200

Hi Xiangsong,

Xiangsong Cui wrote:
> ï»¿
>                         ^         \                   | sending out 
> flow  
The purpose with the draft is to define the rule language to be used for 
creating routing rules. Section 3 "Conceptual Model" was added to 
highlight the difference between policies and routing rules. The exact 
behavior of the "Connection Manager" is outside the scope of the draft 
and so would the state diagram be.
> after receiving the response?
Very good questions and they definitely have to be outlined. I believe 
the issues you brought up here should be outlined in Hesham's draft, 
which defines how the Routing Rules are transported from the MN to the 
HA/CN. This draft should explain the procedure in the MN/HA/CN when the 
Routing Rules are accepted/not accepted, i.e., when to start sending 
traffic using the new Routing Rules.

Thanks for your review.

Regards
Conny Larsson
> å?Z(ä¸ºæS(EURæoe¯æoe0/00é^(TM)?å...¬å?¸ huawei_logo
> åoe°å?EURï¼s(æ·±åoe³å¸,é¾^(TM)å²---åOEºå?,ç"°å?Z(ä¸ºåY"ºåoe° 
> é,®ç¼--ï¼s(518129
> http://www.huawei.com
> æoeé,®ä»¶å?S(å...¶é^(TM)"ä»¶å?«æoe0/00å?Z(ä¸ºå...¬å?¸çs("ä¿?å¯+ä¿¡æ?¯ï¼OEä»...é^(TM)?äºZ(å?'éEUR?ç»^(TM)ä¸S(é?¢åoe°å?EURä¸­å^---å++ºçs("ä¸ªäººæ^--ç¾¤ç»"ãEUR,ç¦?
> æ­¢ä»»ä½.å...¶ä»--äººä»¥ä»»ä½.å½¢å¼?ä½¿ç"¨ï¼^åOE...æ<¬ä½+ä¸?é^(TM)?äºZ(å...¨éf¨æ^--éf¨å^+åoe°æ³"éoe²ãEUR?å¤?å^¶ãEUR?æ^--æ.£å?'ï¼0/00æoe¬é,®ä»¶ä¸­
> çs("ä¿¡æ?¯ãEUR,å¦,æz(oeæ,¨é"^(TM)æ"¶äº+æoe¬é,®ä»¶ï¼OEè¯·æ,¨ç«<å?³ç"µè¯?æ^--é,®ä»¶éEURs(çY"¥å?'ä»¶äººå¹¶å^ é^(TM)¤æoe¬é,®ä»¶ï¼?
>     *From:* Conny Larsson <mailto:[email-masked]>
>     *To:* mext <mailto:[email-masked]> ; marcelo bagnulo
>     <mailto:[email-masked]> ; [email-masked]
>     <mailto:[email-masked]>
>     *Sent:* Tuesday, April 14, 2009 11:35 PM
>     *Subject:* [MEXT] Call for adoptation
>     [email-masked] <mailto:[email-masked]>

---

From: Xiangsong Cui <[email-masked]>
Date: Fri, 17 Apr 2009 17:49:02 +0800

> Very good questions and they definitely have to be outlined. I believe the issues you brought up here should be 
> outlined in Hesham's draft, which defines how the Routing Rules are transported from the MN to the HA/CN. This draft
> should ? explain the procedure in the MN/HA/CN when the Routing Rules are accepted/not accepted, i.e., when to start 
> sending traffic using the new Routing Rules.

Thank you, I understand the relation between the two drafts after I have read Hesham's draft.

I just want to say, IMO, it is better to provide a thorough solution.

Regards
Xiangsong

华为技术有限公司  

  ----- Original Message ----- 
  From: Conny Larsson 
  To: Xiangsong Cui 
  Cc: mext ; marcelo bagnulo ; [email-masked] 
  Sent: Friday, April 17, 2009 3:37 PM
  Subject: Re: [MEXT] Call for adoptation ofdraft-larsson-mext-flow-distribution-rules

  Hi Xiangsong,

  Xiangsong Cui wrote: 
    ï»¿ 
    Hi Larsson,

  The purpose with the draft is to define the rule language to be used for creating routing rules. Section 3 "Conceptual Model" was added to highlight the difference between policies and routing rules. The exact behavior of the "Connection Manager" is outside the scope of the draft and so would the state diagram be.

  Very good questions and they definitely have to be outlined. I believe the issues you brought up here should be outlined in Hesham's draft, which defines how the Routing Rules are transported from the MN to the HA/CN. This draft should explain the procedure in the MN/HA/CN when the Routing Rules are accepted/not accepted, i.e., when to start sending traffic using the new Routing Rules.

  Thanks for your review.

  Regards
  Conny Larsson

    Regards

    Xiangsong
    åŽä¸ºæŠ€æœ¯æœ‰é™å…¬å¸  
    åœ°å€ï¼šæ·±åœ³å¸‚é¾™å²—åŒºå‚ç”°åŽä¸ºåŸºåœ° é‚®ç¼–ï¼š518129
    http://www.huawei.com
    -------------------------------------------------------------------------------------------------------------------------------------
    æœ¬é‚®ä»¶åŠå…¶é™„ä»¶å«æœ‰åŽä¸ºå…¬å¸çš„ä¿å¯†ä¿¡æ¯ï¼Œä»…é™äºŽå‘é€ç»™ä¸Šé¢åœ°å€ä¸­åˆ—å‡ºçš„ä¸ªäººæˆ–ç¾¤ç»„ã€‚ç¦
    æ­¢ä»»ä½•å…¶ä»–äººä»¥ä»»ä½•å½¢å¼ä½¿ç”¨ï¼ˆåŒ…æ‹¬ä½†ä¸é™äºŽå…¨éƒ¨æˆ–éƒ¨åˆ†åœ°æ³„éœ²ã€å¤åˆ¶ã€æˆ–æ•£å‘ï¼‰æœ¬é‚®ä»¶ä¸­
    çš„ä¿¡æ¯ã€‚å¦‚æžœæ‚¨é”™æ”¶äº†æœ¬é‚®ä»¶ï¼Œè¯·æ‚¨ç«‹å³ç”µè¯æˆ–é‚®ä»¶é€šçŸ¥å‘ä»¶äººå¹¶åˆ é™¤æœ¬é‚®ä»¶ï¼
    This e-mail and its attachments contain confidential information from HUAWEI, which 
    is intended only for the person or entity whose address is listed above. Any use of the 
    information contained herein in any way (including, but not limited to, total or partial 
    disclosure, reproduction, or dissemination) by persons other than the intended 
    recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by 
    phone or email immediately and delete it!

      ----- Original Message ----- 
      From: Conny Larsson 
      To: mext ; marcelo bagnulo ; [email-masked] 
      Sent: Tuesday, April 14, 2009 11:35 PM
      Subject: [MEXT] Call for adoptation ofdraft-larsson-mext-flow-distribution-rules

      Hi,

      Regards
      Conny

---

From: Conny Larsson <[email-masked]>
Date: Fri, 17 Apr 2009 13:21:29 +0200

Hi Tasaka,

Yes you are right, both static and dynamic configuration of filters are 
supported. In section 5.3 "Conditional Rule-Sets" there is an example of 
how a static configuration of the rules can be used.

Regards
Conny

Kazuyuki Tasaka wrote:
>>> Ryuji Wakikawa escribiÃ³:
>>>> Hi Marcelo,
>>>>
>>>>> George Tsirtsis escribiÃ³:
>>>>>> Hi Marcelo,
>>>>>>
>>>>>>> George Tsirtsis escribiÃ³:
>>>>>>>
>>>>>>>> Hi Conny,
>>>>>>>>