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

Brian E Carpenter <> Fri, 04 May 2012 11:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5AD3821F85C2 for <>; Fri, 4 May 2012 04:58:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.554
X-Spam-Status: No, score=-101.554 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id z1FNIw6+87Ac for <>; Fri, 4 May 2012 04:58:50 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9251021F858F for <>; Fri, 4 May 2012 04:58:50 -0700 (PDT)
Received: by eeke51 with SMTP id e51so886673eek.31 for <>; Fri, 04 May 2012 04:58:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=GRrY/vM7aOYFP4ae7iB0caIF2CZLAnX3rI5p76PgmDY=; b=ERBE6oJUj/FMGbi6lUletl/KOHv0m1/s8El9K6xlSBrn5VPZXkTrPBfF63RDuxCLPt 8N/KtQW2R9HQ+AcD5BaUB+nuL8+OdobXPMx2Hvr2tWpB51cnHiyHy6Tbwq8jVVlfLq1h DMt50nN00ENNSl04bNdvXam2zaH3jg+sVVabJoaySEXufR8wGD1DKM39acud07Z4fLG7 ViDoUBny0KBReJWlmfm9/xHOf+G52akNI5ofT1H8PAdc/CO61dP6A/fHFu7HctNNVhJL qe+Jh3VJhFoewHH+IASgJmpZxDY359g+tpmkDwxT1Im3bYJsplxDOs3Xe7fyloPO8h9w L0vw==
Received: by with SMTP id z56mr1106847eef.79.1336132729571; Fri, 04 May 2012 04:58:49 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id m42sm40556354eef.0.2012. (version=SSLv3 cipher=OTHER); Fri, 04 May 2012 04:58:48 -0700 (PDT)
Message-ID: <>
Date: Fri, 04 May 2012 12:58:46 +0100
From: Brian E Carpenter <>
Organization: University of Auckland
User-Agent: Thunderbird (Windows/20070728)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Fri, 04 May 2012 07:29:31 -0700
Subject: Re: [Roll] I-D Action: draft-thubert-roll-flow-label-00.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 04 May 2012 11:58:51 -0000


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.

   Brian Carpenter

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