Re: [Roll] rplinfo

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 04 August 2017 16:07 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 3B0741323B3 for <roll@ietfa.amsl.com>; Fri, 4 Aug 2017 09:07:12 -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 p0ufxAvFU6HV for <roll@ietfa.amsl.com>; Fri, 4 Aug 2017 09:07:10 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6049E1323B1 for <roll@ietf.org>; Fri, 4 Aug 2017 09:07:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5025; q=dns/txt; s=iport; t=1501862830; x=1503072430; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xRF97XiEtaKEb3HEmtwD9l/1Q6oCr9TpK40UYrhuX0Y=; b=ia6DgWJxDKnwHUzFZydoWBhNTNd3sUJW1auPDCqnBhxSib04lbUtT8C/ ymt8p1tswE81OWS/je1BjvGfDClV6V5x26iRd2B89My/ezfYtAjayv0CW Iho5IMLsBLTZS0n7ZAQqn42M9j/qFUSJ2BmpjcIHjIOgmQOsEosdlZeJk A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AVAQAdm4RZ/51dJa1cGgEBAQECAQEBAQgBAQEBg1pkbScHjgiQB4FulhUOggQhC4UbAoRKPxgBAgEBAQEBAQFrKIUYAQEBAQIBAQFsCwUHBAIBCBEEAQEoBycLFAkIAgQOBQiKDwMNCBCxLYcyDYQBAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWDKIICgUyFCoJXgWIEGg+GAQWRO45KAoseiQaCGIVYimKJXowjAR84gQp3FUmFFxyBZ3aHKYEwgQ8BAQE
X-IronPort-AV: E=Sophos;i="5.41,321,1498521600"; d="scan'208";a="464890330"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Aug 2017 16:07:09 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v74G79FL022043 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 Aug 2017 16:07:09 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 4 Aug 2017 11:07:08 -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 11:07:08 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
CC: Ines Robles <mariainesrobles@googlemail.com>
Thread-Topic: [Roll] rplinfo
Thread-Index: AQHS/6NEv51YLwBSwEmY1pHRxPGzJaJZwscAgAACX4CAAAJ3AIAABH8AgBpzsbCAAHbDgP//wEmw
Date: Fri, 04 Aug 2017 16:06:39 +0000
Deferred-Delivery: Fri, 4 Aug 2017 16:06:19 +0000
Message-ID: <70092d356aa1481888920851d6b8bd6b@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> <b9baea4ec79540bbaeff2e2d949915c5@XCH-RCD-001.cisco.com> <alpine.DEB.2.20.1708041446230.10279@ubuntu-1604-lts.c.rjtmp-165304.internal>
In-Reply-To: <alpine.DEB.2.20.1708041446230.10279@ubuntu-1604-lts.c.rjtmp-165304.internal>
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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/BIrtK27TVEcC1jgdN5t3GhjoK1A>
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 16:07:12 -0000

I'm not suggesting to split, Rahul, but pointing the consequences if we did.

If we did, the 6LBR would do DAR/DAC, and the RPL root DAO/DIO. And the root would need to signal to the 6LBR upon a DAO, e.g. a proxy DAR/DAC exchange.
Note also that RPL does not have the OID. 

Take care,

Pascal
-----Original Message-----
From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Rahul Jadhav
Sent: vendredi 4 août 2017 16:50
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Cc: Ines Robles <mariainesrobles@googlemail.com>
Subject: Re: [Roll] rplinfo

Hello Pascal,

Please find my resp inline..

Regards,
Rahul

On Fri, 4 Aug 2017, Pascal Thubert (pthubert) wrote:

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

[RJ]: Yes this draft is needed and it will optimize the non-RPL-aware leaf node joining (as compared to using proxy NS/NA DAR/DAC). One of the thing that is missing is the DAO-ACK signalling to the non-RPL-aware leaf node i.e. if DAO-ACK is received with negative status then what should the first-6LR node send to the non-RPL-aware node? Should the first-6LR delay the NA response till the time DAO-ACK is returned? This has its own complexities. Note that DAO-ACK might be sent from the Root/parent-6LR regardless of 'K' bit in the DAO message. Thus this has to be handled.

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

[RJ]: Are you suggesting splitting it up in a way that there is different RPL signalling between 6LBR and multiple RPL roots? Or is it that 6LBR will initiate the DIO and RPL roots simply become 6LRs? The later approach has multiple issues.

> > 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
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>

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