[Roll] (Was: review of dao-projection -22)

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 14 January 2022 10:20 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 A87D93A20FB for <roll@ietfa.amsl.com>; Fri, 14 Jan 2022 02:20:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.885
X-Spam-Level:
X-Spam-Status: No, score=-11.885 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, 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=c9HBcVY/; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=VJXFjrXU
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 ATXJGJsFG1DY for <roll@ietfa.amsl.com>; Fri, 14 Jan 2022 02:20:34 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C28F3A20F8 for <roll@ietf.org>; Fri, 14 Jan 2022 02:20:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29994; q=dns/txt; s=iport; t=1642155634; x=1643365234; h=from:to:cc:subject:date:message-id:mime-version; bh=ozeRd210r9zowZlUb8Uj56SPtcD4DbMMF/O/yQnTgxg=; b=c9HBcVY/F4yZ6tpm2WnFaYi6s9qnbHItGTtrpaXnn6GiJ9u6wVtVY2tf ihv7aBrJgEW+e2jstJBCwqdnafCv1GFuv7/Ol5GoUEbzGoXj7cnam77Jp SQv7RU6znkMRK45LNIbD33HgY7t6LP/TtC8tpeMuxcfZB5owJzChm+Mge Y=;
X-IPAS-Result: A0A3BgCZTeFh/4oNJK1agQmBWYEhMVYHd1o3MYgOA4U5hQ6DAoEWjyGCMYg5gS4UgREDVAsBAQENAQE3CgQBAYUFAoNKAiU0CQ4BAgQBAQEBAwIDAQEBAQUBAQUBAQECAQYEgQkThTsBBCgNhkIBAQEBDwYVBhMBATcBEQEZBAEBIQE/HQkBBA4FCBqCY4IOVwMuAQ6fXwGBOgKKH3iBATKBAYIIAQEGBASFCxiCNgMGgTqDDoJ+VEqHMByBSUSBFAFDVYERSnWCYwICgSQcBBwkB4Migi6QICVGDmANNg4CTQMrHjcKDgECEgcPHwufRoFwnlgKg0SWEYlaFZQck1KWQSChCBcLC4ReAgQCBAUCDgEBBoFhO4FZcBWDJFEZD4Vrgl+JR4UUhUp0AjYCBgsBAQMJjWcHgj8BAQ
IronPort-PHdr: A9a23:mkd3uB1Gm8lfdCcksmDPr1BlVkEcU/3cMg0U788hjLRDOuSm8o/5N UPSrfNqkBfSXIrd5v4F7oies63pVWEap5rUtncEfc9AUhYfgpAQmAotSMeOFUz8KqvsaCo3V MRPXVNo5Te1K09QTc3/fFbV5Ha16G16Jw==
IronPort-Data: A9a23:1ZQ5Ua8CtYu+zvAg3fFLDrUDcXyTJUtcMsCJ2f8bNWPcYEJGY0x3n WtJDW/UOa6ONjHxL94nbojkpB5XvpeHnIdjSFY9+HxEQiMRo6IpJzg2wmQcns+2BpeeJK6yx 5xGMrEsFC23J5Pljk/F3oLJ9RGQ7onVAOqsYAL4EnopH1U8EX590UgLd9MR2+aEv/DoW2thh vuqyyHvEAfNN+lcaz98Bwqr8XuDjdyq0N8qlgVWicNj4Dcyo0Io4Kc3fsldGZdXrr58RYZWT 86bpF2wE/iwEx0FUrtJmZ6jGqEGryK70QWm0hJrt6aebhdq/hUIiIESBqcgNHxwlWTYoe4um OpAusnlIespFvWkdOU1Wh1cFWR1OrdLveKBKnmkusvVxErDG5fu66wxVwdtY8tBoaAuWjEmG f8wcFjhajibm+Kryr+hVsFnh98oK4/gO4Z3VnRInW2HU6x2EcGYK0nMzdpK3RMSmcVtJ+T5a pFeMBRDdCmDUyQabz/7D7p7xo9EnELXaTpcrHqUqLY5pW/Jw2RMPKPFOd7RfJmBQt9Y2xver WPd9GO/CRYfXDCC9Qe4HruXrrentUvGtEg6TdVUKtYCbIWv+1Eu
IronPort-HdrOrdr: A9a23:0d7XA6Ho6mY6EYQ7pLqFX5HXdLJyesId70hD6qkvc31om52j+f xGws516fatskdsZJkh8erwX5VoMkmsiqKdgLNhcotKOTOHhILGFvAY0WNtqQeQYREWmtQtsJ uIEJIORuEYb2IK8PoSiTPQe71LrbX3k9HLuQ609QYKcegeUdAZ0+4PMHfjLqQZfngjObMJUL 6nouZXrTupfnoaKu6hAGMeYuTFr9rX0Lr7fB8vHXccmUizpALtzIS/PwmT3x8YXT8K66wl63 L5nwvw4bjmm+2nyyXby3TY4/1t6ZvcI5p4dY+xY/ouW3DRYzWTFcBcsnq5zXcISdSUmRQXeR /30lEd1opImirslyqO0GXQMkHboUcTAjnZuAelab+Jm72ieNr8YPAx3r6xOyGpm3YIrZVy1r lG0HmesIcSBRTcnD7l79yNTB1ykFGoyEBS29L7okYvGbf2UoUh5rD3PXklZKsoDWb/8sQqAe NuBMbT6LJfdk6bdWnQui1qzMa3Vno+Ex+aSgxa0/blnwR+jTR81Q8V1cYflnAP+NY0TIRF/f 3NNuBtmKtVRsEbYKphDKMKQNexCGbKXRXQWVjibGjPBeUCITbAupT36LI66KWjf4EJ1oI7nN DbXFZRpQcJCgvT4A21ret2Gzz2MReAtAXWu7ZjDsJCy87BrZLQQFi+dGw=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.88,288,1635206400"; d="scan'208,217";a="846628893"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Jan 2022 10:20:31 +0000
Received: from mail.cisco.com (xbe-aln-007.cisco.com [173.36.7.22]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 20EAKVXH010365 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for <roll@ietf.org>; Fri, 14 Jan 2022 10:20:31 GMT
Received: from xfe-rcd-003.cisco.com (173.37.227.251) by xbe-aln-007.cisco.com (173.36.7.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Fri, 14 Jan 2022 04:20:31 -0600
Received: from xfe-rtp-001.cisco.com (64.101.210.231) by xfe-rcd-003.cisco.com (173.37.227.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Fri, 14 Jan 2022 04:20:30 -0600
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-001.cisco.com (64.101.210.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Fri, 14 Jan 2022 05:20:30 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eCYHtkOnMbWnnWKn2HDk4r64oDniPgfGxYbTrh4+llUZY1Jsy8l4/ErITNgvYuBbVXQR6ulZCujKHRmK9qTynHqv0Z1DfJT93SJDJS3gHUMDgoB5NGVYNKFePn1s8TN2CyJ/QHlicdxfjteiRPl21ne0iXIFqSP9pn+Tmlr1ZrBEIvibG3zkyiKAAnAS/fMTVTjnuNMmofSMkP5J24G4uBgIcWcK3mLj6KVPuERze9gBWZ2su3JO1P2jBlb/BHb8q1m1hKjJCOAyDDcLkktkyBZRlDr2DpLqkktw7HEMFfM20S5G1xi+98cfnedk4AoDX/BWuzJrF+BPlIeE4cpUbg==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=DiClFGGDNb/6kxV3ZmaD9ifExAGYKv8iW19dB2RnKCQ=; b=AumZuXa4xaf3+L8HlDozsVExHdA/LFL7D033iayjLm07/JyWPLnupNiaSeKjmJBvvTZOQnZ6VZ2hdx47Si6V3kFF1CE6yT4rAabbUvpvgcU3KDgmEgrT0uj8l4EswRkkLW23MlUOJwNh1ckYU9JRcHzSKHxwcpOhR7RpIk5C2ivkQkiPz4dgb4nHA4M3A4Qm2+SwBLJQr+45uryuLAfej+HlpK3NB8Y9Wh5RGf29DffnxsM0VsUS0S5PfbiJYZNhRW3uXFOmLDZeaOYXpL4bAH8FpBRsSSTV3AFU7yZiCum23ixDuo3apaCGODfD5ztpZC7uhBCR0jmuAF+sK+2aWw==
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=DiClFGGDNb/6kxV3ZmaD9ifExAGYKv8iW19dB2RnKCQ=; b=VJXFjrXUcnkrhAbP3Uw0ZkPAq6Q2tySbgM5Ky4k0Dn51TBssMSs/EUf6rHu7r7Uqlqu+f/1gMTIB/Dnnp2/l8+/2byPGQL7C61aKLrW+EudHEaWV47/A4mn+tpwyPtvZtLhisjlSuK9HnoliTCjt8kAcnfvjSOStRqUl+Sn44T4=
Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by DM6PR11MB4331.namprd11.prod.outlook.com (2603:10b6:5:203::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4888.11; Fri, 14 Jan 2022 10:20:27 +0000
Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::709f:e8ff:325c:2b51]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::709f:e8ff:325c:2b51%8]) with mapi id 15.20.4888.012; Fri, 14 Jan 2022 10:20:27 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "ROLL WG (roll@ietf.org)" <roll@ietf.org>
Thread-Topic: (Was: review of dao-projection -22)
Thread-Index: AdgJJ9cj+2W7GoFsTae3G3ZQ5jeTyQ==
Date: Fri, 14 Jan 2022 10:20:14 +0000
Deferred-Delivery: Fri, 14 Jan 2022 10:19:51 +0000
Message-ID: <CO1PR11MB488196A1C6DA491569F8C523D8549@CO1PR11MB4881.namprd11.prod.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: fedd40fe-687e-45fa-36ea-08d9d7477c0d
x-ms-traffictypediagnostic: DM6PR11MB4331:EE_
x-microsoft-antispam-prvs: <DM6PR11MB4331C2030636C03F9FDA5415D8549@DM6PR11MB4331.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: krOkFVi3RYLksiMWpAmjSIYi2dXMWfbrtwF0VhQR/9HnT6dos56EltmwC1Y4okvJs7/zBNCN+KfOKju7eLltxQWxhF0i0lRA6DVInH8J9ZtdfxGnopZljDL8BJdFJFE3BGo+yokKY929d1w8iKez6BMaSR5nmZ9KPiamp3Hiz+ferZlotuXvXIw3haD+SXBjQiEO9Sm8R+KAav+jBweGOblueNxfLwZXQu+/7kcK2SZbrB1WBNcEVk0rOAIvf6mbNtUW8JBJqmQyNZZo89dtUHcmP71bbNsucrBhmzGFEkLfYlG89GchTaWzC7yLmErDvVPJEWZm53v8TYXzSq30eQ1aCt7F/z5mDeowan/Lz+PKdkFkwmZoU9GxYjoUNKpcMfwVnvHcRU9Iv7fCSnSoi+K2d1jWz57/pEx59l1hfT5z44csQlQJxgVdLSCwspK36L7J9ehlIo8QKeKKQcBUwkU+ZCQSOMeO7xmezS0Xkdk/p3zsxp9/W9F752Qjt9GhfOYz/wxUrs3kRl58Y5FkJNQCAt4EuLYKz4edBZ/33mIkJcpj0s2Gt/P8Xrb0zy6ZnMsungEW8i1Kh4SLtCKS4Zt6Kieu/+W7mOFLAvmmo7ZTl2XNh4nGyEUd0m8T2h3z6iFrLX7uzeOw5QO7l45afzTHee/EAXCVZPWSQ1f1F8oo26KFuabPrFKsGBSZv8v8ld5gxY5Gxhhf6PTjHR4X0GaRi2zX5/0dWVdjLorCknrL664/G+bPGMef+w93+4U2oqLcHOx/fuhjhCla1hEj2rirqpdPyQ8Mw6IW/KRvYEY=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB4881.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(316002)(107886003)(166002)(4326008)(52536014)(38100700002)(122000001)(33656002)(6916009)(7696005)(71200400001)(6666004)(8676002)(8936002)(5660300002)(66946007)(76116006)(66476007)(38070700005)(66446008)(64756008)(66556008)(9686003)(83380400001)(6506007)(2906002)(508600001)(26005)(186003)(55016003)(66574015)(53546011)(86362001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: x9DhbooAjW/cZc8QuJiYJCgZ2GyJHq98CP8ruTbZ+Ax4d5QsG7UvxsH+jBdHYogN5N65OGOktzAhwqMLuUxQvBb4+I5B1tRH1lFwlSmNPCJjCZCrsO0iejzzBXosck+J0iFP5EziLQiOv9GmbwQO30qwhO/QRvzo1dBmN8ZC18qWA0aNuNLCcTbl7f+vX3tKzVmLmRpcyXbK4k6d6LhWFrO62AUstieHtZJjE73x4oBcYaLuMUhf9Dl90JUMnOslOy6oE1UFZuQcT7a1TfG9qoK9t5f8ko1pNDEgLpVXCz0ej5LfLQD9hBqkFTd+1z1B/dj4T5p105Z7iGTA9EzL+KTr9P1xnEfJwChdqX1FW5pXpZj/WNASFi24UFpuHgHlmOneqwevBlHD+jTFZ/xMLTQQXMVfYWLoKB/PvS23ZRMzvGZ5HlLrQsGpRFL2Jz+5hH978ujHM+XR4WW6oD/sYR3GfpEpo7CkXsWf50nb/1BW6P+NLXedXLW6Uyr56L1Rbb1cjQ3CY9bpYCVETHhanDhIbfUw7RC6vlHqjW3LXOcWo19+NlTZ0cbZSDKN1bjFKA7X5JwpTeHgcEy735mke2eawDUYXLqP8FHjcrWIoeBkOkh/qqt5KCKJbLgIzTvv6jZFQcUuCO5zaz09AMEi6uISWraOAM2PtaHC5NitgwGvvdEBARVTXU9x8OWKOaDpSTJfmFq5CnxhQ1DvwQPWtsYBNlcIAZQ/Rr50SxBE02PZv6lwfnvO3Y1wjN7dwUy5U9qgZYb6gBNi6AqFsJKtVevTVXbPEoYFhNeoHVqBs9Wo5xxSxxzkIXn8r2fmgcsK4W/voHzkoqV19uDrB2VUEyPMIHjic5WB3BRjg4SV+GEo3bnyYB+eGg44mB9cWCscFdqtWnhOmO18NBQwDwEPCEEqUsDCXFkngTcukBVGcC7AnPYC0PvUHOBnf2Mt7qZ3vrNerRknxkhheEz0v038ZDHwiLJ+mZmb0oCOvS7Fk8SnoP4V4IefUheuL84DQH5dZwrWneiyQNlCcYOcnscALT1GPhhkiZc0G6fJpbqRd57k2Zt05rRMcS0CDJDjAIPNafkGNHwIwcekloAc5N/Xf3JcNJyZLmnFbRTrZEbatwcIHbK/FQTg0VXkVUZfdFUF0kuNlisyL+dGzFPweKDpTvcOJ+xjhdJsw70Bt3Jn8OejK9Cqje9lzEkUZg/+pIGQxUvdpVbaTh/WkMkHfSiLQDzh5uH9NtZgskai3MVbu4GQGMtPTToFoxUuyVdTwYbVaN9CwUEgTgtICAcUpEAWdNix1yiRq38kPPBTZvmB0bGRxDUxMrtIv00yJrZJrPiH5DRlnDTxUOuOADbMPdaW1h6g7jF3NdmBvJk5e6+IgmCsT95oe2BjD2YWo4PlaTkXcj1TDwE1YAB8f0FS4mPGXESRDFSkNOeNzlvl1DptNccRvDnsRlsobigE+L+Kos9VMSavqcMzrcyM6Unnxd3w0LoJNPtRVrKX/2LKvll1mcF1s755WCUwWqjcTwEGKSFgTlrvRPw8rkH4v0/a8X87tboYilMGna2WdaHlSe0if5dyQeGQLE1ry0lxJ2SaqTs7qPPcvpX6gWFMJC2qzINESqMBuro7/c+iUdBOSGsucH8=
Content-Type: multipart/alternative; boundary="_000_CO1PR11MB488196A1C6DA491569F8C523D8549CO1PR11MB4881namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4881.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fedd40fe-687e-45fa-36ea-08d9d7477c0d
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2022 10:20:27.2745 (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: jGlzzZfI7q1O/Kxu7OzYlUMd78ftwrt93BYZhRc/uEujIr+GuH+HIlYXMZKVUQYwlvliTtlP6srVKJir3Ep9Vw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4331
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.22, xbe-aln-007.cisco.com
X-Outbound-Node: alln-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/6Cr6kxy2X80bP9eMwAGP2lKtzTI>
Subject: [Roll] (Was: review of dao-projection -22)
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: Fri, 14 Jan 2022 10:20:39 -0000

Dear all: we had this thread as part of Li's review:


About "5.4 only the router with the lowest Interface ID in its registered address needs report the SIO, and the Root will assume symmetry."

[Li] -> Is it possible to add a flag to indicate the symmetry? Otherwise, if A chooses B as sibling, but B doesn't choose A as sibling, Root may treat SIO from A as symmetry incorrectly when only receiving SIO from A.

[PT] we used to have that (B Flag for bidir) but we removed it for simplification. I'm OK to add it back, but we still lake a good description of how the node will know that the link is roughly symmetrical.

[Li] Some physical layer measurements such as RSSI/LQI have forward and reverse direction. Can it indicate symmetrical?
                  In layer 3, receiving DIO/NS messages from each other indicate symmetrical

[PT] There's a nuance between bidir and symmetrical.  Maybe the ping works but the link quality is very different in both directions. If so the Rank increment computation would differ widely and we would need both sides.

At the moment the text says:
"
   B:  1-bit flag that is set to indicate that the connectivity to the
      sibling is bidirectional and roughly symmetrical.  In that case,
      only one of the siblings may report the SIO for the hop.  If 'B'
      is not set then the SIO only indicates connectivity from the
      sibling to this node, and does not provide information on the hop
      from this node to the sibling.
"

We need to clarify what the B flag means, when it can be set, and what is expected from the Root/ PCE about path computation when it is set or not set.

Suggestions welcome;

Pascal

From: Roll <roll-bounces@ietf.org> On Behalf Of Li Zhao (liz3)
Sent: mercredi 12 janvier 2022 10:51
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: [Roll] review of dao-projection -22

Hello Authors,

Thanks for your great effort. The PDAO draft looks more clear and detailed. Following is some concern:

3.5.2 Using Non-Storing Mode joining Tracks
P-DAO 1 signals C==>D==>E-to-F,G
P-DAO 2 signals A==>B==>C-to-C,F,G

   [Li] ->  Should it be ?
P-DAO 1 signals C==>D==>E-to-F,G
P-DAO 2 signals A==>B==>C-to-E,F,G

    Otherwise RIBs in A cannot include destination to E.

4.1. Extending RFC 6550
To ensure that the PDR and P-DAO messages can flow at most times, it is RECOMMENDED that the nodes involved in a Track ===mantain=== multiple parents in the Main DODAG, advertise them all to the Root, and use them in turn to retry similar packets. It is also RECOMMENDED that the Root uses diverse source route paths to retry similar messages ===ot=== the nodes in the Track.ΒΆ

[Li] -> Typo for "mantain" and "ot"?

4.1.6.
This specification defines a new flag "Projected Routes Support" (D).
The DODAG Configuration option is copied unmodified from parents to children. ====xref target='RFC6550'/>====  states that:

[Li] -> Typo for "xref target='RFC6550'/>".  Why is flag named as "D"? There is no D in "Projected Routes Support"...


5.1 The Root may use an asynchronous PDR-ACK with an negative status to indicate that the Track was terminated before its time.

[Li] -> What's the difference between negative status PDR-ACK and No-Path P-DAO in section 6.5?  And when to use asynchronous PDR-ACK?
In storing mode, root should use No-Path P-DAO to tear down Track from egress node. Is PDR-ACK still needed?
In non-storing mode, No-Path P-DAO to ingress node is also enough.
But the PDR-ACK Status field makes sense. Is it possible to add this field in No-Path P-DAO?


5.1 One and only one RPL Target Option MUST be present in the message.

[Li] -> Is it possible to remove the limitation?  It's not flexible If PDR can only carry one RTO.
For instance in figure 7, if node I requests P-Route to B&H together, Root can only push one Track I->A->B->H. Otherwise, Root may push two Tracks I->A->B and I->F->G->H.
If Root cannot computer one Track to multiple RTO, it can response with a special PDR-ACK Status.



5.4 only the router with the lowest Interface ID in its registered address needs report the SIO, and the Root will assume symmetry.



[Li] -> Is it possible to add a flag to indicate the symmetry? Otherwise, if A chooses B as sibling, but B doesn't choose A as sibling, Root may treat SIO from A as symmetry incorrectly when only receiving SIO from A.



6.2  There is no notification to the requesting node when those changes happen.



[Li] -> Confuse with this claim. Is it a MUST NOT if root wants to send notification to the requesting node when those changes happen.





6.3 In a particular deployment where PDR are not used, the namespace can be delegated to the main Root, which can assign the TrackIDs for the Tracks it creates without collision.



[Li] -> Can you add some description for the collision case? E.g., node trusts itself than Root.



6.4.1 In both cases the Track Ingress is the owner of the Track, and it generates the P-DAO-ACK when the installation is successful

[Li] ->  Is there any difference between P-DAO-ACK and normal DAO-ACK? E.g. any flags?  Normally, root won't receive any DAO-ACK from nodes.
Is it possible to add flag to distinguish P-DAO-ACK from DAO-ACK as P-DAO from DAO.


8 Profiles 0 and 1 are REQUIRED by all implementations that may be used in LLNs; this enables to use Storing Mode to reduce the size of the Source Route Header in the most common LLN deployments.

[Li] -> Profile 0 is the Legacy support of [RPL<https://www.ietf.org/archive/id/draft-ietf-roll-dao-projection-22.html#RFC6550>] Non-Storing Mode. I'm confuse about "this enables to use Storing Mode to reduce the size of the Source Route Header in the most common LLN deployments."



Best regards,
Li