Re: [Roll] Review of draft-ietf-roll-aodv-rpl-13

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 29 June 2022 06:53 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 2903EC15CF3E; Tue, 28 Jun 2022 23:53:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.604
X-Spam-Level:
X-Spam-Status: No, score=-9.604 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_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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=J+YP/vsa; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=f8dPHKqe
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PgZf_lui4mA; Tue, 28 Jun 2022 23:53:00 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92EA6C15AE2D; Tue, 28 Jun 2022 23:53:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36198; q=dns/txt; s=iport; t=1656485580; x=1657695180; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=C9l2hrO19cDctcXkUngkPaLldndDWcLhKEyy1zRQPuo=; b=J+YP/vsaQerUYkoC4vEadwQjDmMoK49OatpeCV4IjM/JrOHzxUzboK03 SmPQ0J8Zc6qvCfF0EPdoama6hDOcWQ5bXgJX2EddXfWaRWLM9f2MF1xOr YbPKJ2Xl7vQMN61oFq8v13hQmugTwKtaeSHdcpXlVVf56SxNa5l/aSy9e E=;
X-IPAS-Result: =?us-ascii?q?A0BNAACX9btimIENJK1QCh0BAQEBCQESAQUFAUCBPgUBC?= =?us-ascii?q?wGBUVJ/Alk6RIROg0wDhTGFC4MCA4ETjz+KdYFAgREDVAsBAQENAQE3CwQBA?= =?us-ascii?q?YUDAhaFNAIlNwYOAQIEAQEBAQMCAwEBAQEBAQMBAQUBAQECAQcEFAEBAQEBA?= =?us-ascii?q?QEBHQcGDAUOECeFOwYnDYZCAQEBAQIBEggJEQwBATcBBA0BBgIOCgICJgIEM?= =?us-ascii?q?BUSBAENDQ0NglsBgmUDDSMDAQ6QLo85AYE/AoofeoExgQGCCAEBBgQEhQ4Yg?= =?us-ascii?q?jgJgREsAYMVgwtfTYcsJxyBSUSBFUOBZko3PoJLFwSBJAUBBwsBIxWDPzeCL?= =?us-ascii?q?plZHDkDRy8SgSBuAQgGBgcKBTAGAgwYFAQCExJNBhwCEgwKBhUOQhIXDA8DE?= =?us-ascii?q?gMRAQcCCRIIFSsIAwIDCAMCAyALAgMWCQcKAx0IChwSEBQCBBEeCwgDGR4sC?= =?us-ascii?q?QIEDgNCCAsKAxEEAxMYCRYIEAQGAwgvDScLAwUPDQEGAwYCBQUBAyADFAMFJ?= =?us-ascii?q?AcDIQ8mDQ0EGwcdAwMFJQMCAhsHAgIDAgYVBgICGFYuDQgECAQYHyQPBQIHL?= =?us-ascii?q?wUELwIeBAUGEQgCFgIGBAUCBAQWAhAIAggnFwcNBjMZAQVZEAkhFgYpCgYFB?= =?us-ascii?q?hYDIUomBUUPKDMBNjwsHxsKgRosCSIWAwQEAwIGGgMDIgISKQY5AxkFBCAbm?= =?us-ascii?q?wwKEFsGF00EDQEGGwMRDgIETBATCAoTCC0RCgEUBgIOHgELKw+RbyqDVIpLo?= =?us-ascii?q?FMKg06LIZUSFYN1gVCKcwOGX5FKlnIggiufOwiFCwIEAgQFAg4BAQaBdyRrc?= =?us-ascii?q?HAVO4JoCUgZD4R2iSoMDQmDUIUUhUp1AgEBNwIGAQoBAQMJjDkHgkEBAQ?=
IronPort-PHdr: A9a23:SqBt5hK8ZkQiIYFROdmcuWEyDhhOgF28FgIW659yjbVIf+zj+pn5J 0XQ6L1ri0OBRoTU7f9Iyo+0+6DtUGAN+9CN5XYFdpEfWxoMk85DmQsmDYaMAlH6K/i/aSs8E YxCWVZp8mv9P1JSHZP1ZkbZpTu56jtBcig=
IronPort-Data: A9a23:y6mZsaDQmCTToBVW/xDjw5YqxClBgxIJ4kV8jS/XYbTApD4rgTVVn 2YeXD/TMquKazf2c9lxaI6/909V7MCEztVrOVdlrnsFo1CmBibm6XV1Cm+qYkt+++WaFBoPA /02M4WGdIZuJpPljk/F3oLJ9RGQ7onVAOumYAL4EnopH1U8Fn1x0UkLd9MR2+aEv/DoW2thh vuqyyHvEAfNN+lcaz98Bwqr8XuDjdyq0N8qlgVWicNj4Dcyo0Io4Kc3fsldGZdXrr58RYZWT 86bpF2wE/iwEx0FUrtJmZ6jGqEGryK70QWm0hJrt6aebhdq4XY+14gFDPclUE5IrCWgwpMy0 d4TnMnlIespFvWkdOU1Wh1cFWR1OrdLve6BKnmkusvVxErDG5fu66wxVwdtY8tBoaAuWzAmG f8wcFjhajibm+Kryr+hVsFnh98oK4/gO4Z3VnRInWCIXKx/HMydK0nMzf1p9hA63OVuIezPY swIdAtBLzD/YAIabz/7D7pnzLv32RETaQZwslWRoYI27nTdigtr39DFPMDcdMDPRMhJkAOCo WbCum3+Dg9fLsSbjzOB9lqti/PB2yThV+o6H72x7PprjUW7wnELCRsSUle0rL+yjUvWZj5EA 0UQ/ixrpq8o+Qn6CNL8RBa/5nWDu3bwRua8DcV9sg2I5JTs7j+gD3cjXhccK58/v5EfEGlCO kCyo/vlAjlmsbuwQH2b96uJoT7aBcTzBTJcDcPjZVZZi+QPsL3fnTqUFY86T/DdYsndXGCun W/b9UDSkp1J1aY2O7OHEUcrat5GjrHNSgMzjuk8dj34tloiDGJJinDB1LQ2xf9EKIDcRV6bs T1V3cOf9+sJS5qKkURhodnh/pn0uJ5p0xWF3DaD+qXNERz2oBZPmqgLullDyL9BaJpsRNMQS Ba7VfltzJFSJmC2SqR8fpi8Dc8npYC5S4m7CqyNNoERPcMgHONiwM2ITRPAt4wKuBVx+ZzTx b/AGSpRJS9AUP8+nGbeqxk1iOR3m0jSOl8/tbiin0j4jtJylVaeSKwONxOVf/sl4aafyDg5A P4BX/ZmPy53CbWkCgGOqNZ7BQlTcRATWMGtw+QKJ7HrClQ9QgkJVaSOqY7NjqQ4xcy5YM+So ivnMqKZoXKi7UD6xfKiMCgzM+6wA8Yn8RrW/0UEZD6V5pTqWq73hI93Snf9VeBPGDBLpRKsc 8Q4Rg==
IronPort-HdrOrdr: A9a23:xB3Y4q2sSiVcbP5fIBQSjQqjBR9yeYIsimQD101hICG9Lfb3qy n+ppsmPEHP5Ar5AEtQ5OxpOMG7MBfhHQYc2/hcAV7QZnibhILOFvAs0WKC+UysJ8SazI9gPM hbAtBD4FObNykAsS+X2njbLz9C+qjIzEnLv5al854Fd2gDAMsMj3YbNu/xKDwQeOAyP+tBKH Pq3Lsgm9PPQwVzUu2LQl0+G8TTrdzCk5zrJTQcAQQ81QWIhTS0rJbnDhmxxH4lInJy6IZn1V KAvx3y562lvf3+4ATbzXXv45Nfn8ak4sdfBfaLltMeJlzX+0aVjcVaKv6/VQIO0aSSAWUR4Z 3xStAbToNOAkbqDyOISN3Wqk/dOXgVmibfIBSj8ATeSITCNUwH4ox69Npkmt+z0Tt7gDm6u5 g7hF5x/qAnfC/ojWDz4cPFWAptkVfxqX0+kfQLh3gaSocGbqRNxLZvtH+9Pa1wah4S0rpXWd VGHYXZ/rJbYFmaZ3fWsi1mx8GtRG06GlODTlIZssKY3jBKlDQhpnFojvA3jzMF7tYwWpNE7+ PLPuBhk6xPVNYfaeZ4CP0aScW6B2TRSVbHMX6UI17gCKYbUki94KLf8fEw/qWnaZYIxJw9lN DIV05Zr3c7fwb0BciHzPRwg2fwqE7UZ0Wc9iif3ekMhlTRfsuYDcTYciFcryKJmYRrPvHm
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.92,230,1650931200"; d="scan'208";a="899921546"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Jun 2022 06:52:58 +0000
Received: from mail.cisco.com (xfe-rcd-002.cisco.com [173.37.227.250]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 25T6qwHZ026963 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 29 Jun 2022 06:52:58 GMT
Received: from xfe-rtp-001.cisco.com (64.101.210.231) by xfe-rcd-002.cisco.com (173.37.227.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Wed, 29 Jun 2022 01:52:58 -0500
Received: from NAM11-BN8-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; Wed, 29 Jun 2022 02:52:58 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UqGxBklqKXLLW27e95+EfydOt0u84tPgaebWWDBXNTeiDvdSjAyjYsC9PMdO3qcuI2MFbU0EHSFeP8cnQN5TCoO5CXAdlotUXrPpREGs2IgwC1pjdgkk8/7joTIgYbZS9O5gCTROxL3yskMVLIftVzGud/sunhBYWudcfnomwkCR4RNtECRT6mjnRqWmDHCMjNRQqTmCSFAnmzbJIjAprveZr1wNoLe9OWC71nXN8GqzYDlrMPjDu02pLqRONxuNalI91zwijjksa1h4ekWFwbBIeEOAqP354bM59dYz4wGiNDGQJ1rgMGYECrIdU4+9ybq19ZXctNUANmo3Hms1eQ==
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=C9l2hrO19cDctcXkUngkPaLldndDWcLhKEyy1zRQPuo=; b=Q1lGRwbFkRET6+7+FqJc2MEelz5vIUoLT5kQDzRXltfKka5OiycasVnx/XT0R4ut8P4B9BPqV2DWMWlTcW6jF3r8yH/AWn3y2Lg6pTVFliD0J1W64E4WpI+EBM8VPKKinMo+88vyz+VtOUnAfr+QOuwA7jFAfbqlvtUhWxY2aELVpbh8d4prKodz1VuWQ5tJATef6SwN/nx7CZkJwagfg0MCrXVCCw4jERy8UAVCx5iWI1VA4XupgkYrF/DgBWEGAn5zMb4OptOHX02b4uH5Xa1lQFWUWJHeT1sZ7LtH2FctmYQnB2lwZVnEy8sgzFEjDCmNGYYqhxJ/fjhpNgA4XQ==
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=C9l2hrO19cDctcXkUngkPaLldndDWcLhKEyy1zRQPuo=; b=f8dPHKqeUqfJgn7nktqXGXY2mge1GHBVH3Vxt76QB/DHntB+b7H+pEpwzTpccGCVJxI1B3K6RzwewXTBN79ULRt8v4CxxWGvowNuozumaCmd1nj8FQ08NXClO7cgklbQniNcb8AvfpJljSw1Q37+pilO1vQBrbpEX2xSwHln/lg=
Received: from SJ0PR11MB4896.namprd11.prod.outlook.com (2603:10b6:a03:2dd::20) by BY5PR11MB4436.namprd11.prod.outlook.com (2603:10b6:a03:1c3::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5373.15; Wed, 29 Jun 2022 06:52:55 +0000
Received: from SJ0PR11MB4896.namprd11.prod.outlook.com ([fe80::9e6:6e79:2ab9:1415]) by SJ0PR11MB4896.namprd11.prod.outlook.com ([fe80::9e6:6e79:2ab9:1415%7]) with mapi id 15.20.5373.018; Wed, 29 Jun 2022 06:52:55 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Charles Perkins <charliep@lupinlodge.com>, "draft-ietf-roll-aodv-rpl.all@ietf.org" <draft-ietf-roll-aodv-rpl.all@ietf.org>
CC: "ROLL WG (roll@ietf.org)" <roll@ietf.org>
Thread-Topic: Review of draft-ietf-roll-aodv-rpl-13
Thread-Index: AQHYilaNduspcl5g8Eqcdrv7EjY4bw==
Date: Wed, 29 Jun 2022 06:52:50 +0000
Deferred-Delivery: Wed, 29 Jun 2022 06:52:04 +0000
Message-ID: <SJ0PR11MB48963BFC38F11AFDE015E3DBD8BB9@SJ0PR11MB4896.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-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0b6bb25b-3124-4e3e-7101-08da599bfebe
x-ms-traffictypediagnostic: BY5PR11MB4436:EE_
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: sBkzideFA3+0dPgsZ0NC/Cto62CI3KlGEwf3p5LBNVg26Ue/fQ6PKbwPoR+vPsG9e5yOTK6KUVnJ80B8NWT7iEjcuk+tqfZxJIaXmplx8RDSneAJRoMh574A08FRdx6kIL9Zj9LMn9RW3XP0f359hQk1u3O0TyBLv6rCrYHUwK1gvr4uz/AZtj76Z5quDn839JgqQONOuWWcCwP5CWXHA62eNdmRC+XfyFF3BpBqjnIHt3+Jq5v/QA5PwlhhHPhnslJ3tvdKtnWJ6+Ci2TgoAB1hTREQ8VsxxFlqdievFTtKUCMXdH/H7+WUlRyTUoTpb+ldht67wBKtQ0S+4Em9nF6oh6/ovVBW77h7DtPb4fU7W74XZnBV6zPFf3A35R9BFmNw5Pc9EgmxZltkOsIR4d56+Mu9Erpxo6S8pmDTLi/PdR7lmRxsH6cgWPFxy3d6mqxfwEjfWpX3a1rsh0mWEbhnfbu4wnkAcNReeAyCYdUphyoNZ8AnXioBODJObDlmTclEMMm/CRpZ85dXnWQ3YchzjcpRbE+uQtgZnz3osb8BqMs2BQ5Ezy5C+e+SOFdazI8Wbp1E+ZnmXfpFqbdisTOo9maqe3TOk80CfPY7yP0NnVIEWtR1sSqX/kC1WGbUl7Ym5HXkoDXhrW+xfc1JGUZqVYaNxEAVlu7k9KH896O085P79ezzjhxs+Vl1qolIBBOFJW5zY+nuwLNGKRlYLW3JCpihtGr58eFt875W6lLbiUXN1BYQSvu5yujjjif6zxmrhzE2qAIw+Bz0Lo/cC25YnCIdlBXBFanb2NVmflM1jW8naYVOoASGAP4MOka8RUn1tu6g/UXN2gPG+2WfZg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR11MB4896.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(4636009)(136003)(39860400002)(396003)(346002)(376002)(366004)(30864003)(8676002)(52536014)(38070700005)(66446008)(66556008)(66476007)(478600001)(966005)(55016003)(26005)(76116006)(33656002)(53546011)(66946007)(4326008)(86362001)(64756008)(9686003)(66574015)(84970400001)(110136005)(5660300002)(7696005)(2906002)(316002)(122000001)(8936002)(41300700001)(6666004)(186003)(71200400001)(6506007)(38100700002)(83380400001)(559001)(579004); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?utf-8?B?eVNWZFpzeWsyak9hOWlRNUFUamhTTzBpa3VKWFU0M3NPODJPcnlsd1diQ2Fj?= =?utf-8?B?OENxZ0hocTQycEY0MmYwNFVRZWZGQnNsNnA0QWJnMFdUc2FsUGZnYlVtRFUz?= =?utf-8?B?SUt0TzhkRzZ3dHhxV1I0bzBPMURxbXdBT1U0c1RHQTVlR3pLdW1CemJlRGhR?= =?utf-8?B?Ykt3ckpDUXV1eDEvU1M3MlREekI3ODZrKzhQNVQyZUJhejBrU05pZTBSMVlJ?= =?utf-8?B?UzVUWXlyRnZvTnd2YkpYYUhaQkRXQmlsZjhXaTc3amxmRU4zZGVBTkJId1pQ?= =?utf-8?B?NS83WjNUUzl5V3pPRjRvVGVIdyt4bEMxdmdKbDNKendLVklNc3R3MVhJREJC?= =?utf-8?B?SjBpck1sNWFFbk9GNDZQRUxWUk41VC82a1N5RlJYeDBacHd2VzNSUDJkYTMz?= =?utf-8?B?WldrT0dmRnpwOHZIOUhWUGR5cTJWV1FwVTFKWFNHaWI0OVE0cWJYWGEwZE8y?= =?utf-8?B?VDhGZ3RHanIrZEhVelF6eitBYmVxcmtUbFJleFBXN2RTZzVyUGlTeUFxbDlH?= =?utf-8?B?UkwvSVo1d3c2eEZaaDhzdlV4UHdYK3MrRmIwaXFNTU9vMHNJTnpISUY4Uk1p?= =?utf-8?B?cjZLS1FNZC9zekRMdDUyTnc4Z3RSWnBHbCt5KytaWTdKT1pORWJOSDl0S2RU?= =?utf-8?B?NTVEQWswKzFxTHkyY2FNWGg4bndlZ2JOMzRzbllJN2N1dTZhRkZLaGE3NGFM?= =?utf-8?B?Sk5qMXNiQjdrSjl4UkxPUWt2RXZBQWx3VXNyY1JxaDJmWElGK2JNaWxmZGJ0?= =?utf-8?B?M09NZ1pxQkVaRXhOMDVBNUUvQlRqT2xmUWFsTWNhL0JFODZyeEJxOW9vUENZ?= =?utf-8?B?VkFleUdEejJ1eUVtblhLRHJrekpaWVRtZVpqS3FvazVWT1A5cWd0U1EyK2lK?= =?utf-8?B?Nks0aElRTUs1ZndEdnU2S0ZSQk9kRy8rbVBoQXpseU9VSGQydmlsS21vTUhO?= =?utf-8?B?d0Z1UTBPVm5TLzg5TVVRdzhiNnYvT3VrQ25OK2I1SzVqcVR1WEVvbjRuZ3Iv?= =?utf-8?B?WnZCV1FiYURyNnBTMWQrLyt0VlNnS0xBMjJ4QTBmMFk2RjZYbU05ZmhNK2tU?= =?utf-8?B?S3Q5cFl2elR0QVN4Z0xBZ05Zc2JMK2RLQVErandCT1h2OFVWcitaajl6dDZV?= =?utf-8?B?NkNjaFN4aFhCcDVKZzcySTJnc1I5MlZLZHNhOWRQNjUxY0VRdElZRnp0VHAz?= =?utf-8?B?MFRnS1dqY2lnUEJQVVBMSm0rdk1uMksvdmlId0RaU1ExNlQxcXNiU1hRZlFJ?= =?utf-8?B?K1ZWOG9wNU5rY1BFN3lXYUg1Zk5iYnZUc3lUdmZjakpnT2I4NStpN0ZadVZG?= =?utf-8?B?Tm9KYWZhZm5IYlpydGNKU3hpSG50RHRQckdhTEVCQ1FkdENJRUh4R3dZRDdW?= =?utf-8?B?QkhZcE5BL3dhaDZrYjl3N09sZkd6b0t0QjQ0eTBBV2hld2wvQmFxRjlYaTBK?= =?utf-8?B?YkRORHhzZmg2MStzL2gvckg2eHpwWHorZGQxelVhdWtWVWFXQjNjWGVpL053?= =?utf-8?B?YmR5c2NuMDRudGlHVTBxMmZ1eTBWWFBSWGltM3kzNE15eGdjem02WWJGbHdM?= =?utf-8?B?TTZuSCtOR1dSTE5FT3Y4UTNvWlcyaVZ6QWNLV3pXcXhnTWwwbWMzMVVORHlP?= =?utf-8?B?MmlQSldaYmcwZVA2QlVKOEFiSG1TRXl5bjl6UEVTUi9lVm1YUWVzTWtJU1pJ?= =?utf-8?B?ZFRzMkI4eng1V1VjTHk4M1dmNVFyMEg2c3ljd0VBUURPWTQvM3RtOVVraHRS?= =?utf-8?B?OHJoeE1kK2ZPaEdjN2c1VkhuMFd5TVEvdXFscmt2T0dPU3hKTXBRcm5rZnRk?= =?utf-8?B?Y3duR3BVblZHUTVxM0lmbTNZeEs4UWRaczNKMXI0NFdWSEw0dGpSU1d2WFJz?= =?utf-8?B?eUF5NEg2d2Qzenc1cjBrNEFWcmt2MFVQazNOalROSmM5VDNrcTA2YXFMR2hu?= =?utf-8?B?d3RXK09uSVVBRFNnZ0RmSVB0NlpyQ0RzSmVUVVdkT1BFQjRaSjRQa2hrQVNU?= =?utf-8?B?T2kvclVlVldPOG9hOGJsZGl4c2U3RFFtOHlLaHNpSHFCbG5wVjFiblpZdUo3?= =?utf-8?B?aVBjU2dnbUpRbG9VbXJncnkxbXErbndOMGpaSG41L2hnTStjTjJvdDI1ME80?= =?utf-8?Q?2R6G3vM223Tur9IpXi62FEVbh?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <A2EA29FC0AFE41458B0FBA94B427D0CF@cisco.onmicrosoft.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR11MB4896.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0b6bb25b-3124-4e3e-7101-08da599bfebe
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2022 06:52:55.4574 (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: 7C8GUGbwH7ZDle/0uha5demT2umuz6yTHdgejk6lD/0c2xCw3gmC6mTLlIL4MOfP/FAiuNwYqng/WoqKDVjPEA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4436
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.227.250, xfe-rcd-002.cisco.com
X-Outbound-Node: alln-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/wBj24Vq97dTRyr6A6Lal9Sj3zcQ>
Subject: Re: [Roll] Review of draft-ietf-roll-aodv-rpl-13
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 29 Jun 2022 06:53:05 -0000

Hello Charlie

I hope you're doing well, it's been a while.

In the below I skipped the things for which you agreed directly and used WFM to accept your proposals:

> Thanks for your many helpful observations and suggestions.

:) 


>> ------------------------------------------------------------------------
>>                 The on-demand nature of AODV  >     route discovery is
> natural for the needs of peer-to-peer routing in  >     RPL-based LLNs.
>> => because ? "natural" lacks substanciation. One could argue the exact
> same for projected DAO, and all the DetNet / RAW work would support it. I'd
> remove that sentence. Instead, it would be nice to qualify the properties of
> on demand that fits which needs so we can derive applicability.
>>      I'd say that all RPL variations have in common that they avoid
> building optimized routes between every all pairs of nodes, to save
> constrained resources and control protocol exchanges. On-demand enables an
> optimization for specific pairs where a larger main RPL DODAG will allow
> stretched but any-to-any connectivity.
> 
> 
> 
> On demand is better when routes are needed but aren't yet established.
> Peer-to-peer routing is better when shorter routes are desired and especially
> when it is desired to avoid heavier traffic through a root or gateway node of
> the network. This seems natural to me.  However, some peer-to-peer routing
> should be done proactively, and so the sentence needs work.  Thanks for
> pointing this out.

I'm sure you saw that I did not mention it for the sake of a chat but with the hope that you'd place such text as this exchange in the document 😊
This would certainly help a rpl-junior reader.


> 
>> ------------------------------------------------------------------------
>>      " AODV-RPL can be operated whether or not P2P-RPL or native RPL is
> running otherwise."
> 
> In order to remove the possible ambiguity when other protocols are using the
> same MOP, and as you suggest below, I agree that AODV-RPL should use a new
> multicast group.

And that we MUST a specific instance ID so it operates as ship in the night.

> 
> 
>> ------------------------------------------------------------------------
>>      " For many networks AODV-RPL could be a
>>      replacement for RPL, since it can find better routes at very moderate
>>      extra cost.  Consequently, it is unlikely that RPL would be needed in
>>      a network that is running AODV-RPL, even though it would be possible
>>      to run both protocols at the same time."
>> => "better" is unsubstanciated.
> 
> Better because shorter paths, etc.

Yes. It's hard to qualify shortest or best in radios. Depends on what you care for, and things keep changing anyway.
When the "shortest" paths are busy and dropping packets (including RR), it might be that a reactive protocol finds a "longer path".
This is the sort of things that the reader should understand to position the usability of the protocol. It is distributed, autonomic, but provides no optimality guarantees. The best option for a demanding application is probably to max out the Rank Diameter that the RR probe can reach, to avoid using a path that is not usable by the application. 

In contrast, a real optimization requires a global view of all flows. This is what a PCE does in TE space, and this is why we have DAO projection in RPL.

> 
>> I suggest to remove that text altogether. I believe that it suffices
> to say what I pointed above, that RPL and AODV RPL must be operated in
> different instances, which is unavoidablme since they are running with
> different MOPs, so they just cannot interfere. Which one is used is a
> policy decision, out of scope.
> 
> Do you think there are times when RPL discovers better routes than AODV-RPL?

When DAO projection is implemented. Applications like industrial automation require full control and visibility, e.g., which path is used by which flow. They'll want to dispatch the flows to optimize globally the latency and reliability. They'll do DetNet PREOF / RAW PAREO things. The cost is significant - a controller -, but for them the routes that can guarantee no link or node congruence, time and space diversity, max latency, global load balancing, etc... are indeed "better". 

> 
> 
>> -------------------------------------------------------------------------
>> "
>>      DIO
>>         DODAG Information Object
>> "
>> => Remove, this is already defined in RFC 6550
> 
> How about adding "(as defined in RFC6550)"?  There ought to be
> something to help the reader.

WFM

> 
>> -----------------------------------------------------------------------
>> "
>>      Source routing
>>         A mechanism by which the source supplies the complete route
>>         towards the target node along with each data packet [RFC6550]
>> "
>> => if it is "complete" then this is *strict* source routing.
> 
> Maybe complete isn't best.  We can just say "supplies a vector of
> addresses".

WFM

>>    Also, 256 s might be very short for energy scavenging devices.
>>    Could that be based on the " Lifetime Unit " in
> https://www.rfc-editor.org/rfc/rfc6550.html#section-6.7.6  so
> deployments could use very different ranges?
> 
> That's a lot more bits.  It seems like a pretty big change at this point
> of time during Last Call.  We could instead define a new Option to
> override the L field value in the Option header.  Would that suffice?
> Maybe it should be done later after the base document is published.

WFM


> 
>> ------------------------------------------------------------------------
>>     "In Figure 4 and Figure 5, BR is the Border Router, O is
>>      the OrigNode, "
>> => This seems to indicate that there's a need for a main RPL
> instance. But the text clearly said it is not the case.
>> So maybe indicate that this is an example where you have connectivity
> to the outside (which is not needed) and a main RPL Instance rooted at
> the BR (which is not needed either).
> 
> We could change it so that BR has a different name, or we could make it
> clear that the use of BR is for illustrative purposes only and not
> necessary to run AODV-RPL.

WFM


> 
>> ------------------------------------------------------------------------
>> " criteria used
>>      when determining whether or not each link is symmetric. "
>> => maybe mention DLEP ? No pressure
> 
> The criteria used do not have to conform to any standardized protocol.

WFM

> 
> 
>> ------------------------------------------------------------------------
>> "
>> Figure 5:
>> "
>> => The propagation of both DIOs appears to be along a sequence of
> nodes though it is really flooded in a Rank Diameter around O. I believe
> it is worth explaining. Also, what happens when the S flag arrives at T
> with both flavors?
> 
> The evaluation of the rank seems preferable for picking among several
> possible routes, not the setting of the S bit.

Good to clarify that I the text.



>> ------------------------------------------------------------------------
>> Section 6.2.1 is pseudo code with no indentation.
> 
> This is the first time I can remember having such a paragraph described
> as pseudo code.

OK I was unclear. I mean that the text has a lot of logical steps, but is unclear what and otherwise is for there are multiple steps and conditions before.
In the end it looks like a python code that would not have been indented and it could be misunderstood. I'm asking to ensure that it can be read and coded without ambiguity. The form is yours to choose.


>>    This results in ambiguity. For instance,
>> "
>> The upstream neighbor router
>>      that transmitted the received RREQ-DIO is selected as the preferred
>>      parent.
>> "
>> This is true only in the case where the received DIO is the best.
> 
> A previous sentence specifies "... the following steps are not processed."
> 
> Perhaps a new paragraph after that statement would clarify so that the
> intended meaning is more evident.

This is an example of what I'm asking above, yes.

> 
> 
>> ------------------------------------------------------------------------
>> Section 6.2.2 :
>> "
>> After determining that a received RREQ provides a usable route
>> "
>> Does that determination impact the operation of this section? What if
> S=0?
> 
> If S=0, the determination of Target Node status and determination of a
> usable route to OrigNode is still the same.

Better safe than sorry. Please add the words.

> 
> 
>> ------------------------------------------------------------------------
>> Section 6.2.3 :
>> "
>> then the router MUST build or update its upward route
>>      entry towards OrigNode,
>> "
>> Even if S=0 ? Even if not the newest sequence? Even if RREQ not from
> preferred parent to orig?
>> Suggest to list all the checks first and then if OK the action. Here
> the last sentence is only one of the checks and appears too late to
> follow the logic.
> 
> That would seem to duplicate specification text in previous sections.
> Usually
> such duplication is a bad idea, because duplication of text leads to errors
> when one of the duplicated texts is edited but the other is not.

the position of the reader, I need to find the full story at one and not scattered. I agree that the normative text must not be duplicated. You're better at this game than I am.


> Even for S=0, the RREQ advertises a route to OrigNode.  If the RREQ is
> not from a preferred parent, it should not be propagated.  If the RREQ
> is not the newest sequence it should not be propagated.  These are all
> specified earlier.
> 
> There are too many things in the preceding sections of the document to
> repeat
> them here.

Maybe think of it as a function. Detail the common steps above in a section and then refer to it everywhere you need. As is, I, as a reader, was confused.

> 
> 
>> ------------------------------------------------------------------------
>> Section 6.2.5 :
>> What if the interface up is not the interface down, and the addresses are
>> different? The result is that the address list is not reversible. In
>> particular, in the case where S = 1?
> 
> In this case, the route is not symmetric and S = 0.
> 
> Each radio interface/link and the associated address should be treated s an
> independent intermediate router.  The two routers have different links and
> the rules for the link symmetry apply independently for each of these.

Please add clarifying text in the spec.

> 
>> ------------------------------------------------------------------------
>> Section 6.2.5 :
>> "
>>      If the router is a TargNode and was already associated with the RREQ-
>>      Instance, it takes no further action and does not send an RREP-DIO
>> "
>> In 6.3.1 it says
>> "
>>      For a symmetric route, the RREP-DIO message is unicast to the next
>>      hop according to the Address Vector (H=0) or the route entry (H=1);
>> "
>> This means that if an RREP-DIO was sent on a bad path received fast,
> it will not be updated when a better path shows?
> 
> The RREP advertises a route to TargNode.  If the TargNode already sent
> an RREP, and then receives a better RREQ, it does not have to re-send
> the RREP.

Which means that a "bad path" will be used if the RREQ was received first? 
Note that latency might not be the criteria to optimize for. 
E.g., a more reliable path may be slower / more hops.


> 
>> ------------------------------------------------------------------------
>> Section 6.3.3 :
>> This all idea of delta is complicated. Why not just place in that
> field the RPL instance ID of the RREQ instance? It's also 6 bits since
> it is a local RPL Instance ID.
> 
> Delta is needed to associate the RREQ_InstanceID to the RREP_InstanceID.  It
> is possible that TargNode might have used OrigNode's choice of
> RPLInstanceID for
> some other unrelated route discovery.  It is even possible that OrigNode's
> choice of RPLInstanceID was previously used by TargNode for a route
> discovery
> for OrigNode with a different OF.  Using Delta to effect the association is
> a good technique which is very simple to manage.

I did not challenge the idea, just the use of a new field

> 
>> ------------------------------------------------------------------------
>> Section 6.4.1 :
>> "
>> The router that
>>      transmitted the received RREP-DIO is selected as the preferred
>>      parent.  Afterwards, other RREP-DIO messages can be received.
>> "
>> What if more than one RREP-DIO are received?
> 
> This just means that the receiving node is getting multiple
> advertisements for
> routes to TargNode.   In such a case the router might already be in the
> DODAG.
> AODV-RPL does not specify any action to be taken in such cases.
> 

But then, what is the developer to do? Select the best one? Ignore ? keep some, or them all, for NECMP? do what he likes?


> 
>> ------------------------------------------------------------------------
>> Section 6.4.4 :
>> "
>> If H=0, the
>>      intermediate router MUST include the address of the interface
>>      receiving the RREP-DIO into the address vector.
>> "
>> Same as the other direction. The address on the receive interface of
> the RREQ-DIO may not be visible on the interface from which traffic to
> target is received. It would make sense to place the address of the
> previous hop from which the RREP-DIO is received.
> 
> If a node transmits a RREQ over an interface which is different than the
> interface from which it was received, both interface addresses should be in
> the address vector.
> 

I did not read that in the spec. Did I miss it?
Optimization question: Is that useful, e.g., in non-symmetrical paths?
In traditional RPL, the (source) route only indicates to the previous hop the address of the next hop that it can see. 

> 
>> ------------------------------------------------------------------------
>> Section 7
>> "
>> an Intermediate router that receives a RREQ-DIO
>>      message MAY transmit a "Gratuitous" RREP-DIO message
>> "
>> How does it select the RPL Instance ID? I believe only the target can
> do that so only the target should send the RREP-DIO
> 
> Regardless of TargNode's choice of RREP_InstanceID and Delta, an
> intermediate
> node can unambiguously identify the DODAG by using RREQ_InstanceID in the
> returned Gratuitous unicast RREP to OrigNode.  Then, when the intermediate
> node later receives TargNode's unicast RREP, the intermediate node will be
> able to make the association between RREQ_InstanceID and RREP_InstanceID.
> 

This is assuming that there is a RREP Instance ID, meaning that the RREQ reaches the Target.

I guess that my confusion is that I thought that the Intermediate routers absorbs the RREQ, so we do not look for the rest of the path.
Apparently, the Intermediate router that does the gratuitous thingy still must pass the RREQ on. If it does, then the gratuitous thing is useless till the RREP from Target comes in. But then if so, what's the use of the gratuitous? 

Charlie, I'm sorry if I missed something that is already explained; but if not, please clarify.

Keep safe;

Pascal


> Naturally Yours,
> Charlie P.
> 
> 
> 
> 
> Naturally Yours,
> Charlie P.
> 
> ============================ Original email follows ======================
> 
> 
> On 3/17/2022 7:56 AM, Pascal Thubert (pthubert) wrote:
>> Dear authors and all;
>> Please find my comments on draft-ietf-roll-aodv-rpl-13 below:
>> Bottom line is that we're not there yet. I believe a number of mechanism
> are either underspecified or broken as described, e.g., the way a source
> route is constructed does not seem to work for nodes with different
> interfaces up and down.
>> ---------------------------------------------------------------------------
> ---------------------
>>                                           " Consequently, for traffic
>>    between routers within the DODAG (i.e., Peer-to-Peer (P2P) traffic)
>>    data packets either have to traverse the root in non-storing mode, or
>>    traverse a common ancestor in storing mode."
>> => Suggest to add references to RFC 6687 for the route stretch and to RFC
> 9010 for the detailed impacts.
>> ---------------------------------------------------------------------------
> ---------------------
>>               The on-demand nature of AODV
>>    route discovery is natural for the needs of peer-to-peer routing in
>>    RPL-based LLNs.
>> => because ? "natural" lacks substanciation. One could argue the exact same
> for projected DAO, and all the DetNet / RAW work would support it. I'd remove
> that sentence. Instead, it would be nice to qualify the properties of on
> demand that fits which needs so we can derive applicability.
>>    I'd say that all RPL variations have in common that they avoid building
> optimized routes between every all pairs of nodes, to save constrained
> resources and control protocol exchanges. On-demand enables an optimization
> for specific pairs where a larger main RPL DODAG will allow stretched but
> any-to-any connectivity.
>> ---------------------------------------------------------------------------
> ---------------------
>>    " AODV-RPL can be operated whether or not P2P-RPL or native RPL is
> running otherwise."
>>    I do not believe that is generally true, please remove the text. MOP 4
> in DIOs could create a confusion between the reactive methods and  a P2P RPL
> implementation will not recognize the RREQ option and may process the DIO or
> enter an error state. But it does not matter. I'd indicate that if ever RPL,
> P2P RPL, and/or AODV RPL run between the same nodes (so unlikely!) then they
> operate as different RPL instances anyway (since " the OrigNode builds a
> local RPLInstance and a DODAG rooted at itself."). Instances do not mix, by
> definition.
>> ---------------------------------------------------------------------------
> ---------------------
>>    " For many networks AODV-RPL could be a
>>    replacement for RPL, since it can find better routes at very moderate
>>    extra cost.  Consequently, it is unlikely that RPL would be needed in
>>    a network that is running AODV-RPL, even though it would be possible
>>    to run both protocols at the same time."
>> => "better" is unsubstanciated.
>> I suggest to remove that text altogether. I believe that it suffices to say
> what I pointed above, that RPL and AODV RPL must be operated in different
> instances, which is unavoidablme since they are running with different MOPs,
> so they just cannot interfere. Which one is used is a policy decision, out of
> scope.
>> ---------------------------------------------------------------------------
> ---------------------
>> "
>>    DIO
>>       DODAG Information Object
>> "
>> => Remove, this is already defined in RFC 6550
>> ---------------------------------------------------------------------------
> ---------------------
>> "
>>    Source routing
>>       A mechanism by which the source supplies the complete route
>>       towards the target node along with each data packet [RFC6550]
>> "
>> => if it is "complete" then this is *strict* source routing.
>> ---------------------------------------------------------------------------
> ---------------------
>> "
>> OrigNode selects one of its IPv6 addresses and sets it in the DODAGID
>>    field of the RREQ-DIO message.
>> "
>> =>The address scope must encompass the domain where the route is built.
> E.G, not link-local.
>> ---------------------------------------------------------------------------
> ---------------------
>> "
>>   H
>>       Set to one for a hop-by-hop route
>> "
>> => In the RPL culture we call that Storing Mode (I did not choose that
> term!!!). Source route is Non-Storing Mode.
>>   Ideally we'd align terminology. Alse, it should at least be indicated in
> the terminology and the introduction.
>> ---------------------------------------------------------------------------
> ---------------------
>> "   L
>>       2-bit unsigned integer determining the length of time that a node
>>       is able to belong to the RREQ-Instance
>> "
>>  length of time => duration?
>>  Also, 256 s might be very short for energy scavenging devices.
>>  Could that be based on the " Lifetime Unit " in https://www.rfc-
> editor.org/rfc/rfc6550.html#section-6.7.6  so deployments could use very
> different ranges?
>> 
>> ---------------------------------------------------------------------------
> ---------------------
>> 
>>   "In Figure 4 and Figure 5, BR is the Border Router, O is
>>    the OrigNode, "
>> 
>> => This seems to indicate that there's a need for a main RPL instance. But
> the text clearly said it is not the case.
>> So maybe indicate that this is an example where you have connectivity to
> the outside (which is not needed) and a main RPL Instance rooted at the BR
> (which is not needed either).
>> 
>> 
>> 
>> 
>> ---------------------------------------------------------------------------
> ---------------------
>> 
>> " criteria used
>>    when determining whether or not each link is symmetric. "
>> 
>> => maybe mention DLEP ? No pressure
>> 
>> ---------------------------------------------------------------------------
> ---------------------
>> 
>> "
>> Figure 5:
>> "
>> => The propagation of both DIOs appears to be along a sequence of nodes
> though it is really flooded in a Rank Diameter around O. I believe it is
> worth explaining. Also, what happens when the S flag arrives at T with both
> flavors?
>> 
>> 
>> ---------------------------------------------------------------------------
> ---------------------
>> 
>> "to multicast group all-RPL-nodes".
>> 
>> => could we have a all-AODV-RPL-nodes group? The all-RPL-nodes is for
> normal DIOs.
>> 
>> 
>> 
>> ---------------------------------------------------------------------------
> ---------------------
>> 
>> "The address in the ART Option can be a unicast IPv6 address or a"
>> 
>> =>  The Target Prefix / Address in the ART option ...
>> 
>> ---------------------------------------------------------------------------
> ---------------------
>> 
>> Section 6.2.1 is pseudo code with no indentation. This results in
> ambiguity. For instance,
>> 
>> 
>> "
>> The upstream neighbor router
>>    that transmitted the received RREQ-DIO is selected as the preferred
>>    parent.
>> "
>> 
>> This is true only in the case where the received DIO is the best.
>> 
>> ---------------------------------------------------------------------------
> ---------------------
>> 
>> Section 6.2.2 :
>> "
>> After determining that a received RREQ provides a usable route
>> "
>> 
>> Does that determination impact the operation of this section? What if S=0?
>> 
>> 
>> ---------------------------------------------------------------------------
> ---------------------
>> 
>> Section 6.2.3 :
>> 
>> "
>> then the router MUST build or update its upward route
>>    entry towards OrigNode,
>> "
>> 
>> Even if S=0 ? Even if not the newest sequence? Even if RREQ not from
> preferred parent to orig?
>> Suggest to list all the checks first and then if OK the action. Here the
> last sentence is only one of the checks and appears too late to follow the
> logic.
>> 
>> ---------------------------------------------------------------------------
> ---------------------
>> 
>> Section 6.2.5 :
>> 
>> What is the interface up is not the interface down, and the addresses are
> different?
>> The result is that the address list is not reversible. In particular, in
> the case where S = 1?
>> 
>> ---------------------------------------------------------------------------
> ---------------------
>> 
>> Section 6.2.5 :
>> 
>> "
>>    If the router is a TargNode and was already associated with the RREQ-
>>    Instance, it takes no further action and does not send an RREP-DIO
>> "
>> In 6.3.1 it says
>> "
>>    For a symmetric route, the RREP-DIO message is unicast to the next
>>    hop according to the Address Vector (H=0) or the route entry (H=1);
>> "
>> 
>> This means that if an RREP-DIO was sent on a bad path received fast, it
> will not be updated when a better path shows?
>> 
>> ---------------------------------------------------------------------------
> ---------------------
>> 
>> Section 6.3.3 :
>> 
>> This all idea of delta is complicated. Why not just place in that field the
> RPL instance ID of the RREQ instance? It's also 6 bits since it is a local
> RPL Instance ID.
>> 
>> 
>> ---------------------------------------------------------------------------
> ---------------------
>> 
>> Section 6.4.1 :
>> "
>> The router that
>>    transmitted the received RREP-DIO is selected as the preferred
>>    parent.  Afterwards, other RREP-DIO messages can be received.
>> "
>> 
>> What if more than one RREP-DIO are received?
>> 
>> ---------------------------------------------------------------------------
> ---------------------
>> Section 6.4.4 :
>> "
>> If H=0, the
>>    intermediate router MUST include the address of the interface
>>    receiving the RREP-DIO into the address vector.
>> "
>> 
>> Same as the other direction. The address on the receive interface of the
> RREQ-DIO may not be visible on the interface from which traffic to target is
> received. It would make sense to place the address of the previous hop from
> which the RREP-DIO is received.
>> 
>> ---------------------------------------------------------------------------
> ---------------------
>> Section 7
>> 
>> "
>> an Intermediate router that receives a RREQ-DIO
>>    message MAY transmit a "Gratuitous" RREP-DIO message
>> "
>> 
>> How does it select the RPL Instance ID? I believe only the target can do
> that so only the target should send the RREP-DIO
>> 
>> 
>> ---------------------------------------------------------------------------
> ---------------------
>> Keep safe,
>> 
>> Pascal
>>