Re: [Roll] rplinfo

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 04 August 2017 13:00 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0D09132163 for <roll@ietfa.amsl.com>; Fri, 4 Aug 2017 06:00:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 VHismzvGW7d8 for <roll@ietfa.amsl.com>; Fri, 4 Aug 2017 06:00:42 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DEE2131CE8 for <roll@ietf.org>; Fri, 4 Aug 2017 06:00:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3126; q=dns/txt; s=iport; t=1501851637; x=1503061237; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=H6jO0O2q6w7ocqgZnlBtiJHDHpSGPjhvUjs/lcdc2yo=; b=PypOf7ABHbqbnb/319Eb0KnLj99n5kn5sH6FLs9qQIUzmUIDT8cjMcHF G6XLVSsJK1iXt+r0d1SAV5rc865Qr/PkpuQ1IrhH3SUpupwnzYO3FzOJ6 5EH3OO5GAv/9VnEU0VhU4aL8cJ7S4HiS3g979W6QJBgfUUGf2mIoRxfSS Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AVAQAcb4RZ/5pdJa1dGgEBAQECAQEBAQgBAQEBg1pkbScHjgiQB4FulhUOggQhC4UbAoRHPxgBAgEBAQEBAQFrKIUYAQEBAQMBATg0FwQCAQgRBAEBHwkHJwsUCQgCBAESCIoPAxUQsGWHMQ2EAQEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgyiCAoFMhQqCV4FiBBoPhgEFoAUCix6JBoIYhViKYolejCMBHziBCncVSYUXHIFndocpgTCBDwEBAQ
X-IronPort-AV: E=Sophos;i="5.41,321,1498521600"; d="scan'208";a="268228834"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Aug 2017 13:00:36 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v74D0aE1025400 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 Aug 2017 13:00:36 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 4 Aug 2017 08:00:35 -0500
Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Fri, 4 Aug 2017 08:00:35 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "consultancy@vanderstok.org" <consultancy@vanderstok.org>, Routing Over Low power and Lossy networks <roll@ietf.org>, Ines Robles <mariainesrobles@googlemail.com>
Thread-Topic: [Roll] rplinfo
Thread-Index: AQHS/6NEv51YLwBSwEmY1pHRxPGzJaJZwscAgAACX4CAAAJ3AIAABH8AgBpzsbA=
Date: Fri, 04 Aug 2017 13:00:24 +0000
Deferred-Delivery: Fri, 4 Aug 2017 13:00:21 +0000
Message-ID: <b9baea4ec79540bbaeff2e2d949915c5@XCH-RCD-001.cisco.com>
References: <b8c959fd621886daf3165d8edb4aa321@xs4all.nl> <CAP+sJUcSg4f_qbnxwCv1dwYUa+MftcZmmhSkOT6jj=wXPPYU0Q@mail.gmail.com> <6b3ea5150f609d2f13a329c39f5aafa6@xs4all.nl> <CAP+sJUfVdUCp-5ELAD8w6imqfqn5GQRx7FXoW3F6BgoHLvbGkg@mail.gmail.com> <53ff58f630492909409429a1f49da504@xs4all.nl>
In-Reply-To: <53ff58f630492909409429a1f49da504@xs4all.nl>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.228.216.25]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/Br4FVrZJ4bD6RUjwwUBUXrDxy1o>
Subject: Re: [Roll] rplinfo
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 04 Aug 2017 13:00:44 -0000

Dear all:

Very soon, when 6lo ships rfc6775-update, we will have the tools we need from the outside to enable interconnecting non-RPL-aware hosts as RPL leaves. Leaves will need a certain level of 6lo but no knowledge of RPL. And RPL will be able to register leaves with upgraded 6lo with a certain upgrade of RPL as well.

We'll need a new draft to specify the building of DAOs by the firs RPL router on behalf of the leaves in both storing and non-storing (there's a E bit to signal that already in RPL). The 6LR will have to be the first RPL router, and the 6lo spec will give us the TID which maps to the path-sequence, and the router will turn the periodic NS/NA into a periodic DAO.

We may specify that similarly, the DAO reaching the RPL root can be used to refresh the 6LBR in order to save the periodic DAR/DAC, but in order to do that, the 6LBR will also have to be the RPL root. Separating them will require additional signaling between the split functions, hopefully more a local exchange than the DAR/DAC.

Take care,

Pascal

-----Original Message-----
From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of peter van der Stok
Sent: mardi 18 juillet 2017 13:49
To: Ines Robles <mariainesrobles@googlemail.com>
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: Re: [Roll] rplinfo

Hi Ines,

my suggestion:
There is a LLN of connected nodes with IPv6 addresses and paths between them A subset of these nodes is RPL aware.
These RPL aware nodes form a DODAG.
The non RPL aware nodes are not part of the DODAG and cannot be leaves of the DODAG However, communication is possible between a rpl-aware node and a non-rpl-aware node via link-local addresses at least.

Peter

Ines  Robles schreef op 2017-07-18 13:32:
> Yes, agree.
> 
> So, could we have a case where the leaf nodes do not accept DIO 
> Messages like in the use cases?
> 
> Maybe we should define the features with more detail of a 
> not-RPL-aware-leaf in the document.
> 
> 2017-07-18 13:23 GMT+02:00 peter van der Stok <stokcons@xs4all.nl>:
> 
>> section 2, rpl-not-capable; how can this node be a leaf of a DODAG.
>> It can be a neighbour of a DODAG node but not a leaf in my 
>> understanding
>> 
>> I understand that we can have it. Please someone correct me if I am 
>> wrong.
>> 
>> RFC 6550 (pag. 110) mentions that a RPL-Leaf-Node-only:
>> 
>> - A leaf node (only) does not ever participate as a RPL router.
>> 
>> - Support of a particular MOP encoding is not required
>> 
>> - Support of a particular OF is not required.
>> 
>> -  A leaf node does not generally issue DIO messages,
>> 
>> - it may issue DAO and DIS messages.  A leaf node accepts DIO 
>> messages though it generally ignores DAO and DIS messages  (not 
>> applied in our case)
> 
>  A leaf node accepts DIO messages and is thus RPL-aware in my 
> understanding;
> 
> Peter

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll