Re: [Roll] Comments on draft-ietf-roll-dao-projection-09
"Liubing (Remy)" <remy.liubing@huawei.com> Tue, 07 January 2020 03:39 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 5E7B9120058 for <roll@ietfa.amsl.com>; Mon, 6 Jan 2020 19:39:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 iejLs7Rlk7yE for <roll@ietfa.amsl.com>; Mon, 6 Jan 2020 19:39:40 -0800 (PST)
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 2D03212004A for <roll@ietf.org>; Mon, 6 Jan 2020 19:39:40 -0800 (PST)
Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 4BCD7F1CAEF5A4E056E6 for <roll@ietf.org>; Tue, 7 Jan 2020 03:39:38 +0000 (GMT)
Received: from lhreml701-chm.china.huawei.com (10.201.108.50) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 7 Jan 2020 03:39:37 +0000
Received: from lhreml701-chm.china.huawei.com (10.201.108.50) by lhreml701-chm.china.huawei.com (10.201.108.50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Tue, 7 Jan 2020 03:39:37 +0000
Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml701-chm.china.huawei.com (10.201.108.50) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Tue, 7 Jan 2020 03:39:37 +0000
Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.58]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0439.000; Tue, 7 Jan 2020 11:39:31 +0800
From: "Liubing (Remy)" <remy.liubing@huawei.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: Comments on draft-ietf-roll-dao-projection-09
Thread-Index: AdW5cQcc12mzHhBPSAydPP/oeu3NqgK9Sp3AACb5xYA=
Date: Tue, 07 Jan 2020 03:39:30 +0000
Message-ID: <BB09947B5326FE42BA3918FA28765C2E01164FD7@DGGEMM506-MBS.china.huawei.com>
References: <BB09947B5326FE42BA3918FA28765C2E0113F924@DGGEMM506-MBS.china.huawei.com> <MN2PR11MB3565B94765C68A0E7D45ACB8D83C0@MN2PR11MB3565.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB3565B94765C68A0E7D45ACB8D83C0@MN2PR11MB3565.namprd11.prod.outlook.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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/ktY1KKxjk7PePWJXR0cWDLIXLdo>
Subject: Re: [Roll] Comments on draft-ietf-roll-dao-projection-09
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 07 Jan 2020 03:39:42 -0000
Hello Pascal, Thank you for your reply. I think you have answered almost all my questions. Let's discuss the second question in a separate mail. Best regards, Remy > -----Original Message----- > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert > (pthubert) > Sent: Monday, January 06, 2020 5:54 PM > To: Routing Over Low power and Lossy networks <roll@ietf.org> > Subject: Re: [Roll] Comments on draft-ietf-roll-dao-projection-09 > > Hello Remy > > Many thanks for your review! > > Please see below: > > > I've read the latest version of the draft. Great efforts! Please find > > my comments below for your consideration. > > > > 1. Why do you choose to extend RPL instead of designing a new separate > > protocol to realize the establishment of a path? Technically, > > extending RPL works for sure. But if you look outside the IOT domain, > > the PCE have a separate protocol, i.e. PCEP, to establish the paths on the > devices. > > > PCEP to the device acting as PCC was considered in the history of 6TiSCH. So > was RSVP-TE. The Okham razor we used was code footprint. > Most implementations we are aware of do not provide TCP that PCEP needs, > and RSVP-TE would be a whole new protocol to support. > We'd have needed both plus a TE extension to RPL anyway. Extending RPL > for the whole thing was a simpler and smaller update. > Also we wanted to maintain the device<->root relationship that we use in > non-storing mode and that may be secured separately in the future. > It is still possible to use PCEP for the southbound interface root<->PCE and > have the Root acting as PCC translate in P-DAO terms as opposed to RSVP-TE. > > > 2. The titles of the subsections in section 6 are misleading. When I > > looked at the title "Non-storing/Storing mode projected route", I > > misunderstood them into "Route projection in non-storing/storing > > mode". Actually, until I reached at the appendix, I realized that they > > means the projected route itself is source-routed or hop-by-hop (no > > matter strict or loose). Do you think it is necessary to add some clarification > or to change the titles? > > Yes, that makes sense to me. Would you have a suggestion? Could you make > that a separate thread to attract a better attention from the group? > > > 3. The following specification is not accurate in some cases: " In the > > uncompressed form the source of the packet would be self, the > > destination would be the first Via Address in the SRVIO, and the SRH > > would contain the list of the remaining Via Addresses and then the Target". > > It is true if RPL is running in storing mode, otherwise, another > > encapsulation takes place to indicate the explicit route to the via > > address, just like you have said in the preceding paragraph. And the > > said explicit route should be projected as well. Please consider combining > the two paragraphs to make it correct. > > Great suggestion! Reordering things give: > > " > > When forwarding a packet to a destination for which the router > determines that routing happens via the Target, the router inserts > the source routing header in the packet to reach the Target. In > order to add a source-routing header, the router encapsulates the > packet with an IP-in-IP header and a non-storing mode source routing > header (SRH) [RFC6554]. In the uncompressed form the source of the > packet would be self, the destination would be the first Via Address > in the SRVIO, and the SRH would contain the list of the remaining Via > Addresses and then the Target. > > In the case of a loose source-routed path, there MUST be either a > neighbor that is adjacent to the loose next hop, on which case the > packet is forwarded to that neighbor, or a source-routed path to the > loose next hop; in the latter case, another encapsulation takes place > and the process possibly recurses; otherwise the packet is dropped. > > " > > Works? > > > 4. You've mentioned that the root can be the egress of a path. Does it > > mean that the upward route needs to be projected in some cases, given > > the fact that most of the examples given in the draft are downward or > transversal routes? > > Could you give an example on that situation? > > The P-DAO routes are separate RPL instances. They can be computed based > on an alternate choice of metrics. > This means that the "short" path along the DODAG for the main OF may > differ from the preferred one for the objective of the P-DAO route. > e.g., if reliability is required for the P-DAO route, the root may enforce B-A- > >root through in the main DODAG B is a child of root. > > All the best, > > Pascal > > > > _______________________________________________ > > 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
- Re: [Roll] Comments on draft-ietf-roll-dao-projec… Liubing (Remy)
- [Roll] Comments on draft-ietf-roll-dao-projection… Liubing (Remy)
- Re: [Roll] Comments on draft-ietf-roll-dao-projec… Pascal Thubert (pthubert)