Re: [Roll] WRT adopting draft-rahul-roll-rpl-observations as WG document
"Liubing (Remy)" <remy.liubing@huawei.com> Wed, 01 August 2018 09:16 UTC
Return-Path: <remy.liubing@huawei.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 E756F130DE9 for <roll@ietfa.amsl.com>; Wed, 1 Aug 2018 02:16:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[HTML_MESSAGE=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 w7IxGZ3I0jKH for <roll@ietfa.amsl.com>; Wed, 1 Aug 2018 02:16:13 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5343129385 for <roll@ietf.org>; Wed, 1 Aug 2018 02:16:12 -0700 (PDT)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 793F4F04D2814 for <roll@ietf.org>; Wed, 1 Aug 2018 10:16:08 +0100 (IST)
Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 1 Aug 2018 10:16:09 +0100
Received: from DGGEMM526-MBS.china.huawei.com ([169.254.7.233]) by DGGEMM406-HUB.china.huawei.com ([10.3.20.214]) with mapi id 14.03.0382.000; Wed, 1 Aug 2018 17:15:48 +0800
From: "Liubing (Remy)" <remy.liubing@huawei.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>, "consultancy@vanderstok.org" <consultancy@vanderstok.org>
CC: Michael Richardson <mcr+ietf@sandelman.ca>
Thread-Topic: [Roll] WRT adopting draft-rahul-roll-rpl-observations as WG document
Thread-Index: AQHUKD/QDUv2uN0ixk2Stx7G+HnXz6SoYh0AgABgDQCAAdvsoA==
Date: Wed, 01 Aug 2018 09:15:48 +0000
Message-ID: <BB09947B5326FE42BA3918FA28765C2EE56BDA@dggemm526-mbs.china.huawei.com>
References: <30663.1532980742@localhost>, <22dd687bb26c96a86b7c0612c2af2ed7@bbhmail.nl> <28813905-00C9-4720-B20E-25B43DAAF394@cisco.com>
In-Reply-To: <28813905-00C9-4720-B20E-25B43DAAF394@cisco.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.130.180.83]
Content-Type: multipart/alternative; boundary="_000_BB09947B5326FE42BA3918FA28765C2EE56BDAdggemm526mbschina_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/T7J5EWm40OV1WY4J-T9CvjtPFYI>
Subject: Re: [Roll] WRT adopting draft-rahul-roll-rpl-observations as WG document
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.27
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: Wed, 01 Aug 2018 09:16:16 -0000
Hi all, I agree with Pascal. Although currently storing mode is not widely deployed comparing to non-storing mode, the WG has some directions such as DAO-projection, no path DAO and BIER-RPL to make it more feasible and efficient. If the WG has any plan to update RFC6550, I’d like to be part of it. Best regards, Remy From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert) Sent: Tuesday, July 31, 2018 8:46 PM To: consultancy@vanderstok.org; Routing Over Low power and Lossy networks <roll@ietf.org> Cc: Michael Richardson <mcr+ietf@sandelman.ca> Subject: Re: [Roll] WRT adopting draft-rahul-roll-rpl-observations as WG document Hello all I agree with pretty much everything that Michael suggested but the removal of storing node. Please remember that RPL is a routing protocol and that it can be used in various environments. Storing mode has an ancestor that did well in Manet type of networks. It can be used in home and in smartgrid networking where memory is not necessarily a constraint. It is used between “normal” routers to bootstrap a fabric in ANIMA. Even if it implies states, it is still a lot less than for a classical IGP. We cannot even consider making it historic. It just has an applicability that does not include large dodags of memory constrained devices. I agree though with the spirit in Michael’s mail whereby route projection provides an hybridation of a non storing infrastructure with particular storing mode projected routes that make storing applicable to memory constrained nodes, and that we need a new spec to advertise neighborhood (peers and delta Rank) and capabilities (eg amount or storing mode routes that can be held) to the root. Cheers Pascal Le 31 juil. 2018 à 09:02, Peter van der Stok <stokcons@bbhmail.nl<mailto:stokcons@bbhmail.nl>> a écrit : Hi Michael, thanks for a drastic point of view concerning 6550bis with removal of storing mode.What will removing SM mean for existing installations?. Removing SM means at least a 6550bis RFC and no update documents. Personally I am in favor of RPL 1.2 such that legacy can be managed. BTW are there volunteers for the writing? Peter Michael Richardson schreef op 2018-07-30 21:59: {been watching the youtube video of the ROLL session} 1) I think that the work in roll-rpl-observations is really important. -> that's why we should adopt the document so that it can have priority over other non-WG documents in the agenda. As our AD pointed out, we don't have to publish it. 2) Starting rfc6550bis or rfc6550updates is very important!!! We have some options on how to do this, one of which is to publish a bunch of very small updates. That's probably the lowest latency way, but it does cause more IESG and RFC-EDITOR work. So I think that we will be forced to publish a ~60-page update document that collects all sorts of things. 3) I'd like to move to obsolete (mark as "historical") storing mode in favour of dao-projection mode. I think that this is mostly orthogonal to the updates work, but if we agree that we are going in that direction, there might be updates that we don't need to do. 4) We need a new node capabilities mechanism. It could be quite controversial as there are a lot of design choices here. maybe we should probably encourage implementations, and then experimental RFCs. _______________________________________________ Roll mailing list Roll@ietf.org<mailto:Roll@ietf.org> https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org<mailto:Roll@ietf.org> https://www.ietf.org/mailman/listinfo/roll
- Re: [Roll] WRT adopting draft-rahul-roll-rpl-obse… Liubing (Remy)
- [Roll] WRT adopting draft-rahul-roll-rpl-observat… Michael Richardson
- Re: [Roll] WRT adopting draft-rahul-roll-rpl-obse… Peter van der Stok
- Re: [Roll] WRT adopting draft-rahul-roll-rpl-obse… Pascal Thubert (pthubert)