On 2011-07-19 03:51, Brian Haberman wrote:
> 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.
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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
