Re: [Roll] Review of draft-ietf-roll-enrollment-priority-05

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Thu, 12 August 2021 09:47 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 9D2543A3FBA; Thu, 12 Aug 2021 02:47:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.599
X-Spam-Level:
X-Spam-Status: No, score=-9.599 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=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=eZhVkN1M; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=q4GFmImH
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 VQKARufN_LGJ; Thu, 12 Aug 2021 02:47:37 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F19A23A3FB8; Thu, 12 Aug 2021 02:47:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16051; q=dns/txt; s=iport; t=1628761657; x=1629971257; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4UUiaoXleSD+g8We2NmT/FLiZEBtl1ayAycpqguJ830=; b=eZhVkN1MwLTwL6068aLFLP6+M/NBDgvxeJ88KyCF7o4Sb5BWoqPmgTfN RrJWj4rAPiiw01STxvPRaToOjadDBFnP0QiNBGeFvLKJfATd1hbJWC0Sr SdHN0Rrjnw7jvI4WWhGg5P9s1VHUhFPWrhYAxf57sjlL5IYx9L9Y1e83b Y=;
X-IPAS-Result: =?us-ascii?q?A0DsAQCp7RRhl4MNJK1aHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?VmBUykoflo3MYgPA4U5iGkDj2+KRoFCgREDVAsBAQENAQEqCwwEAQGBIIM5A?= =?us-ascii?q?oJmAiU4EwECBAEBAQEDAgMBAQEBBQEBBQEBAQIBBgQUAQEBAQEBAQGBCIVoD?= =?us-ascii?q?YZCAQEBAQIBAQEQLgEBLAsBBAcEAgEIEQQBARYZJwsdCAIEDgUIEweCTwGCV?= =?us-ascii?q?QMOIQEOnjoBgToCih94gTOBAYIHAQEGBASFKhiCNAMGgTqCfYJyU4cuJxyBS?= =?us-ascii?q?USBFUNUgQ2BAT6CYgEBgRkNBBgFGz2DDoIugnsRAVoGPhwODSIUEAQFDgs5A?= =?us-ascii?q?h4dLRoJARoQDBQKAh8KD5E4jXqddwqDKJ5mEqZzhTuwbAQEC4R0AgQCBAUCD?= =?us-ascii?q?gEBBoF3IoFbcBU7gmlQGQ6OHxmBDQEHCAeCNYUUhUpzOAIGAQoBAQMJiC5eA?= =?us-ascii?q?QE?=
IronPort-PHdr: A9a23:uY/4NBf76rWx83FsChNnnw4+lGM/qYqcDmcuAtIPir9SfOKk5Zuxd EDc5PA4iljPUM2b7v9fkOPZvujmXnBI+peOtn0OMfkuHx8IgMkbhUosVciCD0CoLfP2YWo9B ssRHFNg9muwZE5SHsu2blbOo3q0uDgVHBi3NQd8KunvXIDIiMHi3OGp8JqVaAJN11KA
IronPort-HdrOrdr: A9a23:hbPRZ6MWf0Bl78BcT57255DYdb4zR+YMi2TDiHoRdfUFSKKlfp 6V88jzjSWE9gr4WBkb6Le90dq7MALhHPlOkMos1NaZLUnbUQ6TTL2KgrGSuAEJlUfFh5RgPM tbAs1D4ZjLfCdHZKXBkUuF+rQbsaS6GcmT7I+0pRoAPGIaCZ2IrT0JdjpzeXcGIjWucKBJbK Z0kfA33gZIF05nCviTNz0gZazuttfLnJXpbVotHBg88jSDijuu9frTDwWY9g12aUIL/Z4StU z+1yDp7KSqtP+2jjXG0XXI0phQkNz9jvNeGc23jNQPIDmEsHftWG0hYczEgNkGmpD31L8Yqq iVn/7mBbUp15rlRBDynfIq4Xi77N9h0Q6+9bbSuwqSnSWwfkNINyMGv/METvMcgHBQ4u2VF8 lwrj2kXtNsfGH9tTW46N7SWx5wkE2o5XIkjO4IlnRaFZATcblLsOUkjQ9o+bo7bWjHAbocYa RT5QDnlYBrWELfa2qcsnhkwdSqUHh2FhCaQlIassjQ1zRNhnh2w0YR2cRaxx47hdwAYogB4/ 6BPrVjlblIQMNTZaVhBP0ZSc/yDmDWWxrDPG+bPFyiHqAaPHDGrYLx/dwOla6XUY1NyIF3lI XKUVteu2J3c0XyCdeW1JkO6RzJSHXVZ0Wn9iif3ekwhlTYfsurDcSuciFbryKQmYRXPiSAYY fHBHt/OY6VEVfT
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.84,315,1620691200"; d="scan'208";a="729236053"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Aug 2021 09:47:35 +0000
Received: from mail.cisco.com (xbe-rcd-007.cisco.com [173.37.102.22]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 17C9lYe8016295 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Thu, 12 Aug 2021 09:47:35 GMT
Received: from xfe-rtp-004.cisco.com (64.101.210.234) by xbe-rcd-007.cisco.com (173.37.102.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 12 Aug 2021 04:47:34 -0500
Received: from xfe-aln-003.cisco.com (173.37.135.123) by xfe-rtp-004.cisco.com (64.101.210.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 12 Aug 2021 05:47:33 -0400
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-003.cisco.com (173.37.135.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Thu, 12 Aug 2021 04:47:33 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=P40A1aI5HNzdHzyCxw9GXpSD7mpxIF88Nn8n5APYwX1hmQelDUqHmn1gnbxsONzgPNOrMZprX7Q/KjlAA0F5lTtrqNUTZ97H0YvaxtYeVv0C/9clxoGB9AVjDXsAJ5eZWdpVE7L8aV7inu22H0erBCfrXM5O5lt3xdKJ9ydOPR/m79q0bT/y7yYRgEcUqnE0QUcUCbGOGPWyG9iJRq0PcFmQ0nPv0+LULam5Bk2mcZyjfB+E8LJEzCZpv7XBbDrqtxKsLj8IszibLpiLRLi8Y1nFHKtDsj0Ka/tGInE55lY+ImkY66rgsXZgWN4LmDPzjfvjS9fZDq48NcyUiXiT6Q==
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=pk7UJ9qZkUmNJYd4tuTIpNixR/99BQ2OU43RnNurhno=; b=ix+fn/un5hEGy29zGQeS9CPu8rtbN4+N06WW7KACEdfCqeU2+UOiEUA/ekDdl+N3m3ChgEN3f/EKt8KBLKRE0EhLpXOj4iCeKh7LDWwg3ZvnBsXFcip0H2r3NQJtB3MgOnL8qr2gXuJHw+kxeQ9LdThSJK4Hs1vaosTcvvnC630u6Gj55erW6DU3r9W286c3F51jFWPRPgXS6jKfQ4/0ks61oWVhArqw5zD+j4hDYtdvfO97AZCRo51nHA8scmwCIERjZo5JgpccaIvgkjAjy6QN1y6HL+LZA6jJsb06nG0PaXfMC323vCaQFYqW6atnPl5ZP2alsalhdhZZ7zxHJg==
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=pk7UJ9qZkUmNJYd4tuTIpNixR/99BQ2OU43RnNurhno=; b=q4GFmImH4meIuzVkfonoc1TnkpLs1ep5cNfjukSKqulEa4JqmH0hU60aKj90TVkx++BCxssi5WarvkoNecSa+BEqiHn/MPGDUmI8XM1zM1uSqhqzQqb/I2PMb6dXs4UB5tZ/RKcaV8QHXx4wzPhcZjJ5XXe7RX8G+BtMS3Q3dcE=
Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by CO1PR11MB4996.namprd11.prod.outlook.com (2603:10b6:303:90::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4415.17; Thu, 12 Aug 2021 09:47:32 +0000
Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::487e:47b8:314f:189a]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::487e:47b8:314f:189a%7]) with mapi id 15.20.4415.018; Thu, 12 Aug 2021 09:47:32 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
CC: roll-chairs <roll-chairs@ietf.org>
Thread-Topic: [Roll] Review of draft-ietf-roll-enrollment-priority-05
Thread-Index: AQHXjvdeih/QhHt6aEmURQMfl9q056tvmydQ
Date: Thu, 12 Aug 2021 09:47:16 +0000
Deferred-Delivery: Thu, 12 Aug 2021 09:46:28 +0000
Message-ID: <CO1PR11MB488177A3BBB15404F812521FD8F99@CO1PR11MB4881.namprd11.prod.outlook.com>
References: <f7a504ac-764d-09e9-d969-067e6a21646a@mimuw.edu.pl> <CAO0Djp1Dmj-CSp+GvGrRh+NmL70PekSLLjsnbfKTGHFPOurYXQ@mail.gmail.com> <CO1PR11MB48812CDAA6A2E3DC818FC0C8D8F39@CO1PR11MB4881.namprd11.prod.outlook.com> <9b7eabc7-e521-bf82-4087-c65e08fc9fc0@mimuw.edu.pl>
In-Reply-To: <9b7eabc7-e521-bf82-4087-c65e08fc9fc0@mimuw.edu.pl>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ceaad4ec-dca8-447e-c0bd-08d95d7634cb
x-ms-traffictypediagnostic: CO1PR11MB4996:
x-microsoft-antispam-prvs: <CO1PR11MB49968C20E101C3A3E40B9BEED8F99@CO1PR11MB4996.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: QOvLbnWEc67s1Qfl0TPg1A2S0LBtPrVEamYNRHH8zNHvR0Xld1+1V/Gxyd1eBxvf+DIV/rCl29LTCx3ryzA2Bk1BWyN1csaYoKbmQg3hjNFltzuvF6B4HLRuUIrIpF45vQkPQPaCgAPXQfYUCGfy+GP/wtWpJOdcEwEeKxKIBU6VniV2Srp2GKix6ifmMn1oqeaGOBRlZaLP2UeNA0os2X1llq7XFMXLevLScUX6XwOmKHk/tZoQsnsemStBVXsHKJgQjoI0Itv4q5197PF4vgOm1rMJ8crCUjnLmC6sDQTO15Sd/LGDFwQj9PTSUud6Tghh8lhqhMmT+OW4dXZm3pg6vMe3wcXlnUKXUz3dF8Ze8BrhA4bgIBu4g6SC2R6gYISNq5qFDhX127REos61UZPzBWztp2sN51kbDYsnPq2W0ixa/mryfN/0vXPTZGQsOqpyCmaoRdvj8nEalUXuMNGwPk3vZsVP3LX+nQM3fn29AgyW+RQoyQGTWZrOf3bIBPAzf1AJNtzE/HAKDFrTtE6/xQEil8wii9XJSdcaUgxpMU4mWOHTczZSHsjn8/3CuMODIN96oeWhmEl2aMVEfq6AO+LficzwRx6NDNezL9xvsmu3mwDhylUVOiC+YAtLLww8E7oWGLAROJtBPH3pOE8+TMFqSS55Nx2bUNoCdfeA5d3VlXme3Tvwvc8lJYnYe24lho0rP6iZFLh+/WmOyJrQJ07Y4UWVgMo+Z7TMqKgCyQ4AEC1xKQCDO3fJUJ36xdddtVfdSTQa5WFGeYyuuFPJv7it1eMUBUqn/B0QBZ4=
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:(136003)(366004)(39860400002)(376002)(396003)(346002)(122000001)(55016002)(8676002)(8936002)(38100700002)(76116006)(66946007)(33656002)(9686003)(186003)(64756008)(66446008)(2906002)(66476007)(66574015)(30864003)(66556008)(6666004)(966005)(316002)(71200400001)(6916009)(86362001)(83380400001)(53546011)(7696005)(6506007)(450100002)(52536014)(478600001)(4326008)(5660300002)(38070700005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?8FAaZzxKR0mW7LK+W0URuuSuTzI+wj7mqvrYyiLyIrEi0nPWXAIJIrR/xO?= =?iso-8859-1?Q?cSvZBYmN+7UZUX+baqPEGVSNCcSNXU+jKhBgOYy+cro+7bY8lYLe2ws2x2?= =?iso-8859-1?Q?q6cJ2s6WDEIMrgFNVAHeeBTxAtybyEMXPXsSBVnTk+HV/Df88nXxKbySFq?= =?iso-8859-1?Q?YaW/bUtdF2ecE9qXDb+DQuWZNPvA8LqCf7jg99WO0zrESVqGBDM1gQ6WJA?= =?iso-8859-1?Q?SZQ1EOUuqNkJHkggKW9iPbS8FDTTTVLGevrmnLzqzN33ttC3bl9uG8xZBr?= =?iso-8859-1?Q?Bub0arcaJ/dSWkrr7osMQtewH6HIgNOnJMiYrCwSWZZL2FTzmVTjddV3ml?= =?iso-8859-1?Q?rf2zt+dj0e3GXI6KkgHWVFB1kY6Y9SoTJw1j2Fnf/V36/Hbno2vypRb8Dc?= =?iso-8859-1?Q?bMCU11WR5UmtNJOsukOZ0IEmzhDQEDrAeVY1xi8MFAiiysa1jOFPsI7T5y?= =?iso-8859-1?Q?RxM0K4YB5Q4PO1j77RqH63Ip0Ne4iqCJLIQn/mHx5pdrMn4s3NhrhdRz9D?= =?iso-8859-1?Q?To19UW0Cjy2ENKWdzsgdDGAZ81JnvQ2r+cr1TNcP4AYKviyrtu+sKSIZK5?= =?iso-8859-1?Q?n1VH65SyJIEDF2dIDxsrV5U3I8XA02Ou2/AqYeNOJ2US659X18RHqkupQZ?= =?iso-8859-1?Q?bft8EXZ9FLzZ8kYmizmR95Xsg5mwxVngHiMm6CvdUjDxBlQed3OyRle/fJ?= =?iso-8859-1?Q?XA0OaLSaLmDGEs4K2E8lhdmBw3HoNfDebjmaRlI3eq/8eiqqOkk3dLrE/q?= =?iso-8859-1?Q?JDTz1HuEF4tnbdla3mS/c2D/DWJ9CbT0g3q00TXw0WIBEeLQe0dSn/4ByZ?= =?iso-8859-1?Q?+Tm9S7zkcuiYba7waJ+0hOsJ7pFU1e6jtgt8/JQ5GQNDtl3dqHm5oDgZNI?= =?iso-8859-1?Q?ChoyU+/tLSDsPqsG2zt0vB835YNU96CAio2UzkHoJ2faHCduqd/ZS8Xbsi?= =?iso-8859-1?Q?BrZaSpkBZsozo0nlgJh24MmF9PNy3ITojWJ/dqF3ou4cvodbvbcyGB062J?= =?iso-8859-1?Q?mEQgcw9MPc375BOK8f/X4dX0q9EhAhygMDxHTpn/T2BHJb8SQo7kTmquNB?= =?iso-8859-1?Q?5Qjh/eC8uz5nJ7ycX6FSqH6RC+rT19QHZOoIO/8wn8whUat6zpauep7Kdv?= =?iso-8859-1?Q?yoRRLNArax5KrCpnPaEmK0YbWV4B3cQjRCn2IIa+1F2HVVQLh/+4p2l7wY?= =?iso-8859-1?Q?TzOlggPSS6wkMPkoXsgDRojR1lGkW052FAoNGYshpv5iF+fo3YNufKMgC9?= =?iso-8859-1?Q?ZrP9u2hKPU9R6rhk1ZUg6Cct7tnaxiEeLjky4T2NUr9pjcOGhi6259BOvS?= =?iso-8859-1?Q?NzHBK5LOq+k9lWY6TwoM2eLwhsTZKH5D+eVq6htQ34pF8iMpb5QtHrOKkS?= =?iso-8859-1?Q?nJ9UJv2/jy0MQkMFgGtabBRAHRxoh41BamtMg96Q2Wjrp07s/GXLRVdFsO?= =?iso-8859-1?Q?+HVeIWVfX8aXte9C?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
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: ceaad4ec-dca8-447e-c0bd-08d95d7634cb
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Aug 2021 09:47:32.1046 (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: 0lQVsdVshrWtd68IJUIBaXHI9/lwWQJwgrQXqFsE1CnLjt7PvIB4V9jbOkulPgr4fqMxduKG3lFCzJvO99Oexw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB4996
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.22, xbe-rcd-007.cisco.com
X-Outbound-Node: alln-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/2MaZ4wXLVzJbmLC-LO6c--DsbWQ>
Subject: Re: [Roll] Review of draft-ietf-roll-enrollment-priority-05
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: Thu, 12 Aug 2021 09:47:43 -0000

Hello Konrad, 

This is great explanations of both options and how they could be made to work.

 What we need to add is, what do we want them for, which use case are we serving?

GLOBAL serves the need for a node to compare the load of the current DODAG with that of other DODAGs it could jump to. The use case is balancing DODAGs. 

FLEXIBLE gives an indication of load of a preferred path. What would be the use of that?

- in storing mode it could indicate the capability of creating DAO state. But you'll find looking at it that you'd need a lot more than good or bad. If a node moves to another parent and has 100 children it needs to know that the new parent and its path up to the root have 100 rooms left. OK, it would split the DAOs between 2 parents, but if the bottleneck is up there where the paths from the parents cross, it fails. Bottom line, hard problem that we avoided so far.

- in any mode, it could indicate the throughput load. But then: 
  * usually (P2MP or MP2P with homogeneous radios) that overload affects primarily the root's radio space, so there is no benefit in increasing the minimum, the root's one is the worst already. 
  * there's the need to normalize the increment, IOW to explain by what the min value should be increased by the 6LRs and when so the result down there is comparable between preferred parent chains. Like the Rank computation which imposes a single OF, you need to impose a single operation throughout. From there, all the problems of updating OFs, using multiple OFs, etc...
  * the real need would be to rebalance the tree, but rebalancing a tree in a distributed protocol is another hard problem, subject to loops

So what is FLEXIBLE for? Convince me we need it and I'll support doing both.

On the side, I completely agree with you sequence counter in any case. The counter should follow section 7 of RFC 6550, including freshness assertion, etc... in which case there's little additional to describe.

Keep safe,

Pascal



> -----Original Message-----
> From: Roll <roll-bounces@ietf.org> On Behalf Of Konrad Iwanicki
> Sent: mercredi 11 août 2021 23:25
> To: Routing Over Low power and Lossy networks <roll@ietf.org>
> Cc: roll-chairs <roll-chairs@ietf.org>
> Subject: [Roll] Review of draft-ietf-roll-enrollment-priority-05
> 
> Dear Rahul, Pascal, Michael, and all,
> 
> As promised, I am sending my remarks about the enrollment priority draft,
> version 05, so as to point out the issues I have with the draft, thereby
> providing some starting point for discussion at the August interim. Sorry
> for the text being rather lengthy, but I wanted to highlight all major
> issues that came to my mind. I am not providing any editorial changes,
> because those below are more important at this point.
> 
> 
> PROTOCOL OPERATION WRT. FIELD MIN PRIORITY
> 
> Based on your comments on my previous review, I gather that there are two
> different ideas on how the protocol should work, clarifying which was also
> the reason for the questions I put in my previous review (of the draft
> version 04).
> 
> Unless noted otherwise, the text below refers only to the management of
> field min priority. In other words, let us completely ignore field
> DODAG_Size for a while. We will return to it later.
> 
> 
> IDEA 1 (GLOBAL)
> 
> The first idea on how the min priority field should be managed is
> supported by Pascal, and I will refer to it as GLOBAL. Essentially, it
> works as follows:
> 
> 1. The min priority values are generated solely by the DODAG root node;
> other nodes are not allowed to change these values.
> 
> 2. A node extracts the value from a received option, stores it locally,
> and uses it as a base when computing the proxy priority for EBs, which may
> also account for the node's local constraints (e.g., load); however, per
> 1., only the originally received (and stored) value of min priority is
> used in the options in DIOs sent by the node.
> 
> 3. An option received from ANY node can be used as the source of the min
> priority value but the receiving node has to be able to judge whether the
> received value is fresher than the one it already stores locally.
> 
> 4. To this end, a lollipop sequence counter that I proposed, let's call it
> OSN, can be used. I suggested adding it to the option, but others
> suggested using some existing counters. This is immaterial for now---more
> on that later; instead, let us just assume that we have OSN mapped to some
> counter.
> 
> 5. In any case, the root node bumps its OSN when it produces a new value
> of min priority. (This condition can also be relaxed but I'd rather not
> make this text longer. We can discuss this during the interim.)
> 
> 6. Whenever a node receives an option with a value of OSN that is greater
> than its own local value of OSN, it adopts the received value of OSN and
> the received value of min priority as its local ones. Those values will
> then be sent in the options in DIOs transmitted by the node.
> 
> This is a really simple and robust solution. Its main advantage is that
> there are normally many paths that allow a node to learn the value of min
> priority, which alleviates the problem of nodes that do not support the
> option or nodes that experience (temporal) down times, overload, and the
> like. The problem of the different paths being asynchronous, and hence
> offering different propagation times for the values of min priority, is in
> turn solved by OSN: the counter unambiguously discriminates between
> fresher and older values. The effect is that as long as each node has at
> least one neighbor (not necessarily a parent) that supports the option,
> the min priory values will be eventually consistent globally.
> 
> In contrast, the main drawback of this solution is that the value of min
> priority is global. In particular, it does not take into account any
> heterogeneity in the load, available resources, etc. in different regions
> of the DODAG.
> 
> 
> IDEA 2 (FLEXIBLE)
> 
> Michael and Rahul thus advocate an alternative idea, let's call it
> FLEXIBLE. In this approach, it is possible to adjust the value of min
> priority per node by incrementing the base value the node has originally
> received. Although the new version (05) of the draft does not describe
> this in sufficient detail, from Michael's comments I gather that the
> envisioned solution is something as follows:
> 
> 1. The root sets a value of min priority in the option in its DIOs.
> 
> 2. A non-root node obtains the value of its min priority only from an
> option received from its preferred parent and stores this value locally.
> It can then only increase the local value, for instance, accounting for
> its local constraints, before putting it into EBs and the options
> transmitted in its own DIOs to its children. In other words, the value of
> min priority can only grow at each hop, reflecting the local constraints
> of the nodes on the path upward to the root.
> 
> 3. Since for each node, there is only one source of min priority values
> (its preferred parent), there are no conflicts. Consequently, in theory,
> we could omit OSN, as is the case in the current version of the draft.
> (This approach is wrong, as we will see shortly.)
> 
> 4. To be compatible with the DIO processing rules in RFC 6550, a node
> receiving an option with min priority from any neighbor performs the
> processing according to the following rule (currently missing in the
> draft): "When processing the option, a node ignores the value of min
> priority in the option if the option does not come from the node's
> preferred parent." (This rule is again wrong, as we will see shortly.)
> 
> 5. If the node's preferred parent does not support the option, the node
> assumes a default value (0x40) for its local min priority. This value,
> potentially increased to account for the node's local constraints, is put
> in the options in the DIOs transmitted by the node to its children.
> 
> The main advantage of this approach is that the min priority value can be
> adjusted in a DODAG subtree. The approach thus offers much more
> flexibility in configuring the values: an entire subtree that is
> overloaded or experiences other problems can adopt a higher min priority
> values so as to deflect enrollment traffic to other parts of the DODAG.
> A disadvantage is in turn that the approach precisely defines the path
> along which a node has to learn its value.
> 
> 
> PROBLEMS WITH IDEA 2 (AND A POSSIBLE SOLUTION)
> 
> However, because of the existence of just a single path for propagating
> min priority value to each node, FLEXIBLE, as presented hitherto, is
> wrong.
> 
> To explain, an important use-case, mentioned also in the present version
> of that draft, is disabling enrollment in an entire DODAG. This is done by
> the DODAG root setting its min priority value to 0x7f. Now suppose the
> DODAG root has done this and that there exists a node, let's call it X, in
> the DODAG that does not support the option. The children of node X would
> thus adopt values 0x40+delta (depending on their local
> constraints) as their min priority values. Since 0x40+delta need not be
> equal to 0x7f, an entire subtree of node X need not disable enrollment,
> which is invalid.
> 
> In general, in FLEXIBLE, nodes that do not support the option are a major
> problem, as their ancestors disregard any decisions of upstream nodes,
> including the root. The problem can be solved as follows.
> 
> - We use multiple paths for propagating min priority information but one
> of them is preferred by each node (the one through the node's preferred
> parent).
> 
> - To ensure consistency, we do employ the aforementioned OSN. Again, for
> simplicity let's assume that it is incremented whenever the DODAG root
> produces a new value of min priority but, like in GLOBAL, this condition
> can be relaxed.
> 
> - There is no default value (0x40) a node ever adopts for its min
> priority. (Apart perhaps from the value accompanying the initial OSN
> value.)
> 
> - Each node locally stores:
>    * the last value of OSN
>    * the accompanying value of min priority
>    * a bit, let's call it PB, indicating whether the above values come
> from the node's preferred parent (1) or not (0)
> 
> - In contrast, to the present version of the draft, we maintain the
> following invariant:
>      "For a given OSN value, the value of min priority at any node is
> greater than or equal to the value of min priority at the root node."
>    This is to ensure that no node, including the children of a node that
> does not support the option, is able to override the root's setting of min
> priority down for a given value of OSN. In particular, the invariant
> ensures that if the root disables enrollment globally, then so will all
> nodes (under the same assumptions on connectivity as in GLOBAL).
> 
> Given these points, the specific rules for processing the option are as
> follows:
> 
> 1. If a node receives an option with a greater value of OSN than its local
> one, then eventually it adopts the received values of OSN and min priority
> as local ones, and sets PB appropriately (i.e., to 1 if the option is
> received from its preferred parent or 0 otherwise). It does not have to do
> this immediately. In particular, it may wait for a while to receive the
> option with the greater OSN from its preferred parent.
> Nevertheless, eventually it MUST adopt the greater OSN (and an
> accompanying min priority).
> 
> 2. If a node receives an option with the same value of OSN as its local
> one then:
>    a. if the option is received from its preferred parent, then it adopts
> the value of min priority from the option and sets PB to 1.
>    b. otherwise,
>      i. if its local PB is 1, then it ignores the received option;
>      ii. if its local PB is 0, then it sets its local min priority to the
> minimum of its local min priority and the value of min priority from the
> option
> 
> 3. If a node receives an option with a smaller value of OSN than its local
> one, then it ignores the received option.
> 
> 4. If a node changes its preferred parent, then it sets its PB to 0.
> 
> 5. If a node sends the option in its own DIO, then it puts in the option
> its local value of min priority or a greater value (e.g., taking into
> account the node's local constraints). It can never sent the option with a
> lower value of min priority than its local one.
> 
> This should do what I would expect from FLEXIBLE. However, I wrote this up
> in a haste, so it would be great if somebody verified the above algorithm.
> 
> As a side note, the algorithm suggests that FLEXIBLE is indeed a bit more
> involved than GLOBAL, so a decision should be made, which of them to put
> in the draft.
> 
> 
> FURTHER ISSUES UNCOVERED IN THE DRAFT OR TO BE DISCUSSED AT THE INTERIM
> 
> Irrespective of the decision whether to settle down on GLOBAL or FLEXIBLE,
> I believe that the following issues also have to be covered in the draft
> (and discussed during the interim).
> 
> 1. Should DODAG_Size be part of the option?
> 
> I mentioned this in my previous review and there has been some discussion
> already. I would just like to add one observation to that
> discussion: whereas min priority can follow either GLOBAL or FLEXIBLE, I
> believe there is an agreement that DODAG_Size should follow GLOBAL when it
> comes to propagating its value in the network. This information may
> influence our decision on which of the approaches to adopt for min
> priority and whether to put DODAG_Size in the option at all or move it to
> another one.
> 
> 2. Which counter to use as OSN?
> 
> I proposed a dedicated counter, which I believe is a clean solution.
> However, there are other possibilities. I also believe that we agreed that
> DTSN from DIO base is not the best choice. In my view, nor is DODAGVersion
> but we can discuss this.
> 
> 3. How do changes to min priority (and OSN) affect DIO Trickle timers?
> 
> This is currently not covered in the draft. However, I would imagine that
> some decisions regarding min priority should be propagated fast in a
> DODAG, and hence require Trickle timer resets. In particular, I would
> expect that disabling enrollment globally should be disseminated as soon
> as possible. Therefore, if I were to suggest anything, I would say that a
> change by a node of min priority to the maximal value (0x7f) from a lower
> one MUST entail a Trickle timer reset. In turn, a change from the maximal
> value to a smaller one MAY/SHOULD entail a Trickle timer reset.
> Other changes are, at least in my view, not that important, but this can
> and should be discussed.
> 
> 4. How does a (temporal) lack of a preferred parent affect the proxy
> priority of the node in EBs (and in general, the node's behavior)?
> 
> This is also ignored in the draft but it may happen that a node does not
> have any preferred parent for a while. In this case, it is unable to
> handle any enrollments. What should it do? I would expect that it would
> advertise the maximal proxy priority in EBs. However, should it also
> modify its local min priority? I would probably be against.
> 
> Plus there are smaller issues I mentioned earlier, and I probably forgot
> something. In any case, sorry again for such long a text but I hope it may
> help during the interim.
> 
> Best,
> --
> - Konrad Iwanicki.
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll