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