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

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 04 May 2012 11:58 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD3821F85C2 for <roll@ietfa.amsl.com>; Fri, 4 May 2012 04:58:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.554
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1FNIw6+87Ac for <roll@ietfa.amsl.com>; Fri, 4 May 2012 04:58:50 -0700 (PDT)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9251021F858F for <roll@ietf.org>; Fri, 4 May 2012 04:58:50 -0700 (PDT)
Received: by eeke51 with SMTP id e51so886673eek.31 for <roll@ietf.org>; Fri, 04 May 2012 04:58:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.14.100.208 with SMTP id z56mr1106847eef.79.1336132729571; Fri, 04 May 2012 04:58:49 -0700 (PDT)
Received: from [192.168.1.65] (host-2-102-217-144.as13285.net. [2.102.217.144]) by mx.google.com with ESMTPS id m42sm40556354eef.0.2012.05.04.04.58.47 (version=SSLv3 cipher=OTHER); Fri, 04 May 2012 04:58:48 -0700 (PDT)
Message-ID: <4FA3C476.5000903@gmail.com>
Date: Fri, 04 May 2012 12:58:46 +0100
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: roll@ietf.org, pthubert@cisco.com
References: <20120504080338.24030.4170.idtracker@ietfa.amsl.com>
In-Reply-To: <20120504080338.24030.4170.idtracker@ietfa.amsl.com>
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-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 May 2012 11:58:51 -0000

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)