IETF Logo Mail Archive

Re: [6tisch] tagging join traffic wih DSCP: why inside IP header?

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 16 November 2017 20:39 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71542128BB6 for <6tisch@ietfa.amsl.com>; Thu, 16 Nov 2017 12:39:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 gWgv57kaD5ns for <6tisch@ietfa.amsl.com>; Thu, 16 Nov 2017 12:39:54 -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 2E7151201FA for <6tisch@ietf.org>; Thu, 16 Nov 2017 12:39:54 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D988920091; Thu, 16 Nov 2017 15:41:38 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C4F9B82639; Thu, 16 Nov 2017 15:39:52 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
cc: Thomas Watteyne <thomas.watteyne@inria.fr>, "6tisch@ietf.org" <6tisch@ietf.org>
In-Reply-To: <4794F61D-EE1C-4D39-8225-31546ACC8F38@cisco.com>
References: <CADJ9OA_cKxWZLvfpNXhjNgL1HurfdK-Oqj1M-wU9pK5t+1kU4g@mail.gmail.com> <20396.1510678103@obiwan.sandelman.ca> <32033.1510687749@obiwan.sandelman.ca> <92bca0456cb746c995733131edad10a2@XCH-RCD-001.cisco.com> <CADJ9OA_b2fHUg=3utnCv8iTMZcwL-n3J_H2N6uU=v8SjenjmFA@mail.gmail.com> <361109c852ca4d8e983f19899648c811@XCH-RCD-001.cisco.com> <CADJ9OA-JgzSpDKSbZ=7P91beoThvVh+0_HgLvVRiaWMhHmv+iQ@mail.gmail.com>, <32611.1510778999@obiwan.sandelman.ca> <4794F61D-EE1C-4D39-8225-31546ACC8F38@cisco.com>
X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.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-sha256"; protocol="application/pgp-signature"
Date: Thu, 16 Nov 2017 15:39:52 -0500
Message-ID: <18348.1510864792@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/wldRhgkZuZMhwDlWPoS2IyRibtQ>
Subject: Re: [6tisch] tagging join traffic wih DSCP: why inside IP header?
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Nov 2017 20:39:56 -0000

Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
    > Could we leverage the use of RPL information draft to indicate that the
    > RPL info can be safely removed on RPL packets outgoing the domain ?  I
    > think that would pass.

I don't think that would work... but feel free to suggest that during the
WGLC for the document :-)

I suggest that we should get the rules as they are past IESG, and then if we
want to do better that we can do that.

    > We can also indicate that insertion in allowed on incoming packets and
    > see what pushback we get now.
    > This would avoid having too many flag days as the rules become more
    > realistic. The times they are a-changing..,

Aside from 0x63->0x23, there are no other flag days that I forsee.

If one decides to insert/remove headers at the DODAG root, then I think
that this is a unilateral decision.   If one has a network that is intolerant
of the 0x63 RPI option, and updating the LLN is not feasible, then either
fixing that in the DODAG root or removing the header at the DODAG seems like
something a product might just do.

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

v2.23.0 | Report a Bug | By Email