IETF Logo Mail Archive

Re: [6lo] Adaption of ROLL for mesh-under

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 13 April 2017 14:51 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6C01293F8 for <6lo@ietfa.amsl.com>; Thu, 13 Apr 2017 07:51:21 -0700 (PDT)
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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 HvWD1Dz2zkYo for <6lo@ietfa.amsl.com>; Thu, 13 Apr 2017 07:51:19 -0700 (PDT)
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 7F4861205D3 for <6lo@ietf.org>; Thu, 13 Apr 2017 07:51:19 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D311CE1D7; Thu, 13 Apr 2017 11:16:04 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 340AA636BB; Thu, 13 Apr 2017 10:51:18 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
cc: "6lo@ietf.org" <6lo@ietf.org>
In-Reply-To: <355d3c67e7e64024961916debbaa4b6c@XCH-RCD-001.cisco.com>
References: <1491971619970.42705@ssni.com>, <CD3480AD-3934-4C9E-B6F3-E399A32BACC8@tzi.org> <3BE49481-8869-49DD-91A9-37CF7B532E2E@cisco.com> <11848.1492007709@obiwan.sandelman.ca> <355d3c67e7e64024961916debbaa4b6c@XCH-RCD-001.cisco.com>
X-Mailer: MH-E 8.6; nmh 1.6+dev; 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, 13 Apr 2017 10:51:18 -0400
Message-ID: <14548.1492095078@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/DSyABA9M6JsQlFGZcp5dDKbUanY>
Subject: Re: [6lo] Adaption of ROLL for mesh-under
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Apr 2017 14:51:21 -0000

Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
    mcr> I would suggest that networks that want to move from mesh-under to
    mcr> route-over and are already running IPv6, would be best to use RPL in
    mcr> the way 6tisch uses it.  Gather the topology with RPL, then
    mcr> establish  6tisch-like tracks at L2.

    > [Pascal] In a green field, yes; maybe leveraging DAO projection,
    > too. But then if the goal is to use an existing forwarding plane,
    > certainly that's not the same story.

yeah, I'm not entirely sure I know what the existing situation is.
My impression is that the idea is to have a network that is a hybrid of both
mechanisms, because the network is being incrementally evolved.

As such I can see perhaps making L3 adjacencies (parent/child) over multi-hop
L2 mechanisms,  but in some cases, also recognizing that there are L3 aware
nodes in between.

If the nodes capabilities are high (and software upgrades or incremental
replacement is possible), but the network bandwidth is such that running two
networks (on different PANIDs or something) is impossible, then this might
work.

I asked Benjamin for more details privately, and I think that we'll get some
more details soon.

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

v2.23.0 | Report a Bug | By Email