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

Michael Richardson <mcr+ietf@sandelman.ca> Sun, 16 November 2014 05:48 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 569D31A898C for <roll@ietfa.amsl.com>; Sat, 15 Nov 2014 21:48:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.495
X-Spam-Level:
X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsYlUTNxs6KW for <roll@ietfa.amsl.com>; Sat, 15 Nov 2014 21:48:27 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 955EC1A898A for <roll@ietf.org>; Sat, 15 Nov 2014 21:48:27 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 5D71E20012 for <roll@ietf.org>; Sun, 16 Nov 2014 00:50:46 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id 57627637F4; Sun, 16 Nov 2014 00:48:26 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 33A32637EA for <roll@ietf.org>; Sun, 16 Nov 2014 00:48:26 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
In-Reply-To: <B250E09C-99CF-45B5-9997-942DD81A7692@cisco.com>
References: <54667C2C.6000509@gmail.com>, <5466AB5C.9070806@acm.org> <B250E09C-99CF-45B5-9997-942DD81A7692@cisco.com>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Sun, 16 Nov 2014 00:48:26 -0500
Message-ID: <27581.1416116906@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/a5fdWbMne6IklHd8OUx-yhXfufc
Subject: Re: [Roll] Fwd: draft-previdi-6man-segment-routing-header
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
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: Sun, 16 Nov 2014 05:48:29 -0000

Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
    > This also relates to our discussion on whether a RH or a RPL option can
    > be inserted or cause an extra IPinIP encapsulation. Certainly the rule
    > is to encapsulate.

    > 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.

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

    > 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.


-- 
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-