Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03

"Pascal Thubert (pthubert)" <> Fri, 01 August 2014 13:25 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C9E4F1A0B13; Fri, 1 Aug 2014 06:25:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QlWDk0sQR-t1; Fri, 1 Aug 2014 06:25:08 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 237361A0B06; Fri, 1 Aug 2014 06:25:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=1573; q=dns/txt; s=iport; t=1406899508; x=1408109108; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QhAjaCNubhiAAMcAlhI5fiNV4z2CCx9hEgOCeJUHzfs=; b=VEn9Ebw5lNX2IXqLQNR7yKrIVEPqG/dRyhpsTbYsRsgTkt2WZfSc6QEe E86LmeO48C/K3Z9OBZ6iL89ISeCoXdvKA7lMGkBQPohCuYiL08PZkffWA C+dVmay4WxEgUUNdC5Xl6gSJGrBJERa6hK/u1JIeuGnBR0RiBSSkpl18G w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAA+U21OtJV2b/2dsb2JhbABbgw2BLdNVAYEIFneEBAEBAwE6PwULAgEIDgQQFBAyFw4CBA4NiDIIyXwXjxsxB4MvgRwBBLBUg0mCMQ
X-IronPort-AV: E=Sophos;i="5.01,780,1400025600"; d="scan'208";a="341312469"
Received: from ([]) by with ESMTP; 01 Aug 2014 13:25:07 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s71DP7a6016088 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Aug 2014 13:25:07 GMT
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Fri, 1 Aug 2014 08:25:06 -0500
From: "Pascal Thubert (pthubert)" <>
To: Carsten Bormann <>
Thread-Topic: WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Index: AQHPrXsN1MAnFsPEm0SwuR6qTQA6spu7tLlA
Date: Fri, 01 Aug 2014 13:25:06 +0000
Deferred-Delivery: Fri, 1 Aug 2014 13:25:00 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: roll <>, "" <>
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <>
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 01 Aug 2014 13:25:10 -0000

> I think the visceral reaction that most of us have in using the flow label as a
> mesh routing header is that this blurs the layer boundaries.  So much for O,
> R, F, and rank.  Putting the VLAN ("instance ID") into the packet is a
> significantly larger change, because it essentially extends the IP service
> interface by a VLAN ID.  We normally try to hide IDs of this kind below IP.
> Now, I'm not saying any of this new architecture is wrong.  I just think what
> we need to do is discuss this as the architectural change that it is, not as a
> simple optimization.  (The need for some kind of optimization of IP-in-IP
> mesh routing for small-packet IoT applications is pretty obvious to me.)
I agree, Carsten.

An angle is that we allow for localized usage of the flow label as opposed to end-to-end.

Another is that we allow for different semantics within a local domain, as long as the packet that leaves the local domain fits the requirements in RFC 6437.

As you point out, it is worth noting that we include information about flow isolation and rules by which a flow will be routed, which is akin to Multi-Topology Routing though MTR is based on TOS bits.

It would be good to design an architecture that encompasses such capabilities.

We'll note that ISA100.11a is shipping with a flow label that contains an index to a state (so-called a contract) that is installed on the nodes on the way and by and large extends the notion of PHB on a per flow basis.