Subject: DISCUSS: draft-ietf-6man-flow-3697bis and reserving bits from the flow label

From: Brian Haberman <[email-masked]>
Date: Mon, 18 Jul 2011 11:51:49 -0400

6MAN Participants,
     During IESG evaluation, a DISCUSS position was raised on whether or
not several of the bits (4 was suggested) be reserved as a discriminator
to identify how the flow label is being used.  We had a discussion in
2010 on separating the current 20 bits of flow label into sub-fields
(discussion started around this point in the mailing list archives :
http://www.ietf.org/mail-archive/web/ipv6/current/msg12031.html).

     The consensus from that mailing list discussion was to not divide
the flow label for several reasons:

1. Encoding semantics was too complex to handle at line rate

2. A 16-bit flow label may be too easy to predict

3. These fields are not protected in anyway, so there is little trust in
the values set

The above reasons led to the decision to retain the flow label as a
single 20-bit field as it is currently defined in 3697bis.  Since this
is a DISCUSS position, the goal of this message is to educate the IESG
on our line of thinking and allow other WG participants to chime in with
other reasons I have omitted for keeping the flow label a single entity
within the IPv6 header.

Regards,
Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Jul 2011 11:00:42 +1200

> other reasons I have omitted for keeping the flow label a single entity

I would add three points:

4. A somewhat similar idea was proposed to the WG in
draft-carpenter-6man-flow-update-01 (March 2010), although it
only used one bit:

  "o  If the most significant bit (MSB) of the flow label is 0 and the
      flow label is not all-zero, then the remaining 19 bits MUST obey
      the rules of [RFC3697].
   o  If the MSB of the flow label is 1, the remaining 19 bits MAY obey
      a locally defined set of rules and those bits MAY be changed en
      route."

There was painfully strong consensus against this approach at IETF77
and IETF78.

5. The DISCUSS says "This specification uses the full size of the flow label.
Since it has no discriminator to indicate that it is being used for load
balancing, no other use can be made of this field."

It isn't completely true that the draft precludes any other use. It precludes
any other use *without signaling*. If (for example) Intserv/RSVP was used to signal
a flow label value as part of a Tspec, it could have a specific meaning.

6. This is a bit of a FUD argument, but changing the flow label size at this
point might cause interop problems for any existing deployment that conforms
to RFC 3697. The current 3697bis proposal is very unlikely to cause such problems.

Regards
   Brian Carpenter