Subject: [MEXT] binary filters draft 0

From: Christian Kaas-Petersen <[email-masked]>
Date: Mon, 4 May 2009 10:13:17 +0000 (GMT)

A few comments.

 * Flow description and flow descriptor seem to be used interchangeably.
   I should like to use flow description for what is presented in the
   draft, and flow descriptor as an index into a table (just like UNIX
   file descriptor is an index).  In MEXT setting there is no need for
   flow descriptor, as the term flow identifier is used.

 * Figure 1 and Figure 3: I count 4 bits for the NxPs field, although
   the text says they are 3-bit fields.

 * Section 3.1.  Hasn't TOS gone out of use, so that DSCP should be
   used instead?

 * Section 3.1.  Address ranges are specified by a single address and
   a prefix, whereas port ranges are specified from low to high.
   I guess the motivation for this, is that addresses will most often be
   a single address (MIP) or a prefix (NEMO).  I like to have such design
   rationales mentioned in the document.  The traffic selectors of IPsec
   prefer address ranges from low to high value, and this document could
   have followed what IPsec is doing.

 * Section 3.1.  In Source Port - High, why not stay firm: If only one port
   is of interest, Source Port - High must be absent.  Somewhere,
   probably in flow binding draft, there will be an error code for
   a malformed flow description.

Christian

      Find din nye laptop på kelkoo.dk. Se de gode tilbud her - http://dk.yahoo.com/r/pat/mm

---

From: George Tsirtsis <[email-masked]>
Date: Tue, 5 May 2009 09:29:13 +0100

Hi Christian,

thanks for the review and for catching these. See  comments inline.

>   flow descriptor, as the term flow identifier is used.

GT> OK, makes sense.

>   the text says they are 3-bit fields.

GT> yes thanks.

>  * Section 3.1.  Hasn't TOS gone out of use, so that DSCP should be

GT> Yes, you are probably right. Will correct.

>   have followed what IPsec is doing.

GT> The reason for the difference is simply packing efficiency. If we
do IP address range with a from/to, we will end up with 2x32 or 2x128
as opposed to 32+1 or 128+1 which is how it is now. For port numbers
from/to did not seem that bad since they are only 2bytes each. Does
that make sense?

>   a malformed flow description.

GT> Good suggestions, thanks. I will do what you say with the ports
and I will define a new FID status code in this draft.

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

---

From: George Tsirtsis <[email-masked]>
Date: Tue, 5 May 2009 11:18:41 +0100

Christian, et.al.,

As I was implementing the changes discussed earlier, the following
issue came up.

One of your comments is about renaming the TOS field to DSCP. First of
all I noticed we used the term Class of Service (CS) in the IPv6
header which is not correct...instead it is Traffic Class.

Looking into this a bit more, however, I remembered that the IPv4 TOS
byte as well as the IPv6 TC byte were redefined as 6bit DSfield and 2
bit Currently Unused (CU) fields. One of the CU bits was then used by
ECN (see RFC3260 for all this).

Since I do not anticipate anyone to be matching the ECN bit for the
purpose of Flow Bindings, I suggest we redefine the 8-bit TOS field as
an 8bit DSfield, the last 2 bits of which MUST be set to 0 by sender
and ignored by the receiver. This way a given DSCP can be matched
without getting confused by the ECN bit.

If someone really wants to match the ECN bit, (who knows why) of
course they still can, by using the offset based pointers defined in
the draft.

Note that I do not want to make this a 6bit field because that would
break byte alignment for the sub-option, when this field is present..

Does this make sense?

George