Re: [Roll] Comments on draft-ietf-roll-dao-projection-09

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Mon, 06 January 2020 09:54 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 EECBF120122 for <roll@ietfa.amsl.com>; Mon, 6 Jan 2020 01:54:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level:
X-Spam-Status: No, score=-14.52 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, 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 header.b=i+u9/Y+Z; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=oF/3oZVY
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 xlM-496BPUeg for <roll@ietfa.amsl.com>; Mon, 6 Jan 2020 01:54:01 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A66A120106 for <roll@ietf.org>; Mon, 6 Jan 2020 01:54:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4365; q=dns/txt; s=iport; t=1578304441; x=1579514041; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=TylscyZh5Xpt550Nx4zcXmzLjum61DAsID/yGn6fLzc=; b=i+u9/Y+ZEddTv8yQUIt3UscZV/5l7J134FHJQbMuoBhmwFojGjgoFEB2 mOhZcFW/QkjQwNL1RdL4hrLsKQt6jc+4nvecDSYrIqM03MycEIkgHiCB/ /u7fYiLXWZdD42Tk7CG7zra3r20dfnBe8vKcQKixBph60IY23+zlZEvze 0=;
IronPort-PHdr: =?us-ascii?q?9a23=3AZ7ZwFx1ODSbJdY74smDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQEVH7MfTndTASF8VZX1gj9Ha+YgBY?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AzFQBpAhNe/5FdJa1mHgELHINQUAV?= =?us-ascii?q?sWCAECyqHTwOKf06CEYEBlwyCUgNUCQEBAQwBARgLCgIBAYRAAoFpJDgTAgM?= =?us-ascii?q?NAQEEAQEBAgEFBG2FCwclDIVeAQEBAQIBAQEQFRMGAQEsBAgECwIBCDYQJws?= =?us-ascii?q?lAQEEEwgagwGCRgMOIAECDKIAAoE4iGGBdDOCfgEBBYR/GIIMAwaBNoUdhnw?= =?us-ascii?q?agUE/gRABR4FOSTU+gmQBAYFlg0CCLIl3lgGONm8KgjaMb4QqhRyCRod9hEG?= =?us-ascii?q?HFYRCkBqZEgIEAgQFAg4BAQWBaSKBWHAVGiGCbFAYDYwJgQkMF4NQhRSFP3S?= =?us-ascii?q?BKIxzYAEB?=
X-IronPort-AV: E=Sophos;i="5.69,402,1571702400"; d="scan'208";a="697226319"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Jan 2020 09:54:00 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 0069s01w018897 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <roll@ietf.org>; Mon, 6 Jan 2020 09:54:00 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 6 Jan 2020 03:53:59 -0600
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 6 Jan 2020 03:53:58 -0600
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 6 Jan 2020 03:53:58 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I/jotowvFVAv+Jh1kzIOC3TIN79UYf2aos4x8O5Li4AlN+DWMze1+9aYzcT6MZ9HLyr+j2yDIhEK9QBxywtZcPDkI/3n61TlLN8v6+EOVZ7QPxaWNgCJjbAnwjQI3T8rnzyHs44A9bChnqMPo/Drg+A+aXZl9xxGd4WWTl22QC192U8rQ0T6wA5ao6nPaz57ryZCjZbzAwSBp/VPSjh6ZOpJJHf2WnCMViiq1RlGLUEeWjDyDaIsoJsCXUe3tmh/hiP083IYEnZUd8KLDFdkigIAMHsreiEsQXcOEsK1HHn4UsO0KIYX/+XcwG+Y/EWKkjFKY3Fqiog36R1p1EhfGA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TmIQRy5b/m/NhUj2FztixcTOzO9zgaRr83bzJbOOl3o=; b=dNljIgvvvgcAaO1g5CQcHWOJkPgAK7zE2K5zj1eBQQUmKjMBF1J+Rzq7Fkb8AIil2tQz6XRHfxXUI9skv229/OVef6UoDTmIWtIddQjNLiCT/X9WPFc7Fk5uhRp2AtqrejvLP0hsQmyUEyqXPwTdyGKP4fDFZZne+lQrUIaonKLhWkrClyJ6C08lMENSQ4eIJecKLTpKUMPh4MInWzXPg5eh0AezNtaRS62wyNkWUpU86gyAQvBsxGHYpbIUWaztVekMsnJIHW2gzC2EOfBI/6m+y9v8/B818DXMjPXzkpUOMXPBpWeyzrIw9WAs8jh+rpYneavzL/U+TpIeDRVVtA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TmIQRy5b/m/NhUj2FztixcTOzO9zgaRr83bzJbOOl3o=; b=oF/3oZVYkRuggBDoLXEELa9ILVJQfCCX03EpzJfWv+xbc5bdjMXUp1C0QF+YLeYEG1MaNEqWdWPs2W37emF2HA8asXbBNIt33Ob4ab2Ds+SbvHZhX2kzwh+9gf40gKfEpVMQYpfGqOjG+eMrEAeHpy63JAks4Ifet3QQCGkL7rU=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4511.namprd11.prod.outlook.com (52.135.37.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.13; Mon, 6 Jan 2020 09:53:57 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a%3]) with mapi id 15.20.2602.015; Mon, 6 Jan 2020 09:53:57 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.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/oeu3NqgK9Sp3A
Date: Mon, 6 Jan 2020 09:53:48 +0000
Deferred-Delivery: Mon, 6 Jan 2020 09:53:40 +0000
Message-ID: <MN2PR11MB3565B94765C68A0E7D45ACB8D83C0@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <BB09947B5326FE42BA3918FA28765C2E0113F924@DGGEMM506-MBS.china.huawei.com>
In-Reply-To: <BB09947B5326FE42BA3918FA28765C2E0113F924@DGGEMM506-MBS.china.huawei.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com;
x-originating-ip: [2001:420:c0c0:1001::111]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e5ac9c20-20ad-4eb3-37ba-08d7928e5941
x-ms-traffictypediagnostic: MN2PR11MB4511:
x-microsoft-antispam-prvs: <MN2PR11MB45111E905968B21008A9572CD83C0@MN2PR11MB4511.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0274272F87
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(366004)(39860400002)(376002)(346002)(37854004)(199004)(189003)(81166006)(81156014)(6916009)(316002)(71200400001)(5660300002)(66574012)(8936002)(8676002)(2906002)(86362001)(52536014)(6506007)(966005)(186003)(33656002)(66556008)(66476007)(64756008)(66446008)(66946007)(7696005)(76116006)(6666004)(9686003)(478600001)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4511; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: bWcSGpxHI+ShwHteGWtOhkP+PbDqcM/iwvaOHdWmNidkM4RChDPUPbJw4THyRfb/hy2ucgva9L60UsRdV9TRQabhB5wDDZU6N/7BsLILQrVaY1zxu5JBsOS+QC7AKM37Ct1QIpZAQCxcSqZeFBJyCpZhKUNPBIkNlFf2AR4Fdfhy5xu4JVj6ViNLzLzvuggcaDgg9+7iMcC9DAjJ9lPVqq7u4ukp949bonS2zgtPsOkParbTK2YGgEo57UZrCJbx490YglF7uE/hN0+oC0pB3wviX+xGLa34W44Ji1ELkvNMxUoYjKmIjihmeZhP/JgWMS5k+AUSfSDoc/l8Cno7IXPW9xBWJ+HuCa83tA2RyfqbO/zqr2d5jlR1VCEymDCc/e1hk9qpLJuJcnTX9VRpbwGQ91XwV6K97maan4PjV0Boc2b9VBwgmsXV5A+c5zvUOUl3NcZMjHY301eg/qV1tlnBDHKYYT0ZuEKVHe84QAH6Zzw0SC82sY3+EnMZeVG/3FZUeKUzKr6UY8wCtU15biiT/e4yATgd7ZgZKKWvhVU=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: e5ac9c20-20ad-4eb3-37ba-08d7928e5941
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2020 09:53:57.5113 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ZLabn+GJ6ge7LH51zHBmeEYyVlOQjl2j0umWwKl8rKbWehIw9aG/YfAeiMtvbMFRcdEtAipu5mnp6t5rPQL9Pw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4511
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com
X-Outbound-Node: rcdn-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/d2q1yOc9HldhC4L-JCtyULG2_YA>
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: Mon, 06 Jan 2020 09:54:04 -0000

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