Re: [Idr] I-D Action: draft-ietf-idr-flow-spec-v6-01.txt

[Brian E Carpenter <[e-mail]>]

Hi,

My comments below don't seem to have been addresed.
draft-ietf-6man-flow-3697bis is now in the RFC Editor queue, by the way.

Regards
   Brian Carpenter


-------- Original Message --------
Subject: Re: I-D Action: draft-ietf-idr-flow-spec-v6-00.txt
Date: Wed, 15 Jun 2011 01:54:04 +1200
From: Brian E Carpenter <[e-mail]>
Organization: University of Auckland
To: [e-mail]
References: <[e-mail]>

Hi,

I have a couple of concerns about this draft.

>    Type 13 - Flow Label - New type
>
>       Encoding: <type (1 octet), [op, value]+>
>
>       Contains a set of {operator, value} pairs that are used to match
>       the 20-bit Flow Label field [RFC2460].The operator byte is encoded
>       as specified in the component type 3 of [RFC5575].

One point is that RFC 2460 really doesn't specify anything about the flow
label except where it sits in the IPv6 header. The current spec is RFC 3697,
but that is close to being replaced by draft-ietf-6man-flow-3697bis.
However, that describes a stateless model where there is no need for
flow signaling.

So, I have no idea what this new type is good for. If  there is no use case,
why define it? At the very least, there should be a pointer to 3697bis.

>    Traffic Marking: The traffic marking extended community instructs a
>    system to modify the Traffic Class bits of a transiting IPv6 packet
>    to the corresponding value.  This extended community is encoded as a
>    sequence of 5 zero bytes followed by the 8 bit Traffic Class value
>    encoded in the 6th byte.

This breaks ECN. You must only touch the 6 DSCP bits, according to
RFC 2474. (That would also be true for IPv4.) Of course there should be
a reference to RFC 2474 too.

Regards
   Brian Carpenter