From nobody Sun Apr 4 09:10:43 2021 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 C1B0F3A0B1D; Sun, 4 Apr 2021 09:10:37 -0700 (PDT) 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.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <161755263773.11775.16590076903859217648@ietfa.amsl.com> Date: Sun, 04 Apr 2021 09:10:37 -0700 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-aodv-rpl-10.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, 04 Apr 2021 16:10:38 -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 : Satish Anamalamudi Mingui Zhang Charles E. Perkins S.V.R Anand Bing Liu Filename : draft-ietf-roll-aodv-rpl-10.txt Pages : 28 Date : 2021-04-04 Abstract: Route discovery for symmetric and asymmetric Point-to-Point (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, in case some of the links between source and target node are asymmetric. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-aodv-rpl/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-roll-aodv-rpl-10 https://datatracker.ietf.org/doc/html/draft-ietf-roll-aodv-rpl-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-aodv-rpl-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 7 12:37:10 2021 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 83CAE3A26A4 for ; Wed, 7 Apr 2021 12:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 UxcsbC0G0OBy for ; Wed, 7 Apr 2021 12:37:05 -0700 (PDT) Received: from mail.mimuw.edu.pl (mail.mimuw.edu.pl [IPv6:2001:6a0:5001::4]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7271A3A2699 for ; Wed, 7 Apr 2021 12:37:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by duch.mimuw.edu.pl (Postfix) with ESMTP id 6BF5C61D63B2C for ; Wed, 7 Apr 2021 21:37:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at mimuw.edu.pl Received: from duch.mimuw.edu.pl ([127.0.0.1]) by localhost (mail.mimuw.edu.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id dy0sEuBRFiZB for ; Wed, 7 Apr 2021 21:36:58 +0200 (CEST) Received: from Konrads-MacBook-Pro.local (unknown [IPv6:2a02:a311:813e:880:8130:4221:d1fc:6827]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by duch.mimuw.edu.pl (Postfix) with ESMTPSA for ; Wed, 7 Apr 2021 21:36:56 +0200 (CEST) From: Konrad Iwanicki Reply-To: Routing Over Low power and Lossy networks To: Routing Over Low power and Lossy networks References: <49ac5fc3-4a3c-fb87-d366-eb7e7cfd60df@mimuw.edu.pl> <18233.1583176305@localhost> Message-ID: <10272666-28c7-ab3e-9ceb-1b8f2bb6e5e5@mimuw.edu.pl> Date: Wed, 7 Apr 2021 21:36:54 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Roll] Border router failure detection 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, 07 Apr 2021 19:37:09 -0000 Dear all, Approximately a year ago, I joined the WG and advertised an extension to RPL that I had been working on for some time with a goal of describing it in a draft. Unfortunately, just when I got the necessary pointers and a few initial comments, the pandemic broke out. The resulting surge of professional and personal obligations made it literally impossible for me to participate in and, at some point, even follow the group's activities, for which I am sorry. However, I did strive to regularly find a little time to get somewhat acquainted with IETF's procedures and write up something that may resemble a draft. I have just submitted it as: draft-iwanicki-roll-rnfd-00 and created a dedicated repository on the group's GitHub. Since I have no experience writing IETF documents, I would really appreciate your collaboration on either turning the text into a true draft or concluding that this should not be done. Please, keep mind in mind that I decided to maximally cut down the original algorithms, so that the extension is as simple as possible without losing key properties. Therefore, it is likely that if the extension as a whole or any of its parts turn out relevant or interesting, still a considerable amount of work may be necessary to have it or them described properly. Your contribution is most welcome. Thanks in advance. Best regards, -- - Konrad Iwanicki. From nobody Wed Apr 7 16:46:34 2021 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 417E03A2EDE for ; Wed, 7 Apr 2021 16:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ePK3sWQTA7GO for ; Wed, 7 Apr 2021 16:46:28 -0700 (PDT) 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 2CC4F3A2EDD for ; Wed, 7 Apr 2021 16:46:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 7FDB638FD8 for ; Wed, 7 Apr 2021 19:53:16 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WqwZMh1KWSgC for ; Wed, 7 Apr 2021 19:53:15 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 16C3B38FD7 for ; Wed, 7 Apr 2021 19:53:15 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 249C348B for ; Wed, 7 Apr 2021 19:46:24 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: <10272666-28c7-ab3e-9ceb-1b8f2bb6e5e5@mimuw.edu.pl> References: <49ac5fc3-4a3c-fb87-d366-eb7e7cfd60df@mimuw.edu.pl> <18233.1583176305@localhost> <10272666-28c7-ab3e-9ceb-1b8f2bb6e5e5@mimuw.edu.pl> 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 Archived-At: Subject: Re: [Roll] Border router failure detection 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, 07 Apr 2021 23:46:33 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Konrad Iwanicki wrote: > draft. Unfortunately, just when I got the necessary pointers and a few > initial comments, the pandemic broke out. I know the feeling. I keep thinking I should be able to do *more* since I can't go out. > draft-iwanicki-roll-rnfd-00 > and created a dedicated repository on the group's GitHub. I see it at: https://github.com/roll-wg/draft-rnfd You might want to add a Makefile, either via https://github.com/martinthomson/i-d-template/blob/master/doc/SETUP.md or rip of my minimal one, such as: https://github.com/roll-wg/draft-ietf-roll-enrollment-priority/blob/mas= ter/Makefile > Since I have no experience writing IETF documents, I would really app= reciate > your collaboration on either turning the text into a true draft or co= ncluding > that this should not be done. It looks like you did a really good job. RPL is being used in storing mode the ANIMA WG's Autonomic Control Plane. See: https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-pl= ane/ ( section 6.12. ). The document is minutes away from getting an RFC#. We think that the border router, DODAG root, will be a device in the NOC. The NOC may get replicated into multiple locations so there could potential= ly be more than one candidate DODAG root. Given nodes are not constrained in the RFC7228 sense, supporting multiple DODAGs could be done, but we simplified our life by not mandating (actually, at this point, forbidding) the RPI header, so we are lacking an instanceID. The short of it is that I'd really like nodes to be able to float non-grounded DODAG roots if they don't hear a DIO after a few seconds. =2D--- It seems that you might want a term for the LBR's children. That is, the devices at rank "1", that hear the LBR's DIOs. I think that I would move some of section 3.2 further forward in the document. I think that I need a gentler introduction to CFRCs here, and I don't really need to know the properties, rather I need a higher-level idea of things. Since section 4 goes over the operations again, I would leave it for that spot, and make it a section 4.1. Having gone forward and back a bit, I'm still a bit uncertain how nodes assign themselves a bit... oh, self() in section 4 says "random". Why not make this a function (hash?) of the short-IPv6 address or something? Not every media has ACK frames at the L2 to establish that there are failures. It might be worth putting the Detecting and the Verifying into separate sections. Aside from the ANIMA case (which is usually pure ethern= et), there are also situations where there is an ethernet backbone connecting a few 6LBRs (RFC8929), and your protocol would sensibly run on both the wireless and the wired side of the 6LBRs. I also wonder if the RNFD could be included in DAOs (particularly storing mode ones) sent to the DODAG root. I know that probably seems senseless: why tell the root that you are observing it to be dying.... But, it acts as interesting telemetry about what the nodes are seeing, and might serve as a useful indication of immine= nt failure, or some kind of systematic long-cycle pathology. Your IANA considerations are how the document will look after IANA has processed it. Prior to that point, you need to write it as a request. Something like: IANA is requested to allocate the value TBD1 from the "RPL Control Messa= ge Options" sub-registry of the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry. I like to include the URL of the registry in my request to be really really clear, and to save everyone else the time to find it. Your security considerations will want to cite RFC7416. In particular, 7.2.4, and section 7.3.4 and 7.3.5 might be relevant. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmBuRE8ACgkQgItw+93Q 3WVPIAf9H1QPs7O3wvS3KkrYPwm/KSFPHrBVvRWB6jUQ/4bmoyOL95DBddCdPhO3 rI1cxwPQA3IFbf2ESbsHt+1COC9+yn/ZdwxOHu5XILG3i1UMO9HuTx/MxTFLXUP7 tgtVujmanHzh+asDNC84DZBj37JR3t4RGNnuuVPhhaevOAPvb3vCe7c2j575x49/ c16V3PxmsH5v/qQTHKO8AuD130OlD2g/dc2bS0L8tO6rovG30SPwavTAtSNLQTOC qj/P2uLOz8evpOhSKmnLlNu0FXQ4a1lH53bIUt0X7vp4LlgYn3d8t53mY7APcdr8 s1qLVW293OXB74RXq6Cgdk085dryxg== =6+U/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 8 07:06:09 2021 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 E04E43A18D4 for ; Thu, 8 Apr 2021 07:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.619 X-Spam-Level: X-Spam-Status: No, score=-9.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=CokrEPdL; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=yHXQfKTm 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 QDz8effjcGI8 for ; Thu, 8 Apr 2021 07:06:01 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 834DE3A18D3 for ; Thu, 8 Apr 2021 07:06:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7440; q=dns/txt; s=iport; t=1617890761; x=1619100361; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=pll7V00HBKdmdgMRam4P1frxM1RW8CRpycy0wsNzy68=; b=CokrEPdLSohIf8GE+w0LWNZ3y9My2AKuk/dconapL5O/aOZRkZaxWPjf aOeRZ0LkG41SkP8+AQsu+vTxi2Zq2Q7I7oHd5FqIAFA1uklSGbSZiKkmr 304iBINn8NGYiBmjW+JkhSp2EZNBkZoW7RhbqtdBI8FWNZ2qLyLxWdtX8 o=; X-IPAS-Result: =?us-ascii?q?A0DlCQCGDG9g/5xdJa1agQmDJVEHd1o2MYRCg0gDhTmIT?= =?us-ascii?q?gOPJ4VNhEeBQoERA1QBCgEBAQ0BASgKAgQBAYFbgnUCF4FgAiU4EwIDAQEBA?= =?us-ascii?q?wIDAQEBAQEFAQEBAgEGBHEThVANhkQBAQEBAyMRDAEBOAsEAgEIEQQBAQECA?= =?us-ascii?q?iYCAgIwFQgIAgQTCBGCWYJVAy8BDqAtAoofd4EygQGCBAEBBoFHQYMfGIITA?= =?us-ascii?q?waBDyqCdoJxUEiGTiccgUlCgRNDgl8+gmACAgGBPwUbgxU1giuBWWtqAQMdJ?= =?us-ascii?q?hAvQgodgRNJA5QGk3OSTwqDC4ljhx2MH4lNmySgf5JWCBgBD4Q5AgQCBAUCD?= =?us-ascii?q?gEBBoFrI4FZcBWDJFAXAg6OKgEWg06FFIVFczgCBgEJAQEDCXyMFQEB?= IronPort-PHdr: A9a23:TiG8rRK0uSVS6wq7LdmcuZcyDhhPgJ39IxIV55w7irlHbqWk+dH4M VfC4el25HfIUJnVrfVehLmev6PhXDkG5pCM+DAHfYdXXhAIwcMRg0Q7AcGDBEG6SZyibyEzE MlYElMw+Xa9PBtUFdrwIVrIrS764TsbAB6qMw1zK6z8EZLTiMLi0ee09tXTbgxEiSD7b6l1K UC9rB7asY8dho4xQps= IronPort-HdrOrdr: A9a23:TLk4pq45XAwfmVzlJAPXwaiFI+orLtY04lQ7vn1ZYSd+NuSFis Gjm+ka3xfoiDAXHEotg8yEJbPoexLh3LZPy800Ma25VAfr/FGpIoZr8Jf4z1TbdRHW3tV2kZ 1te60WMrLNJHBxh8ri/U2cG9Ev3NGI/MmT9Jjj5l1qShxnbLwlyg9/BBqSHEEefng5ObMSEp 2A6s1b4we6cXMMYcihQlUDVe7Pp9rE/aiWICIuLRgh9QWIkHeU+Kf3eiLokCs2fhFu5fMZ8W bDmxHk/anLiZGG4zLVymO71eUvpPLNxtROH9eBh4w5JjDtlQqydO1aKsa/lR8vpuXH0idOrP DtpFMaM913+zfteAiO0GfQ8i3B9Bpr1HP401+fhhLY0IzEbRY3EdBIi44cUjax0TtbgPhG3K hG332UuvNsZHuq9kmQlru4NS1CrUa6rWEvluQelRVkIPYjQYVMpo8S9l49KuZmIAvG6ZsqGO QrLMbQ6Oc+SyLiU1nlv3JiyNHpY3IrHh3ueDllhuWp1VFt7RRE5npd4PZasmYL9Zo7RZUBzf /DKL5UmLZHSdJTRb5hBc8aKPHHSVDlcFbpCia/MF7nHKYINzbmsJjs+og44+msZdgh0IYyop LcS1lV3FRCOX7GOImr5tlm4xrNSGKyUXDG0cdF/aV0vbX6Wf7NPTCcTkst1++tue8WDMGee/ vbAuMSP9bTaU/VXapZ1Qz3XJdfbVMEVtcOh9o9U1WS5s3RLInnsfHabebTKLLhHS1MYBK5Pl IzGBzIYOlQ5EGiXXH1xDLLXWn2R0D59ZVsVKjWltJjjrQlB8lpiEw4mF657saEJXlpqaotZn ZzJ7vhj+e+rWmy9mDY8nVxNnNmfx9oyYSld0kPiR4BMkvyf7pGkc6YY3pu0HyOIQI6SdjXHg 5Zr1F+4rm2MJSU2CAnB7ucQyanpkpWgEjPY4YXm6WF68ugUIg/FIwaVKt4EhiOCwZ4gh9wqG BIaBYNQ0jWEj+Gs9T8sLUkQMXkM/VsigaiJsBZ7U/FvUKHvMc1Wz8wRDi1S/Oahg4oWhtZjl B86LUknbKFgDqjQFFP29gQARlpUiC3CKgDJBmZbI9U84qbCT1YfCOvv3imrD0dPkDt7F4fg2 T9Kzb8Q4C6PnNt/lZC0qjr91tocH66ZEwYUAEhjaRNUULbp310zeiHIo203mf5UCpf/sgtdB fYfDAVPgRig+qS6SfQsjODGXI6r69eY9D1BKg/cr3Vx3OmIJCJk6ZDBPNP4JN5LrnVw5w2eP PadAmPIDziDeQ1nwSTu3Y+ISFx7GIpiPXyxXTenSWF9W96BfrZO1J9Qb4HZ9ma8mj/Xv6Nua 8Jxu4drK+1Mm/rbMSBxrySZzlfKgnLqWrzS+0zs5hbseYzs7R0dqOrGwfgxTVC3B8kKt3zm1 5bSKNn4KrZMosqZtcMYUtijywUvcXKKFFuvh39A+c4c11oh3jHP8mR676NrbY0GEWOqAb5JF H3yVwQw97VGy+YkbIKAaM5JmpbLFIx73lv5+uOfYzdAgfCTZAKwHOqdnumNLNNQqmMHrsd6g tg69aThumNam723hvTsTYTGNMAz0+3BcepRASCFu5D/4bkZRCCgq627NWyizmyQz2hcEgcjZ BEc0tVbskrsEhXsKQnliypDqrwqQY5llEb5zdtnFvkwJKn72fWBlsuC3yRvrxGGT1IdmGVhs HE+/WC3Hvz4DJZyYDOfX0gC+1mCpwVVMzrNC9gJsgboa6w86cuiipFZg0yD2RUskGL48p2mb Gj2PvTXOX+CXDnfVIZkAQ1dLJJog== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,206,1613433600"; d="scan'208";a="677336047" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Apr 2021 14:05:59 +0000 Received: from mail.cisco.com (xbe-rcd-001.cisco.com [173.37.102.16]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 138E5xXu027747 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for ; Thu, 8 Apr 2021 14:05:59 GMT Received: from xfe-aln-002.cisco.com (173.37.135.122) by xbe-rcd-001.cisco.com (173.37.102.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Thu, 8 Apr 2021 09:05:59 -0500 Received: from xfe-rcd-002.cisco.com (173.37.227.250) 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.792.3; Thu, 8 Apr 2021 09:05:58 -0500 Received: from NAM02-BL2-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.792.3 via Frontend Transport; Thu, 8 Apr 2021 09:05:58 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=c+srAdVal6FLW4LREX0dviCHzukKvur+UzEv60BulS1y9NEfXytBSdWmTkzoGpbWJVCqvxBU0kazv06c1R0cuvMI2gtD2bllcrqJsVs3oYwtF8VSGokeUBTtD2IQ3dcSfQydB8tg7yiNGReCphb83uOc5mnSAsGmpIYzePAHdOX6YTxMUTADjYxOG6u0PobtH4qpriS8sf+hSly6xdQb3bVNl38hz9HHlk/n41CSlgC9Fjyd8YI8TqpT0+9yGIdos6EmZED+G/EwPCRtIraEDPNvbUdlMUa+7fyzTl3mYYf7kFOFCnYFyGs+NcLIEI+KxnooYJHparUDfTzj5Gd6LA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pll7V00HBKdmdgMRam4P1frxM1RW8CRpycy0wsNzy68=; b=EJ4byNT85FUzGzcf5xz7lTGt8N+93qUkt6rCPPh3mDf/eeB8l/bZDh8yKCNtxfu5lKytRqnVDLxDvBSODdzE+Fio/9FJR25Kvan+Tntu238HLH2Up4gCOodPtaWZJEzkUxBPrF5ZYUGJkm0ZimWqX5yqdh0nHgzDkB6ZuUN6IZ7HvzsAaxVL8k9d+9eBbMTL0JFSFFp7WL0//1oi1KbNY7eZ9SNDMgMzJ594scYZqZp3es6pCBNbaPtJEW9QGEwF2qK2RQlst+gCtcE8jbf6MaRv5oDi0RjpIlQq1j9v2bUVoJ2i9910a7aD50n2EJP2haDhHenZjm0FTRzBEaq4lw== 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=pll7V00HBKdmdgMRam4P1frxM1RW8CRpycy0wsNzy68=; b=yHXQfKTm+HmFrhdbsSpGoPUM9hR/2nVkbICJj0lkjrvYEEsbYz7C8ap5eSwmhtyyHlOTbCvmgp+LQp1iiTZQlpklzMUNX/+wAlhwYuyMofFI9XWYYefvmXNtLW30hG7Hi4v2J4HM6aKJc5lLFSTa7FwZOWoAvdHCI9msdOGmdsQ= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by CO1PR11MB4964.namprd11.prod.outlook.com (2603:10b6:303:9e::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3999.28; Thu, 8 Apr 2021 14:05:56 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::cd01:ffc9:6592:b1d5]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::cd01:ffc9:6592:b1d5%6]) with mapi id 15.20.3999.032; Thu, 8 Apr 2021 14:05:56 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Border router failure detection Thread-Index: AQHXK+V11ZIg9ppwIUWAf2h5ir/s+6qpuKQAgADqrQA= Date: Thu, 8 Apr 2021 14:05:53 +0000 Deferred-Delivery: Thu, 8 Apr 2021 14:05:09 +0000 Message-ID: References: <49ac5fc3-4a3c-fb87-d366-eb7e7cfd60df@mimuw.edu.pl> <18233.1583176305@localhost> <10272666-28c7-ab3e-9ceb-1b8f2bb6e5e5@mimuw.edu.pl> <8372.1617839184@localhost> In-Reply-To: <8372.1617839184@localhost> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2a01:cb1d:4ec:2200:8832:c2f1:a513:23ff] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b41651ae-f773-4aaa-d96c-08d8fa976e1b x-ms-traffictypediagnostic: CO1PR11MB4964: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZkyrjhFo5QzLHzqOXcuIONXw2p+a7GX64yDvvkMngduX3QPa0oZ6d8k0i7g3pVCnmWt3WOFwS73baJ0AsgD6iJpLikpYHYX2sQeOQ7lg9c3vL7lYKufZSSAo3gy6O3XVEpiCvuMrK/i2L5LEK4Yjr+l2fxMj1nQTSNysh8QkbowuwDo/HkcJmtk56rABQ8eC9e8/qiFcn4EV1sjEbtG9gD5a6wl6BcrOUJ9lDoboHNrlpOB2sSDr6vLRTJIIcUrGdWFHQ4fipksls1u0c6uuPPOBHAXhhs0T3oLjVvTdjcv32w6zePuEbkzJsQhGCdxUEbSx6EBMUZZRcsSTPLH0B1b59aSjHzX36mnxXctDiMfU9oQdyN72qSSUYIOjf5Ztp1lsRjPCRJcTTWzSz+gBkQRU1T9kSYzR5/XB54Jz6NEFwZ6rDl5elQc4o4dI8hkqVUaS68azppXjXoofSr2HuAKOFclbolKWpGHYDA/1ir8zB7bAvsGsVE2umEiFoPfJ6sZF2OQDIMEfJoQDbFBEqBj6To0+yk3sPnunsALFLsQg13Mk/ciqCmRuzS6PPHznxhlMvfS0npHmHmGFRXoUS+uIS0xJd11npc1xoVahmYfXDJleZKvsiJVuinMhlUccEX4m2co4wnI7EmragfjAJcc2iVLnF0XkAjk3pyR7ErngR3opqWLq33eu3kOqoan1aOkhU3Md1uiaEP4H+owlLKMfltKMGwVBVulNXFi26Kw= 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:(396003)(39860400002)(136003)(376002)(346002)(366004)(53546011)(6506007)(66946007)(7696005)(5660300002)(71200400001)(33656002)(966005)(66476007)(66556008)(55016002)(66446008)(2906002)(186003)(64756008)(86362001)(66574015)(76116006)(8676002)(6916009)(6666004)(83380400001)(38100700001)(316002)(478600001)(8936002)(52536014)(9686003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?cGhBRER5ekg0MjB6K0k4c2JMb1ltdUV0NGlNNXJndDJzUEZ5S3NUb0lEVHpq?= =?utf-8?B?ZThJYXVMa0VYeUF3VjNnSTR3S3k1U0ExWDZSSzF6Q0tZc3JJU1pEM1ZVeVQr?= =?utf-8?B?cFpCdkFEUysxZDF1WU5tU01lSnRveXR6ZGdxQnhuQVcrMWgxYWY1cGdhWCtT?= =?utf-8?B?azFDYVRjKzZFblV2NUxPdHBHTWl1bGZvaVc5ODV5V0dWS0tOTlU0eHJZN2I4?= =?utf-8?B?V2ppaWhYSW1nWDV0a2RLVFFuaTd1cUR0VXhRNHpkNGJFaisyM2R1RzYwQ2dM?= =?utf-8?B?eXhZMWM1Z3d2TUYvU2ppWk04Skh5QTVMZENVNGFTTTdYQ1llK0hXL3E1dTE2?= =?utf-8?B?aTQrMEZJVDhnTzFzSC82Qi9WM3FoTjBkZ0Z5djg5dFZXZ20rQjFPdGFEZ0ti?= =?utf-8?B?dTVvWEJHelNKT0hYWGtLRDlkcTZ2VTVmWGs3ODg0ckttSDQ5aW5QN0dPVFNZ?= =?utf-8?B?OHVlblQ2NytjWUlISTcycGl0N0RIdnQwWnBBWmVnbEJZWDRCaGRaQ1BHL0M5?= =?utf-8?B?UE4rZy9uR1g0ZmhyQ0l3alRMOVl2SzViZXZoMFBIM2tyNlBES2l2YXRSbU04?= =?utf-8?B?YkNFRWx1RjRXaVN4clBycStzNENHeXQrLzZZajhkakdLcENkZ2xQdXo4S3NM?= =?utf-8?B?V0FPOGJBOW9KZDdGN21hTkgvL2tZeHlOMHA2d1NVaWc0TlFoZ3RibkFUczFm?= =?utf-8?B?TnZTNDdsS1pENlhFR0c5K00vdFNIMTdMM1VuNnMyNFZhdzJtYWtxS2p3ZlZF?= =?utf-8?B?UDRVSWM5dnlLQXB4a2JWb0FLNjBNR0Y3bG10VnZlS3VwYzNTbmdDc0hDQjNU?= =?utf-8?B?cndDTkJnS0lSL3lCRi9qSXh6cTdvUkxhaXQydUNaUlM0Y3ZDa2h4UFJzS2tO?= =?utf-8?B?c0ZKWGZWNFM5S0JQNVVNdUU1U2d4ZDUyVkNzYzJYRkhBYWVhbkQ3R2wzcHFM?= =?utf-8?B?WVQxZDJnbkJtS0FUY0x4V29ZT0YrQ3VNdnduRy9CbTlkMCs5b1dYYW5BOXVo?= =?utf-8?B?RUMxc0M3VklLZStvd0paMWFLTk51MlFRQnBPay8yamxtdExpUUxOOUxQdmtJ?= =?utf-8?B?a25yLy9hclYvUnVKeGhtK3A4dkp6UGJJYkRvalgvN3ZHMnMxSXA3S05xVVlS?= =?utf-8?B?NEdqOXAxUjh1eE42L1lIKzBTanByWEdZQzdHYWsvNC94S3ZqZFQwcXk2MlF4?= =?utf-8?B?R3FIS0tqN1BGWFc2RnBEVEt6dFBYenlHWHRUMFNZV2E3WDdFZEVWazd4VDBr?= =?utf-8?B?aWFPRUVLa3FDUjlWYUtHejVmR203ZDBQTzhKazJEd2hCL3MxRzZmekZJbVVx?= =?utf-8?B?QUpZWDU2L091aXFjTllhR0dIUFZKbG9lZ3hELzBpejNKUFR4amtsOG9vYVZz?= =?utf-8?B?bVNCbHNGcWVPT2lhSkhuRGZSTVBEbGRHUmdueWhCWXVNYWtIV2syM1Q0UmVM?= =?utf-8?B?Z0xBb1hLak9uSlh1QlFKREs3M0dwcUN5WUFkbkVWQkQvV2hsK2tSTkNwRTgy?= =?utf-8?B?dVZ4LzNYdGJ3emV4NmRsWHplQktmNldDMmt1YURQZThFSDVKT1FLVnRYbXps?= =?utf-8?B?ZTNzUDl0bkhYWUlCZlhJdFYrbnVjbzQ4bFRoaG5DZCszcWZsV2JQWHlQeWdH?= =?utf-8?B?SHRoV05aUDRrNmVqRnFqb3hlYlFCeGwyemI4eXl2aUU3bXFuTVZ3d3drbFlj?= =?utf-8?B?NDcrNWVFU1RKT3M2enU2NG5IME5zUi9KbUliL0F5dEFUY01jb0FpN2JFOWFn?= =?utf-8?B?NnV0b3UyY3JtYXY2Zm5RL2RSQjFtUXNqVy9JQ3VwbmJ1aXhLdkd4MUZZSmdJ?= =?utf-8?B?a0FjWnkxUEVEenU1T3lpaEd1anBFZ0ZRSDE1RGJXdXR5Y2N6cVFjL25jSVZo?= =?utf-8?Q?OJXLnas0kRsUx?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 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: b41651ae-f773-4aaa-d96c-08d8fa976e1b X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2021 14:05:56.5447 (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: qVBs69r9RMiKCapqirArN/qv122DO+grh/sbvAQSOI/IfRcRb6C/8Y+Gq0oIYmAQ7HjnQPLHgI0We83hQjnunQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB4964 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.16, xbe-rcd-001.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [Roll] Border router failure detection 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, 08 Apr 2021 14:06:07 -0000 SGVsbG8gTWljaGFlbCBhbmQgS29ucmFkDQoNCkkgY29uY3VyIHRoYXQgdGhpcyBpcyBleGNlbGxl bnQgd29yayBhbmQgdGhhdCB3ZSB3YW50IHRvIGRpc2N1c3MgaXQuIEFzIGNvbnRleHQ6DQoNCklm IEkgbWF5IGFkZDogQXQgdGhlIChlYXJseSkgdGltZSBJIGNvbnRyaWJ1dGVkIHRvIHRoZSBBQ1Ag ZGVzaWduLCB0aGUgaWRlYSB3YXMgdGhhdCB0aGUgUm9vdCdzIGNoaWxkcmVuIHdlcmUgY29uZmln dXJlZCB3aXRoIGEgRE9EQUdQcmVmZXJlbmNlIChwcmYpIHRoYXQgaXMgbW9yZSB0aGFuIHRoZSBk ZWZhdWx0IHZhbHVlIChvZiAwKSBpbnNpZGUgdGhlIG5ldHdvcmsuIERpZmZlcmVudCBjaGlsZHJl biBtYXkgYmUgZ2l2ZW4gZGlmZmVyZW50IHByZiB0byBlbmZvcmNlIGFuIG9yZGVyIGluIHdoaWNo IHRoZXkgYmVjb21lIHRoZSByZXBsYWNlbWVudCBmb3IgdGhlIExCUiBzZXJ2aW5nIGFzIFJvb3Qu IA0KDQpXaGVuIGxvc2luZyBjb25uZWN0aXZpdHkgdG8gdGhlIExCUiwgYSBjaGlsZCB0aGF0IGRv ZXMgbm90IGhhdmUgY29ubmVjdGl2aXR5IHRvIHRoZSBtYWluIERPREFHIGJlY29tZXMgZmxvYXRp bmcgUm9vdCBvZiBpdHMgb3duIERPREFHLiBJZiB0aGUgTEJSIGRpZXMsIGFsbCB0aGUgY2hpbGRy ZW4gbG9zZSB0aGVpciBwYXJlbnQsIGFuZCB0aGUgZmxvYXRpbmcgRE9EQUcgcmVmb3JtcyBmcm9t IHRoZSBjaGlsZCB3aXRoIHRoZSBoaWdoZXN0IHByZi4gTm9kZXMgdGhhdCBhcmUgd2lsbGluZyB0 byBqdW1wIHRvIGFuIGFsdGVybmF0ZSBET0RBRyB0aGF0IGlzIGdyb3VuZGVkIHdpbGwgZG8gc28u IFRoaXMgaXMgc3VwcG9zZWQgdG8gYmUgc29tZXdoYXQgZmFzdCBiZWNhdXNlIHRoZSBUcmlja2xl IHRpbWVycyBhcmUgcmVzZXQuDQoNCkkgdW5kZXJzdGFuZCB0aGF0IHRoZSBpZGVhIGhlcmUgaXMg dG8gYmUgZmFzdGVyIHRoYW4gdGhhdC4gDQoNCktlZXAgc2FmZTsNCg0KUGFzY2FsDQoNCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUm9sbCA8cm9sbC1ib3VuY2VzQGlldGYu b3JnPiBPbiBCZWhhbGYgT2YgTWljaGFlbCBSaWNoYXJkc29uDQo+IFNlbnQ6IGpldWRpIDggYXZy aWwgMjAyMSAxOjQ2DQo+IFRvOiBSb3V0aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBMb3NzeSBuZXR3 b3JrcyA8cm9sbEBpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFtSb2xsXSBCb3JkZXIgcm91dGVy IGZhaWx1cmUgZGV0ZWN0aW9uDQo+IA0KPiANCj4gS29ucmFkIEl3YW5pY2tpIDxpd2FuaWNraUBt aW11dy5lZHUucGw+IHdyb3RlOg0KPiAgICAgPiBkcmFmdC4gVW5mb3J0dW5hdGVseSwganVzdCB3 aGVuIEkgZ290IHRoZSBuZWNlc3NhcnkgcG9pbnRlcnMgYW5kIGENCj4gZmV3DQo+ICAgICA+IGlu aXRpYWwgY29tbWVudHMsIHRoZSBwYW5kZW1pYyBicm9rZSBvdXQuDQo+IA0KPiBJIGtub3cgdGhl IGZlZWxpbmcuDQo+IEkga2VlcCB0aGlua2luZyBJIHNob3VsZCBiZSBhYmxlIHRvIGRvICptb3Jl KiBzaW5jZSBJIGNhbid0IGdvIG91dC4NCj4gDQo+IA0KPiAgICAgPiBkcmFmdC1pd2FuaWNraS1y b2xsLXJuZmQtMDANCj4gDQo+ICAgICA+IGFuZCBjcmVhdGVkIGEgZGVkaWNhdGVkIHJlcG9zaXRv cnkgb24gdGhlIGdyb3VwJ3MgR2l0SHViLg0KPiANCj4gSSBzZWUgaXQgYXQ6DQo+ICAgaHR0cHM6 Ly9naXRodWIuY29tL3JvbGwtd2cvZHJhZnQtcm5mZA0KPiANCj4gWW91IG1pZ2h0IHdhbnQgdG8g YWRkIGEgTWFrZWZpbGUsIGVpdGhlciB2aWENCj4gICAgIGh0dHBzOi8vZ2l0aHViLmNvbS9tYXJ0 aW50aG9tc29uL2ktZC10ZW1wbGF0ZS9ibG9iL21hc3Rlci9kb2MvU0VUVVAubWQNCj4gb3Igcmlw IG9mIG15IG1pbmltYWwgb25lLCBzdWNoIGFzOg0KPiAgICAgaHR0cHM6Ly9naXRodWIuY29tL3Jv bGwtd2cvZHJhZnQtaWV0Zi1yb2xsLWVucm9sbG1lbnQtDQo+IHByaW9yaXR5L2Jsb2IvbWFzdGVy L01ha2VmaWxlDQo+IA0KPiAgICAgPiBTaW5jZSBJIGhhdmUgbm8gZXhwZXJpZW5jZSB3cml0aW5n IElFVEYgZG9jdW1lbnRzLCBJIHdvdWxkIHJlYWxseQ0KPiBhcHByZWNpYXRlDQo+ICAgICA+IHlv dXIgY29sbGFib3JhdGlvbiBvbiBlaXRoZXIgdHVybmluZyB0aGUgdGV4dCBpbnRvIGEgdHJ1ZSBk cmFmdCBvcg0KPiBjb25jbHVkaW5nDQo+ICAgICA+IHRoYXQgdGhpcyBzaG91bGQgbm90IGJlIGRv bmUuDQo+IA0KPiBJdCBsb29rcyBsaWtlIHlvdSBkaWQgYSByZWFsbHkgZ29vZCBqb2IuDQo+IA0K PiBSUEwgaXMgYmVpbmcgdXNlZCBpbiBzdG9yaW5nIG1vZGUgdGhlIEFOSU1BIFdHJ3MgQXV0b25v bWljIENvbnRyb2wgUGxhbmUuDQo+IFNlZTogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1hbmltYS1hdXRvbm9taWMtY29udHJvbC0NCj4gcGxhbmUvDQo+ICggc2Vj dGlvbiA2LjEyLiApLiAgIFRoZSBkb2N1bWVudCBpcyBtaW51dGVzIGF3YXkgZnJvbSBnZXR0aW5n IGFuIFJGQyMuDQo+IA0KPiBXZSB0aGluayB0aGF0IHRoZSBib3JkZXIgcm91dGVyLCBET0RBRyBy b290LCB3aWxsIGJlIGEgZGV2aWNlIGluIHRoZSBOT0MuDQo+IFRoZSBOT0MgbWF5IGdldCByZXBs aWNhdGVkIGludG8gbXVsdGlwbGUgbG9jYXRpb25zIHNvIHRoZXJlIGNvdWxkDQo+IHBvdGVudGlh bGx5IGJlIG1vcmUgdGhhbiBvbmUgY2FuZGlkYXRlIERPREFHIHJvb3QuICBHaXZlbiBub2RlcyBh cmUgbm90DQo+IGNvbnN0cmFpbmVkIGluIHRoZSBSRkM3MjI4IHNlbnNlLCBzdXBwb3J0aW5nIG11 bHRpcGxlIERPREFHcyBjb3VsZCBiZQ0KPiBkb25lLCBidXQgd2Ugc2ltcGxpZmllZCBvdXIgbGlm ZSBieSBub3QgbWFuZGF0aW5nIChhY3R1YWxseSwgYXQgdGhpcw0KPiBwb2ludCwgZm9yYmlkZGlu ZykgdGhlIFJQSSBoZWFkZXIsIHNvIHdlIGFyZSBsYWNraW5nIGFuIGluc3RhbmNlSUQuDQo+IA0K PiBUaGUgc2hvcnQgb2YgaXQgaXMgdGhhdCBJJ2QgcmVhbGx5IGxpa2Ugbm9kZXMgdG8gYmUgYWJs ZSB0byBmbG9hdCBub24tDQo+IGdyb3VuZGVkIERPREFHIHJvb3RzIGlmIHRoZXkgZG9uJ3QgaGVh ciBhIERJTyBhZnRlciBhIGZldyBzZWNvbmRzLg0KPiANCj4gLS0tLQ0KPiANCj4gSXQgc2VlbXMg dGhhdCB5b3UgbWlnaHQgd2FudCBhIHRlcm0gZm9yIHRoZSBMQlIncyBjaGlsZHJlbi4NCj4gVGhh dCBpcywgdGhlIGRldmljZXMgYXQgcmFuayAiMSIsIHRoYXQgaGVhciB0aGUgTEJSJ3MgRElPcy4N Cj4gDQo+IEkgdGhpbmsgdGhhdCBJIHdvdWxkIG1vdmUgc29tZSBvZiBzZWN0aW9uIDMuMiBmdXJ0 aGVyIGZvcndhcmQgaW4gdGhlDQo+IGRvY3VtZW50LiAgSSB0aGluayB0aGF0IEkgbmVlZCBhIGdl bnRsZXIgaW50cm9kdWN0aW9uIHRvIENGUkNzIGhlcmUsIGFuZCBJDQo+IGRvbid0IHJlYWxseSBu ZWVkIHRvIGtub3cgdGhlIHByb3BlcnRpZXMsIHJhdGhlciBJIG5lZWQgYSBoaWdoZXItbGV2ZWwN Cj4gaWRlYQ0KPiBvZiB0aGluZ3MuICAgIFNpbmNlIHNlY3Rpb24gNCBnb2VzIG92ZXIgdGhlIG9w ZXJhdGlvbnMgYWdhaW4sIEkgd291bGQNCj4gbGVhdmUNCj4gaXQgZm9yIHRoYXQgc3BvdCwgYW5k IG1ha2UgaXQgYSBzZWN0aW9uIDQuMS4NCj4gDQo+IEhhdmluZyBnb25lIGZvcndhcmQgYW5kIGJh Y2sgYSBiaXQsIEknbSBzdGlsbCBhIGJpdCB1bmNlcnRhaW4gaG93IG5vZGVzDQo+IGFzc2lnbiB0 aGVtc2VsdmVzIGEgYml0Li4uIG9oLCBzZWxmKCkgaW4gc2VjdGlvbiA0IHNheXMgInJhbmRvbSIu DQo+IFdoeSBub3QgbWFrZSB0aGlzIGEgZnVuY3Rpb24gKGhhc2g/KSBvZiB0aGUgc2hvcnQtSVB2 NiBhZGRyZXNzIG9yDQo+IHNvbWV0aGluZz8NCj4gDQo+IE5vdCBldmVyeSBtZWRpYSBoYXMgQUNL IGZyYW1lcyBhdCB0aGUgTDIgdG8gZXN0YWJsaXNoIHRoYXQgdGhlcmUgYXJlDQo+IGZhaWx1cmVz LiAgSXQgbWlnaHQgYmUgd29ydGggcHV0dGluZyB0aGUgRGV0ZWN0aW5nIGFuZCB0aGUgVmVyaWZ5 aW5nIGludG8NCj4gc2VwYXJhdGUgc2VjdGlvbnMuICBBc2lkZSBmcm9tIHRoZSBBTklNQSBjYXNl ICh3aGljaCBpcyB1c3VhbGx5IHB1cmUNCj4gZXRoZXJuZXQpLCB0aGVyZSBhcmUgYWxzbyBzaXR1 YXRpb25zIHdoZXJlIHRoZXJlIGlzIGFuIGV0aGVybmV0IGJhY2tib25lDQo+IGNvbm5lY3Rpbmcg YSBmZXcgNkxCUnMgKFJGQzg5MjkpLCBhbmQgeW91ciBwcm90b2NvbCB3b3VsZCBzZW5zaWJseSBy dW4gb24NCj4gYm90aCB0aGUgd2lyZWxlc3MgYW5kIHRoZSB3aXJlZCBzaWRlIG9mIHRoZSA2TEJS cy4NCj4gDQo+IEkgYWxzbyB3b25kZXIgaWYgdGhlIFJORkQgY291bGQgYmUgaW5jbHVkZWQgaW4g REFPcyAocGFydGljdWxhcmx5IHN0b3JpbmcNCj4gbW9kZSBvbmVzKSBzZW50IHRvIHRoZSBET0RB RyByb290Lg0KPiBJIGtub3cgdGhhdCBwcm9iYWJseSBzZWVtcyBzZW5zZWxlc3M6IHdoeSB0ZWxs IHRoZSByb290IHRoYXQgeW91IGFyZQ0KPiBvYnNlcnZpbmcgaXQgdG8gYmUgZHlpbmcuLi4uICBC dXQsIGl0IGFjdHMgYXMgaW50ZXJlc3RpbmcgdGVsZW1ldHJ5IGFib3V0DQo+IHdoYXQgdGhlIG5v ZGVzIGFyZSBzZWVpbmcsIGFuZCBtaWdodCBzZXJ2ZSBhcyBhIHVzZWZ1bCBpbmRpY2F0aW9uIG9m DQo+IGltbWluZW50IGZhaWx1cmUsIG9yIHNvbWUga2luZCBvZiBzeXN0ZW1hdGljIGxvbmctY3lj bGUgcGF0aG9sb2d5Lg0KPiANCj4gWW91ciBJQU5BIGNvbnNpZGVyYXRpb25zIGFyZSBob3cgdGhl IGRvY3VtZW50IHdpbGwgbG9vayBhZnRlciBJQU5BIGhhcw0KPiBwcm9jZXNzZWQgaXQuICBQcmlv ciB0byB0aGF0IHBvaW50LCB5b3UgbmVlZCB0byB3cml0ZSBpdCBhcyBhIHJlcXVlc3QuDQo+IA0K PiBTb21ldGhpbmcgbGlrZToNCj4gDQo+ICAgIElBTkEgaXMgcmVxdWVzdGVkIHRvIGFsbG9jYXRl IHRoZSB2YWx1ZSBUQkQxIGZyb20gdGhlICJSUEwgQ29udHJvbA0KPiBNZXNzYWdlDQo+ICAgIE9w dGlvbnMiIHN1Yi1yZWdpc3RyeSBvZiB0aGUgIlJvdXRpbmcgUHJvdG9jb2wgZm9yIExvdyBQb3dl ciBhbmQgTG9zc3kNCj4gICAgTmV0d29ya3MgKFJQTCkiIHJlZ2lzdHJ5Lg0KPiANCj4gSSBsaWtl IHRvIGluY2x1ZGUgdGhlIFVSTCBvZiB0aGUgcmVnaXN0cnkgaW4gbXkgcmVxdWVzdCB0byBiZSBy ZWFsbHkNCj4gcmVhbGx5IGNsZWFyLCBhbmQgdG8gc2F2ZSBldmVyeW9uZSBlbHNlIHRoZSB0aW1l IHRvIGZpbmQgaXQuDQo+IA0KPiBZb3VyIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHdpbGwgd2Fu dCB0byBjaXRlIFJGQzc0MTYuDQo+IEluIHBhcnRpY3VsYXIsIDcuMi40LCBhbmQgc2VjdGlvbiA3 LjMuNCBhbmQgNy4zLjUgbWlnaHQgYmUgcmVsZXZhbnQuDQo+IA0KPiAtLQ0KPiBNaWNoYWVsIFJp Y2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1hbi5jYT4gICAuIG8gTyAoIElQdjYgScO4VCBjb25z dWx0aW5nICkNCj4gICAgICAgICAgICBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MgSW5jLCBPdHRh d2EgYW5kIFdvcmxkd2lkZQ0KDQo= From nobody Thu Apr 8 07:16:36 2021 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 B9EF03A193B for ; Thu, 8 Apr 2021 07:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.618 X-Spam-Level: X-Spam-Status: No, score=-9.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=U2dsB07Z; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=UTeu/t+w 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 e7QuZi-gL648 for ; Thu, 8 Apr 2021 07:16:30 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44E2E3A1927 for ; Thu, 8 Apr 2021 07:16:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2740; q=dns/txt; s=iport; t=1617891390; x=1619100990; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=R7INYimaBH8lkzz375aqJWHTq310kXTjg9+Su4QYxMc=; b=U2dsB07Zw3xf0XYfZt5iqL38fTRjQypY0THpHlrhrnIIiXqgmn0TrBTt Nqc4mp8UUgHiRqXGxYydJ+JbVm7uLrwE7XUH6lUH2UgK7a+7gHWZmTfSJ zw3TAGMk9cG9XlxFX0Efzk7xbSWPIuiY+jMbURVGQOY/9zdwxCHuVpN4z k=; X-IPAS-Result: =?us-ascii?q?A0CYAgATD29gmJldJa1aHgEBCxIMQIFHC4FTUX5aNjGIC?= =?us-ascii?q?gOFOYhPA5R0hEeBLhSBEQNUAQoBAQENAQEdCwoCBAEBgRYBgzkCgXcCJTUID?= =?us-ascii?q?gIDAQEBAwIDAQEBAQEFAQEBAgEGBBQBAQEBAQEBAWiFUA2GRAEBAQEDAQE4B?= =?us-ascii?q?gEBLAwLBAIBCBEEAQEfECcLHQgCBBMIgmkBglUDLwEOoDECih91gTSBAYIEA?= =?us-ascii?q?QEGhScYghMDBoE5gnaCcVCHFiccgUlCgVZUgQuBAD6CYAEBAgGBIxwgg0qCK?= =?us-ascii?q?4MvAx0SIgJbPRhDgQEDkHWXBJJPCoMLiWOTPINNhgCEeJYsoH+SVgiEYQICA?= =?us-ascii?q?gIEBQIOAQEGgVYCNIFbcBU7gmlQFwIOjh8MDQmDToUUhUVzAgE1AgYKAQEDC?= =?us-ascii?q?XyMFQEB?= IronPort-PHdr: A9a23:WObf+BO8JpbJ0pxcLPAl6nf1WUAX047cNxMJ6pchl7NFe7ii+JKnJ kHE+PFxlzfhXIjH5bRDkeWF+6zjWGlV55GHvThCdZFXTBYKhI0QmBBoG8+KD0D3bZuIJyw3F chPThlpqne8N0UGGcviaRvVuHLhpTIXEw/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oK xDjpgTKvc5Qioxnec4M IronPort-HdrOrdr: A9a23:EA8+j6zDH46eO+bRoYUkKrPxTO8kLtp033Aq2lEZdDV8Sebdv9 yynfgdyB//gCsQXnZlotybJKycWxrnlKJdybI6eZOvRhPvtmftFoFt6oP+3ybtcheRysd07o 0lSaR3DbTLYmRSpczx7BCkV/Mpx9ea+K6l7N2usEtFZwdsdq1m8kNdAgGUDkV5SGB9dOQEPb Cb4ddKoCflRG8ead61CmJAc+/IodDKk5yOW29GOzcM7g6SgTS0rIPrChTw5GZRbxpj45cHtV LEnQvw+7m5v5iAqiP0+mfP4/1t6aPc4/ZOC8CWkcQZbhjhjwa2aJ9wMofyxwwdj/qo7D8R4b zxijcme/9+8nbAOlyyyCGdpzXI9BYLxzvcxUSDgX3lyPaJBA4SL8Zan4pWfl/4xiMbzatB+Z lG1W6YqJZbZCmo9E+WirS4NGAJqmOOrXUviuIVhXBEOLFuFYN5l5AV/09eDf47bUXHwb0nC+ VnAYX94/tbYDqhHgnkl1Rv29ClUzAPGA6HSCE5y6qo+gVR9UoJq3cw9Yg6pDMt5Zg9Q55L66 DvKaJzjoxDSccQcOZUGPoBadHfMB2PfTv8dEapZXj3HqAOPHzA77Tt5q8u2e2scJsUiLMvhZ X6Vk9Cv2JaQTOtNeS+mLlwtjzdSmS0WjrgjutE4YJih7H6TL33dQqOVU4piMnlh/kEGMXUV7 KSNfttcrreBFqrPbwM8xz1WpFUJ3VbetYSoMwHV1WHpd+OJZbtsuDdbfbPNLvgGTspQQrEcz w+dQm2AP8FwlGgW3f+jhSUcWjqYFbD8ZV5F7Wf/+V78vlKCqR89iwuzXip7MCCLjNP9oYsel FlHb/hmqSn4W2//WPC6XR1KgNQZ3wluYnIYjdvn0snIkn0ebEMt5G0YmZJxkaKIRd5UofRCw 5Qp1N+/KqtNJyOzSU+C9aqW1jqy0c7lTavddMxi6eD7cDqdtcTFZA9QpF8Eg3NClhogwpwsX xCbwUFX0fbETvrhcye/cQpLdCaU+M5rBagIMZSp36aiF6Vots3QGAHGxS0V9SMvAooTz1Ip1 F4/qMFmoCckTK3JWZXupViDHR8LECsRJNPFkCseZhdkLGDQnAAcU66wRihzywVVkWv3UMInW DlJTCTYpjwcypgk0Ed9L3r/lNyfniaZGRqZBlBwNdAPFWDnGpv2umWYaf29G2dZjI5s70gGQ CARycOKQVzwN3y7jqpoXKpEHUrwYhGBJ2BMJ0qb6zT1nSxKIeBiKEBGLtO8Ix4Mc3129V7It 63akubKij1BPgu3BHQrnE5ODNsoH1hiv/w3gb5hVLIkUIXEL7XIF58QascLMzZ52/4R+yQ2J ERt6N/gcKgdmHwYMWB06fZcnpKLQ7Su3e/S6UtpYpPtaw/8Lt1EJ+za0qD6FhXmBE/Jtzzjk UQXeBy563AIJZme4gKYD1Cl2BZ4uinPQ8uqEj7E+U+dVYigzvSOM6I+aPBrf4qDlearAX9NF GD+0Rmjrv4djrG0aRfB7M7IGxQZkR58nhk8e+Yf4DbCQmhdYh4jRKHG274dKUYRLmOGL0WoB o//sqBmPWPcTHknA/Xpjl2L8t1gimaaNL3BBjJH+FG89a3YwvRxqSr5dO+lzfxR3+wbV8CiY hMaEwXaYBCh1AZ/fkK+zn3TraypEQv10Za63VgkFXm34C9+mfVHU1cK2Ti89xrdCgWNmLNlN jP9OiTyW/07zdE04TSDUs4RKA6J/EACozsazp0IccevLS077MijyRKbhApFXM9glnGrpRb9K b83u7TVe3kAWrpPlxE+SctPP8HohAW X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,206,1613433600"; d="scan'208";a="672890663" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Apr 2021 14:16:29 +0000 Received: from mail.cisco.com (xbe-aln-002.cisco.com [173.36.7.17]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 138EGT1C010829 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for ; Thu, 8 Apr 2021 14:16:29 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xbe-aln-002.cisco.com (173.36.7.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Thu, 8 Apr 2021 09:16:28 -0500 Received: from xfe-aln-002.cisco.com (173.37.135.122) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 8 Apr 2021 10:16:27 -0400 Received: from NAM11-DM6-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.792.3 via Frontend Transport; Thu, 8 Apr 2021 09:16:27 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OG8rNcYsrUSDSQi0fGy/WYG+rMknz+zi5ZqKqXdlCuGiZSuj9GmX5Zlp1ZweIlKuxQuCkIs4boJRiIw0acpSL2N4nE9R7WhFhcBBIC+AeUqTkmSllG9Q4UCMVz4qshxJWhkBJUATQMvJsyckh2iJRtz5779BKNIs/EJpdpSKL9GcFOzb1OeFyPVvckrx6hVg3rnR/p6DwHrifYrQn0dbZ6YW1ucVPP9khGO1FLSUiUlAzVrtnEj7BhBKis/ZG8Hmu9mfiCPKXpfxoZHL4KED2NKUYWDP9mU/+R/jWXbo1etMVqgPiVbSWwag6fajbkcQJegsL8cbcIy4LBVnpMxiyA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/rC+IkgUFe2Te+Lb8QvO66rcVu7aVVVMbUcZNaAlKmw=; b=DNu8EdhQoQH2R63HXe9XTQ/j+ljQE0bMgavEHZcX1I8nPMySVKBd7hSSd3UnAfe72nAjLgCNvG6ZC0XVkWN82OaDmrzYRFHdCRrhaWsY19VVOkjHbpaGhVzfSYjGIvOnI0mO7xu6iARL5PsiDyD13M9KnOrXKjjgGbeeTcO3pVJ37AE9YAxriCb+I1A51oGvDSUd7jHr1A5HXsS9nYIcxaBrzANtAC5+e/c6Ff8u4tkke2VbpHObBgTjH2uSou3xh48c3JMcg94A2s3upIcOtrW4mDtkxWQaPAt1ldG4L+pUFzu/kgM/kVvLJZvLYHO9stYskzffyLa3mgNH2pfs9Q== 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=/rC+IkgUFe2Te+Lb8QvO66rcVu7aVVVMbUcZNaAlKmw=; b=UTeu/t+wmrDhdC/G3pcTz9VgUulA5rJuynwMh3/P++yotjTV/MCWrGxjmYTB/cRrhP54dVTjHzAKgc4xGS/W6HM9Pt5dtJS5mlxAkXwJGN39MP0TgWP4Q7oWbqGpnzNzTiJfTkRqxk23TwlNsMhNSUcVdjd816swgUMTg/Xssy0= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MWHPR11MB1936.namprd11.prod.outlook.com (2603:10b6:300:111::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.24; Thu, 8 Apr 2021 14:16:26 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::cd01:ffc9:6592:b1d5]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::cd01:ffc9:6592:b1d5%6]) with mapi id 15.20.3999.032; Thu, 8 Apr 2021 14:16:26 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Border router failure detection Thread-Index: AQHXK+V11ZIg9ppwIUWAf2h5ir/s+6qqqk1A Date: Thu, 8 Apr 2021 14:16:04 +0000 Deferred-Delivery: Thu, 8 Apr 2021 14:15:05 +0000 Message-ID: References: <49ac5fc3-4a3c-fb87-d366-eb7e7cfd60df@mimuw.edu.pl> <18233.1583176305@localhost> <10272666-28c7-ab3e-9ceb-1b8f2bb6e5e5@mimuw.edu.pl> In-Reply-To: <10272666-28c7-ab3e-9ceb-1b8f2bb6e5e5@mimuw.edu.pl> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2a01:cb1d:4ec:2200:8832:c2f1:a513:23ff] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9d007c8d-3423-4ce1-126a-08d8fa98e59e x-ms-traffictypediagnostic: MWHPR11MB1936: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: VgnFvbyKiYGtpdjuDqY23VaBAsG5GWjnP/+dQEaMIX7FAyoRciA51onIa1AXNxhBTBpcUoIkucvfh4wzIuU7RO50nns11Va6of340qXnZLZLrYKFCNchBICBYz7dd4mTeo9//lGfVZIipd//Grl65hWyFDsNLlq/4JsaQ6PQzvcK4ZaJqwovhMnFn10LkzxTNkGfpOeEvSkT0b4vGO9HREMIQGmaJkOtNECr9HFAc9pZ3f84cqJkSPyWaGOUiS6I8qqRO4YvFKfrCXFNzmJGGJZW34GAN7uNwRX0lJctBHIXny6NugFD64uQ7DCnpIoyaYsYWriSMg8sjYgeL1yLwAyERiwSGaghoeZx/F8+HTrvTPo7Ts9up08mZ4O9nozVHlTWp6f1jYtBC6Lpv8tYtWRyBWrcIElkcxibkd1ySQuUxfjqGgB6QVLt9JYH1gS1XGwte+rC0jduVv+gKLLlflTcEYWSpWiog5mTmORA625DxHdnv+godIhyYMS6UZ48MqQQndllJhln2ZxbW+/oNmUoHZt9SzRmFHbSDPUmK1HoORZdOTAMTsrkCPCbVbMJNaMSoos8FNCS+DnkU9112IQUjv7UHIGYIjnVhmZElL1j1MLSHM4mH2dLnUFNQCAhdScmIDP/9RTbs9iuHQ0+Y30/PTGxl3zMAcxeIN0U8kKLP/N5oZ48K/0xb+OSGSfiYIKqa4ZCDOtONl/yroOvMIZia17nbiRxDxdoHQhgGhA= 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:(396003)(39860400002)(346002)(136003)(366004)(376002)(2906002)(8936002)(8676002)(316002)(66574015)(76116006)(38100700001)(966005)(66446008)(6666004)(66556008)(64756008)(55016002)(478600001)(9686003)(6506007)(53546011)(5660300002)(66476007)(71200400001)(66946007)(83380400001)(7696005)(6916009)(86362001)(33656002)(186003)(52536014); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?4Qe6En8uMbMMtrfw3Ih3/PO1QuuI9oANeTHznl/Ev644eZhVxyQyatZPU+Vi?= =?us-ascii?Q?sUDxjIXpYebGSnWygaZqDEaVP10xq/kcNnbmp/YFD2+EaC/4a9Y38gv80P//?= =?us-ascii?Q?OQ7obF1cEaocWdMFrjVLGGeF57YiB9q2j58kUNgbzpGrAi7h5dZlH0ouPx+p?= =?us-ascii?Q?JT7TezeNGyEmgbAcmiq9cLWzuv6pdgC4hAwf/KFdJJjL/DQvNvEMkPDu0YBe?= =?us-ascii?Q?/h0rjsD7t2aKQGppyBhPQjYT3sguAAucmfiWXZHftchiM2LResHTzIyh2v75?= =?us-ascii?Q?mkGoXnE5ba5/WCSgJhWIIFqN+ILK3LR0ZusHQ2oCjemAnp3UfLNMTHHKSlqW?= =?us-ascii?Q?GHECm95Xl8sTZZ93gsDOivvQEbYjB9lSQ/TcGCr5VN/9N6r02UYPzyUjhZ4S?= =?us-ascii?Q?3M7ZvYMs7Zr2Roqk+oIwBOrvYAwNwxoe6Mh8bT89ozc9y9MnCdAHH8xUjdL6?= =?us-ascii?Q?uf8nkx50cnq0Q8Y/pCnxk8cth5+s7evaPbBaWsrNLfE9gRqE3SpZWJWvn9Ph?= =?us-ascii?Q?/Zhqy4R/itag1/HtfqIxUYKblFl4WP/wYnzF499yq1Kh+Jn4Xkno16M/ql2J?= =?us-ascii?Q?v50P0bHUDA8M2rbL4lCxp4epwvPy0JHOEE2wb0koo5k2uLKRVa2zX92rSHoq?= =?us-ascii?Q?Oo64MV3hFH2qvQQ0rdaWMpujvJltln5mMlqcoCGm8abWfIlaKdiiex7acWOt?= =?us-ascii?Q?WgpW1xFU1j0y9LGaL+r5oTOE0klttTuLoWkM5G08wwkovSQoQ+olvXmFLLId?= =?us-ascii?Q?YrBwVglWRb2eKzVgIhBA08Ge7qeQwxW/UNZqKSv59SqQ2Hq57oph2NH1wUNt?= =?us-ascii?Q?+n4Y5kILxICWvO/PyCiaK4SyDEf6E2HbEqwMeuvTlP/68BspAxPv5SM9wGww?= =?us-ascii?Q?5nYM+6wrDe8cbGXpEUx1CfuWNAz0+8U5hQP9gimfrk4GxVwsQClSAQ7UygHR?= =?us-ascii?Q?9Qgywup1MG60JkH1gGiJ7ksQ9CSFDGogSRpLoL2ImMv/lv8TOlQndOLS7mtg?= =?us-ascii?Q?SAMhxo1h6uwRBpRNnLlQDw3Ra59vLpAtMal+6qbMyVfxPeFzLpyVvWcWBEBa?= =?us-ascii?Q?9rT8EcFNrpZUSP3KyoaAhQJ0utuIaE7X4bz6hGvgZtkJSq8q5GUmPZdh7FjU?= =?us-ascii?Q?xlw3dADUan2yjWFxsAZKIl47HFhLAXrH6j3OQzz7p/ORi8PNFmIG5bpAcsJ0?= =?us-ascii?Q?a0bTX+7+t2PQpcPWlgfcBj4+06AM9wDiisLPIjiYo22wmuwH7r8Wiih7Bby5?= =?us-ascii?Q?RBdS0z+ZoZRUl+DTbbH1+T/yTGa3OGh/eaUktB5i3WmsJsDTFxtCEww0mswj?= =?us-ascii?Q?JokW3AtBl/94FP64i6lvHuQdrMa09bPwkLgnIF0DHphck4gtQo4Fx+/XdgWE?= =?us-ascii?Q?N+pAzqzgak3dEGGTls7OOBTAk/Pj?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4881.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9d007c8d-3423-4ce1-126a-08d8fa98e59e X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2021 14:16:26.5577 (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: HImojtr40zJoSJQ42metSXjOXdW0vN9anxQP5M3K8F0P+qH/7lvcp5vKPX2YZa9Xp4scC/4YTYNlEzqI+7i+KA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1936 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.17, xbe-aln-002.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [Roll] Border router failure detection 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, 08 Apr 2021 14:16:35 -0000 Hello Konrad About this text " Since all DODAG paths lead to the corresponding LBR, detecting its crash by a node entails dropping all parents and adopting an infinite rank, which reflects the node's inability to reach the LBR. However, achieving this state for all nodes is slow, can generate heavy traffic, and is difficult to implement correctly [Iwanicki16] [Paszkowska19] [Ciolkosz19]. " Please note that this may be what an implementation decides to do, but is b= y far not my favorite option. The alternate is to rest the "G" but and become floating root. The benefit = is that the DODAG structure is mostly maintained and that routing inside ma= y persist. See https://tools.ietf.org/html/rfc6550#section-18.2.4 for how to configure= this. Keep safe; Pascal > -----Original Message----- > From: Roll On Behalf Of Konrad Iwanicki > Sent: mercredi 7 avril 2021 21:37 > To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] Border router failure detection >=20 > Dear all, >=20 > Approximately a year ago, I joined the WG and advertised an extension to > RPL that I had been working on for some time with a goal of describing it > in a draft. Unfortunately, just when I got the necessary pointers and a > few initial comments, the pandemic broke out. The resulting surge of > professional and personal obligations made it literally impossible for me > to participate in and, at some point, even follow the group's activities, > for which I am sorry. >=20 > However, I did strive to regularly find a little time to get somewhat > acquainted with IETF's procedures and write up something that may resembl= e > a draft. I have just submitted it as: >=20 > draft-iwanicki-roll-rnfd-00 >=20 > and created a dedicated repository on the group's GitHub. >=20 > Since I have no experience writing IETF documents, I would really > appreciate your collaboration on either turning the text into a true draf= t > or concluding that this should not be done. >=20 > Please, keep mind in mind that I decided to maximally cut down the > original algorithms, so that the extension is as simple as possible > without losing key properties. Therefore, it is likely that if the > extension as a whole or any of its parts turn out relevant or interesting= , > still a considerable amount of work may be necessary to have it or them > described properly. Your contribution is most welcome. >=20 > Thanks in advance. >=20 > Best regards, > -- > - Konrad Iwanicki. >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Thu Apr 8 07:59:49 2021 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 449C53A1A93 for ; Thu, 8 Apr 2021 07:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 HKovk6VMo1zG for ; Thu, 8 Apr 2021 07:59:43 -0700 (PDT) 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 971E23A1A92 for ; Thu, 8 Apr 2021 07:59:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 77C4338FF4 for ; Thu, 8 Apr 2021 11:06:34 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6JAvY0bU4O0Z for ; Thu, 8 Apr 2021 11:06:33 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E07A838FE8 for ; Thu, 8 Apr 2021 11:06:32 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 96FA666B for ; Thu, 8 Apr 2021 10:59:39 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: <49ac5fc3-4a3c-fb87-d366-eb7e7cfd60df@mimuw.edu.pl> <18233.1583176305@localhost> <10272666-28c7-ab3e-9ceb-1b8f2bb6e5e5@mimuw.edu.pl> 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 Archived-At: Subject: Re: [Roll] Border router failure detection 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, 08 Apr 2021 14:59:48 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Pascal Thubert \(pthubert\) wrote: > Since all DODAG paths lead to the corresponding LBR, detecting its > crash by a node entails dropping all parents and adopting an infinite > rank, which reflects the node's inability to reach the LBR. However, > achieving this state for all nodes is slow, can generate heavy > traffic, and is difficult to implement correctly [Iwanicki16] > [Paszkowska19] [Ciolkosz19]. > " > Please note that this may be what an implementation decides to do, but > is by far not my favorite option. > The alternate is to rest the "G" but and become floating root. The > benefit is that the DODAG structure is mostly maintained and that > routing inside may persist. This works well for storing mode where one expects that all 6LR are pretty much equivalently capable. For Non-Storing Mode, it could be that only the LBR (and it's redundant backup...), are capable of accepting the DAOs, maintaining that table and generating the right routing headers. Perhaps this is where the gap lies. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmBvGlsACgkQgItw+93Q 3WUVcggAkmDMfWza5lJxPDoSsT+GJUAMSujm/poof9uotV/ItpVi9Y1JwZIY8Mhp 9+sG8PGMGHDzEvTXscQjfvbrYZXzG6eGu1X3il75gXWc+1M8zaJJVtLe50iau2Nr kISVfbfA4YOOLEu8l7j+0lThCwly+IRSTxKSu5SoEJXNNPkwa2SiUBGF1bC/UAvF EPs/jwlSTVVxV2tBiQQxcSJa2A3uHgaHHGVfVBv13EporV9gZ+yZ1zteyv+DI2vI LqMSzWuR0MhHqUxSfrxejnNf645cOlRfAhbR05phirEomfHmp6jFQqfV54PC8Dlv CQ+F3RC3qKpPWs2R+SoGUdtVfSeVnw== =ALrM -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 8 14:17:18 2021 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 4CC5E3A1CBE for ; Thu, 8 Apr 2021 14:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 jmk9TsEtVZMt for ; Thu, 8 Apr 2021 14:17:12 -0700 (PDT) Received: from mail.mimuw.edu.pl (mail.mimuw.edu.pl [IPv6:2001:6a0:5001::4]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E78F33A1CC6 for ; Thu, 8 Apr 2021 14:17:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by duch.mimuw.edu.pl (Postfix) with ESMTP id 0185A600A1A25; Thu, 8 Apr 2021 23:17:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at mimuw.edu.pl Received: from duch.mimuw.edu.pl ([127.0.0.1]) by localhost (mail.mimuw.edu.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9eHWJ2hThwmp; Thu, 8 Apr 2021 23:17:05 +0200 (CEST) Received: from Konrads-MacBook-Pro.local (unknown [IPv6:2a02:a311:813e:880:446c:71a3:f6c4:59d5]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by duch.mimuw.edu.pl (Postfix) with ESMTPSA; Thu, 8 Apr 2021 23:17:02 +0200 (CEST) To: Routing Over Low power and Lossy networks , Michael Richardson , "Pascal Thubert (pthubert)" References: <49ac5fc3-4a3c-fb87-d366-eb7e7cfd60df@mimuw.edu.pl> <18233.1583176305@localhost> <10272666-28c7-ab3e-9ceb-1b8f2bb6e5e5@mimuw.edu.pl> <27309.1617893979@localhost> From: Konrad Iwanicki Message-ID: <4ab61b5f-c5f2-085b-beb6-26f4a67d8ca2@mimuw.edu.pl> Date: Thu, 8 Apr 2021 23:17:01 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: <27309.1617893979@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Roll] Border router failure detection 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, 08 Apr 2021 21:17:16 -0000 Hi Pascal, Michael, First of all, thanks for your interest, encouragement, and feedback! I'll try to answer in the "stack mode" (from your last email to the first) and as much as I can tonight because my throughput this week again became very limited due to another lockdown. On 08/04/2021 16:59, Michael Richardson wrote: > > Pascal Thubert \(pthubert\) wrote: > > Since all DODAG paths lead to the corresponding LBR, detecting its > > crash by a node entails dropping all parents and adopting an infinite > > rank, which reflects the node's inability to reach the LBR. However, > > achieving this state for all nodes is slow, can generate heavy > > traffic, and is difficult to implement correctly [Iwanicki16] > > [Paszkowska19] [Ciolkosz19]. > > " > > > Please note that this may be what an implementation decides to do, but > > is by far not my favorite option. > > > The alternate is to rest the "G" but and become floating root. The > > benefit is that the DODAG structure is mostly maintained and that > > routing inside may persist. > > This works well for storing mode where one expects that all 6LR are pretty > much equivalently capable. > > For Non-Storing Mode, it could be that only the LBR (and it's redundant > backup...), are capable of accepting the DAOs, maintaining that table and > generating the right routing headers. > > Perhaps this is where the gap lies. Floating DODAGs are really the best option to keep routing inside a DODAG possible in the face of failures. RNFD, however, deals with an orthogonal problem and can actually help spawning floating DODAGs faster after a grounded DODAG's root dies, as I try to explain below. To start with, the envisioned use of RNFD concerns "important" DODAG roots (e.g., providing connectivity with the rest of the Internet) that in addition have an increased risk of failures (because of e.g. power supply interruptions or bugs resulting from greater HW/SW complexity compared to "normal" nodes). In practice, these will be LBRs that are roots of grounded DODAGs, and hence they are emphasized in the text. Nevertheless, one can use the algorithm also for any other DODAG roots. The cost is the overhead on DIOs and DISs due to the extra option and possible Trickle timer resets. Moreover, RNFD aims at minimal requirements with respect to RPL. In particular, it works even if a DODAG is completely degenerated. Likewise, it works for all RPL MOPs, notably even MOP 0 without any downward routes (which I believe is a particularly attractive feature). Therefore, regarding floating DODAGs, irrespective of nodes' capabilities, a major question is: When should a node leave a grounded DODAG and start advertising a floating one? More specifically, https://tools.ietf.org/html/rfc6550#section-18.2.4, quoted by Pascal in the previous e-mail, states that this is done by a node whose parent set becomes empty. And this moment is justified because---before---a node always has a possibility to select some node as the preferred parent. However, normally having an empty parent set implies that the node has already performed multiple unnecessary parent switches after a crash of the DODAG root, as the ranks of its subsequent parents grew repeatedly due to the lack of root. These switches must have taken time and generated control traffic resulting from Trickle timer resets. What RNFD can do is reduce the time from the crash of a DODAG root to the moment a node empties its parent set (which is done when RNFD sets its LORS to GLOBALLY DOWN) by an order of magnitude. This means that a node can much quicker conclude that the root node of a grounded DODAG is dead, empty its parent set, and start being the root of a floating DODAG. Note that this is independent of whether a storing or non-storing mode is utilized. What is more, this reduction of the root's crash detection period also reduces RPL's opportunities to switch the node's parents and degenerate downward routes in effect. Therefore, with RNFD it is likely that downward routes in the floating DODAG remain closer to what where in the original grounded DODAG, which is probably more important in a storing mode. To sum up, when operating together with RPL in a deployment where nodes can spawn floating DODAGs, RNFD can significantly reduce the interruption period of downward routing as well. What I see in the text of the draft is that indeed I did not mention the possibility of starting a floating DODAG when the GLOBALLY DOWN value of LORS is attained. Thanks a lot for these observations! Where do you think it would be best to put this information in the text? Best, -- - Konrad Iwanicki. From nobody Thu Apr 8 14:19:44 2021 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 4B2663A1D22 for ; Thu, 8 Apr 2021 14:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 5Xjb9ykYWpuk for ; Thu, 8 Apr 2021 14:19:38 -0700 (PDT) Received: from mail.mimuw.edu.pl (mail.mimuw.edu.pl [IPv6:2001:6a0:5001::4]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5E513A1D1D for ; Thu, 8 Apr 2021 14:19:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by duch.mimuw.edu.pl (Postfix) with ESMTP id 84FAD600A1A25; Thu, 8 Apr 2021 23:19:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at mimuw.edu.pl Received: from duch.mimuw.edu.pl ([127.0.0.1]) by localhost (mail.mimuw.edu.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id JX7GSma31wH4; Thu, 8 Apr 2021 23:19:34 +0200 (CEST) Received: from Konrads-MacBook-Pro.local (unknown [IPv6:2a02:a311:813e:880:446c:71a3:f6c4:59d5]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by duch.mimuw.edu.pl (Postfix) with ESMTPSA; Thu, 8 Apr 2021 23:19:34 +0200 (CEST) To: Routing Over Low power and Lossy networks , "Pascal Thubert (pthubert)" References: <49ac5fc3-4a3c-fb87-d366-eb7e7cfd60df@mimuw.edu.pl> <18233.1583176305@localhost> <10272666-28c7-ab3e-9ceb-1b8f2bb6e5e5@mimuw.edu.pl> From: Konrad Iwanicki Message-ID: Date: Thu, 8 Apr 2021 23:19:33 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Roll] Border router failure detection 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, 08 Apr 2021 21:19:43 -0000 Hi again Pascal, On 08/04/2021 16:16, Pascal Thubert (pthubert) wrote: > Hello Konrad > > About this text > " > > Since all DODAG paths lead to the corresponding LBR, detecting its > crash by a node entails dropping all parents and adopting an infinite > rank, which reflects the node's inability to reach the LBR. However, > achieving this state for all nodes is slow, can generate heavy > traffic, and is difficult to implement correctly [Iwanicki16] > [Paszkowska19] [Ciolkosz19]. > " > > Please note that this may be what an implementation decides to do, but is by far not my favorite option. > The alternate is to rest the "G" but and become floating root. The benefit is that the DODAG structure is mostly maintained and that routing inside may persist. > > See https://tools.ietf.org/html/rfc6550#section-18.2.4 for how to configure this. OK, I think I addressed this in my previous e-mail to you and Michael. (The next two e-mails will have to wait till tomorrow I am affraid.) Best, -- - Konrad Iwanicki. >> -----Original Message----- >> From: Roll On Behalf Of Konrad Iwanicki >> Sent: mercredi 7 avril 2021 21:37 >> To: Routing Over Low power and Lossy networks >> Subject: Re: [Roll] Border router failure detection >> >> Dear all, >> >> Approximately a year ago, I joined the WG and advertised an extension to >> RPL that I had been working on for some time with a goal of describing it >> in a draft. Unfortunately, just when I got the necessary pointers and a >> few initial comments, the pandemic broke out. The resulting surge of >> professional and personal obligations made it literally impossible for me >> to participate in and, at some point, even follow the group's activities, >> for which I am sorry. >> >> However, I did strive to regularly find a little time to get somewhat >> acquainted with IETF's procedures and write up something that may resemble >> a draft. I have just submitted it as: >> >> draft-iwanicki-roll-rnfd-00 >> >> and created a dedicated repository on the group's GitHub. >> >> Since I have no experience writing IETF documents, I would really >> appreciate your collaboration on either turning the text into a true draft >> or concluding that this should not be done. >> >> Please, keep mind in mind that I decided to maximally cut down the >> original algorithms, so that the extension is as simple as possible >> without losing key properties. Therefore, it is likely that if the >> extension as a whole or any of its parts turn out relevant or interesting, >> still a considerable amount of work may be necessary to have it or them >> described properly. Your contribution is most welcome. >> >> Thanks in advance. >> >> Best regards, >> -- >> - Konrad Iwanicki. >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From nobody Fri Apr 9 13:57:21 2021 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 5130A3A10C1 for ; Fri, 9 Apr 2021 13:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 Kvc4Gg3f1P0s for ; Fri, 9 Apr 2021 13:57:14 -0700 (PDT) Received: from mail.mimuw.edu.pl (mail.mimuw.edu.pl [193.0.96.6]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB1183A10BF for ; Fri, 9 Apr 2021 13:57:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by duch.mimuw.edu.pl (Postfix) with ESMTP id B5A156010FA31; Fri, 9 Apr 2021 22:57:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at mimuw.edu.pl Received: from duch.mimuw.edu.pl ([127.0.0.1]) by localhost (mail.mimuw.edu.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id PQrEMhcpJaPS; Fri, 9 Apr 2021 22:57:04 +0200 (CEST) Received: from Konrads-MacBook-Pro.local (unknown [IPv6:2a02:a311:813e:880:f86e:cf5d:9341:bdc3]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by duch.mimuw.edu.pl (Postfix) with ESMTPSA; Fri, 9 Apr 2021 22:57:01 +0200 (CEST) To: Routing Over Low power and Lossy networks , "Pascal Thubert (pthubert)" References: <49ac5fc3-4a3c-fb87-d366-eb7e7cfd60df@mimuw.edu.pl> <18233.1583176305@localhost> <10272666-28c7-ab3e-9ceb-1b8f2bb6e5e5@mimuw.edu.pl> <8372.1617839184@localhost> From: Konrad Iwanicki Message-ID: Date: Fri, 9 Apr 2021 22:57:01 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Roll] Border router failure detection 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, 09 Apr 2021 20:57:20 -0000 Hello Pascal, On 08/04/2021 16:05, Pascal Thubert (pthubert) wrote: > If I may add: At the (early) time I contributed to the ACP design, the idea was that the Root's children were configured with a DODAGPreference (prf) that is more than the default value (of 0) inside the network. Different children may be given different prf to enforce an order in which they become the replacement for the LBR serving as Root. > > When losing connectivity to the LBR, a child that does not have connectivity to the main DODAG becomes floating Root of its own DODAG. If the LBR dies, all the children lose their parent, and the floating DODAG reforms from the child with the highest prf. Nodes that are willing to jump to an alternate DODAG that is grounded will do so. This is supposed to be somewhat fast because the Trickle timers are reset. > > I understand that the idea here is to be faster than that. That's an interesting idea, which is again orthogonal to RNFD and related to what I wrote in the previous e-mail: RNFD's operation is focused on the period from the DODAG root's crash to the moment of detecting it by all nodes. In this case, RNFD would thus speed up the occurrence of the moment the root's neighbors promote themselves to the roots of floating DODAGs. As to the promotion itself, I was wondering if one could additionally integrate the election of the root's neighbor with the best prf into RNFD to speed up the formation of the newly created floating DODAG. However, as you pointed out, DODAG construction is rapid because of Trickle, so modifying RNFD to also perform the election of the neighbor with the best prf would bring little benefit and would only make the algorithm more involved. To sum up, as I mentioned in the previous e-mail, RNFD can significantly accelerate the detection of the DODAG root's crash and bootstrapping of floating DODAGs by the root's neighbors, and the prf algorithm kicks in after the DODAG root's crash has been detected. Best, -- - Konrad Iwanicki. >> -----Original Message----- >> From: Roll On Behalf Of Michael Richardson >> Sent: jeudi 8 avril 2021 1:46 >> To: Routing Over Low power and Lossy networks >> Subject: Re: [Roll] Border router failure detection >> >> >> Konrad Iwanicki wrote: >> > draft. Unfortunately, just when I got the necessary pointers and a >> few >> > initial comments, the pandemic broke out. >> >> I know the feeling. >> I keep thinking I should be able to do *more* since I can't go out. >> >> >> > draft-iwanicki-roll-rnfd-00 >> >> > and created a dedicated repository on the group's GitHub. >> >> I see it at: >> https://github.com/roll-wg/draft-rnfd >> >> You might want to add a Makefile, either via >> https://github.com/martinthomson/i-d-template/blob/master/doc/SETUP.md >> or rip of my minimal one, such as: >> https://github.com/roll-wg/draft-ietf-roll-enrollment- >> priority/blob/master/Makefile >> >> > Since I have no experience writing IETF documents, I would really >> appreciate >> > your collaboration on either turning the text into a true draft or >> concluding >> > that this should not be done. >> >> It looks like you did a really good job. >> >> RPL is being used in storing mode the ANIMA WG's Autonomic Control Plane. >> See: https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control- >> plane/ >> ( section 6.12. ). The document is minutes away from getting an RFC#. >> >> We think that the border router, DODAG root, will be a device in the NOC. >> The NOC may get replicated into multiple locations so there could >> potentially be more than one candidate DODAG root. Given nodes are not >> constrained in the RFC7228 sense, supporting multiple DODAGs could be >> done, but we simplified our life by not mandating (actually, at this >> point, forbidding) the RPI header, so we are lacking an instanceID. >> >> The short of it is that I'd really like nodes to be able to float non- >> grounded DODAG roots if they don't hear a DIO after a few seconds. >> >> ---- >> >> It seems that you might want a term for the LBR's children. >> That is, the devices at rank "1", that hear the LBR's DIOs. >> >> I think that I would move some of section 3.2 further forward in the >> document. I think that I need a gentler introduction to CFRCs here, and I >> don't really need to know the properties, rather I need a higher-level >> idea >> of things. Since section 4 goes over the operations again, I would >> leave >> it for that spot, and make it a section 4.1. >> >> Having gone forward and back a bit, I'm still a bit uncertain how nodes >> assign themselves a bit... oh, self() in section 4 says "random". >> Why not make this a function (hash?) of the short-IPv6 address or >> something? >> >> Not every media has ACK frames at the L2 to establish that there are >> failures. It might be worth putting the Detecting and the Verifying into >> separate sections. Aside from the ANIMA case (which is usually pure >> ethernet), there are also situations where there is an ethernet backbone >> connecting a few 6LBRs (RFC8929), and your protocol would sensibly run on >> both the wireless and the wired side of the 6LBRs. >> >> I also wonder if the RNFD could be included in DAOs (particularly storing >> mode ones) sent to the DODAG root. >> I know that probably seems senseless: why tell the root that you are >> observing it to be dying.... But, it acts as interesting telemetry about >> what the nodes are seeing, and might serve as a useful indication of >> imminent failure, or some kind of systematic long-cycle pathology. >> >> Your IANA considerations are how the document will look after IANA has >> processed it. Prior to that point, you need to write it as a request. >> >> Something like: >> >> IANA is requested to allocate the value TBD1 from the "RPL Control >> Message >> Options" sub-registry of the "Routing Protocol for Low Power and Lossy >> Networks (RPL)" registry. >> >> I like to include the URL of the registry in my request to be really >> really clear, and to save everyone else the time to find it. >> >> Your security considerations will want to cite RFC7416. >> In particular, 7.2.4, and section 7.3.4 and 7.3.5 might be relevant. >> >> -- >> Michael Richardson . o O ( IPv6 IøT consulting ) >> Sandelman Software Works Inc, Ottawa and Worldwide > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From nobody Fri Apr 9 15:55:26 2021 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 628353A1599; Fri, 9 Apr 2021 15:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 7Qajyn4x4tpF; Fri, 9 Apr 2021 15:55:16 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF9FF3A1592; Fri, 9 Apr 2021 15:55:16 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 40190F40785; Fri, 9 Apr 2021 15:55:06 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, roll@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20210409225506.40190F40785@rfc-editor.org> Date: Fri, 9 Apr 2021 15:55:06 -0700 (PDT) Archived-At: Subject: [Roll] =?utf-8?q?RFC_9008_on_Using_RPI_Option_Type=2C_Routing_He?= =?utf-8?q?ader_for_Source_Routes=2C_and_IPv6-in-IPv6_Encapsulation_in_the?= =?utf-8?q?_RPL_Data_Plane?= 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, 09 Apr 2021 22:55:21 -0000 A new Request for Comments is now available in online RFC libraries. RFC 9008 Title: Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6 Encapsulation in the RPL Data Plane Author: M.I. Robles, M. Richardson, P. Thubert Status: Standards Track Stream: IETF Date: April 2021 Mailbox: mariainesrobles@gmail.com, mcr+ietf@sandelman.ca, pthubert@cisco.com Pages: 49 Updates: RFC 6553, RFC 6550, RFC 8138 I-D Tag: draft-ietf-roll-useofrplinfo-44.txt URL: https://www.rfc-editor.org/info/rfc9008 DOI: 10.17487/RFC9008 This document looks at different data flows through Low-Power and Lossy Networks (LLN) where RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) is used to establish routing. The document enumerates the cases where RPL Packet Information (RPI) Option Type (RFC 6553), RPL Source Route Header (RFC 6554), and IPv6-in-IPv6 encapsulation are required in the data plane. This analysis provides the basis upon which to design efficient compression of these headers. This document updates RFC 6553 by adding a change to the RPI Option Type. Additionally, this document updates RFC 6550 by defining a flag in the DODAG Information Object (DIO) Configuration option to indicate this change and updates RFC 8138 as well to consider the new Option Type when the RPL Option is decompressed. This document is a product of the Routing Over Low power and Lossy networks Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Apr 9 15:55:48 2021 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 30F5D3A1599; Fri, 9 Apr 2021 15:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 d5t8hPFpAZ3d; Fri, 9 Apr 2021 15:55:36 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21E0A3A15E6; Fri, 9 Apr 2021 15:55:34 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 050B5F4079B; Fri, 9 Apr 2021 15:55:24 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, roll@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20210409225524.050B5F4079B@rfc-editor.org> Date: Fri, 9 Apr 2021 15:55:24 -0700 (PDT) Archived-At: Subject: [Roll] =?utf-8?q?RFC_9009_on_Efficient_Route_Invalidation?= 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, 09 Apr 2021 22:55:47 -0000 A new Request for Comments is now available in online RFC libraries. RFC 9009 Title: Efficient Route Invalidation Author: R.A. Jadhav, Ed., P. Thubert, R.N. Sahoo, Z. Cao Status: Standards Track Stream: IETF Date: April 2021 Mailbox: rahul.ietf@gmail.com, pthubert@cisco.com, rabinarayans0828@gmail.com, zhencao.ietf@gmail.com Pages: 21 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-roll-efficient-npdao-18.txt URL: https://www.rfc-editor.org/info/rfc9009 DOI: 10.17487/RFC9009 This document explains the problems associated with the use of No-Path Destination Advertisement Object (NPDAO) messaging in RFC 6550 and also discusses the requirements for an optimized route invalidation messaging scheme. Further, this document specifies a new proactive route invalidation message called the "Destination Cleanup Object" (DCO), which fulfills requirements for optimized route invalidation messaging. This document is a product of the Routing Over Low power and Lossy networks Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Apr 9 15:56:18 2021 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 1F4323A15B8; Fri, 9 Apr 2021 15:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 73taP0EgnLmQ; Fri, 9 Apr 2021 15:56:01 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 189D53A15B6; Fri, 9 Apr 2021 15:55:55 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 048AEF40787; Fri, 9 Apr 2021 15:55:45 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, roll@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20210409225545.048AEF40787@rfc-editor.org> Date: Fri, 9 Apr 2021 15:55:45 -0700 (PDT) Archived-At: Subject: [Roll] =?utf-8?q?RFC_9010_on_Routing_for_RPL_=28Routing_Protocol?= =?utf-8?q?_for_Low-Power_and_Lossy_Networks=29_Leaves?= 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, 09 Apr 2021 22:56:13 -0000 A new Request for Comments is now available in online RFC libraries. RFC 9010 Title: Routing for RPL (Routing Protocol for Low-Power and Lossy Networks) Leaves Author: P. Thubert, Ed., M. Richardson Status: Standards Track Stream: IETF Date: April 2021 Mailbox: pthubert@cisco.com, mcr+ietf@sandelman.ca Pages: 36 Updates: RFC 6550, RFC 6775, RFC 8505 I-D Tag: draft-ietf-roll-unaware-leaves-30.txt URL: https://www.rfc-editor.org/info/rfc9010 DOI: 10.17487/RFC9010 This specification provides a mechanism for a host that implements a routing-agnostic interface based on IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery to obtain reachability services across a network that leverages RFC 6550 for its routing operations. It updates RFCs 6550, 6775, and 8505. This document is a product of the Routing Over Low power and Lossy networks Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Mon Apr 12 07:53:49 2021 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 47AAD3A2233; Mon, 12 Apr 2021 07:53:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: Cc: draft-ietf-roll-aodv-rpl.all@ietf.org, last-call@ietf.org, roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161823921524.12303.16717431883070401287@ietfa.amsl.com> Reply-To: Tero Kivinen Date: Mon, 12 Apr 2021 07:53:35 -0700 Archived-At: Subject: [Roll] Secdir telechat review of draft-ietf-roll-aodv-rpl-10 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: Mon, 12 Apr 2021 14:53:41 -0000 Reviewer: Tero Kivinen Review result: Has Nits This is rereview of this document. Some of my comments from the previous review were not properly implemented. I.e., even when the figure changed the reserved field in section 4.3 to be 'X' instead of 'r', the text listing fields still refers to it as 'r'. Also the acronym format is not not consistent, i.e., either pick format of "long name (ACRONYM)" or "ACRONYM (long name)", and do not use both of them. Now there is still acronyms RPL, DIO, and MOP in section 1 using different format than what for example acronyms DODAG, P2P, DAO in same section. From nobody Wed Apr 14 05:11:37 2021 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 1C90A3A0B21 for ; Wed, 14 Apr 2021 05:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-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 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 D8-4pK7mVzCs for ; Wed, 14 Apr 2021 05:11:32 -0700 (PDT) Received: from mail.mimuw.edu.pl (mail.mimuw.edu.pl [193.0.96.6]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C937C3A0B15 for ; Wed, 14 Apr 2021 05:11:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by duch.mimuw.edu.pl (Postfix) with ESMTP id 89C5161D63B0C; Wed, 14 Apr 2021 14:11:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at mimuw.edu.pl Received: from duch.mimuw.edu.pl ([127.0.0.1]) by localhost (mail.mimuw.edu.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id V9UWzi_mGCpx; Wed, 14 Apr 2021 14:11:25 +0200 (CEST) Received: from [IPv6:2001:6a0:5001:2:6195:3168:3284:dbd5] (unknown [IPv6:2001:6a0:5001:2:6195:3168:3284:dbd5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by duch.mimuw.edu.pl (Postfix) with ESMTPSA; Wed, 14 Apr 2021 14:11:23 +0200 (CEST) From: Konrad Iwanicki To: Michael Richardson , Routing Over Low power and Lossy networks References: <49ac5fc3-4a3c-fb87-d366-eb7e7cfd60df@mimuw.edu.pl> <18233.1583176305@localhost> <10272666-28c7-ab3e-9ceb-1b8f2bb6e5e5@mimuw.edu.pl> <8372.1617839184@localhost> Message-ID: <4db6ca0b-86a7-cad2-27fc-4728f01e0f06@mimuw.edu.pl> Date: Wed, 14 Apr 2021 14:12:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <8372.1617839184@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Roll] Border router failure detection 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, 14 Apr 2021 12:11:36 -0000 Dear Michael, On 08/04/2021 01:46, Michael Richardson wrote: > You might want to add a Makefile, either via > https://github.com/martinthomson/i-d-template/blob/master/doc/SETUP.md > or rip of my minimal one, such as: > https://github.com/roll-wg/draft-ietf-roll-enrollment-priority/blob/master/Makefile Thanks for the suggestion! I did borrow your getver and Makefile, slightly adapting the latter. > RPL is being used in storing mode the ANIMA WG's Autonomic Control Plane. > See: https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ > ( section 6.12. ). The document is minutes away from getting an RFC#. > > We think that the border router, DODAG root, will be a device in the NOC. > The NOC may get replicated into multiple locations so there could potentially > be more than one candidate DODAG root. Given nodes are not constrained in > the RFC7228 sense, supporting multiple DODAGs could be done, but we > simplified our life by not mandating (actually, at this point, forbidding) > the RPI header, so we are lacking an instanceID. > > The short of it is that I'd really like nodes to be able to float > non-grounded DODAG roots if they don't hear a DIO after a few seconds. I have read the relevant section of the ANIMA ACP draft. I do not know if I got all the details, so correct me if I am wrong. Indeed, the draft adopts RPL in a storing MOP with a single RPLInstance. It assumes that NOC can be replicated and seems to suggest that the DODAG Root is a node within an NOC. More specifically, though I may not have gotten this correctly, there would be a single primary DODAG root and when it malfunctions, another node, possibly in a different NOC, takes over this role so that at any time at most one DODAG root is active. I did not find the details of the failover mechanisms but I presume that the nodes that can act as DODAG roots synchronize with each other using regular RPL control messages over non-LLN links (perhaps inter-NOC ones). Therefore, DIOs over such links can be exchanged at a much higher frequency than over LLN links. In effect, indeed, if one of such NOC-based DODAG root candidate nodes does not hear a DIO from the acting DODAG root node within a few seconds, it may take over. In such a setting, RNFD may not have a lot of advantages: depending on a number of factors, it could offer comparable performance, and hence could serve as a support for the DIO timeout mechanism. As I explained in the previous e-mails, the possibility of spawning floating DODAGs is actually not an obstacle. There is, however, at least one situation in which RNFD could help. More specifically, it may be the case that the LLN interface of the NOC-based DODAG root does not work but the one used for synchronizing with other NOC-based candidates works normally. In this scenario, simply exchanging DIOs between the DODAG root candidates need not detect the failure, in contrast to RNFD, which would monitor the actual LLN links. All in all, I believe that to some extent RNFD can be beneficial even with ACP. What is more, your remark actually got me thinking about Virtual DODAG Roots (as per https://tools.ietf.org/html/rfc6550#section-8.2.2.2), where multiple nodes, potentially NOC-based, coordinate to transparently and simultaneously (not in a primary-backup fashion) act as a single DODAG root. In such a deployment, RNFD also works but need not detect crashes of an individual node comprising the virtual root. This is, however, an expected behavior because, despite the crash of the node, the root as a whole continues to function. Depending on the deployment policies, RNFD may need to be configured with a different threshold, though. Consequently, I believe that virtual DODAG roots also need to be mentioned in the draft, which I forgot about. Thanks for the remark! As for the comments below, I will try to apply them to the draft, together with addressing the previous issues, and get back to you when this has been done. > It seems that you might want a term for the LBR's children. > That is, the devices at rank "1", that hear the LBR's DIOs. > > I think that I would move some of section 3.2 further forward in the > document. I think that I need a gentler introduction to CFRCs here, and I > don't really need to know the properties, rather I need a higher-level idea > of things. Since section 4 goes over the operations again, I would leave > it for that spot, and make it a section 4.1. > > Having gone forward and back a bit, I'm still a bit uncertain how nodes > assign themselves a bit... oh, self() in section 4 says "random". > Why not make this a function (hash?) of the short-IPv6 address or something? > > Not every media has ACK frames at the L2 to establish that there are > failures. It might be worth putting the Detecting and the Verifying into > separate sections. Aside from the ANIMA case (which is usually pure ethernet), > there are also situations where there is an ethernet backbone connecting a > few 6LBRs (RFC8929), and your protocol would sensibly run on both the > wireless and the wired side of the 6LBRs. > > I also wonder if the RNFD could be included in DAOs (particularly storing > mode ones) sent to the DODAG root. > I know that probably seems senseless: why tell the root that you are > observing it to be dying.... But, it acts as interesting telemetry about > what the nodes are seeing, and might serve as a useful indication of imminent > failure, or some kind of systematic long-cycle pathology. > > Your IANA considerations are how the document will look after IANA has > processed it. Prior to that point, you need to write it as a request. > > Something like: > > IANA is requested to allocate the value TBD1 from the "RPL Control Message > Options" sub-registry of the "Routing Protocol for Low Power and Lossy > Networks (RPL)" registry. > > I like to include the URL of the registry in my request to be really really > clear, and to save everyone else the time to find it. > > Your security considerations will want to cite RFC7416. > In particular, 7.2.4, and section 7.3.4 and 7.3.5 might be relevant. Best, -- - Konrad Iwanicki. From nobody Wed Apr 14 07:48:20 2021 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 4841C3A10E7 for ; Wed, 14 Apr 2021 07:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.618 X-Spam-Level: X-Spam-Status: No, score=-9.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=OrGVRoZw; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=MtQDDGns 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 j9uuY5TEyAQp for ; Wed, 14 Apr 2021 07:48:14 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F230C3A10E9 for ; Wed, 14 Apr 2021 07:48:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4855; q=dns/txt; s=iport; t=1618411694; x=1619621294; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=J6Q+HAHxzrcEGFDNGSfLgCKs1TBL98ZuFBjtEtetDd4=; b=OrGVRoZwm8Z8WCimO4AKR7lDh+KEa9Mwcu5bEjw3Jy7BGPFEdJkVLUdK d9DQm7h+t/3GF1ra74KvlnaAsnVoZ4f1srpRw78ic3VBnqV7yDv5NRl22 jwXoPChH1iWd55p5URHIpYUVnHOa/ATfb5aRWOGf9XMT+gsg0mcV3FjOb o=; X-IPAS-Result: =?us-ascii?q?A0AfAgBP/3ZgmJFdJa1aHgEBCxIMQIFHC4FTUX5aNjELi?= =?us-ascii?q?AADhTmIawOUdYRHgS4UgREDVAEKAQEBDQEBHQsKAgQBAYEWAYM5AoFzAiU0C?= =?us-ascii?q?Q4CAwEBAQMCAwEBAQEBBQEBAQIBBgQUAQEBAQEBAQFohVANhkQBAQEEAQE4B?= =?us-ascii?q?gEBLAwLBAIBCBEEAQEBHhAnCx0IAgQTCIJpAYJVAy8BDqItAoofd4E0gQGCB?= =?us-ascii?q?AEBBoUmGIITAwaBOYJ4gnFRhxonHIFJQoFWVIELgQA+gmABAQIBgSMcIINKg?= =?us-ascii?q?iuBaYE6DAMdEgMRDgIgOAMBKRMYFBoVgQEDkC5JlwuSUAqDC4lnkz+DTYYCh?= =?us-ascii?q?HmBPJR0lRWLbpJTBgiEYQICAgIEBQIOAQEGgVQ4gVtwFTuCaVAXAg6OHwwNC?= =?us-ascii?q?YNOhRSFRXMCATUCBgoBAQMJfIsDAYEOAQE?= IronPort-PHdr: A9a23:SqPluRb255s3bYg1b5wx1aL/LTDfhN3EVjU944c7i79IbqWo9ojjO 0qa//h2kVvVRu3z6v9YhazRqa+zEWAD4JPUtncEfdQMUhIekswZkkQmB9LNEkz0KvPmLklYV MRPXVNo5Te3ZE5SHsutZlDOrDu19zFBUhn6PBB+c+LyHIOahs+r1ue0rpvUZQgAhDe0bb5oa husqgCEvcgNiowkIaE0mXP0 IronPort-HdrOrdr: A9a23:Vd8KuKn0UAZBLaF35fHZxaBf4CnpDfNMjmdD5ilNYBxZY6Wkvu iUtrAyyQL0hDENWHsphNCHP+26TWnB8INuiLNxAZ6LZyOjnGezNolt4c/ZwzPmEzDj7eI178 ldWoBEIpnLAVB+5PyU3CCRGdwt2cTC1aiui/vXwXsFd3AUV4hL6QBlBgGHVmh/QwdbDZQ0fa DsmPZvjTymZHgRc4CHHXEDRefOvJnmk5jhbB4ACXccmUizpBmv76P3FAXd4wcGX1p0sPkf2E Xmsyi83KWstPmn1gTRvlWy0716kMbso+EzfPCkp8QbJi72hgvtSYhlW6KPpyBdmpDV1H8Ei9 /Jyi1QWvhby3SURW2tpAuo5g+I6kdT11bH6Xu1xUTuutb4QjVSMbsAuat8fgHC40Qt+PFQuZ g7pV6xjJZcARPekCmV3bGhPHsG+jvW0BgfuNUegHBFXYwVZKU5l/1jwGpuDJwCECjmgbpXd9 VGMcDG6P5aNXOcYnzJ11MfueCEY3UpEh+KBnUFo8yeugIm+kxR8k1w/r16ol4wsLYGD7VU7e XNNapl0JtUSNUNUK57DOAdBeOqF23kW3v3QSGvCGWiMJtCF2PGqpbx7rlwzvqtYoY0wJw7n4 mEeE9EtFQ1Z1nlBaS1rd922yGIZF/4cSXmy8lY6ZQ8kKb7XqDXPSqKT01rtMe8vfMFAIn+V+ yoMJxbR9/vRFGeXLph7knbYd1/OHMeWMoatpIQQFSVuP/GLYXsq6jVa/DWKL3xESs1W2/2D3 cZNQKDY/lo3wSOYDvVkRLRU3TidgjU5pRrCpXX+OAV1cwMO+R3w04ooGX8wvvOBSxJs6Qwck c7CqjgiLmHqW6/+nuN621oPxFaH1tE+bmIaQISmSY6d2fPNZoTsdSWfm5fmFGdIAVkcs/QGA lD41Jt+ay2KJSUzTs4C82uN3+bi3d7ngPPc74s3om4oev1cJIxCZgrHIZrEx/QKhBzkQF27H tYZBQcXU/ZHDP2gaCjhJgZbduvL+VUsUOOG4p5uHjfvUKTqYUTXXMdRSepStPSqx0pXSBoil p49LI/jLKMlS20E3Y2hP01PTR3GT+qKYMDKD7ARY1P3pj3ZQl7TA6x9E2noiB2XlCvymI/qS jKKzaOdfTCH1xH00oooprCwRdTbWWSf0V5d3Zgl5ZyfF624Epb4Kusere51XeXZx8kxOwQWQ u1PQc6E0dJ28290gKTlXK5MUgegr8qPuDbEd0YAuzu83uwNYyFkrwHFfdI/JBjcMvjqPMPTP j3QX7nEBroT+wuwACbvXAjJW19r2Qli+rh3Fn/4HG/x2NXO4ueHH12A7UaKcqb9W7qWrKB14 h4l8s8uYKLQy7MQ8/DzaHcdDhYLBzP5WawUuEzsJhR+aY/rqF6EZWeUTzG0hh8rV8DBdaxkE MVW6Jg5r/dfodpYswJYipcukMzi87nFjpcjiXmRuslOV09hX7SON2Ep7LOtLo0G0WE4A/9I0 OW/SFR9+rMNhHzmYIyGuY1OyBbeUI84HNt8KeZe4rcBB6jeutD8FC5W0XNOIN1WeyAA/Edvx x669aHk6uLbCL+whnXpiY+LaRU8WqrKPnCTz6kCKpN6Zi9NluNiKfxv5L2gzfzVDeha0MXwY dCblcda8xfij8kyI07uxLCPpDfswYgiR9Z5zoii1vmno6h623fFVtdMQLYjo5NNAMje0SgnI DA66yAyH/54DJZwpHNG0dbY8FWF7ErP/3KBjYrLdJVoaWh8KUuiDlSeRsiD2YzjzbmwuNttI 3Jr8n6SqnlEnfnOVUI5D5DCMp1h0UQ2BN9T/Q= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,222,1613433600"; d="scan'208";a="670120636" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Apr 2021 14:48:12 +0000 Received: from mail.cisco.com (xbe-aln-006.cisco.com [173.36.7.21]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 13EEmCH2019971 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 14 Apr 2021 14:48:12 GMT Received: from xfe-rcd-004.cisco.com (173.37.227.252) by xbe-aln-006.cisco.com (173.36.7.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Wed, 14 Apr 2021 09:48:12 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xfe-rcd-004.cisco.com (173.37.227.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Wed, 14 Apr 2021 09:48:11 -0500 Received: from NAM02-DM3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 14 Apr 2021 10:48:11 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UjymAeSpTeMHDLhVrvlG07zsu2IsAMPBddK5riM06ZuuVqB7OjbCAeELRa1o9plFNTa0RI9zqrusFhAX+iAd+To/CjA1YUkJoeDMJgmff8ipYETzbHiB08yn8LM7a31pFPEZ4LysOTpxKeXpOFCABrIDFOLyythZqhQvkC6WRDdDZk125S6nKKJsgUVacKDmKvy7iZ3bJFuwVNN0uO4QxMUPViuUtIhjzVonPiclH2t/EwWXDMWjJoIhLG1xKTBiowBsZ9ooiP2YPJTrxFH7JUtqalNAwBKt6a15v6SNJ3VrW7OFR2UsVzdDt8dvTVA8V9tYxCHOcUC/HN/QGfAcyA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nHRTgqM92p1DlDfXUHHqdHJZXsMhGIXCUb8D4ZzgjcE=; b=XmTsQd2TozGoXa96EXNoNfq89wAH7OJu8S0mEAOGf7YtZihhu96AWmSmjMnx31hfccdc7cwkB2uiET4knz8BTLtst10m20OObIPY6Se3A5bkaPf6w6PTmxotaLzBB/TiG0n55T4OMqQ6hpDmhVel408d8CKrcC2YL4vY96fTbSnL9JK6+WAuJwGTZJFtLFHqePBwhlcz9AeQllMksjU252UoldPt2HBVDuUVhuZ9tcxkE2HJor/Nsy1FN/dBwD8wp7/ZZxgOisCvbl/l8VNFJX1TDJDGK+GY65rxQ4cbU37Uh9d1RZRX2kGQvrRQbvNVS+N2b2rlwvbm753zH2eZXw== 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=nHRTgqM92p1DlDfXUHHqdHJZXsMhGIXCUb8D4ZzgjcE=; b=MtQDDGns+nNKZ31LUwIDdcsoF1m1yaVB07imbFoFEELemKCaPMJPEhnmoeZbdPwKqfb0d0Ftg8MBGPbUuDYlKcmiQQT3rIolicS47vl+hd4Gadg00pgqyKgSai5ulvnl2IYnX85sX52ZU8GW1Fm6sdUJ7zOnb4YOleWHd4jRf8k= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MWHPR11MB1934.namprd11.prod.outlook.com (2603:10b6:300:114::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.24; Wed, 14 Apr 2021 14:48:10 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::cd01:ffc9:6592:b1d5]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::cd01:ffc9:6592:b1d5%6]) with mapi id 15.20.4020.022; Wed, 14 Apr 2021 14:48:10 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks , "Pascal Thubert (pthubert)" Thread-Topic: [Roll] Border router failure detection Thread-Index: AQHXK+V11ZIg9ppwIUWAf2h5ir/s+6qqqk1AgAB3pYCAByLXkA== Date: Wed, 14 Apr 2021 14:47:59 +0000 Deferred-Delivery: Wed, 14 Apr 2021 14:47:25 +0000 Message-ID: References: <49ac5fc3-4a3c-fb87-d366-eb7e7cfd60df@mimuw.edu.pl> <18233.1583176305@localhost> <10272666-28c7-ab3e-9ceb-1b8f2bb6e5e5@mimuw.edu.pl> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.220.54] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: aca5bff9-fea3-46c1-4d2b-08d8ff5452da x-ms-traffictypediagnostic: MWHPR11MB1934: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: VMLEwt8puBToLVa6RY8ZLyOWt59WOX2bPzWcUfQAXb/BuD0u/v94JnFn3mIbGzRRSOwg+cxC90qXo/5DqBdQdpvaUivbodxXORvCyC1SJ74VGT/bHcZp7M+n0B/xZEDrymes6JrLC3tgHk+qjWzHw0FAyo/gAAF4TWFPhnIssJoj2bt9UqUtBHDEuREu+ggje+/6yc6AAncyqgoIGIsfv1Y4tAsD/uWRte8Bftt7jGi0cljOgEdJa0C0j9N1b+3sOtPmSZiNxPt6BMKYDbSZdr94KQDoiJJSgrb4sDl5z3HNmnRP3q/kEsL1n55wYONln3zNdsPs6lm8L1Iiu1eqjY06XRI1qp/tIOGrQQrPTAGUt6BIN8oHBHv4EXKgmRwuIBxkVSOyy0kn1VW0EIPj8KxxskJU6+Smw7522eNVEvibvgr6/s60hsB38BBeWCPBWnetjoNgfQSCXp4pIAvC65SLbsrybVh8490tUtSdclNMwZHHkQcCdPbJ1ZRKg8IvHMdUIdcypcFR5/VzIAek10KwHHYc6JKQoTiSTg0uDF8sWkVIiucqK+ApRJJPHirb9zUdcJbadXznh/nzOgVhGcm68ZXJs9xraFDygOJ3TJqozx4JEVlZoEhvUKPR0ufID0q/merv8/8Vbz+PrQYDEYAVkZxpaakKm6N7QTfJQEHOlhq2egfXcqUtdQQXyuw3 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:(396003)(39860400002)(136003)(346002)(376002)(366004)(186003)(38100700002)(66946007)(8676002)(5660300002)(83380400001)(76116006)(478600001)(2906002)(71200400001)(122000001)(86362001)(66556008)(66574015)(33656002)(9686003)(53546011)(52536014)(316002)(7696005)(55016002)(6506007)(66446008)(66476007)(966005)(64756008)(6666004)(110136005)(8936002)(26005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?kmu2a5njOHdj4mieazJmee3q89CS93UDl8U2/9BxPHIh1ggChvuQHu7DSjhf?= =?us-ascii?Q?fQJUMiA9kaxGZ2bjW3XIIn2qdRFIoLZnn985ad4ut8UMsM4ref/R2iXrWBbS?= =?us-ascii?Q?N6UwWgMWXmjycuyy7zKs8unra9JAsPLpJglZZtZl2b1PNrOhKZfPL+svRgph?= =?us-ascii?Q?vDDBPws+rLWOECn49W0qVuy5VoR+9Ptqk9KcfgCI+bg/miOL3579xr+B7zbs?= =?us-ascii?Q?a2cUk4bYpo2JpLNWgmFoxwFNHs5iVsuBA46x/iyFCOp3qlU2rX+TZmTFHi/E?= =?us-ascii?Q?mHIvsDuPHNNVgqF+bmZh9gX0vZb0ZTJG2QmpVyBfb7QpBcUjytI3hfNxk22I?= =?us-ascii?Q?aFZQ+5QMB6TVjtg0ZJT0bNQboNF3STbyDDdxeEGu4YbVQbDFdl+6HkUOawRR?= =?us-ascii?Q?nqf8hUWtAI/eOLqYTBdapmS2rjKjZ5IrGcZkHk/T1okilduvC24CSblI5WOb?= =?us-ascii?Q?OywS4aTByQ1/3RNCjBQOwINscRLycu0Pp53Z3+scZArILrk0LJC9sB9eB7bA?= =?us-ascii?Q?fjmhdI012JLCwiyVuOcPyUkIh7bDEFIOQ7QDYdz9+jzZaFnwxV8MNVcd6YKQ?= =?us-ascii?Q?5HhIAnvxQR8YjiWDAhtTlUb3wlj7OnNvZQ4B+TUYjJPvO0tnDWcUWfSRvcfM?= =?us-ascii?Q?881yIUxNNVyOSsnCVzyvAQLpECQPqMwFesiFkmxLulkuJJQSb5Fjrro0uwa2?= =?us-ascii?Q?pYu6v04UAmJbcnNW/fUPXSXPqMCgUcTN118ja5PeBLF1/JoYhV/JeTgFUNJJ?= =?us-ascii?Q?dbdUAwUqT91O2nBeZFEd5CtAT8SGuIcTljQjx/x5QSs5AdJ4h2Yf5WVVEHt5?= =?us-ascii?Q?0EX1IEvY/beX9e8pyo5JV3Izqc7BVLzfzFgpajLQLYhmyjA4gggFd/KngnFR?= =?us-ascii?Q?ZtWTzUPYnZ/zpTz2ZyBV/oFTx/DYvQjQmsgrBuU7d5zNr7X6y9rcRHx/qCaA?= =?us-ascii?Q?wd/V95AwRP79Vv9P240yjGXcjJGJ4DWxto9GJccY+6krneFxKsnN5KPpWycu?= =?us-ascii?Q?QdlKXksDTjgs7Ff5V6D8WR8saQ/r7Q76Ndte9feUyBYIwXp4kwn3J0M9n97a?= =?us-ascii?Q?R55O1cNzqjKtCHZdF8/DUNGXRlXG3WLfwiKmkIElvHn8EMcQKyZWNXIjtNML?= =?us-ascii?Q?lHpYfRaZiYrMmjaYw8m79wJDSAJ5oxDZ5YNJ7WmNYwY0mfs7TPvKypNuours?= =?us-ascii?Q?SeAXyCmKTOxGiX9Y7IRJtLV5O8mAEfZZHpicVQDprR2+aMFe9gwAg8W0KYbH?= =?us-ascii?Q?054y0rn3hu+RG1lgobbhhPg52lUgOvNI24e6qd4qK2k2/3MShfgFTSW3WkPo?= =?us-ascii?Q?VhhPcRlp8AEeaAmJ83EzCTWx?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4881.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: aca5bff9-fea3-46c1-4d2b-08d8ff5452da X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2021 14:48:10.3795 (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: p5dlcYFkypWCWD4BuKjt8EDtPsU2C4A0ttgq4AnxyUrS/ramjWz+yq1AL0aErdSqfB2YOsNkHLyDMRqnoTVH7g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1934 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.21, xbe-aln-006.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [Roll] Border router failure detection 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, 14 Apr 2021 14:48:19 -0000 Hello Konrad At an abstract level I see your proposal as a form of BFD where the network= assesses the liveliness of the root. The operation is done by a number of = representatives that must agree that the root is gone. The draft does a goo= d job at addressing the Byzantine problem once we know who the generals are= , but it's unclear to me how they are elected and how they converse. That's a family of questions around the issue of how we avoid false positiv= e. Seems that the more sentinels the less of them. But the less efficient t= he algorithm is.=20 - do the sentinels encompass all first hop nodes? - how do we compute the right number of sentinels? - do the sentinels needs direct connectivity to one another? - how quick should the protocol react ?=20 - I mean, if the root reboots, is that worth the hassle of breaking and for= ming the DODAG again? - do the sentinels form a connected group ? how ? if not, what happens if o= ne group loose connectivity to the root but the other does not? Keep safe; Pascal > -----Original Message----- > From: Roll On Behalf Of Konrad Iwanicki > Sent: jeudi 8 avril 2021 23:20 > To: Routing Over Low power and Lossy networks ; Pascal > Thubert (pthubert) > Subject: Re: [Roll] Border router failure detection >=20 > Hi again Pascal, >=20 > On 08/04/2021 16:16, Pascal Thubert (pthubert) wrote: > > Hello Konrad > > > > About this text > > " > > > > Since all DODAG paths lead to the corresponding LBR, detecting its > > crash by a node entails dropping all parents and adopting an > infinite > > rank, which reflects the node's inability to reach the LBR. > However, > > achieving this state for all nodes is slow, can generate heavy > > traffic, and is difficult to implement correctly [Iwanicki16] > > [Paszkowska19] [Ciolkosz19]. > > " > > > > Please note that this may be what an implementation decides to do, but > is by far not my favorite option. > > The alternate is to rest the "G" but and become floating root. The > benefit is that the DODAG structure is mostly maintained and that routing > inside may persist. > > > > See https://tools.ietf.org/html/rfc6550#section-18.2.4 for how to > configure this. >=20 > OK, I think I addressed this in my previous e-mail to you and Michael. >=20 > (The next two e-mails will have to wait till tomorrow I am affraid.) >=20 > Best, > -- > - Konrad Iwanicki. >=20 > >> -----Original Message----- > >> From: Roll On Behalf Of Konrad Iwanicki > >> Sent: mercredi 7 avril 2021 21:37 > >> To: Routing Over Low power and Lossy networks > >> Subject: Re: [Roll] Border router failure detection > >> > >> Dear all, > >> > >> Approximately a year ago, I joined the WG and advertised an extension > >> to RPL that I had been working on for some time with a goal of > >> describing it in a draft. Unfortunately, just when I got the > >> necessary pointers and a few initial comments, the pandemic broke > >> out. The resulting surge of professional and personal obligations > >> made it literally impossible for me to participate in and, at some > >> point, even follow the group's activities, for which I am sorry. > >> > >> However, I did strive to regularly find a little time to get somewhat > >> acquainted with IETF's procedures and write up something that may > >> resemble a draft. I have just submitted it as: > >> > >> draft-iwanicki-roll-rnfd-00 > >> > >> and created a dedicated repository on the group's GitHub. > >> > >> Since I have no experience writing IETF documents, I would really > >> appreciate your collaboration on either turning the text into a true > >> draft or concluding that this should not be done. > >> > >> Please, keep mind in mind that I decided to maximally cut down the > >> original algorithms, so that the extension is as simple as possible > >> without losing key properties. Therefore, it is likely that if the > >> extension as a whole or any of its parts turn out relevant or > >> interesting, still a considerable amount of work may be necessary to > >> have it or them described properly. Your contribution is most welcome. > >> > >> Thanks in advance. > >> > >> Best regards, > >> -- > >> - Konrad Iwanicki. > >> > >> _______________________________________________ > >> Roll mailing list > >> Roll@ietf.org > >> https://www.ietf.org/mailman/listinfo/roll > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Wed Apr 14 08:46:29 2021 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 125E03A1447; Wed, 14 Apr 2021 08:46:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Lars Eggert via Datatracker To: "The IESG" Cc: draft-ietf-roll-aodv-rpl@ietf.org, roll-chairs@ietf.org, roll@ietf.org, Ines Robles , aretana.ietf@gmail.com, mariainesrobles@googlemail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Lars Eggert Message-ID: <161841517905.8620.14903415282133221941@ietfa.amsl.com> Date: Wed, 14 Apr 2021 08:46:19 -0700 Archived-At: Subject: [Roll] Lars Eggert's No Objection on draft-ietf-roll-aodv-rpl-10: (with COMMENT) 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: Wed, 14 Apr 2021 15:46:25 -0000 Lars Eggert has entered the following ballot position for draft-ietf-roll-aodv-rpl-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-roll-aodv-rpl/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 2, paragraph 1, comment: > 2. Terminology Is there some logic as to which terms are capitalized and which are not? (Also in the text.) ------------------------------------------------------------------------------- All comments below are very minor change suggestions that you may choose to incorporate in some way (or ignore), as you see fit. There is no need to let me know what you did with these suggestions. Section 4.1, paragraph 10, nit: > X > Reserved. Any recommendation what this should be set to on send? Section 4.2, paragraph 9, nit: > X > Reserved. Any recommendation what this should be set to on send? Section 4.2, paragraph 13, nit: > Rsv > MUST be initialized to zero and ignored upon reception. I guess these bits are reserved? Could you not just mark them X? Section 4.3, paragraph 6, nit: > Figure 3: ART Option format for AODV-RPL MOP X is missing from the description of the fields. Section 1, paragraph 4, nit: - functionality to support routes with birectional asymmetric links. + functionality to support routes with bidirectional asymmetric links. + ++ Section 5, paragraph 7, nit: - of cells used in 6tisch), a priori knowledge (e.g. link quality + of cells used in 6tisch), a priori knowledge (e.g., link quality + + Section 5, paragraph 7, nit: - for evaluating link state (see([RFC7548], [RFC7276], [co-ioam]) MAY - ^ + for evaluating link state (see [RFC7548], [RFC7276], [co-ioam]) MAY + ^ Section 6.2.1, paragraph 4, nit: - the downward (i.e. towards the TargNode) direction of the link + the downward (i.e., towards the TargNode) direction of the link + + Section 6.3.1, paragraph 2, nit: - symmetric route along which both directions satisfy the Objective - ------------ + symmetric route both of whose directions satisfy the Objective + +++++++++ Section 6.3.1, paragraph 2, nit: - routes (i.e. S=0). Selection between a qualified symmetric route - ^ + routes (i.e., S=0). Selection between a qualified symmetric route + ^ From nobody Thu Apr 15 02:55:57 2021 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 044163A1907; Thu, 15 Apr 2021 02:55:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Peter Van der Stok via Datatracker To: Cc: draft-ietf-roll-aodv-rpl.all@ietf.org, last-call@ietf.org, roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161848055597.18527.2186863564067252978@ietfa.amsl.com> Reply-To: Peter Van der Stok Date: Thu, 15 Apr 2021 02:55:56 -0700 Archived-At: Subject: [Roll] Iotdir telechat review of draft-ietf-roll-aodv-rpl-10 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, 15 Apr 2021 09:55:56 -0000 Reviewer: Peter Van der Stok Review result: Ready with Nits Review of draft-ietf-roll-aodv-rpl-10 Peter van der stok, 15 April 2021 In general, the document is well written. By looking regularly into RFC 6550, I am rather sure that I could implement the protocol. The question remains how this draft relates to RFC 6997. When the WG decides that this draft replaces RFC 6997, then it would be good to copy some text from 6997 to this draft, because RFC 6997 is more explicit about the use of RPL parameters as specified in RFC 6550 and presents more explicit motivation. Many thanks for this document peter _________________________________________________________ Some suggestions for the text follow here: Page 14, lines 3 and 4; OLD: ART Options and within New: ART Options. Within Page 14, line 9 distinguished -> generated page 14 section 6.2.1 OLD: does not belong to the RREQ-Instance NEW: has not joint the RREQ-Instance Joining is used in Step 1, 2nd paragraph. Question: what is the "best previous RREQ"? Page 14, Step 1, 2nd paragraph OLD: router's Rank would not exceed NEW: router's Rank does not exceed Page 15 end of Step 3; Question: What is a "stale sequence number"? Page 15, section 6.2.2 OLD: If the OrigNode tries to reach multiple TargNodes in a single RREQ-Instance, one of the TargNodes can be an intermediate router to the others, therefore it MUST continue sending RREQ-DIO to reach other targets. NEW: If the OrigNode tries to reach multiple TargNodes in a single RREQ-Instance, it MUST continue sending RREQ-DIO to reach other Targets because one of the TargNodes can be an intermediate router to the others. End Page 15 OLD: but have different NEW: with different OLD the intersection of these list NEW the intersection all received lists Page 16 line 8 OLD associated with the NEW for a given Page 17: the terms occupied RPLInstanceID, and second RPLInstancID are difficult to parse. Maye be use received RPLInstanceID and shifted RPLInstanceID? Further on you use original RPLInstanceID, is that a third one? Question: what does "shifted into another integer" mean? Question: who or what chooses the shift value, when is it set and into which RREP-DIO field is the shifted value set? Page 18 Step 2; Are multiple addresses possible in the ART option. I just understood there is only one per RPLInstanceID (shifted or not). Page 18 Step 3, As above Stale sequence number? From nobody Thu Apr 15 05:15:41 2021 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 81F273A1D9B; Thu, 15 Apr 2021 05:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.918 X-Spam-Level: X-Spam-Status: No, score=-11.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=Y/WBWQMP; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=IC3MO5ef 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 ghH99s4EyWcJ; Thu, 15 Apr 2021 05:15:35 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFF0C3A1D97; Thu, 15 Apr 2021 05:15:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4836; q=dns/txt; s=iport; t=1618488934; x=1619698534; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OP8774WWweivbFusvKcle5zY5gO39vaf/PHQKhPnDDA=; b=Y/WBWQMP55cBkfsD8ABQKOcbTTvDnRWJKBrR3nCkoAXsxIHvWssGF2K3 JEeom/GS2odvBH+r/PDmWjaIHx43P+vmi0LlJTbPSu8NYT756EpC/Q3ol LCKhyee/skydlwpj1bHcZrKSX9R7ptOBrabPaT7cfdHRnvIG9CBN3Y+im Q=; IronPort-PHdr: =?us-ascii?q?A9a23=3A7ot7xRKrJ/YRh9H1+tmcuZsyDhhPgJ39IxIV5?= =?us-ascii?q?5w7irlHbqWk+dH4MVfC4el25HfXVIPX5uhfl+3V9af6Vj9I7ZWAtSUEd5pBH?= =?us-ascii?q?18AhN4NlgMtSMiCFQXgLfHsYiB7eaYKVFJs83yhd0QAHsH4ag7Mq3u+4CQJB?= =?us-ascii?q?hL8cw1vKbe9Fovblc/i0ee09tXaaBlJgzzoZ7R0IV22oAzdu9NQj5FlL/M6y?= =?us-ascii?q?wDCpT1DfOEFrV4=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3ATN4d36D/4X6Jp3rlHei9tceALOonbusQ8z?= =?us-ascii?q?AX/mhLY1h8btGYm8eynP4SyB/zj3IrVGs9nM2bUZPgfVr1zrQwxYUKJ7+tUE?= =?us-ascii?q?3duGWuJJx/9oeK+VPdMgXE3Kpm2a9kGpIQNPTZB1J3lNu/xQG+HcopztXvyt?= =?us-ascii?q?HWuc715R5WPGZXQotn6Bp0DRveMmAefngHObMSEp2A6s1b4x+pfnoKZsq2b0?= =?us-ascii?q?N1IdTrjdvNiZ7gfFo6HBYh8gaDlneF77T9Hhie0H4lInBy6J0l9nXIlBG827?= =?us-ascii?q?W7v5iAu17h/kLwz7ATotvuzdNfGNeB4/J0FhzAghulDb4RIIGqkysypIiUmT?= =?us-ascii?q?MXufnK5ywtJsFir07WF1vF3SfF/ynF/HIQ52T5yVme6EGT4/DRYD4hEcJOic?= =?us-ascii?q?Z4X3LimjAdlepx2q5KwG6V3qA/ZXir8UiNhKmrazhQmkW5unYkm+II5kYvLL?= =?us-ascii?q?c2UqNbroAU4SpuYfE9NR/684wuHa1PC8zR9Z9tACunRk3ZpWVmzZiQWG0yFH?= =?us-ascii?q?69MzE/k/GSugIm+ExR/g89/ogyj30A/JUyR91v/OLfKJllk7lIU4s/cb99LP?= =?us-ascii?q?1pe7rzNkX9BTb3dE6CK1XuE68Kf1jXrYTs3bkz7Oa2PLQV0ZoJnojbWl8wjx?= =?us-ascii?q?93R2veTem1mLFb+BHER2uwGR73zNtF2pR/srrgAJ3mLDOEU1Jrt8e7uf0QDo?= =?us-ascii?q?n6Vp+ISdVrKs6mCVGrNZdC3gX4VZUXA2IZStcpttEyXE/LrdnMLoHsq+zHYP?= =?us-ascii?q?feLLfgCl8fKzrCK0pGeAK2CNRL70itVHO9qgPWQWnRdkv2+o81EKWyxZlK9K?= =?us-ascii?q?E9cql39iQFg1Ww4c+GbRdYtLYtQUd4KLT71qeypWy8+3fU/3xkUyAtVXp90f?= =?us-ascii?q?HFaTdntAUKO0T7ffIooNOEY11f23OBO1t4VMPZEAlWolxt4qKpJ5mMxSQvYu?= =?us-ascii?q?jXdF6yvj82njanXp0ckqqM6YPOYZUjFKsrX6R3CEHWDRBvgB1rr21CcQcAQU?= =?us-ascii?q?faGlrV+P+Ypa1RINuaW8h3gQ+tL8IRlGnWsl+Eo9ozAlEBWSS1bMKRiQEyZj?= =?us-ascii?q?Zdi1Fr6ZUDiL6YlTvHExpjvM0IdHl3LEWeGvZvERmMboQ8oMGbRChACUOxwQ?= =?us-ascii?q?G8pz52UGzw7EkWjnHmNkSvCIH2K2sYnGtZ3Kbs+E5zbUOHcStLGyxHmLw4M3?= =?us-ascii?q?jasXBu1uLOQay/3wKqGwU/69BYFi3Zaj0PJQ4r/fSL7Vq+nTaPEmhO/ORwAs?= =?us-ascii?q?XUEKkjf7bP2nmkNY2PkuUcE+VJ+Yt+XeqewNMjTfiSYEucIj/+FooSqn+oj2?= =?us-ascii?q?dgNy9upHY+l/T0nBXj8WijxXY6ReHfOVJ8WtggUp2hxnmhQ/aDy5Nii90p+e?= =?us-ascii?q?O2L2Xqc9aDoJunJQJrO1fWoWSsSfsvpo0RtaUutKFrF52eVTfTznlI0FE/K8?= =?us-ascii?q?jz/XluDZhT8fTEOoV1edYVdD8c9l01lM6XJE9uqxfoGIYFDBgQpm6eO8nM76?= =?us-ascii?q?vDqLIpDEHErAzsOUOH+ykY+/veRSOM2bMTFqpYGxUYVGEsrHB5uO+SfYzZDw?= =?us-ascii?q?unM/tO+1e3KXexer5QQqrtI8Rakj9qp9WT2+OHfSvx3w7d+SZhKqVV6mC9XI?= =?us-ascii?q?e8BhmPFeMgya31BX2cxq+xpMi9gzf8RWHlNwAWhYhZeVcRacoGgD84l4Ez2j?= =?us-ascii?q?WzTKuyok9NqSoo3Rh30lr2no6h6yPHGEsDNwvTiJBfRyNSPXiFlt6ty5nR6F?= =?us-ascii?q?3tpDxenYDeH0JRdMxUE9ceToLrPz5jQPJgyIKA7u4qmGBfex8gAG43lSDl0+?= =?us-ascii?q?5n1bm/3u/OW+eKMwafBXsRvThfBoB1mSQ3qWZPN8imhKjNFzkqKg=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B7AABrLXhg/5ldJa1aHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgT8GAQELAYFSUQd3WjYxhEODSAOFOYhsA5k8gS6BJQNUCwE?= =?us-ascii?q?BAQ0BAR0LCgIEAQGEUAIXgVwCJTUIDgIDAQEMAQEFAQEBAgEGBHEThVANhkQ?= =?us-ascii?q?BAQEEAQEhBA0MAQEsCwELBAIBCBEDAQIDAiYCAgIlCxUICAIEAQ0FgnEBglU?= =?us-ascii?q?DLwEOoEYCih95fzOBAYIEAQEGhTAYghMDBoEPKgGCd4QKhlInHIFJQoETJxy?= =?us-ascii?q?CXz6CYAEBgWCDFzWCK4J4BDIELxQQWyAEBhNFBhAOESCUTqUDPYELCoMMl06?= =?us-ascii?q?FNgQfpHuVF6M3AgICAgQFAg4BAQaBVgE3gVlwFTsqAYI+UBcCDo4fg3CFFIV?= =?us-ascii?q?FczgCBgEJAQEDCXyMEgEB?= X-IronPort-AV: E=Sophos;i="5.82,223,1613433600"; d="scan'208";a="887814171" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Apr 2021 12:15:23 +0000 Received: from mail.cisco.com (xbe-rcd-001.cisco.com [173.37.102.16]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 13FCF6YX027763 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Thu, 15 Apr 2021 12:15:21 GMT Received: from xfe-aln-003.cisco.com (173.37.135.123) by xbe-rcd-001.cisco.com (173.37.102.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Thu, 15 Apr 2021 07:15:13 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xfe-aln-003.cisco.com (173.37.135.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Thu, 15 Apr 2021 07:15:13 -0500 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 15 Apr 2021 08:15:12 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bcV7wzRM4aL9fTb5khr2T8K0GZul1uCtB1pwfXZgmf9eGbSzfP1jhODInCuetoUAMJsk7qv5q4SPRN0ZXkxMxmYZsU8tv5KB1WGa/eZ2Bc+tke7q2h5dI+qw2OyF5IHmbtHVqsdZPbTNr3kgNWX0wiHpt7C/OX4KYre4wsND9X1UtSYiGB7EkeDSVrmJN38EXpjxUt6L/VvcCtImSr3Fizh2YCNdxSD/ETL86jNvMTzfaOEIwPTIr9tWnfSYoY8nPpyzL8IrzHIee1LlIvVIxyYuFiChA0TZV0j51C0blxwMv0Ux9KPaZPQp1Pov3yQ+ci9HBsKqK2brwTcBPEx+Ng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OP8774WWweivbFusvKcle5zY5gO39vaf/PHQKhPnDDA=; b=Zo72DGNhXNwLALPt++CNi2SBZo5TQTmXQFB27ChFneM7U+MNVEv2OO23BT3fC0iCO7pLGK/v8/xEDWlLd092ndWvnwBGuBzY4uZxPhqS8IGwWFxOoHTvYjCsUafUptgnw9Xfgw/VBHMvwFJPeiSdRiNdSxJOQk7Hv2Vc1MFt7Ebf/MD8606mQTvT/ZE/DhtQK8Pxa0vrXsSrTXoArS9LjJ8T7dNzM5PNfKlYEtJZ83kHW1pwUPIN63cgjoLXfYhMfNvmZEsgSkgQT6pM0bOFwZfOeU2SN5HowI8wvB16lb+NxOZBgnmZio0T4n5C5ZauIg07nNgA5dz4JXPjvFh/Lg== 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=OP8774WWweivbFusvKcle5zY5gO39vaf/PHQKhPnDDA=; b=IC3MO5ef9Z0bibnWlJRSsFeOsl2xc9rqA7Z/t62Db/mYF8W0kYvabSMee1rh9jePPWIEkvo9z2ABQjFQq+ouxDUy9mUMYgrzfxiVsw+Mcne0g2RXs5oX2gycj19I/BiXVRfWQN/QaxFiXHXgIzdGalMG/CZ23ugdmFyxhJagpYA= Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB4965.namprd11.prod.outlook.com (2603:10b6:510:34::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.18; Thu, 15 Apr 2021 12:15:10 +0000 Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::dcdf:3910:b85d:6eba]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::dcdf:3910:b85d:6eba%7]) with mapi id 15.20.4042.018; Thu, 15 Apr 2021 12:15:10 +0000 From: "Eric Vyncke (evyncke)" To: Peter Van der Stok , "iot-directorate@ietf.org" CC: "last-call@ietf.org" , "roll@ietf.org" , "draft-ietf-roll-aodv-rpl.all@ietf.org" Thread-Topic: [Iot-directorate] Iotdir telechat review of draft-ietf-roll-aodv-rpl-10 Thread-Index: AQHXMd2uyDEwChKLc0u6iLwzVfFHpaq1n8CA Date: Thu, 15 Apr 2021 12:15:10 +0000 Message-ID: <824AC95C-2CE5-4C57-A937-29062B13CDDD@cisco.com> References: <161848055597.18527.2186863564067252978@ietfa.amsl.com> In-Reply-To: <161848055597.18527.2186863564067252978@ietfa.amsl.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.48.21041102 authentication-results: vanderstok.org; dkim=none (message not signed) header.d=none;vanderstok.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:c0c1:36:1d1e:f116:2535:4da1] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f85df955-15d2-4a10-5f30-08d900081d9c x-ms-traffictypediagnostic: PH0PR11MB4965: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: GlNcYUAubcKwdGPdGVF18Y0+k0v3nq9hOlZM7SNWV7JXu9AlPmW/a7tiOwN83Pxv0anyKEhWCR9pNtA48Kfb6t/+XyD/ZvvdZCtgYcvx0fDUVVywZm2W/ArWXKrVqn0Ghn8Bc9fFcvOESCLD8m7OXcomUSEKOv2relfg2eTttcOnjXu8mjor5fiz1BJ0vWWOqWEPtRABDYZISdVzoiOK92Mv1YQ8hFqP6Q3iBnzINla5n/prGOuQptgH+A6eUhe4Wd8+FsSKu2SMKHobbF/eRe5a8UqbrNU2NMf3N2kkCtwI027xLiQon2e4/hKxIrzgMASeRproMmSxbECLDXnGHUCRU4MqNeLkkdrW05o/AtLma5ZwHp2Uo2o1JqCV8Oqf49CaODeSZRo7nfBRo/CsPMthsLHg+7nNVnXFva7KyVWkby9dWjZXAFafy6zleg36shO/zMxofyGN5dNhSJ2GA4TOu/Lw9iTJMgIbEiEmThmjJ+9gNjyDK8hXinpLmywwxwDeb4WMvJL8cLCiXUvzBSIs/aIP3IXfCG0Ru9ifRM7UxiOx2Pt171eiqqeqv4SfMfxu4AAHHgYWB6p/xNM/VeC8QqARszJxuIlamlePsl9oI3St46XRkcuitLwYJpSH4p/u5mnIMxxRnaQ9hIzRfylMKk132LyZQaqiaSuPJGaA4DMYy4EVIl9v0kbmeQ0GBroSfDIXRZR+QzNJxiSyxLjz2i0YZw4Pqr0IHgAgcDI= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(376002)(39860400002)(136003)(366004)(396003)(53546011)(8936002)(6506007)(6486002)(66574015)(8676002)(76116006)(71200400001)(54906003)(91956017)(122000001)(2906002)(316002)(4326008)(110136005)(186003)(66476007)(5660300002)(66446008)(36756003)(86362001)(478600001)(83380400001)(33656002)(64756008)(38100700002)(2616005)(6512007)(66556008)(966005)(66946007)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?emhnd2FhMEZONGhHWUdEdmNuTk1ZY1FnNiswenVXVjZzVjVFYkcweXlCL0ha?= =?utf-8?B?WWN3OUl4eCt0d3RYMmhKMlJtdGlDOVROb3JENlpNT2NXZEZRYWRIK1FSdHJL?= =?utf-8?B?NUkyYUdpMnoxTFJhMi9XRmhWVllDa3B5YTNzajVCYWQ4RXZMSzlLUXZ3MUhO?= =?utf-8?B?d2dINE9BSzVkcHh4d0IyYVJJVTVhWThSY0V3ZmtmVVE5S29OM0FqNmZjVlFt?= =?utf-8?B?U3F1aXNzRnEwczkyNm5RdFd5Z1plbmJUWFI3eEhvY1Z1NWUydHhrSnNuZW8y?= =?utf-8?B?T2N1VS9CZisrS2h0cEgwM1RqR1FXRUtBYUZpL0R3Nm5EQzZPdTRrT3hmQllR?= =?utf-8?B?ZkN5MkVRTzZIZ0xRUEp2anJlYVkrKyttbDBLRCtublBoTTZTMUMvSnBoRHBR?= =?utf-8?B?QW5YU0VpUys0UU1RVHc1Y0ZqQUY2U0JSL0IrS3FnQjkvTUQ5b09hdlFtYXIr?= =?utf-8?B?MnlCWnpKaGtLUFZTb1NsUDFYQlE2MmV6NGZMMURzZTRZN01ZWkkrMlhOM3JV?= =?utf-8?B?Ly9mUlRyWnRDQ0JaVS80dUcyVkFvZ0R3N0JvUkdOemJNRlFpbU95UEZhUktB?= =?utf-8?B?Q083Sm5EeEpCdGdQK2JKdkNOT0JkOUhWYStpZ0I2WWJsdDJMNmZBSnNobVJM?= =?utf-8?B?UFE1TmFHektvaS91L1hoRkRsd2NFMnpFOXRpbk1EaEJyK0hoRk9tWXNmK3l1?= =?utf-8?B?VTVZUkZ0ZEllRjhrMkxURHF0Z0IvRTRlOXRkUXU1WVlBZ3lGZ2xDektwY3pR?= =?utf-8?B?SE9OOGVCM1RhNTlRT1NoY0tOYXRqNUZKMUNGUExNeTZGVzljZnJOcWd4clRE?= =?utf-8?B?NjlkcDdEYkFubVl6WThPSVBDbmQrZ0Q1WEFCcU02dCs4MkNkME1XQ0E4cER1?= =?utf-8?B?S2UxNWhqdHpTbUZ3Q2hJVC9zaktkNVQrMzVsOGh4Ni8rY3pSb3E2dWpoK3Jl?= =?utf-8?B?eWJNTlR4NXVqeFhKTUdJSGh3K1RmcW5saTFoL3VHc0RoSWVEY2NRS2hveXEz?= =?utf-8?B?QjV6TnF0Ynh2MFpkOGs0VE5TSVU0MEd5aHVPcmRoeFlGelRDdEpNUTg4c1ky?= =?utf-8?B?MkVvMzdkVTMySU5KOCtjSFNZaTJ2ZW9Sb0V0UVBjell0VkpjYldtQStrS01Q?= =?utf-8?B?ZXNnRm54SklvTHZNQ1UvRC9RRldYdUhtMkdMOGNZcmpIZDJTMEh6bVVLamI1?= =?utf-8?B?d1BIMndNc1YrNGFaNU12TlhvSkNtTkJZTXFrVGZXZXc5aGdEc1FKZEVaajZE?= =?utf-8?B?SEFXanJmRFZ1cU5Pem5CVGQxZGRNSnFYWURIWDhlMmo0WXpZNUV2clJlT3BB?= =?utf-8?B?dktJLzM5d20rTjZma3BGWlJyUm9kT3J5K3FyT282cHBoM3VLMFpiYXBCSUxO?= =?utf-8?B?N0ZkR3VaZ2t0Z3Y1dk5Lc0dtZThXaFVMcXlJd3h1NjdXSlBYVnM4bkFsS3NP?= =?utf-8?B?dDhvY2tib0ZVU0I2R3BUMmh2aitHVHRST256L1dQY0U1cEtwcmgwcUczRDlX?= =?utf-8?B?N2g2a2JoOWt6OWxUMXNJL1ZrcXFmaHVBZU1pMFhhN2VZeGZKbjU0dzVEVTNy?= =?utf-8?B?Vy9NQmlxQlo2Zy85dzNDMS9GQzk0czJUNmNhNE5kSDJ0RjFQR2dFY0JlSktB?= =?utf-8?B?QU1VdHAyWFp0OHlMelJ2RXVEb2QyMGpGQWpueTBWb1NQeUdLREZkcDZOWFVK?= =?utf-8?B?T3M1SVlEalZwMERmektSUjUxU0V1WHFXVmZISm5qUjdPOGVzUHlpVisxSWNT?= =?utf-8?B?VGxEeEZBWVVCc3ZqeTJ5cFZvM25JeXhWSkJKMmlTSVBmRG5nV3BjVXByd01E?= =?utf-8?B?K3NPNm42bVluZXJuWjlpVUtZZmFubjF3bEtjd0wxblF0RVVnTGc3dkdmZFlU?= =?utf-8?Q?LgarF2vWFWO27?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <31B53962C090E441B0DA5641CDE665A7@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f85df955-15d2-4a10-5f30-08d900081d9c X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2021 12:15:10.4618 (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: y2va7XGEkJZqMvL/7TWWKsjHrAQ1nrsHrPqMWpnVEWh3lsROuhevR5d2Zm4XCSiivg/o72FueMd9CP3nuBSK+w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4965 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.16, xbe-rcd-001.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [Roll] [Iot-directorate] Iotdir telechat review of draft-ietf-roll-aodv-rpl-10 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, 15 Apr 2021 12:15:40 -0000 VGhhbmsgeW91IFBldGVyIGZvciB5b3VyIHJldmlldywgSSByZWFsbHkgYXBwcmVjaWF0ZSBpdCBh bmQgd2lsbCB1c2UgaXQgd2hlbiBiYWxsb3Rpbmcgb24gdGhlIGRvY3VtZW50Lg0KDQpSZWdhcmRz DQoNCi3DqXJpYw0KDQrvu78tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSW90LWRp cmVjdG9yYXRlIDxpb3QtZGlyZWN0b3JhdGUtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9m IFBldGVyIFZhbiBkZXIgU3RvayB2aWEgRGF0YXRyYWNrZXIgPG5vcmVwbHlAaWV0Zi5vcmc+DQpS ZXBseS1UbzogUGV0ZXIgVmFuIGRlciBTdG9rIDxjb25zdWx0YW5jeUB2YW5kZXJzdG9rLm9yZz4N CkRhdGU6IFRodXJzZGF5LCAxNSBBcHJpbCAyMDIxIGF0IDExOjU3DQpUbzogImlvdC1kaXJlY3Rv cmF0ZUBpZXRmLm9yZyIgPGlvdC1kaXJlY3RvcmF0ZUBpZXRmLm9yZz4NCkNjOiAibGFzdC1jYWxs QGlldGYub3JnIiA8bGFzdC1jYWxsQGlldGYub3JnPiwgInJvbGxAaWV0Zi5vcmciIDxyb2xsQGll dGYub3JnPiwgImRyYWZ0LWlldGYtcm9sbC1hb2R2LXJwbC5hbGxAaWV0Zi5vcmciIDxkcmFmdC1p ZXRmLXJvbGwtYW9kdi1ycGwuYWxsQGlldGYub3JnPg0KU3ViamVjdDogW0lvdC1kaXJlY3RvcmF0 ZV0gSW90ZGlyIHRlbGVjaGF0IHJldmlldyBvZiBkcmFmdC1pZXRmLXJvbGwtYW9kdi1ycGwtMTAN Cg0KICAgIFJldmlld2VyOiBQZXRlciBWYW4gZGVyIFN0b2sNCiAgICBSZXZpZXcgcmVzdWx0OiBS ZWFkeSB3aXRoIE5pdHMNCg0KICAgIFJldmlldyBvZiBkcmFmdC1pZXRmLXJvbGwtYW9kdi1ycGwt MTANCiAgICBQZXRlciB2YW4gZGVyIHN0b2ssIDE1IEFwcmlsIDIwMjENCg0KICAgIEluIGdlbmVy YWwsIHRoZSBkb2N1bWVudCBpcyB3ZWxsIHdyaXR0ZW4uIEJ5IGxvb2tpbmcgcmVndWxhcmx5IGlu dG8gUkZDIDY1NTAsIEkNCiAgICBhbSByYXRoZXIgc3VyZSB0aGF0IEkgY291bGQgaW1wbGVtZW50 IHRoZSBwcm90b2NvbC4gVGhlIHF1ZXN0aW9uIHJlbWFpbnMgaG93DQogICAgdGhpcyBkcmFmdCBy ZWxhdGVzIHRvIFJGQyA2OTk3LiBXaGVuIHRoZSBXRyBkZWNpZGVzIHRoYXQgdGhpcyBkcmFmdCBy ZXBsYWNlcw0KICAgIFJGQyA2OTk3LCB0aGVuIGl0IHdvdWxkIGJlIGdvb2QgdG8gY29weSBzb21l IHRleHQgZnJvbSA2OTk3IHRvIHRoaXMgZHJhZnQsDQogICAgYmVjYXVzZSBSRkMgNjk5NyBpcyBt b3JlIGV4cGxpY2l0IGFib3V0IHRoZSB1c2Ugb2YgUlBMIHBhcmFtZXRlcnMgYXMgc3BlY2lmaWVk DQogICAgaW4gUkZDIDY1NTAgYW5kIHByZXNlbnRzIG1vcmUgZXhwbGljaXQgbW90aXZhdGlvbi4N Cg0KICAgIE1hbnkgdGhhbmtzIGZvciB0aGlzIGRvY3VtZW50DQoNCiAgICBwZXRlcg0KICAgIF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K ICAgIFNvbWUgc3VnZ2VzdGlvbnMgZm9yIHRoZSB0ZXh0IGZvbGxvdyBoZXJlOg0KICAgIFBhZ2Ug MTQsIGxpbmVzIDMgYW5kIDQ7DQogICAgT0xEOiBBUlQgT3B0aW9ucyBhbmQgd2l0aGluDQogICAg TmV3OiBBUlQgT3B0aW9ucy4gV2l0aGluDQogICAgUGFnZSAxNCwgbGluZSA5DQogICAgZGlzdGlu Z3Vpc2hlZCAtPiBnZW5lcmF0ZWQNCiAgICBwYWdlIDE0IHNlY3Rpb24gNi4yLjENCiAgICBPTEQ6 IGRvZXMgbm90IGJlbG9uZyB0byB0aGUgUlJFUS1JbnN0YW5jZQ0KICAgIE5FVzogaGFzIG5vdCBq b2ludCB0aGUgUlJFUS1JbnN0YW5jZQ0KICAgIEpvaW5pbmcgaXMgdXNlZCBpbiBTdGVwIDEsIDJu ZCBwYXJhZ3JhcGguDQogICAgUXVlc3Rpb246IHdoYXQgaXMgdGhlICJiZXN0IHByZXZpb3VzIFJS RVEiPw0KICAgIFBhZ2UgMTQsIFN0ZXAgMSwgMm5kIHBhcmFncmFwaA0KICAgIE9MRDogcm91dGVy J3MgUmFuayB3b3VsZCBub3QgZXhjZWVkDQogICAgTkVXOiByb3V0ZXIncyBSYW5rIGRvZXMgbm90 IGV4Y2VlZA0KICAgIFBhZ2UgMTUgZW5kIG9mIFN0ZXAgMzsNCiAgICBRdWVzdGlvbjogV2hhdCBp cyBhICJzdGFsZSBzZXF1ZW5jZSBudW1iZXIiPw0KICAgIFBhZ2UgMTUsIHNlY3Rpb24gNi4yLjIN CiAgICBPTEQ6DQogICAgSWYgdGhlIE9yaWdOb2RlIHRyaWVzIHRvIHJlYWNoIG11bHRpcGxlIFRh cmdOb2RlcyBpbiBhIHNpbmdsZSBSUkVRLUluc3RhbmNlLA0KICAgIG9uZSBvZiB0aGUgVGFyZ05v ZGVzIGNhbiBiZSBhbiBpbnRlcm1lZGlhdGUgcm91dGVyIHRvIHRoZSBvdGhlcnMsIHRoZXJlZm9y ZSBpdA0KICAgIE1VU1QgY29udGludWUgc2VuZGluZyBSUkVRLURJTyB0byByZWFjaCBvdGhlciB0 YXJnZXRzLg0KDQogICAgTkVXOg0KICAgIElmIHRoZSBPcmlnTm9kZSB0cmllcyB0byByZWFjaCBt dWx0aXBsZSBUYXJnTm9kZXMgaW4gYSBzaW5nbGUgUlJFUS1JbnN0YW5jZSwgaXQNCiAgICBNVVNU IGNvbnRpbnVlIHNlbmRpbmcgUlJFUS1ESU8gdG8gcmVhY2ggb3RoZXIgVGFyZ2V0cyBiZWNhdXNl IG9uZSBvZiB0aGUNCiAgICBUYXJnTm9kZXMgY2FuIGJlIGFuIGludGVybWVkaWF0ZSByb3V0ZXIg dG8gdGhlIG90aGVycy4NCg0KICAgIEVuZCBQYWdlIDE1DQogICAgT0xEOiBidXQgaGF2ZSBkaWZm ZXJlbnQNCiAgICBORVc6IHdpdGggZGlmZmVyZW50DQoNCiAgICBPTEQgdGhlIGludGVyc2VjdGlv biBvZiB0aGVzZSBsaXN0DQogICAgTkVXIHRoZSBpbnRlcnNlY3Rpb24gYWxsIHJlY2VpdmVkIGxp c3RzDQoNCiAgICBQYWdlIDE2IGxpbmUgOA0KICAgIE9MRCBhc3NvY2lhdGVkIHdpdGggdGhlDQog ICAgTkVXIGZvciBhIGdpdmVuDQoNCiAgICBQYWdlIDE3OiB0aGUgdGVybXMgb2NjdXBpZWQgUlBM SW5zdGFuY2VJRCwgYW5kIHNlY29uZCBSUExJbnN0YW5jSUQgYXJlDQogICAgZGlmZmljdWx0IHRv IHBhcnNlLiBNYXllIGJlIHVzZSByZWNlaXZlZCBSUExJbnN0YW5jZUlEIGFuZCBzaGlmdGVkDQog ICAgUlBMSW5zdGFuY2VJRD8gRnVydGhlciBvbiB5b3UgdXNlIG9yaWdpbmFsIFJQTEluc3RhbmNl SUQsIGlzIHRoYXQgYSB0aGlyZCBvbmU/DQoNCiAgICBRdWVzdGlvbjogd2hhdCBkb2VzICJzaGlm dGVkIGludG8gYW5vdGhlciBpbnRlZ2VyIiBtZWFuPw0KICAgIFF1ZXN0aW9uOiB3aG8gb3Igd2hh dCBjaG9vc2VzIHRoZSBzaGlmdCB2YWx1ZSwgd2hlbiBpcyBpdCBzZXQgYW5kIGludG8gd2hpY2gN CiAgICBSUkVQLURJTyBmaWVsZCBpcyB0aGUgc2hpZnRlZCB2YWx1ZSBzZXQ/DQoNCiAgICBQYWdl IDE4IFN0ZXAgMjsgQXJlIG11bHRpcGxlIGFkZHJlc3NlcyBwb3NzaWJsZSBpbiB0aGUgQVJUIG9w dGlvbi4gSSBqdXN0DQogICAgdW5kZXJzdG9vZCB0aGVyZSBpcyBvbmx5IG9uZSBwZXIgUlBMSW5z dGFuY2VJRCAoc2hpZnRlZCBvciBub3QpLg0KDQogICAgUGFnZSAxOCBTdGVwIDMsIEFzIGFib3Zl DQogICAgU3RhbGUgc2VxdWVuY2UgbnVtYmVyPw0KDQoNCg0KICAgIC0tIA0KICAgIElvdC1kaXJl Y3RvcmF0ZSBtYWlsaW5nIGxpc3QNCiAgICBJb3QtZGlyZWN0b3JhdGVAaWV0Zi5vcmcNCiAgICBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lvdC1kaXJlY3RvcmF0ZQ0KDQo= From nobody Thu Apr 15 11:57:40 2021 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 320A83A2AF8; Thu, 15 Apr 2021 11:57:30 -0700 (PDT) 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, 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=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 uG7ZYxMAgLbP; Thu, 15 Apr 2021 11:57:25 -0700 (PDT) Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (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 30EE03A2AF4; Thu, 15 Apr 2021 11:57:25 -0700 (PDT) Received: by mail-ej1-x633.google.com with SMTP id sd23so29782615ejb.12; Thu, 15 Apr 2021 11:57:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=fuyVvCgQD9orvMJnsU77s1mwzeJKy75chysHx2V1LPo=; b=tfSkpzHb0122BL3Y+KwD8ek448xHlw1LZYMr7/MpD7F6iRRWzporjR7JBWS4IniDaF X1EQAv4ZY/7rFxFUJDZ/RaA1WMF4VmIGkmfNxgMQSn4ula2hF5q510GhhFN4zZnMga41 OjR9jwy2f3tEf62HT3ADdmkoRRKZjPTaIyhHCIN67OtGAiHG8FL58BRBUR9voiLUhDCx h3oSENiCYmjOv6ClZm4rVMNFktOdK2Wa7PytMGpwGHhnX0A55zMxm4wT8nJ8UJ2OvkDP Up3ZmoVk3wIk5qih7Vnbs9hG3bkVFcklT6FnSuOZutFcNWZX/2B0B2dEKoDi/jYW8nzn 8FWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=fuyVvCgQD9orvMJnsU77s1mwzeJKy75chysHx2V1LPo=; b=TE5QKSEwI+v6a7KDYKpuiTsuyOs1eHYjHlvfXZx5p9rPa03076VsHzr5qA5CIkqVyt KfPNevt7X1pI14ZmXJZQZQaaxhqPajd1MPnI6bxyR6JrpewtkJgYjMar9CaWOuQ+AMS7 sNCvlynmF63wyYLvGaRYgZwkjXwR32INjxa3bbfrw1rg0aWZEo4HmLHoQs4OF75EUH7t 8HvOIl/J58fzuccNj5LmNHAAVHL93iXi7gWQvl55kvhtN8xk38cqnPGn02PJcsWetHGJ QDadPNetUHyUl7ElAOQKLqkpNzRux/7CNSpu0Fh3fJ/xUhXSWEhBRWsnErepwe0bk3oK OVbw== X-Gm-Message-State: AOAM530w+Wub8st0WYQKqtIKxbdyhJ3mj0hMuFsQOHu7aQ5f6ILWbpkt WenX7lUQebASSZsiRuySVGz3oY+i7HmxkUjGyVI= X-Google-Smtp-Source: ABdhPJxr4KLEk9mIQ5oaMnqCgq4QNYmxjSCcg6eZqMBY47+nhhjAAI/ENWzPZVIgoQ9h7+ZLfaLkifZHIDWYk3HLIrw= X-Received: by 2002:a17:906:134d:: with SMTP id x13mr4971088ejb.61.1618513041823; Thu, 15 Apr 2021 11:57:21 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 15 Apr 2021 18:57:21 +0000 From: Alvaro Retana In-Reply-To: <161848055597.18527.2186863564067252978@ietfa.amsl.com> References: <161848055597.18527.2186863564067252978@ietfa.amsl.com> MIME-Version: 1.0 Date: Thu, 15 Apr 2021 18:57:21 +0000 Message-ID: To: Peter Van der Stok Cc: last-call@ietf.org, draft-ietf-roll-aodv-rpl.all@ietf.org, iot-directorate@ietf.org, roll@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Roll] Iotdir telechat review of draft-ietf-roll-aodv-rpl-10 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, 15 Apr 2021 18:57:30 -0000 On April 15, 2021 at 5:55:57 AM, Peter Van der Stok wrote: Peter: Hi! =C2=A0I hope you're doing well! > In general, the document is well written. By looking regularly into RFC 6= 550, > I am rather sure that I could implement the protocol. The question remain= s > how this draft relates to RFC 6997. When the WG decides that this draft > replaces RFC 6997, then it would be good to copy some text from 6997 to t= his > draft, because RFC 6997 is more explicit about the use of RPL parameters = as > specified in RFC 6550 and presents more explicit motivation. As you know, the roll WG considered the question of replacing rfc6997 as part of my AD review [1]. =C2=A0At the time there didn't seem to be any strong interest in doing so. =C2=A0Do you think that has changed? Thanks for the review! Alvaro. [1] https://mailarchive.ietf.org/arch/msg/roll/r3MP2MKrWqTMVmAQjKJDfU6iu-A/ From nobody Thu Apr 15 23:48:22 2021 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 B69443A18E5; Thu, 15 Apr 2021 23:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 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.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bbhmail.nl 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 SIX9f-Ak2dsn; Thu, 15 Apr 2021 23:48:07 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0222.hostedemail.com [216.40.44.222]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 587223A18E3; Thu, 15 Apr 2021 23:48:06 -0700 (PDT) Received: from omf08.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay06.hostedemail.com (Postfix) with ESMTP id 6AAF5180721B1; Fri, 16 Apr 2021 06:48:05 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: stokcons@bbhmail.nl) by omf08.hostedemail.com (Postfix) with ESMTPA id 000411A29F6; Fri, 16 Apr 2021 06:48:04 +0000 (UTC) MIME-Version: 1.0 Date: Fri, 16 Apr 2021 08:48:04 +0200 From: Peter van der Stok To: Alvaro Retana Cc: Peter Van der Stok , last-call@ietf.org, roll@ietf.org, draft-ietf-roll-aodv-rpl.all@ietf.org, iot-directorate@ietf.org Reply-To: consultancy@vanderstok.org In-Reply-To: References: <161848055597.18527.2186863564067252978@ietfa.amsl.com> User-Agent: Roundcube Webmail/1.4.11 Message-ID: <2899fa5646cea7c4de6b34ee3f9436dd@bbhmail.nl> X-Sender: stokcons@bbhmail.nl Organization: vanderstok consultancy Content-Type: multipart/alternative; boundary="=_0bb9c5a8d41ec8a255cb093248a20a7c" X-Stat-Signature: mwxy4fg83td6ccrt6jbnbxufcstyhszq X-Rspamd-Server: rspamout05 X-Rspamd-Queue-Id: 000411A29F6 X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C X-Session-ID: U2FsdGVkX19uXRGIPzsBadxQkgV41og9ewJreYXw4Z8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bbhmail.nl; h=mime-version:date:from:to:cc:subject:reply-to:in-reply-to:references:message-id:content-type; s=key; bh=Qu9ssatUenWdKXWuRAcBEuoHi+Eu5nh6pnQ13nf3nVY=; b=ghnItR9frfBkmP1+mvBlWLqeo6l8TpAJVhKlRbRjxUdRihw3BN8xIqVAvdOpM4Yutsn+s/LRwKRKgWzo72i81AP0E8l9l3mgkLhOdW0vcCasBvVqb0+t/wy/6Fb3aG8Wpj7/gwhi0K8QP2urAwNfLTf+/07q581ya2LeNbs3nXU= X-HE-Tag: 1618555684-566776 Archived-At: Subject: Re: [Roll] [Iot-directorate] Iotdir telechat review of draft-ietf-roll-aodv-rpl-10 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, 16 Apr 2021 06:48:13 -0000 --=_0bb9c5a8d41ec8a255cb093248a20a7c Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Hi Alvaro, Yes, I'm fine; I hope you are also in good health. Since a year I am not following the undercurrents in the ROLL WG. I am unable to tell you what they think about replacing rfc6997 currently. When I was chair, I was more concerned with the continuation of the document than eventual consequences for rfc6697. However, I think that this is the right moment to reconsider the replacement question. Having two aodv documents may be confusing for ROLL adopters. BTW, I encouraged the creation and development of rfc6697 for the reasons mentioned in the document. When replacement is considered, this motivation is needed in the new aodv draft. Hope this explains a bit better my review remarks. Greetings, Peter Alvaro Retana schreef op 2021-04-15 20:57: > On April 15, 2021 at 5:55:57 AM, Peter Van der Stok wrote: > > Peter: > > Hi! I hope you're doing well! > >> In general, the document is well written. By looking regularly into >> RFC 6550, >> I am rather sure that I could implement the protocol. The question >> remains >> how this draft relates to RFC 6997. When the WG decides that this >> draft >> replaces RFC 6997, then it would be good to copy some text from 6997 >> to this >> draft, because RFC 6997 is more explicit about the use of RPL >> parameters as >> specified in RFC 6550 and presents more explicit motivation. > > As you know, the roll WG considered the question of replacing rfc6997 > as part of my AD review [1 [1]]. At the time there didn't seem to be > any > strong interest in doing so. Do you think that has changed? > > Thanks for the review! > > Alvaro. > > [1] > https://mailarchive.ietf.org/arch/msg/roll/r3MP2MKrWqTMVmAQjKJDfU6iu-A/ Links: ------ [1] https://mailarchive.ietf.org/arch/msg/roll/r3MP2MKrWqTMVmAQjKJDfU6iu-A/ --=_0bb9c5a8d41ec8a255cb093248a20a7c Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 Hi Alvaro,

Yes, I'm fine; I hope you are also in good health.
Since a year I am not following the undercurrents in the ROLL WG= =2E I am unable to tell you what they think about replacing rfc6997 current= ly.
When I was chair, I was more concerned with the continuation of th= e document than eventual consequences for rfc6697.

However, I th= ink that this is the right moment to reconsider the replacement question.Having two aodv documents may be confusing for ROLL adopters.


BTW, I encouraged the creation and development of rfc6697 for the r= easons mentioned in the document.
When replacement is considered, this= motivation is needed in the new aodv draft.

Hope this explains = a bit better my review remarks.

Greetings,

Peter

Alvaro Retana schreef op 2021-04-15 20:57:

= On April 15, 2021 at 5:55:57 AM, Peter Van der Stok wrote:


Peter:

Hi!  I hope you're doing well!


In general, the document is well written. By looking r= egularly into RFC 6550,
I am rather sure that I could implement the pr= otocol. The question remains
how this draft relates to RFC 6997. When = the WG decides that this draft
replaces RFC 6997, then it would be goo= d to copy some text from 6997 to this
draft, because RFC 6997 is more = explicit about the use of RPL parameters as
specified in RFC 6550 and = presents more explicit motivation.

As you know, the roll WG considered the question of replacing rfc6997=
as part of my AD review [1].  At the time there didn't seem to be any
stron= g interest in doing so.  Do you think that has changed?

Tha= nks for the review!

Alvaro.

[1] https://mailarchive.ietf.org/arch/msg/rol= l/r3MP2MKrWqTMVmAQjKJDfU6iu-A/
--=_0bb9c5a8d41ec8a255cb093248a20a7c-- From nobody Mon Apr 19 08:44:14 2021 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 164253A36C9; Mon, 19 Apr 2021 08:44:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Francesca Palombini via Datatracker To: "The IESG" Cc: draft-ietf-roll-aodv-rpl@ietf.org, roll-chairs@ietf.org, roll@ietf.org, Ines Robles , aretana.ietf@gmail.com, mariainesrobles@googlemail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Francesca Palombini Message-ID: <161884704906.8680.6192562844809236074@ietfa.amsl.com> Date: Mon, 19 Apr 2021 08:44:09 -0700 Archived-At: Subject: [Roll] Francesca Palombini's No Objection on draft-ietf-roll-aodv-rpl-10: (with COMMENT) 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: Mon, 19 Apr 2021 15:44:09 -0000 Francesca Palombini has entered the following ballot position for draft-ietf-roll-aodv-rpl-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-roll-aodv-rpl/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work on this document. I have some minor comments/questions below. Francesca 1. ----- Section 2. FP: Thank you for this very extensive (and useful) terminology section. I would suggest to add a sentence to say that the reader is expected to be familiar with RFC 6550 terminology. Alternatively, it might be good to add terms defined there and used in this document, such as DODAG and DODAGID, into this section as well. It also might improve readability to add references to documents when appropriate (for example, DIO could reference RFC 6550). 2. ----- to OrigNode. Intermediate routers join the Paired DODAGs based on the Rank as calculated from the DIO message. Henceforth in this FP: Please add a reference to where Rank is first defined, and/or add it to the terminology. 3. ----- Target Prefix / Address (variable-length field) An IPv6 destination address or prefix. The Prefix Length field contains the number of valid leading bits in the prefix. The length of the field is the least number of octets that can contain all of the bits of the Prefix, in other words Floor((7+(Prefix Length))/8) octets. The remaining bits in FP: "Floor((7+(Prefix Length))/8)" I am not sure where the "7+" comes from. Noting that the Prefix Length is 7-bit long, I am tempted to say that the number of octets calculated here also includes Prefix Length, however that is not clear from the sentence above ("The length of the field" - I assume the field refers to the Target Prefix / Address only). I think some clarification is necessary. From nobody Mon Apr 19 13:32:10 2021 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 C76C13A4323; Mon, 19 Apr 2021 13:31:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: John Scudder via Datatracker To: "The IESG" Cc: draft-ietf-roll-aodv-rpl@ietf.org, roll-chairs@ietf.org, roll@ietf.org, Ines Robles , aretana.ietf@gmail.com, mariainesrobles@googlemail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: John Scudder Message-ID: <161886431878.23690.10633892549620498188@ietfa.amsl.com> Date: Mon, 19 Apr 2021 13:31:58 -0700 Archived-At: Subject: [Roll] John Scudder's Discuss on draft-ietf-roll-aodv-rpl-10: (with DISCUSS and COMMENT) 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: Mon, 19 Apr 2021 20:32:05 -0000 John Scudder has entered the following ballot position for draft-ietf-roll-aodv-rpl-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-roll-aodv-rpl/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- A lot of effort has clearly gone into this work, thank you. I do have one topic I want to DISCUSS, as it seriously impacted the readability of the document from my point of view. I don’t anticipate that it will be very difficult to resolve this DISCUSS as it relates to clarity and not to anything fundamental. My chief difficulty with the document is placing it in context. No hints are given to the reader as to what the expected network environment is. I think it would be almost sufficient to say, for example “the network environment is assumed to be the same as described in RFC 6550, Section 1” for example, but without that hint and without a strong background in ROLL, I found myself struggling. Figures 4 and 5 in particular lead me to believe the expected environment looks similar to a classic ISP network — a collection of nodes connected by point-to-point links. If this isn’t correct (and I bet it’s not) that may have led me into incorrect assumptions, which may be reflected in my other comments below. Further, it’s not stated anywhere whether AODV-RPL is intended to stand alone as its own routing protocol, or to be viewed as an extension of RPL. In the former case, it seems the document is lacking details that are present in RFC 6550. I’m assuming the latter is the case, but a clear statement to that effect seems indicated. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1. Section 1: Reply. AODV-RPL currently omits some features compared to AODV -- in particular, flagging Route Errors, blacklisting unidirectional links, multihoming, and handling unnumbered interfaces. Your use of language is entirely up to you, but I feel obliged to point out that there’s been a lot of discussion in the IETF community recently about use of language that raises sensitive points, and about the term “blacklisting” in particular. I understand that this is the only place in the document the term appears, and since it refers to AODV you can’t just use another term, but placing it in quotation marks might make it clear that it’s referring verbatim to the language of RFC 3561. 2. Section 1: support for storing and non-storing modes. AODV adds basic messages RREQ and RREP as part of RPL DIO (DODAG Information Object) control Did you mean “AODV-RPL adds”? 3. Section 2: Symmetric route The upstream and downstream routes traverse the same routers. Same routers? Or same links? (Or both, if multi-access links are part of the mix, as I imagine they may be?) 4. Section 4.1: OrigNode sets its IPv6 address in the DODAGID field of the RREQ-DIO message. A RREQ-DIO message MUST carry exactly one RREQ option, Should that say “one of its IPv6 addresses"? Is it even necessary to restate this? RFC 6550 §6.3.1 already has a clearer requirement: DODAGID: 128-bit IPv6 address set by a DODAG root that uniquely identifies a DODAG. The DODAGID MUST be a routable IPv6 address belonging to the DODAG root. 5. Section S4.1: TargNode can join the RREQ instance at a Rank whose integer portion is equal to the MaxRank. Not less than or equal, right? Strict equality to MaxRank is required? 6. Section 4.2: TargNode sets its IPv6 address in the DODAGID field of the RREP-DIO message. A RREP-DIO message MUST carry exactly one RREP option, Same as #4. 7. Section 4.2: Address Vector Only present when the H bit is set to 0. For an asymmetric route, the Address Vector represents the IPv6 addresses of the route that the RREP-DIO has passed. The first time I read through this, I didn’t understand it at all. On re-reading, I think you’re using the word “route” in two different ways in the same sentence, the first time to mean “route” in the sense of an object in the protocol, the second time in the more casual sense of “a path through the network”. If that’s right, I suggest rewriting the second instance, as in “… represents the IPv6 addresses of the path through the network the RREP-DIO has traversed.” Also, as in point #4, is it right to say *the* IPv6 addresses? Couldn’t any given node have various IPv6 addresses? So maybe just lose the definite article, as in “… represents IPv6 addresses of the path…”? 8. Section 4.3: r A one-bit reserved field. This field MUST be initialized to zero by the sender and MUST be ignored by the receiver. The figure doesn’t show an “r” field. I assume the field labeled “X” should be relabeled as “r”? 9. Section 5: Figure 4. If an intermediate router sends out RREQ-DIO with the S bit set to 1, then all the one-hop links on the route from the OrigNode O to this router meet the requirements of route discovery, On first reading I didn’t understand this. Having read the whole document, I now get it (I think!). Possibly changing “meet” to “have met” would have been enough to get me past my initial befuddlement. 10. Section 5: The criteria used to determine whether or not each link is symmetric is beyond the scope of the document. For instance, intermediate Should be “criterion … is beyond", or "criteria … are beyond", depending on whether you want singular or plural. 11. Section 5: routers can use local information (e.g., bit rate, bandwidth, number of cells used in 6tisch) I wouldn’t have minded a reference for 6tisch. 12. Section 5: Upon receiving a RREQ-DIO with the S bit set to 1, a node determines whether this one-hop link can be used symmetrically, i.e., both the two directions meet the requirements of data transmission. If the RREQ-DIO arrives over an interface that is not known to be symmetric, or is known to be asymmetric, the S bit is set to 0. If the S bit arrives already set to be '0', it is set to be '0' on retransmission The term “retransmission” seems misused here. I guess you mean something like “when the RREQ-DIO is propagated”. 13. Section 5: Appendix A describes an example method using the upstream Expected Number of Transmissions" (ETX) and downstream Received Signal Strength Indicator (RSSI) to estimate whether the link is symmetric in terms of link quality is given in using an averaging technique. This sentence needs a rewrite to make it grammatical. It works up until "is given in using an averaging technique”. 14. Section 6.2.1: If the S bit in the received RREQ-DIO is set to 1, the router MUST determine whether each direction of the link (by which the RREQ- DIO is received) satisfies the Objective Function. In case that the downward (i.e. towards the TargNode) direction of the link does not satisfy the Objective Function, the link can't be used symmetrically, thus the S bit of the RREQ-DIO to be sent out MUST be set as 0. If the S bit in the received RREQ-DIO is set to 0, the router MUST determine into the upward direction (towards the OrigNode) of the link. The last sentence doesn’t make sense. 15. Section 6.2.1: If the router is an intermediate router, then it transmits a RREQ- DIO via link-local multicast; On what interface? Routers generally can have multiple interfaces. Again, this is a place a clear description of the network environment might have helped. 16. Section 6.2.2: If the OrigNode tries to reach multiple TargNodes in a single RREQ- Instance, one of the TargNodes can be an intermediate router to the others, therefore it MUST continue sending RREQ-DIO to reach other targets. In this case, before rebroadcasting the RREQ-DIO The use of the term “broadcast” here confuses me. Is this “broadcast” in the RF sense? Again, this is a place a clear description of the network environment might have helped. 17. Section 6.2.2: send out any RREQ-DIO. For the purposes of determining the intersection with previous incoming RREQ-DIOs, the intermediate router maintains a record of the targets that have been requested associated with the RREQ-Instance. Any RREQ-DIO message with different ART Options coming from a router with higher Rank is ignored. It’s not clear to me if the last sentence goes with the previous and if so, how. Does it even relate to multiple targets? Also, different from what? If it has the same ART Options (same as what?) is it *not* ignored? 18. Section 6.3.1: implementation-specific and out of scope. If the implementation selects the symmetric route, and the L bit is not 0, the TargNode MAY delay transmitting the RREP-DIO for duration RREP_WAIT_TIME to await a symmetric route with a lower Rank. The value of RREP_WAIT_TIME is set by default to 1/4 of the time duration determined by the L bit. It’s not an L bit though, it’s an L field. 19. Section 6.3.2: multicast until the OrigNode is reached or MaxRank is exceeded. The TargNode MAY delay transmitting the RREP-DIO for duration RREP_WAIT_TIME to await a route with a lower Rank. The value of RREP_WAIT_TIME is set by default to 1/4 of the time duration determined by the L bit. Again, it’s an L field. Also, what if L is zero? Is RREP_WAIT_TIME set to infinity, as the text implies? Please do a global search for “L bit”, as there are additional instances I haven’t called out. 20. Section 6.4: Step 4: If the receiver is the OrigNode, it can start transmitting the application data to TargNode along the path as provided in RREP- Instance, and processing for the RREP-DIO is complete. Otherwise, in case of an asymmetric route, the intermediate router MUST include the address of the interface receiving the RREP-DIO into the address vector, and then transmit the RREP-DIO via link-local multicast. In case of a symmetric route, the RREP-DIO message is As with #15: on what interface(s)? 21. Section 10: fake AODV-RPL route discoveries. In this type of scenario, RPL's preinstalled mode of operation, where the key to use for a P2P-RPL route discovery is preinstalled, SHOULD be used. What type of scenario is that? 22. Appendix A: s/pakcet/packet/ 23. General remark: Although “acknowledgements” isn’t a required section I was a little surprised not to encounter it, as it’s usually present. Your call of course. From nobody Tue Apr 20 04:22:01 2021 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 D5EC73A1E3E; Tue, 20 Apr 2021 04:21:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-roll-aodv-rpl@ietf.org, roll-chairs@ietf.org, roll@ietf.org, Ines Robles , aretana.ietf@gmail.com, mariainesrobles@googlemail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <161891771644.17807.13402380343710528758@ietfa.amsl.com> Date: Tue, 20 Apr 2021 04:21:56 -0700 Archived-At: Subject: [Roll] Robert Wilton's Discuss on draft-ietf-roll-aodv-rpl-10: (with DISCUSS) 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: Tue, 20 Apr 2021 11:21:57 -0000 Robert Wilton has entered the following ballot position for draft-ietf-roll-aodv-rpl-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-roll-aodv-rpl/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hi, Thank you for your work on this document. I support John's comment that this document could more clearly state its relationship to RPL, which may have a bearing on my discuss comment below. I've balloted discuss on this document because it is not clear to me how this network protocol would be managed. I.e., this document doesn't seem to have any text related to how the protocol is managed, nor does it define a YANG data model, and I cannot see any YANG data models for this protocol currently in the ROLL WG. So, the specific questions that I have are: (1) Are YANG data models and the existing NETCONF/RESTCONF protocols suitable for managing devices running AODV-RPL? (2) Does this protocol build on RPL, and hence would any YANG data models expect to also build on an RPL YANG data model? (3) If the answer to 1 or 2 is yes, then a question for the chairs/ADs: Is there a plan for the ROLL WG to develop a YANG data model for this protocol (and RPL if required)? (4) If the answer to 1 or 2 is no, then what other information can be provided in this document to help implementations create an interoperable management interface for this protocol? For clarity, I'm not saying that a YANG data model needs to be provided before this document can progress, but I would like to understand the path to ensuring that this protocol can be managed, which may require additional text depending on the answers to the questions above. Regards, Rob From nobody Tue Apr 20 04:33:55 2021 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 01B0B3A1EA2 for ; Tue, 20 Apr 2021 04:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 saMjXbGf-zNH for ; Tue, 20 Apr 2021 04:33:50 -0700 (PDT) Received: from mail.mimuw.edu.pl (mail.mimuw.edu.pl [193.0.96.6]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D5F73A1EA1 for ; Tue, 20 Apr 2021 04:33:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by duch.mimuw.edu.pl (Postfix) with ESMTP id 303D8603688B0; Tue, 20 Apr 2021 13:33:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at mimuw.edu.pl Received: from duch.mimuw.edu.pl ([127.0.0.1]) by localhost (mail.mimuw.edu.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id mAlLO4zzUQmu; Tue, 20 Apr 2021 13:33:45 +0200 (CEST) Received: from [IPv6:2001:6a0:5001:2:d17:20fd:68fc:a5a2] (unknown [IPv6:2001:6a0:5001:2:d17:20fd:68fc:a5a2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by duch.mimuw.edu.pl (Postfix) with ESMTPSA; Tue, 20 Apr 2021 13:33:43 +0200 (CEST) From: Konrad Iwanicki To: Routing Over Low power and Lossy networks , Michael Richardson References: <49ac5fc3-4a3c-fb87-d366-eb7e7cfd60df@mimuw.edu.pl> <18233.1583176305@localhost> <10272666-28c7-ab3e-9ceb-1b8f2bb6e5e5@mimuw.edu.pl> <8372.1617839184@localhost> Message-ID: <8abdccb5-afa1-8ba5-8974-8d8fe5bb96ff@mimuw.edu.pl> Date: Tue, 20 Apr 2021 13:34:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <8372.1617839184@localhost> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Roll] Border router failure detection 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: Tue, 20 Apr 2021 11:33:55 -0000 Hi Michael, Below, you can find my replies to your detailed comments, which I promised in my previous e-mail. > It seems that you might want a term for the LBR's children. > That is, the devices at rank "1", that hear the LBR's DIOs. That would be useful. However, I am really bad at inventing names. Any ideas for a fitting one-word term? Also, if you have better names for the two node roles, they may be worth considering because I am not perfectly satisfied with "sentinel" and "acceptor". > I think that I would move some of section 3.2 further forward in the > document. I think that I need a gentler introduction to CFRCs here, and I > don't really need to know the properties, rather I need a higher-level idea > of things. Since section 4 goes over the operations again, I would leave > it for that spot, and make it a section 4.1. True. Will do that. > Having gone forward and back a bit, I'm still a bit uncertain how nodes > assign themselves a bit... oh, self() in section 4 says "random". > Why not make this a function (hash?) of the short-IPv6 address or something? Hash could work. However, the choice of the random function allows a node to become sentinel, then give up, then become sentinel again, and so on, possibly multiple times. Having a hash based on the short-IPv6 address would allow for only one such transition, unless for instance the node kept an additional counter that was hashed together with the address. > Not every media has ACK frames at the L2 to establish that there are > failures. It might be worth putting the Detecting and the Verifying into > separate sections. Aside from the ANIMA case (which is usually pure ethernet), > there are also situations where there is an ethernet backbone connecting a > few 6LBRs (RFC8929), and your protocol would sensibly run on both the > wireless and the wired side of the 6LBRs. Indeed, RNFD can work with other link layers. L2 ACKs are only given as an example of an event that can be relevant to RNFD. In link-layers without ACKs, results from probing or other relevant events can be used (e.g., medium disconnection event). I tried to keep the example list brief, but perhaps more examples could be given for other underlying technologies? Likewise, I was actually considering separating detection from verification but they are related as the same mechanisms can be used for both purposes. Therefore, ultimately they ended up in a single section. > I also wonder if the RNFD could be included in DAOs (particularly storing > mode ones) sent to the DODAG root. > I know that probably seems senseless: why tell the root that you are > observing it to be dying.... But, it acts as interesting telemetry about > what the nodes are seeing, and might serve as a useful indication of imminent > failure, or some kind of systematic long-cycle pathology. Actually, the RNFD Option can be embedded into any control/data messages for which the DODAG ID and DODAG Version can be inferred unambiguously. In particular, in multi-hop messages, the option could even be updated and acted upon at each hop, which would speed up information propagation. The draft focuses on DIOs and DISs as they are basic messages that are exchanged irrespective of the current DODAG condition and existence of particular paths. Do you think this should be mentioned somewhere? BTW. The root, if alive, sees that it is being observed and what the outcome of this observation is based on its local CFRCs. > Your IANA considerations are how the document will look after IANA has > processed it. Prior to that point, you need to write it as a request. > > Something like: > > IANA is requested to allocate the value TBD1 from the "RPL Control Message > Options" sub-registry of the "Routing Protocol for Low Power and Lossy > Networks (RPL)" registry. > > I like to include the URL of the registry in my request to be really really > clear, and to save everyone else the time to find it. Thanks, I did not know how to formulate this. I will correct the section. > Your security considerations will want to cite RFC7416. > In particular, 7.2.4, and section 7.3.4 and 7.3.5 might be relevant. Thanks for the pointer. I was not aware that such a RPL-oriented document exists. Gathering all major threats and possible counter-measures, which would otherwise had to be picked from various works in the literature, it seems extremely valuable for prospective RPL's adopters. As to the particular sections you mentioned, RNFD essentially relies of DIO and DIS messages. Since these messages are broadcast, sinkhole attacks (7.3.4) are of limited threat (to the RNFD itself): for any two nodes, if there exists any path in the network (comprising L2-induced communication links and non-compromised nodes), then eventually CFRCs from one of the nodes will reach (indirectly, through merging) the other node, irrespective of the sinkholes that may attract routed L3 traffic. Wormhole attacks (7.3.5) in turn would speed up the propagation of CFRC updates, so they actually can help RNFD. Therefore, in my view, the major threats are indeed those already mentioned in the draft, which are referred to as overclaiming/misclaiming in the RFC you pointed at (7.2.4). Looking again at the security section of the RNFD draft, I am leaning toward expanding it a bit. In any case, an advantage of RNFD is that its construction allows for detecting such attacks to some extent and disabling the algorithm if necessary (though under such attacks, RPL would likely have more problems on its own). The preferred means of disabling and enabling the algorithm at runtime is actually one of the issues I would like to discuss with the WG but probably after I have addressed all other issues that you and Pascal have raised (I think Pascal's last e-mail is next). Best regards, -- - Konrad Iwanicki. From nobody Tue Apr 20 07:24:54 2021 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 8F69E3A25D6; Tue, 20 Apr 2021 07:24:49 -0700 (PDT) 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 E5G0cJmpBMtR; Tue, 20 Apr 2021 07:24:45 -0700 (PDT) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 3AB4A3A25D7; Tue, 20 Apr 2021 07:24:44 -0700 (PDT) Received: by mail-ed1-x529.google.com with SMTP id j7so8409577eds.8; Tue, 20 Apr 2021 07:24:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=lZosBAWDrPI/Epx5au+koMEFGPtppIlfSvT3ynjmwQw=; b=Cw6XSdyoaUcyILrIR53m6QPnt8ftUbcNQQSMgk5upqMjULVbIAAngxn2bB/ABdhjLn ZgjtON3ydpp46CSDvzwA6NZNmcRf6rNXXMq1psJJAavEj+BdU10MYjSxVwMC4+e4CRgD xYU/QLNm+QboTtkCaEQ5WF32xbrxmH93t2WGhCB7zOft24CvDMIvYZ6/ViRWNrliGc8p 5qAuagUpD00+nv5d52NvKCvwzRF1/dumRnnAosYPpd1Nir/LpgE69t2aenRlWziJF/SZ 0TQHrm8LA+ecpRwZD7q88M/uc7jKXGFP0wTPpvu84719vZcrZboskB+o2rNrtG3Q+h3X Jjhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=lZosBAWDrPI/Epx5au+koMEFGPtppIlfSvT3ynjmwQw=; b=b1FNjmJ5ZbIoBelGc46ejnu6sp9DmmAQqELhZExHfrf11vTd6TOm6Zt3mZ6HmWteHh Dem0gf3T4z4yFqZUbG/xscBgsoZ9+h5X5pjNyTsrHqyQe+8dXMd5tzPcSvrP8jBDMqvv 45Cc43bELJZ8nIsxaRo5minKXxkGl9Wp4EEvkuyisOWfTjzAfT2ICrxqQg/sW9Uzd0Gj f1fbmS5UbPfEhJUkfSccfLeSTgTAznfuoFhUHUbkgbuhwwydlxjisLanI8JEc2Qh1uVT 87rVmKiJAGqOq73qupZ9R/28msdItOjcejAXuQBtIeQ411B18WOq6kMM7bM/umPvaE3G duBQ== X-Gm-Message-State: AOAM532viLNF3kWkHaGS0+R8/419d5g8t+g+jWNyhuG5VQUEV1C407SB P9XEnON3x/fNCgDcGMlBljVa98UZjPRLFmrV+99EZqQF3shqow== X-Google-Smtp-Source: ABdhPJz+sASy//FGlbq6rbuQcjH1zubIDqmeqvJC3iGzGNuwMna94t+oMEYyco5lqoqsN3fDTPLQZYFD7Ax73NAHYIo= X-Received: by 2002:aa7:dbd3:: with SMTP id v19mr32456136edt.314.1618928677358; Tue, 20 Apr 2021 07:24:37 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 20 Apr 2021 07:24:36 -0700 From: Alvaro Retana In-Reply-To: <161891771644.17807.13402380343710528758@ietfa.amsl.com> References: <161891771644.17807.13402380343710528758@ietfa.amsl.com> MIME-Version: 1.0 Date: Tue, 20 Apr 2021 07:24:36 -0700 Message-ID: To: Robert Wilton Cc: draft-ietf-roll-aodv-rpl@ietf.org, roll@ietf.org, roll-chairs@ietf.org, Ines Robles , The IESG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Roll] Robert Wilton's Discuss on draft-ietf-roll-aodv-rpl-10: (with DISCUSS) 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: Tue, 20 Apr 2021 14:24:50 -0000 On April 20, 2021 at 7:21:57 AM, Robert Wilton wrote: Rob: Hi! =C2=A0Thanks for your review! ... > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- ... > So, the specific questions that I have are: > > (1) Are YANG data models and the existing NETCONF/RESTCONF protocols suit= able > for managing devices running AODV-RPL? > > (2) Does this protocol build on RPL, and hence would any YANG data models > expect to also build on an RPL YANG data model? > > (3) If the answer to 1 or 2 is yes, then a question for the chairs/ADs: I= s > there a plan for the ROLL WG to develop a YANG data model for this protoc= ol > (and RPL if required)? AODV-RPL builds on RPL; it uses a new Mode of Operation (MOP) dedicated to the discovery of p2p routes. =C2=A0Yes, any RPL-specific management should be able to be extended for AODV-RPL. The roll charter specifically mentions the definition of a data model for RPL. =C2=A0The WG has been focused on other work and this item hasn't been a priority yet. Alvaro. From nobody Tue Apr 20 07:55:20 2021 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 5225F3A26F9; Tue, 20 Apr 2021 07:55:15 -0700 (PDT) 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 N92EXeWiu9aq; Tue, 20 Apr 2021 07:55:10 -0700 (PDT) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 27AD13A26F4; Tue, 20 Apr 2021 07:55:10 -0700 (PDT) Received: by mail-ed1-x529.google.com with SMTP id j12so20403771edy.3; Tue, 20 Apr 2021 07:55:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=tthSrAePOHP9zLO2tQvS1409ythwiBM4Li2nXbXMq/c=; b=cNPFQ81pr/tGjdm2ANxQaF9a5eIYpTTl4wL0AbM6CVtRJpYMWAbNjbLRIY38xRrIPb BeNucZww8LjlskdXdUhTWXxPIAX5D+GmG2LK7bVAS2BTT0jKly/A5uTqsDsXQj0h4yN+ Sh28AODjog71E6lNB3eVYRB6FBPvuA6XpxBQzw77AwzxcwRFxgcqZkjWjGwcjr/uL4AW M6UDe49+IlVDK5deMsV12N7YnGCQ2RPrrjQH489Ww/7GL8/S/9pot4P/xOmQZp48Npg/ bXAGQmFu8POFsG0Jld/JOFWV+QFt+pcFEsBiFsZlDUH0hnA+xA0owotfTfTSaCJwKysV /0pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=tthSrAePOHP9zLO2tQvS1409ythwiBM4Li2nXbXMq/c=; b=YbQX5jPm2upWc58y10iYcbKgLTIh2NdLnllaT1UUvWX4ZeRQbteJkma4gv7QkWrCIC 2KbARrNOWWAdcKXtY6oMVklRVlgZScj925Ef9C5WH+p8E3HAxEhBKSVQ9SZux6qAjTsc Zx/HjSHB9UyJvYDU0d+rlnyRmZikD7ZTvV9VIDIcTh9fNYAME+etNnMu4CAEhvMIsqxa qyw/GIBlxhePXVccWS3y0XmZdQuR1mWp2cjb7Nu+nRtlEOWmKZuCkK10h4gkWiQ3YEsZ +3rcmqF0OyxVE2Nwai+hleN4SKmCR8kYgjQ6N2vnWh4d8loZPnhiTAzVV57k6+A5KAoD LrZg== X-Gm-Message-State: AOAM532KBKROIAVvu0Ots66LeNPmCs06FfrdB5wlX2zvaPbdZzrQHfTq 92+hwmiKRzH9u/0bxKMlk+QBKZXE/QKrkHXtxwA= X-Google-Smtp-Source: ABdhPJyGDXuFrPgzZxWNIMp8EVAK0aO4QduKmnAxZbWKaiXCuWQNupBanApFP6D2K5uun4bAeZoAWhi6+RdKPfUeHt8= X-Received: by 2002:aa7:c2c8:: with SMTP id m8mr18823283edp.86.1618930507621; Tue, 20 Apr 2021 07:55:07 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 20 Apr 2021 07:55:06 -0700 From: Alvaro Retana In-Reply-To: <161886431878.23690.10633892549620498188@ietfa.amsl.com> References: <161886431878.23690.10633892549620498188@ietfa.amsl.com> MIME-Version: 1.0 Date: Tue, 20 Apr 2021 07:55:06 -0700 Message-ID: To: John Scudder Cc: draft-ietf-roll-aodv-rpl@ietf.org, roll@ietf.org, roll-chairs@ietf.org, Ines Robles , The IESG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Roll] John Scudder's Discuss on draft-ietf-roll-aodv-rpl-10: (with DISCUSS and COMMENT) 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: Tue, 20 Apr 2021 14:55:16 -0000 On April 19, 2021 at 4:32:03 PM, John Scudder wrote: John: Hi! =C2=A0Thanks for the review! I'm just replying to your DISCUSS -- I will let the authors address the rest of the comments. > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- ... > My chief difficulty with the document is placing it in context. No hints = are > given to the reader as to what the expected network environment is. I thi= nk > it would be almost sufficient to say, for example =E2=80=9Cthe network en= vironment is > assumed to be the same as described in RFC 6550, Section 1=E2=80=9D for e= xample, but > without that hint and without a strong background in ROLL, I found myself > struggling. AODV-RPL is an extension of RPL -- the same types of networks that RPL targets are appropriate for AODV-RPL. =C2=A0The one differentiator is the ability of AODV-RPL to discover p2p routes that may not need to traverse the root (more below). =C2=A0IOW, networks that have significant p2p traffic would benefit the most. > Figures 4 and 5 in particular lead me to believe the expected environment > looks similar to a classic ISP network =E2=80=94 a collection of nodes co= nnected by > point-to-point links. If this isn=E2=80=99t correct (and I bet it=E2=80= =99s not) that may > have led me into incorrect assumptions, which may be reflected in my othe= r > comments below. Now that I look at the figures again, I can see how they might look like a segment of a traditional access-distribution-core network. :-) RPL forms a Destination-Oriented Directed Acyclic Graph (DODAG), which results in a tree-like structure with a Border Router (BR) at the top. In general, instead of access-distribution-core, the whole RPL instance is made up of leaves-transit routers-border router. =C2=A0In some cases the leaves are RPL-aware, but not always. > Further, it=E2=80=99s not stated anywhere whether AODV-RPL is intended to= stand > alone as its own routing protocol, or to be viewed as an extension of RPL= . > In the former case, it seems the document is lacking details that are pre= sent > in RFC 6550. I=E2=80=99m assuming the latter is the case, but a clear sta= tement to > that effect seems indicated. AODV-RPL uses a new Mode of Operation (MOP) dedicated to the discovery of p2p routes. =C2=A0This means that it runs in a separate instance from the "base RPL". =C2=A0Also, it can be used whether or not a "base RPL" instance is used. =C2=A0IOW, it is RPL using MOP 5. Most of what I wrote above, which I hope helps clarify, is in the Introduction (pasted below). =C2=A0I think that the text could have been a little more explicit in tying p2p traffic to AODV-RPL -- everything else seems to be there. =C2=A0Yes, there is a strong assumption that the reader knows RPL. Do you have specific suggestion on what can be added to the Introduction? Thanks! Alvaro. 1. =C2=A0Introduction =C2=A0 =C2=A0RPL (Routing Protocol for Low-Power and Lossy Networks) [RFC65= 50] is =C2=A0 =C2=A0an IPv6 distance vector routing protocol designed to support m= ultiple =C2=A0 =C2=A0traffic flows through a root-based Destination-Oriented Direct= ed =C2=A0 =C2=A0Acyclic Graph (DODAG). =C2=A0Typically, a router does not have= routing =C2=A0 =C2=A0information for most other routers. =C2=A0Consequently, for tr= affic =C2=A0 =C2=A0between routers within the DODAG (i.e., Point-to-Point (P2P) t= raffic) =C2=A0 =C2=A0data packets either have to traverse the root in non-storing m= ode, or =C2=A0 =C2=A0traverse a common ancestor in storing mode. =C2=A0Such P2P tra= ffic is =C2=A0 =C2=A0thereby likely to traverse longer routes and may suffer severe =C2=A0 =C2=A0congestion near the root (for more information see [RFC6997], =C2=A0 =C2=A0[RFC6998]). =C2=A0 =C2=A0The route discovery process in AODV-RPL is modeled on the anal= ogous =C2=A0 =C2=A0procedure specified in AODV [RFC3561]. =C2=A0The on-demand nat= ure of AODV =C2=A0 =C2=A0route discovery is natural for the needs of peer-to-peer routi= ng in =C2=A0 =C2=A0RPL-based LLNs. =C2=A0AODV terminology has been adapted for us= e with AODV- =C2=A0 =C2=A0RPL messages, namely RREQ for Route Request, and RREP for Rout= e =C2=A0 =C2=A0Reply. =C2=A0AODV-RPL currently omits some features compared t= o AODV -- in =C2=A0 =C2=A0particular, flagging Route Errors, blacklisting unidirectional= links, =C2=A0 =C2=A0multihoming, and handling unnumbered interfaces. =C2=A0 =C2=A0AODV-RPL reuses and provides a natural extension to the core R= PL =C2=A0 =C2=A0functionality to support routes with birectional asymmetric li= nks. =C2=A0 =C2=A0It retains RPL's DODAG formation, RPL Instance and the associa= ted =C2=A0 =C2=A0Objective Function (defined in [RFC6551]), trickle timers, and =C2=A0 =C2=A0support for storing and non-storing modes. =C2=A0AODV adds bas= ic messages =C2=A0 =C2=A0RREQ and RREP as part of RPL DIO (DODAG Information Object) co= ntrol =C2=A0 =C2=A0messages, and does not utilize the Destination Advertisement O= bject =C2=A0 =C2=A0(DAO) message of RPL. =C2=A0AODV-RPL specifies a new MOP (Mode= of =C2=A0 =C2=A0Operation) running in a separate instance dedicated to discove= r P2P =C2=A0 =C2=A0routes, which may differ from the point-to-multipoint routes =C2=A0 =C2=A0discoverable by native RPL. =C2=A0AODV-RPL can be operated whe= ther or not =C2=A0 =C2=A0native RPL is running otherwise. From nobody Tue Apr 20 08:09:18 2021 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 464893A276C; Tue, 20 Apr 2021 08:09:12 -0700 (PDT) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=juniper.net header.b=kjrKVWue; dkim=pass (1024-bit key) header.d=juniper.net header.b=Tcx/o6wL 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 agYBLzK8eGXY; Tue, 20 Apr 2021 08:09:06 -0700 (PDT) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D9753A2769; Tue, 20 Apr 2021 08:09:06 -0700 (PDT) Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 13KF7uOC008813; Tue, 20 Apr 2021 08:09:04 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=Tk/OnQeNA+aPwoQIltwtFwr6c14VKO6A7CXRFfd3DfM=; b=kjrKVWueMJn9WZ0GKCrEqtexV4Lz18+kPI8ovMM7bs1U4HcK23m3HAx/WabCNECBcDnG rYD7pTANHhsbUHcNu4XjO5BVUSY0Oi2w/qIsIFqB2IZ8EGGMIUr0RjOEp6p4enCsx/Qj 1A97sNTcZ9xVWvPKVhYqzqaDT/IRVtxfuPQd+jIFSSElPe1VrqImqQ7JtXo97n0wVq19 vEcU/x95x/9cSgRoTiKc66GV+qKxlP73WPS62Hd0isqt0CDPSulQJx3GsApdf3eR746+ bcl7BqO60XOFmlMeUDCGOlQDSNvRuxJ6gcWS+BHoj+BviK0z0dS8ZKrslkU0MWwEuocW 7Q== Received: from nam11-bn8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2171.outbound.protection.outlook.com [104.47.58.171]) by mx0a-00273201.pphosted.com with ESMTP id 381exe1urb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 20 Apr 2021 08:09:03 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HfgyfBfcHxKXFPH9F89s2PQ63n6A45WVns/JDBEeZ3Lzt/4j18F4fwekcSA31vJkzaVr1JsDBVNaDb3up0XQu3mQxnjbd3j1EWcRJjT2jAZpQe1qvpQl/pZlO0RwzwbSrk6jdq+2JaUiWhCsPFIC2V/vlfsKJ1yl3bjL4s7EuhdDpAW5FpJUk4t7Z9UPt06fMg5eNHhp6T6ol5hraEf0aPsaMs5Nddp4UIZDisxmIjFJU1x04STZWNVFK64uH5vjDPZSwEOt1AUeOcrcJJxipblUcgDfVzDovdmhOEX0PZKIoQilRJ2BFQLeNcudWF9W2q8OfTofQCaB/kJQtgZWjw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Tk/OnQeNA+aPwoQIltwtFwr6c14VKO6A7CXRFfd3DfM=; b=myLyLKLYVCgVtCQWKEF6HANWBlYhU+ZcekT3ovLQzm2CvrERE7FGGuhzE3qEC9wjf7ago1MPk1zly+AAljnEOKqHXKpsZgnnl+mmQD0wv7d4W4IvtNZMlH6aEHlJuFJg+zJyt1s8qRe63sXZRvZeqsOWuv8qOja6Ci7dIgwuS5nT2tWwzETMRti9fD+eQ0Pu6vvUt/x1knmeBkXu/ODuBTaVzvlRpWN06503WT0o8gU6R0k2qnVT8du9YHcgwmnKi2KW7Y8xnu2P6nNbVaDlfbaMZskGWmMbVofyKULm33FTeAVFX0N4RNhabS9iP3J+z0R1MpI/mqpjpio7FoPNWA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Tk/OnQeNA+aPwoQIltwtFwr6c14VKO6A7CXRFfd3DfM=; b=Tcx/o6wLjtMtm4uDTpXeo+Bnmump1dXOo8o3XFL3O1YfaohAcLQ8JHNaTPvmX/21rFrHK8SRGSJPlDrlE13SEWPe8daPvUu+xs1IHrzddDaLV90WmNgeFr1nfBiUmmBozIWXCV1rIRbx5IJyMa2VLsVOmmpFsEoiTTkOEItpabw= Received: from MN2PR05MB6109.namprd05.prod.outlook.com (2603:10b6:208:c4::20) by BLAPR05MB7299.namprd05.prod.outlook.com (2603:10b6:208:29a::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.6; Tue, 20 Apr 2021 15:09:01 +0000 Received: from MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::3020:ac3:590d:83f1]) by MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::3020:ac3:590d:83f1%5]) with mapi id 15.20.4065.019; Tue, 20 Apr 2021 15:09:01 +0000 From: John Scudder To: Alvaro Retana CC: "draft-ietf-roll-aodv-rpl@ietf.org" , "roll@ietf.org" , "roll-chairs@ietf.org" , Ines Robles , The IESG Thread-Topic: John Scudder's Discuss on draft-ietf-roll-aodv-rpl-10: (with DISCUSS and COMMENT) Thread-Index: AQHXNVsZVxHxg8VYVkSdat85+ymoxKq9f5YAgAAD5IA= Date: Tue, 20 Apr 2021 15:09:01 +0000 Message-ID: <1877C29A-5991-4D8A-9230-04697ECAB0CA@juniper.net> References: <161886431878.23690.10633892549620498188@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.120.23.2.4) authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [162.225.191.192] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 42d9c4ca-8a94-4ff9-f266-08d9040e3b21 x-ms-traffictypediagnostic: BLAPR05MB7299: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: uwHwQ89DLhqZY8F8YYow42ptmAkOBDw2idZB7ZB3UM9m3ksUBiXHcfmkz7Tv6eHJDpMeX2s3+lLxuF6DiKhHc8ux1oiDwWbgtZTkAobBxaQPo1mzv+bxhkJXMB6AjCI1CoxA1e1d+2VTvuHG4UoI3HFb7k7LocsbO/Z9uO4sNdJkhfgtbm63lstbj0Fc2lSyANJGToDDLeoURHwAZg+52NGRPO8eL48z2n8QbQ8Q6+KB28P9BHrytVdQK3pRE7bD6TuVVvbU/AFrqhDEMSQiMsjdb/xCwx90jj++2wYLWe3edyXQLKO+ZUHV1q1SiyQkNnOhU96pf0dVUVCQhcjDdI1pxpSiIdz+KzWGLXxYBTOaH4Ia4FDNNxOJpFi+bT6FYZVNbdm/VTt5lxNwYdQaJtvLZg6cEFzUPfsZeqrLXqSmEFDCxt5goHsLz38DI+Pa5ATaeNN18uuL1aupdDpUFA6CPY9MqS8yqMRB449NAWbVq+lRHsa4tqlb1ozJDq2bXs8S56/J28a/EYVo31dLp7VwszklE97QkvsX3uYwO75Fx7q/NyrJ8nHBT7m9JJYDqEy49nMfTlnzNZ77eazPcV25yr0pgJRIsipPOWdQ38s1kjFHHx1FruBTuNMcUEgMEymWUFhdaXOKhMe/Zrh2Fv5klP5VEtFF/y7HwxFrKUc= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR05MB6109.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(346002)(39850400004)(396003)(366004)(376002)(64756008)(76116006)(91956017)(6486002)(6512007)(33656002)(122000001)(2616005)(66446008)(8676002)(6506007)(6916009)(26005)(8936002)(66476007)(66556008)(36756003)(66946007)(478600001)(53546011)(4326008)(186003)(54906003)(38100700002)(5660300002)(2906002)(316002)(71200400001)(86362001)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?YzBkQ0FSSHNOMzVhYm8vb3Z2RFFpQkI4UTMyc3ZNZlZSMzAxNGlhSDlQQWFy?= =?utf-8?B?bEZ6dllYbWZVaUUzQ2V3MDZDRVpxRm1zRWZMdHZ6cXRuY0ZrTjQ5dlBpRkxL?= =?utf-8?B?Y0taeVpNTzVUNU9qUUltR0dFamlLVC9JUmlXS0U4bk4zbDlDUGExZUdMTGJx?= =?utf-8?B?SmpBOGZIMWM1SzY5Z3I0WEVCTkxKVnIxZ0F0eVJuVTlheDhtOVRkYzN6bGdN?= =?utf-8?B?RjVDS2ZIWVIxVWNHaTRiWUprUkc4SzFudUNwaVJBM3ZWRW12OUFibHFNa2ZI?= =?utf-8?B?SlA4MnVxdnhOempqSXNSbW5hNHR5Wk5xUWdDWUlsTEdXZ21LYlJtUEN1cTEv?= =?utf-8?B?UklsdWQ5bWhFZHhJVGd4aE9ON085cnhQTjUvK2pSWGw4d0RMUGhLTFNiRmJB?= =?utf-8?B?dWZjZURxV3RxN2p2WWNoOEN2M2w1UkZiRFBURXdwem9WZ3Z3a1MrcEM0Szlp?= =?utf-8?B?cnIzRitQTXpiTXBpeGhOUXJHdk95OTc4K1pwQUp1eWtHakZTaElSSjdkaHZ4?= =?utf-8?B?cFY0eUo2QVpsWklBenhCZmR4ZjBPbm1mSGN4TWVNUFZ6ckVNcE1SakdPeGtm?= =?utf-8?B?ZnlldlA5UnlEdVFZRWYvQ09mbFJoc3gwRlVlSUhHUnliVkR6VStWY25OYmFi?= =?utf-8?B?Uy9reFR1bWJzVmwxcE4rSFZTOVYrMG1Ta2hXM3grVTNaL0xzZHEyMkxKUTVx?= =?utf-8?B?OU5vcDNGQ1l1RDFWSFYxcWQrNjE1emdGcFhLZGVUNE9kSHNQS0tOU1VwL2pR?= =?utf-8?B?TjBDcThQdVBncmx4TzdueFZCTUx5YWgzREV3eFZsMUpVVjIzaktMSm5Ya3BE?= =?utf-8?B?NDQrYVBRTDYwMVdaTE4ybFRzejdLVWZmMHk5WmM3SXpBNnpvUGlYRS9BOExB?= =?utf-8?B?MW1DTjMvR1RQT0ZhVkZkdGNmeEt1TXlDdmM0WXphTDhOMWhwUTU4WGp1S3Br?= =?utf-8?B?dVJ4RmZmRDI3YjBrS0lpQ3ZaSGJUVksvc0pzNWFQRkNVZk1SYmhlMWZ3a3Rt?= =?utf-8?B?K3g4QVZEdXRHVWRkM203ZmpJZklyTGZwZ2xEVW5iRGhzZWg4RGI1QmZBcjQ5?= =?utf-8?B?Q0pYNi9pTEdJUkNqVUcvTnhFLzkwUkJZcFhJS2tWM1UrYWdQSkRFT0xUa0ZD?= =?utf-8?B?SjhJRlY0elhrUDNaSlI1ZUJXTHhTaHd1MG5LRHFSMnBZNkpCMVNxSXIxMXR3?= =?utf-8?B?cjdydC9lVE1mUjVzZE1VcGlGU2NyeUJYZTYwMy9INjROWWxQVEk3NVFpeENt?= =?utf-8?B?L2FQWUF4b09tbGZlU01RNy94REpNTGdNU25UaGg4TEZXM1BuNGtrSGdTNzRV?= =?utf-8?B?bWdXN1lOWGFmeTZwYVF2d0QyY2RwQ21ZWHFWM2FYQTRvbHdJN3FObnRrbUc4?= =?utf-8?B?aGc3N2hSQW03QTJWWEdCdXpoQ1NrZjZxaVNkVEVENWxxT1d0Q0UyYjFJaVVN?= =?utf-8?B?dksrWEZGV3FuZVNNa3FhV3h2SGVqdnZmV2E0VktSZER2eGVaYmM4OGRtRDJ5?= =?utf-8?B?VVV6UmhsamJlamt0bTgwQ0Ixb1F6dzQyOGY2b0wwZkRkcFFtMUNHK1J0T1I4?= =?utf-8?B?c2JKdEFaUUc5dk1xWnJidjZBMS9nZStvNm8rdjUxTXlydFd6ZWdDUU9xUHNR?= =?utf-8?B?M2tNSnUyRkgxaVU4ditvNFc1bTI5end2NGtRc1N2TlVlQklpUE5SRWwzR2Vi?= =?utf-8?B?OGtLYkZnTWQ0OW5kZE4yUU9GWCtpUDFMNnMwbVhSZkU1WmpINWtKQ0U2UDNa?= =?utf-8?B?OEtWQTJrUWV3eEhiRFgzbjQrQlIyTTFYQ29sRExwclFlaXVOMmN4di8zd2Ur?= =?utf-8?B?aHJoOTcrL21uRFNJWnJiUT09?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_1877C29A59914D8A923004697ECAB0CAjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR05MB6109.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 42d9c4ca-8a94-4ff9-f266-08d9040e3b21 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2021 15:09:01.6330 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: uofCN6T6XKwC6+YD9vY26BWRbiwQpa931e0nxtFvfNlWlM6X8WrXWh7kfqZWdQbU X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR05MB7299 X-Proofpoint-GUID: eq97HQN4DHMJ_I2zhre5dWl8SkG5PH11 X-Proofpoint-ORIG-GUID: eq97HQN4DHMJ_I2zhre5dWl8SkG5PH11 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-04-20_07:2021-04-20, 2021-04-20 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=1 malwarescore=0 clxscore=1011 impostorscore=0 spamscore=1 lowpriorityscore=0 phishscore=0 mlxscore=1 adultscore=0 suspectscore=0 bulkscore=0 mlxlogscore=196 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000 definitions=main-2104200113 Archived-At: Subject: Re: [Roll] John Scudder's Discuss on draft-ietf-roll-aodv-rpl-10: (with DISCUSS and COMMENT) 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: Tue, 20 Apr 2021 15:09:12 -0000 --_000_1877C29A59914D8A923004697ECAB0CAjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWx2YXJvLA0KDQpJIGhhdmUgb25lIHBhcnRpYWwgcmVwbHkgYmVsb3csIGJ1dCBJIHRoaW5r IHdlIG1pZ2h0IGJlbmVmaXQgZnJvbSBhIHNob3J0IHBob25lIGNhbGwuIEnigJlsbCB1bmljYXN0 IHlvdSBzb21lIHRpbWVzIHRoYXQgd291bGQgd29yayBmb3IgbWUuDQoNCk9uIEFwciAyMCwgMjAy MSwgYXQgMTA6NTUgQU0sIEFsdmFybyBSZXRhbmEgPGFyZXRhbmEuaWV0ZkBnbWFpbC5jb208bWFp bHRvOmFyZXRhbmEuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCi4uLg0KRnVydGhlciwgaXTigJlz IG5vdCBzdGF0ZWQgYW55d2hlcmUgd2hldGhlciBBT0RWLVJQTCBpcyBpbnRlbmRlZCB0byBzdGFu ZA0KYWxvbmUgYXMgaXRzIG93biByb3V0aW5nIHByb3RvY29sLCBvciB0byBiZSB2aWV3ZWQgYXMg YW4gZXh0ZW5zaW9uIG9mIFJQTC4NCkluIHRoZSBmb3JtZXIgY2FzZSwgaXQgc2VlbXMgdGhlIGRv Y3VtZW50IGlzIGxhY2tpbmcgZGV0YWlscyB0aGF0IGFyZSBwcmVzZW50DQppbiBSRkMgNjU1MC4g SeKAmW0gYXNzdW1pbmcgdGhlIGxhdHRlciBpcyB0aGUgY2FzZSwgYnV0IGEgY2xlYXIgc3RhdGVt ZW50IHRvDQp0aGF0IGVmZmVjdCBzZWVtcyBpbmRpY2F0ZWQuDQoNCkFPRFYtUlBMIHVzZXMgYSBu ZXcgTW9kZSBvZiBPcGVyYXRpb24gKE1PUCkgZGVkaWNhdGVkIHRvIHRoZSBkaXNjb3ZlcnkNCm9m IHAycCByb3V0ZXMuICBUaGlzIG1lYW5zIHRoYXQgaXQgcnVucyBpbiBhIHNlcGFyYXRlIGluc3Rh bmNlIGZyb20NCnRoZSAiYmFzZSBSUEwiLiAgQWxzbywgaXQgY2FuIGJlIHVzZWQgd2hldGhlciBv ciBub3QgYSAiYmFzZSBSUEwiDQppbnN0YW5jZSBpcyB1c2VkLiAgSU9XLCBpdCBpcyBSUEwgdXNp bmcgTU9QIDUuDQoNClRoaXMgZG9lc27igJl0IHJlYWxseSBjbGVhciB1cCBteSBjb25jZXJuLCB3 aGljaCBJIGNhbiByZXBocmFzZSB0aGlzIHdheTogSeKAmW0gcHJldHR5IHN1cmUgQU9EVi1SUEws IHN0YW5kaW5nIGFsb25lLCBpc27igJl0IGFuIGltcGxlbWVudGFibGUgc3BlY2lmaWNhdGlvbi4g SWYgaXQgYXNzdW1lcyB0aGF0IGFsbCB0aGUgcHJvdG9jb2wgbWFjaGluZXJ5IG9mIFJGQyA2NTUw IGlzIHByZXNlbnQsIHRoZW4gSeKAmW0gd2lsbGluZyB0byBhY2NlcHQgb24gZmFpdGggdGhhdCB0 aGUgZ2FwcyBhcmUgZmlsbGVkIHRoYXQgd2F5LCBidXQgdGhpcyBuZWVkcyB0byBiZSBzYWlkLiBJ ZiBpdCBkb2VzbuKAmXQgYXNzdW1lIHRoYXQgYWxsIG9mIFJGQyA2NTUwIGlzIHByZXNlbnQsIHRo ZW4gSSB0aGluayBpdCBzaG91bGQgY2FsbCBvdXQgYnkgcmVmZXJlbmNlIHdoYXQgdGhlIHJlcXVp cmVkIHBhcnRzIGFyZS4NCg0KSSBoYXZlbuKAmXQgdHJpZWQgdG8gZ28gdGhyb3VnaCB0aGUgZG9j dW1lbnQgYW5kIHNheSDigJx0aGlzIGlzbuKAmXQgaW1wbGVtZW50YWJsZSBiZWNhdXNlIHlvdSBs ZWZ0IG91dCB0aGlzLCBhbmQgdGhhdCwgYW5kIHNvIG9u4oCdIGJlY2F1c2Ugc28gZmFyIG15IGd1 ZXNzIGlzIGl04oCZcyBhc3N1bWVkIHRoYXQgdGhlIGVudGlyZSBiYXNlIG9mIFJGQyA2NTUwIGlz IGF2YWlsYWJsZSwgc28gaXQgd291bGRu4oCZdCBiZSBhIGdvb2QgdXNlIG9mIGFueW9uZeKAmXMg dGltZSB0byBwcm9kdWNlIHRoYXQga2luZCBvZiByZXZpZXcuDQoNCuKAlEpvaG4NCg== --_000_1877C29A59914D8A923004697ECAB0CAjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkhpIEFsdmFybywNCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkgaGF2ZSBvbmUgcGFydGlhbCByZXBs eSBiZWxvdywgYnV0IEkgdGhpbmsgd2UgbWlnaHQgYmVuZWZpdCBmcm9tIGEgc2hvcnQgcGhvbmUg Y2FsbC4gSeKAmWxsIHVuaWNhc3QgeW91IHNvbWUgdGltZXMgdGhhdCB3b3VsZCB3b3JrIGZvciBt ZS48YnIgY2xhc3M9IiI+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBBcHIgMjAsIDIwMjEsIGF0IDEwOjU1IEFN LCBBbHZhcm8gUmV0YW5hICZsdDs8YSBocmVmPSJtYWlsdG86YXJldGFuYS5pZXRmQGdtYWlsLmNv bSIgY2xhc3M9IiI+YXJldGFuYS5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KLi4uPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPkZ1cnRoZXIsIGl04oCZcyBub3Qgc3RhdGVkIGFueXdoZXJlIHdo ZXRoZXIgQU9EVi1SUEwgaXMgaW50ZW5kZWQgdG8gc3RhbmQ8YnIgY2xhc3M9IiI+DQphbG9uZSBh cyBpdHMgb3duIHJvdXRpbmcgcHJvdG9jb2wsIG9yIHRvIGJlIHZpZXdlZCBhcyBhbiBleHRlbnNp b24gb2YgUlBMLjxiciBjbGFzcz0iIj4NCkluIHRoZSBmb3JtZXIgY2FzZSwgaXQgc2VlbXMgdGhl IGRvY3VtZW50IGlzIGxhY2tpbmcgZGV0YWlscyB0aGF0IGFyZSBwcmVzZW50PGJyIGNsYXNzPSIi Pg0KaW4gUkZDIDY1NTAuIEnigJltIGFzc3VtaW5nIHRoZSBsYXR0ZXIgaXMgdGhlIGNhc2UsIGJ1 dCBhIGNsZWFyIHN0YXRlbWVudCB0bzxiciBjbGFzcz0iIj4NCnRoYXQgZWZmZWN0IHNlZW1zIGlu ZGljYXRlZC48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpBT0RW LVJQTCB1c2VzIGEgbmV3IE1vZGUgb2YgT3BlcmF0aW9uIChNT1ApIGRlZGljYXRlZCB0byB0aGUg ZGlzY292ZXJ5PGJyIGNsYXNzPSIiPg0Kb2YgcDJwIHJvdXRlcy4gJm5ic3A7VGhpcyBtZWFucyB0 aGF0IGl0IHJ1bnMgaW4gYSBzZXBhcmF0ZSBpbnN0YW5jZSBmcm9tPGJyIGNsYXNzPSIiPg0KdGhl ICZxdW90O2Jhc2UgUlBMJnF1b3Q7LiAmbmJzcDtBbHNvLCBpdCBjYW4gYmUgdXNlZCB3aGV0aGVy IG9yIG5vdCBhICZxdW90O2Jhc2UgUlBMJnF1b3Q7PGJyIGNsYXNzPSIiPg0KaW5zdGFuY2UgaXMg dXNlZC4gJm5ic3A7SU9XLCBpdCBpcyBSUEwgdXNpbmcgTU9QIDUuPGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPlRoaXMgZG9lc27igJl0IHJlYWxseSBjbGVhciB1cCBteSBjb25jZXJu LCB3aGljaCBJIGNhbiByZXBocmFzZSB0aGlzIHdheTogSeKAmW0gcHJldHR5IHN1cmUgQU9EVi1S UEwsIHN0YW5kaW5nIGFsb25lLCBpc27igJl0IGFuIGltcGxlbWVudGFibGUgc3BlY2lmaWNhdGlv bi4gSWYgaXQgYXNzdW1lcyB0aGF0IGFsbCB0aGUgcHJvdG9jb2wgbWFjaGluZXJ5IG9mIFJGQyA2 NTUwIGlzIHByZXNlbnQsIHRoZW4gSeKAmW0gd2lsbGluZyB0byBhY2NlcHQNCiBvbiBmYWl0aCB0 aGF0IHRoZSBnYXBzIGFyZSBmaWxsZWQgdGhhdCB3YXksIGJ1dCB0aGlzIG5lZWRzIHRvIGJlIHNh aWQuIElmIGl0IDxpIGNsYXNzPSIiPg0KZG9lc27igJl0PC9pPjxzcGFuIHN0eWxlPSJmb250LXN0 eWxlOiBub3JtYWw7IiBjbGFzcz0iIj4mbmJzcDthc3N1bWUgdGhhdCBhbGwgb2YgUkZDIDY1NTAg aXMgcHJlc2VudCwgdGhlbiBJIHRoaW5rIGl0IHNob3VsZCBjYWxsIG91dCBieSByZWZlcmVuY2Ug d2hhdCB0aGUgcmVxdWlyZWQgcGFydHMgYXJlLjwvc3Bhbj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PHNwYW4gc3R5bGU9ImZvbnQtc3R5bGU6IG5vcm1hbDsiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N Cjwvc3Bhbj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SSBoYXZlbuKAmXQgdHJpZWQgdG8gZ28gdGhy b3VnaCB0aGUgZG9jdW1lbnQgYW5kIHNheSDigJx0aGlzIGlzbuKAmXQgaW1wbGVtZW50YWJsZSBi ZWNhdXNlIHlvdSBsZWZ0IG91dCB0aGlzLCBhbmQgdGhhdCwgYW5kIHNvIG9u4oCdIGJlY2F1c2Ug c28gZmFyIG15IGd1ZXNzIGlzIGl04oCZcyBhc3N1bWVkIHRoYXQgdGhlIGVudGlyZSBiYXNlIG9m IFJGQyA2NTUwIGlzIGF2YWlsYWJsZSwgc28gaXQgd291bGRu4oCZdCBiZSBhIGdvb2QgdXNlIG9m DQogYW55b25l4oCZcyB0aW1lIHRvIHByb2R1Y2UgdGhhdCBraW5kIG9mIHJldmlldy48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPuKAlEpv aG48L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_1877C29A59914D8A923004697ECAB0CAjunipernet_-- From nobody Tue Apr 20 08:23:34 2021 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 7CA893A27EA; Tue, 20 Apr 2021 08:23:33 -0700 (PDT) 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, 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=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 ew9m4XYi0Wff; Tue, 20 Apr 2021 08:23:28 -0700 (PDT) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 52D123A27E7; Tue, 20 Apr 2021 08:23:28 -0700 (PDT) Received: by mail-ed1-x52d.google.com with SMTP id bx20so44442239edb.12; Tue, 20 Apr 2021 08:23:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=EDbkQevjGbJzAaqgNuAqpXrhPH4MemCy03ZoM9/5+ZQ=; b=kEF9slFyUeGQv24IS34I81YuvX9GO97Ka4omy/Y4GoR+T59ChDQvsOTj07D1QV8Fex BVaW81nmxYDr6TfC4UdH96lNTDyE+Ke79l0fXIfPCsz3PDDvTY/IFK3IUuwtVdim/fcY DklB0SCAAWJeciKfbztd1nRvFGhKwVbfu0xZoTgvQCPyi20AXAg8JiLQrsDRxLzf0tRG U59b0DYrUQwl9DxUGPuGN0uxGMr4lz0xPSCo34IDtHZ03oY752WtmbPdgEl0Gy92UoLg ta14DgdYpElKoFjzFVTAYhF5WMOjhcXE3ttfFrKY/sBIU1GFdfR9LGv5b9c+vBdHBfHu k4nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=EDbkQevjGbJzAaqgNuAqpXrhPH4MemCy03ZoM9/5+ZQ=; b=VEDhx5DJNTZ0C4hkIPKrnLQ+6Aba1Fzg5Ad/YhTSuv0EI7JEHZ74XAfnFEy2K+eVsS 9vOXzhNTZ3tU9iTQ7VsaaI+HFvOxRCSPAvcywF0z8Xwj/R2na7ff7ewnapWsIOhbPwWN TSZn0NKNJq6ZV6U97knGWnBkbDl8gt70TjELP5nrTRFryXDZyJyOjpasc4m86faOzqKR VS9bUdnlLGAkUUA/24Vb6VDhCozr32AnvBs0qnpnb5uyO14pFwP01gWSEHTPXjJOEKsL UC3IGYYN3G5ZdUcf3f4JNdJLzbgBAH1lstZcd7DlwOUcfDRMOllyDNj+lAJ72vqOoCTO 6JDA== X-Gm-Message-State: AOAM533t3oXf6kaim45eBRPdaJEdvu5UsAevHfwKuPLTsBS31ov0g2Ag 5TyMYuutXftvDw1ghjyaUm+IwRWOzLpg/+vAdfWdLjnpqVl5bA== X-Google-Smtp-Source: ABdhPJwmwFHaDoVhfG8tWQ06oP6pprxT627QCjwctTLhhZ3D/VKHdRSoIwOzhf0MxrZRWFj4fwIn/zSN81Zr2lpRZak= X-Received: by 2002:aa7:c1c9:: with SMTP id d9mr32686027edp.155.1618932205958; Tue, 20 Apr 2021 08:23:25 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 20 Apr 2021 08:23:25 -0700 From: Alvaro Retana In-Reply-To: <1877C29A-5991-4D8A-9230-04697ECAB0CA@juniper.net> References: <161886431878.23690.10633892549620498188@ietfa.amsl.com> <1877C29A-5991-4D8A-9230-04697ECAB0CA@juniper.net> MIME-Version: 1.0 Date: Tue, 20 Apr 2021 08:23:25 -0700 Message-ID: To: John Scudder Cc: "draft-ietf-roll-aodv-rpl@ietf.org" , "roll@ietf.org" , "roll-chairs@ietf.org" , The IESG , Ines Robles Content-Type: multipart/alternative; boundary="0000000000000d396d05c0690729" Archived-At: Subject: Re: [Roll] John Scudder's Discuss on draft-ietf-roll-aodv-rpl-10: (with DISCUSS and COMMENT) 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: Tue, 20 Apr 2021 15:23:34 -0000 --0000000000000d396d05c0690729 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ACK. (For the record) On April 20, 2021 at 11:09:05 AM, John Scudder (jgs@juniper.net) wrote: Hi Alvaro, I have one partial reply below, but I think we might benefit from a short phone call. I=E2=80=99ll unicast you some times that would work for me. On Apr 20, 2021, at 10:55 AM, Alvaro Retana wrote: ... Further, it=E2=80=99s not stated anywhere whether AODV-RPL is intended to s= tand alone as its own routing protocol, or to be viewed as an extension of RPL. In the former case, it seems the document is lacking details that are present in RFC 6550. I=E2=80=99m assuming the latter is the case, but a clear state= ment to that effect seems indicated. AODV-RPL uses a new Mode of Operation (MOP) dedicated to the discovery of p2p routes. This means that it runs in a separate instance from the "base RPL". Also, it can be used whether or not a "base RPL" instance is used. IOW, it is RPL using MOP 5. This doesn=E2=80=99t really clear up my concern, which I can rephrase this = way: I=E2=80=99m pretty sure AODV-RPL, standing alone, isn=E2=80=99t an implementable specif= ication. If it assumes that all the protocol machinery of RFC 6550 is present, then I=E2=80=99m willing to accept on faith that the gaps are filled that way, b= ut this needs to be said. If it * doesn=E2=80=99t* assume that all of RFC 6550 is p= resent, then I think it should call out by reference what the required parts are. I haven=E2=80=99t tried to go through the document and say =E2=80=9Cthis is= n=E2=80=99t implementable because you left out this, and that, and so on=E2=80=9D becau= se so far my guess is it=E2=80=99s assumed that the entire base of RFC 6550 is av= ailable, so it wouldn=E2=80=99t be a good use of anyone=E2=80=99s time to produce th= at kind of review. =E2=80=94John --0000000000000d396d05c0690729 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
ACK.= (For the record)

<= br>

On April 20, 2021 at 11:09:05 AM, Joh= n Scudder (jgs@juniper.net) wrote:

=
Hi Alvaro,

I have one partial reply below, but I think we might benefi= t from a short phone call. I=E2=80=99ll unicast you some times that would w= ork for me.

On Apr 20, 2021, at 10:55 AM, Alvaro Retana <aretana.ietf@gmail.com> wr= ote:
...
Further, it=E2=80=99s not stated anywh= ere whether AODV-RPL is intended to stand
alone as its own routing protocol, or to be viewed as an extension of RPL.<= br class=3D""> In the former case, it seems the document is lacking details that are prese= nt
in RFC 6550. I=E2=80=99m assuming the latter is the case, but a clear state= ment to
that effect seems indicated.

AODV-RPL uses a new Mode of Operation (MOP) dedicated to the discovery
of p2p routes.=C2=A0 This means that it runs in a separate instance from the "base RPL".=C2=A0 Also, it can be used whether or not a "= ;base RPL"
instance is used.=C2=A0 IOW, it is RPL using MOP 5.

This doesn=E2=80=99t really clear up my concern, which I ca= n rephrase this way: I=E2=80=99m pretty sure AODV-RPL, standing alone, isn= =E2=80=99t an implementable specification. If it assumes that all the proto= col machinery of RFC 6550 is present, then I=E2=80=99m willing to accept on faith that the gaps are filled that way, but this needs to be said. If = it doesn=E2=80=99t=C2=A0assum= e that all of RFC 6550 is present, then I think it should call out by refer= ence what the required parts are.

I haven=E2=80=99t tried to go through the document and say = =E2=80=9Cthis isn=E2=80=99t implementable because you left out this, and th= at, and so on=E2=80=9D because so far my guess is it=E2=80=99s assumed that= the entire base of RFC 6550 is available, so it wouldn=E2=80=99t be a good= use of anyone=E2=80=99s time to produce that kind of review.

=E2=80=94John
--0000000000000d396d05c0690729-- From nobody Tue Apr 20 15:03:59 2021 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 B2AE53A1F1F; Tue, 20 Apr 2021 15:03:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari via Datatracker To: "The IESG" Cc: draft-ietf-roll-aodv-rpl@ietf.org, roll-chairs@ietf.org, roll@ietf.org, Ines Robles , aretana.ietf@gmail.com, mariainesrobles@googlemail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Warren Kumari Message-ID: <161895622802.25938.15008636103702222386@ietfa.amsl.com> Date: Tue, 20 Apr 2021 15:03:48 -0700 Archived-At: Subject: [Roll] Warren Kumari's No Objection on draft-ietf-roll-aodv-rpl-10: (with COMMENT) 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: Tue, 20 Apr 2021 22:03:55 -0000 Warren Kumari has entered the following ballot position for draft-ietf-roll-aodv-rpl-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-roll-aodv-rpl/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Firstly, thank you for writing this - I'm really not a ROLL person, but I found it interesting... I support John and Rob's DISCUSSes, but I'll let them carry the heavy load :-) I have a few nits: Section 4.3: 'r A one-bit reserved field. This field MUST be initialized to zero by the sender and MUST be ignored by the receiver.' I could find no 'r' in Figure 3 - did you mean 'X'? Section 6.2.1, Step 1: 'If the S bit in the received RREQ-DIO is set to 0, the router MUST determine into the upward direction (towards the OrigNode) of the link.' I was unable to parse this. More worryingly, I was also not able to figure out what it should say... Section 6.3.1: 'default to 1/4 of the time duration determined by the L bit.' - s/L bit/L value'. This says that the default of 1/4 of the time duration, but I didn't see where /why the default would change. Also, isn't 'time' in 'time duration' unnecessary? Duration implies time. Appendix A: 'The combination of Received Signal Strength Indication(downstream) (RSSI) and Expected Number of Transmissions(upstream)" (ETX) ' -- this is a random closing quote without an opening one. From nobody Wed Apr 21 01:38:17 2021 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 64BBC3A1B6E for ; Wed, 21 Apr 2021 01:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 EBMylZ_NJ5Ez for ; Wed, 21 Apr 2021 01:38:11 -0700 (PDT) Received: from mail.mimuw.edu.pl (mail.mimuw.edu.pl [193.0.96.6]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CF653A1B6B for ; Wed, 21 Apr 2021 01:38:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by duch.mimuw.edu.pl (Postfix) with ESMTP id 714406036AA1F; Wed, 21 Apr 2021 10:38:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at mimuw.edu.pl Received: from duch.mimuw.edu.pl ([127.0.0.1]) by localhost (mail.mimuw.edu.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id xHUaJbywv20r; Wed, 21 Apr 2021 10:38:00 +0200 (CEST) Received: from [IPv6:2001:6a0:5001:2:e859:37e0:88bf:b374] (unknown [IPv6:2001:6a0:5001:2:e859:37e0:88bf:b374]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by duch.mimuw.edu.pl (Postfix) with ESMTPSA; Wed, 21 Apr 2021 10:37:58 +0200 (CEST) From: Konrad Iwanicki To: Routing Over Low power and Lossy networks , "Pascal Thubert (pthubert)" References: <49ac5fc3-4a3c-fb87-d366-eb7e7cfd60df@mimuw.edu.pl> <18233.1583176305@localhost> <10272666-28c7-ab3e-9ceb-1b8f2bb6e5e5@mimuw.edu.pl> Message-ID: Date: Wed, 21 Apr 2021 10:39:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Roll] Border router failure detection 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, 21 Apr 2021 08:38:15 -0000 Hi Pascal, Thanks for reading the draft in such a great depth! A short answer to your questions: sentinel selection and other issues you mention are very much dependent on a particular deployment (i.e., network topology, application, other technologies used with RPL); RNFD thus focuses on providing mechanism for enforcing deployment-specific policies in that matter, including possibilities for dynamically changing the policies at runtime. A much longer answer follows. On 14/04/2021 16:47, Pascal Thubert (pthubert) wrote: > At an abstract level I see your proposal as a form of BFD where the network assesses the liveliness of the root. The operation is done by a number of representatives that must agree that the root is gone. The draft does a good job at addressing the Byzantine problem once we know who the generals are, but it's unclear to me how they are elected and how they converse. This intuition is correct. Just one remark to be precise: the algorithm assumes no Byzantine nodes, merely ones that may have incorrect observations about the state of the DODAG root but otherwise follow the protocol. > That's a family of questions around the issue of how we avoid false positive. Seems that the more sentinels the less of them. But the less efficient the algorithm is. I think this intuition is by and large justified. However, it need not be correct formally, especially if one considers corner cases. Let me try to build up more intuition, which will hopefully also clarify some of my answers to your detailed questions. To start with, as you pointed up above, the decision that the root is down is a collective one. It is based on observations of multiple sentinel nodes. Each observation regards the direct link between the corresponding sentinel and the root. The observations are communicated between nodes---both sentinels and acceptors---in CFRCs. A decision based on such accumulated observations can be made by any node: sentinel or acceptor. It is important to note that "multiple" here means a number above some threshold, referred to in the draft as RNFD_CONSENSUS_THRESHOLD. The threshold should be reasonably large (e.g., more than 50%). However, it should not be too large (in particular, equal to 100%) because some sentinels may be dead as well or may be too slow detecting the failure. Formally, this implies that false positives are unavoidable. For example, assume that you have N>=3 sentinels, your threshold is 51%, 1 sentinel is certain that the root is up while the other N-1 sentinels claim the opposite, and the root is actually up and communicating with the 1 sentinel. In such a case, the N-1 sentinels claiming that the root is dead will outvote the 1 sentinel claiming otherwise and a global decision will be made that the root has crashed, which---formally---is a false positive irrespective of how large N is. What will happen is that, being able to communicate with the 1 sentinel, the root will learn the decision and rapidly initiate DODAG rebuilding by generating a new DODAG Version. In the new version, the N-1 old sentinels will likely not be sentinels anymore because they will not satisfy the necessary condition (unless their connectivity to the root is restored). Are such false positives bad? A sentinel claims that the root is dead if and only if its link with the root seems to be down. If a significant number of sentinels (e.g., more than the aforementioned 50%) claim this, then something undesirable must have happened to the connectivity within the DODAG. Therefore, in practice, even if the root has not crashed, it may make a lot of sense to rebuild the DODAG to account for the connectivity changes, especially since RPL's rank assignment algorithms may preclude some nodes from assigning ranks significantly larger than their minimal ones. Is there anything to be done to prevent such rebuilding from disrupting routing? First of all, if so many links are broken to make nodes believe that the root is dead, then routing is likely already significantly disrupted. Nevertheless, one may still want to avoid all nodes emptying their parent sets, which happens when RNFD's LORS transits to GLOBALLY DOWN. In this case, the root may act proactively, as mentioned in paragraph 2, Section 5.5 of the draft: It [the root] MAY also generate a new DODAG Version if fraction value(NegativeCFRC)/value(PositiveCFRC) approaches RNFD_CONSENSUS_THRESHOLD, so as to avoid potential interruptions to routing. For example, if the fraction exceeds 50% or 80% of the aforementioned threshold. Also, additional solutions are possible to further alleviate the problem but I think we have never needed to implement them, and hence they are omitted in the draft. So let's proceed to your detailed questions. > - do the sentinels encompass all first hop nodes? The formal answer is "not necessarily", which is what the draft states: to be sentinel a node must be a first-hop node but not every first-hop node has to be sentinel. The practical answer is that if one can accommodate all such nodes as sentinels (see the next question), then why not. > - how do we compute the right number of sentinels? The formal answer is that an optimal selection of sentinels depends on a number of deployment-specific factors and may thus be extremely hard to compute. Therefore, rather than an exact formula describing the number (and the placement) of sentinels, it is better to think in terms of trade-offs, precisely as in your intuition: - on the one hand, the more sentinels and the higher the decision threshold, the more "confidence" one can feel about their decisions on the root's crashes being correct but - on the other hand, the greater the overhead in that: the larger the CFRCs (which implies longer DIOs, possibly even fragmented), the more trickle timer resets, and potentially the more load on the root during suspicion verification. Given this, ideally, to select root's neighbors acting as sentinels, one would do a thorough statistical analysis factoring in all major risks. This may also be too difficult, though. My practical, experience-based recommendation for the sentinel selection procedure is thus roughly as follows: 1. Select the CFRC size such that the RNFD Option fits a DIO without causing too much overhead (especially to avoid fragmentation). 2. Let the root's neighbors become sentinels at random and gradually adapt their behavior such that PositiveCFRCs do not fill up (as described in Section 6) of the draft. More specifically, - start with all neighbors having the possibility of becoming sentinels; - if PositiveCFRCs do fill up (without a significant increase in NegativeCFRC), decrease the probability of becoming sentinel by half and issue a new DODAG version (this can be done autonomously by the individual nodes observing filling up of PositiveCFRC); - repeat the last step unless satisfied. 3. Furthermore, if some of the root's neighbors tend to switch roles too often or have unstable links to the root, blacklist them from becoming sentinels (again, this can be done autonomously by the nodes -- they can self-blacklist). 4. Finally, if RNFD experiences too many false positives nevertheless (which at this point probably means that the root is poorly connected in general), simply disable the algorithm (never happened in our deployments). To give some absolute numbers, I would aim at ~10, at most ~20 sentinels with stable links to the root. In the end, they are just representatives of the root's neighbors' population. After going though this a few times, one will probably have a good setting of initial parameters for similar deployments and the particular technologies employed with RPL. In effect, one would have to fine-tune them only in extreme cases, like ultra-sparse or ultra-dense networks. What I am trying to convey here is that sentinel selection is a matter of managing the network rather than a responsibility of the RNFD protocol itself. The protocol strives to provide only mechanisms that enable effective management by network administrators. Equipped with such tools, it is the administrators who will come up with the best management policies, which are inherently deployment-specific. What is more, the mechanisms provided by RNFD allow for having the policy enforcement automated to a large extent. > - do the sentinels needs direct connectivity to one another? No. The sentinels alone do not even need to form a connected graph on their own (decisions are made by sentinels or acceptors), which makes the algorithm really broadly applicable (including the aforementioned possibility of random sentinel selection and robustness to some of the security threats mentioned earlier by Michael). > - how quick should the protocol react ? This also depends on the particular technologies one uses RPL with. At worst, RNFD must react as soon as routing adjacency maintenance at a root's neighbor acting as sentinel detects that the link to the root is down. More aggressive approaches can be adopted though, especially since for some neighbor unreachability detection solutions, the precise convergence criteria need not be straightforward to infer. > - I mean, if the root reboots, is that worth the hassle of breaking and forming the DODAG again? This also depends on a particular deployment, the duration of the reboot, and other technologies that RPL is used with (e.g., how quickly a link failure is detected by routing adjacency maintenance). In our settings, an immediate LBR reboot could pass undetected, unless we did not want it to. In this context, I believe that one DODAG rebuilding due to an LBR reboot probably does not hurt. However, repeated reboots may indicate some problems with the LBR that may require attention, irrespective of whether RNFD is used or not. > - do the sentinels form a connected group ? how ? if not, what happens if one group loose connectivity to the root but the other does not? Ad 1. No (see one of the previous answers). Ad 2. N/A Ad 3. To answer precisely, one would need to know the sizes of the groups with respect to the total number of sentinels and the decision threshold. In short, in a pessimistic scenario in which in addition to the crash of the root the whole network partitions into multiple groups none of which has enough sentinels to exceed the decision threshold, RNFD would not detect the crash in any of the groups; it would be detected with RPL's own mechanisms, which are much slower though (provided RPL is correctly configured). To close this e-mail, I would like to emphasize that, as mentioned in the draft, RNFD is inherently probabilistic. It can significantly improve RPL's performance in a wide range of deployment settings. However, like for any other protocol, this range is not infinite, and beyond it, no gains will be observed. Similarly, like any other protocol, it may require some maintenance, but this maintenance can be largely automated. Finally, should such a need arise, RNFD can always be disabled at runtime. Once again, thank you for your insightful questions Pascal. Best regards, -- - Konrad Iwanicki. >> -----Original Message----- >> From: Roll On Behalf Of Konrad Iwanicki >> Sent: jeudi 8 avril 2021 23:20 >> To: Routing Over Low power and Lossy networks ; Pascal >> Thubert (pthubert) >> Subject: Re: [Roll] Border router failure detection >> >> Hi again Pascal, >> >> On 08/04/2021 16:16, Pascal Thubert (pthubert) wrote: >>> Hello Konrad >>> >>> About this text >>> " >>> >>> Since all DODAG paths lead to the corresponding LBR, detecting its >>> crash by a node entails dropping all parents and adopting an >> infinite >>> rank, which reflects the node's inability to reach the LBR. >> However, >>> achieving this state for all nodes is slow, can generate heavy >>> traffic, and is difficult to implement correctly [Iwanicki16] >>> [Paszkowska19] [Ciolkosz19]. >>> " >>> >>> Please note that this may be what an implementation decides to do, but >> is by far not my favorite option. >>> The alternate is to rest the "G" but and become floating root. The >> benefit is that the DODAG structure is mostly maintained and that routing >> inside may persist. >>> >>> See https://tools.ietf.org/html/rfc6550#section-18.2.4 for how to >> configure this. >> >> OK, I think I addressed this in my previous e-mail to you and Michael. >> >> (The next two e-mails will have to wait till tomorrow I am affraid.) >> >> Best, >> -- >> - Konrad Iwanicki. >> >>>> -----Original Message----- >>>> From: Roll On Behalf Of Konrad Iwanicki >>>> Sent: mercredi 7 avril 2021 21:37 >>>> To: Routing Over Low power and Lossy networks >>>> Subject: Re: [Roll] Border router failure detection >>>> >>>> Dear all, >>>> >>>> Approximately a year ago, I joined the WG and advertised an extension >>>> to RPL that I had been working on for some time with a goal of >>>> describing it in a draft. Unfortunately, just when I got the >>>> necessary pointers and a few initial comments, the pandemic broke >>>> out. The resulting surge of professional and personal obligations >>>> made it literally impossible for me to participate in and, at some >>>> point, even follow the group's activities, for which I am sorry. >>>> >>>> However, I did strive to regularly find a little time to get somewhat >>>> acquainted with IETF's procedures and write up something that may >>>> resemble a draft. I have just submitted it as: >>>> >>>> draft-iwanicki-roll-rnfd-00 >>>> >>>> and created a dedicated repository on the group's GitHub. >>>> >>>> Since I have no experience writing IETF documents, I would really >>>> appreciate your collaboration on either turning the text into a true >>>> draft or concluding that this should not be done. >>>> >>>> Please, keep mind in mind that I decided to maximally cut down the >>>> original algorithms, so that the extension is as simple as possible >>>> without losing key properties. Therefore, it is likely that if the >>>> extension as a whole or any of its parts turn out relevant or >>>> interesting, still a considerable amount of work may be necessary to >>>> have it or them described properly. Your contribution is most welcome. >>>> >>>> Thanks in advance. >>>> >>>> Best regards, >>>> -- >>>> - Konrad Iwanicki. >>>> >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From nobody Wed Apr 21 02:44:47 2021 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 40FB73A1DB6; Wed, 21 Apr 2021 02:44:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-roll-aodv-rpl@ietf.org, roll-chairs@ietf.org, roll@ietf.org, Ines Robles , aretana.ietf@gmail.com, mariainesrobles@googlemail.com, consultancy@vanderstok.org X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <161899828182.30762.17925223604861378275@ietfa.amsl.com> Date: Wed, 21 Apr 2021 02:44:42 -0700 Archived-At: Subject: [Roll] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-roll?= =?utf-8?q?-aodv-rpl-10=3A_=28with_DISCUSS_and_COMMENT=29?= 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: Wed, 21 Apr 2021 09:44:42 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-roll-aodv-rpl-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-roll-aodv-rpl/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for the work put into this document. I seems that all cases have been thought of :-) Good job! and having a shorter path between two RPL nodes can be benefitial of course. Please find below one blocking (but probably trivial to fix) DISCUSS point, some non-blocking COMMENT points (but replies would be appreciated), and some nits. Special thanks to Peter Van der Stock for the IoT directorate review: https://datatracker.ietf.org/doc/review-ietf-roll-aodv-rpl-10-iotdir-telechat-van-der-stok-2021-04-15/ To be honest, the lack of reply to Peter's review by the authors or by the WG a little bit suprising (thank you to the RTG AD though). Minor regret on the age of the document shepherd's write-up dated 2 years ago and about the -06 version. Little is said about the WG consensus. But, I am trusting the responsible AD on the consensus. I hope that this helps to improve the document, Regards, -éric == DISCUSS == A very trivial to fix but I do want to have a justification of using "point-to-point" (typically used over the two sides of a single link) vs. "peer-to-peer" (typically used over multiple links). Is it intentional by the ROLL WG ? Did I fail to understand the purpose of this document ? (quite possible of course!). I am afraid that many people will interpret the "point-to-point" like me. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- == COMMENTS == -- Section 4.3 -- Figure 3 has a 'X' while the text has a 'r' ;) Any reason why using "Floor((7+(Prefix Length))/8) octets" rather than the simple "Ceil(Prefix Length/8)" ? -- Section 6.1 -- "Each node maintains a sequence number" does it impact constrained nodes ? == NITS == -- Abstract -- "the links between source and target node are asymmetric" should this be "nodes" (plural) ? -- section 1 (and possibly others) -- I believe that the usual way to introduce acronyms is to first write the expansion than the acronym itself. So " RPL (Routing Protocol for Low-Power and Lossy Networks)" does not seem to fit ;) -- Section 5 -- "R is an intermediate router" or "Rs are intermediate routers" ? From nobody Wed Apr 21 03:42:57 2021 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 6386B3A1FC0; Wed, 21 Apr 2021 03:42:52 -0700 (PDT) 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, RCVD_IN_DNSWL_BLOCKED=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=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 x6vq1bLi0jyO; Wed, 21 Apr 2021 03:42:48 -0700 (PDT) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 65AF83A1FC2; Wed, 21 Apr 2021 03:42:47 -0700 (PDT) Received: by mail-ed1-x52f.google.com with SMTP id h8so8627024edb.2; Wed, 21 Apr 2021 03:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=1JdCaKAL9Me/uRuIGYqIlAL5PX07n0RjnbPJOd5RNgc=; b=iX4ardW6MdQbkmn26MiWoq5/qSK1mdvHK1xlJ6GBW4zLzbNRUmcnYLAEcj38vUbQ4B dqSwK5GIHTQpTqsrOsC3A0EiR6KgrRTp033GZ//79fpnClbZ1cXC3A5VeAe3McyN4s6x ZldKKxEPIDnr1/Q8E1iLAwq07CUzYd2zt8S/9UKTJxN61Wwk877YvDvs2IHOtacImIqb K1rq3zED3fbBOm0ZyUIj6XFcpoGnYOjtjQFPyIHZY0j0/tQDL6yh/x0hoktPJxqMtfSr FmFPKAm3b6e77Nwa+8VdZ7eqkNRfUpNsFCeAoR87Jmz61nuJoQDbGQxsTFW4B0LC4EeW 2dVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=1JdCaKAL9Me/uRuIGYqIlAL5PX07n0RjnbPJOd5RNgc=; b=Dq/nBpXn++g27dVAsKEXGlwLjnwzRtYpLgx9dtLceeEs2uyUslvQOOblju2H0iCTVA xj6vjnx/xtG44wl5mnroakIIHVRoasQ+AcA+Tsohb1tGAvrvk93uSuIIxrcpy797iqc6 tq+aoT1DFqIMC3cjsk0XEPWa5GNC7/kU9lS/IjBJ1ndZ075NgwCWQtxeJ1vPByaK/7lJ eSn87mbwd0imPFVLAGQ1ROfsb9FvERU8batL34IwF2GxPpPDiklTsdiIvSBYHuEBABrF NEhwLyFY2B/HrZQ6yTfb0sOq84OVJmpMCXknAwuHLKm9r0+FbbFS7YGe8KwBV/zOXowp /Ncg== X-Gm-Message-State: AOAM530HwDKUlAC1q2NQADVC8akdHjT71ZJ2ZCf70319tI7TruHDYScm B5Npst50yHu2kcAQPHHMesqW1qZoDUAvSpcz+Kte2HsR0NU43g== X-Google-Smtp-Source: ABdhPJweetVx0LfQ+5K5pHocAKRFb9qQi618e6YPRSJvbFza6j4ZTPDYEW6x9o1ddQk2LWMk2/0xcwgv7yzSSiLLdEk= X-Received: by 2002:aa7:c1c9:: with SMTP id d9mr37393953edp.155.1619001764762; Wed, 21 Apr 2021 03:42:44 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 21 Apr 2021 03:42:43 -0700 From: Alvaro Retana In-Reply-To: <161899828182.30762.17925223604861378275@ietfa.amsl.com> References: <161899828182.30762.17925223604861378275@ietfa.amsl.com> MIME-Version: 1.0 Date: Wed, 21 Apr 2021 03:42:43 -0700 Message-ID: To: =?UTF-8?Q?=C3=89ric_Vyncke_via_Datatracker?= , =?UTF-8?B?w4lyaWMgVnluY2tl?= , The IESG Cc: draft-ietf-roll-aodv-rpl@ietf.org, roll@ietf.org, roll-chairs@ietf.org, consultancy@vanderstok.org, Ines Robles Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Roll] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-roll?= =?utf-8?q?-aodv-rpl-10=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 21 Apr 2021 10:42:53 -0000 On April 21, 2021 at 5:44:43 AM, =C3=89ric Vyncke wrote: =C3=89ric: Hi! =C2=A0Thanks for the review! Just replying to the DISCUSS. ... > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- ... > Special thanks to Peter Van der Stock for the IoT directorate review: > https://datatracker.ietf.org/doc/review-ietf-roll-aodv-rpl-10-iotdir-tele= chat-van-der-stok-2021-04-15/ > > To be honest, the lack of reply to Peter's review by the authors or by th= e WG > a little bit suprising (thank you to the RTG AD though). I'll make sure the authors reply to Peter before we move forward. [BTW, Peter was roll chair when this document went through WGLC. :-) We're all very grateful for his work.] ... > =3D=3D DISCUSS =3D=3D > > A very trivial to fix but I do want to have a justification of using > "point-to-point" (typically used over the two sides of a single link) vs. > "peer-to-peer" (typically used over multiple links). Is it intentional by= the > ROLL WG ? Did I fail to understand the purpose of this document ? (quite > possible of course!). I am afraid that many people will interpret the > "point-to-point" like me. That is the terminology that is used to describe this type of traffic flow in RPL -- see rfc6550/=C2=A74 (Traffic Flows Supported by RPL). Alvaro. From nobody Wed Apr 21 03:51:16 2021 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 D469D3A2009; Wed, 21 Apr 2021 03:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.617 X-Spam-Level: X-Spam-Status: No, score=-9.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=Sv3HRnHw; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=QR87cQ73 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 L8klrQJ7tAji; Wed, 21 Apr 2021 03:51:07 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE55E3A200B; Wed, 21 Apr 2021 03:51:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3506; q=dns/txt; s=iport; t=1619002267; x=1620211867; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=QDse73BOzNtA4gwsp1DrPDcWuxRMZs34j2zltNgCPaE=; b=Sv3HRnHwnQmeWEERyYgohG63DdwRnDf6UlaXK4qOrl1bD24cR8fHupW1 5uwAsJJUNIFOLPQZpuECxnM/bV2sN9j1aTMNTRYZECTbXLs1qlx9vmY0o /XQBs6Q0n4hDQHLbDMH1MtGXpfhVQI5suLNSXlsym2ukXFMLrsY0ubz84 A=; X-IPAS-Result: =?us-ascii?q?A0BYAAB2AoBg/5xdJa1UBhwBAQEBAQEHAQESAQEEBAEBQ?= =?us-ascii?q?IE+BwEBCwGBUlEHd1o2MYRDg0gDhFlgiE0lA4EJiSaPD4EugSUDVAsBAQENA?= =?us-ascii?q?QEqCAIEAQGEUAIXgV4CJTQJDgIDAQEBAwIDAQEBAQEFAQEBAgEGBHEThVANh?= =?us-ascii?q?kQBAQEBAyMRDAEBNwELBAIBCA4DAwECAwImAgICHxEVBQMIAgQBDQWCcQGCV?= =?us-ascii?q?QMvAQ6dPAKKH3qBMoEBggQBAQaBNwIBDUGDMQ0LghMDBoEQKgGCd4QLgkCEE?= =?us-ascii?q?iccgUlCgRMnDBCCKTY+gh5CAgOBTYMnNoIrgWlhZARTUCsEGWkRYpBegnVCl?= =?us-ascii?q?HGRClsKgw2Jao1pBIU4BCGlBYUTkA2LcYMZlDcCBAIEBQIOAQEGNYEfOoFZc?= =?us-ascii?q?BVlAYI+UBcCDo4fDBYVgzmFFIVJczgCBgEJAQEDCQF7jBMBAQ?= IronPort-PHdr: A9a23:QdO6GxFgeZlTbt8owhEM751GftIY04WcBSYc94YnhrRSc6+q45XlO gnF6O5wiEPSNa3U7vtFj6zdtKWzEWAD4JPUtncEfdQMUhIekswZkkQmB9LNEkz0KvPmLklYV MRPXVNo5Te3ZE5SHsutaFjbo3n05jkXSV3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/N lO4twLU48IXmoBlbK02z0ihnw== IronPort-HdrOrdr: A9a23:uY9qoqCFqVPvI9PlHei9tceALOonbusQ8zAX/mhLY1h8btGYm8 eynP4SyB/zj3IrVGs9nM2bUZPgfVr1zrQwxYUKJ7+tUE3duGWuJJx/9oeK+VPdMgXE3Kpm2a 9kGpIQNPTZB1J3lNu/xQG+HcopztXvytHWuc715R5WPGZXQotn6Bp0DRveMmAefngHObMSEp 2A6s1b4x+pfnoKZsq2b0N1IdTrjdvNiZ7gfFo6HBYh8gaDlneF77T9Hhie0H4lInBy6J0l9n XIlBG827W7v5iAu17h/kLwz7ATotvuzdNfGNeB4/J0FhzAghulDb4RIIGqkysypIiUmTMXuf nK5ywtJsFir07WF1vF3SfF/ynF/HIQ52T5yVme6EGT4/DRYD4hEcJOicZ4X3LimjAdlepx2q 5KwG6V3qA/ZXir8UiNhKmrazhQmkW5unYkm+II5kYvLLc2UqNbroAU4SpuYfE9NR/684wuHa 1PC8zR9Z9tACunRk3ZpWVmzZiQWG0yFH69MzE/k/GSugIm+ExR/g89/ogyj30A/JUyR91v/O LfKJllk7lIU4s/cb99LP1pe7rzNkX9BTb3dE6CK1XuE68Kf1jXrYTs3bkz7Oa2PLQV0ZoJno jbWl8wjx93R2veTem1mLFb+BHER2uwGR73zNtF2pR/srrgAJ3mLDOEU1Jrt8e7uf0QDon6Vp +ISdVrKs6mCVGrNZdC3gX4VZUXA2IZStcpttEyXE/LrdnMLoHsq+zHYPfeLLfgCl8fKzrCK0 pGeAK2CNRL70itVHO9qgPWQWnRdkv2+o81EKWyxZlK9KE9cql39iQFg1Ww4c+GbRdYtLYtQU d4KLT71qeypWy8+3fU/3xkUyAtVXp90fHFaTdntAUKO0T7ffIooNOEY11f23OBO1t4VMPZEA lWolxt4qKpJ5mMxSQvYujXdF6yvj82njanXp0ckqqM6YPOYZUjFKsrX6R3CEHWDRBvgB1rr2 1CcQcAQUfaGlrV+P+Ypa1RINuaW8h3gQ+tL8IRlGnWsl+Eo9ozAlEBWSS1bMKRiQEyZjZdi1 Fr6ZUDiL6YlTvHExpjvM0IdHl3LEWeGvZvERmMboQ8oMGbRChACUOxwQG8pz52UGzw7EkWjn HmNkSvCIH2K2sYnGtZ3Kbs+E5zbUOHcStLGyxHmLw4M3jasXBu1uLOQay/3wKqGwU/69BYFi 3Zaj0PJQ4r/fSL7Vq+nTaPEmhO/ORwAsXUEKkjf7bP2nmkNY2PkuUcE+VJ+Yt+XeqewNMjTf iSYEucIj/+FooSqn+oj2dgNy9upHY+l/T0nBXj8WijxXY6ReHfOVJ8WtggUp2hxnmhQ/aDy5 Nii90p+eO2L2Xqc9aDoJunJQJrO1fWoWSsSfsvpo0RtaUutKFrF52eVTfTznlI0FE/K8jz/X luDZhT8fTEOoV1edYVdD8c9l01lM6XJE9uqxfoGIYFDBgQpm6eO8nM76vDqLIpDEHErAzsOU OH+ykY+/veRSOM2bMTFqpYGxUYVGEsrHB5uO+SfYzZDwunM/tO+1e3KXexer5QQqrtI8Rakj 9qp9WT2+OHfSvx3w7d+SZhKqVV6mC9XIe8BhmPFeMgya31BX2cxq+xpMi9gzf8RWHlNwAWhY hZeVcRacoGgD84l4Ez2jWzTKuyok9NqSoo3Rh30lr2no6h6yPHGEsDNwvTiJBfRyNSPXiFlt 6ty5nR6F3tpDxenYDeH0JRdMxUE9ceToLrPz5jQPJgyIKA7u4qmGBfex8gAG43lSDl0+5n1b m/3u/OW+eKMwafBXsRvThfBoB1mSQ3qWZPN8imhKjNFzkqKg== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,238,1613433600"; d="scan'208";a="685581580" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Apr 2021 10:51:05 +0000 Received: from mail.cisco.com (xbe-rcd-007.cisco.com [173.37.102.22]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 13LAp5pq030216 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 21 Apr 2021 10:51:05 GMT Received: from xfe-aln-001.cisco.com (173.37.135.121) by xbe-rcd-007.cisco.com (173.37.102.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Wed, 21 Apr 2021 05:51:05 -0500 Received: from xfe-aln-001.cisco.com (173.37.135.121) by xfe-aln-001.cisco.com (173.37.135.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Wed, 21 Apr 2021 05:51:05 -0500 Received: from NAM04-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-001.cisco.com (173.37.135.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Wed, 21 Apr 2021 05:51:05 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I+fF+vcvhXdVXvcO1xVmlqVeKnXhj6OwisBDEQfcE07GBoShxEgswBcl70EkS7V5eyrXG97N09/hFjBp8PmdMn0PoVDQMGjAUNHT9ZnJHdqlnCYxyZUYESWy/PrYrEiYhbVuxHkeX2sbFJKDgUH/CgDhnMc+MHEYxbRh4M4+K5Z8ic58aYPuJ3UudFAaeJwcxiNl/Fv1hyCGr/vQpe0UdANR5luaSARQRjJSEhLu+V1uf3Ty2HShOX055JzhMrKqfA23OJru6amZkUCRIK0jcWSwt8pMEbRKFSNrxSuxpgOPtb+W7f2LlMEThP1NMg1uwVGa9KhUdWAzgWuiBjTfQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QDse73BOzNtA4gwsp1DrPDcWuxRMZs34j2zltNgCPaE=; b=cSYdcMCL4srj/zzDNWYenG5LlG4GTgmMAX6/oydr/VtycChsuSPxirRX2dSvfFPMAG13g6VgL8FJ5Z6MXpdFn0Ulfd07vG16mEGeOI39FxA5a0VdVFv8aNR3XnEZPguj+3n2cE+hv87RtdEfzIjQXlTi1Su82Xw2MV9C9VkNV/E9ZHfaLmcEQXguyNljDRnWjuZoZiAIs5chM/WrijFU0j4yjwo00DEeqKKrXlPahes/Z3UB5LE3DnCbmqIS9cEVBA5XfU1SY2tmoszBU3hlwfxco3yURB39p7FWM8JJXmUeACoOgUdl4RC2TI6m0LjrO+cFyz0wTkAtSNcdW+6bDw== 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=QDse73BOzNtA4gwsp1DrPDcWuxRMZs34j2zltNgCPaE=; b=QR87cQ73UItldzkyRmRQei45AKM+9+TyCY53atlb+qZ1GBkLGgZLEp5piwlR/O0PEOooHEXPdGZd3bDhMUc7pjyvA1j+A+WFe6sjrVPkrc363H09zmEkDLsALeuOR+X/8W4modrvjCX72Z2mSvwtvqJcfsGewA2jzKM31LDFf3Q= Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB4855.namprd11.prod.outlook.com (2603:10b6:510:41::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.16; Wed, 21 Apr 2021 10:51:04 +0000 Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::dcdf:3910:b85d:6eba]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::dcdf:3910:b85d:6eba%7]) with mapi id 15.20.4042.018; Wed, 21 Apr 2021 10:51:04 +0000 From: "Eric Vyncke (evyncke)" To: Alvaro Retana , =?utf-8?B?w4lyaWMgVnluY2tlIHZpYSBEYXRhdHJhY2tlcg==?= , "The IESG" CC: "draft-ietf-roll-aodv-rpl@ietf.org" , "roll@ietf.org" , "roll-chairs@ietf.org" , "consultancy@vanderstok.org" , Ines Robles Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXJvbGwtYW9k?= =?utf-8?Q?v-rpl-10:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHXNpMBvYX1IRClB0eUcTFEoYIq36q+yPeAgAAj3IA= Date: Wed, 21 Apr 2021 10:51:03 +0000 Message-ID: <29EDF026-9741-4864-AC0C-E8375E402D4C@cisco.com> References: <161899828182.30762.17925223604861378275@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.48.21041102 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2a02:578:8557:600:b8ca:60c1:da08:40d7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1ab826b5-4014-460b-705a-08d904b35c31 x-ms-traffictypediagnostic: PH0PR11MB4855: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: PFdCuxM3TmCfxR0hVuqagpPC6DYX4vUz0kWtSflftaAWYzlwCnOH1I/cmPmj4OWJEYaG3OAZ7ZuZjF4QI+w4JNQcGFzm2tlgA46gEFa/0fbDV/ILOzUZeDqXFE5uVCg+u/Dg6YYvRBcwnb2AGy9KiXe5LDoEW/hGsCo/M5vY/+8UAH7oHbb8HVdRPaXLXzKaBzd5sHbGGobErSSX6mw1eB0+5nr+yfokleWyxLJkPCeTrmTpRQbQAhpY23Qm+NUk3k1AAzzdpyhS/kmbHBcsHtraFg8zOu440TOnzM5TcYjJiKpt65QWnRWns4q9QhZY9QPutZ6lOmQcyLK/wdm6MhCGRoBvr0yVTIbmPl2FiXpUNvOgD8Cp39rTChbbLHjX3wPWo2Dl43pR/JTYMKSsm1L46u7ew3q1n89PUHWG3CKVeuwc0mRkIMZ/5uwb56/tKA5JGsnV2Yxqq/lKER95RNJuu2ou4AAqnMyxIcvn9wktPI5g5Afj176RiQ9B9eJQD+byte+P0xXRUGevzTGSevFVXGQyFTwgYLJsQyeBPIKcz2f2MHnM31iL8mUNpIhDd7SVyjEqU/or6nEG9MJth9IOWEHW7WxySnFglb1pnoebBvpGVX+L1tAuKyuwuOxGel1EvxTIJ27eheV2ZfLBgU3Dpt5goMXZHAWMFI8hRyuStpTk1mqYNqvxpRcG43I63QAc1RNAG6ib992W5TJ6oiqcuQwHJdee2Lrli17VVwk= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(136003)(366004)(376002)(396003)(346002)(91956017)(6512007)(6486002)(86362001)(8936002)(186003)(64756008)(316002)(66446008)(54906003)(2616005)(122000001)(36756003)(110136005)(66556008)(66946007)(76116006)(38100700002)(71200400001)(6506007)(966005)(2906002)(4326008)(224303003)(83380400001)(478600001)(33656002)(66476007)(53546011)(5660300002)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?TENiNTAreE1lRG9pZGVLeitQQW5xdFFqRTVDZ0FKVWhCYjdDdkFPbkQ5ejFu?= =?utf-8?B?Yy9ZNG5vODdmbDlxY0hNUlVvWGVKYTFlaG43U3BtZXZyZjJVeWQyM2xtbitR?= =?utf-8?B?TXh2VTU1T3FmeGNQRTk2SjdscVM5dllQenJyenpOTmFhb1hxN2JqMTN1WTRl?= =?utf-8?B?OGxORHJHRllaRVFUYys1WWlpbjhRTWxidUUwcXEyWTNxMWVJeVRrRDQ2bjlt?= =?utf-8?B?NEhaR2FIVHAweU9FejlJSDNoR2NJMDJTaHM0YVkyN3drd0NFdkxOR0dlcHVr?= =?utf-8?B?N2dBUWxMZlFTOUZPMHp6SlFKbEl5WmtwOVhjK1MzelhVWUF4M3BXZnIwWitG?= =?utf-8?B?UmQ1UWJMb0I4SWJQR28wenQwWkN4SU5GMitzN1NWYVlZblRPVXp1aGtkRXBQ?= =?utf-8?B?VUUvbDV0WlVEZ2hDWXlhRWIxWjUwakd1NjloRzlGaFdtRG4zV1FzWUR6cy9u?= =?utf-8?B?YmdiVWpvamQxcWtxUkxBeHExZ0hXNHY4VU42YW1Gczd5eUJGMGtpQkFZS2xn?= =?utf-8?B?bkZrSzgvMFV2WGh1Q0xCNCtZNEJKQUJqRDF6N3k5UHF5VUtyRjB4NWhDM0hv?= =?utf-8?B?UEVRTHAvNjcxZDE2Qk9GMDZzRjkvcFRncEVhWFE5d3JxQWZPanpZRFBwWVpk?= =?utf-8?B?Zm05MGdvV210RUh1REgwRHd1dmpLcEdGMnVQN2ovd3k3SU5yelUrREdtRHUw?= =?utf-8?B?alg5NUJRc1ZyYzc3SjZINTZxZUorQytNalY1TnRLbHR6VStEUzloWHlXODNm?= =?utf-8?B?VStTc0swOFJtclhlMzViWWFCRGlldGJCMS9uckxkY0ZTaUc2K2J4WTkvMytT?= =?utf-8?B?a1NTVlVzam1DR2NNTHEzTERUQVlXVEZKYm1IQVg3TWZwQlNLNDF4R0ZTTzIz?= =?utf-8?B?bDJ4UGsvRHRMalBTclNrblJhMzNyQldZckxTckYrTFgyZDRPdzVKU2ltTmph?= =?utf-8?B?NEp2UHZNaXhiYmh1eWFDSTg2L3IxdDcza0Q5d3N4cEtSczVDWlRPVjMyTXdr?= =?utf-8?B?cDJjUzF4bjY0TEE5NHVVVHQ5ZFBKR05McVpDSTNuejhuU2xpSURwWTMrUXAx?= =?utf-8?B?bnFPN3FWdWJEdHQxejFtcWpTMkEySmp5OE1wSHpyNjJCZkV1K3RnTDJyZS96?= =?utf-8?B?RGd5NEpxblVKa3dRQ0VjM2dFSnpnUm5EdTBISnc1TG9NOFdqakpaUkdJa2sx?= =?utf-8?B?S3BFZWFncERhd1VnNzE3M2ZHVU50S2Y3cDVvZlAzUTZxR2lnczNYSzd3N1Rz?= =?utf-8?B?Um5rQndOQTRzY091aEJqZ0JZc1U3bTQzaHU0b1l5Tmw5cTZTSzZYck00MGlu?= =?utf-8?B?WDVZSWZueVZucS8xM29ieUVyRlJJZVZZWVFQUlNzSGJzVmoydjNXR1o1Znp1?= =?utf-8?B?N05LVEsyOWozYzUxVzlHQkZNcHhHdTZiQStwOEtEbGhWZFdXdjJsYlE3ZExB?= =?utf-8?B?K2Rab1BGckxVT3A3QklwMEV1azh4emRRc01VT1NJNktzNm0wdkNKUzdxc0RY?= =?utf-8?B?Wk1vZzB2aUJrTjg3akxOekNBQ3FGRnRxMTBvMVZYL3kxeEs1QXVRTHBHT2ty?= =?utf-8?B?ajBqT0psSGM0ajkrMndjK1Bpb1l0OFRGbTNPL0RDQ1ZCN2g5Z2t0YzFTTHQ5?= =?utf-8?B?ZzE3eWZlUzdoT2NHZys4NmRGZFlpM2g1ZzVRZkdUMXVlbWl1WDRuSGVlMGIw?= =?utf-8?B?NTFMQjVjcUdaTVlKVG9CcHlzdGJKL01TVGZtVUNZSXc3QjVjZkplS2wrVHlz?= =?utf-8?B?MnpXV1g2TjUrM3F2QWk2cEIyd0p4bDJQU2RkSEwremdpdEZrL1FncHlvaFdR?= =?utf-8?B?a0Z0TFFTYmxZZ25YYzhMSWxVbUlKN25TdTJYUEJtd3NTMG5iVDhlTG5HaVRp?= =?utf-8?B?QU9yeGt4VmdxbFRJR3J2V0JuV0dCb1VHOVpXNkxBbEZzVnc9PQ==?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <2D81CC36CE43734FB1EC1B8631848DC2@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1ab826b5-4014-460b-705a-08d904b35c31 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2021 10:51:03.9567 (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: ATe8/2jwp4+TTOoIRg4y7hA6jbFvSw4BCscqvWwcFdeW2ACq93840O6KQ5Smn/SDZ7zSmWcT4Tudf6F13b6Djg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4855 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.22, xbe-rcd-007.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [Roll] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-roll?= =?utf-8?q?-aodv-rpl-10=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 21 Apr 2021 10:51:12 -0000 QWx2YXJvLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgcmVwbHkgYW5kIGVzcGVjaWFsbHkgYWJvdXQ6 DQotIHRoZSBJTlQgZGlyZWN0b3JhdGUgcmV2aWV3DQotIHRoZSBQMlAgbmFtaW5nLi4uIFRoZSDC pzQgb2YgUkZDIDY1NTAgaW5kZWVkIHVzZXMgdGhpcyByZWFsbHkgdW51c3VhbCBtZWFuaW5nIGZv ciBwb2ludC10by1wb2ludCA6LSggTWF5IEkgc3VnZ2VzdCB0aGUgZG9jdW1lbnQgYXV0aG9ycyB0 byBhZGQgYW4gZXhwbGFuYXRpb24gb24gdGhpcyBzZW1hbnRpYyBpbiB0aGUgdGVybWlub2xvZ3kg YXMgd2VsbCBhcyBpbiB0aGUgYWJzdHJhY3QgKGFzIGl0IG5lZWRzIHRvIHN0YW5kIGJ5IGl0c2Vs ZikgPw0KDQpIYXBweSB0byBjbGVhciBteSB0cml2aWFsIERJU0NVU1Mgd2hlbiB0aGUgYXV0aG9y cy9XRyBhZ3JlZSB3aXRoIHRoZSBhYm92ZSBjaGFuZ2UuDQoNClJlZ2FyZHMNCg0KLcOpcmljDQoN Cu+7vy0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBbHZhcm8gUmV0YW5hIDxhcmV0 YW5hLmlldGZAZ21haWwuY29tPg0KRGF0ZTogV2VkbmVzZGF5LCAyMSBBcHJpbCAyMDIxIGF0IDEy OjQyDQpUbzogw4lyaWMgVnluY2tlIHZpYSBEYXRhdHJhY2tlciA8bm9yZXBseUBpZXRmLm9yZz4s IEVyaWMgVnluY2tlIDxldnluY2tlQGNpc2NvLmNvbT4sIFRoZSBJRVNHIDxpZXNnQGlldGYub3Jn Pg0KQ2M6ICJkcmFmdC1pZXRmLXJvbGwtYW9kdi1ycGxAaWV0Zi5vcmciIDxkcmFmdC1pZXRmLXJv bGwtYW9kdi1ycGxAaWV0Zi5vcmc+LCAicm9sbEBpZXRmLm9yZyIgPHJvbGxAaWV0Zi5vcmc+LCAi cm9sbC1jaGFpcnNAaWV0Zi5vcmciIDxyb2xsLWNoYWlyc0BpZXRmLm9yZz4sICJjb25zdWx0YW5j eUB2YW5kZXJzdG9rLm9yZyIgPGNvbnN1bHRhbmN5QHZhbmRlcnN0b2sub3JnPiwgSW5lcyBSb2Js ZXMgPG1hcmlhaW5lc3JvYmxlc0Bnb29nbGVtYWlsLmNvbT4NClN1YmplY3Q6IFJlOiDDiXJpYyBW eW5ja2UncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtcm9sbC1hb2R2LXJwbC0xMDogKHdpdGggRElT Q1VTUyBhbmQgQ09NTUVOVCkNCg0KICAgIE9uIEFwcmlsIDIxLCAyMDIxIGF0IDU6NDQ6NDMgQU0s IMOJcmljIFZ5bmNrZSB3cm90ZToNCg0KDQogICAgw4lyaWM6DQoNCiAgICBIaSEgIFRoYW5rcyBm b3IgdGhlIHJldmlldyENCg0KICAgIEp1c3QgcmVwbHlpbmcgdG8gdGhlIERJU0NVU1MuDQoNCg0K ICAgIC4uLg0KICAgID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgID4gRElTQ1VTUzoNCiAgICA+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCiAgICAuLi4NCiAgICA+IFNwZWNpYWwgdGhhbmtzIHRvIFBldGVyIFZhbiBkZXIg U3RvY2sgZm9yIHRoZSBJb1QgZGlyZWN0b3JhdGUgcmV2aWV3Og0KICAgID4gaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvcmV2aWV3LWlldGYtcm9sbC1hb2R2LXJwbC0xMC1pb3RkaXIt dGVsZWNoYXQtdmFuLWRlci1zdG9rLTIwMjEtMDQtMTUvDQogICAgPg0KICAgID4gVG8gYmUgaG9u ZXN0LCB0aGUgbGFjayBvZiByZXBseSB0byBQZXRlcidzIHJldmlldyBieSB0aGUgYXV0aG9ycyBv ciBieSB0aGUgV0cNCiAgICA+IGEgbGl0dGxlIGJpdCBzdXByaXNpbmcgKHRoYW5rIHlvdSB0byB0 aGUgUlRHIEFEIHRob3VnaCkuDQoNCiAgICBJJ2xsIG1ha2Ugc3VyZSB0aGUgYXV0aG9ycyByZXBs eSB0byBQZXRlciBiZWZvcmUgd2UgbW92ZSBmb3J3YXJkLg0KDQogICAgW0JUVywgUGV0ZXIgd2Fz IHJvbGwgY2hhaXIgd2hlbiB0aGlzIGRvY3VtZW50IHdlbnQgdGhyb3VnaCBXR0xDLiA6LSkNCiAg ICBXZSdyZSBhbGwgdmVyeSBncmF0ZWZ1bCBmb3IgaGlzIHdvcmsuXQ0KDQoNCiAgICAuLi4NCiAg ICA+ID09IERJU0NVU1MgPT0NCiAgICA+DQogICAgPiBBIHZlcnkgdHJpdmlhbCB0byBmaXggYnV0 IEkgZG8gd2FudCB0byBoYXZlIGEganVzdGlmaWNhdGlvbiBvZiB1c2luZw0KICAgID4gInBvaW50 LXRvLXBvaW50IiAodHlwaWNhbGx5IHVzZWQgb3ZlciB0aGUgdHdvIHNpZGVzIG9mIGEgc2luZ2xl IGxpbmspIHZzLg0KICAgID4gInBlZXItdG8tcGVlciIgKHR5cGljYWxseSB1c2VkIG92ZXIgbXVs dGlwbGUgbGlua3MpLiBJcyBpdCBpbnRlbnRpb25hbCBieSB0aGUNCiAgICA+IFJPTEwgV0cgPyBE aWQgSSBmYWlsIHRvIHVuZGVyc3RhbmQgdGhlIHB1cnBvc2Ugb2YgdGhpcyBkb2N1bWVudCA/IChx dWl0ZQ0KICAgID4gcG9zc2libGUgb2YgY291cnNlISkuIEkgYW0gYWZyYWlkIHRoYXQgbWFueSBw ZW9wbGUgd2lsbCBpbnRlcnByZXQgdGhlDQogICAgPiAicG9pbnQtdG8tcG9pbnQiIGxpa2UgbWUu DQoNCiAgICBUaGF0IGlzIHRoZSB0ZXJtaW5vbG9neSB0aGF0IGlzIHVzZWQgdG8gZGVzY3JpYmUg dGhpcyB0eXBlIG9mIHRyYWZmaWMNCiAgICBmbG93IGluIFJQTCAtLSBzZWUgcmZjNjU1MC/CpzQg KFRyYWZmaWMgRmxvd3MgU3VwcG9ydGVkIGJ5IFJQTCkuDQoNCg0KICAgIEFsdmFyby4NCg0K From nobody Wed Apr 21 04:05:33 2021 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 8EC013A209A; Wed, 21 Apr 2021 04:05:28 -0700 (PDT) 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 qBFgdIZB0w3T; Wed, 21 Apr 2021 04:05:24 -0700 (PDT) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 60D0C3A209B; Wed, 21 Apr 2021 04:05:23 -0700 (PDT) Received: by mail-ed1-x534.google.com with SMTP id j12so23817351edy.3; Wed, 21 Apr 2021 04:05:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=rGX4o0UGHEuZhxcpYRYyXaryiRapGLTY9hxtqYYHvMY=; b=Zd6RSUvovsW5viyBBE1cycSTIz0ezkGdV2FH1ihZTYwVQW6KgrAoiap2fWzLVm60YB mGCn1sY/DRLlGF+8uoQYQL76bybMjj+nRKUrIMrFl+IpHmSlRo6QumI6rIplSGuZ9m+X DAZemXVzQOKbDx3cjdwipMi9LJlNZVYdacf6ffUwCjv8zlbYVyoRvEitU3T7UiqoZg0k GKOgIjT/Hm/XceWVYIzhbIgzR7jF5MHn6VCWHpHP9qwtDJKuXrjFfg1H1SD/EX+JZzJj vdyufvKDwwc5C64+8d/I7zaE37IJD3+cVTxNTm9bc9W3VVRBgZONCDsysNVVAfLBo5cC zL2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=rGX4o0UGHEuZhxcpYRYyXaryiRapGLTY9hxtqYYHvMY=; b=nfGxOovSJdtvgLBjM3Mb7liYb63Lnap89d/lZdtOxzSLpG/uz+2gj3Hr6y3LDg1DhH IreZUWU32iE95y3seU1pis+jGQ7CxYSpCndulwxjB0WffWFuo7SMPp1wsewlZ9wDQ9GP m5GanIPaZxEjTKBIgzoYcM7Rv/BWOBlI2lwAJ0hI99bi+CV4t2hfvz1JEgThiKO88/X2 D10ls9hV3sc4Dk0ozesbLwsiga/5itUMr+E9h9jkKsGVo9Fw63Gxo/7u1T+5UFG9nzAw NiBBBBTAu7vSFgvc7KLwbYYtbQVxlt0KISCif+Ym0GAHcQJFMDh+wiGHTsET2zgAXhku 2jiQ== X-Gm-Message-State: AOAM531oNs+mSTjT4Sovx/LpJazenzX0A01iGdt4pFQUOnCLWMEBFvif E01KKB3Wg/51s7UyJ0drN6x44YvmtdGn7+6hyhsbm4CeJ5tVOA== X-Google-Smtp-Source: ABdhPJzx9/UJpcEBhsOqBfkdSQu0RdSKcGHTRNZIlCFoBV4cm83cDRTnt27NQfRZjs2UAB23tv3wlV+RabBQsaZP+xo= X-Received: by 2002:aa7:d596:: with SMTP id r22mr11254081edq.344.1619003120598; Wed, 21 Apr 2021 04:05:20 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 21 Apr 2021 04:05:19 -0700 From: Alvaro Retana In-Reply-To: <29EDF026-9741-4864-AC0C-E8375E402D4C@cisco.com> References: <161899828182.30762.17925223604861378275@ietfa.amsl.com> <29EDF026-9741-4864-AC0C-E8375E402D4C@cisco.com> MIME-Version: 1.0 Date: Wed, 21 Apr 2021 04:05:19 -0700 Message-ID: To: =?UTF-8?Q?=C3=89ric_Vyncke_via_Datatracker?= , "Eric Vyncke (evyncke)" , The IESG Cc: "draft-ietf-roll-aodv-rpl@ietf.org" , "roll@ietf.org" , "roll-chairs@ietf.org" , "consultancy@vanderstok.org" , Ines Robles Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Roll] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-roll?= =?utf-8?q?-aodv-rpl-10=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 21 Apr 2021 11:05:29 -0000 On April 21, 2021 at 6:51:06 AM, Eric Vyncke wrote: =C3=89ric: > - the P2P naming... The =C2=A74 of RFC 6550 indeed uses this really unusu= al > meaning for point-to-point :-( May I suggest the document authors to add = an > explanation on this semantic in the terminology as well as in the abstrac= t > (as it needs to stand by itself) ? It's not unusual for RPL networks. ;-) The terminology section already includes an entry (P2P). =C2=A0Is that enough or do you think more is needed? For the abstract, how about adding this as the second sentence (which is similar to what is in the rfc6550 abstract)? =C2=A0 =C2=A0A P2P traffic flow is one between devices inside the LLN. =C2=A0 =C2=A0[Note that the first sentence already has the expanded version= of P2P and =C2=A0 =C2=A0LLN.] Thanks! Alvaro. From nobody Wed Apr 21 04:07:09 2021 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 0D4493A20A9; Wed, 21 Apr 2021 04:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.918 X-Spam-Level: X-Spam-Status: No, score=-11.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=ixc93h24; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=OzLICmuw 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 irU3hxFb61aQ; Wed, 21 Apr 2021 04:06:58 -0700 (PDT) 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 20B0B3A1C58; Wed, 21 Apr 2021 04:06:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3372; q=dns/txt; s=iport; t=1619003218; x=1620212818; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5/MVH27TL98yAjGwNJJg21IbP0zyqTIVXD5VVyUiFk0=; b=ixc93h24un09DnkkkIOHYVX4qEkm/8Zqww4vYhMPTojvufF/aeRWz9V4 cYkgkcory3cdGXGCphYtzoYkadUgpt77XVm1BxRJkq/Wv5gLLjJl7eb1x 0gDbZCw0Y+yqRBY5J+WTtSePfr1nYSLXWCGeUaixpu8p8eLNQFMw/+rjF 0=; IronPort-PHdr: =?us-ascii?q?A9a23=3AF/h0xBQeVyQamh3Xn1SSDzuiA9pso03LVj590?= =?us-ascii?q?bIulq5Of6K//p/rIE3Y47B3gUTUWZnAg9pFhvbY9af6Vj9I7ZWAtSUEd5pBH?= =?us-ascii?q?18AhN4NlgMtSMiCFQXgLfHsYiB7eaYKVFJs83yhd0QAHsH4ag7Tr2G8qzkIF?= =?us-ascii?q?Ua3OQ98PO+gHInUgoy+3Pyz/JuGZQJOiXK9bLp+IQ/wox/Ws5wdgJBpLeA6z?= =?us-ascii?q?R6aykY=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3A4NMfR6krFQ/3dYztGpR36LJuJxzpDfM0jm?= =?us-ascii?q?dD5ilNYBxZY6WkvuiUtrAyyQL0hDENWHsphNCHP+26TWnB8INuiLNxAZ6LZy?= =?us-ascii?q?OjnGezNolt4c/ZwzPmEzDj7eI178ldWoBEIpnLAVB+5PyU3CCRGdwt2cTC1a?= =?us-ascii?q?iui/vXwXsFd3AVV4hLxW5Ce2GmO2dxQxRLAod8MZKa6NZOqTbIQwVnUu2QAH?= =?us-ascii?q?4ZU+/f4+DRnJX9bhIcQzIh4g+CjTSngYSKUySw9BEYTj9J3PMe4XHI+jaJp5?= =?us-ascii?q?mLntOa7lvn12HV54lLg9eJ8Lt+LeGFl8R9EESWti+EaItsQKaPsXQZrOSu91?= =?us-ascii?q?owgLD30m0dFutp7Xe5RBDRnTLM3E3a3C8q+zvezzaj8ATeiOjYYB5/NMZbn4?= =?us-ascii?q?JedXLimgkdlfVxyrhC0W7cl7c/N2K8oA3H69LFVw5nmyOPyBJI+4N+/h8vM7?= =?us-ascii?q?c2U7NfoZcS+0lYCv47bV7Hwbo6G+pjBty03ocxTXqmbmvUtmQq4NugUmVbJG?= =?us-ascii?q?b/fmE+u9eY2zUToXZhz0Fw/r1nol488vsGOv15ztWBFp4tuKBFT8cQY644Lv?= =?us-ascii?q?wGW9GLBmvERg+JGH6OIHz8fZt3eU7lmtrS2vEY9euqcJsHwN8Zg5LaSm5Vsm?= =?us-ascii?q?Y0ZgbHFdCO5ptW6RrAKV/NGAjF+4V73dxUq7f8TL3kPWmoU1Y1ifatpP0ZH4?= =?us-ascii?q?n9V+usPolVR9vuN3HnF4oM/wCWYegXFVAuFOku/vorUVOHpczGbqfwsPbATf?= =?us-ascii?q?rVLL3xVTk+XGfyBWYCQSjzKM1M4lvDYA6/vDHhH1fWPmDv95N5F6bXu8IJzp?= =?us-ascii?q?IWC4FKug8JzVS1j/v7cAFqg+gTRg9TMbnnmqS0qS2d5mDT9VhkPRJbEwJQ6L?= =?us-ascii?q?XkWHVauB8SPyrPAO4+kuTaXVoX8GqMJxd5Qc+TOhVYvU5L9aW+KIHVwzsjBd?= =?us-ascii?q?KhOmeTlGASu3qOUpcZlsS4lIDYU6J9KqxjdL16FA3NGRAwsx1tsn1/ZAgNQV?= =?us-ascii?q?KaCinjkry/jJsfBPjWct51hAvDG78OlVvv8WGn4e0/THoSWDCjFfONiQE1Xj?= =?us-ascii?q?xOmxla6KkEmoeNnj6pNEoyiOk1K0d3dWySGb5KZT71Prl8q/TOQkVQRX3PrS?= =?us-ascii?q?GGgxszE1Cah3k6tyjEF2moXt3lRnBaoWtV16729kgcTBTvQ2tALlZgsYN8Em?= =?us-ascii?q?zavG1UyuHjXNvv70KhLn0f3+oaLDbJJRwVLw8G/aHp6Del3BCfCH4h2pIiet?= =?us-ascii?q?b4MY1mWbTS1nSxQbf4yZ0uF+NI/ZpjKdDluvIKV+XaYAOOMDbkEYoSqn6oj2?= =?us-ascii?q?dgNy9upHY+l/T0nBXj8WijxXY6ReHfOVJ8WtggUp6hxnmhQ/aDy5Nii90p+e?= =?us-ascii?q?O2L2Xqc9aDoJunIgJrO1fWoWSsSfsvpo0RtaUutKFrF52eVTfTznlI0FE/K8?= =?us-ascii?q?jz/XluDJhT8fTEOoV1edYVdD8c9l01lM6XJE9uqxfoGIYFDBkQpm6eO8nM76?= =?us-ascii?q?vDqLIpDEHErAzsOUOH+ykY+/veRSOM2bMTFqpYGxUZVGEsrHB5uO+SfYzZDw?= =?us-ascii?q?unM/tO+1e3KXexer5QQqrtI8Rbkj9qp9WT2+OHfSvx3w7d+SZhKqVV6mC9XI?= =?us-ascii?q?e8BhmPFeMgya3yBX2cxq+xpMi9gzf8RWHlNwAWhYhZeVcRacoGgD84l4Ez2j?= =?us-ascii?q?WzTKuyok9NqSoo3Rh30lr2no6h6yPHGEsDNwvTiJBfRyNSPXiFlt6ty5nS6F?= =?us-ascii?q?3tpDxenYDeH0JRdMxUE9ceToLrPz5jQPJgyIKA7u4qmGBfex8gAG43lSDl0+?= =?us-ascii?q?5n1bm/3u/OW+eKMwafBXsRvThfBoB1mSQ3qWZPN8imhKjNFzkqKg=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CsAAD4BoBg/4kNJK1aHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUAFAQELAYFSUQd3WjYxC4Q4g0gDhTmIcwOBDJg1gS6BJQN?= =?us-ascii?q?UCwEBAQ0BAR0LCgIEAQGEUAIXgV4CJTYHDgIDAQEMAQEFAQEBAgEGBHEThVA?= =?us-ascii?q?NhkQBAQEEAQEhEQwBASwLAQsEAgEIEQQBAQECAiYCAgIlCxUFAwgCBAENBQi?= =?us-ascii?q?CaoJVAy8BAwudOgKKH3qBMoEBggQBAQaBNwMNQYMxDQuCEwMGgRAqAYJ3hAu?= =?us-ascii?q?CQB2DdiccgUlCgRNDgik2PoIeQgEBAgGBPyCDFTaCK4MuBFECUAsgBBlpEWK?= =?us-ascii?q?QYYM3lHKRZQqDDYlrjW+FTRClCIUUkA2LcZdQAgQCBAUCDgEBBjWBJgcsgVl?= =?us-ascii?q?wFRohgmlQFwIOjh8MFhWDOYUUhUlzOAIGAQkBAQMJAXuLAwGBDwEB?= X-IronPort-AV: E=Sophos;i="5.82,238,1613433600"; d="scan'208";a="877894641" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Apr 2021 11:06:55 +0000 Received: from mail.cisco.com (xbe-rcd-001.cisco.com [173.37.102.16]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 13LB6tdh021141 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 21 Apr 2021 11:06:55 GMT Received: from xfe-rcd-002.cisco.com (173.37.227.250) by xbe-rcd-001.cisco.com (173.37.102.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Wed, 21 Apr 2021 06:06:55 -0500 Received: from xfe-rcd-002.cisco.com (173.37.227.250) 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.792.3; Wed, 21 Apr 2021 06:06:55 -0500 Received: from NAM11-BN8-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.792.3 via Frontend Transport; Wed, 21 Apr 2021 06:06:55 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NQHSfvmnav5KS1jzquveA1tm8nIfIzajKFm+1dlUf3cNSFwItViYUaFC/S+GoL94oOjXc7HJa/uUh1S2N332+WRnz04j8u59LqJtuHSzZrvLQbQ7Rgkh1bfic+UbhoSgBSIPwGuOKmfb+KXtBTDtXLr0XU/RLJRMLpLAy/W13whNemP/tTporodP0fma80EuD7UFnhK8TlopOTDlMzpLxqSmCcebqgXxcC8WoG8YOoAcRyjfbhQ3BriCvq/jhDr2PoEqiRXw+H/TN2Vmg5D+VN2Eo9YdxzwJooZvL00WUUVMk/ab6L38kujAre0DrLqoRhTAzjpyactPHfvWvy/cHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5/MVH27TL98yAjGwNJJg21IbP0zyqTIVXD5VVyUiFk0=; b=cSzYUpTM3E9gNTyAb2E6AsApkxNgPe7WyTXirQPYFWprcvA9Bz7dWdRMCrpax4Zg7a1Yl9wK+PrRmoQ0TpJGAPNFewumwc8RPBZ2cpiNVugnPLUYINoT07Wzy/iFZN37DG6hauiDkqSr6ZC3Yh7S3iYYxEzUza8OCFXPyFnXHNED0JeMU/vJfCAPjhGCXveL0g2ZO0R9Zuqi+O2QQsx6MyrxjG76OBQIW7oRWOn5orF0Dumrt3RbM36iF6w1zdpiK/eVkLB7PaYAuijWZlCR57KRiWKlMwRcHz8gWUVudOCBWWZC6nq1gmR9ZO0WkdjRBL4+MCZkIx8nyEasDZygpQ== 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=5/MVH27TL98yAjGwNJJg21IbP0zyqTIVXD5VVyUiFk0=; b=OzLICmuwHstX9nsSePuq0jx7L7sgbMeUnzqgm9qsJ9obL15TaZthmyxmQ9J/PX77hszIyLXn0X0PPc1etrxJflS/RGKjo5drW3qYasjLbYeFNMtnhAoWjLoptxCBjVCxOKBDacNAj0pZ5NPhKdknwDqSgA2X1S+w02rB8azEIts= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by CO1PR11MB4884.namprd11.prod.outlook.com (2603:10b6:303:6c::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.21; Wed, 21 Apr 2021 11:06:54 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::cd01:ffc9:6592:b1d5]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::cd01:ffc9:6592:b1d5%6]) with mapi id 15.20.4065.020; Wed, 21 Apr 2021 11:06:53 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks , =?utf-8?B?w4lyaWMgVnluY2tlIHZpYSBEYXRhdHJhY2tlcg==?= , "Eric Vyncke (evyncke)" , The IESG CC: "roll-chairs@ietf.org" , Ines Robles , "draft-ietf-roll-aodv-rpl@ietf.org" Thread-Topic: =?utf-8?B?W1JvbGxdICDDiXJpYyBWeW5ja2UncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYt?= =?utf-8?Q?roll-aodv-rpl-10:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHXNpsdFDXZXvl8Ik29uEtAXbFoh6q+zZag Date: Wed, 21 Apr 2021 11:06:27 +0000 Deferred-Delivery: Wed, 21 Apr 2021 11:06:13 +0000 Message-ID: References: <161899828182.30762.17925223604861378275@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: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [90.118.185.66] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8af84c92-6419-4c47-d664-08d904b5924a x-ms-traffictypediagnostic: CO1PR11MB4884: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zaMfEbjOTCt5LdrRttBK5cWH8JpB0oCgBtwUfHMiiLksrKSoSA7O57eouDCNOWPajNYXIFMkmZjCdFdGnt7JZ1JJ6xaAKq8q6P9b2Bzlq27BJYdzZPqNzCJAXC7VHoZBSKYkvWZW9AbFc2kfHhUqK1AU26+YsQ9ZZagVzenGzqoZmSowGkXbflnS6xuk3yk9y5ngdy0lLZAk1AhV+0YAe+BgQxILGYGoX8WQ/9FD7Uw00Jh3XvuvSwRMym0oKcIcyL5C/800vT50b19wuBeyqkKOh5+T6qr2MkJFJR7T2Gzi8Sc2HrRaCY2nBwM5AslRzc+JbGjeWu+IEISaABLA+jOPDC56BvOnbm1QcTUu1E7v6Vbkasioyu0vTAvqA3fNbut4dBefl/6EqnBdaEvTWMf6BUffEJzi3MO1cxR7ZQKshxICCAuUXA5MrGg2MlJAINc9Z+ADUVlulz4ckOKlrU1/WZd9wFWIxRcwVZewOPRKEv9nWMJoTlSPQEorx+7Wkqw6mR6XAl0kOL4md7ds7GIcCqFQzrxePDRCkmUd/MVftUPrSUWi0fxKd2lG+HSPqejjVmyZqKaBgnrg7GXGhc9f5n9c99kcAuwL5ce4rYJIJwbWS8utFjxxZGh+zF+gmxu7lIo01QjLbLLGfAJyas2DbuzzRzP8teYTQiF/+5E= 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:(39860400002)(366004)(396003)(346002)(376002)(136003)(224303003)(478600001)(9686003)(110136005)(54906003)(316002)(8936002)(66556008)(66446008)(5660300002)(52536014)(76116006)(86362001)(66946007)(83380400001)(33656002)(66476007)(966005)(71200400001)(64756008)(53546011)(7696005)(6666004)(6506007)(38100700002)(4326008)(26005)(2906002)(186003)(55016002)(122000001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?TFl5dTJQem12NWEySGhrZjZUd0xMOUZPZ0hCajZTNnJBZi9HNnBiQmk5dktV?= =?utf-8?B?aWVvYlRsVmxpdWFpbldiUml5S3IwVWI0ZmNJYy9TSmdSZzk5MnNYcWhUMHkv?= =?utf-8?B?QnBxOXBReG10KzVQOUYzVmRXSjU2YllOZ25qemRuTWEybmsyV1hWQzNiWE5J?= =?utf-8?B?YzZuYVVobXJFdXUrWGtORUJ6eDg5OWZTUHdWSDJnNWlxOU0rSHR5d2x2dUgx?= =?utf-8?B?a2tpTGpwZGc2b3VseU9HUTZIVFMzaWtCbS9mZ3ZzZktIc21tZ2ptUWVOSzE3?= =?utf-8?B?UWhxN3JBbnNpVUJiTFh2bEZnREw4d2ltdDlvUDd0VHRhdlhDTzZTRTJtNkZQ?= =?utf-8?B?R0ZzbG1leW0zMkR2bExpdWVUR3NDZDhFKzFhNHU1ZTdVL2JoMzJPb0ZIRENW?= =?utf-8?B?ZVRDT0U4ZDArbDlVYytZZ2YvamxpUGdMVnJ3eXlqRnRuaWJNN3kyOFpvT2ta?= =?utf-8?B?QTRhazh6b1NCR1hDQW5lK3VJYkNoOTkzKzN3VkhkN25QdUY5Y2xGbHJMMnAz?= =?utf-8?B?cFRoSXZYTFRrVlBwdEtZTnNnV0lLdXdVT2hJaHBFTTRtS3Fmall0RnlBVEdD?= =?utf-8?B?RjFycUxpUWxja2FaUWRVMTBMalNXR1FMMU91b0ovL2czc2NoWGVBenBwbWRp?= =?utf-8?B?VGYvenZYdlMwemZSYjhZSjNESWluUG53Uk55YXRvdUFjV28weCttOTJMSkZX?= =?utf-8?B?U3dHMjFPaHB2V1dubFQ2b0FhdTJQL1VTYU9wYmozdHEvbEFLLzVrMU1SbjZE?= =?utf-8?B?UzBoUmJKbDlyMXRGNkcxbnhtaWRQY3llWlZCaTEvZDBkem5TbVF3SHF4WkR2?= =?utf-8?B?WVpuZGp5dUFOYXRoYzRWT2h1a05UN1FROHE2c2JYYmJaejNXakZqYzhucnh2?= =?utf-8?B?ZTBnVWNZZjlrakhNR1RpbG9pTDBuczMxVkdrYkdCSGh3ZzlpZEhXQm90TGpZ?= =?utf-8?B?d0VhSWtlSnB3SHRuNjdKNUNBKzU0WGx1cGNreCt6QTAvcVl1TlhvVHE1T3F1?= =?utf-8?B?ZlV3WXp3YktFK2E2RCtSL0tST2o3aTlBWUNXdXJFMFNZaDhkQUtBbm1Kd0w3?= =?utf-8?B?Z1hjWm9VMHl0OFZZY0dpMEZ6Y1VMZkt3THE0U3k2NnFsQ3Z0K3ZWSmpReno4?= =?utf-8?B?VUdaaVBXM1hlSWUyUDM5QzZwKzNpOHJaaC9jSE9hUjhTbjRWS0x2elB1Q214?= =?utf-8?B?TkxpSm1qaDNDSlZ0a29IMnhFdVpUZkdXRlRtR1ZiZmxKNEx2VlBIZlQzL3Jr?= =?utf-8?B?M1FhYUNoSXoxd3F5K0dBUGx6MCtSZjcrZkwxNysxMEZyOXBIdGhxTDd6TFIv?= =?utf-8?B?OXd4aG15WUZ3WmtRTWVwV0ZTVCszYVordDQrRDhQYWN1RGNRSmJsK01MV296?= =?utf-8?B?VkhqcGtkN2djd09TVkd2ZEIzRDFCOHdrUG40NDBaLy9mTVpBOFEydHM3RXli?= =?utf-8?B?Wms0L2FaSXFYQXU2eU14TVpZSms0TDdFWWtpeDNzVUh0VXI4bDNXZlB5OEFE?= =?utf-8?B?bFAraW80UTNjTmNmVW1ORG5xcjA2YXFRRE5oQm42QkxYdEdVVUNuUnV0N0ww?= =?utf-8?B?WHBkemQ2VUYzbFBObVhpZVNLcW1JL2ZKUWtVNW1YUXNNNzlTdXVyZ3h1ZnBR?= =?utf-8?B?VThaSWZsUlR1OXNlMFR0Q3Z0YXduMTNpaWhFWUt1RGNYYkhTRENaL3FuTTcx?= =?utf-8?B?SThjM0tVRitvQzFJeXlSZFdZQ21kZk1CUnRtWXBhZU5hNWdteSs1bmxFMnZ2?= =?utf-8?Q?EbnI4O6Llky6koNS12y2253vWtgqB00YzAxsz2S?= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 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: 8af84c92-6419-4c47-d664-08d904b5924a X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2021 11:06:53.8480 (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: 30za3s4J2Gj/EiH93hnuFDufySWtwAtnHvZN578WMSFWBPHF1E+5sKOS34NtO0RVmK3TenDI6NwXtH+0dvV7NA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB4884 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.16, xbe-rcd-001.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [Roll] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-roll?= =?utf-8?q?-aodv-rpl-10=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 21 Apr 2021 11:07:03 -0000 VGhhbmtzIEFsdmFybyENCg0KV2UgdXNlIFAyUCBpbmRlZWQ7IHNlZSBhbHNvIHRoZSB0aXRsZSBv ZiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjk5NyAiUmVhY3RpdmUgRGlzY292ZXJ5 IG9mIFBvaW50LXRvLVBvaW50IFJvdXRlcyBpbiBMb3ctUG93ZXIgYW5kIExvc3N5IE5ldHdvcmtz IiB0aGF0IHRoaXMgaXMgc3VwcG9zZWQgdG8gZXh0ZW5kLg0KVGhpcyBpcyBhcyBvcHBvc2VkIHRv IFAyTVAgYW5kIE1QMlAgbW9kZWxzIHdoaWNoIGFyZSB0aGUgbW9zdCBjb21tb24gcGF0dGVybnMg aW4gTExOIG1lc2hlcy4gDQoNClRha2UgY2FyZSwNCg0KUGFzY2FsDQoNCg0KDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFJvbGwgPHJvbGwtYm91bmNlc0BpZXRmLm9yZz4g T24gQmVoYWxmIE9mIEFsdmFybyBSZXRhbmENCj4gU2VudDogbWVyY3JlZGkgMjEgYXZyaWwgMjAy MSAxMjo0Mw0KPiBUbzogw4lyaWMgVnluY2tlIHZpYSBEYXRhdHJhY2tlciA8bm9yZXBseUBpZXRm Lm9yZz47IEVyaWMgVnluY2tlIChldnluY2tlKQ0KPiA8ZXZ5bmNrZUBjaXNjby5jb20+OyBUaGUg SUVTRyA8aWVzZ0BpZXRmLm9yZz4NCj4gQ2M6IHJvbGwtY2hhaXJzQGlldGYub3JnOyByb2xsQGll dGYub3JnOyBJbmVzIFJvYmxlcw0KPiA8bWFyaWFpbmVzcm9ibGVzQGdvb2dsZW1haWwuY29tPjsg ZHJhZnQtaWV0Zi1yb2xsLWFvZHYtcnBsQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbUm9sbF0g w4lyaWMgVnluY2tlJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXJvbGwtYW9kdi1ycGwtMTA6DQo+ ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+IA0KPiBPbiBBcHJpbCAyMSwgMjAyMSBhdCA1 OjQ0OjQzIEFNLCDDiXJpYyBWeW5ja2Ugd3JvdGU6DQo+IA0KPiANCj4gw4lyaWM6DQo+IA0KPiBI aSEgwqBUaGFua3MgZm9yIHRoZSByZXZpZXchDQo+IA0KPiBKdXN0IHJlcGx5aW5nIHRvIHRoZSBE SVNDVVNTLg0KPiANCj4gDQo+IC4uLg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBESVNDVVNTOg0K PiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4gLi4uDQo+ID4gU3BlY2lhbCB0aGFua3MgdG8gUGV0ZXIgVmFu IGRlciBTdG9jayBmb3IgdGhlIElvVCBkaXJlY3RvcmF0ZSByZXZpZXc6DQo+ID4gaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvcmV2aWV3LWlldGYtcm9sbC1hb2R2LXJwbC0xMC1pb3Rk aXItdA0KPiA+IGVsZWNoYXQtdmFuLWRlci1zdG9rLTIwMjEtMDQtMTUvDQo+ID4NCj4gPiBUbyBi ZSBob25lc3QsIHRoZSBsYWNrIG9mIHJlcGx5IHRvIFBldGVyJ3MgcmV2aWV3IGJ5IHRoZSBhdXRo b3JzIG9yIGJ5DQo+ID4gdGhlIFdHIGEgbGl0dGxlIGJpdCBzdXByaXNpbmcgKHRoYW5rIHlvdSB0 byB0aGUgUlRHIEFEIHRob3VnaCkuDQo+IA0KPiBJJ2xsIG1ha2Ugc3VyZSB0aGUgYXV0aG9ycyBy ZXBseSB0byBQZXRlciBiZWZvcmUgd2UgbW92ZSBmb3J3YXJkLg0KPiANCj4gW0JUVywgUGV0ZXIg d2FzIHJvbGwgY2hhaXIgd2hlbiB0aGlzIGRvY3VtZW50IHdlbnQgdGhyb3VnaCBXR0xDLiA6LSkg V2UncmUNCj4gYWxsIHZlcnkgZ3JhdGVmdWwgZm9yIGhpcyB3b3JrLl0NCj4gDQo+IA0KPiAuLi4N Cj4gPiA9PSBESVNDVVNTID09DQo+ID4NCj4gPiBBIHZlcnkgdHJpdmlhbCB0byBmaXggYnV0IEkg ZG8gd2FudCB0byBoYXZlIGEganVzdGlmaWNhdGlvbiBvZiB1c2luZw0KPiA+ICJwb2ludC10by1w b2ludCIgKHR5cGljYWxseSB1c2VkIG92ZXIgdGhlIHR3byBzaWRlcyBvZiBhIHNpbmdsZSBsaW5r KQ0KPiB2cy4NCj4gPiAicGVlci10by1wZWVyIiAodHlwaWNhbGx5IHVzZWQgb3ZlciBtdWx0aXBs ZSBsaW5rcykuIElzIGl0IGludGVudGlvbmFsDQo+ID4gYnkgdGhlIFJPTEwgV0cgPyBEaWQgSSBm YWlsIHRvIHVuZGVyc3RhbmQgdGhlIHB1cnBvc2Ugb2YgdGhpcyBkb2N1bWVudA0KPiA+ID8gKHF1 aXRlIHBvc3NpYmxlIG9mIGNvdXJzZSEpLiBJIGFtIGFmcmFpZCB0aGF0IG1hbnkgcGVvcGxlIHdp bGwNCj4gPiBpbnRlcnByZXQgdGhlICJwb2ludC10by1wb2ludCIgbGlrZSBtZS4NCj4gDQo+IFRo YXQgaXMgdGhlIHRlcm1pbm9sb2d5IHRoYXQgaXMgdXNlZCB0byBkZXNjcmliZSB0aGlzIHR5cGUg b2YgdHJhZmZpYyBmbG93DQo+IGluIFJQTCAtLSBzZWUgcmZjNjU1MC/CpzQgKFRyYWZmaWMgRmxv d3MgU3VwcG9ydGVkIGJ5IFJQTCkuDQo+IA0KPiANCj4gQWx2YXJvLg0KPiANCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gUm9sbCBtYWlsaW5nIGxp c3QNCj4gUm9sbEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3JvbGwNCg== From nobody Wed Apr 21 06:20:45 2021 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 5D5713A2775; Wed, 21 Apr 2021 06:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.617 X-Spam-Level: X-Spam-Status: No, score=-9.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=HniR/gzK; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=N4EuVhAZ 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 jfmQ890Wjs4p; Wed, 21 Apr 2021 06:20:36 -0700 (PDT) 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 CE06B3A2774; Wed, 21 Apr 2021 06:20:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2674; q=dns/txt; s=iport; t=1619011236; x=1620220836; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ChkGMjyis8ty9u4aLIbCB3XHV9o2jQ+KqXCvNPSgLKA=; b=HniR/gzKf2QFM0ouVpaEuqKNk0bgzATh6JyGzONPF6eAYoPEt3/M4W9G SE7VvelzmtSU33QhVBZ2QPRSdPERsy7p57wVnx6ZtU6gU3BqIMRq8G/oC U4IYEADsVodVHFHDaoA3//GvOnsvXmBNBsKjRMZjja+tpV56831yqiFDz g=; IronPort-PHdr: =?us-ascii?q?A9a23=3AHd84zR9cvIFnHP9uWNHoyV9lXQAupqn0MwgJ6?= =?us-ascii?q?5Eul7NJdOG58o//OFDEjd1iiVbIWcPQ7PcXw+bVsqW1X2sG7N7BtX0Za5VDW?= =?us-ascii?q?lcDjtlehA0vBsOJSCiZZP7nZiA3BoJOAVli+XzoPk1cGcK4bFrX8TW+6DcIE?= =?us-ascii?q?UD5Mgx4bu3+Bo/ViZGx0Oa/s53eaglFnnyze7R3eR63tg7W8MIRhNgKFw=3D?= =?us-ascii?q?=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3A/CEHWaHz+RWUpc65pLqF+ZXXdLJzesId70?= =?us-ascii?q?hD6mlYcjYQWtCElsyogfQQ3QL1jjFUY307hdWcIsC7IE/03aVepa0cJ62rUg?= =?us-ascii?q?WjgmunK4l+8ZDvqgePJwTXzcQY76tpdsFFZ+HYJVJxgd/mpCyxFNg9yNeKmZ?= =?us-ascii?q?rY+tv25V0Fd3AMV4hL6QBlBgGHVm1aLTM2RaYRPpya+8ZBun6EcXMYcsy0Ch?= =?us-ascii?q?A+Lpb+jvfMk4/rZgNDOgUu7xOAgSjtxLnxFRWZ2Rl2aUIN/Z4J92/Znwvlop?= =?us-ascii?q?iyqv3T8G6c60b/zbRz3OHgxNxKGdCWhqEuSgnEpw60aO1aKsa/lR8vpuXH0i?= =?us-ascii?q?dOrPDtpFMaM913+zfteAiO0GfQ8i3B9Bpr1HP401+fhhLY0I7EbRY3EdBIi4?= =?us-ascii?q?4cUjax0TtbgPhG3KhG332UuvNsZHuq9kmQlru4NS1CrUa6rWEvluQelRVkIP?= =?us-ascii?q?YjQYVMpo8S9l49KuZnIAvG6ZsqGOQrLMbQ6Oc+SyLjU1nlv3JiyNHpY3IrHh?= =?us-ascii?q?3ueDl6huWp1VFt7RRE5npd4PZasmYL9Zo7RZUBzf/DKL5UmLZHSdJTRb5hBc?= =?us-ascii?q?8aKPHHT1DlcFbpCia/MF7nHKYINzbmsJjs+og44+msZdgh0IYyopLcS1lV3F?= =?us-ascii?q?RCP37GOImr5tlm4xrNSGKyUXDG0cdF/aV0vbX6Wf7NPTCcTkst1++tue8WDM?= =?us-ascii?q?Gee/vbAuMQP9bTaU/VXapZ1Qz3XJdfbVMEVtcOh9o9U1WS5s3RLInnsfHabe?= =?us-ascii?q?bTKLLhHS1MYBKnPlIzGBzIYOlQ5EGiXXH1xDLLXWn2R0D59ZVsVKjWltJjkL?= =?us-ascii?q?QlB8lpiEw4mF657saEJXlpqaotZnZzJ7vhj+e+rWmy9mDY8nVxNnNmfx1oyY?= =?us-ascii?q?Sld0kPiR4BMkvyf7pGkc6YY3pu0HyOIQI6SdjXHg5Zr1F+4rm2MJSU2CAnB7?= =?us-ascii?q?ucQySnpkpWgEjPY4YXm6WF68ugUIg/FIwaVKt4EhiOCwZ4gh9wqGBIaBYNQ0?= =?us-ascii?q?jWEj+Gs9T+sLUkQMXkM/VsigaiJsBZ7U/FvUKHvMc1Wz8wRDi1S/Oahg4oWh?= =?us-ascii?q?tZjlB86LUknbKFgDqjQFFP3dgQARlpUiC3CKgDJBmZbI9U84qbCT1YfCOvv3?= =?us-ascii?q?imrD0dPkDt7F4fg2T9Kzb8Q4C6PnNt/lZC0qjr91tocH66ZEwYUAEnjaRNUU?= =?us-ascii?q?Lbp310zeiHIo203mf5UCpd/sgtdBfYfDAVPgRig+qS6SfQsjODGXI6r69eYd?= =?us-ascii?q?D1BKg/cr3Vx3OmIJCJk6ZDBPNP4JN5LrnVw502eP6EdxTQJD31DP5B4X3nml?= =?us-ascii?q?81fCZzs3UqivXuxVns63W5xmc2Bb7ILE1hXKxzGaDR00H0A/KJ2o5+l9Q7oK?= =?us-ascii?q?+5NXjwcMePzcjsHnR+AwKWpW69VOczr59I+ao0qbtoBpHeFT/FzmtO0hl7LM?= =?us-ascii?q?D6kiolMelGyaGEPo9kZMoJfS1FulIvidSUNUMu9hXsHfVWRyBls1bLe9eSp7?= =?us-ascii?q?bYo7smBUOM4AP2JFmE6iVYu/PIRTGK27IWA785SF4mJ3QU+TBn5qePZofQAA?= =?us-ascii?q?Kle6VY8F22PmS0fbVdRKKGcI9g5SpS8pWNhauaZiD40AffsX9nOapI6X+gWt?= =?us-ascii?q?73DwSWG+JEmubKd2ikk++v+oq0gzj2QzfgNBhdio1BaEAKbsNMzjMll5Y61y?= =?us-ascii?q?CuSqrx5kIp+mEulg1PhxrowMyh5myeAERNdQveiZ9SVSNIMneJgd/emNLonE?= =?us-ascii?q?jV8XxAw93bCExUfttSANAeQYj8Mjd2JaErzcqV1rtqhj4GfQwnAGE9gi3sxu?= =?us-ascii?q?9q3b+23/PJRu3pYE2YT24p6HpCHY57nisitGFGfYy/9PuGE3AqKtI=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BMAAA0JoBg/4oNJK1UBhwBAQEBAQE?= =?us-ascii?q?HAQESAQEEBAEBQIE+BwEBCwGBUlEHgVE2MYRDg0gDhFlgiHWKMo8PgS6BJQN?= =?us-ascii?q?UCwEBAQ0BATICBAEBhFACF4FeAiU0CQ4CAwEBDAEBBQEBAQIBBgRxE4VQDYZ?= =?us-ascii?q?EAQEBBCMRDAEBKQ4BCwQCAQgOAwMBAgMCJgICAh8RFQUDCAIEAQ0FgnGCVgM?= =?us-ascii?q?vAZ11AoofeoEygQGCBAEBBoVCDQuCEwmBECoBgneEC4JAhBMnHIFJQoETJxy?= =?us-ascii?q?CXz6CHoIUEIMXNoIrgy4EgVIZaZRJQpRykQpbCoMNl1YEhTgEIaUIhRSQDY8?= =?us-ascii?q?KlDcCAgICBAUCDgEBBjWBHzqBWXAVZQGCPlAXAg6OHzeDOYpdczgCBgEJAQE?= =?us-ascii?q?DCQF7jBMBAQ?= X-IronPort-AV: E=Sophos;i="5.82,240,1613433600"; d="scan'208";a="861855585" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Apr 2021 13:20:04 +0000 Received: from mail.cisco.com (xbe-rcd-006.cisco.com [173.37.102.21]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 13LDK2Yc005330 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 21 Apr 2021 13:20:03 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xbe-rcd-006.cisco.com (173.37.102.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Wed, 21 Apr 2021 08:20:02 -0500 Received: from xfe-aln-004.cisco.com (173.37.135.124) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 21 Apr 2021 09:20:01 -0400 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.792.3 via Frontend Transport; Wed, 21 Apr 2021 08:20:01 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Qg5ZvXto5lY6fKBzcBRGBgO8vzRHqLz5cSVpJl/Vz/Xhr5VGsOM2CR2BEq2zKpTN0b2V8pI97/rGii6FW6nrwaLqxGyoUGZe10PZrO8YyzFLjynmksV1bBuobCILHji+kSYnwfG6JrHzvaCUfuROc+o3UGJT/TxWmE8hOgXd+Qwvvm9LnU8NLaOGEqSVUYTjtbAVmW0HadvGGmHTxiH4sZ92vIZMtIs4VfEUSXfinPPrpqMwQvlGwHoftxlwHPvOOMTn0OPZeh2Pmus5SaDBabHGcNw40tosUGjfTpIZ2uwwoZpYkoCxdybG1VrDr351O7EgdmhN7vKiDSDrp9GLLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ChkGMjyis8ty9u4aLIbCB3XHV9o2jQ+KqXCvNPSgLKA=; b=auBK2TRDX3hFsXHSqlSpJRht+vky0vyc8IODvOzxfq50q3orcbihp6N/S4wLHo7sISNsZ9d8qJzwylFgm/3Pm+yQOX/LMat/mXgNTwR2Qr3D9SZbGUTiYsnnju15UlkxxDEpbUlZppDWT6gV4yofgltV+2x2HRCKxg3CwdSPHDu6NMhAkXOYpkFz1rt5NHP3pBQS9tOo3jkGnFRwGbhGNOL/JIDpLEqkPKKvKinqV/hJQ6zA18GxTjjGsDwRVKEaQT5BBoslx1kXjh12UUu3CxCE2B/QnYUcHFgYycsDoE3HNFX7/Ne1daH/UMLC2mkkQL03CFI5LIv5MGVITpJjZg== 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=ChkGMjyis8ty9u4aLIbCB3XHV9o2jQ+KqXCvNPSgLKA=; b=N4EuVhAZH+CyEuZ1/TWaRTV0Wbz5pAoO/ZkwwY4/rxLu3HBRxVIHozmQ/wEYJjtfs5SSAXwoYP/3Evcll33OU/Esev4Ms3p9gpooK1qUY6EBqWvkMyLFGO+fVHEvQ3R2RTg1SWIuH3OZM6dB5QskDzXkwj4GQUqEVw682f1m33U= Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB4840.namprd11.prod.outlook.com (2603:10b6:510:43::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.18; Wed, 21 Apr 2021 13:20:00 +0000 Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::dcdf:3910:b85d:6eba]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::dcdf:3910:b85d:6eba%7]) with mapi id 15.20.4042.018; Wed, 21 Apr 2021 13:20:00 +0000 From: "Eric Vyncke (evyncke)" To: Alvaro Retana , =?utf-8?B?w4lyaWMgVnluY2tlIHZpYSBEYXRhdHJhY2tlcg==?= , "The IESG" CC: "draft-ietf-roll-aodv-rpl@ietf.org" , "roll@ietf.org" , "roll-chairs@ietf.org" , "consultancy@vanderstok.org" , Ines Robles Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXJvbGwtYW9k?= =?utf-8?Q?v-rpl-10:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHXNpMBvYX1IRClB0eUcTFEoYIq36q+yPeAgAAj3ID//+J1gIAARyeA Date: Wed, 21 Apr 2021 13:20:00 +0000 Message-ID: <16F53684-CED1-4F60-B7FC-D9540CFACD82@cisco.com> References: <161899828182.30762.17925223604861378275@ietfa.amsl.com> <29EDF026-9741-4864-AC0C-E8375E402D4C@cisco.com> In-Reply-To: Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.48.21041102 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2a02:578:8557:600:b8ca:60c1:da08:40d7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 65e144f3-accc-4f43-130f-08d904c82aa0 x-ms-traffictypediagnostic: PH0PR11MB4840: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: DdwZxWeLpSZ6Rh57UXQ1hAIEKLuvlXyCmFbu09d75K2FE2U9/9hCOXvAWKD6M/nBrgq2ssr2ktVjn79AHMNWp+F/S+6NqSaPf9HvldabuX2rVK0vAJRfBOJvhdTPXyaUf89SkNpLwkEABTUcFQaLXlNKIHWJAfKZDFvTBPrYnemEGeEkQrI0uCs/VY7vBLZrimNWc9kQlh3qHxVgxMvF+i7xWRJPpeFVGO+47Uwcv3sGXGJDyQYYhBU3M1SipjuYxQ8OF7ufmLruwzc1oey25KUIrQETU0Krm5VuFctzXbue7QdFihsZwdXVJPi0AktyMJxj3b7JiSO7vdQ9EQHh1RXoTi0eLavL99Y43h2Hq2TRPAXXxX/r5+TdvQdGOLhjGtL7CruDeRfOCrnc20/FGaE1hYyNs0BbJrjr6sJBTYmF5nsXR9W/tlzsdy7A4erFPUKywXjaNEPNNCyuATbTPhR7j75+jO2jusTrwr45DWdEX1UVI7SWcd2gjY5TAlruXaNGcAPOl55esnKZ3yHmAfm8genmbFni9xOw1pwGUGnRxogOxlXqYzf5/xFq14Al7O1O4i/JSC7gL6cAbrUqopYoz1IQ2hbhF51Ohjrnyoz42eJhBjYJb73bHFJsY0B5mZWT3wAYHLe27YDdgm8T6WPOb36e8Z1elOMAXwMx1sw= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(136003)(396003)(346002)(376002)(39860400002)(66946007)(76116006)(122000001)(66476007)(2616005)(83380400001)(6486002)(6512007)(4326008)(66446008)(71200400001)(86362001)(38100700002)(54906003)(64756008)(36756003)(6506007)(110136005)(91956017)(2906002)(478600001)(53546011)(316002)(8936002)(5660300002)(33656002)(224303003)(186003)(66556008)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?ZlZDeGtiblhwYUdVYUI1Q0daTUwyc3UzR0dPZ3ozNlB5QUZHcTVKR1hVK0kz?= =?utf-8?B?NVBQNDhoRWxaVTAwVjNBdzZtVzJPOTJadUU1cVZ3ZCtGUUxDS0tldE5haDJt?= =?utf-8?B?Z0NqRGJtenF5NFo3S0FLeFFtN0M0S2h3VjhOcW9uQkN0QzQxdjBPcCtVb2ZO?= =?utf-8?B?S0pZV2NSdllLTzk0Qndibnh1eWsvU2ZxaEdUdVVtTGI1WXBRNnMwSmFVdm9m?= =?utf-8?B?SXBhT2VwcEVNQjhPeDRXRlpuKzVPNEk3ZjI3SmpHQlBMNy9ab25qVUtVbmsr?= =?utf-8?B?dFRPcU5nOFh3aExXcFJkQUV6dUhnN1BEa3lUZy9zNkxEb2kxdEhiNWVha3h2?= =?utf-8?B?b0JyUVA3djdOU3JLMEpLQWpSUnNkODVjQnpISUFGdkJGcENPdUlFSWRwQUll?= =?utf-8?B?Rm1IMkFrcHRqQ041VGVzQXhUcHZKMzVwOGdQUTFqZisxa0tQdXV3SjREWXRy?= =?utf-8?B?RzNrNlQrZjJBTlQrbURqT1J2VjVEWlFqT3NDc2FsYXlPVFhhSHkxaGRFZEoy?= =?utf-8?B?N3ZhT0gyQkozRStCUTlUMGN2OTF1bkNyL01xcGhyR21qVEMvOUpQT2M0Y00x?= =?utf-8?B?cjVNdEo2dFFscFBmMzBxandkdnh2Z1pHN0NtOWFJVWlLREpoVFRSaVF6YkdS?= =?utf-8?B?QlFPdUl5RXE2N0xlWUMrVXYwa1YvNDJ0bVNCOS9rWjdjWVY3U29sU0lqNDZC?= =?utf-8?B?aFpTN1JsMWJESUNZeEk0aXFSQzZScUo5TU9mR005L1lTdEVlaTBQK084M2cw?= =?utf-8?B?NXFPU0ROV1RWQTdUcExUSTdBMFY0ZDdITTJCekdRbUtzUGhORVd0QlRibHNR?= =?utf-8?B?YTdxOVpOZmxDTS8xVUEybXl4VWlNOXJJdTVrdDlXalRKRFozSE9KbEVid2Fj?= =?utf-8?B?dElYTWdnZTJmZFFIUDlzMHJVN29tWU9HQzQ3YVlPN2ZtNG00T29DS2RIa0Yv?= =?utf-8?B?S2NnekphaUkyOEMveXRJTVJ0U1drRFNIZktnYkkvSzNnRjVrMEo1UGZmNm56?= =?utf-8?B?b1MycDlNZG9YR3JpYWdEUG1TMlFYUHkwbDBCcmNwZ0t0dWhCTk5tbTZUVnRQ?= =?utf-8?B?VHVGUHVjWDVncEdDbHdkQlpMbG9qdzJjdWJOMjVEMjZFelp1V1l4YkV6dE9p?= =?utf-8?B?Vmd1T1QxTVZ3M25vRmFpQWJHcFpyR2RJbEhRMFIyUUpCNXdJbFVVZXQzWEZD?= =?utf-8?B?V281ZjdKOFpzY0ZyNzhDSE9HMmRIZjZJN1huTXF4aU5NRkIrSlREQjVuYUxR?= =?utf-8?B?KzVaTXdiUExIRjF1UFlDNyttMDhpQmxzK1FZRktxYnpJekVQa2RDeWlwbjRJ?= =?utf-8?B?eTAwUUx1cktDMzlySW1qek9aNlFZci9ZV1ZZSURxZjc4S2Z6WnIyVEFid0RN?= =?utf-8?B?czBydGJlMGk2Z2FNdmZSLzVmTnJtdXg0VGQzMGNNSFhORitpUlRramhOU2dE?= =?utf-8?B?WmtBUjIyR2s4ZW5uSzlvM3YvUlVpRlV5SzM3dytwdXdBOFhkNlJjL1ZCTCtZ?= =?utf-8?B?bG1IRlBxL2h1YlF2dmVHSkNsTEt4SmMzaG1WT2ZQamc0aytSWlA4NHNOaUs2?= =?utf-8?B?Y0VaRTZ4U2N5NjV3bGdXa2dtK3psSFh2Q1pISExvR0YrVkYxTE5DMkpudmpn?= =?utf-8?B?Zlk4VTlLd1NROURJSzZqbTNYMlh1WE9NOVJkRkloaXNvZW1nLzZ4UDM5dHYx?= =?utf-8?B?bnVZdGdoTlp2OHdBdmZJZHU5RzNPQTF4b3Axb1NObGdLVG9GbFAySTV1Njk5?= =?utf-8?B?UDVWaHo5NFAxVy92ZlBhUHQyVUlhYmZjR2poRlBhdWlsMFo3U3V0V212WDVR?= =?utf-8?B?QitwbWlrd1ZROCt4TjUwTHNZRWtmS2ZrRExUalhYcFJwYjF0ZFNPK0RpRkd1?= =?utf-8?B?MFN0aEk3VVpoM3JhYlh2MThkaG5JTzVzNVVRZFBpV000c2c9PQ==?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <59E66C6865217C4EAF8857271FD662E6@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 65e144f3-accc-4f43-130f-08d904c82aa0 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2021 13:20:00.3037 (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: e4orYujdLF69hbKRHimlJ/mb/6OuQLa6CT8TGQJmwT18eOhJeazAmGiLZ5uWNkKu82d6wldVGQbNZpoxWSmwng== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4840 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.21, xbe-rcd-006.cisco.com X-Outbound-Node: alln-core-5.cisco.com Archived-At: Subject: Re: [Roll] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-roll?= =?utf-8?q?-aodv-rpl-10=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 21 Apr 2021 13:20:41 -0000 QWx2YXJvLA0KDQpUaGUgdGVybWlub2xvZ3kgc2VjdGlvbiBkZWZpbmVzIFAyUCBhczoNCiJQMlAN CiAgICAgIFBvaW50LXRvLVBvaW50IC0tIGluIG90aGVyIHdvcmRzLCBub3QgY29uc3RyYWluZWQg YSBwcmlvcmkgdG8NCiAgICAgIHRyYXZlcnNlIGEgY29tbW9uIGFuY2VzdG9yLiINCg0KV2hpY2gg aXMgYSBmYXIgZmV0Y2ggZnJvbSB1c3VhbCAicGVlci10by1wZWVyIiBvciBzaW1pbGFyIHdvcmRp bmdzLiBCdXQsIHRoaXMgaXMgaW5kZWVkIHRoZSBwbGFjZSB3aGVyZSBJIHdvdWxkIHB1dCBhIG1v cmUgZGVzY3JpcHRpdmUgZGVmaW5pdGlvbiBmb3Igbm9uLVJQTCBleHBlcnRzLi4uICsgYWxzbyBp biB0aGUgYWJzdHJhY3QsIHdoaWNoIHNob3VsZCBiZSBzZWxmIHN0YW5kaW5nIElNSE8uDQoNCkEg cmVwbHkgZnJvbSB0aGUgYXV0aG9ycyBvbiB0aG9zZSAyIHRvcGljcyB3aWxsIGJlIHdlbGNvbWUN Cg0KUmVnYXJkcyAoYW5kIHRoYW5rcyBmb3IgeW91ciB0aW1lKQ0KDQotw6lyaWMNCg0K77u/LS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEFsdmFybyBSZXRhbmEgPGFyZXRhbmEuaWV0 ZkBnbWFpbC5jb20+DQpEYXRlOiBXZWRuZXNkYXksIDIxIEFwcmlsIDIwMjEgYXQgMTM6MDUNClRv OiDDiXJpYyBWeW5ja2UgdmlhIERhdGF0cmFja2VyIDxub3JlcGx5QGlldGYub3JnPiwgRXJpYyBW eW5ja2UgPGV2eW5ja2VAY2lzY28uY29tPiwgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQpDYzog ImRyYWZ0LWlldGYtcm9sbC1hb2R2LXJwbEBpZXRmLm9yZyIgPGRyYWZ0LWlldGYtcm9sbC1hb2R2 LXJwbEBpZXRmLm9yZz4sICJyb2xsQGlldGYub3JnIiA8cm9sbEBpZXRmLm9yZz4sICJyb2xsLWNo YWlyc0BpZXRmLm9yZyIgPHJvbGwtY2hhaXJzQGlldGYub3JnPiwgImNvbnN1bHRhbmN5QHZhbmRl cnN0b2sub3JnIiA8Y29uc3VsdGFuY3lAdmFuZGVyc3Rvay5vcmc+LCBJbmVzIFJvYmxlcyA8bWFy aWFpbmVzcm9ibGVzQGdvb2dsZW1haWwuY29tPg0KU3ViamVjdDogUmU6IMOJcmljIFZ5bmNrZSdz IERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1yb2xsLWFvZHYtcnBsLTEwOiAod2l0aCBESVNDVVNTIGFu ZCBDT01NRU5UKQ0KDQogICAgT24gQXByaWwgMjEsIDIwMjEgYXQgNjo1MTowNiBBTSwgRXJpYyBW eW5ja2Ugd3JvdGU6DQoNCg0KICAgIMOJcmljOg0KDQogICAgPiAtIHRoZSBQMlAgbmFtaW5nLi4u IFRoZSDCpzQgb2YgUkZDIDY1NTAgaW5kZWVkIHVzZXMgdGhpcyByZWFsbHkgdW51c3VhbA0KICAg ID4gbWVhbmluZyBmb3IgcG9pbnQtdG8tcG9pbnQgOi0oIE1heSBJIHN1Z2dlc3QgdGhlIGRvY3Vt ZW50IGF1dGhvcnMgdG8gYWRkIGFuDQogICAgPiBleHBsYW5hdGlvbiBvbiB0aGlzIHNlbWFudGlj IGluIHRoZSB0ZXJtaW5vbG9neSBhcyB3ZWxsIGFzIGluIHRoZSBhYnN0cmFjdA0KICAgID4gKGFz IGl0IG5lZWRzIHRvIHN0YW5kIGJ5IGl0c2VsZikgPw0KDQogICAgSXQncyBub3QgdW51c3VhbCBm b3IgUlBMIG5ldHdvcmtzLiA7LSkNCg0KICAgIFRoZSB0ZXJtaW5vbG9neSBzZWN0aW9uIGFscmVh ZHkgaW5jbHVkZXMgYW4gZW50cnkgKFAyUCkuICBJcyB0aGF0DQogICAgZW5vdWdoIG9yIGRvIHlv dSB0aGluayBtb3JlIGlzIG5lZWRlZD8NCg0KICAgIEZvciB0aGUgYWJzdHJhY3QsIGhvdyBhYm91 dCBhZGRpbmcgdGhpcyBhcyB0aGUgc2Vjb25kIHNlbnRlbmNlICh3aGljaA0KICAgIGlzIHNpbWls YXIgdG8gd2hhdCBpcyBpbiB0aGUgcmZjNjU1MCBhYnN0cmFjdCk/DQoNCiAgICAgICBBIFAyUCB0 cmFmZmljIGZsb3cgaXMgb25lIGJldHdlZW4gZGV2aWNlcyBpbnNpZGUgdGhlIExMTi4NCg0KICAg ICAgIFtOb3RlIHRoYXQgdGhlIGZpcnN0IHNlbnRlbmNlIGFscmVhZHkgaGFzIHRoZSBleHBhbmRl ZCB2ZXJzaW9uIG9mIFAyUCBhbmQNCiAgICAgICBMTE4uXQ0KDQoNCiAgICBUaGFua3MhDQoNCiAg ICBBbHZhcm8uDQoNCg== From nobody Wed Apr 21 13:02:11 2021 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 B3DE03A34A7; Wed, 21 Apr 2021 13:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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=juniper.net header.b=e9W94kaV; dkim=pass (1024-bit key) header.d=juniper.net header.b=JlqLkXi3 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 L8BOjcVsVMab; Wed, 21 Apr 2021 13:02:00 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 254C63A12B7; Wed, 21 Apr 2021 13:01:59 -0700 (PDT) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 13LJoHmp030965; Wed, 21 Apr 2021 13:01:58 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=E/JoAKCD7+jIqOEqN6mETMoocRjQve82mJB8B4ow5tU=; b=e9W94kaV2w8QV/H1hkb3HNul4naxjN/pbRWL1lheCLgtZTZWaGOHvbWM9Fr3JbuPV2RV p2C0p8G1gQnRXc9A/8/OJktR6vDdTqfCFAMCYSVqlyQGY8/zqs/dX5N0nAouM9jvT9EO 5XQLSv8/DC5/rMhW/sduqi9T57KI/tKjJUFnrmnOV0PzPuTUNBfIpVBjIAh9qEJvvMUJ G/UWyVXOtQeO8Pe33i/+9ILundoIQ1SfztW68o41skesfLTCre89Ic5qzuJkJlyQZL95 QaLFDU+PaM+c0wMUy+Cw+VOd7Lqt6r33JXjatFXkDndOdgjtXuLrmEJ5lYqayQzYLFcy Ew== Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2173.outbound.protection.outlook.com [104.47.59.173]) by mx0a-00273201.pphosted.com with ESMTP id 382ac4hvad-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 21 Apr 2021 13:01:58 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R45scHM2qQuL0Rg36sgEK5DKEgTmD5S92yg0DtNBMZkDk3kUOT5/5AIoip4NHQCwudQX3JfyoUuFf0lT4fzIKMf3/HMNop0ILZxan3dzxpWlm1zkKzPZeph31FesEVvLTDGrsGuLW8Qkk0f7zGTCksxIWIYomOG09A5GM5O1hKYkPbDEAzjVcSZnJ3heOjzyvJ8YSLY8C0ezDGL0L2Itxj07FGGyGFQ6E0/JKnFF9FqWp9SnVqMXmNtdxTfScoQrfySf9cuuGaruLWznxE6RVdHf6CHWP6oOKQt5ZMYEkk/fumeM7Al/wP1OFz3R67uND7WnBUb+Ymj0beLLb/spXg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=E/JoAKCD7+jIqOEqN6mETMoocRjQve82mJB8B4ow5tU=; b=lIziR2w1MJBt+wuNqMfQghpj9Nh2w/hlWPEBA0JmSsFCqSdiwNwIEMcxYUPZJsG9ZiNiPWmiex6PbtfrgoJwy6WO5rBJ8vyfVm44qxKdfRVuj4JpwTOVoTyXgj1n4sDXNoocO2XNU6FdEVFkk6QnIOvuLgrBxl++c7mC3RLalT1AmqERQ+IxDZJ6qpQQcTJDzzNLLDW0dxMDUr681fMrSclbZkWAJk8KzL4iI14+JTRKzvL4T+taeRm0O4AWcNTKO6mHwBfi190i6CobrxNz845shDIID0FQ/qxUdKIWCl34QRPt8NvI+LgZB+m9r8KJqX2MSsyRgg8j/iaplHeI5w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=E/JoAKCD7+jIqOEqN6mETMoocRjQve82mJB8B4ow5tU=; b=JlqLkXi3iqnEUko5ZKJOOb6uC+smYgtClyNPlHvO1EiG38AzAEIuYbYxh++IRYWvrzBmI6MPBy8nfZcPZ1yU3wVF7luLf8pOlmfVFlDZyNkqGidriuZfipHiWlMpEc+Ck1T265nT8PYJ4Lh8BLCadEt2qoXwjMjbIV0jjxGXVWo= Received: from BN8PR05MB6098.namprd05.prod.outlook.com (2603:10b6:408:45::29) by BN6PR05MB2995.namprd05.prod.outlook.com (2603:10b6:404:2a::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.6; Wed, 21 Apr 2021 20:01:54 +0000 Received: from BN8PR05MB6098.namprd05.prod.outlook.com ([fe80::4d47:2d3c:d3c5:2e14]) by BN8PR05MB6098.namprd05.prod.outlook.com ([fe80::4d47:2d3c:d3c5:2e14%3]) with mapi id 15.20.4065.021; Wed, 21 Apr 2021 20:01:54 +0000 From: John Scudder To: Alvaro Retana CC: "draft-ietf-roll-aodv-rpl@ietf.org" , "roll@ietf.org" , "roll-chairs@ietf.org" , Ines Robles , The IESG Thread-Topic: John Scudder's Discuss on draft-ietf-roll-aodv-rpl-10: (with DISCUSS and COMMENT) Thread-Index: AQHXNVsZVxHxg8VYVkSdat85+ymoxKq9f5YAgAHoDIA= Date: Wed, 21 Apr 2021 20:01:53 +0000 Message-ID: <6279B4EF-BDA3-4A5D-9974-E850D5E836A5@juniper.net> References: <161886431878.23690.10633892549620498188@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.120.23.2.4) authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [162.225.191.192] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d5df4b66-3be8-4a7f-4565-08d905004f84 x-ms-traffictypediagnostic: BN6PR05MB2995: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: gmMbffHSHrGjuEXwqj4hqWcioWGCI9fUmHE6TWh4c7l+DLTz2AJPS0W+aF527B1sRlafwS5siq8PFrFO2UuJzmwItMV4AULS/W0JfGhoLuqwR8G+AybVQWYwP9+SLUnT3xpWFhtztF73a14Lfgrfl4IlIS8dGzxTttHk8FDgnqCBRIaywnYIvQILmwlz2yjltx2tZsqQ8Bi/QN7RE6lgBggSFaR+HRGXpw488nvP+U7k7ob0nHN4j+I1F4xIsZVj1X4Ah+uJ5MwO4FH/RtrEGlhmPxi++YdpPXZa+yolNrP5YCnJCVpkenkSS99G2rVdqVFUmysTDkJbr2RB6OFT24ovX/xx2DqihnQNV4xV/MtzNH1A8OMEZVBYfrdfO5Ffstt5fapgd7nL/HVnOj+sKh7sh5bXqZDX1KcgvxAd74paw7GD2iAp5DbRHCoDv69LO/7cqBeYXV/q5q/yr+qWUFzYmFLQ0bXR9nDGXutBY7M3GHrZXJsWZXABNDMFRwZJo7GEDPu7vWYTCLbx28jogXZndnu6/EBd07uvpG137Wvn1GNO++AZXAxflAwyg4mdVTHYXUsmJB5565ZKyJfizQ75+mgRMaQF9Bbr0naS5nV5yyBqAFxj7qgLCxli+zb56Xfjri0OjAPZzDAMyQIxTSomfuaQbrusZd/Qq9Whpzw= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN8PR05MB6098.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(39860400002)(366004)(376002)(346002)(396003)(8676002)(83380400001)(2616005)(38100700002)(122000001)(71200400001)(91956017)(4326008)(66946007)(66476007)(6512007)(66446008)(66556008)(36756003)(76116006)(64756008)(478600001)(5660300002)(66574015)(33656002)(8936002)(86362001)(186003)(6506007)(53546011)(26005)(6486002)(54906003)(6916009)(316002)(2906002)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?SVBZcXRhNUtqbHc0WERkTTI5S3NMQjRiVWZ3WWxVYjMrZDBaU1BRU3FkTk1T?= =?utf-8?B?djhWeDVtQjNjYWlneTRvQnVoblUwNEMwYlFPU3lDTC96alZwaWkyYTMrNlFl?= =?utf-8?B?V1dScnd3Zjh1SGdXdE5BWGdTSTJuRGpEb0lnVjVxeEFxVXF1Y3RwTi9EODRU?= =?utf-8?B?MCtOQWZlMnNBZTdtTXVZaDQ1ajJWNzlKUnRqV0R1Smt0VHAyaW1EczZZUnVF?= =?utf-8?B?cTQwcWIyc3Y2STE3alhRM09MSFNINXpuc05xeDVWUnZCcTlOZksyUjI2bFdo?= =?utf-8?B?V2Y5SjFOTEpwYk42U3JHUU1ab0MzUU44eUhvSm5ySG1UZVJUNjZWQVY4VWhF?= =?utf-8?B?TXBDSnIwbVJ4eTEzWGFJdmlUNlZEQzI0Ni9EaEhJaG9OUHJJWmFjYnNGQ3ln?= =?utf-8?B?ekk2c0Y0VUw1YnhUYlkrREthNEFnR0FFblk4NDR1enZJU1R4SHY4djBNcEZC?= =?utf-8?B?bDhMRmI2SVZHV245MmpUSVJXdEhYbDVsemRueGxSKzc5aVdSQjFIS3dXNmtP?= =?utf-8?B?ZnJOQ2dWeTAyMHpvZlZJSHQ0YU9FLzhlMEJDOTRBS05ZUWFsMkI5M0RUbFU3?= =?utf-8?B?NEt3UlhEaXBEbXBKZ3loVU1LcEJaV0psVm0vbitrVi9Pc0s2ZENneFNDQS9P?= =?utf-8?B?eS9KMmdacS96YUtCK3dlSkdWN25GV2J0dW00OW0wY05kSVNWdDdaVjNVdUNq?= =?utf-8?B?bFVHQndVemM3WXBzeHllbnZad2dkQ05nWDlVRWtnZmVPS0ZWMm5qWnJkM3lP?= =?utf-8?B?dGlZWVRtOUZtdmMwSXhZL1orUk9zT0FUQWEydDdKU1MySDN5ZXkvdzZaRS9p?= =?utf-8?B?TktYS0JKc0RnaStZM0VkaEFwTWJOaXlzcXE2MUpnbWZtS3IyOEdlN2tWdGNp?= =?utf-8?B?UkluYlhsWDk0Uk8xVFhkYWk5ZlQ5alROdXdnQURLRmhtQWh4a2F0dkVXMko1?= =?utf-8?B?OFI0MS9FeEhBUFdVTGY4TU0xaFkwWm5JZk5XK2VOWFJJZ2RtbzZOY1Y4MWZw?= =?utf-8?B?VVdPR3hmVEp4UkNKZXBJMjR0bWtBcmxjYk5oaFRGRWxFSFRtZ2NJQTdzdDhI?= =?utf-8?B?azZ6WnE4aHRMQVY1aFpqRlNlTkJlQndFTGtLcUthcHlLb1dFVUkwMUhPb2d0?= =?utf-8?B?aThnWkk5LzcvVkxTVG1Pd2IrNXdqaElYdVloYUZ1SGZyWUxFZHZBSVhQdCt5?= =?utf-8?B?aFAyMTJhd2l3T1dYdW10ZDZQaXFGb2ZKc0tRQytEcjVyU05GVXh6aVZ6bm1S?= =?utf-8?B?VUxONk8xRkttYWYwczhwdUxTZjNQbWFmb2huUTFHU0RkK3JSeGpuNE9CNVVz?= =?utf-8?B?bUZXYk96K3N2YWhxd1R2OERHRS9TbktWZ1REaVBGVURJSU9UdmM1aDJPT2tk?= =?utf-8?B?d0c5L2V1Tk9WVXEvamxRbUdOaHJOa1VJSmJCVjdzcDh5Z2R6VTBZbXFrNDBn?= =?utf-8?B?UFZRaGxlSUtiRFo3bXpsUndnWHN5R0w1WFJNQnppR29EYk5QelVNRks4NnRP?= =?utf-8?B?dXMwQlIxUVhFMDBsNk5oMW41aXNvbmR1WURmcE5wSXFRUm1YcSs2eGl1Y05H?= =?utf-8?B?V3N6d1pEelg5YitaOFJKU21ZK3ltUHFGeUxiWFhuK0lvVHppWlJzeERIRW01?= =?utf-8?B?V3kvcjRzUWpKcnlWVDhaa2I0QTdnTXBTNnJGazY4SnVya2ZTZFM2eHBSR25r?= =?utf-8?B?L3FYR1Qwb2NNQ0t0Zk1ZUlBzWklpNklmT24zZFNSbG1vU20rbHk0Y1AxL1Mx?= =?utf-8?B?YnovNjE3NDBxR1dSREFQWXlCcTFXUnhVSFhIYWg4MnRIaTJEV1BoK1k2ZjFT?= =?utf-8?B?K29sZHZCdGo0cjZXZnZZZz09?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN8PR05MB6098.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d5df4b66-3be8-4a7f-4565-08d905004f84 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2021 20:01:53.9894 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: e/50zTyA2Pcf9WsMfqZOuBfq85KsTSdqDOJFr9YBjEpiEZbxc1XCzrMG/Jro03yV X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR05MB2995 X-Proofpoint-GUID: 4PRJ9DuQn4zi5mMpWN38yq0XJ3-Pu4Dg X-Proofpoint-ORIG-GUID: 4PRJ9DuQn4zi5mMpWN38yq0XJ3-Pu4Dg X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-04-21_05:2021-04-21, 2021-04-21 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxscore=0 suspectscore=0 phishscore=0 mlxlogscore=457 clxscore=1015 adultscore=0 impostorscore=0 spamscore=0 bulkscore=0 lowpriorityscore=0 priorityscore=1501 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000 definitions=main-2104210136 Archived-At: Subject: Re: [Roll] John Scudder's Discuss on draft-ietf-roll-aodv-rpl-10: (with DISCUSS and COMMENT) 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, 21 Apr 2021 20:02:05 -0000 SGkgQWx2YXJvLA0KDQpBZnRlciBvdXIgY2FsbCBJIGZlZWwgbGlrZSB3ZeKAmXZlIG1hZGUgcHJv Z3Jlc3MgYnV0IHRoZXJlIGFyZSBzdGlsbCBzb21lIHRoaW5ncyBJ4oCZZCBsaWtlIHRvIGZpbmlz aCBoYXNoaW5nIG91dC4NCg0KPiBPbiBBcHIgMjAsIDIwMjEsIGF0IDEwOjU1IEFNLCBBbHZhcm8g UmV0YW5hIDxhcmV0YW5hLmlldGZAZ21haWwuY29tPiB3cm90ZToNCj4gDQo+IE9uIEFwcmlsIDE5 LCAyMDIxIGF0IDQ6MzI6MDMgUE0sIEpvaG4gU2N1ZGRlciB3cm90ZToNCj4gDQo+IA0KPiBKb2hu Og0KPiANCj4gSGkhICBUaGFua3MgZm9yIHRoZSByZXZpZXchDQo+IA0KPiBJJ20ganVzdCByZXBs eWluZyB0byB5b3VyIERJU0NVU1MgLS0gSSB3aWxsIGxldCB0aGUgYXV0aG9ycyBhZGRyZXNzDQo+ IHRoZSByZXN0IG9mIHRoZSBjb21tZW50cy4NCj4gDQo+IA0KPj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4g RElTQ1VTUzoNCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLi4uDQo+PiBNeSBjaGllZiBkaWZmaWN1bHR5 IHdpdGggdGhlIGRvY3VtZW50IGlzIHBsYWNpbmcgaXQgaW4gY29udGV4dC4gTm8gaGludHMgYXJl DQo+PiBnaXZlbiB0byB0aGUgcmVhZGVyIGFzIHRvIHdoYXQgdGhlIGV4cGVjdGVkIG5ldHdvcmsg ZW52aXJvbm1lbnQgaXMuIEkgdGhpbmsNCj4+IGl0IHdvdWxkIGJlIGFsbW9zdCBzdWZmaWNpZW50 IHRvIHNheSwgZm9yIGV4YW1wbGUg4oCcdGhlIG5ldHdvcmsgZW52aXJvbm1lbnQgaXMNCj4+IGFz c3VtZWQgdG8gYmUgdGhlIHNhbWUgYXMgZGVzY3JpYmVkIGluIFJGQyA2NTUwLCBTZWN0aW9uIDHi gJ0gZm9yIGV4YW1wbGUsIGJ1dA0KPj4gd2l0aG91dCB0aGF0IGhpbnQgYW5kIHdpdGhvdXQgYSBz dHJvbmcgYmFja2dyb3VuZCBpbiBST0xMLCBJIGZvdW5kIG15c2VsZg0KPj4gc3RydWdnbGluZy4N Cj4gDQo+IEFPRFYtUlBMIGlzIGFuIGV4dGVuc2lvbiBvZiBSUEwgLS0gdGhlIHNhbWUgdHlwZXMg b2YgbmV0d29ya3MgdGhhdCBSUEwNCj4gdGFyZ2V0cyBhcmUgYXBwcm9wcmlhdGUgZm9yIEFPRFYt UlBMLiAgVGhlIG9uZSBkaWZmZXJlbnRpYXRvciBpcyB0aGUNCj4gYWJpbGl0eSBvZiBBT0RWLVJQ TCB0byBkaXNjb3ZlciBwMnAgcm91dGVzIHRoYXQgbWF5IG5vdCBuZWVkIHRvDQo+IHRyYXZlcnNl IHRoZSByb290IChtb3JlIGJlbG93KS4gIElPVywgbmV0d29ya3MgdGhhdCBoYXZlIHNpZ25pZmlj YW50DQo+IHAycCB0cmFmZmljIHdvdWxkIGJlbmVmaXQgdGhlIG1vc3QuDQoNCkFzIHdlIGRpc2N1 c3NlZCBvbiBvdXIgY2FsbCwgSSB0aGluayB0aGUg4oCcZXhwZWN0ZWQgbmV0d29yayBlbnZpcm9u bWVudOKAnSB0aGluZyB3YXMgbGFyZ2VseSBhIHJlZCBoZXJyaW5nIEkgd2FzIGxlZCB0byBieSBp bXByZWNpc2lvbiBpbiB0aGUgdXNlIG9mIOKAnG11bHRpY2FzdOKAnSwgc2VlIGZvciBleGFtcGxl IG15IGNvbW1lbnQgIzE1LiBJIHRoaW5rIHdlIGNhbiBjb25zaWRlciB0aGUg4oCcbmV0d29yayBl bnZpcm9ubWVudOKAnSBwb2ludCBwdXQgdG8gcmVzdC4NCg0KPj4gRmlndXJlcyA0IGFuZCA1IGlu IHBhcnRpY3VsYXIgbGVhZCBtZSB0byBiZWxpZXZlIHRoZSBleHBlY3RlZCBlbnZpcm9ubWVudA0K Pj4gbG9va3Mgc2ltaWxhciB0byBhIGNsYXNzaWMgSVNQIG5ldHdvcmsg4oCUIGEgY29sbGVjdGlv biBvZiBub2RlcyBjb25uZWN0ZWQgYnkNCj4+IHBvaW50LXRvLXBvaW50IGxpbmtzLiBJZiB0aGlz IGlzbuKAmXQgY29ycmVjdCAoYW5kIEkgYmV0IGl04oCZcyBub3QpIHRoYXQgbWF5DQo+PiBoYXZl IGxlZCBtZSBpbnRvIGluY29ycmVjdCBhc3N1bXB0aW9ucywgd2hpY2ggbWF5IGJlIHJlZmxlY3Rl ZCBpbiBteSBvdGhlcg0KPj4gY29tbWVudHMgYmVsb3cuDQo+IA0KPiBOb3cgdGhhdCBJIGxvb2sg YXQgdGhlIGZpZ3VyZXMgYWdhaW4sIEkgY2FuIHNlZSBob3cgdGhleSBtaWdodCBsb29rDQo+IGxp a2UgYSBzZWdtZW50IG9mIGEgdHJhZGl0aW9uYWwgYWNjZXNzLWRpc3RyaWJ1dGlvbi1jb3JlIG5l dHdvcmsuIDotKQ0KPiANCj4gUlBMIGZvcm1zIGEgRGVzdGluYXRpb24tT3JpZW50ZWQgRGlyZWN0 ZWQgQWN5Y2xpYyBHcmFwaCAoRE9EQUcpLCB3aGljaA0KPiByZXN1bHRzIGluIGEgdHJlZS1saWtl IHN0cnVjdHVyZSB3aXRoIGEgQm9yZGVyIFJvdXRlciAoQlIpIGF0IHRoZSB0b3AuDQo+IEluIGdl bmVyYWwsIGluc3RlYWQgb2YgYWNjZXNzLWRpc3RyaWJ1dGlvbi1jb3JlLCB0aGUgd2hvbGUgUlBM DQo+IGluc3RhbmNlIGlzIG1hZGUgdXAgb2YgbGVhdmVzLXRyYW5zaXQgcm91dGVycy1ib3JkZXIg cm91dGVyLiAgSW4gc29tZQ0KPiBjYXNlcyB0aGUgbGVhdmVzIGFyZSBSUEwtYXdhcmUsIGJ1dCBu b3QgYWx3YXlzLg0KDQpBIGtleSBvYnNlcnZhdGlvbiBpcyB0aGF0IHRoZSBmaWd1cmUgZGVwaWN0 cyBhIGNvbnRyb2wgcGxhbmUgdG9wb2xvZ3ksIG5vdCBhIHBoeXNpY2FsIHRvcG9sb2d5LCByaWdo dD8NCg0KPj4gRnVydGhlciwgaXTigJlzIG5vdCBzdGF0ZWQgYW55d2hlcmUgd2hldGhlciBBT0RW LVJQTCBpcyBpbnRlbmRlZCB0byBzdGFuZA0KPj4gYWxvbmUgYXMgaXRzIG93biByb3V0aW5nIHBy b3RvY29sLCBvciB0byBiZSB2aWV3ZWQgYXMgYW4gZXh0ZW5zaW9uIG9mIFJQTC4NCj4+IEluIHRo ZSBmb3JtZXIgY2FzZSwgaXQgc2VlbXMgdGhlIGRvY3VtZW50IGlzIGxhY2tpbmcgZGV0YWlscyB0 aGF0IGFyZSBwcmVzZW50DQo+PiBpbiBSRkMgNjU1MC4gSeKAmW0gYXNzdW1pbmcgdGhlIGxhdHRl ciBpcyB0aGUgY2FzZSwgYnV0IGEgY2xlYXIgc3RhdGVtZW50IHRvDQo+PiB0aGF0IGVmZmVjdCBz ZWVtcyBpbmRpY2F0ZWQuDQo+IA0KPiBBT0RWLVJQTCB1c2VzIGEgbmV3IE1vZGUgb2YgT3BlcmF0 aW9uIChNT1ApIGRlZGljYXRlZCB0byB0aGUgZGlzY292ZXJ5DQo+IG9mIHAycCByb3V0ZXMuICBU aGlzIG1lYW5zIHRoYXQgaXQgcnVucyBpbiBhIHNlcGFyYXRlIGluc3RhbmNlIGZyb20NCj4gdGhl ICJiYXNlIFJQTCIuICBBbHNvLCBpdCBjYW4gYmUgdXNlZCB3aGV0aGVyIG9yIG5vdCBhICJiYXNl IFJQTCINCj4gaW5zdGFuY2UgaXMgdXNlZC4gIElPVywgaXQgaXMgUlBMIHVzaW5nIE1PUCA1Lg0K DQpUaGUgdXNlIG9mIHRoZSB0ZXJtIOKAnGJhc2UgUlBM4oCdLCBvciDigJxuYXRpdmUgUlBM4oCd IGFzIHRoZSBpbnRyb2R1Y3Rpb24gY2FsbHMgaXQsIGlzIHByb2JsZW1hdGljLCBpZiBJ4oCZdmUg dW5kZXJzdG9vZCB5b3UgcmlnaHQuIEl04oCZcyBhIGNhc2Ugb2Yg4oCcdGhlIGV4Y2VwdGlvbiB0 aGF0IHByb3ZlcyB0aGUgcnVsZeKAnSwgaS5lLiBieSByZWZlcmVuY2luZyDigJxuYXRpdmUgUlBM 4oCdIHRoYXQgaW1wbGllcyB0aGUgQU9EVi1SUEwgaXMgKm5vdCogUlBMLCB3aGljaCBpcyBhIGNv bnRyYWRpY3Rpb24gdG8gd2hhdCB5b3XigJl2ZSB3cml0dGVuIGFib3ZlIGFuZCBleHBsYWluZWQg dG8gbWUuDQoNClNvIEkgdGhpbmsgc29tZSB3b3JrIG9uIHRoYXQgbGFuZ3VhZ2UgaXMgaW4gb3Jk ZXIuDQoNCj4gTW9zdCBvZiB3aGF0IEkgd3JvdGUgYWJvdmUsIHdoaWNoIEkgaG9wZSBoZWxwcyBj bGFyaWZ5LCBpcyBpbiB0aGUNCj4gSW50cm9kdWN0aW9uIChwYXN0ZWQgYmVsb3cpLiAgSSB0aGlu ayB0aGF0IHRoZSB0ZXh0IGNvdWxkIGhhdmUgYmVlbiBhDQo+IGxpdHRsZSBtb3JlIGV4cGxpY2l0 IGluIHR5aW5nIHAycCB0cmFmZmljIHRvIEFPRFYtUlBMIC0tIGV2ZXJ5dGhpbmcNCj4gZWxzZSBz ZWVtcyB0byBiZSB0aGVyZS4gIFllcywgdGhlcmUgaXMgYSBzdHJvbmcgYXNzdW1wdGlvbiB0aGF0 IHRoZQ0KPiByZWFkZXIga25vd3MgUlBMLg0KPiANCj4gRG8geW91IGhhdmUgc3BlY2lmaWMgc3Vn Z2VzdGlvbiBvbiB3aGF0IGNhbiBiZSBhZGRlZCB0byB0aGUgSW50cm9kdWN0aW9uPw0KDQpTZWUg YmVsb3cuDQoNCj4gVGhhbmtzIQ0KPiANCj4gQWx2YXJvLg0KPiANCj4gDQo+IA0KPiANCj4gMS4g IEludHJvZHVjdGlvbg0KPiANCj4gICBSUEwgKFJvdXRpbmcgUHJvdG9jb2wgZm9yIExvdy1Qb3dl ciBhbmQgTG9zc3kgTmV0d29ya3MpIFtSRkM2NTUwXSBpcw0KPiAgIGFuIElQdjYgZGlzdGFuY2Ug dmVjdG9yIHJvdXRpbmcgcHJvdG9jb2wgZGVzaWduZWQgdG8gc3VwcG9ydCBtdWx0aXBsZQ0KPiAg IHRyYWZmaWMgZmxvd3MgdGhyb3VnaCBhIHJvb3QtYmFzZWQgRGVzdGluYXRpb24tT3JpZW50ZWQg RGlyZWN0ZWQNCj4gICBBY3ljbGljIEdyYXBoIChET0RBRykuICBUeXBpY2FsbHksIGEgcm91dGVy IGRvZXMgbm90IGhhdmUgcm91dGluZw0KPiAgIGluZm9ybWF0aW9uIGZvciBtb3N0IG90aGVyIHJv dXRlcnMuICBDb25zZXF1ZW50bHksIGZvciB0cmFmZmljDQo+ICAgYmV0d2VlbiByb3V0ZXJzIHdp dGhpbiB0aGUgRE9EQUcgKGkuZS4sIFBvaW50LXRvLVBvaW50IChQMlApIHRyYWZmaWMpDQo+ICAg ZGF0YSBwYWNrZXRzIGVpdGhlciBoYXZlIHRvIHRyYXZlcnNlIHRoZSByb290IGluIG5vbi1zdG9y aW5nIG1vZGUsIG9yDQo+ICAgdHJhdmVyc2UgYSBjb21tb24gYW5jZXN0b3IgaW4gc3RvcmluZyBt b2RlLiAgU3VjaCBQMlAgdHJhZmZpYyBpcw0KPiAgIHRoZXJlYnkgbGlrZWx5IHRvIHRyYXZlcnNl IGxvbmdlciByb3V0ZXMgYW5kIG1heSBzdWZmZXIgc2V2ZXJlDQo+ICAgY29uZ2VzdGlvbiBuZWFy IHRoZSByb290IChmb3IgbW9yZSBpbmZvcm1hdGlvbiBzZWUgW1JGQzY5OTddLA0KPiAgIFtSRkM2 OTk4XSkuDQo+IA0KPiAgIFRoZSByb3V0ZSBkaXNjb3ZlcnkgcHJvY2VzcyBpbiBBT0RWLVJQTCBp cyBtb2RlbGVkIG9uIHRoZSBhbmFsb2dvdXMNCj4gICBwcm9jZWR1cmUgc3BlY2lmaWVkIGluIEFP RFYgW1JGQzM1NjFdLiAgVGhlIG9uLWRlbWFuZCBuYXR1cmUgb2YgQU9EVg0KPiAgIHJvdXRlIGRp c2NvdmVyeSBpcyBuYXR1cmFsIGZvciB0aGUgbmVlZHMgb2YgcGVlci10by1wZWVyIHJvdXRpbmcg aW4NCj4gICBSUEwtYmFzZWQgTExOcy4gIEFPRFYgdGVybWlub2xvZ3kgaGFzIGJlZW4gYWRhcHRl ZCBmb3IgdXNlIHdpdGggQU9EVi0NCj4gICBSUEwgbWVzc2FnZXMsIG5hbWVseSBSUkVRIGZvciBS b3V0ZSBSZXF1ZXN0LCBhbmQgUlJFUCBmb3IgUm91dGUNCj4gICBSZXBseS4gIEFPRFYtUlBMIGN1 cnJlbnRseSBvbWl0cyBzb21lIGZlYXR1cmVzIGNvbXBhcmVkIHRvIEFPRFYgLS0gaW4NCj4gICBw YXJ0aWN1bGFyLCBmbGFnZ2luZyBSb3V0ZSBFcnJvcnMsIGJsYWNrbGlzdGluZyB1bmlkaXJlY3Rp b25hbCBsaW5rcywNCj4gICBtdWx0aWhvbWluZywgYW5kIGhhbmRsaW5nIHVubnVtYmVyZWQgaW50 ZXJmYWNlcy4NCj4gDQo+ICAgQU9EVi1SUEwgcmV1c2VzIGFuZCBwcm92aWRlcyBhIG5hdHVyYWwg ZXh0ZW5zaW9uIHRvIHRoZSBjb3JlIFJQTA0KPiAgIGZ1bmN0aW9uYWxpdHkgdG8gc3VwcG9ydCBy b3V0ZXMgd2l0aCBiaXJlY3Rpb25hbCBhc3ltbWV0cmljIGxpbmtzLg0KPiAgIEl0IHJldGFpbnMg UlBMJ3MgRE9EQUcgZm9ybWF0aW9uLCBSUEwgSW5zdGFuY2UgYW5kIHRoZSBhc3NvY2lhdGVkDQo+ ICAgT2JqZWN0aXZlIEZ1bmN0aW9uIChkZWZpbmVkIGluIFtSRkM2NTUxXSksIHRyaWNrbGUgdGlt ZXJzLCBhbmQNCj4gICBzdXBwb3J0IGZvciBzdG9yaW5nIGFuZCBub24tc3RvcmluZyBtb2Rlcy4g IEFPRFYgYWRkcyBiYXNpYyBtZXNzYWdlcw0KPiAgIFJSRVEgYW5kIFJSRVAgYXMgcGFydCBvZiBS UEwgRElPIChET0RBRyBJbmZvcm1hdGlvbiBPYmplY3QpIGNvbnRyb2wNCj4gICBtZXNzYWdlcywg YW5kIGRvZXMgbm90IHV0aWxpemUgdGhlIERlc3RpbmF0aW9uIEFkdmVydGlzZW1lbnQgT2JqZWN0 DQo+ICAgKERBTykgbWVzc2FnZSBvZiBSUEwuICBBT0RWLVJQTCBzcGVjaWZpZXMgYSBuZXcgTU9Q IChNb2RlIG9mDQo+ICAgT3BlcmF0aW9uKSBydW5uaW5nIGluIGEgc2VwYXJhdGUgaW5zdGFuY2Ug ZGVkaWNhdGVkIHRvIGRpc2NvdmVyIFAyUA0KPiAgIHJvdXRlcywgd2hpY2ggbWF5IGRpZmZlciBm cm9tIHRoZSBwb2ludC10by1tdWx0aXBvaW50IHJvdXRlcw0KPiAgIGRpc2NvdmVyYWJsZSBieSBu YXRpdmUgUlBMLiAgQU9EVi1SUEwgY2FuIGJlIG9wZXJhdGVkIHdoZXRoZXIgb3Igbm90DQo+ICAg bmF0aXZlIFJQTCBpcyBydW5uaW5nIG90aGVyd2lzZS4NCg0KVGhlIGZpbmFsIHBhcmFncmFwaCBp cyB0aGUgb25lIHRoYXQgbGVkIG1lIGFzdHJheS4gSXMgdGhpcyByZXdyaXRlIG9uIHRhcmdldD8N Cg0KQU9EVi1SUEwgaXMgYSBuZXcgUlBMIE1vZGUgb2YgT3BlcmF0aW9uIChNT1ApIHRoYXQgZXh0 ZW5kcyBSRkMgNjU1MCB0byBzdXBwb3J0IHJvdXRlcyB3aXRoIGJpZGlyZWN0aW9uYWwgYXN5bW1l dHJpYyBsaW5rcy4gSXQgbWFrZXMgdXNlIG9mIFJGQyA2NTUw4oCZcyBET0RBRyBmb3JtYXRpb24s IFJQTCBJbnN0YW5jZSwgYW5kIHRoZSBhc3NvY2lhdGVkIE9iamVjdGl2ZSBGdW5jdGlvbiAoZGVm aW5lZCBpbiBbcmZjNjU1MV0pLCB0cmlja2xlIHRpbWVycywgYW5kIHN1cHBvcnQgZm9yIHN0b3Jp bmcgYW5kIG5vbi1zdG9yaW5nIG1vZGVzLiBBT0RWLVJQTCBhZGRzIGJhc2ljIG1lc3NhZ2VzIFJS RVEgYW5kIFJSRVAgYXMgcGFydCBvZiB0aGUgUlBMIERJTyAoRE9EQUcgSW5mb3JtYXRpb24gT2Jq ZWN0KSBjb250cm9sIG1lc3NhZ2VzLCBhbmQgZG9lcyBub3QgdXRpbGl6ZSB0aGUgRGVzdGluYXRp b24gQWR2ZXJ0aXNlbWVudCBPYmplY3QgKERBTykuIFRoZSBBT0RWLVJQTCBNT1AgcnVucyBpbiBh IHNlcGFyYXRlIGluc3RhbmNlIGRlZGljYXRlZCB0byBkaXNjb3ZlcmluZyBQMlAgWypdIHJvdXRl cywgd2hpY2ggbWF5IGRpZmZlciBmcm9tIHRoZSBwb2ludC10by1tdWx0aXBvaW50IHJvdXRlcyBk aXNjb3ZlcmFibGUgYnkgUlBM4oCZcyBvdGhlciBtb2RlcyBvZiBvcGVyYXRpb24uIEFPRFYtUlBM IGNhbiBiZSBvcGVyYXRlZCB3aGV0aGVyIG9yIG5vdCBvdGhlciBSUEwgbW9kZXMgb2Ygb3BlcmF0 aW9uIGFyZSBydW5uaW5nIG90aGVyd2lzZS4NCg0KWypdIEFsdGhvdWdoLCBJIGRvIGFncmVlIHdp dGggw4lyaWPigJlzIERJU0NVU1MgYWJvdXQgdXNlIG9mIHRoaXMgdGVybWlub2xvZ3kuIEkgdW5k ZXJzdGFuZCBmcm9tIEFsdmFybyB0aGF0IGl04oCZcyB3YXRlciB1bmRlciB0aGUgYnJpZGdlLCBi dXQgc29tZSBraW5kIG9mIHdhcm5pbmcgdG8gdGhlIHVud2FyeSB0cmF2ZWxlciBpcyBpbiBvcmRl cjog4oCYaGV5LCBiZSBhd2FyZSB3ZSB1c2Ug4oCccDJwIiBpbiBhIHdheSB5b3UgbWF5IGZpbmQg dW51c3VhbCHigJkNCg0KVGhhbmtzLA0KDQrigJRKb2hu From nobody Wed Apr 21 16:04:03 2021 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 6C15F3A3A5A; Wed, 21 Apr 2021 16:03:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-roll-aodv-rpl@ietf.org, roll-chairs@ietf.org, roll@ietf.org, Ines Robles , aretana.ietf@gmail.com, mariainesrobles@googlemail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <161904623841.17653.13314629547868546211@ietfa.amsl.com> Date: Wed, 21 Apr 2021 16:03:58 -0700 Archived-At: Subject: [Roll] Roman Danyliw's Discuss on draft-ietf-roll-aodv-rpl-10: (with DISCUSS and COMMENT) 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: Wed, 21 Apr 2021 23:03:59 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-roll-aodv-rpl-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-roll-aodv-rpl/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- ** Section 10 If a rogue router knows the key for the Security Configuration in use, it can join the secure AODV-RPL route discovery and cause various types of damage. Such a rogue router could advertise false information in its DIOs in order to include itself in the discovered route(s). It could generate bogus RREQ-DIO, and RREP-DIO messages carrying bad routes or maliciously modify genuine RREP-DIO messages it receives. A rogue router acting as the OrigNode could launch denial-of-service attacks against the LLN deployment by initiating fake AODV-RPL route discoveries. In this type of scenario, RPL's preinstalled mode of operation, where the key to use for a P2P-RPL route discovery is preinstalled, SHOULD be used. Can the normative language in the last sentence please be clarified. The entire paragraph prior is describing the behavior of the attacker. Is this last sentence is suggesting a particular mode of operation? If the router is rogue, how is the fact that the key is pre-installed inhibit the behavior of the attacker? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ** I support John’s DISUSS. My feedback are also around clarifying what AODV-RPL inherits from RPL. ** Section 10. Per “In general, the security considerations for the operation of AODV-RPL are similar to those for the operation of RPL”, to be clear do all of the considerations from RFC6550 apply? The caveat of “In general …” doesn’t necessarily suggest that to me. ** Section 10. Unless AODV-RPL is upgrading the requirements of RPL, I believe all of the referenced security framework is optional. I would recommend being clear on that: OLD: Sections 6.1 and 10 of [RFC6550] describe RPL's security framework, which provides data confidentiality, authentication, replay protection, and delay protection services. NEW: Sections 6.1 and 10 of [RFC6550] describe RPL's optional security framework, which AODV-RPL rely on to provides data confidentiality, authentication, replay protection, and delay protection services. ** Section 10. Per “A router can join a temporary DAG … only if it can support the Security Configuration in use, which also specifies the key I use”: -- Is “Security Configuration” a term of art in RPL to be capitalized? I'm not sure if this is editorial feedback or a reference to some RPL mechanism. -- Is this section referring to the processes described in Section 10.2 of RFC6550? I ask because couldn’t there be an RPL configuration which doesn’t use secure join (i.e., “unsecured mode” per Section 10.1 of RFC6550)? ** Section 10. This section introduces a new acronym “P2P-RPL” not used in any other part of the document From nobody Wed Apr 21 19:47:13 2021 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 819D53A0ED3; Wed, 21 Apr 2021 19:47:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Erik Kline via Datatracker To: "The IESG" Cc: draft-ietf-roll-aodv-rpl@ietf.org, roll-chairs@ietf.org, roll@ietf.org, Ines Robles , aretana.ietf@gmail.com, mariainesrobles@googlemail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Erik Kline Message-ID: <161905962749.10179.18114562350901227233@ietfa.amsl.com> Date: Wed, 21 Apr 2021 19:47:07 -0700 Archived-At: Subject: [Roll] Erik Kline's No Objection on draft-ietf-roll-aodv-rpl-10: (with COMMENT) 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, 22 Apr 2021 02:47:08 -0000 Erik Kline has entered the following ballot position for draft-ietf-roll-aodv-rpl-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-roll-aodv-rpl/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [[ nits ]] [ section 4.1 ] * "sets its IPv6 address" could perhaps be something like "sets a selected IPv6 source address" [ section 4.3 ] * "r" is not depicted in Figure 3? Probably "X"? Or update Figure to match the field description. From nobody Thu Apr 22 00:44:31 2021 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 A62903A1AA3; Thu, 22 Apr 2021 00:44:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Murray Kucherawy via Datatracker To: "The IESG" Cc: draft-ietf-roll-aodv-rpl@ietf.org, roll-chairs@ietf.org, roll@ietf.org, Ines Robles , aretana.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <161907746666.4867.10229249239001365546@ietfa.amsl.com> Date: Thu, 22 Apr 2021 00:44:26 -0700 Archived-At: Subject: [Roll] Murray Kucherawy's No Objection on draft-ietf-roll-aodv-rpl-10: (with COMMENT) 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, 22 Apr 2021 07:44:27 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-roll-aodv-rpl-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-roll-aodv-rpl/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I concur with Roman's DISCUSS, especially around the use of SHOULD. I'd go further and ask why that's not a MUST, or in the alternative, provide some guidance around why an implementer might legitimately decide against doing what the SHOULD said. The document shepherd writeup is more than two years old. In Section 2, although "AODV-RPL Instance" is defined, it is present nowhere in the document. Also "ART Option" doesn't seem to be ordered correctly. In Section 9, I suggest being clear that what you're actually updating are the named sub-registries of the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry. From nobody Thu Apr 22 01:25:15 2021 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 4F05F3A1D5E for ; Thu, 22 Apr 2021 01:25:14 -0700 (PDT) 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 j7vZL-DFwwEy for ; Thu, 22 Apr 2021 01:25:09 -0700 (PDT) Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (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 8F5A03A1D5D for ; Thu, 22 Apr 2021 01:25:09 -0700 (PDT) Received: by mail-vs1-xe31.google.com with SMTP id g20so22510098vst.2 for ; Thu, 22 Apr 2021 01:25:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=DpCfe5opNTg1AkywIIrN/RjwQWXciLe+2uxgr+Yu8rM=; b=ndGu9XhEvuMqh1FhRNtMJDKk5ROaxx5bzqj0MQojJATWJ8c/g2mF8IuljSB6ERh0if viuxFvSqn69jSX3DLDEcO+qSEXiJ0n/i+jD1rM8j76Cx8iX3xk8ZXyfAOwufigu6m4QX bGpgMUp9GL6vBQqnHPeqKb+peEpZuj/lXzLXQPpvvIqDgNCXpRt8yf7p918vGb8l1Uaz j+BItFpiMFU5y3Llj2Hc9NZUhVtvk9Z5lCIA1GGa/gnADk06hYXS3NKl9bIYIC9PODli VVzaTkbSO+TUbptS6HOkXqMDjLXmQfbxddu0bUYRS5XQBId4g0fVbiGYHz8feiYYqw2z cBVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=DpCfe5opNTg1AkywIIrN/RjwQWXciLe+2uxgr+Yu8rM=; b=E2JkRBRtXUzOWOGAP5Mfg8BPmfl5xZ3jOvseEpMiZcpC4fWfB8l39RLqaOXq4/slrr W4XSodY0A83n++IzucX8XqLn7Sr9txJiEUzsyjea5MVOFaf9EbVjPB385kiMbmJ+0kSa BX2bUIcdaMTXtHpcLOPf86shf2GNnjth0CxiJ8cw+RdpYXq3sxpkCuYCtnda3HgUPok8 1juIKWaKva4i2h3sfmgyn5T5Xx5TWEO+fmfFB2qQMRnk1731/CqKNnahogx/VSCYbEb5 nj0AZCKgtRAflAwVZ+qEQkNUI0lS6mTBgdzytxeJ4HbntCjsrjkU9QX+z/WLNG5PjIVS 0H1A== X-Gm-Message-State: AOAM531DdLlKIhSn672EmHGLT6mOCbZlJOnmLuvrdb8d1ugXYLFuiSva A34p0cLTDJfCApzEKyW3l3Wxrp3MRXeuLV0fDjH6rSnU+Gc= X-Google-Smtp-Source: ABdhPJzW4seT1WiHbKW2I0vvoYRYu1qh+BDESKs1p/YsYnFdWMfcO53GMGDPexCklMbkJdZUz8sI6qhaqYVE+T9pscU= X-Received: by 2002:a67:ff03:: with SMTP id v3mr1402377vsp.34.1619079907864; Thu, 22 Apr 2021 01:25:07 -0700 (PDT) MIME-Version: 1.0 From: Ines Robles Date: Thu, 22 Apr 2021 11:24:32 +0300 Message-ID: To: roll Content-Type: multipart/alternative; boundary="000000000000c5712c05c08b6a00" Archived-At: Subject: [Roll] Request for Reviews and Document Shepherd for draft-ietf-roll-mopex 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, 22 Apr 2021 08:25:14 -0000 --000000000000c5712c05c08b6a00 Content-Type: text/plain; charset="UTF-8" Dear all, We are looking for reviews and Document Shepherd for the draft-ietf-roll-mopex-03 Please let us know, Thank you in advance, Ines and Dominique. --000000000000c5712c05c08b6a00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

We are looking for review= s and Document Shepherd for the=C2=A0draft-ietf-roll-mopex-03

P= lease let us know,

Thank you in advance,

Ines and Dominique.=C2=A0
--000000000000c5712c05c08b6a00-- From nobody Thu Apr 22 15:48:50 2021 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 1966A3A1667; Thu, 22 Apr 2021 15:48:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-roll-aodv-rpl@ietf.org, roll-chairs@ietf.org, roll@ietf.org, Ines Robles , aretana.ietf@gmail.com, mariainesrobles@googlemail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <161913172006.16574.8625402788675096789@ietfa.amsl.com> Date: Thu, 22 Apr 2021 15:48:40 -0700 Archived-At: Subject: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-aodv-rpl-10: (with DISCUSS and COMMENT) 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, 22 Apr 2021 22:48:46 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-roll-aodv-rpl-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-roll-aodv-rpl/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- My apologies for coming in with a late review, but I think there are some serious internal inconsistencies in this document that leave me unsure whether the document is in a reviewable form. It might be prudent to have the document return to the WG to fix the identified issues and get additional review. Specifically, there are several places in the document (most notably Section 6.4) that provide steps for processing a RREP-DIO that refer to the value of the "S bit". There is no S bit in the RREP option as defined in Section 4.2; indeed, there has never been an S bit in the RREP option since it was introduced in the -03. The -02 was proposing changes directly in the DIO base object, which included an S bit, so in that version of the document referring to an "S bit" in the reply processing could have made sense. There are also a few places that refer to using RREP (reply) processing to relate to membership in or joining of the RREQ (request) DODAG. I assume that these are, in effect, typographical errors that should refer to the RREP DODAG, but the one character has extreme significance to protocol operations. I also think that there is too much ambiguity relating to the processing of RREPs in the symmetric vs asymmetric case (which returns to the question of whether there is or should be an S bit in the RREP option). In particular, the semantics of the Address Vector field (for the source-routing case only, of course) vary. In the symmetric case this field is set by TargNode and propagated unchanged in the RREPs, but for the asymmetric case each intermediate node needs to add its address in the Address Vector. We do cover these different behaviors in Sections 6.3.1 and 6.3.2, but leave it very unclear as to how an intermediate node tells whether a received RREP is for the symmetric or asymmetric case. An explicit S bit would make this easy, of course, though it seems like it *might* be possible to use whether the RREP was received over a unicast or multicast address/interface as a stand in. However, that technique would be complicated by the presence of gratuitous RREPs, which are unicast in cases that do not quite align up with symmetric vs asymmetric. (Whether the processing behavior should reflect the "append to address vector" or "propagate address vector unchanged" for the gratuitous case is also not entirely clear to me.) On a more minor note, I don't think the description of rollover in Section 6.3.3 is correct. More in the COMMENT, but in essence, even though the shift is capped at 63, the instance ID can go up to 255 and wrapping should occur at the instance ID boundary, not the shift boundary. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The Abstract and Introduction do not paint a very clear picture of what is going to happen. Section 3 helps a fair bit, but I would have expected the introduction to mention that RREQ/RREP go in separate (paired) RPL instances, and that instances are created (and destroyed?) for each route being discovered. (This would also be a great place to clarify how AODV-RPL interacts with regular RPL, as was requested by other ADs already.) I would like to see a clearer picture of the relationship between the lifetime of routes discovered using AODV-RPL and the lifetime of the DODAGs used to build them. The (non-infinite) DODAG lifetime options are fairly short, and I would (perhaps naively) expect routes to have a longer lifetime than that in many cases. But it seems that the information stored with a route includes the RPL InstanceID, and if the route is to outlast the DODAG, then that information would become stale, and I don't know what value there would be in keeping it around in that case and risking collisions. Is it expected that when routes are to be long-lived, the L value of 0 is to be used? Section 1 (DAO) message of RPL. AODV-RPL specifies a new MOP (Mode of Operation) running in a separate instance dedicated to discover P2P routes, which may differ from the point-to-multipoint routes discoverable by native RPL. AODV-RPL can be operated whether or not I don't really understand why we find it useful to make a comparison between P2P routes and P2MP routes. Section 2 RREP-DIO message An AODV-RPL MOP DIO message containing the RREP option. The RPLInstanceID in RREP-DIO is typically paired to the one in the Typically, or actually (noting that §6.3.3 allows for the pairing process to include a "Shift" count for cases where the value cannot match exactly)? Is this an attempt to reflect the symmetric case where a DODAG is not built for symmetric routes? If so, it's not clear that we accurately portray what would be the "typical" case...but even in that symmetric case we still have to populate the RPLInstance field in the unicast RREP-DIO, and that still has the pairing logic. So I'm back to wondering when these would not be paired. Section 3 The routes discovered by AODV-RPL are not constrained to traverse a common ancestor. AODV-RPL can enable asymmetric communication paths in networks with bidirectional asymmetric links. For this purpose, Can AODV-RPL function in networks with unidirectional links? to TargNode, and another from TargNode to OrigNode. When possible, AODV-RPL also enables symmetric route discovery along Paired DODAGs (see Section 5). In what circumstances is it not possible to do so? Section 4.1 OrigNode sets its IPv6 address in the DODAGID field of the RREQ-DIO message. A RREQ-DIO message MUST carry exactly one RREQ option, otherwise it MUST be dropped. (Similarly for RREP in §4.2.) I suggest clarifying that other options are allowed (required, even). Who sets the S bit, and can it change as the DODAG is being constructed? ("See Section 5" would be fine.) L 2-bit unsigned integer determining the duration that a node is able to belong to the temporary DAG in RREQ-Instance, including the OrigNode and the TargNode. Once the time is reached, a node MUST leave the DAG and stop sending or receiving any more DIOs for the temporary DODAG. How do we account for time skew as the DIO propagates? Each node just leaves on their own timer? Address Vector A vector of IPv6 addresses representing the route that the RREQ- DIO has passed. It is only present when the H bit is set to 0. The prefix of each address is elided according to the Compr field. TargNode can join the RREQ instance at a Rank whose integer portion is equal to the MaxRank. Other nodes MUST NOT join a RREQ instance if its own Rank would be equal to or higher than MaxRank. A router MUST discard a received RREQ if the integer part of the advertised Rank equals or exceeds the MaxRank limit. Both of these descriptions might benefit from a bit more detail. E.g., the latter paragraph doesn't say that TargNode can join if the rank is less than MaxRank, only if it's equal. Section 4.2 H Requests either source routing (H=0) or hop-by-hop (H=1) for the downstream route. It MUST be set to be the same as the H bit in RREQ option. (editorial) I'd suggest putting the "MUST be the same" requirement as the first sentence, and then the other sentence could be "determines whether source routing (H=0) or hop-by-hop (H=1) is used for the downstream route" L 2-bit unsigned integer defined as in RREQ option. Does L need to have the same value as in the triggering RREQ option? If not, when might TargNode choose a different value? Address Vector Only present when the H bit is set to 0. For an asymmetric route, the Address Vector represents the IPv6 addresses of the route that the RREP-DIO has passed. For a symmetric route, it is the Address Vector when the RREQ-DIO arrives at the TargNode, unchanged during the transmission to the OrigNode. [ed. this was written before I made a discuss point about it, but I'm leaving the text for the extra detail. It's okay to just respond to the discuss point and not here.] If I understand correctly, the S bit indicating symmetric vs asymmetric route is present only in the RREQ-DIO, and is not included in-band in the RREP-DIO. Does this require all nodes on the path to remember whether a symmetric route is being constructed on the RREQ-DIO instance, use the Shift in the RREP-DIO to correlate to the corresponding RREQ-DIO and 'S' bit status, as part of the processing (to determine whether or not to append to the Address Vector)? Section 4.3 Dest SeqNo In RREQ-DIO, if nonzero, it is the last known Sequence Number for TargNode for which a route is desired. In RREP-DIO, it is the destination sequence number associated to the route. The destination sequence number for the downstream route or the upstream route? Also, should we say that zero is used if there is no known information about the sequence number of TargNode (and not otherwise)? r A one-bit reserved field. This field MUST be initialized to zero by the sender and MUST be ignored by the receiver. The secdir reviewer noted the mismatch between 'X' in the figure and 'r' here; please fix. Prefix Length 7-bit unsigned integer. Number of valid leading bits in the IPv6 Prefix. If Prefix Length is 0, then the value in the Target Prefix / Address field represents an IPv6 address, not a prefix. Target Prefix / Address (variable-length field) An IPv6 destination address or prefix. The Prefix Length field contains the number of valid leading bits in the prefix. The length of the field is the least number of octets that can contain all of the bits of the Prefix, in other words Floor((7+(Prefix Length))/8) octets. The remaining bits in the Target Prefix / Address field after the prefix length (if any) MUST be set to zero on transmission and MUST be ignored on receipt. Please specify how long the Address field is when Prefix Length is zero (indicating that the last field is the Address variant). Section 5 Links are considered symmetric until additional information is collected. [...] What kinds of problems will arise if we start taking actions based on this assumption before the "additional information" is available? (That is to say, perhaps this is not a useful phrasing, since what we actually do is get updates about the presence of asymmetric links as we construct the route.) bit set to 1, then all the one-hop links on the route from the OrigNode O to this router meet the requirements of route discovery, Re "the route", this would presumably be the one recorded in the Address Vector of the RREQ in question? (Multiple RREQs for the same route computation can arrive at a given node with different address vectors, right? Also, the way this is written implies that it does not say anything about "non-one-hop links" on the route, but I don't really know what a link that's not a one-hop link would be. Can we just say "all the hops" or "all the links"? and the route can be used symmetrically. But does that matter for any routers other than TargNode (for any of the AODV-RPL Target Options)? doesn't satisfy the Objective Function. Based on the S bit received in RREQ-DIO, TargNode T determines whether or not the route is symmetric before transmitting the RREP-DIO message upstream towards the OrigNode O. Does that determination affect the construction of the RREP-DIO in any way? (E.g., if there was an S bit.) Figure 5: AODV-RPL with Asymmetric Paired Instances Some discussion of how the third(? second?) intermediate router detects the asymmetry and clears the S bit might be appropriate. Section 6.1 link-local multicast. The DIO MUST contain at least one ART Option (see Section 4.3). The S bit in RREQ-DIO sent out by the OrigNode is set to 1. I'd suggest saying that the required ART Option indicates the TargNode. OrigNode can maintain different RPLInstances to discover routes with different requirements to the same targets. Using the RPLInstanceID pairing mechanism (see Section 6.3.3), route replies (RREP-DIOs) for different RPLInstances can be distinguished. When using different RPLInstances for this purpose, what constitutes "initiates a route discovery process" across those instances -- is it permissible to only increment the sequence number once when initiating multiple discovery processes on different instances? Section 6.2.1 Step 1: If the S bit in the received RREQ-DIO is set to 1, the router MUST determine whether each direction of the link (by which the RREQ- DIO is received) satisfies the Objective Function. In case that the downward (i.e. towards the TargNode) direction of the link does not satisfy the Objective Function, the link can't be used symmetrically, thus the S bit of the RREQ-DIO to be sent out MUST be set as 0. If the S bit in the received RREQ-DIO is set to 0, the router MUST determine into the upward direction (towards the OrigNode) of the link. If the upward direction of the link can satisfy the Objective Function, and the router's Rank would not exceed the MaxUseRank limit, the router joins the DODAG of the RREQ-Instance. The router that transmitted the received RREQ-DIO is selected as the preferred parent. Otherwise, if the Objective Function is not satisfied or the MaxUseRank limit is exceeded, the router MUST discard the received RREQ-DIO and MUST NOT join the DODAG. The way this is written is confusing to me. It seems to say that (1) you only check the upward direction is the S bit in the received RREQ-DIO is set to zero, and (2) the only time you join the DODAG is if you're checking the upward direction. So, when the received S-bit is 1, do you just never join the DODAG? I assume this is not the intent, but that is how I interpret the words that are on the page. Sequence Number. The Destination Address and the RPLInstanceID respectively can be learned from the DODAGID and the RPLInstanceID of the RREQ-DIO, and the Source Address is the address used by the local router to send data to the OrigNode. The Next Hop is the "Source Address is the address used by the local router to send data to the OrigNode" seems like the definition of the source address in a route table entry, not a procedure for how to set it. Should this be the address used by the local router to send data to the preferred parent? Section 6.3.1 implementation-specific and out of scope. If the implementation selects the symmetric route, and the L bit is not 0, the TargNode MAY delay transmitting the RREP-DIO for duration RREP_WAIT_TIME to await a symmetric route with a lower Rank. The value of RREP_WAIT_TIME is set by default to 1/4 of the time duration determined by the L bit. There is no L *bit* in the RREQ option or the RFC 6550 DIO. There is a two-bit L field in the RREQ option, but even if I replace 'bit' with 'field', it's still not clear why having a DODAG with no lifetime limit implies that delaying the RREP-DIO is not allowed. Section 6.3.2 When a RREQ-DIO arrives at a TargNode with the S bit set to 0, the TargNode MUST build a DODAG in the RREP-Instance rooted at itself in I don't understand how the definite article is appropriate for "the RREP-Instance rooted at itself" -- I thought there were multiple (paired) instances corresponding to the various RREQ DODAGs that requested routes to TargNode. RREP_WAIT_TIME to await a route with a lower Rank. The value of RREP_WAIT_TIME is set by default to 1/4 of the time duration determined by the L bit. ("L bit" again, and no indication of what to do for L==0.) The settings of the fields in RREP option and ART option are the same as for the symmetric route, except for the S bit. There is no S bit in the RREP. What is this intending to say? Section 6.3.3 When preparing the RREP-DIO, a TargNode could find the RPLInstanceID to be used for the RREP-Instance is already occupied by another RPL Instance from an earlier route discovery operation which is still active. In other words, it might happen that two distinct OrigNodes need routes to the same TargNode, and they happen to use the same RPLInstanceID for RREQ-Instance. In this case, the occupied RPLInstanceID MUST NOT be used again. [...] A reminder might be helpful that the RPLInstanceID is a property of a DODAG, and a DODAG is identified by the DODAGID, which in this case is the address of the TargNode. So that is why we need to avoid reusing RPLInstanceID in the context of the RREP-DIO, whereas there is no problem with collisions in RPLInstanceID across RREQ-DIOs (where the DODAGID is the OrigNode address, that suffices to disambiguate). shift to be applied to original RPLInstanceID. When the new RPLInstanceID after shifting exceeds 63, it rolls over starting at 0. I thought RPLInstanceID was a full 8-bit field (even though Shift is only six bits); wouldn't rollover happen after 255? For example, the original RPLInstanceID is 60, and shifted by 6, the new RPLInstanceID will be 2. Related operations can be found in Section 6.4. (So this example wouldn't actually show rollover.) Section 6.4 Upon receiving a RREP-DIO, a router which does not belong to the RREQ-Instance goes through the following steps: Do we care about RREQ-Instance membership or RREP-Instance membership, for processing the RREP-DIO? Step 1: If the S bit is set to 1, the router MUST proceed to step 2. There is no S bit in the RREP option! and the destination address is learned from the DODAGID. The lifetime is set according to DODAG configuration (i.e., not the L bit) and can be extended when the route is actually used. The ("L bit" again) Upon receiving a RREP-DIO, a router which already belongs to the RREQ-Instance SHOULD drop the RREP-DIO. (RREQ-Instance vs RREP-Instance, again.) Section 10 It seems like a malicious node that forges a gratuitous RREP could do significant damage as well, so that might be worth mentioning. routing loop. The TargNode MUST NOT generate a RREP if one of its addresses is present in the Address Vector. An Intermediate Router MUST NOT forward a RREP if one of its addresses is present in the Address Vector. These requirements seem important enough that I'd prefer to seem them imposed in the main body text that covers RREP handling, and the security considerations mentioned here and referring to those handling requirements. From nobody Thu Apr 22 17:46:07 2021 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 968AC3A1C89; Thu, 22 Apr 2021 17:45:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Meral Shirazipour via Datatracker To: Cc: draft-ietf-roll-aodv-rpl.all@ietf.org, last-call@ietf.org, roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161913875755.29365.13743105077300345063@ietfa.amsl.com> Reply-To: Meral Shirazipour Date: Thu, 22 Apr 2021 17:45:57 -0700 Archived-At: Subject: [Roll] Genart last call review of draft-ietf-roll-aodv-rpl-10 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: Fri, 23 Apr 2021 00:45:58 -0000 Reviewer: Meral Shirazipour Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-roll-aodv-rpl-10 Reviewer: Meral Shirazipour Review Date: 2021-04-22 IETF LC End Date: 2021-03-31 IESG Telechat date: 2021-04-22 Summary: This draft is almost ready to be published as Standards Track RFC but I have some comments. Major issues: Minor issues: Other than some issues already reported on the list, the draft is a bit hard to follow, Intro could be improved and the terminology was very long, maybe presenting terms in category would help. Nits/editorial comments: Section B1 says "Reclassified [RFC6998] and [RFC7416] as Informational." RFC7416 was already Informational. What that a typo? This is not part of the final RFC - I was just trying to follow the various diffs of the document. From nobody Thu Apr 22 20:56:48 2021 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 835853A0C9F; Thu, 22 Apr 2021 20:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earthlink.net; domainkeys=pass (2048-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.net 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 oyZxgGqFRnTl; Thu, 22 Apr 2021 20:56:37 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 743C53A0C5C; Thu, 22 Apr 2021 20:56:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1619150196; bh=9eckdJ+yfg6lfV7CcL3398cmPynwexrrmykQ aDTWeBs=; h=Received:Subject:To:Cc:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Content-Language:X-ELNK-Trace: X-Originating-IP; b=WfcaSWHTIycKCj9K3dPW9dK5WywHxgCOJtOgW9H27qvfaY Hb+j59Nz0qnWukDe3BiLvVCmvFpsZgqU9ruUgbuBxYW2Q/F8G5vl1Tml/Wd5jOfKjof 0cJWT2hj3NfcIoDQZdcfRlA9jWJoltwzq6HPzMGA+0NCbRKvCB8h887NP4COyi8GkO9 xbv6UkOooroflwiLvJHZ4TyiGtvO3I3GhJ1CM4H6L36SE1C3sqqvNy3fGtOVATV3ArW xzVLIuuwRsJJZf5zQBKBWoeQtFS4Gpk5xMH0/ZJoJrAtA2oOyOaSgP/k44Zazy7aEAi Herbl0CE0fG9EgWvgV+fGKXu6Mcw== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=pww/bE/sEk8ho/Pv2neTqZrLFa6IfQ6S5Fqa41H2flm8ysNJEPvXaP3ZmwzeHBU8V8QdhrkDY5VeMp9ZyknkHiFIMQRr4MMw/s6ox5dxVK/ElUMPkyKhtr3ASS2IEjPu+X9mBooBU87XlkPwxQr8oo1KpryGHrPVGB52YeCbnZRkC3Ivq8lAu9q6J0oIDFsfifrSNSVVQPG17yON8dn/OUocRolQyRnk5+0I+MVJHl1rAp72inz4//tjx4XFjmSUC2uGR4YjeLNuTKMWYKkj+3tAtaGEllZQ9mCsGwNLSKFK37j+6oy6RpTYI+dwh0sOlBoEpAkb7300HVuWejzZVQ==; h=Received:Subject:To:Cc:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Content-Language:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.196] (helo=[192.168.1.72]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4) (envelope-from ) id 1lZmvh-000CFM-Qi; Thu, 22 Apr 2021 23:56:33 -0400 To: Meral Shirazipour , gen-art@ietf.org Cc: draft-ietf-roll-aodv-rpl.all@ietf.org, last-call@ietf.org, roll@ietf.org References: <161913875755.29365.13743105077300345063@ietfa.amsl.com> From: Charlie Perkins Message-ID: <1f0711f0-5657-4ce5-e4cd-b8a5961c1962@earthlink.net> Date: Thu, 22 Apr 2021 20:56:32 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 In-Reply-To: <161913875755.29365.13743105077300345063@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956df8303b86ceddf554ddd58261582a06ece7f818a0bd81870350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: Subject: Re: [Roll] Genart last call review of draft-ietf-roll-aodv-rpl-10 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, 23 Apr 2021 03:56:39 -0000 Hello Meral, Regarding the following: On 4/22/2021 5:45 PM, Meral Shirazipour via Datatracker wrote: > Section B1 says "Reclassified [RFC6998] and [RFC7416] as Informational." > RFC7416 was already Informational. What that a typo? > This is not part of the final RFC - I was just trying to follow the various > diffs of the document. > > This just meant to say that a document which was previously listed as a Normative Reference was changed to be listed as an Informational Reference.  It doesn't affect anything about the actual referenced document. > Minor issues: > Other than some issues already reported on the list, the draft is a bit hard to > follow, Intro could be improved and the terminology was very long, maybe > presenting terms in category would help. We will have to look at how this might be improved.  If you think of any more specific suggestions please send them also. Naturally Yours, Charlie P. From nobody Fri Apr 23 06:34:25 2021 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 777B83A14F6 for ; Thu, 22 Apr 2021 13:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 m32GJqRhxWVB for ; Thu, 22 Apr 2021 13:21:55 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FF363A14F3 for ; Thu, 22 Apr 2021 13:21:55 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 673B6F407C8; Thu, 22 Apr 2021 13:21:49 -0700 (PDT) To: wintert@acm.org, pthubert@cisco.com, abr@sdesigns.dk, jhui@archrock.com, kelsey@ember.com, pal@cs.stanford.edu, kpister@dustnetworks.com, rstruik.ext@gmail.com, jpv@cisco.com, roger.alexander@cooperindustries.com, aretana.ietf@gmail.com, jgs@juniper.net, martin.vigoureux@nokia.com, dominique.barthel@orange.com, mariainesrobles@googlemail.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Cc: nmalykh@ieee.org, roll@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20210422202149.673B6F407C8@rfc-editor.org> Date: Thu, 22 Apr 2021 13:21:49 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Fri, 23 Apr 2021 06:34:23 -0700 Subject: [Roll] [Editorial Errata Reported] RFC6550 (6554) 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, 22 Apr 2021 20:22:01 -0000 The following errata report has been submitted for RFC6550, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6554 -------------------------------------- Type: Editorial Reported by: Nikolai Malykh Section: 9.9 Original Text ------------- 2. The node MUST logically construct groupings of its DAO parents while populating the Path Control field, where each group consists of DAO parents of equal preference. Those groups MUST then be ordered according to preference, which allows for a logical mapping of DAO parents onto Path Control subfields (see Figure 27). Groups MAY be repeated in order to extend over the entire bit width of the patch control field, but the order, including repeated groups, MUST be retained so that preference is properly communicated. Corrected Text -------------- 2. The node MUST logically construct groupings of its DAO parents while populating the Path Control field, where each group consists of DAO parents of equal preference. Those groups MUST then be ordered according to preference, which allows for a logical mapping of DAO parents onto Path Control subfields (see Figure 27). Groups MAY be repeated in order to extend over the entire bit width of the path control field, but the order, including repeated groups, MUST be retained so that preference is properly communicated. Notes ----- Typo - patch instead of path Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6550 (draft-ietf-roll-rpl-19) -------------------------------------- Title : RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks Publication Date : March 2012 Author(s) : T. Winter, Ed., P. Thubert, Ed., A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, JP. Vasseur, R. Alexander Category : PROPOSED STANDARD Source : Routing Over Low power and Lossy networks Area : Routing Stream : IETF Verifying Party : IESG From nobody Fri Apr 23 06:34:29 2021 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 854853A09E1; Thu, 22 Apr 2021 13:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 uf13YaBoeJ0S; Thu, 22 Apr 2021 13:55:20 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8ECF3A09E8; Thu, 22 Apr 2021 13:55:19 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 0A0C7F407CC; Thu, 22 Apr 2021 13:55:14 -0700 (PDT) To: nmalykh@ieee.org, wintert@acm.org, pthubert@cisco.com, abr@sdesigns.dk, jhui@archrock.com, kelsey@ember.com, pal@cs.stanford.edu, kpister@dustnetworks.com, rstruik.ext@gmail.com, jpv@cisco.com, roger.alexander@cooperindustries.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Cc: aretana.ietf@gmail.com, iesg@ietf.org, roll@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20210422205514.0A0C7F407CC@rfc-editor.org> Date: Thu, 22 Apr 2021 13:55:14 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Fri, 23 Apr 2021 06:34:23 -0700 Subject: [Roll] [Errata Verified] RFC6550 (6554) 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, 22 Apr 2021 20:55:26 -0000 The following errata report has been verified for RFC6550, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6554 -------------------------------------- Status: Verified Type: Editorial Reported by: Nikolai Malykh Date Reported: 2021-04-22 Verified by: Alvaro Retana (IESG) Section: 9.9 Original Text ------------- 2. The node MUST logically construct groupings of its DAO parents while populating the Path Control field, where each group consists of DAO parents of equal preference. Those groups MUST then be ordered according to preference, which allows for a logical mapping of DAO parents onto Path Control subfields (see Figure 27). Groups MAY be repeated in order to extend over the entire bit width of the patch control field, but the order, including repeated groups, MUST be retained so that preference is properly communicated. Corrected Text -------------- 2. The node MUST logically construct groupings of its DAO parents while populating the Path Control field, where each group consists of DAO parents of equal preference. Those groups MUST then be ordered according to preference, which allows for a logical mapping of DAO parents onto Path Control subfields (see Figure 27). Groups MAY be repeated in order to extend over the entire bit width of the path control field, but the order, including repeated groups, MUST be retained so that preference is properly communicated. Notes ----- Typo - patch instead of path -------------------------------------- RFC6550 (draft-ietf-roll-rpl-19) -------------------------------------- Title : RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks Publication Date : March 2012 Author(s) : T. Winter, Ed., P. Thubert, Ed., A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, JP. Vasseur, R. Alexander Category : PROPOSED STANDARD Source : Routing Over Low power and Lossy networks Area : Routing Stream : IETF Verifying Party : IESG From nobody Fri Apr 23 06:34:33 2021 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 933943A0825 for ; Fri, 23 Apr 2021 06:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 7T5cj2IF3RnG for ; Fri, 23 Apr 2021 06:30:53 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A8513A0835 for ; Fri, 23 Apr 2021 06:30:36 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A3CD8F407DC; Fri, 23 Apr 2021 06:30:28 -0700 (PDT) To: pthubert@cisco.com, mcr+ietf@sandelman.ca, aretana.ietf@gmail.com, jgs@juniper.net, martin.vigoureux@nokia.com, dominique.barthel@orange.com, mariainesrobles@googlemail.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Cc: nmalykh@ieee.org, roll@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20210423133028.A3CD8F407DC@rfc-editor.org> Date: Fri, 23 Apr 2021 06:30:28 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Fri, 23 Apr 2021 06:34:23 -0700 Subject: [Roll] [Editorial Errata Reported] RFC9010 (6556) 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, 23 Apr 2021 13:30:58 -0000 The following errata report has been submitted for RFC9010, "Routing for RPL (Routing Protocol for Low-Power and Lossy Networks) Leaves". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6556 -------------------------------------- Type: Editorial Reported by: Nikolai Malykh Section: 4.1 Original Text ------------- [RFC6775] also introduces the Address Registration Option (ARO), which is carried in the unicast Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages between the 6LoWPAN Node (6LN) and the 6LoWPAN router (6LR). It also defines the Duplicate Address Request (DAR) and Duplicate Address Confirmation (DAC) messages between the 6LR and the 6LBR). In an LLN, the 6LBR is the central repository of all the Registered Addresses in its domain and the source of truth for uniqueness and ownership. Corrected Text -------------- [RFC6775] also introduces the Address Registration Option (ARO), which is carried in the unicast Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages between the 6LoWPAN Node (6LN) and the 6LoWPAN router (6LR). It also defines the Duplicate Address Request (DAR) and Duplicate Address Confirmation (DAC) messages between the 6LR and the 6LBR. In an LLN, the 6LBR is the central repository of all the Registered Addresses in its domain and the source of truth for uniqueness and ownership. Notes ----- Extra closing parenthesis Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC9010 (draft-ietf-roll-unaware-leaves-30) -------------------------------------- Title : Routing for RPL (Routing Protocol for Low-Power and Lossy Networks) Leaves Publication Date : April 2021 Author(s) : P. Thubert, Ed., M. Richardson Category : PROPOSED STANDARD Source : Routing Over Low power and Lossy networks Area : Routing Stream : IETF Verifying Party : IESG From nobody Fri Apr 23 08:14:16 2021 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 5ADFF3A1158; Fri, 23 Apr 2021 08:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 5mUQ73j-G4eO; Fri, 23 Apr 2021 08:14:10 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C21EB3A1165; Fri, 23 Apr 2021 08:14:10 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E87E3F4078B; Fri, 23 Apr 2021 08:14:03 -0700 (PDT) To: nmalykh@ieee.org, pthubert@cisco.com, mcr+ietf@sandelman.ca X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Cc: aretana.ietf@gmail.com, iesg@ietf.org, roll@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20210423151403.E87E3F4078B@rfc-editor.org> Date: Fri, 23 Apr 2021 08:14:03 -0700 (PDT) Archived-At: Subject: [Roll] [Errata Verified] RFC9010 (6556) 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, 23 Apr 2021 15:14:15 -0000 The following errata report has been verified for RFC9010, "Routing for RPL (Routing Protocol for Low-Power and Lossy Networks) Leaves". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6556 -------------------------------------- Status: Verified Type: Editorial Reported by: Nikolai Malykh Date Reported: 2021-04-23 Verified by: Alvaro Retana (IESG) Section: 4.1 Original Text ------------- [RFC6775] also introduces the Address Registration Option (ARO), which is carried in the unicast Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages between the 6LoWPAN Node (6LN) and the 6LoWPAN router (6LR). It also defines the Duplicate Address Request (DAR) and Duplicate Address Confirmation (DAC) messages between the 6LR and the 6LBR). In an LLN, the 6LBR is the central repository of all the Registered Addresses in its domain and the source of truth for uniqueness and ownership. Corrected Text -------------- [RFC6775] also introduces the Address Registration Option (ARO), which is carried in the unicast Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages between the 6LoWPAN Node (6LN) and the 6LoWPAN router (6LR). It also defines the Duplicate Address Request (DAR) and Duplicate Address Confirmation (DAC) messages between the 6LR and the 6LBR. In an LLN, the 6LBR is the central repository of all the Registered Addresses in its domain and the source of truth for uniqueness and ownership. Notes ----- Extra closing parenthesis -------------------------------------- RFC9010 (draft-ietf-roll-unaware-leaves-30) -------------------------------------- Title : Routing for RPL (Routing Protocol for Low-Power and Lossy Networks) Leaves Publication Date : April 2021 Author(s) : P. Thubert, Ed., M. Richardson Category : PROPOSED STANDARD Source : Routing Over Low power and Lossy networks Area : Routing Stream : IETF Verifying Party : IESG From nobody Fri Apr 23 08:20:49 2021 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 537E03A12F3; Fri, 23 Apr 2021 08:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 fDMWPH00nHyt; Fri, 23 Apr 2021 08:20:37 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC7603A11D7; Fri, 23 Apr 2021 08:19:40 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D83F9F4078C; Fri, 23 Apr 2021 08:19:33 -0700 (PDT) To: pthubert@cisco.com, mariainesrobles@gmail.com, mcr+ietf@sandelman.ca, pthubert@cisco.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Cc: aretana.ietf@gmail.com, iesg@ietf.org, roll@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20210423151933.D83F9F4078C@rfc-editor.org> Date: Fri, 23 Apr 2021 08:19:33 -0700 (PDT) Archived-At: Subject: [Roll] [Errata Verified] RFC9008 (6557) 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, 23 Apr 2021 15:20:48 -0000 The following errata report has been verified for RFC9008, "Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6 Encapsulation in the RPL Data Plane". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6557 -------------------------------------- Status: Verified Type: Editorial Reported by: Pascal Thubert Date Reported: 2021-04-23 Verified by: Alvaro Retana (IESG) Section: 11.1 Original Text ------------- DODAG Configuration Option Flag to Indicate the RPI Flag Day Corrected Text -------------- DODAG Configuration Option Flag to Set the Value of the RPI Option Type Notes ----- The point of the new flag is to avoid a flag day. This text is as the name for Tables 1 and 26 on sections 4.1.3 and 11.1, respectively. -------------------------------------- RFC9008 (draft-ietf-roll-useofrplinfo-44) -------------------------------------- Title : Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6 Encapsulation in the RPL Data Plane Publication Date : April 2021 Author(s) : M.I. Robles, M. Richardson, P. Thubert Category : PROPOSED STANDARD Source : Routing Over Low power and Lossy networks Area : Routing Stream : IETF Verifying Party : IESG From nobody Tue Apr 27 07:24:19 2021 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 6029B3A0BF5 for ; Tue, 27 Apr 2021 07:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=landisgyr.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 eIDSly4pi38T for ; Tue, 27 Apr 2021 07:24:14 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2100.outbound.protection.outlook.com [40.107.21.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB6CE3A0BF3 for ; Tue, 27 Apr 2021 07:24:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jLdSfNzC+3tRNfzf60JdvE4MWb3WLO2ah3bBVBfZfrLxyYMj47XHRsuok3PhIvGE1PaECEx2yhd31jHGi1fqrrAzsWj6933VPKfJHZ2u8bkzg07oGzF5w5jAcOMw5JiafUlpifIAOVHtnZ0fYGdzJB2VKwuMPDFC4sjpCCwjMfzlg3yEkxrk5gAiM5T9jDNM77Jr3yu7xhRBO3s1XoqGR70ksFEgl90oh+sfLJW6k1wnCjwEmurE2yfPxeP+nJ1q/PC8Auj8HNn0NHx4ZJj/degwfV6f7HDlviP66gqqCGMqr5GvGaJ3l/xz57NLQAY8cyVYBEhoAHe3fpBz01ls5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=J8+XH/9W3P0TQrEOvjr1TeYcwLzN8uLwdAb89G9OYXQ=; b=Ft/xeYJp5yi+PW5/zoa0PBxeQfPO2CXVkVU7/zRQ9w+Eff9algJL/LX91pQWPvfmekBXddNF8OPbDAS0X+p+6qXgjz/jBpa7UpkoOzgbae6UJo9DyrfY2r6RhvonZ2N+wGjU1C9VmhM3ne5LEhVDH19pJ+QaZUcabfOkvWZyy2YPJYw+WBeF460BZlhSQYZTcZfXDZ/H3xWGJ1ul2Q/H1/pEPPnLFhwGTQBWhwvcqWOaxqJ+8UEIZ4rnLg8EwGK/Eg3eQSjv0/bECkKPwAOEBJk9WxkstVrP52vEBVmV61guj2Fzha97puihS1Efzds3Zr/mF9pAnM+YOx5rUC5wQA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=landisgyr.com; dmarc=pass action=none header.from=landisgyr.com; dkim=pass header.d=landisgyr.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=landisgyr.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=J8+XH/9W3P0TQrEOvjr1TeYcwLzN8uLwdAb89G9OYXQ=; b=ickjjnadhoeKr4bcySB0mGEpA9LMgCcrnWc4LQqhPoBpeWgP8vDGz8/NDhh4MtOCC9ge09FABYxrFvOBumhmbqSkcGLjj6H4Oj+HwyyhUoiB4LezZcWhvJq8cgNu+kI+L1X1ZsdXiNQv/S5kr7XoyDmJdNMb43d1ckQlTavUXkM= Received: from DBBPR01MB7657.eurprd01.prod.exchangelabs.com (2603:10a6:10:1f3::14) by DBBPR01MB7850.eurprd01.prod.exchangelabs.com (2603:10a6:10:1e6::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4087.25; Tue, 27 Apr 2021 14:24:10 +0000 Received: from DBBPR01MB7657.eurprd01.prod.exchangelabs.com ([fe80::ed6e:84c0:f10e:1b3e]) by DBBPR01MB7657.eurprd01.prod.exchangelabs.com ([fe80::ed6e:84c0:f10e:1b3e%5]) with mapi id 15.20.4065.027; Tue, 27 Apr 2021 14:24:10 +0000 From: "Turner, Randy" To: "'roll@ietf.org'" Thread-Topic: RFC 7731 (MPL) implementations Thread-Index: Adc7cOFUDxvD6K4GSIm65FoOBw71rg== Date: Tue, 27 Apr 2021 14:24:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_724d29b2-602f-4b77-ba15-b7b42511c7c5_ActionId=6fff453d-2436-452f-b1af-ef397e2d0a57; MSIP_Label_724d29b2-602f-4b77-ba15-b7b42511c7c5_ContentBits=0; MSIP_Label_724d29b2-602f-4b77-ba15-b7b42511c7c5_Enabled=true; MSIP_Label_724d29b2-602f-4b77-ba15-b7b42511c7c5_Method=Standard; MSIP_Label_724d29b2-602f-4b77-ba15-b7b42511c7c5_Name=724d29b2-602f-4b77-ba15-b7b42511c7c5; MSIP_Label_724d29b2-602f-4b77-ba15-b7b42511c7c5_SetDate=2021-04-27T14:23:04Z; MSIP_Label_724d29b2-602f-4b77-ba15-b7b42511c7c5_SiteId=ee2cd48b-958f-4be4-9852-b8f104c001b9; authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=landisgyr.com; x-originating-ip: [24.98.201.185] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f7c71172-e63f-4e8f-f68f-08d909881fda x-ms-traffictypediagnostic: DBBPR01MB7850: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3968; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0XwmCEgC7X8uOEjuwilcVk+OzkSPmx+c1rzlmRZrptLmLLvrxeZofV6dYlIy2294ZDLSN6/tHyo1HLo3ElUWxC1A+lzlV1P4PzRDgkaFoDD9Wfl+SznMqVvAwizyllYM5cXnnUx9WauWIl2p5zpYAAUBm9Vg3ZFZJZnqevmsgt09c6edG5toE0oy9VjrJlatIlDdOYULsZyCbAwKsYZIMw818G/uSoMpkcq3zWiH9E0gNhc3TpKoV+Ui0DhRiz4bs3cJ8/z6T47N3OqKqJV4JM7MnHkij6cjV9Nv+r7D8vG8bh3Nq/eT1l88K/wfPGm6zIGF6N5MEW3SEW7JHxaW69/A4WA1i/tulpkL4D0Ekb2uugEGIoX+cfGO3GeW8/cZnLagUACXu9vTu7b7dfae9jNbblmm3m8kKBdHU/Ckyr+edjRC9yiK+QsV7eITUgJn2ti/lep+qZmmPcSVJMuOWpnzqZoxmO3ksnaMgfmuEp7LTtIUe1/rpbsKjtWuLCJd+pDLHh0IikuxpdmPP/mYV41KVGShirex75kR9AQd8zWq1v30ll2SfmZjcBEVkPC16DCqiP2hCgZNocAJLW/IBHxhfOBXHW1n/JHs+tlya6QoqOq5K2VX9oxtVnzQ7Yx63qjEpYmM28yNVyI1GpwLtQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBBPR01MB7657.eurprd01.prod.exchangelabs.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(376002)(136003)(366004)(346002)(39850400004)(6916009)(558084003)(122000001)(4270600006)(2906002)(38100700002)(5660300002)(6506007)(52536014)(478600001)(66446008)(66946007)(8676002)(76116006)(66556008)(66476007)(7696005)(64756008)(316002)(55016002)(9686003)(86362001)(9326002)(26005)(186003)(71200400001)(33656002)(8936002)(491001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?Y5177Wfy9Z7LFM5El3FbpQHyzuWMpEbBYpnLfons2xZjm0OjCfJrWyZDHqMt?= =?us-ascii?Q?gEUI/wnE05J4QrlzOLuHOvHGYL6m5Gvn1EhFgzB47ENQxOKcSKdDqUP7uHy2?= =?us-ascii?Q?9dTYdsUFRKPug7ffIAjTckutjhr4sW84/moiZknZSUdj2SaycOhvDdRd7e3g?= =?us-ascii?Q?0hZdmwBMO6ArMKYGP+KfXIMzJKmWN3X9xd7rlTS53gzKfaSss+Llv4A0cY50?= =?us-ascii?Q?Z12ovWugbSgiu8J12bYDZEMl6ngHPO0EcJxIcj26zCc9wKNn2btiLfv5amPk?= =?us-ascii?Q?EqIh829FQa6XzVaTj0c9nilZtNgNmmsBR7VToPDGzTmfQlL+bXYKlhiEDakQ?= =?us-ascii?Q?7YaPNyjCjawWLFB+N0P8A7ocwOE1eSLBdIj6Hw8uTkOMOf0SlnbFpf+Pdz1I?= =?us-ascii?Q?gW0K74AVJ55okIwJvfhUFUVcrdnTh0WZgncOZ+Pt2Z3h+l2xnOI7t5exu32Q?= =?us-ascii?Q?l5FeHWpiCo5gXzvf+91bRdrlufg83XArr7K0aHqUKKY2nNV5OwbiLRTmr7Ke?= =?us-ascii?Q?spjGIbPsoQu7i21wjuLPlJ1xx83rBTo/cTmYU4lAfcX/INpfAvbEmCvPqJ3d?= =?us-ascii?Q?i0JGu1qJV9P0hDVnh21fMc9c7F3ADoraM90WUV4CHTWNA5HZAEGG8hxogBll?= =?us-ascii?Q?5fHRHUJ+O7KTUsWKRWvjHryCNVD4dWnFxdpNQT+B/SfZeoCifXhrhG/Y2zRD?= =?us-ascii?Q?D0jVXh5bcxmuEwddCRA5UWoBj1FmBcmULYIBtSY0Il5ShVu+EH0QrYz1+nBc?= =?us-ascii?Q?oD2CKYJ9JOVrmBjV0hFZeqL/swiSRT6k+41CvgHAu8hEfvaOfZv2O8UgREx5?= =?us-ascii?Q?LJkMfM0gBZMBcTRSTN+sMLnwAqVBfaSKPCF93j32wUWYwePLh6jHyFRGFiSg?= =?us-ascii?Q?C6DeLf2VGeF3+8zqe4PpCqjlVSr4DYJTZs1RvPdQw77XVwM0rRyR6iLYKm4F?= =?us-ascii?Q?wvSFvceqxG4/9BNRYnHcrz2V8DkbB7AovZ579kTvugGXgXjStY86zIT9X3RZ?= =?us-ascii?Q?e+EFmm37XDE2qUaExgnCQIGO6gzgfUIUsWJ5iOvGCKhTP5yLHmeN1F+YIdTU?= =?us-ascii?Q?wo4udlVSlhvigmqp/kCSAWAWyEhN8Xp9mZFyqZKWTnQaWnUTuzry7DSWwDzM?= =?us-ascii?Q?s+i1xQGXf29IkmIhInnE3oSnO0Sn0HAS7rwpoobu38gaqWAh367xlPBxInvw?= =?us-ascii?Q?nDxVdVIPy7QkpcIN9s7OEFS/eFXqwRiOj3pzBl/5/2lCReKk+Aiin42vmz2q?= =?us-ascii?Q?Gt+R4ryAE0vR63M8rxTGYylgO9v5xy5hxipFAMdOfQc7ZalcDqljFG2OanWm?= =?us-ascii?Q?V2oKOUe8AwlDLTKp2nwyDh7v?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DBBPR01MB765720E3C376AFF8A5081FB080419DBBPR01MB7657eurp_" MIME-Version: 1.0 X-OriginatorOrg: landisgyr.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DBBPR01MB7657.eurprd01.prod.exchangelabs.com X-MS-Exchange-CrossTenant-Network-Message-Id: f7c71172-e63f-4e8f-f68f-08d909881fda X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2021 14:24:10.3793 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ee2cd48b-958f-4be4-9852-b8f104c001b9 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 0AuXlW4rLe7RGwoQ1UjsYZAVBdRO5L6qUx/wIQ5jCPr4otQfPtD1L2hEaeczQE4t93Ltyb6SpDdM0r5SN4cA4qEiyFw8cvjnNUI/YZZgBlI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR01MB7850 Archived-At: Subject: [Roll] RFC 7731 (MPL) implementations 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: Tue, 27 Apr 2021 14:24:18 -0000 --_000_DBBPR01MB765720E3C376AFF8A5081FB080419DBBPR01MB7657eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, Does anyone know if there is a MPL implementation for Linux ? Thanks! R. --_000_DBBPR01MB765720E3C376AFF8A5081FB080419DBBPR01MB7657eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

Does anyone know if there is a MPL implementation fo= r Linux ?

 

Thanks!
R.

--_000_DBBPR01MB765720E3C376AFF8A5081FB080419DBBPR01MB7657eurp_-- From nobody Tue Apr 27 07:34:31 2021 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 315D43A0CC1 for ; Tue, 27 Apr 2021 07:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=mail-udp-cl.20150623.gappssmtp.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 4rUtnPOmQHea for ; Tue, 27 Apr 2021 07:34:21 -0700 (PDT) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 5A31B3A0CB8 for ; Tue, 27 Apr 2021 07:34:07 -0700 (PDT) Received: by mail-ot1-x32f.google.com with SMTP id u21-20020a0568301195b02902a2119f7613so8556846otq.10 for ; Tue, 27 Apr 2021 07:34:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail-udp-cl.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=hVrjFP8JeF4JW6IiXz6r1LDQUtKCAuERDNnPxdcGV/g=; b=jrv3lHcWv84byhkLEKfbb4yGexHoKpjKV6I9GldV5H8M5Gv1X81mugIvmFwVhnWbSx EnT7+F02Cg8ZcZ6TNOs4T3N4hRcxqTOJXQu59tsIZ8vqkUMj5hEBzHczvM1tKvXk8J19 OgH/ZZwOLYr8xo/w/AebfKuQV76y/opNJwk5JYEWAw92pbNPiSEwrvPDEr3Fczrjqd9I hU26w3pzmggmd2R7VoNpt5F5q4mU1m2WRz1D+nih55Na7Pey+GZWe3y0ncOpSqYk4Gwc AHg04LR6gLQ/+cjkAy1cY5q7E4sauHHbyRsEJ9uXuCMasrP47CCXj+imESKAKi877yBT LelA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=hVrjFP8JeF4JW6IiXz6r1LDQUtKCAuERDNnPxdcGV/g=; b=ufbfTlm8L34IEkRmjpOlfuMIP+1PRR8AuLWOkP4Ao3ysUXmm3WMp0Tiv5GUl228mYG deaps9BcIskJSbb9WH+Y2kIAMzMv2vB1cJFnc/H5EfjtpWxqVZc1tzx5+I6yjuOm8Kon LUz4L59/OB2HnJWX5zEZkSgeWBdGdqTcUsICaLL8Yqfb2bHSFvxtU+Sh29Nx4zLq6Hpd bWg4XeCZEU/Es11pdkegucTWGmswU6YFwotSYql039r2kteJ8YEKTcWdEpgA8UvVtxSe 5h7uHvmSUMAoCzAjd+/VBLa0s0JxsFc3X+SF6fwKbDoiSNJF7xPEtNixE35/ObxeV1HB nn9Q== X-Gm-Message-State: AOAM53278+0WDer/1xDQ7yj5zj9x98UoWqPpEDXaHtBuCons/K5uzGjt stp9Yrp+pZcxC0Cgxlk+uJv5Q6RgdJmOJ306gKZ5limNgvknfA== X-Google-Smtp-Source: ABdhPJxq7n7D+MCqCEE3lJ/VeCB3LfcKtd1tVOvysu+c6LYFCqJriiPaYGFpEjMPrLXlNIRpgaaETC+ii4XHYgbdZT4= X-Received: by 2002:a9d:30b:: with SMTP id 11mr1111612otv.298.1619534045588; Tue, 27 Apr 2021 07:34:05 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Prof. Diego Dujovne" Date: Tue, 27 Apr 2021 10:33:54 -0400 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="0000000000007d3eb105c0f527b4" Archived-At: Subject: Re: [Roll] RFC 7731 (MPL) implementations 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: Tue, 27 Apr 2021 14:34:26 -0000 --0000000000007d3eb105c0f527b4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Randy, All, I am also interested in finding a working implementation of MPL, not only for Linux, but also for embedded devices, if available. Thanks you. Diego Le mar. 27 avr. 2021 =C3=A0 10:24, Turner, Randy a =C3=A9crit : > Hi All, > > Does anyone know if there is a MPL implementation for Linux ? > > > > Thanks! > R. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --=20 DIEGO DUJOVNE Profesor Asociado Escuela de Inform=C3=A1tica y Telecomunicaciones Facultad de Ingenier=C3=ADa - Universidad Diego Portales - Chile www.ingenieria.udp.cl (56 2) 676 8125 --0000000000007d3eb105c0f527b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Randy, All,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0I am also interested in finding a working implementatio= n of MPL,
not only for Linux, but also for embedded devices, if a= vailable.
Thanks you.

=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=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Diego= =C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0

Le=C2=A0mar. 27 avr. 2021 =C3=A0=C2= =A010:24, Turner, Randy <R= andy.Turner@landisgyr.com> a =C3=A9crit=C2=A0:

Hi All,

Does anyone know if there is a MPL implementation fo= r Linux ?

=C2=A0

Thanks!
R.

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll


--
DIEG= O DUJOVNE
Profesor Asociado
Escuela de Inform=C3=A1tica y Telecomunic= aciones
Facultad de Ingenier=C3=ADa - Universidad Diego Portales - Chile=
www.ingenier= ia.udp.cl
(56 2) 676 8125
--0000000000007d3eb105c0f527b4-- From nobody Tue Apr 27 13:52:23 2021 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 3FB223A2007 for ; Tue, 27 Apr 2021 13:52:21 -0700 (PDT) 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=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 3QaCicAD0YYN for ; Tue, 27 Apr 2021 13:52:16 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 F1E133A200C for ; Tue, 27 Apr 2021 13:52:15 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id d27so38911994lfv.9 for ; Tue, 27 Apr 2021 13:52:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=nsKxsj9jBdDXjFu3/yQDiLwGcgcYNteU67Y9aiYcG9M=; b=sa5EJ3VvsU3hTpcZGrbsYH5G7HLc+cSKONm2g89eXaIZG784P0Av7R70D7t5B7EL4C ZDXNKGetNLaxPQQicEva1SyL7JD9Rlkx9zzmVDsl7VeBXr3We+pI4fOEg8DEHUDbDf/m ne5V+RUqV4aQvOjAboq3rel6QkchgU/kxb7KDAX7iy22TBZCmY8uWKBUM43D5nHaCl/q irxIb8/9oesl34SVcojsL1WT9uy7vwke7tQhBdJQl5yZoeksbg+F+gE452l8+s76p3Ll vKHsIEO/yu3SnEo3uD1XFrlGp/Eab4rOTT0+Y3DVDB5wl2d0KEEQi2sNCAtl+MCo3CSW jNog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=nsKxsj9jBdDXjFu3/yQDiLwGcgcYNteU67Y9aiYcG9M=; b=GFI2O2jGdvCmpNtFkdcqQq6RNhdVjhAHTLgenjdV/8fNijDbXsc6g4acrf+FJ6U1v/ YoWNt01SEvoT6BS1zuJ+gjHO8kz7c/hNLXRMoxxPvGiCTYvKrUGzO+nDBEz295SOJJea 4pdp3sLvt71Xfj6IfLP8TZVlMU6DNDH2DT+HW3a9INwmaB34kmvaCvtprXe+CaJNv74C ld4/e1+6MwQpNN5TkzkEN+fyPPGWN0aBDVWfMFBtFDR5sEa9LzzuG3Df9tEasGUOJGKC xDd08VgEyh0EtLrk5YY7GT8MXUJhlaLla1D4TVipNdFP31mslge9PlnaIA4NDAQzcuAM q+6w== X-Gm-Message-State: AOAM530YXN3nERdqLj4HsGmpu+MeiVtLVlNh/Tpr/Rxza6xFf1uVW7Ck 3CEY8DYY/oR1SFLbMKQVZSU+Hqe6dX2oQanFKIQb6+/0 X-Google-Smtp-Source: ABdhPJxgRcqI4DN8WYQUYPq4dIHbUkMhnxGwKZNlk4xusNs64MWkwQ35qpquWkbw6yGWjcPl6+HBClHVEaMs/syfmmg= X-Received: by 2002:a05:6512:3b89:: with SMTP id g9mr17196501lfv.499.1619556733297; Tue, 27 Apr 2021 13:52:13 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:8717:0:0:0:0:0 with HTTP; Tue, 27 Apr 2021 13:52:12 -0700 (PDT) In-Reply-To: References: From: Badis Djamaa Date: Tue, 27 Apr 2021 22:52:12 +0200 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="000000000000c82a8b05c0fa6f56" Archived-At: Subject: Re: [Roll] RFC 7731 (MPL) implementations 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: Tue, 27 Apr 2021 20:52:21 -0000 --000000000000c82a8b05c0fa6f56 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Diego, All, Contiki-ng has an implementation of MPL here https://github.com/contiki-ng/contiki-ng/tree/develop/os/net/ipv6/multicast A how-to document is available at https://github.com/contiki-ng/contiki-ng/wiki/Documentation:-IPv6-multicast Best, Badis On Tuesday, 27 April 2021, Prof. Diego Dujovne wrote: > Randy, All, > I am also interested in finding a working implementation of MPL, > not only for Linux, but also for embedded devices, if available. > Thanks you. > Diego > > Le mar. 27 avr. 2021 =C3=A0 10:24, Turner, Randy a =C3=A9crit : >> >> Hi All, >> >> Does anyone know if there is a MPL implementation for Linux ? >> >> >> >> Thanks! >> R. >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > > -- > DIEGO DUJOVNE > Profesor Asociado > Escuela de Inform=C3=A1tica y Telecomunicaciones > Facultad de Ingenier=C3=ADa - Universidad Diego Portales - Chile > www.ingenieria.udp.cl > (56 2) 676 8125 > --000000000000c82a8b05c0fa6f56 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Diego, All,

Contiki-ng has an implementation of MPL here https://githu= b.com/contiki-ng/contiki-ng/wiki/Documentation:-IPv6-multicast

B= est, Badis

On Tuesday, 27 April 2021, Prof. Diego Dujovne <diego.dujovne@mail.udp.cl> wr= ote:
> Randy, All,
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0I am also interested in finding a working implementatio= n of MPL,
> not only for Linux, but also for embedded devices, if ava= ilable.
> Thanks you.
> =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=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Diego=C2=A0
> =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
&g= t; Le=C2=A0mar. 27 avr. 2021 =C3=A0=C2=A010:24, Turner, Randy <Randy.Turner@landisgyr.com> a= =C3=A9crit=C2=A0:
>>
>> Hi All,
>>
>> = Does anyone know if there is a MPL implementation for Linux ?
>>>> =C2=A0
>>
>> Thanks!
>> R.
>>= ;
>> _______________________________________________
>> R= oll mailing list
>> Roll@ietf.org=
>> htt= ps://www.ietf.org/mailman/listinfo/roll
>
>
> --
&= gt; DIEGO DUJOVNE
> Profesor Asociado
> Escuela de Inform=C3=A1= tica y Telecomunicaciones
> Facultad de Ingenier=C3=ADa - Universidad= Diego Portales - Chile
> ww= w.ingenieria.udp.cl
> (56 2) 676 8125
> --000000000000c82a8b05c0fa6f56-- From nobody Wed Apr 28 12:33:00 2021 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 63CF73A1D24 for ; Wed, 28 Apr 2021 12:32:58 -0700 (PDT) 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 o-8npisn7ai2 for ; Wed, 28 Apr 2021 12:32:53 -0700 (PDT) Received: from mail-vk1-xa2d.google.com (mail-vk1-xa2d.google.com [IPv6:2607:f8b0:4864:20::a2d]) (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 A1C253A1D21 for ; Wed, 28 Apr 2021 12:32:53 -0700 (PDT) Received: by mail-vk1-xa2d.google.com with SMTP id n74so1310337vkc.6 for ; Wed, 28 Apr 2021 12:32:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=AUwlqrMSrArae5jFZthTfCVTH9mT32YlfNlpEoMLBQ4=; b=D3hd/bYL7uFHpUvmcAwpYvOtiEySg+RXNWdIrVpIVC0Ev1jWcH43xndDwENnXlcTl/ 3Jw3+MBrQczYwEZg51N8q6sFp43fv1MjuPV8V8EIpfeG+vum6SwX82d5EKM3EV7fscx4 UXfNf4yQjMfAHRUYmGxjtAExfsj75Of85CKd4K45jsa7esJTw3A2Jus/Eb44vTKiO/hK Vr9nMVYqhfIZ4bDwSBmq6R4Xev49f1LJvU1TX0FTSZxA8nMWeFddcsqRGzGpvrrSo/cY 89mJAnVGlriIwjNJKhwtOFjdFJDb8qTwxT1NunLoSk/16OHbwbvcfXHQjSgpNimWzTUt JkgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=AUwlqrMSrArae5jFZthTfCVTH9mT32YlfNlpEoMLBQ4=; b=IA68yepESzZdkH8YrqGCNfEE35XoRBBeT/+8Yvt5TGWIiAUmkl2AE4ENkeJJB/EOI8 4IfkfN0e2An3sQ9NzB6OGlX/wiofYw/C6iBH03d0QzdHF2gdcv5YerdghDqRzzuV1oM1 11p1irrPDwZTnK9v5TIXAyKFMVWeBYau+wtIZ6exisFt925s5TXdQC55pva4H9T/061q j4BQMfhjnnU7Yg32a7Rha+5KWDfLhtOoTxyl29RC/8eqlGrhklqAVe3N+Cjy6WcVVm0h vmRMqtpzzyJt6bvj9fFa7PKc08TFD4VHqvVfY/kGeCxw+rhZ4qDY4XES64M8i58geGrr EgKA== X-Gm-Message-State: AOAM530zDRsnmtP3PNcc6G+PVI6kINsL9raT3xEdQz9/njcXkqCzz7/b f6xOG0o2nWC6asLq0su6yI92ESDPFvqu+PgBA+PbOvSi5ZI= X-Google-Smtp-Source: ABdhPJxak1LTWMIi3KJeZmBI+ap7ycMna8b4L3YWu0bNLi61K8rOLK3dTH/xYStR744PN3/he8GpEea6DWqZP5KlB+4= X-Received: by 2002:a1f:99cc:: with SMTP id b195mr2707785vke.19.1619638371630; Wed, 28 Apr 2021 12:32:51 -0700 (PDT) MIME-Version: 1.0 From: Ines Robles Date: Wed, 28 Apr 2021 22:32:15 +0300 Message-ID: To: roll Content-Type: multipart/alternative; boundary="000000000000ce43a105c10d71e0" Archived-At: Subject: [Roll] Roll at IETF 111 - 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: Wed, 28 Apr 2021 19:32:58 -0000 --000000000000ce43a105c10d71e0 Content-Type: text/plain; charset="UTF-8" Dear all, In order to help us assess the need for a ROLL session at the IETF 111 meeting, would you please fill the following form *by 20th May.* https://www.surveymonkey.com/r/JTSD7QK (estimated time to fill it: 2 minutes) Thank you in advance, Ines and Dominique --000000000000ce43a105c10d71e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,=C2=A0

In order to help us ass= ess the need for a ROLL session at the IETF 111 meeting, would you please f= ill the following form=C2=A0by 20th May.
=C2=A0
https://www.surveymonkey.com/r/JTSD7QK=C2=A0 (estimated time to fill i= t: 2 minutes)

Thank you in advance,

Ines and Dominique=C2=A0
--000000000000ce43a105c10d71e0-- From nobody Fri Apr 30 23:15:21 2021 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 239213A36E2; Fri, 30 Apr 2021 23:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 4P80cebU9GsM; Fri, 30 Apr 2021 23:15:14 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5F783A36DF; Fri, 30 Apr 2021 23:15:14 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 94B63F407A3; Fri, 30 Apr 2021 23:14:57 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, roll@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20210501061457.94B63F407A3@rfc-editor.org> Date: Fri, 30 Apr 2021 23:14:57 -0700 (PDT) Archived-At: Subject: [Roll] =?utf-8?q?RFC_9035_on_A_Routing_Protocol_for_Low-Power_an?= =?utf-8?q?d_Lossy_Networks_=28RPL=29_Destination-Oriented_Directed_Acycli?= =?utf-8?q?c_Graph_=28DODAG=29_Configuration_Option_for_the_6LoWPAN_Routin?= =?utf-8?q?g_Header?= 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: Sat, 01 May 2021 06:15:20 -0000 A new Request for Comments is now available in online RFC libraries. RFC 9035 Title: A Routing Protocol for Low-Power and Lossy Networks (RPL) Destination-Oriented Directed Acyclic Graph (DODAG) Configuration Option for the 6LoWPAN Routing Header Author: P. Thubert, Ed., L. Zhao Status: Standards Track Stream: IETF Date: April 2021 Mailbox: pthubert@cisco.com, liz3@cisco.com Pages: 9 Updates: RFC 8138 I-D Tag: draft-ietf-roll-turnon-rfc8138-18.txt URL: https://www.rfc-editor.org/info/rfc9035 DOI: 10.17487/RFC9035 This document updates RFC 8138 by defining a bit in the Routing Protocol for Low-Power and Lossy Networks (RPL) Destination-Oriented Directed Acyclic Graph (DODAG) Configuration option to indicate whether compression is used within the RPL Instance and to specify the behavior of nodes compliant with RFC 8138 when the bit is set and unset. This document is a product of the Routing Over Low power and Lossy networks Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC