Subject: Suggestion: Define the Flow Descriptor as a Suboption RE: [Monami6] new revision of draft-soliman-monami6-flow-binding-02

From: "Tsirtsis, George" <[email-masked]>
Date: Tue, 3 Oct 2006 07:06:47 -0700

Hesham,

I think the idea of including the CLS field in the Flow Description
option is in the right direction but I do not think it is sufficient in
its current form. The point of the CLS field is to allow for other ways
of describing flows (e.g., text based) or other types of flows (e.g.,
IPv4 flow).

The Flow Identification option, however, has the flags that indicate
whether certain fields of the current flow descriptor are present in the
option before the CLS field. So, if one wanted to change the way a flow
is described, the option will still have to carry the now meaningless
flags in its front part. In other words, the Flow Identification option
is not modular enough to allow for alternate formats of the flow
descriptor in a clean way.

I believe that the flow description option could trivially become more
modular by defining the "flow descriptor" part as a sub option. This
way, other drafts can easily be written to define entirely different
types of filter descriptors. I believe this is simply a format issue and
does not significantly affects the protocol operation, which I think is
generally correct.

As an example, here is how the Flow Identification option could be
changed:

      0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Option Type    |  Option Len   | Reserved      |       PRI     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        FID    |   Action      |  Status       |      PRO      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Suboption Type| Subopt Length |   Flow Descriptor ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

And here is how you could define the current flow descriptor as a
suboption:

     0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |SubOpt Type    |  SubOpt Len   |S|E|F|L|O|W|T|I|R|H| reserved  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                       Source Address                          +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Prefix      |                 Res1                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                                                               |
       +                    Destination Address                        +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Prefix      |                  Res2                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Source port - Min         |         Source port - Max     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Dst port - Min            |         Dst port - Max        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            SPI                                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Flow Label                       | Res3  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Protocol    | C. S.         |           Res4                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Thoughts?

George

> -----Original Message-----
> From: Soliman, Hesham [mailto:[email-masked]]
> Sent: Wednesday, September 27, 2006 2:34 AM
> To: Monami6 WG
> Subject: [Monami6] new revision of
draft-soliman-monami6-flow-binding-02
> 
> 
> Folks,
> 
> Please note that a new revision has been submitted based on our
> discussions
> in Montreal. Until it apperas on the IETF site, you can find it here:
> 
>
http://www-r2.u-strasbg.fr/~montavont/draft-soliman-monami6-flow-binding
> -02.txt
> 
> We made significant changes in this revision, here are the main ones:
> 
> - Combine the use of the flow id with the BID for aggregation and
>   n-casting benefits.
> - Modified the Flow id option to include the BID (as a sub-option)
> - Defined a new BID sub-option for the purpose above
> - Added a new field (CLS) to the option in order to allow other ways
of
> definining a flow.
> This issue was brought up in the last meeting. We can now have 15
> different mechanisms
> (or languages) to define a flow.
> 
> We look forward to your comments.
> 
> Hesham
> 
> _______________________________________________
> 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: "Soliman, Hesham" <[email-masked]>
Date: Thu, 5 Oct 2006 08:49:01 -0700

I think this can work. It's certainly clean, my only concern is tying
sub-options to each other and whether that causes any problems in
processing at the receiver. For example we already have the BID
sub-option, which needs to be associated with the FID, and it is
definitely possible that new sub-options would be added in future and
tied to the same FID. But I think it can work without problems we just
have to be clear that one option can only contain one flow descriptor. 

Hesham 

 > From: Tsirtsis, George 
 > Sent: Wednesday, October 04, 2006 12:07 AM
 > To: Monami6 WG
 > Cc: Soliman, Hesham
 > Subject: Suggestion: Define the Flow Descriptor as a 
 > Suboption RE: [Monami6] new revision of 
 > I think the idea of including the CLS field in the Flow 
 > Description option is in the right direction but I do not 
 > think it is sufficient in its current form. The point of the 
 > CLS field is to allow for other ways of describing flows 
 > (e.g., text based) or other types of flows (e.g., IPv4 flow).
 > 
 > The Flow Identification option, however, has the flags that 
 > indicate whether certain fields of the current flow 
 > descriptor are present in the option before the CLS field. 
 > So, if one wanted to change the way a flow is described, the 
 > option will still have to carry the now meaningless flags in 
 > its front part. In other words, the Flow Identification 
 > option is not modular enough to allow for alternate formats 
 > of the flow descriptor in a clean way.
 > 
 > I believe that the flow description option could trivially 
 > become more modular by defining the "flow descriptor" part 
 > as a sub option. This way, other drafts can easily be 
 > written to define entirely different types of filter 
 > descriptors. I believe this is simply a format issue and 
 > does not significantly affects the protocol operation, which 
 > I think is generally correct.
 > 
 > As an example, here is how the Flow Identification option 
 > could be changed:
 > 
 >       0                   1                   2                   3
 > And here is how you could define the current flow descriptor 
 > as a suboption:
 > 
 >      0                   1                   2                   3
 >        |                                                     
 >           |
 >        +                                                     
 >           +
 >        |                                                     
 >           |
 >        +                       Source Address                
 >           +
 >        |                                                     
 >           |
 >        +                                                     
 >           +
 >        |                                                     
 >           |
 >        | Prefix      |                 Res1                  
 >           |
 >        |                                                     
 >           |
 >        +                                                     
 >           +
 >        |                                                     
 >           |
 >        +                    Destination Address              
 >           +
 >        |                                                     
 >           |
 >        +                                                     
 >           +
 >        |                                                     
 >           |
 >        | Prefix      |                  Res2                 
 >           |
 >        |                            SPI                      
 >           |
 >        |                      Flow Label                     
 >   | Res3  |
 > > - Added a new field (CLS) to the option in order to allow 
 > other ways of
 > > definining a flow.

---

From: Thierry Ernst <[email-masked]>
Date: Mon, 9 Oct 2006 02:46:37 +0200

Dear all,

I didn't read all the draft yet, but I noticed a couple of editorial
details which would require some modifications particularly when it
comes to NEMO.

In abstract:

- Mobile IPv6 is mentioned but not NEMO Basic Support. Since you refer
to the specifications and not the concept, both names are needed.

In introduction

- it is said the BU can be sent to a CN or a mobility anchor point. I
would be more explicitly on what the anchor point is. Also, I'm not sure
we should deal with the MAP or the CN. Let's don't forget that this
specification should be about extensions to MIP6 and NEMO BS, not
HMIPv6, and not in the RO case. It the extensions equally works for the
CN and the MAP, this is fine, but it should be pointed out at another
place. 

- [3] is referred as an extension to MIPv6; NEMO BS should equally be
cited

- Before referencing [3],  I would first reference to the MIP6 Analysis
draft and the NEMO BS Multihoming Issues draft, giving for both the
appropriate section number.

- You may add a terminology section where you would put the definition
of a flow, and proper reference to other documents where terms are
defined, i.e. draft-ietf-nemo-terminology and RFC 3753.

Section 2

- same comment as before, this document proposes extensions to MIP6 and
NEMO.

References:

-  [3], [6] and [7] you didn't put all the author names or "et all".

- please add an entry for
  1. draft-ietf-nemo-multihoming-issues
  2. draft-ietf-nemo-terminology 
  3. RFC 3753.

Thierry.

On Tue, 26 Sep 2006 23:34:27 -0700
"Soliman, Hesham" <[email-masked]> wrote:

> - Added a new field (CLS) to the option in order to allow other ways of
> definining a flow. 

-- 
Thierry ERNST, PhD
http://www.nautilus6.org/~thierry
IETF NEMO WG Chair, IETF MonAmi6 Chair, Nautilus6 Chair
--
INRIA Rocquencourt Project-Team IMARA, France.
+33 1 39 63 59 30 (office)

---

From: "Soliman, Hesham" <[email-masked]>
Date: Mon, 9 Oct 2006 02:05:50 -0700

Hi Thierry,  

 > to the specifications and not the concept, both names are needed.

=> Ok, actually nemo is already supported in the spec and the mobile
router is mentioned in all processing sections.  

 > CN and the MAP, this is fine, but it should be pointed out at another

=> I don't understand your logic here "MIPv6" *includes* sending BUs to
CNs. Why should we proactively limit that operation if it already works
in this spec? Also, sending the BU to an HA or a MAP is the same in
terms of processing. Why can't we use that term? DSMIP for instance does
exactly that, so I don't understand why we should limit ourselves to
subsets of  MIPv6. 

 > - [3] is referred as an extension to MIPv6; NEMO BS should equally be

=> yes.

 > appropriate section number.

=> We don't really talk about them in the spec, but if you mean add them
as informative references then that's fine. [3] is not really
informative. 

 > defined, i.e. draft-ietf-nemo-terminology and RFC 3753.

=> Agreed. 

Hesham

---

From: Thierry Ernst <[email-masked]>
Date: Mon, 9 Oct 2006 17:33:21 +0200

Hi Hesham,

> router is mentioned in all processing sections.  

I didn't read the technical sections but I can guess this would be clear
from reading the whole draft.  But I prefer things to be explicitly
written though this might be obvious. The purpose of the introduction is
to explained the motivation and technical findings presented in the rest
of the doc.

> exactly that, so I don't understand why we should limit ourselves to

My logic is that to qualifty for a Monami6 deliverable, we shouldn't
tackle with RO. If the solution allows to do it with any change nor more
extra work from the WG, then very fine, but I would prefer to see this
written clearly in the abstract / introducion and potentially in another
section called "applicability to MIP6 with RO", "applicatbility to
HMIPv6", etc.

So, it's not a matter of limiting the spec, but making it compliant with
the Monami6 charter, and this is mostly editorial (i.e. how things are
introduced and presented in the draft). I'm sure you will understand
this point from a charter view point.

> as informative references then that's fine. [3] is not really

The point I'm tryiing to make is that both the MIP6 mhoming analyis and
the NEMO mhoming analysis are here to explain the problem and do it
pretty well. So, referencing them and the section where the policie
setting is explaned in both draft would help the readers and will also
serve our cause when the draft reach IESG hands. Both drafts are to be
cited as informational, of course.

Thierry.

---

From: "Soliman, Hesham" <[email-masked]>
Date: Tue, 10 Oct 2006 05:40:46 -0700

> to explained the motivation and technical findings presented 

=> Sure, we'll do.

 > section called "applicability to MIP6 with RO", "applicatbility to

=> We can add this explicit heading if you like, I don't see a problem
with that. 

 > this point from a charter view point.

=> Sure, no problem, I thought you meant we should take it out of the
spec, but obviously not. 

 > cited as informational, of course.

=> Ok, fine with me. 

Hesham