Subject: Re: [Monami6] consensus call on draft-soliman-monami6-flow-binding-04.txt

From: Kazuyuki Tasaka <[email-masked]>
Date: Sun, 02 Sep 2007 11:25:47 +0900

Dear All

I agree this solution as one solution for the trasport of flow filters.

On the other hand, when thinking about a generic solution for the
transport, I think we also need to consider a use case for the transport
of flow filters from HA to MN/MR.

For example, there is a case that an administrator of HA such as
a network operator wants to modify flow filters of MN/MR for
network congestion control.

What do you think about this case?

regards,
Kazuyuki

Thierry Ernst Wrote:
> 
> Dear all,
> 
> On Aug. 2, we asked for consensus to confirm the acceptance of
> draft-soliman-monami6-flow-binding-04.txt as MonAmi6 WG item for the
> transport of flow filters (4th working group item on the charter). This 
> is a  confirmation of the positive show of hands during the last IETF 
> meeting in Chicago (see the MonAmi6 minutes)
> 
> Since then we got (only) one feedback from Koshiro Mitsuya who disagrees 
> on this decision to accept this personal draft as a WG document (see his 
> comments early August on this thread).
> 
> Note that during the discussion we had at IETF 68, we agreed that the 
> Monami6 WG would define a solution which transports the filter rules 
> within the mobility messages, especially to re-use the security 
> association between the MN and its HA. Only draft-soliman meets this 
> agreement.
> 
> So, unless other people express themselves on this list in the next few
> days (thus, people who where on vacation in August still have the
> opportunity to express their opinion), I think it's reasonable to say 
> that we have rough consensus to 
> adoptdraft-soliman-monami6-flow-binding-04.txt as WG document.
> 
> That document would then still be in a draft state and any input to 
> improve the solution would be welcomed.
> 
> Regards,
> MonAmi6 WG Chairs Nicolas Montavont & Thierry Ernst
> 
> 
> 
> Nicolas Montavont wrote:
>> During the meeting, chairs asked the attendees if
>>
>> draft-soliman-monami6-flow-binding-04.txt
>>
>> shall be accepted for the transport of the policies as described in 
>> the 4th WG 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 the policy format and another for its 
>> transport [both Standard Track]
>>
>> To this question, nobody voted against at the last Monami6 meeting. 
>> So, we would like to confirm this decision on the ML.
>>
>> If you have a specific concern with this decision, please express your 
>> views until 12:01 am UTC Thursday, August the 16th, 2007
>>
>> Regards,
>> the chairs
>>
>> _______________________________________________
>> Monami6 mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/monami6
>>
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Monami6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/monami6
> 
> 

_______________________________________________
Monami6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/monami6

---

From: Nicolas Montavont <[email-masked]>
Date: Tue, 4 Sep 2007 15:56:41 +0200

Hi Kazuyuki,

> What do you think about this case?

I think this is a valid case, and as you said this is more generic.
draft-flow-binding "only" allows policies enforcement: the MR being  
the only one to know the mapping between its CoA and its interfaces,  
draft-flow-binding allows the MR to indicate to the HA how to  
distribute flows on several CoAs.

Of course, how to set up the policies on the MR is out of scope of  
draft-flow-binding, even from Monami6 (as for now). You can think of  
a manual configuration directly on the MR, or you can consider that  
an external entity, such as the HA or another entity in the network,  
decides how the MR should use its interfaces. In case the policies  
are issued by something else than the MR, these policies need to be  
installed on the MR, and a (generic) protocol could be defined here.  
Just to make sure I am clear, here is a drawing of what I am discussing:

Decision entity             <-------------------------->             MR
Establish the policies     Generic protocol      Configure the policies
                                            to install policies        
Map the policies to CoAs
                                                                         
                       |
                                                                         
                       |   draft-flow-binding
                                                                         
                       |
                                                                         
                       |
                                                                         
                      HA
                                                                   
Distribute the traffic on CoAs

Nicolas

>> transport of flow filters (4th working group item on the charter).  
>> This is a  confirmation of the positive show of hands during the  
>> last IETF meeting in Chicago (see the MonAmi6 minutes)
>> Since then we got (only) one feedback from Koshiro Mitsuya who  
>> disagrees on this decision to accept this personal draft as a WG  
>> document (see his comments early August on this thread).
>> Note that during the discussion we had at IETF 68, we agreed that  
>> the Monami6 WG would define a solution which transports the filter  
>> rules within the mobility messages, especially to re-use the  
>> security association between the MN and its HA. Only draft-soliman  
>> meets this agreement.
>> opportunity to express their opinion), I think it's reasonable to  
>> say that we have rough consensus to adoptdraft-soliman-monami6- 
>> flow-binding-04.txt as WG document.
>> That document would then still be in a draft state and any input  
>> to improve the solution would be welcomed.
>> Regards,
>>> shall be accepted for the transport of the policies as described  
>>> in the 4th WG item
>>>
>>> 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]
>>>
>>> To this question, nobody voted against at the last Monami6  
>>> meeting. So, we would like to confirm this decision on the ML.
>>>
>>> If you have a specific concern with this decision, please express  
>>> your views until 12:01 am UTC Thursday, August the 16th, 2007
>>>
>>> Regards,
>>> the chairs
>>>

---

From: Kazuyuki Tasaka <[email-masked]>
Date: Fri, 07 Sep 2007 21:13:40 +0900

Hi Nicolas,

Thank you for your comments.

Nicolas Montavont Wrote:
> draft-flow-binding "only" allows policies enforcement: the MR being the 
> only one to know the mapping between its CoA and its interfaces, 
> draft-flow-binding allows the MR to indicate to the HA how to distribute 
> flows on several CoAs.

That's right.

> draft-flow-binding, even from Monami6 (as for now). You can think of a 
> manual configuration directly on the MR, or you can consider that an 
> external entity, such as the HA or another entity in the network, 
> decides how the MR should use its interfaces. In case the policies are 
> issued by something else than the MR, these policies need to be 
>                                            to install policies       Map 
> the policies to CoAs

Thank you for the clarification.

When considering more generic protocol to transport policies in this WG,
we can define other protocol different from draft-flow-binding.
Therefore, I think that we need more discussion about the transport of
policies (flow filters) before accepting draft-flow-binding in current
version as MonAmi6 WG document.

In this connection, the following document considers to set up
the policies on the local hosts and the policies on the MR from HA,
and defines Policy Data Set.

http://tools.ietf.org/id/draft-mitsuya-monami6-flow-distribution-policy-04.txt

However, this document defines only policy data set and doesn't define
the transport protocol.

I think that we need to define generic transport protocol in
the document such as draft-flow-binding as WG document,
and define common filter rules and processing when receiving of
filter rules in the document such as draft-flow-distribution-policy
as WG document.

Do you have any comments?

regards,
Kazuyuki

>>> This is a  confirmation of the positive show of hands during the last 
>>> IETF meeting in Chicago (see the MonAmi6 minutes)

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 7 Sep 2007 22:30:31 +1000

> version as MonAmi6 WG document.

=> We've already discussed the generic Vs MIPv6-specific protocol issue. I
don't think we need to discuss it again since nothing new came up.

The point you raised is quite valid but is independent from the problem
solved by draft-soliman as Nicolas already explained. The point you raise is
"how does the MN know the policy?" Is it possible for the HA to tell the MN
what the policies should be? is it manually configured? is it dependent on a
generic algorithm? user configured? or all of the above? 
I suspect it will be all of the above. You could argue for the need for a
framework to handle this issue or even a protocol, but this is independent
from the need for the MN to *tell* the HA that it should enable forwarding
in a certain manner. These are two different problems and I don't think we
need to hold one protocol for another when there is no dependency. 

Hesham

---

From: Conny Larsson <[email-masked]>
Date: Tue, 11 Sep 2007 16:13:06 +0200

Hi Nicolas, Hesham

I'm not happy with the way the filter format is being defined in 
draft-soliman-monami6-flow-binding-03.txt. However, I have not been able 
to find the latest version (the one that the consensus call is being 
made on). Could anyone of you send me the file so that I can read the 
latest version?

In general I can accept the transport defined in draft-soliman (if the 
filter format is defined in a separate draft). I know that other persons 
have expressed their view on the shortcomings (no support for network 
initiated filter transport) of this transport protocol. However, as long 
as the filter format is generic we could always come up with additional 
transport protocol proposals when needed.

Regards
Conny

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 12 Sep 2007 00:54:47 +1000

Hi Conny, 

We agreed in the last meeting that only the transport is going to be defined
in draft-soliman, so the filter format is going to be removed. I believe
this concensus call assumes that draft-soliman will not contain filter
formats in the WG revision. 

Hesham 

 > -----Original Message-----
 > From: Conny Larsson [mailto:[email-masked]] 
 > Sent: Wednesday, September 12, 2007 12:13 AM
 > To: Monami6 WG; Hesham Soliman; [email-masked]
 > Subject: Re: [Monami6] consensus call on 
 > meeting.

---

From: Kazuyuki Tasaka <[email-masked]>
Date: Wed, 12 Sep 2007 01:44:23 +0900

Hi, Hesham

Sorry for the late reply.
Please see comment inline.

> don't think we need to discuss it again since nothing new came up.

I agree that draft-soliman is the generic Vs MIPv6-specific protocol.

> need to hold one protocol for another when there is no dependency. 

The point of my comment is there may be at least two draft about
transport protocl in the future.
If this is less of a problem and the case I raised is future work,
I agree that draft-soliman is accepted as WG draft.

regards,
Kazuyuki

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 12 Sep 2007 11:57:48 +1000

Just one clarification.

 > transport protocl in the future.

=> To be more accurate, you want to have a draft about the transfer of
*policies* in addition to the solution in draft-soliman. These are two
different solutions that can co-exist because draft-soliman doesn't transfer
policies, it transfers *filter rules*. 

Hesham

---

From: Kazuyuki Tasaka <[email-masked]>
Date: Thu, 13 Sep 2007 23:47:51 +0900

Hi, Hesham

Thank you for your clarification.

 > different solutions that can co-exist because draft-soliman doesn't
 > transfer policies, it transfers *filter rules*.

I agree.
I have no idea about the generic transport protocol of *policies* from
MN/MR to HA and from HA to MN/MR yet. However, I consider its data set
in draft-mitsuya and I would like to hear from everyone about it.

regards,
Kazuyuki

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Fri, 14 Sep 2007 18:16:08 +0900

Hi Hesham

Can you explain how will you remove the filter format from the spec?
Are you going to remove the filter format of the flow identification  
option?

thanks
ryuji

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Fri, 14 Sep 2007 19:19:51 +0900

Hi Thierry and Hesham

Sorry for my late comments...

I think the draft-flow-binding provides two functionalities
1. coupling FID and flow (formats)
2. registering filters with FID and BID
If the previous Hesham mail to Conny implies that this document
removes the function-1, we need a document for the generic format.
However, the current draft-hesham still has filters description, I  
want to see
the latest document updated after the last IETF.

I have one suggestion.
Since the FID option is mobility option, the authors should consider
the use of Mobility Header Signaling Messages.
draft-haley-mip6-mh-signaling-02.txt (This document was already
approved as a MIP6 WG document).
The two reasons:
1. HA can signal filters to MNs!
2. The use of BU is most efficient way (the event of filter rules
changes are often caused by the movement, i.e. BU), but this is
not only events when MN changes the filters. I personally think
MN should avoid sending BU for other purpose than the binding  
registration.

Next comment is that this document requires for MN to maintain filter
rules in BC and BUL.  This should be up to implementation. The BID
itself can point to specific BC or BUL.  No reason to keep the FID and
flow information in the BC or BUL.
For example, an implementation of HA can manage the sets of FID and
BID in the flow database.  HA first compares the incoming packets with
the flow database and acquires the corresponding BID.  Then, HA can
look for the desired binding which matched with BID and HoA.

Another comment is whether we really need n-cast or not. The document
supports n-cast only for HA, but I am not sure we really need this.

Authors also needs some editorial updates.
For example, in section4.2, the draft said
"   This specification extends the binding cache and the binding update
    list structures, and allows mobile node to (1) register multiple
    care-of addresses for a given home address and (2) associate flow
    binding policies with the registered care-of addresses."
The similar text is available at the Section7, too.

A general question (not specific to this document)
Monami6 WG needs to coordinate activity. I think we
reach the consensus what we need in the WG such as..
- registering multiple CoAs (mcoa WG document)
- MN initiated filters registration (draft-hesham)
- HA initiated filters registration (supporting MH signaling in draft- 
hesham?)
- filters and policy rules (draft-larsson and draft-mitsuya)

In the WG charter, it has
- A protocol extension to Mobile IPv6 (RFC 3775) and NEMO Basic
Support (RFC 3963) to support the registration of multiple Care-of
Addresses at a given Home Agent address [Standard Track].
- 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 [Standard Track].

I don't check the MEXT charter, but can we work on
the generic filter/policy rules in the MEXT WG?

regards
ryuji

On 2007/08/30, at 6:10, Thierry Ernst wrote:

> say that we have rough consensus to adoptdraft-soliman-monami6-flow- 
> binding-04.txt as WG document.
>
>> 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

---

From: "Hesham Soliman" <[email-masked]>
Date: Sat, 15 Sep 2007 00:19:40 +1000

Hi Ryuji,

 > Can you explain how will you remove the filter format from the spec?

=> Sure, I'll highlight the text and cut it :)

 > Are you going to remove the filter format of the flow 

=> Basically we will have a generic header that includes the FID (same
meaning as today), the type of operation that needs to be done, priority,
and the type of flow format used...etc and leave the actual flow format out
of the draft. So the draft will still explain how to add/remove/modify
...etc without showing how the flow will be defined. It'll be a generic
header independent of the format. George Tsirtsis made a suggestion to
separate the two headers within the same draft a long time ago. So we will
follow that suggestion except the format will be defined in a different
draft. 

Hesham

---

From: "Hesham Soliman" <[email-masked]>
Date: Sat, 15 Sep 2007 15:23:11 +1000

> removes the function-1, we need a document for the generic format.

=> We don't remove function 1 as you describe it, we simply define the
format in a different document. That does not change the fact that the
transport mechanism binds a flow (in whatever format) to the FID. 

 > MN should avoid sending BU for other purpose than the binding  

=> Unfortunately I don't think point 2 above provides a technical rationale.
It clearly states your opinion, but there is no technical backing for that.
On the other hand, the flow binding, as the name suggests, is tightly
coupled to the binding process, including the binding cache management. I
think it's messy to try to put it in another MH, but more importantly, it's
unnecessary. 
If you want to do a protocol that allows the HA to send *policies* to the
MN, then you should do that, however, I think it's short sighted to put that
in MIPv6 messages. Such protocol need not be coupled to MIPv6 and others can
benefit from it. 

 > rules in BC and BUL.  This should be up to implementation. 

=> It doesn't require anything, if there is mandatory language we can check
it. The point is that we provide conceptual data management, which makes
sense for implementers. I think we had this discussion for other drafts.

 > supports n-cast only for HA, but I am not sure we really need this.

=> This was requested by several people for redundancy and mobility
management. It's not limited to the HA, a MAP can do it too.

 > - HA initiated filters registration (supporting MH signaling 

=> I don't recall discussing this third point in the meeting or getting any
concensus on it. Not sure which discussion you're referring to. I don't
think draft-soliman is the right place for it, as indicated earlier on the
list. 

Hesham

---

From: Nicolas Montavont <[email-masked]>
Date: Mon, 24 Sep 2007 17:06:56 +0200

Hi Ryuji,

[snip]

>> - HA initiated filters registration (supporting MH signaling

In the MEXT charter, it is written :

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

And I proposed at the last IETF to change it because it is not clear  
to me.
Here is the text I wrote on this issue:

I think this goal is not very clear and would need to be clarified. I  
can read here three different goals, which are:
    (1) Exchange policies to influence the choice of the CoA
    (2) Exchange policies to influence the choice of the HA address
    (3) Specify a generic format to describe the policies

I think that (1) should be re-written to "Policies enforcement from  
the mobile host/router to the HA to influence the choice of the CoA."  
I suggest that because the mobile host/router is the only one to know  
the addresses that are mapped to its interfaces. What we need, is a  
protocol to indicate to the HA which CoA to use at the HA for a  
specific flow. The policies set up (e.g., I want VoIP over your Wifi  
interface) was always out of scope of the work in monami6.

(2) We never discuss this point in the WG. Shall we?

(3) Can't we add an additional item to make clear that we will have 2  
documents?

Regards,

Nicolas

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Tue, 25 Sep 2007 03:48:12 +0900

Hi Nicolas,

> transport [both Standard Track].

If this is the fixed charter, the Hesham's draft does not satisfy the  
charter, doest it?
It fails to support the function from the Home Agent to the mobile  
host/router...

> And I proposed at the last IETF to change it because it is not  
> clear to me.
> I think this goal is not very clear and would need to be clarified.  
> I can read here three different goals, which are:
> the mobile host/router to the HA to influence the choice of the  
> CoA." I suggest that because the mobile host/router is the only one  
> to know the addresses that are mapped to its interfaces. What we  
> need, is a protocol to indicate to the HA which CoA to use at the  
> HA for a specific flow. The policies set up (e.g., I want VoIP over  
> your Wifi interface) was always out of scope of the work in monami6.

Agree with you that Policies setup is out of scope in monami6.
However, I cannot agree that the client is the only one to know the  
mapping of CoA and its interface.
If operators has wifi and wimax networks, they can surely know which  
address is mapped to which interface.
This is just an example, but we should not exclude this case. (At  
least, Tasaka and koshiro expressed their support on this approach.)

> (2) We never discuss this point in the WG. Shall we?

no..

regards
ryuji

>
> (3) Can't we add an additional item to make clear that we will have  
> 2 documents?
>
> Regards,
>
> Nicolas
>
>
>>

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Tue, 25 Sep 2007 04:00:44 +0900

Hi Hesham,

Thanks for clarification.
I will wait for new document.

regards,
ryuji

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Tue, 25 Sep 2007 04:12:39 +0900

Hi Hesham,

> think it's messy to try to put it in another MH, but more  

By sending flow binding, MN updates both binding and flow information  
at once.
MN always changes two databases: BC and the filter DB.
To me, it is better to support a mechanism to update only the filter  
rules.

> in MIPv6 messages. Such protocol need not be coupled to MIPv6 and  

About policies exchange, agree.
But why not installing filters from HA to MN?

> sense for implementers. I think we had this discussion for other  

Yes, it is same as the DSMIP. We should open this decision to the  
implementations.
Indeed, the filter stuff is not always implemented on the IP layer on  
some OS.

> management. It's not limited to the HA, a MAP can do it too.

ok. use case may help to understand why bi-cast.
(pointer to motivation draft may be enough).

> think draft-soliman is the right place for it, as indicated earlier  

hmm.
According to Nicolas' reply, MEXT charter said that.

ryuji

---

From: "Hesham Soliman" <[email-masked]>
Date: Tue, 25 Sep 2007 12:16:13 +1000

> MN always changes two databases: BC and the filter DB.

=> I don't know what a filter DB is. Conceptually, the BU updates the BC.
Whether you store flows in the BC or not, is an implementation issue, but
conceptually it only updates one thing. 

 > > If you want to do a protocol that allows the HA to send 
 > *policies*  
 > > to the
 > > MN, then you should do that, however, I think it's short 
 > sighted to  
 > > put that

=> Because that's the *policy*. I don't think you're on the same page here.
I hope it's just a terminology issue. The HA *cannot* install active
bindings on the MN because a) this is not how MIP works, and b) the Ha has
no idea what interfaces are active or best for the MN. So what it can do is
send a message that says "If you have a UMTS interface and a WLAN interface
up it's better to use the WLAN interface for your web browsing". This is a
*policy* not a flow installation.

 > (pointer to motivation draft may be enough).

=> ok.

 > > think draft-soliman is the right place for it, as 
 > indicated earlier  
 > > on the
 > > list.
 > 
 > hmm.

=> Ok but as I said we didn't discuss it in the meeting or say anything
about draft-soliman being the place for it. The charter also says that
policies are out of scope. So which parts of the charter should we take
seriously? 

Hesham