Re: [Roll] Fwd: draft-previdi-6man-segment-routing-header

"Pascal Thubert (pthubert)" <> Sun, 16 November 2014 06:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D40421A89A6 for <>; Sat, 15 Nov 2014 22:59:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.094
X-Spam-Status: No, score=-15.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Riyy832pShBt for <>; Sat, 15 Nov 2014 22:59:21 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 730C71A1B09 for <>; Sat, 15 Nov 2014 22:59:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=14639; q=dns/txt; s=iport; t=1416121161; x=1417330761; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Ew2IsBRLa/8qNoUAvd+hCzf1s1sfl37vfzI+SE5eukQ=; b=fyPhKiZRtHxrMaam3QXy0nz1ZJWdMQgkE4xun9xh+zJkFJtOGaUUO1yp 1ftvApzNRAy1egGEU7MEHD9HXeZfpX8G3Zu5v5yi6bFrAy0dhuqRSj7Z3 3WkE0B2lib1ama6bdKN7bvAarQ2X6W0CWh6GBJhAO+V0WaHEddOlqJSIi U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="5.07,396,1413244800"; d="scan'208,217"; a="97009084"
Received: from ([]) by with ESMTP; 16 Nov 2014 06:59:20 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id sAG6xKSW017349 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <>; Sun, 16 Nov 2014 06:59:20 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Sun, 16 Nov 2014 00:59:20 -0600
From: "Pascal Thubert (pthubert)" <>
To: Routing Over Low power and Lossy networks <>
Thread-Topic: [Roll] Fwd: draft-previdi-6man-segment-routing-header
Thread-Index: AQHQAFbVfdYglDMLE0GUchpU6eOffZxhScYA///tBo2AAe78AP//rJ8w
Date: Sun, 16 Nov 2014 06:59:19 +0000
Deferred-Delivery: Sun, 16 Nov 2014 06:59:00 +0000
Message-ID: <>
References: <>, <> <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD848A6282Axmbrcdx01ciscoc_"
MIME-Version: 1.0
Subject: Re: [Roll] Fwd: draft-previdi-6man-segment-routing-header
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: Sun, 16 Nov 2014 06:59:24 -0000

Hello Michael

>     > This is where the Flow Label technique was of particular interest.


> So you are saying that in order for us to add the RFC6553 header (no matter how

> compressed it is), we have to encapsulate all external traffic.

> I forgot that part in our excitement to come to consensus.

> This really sucks for RPL over things that don't need/want 6loHC (802.11* links,

> ethernet)... it sucks because it means screwing up the end to end MTU.

[PT] Yes, I insisted on it again at the 6lo presentation I made on the subject

My slide 3 was like:

*        Flow Label compresses RPI down to 20 bits

*        Flow label avoids IP-in-IP encapsulation

*        Flow Label needs 6MAN approval

*        6lo/NHC is unambiguous about RPI

*        6lo/NHC allows to compress 2-byte rank

*        6lo/NHC is a compressed form of RFC 6553 as opposed to a new format

I presented at 6MAN, with the following asks

1) the right for a source in the LLN not to set the flow label

2) the right for the LLN border router to reset the LLN for packets coming in the LLN

3) as an extension of 2) the right for the LLN border router to set the LLN that it just rest to a new value

4) as an extension to 3) the right for any router in the LLN to update the flow label

Noting that:

4) is what we need to use the flow label for RPL.

3) is what we need to maintain ISA100.11a legit.

1) and 2) are meant to save energy in the LLN.

> Are you saying you want to re-open the flow-label discussion?

[PT] I suggest we keep exploring 6lo solutions. At the moment we do not have a conclusion there.

So it is safe that at the same time try to remove the 6MAN-related arguments against the flow label approach so we have free hands ultimately.


>     > Now if we could go along the path of a routing dispatch where all the

>     > LLN routing artifacts are stored prior to the compressed packet we

>     > could probably make things innocuous.


> I don't understand this part.


[PT] This is something I hinted at the 6TiSCH call.

There is a third way that places all the LLN routing artifacts, including RH3 and RPI, in a routing dispatch, prior to the compressed packet.

A dispatch for the RPI only was overkill, but a routing dispatch can be a good idea that seems to alleviate the need for IP in IP.

Let me write that down so everyone can make his own opinion.




> --

> Michael Richardson <<>>, Sandelman Software Works  -=

> IPv6 IoT consulting =-