Re: [Roll] I-D Action: draft-thubert-roll-flow-label-00.txt

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

Hi,

IMHO there are problems with this proposal.

One is that it doesn't, as far as I can see, demonstrate that
the overhead of rewriting the flow label on exit from an RPL
domain is significantly less than the overhead of dealing
with the RPL hop-by-hop option at the edge of the domain.

Then, this phrase:

>    Sadly, the Option must be placed in
>    a Hop-by-Hop option that must be inserted or removed as the packet
>    crosses the border of the RPL domain. 

bothers me, because (and I have looked recently) there is nothing
in the IPv6 specs that allows for an extension header being
inserted (or removed) en route. The text continues

>    ...This operation may involve an
>    extra encapsulation that is detrimental to the network operation, in
>    particular with regards to bandwidth and battery constraints.

Why "may"? If the packet is inbound to RPL, RFC 6553 makes it clear
that it must be encapsulated; if the packet is outbound, why would
it be encapsulated at all? This case is covered in the RFC too:

>    3.  Datagrams destined to nodes outside the RPL Instance are dropped
>        if the outermost IPv6 header contains a RPL Option not generated
>        by the RPL router forwarding the datagram.

Then, the draft says:

>    This document specifies how the Flow Label can be reused within the
>    RPL domain as a replacement to the RPL option.  The use of the Flow
>    Label within a RPL domain is an instance of the stateful scenarios
>    decribed in [RFC6437]...

In fact RFC 6437 carefully says very little about stateful scenarios; it
does not describe them, but it does constrain them. Here is the entire
section on this topic:

> 4.  Flow State Establishment Requirements
> 
>    A node that sets the flow label MAY also take part in a flow state
>    establishment method that results in assigning specific treatments to
>    specific flows, possibly including signaling.  Any such method MUST
>    NOT disturb nodes taking part in the stateless scenario just
>    described.  Thus, any node that sets flow label values according to a
>    stateful scheme MUST choose labels that conform to Section 3 of this
>    specification.  Further details are not discussed in this document.

The problem is that section 3 intentionally does not consider flow label
values in which any of the bits have semantic significance, and this was
the consensus in the 6MAN WG after a great deal of discussion. However,
the present proposal assigns semantics to various bits in the flow
label, destroying its desired property of belonging to a statistically
uniform distribution.

The issue is clearly stated in RFC 6437:

>    Once set to a non-zero value, the Flow Label is expected to be
>    delivered unchanged to the destination node(s).  A forwarding node
>    MUST either leave a non-zero flow label value unchanged or change it
>    only for compelling operational security reasons as described in
>    Section 6.1.

Regards
   Brian Carpenter

(please keep me on CC as I am not on the ROLL list)