From nobody Wed Jan 12 01:51:05 2022 Return-Path: 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 D64CF3A1420 for ; Wed, 12 Jan 2022 01:51:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.585 X-Spam-Level: X-Spam-Status: No, score=-9.585 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_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=VBe/k+NG; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=D7QVE3Bx 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 jN_MzYja0tei for ; Wed, 12 Jan 2022 01:50:58 -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 F2D913A141E for ; Wed, 12 Jan 2022 01:50:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22085; q=dns/txt; s=iport; t=1641981057; x=1643190657; h=from:to:subject:date:message-id:mime-version; bh=YIrKn7av78DMNnol5d72MA9NGJO3lAYMriyzCMcAEAs=; b=VBe/k+NGg8S7+eIjBFgXlgIoX05c5xAlxMWaRv7BsApbCxC2KXOjjPrc /V6Aa/mRHRLeK/Iusik92+HeMNlWLK0fRXxEvNoAMNfQRR6RezC95uH5q yMEFXXfMuEwVvZJ8DSM8WqEsH2zhRmjZVta4VNuLblTWtpd08cFrk5y04 k=; X-IPAS-Result: =?us-ascii?q?A0DKBgCIo95h/4ENJK1aHgErCwYMIoFZgSExVQd3Wjcxi?= =?us-ascii?q?AwCA4U5hQ5dgiWBFo8himqBLoElA1QLAQEBDQEBNwoEAQGFBgKDSAIlNAkOA?= =?us-ascii?q?QIEAQEBAQMCAwEBAQEFAQEFAQEBAgEGBIEJE4U7AQQoDYZVBhUZAQE4EQFAQ?= =?us-ascii?q?CcEGxqCXYIOVwMuAQ6gdwGBOgKKH3iBATKBAYIIAQEGBASFCxiCNgMGgTqDD?= =?us-ascii?q?oJ+VEqHL4IpgRQBQ1WBEUqDWAICgWArgyKCLo94JUYOYA1EAk0uHjcYAQISB?= =?us-ascii?q?w8fC4EQAZ4voEYGBINDn2sVp2uWPaElFwsLhF4CBAIEBQIOAQEGgWE7gVlwg?= =?us-ascii?q?W6BS1EZD4Vrgl+JR4UUhUp0AjYCBgsBAQMJjHwHgj8BAQ?= IronPort-PHdr: A9a23:Ite1+R8ZMtUOZv9uWCXoyV9kXcBvk7n3PwtA7J0hhvoOd6m45J3tM QTZ4ukll17GW4jXqpcmw+rbuqztQyoMtJCGtn1RfJlFTRRQj8IQkkQpC9KEDkuuKvnsYmQ6E c1OWUUj8Wu8NB1eGd31YBvZpXjhhQM= IronPort-Data: A9a23:AHrWMqNTT972aLHvrR1QlcFynXyQoLVcMsEvi/4bfWQNrUoihTUPm 2MXWm7QOv/ZMWLweNt0bomxo08Eu57TmtJgTXM5pCpnJ55oRWUpJjg4wmPYZX76whjrFRo/h ykmh1qpwPkcFhcwnD/1WlTahSQ6hfHgqobUUraeYHgoHFU8EU/NtDo68wIHqt8w6TSGK1vlV ePa+6Uz73f8hlaYmkpNg06ygEsHUMba4Vv0jXRiDRx/h2IyolFOZH4pyQ5dGFOjKmVcNrbSq +8uV9hV9EuBl/smIovNfroW7iTmT5aKVTVihEa6VID7nAFFhxMYj58pH+c+cFxlggSMo95+n YAlWZyYEW/FP4XFnOAbFhJfCSw7bOtN+aTMJj60tsn7I0/uKiS3ha4wShhte9RCq46bAkkWn RAcADQMfEurjOOty7X9Qe5p7igmBJm3Yd5B4yw9l1k1C94sbqnyfKebuuZn9xkXhexxMtr3e e4gPG8HgBPoJkcn1k0sIIg5mOOAh3TjfXtfsl39mEYsy2HXyAo027/3PZ+EPNeLXs5S2E2fo woq4ljEP/3TD/THoRLtz55mrrancf/TMG7KKICFyw== IronPort-HdrOrdr: A9a23:FRfbhqNZPhNtg8BcT3j155DYdb4zR+YMi2TDiHoRdfUFSKKlfp 6V88jzjSWE8gr5K0tQ5OxoWZPwDE80kKQU3WB/B8bbYOCLghrMEGgA1/qv/9SDIVyEygc178 4JGMISZKySfDpHZK3BkW6F+qMbsaC6GdeT9IHjJhlWPGVXQpAlyz08JheQE0VwSgUDL4E+Do Cg6s1OoCflUWgLb+ygb0N1ENTrlpnurtbLcBQGDxko5E2lljWz8oP3FBCew1M3Ty5P+7E/6m LI+jaJqJlL8svLiyM05VWjrKi+q+GRiOerw/b8z/T9Hw+cyjpAor4RH4Fq8gpF591Ho2xa7O Uk6y1QQPibrUmhOF1cZXDWqlHdOPFE0Q669bbQuwqcneXpAD09EMZPnoRfb1/Q7Fchpsh11O ZR03uerIc/N2KJoM3R3am/a/hRrDv8nZPiq59gs1VPFY8FLLNBp40W+01YVJ8GASLh8YgiVO 1jFtvV6vpaeU6TKymxhBgk/PW8GnAoWhuWSEkLvcKYlzBQgXBi1kMdgMgShG0J+p4xQ4RNo+ 7ELqNrnrdTSdJ+V9M3OM4RBc+sTmDdSxPFN2yfZVzhCaEcInrI74X65b0kjdvaD6DgDKFC7K gpfGkoxVLaSniefPFmhqc7gywlaF/NLgjQ9g== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.88,282,1635206400"; d="scan'208,217";a="845561552" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Jan 2022 09:50:56 +0000 Received: from mail.cisco.com (xbe-rcd-002.cisco.com [173.37.102.17]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 20C9oubR005010 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for ; Wed, 12 Jan 2022 09:50:56 GMT Received: from xfe-aln-003.cisco.com (173.37.135.123) by xbe-rcd-002.cisco.com (173.37.102.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Wed, 12 Jan 2022 03:50:33 -0600 Received: from xfe-aln-004.cisco.com (173.37.135.124) 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.986.14; Wed, 12 Jan 2022 03:50:32 -0600 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-004.cisco.com (173.37.135.124) 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, 12 Jan 2022 03:50:32 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UFdPdiHpPkud31ZEGB37JxOdFg9NDElJG42kxLS/xztm1jQF2AqyeBa82+zXqtz6jBO+JqbyyFV6hxk7PHT7EOLiJ02rm/6aOu6ca838seE1lzXEYTCIvk8Yp18jRBPhmxQfPswPGAqrxDSgzbFtJ0eizwlO2ipaM8R7khOPLFfyuzf4m80zrboV9MyMqanmkGlkp82Zub3o1c5kLzIgeg5H11vSi9bkPcVKCBrrc2hzaAouU3PGGWaoEykrY/kASx/5aeZTdNvDpvFfqQC25MWTNIsTs0t+E4aNRW1P8Pp7bOq5Le4nFFhmsO6yx5XTtWYkkemwgR37+fu9ql3AHA== 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=oJVUayKNFA1HSdEMsyG2eT7VYL/bgEwE1HzEBC+UwGY=; b=WAtEILXtJ4k2e7WxxPMMWynpXk7G/NR8pfQdxCalnVNetjAAJhGhZrTw+YFCjGFJ0EPXTtTieFldoHaWDxZn2GE2o2c3EumzqFUHDur+XGx5Fp6LdaTB1RWMX8LzhPk7booK+BiNvZkVj1DE4n9y3G3SFkuNE0TLPx5pW1BvqS8RTngCs2ucqysG9H+hQ8EX6n/lPhJ3XKgwxnw542p4gvpZcCk2azbGn7bHln/pbHNRDi3Wo0C5DFGI9A/oyuLtgeKkbi0U6LJMRaAR3S17CRJv0gVkgPSW8fhh6ak/Fr9ritrGUYJXGPGCx/WkIi/4nwMaRvAn7roG74/gIELhDA== 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=oJVUayKNFA1HSdEMsyG2eT7VYL/bgEwE1HzEBC+UwGY=; b=D7QVE3BxPyLgXuaS2kLgnIFdt2Bw4IpiP7SMzQGvktqFQ/Nw1I1+smPb/7iu9Kp6Vm7e2ArCVZvKoPvpS5l6yWHjTc6HYxdGd4zKisK35/fJHN7FVopJ+qlkw9ggna+Ro+NZU12pXXYNRor9N4BydeL0ecaMcys+zEukUHuTTXg= Received: from PH0PR11MB4919.namprd11.prod.outlook.com (2603:10b6:510:34::12) by SN6PR11MB3261.namprd11.prod.outlook.com (2603:10b6:805:c1::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4867.9; Wed, 12 Jan 2022 09:50:31 +0000 Received: from PH0PR11MB4919.namprd11.prod.outlook.com ([fe80::610b:fc73:3a3a:49e7]) by PH0PR11MB4919.namprd11.prod.outlook.com ([fe80::610b:fc73:3a3a:49e7%6]) with mapi id 15.20.4888.009; Wed, 12 Jan 2022 09:50:31 +0000 From: "Li Zhao (liz3)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] review of dao-projection -22 Thread-Index: AQHYB3I0RLVoN8WqFEOEiCVUH4Liaw== Date: Wed, 12 Jan 2022 09:50:30 +0000 Message-ID: Accept-Language: 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: d2d58521-992e-482b-a096-08d9d5b0f88a x-ms-traffictypediagnostic: SN6PR11MB3261:EE_ x-microsoft-antispam-prvs: 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: IYTFlQa8YX0/F7fnY+FnmbuHgR8q7GeqiVG5Dud8G0Nrkf25q5cg8XBVcLn4UIqj/DpaPyhf0vlsH3FwK1wWHCFlsORSn3rMoC+BQEdZbx0QGBRG7nk/LATaAIq3gfsHx//QL+3JZBegUZ4kI/2DiR5zpbLlfrGFYIk8EQGfwBrSdAyfOEAisYkNfWZRZy1WUqSsrpctKSI2iJ5AWH64QO18dqDShytIbqxyFFCZ7ygw8Cq+FuyjydFZIA1TQ0I5F8Zuk+FxYqPvozS5kbsn6WbdZjDLMbP8hWvlQ+KJYx1+vUWaR1VU4Kd4QKT7+Z5sxxzWRZgj4h0W5bYSAGDi+AqXu84kdXiLQF9DutCC6C1JMFdIfK0g53ej3FX9pvMZHept4fWID20Z3pQJcdm8zeGn5Tzr5QnlznFizM1n6BzE6F4H2GYFaDLaSpcYFoTQlZZMlR5V+zJQjhgYK2DTG82CyB8IealXjyzFIdPy6e/1HShkDzh9RebgyLvgM/FKdZFHQ/Prcn5k8l9PwP98nTxbfMc6HTNvu2+ji9yaqlsMTDIt4mCxD9NTv0STAVIoCYoYlIvrAnzjQzMJfTr+iPUEXNuKsYXTWtYLSqNt4+/c7PAeI3zTKdpb+BQnSbsZN7gpm5aEJi+RAtaOQPs3o5H6MpdOgidONPeV0smt/iYVklbAtUI/vlzfRyZTUGvv/b0S5lfhOeZFhf9R0AYI3/rmTcHtBf14Exhk+Cl25pgu1XPOUI3NYFTheWQYt2I83boarZcpnUjruqwR6/PjRVlnSqI0WZUbu74wzksa5hUEIWSN/eruV1iVQ033ox9h x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4919.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(508600001)(66574015)(166002)(66556008)(71200400001)(52536014)(83380400001)(2906002)(86362001)(66446008)(8676002)(91956017)(5660300002)(76116006)(64756008)(66476007)(6916009)(66946007)(186003)(316002)(9686003)(38070700005)(38100700002)(55016003)(8936002)(122000001)(33656002)(7696005)(6506007)(88722004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?ZXqoh+Hy/anvxjeG5nMu1PlGEulIj/wvwA2ovDGx5sVseVkwQHsrhSJz?= =?Windows-1252?Q?m6N6ABJ2ep1wVf9Du5s54prjKuohNdpLlwJml7S9HzejZCUSp00uht6Q?= =?Windows-1252?Q?YQRySdpbPS4DoOcAZ1+HM/T+VMCLqIcJ5kRr3tBezxC4NeHYDlZNWekw?= =?Windows-1252?Q?ILBLekBGnscCHpatYIW6FXMlP3jX6bXRS+K8rqceX+k/HUUIHEHN1znF?= =?Windows-1252?Q?xOgOAWIq5SfNIhWBYBC+0gDZ+AlTOVYzgIcGn+hgDwas6iGJVx7M9i6v?= =?Windows-1252?Q?/DhwfO7mf1RQ2qzKK/agKWpHiPxTM+fq2heQzufqPZeHqGCbE+ZBvRD+?= =?Windows-1252?Q?f59vas59H43a55DJZioeSb3jdG0VKa8zPP1CClNQ199Uo+JrXGDzSZTh?= =?Windows-1252?Q?qM3+khLvVlQLke35cNjc3JZns0SMsnzqH+XCdjH/DVj14fTE7BFJNoyi?= =?Windows-1252?Q?s06J1Y0XbSDkZv2fd0R+PYPrMjJcwsg3FGhrQD2rfcJvlxtrqtPLbYIt?= =?Windows-1252?Q?KdJu+BW5RO2wzfno8diTE4K2/ryw7ZIQ7q2fRTmLpCiWUsuXuqkSKKtw?= =?Windows-1252?Q?B/mxwSmjSrxWuG7q4wUYbvusodqhzSfxLFyNn4UO8zFfHVv27fHv+nDE?= =?Windows-1252?Q?MiWzoT6Bgr4mYbQf3d1qB3y+QAkT2whwQ0Fe8T2NUai28+eJD+OUh4t1?= =?Windows-1252?Q?PWT4NQpQfvjItXbA2srAyxbVT/BHMUMB8NynPGqj1DUzyYW4nu5TUGBM?= =?Windows-1252?Q?f3mFOO8ZvW7a41wKuXnr6I7wIbToeSZpND/rKJkxX/No9SID376ltSG+?= =?Windows-1252?Q?2/J14MSrxZJQFd1DFLKjqHQhTj54TtW83o87aL6/hYwEAzaxH0prbAKV?= =?Windows-1252?Q?H1PTuu+xUD3qnKm8RFlSA638Oeernws9PED5UGkBm5bvKuiZRtu3oseQ?= =?Windows-1252?Q?5uzu5hU1Luk/MjJJZW4roxzoaUT2IK+q3WEBiTFD66wuDNdTaHxXpsYA?= =?Windows-1252?Q?O5xGKF3w8ggQ2EngzJIYABE1IYSXCLHZFPd0TEc118ehiAWPTsvsVx51?= =?Windows-1252?Q?4nMVn1awYCuzivnQ0FlFynDcYO9lKeETByPKmQ+M1d2l1yCGv/ilpXQW?= =?Windows-1252?Q?WCBNy4IEvvRgT/Sy9l72/QDvAbHBcaymcK/xBP7V4NdE0/HNdYgT5sds?= =?Windows-1252?Q?jx2Y4F4/RiZv/UMIDbBZ360Y9UX1lDfMaIfxO2YpFmP7DRi3gG4CF0vc?= =?Windows-1252?Q?pMjySIoafqPZuOZ455Vl7nazD6w1VYlfFX+UJ9B3CHv60oKCQyIDPx8M?= =?Windows-1252?Q?PiQgdHyXO/GuckKOnKVN87aYk7R3yXmmiVhvKjMiCPfwFUawGnJrbZFc?= =?Windows-1252?Q?U25u/G6kT51VNbIGDIZe7GeE8ma0nDjs0LrhB2Vbzvy323FRAZw3liO4?= =?Windows-1252?Q?+oTmOsQnQRGT5lywKglEcHeSZVuvNKnPlxLMpPV/P/UqEg8fTiyOi+vQ?= =?Windows-1252?Q?tAcMmdyjU4oNoctii/1I0RKTyFGb11Hw3cKwH9/LF6nYE302eJdrIwN1?= =?Windows-1252?Q?kR5EOZGRZtAXx11ZumRWB9ukupLSHSJox/4kQ3kHfAT7OFo3UMfalsMS?= =?Windows-1252?Q?XFEQ90ehW/SpSmcSmBIZXfOHxOIzRgLsTV9PNxlmrHptIcrocczc7om5?= =?Windows-1252?Q?pPXhNi893qBZNcpt+AwTxrSWcMpLpm0g8h3na4bKrYHCJnUDX3wTU08G?= =?Windows-1252?Q?bbrstUqHiqVTYVXib3TxPwIX653ZlbGfi1dZ8fw7?= Content-Type: multipart/alternative; boundary="_000_PH0PR11MB49191206429434A87E700C4E8C529PH0PR11MB4919namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4919.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d2d58521-992e-482b-a096-08d9d5b0f88a X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2022 09:50:30.8868 (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: RGnqLp18KBfDywEN10TbuLL25XyQoW3PnzTzVGHi+flvBybPIXjch1L/nSeGcq2l X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB3261 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.17, xbe-rcd-002.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: [Roll] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2022 09:51:03 -0000 --_000_PH0PR11MB49191206429434A87E700C4E8C529PH0PR11MB4919namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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=3D=3D>D=3D=3D>E-to-F,G P-DAO 2 signals A=3D=3D>B=3D=3D>C-to-C,F,G [Li] -> Should it be ? P-DAO 1 signals C=3D=3D>D=3D=3D>E-to-F,G P-DAO 2 signals A=3D=3D>B=3D=3D>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 REC= OMMENDED that the nodes involved in a Track =3D=3D=3Dmantain=3D=3D=3D multi= ple 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 use= s diverse source route paths to retry similar messages =3D=3D=3Dot=3D=3D=3D= the nodes in the Track.=B6 [Li] -> Typo for =93mantain=94 and =93ot=94? 4.1.6. This specification defines a new flag "Projected Routes Support" (D). The DODAG Configuration option is copied unmodified from parents to childre= n. =3D=3D=3D=3Dxref target=3D'RFC6550'/>=3D=3D=3D=3D states that: [Li] -> Typo for =93xref target=3D'RFC6550'/>=94. Why is flag named as =93= D=94? There is no D in "Projected Routes Support"=85 5.1 The Root may use an asynchronous PDR-ACK with an negative status to ind= icate 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 egre= ss 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=92s not flexible If PD= R 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 s= pecial 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, i= f 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 hap= pen. [Li] -> Confuse with this claim. Is it a MUST NOT if root wants to send not= ification 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 i= t creates without collision. [Li] -> Can you add some description for the collision case? E.g., node tru= sts itself than Root. 6.4.1 In both cases the Track Ingress is the owner of the Track, and it gen= erates 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 f= rom 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 Rou= te Header in the most common LLN deployments. [Li] -> Profile 0 is the Legacy support of [RPL] Non-Storing Mode. I= =92m confuse about =93this enables to use Storing Mode to reduce the size o= f the Source Route Header in the most common LLN deployments.=94 Best regards, Li --_000_PH0PR11MB49191206429434A87E700C4E8C529PH0PR11MB4919namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hello Authors,

 

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

 

3.5.2 Using Non-Storing Mode jo= ining Tracks

P-= DAO 1 signals C=3D=3D>D=3D=3D>E-to-F,G

P-= DAO 2 signals A=3D=3D>B=3D=3D>C-to-C,F,G

 

   [Li] ->  S= hould it be ?

P-= DAO 1 signals C=3D=3D>D=3D=3D>E-to-F,G

P-= DAO 2 signals A=3D=3D>B=3D=3D>C-to-E,F,G

 

    Otherwise RI= Bs in A cannot include destination to E.

 

4.1. Extending RFC 6550

To ensure that the PDR and P-DAO messages can flow a= t most times, it is RECOMMENDED that the nodes involved in a Track =3D=3D= =3Dmantain=3D=3D=3D 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 pa= ths to retry similar messages =3D=3D=3Dot=3D=3D=3D the nodes in the Track.= =B6

    <= /span>

[Li] -> Typo for =93mantain= =94 and =93ot=94?

 

4.1.6.

This specification defines a new flag "Projecte= d Routes Support" (D).

The DODAG Configuration option is copied unmodified = from parents to children. =3D=3D=3D=3Dxref target=3D'RFC6550'/>=3D=3D=3D= =3D  states that:

 

[Li] -> Typo for =93xref target=3D'RFC6550'/>= =94.  Why is flag named as =93D=94? There is no D in "Projected R= outes Support"=85

 

 

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 st= atus PDR-ACK and No-Path P-DAO in section 6.5?&= nbsp; And when to use asynchronous PDR-ACK?

In storing mode, root s= hould 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?<= /o:p>

 

 

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

 

[Li] -> Is it possible to re= move the limitation?  It=92s not flexible If PDR can only carry one RT= O.

Fo= r instance in figure 7, if node I requests P-Route to B&H together, Roo= t 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 spe= cial PDR-ACK Status.

 

 

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

 

[Li] -> Is it possible to ad= d a flag to indicate the symmetry? Otherwise, if A chooses B as sibling, bu= t B doesn't choose A as sibling, Root may treat SIO from A as symmetry incorr= ectly when only receiving SIO from A.<= /p>

 

 

6.2  There is no notificat= ion 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 descriptio= n for the collision case? E.g., node trusts itself than Root.

 

 

6.4.1 In both cases the Track Ingress is the owner o= f the Track, and it generates the P-DAO-ACK when the installation is succes= sful

 

[Li] ->  Is ther= e 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 f= lag to distinguish P-DAO-ACK from DAO-ACK as P-DAO from DAO.

 

 

8 Profiles 0 and 1 are REQUIRED by all implementatio= ns 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] Non-Storing Mode. I=92m confuse about =93this enables to u= se Storing Mode to reduce the size of the Source Route Header in the most c= ommon LLN deployments.=94

 

 

 

Best regards,=

Li

 

 

 

 

 

 

 

 

 

 

--_000_PH0PR11MB49191206429434A87E700C4E8C529PH0PR11MB4919namp_-- From nobody Thu Jan 13 09:28:28 2022 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BCF83A181D; Thu, 13 Jan 2022 09:28:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.42.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <164209490109.19276.7124646419969397685@ietfa.amsl.com> Date: Thu, 13 Jan 2022 09:28:21 -0800 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-dao-projection-23.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2022 17:28:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks WG of the IETF. Title : Root initiated routing state in RPL Authors : Pascal Thubert Rahul Arvind Jadhav Filename : draft-ietf-roll-dao-projection-23.txt Pages : 82 Date : 2022-01-13 Abstract: This document extends RFC 6550, RFC 6553, and RFC 8138 to enable a RPL Root to install and maintain Projected Routes within its DODAG, along a selected set of nodes that may or may not include self, for a chosen duration. This potentially enables routes that are more optimized or resilient than those obtained with the classical distributed operation of RPL, either in terms of the size of a Routing Header or in terms of path length, which impacts both the latency and the packet delivery ratio. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-dao-projection/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-roll-dao-projection-23.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-dao-projection-23 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Thu Jan 13 09:31:23 2022 Return-Path: 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 DBC2D3A1837 for ; Thu, 13 Jan 2022 09:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.585 X-Spam-Level: X-Spam-Status: No, score=-9.585 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_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=MJDRYrPk; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=wv5+cqTN 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 0503A84Ecy2Z for ; Thu, 13 Jan 2022 09:31:17 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 753283A1834 for ; Thu, 13 Jan 2022 09:31:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=46992; q=dns/txt; s=iport; t=1642095077; x=1643304677; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=ESS3E1Lx7RWAaY0ZBKaReWsogQn2YjYLzoDcUPqlAk0=; b=MJDRYrPk1qE0WB3t+t2c7/ZtSotz+JjPTqhirVmL5tKki5sgcKODLrcy pnkVU9KSJkzO4eDybm0cJM+zVUtChnbLXQv3IuKss7Q16DiLBRmje3bPB mmZ/kriUL+TV8j4vdYC8jNxejzWnXTzfOqRHU/2828TFjqOkZSiPyvLM1 Q=; X-IPAS-Result: =?us-ascii?q?A0AVAQAQYeBhl4cNJK1aHgErCwYMIoFZgSExVX5aNzGID?= =?us-ascii?q?AIDhTmFDl2CJQOBE48gimqBLhSBEQNUCwEBAQ0BATcKBAEBhQYCg0oCJTQJD?= =?us-ascii?q?gECBAEBAQEDAgMBAQEBBQEBBQEBAQIBBgQUAQEBAQEBAQEkBgwFEDWFOwEEK?= =?us-ascii?q?A2GQgEBAQECAQwGFQYTAQE4BAsCAQgRBAEBIQENMh0IAgQTCBqCXAGCDlcDD?= =?us-ascii?q?SEBDqIOAYE6AoofeIEBMoEBgggBAQYEBIE6AoNPGII2AwaBOoMOgn5USocJJ?= =?us-ascii?q?xyBSUSBFAFDVYERSjc+gmMCAhiBKAQcJAeDIoIukBIBJUYOYA0lEQ4CIC0DD?= =?us-ascii?q?R4IFjcYAQISBw8fC5I/jQeBcIt+klkKg0OJIpZJFYNwjAqXcpZAoSgXCwuEX?= =?us-ascii?q?gIEAgQFAg4BAQaBYTmBW3AVgyRRGQ+Fa4JfhW+DWIUUhUp0AjYCBgsBAQMJj?= =?us-ascii?q?VAHgj8BAQ?= IronPort-PHdr: A9a23:bMjxYBFwTHztj0Jil4pABp1GfiYY04WdBeZdwpYkircbdKOl8tyiO UHE/vxigRfPWpmT8PNLjefa8sWCEWwN6JqMqjYOJZpLURJWhcAfhQd1BsmDBAXyJ+LraCpvG sNEWRdl8ni3PFITFtz5YgjZo2a56ngZHRCsXTc= IronPort-Data: A9a23:7Ngveq8QNWMdTHIXYJtZDrUD636TJUtcMsCJ2f8bNWPcYEJGY0x3n GZNCGuFPazcajfyf9wjOYWyo0NV6p/czNE1TlNsrihEQiMRo6IpJzg2wmQcns+2BpeeJK6yx 5xGMrEsFC23J5Pljk/F3oLJ9RGQ7onVAOqsYAL4EnopH1U8EX560UgLd9MR2+aEv/DoW2thh vuqyyHvEAfNN+lcaz98Bwqr8XuDjdyq0N8qlgVWicNj4Dcyo0Io4Kc3fsldGZdXrr58RYZWT 86bpF2wE/iwEx0FUrtJmZ6jGqEGryK70QWm0hJrt6aebhdqmXAz8vhgJfEnTGhLqQSSk9E27 M1VusnlIespFvWkdOU1Wh1cFWR1OrdLveWBKnmkusvVxErDG5fu66wxVwdtY8tBoaAuWjwmG f8wcFjhajibm+Kryr+hVsFnh98oK4/gO4Z3VnRInWmBUat+GcCYK0nMzfx2x25vgd1pJtL1X tchMSNiVz7fRQIabz/7D7pnzLv32RETaQZwslWRoYI27nTdigtr39DQ3MH9c9iOQ4BemVyV4 ziA9GXiCRZcP9uaodaYzp6yrtCTnAOlA5MZL5iX6txbm1GSgUgLEBJDADNXvsKFokK5XtteL Wkd9SwvsbU++SSXoj/VAkHQTJms40V0ZjZALwEpwFrWk/OLvW51EkBBH2AfN41/3CMjbWVyj je0c8XV6SuDWVF/YVuZ8rqSxd9ZEXdIdTZZDcPooPds3jUOiIg3ihSKRdF5HevvyNb0Ajr3h TuNqUDSZon/b+ZWi81XHnie3lpAQ6QlqCZuvG07uUr+t2tEiHaNPdDA1LQixa8owHylZleAp mMYvMOV8foDC5qA/ATUHrlXROjzva7famKA6bKKI3XH32nyk5JEVd0OiAyS2G8yWir5UWazO RSK6V85CGF7ZSX7PMebnL5d++xznfS/SrwJp9jfb8FFZdBqZRSb8SR1DXN8LEiz+HXAZZoXY M/BGe71VC5yIf0+nFKeGrZGuZd2l39W+I8mbc2ip/hR+eHGNCD9pHZsGAbmU93VG4vf8VqFq IgOZpLao/idOcWnChTqHUcoBQhiBRAG6Vre8aS7qsbrztJaJVwc IronPort-HdrOrdr: A9a23:fcJu1KFxu3TEChxqpLqFRJHXdLJyesId70hD6qkvc31om52j+f xGws516fatskdvZJhSo6H/BEDgewKTyXcR2+ks1NiZLXHbUOXDFvAY0WKP+UyEJ8S6zJ8g6U 4CSdk+NDSTNykBsS+S2mDReLxMrKjlgcKVbKXlvgpQpGpRGsZdBnJCe3+m+zpNNW977PQCZf 6hz/sCgwDlVWUcb8y9CHVAdfPEvcf3mJXvZgNDLwI76SGV5AnYqILSIly95FMzQjlPybAt/S zuiAri/JiutPm911v1y3LT1ZJLg9Hso+EzR/Bky/JlaAkEuDzYILiJaIfy+wzdZ9vfrmrCpe O85ivI+f4Dsk85MFvF+ScFkDOQoQrGo0WSuWNwx0GT+vAQgFkBepd8bUUzSGqC16NohqAO7I tbm22erJZZFhXGgWD04MXJTQhjkg6urWMlivN7tQ0TbWIyUs4bkWUkxjIeLH7AJlOM1Kk3VO 11SM3M7vdfdl2XK3jfo2l02dSpGnA+BA2PTEQOstGcl2E+pgE382IIgMgE2nsQ/pM0TJdJo+ zCL6RzjblLCssbd7h0CusNSda+TmbNXRXPOmSPJkmPLtBKB1vd75rspLkl7uCjf5IFiJM0hZ TaSVtd8XU/fkr/YPf+lKGjMiq9CVlVcQ6dv/221qIJzIEUHoCbQxFrYGpe5/ednw== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.88,286,1635206400"; d="scan'208,217";a="800450083" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Jan 2022 17:31:16 +0000 Received: from mail.cisco.com (xbe-rcd-002.cisco.com [173.37.102.17]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 20DHVF15018282 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for ; Thu, 13 Jan 2022 17:31:15 GMT Received: from xfe-rtp-001.cisco.com (64.101.210.231) by xbe-rcd-002.cisco.com (173.37.102.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Thu, 13 Jan 2022 11:31:15 -0600 Received: from xfe-aln-002.cisco.com (173.37.135.122) 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; Thu, 13 Jan 2022 12:31:14 -0500 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-002.cisco.com (173.37.135.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Thu, 13 Jan 2022 11:31:14 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nH9+qzWzXUVFw1Og1/cy0kxZHFUj7KPlAlx2zGFBN677EkKFf//TDX1w3JqzNAQjQOtLp7+A8mIL8mqhfkel4gUzNQ1Hb039dlH6hbw657VMQMCj9Bx4C74ecREFqFCUQmmIM60cGaWsTsE5TWvdkt8PZ+Yc+/JGJdwtZ7DW7kQKYZXeijL6I9ae7afZRedPu0OGOGziEpBOTCzVsIk8HfW6A0bMPqDmJHxq4rsDv7gAjr+MJtndrI2yQ1HZ92xEsbLyj2DkHV3pqFcYRwXd9Nbpx8dyPw3QhM4C4H6wfGOaCqRMRGToVwMdW6VBeSsgonaKxkuW0Jg+PYeL0FF2Yg== 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=SQCsuYdKJnIqjXlYAZmC/kaJkbM3qPQHwf7mywmre44=; b=kab8K58o1RSkMCjHN0rsF6wT/3mdp7/n4buLeblKVj+ifzNKKP+w5108VgMiklNCdBWc0HBlaCaaDqXd0KQrlabbuBfoTtc8eUrag8aWSpv4OAosDECwyT4KWN7+fmMw1EIeno771Xu6JTlQkLSRHLHUBtLgYlcJY9jZVCKwERHcIVQMQMs9eMZ/cC2ozewPDgy7z7MwhciTIKXwOSRJXyJ8hdAbiu9ced+/eIBkLRwyrQQYv+2KLTCZRJ6JEBVvHhO3EQ+sUXAuMUu/IJA7qhbTtwRcHT7dDPcGJVivCNokXCTEIEP38YAmHLyGyNWZQuKbKBAuZ7Pg9X8Z7m4vIA== 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=SQCsuYdKJnIqjXlYAZmC/kaJkbM3qPQHwf7mywmre44=; b=wv5+cqTNmZApWH+yVifnRdpNNeMbUX9qmwHLESKgLSh8M3/CB75m0hIfFB3hFt+tCcnflpGT+H2XixPymWfTzYfXDgdgQr6SEsf7G0kplyViVf6kwv9kSVoop7xQy8fo6e843a/zSe2jsBrDEw5Gl0RlcQnI7GI0xQflERmEcnA= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MWHPR11MB1360.namprd11.prod.outlook.com (2603:10b6:300:26::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4867.11; Thu, 13 Jan 2022 17:31:12 +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.011; Thu, 13 Jan 2022 17:31:12 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] review of dao-projection -22 Thread-Index: AQHYB3I0RLVoN8WqFEOEiCVUH4Lia6xglxwQ Date: Thu, 13 Jan 2022 17:30:53 +0000 Deferred-Delivery: Thu, 13 Jan 2022 17:30:49 +0000 Message-ID: References: In-Reply-To: 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: 4b34e8aa-9d78-4cca-c00c-08d9d6ba7ebc x-ms-traffictypediagnostic: MWHPR11MB1360:EE_ x-microsoft-antispam-prvs: 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: /4zV7so/f+sRGZQ1fQhcMYGgwgy4bXch/WCfbTRJlMEzOrwyXmPun6ObKPswvS3SWfCfaIbLG/WKGfUSO/1PZL80ofvGisYUwFwKev927/jhTxgFZ9oMYpzr1s6HJWh+jI/ZW6ZUWL7qHgIPzaLFglt+10BW1Q8EAoCGs1ZbFS6kPknrV0O6TniDRFAVWwLMfSrZ0MSipDsQ81mwJRx2fVKcQldskjViXIXvZ25gsBxRrtlBEpUliHwqIiCSnT4y8JCL80Ay1IDKwrktaozm7y+pFVWeuJDlLxSzGvWPjr7rL4MqFZwMyhYtOm6/GW5BA7l7BCrbjpQc5k69+yOgZOQKqkdDCXPF+yYj8TxQc2BQspaXBje0d2BtYrjza38P7++TsqgCVH6UM6XdeNvN711Idd5tC3lAuAgaW+FpwxDwjDG0dIo6NtQ/Ez+iZLJloRTlaNeJeO5RHG6hxgqCoPXQ2q2zc7o8ezlVw+YYYgXKgVhOIxczXn3tAfw24oavhcpkKl85mV1XqJ1VPoBWz21625b8srOdEuVnCdr1/M7ky5i0WFev2Q6HujNgzopdeXAifbYDhhebCfUHtAVbDDcDuvxd0yKU3IEjslzzZZ42Wq8fpxPzE9sHqt/qzbfT/zkalzzL/FsUtOrozsnw1LLrNHgOrJFIvI5gaXleHVp7a3zzg5prcBvg0wAQNYtZAtGFirMg1u2uliqr/B8OSx83fyFxv1sc4RlXGN5mQ+rE6mkdw+sU+I4po4T43m2IscCEbhzkjcDnm9PN5VJmkM9SDliTG+a8p9FBfzynE/bMh7iJSGAWgSNecN879btHv7oovRjyxmLcU+HcaKJxog== 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)(9686003)(55016003)(33656002)(66574015)(83380400001)(166002)(52536014)(966005)(86362001)(508600001)(7696005)(38070700005)(5660300002)(64756008)(8936002)(26005)(66446008)(122000001)(186003)(66946007)(53546011)(2906002)(6666004)(316002)(71200400001)(6916009)(6506007)(8676002)(66476007)(66556008)(38100700002)(76116006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?6A8OPtgRUXVn5UeqfWv0iQhYjI5gyo8WchyixONPZSpnoWUi+FOycHBTyi?= =?iso-8859-1?Q?l6ElLy30tnynC9tCio6UzQvrhAArQC4Q+2PXbQcPDP/CXNoHeMJyL62ur8?= =?iso-8859-1?Q?V3jWy2sc7EhhaP+tawhHluoxD4nVHflTPfUZ0DWDm0UFM4+nj0MKL+1hHs?= =?iso-8859-1?Q?JCWOjfLgU1k95nSB6xf/USuRWrtWJC6soN0/UPhfMU0af3yUAz/Ila/G3a?= =?iso-8859-1?Q?wU/YFPoC6t/w/+zXN/oozW0gOrjhdHaFh0OKKXgtuU2UeYOB6jRJPEvyig?= =?iso-8859-1?Q?w3ik54qcBpd4XvSaTYECLr+ROdL8H6+lI/xEr04b4XnRB0G81KO9X8In2Q?= =?iso-8859-1?Q?nhUMOW1tlrygaKw+p15BdDv/SXd4halypyqkiLWBX5d5Hb3zM1781AT4af?= =?iso-8859-1?Q?djaeP3Uh2AGzNhK9IgHuDXSmZd2CmYZcDDclWsYa0BgLdD3yarMxuzcQuY?= =?iso-8859-1?Q?+yFKH3zNQ4tjT56uJFhWsrqyXd6MovdZbbG3uxhnHxFUDOBDNfusDaVSTS?= =?iso-8859-1?Q?MhN+QnQhgWNSIv3eSFmys6wfcSastZLOl30+UVPEXdSxoZuJ/27lUkHNCf?= =?iso-8859-1?Q?qF3y+BQLI4ajAga1K7Vwpe28ORHe0s812cNh9FeWfSc6MXwhSwMMiHCzsA?= =?iso-8859-1?Q?a5zbSLrvNFLefg48ZzEkIVa6MoXOapZ8IUDRXd6J0EOVvX9s5EK9bPCkUO?= =?iso-8859-1?Q?5LjwsxoiB910p/kKxCLrfNYgKXgrlfrLZ1Lpts+oP30T/RgRgfa3dFnr/8?= =?iso-8859-1?Q?O3uAVqYVNKCPD5CwiCQ58wMWDY9f6K3kLEoZf5fQlq1nSP57R6Dzi3gM/n?= =?iso-8859-1?Q?rNZTbhANUh/E0uE/yrAZeswHYyC4yxQ/ZXreKeiYPqGnEIYfqeU9szex5q?= =?iso-8859-1?Q?EEgp9wyNdoYd2lDyxf+IFks4CZ/VJKA0tJPiaFsfJcz0LrOvUVJv0dIOOI?= =?iso-8859-1?Q?xHHswn8JmC3jUng05jIzYCLFLdSVTmSPwyTz2J9S/OyhS97Hdywi3PP6qC?= =?iso-8859-1?Q?j8JZG22Pl8SN1sP0PWVlYJ/URRI8uQy1ksYv7bKDe2T43v+kq0KYMh5tXd?= =?iso-8859-1?Q?Gl3uGrautf58LkAkrjwcf3k/RvUpOCcmFyl2efjZZMJCoSndv8cUFmh0WI?= =?iso-8859-1?Q?c8Cl7osrLBjiioB4azEZtoKWU6Q4OZ6Fv91P6r+ZE+AE9KtiMGwC7zS9wX?= =?iso-8859-1?Q?3eKlS1e7CyUKaBvbFKRksaI5gB8wsfI6vVSwN2EaOWSDD7AL/28HTFCmPR?= =?iso-8859-1?Q?WGXc/yV5wFJEQnB4f0Tii66MIEJJjvQ2Hl45uwn2Z8FoaUyzP1ePBjOTmU?= =?iso-8859-1?Q?RyKGtSDGquoPojBji45MqlTE2SaA2rxBduOvqsuhXgo5FxQ4lDy8dG+CPA?= =?iso-8859-1?Q?E33dWOJ6MFapBsywqFioMpHMGtsV7MCdVaD1rltzTt5Hga8JyXakAY+Yty?= =?iso-8859-1?Q?nhei0wm1plyWztM87AD8i4vbo+2zSrT5kdDJmjeZ4AcAeMzMkCh22ufPL+?= =?iso-8859-1?Q?f+NBOAkt0+7HpR6L6mLTQ2Y7xDn8clPOwTRO5esiDdnopy0y2y6rAvctuE?= =?iso-8859-1?Q?LVwVenExokcXskz9IMrxzGslCfH5yza51iX28e9SjB7J8nLLgzEx4+qQG4?= =?iso-8859-1?Q?kM7bz7l/HDZgGOxsmengfUdDuv2JCZTBXryPLQtKeGlaC2radeJ9QxCHbw?= =?iso-8859-1?Q?lTcZ2mis66oNsz4rESE=3D?= Content-Type: multipart/alternative; boundary="_000_CO1PR11MB488199BB84788175250761EAD8539CO1PR11MB4881namp_" 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: 4b34e8aa-9d78-4cca-c00c-08d9d6ba7ebc X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2022 17:31:12.5227 (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: DsER21oR6qcwWICwmZgSq2UyaNk/dxeI8/VbzL2YaSltm7BqXKQFfcTBBwh9JyBK45FVSRyxzx5DPl6n2nrO7g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1360 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.17, xbe-rcd-002.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [Roll] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2022 17:31:21 -0000 --_000_CO1PR11MB488199BB84788175250761EAD8539CO1PR11MB4881namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Li A great many thanks for your excellent review! Such are much needed at this= time. > [Li] -> Should it be ? > P-DAO 1 signals C=3D=3D>D=3D=3D>E-to-F,G > P-DAO 2 signals A=3D=3D>B=3D=3D>C-to-E,F,G [PT] correct, great catch! > [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 T= rack from egress node. Is PDR-ACK still needed? > In non-storing mode, No-Path P-DAO to ingress node is also en= ough. > But the PDR-ACK Status field makes sense. Is it possible to a= dd this field in No-Path P-DAO? [PT] The no path DAO flow along the reverse path and cleans it; so the end= result would be that the Track is terminated as you figured. So yes, it co= uld be possible to add a status to the no-path DAO but remember that it is = a normal DAO not a completion (IOW not an ack). How could we justify a stat= us in all DAOs? I'm unclear why the async PDR ack is an issue. If the PDR c= an not be served, the track ingress already needs to support a PDR ack that= "terminates" a Track. To clarify that sentence we can say: " The main Root MAY indicate to the Track Ingress that the Track was termi= nated before its time and to do so, it MUST uses an asynchronous PDR-ACK with = an negative status. " Should that be more than a MAY? > [Li] -> Is it possible to remove the limitation? It's not flexible If PD= R can only carry one RTO. > For instance in figure 7, if node I requests P-Route to B&H t= ogether, 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 res= ponse with a special PDR-ACK Status. [PT] This was done in the interest to simplicity, and yes we can rediscuss= that. We'd need to make decisions on partially successful use cases e.g.,: * What if there's a path to only a subset? Should the root form more th= an one track? * Or deny with your special status but then what can the source do afte= r that? Try all combinations? * What is the best path to one target cannot reach all targets but a lo= wer quality path can? Should we use that one? * Maybe there could be one main target and additional desirable targets= ? In that case the Root could form the track and indicate which of the opti= onal targets are effectively reachable via the track to the main target. > [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 tre= at 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 simplifi= cation. 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] -> Confuse with this claim. Is it a MUST NOT if root wants to send n= otification to the requesting node when those changes happen. [PT] There's no protocol element to "send notification to the requesting no= de when those changes happen". So it's hard to say that the root MUST NOT d= o something that it cannot do. Reworded to " Note that there is no protocol element to notify to the requesting Tr= ack Ingress when changes happen deeper down the Track, so they are transp= arent to the Track Ingress. If the main Root cannot maintain an expected se= rvice level, then it needs to tear down the Track completely. " > [Li] -> Can you add some description for the collision case? E.g., node t= rusts itself than Root. [PT] I reworded to " = In a particular deployment where PDR are not used, a portion of the namespace can be administrati= vely delegated to the main Root, meaning that the main Root is authoritativ= e for assigning the TrackIDs for the Tracks it creates.. " [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 f= rom DAO. [PT] Done; I added a section for the P-DAO-ACK > [Li] -> Profile 0 is the Legacy support of [RPL] Non-Storing Mode. I= 'm confuse about "this enables to use Storing Mode to reduce the size of th= e Source Route Header in the most common LLN deployments." [PT] I really meant Profile 1 enables... Changing that. I guess that's it ! I submitted -23 with this, please have a look at https://www.ietf.org/rfcdi= ff?url2=3Ddraft-ietf-roll-dao-projection-23 Again many thanks! Pascal From: Roll On Behalf Of Li Zhao (liz3) Sent: mercredi 12 janvier 2022 10:51 To: Routing Over Low power and Lossy networks 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=3D=3D>D=3D=3D>E-to-F,G P-DAO 2 signals A=3D=3D>B=3D=3D>C-to-C,F,G [Li] -> Should it be ? P-DAO 1 signals C=3D=3D>D=3D=3D>E-to-F,G P-DAO 2 signals A=3D=3D>B=3D=3D>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 REC= OMMENDED that the nodes involved in a Track =3D=3D=3Dmantain=3D=3D=3D multi= ple 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 use= s diverse source route paths to retry similar messages =3D=3D=3Dot=3D=3D=3D= the nodes in the Track.=B6 [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 childre= n. =3D=3D=3D=3Dxref target=3D'RFC6550'/>=3D=3D=3D=3D states that: [Li] -> Typo for "xref target=3D'RFC6550'/>". Why is flag named as "D"? Th= ere is no D in "Projected Routes Support"... 5.1 The Root may use an asynchronous PDR-ACK with an negative status to ind= icate 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 egre= ss 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 s= pecial 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, i= f 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 hap= pen. [Li] -> Confuse with this claim. Is it a MUST NOT if root wants to send not= ification 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 i= t creates without collision. [Li] -> Can you add some description for the collision case? E.g., node tru= sts itself than Root. 6.4.1 In both cases the Track Ingress is the owner of the Track, and it gen= erates 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 f= rom 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 Rou= te Header in the most common LLN deployments. [Li] -> Profile 0 is the Legacy support of [RPL] 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 --_000_CO1PR11MB488199BB84788175250761EAD8539CO1PR11MB4881namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello Li

 

A great many thanks for your excellent review! Such are much= needed at this time.

 

> [Li] ->  Should it be ?

>          &= nbsp;  P-DAO 1 signals C=3D=3D>D=3D=3D>E-to-F,G

>          &= nbsp;  P-DAO 2 signals A=3D=3D>B=3D=3D>C-to-E,F,G

[PT] correct, great catch!

 

 

> [Li] -> What's the difference between negative status PDR-= ACK and No-Path P-DAO in section 6.5?  And when to use asynchronous PD= R-ACK?

>          &= nbsp;  In storing mode, root should use No-Path P-DAO to tear down T= rack from egress node. Is PDR-ACK still needed?

>         &n= bsp;   In non-storing mode, No-Path P-DAO to ingress node is also en= ough.

>          &= nbsp;  But the PDR-ACK Status field makes sense. Is it p= ossible to add this field in No-Path P-DAO?

 

[PT]  The no path DAO flow along the reverse path and c= leans it; so the end result would be that the Track is terminated as you fi= gured. So yes, it could be possible to add a status to the no-path DAO but remember that it is a normal DAO not a compl= etion (IOW not an ack). How could we justify a status in all DAOs? I’= m unclear why the async PDR ack is an issue. If the PDR can not be served, = the track ingress already needs to support a PDR ack that ”terminates” a Track.<= /p>

 

To clarify that sentence we can say:

“

   The main Root MAY indicate to the Track Ingress= that the Track was terminated

   before its time and to do so, it MUST uses an a= synchronous PDR-ACK with an

   negative status.

“

Should that be more than a MAY?

 

> [Li] -> Is it possible to remove the limitation? &nb= sp;It’s not flexible If PDR can only carry one RTO.=

>          &= nbsp;  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, Roo= t may push two Tracks I->A->B and I->F->G->H.

>         &n= bsp;   If Root cannot computer one Track to multiple RTO, it can = response with a special PDR-ACK Status.

 

[PT]  This was done in the interest to simplicity, and = yes we can rediscuss that.

We’d need to make decisions on partially successful us= e cases e.g.,:

  • Wh= at if there’s a path to only a subset? Should the root form more than= one track?
  • Or deny with your special status but then what = can the source do after that? Try all combinations?
  • What is the best path to one target cannot reach all targets but a lowe= r quality path can? Should we use that one?
    • Mayb= e there could be one main target and additional desirable targets? In that = case the Root could form the track and indicate which of the optional targets are effectively reachable via the track to t= he main target.

 

 

 

> [Li] -> Is it possible to add a flag to indicate the symmetry? Otherw= ise, 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 receiv= ing 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 goo= d description of how the node will know that the link is roughly symmetrical.

 

 

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

 

[PT] There’s no protocol element to “send notification to the requesting node when those changes happen”= . So it’s hard to say that the root MUST NOT do something that it can= not do. Reworded to

 

“

      Note that there is no protoco= l element to notify to the requesting Track

      Ingress when changes hap= pen deeper down the Track, so they are transparent=

      to the Track Ingress. If the = main Root cannot maintain an expected service

      level, then it needs to tear = down the Track completely.

“

 

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

 

[PT] I reworded to

“

          =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =          In a particular deployment=

     where PDR are not used, a portion o= f the namespace can be administratively

     delegated to the main Root, meaning= that the main Root is authoritative for

     assigning the TrackIDs for the Trac= ks it creates..

“

 

[Li] ->  Is there any difference between P-DAO-ACK and normal DA= O-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.

 

[PT] Done; I added a section for the P-DAO-ACK

 

> [Li] -> Profile 0 is the Legacy support of [RPL] 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.R= 21;

 

[PT] I really meant Profile 1 enables… Changing that.<= o:p>

 

I guess that’s it !=

 

I submitted -23 with this, please have a look at https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-dao-projection-2= 3

 

Again many thanks!

 

Pascal

 

From: Roll <roll-bo= unces@ietf.org> On Behalf Of Li Zhao (liz3)<= br> Sent: mercredi 12 janvier 20= 22 10:51
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org>
Subject: [Roll] review of da= o-projection -22

 

Hello Authors,

 

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

 

3.5.2 Using Non-Storing Mode joining Tracks

P-DAO 1 signals C=3D=3D>D= =3D=3D>E-to-F,G

P-DAO 2 signals A=3D=3D>B= =3D=3D>C-to-C,F,G

 

   [Li] ->  Should it be ?

P-DAO 1 signals C=3D=3D>D= =3D=3D>E-to-F,G

P-DAO 2 signals A=3D=3D>B= =3D=3D>C-to-E,F,G

 

    Otherwise RIBs in A cannot include destin= ation to E.

 

4.1. Extending RFC 6550

To ensure that the PDR and P-DAO messages can flow at most t= imes, it is RECOMMENDED that the nodes involved in a Track =3D=3D=3Dmantain= =3D=3D=3D 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 si= milar messages =3D=3D=3Dot=3D=3D=3D the nodes in the Track.=B6

   

[Li] -> Typo for “mantain” and “ot̶= 1;?

 

4.1.6.

This specification defines a new flag "Projected Routes= Support" (D).

The DODAG Configuration option is copied unmodified from par= ents to children. =3D=3D=3D=3Dxref target=3D'RFC6550'/>=3D=3D=3D=3D &nbs= p;states that:

 

[Li] -> Typo for “xref target=3D'RFC6550'/>̶= 1;.  Why is flag named as “D”? There is no D in "Proj= ected Routes Support"…

 

 

5.1 The Root may use an asynchronous PDR-ACK with an negativ= e 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 th= e 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 T= rack to multiple RTO, it can response with a special PDR-ACK Status.

 

 

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

 

[Li] -> Is it possible to add a flag to indicate the symmetry? Otherw= ise, 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 receiv= ing SIO from A.

 

 

6.2  There is no notification to the requesting node when those changes h= appen.

 

[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 n= amespace can be delegated to the main Root, which can assign the TrackIDs f= or the Tracks it creates without collision.

 

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

 

 

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

 

[Li] ->  Is there any difference between P-DAO-ACK and normal DA= O-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= ] Non-Storing Mode. I’m confuse about “this enables to use Storing Mode to reduce the size of the So= urce Route Header in the most common LLN deployments.”

 

 

 

Best regards,

Li

 

 

 

 

 

 

 

 

 

 

--_000_CO1PR11MB488199BB84788175250761EAD8539CO1PR11MB4881namp_-- From nobody Thu Jan 13 17:51:09 2022 Return-Path: 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 74B4B3A1487 for ; Thu, 13 Jan 2022 17:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.585 X-Spam-Level: X-Spam-Status: No, score=-9.585 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_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=hu1ol+Zd; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=sdm5s1WL 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 1y5E2N88GgfF for ; Thu, 13 Jan 2022 17:51:01 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EE5A3A1485 for ; Thu, 13 Jan 2022 17:51:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=48454; q=dns/txt; s=iport; t=1642125061; x=1643334661; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=ZjqDyYwdHnEgXvnKO6MpOHo4SfCHBNb50X7/YCtxZns=; b=hu1ol+ZdrYs+m9fSBqkeAHZme8kSFZMD+3UxNwoZkxx1DwBg3oaC5zZQ kIz6MSmiSkP1nBXPOq386wvnVtBQQIw/LJwjIlBsxM9y6Sn524qEnU95y gbE3C95dfsThGC3fz4rQ8tacYm1ZXsgnQG2W30FKD+M/+haDpVTZ+foam g=; IronPort-PHdr: =?us-ascii?q?A9a23=3A6TBOwRPs/xjqenxtRTwl6ncDWUAX0o4cdiYZ6?= =?us-ascii?q?Zsi3rRJdKnrv5HvJ1fW6vgliljVFZ7a5PRJh6uz0ejgVGUM7IzHvCUEd5pBB?= =?us-ascii?q?BMAgN8dygonBsPNAEbnLfnsOio9GskKVFJs83yhd0ZPH8OrbFzJqXr05jkXS?= =?us-ascii?q?X3C?= IronPort-Data: =?us-ascii?q?A9a23=3AoTyK6apryxmIkteNgwlAwuQl4FteBmIJZxIvg?= =?us-ascii?q?KrLsJaIsI4StFCztgarIBmDbv6JMTf3f9x3OYS+pEpUu8XRyYJlTlRvqnxgQ?= =?us-ascii?q?nsV9+PIVI+TRqvS04x+DSFioHqKZKzyU/GYRCwPZiKa9kfF3oTJ9yEmj/nRH?= =?us-ascii?q?+akUYYoBwgoLeNaYHZ54f5cs7ZRbr5A2bBVMivV0T/Ai5S31GyNg1aYBlkpB?= =?us-ascii?q?5er83uDihhdVAQw5TTSbdgT1LPXeuJ84Jg3fcldJFOgKmVY83LTegrN8F251?= =?us-ascii?q?juxExYFENiplPPwdVcHB+eLewOPkXFRHaOlh3CupARrjf19b6VaOBwR0mnW9?= =?us-ascii?q?zxy4I0lWZiYTQY7ZYXHmf8WVF9TFCQW0ahuqeGXeSbv7JDJp6HBWz62qxl0N?= =?us-ascii?q?2ksOokc0ud6HW8I8uYXQA3hxDjra/me2rm3TKxngd4uaZCyeogeoXpnizreC?= =?us-ascii?q?J4brVn4a/2izbdlMP0Y36iixcrjWvc=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3ANoGQ3KNdC2xfAcBcT3T155DYdb4zR+YMi2?= =?us-ascii?q?TDiHoRdfUFSKKlfp6V88jzjSWE9Ar5K0tQ5uxoWZPwDk80kKQU3WB/B8bbYO?= =?us-ascii?q?CLghrMEGgm1/qe/9SCIVyxygc+79YaT0EWMrSZZjIW4beYkWuF+pQbsaO6Gc?= =?us-ascii?q?uT9IDjJgJWPHhXgtZbnmFE42igYylLbTgDIaB8OIuX58JBqTblU28QdN6HCn?= =?us-ascii?q?4MWPWGj8HXlbr9CCR2RiIP2U2rt3eF+bT6Gx+X0lM1SDVU24ov9mDDjkjQ+r?= =?us-ascii?q?ijifem0RXRvlWjr6i+2eGRieerNvb8z/T9GQ+czjpAo74RHIFqiQpF4t1HLm?= =?us-ascii?q?xa1uUk7S1QZviboEmhAF1d6SGdqjUIlgxes0MLDTSj8CHeSQuTfkNgNyMJv/?= =?us-ascii?q?MoTjLJr0Unp91yy6RNwiaQsIdWFwrJmGDn68HPTAwCrDv/nZMOq59as5Vka/?= =?us-ascii?q?pUVFaRl/1qwGpFVJMbWC7q4oEuF+djSMna+fZNaFufK3TUpHNmztCgVmk6Wk?= =?us-ascii?q?7ueDlPhuWFlzxN2HxpxUoRw8IS2n8G6ZImUpFBo+DJKL5hmr1CRtIfKah9GO?= =?us-ascii?q?ACS82qDXGle2OADEuCZVD8UK0XMXPErJD6pL0z+eGxYZQNiIA/nZzQOWko/F?= =?us-ascii?q?Lau3ief/Fm8Kc7gCwlcV/NKggFkPsulKSRkoeMMYbWDQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DNCwD11eBh/5NdJa1aHQEBKwEJAQY?= =?us-ascii?q?BBQUBIoFZAoEfMVUHd1o3MYgMAgOFOYUOXYIlA4ETjyCKaoEuFIERA1QLAQE?= =?us-ascii?q?BDQEBEgIjCgQBAYUFAoNKAiU0CQ4BAgQBAQESAQEFAQEBAgEGBIEJE4U7AQQ?= =?us-ascii?q?oDYZCAQEBAQIBDAYVGQEBOAQLAgEIEQMBAQEhAQ0yHQgCBBMIGoJdgg5XAw0?= =?us-ascii?q?hAQ6hAwGBOgKKH3iBATKBAYIIAQEGBASBOgKDTxiCNgMGgToBgw2CflRKhwk?= =?us-ascii?q?ngimBFAFDVYERSjc+gmMCAhiBKAQcHgYHgyKCLpAdASVGDmANJREOAiAtAw0?= =?us-ascii?q?eCBUBNxgBAhIHDx8LC4EFAZEujQeNbpJZBgSDQ4kilkkVg3CMCpdylkChKAg?= =?us-ascii?q?PCwuEXgIEAgQFAg4BAQaBYTuBWXCBboFLURkPhWuCX4lHhRSFSnQCNgIGCwE?= =?us-ascii?q?BAwmNZweCPwEB?= X-IronPort-AV: E=Sophos;i="5.88,287,1635206400"; d="scan'208,217";a="968068542" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Jan 2022 01:50:59 +0000 Received: from mail.cisco.com (xbe-rcd-004.cisco.com [173.37.102.19]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 20E1oxCj016355 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for ; Fri, 14 Jan 2022 01:50:59 GMT Received: from xfe-aln-003.cisco.com (173.37.135.123) by xbe-rcd-004.cisco.com (173.37.102.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Thu, 13 Jan 2022 19:50:59 -0600 Received: from xfe-rcd-001.cisco.com (173.37.227.249) 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.986.14; Thu, 13 Jan 2022 19:50:58 -0600 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-001.cisco.com (173.37.227.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Thu, 13 Jan 2022 19:50:58 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SKrxLPeqeZckCEVdoX9iuTWNQZxIYaOxjLELjOiELJNP5KXPfSbRvb56+M6yplGGVPwFDGgv/8mwU0n1PWfhyt5ElLudn28QryRuZgwPNbjznAJV60B8WRgQC9TFzcBsUhhls+YPvqmRw8p65NpvK5nEabhuqhD69E3KJm3peqmn6g2jMdmmsEeIjicjmrDEKU0oDKsHDlZDwp2vRfCGqWK8jfKUiK0tG3Ge1DBnfethMhUDljySrxHbEZCIwwS5uvWis6ukizxj9MzYqDrp2sMk/IRBY11c70RR2Bk4nouyvNo0m+Bjc0JMrRCbGGB91nqytWsqgDDvHQyj5tpa9g== 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=V3xvpgXL3JzDyQpgECVznAjjX/6ShU+KMkMg4v9Y8Mc=; b=lAI+tD8aExoDB/PIHLekjg8aMbMx6SxkWzkEy4JOispVaI9jfaS5g/kRF16dYSMDvwg+vGwj8ul7VlLbKJJwlksuXrbVwpugNAX17sFolNMaaawvU5PZANFpNcaKloaazZfSBWT8XPgGvYE0LHjIlIFrSC1K2r0i9JgKXJmJaNReh9HLQjxYP68N2Ehsd1ctpehfrFWLhppLw0ZWGT5gAwXwiruXZDftKbMQ546tK9Xgp+jQy+Tk2AjpJlKcJKFGHo01646ByjTVmlAsa9bpTDnOWhfqyf2zqoTkjoxOnCTE4cXFAqhqE3Vxi1B1qpvFkOFrVDA4Er9BzTLhCSRJMg== 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=V3xvpgXL3JzDyQpgECVznAjjX/6ShU+KMkMg4v9Y8Mc=; b=sdm5s1WLunB71vypXZPJfqu1lrZ9SnIPCs0xasg1Qb5oDgnan094/J4u02Ad820MJ1TYo47C+WJQG1fipk4CBNG/ccm686vLHCxxEHwbFJfjH5VrllFTETaeYOYRReRzkH72BijacJ5Zzvtzxb5JuJ5QGWhY8y5PEUu4mcApBYY= Received: from SA2PR11MB4922.namprd11.prod.outlook.com (2603:10b6:806:111::20) by SA2PR11MB4986.namprd11.prod.outlook.com (2603:10b6:806:114::13) 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 01:50:56 +0000 Received: from SA2PR11MB4922.namprd11.prod.outlook.com ([fe80::f541:5d11:56bd:a1fc]) by SA2PR11MB4922.namprd11.prod.outlook.com ([fe80::f541:5d11:56bd:a1fc%8]) with mapi id 15.20.4888.011; Fri, 14 Jan 2022 01:50:56 +0000 From: "Li Zhao (liz3)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] review of dao-projection -22 Thread-Index: AQHYB3I0RLVoN8WqFEOEiCVUH4Lia6xglxwQgAEjfSc= Date: Fri, 14 Jan 2022 01:50:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: 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: 1a73fce5-fb3c-4b52-9dce-08d9d7004e7b x-ms-traffictypediagnostic: SA2PR11MB4986:EE_ x-microsoft-antispam-prvs: 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: 0A9UaYxqnfd0LqoaP9iVfibByJ8xiuNbjWhDnOkZtTFl0EAfr6TcdQeOqAIMK53yutfr7TToB/OatnEfL2z9Cw1El9mUspZIY8eb8OTdhS9MG+JsvRruqbUwQzegqVqpvEcLew96kV1TIZzUA9+CmbQAW1XF+6mQ4RQC9u32hamy0rq+mL7evKja7iCdE4QytKHxjQCqd2vfJlpYkfidgaLDIJCbx8EKUY6L9tZUTudNvPITWF3yeBMABTBZbOi5EFoysdgmmniRlpQ0QyvSxkGbndQGudClk6qIWqkfBmvYPpUrhtm3xSkUj8+cNSLRS6MUdgpKyEDu8A/9iyHULohKX345iDJwDtx/jHid0Hd/t5AlAdoPU70HR7Qa8AUlhcrFUSc62DRWzVTSzPYZbO1jIE9r/cPLNYF9POYiWLTdkT2BWJkm2QDzW9sPh2MoDLwM6OW5xFk23xbnQlyXniHhieH4Se3HbGCPZ0WLDPuNEgNtfIrUN1693mdBsQpd+zlJGRUi+jrQBVZKVUIgTgAm0v+VRN+nYd+FnJtuAUOD/dC8/u5YNTI/aeiVWtOJ9YzDugzx6+jeZ+S4AqQHzCyGP2tRT98tHOinIPpuf/S25xMhLxyitkP008gsBD2Ee5XeQibyt6cf/fprOUtcN4fWoDLgfVBe/1z6luBbL9ZwWyZ/KOq0yuAzlXVHVep4dsvU4q6ezL5iHdIesIPp3HebbqoXu8Av+mHso22sxRVK2MmL/MTNvF3UHDW71rp/lSK4yvVImGAAJ+5jIQqLA9AYyKItjNuKr3ZIm97SNsjZo2syXOEu8TjRnxsux00IlmXFD9xpS4g6dilR78IHgb7X1ET6xjV9NBSVkGDzjMo= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA2PR11MB4922.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(66446008)(71200400001)(316002)(86362001)(122000001)(52536014)(66946007)(91956017)(66476007)(66556008)(76116006)(64756008)(38100700002)(5660300002)(966005)(83380400001)(6506007)(53546011)(508600001)(8936002)(66574015)(6916009)(7696005)(8676002)(186003)(2906002)(55016003)(38070700005)(9686003)(33656002)(166002)(88722004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?pbEGXxDPpSgU6/Dm58/LHwxefpWCZ3vYyCMH/v5ImuthT+Uh6ZNwvTLk?= =?Windows-1252?Q?VWkoVQ8v8R8kufGNdXcx6rzaKjdyahD/u898hY4wq/oID9LsqubcL9bP?= =?Windows-1252?Q?eUsqPv9JY67rdtokOHbVbQzvEQ8mjZFhAvOJjBZeLvio9hVYRadFS+7D?= =?Windows-1252?Q?d2jQDXoiWM4VE9djVt28rjsvSqKTB5umBTMh628wT5Ur9KU4PiUnybqr?= =?Windows-1252?Q?pvTJJKvAKus7tQHYfvR3RbJYic+zSPrA64GrYzXaEbN9Gl1AMSpLlCBk?= =?Windows-1252?Q?v69awt3LLv3udtOd2qPPznkDL6MTdwQ9r9XZjrjsYfckc0yjL+tpudHc?= =?Windows-1252?Q?Njao+98mnNtoRN0d8l7xQs+smEO9Wlehc0Cjk7KAvyyNTy/4i4Lizrw+?= =?Windows-1252?Q?2XliPBLPoucMBF4XLNZwH733CxtsOLKWdChtIwn+C3d89eBueE5fg5It?= =?Windows-1252?Q?mqM75JUkgv3xzTGhq46ZWei5AJnH5e0iMYTirIujJao67CWptnHVEzw4?= =?Windows-1252?Q?d1s7Rhk/Rvjp9HgopRsx9x3FBHi5R8xWK/m+RZ2nHJY9j3f8ZneGgjNn?= =?Windows-1252?Q?0ZAdZH8aD/+WilpopDayJMfFmN9cxIJu2q5emYo+2FHUEFkqCsEYnvNL?= =?Windows-1252?Q?ig6NULp46AwgX3tFY35IxmfBhHTHdEetggSc4fG6GgTtZDw2oatDAryM?= =?Windows-1252?Q?ioGadUSjnCh/Mn82inQf0S9L9PNQGt1oWGXBADaW82sBvmBHE30wsQTH?= =?Windows-1252?Q?MQef9kLwWVTyTEdwaboDyvbTcgneHf5WtCyI7qLwvLtMe8llaitz/GX0?= =?Windows-1252?Q?Lj/Vh5G5RcyJOEoj3WYSWyjMyfnBwHnCdFetrNsl6iLe7x5NNccsLrHt?= =?Windows-1252?Q?eRMjbtYLr0ifuCnUUGO2gYK/Q1Dkh/Pw7X5QtyPq8G4NB/0U/RhDix8C?= =?Windows-1252?Q?ooMBjvEd7++xGCYZKyqmSWNPfK7/H5wL+hwZbF3wamWOj8YSpWVfxCry?= =?Windows-1252?Q?4UAx7ioAQ2hsZK2sH4CqDjO7wUGhcJceL+ne22vTZfn3/bzHK8ieQMzZ?= =?Windows-1252?Q?n4wYjAs/RY4Xh/X1pIQGLOyNLzCQxsysu8XYnEBPiXWoMD5sKSC6Ubte?= =?Windows-1252?Q?tDBOQI8ZQGkwkGh+BPpxGe1vPwN3MilIVhN5ksJdt625Kfdy03RBI7nB?= =?Windows-1252?Q?Fb+jmBCLiNxTkf6QH/AVEDCtOrbGAPZoWn+2IY1npxqi6/+0jJNaNOfj?= =?Windows-1252?Q?TGIA+7sjhNMBTa6g0sj78rvu+EVcBKpfbc8Wzu/ujjmeXLZXwk3zirnX?= =?Windows-1252?Q?nIeu89XHOSH5n09S4RhElZ3bX9T9jzGEIGtb1jYO390rHi9GYgyKvBzf?= =?Windows-1252?Q?U1t3HJ+shHzJ6FxaA60yWhKGsuJrssInTqH5gdif/QEIQObcUZunTPd+?= =?Windows-1252?Q?ZS7w0urYBwQUfKj4fkzQ3xUlGkNR2LN/pyEI0K1rePaU8ItzDnd8vWbX?= =?Windows-1252?Q?AxkXpM4kq74PKMaYoE8Sf/e/QSqHm56ZnIwC0/rjJ3nr6v+gazF5QIZX?= =?Windows-1252?Q?7YziXatG/3FH3Jk0dcaoAXW7xw4QRVOQUnBCZLZfNdbg2whr2QBJryOI?= =?Windows-1252?Q?qNjp95WU/56laG7rSHAFxhH/foauCyLfcGKk5qGaVtdzdd+oPLq351hr?= =?Windows-1252?Q?5O7wvaSlJ0hONXjrF57HqH4rAWSCSgJupvFWuPL+92xerL7yWuGRW9lq?= =?Windows-1252?Q?FLLDCWgo3qednODzqmmt90ZWdeNlVLpI7N4mJLJ4?= Content-Type: multipart/alternative; boundary="_000_SA2PR11MB49223D05C658DEB5DD0971B98C549SA2PR11MB4922namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA2PR11MB4922.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1a73fce5-fb3c-4b52-9dce-08d9d7004e7b X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2022 01:50:56.4769 (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: PeWasPwKTtfqEtJKD8Wp1wkq4SzvoMkExXuFOdypOxw/yDV4NsgM1W08myPYGojm X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR11MB4986 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.19, xbe-rcd-004.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [Roll] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2022 01:51:07 -0000 --_000_SA2PR11MB49223D05C658DEB5DD0971B98C549SA2PR11MB4922namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Pascal, Please find my comments inline. Best regards, Li From: Roll on behalf of Pascal Thubert (pthubert) <= pthubert=3D40cisco.com@dmarc.ietf.org> Date: Friday, January 14, 2022 at 01:31 To: Routing Over Low power and Lossy networks Subject: Re: [Roll] review of dao-projection -22 Hello Li A great many thanks for your excellent review! Such are much needed at this= time. > [Li] -> Should it be ? > P-DAO 1 signals C=3D=3D>D=3D=3D>E-to-F,G > P-DAO 2 signals A=3D=3D>B=3D=3D>C-to-E,F,G [PT] correct, great catch! > [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 T= rack from egress node. Is PDR-ACK still needed? > In non-storing mode, No-Path P-DAO to ingress node is also en= ough. > But the PDR-ACK Status field makes sense. Is it possible to a= dd this field in No-Path P-DAO? [PT] The no path DAO flow along the reverse path and cleans it; so the end= result would be that the Track is terminated as you figured. So yes, it co= uld be possible to add a status to the no-path DAO but remember that it is = a normal DAO not a completion (IOW not an ack). How could we justify a stat= us in all DAOs? I=92m unclear why the async PDR ack is an issue. If the PDR= can not be served, the track ingress already needs to support a PDR ack th= at =94terminates=94 a Track. To clarify that sentence we can say: =93 The main Root MAY indicate to the Track Ingress that the Track was termi= nated before its time and to do so, it MUST uses an asynchronous PDR-ACK with = an negative status. =93 Should that be more than a MAY? >>>> [Li] Yes. It=92s more clear. So PDR-ACK is for original PDR. And for m= aintain or tear down case, Root should use No-Path P-DAO to terminate P-Rou= te. Correct? > [Li] -> Is it possible to remove the limitation? It=92s not flexible If = PDR can only carry one RTO. > For instance in figure 7, if node I requests P-Route to B&H t= ogether, 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 res= ponse with a special PDR-ACK Status. [PT] This was done in the interest to simplicity, and yes we can rediscuss= that. We=92d need to make decisions on partially successful use cases e.g.,: * What if there=92s a path to only a subset? Should the root form more = than one track? * Or deny with your special status but then what can the source do afte= r that? Try all combinations? * What is the best path to one target cannot reach all targets but a lo= wer quality path can? Should we use that one? * Maybe there could be one main target and additional desirable targets= ? In that case the Root could form the track and indicate which of the opti= onal targets are effectively reachable via the track to the main target. >>>> [Li] Maybe it depends on implement of PCE? I=92d like to keep the fle= xibility because there is a user case for street lighting. Some controllers= (Ingress nodes) need to light the street lighting linearly with low-latency= . > [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 tre= at 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 simplifi= cation. I=92m OK to add it back, but we still lake a good description of ho= w the node will know that the link is roughly symmetrical. >>>> [Li] Some physical layer measurements such as RSSI/LQI have forward an= d reverse direction. Can it indicate symmetrical? In layer 3, receiving DIO/NS messages from each other ind= icate symmetrical? > [Li] -> Confuse with this claim. Is it a MUST NOT if root wants to send n= otification to the requesting node when those changes happen. [PT] There=92s no protocol element to =93send notification to the requestin= g node when those changes happen=94. So it=92s hard to say that the root MU= ST NOT do something that it cannot do. Reworded to =93 Note that there is no protocol element to notify to the requesting Tr= ack Ingress when changes happen deeper down the Track, so they are transp= arent to the Track Ingress. If the main Root cannot maintain an expected se= rvice level, then it needs to tear down the Track completely. =93 > [Li] -> Can you add some description for the collision case? E.g., node t= rusts itself than Root. [PT] I reworded to =93 = In a particular deployment where PDR are not used, a portion of the namespace can be administrati= vely delegated to the main Root, meaning that the main Root is authoritativ= e for assigning the TrackIDs for the Tracks it creates.. =93 [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 f= rom DAO. [PT] Done; I added a section for the P-DAO-ACK > [Li] -> Profile 0 is the Legacy support of [RPL] Non-Storing Mode. I= =92m confuse about =93this enables to use Storing Mode to reduce the size o= f the Source Route Header in the most common LLN deployments.=94 [PT] I really meant Profile 1 enables=85 Changing that. I guess that=92s it ! I submitted -23 with this, please have a look at https://www.ietf.org/rfcdi= ff?url2=3Ddraft-ietf-roll-dao-projection-23 Again many thanks! Pascal From: Roll On Behalf Of Li Zhao (liz3) Sent: mercredi 12 janvier 2022 10:51 To: Routing Over Low power and Lossy networks 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=3D=3D>D=3D=3D>E-to-F,G P-DAO 2 signals A=3D=3D>B=3D=3D>C-to-C,F,G [Li] -> Should it be ? P-DAO 1 signals C=3D=3D>D=3D=3D>E-to-F,G P-DAO 2 signals A=3D=3D>B=3D=3D>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 REC= OMMENDED that the nodes involved in a Track =3D=3D=3Dmantain=3D=3D=3D multi= ple 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 use= s diverse source route paths to retry similar messages =3D=3D=3Dot=3D=3D=3D= the nodes in the Track.=B6 [Li] -> Typo for =93mantain=94 and =93ot=94? 4.1.6. This specification defines a new flag "Projected Routes Support" (D). The DODAG Configuration option is copied unmodified from parents to childre= n. =3D=3D=3D=3Dxref target=3D'RFC6550'/>=3D=3D=3D=3D states that: [Li] -> Typo for =93xref target=3D'RFC6550'/>=94. Why is flag named as =93= D=94? There is no D in "Projected Routes Support"=85 5.1 The Root may use an asynchronous PDR-ACK with an negative status to ind= icate 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 egre= ss 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=92s not flexible If PD= R 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 s= pecial 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, i= f 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 hap= pen. [Li] -> Confuse with this claim. Is it a MUST NOT if root wants to send not= ification 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 i= t creates without collision. [Li] -> Can you add some description for the collision case? E.g., node tru= sts itself than Root. 6.4.1 In both cases the Track Ingress is the owner of the Track, and it gen= erates 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 f= rom 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 Rou= te Header in the most common LLN deployments. [Li] -> Profile 0 is the Legacy support of [RPL] Non-Storing Mode. I= =92m confuse about =93this enables to use Storing Mode to reduce the size o= f the Source Route Header in the most common LLN deployments.=94 Best regards, Li --_000_SA2PR11MB49223D05C658DEB5DD0971B98C549SA2PR11MB4922namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hell= o Pascal,

 

Please find my comm= ents inline.

 

Best= regards,

Li

 

From: Roll= <roll-bounces@ietf.org> on behalf of Pascal Thubert (pthubert) <p= thubert=3D40cisco.com@dmarc.ietf.org>
Date: Friday, January 14, 2022 at 01:31
To: Routing Over Low power and Lossy networks <roll@ietf.org><= br> Subject: Re: [Roll] review of dao-projection -22

Hell= o Li

&nbs= p;

A gr= eat many thanks for your excellent review! Such are much needed at this tim= e.

&nbs= p;

>= [Li] ->  Should it be ?

>=             P-DAO 1= signals C=3D=3D>D=3D=3D>E-to-F,G

>=             P-DAO 2= signals A=3D=3D>B=3D=3D>C-to-E,F,G

[PT]= correct, great catch!

&nbs= p;

&nbs= p;

>= [Li] -> What's the difference between negative status PDR-ACK and No-Pa= th P-DAO in section 6.5?  And when to use asynchronous PDR-ACK?

>=             In stor= ing 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-P= ath P-DAO?

&nbs= p;

[PT]=  The no path DAO flow along the reverse path and cleans it; so the en= d result would be that the Track is terminated as you figured. So yes, it c= ould be possible to add a status to the no-path DAO but remember that it is a normal DAO not a completion (IOW not an ack)= . How could we justify a status in all DAOs? I=92m unclear why the async PD= R ack is an issue. If the PDR can not be served, the track ingress already = needs to support a PDR ack that =94terminates=94 a Track.

&nbs= p;

To c= larify that sentence we can say:

=93<= o:p>

&nbs= p;  The main Root MAY indicate to the Track Ingress that the Track was= terminated

&nbs= p;  before its time and to do so, it MUST uses an asynchronous PDR-ACK= with an

&nbs= p;  negative status.

=93<= o:p>

Shou= ld that be more than a MAY?

 

>= >>> [Li] Yes. It=92s more clear. So PDR-ACK is for original PDR. A= nd for maintain or tear down case, Root should use No-Path P-DAO to ter= minate P-Route. Correct?

 

 

>= [Li] -> Is it possible to remove the limitation?  It=92s not flexi= ble If PDR can only carry one RTO.

>=             For ins= tance 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 Trac= ks I->A->B and I->F->G->H.

>=              If= Root cannot computer one Track to multiple RTO, it can response with a spe= cial PDR-ACK Status.

&nbs= p;

[PT]=  This was done in the interest to simplicity, and yes we can rediscus= s that.

We= =92d need to make decisions on partially successful use cases e.g.,:

  • What if there=92s a p= ath to only a subset? Should the root form more than one track?
  • Or deny with your = special status but then what can the source do after that? Try all combinat= ions?
  • What is the best path to one target cannot reach all targets but a l= ower quality path can? Should we use that one?
  • = Maybe there could be one ma= in target and additional desirable targets? In that case the Root could for= m the track and indicate which of the optional targets are effectively reachable via the track to the main t= arget.

&nbs= p;

>= >>> [Li] Maybe it depends on implement of PCE?  I=92d like to= keep the flexibility because there is a user case for street lighting. Som= e controllers(Ingress nodes) need to light the street lighting linearly with low-latency.

&nbs= p;

 

> [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.

&nbs= p;

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

&nbs= p;

>= >>> [Li] Some physical layer measurements such as RSSI/LQI have fo= rward and reverse direction. Can it indicate symmetrical?

&nbs= p;            &= nbsp;    In layer 3, receiving DIO/NS messages from each oth= er indicate symmetrical?<= span lang=3D"EN-US" style=3D"font-size:11.0pt">

&nbs= p;

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

&nbs= p;

[PT]= There=92s no protocol element to =93send notification to the = requesting node when those changes happen=94. So it=92s hard to say that th= e root MUST NOT do something that it cannot do. Reworded to

&nbs= p;

=93<= o:p>

&nbs= p;     Note that there is no protocol element to notify= to the requesting Track

&nbs= p;     Ingress when changes happen deeper down the= Track, so they are transparent

&nbs= p;     to the Track Ingress. If the main Root cannot ma= intain an expected service

&nbs= p;     level, then it needs to tear down the Track comp= letely.

=93<= o:p>

 

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

 

[PT]= I reworded to

=93<= o:p>

&nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     In a particular deployment<= /p>

&nbs= p;    where PDR are not used, a portion of the namespace can= be administratively

&nbs= p;    delegated to the main Root, meaning that the main Root= is authoritative for

&nbs= p;    assigning the TrackIDs for the Tracks it creates..

=93<= o:p>

&nbs= p;

[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-AC= K from DAO-ACK as P-DAO from DAO.

&nbs= p;

[PT]= Done; I added a section for the P-DAO-ACK

&nbs= p;

>= [Li] -> Profile 0 is the Leg= acy support of [RPL] Non-Storing Mode. I=92m confuse about =93this enables to use Storing Mode to reduce the size= of the Source Route Header in the most common LLN deployments.=94

&nbs= p;

[PT]= I really meant Profile 1 enables=85 Changing that.

&nbs= p;

I guess= that=92s it !<= o:p>

 <= /span>

I su= bmitted -23 with this, please have a look at https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-dao-projection-2= 3

&nbs= p;

Agai= n many thanks!

&nbs= p;

Pasc= al

&nbs= p;

F= rom: Roll <ro= ll-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><= br> Subject: [Roll] review of dao-projection -22

&nbs= p;

Hell= o Authors,

&nbs= p;

Than= ks for your great effort. The PDAO draft looks more clear and detailed. Fol= lowing is some concern:

&nbs= p;

3.5.= 2 Using Non-Storing Mode joining Tracks

P-DAO 1 signals C=3D=3D>D=3D=3D>E-to-F,G

P-DAO 2 signals A=3D=3D>B=3D=3D>C-to-C,F,G

&nbs= p;

&nbs= p;  [Li] ->  Should it be ?

P-DAO 1 signals C=3D=3D>D=3D=3D>E-to-F,G

P-DAO 2 signals A=3D=3D>B=3D=3D>C-to-E,F,G

&nbs= p;

&nbs= p;   Otherwise RIBs in A cannot include destination to E.

&nbs= p;

4.1.= Extending RFC 6550

To e= nsure that the PDR and P-DAO messages can flow at most times, it is RECOMME= NDED that the nodes involved in a Track =3D=3D=3Dmantain=3D=3D=3D multiple = parents in the Main DODAG, advertise them all to the Root, and use them in turn to retry similar packets. It is also RECOMMENDE= D that the Root uses diverse source route paths to retry similar messages = =3D=3D=3Dot=3D=3D=3D the nodes in the Track.=B6

&nbs= p;  

[Li]= -> Typo for =93mantain=94 and =93ot=94?

&nbs= p;

4.1.= 6.

This= specification defines a new flag "Projected Routes Support" (D).

The = DODAG Configuration option is copied unmodified from parents to children. = =3D=3D=3D=3Dxref target=3D'RFC6550'/>=3D=3D=3D=3D  states that:

&nbs= p;

[Li]= -> Typo for =93xref target=3D'RFC6550'/>=94.  Why is flag named= as =93D=94? There is no D in "Projected Routes Support"=85<= /o:p>

&nbs= p;

&nbs= p;

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

&nbs= p;

[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 f= ield in No-Path P-DAO?

&nbs= p;

&nbs= p;

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

&nbs= p;

[Li]= -> Is it possible to remove the limitation?  It=92s not flexible I= f PDR can only carry one RTO.

For instance in figure 7, if node I requests P-Rou= te to B&H together, Root can only push one Track I->A->B->H. O= therwise, 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.

&nbs= p;

&nbs= p;

5.4 only the router with the lowest In= terface ID in its registered address needs report the SIO, and the Root wil= l assume symmetry.

 

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

&nbs= p;

&nbs= p;

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 wh= en those changes happen.

 

 

 

6.3 In a particular deployment where P= DR 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 descriptio= n for the collision case? E.g., node trusts itself than Root.

 

&nbs= p;

6.4.= 1 In both cases the Track Ingress is the owner of the Track, and it generat= es the P-DAO-ACK when the installation is successful

&nbs= p;

[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-AC= K from DAO-ACK as P-DAO from DAO.

&nbs= p;

&nbs= p;

8 Pr= ofiles 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 H= eader in the most common LLN deployments.

&nbs= p;

[Li]= -> Profile 0 is the Legacy support of [RPL] Non-Storing Mode. I=92m confuse about =93this enables to use Storing Mode to reduce th= e size of the Source Route Header in the most common LLN deployments.=94

&nbs= p;

&nbs= p;

&nbs= p;

Best= regards,

Li

&nbs= p;

&nbs= p;

&nbs= p;

&nbs= p;

&nbs= p;

&nbs= p;

&nbs= p;

&nbs= p;

&nbs= p;

&nbs= p;

--_000_SA2PR11MB49223D05C658DEB5DD0971B98C549SA2PR11MB4922namp_-- From nobody Fri Jan 14 00:18:42 2022 Return-Path: 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 833FE3A1E5A for ; Fri, 14 Jan 2022 00:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.585 X-Spam-Level: X-Spam-Status: No, score=-9.585 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_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=a+yHeLOg; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=wJN71sdC 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 qFkz5iuITFIm for ; Fri, 14 Jan 2022 00:18:35 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77BAA3A1E58 for ; Fri, 14 Jan 2022 00:18:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=63923; q=dns/txt; s=iport; t=1642148315; x=1643357915; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Cb5RENwIX322ct6PV3nYBYefVI2yn+II6txOuA7+wWQ=; b=a+yHeLOg/rhlMInKEvwOm54+r6oFm1bTZZY4KUetojHvX1W5jKbMp8x+ MyYrZxPNm2jjzXdiLG+M2HutVF7K63y8GL69s24wt9lUMfCY9hT0NjbKY GJfV006QyK3016RF2/0r3TwD5XF8qsj0bOoRWOYsbeDv0MFxM9XBJL8Sk 0=; IronPort-PHdr: =?us-ascii?q?A9a23=3A5G6EqR8+rq/6j/9uWCXoyV9kXcBvk7n3PwtA7?= =?us-ascii?q?J0hhvoOd6m45J3tMQTZ4ukll17GW4jXqpcmw+rbuqztQyoMtJCGtn1RfJlFT?= =?us-ascii?q?RRQj8IQkkQpC9KEDkuuKvnsYmQ6Ec1OWUUj8Wu8NB1eGd31YBvZpXjhhQM?= =?us-ascii?q?=3D?= IronPort-Data: =?us-ascii?q?A9a23=3Av7LifKxCGH3OoxRNZch6t+clxCrEfRIJ4+Muj?= =?us-ascii?q?C+fZmUNrF6WrkVVy2IYXjiEb/eOMDShfYgjbYS+8xgPuJLSyYJnGVFupFhgH?= =?us-ascii?q?ilAwSbn6Xt1DatR0xt/paQvdWo/hyklQoSGfJBcokP0/E/3aOC49CUkj8lke?= =?us-ascii?q?5KlYAL6EnEpLeNbYH9JZSJLw4bVs6Yw6TSLK1rlVeDa+6UzDGSYNwtcaQr43?= =?us-ascii?q?U4sRCRH55wesBtA1rA3iGsiUFX2zxH5B7pHTU29wueRf2VaIgK6b76rILCR5?= =?us-ascii?q?GjV+VImDcmo1+e9eUwRSbmUNg+L4pZUc/H92V4Z+WpjieBiaKd0hUR/011lm?= =?us-ascii?q?/hp1NVQv5GqVS8iP7bHn6IWVBww/yRWbPAZqeGffyDi2SCU5wicG5f2+N10C?= =?us-ascii?q?0UyFYwV5ugxBntBncH0ghhlggurnem6xvewTfNhw5VlJ8jwN4RZsXZlpQw1x?= =?us-ascii?q?M0OGfjrK5gmL/cCgV/cXvxzIMs=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AWsiP1KGMRJyqHxm4pLqFRJHXdLJyesId70?= =?us-ascii?q?hD6qkvc31om52j+fxGws516fatskdvZJhSo6H/BEDgewKTyXcR2+ks1NiZLX?= =?us-ascii?q?HbUOXDFvAY0WKP+UyEJ8S6zJ8g6U4CSdk+NDSTNykBsS+S2mDReLxMrKjlgc?= =?us-ascii?q?KVbKXlvgpQpGpRGsZdBnJCe3+m+zpNNW977PQCZf6hz/sCgwDlVWUcb8y9CH?= =?us-ascii?q?VAdfPEvcf3mJXvZgNDLwI76SGV5AnYqILSIly95FMzQjlPybAt/SzuiAri/J?= =?us-ascii?q?iutPm911v1y3LT1ZJLg9Hso+EzR/Bky/JlaAkEuDzYILiJaIfy+wzdZ9vfrm?= =?us-ascii?q?rCpeO85ivI+f4Dsk85MFvF+ScFkDOQoQrGo0WSuWNwx0GT+vAQgFkBepd8bU?= =?us-ascii?q?UzSGqC16NohqAO7Itbm22erJZZFhXGgWD04MXJTQhjkg6urWMlivN7tQ0TbW?= =?us-ascii?q?IyUs4bkWUkxjIeLH7AJlOM1Kk3VO11SM3M7vdfdl2XK3jfo2l02dSpGnA+BA?= =?us-ascii?q?2PTEQOstGcl2E+pgE382IIgMgE2nsQ/pM0TJdJo+zCL6RzjblLCssbd7h0Cu?= =?us-ascii?q?sNSda+TmbNXRXPOmSPJkmPLtBKB1vd75rspLkl7uCjf5IFiJM0hZTaSVtd8X?= =?us-ascii?q?U/fkr/YPf+lKGjMiq9CVlVcQ6dv/221qIJzIEUHoCbQxFrYGpe5/ednw=3D?= =?us-ascii?q?=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C7BgBdMeFh/5FdJa1aHgErCwYMIoF?= =?us-ascii?q?ZgSEBMFYHd1o3MYgMAgOFOYUOXYIlA4ETjyGKaoEuFIERA1QLAQEBDQEBNwo?= =?us-ascii?q?EAQGFBQKDSgIlNAkOAQIEAQEBEgEBBQEBAQIBBgSBCROFOwEEKA2GQgEBAQE?= =?us-ascii?q?CAQwGCA0GEwEBOAQLAgEIEQMBAQEhAQYHMhQJCAIEEwgagmOCDlcDDSEBDqA?= =?us-ascii?q?KAYE6AoofeIEBMoEBgggBAQYEBIE6AoNPGII2AwaBOoMOgn5USocJJxyBSUS?= =?us-ascii?q?BFAFDVYERSjc+gmMCAhiBKAQcHgYHCYMZgi6QHwEQFUYOYA0lEQ4CIAIrAw0?= =?us-ascii?q?eCBUBNw8JAQISBw8fCwuSNI0HgXCLfpJaCoNEiSKWSRWDcIwMl3KWQaEoCA8?= =?us-ascii?q?LC4ReAgQCBAUCDgEBBoFhO4FZcBWDJFEZD4Vrgl+JR4UUhUp0AjYCBgsBAQM?= =?us-ascii?q?JjWcHgj8BAQ?= X-IronPort-AV: E=Sophos;i="5.88,288,1635206400"; d="scan'208,217";a="957960605" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Jan 2022 08:18:30 +0000 Received: from mail.cisco.com (xbe-rcd-007.cisco.com [173.37.102.22]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 20E8IUxo029182 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for ; Fri, 14 Jan 2022 08:18:30 GMT Received: from xfe-aln-002.cisco.com (173.37.135.122) 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.986.14; Fri, 14 Jan 2022 02:18:29 -0600 Received: from xfe-rcd-001.cisco.com (173.37.227.249) by xfe-aln-002.cisco.com (173.37.135.122) 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 02:18:29 -0600 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-001.cisco.com (173.37.227.249) 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 02:18:29 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UY/0zZz831o36f2lb1jH1owr5J+tyfnq6CpQ2FLjihv8cY+rsal7m/lF4npQlcItrQrMhrT9P1k/ed6RQ6xhk1DMd5bRst9mf286jWNzR9e57M1vIs/dofMPtKjpPOiyt//HCJg70+E5VSnCYu14y/HjZujBoJlDQUFGayIGAwHdvoxZ+lnINBjFJREeBW6aVon3x0miqO72eLnoc8eiEMTPU1fTnIveeoknaVkx1OM/QSCcD9mbfXu4zvO3yy/yyOiYkYPyP8F2x0m4pCeslsJzAg0+Niexjk0lTJNOTeXxJWVRbQCWq71zhyu5elmtmBy470GUMXN1bbLsp2Rhzg== 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=qm70PPe7n+jFXZtObbU+oBNX91wFHn6gUhlq7Y7zwYU=; b=G0AbnwMKBGHp/PH8rSFvDk6GDR7InFXfb0p7wMZcCthOG98s3KqAo3aerCFJJQ3TIfp9mdPLftt4KHEG+Lzf8KCbgDfo4MEInoTGpo2va1ksQRDd8V/ds5xyuzpov/GO7ejUFkTOXGc9D5BuIEAvYx7Geg8eY8NlB1sSIPkcrgobMeN9g0U1APxChFGfyWHxVTMQqzaoS05EYnHhpYxEBj1dWZFMo/2X7h8iEB91vwyDPh899zviApam0lIfQmMYoWuFor/VXVfJW9/2Z3VAs/d7moUx3fzV5Yc3UrOVGG/y8lpf2h7dsgCbA4KbSRQsug4nkRh7igJK93DrAqoWXA== 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=qm70PPe7n+jFXZtObbU+oBNX91wFHn6gUhlq7Y7zwYU=; b=wJN71sdCx/h7vA3aNHwq0vQPsiz55fAK/m7nzkpjcj0ykqoji3deVUaQkdQPCCjt1hiHGnB5e2TKH3N+K6njCwn+4TckthKVVZR3aAC/RhL+KdnlGyV5TmKo4WlstMF+80NIOLYqnlwLxS3f6gNU1Vq/jZEhCg+XdQ2bA5i9BHo= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MWHPR1101MB2126.namprd11.prod.outlook.com (2603:10b6:301:50::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4867.11; Fri, 14 Jan 2022 08:18: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 08:18:27 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] review of dao-projection -22 Thread-Index: AQHYB3I0RLVoN8WqFEOEiCVUH4Lia6xglxwQgAEjfSeAAGmRUA== Date: Fri, 14 Jan 2022 08:18:07 +0000 Deferred-Delivery: Fri, 14 Jan 2022 08:17:35 +0000 Message-ID: References: In-Reply-To: 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: 17d9beb8-1bb7-4ad6-06a4-08d9d73670f2 x-ms-traffictypediagnostic: MWHPR1101MB2126:EE_ x-microsoft-antispam-prvs: 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: H4p5lWNxVdM/rLFsVrgv2VvCY2z1oSfaTjbo8S7fJuy4zykFLcqoZ7crdJc0eQXaSMGcxnXuVqaiI2RkiXymWYOH2MduMMZPmMprINo4kv/yaQDoMYzsVoATr64JyY0eIeMLQDL95EPU4KfXxAd4R9IV3OWHNn8rASKh7hsnHRrqug2DvX8CJgQfB6N6dcEXequOcZ3Tzc6xNGlkyzQ11vwyIs4Nukn//zx1tZQETEDF4Jy9gMQQ9onenmyl12F+9f/B8Ol4Sw0nmNhb3QF21Vg9EmcTUjh/ogHSj69Nj1ThUk7lIO+hPXfqUR7QwFX14wFzwelsWeWuihPNqsurbTtMv93YEYj+Qx9Os0HGTiYncHRSof7cv3XUsddPW5yAgppQBUvOPzklUsGYHmlSH3AUEAbe8yOihb2ocYspOlP3SLE3vJzmaiGsPK0Wp9HVA4xM9NOnrjnhLXKzbzq273++uyL7vGv7lsIT1DSdBLawayt6NkCk1rLHUVDvFNVmibzXNJGZmDnk6oRkddyKAe8Naa9BWES2ugOQDDQtQMcaFeVIRefWswdXrw/dQbKEspw7pv/iqpj4q0jE2k23ZkrtywtbfpTxKbwSkWcUC5VPxQSYKH7kxWR0z+ZcmCHvT7f3BaznesnWmGWzN97n2qG62WZ60qcIOz0ybNp5MvDEGOymvUhvi07YoS9vAJRX5qoI82cSTEFDMAXQ0UUYQuSFF1O9g8U03N/7dgBZAHTcMbj2h4qL33Dx0ZL816s5eOXjb7MDdati2CWYIeMFTG+UVHYWxGpEDfhfHohsaSms/YmdjNR+RMYCZIqRwaXwxvXZxWZEQK6r92PL2ZRI9w== 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)(52536014)(9686003)(66574015)(7696005)(55016003)(38070700005)(86362001)(66946007)(966005)(166002)(26005)(33656002)(508600001)(83380400001)(2906002)(76116006)(30864003)(5660300002)(66446008)(66476007)(8676002)(122000001)(66556008)(316002)(6666004)(6916009)(53546011)(186003)(6506007)(8936002)(71200400001)(38100700002)(64756008)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?0k4jWJomb5pJyVMDUVeKZNrDaC1nFGVepNey6qyA9/hBqsQ+8sVMD615aB?= =?iso-8859-1?Q?hEuJZvORhOnu1E7a1UVU2D1CpIau4FTrSVyIe2i+sYXgib/ug3nlwlsZGs?= =?iso-8859-1?Q?mKU1E6Ins+jOq7VCMB/2LZ4CQ6C1tijsLGDS4GvIwIk+863zLcftZofAFy?= =?iso-8859-1?Q?gYkD1OXkMl1RfNpz+OKmz8tthqgA5nTle5TpQF8OniPWyoSJI+SriGHHLl?= =?iso-8859-1?Q?RBm7a6IqDdjJ7DHTzQRNMIqOrmxG+vN2y6/Agvh2N/n0lhR/XeCcV8qz91?= =?iso-8859-1?Q?NlA6A5EXKr+RTQL30rVBW4aFB9ZYV3JKRezS9arYu4/3vmTakX3zW7gQmQ?= =?iso-8859-1?Q?WGqAAnJsHTBiFPGfO7DhYd1lKu4TuiPumSPS03f+GZGlrc1Suf8rYkBqFW?= =?iso-8859-1?Q?4C70wo1na5U7tBgtK+jHTP3VkzAf/aQvSLVs4uqZf7ysqi/KPA8/bynlXy?= =?iso-8859-1?Q?fu+ysZJyqWYPNUlFQ+Xr+4Uz1+VsdA3tREtVmMy2297yvrFXCsOZWyENSF?= =?iso-8859-1?Q?9DqZrK1bk4OQOGxCGM87gOAYVB3cuy9oLcfH8AvGBSUY0rvq7bVr1iovBW?= =?iso-8859-1?Q?ujkpzayCZ4ZUUgEjUwwvykV+ls2Hkb9sUQzQ9Hv57mNJsg24IKXvWzhyHM?= =?iso-8859-1?Q?yHh0uA1f3RgTfSTV9uR2v9kgzFrcaz6QFI+ugy0VaxOrcCfbZjuLdomZ7Q?= =?iso-8859-1?Q?TbDyGmbTbfh+LdkxLDQJ56Bnb2IUY+m5pHuP6JjSFZw37O3iIyUvbul5wp?= =?iso-8859-1?Q?jDJAoU2lGx7+eyay8bW+1P76ggbI09A8GnXA7vkJpAf+2zpXp8+YgZY7/7?= =?iso-8859-1?Q?Ew9Q3BWROgZuAO/FblZWlgHXf8IXtFoBJRjK7Lx/1OtsqP52Pw/2/9wYuq?= =?iso-8859-1?Q?x2pw92857SN3Uwd/KLG9FkkJMUOK4qyWESpOf/vKxGpojrBkBtwZQl9+6L?= =?iso-8859-1?Q?Te5lxlNWbd/HCIFjNsaWno/tnuSo0LoUp/KqFnj47wHxZaYcKJd/44ZzFE?= =?iso-8859-1?Q?e3kozGjs/Vq8FXRp1hIFsZuCbCt602HJrBJ7cg3OZiw+r6rh0duixWJ0y3?= =?iso-8859-1?Q?e+Y5mNMsu+IONHxDnydxoUhitids2LYBtgXsczfZpWiBekBRuYaiWhL8kY?= =?iso-8859-1?Q?JaLuIaP5Vmfhe84I/0uZ560LsqIm31kp+7lK5eCWmFLUj9Fl/ccoI12vsP?= =?iso-8859-1?Q?q+HkXbfv9JBRfcLsKWWDjh646MqeXIeaurMJMdJfk093SnCVgiH3ayh0kg?= =?iso-8859-1?Q?jDKIPt4WSZ6CI93xKbpPgG71BZHJQGbxZa6FRl1xk/lmrhSRinEUx6K4/L?= =?iso-8859-1?Q?kBFWHzf7qt46leCJODAOFoie6eGQJF2jrLn0RFNpWNi7HD8nohkHa2Z6GR?= =?iso-8859-1?Q?tpoOuZcDCi7lx1UM+wOxoeiSsaYPmHT7yk0qjlQAumX/sRx4PDivfw5SGr?= =?iso-8859-1?Q?X3bXFOplflOoUkV3bRAde7heKAkhBaiaW8w46yN7nYYpnjPmHBRz6FcMMI?= =?iso-8859-1?Q?8npGpJ2K4a2kLydP2z2ld03TPYqeDeDCmwwYBiEB4SLcCW1jXRdMMsmCMb?= =?iso-8859-1?Q?8t8Kg+5VI0G4qOH7gUaRsbSKB48dzkRbNu9n8LGeztN8yqlaiZaC0f7I79?= =?iso-8859-1?Q?Rjxa8o88iIE9Bp3+BL9xCSFpAuUuU6wTqqe9q4aC/23thFWjMVAoqxGm4A?= =?iso-8859-1?Q?xjwgmRP701QhCf1HrTc=3D?= Content-Type: multipart/alternative; boundary="_000_CO1PR11MB48816A433456154415039FCCD8549CO1PR11MB4881namp_" 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: 17d9beb8-1bb7-4ad6-06a4-08d9d73670f2 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2022 08:18:27.1501 (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: KG462fJ5Jx3XEi+UjfsqYSEHAzJ5vNi3e1OXDxK9be4PrvrMkows8lQ97vsn2mkyqCY7Dw8s+YFKobd6/+zrzg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1101MB2126 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.22, xbe-rcd-007.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [Roll] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2022 08:18:41 -0000 --_000_CO1PR11MB48816A433456154415039FCCD8549CO1PR11MB4881namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Li: > [Li] Yes. It's more clear. So PDR-ACK is for original PDR. And for mainta= in or tear down case, Root should use No-Path P-DAO to terminate P-Route. C= orrect? [PT] yes: the NP DAO cleans the state in the network. It removes the Track.= The PDR ACK signals to the Ingress that it is being done and why. Maybe w= e need to explain that those 2 may be asynchronous to one another. I agree = with you that we can probably think this through a little more. E.g., shoul= d the PDR ACK trigger a DCO (RFC 9009) ? Could the PDR ack signal status th= at is not the death of the Track but other stuff? > [Li] Maybe it depends on implement of PCE? I'd like to keep the flexibil= ity because there is a user case for street lighting. Some controllers(Ingr= ess nodes) need to light the street lighting linearly with low-latency. [PT] sure, at the expense of complexity in signaling and processing in the = nodes. We need to be specific on the scenarios and status codes. The PDR f= orms a single Track since the TrackID is provided. Since signaling is invol= ved we need a story for all those questions: * What if there's a path to only a subset? Should the root form more th= an one track? * Or deny with your special status but then what can the source do afte= r that? Try all combinations? * What is the best path to one target cannot reach all targets but a lo= wer quality path can? Should we use that one? * Maybe there could be one main target and additional desirable targets= ? In that case the Root could form the track and indicate which of the opti= onal targets are effectively reachable via the track to the main target. > [Li] Some physical layer measurements such as RSSI/LQI have forward and r= everse direction. Can it indicate symmetrical? In layer 3, receiving DIO/NS messages from each other ind= icate symmetrical There's a nuance between bidir and symmetrical. Maybe the ping works but t= he link quality is very different in both directions. If so the Rank increm= ent computation would differ widely and we would need both sides. We need separate threads to solve these issues. Let me start them Keep safe! Pascal Pascal From: Roll On Behalf Of Li Zhao (liz3) Sent: vendredi 14 janvier 2022 2:51 To: Routing Over Low power and Lossy networks Subject: Re: [Roll] review of dao-projection -22 Hello Pascal, Please find my comments inline. Best regards, Li From: Roll > on behalf = of Pascal Thubert (pthubert) > Date: Friday, January 14, 2022 at 01:31 To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] review of dao-projection -22 Hello Li A great many thanks for your excellent review! Such are much needed at this= time. > [Li] -> Should it be ? > P-DAO 1 signals C=3D=3D>D=3D=3D>E-to-F,G > P-DAO 2 signals A=3D=3D>B=3D=3D>C-to-E,F,G [PT] correct, great catch! > [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 T= rack from egress node. Is PDR-ACK still needed? > In non-storing mode, No-Path P-DAO to ingress node is also en= ough. > But the PDR-ACK Status field makes sense. Is it possible to a= dd this field in No-Path P-DAO? [PT] The no path DAO flow along the reverse path and cleans it; so the end= result would be that the Track is terminated as you figured. So yes, it co= uld be possible to add a status to the no-path DAO but remember that it is = a normal DAO not a completion (IOW not an ack). How could we justify a stat= us in all DAOs? I'm unclear why the async PDR ack is an issue. If the PDR c= an not be served, the track ingress already needs to support a PDR ack that= "terminates" a Track. To clarify that sentence we can say: " The main Root MAY indicate to the Track Ingress that the Track was termi= nated before its time and to do so, it MUST uses an asynchronous PDR-ACK with = an negative status. " Should that be more than a MAY? >>>> [Li] Yes. It's more clear. So PDR-ACK is for original PDR. And for mai= ntain or tear down case, Root should use No-Path P-DAO to terminate P-Route= . Correct? > [Li] -> Is it possible to remove the limitation? It's not flexible If PD= R can only carry one RTO. > For instance in figure 7, if node I requests P-Route to B&H t= ogether, 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 res= ponse with a special PDR-ACK Status. [PT] This was done in the interest to simplicity, and yes we can rediscuss= that. We'd need to make decisions on partially successful use cases e.g.,: * What if there's a path to only a subset? Should the root form more th= an one track? * Or deny with your special status but then what can the source do afte= r that? Try all combinations? * What is the best path to one target cannot reach all targets but a lo= wer quality path can? Should we use that one? * Maybe there could be one main target and additional desirable targets= ? In that case the Root could form the track and indicate which of the opti= onal targets are effectively reachable via the track to the main target. >>>> [Li] Maybe it depends on implement of PCE? I'd like to keep the flexi= bility because there is a user case for street lighting. Some controllers(I= ngress nodes) need to light the street lighting linearly with low-latency. > [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 tre= at 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 simplifi= cation. 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 an= d reverse direction. Can it indicate symmetrical? In layer 3, receiving DIO/NS messages from each other ind= icate symmetrical? > [Li] -> Confuse with this claim. Is it a MUST NOT if root wants to send n= otification to the requesting node when those changes happen. [PT] There's no protocol element to "send notification to the requesting no= de when those changes happen". So it's hard to say that the root MUST NOT d= o something that it cannot do. Reworded to " Note that there is no protocol element to notify to the requesting Tr= ack Ingress when changes happen deeper down the Track, so they are transp= arent to the Track Ingress. If the main Root cannot maintain an expected se= rvice level, then it needs to tear down the Track completely. " > [Li] -> Can you add some description for the collision case? E.g., node t= rusts itself than Root. [PT] I reworded to " = In a particular deployment where PDR are not used, a portion of the namespace can be administrati= vely delegated to the main Root, meaning that the main Root is authoritativ= e for assigning the TrackIDs for the Tracks it creates.. " [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 f= rom DAO. [PT] Done; I added a section for the P-DAO-ACK > [Li] -> Profile 0 is the Legacy support of [RPL] Non-Storing Mode. I= 'm confuse about "this enables to use Storing Mode to reduce the size of th= e Source Route Header in the most common LLN deployments." [PT] I really meant Profile 1 enables... Changing that. I guess that's it ! I submitted -23 with this, please have a look at https://www.ietf.org/rfcdi= ff?url2=3Ddraft-ietf-roll-dao-projection-23 Again many thanks! Pascal From: Roll > On Behalf = Of Li Zhao (liz3) Sent: mercredi 12 janvier 2022 10:51 To: Routing Over Low power and Lossy networks > 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=3D=3D>D=3D=3D>E-to-F,G P-DAO 2 signals A=3D=3D>B=3D=3D>C-to-C,F,G [Li] -> Should it be ? P-DAO 1 signals C=3D=3D>D=3D=3D>E-to-F,G P-DAO 2 signals A=3D=3D>B=3D=3D>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 REC= OMMENDED that the nodes involved in a Track =3D=3D=3Dmantain=3D=3D=3D multi= ple 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 use= s diverse source route paths to retry similar messages =3D=3D=3Dot=3D=3D=3D= the nodes in the Track.=B6 [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 childre= n. =3D=3D=3D=3Dxref target=3D'RFC6550'/>=3D=3D=3D=3D states that: [Li] -> Typo for "xref target=3D'RFC6550'/>". Why is flag named as "D"? Th= ere is no D in "Projected Routes Support"... 5.1 The Root may use an asynchronous PDR-ACK with an negative status to ind= icate 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 egre= ss 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 s= pecial 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, i= f 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 hap= pen. [Li] -> Confuse with this claim. Is it a MUST NOT if root wants to send not= ification 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 i= t creates without collision. [Li] -> Can you add some description for the collision case? E.g., node tru= sts itself than Root. 6.4.1 In both cases the Track Ingress is the owner of the Track, and it gen= erates 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 f= rom 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 Rou= te Header in the most common LLN deployments. [Li] -> Profile 0 is the Legacy support of [RPL] 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 --_000_CO1PR11MB48816A433456154415039FCCD8549CO1PR11MB4881namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello Li:

 

 

> [Li] Yes. It’s more clear. So PDR-ACK is for orig= inal PDR. And for maintain or tear down case, Root should use No-Path P-DAO= to terminate P-Route. Correct?

 

[PT] yes: the NP DAO cleans the state in the network. It rem= oves the Track. The PDR ACK signals to the Ingress that it is being done an= d why.  Maybe we need to explain that those 2 may be asynchronous to one another. I agree with you that we can probabl= y think this through a little more. E.g., should the PDR ACK trigger a DCO = (RFC 9009) ? Could the PDR ack signal status that is not the death of the T= rack but other stuff?

 

> [Li] Maybe it depends on implement of PCE?  I̵= 7;d like to keep the flexibility because there is a user case for street li= ghting. Some controllers(Ingress nodes) need to light the street lighting linearly with low-latency.

[PT] sure, at the expense of complexity in signaling and pro= cessing in the nodes. We need to  be specific on the scenarios and sta= tus codes. The PDR forms a single Track since the TrackID is provided. Since signaling is involved we need a story for a= ll those questions:

  • Wh= at if there’s a path to only a subset? Should the root form more than= one track?
  • Or deny with your special status but then what = can the source do after that? Try all combinations?
  • What is the best path to one target cannot reach all targets but a lowe= r quality path can? Should we use that one?
    • Mayb= e there could be one main target and additional desirable targets? In that = case the Root could form the track and indicate which of the optional targets are effectively reachable via the track to t= he main target.

 

> [Li] Some physical layer measurements such as RSSI/LQI = have forward and reverse direction. Can it indicate symmetrical?

          =         In layer 3, receiving DIO/NS mes= sages from each other indicate symmetrical

There’s a nuance between bidir and symmetrical.  = Maybe the ping works but the link quality is very different in both directi= ons. If so the Rank increment computation would differ widely and we would need both sides.

 

We need separate threads to solve these issues. Let me start= them

 

Keep safe!

 

Pascal

 

Pascal

 

From:= Roll <roll-bounces@ietf.org> On Behalf Of Li Zhao (liz3)<= br> Sent: vendredi 14 janvier 20= 22 2:51
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org>
Subject: Re: [Roll] review o= f dao-projection -22

 

Hello Pascal,

 

Please find my comments inline.

 

Best regards,

Li

 

From: Roll <roll= -bounces@ietf.org> on behalf of Pascal Thubert (pthubert) <pthubert=3D40cisco.com@d= marc.ietf.org>
Date: Friday, January 14, 20= 22 at 01:31
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org>= ;
Subject: Re: [Roll] review o= f dao-projection -22

Hello Li

 

A great many thanks for your excellent review! Such are much= needed at this time.

 

> [Li] ->  Should it be ?

>          &= nbsp;  P-DAO 1 signals C=3D=3D>D=3D=3D>E-to-F,G

>          &= nbsp;  P-DAO 2 signals A=3D=3D>B=3D=3D>C-to-E,F,G

[PT] correct, great catch!

 

 

> [Li] -> What's the difference between negative statu= s PDR-ACK and No-Path P-DAO in section 6.5?  And when to use asynchron= ous PDR-ACK?

>          &= nbsp;  In storing mode, root should use No-Path P-DAO to tear down Tra= ck from egress node. Is PDR-ACK still needed?

>         &n= bsp;   In non-storing mode, No-Path P-DAO to ingress node is also= enough.

>          &= nbsp;  But the PDR-ACK Status field makes sense. Is it possible to add= this field in No-Path P-DAO?

 

[PT]  The no path DAO flow along the reverse path and c= leans it; so the end result would be that the Track is terminated as you fi= gured. So yes, it could be possible to add a status to the no-path DAO but remember that it is a normal DAO not a compl= etion (IOW not an ack). How could we justify a status in all DAOs? I’= m unclear why the async PDR ack is an issue. If the PDR can not be served, = the track ingress already needs to support a PDR ack that ”terminates” a Track.<= /p>

 

To clarify that sentence we can say:

“

   The main Root MAY indicate to the Track Ingress= that the Track was terminated

   before its time and to do so, it MUST uses an a= synchronous PDR-ACK with an

   negative status.

“

Should that be more than a MAY?

 

>>>> [Li] Yes. It’s more clear. So PDR-ACK= is for original PDR. And for maintain or tear down case, Root should use N= o-Path P-DAO to terminate P-Route. Correct?

 

 

> [Li] -> Is it possible to remove the limitation? &nb= sp;It’s not flexible If PDR can only carry one RTO.=

>          &= nbsp;  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, Roo= t may push two Tracks I->A->B and I->F->G->H.

>         &n= bsp;   If Root cannot computer one Track to multiple RTO, it can = response with a special PDR-ACK Status.

 

[PT]  This was done in the interest to simplicity, and = yes we can rediscuss that.

We’d need to make decisions on partially successful us= e cases e.g.,:

  • Wh= at if there’s a path to only a subset? Should the root form more than= one track?
  • Or deny with your special status but then what = can the source do after that? Try all combinations?
  • What is the best path to one target cannot reach all targets but a lowe= r quality path can? Should we use that one?
    • Mayb= e there could be one main target and additional desirable targets? In that = case the Root could form the track and indicate which of the optional targets are effectively reachable via the track to t= he main target.

 

>>>> [Li] Maybe it depends on implement of PCE? =  I’d like to keep the flexibility because there is a user case f= or street lighting. Some controllers(Ingress nodes) need to light the street lighting linearly with low-latency.

 

 

> [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 receiv= ing 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 goo= d 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 mes= sages from each other indicate symmetrical?

 

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

 

[PT] There’s no protocol element to “send notification to the reque= sting node when those changes happen”. So it’s hard to say that= the root MUST NOT do something that it cannot do. Reworded to

 

“

      Note that there is no protoco= l element to notify to the requesting Track

      Ingress when changes hap= pen deeper down the Track, so they are transparent=

      to the Track Ingress. If the = main Root cannot maintain an expected service

      level, then it needs to tear = down the Track completely.

“

 

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

 

[PT] I reworded to

“

          =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =          In a particular deployment=

     where PDR are not used, a portion o= f the namespace can be administratively

     delegated to the main Root, meaning= that the main Root is authoritative for

     assigning the TrackIDs for the Trac= ks it creates..

“

 

[Li] ->  Is there any difference between P-DAO-ACK a= nd normal DAO-ACK? E.g. any flags?  Normally, root won't receive any D= AO-ACK from nodes.

Is it possible to add flag to= distinguish P-DAO-ACK from DAO-ACK as P-DAO from DAO.

 

[PT] Done; I added a section for the P-DAO-ACK

 

> [Li] -> = Profile 0 is the Legacy support of [RPL= ] Non-Storing Mode. I’m confuse about “this enables to use Storing Mode to r= educe the size of the Source Route Header in the most common LLN deployment= s.”

 

[PT] I really meant Profile 1 enables… Changing that.<= o:p>

 

I guess that’s it !

 

I submitted -23 with this, please have a look at https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-dao-projection-2= 3

 

Again many thanks!

 

Pascal

 

From:= Roll <roll-bounces@ietf.org> On Behalf Of Li Zhao (liz3)<= br> Sent: mercredi 12 janvier 20= 22 10:51
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org>= ;
Subject: [Roll] review of da= o-projection -22

 

Hello Authors,

 

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

 

3.5.2 Using Non-Storing Mode joining Tracks

P-DAO 1 signals C=3D=3D>D= =3D=3D>E-to-F,G

P-DAO 2 signals A=3D=3D>B= =3D=3D>C-to-C,F,G

 

   [Li] ->  Should it be ?

P-DAO 1 signals C=3D=3D>D= =3D=3D>E-to-F,G

P-DAO 2 signals A=3D=3D>B= =3D=3D>C-to-E,F,G

 

    Otherwise RIBs in A cannot include destin= ation to E.

 

4.1. Extending RFC 6550

To ensure that the PDR and P-DAO messages can flow at most t= imes, it is RECOMMENDED that the nodes involved in a Track =3D=3D=3Dmantain= =3D=3D=3D 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 si= milar messages =3D=3D=3Dot=3D=3D=3D the nodes in the Track.=B6

   

[Li] -> Typo for “mantain” and “ot̶= 1;?

 

4.1.6.

This specification defines a new flag "Projected Routes= Support" (D).

The DODAG Configuration option is copied unmodified from par= ents to children. =3D=3D=3D=3Dxref target=3D'RFC6550'/>=3D=3D=3D=3D &nbs= p;states that:

 

[Li] -> Typo for “xref target=3D'RFC6550'/>̶= 1;.  Why is flag named as “D”? There is no D in "Proj= ected Routes Support"…

 

 

5.1 The Root may use an asynchronous PDR-ACK with an negativ= e 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 neede= d?

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-Pat= h P-DAO?

 

 

5.1 One and only one RPL Target Option MUST be present in th= e 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 T= rack to multiple RTO, it can response with a special PDR-ACK Status.

 

 

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

 

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

 

 

6.2  There is no notification to the requesting node wh= en 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 happe= n.

 

 

 

6.3 In a particular deployment where PDR are not used, the n= amespace can be delegated to the main Root, which can assign the TrackIDs f= or the Tracks it creates without collision.

 

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

 

 

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

 

[Li] ->  Is there any difference between P-DAO-ACK a= nd normal DAO-ACK? E.g. any flags?  Normally, root won't receive any D= AO-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] Non-Storing Mode. I’m confuse about “this enables to use Storing Mode to r= educe the size of the Source Route Header in the most common LLN deployment= s.”

 

 

 

Best regards,

Li

 

 

 

 

 

 

 

 

 

 

--_000_CO1PR11MB48816A433456154415039FCCD8549CO1PR11MB4881namp_-- From nobody Fri Jan 14 01:15:09 2022 Return-Path: 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 6538F3A1F8C for ; Fri, 14 Jan 2022 01:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.585 X-Spam-Level: X-Spam-Status: No, score=-9.585 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_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=DHfn7yQu; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=cP+k8qK+ 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 v0XV5dp2ai1c for ; Fri, 14 Jan 2022 01:15:03 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6B393A1F8A for ; Fri, 14 Jan 2022 01:15:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=75460; q=dns/txt; s=iport; t=1642151702; x=1643361302; h=from:to:cc:subject:date:message-id:mime-version; bh=D9uW0epSzoXrd7iq7w69Lypu4dyv90ViUvNtyvr7L9Q=; b=DHfn7yQuDvVqp0LKlX5edGWtkYuMNTFq+wtUJsdJZJniN2GU1pftHtuP cDm0hWWTHV+TIA2axSGgftSj/db7zdhI0DGK85/80ZDaM+reGJ2sH53QC aYGiYqMnFUKADZtKW+vLnctmFk+ACgV3W2+NiAC9kDJ1xBoKLaBVywOXI M=; X-Files: ATT00001.txt : 127 IronPort-PHdr: =?us-ascii?q?A9a23=3AyQ85vhT974f/kmB6pQ+PWdyCCNpso7vLVj580?= =?us-ascii?q?XJvo75Nc6H2+ZPkMQSf4Ph2l1bGUM3d7O4MkOvZta3sGAliqZaMuXwPatpAA?= =?us-ascii?q?hkCj8hFkwkpGsXQD0r9IbbjZDA7G8IXUlhj8jm7PEFZFdy4aUfVpyi57CUZH?= =?us-ascii?q?VP0Mg8mTtk=3D?= IronPort-Data: =?us-ascii?q?A9a23=3AKasrhqumr3CNkiLe7gESHpFl6OfnVKhcMUV32?= =?us-ascii?q?f8akzHdYApBs4E2ekKraxn3XpuKYmL1escyIMmGQXl2vZfVztJgQARv/igyE?= =?us-ascii?q?S1Ao5udCYXGcxv6bn7LcpDPRRM2t5pGNtWZdps4FHTS/0ukP+O7oCAgj62FG?= =?us-ascii?q?ObxAraaZ0idKeMcpHAJ0Eg889MEbq5UbfmRDQ7X4o2pr5XWMgT0i24lbWtEs?= =?us-ascii?q?/3T8ks14Kv84ThC5FcXaKEQtjcytZW64LHzhE2JwvCRrrB8RoZWfM6eiuHpl?= =?us-ascii?q?o/l1011UIn9y++nKhdiroP6ZGBitFIHA8BOvTAazsAC+v5T2Ms0MS+7uR3Q9?= =?us-ascii?q?zxC4I0lWaiLdOscFvakdNLx/PVvO3oW0aVuoNcrKJUk2CCZ5xWun3DEm52CA?= =?us-ascii?q?KyqVLD09NqbAUkWnRAZACoGYhbGjOWszffnDOJtnc8kasLsOevzuFk5kmqfV?= =?us-ascii?q?qlgEMuFGviXjTNb9G9YasRmBereesAUcyZHZxXbaBoJMVASYH47tLb42iehI?= =?us-ascii?q?2UF8zp5ooJyuQA/1jdZyr/pNPLUd8CEA8JPkS6lSsjul4jiKgsRONrawj2f/?= =?us-ascii?q?zfwwOTOhij8HokVEdWFGjdRqAX77gQu5Nc+DDNXecWEt3M=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AUlVHpaAWDcLnWVzlHegbsceALOsnbusQ8z?= =?us-ascii?q?AXPh9KKCC9I/b3qynxppsmPEfP+UossHFJo6HmBEDyewKiyXcV2/hfAV7GZm?= =?us-ascii?q?nbUQSTXfpfBQWJ+UybJ8STzJ856U4CSdkxNDSTNykGsS+S2mDReLxMrKjlgc?= =?us-ascii?q?KVbIzlvhFQpHRRGtldBnBCe3+m+yNNNW17LKt8MKDZyttMpjKmd3hSRN+8HG?= =?us-ascii?q?M5U+/KoMCOvI76YDYdbiRXqTWmvHeN0vrXAhKY1hARX3dk2rE561XIlAT/++?= =?us-ascii?q?GKr+y78BnBzGXehq4m2OcJi+EzR/BkuPJlbwkEuTzYILiJnIfy+wzdldvfqm?= =?us-ascii?q?rCVuO85SvIcf4Dsk85NVvF3ycFkzOQoQrGrUWSkWNxRRDY0JbErPVQMbsbuW?= =?us-ascii?q?sRSGqo12Mw+N57y65FxGSfqt5eCg7Bhj3045zSWwhtjVfcmwtprQc/tQ0WbW?= =?us-ascii?q?IlUs4bkWXfxjIgLL4QWCbhrIw3GuhnC8/RoP5QbFOBdnjc+m1i2salUHg/Fg?= =?us-ascii?q?qPBhFqgL3Y7xFG2HRii0cIzs0WmXkNsJo7Vplf/uzBdqBljqtHQMMaZb90QO?= =?us-ascii?q?0BXcy0AGrQRg+kChPeHX33UKUcf37doZ/+57s4oOmsZZwT1ZM33I/MVVtJ3F?= =?us-ascii?q?RCMn4Gyff+qqGj3iq9MllVbA6dvf22vaIJyYEUbICbRBG+dA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BsAAB/PuFh/5tdJa1aHQEBAQEJARI?= =?us-ascii?q?BBQUBQIFFCAELAYEgATBWB3daNzGIDgOEWWCFDoMCA4ETjyGCMYg5gS4UgRE?= =?us-ascii?q?DTwUEBwEBAQ0BASoBDAoEAQGFBQKDSgIlNAkOAQIEAQEBEgEBBQEBAQIBBgS?= =?us-ascii?q?BCROFOwEEKA2GQgEBAQECAgEKBggNBhMBASwLAQQNARkDAQEBIQEGCSULFAk?= =?us-ascii?q?JAQQOBQgGFIJjgmUDDSEBDp9eAYE6AoofeIEBMoEBgggBAQYEBIE6AoNPGII?= =?us-ascii?q?vBwMGgToBgw2CfgpKSocJJxyBSUSBFAFDVYERSnWCYwEBAhiBDBwEHB4GBwm?= =?us-ascii?q?DGYIukB8BEBVGDmANJREOAiACKwMLAh4IFQEyBQ8JAQISBw8fCwuSNI0HgXA?= =?us-ascii?q?Pi2+SWgqDRIVigxgojG+JWhWDcIwMl3KWQSChCAgPCwuEXgIEAgQFAg4BAQa?= =?us-ascii?q?BYTuBWXAVO4JpURkPhWuCX4VWg3GFFIVKdAI2AgYLAQEDCY1nB4I/AQE?= X-IronPort-AV: E=Sophos;i="5.88,288,1635206400"; d="txt'?scan'208,217";a="984668053" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Jan 2022 09:15:00 +0000 Received: from mail.cisco.com (xbe-rcd-006.cisco.com [173.37.102.21]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 20E9F06b003950 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for ; Fri, 14 Jan 2022 09:15:00 GMT Received: from xfe-rcd-001.cisco.com (173.37.227.249) by xbe-rcd-006.cisco.com (173.37.102.21) 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 03:15:00 -0600 Received: from xfe-rtp-005.cisco.com (64.101.210.235) by xfe-rcd-001.cisco.com (173.37.227.249) 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 03:15:00 -0600 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-005.cisco.com (64.101.210.235) 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 04:14:59 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GdJHtPBWKZDy6UeggUqOATtOY+PYPVO76Y/seA7YCUzSowPvcnTqSaGsvS6It9T6M8JoWRNdKBq4ikYje7cW2hc3ZdXfzmHHFFQiKYQLyuXVFdl8wet6hCBwtl2kFKskXcLG8w8wnAOm6GhHufNQYkEHw6ddySK3/8lGZWy3wCVuIbr7yQ9Pv60Ob4TAAY4CuDSZ30iIFWbR2DBXG4s0Qe9i+lnfH8TuuKc1GRfyRj8obSg/ErpX/P3lrUQunMKMTKB0vJCUeDfBKCGLb0AGTyRht2m6o/W9ek4GWzzAfiYrXIS/CSzQ70mX5aLCD0Av3tLExxv6ZHu2mOzJbqPvFA== 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=/tX4F3qQh5W7Ccor+VLQEeDDWd4XF/ZaoHZfl0rK8ec=; b=X3pSAKDf6l/OBnlzM360I02HO0kgs0JXT6ZTkSaHvKIaTAHRht5rYeO60Cl7etv0kVIZ6IvfScqAlsC0XNKP61ha2l7KlHqeTVcQDmyNP7mq2tirTAqHLpAtmeztvagQcsMDkBzeTuoO6P14UCQDnkJ/h7h5au1QziRMbUHCB8D1zBa+yQZLh2awAD7OqSr3lb9VEEx9q4FazmU1053NbP6lHnFfd3qtBLw66aru3PHwO3sY+vKsK5nM/SfwZD3FN37uFO2l0qHsZzlttQZOm8xB/T3RDxRp55xZGy99JiAMRs6pVW3H5z+bViN4l9SPFszAeypyV6OmDf52tqQMDg== 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=/tX4F3qQh5W7Ccor+VLQEeDDWd4XF/ZaoHZfl0rK8ec=; b=cP+k8qK+1YM2NQBlwBglLz95qQZR6McKvZFlIVrOmc1KU0yMV2fwNkKpGgHWj078KQ9IChuceFhkSsdhm+PcJmr65o14Lmfoi0RksM9Se0u+xzdipHgEiZSLH8qpdz06tT0Q6ip9dbIz+7vnYJYYW4lJxy2RWM8AzeZBy/53DGk= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MWHPR1101MB2127.namprd11.prod.outlook.com (2603:10b6:301:58::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4867.11; Fri, 14 Jan 2022 09:14:57 +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 09:14:57 +0000 From: "Pascal Thubert (pthubert)" To: "ROLL WG (roll@ietf.org)" Thread-Topic: Asynchronous PDR-ACK procedure (Was: [Roll] review of dao-projection -22) Thread-Index: AdgJJwg/xVA9ZxIxQQavxeqMKc3l4A== Date: Fri, 14 Jan 2022 09:14:40 +0000 Deferred-Delivery: Fri, 14 Jan 2022 09:14:06 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes 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: 1824d56a-c274-47fa-2bdc-08d9d73e5598 x-ms-traffictypediagnostic: MWHPR1101MB2127:EE_ x-microsoft-antispam-prvs: 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: h0akldI/PZu5ybID+OG4d7bOmQCoUL21x9HKGbfkE6KR+XdNOdMS1+I9GhJqFY/Mp8jo93EvJbQZUKYCordvbDrwwtEKIAyOCPwCW1/LBvJWFysvJ/l4G56FkN/FX1NM0lohtaGC0Er2IaxW2XxwQMI0kUlu6TC0pi5SsZ+bAzgVwaNyOFzEyBoiMZNtZYI8izIJYkc5/GpCj4uzpFOc8dkNXQrQUohoq2V3AlaVnXuKn0vlKd5sn4NStrjN1ZH505wmdBRHv9NkWMsGQlY2PD2N08V3VtYxYVlR6mO6+7h0DZEKlzN++hoos0ST8Kazvm0kaqTVmnjsapm5fAbS3aN/OgsHRS9lv9Wkc/GBFeF9G7AMnEgsvbVD+gCBqcfr+8//5ucGPi6Ulx2Dovd1yf3kM4YMkbNmiYO+Uhf0q5p2IvJxWlUWO+r76zHQPX4aVJZYHgYe2nad9MU2PeQkJJF86mAiG/nnnJit/4w7v+pIFLclrLsL12uFBm1rRVqAdL55NhuJDs4INyyRYJrQJUVzXwOwBffn1a/bnhenHcng+nFGVIBH7uwU4QwRwxAeWQi9vYU8HMqgekgswpCTdfXMW9S1X3d7c56J1UdYvY0P+DoF7yPjoJ0imNZf51Lz4ZlLO267znm38HjrpbY43GlSPoO63TvemLD/74Hu2EweocfF7dUlymrLOWn+3cIlmA+HRKPS4MHa2/R1lJHmslzCNVuyQ0whZkA0sBlBYV5H2Urrq5XFmLvXZxDGN3KiXIp12hrVBFyZKAENn3cnF9wSUdHDrh04Ibo1WHDV5rF182P+9Bz55oGtwfA8Iz4StOnI4lvsO6jBXVS1BdzS/Q== 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)(9686003)(186003)(30864003)(122000001)(38100700002)(5660300002)(7696005)(83380400001)(53546011)(26005)(6506007)(52536014)(166002)(6916009)(2906002)(316002)(66556008)(76116006)(508600001)(8676002)(33656002)(55016003)(107886003)(99936003)(6666004)(38070700005)(966005)(8936002)(4326008)(66946007)(71200400001)(66446008)(66476007)(64756008)(86362001)(66574015)(579004)(559001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?GiOWnoxrN+NWVGJBpdeUjTGvJYOoy5Vit7FXeVad7hqFrQe+A9jUA9xYy3?= =?iso-8859-1?Q?3odtq3+6CtBTJvTd7HjYn5aN5puCGoPR1P2GoZg6pRwXOrXZ0lhAd6WEVp?= =?iso-8859-1?Q?MdCC/Z2t8EJiswYLiksMVnLYrA3PfQE2rlwVh4j5xcFDUk3w1aWcDFS5AH?= =?iso-8859-1?Q?dQK4uN1pTNXymfg/Kurk78AafJzbwK902MeVmyzIb2dTCpO0pZ9iF3uxCa?= =?iso-8859-1?Q?s5u7ZkU1RbSjYBFUWloUV5gY8+9LiZfxWw3c3Kt7OTAzBGE0ZEswwyvGH9?= =?iso-8859-1?Q?qZfnvpVcyZCX8ytOeqSPWYkEVugVQ3FcLtShfm2thA8TfNvCBulLfs05rh?= =?iso-8859-1?Q?is03pxek3JOrTvP36taYjnGvPVK8e48M/xN4b726JAru3YFCpm6lrKeC0t?= =?iso-8859-1?Q?tMvbNofxn4Dy2NKYE+6z6SZdZblh7QkxCiHoAdxaBBCVRC6+Rw2ZnUZQ+c?= =?iso-8859-1?Q?bhgCgmHq1WfRVcfUWWmWDmJcRey4e2V7iKk1dNm7+6DAChhRYdI07tVb/D?= =?iso-8859-1?Q?+z130hOvlFNvNVQOViCMxiYlAHBHhHiBXLG9tbSy/KZZxNU0PAmLJb48bQ?= =?iso-8859-1?Q?6z7+KNtsntIJXayCcgcncC0TvpVLJnyqiYw3+vC5s/W/IZN46cMvKgwnm5?= =?iso-8859-1?Q?XntbPrR69uv+qmVd79E6hX/mBsON4wTJZ/xjGK5nrMjNlIrsryDTJvUV3E?= =?iso-8859-1?Q?cI1oPKtN303n9qbabGzxI7pub1lryA3+CIKAT47tPAOdMvaJZKZ/o0FANa?= =?iso-8859-1?Q?wC3Wz6o0TeMZcJa5xDyd4n3oSrWoopdEp/YTKv/KsNwZ3mwigVlDqpLbSX?= =?iso-8859-1?Q?X98FuoySI/2AVAOhQquyWzVGmhj4NyZxe4WlEXpwkz7P+devdgQHp67whb?= =?iso-8859-1?Q?9IniONx/l6Y5eLDA2ljn+wgt6ZQWTlRvyUX7BUTPmIRCuMk+F9Zgv5DzG4?= =?iso-8859-1?Q?pGlxuEsBfO0yhd25EXCUhKorizxkcAyEuvqysmXSp5o3TVAuTiWsk/sfUG?= =?iso-8859-1?Q?Ur7d2MhMTS479e+sS1fTCYkuDzBKaq6CObNW+JXOUNAtdeCGJe6aMckrRX?= =?iso-8859-1?Q?JmFj+MtFV/tUP2WYq0PYuwjhxiM8blH6FGW6VDHlJa/K1f9wJEXHeJh5Q6?= =?iso-8859-1?Q?rKy8SVr1uelOIKTC/ZnECDaZgIus/VwU8l9WoQJ6ppXeOoTkZF41WaxfHr?= =?iso-8859-1?Q?w32AAzW7n2R5Q/AFWXbVHyyzXskfrXZG5AeJOK3kAplCMplMaChv8hnMF7?= =?iso-8859-1?Q?i4u0FkUJxmowX2W4MZaz6oF4+PLK3SgWj1/+01f3NMd8KSOM3CPOy/UglS?= =?iso-8859-1?Q?lNwQfAa75bnaau1aqktc7uGOz4V4YU4EBHphY4yuT5xmUQWXuFv9Y1tusF?= =?iso-8859-1?Q?AfmGvIJqHm89vg/GfYZiG5a541Fy9SWRZbmHzOaNeFWVB1Lwf4AF4TZXzL?= =?iso-8859-1?Q?80vvu7c36YqbQWazr8c4fVLnstsE1JlUpB3m0gllRzRX9gb26tbx8dLjiK?= =?iso-8859-1?Q?DViX7Ig4UC+sCFe50GhSv2OZRs/XrcRma0io4Qh2z+W8dz9XQZKtbECdbG?= =?iso-8859-1?Q?ANfB0bmejeM1TbpQzynVm6/4wHeLBgiQTXo26sAfxGb9uW5o4Odwu2Uo9Q?= =?iso-8859-1?Q?qbq0l8bcqVooq3auEDtvGohpyV6GhMdSDTImitcWFeA6N0SvQwgW28zXy4?= =?iso-8859-1?Q?McKOFvtFhv1V5ou1JkQ=3D?= Content-Type: multipart/mixed; boundary="_004_CO1PR11MB48814F2E0935FE03CC5D1271D8549CO1PR11MB4881namp_" 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: 1824d56a-c274-47fa-2bdc-08d9d73e5598 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2022 09:14:57.2053 (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: t4HEf7O2n3gAa6zPLYWF/denBMaWOqp5U/5i8DqnDDzTvM/0v39Q6oLv49aXmK1U51pFlO/V8+TUgm0Z1oIHnw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1101MB2127 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.21, xbe-rcd-006.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: [Roll] Asynchronous PDR-ACK procedure (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2022 09:15:08 -0000 --_004_CO1PR11MB48814F2E0935FE03CC5D1271D8549CO1PR11MB4881namp_ Content-Type: multipart/alternative; boundary="_000_CO1PR11MB48814F2E0935FE03CC5D1271D8549CO1PR11MB4881namp_" --_000_CO1PR11MB48814F2E0935FE03CC5D1271D8549CO1PR11MB4881namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all: we had this thread as part of Li's review: > [Li] So PDR-ACK is for original PDR. And for maintain or tear down case, = Root should use No-Path P-DAO to terminate P-Route. Correct? [PT] yes: the NP DAO cleans the state in the network. It removes the Track.= The PDR ACK signals to the Ingress that it is being done and why. Maybe w= e need to explain that those 2 may be asynchronous to one another. I agree = with you that we can probably think this through a little more. * E.g., should the PDR ACK trigger a DCO (RFC 9009) ? * Could the PDR ack signal status that is not the death of the Track bu= t other stuff? Basically we need to clarify when the main Root sends an async PDR ACK, wha= t status go on there and what the reaction is by the Track Ingress based on= the status (including unknown). Comments welcome! Pascal From: Roll On Behalf Of Pascal Thubert (pthubert) Sent: vendredi 14 janvier 2022 9:18 To: Routing Over Low power and Lossy networks Subject: Re: [Roll] review of dao-projection -22 Hello Li: > [Li] Yes. It's more clear. So PDR-ACK is for original PDR. And for mainta= in or tear down case, Root should use No-Path P-DAO to terminate P-Route. C= orrect? [PT] yes: the NP DAO cleans the state in the network. It removes the Track.= The PDR ACK signals to the Ingress that it is being done and why. Maybe w= e need to explain that those 2 may be asynchronous to one another. I agree = with you that we can probably think this through a little more. E.g., shoul= d the PDR ACK trigger a DCO (RFC 9009) ? Could the PDR ack signal status th= at is not the death of the Track but other stuff? > [Li] Maybe it depends on implement of PCE? I'd like to keep the flexibil= ity because there is a user case for street lighting. Some controllers(Ingr= ess nodes) need to light the street lighting linearly with low-latency. [PT] sure, at the expense of complexity in signaling and processing in the = nodes. We need to be specific on the scenarios and status codes. The PDR f= orms a single Track since the TrackID is provided. Since signaling is invol= ved we need a story for all those questions: * What if there's a path to only a subset? Should the root form more th= an one track? * Or deny with your special status but then what can the source do afte= r that? Try all combinations? * What is the best path to one target cannot reach all targets but a lo= wer quality path can? Should we use that one? * Maybe there could be one main target and additional desirable targets= ? In that case the Root could form the track and indicate which of the opti= onal targets are effectively reachable via the track to the main target. > [Li] Some physical layer measurements such as RSSI/LQI have forward and r= everse direction. Can it indicate symmetrical? In layer 3, receiving DIO/NS messages from each other ind= icate symmetrical There's a nuance between bidir and symmetrical. Maybe the ping works but t= he link quality is very different in both directions. If so the Rank increm= ent computation would differ widely and we would need both sides. We need separate threads to solve these issues. Let me start them Keep safe! Pascal Pascal From: Roll > On Behalf = Of Li Zhao (liz3) Sent: vendredi 14 janvier 2022 2:51 To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] review of dao-projection -22 Hello Pascal, Please find my comments inline. Best regards, Li From: Roll > on behalf = of Pascal Thubert (pthubert) > Date: Friday, January 14, 2022 at 01:31 To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] review of dao-projection -22 Hello Li A great many thanks for your excellent review! Such are much needed at this= time. > [Li] -> Should it be ? > P-DAO 1 signals C=3D=3D>D=3D=3D>E-to-F,G > P-DAO 2 signals A=3D=3D>B=3D=3D>C-to-E,F,G [PT] correct, great catch! > [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 T= rack from egress node. Is PDR-ACK still needed? > In non-storing mode, No-Path P-DAO to ingress node is also en= ough. > But the PDR-ACK Status field makes sense. Is it possible to a= dd this field in No-Path P-DAO? [PT] The no path DAO flow along the reverse path and cleans it; so the end= result would be that the Track is terminated as you figured. So yes, it co= uld be possible to add a status to the no-path DAO but remember that it is = a normal DAO not a completion (IOW not an ack). How could we justify a stat= us in all DAOs? I'm unclear why the async PDR ack is an issue. If the PDR c= an not be served, the track ingress already needs to support a PDR ack that= "terminates" a Track. To clarify that sentence we can say: " The main Root MAY indicate to the Track Ingress that the Track was termi= nated before its time and to do so, it MUST uses an asynchronous PDR-ACK with = an negative status. " Should that be more than a MAY? >>>> [Li] Yes. It's more clear. So PDR-ACK is for original PDR. And for mai= ntain or tear down case, Root should use No-Path P-DAO to terminate P-Route= . Correct? > [Li] -> Is it possible to remove the limitation? It's not flexible If PD= R can only carry one RTO. > For instance in figure 7, if node I requests P-Route to B&H t= ogether, 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 res= ponse with a special PDR-ACK Status. [PT] This was done in the interest to simplicity, and yes we can rediscuss= that. We'd need to make decisions on partially successful use cases e.g.,: * What if there's a path to only a subset? Should the root form more th= an one track? * Or deny with your special status but then what can the source do afte= r that? Try all combinations? * What is the best path to one target cannot reach all targets but a lo= wer quality path can? Should we use that one? * Maybe there could be one main target and additional desirable targets= ? In that case the Root could form the track and indicate which of the opti= onal targets are effectively reachable via the track to the main target. >>>> [Li] Maybe it depends on implement of PCE? I'd like to keep the flexi= bility because there is a user case for street lighting. Some controllers(I= ngress nodes) need to light the street lighting linearly with low-latency. > [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 tre= at 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 simplifi= cation. 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 an= d reverse direction. Can it indicate symmetrical? In layer 3, receiving DIO/NS messages from each other ind= icate symmetrical? > [Li] -> Confuse with this claim. Is it a MUST NOT if root wants to send n= otification to the requesting node when those changes happen. [PT] There's no protocol element to "send notification to the requesting no= de when those changes happen". So it's hard to say that the root MUST NOT d= o something that it cannot do. Reworded to " Note that there is no protocol element to notify to the requesting Tr= ack Ingress when changes happen deeper down the Track, so they are transp= arent to the Track Ingress. If the main Root cannot maintain an expected se= rvice level, then it needs to tear down the Track completely. " > [Li] -> Can you add some description for the collision case? E.g., node t= rusts itself than Root. [PT] I reworded to " = In a particular deployment where PDR are not used, a portion of the namespace can be administrati= vely delegated to the main Root, meaning that the main Root is authoritativ= e for assigning the TrackIDs for the Tracks it creates.. " [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 f= rom DAO. [PT] Done; I added a section for the P-DAO-ACK > [Li] -> Profile 0 is the Legacy support of [RPL] Non-Storing Mode. I= 'm confuse about "this enables to use Storing Mode to reduce the size of th= e Source Route Header in the most common LLN deployments." [PT] I really meant Profile 1 enables... Changing that. I guess that's it ! I submitted -23 with this, please have a look at https://www.ietf.org/rfcdi= ff?url2=3Ddraft-ietf-roll-dao-projection-23 Again many thanks! Pascal From: Roll > On Behalf = Of Li Zhao (liz3) Sent: mercredi 12 janvier 2022 10:51 To: Routing Over Low power and Lossy networks > 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=3D=3D>D=3D=3D>E-to-F,G P-DAO 2 signals A=3D=3D>B=3D=3D>C-to-C,F,G [Li] -> Should it be ? P-DAO 1 signals C=3D=3D>D=3D=3D>E-to-F,G P-DAO 2 signals A=3D=3D>B=3D=3D>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 REC= OMMENDED that the nodes involved in a Track =3D=3D=3Dmantain=3D=3D=3D multi= ple 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 use= s diverse source route paths to retry similar messages =3D=3D=3Dot=3D=3D=3D= the nodes in the Track.=B6 [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 childre= n. =3D=3D=3D=3Dxref target=3D'RFC6550'/>=3D=3D=3D=3D states that: [Li] -> Typo for "xref target=3D'RFC6550'/>". Why is flag named as "D"? Th= ere is no D in "Projected Routes Support"... 5.1 The Root may use an asynchronous PDR-ACK with an negative status to ind= icate 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 egre= ss 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 s= pecial 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, i= f 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 hap= pen. [Li] -> Confuse with this claim. Is it a MUST NOT if root wants to send not= ification 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 i= t creates without collision. [Li] -> Can you add some description for the collision case? E.g., node tru= sts itself than Root. 6.4.1 In both cases the Track Ingress is the owner of the Track, and it gen= erates 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 f= rom 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 Rou= te Header in the most common LLN deployments. [Li] -> Profile 0 is the Legacy support of [RPL] 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 --_000_CO1PR11MB48814F2E0935FE03CC5D1271D8549CO1PR11MB4881namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

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

 

> [Li] So PDR-ACK is for original PDR. And for maintain o= r tear down case, Root should use No-Path P-DAO to terminate P-Route. Corre= ct?

 

[PT] yes: the NP DAO cleans the state in the network. It rem= oves the Track. The PDR ACK signals to the Ingress that it is being done an= d why.  Maybe we need to explain that those 2 may be asynchronous to one another. I agree with you that we can probabl= y think this through a little more.

  • E.= g., should the PDR ACK trigger a DCO (RFC 9009) ?
  • Could the PDR ack signal status that is not the= death of the Track but other stuff?

 

 

Basically we need to clarify when the main Root sends an asy= nc PDR ACK, what status go on there and what the reaction is by the Track I= ngress based on the status (including unknown).

 

Comments welcome!

 

Pascal

 

From:= Roll <roll-bounces@ietf.org> On Behalf Of Pascal Thubert = (pthubert)
Sent: vendredi 14 janvier 20= 22 9:18
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org>
Subject: Re: [Roll] review o= f dao-projection -22

 

Hello Li:

 

 

> [Li] Yes. It’s more clear. So PDR-ACK is for orig= inal PDR. And for maintain or tear down case, Root should use No-Path P-DAO= to terminate P-Route. Correct?

 

[PT] yes: the NP DAO cleans the state in the network. It rem= oves the Track. The PDR ACK signals to the Ingress that it is being done an= d why.  Maybe we need to explain that those 2 may be asynchronous to one another. I agree with you that we can probabl= y think this through a little more. E.g., should the PDR ACK trigger a DCO = (RFC 9009) ? Could the PDR ack signal status that is not the death of the T= rack but other stuff?

 

> [Li] Maybe it depends on implement of PCE?  I̵= 7;d like to keep the flexibility because there is a user case for street li= ghting. Some controllers(Ingress nodes) need to light the street lighting linearly with low-latency.

[PT] sure, at the expense of complexity in signaling and pro= cessing in the nodes. We need to  be specific on the scenarios and sta= tus codes. The PDR forms a single Track since the TrackID is provided. Since signaling is involved we need a story for a= ll those questions:

  • Wh= at if there’s a path to only a subset? Should the root form more than= one track?
  • Or deny with your special status but then what = can the source do after that? Try all combinations?
  • What is the best path to one target cannot reach all targets but a lowe= r quality path can? Should we use that one?
    • Mayb= e there could be one main target and additional desirable targets? In that = case the Root could form the track and indicate which of the optional targets are effectively reachable via the track to t= he main target.

 

> [Li] Some physical layer measurements such as RSSI/LQI = have forward and reverse direction. Can it indicate symmetrical?

          =         In layer 3, receiving DIO/NS mes= sages from each other indicate symmetrical

There’s a nuance between bidir and symmetrical.  = Maybe the ping works but the link quality is very different in both directi= ons. If so the Rank increment computation would differ widely and we would need both sides.

 

We need separate threads to solve these issues. Let me start= them

 

Keep safe!

 

Pascal

 

Pascal

 

From:= Roll <roll-bounces@ietf.org> On Behalf Of Li Zhao (liz3)<= br> Sent: vendredi 14 janvier 20= 22 2:51
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org>= ;
Subject: Re: [Roll] review o= f dao-projection -22

 

Hello Pascal,

 

Please find my comments inline.

 

Best regards,

Li

 

From: Roll <roll= -bounces@ietf.org> on behalf of Pascal Thubert (pthubert) <pthubert=3D40cisco.com@d= marc.ietf.org>
Date: Friday, January 14, 20= 22 at 01:31
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org>= ;
Subject: Re: [Roll] review o= f dao-projection -22

Hello Li

 

A great many thanks for your excellent review! Such are much= needed at this time.

 

> [Li] ->  Should it be ?

>          &= nbsp;  P-DAO 1 signals C=3D=3D>D=3D=3D>E-to-F,G

>          &= nbsp;  P-DAO 2 signals A=3D=3D>B=3D=3D>C-to-E,F,G

[PT] correct, great catch!

 

 

> [Li] -> What's the difference between negative statu= s PDR-ACK and No-Path P-DAO in section 6.5?  And when to use asynchron= ous PDR-ACK?

>          &= nbsp;  In storing mode, root should use No-Path P-DAO to tear down Tra= ck from egress node. Is PDR-ACK still needed?

>         &n= bsp;   In non-storing mode, No-Path P-DAO to ingress node is also= enough.

>          &= nbsp;  But the PDR-ACK Status field makes sense. Is it possible to add= this field in No-Path P-DAO?

 

[PT]  The no path DAO flow along the reverse path and c= leans it; so the end result would be that the Track is terminated as you fi= gured. So yes, it could be possible to add a status to the no-path DAO but remember that it is a normal DAO not a compl= etion (IOW not an ack). How could we justify a status in all DAOs? I’= m unclear why the async PDR ack is an issue. If the PDR can not be served, = the track ingress already needs to support a PDR ack that ”terminates” a Track.<= /p>

 

To clarify that sentence we can say:

“

   The main Root MAY indicate to the Track Ingress= that the Track was terminated

   before its time and to do so, it MUST uses an a= synchronous PDR-ACK with an

   negative status.

“

Should that be more than a MAY?

 

>>>> [Li] Yes. It’s more clear. So PDR-ACK= is for original PDR. And for maintain or tear down case, Root should use N= o-Path P-DAO to terminate P-Route. Correct?

 

 

> [Li] -> Is it possible to remove the limitation? &nb= sp;It’s not flexible If PDR can only carry one RTO.=

>          &= nbsp;  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, Roo= t may push two Tracks I->A->B and I->F->G->H.

>         &n= bsp;   If Root cannot computer one Track to multiple RTO, it can = response with a special PDR-ACK Status.

 

[PT]  This was done in the interest to simplicity, and = yes we can rediscuss that.

We’d need to make decisions on partially successful us= e cases e.g.,:

  • Wh= at if there’s a path to only a subset? Should the root form more than= one track?
  • Or deny with your special status but then what = can the source do after that? Try all combinations?
  • What is the best path to one target cannot reach all targets but a lowe= r quality path can? Should we use that one?
    • Mayb= e there could be one main target and additional desirable targets? In that = case the Root could form the track and indicate which of the optional targets are effectively reachable via the track to t= he main target.

 

>>>> [Li] Maybe it depends on implement of PCE? =  I’d like to keep the flexibility because there is a user case f= or street lighting. Some controllers(Ingress nodes) need to light the street lighting linearly with low-latency.

 

 

> [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 receiv= ing 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 goo= d 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 mes= sages from each other indicate symmetrical?

 

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

 

[PT] There’s no protocol element to “send notification to the reque= sting node when those changes happen”. So it’s hard to say that= the root MUST NOT do something that it cannot do. Reworded to

 

“

      Note that there is no protoco= l element to notify to the requesting Track

      Ingress when changes hap= pen deeper down the Track, so they are transparent=

      to the Track Ingress. If the = main Root cannot maintain an expected service

      level, then it needs to tear = down the Track completely.

“

 

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

 

[PT] I reworded to

“

          =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =          In a particular deployment=

     where PDR are not used, a portion o= f the namespace can be administratively

     delegated to the main Root, meaning= that the main Root is authoritative for

     assigning the TrackIDs for the Trac= ks it creates..

“

 

[Li] ->  Is there any difference between P-DAO-ACK a= nd normal DAO-ACK? E.g. any flags?  Normally, root won't receive any D= AO-ACK from nodes.

Is it possible to add flag to= distinguish P-DAO-ACK from DAO-ACK as P-DAO from DAO.

 

[PT] Done; I added a section for the P-DAO-ACK

 

> [Li] -> = Profile 0 is the Legacy support of [RPL= ] Non-Storing Mode. I’m confuse about “this enables to use Storing Mode to r= educe the size of the Source Route Header in the most common LLN deployment= s.”

 

[PT] I really meant Profile 1 enables… Changing that.<= o:p>

 

I guess that’s it !

 

I submitted -23 with this, please have a look at https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-dao-projection-2= 3

 

Again many thanks!

 

Pascal

 

From:= Roll <roll-bounces@ietf.org> On Behalf Of Li Zhao (liz3)<= br> Sent: mercredi 12 janvier 20= 22 10:51
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org>= ;
Subject: [Roll] review of da= o-projection -22

 

Hello Authors,

 

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

 

3.5.2 Using Non-Storing Mode joining Tracks

P-DAO 1 signals C=3D=3D>D= =3D=3D>E-to-F,G

P-DAO 2 signals A=3D=3D>B= =3D=3D>C-to-C,F,G

 

   [Li] ->  Should it be ?

P-DAO 1 signals C=3D=3D>D= =3D=3D>E-to-F,G

P-DAO 2 signals A=3D=3D>B= =3D=3D>C-to-E,F,G

 

    Otherwise RIBs in A cannot include destin= ation to E.

 

4.1. Extending RFC 6550

To ensure that the PDR and P-DAO messages can flow at most t= imes, it is RECOMMENDED that the nodes involved in a Track =3D=3D=3Dmantain= =3D=3D=3D 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 si= milar messages =3D=3D=3Dot=3D=3D=3D the nodes in the Track.=B6

   

[Li] -> Typo for “mantain” and “ot̶= 1;?

 

4.1.6.

This specification defines a new flag "Projected Routes= Support" (D).

The DODAG Configuration option is copied unmodified from par= ents to children. =3D=3D=3D=3Dxref target=3D'RFC6550'/>=3D=3D=3D=3D &nbs= p;states that:

 

[Li] -> Typo for “xref target=3D'RFC6550'/>̶= 1;.  Why is flag named as “D”? There is no D in "Proj= ected Routes Support"…

 

 

5.1 The Root may use an asynchronous PDR-ACK with an negativ= e 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 neede= d?

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-Pat= h P-DAO?

 

 

5.1 One and only one RPL Target Option MUST be present in th= e 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 T= rack to multiple RTO, it can response with a special PDR-ACK Status.

 

 

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

 

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

 

 

6.2  There is no notification to the requesting node wh= en 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 happe= n.

 

 

 

6.3 In a particular deployment where PDR are not used, the n= amespace can be delegated to the main Root, which can assign the TrackIDs f= or the Tracks it creates without collision.

 

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

 

 

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

 

[Li] ->  Is there any difference between P-DAO-ACK a= nd normal DAO-ACK? E.g. any flags?  Normally, root won't receive any D= AO-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] Non-Storing Mode. I’m confuse about “this enables to use Storing Mode to r= educe the size of the Source Route Header in the most common LLN deployment= s.”

 

 

 

Best regards,

Li

 

 

 

 

 

 

 

 

 

 

--_000_CO1PR11MB48814F2E0935FE03CC5D1271D8549CO1PR11MB4881namp_-- --_004_CO1PR11MB48814F2E0935FE03CC5D1271D8549CO1PR11MB4881namp_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=127; creation-date="Fri, 14 Jan 2022 08:18:56 GMT"; modification-date="Fri, 14 Jan 2022 09:14:39 GMT" Content-ID: Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClJvbGwgbWFp bGluZyBsaXN0DQpSb2xsQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3JvbGwNCg== --_004_CO1PR11MB48814F2E0935FE03CC5D1271D8549CO1PR11MB4881namp_-- From nobody Fri Jan 14 01:20:09 2022 Return-Path: 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 A95E63A1FB1 for ; Fri, 14 Jan 2022 01:20:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.585 X-Spam-Level: X-Spam-Status: No, score=-9.585 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_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=LqD7+col; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ktdscXks 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 lvl2ph3b36hP for ; Fri, 14 Jan 2022 01:20:02 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 891213A1FB0 for ; Fri, 14 Jan 2022 01:20:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=71136; q=dns/txt; s=iport; t=1642152002; x=1643361602; h=from:to:cc:subject:date:message-id:mime-version; bh=eBdXjdgQYTEida39Kryg2fajOIWpkpwwbJC8sLfcBDM=; b=LqD7+colzOr4e39gMZ7JhZPZTXdAkRyWnX7wc4kZvgQb611GUm1whyv3 aeIvgHYjhKTdyjByCYeCYhGujEr4ggsfwh+AMntNwlnDYqs/pH5KNt0uc rDpvlZMGyeUnH+jKkbDrjMiso11DXWk3Ck+cjG8Qk4VjUhbZwQM6hJsNA o=; X-Files: ATT00001.txt : 127 IronPort-PHdr: =?us-ascii?q?A9a23=3Ag2Z6CxK3lxVX3sxFY9mcuWEyDhhOgF28FgIW6?= =?us-ascii?q?59yjbVIf+zj+pn5J0XQ6L1ri0OBRoTU7f9Iyo+0+6DtUGAN+9CN5XYFdpEfW?= =?us-ascii?q?xoMk85DmQsmDYaMAlH6K/i/aSs8EYxCWVZp8mv9P1JSHZP1ZkbZpTu56jtBc?= =?us-ascii?q?ig=3D?= IronPort-Data: =?us-ascii?q?A9a23=3Aj4lpTKjZ/KYeqhrcudAGokSLX161nhIKZh0uj?= =?us-ascii?q?C45NGQN5FlGYwSz7tYtKRjiXv+KYmL0ZZ0+LL0CxjoCuJbVytVrTgE/rC4zE?= =?us-ascii?q?HhA+JLJVIvEck2hYnrOc8HKHRM/sJ1CZoCad8xuRXGF+h6gaeLs9CUm2azWG?= =?us-ascii?q?rf2ULCZUswdqXeIHw94000LptPVorKEoPDjXVKGt42s/pWONgKu1mB5PG9E4?= =?us-ascii?q?fjZ8kox7a2q42kR5XUzNKtB1LP8e9b5L36+yZlcpBIUe6EMdgKBb7uFnOHRE?= =?us-ascii?q?l/xpU93UIv8y+qjKCXmf5aLVeSwoisOM0SdqkAqShwais7XBdJEAatlo2zhc?= =?us-ascii?q?+NZkL2hgaeNpTIBZcUgrgiyvy5wSEmSNYUekFPOzOPWXca7lyUqeFO0qxli4?= =?us-ascii?q?d1fAGEWxgp3KTkmGf0wMjsBaFWIgPi7hej9Qeh3jcNlJ87uVG8dkig/lneCU?= =?us-ascii?q?rB3GtaaHv6iCdxwhF/cguhWAfbDbccDdRJkbQ/LZFtEPVJ/5JcWzbj03yKvK?= =?us-ascii?q?mAFwL6Sje9ti4TJ9yRr17zpGNvYZtLMQt9a9nt0DEquE3/RGBoWMpmUziCIt?= =?us-ascii?q?yjqje7UliS9U4UXfIBUP8VC2DW7rlH/wjVPPbdjncSEtw=3D=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AdmZ2rKyOicLr7K0D3RVJKrPxm+skLtp133?= =?us-ascii?q?Aq2lEZdPULSK2lfpGV8sjziyWatN9IYgBdpTiBUJPwJk80hqQFnrX5XI3SEz?= =?us-ascii?q?UO3VHJEGgM1/qY/9VvcReOjNK1uZ0QFpSWa+eAQ2SS7/yKnTVQeuxIqLLsnc?= =?us-ascii?q?zY5pa9854Hd3ANV0gU1XYANu/tKDwOeOApP+tcKLOsou584xawc3Ueacq2Ql?= =?us-ascii?q?MfWfLYmtHNnJX6JTYbGh8O8mC1/HKVwY+/NyLd8gYVUjtJz7tn23PCiRbF6q?= =?us-ascii?q?KqtOz+4gPA1lXU849dlLLau5t+7Y23+4sowwfX+0OVjbdaKvm/VfcO0aaSAW?= =?us-ascii?q?MR4ZvxStEbToJOAj3qDziISFDWqnfdOX4Vmg7fIBmj8CPeSQiTfkNhNyKH7r?= =?us-ascii?q?gpKScxonBQzO1UweZF2XmUuIFQCg6FlCPh58LQXxUvjUasp2E++NRjxUC3fL?= =?us-ascii?q?FuIIO5l7Zvt3+90a1waB7S+cQiCq1jHcvc7PFZfReTaG3YpHBmxJipUm4oFh?= =?us-ascii?q?mLT0AesojNugIm0ExR3g8d3ogSj30A/JUyR91N4PnFKL1hkPVLQtUNZaxwCe?= =?us-ascii?q?8dSY+8C3DLQxjLLGWOSG6XWZ0vKjbIsdr68b817OaldNgBy4Yzgo3IVBdCuW?= =?us-ascii?q?s7ayvVeISzNV1wg2bwqUmGLEbQI/Bllu9EU+fHNcnW2AW4OSUTr/c=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BsAAA/P+Fh/5ldJa1aHQEBAQEJARI?= =?us-ascii?q?BBQUBQIFFCAELAYEgATBWB3daNzGIDgOEWWCFDoMCA4ETjyGCMYg5gS4UgRE?= =?us-ascii?q?DTwUEBwEBAQ0BASoBDAoEAQGFBQKDSgIlNAkOAQIEAQEBEgEBBQEBAQIBBgS?= =?us-ascii?q?BCROFOwEEKA2GQgEBAQECAgEKBggNBhMBASwLAQQNARkDAQEBIQEGCSULFAk?= =?us-ascii?q?JAQQOBQgGFIJjgmUDDSEBDp9hAYE6AoofeIEBMoEBgggBAQYEBIE6AoNPGII?= =?us-ascii?q?vBwMGgToBgw2CfgpKSocJJxyBSUSBFAFDVYERSnWCYwEBAhiBDBwEHB4GBwm?= =?us-ascii?q?DGYIukB8BJUYOYA0lEQ4CIC0DCwIeCBUBNw8JAQISBw8fCwuSNI0HgXAPi2+?= =?us-ascii?q?SWgqDRAWFXYMYKIxviVoVg3CMDJdylkEgoQgIDwsLhF4CBAIEBQIOAQEGgWE?= =?us-ascii?q?7gVlwFTuCaVEZD4Vrgl+FVoNxhRSFSnQCNgIGCwEBAwmNZweCPwEB?= X-IronPort-AV: E=Sophos;i="5.88,288,1635206400"; d="txt'?scan'208,217";a="974138155" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Jan 2022 09:20:00 +0000 Received: from mail.cisco.com (xbe-aln-007.cisco.com [173.36.7.22]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 20E9K0rt022963 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for ; Fri, 14 Jan 2022 09:20:00 GMT Received: from xfe-rcd-004.cisco.com (173.37.227.252) 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 03:19:59 -0600 Received: from xfe-aln-005.cisco.com (173.37.135.125) by xfe-rcd-004.cisco.com (173.37.227.252) 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 03:19:59 -0600 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-005.cisco.com (173.37.135.125) 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 03:19:59 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SmQjS0rFV7LtG0Q8yPBE0AXwzohZ8bXsgOfo4NhTs/DIggiAfnglZ7mQ0mneiTma2ApULD2a7tINEbHdhDIyI5AtUw8DT872rcwZG50yrLPiF4IKeA29xd7sdrf8b1ALpDiUQmUKDoRZAMqGxUL02WFYYPEBGmbyFVpN3j+Uknyr5P90tgl9CnwKur6URxYWXI7JCyqpeyM2B4ROmzvgm2s/jONrtNXDFLENb5Jt9TDr1q+opbH3ICP7DSOHo1jPEWpk41MDqse8ITvXYGJBc6aN0zTW3gNXlmq2VZ85LoTwVRrexogccoEFV+1yiZhQKWhAF0bWFO1CLIFR08ZStQ== 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=KzOa3OvA+KxC7/zwrDSnDwEgv0+DiX3jVz8JafcWxnA=; b=drjpszg4fOkGcqItWJ8a4lZLpcFUP9PWyPdrmnO6RDzzald3TaQP1Ayo3U0s1UaH3PjrQOhTTKnRH2h3Y5aIK24Hm7l1KaKoHad74qMgjSXStXwImKQPWoAh9Jvl8VAjs05LLbKSglSLbE51a4+cOx0+G6v8jwDh4pajcCCwO9FKO6eHA9qL3hclevTB8ZCInkWk2cN+cTe6F03uHTu9adE+FZVZKE3WGdg3hTtFXJpP8u3L/UQTkusoTR4a/a5Ao1nPnK6EhVQ1ZCNffqbK9pm9W/Fuq5ru0b4dFm1k6wp4jSo1JDGadcRO1OHSX7PGcuDp37KzDG0ENRNAumFt7Q== 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=KzOa3OvA+KxC7/zwrDSnDwEgv0+DiX3jVz8JafcWxnA=; b=ktdscXksBpLY1hZuWUf+w+m0/clzXxAO1zSQzKJjei3vr1jN6Vgdql+aS4XKd2uXk85lRBjQppomZoM9cJ/Pgv847PdvqHHRnbZ7HI+A63Oy2rwBrtKPwoslTeo4r4bEBWJNOnYw+9ur4jtDRfDwmd9L+REF+sO5jYcOIw+VD/o= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by CY4PR11MB2005.namprd11.prod.outlook.com (2603:10b6:903:2e::18) 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 09:19:57 +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 09:19:57 +0000 From: "Pascal Thubert (pthubert)" To: "ROLL WG (roll@ietf.org)" Thread-Topic: Multiple targets in PDR (Was: [Roll] review of dao-projection -22) Thread-Index: AdgJJyV6ErEZ4KG8SV+3gpNv1SjopA== Date: Fri, 14 Jan 2022 09:19:40 +0000 Deferred-Delivery: Fri, 14 Jan 2022 09:19:07 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes 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: 25b0b2c3-f48e-4a30-0d0e-08d9d73f0869 x-ms-traffictypediagnostic: CY4PR11MB2005:EE_ x-microsoft-antispam-prvs: 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: XjgatV9sIUxWCvWjBk/SD0nH6v3kcLdhA/OY6PsM1Nk5bbyFlvvk+tuUmJ9g2ftGahTFGKSRpWC5Owx94NCsvG+oGbCxpXS5gcUuChwa7fYXjMY2BX60S/j2FZYXUGzuh3dqLQvvrvfoQOApcDjN5NXCsx9gGUBMT7hSXGp9QuFuZ1nWd0zaa+Uv882AiSGT6hP8u3X2YPRg0lL0NIRztwD9lB+xr8IK5L7SqdzrvQIc6Vdz8OhPEn7IEi8BKQgG3H2mLYuFbtvBZCmUOW3CLylzY4izEEFMq1yQ4sXbNYUp2YN5dEIcO5fuJxApX6aaxVmHi0ChAOPKqGi0gjeYJF7S6/aO9NnaAgjbRTHf5pjNZHjCEI0aFb83wY47Hh0IeU/O/g71PMvC95AwWDwPasvJX0o1eofvNF9TV1cLP4B153aYH7u6wcP3aRbC7Odh3qoB6rCrKNNjqKwGEPxlG3jSXv1WejEfY8gr9shGuXfiE3ncg7dR4SiQGxvSlQR56Usf1SjNkRR6XS1MKjoleY6JPQ9BwKGKU10I//GdbFBXKZuJ9rRYQ9kXXX4zM+P/xmkurSi6AAM1eL/IWp2FO6qbXZcJHqPa73U4PfKiNp0F6vN2eEUh53K7DOmzpPpR6TNuFUuIHvlKumLPnEVtKcjhXABqtv7l6OZQadrSQNkVk2O4YVrsJ+YFh0OeMQYjz7yOVT+F9caLJOr7cUk+l8dNL/EEfWLTtuim+CEn+fXy8a2IeFuOUU9pq98PdaRGfgNz/ljhGP5SRQZ4zEKXWz3Hysx/5hhPi45g0x8WNaIIvJvOSeLWpwaXrdXoUH4aec+/UaYfjbU97RrxwFUyQQ== 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)(86362001)(107886003)(4326008)(71200400001)(508600001)(55016003)(30864003)(7696005)(8936002)(38070700005)(38100700002)(966005)(6916009)(6666004)(122000001)(83380400001)(5660300002)(66556008)(66476007)(186003)(8676002)(66574015)(53546011)(26005)(6506007)(99936003)(66446008)(33656002)(52536014)(316002)(64756008)(76116006)(166002)(66946007)(2906002)(9686003)(559001)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?5yHMRYUnOlBuf6hL0AYgwVId813FZzb354jjnmWrA38x76MH/GKsGHsrLS?= =?iso-8859-1?Q?bJZYgTnOsM8bp6+AlmDZva1OZF/al80VCXvoMeSgXXrCtMj88t0D97nhWW?= =?iso-8859-1?Q?1m5KtUE+XrEuj3RGRb71ezrAV3sfxRwSHRRCRuRZAL8Uvce9ghrzVwjd2W?= =?iso-8859-1?Q?eh4TKrFguQpqeIBzqNE62ifGcIjXM8IprxSHsxIUZ3vKPaqcacjqoegTG/?= =?iso-8859-1?Q?tvlmPMVetdvgjgLhGdF7FEXEgKTUrOvPyYFjCQJ6b0CXAvvZxgGN8pArSn?= =?iso-8859-1?Q?9sQxNCU53p2A9Bdyy72Ycr6e8NwS7YN/Jz4N1ouL7Q9v/KatvsLayfXE5M?= =?iso-8859-1?Q?UdtO6rXi9ptWxCv/yV1tZuQY4mrey+FlPhzEyEaThzH7t/Jk3XToR1L7WX?= =?iso-8859-1?Q?i24H8cKo+JagPpnrMFtXbvfhzDWviA6b3Nv2P8Nwa4GnK9ryXmFCQ8yXtL?= =?iso-8859-1?Q?4cwfIILhX3ZyQaawtFOgO0oj8Rra7qgl0rYxx/gx6Dh8kdkz2kc6neZ5di?= =?iso-8859-1?Q?t8r4yUUnUdMgdWJjWiQvoyYAWpg/ELqgIUWlDazrVLNbbS+Qih6iJkVBd0?= =?iso-8859-1?Q?iBS/GdhK7mXwa+GDdB0rnUhyfIqvIAwgAgRWkJ1WmSAuRwCFIeXIUbHUiw?= =?iso-8859-1?Q?53LOYehAatD+6mJ2UsS7oz44OGfnWHsEMwG7NEauhfA+mr572YdKs+qktQ?= =?iso-8859-1?Q?i4QHFyeg6JLBNmoYCTRFLPkhqkUgsc/K1X+9M40F3qKn/FiwNRL6QKsQFr?= =?iso-8859-1?Q?iPWpMtF7QcTy7zn8TbEBQbevNvLwrJU2yQKQlewqjFLueQVdDbJADcmSiB?= =?iso-8859-1?Q?DbKINug4pmMyoljiLOJehK6ZlXMivoo6iDTqVN0ewZLguAZktqTblhcEz+?= =?iso-8859-1?Q?lcg41yKYJEpsi1YNibKt4Ka0zvTwtcRsPAuqnnLNBBanc7hDp9+OSO/NtF?= =?iso-8859-1?Q?naNOiv33JBcqc7rNL70tfMX+ZrzpaXSDkldiibJpCxwZ595HY1znZizln2?= =?iso-8859-1?Q?Tswu18G0U2bKkJPIo9zwYE5JM2sIFEP7xYRc1IQZiyImaUNAq9/YaIJs/0?= =?iso-8859-1?Q?D33Zf5VKpbQqjjkonVMxKN+PMwsxgw1ot4JBuP0Anox6PCPz70931cU3OI?= =?iso-8859-1?Q?a40tRI3TmxcQ9hPTk2c+0q2HF3DW58NmAupMMrIN6Qfc4PSJwTT4jHHj56?= =?iso-8859-1?Q?6kkKXOY5QGVHpj2YSJrxL7rahPJ6sMmBOLne55crzoXpFpY+m4k6giMn4v?= =?iso-8859-1?Q?L/GRJ0oheyhzxbuCG3yMuhph9Qd+EEl7LR2WqLXPBpL7QzuNYOm5okGBUX?= =?iso-8859-1?Q?fIJ53sU0I6hG9YdYeauq0okJrT31Zg7MKV4WWzH/8bdkoS0zTMrTzZxDHt?= =?iso-8859-1?Q?4Bdu6WRGs4QzzaYJYHYry1FBe5JiXLAxiPXhptdxwOl5+TexsHGcRK9MUm?= =?iso-8859-1?Q?LwFiid2OhcVdwF7Ef+krrHN8lwvLQLo4ZlnnDwsr3uwRhkpxSnI7MmVC0P?= =?iso-8859-1?Q?gh7bnyheFpKaDDJojX5W2lPoghBEr+uYss50ucaZWli7x/Fy2NjoBIdLHu?= =?iso-8859-1?Q?XgP9NmIh6Zz6qIcqj2QwivC5lGXyYEKY7dcI+BUshv6ZG/6aeQ1VXIigAN?= =?iso-8859-1?Q?YyYc5fb8l2p4+XPSR+k0GRuaTKzgG5LPcY2R87ubxs2dcsb24BiWRiNUy9?= =?iso-8859-1?Q?xA4DXLGfdkje+e4z1vM=3D?= Content-Type: multipart/mixed; boundary="_004_CO1PR11MB48816B0F65E5A89EE727FCF4D8549CO1PR11MB4881namp_" 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: 25b0b2c3-f48e-4a30-0d0e-08d9d73f0869 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2022 09:19:57.2087 (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: itj2scFrcItI39T/mZRhqovg+TSEwIXHxcH6oItYCsFgM0uaKpjUOyaG+aZLECeAw5JzGjdDa+L/3ieC9y3URg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR11MB2005 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.22, xbe-aln-007.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: [Roll] Multiple targets in PDR (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2022 09:20:08 -0000 --_004_CO1PR11MB48816B0F65E5A89EE727FCF4D8549CO1PR11MB4881namp_ Content-Type: multipart/alternative; boundary="_000_CO1PR11MB48816B0F65E5A89EE727FCF4D8549CO1PR11MB4881namp_" --_000_CO1PR11MB48816B0F65E5A89EE727FCF4D8549CO1PR11MB4881namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all: we had this thread as part of Li's review: About : "5.1 One and only one RPL Target Option MUST be present in the mess= age." [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 tog= ether, Root can only push one Track I->A->B->H. Otherwise, Root may push tw= o Tracks I->A->B and I->F->G->H. If Root cannot computer one Track to multiple RTO, it can resp= onse with a special PDR-ACK Status. [PT] This was done in the interest to simplicity, and yes we can rediscuss= that. We'd need to make decisions on partially successful use cases e.g.,: * What if there's a path to only a subset? Should the root form more th= an one track? * Or deny with your special status but then what can the source do afte= r that? Try all combinations? * What is the best path to one target cannot reach all targets but a lo= wer quality path can? Should we use that one? * Maybe there could be one main target and additional desirable targets= ? In that case the Root could form the track and indicate which of the opti= onal targets are effectively reachable via the track to the main target. [Li] Maybe it depends on implement of PCE? I'd like to keep the flexibilit= y because there is a user case for street lighting. Some controllers(Ingres= s nodes) need to light the street lighting linearly with low-latency. [PT] sure, at the expense of complexity in signaling and processing in the = nodes. We need to be specific on the scenarios and status codes. The PDR f= orms a single Track since the TrackID is provided. I believe it makes sense to ask for more targets since the root can install= a Track for more than one target. Still, signaling is involved and we nee= d a story for all those questions: * What if there's a path to only a subset? Should the root form more th= an one track? * Or deny with your special status but then what can the source do afte= r that? Try all combinations? * What is the best path to one target cannot reach all targets but a lo= wer quality path can? Should we use that one? * Maybe there could be one main target and additional desirable targets= ? In that case the Root could form the track and indicate which of the opti= onal targets are effectively reachable via the track to the main target. Comments welcome! Pascal From: Roll > On Behalf = Of Li Zhao (liz3) Sent: vendredi 14 janvier 2022 2:51 To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] review of dao-projection -22 Hello Pascal, Please find my comments inline. Best regards, Li From: Roll > on behalf = of Pascal Thubert (pthubert) > Date: Friday, January 14, 2022 at 01:31 To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] review of dao-projection -22 Hello Li A great many thanks for your excellent review! Such are much needed at this= time. > [Li] -> Should it be ? > P-DAO 1 signals C=3D=3D>D=3D=3D>E-to-F,G > P-DAO 2 signals A=3D=3D>B=3D=3D>C-to-E,F,G [PT] correct, great catch! > [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 T= rack from egress node. Is PDR-ACK still needed? > In non-storing mode, No-Path P-DAO to ingress node is also en= ough. > But the PDR-ACK Status field makes sense. Is it possible to a= dd this field in No-Path P-DAO? [PT] The no path DAO flow along the reverse path and cleans it; so the end= result would be that the Track is terminated as you figured. So yes, it co= uld be possible to add a status to the no-path DAO but remember that it is = a normal DAO not a completion (IOW not an ack). How could we justify a stat= us in all DAOs? I'm unclear why the async PDR ack is an issue. If the PDR c= an not be served, the track ingress already needs to support a PDR ack that= "terminates" a Track. To clarify that sentence we can say: " The main Root MAY indicate to the Track Ingress that the Track was termi= nated before its time and to do so, it MUST uses an asynchronous PDR-ACK with = an negative status. " Should that be more than a MAY? >>>> [Li] Yes. It's more clear. So PDR-ACK is for original PDR. And for mai= ntain or tear down case, Root should use No-Path P-DAO to terminate P-Route= . Correct? > [Li] -> Is it possible to remove the limitation? It's not flexible If PD= R can only carry one RTO. > For instance in figure 7, if node I requests P-Route to B&H t= ogether, 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 res= ponse with a special PDR-ACK Status. [PT] This was done in the interest to simplicity, and yes we can rediscuss= that. We'd need to make decisions on partially successful use cases e.g.,: * What if there's a path to only a subset? Should the root form more th= an one track? * Or deny with your special status but then what can the source do afte= r that? Try all combinations? * What is the best path to one target cannot reach all targets but a lo= wer quality path can? Should we use that one? * Maybe there could be one main target and additional desirable targets= ? In that case the Root could form the track and indicate which of the opti= onal targets are effectively reachable via the track to the main target. >>>> [Li] Maybe it depends on implement of PCE? I'd like to keep the flexi= bility because there is a user case for street lighting. Some controllers(I= ngress nodes) need to light the street lighting linearly with low-latency. > [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 tre= at 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 simplifi= cation. 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 an= d reverse direction. Can it indicate symmetrical? In layer 3, receiving DIO/NS messages from each other ind= icate symmetrical? > [Li] -> Confuse with this claim. Is it a MUST NOT if root wants to send n= otification to the requesting node when those changes happen. [PT] There's no protocol element to "send notification to the requesting no= de when those changes happen". So it's hard to say that the root MUST NOT d= o something that it cannot do. Reworded to " Note that there is no protocol element to notify to the requesting Tr= ack Ingress when changes happen deeper down the Track, so they are transp= arent to the Track Ingress. If the main Root cannot maintain an expected se= rvice level, then it needs to tear down the Track completely. " > [Li] -> Can you add some description for the collision case? E.g., node t= rusts itself than Root. [PT] I reworded to " = In a particular deployment where PDR are not used, a portion of the namespace can be administrati= vely delegated to the main Root, meaning that the main Root is authoritativ= e for assigning the TrackIDs for the Tracks it creates.. " [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 f= rom DAO. [PT] Done; I added a section for the P-DAO-ACK > [Li] -> Profile 0 is the Legacy support of [RPL] Non-Storing Mode. I= 'm confuse about "this enables to use Storing Mode to reduce the size of th= e Source Route Header in the most common LLN deployments." [PT] I really meant Profile 1 enables... Changing that. I guess that's it ! I submitted -23 with this, please have a look at https://www.ietf.org/rfcdi= ff?url2=3Ddraft-ietf-roll-dao-projection-23 Again many thanks! Pascal From: Roll > On Behalf = Of Li Zhao (liz3) Sent: mercredi 12 janvier 2022 10:51 To: Routing Over Low power and Lossy networks > 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=3D=3D>D=3D=3D>E-to-F,G P-DAO 2 signals A=3D=3D>B=3D=3D>C-to-C,F,G [Li] -> Should it be ? P-DAO 1 signals C=3D=3D>D=3D=3D>E-to-F,G P-DAO 2 signals A=3D=3D>B=3D=3D>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 REC= OMMENDED that the nodes involved in a Track =3D=3D=3Dmantain=3D=3D=3D multi= ple 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 use= s diverse source route paths to retry similar messages =3D=3D=3Dot=3D=3D=3D= the nodes in the Track.=B6 [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 childre= n. =3D=3D=3D=3Dxref target=3D'RFC6550'/>=3D=3D=3D=3D states that: [Li] -> Typo for "xref target=3D'RFC6550'/>". Why is flag named as "D"? Th= ere is no D in "Projected Routes Support"... 5.1 The Root may use an asynchronous PDR-ACK with an negative status to ind= icate 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 egre= ss 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 s= pecial 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, i= f 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 hap= pen. [Li] -> Confuse with this claim. Is it a MUST NOT if root wants to send not= ification 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 i= t creates without collision. [Li] -> Can you add some description for the collision case? E.g., node tru= sts itself than Root. 6.4.1 In both cases the Track Ingress is the owner of the Track, and it gen= erates 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 f= rom 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 Rou= te Header in the most common LLN deployments. [Li] -> Profile 0 is the Legacy support of [RPL] 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 --_000_CO1PR11MB48816B0F65E5A89EE727FCF4D8549CO1PR11MB4881namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

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

 

About : “5.1 One and only one RPL Target Option MUST b= e 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 toge= ther, 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 resp= onse with a special PDR-ACK Status.

 

[PT]  This was done in the interest to simplicity, and = yes we can rediscuss that.

We’d need to make decisions on partially successful us= e cases e.g.,:

  • Wh= at if there’s a path to only a subset? Should the root form more than= one track?
  • Or deny with your special status but then what = can the source do after that? Try all combinations?
  • What is the best path to one target cannot reach all targets but a lowe= r quality path can? Should we use that one?
    • Mayb= e there could be one main target and additional desirable targets? In that = case the Root could form the track and indicate which of the optional targets are effectively reachable via the track to t= he main target.

 

[Li] Maybe it depends on implement of PCE?  I’d l= ike to keep the flexibility because there is a user case for street lightin= g. Some controllers(Ingress nodes) need to light the street lighting linearly with low-latency.

 

[PT] sure, at the expense of complexity in signaling and pro= cessing in the nodes. We need to  be specific on the scenarios and sta= tus codes. The PDR forms a single Track since the TrackID is provided.

 

 

I believe it makes sense to ask for more targets since the r= oot can install a Track for more than one target. Still,  signaling is= involved and we need a story for all those questions:

  • Wh= at if there’s a path to only a subset? Should the root form more than= one track?
  • Or deny with your special status but then what = can the source do after that? Try all combinations?
  • What is the best path to one target cannot reach all targets but a lowe= r quality path can? Should we use that one?
    • Mayb= e there could be one main target and additional desirable targets? In that = case the Root could form the track and indicate which of the optional targets are effectively reachable via the track to t= he main target.

 

Comments welcome!

 

Pascal

 

From:= Roll <ro= ll-bounces@ietf.org> On Behalf Of Li Zhao (liz3)<= br> Sent: vendredi 14 janvier 20= 22 2:51
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org= >
Subject: Re: [Roll] review o= f dao-projection -22

 

Hello Pascal,

 

Please find my comments inline.

 

Best regards,

Li

 

From: Roll <roll-bounces@ie= tf.org> on behalf of Pascal Thubert (pthubert) <pthubert=3D40cisco.com@dmarc.ietf.org&g= t;
Date: Friday, January 14, 20= 22 at 01:31
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org= >
Subject: Re: [Roll] review o= f dao-projection -22

Hello Li

 

A great many thanks for your excellent review! Such are much= needed at this time.

 

> [Li] ->  Should it be ?

>          &= nbsp;  P-DAO 1 signals C=3D=3D>D=3D=3D>E-to-F,G

>          &= nbsp;  P-DAO 2 signals A=3D=3D>B=3D=3D>C-to-E,F,G

[PT] correct, great catch!

 

 

> [Li] -> What's the difference between negative statu= s PDR-ACK and No-Path P-DAO in section 6.5?  And when to use asynchron= ous PDR-ACK?

>          &= nbsp;  In storing mode, root should use No-Path P-DAO to tear down Tra= ck from egress node. Is PDR-ACK still needed?

>         &n= bsp;   In non-storing mode, No-Path P-DAO to ingress node is also= enough.

>          &= nbsp;  But the PDR-ACK Status field makes sense. Is it possible to add= this field in No-Path P-DAO?

 

[PT]  The no path DAO flow along the reverse path and c= leans it; so the end result would be that the Track is terminated as you fi= gured. So yes, it could be possible to add a status to the no-path DAO but remember that it is a normal DAO not a compl= etion (IOW not an ack). How could we justify a status in all DAOs? I’= m unclear why the async PDR ack is an issue. If the PDR can not be served, = the track ingress already needs to support a PDR ack that ”terminates” a Track.<= /p>

 

To clarify that sentence we can say:

“

   The main Root MAY indicate to the Track Ingress= that the Track was terminated

   before its time and to do so, it MUST uses an a= synchronous PDR-ACK with an

   negative status.

“

Should that be more than a MAY?

 

>>>> [Li] Yes. It’s more clear. So PDR-ACK= is for original PDR. And for maintain or tear down case, Root should use N= o-Path P-DAO to terminate P-Route. Correct?

 

 

> [Li] -> Is it possible to remove the limitation? &nb= sp;It’s not flexible If PDR can only carry one RTO.=

>          &= nbsp;  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, Roo= t may push two Tracks I->A->B and I->F->G->H.

>         &n= bsp;   If Root cannot computer one Track to multiple RTO, it can = response with a special PDR-ACK Status.

 

[PT]  This was done in the interest to simplicity, and = yes we can rediscuss that.

We’d need to make decisions on partially successful us= e cases e.g.,:

  • Wh= at if there’s a path to only a subset? Should the root form more than= one track?
  • Or deny with your special status but then what = can the source do after that? Try all combinations?
  • What is the best path to one target cannot reach all targets but a lowe= r quality path can? Should we use that one?
    • Mayb= e there could be one main target and additional desirable targets? In that = case the Root could form the track and indicate which of the optional targets are effectively reachable via the track to t= he main target.

 

>>>> [Li] Maybe it depends on implement of PCE? =  I’d like to keep the flexibility because there is a user case f= or street lighting. Some controllers(Ingress nodes) need to light the street lighting linearly with low-latency.

 

 

> [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 receiv= ing 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 goo= d 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 mes= sages from each other indicate symmetrical?

 

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

 

[PT] There’s no protocol element to “send notification to the reque= sting node when those changes happen”. So it’s hard to say that= the root MUST NOT do something that it cannot do. Reworded to

 

“

      Note that there is no protoco= l element to notify to the requesting Track

      Ingress when changes hap= pen deeper down the Track, so they are transparent=

      to the Track Ingress. If the = main Root cannot maintain an expected service

      level, then it needs to tear = down the Track completely.

“

 

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

 

[PT] I reworded to

“

          =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =          In a particular deployment=

     where PDR are not used, a portion o= f the namespace can be administratively

     delegated to the main Root, meaning= that the main Root is authoritative for

     assigning the TrackIDs for the Trac= ks it creates..

“

 

[Li] ->  Is there any difference between P-DAO-ACK a= nd normal DAO-ACK? E.g. any flags?  Normally, root won't receive any D= AO-ACK from nodes.

Is it possible to add flag to= distinguish P-DAO-ACK from DAO-ACK as P-DAO from DAO.

 

[PT] Done; I added a section for the P-DAO-ACK

 

> [Li] -> = Profile 0 is the Legacy support of [RPL] Non-Storing Mode. I’m confuse about “this enables to use Storing Mode to r= educe the size of the Source Route Header in the most common LLN deployment= s.”

 

[PT] I really meant Profile 1 enables… Changing that.<= o:p>

 

I guess that’s it !

 

I submitted -23 with this, please have a look at http= s://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-dao-projection-23

 

Again many thanks!

 

Pascal

 

From:= Roll <ro= ll-bounces@ietf.org> On Behalf Of Li Zhao (liz3)<= br> Sent: mercredi 12 janvier 20= 22 10:51
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org= >
Subject: [Roll] review of da= o-projection -22

 

Hello Authors,

 

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

 

3.5.2 Using Non-Storing Mode joining Tracks

P-DAO 1 signals C=3D=3D>D= =3D=3D>E-to-F,G

P-DAO 2 signals A=3D=3D>B= =3D=3D>C-to-C,F,G

 

   [Li] ->  Should it be ?

P-DAO 1 signals C=3D=3D>D= =3D=3D>E-to-F,G

P-DAO 2 signals A=3D=3D>B= =3D=3D>C-to-E,F,G

 

    Otherwise RIBs in A cannot include destin= ation to E.

 

4.1. Extending RFC 6550

To ensure that the PDR and P-DAO messages can flow at most t= imes, it is RECOMMENDED that the nodes involved in a Track =3D=3D=3Dmantain= =3D=3D=3D 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 si= milar messages =3D=3D=3Dot=3D=3D=3D the nodes in the Track.=B6

   

[Li] -> Typo for “mantain” and “ot̶= 1;?

 

4.1.6.

This specification defines a new flag "Projected Routes= Support" (D).

The DODAG Configuration option is copied unmodified from par= ents to children. =3D=3D=3D=3Dxref target=3D'RFC6550'/>=3D=3D=3D=3D &nbs= p;states that:

 

[Li] -> Typo for “xref target=3D'RFC6550'/>̶= 1;.  Why is flag named as “D”? There is no D in "Proj= ected Routes Support"…

 

 

5.1 The Root may use an asynchronous PDR-ACK with an negativ= e 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 neede= d?

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-Pat= h P-DAO?

 

 

5.1 One and only one RPL Target Option MUST be present in th= e 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 T= rack to multiple RTO, it can response with a special PDR-ACK Status.

 

 

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

 

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

 

 

6.2  There is no notification to the requesting node wh= en 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 happe= n.

 

 

 

6.3 In a particular deployment where PDR are not used, the n= amespace can be delegated to the main Root, which can assign the TrackIDs f= or the Tracks it creates without collision.

 

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

 

 

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

 

[Li] ->  Is there any difference between P-DAO-ACK a= nd normal DAO-ACK? E.g. any flags?  Normally, root won't receive any D= AO-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 [<= /font>RPL] Non-Storing Mode. I’m confuse about “this enables to use Storing Mode to r= educe the size of the Source Route Header in the most common LLN deployment= s.”

 

 

 

Best regards,

Li

 

 

 

 

 

 

 

 

 

 

--_000_CO1PR11MB48816B0F65E5A89EE727FCF4D8549CO1PR11MB4881namp_-- --_004_CO1PR11MB48816B0F65E5A89EE727FCF4D8549CO1PR11MB4881namp_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=127; creation-date="Fri, 14 Jan 2022 08:18:56 GMT"; modification-date="Fri, 14 Jan 2022 09:19:40 GMT" Content-ID: Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClJvbGwgbWFp bGluZyBsaXN0DQpSb2xsQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3JvbGwNCg== --_004_CO1PR11MB48816B0F65E5A89EE727FCF4D8549CO1PR11MB4881namp_-- From nobody Fri Jan 14 02:20:40 2022 Return-Path: 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 ; 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 ; 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 ; 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: =?us-ascii?q?A0A3BgCZTeFh/4oNJK1agQmBWYEhMVYHd1o3MYgOA4U5h?= =?us-ascii?q?Q6DAoEWjyGCMYg5gS4UgREDVAsBAQENAQE3CgQBAYUFAoNKAiU0CQ4BAgQBA?= =?us-ascii?q?QEBAwIDAQEBAQUBAQUBAQECAQYEgQkThTsBBCgNhkIBAQEBDwYVBhMBATcBE?= =?us-ascii?q?QEZBAEBIQE/HQkBBA4FCBqCY4IOVwMuAQ6fXwGBOgKKH3iBATKBAYIIAQEGB?= =?us-ascii?q?ASFCxiCNgMGgTqDDoJ+VEqHMByBSUSBFAFDVYERSnWCYwICgSQcBBwkB4Mig?= =?us-ascii?q?i6QICVGDmANNg4CTQMrHjcKDgECEgcPHwufRoFwnlgKg0SWEYlaFZQck1KWQ?= =?us-ascii?q?SChCBcLC4ReAgQCBAUCDgEBBoFhO4FZcBWDJFEZD4Vrgl+JR4UUhUp0AjYCB?= =?us-ascii?q?gsBAQMJjWcHgj8BAQ?= 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 ; 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)" To: "ROLL WG (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: 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: 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: =?iso-8859-1?Q?x9DhbooAjW/cZc8QuJiYJCgZ2GyJHq98CP8ruTbZ+Ax4d5QsG7UvxsH+jB?= =?iso-8859-1?Q?dHYogN5N65OGOktzAhwqMLuUxQvBb4+I5B1tRH1lFwlSmNPCJjCZCrsO0i?= =?iso-8859-1?Q?ejzzBXosck+J0iFP5EziLQiOv9GmbwQO30qwhO/QRvzo1dBmN8ZC18qWA0?= =?iso-8859-1?Q?aNuNLCcTbl7f+vX3tKzVmLmRpcyXbK4k6d6LhWFrO62AUstieHtZJjE73x?= =?iso-8859-1?Q?4oBcYaLuMUhf9Dl90JUMnOslOy6oE1UFZuQcT7a1TfG9qoK9t5f8ko1pND?= =?iso-8859-1?Q?EgLpVXCz0ej5LfLQD9hBqkFTd+1z1B/dj4T5p105Z7iGTA9EzL+KTr9P1x?= =?iso-8859-1?Q?nEfJwChdqX1FW5pXpZj/WNASFi24UFpuHgHlmOneqwevBlHD+jTFZ/xMLT?= =?iso-8859-1?Q?QQXMVfYWLoKB/PvS23ZRMzvGZ5HlLrQsGpRFL2Jz+5hH978ujHM+XR4WW6?= =?iso-8859-1?Q?oD/sYR3GfpEpo7CkXsWf50nb/1BW6P+NLXedXLW6Uyr56L1Rbb1cjQ3CY9?= =?iso-8859-1?Q?bpYCVETHhanDhIbfUw7RC6vlHqjW3LXOcWo19+NlTZ0cbZSDKN1bjFKA7X?= =?iso-8859-1?Q?5JwpTeHgcEy735mke2eawDUYXLqP8FHjcrWIoeBkOkh/qqt5KCKJbLgIzT?= =?iso-8859-1?Q?vv6jZFQcUuCO5zaz09AMEi6uISWraOAM2PtaHC5NitgwGvvdEBARVTXU9x?= =?iso-8859-1?Q?8OWKOaDpSTJfmFq5CnxhQ1DvwQPWtsYBNlcIAZQ/Rr50SxBE02PZv6lwfn?= =?iso-8859-1?Q?vO3Y1wjN7dwUy5U9qgZYb6gBNi6AqFsJKtVevTVXbPEoYFhNeoHVqBs9Wo?= =?iso-8859-1?Q?5xxSxxzkIXn8r2fmgcsK4W/voHzkoqV19uDrB2VUEyPMIHjic5WB3BRjg4?= =?iso-8859-1?Q?SV+GEo3bnyYB+eGg44mB9cWCscFdqtWnhOmO18NBQwDwEPCEEqUsDCXFkn?= =?iso-8859-1?Q?gTcukBVGcC7AnPYC0PvUHOBnf2Mt7qZ3vrNerRknxkhheEz0v038ZDHwiL?= =?iso-8859-1?Q?J+mZmb0oCOvS7Fk8SnoP4V4IefUheuL84DQH5dZwrWneiyQNlCcYOcnscA?= =?iso-8859-1?Q?LT1GPhhkiZc0G6fJpbqRd57k2Zt05rRMcS0CDJDjAIPNafkGNHwIwceklo?= =?iso-8859-1?Q?Ac5N/Xf3JcNJyZLmnFbRTrZEbatwcIHbK/FQTg0VXkVUZfdFUF0kuNlisy?= =?iso-8859-1?Q?L+dGzFPweKDpTvcOJ+xjhdJsw70Bt3Jn8OejK9Cqje9lzEkUZg/+pIGQxU?= =?iso-8859-1?Q?vdpVbaTh/WkMkHfSiLQDzh5uH9NtZgskai3MVbu4GQGMtPTToFoxUuyVdT?= =?iso-8859-1?Q?wYbVaN9CwUEgTgtICAcUpEAWdNix1yiRq38kPPBTZvmB0bGRxDUxMrtIv0?= =?iso-8859-1?Q?0yJrZJrPiH5DRlnDTxUOuOADbMPdaW1h6g7jF3NdmBvJk5e6+IgmCsT95o?= =?iso-8859-1?Q?e2BjD2YWo4PlaTkXcj1TDwE1YAB8f0FS4mPGXESRDFSkNOeNzlvl1DptNc?= =?iso-8859-1?Q?cRvDnsRlsobigE+L+Kos9VMSavqcMzrcyM6Unnxd3w0LoJNPtRVrKX/2LK?= =?iso-8859-1?Q?vll1mcF1s755WCUwWqjcTwEGKSFgTlrvRPw8rkH4v0/a8X87tboYilMGna?= =?iso-8859-1?Q?2WdaHlSe0if5dyQeGQLE1ry0lxJ2SaqTs7qPPcvpX6gWFMJC2qzINESqMB?= =?iso-8859-1?Q?uro7/c+iUdBOSGsucH8=3D?= 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2022 10:20:39 -0000 --_000_CO1PR11MB488196A1C6DA491569F8C523D8549CO1PR11MB4881namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 a= ddress needs report the SIO, and the Root will assume symmetry." [Li] -> Is it possible to add a flag to indicate the symmetry? Otherwise, i= f 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 simplifi= cation. 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 rev= erse direction. Can it indicate symmetrical? In layer 3, receiving DIO/NS messages from each other ind= icate 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 i= ncrement 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 e= xpected from the Root/ PCE about path computation when it is set or not set= . Suggestions welcome; Pascal From: Roll On Behalf Of Li Zhao (liz3) Sent: mercredi 12 janvier 2022 10:51 To: Routing Over Low power and Lossy networks 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=3D=3D>D=3D=3D>E-to-F,G P-DAO 2 signals A=3D=3D>B=3D=3D>C-to-C,F,G [Li] -> Should it be ? P-DAO 1 signals C=3D=3D>D=3D=3D>E-to-F,G P-DAO 2 signals A=3D=3D>B=3D=3D>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 REC= OMMENDED that the nodes involved in a Track =3D=3D=3Dmantain=3D=3D=3D multi= ple 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 use= s diverse source route paths to retry similar messages =3D=3D=3Dot=3D=3D=3D= the nodes in the Track.=B6 [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 childre= n. =3D=3D=3D=3Dxref target=3D'RFC6550'/>=3D=3D=3D=3D states that: [Li] -> Typo for "xref target=3D'RFC6550'/>". Why is flag named as "D"? Th= ere is no D in "Projected Routes Support"... 5.1 The Root may use an asynchronous PDR-ACK with an negative status to ind= icate 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 egre= ss 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 s= pecial 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, i= f 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 hap= pen. [Li] -> Confuse with this claim. Is it a MUST NOT if root wants to send not= ification 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 i= t creates without collision. [Li] -> Can you add some description for the collision case? E.g., node tru= sts itself than Root. 6.4.1 In both cases the Track Ingress is the owner of the Track, and it gen= erates 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 f= rom 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 Rou= te Header in the most common LLN deployments. [Li] -> Profile 0 is the Legacy support of [RPL] 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 --_000_CO1PR11MB488196A1C6DA491569F8C523D8549CO1PR11MB4881namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

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

 

 

About “5.4 only the router with the lowest Interface I= D 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 symm= etry? Otherwise, if A chooses B as sibling, but B doesn't choose A as sibli= ng, 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 goo= d 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 mes= sages from each other indicate symmetrical

 

[PT] There’s a nuance between bidir and symmetrical.&n= bsp; Maybe the ping works but the link quality is very different in both di= rections. 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 tha= t 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 doe= s 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-bo= unces@ietf.org> On Behalf Of Li Zhao (liz3)<= br> Sent: mercredi 12 janvier 20= 22 10:51
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org>
Subject: [Roll] review of da= o-projection -22

 

Hello Authors,

 

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

 

3.5.2 Using Non-Storing Mode joining Tracks

P-DAO 1 signals C=3D=3D>D= =3D=3D>E-to-F,G

P-DAO 2 signals A=3D=3D>B= =3D=3D>C-to-C,F,G

 

   [Li] ->  Should it be ?

P-DAO 1 signals C=3D=3D>D= =3D=3D>E-to-F,G

P-DAO 2 signals A=3D=3D>B= =3D=3D>C-to-E,F,G

 

    Otherwise RIBs in A cannot include destin= ation to E.

 

4.1. Extending RFC 6550

To ensure that the PDR and P-DAO messages can flow at most t= imes, it is RECOMMENDED that the nodes involved in a Track =3D=3D=3Dmantain= =3D=3D=3D 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 si= milar messages =3D=3D=3Dot=3D=3D=3D the nodes in the Track.=B6

   

[Li] -> Typo for “mantain” and “ot̶= 1;?

 

4.1.6.

This specification defines a new flag "Projected Routes= Support" (D).

The DODAG Configuration option is copied unmodified from par= ents to children. =3D=3D=3D=3Dxref target=3D'RFC6550'/>=3D=3D=3D=3D &nbs= p;states that:

 

[Li] -> Typo for “xref target=3D'RFC6550'/>̶= 1;.  Why is flag named as “D”? There is no D in "Proj= ected Routes Support"…

 

 

5.1 The Root may use an asynchronous PDR-ACK with an negativ= e 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 th= e 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 T= rack to multiple RTO, it can response with a special PDR-ACK Status.

 

 

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

 

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

 

 

6.2  There is no notification to the requesting node wh= en 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 happe= n.

 

 

6.3 In a particular deployment where PDR are not used, the n= amespace can be delegated to the main Root, which can assign the TrackIDs f= or the Tracks it creates without collision.

 

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

 

 

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

 

[Li] ->  Is there any difference between P-DAO-ACK a= nd normal DAO-ACK? E.g. any flags?  Normally, root won't receive any D= AO-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] Non-Storing Mode. I’m confuse about “this enables to use Storing Mode to r= educe the size of the Source Route Header in the most common LLN deployment= s.”

 

 

 

Best regards,

Li

 

 

 

 

 

 

 

 

 

 

--_000_CO1PR11MB488196A1C6DA491569F8C523D8549CO1PR11MB4881namp_-- From nobody Mon Jan 17 07:39:06 2022 Return-Path: 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 9B4AE3A1075 for ; Mon, 17 Jan 2022 07:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com 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 rnjPj5aAm1NY for ; Mon, 17 Jan 2022 07:39:00 -0800 (PST) Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA3343A1072 for ; Mon, 17 Jan 2022 07:38:59 -0800 (PST) Received: by mail-yb1-xb2d.google.com with SMTP id v186so47001564ybg.1 for ; Mon, 17 Jan 2022 07:38:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20210112; h=mime-version:from:date:message-id:subject:to:cc; bh=uSjf0y8++si3TXq8USY17QCgCWK7aOp4Ul4prdfSvUY=; b=qkQfEFYdsP5FdZHDEHxAU/RgZ0TQXo+kG1qVV1B1Kn9F/96gSivOoTIxVI+6jcC4BS 4nLESoGwyqWJH3nskef/b45LW8Q9ZUx76DlRTQDu0LOtnKDLD6iw/IVjeYwSi/VOBvUY TMaMoGDXHKJlEFqFYaify+vu3LbAxjQRCAvoH1BRJH2XIL8JVdr2YbIoq5UZoeZjlGZw QR03+osWBlGtIasiPXve3TmyOAXPn038sdxP17gcO4dXBZFLIHO4IjHpYC5141DDN67L Ea1EjJWh83w1yvMAcRnSs1BiCBA0amthnzwhOa8kDuOqGOpdBGqVCEOQme+h4ru1/+/Z GxOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=uSjf0y8++si3TXq8USY17QCgCWK7aOp4Ul4prdfSvUY=; b=Oto3aUA0PbhXHX6s9TRvnq5oof+Fv1peye+gNWGRP+gaSK5hU0OGu0obnuwCz/dXxl sTPX41ktVlftk9V6VIQe+DKsoMm3VszgQGvf2FslDakyD8IJes5hhRL1IvnLCU+hCge3 jURO/ZRCms/JSEDLwnMxqXpUwAIFx5qoyzjuJPR/Lw26hJJB6R95COYSIk5doDkO/y1P iGY8z6dlqBkfdQDj6SYO6mGu34D9RoBW72QLpT9cve6pHrVsQorJB8jcFraSUlDa269I 6lOt4KozOYCIjKZ60rTWwv7vt68yyszUraivL5R3zuPuuJO13gfRK/r3U7wZPI50S1Qd LPCA== X-Gm-Message-State: AOAM530jTDDrBpmU3d5tpvISQ05lo7llL+QWUmIBFXrOHhjFWSQhxtiC 2Excnyj3UbSGLdwCrqc7yk9JSqKZHMgucQR+a2fhe89pBoo= X-Google-Smtp-Source: ABdhPJybCnAGj6JgxTO1qbhsZPvW/1dYV00WWCJwyV+TfEBpG54J7rKnrlVsehkIdg1eTjigD8Zd77cY0+pJgCxMWz0= X-Received: by 2002:a25:b227:: with SMTP id i39mr18973300ybj.682.1642433937500; Mon, 17 Jan 2022 07:38:57 -0800 (PST) MIME-Version: 1.0 From: Ines Robles Date: Mon, 17 Jan 2022 17:38:21 +0200 Message-ID: To: roll Content-Type: multipart/alternative; boundary="000000000000696e0c05d5c8f39a" Archived-At: Subject: [Roll] Roll at IETF 113 - Request to fill a survey X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2022 15:39:05 -0000 --000000000000696e0c05d5c8f39a Content-Type: text/plain; charset="UTF-8" Dear all, In order to help us assess the need for a ROLL session at the IETF 113 meeting, would you please fill the following form by 30th January. https://www.surveymonkey.com/r/TN6XNR8 (estimated time to fill it: 2 minutes) Thank you in advance, Ines and Dominique --000000000000696e0c05d5c8f39a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

In order to help us assess the need for = a ROLL session at the IETF 113 meeting, would you please fill the following= form by 30th January.

https://www.surveymonkey.com/r/TN6XNR8 (estimated time to fill it= : 2 minutes)

Thank you in advance,

Ines and Dominique=C2=A0
--000000000000696e0c05d5c8f39a-- From nobody Mon Jan 17 07:44:37 2022 Return-Path: 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 2B4903A10E2 for ; Mon, 17 Jan 2022 07:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com 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 07JsvPjdzMc1 for ; Mon, 17 Jan 2022 07:44:31 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D5443A10E4 for ; Mon, 17 Jan 2022 07:44:31 -0800 (PST) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfedar24.francetelecom.fr (ESMTP service) with ESMTPS id 4Jcx6P1yhVz5vf8 for ; Mon, 17 Jan 2022 16:44:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1642434269; bh=Wd0RsB+IfOrN2+252KqJ6x/eMZaS+Yigu77PkyKt1VQ=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=gdm6APKYVsCYDDwYV+tlkuVaS7MH+WddCf6JLw8sbu37ypv0/ack9jQ7zpJYFkbeu Yw2XKrIfoyPKJdD1PIzB09cX5fg9VDLkcc45OBkCspyTVGaLUS9/8TxU/CQEthS27/ te8CItMg+lFBr07RIDrW8Iip6p8w5BJ1Gb3VE2TIyy7D/lRjPp/m1zrpZI8n+VlQYc LbH74FU18Mirp/yzaJWDlHmUny37t779Mdxtg8iGZpJz8S4uEERgcHj5O07p6XemxE KMzW3AMXVMkBu/735YUDMrgGHYejYAFglICBSXIUVqCR+5+GcH/3Yu6SPlM5pKwAW3 Y/X2hP6Nv/uvQ== From: To: roll Thread-Topic: Call for adoption of " RNFD: Fast border router crash detection in RPL" Thread-Index: AdgLt8z6nGBxALo4Q5GkBp5G6uK8VQ== Date: Mon, 17 Jan 2022 15:44:28 +0000 Message-ID: <14433_1642434269_61E58EDD_14433_392_1_1dd1e18428384bff9514ff4919cec3d9@orange.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.115.26.50] Content-Type: multipart/alternative; boundary="_000_1dd1e18428384bff9514ff4919cec3d9orangecom_" MIME-Version: 1.0 Archived-At: Subject: [Roll] Call for adoption of " RNFD: Fast border router crash detection in RPL" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2022 15:44:36 -0000 --_000_1dd1e18428384bff9514ff4919cec3d9orangecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear ROLL WG, First of all, our best wishes to you and your loved ones for 2022, hoping e= veryone is safe! Let's hope that this year will allow us to meet in person again and revive = the collaborative momentum. At the IETF112 ROLL session, we discussed the "RNFD: Fast border router cra= sh detection in RPL" draft (draft-iwanicki-roll-rnfd-01). There was no objection among the attendees to adopt the draft as a WG docum= ent, an several participants expressed their interest in the problem addres= sed. We understand that the solution to the problem might be improved furth= er with the WG' s participation. This mail starts a 2 week call for adoption for "RNFD: Fast border router c= rash detection in RPL". Please express any objections or your support in that time frame, letting u= s know if you'd be willing to contribute work or review the draft. Best regards Ines & Dominique ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_1dd1e18428384bff9514ff4919cec3d9orangecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear ROLL WG,=

 

First of all, our best wishes t= o you and your loved ones for 2022, hoping everyone is safe!

Let’s hope that this year= will allow us to meet in person again and revive the collaborative momentu= m.

 

At the IETF112 ROLL session, we= discussed the “RNFD: Fast border router crash detection in RPL”= ; draft (draft-iwanicki-roll-rnfd-01).

There was no objection among th= e attendees to adopt the draft as a WG document, an several participants ex= pressed their interest in the problem addressed. We understand that the sol= ution to the problem might be improved further with the WG’ s participation.

 

This mail starts a 2 week ca= ll for adoption for “RNFD: Fast border router crash detection in RPL&= #8221;.

Please express any objections o= r your support in that time frame, letting us know if you’d be willin= g to contribute work or review the draft.

 

Best regards<= /p>

 

Ines & Dominique 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_1dd1e18428384bff9514ff4919cec3d9orangecom_-- From nobody Mon Jan 17 08:05:20 2022 Return-Path: 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 EEF493A122E for ; Mon, 17 Jan 2022 08:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.595 X-Spam-Level: X-Spam-Status: No, score=-9.595 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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=MH3oMmXv; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=FZd4bOty 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 XieRnpUts0ak for ; Mon, 17 Jan 2022 08:05:14 -0800 (PST) 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 D52633A122B for ; Mon, 17 Jan 2022 08:05:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12379; q=dns/txt; s=iport; t=1642435513; x=1643645113; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=qM19qR+MWpzypUHWXd1gVCfxx9qzr3ml/1tWw1qqY7U=; b=MH3oMmXvT5jfuRuIPS5edGIkurnWKrBjH414l68cc4ksFo+d/LqFkJDt QOJILRaWuWDNOD1FMMcTqKPmX7AdeocXU3izwrhMylXpmv0JW96nT7pvo NIbwe9jDN0XCtZPe7J9ViwA/BFbZcrmJfIsTyTP/zRbUpi+F81IuHTy+I 4=; X-IPAS-Result: =?us-ascii?q?A0AVAQBKk+Vhl5tdJa1agQmBWYEhMVZ+WjcxiA4DhTmFD?= =?us-ascii?q?l2CJQOWEIUOgS4UgREDVAsBAQENAQFBBAEBhQUCg0oCJTQJDgECBAEBAQEDA?= =?us-ascii?q?gMBAQEBBQEBBQEBAQIBBgQUAQEBAQEBAQEkBgwFDjeFaA2GQgEBAQEDEgsQE?= =?us-ascii?q?wEBOA8CAQgRBAEBLzIdCAEBBBMIEweCYgGCDlcDLgGgBQGBOgKKH3iBM4EBg?= =?us-ascii?q?ggBAQYEBIUNGII3CYE6gw6EHIcJJxyBSUSBFUOCZz6ECwUBEQIBIoNNgi6RI?= =?us-ascii?q?mMEFAcoHUsrQhA+JwM6kV+NMI1vklsKg0WfbhWDcIwPl3KWQqY2AgQCBAUCD?= =?us-ascii?q?gEBBoFhOWtwcBWDJFEZD445HoM6il50OAIGCwEBAwmQLQEB?= IronPort-PHdr: A9a23:N50w1R3v5dcDCPWwsmDPr1BlVkEcU/3cMg0U788hjLRDOuSm8o/5N UPSrfNqkBfSXIrd5v4F7oies63pVWEap5rUtncEfc9AUhYfgpAQmAotSMeOFUz8KqvsaCo3V MRPXVNo5Te1K09QTc3/fFbV5Ha16G16Jw== IronPort-Data: A9a23:NRUtnKhUDYc0nqE2T9kt+WkYX161ERAKZh0ujC45NGQN5FlHY01je htvDDrSb6qIZTSgfd1yPI23px8H7ZDQyYJjHAs6pSlnRX5jpJueD7x1DKtf0wB+jyHnZBg6h ynLQoCYdKjYdpJfz/uUGuCJQUNUjclkfZKhTr6UUsxNbVU8En150Es8w7dRbrNA2LBVPSvc4 bsenOWHULOV82Yc3rU8sv/rRLtH5ZweiRtA1rAMTakjUGz2yxH5OKkiyZSZdBMUdGX78tmSH I4vxJnhlo/QEoxE5tmNyt4XeWVSKlLe0JTnZnd+A8CfbhZ+SiMaioUmCKcFb01ugjDXuOJOy Y5wrseSVlJ8VkHMsLx1vxhwCSpyO+hN/6XKZCT5us2IxEqAeHzpqxlsJBhpZstDpaAmWicXq KFwxDMlNnhvg8qu3LKmQOR2muwoLdLgO8UUvXQIITTxUqd9GsqbE/uajTNe9HBgneJlPc35X dAIRgdsPEnQZUNoZFhCXfrSm8/x1iWgLFW0smm9v60z50DSwRB/lr/3P7LolseiX85ZmAOTo XjLuji/CRABP9vZwj2Amp6xugPRtXvYRb5PDbuyz/dv3nqh+W1INQZNd0Tu9JFVlXWCc95YL kUV/A8noq4z6FGnQ7HBs/uQ/SbsUvk0BoE4LgEq1O2e4vGOslrGXADoWhYEOYJ57JVpLdA// gbRx4uBONB5jFGCpZtxHJ+urDiyMDIZNmgEDcPvZVRYu4m6yG3fY+6mczqOOLS+gtuwEjbqz nXW6iM/nL4Uy8UM0s1XHGwrYRrx9vAlrSZsu207u15JCCsiPOZJgKTztTDmAQ5odtrxc7V4l CFsdzKixO4PF4qRsyeGXf8AGrqkj97cbmGG2gMwT8B6qWXxk5JGQWy2yGwiTKuOGptbEQIFn GeI0e+szMYJZSDzPfMfj3yZUptyncAM6ugJptiNPoYRPfCdhSeM/TplYgaLznvxnU03+ZzTy r/FGftA+U0yUPw9pBLvHr91+eZymkgWmDKILbimnkvP7FZrTCPMIVvzGADWPr5RAWLtiFi9z uuzwOPRmkoPC7OvM3CHmWPRRHhTRUUG6VnNg5Q/Xoa+zsBOQgnN19e5LWsdRrFY IronPort-HdrOrdr: A9a23:Ag3NkKgxfGh+I9QiKW5Q/Ch9r3BQX3Z13DAbv31ZSRFFG/FwyP rOoB1L73HJYWgqN03IwerwR5VoMkmsi6KdgLNhc4tKOTOHhILGFvAb0WNtqQeQYBEWmtQtsJ uINpIOdOEYbmIKzPoSgjPIaerIqePvmMvD6IuurAYOcegpUdAc0+4TMHf9LqQCfng+OXNPLu v72iMonUvFRV0nKuCAQlUVVenKoNPG0Lj8ZwQdOhIh4A6SyRu19b/TCXGjr1cjegIK5Y1n3X nOkgT/6Knmmeq80AXg22ja6IkTsMf9y+FEGNeHhqEuW3bRY0eTFcZcso+5zXQISdKUmREXeR 730lEd1vFImjbsl6eO0ELQMkfboW4TAjTZuC6laDPY0LzErXQBepF8bUYzSGqF16Lm1+sMip 6jlljpxKZ/HFfOmj/w6MPPUAwvnk2ooWA6mepWlHBHV5ACAYUh4LD30XklW6voJhiKorzP0d Mee/309bJTaxeXfnrZtm5gzJilWWkyBA6PRgwHttaO2zZbkXhlxw9ArfZv0Uso5dY4Ud1J9u 7EOqNnmPVHSdIXd7t0AKMETdGsAmLATBrQOCaZIEjhFqsAJ3XRwqSHrIkd9aWvYtgF3ZEykJ POXBdRsnMzYVvnDYmU0JhC4nn2MS2AtPTWu4hjDrRCy8jBrYvQQFu+oQoV4rmdSt0kc7nmZ8 o= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.88,295,1635206400"; d="scan'208,217";a="793320868" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Jan 2022 16:05:12 +0000 Received: from mail.cisco.com (xbe-aln-004.cisco.com [173.36.7.19]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 20HG5Co0006559 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for ; Mon, 17 Jan 2022 16:05:12 GMT Received: from xfe-aln-002.cisco.com (173.37.135.122) by xbe-aln-004.cisco.com (173.36.7.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Mon, 17 Jan 2022 10:05:12 -0600 Received: from xfe-rtp-003.cisco.com (64.101.210.233) by xfe-aln-002.cisco.com (173.37.135.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Mon, 17 Jan 2022 10:05:12 -0600 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-003.cisco.com (64.101.210.233) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Mon, 17 Jan 2022 11:05:11 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TEcORYGSsoNwT5isxTF400/I7tvt/bENh5/tYOhiz6/gPa9SuiTeJgp6XoqU+ahbx/Io6chW3bfuO5Am7wtzx+qCGb2Sqw0qRWN6sJ/d6mlPPWms0mYtYofyXW+pTuoy2VxqSeoevv7toNqdUpB0qRCgmdyNdgAdRUe6nzuedBe76ZSK+61hRLKmPyy9WxptALhrll1ZlqAcY7z+o077HPEX4TbV+NE5rsOe1zbjD1KZ33CxBFYZSzH1Li1E4pOwrYoDjKdTF00IH1vqJMoOHRO7dMU7aOiKAV+r7T6ZYC8M8O3W5W9SkMIAuTYusTbUOA8Rpd+jRjY7J6Ae4TmdeA== 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=dBYpbXRqeAJdCfO03qoxCPnRcrJbhhn3SqFblKcpEVs=; b=ZVf5vutXb+m7CEyp4WtqY+oDEFoNSDBu3xfxcBNDW+V/pRcWI+Tbr12qoUjUyMegj4f8gx2o4MtSecPMvpc1gDUND1zsv+uVSJ1FYgKQg/xNIEj70OLQr29fyY32mr9GtBqdLNui2fnTevLyg6r7zsSd9xAX5TGSPifyp/eThcSNcuX2e3Rx0MJkjItdYWEeavAq4fBfOrnVEP5+UpeYAdSpZNbGV81attSVMKiRNYMbc/D4vZWFC9be6oAaif7egjQ8F3FZZ5wErNuORPm1WQRLt+7+f/9akOdhxt7cMzy0fQnHNwPAAxxatU0fGMGWWfd6Ggo1J6m9LJ8sahhjSQ== 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=dBYpbXRqeAJdCfO03qoxCPnRcrJbhhn3SqFblKcpEVs=; b=FZd4bOtyT1fd+YLxdkiBWaMChHGFrOzr/jl3Tx2lmBVXm3XUnwILyfSm2VrRRSKJ9skUmk7OjHZ+KXQigm1Z76ImR1KLrGOKG1BwhCqsPPUoZwoW20OpwJYKV1TPpWeg7kioJi3OLA42151/FZD2bAYsfUUAlJnEmrIPmq1eO84= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by DM5PR11MB1545.namprd11.prod.outlook.com (2603:10b6:4:9::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4888.11; Mon, 17 Jan 2022 16:05:10 +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.014; Mon, 17 Jan 2022 16:05:10 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Call for adoption of " RNFD: Fast border router crash detection in RPL" Thread-Index: AdgLt8z6nGBxALo4Q5GkBp5G6uK8VQAA83IA Date: Mon, 17 Jan 2022 16:05:08 +0000 Deferred-Delivery: Mon, 17 Jan 2022 16:04:43 +0000 Message-ID: References: <14433_1642434269_61E58EDD_14433_392_1_1dd1e18428384bff9514ff4919cec3d9@orange.com> In-Reply-To: <14433_1642434269_61E58EDD_14433_392_1_1dd1e18428384bff9514ff4919cec3d9@orange.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: 7c0c604b-fbbe-4a8a-adda-08d9d9d3233d x-ms-traffictypediagnostic: DM5PR11MB1545:EE_ x-microsoft-antispam-prvs: 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: ThTmYCya73G3Ky9L649ZpOMfl1W3qg0jiWLwVRpQa9FqbHeBw64r6n4XudTeK2lZ4Hol9GgY28FZB/p9sTn68f5epqFJR6LMPOqtBpELUMbu8W489ff9PeeGDn58+sEM43HPUQCFOCU6zaLbYiSi7JxahVnV5Oru8N6cG2MchJaIe2qmb2K0QpPCsQ53Tb1uuL+3wGmnA/nTurhZ6WFta74L11xOBf9+Jd6kT2pFy/An0zjHbVf67kVDJWMmulhTspv88vJMeNv9uCRIFneKa2fpbU8/DLPJ/VOd70LuCDXflC60Gz1auwo1tG7+sgvi1aToGWZKSq0ACkuckSVZKd8ITjp+QjfpXUj1Y1SHwqXvwHEEsLBs2wKvQIcbEIyg0rNmF6Dw2bml/1E+oJX6Wi0+/VhrAd+ngvYPvOTSE/k4+7ASnal2LSUVXRnwsssXNQjeUz1kqNP3C1ZUPz8eDrSozyN5BV/IYysMjTRzgUXeuJdpRaqfRAfO+p04molFPYxacKFyd3PbgZ4t6tRGH0urtg3QbbhAfIymghXgtVCL4g68A7i55HCNID2lTdI0Ka49ieZiHtYMrFcwWEWbrMonT3KBYSOL8qd0aCuFnTei4PCScrUUOexZauEdclk6/GZPxcUmXtpJPx2mwHrLH6kIDzl9IUkvfCRDw+Ore3kJVodVXZNQICRr8R4xGea3HrUcXD7SF81A/fn+Zt82yQ== 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)(38070700005)(5660300002)(38100700002)(55016003)(316002)(9686003)(66476007)(64756008)(66556008)(53546011)(2906002)(6506007)(8676002)(86362001)(186003)(66946007)(6916009)(76116006)(26005)(8936002)(66446008)(52536014)(508600001)(71200400001)(66574015)(122000001)(83380400001)(33656002)(7696005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?mmCCLF3aDt7J8o2R0M7THj/wnPAr7tCFkyhHyAyoFo41Q0VssQMleJtYS3Pd?= =?us-ascii?Q?QVP9H2r2tqdmyFI77Mzf6KcJEHUurxWpY/lu6ffAutadIrt2bfzi2Jk1ZErn?= =?us-ascii?Q?rncAMUBihG5y6wGJ6MCN/jinRMWY1thxK/XVTCnBXgV3w9TnzWzGuGCWM+Nq?= =?us-ascii?Q?3r5cUnNL9NV/MAm1cmHhVx9cAQ8e80gKBMsIlmLQnQXHb8CDfg12F3d2Y//B?= =?us-ascii?Q?+3DHu49NWKaMu4x+e7IQrLXyVtFDrFVLgxdvrcbdd0NvP0gdlc1Zvhp0cARs?= =?us-ascii?Q?6GfSynwnAqRLW3vvPRS0qq6mk0h4ALumLluN8spYYwqi3plrS3JULnqcZN8t?= =?us-ascii?Q?/XYMO/h2z4EL2NBZgeTeYxi7OCNYVVcOXpEw6aCG7Rrgf+FrUJaRrC0rv/n0?= =?us-ascii?Q?OsSAUOgBGxjuhCZHrMIG/lNm9LAd4QTNJfd7Pgr/A4zGmB2bpfBe+Qyz7Npw?= =?us-ascii?Q?pebmvgpAFj5A/aEY4iwoWOV9iQJlDdGSKsC4xbWDDITBJZgdEbr4OuN1ZkhI?= =?us-ascii?Q?BfYuMhdm/CJamJW/6taDjlcDhykEaobI2+P2UJB2XaguZGo65HCCmPe9O1ss?= =?us-ascii?Q?IswHddHeYfuwVBGobP51UMNibrTvCAK1QctDhPYmPvsSVDtZu0sx2eX0juTe?= =?us-ascii?Q?CdSFdf/i9XTrOjFySlKG2ixCLiEMtb7s+299EdpL2t8YduN2bd6AKehTtnzm?= =?us-ascii?Q?80GcALTyd7piT0L8zBjnKnssp9gldshTlXjfYZB0QwH2tbVAJ1f4lCaxrL3V?= =?us-ascii?Q?JoLUDg0c7SCoXKn/wR25UdjUr/eYvJ6j+C0xqOSXvZYJIqqkSW+DW6GksPGW?= =?us-ascii?Q?Ud5tqj2Rgfj4HNndzr9eoSms8RXHGavzswIJRlekKtqsY98RDIYkmmPjT6Jv?= =?us-ascii?Q?Safr5WKRj//u0ogSEG95rSVtNLHXHP+xofU8BtNDOIP3U8Y733PiKUZdqZnX?= =?us-ascii?Q?6NMO/WN2cF6xIsBX0YRie97PW8E0WhS56FKf0J2vNkYPBYX+n8voviI97sjN?= =?us-ascii?Q?YeyGBFt2VRWhqrAUdO8B5MtW16eYlEzIHoJNaKA7KkmvY/9OA5D4l4zWjrj0?= =?us-ascii?Q?692uVVIpwJDoZZ0cvwkGOSv1pUsInHvboWkOXUABbgiKisOaTfHqH/5fJsOx?= =?us-ascii?Q?2OoiQQY1JSpCJmX3MimwDhbhQGycRHQPCQcfgswxBOMS1aRjg1eDg3kA6rE6?= =?us-ascii?Q?YKXf/K20SfcNTiBGsQT0//byhoWy7klgBHh6XZcjBSFC9L15LKP7miFhWs44?= =?us-ascii?Q?5WnRQdT3bTaMMeDNcpsCfIJv+nR83xnKNrXR0/8rlIDscfVIJKv/k+6QIdiE?= =?us-ascii?Q?w8PRB2cedqsWxupGDaDaGW53t1A2rUE8UGPBrx9K5tRJgPJcydq3U6C/9+GY?= =?us-ascii?Q?Xym3vv6xaRP+Jo84S2Bj4Q+wcQ3+pVLTK7OWBJNYdzthZ2Qi11j5u9YwNhQ3?= =?us-ascii?Q?C4R88LclBLGXTNSLAsOFbB6GBaKaGax7OQmMpseHSjYKI2MhST78TbO/bO6c?= =?us-ascii?Q?0cWwL1FKkiVnlLqu8iwTUNbqJdVi5Y7mGkgzxF3WIKjDrgL/PAzDUlJ7mcFp?= =?us-ascii?Q?yRv3P53T4pq6ANTFIof7e2tAZDgHwVQXtpyeY3o0YRSRPabjACbGAQNX77wU?= =?us-ascii?Q?OLiI+p1pAhVegTaGTCSLN+I=3D?= Content-Type: multipart/alternative; boundary="_000_CO1PR11MB4881420676CCF78691377751D8579CO1PR11MB4881namp_" 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: 7c0c604b-fbbe-4a8a-adda-08d9d9d3233d X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2022 16:05:10.0176 (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: KzneZCJ3TthbzJ8l2WKUtxRoVpOexj3IGahhNB+BUk5tLaJYH9nRzN4BdEjffmR/FDM7AP21hkHonZdBi2Kc0A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1545 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.19, xbe-aln-004.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [Roll] Call for adoption of " RNFD: Fast border router crash detection in RPL" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2022 16:05:19 -0000 --_000_CO1PR11MB4881420676CCF78691377751D8579CO1PR11MB4881namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear chairs I'll be happy to contribute to the discussion; this is a real and good prob= lem. It is also a hard problem. I'm good to adopt the work, though I'm not necessarily in line with the pro= posed solution for now. Let's talk more! Pascal From: Roll On Behalf Of dominique.barthel@orange.co= m Sent: lundi 17 janvier 2022 16:44 To: roll Subject: [Roll] Call for adoption of " RNFD: Fast border router crash detec= tion in RPL" Dear ROLL WG, First of all, our best wishes to you and your loved ones for 2022, hoping e= veryone is safe! Let's hope that this year will allow us to meet in person again and revive = the collaborative momentum. At the IETF112 ROLL session, we discussed the "RNFD: Fast border router cra= sh detection in RPL" draft (draft-iwanicki-roll-rnfd-01). There was no objection among the attendees to adopt the draft as a WG docum= ent, an several participants expressed their interest in the problem addres= sed. We understand that the solution to the problem might be improved furth= er with the WG' s participation. This mail starts a 2 week call for adoption for "RNFD: Fast border router c= rash detection in RPL". Please express any objections or your support in that time frame, letting u= s know if you'd be willing to contribute work or review the draft. Best regards Ines & Dominique ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_CO1PR11MB4881420676CCF78691377751D8579CO1PR11MB4881namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear chairs

 

I’ll be happy to contribute to the discussion; this is= a real and good problem. It is also a hard problem.

I’m good to adopt the work, though I’m not neces= sarily in line with the proposed solution for now.

 

Let’s talk more!

 

Pascal

 

From: Roll <roll-bo= unces@ietf.org> On Behalf Of dominique.barth= el@orange.com
Sent: lundi 17 janvier 2022 = 16:44
To: roll <roll@ietf.org&g= t;
Subject: [Roll] Call for ado= ption of " RNFD: Fast border router crash detection in RPL"<= /o:p>

 

Dear ROLL WG,

 

First of all, our best wishes to you and your loved ones for= 2022, hoping everyone is safe!

Let’s hope that this year will allow us to meet in per= son again and revive the collaborative momentum.

 

At the IETF112 ROLL session, we discussed the “RNFD: F= ast border router crash detection in RPL” draft (draft-iwanicki-roll-= rnfd-01).

There was no objection among the attendees to adopt the draf= t as a WG document, an several participants expressed their interest in the= problem addressed. We understand that the solution to the problem might be improved further with the WG’ s par= ticipation.

 

This mail starts a 2 week call for adopt= ion for “RNFD: Fast border router crash detection in RPL”.=

Please express any objections or your support in that time f= rame, letting us know if you’d be willing to contribute work or revie= w the draft.

 

Best regards

 

Ines & Dominique 

___________________________________________________________=
______________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des infor=
mations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. S=
i vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes.=
 Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete alt=
ere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential o=
r privileged information that may be protected by law;
they should not be distributed, used or copied without auth=
orisation.
If you have received this email in error, please notify the=
 sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages=
 that have been modified, changed or falsified.

Thank you.
--_000_CO1PR11MB4881420676CCF78691377751D8579CO1PR11MB4881namp_-- From nobody Mon Jan 17 11:08:08 2022 Return-Path: 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 C30C03A1076 for ; Mon, 17 Jan 2022 11:08:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca 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 sZg4Dw7SOd4r for ; Mon, 17 Jan 2022 11:08:02 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EB913A1075 for ; Mon, 17 Jan 2022 11:08:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 9909D38C6C for ; Mon, 17 Jan 2022 14:14:13 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xPbP1BpCUbrA for ; Mon, 17 Jan 2022 14:14:12 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id C33EB38C69 for ; Mon, 17 Jan 2022 14:14:12 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1642446852; bh=vH6OC8dV44NNxuMKxHf4mxJgJChC2Klal/p6XFSZ0a8=; h=From:To:Subject:In-Reply-To:References:Date:From; b=pHsoW/5yvrcqFCCJuNAvloQw6gvSdocLxuuCTpEq86HcbL3u8i6WD0dA8JcezgFQP GfBo355sLhggYdBwp/jP6shDqsGo0/IBG8xTJcF2ZBix8dx150e75YbEDfIl1Oq2DE deQXVJ+ro+Az04NiZavJ/mnuA2vHbGwMJ/jFJqa631qQXotyrR8LYwjrgZLByzhehN c4A/iaBN/fUIA3i7s9THdvEjYFpS3lMvgZLPaQnBtAwo0hF4F+h60vC8iQiwdgCPX1 MwnxlY5Di7/imhHbXedemXqNv3PKZ97EI19svScYJaNgTttLvDVnkAqUE0oStSNz95 ymXpyEMKfG1rA== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4FBEF6BE for ; Mon, 17 Jan 2022 14:07:57 -0500 (EST) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: <14433_1642434269_61E58EDD_14433_392_1_1dd1e18428384bff9514ff4919cec3d9@orange.com> References: <14433_1642434269_61E58EDD_14433_392_1_1dd1e18428384bff9514ff4919cec3d9@orange.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Date: Mon, 17 Jan 2022 14:07:57 -0500 Message-ID: <28158.1642446477@localhost> Archived-At: Subject: Re: [Roll] Call for adoption of " RNFD: Fast border router crash detection in RPL" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2022 19:08:08 -0000 wrote: > This mail starts a 2 week call for adoption for "RNFD: Fast border > router crash detection in RPL". Please express any objections or your > support in that time frame, letting us know if you'd be willing to > contribute work or review the draft. I have no objection, and I am willing to continue reviewing. From nobody Tue Jan 18 23:33:10 2022 Return-Path: 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 E6C013A10DE for ; Tue, 18 Jan 2022 23:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 VVJhvutVlQc9 for ; Tue, 18 Jan 2022 23:33:04 -0800 (PST) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F5303A10DD for ; Tue, 18 Jan 2022 23:33:04 -0800 (PST) Received: by mail-wm1-x334.google.com with SMTP id q141-20020a1ca793000000b00347b48dfb53so3974441wme.0 for ; Tue, 18 Jan 2022 23:33:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=zn6yncTAnfoB9l/iZSwS3iRdDKqRck2y+fschXkU5bM=; b=K1xsGUt+Z/LywOhOqCPRDtiKYsMbPj/7EJoj5ivTFgVxxAikNMIdXiNqlp7bnyyZxw HSFXXXHnmyouqMii8Rk9vw7ztFN9SJdIeCHekTybMO/LnfuW7D0VwX0cxOPTYDYZl38X LSbOC41389tGKd1nz3BTXID1z1QvzE74Mx1I9kuQeknh/J1H/iAnY4UDSESmJaKTfuCK QeIESbkXl1SuGyS1t0E84+fEzc5xFWY46TfCZrR6Ey1JbS8V8S+qscJ6yJHqIA/hy7+i ashazuP17EB2AHTe4cl9bLKM3rYYbBXLmZSsODBEkBuuWfsF5J0MMrAPCCwKM+2DUAeN DS9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=zn6yncTAnfoB9l/iZSwS3iRdDKqRck2y+fschXkU5bM=; b=az3P17c8THqbTZPkOgM7uFHEvbxpqlNIcEEs3dEf7p4qnVoa6AlB5CtKg42nn66jQh KN2pDqRYcvPgWcdHTXhN+qnsP5MgqTNIpo9g8UUXnToX1zBr4td8ZouUFb4rcJLl4Sxm ErDJR5lfCovVVZyvGZ2Y/CusMmH6h+hyzdJS4PV0CR7LKcYTDMRrA3CmM7y8itMN/Ct6 RvcC8JQCTzDnszjA7t5TaXeA6pI+vEaayDD/7Ru/ZqxWGp+adkcGi0rtz3VE3Sfd2gHF /XtF4J+xnCdqwm0FaxbaQHZB+eEvagBcVVLCPg5Ysp6vaUHpKq9QzjkNqyYGMiwfvVL5 uiKg== X-Gm-Message-State: AOAM533BNFefYULZwKTyCB9hs5GCRUhdGc3i5iRFdhZgcFirrmi9qQ2h obXxlV2ajcErnZYA8dWai+FDWTdaWQ/f2DvWBo8IWer88q0= X-Google-Smtp-Source: ABdhPJxx4zyTcFGV465bhV5n66hQ/A4BgplM/Yqb0aHMbbVttLHisXQSkiajRUUML/T73psmHIs+0yXLCdl0j+ZpPfU= X-Received: by 2002:a5d:4f8b:: with SMTP id d11mr27690220wru.69.1642577581008; Tue, 18 Jan 2022 23:33:01 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Abdussalam Baryun Date: Wed, 19 Jan 2022 09:28:39 +0200 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="0000000000003b683105d5ea6575" Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2022 07:33:09 -0000 --0000000000003b683105d5ea6575 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jan 14, 2022 at 12:21 PM Pascal Thubert (pthubert) wrote: > Dear all: we had this thread as part of Li=E2=80=99s review: > > > > > > About =E2=80=9C5.4 only the router with the lowest Interface ID in its re= gistered > address needs report the SIO, and the Root will assume symmetry.=E2=80=9D > > > > [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=E2=80=99m OK to add it back, but we still lake a good d= escription > 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=E2=80=99s a nuance between bidir and symmetrical. Maybe the p= ing 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: > > =E2=80=9C > > 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. > > =E2=80=9C > > > > 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. > I think the flag needs more than two possibilities for connectivity issues, could we have two bits? AB --0000000000003b683105d5ea6575 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Jan 14, 2022 at 12:21 PM Pasc= al Thubert (pthubert) <pthubert=3D40cisco.com@dmarc.ietf.org> wrote:

Dear all: we had this thread as part of Li=E2=80=99s review:

=C2=A0

=C2=A0

About =E2=80=9C5.4 only the router with the lowest Interface I= D in its registered address needs report the SIO, and the Root will assume = symmetry.=E2=80=9D

=C2=A0

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

=C2=A0

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

=C2=A0

[Li] Some physical layer measurements such as RSSI/LQI have fo= rward and reverse direction. Can it indicate symmetrical?

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0In layer 3, receiving DIO/NS mes= sages from each other indicate symmetrical

=C2=A0

[PT] There=E2=80=99s a nuance between bidir and symmetrical.= =C2=A0 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.

=C2=A0

At the moment the text says:

=E2=80=9C

=C2=A0=C2=A0 B:=C2=A0 1-bit flag that is set to indicate that = the connectivity to the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sibling is bidirectional and ro= ughly symmetrical.=C2=A0 In that case,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 only one of the siblings may re= port the SIO for the hop.=C2=A0 If 'B'<= /p>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is not set then the SIO only in= dicates connectivity from the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sibling to this node, and does = not provide information on the hop

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 from this node to the sibling.<= u>

=E2=80=9C

=C2=A0

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 s= et or not set.


I think the flag needs more than two possibilities for connectivity issue= s, could we have two bits?

AB
=C2=A0
--0000000000003b683105d5ea6575-- From nobody Tue Jan 18 23:50:29 2022 Return-Path: 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 26E3F3A1176 for ; Tue, 18 Jan 2022 23:50:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.595 X-Spam-Level: X-Spam-Status: No, score=-9.595 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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=QZ2Ub0Gu; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=VEtjnPv+ 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 leA7gKJj0xdN for ; Tue, 18 Jan 2022 23:50:22 -0800 (PST) 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 7E5953A1175 for ; Tue, 18 Jan 2022 23:50:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19484; q=dns/txt; s=iport; t=1642578622; x=1643788222; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Zo6/a+6vkKP3WDtVTAeI4aN5RsldfctqXc4W9fa+VIM=; b=QZ2Ub0GuCqwAb2fO9P18ZZYNOrqzrodSp7rHw2nC5iBYvPP9aGjUA7JX +n76x8MagzQHHmjuMaguv7dUBbrTemj6Fgu0OEhxyiRJLLlr3291CYy6q KXOx7pqARi9L9qDADcnvFbWdThdH+JnUu71ioPzpOXzuvHwxNyibM0Epx s=; X-IPAS-Result: =?us-ascii?q?A0AIAQBuwudhl49dJa1agmKBITFWflo3MYRHg0cDhTmFD?= =?us-ascii?q?l2CJQOWEIUOgS4UgREDVAsBAQENAQFBBAEBhQUCF4MyAiU0CQ4BAgQBAQEBA?= =?us-ascii?q?wIDAQEBAQUBAQUBAQECAQYEFAEBAQEBAQEBJAYMBRA1hWgNhkIBAQEBAxIRB?= =?us-ascii?q?AYTAQE4DwIBCBEEAQEoAwICAjAUCQgBAQQTCBqCYgGCDlcDLgGiXQGBOgKKH?= =?us-ascii?q?3p/MoEBgggBAQYEBIUNGII3CYE6gw6CflRKAQGHByccgUlEgRVDgmc+gmMEg?= =?us-ascii?q?SQcBBw0gmI3gi6QR2uBMTIugQoPKpYviUWNb5JbCoNFlhWJWhWUIZNSlkOhK?= =?us-ascii?q?wiFBAIEAgQFAg4BAQaBYTmBW3AVO4JpURkPjjmDWIpedAI2AgYBCgEBAwmQO?= =?us-ascii?q?gEB?= IronPort-PHdr: A9a23:AXg9Ex16UvXhqvKesmDPr1BlVkEcU/3cMg0U788hjLRDOuSm8o/5N UPSrfNqkBfSXIrd5v4F7oies63pVWEap5rUtncEfc9AUhYfgpAQmAotSMeOFUz8KqvsaCo3V MRPXVNo5Te1K09QTc3/fFbV5Ha16G16Jw== IronPort-Data: A9a23:qwtEG612p7UDUhrPhvbD5atxkn2cJEfYwER7XKvMYLTBsI5bp2dSy WQYCGmFb67ZYDCmed9/aImxoBtVv5TSz9VkQQNs3Hw8FHgiRegpqji6wuYcGwvIc6UvmWo+t 512huEtr6nYd1eEzvuXGuCJQUJUiOfYFtIQNMaeYnorHVY9GX944f5es7dRbrBA0IDR7zyl4 bsek+WHULNy82cpWo68w/vrRCJH5JweihtB1rANTawjUGvlqpUgJMl3yZddgJfPatI88uaSH 44vxVwil4/T109F5tiNyt4XfqCWK1LfFVDmt5ZYZ0Stqh8FhnZo2Jp4DvAjcxZazASpsdFa6 9oY4PRcSS9xVkHNsP4WXx8dGCZkMOgZvrTGOnO498eUyiUqcVO1nK4oVx5wbNZeo7osaY1N3 aRwxDQldgyDmui72q6TQeh3jcNlJ87uVG8akiE6l2GDVKh6EPgvRY3w9cNd9SgLmfpLR9XEY fsDbRxfUlf5Nkgn1lA/UcJiw7jAamPEWydfrFa9pKcr7S7U1gMZ7VT2GMDedtrPTsJPkwPH4 GnH5G/+RBodMbRz1AZp7Fqrwc+VxynHG7gYK6fp+7lboHOS7U8cXUh+uUSAndG1jUu3WtR6I kMS+zYzoaVayKBNZoSmN/FfiCPf1iPwS+a8AMVhslDRlfC8DxKxQzlaEWYbN7TKoedvHWRyv mJlie8FEtCGXFe9c3OW9r6OoSi1P0D5xkddOHdUFGPpDzQfybzfYzrVRdplVaWylNCwRnf7w iuBq241gLB7YS83O0eToA6vb9GE/8WhousJCuP/BTnNAuRRP9LNWmBQwQKHhcus1rqxQFibp 2QjkMOD9u0IBpzlvHXTHL9QR+n3vq3Ua2C0bbtT838JqmvFF5mLIN443d2CDBwB3jssIGWwO xaD5Wu9GrcKYir6BUOIX25BI516kfe/fTgUfvvVddFJKoNgbxOK+ToGWKJj9z6FraTYqolmY c3zWZ/1VR4yUP03pBLrFrx1+eJ6mUgDKZb7GMmT5w65yoCXeHP9Ye5DaDNimMhitPPayOgUm v4CX/a3J+J3C7yhMnKJoN9KfTjn7xETXPjLliCeTcbbSiIOJY3rI6G5LW8JE2C9o5loqw== IronPort-HdrOrdr: A9a23:ldTt1qs9pWNDJS/40YY0CF5y7skC2oMji2hC6mlwRA09TyXGra GTdaUguyMc1gx/ZJh5o6H+BEDyewKjyXcV2/heAV7GZmnbUQSTXflfBQWJ+UyaJ8STzJ856U 4kSdkDNDSSNyk6sS+Z2njDLz9I+rDum8rE6Za8vhVQpENRGtxdBmxCe2Gm+zhNNXB77O0CZf yhD6R81l6dUEVSSv7+KmgOXuDFqdGOvonhewQ6Cxku7xTLpS+06ZbheiLonis2Yndq+/MP4G LFmwv26uGIqPeg0CLR0GfV8tB/hMbh8N1eH8aB4/JlaQkEyzzYJriJaYfy+Azdk9vfr2rCV+ O85SvICv4Drk85uFvF+CcFlTOQiArGoEWSuGNwyUGT0fARAghKUPaoQeliA0bkA41KhqAn7E sD5RPri7NHSRzHhyjz/N7OSlVjkVe1u2MrlaoJg2VYSpZ2Us4dkWUzxjIfLH47JlOx1GnnKp gYMOjMoPJNNV+KZXHQuWdihNSqQ3QoBx+DBkwPoNac3TRalG1wixJw/r1Rol4QsJYmD5VU7e XNNapl0LlIU88NdKp4QOMMW9G+BGDBSQ/FdGiSPVPkHqcaPG+lke+63JwloOWxPJAYxpo7n5 rMFFteqG4pYkrrTdaD2ZVamyq9CFlVnQ6dg/22y6IJz4EUdYCbRxFrEmpe4fdIi89vdvHmZw == X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.88,299,1635206400"; d="scan'208,217";a="822821649" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Jan 2022 07:49:57 +0000 Received: from mail.cisco.com (xbe-rcd-002.cisco.com [173.37.102.17]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 20J7nuQe006074 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for ; Wed, 19 Jan 2022 07:49:57 GMT Received: from xfe-rcd-003.cisco.com (173.37.227.251) by xbe-rcd-002.cisco.com (173.37.102.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Wed, 19 Jan 2022 01:49:56 -0600 Received: from xfe-rtp-002.cisco.com (64.101.210.232) 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; Wed, 19 Jan 2022 01:49:55 -0600 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-002.cisco.com (64.101.210.232) 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, 19 Jan 2022 02:49:55 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SIg+Jj73+EUTVIsSGA9QCfP5wUyrAL9ZdhMNWVfHRc6YGAVjlfVprW660OBscx/DjYudtbMY13a+raiK30RGw3kFaG1bTVA2gEEJsxiaDJtZ9ogKtB5dxh9W7bVmjuDDWhB4RUMDYHfrFxOXSxPMP8fBdETcT6eYnl1B+nqpppoo4PkF4EgZbysisdqeGDqZ5XOd27d6Q2WkkLPfVHLgl5/y1X0tpz1D3vxnaEdm5XQ/1WvRZ7GrLwpbXu6PfmlikWXbD5J3AfcIDdImdgWht30MH+AEWW7fXbywutEBjITxZSQGtV4WZwEidzp/UqVpk0CGWbv0nFYZXz66xYL9TA== 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=Zo6/a+6vkKP3WDtVTAeI4aN5RsldfctqXc4W9fa+VIM=; b=j4ZAFcawnuBW7YjAgnx0T25HnGbeCS5SPCOs4wg7mafs6WIkAFVvyzUCXQwykuedrQrCwUz14AD8jvDqDhtt63QDPqrLKoWZlneUgjJyzrBHExEKalQv3RpfDkbq8tjBVuIoWyonFR7sMl1PNDWQceEmNA+ZWm+G8E+8zXyEGF65rVFvWJ1cdrPGFXq+ZwlBjvjcPSxEiqgYJx677GElffMIdluSpCUL1SzG4hldzFEBHINCYSpUYRIDl05OkJlD87PfZlMw0/k6Q8oucnxDRolrQ+WiHrd4ECGzbEkLo6oT0Lb5kY9cLu20s8Dw/A8+Q1sGOno7A7vu+MhIiYH0UA== 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=Zo6/a+6vkKP3WDtVTAeI4aN5RsldfctqXc4W9fa+VIM=; b=VEtjnPv+l6uGsVK2kXvQZ6TNsD01pmE5YqFnC5uIlSfYHbYJvGgQri+0/cP8QOuIi6IZE18AWMnFWEn30HaJTG43uDDKQuWsAqft8l0Oj6fgAcohQMBmDRiFVRHar487TOY4AhTYK8XND6vbSJmeikn47rdKxf27z9fRLIaCj+8= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MWHPR11MB1997.namprd11.prod.outlook.com (2603:10b6:300:2a::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4888.10; Wed, 19 Jan 2022 07:49:54 +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.4909.008; Wed, 19 Jan 2022 07:49:54 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] (Was: review of dao-projection -22) Thread-Index: AdgJJ9cj+2W7GoFsTae3G3ZQ5jeTyQD3lZCAAACZYDA= Date: Wed, 19 Jan 2022 07:49:40 +0000 Deferred-Delivery: Wed, 19 Jan 2022 07:48:45 +0000 Message-ID: References: In-Reply-To: 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: 1a3d6188-ce79-4f12-aef3-08d9db2047ea x-ms-traffictypediagnostic: MWHPR11MB1997:EE_ x-microsoft-antispam-prvs: 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: 1rGSn2SAYB+xQCqtzlra3v06I9en3So60HNA9TFa9uA5lDKcseMNnt7P/1LPRfCIoxsqLyHCrSnaqMKKgHFa9Bc7OATL0F2LLHRysOy9QHS+qV9l7a0p60ld7RszpelCjdzpuFcFmdwlGinV5S5cqyRXzJfMra2bP2Ph5h28tqkIC/NLU8KmVMLuKsywD6alwcYUfXhrfMz6+FvYbyXloMBH/A37FPX+M/wsO1tUyD/p+fY690SYPVrClL4np5Jd/gAD0yNhEKKBd00ZdlGlNQpexBaDnAj46s8KvIteJcmjpUr/5M3YGmD3i64OsWJhGWMrarX5DbgTchDdnClK7Ak3bP23OWz9Dt/aEiOMCQgXv0EewkgEhZ3/MMzje1iv6Lo9h1SByJba/cUzxA4s1KPrMamhH0pDhuVPU2NLldRb1aXI2qTRrrhFHtbDoPQxOK2BKqC0dmoecbpk4MnrjRLhRNo/BJ1R47Z4gBmkMy5dPrSCZb3SSKlrx17DS3ddIb1uvCCFUxa91OvBpUy9Ad8n/XyQ4vpUBDQ9v0YQ4kgczKR3qcGB98duSS3HAl7B2+VOzhK1ogermgYVHbc3xuBrCRH4K3iGlQNlOHbh09f1wYN5I665SINDyCQDnxu5lage/MwqoxLk21BtAS1d0yvC5RybeKsAYh5NQL9V91dx22lNYer98WHGL4jn+rVwBczO9JLBr33mdrUu7WemMQ== 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)(76116006)(38100700002)(71200400001)(66574015)(26005)(66446008)(53546011)(186003)(9326002)(8936002)(508600001)(6916009)(64756008)(2906002)(8676002)(6506007)(5660300002)(66556008)(6666004)(7696005)(33656002)(52536014)(122000001)(38070700005)(66476007)(83380400001)(55016003)(66946007)(9686003)(316002)(86362001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?N0VYUEx5bHNBZzJLRTlybWx3WGhNYXZrSWhyRFdJc2pDeHN4L0JJZlRLcDA2?= =?utf-8?B?TjRUWmUwa3Z5Q29PSnNKQThrei80TzFVNVE2aXBHakZZZUN3QXJCNEhDZng5?= =?utf-8?B?RnZ2eit6R0YxdDhEcU1oSDlTRVdIS2RtOFl4ZU1FTFZJTmpGUURzRTZWaFhR?= =?utf-8?B?VjdmeXRPSldydmxqeDhndDNVM091LzY1QUZ3RTFiZ3dyakVOdlVhUkYwR25t?= =?utf-8?B?bzZKT3ZETGFKbzU1d3FwWTVIejZmTlcvVVF5VWczcWxLYWtId3N2b1p2bmcw?= =?utf-8?B?NnVpcldtejBkdFI3WWdydGZFY3g2M1FwWFJGOTNQeDRmSWtRN1UzUzIrR3Rn?= =?utf-8?B?U2wrMHZ0anU3U1BhazhQL3RMK0Irc3ZGczVma0FaN2hHSGlrRy9TK1FiL2F4?= =?utf-8?B?T2lORTVYQkEzVWVIdDNsemRuSDVVczAwRTFiYU0veUhJVlpwYVdiQUhqWWQ5?= =?utf-8?B?MEhUbHBDdDVvekd0bi9sQjBJWXYvVTEvYlFzOVp2MGh5MC9yNHVwNGFlVGdl?= =?utf-8?B?OWdhNmwwWHY4WEZHSG9NUGVXYWI0UTJyVzMwZUtwVnhwMVArYWhER3lmUW1I?= =?utf-8?B?Q1piUDk0ZjZNbWt0eEl3NUVWNysvUlRYREo4d1FpVHd0QjZ0OVVyVUtxTUNy?= =?utf-8?B?eFBEU2kvUldydm5ZUXpYOVNuSi81UEJkZW9hZCt3MVRXSWVyS0JmRzlwMWVy?= =?utf-8?B?SlJCMExoN1RpNGlxaTBveUo4MlIwR3BmM2ZnRDB1cTJ3NkVaaDVpYjFVTGNG?= =?utf-8?B?S3I5dXp4NTdabDRtdkh0WURyS1FkRS9rV0lXUEE2TFVqQ0xpT3EyVnVnbnpS?= =?utf-8?B?RVFxVDFYV3B4ZEs5TkpQamptRWxEUTgydDNTdi9TL21pTEpTd3VsVnRlK3ZJ?= =?utf-8?B?VldleDZPSGM0Sm4zZ2NBNkQ3U0VwVVFOaldmRUU0K05lL2w1a1RKTkpOY1dR?= =?utf-8?B?ZWVRRGkwSVlVbFJqdUdLMUt4WHhBR1NBNTZwZmpHeWFlQnh6bm1DZWpMWTJk?= =?utf-8?B?R1J2R0w4dWJiclU5K1NIWWhGYXovTllucVBWUEZZME5LNXBKaEdYRllpSm9a?= =?utf-8?B?aC9KVmFuM01rZWdHVldCWFlpOUlQbU1WZnNyRFNNSGVtbnZ0WkRyMG9YTXhT?= =?utf-8?B?VWVXWTlhUENtd3Y2cTE5Y3VXQWZjWU1PSCs0d2dYb1Fmcll2ajAvdVArOHdt?= =?utf-8?B?eGgwZW5UdGpvczZqdUxpMVBtcmpZWUtzcmZVbk1LdW5OWHFqTDZySUZJOUNN?= =?utf-8?B?ZVFGMldOUXpoeDZpUDFZZEtmUXJMK2RSR3VZNENWMmM0T2M4TnhRR0ZCamU0?= =?utf-8?B?Sk5JbUZiY0hXUGlWZ0VVSjlNU3NxRlV6djlZYnJDYXR2K0pLeGhMUllpMnpU?= =?utf-8?B?Q243YVU1cVRXcW94eGpvWjNqWUwzV3JVQ05PQ3gvbStndDhZenBJcTlKK1dG?= =?utf-8?B?TDlPaFY5eWhsZlRVK3dDTXBoVkx6bHRINXRkZnVRNDlOYSs1Q09CZzdVYUZk?= =?utf-8?B?WDRiMnpkRzM0aysvbVhPeWJXUUhXd3JTU1hLdEdiSG1Nd05DdXVMZTc5Zi91?= =?utf-8?B?YmUvZTBBcVBPOXBZTTlUTVJJMVd0M1hpaFFXN1gyV2MvbkZHcVZtdWJqTFU4?= =?utf-8?B?TnlQREUxTWNvemNMN3lOelllTmRkRVVQSUJZSENVdE92MHAvOTdaZTZVb2h3?= =?utf-8?B?TjZ4Sm92cy9URU9hK1NBQ0tucEV1VEozZkhzcldENCtRUE5QbDhlRFFWdFF1?= =?utf-8?B?R3hnYlg5SlV1VWRWaUlycjUyRDlwYVJCbTR5UmdNVFN5cDMwWDdpSmtnYk0v?= =?utf-8?B?THRHN2phSG1RcTFuUHNWWVo1d2NCcEtienhMbXRHSHVscE5QRnN5dy9BTWhv?= =?utf-8?B?YzhHODdHWkd4Qm1tRExyNDVlK2dweW1MTnM3VzVYSHRaMXlkMXZqY0YzNW9x?= =?utf-8?B?Slo4djBuTzNrUVowU3RjME1SaWxCM1VOVWhsbzVGYVExeEQ1QzBJM0ZvVk1h?= =?utf-8?B?T3kwTzhwSm95amo0VlFCVjJkcEtzcHJCVFV6bXpKYXFrSlZTdStKUEZick11?= =?utf-8?B?K0dQcytNTFFYdGVZRlVHZUl1T2loV3F6a1pIcmJGWUl3ZFBtOWZrVTZ6SFlp?= =?utf-8?B?aUZTQ0hpTUdpa0UxTUFITlJTZFR0K3dCRk5QM2FJc0lJeTJGNXpmQjdQNDBB?= =?utf-8?Q?AzZJnIWkMA9Dk2DtTMhpe+g=3D?= Content-Type: multipart/alternative; boundary="_000_CO1PR11MB488139581F2465D12E6A668CD8599CO1PR11MB4881namp_" 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: 1a3d6188-ce79-4f12-aef3-08d9db2047ea X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jan 2022 07:49:54.1322 (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: VfUkncT+TOINv1Oyhm5hG9NKz0Wug89ir0osGGIOIHohwgGWr6WWu+FexjgGqj83S7BWPkr29M9y1zQFYBOWoQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1997 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.17, xbe-rcd-002.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2022 07:50:27 -0000 --_000_CO1PR11MB488139581F2465D12E6A668CD8599CO1PR11MB4881namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gQWJkdXNzYWxhbQ0KDQpQb3NzaWJseS4gV2UgbmVlZCBhIGxpc3Qgb2YgY29uZGl0aW9u cyB3ZSB3b3VsZCBhZHZlcnRpc2UgYW5kIG9mIHRoZSBkaWZmZXJlbnQgYmVoYXZpb3VycyB0aGF0 IHdvdWxkIGJlIGV4cGVjdGVkIHdoZW4gc2lnbmFsZWTigKYNCkRvIHlvdSBoYXZlIGEgc3RhcnRp bmcgcG9pbnQ/DQoNCktlZXAgc2FmZTsNCg0KUGFzY2FsDQoNCg0KDQpGcm9tOiBSb2xsIDxyb2xs LWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBBYmR1c3NhbGFtIEJhcnl1bg0KU2VudDog bWVyY3JlZGkgMTkgamFudmllciAyMDIyIDg6MjkNClRvOiBSb3V0aW5nIE92ZXIgTG93IHBvd2Vy IGFuZCBMb3NzeSBuZXR3b3JrcyA8cm9sbEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbUm9sbF0g KFdhczogcmV2aWV3IG9mIGRhby1wcm9qZWN0aW9uIC0yMikNCg0KDQoNCk9uIEZyaSwgSmFuIDE0 LCAyMDIyIGF0IDEyOjIxIFBNIFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkgPHB0aHViZXJ0PTQw Y2lzY28uY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9y Zz4+IHdyb3RlOg0KRGVhciBhbGw6IHdlIGhhZCB0aGlzIHRocmVhZCBhcyBwYXJ0IG9mIExp4oCZ cyByZXZpZXc6DQoNCg0KQWJvdXQg4oCcNS40IG9ubHkgdGhlIHJvdXRlciB3aXRoIHRoZSBsb3dl c3QgSW50ZXJmYWNlIElEIGluIGl0cyByZWdpc3RlcmVkIGFkZHJlc3MgbmVlZHMgcmVwb3J0IHRo ZSBTSU8sIGFuZCB0aGUgUm9vdCB3aWxsIGFzc3VtZSBzeW1tZXRyeS7igJ0NCg0KW0xpXSAtPiBJ cyBpdCBwb3NzaWJsZSB0byBhZGQgYSBmbGFnIHRvIGluZGljYXRlIHRoZSBzeW1tZXRyeT8gT3Ro ZXJ3aXNlLCBpZiBBIGNob29zZXMgQiBhcyBzaWJsaW5nLCBidXQgQiBkb2Vzbid0IGNob29zZSBB IGFzIHNpYmxpbmcsIFJvb3QgbWF5IHRyZWF0IFNJTyBmcm9tIEEgYXMgc3ltbWV0cnkgaW5jb3Jy ZWN0bHkgd2hlbiBvbmx5IHJlY2VpdmluZyBTSU8gZnJvbSBBLg0KDQpbUFRdIHdlIHVzZWQgdG8g aGF2ZSB0aGF0IChCIEZsYWcgZm9yIGJpZGlyKSBidXQgd2UgcmVtb3ZlZCBpdCBmb3Igc2ltcGxp ZmljYXRpb24uIEnigJltIE9LIHRvIGFkZCBpdCBiYWNrLCBidXQgd2Ugc3RpbGwgbGFrZSBhIGdv b2QgZGVzY3JpcHRpb24gb2YgaG93IHRoZSBub2RlIHdpbGwga25vdyB0aGF0IHRoZSBsaW5rIGlz IHJvdWdobHkgc3ltbWV0cmljYWwuDQoNCltMaV0gU29tZSBwaHlzaWNhbCBsYXllciBtZWFzdXJl bWVudHMgc3VjaCBhcyBSU1NJL0xRSSBoYXZlIGZvcndhcmQgYW5kIHJldmVyc2UgZGlyZWN0aW9u LiBDYW4gaXQgaW5kaWNhdGUgc3ltbWV0cmljYWw/DQogICAgICAgICAgICAgICAgICBJbiBsYXll ciAzLCByZWNlaXZpbmcgRElPL05TIG1lc3NhZ2VzIGZyb20gZWFjaCBvdGhlciBpbmRpY2F0ZSBz eW1tZXRyaWNhbA0KDQpbUFRdIFRoZXJl4oCZcyBhIG51YW5jZSBiZXR3ZWVuIGJpZGlyIGFuZCBz eW1tZXRyaWNhbC4gIE1heWJlIHRoZSBwaW5nIHdvcmtzIGJ1dCB0aGUgbGluayBxdWFsaXR5IGlz IHZlcnkgZGlmZmVyZW50IGluIGJvdGggZGlyZWN0aW9ucy4gSWYgc28gdGhlIFJhbmsgaW5jcmVt ZW50IGNvbXB1dGF0aW9uIHdvdWxkIGRpZmZlciB3aWRlbHkgYW5kIHdlIHdvdWxkIG5lZWQgYm90 aCBzaWRlcy4NCg0KQXQgdGhlIG1vbWVudCB0aGUgdGV4dCBzYXlzOg0K4oCcDQogICBCOiAgMS1i aXQgZmxhZyB0aGF0IGlzIHNldCB0byBpbmRpY2F0ZSB0aGF0IHRoZSBjb25uZWN0aXZpdHkgdG8g dGhlDQogICAgICBzaWJsaW5nIGlzIGJpZGlyZWN0aW9uYWwgYW5kIHJvdWdobHkgc3ltbWV0cmlj YWwuICBJbiB0aGF0IGNhc2UsDQogICAgICBvbmx5IG9uZSBvZiB0aGUgc2libGluZ3MgbWF5IHJl cG9ydCB0aGUgU0lPIGZvciB0aGUgaG9wLiAgSWYgJ0InDQogICAgICBpcyBub3Qgc2V0IHRoZW4g dGhlIFNJTyBvbmx5IGluZGljYXRlcyBjb25uZWN0aXZpdHkgZnJvbSB0aGUNCiAgICAgIHNpYmxp bmcgdG8gdGhpcyBub2RlLCBhbmQgZG9lcyBub3QgcHJvdmlkZSBpbmZvcm1hdGlvbiBvbiB0aGUg aG9wDQogICAgICBmcm9tIHRoaXMgbm9kZSB0byB0aGUgc2libGluZy4NCuKAnA0KDQpXZSBuZWVk IHRvIGNsYXJpZnkgd2hhdCB0aGUgQiBmbGFnIG1lYW5zLCB3aGVuIGl0IGNhbiBiZSBzZXQsIGFu ZCB3aGF0IGlzIGV4cGVjdGVkIGZyb20gdGhlIFJvb3QvIFBDRSBhYm91dCBwYXRoIGNvbXB1dGF0 aW9uIHdoZW4gaXQgaXMgc2V0IG9yIG5vdCBzZXQuDQoNCkkgdGhpbmsgdGhlIGZsYWcgbmVlZHMg bW9yZSB0aGFuIHR3byBwb3NzaWJpbGl0aWVzIGZvciBjb25uZWN0aXZpdHkgaXNzdWVzLCBjb3Vs ZCB3ZSBoYXZlIHR3byBiaXRzPw0KDQpBQg0KDQo= --_000_CO1PR11MB488139581F2465D12E6A668CD8599CO1PR11MB4881namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQg NzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBzdHls ZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5IZWxsbw0KPC9zcGFuPjwvZm9udD5BYmR1c3NhbGFtPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJD YWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZh Y2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Qb3NzaWJseS4gV2Ug bmVlZCBhIGxpc3Qgb2YgY29uZGl0aW9ucyB3ZSB3b3VsZCBhZHZlcnRpc2UgYW5kIG9mIHRoZSBk aWZmZXJlbnQgYmVoYXZpb3VycyB0aGF0IHdvdWxkIGJlIGV4cGVjdGVkIHdoZW4gc2lnbmFsZWTi gKY8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZv bnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PkRvIHlvdSBoYXZlIGEgc3RhcnRpbmcgcG9pbnQ/PG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJy aSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPktlZXAgc2FmZTs8bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFj ZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIy IiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UGFzY2FsPG86 cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNp emU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC13ZWlnaHQ6Ym9sZCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvYj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9m b250PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0i Q2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC13ZWlnaHQ6Ym9sZCI+ RnJvbTo8L3NwYW4+PC9mb250PjwvYj4gUm9sbCAmbHQ7cm9sbC1ib3VuY2VzQGlldGYub3JnJmd0 Ow0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPk9uIEJlaGFsZiBPZiA8L3NwYW4+ PC9iPkFiZHVzc2FsYW0gQmFyeXVuPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJv bGQiPlNlbnQ6PC9zcGFuPjwvYj4gbWVyY3JlZGkgMTkgamFudmllciAyMDIyIDg6Mjk8YnI+DQo8 Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86PC9zcGFuPjwvYj4gUm91dGluZyBP dmVyIExvdyBwb3dlciBhbmQgTG9zc3kgbmV0d29ya3MgJmx0O3JvbGxAaWV0Zi5vcmcmZ3Q7PGJy Pg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6PC9zcGFuPjwvYj4g UmU6IFtSb2xsXSAoV2FzOiByZXZpZXcgb2YgZGFvLXByb2plY3Rpb24gLTIyKTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIi IGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9 IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5PbiBGcmksIEphbiAxNCwg MjAyMiBhdCAxMjoyMSBQTSBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpICZsdDtwdGh1YmVydD08 YSBocmVmPSJtYWlsdG86NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmciPjQwY2lzY28uY29tQGRt YXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+RGVhciBhbGw6IHdlIGhhZCB0aGlzIHRocmVhZCBhcyBwYXJ0IG9mIExp4oCZcyByZXZp ZXc6PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+QWJvdXQg4oCcNS40IG9ubHkgdGhlIHJvdXRlciB3aXRoIHRoZSBs b3dlc3QgSW50ZXJmYWNlIElEIGluIGl0cyByZWdpc3RlcmVkIGFkZHJlc3MgbmVlZHMgcmVwb3J0 IHRoZSBTSU8sIGFuZCB0aGUgUm9vdA0KIHdpbGwgYXNzdW1lIHN5bW1ldHJ5LuKAnTxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9 IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9u dCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ W0xpXSAtJmd0OyBJcyBpdCBwb3NzaWJsZSB0byBhZGQgYSBmbGFnIHRvIGluZGljYXRlIHRoZSBz eW1tZXRyeT8gT3RoZXJ3aXNlLCBpZiBBIGNob29zZXMgQiBhcyBzaWJsaW5nLCBidXQgQiBkb2Vz bid0IGNob29zZQ0KIEEgYXMgc2libGluZywgUm9vdCBtYXkgdHJlYXQgU0lPIGZyb20gQSBhcyBz eW1tZXRyeSBpbmNvcnJlY3RseSB3aGVuIG9ubHkgcmVjZWl2aW5nIFNJTyBmcm9tIEEuPG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6 ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxm b250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij5bUFRdIHdlIHVzZWQgdG8gaGF2ZSB0aGF0IChCIEZsYWcgZm9yIGJpZGlyKSBidXQgd2UgcmVt b3ZlZCBpdCBmb3Igc2ltcGxpZmljYXRpb24uIEnigJltIE9LIHRvIGFkZCBpdCBiYWNrLCBidXQg d2Ugc3RpbGwNCiBsYWtlIGEgZ29vZCBkZXNjcmlwdGlvbiBvZiBob3cgdGhlIG5vZGUgd2lsbCBr bm93IHRoYXQgdGhlIGxpbmsgaXMgcm91Z2hseSBzeW1tZXRyaWNhbC48bzpwPjwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIyIiBmYWNl PSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0i MiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPltMaV0gU29t ZSBwaHlzaWNhbCBsYXllciBtZWFzdXJlbWVudHMgc3VjaCBhcyBSU1NJL0xRSSBoYXZlIGZvcndh cmQgYW5kIHJldmVyc2UgZGlyZWN0aW9uLiBDYW4gaXQgaW5kaWNhdGUgc3ltbWV0cmljYWw/DQo8 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9u dCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwO0luIGxheWVyIDMs IHJlY2VpdmluZyBESU8vTlMgbWVzc2FnZXMgZnJvbSBlYWNoIG90aGVyIGluZGljYXRlIHN5bW1l dHJpY2FsPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij5bUFRdIFRoZXJl4oCZcyBhIG51YW5jZSBiZXR3ZWVuIGJpZGlyIGFuZCBz eW1tZXRyaWNhbC4mbmJzcDsgTWF5YmUgdGhlIHBpbmcgd29ya3MgYnV0IHRoZSBsaW5rIHF1YWxp dHkgaXMgdmVyeSBkaWZmZXJlbnQgaW4NCiBib3RoIGRpcmVjdGlvbnMuIElmIHNvIHRoZSBSYW5r IGluY3JlbWVudCBjb21wdXRhdGlvbiB3b3VsZCBkaWZmZXIgd2lkZWx5IGFuZCB3ZSB3b3VsZCBu ZWVkIGJvdGggc2lkZXMuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5BdCB0aGUgbW9tZW50IHRoZSB0ZXh0IHNheXM6PG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6 ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPuKAnDxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250 IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4m bmJzcDsmbmJzcDsgQjombmJzcDsgMS1iaXQgZmxhZyB0aGF0IGlzIHNldCB0byBpbmRpY2F0ZSB0 aGF0IHRoZSBjb25uZWN0aXZpdHkgdG8gdGhlPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBzaWJsaW5nIGlzIGJpZGlyZWN0aW9uYWwgYW5kIHJvdWdobHkgc3ltbWV0cmljYWwuJm5ic3A7 IEluIHRoYXQgY2FzZSw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9ubHkgb25lIG9m IHRoZSBzaWJsaW5ncyBtYXkgcmVwb3J0IHRoZSBTSU8gZm9yIHRoZSBob3AuJm5ic3A7IElmICdC JzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxm b250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaXMgbm90IHNldCB0aGVuIHRoZSBTSU8g b25seSBpbmRpY2F0ZXMgY29ubmVjdGl2aXR5IGZyb20gdGhlPG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2Fs aWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBzaWJsaW5nIHRvIHRoaXMgbm9kZSwgYW5kIGRvZXMgbm90IHByb3ZpZGUgaW5m b3JtYXRpb24gb24gdGhlIGhvcDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZnJvbSB0 aGlzIG5vZGUgdG8gdGhlIHNpYmxpbmcuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPuKAnDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxp YnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+V2UgbmVlZCB0byBjbGFyaWZ5IHdo YXQgdGhlIEIgZmxhZyBtZWFucywgd2hlbiBpdCBjYW4gYmUgc2V0LCBhbmQgd2hhdCBpcyBleHBl Y3RlZCBmcm9tIHRoZSBSb290LyBQQ0UgYWJvdXQgcGF0aCBjb21wdXRhdGlvbg0KIHdoZW4gaXQg aXMgc2V0IG9yIG5vdCBzZXQuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQg c2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+SSB0aGluayB0aGUgZmxhZyBuZWVkcyBtb3JlIHRoYW4gdHdvIHBv c3NpYmlsaXRpZXMgZm9yIGNvbm5lY3Rpdml0eSBpc3N1ZXMsIGNvdWxkIHdlIGhhdmUgdHdvIGJp dHM/PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2Fs aWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkFCPG86cD48L286cD48L3NwYW4+ PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNp emU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CO1PR11MB488139581F2465D12E6A668CD8599CO1PR11MB4881namp_-- From nobody Mon Jan 24 07:39:15 2022 Return-Path: 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 1D9E83A0F52 for ; Mon, 24 Jan 2022 07:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 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_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com 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 0c9mJe3ptk5i for ; Mon, 24 Jan 2022 07:39:09 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CECB3A0FDF for ; Mon, 24 Jan 2022 07:39:09 -0800 (PST) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr22.francetelecom.fr (ESMTP service) with ESMTPS id 4JjDfz44K8z106N for ; Mon, 24 Jan 2022 16:39:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1643038747; bh=0RgqwFEZuSxrUi+3WyyT4djY/c3Jt76mp1MkLryUNqs=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=ti1CYiu8j06rlZMTVqUsuybTDWAK22Pe3ATvixHU2iF542BnxTKy5+qma66w6n01N 3oGkXf8ktOYS/6ll5HKaCZuqvWiqszwn2Bv4TM8VxU2PUIXPYO7YXl2f+XkF/MIk9h 5vcpCFTdy3tBoVszMzrsTbYTsUN+NKn5nK5uJbC/uhbY03Q/p6i8Edq8Vco18PDohX OlvNd+JkqfZMc9C/vFBzTaNyKbhqB/I6eASgAcpZyNZzqdvkWS3H5geYnu9WfcjLvE w/x/CbYEB1vsbXNnmV+0IlMBnUSVoKgNcl6WLe1XxLlmRY3JlbKMOPuPq7s9ctCTZ9 Wum5AbY7q1aWw== From: To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Call for adoption of " RNFD: Fast border router crash detection in RPL" Thread-Index: AdgLt8z6nGBxALo4Q5GkBp5G6uK8VQFgFwMQ Date: Mon, 24 Jan 2022 15:39:07 +0000 Message-ID: <9723_1643038747_61EEC81B_9723_38_4_48abe35ef00042e48c83052e3b317dbf@orange.com> References: <14433_1642434269_61E58EDD_14433_392_1_1dd1e18428384bff9514ff4919cec3d9@orange.com> In-Reply-To: <14433_1642434269_61E58EDD_14433_392_1_1dd1e18428384bff9514ff4919cec3d9@orange.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.115.27.50] Content-Type: multipart/alternative; boundary="_000_48abe35ef00042e48c83052e3b317dbforangecom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] Call for adoption of " RNFD: Fast border router crash detection in RPL" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2022 15:39:14 -0000 --_000_48abe35ef00042e48c83052e3b317dbforangecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello ROLL WG, This is a gentle reminder that we have a call for adoption on-going, and th= at we would get as many opinion as possible. Thanks to those who have responded. For those of you who haven't responded yet, let your opinion be heard! Best regards, Dominique From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of dominique.barthel@or= ange.com Sent: 17 January 2022 16:44 To: roll Subject: [Roll] Call for adoption of " RNFD: Fast border router crash detec= tion in RPL" Dear ROLL WG, First of all, our best wishes to you and your loved ones for 2022, hoping e= veryone is safe! Let's hope that this year will allow us to meet in person again and revive = the collaborative momentum. At the IETF112 ROLL session, we discussed the "RNFD: Fast border router cra= sh detection in RPL" draft (draft-iwanicki-roll-rnfd-01). There was no objection among the attendees to adopt the draft as a WG docum= ent, an several participants expressed their interest in the problem addres= sed. We understand that the solution to the problem might be improved furth= er with the WG' s participation. This mail starts a 2 week call for adoption for "RNFD: Fast border router c= rash detection in RPL". Please express any objections or your support in that time frame, letting u= s know if you'd be willing to contribute work or review the draft. Best regards Ines & Dominique ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_48abe35ef00042e48c83052e3b317dbforangecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello ROLL WG,

 

This is a gentle remin= der that we have a call for adoption on-going, and that we would get as man= y opinion as possible.

Thanks to those who ha= ve responded.

For those of you who h= aven’t responded yet, let your opinion be heard!

Best regards,

 

Dominique

 

From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of dominique.barthel@orange.com
Sent: 17 January 2022 16:44
To: roll <roll@ietf.org>
Subject: [Roll] Call for adoption of " RNFD: Fast border router= crash detection in RPL"

 

Dear ROLL WG,=

 

First of all, our best wishes t= o you and your loved ones for 2022, hoping everyone is safe!

Let’s hope that this year= will allow us to meet in person again and revive the collaborative momentu= m.

 

At the IETF112 ROLL session, we= discussed the “RNFD: Fast border router crash detection in RPL”= ; draft (draft-iwanicki-roll-rnfd-01).

There was no objection among th= e attendees to adopt the draft as a WG document, an several participants ex= pressed their interest in the problem addressed. We understand that the sol= ution to the problem might be improved further with the WG’ s participation.

 

This mail starts a 2 week ca= ll for adoption for “RNFD: Fast border router crash detection in RPL&= #8221;.

Please express any objections o= r your support in that time frame, letting us know if you’d be willin= g to contribute work or review the draft.

 

Best regards<= /p>

 

Ines & Dominique 

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_48abe35ef00042e48c83052e3b317dbforangecom_-- From nobody Wed Jan 26 06:35:36 2022 Return-Path: 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 2ACBF3A122B for ; Wed, 26 Jan 2022 06:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 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_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com 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 3PERLh240wYb for ; Wed, 26 Jan 2022 06:35:29 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43A7E3A122A for ; Wed, 26 Jan 2022 06:35:29 -0800 (PST) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr21.francetelecom.fr (ESMTP service) with ESMTPS id 4JkR8b5C4wz5w8M for ; Wed, 26 Jan 2022 15:35:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1643207727; bh=OHxHmqcmGOuQRCCmjwA6sRlUc/ev3VR31rEsdx/3LyU=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=ouFNxMBFii2WH1BN8jm3tRMmdW7zztj8dMvWsvLqlXq6PU5hEXOiFOMUe+hPwLN74 UtpCBj9MLkIXKI9dNB10HJGoi36Qw9vX6diAMPzU3NNIWdRyj9G0SyAIpMyLmuYkeE 85RgaVm0Zj/nOIBPg8ecKlQ3eUDu/4YQR9KyhKDgt5J89ck+jjVK78lqk8cV71KqZc 9i8+IpYQRWpVljwYN0XDRryxgiX/1hfDJUNy76e+ioRbpT3/R7JZb8+csoJF0Lv6cv aYNHF35wTj/vxsWG42XtAyQ+vI3EFKyI/xwEEfPX/mKAggs4gGQDukmrHj7D/rLr6D YzWY+3dPzxJEw== From: To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Call for adoption of " RNFD: Fast border router crash detection in RPL" Thread-Index: AdgLt8z6nGBxALo4Q5GkBp5G6uK8VQFgFwMQAGJYh5A= Date: Wed, 26 Jan 2022 14:35:27 +0000 Message-ID: <24602_1643207727_61F15C2F_24602_200_10_39e8771dc06942e2b901986a3640b984@orange.com> References: <14433_1642434269_61E58EDD_14433_392_1_1dd1e18428384bff9514ff4919cec3d9@orange.com> <9723_1643038747_61EEC81B_9723_38_4_48abe35ef00042e48c83052e3b317dbf@orange.com> In-Reply-To: <9723_1643038747_61EEC81B_9723_38_4_48abe35ef00042e48c83052e3b317dbf@orange.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.115.26.50] Content-Type: multipart/alternative; boundary="_000_39e8771dc06942e2b901986a3640b984orangecom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] Call for adoption of " RNFD: Fast border router crash detection in RPL" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2022 14:35:34 -0000 --_000_39e8771dc06942e2b901986a3640b984orangecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello ROLL Working Group, Regarding myself (chair hat off), I support adopting this draft, and the WG= working on quick border router failure detection. I'm willing to discuss a= nd review the problem statement and technical proposals that would ensue. Don't forget to express yourself ! Best regards Dominique From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of dominique.barthel@or= ange.com Sent: 24 January 2022 16:39 To: Routing Over Low power and Lossy networks Subject: Re: [Roll] Call for adoption of " RNFD: Fast border router crash d= etection in RPL" Hello ROLL WG, This is a gentle reminder that we have a call for adoption on-going, and th= at we would get as many opinion as possible. Thanks to those who have responded. For those of you who haven't responded yet, let your opinion be heard! Best regards, Dominique From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of dominique.barthel@or= ange.com Sent: 17 January 2022 16:44 To: roll > Subject: [Roll] Call for adoption of " RNFD: Fast border router crash detec= tion in RPL" Dear ROLL WG, First of all, our best wishes to you and your loved ones for 2022, hoping e= veryone is safe! Let's hope that this year will allow us to meet in person again and revive = the collaborative momentum. At the IETF112 ROLL session, we discussed the "RNFD: Fast border router cra= sh detection in RPL" draft (draft-iwanicki-roll-rnfd-01). There was no objection among the attendees to adopt the draft as a WG docum= ent, an several participants expressed their interest in the problem addres= sed. We understand that the solution to the problem might be improved furth= er with the WG' s participation. This mail starts a 2 week call for adoption for "RNFD: Fast border router c= rash detection in RPL". Please express any objections or your support in that time frame, letting u= s know if you'd be willing to contribute work or review the draft. Best regards Ines & Dominique ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_39e8771dc06942e2b901986a3640b984orangecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello ROLL Working Gro= up,

 

Regarding myself (chai= r hat off), I support adopting this draft, and the WG working on quick bord= er router failure detection. I’m willing to discuss and review  = the problem statement and technical proposals that would ensue.

 

Don’t forget to = express yourself !

 

Best regards

 

Dominique

 

From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of dominique.barthel@orange.com
Sent: 24 January 2022 16:39
To: Routing Over Low power and Lossy networks <roll@ietf.org><= br> Subject: Re: [Roll] Call for adoption of " RNFD: Fast border ro= uter crash detection in RPL"

 

Hello ROLL WG,

 

This is a gentle remin= der that we have a call for adoption on-going, and that we would get as man= y opinion as possible.

Thanks to those who ha= ve responded.

For those of you who h= aven’t responded yet, let your opinion be heard!

Best regards,

 

Dominique

 

From: Roll [mailto:roll-bounces= @ietf.org] On Behalf Of dominiq= ue.barthel@orange.com
Sent: 17 January 2022 16:44
To: roll <roll@ietf.org><= br> Subject: [Roll] Call for adoption of " RNFD: Fast border router= crash detection in RPL"

 

Dear ROLL WG,=

 

First of all, our best wishes t= o you and your loved ones for 2022, hoping everyone is safe!

Let’s hope that this year= will allow us to meet in person again and revive the collaborative momentu= m.

 

At the IETF112 ROLL session, we= discussed the “RNFD: Fast border router crash detection in RPL”= ; draft (draft-iwanicki-roll-rnfd-01).

There was no objection among th= e attendees to adopt the draft as a WG document, an several participants ex= pressed their interest in the problem addressed. We understand that the sol= ution to the problem might be improved further with the WG’ s participation.

 

This mail starts a 2 week ca= ll for adoption for “RNFD: Fast border router crash detection in RPL&= #8221;.

Please express any objections o= r your support in that time frame, letting us know if you’d be willin= g to contribute work or review the draft.

 

Best regards<= /p>

 

Ines & Dominique 

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_39e8771dc06942e2b901986a3640b984orangecom_-- From nobody Fri Jan 28 01:36:38 2022 Return-Path: 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 A700C3A260C for ; Fri, 28 Jan 2022 01:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com 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 uwb4Zru95PEj for ; Fri, 28 Jan 2022 01:36:32 -0800 (PST) Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30C363A260B for ; Fri, 28 Jan 2022 01:36:32 -0800 (PST) Received: by mail-yb1-xb36.google.com with SMTP id c6so16779493ybk.3 for ; Fri, 28 Jan 2022 01:36:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=L8p+u22Y74DJEZ2/4H044t1kCeeww6Cbi2UkLH8irFA=; b=CLJMxlG8dzTTYgLXRr1uUZjU0gEzkfABpQApdBmIFGwrmZkhzIvZ3us2xwtoOnjwof 3KQarxs0tfNtmZFsUmg7kRtKRwZAt94Wlu2smgZ6rb74135ATygv3X3TpkmslBsy9bdc TPVsgWGWb28FYifJeQ0WEw2viARnCu1Z148fFuboz6/4x3q+d/Q10aG89O2CLgpTrF4u KrJyqxu/qk5zREf6H9QoFWMPFoaPkvIKesNnJcRyvUgbcWPoAwSN92AO0hnIDnB5iF0S RpeQiCG12nFRHdOBsf473lZ2wk4ESAyxgWnrD9r32ELhn9Qg/tvAQZGM6gpM7YesR4fE ljYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=L8p+u22Y74DJEZ2/4H044t1kCeeww6Cbi2UkLH8irFA=; b=3wilcH8GIvDOne164VjBzQl2zRXGlOX/yEKY8UpCVV7V7vo6DPnNfgCmv6leuCzTXm 2Nbkt6zG/dxLZxzl2BgkNEpvk03L2XPe1fB1F8fw7yen3e3yR1ZsTES/GB62ukUTd0PT XYdlpQn3IHn3gjTh4Mwc6sXRaE1KzU4H53Lp3HTi89cN+3zLberhOi4/8dmcCjx7bXDS xMJBDQd0jInnjSRL/Ial/H9jBvSWDczMIDHldvflh9aJrpdnlXKFANBFPDuZLBwfmosB +QFL23+rUDFOnU6NspJVjQdF5mxR6AJwcEbGPRICHDD4GbOlTyLoCgFa5jLGn+xoOaFx oAXw== X-Gm-Message-State: AOAM530IPaNIE8aXSRfgJUQZMOKM4sEzJ5pRGyYfwVVCoigd/dkOG6bD uOSUaTmvRvaItL/t7PL2XwMIsic0G19Ui+2Padk7Vc4A X-Google-Smtp-Source: ABdhPJzMqWUl3vN4yj2Xb7HHrPCHDeDaSgvXkc/Pti0VDsVoxsPVA6pbZE8OlSc8jabqvL/xA9enY5E4zz5EEnvyYEQ= X-Received: by 2002:a5b:38f:: with SMTP id k15mr12272115ybp.421.1643362591037; Fri, 28 Jan 2022 01:36:31 -0800 (PST) MIME-Version: 1.0 References: <14433_1642434269_61E58EDD_14433_392_1_1dd1e18428384bff9514ff4919cec3d9@orange.com> In-Reply-To: <14433_1642434269_61E58EDD_14433_392_1_1dd1e18428384bff9514ff4919cec3d9@orange.com> From: Ines Robles Date: Fri, 28 Jan 2022 11:35:55 +0200 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="00000000000079dd7905d6a12b0d" Archived-At: Subject: Re: [Roll] Call for adoption of " RNFD: Fast border router crash detection in RPL" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2022 09:36:37 -0000 --00000000000079dd7905d6a12b0d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, [Chair's hat off ] I support this work and I am willing to review it and contribute to the discussion of problem and solution definitions. BR, Ines. On Mon, Jan 17, 2022 at 5:44 PM wrote: > Dear ROLL WG, > > > > First of all, our best wishes to you and your loved ones for 2022, hoping > everyone is safe! > > Let=E2=80=99s hope that this year will allow us to meet in person again a= nd revive > the collaborative momentum. > > > > At the IETF112 ROLL session, we discussed the =E2=80=9CRNFD: Fast border = router > crash detection in RPL=E2=80=9D draft (draft-iwanicki-roll-rnfd-01). > > There was no objection among the attendees to adopt the draft as a WG > document, an several participants expressed their interest in the problem > addressed. We understand that the solution to the problem might be improv= ed > further with the WG=E2=80=99 s participation. > > > > *This mail starts a 2 week call for adoption for =E2=80=9CRNFD: Fast bord= er router > crash detection in RPL=E2=80=9D.* > > Please express any objections or your support in that time frame, letting > us know if you=E2=80=99d be willing to contribute work or review the draf= t. > > > > Best regards > > > > Ines & Dominique > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --00000000000079dd7905d6a12b0d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

[Chair's ha= t off ] I support this work and I am willing to review it and contribute to= the discussion of problem=C2=A0and solution definitions.=C2=A0
<= br>
BR,
Ines.=C2=A0

On Mon, Jan 17, 2022 at 5:44 P= M <dominique.barthel@ora= nge.com> wrote:

Dear ROLL WG,

=C2=A0

First of all, our best wishes t= o you and your loved ones for 2022, hoping everyone is safe!<= /span>

Let=E2=80=99s hope that this ye= ar will allow us to meet in person again and revive the collaborative momen= tum.

=C2=A0

At the IETF112 ROLL session, we= discussed the =E2=80=9CRNFD: Fast border router crash detection in RPL=E2= =80=9D draft (draft-iwanicki-roll-rnfd-01).

There was no objection among th= e attendees to adopt the draft as a WG document, an several participants ex= pressed their interest in the problem addressed. We understand that the sol= ution to the problem might be improved further with the WG=E2=80=99 s participation.

=C2=A0

This mail starts a 2 week ca= ll for adoption for =E2=80=9CRNFD: Fast border router crash detection in RP= L=E2=80=9D.

Please express any objections o= r your support in that time frame, letting us know if you=E2=80=99d be will= ing to contribute work or review the draft.

=C2=A0

Best regards

=C2=A0

Ines & Dominique = 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message=
s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--00000000000079dd7905d6a12b0d-- From nobody Fri Jan 28 02:47:28 2022 Return-Path: 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 DF63F3A09D4 for ; Fri, 28 Jan 2022 02:47:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.097 X-Spam-Level: X-Spam-Status: No, score=-7.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 C3cZ6b78EzZL for ; Fri, 28 Jan 2022 02:47:22 -0800 (PST) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DCDA3A09E0 for ; Fri, 28 Jan 2022 02:47:22 -0800 (PST) Received: by mail-ej1-x62a.google.com with SMTP id h7so14718315ejf.1 for ; Fri, 28 Jan 2022 02:47:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=ppnsaBNNGNW5vg6dOz7ATosAfczviYmPFmeOGDBNzu4=; b=Fb8nk619cLHOrYydrEWs+FE7qXaI4EWgiNHeyVEIIUCKNCPE4f3OkTMgfTh0l0yUVI SGjWmPxcfA7caohaWIGGegTE2MS4TYqFSfEGxzSxlSk6hKl917BJgAxDjoLt1AF3P3FU QoL0ReiEEhHPDzA9gx5f4fmJil15oPL3pAhkRcfS3scPjLpb8CAG5hSiRZa1OD/x1nLJ fm/zYCS+QxKzueIUNw7vpyULCHZbTo0cyosk67/7utl/uKLd5bdpNE3+VIyOvrBbbkd3 b5CbzAZzsHZQcmuuO/LebyryIOa5bVe2JhM/SoaeKb3etFeo2P+YyLnMuoMPTzEQ/qft xiXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ppnsaBNNGNW5vg6dOz7ATosAfczviYmPFmeOGDBNzu4=; b=RxR1+avRnOqSZ3CnxqRim1TZGfjLOxdGqg2xMxlT8jf2j92oRrojszhKqJY95yIkpo zWUxkxs4JBIgD0xfaePLWXKV00FG6LBGGLslSrUzUFsgorh48fiqHTxBc7jzOMlf+Ell h+7Hf90piT44KIYk3p0aDmaT7LacaIgLjz4+DbAkpKFTBTfJscQXUXID2bKY4OoVKu+/ 6dYB1yzFHDU1Ylzv5NUe369ck3h3dghiLZ/lhrymvMqhH0EasGr4V+ApVVRkxQPo0RX5 U0gSiopVabkxbR2KRnLYDAEDgOJtUkqhEswUS1LLHWbVRrSqIskOgjreGr0pgP6B6OMG wvsw== X-Gm-Message-State: AOAM531Q7hs55RMXHk6VmpD5qRsz6VZdbhlvTrEYaqGxvmRBlfDivWRV V5q8iAT+0Qk9pDnGwa7ffpNhbaI+3WVfwadhZI73mq27 X-Google-Smtp-Source: ABdhPJx/pRF6fMZLTOiGF7VmjvPn0jl835s+7AWlT4qVgFpS5yxXujCy3nCulsOVIwTvRdrTfVrRpGUwJES390ewkVk= X-Received: by 2002:a17:907:9725:: with SMTP id jg37mr6394368ejc.396.1643366840172; Fri, 28 Jan 2022 02:47:20 -0800 (PST) MIME-Version: 1.0 References: <14433_1642434269_61E58EDD_14433_392_1_1dd1e18428384bff9514ff4919cec3d9@orange.com> <9723_1643038747_61EEC81B_9723_38_4_48abe35ef00042e48c83052e3b317dbf@orange.com> In-Reply-To: <9723_1643038747_61EEC81B_9723_38_4_48abe35ef00042e48c83052e3b317dbf@orange.com> From: Rahul Jadhav Date: Fri, 28 Jan 2022 16:17:09 +0530 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="000000000000be83b605d6a228d4" Archived-At: Subject: Re: [Roll] Call for adoption of " RNFD: Fast border router crash detection in RPL" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2022 10:47:27 -0000 --000000000000be83b605d6a228d4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Folks, Interesting problem space. Would be happy to review the draft in the future and be part of the conversation. Regards, Rahul On Mon, 24 Jan 2022 at 21:09, wrote: > Hello ROLL WG, > > > > This is a gentle reminder that we have a call for adoption on-going, and > that we would get as many opinion as possible. > > Thanks to those who have responded. > > For those of you who haven=E2=80=99t responded yet, let your opinion be h= eard! > > Best regards, > > > > Dominique > > > > *From:* Roll [mailto:roll-bounces@ietf.org] *On Behalf Of * > dominique.barthel@orange.com > *Sent:* 17 January 2022 16:44 > *To:* roll > *Subject:* [Roll] Call for adoption of " RNFD: Fast border router crash > detection in RPL" > > > > Dear ROLL WG, > > > > First of all, our best wishes to you and your loved ones for 2022, hoping > everyone is safe! > > Let=E2=80=99s hope that this year will allow us to meet in person again a= nd revive > the collaborative momentum. > > > > At the IETF112 ROLL session, we discussed the =E2=80=9CRNFD: Fast border = router > crash detection in RPL=E2=80=9D draft (draft-iwanicki-roll-rnfd-01). > > There was no objection among the attendees to adopt the draft as a WG > document, an several participants expressed their interest in the problem > addressed. We understand that the solution to the problem might be improv= ed > further with the WG=E2=80=99 s participation. > > > > *This mail starts a 2 week call for adoption for =E2=80=9CRNFD: Fast bord= er router > crash detection in RPL=E2=80=9D.* > > Please express any objections or your support in that time frame, letting > us know if you=E2=80=99d be willing to contribute work or review the draf= t. > > > > Best regards > > > > Ines & Dominique > > _________________________________________________________________________= ________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > > Thank you. > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --000000000000be83b605d6a228d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Folks,

I= nteresting problem space. Would be happy to review the draft in the future = and be part of the conversation.=C2=A0

R= egards,
Rahul

On Mon, 24 Jan 2022 at 21:09, <dominique.barthel@orange.com&g= t; wrote:

Hello ROLL WG,<= u>

=C2=A0

This is a gentl= e reminder that we have a call for adoption on-going, and that we would get= as many opinion as possible.

Thanks to those= who have responded.

For those of yo= u who haven=E2=80=99t responded yet, let your opinion be heard!

Best regards,

=C2=A0

Dominique

=C2=A0

From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of dominique.barthel@orange.com
Sent: 17 January 2022 16:44
To: roll <roll= @ietf.org>
Subject: [Roll] Call for adoption of " RNFD: Fast border router= crash detection in RPL"

=C2=A0

Dear ROLL WG,

=C2=A0

First of all, our best wishes t= o you and your loved ones for 2022, hoping everyone is safe!<= /span>

Let=E2=80=99s hope that this ye= ar will allow us to meet in person again and revive the collaborative momen= tum.

=C2=A0

At the IETF112 ROLL session, we= discussed the =E2=80=9CRNFD: Fast border router crash detection in RPL=E2= =80=9D draft (draft-iwanicki-roll-rnfd-01).

There was no objection among th= e attendees to adopt the draft as a WG document, an several participants ex= pressed their interest in the problem addressed. We understand that the sol= ution to the problem might be improved further with the WG=E2=80=99 s participation.

=C2=A0

This mail starts a 2 week ca= ll for adoption for =E2=80=9CRNFD: Fast border router crash detection in RP= L=E2=80=9D.

Please express any objections o= r your support in that time frame, letting us know if you=E2=80=99d be will= ing to contribute work or review the draft.

=C2=A0

Best regards

=C2=A0

Ines & Dominique = 

______________________________________________________________________=
___________________________________________________
=C2=A0
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les me=
ssages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


=C2=A0


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
u>


If you have received this email in error, please notify the sender and=
 delete this message and its attachments.


As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.


Thank you.


______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message=
s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--000000000000be83b605d6a228d4-- From nobody Fri Jan 28 06:34:33 2022 Return-Path: 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 896913A1622 for ; Fri, 28 Jan 2022 06:34:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.097 X-Spam-Level: X-Spam-Status: No, score=-7.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com 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 mIAr0ARynUfI for ; Fri, 28 Jan 2022 06:34:27 -0800 (PST) Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 647E13A161D for ; Fri, 28 Jan 2022 06:34:27 -0800 (PST) Received: by mail-yb1-xb2a.google.com with SMTP id k17so19013645ybk.6 for ; Fri, 28 Jan 2022 06:34:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+6UKUka1Jq7K0RZDs0/jvuKJ1DXFg5e5Dz8pBPpR3oE=; b=Nan+E+q+ess++E4T+Z8uK8E+NtsTm2ArsuNu1l+YMcQ3LG8ZNvBqTbkUj45tMZVjuz jCY/41RZkxH/PJzzcTD/86yOm7DtJMthk/Pse4HTqOqILKsCGlz0WHz0NrBB2TYmXQnf fLqBe+RdbUpMFerCa+2rgke2mElEgzkAlYRp6oabKbMprDCe3wnvi3O+U+HeTyvUV2iJ aqA7w2MNaQst5mnMsvaFcr95+Gml6UoUK26hBSAuEqCWFkTBze+yEtwrlolWk6dTUTKv 5Xy2cBXCM/azveHJLug27juchIB3nYSVMN4IsqgRlRj+ccH7Tq6GriXCWrOUneteE2UM 2M7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+6UKUka1Jq7K0RZDs0/jvuKJ1DXFg5e5Dz8pBPpR3oE=; b=lLRHxZqcGYo7BiwnqTbW+WGJAi8MNJkCorVdwxlnBGtNgR5e+8sqiyN85bVnFcvzJi kkBz+M/8nGzCMybEjxkpjM5nUi7Jz0FZ+Ws/jrjw2AHUvT9GW96ltoqtVqnDiJo3VCAn HkxjsZhpJOG72kktbSaSqmk3+qzE8aBH7CkG73wzZzIhcrg1Wna2zBnlqRl2+x8zBOHZ 1+emsbuC5f5ggBvZ+GAQ8/WrkDgM8tebdDYas2ukvqA+QIDbQ5xx2w7boFMTc/A1+TLn 4QAfosHXGwKfctnWTCdUdWpnjpCVkRfjdXfhZoZbKaHBVb+33Jtla8pV2TToNBoPKhAK xBCw== X-Gm-Message-State: AOAM530yj7VK3x5B+ELebbAfbxiEZOtBiNcCiuANhAnEIz6KesPojDgM Pigflp8Afb9S6vsx31EABGcFu/CVJ37VD5UToixwpKuJSXM= X-Google-Smtp-Source: ABdhPJxxzQnZTuXniwk5KBcMBGaZSR9DWMfvNeYmCIsDLzYPJUbfRW31A093flqKba1Pswm5JaWk+/+7Yd+L9PySq/w= X-Received: by 2002:a25:2416:: with SMTP id k22mr12880552ybk.400.1643380465000; Fri, 28 Jan 2022 06:34:25 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ines Robles Date: Fri, 28 Jan 2022 16:33:49 +0200 Message-ID: To: roll Content-Type: multipart/alternative; boundary="000000000000d8e77a05d6a554a6" Archived-At: Subject: Re: [Roll] Roll at IETF 113 - Request to fill a survey X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2022 14:34:32 -0000 --000000000000d8e77a05d6a554a6 Content-Type: text/plain; charset="UTF-8" Dear all, This is a kindly reminder to fill the survey, https://www.surveymonkey.com/r/TN6XNR8 (estimated time to fill it: 2 minutes) Thank you, Ines and Dominique On Mon, Jan 17, 2022 at 5:38 PM Ines Robles wrote: > Dear all, > > In order to help us assess the need for a ROLL session at the IETF 113 > meeting, would you please fill the following form by 30th January. > > https://www.surveymonkey.com/r/TN6XNR8 (estimated time to fill it: 2 > minutes) > > Thank you in advance, > > Ines and Dominique > --000000000000d8e77a05d6a554a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

This is a kindly reminder= to fill the survey,

https://www.surveymonkey.com/r/TN6XNR8=C2=A0(estimated time to fill it: 2 = minutes)

Thank you,

I= nes and Dominique

On Mon, Jan 17, 2022 at 5:38 PM Ines Robles <mariainesrobles@googlemail.c= om> wrote:
Dear all,

In order to help us assess the need fo= r a ROLL session at the IETF 113 meeting, would you please fill the followi= ng form by 30th January.

https://www.surveymonkey.com/r/TN6XNR8 (estim= ated time to fill it: 2 minutes)

Thank you in advance,

Ines a= nd Dominique=C2=A0
--000000000000d8e77a05d6a554a6-- From nobody Sun Jan 30 09:27:09 2022 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE793A1869; Sun, 30 Jan 2022 09:27:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.44.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <164356362763.19666.10893663352366955802@ietfa.amsl.com> Date: Sun, 30 Jan 2022 09:27:07 -0800 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-aodv-rpl-12.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2022 17:27:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks WG of the IETF. Title : Supporting Asymmetric Links in Low Power Networks: AODV-RPL Authors : Charles E. Perkins S.V.R Anand Satish Anamalamudi Bing Liu Filename : draft-ietf-roll-aodv-rpl-12.txt Pages : 32 Date : 2022-01-30 Abstract: Route discovery for symmetric and asymmetric Peer-to-Peer (P2P) traffic flows is a desirable feature in Low power and Lossy Networks (LLNs). For that purpose, this document specifies a reactive P2P route discovery mechanism for both hop-by-hop routing and source routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL protocol (AODV-RPL). Paired Instances are used to construct directional paths, for cases where there are asymmetric links between source and target nodes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-aodv-rpl/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-roll-aodv-rpl-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-aodv-rpl-12 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Sun Jan 30 22:53:01 2022 Return-Path: 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 707813A2411 for ; Sun, 30 Jan 2022 22:52:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com 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 1krzBD_141bL for ; Sun, 30 Jan 2022 22:52:55 -0800 (PST) Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B6843A2410 for ; Sun, 30 Jan 2022 22:52:55 -0800 (PST) Received: by mail-yb1-xb2d.google.com with SMTP id m6so37387752ybc.9 for ; Sun, 30 Jan 2022 22:52:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ntBYJMJFMKf+YHIKaiX8phFFEjN3a2YP/ZRPHW8pJcc=; b=lPR+VfO7UlL2gaqs0u9FCLeqIdg7kV1NtzqvH8d10CmMe2lCaARSeUaloeDkumJUX2 iYfyt4Jp+VhA/b+3FgDb3iSt80Pi67CyjDMpXSr7lyKLxpBnzZeZbZ8pHL6KzI77ovEk beg+6EG7gvjzn4NAbzIzQduI3sGnzVxe2Ci1D/MEHsE6C03VyozRm1EeucUVsEaK9q9H 4CHwBrDi+5PIr8fDRndCUbOv2+i1rm7JZnW7q6fkSqJr3ULW8LDS4jjpfaXrBnD1DcaD xwBs3yigD480rTXVBEJYGqYaI0EYiykAJsrlQp86xLQWW2qzXQ5LxujQNFODEE5nheox o/vA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ntBYJMJFMKf+YHIKaiX8phFFEjN3a2YP/ZRPHW8pJcc=; b=ujOjv5N83+ZxKbKBWYCwvs/+YNRkKZWhUrEHS6V4DGGabUqzaQftZO63ptQdpHTp9r ruP9yHyqvRuNRl73ts0/L6ypqiWJsgcsooegGn112goaqEtgyzYw4XScB5Ld/LcaqiLH tAGjE8Jc9rGwGL5CZSZcxUVNHK3ZFy+eQ+4EhpeAGdHegMGdnPsOH13+5HkGwkTG65vK AUbI1VmfJbn6E4GioNqDF9dC4KWJdugR2eteVSk1B8EmnreZIzE3qoHqH4tM3DhpINDO xRFBypFk6WfSdzOwpwVLq8ygqi86do7Yra60qx3YJC3j//BzXA+nsaHek2t9Fdpw2FzQ pRYw== X-Gm-Message-State: AOAM532CsT2xRZ5rK4e2P+ROJQf6c7cjXcA2bveVmVvHxL6mpRvMeVSp lhAyO7NH64Mm7imhVpE2po8RUYSZ/NgAbgwWIdJ96yz6wuk= X-Google-Smtp-Source: ABdhPJzAMewdDrWT/+X7lSHQLinNKjWx+wtDGJIcfd2zapjbp0i8bwQlLfxNgxczLz2Z6bdbBQFZRUIfGRaVsAS2tss= X-Received: by 2002:a5b:38f:: with SMTP id k15mr29878769ybp.421.1643611973124; Sun, 30 Jan 2022 22:52:53 -0800 (PST) MIME-Version: 1.0 References: <164356362763.19666.10893663352366955802@ietfa.amsl.com> In-Reply-To: <164356362763.19666.10893663352366955802@ietfa.amsl.com> From: Ines Robles Date: Mon, 31 Jan 2022 08:52:16 +0200 Message-ID: To: roll Content-Type: multipart/alternative; boundary="000000000000ce83d305d6db3b8d" Archived-At: Subject: [Roll] WGLC draft-ietf-roll-aodv-rpl-12 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2022 06:53:00 -0000 --000000000000ce83d305d6db3b8d Content-Type: text/plain; charset="UTF-8" Dear all, Please find below a new version of aodv-rpl draft. This email starts a WGLC of one week. Please review and send your comments by 5th February. Note that this draft updates the MOP to 4 [ https://mailarchive.ietf.org/arch/msg/roll/yNEWYkKGcrDWYfKxCaCCX96lCUY/] Thank you, Ines and Dominique. On Sun, Jan 30, 2022 at 7:27 PM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Routing Over Low power and Lossy networks > WG of the IETF. > > Title : Supporting Asymmetric Links in Low Power > Networks: AODV-RPL > Authors : Charles E. Perkins > S.V.R Anand > Satish Anamalamudi > Bing Liu > Filename : draft-ietf-roll-aodv-rpl-12.txt > Pages : 32 > Date : 2022-01-30 > > Abstract: > Route discovery for symmetric and asymmetric Peer-to-Peer (P2P) > traffic flows is a desirable feature in Low power and Lossy Networks > (LLNs). For that purpose, this document specifies a reactive P2P > route discovery mechanism for both hop-by-hop routing and source > routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL > protocol (AODV-RPL). Paired Instances are used to construct > directional paths, for cases where there are asymmetric links between > source and target nodes. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-roll-aodv-rpl/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-roll-aodv-rpl-12 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-aodv-rpl-12 > > > Internet-Drafts are also available by rsync at rsync.ietf.org: > :internet-drafts > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --000000000000ce83d305d6db3b8d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

<= /div>
Please find below a new version of aodv-rpl draft. This email sta= rts a WGLC of one week.

Please review and send you= r comments by 5th February.=C2=A0

Note that this d= raft updates the MOP to 4=C2=A0 [https://mailarc= hive.ietf.org/arch/msg/roll/yNEWYkKGcrDWYfKxCaCCX96lCUY/]=C2=A0

Thank you,

Ines and Dominique.= =C2=A0

On Sun, Jan 30, 2022 at 7:27 PM <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Routing Over Low power and Lossy networks = WG of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Supporting Asymmetric Links in Low Power Networks: AODV-RPL
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Char= les E. Perkins
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 S.V.R Anand
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Satish Anamalamudi
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Bing Liu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-roll-aodv-rpl-12.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 32
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2022-01-30

Abstract:
=C2=A0 =C2=A0Route discovery for symmetric and asymmetric Peer-to-Peer (P2P= )
=C2=A0 =C2=A0traffic flows is a desirable feature in Low power and Lossy Ne= tworks
=C2=A0 =C2=A0(LLNs).=C2=A0 For that purpose, this document specifies a reac= tive P2P
=C2=A0 =C2=A0route discovery mechanism for both hop-by-hop routing and sour= ce
=C2=A0 =C2=A0routing: Ad Hoc On-demand Distance Vector Routing (AODV) based= RPL
=C2=A0 =C2=A0protocol (AODV-RPL).=C2=A0 Paired Instances are used to constr= uct
=C2=A0 =C2=A0directional paths, for cases where there are asymmetric links = between
=C2=A0 =C2=A0source and target nodes.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ie= tf-roll-aodv-rpl/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/ht= ml/draft-ietf-roll-aodv-rpl-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Dd= raft-ietf-roll-aodv-rpl-12


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-dra= fts


_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--000000000000ce83d305d6db3b8d-- From nobody Mon Jan 31 00:05:38 2022 Return-Path: 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 8558E3A26BD for ; Mon, 31 Jan 2022 00:05:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.596 X-Spam-Level: X-Spam-Status: No, score=-9.596 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_BLOCKED=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=X/XesrcD; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=krgM1Z0o 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 hNPf4XAB2ZBT for ; Mon, 31 Jan 2022 00:05:32 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C90A43A26B2 for ; Mon, 31 Jan 2022 00:05:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14190; q=dns/txt; s=iport; t=1643616331; x=1644825931; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=bAjY5AuEsDVbhjyked2Vm30YpvEJSUF19GlNz10ZbXs=; b=X/XesrcDHt9mEGFMB0XEPjhQzgKsBpxmtxTL/wZITptCwU11Gi6fn4mn a9zjY0UDzWe502eYg6EhN4lQRvh7Ow9Za7jdcNtqALwRwK/925wJTE37o 6q4mnhMRBFa5/5X5UbHPV4wi8rt3MelH+nlYsKaJhJlASM973CXesQSn+ U=; IronPort-PHdr: =?us-ascii?q?A9a23=3ASxCILh38mz64GPEXsmDPr1BlVkEcU/3cMg0U7?= =?us-ascii?q?88hjLRDOuSm8o/5NUPSrfNqkBfSXIrd5v4F7oies63pVWEap5rUtncEfc9AU?= =?us-ascii?q?hYfgpAQmAotSMeOFUz8KqvsaCo3VMRPXVNo5Te1K09QTc3/fFbV5Ha16G16J?= =?us-ascii?q?w=3D=3D?= IronPort-Data: =?us-ascii?q?A9a23=3Aqelc9K5+tegNZ8wAP6yUkgxRtCvFchMFZxGqf?= =?us-ascii?q?qrLsTDasY5as4F+vjYaWjvVbPrYYzb8KtFwa4jip0gO65DSnYMwTQNtqioyZ?= =?us-ascii?q?n8b8sCt6fZ1gavT04J+FiBIJa5ex512huLocYZkHhcwmj/3auK79SAnjPnRL?= =?us-ascii?q?lbBILes1h5ZFFcMpBgJ0XqPq8Zh6mJZqYDR7zGl4LsekOWHULOR4AOYB0pPg?= =?us-ascii?q?061RLyDi9yp0N8QlgRWifmmJzYynVFNZH4UDfnZw3cV3uBp8uCGq+brlNlV/?= =?us-ascii?q?0vD9BsrT9iiiLu+KwsBQ6XZOk6FjX8+t6qK20cZ4HdtlPdgcqNBMy+7iB3R9?= =?us-ascii?q?zx14M1RtYG6RB01FqbNg+8aFRJfFkmSOIUXqO6aeSDg4JD7I0ruNiGEL+9VJ?= =?us-ascii?q?FsxOYkw++trDydJ7/NwFdynRnhvnMqsy769D+JrnMlmdY/gPZgUvTdryjSxM?= =?us-ascii?q?BrveribK42i2DOS9G1YahhyIMvj?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3A2rhH7az94qtipuTrhMZ/KrPxgOskLtp133?= =?us-ascii?q?Aq2lEZdPULSK2lfpGV8sjziyWatN9IYgBepTnyAtj/fZq8z+863WB1B9eftW?= =?us-ascii?q?bdyROVxA8J1/qY/9SNIVyaygcZ79YdT0EcMqywMbEZt7eB3ODQKb9Jq7PrnN?= =?us-ascii?q?HK9IXjJjVWPHxXgspbnmBE43OgYzRLrX59dPwE/fSnl656jgvlXU5SQtWwB3?= =?us-ascii?q?EDUeSGjcbMjojabRkPAANiwBWSjBuzgYSKUySw71M7aXdi0L0i+W/Kn0jS/a?= =?us-ascii?q?O4qcy2zRfayiv684lWot380dFObfb8yfT9aw+cyDpAVr4RH4FqjwpF591HL2?= =?us-ascii?q?xa1uUkli1QevibLUmhJ11d7yGdgzUImwxemkMKgWXo8UcL5/aJHw7Tz6F69N?= =?us-ascii?q?9kmtyz0Tt7gDg06tM540uJ85VQFh/OhyL7+pzBUAxrjFO9pT44nfcUlGE3a/?= =?us-ascii?q?pSVFZ9l/1VwKpuKuZLIMs60vFRLMB+SMXHoPpGe1KTaH7U+mFp3dy3R3w2Wh?= =?us-ascii?q?OLWFILtMCZ2yVf2CkR9TpW+OUP2nMbsJ4tQZhN4OrJdqxuibFVV8cTKaZwHv?= =?us-ascii?q?0IT8e7AnHEBRjMLGWRK1L6E7xvAQOAl7fnpLEuoO26cp0By5U/3JzHTVNDrG?= =?us-ascii?q?Y3P1njDMWftac7uiwlgF/NFAgF5vsukqSRi4eMMoYDaxfzOmzGu/HQ18kiPg?= =?us-ascii?q?=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CZBwDNl/dh/5hdJa1agmOBITFWB3d?= =?us-ascii?q?aNzGESYNHA4U5hQ6DAgOBE5UDhQ6BLhSBEQNUCwEBAQ0BASoBCgwEAQGFBQI?= =?us-ascii?q?Xg0kCJTUIDgECBAEBARIBAQUBAQECAQYEgQkThWgNhkIBAQEBAwEBEBEKEwE?= =?us-ascii?q?BLAwPAgEIEQQBASgDAgICJQsUCQgCBBMIGoJjgg5XAy4BDqFWAYE6AoofeoE?= =?us-ascii?q?xgQGCCAEBBgQEgTYBAwIOQYMCGII3AwaBOoMOhBwBAYcHJxyBSUSBFUOCMDc?= =?us-ascii?q?+gmMBAQIBF4EMBQESAQMgKwmCYjeCLpMUBFECFEeBOB9FlU+JTo1ykmEKg0a?= =?us-ascii?q?LAYsdiV0Vg3KMHJUHgnKWSo0PmTMCBAIEBQIOAQEGgWMBOTgxcHAVGiGCNQE?= =?us-ascii?q?BMlEZD5IRhRSFSnQ4AgYLAQEDCY1MAQE?= X-IronPort-AV: E=Sophos;i="5.88,330,1635206400"; d="scan'208,217";a="989500794" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 31 Jan 2022 08:05:29 +0000 Received: from mail.cisco.com (xbe-aln-007.cisco.com [173.36.7.22]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 20V85TNb023771 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for ; Mon, 31 Jan 2022 08:05:29 GMT Received: from xfe-rtp-004.cisco.com (64.101.210.234) 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; Mon, 31 Jan 2022 02:05:28 -0600 Received: from xfe-rcd-002.cisco.com (173.37.227.250) 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.986.14; Mon, 31 Jan 2022 03:05:27 -0500 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (72.163.14.9) 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 via Frontend Transport; Mon, 31 Jan 2022 02:05:27 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iMCS/o958j9NRXsgto8l7mfxv5yVXiPu8VDukmaugMS0WtmC/ZQJ0fCpvyY1coE6JLl8IPlPI4Zj8Zn2NZLpdui+vblkLH4H7UznW8bF0NbwqWpp4sTH/rDVrl/RetkjxW7oCQAyQ3HmARRxFh7WGuN5yIhBcb2PmNqSnMg82FG9hMk9CkROLyeXYRD3t5d2eDZgla7BiKr1VKnOF70sj+uIXiD+UZFhJiMgzRJCzFgY0FFQWbGTtmjXmZJQgByMz8vzWuVrIV7+5IsUYWhjY5wlIukVblqYeDPuRp16g+IZwBrMcDrzkS3oOUUIzyJ7xU7YW1cHd43GyIJ47vjCdA== 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=bAjY5AuEsDVbhjyked2Vm30YpvEJSUF19GlNz10ZbXs=; b=DwcC+Ps9nIuYNGCa2g3x42+RcJUbTjAAxxk9mutVirKNAHipNAaiLlrMXnk/680dIcZfANnfgLJzkQPSeQDKHjFEDa02D0r6I1NTgsJMH0gRV56FbzwiJMWmU5CC0M2h7Q+C43bJgxb9xAf1NwyZLxDTIzGZdQlKEHLsy9oM2jP2L4ZYErbOAUqryhENAXYuMOhp+87M35983Wb5fl8dy0cwbOvx1NVAtdH0HRyVOG4OP3lA2PtNKiGwoKKLcFNdNqulIbd88E2jAQ8AdElSDxzeJtm1F4UIK51c+XV4BDYJSjP7IGdk3n7NkokCQU881ypJrIZLJJxA+UojpIWeZA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; 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=bAjY5AuEsDVbhjyked2Vm30YpvEJSUF19GlNz10ZbXs=; b=krgM1Z0oDsI3Ha2fg7lHjFc7NYFoKtU9Wo0zR62KEtvXzirAG1lKsba6DcFWRMO8vmOxZm9QJ3uhn7Dg6VJEC4TvwIOni4MYrswno7sFUpJl8slFa00IfLNiokEfLMRekBKJTM9Ks3wspJPDjh+VwJLLUJu5IsVBFSxi9pOQNCA= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by SJ0PR11MB4800.namprd11.prod.outlook.com (2603:10b6:a03:2af::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4930.18; Mon, 31 Jan 2022 08:05:21 +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.4930.021; Mon, 31 Jan 2022 08:05:21 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] WGLC draft-ietf-roll-aodv-rpl-12 Thread-Index: AQHYFm87VS3/BJqAm0GAoUNE+YHq+Kx8xUeQ Date: Mon, 31 Jan 2022 08:04:59 +0000 Deferred-Delivery: Mon, 31 Jan 2022 08:04:52 +0000 Message-ID: References: <164356362763.19666.10893663352366955802@ietfa.amsl.com> In-Reply-To: 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: e62b65b9-fd3e-48ea-1570-08d9e4906d6f x-ms-traffictypediagnostic: SJ0PR11MB4800:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3hykVheP8C2OlFSEas4LMGufO0CvHxKKn9fw5iJSqIsiVlR9EcFOnTwN+B4Z1K3Q5Kwqko6wYsSsekz2h34U58KsSrYlU0AoFFRvXVnbXPWpfmz3dKnvkHkpWqO9eTybFjEDC48ChcKFannYY2bkjZHehk/PanRS0imWGV02QKqzq9PgZZMKdrAHcQZpRO/hAypPUigNFjwdlZ+cuO4pA9qCrs1KveLiFnp0wQdMNioGSXT/+SnFvdgHc4gVL55qZgzu/ikAzCAxGJVI/k8o0CYrI4uCqrPUjTpdXGxxEwSe6eSQcq/LwlBfk5FTzakK0OqpNzrjBDqeiJCLQhkG0jH0baFHECoWwzT2fkqJxz6r72/fyBTK+m8nPX7Fqy/R+bCIQqQhZ7Eg8wCp40NZWnMSnF4T5d/ANH5xsuGr00LsOOgwyzCKz/Xs5gLFCX6h+g7J1g61Nk/mGclrgliedc1Os2K/TKTypY3dp7euR+7xmqp49a9K6qxUsPtLu2web34JV6TrVgPtzFy/lrSgqnhiyYmf5HXoIg4VhJY/rqzOSZhVwDeTQo+WXGcFmPZEfzuX+ZTKio5OcwSrJHyprSIG5Z0YTAvcrRJF39qp8pQI+JKo/5og6sZwvhMm0aKzHZ3ivrFiuTmOknn35yNsAA6HGAHWZMiW76bt8Upfa/OcYEDfGZOsWyO8ZCndrSrr/ES3MAZzS898T3uaCFf6SJU1lsksCDLJ4zwhNeZzIRkBlnm+dsTJ8I+SDo83SZWodVwd+vSNH6jaR058QnKs9x9xBTGOxV+LhdYpJKWj/hLvRNSSJ1Yp7hxg14IlosBET1q6uO+hnH6J6nGoD4HltQ== 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:(13230001)(366004)(166002)(9686003)(5660300002)(66574015)(7696005)(2906002)(6506007)(71200400001)(55016003)(83380400001)(53546011)(26005)(33656002)(52536014)(6666004)(186003)(86362001)(64756008)(66946007)(66446008)(66476007)(66556008)(122000001)(76116006)(8936002)(8676002)(508600001)(966005)(38070700005)(6916009)(316002)(38100700002)(20210929001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?UW1ITmZFTlFmaXhRVHF2YWJ0Z0d5cC9NS2tiUEkxNXFHOUtXdnNtUFlEbkYx?= =?utf-8?B?Z3dzNk5jTytlNFU5M0tFcUpyRk5rOFFjTW84eHppMDA3bzdGdGphcmJIY3dr?= =?utf-8?B?YWp4eVdza2xTSzlabGxwTFRQN1NzeVVqNStCK2xIdFUrZVh6QUNBT1NNV3cz?= =?utf-8?B?R2tXalc0ZjlWWGhRVUNRbVFqRHpPc2p0VjNyeTFDYVVYbXRiUkxCVjNSQzZq?= =?utf-8?B?em9mME1CWG9PbDZMUDR0SW5Fd2VvZk5PQWlWdHEvZDFFS0NYWlIzTTREUTZt?= =?utf-8?B?V2hUZ1A4YlZYSFRVLzRnTHVmTHEraDM5cGpZTHRYeWI2M0dSUHhKRTBoTXRU?= =?utf-8?B?MWhveTY0Sk8yRlVuTTZKeXZlRHc5QUhPa3IrVEhiU3JFWXdOc3RuYXRhbnZk?= =?utf-8?B?ZlJWNG1UZE9BSGdhWFMySTFOK3RWUmVLWVI3TDFpOFB3V0ZjYVNqdnFUQlFH?= =?utf-8?B?RDMwTHhzNWxsMGMxUTJmbisyR0xxTDNDM2hUUmhTMWo0dFdxdUorMXBHdURp?= =?utf-8?B?WStOTjUyY0h5ZDZpL0ZreG9wcmluR0dsSnBLV3lpbG5sQjBkM0M0aWJrWS85?= =?utf-8?B?bXlON3dibVpjN1oyMEVzNmVTNW5vb0lTVlJ3azlWVlNCSnNYVHVVUDhPMDBP?= =?utf-8?B?bENBdTVHRFFwOThtTVJRanUycGtsalhTTklNMUZacHBiM001UnM4Z080UWR6?= =?utf-8?B?Sm9wb3FwUUk4c21jdXp2TG9hczZKY2pJSHdYUjNhOGRhUXY3Yml6b3Q3VzJV?= =?utf-8?B?NFkyZUpKeEVGSXZFK1p3enpKbjIzRGNsVWFmOXEranFvR1dydEJwQ1ExM1dF?= =?utf-8?B?SVF0VG1kRnljb1hXOWpBNDViRDVCS25PQjBIUVRscWsycTAyTGp0bi9WaWlO?= =?utf-8?B?TGc3Q1BONDY4Ym5MeEFINXFjSnJybGdKMTRlR3VzWFBVYXNVYy9McWEvTldP?= =?utf-8?B?L2xqRUx4S3liZElxVjh6eWc1dG9xR2tZNGFXNWRVTDFyVS9obTgzQW1ZM0VY?= =?utf-8?B?YkZnWXlvMkRNLzlZNmFhbVNCai8yTlFDbUtpOFpEcHByUEFOR3JNRTkza2N5?= =?utf-8?B?TmcwMDdsV3RUUnBRalI1RVYrUWFURW0xenlCN0MrZm44NHhGYmxPNXhyQXR1?= =?utf-8?B?VWdLc3Y2SURwUllRcW5uMlFxREhIR3JsT2o3SU9HY0NBcUxKRXdzRzNWNlRU?= =?utf-8?B?ekVEeGZVb0tjN0xMbkdNSjg1cHV0Q2QyVWFhZDdxak45VVRzS0F6Rk5qREtF?= =?utf-8?B?Uk5kQTBBS3lBdUNiT3IzL1ZKQnJvd3krUi9ucUdxTXRyT3VrVEptU01LMlBP?= =?utf-8?B?ejJmQnF5dVlQMENlSUtVcjlBdG1yNDF5YzFHTHNzd0lvamI2eUhYeU03MElW?= =?utf-8?B?c0x2WVVncXBpYk9Ud1Y3TzlqcFI1RkxiTHBDeFovZ21rZWxMRmdZUTBFQ3R6?= =?utf-8?B?SWlidVZvbkNSRk5SQUNITXhpNWI0TEovSnNnbmkxaXVZZndhWDh0eTJNWjYx?= =?utf-8?B?S3Q5cld0OVYyeWJUWmE0aTNsVTRhUU1Jb1dnM09tZjNJaVlVcE1Gdzd5WC9n?= =?utf-8?B?V25ESkQ2cU9NeFJyajlzK2lKNjJINUk1ZjZxTVlsTEpGYTdkS2pDd1QyOGNj?= =?utf-8?B?L0d2MEh6b0FKTlB3NHNWQWV6U0hjN0dpQS9WWnRxN2VPYkxPRGttQ1JJQ3Z0?= =?utf-8?B?di94SUlWOGhIRjRMSzJXdEJuQjRUMndSQ2Y0akN6OU8yNGZKa1RjVzRVV2Jh?= =?utf-8?B?ZmVNTlROVlNaMnRUUm9ZMEY4LzRlTjBaeVAyRDNaZWhIRXFscjVzZ3NQc0g4?= =?utf-8?B?K0cvMlhLTDMrRWFQU3NXUVJqOW1Ed0JaS25sVkNFM2JhOS9SeG5xNGRENGkx?= =?utf-8?B?UUJuNkJEbGZhcWtQa0lnS1hRQWJ6UEhkaTVqeUU0S1QzTTlrUXlsOSt2eGh4?= =?utf-8?B?emVEb1I5THNlbUR0bVZZbjIyM3JtR0dNVGR5Rk82Q0NPMWs2a3N2a0QrU3dN?= =?utf-8?B?TjRhKzZHUEM2TEhyN29wWmdBVUdRZnlKbEY2L2sxUnRKdlRlSUNSMzlqSyta?= =?utf-8?B?am8ydzFaMFJxN2xTV2lFckJ2UWQvcjhPdGFaV0dHbzRNdm1rRUpOWFU3cS9Z?= =?utf-8?B?TEM4dWNDQytzR1JQZG56cnNYT0RFaFJtTGM1MnlZdWlqS2M1NFZJT3pzSjVH?= =?utf-8?Q?bBMObUWoMttQnptNTOyGthA=3D?= Content-Type: multipart/alternative; boundary="_000_CO1PR11MB488134645BB839E71D6ACBC0D8259CO1PR11MB4881namp_" 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: e62b65b9-fd3e-48ea-1570-08d9e4906d6f X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2022 08:05:20.3463 (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: A2RZsRbUfnj1S/ozOTFhYCGUeI7bEREtvrouHkTMdRqoIF6WrkPUhIULgibRcyR2iIZh912T1eMAXEGhX6Tx7g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB4800 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.22, xbe-aln-007.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [Roll] WGLC draft-ietf-roll-aodv-rpl-12 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2022 08:05:37 -0000 --_000_CO1PR11MB488134645BB839E71D6ACBC0D8259CO1PR11MB4881namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RXhjZWxsZW50IQ0KDQpGcm9tOiBSb2xsIDxyb2xsLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFs ZiBPZiBJbmVzIFJvYmxlcw0KU2VudDogbHVuZGkgMzEgamFudmllciAyMDIyIDc6NTINClRvOiBy b2xsIDxyb2xsQGlldGYub3JnPg0KU3ViamVjdDogW1JvbGxdIFdHTEMgZHJhZnQtaWV0Zi1yb2xs LWFvZHYtcnBsLTEyDQoNCkRlYXIgYWxsLA0KDQpQbGVhc2UgZmluZCBiZWxvdyBhIG5ldyB2ZXJz aW9uIG9mIGFvZHYtcnBsIGRyYWZ0LiBUaGlzIGVtYWlsIHN0YXJ0cyBhIFdHTEMgb2Ygb25lIHdl ZWsuDQoNClBsZWFzZSByZXZpZXcgYW5kIHNlbmQgeW91ciBjb21tZW50cyBieSA1dGggRmVicnVh cnkuDQoNCk5vdGUgdGhhdCB0aGlzIGRyYWZ0IHVwZGF0ZXMgdGhlIE1PUCB0byA0ICBbaHR0cHM6 Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9yb2xsL3lORVdZa0tHY3JEV1lmS3hDYUND WDk2bENVWS9dDQoNClRoYW5rIHlvdSwNCg0KSW5lcyBhbmQgRG9taW5pcXVlLg0KDQpPbiBTdW4s IEphbiAzMCwgMjAyMiBhdCA3OjI3IFBNIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRv OmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4+IHdyb3RlOg0KDQpBIE5ldyBJbnRlcm5ldC1EcmFm dCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3Jp ZXMuDQpUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBSb3V0aW5nIE92ZXIgTG93IHBv d2VyIGFuZCBMb3NzeSBuZXR3b3JrcyBXRyBvZiB0aGUgSUVURi4NCg0KICAgICAgICBUaXRsZSAg ICAgICAgICAgOiBTdXBwb3J0aW5nIEFzeW1tZXRyaWMgTGlua3MgaW4gTG93IFBvd2VyIE5ldHdv cmtzOiBBT0RWLVJQTA0KICAgICAgICBBdXRob3JzICAgICAgICAgOiBDaGFybGVzIEUuIFBlcmtp bnMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgUy5WLlIgQW5hbmQNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgU2F0aXNoIEFuYW1hbGFtdWRpDQogICAgICAgICAgICAgICAgICAgICAgICAg IEJpbmcgTGl1DQogICAgICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtcm9sbC1hb2R2 LXJwbC0xMi50eHQNCiAgICAgICAgUGFnZXMgICAgICAgICAgIDogMzINCiAgICAgICAgRGF0ZSAg ICAgICAgICAgIDogMjAyMi0wMS0zMA0KDQpBYnN0cmFjdDoNCiAgIFJvdXRlIGRpc2NvdmVyeSBm b3Igc3ltbWV0cmljIGFuZCBhc3ltbWV0cmljIFBlZXItdG8tUGVlciAoUDJQKQ0KICAgdHJhZmZp YyBmbG93cyBpcyBhIGRlc2lyYWJsZSBmZWF0dXJlIGluIExvdyBwb3dlciBhbmQgTG9zc3kgTmV0 d29ya3MNCiAgIChMTE5zKS4gIEZvciB0aGF0IHB1cnBvc2UsIHRoaXMgZG9jdW1lbnQgc3BlY2lm aWVzIGEgcmVhY3RpdmUgUDJQDQogICByb3V0ZSBkaXNjb3ZlcnkgbWVjaGFuaXNtIGZvciBib3Ro IGhvcC1ieS1ob3Agcm91dGluZyBhbmQgc291cmNlDQogICByb3V0aW5nOiBBZCBIb2MgT24tZGVt YW5kIERpc3RhbmNlIFZlY3RvciBSb3V0aW5nIChBT0RWKSBiYXNlZCBSUEwNCiAgIHByb3RvY29s IChBT0RWLVJQTCkuICBQYWlyZWQgSW5zdGFuY2VzIGFyZSB1c2VkIHRvIGNvbnN0cnVjdA0KICAg ZGlyZWN0aW9uYWwgcGF0aHMsIGZvciBjYXNlcyB3aGVyZSB0aGVyZSBhcmUgYXN5bW1ldHJpYyBs aW5rcyBiZXR3ZWVuDQogICBzb3VyY2UgYW5kIHRhcmdldCBub2Rlcy4NCg0KDQpUaGUgSUVURiBk YXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcm9sbC1hb2R2LXJwbC8NCg0KVGhlcmUgaXMg YWxzbyBhbiBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1yb2xsLWFvZHYtcnBsLTEyDQoNCkEgZGlm ZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vd3d3 LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXJvbGwtYW9kdi1ycGwtMTINCg0KDQpJ bnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IHJzeW5jIGF0IHJzeW5jLmlldGYu b3JnOjppbnRlcm5ldC1kcmFmdHMNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KUm9sbCBtYWlsaW5nIGxpc3QNClJvbGxAaWV0Zi5vcmc8bWFpbHRv OlJvbGxAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Jv bGwNCg== --_000_CO1PR11MB488134645BB839E71D6ACBC0D8259CO1PR11MB4881namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQg NzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBzdHls ZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5FeGNlbGxlbnQhPG86cD48L286cD48L3NwYW4+PC9mb250 PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmki PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48Zm9udCBzaXplPSIyIiBmYWNl PSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LXdlaWdodDpib2xk Ij5Gcm9tOjwvc3Bhbj48L2ZvbnQ+PC9iPiBSb2xsICZsdDtyb2xsLWJvdW5jZXNAaWV0Zi5vcmcm Z3Q7DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+T24gQmVoYWxmIE9mIDwvc3Bh bj48L2I+SW5lcyBSb2JsZXM8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+ U2VudDo8L3NwYW4+PC9iPiBsdW5kaSAzMSBqYW52aWVyIDIwMjIgNzo1Mjxicj4NCjxiPjxzcGFu IHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Ubzo8L3NwYW4+PC9iPiByb2xsICZsdDtyb2xsQGll dGYub3JnJmd0Ozxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0 Ojwvc3Bhbj48L2I+IFtSb2xsXSBXR0xDIGRyYWZ0LWlldGYtcm9sbC1hb2R2LXJwbC0xMjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNp emU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+RGVhciBhbGwsPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNh bGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZv bnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PlBsZWFzZSBmaW5kIGJlbG93IGEgbmV3IHZlcnNpb24gb2YgYW9kdi1ycGwgZHJhZnQuIFRoaXMg ZW1haWwgc3RhcnRzIGEgV0dMQyBvZiBvbmUgd2Vlay48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIg ZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+UGxlYXNlIHJldmlldyBhbmQgc2VuZCB5b3VyIGNvbW1lbnRzIGJ5IDV0aCBGZWJy dWFyeS4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBm YWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Tm90ZSB0aGF0IHRo aXMgZHJhZnQgdXBkYXRlcyB0aGUgTU9QIHRvIDQmbmJzcDsgWzxhIGhyZWY9Imh0dHBzOi8vbWFp bGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvcm9sbC95TkVXWWtLR2NyRFdZZkt4Q2FDQ1g5NmxD VVkvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21z Zy9yb2xsL3lORVdZa0tHY3JEV1lmS3hDYUNDWDk2bENVWS88L2E+XSZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGFuayB5b3UsPG86cD48L286cD48L3NwYW4+PC9mb250 PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIi IGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPkluZXMgYW5kIERvbWluaXF1ZS4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNl PSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPk9uIFN1biwgSmFuIDMwLCAyMDIyIGF0IDc6MjcgUE0gJmx0OzxhIGhyZWY9Im1haWx0bzpp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PGJyPg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMg YXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLjxi cj4NClRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFJvdXRpbmcgT3ZlciBMb3cgcG93 ZXIgYW5kIExvc3N5IG5ldHdvcmtzIFdHIG9mIHRoZSBJRVRGLjxicj4NCjxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBUaXRsZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7OiBTdXBwb3J0aW5nIEFzeW1tZXRyaWMgTGlua3MgaW4gTG93IFBvd2VyIE5ldHdv cmtzOiBBT0RWLVJQTDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBBdXRob3JzJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogQ2hhcmxlcyBFLiBQZXJraW5zPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFMuVi5SIEFuYW5kPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFNhdGlzaCBBbmFtYWxhbXVkaTxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBCaW5nIExpdTxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBGaWxlbmFtZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IGRyYWZ0 LWlldGYtcm9sbC1hb2R2LXJwbC0xMi50eHQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgUGFnZXMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogMzI8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgRGF0ZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IDogMjAyMi0wMS0zMDxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4N CiZuYnNwOyAmbmJzcDtSb3V0ZSBkaXNjb3ZlcnkgZm9yIHN5bW1ldHJpYyBhbmQgYXN5bW1ldHJp YyBQZWVyLXRvLVBlZXIgKFAyUCk8YnI+DQombmJzcDsgJm5ic3A7dHJhZmZpYyBmbG93cyBpcyBh IGRlc2lyYWJsZSBmZWF0dXJlIGluIExvdyBwb3dlciBhbmQgTG9zc3kgTmV0d29ya3M8YnI+DQom bmJzcDsgJm5ic3A7KExMTnMpLiZuYnNwOyBGb3IgdGhhdCBwdXJwb3NlLCB0aGlzIGRvY3VtZW50 IHNwZWNpZmllcyBhIHJlYWN0aXZlIFAyUDxicj4NCiZuYnNwOyAmbmJzcDtyb3V0ZSBkaXNjb3Zl cnkgbWVjaGFuaXNtIGZvciBib3RoIGhvcC1ieS1ob3Agcm91dGluZyBhbmQgc291cmNlPGJyPg0K Jm5ic3A7ICZuYnNwO3JvdXRpbmc6IEFkIEhvYyBPbi1kZW1hbmQgRGlzdGFuY2UgVmVjdG9yIFJv dXRpbmcgKEFPRFYpIGJhc2VkIFJQTDxicj4NCiZuYnNwOyAmbmJzcDtwcm90b2NvbCAoQU9EVi1S UEwpLiZuYnNwOyBQYWlyZWQgSW5zdGFuY2VzIGFyZSB1c2VkIHRvIGNvbnN0cnVjdDxicj4NCiZu YnNwOyAmbmJzcDtkaXJlY3Rpb25hbCBwYXRocywgZm9yIGNhc2VzIHdoZXJlIHRoZXJlIGFyZSBh c3ltbWV0cmljIGxpbmtzIGJldHdlZW48YnI+DQombmJzcDsgJm5ic3A7c291cmNlIGFuZCB0YXJn ZXQgbm9kZXMuPGJyPg0KPGJyPg0KPGJyPg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBh Z2UgZm9yIHRoaXMgZHJhZnQgaXM6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1yb2xsLWFvZHYtcnBsLyIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcm9sbC1hb2R2LXJwbC88 L2E+PGJyPg0KPGJyPg0KVGhlcmUgaXMgYWxzbyBhbiBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJs ZSBhdDo8YnI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1s L2RyYWZ0LWlldGYtcm9sbC1hb2R2LXJwbC0xMiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1yb2xsLWFvZHYtcnBsLTEyPC9h Pjxicj4NCjxicj4NCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJs ZSBhdDo8YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh ZnQtaWV0Zi1yb2xsLWFvZHYtcnBsLTEyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtcm9sbC1hb2R2LXJwbC0xMjwvYT48YnI+DQo8 YnI+DQo8YnI+DQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IHJzeW5jIGF0 IHJzeW5jLmlldGYub3JnOjppbnRlcm5ldC1kcmFmdHM8YnI+DQo8YnI+DQo8YnI+DQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClJvbGwgbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlJvbGxAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5Sb2xsQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcm9sbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcm9sbDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_CO1PR11MB488134645BB839E71D6ACBC0D8259CO1PR11MB4881namp_-- From nobody Mon Jan 31 08:01:39 2022 Return-Path: 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 EEA283A09BA for ; Mon, 31 Jan 2022 08:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.097 X-Spam-Level: X-Spam-Status: No, score=-7.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com 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 mj6Vn56IpZn3 for ; Mon, 31 Jan 2022 08:01:32 -0800 (PST) Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D6943A09C1 for ; Mon, 31 Jan 2022 08:01:32 -0800 (PST) Received: by mail-yb1-xb31.google.com with SMTP id i10so41837890ybt.10 for ; Mon, 31 Jan 2022 08:01:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XLJkEcLGmRYtLtjTmBrLFgKkKKykLpKju/ElFbuowbw=; b=pV4SiPkTyP7wsfkQWXDXSprqX7ivsZrCkFmc7PRjNntLXbG9nm7XVSECvgVkmgzwtN Vgm4+RSV+4CtDno5U5NJhEVEQ9ED9OzOkt/TN6TRSnAYpDJqiUtmtvtODH+Lnm1geGGV bs5KlR3Cw3Jr0EAdxTxiYJpyDbkXluaF+aZ9vza2Uo8v0Jwzx0n+3REycIT3xSp6BAOy IzMtxHVvwTVHRM4xxf5EiaGvjzL4xO/UC/6ENk3LAQAnVGjUfvZ0FgTV8mHKId60SufO 2MZehcMEEnp7EKiK0uX76tL+vmDfnhwofgY7TPv2jcpjC98I8PfuIxOXNgQ1jgJBkjSF NQlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XLJkEcLGmRYtLtjTmBrLFgKkKKykLpKju/ElFbuowbw=; b=gq5edcV6LIACHJIy1qV9BzYJoGTU4rzTidtUsltvcmS8mh8OlAKAi5nRnebbpSqvpp 6i976x8jhzfOVyscHaOQAvUTXwe1BWYiqftAIUXN6/RoT1JmtbmD/7Si9ExsWPcLPYjJ CPvFMjngqLq7zWVHF8oO9NlDPbLxoq4XhBldO3TV/CWMrcYrX+hC4dC2n1VO2rdL16N4 7tUOgAs+Sw6vhkpAYNk5FBW1Q40R+s5tsqjFJlamod/XdB9s3gywTuYMpA9dRov7Tys+ mzqeDKJLw5Ai4giT39YeS2y3tj1RAeEDo1o8wwRA0bOqGzGvXqrg7QTuVk1Y8oSRYCK/ nTcw== X-Gm-Message-State: AOAM531VnmvDxv/R/j35iWRub0Kt2YnkzSNd3rjxoEWPU/ZsQnecrd/b WgxfacYmk2CM6778f64XFSAN6wan21tcs2XzdHs= X-Google-Smtp-Source: ABdhPJyA8UyBcxSLEJXGjBjAEhNaSAw00KNfOHoYvPpCSIGbuA8POkJ9KN1vNKpZtWba97ly+XZnO/LV9AJzKWAlCPU= X-Received: by 2002:a5b:989:: with SMTP id c9mr31224025ybq.371.1643644891078; Mon, 31 Jan 2022 08:01:31 -0800 (PST) MIME-Version: 1.0 References: <708005781.5136991643640377819.JavaMail.nobody@rva2rmd102.webex.com> <20550.1643644642@localhost> In-Reply-To: <20550.1643644642@localhost> From: Ines Robles Date: Mon, 31 Jan 2022 18:00:55 +0200 Message-ID: To: Michael Richardson Cc: roll Content-Type: multipart/alternative; boundary="000000000000dea60c05d6e2e5e4" Archived-At: Subject: Re: [Roll] Webex meeting reminder: DAO Projection open issues X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2022 16:01:37 -0000 --000000000000dea60c05d6e2e5e4 Content-Type: text/plain; charset="UTF-8" Apologizes Michael, my mistake, Minutes here: https://notes.ietf.org/roll-dao-projection-open-issues-20220131?both We went through P DAO open issues. Action Points: Chairs to create tickets of Li comments on PDAO br, Ines. On Mon, Jan 31, 2022 at 5:57 PM Michael Richardson wrote: > messenger@webex.com wrote: > > DAO Projection open issues Monday, January 31, 2022 5:00 PM | > Northern > > Europe Time (Helsinki, GMT+02:00) | 1 hr 30 min Meeting number > (access > > code): 2425 778 0560 Meeting password: 5Sskq5edda3 > > 17:00 EET = 1500 UTC = 10am EST, so already happened? > > I wish this had been on the virtual interim calendar :-( > > > > --000000000000dea60c05d6e2e5e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Apologizes Michael, my mistake,=C2=A0


We went through P DAO open i= ssues.=C2=A0

Action Points: Chairs to create ticke= ts of Li comments on PDAO

br,
Ines.=C2= =A0

On Mon, Jan 31, 2022 at 5:57 PM Michael Richardson <mcr@sandelman.ca> wrote:
messenger@webex.com wrote:
=C2=A0 =C2=A0 > DAO Projection open issues Monday, January 31, 2022 5:00= PM | Northern
=C2=A0 =C2=A0 > Europe Time (Helsinki, GMT+02:00) | 1 hr 30 min Meeting = number (access
=C2=A0 =C2=A0 > code): 2425 778 0560 Meeting password: 5Sskq5edda3

17:00 EET =3D 1500 UTC =3D 10am EST, so already happened?

I wish this had been on the virtual interim calendar :-(



--000000000000dea60c05d6e2e5e4-- From nobody Mon Jan 31 08:02:52 2022 Return-Path: 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 41F8D3A09ED for ; Mon, 31 Jan 2022 08:02:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.595 X-Spam-Level: X-Spam-Status: No, score=-14.595 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_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=etFoOWrT; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=eSlAkBAf 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 ZyP4rjxi4vh5 for ; Mon, 31 Jan 2022 08:02:45 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B42B3A09E9 for ; Mon, 31 Jan 2022 08:02:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16086; q=dns/txt; s=iport; t=1643644965; x=1644854565; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=kHftBctSaTIHk50aMSdUJxFrcp+4K9cla6YHB47PWBI=; b=etFoOWrTNuqbk2AYn3jyqNfVPxhprlHKVBYpDwLJP/O8YG7556JuXxrC kepH01/Lh4kEsORQ88cmk57Jjn3Sa+SG7Oq9Whwcvp3uFEsmT4Jlo+6vI ZnwxJcC6msEoXgWsgnoxZyxgm4djVpY5nomAF+RszfZKOQPBKsLZDfV/P Q=; IronPort-PHdr: =?us-ascii?q?A9a23=3ARpqokhGrjjRZTDvoGoUlLp1GfiYY04WdBeZdw?= =?us-ascii?q?pYkircbdKOl8tyiOUHE/vxigRfPWpmT8PNLjefa8sWCEWwN6JqMqjYOJZpLU?= =?us-ascii?q?RJWhcAfhQd1BsmDBAXyJ+LraCpvGsNEWRdl8ni3PFITFtz5YgjZo2a56ngZH?= =?us-ascii?q?RCsXTc=3D?= IronPort-Data: =?us-ascii?q?A9a23=3AKBSoqKlP8CwTI1Lq/fL0Cpfo5gycJERdPkR7X?= =?us-ascii?q?Q2eYbSJt1+Wr1GztxJNX2DSM/iNYGr9eNhxa9m/pkoC7J/VmtdhTwo//39nQ?= =?us-ascii?q?1tH+JHPbTi7wugcHM8zwvUuxyuL1u1GAjX7BJ1yHi+0SiuFaOC79yEljvjQH?= =?us-ascii?q?NIQNcadUsxPbV48IMseoUoLd94R2uaEsPDha++/kYqaT/73YDdJ7wVJ3lc8s?= =?us-ascii?q?Mpvnv/AUMPa41v0tnRmDRxCUcS3e3M9VPrzLonpR5f0rxU9IwK0ewrD5OnRE?= =?us-ascii?q?mLx5RwhDJaulaz2Nx1MSb/JNg/IgX1TM0SgqkEd/WppjeBqb7xFNRs/Zzahx?= =?us-ascii?q?7idzP1VqZytQwozIoXHmf8WVF9TFCQW0ahuqeGbcCHv6ZXNp6HBWz62qxl0N?= =?us-ascii?q?2ksOokc0ud6HW8I8uYXQA3hxDjra/me2rm3TKxngd4uaZmtN4IEsXYmxjbcZ?= =?us-ascii?q?cvKiKvrG83ijeK0Fh9p3pwm8S7iWvck?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AjPOoIaBMhu72/KLlHegAsceALOsnbusQ8z?= =?us-ascii?q?AXPh9KKCC9I/b3qynxppsmPEfP+UkssQIb6K690ci7MD3hHPtOgbX5Uo3SJD?= =?us-ascii?q?UPNgGTXfpfBOfZsljd8mjFh5JgPMRbAulD4b/LfCJHZK/BiWHSebtNsbr3kp?= =?us-ascii?q?xAx92uskuFJjsaDJ2Imj0JczpzZXcGIjWua6BJcKa0145inX6NaH4XZsO0Cj?= =?us-ascii?q?0uRO7YveDGk5rgfFovGwMnwBPmt0Lp1JfKVzyjmjsOWTJGxrkvtULflRbi26?= =?us-ascii?q?mlu/anjjfBym7o6YhMkteJ8KoBOCXMsLlWFtzfsHftWG1TYczEgNnzmpDo1L?= =?us-ascii?q?8eqqiIn/7nBbUr15qeRBDsnfKn4XiQ7N9n0Q6T9bbfuwq5nSQ8LwhKVvaoQu?= =?us-ascii?q?liA0HkAgMbzaJB+bMO0GSDu5VNCxTc2Cz7+tjTThlv0lG5uHw4jIco/jFiuK?= =?us-ascii?q?YlGfRsRLYkjQlo+VY7bVXHwZFiFPMrANDX5f5Qf1/fZ3fFvnN3yNjpWngoBB?= =?us-ascii?q?+JTkULp8TQilFt7T9E5lpdwNZakmYL9Zo7RZUB7+PYMr5wnLULSsMNd6pyCO?= =?us-ascii?q?oIXMPyAG3QRhDHNn6UPD3cZe06EmOIr4Sy7KQ+5emsdpBNxJwumI7ZWFcdrm?= =?us-ascii?q?I2c1KGM7zH4HSKyGGFfIyQZ0WZ9ihu3ekOhlSnfsuYDcSqciFbr/ed?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CbBwDiBvhh/5BdJa1agmOBITFWB3d?= =?us-ascii?q?aNzGESYNHA4U5hQ5dgiUDgROVA4UOgS4UgREDVAsBAQENAQEqAQoMBAEBhQU?= =?us-ascii?q?CF4NJAiU1CA4BAgQBAQESAQEFAQEBAgEGBIEJE4VoDYZCAQEBAQMBARARChM?= =?us-ascii?q?BASwMDwIBCBEEAQEoAwICAiULFAkIAgQTCBqCY4IOVwMuAQ6hQwGBOgKKH3q?= =?us-ascii?q?BMYEBgggBAQYEBIE2AQMCDkGDAhiCNwMGgTqDDoQcAQGHByccgUlEgRVDgjA?= =?us-ascii?q?3PoJjAQECAReBDAUBEgEDICsJgmI3gi6RRYFFBFECFEeBOB9FlU+JTo1ykmE?= =?us-ascii?q?Kg0aLAYsdiV0Vg3KMHJUHgnKWSo0PlC+FBAIEAgQFAg4BAQaBYwE5ODFwcBU?= =?us-ascii?q?aIYI1AQEyURkPkhGFFIVKdDgCBgEKAQEDCY1MAQE?= X-IronPort-AV: E=Sophos;i="5.88,331,1635206400"; d="scan'208,217";a="964918016" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 31 Jan 2022 16:02:32 +0000 Received: from mail.cisco.com (xbe-rcd-003.cisco.com [173.37.102.18]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 20VG2W8t018811 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for ; Mon, 31 Jan 2022 16:02:32 GMT Received: from xfe-aln-002.cisco.com (173.37.135.122) by xbe-rcd-003.cisco.com (173.37.102.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Mon, 31 Jan 2022 10:02:32 -0600 Received: from xfe-aln-003.cisco.com (173.37.135.123) by xfe-aln-002.cisco.com (173.37.135.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Mon, 31 Jan 2022 10:02:32 -0600 Received: from NAM04-BN8-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.986.14 via Frontend Transport; Mon, 31 Jan 2022 10:02:32 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hWeSisVp+g1zsAd8c8eylgvffeMYDbZ3z2ulkHf2jXulYue6grrEAwHoq6OxB+EXjhJNlxdnVx2C6Noikn2LKGgUI/jVI7iFnPdf+K4WP7wi9fe0HJiLp4nrQz9t+n5478yQF96lf5F2B4KmVLOZ9rRF3cKgfDqCTcuUhxGp8v/Llo/mX8KvhvMJzK+3AcU9yhHNFR/61DMEPKir15EeZ4sYn4E30njaFu5w/dhk3mtNlw9NqUNqysLrwechY2kymNWt2WWiOjkPG/znZxbI7HxOqPlrmg5SHqm8g7J85we3+607MdI9y2JgE82xkoyYQXuk6gv95MxPqABJR/AWag== 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=kHftBctSaTIHk50aMSdUJxFrcp+4K9cla6YHB47PWBI=; b=BWKeZl8Ydhmdq0eRKeuqCULBzfMACagttSKUlSh7ClNMiFfpQIwzKQ+UAo/18xm9P6So0ysj3iYt1UbZ2+YKLqFLwTbM4sXLomg2mED/rdMitZJn2hlg2slGaBZA6EM8aE7e9sOPOE8/SNMU9rLuIKbcHpMCWhS5Kwbhu/iTNMDi+8q8hUJAKRRk6CsroAX2SmJou0NqAU0ez9E72yLouLsZGFlestaMtWb92lyA/2KooGh0DJ0YO8uGXzSDKapuFEXNLeHhdSoo8YDWR2zQyZQH2/8tUNK5NlKfdhkAfX+OMXy8LV/TMXq+glWFwChzkNSh6Fkbyii9FAuq8lZ5UQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; 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=kHftBctSaTIHk50aMSdUJxFrcp+4K9cla6YHB47PWBI=; b=eSlAkBAfLKV2YjMJvOMg0rtJq+ud+zB16HfZJcy7EnIC+apOHP0huQEb13/cL8mw1P7vaCOKXR2z5CqJKHQONr6mYDJU/19qHzDQeuKaV0YvReOXh8EMYA3fpPhI5C59vkI2nrrYxgyru24oZRcPue8JVHmaxG3J3pEJK2GRhGI= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by PH0PR11MB5032.namprd11.prod.outlook.com (2603:10b6:510:3a::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4930.20; Mon, 31 Jan 2022 16:02:29 +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.4930.022; Mon, 31 Jan 2022 16:02:29 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] WGLC draft-ietf-roll-aodv-rpl-12 Thread-Index: AQHYFm87VS3/BJqAm0GAoUNE+YHq+Kx9Sc8w Date: Mon, 31 Jan 2022 16:02:05 +0000 Deferred-Delivery: Mon, 31 Jan 2022 16:01:04 +0000 Message-ID: References: <164356362763.19666.10893663352366955802@ietfa.amsl.com> In-Reply-To: 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: b62ed716-8e6d-43dc-b939-08d9e4d3156c x-ms-traffictypediagnostic: PH0PR11MB5032:EE_ x-microsoft-antispam-prvs: 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: 3zhVkDbFFReKSxQ23KXTym5DyMXZXNw0YUvbXVysxV8IYPdFg27s7MA1Ecxwm15PoPMKfS8BRqqw01I063VgJrAaXG2FWy2BqfS5PxnmkXdUARW3sT0q+YnGwdWC8o0p/tOsjoAEP98SObBcsea+HNj/+7m2cHWef4I2aTZYBWs01naudeIVMf0Ffssbky6PeWubxN/pn4eQyXykBfyOxPV5x6upGC0xifVaQc3MT9bBCTuRKC9J6d6Ow58GWY7vyShuU4t3MtN5QrQIKuaw4ITeksvTVHo/KQg57sk6a+s8BEbuzo/yBcSXZp/UXIjNmO5Et0wogIXWloi1cA+MGVCALNzWWb/n4aj2CZk6niji6RTGjT9f8KvWwDdNn9ttNDdWZAukaGP90Gb28vqWqO/j9gixa1zdL+SDUSkcPv9Mp9W97bjXDro66RUN6z1GN5RucA7SIwsnwFuiy1BGR7bo6WjJ7rkx2E2D1iZ1R7NTL848H4ejEbxWsLeoZ1hzvMupUwPmH9Jzlxr7GD0odIk7as+jSRQKuICk/ZKBKeisdvnrZ9U/3kwMhzr9E3CQjAUiLIR1Dr/Dir+l2i8G49YiYyltvkokRQcbL81namKdXAPKN/FRZoHS9hL2NRAY3ZSwjfyE0rAwbfs384Z+atx/9vM48sWgnjfBeoTslcUOXFzvcKi9Vs7ApeZbZd4MTMr/9R2HOy142EJsiabG4/GZZdIIMp+f3QsXSRGaWAZH7b7pu5CbxU47g0HZ3eObA86l3oTcgmacvp3KcJ/aob3Yj+2XZPFUS3loXjgBz18UIFuzTHdepVdAcdKQnnbsSeVUKGKT0BXifSW3GULhxQ== 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:(13230001)(366004)(71200400001)(86362001)(38100700002)(33656002)(83380400001)(38070700005)(52536014)(6916009)(66574015)(316002)(966005)(53546011)(66446008)(55016003)(8676002)(186003)(8936002)(2906002)(64756008)(9686003)(6666004)(166002)(66476007)(5660300002)(7696005)(508600001)(26005)(66556008)(6506007)(76116006)(66946007)(122000001)(20210929001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?M1psNmNack82ODdOc0VnWUxhYVdQcklIY1k5M1pzRWtyaU02cXJCcWRodytS?= =?utf-8?B?b1A5OVd3Z2IxVHY3VEpIVU53TSt4MncxK3ZHZDZlMkpoNTdBVWpxVTJ4OVZZ?= =?utf-8?B?bklDTVNQR093TldicEVKQjBOazgvNzJTK2YwaUNBMi8weFEzUG4ydWR0Um91?= =?utf-8?B?T2RrM2h4R2FwRHFsY2NJMkdLN05VZHdvQ2h1Rm1RYlN3YWhZMzF6LzhuQzVq?= =?utf-8?B?aEpJcy9qSEZjSklEZkV0NmdHdzZRY0tuQTJyTUVOVENPTmxsSEpkSDZLUTYx?= =?utf-8?B?UlFwUHA2VFB0SDkxWS9aVCtIeW1HSGJNc0pFSlQyQW1RNVRWRzYxVG44NlV2?= =?utf-8?B?bTdqeXQ0OU54d1o0ZXJVZ2lZTmNxakFqQy90V1FLNHBKNGExT0E1amYxemhq?= =?utf-8?B?VkNsUzJZRys1TlpqMld4ZlFDY2RqdWtrOUpUUXlyU2ZHWTErSlh4a0UvdHg1?= =?utf-8?B?bStHekF2MU1VSG4rY0p2U2ZKOEF5UUN3ZytVS1Z0ZVZHNkZZWHl5MWlVUytR?= =?utf-8?B?TVhWUjFEbkxTVGIxTmZUNGNNb2pGS3VmV3A1WXpRdjdsTWZkZHhVNktITFJp?= =?utf-8?B?eTRVdCtYZnZUaUwvYytvMFR3b3RKeHZxS0R0UjVRVzFIZFY2QVJ6UWZmYjF0?= =?utf-8?B?N0RvOFBQYUVGdVcycndnTzBDU0ptZTlNNjh0U0FXV1h5ZHVJRTNMRmZ3a05r?= =?utf-8?B?VTR2anNkR0ZSNmM5U3ZPeldWMnZFbEhCWmpvS2RpdFhSSFVHclA5UmFQbmpn?= =?utf-8?B?S2pyeFAzV3RqTUtpcFMzQ2FkSmRsUnVabVhEMll0Y3ZHQmJZdHdORVBIb21Q?= =?utf-8?B?M2lkeTBRL2hHL0g3RzZSMEIwbTJmeTByUVBGR3pvNUdjYkV1OEFxYzliNGdh?= =?utf-8?B?ekNEZEJ5RS9ta3hNQVhuR21lVnBXU2FGaUpzalVFczNaTFpqKzBqbGZGWU11?= =?utf-8?B?Ri9kQ2NHK2R1d2lheDV6UXVzSm1nMUtUUzNLV0hvc085VnF0VmN1bXdvdm9Y?= =?utf-8?B?TUJsVDdxTVNkeXFrRXRxNC9xYTFWWkRxQnZHYUJ4Rlltc2VmcklpWTNsU0lP?= =?utf-8?B?MlJ2RjdBWmdjRmFaQ1huWFBvNjJ5eFZENWZha2k3d1E2b1FOWG5FYlRjUlNq?= =?utf-8?B?bWI3NGh1VVQzUnFqSDY3TDRPd1l2OE1TZVFYNzlkUlUxbTI2UW5ZN2NiQTVQ?= =?utf-8?B?UXBTdVJocHJPckZEYmZYYnBtU3d1MVpta3B6ck1mTkoxcXlic2YrNUNYZ0FX?= =?utf-8?B?TXpNQ2NMZXgvek5kekFrME5nUDhvT2szYkJ2YzhRSHlCUkhhZDFWdHI5aWgv?= =?utf-8?B?a2R0cElmdDk4R3V1OWYwYjhkbkNIOCtvdm1xYWI2YVpkVUdvRkZBaE9RN0RB?= =?utf-8?B?bGZpQXlsQlRyb2VzTG4rNXgxQzMzK3JxMFpyUEVQZTh4YkVqOVFmQmR0aXRP?= =?utf-8?B?SW9LZnd2czd6RlAwRGFNNW9YN1JUcHNKTmprUEhVSDcwdm9aSnlHdThTbVpr?= =?utf-8?B?azA3bE1tUVIrZGZjL0NxSWZYRlJpUm1rU2M5SE4vaENoeVVTRXhFejJxK2dk?= =?utf-8?B?SUJyVE55MGE2MDUxd3dLWVdublRBRk12VC85ZHZmbGVGbGtGUTY2UkhhQXdK?= =?utf-8?B?QWRTR09XY2RteERHaVNaUjZMQS9DOFhOTHpNbkorWGFhN1ltU0h0MnpyZmtp?= =?utf-8?B?azBhUnYya3NzZ29ESzBseXIxaUR4NlorRG5LZ3VHQVRkdWZ0QXpiSEdHb1dp?= =?utf-8?B?cTYxSlRoSWk4UTFFZUN5M01HZTJsQWNldk5Bb1JnMWZ2T0d0Qm5ueGVLNmJC?= =?utf-8?B?Ym8rTDI2NWl0eW5XbTRqT3I0LzFtMzhwTCt4MUwzSGNVbWtNUFkyZStCRWJl?= =?utf-8?B?aHNWamFZTFJWT1NYZkxJZGRFMGx2MTdvSWxoMzlIUklReTE4ejJDTlZMbHBN?= =?utf-8?B?OGZ1elFSTG1RUnFGbWpWUnJHbXo2UmdTTThrZHhoSDJ1Sm5lZGc1Sysza2pC?= =?utf-8?B?UU5UNXVnWjdWTkxnR0tZd2NiOExSb2FiN3hmUUJHVXkwZC9qR0poVkY0MW43?= =?utf-8?B?OHFZZGVTdFBLRFVNU2xMMHErRTBIT1o0RS82blE0Y3RnRGoxNHdRV0dzUlNS?= =?utf-8?B?ekdPK0YvM253N1E3d3lwWVp5MlBXQjc4eUFGdDZMQkprYmhEQ0xDbnRIMEEx?= =?utf-8?Q?1pkEqHytg1E2BEaWkz0VWZE=3D?= Content-Type: multipart/alternative; boundary="_000_CO1PR11MB4881FA1A2827CD8E5D825796D8259CO1PR11MB4881namp_" 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: b62ed716-8e6d-43dc-b939-08d9e4d3156c X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2022 16:02:29.7671 (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: SEYsA2zKvSiYw4AHdyzOer96mhBbCwBQLANMiX81HCEZOTJ2OMgz45ZTq3MALKd3ZQ1RAVXLH3FAy+CO3DXSNQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5032 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.18, xbe-rcd-003.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [Roll] WGLC draft-ietf-roll-aodv-rpl-12 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2022 16:02:50 -0000 --_000_CO1PR11MB4881FA1A2827CD8E5D825796D8259CO1PR11MB4881namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWJvdXQg4oCcDQpBT0RWLVJQTCBjYW4gYmUgb3BlcmF0ZWQgd2hldGhlciBvciBub3QgbmF0aXZl IFJQTCBpcyBydW5uaW5nIG90aGVyd2lzZS4NCuKAnA0KSSBhZ3JlZSB0aGF0IHRoZSBhZHZlcnRp c2VtZW50cyBjYW4gYmUgZGlmZmVyZW50aWF0ZWQ7IHN0aWxsIGl04oCZcyBzaW1wbGVyIHRvIGRp c2NvdXJhZ2UgdXNpbmcgYm90aCBwcm90b2NvbHMgaW4gdGhlIHNhbWUgbmV0d29yay4gV2h5IGRv IHNvIHNpbmNlIHRoaXMgaXMgZXNzZW50aWFsbHkgdGhlIHJlcGxhY2VtZW50IHByb3RvY29sPw0K DQpLZWVwIHNhZmU7DQoNClBhc2NhbA0KDQpGcm9tOiBSb2xsIDxyb2xsLWJvdW5jZXNAaWV0Zi5v cmc+IE9uIEJlaGFsZiBPZiBJbmVzIFJvYmxlcw0KU2VudDogbHVuZGkgMzEgamFudmllciAyMDIy IDc6NTINClRvOiByb2xsIDxyb2xsQGlldGYub3JnPg0KU3ViamVjdDogW1JvbGxdIFdHTEMgZHJh ZnQtaWV0Zi1yb2xsLWFvZHYtcnBsLTEyDQoNCkRlYXIgYWxsLA0KDQpQbGVhc2UgZmluZCBiZWxv dyBhIG5ldyB2ZXJzaW9uIG9mIGFvZHYtcnBsIGRyYWZ0LiBUaGlzIGVtYWlsIHN0YXJ0cyBhIFdH TEMgb2Ygb25lIHdlZWsuDQoNClBsZWFzZSByZXZpZXcgYW5kIHNlbmQgeW91ciBjb21tZW50cyBi eSA1dGggRmVicnVhcnkuDQoNCk5vdGUgdGhhdCB0aGlzIGRyYWZ0IHVwZGF0ZXMgdGhlIE1PUCB0 byA0ICBbaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9yb2xsL3lORVdZa0tH Y3JEV1lmS3hDYUNDWDk2bENVWS9dDQoNClRoYW5rIHlvdSwNCg0KSW5lcyBhbmQgRG9taW5pcXVl Lg0KDQpPbiBTdW4sIEphbiAzMCwgMjAyMiBhdCA3OjI3IFBNIDxpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4+IHdyb3RlOg0KDQpBIE5ldyBJ bnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFm dHMgZGlyZWN0b3JpZXMuDQpUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBSb3V0aW5n IE92ZXIgTG93IHBvd2VyIGFuZCBMb3NzeSBuZXR3b3JrcyBXRyBvZiB0aGUgSUVURi4NCg0KICAg ICAgICBUaXRsZSAgICAgICAgICAgOiBTdXBwb3J0aW5nIEFzeW1tZXRyaWMgTGlua3MgaW4gTG93 IFBvd2VyIE5ldHdvcmtzOiBBT0RWLVJQTA0KICAgICAgICBBdXRob3JzICAgICAgICAgOiBDaGFy bGVzIEUuIFBlcmtpbnMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgUy5WLlIgQW5hbmQNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgU2F0aXNoIEFuYW1hbGFtdWRpDQogICAgICAgICAgICAg ICAgICAgICAgICAgIEJpbmcgTGl1DQogICAgICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWll dGYtcm9sbC1hb2R2LXJwbC0xMi50eHQNCiAgICAgICAgUGFnZXMgICAgICAgICAgIDogMzINCiAg ICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAyMi0wMS0zMA0KDQpBYnN0cmFjdDoNCiAgIFJvdXRl IGRpc2NvdmVyeSBmb3Igc3ltbWV0cmljIGFuZCBhc3ltbWV0cmljIFBlZXItdG8tUGVlciAoUDJQ KQ0KICAgdHJhZmZpYyBmbG93cyBpcyBhIGRlc2lyYWJsZSBmZWF0dXJlIGluIExvdyBwb3dlciBh bmQgTG9zc3kgTmV0d29ya3MNCiAgIChMTE5zKS4gIEZvciB0aGF0IHB1cnBvc2UsIHRoaXMgZG9j dW1lbnQgc3BlY2lmaWVzIGEgcmVhY3RpdmUgUDJQDQogICByb3V0ZSBkaXNjb3ZlcnkgbWVjaGFu aXNtIGZvciBib3RoIGhvcC1ieS1ob3Agcm91dGluZyBhbmQgc291cmNlDQogICByb3V0aW5nOiBB ZCBIb2MgT24tZGVtYW5kIERpc3RhbmNlIFZlY3RvciBSb3V0aW5nIChBT0RWKSBiYXNlZCBSUEwN CiAgIHByb3RvY29sIChBT0RWLVJQTCkuICBQYWlyZWQgSW5zdGFuY2VzIGFyZSB1c2VkIHRvIGNv bnN0cnVjdA0KICAgZGlyZWN0aW9uYWwgcGF0aHMsIGZvciBjYXNlcyB3aGVyZSB0aGVyZSBhcmUg YXN5bW1ldHJpYyBsaW5rcyBiZXR3ZWVuDQogICBzb3VyY2UgYW5kIHRhcmdldCBub2Rlcy4NCg0K DQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcm9sbC1hb2R2LXJwbC8N Cg0KVGhlcmUgaXMgYWxzbyBhbiBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1yb2xsLWFvZHYtcnBs LTEyDQoNCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoN Cmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXJvbGwtYW9kdi1y cGwtMTINCg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IHJzeW5jIGF0 IHJzeW5jLmlldGYub3JnOjppbnRlcm5ldC1kcmFmdHMNCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KUm9sbCBtYWlsaW5nIGxpc3QNClJvbGxAaWV0 Zi5vcmc8bWFpbHRvOlJvbGxAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3JvbGwNCg== --_000_CO1PR11MB4881FA1A2827CD8E5D825796D8259CO1PR11MB4881namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQg NzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBzdHls ZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5BYm91dCDigJw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkFPRFYtUlBMIGNhbiBiZSBvcGVyYXRlZCB3 aGV0aGVyIG9yIG5vdCBuYXRpdmUgUlBMIGlzIHJ1bm5pbmcgb3RoZXJ3aXNlLjwvc3Bhbj48L2Zv bnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBm YWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+4oCcPG86cD48L286 cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIi IGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIGFncmVlIHRo YXQgdGhlIGFkdmVydGlzZW1lbnRzIGNhbiBiZSBkaWZmZXJlbnRpYXRlZDsgc3RpbGwgaXTigJlz IHNpbXBsZXIgdG8gZGlzY291cmFnZSB1c2luZyBib3RoIHByb3RvY29scyBpbiB0aGUgc2FtZSBu ZXR3b3JrLiBXaHkgZG8gc28gc2luY2UgdGhpcyBpcyBlc3NlbnRpYWxseSB0aGUgcmVwbGFjZW1l bnQNCiBwcm90b2NvbD88bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+S2VlcCBzYWZlOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250 PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmki PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5QYXNjYWw8bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2Fs aWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxmb250IHNpemU9IjIi IGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtd2VpZ2h0 OmJvbGQiPkZyb206PC9zcGFuPjwvZm9udD48L2I+IFJvbGwgJmx0O3JvbGwtYm91bmNlc0BpZXRm Lm9yZyZndDsNCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5PbiBCZWhhbGYgT2Yg PC9zcGFuPjwvYj5JbmVzIFJvYmxlczxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi b2xkIj5TZW50Ojwvc3Bhbj48L2I+IGx1bmRpIDMxIGphbnZpZXIgMjAyMiA3OjUyPGJyPg0KPGI+ PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOjwvc3Bhbj48L2I+IHJvbGwgJmx0O3Jv bGxAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1 YmplY3Q6PC9zcGFuPjwvYj4gW1JvbGxdIFdHTEMgZHJhZnQtaWV0Zi1yb2xsLWFvZHYtcnBsLTEy PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZv bnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij5EZWFyIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFj ZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+UGxlYXNlIGZpbmQgYmVsb3cgYSBuZXcgdmVyc2lvbiBvZiBhb2R2LXJwbCBkcmFmdC4g VGhpcyBlbWFpbCBzdGFydHMgYSBXR0xDIG9mIG9uZSB3ZWVrLjxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXpl PSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij5QbGVhc2UgcmV2aWV3IGFuZCBzZW5kIHlvdXIgY29tbWVudHMgYnkgNXRo IEZlYnJ1YXJ5LiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9m b250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9 IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Ob3RlIHRo YXQgdGhpcyBkcmFmdCB1cGRhdGVzIHRoZSBNT1AgdG8gNCZuYnNwOyBbPGEgaHJlZj0iaHR0cHM6 Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9yb2xsL3lORVdZa0tHY3JEV1lmS3hDYUND WDk2bENVWS8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2Fy Y2gvbXNnL3JvbGwveU5FV1lrS0djckRXWWZLeENhQ0NYOTZsQ1VZLzwvYT5dJm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoYW5rIHlvdSw8bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6 ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+SW5lcyBhbmQgRG9taW5pcXVlLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIi IGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+T24gU3VuLCBKYW4gMzAsIDIwMjIgYXQgNzoyNyBQTSAmbHQ7PGEgaHJlZj0ibWFp bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmki PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48YnI+DQpBIE5ldyBJbnRlcm5ldC1EcmFm dCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3Jp ZXMuPGJyPg0KVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgUm91dGluZyBPdmVyIExv dyBwb3dlciBhbmQgTG9zc3kgbmV0d29ya3MgV0cgb2YgdGhlIElFVEYuPGJyPg0KPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRpdGxlJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDs6IFN1cHBvcnRpbmcgQXN5bW1ldHJpYyBMaW5rcyBpbiBMb3cgUG93ZXIg TmV0d29ya3M6IEFPRFYtUlBMPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEF1dGhv cnMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBDaGFybGVzIEUuIFBlcmtpbnM8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUy5WLlIgQW5hbmQ8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgU2F0aXNoIEFuYW1hbGFtdWRpPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEJpbmcgTGl1PGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IEZpbGVuYW1lJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDog ZHJhZnQtaWV0Zi1yb2xsLWFvZHYtcnBsLTEyLnR4dDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBQYWdlcyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiAz Mjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBEYXRlJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiAyMDIyLTAxLTMwPGJyPg0KPGJyPg0KQWJzdHJhY3Q6 PGJyPg0KJm5ic3A7ICZuYnNwO1JvdXRlIGRpc2NvdmVyeSBmb3Igc3ltbWV0cmljIGFuZCBhc3lt bWV0cmljIFBlZXItdG8tUGVlciAoUDJQKTxicj4NCiZuYnNwOyAmbmJzcDt0cmFmZmljIGZsb3dz IGlzIGEgZGVzaXJhYmxlIGZlYXR1cmUgaW4gTG93IHBvd2VyIGFuZCBMb3NzeSBOZXR3b3Jrczxi cj4NCiZuYnNwOyAmbmJzcDsoTExOcykuJm5ic3A7IEZvciB0aGF0IHB1cnBvc2UsIHRoaXMgZG9j dW1lbnQgc3BlY2lmaWVzIGEgcmVhY3RpdmUgUDJQPGJyPg0KJm5ic3A7ICZuYnNwO3JvdXRlIGRp c2NvdmVyeSBtZWNoYW5pc20gZm9yIGJvdGggaG9wLWJ5LWhvcCByb3V0aW5nIGFuZCBzb3VyY2U8 YnI+DQombmJzcDsgJm5ic3A7cm91dGluZzogQWQgSG9jIE9uLWRlbWFuZCBEaXN0YW5jZSBWZWN0 b3IgUm91dGluZyAoQU9EVikgYmFzZWQgUlBMPGJyPg0KJm5ic3A7ICZuYnNwO3Byb3RvY29sIChB T0RWLVJQTCkuJm5ic3A7IFBhaXJlZCBJbnN0YW5jZXMgYXJlIHVzZWQgdG8gY29uc3RydWN0PGJy Pg0KJm5ic3A7ICZuYnNwO2RpcmVjdGlvbmFsIHBhdGhzLCBmb3IgY2FzZXMgd2hlcmUgdGhlcmUg YXJlIGFzeW1tZXRyaWMgbGlua3MgYmV0d2Vlbjxicj4NCiZuYnNwOyAmbmJzcDtzb3VyY2UgYW5k IHRhcmdldCBub2Rlcy48YnI+DQo8YnI+DQo8YnI+DQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0 dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczo8YnI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXJvbGwtYW9kdi1ycGwvIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1yb2xsLWFvZHYt cnBsLzwvYT48YnI+DQo8YnI+DQpUaGVyZSBpcyBhbHNvIGFuIGh0bWxpemVkIHZlcnNpb24gYXZh aWxhYmxlIGF0Ojxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2h0bWwvZHJhZnQtaWV0Zi1yb2xsLWFvZHYtcnBsLTEyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXJvbGwtYW9kdi1ycGwt MTI8L2E+PGJyPg0KPGJyPg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZh aWxhYmxlIGF0Ojxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJs Mj1kcmFmdC1pZXRmLXJvbGwtYW9kdi1ycGwtMTIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1yb2xsLWFvZHYtcnBsLTEyPC9hPjxi cj4NCjxicj4NCjxicj4NCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgcnN5 bmMgYXQgcnN5bmMuaWV0Zi5vcmc6OmludGVybmV0LWRyYWZ0czxicj4NCjxicj4NCjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KUm9sbCBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86Um9sbEBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPlJvbGxAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9yb2xsIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_CO1PR11MB4881FA1A2827CD8E5D825796D8259CO1PR11MB4881namp_--