From nobody Wed Aug 4 13:31:35 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 DEC3F3A0932; Wed, 4 Aug 2021 13:31:32 -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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-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 SmuSBnBRf8Gg; Wed, 4 Aug 2021 13:31:30 -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 B63443A0931; Wed, 4 Aug 2021 13:31:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by duch.mimuw.edu.pl (Postfix) with ESMTP id 88679600A06EB; Wed, 4 Aug 2021 22:31:25 +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 xNQPj0a1kBOg; Wed, 4 Aug 2021 22:31:23 +0200 (CEST) Received: from Konrads-MacBook-Pro.local (unknown [IPv6:2a02:a311:813e:880:6021:1a6c:1c03:8001]) (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; Wed, 4 Aug 2021 22:31:22 +0200 (CEST) From: Konrad Iwanicki To: roll@ietf.org Cc: roll-chairs@ietf.org Message-ID: Date: Wed, 4 Aug 2021 22:31:15 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Roll] Review of draft-ietf-roll-enrollment-priority-04 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, 04 Aug 2021 20:31:33 -0000 Dear authors, This is the first review I am doing for IETF's draft, so any suggestions on how I could improve the quality of my future reviews are welcome. I have the following major issues with the draft. Perhaps some of them have been covered during some meetings (sorry for missing those); my comments are based just on what I got from the draft (and the related drafts). 1. I was confused by two seemingly contradictory statements. Par. 2 of sect. 2 (starting with "With this specification") states that the introduced option "MUST be propagated down the DODAG without modification" (compared to what is issued by the DODAG root). However, par. 2 of sect. 2.1 (starting with "6LRs that support this option") states that "nodes adjust this base value based upon their observed congestion, emitting their adjusted DIO value to their children." What I understand is that the adjustment applies only in a particular case. More specifically, if a node receives the option, it copies it to its DIOs without any modification. In contrast, if the node does not receive the option but is capable of processing it, then it synthesizes the option for its DIOs by taking as the min priority the base value (0x40) adjusted with the node's local observations. This seems inconsistent, though. In particular, two children with the same parent can emit DIOs with different values of min priority. Why not simply omit the option in such a case? 2. The draft implicitly assumes a DIO processing policy that differs from RPL's original one. More specifically, throughout the draft, it is implied or assumed that a node processes the option received only from its parent(s). For example: - par. 8 of sect. 1 (starting with "A network operator might"): "... it would like to adjust the enrollment priority (the proxy priority field of [...]) among all nodes in the subtree of a congested link."; - par. 1 of sect. 2.1 (starting with "A 6LR which did not support"): "Children and grandchildren nodes would therefore not receive any telemetry via that path and need to assume a default value."; - par. 2 of sect. 2.1: "6LRs that support this option, but whose parent does not send it [...]" and the rest of the paragraph as well. In contrast, RFC 6550, sect. 8.2.3 states that DIOs not only from parents but also other neighbors must be processed by a node. This guarantees correct route formation and maintenance. Therefore, if the draft changes this policy with respect to the introduced option, I would expect it to state this change explicitly. Such a change would also require answering several questions, notably: - From which parent do we process the option? - If only from the preferred parent, what happens if a node has none? - If from any, then what happens if a node gets different values of min priority or DODAG_Size from different parents? However, I believe that a meta question worth answering first is: Do we want to have different min priority values in different subtrees or just one global value for the entire DODAG? Either of the answers in my view requires explicit formulation and preferably also an explanation in the draft. 3. Even if the draft identified a single parent as the only source of min priority values for a node, there still would be a problem of value consistency. Since the DODAG root can change its values of min priority and DODAG_Size and since a node can change its parents, there may still be a case when the node must decide whether to adopt the newly received values or not. Without a proper conflict resolution policy, it may be the case that when the root, for example, disables enrollment, then enables it again, then the DODAG may exhibit strange behaviors: the root's decision may not be propagated to all nodes, a decision may be revoked by nodes that have already accepted it, and the like. There are many ways in which such conflict resolution can be provided. If I may suggest anything, I would recommend adding to the option a lollipop sequence counter (like those described in RFC 6550, sect. 7.2), let's call it osn. It would effectively order different versions of the option values produced by the DODAG root. In effect, whenever a node received an option (be it from a parent or another neighbor, depending on the way the previous issues are addressed), it would adopt the min priority and DODAG_Size values the option carries if and only if the osn value in the received option is greater than the node's locally stored osn. This would guarantee eventual consistency and avoid strange behaviors such as those mentioned above. 4. Why put DODAG_Size in the option? I can imagine that other services/protocols would like to use it as well, and extracting this information from an option related solely to enrollment does not seem the best idea. I have been thinking for some time about an option for RPL that would provide some aggregate information about the DODAG to the nodes, such as its size, max depth, and the like. The option could also be used in the enrollment process. Do you think this makes sense? 5. It should be made clearer in the draft what is actually being configured. The only place where field "proxy priority" of EB appears in the entire draft is par. 8 of sect. 1. Reading the draft for the first time I was confused what min priority for the option is used for and what is actually adjusted at various places. Apart from these major issues, I have also a few editorial suggestions. A. After the par. 1 of sect. 1, I would introduce a subsection heading titled, for instance, "Terminology Disambiguation" to prepare the readers for what they are going to see next. B. Similarly, before par. 5 of sect. 1 (starting with "It has become clear that not every routing member"), I would introduce a subsection heading titled "Motivation and Overview", just "Overview", or something along these lines. C. I would promote the "Terminology" subsection to a section. D. I would move par. 1 of sect. 2 (starting with "The size of the DODAG is measured by the Root") toward the end of sect. 1 as it has little to do with the option definition. E. I would fix the bullet list in sect. 2.1 so that it renders correctly in the text version of the draft. Finally, I have numerous small editorial suggestions, but they seem immaterial at this point. Hope the review helps. Best, -- - Konrad Iwanicki. From nobody Thu Aug 5 23:48:05 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 913053A2176; Thu, 5 Aug 2021 23:48:03 -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=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 3ptMO5uYzCzu; Thu, 5 Aug 2021 23:47:58 -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 75EBF3A2175; Thu, 5 Aug 2021 23:47:58 -0700 (PDT) Received: by mail-ed1-x529.google.com with SMTP id y7so11707931eda.5; Thu, 05 Aug 2021 23:47:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7W5bBKaHHqBJjKMxlAO9TW1noxH6n/+AhHi3u2AjWb4=; b=kzEofB+JEl8stEpF98YmvuE0AZO2JyMaT6/cIkrLh3btv/GOHeUOV/ElSsoliOnvSy n8Uxhc1MtcwkieltrkAanaEZmdGsBp3YYRj+AccCj3y/7hMWwn4Fot2f4P1sj4D8NmAQ lQyUuwGlPhVNKGIvPc2+PSE8rIV5ueRVKzeTkBkD68Pxkedu1MR++IJ9uc4KrOmIwOdq nE9poU/KKYoKEGicd0qadppKE80/cOpDVazbbp2bR6rN2bFwJ4+s4PuzlgRLHXoNHX6N fIn2mFKOGzNsTwUatWbQWVNi18TSqIK8q/EnjH0nPHjf8RGyJUnHjx3eSmC7sGgmjGNp G69A== 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:cc; bh=7W5bBKaHHqBJjKMxlAO9TW1noxH6n/+AhHi3u2AjWb4=; b=DyMuYh3e+wMiXnFYakuadb4ha/YhKrIFyAu40HHlQy3XZaHV1jyneD3WAt3FdITPcP u1kN3mm8qDerXogBAImqh3NDCykvV9e/IvHrS02MgD+IlT45asbOWeVtrXb+yxW7aMfm MO9W5vTPpKf+bdKBzyxYqYuZFcxGC38hVIJdrSnsE7vdP4O0MZKU/va8mCZ2gw0OQga3 B93twFlY313Jx7w5G/itfAf/xRaLEpFw2aIVkIZScfle6pzAklKnEerlrSnie98n8qII aOWXg1YVpcn6E34HQWu0Owr3IEeIEPEYrOqFI9Mk+H2j4SHYp0S3dn1DJklbry9PePJ2 95Jg== X-Gm-Message-State: AOAM532aBmnbBZ0aJt0zcE9vY94zbuPIxiPhbnxjFKr2/m7X83PSh0nt 36Ve3CHcAVlMYsW2bbgHsBJGU1jfZcAXDFs/OGI05WZTzJc= X-Google-Smtp-Source: ABdhPJy/HLQVLa8uN3rRGtjwCB33yB1BPN6EuJOFR5rxo65hgVhLiACjU9HxulyO+cnXwiCu2b668nH8hY1X3vz3JzY= X-Received: by 2002:aa7:c40b:: with SMTP id j11mr2182706edq.253.1628232475629; Thu, 05 Aug 2021 23:47:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rahul Jadhav Date: Fri, 6 Aug 2021 12:17:43 +0530 Message-ID: To: Routing Over Low power and Lossy networks Cc: roll-chairs Content-Type: multipart/alternative; boundary="000000000000525dfd05c8de6a3f" Archived-At: Subject: Re: [Roll] Review of draft-ietf-roll-enrollment-priority-04 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, 06 Aug 2021 06:48:04 -0000 --000000000000525dfd05c8de6a3f Content-Type: text/plain; charset="UTF-8" Excellent review. Many thanks Konrad. Please find my comments inline. Thanks, Rahul On Thu, 5 Aug 2021 at 02:02, Konrad Iwanicki wrote: > Dear authors, > > This is the first review I am doing for IETF's draft, so any suggestions > on how I could improve the quality of my future reviews are welcome. > [RJ] This is an excellent in-depth review. Appreciate. > > I have the following major issues with the draft. Perhaps some of them > have been covered during some meetings (sorry for missing those); my > comments are based just on what I got from the draft (and the related > drafts). > > > 1. I was confused by two seemingly contradictory statements. > > Par. 2 of sect. 2 (starting with "With this specification") states that > the introduced option "MUST be propagated down the DODAG without > modification" (compared to what is issued by the DODAG root). > > However, par. 2 of sect. 2.1 (starting with "6LRs that support this > option") states that "nodes adjust this base value based upon their > observed congestion, emitting their adjusted DIO value to their children." > [RJ] This is a good point. Will raise this as an issue on GH. The way I see it, the value adjustment might have to be done going downstream and I would like to see what others think of it. Nonetheless, the text will need modifications. > > What I understand is that the adjustment applies only in a particular > case. More specifically, if a node receives the option, it copies it to > its DIOs without any modification. In contrast, if the node does not > receive the option but is capable of processing it, then it synthesizes > the option for its DIOs by taking as the min priority the base value > (0x40) adjusted with the node's local observations. This seems > inconsistent, though. In particular, two children with the same parent > can emit DIOs with different values of min priority. Why not simply omit > the option in such a case? > [RJ] Two children with the same parent are permitted to emit DIOs with different values of min priority. Consider the case where child1 has fewer resources than child2 and wants to limit downstream nodes joining through it. This case requires different min-priority to be emitted. There are several other reasons why the priorities could be different. > > > 2. The draft implicitly assumes a DIO processing policy that differs > from RPL's original one. > > More specifically, throughout the draft, it is implied or assumed that a > node processes the option received only from its parent(s). For example: > - par. 8 of sect. 1 (starting with "A network operator might"): "... it > would like to adjust the enrollment priority (the proxy priority field > of [...]) among all nodes in the subtree of a congested link."; - par. 1 of sect. 2.1 (starting with "A 6LR which did not support"): > "Children and grandchildren nodes would therefore not receive any > telemetry via that path and need to assume a default value."; > - par. 2 of sect. 2.1: "6LRs that support this option, but whose parent > does not send it [...]" and the rest of the paragraph as well. > In contrast, RFC 6550, sect. 8.2.3 states that DIOs not only from > parents but also other neighbors must be processed by a node. This > guarantees correct route formation and maintenance. > > Therefore, if the draft changes this policy with respect to the > introduced option, I would expect it to state this change explicitly. [RJ] I don't think the draft changes this policy. RFC 6550 says that the DIO will be received by a node from all its neighbors and that is because of the broadcast nature of the DIOs. When DIOs are received from the neighbors, these neighbors could be promoted to the parent set. The draft does not change this processing behavior. Par 2 of sect 2.1 "6LRs that support this option, but whose parent does not send it...." this statement does not change the 6550 behavior. All it says is for some reason, if the selected parent does not support the option then the draft dictates a particular behavior. > Such a change would also require answering several questions, notably: > - From which parent do we process the option? > - If only from the preferred parent, what happens if a node has none? > - If from any, then what happens if a node gets different values of min > priority or DODAG_Size from different parents? > [RJ] If we agree that we are not changing 6550 DIO processing behavior as mentioned above, then these questions do not apply. > > However, I believe that a meta question worth answering first is: Do we > want to have different min priority values in different subtrees or just > one global value for the entire DODAG? > [RJ] This is the point to be discussed. IMO, the min priority is not a constant global value. However, the draft text contradicts this and will raise the issue in GH before we fix it to garner some discussion. > > Either of the answers in my view requires explicit formulation and > preferably also an explanation in the draft. > > > 3. Even if the draft identified a single parent as the only source of > min priority values for a node, there still would be a problem of value > consistency. > > Since the DODAG root can change its values of min priority and > DODAG_Size and since a node can change its parents, there may still be a > case when the node must decide whether to adopt the newly received > values or not. Without a proper conflict resolution policy, it may be > the case that when the root, for example, disables enrollment, then > enables it again, then the DODAG may exhibit strange behaviors: the > root's decision may not be propagated to all nodes, a decision may be > revoked by nodes that have already accepted it, and the like. > [RJ] The exact conflict resolution policy is not within the scope of this document. However, for the scenario you quoted, "What happens if the enrollment is enabled/disabled by the root?" We do not expect the enrollment enable/disable to be precisely known by all others i.e., there could be nodes who do not have the latest status of the enrollment option. This could cause some additional signaling i.e., a node might try to join even though the (latest) priority did not allow it. This could lead to a few more messaging but it should not result in any untoward behavior. > > There are many ways in which such conflict resolution can be provided. > If I may suggest anything, I would recommend adding to the option a > lollipop sequence counter (like those described in RFC 6550, sect. 7.2), > let's call it osn. It would effectively order different versions of the > option values produced by the DODAG root. In effect, whenever a node > received an option (be it from a parent or another neighbor, depending > on the way the previous issues are addressed), it would adopt the min > priority and DODAG_Size values the option carries if and only if the osn > value in the received option is greater than the node's locally stored > osn. This would guarantee eventual consistency and avoid strange > behaviors such as those mentioned above. > [RJ] With LLNs there is no way to have guaranteed consistency. Consider the case where a node goes off the network and comes back later and did not see part of the traffic at all. Also, note that there is other non-static information such as metrics/constraints that are carried by the DIO. Worst case if the information changes too quickly and the nodes might not have consistent information there could be some additionally messaging but over time the network should converge to the right configuration. I am not sure if introducing something like OSN is the way to tackle this problem. > > > 4. Why put DODAG_Size in the option? > [RJ] This was a recent proposition. Please check this discussion for context, "[Roll] About measure DODAG size and priority " https://mailarchive.ietf.org/arch/msg/roll/-MqqxvTW-3bM5F4k4qH7n5FaxYM/ > I can imagine that other services/protocols would like to use it as > well, and extracting this information from an option related solely to > enrollment does not seem the best idea. I have been thinking for some > time about an option for RPL that would provide some aggregate > information about the DODAG to the nodes, such as its size, max depth, > and the like. The option could also be used in the enrollment process. > Do you think this makes sense? > [RJ] size is already there. For max-depth, what could be the use-case? Is there anything else you have in mind? Would be nice to discuss it now. > > > 5. It should be made clearer in the draft what is actually being > configured. > > The only place where field "proxy priority" of EB appears in the entire > draft is par. 8 of sect. 1. Reading the draft for the first time I was > confused what min priority for the option is used for and what is > actually adjusted at various places. > [RJ] The aim of the draft was to be generic enough but also serve/fulfill the use-case for the 6tisch scenario. Hence the EB point appears only in the introduction. In my previous experience where we used PANA for onboarding nodes in an AMI network, we needed a similar feature and we ended up using a proprietary (but similar) signaling. > > > Apart from these major issues, I have also a few editorial suggestions. > > A. After the par. 1 of sect. 1, I would introduce a subsection heading > titled, for instance, "Terminology Disambiguation" to prepare the > readers for what they are going to see next. > [RJ] I think we should have defined the terms used in the document in the Terminology section as done in all other drafts. Will do that? Do you see any ambiguous terms used? > > B. Similarly, before par. 5 of sect. 1 (starting with "It has become > clear that not every routing member"), I would introduce a subsection > heading titled "Motivation and Overview", just "Overview", or something > along these lines. > [RJ] Let me check if we could improve this. > > C. I would promote the "Terminology" subsection to a section. > [RJ] We'll add the terms used in the document in the Terminology section (Section 1.1). The Terminology section defined today doesn't serve the draft well. Needs update. > > D. I would move par. 1 of sect. 2 (starting with "The size of the DODAG > is measured by the Root") toward the end of sect. 1 as it has little to > do with the option definition. > [RJ] Makes sense to me. > > E. I would fix the bullet list in sect. 2.1 so that it renders correctly > in the text version of the draft. > [RJ] The text rendering seems alright to me in the browser. Should we add a colon ':' after the bullet tag? > > > Finally, I have numerous small editorial suggestions, but they seem > immaterial at this point. > Hope the review helps. > [RJ] Certainly helps. Thank You. > > Best, > -- > - Konrad Iwanicki. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --000000000000525dfd05c8de6a3f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Excellent review. Many thanks Ko= nrad.

Please find my comments inline.

Thanks,
Rahul

On Thu, 5 Aug= 2021 at 02:02, Konrad Iwanicki <iwanicki@mimuw.edu.pl> wrote:
Dear authors,

This is the first review I am doing for IETF's draft, so any suggestion= s
on how I could improve the quality of my future reviews are welcome.

[RJ] This is an excellent in-depth= =C2=A0review. Appreciate.

I have the following major issues with the draft. Perhaps some of them
have been covered during some meetings (sorry for missing those); my
comments are based just on what I got from the draft (and the related
drafts).


1. I was confused by two seemingly contradictory statements.

Par. 2 of sect. 2 (starting with "With this specification") state= s that
the introduced option "MUST be propagated down the DODAG without
modification" (compared to what is issued by the DODAG root).

However, par. 2 of sect. 2.1 (starting with "6LRs that support this option") states that "nodes adjust this base value based upon the= ir
observed congestion, emitting their adjusted DIO value to their children.&q= uot;

[RJ] This is a good poin= t. Will raise this as an issue on GH. The way I see it, the value adjustmen= t might have to be done going downstream and I would like to see what other= s think of it. Nonetheless, the text will need modifications.

What I understand is that the adjustment applies only in a particular
case. More specifically, if a node receives the option, it copies it to its DIOs without any modification. In contrast, if the node does not
receive the option but is capable of processing it, then it synthesizes the option for its DIOs by taking as the min priority the base value
(0x40) adjusted with the node's local observations. This seems
inconsistent, though. In particular, two children with the same parent
can emit DIOs with different values of min priority. Why not simply omit the option in such a case?

[R= J] Two children with the same parent are permitted to=C2=A0emit DIOs with d= ifferent values of min priority. Consider the case where child1 has fewer r= esources than child2 and wants to limit downstream nodes joining through it= . This case requires different min-priority to be emitted. There are severa= l other reasons why the priorities could be different.
=


2. The draft implicitly assumes a DIO processing policy that differs
from RPL's original one.

More specifically, throughout the draft, it is implied or assumed that a node processes the option received only from its parent(s). For example: - par. 8 of sect. 1 (starting with "A network operator might"): &= quot;... it
would like to adjust the enrollment priority (the proxy priority field
of [...]) among all nodes in the subtree of a congested link.";
- par. 1 of sect. 2= .1 (starting with "A 6LR which did not support"):
"Children and grandchildren nodes would therefore not receive any
telemetry via that path and need to assume a default value.";
- par. 2 of sect. 2.1: "6LRs that support this option, but whose paren= t
does not send it [...]" and the rest of the paragraph as well.=C2=A0

In contrast, RFC 6550, sect. 8.2.3 states that DIOs = not only from
parents but also other neighbors must be processed by a node. This
guarantees correct route formation and maintenance.

Therefore, if the draft changes this policy with respect to the
introduced option, I would expect it to state this change explicitly.

[RJ] I don't think the draft chang= es this policy.
RFC 6550 says that the DIO will be rece= ived by a node from all its neighbors and that is because of the broadcast = nature of the DIOs. When DIOs are received from the neighbors, these neighb= ors could be promoted to the parent set. The draft does not change this pro= cessing behavior. Par 2 of sect 2.1 "6LRs that support this option, bu= t whose parent does not send it...." this statement does not change th= e 6550 behavior. All it says is for some reason, if the selected parent doe= s not support the option then the draft dictates a particular behavior.

[RJ] If we agree that we are not changing 6550 DIO proces= sing behavior as mentioned above, then these questions do not apply.
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
However, I believe that a meta question worth answering first is: Do we want to have different min priority values in different subtrees or just one global value for the entire DODAG?

[RJ] This is the point to be discussed. IMO, the min priority is = not a constant global value. However, the draft text contradicts this and w= ill raise the issue in GH before we fix it to garner some discussion.
=

Either of the answers in my view requires explicit formulation and
preferably also an explanation in the draft.


3. Even if the draft identified a single parent as the only source of
min priority values for a node, there still would be a problem of value consistency.

Since the DODAG root can change its values of min priority and
DODAG_Size and since a node can change its parents, there may still be a case when the node must decide whether to adopt the newly received
values or not. Without a proper conflict resolution policy, it may be
the case that when the root, for example, disables enrollment, then
enables it again, then the DODAG may exhibit strange behaviors: the
root's decision may not be propagated to all nodes, a decision may be <= br> revoked by nodes that have already accepted it, and the like.

[RJ] The exact conflict resolution po= licy is not within the scope of this document. However, for the scenario yo= u quoted, "What happens if the enrollment is enabled/disabled by the r= oot?" We do not expect the enrollment enable/disable to be precisely= =C2=A0known by all others i.e., there could be nodes who do not have the la= test status of the enrollment option. This could cause some additional sign= aling i.e., a node might try to join even though the (latest) priority did = not allow it. This could lead to a few more messaging but it should not res= ult in any untoward behavior.

=C2=A0

There are many ways in which such conflict resolution can be provided.
If I may suggest anything, I would recommend adding to the option a
lollipop sequence counter (like those described in RFC 6550, sect. 7.2), let's call it osn. It would effectively order different versions of the=
option values produced by the DODAG root. In effect, whenever a node
received an option (be it from a parent or another neighbor, depending
on the way the previous issues are addressed), it would adopt the min
priority and DODAG_Size values the option carries if and only if the osn value in the received option is greater than the node's locally stored =
osn. This would guarantee eventual consistency and avoid strange
behaviors such as those mentioned above.

[RJ] With LLNs there is no way to have guaranteed consiste= ncy. Consider the case where a node goes off the network and comes back lat= er and did not see part of the traffic at all.
Also, no= te that there is other non-static information such as metrics/constraints t= hat are carried by the DIO. Worst case if the information changes too quick= ly and the nodes might not have consistent information there could be some = additionally messaging but over time the network should converge to the rig= ht configuration. I am not sure if introducing something like OSN is the wa= y to tackle this problem.
=C2=A0


4. Why put DODAG_Size in the option?

[RJ] This was a recent proposition. Please check this discussion fo= r context, "[Roll] About measure DODAG size and priority&= quot;
https://mailarchive.ietf.org/arch/msg/ro= ll/-MqqxvTW-3bM5F4k4qH7n5FaxYM/


I can imagine that other services/protocols would like to use it as
well, and extracting this information from an option related solely to
enrollment does not seem the best idea. I have been thinking for some
time about an option for RPL that would provide some aggregate
information about the DODAG to the nodes, such as its size, max depth,
and the like. The option could also be used in the enrollment process.
Do you think this makes sense?

[RJ] size is already there. For max-depth, what could be the use-cas= e? Is there anything else you have in mind? Would be nice to discuss it now= .

=C2=A0


5. It should be made clearer in the draft what is actually being configured= .

The only place where field "proxy priority" of EB appears in the = entire
draft is par. 8 of sect. 1. Reading the draft for the first time I was
confused what min priority for the option is used for and what is
actually adjusted at various places.

[RJ] The aim of the draft was to be generic enough but also se= rve/fulfill the use-case for the 6tisch scenario. Hence the EB point appear= s only in the introduction.
In my previous experience w= here we used PANA for onboarding nodes in an AMI= =C2=A0network, we needed a similar feature and we ended up using a propriet= ary=C2=A0(but similar) signaling.

=C2=A0


Apart from these major issues, I have also a few editorial suggestions.

A. After the par. 1 of sect. 1, I would introduce a subsection heading
titled, for instance, "Terminology Disambiguation" to prepare the=
readers for what they are going to see next.

[RJ] I think we should have defined the terms used in the d= ocument in the Terminology section as done in all other drafts. Will do tha= t? Do you see any ambiguous terms used?

B. Similarly, before par. 5 of sect. 1 (starting with "It has become <= br> clear that not every routing member"), I would introduce a subsection =
heading titled "Motivation and Overview", just "Overview&quo= t;, or something
along these lines.

[RJ] Let m= e check if we could improve this.

C. I would promote the "Terminology" subsection to a section.
=

[RJ] We'll add the terms use= d in the document in the Terminology section (Section 1.1). The Terminology= section defined today doesn't serve the draft well. Needs update.

D. I would move par. 1 of sect. 2 (starting with "The size of the DODA= G
is measured by the Root") toward the end of sect. 1 as it has little t= o
do with the option definition.

[RJ] Makes sense to me.

E. I would fix the bullet list in sect. 2.1 so that it renders correctly in the text version of the draft.

[RJ] The text rendering seems alright to me in the browser. Should we = add a colon ':' after the bullet tag?


Finally, I have numerous small editorial suggestions, but they seem
immaterial at this point.

Hope the review helps.

[RJ] C= ertainly helps. Thank You.

Best,
--
- Konrad Iwanicki.

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--000000000000525dfd05c8de6a3f-- From nobody Fri Aug 6 04:02:51 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 B56763A28C3; Fri, 6 Aug 2021 04:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.596 X-Spam-Level: X-Spam-Status: No, score=-9.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=CKLjFi9O; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=kKHlqg2g 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 MD46wbrrfgF3; Fri, 6 Aug 2021 04:02:46 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D7BC3A28C0; Fri, 6 Aug 2021 04:02:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1114; q=dns/txt; s=iport; t=1628247765; x=1629457365; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=rgHNahn0qvSQ1ikVGiehpL8NMTPPQsR+LU+P+agT0RQ=; b=CKLjFi9OByjiPuDYI4+a4XfwDvXIU7Kkl2WfOOMB3VUCs3dZ/gEnWSzs FXZgal88Df9uj3j/EMO9RhXAuA99Hrch0CISwW2NOIJfqpWV2GEjviEHT zqiuVweUL8SmKHnVbfnse0KfhE+HHc+xkwzNLr9SCGo/6IYRNtfc2zLu5 M=; IronPort-PHdr: =?us-ascii?q?A9a23=3AhO0izxDQ2rYl3hQ9ForpUyQVdBdPi9zP1kY96?= =?us-ascii?q?5c7hfRJaKvwt5jhPUmK4/JrgReJWIjA8PtLhqLQtLyoQm0P55uN8RVgOJxBX?= =?us-ascii?q?hMIk4MaygonBsPWCEDnIrjtdSNpVMhHXUVuqne8N0UdEc3iZlrU93u16zNaG?= =?us-ascii?q?hj2OQdvYOrvHYuHhMWs3Of08JrWMG11?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AdnKQrqGT3bhyQzYepLqFt5LXdLJyesId70?= =?us-ascii?q?hD6qkvc31om52j+fxGws516fatskduZJkh8erwX5VoMkmshKKdhrNhfotKPT?= =?us-ascii?q?OW+FdASbsD0WKM+UyaJ8VxnNQtr5uIH5IObeEYSGIK8voSgzPIUerIouP3jZ?= =?us-ascii?q?xA7N22pxwGIG0aCNAD0+46MHfmLqQcfnghOXNNLuvl2iMxnUvYRZ14VLXeOl?= =?us-ascii?q?A1G8z44/HbnpPvZhALQzQ97hOVsD+u4LnmVzCFwxY3SVp0sPIf2FmAtza8yr?= =?us-ascii?q?Sosvm9xBOZ/XTU9Y5qlNzozcYGLNCQi/ISNi7nhm+TFcBcsvy5zXcISdOUmQ?= =?us-ascii?q?8Xeer30k8d1gNImijsl1SO0F3QMs/boWwTAjHZuAKlaDDY0LzErXoBerl8bM?= =?us-ascii?q?RiA0fkA45KhqAj7EqNtFjp6Ka/RCmw7hjV9pzGUQpnmVGzpmdnmekPj2ZHWY?= =?us-ascii?q?9bc7NJq5cDlXklXKvoMRiKorzPKtMeQf00JcwmB2+yfjTcpC1i0dasVnM8El?= =?us-ascii?q?OPRVUDoNWc13xTkGpix0UVycQDljNYnahNBaVs9qDBKOBlhbtORsgZYeZ0A/?= =?us-ascii?q?oAW9K+DijITQjXOGyfLFz7HOUMOm7LqZTw/LIpjdvaN6Ag3d83gtDMQVlYvW?= =?us-ascii?q?k9dwbnDtCPxoRC9lTXTGC0TV3Wu4pjDlhCy/XBrZ/QQGy+oXwV4r+dSsQkc4?= =?us-ascii?q?TmsqyISedr6tfYXBzTJbo=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BbBgC9FQ1h/5pdJa1aHgEBCxIMQIF?= =?us-ascii?q?OC4FTKSgHgVE3MYgPA4U5iGYDmjSBLhSBEQNUCwEBAQ0BAUEEAQGBH4M5AoM?= =?us-ascii?q?DAiU0CQ4BAgQBAQESAQEFAQEBAgEGBIERE4VoDYZCAQEBAQMSKAYBATcBCwQ?= =?us-ascii?q?CAQgVAh8QMh0IAgQOBQgahSUDLwGeXgGBOgKKH3iBM4EBggcBAQYEBIU9GII?= =?us-ascii?q?0CYE6gnyKcyccgUlEgRVDgmI+hAo8g0uCLoMWbDs6dlUVEQKrX5IaCoMonmM?= =?us-ascii?q?Sg2WLYJB1hjSFObBvC4R0AgQCBAUCDgEBBoFgO4FZcBWDJFAZDo4fgSUBBwg?= =?us-ascii?q?HgjWKXnM4AgYLAQEDCYpQAQE?= X-IronPort-AV: E=Sophos;i="5.84,300,1620691200"; d="scan'208";a="824720474" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Aug 2021 11:02:44 +0000 Received: from mail.cisco.com (xbe-rcd-003.cisco.com [173.37.102.18]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 176B2iQQ031305 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 6 Aug 2021 11:02:44 GMT Received: from xfe-aln-004.cisco.com (173.37.135.124) by xbe-rcd-003.cisco.com (173.37.102.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Fri, 6 Aug 2021 06:02:44 -0500 Received: from xfe-rcd-003.cisco.com (173.37.227.251) 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.15; Fri, 6 Aug 2021 06:02:44 -0500 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-003.cisco.com (173.37.227.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Fri, 6 Aug 2021 06:02:43 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XP68tb2hUana/aI2y6722ef1vd1AXQCL1JXnKRP/etgeKGFxj1f3dqq2PNSvWyYIlsywm12PeGKmIhcywG6GcCLaDdabbuz8T9Z4pabbDVva792XMyJwqVZ7QU6CdgQ5h33cNfvXImrO6cNdt/+wtuM789x+UFmZkCQy97aSq3HFaRSiTToVjUzywZpu+P7a4mMBH4cuHCrCLfSqzkSwid4ZOfQm6qKSPjw88YUFkU2jTUgHO+Cu7aFvIVGqTjl5k7vuAaGuNYcwotc0aPdw6B/RqV1SMdoyb6jRe1H4v4oleRwPdKeBA4jq/xlKB3Kze1HxSPerWKaRGYI5c+F0ZA== 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=rgHNahn0qvSQ1ikVGiehpL8NMTPPQsR+LU+P+agT0RQ=; b=F7H0Gq6UEkvmxUd0Rd/grDaaC2tmbCaJuBfuBU3vIiKAsgjdeN/w/SOjHWTf9zj+Zef//gWRSmdHiVNcfvlH6JhlUwHHOWR+z6SEN+xqObxUazBY7OKl09rGo7GigzvPlG2rTn7tItDTA1oLZ3HgAXxxkMLuDInc6CqvyruU/M7q99qAngWxuLefUItmZLwiXLFteFEE2jAGlbphJn7vv82l6rTzazeTPaxwla5I6sGvLoHAlHDedxT/ftAm2U68orKABuiMVVshRmsxqBveU2VlyEjHsFBbEIJ6YLsjMuYONiEdx2qIpzQgj7iTZQeoIAa/cq2atrVxH+bTaZEfUQ== 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=rgHNahn0qvSQ1ikVGiehpL8NMTPPQsR+LU+P+agT0RQ=; b=kKHlqg2gTVH25Mri1BqDLccYGnRZz2N+P2nB9CJHFdxUz2+DTQJm8ZsDn7CXnkyJq3eVVKWNbJQk0BjdWWvMWzQF/CIXNWdKC01AZw7FAq1idYzZrY3zlUBUQ7z5Mhe0FZvxT5Is2ICxCmBiN3vs7pJ5ofPCZMeZymDdhpoG2Tk= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by CO1PR11MB4915.namprd11.prod.outlook.com (2603:10b6:303:93::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.18; Fri, 6 Aug 2021 11:02:43 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::487e:47b8:314f:189a]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::487e:47b8:314f:189a%6]) with mapi id 15.20.4394.019; Fri, 6 Aug 2021 11:02:43 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks CC: "roll-chairs@ietf.org" Thread-Topic: [Roll] Review of draft-ietf-roll-enrollment-priority-04 Thread-Index: AQHXiW/D5aIXC0jIjUWmxkQskylezqtmToWg Date: Fri, 6 Aug 2021 11:02:41 +0000 Deferred-Delivery: Fri, 6 Aug 2021 11:01:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5deb268c-96eb-4d67-5cf2-08d958c9b6ef x-ms-traffictypediagnostic: CO1PR11MB4915: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7X4k1M69rRNrEDjo3kwfYvnGaBmUKrYyum+DHETy1a1Ia7TnH86ImtQPFs1xDP8RdcFXt11fBuQH9IDrpptM1b3YEJ2FvJWjGqf1uHam5kkCstQszXnsMeP1sNzY4sPu3YXhbA902YqavzdRX/pUAFGBbQ7Sz4heIGnxZLxCxpkBZ8OAuUNQ5krg5VGwcWXkNA1Cda41PEGBsIT3jds2zEfIncpUwsfky59ovHLi52yEczf7x0+Me/QNH2IEOmGkcFYB0JY77tFD7K1KMg7Bp1N6M++aOtBETiduPw979AijdSrkK9VFCXr9MMx6UXnSSGLZmAScPlIbIKsPYQPHZ2t9SYExXF0Wzq+78e05bS2hIcwYfz/Ru4FEdzpXaVtVcHYK39oH0iDnVnqVvzrbXWLyClp5kNshqPLvBz1Lw116JkbbIn/WEhFDVzcLv0XVEbNWd1gYrXe5DmD+qh1IrKkP+GDI6NnSoNk1hWuaq528CN3g714CSK+W8FUcp/aDk9tUnNdgCwauEuVKkaoL4vM4Qmac3H/KD2GEDUwkRfKBd+r+axRoLRa0707NVyLMGDg2EtsUFKqt4gH83SS6ynKUK7+wL+5aLyI4FS61zrlId9WeN9E0BMY8IIDF8TgpViGd0f2sS6wPUjq8Q4oe83BNo+7fZSOjTThVMpKjz0Z5w0HZ6zxn48QVntUYb7w7OYzS6BfYmczxwRqOLiuGzw== 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:(376002)(136003)(346002)(396003)(366004)(39860400002)(6916009)(122000001)(4326008)(316002)(64756008)(66556008)(450100002)(38100700002)(66476007)(76116006)(66946007)(52536014)(66446008)(71200400001)(86362001)(2906002)(38070700005)(55016002)(7696005)(9686003)(33656002)(5660300002)(8936002)(8676002)(83380400001)(186003)(6506007)(478600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?i3eHZeeGRCrjy4BrzsN1iEwwqiSPASj9N1QXPIegqEEA2DYyGfZ1BSGQqe+j?= =?us-ascii?Q?TQzKv+SI/NQoV84kqpYZ9/o23WyZ4r7taICY1T9YllAjNiFHZ2+y1eeFo6GH?= =?us-ascii?Q?TNkHvNRbSRsvLJ/F12vxf3gqsY4kTML33H7cG931xTFRtMFnIkRfeMQfZrBX?= =?us-ascii?Q?ycT9YDjrQ8W/UY3jI5oLad4pAdaRli3sZyZsuDwIC8SpS8NEB2GZBNNMunor?= =?us-ascii?Q?kA8AXXFLT37jjiNupcTOrFkwMtR59r1KNvMWF+5O0r9s9e+YgEW1FKnyEF2q?= =?us-ascii?Q?FjT0D7760we6hPM7SF8q/cHG1/L9GaDG9doGPFt6VKvWizqnWxVs0Mus7Ndv?= =?us-ascii?Q?L/lMZIwvBZfN4pB6oNNxB5EGq2Gs0TU60W3Trnqe761fpRhciU/WPT+gJcg0?= =?us-ascii?Q?NhN0o4DUUp89VnyLGTkrkWsA8SrsslIziVXhSaRG2cMWQwq5XqUD4rxqNBSd?= =?us-ascii?Q?OTArSDnSdynSR0DH8XbWjoLOQf/oVLGUp4kabgqHJShniW7ETpfeP6xZTDqA?= =?us-ascii?Q?S7j0s2kjXJRLgbsKEN2+N0FoS8anKdFiME7bKLEJl8DVdWyy9sAbCjNnmL7j?= =?us-ascii?Q?CG40vdw42VK7opxWRWVTBDT0sT+gyNY1tVyR/0scpjtWjCyjnqWccF3Ns4dK?= =?us-ascii?Q?XH4/HwADwgWO5K2/nW5DEGiOzM1XSzYviNc+MkFTl3PM7M0dSgR0yrroNKSK?= =?us-ascii?Q?Gxfq9sD407MbUyQy9nqlGcoS4LQekxdkr1PlhQZl1cUEmZXKg50WbbYrk40X?= =?us-ascii?Q?7F2Qk6WdIlFTV6Lllcxiw2zMFatf9x/ZPsLQYqrz7Mbjvlj3C8RoD0d2T110?= =?us-ascii?Q?Vi5OLVLOgUIGCxW5c72hqnXC1V8lYxJ7Ljz84zez81DLuh/+z7uMQMDAvj4b?= =?us-ascii?Q?MK4wZcTZjIYOOqkW9KVvW0re0QHxrLSup2AmOq39EeNTtYWlw/nFsvk9GYIf?= =?us-ascii?Q?cYGHwetPcmGVVIREISZjGq7ZITks0tO+5mTzdrvl//EgpUdJqGgNaZ8Cy3vQ?= =?us-ascii?Q?0p97iPNG8Kdp98IbUF940IzpDw4xqSzL+FuIM4K8KsSUneW1ID38rRy7ai6q?= =?us-ascii?Q?rCRZ7YqDYggsL9OVT0id9jgGmHD7saOv3i3yZf6HZtWPmXoxFo4Nu1Q3WEKR?= =?us-ascii?Q?ROyQ55bnY2nurJulkhQo/vrQJykpX7yg+ZR/JcowslWiypT459AFbe4zjsYQ?= =?us-ascii?Q?qJgV69TgRyH3oU1OIgsrzSLOnOkdUM5V73w6L7C+UcW/RsLUujtW3Sg3+iRc?= =?us-ascii?Q?fsv6lOpL1njtZ0r9iyPeftgSEZezaoU++kF7/UMpCbPjoZ1HhTbAG/2j8DSI?= =?us-ascii?Q?z+GyGMOTkHFLaeeh25hzduFhc7+nFx21CxfGO3Z/SuXL+AozgkKdZkA6aVrF?= =?us-ascii?Q?qEw/Ft6jazSAnx9llg3fpfskz9q4?= 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: 5deb268c-96eb-4d67-5cf2-08d958c9b6ef X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Aug 2021 11:02:42.9033 (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: HEJVpEBbVWv/0zbw6wpZJe4VV5rGvMY13q5uW59n3tUv1v8/2vtvn25QNM6InZ3H92U4TkKqP77aSRGfNiKMVQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB4915 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.18, xbe-rcd-003.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [Roll] Review of draft-ietf-roll-enrollment-priority-04 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, 06 Aug 2021 11:02:51 -0000 Dear Konrad Many fair points below. Many thanks for is a very useful review. Please see below > -----Original Message----- > From: Roll On Behalf Of Konrad Iwanicki > Subject: [Roll] Review of draft-ietf-roll-enrollment-priority-04 >=20 > Dear authors, >=20 > This is the first review I am doing for IETF's draft, so any suggestions > on how I could improve the quality of my future reviews are welcome. >=20 > I have the following major issues with the draft. Perhaps some of them > have been covered during some meetings (sorry for missing those); my > comments are based just on what I got from the draft (and the related > drafts). This is indeed very helpful, Konrad. With this quality of comments, the mor= e the merrier.=20 And as it goes, the ROLL interims are usually at very palatable times for p= eople in central Europe.=20 You're free and would be very welcome to join, no need to register to anyth= ing though we like to see the real names of attendees for the records. For the rest, I'll react from Rahul's reply. Keep safe! Pascal From nobody Fri Aug 6 05:45:24 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 D92BF3A2BAD; Fri, 6 Aug 2021 05:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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_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=T6DfdLjQ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=vCK1FWg2 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 P1wAI1g1bKDV; Fri, 6 Aug 2021 05:45:17 -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 838B83A2BAC; Fri, 6 Aug 2021 05:45:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=80780; q=dns/txt; s=iport; t=1628253917; x=1629463517; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=M6MuZ9mWv1fd7l4ZTI26WIhjjc7G/yfgTfVU5xUHrNU=; b=T6DfdLjQyqhphpUmsdcg2aBXXE8tGD+y0q0Uw+SSa/LUKbhOfCibCGgf JCMTMOT5TRh9ZUnLJnESJDkhdLrpyn03tAbaO4Y5f4s48cMY5oXbF9AHB Nt6SnZrXOFJyKozw/i1guDCpj24Fem3afm1NqB7ECOgIhAheVqK6d8ujK I=; X-IPAS-Result: =?us-ascii?q?A0CfAgBHLg1hl4kNJK1aHgEBCxIMgg4LgSMwIwYoflo3M?= =?us-ascii?q?YRHg0gDhTmIZwOBEI5eikaBLhSBEQNUCwEBAQ0BATcKBAEBhFgCF4JtAiU1C?= =?us-ascii?q?A4BAgQBAQEBAwIDAQEBAQUBAQUBAQECAQYEFAEBAQEBAQEBgQiFOwEsDYZCA?= =?us-ascii?q?QEBBA4ECAkKEwEBIwISAQ8CAQgRBAEBIQEGAwICAjAUCQgCBA4FCBqCTwGBf?= =?us-ascii?q?lcDLwEOoHIBgToCih96gTGBAYIHAQEGBASBSkGDMRiCNAMGgTqCfIQNAQGGZ?= =?us-ascii?q?CccgUlEgRVDVIFXNz6CYgEBAgGBIxIKICsJgmE2gi6CKBFbBgIhNwEJBC8DE?= =?us-ascii?q?Q4CIAEBLhoRChMtCA0EAQYDAhkCDgIcAQUGKw+RExNFgxCISo09kQSBFwqDK?= =?us-ascii?q?Io5hz2MbhKDZYtghkOOAoJlhTmdE5NbBAsNA4RkAgQCBAUCDgEBBoFiAjWBW?= =?us-ascii?q?3AVgnABATJQGQ6LR2iBcAwNCYEDAQMEAgYHgjWFFIVKcwIBATQCBgEKAQEDC?= =?us-ascii?q?YgJAScCgT9eAQE?= IronPort-PHdr: A9a23:aIS/NBexul+fGVP4kUji22nTlGM/qYqcDmcuAtIPir9SfOKk5Zuxd EDc5PA4iljPUM2b7v9fkOPZvujmXnBI+peOtn0OMfkuHx8IgMkbhUosVciCD0CoLfP2YWo9B ssRHFNg9muwZE5SHsu2blbOo3q0uDgVHBi3NQd8KunvXIDIiMHi3OGp8JqVaAJN11KA IronPort-HdrOrdr: A9a23:I8c65KHniEgr65KzpLqFsZLXdLJyesId70hD6qkvc31om52j+f xGws516fatskduZJkh8erwX5VoMkmshKKdgLNhfYtKOTOHhILGFvAY0WNtqQeQYREWmtQtsJ uINpIOd+EYbmIKzvoSgjPIburIqePvmMvD6IuurAYOcegpUdAd0+4TMHf8LqQCfng/OXNPLu vk2iMonUvFRV0nKuCAQlUVVenKoNPG0Lj8ZwQdOhIh4A6SyRu19b/TCXGjr1UjegIK5Y1n3X nOkgT/6Knmmeq80AXg22ja6IkTsMf9y+FEGNeHhqEuW3DRY0eTFcBcso+5zXYISdKUmQ8XeR 730k8d1vFImjTsl6eO0EDQMkfboWwTAjTZuC+laDPY0L/ErXQBepd8bUYzSGqH16Lm1+sMjJ 6jlljpxaZ/HFfOmj/w6MPPUAwvnk2ooWA6mepWlHBHV5ACAYUh4bD30XklWqvoJhiKpbzP0d Meev309bJTaxeXfnrZtm5gzJilWWkyBA6PRgwHttaO2zZbkXhlxw9ArfZv0Eso5dY4Ud1J9u 7EOqNnmPVHSdIXd7t0AKMETdGsAmLATBrQOCaZIEjhFqsAJ3XRwqSHr4kd9aWvYtgF3ZEykJ POXBdRsnMzYVvnDYmU0JhC4nn2MS6AtPTWu4ljDr1Cy/zBrZbQQFm+oWEV4oKdSq8kc7jmst 6ISeVrP8M= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.84,300,1620691200"; d="scan'208,217";a="726047849" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Aug 2021 12:45:15 +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 176Cj4o2014002 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 6 Aug 2021 12:45:15 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.15; Fri, 6 Aug 2021 07:45:15 -0500 Received: from xfe-rtp-004.cisco.com (64.101.210.234) 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.15; Fri, 6 Aug 2021 07:45:14 -0500 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-004.cisco.com (64.101.210.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Fri, 6 Aug 2021 08:45:14 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mwwgMbQpzFV7M2vMXWyddpEY+XnP1Nh+KpwZ2KFKeCejmrpe0xI1uhAP8YP1zPGhIoa92oicoCRU4oXe807BFk1xyaNHEsxkg/03esRYIfL3hwYpMAiVOa4it2ZoXUy6l5fBjuJQbJlS3fiofA8XUGB7RHr5GMr2ZRWUcUgAaM51zWtQW/WH3rNgaTgrcRyH6mxMTl5l1TSdg0D6yfM7YXef5iVp/9mK74WOreNuCxrN3rHZpChAZI76Af/d6vIt+ruNY61D5ym2uptp58A+jPQw18xt0UsKRwHobf9PQ8TA8hc6MH6mxyHsSd/iNbdRgW00HZRULOhxlR/TU+CSIg== 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=M6MuZ9mWv1fd7l4ZTI26WIhjjc7G/yfgTfVU5xUHrNU=; b=GHqX109OHt37QARGi0laaUk/Wks3ymKNQngnUwt/O/A76i8m3q7KC+Yvbns4NOvtnGTJuRLdX5k2YiK+t1nUrDi5WJaeXp0wKlFn0uA8/HC6XIBjjRkQmyLJEbMrHiYXZbGsrgbY5+eQE43A8STxEN3BWFpFuay+yWfhAwseINucnlwVQoHCqvLw7J6vedm63yxsLZkPyRxPL44meexu3WZWgCXjzjMgqwh1NH6o43qCE7sLcUZx/76mFcC8V/7xMsKRaPlZkVECN9qN1E8njCG/ltJJJEK+88it9IRMQyj3GxFO+JKneAlq/JQYExE0e24COac7ypwlaHuNZsjbYg== 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=M6MuZ9mWv1fd7l4ZTI26WIhjjc7G/yfgTfVU5xUHrNU=; b=vCK1FWg2O7blwxN6HgPkiFgsoZt9CxziCjGFVYqJBI91vr2glTZoevMN9V4yQW0CQDOH70gEID2IhPoCnI2BIvR2hYV5zixtqdqBksWhJ9JRsrWGunASGKale8xR195g9dYMa2QnKisHW15DCSJ6/QNvjl9pVa/lZBuIWmZolEk= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MWHPR11MB1360.namprd11.prod.outlook.com (2603:10b6:300:26::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.17; Fri, 6 Aug 2021 12:45:13 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::487e:47b8:314f:189a]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::487e:47b8:314f:189a%6]) with mapi id 15.20.4394.019; Fri, 6 Aug 2021 12:45:13 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks CC: roll-chairs Thread-Topic: [Roll] Review of draft-ietf-roll-enrollment-priority-04 Thread-Index: AQHXiW/D5aIXC0jIjUWmxkQskylezqtmCwqAgABHqDA= Date: Fri, 6 Aug 2021 12:45:05 +0000 Deferred-Delivery: Fri, 6 Aug 2021 12:44:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4283fafa-856f-4307-b257-08d958d808b1 x-ms-traffictypediagnostic: MWHPR11MB1360: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZqyG91NN0sJR56qDXa12UDKvhLx8BSjWX8MIF8QTdqtHfeaQawTzRMap/S8NZAQS/NQY6VPaOHF1qqq408XIiHaXshT6VakmL/HvPNSDMrp7pVyQUlUj1QJPQ5xBlr2Q/LFdgTtLXtCJX3fVvoEHl95wXbKHc8s9eNlYcl9Y7bK881mSy78FSCdGVr/6GAC/Lm71P66SGg+DsnZXYs4NrvwOEDpI1Bqnn+bWLC4ilx84g68EH/tKPp0o+5cfcwt9fppsdLLjWaDUgHvQpKJMZiPRTPaANLQJgLFltG2iTxp3Jcp2FCQyVehiuu4C6zMlEG/QcsY1b9TkSg2dvxP5/kInZv9jhB441f721zDZGnPedG1OlHpkXxcB/jM0XrrqXZUbMnBrcQNSdylwQNndB31wpbkq8oyQ9R3mVqHI6zG6oydQVFB6slNJ/wpa+nJ1vsblQK8updKPL8PZD1V2WGBqproZsRnVnr8o8yWiwTSbyw/pEd4BSz/kR4DaGI8ynFXi0HgzS5W9ON+m+VPOv1GGoidek/6iLKxVG0JZUM3Mt5CZVsyqxzzT/91hntLqDmR38aIyZnov/yueTl1vYtmTKp0EIIS162Juq0Mvjg4ssLHW53WhsDqtzItXMpfTcb0XgpcJVXgc9MY1Q1UJbHQ8FtSmcgVxmW0hASFmhWzLNKIw9Kdn83QG9vPn46SPmnXM0USVtEVVnTTSzZ9YPZM8aXVenwDZjGvniPSShBkAbEkRXgMGLVrCfSnXFVZuPecV5Z9qIQyXKrjz13nW4uh1c1QapSCZN/TyMKZkzbo0mhuyV4dHCjFnGYKiMQYNZTGjQB4kwS+WkraQQgY+8w== 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)(346002)(376002)(136003)(396003)(366004)(5660300002)(64756008)(9686003)(66946007)(66476007)(66556008)(66446008)(55016002)(76116006)(6916009)(52536014)(30864003)(2906002)(6666004)(86362001)(71200400001)(186003)(83380400001)(66574015)(8936002)(4326008)(7696005)(450100002)(166002)(8676002)(6506007)(53546011)(122000001)(38100700002)(316002)(966005)(38070700005)(33656002)(478600001)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?Q2IxWG5WNEdVUVFvMEZYZFgwUXEwT1cvZGhPek9WdW9tbnUxNzRBdzRJNmdi?= =?utf-8?B?dHoxaGhERFJRc1FYejdnbFlVOE9kdTZ1Y2cvNjMrVzN4bjUraStpbkxCM3lO?= =?utf-8?B?b3RhWC9OOEtrUEx2WnRFYUZVTVdyUzlCRUlJd1pqd3ptbzVrSlJsVE9WVHZw?= =?utf-8?B?azRMRzVBb1J6VTkzN05VdWFIUHkrZnJKR2dja05XdUdKb1l6KzNKM1ZEUEh1?= =?utf-8?B?T3ByeU1ZSmIyUVZZLzdoZXh6cjdSUy9NR2crMGh4N3c2aFUwZzdMYU9hTEYy?= =?utf-8?B?czhNNGozdXkzangxbnF6cFJqT3lDQmtvU1hteER5NGhkbjRPWHhRaGQrUVMz?= =?utf-8?B?MTNZelMzZGU2YkVoSFU2V2dzeHMveXo2U2gwUUc4OGVPR1BJNFFSZjZMMVhT?= =?utf-8?B?blQ0bVd4ek9heVFMcEJCTFlVNTZmUG1WYzdFTGFla2ZJT3pHOU1ubERuYTdP?= =?utf-8?B?Myt6RGo5ZExHczhtWjNWL3NhNjRwWHN2VHdja1VINjRXR2U5OWV3cXNlaEEw?= =?utf-8?B?T1FHd0RDRlRpd3pCVHFBanMzUzlWZ2JlK3JlaDJpRkVObXBuMnphdGhoNk1H?= =?utf-8?B?cHhjR0c0TnJab3daSWlYZDFmd2ljeW8xelVFRlNIU0FmVW1tRG1oVklKZmE2?= =?utf-8?B?Y1M3cEFmK29hOXo1TXZ5OEhyOVV3TTZCdmJqMnBiTUlNSkQyQUlXQmFEUWdC?= =?utf-8?B?K05qcWFQR2NnU1V4ckEzeWhJNitHOEs2Z2JSN1pTbmhBbU52MVdCZXFCM1ZT?= =?utf-8?B?cWhUd29uZzdRRUVPdUl0YkRhTXVLald4S3p3YVB3SzkrM2tmTUNaMGhxK2tj?= =?utf-8?B?QTFyUG1CTXZHbHRKcnhXTFJoQm9zYUtWY2d2bmIvTEJGOG1TQy9GTEF4eU9W?= =?utf-8?B?dDN0YnpNdGM4L3VFSkZyZ1hJYU1mVVplOG41MFZhOW9udkxBZzZBYVdER3F6?= =?utf-8?B?NlpDZGpTcjREZit1a01HeEFaQjlJdlluVWRkdnNyR3M5WTVJYTJuYzJEdGdY?= =?utf-8?B?cTdEVURGc1lVREtkQVFiZkpEZTVmOXFtek9NRE5yTzY4Q0x4cFBZQk9hNDVN?= =?utf-8?B?V0swbnR6U0Nsb2FIQ2hDMkxRVHBTdWpGVTc1UVZnbUhUdU9xbXNBWExPOXg0?= =?utf-8?B?VisrcThEZWhraXJZeHVzemdZa2hPQ1dnMGNLNmE4dVJBRlp3NVpsTURwNTh3?= =?utf-8?B?aTYyMG1aNW5RRVV3amxnOWtLalhZaFRjaUlnS0ZxTys2WmU0dEhTcWlobGpE?= =?utf-8?B?b2lVcUNydFp1dStBRkpMcm9ZdHk5TjRWZjk3aGl0S0pFamNhZElJb3JZY3gv?= =?utf-8?B?Lzd5TkZhOFg0SXc0ZFAwYWsyYkZucUVuZFVzaFNFNVNCeGNkNmliUjM3Wk02?= =?utf-8?B?RHVSQVFRZ0hXUXJZLzcwQjBrL0RxamhBZkxLcUhHNm5Wckx0ZmVCSkR2QkZY?= =?utf-8?B?TXFnd0QvdmRabVV0UTYvWm9Qa3dKRDdoK0N4UU5CdGljRFMxaUVzU1g0QTBH?= =?utf-8?B?QlZUVFo0cTBoNkRFbEhPSElpSUphK0loanZYNWRQb0Urb3Vkc2hudTBUOHFX?= =?utf-8?B?a2cvbzRFTmx4MEN2QjFQMndtcyt2UWVDb0R6V1hrOXNXYXZqNWkzNGdZc0M2?= =?utf-8?B?elN4emhhSHVkL3Y1N2xlK2U0M0QrR3pkZzdLcy9RUnhoSVFhVGRaRnRQWHFL?= =?utf-8?B?TEQ4R1NVTWYyMGY2L282S25GOGNWcktMeEpDUWdaZTFGck1QaEV5SUJUalcz?= =?utf-8?B?aWw2b094SGsxQzRnMTNRelYrREk2VkhWSXBBem9rYys1a0J1R29qeW1MamFa?= =?utf-8?B?R0JBcGY5bDBPT2ZHYTFTd0k1NXV1OWpFVyswSjEwR05FeWV4NUlpN1gvTmRE?= =?utf-8?Q?3QEMJAEAl85I2?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CO1PR11MB48812CDAA6A2E3DC818FC0C8D8F39CO1PR11MB4881namp_" 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: 4283fafa-856f-4307-b257-08d958d808b1 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Aug 2021 12:45:13.0096 (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: bL+o6HTHM4mIQPNsHW9eZ1UQOjr7BZHZ54wDX92FyGA1kctfCqIJRm23MPZilRSgcet4CdlrM4Us9NuzPY0WVQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1360 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] Review of draft-ietf-roll-enrollment-priority-04 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, 06 Aug 2021 12:45:23 -0000 --_000_CO1PR11MB48812CDAA6A2E3DC818FC0C8D8F39CO1PR11MB4881namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAgICAgICAgICAgICBUaGUgbm9kZXMgdGhlbg0KICAgYWRqdXN0IHRoaXMgYmFzZSB2YWx1ZSBi YXNlZCB1cG9uIHRoZWlyIG9ic2VydmVkIGNvbmdlc3Rpb24sIGVtaXR0aW5nDQogICB0aGVpciBh ZGp1c3RlZCBESU8gdmFsdWUgdG8gdGhlaXIgY2hpbGRyZW4uDQoNCg0KRnJvbTogUm9sbCA8cm9s bC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgUmFodWwgSmFkaGF2DQpTZW50OiB2ZW5k cmVkaSA2IGFvw7t0IDIwMjEgODo0OA0KVG86IFJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5kIExv c3N5IG5ldHdvcmtzIDxyb2xsQGlldGYub3JnPg0KQ2M6IHJvbGwtY2hhaXJzIDxyb2xsLWNoYWly c0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbUm9sbF0gUmV2aWV3IG9mIGRyYWZ0LWlldGYtcm9s bC1lbnJvbGxtZW50LXByaW9yaXR5LTA0DQoNCkV4Y2VsbGVudCByZXZpZXcuIE1hbnkgdGhhbmtz IEtvbnJhZC4NCg0KW1Bhc2NhbF06IHZlcnkgbXVjaCwgeWVzIQ0KDQpQbGVhc2UgZmluZCBteSBj b21tZW50cyBpbmxpbmUuDQoNClRoYW5rcywNClJhaHVsDQoNCk9uIFRodSwgNSBBdWcgMjAyMSBh dCAwMjowMiwgS29ucmFkIEl3YW5pY2tpIDxpd2FuaWNraUBtaW11dy5lZHUucGw8bWFpbHRvOml3 YW5pY2tpQG1pbXV3LmVkdS5wbD4+IHdyb3RlOg0KRGVhciBhdXRob3JzLA0KDQpUaGlzIGlzIHRo ZSBmaXJzdCByZXZpZXcgSSBhbSBkb2luZyBmb3IgSUVURidzIGRyYWZ0LCBzbyBhbnkgc3VnZ2Vz dGlvbnMNCm9uIGhvdyBJIGNvdWxkIGltcHJvdmUgdGhlIHF1YWxpdHkgb2YgbXkgZnV0dXJlIHJl dmlld3MgYXJlIHdlbGNvbWUuDQoNCltSSl0gVGhpcyBpcyBhbiBleGNlbGxlbnQgaW4tZGVwdGgg cmV2aWV3LiBBcHByZWNpYXRlLg0KDQpJIGhhdmUgdGhlIGZvbGxvd2luZyBtYWpvciBpc3N1ZXMg d2l0aCB0aGUgZHJhZnQuIFBlcmhhcHMgc29tZSBvZiB0aGVtDQpoYXZlIGJlZW4gY292ZXJlZCBk dXJpbmcgc29tZSBtZWV0aW5ncyAoc29ycnkgZm9yIG1pc3NpbmcgdGhvc2UpOyBteQ0KY29tbWVu dHMgYXJlIGJhc2VkIGp1c3Qgb24gd2hhdCBJIGdvdCBmcm9tIHRoZSBkcmFmdCAoYW5kIHRoZSBy ZWxhdGVkDQpkcmFmdHMpLg0KDQoNCjEuIEkgd2FzIGNvbmZ1c2VkIGJ5IHR3byBzZWVtaW5nbHkg Y29udHJhZGljdG9yeSBzdGF0ZW1lbnRzLg0KDQpQYXIuIDIgb2Ygc2VjdC4gMiAoc3RhcnRpbmcg d2l0aCAiV2l0aCB0aGlzIHNwZWNpZmljYXRpb24iKSBzdGF0ZXMgdGhhdA0KdGhlIGludHJvZHVj ZWQgb3B0aW9uICJNVVNUIGJlIHByb3BhZ2F0ZWQgZG93biB0aGUgRE9EQUcgd2l0aG91dA0KbW9k aWZpY2F0aW9uIiAoY29tcGFyZWQgdG8gd2hhdCBpcyBpc3N1ZWQgYnkgdGhlIERPREFHIHJvb3Qp Lg0KDQpIb3dldmVyLCBwYXIuIDIgb2Ygc2VjdC4gMi4xIChzdGFydGluZyB3aXRoICI2TFJzIHRo YXQgc3VwcG9ydCB0aGlzDQpvcHRpb24iKSBzdGF0ZXMgdGhhdCAibm9kZXMgYWRqdXN0IHRoaXMg YmFzZSB2YWx1ZSBiYXNlZCB1cG9uIHRoZWlyDQpvYnNlcnZlZCBjb25nZXN0aW9uLCBlbWl0dGlu ZyB0aGVpciBhZGp1c3RlZCBESU8gdmFsdWUgdG8gdGhlaXIgY2hpbGRyZW4uIg0KDQpbUkpdIFRo aXMgaXMgYSBnb29kIHBvaW50LiBXaWxsIHJhaXNlIHRoaXMgYXMgYW4gaXNzdWUgb24gR0guIFRo ZSB3YXkgSSBzZWUgaXQsIHRoZSB2YWx1ZSBhZGp1c3RtZW50IG1pZ2h0IGhhdmUgdG8gYmUgZG9u ZSBnb2luZyBkb3duc3RyZWFtIGFuZCBJIHdvdWxkIGxpa2UgdG8gc2VlIHdoYXQgb3RoZXJzIHRo aW5rIG9mIGl0LiBOb25ldGhlbGVzcywgdGhlIHRleHQgd2lsbCBuZWVkIG1vZGlmaWNhdGlvbnMu DQoNCltQYXNjYWxdIFRoZSBmaWVsZCBpcyB0aGUgTUlOIHByaW9yaXR5IGFuZCBpdCBpcyBkZWNp ZGVkIGJ5IHRoZSByb290LiBUbyBteSBiZXN0IGtub3dsZWRnZS9tZW1vcnksIHRoZSBpbnRlbnQg d2FzIHRvIGFkanVzdCB0aGUgcHJpb3JpdHkgdmFsdWUgdGhhdCBpcyByZXBvcnRlZCBvdXRzaWRl IG9mIHRoZSBESU8gKGluIGJlYWNvbnMpIHRoYXQgY2Fubm90IGJlIGxvd2VyIHRoYW4gdGhlIG1p bmltdW0gcHJpb3JpdHkgaW4gdGhlIERJTywgZS5nLiwgd2hlbiB0aGUgNkxSIGV4cG9zZXMgaXRz IGRlc2lyZSB0byBiZSBhIGpvaW4gcHJveHksIGFzIGRpc2N1c3NlZCBpbiB0aGlzIHRleHQ6DQri gJwNCg0KICAgQSA2TFIgd2hpY2ggd291bGQgb3RoZXJ3aXNlIGJlIHdpbGxpbmcgdG8gYWN0IGFz IGEgX0pvaW4gUHJveHlfLCB3aWxsDQogICBleGFtaW5lIHRoZSBtaW5pbXVtIHByaW9yaXR5IGZp ZWxkLCBhbmQgdG8gdGhhdCBudW1iZXIsIGFkZCBhbnkNCiAgIGFkZGl0aW9uYWwgbG9jYWwgY29u c2lkZXJhdGlvbiAoc3VjaCBhcyB1cHN0cmVhbSBjb25nZXN0aW9uKS4NCg0K4oCcDQpCdXQgdGhl IE1pbiBwcmlvcml0eSBpbiB0aGUgRElPIGlzIHVuY2hhbmdlZC4gTm90ZSB0aGF0IGlmIGl0IHdh cywgYSBjaGlsZCB3aXRoIG11bHRpcGxlIHBhcmVudHMgd291bGQgZ2V0IGNvbmZsaWN0aW5nIERJ T3Mgd2l0aCBib3RoIHRpbWVseSBpbmZvcm1hdGlvbiBhbmQgd2Ugd291bGQgaGF2ZSB0byBzcGVj aWZ5IHdoaWNoIHZhbHVlIGl0IHJlcG9ydHMuIFJpZ2h0IG5vdyB0aGUgaWRlYSB3b3VsZCBiZSB0 byByZXBvcnQgdGhlIG1vc3QgcmVjZW50LCB0aG91Z2ggaXQgaXMgc29tZXdoYXQgdW5jbGVhciBo b3cgdGhhdCBpcyBkZXRlcm1pbmVkLg0KDQpTdGlsbCBJIGFncmVlIHRoYXQgd2UgbmVlZCB0byBp bXByb3ZlIHRoZSB0ZXh0LCBhcyBLb25yYWQgc2F5cyBpdCBpcyBxdWl0ZSBjb25mdXNpbmcuDQoN CklmIHdlIHdhbnQgc29tZXRoaW5nIHRoYXQgcmVwb3J0cyB0aGUgbG9hZCBvZiB0aGUgRE9EQUcg YWJvdmUsIHdl4oCZbGwgaGF2ZSB0byBleGFtaW5lIHRoZSB2YWx1ZSBhbmQgaWYgaXQgaXMgbmVl ZGVkLCB0aGVuIGRlZmluZSB0aGUgYmVoYXZpb3IuDQoNCg0KDQoNCg0KV2hhdCBJIHVuZGVyc3Rh bmQgaXMgdGhhdCB0aGUgYWRqdXN0bWVudCBhcHBsaWVzIG9ubHkgaW4gYSBwYXJ0aWN1bGFyDQpj YXNlLiBNb3JlIHNwZWNpZmljYWxseSwgaWYgYSBub2RlIHJlY2VpdmVzIHRoZSBvcHRpb24sIGl0 IGNvcGllcyBpdCB0bw0KaXRzIERJT3Mgd2l0aG91dCBhbnkgbW9kaWZpY2F0aW9uLiBJbiBjb250 cmFzdCwgaWYgdGhlIG5vZGUgZG9lcyBub3QNCnJlY2VpdmUgdGhlIG9wdGlvbiBidXQgaXMgY2Fw YWJsZSBvZiBwcm9jZXNzaW5nIGl0LCB0aGVuIGl0IHN5bnRoZXNpemVzDQp0aGUgb3B0aW9uIGZv ciBpdHMgRElPcyBieSB0YWtpbmcgYXMgdGhlIG1pbiBwcmlvcml0eSB0aGUgYmFzZSB2YWx1ZQ0K KDB4NDApIGFkanVzdGVkIHdpdGggdGhlIG5vZGUncyBsb2NhbCBvYnNlcnZhdGlvbnMuIFRoaXMg c2VlbXMNCmluY29uc2lzdGVudCwgdGhvdWdoLiBJbiBwYXJ0aWN1bGFyLCB0d28gY2hpbGRyZW4g d2l0aCB0aGUgc2FtZSBwYXJlbnQNCmNhbiBlbWl0IERJT3Mgd2l0aCBkaWZmZXJlbnQgdmFsdWVz IG9mIG1pbiBwcmlvcml0eS4gV2h5IG5vdCBzaW1wbHkgb21pdA0KdGhlIG9wdGlvbiBpbiBzdWNo IGEgY2FzZT8NCg0KW1JKXSBUd28gY2hpbGRyZW4gd2l0aCB0aGUgc2FtZSBwYXJlbnQgYXJlIHBl cm1pdHRlZCB0byBlbWl0IERJT3Mgd2l0aCBkaWZmZXJlbnQgdmFsdWVzIG9mIG1pbiBwcmlvcml0 eS4gQ29uc2lkZXIgdGhlIGNhc2Ugd2hlcmUgY2hpbGQxIGhhcyBmZXdlciByZXNvdXJjZXMgdGhh biBjaGlsZDIgYW5kIHdhbnRzIHRvIGxpbWl0IGRvd25zdHJlYW0gbm9kZXMgam9pbmluZyB0aHJv dWdoIGl0LiBUaGlzIGNhc2UgcmVxdWlyZXMgZGlmZmVyZW50IG1pbi1wcmlvcml0eSB0byBiZSBl bWl0dGVkLiBUaGVyZSBhcmUgc2V2ZXJhbCBvdGhlciByZWFzb25zIHdoeSB0aGUgcHJpb3JpdGll cyBjb3VsZCBiZSBkaWZmZXJlbnQuDQoNCg0KW1Bhc2NhbF0NCg0KVG8gS29ucmFk4oCZcyBwb2lu dCA6IEkgIGFncmVlIHdpdGggeW91IHRoYXQgdGhpcyBjcmVhdGVzIGEgc2l0dWF0aW9uIHRoYXQg aXMgbm9ybWFsbHkgc2VlbiBvbmx5IHdoZW4gdGhlIHJvb3QgY2hhbmdlcyB0aGUgdmFsdWUgKHdo aWNoIGFyZ3VhYmx5IG1heSBoYXBwZW4gYSBsb3QgYW5kIHNob3VsZCBiZSBkYW1wZW5lZCB3aXRo IGh5c3RlcmVzaXMgYW5kIHN0dWZmKS4gSSBiZWxpZXZlIHdlIHNob3VsZCByZXRyYWN0IHRoZSB0 ZXh0IHRoYXQgYWxsb3dzIHRoZSA2TFIgdG8gZ2VuZXJhdGUgdGhlIG9wdGlvbiwgcmVhc29uIGlz LCBpZiB0aGUgcm9vdCBzZXRzIGl0IGFuZCBvbmx5IHRoZSA2TFLigJlzIHBhcmVudCBkbyBub3Qg c3VwcG9ydCwgYSBjaGlsZCBvZiB0aGUgNkxSIG1heSBzZWUgYml0aCB0aGUgUm9vdOKAmXMgdmFs dWUgYW5kIHRoZSA2TFLigJlzIHZhbHVlLiBEYW5nZXJvdXMuIFNvIHRoZSBzdWdnZXN0aW9uIGlz IHRvIHJldHJhY3QNCuKAnA0KDQpUaGUgbm9kZXMgdGhlbg0KICAgYWRqdXN0IHRoaXMgYmFzZSB2 YWx1ZSBiYXNlZCB1cG9uIHRoZWlyIG9ic2VydmVkIGNvbmdlc3Rpb24sIGVtaXR0aW5nDQogICB0 aGVpciBhZGp1c3RlZCBESU8gdmFsdWUgdG8gdGhlaXIgY2hpbGRyZW4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIOKAnA0KDQrigJwNCg0KVG8gUmFodWzigJlzOiBUaGlzIGNvdWxkIGJl IGFuIGltcG9ydGFudCB0aGluZyB0byByZXBvcnQsIGFuZCB3ZSBjYW4gdGFrZSBpdCBvdXRzaWRl IHRoaXMgdGhyZWFkLiBBcyBvZiB0b2RheSB3ZSBkbyBub3QgcmVwb3J0IHRoZSBwYXJlbnQgbG9h ZC9jYXBhYmlsaXR5IHRvIHRha2UgbW9yZSBjaGlsZHJlbiBpbiBESU9zLiBUaGUgcmVhc29uIHdl IGRpZCBub3QgZG8gdGhhdCBpbiB0aGUgcGFzdCB3YXMgdG8gbGltaXQgdGhlIGNvbXBsZXhpdHkg b2YgdGhlIFJQTCBzcGVjLiBCZWNhdXNlIHlvdeKAmWQgYWxzbyBuZWVkIHRvIGV4cGxhaW4gd2hh dCBub2RlcyBkbyB3aXRoIHRoZSBpbmZvcm1hdGlvbiwgZS5nLiwgaG93IHRvIGJhbGFuY2UgdGhl IGdyYXBoIHNvIHRoYXQgZXZlcnlvbmUgaGFzIGF0IGxlYXN0IG9uZSBwYXJlbnQsIHdoaWNoIHdv dWxkIGludm9sdmUgc29tZSBzaG91bGRlciB0byBzaG91bGRlciBwdXNoYmFjay4gU28gd2Ugc2Fp ZCBhdCB0aGUgdGltZSwgZWl0aGVyIGFsbCBub2RlcyBoYXZlIGVub3VnaCBtZW1vcnkgb3IgeW91 IGdvIGZvciBub24tc3RvcmluZywgYnV0IHlvdSBuZXZlciBoYXZlIHRvIHJlYWN0IHRvIHRoZSBw YXJlbnTigJlzIGxvYWQuDQoNClRoaXMgaXMgc29tZXRoaW5nIHdlIGNhbiByZW9wZW4gbm93LCBi dXQgcHJvYmFibHkgdW5kZXIgdGhlIFJQTHYyIHVtYnJlbGxhLg0KDQoNCg0KDQoNCg0KMi4gVGhl IGRyYWZ0IGltcGxpY2l0bHkgYXNzdW1lcyBhIERJTyBwcm9jZXNzaW5nIHBvbGljeSB0aGF0IGRp ZmZlcnMNCmZyb20gUlBMJ3Mgb3JpZ2luYWwgb25lLg0KDQpNb3JlIHNwZWNpZmljYWxseSwgdGhy b3VnaG91dCB0aGUgZHJhZnQsIGl0IGlzIGltcGxpZWQgb3IgYXNzdW1lZCB0aGF0IGENCm5vZGUg cHJvY2Vzc2VzIHRoZSBvcHRpb24gcmVjZWl2ZWQgb25seSBmcm9tIGl0cyBwYXJlbnQocykuIEZv ciBleGFtcGxlOg0KLSBwYXIuIDggb2Ygc2VjdC4gMSAoc3RhcnRpbmcgd2l0aCAiQSBuZXR3b3Jr IG9wZXJhdG9yIG1pZ2h0Iik6ICIuLi4gaXQNCndvdWxkIGxpa2UgdG8gYWRqdXN0IHRoZSBlbnJv bGxtZW50IHByaW9yaXR5ICh0aGUgcHJveHkgcHJpb3JpdHkgZmllbGQNCm9mIFsuLi5dKSBhbW9u ZyBhbGwgbm9kZXMgaW4gdGhlIHN1YnRyZWUgb2YgYSBjb25nZXN0ZWQgbGluay4iOw0KLSBwYXIu IDEgb2Ygc2VjdC4gMi4xIChzdGFydGluZyB3aXRoICJBIDZMUiB3aGljaCBkaWQgbm90IHN1cHBv cnQiKToNCiJDaGlsZHJlbiBhbmQgZ3JhbmRjaGlsZHJlbiBub2RlcyB3b3VsZCB0aGVyZWZvcmUg bm90IHJlY2VpdmUgYW55DQp0ZWxlbWV0cnkgdmlhIHRoYXQgcGF0aCBhbmQgbmVlZCB0byBhc3N1 bWUgYSBkZWZhdWx0IHZhbHVlLiI7DQotIHBhci4gMiBvZiBzZWN0LiAyLjE6ICI2TFJzIHRoYXQg c3VwcG9ydCB0aGlzIG9wdGlvbiwgYnV0IHdob3NlIHBhcmVudA0KZG9lcyBub3Qgc2VuZCBpdCBb Li4uXSIgYW5kIHRoZSByZXN0IG9mIHRoZSBwYXJhZ3JhcGggYXMgd2VsbC4NCg0KSW4gY29udHJh c3QsIFJGQyA2NTUwLCBzZWN0LiA4LjIuMyBzdGF0ZXMgdGhhdCBESU9zIG5vdCBvbmx5IGZyb20N CnBhcmVudHMgYnV0IGFsc28gb3RoZXIgbmVpZ2hib3JzIG11c3QgYmUgcHJvY2Vzc2VkIGJ5IGEg bm9kZS4gVGhpcw0KZ3VhcmFudGVlcyBjb3JyZWN0IHJvdXRlIGZvcm1hdGlvbiBhbmQgbWFpbnRl bmFuY2UuDQoNClRoZXJlZm9yZSwgaWYgdGhlIGRyYWZ0IGNoYW5nZXMgdGhpcyBwb2xpY3kgd2l0 aCByZXNwZWN0IHRvIHRoZQ0KaW50cm9kdWNlZCBvcHRpb24sIEkgd291bGQgZXhwZWN0IGl0IHRv IHN0YXRlIHRoaXMgY2hhbmdlIGV4cGxpY2l0bHkuDQoNCltSSl0gSSBkb24ndCB0aGluayB0aGUg ZHJhZnQgY2hhbmdlcyB0aGlzIHBvbGljeS4NClJGQyA2NTUwIHNheXMgdGhhdCB0aGUgRElPIHdp bGwgYmUgcmVjZWl2ZWQgYnkgYSBub2RlIGZyb20gYWxsIGl0cyBuZWlnaGJvcnMgYW5kIHRoYXQg aXMgYmVjYXVzZSBvZiB0aGUgYnJvYWRjYXN0IG5hdHVyZSBvZiB0aGUgRElPcy4gV2hlbiBESU9z IGFyZSByZWNlaXZlZCBmcm9tIHRoZSBuZWlnaGJvcnMsIHRoZXNlIG5laWdoYm9ycyBjb3VsZCBi ZSBwcm9tb3RlZCB0byB0aGUgcGFyZW50IHNldC4gVGhlIGRyYWZ0IGRvZXMgbm90IGNoYW5nZSB0 aGlzIHByb2Nlc3NpbmcgYmVoYXZpb3IuIFBhciAyIG9mIHNlY3QgMi4xICI2TFJzIHRoYXQgc3Vw cG9ydCB0aGlzIG9wdGlvbiwgYnV0IHdob3NlIHBhcmVudCBkb2VzIG5vdCBzZW5kIGl0Li4uLiIg dGhpcyBzdGF0ZW1lbnQgZG9lcyBub3QgY2hhbmdlIHRoZSA2NTUwIGJlaGF2aW9yLiBBbGwgaXQg c2F5cyBpcyBmb3Igc29tZSByZWFzb24sIGlmIHRoZSBzZWxlY3RlZCBwYXJlbnQgZG9lcyBub3Qg c3VwcG9ydCB0aGUgb3B0aW9uIHRoZW4gdGhlIGRyYWZ0IGRpY3RhdGVzIGEgcGFydGljdWxhciBi ZWhhdmlvci4NCg0KW1Bhc2NhbF0gSSBiZWxpZXZlIHRoYXQgS29ucmFk4oCZcyBwb2ludCBpcyB0 aGF0DQrigJwNCg0KDQpSUEwgbGltaXRzIHRoZSBjYXNlcyB3aGVyZSBhIG5vZGUgbWF5IHByb2Nl c3MgRElPIG1lc3NhZ2VzIGZyb20NCg0KICAgZGVlcGVyIG5vZGVzIHRvIHNvbWUgZm9ybSBvZiBs b2NhbCByZXBhaXIuDQoNCuKAnCAgZnJvbSBSRkMgNjU1MCwgYXMgZXhwbGFpbmVkIGluIG1vcmUg ZGV0YWlscyBpbiAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9yZmM2NTUw I3NlY3Rpb24tOC4yLjIuNA0KDQpXaGljaCBpcyBJT1cgdGhhdCBhIG5vZGUgbm9ybWFsbHkgaWdu b3JlcyBESU9zIGNvbWluZyBmcm9tIGRlZXBlci4gQnV0IGl0IG5lZWRzIHRvIHByb2Nlc3MgRElP cyBmb3IgYWxsIG5vZGVzIHRoYXQgbWF5IGJlY29tZSBwb3RlbnRpYWwgcGFyZW50Lg0KT24gdGhl IG9uZSBoYW5kIEnigJlkIHNheSB0aGF0IGlmIHRoZSBvcHRpb24gaXMgZXhwZWN0ZWQgdG8gcmVw b3J0IHBhcmVudCBsb2FkIGluIHRoZSBmdXR1cmUsIHRoZSBub2RlIHNob3VsZCBwYXJzZSB0aGUg b3B0aW9uIGluIGFueSBESU8gdGhhdCBpcyBhY2NlcHRhYmxlIG90aGVyd2lzZSwgYW5kIHRvIEtv bnJhZOKAmXMgcG9pbnQgZm9sbG93IHRoZSBleGFjdCBzYW1lIHJ1bGVzIGFzIFJQTC4NCk9UT0gs IHRoaXMgaXMgbW9yZSBjaGFuY2VzIGZvciBnZXR0aW5nIGRpZmZlcmVudCB2YWx1ZXMgYWxvbmcg ZGlmZmVyZW50IGFzeW5jaHJvbm91cyBwYXRocy4gV2hpY2ggbWFrZXMgdGhlIHByb2JsZW0gb2Yg ZmluZGluZyB0aGUgbW9zdCByZWNlbnQgdmFsdWUgZXZlbiBoYXJkZXIuDQoNClNlZW1zIHRoYXQg dGhlIG9wdGlvbiBzaG91bGQgaGF2ZSBpdHMgb3duIHNlcXVlbmNlLCB3aGljaCBpcyBhIGdlbmVy aWMgcHJvYmxlbSB0aGF0IHdhcyBkaXNjdXNzZWQgaW4gZHJhZnQtdGh1YmVydC1yb2xsLWVsaWRp bmctZGlvLWluZm9ybWF0aW9uLiBOb3RlIHRoYXQgaW4gdGhpcyBjYXNlLCBJIGRvIG5vdCBiZWxp ZXZlIHRoYXQgd2Ugc2hvdWxkIGNoYW5nZSB0aGUgUkNTUyBpbiB0aGF0IGRyYWZ0LCBzbyB0aGUg YmVzdCBjb3VsZCBiZSB0aGF0IHRoZSBvcHRpb24gaGFzIGl0cyBvd24gc2VxdWVuY2UuIFRoZSB0 ZXh0IHdvdWxkIGNoYW5nZSB0byByZWZsZWN0IHRoYXQgd2UgdXNlIGFueSBESU8gdGhhdCB3ZSBu b3JtYWxseSB1c2UsIGFuZCByZXRhaW4gdGhlIHZhbHVlIG9mIHRoZSBtaW4gcHJpb3JpdHkgZnJv bSB0aGUgbW9zdCByZWNlbnQgb2YgYWxsLg0KDQoNCg0KDQpTdWNoIGEgY2hhbmdlIHdvdWxkIGFs c28gcmVxdWlyZSBhbnN3ZXJpbmcgc2V2ZXJhbCBxdWVzdGlvbnMsIG5vdGFibHk6DQotIEZyb20g d2hpY2ggcGFyZW50IGRvIHdlIHByb2Nlc3MgdGhlIG9wdGlvbj8NCi0gSWYgb25seSBmcm9tIHRo ZSBwcmVmZXJyZWQgcGFyZW50LCB3aGF0IGhhcHBlbnMgaWYgYSBub2RlIGhhcyBub25lPw0KLSBJ ZiBmcm9tIGFueSwgdGhlbiB3aGF0IGhhcHBlbnMgaWYgYSBub2RlIGdldHMgZGlmZmVyZW50IHZh bHVlcyBvZiBtaW4NCnByaW9yaXR5IG9yIERPREFHX1NpemUgZnJvbSBkaWZmZXJlbnQgcGFyZW50 cz8NCg0KDQpbUkpdIElmIHdlIGFncmVlIHRoYXQgd2UgYXJlIG5vdCBjaGFuZ2luZyA2NTUwIERJ TyBwcm9jZXNzaW5nIGJlaGF2aW9yIGFzIG1lbnRpb25lZCBhYm92ZSwgdGhlbiB0aGVzZSBxdWVz dGlvbnMgZG8gbm90IGFwcGx5Lg0KDQpbUGFzY2FsXSBJIHRoaW5rIHRoZXkgZG8sIHBlciBteSBy ZXBsaWVzIGFib3ZlLg0KDQoNCg0KSG93ZXZlciwgSSBiZWxpZXZlIHRoYXQgYSBtZXRhIHF1ZXN0 aW9uIHdvcnRoIGFuc3dlcmluZyBmaXJzdCBpczogRG8gd2UNCndhbnQgdG8gaGF2ZSBkaWZmZXJl bnQgbWluIHByaW9yaXR5IHZhbHVlcyBpbiBkaWZmZXJlbnQgc3VidHJlZXMgb3IganVzdA0Kb25l IGdsb2JhbCB2YWx1ZSBmb3IgdGhlIGVudGlyZSBET0RBRz8NCg0KW1JKXSBUaGlzIGlzIHRoZSBw b2ludCB0byBiZSBkaXNjdXNzZWQuIElNTywgdGhlIG1pbiBwcmlvcml0eSBpcyBub3QgYSBjb25z dGFudCBnbG9iYWwgdmFsdWUuIEhvd2V2ZXIsIHRoZSBkcmFmdCB0ZXh0IGNvbnRyYWRpY3RzIHRo aXMgYW5kIHdpbGwgcmFpc2UgdGhlIGlzc3VlIGluIEdIIGJlZm9yZSB3ZSBmaXggaXQgdG8gZ2Fy bmVyIHNvbWUgZGlzY3Vzc2lvbi4NCg0KW1Bhc2NhbF0gVGhlIG1pbiBwcmlvcml0eSBpbiB0aGUg ZHJhZnQgaXMgZWZmZWN0aXZlbHkgZ2xvYmFsLCBzZXQgYnkgdGhlIHJvb3QuIElmIHdlIHdhbnQg b3RoZXIgaW5mbyBpbiB0aGUgZHJhZnQsIGl0IGlzIHN0aWxsIHRpbWUgdG8gYWRkIGl0LCBidXQg cGxlYXNlIGxldOKAmXMgd29yayBvbiBpdCBub3cgYW5kIHRoZW4gc2hpcC4gVGhlcmUgYXJlIGV4 dGVybmFsIGJvZGllcyB3YWl0aW5nIGZvciB0aGlzIHNwZWMuDQoNCg0KDQpFaXRoZXIgb2YgdGhl IGFuc3dlcnMgaW4gbXkgdmlldyByZXF1aXJlcyBleHBsaWNpdCBmb3JtdWxhdGlvbiBhbmQNCnBy ZWZlcmFibHkgYWxzbyBhbiBleHBsYW5hdGlvbiBpbiB0aGUgZHJhZnQuDQoNCltQYXNjYWxdIElu ZGVlZA0KDQoNCg0KDQozLiBFdmVuIGlmIHRoZSBkcmFmdCBpZGVudGlmaWVkIGEgc2luZ2xlIHBh cmVudCBhcyB0aGUgb25seSBzb3VyY2Ugb2YNCm1pbiBwcmlvcml0eSB2YWx1ZXMgZm9yIGEgbm9k ZSwgdGhlcmUgc3RpbGwgd291bGQgYmUgYSBwcm9ibGVtIG9mIHZhbHVlDQpjb25zaXN0ZW5jeS4N Cg0KU2luY2UgdGhlIERPREFHIHJvb3QgY2FuIGNoYW5nZSBpdHMgdmFsdWVzIG9mIG1pbiBwcmlv cml0eSBhbmQNCkRPREFHX1NpemUgYW5kIHNpbmNlIGEgbm9kZSBjYW4gY2hhbmdlIGl0cyBwYXJl bnRzLCB0aGVyZSBtYXkgc3RpbGwgYmUgYQ0KY2FzZSB3aGVuIHRoZSBub2RlIG11c3QgZGVjaWRl IHdoZXRoZXIgdG8gYWRvcHQgdGhlIG5ld2x5IHJlY2VpdmVkDQp2YWx1ZXMgb3Igbm90LiBXaXRo b3V0IGEgcHJvcGVyIGNvbmZsaWN0IHJlc29sdXRpb24gcG9saWN5LCBpdCBtYXkgYmUNCnRoZSBj YXNlIHRoYXQgd2hlbiB0aGUgcm9vdCwgZm9yIGV4YW1wbGUsIGRpc2FibGVzIGVucm9sbG1lbnQs IHRoZW4NCmVuYWJsZXMgaXQgYWdhaW4sIHRoZW4gdGhlIERPREFHIG1heSBleGhpYml0IHN0cmFu Z2UgYmVoYXZpb3JzOiB0aGUNCnJvb3QncyBkZWNpc2lvbiBtYXkgbm90IGJlIHByb3BhZ2F0ZWQg dG8gYWxsIG5vZGVzLCBhIGRlY2lzaW9uIG1heSBiZQ0KcmV2b2tlZCBieSBub2RlcyB0aGF0IGhh dmUgYWxyZWFkeSBhY2NlcHRlZCBpdCwgYW5kIHRoZSBsaWtlLg0KDQpbUkpdIFRoZSBleGFjdCBj b25mbGljdCByZXNvbHV0aW9uIHBvbGljeSBpcyBub3Qgd2l0aGluIHRoZSBzY29wZSBvZiB0aGlz IGRvY3VtZW50LiBIb3dldmVyLCBmb3IgdGhlIHNjZW5hcmlvIHlvdSBxdW90ZWQsICJXaGF0IGhh cHBlbnMgaWYgdGhlIGVucm9sbG1lbnQgaXMgZW5hYmxlZC9kaXNhYmxlZCBieSB0aGUgcm9vdD8i IFdlIGRvIG5vdCBleHBlY3QgdGhlIGVucm9sbG1lbnQgZW5hYmxlL2Rpc2FibGUgdG8gYmUgcHJl Y2lzZWx5IGtub3duIGJ5IGFsbCBvdGhlcnMgaS5lLiwgdGhlcmUgY291bGQgYmUgbm9kZXMgd2hv IGRvIG5vdCBoYXZlIHRoZSBsYXRlc3Qgc3RhdHVzIG9mIHRoZSBlbnJvbGxtZW50IG9wdGlvbi4g VGhpcyBjb3VsZCBjYXVzZSBzb21lIGFkZGl0aW9uYWwgc2lnbmFsaW5nIGkuZS4sIGEgbm9kZSBt aWdodCB0cnkgdG8gam9pbiBldmVuIHRob3VnaCB0aGUgKGxhdGVzdCkgcHJpb3JpdHkgZGlkIG5v dCBhbGxvdyBpdC4gVGhpcyBjb3VsZCBsZWFkIHRvIGEgZmV3IG1vcmUgbWVzc2FnaW5nIGJ1dCBp dCBzaG91bGQgbm90IHJlc3VsdCBpbiBhbnkgdW50b3dhcmQgYmVoYXZpb3IuDQoNCiBbUGFzY2Fs XSBJIGJlbGlldmUgd2UgY2FuIGdldCB0aGluZ3MgYSBsb3Qgc2ltcGxlciBpZiAxKSB0aGUgbWlu IGNvbWVzIG9ubHkgZnJvbSB0aGUgcm9vdCBhcyBvZiBub3cgYW5kIDIpIHdlIGFkZCBhIHNlcXVl bmNlIGNvdW50ZXIgaW4gdGhlIG9wdGlvbiB0aGF0IHRoZSBSb290IGluY3JlbWVudHMgdG8gaW5k aWNhdGUgdGhlIGZyZXNoZXN0Lg0KDQoNCg0KVGhlcmUgYXJlIG1hbnkgd2F5cyBpbiB3aGljaCBz dWNoIGNvbmZsaWN0IHJlc29sdXRpb24gY2FuIGJlIHByb3ZpZGVkLg0KSWYgSSBtYXkgc3VnZ2Vz dCBhbnl0aGluZywgSSB3b3VsZCByZWNvbW1lbmQgYWRkaW5nIHRvIHRoZSBvcHRpb24gYQ0KbG9s bGlwb3Agc2VxdWVuY2UgY291bnRlciAobGlrZSB0aG9zZSBkZXNjcmliZWQgaW4gUkZDIDY1NTAs IHNlY3QuIDcuMiksDQpsZXQncyBjYWxsIGl0IG9zbi4gSXQgd291bGQgZWZmZWN0aXZlbHkgb3Jk ZXIgZGlmZmVyZW50IHZlcnNpb25zIG9mIHRoZQ0Kb3B0aW9uIHZhbHVlcyBwcm9kdWNlZCBieSB0 aGUgRE9EQUcgcm9vdC4gSW4gZWZmZWN0LCB3aGVuZXZlciBhIG5vZGUNCnJlY2VpdmVkIGFuIG9w dGlvbiAoYmUgaXQgZnJvbSBhIHBhcmVudCBvciBhbm90aGVyIG5laWdoYm9yLCBkZXBlbmRpbmcN Cm9uIHRoZSB3YXkgdGhlIHByZXZpb3VzIGlzc3VlcyBhcmUgYWRkcmVzc2VkKSwgaXQgd291bGQg YWRvcHQgdGhlIG1pbg0KcHJpb3JpdHkgYW5kIERPREFHX1NpemUgdmFsdWVzIHRoZSBvcHRpb24g Y2FycmllcyBpZiBhbmQgb25seSBpZiB0aGUgb3NuDQp2YWx1ZSBpbiB0aGUgcmVjZWl2ZWQgb3B0 aW9uIGlzIGdyZWF0ZXIgdGhhbiB0aGUgbm9kZSdzIGxvY2FsbHkgc3RvcmVkDQpvc24uIFRoaXMg d291bGQgZ3VhcmFudGVlIGV2ZW50dWFsIGNvbnNpc3RlbmN5IGFuZCBhdm9pZCBzdHJhbmdlDQpi ZWhhdmlvcnMgc3VjaCBhcyB0aG9zZSBtZW50aW9uZWQgYWJvdmUuDQoNCltSSl0gV2l0aCBMTE5z IHRoZXJlIGlzIG5vIHdheSB0byBoYXZlIGd1YXJhbnRlZWQgY29uc2lzdGVuY3kuIENvbnNpZGVy IHRoZSBjYXNlIHdoZXJlIGEgbm9kZSBnb2VzIG9mZiB0aGUgbmV0d29yayBhbmQgY29tZXMgYmFj ayBsYXRlciBhbmQgZGlkIG5vdCBzZWUgcGFydCBvZiB0aGUgdHJhZmZpYyBhdCBhbGwuDQpBbHNv LCBub3RlIHRoYXQgdGhlcmUgaXMgb3RoZXIgbm9uLXN0YXRpYyBpbmZvcm1hdGlvbiBzdWNoIGFz IG1ldHJpY3MvY29uc3RyYWludHMgdGhhdCBhcmUgY2FycmllZCBieSB0aGUgRElPLiBXb3JzdCBj YXNlIGlmIHRoZSBpbmZvcm1hdGlvbiBjaGFuZ2VzIHRvbyBxdWlja2x5IGFuZCB0aGUgbm9kZXMg bWlnaHQgbm90IGhhdmUgY29uc2lzdGVudCBpbmZvcm1hdGlvbiB0aGVyZSBjb3VsZCBiZSBzb21l IGFkZGl0aW9uYWxseSBtZXNzYWdpbmcgYnV0IG92ZXIgdGltZSB0aGUgbmV0d29yayBzaG91bGQg Y29udmVyZ2UgdG8gdGhlIHJpZ2h0IGNvbmZpZ3VyYXRpb24uIEkgYW0gbm90IHN1cmUgaWYgaW50 cm9kdWNpbmcgc29tZXRoaW5nIGxpa2UgT1NOIGlzIHRoZSB3YXkgdG8gdGFja2xlIHRoaXMgcHJv YmxlbS4NCg0KW1Bhc2NhbF0gQXJmIEkgc2hvdWxkIGhhdmUgcmVhZCBpdCB0aHJvdWdoLiBJIGFn cmVlIHdpdGggS29ucmFkIGFnYWluLg0KDQoNCg0KDQoNCjQuIFdoeSBwdXQgRE9EQUdfU2l6ZSBp biB0aGUgb3B0aW9uPw0KDQpbUkpdIFRoaXMgd2FzIGEgcmVjZW50IHByb3Bvc2l0aW9uLiBQbGVh c2UgY2hlY2sgdGhpcyBkaXNjdXNzaW9uIGZvciBjb250ZXh0LCAiW1JvbGxdIEFib3V0IG1lYXN1 cmUgRE9EQUcgc2l6ZSBhbmQgcHJpb3JpdHk8aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9h cmNoL21zZy9yb2xsLy1NcXF4dlRXLTNiTTVGNGs0cUg3bjVGYXhZTS8+Ig0KaHR0cHM6Ly9tYWls YXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9yb2xsLy1NcXF4dlRXLTNiTTVGNGs0cUg3bjVGYXhZ TS8NCg0KW1Bhc2NhbF0gSW5kZWVkLCB3ZSBoYXZlIHRoZSByZXF1ZXN0IGZyb20gV2ktU1VOIHdo aWNoIHVzZXMgUlBMLiBUaGUgZ29hbCBpcyB0byBiYWxhbmNlIHRoZSBzaXplIG9mIG11bHRpcGxl IGxhcmdlIERPREFHcyBpbiB0aGUgc2FtZSBpbnN0YW5jZS4NCg0KDQoNCg0KSSBjYW4gaW1hZ2lu ZSB0aGF0IG90aGVyIHNlcnZpY2VzL3Byb3RvY29scyB3b3VsZCBsaWtlIHRvIHVzZSBpdCBhcw0K d2VsbCwgYW5kIGV4dHJhY3RpbmcgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIGFuIG9wdGlvbiByZWxh dGVkIHNvbGVseSB0bw0KZW5yb2xsbWVudCBkb2VzIG5vdCBzZWVtIHRoZSBiZXN0IGlkZWEuIEkg aGF2ZSBiZWVuIHRoaW5raW5nIGZvciBzb21lDQp0aW1lIGFib3V0IGFuIG9wdGlvbiBmb3IgUlBM IHRoYXQgd291bGQgcHJvdmlkZSBzb21lIGFnZ3JlZ2F0ZQ0KaW5mb3JtYXRpb24gYWJvdXQgdGhl IERPREFHIHRvIHRoZSBub2Rlcywgc3VjaCBhcyBpdHMgc2l6ZSwgbWF4IGRlcHRoLA0KYW5kIHRo ZSBsaWtlLiBUaGUgb3B0aW9uIGNvdWxkIGFsc28gYmUgdXNlZCBpbiB0aGUgZW5yb2xsbWVudCBw cm9jZXNzLg0KRG8geW91IHRoaW5rIHRoaXMgbWFrZXMgc2Vuc2U/DQoNCltSSl0gc2l6ZSBpcyBh bHJlYWR5IHRoZXJlLiBGb3IgbWF4LWRlcHRoLCB3aGF0IGNvdWxkIGJlIHRoZSB1c2UtY2FzZT8g SXMgdGhlcmUgYW55dGhpbmcgZWxzZSB5b3UgaGF2ZSBpbiBtaW5kPyBXb3VsZCBiZSBuaWNlIHRv IGRpc2N1c3MgaXQgbm93Lg0KDQpbUGFzY2FsXSBJbmRlZWQgbm93IGlzIGEgZ29vZCB0aW1lLiBU aGUgbWF4IGRlcHRoIHdvdWxkIGJlIGFuIGluZGljYXRpb24gZm9yIHRoZSA2TFIgTk9UIFRPIGFj Y2VwdCBqb2lucyBpZiBpdCBpcyB0b28gZGVlcCwgc28gaXQgaXMgcmVsYXRlZCB0byBqb2luLiBO b3cgdGhhdOKAmXMgYWxzbyBhIHZlcnkgZGFuZ2Vyb3VzIHRoaW5nIHRvIGRvLiBJdCB3b3VsZCBo YXBwZW5zaW4gdGhlIGZpZWxkIHRoYXQgc29tZSBuZXR3b3JrcyBnZXQgdmVyeSBkZWVwLCBlLmcu LCB3aGVuIG9uZSBvZiB0aGUgUm9vdHMgcmVib290IGFuZCBsYXJnZSBET0RBR3MgbWVyZ2UgdG8g YWJzb3JiIHRoZSBub2RlcyBsZWZ0IG9ycGhhbi4NCg0KDQoNCg0KDQo1LiBJdCBzaG91bGQgYmUg bWFkZSBjbGVhcmVyIGluIHRoZSBkcmFmdCB3aGF0IGlzIGFjdHVhbGx5IGJlaW5nIGNvbmZpZ3Vy ZWQuDQoNClRoZSBvbmx5IHBsYWNlIHdoZXJlIGZpZWxkICJwcm94eSBwcmlvcml0eSIgb2YgRUIg YXBwZWFycyBpbiB0aGUgZW50aXJlDQpkcmFmdCBpcyBwYXIuIDggb2Ygc2VjdC4gMS4gUmVhZGlu ZyB0aGUgZHJhZnQgZm9yIHRoZSBmaXJzdCB0aW1lIEkgd2FzDQpjb25mdXNlZCB3aGF0IG1pbiBw cmlvcml0eSBmb3IgdGhlIG9wdGlvbiBpcyB1c2VkIGZvciBhbmQgd2hhdCBpcw0KYWN0dWFsbHkg YWRqdXN0ZWQgYXQgdmFyaW91cyBwbGFjZXMuDQoNCltSSl0gVGhlIGFpbSBvZiB0aGUgZHJhZnQg d2FzIHRvIGJlIGdlbmVyaWMgZW5vdWdoIGJ1dCBhbHNvIHNlcnZlL2Z1bGZpbGwgdGhlIHVzZS1j YXNlIGZvciB0aGUgNnRpc2NoIHNjZW5hcmlvLiBIZW5jZSB0aGUgRUIgcG9pbnQgYXBwZWFycyBv bmx5IGluIHRoZSBpbnRyb2R1Y3Rpb24uDQpJbiBteSBwcmV2aW91cyBleHBlcmllbmNlIHdoZXJl IHdlIHVzZWQgUEFOQTxodHRwczovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9Qcm90b2NvbF9mb3Jf Q2FycnlpbmdfQXV0aGVudGljYXRpb25fZm9yX05ldHdvcmtfQWNjZXNzPiBmb3Igb25ib2FyZGlu ZyBub2RlcyBpbiBhbiBBTUkgbmV0d29yaywgd2UgbmVlZGVkIGEgc2ltaWxhciBmZWF0dXJlIGFu ZCB3ZSBlbmRlZCB1cCB1c2luZyBhIHByb3ByaWV0YXJ5IChidXQgc2ltaWxhcikgc2lnbmFsaW5n Lg0KDQogW1Bhc2NhbF0gQWxsIHRydWUsIGFuZCB5ZXQgd2UgaGF2ZSBhbiBvcHBvcnR1bml0eSB0 byBjbGFyaWZ5IHRoYXQgdGV4dCB0aGF0IHdlIG5lZWQgdG8gbGV2ZXJhZ2UgYmVmb3JlIElFU0cs IGJlY2F1c2UgdGhhdCBwb2ludCB3b3VsZCBjb21lIGJhY2sgd2l0aCBhIHJldmVuZ2UuIExldOKA mXMgY2xhcmlmeS4NCg0KRm9yIHRoZSBlZGl0b3JpYWwgZGlzY3Vzc2lvbnMsIEkgYWdyZWUgd2l0 aCBLb25yYWTigJlzIHBvaW50IGFuZCAgUmFodWzigJlzIGFuc3dlcnMgYW5kIGxlYXZlIGl0IHlv dXIgZWNoYW5nZS4NCg0KS2VlcCBzYWZlIQ0KDQpQYXNjYWwNCg0K --_000_CO1PR11MB48812CDAA6A2E3DC818FC0C8D8F39CO1PR11MB4881namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEg NiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxl LW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt Y29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAu ODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZh Y2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBub2Rl cyB0aGVuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxmb250IHNpemU9IjIiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7 IGFkanVzdCB0aGlzIGJhc2UgdmFsdWUgYmFzZWQgdXBvbiB0aGVpciBvYnNlcnZlZCBjb25nZXN0 aW9uLCBlbWl0dGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyB0aGVpciBhZGp1c3RlZCBESU8gdmFsdWUgdG8gdGhlaXIgY2hpbGRyZW4uPG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9 IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQg c2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtd2VpZ2h0OmJvbGQiPkZyb206PC9zcGFuPjwvZm9udD48L2I+IFJvbGwgJmx0 O3JvbGwtYm91bmNlc0BpZXRmLm9yZyZndDsNCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi b2xkIj5PbiBCZWhhbGYgT2YgPC9zcGFuPjwvYj5SYWh1bCBKYWRoYXY8YnI+DQo8Yj48c3BhbiBz dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U2VudDo8L3NwYW4+PC9iPiB2ZW5kcmVkaSA2IGFvw7t0 IDIwMjEgODo0ODxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Ubzo8L3Nw YW4+PC9iPiBSb3V0aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBMb3NzeSBuZXR3b3JrcyAmbHQ7cm9s bEBpZXRmLm9yZyZndDs8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6 PC9zcGFuPjwvYj4gcm9sbC1jaGFpcnMgJmx0O3JvbGwtY2hhaXJzQGlldGYub3JnJmd0Ozxicj4N CjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0Ojwvc3Bhbj48L2I+IFJl OiBbUm9sbF0gUmV2aWV3IG9mIGRyYWZ0LWlldGYtcm9sbC1lbnJvbGxtZW50LXByaW9yaXR5LTA0 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZv bnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzIwMTI0ZCIgZmFj ZT0iVmVyZGFuYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMDEyNEQiPkV4Y2VsbGVudCByZXZp ZXcuIE1hbnkgdGhhbmtzIEtvbnJhZC48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+W1Bhc2NhbF06IHZlcnkgbXVjaCwgeWVzIQ0KPG86 cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMjAxMjRkIiBmYWNlPSJWZXJkYW5hIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzIwMTI0RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250 PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIi IGNvbG9yPSIjMjAxMjRkIiBmYWNlPSJWZXJkYW5hIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIw MTI0RCI+UGxlYXNlIGZpbmQgbXkgY29tbWVudHMgaW5saW5lLjxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXpl PSIyIiBjb2xvcj0iIzIwMTI0ZCIgZmFjZT0iVmVyZGFuYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMyMDEyNEQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzIwMTI0ZCIg ZmFjZT0iVmVyZGFuYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMDEyNEQiPlRoYW5rcyw8bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMyMDEyNGQiIGZhY2U9IlZlcmRhbmEiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMjAxMjREIj5SYWh1bDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIg ZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5PbiBUaHUsIDUgQXVnIDIwMjEgYXQgMDI6MDIsIEtvbnJhZCBJd2FuaWNraSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOml3YW5pY2tpQG1pbXV3LmVkdS5wbCI+aXdhbmlja2lAbWltdXcuZWR1 LnBsPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNh bGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5EZWFyIGF1dGhvcnMsPGJyPg0K PGJyPg0KVGhpcyBpcyB0aGUgZmlyc3QgcmV2aWV3IEkgYW0gZG9pbmcgZm9yIElFVEYncyBkcmFm dCwgc28gYW55IHN1Z2dlc3Rpb25zIDxicj4NCm9uIGhvdyBJIGNvdWxkIGltcHJvdmUgdGhlIHF1 YWxpdHkgb2YgbXkgZnV0dXJlIHJldmlld3MgYXJlIHdlbGNvbWUuPG86cD48L286cD48L3NwYW4+ PC9mb250PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMjAxMjRkIiBmYWNlPSJW ZXJkYW5hIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtW ZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIwMTI0RCI+W1JKXSBUaGlzIGlzIGFuIGV4 Y2VsbGVudCBpbi1kZXB0aCZuYnNwO3Jldmlldy4gQXBwcmVjaWF0ZS48bzpwPjwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPjxicj4NCkkgaGF2ZSB0aGUgZm9sbG93aW5nIG1ham9yIGlzc3VlcyB3aXRoIHRoZSBkcmFm dC4gUGVyaGFwcyBzb21lIG9mIHRoZW0gPGJyPg0KaGF2ZSBiZWVuIGNvdmVyZWQgZHVyaW5nIHNv bWUgbWVldGluZ3MgKHNvcnJ5IGZvciBtaXNzaW5nIHRob3NlKTsgbXkgPGJyPg0KY29tbWVudHMg YXJlIGJhc2VkIGp1c3Qgb24gd2hhdCBJIGdvdCBmcm9tIHRoZSBkcmFmdCAoYW5kIHRoZSByZWxh dGVkIDxicj4NCmRyYWZ0cykuPGJyPg0KPGJyPg0KPGJyPg0KMS4gSSB3YXMgY29uZnVzZWQgYnkg dHdvIHNlZW1pbmdseSBjb250cmFkaWN0b3J5IHN0YXRlbWVudHMuPGJyPg0KPGJyPg0KUGFyLiAy IG9mIHNlY3QuIDIgKHN0YXJ0aW5nIHdpdGggJnF1b3Q7V2l0aCB0aGlzIHNwZWNpZmljYXRpb24m cXVvdDspIHN0YXRlcyB0aGF0IDxicj4NCnRoZSBpbnRyb2R1Y2VkIG9wdGlvbiAmcXVvdDtNVVNU IGJlIHByb3BhZ2F0ZWQgZG93biB0aGUgRE9EQUcgd2l0aG91dCA8YnI+DQptb2RpZmljYXRpb24m cXVvdDsgKGNvbXBhcmVkIHRvIHdoYXQgaXMgaXNzdWVkIGJ5IHRoZSBET0RBRyByb290KS48YnI+ DQo8YnI+DQpIb3dldmVyLCBwYXIuIDIgb2Ygc2VjdC4gMi4xIChzdGFydGluZyB3aXRoICZxdW90 OzZMUnMgdGhhdCBzdXBwb3J0IHRoaXMgPGJyPg0Kb3B0aW9uJnF1b3Q7KSBzdGF0ZXMgdGhhdCAm cXVvdDtub2RlcyBhZGp1c3QgdGhpcyBiYXNlIHZhbHVlIGJhc2VkIHVwb24gdGhlaXIgPGJyPg0K b2JzZXJ2ZWQgY29uZ2VzdGlvbiwgZW1pdHRpbmcgdGhlaXIgYWRqdXN0ZWQgRElPIHZhbHVlIHRv IHRoZWlyIGNoaWxkcmVuLiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFj ZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzIwMTI0ZCIgZmFjZT0iVmVyZGFuYSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMyMDEyNEQiPltSSl0gVGhpcyBpcyBhIGdvb2QgcG9pbnQuIFdpbGwgcmFp c2UgdGhpcyBhcyBhbiBpc3N1ZSBvbiBHSC4gVGhlIHdheSBJIHNlZSBpdCwgdGhlIHZhbHVlIGFk anVzdG1lbnQgbWlnaHQgaGF2ZQ0KIHRvIGJlIGRvbmUgZ29pbmcgZG93bnN0cmVhbSBhbmQgSSB3 b3VsZCBsaWtlIHRvIHNlZSB3aGF0IG90aGVycyB0aGluayBvZiBpdC4gTm9uZXRoZWxlc3MsIHRo ZSB0ZXh0IHdpbGwgbmVlZCBtb2RpZmljYXRpb25zLjwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0i VmVyZGFuYSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPltQYXNjYWxdIFRoZSBmaWVsZCBpcyB0aGUgTUlOIHByaW9yaXR5IGFuZCBp dCBpcyBkZWNpZGVkIGJ5IHRoZSByb290LiBUbyBteSBiZXN0IGtub3dsZWRnZS9tZW1vcnksIHRo ZSBpbnRlbnQgd2FzIHRvIGFkanVzdCB0aGUgcHJpb3JpdHkgdmFsdWUgdGhhdCBpcyByZXBvcnRl ZCBvdXRzaWRlIG9mIHRoZQ0KIERJTyAoaW4gYmVhY29ucykgdGhhdCBjYW5ub3QgYmUgbG93ZXIg dGhhbiB0aGUgbWluaW11bSBwcmlvcml0eSBpbiB0aGUgRElPLCBlLmcuLCB3aGVuIHRoZSA2TFIg ZXhwb3NlcyBpdHMgZGVzaXJlIHRvIGJlIGEgam9pbiBwcm94eSwgYXMgZGlzY3Vzc2VkIGluIHRo aXMgdGV4dDo8L3NwYW4+PC9mb250Pjxmb250IGZhY2U9IlZlcmRhbmEiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNl PSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+4oCcPG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZh Y2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250 PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNvdXJpZXIg TmV3Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IEEgNkxSIHdoaWNoIHdvdWxkIG90aGVyd2lzZSBi ZSB3aWxsaW5nIHRvIGFjdCBhcyBhIF9Kb2luIFByb3h5Xywgd2lsbDxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJD b3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBleGFtaW5lIHRoZSBtaW5pbXVtIHBy aW9yaXR5IGZpZWxkLCBhbmQgdG8gdGhhdCBudW1iZXIsIGFkZCBhbnk8bzpwPjwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0i Q291cmllciBOZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgYWRkaXRpb25hbCBsb2NhbCBjb25z aWRlcmF0aW9uIChzdWNoIGFzIHVwc3RyZWFtIGNvbmdlc3Rpb24pLjxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJD YWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZh Y2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7igJw8bzpwPjwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIg ZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkJ1dCB0aGUgTWlu IHByaW9yaXR5IGluIHRoZSBESU8gaXMgdW5jaGFuZ2VkLiBOb3RlIHRoYXQgaWYgaXQgd2FzLCBh IGNoaWxkIHdpdGggbXVsdGlwbGUgcGFyZW50cyB3b3VsZCBnZXQgY29uZmxpY3RpbmcgRElPcyB3 aXRoIGJvdGggdGltZWx5IGluZm9ybWF0aW9uIGFuZCB3ZSB3b3VsZCBoYXZlIHRvIHNwZWNpZnkN CiB3aGljaCB2YWx1ZSBpdCByZXBvcnRzLiBSaWdodCBub3cgdGhlIGlkZWEgd291bGQgYmUgdG8g cmVwb3J0IHRoZSBtb3N0IHJlY2VudCwgdGhvdWdoIGl0IGlzIHNvbWV3aGF0IHVuY2xlYXIgaG93 IHRoYXQgaXMgZGV0ZXJtaW5lZC48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+U3RpbGwgSSBhZ3JlZSB0aGF0IHdlIG5lZWQgdG8gaW1w cm92ZSB0aGUgdGV4dCwgYXMgS29ucmFkIHNheXMgaXQgaXMgcXVpdGUgY29uZnVzaW5nLjxvOnA+ PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXpl PSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250 IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5J ZiB3ZSB3YW50IHNvbWV0aGluZyB0aGF0IHJlcG9ydHMgdGhlIGxvYWQgb2YgdGhlIERPREFHIGFi b3ZlLCB3ZeKAmWxsIGhhdmUgdG8gZXhhbWluZSB0aGUgdmFsdWUgYW5kIGlmIGl0IGlzIG5lZWRl ZCwgdGhlbiBkZWZpbmUgdGhlIGJlaGF2aW9yLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250 PjwvcD4NCjxkaXYgc3R5bGU9Im1zby1lbGVtZW50OnBhcmEtYm9yZGVyLWRpdjtib3JkZXI6bm9u ZTtib3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20gMGNtIDEu MHB0IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYm9yZGVyOm5vbmU7cGFkZGlu ZzowY20iPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250Pjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQg c2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxi cj4NCldoYXQgSSB1bmRlcnN0YW5kIGlzIHRoYXQgdGhlIGFkanVzdG1lbnQgYXBwbGllcyBvbmx5 IGluIGEgcGFydGljdWxhciA8YnI+DQpjYXNlLiBNb3JlIHNwZWNpZmljYWxseSwgaWYgYSBub2Rl IHJlY2VpdmVzIHRoZSBvcHRpb24sIGl0IGNvcGllcyBpdCB0byA8YnI+DQppdHMgRElPcyB3aXRo b3V0IGFueSBtb2RpZmljYXRpb24uIEluIGNvbnRyYXN0LCBpZiB0aGUgbm9kZSBkb2VzIG5vdCA8 YnI+DQpyZWNlaXZlIHRoZSBvcHRpb24gYnV0IGlzIGNhcGFibGUgb2YgcHJvY2Vzc2luZyBpdCwg dGhlbiBpdCBzeW50aGVzaXplcyA8YnI+DQp0aGUgb3B0aW9uIGZvciBpdHMgRElPcyBieSB0YWtp bmcgYXMgdGhlIG1pbiBwcmlvcml0eSB0aGUgYmFzZSB2YWx1ZSA8YnI+DQooMHg0MCkgYWRqdXN0 ZWQgd2l0aCB0aGUgbm9kZSdzIGxvY2FsIG9ic2VydmF0aW9ucy4gVGhpcyBzZWVtcyA8YnI+DQpp bmNvbnNpc3RlbnQsIHRob3VnaC4gSW4gcGFydGljdWxhciwgdHdvIGNoaWxkcmVuIHdpdGggdGhl IHNhbWUgcGFyZW50IDxicj4NCmNhbiBlbWl0IERJT3Mgd2l0aCBkaWZmZXJlbnQgdmFsdWVzIG9m IG1pbiBwcmlvcml0eS4gV2h5IG5vdCBzaW1wbHkgb21pdCA8YnI+DQp0aGUgb3B0aW9uIGluIHN1 Y2ggYSBjYXNlPzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXpl PSIyIiBjb2xvcj0iIzIwMTI0ZCIgZmFjZT0iVmVyZGFuYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMyMDEyNEQiPltSSl0gVHdvIGNoaWxkcmVuIHdpdGggdGhlIHNhbWUgcGFyZW50IGFyZSBwZXJt aXR0ZWQgdG8mbmJzcDtlbWl0IERJT3Mgd2l0aCBkaWZmZXJlbnQgdmFsdWVzIG9mIG1pbiBwcmlv cml0eS4gQ29uc2lkZXINCiB0aGUgY2FzZSB3aGVyZSBjaGlsZDEgaGFzIGZld2VyIHJlc291cmNl cyB0aGFuIGNoaWxkMiBhbmQgd2FudHMgdG8gbGltaXQgZG93bnN0cmVhbSBub2RlcyBqb2luaW5n IHRocm91Z2ggaXQuIFRoaXMgY2FzZSByZXF1aXJlcyBkaWZmZXJlbnQgbWluLXByaW9yaXR5IHRv IGJlIGVtaXR0ZWQuIFRoZXJlIGFyZSBzZXZlcmFsIG90aGVyIHJlYXNvbnMgd2h5IHRoZSBwcmlv cml0aWVzIGNvdWxkIGJlIGRpZmZlcmVudC48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQo8ZGl2IHN0eWxlPSJtc28tZWxlbWVudDpwYXJhLWJvcmRlci1kaXY7Ym9yZGVyOm5vbmU7 Ym9yZGVyLWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAxLjBw dCAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJvcmRlcjpub25lO3BhZGRpbmc6 MGNtIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSI+PGZvbnQgc2l6ZT0iMiIg ZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPltQYXNjYWxdDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJvcmRlcjpub25lO3BhZGRpbmc6MGNtIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9m b250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJib3JkZXI6bm9uZTtwYWRkaW5n OjBjbSI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPlRvIEtvbnJhZOKAmXMgcG9pbnQgOiBJICZuYnNwO2FncmVlIHdpdGggeW91IHRo YXQgdGhpcyBjcmVhdGVzIGEgc2l0dWF0aW9uIHRoYXQgaXMgbm9ybWFsbHkgc2VlbiBvbmx5IHdo ZW4gdGhlIHJvb3QgY2hhbmdlcyB0aGUgdmFsdWUgKHdoaWNoIGFyZ3VhYmx5DQogbWF5IGhhcHBl biBhIGxvdCBhbmQgc2hvdWxkIGJlIGRhbXBlbmVkIHdpdGggaHlzdGVyZXNpcyBhbmQgc3R1ZmYp LiBJIGJlbGlldmUgd2Ugc2hvdWxkIHJldHJhY3QgdGhlIHRleHQgdGhhdCBhbGxvd3MgdGhlIDZM UiB0byBnZW5lcmF0ZSB0aGUgb3B0aW9uLCByZWFzb24gaXMsIGlmIHRoZSByb290IHNldHMgaXQg YW5kIG9ubHkgdGhlIDZMUuKAmXMgcGFyZW50IGRvIG5vdCBzdXBwb3J0LCBhIGNoaWxkIG9mIHRo ZSA2TFIgbWF5IHNlZSBiaXRoIHRoZQ0KIFJvb3TigJlzIHZhbHVlIGFuZCB0aGUgNkxS4oCZcyB2 YWx1ZS4gRGFuZ2Vyb3VzLiBTbyB0aGUgc3VnZ2VzdGlvbiBpcyB0byByZXRyYWN0PG86cD48L286 cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJib3JkZXI6 bm9uZTtwYWRkaW5nOjBjbSI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPuKAnDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYm9yZGVyOm5vbmU7cGFkZGluZzowY20iPjxmb250 IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoZSBu b2RlcyB0aGVuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7IGFkanVzdCB0aGlzIGJhc2UgdmFsdWUgYmFzZWQgdXBvbiB0aGVpciBvYnNlcnZlZCBjb25n ZXN0aW9uLCBlbWl0dGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2IHN0eWxl PSJtc28tZWxlbWVudDpwYXJhLWJvcmRlci1kaXY7Ym9yZGVyOm5vbmU7Ym9yZGVyLWJvdHRvbTpz b2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAxLjBwdCAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJvcmRlcjpub25lO3BhZGRpbmc6MGNtIj48Zm9udCBzaXpl PSIyIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB0aGVpciBhZGp1 c3RlZCBESU8gdmFsdWUgdG8gdGhlaXIgY2hpbGRyZW48L3NwYW4+PC9mb250PiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KIOKAnDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJv cmRlcjpub25lO3BhZGRpbmc6MGNtIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250 PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJib3JkZXI6bm9uZTtwYWRkaW5nOjBj bSI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPuKAnDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYm9yZGVyOm5vbmU7cGFkZGluZzowY20iPjxmb250IHNpemU9IjIiIGZhY2U9 IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJvcmRlcjpu b25lO3BhZGRpbmc6MGNtIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+VG8gUmFodWzigJlzOiBUaGlzIGNvdWxkIGJlIGFuIGltcG9y dGFudCB0aGluZyB0byByZXBvcnQsIGFuZCB3ZSBjYW4gdGFrZSBpdCBvdXRzaWRlIHRoaXMgdGhy ZWFkLiBBcyBvZiB0b2RheSB3ZSBkbyBub3QgcmVwb3J0IHRoZSBwYXJlbnQgbG9hZC9jYXBhYmls aXR5DQogdG8gdGFrZSBtb3JlIGNoaWxkcmVuIGluIERJT3MuIFRoZSByZWFzb24gd2UgZGlkIG5v dCBkbyB0aGF0IGluIHRoZSBwYXN0IHdhcyB0byBsaW1pdCB0aGUgY29tcGxleGl0eSBvZiB0aGUg UlBMIHNwZWMuIEJlY2F1c2UgeW914oCZZCBhbHNvIG5lZWQgdG8gZXhwbGFpbiB3aGF0IG5vZGVz IGRvIHdpdGggdGhlIGluZm9ybWF0aW9uLCBlLmcuLCBob3cgdG8gYmFsYW5jZSB0aGUgZ3JhcGgg c28gdGhhdCBldmVyeW9uZSBoYXMgYXQgbGVhc3Qgb25lIHBhcmVudCwNCiB3aGljaCB3b3VsZCBp bnZvbHZlIHNvbWUgc2hvdWxkZXIgdG8gc2hvdWxkZXIgcHVzaGJhY2suIFNvIHdlIHNhaWQgYXQg dGhlIHRpbWUsIGVpdGhlciBhbGwgbm9kZXMgaGF2ZSBlbm91Z2ggbWVtb3J5IG9yIHlvdSBnbyBm b3Igbm9uLXN0b3JpbmcsIGJ1dCB5b3UgbmV2ZXIgaGF2ZSB0byByZWFjdCB0byB0aGUgcGFyZW50 4oCZcyBsb2FkLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYm9yZGVyOm5vbmU7cGFkZGluZzowY20iPjxmb250IHNpemU9IjIiIGZhY2U9 IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJvcmRlcjpu b25lO3BhZGRpbmc6MGNtIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+VGhpcyBpcyBzb21ldGhpbmcgd2UgY2FuIHJlb3BlbiBub3cs IGJ1dCBwcm9iYWJseSB1bmRlciB0aGUgUlBMdjIgdW1icmVsbGEuPG86cD48L286cD48L3NwYW4+ PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJib3JkZXI6bm9uZTtwYWRk aW5nOjBjbSI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYm9yZGVyOm5vbmU7cGFkZGluZzowY20iPjxiPjxmb250IHNp emU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt d2VpZ2h0OmJvbGQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L2I+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9m b250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGli cmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPjxicj4NCjxicj4NCjIuIFRoZSBkcmFmdCBpbXBsaWNpdGx5IGFzc3VtZXMgYSBESU8gcHJv Y2Vzc2luZyBwb2xpY3kgdGhhdCBkaWZmZXJzIDxicj4NCmZyb20gUlBMJ3Mgb3JpZ2luYWwgb25l Ljxicj4NCjxicj4NCk1vcmUgc3BlY2lmaWNhbGx5LCB0aHJvdWdob3V0IHRoZSBkcmFmdCwgaXQg aXMgaW1wbGllZCBvciBhc3N1bWVkIHRoYXQgYSA8YnI+DQpub2RlIHByb2Nlc3NlcyB0aGUgb3B0 aW9uIHJlY2VpdmVkIG9ubHkgZnJvbSBpdHMgcGFyZW50KHMpLiBGb3IgZXhhbXBsZTo8YnI+DQot IHBhci4gOCBvZiBzZWN0LiAxIChzdGFydGluZyB3aXRoICZxdW90O0EgbmV0d29yayBvcGVyYXRv ciBtaWdodCZxdW90Oyk6ICZxdW90Oy4uLiBpdCA8YnI+DQp3b3VsZCBsaWtlIHRvIGFkanVzdCB0 aGUgZW5yb2xsbWVudCBwcmlvcml0eSAodGhlIHByb3h5IHByaW9yaXR5IGZpZWxkIDxicj4NCm9m IFsuLi5dKSBhbW9uZyBhbGwgbm9kZXMgaW4gdGhlIHN1YnRyZWUgb2YgYSBjb25nZXN0ZWQgbGlu ay4mcXVvdDs7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxp YnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+LSBwYXIuIDEgb2Ygc2VjdC4gMi4x IChzdGFydGluZyB3aXRoICZxdW90O0EgNkxSIHdoaWNoIGRpZCBub3Qgc3VwcG9ydCZxdW90Oyk6 DQo8YnI+DQomcXVvdDtDaGlsZHJlbiBhbmQgZ3JhbmRjaGlsZHJlbiBub2RlcyB3b3VsZCB0aGVy ZWZvcmUgbm90IHJlY2VpdmUgYW55IDxicj4NCnRlbGVtZXRyeSB2aWEgdGhhdCBwYXRoIGFuZCBu ZWVkIHRvIGFzc3VtZSBhIGRlZmF1bHQgdmFsdWUuJnF1b3Q7Ozxicj4NCi0gcGFyLiAyIG9mIHNl Y3QuIDIuMTogJnF1b3Q7NkxScyB0aGF0IHN1cHBvcnQgdGhpcyBvcHRpb24sIGJ1dCB3aG9zZSBw YXJlbnQgPGJyPg0KZG9lcyBub3Qgc2VuZCBpdCBbLi4uXSZxdW90OyBhbmQgdGhlIHJlc3Qgb2Yg dGhlIHBhcmFncmFwaCBhcyB3ZWxsLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQg c2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxi cj4NCkluIGNvbnRyYXN0LCBSRkMgNjU1MCwgc2VjdC4gOC4yLjMgc3RhdGVzIHRoYXQgRElPcyBu b3Qgb25seSBmcm9tIDxicj4NCnBhcmVudHMgYnV0IGFsc28gb3RoZXIgbmVpZ2hib3JzIG11c3Qg YmUgcHJvY2Vzc2VkIGJ5IGEgbm9kZS4gVGhpcyA8YnI+DQpndWFyYW50ZWVzIGNvcnJlY3Qgcm91 dGUgZm9ybWF0aW9uIGFuZCBtYWludGVuYW5jZS48YnI+DQo8YnI+DQpUaGVyZWZvcmUsIGlmIHRo ZSBkcmFmdCBjaGFuZ2VzIHRoaXMgcG9saWN5IHdpdGggcmVzcGVjdCB0byB0aGUgPGJyPg0KaW50 cm9kdWNlZCBvcHRpb24sIEkgd291bGQgZXhwZWN0IGl0IHRvIHN0YXRlIHRoaXMgY2hhbmdlIGV4 cGxpY2l0bHkuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9m b250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9 IjIiIGNvbG9yPSIjMjAxMjRkIiBmYWNlPSJWZXJkYW5hIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzIwMTI0RCI+W1JKXSBJIGRvbid0IHRoaW5rIHRoZSBkcmFmdCBjaGFuZ2VzIHRoaXMgcG9saWN5 LjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzIwMTI0ZCIgZmFjZT0iVmVyZGFuYSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMDEyNEQiPlJGQyA2NTUwIHNheXMgdGhhdCB0aGUgRElP IHdpbGwgYmUgcmVjZWl2ZWQgYnkgYSBub2RlIGZyb20gYWxsIGl0cyBuZWlnaGJvcnMgYW5kIHRo YXQgaXMgYmVjYXVzZSBvZiB0aGUgYnJvYWRjYXN0DQogbmF0dXJlIG9mIHRoZSBESU9zLiBXaGVu IERJT3MgYXJlIHJlY2VpdmVkIGZyb20gdGhlIG5laWdoYm9ycywgdGhlc2UgbmVpZ2hib3JzIGNv dWxkIGJlIHByb21vdGVkIHRvIHRoZSBwYXJlbnQgc2V0LiBUaGUgZHJhZnQgZG9lcyBub3QgY2hh bmdlIHRoaXMgcHJvY2Vzc2luZyBiZWhhdmlvci4gUGFyIDIgb2Ygc2VjdCAyLjEgJnF1b3Q7NkxS cyB0aGF0IHN1cHBvcnQgdGhpcyBvcHRpb24sIGJ1dCB3aG9zZSBwYXJlbnQgZG9lcyBub3Qgc2Vu ZCBpdC4uLi4mcXVvdDsNCiB0aGlzIHN0YXRlbWVudCBkb2VzIG5vdCBjaGFuZ2UgdGhlIDY1NTAg YmVoYXZpb3IuIEFsbCBpdCBzYXlzIGlzIGZvciBzb21lIHJlYXNvbiwgaWYgdGhlIHNlbGVjdGVk IHBhcmVudCBkb2VzIG5vdCBzdXBwb3J0IHRoZSBvcHRpb24gdGhlbiB0aGUgZHJhZnQgZGljdGF0 ZXMgYSBwYXJ0aWN1bGFyIGJlaGF2aW9yLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJW ZXJkYW5hIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtW ZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+W1Bhc2NhbF0gSSBiZWxpZXZlIHRoYXQgS29u cmFk4oCZcyBwb2ludCBpcyB0aGF0PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij7igJw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8cHJlPjxmb250IHNpemU9IjIiIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+UlBMIGxpbWl0cyB0aGUgY2FzZXMgd2hlcmUgYSBub2RlIG1heSBwcm9j ZXNzIERJTyBtZXNzYWdlcyBmcm9tPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHBy ZT48Zm9udCBzaXplPSIyIiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPiZuYnNwOyZuYnNwOyBkZWVwZXIgbm9kZXMgdG8gc29tZSBmb3JtIG9mIGxvY2Fs IHJlcGFpci4gPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+4oCcICZuYnNwO2Zyb20gUkZDIDY1NTAsIGFzIGV4cGxhaW5lZCBpbiBt b3JlIGRldGFpbHMgaW4gJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvaHRtbC9yZmM2NTUwI3NlY3Rpb24tOC4yLjIuNCI+aHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvaHRtbC9yZmM2NTUwI3NlY3Rpb24tOC4yLjIuNDwvYT48bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFj ZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIy IiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+V2hpY2ggaXMg SU9XIHRoYXQgYSBub2RlIG5vcm1hbGx5IGlnbm9yZXMgRElPcyBjb21pbmcgZnJvbSBkZWVwZXIu IEJ1dCBpdCBuZWVkcyB0byBwcm9jZXNzIERJT3MgZm9yIGFsbCBub2RlcyB0aGF0IG1heSBiZWNv bWUgcG90ZW50aWFsIHBhcmVudC48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPk9uIHRoZSBvbmUgaGFuZCBJ4oCZZCBzYXkgdGhhdCBpZiB0aGUg b3B0aW9uIGlzIGV4cGVjdGVkIHRvIHJlcG9ydCBwYXJlbnQgbG9hZCBpbiB0aGUgZnV0dXJlLCB0 aGUgbm9kZSBzaG91bGQgcGFyc2UgdGhlIG9wdGlvbiBpbiBhbnkgRElPIHRoYXQgaXMgYWNjZXB0 YWJsZSBvdGhlcndpc2UsIGFuZCB0byBLb25yYWTigJlzDQogcG9pbnQgZm9sbG93IHRoZSBleGFj dCBzYW1lIHJ1bGVzIGFzIFJQTC48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPk9UT0gsIHRoaXMgaXMgbW9yZSBjaGFuY2VzIGZvciBnZXR0aW5n IGRpZmZlcmVudCB2YWx1ZXMgYWxvbmcgZGlmZmVyZW50IGFzeW5jaHJvbm91cyBwYXRocy4gV2hp Y2ggbWFrZXMgdGhlIHByb2JsZW0gb2YgZmluZGluZyB0aGUgbW9zdCByZWNlbnQgdmFsdWUgZXZl biBoYXJkZXIuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPlNlZW1zIHRoYXQgdGhlIG9wdGlvbiBzaG91bGQgaGF2ZSBpdHMgb3duIHNl cXVlbmNlLCB3aGljaCBpcyBhIGdlbmVyaWMgcHJvYmxlbSB0aGF0IHdhcyBkaXNjdXNzZWQgaW4g ZHJhZnQtdGh1YmVydC1yb2xsLWVsaWRpbmctZGlvLWluZm9ybWF0aW9uLiBOb3RlIHRoYXQgaW4g dGhpcyBjYXNlLCBJIGRvIG5vdA0KIGJlbGlldmUgdGhhdCB3ZSBzaG91bGQgY2hhbmdlIHRoZSBS Q1NTIGluIHRoYXQgZHJhZnQsIHNvIHRoZSBiZXN0IGNvdWxkIGJlIHRoYXQgdGhlIG9wdGlvbiBo YXMgaXRzIG93biBzZXF1ZW5jZS4gVGhlIHRleHQgd291bGQgY2hhbmdlIHRvIHJlZmxlY3QgdGhh dCB3ZSB1c2UgYW55IERJTyB0aGF0IHdlIG5vcm1hbGx5IHVzZSwgYW5kIHJldGFpbiB0aGUgdmFs dWUgb2YgdGhlIG1pbiBwcmlvcml0eSBmcm9tIHRoZSBtb3N0IHJlY2VudCBvZiBhbGwuPG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9 IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdiBzdHlsZT0ibXNvLWVsZW1lbnQ6cGFy YS1ib3JkZXItZGl2O2JvcmRlcjpub25lO2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAx LjBwdDtwYWRkaW5nOjBjbSAwY20gMS4wcHQgMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJy aSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIi IGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPjxicj4NClN1Y2ggYSBjaGFuZ2Ugd291bGQgYWxzbyByZXF1aXJlIGFu c3dlcmluZyBzZXZlcmFsIHF1ZXN0aW9ucywgbm90YWJseTo8YnI+DQotIEZyb20gd2hpY2ggcGFy ZW50IGRvIHdlIHByb2Nlc3MgdGhlIG9wdGlvbj88YnI+DQotIElmIG9ubHkgZnJvbSB0aGUgcHJl ZmVycmVkIHBhcmVudCwgd2hhdCBoYXBwZW5zIGlmIGEgbm9kZSBoYXMgbm9uZT88YnI+DQotIElm IGZyb20gYW55LCB0aGVuIHdoYXQgaGFwcGVucyBpZiBhIG5vZGUgZ2V0cyBkaWZmZXJlbnQgdmFs dWVzIG9mIG1pbiA8YnI+DQpwcmlvcml0eSBvciBET0RBR19TaXplIGZyb20gZGlmZmVyZW50IHBh cmVudHM/PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmki PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6 ZT0iMiIgY29sb3I9IiMyMDEyNGQiIGZhY2U9IlZlcmRhbmEiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMjAxMjREIj5bUkpdIElmIHdlIGFncmVlIHRoYXQgd2UgYXJlIG5vdCBjaGFuZ2luZyA2NTUw IERJTyBwcm9jZXNzaW5nIGJlaGF2aW9yIGFzIG1lbnRpb25lZCBhYm92ZSwgdGhlbiB0aGVzZSBx dWVzdGlvbnMNCiBkbyBub3QgYXBwbHkuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPltQYXNjYWxdIEkgdGhpbmsgdGhleSBkbywgcGVy IG15IHJlcGxpZXMgYWJvdmUuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXYgc3R5 bGU9Im1zby1lbGVtZW50OnBhcmEtYm9yZGVyLWRpdjtib3JkZXI6bm9uZTtib3JkZXItYm90dG9t OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20gMGNtIDEuMHB0IDBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYm9yZGVyOm5vbmU7cGFkZGluZzowY20iPjxmb250IHNp emU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGli cmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48YnI+DQpIb3dldmVyLCBJIGJlbGll dmUgdGhhdCBhIG1ldGEgcXVlc3Rpb24gd29ydGggYW5zd2VyaW5nIGZpcnN0IGlzOiBEbyB3ZSA8 YnI+DQp3YW50IHRvIGhhdmUgZGlmZmVyZW50IG1pbiBwcmlvcml0eSB2YWx1ZXMgaW4gZGlmZmVy ZW50IHN1YnRyZWVzIG9yIGp1c3QgPGJyPg0Kb25lIGdsb2JhbCB2YWx1ZSBmb3IgdGhlIGVudGly ZSBET0RBRz88bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0i MiIgY29sb3I9IiMyMDEyNGQiIGZhY2U9IlZlcmRhbmEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MjAxMjREIj5bUkpdIFRoaXMgaXMgdGhlIHBvaW50IHRvIGJlIGRpc2N1c3NlZC4gSU1PLCB0aGUg bWluIHByaW9yaXR5IGlzIG5vdCBhIGNvbnN0YW50IGdsb2JhbCB2YWx1ZS4gSG93ZXZlciwgdGhl IGRyYWZ0DQogdGV4dCBjb250cmFkaWN0cyB0aGlzIGFuZCB3aWxsIHJhaXNlIHRoZSBpc3N1ZSBp biBHSCBiZWZvcmUgd2UgZml4IGl0IHRvIGdhcm5lciBzb21lIGRpc2N1c3Npb24uPG86cD48L286 cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPltQYXNjYWxdIFRoZSBtaW4gcHJpb3JpdHkgaW4gdGhlIGRyYWZ0IGlz IGVmZmVjdGl2ZWx5IGdsb2JhbCwgc2V0IGJ5IHRoZSByb290LiBJZiB3ZSB3YW50IG90aGVyIGlu Zm8gaW4gdGhlIGRyYWZ0LCBpdCBpcyBzdGlsbCB0aW1lIHRvIGFkZCBpdCwgYnV0IHBsZWFzZSBs ZXTigJlzIHdvcmsgb24gaXQgbm93DQogYW5kIHRoZW4gc2hpcC4gVGhlcmUgYXJlIGV4dGVybmFs IGJvZGllcyB3YWl0aW5nIGZvciB0aGlzIHNwZWMuPG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCjxkaXYgc3R5bGU9Im1zby1lbGVtZW50OnBhcmEtYm9yZGVyLWRpdjtib3JkZXI6bm9uZTti b3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20gMGNtIDEuMHB0 IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYm9yZGVyOm5vbmU7cGFkZGluZzow Y20iPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48YnI+DQpFaXRoZXIgb2YgdGhlIGFuc3dlcnMgaW4g bXkgdmlldyByZXF1aXJlcyBleHBsaWNpdCBmb3JtdWxhdGlvbiBhbmQgPGJyPg0KcHJlZmVyYWJs eSBhbHNvIGFuIGV4cGxhbmF0aW9uIGluIHRoZSBkcmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJy aSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJD YWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+W1Bhc2NhbF0gSW5kZWVkPG86 cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXYgc3R5bGU9Im1zby1lbGVtZW50OnBhcmEt Ym9yZGVyLWRpdjtib3JkZXI6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4w cHQ7cGFkZGluZzowY20gMGNtIDEuMHB0IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYm9yZGVyOm5vbmU7cGFkZGluZzowY20iPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmki PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBm YWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9 IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQg c2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxi cj4NCjMuIEV2ZW4gaWYgdGhlIGRyYWZ0IGlkZW50aWZpZWQgYSBzaW5nbGUgcGFyZW50IGFzIHRo ZSBvbmx5IHNvdXJjZSBvZiA8YnI+DQptaW4gcHJpb3JpdHkgdmFsdWVzIGZvciBhIG5vZGUsIHRo ZXJlIHN0aWxsIHdvdWxkIGJlIGEgcHJvYmxlbSBvZiB2YWx1ZSA8YnI+DQpjb25zaXN0ZW5jeS48 YnI+DQo8YnI+DQpTaW5jZSB0aGUgRE9EQUcgcm9vdCBjYW4gY2hhbmdlIGl0cyB2YWx1ZXMgb2Yg bWluIHByaW9yaXR5IGFuZCA8YnI+DQpET0RBR19TaXplIGFuZCBzaW5jZSBhIG5vZGUgY2FuIGNo YW5nZSBpdHMgcGFyZW50cywgdGhlcmUgbWF5IHN0aWxsIGJlIGEgPGJyPg0KY2FzZSB3aGVuIHRo ZSBub2RlIG11c3QgZGVjaWRlIHdoZXRoZXIgdG8gYWRvcHQgdGhlIG5ld2x5IHJlY2VpdmVkIDxi cj4NCnZhbHVlcyBvciBub3QuIFdpdGhvdXQgYSBwcm9wZXIgY29uZmxpY3QgcmVzb2x1dGlvbiBw b2xpY3ksIGl0IG1heSBiZSA8YnI+DQp0aGUgY2FzZSB0aGF0IHdoZW4gdGhlIHJvb3QsIGZvciBl eGFtcGxlLCBkaXNhYmxlcyBlbnJvbGxtZW50LCB0aGVuIDxicj4NCmVuYWJsZXMgaXQgYWdhaW4s IHRoZW4gdGhlIERPREFHIG1heSBleGhpYml0IHN0cmFuZ2UgYmVoYXZpb3JzOiB0aGUgPGJyPg0K cm9vdCdzIGRlY2lzaW9uIG1heSBub3QgYmUgcHJvcGFnYXRlZCB0byBhbGwgbm9kZXMsIGEgZGVj aXNpb24gbWF5IGJlIDxicj4NCnJldm9rZWQgYnkgbm9kZXMgdGhhdCBoYXZlIGFscmVhZHkgYWNj ZXB0ZWQgaXQsIGFuZCB0aGUgbGlrZS48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZh Y2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMjAxMjRkIiBmYWNlPSJWZXJkYW5hIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIwMTI0RCI+W1JKXSBUaGUgZXhhY3QgY29uZmxpY3QgcmVz b2x1dGlvbiBwb2xpY3kgaXMgbm90IHdpdGhpbiB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4g SG93ZXZlciwgZm9yIHRoZSBzY2VuYXJpbyB5b3UNCiBxdW90ZWQsICZxdW90O1doYXQgaGFwcGVu cyBpZiB0aGUgZW5yb2xsbWVudCBpcyBlbmFibGVkL2Rpc2FibGVkIGJ5IHRoZSByb290PyZxdW90 OyBXZSBkbyBub3QgZXhwZWN0IHRoZSBlbnJvbGxtZW50IGVuYWJsZS9kaXNhYmxlIHRvIGJlIHBy ZWNpc2VseSZuYnNwO2tub3duIGJ5IGFsbCBvdGhlcnMgaS5lLiwgdGhlcmUgY291bGQgYmUgbm9k ZXMgd2hvIGRvIG5vdCBoYXZlIHRoZSBsYXRlc3Qgc3RhdHVzIG9mIHRoZSBlbnJvbGxtZW50IG9w dGlvbi4gVGhpcyBjb3VsZCBjYXVzZQ0KIHNvbWUgYWRkaXRpb25hbCBzaWduYWxpbmcgaS5lLiwg YSBub2RlIG1pZ2h0IHRyeSB0byBqb2luIGV2ZW4gdGhvdWdoIHRoZSAobGF0ZXN0KSBwcmlvcml0 eSBkaWQgbm90IGFsbG93IGl0LiBUaGlzIGNvdWxkIGxlYWQgdG8gYSBmZXcgbW9yZSBtZXNzYWdp bmcgYnV0IGl0IHNob3VsZCBub3QgcmVzdWx0IGluIGFueSB1bnRvd2FyZCBiZWhhdmlvci48bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PC9mb250PltQYXNjYWxdIEkgYmVs aWV2ZSB3ZSBjYW4gZ2V0IHRoaW5ncyBhIGxvdCBzaW1wbGVyIGlmIDEpIHRoZSBtaW4gY29tZXMg b25seSBmcm9tIHRoZSByb290IGFzIG9mIG5vdyBhbmQgMikgd2UgYWRkIGEgc2VxdWVuY2UgY291 bnRlciBpbiB0aGUgb3B0aW9uIHRoYXQgdGhlIFJvb3QNCiBpbmNyZW1lbnRzIHRvIGluZGljYXRl IHRoZSBmcmVzaGVzdC48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9Im1zby1lbGVtZW50OnBh cmEtYm9yZGVyLWRpdjtib3JkZXI6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQg MS4wcHQ7cGFkZGluZzowY20gMGNtIDEuMHB0IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYm9yZGVyOm5vbmU7cGFkZGluZzowY20iPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGli cmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIy IiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNt IDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij48YnI+DQpUaGVyZSBhcmUgbWFueSB3YXlzIGluIHdoaWNoIHN1Y2gg Y29uZmxpY3QgcmVzb2x1dGlvbiBjYW4gYmUgcHJvdmlkZWQuIDxicj4NCklmIEkgbWF5IHN1Z2dl c3QgYW55dGhpbmcsIEkgd291bGQgcmVjb21tZW5kIGFkZGluZyB0byB0aGUgb3B0aW9uIGEgPGJy Pg0KbG9sbGlwb3Agc2VxdWVuY2UgY291bnRlciAobGlrZSB0aG9zZSBkZXNjcmliZWQgaW4gUkZD IDY1NTAsIHNlY3QuIDcuMiksIDxicj4NCmxldCdzIGNhbGwgaXQgb3NuLiBJdCB3b3VsZCBlZmZl Y3RpdmVseSBvcmRlciBkaWZmZXJlbnQgdmVyc2lvbnMgb2YgdGhlIDxicj4NCm9wdGlvbiB2YWx1 ZXMgcHJvZHVjZWQgYnkgdGhlIERPREFHIHJvb3QuIEluIGVmZmVjdCwgd2hlbmV2ZXIgYSBub2Rl IDxicj4NCnJlY2VpdmVkIGFuIG9wdGlvbiAoYmUgaXQgZnJvbSBhIHBhcmVudCBvciBhbm90aGVy IG5laWdoYm9yLCBkZXBlbmRpbmcgPGJyPg0Kb24gdGhlIHdheSB0aGUgcHJldmlvdXMgaXNzdWVz IGFyZSBhZGRyZXNzZWQpLCBpdCB3b3VsZCBhZG9wdCB0aGUgbWluIDxicj4NCnByaW9yaXR5IGFu ZCBET0RBR19TaXplIHZhbHVlcyB0aGUgb3B0aW9uIGNhcnJpZXMgaWYgYW5kIG9ubHkgaWYgdGhl IG9zbiA8YnI+DQp2YWx1ZSBpbiB0aGUgcmVjZWl2ZWQgb3B0aW9uIGlzIGdyZWF0ZXIgdGhhbiB0 aGUgbm9kZSdzIGxvY2FsbHkgc3RvcmVkIDxicj4NCm9zbi4gVGhpcyB3b3VsZCBndWFyYW50ZWUg ZXZlbnR1YWwgY29uc2lzdGVuY3kgYW5kIGF2b2lkIHN0cmFuZ2UgPGJyPg0KYmVoYXZpb3JzIHN1 Y2ggYXMgdGhvc2UgbWVudGlvbmVkIGFib3ZlLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0i MiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMyMDEyNGQiIGZhY2U9IlZlcmRh bmEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRh bmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjAxMjREIj5bUkpdIFdpdGggTExOcyB0aGVyZSBp cyBubyB3YXkgdG8gaGF2ZSBndWFyYW50ZWVkIGNvbnNpc3RlbmN5LiBDb25zaWRlciB0aGUgY2Fz ZSB3aGVyZSBhIG5vZGUgZ29lcyBvZmYgdGhlIG5ldHdvcmsNCiBhbmQgY29tZXMgYmFjayBsYXRl ciBhbmQgZGlkIG5vdCBzZWUgcGFydCBvZiB0aGUgdHJhZmZpYyBhdCBhbGwuPG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxm b250IHNpemU9IjIiIGNvbG9yPSIjMjAxMjRkIiBmYWNlPSJWZXJkYW5hIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzIwMTI0RCI+QWxzbywgbm90ZSB0aGF0IHRoZXJlIGlzIG90aGVyIG5vbi1zdGF0 aWMgaW5mb3JtYXRpb24gc3VjaCBhcyBtZXRyaWNzL2NvbnN0cmFpbnRzIHRoYXQgYXJlIGNhcnJp ZWQgYnkgdGhlIERJTy4gV29yc3QNCiBjYXNlIGlmIHRoZSBpbmZvcm1hdGlvbiBjaGFuZ2VzIHRv byBxdWlja2x5IGFuZCB0aGUgbm9kZXMgbWlnaHQgbm90IGhhdmUgY29uc2lzdGVudCBpbmZvcm1h dGlvbiB0aGVyZSBjb3VsZCBiZSBzb21lIGFkZGl0aW9uYWxseSBtZXNzYWdpbmcgYnV0IG92ZXIg dGltZSB0aGUgbmV0d29yayBzaG91bGQgY29udmVyZ2UgdG8gdGhlIHJpZ2h0IGNvbmZpZ3VyYXRp b24uIEkgYW0gbm90IHN1cmUgaWYgaW50cm9kdWNpbmcgc29tZXRoaW5nIGxpa2UgT1NODQogaXMg dGhlIHdheSB0byB0YWNrbGUgdGhpcyBwcm9ibGVtLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNp emU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZv bnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PltQYXNjYWxdIEFyZiBJIHNob3VsZCBoYXZlIHJlYWQgaXQgdGhyb3VnaC4gSSBhZ3JlZSB3aXRo IEtvbnJhZCBhZ2Fpbi48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdiBzdHlsZT0i bXNvLWVsZW1lbnQ6cGFyYS1ib3JkZXItZGl2O2JvcmRlcjpub25lO2JvcmRlci1ib3R0b206c29s aWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMS4wcHQgMGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSI+PGZvbnQgc2l6ZT0i MiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxp YnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PGJyPg0KPGJyPg0KNC4gV2h5IHB1 dCBET0RBR19TaXplIGluIHRoZSBvcHRpb24/PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIy IiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMjAxMjRkIiBmYWNlPSJWZXJkYW5hIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzIwMTI0RCI+W1JKXSBUaGlzIHdhcyBhIHJlY2VudCBwcm9wb3Np dGlvbi4gUGxlYXNlIGNoZWNrIHRoaXMgZGlzY3Vzc2lvbiBmb3IgY29udGV4dCwgJnF1b3Q7PGEg aHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9yb2xsLy1NcXF4dlRX LTNiTTVGNGs0cUg3bjVGYXhZTS8iPltSb2xsXQ0KIEFib3V0IG1lYXN1cmUgRE9EQUcgc2l6ZSBh bmQgcHJpb3JpdHk8L2E+JnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMjAx MjRkIiBmYWNlPSJWZXJkYW5hIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIwMTI0RCI+PGEgaHJl Zj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9yb2xsLy1NcXF4dlRXLTNi TTVGNGs0cUg3bjVGYXhZTS8iPmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cv cm9sbC8tTXFxeHZUVy0zYk01RjRrNHFIN241RmF4WU0vPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxp YnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9 IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5bUGFzY2FsXSBJbmRlZWQs IHdlIGhhdmUgdGhlIHJlcXVlc3QgZnJvbSBXaS1TVU4gd2hpY2ggdXNlcyBSUEwuIFRoZSBnb2Fs IGlzIHRvIGJhbGFuY2UgdGhlIHNpemUgb2YgbXVsdGlwbGUgbGFyZ2UgRE9EQUdzIGluIHRoZSBz YW1lIGluc3RhbmNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2IHN0eWxlPSJt c28tZWxlbWVudDpwYXJhLWJvcmRlci1kaXY7Ym9yZGVyOm5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xp ZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAxLjBwdCAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJvcmRlcjpub25lO3BhZGRpbmc6MGNtIj48Zm9udCBzaXplPSIy IiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzIwMTI0ZCIgZmFjZT0i VmVyZGFuYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMDEyNEQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+PGJyPg0KSSBjYW4gaW1hZ2luZSB0aGF0IG90aGVyIHNlcnZpY2VzL3Byb3RvY29s cyB3b3VsZCBsaWtlIHRvIHVzZSBpdCBhcyA8YnI+DQp3ZWxsLCBhbmQgZXh0cmFjdGluZyB0aGlz IGluZm9ybWF0aW9uIGZyb20gYW4gb3B0aW9uIHJlbGF0ZWQgc29sZWx5IHRvIDxicj4NCmVucm9s bG1lbnQgZG9lcyBub3Qgc2VlbSB0aGUgYmVzdCBpZGVhLiBJIGhhdmUgYmVlbiB0aGlua2luZyBm b3Igc29tZSA8YnI+DQp0aW1lIGFib3V0IGFuIG9wdGlvbiBmb3IgUlBMIHRoYXQgd291bGQgcHJv dmlkZSBzb21lIGFnZ3JlZ2F0ZSA8YnI+DQppbmZvcm1hdGlvbiBhYm91dCB0aGUgRE9EQUcgdG8g dGhlIG5vZGVzLCBzdWNoIGFzIGl0cyBzaXplLCBtYXggZGVwdGgsIDxicj4NCmFuZCB0aGUgbGlr ZS4gVGhlIG9wdGlvbiBjb3VsZCBhbHNvIGJlIHVzZWQgaW4gdGhlIGVucm9sbG1lbnQgcHJvY2Vz cy4gPGJyPg0KRG8geW91IHRoaW5rIHRoaXMgbWFrZXMgc2Vuc2U/PG86cD48L286cD48L3NwYW4+ PC9mb250PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzIwMTI0ZCIg ZmFjZT0iVmVyZGFuYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMDEyNEQiPltSSl0gc2l6ZSBp cyBhbHJlYWR5IHRoZXJlLiBGb3IgbWF4LWRlcHRoLCB3aGF0IGNvdWxkIGJlIHRoZSB1c2UtY2Fz ZT8gSXMgdGhlcmUgYW55dGhpbmcgZWxzZSB5b3UgaGF2ZSBpbiBtaW5kPw0KIFdvdWxkIGJlIG5p Y2UgdG8gZGlzY3VzcyBpdCBub3cuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPltQYXNjYWxdIEluZGVlZCBub3cgaXMgYSBnb29kIHRp bWUuIFRoZSBtYXggZGVwdGggd291bGQgYmUgYW4gaW5kaWNhdGlvbiBmb3IgdGhlIDZMUiBOT1Qg VE8gYWNjZXB0IGpvaW5zIGlmIGl0IGlzIHRvbyBkZWVwLCBzbyBpdCBpcyByZWxhdGVkIHRvIGpv aW4uIE5vdyB0aGF04oCZcyBhbHNvIGEgdmVyeSBkYW5nZXJvdXMNCiB0aGluZyB0byBkby4gSXQg d291bGQgaGFwcGVuc2luIHRoZSBmaWVsZCB0aGF0IHNvbWUgbmV0d29ya3MgZ2V0IHZlcnkgZGVl cCwgZS5nLiwgd2hlbiBvbmUgb2YgdGhlIFJvb3RzIHJlYm9vdCBhbmQgbGFyZ2UgRE9EQUdzIG1l cmdlIHRvIGFic29yYiB0aGUgbm9kZXMgbGVmdCBvcnBoYW4uPG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCjxkaXYgc3R5bGU9Im1zby1lbGVtZW50OnBhcmEtYm9yZGVyLWRpdjtib3JkZXI6 bm9uZTtib3JkZXItYm90dG9tOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20gMGNt IDEuMHB0IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYm9yZGVyOm5vbmU7cGFk ZGluZzowY20iPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250 PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQg c2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+PGJyPg0KPGJyPg0KNS4gSXQgc2hvdWxkIGJlIG1hZGUg Y2xlYXJlciBpbiB0aGUgZHJhZnQgd2hhdCBpcyBhY3R1YWxseSBiZWluZyBjb25maWd1cmVkLjxi cj4NCjxicj4NClRoZSBvbmx5IHBsYWNlIHdoZXJlIGZpZWxkICZxdW90O3Byb3h5IHByaW9yaXR5 JnF1b3Q7IG9mIEVCIGFwcGVhcnMgaW4gdGhlIGVudGlyZSA8YnI+DQpkcmFmdCBpcyBwYXIuIDgg b2Ygc2VjdC4gMS4gUmVhZGluZyB0aGUgZHJhZnQgZm9yIHRoZSBmaXJzdCB0aW1lIEkgd2FzIDxi cj4NCmNvbmZ1c2VkIHdoYXQgbWluIHByaW9yaXR5IGZvciB0aGUgb3B0aW9uIGlzIHVzZWQgZm9y IGFuZCB3aGF0IGlzIDxicj4NCmFjdHVhbGx5IGFkanVzdGVkIGF0IHZhcmlvdXMgcGxhY2VzLjxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIg Y29sb3I9IiMyMDEyNGQiIGZhY2U9IlZlcmRhbmEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjAx MjREIj5bUkpdIFRoZSBhaW0gb2YgdGhlIGRyYWZ0IHdhcyB0byBiZSBnZW5lcmljIGVub3VnaCBi dXQgYWxzbyBzZXJ2ZS9mdWxmaWxsIHRoZSB1c2UtY2FzZSBmb3IgdGhlIDZ0aXNjaCBzY2VuYXJp by4NCiBIZW5jZSB0aGUgRUIgcG9pbnQgYXBwZWFycyBvbmx5IGluIHRoZSBpbnRyb2R1Y3Rpb24u PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMjAxMjRkIiBmYWNlPSJWZXJkYW5hIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIwMTI0RCI+SW4gbXkgcHJldmlvdXMgZXhwZXJpZW5jZSB3 aGVyZSB3ZSB1c2VkDQo8YSBocmVmPSJodHRwczovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9Qcm90 b2NvbF9mb3JfQ2FycnlpbmdfQXV0aGVudGljYXRpb25fZm9yX05ldHdvcmtfQWNjZXNzIj4NClBB TkE8L2E+IGZvciBvbmJvYXJkaW5nIG5vZGVzIGluIGFuIEFNSSZuYnNwO25ldHdvcmssIHdlIG5l ZWRlZCBhIHNpbWlsYXIgZmVhdHVyZSBhbmQgd2UgZW5kZWQgdXAgdXNpbmcgYSBwcm9wcmlldGFy eSZuYnNwOyhidXQgc2ltaWxhcikgc2lnbmFsaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNh bGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZv bnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PiZuYnNwOzwvc3Bhbj48L2ZvbnQ+W1Bhc2NhbF0gQWxsIHRydWUsIGFuZCB5ZXQgd2UgaGF2ZSBh biBvcHBvcnR1bml0eSB0byBjbGFyaWZ5IHRoYXQgdGV4dCB0aGF0IHdlIG5lZWQgdG8gbGV2ZXJh Z2UgYmVmb3JlIElFU0csIGJlY2F1c2UgdGhhdCBwb2ludCB3b3VsZCBjb21lIGJhY2sgd2l0aCBh IHJldmVuZ2UuDQogTGV04oCZcyBjbGFyaWZ5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+Rm9yIHRoZSBlZGl0b3JpYWwgZGlzY3Vzc2lvbnMsIEkgYWdyZWUg d2l0aCBLb25yYWTigJlzIHBvaW50IGFuZCZuYnNwOyBSYWh1bOKAmXMgYW5zd2VycyBhbmQgbGVh dmUgaXQgeW91ciBlY2hhbmdlLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5LZWVwIHNhZmUhPG86cD48L286cD48L3NwYW4+PC9mb250 PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmki PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6 ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlBhc2Nh bDwvc3Bhbj48L2ZvbnQ+PGZvbnQgY29sb3I9IiMyMDEyNGQiIGZhY2U9IlZlcmRhbmEiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzIwMTI0RCI+PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_CO1PR11MB48812CDAA6A2E3DC818FC0C8D8F39CO1PR11MB4881namp_-- From nobody Mon Aug 9 11:49: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 44F1A3A12B1; Mon, 9 Aug 2021 11:49:12 -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 ADTmlRQlq-0P; Mon, 9 Aug 2021 11:49:06 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 992A03A1337; Mon, 9 Aug 2021 11:48:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 5BC94389B8; Mon, 9 Aug 2021 14:53:24 -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 eKah7feTszZr; Mon, 9 Aug 2021 14: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 2AC6A389B1; Mon, 9 Aug 2021 14:53:15 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8303DC65; Mon, 9 Aug 2021 14:48:40 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks cc: roll-chairs@ietf.org In-Reply-To: References: 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] Review of draft-ietf-roll-enrollment-priority-04 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2021 18:49:21 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Konrad Iwanicki wrote: > I have the following major issues with the draft. Perhaps some of the= m have > been covered during some meetings (sorry for missing those); my comme= nts are > based just on what I got from the draft (and the related drafts). > 1. I was confused by two seemingly contradictory statements. > Par. 2 of sect. 2 (starting with "With this specification") states th= at the > introduced option "MUST be propagated down the DODAG without modifica= tion" > (compared to what is issued by the DODAG root). Good catch. I will remove the words "without modification" > What I understand is that the adjustment applies only in a particular > case. More specifically, if a node receives the option, it copies it = to its > DIOs without any modification. In contrast, if the node does not rece= ive the > option but is capable of processing it, then it synthesizes the optio= n for > its DIOs by taking as the min priority the base value (0x40) adjusted= with > the node's local observations. Agreed. > This seems inconsistent, though. > In particular, two children with the same parent can emit DIOs with d= ifferent > values of min priority. Why not simply omit the option in such a case? So you are assuming the DAG: A / \ B C / \ \ D E F And "A" does not know to send this option, so both B and C assume a value o= f 0x40. Then, each one adjusts this based upon their local conditions. D+E might see a value of 0x50 (if B added 16), while F might see a value of 0x60 (if C added 32). This would make new nodes prefer to enroll with D or E, rather than F. The reason is that perhaps B has more resources than C for new children. > 2. The draft implicitly assumes a DIO processing policy that differs = from > RPL's original one. > More specifically, throughout the draft, it is implied or assumed tha= t a node > processes the option received only from its parent(s). > For example: > - par. 8 of sect. 1 (starting with "A network operator might"): "... = it would > like to adjust the enrollment priority (the proxy priority field of [= ...]) > among all nodes in the subtree of a congested link."; > - par. 1 of sect. 2.1 (starting with "A 6LR which did not support"): > "Children and grandchildren nodes would therefore not receive any tel= emetry > via that path and need to assume a default value."; > - par. 2 of sect. 2.1: "6LRs that support this option, but whose pare= nt does > not send it [...]" and the rest of the paragraph as well. > In contrast, RFC 6550, sect. 8.2.3 states that DIOs not only from par= ents but > also other neighbors must be processed by a node. This guarantees cor= rect > route formation and maintenance. Yes, it's true. A node should evaluate DIOs from other sources, and if tho= se sources are better, then it should switch parents. But at any point, a node really has only one parent. The other nodes are potential parents, but not parents. Perhaps RFC6550 has some other terms which I've neglected to use. > 3. Even if the draft identified a single parent as the only source of= min > priority values for a node, there still would be a problem of value > consistency. > Since the DODAG root can change its values of min priority and DODAG_= Size and > since a node can change its parents, there may still be a case when t= he node > must decide whether to adopt the newly received values or not. Withou= t a > proper conflict resolution policy, it may be the case that when the r= oot, for > example, disables enrollment, then enables it again, then the DODAG m= ay > exhibit strange behaviors: the root's decision may not be propagated = to all > nodes, a decision may be revoked by nodes that have already accepted = it, and > the like. A root that did this, would have to increment the DTSN right each time it changed it's mind. > There are many ways in which such conflict resolution can be provided= . If I > may suggest anything, I would recommend adding to the option a lollip= op > sequence counter (like those described in RFC 6550, sect. 7.2), let's= call it > osn. It would effectively order different versions of the option valu= es > produced by the DODAG root. In effect, whenever a node received an op= tion (be > it from a parent or another neighbor, depending on the way the previo= us > issues are addressed), it would adopt the min priority and DODAG_Size= values > the option carries if and only if the osn value in the received optio= n is > greater than the node's locally stored osn. This would guarantee even= tual > consistency and avoid strange behaviors such as those mentioned above. I'm not convinced we need another lollipop counter. I think that we already have that. > 4. Why put DODAG_Size in the option? > I can imagine that other services/protocols would like to use it as w= ell, and > extracting this information from an option related solely to enrollme= nt does > not seem the best idea. I have been thinking for some time about an o= ption > for RPL that would provide some aggregate information about the DODAG= to the > nodes, such as its size, max depth, and the like. The option could al= so be > used in the enrollment process. Do you think this makes sense? We agreed to merge two drafts. The DODAG_Size came from the other draft. We think that the two values are very much related and it made sense to send them together. > Apart from these major issues, I have also a few editorial suggestion= s. > A. After the par. 1 of sect. 1, I would introduce a subsection heading > titled, for instance, "Terminology Disambiguation" to prepare the rea= ders for > what they are going to see next. okay, I have re-organized some text. > B. Similarly, before par. 5 of sect. 1 (starting with "It has become = clear > that not every routing member"), I would introduce a subsection headi= ng > titled "Motivation and Overview", just "Overview", or something along= these > lines. > C. I would promote the "Terminology" subsection to a section. > D. I would move par. 1 of sect. 2 (starting with "The size of the DOD= AG is > measured by the Root") toward the end of sect. 1 as it has little to = do with > the option definition. okay. > E. I would fix the bullet list in sect. 2.1 so that it renders correc= tly in > the text version of the draft. markdown issue. =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+93Q3WUFAmEReIgACgkQgItw+93Q 3WUoAgf/bsl4GuDf9jM4ct5hsnuR21aYOSdzcTzKOEMpYvanSbxOiEaejE5dWYrE 3ScLnRCBbZhYp7RM00lRRBzljkIkcbCU1xTxR29xySGzRvCCgG0k5et5wdaRuc55 Xu0zQtVtpNyuF2cmb3qlgFZpEdxlVpukdsHkFWAyqieJgdfr684T+RTOyy9TdewQ C82xvBFTd0E7+zeA9DAG44T+2irnsDoDSQ3kmYZD1cWrCqIxaWYZy3H5Gz/Lk19N TKNhbh2NiW7sRfze1EGDr0F0+A1XpavuRShvnvqKKMyKS+u0RgrXHOpIhHxP8e3L TZPxspPqUlIUUC3I7/my8xLwOdC38w== =mWdO -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 9 11:51: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 61F743A118B; Mon, 9 Aug 2021 11:51:45 -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.36.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <162853510532.9659.11036936131672037162@ietfa.amsl.com> Date: Mon, 09 Aug 2021 11:51:45 -0700 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-enrollment-priority-05.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: Mon, 09 Aug 2021 18:51:46 -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 : Controlling Secure Network Enrollment in RPL networks Authors : Michael Richardson Rahul Arvind Jadhav Pascal Thubert Huimin She Filename : draft-ietf-roll-enrollment-priority-05.txt Pages : 9 Date : 2021-08-09 Abstract: [I-D.ietf-6tisch-enrollment-enhanced-beacon] defines a method by which a potential [I-D.ietf-6tisch-minimal-security] enrollment proxy can announce itself as a available for new Pledges to enroll on a network. The announcement includes a priority for enrollment. This document provides a mechanism by which a RPL DODAG root can disable enrollment announcements, or adjust the base priority for enrollment operation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-enrollment-priority/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-roll-enrollment-priority-05.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-enrollment-priority-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 9 12:45:08 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 1A7663A12EC for ; Mon, 9 Aug 2021 12:45:07 -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 v6uoTwXGGGJC for ; Mon, 9 Aug 2021 12:45:01 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0361F3A143D for ; Mon, 9 Aug 2021 12:45:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 03D00389BE for ; Mon, 9 Aug 2021 15:49:35 -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 SjDsdagb7bw9 for ; Mon, 9 Aug 2021 15:49:30 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 258F1389B8 for ; Mon, 9 Aug 2021 15:49:30 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5C894622 for ; Mon, 9 Aug 2021 15:44:55 -0400 (EDT) From: Michael Richardson To: roll@ietf.org In-Reply-To: <162853510532.9659.11036936131672037162@ietfa.amsl.com> References: <162853510532.9659.11036936131672037162@ietfa.amsl.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] I-D Action: draft-ietf-roll-enrollment-priority-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2021 19:45:07 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts di= rectories. > This draft is a work item of the Routing Over Low power and Lossy net= works WG of the IETF. > Title : Controlling Secure Network Enrollment in RPL networ= ks > Authors : Michael Richardson > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-enrollment-priori= ty-05 This includes review comments from Konrad. =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+93Q3WUFAmERhbcACgkQgItw+93Q 3WVF4QgAqcDjjcJbE2kIQczRDV8w3DONWz/K9l1f/U8FDXciWLGZOj0dBXbtoMCg rw8sUkr4ncoJO9BRo9BYGVKFTlC6vIJivnzcYUlryD7UH3PNfgfgnmqcHaqroYtR D7RJHqyJSfIjPfARSCMdtZQCbIgoz3TqO/NcyaCO3OFYpcYU1k/XHPA29r5EL3FT wSgKu3ocAyo3VSMstGq5wWEi3Ywr0twc423R4RWZq9ottZ5D6o5cZuz3NCum20BS 74GtEZyFcSDcwEu0QLlm/GucSm5dnnAE0Oc1n2TNvW05um7obrIGz/WBXGgyGMBF sn989m90qqeK18RnLa8s9b8ciUh+tA== =iVsz -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 9 14:09:59 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 BB0D43A176B; Mon, 9 Aug 2021 14:09:57 -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 5i-nVdRurxlE; Mon, 9 Aug 2021 14:09:55 -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 579E63A1704; Mon, 9 Aug 2021 14:09:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by duch.mimuw.edu.pl (Postfix) with ESMTP id 9B60761DA0897; Mon, 9 Aug 2021 23:09: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 jFWhX80TR_01; Mon, 9 Aug 2021 23:09:45 +0200 (CEST) Received: from Konrads-MacBook-Pro.local (unknown [IPv6:2a02:a311:813e:880:3194:b38d:ab3e:5e37]) (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; Mon, 9 Aug 2021 23:09:43 +0200 (CEST) To: Routing Over Low power and Lossy networks , Michael Richardson Cc: roll-chairs@ietf.org References: <26245.1628534920@localhost> From: Konrad Iwanicki Message-ID: Date: Mon, 9 Aug 2021 23:09:37 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <26245.1628534920@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Roll] Review of draft-ietf-roll-enrollment-priority-04 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2021 21:09:58 -0000 Dear Michael and all, First of all, thank you for your kind words regarding the review. I am actually planning to attend the August interim, because I will be presenting the rnfd draft, so we can discuss the enrollment priority draft in depth as well. Below I just quickly reply inline to Michael's comments as they led to a new version of the draft. I was actually replying to Pascal's and Rahul's comments while the new draft version appeared, and the new version still has some issues, which I wanted to point out in those replies. So what do I do then, write another review for the new version where I can explain those issues? On 09/08/2021 20:48, Michael Richardson wrote: > > In contrast, RFC 6550, sect. 8.2.3 states that DIOs not only from parents but > > also other neighbors must be processed by a node. This guarantees correct > > route formation and maintenance. > > Yes, it's true. A node should evaluate DIOs from other sources, and if those > sources are better, then it should switch parents. But at any point, a node > really has only one parent. > The other nodes are potential parents, but not parents. > Perhaps RFC6550 has some other terms which I've neglected to use. I believe RFC 6550 uses term "parent" for any neighbor with a rank lower than the node itself and "preferred parent" for the parent (conceptually a single one) that the node uses as the next hop on its upward routes. This may be one of the sources of my confusion. After your explanation, I understand your point of view on the protocol. Thanks. > > 3. Even if the draft identified a single parent as the only source of min > > priority values for a node, there still would be a problem of value > > consistency. > > > Since the DODAG root can change its values of min priority and DODAG_Size and > > since a node can change its parents, there may still be a case when the node > > must decide whether to adopt the newly received values or not. Without a > > proper conflict resolution policy, it may be the case that when the root, for > > example, disables enrollment, then enables it again, then the DODAG may > > exhibit strange behaviors: the root's decision may not be propagated to all > > nodes, a decision may be revoked by nodes that have already accepted it, and > > the like. > > A root that did this, would have to increment the DTSN right each time it > changed it's mind. OK but: 1. This is not mentioned in the new version of the draft. 2. In non-storing mode, this would generate upward traffic from every member of a DODAG, which may be problematic. To explain, suppose that the MOP is indeed non-storing and that the root sets its min priority to 0x7f to disable enrollments because it is unable to handle any more traffic. According to your suggestion, doing this, the root increments its DTSN. Per point 1. of the ordered list in Sect. 9.6 or RFC 6550, every node seeing the incremented DTSN from its parent issues a DAO message upwards. Per point 2. of the same list, the node also increments its own DTSN. In effect, every node in the DODAG sends a DAO to the root, which may swamp the root---a situation that the root wanted to avoid in the first place by disabling enrollments. This situation may be even worse if DAO-Acks are to be sent in reply to the DAOs. 3. Even if the this approach were covered in the draft, it still has some issues, which I was about to explain but the new version of the draft appeared. > > There are many ways in which such conflict resolution can be provided. If I > > may suggest anything, I would recommend adding to the option a lollipop > > sequence counter (like those described in RFC 6550, sect. 7.2), let's call it > > osn. It would effectively order different versions of the option values > > produced by the DODAG root. In effect, whenever a node received an option (be > > it from a parent or another neighbor, depending on the way the previous > > issues are addressed), it would adopt the min priority and DODAG_Size values > > the option carries if and only if the osn value in the received option is > > greater than the node's locally stored osn. This would guarantee eventual > > consistency and avoid strange behaviors such as those mentioned above. > > I'm not convinced we need another lollipop counter. > I think that we already have that. I would say this need not be the best choice per: a) my reply above b) the fact that DTSN is conceptually for something else. >> > 4. Why put DODAG_Size in the option? >> >> > I can imagine that other services/protocols would like to use it as well, and >> > extracting this information from an option related solely to enrollment does >> > not seem the best idea. I have been thinking for some time about an option >> > for RPL that would provide some aggregate information about the DODAG to the >> > nodes, such as its size, max depth, and the like. The option could also be >> > used in the enrollment process. Do you think this makes sense? >> >> We agreed to merge two drafts. The DODAG_Size came from the other draft. >> We think that the two values are very much related and it made sense to send >> them together. OK, now I understand. However, this also generates some further issues I wanted to point in my reply to Rahul's and Pascal's comments. Best, -- - Konrad Iwanicki. From nobody Tue Aug 10 00:24:59 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 B1BD33A2B57; Tue, 10 Aug 2021 00:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.596 X-Spam-Level: X-Spam-Status: No, score=-9.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=bb737wkG; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=zg/DVWJm 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 9Y97InIu2BbU; Tue, 10 Aug 2021 00:24:52 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4CA23A2B5B; Tue, 10 Aug 2021 00:24:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9722; q=dns/txt; s=iport; t=1628580291; x=1629789891; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=bwDq+WRPzsFeNQA0FZsQEYGbDaKsD03F9yHHmrGantE=; b=bb737wkGu+JpMmar6+mTuvYOkDUYjieyok+MQcywwYszpSkiYpXYtQf+ QPxqWLkpeqwKuNrVd0EIFXaJCg7kSfHxHK2uz4wMxEJfIjkYFYnxzikbk w9hqT+401zGmOzLAEUQ3nYBCvMmSyRArCjGu/NY/iwsokMPzAUejxGTo4 s=; IronPort-PHdr: =?us-ascii?q?A9a23=3AIrxAeh3L5vimPjkismDPS1BlVkEcU/3cJQcT5?= =?us-ascii?q?pcjjrtINK+qrNzuP03asPNqilKBHYDW8OlNhOeetaf8EXcB7pCMvDFnEtRMW?= =?us-ascii?q?hYJhN9Qk1kmB8iIWlbyKvLnaykzGoJJXQwt83SyK0MAHsH4ahXbqWGz6jhHH?= =?us-ascii?q?BL5OEJ1K+35F5SUgd6w0rW5+obYZENDgz/uCY4=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3ACB1V1qBemzRPdcnlHej0sseALOsnbusQ8z?= =?us-ascii?q?AXPh9KKCC9I/b3qynxppsmPEfP+UkssHFJo6HmBEDyewKjyXcT2/hQAV7CZn?= =?us-ascii?q?imhILMFuFfBOTZskbd8kHFh4tgPOJbAtRD4b7LfBtHZKTBkXOF+r8bqbHtms?= =?us-ascii?q?3F9ISurUuFDzsaFp2IhD0JbDpzZ3cGPDWucqBJbaZ0iPA3wwaISDAyVICWF3?= =?us-ascii?q?MFV+/Mq5ngj5T9eyMLABYh9U2nkS6owKSSKWnb4j4uFxd0hZsy+2nMlAL0oo?= =?us-ascii?q?+5teug9xPa32jPq7xLhdrazMdZDsDksLlRFtyssHftWG1SYczFgNkHmpD31L?= =?us-ascii?q?/sqqiVn/4UBbU115oWRBDvnfKi4Xi77N9k0Q6S9bbRuwqSnSW+fkNmNyKE7r?= =?us-ascii?q?gpLScwLCEbzY1BOetwrhGknosSAhXakCvn4d/UExlsi0qvuHIn1fUelnpFTO?= =?us-ascii?q?IlGfJsRKEkjQho+a07bWjHAUEcYZ5TJdCZ4OwTfUKRbnjfsGUqyNuwXm4rFh?= =?us-ascii?q?PDRkQZoMSa3zVfgXg8liIjtYMit2ZF8Ih4R4hP5uzCPKgtnLZSTtUOZaY4AO?= =?us-ascii?q?saW8O4BmHEXBqJOmOPJlbsEr0BJhv22tLKyaRw4PvvdI0DzZM0lpiEWFREtX?= =?us-ascii?q?Qqc0arEsGK1I0jyGGEfIx8Z0Wl9ih63ek2hlTRfsufDcSzciFZryL7mYRsPi?= =?us-ascii?q?TyYYfGBK5r?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AzCwB4KRJh/5pdJa1aHgEBCxIMQIF?= =?us-ascii?q?OC4FTKSgHd1o3MYRHg0gDhTmIYwOPb4pGgUKBEQNUCwEBAQ0BASoLDAQBAYR?= =?us-ascii?q?YAheCSQIlNwYOAQIEAQEBEgEBBQEBAQIBBgSBEROFaA2GQgEBAQECAQEBEBE?= =?us-ascii?q?RDAEBJQcLAQQLAgEIGAICJgICAiULFRACBA4FIoJPAYJVAw4hAQ6cKQGBOgK?= =?us-ascii?q?KH3qBMYEBggcBAQYEBIJRgkEYgjQDBoEQKoJ8hA+GZCccgUlEgRUnDBBUgQ2?= =?us-ascii?q?BAT6CYgEBgSZRgwA2gi6DSgYBWAEOUyINLGoIDRAYER8FMRKRECKDRqghCoM?= =?us-ascii?q?okXaMVQUmpm+FObByhH8CBAIEBQIOAQEGgXYlgVlwFTsqAYI+UBkOi0eCWAw?= =?us-ascii?q?WgQMBBwIGB4I1hRSFSnM4AgYBCgEBAwmGMSqBP14BAQ?= X-IronPort-AV: E=Sophos;i="5.84,309,1620691200"; d="scan'208";a="825653603" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Aug 2021 07:24:43 +0000 Received: from mail.cisco.com (xbe-rcd-002.cisco.com [173.37.102.17]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 17A7OhQI026207 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Tue, 10 Aug 2021 07:24:43 GMT Received: from xfe-rcd-003.cisco.com (173.37.227.251) by xbe-rcd-002.cisco.com (173.37.102.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 10 Aug 2021 02:24:43 -0500 Received: from xfe-rcd-002.cisco.com (173.37.227.250) by xfe-rcd-003.cisco.com (173.37.227.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 10 Aug 2021 02:24:42 -0500 Received: from NAM02-DM3-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.15 via Frontend Transport; Tue, 10 Aug 2021 02:24:42 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WOBLwjVRn/hGm1sdthXmr3KYrLdxwhE3lq4341+l7F2i2Ypfyp73bhQPllONPV858F3s/UPCue0RSJ4PhpMOiFYM6b0CmOSxfEwitd0mylcqsZAfNgnU3CBmfOZboRzk+ky7SAcxUdILN/JGTs2A+Le8DYlJBFh9cK4YjR1Pf1b+MIvapCt8GjFb8vqT1PM7ToiX4Q6TqQgl8Ywmu5nopTeIiApsjQNUYbHKtvF811r1xtIHXlBp4yo0LW28IgMLcgmvlAEgxcgAa4D7iCGRRQVazX3rxbk3HbXFPx0OQE74P1KrgisJZnnh3RL1WW7I/bTaxwrVIQc1o7S0uf1rhg== 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=bwDq+WRPzsFeNQA0FZsQEYGbDaKsD03F9yHHmrGantE=; b=h0oxV7dbC+uiXPk7d2lnRbNqN1pmvaPNoqTRe5QOy5dNwzk9FVJVwARqKhlWJCoCdneci1Ht5gwRzrXnY7ToiVr+u8yFO0qCMSgT0cJciSIsdPwr+wAiZ6nBSmeFwGJ2loNIB4d8iD8GQs9/V+hU9r5qbFKNJ0v6ZIQfJcF6XO3x5LY6/l+eHrGP0Q1zFjTUc2IFZu39Jp9tHl1lVmH/OwpFlnPMLLqXJZZ2MdIID4PvVTEQ29DRUlKC2bkk/Q1m4uC1Hlz4ikNrfLbIpCPMMeB2KX5wd6csRBv4seAJaHNBcxsvvRq2mt+skjWzg6YWrIcbEuxoul5oqP7MjN64Kw== 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=bwDq+WRPzsFeNQA0FZsQEYGbDaKsD03F9yHHmrGantE=; b=zg/DVWJmEji/qY3+UhBJpfdOHKmUcxRkaC57XoDMzAaayZmM/zP/30x7VgD3B3KNuCSrYihyjN25N8cuG5yORP0iiwfLV4lz4hv9nSLe5BoqYueDIMQ2Q4J6q/FhpI7aA266get20BL3elCaoqbqWDQ5IZJ0GGfS1/wNUUoAcQY= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MWHPR11MB1326.namprd11.prod.outlook.com (2603:10b6:300:21::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.17; Tue, 10 Aug 2021 07:24:40 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::487e:47b8:314f:189a]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::487e:47b8:314f:189a%6]) with mapi id 15.20.4394.023; Tue, 10 Aug 2021 07:24:40 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks CC: Michael Richardson , "roll-chairs@ietf.org" Thread-Topic: [Roll] Review of draft-ietf-roll-enrollment-priority-04 Thread-Index: AQHXiW/D5aIXC0jIjUWmxkQskylezqtri3cAgAAnYYCAAKvYRg== Date: Tue, 10 Aug 2021 07:24:40 +0000 Message-ID: <9A1DA017-AF66-4349-B070-57A4BC28A48A@cisco.com> References: <26245.1628534920@localhost>, In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 92e97ab6-71d9-4eff-7388-08d95bcfeafe x-ms-traffictypediagnostic: MWHPR11MB1326: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 9K5fVZjBIzF+/OvXwhmwYGk3MRj5fEy/rQCVc2m7FzsAWSxobdK5v3LkWVtMxwiKyg/ZrsrAVd10ZGlD5flrFPYRW59/qT/WUBYF1V9G87lpJQAUavGtF0MmpCrabSFbn0dAUooTNSoemGuTxSa1fI6SQlaoxy6FCkWF3KDMQ68OJ+8Z+CA8J5knjeioGMtmGtnAcrnDeBh+ECjeF0ilGpfa32xN2yvEYtYIO06zT63MJ/31zplm7wxzN/CYhacquHKWECYflqZsoiaiNI+oPCoZjTc/Mstos8Y7FPc7+ppOaoEpVTck2HUnman1in6731k0wtr1zDBrBwlwFAWy/k4v/jfMZTbeRKywJMSDqPP5g3XDqMM/pTESDvIhPFOoAUeOCHTVytasI8hjRLcXPh0e+2jjRifJTUdADOi5TDNEMMsfSzw3lRzjNUvKnieo0ds5hHpgH/22hHfb6UjL9GRWI6JO/6JVj6yA6ScgpieN8iawfOqMbkd2uijQ0ZvoGtVsw+K7w85MgoriOGZTqx4xR4tdUH6mmkc3kTUqnkD5V/sdELkLxP0X3KixcY19nkBsYKQ1VuVucXLYMdwsBMawZUov6CuH8j4a+CU6oXFnVitiRNnjr7qD0MsVigW/sS/4uyASIrb3VDP/FOeTxsScOLlAC3EvVjcLixApdXQdgMLZ2IZ0i3bnBhTdPaVvSZ5e2GPgQPbK1XAQ6/iyj21mtZak5i56BmAJyyDFEd6KK/yk5viV2F67oyI6C2Ii3ROkQ3ysZ3gLeYQ25+Mk+xatqauVmsodgVeZeyZ4+Oo3val3OheP3l+B2UjG5YVE 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)(376002)(366004)(136003)(396003)(346002)(66476007)(66556008)(66446008)(64756008)(54906003)(6916009)(91956017)(76116006)(316002)(966005)(71200400001)(2906002)(6486002)(66946007)(8676002)(38070700005)(86362001)(6512007)(8936002)(36756003)(66574015)(4326008)(5660300002)(186003)(2616005)(478600001)(6506007)(38100700002)(122000001)(33656002)(83380400001)(53546011)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?YVdybkZ1TTFLM2I3NVpGTVhYNG9jK0huMnBGd1VLSzRmeHZ3NkxuMzJwRGl6?= =?utf-8?B?QU5ySFNQaU1kcHI3Z0Zud2s2VU94ZnBxSFEreE8zQ2QzaENhbnNoME9RZ1BN?= =?utf-8?B?RGZQeEg2bVR3RHUvM1NzVUp6ajBudnVFaW1DZWpkendYY1BzR1c5a1kvaWgz?= =?utf-8?B?NnJER3ZQT1hyOTFaUWl4TUF3dFBGYnlsRGZ1cTBxQUQvakRmRG5HUVFhZkp2?= =?utf-8?B?Q1BmcG9BTld4VHNKZzRqQjVvL2huQldGYlptMWdudlZ3UkNQUEp2ZDQzblMy?= =?utf-8?B?SzZWTWIwdHVkZk9ucUM0RGhhOHpZcG4ydUlNVEsyYzRLdSt5TWxhV1psWFMz?= =?utf-8?B?R0c4a0ZDYU90NTRmZTVNY0V4WmhsSnFkUTlKYmZNSk1EclhHUndPbFRIUjBy?= =?utf-8?B?V28rMlFNRFd2anE5NGdGaHB0VXNJR1plbTJTZlkrNlBCOVRialJHcXhOZU1R?= =?utf-8?B?VnVuVGVjNTBldEJtZ3FlOXgwNkJqUWxhanl2UEVLd21HSituZ3dQY2dlcjd0?= =?utf-8?B?MjcwSTF4ZSs5dlIreGgxWCtPTnB0SkxzSHQvbWRoRkd0K3Zab1VWNGhBU0ZS?= =?utf-8?B?RjJGN0JxdnpFRENtbUMxQ0tFNUl0OTE3VE83N2ZSeDRnNDNzWTl4dTJQZFZo?= =?utf-8?B?SVNZYkNoN01JOTVDVVFUbngzdjM0SDYzb1RxT1h2azdneHJJeVJrTE05eXRK?= =?utf-8?B?UXBhS2I5Qld0MzFWRGxmVW9GQ2svZEt4Zm92c0Q3bEsxKzZsempsTW8yL0Rt?= =?utf-8?B?dlcxQnIzNDA1U3dIeFo4cVN2OGNvOWkwOUFndE9KUGc5SFpZbFhMK0lHWXRK?= =?utf-8?B?dkZmSmNkTE9XVU16UklYZG1naXNDSFhuOUhzNjlHYVhFZS9uZlhwc0tNSEJR?= =?utf-8?B?cmxXemhPVlhod2FmakZkRGFVYjdsQmtyTzZ3RGJFaHNvcWNPT2x0N2dBdkJi?= =?utf-8?B?M205QWtXNG1QbGhNVzlqUGVEbTUva1Q1Si9NVkxVNlYwZXFjS245SmV2dVcw?= =?utf-8?B?TnBrVk5JWEZ2d3VzMTA4VVJSSWpjaWovNmo4bTFmYm5oL2RrRTA2WGQ0N0dS?= =?utf-8?B?MDFmOHZMQjZmcVI3dEltRzgzRGorSXlaQWlNdUwzaEF1dzUzNEhLUTMzRmhv?= =?utf-8?B?ZTNNUysrQkJmWHJuZkFIVW5hM05FMkhmQTNRL2lRWlRRdVloYjM0WUlqaXhP?= =?utf-8?B?bjQxMytiT3NTM29HcXUvOTBidUx0SkFPbkpJRzZyS0RWdkZRWkJZWU9Ld3hw?= =?utf-8?B?R09YWjBwTjlLaFBmNmlCMXhxWmVXdG5RalZTOW1KMzlROWtUalYwaU1Mci9Q?= =?utf-8?B?MWZFK3BjSDIydFNzM1FoRjZtbjd6aGdoWEx1R00vRys2aVljajlMaW0rUW1Y?= =?utf-8?B?N2RBZ2hJNnJmNmJ0OXhpWXVUSy95cC9uWml4cjFNMmhNOXZNZFplb2hMYlZW?= =?utf-8?B?MzR6UGY5c200dXhaekFZOXNIZmkvOXdISEMvZDBjZWxPR0FLbnhycGpFL2xL?= =?utf-8?B?TmRnR2FpMnRLb0RsbFAwWkR2T0FiM0l1Y3JYcVcvcDFQUGZpRW9JTkMyb1lw?= =?utf-8?B?VVJrNXJWcDkxaXVyeDh0ckdZTCtHS2N4MEZwd2Y2U3MzSlhweEhJN2I2RHdn?= =?utf-8?B?dG10L1lzYmw4R0NyVlhkZ2ZTbkRsOU5WeU9ZdHpnSXlpWlRpemdDQzE4RTdL?= =?utf-8?B?NEhwcG9BWFB5WTNHNXpxMmlVYjNCR0JkVnRGZmFZeXlEbTM3RXcrZVNDTjdE?= =?utf-8?B?ZklJNnMzQTRBMTh5OXZqYjBaTjZxMWEraVdkRlM1K1JhZzFHbnVHcGtwU0pk?= =?utf-8?B?OVBiRHc1NUN6YWhjRFRkbEhOUkdzZ2pLQzVRUGtiV2hXOHIrb3pvVmtVL1hC?= =?utf-8?Q?GNnG/ztswh5eq?= 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: 92e97ab6-71d9-4eff-7388-08d95bcfeafe X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Aug 2021 07:24:40.7422 (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: rb2DaAxPq0od/md7hpqxdz8pcw5o6fYtJ/fZkWsMjiQkR8Kckq340Dxu7pWyPXYoOKe+nA/c/B7FC2Gk/IKhdw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1326 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.17, xbe-rcd-002.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [Roll] Review of draft-ietf-roll-enrollment-priority-04 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, 10 Aug 2021 07:24:58 -0000 DQoNCj4gTGUgOSBhb8O7dCAyMDIxIMOgIDIzOjEwLCBLb25yYWQgSXdhbmlja2kgPGl3YW5pY2tp QG1pbXV3LmVkdS5wbD4gYSDDqWNyaXQgOg0KPiANCj4g77u/RGVhciBNaWNoYWVsIGFuZCBhbGws DQo+IA0KPiBGaXJzdCBvZiBhbGwsIHRoYW5rIHlvdSBmb3IgeW91ciBraW5kIHdvcmRzIHJlZ2Fy ZGluZyB0aGUgcmV2aWV3LiBJIGFtIGFjdHVhbGx5IHBsYW5uaW5nIHRvIGF0dGVuZCB0aGUgQXVn dXN0IGludGVyaW0sIGJlY2F1c2UgSSB3aWxsIGJlIHByZXNlbnRpbmcgdGhlIHJuZmQgZHJhZnQs IHNvIHdlIGNhbiBkaXNjdXNzIHRoZSBlbnJvbGxtZW50IHByaW9yaXR5IGRyYWZ0IGluIGRlcHRo IGFzIHdlbGwuDQo+IA0KPiBCZWxvdyBJIGp1c3QgcXVpY2tseSByZXBseSBpbmxpbmUgdG8gTWlj aGFlbCdzIGNvbW1lbnRzIGFzIHRoZXkgbGVkIHRvIGEgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0 LiBJIHdhcyBhY3R1YWxseSByZXBseWluZyB0byBQYXNjYWwncyBhbmQgUmFodWwncyBjb21tZW50 cyB3aGlsZSB0aGUgbmV3IGRyYWZ0IHZlcnNpb24gYXBwZWFyZWQsIGFuZCB0aGUgbmV3IHZlcnNp b24gc3RpbGwgaGFzIHNvbWUgaXNzdWVzLCB3aGljaCBJIHdhbnRlZCB0byBwb2ludCBvdXQgaW4g dGhvc2UgcmVwbGllcy4NCj4gDQo+IFNvIHdoYXQgZG8gSSBkbyB0aGVuLCB3cml0ZSBhbm90aGVy IHJldmlldyBmb3IgdGhlIG5ldyB2ZXJzaW9uIHdoZXJlIEkgY2FuIGV4cGxhaW4gdGhvc2UgaXNz dWVzPw0KPiANCj4+IE9uIDA5LzA4LzIwMjEgMjA6NDgsIE1pY2hhZWwgUmljaGFyZHNvbiB3cm90 ZToNCj4+ICAgICA+IEluIGNvbnRyYXN0LCBSRkMgNjU1MCwgc2VjdC4gOC4yLjMgc3RhdGVzIHRo YXQgRElPcyBub3Qgb25seSBmcm9tIHBhcmVudHMgYnV0DQo+PiAgICAgPiBhbHNvIG90aGVyIG5l aWdoYm9ycyBtdXN0IGJlIHByb2Nlc3NlZCBieSBhIG5vZGUuIFRoaXMgZ3VhcmFudGVlcyBjb3Jy ZWN0DQo+PiAgICAgPiByb3V0ZSBmb3JtYXRpb24gYW5kIG1haW50ZW5hbmNlLg0KPj4gWWVzLCBp dCdzIHRydWUuICBBIG5vZGUgc2hvdWxkIGV2YWx1YXRlIERJT3MgZnJvbSBvdGhlciBzb3VyY2Vz LCBhbmQgaWYgdGhvc2UNCj4+IHNvdXJjZXMgYXJlIGJldHRlciwgdGhlbiBpdCBzaG91bGQgc3dp dGNoIHBhcmVudHMuICBCdXQgYXQgYW55IHBvaW50LCBhIG5vZGUNCj4+IHJlYWxseSBoYXMgb25s eSBvbmUgcGFyZW50Lg0KPj4gVGhlIG90aGVyIG5vZGVzIGFyZSBwb3RlbnRpYWwgcGFyZW50cywg YnV0IG5vdCBwYXJlbnRzLg0KPj4gUGVyaGFwcyBSRkM2NTUwIGhhcyBzb21lIG90aGVyIHRlcm1z IHdoaWNoIEkndmUgbmVnbGVjdGVkIHRvIHVzZS4NCj4gDQo+IEkgYmVsaWV2ZSBSRkMgNjU1MCB1 c2VzIHRlcm0gInBhcmVudCIgZm9yIGFueSBuZWlnaGJvciB3aXRoIGEgcmFuayBsb3dlciB0aGFu IHRoZSBub2RlIGl0c2VsZiBhbmQgInByZWZlcnJlZCBwYXJlbnQiIGZvciB0aGUgcGFyZW50IChj b25jZXB0dWFsbHkgYSBzaW5nbGUgb25lKSB0aGF0IHRoZSBub2RlIHVzZXMgYXMgdGhlIG5leHQg aG9wIG9uIGl0cyB1cHdhcmQgcm91dGVzLiBUaGlzIG1heSBiZSBvbmUgb2YgdGhlIHNvdXJjZXMg b2YgbXkgY29uZnVzaW9uLiBBZnRlciB5b3VyIGV4cGxhbmF0aW9uLCBJIHVuZGVyc3RhbmQgeW91 ciBwb2ludCBvZiB2aWV3IG9uIHRoZSBwcm90b2NvbC4gVGhhbmtzLg0KPiANCj4+ICAgICA+IDMu IEV2ZW4gaWYgdGhlIGRyYWZ0IGlkZW50aWZpZWQgYSBzaW5nbGUgcGFyZW50IGFzIHRoZSBvbmx5 IHNvdXJjZSBvZiBtaW4NCj4+ICAgICA+IHByaW9yaXR5IHZhbHVlcyBmb3IgYSBub2RlLCB0aGVy ZSBzdGlsbCB3b3VsZCBiZSBhIHByb2JsZW0gb2YgdmFsdWUNCj4+ICAgICA+IGNvbnNpc3RlbmN5 Lg0KPj4gICAgID4gU2luY2UgdGhlIERPREFHIHJvb3QgY2FuIGNoYW5nZSBpdHMgdmFsdWVzIG9m IG1pbiBwcmlvcml0eSBhbmQgRE9EQUdfU2l6ZSBhbmQNCj4+ICAgICA+IHNpbmNlIGEgbm9kZSBj YW4gY2hhbmdlIGl0cyBwYXJlbnRzLCB0aGVyZSBtYXkgc3RpbGwgYmUgYSBjYXNlIHdoZW4gdGhl IG5vZGUNCj4+ICAgICA+IG11c3QgZGVjaWRlIHdoZXRoZXIgdG8gYWRvcHQgdGhlIG5ld2x5IHJl Y2VpdmVkIHZhbHVlcyBvciBub3QuIFdpdGhvdXQgYQ0KPj4gICAgID4gcHJvcGVyIGNvbmZsaWN0 IHJlc29sdXRpb24gcG9saWN5LCBpdCBtYXkgYmUgdGhlIGNhc2UgdGhhdCB3aGVuIHRoZSByb290 LCBmb3INCj4+ICAgICA+IGV4YW1wbGUsIGRpc2FibGVzIGVucm9sbG1lbnQsIHRoZW4gZW5hYmxl cyBpdCBhZ2FpbiwgdGhlbiB0aGUgRE9EQUcgbWF5DQo+PiAgICAgPiBleGhpYml0IHN0cmFuZ2Ug YmVoYXZpb3JzOiB0aGUgcm9vdCdzIGRlY2lzaW9uIG1heSBub3QgYmUgcHJvcGFnYXRlZCB0byBh bGwNCj4+ICAgICA+IG5vZGVzLCBhIGRlY2lzaW9uIG1heSBiZSByZXZva2VkIGJ5IG5vZGVzIHRo YXQgaGF2ZSBhbHJlYWR5IGFjY2VwdGVkIGl0LCBhbmQNCj4+ICAgICA+IHRoZSBsaWtlLg0KPj4g QSByb290IHRoYXQgZGlkIHRoaXMsIHdvdWxkIGhhdmUgdG8NCj4+IGluY3JlbWVudCB0aGUgRFRT TiByaWdodCBlYWNoIHRpbWUgaXQNCj4+IGNoYW5nZWQgaXQncyBtaW5kLg0KPiANCj4gT0sgYnV0 Og0KPiANCg0KQWN0dWFsbHkgbm90IE9LIA0KDQpUaGUgRFRTTiB0cmlnZ2VycyBEQU8gbWVzc2Fn ZXM7IHRoaXMgc2VlbXMgdW5yZWxhdGVkIGFuZCB1bmRlc2lyYWJsZS4gDQoNCk1heWJlIHRoZSBz dWdnZXN0aW9uIHdhcyByZWFsbHkgdG8gcmVzeW5jIHRoZSBEQUcgdG8gYSBuZXcgdmVyc2lvbiB0 aGF0IHdvdWxkIG9wZXJhdGUgd2l0aCB0aGUgbmV3IG1pbmltdW0/DQoNClRoYXTigJlzIGFjdHVh bGx5IG5vdCBhIGNvbnZpbmNpbmcgaWRlYSBlaXRoZXIsIHNpbmNlIHRoZSBtaW5pbXVtIHZhbHVl IG9mIHByaW9yaXR5IGlzIG5vdCBjb25maWd1cmVkIGJ1dCBhIER5bmFtaWMgY29tcHV0YXRpb24g dGhhdCBtYXkgY2hhbmdlIGEgbG90IG1vc3RseSBkdXJpbmcgdGhlIERPREFHIGZvcm1hdGlvbi4N Cg0KDQo+IDEuIFRoaXMgaXMgbm90IG1lbnRpb25lZCBpbiB0aGUgbmV3IHZlcnNpb24gb2YgdGhl IGRyYWZ0Lg0KPiAyLiBJbiBub24tc3RvcmluZyBtb2RlLCB0aGlzIHdvdWxkIGdlbmVyYXRlIHVw d2FyZCB0cmFmZmljIGZyb20gZXZlcnkgbWVtYmVyIG9mIGEgRE9EQUcsIHdoaWNoIG1heSBiZSBw cm9ibGVtYXRpYy4gVG8gZXhwbGFpbiwgc3VwcG9zZSB0aGF0IHRoZSBNT1AgaXMgaW5kZWVkIG5v bi1zdG9yaW5nIGFuZCB0aGF0IHRoZSByb290IHNldHMgaXRzIG1pbiBwcmlvcml0eSB0byAweDdm IHRvIGRpc2FibGUgZW5yb2xsbWVudHMgYmVjYXVzZSBpdCBpcyB1bmFibGUgdG8gaGFuZGxlIGFu eSBtb3JlIHRyYWZmaWMuIEFjY29yZGluZyB0byB5b3VyIHN1Z2dlc3Rpb24sIGRvaW5nIHRoaXMs IHRoZSByb290IGluY3JlbWVudHMgaXRzIERUU04uIFBlciBwb2ludCAxLiBvZiB0aGUgb3JkZXJl ZCBsaXN0IGluIFNlY3QuIDkuNiBvciBSRkMgNjU1MCwgZXZlcnkgbm9kZSBzZWVpbmcgdGhlIGlu Y3JlbWVudGVkIERUU04gZnJvbSBpdHMgcGFyZW50IGlzc3VlcyBhIERBTyBtZXNzYWdlIHVwd2Fy ZHMuIFBlciBwb2ludCAyLiBvZiB0aGUgc2FtZSBsaXN0LCB0aGUgbm9kZSBhbHNvIGluY3JlbWVu dHMgaXRzIG93biBEVFNOLiBJbiBlZmZlY3QsIGV2ZXJ5IG5vZGUgaW4gdGhlIERPREFHIHNlbmRz IGEgREFPIHRvIHRoZSByb290LCB3aGljaCBtYXkgc3dhbXAgdGhlIHJvb3QtLS1hIHNpdHVhdGlv biB0aGF0IHRoZSByb290IHdhbnRlZCB0byBhdm9pZCBpbiB0aGUgZmlyc3QgcGxhY2UgYnkgZGlz YWJsaW5nIGVucm9sbG1lbnRzLiBUaGlzIHNpdHVhdGlvbiBtYXkgYmUgZXZlbiB3b3JzZSBpZiBE QU8tQWNrcyBhcmUgdG8gYmUgc2VudCBpbiByZXBseSB0byB0aGUgREFPcy4NCj4gDQpUcnVlIA0K SXTigJlzIG5vdCAganVzdCBub24gc3RvcmluZyBpdOKAmXMgYWxsIG1vZGVzDQoNCg0KPiAzLiBF dmVuIGlmIHRoZSB0aGlzIGFwcHJvYWNoIHdlcmUgY292ZXJlZCBpbiB0aGUgZHJhZnQsIGl0IHN0 aWxsIGhhcyBzb21lIGlzc3Vlcywgd2hpY2ggSSB3YXMgYWJvdXQgdG8gZXhwbGFpbiBidXQgdGhl IG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdCBhcHBlYXJlZC4NCj4gDQpZZXMgd2UgbmVlZCB0byBz eW5jLiBJIHRoaW5rIE1pY2hhZWwgc3RpbGwgaGFzIGluIG1pbmQgdGhhdCB0aGUgbWluaW11bSBp cyBpbmNyZW1lbnRlZCBkb3duLiBUaGF0IHdhcyB0aGUgaW5pdGlhbCBpZGVhLiANCg0KQnV0IHRo YXTigJlzIGNyZWF0aW5nIG1vcmUgcHJvYmxlbXMgdGhhdCBoZWxwIG1vc3RseSBkdWUgdG8gdGhl IGRvZGFnIHN0cnVjdHVyZSBhbmQgY3V0IHRoZSBjYXBhYmlsaXR5IGZvciB0aGUgcm9vdCB0byBn aXZlIGEgZGlyZWN0IGZlZWRiYWNrIHRvIHRoZSBub2Rlcy4gSSBub3cgdGhpbmsgdGhpcyBpbmZv cm1hdGlvbiBzaG91bGQgYmUgc2V0IGJ5IHRoZSByb290IGFuZCByZW1haW4gdGhyb3VnaG91dCB0 aGUgZG9kYWcuDQoNClRvIGJlIGRpc2N1c3NlZCBhdCB0aGUgbmV4dCBpbnRlcmlt4oCmDQoNCg0K Pj4gICAgID4gVGhlcmUgYXJlIG1hbnkgd2F5cyBpbiB3aGljaCBzdWNoIGNvbmZsaWN0IHJlc29s dXRpb24gY2FuIGJlIHByb3ZpZGVkLiBJZiBJDQo+PiAgICAgPiBtYXkgc3VnZ2VzdCBhbnl0aGlu ZywgSSB3b3VsZCByZWNvbW1lbmQgYWRkaW5nIHRvIHRoZSBvcHRpb24gYSBsb2xsaXBvcA0KPj4g ICAgID4gc2VxdWVuY2UgY291bnRlciAobGlrZSB0aG9zZSBkZXNjcmliZWQgaW4gUkZDIDY1NTAs IHNlY3QuIDcuMiksIGxldCdzIGNhbGwgaXQNCj4+ICAgICA+IG9zbi4gSXQgd291bGQgZWZmZWN0 aXZlbHkgb3JkZXIgZGlmZmVyZW50IHZlcnNpb25zIG9mIHRoZSBvcHRpb24gdmFsdWVzDQo+PiAg ICAgPiBwcm9kdWNlZCBieSB0aGUgRE9EQUcgcm9vdC4gSW4gZWZmZWN0LCB3aGVuZXZlciBhIG5v ZGUgcmVjZWl2ZWQgYW4gb3B0aW9uIChiZQ0KPj4gICAgID4gaXQgZnJvbSBhIHBhcmVudCBvciBh bm90aGVyIG5laWdoYm9yLCBkZXBlbmRpbmcgb24gdGhlIHdheSB0aGUgcHJldmlvdXMNCj4+ICAg ICA+IGlzc3VlcyBhcmUgYWRkcmVzc2VkKSwgaXQgd291bGQgYWRvcHQgdGhlIG1pbiBwcmlvcml0 eSBhbmQgRE9EQUdfU2l6ZSB2YWx1ZXMNCj4+ICAgICA+IHRoZSBvcHRpb24gY2FycmllcyBpZiBh bmQgb25seSBpZiB0aGUgb3NuIHZhbHVlIGluIHRoZSByZWNlaXZlZCBvcHRpb24gaXMNCj4+ICAg ICA+IGdyZWF0ZXIgdGhhbiB0aGUgbm9kZSdzIGxvY2FsbHkgc3RvcmVkIG9zbi4gVGhpcyB3b3Vs ZCBndWFyYW50ZWUgZXZlbnR1YWwNCj4+ICAgICA+IGNvbnNpc3RlbmN5IGFuZCBhdm9pZCBzdHJh bmdlIGJlaGF2aW9ycyBzdWNoIGFzIHRob3NlIG1lbnRpb25lZCBhYm92ZS4NCj4+IEknbSBub3Qg Y29udmluY2VkIHdlIG5lZWQgYW5vdGhlciBsb2xsaXBvcCBjb3VudGVyLg0KPj4gSSB0aGluayB0 aGF0IHdlIGFscmVhZHkgaGF2ZSB0aGF0Lg0KPiANCj4gSSB3b3VsZCBzYXkgdGhpcyBuZWVkIG5v dCBiZSB0aGUgYmVzdCBjaG9pY2UgcGVyOg0KPiANCj4gYSkgbXkgcmVwbHkgYWJvdmUNCj4gDQo+ IGIpIHRoZSBmYWN0IHRoYXQgRFRTTiBpcyBjb25jZXB0dWFsbHkgZm9yIHNvbWV0aGluZyBlbHNl Lg0KDQpBbmQgbXkgZHJhZnQgb24gdmVyc2lvbmluZyB0aGUgY29uZmlndXJhdGlvbiBpcyBhbHNv IHNvbWV0aGluZyBlbHNlLiBXZSBuZWVkIGEgbmV3IHNlcXVlbmNlIGVpdGhlciBpbiB0aGlzIG9w dGlvbiBvciBnbG9iYWwgdG8gYWxsIGZ1dHVyZSBzdGF0dXMgb3B0aW9ucyBmcm9tIHRoZSByb290 LiBUaGF0IHNlcXVlbmNlIHdvdWxkIG5vdCBhbHRlciB0aGUgUlBMIG9wZXJhdGlvbiBhcyB2ZXJz aW9uIGFuZCBEVFNOIGRvLg0KDQo+IA0KPj4+ICAgICA+IDQuIFdoeSBwdXQgRE9EQUdfU2l6ZSBp biB0aGUgb3B0aW9uPw0KPj4+ICAgICA+IEkgY2FuIGltYWdpbmUgdGhhdCBvdGhlciBzZXJ2aWNl cy9wcm90b2NvbHMgd291bGQgbGlrZSB0byB1c2UgaXQgYXMgd2VsbCwgYW5kDQo+Pj4gICAgID4g ZXh0cmFjdGluZyB0aGlzIGluZm9ybWF0aW9uIGZyb20gYW4gb3B0aW9uIHJlbGF0ZWQgc29sZWx5 IHRvIGVucm9sbG1lbnQgZG9lcw0KPj4+ICAgICA+IG5vdCBzZWVtIHRoZSBiZXN0IGlkZWEuIEkg aGF2ZSBiZWVuIHRoaW5raW5nIGZvciBzb21lIHRpbWUgYWJvdXQgYW4gb3B0aW9uDQo+Pj4gICAg ID4gZm9yIFJQTCB0aGF0IHdvdWxkIHByb3ZpZGUgc29tZSBhZ2dyZWdhdGUgaW5mb3JtYXRpb24g YWJvdXQgdGhlIERPREFHIHRvIHRoZQ0KPj4+ICAgICA+IG5vZGVzLCBzdWNoIGFzIGl0cyBzaXpl LCBtYXggZGVwdGgsIGFuZCB0aGUgbGlrZS4gVGhlIG9wdGlvbiBjb3VsZCBhbHNvIGJlDQo+Pj4g ICAgID4gdXNlZCBpbiB0aGUgZW5yb2xsbWVudCBwcm9jZXNzLiBEbyB5b3UgdGhpbmsgdGhpcyBt YWtlcyBzZW5zZT8NCj4+PiBXZSBhZ3JlZWQgdG8gbWVyZ2UgdHdvIGRyYWZ0cy4gIFRoZSBET0RB R19TaXplIGNhbWUgZnJvbSB0aGUgb3RoZXIgZHJhZnQuDQo+Pj4gV2UgdGhpbmsgdGhhdCB0aGUg dHdvIHZhbHVlcyBhcmUgdmVyeSBtdWNoIHJlbGF0ZWQgYW5kIGl0IG1hZGUgc2Vuc2UgdG8gc2Vu ZA0KPj4+IHRoZW0gdG9nZXRoZXIuDQo+IA0KPiBPSywgbm93IEkgdW5kZXJzdGFuZC4gSG93ZXZl ciwgdGhpcyBhbHNvIGdlbmVyYXRlcyBzb21lIGZ1cnRoZXIgaXNzdWVzIEkgd2FudGVkIHRvIHBv aW50IGluIG15IHJlcGx5IHRvIFJhaHVsJ3MgYW5kIFBhc2NhbCdzIGNvbW1lbnRzLg0KDQpMb29r aW5nIGZvcndhcmQuIFRoYW5rcyBhIGJ1bmNoIEtvbnJhZCBmb3Igb3BlbmluZyB0aGUgZGlzY3Vz c2lvbiBvbiB0aGUgZHJhZnQuIFRoaXMgaXMgaW5jcmVkaWJseSBoZWxwZnVsIQ0KDQpZb3UgYWxs IGtlZXAgc2FmZSwNCg0KUGFzY2FsIA0KDQo+IA0KPiBCZXN0LA0KPiAtLSANCj4gLSBLb25yYWQg SXdhbmlja2kuDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBSb2xsIG1haWxpbmcgbGlzdA0KPiBSb2xsQGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0K From nobody Tue Aug 10 02:01: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 3BDA13A095E; Tue, 10 Aug 2021 02:01:35 -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 xMhG447VlG3b; Tue, 10 Aug 2021 02:01:30 -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 AE31B3A095F; Tue, 10 Aug 2021 02:01:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by duch.mimuw.edu.pl (Postfix) with ESMTP id D4A25600ADAF6; Tue, 10 Aug 2021 11:01:21 +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 raKgOk0ilpYB; Tue, 10 Aug 2021 11:01:17 +0200 (CEST) Received: from [IPv6:2001:6a0:5001:2:8560:597b:1bae:ea9c] (unknown [IPv6:2001:6a0:5001:2:8560:597b:1bae:ea9c]) (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, 10 Aug 2021 11:01:14 +0200 (CEST) To: Routing Over Low power and Lossy networks References: <26245.1628534920@localhost> <9A1DA017-AF66-4349-B070-57A4BC28A48A@cisco.com> Cc: "roll-chairs@ietf.org" , Michael Richardson , "Pascal Thubert (pthubert)" From: Konrad Iwanicki Message-ID: <91409cc4-1adb-dffb-c5a5-a3aa65d94a95@mimuw.edu.pl> Date: Tue, 10 Aug 2021 11:01:29 +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: <9A1DA017-AF66-4349-B070-57A4BC28A48A@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Roll] Review of draft-ietf-roll-enrollment-priority-04 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, 10 Aug 2021 09:01:36 -0000 Hi Pascal and all, Thanks for the comments. Now I have a full picture of how each of you envision the protocol. Before the interim, I will try up to write up all my remarks regarding these ideas and the issues I mentioned throughout my last reply, so that hopefully we have some starting point for discussion. I will probably close the thread at this point and post an e-mail as a review of version 05. Best, -- - Konrad Iwanicki. On 10.08.2021 09:24, Pascal Thubert (pthubert) wrote: > > >> Le 9 août 2021 à 23:10, Konrad Iwanicki a écrit : >> >> Dear Michael and all, >> >> First of all, thank you for your kind words regarding the review. I am actually planning to attend the August interim, because I will be presenting the rnfd draft, so we can discuss the enrollment priority draft in depth as well. >> >> Below I just quickly reply inline to Michael's comments as they led to a new version of the draft. I was actually replying to Pascal's and Rahul's comments while the new draft version appeared, and the new version still has some issues, which I wanted to point out in those replies. >> >> So what do I do then, write another review for the new version where I can explain those issues? >> >>> On 09/08/2021 20:48, Michael Richardson wrote: >>> > In contrast, RFC 6550, sect. 8.2.3 states that DIOs not only from parents but >>> > also other neighbors must be processed by a node. This guarantees correct >>> > route formation and maintenance. >>> Yes, it's true. A node should evaluate DIOs from other sources, and if those >>> sources are better, then it should switch parents. But at any point, a node >>> really has only one parent. >>> The other nodes are potential parents, but not parents. >>> Perhaps RFC6550 has some other terms which I've neglected to use. >> >> I believe RFC 6550 uses term "parent" for any neighbor with a rank lower than the node itself and "preferred parent" for the parent (conceptually a single one) that the node uses as the next hop on its upward routes. This may be one of the sources of my confusion. After your explanation, I understand your point of view on the protocol. Thanks. >> >>> > 3. Even if the draft identified a single parent as the only source of min >>> > priority values for a node, there still would be a problem of value >>> > consistency. >>> > Since the DODAG root can change its values of min priority and DODAG_Size and >>> > since a node can change its parents, there may still be a case when the node >>> > must decide whether to adopt the newly received values or not. Without a >>> > proper conflict resolution policy, it may be the case that when the root, for >>> > example, disables enrollment, then enables it again, then the DODAG may >>> > exhibit strange behaviors: the root's decision may not be propagated to all >>> > nodes, a decision may be revoked by nodes that have already accepted it, and >>> > the like. >>> A root that did this, would have to >>> increment the DTSN right each time it >>> changed it's mind. >> >> OK but: >> > > Actually not OK > > The DTSN triggers DAO messages; this seems unrelated and undesirable. > > Maybe the suggestion was really to resync the DAG to a new version that would operate with the new minimum? > > That’s actually not a convincing idea either, since the minimum value of priority is not configured but a Dynamic computation that may change a lot mostly during the DODAG formation. > > >> 1. This is not mentioned in the new version of the draft. >> 2. In non-storing mode, this would generate upward traffic from every member of a DODAG, which may be problematic. To explain, suppose that the MOP is indeed non-storing and that the root sets its min priority to 0x7f to disable enrollments because it is unable to handle any more traffic. According to your suggestion, doing this, the root increments its DTSN. Per point 1. of the ordered list in Sect. 9.6 or RFC 6550, every node seeing the incremented DTSN from its parent issues a DAO message upwards. Per point 2. of the same list, the node also increments its own DTSN. In effect, every node in the DODAG sends a DAO to the root, which may swamp the root---a situation that the root wanted to avoid in the first place by disabling enrollments. This situation may be even worse if DAO-Acks are to be sent in reply to the DAOs. >> > True > It’s not just non storing it’s all modes > > >> 3. Even if the this approach were covered in the draft, it still has some issues, which I was about to explain but the new version of the draft appeared. >> > Yes we need to sync. I think Michael still has in mind that the minimum is incremented down. That was the initial idea. > > But that’s creating more problems that help mostly due to the dodag structure and cut the capability for the root to give a direct feedback to the nodes. I now think this information should be set by the root and remain throughout the dodag. > > To be discussed at the next interim… > > >>> > There are many ways in which such conflict resolution can be provided. If I >>> > may suggest anything, I would recommend adding to the option a lollipop >>> > sequence counter (like those described in RFC 6550, sect. 7.2), let's call it >>> > osn. It would effectively order different versions of the option values >>> > produced by the DODAG root. In effect, whenever a node received an option (be >>> > it from a parent or another neighbor, depending on the way the previous >>> > issues are addressed), it would adopt the min priority and DODAG_Size values >>> > the option carries if and only if the osn value in the received option is >>> > greater than the node's locally stored osn. This would guarantee eventual >>> > consistency and avoid strange behaviors such as those mentioned above. >>> I'm not convinced we need another lollipop counter. >>> I think that we already have that. >> >> I would say this need not be the best choice per: >> >> a) my reply above >> >> b) the fact that DTSN is conceptually for something else. > > And my draft on versioning the configuration is also something else. We need a new sequence either in this option or global to all future status options from the root. That sequence would not alter the RPL operation as version and DTSN do. > >> >>>> > 4. Why put DODAG_Size in the option? >>>> > I can imagine that other services/protocols would like to use it as well, and >>>> > extracting this information from an option related solely to enrollment does >>>> > not seem the best idea. I have been thinking for some time about an option >>>> > for RPL that would provide some aggregate information about the DODAG to the >>>> > nodes, such as its size, max depth, and the like. The option could also be >>>> > used in the enrollment process. Do you think this makes sense? >>>> We agreed to merge two drafts. The DODAG_Size came from the other draft. >>>> We think that the two values are very much related and it made sense to send >>>> them together. >> >> OK, now I understand. However, this also generates some further issues I wanted to point in my reply to Rahul's and Pascal's comments. > > Looking forward. Thanks a bunch Konrad for opening the discussion on the draft. This is incredibly helpful! > > You all keep safe, > > Pascal > >> >> Best, >> -- >> - 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 Tue Aug 10 02:24: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 E196A3A0A4C; Tue, 10 Aug 2021 02:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.596 X-Spam-Level: X-Spam-Status: No, score=-9.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=BfPrnUTp; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=PGoj4SyX 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 6EdzfoczquIN; Tue, 10 Aug 2021 02:24:02 -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 145163A0A4A; Tue, 10 Aug 2021 02:24:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12246; q=dns/txt; s=iport; t=1628587442; x=1629797042; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=t5EkDnn6e8M3bSyV4HABCVy41BXv/BqKGa9j2N4K3G0=; b=BfPrnUTpHz1x8xVOh6vkuQiS4mQGAU9BWwzWiaXjmnU3FbkwYMifQKeo g119UeIehAy/WsgspFXDVYzHp04M4kpZcnrJkiSKtcpumgGq4dBd8oe+v 6KO0MwqnPci5lXO5MDXkB23ptQKblbEIkrdBZvCyJRWovwS8ih1nuvNU7 Y=; IronPort-PHdr: =?us-ascii?q?A9a23=3AnE0mZxaejpe6vRW5T0YTV17/LTDNhN3EVzX9o?= =?us-ascii?q?rIiirdTbeKu84mkJEiMrflujVqcW4Ld5roEjufNqKnvVCQG5orJq3ENdpFAF?= =?us-ascii?q?npnwcUblgAtGoiJXEv8KvO5ai0/AdsEWVN4uWm/YgBZHc/kbAjUpXu/pTcZB?= =?us-ascii?q?hT4M19zIeL4Uo7fhsi6zaa84ZrWNg5JnzG6J7h1KUbekA=3D=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AwRO3qKomGWNDYjHrtcjVvFkaV5t0LNV00z?= =?us-ascii?q?EX/kB9WHVpm5Oj9vxGzc506farslkssSkb6K690KnpewK6yXcH2/hhAV7EZn?= =?us-ascii?q?ikhILIFvAj0WKG+V3d8kLFh5VgPSkLSdkFNDSdNykesS++2njGLz9C+qjEzE?= =?us-ascii?q?nLv5ai854Fd2gDAMsMg3Ybe2Sm+w9NNXV77PECZfyhD7981kKdkAMsH72G7x?= =?us-ascii?q?c+Loz+juyOsKijTQ8NBhYh5gXLpyiv8qTGHx+R2Qpbey9TwJ85mFK11jDR1+?= =?us-ascii?q?GGibWW2xXc32jc49B9g9360OZOA8SKl4w8NijssAC1f45sMofy+Azd4dvfr2?= =?us-ascii?q?rCouO8+ivIDP4Ds085uVvF+icF7jOQlgrGLUWSk2Nwz0GT/PARDwhKe/apzb?= =?us-ascii?q?gpAScxrXBQ4O2VFMlwrjykX109N2KeoM213am7azh60kWzunYsiugVkjhWVp?= =?us-ascii?q?YfcqZYqcgF8FpSC4poJlO31GkLKpglMCjn3ocaTbpaVQGugkB/hNi3GngjFB?= =?us-ascii?q?aPRUYP/sSTzjhNhXh8i08V3tYWkHsM/I80D8As3ZWLDo140LVVCsMGZ6N0A+?= =?us-ascii?q?kMBcOxF2zWWBrJdGafO07uGq0LM2/E75T3/LI27ue3f4Fg9up8pL3RFFdD8W?= =?us-ascii?q?IicUPnDsODmJVN7xDWWW24GS/gz8lPjqIJ8YEUhICbeRFrbWpe0vdIj89vdv?= =?us-ascii?q?EzaszDca6+WcWTWFcGMbw5qDHDZw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BhDQAcRRJh/5NdJa1aDhABAQsSDEC?= =?us-ascii?q?BTguBUykoB3daNzGER4NIA4U5iGQDj2+KRoFCgREDVAsBAQENAQEqCwwEAQG?= =?us-ascii?q?EWAIXgksCJTcGDgECBAEBARIBAQUBAQECAQYEgREThTsBBiYNhkIBAQEBAwE?= =?us-ascii?q?BEBERDAEBJQcLAQsEAgEIEQQBAQECAiYCAgIlCxUICAIEDgUIGoJQglUDLwE?= =?us-ascii?q?OnDEBgToCih96gTGBAYIHAQEGBASFFRiCNAMGgRAqgnyED4ZkJxyBSUSBFUN?= =?us-ascii?q?UgQ2BAT6CYgEBgSYcIBWDADaCLoNKBgFYAQ5TIg0pAxYnHBEIDRAYER8FDyI?= =?us-ascii?q?SkRAig0aoIQqDKJF2jG4Sg2WLYJcqhTmQVqAchH8CBAIEBQIOAQEGgXYlgVl?= =?us-ascii?q?wFTuCaVAZDokdgiqCWAwWgQMBBwICBAeCNYUUhQVFczgCBgEKAQEDCYYxKoE?= =?us-ascii?q?/XgEB?= X-IronPort-AV: E=Sophos;i="5.84,310,1620691200"; d="scan'208";a="921189336" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Aug 2021 09:24:00 +0000 Received: from mail.cisco.com (xbe-rcd-006.cisco.com [173.37.102.21]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 17A9Nxr9020732 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Tue, 10 Aug 2021 09:24:00 GMT Received: from xfe-aln-001.cisco.com (173.37.135.121) by xbe-rcd-006.cisco.com (173.37.102.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 10 Aug 2021 04:23:59 -0500 Received: from xfe-rcd-002.cisco.com (173.37.227.250) 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.15; Tue, 10 Aug 2021 04:23:59 -0500 Received: from NAM02-BN1-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.15 via Frontend Transport; Tue, 10 Aug 2021 04:23:59 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Jgb+nk8p2TbfQpkOodr2zmFRMFeMXhLZ6xYBz/P8bmuvd1K/EPxQTbYzhcPRDixpxivSAGmfVwK7BHrgF16eAaDfUOAQiAxa93Dj6oNYZ8EPauHuDsO3z/ti6PcUWkYRszBHPXbUZJBKaZh8KRmpuvgPL2mK8h5GtlI0V6Tio5BPs4IaK0ceaA4ObJhUSz5cQkZpgNGoTWK3BpAM5aNsEHUOm/Mj+aVs/s8tqIi4cnKxsPelGTLCkNJgOlLbwyARqbbn5QMcpMlyPNXbm8ZoskmkDbbittdpI0LPlSnPjqQYEeYDosFW+Pk2FmLlqNNp/9XOrNq/11HuMxfszlpMBw== 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=t5EkDnn6e8M3bSyV4HABCVy41BXv/BqKGa9j2N4K3G0=; b=HA/PXXj+tRWiO07sF8wXBHFxhzQek0EkKIaWQyqWmSNOK8VB+c2TbAcY0yez5rikod/5ABOdbpD+ygb/nwTZs1INadfeJuX6HmrTQP17JMGkB9UhyisoWRHULcXxwsHVOjv232R9wtgE3x5MTSG/ZCaHHJV0RkBOGUQwQ2yeXXjE71VWxH4jUGF/atwbWdX6jfrZYGE6Cag4xnImTryBcRSraaUTj053eDKFm8Ge7SRAEmvnmx5z+7VZVmbFN+jA+5+MJJm3eWPI9vNmLS+vkQtMIIdjbQ4kL0dAvJfU9IGuCcX28jCGkM6x/sQ1I39QXfgp7Ew7IrZAv8qMUXCEFA== 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=t5EkDnn6e8M3bSyV4HABCVy41BXv/BqKGa9j2N4K3G0=; b=PGoj4SyXVcJ38+QbzYhYQnExqr8aeM4MvWyu0fuiHF3WyTgv1lN1WEXcArY7pMPN4PLM7UWBYr5hdGCepuR2rpSr1vm1or/QAmOOKIzjGMeQe9Sa6EeZeP0ZZnK/dJ77betmsxzjI/vRBfmMQCIdYGYH5HryZ7dw/YbflfqVix8= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MWHPR11MB1664.namprd11.prod.outlook.com (2603:10b6:301:c::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.16; Tue, 10 Aug 2021 09:23:57 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::487e:47b8:314f:189a]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::487e:47b8:314f:189a%6]) with mapi id 15.20.4394.023; Tue, 10 Aug 2021 09:23:57 +0000 From: "Pascal Thubert (pthubert)" To: Konrad Iwanicki , "Routing Over Low power and Lossy networks" CC: "roll-chairs@ietf.org" , Michael Richardson Thread-Topic: [Roll] Review of draft-ietf-roll-enrollment-priority-04 Thread-Index: AQHXiW/D5aIXC0jIjUWmxkQskylezqtri3cAgAAnYYCAAKvYRoAAGw2AgAAFUTA= Date: Tue, 10 Aug 2021 09:23:45 +0000 Deferred-Delivery: Tue, 10 Aug 2021 09:22:53 +0000 Message-ID: References: <26245.1628534920@localhost> <9A1DA017-AF66-4349-B070-57A4BC28A48A@cisco.com> <91409cc4-1adb-dffb-c5a5-a3aa65d94a95@mimuw.edu.pl> In-Reply-To: <91409cc4-1adb-dffb-c5a5-a3aa65d94a95@mimuw.edu.pl> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: mimuw.edu.pl; dkim=none (message not signed) header.d=none;mimuw.edu.pl; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 491aeaeb-d292-4b8b-467c-08d95be0946a x-ms-traffictypediagnostic: MWHPR11MB1664: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: mf8vsYV9CXjjV0PeBvKZexe1kUd1CDquau4KbniI262PJGg8bJY2Q9CmpGLAejaaVfmaRXJIfLEDjlfiBrAtovoQBp2D/N7A06KUsX7N8mTbJdCJTQ2VjhKKz0nVM2MVNiMMqqgsvkgZqnYFuHXt6oxR+Eu4K4sJG+ZPc1iFAMtc5sOHSmZVMOCCp7qV8k9uM4F0EOUMsmey6IB929y2SCa5wYlwzWTk3FzmlYufp0Z4pPu4x1AW4bLwpo1ljgvKFdvtZwIaj/xss9B1Vj+JSSjQf2gmRnqRugW8miqBABphZTrBg7+195QgmkFrcu10cX72XjZzsDvsLwC2bL4TQixkYvXOJb/vu/zJgtelJdZEcS0y9KawmJlqEUlw1t3IhvSpjRgtws9hkwt9e3iWh94J9iZPBowHgP/2UOSO8lBBoH+x7mxijA5WHvecOSvFIXnLjWOUvTl4h8Nw+5Y0wle2jPEVjMX33yCUeg7cHfYPIOfw/ZkrdxO/d5xeDg55zncwfpqFO4ixRGVDdow+rHqHZQ3qIxiOH7IqL0kh3fAnJpA+JGrS1/a+hux0bL33xiJtdNTp08/hLd4VjhjEDfhm3R4Ldzf78So+Mhlv7gKl7bDa6bxE5oZilP62Nag4w73TTU8DtmGObdW9t0ucltkytZjbrc5Gyb1NQznDtGZoQOi+Ecr6iPgIHMu1roF4KvbsYjf2cZQ51So2sdjnnNysY9UcNmuXEli7wgROgL99l9PS2TVibvzTTKI/Q0QOVDc8dg1vNcTIQ2ChvO30KGBeIqnaF9vZKl5sCX2bV6c= 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:(376002)(39860400002)(346002)(396003)(366004)(136003)(33656002)(9686003)(86362001)(110136005)(66476007)(66556008)(66946007)(64756008)(52536014)(4326008)(83380400001)(8936002)(66446008)(316002)(8676002)(55016002)(71200400001)(6666004)(7696005)(66574015)(186003)(966005)(6506007)(53546011)(54906003)(76116006)(5660300002)(478600001)(2906002)(38100700002)(38070700005)(122000001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?aVF6RFpwTHI5SVZUV0RSMnh1TVlIK3hnUUo0ZG5TMXlRaW1VU2lTNHpzdFJ6?= =?utf-8?B?VUE2bFR6c1RsczJxR0Z3N1BiUHVyb2NlcGttTmNnQUdwVkZ1RVpiUnVMRUhx?= =?utf-8?B?ciswVlFRVjFFemRQN0VGOXBxeGxJcGdJV0RoelNJOUI0V0tpaXFteU5Xa3FY?= =?utf-8?B?ODNpd0lKUVhMenZGb09QUWY5RDNvKzhGRnBYRXNlRFo5OTdYVkZMU28vTU5k?= =?utf-8?B?M0JpelZKWlRyVlBhZTVTSlczRnVqVDRPOXY4dDYwSGNLT0lkWkg3RnVYTWVm?= =?utf-8?B?SVJ1eTYyWVZlTllLSmRHTTVEMHpYaTAxZnF0OVVWQ1ZRUTl0Qi9aWUYwanNS?= =?utf-8?B?WURCd2J3bnJ6SDVtQk5RUUFsamVIczlWclhOOWpIUWdTV01LL05DUjZqbUhM?= =?utf-8?B?VEVtakRIZndxMUZlTW1BZk04c0dzejdyNDZmZHRERzFlU2UrS21iNDJzcXZx?= =?utf-8?B?K05saXJ5WjBWMnVWdlJiSDFMcDAwUUlJeHRCWHNrYmVhQ1VicUVzN29sN25V?= =?utf-8?B?SEdxa0FaNnJmMDVZQUFnaUFuVHJURDIyN2owTjE1dEhNSGVFYzdVM1RDOHJ0?= =?utf-8?B?SEpONmFnRE1adEtJdTVYQVVDMHRjSGV5eVZxVVlpZXc4NUF3ajkwZlRiSnZH?= =?utf-8?B?cXFiSFpVQVlMaTFwNVdNOE52M2VuNFVDVElYL1ZkYlRyV1FTMm84OUZmWEtG?= =?utf-8?B?bDhwUC82bjFyY0t5VkNpMGxUZEVqYW1Cbjl0VE5rdW9oM01Tb2hJWXNocjNj?= =?utf-8?B?MFAvUnlKQmlaU3FCMmU2TS94S2cxbnkyQ0w2elNZajEwdDhtSVRwL0NwR2NG?= =?utf-8?B?RHZyVTUzRUFGeDQvc2pOcmFWNExreC8yUFEyaHVHR0M2eEE0V0R3eEoxeWVU?= =?utf-8?B?dVgwc25yNUlNZGZzMmF5R3Jyb2c1WEZ0QVppek9BRWl2THJ5YW5SY0NRUjJH?= =?utf-8?B?aURJSXZsUG11Ry9qZEdkMGt3bU91akRMbDQ0THFGbmlmZkU0SWc1emRpbVdr?= =?utf-8?B?S2tUaDhqZG9ZdWlrVnhSS1k1a0ROb3FGZXdYOGl2OURkRllURTgxQ3EyZHVm?= =?utf-8?B?emFuZzF6MEJzNkt2K0w1N0piZTBUWHp3d0NyKzBBOTM3Rk9sMXpvUzVBcU5s?= =?utf-8?B?cDBMdW01SldKRXZuSnFKWVlraTM0VGlwcnJMa1RibTFKa3dFOWFqMkNjcEVT?= =?utf-8?B?TitFdktpSUNCanl6MW1Cdm04empjeHgvdUU1QkhaZ3BXVityeEpnZlVuMTJP?= =?utf-8?B?ZVBBcHg3ZG1uR1ZESFJPdEhpMnU4aGMzYXZvcVozQVp5V2JmK09ha2tnV01V?= =?utf-8?B?STRXcXJ3YUpCTHdpc3RTYWtzbHowaUJsYmcyRGlONThlMk9jaDZ6eHVoNVYy?= =?utf-8?B?eDNHQWFJL29iRlh4Y2U3bjUxdmNiWW5vOHFQMEpiNm9QQ3lia1IreGsrNU1Y?= =?utf-8?B?ME9kZUE0YTBqTVJYbFhLZXBGUVBPZDJpQW02RGE2ekJKeGdYWWtqbVJUby9r?= =?utf-8?B?eXJQenhtMW50U0lqYy8xTUI5M3FBTUxvd3pROEgxUWt6WUpYZURoczNkcDdN?= =?utf-8?B?ME1OSEVzZFp1U3dSTmNaVHhMYnJyMWk5TlNiNHdLYWkxQUNWakdlMStNc0dv?= =?utf-8?B?K1F0Yy9XbE8xa2lTeXArVjcyanFGRm5CVDVQOFdjS1kzbllaYlgxc3NtNzJL?= =?utf-8?B?OWxvSG45citqclR5SVhoczR1Yjg4Q1RsRyt4cGdOQzdGUmtLM1lmNWxENUpH?= =?utf-8?B?QjViQnNMdWk4SGVLbW1vZEc2bGFjQjNEbXZEL29PMHFyY2tTSXFMSUNQWHZk?= =?utf-8?B?cEtjS2FibjNYZ0F0VTN1MVNwczZVQ2wrUUZ2QUlZY3N5Y3dZVDJwazdIa2lQ?= =?utf-8?Q?QQkJSLstxwoyR?= 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: 491aeaeb-d292-4b8b-467c-08d95be0946a X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Aug 2021 09:23:56.8797 (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: z4K+VmzbYB+PeQIPBobV4F9SB8UNh49/VxQeLl8iu10DLKPsYb81gbkyW1ee/ca4R78PWPTh2OCziCReWhVs4Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1664 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.21, xbe-rcd-006.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [Roll] Review of draft-ietf-roll-enrollment-priority-04 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, 10 Aug 2021 09:24:08 -0000 R3JlYXQhIA0KDQpQbGVhc2UgYXNrIHRoZSBjaGFpcnMgZm9yIDIwLTMwIG1pbnV0ZXMgYXQgdGhl IGludGVyaW0uIFNpbmNlIHdlIHdhbnQgdG8gc2hpcCB0aGUgZHJhZnQsIHRoaXMgaXMgcHJvYmFi bHkgdXJnZW50IGVub3VnaCBhbmQgaW50ZXJlc3RpbmcgZW5vdWdoIHRvIGp1c3RpZnkgYWEgbGFy Z2Ugc2xvdCB3aXRoIGVub3VnaCBkaXNjdXNzaW9uIHRpbWUgdG8gcmVhY2ggY29uc2Vuc3VzLg0K DQpLZWVwIHNhZmU7DQoNClBhc2NhbA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IEtvbnJhZCBJd2FuaWNraSA8aXdhbmlja2lAbWltdXcuZWR1LnBsPg0KPiBTZW50OiBt YXJkaSAxMCBhb8O7dCAyMDIxIDExOjAxDQo+IFRvOiBSb3V0aW5nIE92ZXIgTG93IHBvd2VyIGFu ZCBMb3NzeSBuZXR3b3JrcyA8cm9sbEBpZXRmLm9yZz4NCj4gQ2M6IHJvbGwtY2hhaXJzQGlldGYu b3JnOyBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitpZXRmQHNhbmRlbG1hbi5jYT47DQo+IFBhc2Nh bCBUaHViZXJ0IChwdGh1YmVydCkgPHB0aHViZXJ0QGNpc2NvLmNvbT4NCj4gU3ViamVjdDogUmU6 IFtSb2xsXSBSZXZpZXcgb2YgZHJhZnQtaWV0Zi1yb2xsLWVucm9sbG1lbnQtcHJpb3JpdHktMDQN Cj4gDQo+IEhpIFBhc2NhbCBhbmQgYWxsLA0KPiANCj4gVGhhbmtzIGZvciB0aGUgY29tbWVudHMu IE5vdyBJIGhhdmUgYSBmdWxsIHBpY3R1cmUgb2YgaG93IGVhY2ggb2YgeW91DQo+IGVudmlzaW9u IHRoZSBwcm90b2NvbC4gQmVmb3JlIHRoZSBpbnRlcmltLCBJIHdpbGwgdHJ5IHVwIHRvIHdyaXRl IHVwIGFsbA0KPiBteSByZW1hcmtzIHJlZ2FyZGluZyB0aGVzZSBpZGVhcyBhbmQgdGhlIGlzc3Vl cyBJIG1lbnRpb25lZCB0aHJvdWdob3V0IG15DQo+IGxhc3QgcmVwbHksIHNvIHRoYXQgaG9wZWZ1 bGx5IHdlIGhhdmUgc29tZSBzdGFydGluZyBwb2ludCBmb3IgZGlzY3Vzc2lvbi4NCj4gDQo+IEkg d2lsbCBwcm9iYWJseSBjbG9zZSB0aGUgdGhyZWFkIGF0IHRoaXMgcG9pbnQgYW5kIHBvc3QgYW4g ZS1tYWlsIGFzIGENCj4gcmV2aWV3IG9mIHZlcnNpb24gMDUuDQo+IA0KPiBCZXN0LA0KPiAtLQ0K PiAtIEtvbnJhZCBJd2FuaWNraS4NCj4gDQo+IE9uIDEwLjA4LjIwMjEgMDk6MjQsIFBhc2NhbCBU aHViZXJ0IChwdGh1YmVydCkgd3JvdGU6DQo+ID4NCj4gPg0KPiA+PiBMZSA5IGFvw7t0IDIwMjEg w6AgMjM6MTAsIEtvbnJhZCBJd2FuaWNraSA8aXdhbmlja2lAbWltdXcuZWR1LnBsPiBhIMOpY3Jp dA0KPiA6DQo+ID4+DQo+ID4+IO+7v0RlYXIgTWljaGFlbCBhbmQgYWxsLA0KPiA+Pg0KPiA+PiBG aXJzdCBvZiBhbGwsIHRoYW5rIHlvdSBmb3IgeW91ciBraW5kIHdvcmRzIHJlZ2FyZGluZyB0aGUg cmV2aWV3LiBJIGFtDQo+IGFjdHVhbGx5IHBsYW5uaW5nIHRvIGF0dGVuZCB0aGUgQXVndXN0IGlu dGVyaW0sIGJlY2F1c2UgSSB3aWxsIGJlDQo+IHByZXNlbnRpbmcgdGhlIHJuZmQgZHJhZnQsIHNv IHdlIGNhbiBkaXNjdXNzIHRoZSBlbnJvbGxtZW50IHByaW9yaXR5IGRyYWZ0DQo+IGluIGRlcHRo IGFzIHdlbGwuDQo+ID4+DQo+ID4+IEJlbG93IEkganVzdCBxdWlja2x5IHJlcGx5IGlubGluZSB0 byBNaWNoYWVsJ3MgY29tbWVudHMgYXMgdGhleSBsZWQgdG8NCj4gYSBuZXcgdmVyc2lvbiBvZiB0 aGUgZHJhZnQuIEkgd2FzIGFjdHVhbGx5IHJlcGx5aW5nIHRvIFBhc2NhbCdzIGFuZA0KPiBSYWh1 bCdzIGNvbW1lbnRzIHdoaWxlIHRoZSBuZXcgZHJhZnQgdmVyc2lvbiBhcHBlYXJlZCwgYW5kIHRo ZSBuZXcgdmVyc2lvbg0KPiBzdGlsbCBoYXMgc29tZSBpc3N1ZXMsIHdoaWNoIEkgd2FudGVkIHRv IHBvaW50IG91dCBpbiB0aG9zZSByZXBsaWVzLg0KPiA+Pg0KPiA+PiBTbyB3aGF0IGRvIEkgZG8g dGhlbiwgd3JpdGUgYW5vdGhlciByZXZpZXcgZm9yIHRoZSBuZXcgdmVyc2lvbiB3aGVyZSBJDQo+ IGNhbiBleHBsYWluIHRob3NlIGlzc3Vlcz8NCj4gPj4NCj4gPj4+IE9uIDA5LzA4LzIwMjEgMjA6 NDgsIE1pY2hhZWwgUmljaGFyZHNvbiB3cm90ZToNCj4gPj4+ICAgICA+IEluIGNvbnRyYXN0LCBS RkMgNjU1MCwgc2VjdC4gOC4yLjMgc3RhdGVzIHRoYXQgRElPcyBub3Qgb25seQ0KPiBmcm9tIHBh cmVudHMgYnV0DQo+ID4+PiAgICAgPiBhbHNvIG90aGVyIG5laWdoYm9ycyBtdXN0IGJlIHByb2Nl c3NlZCBieSBhIG5vZGUuIFRoaXMNCj4gZ3VhcmFudGVlcyBjb3JyZWN0DQo+ID4+PiAgICAgPiBy b3V0ZSBmb3JtYXRpb24gYW5kIG1haW50ZW5hbmNlLg0KPiA+Pj4gWWVzLCBpdCdzIHRydWUuICBB IG5vZGUgc2hvdWxkIGV2YWx1YXRlIERJT3MgZnJvbSBvdGhlciBzb3VyY2VzLCBhbmQNCj4gPj4+ IGlmIHRob3NlIHNvdXJjZXMgYXJlIGJldHRlciwgdGhlbiBpdCBzaG91bGQgc3dpdGNoIHBhcmVu dHMuICBCdXQgYXQNCj4gPj4+IGFueSBwb2ludCwgYSBub2RlIHJlYWxseSBoYXMgb25seSBvbmUg cGFyZW50Lg0KPiA+Pj4gVGhlIG90aGVyIG5vZGVzIGFyZSBwb3RlbnRpYWwgcGFyZW50cywgYnV0 IG5vdCBwYXJlbnRzLg0KPiA+Pj4gUGVyaGFwcyBSRkM2NTUwIGhhcyBzb21lIG90aGVyIHRlcm1z IHdoaWNoIEkndmUgbmVnbGVjdGVkIHRvIHVzZS4NCj4gPj4NCj4gPj4gSSBiZWxpZXZlIFJGQyA2 NTUwIHVzZXMgdGVybSAicGFyZW50IiBmb3IgYW55IG5laWdoYm9yIHdpdGggYSByYW5rDQo+IGxv d2VyIHRoYW4gdGhlIG5vZGUgaXRzZWxmIGFuZCAicHJlZmVycmVkIHBhcmVudCIgZm9yIHRoZSBw YXJlbnQNCj4gKGNvbmNlcHR1YWxseSBhIHNpbmdsZSBvbmUpIHRoYXQgdGhlIG5vZGUgdXNlcyBh cyB0aGUgbmV4dCBob3Agb24gaXRzDQo+IHVwd2FyZCByb3V0ZXMuIFRoaXMgbWF5IGJlIG9uZSBv ZiB0aGUgc291cmNlcyBvZiBteSBjb25mdXNpb24uIEFmdGVyIHlvdXINCj4gZXhwbGFuYXRpb24s IEkgdW5kZXJzdGFuZCB5b3VyIHBvaW50IG9mIHZpZXcgb24gdGhlIHByb3RvY29sLiBUaGFua3Mu DQo+ID4+DQo+ID4+PiAgICAgPiAzLiBFdmVuIGlmIHRoZSBkcmFmdCBpZGVudGlmaWVkIGEgc2lu Z2xlIHBhcmVudCBhcyB0aGUgb25seQ0KPiBzb3VyY2Ugb2YgbWluDQo+ID4+PiAgICAgPiBwcmlv cml0eSB2YWx1ZXMgZm9yIGEgbm9kZSwgdGhlcmUgc3RpbGwgd291bGQgYmUgYSBwcm9ibGVtIG9m DQo+IHZhbHVlDQo+ID4+PiAgICAgPiBjb25zaXN0ZW5jeS4NCj4gPj4+ICAgICA+IFNpbmNlIHRo ZSBET0RBRyByb290IGNhbiBjaGFuZ2UgaXRzIHZhbHVlcyBvZiBtaW4gcHJpb3JpdHkgYW5kDQo+ IERPREFHX1NpemUgYW5kDQo+ID4+PiAgICAgPiBzaW5jZSBhIG5vZGUgY2FuIGNoYW5nZSBpdHMg cGFyZW50cywgdGhlcmUgbWF5IHN0aWxsIGJlIGEgY2FzZQ0KPiB3aGVuIHRoZSBub2RlDQo+ID4+ PiAgICAgPiBtdXN0IGRlY2lkZSB3aGV0aGVyIHRvIGFkb3B0IHRoZSBuZXdseSByZWNlaXZlZCB2 YWx1ZXMgb3Igbm90Lg0KPiBXaXRob3V0IGENCj4gPj4+ICAgICA+IHByb3BlciBjb25mbGljdCBy ZXNvbHV0aW9uIHBvbGljeSwgaXQgbWF5IGJlIHRoZSBjYXNlIHRoYXQgd2hlbg0KPiB0aGUgcm9v dCwgZm9yDQo+ID4+PiAgICAgPiBleGFtcGxlLCBkaXNhYmxlcyBlbnJvbGxtZW50LCB0aGVuIGVu YWJsZXMgaXQgYWdhaW4sIHRoZW4gdGhlDQo+IERPREFHIG1heQ0KPiA+Pj4gICAgID4gZXhoaWJp dCBzdHJhbmdlIGJlaGF2aW9yczogdGhlIHJvb3QncyBkZWNpc2lvbiBtYXkgbm90IGJlDQo+IHBy b3BhZ2F0ZWQgdG8gYWxsDQo+ID4+PiAgICAgPiBub2RlcywgYSBkZWNpc2lvbiBtYXkgYmUgcmV2 b2tlZCBieSBub2RlcyB0aGF0IGhhdmUgYWxyZWFkeQ0KPiBhY2NlcHRlZCBpdCwgYW5kDQo+ID4+ PiAgICAgPiB0aGUgbGlrZS4NCj4gPj4+IEEgcm9vdCB0aGF0IGRpZCB0aGlzLCB3b3VsZCBoYXZl IHRvDQo+ID4+PiBpbmNyZW1lbnQgdGhlIERUU04gcmlnaHQgZWFjaCB0aW1lIGl0IGNoYW5nZWQg aXQncyBtaW5kLg0KPiA+Pg0KPiA+PiBPSyBidXQ6DQo+ID4+DQo+ID4NCj4gPiBBY3R1YWxseSBu b3QgT0sNCj4gPg0KPiA+IFRoZSBEVFNOIHRyaWdnZXJzIERBTyBtZXNzYWdlczsgdGhpcyBzZWVt cyB1bnJlbGF0ZWQgYW5kIHVuZGVzaXJhYmxlLg0KPiA+DQo+ID4gTWF5YmUgdGhlIHN1Z2dlc3Rp b24gd2FzIHJlYWxseSB0byByZXN5bmMgdGhlIERBRyB0byBhIG5ldyB2ZXJzaW9uIHRoYXQNCj4g d291bGQgb3BlcmF0ZSB3aXRoIHRoZSBuZXcgbWluaW11bT8NCj4gPg0KPiA+IFRoYXTigJlzIGFj dHVhbGx5IG5vdCBhIGNvbnZpbmNpbmcgaWRlYSBlaXRoZXIsIHNpbmNlIHRoZSBtaW5pbXVtIHZh bHVlIG9mDQo+IHByaW9yaXR5IGlzIG5vdCBjb25maWd1cmVkIGJ1dCBhIER5bmFtaWMgY29tcHV0 YXRpb24gdGhhdCBtYXkgY2hhbmdlIGEgbG90DQo+IG1vc3RseSBkdXJpbmcgdGhlIERPREFHIGZv cm1hdGlvbi4NCj4gPg0KPiA+DQo+ID4+IDEuIFRoaXMgaXMgbm90IG1lbnRpb25lZCBpbiB0aGUg bmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0Lg0KPiA+PiAyLiBJbiBub24tc3RvcmluZyBtb2RlLCB0 aGlzIHdvdWxkIGdlbmVyYXRlIHVwd2FyZCB0cmFmZmljIGZyb20gZXZlcnkNCj4gbWVtYmVyIG9m IGEgRE9EQUcsIHdoaWNoIG1heSBiZSBwcm9ibGVtYXRpYy4gVG8gZXhwbGFpbiwgc3VwcG9zZSB0 aGF0IHRoZQ0KPiBNT1AgaXMgaW5kZWVkIG5vbi1zdG9yaW5nIGFuZCB0aGF0IHRoZSByb290IHNl dHMgaXRzIG1pbiBwcmlvcml0eSB0byAweDdmDQo+IHRvIGRpc2FibGUgZW5yb2xsbWVudHMgYmVj YXVzZSBpdCBpcyB1bmFibGUgdG8gaGFuZGxlIGFueSBtb3JlIHRyYWZmaWMuDQo+IEFjY29yZGlu ZyB0byB5b3VyIHN1Z2dlc3Rpb24sIGRvaW5nIHRoaXMsIHRoZSByb290IGluY3JlbWVudHMgaXRz IERUU04uDQo+IFBlciBwb2ludCAxLiBvZiB0aGUgb3JkZXJlZCBsaXN0IGluIFNlY3QuIDkuNiBv ciBSRkMgNjU1MCwgZXZlcnkgbm9kZQ0KPiBzZWVpbmcgdGhlIGluY3JlbWVudGVkIERUU04gZnJv bSBpdHMgcGFyZW50IGlzc3VlcyBhIERBTyBtZXNzYWdlIHVwd2FyZHMuDQo+IFBlciBwb2ludCAy LiBvZiB0aGUgc2FtZSBsaXN0LCB0aGUgbm9kZSBhbHNvIGluY3JlbWVudHMgaXRzIG93biBEVFNO LiBJbg0KPiBlZmZlY3QsIGV2ZXJ5IG5vZGUgaW4gdGhlIERPREFHIHNlbmRzIGEgREFPIHRvIHRo ZSByb290LCB3aGljaCBtYXkgc3dhbXANCj4gdGhlIHJvb3QtLS1hIHNpdHVhdGlvbiB0aGF0IHRo ZSByb290IHdhbnRlZCB0byBhdm9pZCBpbiB0aGUgZmlyc3QgcGxhY2UgYnkNCj4gZGlzYWJsaW5n IGVucm9sbG1lbnRzLiBUaGlzIHNpdHVhdGlvbiBtYXkgYmUgZXZlbiB3b3JzZSBpZiBEQU8tQWNr cyBhcmUgdG8NCj4gYmUgc2VudCBpbiByZXBseSB0byB0aGUgREFPcy4NCj4gPj4NCj4gPiBUcnVl DQo+ID4gSXTigJlzIG5vdCAganVzdCBub24gc3RvcmluZyBpdOKAmXMgYWxsIG1vZGVzDQo+ID4N Cj4gPg0KPiA+PiAzLiBFdmVuIGlmIHRoZSB0aGlzIGFwcHJvYWNoIHdlcmUgY292ZXJlZCBpbiB0 aGUgZHJhZnQsIGl0IHN0aWxsIGhhcw0KPiBzb21lIGlzc3Vlcywgd2hpY2ggSSB3YXMgYWJvdXQg dG8gZXhwbGFpbiBidXQgdGhlIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdA0KPiBhcHBlYXJlZC4N Cj4gPj4NCj4gPiBZZXMgd2UgbmVlZCB0byBzeW5jLiBJIHRoaW5rIE1pY2hhZWwgc3RpbGwgaGFz IGluIG1pbmQgdGhhdCB0aGUgbWluaW11bQ0KPiBpcyBpbmNyZW1lbnRlZCBkb3duLiBUaGF0IHdh cyB0aGUgaW5pdGlhbCBpZGVhLg0KPiA+DQo+ID4gQnV0IHRoYXTigJlzIGNyZWF0aW5nIG1vcmUg cHJvYmxlbXMgdGhhdCBoZWxwIG1vc3RseSBkdWUgdG8gdGhlIGRvZGFnDQo+IHN0cnVjdHVyZSBh bmQgY3V0IHRoZSBjYXBhYmlsaXR5IGZvciB0aGUgcm9vdCB0byBnaXZlIGEgZGlyZWN0IGZlZWRi YWNrIHRvDQo+IHRoZSBub2Rlcy4gSSBub3cgdGhpbmsgdGhpcyBpbmZvcm1hdGlvbiBzaG91bGQg YmUgc2V0IGJ5IHRoZSByb290IGFuZA0KPiByZW1haW4gdGhyb3VnaG91dCB0aGUgZG9kYWcuDQo+ ID4NCj4gPiBUbyBiZSBkaXNjdXNzZWQgYXQgdGhlIG5leHQgaW50ZXJpbeKApg0KPiA+DQo+ID4N Cj4gPj4+ICAgICA+IFRoZXJlIGFyZSBtYW55IHdheXMgaW4gd2hpY2ggc3VjaCBjb25mbGljdCBy ZXNvbHV0aW9uIGNhbiBiZQ0KPiBwcm92aWRlZC4gSWYgSQ0KPiA+Pj4gICAgID4gbWF5IHN1Z2dl c3QgYW55dGhpbmcsIEkgd291bGQgcmVjb21tZW5kIGFkZGluZyB0byB0aGUgb3B0aW9uIGENCj4g bG9sbGlwb3ANCj4gPj4+ICAgICA+IHNlcXVlbmNlIGNvdW50ZXIgKGxpa2UgdGhvc2UgZGVzY3Jp YmVkIGluIFJGQyA2NTUwLCBzZWN0LiA3LjIpLA0KPiBsZXQncyBjYWxsIGl0DQo+ID4+PiAgICAg PiBvc24uIEl0IHdvdWxkIGVmZmVjdGl2ZWx5IG9yZGVyIGRpZmZlcmVudCB2ZXJzaW9ucyBvZiB0 aGUgb3B0aW9uDQo+IHZhbHVlcw0KPiA+Pj4gICAgID4gcHJvZHVjZWQgYnkgdGhlIERPREFHIHJv b3QuIEluIGVmZmVjdCwgd2hlbmV2ZXIgYSBub2RlIHJlY2VpdmVkDQo+IGFuIG9wdGlvbiAoYmUN Cj4gPj4+ICAgICA+IGl0IGZyb20gYSBwYXJlbnQgb3IgYW5vdGhlciBuZWlnaGJvciwgZGVwZW5k aW5nIG9uIHRoZSB3YXkgdGhlDQo+IHByZXZpb3VzDQo+ID4+PiAgICAgPiBpc3N1ZXMgYXJlIGFk ZHJlc3NlZCksIGl0IHdvdWxkIGFkb3B0IHRoZSBtaW4gcHJpb3JpdHkgYW5kDQo+IERPREFHX1Np emUgdmFsdWVzDQo+ID4+PiAgICAgPiB0aGUgb3B0aW9uIGNhcnJpZXMgaWYgYW5kIG9ubHkgaWYg dGhlIG9zbiB2YWx1ZSBpbiB0aGUgcmVjZWl2ZWQNCj4gb3B0aW9uIGlzDQo+ID4+PiAgICAgPiBn cmVhdGVyIHRoYW4gdGhlIG5vZGUncyBsb2NhbGx5IHN0b3JlZCBvc24uIFRoaXMgd291bGQgZ3Vh cmFudGVlDQo+IGV2ZW50dWFsDQo+ID4+PiAgICAgPiBjb25zaXN0ZW5jeSBhbmQgYXZvaWQgc3Ry YW5nZSBiZWhhdmlvcnMgc3VjaCBhcyB0aG9zZSBtZW50aW9uZWQNCj4gYWJvdmUuDQo+ID4+PiBJ J20gbm90IGNvbnZpbmNlZCB3ZSBuZWVkIGFub3RoZXIgbG9sbGlwb3AgY291bnRlci4NCj4gPj4+ IEkgdGhpbmsgdGhhdCB3ZSBhbHJlYWR5IGhhdmUgdGhhdC4NCj4gPj4NCj4gPj4gSSB3b3VsZCBz YXkgdGhpcyBuZWVkIG5vdCBiZSB0aGUgYmVzdCBjaG9pY2UgcGVyOg0KPiA+Pg0KPiA+PiBhKSBt eSByZXBseSBhYm92ZQ0KPiA+Pg0KPiA+PiBiKSB0aGUgZmFjdCB0aGF0IERUU04gaXMgY29uY2Vw dHVhbGx5IGZvciBzb21ldGhpbmcgZWxzZS4NCj4gPg0KPiA+IEFuZCBteSBkcmFmdCBvbiB2ZXJz aW9uaW5nIHRoZSBjb25maWd1cmF0aW9uIGlzIGFsc28gc29tZXRoaW5nIGVsc2UuIFdlDQo+IG5l ZWQgYSBuZXcgc2VxdWVuY2UgZWl0aGVyIGluIHRoaXMgb3B0aW9uIG9yIGdsb2JhbCB0byBhbGwg ZnV0dXJlIHN0YXR1cw0KPiBvcHRpb25zIGZyb20gdGhlIHJvb3QuIFRoYXQgc2VxdWVuY2Ugd291 bGQgbm90IGFsdGVyIHRoZSBSUEwgb3BlcmF0aW9uIGFzDQo+IHZlcnNpb24gYW5kIERUU04gZG8u DQo+ID4NCj4gPj4NCj4gPj4+PiAgICAgPiA0LiBXaHkgcHV0IERPREFHX1NpemUgaW4gdGhlIG9w dGlvbj8NCj4gPj4+PiAgICAgPiBJIGNhbiBpbWFnaW5lIHRoYXQgb3RoZXIgc2VydmljZXMvcHJv dG9jb2xzIHdvdWxkIGxpa2UgdG8gdXNlDQo+IGl0IGFzIHdlbGwsIGFuZA0KPiA+Pj4+ICAgICA+ IGV4dHJhY3RpbmcgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIGFuIG9wdGlvbiByZWxhdGVkIHNvbGVs eSB0bw0KPiBlbnJvbGxtZW50IGRvZXMNCj4gPj4+PiAgICAgPiBub3Qgc2VlbSB0aGUgYmVzdCBp ZGVhLiBJIGhhdmUgYmVlbiB0aGlua2luZyBmb3Igc29tZSB0aW1lDQo+IGFib3V0IGFuIG9wdGlv bg0KPiA+Pj4+ICAgICA+IGZvciBSUEwgdGhhdCB3b3VsZCBwcm92aWRlIHNvbWUgYWdncmVnYXRl IGluZm9ybWF0aW9uIGFib3V0IHRoZQ0KPiBET0RBRyB0byB0aGUNCj4gPj4+PiAgICAgPiBub2Rl cywgc3VjaCBhcyBpdHMgc2l6ZSwgbWF4IGRlcHRoLCBhbmQgdGhlIGxpa2UuIFRoZSBvcHRpb24N Cj4gY291bGQgYWxzbyBiZQ0KPiA+Pj4+ICAgICA+IHVzZWQgaW4gdGhlIGVucm9sbG1lbnQgcHJv Y2Vzcy4gRG8geW91IHRoaW5rIHRoaXMgbWFrZXMgc2Vuc2U/DQo+ID4+Pj4gV2UgYWdyZWVkIHRv IG1lcmdlIHR3byBkcmFmdHMuICBUaGUgRE9EQUdfU2l6ZSBjYW1lIGZyb20gdGhlIG90aGVyDQo+ IGRyYWZ0Lg0KPiA+Pj4+IFdlIHRoaW5rIHRoYXQgdGhlIHR3byB2YWx1ZXMgYXJlIHZlcnkgbXVj aCByZWxhdGVkIGFuZCBpdCBtYWRlDQo+ID4+Pj4gc2Vuc2UgdG8gc2VuZCB0aGVtIHRvZ2V0aGVy Lg0KPiA+Pg0KPiA+PiBPSywgbm93IEkgdW5kZXJzdGFuZC4gSG93ZXZlciwgdGhpcyBhbHNvIGdl bmVyYXRlcyBzb21lIGZ1cnRoZXIgaXNzdWVzDQo+IEkgd2FudGVkIHRvIHBvaW50IGluIG15IHJl cGx5IHRvIFJhaHVsJ3MgYW5kIFBhc2NhbCdzIGNvbW1lbnRzLg0KPiA+DQo+ID4gTG9va2luZyBm b3J3YXJkLiBUaGFua3MgYSBidW5jaCBLb25yYWQgZm9yIG9wZW5pbmcgdGhlIGRpc2N1c3Npb24g b24gdGhlDQo+IGRyYWZ0LiBUaGlzIGlzIGluY3JlZGlibHkgaGVscGZ1bCENCj4gPg0KPiA+IFlv dSBhbGwga2VlcCBzYWZlLA0KPiA+DQo+ID4gUGFzY2FsDQo+ID4NCj4gPj4NCj4gPj4gQmVzdCwN Cj4gPj4gLS0NCj4gPj4gLSBLb25yYWQgSXdhbmlja2kuDQo+ID4+DQo+ID4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IFJvbGwgbWFpbGluZyBs aXN0DQo+ID4+IFJvbGxAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9yb2xsDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPiBSb2xsIG1haWxpbmcgbGlzdA0KPiA+IFJvbGxAaWV0Zi5vcmcNCj4g PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCj4gPg0KPiANCg0K From nobody Tue Aug 10 10:30:27 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 C60EF3A159F for ; Tue, 10 Aug 2021 10:30:24 -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 mftwy9lAdhfK for ; Tue, 10 Aug 2021 10:30:19 -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 E15113A1597 for ; Tue, 10 Aug 2021 10:30:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 0F78B389B1; Tue, 10 Aug 2021 13:34:54 -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 SqN8aLSK5yHJ; Tue, 10 Aug 2021 13:34:46 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5CA62389B0; Tue, 10 Aug 2021 13:34:46 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4A64786F; Tue, 10 Aug 2021 13:30:08 -0400 (EDT) From: Michael Richardson To: Konrad Iwanicki , Routing Over Low power and Lossy networks In-Reply-To: References: <26245.1628534920@localhost> 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] Review of draft-ietf-roll-enrollment-priority-04 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, 10 Aug 2021 17:30:25 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable {I'm getting emails in funny orders because roll-chairs gets to be faster, = as I'm the secretary} Konrad Iwanicki wrote: > Below I just quickly reply inline to Michael's comments as they led to > a new version of the draft. I was actually replying to Pascal's and > Rahul's comments while the new draft version appeared, and the new > version still has some issues, which I wanted to point out in those > replies. > So what do I do then, write another review for the new version where I > can explain those issues? You can do that, or open issues at https://github.com/roll-wg/draft-ietf-roll-enrollment-priority (or I can do that). (Then we can iterate on the issue, but in general I prefer using the ML) I have opened an issue: https://github.com/roll-wg/draft-ietf-roll-enrollment-priority/issues/5 It might be that we need a create a ConfigurationNumber lollilop counter. I could live with that. I note that DIO Configuration essentially has the same problem, right? > I believe RFC 6550 uses term "parent" for any neighbor with a rank > lower than the node itself and "preferred parent" for the parent > (conceptually a single one) that the node uses as the next hop on its > upward routes. This may be one of the sources of my confusion. After > your explanation, I understand your point of view on the > protocol. Thanks. If you think that we should use the word "preferred parent", I'm good with that. The nice thing about having new eyes (like yours) on things is that after 5= -6 reads of a document, one tends to think we know what it says, and often we are subtly wrong. >> A root that did this, would have to increment the DTSN right each ti= me >> it changed it's mind. > OK but: > 1. This is not mentioned in the new version of the draft. I agree that it needs to be explained. I resist adding a new lollipop counter, because that's something new that needs to be written to flash. I think that I am wrong to suggest DTSN increment... I claim heat stroke. = :-) I think that incrementing DODAGVersionNumber is the right answer. I think that all of the Configuration work we've been discussing would also depend upon DODAGVersionNumber, and this is just among that group of things. > 3. Even if the this approach were covered in the draft, it still has > some issues, which I was about to explain but the new version of the > draft appeared. Every version has a diff, so most of us deal with the diff to know if the things we want fixed are actually fixed. >>> We agreed to merge two drafts. The DODAG_Size came from the other >>> draft. We think that the two values are very much related and it >>> made sense to send them together. > OK, now I understand. However, this also generates some further issues > I wanted to point in my reply to Rahul's and Pascal's comments. if it turns out that the two things change at significantly different rates, then combining them may have been a poor choice. =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ =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+93Q3WUFAmESt6AACgkQgItw+93Q 3WU8OggAnvuEprFxPMC9BVXQz6wWTvM9QOGTs/pcsqbl3lOy2GA/dafnxlgY9WwG JDBjPPTuLqWgWVsOoFZrZOxh4f+mHDdsrIa7POSX4Q/fCINIE/ot+hV9ceNHk/ph BfQCzonlxyxBqmJAFn2s9BnDHl1Qr3cz6yvq2AbKRCgy00AAGF2STEGmiYxF1xbP UDTbj/yRPX2mUdRyLHIV28qYFMvIbgIn2Z2OdQIYsw7xi/Hc1Sn+l0yCc4VobVrB FheiGJY77sulDTXT72U1ptlWBdYpjWCQbik3nakWuyAW4Cor3YHGm9eLVGqzw2HL EgQH7AWedmme4lJ6Tz83RUb12Kr/Vg== =a0fy -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 10 10:38: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 D6D453A15F3 for ; Tue, 10 Aug 2021 10:38:13 -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 uBk382o25sNH for ; Tue, 10 Aug 2021 10:38:07 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7A273A15F4 for ; Tue, 10 Aug 2021 10:38:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 521203899A; Tue, 10 Aug 2021 13:42:42 -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 Gvkdyh_gjz25; Tue, 10 Aug 2021 13:42:37 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5380738990; Tue, 10 Aug 2021 13:42:37 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3C79C86F; Tue, 10 Aug 2021 13:37:59 -0400 (EDT) From: Michael Richardson To: "Pascal Thubert \(pthubert\)" , Routing Over Low power and Lossy networks In-Reply-To: <9A1DA017-AF66-4349-B070-57A4BC28A48A@cisco.com> References: <26245.1628534920@localhost>, <9A1DA017-AF66-4349-B070-57A4BC28A48A@cisco.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] Review of draft-ietf-roll-enrollment-priority-04 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, 10 Aug 2021 17:38:14 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Pascal Thubert (pthubert) wrote: > Maybe the suggestion was really to resync the DAG to a new version th= at > would operate with the new minimum? > That=E2=80=99s actually not a convincing idea either, since the minim= um value > of priority is not configured but a Dynamic computation that may chan= ge > a lot mostly during the DODAG formation. I guess that this is more dynamic than the capabilities and the like. First idea: it does not belong in DIO, but should be some new dynamic configuration message. The Capabilities do this. But, this requires another (broadcast/multicast) TXop, and so really we really want it as part of the DIO, I think. One thought is that yes, it needs to be in the DIO, but that it should be a compound object, containing the needed new lollipop counter, and then be extensible with additional sub-TLVs. Or maybe just fixed size TVs. =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+93Q3WUFAmESuXYACgkQgItw+93Q 3WUVvAf+OBQZrAMmtEXO9yvJ+ZfvZHK+o/DnoYTvo7HIuq2bpr8LFK7oIjlbzLF7 ywbgo1uOoATmGZ+dxfxPBef/pgR6g5At87MndP+IQCz00vBKR9vyiZCx1IQssowu fig4AgPekrf0PStYGDrxUWdW8Qch1AcIY7eDvXGfFCteHsMtlMrPXVmsYydpcZ9p FWyfVLO78TMUfbla520x0bjVaW8Je0xwpkKUc+NkTj3rUy9+GnQVtmQMMu818AUs 3q+YW8tSETHBGlWMU78pETu85AduBld5/S1p4gdC553rkc0xHSYRollU/44J+96m P10c2XiXPOhlx6kMr/bDZlD/IoKd4w== =Y6UL -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 10 10:42: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 D7C073A161A for ; Tue, 10 Aug 2021 10:42:23 -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 CQMvhdnd2eON for ; Tue, 10 Aug 2021 10:42:18 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F4573A160B for ; Tue, 10 Aug 2021 10:42:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id BE6373899A for ; Tue, 10 Aug 2021 13:46:54 -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 J0K-7jfCxtD5 for ; Tue, 10 Aug 2021 13:46:49 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A9C3938990 for ; Tue, 10 Aug 2021 13:46:49 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8F3FD86F for ; Tue, 10 Aug 2021 13:42:11 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: <9A1DA017-AF66-4349-B070-57A4BC28A48A@cisco.com> References: <26245.1628534920@localhost>, <9A1DA017-AF66-4349-B070-57A4BC28A48A@cisco.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] Review of draft-ietf-roll-enrollment-priority-04 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, 10 Aug 2021 17:42:24 -0000 --=-=-= Content-Type: text/plain Pascal Thubert (pthubert) wrote: >> 3. Even if the this approach were covered in the draft, it still has >> some issues, which I was about to explain but the new version of the >> draft appeared. > Yes we need to sync. I think Michael still has in mind that the minimum > is incremented down. That was the initial idea. So there are three possible things, I think: 1) root expresses constant to entire DODAG each 6LN expresses it's local increment 2) root expresses base value, 6LNs increment it 3) root expresses base value, 6LNs increment or decrement it I can't see a situation where there is a need to decrement it. Is there someone who has a use case that needs that? I thought that (2) was simplest in terms of code. A change to the minimum priority should not reset trickle or cause new DIOs in my opinion. > And my draft on versioning the configuration is also something else. We > need a new sequence either in this option or global to all future > status options from the root. That sequence would not alter the RPL > operation as version and DTSN do. In the end, I agree. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmESunMACgkQgItw+93Q 3WUnsQf/aDhS+LeqK37ujuHCO3GKdCWlqIaKNNAKVfzK8kve6ZArTrsjdYAyxUfY NvmLbjJacnty2tWx/8L44EJu6wi7dsmeJrVoXs4iE5Lg4BaA1DkVVaRUKR3B9U5I f2bbppyuos3S6F64kOUHhR8hpPbZ3TPQ/R/Ht437BYJVCB+g1uYLbqABsDLlo6z1 7Tl1U6VQOEXJ9MGDw2WPKv6i7B+hGRDMOR+ATqC3DyvZnzXahJZMb8pDbeHbALpN b9hyVSRsI5a5jXdu5Cm9HY52hHRaopjO4fAMhGOxpS6WRBLakKMIJDveFV5xXGkH GF27lyAllc3+/OT5cJ/JHDEVLHe2ag== =vtzP -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 10 11:51:42 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 7B6ED3A1867 for ; Tue, 10 Aug 2021 11:51:41 -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 ouvoCd9h9AHT for ; Tue, 10 Aug 2021 11:51:35 -0700 (PDT) Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) (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 A119A3A1865 for ; Tue, 10 Aug 2021 11:51:35 -0700 (PDT) Received: by mail-vk1-xa2f.google.com with SMTP id d15so2435vka.13 for ; Tue, 10 Aug 2021 11:51:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2juoBskQu+ACNk3j7VEMElxECTa6Lveh7FpDGleWWp4=; b=S6vwT7DztscaX7hbplx1nsYcUdkJQQP2IytmIGmAC0qWz1Nn34h2eWZ/JML3YnNqld 0u9HhBFmlnaAjiIAB1+jLsbMyfWMfqw0odJfonqAk0XSs0KToqMfZmutHQQ6qwzfLHxP euunJOIwut3Er75j1wuzfbd0A2OlcB4mN+DK+RJ2ho9u8pGEZ3zZ7K/TvFjbNRBAXjzM oZ8UT2tmdW4ufeR8lI14zsv5ujTgaykskre6WORLTS7uDFQvqah95cPYeqgE1AHVgWAF HR+l91wMY25SnOqAgZZy95lsY56Mme+yRFrDa41NjTRbDiHXPDCSMso9MwrpWFBwrw9x G00g== 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:cc; bh=2juoBskQu+ACNk3j7VEMElxECTa6Lveh7FpDGleWWp4=; b=Ao5+yzcFvQjHgwvUmZbFDLPnw+cmcuff+fzbvOcr8c8rfmuJYHYiyO8KbMuDtmp96C bis5Okf5xOMvGRt9mrxhel9fNznQolDnzYetYQjOBc5KtJ53zx2Iq63VZpZ3vCoff6XL 87UCetdMpF1MLlnDK4zOE0/CC81KVzKeEzVxcHxacnaQi2Ba1erJAJYHSpA9fFFA5YYY fJMSoDqBRmqhugBC1hL/W3mp2Z2YNyA+bFMPohxUMOuMMjaDrjKnhLlrd/zE0opN96B7 Vy2csXGTUAu6Ul20DgXTj3qSYJZzXOkjFjQjcWH4YT4gnTttYwkTE6p86ydwGEPlI9TK PK9A== X-Gm-Message-State: AOAM533hpzLQ+I4YdrrKqTKBN0bG6d7KFxWGFuRai8tq+haum2VcNvgq k9YfI0V0u9MLKtqGzXOwdr0FRxKE3CHxiMJoJ1Vw1b+7 X-Google-Smtp-Source: ABdhPJzoeEgVr6oWDVePuEWALNBOrNjwaoFBwIQweJsORGqnvXigiMWkueHFTz4rBmPD/earLkM1EmpY5Jlv1RLrZRg= X-Received: by 2002:a05:6122:696:: with SMTP id n22mr17832544vkq.19.1628621493616; Tue, 10 Aug 2021 11:51:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ines Robles Date: Tue, 10 Aug 2021 21:50:57 +0300 Message-ID: To: roll Content-Type: multipart/alternative; boundary="00000000000099c62105c938fd97" Archived-At: Subject: [Roll] ROLL Interim Meeting - 31th August - Agenda and meeting details 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, 10 Aug 2021 18:51:42 -0000 --00000000000099c62105c938fd97 Content-Type: text/plain; charset="UTF-8" Dear all, Please find below the agenda for the interim meeting https://datatracker.ietf.org/meeting/interim-2021-roll-02/materials/agenda-interim-2021-roll-02-roll-01-01.txt Presenters, please *by 25th August, *send us the slides in pdf, or alternatively you can upload them in here : https://datatracker.ietf.org/meeting/interim-2021-roll-02/session/roll. Link to the CodiMD: https://codimd.ietf.org/notes-ietf-interim-2021-roll-02-roll Link to Webex : https://ietf.webex.com/ietf/j.php?MTID=m0f82035057cfa91a3d4a625639f73c02 Note that you can find the provided information (CodiMD, Webex Link, Jabber, icalendar) also in the top right corner of the meeting page [ https://datatracker.ietf.org/meeting/interim-2021-roll-02/session/roll] Comments welcome, Thank you and best regards, Ines and Dominique. On Wed, Jun 30, 2021 at 1:10 PM Ines Robles wrote: > Dear all, > > Thank you very much for filling the doodle. The date selected is 31th > August at 3pm UTC. > > Please let us know if you would like to Present a topic by 30th July > specifying: > > - Topic > - Duration > - Presenter. > > Further meeting details (webex, codimd, etc.) will be provided later. > > Thank you very much in advance, > > Ines and Dominique. > > > On Mon, Jun 7, 2021 at 12:57 PM Ines Robles < > mariainesrobles@googlemail.com> wrote: > >> Dear all, >> >> We would like to organize an interim meeting. Thus, we kindly request to >> let us know your availability by filling the following doodle by *12th >> June. * >> >> https://doodle.com/poll/nd3z4wyar6tqudcv?utm_source=poll&utm_medium=link >> >> Thank you very much in advance, >> >> Ines and Dominique. >> > --00000000000099c62105c938fd97 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

Please f= ind below the agenda for the interim meeting


Presenters, please=C2=A0by 25th Aug= ust,=C2=A0send us the slides in pdf, or alternatively you can upload th= em in here :=C2=A0 https://datatracker.ietf.org/meeting/interim-202= 1-roll-02/session/roll.=C2=A0

Link to the Codi= MD:=C2=A0https://codimd.ietf.org/notes-ietf-interim-2021-roll-02-roll


Note that you can find the provided information (CodiMD, Webex Lin= k, Jabber, icalendar) also in the top right corner of the meeting page [https://datatracker.ietf.org/meeting/interim-2021-roll-02/session/roll= ]

Comments welcome,

T= hank you and best regards,

Ines and Dominique.=C2= =A0

On Wed, Jun 30, 2021 at 1:10 PM Ines Robles <mariainesrobles@googlemail.com> wro= te:
Dear all,

Thank you very much = for filling the doodle. The date selected is 31th August at 3pm UTC.=C2=A0<= /div>

Please let us know if you would like to Present a = topic by 30th July specifying:

- Topic
-= Duration
- Presenter.

Further meeting d= etails (webex, codimd, etc.) will be provided later.=C2=A0

Thank you very much in advance,

Ines = and Dominique.=C2=A0


On Mon, Jun 7, 2021 at 12:57 PM In= es Robles <mariainesrobles@googlemail.com> wrote:
Dear all,
We would like to organize an interim meeting. Thus, we kindly = request to let us know your availability by filling the following doodle by= 12th June.=C2=A0


Thank you v= ery much in advance,

Ines and Dominique.=C2=A0
--00000000000099c62105c938fd97-- From nobody Tue Aug 10 13:36:05 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 172953A1B7E for ; Tue, 10 Aug 2021 13:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.596 X-Spam-Level: X-Spam-Status: No, score=-9.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=MXtI7rrh; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=dVjxlgRF 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 3Y8D_SzlKLMK for ; Tue, 10 Aug 2021 13:35:57 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8B5A3A1B78 for ; Tue, 10 Aug 2021 13:35:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1864; q=dns/txt; s=iport; t=1628627756; x=1629837356; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Ld8s7V69JS9bEXDbc3Vy6PLokSJtWtXTyFfZflNwnkY=; b=MXtI7rrhr68Vh7LRJm7jHKSdlVFSLoM/z0iqGnw3+PvhAxxsR4S1GstP 14i6jnzG5TacmlXK2WVRjw5fq+myKAEca16Onx3EuDQZZuPIOiory2bQi EwuEoXsjWxtTkmP8+Ng26SJbfWNXhQZ+ra/i9LLmwLhvdXP9816G5iQYy E=; IronPort-PHdr: =?us-ascii?q?A9a23=3AYFy/VRTwqlo7HY01ZwRw7ekU2dpso6fLVj580?= =?us-ascii?q?XJvo7NDbqrl+I7tbwTT5vRo2VnOW4iTq/dJkPHfvK2oX2scqY2Av3YPfN0pN?= =?us-ascii?q?VcFhMwakhZmDJuDDkv2f//ncyJ8G95NBxdp+nihOh1TH8DzL1TZvny162sUH?= =?us-ascii?q?RPyfQp4L+j4AMjclcOyguuz4JbUJQ5PgWnVXA=3D=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AiGn/kqzKynpNHvmks443KrPxdOgkLtp133?= =?us-ascii?q?Aq2lEZdPULSK2lfpGV8sjziyWatN9IYgBepTiBUJPwJk80hqQFn7X5Wo3SHD?= =?us-ascii?q?UO2VHYbb2KiLGD/9SOIVyEygcw79YET0E6MqyNMbEYt7e43ODbKadb/DDvys?= =?us-ascii?q?nB7o2yowYPPGNXguNbnnpE422gYytLrXx9dOIE/e2nl7N6TlSbCBAqR/X+Ik?= =?us-ascii?q?NAc/nIptXNmp6jSwUBHQQb5A6Hii7twKLmEjCDty1uEQ9n8PMHyyzoggb57q?= =?us-ascii?q?Ksv7WQ0RnHzVLe6JxQhZ/I1sZDPsqRkcIYQw+czzpAJb4RH4FqjgpF5t1H22?= =?us-ascii?q?xayeUkZC1QZ/ib3kmhOV1dZyGdgDUIngxesUMKgmXo8EcL6faJNA7STfAx2L?= =?us-ascii?q?6wtnDimhUdVBYW6tMW44vRjeslMTrQ2Cv6/NTGTBdsiw69pmcji/caizhFXZ?= =?us-ascii?q?IZc6I5l/1TwKp5KuZKIMvB0vFsLACuNrCq2N9GNVeBK3zJtGhmx9KhGnw1Ax?= =?us-ascii?q?edW0AH/siYySJfknx1x1YRgJV3pAZOyLstD51fo+jUOKVhk79DCscQcKJmHe?= =?us-ascii?q?8EBc+6EHbETx7AOH+bZV7nCKYEMXTQrIOf2sR42Mi6PJgTiJcikpXIV11V8W?= =?us-ascii?q?Y0ZkL1EMWLmIZG9xjcKV/NFQgFCvsurqSRn4eMCoYDHRfzPWzGovHQ1cn3WP?= =?us-ascii?q?erKcpbEKgmd8PeEQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAADj4hJh/5tdJa1aHQEBAQEJARI?= =?us-ascii?q?BBQUBQIFFCAELAYFSKSgHgVE3MYRHg0gDhFlgiGcDmjWBLoElA1QLAQEBDQE?= =?us-ascii?q?BQQQBAYFjgnUCF4JLAiU0CQ4BAgQBAQESAQEFAQEBAgEGBIERE4VoDYZCAQE?= =?us-ascii?q?BAQIBEhERDAEBNwEECwIBCBgCAiYCAgIwFRACBA4FIoJPglYDDiEBnQ4BgTo?= =?us-ascii?q?Cih96gTGBAYIHAQEGBASCUYJGGII0CYEQKgGCe4QPhmQnHIFJRIE8DBCCYj6?= =?us-ascii?q?HWzaCLoJncmiBM4ElDpVfqCEKgyieSwUmpm+FObVxAgQCBAUCDgEBBoFgO4F?= =?us-ascii?q?ZcBVlAYI+UBkOjh+BJQEHCAeCNYpeczgCBgEKAQEDCYh4AQE?= X-IronPort-AV: E=Sophos;i="5.84,310,1620691200"; d="scan'208";a="648970824" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Aug 2021 20:35:55 +0000 Received: from mail.cisco.com (xbe-aln-005.cisco.com [173.36.7.20]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 17AKZtFE019016 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Tue, 10 Aug 2021 20:35:55 GMT Received: from xfe-rtp-001.cisco.com (64.101.210.231) by xbe-aln-005.cisco.com (173.36.7.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 10 Aug 2021 15:35:55 -0500 Received: from xfe-aln-001.cisco.com (173.37.135.121) by xfe-rtp-001.cisco.com (64.101.210.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 10 Aug 2021 16:35:54 -0400 Received: from NAM12-BN8-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.15 via Frontend Transport; Tue, 10 Aug 2021 15:35:53 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lnNcz1oG0axwEDGT4FI8ivs53QbLeumIHxC9amiqNHLu9cFu4cBqZ2kTWAktWOPHGMXU/yy6jtMTydI+pboxPO14OXq9RCYrE0Nxj7MuUSuUl6C6h7e6o5NmwtxAJ01ncRE835XZ48t383VzTmf5SBXGsItpOiAfxixej9FMD+/tf/keBHEYNj0Ls6oiCSpRCA1kVJqul0ZNgTyLa6j8BXwtqeFBOj3lzqPV/hokg84WFvVN98kkrg3t+FVqU70WKfOvDfn+l4qdcj947SQlrojEfsZSimH78h6gaYoOSX2F+gGtZedtqgFhL3L6PvVjc1WO/4sOkayK6LNr7LOUbg== 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=Ld8s7V69JS9bEXDbc3Vy6PLokSJtWtXTyFfZflNwnkY=; b=mWPzdk6piw7/A+KjGVmAqtZtSlZQ5pe/KfxS3/1YGP7iRluL7R1LfQegnxSMWsEW5EFcvm9KThIgYfE3DFjQ6GT+Ghm2c6dPZHil5jwyEypDmivs4a+bpCGpQoiLS99CgLIIME+sS1wc6hLH9ojJEgm5lfuanoqFb3FyfqEO1nHz2pyu7JJBNvlwTOLwixRWuusnHCsfkT5K1ypkJs3BUCVXbR961ZLLhHAIWH5wNctKk5FdVNBm+q2xM2NvS6P8vG96JKAu/fmNKO0qqEHd0z29IxkXFKcTl9JcGgjxLeQmF2m9VHV2mN2hmZItlEqWXU5sZ7zUyZSybNfEivIENA== 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=Ld8s7V69JS9bEXDbc3Vy6PLokSJtWtXTyFfZflNwnkY=; b=dVjxlgRF1MCXtq0XC05jKih6br7ua+8QfYZegQ7jJ6yUycEhjJhIMbfaEem336d6aZvqhwoqzKGcwZxyJI7q6cNnJ3Zu4m79DNkVy74054f3RJuVj4hiT1/ibcjmegfcSvl6+J1cApAg6AtibEjyGQOImfbXZgZ6q+pad4wVeHk= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MWHPR11MB1840.namprd11.prod.outlook.com (2603:10b6:300:112::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4415.14; Tue, 10 Aug 2021 20:35:46 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::487e:47b8:314f:189a]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::487e:47b8:314f:189a%6]) with mapi id 15.20.4394.023; Tue, 10 Aug 2021 20:35:46 +0000 From: "Pascal Thubert (pthubert)" To: Michael Richardson CC: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Review of draft-ietf-roll-enrollment-priority-04 Thread-Index: AQHXiW/D5aIXC0jIjUWmxkQskylezqtri3cAgAAnYYCAAKvYRoAAq1yAgAAxrC8= Date: Tue, 10 Aug 2021 20:35:45 +0000 Message-ID: <5475E357-6F94-427D-8875-D88269A76F8F@cisco.com> References: <26245.1628534920@localhost>, <9A1DA017-AF66-4349-B070-57A4BC28A48A@cisco.com>, <11220.1628617079@localhost> In-Reply-To: <11220.1628617079@localhost> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 89822d8a-b8d5-46c3-9d68-08d95c3e6e92 x-ms-traffictypediagnostic: MWHPR11MB1840: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: aF9L0iwm0A4FjzjRESGG6Nds6Q42BxZbcXpZQcZyrcju/OFt09OBE1n6qzGUKO+USHy/qARUuy5u060Yvr+rF/GItFYmDccKhtCyKwYLkljNE7I3h135l6kI9rxJq7xIjGUgFYO5dJ/E7SxP8+BPt31JZZhSH1nMjOJBTpkpIgMqLjW16Mzkij9jU0gjkdcVpZb7rDoOx1pJDV27KmUfY03LBBegw7YtLUZ3Wc4aGezKr7fOzlHay1ilOfQ2wyjhFo6plwgy4Ir8ZPMu9e7/5ig7Mo9xTRsfa5oTeGQM+DlBJC8NVKXuXbLbSqLFYwqr94ZSQTZhm94IXg5YFhBQdurjCyzPHP2d5TmhKALyCWknygoZK7Ymf8tPLn9dVVD3Z2BSE/m5DEz5z8UV8DnQtzhyHwxh9ZvvLmJk5bpup3gaMkHf0lH7JDqRUxGKv0xjVFmDA81VTbeB9B1ehkaYG2LfGiZin77vEHrBMHPYM/1Hpc/7zBjcsW4ozTA50tsIPBaEOA1vmnHpPM3iZnlWYKuhWWNV7/FFxsP/1Kri633DdWLeRIl44nE1ELzebDm0MpTFov07XeGkvnsuLPeFknNwOVe4EBLF9V8ILQWDzrZkEENkljUuMeQRTkHAWd5Lqoj7KGo63UblODgcmkQZohfbCdwBRo9uBR4WjWQEOM6DX8Atb924SrR4q7p2HYBZbkQIAdMiWvdCzE/kSpEYVZeIrHyb9Qkue/AlM6l2nmvRHSOUrnnAGEK63v1WHHsl 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:(376002)(396003)(136003)(346002)(366004)(39860400002)(66476007)(66556008)(316002)(36756003)(83380400001)(66446008)(64756008)(186003)(76116006)(2616005)(8676002)(66946007)(6486002)(38070700005)(91956017)(6512007)(33656002)(8936002)(86362001)(38100700002)(4326008)(6506007)(478600001)(2906002)(71200400001)(66574015)(122000001)(5660300002)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?SlBvZnJ5bnduSzhzQ2hSTHdyT2dLS1R1a0o3M1NpR0lxQnNLcU1NcU83MkJR?= =?utf-8?B?UXdRdE5lL2hMVEJYMWtaUmZvUXk0aU9FYVVRRldZS0NoWUVRODludmltQVFh?= =?utf-8?B?ak5ROFJjT0k5NkQrM09SZFNoeE53Q1JDeFdidVZPYWMrSENzRFYwRWgzcDgy?= =?utf-8?B?UmowRkgrOTM4V0Jkd0laNTFPc0lrQUFQV01UaFk2OUNzcjA0V2c2T1AwRjVx?= =?utf-8?B?RnpqT0VGTGYzb3JGbUZLeExtVDRiZ2lwOUhJVjlsMDFRdERpVzAyNW5wQzBY?= =?utf-8?B?ZUNQRTU4ZW9qbXhHQmFKcUZWOTRmai9peCtuMUU2eTRzY0RvQXg4cDlkSzl1?= =?utf-8?B?TDdNQmtrTCt6SXc5aDhycFZTdzR6dXRaZDJuTnVhREY2bmZ3eXE0bDFCVzlU?= =?utf-8?B?amdpc3pwUTl3ZDlDMmFPR2hiVzVYVElKb0Q4WFVhWVpxVFpidnZ3dVBNa3Bw?= =?utf-8?B?cVF6OFhoS28wNGhsT1JTeSt1ZzlwRFdEWGxCWVM2R2xMV0dvc3F6TjcvTENE?= =?utf-8?B?VEl0cEhrcGtTVW5WYVc5eE1lM1lLbVZtbEk2QlhLMVVPM3N4V0kybjRGcjk3?= =?utf-8?B?N0gyeU5OejRVaVRrZUEybnFLS2d5dVpLVDB0SVc3TjZZMnFoOGtsdWxWU0VH?= =?utf-8?B?bUlKbDNyM29TZ251c3BISzNicFFLM2t3eHR5eDkreVVnb3A4Yzk3SEZ0R0pw?= =?utf-8?B?N055Rklma0RjSjZYTDU5YTdmeW0wdHVHeDhOMkl5ZjE1YmxWbFJZYVZOWWl6?= =?utf-8?B?R05xcDZLdTcrdkpTc0doTFB4YTBFQnNVait1MW5WQXliNkZIemloWjcxMnN4?= =?utf-8?B?RmpLNXR4NEJuMCthQyttc0xSUHhxd3BRYnBRbUdzQk53Y0VYdTd5QWxOYzJk?= =?utf-8?B?Qi9PYUNicmxHU2tockFFdVhCVXhLWE5XWFVkUVh6MGY2SUlYakNqeDFQbjZS?= =?utf-8?B?b01ZVmtycWR5UWYxTVhWZ0VWcXFQWjBEeTVjcEwwVmM3NDd2bUpIR21ZR1Qr?= =?utf-8?B?YTNHZmVMV3FGdzZSVzRlOVNHd0NoN01jUUdrUllabmgzQlkzOExUZ2Vhc1gz?= =?utf-8?B?MHVnWjAreGszSlo3ckRTYWVHM0t4U2xxVDlhUzdLM2Z5d2I4bEE5blNaY3l4?= =?utf-8?B?WE1DR3pRUG93Uno5M2JpQzZtUVMxKzMwbHBSZTRFRnl4UGp6bm9EQ05GcTIw?= =?utf-8?B?VTZxR1l0OGhxRDN5cU1OZE9vNlA2dVMxU0JzdjVxSXZmY1kxTERZMVlRNG5u?= =?utf-8?B?dVd6WWoyQW9icFFHMmFmUmpGazNXVkg2djc1aHdwcG9kOXRMOHluUzR6a212?= =?utf-8?B?d3hEZCtOaVJQaVloTUVRZzRBalhkb2VCWFVYK2k5b0FJcU5xZlFTNysyR3JV?= =?utf-8?B?Nm5rWElCVDEvbGxRdXBPVE5XYy9GSlJBNGkyRXV2ZXZiS2t2OG9DNWkvbUd2?= =?utf-8?B?cklnUlZsR3JQYXBzTEdWYTM1N3NtMCt5cmhsdUpxa2dzVXdjVzNDelNhUnZm?= =?utf-8?B?V3JwaXVqVmtwWXVIdDdSTXM0cWhRd2JVQkVXWS8ycndDRmhlK3hiU2I0dFQ4?= =?utf-8?B?MzI3bGVjTGpSRWlsdllyMTZ3NmlDd0RlenhNbERKTWRnWkk1S2lvV3MvZHBu?= =?utf-8?B?bG85cWJNQkM0Wmw0dHdxMWFIRW5sRWI3YnhiQjhjank1OG5wVmNBRlRuR09E?= =?utf-8?B?L1JiVnJPRmlZZjdBTkFaREZ0OFFhempJVUlxYzQ2TmNINlo3cmJVeXNKTERk?= =?utf-8?B?bTNTL1Mxa3BwVnN6U281dkVMWXl0QzFCL3gvUnVQaDg2TjJtRUtaVWpLbmFt?= =?utf-8?B?MkprTHRRcWJOZHplMGdEa3lsTWJEc0w4R2FHNUZkOXkrSXpucHNSRm9mb3JW?= =?utf-8?Q?EkpCGSipV5vxZ?= 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: 89822d8a-b8d5-46c3-9d68-08d95c3e6e92 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Aug 2021 20:35:46.0056 (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: 5hZyiSfplgrcgaj+f8KztJycsFvISXgYlc/8+JBB+XGUJ8s/ChzU9WDD2+DTZoDh/VsZN/ndXMqDThD/Ij6MLw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1840 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.20, xbe-aln-005.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [Roll] Review of draft-ietf-roll-enrollment-priority-04 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, 10 Aug 2021 20:36:03 -0000 DQoNCj4gTGUgMTAgYW/Du3QgMjAyMSDDoCAxOTo0MiwgTWljaGFlbCBSaWNoYXJkc29uIDxtY3Ir aWV0ZkBzYW5kZWxtYW4uY2E+IGEgw6ljcml0IDoNCj4gDQo+IO+7vw0KPiBQYXNjYWwgVGh1YmVy dCAocHRodWJlcnQpIDxwdGh1YmVydEBjaXNjby5jb20+IHdyb3RlOg0KPj4gTWF5YmUgdGhlIHN1 Z2dlc3Rpb24gd2FzIHJlYWxseSB0byByZXN5bmMgdGhlIERBRyB0byBhIG5ldyB2ZXJzaW9uIHRo YXQNCj4+IHdvdWxkIG9wZXJhdGUgd2l0aCB0aGUgbmV3IG1pbmltdW0/DQo+IA0KPj4gVGhhdOKA mXMgYWN0dWFsbHkgbm90IGEgY29udmluY2luZyBpZGVhIGVpdGhlciwgc2luY2UgdGhlIG1pbmlt dW0gdmFsdWUNCj4+IG9mIHByaW9yaXR5IGlzIG5vdCBjb25maWd1cmVkIGJ1dCBhIER5bmFtaWMg Y29tcHV0YXRpb24gdGhhdCBtYXkgY2hhbmdlDQo+PiBhIGxvdCBtb3N0bHkgZHVyaW5nIHRoZSBE T0RBRyBmb3JtYXRpb24uDQo+IA0KPiBJIGd1ZXNzIHRoYXQgdGhpcyBpcyBtb3JlIGR5bmFtaWMg dGhhbiB0aGUgY2FwYWJpbGl0aWVzIGFuZCB0aGUgbGlrZS4NCj4gDQo+IEZpcnN0IGlkZWE6IGl0 IGRvZXMgbm90IGJlbG9uZyBpbiBESU8sIGJ1dCBzaG91bGQgYmUgc29tZSBuZXcgZHluYW1pYw0K PiBjb25maWd1cmF0aW9uIG1lc3NhZ2UuICAgVGhlIENhcGFiaWxpdGllcyBkbyB0aGlzLg0KPiBC dXQsIHRoaXMgcmVxdWlyZXMgYW5vdGhlciAoYnJvYWRjYXN0L211bHRpY2FzdCkgVFhvcCwgYW5k IHNvIHJlYWxseSB3ZQ0KPiByZWFsbHkgd2FudCBpdCBhcyBwYXJ0IG9mIHRoZSBESU8sIEkgdGhp bmsuDQo+IA0KPiBPbmUgdGhvdWdodCBpcyB0aGF0IHllcywgaXQgbmVlZHMgdG8gYmUgaW4gdGhl IERJTywgYnV0IHRoYXQgaXQgc2hvdWxkIGJlIGENCj4gY29tcG91bmQgb2JqZWN0LCBjb250YWlu aW5nIHRoZSBuZWVkZWQgbmV3IGxvbGxpcG9wIGNvdW50ZXIsIGFuZCB0aGVuIGJlDQo+IGV4dGVu c2libGUgd2l0aCBhZGRpdGlvbmFsIHN1Yi1UTFZzLiAgT3IgbWF5YmUganVzdCBmaXhlZCBzaXpl IFRWcy4NCj4gDQoNCldl4oCZcmUgZ2V0dGluZyB0aGVyZTsgdGhpcyAgaXMgYWtpbiB0byBidXQg bm90IGEgY29uZmlndXJhdGlvbiBvcHRpb247ICBhbiBpbmZvcm1hdGlvbmFsIG9wdGlvbiBwcm92 aWRpbmcgZGF0YSB0aGF0IG1heSBoZWxwIHRoZSBuZXR3b3JrIHNlbGYgbWFuYWdl4oCmDQoNCg0K PiAtLQ0KPiBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1hbi5jYT4gICAuIG8g TyAoIElQdjYgScO4VCBjb25zdWx0aW5nICkNCj4gICAgICAgICAgIFNhbmRlbG1hbiBTb2Z0d2Fy ZSBXb3JrcyBJbmMsIE90dGF3YSBhbmQgV29ybGR3aWRlDQo+IA0KPiANCj4gDQo+IA0K From nobody Tue Aug 10 13:45: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 803813A1BC9 for ; Tue, 10 Aug 2021 13:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=iZ0fhspN; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=xVuCtFei 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 NLI2djC7SeJ5 for ; Tue, 10 Aug 2021 13:45:48 -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 D63FC3A1BC5 for ; Tue, 10 Aug 2021 13:45:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3268; q=dns/txt; s=iport; t=1628628347; x=1629837947; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=9naWK0Fzty79/D0ve+mgY1kbZyXf79bylcMYFmxP1VM=; b=iZ0fhspN/GSmj9wkvYH3K8JB2X9JXZUE242qkEBlW2QR9ZfmSg57vcKh BtNCCl3QPqo9gpbXiuB41o7c2m/vhbjGgbLiyBb9eK5AwvAmyJQ8t1T1h RFn/7+AleSnlVIxjKjhQeZ9SoisUZSA4MIMG2YZnNEWjoov/awZJIZEN5 8=; IronPort-PHdr: =?us-ascii?q?A9a23=3AY4uddh8fFuwc//9uWDnoyV9kXcBvk7T5IgBT7?= =?us-ascii?q?YAo2PpCcaWmqpLlOkGXpfBgl0TAUoiT7fVYw/HXvKbtVS1lg96BvXkOfYYKW?= =?us-ascii?q?0oDjsMbzA0tHMDDDlf0f7bmaiUgF5FEU1lot3iwLUlSHpP4YFvf6n2/5DIfA?= =?us-ascii?q?FPxLw1wc+/0AYXVyc+w0rPaxg=3D=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3A2xwzxqCfCbtjr7flHegNsceALOsnbusQ8z?= =?us-ascii?q?AXPh9KKCC9I/b3qynxppsmPEfP+UossQIb6K+90c67MDLhHP9OkMcs1NKZPD?= =?us-ascii?q?UO11HYVL2KgbGSpgEIXheOi9K1tp0QM5SWaueAdmSS5PySiGLTfrpQo6jkzE?= =?us-ascii?q?nrv5al854Hd3AMV0gU1XYBNu/tKDwReOApP+tcKLOsou584xawc3Ueacq2Ql?= =?us-ascii?q?MfWfLYmtHNnJX6JTYbGh8O8mC1/HCVwY+/NyLd8gYVUjtJz7tn23PCiRbF6q?= =?us-ascii?q?KqtOz+4gPA1lXU849dlLLau5l+7Y23+40owwfX+0GVjbdaKvu/VfcO0biSAW?= =?us-ascii?q?MR4Z3xStEbTpxOAj3qDzqISFDWqnfdOX4Vmg7fIBmj8CHeSQiTfkNnNyKH7r?= =?us-ascii?q?gpLycxonBQzO1UweZF2XmUuIFQCg6FlCPh58LQXxUvjUasp2E++NRjxUC3fL?= =?us-ascii?q?FuIIO5l7Zvt3+90a1waB7S+cQiCq1jHcvc7PFZfReTaG3YpHBmxJipUm4oFh?= =?us-ascii?q?mLT0AesojNugIm0ExR3g8d3ogSj30A/JUyR91N4PnFKL1hkPVLQtUNZaxwCe?= =?us-ascii?q?8dSY+8C3DLQxjLLGWOSG6XWZ0vKjbIsdr68b817OaldNgBy4Yzgo3IVBdCuW?= =?us-ascii?q?s7ayvVeISzNV1wg2bwqUCGLHvQI+1llupEU4zHNc3W2He4OSMTeuOb0oAiPv?= =?us-ascii?q?E=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DvCQDl5BJh/5ldJa1aHgEBCxIMQIF?= =?us-ascii?q?OC4FTKSgHd1o3MYRHg0gDhTmIZwOaNYEuFIERA1QLAQEBDQEBKgsMBAEBgWO?= =?us-ascii?q?CdQIXgksCJTUIDgECBAEBARIBAQUBAQECAQYEgREThWgNhkIBAQEBAgEBARA?= =?us-ascii?q?REQwBASwMBAsCAQgYAgImAgICJQsVEAIEEyKCTwEogi0DDiEBDp0GAYE6Aoo?= =?us-ascii?q?feoExgQGCBwEBBgQEglGCRhiCNAmBECqCfIQPhmQnHIFJRIEVJwwQVIIOPoI?= =?us-ascii?q?EXgEBgUcZgxc2gi6CeFsGaFIBIjmBOJVfqCEKgyieSwUmpm+FObVxAgQCBAU?= =?us-ascii?q?CDgEBBoFiAjeBWXAVOyoBgj4JRxkOjh+BJQEHCAeBYVSFFIVKczgCBgEKAQE?= =?us-ascii?q?DCYh4AQE?= X-IronPort-AV: E=Sophos;i="5.84,310,1620691200"; d="scan'208";a="909318068" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Aug 2021 20:45:46 +0000 Received: from mail.cisco.com (xbe-rcd-006.cisco.com [173.37.102.21]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 17AKjkrL005659 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for ; Tue, 10 Aug 2021 20:45:46 GMT Received: from xfe-aln-004.cisco.com (173.37.135.124) by xbe-rcd-006.cisco.com (173.37.102.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 10 Aug 2021 15:45:46 -0500 Received: from xfe-rcd-003.cisco.com (173.37.227.251) 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.15; Tue, 10 Aug 2021 15:45:45 -0500 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-003.cisco.com (173.37.227.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Tue, 10 Aug 2021 15:45:45 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aROMHS9Ie/Rj6HuNM5Y3evmko9vl6FUz4s7awhjnNIlchp2ya2XaKrwWDQt6kPrh6xB2nomLdSWnDFY2jrN0QGAMCkWELi5UXIvgBteCKE+h6ReQzDUxDe4QcDcXue9DpHAGDpemkCqZRJXdJIJGvB9mTysBOimnOoTNIv6CStIHKpew2H7CH6O6j1ViEmLEWRc+tHkPcKSXvYhO8OTI5alz66LjhjwgodnRHAjiPww/4/kyQBADbowEWXh8VxKl2rSvh2lWA6g2ACYAdtrwVwsUZTc4+w2lbJLheQrDk46Fufw5v/JGbRln2SygbJQyV1v4fAd3Y9F4CgTWtWfgkg== 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=9naWK0Fzty79/D0ve+mgY1kbZyXf79bylcMYFmxP1VM=; b=ZK3x1JeiHHxsC7AlGCNSC5BN2/9JXHKgvmhDXfoGjxPbALz2QD/38B1PZfqFO6nRKBgClE9XWJEPEQCOcWpL/JiBMjgnXzbyl+N9LPen3UWlezNMOkVth5VfYm2XQhSpruJZLypb9vdzX0SCo/PFL0XPa9OvwodW/TSUP3ex8nMKo57z9XvOqQbE912ZsL6Q/VM7GxDZ/PyoBlgXdNZ1T/CDcxKlw/BYmnWP/ejgKWBN7xOI45bBRy4jLhCvXunuHHuRY8U8XKjHOc96v3fRCYX79eWSh2fofwbeFzX4Z98QmkddQtmtuDQulRj7U8huD8EHH0KYaHzmagbpUuHl7w== 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=9naWK0Fzty79/D0ve+mgY1kbZyXf79bylcMYFmxP1VM=; b=xVuCtFei0sGXf4Wl84IX4j2ALLVgsjKhGx/F9oQg9CIbdYnDA3Uelt5msgc53tKoP58BLaR5sYZ0zecxUQdCSnujnfU2Go6SrdrpldQpTd48JpkAyxI7OsCYVzCCSmYQY69QQuFFvm3ah00x5xp7zHlQRAqX3ysLhDBMiFMWE4E= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MW3PR11MB4587.namprd11.prod.outlook.com (2603:10b6:303:58::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4415.13; Tue, 10 Aug 2021 20:45:43 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::487e:47b8:314f:189a]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::487e:47b8:314f:189a%6]) with mapi id 15.20.4394.023; Tue, 10 Aug 2021 20:45:43 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Review of draft-ietf-roll-enrollment-priority-04 Thread-Index: AQHXiW/D5aIXC0jIjUWmxkQskylezqtri3cAgAAnYYCAAKvYRoAArIiAgAAzRzM= Date: Tue, 10 Aug 2021 20:45:42 +0000 Message-ID: <91C647AE-2197-4FC7-95DD-B2A2EC29306B@cisco.com> References: <26245.1628534920@localhost>, <9A1DA017-AF66-4349-B070-57A4BC28A48A@cisco.com>, <12297.1628617331@localhost> In-Reply-To: <12297.1628617331@localhost> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 22062dbb-b8a0-4ba7-7743-08d95c3fd252 x-ms-traffictypediagnostic: MW3PR11MB4587: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: MgpENmjWPMmVaNVKxI/cr8cy3kUhTZvnAVo4DY04LB4z0HaYOaIcKFn2C0FOfPtXvzH+2rsDa/7i+wgM2T43HnYXHMMzPIDblVhGrplpAKDFiWg6qKtrZpospeoj3qrcUgtaMAXV22vaUzhO0R2aXpWJ1Gna+VkSBgh+YzOoB2pf3jyMFcBkG1f4EZXdqW69BHhkcFkFxb49PofThV8p7Xr77Ve+Vo9EDGVy/2ihae/0KTP11r2uhNMZNTmu7l5DIihx5EmuzBht9FDYFL5ZNpfsW8y5095iibJmD9GFqiK4cfRZUfrCNZHAgaDdFDvOB8yYYbUONE069QvU36q955YzqOX5ldMDGcGCnHvi28TTSJMyeOcHTMluWDaSLvT8Nke1XO6DWfHpUagWoP9VpOtixR+Rp5L00G67dLPGnckXclKEJy5x3/ZR2HFN0r3Y3W5V8+DT/TtBtKugWw1R34NRQ8aOJs1iNvJaJp2mFxlnPCfNpQXV3IqPRy6LDjK1o0cYo9HRtOGi/95CLv9U/TRz3x4V0SQoV6wFRYM0mKiOD9JwOdgSw19AkNDmzG40bxGET0biTTGNa4NwKrQCuhRbffvsQh1PsnSbqEB20i+6i8iqOc80VJ/pa1T/EWnz6emp4ZjV4OAIgmeCdbswrkY6aC1r8oKpHZQr6Xl/B6YFgmAhiZkFP5Q5A1VDSacP3pfAE7XwKvsvj7oeAzOFv7XYJrgnBv7sKRA5OEAfWicf3T/N4XfhyBC4Bp3UQBXdN3bk82W5GWJlpht7wks3FOU4O/5SoVrWFIxUWO6EB0AdmSWr/PQtESkYDuWI2sws x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB4881.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(39860400002)(136003)(396003)(376002)(346002)(66946007)(316002)(38100700002)(66446008)(64756008)(66556008)(66476007)(38070700005)(76116006)(91956017)(122000001)(33656002)(186003)(2906002)(5660300002)(86362001)(6512007)(2616005)(71200400001)(478600001)(966005)(8936002)(6486002)(6916009)(8676002)(6506007)(36756003)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?RDhOa3Zsck1Jdk9iWG5HbVNJOU9oU2dCOTdEM3gwd1FmSXBpRzRrZGxWSyt6?= =?utf-8?B?aWUxQUdUWkpWenc3N0FvcnpXdjFJdEhaNFpHU3pPcXcrZUMwMFF1UGt4aHpn?= =?utf-8?B?dnZIWEVKaHRlSHRVK3VoOUZVYnB3QVNaS0xhajZDdzhqQk1lVkhza0pwbHFy?= =?utf-8?B?Ni9ta3NSWE1VWFBJWk1jOVk0UzNpMG5xYUplQkhyNUZHZGpQNjV4VlZLSXN4?= =?utf-8?B?SkwrQ0ZVNm90VkEwblVQRDNQOWRnVXZOeTZtaXQ4RVc0RXQ0ZzJIb3N2elBP?= =?utf-8?B?NGJNSkduSzkvK1Y1ZjQ4UTBQWjlOMnY3TFF2TlhHY2xHSEdoeDdlVTNFUFRl?= =?utf-8?B?SHJzL0tIWVVEL2F2TSt4MW5pOUl4SkpQT1dTamJUUE5JYnRJc3R4UHBPSExR?= =?utf-8?B?akM2UXo4b2l3Z1k3aXJ3K2dFNWx1bm54bUs4Rzk4TXZKbE1XYVREaU1Gc0hM?= =?utf-8?B?cGhxSG1EV0p5aDMwZmtCTHNmY1U4d1VzY0FtKzBkRDhBOVdmZisrZkx4aHdT?= =?utf-8?B?aXVBaSs4ekJyYWdCZ3lPT1dSMlZobm5KeWM1cXRLWFF1SC91Ly8xdldHRnhK?= =?utf-8?B?c1Mzc1UvZVhWRmRScTFqeFR1TDhHTHZHTDR4dXJVeURLLzVVS1B5THlmZWFq?= =?utf-8?B?Tk5OWDg5a0tuNzRuTVgyUVptTnRaVWpBdk9PQVQrS0NKQkZHNElWemxGU0x6?= =?utf-8?B?bFpWL0wxVlFsNGVDTlU2QXJwRkZlR3NNZ0xaSm1iYWp5RkVyTGJ2cmNzMzlj?= =?utf-8?B?N05QMjlKOEN5d1pUU0ZZdkU4OWNuMkY1SjV1aWlQZTNuY0dWdlE5UXdHV3l5?= =?utf-8?B?bGdQZ1g3UXdBbVVmZE5xMW1aRUVZQ1ZkelZsa21uQU1CSFB1VXdlaUEwK1Bw?= =?utf-8?B?TytLdlExQ203dEVwSGlhdUdXRGo4MHhHUitzeXJNR2dXbjIrUjlZRmZGUkha?= =?utf-8?B?aHFoRWJtVG94WkdvRkVXNlFETEkzQzltVUljRERybGtIVjFpZlFlZC9LcldM?= =?utf-8?B?d0FXc25CY3JZOFAwSnFDL1NqMmNKWGZKU2dDbXcrWEMzcjJEKzhCcGxHdTdC?= =?utf-8?B?MXgyNDArMERiQXJ0SVd5d3FPNGZ6MzA0V3l3YUNYaDI4MUoyaHM0YlNpWVRY?= =?utf-8?B?MGhrVE9IajdZelc0bGlnbXNNRUVMZXlPaG9LZ0xnbUxVLzh6NVpIeTJ2SSs5?= =?utf-8?B?bGY5SnB6bjdGMDJDMXprQjhjSjY4SVZsb2xDdktiRmw0cVZiQ0FJM1E0MitG?= =?utf-8?B?T0VmQmRER0RsNE9SOVBDN21PbGhvbWEzUWJweFNVcENUb21xK210d1dkWmp6?= =?utf-8?B?TTZidlE2TmM5UW96T3ZHRlVpWm56RHZ6YnUrRGthT1NRZGJiT1VkQUZWZDJM?= =?utf-8?B?c0hMYmJTOER4R2Y4a3pHWVNJdVpBbzZNVGY2MUc1TDVBSHNZR1F1cTRsTzUw?= =?utf-8?B?SFRTaHZ5cXZWcUtYMnJucTJSaEN4OHJDZWhnR2lldjQ3UlZ5WVNkQzg0QVBl?= =?utf-8?B?NUQ0YUt6R0pqUTZ5NHBJVWRPL2o2WG5DN3QrbzZJZ1VWSnRYUmxtY1RJVTMy?= =?utf-8?B?WllveTYvSzUzeHY0VzZHMkFqN1l5Z2daYldab0xqTkI0cUM4YWt4czVycjhS?= =?utf-8?B?ekN3U0swT3ZtdnZwR3VmNWxtNlBlcWxtaEtQZkVnT1o1T0hzeWEyKzFtODVl?= =?utf-8?B?eVBSQ2lTOEgva3BGNTRCRm40YVpXQmhlMy95SUU1MVd1WGhxUXBvNXJpTllB?= =?utf-8?B?YzN0RkowMDFZaXJwS2hCaHpwZ0p2Q29JNytJekdhSktPV3FwUU5WdEZrTXBT?= =?utf-8?B?emg4QTVML3pmOWVYNjRiK01HYnpWNlZ0QkdVUFdRR1VrbjY3ZEMyOFpVZDdW?= =?utf-8?Q?92DR4DsHVwd1R?= 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: 22062dbb-b8a0-4ba7-7743-08d95c3fd252 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Aug 2021 20:45:42.8322 (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: UX5f7lmDQAyIG8wrUIdSFA6zy9Y48qw5t49simxnxEOJGauXru7Xst5Xf4A4bBpn7LLbYkutYzHdyBE5JshEog== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4587 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.21, xbe-rcd-006.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [Roll] Review of draft-ietf-roll-enrollment-priority-04 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, 10 Aug 2021 20:45:54 -0000 DQo+IExlIDEwIGFvw7t0IDIwMjEgw6AgMTk6NDIsIE1pY2hhZWwgUmljaGFyZHNvbiA8bWNyK2ll dGZAc2FuZGVsbWFuLmNhPiBhIMOpY3JpdCA6DQo+IA0KPiDvu78NCj4gUGFzY2FsIFRodWJlcnQg KHB0aHViZXJ0KSA8cHRodWJlcnRAY2lzY28uY29tPiB3cm90ZToNCj4+PiAzLiBFdmVuIGlmIHRo ZSB0aGlzIGFwcHJvYWNoIHdlcmUgY292ZXJlZCBpbiB0aGUgZHJhZnQsIGl0IHN0aWxsIGhhcw0K Pj4+IHNvbWUgaXNzdWVzLCB3aGljaCBJIHdhcyBhYm91dCB0byBleHBsYWluIGJ1dCB0aGUgbmV3 IHZlcnNpb24gb2YgdGhlDQo+Pj4gZHJhZnQgYXBwZWFyZWQuDQo+IA0KPj4gWWVzIHdlIG5lZWQg dG8gc3luYy4gSSB0aGluayBNaWNoYWVsIHN0aWxsIGhhcyBpbiBtaW5kIHRoYXQgdGhlIG1pbmlt dW0NCj4+IGlzIGluY3JlbWVudGVkIGRvd24uIFRoYXQgd2FzIHRoZSBpbml0aWFsIGlkZWEuDQo+ IA0KPiBTbyB0aGVyZSBhcmUgdGhyZWUgcG9zc2libGUgdGhpbmdzLCBJIHRoaW5rOg0KPiAxKSBy b290IGV4cHJlc3NlcyBjb25zdGFudCB0byBlbnRpcmUgRE9EQUcNCj4gICBlYWNoIDZMTiBleHBy ZXNzZXMgaXQncyBsb2NhbCBpbmNyZW1lbnQNCj4gDQo+IDIpIHJvb3QgZXhwcmVzc2VzIGJhc2Ug dmFsdWUsIDZMTnMgaW5jcmVtZW50IGl0DQo+IA0KPiAzKSByb290IGV4cHJlc3NlcyBiYXNlIHZh bHVlLCA2TE5zIGluY3JlbWVudCBvciBkZWNyZW1lbnQgaXQNCj4gDQo+IEkgY2FuJ3Qgc2VlIGEg c2l0dWF0aW9uIHdoZXJlIHRoZXJlIGlzIGEgbmVlZCB0byBkZWNyZW1lbnQgaXQuDQo+IElzIHRo ZXJlIHNvbWVvbmUgd2hvIGhhcyBhIHVzZSBjYXNlIHRoYXQgbmVlZHMgdGhhdD8NCj4gDQo+IEkg dGhvdWdodCB0aGF0ICgyKSB3YXMgc2ltcGxlc3QgaW4gdGVybXMgb2YgY29kZS4NCg0KSXTigJlz IG5vdCB0aGF0IHNpbXBsZSBzaW5jZSBhIG5vZGUgY2Fubm90IGluZmVyIHdoYXQgdGhlIHZhbHVl IHJlYWxseSBtZWFucy4NCg0KV2l0aCAxKSBwbHVzIGEgc2VxdWVuY2UsIHRoZSB2YWx1ZSBoYXMg YSBnbG9iYWwgbWVhbmluZyBhbmQgdGhlIG1vc3QgcmVjZW50IHZhbHVlIGlzIHRoZSB0cnV0aC4g Tm9kZXMgY2FuIHRha2UgYSBzYW1lIGxvZ2ljYWwgZGVjaXNpb24gcmVnYXJkbGVzcyBvZiB0aGVp ciBsb2NhdGlvbiBpbiB0aGUgbmV0d29yaywgZWcganVtcCBvbnRvIGFub3RoZXIgZGlzYWdncmVn YXRpb24gdG8gcmViYWxhbmNlLiANCg0KV2l0aCAyKSBkaWZmZXJlbnQgcGFyZW50cyBtYXkgZ2l2 ZSBkaWZmZXJlbnQgdmFsdWVzIGZvciB0aGUgc2FtZSBzZXF1ZW5jZS4gV2hpY2ggc2hvdWxkIG91 ciBub2RlIHBpY2s/IFRoZSBvbmUgZnJvbSB0aGUgcHJlZmVycmVkIHBhcmVudD8gT3Igc2hvdWxk IHRoZSBub2RlIHJlcGFyZW50IHRvIHRoZSBiZXN0IG9mZmVyPyBUaGVyZeKAmXMgY29tcGxleGl0 eSBhbmQgY29uc2VxdWVuY2VzIHRvIHRoYXQgZGVjaXNpb24gb2YgcGlja2luZyBvbmUgdmFsdWUu IEFuZCB0aGVuIG5vIHdheSB0byBrbm93IHRoZSBhYnN0cmFjdCBkZXNpcmFiaWxpdHkgb2YgdGhl IG5leHQgZG9kYWcgc2luY2UgdGhlIHZhbHVlIGZyb20gdGhlIHJvb3QgaXMgbG9zdC4gDQoNCg0K DQo+IEEgY2hhbmdlIHRvIHRoZSBtaW5pbXVtIHByaW9yaXR5IHNob3VsZCBub3QgcmVzZXQgdHJp Y2tsZSBvciBjYXVzZSBuZXcgRElPcw0KPiBpbiBteSBvcGluaW9uLg0KPiANCj4+IEFuZCBteSBk cmFmdCBvbiB2ZXJzaW9uaW5nIHRoZSBjb25maWd1cmF0aW9uIGlzIGFsc28gc29tZXRoaW5nIGVs c2UuIFdlDQo+PiBuZWVkIGEgbmV3IHNlcXVlbmNlIGVpdGhlciBpbiB0aGlzIG9wdGlvbiBvciBn bG9iYWwgdG8gYWxsIGZ1dHVyZQ0KPj4gc3RhdHVzIG9wdGlvbnMgZnJvbSB0aGUgcm9vdC4gVGhh dCBzZXF1ZW5jZSB3b3VsZCBub3QgYWx0ZXIgdGhlIFJQTA0KPj4gb3BlcmF0aW9uIGFzIHZlcnNp b24gYW5kIERUU04gZG8uDQo+IA0KPiBJbiB0aGUgZW5kLCBJIGFncmVlLg0KPiANCj4gDQo+IC0t DQo+IF0gICAgICAgICAgICAgICBOZXZlciB0ZWxsIG1lIHRoZSBvZGRzISAgICAgICAgICAgICAg ICAgfCBpcHY2IG1lc2ggbmV0d29ya3MgWw0KPiBdICAgTWljaGFlbCBSaWNoYXJkc29uLCBTYW5k ZWxtYW4gU29mdHdhcmUgV29ya3MgICAgICAgIHwgICAgSW9UIGFyY2hpdGVjdCAgIFsNCj4gXSAg ICAgbWNyQHNhbmRlbG1hbi5jYSAgaHR0cDovL3d3dy5zYW5kZWxtYW4uY2EvICAgICAgICB8ICAg cnVieSBvbiByYWlscyAgICBbDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gUm9sbCBtYWlsaW5nIGxpc3QNCj4gUm9sbEBpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCg== From nobody Tue Aug 10 14:01: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 B3C003A1C2F for ; Tue, 10 Aug 2021 14:01:11 -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 bG-p1nsd5DJd for ; Tue, 10 Aug 2021 14:01:06 -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 EBED63A1C20 for ; Tue, 10 Aug 2021 14:01:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by duch.mimuw.edu.pl (Postfix) with ESMTP id 4662A61D86097; Tue, 10 Aug 2021 23:01:01 +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 ZEBhBuLBv4iF; Tue, 10 Aug 2021 23:00:59 +0200 (CEST) Received: from Konrads-MacBook-Pro.local (unknown [IPv6:2a02:a311:813e:880:a80c:6cf2:ae9e:13c]) (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; Tue, 10 Aug 2021 23:00:59 +0200 (CEST) To: Routing Over Low power and Lossy networks , "Pascal Thubert (pthubert)" References: <26245.1628534920@localhost> <9A1DA017-AF66-4349-B070-57A4BC28A48A@cisco.com> <12297.1628617331@localhost> <91C647AE-2197-4FC7-95DD-B2A2EC29306B@cisco.com> From: Konrad Iwanicki Message-ID: Date: Tue, 10 Aug 2021 23:00:58 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <91C647AE-2197-4FC7-95DD-B2A2EC29306B@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Roll] Review of draft-ietf-roll-enrollment-priority-04 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, 10 Aug 2021 21:01:13 -0000 Hi Pascal, On 10/08/2021 22:45, Pascal Thubert (pthubert) wrote: >> Le 10 août 2021 à 19:42, Michael Richardson a écrit : >> Pascal Thubert (pthubert) wrote: >>>> 3. Even if the this approach were covered in the draft, it still has >>>> some issues, which I was about to explain but the new version of the >>>> draft appeared. >> >>> Yes we need to sync. I think Michael still has in mind that the minimum >>> is incremented down. That was the initial idea. >> >> So there are three possible things, I think: >> 1) root expresses constant to entire DODAG >> each 6LN expresses it's local increment >> >> 2) root expresses base value, 6LNs increment it >> >> 3) root expresses base value, 6LNs increment or decrement it >> >> I can't see a situation where there is a need to decrement it. >> Is there someone who has a use case that needs that? >> >> I thought that (2) was simplest in terms of code. > > It’s not that simple since a node cannot infer what the value really means. > > With 1) plus a sequence, the value has a global meaning and the most recent value is the truth. Nodes can take a same logical decision regardless of their location in the network, eg jump onto another disaggregation to rebalance. > > With 2) different parents may give different values for the same sequence. Which should our node pick? The one from the preferred parent? Or should the node reparent to the best offer? There’s complexity and consequences to that decision of picking one value. And then no way to know the abstract desirability of the next dodag since the value from the root is lost. Let me reply with the issues and a possible way of addressing some of them in the e-mail I have already been writing for a while. Best, -- - Konrad Iwanicki. From nobody Tue Aug 10 17:25:58 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 BBC4B3A232F for ; Tue, 10 Aug 2021 17:25:56 -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 3hgzsg5V4p9Z for ; Tue, 10 Aug 2021 17:25:51 -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 DF2893A232C for ; Tue, 10 Aug 2021 17:25:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id EA672389CD for ; Tue, 10 Aug 2021 20:30:26 -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 rDiNiiuIwRwf for ; Tue, 10 Aug 2021 20:30:21 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7F99A389CC for ; Tue, 10 Aug 2021 20:30:21 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3DA4A53 for ; Tue, 10 Aug 2021 20:25:42 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: <91C647AE-2197-4FC7-95DD-B2A2EC29306B@cisco.com> References: <26245.1628534920@localhost>, <9A1DA017-AF66-4349-B070-57A4BC28A48A@cisco.com>, <12297.1628617331@localhost> <91C647AE-2197-4FC7-95DD-B2A2EC29306B@cisco.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] Review of draft-ietf-roll-enrollment-priority-04 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, 11 Aug 2021 00:25:57 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Pascal Thubert \(pthubert\) wrote: > With 2) different parents may give different values for the same > sequence. Which should our node pick? The one from the preferred > parent? Or should the node reparent to the best offer? There=E2=80=99s > complexity and consequences to that decision of picking one value. And > then no way to know the abstract desirability of the next dodag since > the value from the root is lost. A node should only care about the value from the preferred parent. These values should never affect parent selection, but just be about other nodes either enrolling, or joining this PANID. So I don't understand what you write. =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+93Q3WUFAmETGQUACgkQgItw+93Q 3WXdJQf/efASlmOw+knkYeRrDGE83Zw71Cd82y45wMU4hde5ez6RwJLhbowxhT6F hnHHwRHqLRgDFzhsB2QQVTVY2c97AT6jneozUEM3TFcF/g3Y3q6mISNstV6WuXfH VgcymQFS7jArYWSN0eNcBrYII6kISIwI5jsBSdzOxEPcCKLRcIhZOaMgHRdzX5jR CKQUcUeJx7emohz6nK0OeW/9HzhQXOXrB6GzDciq/koDOeInPswr/ytRrR/RpHzu ElJry3o1hW3JZscyVJY4VqYUyXlz1Exbzwbn+UK+j//GcZrCLdJr6+UEQriS3etL YdW9A+idos7G4fESjQUR3u3LDc4O/g== =pPks -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 10 17:51:53 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 4109D3A07EE for ; Tue, 10 Aug 2021 17:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=PcAidiDH; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=0mqr4Lkb 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 NLM4LUHC3f7n for ; Tue, 10 Aug 2021 17:51:46 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 760303A07E6 for ; Tue, 10 Aug 2021 17:51:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3450; q=dns/txt; s=iport; t=1628643106; x=1629852706; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=fptQJRV4jLbWTBWA3bmK9JFB4pMSYGKXWwm3SVxgwPU=; b=PcAidiDHe480QRVyW2Ze9zd8esFJymsU15jYvfZo018jXU0/OTxzz4zZ vbxGIg2CpOfRhfB52s7NUVm49j2GYgZq38jLkFrFP/kd+z3j7qhlEFZnd BvBcVaNHeAWZ5w0relnFMEe7LmJcwkvgfFxMtrBddu/VwzVEDEM84CBSs I=; X-IPAS-Result: =?us-ascii?q?A0DnAgAMHhNhl4oNJK1aHgEBCxIMQIFOC4FTKSh+Wjcxh?= =?us-ascii?q?EeDSAOFOYhmA5o1gS6BJQNUCwEBAQ0BASoLDAQBAYFjgnUCF4JMAiU2Bw4BA?= =?us-ascii?q?gQBAQEBAwIDAQEBAQUBAQUBAQECAQYEFAEBAQEBAQEBgQiFaA2GQgEBAQECA?= =?us-ascii?q?QEBEBERDAEBLAwECwIBCBgCAiYCAgIlCxUQAgQTIoIESwGCVQMOIQEOnTYBg?= =?us-ascii?q?ToCih96gTGBAYIHAQEGBASCUYJKGII0AwaBECqCfIJyU0qGZCccgUlEgTwcV?= =?us-ascii?q?IIOPoJiAQEChHU2gi6DXmhTIjkgbStnlHioIQqDKJ5LBSamb4U5sGqFBwIEA?= =?us-ascii?q?gQFAg4BAQaBZgEygVtwFTsqAYI+UBkOjh8ZgQwBBwgHgjWFFIVKcwI2AgYBC?= =?us-ascii?q?gEBAwmIeAEB?= IronPort-PHdr: A9a23:O63nzBGcsUO7Um+3+qV/F51GfjoY04WdBeZdwpsql7wIdb6srNzuP 03asPNqilKBHYDW8OlNhOeetaf8EXcB7pCMvDFnEtRMWhYJhN9Qk1kmB8iIWkz2MPCsaDY1T 4xOUVZ/9CS9Nk5YUM/1e1zVpCi06jgfUhXyPAZ4PKL7AInX2s+2zOu1vZbUZlYguQ== IronPort-HdrOrdr: A9a23:p2RYoawvbo3eUfwvH/khKrPxjeskLtp133Aq2lEZdPULSK2lfp GV8sjziyWatN9IYgBdpTnyAtj+fZq6z+813WBxB8btYOCCgguVxe5ZnPPfKlHbakjDH6tmpN pdmstFeZ3N5DpB/L3HCWCDer5KqrTqgcPY59s2jU0dNz2CAJsQiDuRfzzra3GeMzM2Y6bReq DsgvZvln6FQzA6f867Dn4KU6zovNvQjq/rZhYAGloO9BSOpSnA0s+4LzGomjMlFx9fy7Yr9m bI1ybj4L+4jv29whjAk0fO8pVtnsf7wNcrPr3PtiFVEESotu+bXvUnZ1SwhkFynAhp0idyrD D4mWZlAy200QKIQoj6m2q35+Cq6kdR15ar8y7ovZKkm72ieNr/YPAx2b6wtXDimhcdVZhHod J29nPcuJxNARzamiPho9DOShFxj0Kx5WEviOgJkhVkIMEjgZJq3MQiFXluYdw99ePBmfQaOf grCNuZ6OddcFucYXyctm5zwMa0VnB2GhudWEANtsGczjATxRlCvgcl7d1amm1F+IM2SpFC6e iBOqN0lKtWRstTaa5mHu8OTca+F2SISxPRN2CZJ0jhCcg8Sj/wgo+y5K9w6PCheZQOwpd3kJ PdUElAvWp3YE7qAd3m5uwDzvkMehTKYd3J8LAQ23FUgMyPeFPbC1z1dLl1qbrSnxw2OLyvZ8 qO X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.84,311,1620691200"; d="scan'208";a="736872725" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Aug 2021 00:51:45 +0000 Received: from mail.cisco.com (xbe-aln-001.cisco.com [173.36.7.16]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 17B0piTK024061 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for ; Wed, 11 Aug 2021 00:51:44 GMT Received: from xfe-rcd-005.cisco.com (173.37.227.253) by xbe-aln-001.cisco.com (173.36.7.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 10 Aug 2021 19:51:44 -0500 Received: from xfe-rcd-002.cisco.com (173.37.227.250) by xfe-rcd-005.cisco.com (173.37.227.253) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 10 Aug 2021 19:51:43 -0500 Received: from NAM12-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.15 via Frontend Transport; Tue, 10 Aug 2021 19:51:43 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hhZkLqz6Bv9TaryYCpWKmXlI5STLYeRw81jvBCZxPixTU4Hps9+MVbh5NOu5zenNPrJ3+nFdwKr4XpGxZDazmOk4C73uQYC4+NENMlwX9P3kqeV0xdGGWECKT5paE9wIkYIcSZFPo0EadHsiRlBm6HeOz60acgxXRi8NHaroPwyDgEZIjRqa2XuHCgZoK+xf481PObGTjsgr8Be1aLoLgEKW22PK9Y8ttXT1kSMlRLOaQixlrfrGhibRNfoDNfQ1ScA03nvMVQcoIR8ZORtMkuPkV8kvQU544IuWTHUQcLme0N5nkK5tOhDFhHdTtrH4AZ/klzPGXhe7CIqmbQTwOQ== 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=fptQJRV4jLbWTBWA3bmK9JFB4pMSYGKXWwm3SVxgwPU=; b=WZM4ihnvIVTItoDRiuyJwKniZSs4CIwZuY4j4nX8EwhJ63ePXm9CLi1Y0fjMv2EBajRcQcOQSAjvnJpxHktnZP9iGHdDgYY51FrDApk2EP8+VYF9hkWyys5a81Jg+YgmWhGFeaiSEguOyHZdz19M/i4n2VpnzvzPLaOcs1fjAFGDe4RAoeZEeiiISzAAyARbW5mHcuzndpVFz7SYe7CqDXmEIZKltGZ7hlnskXZ1pXCr18fOVs8i9UQ/SbPhMi75Hm/KG/MYYqULzIiUrjSc4jlpPXrdYPXTbcB9g9Rf8jI7Sx9HEksGDGMmbxuN4M34adDjF2YE5Qe5AWX5B/un0A== 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=fptQJRV4jLbWTBWA3bmK9JFB4pMSYGKXWwm3SVxgwPU=; b=0mqr4LkbMoakIQgoteNc5IPEBUAtKsrSRGc5fQPSugAvAM/bWxz3aflax4Pk+XxgsObcPU9AMhBOVKhMWC0sQXgTEHKmDdKyVNBtFgVU0kwymAzIe6qmEtXtkDhcs/qYMpS1ZtBKFQeE8ILhsyq1EkV7SMiW58kntPm9WZ9rbRQ= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MWHPR1101MB2367.namprd11.prod.outlook.com (2603:10b6:300:79::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.17; Wed, 11 Aug 2021 00:51:42 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::487e:47b8:314f:189a]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::487e:47b8:314f:189a%6]) with mapi id 15.20.4394.023; Wed, 11 Aug 2021 00:51:42 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Review of draft-ietf-roll-enrollment-priority-04 Thread-Index: AQHXiW/D5aIXC0jIjUWmxkQskylezqtri3cAgAAnYYCAAKvYRoAArIiAgAAzRzOAAD13AIAAB0Qm Date: Wed, 11 Aug 2021 00:51:42 +0000 Message-ID: <0F3130FC-E1A1-4C4F-AB7A-4DA619751299@cisco.com> References: <26245.1628534920@localhost>, <9A1DA017-AF66-4349-B070-57A4BC28A48A@cisco.com>, <12297.1628617331@localhost> <91C647AE-2197-4FC7-95DD-B2A2EC29306B@cisco.com>, <27800.1628641542@localhost> In-Reply-To: <27800.1628641542@localhost> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ffa6c371-030f-42ce-bf6d-08d95c622f77 x-ms-traffictypediagnostic: MWHPR1101MB2367: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6vn1ECZXF+jDAACMUkRPPXw8XHNbcqPKbdaWL4Ef5tpKxs2a0v1p1RFWCMKMN8ZanWR80BoCZdehhHhJnAw6BTNB0sslJKcMc1ggczUqiMgRUCdEbfuxxyuvSiAegF1JhlRvol52MANwmAIPbdWTSNY3ZS9YNs2LehPR6s/c4+lr2vz9pnzll9HXfw3VcXkLQ2lKORprsUc/KKkm0g11+qO/SlYOr4EYWbiakI6ulyuz3rvo/LxnTvgVy0XhhlIK3sm1cd0E47327+qIP/ls+ejTln4jQiJ4JAOVwUYEAdF5+8WFmRX/3BnknWt49aJy35ln0ZnTmgBj9H3y4pft24PYj8vXSYPiMZZQp2mtriEU5gLCDI1ZRpm8Lfb5gFPFl2DrO/HVfU1PQQcDm6MPX2WapxstfStmpphB+fjPwv+SX/+pA1WcbVf/GSe9wfuxvOp/BMWRdmxYNqAPON79hs5nfPuP98SqxlUa2TP3E9pTZ5ec8kGmvSUT5R3VeHARNwt9igkL2OfrF01R3zQFDLFB69Yq5gEnKrq6Z6tUacH7MwC7S8gZ75kb498XHQi0CGIGi/sUEUDKBrg3K25pYNQaXU4PxAFCaFUdH0mtkQ6hsBa4mGMijZarDs7Znzq16Yd4BzBVFbqc4omhXtPdEb0k9fxafTcLPNxvQ9TPsd+5qDlInLeTYRTMHrAqqOR0MG2JDY0MbJTYSzcWEBIrRpDEfF1Sq4Gxw2ZBstT3MfJkRIVxepvtw6ovYP1//E2UxruDWnUKUht5UXgc3omNlFdDItkFQjpw9YXSvlAj/1LvFp1wYU6LSD7ugy61CrGy 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:(376002)(396003)(39860400002)(346002)(366004)(136003)(8936002)(6506007)(2906002)(8676002)(66476007)(66446008)(64756008)(66556008)(36756003)(86362001)(66946007)(38070700005)(6512007)(186003)(122000001)(38100700002)(76116006)(91956017)(5660300002)(33656002)(966005)(316002)(2616005)(71200400001)(6486002)(6916009)(478600001)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?MWpSZHg5YW1UQU1wM2JkZ0RBNmFETzJ2ak5XYmpZMzM3L05uVEU0NzBadDlS?= =?utf-8?B?a3JGYm1UcHRJZGlGVmhiSklOajUvVkhacWxNcU1KSmErZHg1ZXVOdGl0MzJ4?= =?utf-8?B?SnVnOHJZOXNLL2xVek1KZ0tXek5JMDUvQTZSZkszYzV0eXBKMThaZmdUd2xN?= =?utf-8?B?ckJXL0lyR01VTHM4dy9BZG5EVzRDSmNIdk9hNWp6aFFkcUhmOGJlcGtSbE9Q?= =?utf-8?B?UFQrYkVrQXhadTVaTWp1czJkWkdvWU5Oem81dUV4WlpFS1FacWFqUEhXczFP?= =?utf-8?B?eExYNkVmMjhYNUc2YkhHRGhvNklmamJzc25FN0ZURFlsZzVrcURJeXVIV1hI?= =?utf-8?B?MHNBSERWRXYyZzdnZHUrM3J6NzVMWnRUYXhFUzQwSUswaWdXV2s2aTR0VHZM?= =?utf-8?B?UElzNnRrSFY5bUNkcXZKc0lZMVRiZUhmL3BqR2NnMHl2RExYeFgvczRNQnVD?= =?utf-8?B?aUFjMndPZEIyaUZIcG9qcDFoa3J6MmNCUzNaRHVOaHVpUitGaXZOcmVaaHMz?= =?utf-8?B?dm5vclNJRllPNERsUk5CdUpoaG9BajB5VTEvNTNqaGZ0NzNqQjRBMVRDdUNW?= =?utf-8?B?ck1lV21nbVBuOUErUUhnUkh2Nkx1V2dXdzNrUjRQbk5mbDh5c1RzV3ZIVXJs?= =?utf-8?B?ZmpCalhWTGw4aG1oVUdlSkhQc3VOMCtOV24yRUJsQTB2akgyNjBCUzM1aUtJ?= =?utf-8?B?dStGbDJneHFodEZUZnJrMHBGNmh3OVZXM1EwOThySERlZkxlOFprQ0JJaUZC?= =?utf-8?B?N0pDWDVmZGMzZkJvclRsUnAxN093S0VvU0FRR09RdWh3eGVEaElPY1p3eVNt?= =?utf-8?B?aklUV2Zaa2NJdEpVMUdqUHo1Q3hYQStIdDJlS0ZTQWJudkN2QmZCTjF2MWhK?= =?utf-8?B?VS92VU9FdmtDWnQ1Vko2S1VOdE1aOVoyTllBYWZMK29nMTBWdng5K1FYVDRp?= =?utf-8?B?WG13anFSMk9qQnhrWXh1bC9acUxyaFFPTFozZGdGSncvT1dJRzJrWkhVWnIz?= =?utf-8?B?S1ZrZjY5c25FMXpEZDk1YmY2RkZYNWsrZkN5Nk4zRUVtcWlYRzdOUWtjWGhD?= =?utf-8?B?SXE3RHBBRnAyOTBqRVIwbnJ5QTZzU2tJZElFcEx1b3ZtYm1MSU04Zm5jaFFW?= =?utf-8?B?L2kxdThaVHUySHp1TU9QTFdLSDZQR253VkJERXVMRTNUU1FKRDg1K1lTcUVL?= =?utf-8?B?TXd0WWhXalV5VDZRYUVISmFra1ZaMkNSaTlLampnWWtXWFV1SndjdjMvOWdG?= =?utf-8?B?Z0ZISFgzOXIxU3ZZZWdIbDhrTHBydzFUUEliSGh3dmcxNk8yZHFZbmU1cDNY?= =?utf-8?B?YURQdjh0TkY5eFVBY2RHR1BOYUxVZk9nYW55bXZ6bWhvUXhKdVk0eEVZSGtV?= =?utf-8?B?SVlHUVc0cWpLR2RnTi91VEJNTFZLUjYweDU1bnBFa1RVWnlPdDBmY0ZjZXl5?= =?utf-8?B?Nkl4UlpRaStGSy8yTGh2TTZXdXh2MExYUUc2c1JOZm54Lzd4M1kwcXg5blNj?= =?utf-8?B?dHV2cnU2OWF1ZzQwV2VJRTlMczl1RnRJNVI2dkpJbGU3MkJWVDF4Nlh1d00v?= =?utf-8?B?N1hWUVd5Q2gzTTlua0JCc2VnUTZLakN3MUQrMSt2N2l5d2Z2Q3BVU013Wmhl?= =?utf-8?B?bTNieUdpSzVOWnVONDBLRFRkbUNWei96NlVSMXZVQ0lqOFRaaHZFMGFEaVFU?= =?utf-8?B?ampiSUxhUEZsdzkxL2kxOFZVNXBHRGd4VitsUTJvVFNPM0NQZVdnZmRDSFZh?= =?utf-8?B?RDRIR3U2UUhxdlZmWjhhM3BuMEJ6cmZ5ZWtVL2h0L2s3S3I0UzB5WG5Jem1x?= =?utf-8?B?K1AyaHFwRFVSWlFOeGpzVUFhbkI1QXE3VWw2N1JMQXhQSWxsRHJ3V09IbUZ2?= =?utf-8?Q?txYPLsO8e9ELJ?= 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: ffa6c371-030f-42ce-bf6d-08d95c622f77 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2021 00:51:42.0273 (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: jRfVtEgNIVtCG0rKdaS8MNXQ2LY6oRqv6j+ZvXsJKYIR/ZLAZ/eyNBhKjl2u5CZo8YGbPpgNpU9USrSnr/RSqw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1101MB2367 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.16, xbe-aln-001.cisco.com X-Outbound-Node: alln-core-5.cisco.com Archived-At: Subject: Re: [Roll] Review of draft-ietf-roll-enrollment-priority-04 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, 11 Aug 2021 00:51:52 -0000 SGVsbG8gTWljaGFlbCANCg0KSSBndWVzcyB0aGF04oCZcyBiZWNhdXNlIHdlIGhhdmUgZGlmZmVy ZW50IHVzYWdlcyBpbiBtaW5kLg0KDQpGb3Igb25lIHRoaW5nIHdlIGFyZSBidWlsZGluZyBhIERB RyBib3QgYSB0cmVlIGFuZCB0aGUgaW50ZW50aW9uIGlzIGVmZmVjdGl2ZWx5IHRvIGZvcndhcmQg dmlhIG11bHRpcGxlIHBhcmVudHMgYXQgdGhlIHNhbWUgdGltZSwgYW5kIHJlY2VpdmUgZnJvbSBt dWx0aXBsZSBwYXJlbnRzIGFzIHdlbGwuIA0KDQpUaGUgcHJlZmVycmVkIHBhcmVudCBpcyB1c2Vm dWwgaW4gdGhlIFJhbmsgY29tcHV0YXRpb24gYW5kIGV2ZW50IGhvcml6b24sIGJ1dCBpdCBpcyBu b3QgdGhlIG9ubHkgbmV4dCBob3AuDQoNClNlY29uZCBpcyB0aGF0IHRoZSBpbiBub24gc3Rvcmlu ZyB0aGUgY2hpbGQgYWNjZXB0aW5nIGEgam9pbiBkb2VzIG5vdCBjcmVhdGUgc3RhdGUgaW4gdGhl IHBhcmVudC4gU28gZXZlbiBpZiB0aGUgcGFyZW50IGlzIHNhdHVyYXRlZCB0aGUgY2hpbGQgbWln aHQgYmUgb2suIFNvIHdoeSBzaG91bGQgdGhlIHBhcmVudCBhZmZlY3QgdGhlIGNoaWxkID8gQW5k IHRoZW4gbm9kZXMgb2Z0ZW4gcmVwYXJlbnQuIFRvbyBsYXRlIHRoZSBub2RlIGhhcyBjaGlsZHJl biBzaG91bGQgaGUgYWJhbmRvbiB0aGVtIG5vdyB0aGF0IHRoZSBuZXcgcHJlZmVycmVkIHBhcmVu dCBkb2VzIG5vdCB3YW50IGFueT8NCg0KTW9yZSBzdWJ0bGUgdGhlcmXigJlzIHRoZSBwb2ludCB0 aGF0IHRoZSBuZXcgc3RhdHVzIG9wdGlvbiBzaG91bGQgbm90IGFmZmVjdCByb3V0aW5nLiBJZiB0 aGUgdmFsdWUgY2hhbmdlcyB0aGUgY2FwYWJpbGl0eSBvZiB0aGlzIG5vZGUgdG8gaGF2ZSBjaGls ZHJlbiBpc27igJl0IHRoYXQgYW4gaW5jZW50aXZlIHRvIG1vdmU/DQoNClRoZSByZWFsIGJvdHRs ZSBuZWNrIGZvciB0cmFmZmljIGlzICB1c3VhbGx5IHRoZSB1c2FnZSBvZiB0aGUgcmFkaW8gdG8g dGhlIHJvb3QuIElmIHRoYXQgaXMgc2F0dXJhdGVkIHdl4oCZbGwgaGF2ZSBtb3JlIGNvbXBsZXgg aXNzdWVzIHRoYW4gYmlydGggY29udHJvbC4gTWF5YmUgcmF0ZSBjb250cm9sLiBNYXliZSBpbmNl bnRpdmUgdG8gZW1pZ3JhdGUuIEFsbCB0aGF0IGlzIGludGVyZXN0aW5nIGJ1dCBiZXlvbmQgdGhp cyBkcmFmdC4NCg0KT24gdGhlIG90aGVyIGhhbmQgdGhlIGdsb2JhbCBrbm93bGVkZ2Ugb2YgdGhl IGRhZyBzdGF0dXMgaXMgdXNlZnVsIG5vdCBqdXN0IHRvIGpvaW4gYSBkaWcgYnV0IGFsc28gdG8g bGVhdmUgaXQgZm9yIGEgbGVhc3QgbG9hZGVkIG9uZS4NCg0KSSBiZWxpZXZlIHRoYXQgdGhlIHJv b3QgcGVyc3BlY3RpdmUgd2l0aG91dCBhIGNoYW5nZSBpcyB3aGF0IGtlZXBzIHRoZSBkcmFmdCBz aW1wbGXigKYgDQoNClRha2UgY2FyZSwNCg0KUGFzY2FsDQoNCj4gTGUgMTEgYW/Du3QgMjAyMSDD oCAwMjoyNiwgTWljaGFlbCBSaWNoYXJkc29uIDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E+IGEgw6lj cml0IDoNCj4gDQo+IO+7vw0KPiBQYXNjYWwgVGh1YmVydCBcKHB0aHViZXJ0XCkgPHB0aHViZXJ0 PTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPiB3cm90ZToNCj4+IFdpdGggMikgZGlmZmVyZW50 IHBhcmVudHMgbWF5IGdpdmUgZGlmZmVyZW50IHZhbHVlcyBmb3IgdGhlIHNhbWUNCj4+IHNlcXVl bmNlLiBXaGljaCBzaG91bGQgb3VyIG5vZGUgcGljaz8gVGhlIG9uZSBmcm9tIHRoZSBwcmVmZXJy ZWQNCj4+IHBhcmVudD8gT3Igc2hvdWxkIHRoZSBub2RlIHJlcGFyZW50IHRvIHRoZSBiZXN0IG9m ZmVyPyBUaGVyZeKAmXMNCj4+IGNvbXBsZXhpdHkgYW5kIGNvbnNlcXVlbmNlcyB0byB0aGF0IGRl Y2lzaW9uIG9mIHBpY2tpbmcgb25lIHZhbHVlLiBBbmQNCj4+IHRoZW4gbm8gd2F5IHRvIGtub3cg dGhlIGFic3RyYWN0IGRlc2lyYWJpbGl0eSBvZiB0aGUgbmV4dCBkb2RhZyBzaW5jZQ0KPj4gdGhl IHZhbHVlIGZyb20gdGhlIHJvb3QgaXMgbG9zdC4NCj4gDQo+IEEgbm9kZSBzaG91bGQgb25seSBj YXJlIGFib3V0IHRoZSB2YWx1ZSBmcm9tIHRoZSBwcmVmZXJyZWQgcGFyZW50Lg0KPiBUaGVzZSB2 YWx1ZXMgc2hvdWxkIG5ldmVyIGFmZmVjdCBwYXJlbnQgc2VsZWN0aW9uLCBidXQganVzdCBiZSBh Ym91dCBvdGhlcg0KPiBub2RlcyBlaXRoZXIgZW5yb2xsaW5nLCBvciBqb2luaW5nIHRoaXMgUEFO SUQuDQo+IA0KPiBTbyBJIGRvbid0IHVuZGVyc3RhbmQgd2hhdCB5b3Ugd3JpdGUuDQo+IA0KPiAt LQ0KPiBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1hbi5jYT4gICAuIG8gTyAo IElQdjYgScO4VCBjb25zdWx0aW5nICkNCj4gICAgICAgICAgIFNhbmRlbG1hbiBTb2Z0d2FyZSBX b3JrcyBJbmMsIE90dGF3YSBhbmQgV29ybGR3aWRlDQo+IA0KPiANCj4gDQo+IA0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBSb2xsIG1haWxpbmcg bGlzdA0KPiBSb2xsQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcm9sbA0K From nobody Wed Aug 11 14:24:50 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 6F3333A25AA; Wed, 11 Aug 2021 14:24:49 -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, 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 qJ_xwjNqjiFr; Wed, 11 Aug 2021 14:24:46 -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 215A33A25A8; Wed, 11 Aug 2021 14:24:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by duch.mimuw.edu.pl (Postfix) with ESMTP id F2CD36009F7ED; Wed, 11 Aug 2021 23:24:40 +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 Tl1ib8m0Y3sI; Wed, 11 Aug 2021 23:24:38 +0200 (CEST) Received: from Konrads-MacBook-Pro.local (unknown [IPv6:2a02:a311:813e:880:f03f:7c51:a3e1:8bbd]) (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; Wed, 11 Aug 2021 23:24:37 +0200 (CEST) From: Konrad Iwanicki To: Routing Over Low power and Lossy networks Cc: roll-chairs References: Message-ID: <9b7eabc7-e521-bf82-4087-c65e08fc9fc0@mimuw.edu.pl> Date: Wed, 11 Aug 2021 23:24:36 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.12.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: [Roll] Review of draft-ietf-roll-enrollment-priority-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2021 21:24:50 -0000 Dear Rahul, Pascal, Michael, and all, As promised, I am sending my remarks about the enrollment priority draft, version 05, so as to point out the issues I have with the draft, thereby providing some starting point for discussion at the August interim. Sorry for the text being rather lengthy, but I wanted to highlight all major issues that came to my mind. I am not providing any editorial changes, because those below are more important at this point. PROTOCOL OPERATION WRT. FIELD MIN PRIORITY Based on your comments on my previous review, I gather that there are two different ideas on how the protocol should work, clarifying which was also the reason for the questions I put in my previous review (of the draft version 04). Unless noted otherwise, the text below refers only to the management of field min priority. In other words, let us completely ignore field DODAG_Size for a while. We will return to it later. IDEA 1 (GLOBAL) The first idea on how the min priority field should be managed is supported by Pascal, and I will refer to it as GLOBAL. Essentially, it works as follows: 1. The min priority values are generated solely by the DODAG root node; other nodes are not allowed to change these values. 2. A node extracts the value from a received option, stores it locally, and uses it as a base when computing the proxy priority for EBs, which may also account for the node's local constraints (e.g., load); however, per 1., only the originally received (and stored) value of min priority is used in the options in DIOs sent by the node. 3. An option received from ANY node can be used as the source of the min priority value but the receiving node has to be able to judge whether the received value is fresher than the one it already stores locally. 4. To this end, a lollipop sequence counter that I proposed, let's call it OSN, can be used. I suggested adding it to the option, but others suggested using some existing counters. This is immaterial for now---more on that later; instead, let us just assume that we have OSN mapped to some counter. 5. In any case, the root node bumps its OSN when it produces a new value of min priority. (This condition can also be relaxed but I'd rather not make this text longer. We can discuss this during the interim.) 6. Whenever a node receives an option with a value of OSN that is greater than its own local value of OSN, it adopts the received value of OSN and the received value of min priority as its local ones. Those values will then be sent in the options in DIOs transmitted by the node. This is a really simple and robust solution. Its main advantage is that there are normally many paths that allow a node to learn the value of min priority, which alleviates the problem of nodes that do not support the option or nodes that experience (temporal) down times, overload, and the like. The problem of the different paths being asynchronous, and hence offering different propagation times for the values of min priority, is in turn solved by OSN: the counter unambiguously discriminates between fresher and older values. The effect is that as long as each node has at least one neighbor (not necessarily a parent) that supports the option, the min priory values will be eventually consistent globally. In contrast, the main drawback of this solution is that the value of min priority is global. In particular, it does not take into account any heterogeneity in the load, available resources, etc. in different regions of the DODAG. IDEA 2 (FLEXIBLE) Michael and Rahul thus advocate an alternative idea, let's call it FLEXIBLE. In this approach, it is possible to adjust the value of min priority per node by incrementing the base value the node has originally received. Although the new version (05) of the draft does not describe this in sufficient detail, from Michael's comments I gather that the envisioned solution is something as follows: 1. The root sets a value of min priority in the option in its DIOs. 2. A non-root node obtains the value of its min priority only from an option received from its preferred parent and stores this value locally. It can then only increase the local value, for instance, accounting for its local constraints, before putting it into EBs and the options transmitted in its own DIOs to its children. In other words, the value of min priority can only grow at each hop, reflecting the local constraints of the nodes on the path upward to the root. 3. Since for each node, there is only one source of min priority values (its preferred parent), there are no conflicts. Consequently, in theory, we could omit OSN, as is the case in the current version of the draft. (This approach is wrong, as we will see shortly.) 4. To be compatible with the DIO processing rules in RFC 6550, a node receiving an option with min priority from any neighbor performs the processing according to the following rule (currently missing in the draft): "When processing the option, a node ignores the value of min priority in the option if the option does not come from the node's preferred parent." (This rule is again wrong, as we will see shortly.) 5. If the node's preferred parent does not support the option, the node assumes a default value (0x40) for its local min priority. This value, potentially increased to account for the node's local constraints, is put in the options in the DIOs transmitted by the node to its children. The main advantage of this approach is that the min priority value can be adjusted in a DODAG subtree. The approach thus offers much more flexibility in configuring the values: an entire subtree that is overloaded or experiences other problems can adopt a higher min priority values so as to deflect enrollment traffic to other parts of the DODAG. A disadvantage is in turn that the approach precisely defines the path along which a node has to learn its value. PROBLEMS WITH IDEA 2 (AND A POSSIBLE SOLUTION) However, because of the existence of just a single path for propagating min priority value to each node, FLEXIBLE, as presented hitherto, is wrong. To explain, an important use-case, mentioned also in the present version of that draft, is disabling enrollment in an entire DODAG. This is done by the DODAG root setting its min priority value to 0x7f. Now suppose the DODAG root has done this and that there exists a node, let's call it X, in the DODAG that does not support the option. The children of node X would thus adopt values 0x40+delta (depending on their local constraints) as their min priority values. Since 0x40+delta need not be equal to 0x7f, an entire subtree of node X need not disable enrollment, which is invalid. In general, in FLEXIBLE, nodes that do not support the option are a major problem, as their ancestors disregard any decisions of upstream nodes, including the root. The problem can be solved as follows. - We use multiple paths for propagating min priority information but one of them is preferred by each node (the one through the node's preferred parent). - To ensure consistency, we do employ the aforementioned OSN. Again, for simplicity let's assume that it is incremented whenever the DODAG root produces a new value of min priority but, like in GLOBAL, this condition can be relaxed. - There is no default value (0x40) a node ever adopts for its min priority. (Apart perhaps from the value accompanying the initial OSN value.) - Each node locally stores: * the last value of OSN * the accompanying value of min priority * a bit, let's call it PB, indicating whether the above values come from the node's preferred parent (1) or not (0) - In contrast, to the present version of the draft, we maintain the following invariant: "For a given OSN value, the value of min priority at any node is greater than or equal to the value of min priority at the root node." This is to ensure that no node, including the children of a node that does not support the option, is able to override the root's setting of min priority down for a given value of OSN. In particular, the invariant ensures that if the root disables enrollment globally, then so will all nodes (under the same assumptions on connectivity as in GLOBAL). Given these points, the specific rules for processing the option are as follows: 1. If a node receives an option with a greater value of OSN than its local one, then eventually it adopts the received values of OSN and min priority as local ones, and sets PB appropriately (i.e., to 1 if the option is received from its preferred parent or 0 otherwise). It does not have to do this immediately. In particular, it may wait for a while to receive the option with the greater OSN from its preferred parent. Nevertheless, eventually it MUST adopt the greater OSN (and an accompanying min priority). 2. If a node receives an option with the same value of OSN as its local one then: a. if the option is received from its preferred parent, then it adopts the value of min priority from the option and sets PB to 1. b. otherwise, i. if its local PB is 1, then it ignores the received option; ii. if its local PB is 0, then it sets its local min priority to the minimum of its local min priority and the value of min priority from the option 3. If a node receives an option with a smaller value of OSN than its local one, then it ignores the received option. 4. If a node changes its preferred parent, then it sets its PB to 0. 5. If a node sends the option in its own DIO, then it puts in the option its local value of min priority or a greater value (e.g., taking into account the node's local constraints). It can never sent the option with a lower value of min priority than its local one. This should do what I would expect from FLEXIBLE. However, I wrote this up in a haste, so it would be great if somebody verified the above algorithm. As a side note, the algorithm suggests that FLEXIBLE is indeed a bit more involved than GLOBAL, so a decision should be made, which of them to put in the draft. FURTHER ISSUES UNCOVERED IN THE DRAFT OR TO BE DISCUSSED AT THE INTERIM Irrespective of the decision whether to settle down on GLOBAL or FLEXIBLE, I believe that the following issues also have to be covered in the draft (and discussed during the interim). 1. Should DODAG_Size be part of the option? I mentioned this in my previous review and there has been some discussion already. I would just like to add one observation to that discussion: whereas min priority can follow either GLOBAL or FLEXIBLE, I believe there is an agreement that DODAG_Size should follow GLOBAL when it comes to propagating its value in the network. This information may influence our decision on which of the approaches to adopt for min priority and whether to put DODAG_Size in the option at all or move it to another one. 2. Which counter to use as OSN? I proposed a dedicated counter, which I believe is a clean solution. However, there are other possibilities. I also believe that we agreed that DTSN from DIO base is not the best choice. In my view, nor is DODAGVersion but we can discuss this. 3. How do changes to min priority (and OSN) affect DIO Trickle timers? This is currently not covered in the draft. However, I would imagine that some decisions regarding min priority should be propagated fast in a DODAG, and hence require Trickle timer resets. In particular, I would expect that disabling enrollment globally should be disseminated as soon as possible. Therefore, if I were to suggest anything, I would say that a change by a node of min priority to the maximal value (0x7f) from a lower one MUST entail a Trickle timer reset. In turn, a change from the maximal value to a smaller one MAY/SHOULD entail a Trickle timer reset. Other changes are, at least in my view, not that important, but this can and should be discussed. 4. How does a (temporal) lack of a preferred parent affect the proxy priority of the node in EBs (and in general, the node's behavior)? This is also ignored in the draft but it may happen that a node does not have any preferred parent for a while. In this case, it is unable to handle any enrollments. What should it do? I would expect that it would advertise the maximal proxy priority in EBs. However, should it also modify its local min priority? I would probably be against. Plus there are smaller issues I mentioned earlier, and I probably forgot something. In any case, sorry again for such long a text but I hope it may help during the interim. Best, -- - Konrad Iwanicki. From nobody Thu Aug 12 02:47: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 9D2543A3FBA; Thu, 12 Aug 2021 02:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=eZhVkN1M; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=q4GFmImH Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQKARufN_LGJ; Thu, 12 Aug 2021 02:47:37 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F19A23A3FB8; Thu, 12 Aug 2021 02:47:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16051; q=dns/txt; s=iport; t=1628761657; x=1629971257; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4UUiaoXleSD+g8We2NmT/FLiZEBtl1ayAycpqguJ830=; b=eZhVkN1MwLTwL6068aLFLP6+M/NBDgvxeJ88KyCF7o4Sb5BWoqPmgTfN RrJWj4rAPiiw01STxvPRaToOjadDBFnP0QiNBGeFvLKJfATd1hbJWC0Sr SdHN0Rrjnw7jvI4WWhGg5P9s1VHUhFPWrhYAxf57sjlL5IYx9L9Y1e83b Y=; X-IPAS-Result: =?us-ascii?q?A0DsAQCp7RRhl4MNJK1aHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?VmBUykoflo3MYgPA4U5iGkDj2+KRoFCgREDVAsBAQENAQEqCwwEAQGBIIM5A?= =?us-ascii?q?oJmAiU4EwECBAEBAQEDAgMBAQEBBQEBBQEBAQIBBgQUAQEBAQEBAQGBCIVoD?= =?us-ascii?q?YZCAQEBAQIBAQEQLgEBLAsBBAcEAgEIEQQBARYZJwsdCAIEDgUIEweCTwGCV?= =?us-ascii?q?QMOIQEOnjoBgToCih94gTOBAYIHAQEGBASFKhiCNAMGgTqCfYJyU4cuJxyBS?= =?us-ascii?q?USBFUNUgQ2BAT6CYgEBgRkNBBgFGz2DDoIugnsRAVoGPhwODSIUEAQFDgs5A?= =?us-ascii?q?h4dLRoJARoQDBQKAh8KD5E4jXqddwqDKJ5mEqZzhTuwbAQEC4R0AgQCBAUCD?= =?us-ascii?q?gEBBoF3IoFbcBU7gmlQGQ6OHxmBDQEHCAeCNYUUhUpzOAIGAQoBAQMJiC5eA?= =?us-ascii?q?QE?= IronPort-PHdr: A9a23:uY/4NBf76rWx83FsChNnnw4+lGM/qYqcDmcuAtIPir9SfOKk5Zuxd EDc5PA4iljPUM2b7v9fkOPZvujmXnBI+peOtn0OMfkuHx8IgMkbhUosVciCD0CoLfP2YWo9B ssRHFNg9muwZE5SHsu2blbOo3q0uDgVHBi3NQd8KunvXIDIiMHi3OGp8JqVaAJN11KA IronPort-HdrOrdr: A9a23:hbPRZ6MWf0Bl78BcT57255DYdb4zR+YMi2TDiHoRdfUFSKKlfp 6V88jzjSWE9gr4WBkb6Le90dq7MALhHPlOkMos1NaZLUnbUQ6TTL2KgrGSuAEJlUfFh5RgPM tbAs1D4ZjLfCdHZKXBkUuF+rQbsaS6GcmT7I+0pRoAPGIaCZ2IrT0JdjpzeXcGIjWucKBJbK Z0kfA33gZIF05nCviTNz0gZazuttfLnJXpbVotHBg88jSDijuu9frTDwWY9g12aUIL/Z4StU z+1yDp7KSqtP+2jjXG0XXI0phQkNz9jvNeGc23jNQPIDmEsHftWG0hYczEgNkGmpD31L8Yqq iVn/7mBbUp15rlRBDynfIq4Xi77N9h0Q6+9bbSuwqSnSWwfkNINyMGv/METvMcgHBQ4u2VF8 lwrj2kXtNsfGH9tTW46N7SWx5wkE2o5XIkjO4IlnRaFZATcblLsOUkjQ9o+bo7bWjHAbocYa RT5QDnlYBrWELfa2qcsnhkwdSqUHh2FhCaQlIassjQ1zRNhnh2w0YR2cRaxx47hdwAYogB4/ 6BPrVjlblIQMNTZaVhBP0ZSc/yDmDWWxrDPG+bPFyiHqAaPHDGrYLx/dwOla6XUY1NyIF3lI XKUVteu2J3c0XyCdeW1JkO6RzJSHXVZ0Wn9iif3ekwhlTYfsurDcSuciFbryKQmYRXPiSAYY fHBHt/OY6VEVfT X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.84,315,1620691200"; d="scan'208";a="729236053" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Aug 2021 09:47:35 +0000 Received: from mail.cisco.com (xbe-rcd-007.cisco.com [173.37.102.22]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 17C9lYe8016295 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Thu, 12 Aug 2021 09:47:35 GMT Received: from xfe-rtp-004.cisco.com (64.101.210.234) by xbe-rcd-007.cisco.com (173.37.102.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 12 Aug 2021 04:47:34 -0500 Received: from xfe-aln-003.cisco.com (173.37.135.123) by xfe-rtp-004.cisco.com (64.101.210.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 12 Aug 2021 05:47:33 -0400 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-003.cisco.com (173.37.135.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Thu, 12 Aug 2021 04:47:33 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=P40A1aI5HNzdHzyCxw9GXpSD7mpxIF88Nn8n5APYwX1hmQelDUqHmn1gnbxsONzgPNOrMZprX7Q/KjlAA0F5lTtrqNUTZ97H0YvaxtYeVv0C/9clxoGB9AVjDXsAJ5eZWdpVE7L8aV7inu22H0erBCfrXM5O5lt3xdKJ9ydOPR/m79q0bT/y7yYRgEcUqnE0QUcUCbGOGPWyG9iJRq0PcFmQ0nPv0+LULam5Bk2mcZyjfB+E8LJEzCZpv7XBbDrqtxKsLj8IszibLpiLRLi8Y1nFHKtDsj0Ka/tGInE55lY+ImkY66rgsXZgWN4LmDPzjfvjS9fZDq48NcyUiXiT6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pk7UJ9qZkUmNJYd4tuTIpNixR/99BQ2OU43RnNurhno=; b=ix+fn/un5hEGy29zGQeS9CPu8rtbN4+N06WW7KACEdfCqeU2+UOiEUA/ekDdl+N3m3ChgEN3f/EKt8KBLKRE0EhLpXOj4iCeKh7LDWwg3ZvnBsXFcip0H2r3NQJtB3MgOnL8qr2gXuJHw+kxeQ9LdThSJK4Hs1vaosTcvvnC630u6Gj55erW6DU3r9W286c3F51jFWPRPgXS6jKfQ4/0ks61oWVhArqw5zD+j4hDYtdvfO97AZCRo51nHA8scmwCIERjZo5JgpccaIvgkjAjy6QN1y6HL+LZA6jJsb06nG0PaXfMC323vCaQFYqW6atnPl5ZP2alsalhdhZZ7zxHJg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pk7UJ9qZkUmNJYd4tuTIpNixR/99BQ2OU43RnNurhno=; b=q4GFmImH4meIuzVkfonoc1TnkpLs1ep5cNfjukSKqulEa4JqmH0hU60aKj90TVkx++BCxssi5WarvkoNecSa+BEqiHn/MPGDUmI8XM1zM1uSqhqzQqb/I2PMb6dXs4UB5tZ/RKcaV8QHXx4wzPhcZjJ5XXe7RX8G+BtMS3Q3dcE= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by CO1PR11MB4996.namprd11.prod.outlook.com (2603:10b6:303:90::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4415.17; Thu, 12 Aug 2021 09:47:32 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::487e:47b8:314f:189a]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::487e:47b8:314f:189a%7]) with mapi id 15.20.4415.018; Thu, 12 Aug 2021 09:47:32 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks CC: roll-chairs Thread-Topic: [Roll] Review of draft-ietf-roll-enrollment-priority-05 Thread-Index: AQHXjvdeih/QhHt6aEmURQMfl9q056tvmydQ Date: Thu, 12 Aug 2021 09:47:16 +0000 Deferred-Delivery: Thu, 12 Aug 2021 09:46:28 +0000 Message-ID: References: <9b7eabc7-e521-bf82-4087-c65e08fc9fc0@mimuw.edu.pl> In-Reply-To: <9b7eabc7-e521-bf82-4087-c65e08fc9fc0@mimuw.edu.pl> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ceaad4ec-dca8-447e-c0bd-08d95d7634cb x-ms-traffictypediagnostic: CO1PR11MB4996: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: QOvLbnWEc67s1Qfl0TPg1A2S0LBtPrVEamYNRHH8zNHvR0Xld1+1V/Gxyd1eBxvf+DIV/rCl29LTCx3ryzA2Bk1BWyN1csaYoKbmQg3hjNFltzuvF6B4HLRuUIrIpF45vQkPQPaCgAPXQfYUCGfy+GP/wtWpJOdcEwEeKxKIBU6VniV2Srp2GKix6ifmMn1oqeaGOBRlZaLP2UeNA0os2X1llq7XFMXLevLScUX6XwOmKHk/tZoQsnsemStBVXsHKJgQjoI0Itv4q5197PF4vgOm1rMJ8crCUjnLmC6sDQTO15Sd/LGDFwQj9PTSUud6Tghh8lhqhMmT+OW4dXZm3pg6vMe3wcXlnUKXUz3dF8Ze8BrhA4bgIBu4g6SC2R6gYISNq5qFDhX127REos61UZPzBWztp2sN51kbDYsnPq2W0ixa/mryfN/0vXPTZGQsOqpyCmaoRdvj8nEalUXuMNGwPk3vZsVP3LX+nQM3fn29AgyW+RQoyQGTWZrOf3bIBPAzf1AJNtzE/HAKDFrTtE6/xQEil8wii9XJSdcaUgxpMU4mWOHTczZSHsjn8/3CuMODIN96oeWhmEl2aMVEfq6AO+LficzwRx6NDNezL9xvsmu3mwDhylUVOiC+YAtLLww8E7oWGLAROJtBPH3pOE8+TMFqSS55Nx2bUNoCdfeA5d3VlXme3Tvwvc8lJYnYe24lho0rP6iZFLh+/WmOyJrQJ07Y4UWVgMo+Z7TMqKgCyQ4AEC1xKQCDO3fJUJ36xdddtVfdSTQa5WFGeYyuuFPJv7it1eMUBUqn/B0QBZ4= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB4881.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(366004)(39860400002)(376002)(396003)(346002)(122000001)(55016002)(8676002)(8936002)(38100700002)(76116006)(66946007)(33656002)(9686003)(186003)(64756008)(66446008)(2906002)(66476007)(66574015)(30864003)(66556008)(6666004)(966005)(316002)(71200400001)(6916009)(86362001)(83380400001)(53546011)(7696005)(6506007)(450100002)(52536014)(478600001)(4326008)(5660300002)(38070700005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?8FAaZzxKR0mW7LK+W0URuuSuTzI+wj7mqvrYyiLyIrEi0nPWXAIJIrR/xO?= =?iso-8859-1?Q?cSvZBYmN+7UZUX+baqPEGVSNCcSNXU+jKhBgOYy+cro+7bY8lYLe2ws2x2?= =?iso-8859-1?Q?q6cJ2s6WDEIMrgFNVAHeeBTxAtybyEMXPXsSBVnTk+HV/Df88nXxKbySFq?= =?iso-8859-1?Q?YaW/bUtdF2ecE9qXDb+DQuWZNPvA8LqCf7jg99WO0zrESVqGBDM1gQ6WJA?= =?iso-8859-1?Q?SZQ1EOUuqNkJHkggKW9iPbS8FDTTTVLGevrmnLzqzN33ttC3bl9uG8xZBr?= =?iso-8859-1?Q?Bub0arcaJ/dSWkrr7osMQtewH6HIgNOnJMiYrCwSWZZL2FTzmVTjddV3ml?= =?iso-8859-1?Q?rf2zt+dj0e3GXI6KkgHWVFB1kY6Y9SoTJw1j2Fnf/V36/Hbno2vypRb8Dc?= =?iso-8859-1?Q?bMCU11WR5UmtNJOsukOZ0IEmzhDQEDrAeVY1xi8MFAiiysa1jOFPsI7T5y?= =?iso-8859-1?Q?RxM0K4YB5Q4PO1j77RqH63Ip0Ne4iqCJLIQn/mHx5pdrMn4s3NhrhdRz9D?= =?iso-8859-1?Q?To19UW0Cjy2ENKWdzsgdDGAZ81JnvQ2r+cr1TNcP4AYKviyrtu+sKSIZK5?= =?iso-8859-1?Q?n1VH65SyJIEDF2dIDxsrV5U3I8XA02Ou2/AqYeNOJ2US659X18RHqkupQZ?= =?iso-8859-1?Q?bft8EXZ9FLzZ8kYmizmR95Xsg5mwxVngHiMm6CvdUjDxBlQed3OyRle/fJ?= =?iso-8859-1?Q?XA0OaLSaLmDGEs4K2E8lhdmBw3HoNfDebjmaRlI3eq/8eiqqOkk3dLrE/q?= =?iso-8859-1?Q?JDTz1HuEF4tnbdla3mS/c2D/DWJ9CbT0g3q00TXw0WIBEeLQe0dSn/4ByZ?= =?iso-8859-1?Q?+Tm9S7zkcuiYba7waJ+0hOsJ7pFU1e6jtgt8/JQ5GQNDtl3dqHm5oDgZNI?= =?iso-8859-1?Q?ChoyU+/tLSDsPqsG2zt0vB835YNU96CAio2UzkHoJ2faHCduqd/ZS8Xbsi?= =?iso-8859-1?Q?BrZaSpkBZsozo0nlgJh24MmF9PNy3ITojWJ/dqF3ou4cvodbvbcyGB062J?= =?iso-8859-1?Q?mEQgcw9MPc375BOK8f/X4dX0q9EhAhygMDxHTpn/T2BHJb8SQo7kTmquNB?= =?iso-8859-1?Q?5Qjh/eC8uz5nJ7ycX6FSqH6RC+rT19QHZOoIO/8wn8whUat6zpauep7Kdv?= =?iso-8859-1?Q?yoRRLNArax5KrCpnPaEmK0YbWV4B3cQjRCn2IIa+1F2HVVQLh/+4p2l7wY?= =?iso-8859-1?Q?TzOlggPSS6wkMPkoXsgDRojR1lGkW052FAoNGYshpv5iF+fo3YNufKMgC9?= =?iso-8859-1?Q?ZrP9u2hKPU9R6rhk1ZUg6Cct7tnaxiEeLjky4T2NUr9pjcOGhi6259BOvS?= =?iso-8859-1?Q?NzHBK5LOq+k9lWY6TwoM2eLwhsTZKH5D+eVq6htQ34pF8iMpb5QtHrOKkS?= =?iso-8859-1?Q?nJ9UJv2/jy0MQkMFgGtabBRAHRxoh41BamtMg96Q2Wjrp07s/GXLRVdFsO?= =?iso-8859-1?Q?+HVeIWVfX8aXte9C?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4881.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ceaad4ec-dca8-447e-c0bd-08d95d7634cb X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Aug 2021 09:47:32.1046 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 0lQVsdVshrWtd68IJUIBaXHI9/lwWQJwgrQXqFsE1CnLjt7PvIB4V9jbOkulPgr4fqMxduKG3lFCzJvO99Oexw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB4996 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.22, xbe-rcd-007.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [Roll] Review of draft-ietf-roll-enrollment-priority-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2021 09:47:43 -0000 Hello Konrad,=20 This is great explanations of both options and how they could be made to wo= rk. What we need to add is, what do we want them for, which use case are we se= rving? GLOBAL serves the need for a node to compare the load of the current DODAG = with that of other DODAGs it could jump to. The use case is balancing DODAG= s.=20 FLEXIBLE gives an indication of load of a preferred path. What would be the= use of that? - in storing mode it could indicate the capability of creating DAO state. B= ut you'll find looking at it that you'd need a lot more than good or bad. I= f a node moves to another parent and has 100 children it needs to know that= the new parent and its path up to the root have 100 rooms left. OK, it wou= ld split the DAOs between 2 parents, but if the bottleneck is up there wher= e the paths from the parents cross, it fails. Bottom line, hard problem tha= t we avoided so far. - in any mode, it could indicate the throughput load. But then:=20 * usually (P2MP or MP2P with homogeneous radios) that overload affects pr= imarily the root's radio space, so there is no benefit in increasing the mi= nimum, the root's one is the worst already.=20 * there's the need to normalize the increment, IOW to explain by what the= min value should be increased by the 6LRs and when so the result down ther= e is comparable between preferred parent chains. Like the Rank computation = which imposes a single OF, you need to impose a single operation throughout= . From there, all the problems of updating OFs, using multiple OFs, etc... * the real need would be to rebalance the tree, but rebalancing a tree in= a distributed protocol is another hard problem, subject to loops So what is FLEXIBLE for? Convince me we need it and I'll support doing both= . On the side, I completely agree with you sequence counter in any case. The = counter should follow section 7 of RFC 6550, including freshness assertion,= etc... in which case there's little additional to describe. Keep safe, Pascal > -----Original Message----- > From: Roll On Behalf Of Konrad Iwanicki > Sent: mercredi 11 ao=FBt 2021 23:25 > To: Routing Over Low power and Lossy networks > Cc: roll-chairs > Subject: [Roll] Review of draft-ietf-roll-enrollment-priority-05 >=20 > Dear Rahul, Pascal, Michael, and all, >=20 > As promised, I am sending my remarks about the enrollment priority draft, > version 05, so as to point out the issues I have with the draft, thereby > providing some starting point for discussion at the August interim. Sorry > for the text being rather lengthy, but I wanted to highlight all major > issues that came to my mind. I am not providing any editorial changes, > because those below are more important at this point. >=20 >=20 > PROTOCOL OPERATION WRT. FIELD MIN PRIORITY >=20 > Based on your comments on my previous review, I gather that there are two > different ideas on how the protocol should work, clarifying which was als= o > the reason for the questions I put in my previous review (of the draft > version 04). >=20 > Unless noted otherwise, the text below refers only to the management of > field min priority. In other words, let us completely ignore field > DODAG_Size for a while. We will return to it later. >=20 >=20 > IDEA 1 (GLOBAL) >=20 > The first idea on how the min priority field should be managed is > supported by Pascal, and I will refer to it as GLOBAL. Essentially, it > works as follows: >=20 > 1. The min priority values are generated solely by the DODAG root node; > other nodes are not allowed to change these values. >=20 > 2. A node extracts the value from a received option, stores it locally, > and uses it as a base when computing the proxy priority for EBs, which ma= y > also account for the node's local constraints (e.g., load); however, per > 1., only the originally received (and stored) value of min priority is > used in the options in DIOs sent by the node. >=20 > 3. An option received from ANY node can be used as the source of the min > priority value but the receiving node has to be able to judge whether the > received value is fresher than the one it already stores locally. >=20 > 4. To this end, a lollipop sequence counter that I proposed, let's call i= t > OSN, can be used. I suggested adding it to the option, but others > suggested using some existing counters. This is immaterial for now---more > on that later; instead, let us just assume that we have OSN mapped to som= e > counter. >=20 > 5. In any case, the root node bumps its OSN when it produces a new value > of min priority. (This condition can also be relaxed but I'd rather not > make this text longer. We can discuss this during the interim.) >=20 > 6. Whenever a node receives an option with a value of OSN that is greater > than its own local value of OSN, it adopts the received value of OSN and > the received value of min priority as its local ones. Those values will > then be sent in the options in DIOs transmitted by the node. >=20 > This is a really simple and robust solution. Its main advantage is that > there are normally many paths that allow a node to learn the value of min > priority, which alleviates the problem of nodes that do not support the > option or nodes that experience (temporal) down times, overload, and the > like. The problem of the different paths being asynchronous, and hence > offering different propagation times for the values of min priority, is i= n > turn solved by OSN: the counter unambiguously discriminates between > fresher and older values. The effect is that as long as each node has at > least one neighbor (not necessarily a parent) that supports the option, > the min priory values will be eventually consistent globally. >=20 > In contrast, the main drawback of this solution is that the value of min > priority is global. In particular, it does not take into account any > heterogeneity in the load, available resources, etc. in different regions > of the DODAG. >=20 >=20 > IDEA 2 (FLEXIBLE) >=20 > Michael and Rahul thus advocate an alternative idea, let's call it > FLEXIBLE. In this approach, it is possible to adjust the value of min > priority per node by incrementing the base value the node has originally > received. Although the new version (05) of the draft does not describe > this in sufficient detail, from Michael's comments I gather that the > envisioned solution is something as follows: >=20 > 1. The root sets a value of min priority in the option in its DIOs. >=20 > 2. A non-root node obtains the value of its min priority only from an > option received from its preferred parent and stores this value locally. > It can then only increase the local value, for instance, accounting for > its local constraints, before putting it into EBs and the options > transmitted in its own DIOs to its children. In other words, the value of > min priority can only grow at each hop, reflecting the local constraints > of the nodes on the path upward to the root. >=20 > 3. Since for each node, there is only one source of min priority values > (its preferred parent), there are no conflicts. Consequently, in theory, > we could omit OSN, as is the case in the current version of the draft. > (This approach is wrong, as we will see shortly.) >=20 > 4. To be compatible with the DIO processing rules in RFC 6550, a node > receiving an option with min priority from any neighbor performs the > processing according to the following rule (currently missing in the > draft): "When processing the option, a node ignores the value of min > priority in the option if the option does not come from the node's > preferred parent." (This rule is again wrong, as we will see shortly.) >=20 > 5. If the node's preferred parent does not support the option, the node > assumes a default value (0x40) for its local min priority. This value, > potentially increased to account for the node's local constraints, is put > in the options in the DIOs transmitted by the node to its children. >=20 > The main advantage of this approach is that the min priority value can be > adjusted in a DODAG subtree. The approach thus offers much more > flexibility in configuring the values: an entire subtree that is > overloaded or experiences other problems can adopt a higher min priority > values so as to deflect enrollment traffic to other parts of the DODAG. > A disadvantage is in turn that the approach precisely defines the path > along which a node has to learn its value. >=20 >=20 > PROBLEMS WITH IDEA 2 (AND A POSSIBLE SOLUTION) >=20 > However, because of the existence of just a single path for propagating > min priority value to each node, FLEXIBLE, as presented hitherto, is > wrong. >=20 > To explain, an important use-case, mentioned also in the present version > of that draft, is disabling enrollment in an entire DODAG. This is done b= y > the DODAG root setting its min priority value to 0x7f. Now suppose the > DODAG root has done this and that there exists a node, let's call it X, i= n > the DODAG that does not support the option. The children of node X would > thus adopt values 0x40+delta (depending on their local > constraints) as their min priority values. Since 0x40+delta need not be > equal to 0x7f, an entire subtree of node X need not disable enrollment, > which is invalid. >=20 > In general, in FLEXIBLE, nodes that do not support the option are a major > problem, as their ancestors disregard any decisions of upstream nodes, > including the root. The problem can be solved as follows. >=20 > - We use multiple paths for propagating min priority information but one > of them is preferred by each node (the one through the node's preferred > parent). >=20 > - To ensure consistency, we do employ the aforementioned OSN. Again, for > simplicity let's assume that it is incremented whenever the DODAG root > produces a new value of min priority but, like in GLOBAL, this condition > can be relaxed. >=20 > - There is no default value (0x40) a node ever adopts for its min > priority. (Apart perhaps from the value accompanying the initial OSN > value.) >=20 > - Each node locally stores: > * the last value of OSN > * the accompanying value of min priority > * a bit, let's call it PB, indicating whether the above values come > from the node's preferred parent (1) or not (0) >=20 > - In contrast, to the present version of the draft, we maintain the > following invariant: > "For a given OSN value, the value of min priority at any node is > greater than or equal to the value of min priority at the root node." > This is to ensure that no node, including the children of a node that > does not support the option, is able to override the root's setting of mi= n > priority down for a given value of OSN. In particular, the invariant > ensures that if the root disables enrollment globally, then so will all > nodes (under the same assumptions on connectivity as in GLOBAL). >=20 > Given these points, the specific rules for processing the option are as > follows: >=20 > 1. If a node receives an option with a greater value of OSN than its loca= l > one, then eventually it adopts the received values of OSN and min priorit= y > as local ones, and sets PB appropriately (i.e., to 1 if the option is > received from its preferred parent or 0 otherwise). It does not have to d= o > this immediately. In particular, it may wait for a while to receive the > option with the greater OSN from its preferred parent. > Nevertheless, eventually it MUST adopt the greater OSN (and an > accompanying min priority). >=20 > 2. If a node receives an option with the same value of OSN as its local > one then: > a. if the option is received from its preferred parent, then it adopts > the value of min priority from the option and sets PB to 1. > b. otherwise, > i. if its local PB is 1, then it ignores the received option; > ii. if its local PB is 0, then it sets its local min priority to the > minimum of its local min priority and the value of min priority from the > option >=20 > 3. If a node receives an option with a smaller value of OSN than its loca= l > one, then it ignores the received option. >=20 > 4. If a node changes its preferred parent, then it sets its PB to 0. >=20 > 5. If a node sends the option in its own DIO, then it puts in the option > its local value of min priority or a greater value (e.g., taking into > account the node's local constraints). It can never sent the option with = a > lower value of min priority than its local one. >=20 > This should do what I would expect from FLEXIBLE. However, I wrote this u= p > in a haste, so it would be great if somebody verified the above algorithm= . >=20 > As a side note, the algorithm suggests that FLEXIBLE is indeed a bit more > involved than GLOBAL, so a decision should be made, which of them to put > in the draft. >=20 >=20 > FURTHER ISSUES UNCOVERED IN THE DRAFT OR TO BE DISCUSSED AT THE INTERIM >=20 > Irrespective of the decision whether to settle down on GLOBAL or FLEXIBLE= , > I believe that the following issues also have to be covered in the draft > (and discussed during the interim). >=20 > 1. Should DODAG_Size be part of the option? >=20 > I mentioned this in my previous review and there has been some discussion > already. I would just like to add one observation to that > discussion: whereas min priority can follow either GLOBAL or FLEXIBLE, I > believe there is an agreement that DODAG_Size should follow GLOBAL when i= t > comes to propagating its value in the network. This information may > influence our decision on which of the approaches to adopt for min > priority and whether to put DODAG_Size in the option at all or move it to > another one. >=20 > 2. Which counter to use as OSN? >=20 > I proposed a dedicated counter, which I believe is a clean solution. > However, there are other possibilities. I also believe that we agreed tha= t > DTSN from DIO base is not the best choice. In my view, nor is DODAGVersio= n > but we can discuss this. >=20 > 3. How do changes to min priority (and OSN) affect DIO Trickle timers? >=20 > This is currently not covered in the draft. However, I would imagine that > some decisions regarding min priority should be propagated fast in a > DODAG, and hence require Trickle timer resets. In particular, I would > expect that disabling enrollment globally should be disseminated as soon > as possible. Therefore, if I were to suggest anything, I would say that a > change by a node of min priority to the maximal value (0x7f) from a lower > one MUST entail a Trickle timer reset. In turn, a change from the maximal > value to a smaller one MAY/SHOULD entail a Trickle timer reset. > Other changes are, at least in my view, not that important, but this can > and should be discussed. >=20 > 4. How does a (temporal) lack of a preferred parent affect the proxy > priority of the node in EBs (and in general, the node's behavior)? >=20 > This is also ignored in the draft but it may happen that a node does not > have any preferred parent for a while. In this case, it is unable to > handle any enrollments. What should it do? I would expect that it would > advertise the maximal proxy priority in EBs. However, should it also > modify its local min priority? I would probably be against. >=20 > Plus there are smaller issues I mentioned earlier, and I probably forgot > something. In any case, sorry again for such long a text but I hope it ma= y > help during the interim. >=20 > Best, > -- > - Konrad Iwanicki. >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Wed Aug 18 12:43:56 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 2E9773A1975; Wed, 18 Aug 2021 12:43:55 -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, NICE_REPLY_A=-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=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 MDFajdGIGQmf; Wed, 18 Aug 2021 12:43:50 -0700 (PDT) Received: from mta-202a.oxsus-vadesecure.net (mta-202a.oxsus-vadesecure.net [51.81.232.240]) (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 06AD03A1970; Wed, 18 Aug 2021 12:43:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; bh=S5KT4ct0MqckC/0J5AHRng+J/Uy9F5Ig6CKp6R qugxU=; c=relaxed/relaxed; d=earthlink.net; h=from:reply-to:subject: date:to:cc:resent-date:resent-from:resent-to:resent-cc:in-reply-to: references:list-id:list-help:list-unsubscribe:list-subscribe:list-post: list-owner:list-archive; q=dns/txt; s=dk12062016; t=1629315828; x=1629920628; b=cYi0zV2/Vu1A0FIYFRqOHPz5IAEZAxJAD1N22kJimDopQa2+CdrOv8O 2JhH2PuklaN6F0xFBVSSO+7nxFe9Xp6ZZwRxJ7HCxbh2OAIJTm7cLSmR9xo748zUaOCfOBp Pkgkfy8UWLEKIerM+m/N65bdFbNmCOoci9HTjvLnqwAsTbn1joKfkkItGdsRME+fvbYZDku 16LzpTzvRz0VtamoqOgx7kBCGf80rnssNrtXcZV8HEfMAIXaG7lXAWdNijRFT5BhN8rO4Hl Pyi12/LN1ZX4sFer8uNhFXrPdKl0iCfAQp/fys7TnUagT8QrYxh27FzlSDH7vPEDnBWSMZs i1A== Received: from [192.168.1.72] ([99.51.72.196]) by smtp.oxsus-vadesecure.net ESMTP oxsus2nmtao02p with ngmta id 55006cac-169c7e1ce0d42da5; Wed, 18 Aug 2021 19:43:47 +0000 To: Meral Shirazipour , Routing Over Low power and Lossy networks , gen-art@ietf.org Cc: last-call@ietf.org, draft-ietf-roll-aodv-rpl.all@ietf.org References: <161913875755.29365.13743105077300345063@ietfa.amsl.com> From: Charlie Perkins Message-ID: <03a77ab4-ff78-a0a4-9b09-5b2d850ede73@earthlink.net> Date: Wed, 18 Aug 2021 12:43:46 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 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 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: Wed, 18 Aug 2021 19:43:55 -0000 Hello Meral, Please excuse the unusually long delay it has taken for us to respond to your comments. 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 are making improvements for readability.  If you think of any more specific suggestions please send them also. Naturally Yours, Charlie P. On 4/22/2021 5:45 PM, Meral Shirazipour via Datatracker wrote: > 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. > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Wed Aug 18 12:50: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 E5BF23A19B7; Wed, 18 Aug 2021 12:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, 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 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 VRn4OqzONmKf; Wed, 18 Aug 2021 12:50:12 -0700 (PDT) Received: from mta-202a.oxsus-vadesecure.net (mta-202a.oxsus-vadesecure.net [51.81.232.240]) (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 7A3533A19B4; Wed, 18 Aug 2021 12:50:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; bh=6//Kb40f6L3aE9mgmZiXJ6Jt9wTDj6W9TjZ2qu S8TbM=; c=relaxed/relaxed; d=earthlink.net; h=from:reply-to:subject: date:to:cc:resent-date:resent-from:resent-to:resent-cc:in-reply-to: references:list-id:list-help:list-unsubscribe:list-subscribe:list-post: list-owner:list-archive; q=dns/txt; s=dk12062016; t=1629316211; x=1629921011; b=nQSMqyZH9+/Q8yK0NKpNkhPQH36Mo14zGUmSZg7wkNTZEUNRExJa3++ PiS1jvs/I4svHq9O34BQSQ8vkj0bS6mYBLdmVnIEpxEu1erYhCSryhBxo4Up0gy6nhRErrw xOjMvnqUJcHROoKXscF7RXPzaN445Z9N5UgJucE9FLYxjFYAMqY5U0WJdlXrZTuqOJmc2U0 /ThGVzGifbQgGX3PrbD3RBw66S99Esh3nV2oqgsDft/2398nd9DAgs3tpegj6Mkfpp5YRSi 6Ki9mX7UT6+IU8AccYyc98xm+lTxZiGmDbzPVAx3NU1blOGh1c4rSsslJVs/Vr0BNbyMDYK /xg== Received: from [192.168.1.72] ([99.51.72.196]) by smtp.oxsus-vadesecure.net ESMTP oxsus2nmtao02p with ngmta id de0bc759-169c7e7645ecc661; Wed, 18 Aug 2021 19:50:11 +0000 To: Tero Kivinen , secdir@ietf.org Cc: draft-ietf-roll-aodv-rpl.all@ietf.org, last-call@ietf.org, roll@ietf.org References: <161643127376.6337.10029863442550466574@ietfa.amsl.com> From: Charlie Perkins Message-ID: <8b572d7a-fd1a-9055-7052-057bb56ce720@earthlink.net> Date: Wed, 18 Aug 2021 12:50:10 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <161643127376.6337.10029863442550466574@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Roll] Secdir last call review of draft-ietf-roll-aodv-rpl-09 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, 18 Aug 2021 19:50:17 -0000 Hello Tero, Thanks for your comments, useful as always.  Please excuse the unusually long delay it has taken for us to respond to your comments.  Please see a bit of follow-up below. On 3/22/2021 9:41 AM, Tero Kivinen via Datatracker wrote: > The title of the draft has some acronyms which are not expanded (AODV, P2P) > and if you expand them the title comes way too long. I would propose a usable > title, which might not need to use all possible acronyms, but would better > explain what this document is trying to do. How about "Supporting Asymmetric Links in Low Power Networks"? Replacing "LLNs" by "Low Power Networks" is probably O.K. because lossy is almost implicit given low power (or, often, reality). > Nits: > > In section 1 the text "RPL [RFC6550] (Routing Protocol for Low-Power and Lossy > Networks)" defines acronyms differently than what is used everywhere else. In > all other cases the document uses format where the acronym is in parenthesis > after the full text, i.e. "Routing Protocol for Low-Power and Lossy Networks > (RPL) [RFC6550]" format. I would propose using the same format also for here. Done. > > In section 1 there is acronym DAG which is not expanded, expand it on first > use. I think that sentence reads better just omitting DAG. > Also there are unexpanded acronyms DAO, P2MP, which are not used anywhere > else, perhaps just expand them here. In same paragraph there is also acronym > MOP which is not expanded here on its first use, but it is expanded later. > Expand it here on its first use. Done, except that I thought it would be better to exhibit the acronym DAO since it is well known to readers familiar with RPL. > > What is the difference between different reserve bits X and r in sections > 4.1/4.2 and 4.3? I made them all to be reserved bits 'X'. > > Period missing from the end of sentence of the Option Length description in > Section 4.3. Done. > > In the IANA considerations section I propose add a note to RFC editor saying > that the sentences saying " The parenthesized numbers are only suggestions." > needs to be removed prior publication. > > Done! Naturally Yours, Charlie P. On 3/22/2021 9:41 AM, Tero Kivinen via Datatracker wrote: > Reviewer: Tero Kivinen > Review result: Has Nits > > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area directors. > Document editors and WG chairs should treat these comments just like any other > last call comments. > > The title of the draft has some acronyms which are not expanded (AODV, P2P) and > if you expand them the title comes way too long. I would propose a usable > title, which might not need to use all possible acronyms, but would better > explain what this document is trying to do. > > This draft defines a new mode of operation to the allow peer to peer on demand > routing in low power and lossy networks. I have not enough knowledge of RPL to > really know how the new mode differs from the old methods. The security > considerations section points to the RFC6550, and then explains that if rogue > router has key it can do all kind of things. > > Nits: > > In section 1 the text "RPL [RFC6550] (Routing Protocol for Low-Power and Lossy > Networks)" defines acronyms differently than what is used everywhere else. In > all other cases the document uses format where the acronym is in parenthesis > after the full text, i.e. "Routing Protocol for Low-Power and Lossy Networks > (RPL) [RFC6550]" format. I would propose using the same format also for here. > > In section 1 there is acronym DAG which is not expanded, expand it on first > use. Also there are unexpanded acronyms DAO, P2MP, which are not used anywhere > else, perhaps just expand them here. In same paragraph there is also acronym > MOP which is not expanded here on its first use, but it is expanded later. > Expand it here on its first use. > > What is the difference between different reserve bits X and r in sections > 4.1/4.2 and 4.3? > > Period missing from the end of sentence of the Option Length description in > Section 4.3. > > In the IANA considerations section I propose add a note to RFC editor saying > that the sentences saying " The parenthesized numbers are only suggestions." > needs to be removed prior publication. > > From nobody Wed Aug 18 13:00: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 DACC03A1B85; Wed, 18 Aug 2021 13:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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_H2=-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=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 S9nqPa-_me_s; Wed, 18 Aug 2021 12:59:56 -0700 (PDT) Received: from mta-201a.oxsus-vadesecure.net (mta-201a.oxsus-vadesecure.net [51.81.229.180]) (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 379623A1B48; Wed, 18 Aug 2021 12:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; bh=oDXUiHHPqnTKV6LhONImTF7RbKyIkRv0hMfpbI xhiZU=; c=relaxed/relaxed; d=earthlink.net; h=from:reply-to:subject: date:to:cc:resent-date:resent-from:resent-to:resent-cc:in-reply-to: references:list-id:list-help:list-unsubscribe:list-subscribe:list-post: list-owner:list-archive; q=dns/txt; s=dk12062016; t=1629316794; x=1629921594; b=Vr3fNSWrLFR7UZuFw3tHrdjaPPaYxYq3GcT4aIzZv6Y/uIXYfivFaRU gh2ICcV6gYV7QHlPMvg5qKxTY5H2hpqYij6JkBQtdMvCC4OsxJ8ghrlcFR44ynl54x3rVZN inJD0gtfmLVeQSAJePZoJGHtO48goIvym7y+Zy9GCSHmOWXNrSzfMBUzBMkZJmWhcu/+pk7 r4Nln75ERZ9W/FIY3eP3M7amafJEVc6vJO2kAMj2+3MN6rT8m+oXp9g89+RZ6HUbUCXrFc7 CTWIo7w2Gtf6ZPtxFHM9vYwxLuSXZr848hhB1bENeGe4lR72NaddEw7nN1iCyDyI6tbBHv2 VGQ== Received: from [192.168.1.72] ([99.51.72.196]) by smtp.oxsus-vadesecure.net ESMTP oxsus2nmtao01p with ngmta id 2bc93ab5-169c7efdc7b99bde; Wed, 18 Aug 2021 19:59:54 +0000 To: John Scudder , The IESG Cc: draft-ietf-roll-aodv-rpl@ietf.org, roll-chairs@ietf.org, roll@ietf.org, Ines Robles , aretana.ietf@gmail.com References: <161886431878.23690.10633892549620498188@ietfa.amsl.com> From: Charlie Perkins Message-ID: <2eb22feb-05e7-d811-9d7c-6b5b7d45bf0c@earthlink.net> Date: Wed, 18 Aug 2021 12:59:51 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <161886431878.23690.10633892549620498188@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US 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, 18 Aug 2021 20:00:13 -0000 Hello John, Please excuse the unusually long delay it has taken for us to respond to your comments.  The responses below have been broken up comment by comment in an attempt to make it easier to keep track of the association between comments and responses. > 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. ---------------------------------------------------------------------- RESPONSE to introductory comment: ---------------------------------------------------------------------- Here is some new text to resolve the comment.    Routing Protocol for Low-Power and Lossy Networks (RPL) [RFC6550] is    an IPv6 distance vector routing protocol designed to support multiple    traffic flows through a root-based Destination-Oriented Directed    Acyclic Graph (DODAG).  Typically, a router does not have routing    information for most other routers.  Consequently, for RPL traffic    between routers within the DODAG (i.e., Point-to-Point (P2P) traffic)    data packets either have to traverse the root in non-storing mode, or    traverse a common ancestor in storing mode.  Such P2P traffic is    thereby likely to traverse longer routes and may suffer severe    congestion near the root (for more information see [RFC6997],    [RFC6998]). The network environment that is considered in this document    is assumed to be the same as described in Section 1 of    . ---------------------------------------------------------------------- COMMENT 1: ---------------------------------------------------------------------- 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. ---------------------------------------------------------------------- RESPONSE to Comment 1: ---------------------------------------------------------------------- AODV-RPL currently omits some features compared to AODV -- in particular, flagging Route Errors, "blacklisting" unidirectional links (, multihoming, and handling unnumbered interfaces. We will use the quotation marks as suggested. ---------------------------------------------------------------------- COMMENT 2: ---------------------------------------------------------------------- 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"Â? ---------------------------------------------------------------------- RESPONSE to Comment 2: ---------------------------------------------------------------------- Yes. We will modify the text. Thanks for pointing it out. ---------------------------------------------------------------------- COMMENT 3: ---------------------------------------------------------------------- 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?) ---------------------------------------------------------------------- RESPONSE to Comment 3: ---------------------------------------------------------------------- Updated definition:       The upstream and downstream routes traverse the same routers and over       the same links. ---------------------------------------------------------------------- COMMENT 4: ---------------------------------------------------------------------- 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. ---------------------------------------------------------------------- RESPONSE to Comment 4: ---------------------------------------------------------------------- We could quote this definition and cite RFC 6550. It should say that "one of its IPv6 addresses". ---------------------------------------------------------------------- COMMENT 5: ---------------------------------------------------------------------- 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? ---------------------------------------------------------------------- RESPONSE to Comment 5: ---------------------------------------------------------------------- It shouild say that TargNode can join the RREQ instance at a Rank whose integer portion is less than or equal to the MaxRank. ---------------------------------------------------------------------- COMMENT 6: ---------------------------------------------------------------------- 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, ---------------------------------------------------------------------- RESPONSE to Comment 6: ---------------------------------------------------------------------- Same as response to comment #4. ---------------------------------------------------------------------- COMMENT 7: ---------------------------------------------------------------------- 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"Â? ---------------------------------------------------------------------- RESPONSE to Comment 7: ---------------------------------------------------------------------- You are right. We will fix this. ---------------------------------------------------------------------- COMMENT 8: ---------------------------------------------------------------------- 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"Â? ---------------------------------------------------------------------- RESPONSE to Comment 8: ---------------------------------------------------------------------- Thanks for pointing this out. We will fix this. ---------------------------------------------------------------------- COMMENT 9: ---------------------------------------------------------------------- 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. ---------------------------------------------------------------------- RESPONSE to Comment 9: ---------------------------------------------------------------------- Agree. We will fix this. ---------------------------------------------------------------------- COMMENT 10: ---------------------------------------------------------------------- 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. ---------------------------------------------------------------------- RESPONSE to Comment 10: ---------------------------------------------------------------------- Agree. We will use "criteria are beyond". ---------------------------------------------------------------------- COMMENT 11: ---------------------------------------------------------------------- 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. ---------------------------------------------------------------------- RESPONSE to Comment 11: ---------------------------------------------------------------------- We will include reference to 6tisch. ---------------------------------------------------------------------- COMMENT 12: ---------------------------------------------------------------------- 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"Â. ---------------------------------------------------------------------- RESPONSE to Comment 12: ---------------------------------------------------------------------- Agree. We will fix this. ---------------------------------------------------------------------- COMMENT 13: ---------------------------------------------------------------------- 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"Â. ---------------------------------------------------------------------- RESPONSE to Comment 13: ---------------------------------------------------------------------- New text:     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 using an averaging technique. ---------------------------------------------------------------------- COMMENT 14: ---------------------------------------------------------------------- 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. ---------------------------------------------------------------------- RESPONSE to Comment 14: ---------------------------------------------------------------------- [A]  be set as 0.  If the S bit in the received RREQ-DIO is set to 0,      the router MUST determine the upward direction (towards the      OrigNode) of the link. ---------------------------------------------------------------------- COMMENT 15: ---------------------------------------------------------------------- 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. ---------------------------------------------------------------------- RESPONSE to Comment 15: ---------------------------------------------------------------------- We are not assuming nodes with single interface.  The link-local multicast should go out over all local interfaces. The document should be reviewed to ensure that this is not ambiguous. ---------------------------------------------------------------------- COMMENT 16: ---------------------------------------------------------------------- 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. ---------------------------------------------------------------------- RESPONSE to Comment 16: ---------------------------------------------------------------------- New text:    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 transmitting the RREQ-DIO via link-local    multicast, a TargNode MUST delete the Target Option encapsulating    its own address, so that downstream routers with higher Rank values    do not try to create a route to this TargNode. ---------------------------------------------------------------------- COMMENT 17: ---------------------------------------------------------------------- 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? ---------------------------------------------------------------------- RESPONSE to Comment 17: ---------------------------------------------------------------------- New text:   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 incoming RREQ-DIO message having   multiple ART Options coming from a router with higher Rank than the Rank of   the stored targets is ignored. ---------------------------------------------------------------------- COMMENT 18: ---------------------------------------------------------------------- 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. ---------------------------------------------------------------------- RESPONSE to Comment 18: ---------------------------------------------------------------------- Agree. Will be updated. ---------------------------------------------------------------------- COMMENT 19: ---------------------------------------------------------------------- 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. ---------------------------------------------------------------------- RESPONSE to Comment 19: ---------------------------------------------------------------------- All instances of "L bit" will be changed to "L field".  If L is zero, RREP_WAIT_TIME should be set to the lifetime of the DODAG. <<<<<<<<<<<<< Anand -- this is my GUESS.  Please verify >>>>>>>>>>>>>> [Anand] Yes. We need to change "L bit" to "L field" ---------------------------------------------------------------------- COMMENT 20: ---------------------------------------------------------------------- 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)? Question: Are we assuming single interface? ---------------------------------------------------------------------- RESPONSE to Comment 20: ---------------------------------------------------------------------- AODV-RPL routers can have multiple router interfaces.  Per-node configuration of "RREP-DIO tranmission interfaces" is an administrative feature which is beyond the scope of the document. ---------------------------------------------------------------------- COMMENT 21: ---------------------------------------------------------------------- 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? ---------------------------------------------------------------------- RESPONSE to Comment 21: ---------------------------------------------------------------------- Replace "In this type of scenario" by "When rogue routers might be present" ---------------------------------------------------------------------- COMMENT 22: ---------------------------------------------------------------------- 22. Appendix A: s/pakcet/packet/ ---------------------------------------------------------------------- RESPONSE to Comment 22: ---------------------------------------------------------------------- Will be updated. ---------------------------------------------------------------------- COMMENT 23: ---------------------------------------------------------------------- 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. ---------------------------------------------------------------------- RESPONSE to Comment 23: ---------------------------------------------------------------------- We will add acknowledgements. On 4/19/2021 1:31 PM, John Scudder via Datatracker wrote: > 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 Wed Aug 18 13:42: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 294E23A1CE9; Wed, 18 Aug 2021 13:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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_H2=-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=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 hoUxnmQSskf0; Wed, 18 Aug 2021 13:42:04 -0700 (PDT) Received: from mta-201a.oxsus-vadesecure.net (mta-201a.oxsus-vadesecure.net [51.81.229.180]) (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 0C9943A1CE3; Wed, 18 Aug 2021 13:42:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; bh=8D0+4fpZzrPphMQuzOeuvPt5GpCPwGdoOpAPSD cmQXw=; c=relaxed/relaxed; d=earthlink.net; h=from:reply-to:subject: date:to:cc:resent-date:resent-from:resent-to:resent-cc:in-reply-to: references:list-id:list-help:list-unsubscribe:list-subscribe:list-post: list-owner:list-archive; q=dns/txt; s=dk12062016; t=1629319322; x=1629924122; b=kqp3rkF0/o0o9fFM7brKWlkdn7E9T9f432uuWpVg6jm0tQBOGWt433f PYmZ4cK5LrSB7K4GLfTxI5SxGQbJ1OZ/VvepupjQqu1SLSoQSxk6snoJFNyYA4tCOkJgzFS tvJ3xcziP5QsNXXMsg6l+zNM7sdpUWGjUimqzAGln09tPWb3GwXOE7TuhWfyTibpZL7Zwu4 i2tRG+FQ4BGmZrT5Jwzy2IKugtTgJ/YRAEVm2eFyX1kZWPpxY2BS3ArrRSvZlQUiXqdMepf q6E0kwY1audProcJLWWowyaFEcB/bt1SCRiOD2cEFTCPIFkXQmC193wAmsHtaMWABBHn40b e9Q== Received: from [192.168.1.72] ([99.51.72.196]) by smtp.oxsus-vadesecure.net ESMTP oxsus2nmtao01p with ngmta id 86e2bdb9-169c814a5f334149; Wed, 18 Aug 2021 20:42:02 +0000 To: =?UTF-8?Q?=c3=89ric_Vyncke?= , The IESG Cc: draft-ietf-roll-aodv-rpl@ietf.org, roll-chairs@ietf.org, roll@ietf.org, Ines Robles , aretana.ietf@gmail.com, consultancy@vanderstok.org References: <161899828182.30762.17925223604861378275@ietfa.amsl.com> From: Charlie Perkins Message-ID: <4e7b8d85-9b65-bd8b-067c-c8c3a33056a2@earthlink.net> Date: Wed, 18 Aug 2021 13:41:59 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <161899828182.30762.17925223604861378275@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US 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, 18 Aug 2021 20:42:10 -0000 Hello Éric, Please excuse the unusually long delay it has taken for us to respond to your comments. Regarding the following: >  Éric Vyncke Discuss > Discuss (2021-04-21) > 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). Please excuse the delay.  It has been on my radar for the last couple of months in a very crowded field. > 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. I think there has been discussion about this in previous commentary, so I will count this comment as having been resolved.  Please lt me know if there is disagreement and more resolution is needed.  I am happy to change all instances of P2P to mean peer-to-peer.  However, both terms do not explicitly bring to mind the main point -- which is that the tree root does NOT have to be in the route. > Comment (2021-04-21) > == COMMENTS == > -- Section 4.3 -- > Figure 3 has a 'X' while the text has a 'r' ;) Fixed. > Any reason why using "Floor((7+(Prefix Length))/8) octets" rather > than the simple "Ceil(Prefix Length/8)" ? Thanks for this suggestion.  I don't remember why we didn't use that instead, nobody seems to have thought of it! > -- Section 6.1 -- > "Each node maintains a sequence number" does it impact constrained nodes ? Yes, to the extent that it requires 16 bits of memory and the amount of power to maintain that memory.  Should we mention that? > == NITS == > -- Abstract -- > "the links between source and target node are asymmetric" should this be "nodes" (plural) ? Fixed. > -- 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 ;) Fixed. > -- Section 5 -- > "R is an intermediate router" or "Rs are intermediate routers" ? How about "Each R is an intermediate router"? Regards, Charlie P. On 4/21/2021 2:44 AM, Éric Vyncke via Datatracker wrote: > É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 Aug 18 13:46:32 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 273FA3A1D15; Wed, 18 Aug 2021 13:46:27 -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, NICE_REPLY_A=-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=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 gqueg9U3rw-w; Wed, 18 Aug 2021 13:46:21 -0700 (PDT) Received: from mta-202a.oxsus-vadesecure.net (mta-202a.oxsus-vadesecure.net [51.81.232.240]) (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 A3ED13A1D0C; Wed, 18 Aug 2021 13:46:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; bh=VnJRI69UzpFOttoOFCnPbVvTQ7jaTxB0Ydn8F8 a6WrI=; c=relaxed/relaxed; d=earthlink.net; h=from:reply-to:subject: date:to:cc:resent-date:resent-from:resent-to:resent-cc:in-reply-to: references:list-id:list-help:list-unsubscribe:list-subscribe:list-post: list-owner:list-archive; q=dns/txt; s=dk12062016; t=1629319580; x=1629924380; b=XYlxTAgTituA0f+qJpBamQU7i6xBvJg1Fb/Mvsx8GaWBrskIFmwoZAQ eJNISHTEGX6X+ZkdrYV+x5GDvRZl1F5XjPliqqNUUjmeszHWoK2dgRxv9qkUuQBlSWZEfjn WLtU+D3t5257W1os2iyXZNAVSc8b2Rv84fGVC1/BCW4H3ajBmrmbUDUNoImz0GRnYUGVRcA Sa7YoKYdCfE2xJ8T6ZIQFimgD/uzlgs3+DK7ICfvnPdjHpwUxrjs6o+3e10ymEIl21rWnjC WWNyRq9wq7QPgR404lwX64I2I4jecsTmfY32iJR9NlJ6KwtER07bC8Xy8SOl3WRphHFUB8g whg== Received: from [192.168.1.72] ([99.51.72.196]) by smtp.oxsus-vadesecure.net ESMTP oxsus2nmtao02p with ngmta id 99f79d5f-169c8186661baf04; Wed, 18 Aug 2021 20:46:19 +0000 To: Benjamin Kaduk , The IESG Cc: draft-ietf-roll-aodv-rpl@ietf.org, roll-chairs@ietf.org, roll@ietf.org, Ines Robles , aretana.ietf@gmail.com References: <161913172006.16574.8625402788675096789@ietfa.amsl.com> From: Charlie Perkins Message-ID: <54ab3f3d-3220-6fbb-a01f-8effc87a5f10@earthlink.net> Date: Wed, 18 Aug 2021 13:46:17 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <161913172006.16574.8625402788675096789@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [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 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, 18 Aug 2021 20:46:28 -0000 Hello Benjamin, Please excuse the unusually long delay it has taken for us to respond to your comments. Regarding the following: >  Benjamin Kaduk Discuss > Discuss (2021-04-22) > 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. Thank you very much for pointing out this inconsistency.  Once we decided that the 'S' bit was not explicitly needed in the RREP option, we should have changed this wording, but we just missed it.  Instead of referring to the 'S' bit of the RREP, the text has to instead refer to a status bit in the internal data structure for the RREQ-Instance, which we also called the 'S' bit. <===== Text added after the last para of Step 1 of 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.       When a router joins the RREQ-Instance, it also associates within       its data structure for the RREQ-Instance the information about       whether or not the RREQ has the S-bit set to 1. This information       associated to RREQ-Instance is known as the S-bit of the       RREQ-Instance. It will be used later during the RREP-DIO message       processing (Section 6.4) for RPLInstance pairing as described       in Section 6.3.3. ... <=== Text added to Step 1 of 6.4.===> 6.4.  Receiving and Forwarding Route Reply    Upon receiving a RREP-DIO, a router which does not belong to the    RREP-Instance goes through the following steps:    Step 1:       If the S-bit of the RREQ-Instance is set to 1, the router MUST       proceed to step 2.       If the S-bit of the RREQ-Instance is set to 0, the router MUST       determine whether the downward direction of the link (towards the       TargNode) over which the RREP-DIO is received satisfies the       Objective Function, and the router's Rank would not exceed the       MaxRank limit.  If so, the router joins the DODAG of the RREP-       Instance.  The router that transmitted the received RREP-DIO is       selected as the preferred parent.  Afterwards, other RREP-DIO       messages can be received. > 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. We are reviewing every instance of this wording, and have made the suggested correction where appropriate. > 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. This is intended to be resolved by maintaining the 'S' bit status in the RREQ-Instance. >            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.) Given the maintenance of the 'S' bit status in the RREQ-Instance, it should not be necessary to make the determination based on whether or not the message was received as a multicast. > 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. The point of the shift parameter is to be able to "modify" the value of the RPLInstanceID so that a unique association can be made between RREQ-Instance and RREP-Instance. We are confident that having 64 values to choose from will enable the node to make the unique association. > Comment (2021-04-22) > 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.) We will use your wording when adding additional text to the Introduction. AODV-RPL can be used alongside RPL and add routes to the existing RPL-discovered routes.  However, there does not seem to be much value in maintaining two routing protocols even if they are compatible. > 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? Routes are intended to last long enough to support the applications running on the OrigNode and TargNode that required the route.  The same considerations apply to RPL, and so we expected that AODV-RPL would use the same mechanism for route longevity that is used by RPL. Your explanation for route lifetime is fine to me.  In addition, DODAG lifetime cannot be lower than the route lifetime since that could lead to stale information as observed. > 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. Agreed.  It isn't useful. "P2P routes discoverable by native RPL" is better. > 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. It is intended to allow for the shift parameter.  §6.3.3 clearly states "the RREQ-Instance and the RREP-Instance in the same route discovery MUST be paired using the RPLInstanceID." Accordingly, we modify the text as follows.    "The RPLInstanceID in RREP-DIO MUST be paired to the one in the associated     RREQ-DIO message as described in §6.3.3." > 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? Yes, as long as the node receiving an RREQ or RREP message can valuate whether or not the link bearing an incoming message satisfies the OF. >>    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? It is possible when the links are symmetric. > 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). Yes, other options are allowed. We will clarify this point by referring to Section 4.3 which says, "A RREQ-DIO message MUST carry at least one ART Option.  A RREP-DIO message MUST carry exactly one ART Option. Otherwise, the message MUST be dropped." > Who sets the S bit, and can it change as the DODAG is being constructed? > ("See Section 5" would be fine.) Only the OrigNode sets the 'S' bit. >>    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? Yes, the measure time duration depends on each node's ability to keep track of the time. >>    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. Good point!  Yes, the TargNode can join if the rank is less than or equal to MaxRank. > 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" O.K. >>    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? Both the DODAGs are part of the same route discovery, and RPLInstanceID requires that both DODAGs be alive.  There can however be a route with asymmetric data traffic profile between OrigNode and TargNode.  In this case, it is possible that the data occupancy times of the two DODAGs are different.  The OrigNode should consider this factor while fixing the duration.  The L-value for the RREQ-Instance has to be larger than the L value for the RREP-Instance. >>    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)? Yes, that is the requirement. > 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? The RREQ carries the destination sequence number for the last OF-compliant route that OrigNode stored to the TargNode - i.e., the downstream route. > Also, should we say that zero is used if there is no known information about > the sequence number of TargNode (and not otherwise)? Agreed. >>    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. Agreed. >>    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). Address field is 128 bits for IPv6 addresses. > 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.) How about, "indication to the contrary is received"? >>    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? Yes, both of your statements are correct.  We will try to devise more exact wording, or if you have a suggestion that would be appreciated. > > 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"? Good idea. >>    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)? Yes, because in the symmetric case unicast RREP is specified. >>    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.) Section 6.3.1 says:    "For a symmetric route, the RREP-DIO message is unicast to the next hop     according to the accumulated address vector (H=0) or the route entry (H=1)." >>             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. We will describe Figure 5 by with the help of link asymmetry detection methods discussion given in the same section, Section 5. The proposed text:    As shown in the Figure 5, an intermediate router determines the 'S' bit    value RREQ-DIO should carry with the help of link asymmetry detection    methods discussed in Section 5. It is expected that the intermediate    router has already made the link asymmetry decision by the time RREQ-DIO    arrives. > 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. O.K. >>    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? It is also needed to put in the correct OF and other values specific to the desired route.  If those are all the same, just incrementing the sequence number is fine. > 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. It is supposed to mean that the node always checks the upstream link, and joins if the OF is satisfied.  If the OF is not satisfied, >>       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? Yes, we will use that terminology. > 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. I don't see what is wrong about using L=0 to disallow the delay. > 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. That is a good point.  It has to be the RREP-Instance corresponding to the RREQ-DIO. >>    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 behavior should be the same. >>    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? It should have said, "except for the value of the 'S' bit associated with the RREP-instance". > 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). When preparing the RREP-DIO, a TargNode could find the RPLInstanceID candidate for the RREP-Instance is already occupied by another RPL Instance from an earlier route discovery operation which is still active.   This unlikely case might happen if 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 which denotes Objective Function of the DODAG, MUST NOT be used again.  Reusing the same RPLInstanceID for two distinct DODAGs originated with the same DODAGID (TargNode address) would prevent intermediate routers to distinguish between these DODAGs (and their associated Objective Functions).  RPLInstanceID collisions do not occur across RREQ-DIOs; the DODAGID equals the OrigNode address and is sufficient to disambiguate between DODAGs. >>    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? You are correct.  It should say 255 instead of 63. >>    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.) Correct again. > 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? Right, it should have been RREP-Instance, not RREQ-Instance as shown. But in fact, we do not need this conditional check at all. Processing the newly arriving RREP-DIO even if the router has already joined RREP-Instance can result in better downward route to TargNode. >    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! Correct again.  This should refer to the S-bit of the associated Instance. >>       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) Check. >>    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.) Check. > 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. Yes. >>    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. Agreed.  These requirements belong better in the main body text. Regards, Charlie P. On 4/22/2021 3:48 PM, Benjamin Kaduk via Datatracker wrote: > 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 Wed Aug 18 17:06:38 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 76C223A20DA; Wed, 18 Aug 2021 17:06:35 -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=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 RKw7zvWyQr7Z; Wed, 18 Aug 2021 17:06:29 -0700 (PDT) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (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 A01B33A20D8; Wed, 18 Aug 2021 17:06:29 -0700 (PDT) Received: by mail-vs1-xe30.google.com with SMTP id t4so61688vsm.5; Wed, 18 Aug 2021 17:06:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kVLENoTXmVl1/3lB5MuUDWTLeZDTGtVFaqMBtzKNcMs=; b=Z2JaER3tK5aiZ0CMIs38QPFifq/qVi0/WWLwcruViYoI1YK03O6JcCAcDULONVvsCU 9G5aP2z+OxFJ9qQI08npWgXVp6oCPUkDCwq+8M9zCVuBXCWLhEnIE0AcAzjzPszrMjO3 BlnXoiOnlElbbK34g+F9gOWupLom4jFj3qWfzKDZTjF4fOv96V0z0RYykxWWK4oo9uGM du+8qQYlHJu0qu0/2Th3x4FABmaOKXN5OJPgO+CdV2+ctvtwZKt7GoVpEMp0SgZcPLWk ufpne4ebkYIGp9K5JkSsYKIp3rW5ciMaEMgpJHpWzyKlp/h7+jAHCf7xGH4dkL5gHSXN RDEw== 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:cc; bh=kVLENoTXmVl1/3lB5MuUDWTLeZDTGtVFaqMBtzKNcMs=; b=uZuW7I5t63mZZJ9+6rBVz9wiS4jnyr8W0VloQTlEMAd5k92O1L4HMGxcK2jZ1KsIWw 82zUtY5+K1hupXTN4WuZteVYADBE74ulM6b74R/FQAp77sLzz9FaHuqDQd0c5rlEny2W gppLvu93yBFCozvdMm9Q+yrCm0dWfWAyhjgqBnixrzzlCf2B38p0RrSVgnPe09vytiRo 7d1+jDSlXkLmCL8piHl2yzwkMNY1gV+3wvT1X2eWsr8KyMu+EPFlJ67/JmsnppL8TT1a jqRfh2vua9vOPti3vNIZ7h5XCK+wHbj9lvdG4F9LUolrxEjXaQLc6zSUDXkXB+fPBCMb VKtw== X-Gm-Message-State: AOAM531a85ierPkY4rwqGS3UvCLtzYyqlnVoSSnUis73ym84Kn33AEZU 1xh5WUMEOCdWhdJSo19At/50CXTQ4BSkhgfAFvY= X-Google-Smtp-Source: ABdhPJxlzVzLo0NBvom0L7S9cmP1FGEz2PBSJr9dmas2rofAfkjI2soM8UAS2v7F3ZtBBJhCj4ukIIbdSGDrY2GMlHQ= X-Received: by 2002:a67:f8d5:: with SMTP id c21mr10493877vsp.40.1629331587260; Wed, 18 Aug 2021 17:06:27 -0700 (PDT) MIME-Version: 1.0 References: <161907746666.4867.10229249239001365546@ietfa.amsl.com> In-Reply-To: From: "Murray S. Kucherawy" Date: Wed, 18 Aug 2021 17:06:15 -0700 Message-ID: To: Charles Perkins Cc: The IESG , draft-ietf-roll-aodv-rpl@ietf.org, roll-chairs@ietf.org, roll@ietf.org, Ines Robles , Alvaro Retana Content-Type: multipart/alternative; boundary="0000000000007ae39b05c9de529e" Archived-At: Subject: Re: [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 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, 19 Aug 2021 00:06:36 -0000 --0000000000007ae39b05c9de529e Content-Type: text/plain; charset="UTF-8" Hi Charles, On Wed, Aug 18, 2021 at 1:48 PM Charles Perkins wrote: > > 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, > > suggest that you provide some guidance around why an implementer might > > legitimately decide against doing what the SHOULD says. > > See also the response to Roman Danyliw. An implementer might decide to > use a proprietary security configuration, and not use the security > specification provided by RPL. Alternatively, certain closed systems > will not be vulnerable to insertion of a rogue router, and cost savings > or performance improvements might be realized by eliminating unnecessary > security operations. > You might consider including such guidance around the SHOULD, if it's not there already in some form. > The document shepherd writeup is more than two years old. > > This project fell off of my plate due to changes in employment and > many urgent distractions. Please excuse the delay. > You're the author, not the shepherd or the co-chair. :-) The concern I'm raising here is that such a long time between the writeup and IESG Evaluation forces me to wonder how stale the writeup's content is. We, collectively, should get in the habit of checking on this sort of detail before it hits IESG Evaluation. -MSK --0000000000007ae39b05c9de529e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Charles,

On Wed, Aug 18, 2021 at 1:48 PM Charles Perkins <charliep@lupinlodge.com> wrote:
=C2=A0&g= t; I concur with Roman's DISCUSS, especially around the use of SHOULD.<= br> =C2=A0> I'd go further and ask why that's not a MUST, or in the = alternative,
=C2=A0> suggest that you provide some guidance around why an implementer= might
=C2=A0> legitimately decide against doing what the SHOULD says.

See also the response to Roman Danyliw.=C2=A0 An implementer might decide t= o
use a proprietary security configuration, and not use the security
specification provided by RPL.=C2=A0 Alternatively, certain closed systems<= br> will not be vulnerable to insertion of a rogue router, and cost savings
or performance improvements might be realized by eliminating unnecessary security operations.

You might consider= including such guidance around the SHOULD, if it's not there already i= n some form.

=C2=A0 > The document shepherd writeup is more than two years= old.

This project fell off of my plate due to changes in employment and
many urgent distractions.=C2=A0 Please excuse the delay.

You're the author, not the shepherd or the co-chair.= =C2=A0 :-)=C2=A0 The concern I'm raising here is that such a long time = between the writeup and IESG Evaluation forces me to wonder how stale the w= riteup's content is.=C2=A0 We, collectively, should get in the habit of= checking on this sort of detail before it hits IESG Evaluation.
=
-MSK
--0000000000007ae39b05c9de529e-- From nobody Wed Aug 18 23:29:12 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 2F31E3A1B8E; Wed, 18 Aug 2021 13:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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_H2=-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 (1024-bit key) header.d=lupinlodge.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 8V2ysgEk_y2W; Wed, 18 Aug 2021 13:06:19 -0700 (PDT) Received: from delivery.mailspamprotection.com (delivery.mailspamprotection.com [146.66.121.162]) (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 E66B63A1B82; Wed, 18 Aug 2021 13:06:18 -0700 (PDT) Received: from 246.206.208.35.bc.googleusercontent.com ([35.208.206.246] helo=giowm1055.siteground.biz) by se18.mailspamprotection.com with esmtps (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1mGRpF-000AiG-Kg; Wed, 18 Aug 2021 15:06:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lupinlodge.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=DhLROql0Jj4Y6ZF1Imtu9/E0cFlKFcmvXQSbZHetiJw=; b=wkXk7HVv/Lph8fUNAgctWGfo+5 nmJ8cJH+Sme4Iuh8kBfZNwJV3H87Eu+KyKLcopSKbZUKMtuG9/6gWZWHZ1fRMWZDb7GHadQ14m09J T1o8LUM5juPC17kT9Uw5dN7hLEHseFWiJcqT0HbD1KQeRjfUOFNeAACznnN902lbxZHQ=; Received: from [99.51.72.196] (port=63551 helo=[192.168.1.72]) by giowm1055.siteground.biz with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.90-.1) (envelope-from ) id 1mGRpE-000FvN-Jz; Wed, 18 Aug 2021 20:06:12 +0000 To: Lars Eggert , The IESG Cc: draft-ietf-roll-aodv-rpl@ietf.org, roll-chairs@ietf.org, roll@ietf.org, Ines Robles , aretana.ietf@gmail.com References: <161841517905.8620.14903415282133221941@ietfa.amsl.com> From: Charles Perkins Message-ID: <24245546-4508-801a-83d0-5a3776288048@lupinlodge.com> Date: Wed, 18 Aug 2021 13:06:10 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <161841517905.8620.14903415282133221941@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: 35.208.206.246 X-SpamExperts-Domain: giowm1055.siteground.biz X-SpamExperts-Username: 35.208.206.246 Authentication-Results: mailspamprotection.com; auth=pass smtp.auth=35.208.206.246@giowm1055.siteground.biz X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.12) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9uNNLGYqj4RE/UTkTDq7umPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5xfhCjHc1rE8j8s8Zbm/wGXznzsYfkdUR16HjGz62pljkko TB1XoRIdpR5ZFOj8MnTOPzAiZwO0erKqGmrB0kNW7yD795EJLHugJKDmd9LZyfBlQ+yfeyWAPtDm XI1PtJNHkh02GMZpkpvzzOke7JxoQPrPgIKCOcN1qssFDA9lsDKCUy+RuevJVoQ1jGOH3u89lTcF 0nAicfQwnBE0p73+QyN5+sjOiEpUZ5Uk2j4wBT6uO5354BnWwUbwEhx5IoailnmzNnFcx5VcabXk cY6UvuMlM/ULZixCoUQzrzlFs8msY8kdAEA5kt/74QDG6uC80ROpCg9oXr6AOwqokc/amvmCla9O EyJVlncg7GFRaGUpm2NFwR4vh14nBpnjHnLr7Ev1WTPqxqiX5x7vZD2rI0fsTHgoRFFFPXopWULe ljuA70k+HW2oVWIWwWRpNStHZQU7M0Q2nOK+bh8czW+0M23gyg6iTVD83nl3tPApU+FvX34UTkPT xeYM/1bWYo0NgN9L3/12vRCURm+2Ccu+BPxuyrFKkkqEvRPEq1oSoIY2Fstvi8JdJ94OkJHwXX/p xOsB8gG0slV7ra6jI4BS1Camx3RQtw4/zVtTtR8UQx3X00KIweIqKiVBCOpeq2dHOu6/4Yn4xBuG Lu6ZpfiGPzOWY9pRusm6Xog2JaDeDiUG9ZlEUUTeGJ1w6jlQ2qDl5z+s+aWvnihjjOn1ih1J19p7 joqvJIR2NF0e4NdplFs765aq/7Ihe5JpNEYIVsOMyGnDIpSchlco6RIDoNg/gpqJlqCh0E7QP78U adwZo0RVGZM+1wcbqYXM3ytmvbBz/byN7FajYmOyHLF0nUatASJFC/49WOPBr5nlEUI4xIdvScbF 9uOttIe17rfNDojlsWJoA/N4L72OMz//UQUP4StMAjppagICNJ3x+Wx8+8dbWWCjKJ3i/S5kopHS u52Un+nFMMkRd5k6PHc0U1eHEuy1kJU1AECVdPpwDWSH/uAI7cGNN9BxLjilPAh3ScFXvV2KdaAj /nU2mVpeWRaUnWEFS9JKrkl3Ur0zyZYa70EosCM6yKE4UgLi62ftY8GSVMUV8U9klGSrRKkRdrjy 4U0zK4PaU3TrmieveHT3EVyQnFm970cs29CRQdigsnfVnExWYQsqagncXJk1ANiFw6nIoDr0sXUZ 7YZoZ/GZ+vxMoGEiehQ9Elnyjmh6qKiCFhXHcMhioAWBU337SKMu3jR5NeVaJQBh0uawl0Cg8vG/ FKl+0YpjSy3Xdimy+RnFRZ06/nbCSVtpoXfNhlxO6xz6gnb35zbtEekAsVsRnbdSYnSOwa/RltQp UlvcMGaEjYJNBWxsMROy4gulq6Zm X-Report-Abuse-To: spam@quarantine1.mailspamprotection.com Archived-At: X-Mailman-Approved-At: Wed, 18 Aug 2021 23:29:06 -0700 Subject: Re: [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 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, 18 Aug 2021 20:06:25 -0000 Hello Lars, Please excuse the unusually long delay it has taken for us to respond to your comments. Regarding the following: >  Lars Eggert No Objection > Comment (2021-04-14) > 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.) It is meant to improve the readability by selectively capitalizing certain terms what we felt appropriate.  This is often very subjective.  Do you have any suggestions for improvement? > ------------------------------------------------------------------------------- > 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? We should say it is set to 0. > Section 4.2, paragraph 9, nit: >>    X >>       Reserved. > Any recommendation what this should be set to on send? We should say it is set to 0. > 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? We can use XXX instead of Rsv. > Section 4.3, paragraph 6, nit: >>                Figure 3: ART Option format for AODV-RPL MOP > X is missing from the description of the fields. Fixed. > Section 1, paragraph 4, nit: > -    functionality to support routes with birectional asymmetric links. > +    functionality to support routes with bidirectional asymmetric links. > +                                           ++ Fixed. > 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 > +                                                      + Fixed. > 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 > +                                  ^ Fixed. > 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 > +                         + Fixed. > 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 > +                        +++++++++ Fixed. > 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 > + Fixed. Regards, Charlie P. On 4/14/2021 8:46 AM, Lars Eggert via Datatracker wrote: > 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 Wed Aug 18 23:29:28 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 A9CAB3A1BA7; Wed, 18 Aug 2021 13:10:25 -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, NICE_REPLY_A=-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 (1024-bit key) header.d=lupinlodge.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 V3qeRWDjcZgX; Wed, 18 Aug 2021 13:10:16 -0700 (PDT) Received: from delivery.mailspamprotection.com (delivery.mailspamprotection.com [146.66.121.166]) (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 148913A1BA4; Wed, 18 Aug 2021 13:10:15 -0700 (PDT) Received: from 246.206.208.35.bc.googleusercontent.com ([35.208.206.246] helo=giowm1055.siteground.biz) by se22.mailspamprotection.com with esmtps (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1mGRt3-000AK2-73; Wed, 18 Aug 2021 15:10:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lupinlodge.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Quz6jpXH6peYbnu/O49kzJblQD7LDpwJJDuVBo37lIM=; b=LQHmkE89rC52VOvVm9Vc5PsDyv nft9aZFroIylLXL8whk0tkMAwZpFX49h0kv2vE8TLCfzo6HsCb0wpZ8i9Afo9niMit9FNXhQWa+Qg AQdNpDqV7p5nEziOT9aLVxNkYnWUqy+1GUSpD/sTQlTDl7me3RU1FH4EvU7uMlnXaZek=; Received: from [99.51.72.196] (port=65266 helo=[192.168.1.72]) by giowm1055.siteground.biz with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.90-.1) (envelope-from ) id 1mGRt0-000HBb-S6; Wed, 18 Aug 2021 20:10:06 +0000 To: Francesca Palombini , Routing Over Low power and Lossy networks , The IESG Cc: roll-chairs@ietf.org, mariainesrobles@googlemail.com, draft-ietf-roll-aodv-rpl@ietf.org References: <161884704906.8680.6192562844809236074@ietfa.amsl.com> From: Charles Perkins Message-ID: Date: Wed, 18 Aug 2021 13:10:05 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <161884704906.8680.6192562844809236074@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: 35.208.206.246 X-SpamExperts-Domain: giowm1055.siteground.biz X-SpamExperts-Username: 35.208.206.246 Authentication-Results: mailspamprotection.com; auth=pass smtp.auth=35.208.206.246@giowm1055.siteground.biz X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.12) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT/6vWonFxwAIdK7n3lMrYA8PUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5w7eqjV3umHXtZAfna397uT3Y6eSugsHMsWGw2POxshfUXy Uvr/ef/b2Eaz1j+xAOIG18GTzjJsSc7K2nOvm/XIETTZmou68uehA+IInhf6t7vDKRSeOy6sWF/5 dB1Kd4gzKQSavIsH4FUptcg4aK0N2VX+xIg0zhdLWAAqqCgWjSHoiUpUNz933vbajeziC6tOtugH ezOoM7SsjEENB+pA/PX59ioeNUCElTJyTs66vFC8Ir1AzF9KatNNAmmpgEzilbHtbFYVmmyNP/jz d7CCsVA5h60zvwN7iRldiarkCrcuKT09mK6Rp/QZAwz4lK2/GkI8YkeCnwt/dISYHzgDasd57qnG wTIHdxcV9COU82MrqSAO8/Y1hG2ZUPHyGBGcvNnJhWA+PBOgUcyC6ShzrpqDlHgb5Mo/Ztlo3PMg 2vkZGeWkX0gxbpPlxfRKbdYiZhRybGSIt89rB6jbCSm55ofS+sIMk8ycHFCSF658UIzIacMilJyG VyjpEgOg2D8kBBLwQfaaGL918KaJf/BXS8KWaecotq4zBypQ19eU2GxrlyZPzyn5edZSesYokAKI tBMasm7pZA/O6yBhF8ofxGP8GhEQ1f+yBicGv+yRcyJ7aK1gpIj2t1c9RTfYPopUKxkRsyUboi7c P7bYvbC13Ukc5FMpkpX3IxHQhZm5IGZTa+9+OSMXwPAg8aNYXju8Ksk+aedMfNWSnJswrtlNaJMB VSQPiiteHTBAOUz64AzevvA7ArqeQFEd2navgAlgcaP8dZAj5xCBjGUCfIafi2CriV/LwG2NVUpo NQ0dasCt012iWitKoZsyASvmMhsHKR/6Nm1CH0oswin/s6fYT+qq9Ao/4bbaocVTRylcBOuUvoyt FfxSX3soQthsOQ8ZJhmkUxqYPh8FC8zws1Bqahde7OuvYsgqpXktF3lGxY9ExRsEPo6cys3vnasQ nXMMLQaRvu/qUhWCf5pLfDl10z6bhalFEM/pjPCQA+BAli7zCvukckMSmeDWzLz0EQ4GGzgmrxJJ ssXyURBEIIDYaFozx0Kf/Y8lA3Ig6kSL40paFD1NH7/lRC3Td+MElitn5jS+KxNqou0RjCSsjgaS PAlbDjazCbhs7qBpykynMjE5uYhWkNyoKV8Ovpu0gzlqdv3mEpuuS0JcE5791cerE4eT9uqlngE+ ZUIM1/D1mMjpgIJ+boB/oLddZZ1CMgHejieXwuDtHmdhatH01VjlZUIF0rcnCxMHho65CLsbsGeu pYYdzPm7YfRDaULOU2kHPI/VbX7Xoc+NHoQNZ1fK6WbF+PY4xv+40y1Qv8bvmHh/CfNrQCM4XdfV mVPsv8Uc2eOmWKBjs81R88cYLO8A X-Report-Abuse-To: spam@quarantine1.mailspamprotection.com Archived-At: X-Mailman-Approved-At: Wed, 18 Aug 2021 23:29:07 -0700 Subject: Re: [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 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, 18 Aug 2021 20:10:26 -0000 Hello Francesca, Please excuse the unusually long delay it has taken for us to respond to your comments. Regarding the following: >  Francesca Palombini No Objection > Comment (2021-04-19) > 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). The following paragraph was added to the Terminology section.                 AODV-RPL reuses names for messages and data structures, including         Rank, DODAG and DODAGID, as defined in RPL .         > > 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. See above. > > 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. The "7+" was included to account for Prefix Lengths that are not an even multiple of 8.  The "7+" increases the Floor calculation by 1 in such cases. However, Eric Vyncke suggest using the Ceil() function, which is better: OLD:       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. NEW:       The Target Prefix / Address field contains the least number of       octets that can hold all of the bits of the Prefix, in other       words Ceil(Prefix Length/8) octets. Regards, Charlie P. On 4/19/2021 8:44 AM, Francesca Palombini via Datatracker wrote: > 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. > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Wed Aug 18 23:29: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 B4FDB3A1C6A; Wed, 18 Aug 2021 13:28:33 -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, NICE_REPLY_A=-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 (1024-bit key) header.d=lupinlodge.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 UZxk5rcOQVkJ; Wed, 18 Aug 2021 13:28:28 -0700 (PDT) Received: from delivery.mailspamprotection.com (delivery.mailspamprotection.com [146.66.121.80]) (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 A243B3A1C66; Wed, 18 Aug 2021 13:28:27 -0700 (PDT) Received: from 246.206.208.35.bc.googleusercontent.com ([35.208.206.246] helo=giowm1055.siteground.biz) by se16.mailspamprotection.com with esmtps (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1mGSAe-0006qT-VM; Wed, 18 Aug 2021 15:28:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lupinlodge.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=x4l+UmfpyIqXfSqeVNgFpCPHss6KVGEmcgNNxtGs2Jk=; b=nJ6/9lfWWiU4EVNtHlaY1as0Ox Y8eUWdkNWHcpzrpy0kH8+Jaf4aESQEUz0UyykATmEu1150tWtCigqHajMTqZymfNkRMhBWBt+9w1X Wot8r5iH4OOyBdJp8UH4BLyxB/8BbGEDsLJO2KGqYKy1EAbtRYSZqbSfNqm1pRjHlCKk=; Received: from [99.51.72.196] (port=52040 helo=[192.168.1.72]) by giowm1055.siteground.biz with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.90-.1) (envelope-from ) id 1mGSAe-000PGc-G8; Wed, 18 Aug 2021 20:28:20 +0000 To: Roman Danyliw , Routing Over Low power and Lossy networks , The IESG Cc: roll-chairs@ietf.org, mariainesrobles@googlemail.com, draft-ietf-roll-aodv-rpl@ietf.org References: <161904623841.17653.13314629547868546211@ietfa.amsl.com> From: Charles Perkins Message-ID: Date: Wed, 18 Aug 2021 13:28:18 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <161904623841.17653.13314629547868546211@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: 35.208.206.246 X-SpamExperts-Domain: giowm1055.siteground.biz X-SpamExperts-Username: 35.208.206.246 Authentication-Results: mailspamprotection.com; auth=pass smtp.auth=35.208.206.246@giowm1055.siteground.biz X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.22) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9MKawy7XFKHdYLzfNa8DroPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5w7eqjV3umHXtZAfna397uT3Y6eSugsHMsWGw2POxshfUXy Uvr/ef/b2Eaz1j+xAOIG18GTzjJsSc7K2nOvm/XIETTZmou68uehA+IInhf6t7vDKRSeOy6sWF/5 dB1Kd4gzKQSavIsH4FUptcg4aK0N2VX+xIg0zhdLWAAqqCgWjaav0zW30NAlS7H9Jl9uSg1Z8Dxg G024zvkvsPJPT+VLMbcL5Znwe7iJe4Fg4yFmCSamJpeyEBQavbztVZ2TQzHmsmTsvjKn5rpVYfvw KPaKBGZ7bWHrTmjPEyoSRPRM5jjau8WIqoQoBbCB+7U9IDjaGQj5hQ0a97qLMrIaOR/IfYYhYqV8 k2MbRzeqSn5PuqgnjnNlBx79SYm9UuqYBXf3RXRzW9BocnzEvP3JtZgPfDEDcaKbczMwEis6t81t LoPAgTtUp75uqlx0KezvZHVJxeokEB3D0cxNTmDQAFR2DU9dLcpnr9FBGrchBzrBPRb2lVZ5tHai 5LkYXOEfjG6jztf7q0tqiKlISwggQuJ/+3ZqVB9RZAbQZJCobpUN//xEyVOZcJoJjrk0zpYb4vJA UEzw3S7Xr+3TrSAj4PCqa/x/wFQ2KDOoL0xbfAntwhWOw68b1vmRQ0fnVdIRRnNQvGCM7BBgrfUw QxCkabjUBDliz59Uzc74wyJaSDaT7OWBOXp8nHKe0R+FkIqN7hmBtbNllNMx9TX2yujvcQPoLv/5 85O+pWpOKIzg2yRxxDohWQvZrl8KYYjZj3Z7dAYvBoCzoxYBqLFgKTOKsyPbicD8e4duLeJKOT0U F79lbBqZR3KVQgqF/fPYYAfEfsjazqTD2gzNWgm7xgc6tVOA0HlkTt2NzkjOo8V++WAc/m6u2VZN vpNC2K41iYX23xZr6uP2UZAoFUB4WERHhxhclvwcpb1cjd9a+x9UVX6tlteOfXW9bOs5Y5oTKauz de1PJQcrCIAhqqJ7s6gdsDKnvKbq2Hnj1jge+cx4Kkll92sBaeNhDNYRTDFz49AJRRp+upmQcGbf VfpgQ0NSnqI4metYYgpdIfmCQr9qpmapsJyTHT/JBHLE0nM++24N+wpXosHFbEXtOMAWDaVXMRJ5 QZgwQAQ9NfskToW8laQ6TRPUaZyO2NbJhrfRU4/YgA3Xc4l5oeyLcwgJaO/AFuv91p5nQnG6A8RK fCGGEuMSqGNMzlbYmI3rrDIXGJnzGtawSQaXsZSfLy09ymyq5ov8FyrtVW4KaRSURqFyxA+5h7jO +dcyLACE2rpRco6OnojGhfFCfN1MNGC8/7MK1SfSUinNsb7GqeqHDjHdOLO0qQ== X-Report-Abuse-To: spam@quarantine1.mailspamprotection.com Archived-At: X-Mailman-Approved-At: Wed, 18 Aug 2021 23:29:07 -0700 Subject: Re: [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 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, 18 Aug 2021 20:28:34 -0000 Hello Roman, Please excuse the unusually long delay it has taken for us to respond to your comments. Regarding the following: >  Roman Danyliw Discuss > Discuss (2021-04-21) > ** 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? We are just referring to normative behavior in a published RFC.  It is not the purpose of AODV-RPL to develop new security mechanisms, and so we rely on existing specification.  The vulnerability is not new or specific to AODV-RPL. > Comment (2021-04-21) > ** I support John’s DISUSS.  My feedback are also around clarifying what > AODV-RPL inherits from RPL. Our response to John addresses this comment. > ** 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. "In general" needs to be deleted.  We will identify which considerations do not apply, if any.  Since the routing is point-to-point instead of only star-shaped, AODV-RPL may have other security threats to be considered in addition to RPL security considerations. > ** 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. Thanks for the text. > ** 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. "Security Configuration" should not have been capitalized. > -- 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)? The security configuration refers to Section 6.1 of RFC6550 entitled "RPL Security Fields" for configuring various security variants.  Other RPL security configurations might not use secure join.  During AODV-RPL route discovey, a router can join a temporary DAG created with any of the security modes of operation per Section 10.1 of RFC6550. In modes other than "unsecured" mode, a router can join only if it can support the security configuration in use, which also specifies the key in use. > ** Section 10.  This section introduces a new acronym "P2P-RPL" not used > in any other part of the document That terminology is not needed at all, and is to be deleted. Regards, Charlie P. On 4/21/2021 4:03 PM, Roman Danyliw via Datatracker wrote: > 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 > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Wed Aug 18 23:29:35 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 2D1E03A1C9D; Wed, 18 Aug 2021 13:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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_H2=-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 (1024-bit key) header.d=lupinlodge.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 0polwxqV4MaP; Wed, 18 Aug 2021 13:33:12 -0700 (PDT) Received: from delivery.mailspamprotection.com (delivery.mailspamprotection.com [146.66.121.163]) (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 C91E83A1C97; Wed, 18 Aug 2021 13:33:11 -0700 (PDT) Received: from 246.206.208.35.bc.googleusercontent.com ([35.208.206.246] helo=giowm1055.siteground.biz) by se19.mailspamprotection.com with esmtps (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1mGSFF-000Gwa-Uj; Wed, 18 Aug 2021 15:33:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lupinlodge.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=rJx2dMa7dMwRQ/vD8LdPOh3qu4i4pzmRKF+/OCgFQPo=; b=mwrjzx2VRBTAKVzdqiYtZxGcWU fJffUszevUOgoqeacuPtpdW9yVSc6cEDdIDyHmsa7q0ZV4GMjBYD49wWLYi6K5QXcDkORfqSBw9cZ 6kBvn39Ejyd3JeVlkvMAYdjAmuq4UNRduU/iyCKePLm9wvplhxIRWcJ2eWZwFa3bcW8w=; Received: from [99.51.72.196] (port=52065 helo=[192.168.1.72]) by giowm1055.siteground.biz with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.90-.1) (envelope-from ) id 1mGSFF-00011V-Ks; Wed, 18 Aug 2021 20:33:05 +0000 To: Warren Kumari , Routing Over Low power and Lossy networks , The IESG Cc: roll-chairs@ietf.org, mariainesrobles@googlemail.com, draft-ietf-roll-aodv-rpl@ietf.org References: <161895622802.25938.15008636103702222386@ietfa.amsl.com> From: Charles Perkins Message-ID: <78241387-f81e-2644-70fd-eb22ddc48c9b@lupinlodge.com> Date: Wed, 18 Aug 2021 13:33:03 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <161895622802.25938.15008636103702222386@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: 35.208.206.246 X-SpamExperts-Domain: giowm1055.siteground.biz X-SpamExperts-Username: 35.208.206.246 Authentication-Results: mailspamprotection.com; auth=pass smtp.auth=35.208.206.246@giowm1055.siteground.biz X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.07) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT/fXuv3DpgGas/91a75kkjNPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5w7eqjV3umHXtZAfna397uT3Y6eSugsHMsWGw2POxshfUXy Uvr/ef/b2Eaz1j+xAOIG18GTzjJsSc7K2nOvm/XIETTZmou68uehA+IInhf6t7vDKRSeOy6sWF/5 dB1Kd4gzKQSavIsH4FUptcg4aK0N2VX+xIg0zhdLWAAqqCgWjbUQ5UGbX7EhUD4zlLo+ZBa+NLhT oFwsjPM8amXGn1h2R1/xP5tIN8qWIfbhVgbSIlprjQPFk8m4tSTfORUp3ymkEyH7KrT9+ZKm5OH0 yXBVil6/Ij8oWqsO8xDLwbu1HPDLN1XsnS+1YMzpRBm8AWmkixVZIdYn+f25tix14zzWE5G9sfe4 YKUv6quXAjEIe90RNjqq0Iv6BpyP6DyQyVFuol5KhYwKJnjjMAcxJlOh+6yEpZgfCgxsseX54YBJ Io8VZybCyOlceSwB/WEnavyGkTPzXcTICHrXDGMtZgQ9nHl2TRtBFGxCwNLr/WIXTkC5wbZk23er WgJIgPCPF8XoItvIXRmrhvX/uuNTMRMmtaSzilttAmrqBaikjd6njlfX1nKyBD7fUtwBfx6gVcCG iF96BcYfYYhVBWCUkVsrIh8YE053aUrqZJ0GW+lryzQzOx8RWvE0es0tAZXhUaURn9LU5DBHGoH7 Akc+ZgPARl0XcdZA0SbI/CndaySyea3CpUXntKYdS6GKHvS9DykW/EbdiRrkDrI263X5YQF3bNNS q7msQerNGiO5li8RanygLzkbLcQOZ8n738F8LZIwmjp2Efnte55ilzMuIlJ6P5dkeOP+2rfQz9a0 PHunWxf2H8+2cFkRaSR0J5lWxiQheGRS3M+CnlZtnT6azyREOs60nBj5upWpNPr0/n7kjoXLoIKJ DWxEMrAP1KHnlp89X8HF2AGrCXi2zSvaspra5PE6/jSyMQ34yDkeWVot7Z3kjaNA/ILVuUL26h54 tiN3qKK/TbznanqntWZtaipXrj2QxbnmZq3/57rcrjCNxETs/G2ITcdLSUllZBXY8ph4ydktQgb2 9ayHqC8LVQt6e3ky7exEwyj/vM3opS1r0/A8oClwMsWhclb9vlmMjMBc9aUV1oY4fX3W5eOCNA39 aqZZAa4knd7p5zYlNJ9v3l9FjCxkDJ58Vt3MdU7BbZNjmMsYNuErQjL3CCcd/ww9I7Nvu7NOcHG3 eceU8QoltQy899mqatXkxJuxSWS2WnjvHgmAbdHs/tKJlNgXHaiCLv/585O+pWpOKIzg2yRxxMFW 3Xzo22NbhUd5SYdSxHn9VhfBlyxdTprb44an5m/o1p5nQnG6A8RKfCGGEuMSqB6sfwpJ7NIIWwjk zubeb7o= X-Report-Abuse-To: spam@quarantine1.mailspamprotection.com Archived-At: X-Mailman-Approved-At: Wed, 18 Aug 2021 23:29:07 -0700 Subject: Re: [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 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, 18 Aug 2021 20:33:17 -0000 Hello Warren, Please excuse the unusually long delay it has taken for us to respond to your comments. Regarding the following: >  Warren Kumari No Objection > Comment (2021-04-20) > 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'? Fixed. > 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... New text:       If the S bit in the received RREQ-DIO is set to 0, the router       MUST determine the neighbor from which it received the RREQ-DIO,       and the cost of traversing the link from that neighbor. > Section 6.3.1: > 'default to 1/4 of the time duration determined by the L bit.' >    - s/L bit/L value'. Fixed. > 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. Unfortunately, "time" is ambiguous, since it can often mean a particular point in time, and not a specified duration of time. The following sentence motivates non-default values:      "A greater value for RREP_WAIT_TIME can allow for discovery of cheaper       reverse routes back to OrigNode, at the cost of longer route discovery       times." > 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.  Fixed.  It is surprising that idnits wouldn't catch this. Regards, Charlie P. On 4/20/2021 3:03 PM, Warren Kumari via Datatracker wrote: > 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. > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Wed Aug 18 23:29:39 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 F1C043A1CD5; Wed, 18 Aug 2021 13:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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_H2=-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 (1024-bit key) header.d=lupinlodge.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 sVP7qQkntkcB; Wed, 18 Aug 2021 13:36:22 -0700 (PDT) Received: from delivery.mailspamprotection.com (delivery.mailspamprotection.com [146.66.121.212]) (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 3645D3A1CE0; Wed, 18 Aug 2021 13:36:22 -0700 (PDT) Received: from 246.206.208.35.bc.googleusercontent.com ([35.208.206.246] helo=giowm1055.siteground.biz) by se20.mailspamprotection.com with esmtps (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1mGSIM-000Fd1-4N; Wed, 18 Aug 2021 15:36:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lupinlodge.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=vFovMqZ8TIhMHUo4L/8/u/dmlIKmyqOxhHKdvWuya+k=; b=XTahW8r3jx+XrHpyrtDS2mqWal d+RwNPej7Kriv1QunFMK9/a8sf3xE3YsXxMMRjOuXT2IrPRDahzunnhl9YfH/tDdGlo4l3PC/oWTz yONTyk6q+7RbUr25Lb4RaOtK5zwd8s8CazQn/XP4XtJtnZpPq7U92hz76zZMZeGglwz8=; Received: from [99.51.72.196] (port=49693 helo=[192.168.1.72]) by giowm1055.siteground.biz with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.90-.1) (envelope-from ) id 1mGSIL-0002ZC-FR; Wed, 18 Aug 2021 20:36:17 +0000 To: Erik Kline , Routing Over Low power and Lossy networks , The IESG Cc: roll-chairs@ietf.org, mariainesrobles@googlemail.com, draft-ietf-roll-aodv-rpl@ietf.org References: <161905962749.10179.18114562350901227233@ietfa.amsl.com> From: Charles Perkins Message-ID: <1cf9f5e7-4e6b-16de-31c1-f99ab43ecf6f@lupinlodge.com> Date: Wed, 18 Aug 2021 13:36:15 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <161905962749.10179.18114562350901227233@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: 35.208.206.246 X-SpamExperts-Domain: giowm1055.siteground.biz X-SpamExperts-Username: 35.208.206.246 Authentication-Results: mailspamprotection.com; auth=pass smtp.auth=35.208.206.246@giowm1055.siteground.biz X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.05) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT/2pKE7g7CQgB+SQKz/iuBdPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5w7eqjV3umHXtZAfna397uT3Y6eSugsHMsWGw2POxshfUXy Uvr/ef/b2Eaz1j+xAOIG18GTzjJsSc7K2nOvm/XIETTZmou68uehA+IInhf6t7vDKRSeOy6sWF/5 dB1Kd4gzKQSavIsH4FUptcg4aK0N2VX+xIg0zhdLWAAqqCgWjeaSmLJjCooKO2oSK3dQLgrSMcuS w/1uStLOgipSjG+7DXGe6avXZL/gNLPBaM/HA1prjQPFk8m4tSTfORUp3ymkEyH7KrT9+ZKm5OH0 yXBVil6/Ij8oWqsO8xDLwbu1HPDLN1XsnS+1YMzpRBm8AWmkixVZIdYn+f25tix14zzWE5G9sfe4 YKUv6quXAjEIe90RNjqq0Iv6BpyP6DyQyVFuol5KhYwKJnjjMAcxJlOh+6yEpZgfCgxsseX54YBJ Io8VZybCyOlceSwB/WEnavwCpvHa2aJpMmjLeBoCuFB8nHl2TRtBFGxCwNLr/WIXTkC5wbZk23er WgJIgPCPF8XoItvIXRmrhvX/uuNTMRMmtaSzilttAmrqBaikjd6njlfX1nKyBD7fUtwBfx6gVcCG iF96BcYfYYhVBWCUkVsrIh8YE053aUrqZJ0GW+lryzQzOx8RWvE0es0tAZXhUaURn9LU5DBHGoH7 Akc+ZgPARl0XcdZA0SbI/CndaySyea3CpUXntKYdS6GKHvS9DykW/EbdiRrkDrI263X5YQF3bNNS q7msQerNGiO5li8RanygLzkbLcQOZ8n738F8LZIwmjp2Efnte55ilzMuIlJ6P5dkeOP+2rfQz9a0 PHunWxf2H8+2cFkRaSR0J5lWxiQheGRS3M+CnlZtnT6azyREBZFkZfYOWbFzB4skLrwTtwKDHZZs DCaM16Kph3J0B+U9X8HF2AGrCXi2zSvaspra5PE6/jSyMQ34yDkeWVot7Z3kjaNA/ILVuUL26h54 tiN3qKK/TbznanqntWZtaipXrj2QxbnmZq3/57rcrjCNxETs/G2ITcdLSUllZBXY8ph4ydktQgb2 9ayHqC8LVQt6e3ky7exEwyj/vM3opS1r07fapS2UqlXDT3DG9b8I9e9c9aUV1oY4fX3W5eOCNA39 aqZZAa4knd7p5zYlNJ9v3l9FjCxkDJ58Vt3MdU7BbZNjmMsYNuErQjL3CCcd/ww9I7Nvu7NOcHG3 eceU8QoltQy899mqatXkxJuxSWS2WnjvHgmAbdHs/tKJlNgXHaiCLv/585O+pWpOKIzg2yRxxMFW 3Xzo22NbhUd5SYdSxHn9VhfBlyxdTprb44an5m/o1p5nQnG6A8RKfCGGEuMSqB6sfwpJ7NIIWwjk zubeb7o= X-Report-Abuse-To: spam@quarantine1.mailspamprotection.com Archived-At: X-Mailman-Approved-At: Wed, 18 Aug 2021 23:29:07 -0700 Subject: Re: [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 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, 18 Aug 2021 20:36:41 -0000 Hello Erik, Please excuse the unusually long delay it has taken for us to respond to your comments. Regarding the following: >  Erik Kline No Objection > Comment (2021-04-21) > [[ nits ]] > [ section 4.1 ] > * "sets its IPv6 address" could perhaps be something like >   "sets a selected IPv6 source address" Fixed. > [ section 4.3 ] > * "r" is not depicted in Figure 3?  Probably "X"?  Or update Figure to >   match the field description. Fixed. Regards, Charlie P. On 4/21/2021 7:47 PM, Erik Kline via Datatracker wrote: > 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. > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Wed Aug 18 23:29:43 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 BEF443A1D2D; Wed, 18 Aug 2021 13:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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_H2=-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 (1024-bit key) header.d=lupinlodge.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 i0t1moRHTMTE; Wed, 18 Aug 2021 13:48:55 -0700 (PDT) Received: from delivery.mailspamprotection.com (delivery.mailspamprotection.com [146.66.121.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 BBBF63A1D29; Wed, 18 Aug 2021 13:48:54 -0700 (PDT) Received: from 246.206.208.35.bc.googleusercontent.com ([35.208.206.246] helo=giowm1055.siteground.biz) by se24.mailspamprotection.com with esmtps (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1mGSUP-000CNA-6x; Wed, 18 Aug 2021 15:48:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lupinlodge.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=o/iEllalrSLfnO3iHzW98XFOQtXoNujHUUvpFM/g9Ec=; b=uNeTOsLKOlrXK0xa3FlxIZHG7G F3gVxrmCemBiwApwB8eOl5ZiJBE0BfmeB7ieVfFOua1VYGyqjv5vsLHb/nw1wTe7o5MqkyyjgSD9K 4XTf/EWAezaDUpvfTfT2FlivXDRk09JGduLp2JUo2vKJF4dgL5zG/l9bkbySjiNVMpAs=; Received: from [99.51.72.196] (port=49751 helo=[192.168.1.72]) by giowm1055.siteground.biz with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.90-.1) (envelope-from ) id 1mGSUO-0007qE-2t; Wed, 18 Aug 2021 20:48:44 +0000 To: Murray Kucherawy , The IESG Cc: draft-ietf-roll-aodv-rpl@ietf.org, roll-chairs@ietf.org, roll@ietf.org, Ines Robles , aretana.ietf@gmail.com References: <161907746666.4867.10229249239001365546@ietfa.amsl.com> From: Charles Perkins Message-ID: Date: Wed, 18 Aug 2021 13:48:42 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <161907746666.4867.10229249239001365546@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: 35.208.206.246 X-SpamExperts-Domain: giowm1055.siteground.biz X-SpamExperts-Username: 35.208.206.246 Authentication-Results: mailspamprotection.com; auth=pass smtp.auth=35.208.206.246@giowm1055.siteground.biz X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.08) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT+v0w8gZxDMhITR9xDvibgIPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5xfhCjHc1rE8j8s8Zbm/wGXznzsYfkdUR16HjGz62pljkko TB1XoRIdpR5ZFOj8MnTOPzAiZwO0erKqGmrB0kNW7yD795EJLHugJKDmd9LZyfBlQ+yfeyWAPtDm XI1PtJNHkh02GMZpkpvzzOke7JxoQPrPgIKCOcN1qssFDA9lsDKCUy+RuevJVoQ1jGOH3u89lTcF 0nAicfQwnBE0p73+gi8CjSEWC7j0q8S0agjsJeqO/uBhcW+rSceRJmf0M28nJJi115yA99rHmPhC gjHZoCCtFYmcCNjTw0IEYuSBISdIc1z987KxjnN2qrUKswhgmjnnY6XN7GZkAc90rB/vT6DFxcIx sfY8ymUCNeJ1PV4GLBqE4vFQbCw4uvHas5X6cdujFziTKhHhtuJji2qTZzIlieWO+yOK/hQOlnb7 /gjSjTQtLKET7a1o26jWEA4pT1oQPsaRmjMQQbG4oCtlqraCXgGgCDOczZcC0s+1rB1w4ezeryh8 miQvz6mokWAXKu1VbgppFJRGoXLED7mHbHZsKnPGAG9EmVl99HfXliJerQ/b2vNFvf9+6MY9I7Rm M83oYG1f2hvsbrozvcruUQGikfn1L9uFSajQqTH5BQJf8mVhU8r5rmMqlFbhWQZFh/T02nV1yf6H ImOjkafEVw9h4qB6AAdqJB1vRIoHvM06XMlzwys1Tht21N2PH6FWQNES0ePkR0h9FZBTWJBw31/E 3ahF5MMcDI7KdpjQKS1ufdwfVck/BrlQBpgZOulli19mW0G91CSooRJqA7sIJjRkswWb241mydgU Xdp1uiDrOjhXmyQVnBqirCXNcY7ek8Zfcsf9wYajt5ucndrY++DuIQUs/5JJj4C/n4CILm2PvW0J BPNlv566oByhiElxesPT8ptdGXrNba/E678EQtiCI+DID2BGlZ0tjUQemvCcuqTfiXRspgDFoNJF g4PUYApavlxVu9Nt2j2RoT3QNW+cVyLKs/RxOX1K4cPDaosEMysPur9wmiDBurOy6iR0CTbPdkJV rvqgqaoaGrJ9JlXoybOvrfLlgErbJFPCXxFQ44ODunxoXZO7OzlEJNbmm9PE4oe3oHezoGaGVr4E YKKwuBUHZEPlafCZ/IU1eSG7X+t1TW39Ja77LGPpOwAwcDPWZdrvHscsfgIt+ZPu37Rtgz0MRUjO UKF7bj4xNDXQeHcLi1GvUhYZ2g6f0dRPmL7EZfbXqNNDE/IOu3/b5JVfry8DT8Vcu9N0XejlDgic jIuYGHzNaGtbvdTLIXJ4DqxxlnCnOQKjhagEKuLSExxov/ex1D5pTgvUGv4wSytbsM3JZLzvt/Ye aVSetlaGpIGxPWaoqL63CHqXkByhMS+4ayUpOtEhdxekWDmK9g== X-Report-Abuse-To: spam@quarantine1.mailspamprotection.com Archived-At: X-Mailman-Approved-At: Wed, 18 Aug 2021 23:29:07 -0700 Subject: Re: [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 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, 18 Aug 2021 20:49:02 -0000 Hello Murray, Please excuse the unusually long delay it has taken for us to respond to your comments. Regarding the following: >  Murray Kucherawy No Objection > Comment (2021-04-22) > No email > send info > 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, > suggest that you provide some guidance around why an implementer might > legitimately decide against doing what the SHOULD says. See also the response to Roman Danyliw.  An implementer might decide to use a proprietary security configuration, and not use the security specification provided by RPL.  Alternatively, certain closed systems will not be vulnerable to insertion of a rogue router, and cost savings or performance improvements might be realized by eliminating unnecessary security operations. > I also support John's DISCUSS. We hope that John's DISCUSS has been resolved. > The document shepherd writeup is more than two years old. This project fell off of my plate due to changes in employment and many urgent distractions.  Please excuse the delay. > 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. Deleting "AODV-RPL Instance" is an improvement.  Thanks for the observation. It is logical to describe the RREQ option before describing how the ART option provides the Targets of the route discovery operation. Alternatively, the options could be presented in alphabetical order, which would put RREP before RREQ, but that also seems counerintuitive. > 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. The text in Section 9 will refer to the "Subregistry" instead of "Registry".  A sentence is to be included in the initial section as follows:     The Subregistries in this section are the named sub-registries of the         "Routing Protocol for Low Power and Lossy Networks (RPL)" registry. Thank you for these useful comments. Regards, Charlie P. On 4/22/2021 12:44 AM, Murray Kucherawy via Datatracker wrote: > 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 Aug 19 01:02: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 55C7E3A0404; Thu, 19 Aug 2021 01:01:47 -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, 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 (1024-bit key) header.d=eggert.org 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 ncWBIP0v-0bm; Thu, 19 Aug 2021 01:01:40 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (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 AFF383A0402; Thu, 19 Aug 2021 01:01:40 -0700 (PDT) Received: from smtpclient.apple (unknown [IPv6:2a00:ac00:4000:400:79f4:9f94:3f3a:6e16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id EB3EA600370; Thu, 19 Aug 2021 11:01:29 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1629360090; bh=eDAjv7ZvQcL5Abv/tMF1iwVsn0ju9yk/wFQV5TE01vI=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=odokVuUsna65y+0At33KCW+YX0iU9UvHHTH+kB1firVZp9rqZkfZjSxsbaO3v2QwK MzVZOfun7iPSsFUvQ+gedozSkfN8AU/YdrPd5qITSjTC9bmbw2JJXvLM/FOD5FJcOO ip0FodLFuvYDNWM4cfPATCwQekCxnPPWfOe2urIw= From: Lars Eggert Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_D6DE696B-6B76-4B5F-938B-38A0BC9CB1DF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Thu, 19 Aug 2021 11:01:28 +0300 In-Reply-To: <24245546-4508-801a-83d0-5a3776288048@lupinlodge.com> Cc: The IESG , draft-ietf-roll-aodv-rpl@ietf.org, roll-chairs@ietf.org, roll@ietf.org, Ines Robles , aretana.ietf@gmail.com To: Charles Perkins References: <161841517905.8620.14903415282133221941@ietfa.amsl.com> <24245546-4508-801a-83d0-5a3776288048@lupinlodge.com> X-MailScanner-ID: EB3EA600370.A4DD2 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [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 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, 19 Aug 2021 08:01:48 -0000 --Apple-Mail=_D6DE696B-6B76-4B5F-938B-38A0BC9CB1DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2021-8-18, at 23:06, Charles Perkins wrote: > Please excuse the unusually long delay it has taken for us to respond = to your comments. no worries. I just came back from vacation myself and would not have = responded earlier anyway. > > Section 2, paragraph 1, comment: > >> 2. Terminology >=20 > > Is there some logic as to which terms are capitalized and which are = not? (Also > > in the text.) >=20 > It is meant to improve the readability by selectively capitalizing = certain > terms what we felt appropriate. This is often very subjective. Do = you have > any suggestions for improvement? I found the capitalization applied inconsistently, and found that = confusing. I'd suggest to either consistently capitalize or - rather - = not to capitalize at all. Thanks, Lars --Apple-Mail=_D6DE696B-6B76-4B5F-938B-38A0BC9CB1DF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmEeD9gACgkQVLXDCb9w wVcNuxAA0oP7GWcgEnQ/XFmE6vaX0Ucp6bqeuVqAzg5qZ0rMqJW9gvMYzeZUD/Yl ONxUSbmXbq/p53bXuNO1OXegcC3Z1X92jaIfQLMRyvAZSL44J1vSq2NJIgVlB0w0 iPd3jpqZsQ8l+X08CeGsXFat9QPuLm/0nNH2k5cDK8X146jAMqzhq0cl5asp0J3B 3+LmWMwC3UoOQpM/VyMsdiKTet9ADsQwqNl0FWC0hNH2TinsIcsR0xJz3R+m78gN 71sao9nSKcvzAq6ndqc+u0JfzP4WkoNIIdffYUxRQClh0onynh2zTFLlgR+pI1P6 k2w7FQruDtgO25lNPKSii3P9V5MSYWmmsuzidMJ6tl63HGvyacBe08vZVPumbesr Qa38udMT4PZn92+tO3rHDW/IHek3T4wLJ5IkS39bNMtpq+/kzbDuuOncCG9hHR7B EXEbNzQXVPcKcfIf3HigUiWM4F0FsUFc9lifgWOE0FxgkXbwFGaIWChsYdjqPlV4 QDLN1fLbH95gdoNbR86G2pIjAGRyE+rhNX7RUDUd5iSkBWOokx0/j0gfm11h9Vgx +44PoA9eaEYS9Ri2xtGfagl5XqxsjaAIifplbvVdvNleVUIxSdDfK7ReAkATjdos TTC/5iDQBfRZ5Vtd7d6zU/+lgzsiX1qEQT4HVunJogYkYOlNe28= =WLN+ -----END PGP SIGNATURE----- --Apple-Mail=_D6DE696B-6B76-4B5F-938B-38A0BC9CB1DF-- From nobody Thu Aug 19 02:48: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 F18563A0958; Thu, 19 Aug 2021 02:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.588 X-Spam-Level: X-Spam-Status: No, score=-9.588 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_NONE=0.001, T_MIME_MALF=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=iqsKILwo; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=OVPAr9n5 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 r2FrqzxE1hYZ; Thu, 19 Aug 2021 02:48:45 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 997133A095D; Thu, 19 Aug 2021 02:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=69413; q=dns/txt; s=iport; t=1629366469; x=1630576069; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ZCU5f9lNHlRKQ3ZtA3xJAPkE/frbsANHIYYsINpwsvU=; b=iqsKILwopkunu7NS55ncnz8wUlTA3OiZw5dAq/uliEj1pJEKeGuKT8f2 igof5nI/zZsK9zl5ACzYdGtkL5R1fsfLJGtd1pn6+oySyI4AjdX+4wtha 4XbNbwBQwlZ/NkoAYMeho7vB5yV7CK/0X/jwjSnhFwXdbHU0pg9uNaQHP Q=; X-IPAS-Result: =?us-ascii?q?A0B/AwDJJx5hl4MNJK1aHgEBCxIMQIJ8MCMGKH5aNzGID?= =?us-ascii?q?wOFOYhqA49zikqBQoERA1QLAQEBDQEBQQQBAYRjAoIuAiU4EwECBAEBAQEDA?= =?us-ascii?q?gMBAQEBBQEBBQEBAQIBBgQUAQEBAQEBAQGBCIVoAQyGQgEBAQECARIIASUBA?= =?us-ascii?q?TcBBAcEAgEZAwEBARYLAQ0yHQgCBA4FCBMHgkoEAQGBflcDDiEBnQ8BgToCi?= =?us-ascii?q?h94gTOBAYIHAQEGBASFLgMVgjQJgTqCfoJyU0iCbIN8JxyBSUSBFUNUgQ2FP?= =?us-ascii?q?A0EGAUbBRkYB4MOgi6EEBEBWgY+HA4NIhQUBQ4LOx4dLRoGAwEaEAwUCgIfC?= =?us-ascii?q?g+ROQSMG59fCoRanT0SpnWFPZBXoBcEBAuEdAIEAgQFAg4BAQaBdyIPHoEuc?= =?us-ascii?q?BWDJFAZD44gGYENAQIFCAeCNYpecwIBNQIGCwEBAwmJI14BAQ?= IronPort-PHdr: A9a23:sCV5QRPOKXa8HrQvalsl6ncfWUAX0o4cdiYU54YpzbVUfffr85fjO RnZ4vNgxB/MUJ7A4v1Jw+zRr+j7WGMG7JrA1RJKcJFFWxIfz8lDmQsmDZ2EBFH1avnwYH9yE MFLTlQw+Xa9PABcE9r/YFuHpHq04HYSFxzzOBAzKP7yH9vZjt+80Ka5/JiACzg= IronPort-HdrOrdr: A9a23:qZGNzqu0/G/tH4dl3aqZWO6X7skC1IMji2hC6mlwRA09TyXGra GTdaUguyMc1gx/ZJh5o6H+BEGBKUmskqKdkrNhQ4tKPTOW+VdASbsD0WKM+UyaJ8STzJ856U 4kSdkDNDSSNyk7sS+Z2njDLz9I+rDum8rE6Za8vhVQpENRGtxdBmxCe2Cm+zhNNXF77O0CZe OhD6R81l6dUEVSSv7+KmgOXuDFqdGOvonhewQ6Cxku7xTLpS+06ZbheiLonSs2Yndq+/MP4G LFmwv26uGIqPeg0CLR0GfV8tB/hMbh8N1eH8aB4/JlaAkEyzzYIbiJaYfy+wzdk9vfrmrCV+ O8+ivICv4Dr085uFvF+ScFlTOQiwrGoEWSuGNwyUGT0fARAghKUfaoQeliA0fkA41KhqAg7E sD5RPri7NHSRzHhyjz/N7OSlVjkVe1u2MrlaoJg2VYSpZ2Us4dkWUzxjIfLH47JlOx1GnnKp gYMOjMoPJNNV+KZXHQuWdihNSqQ3QoBx+DBkwPoNac3TRalG1wixJw/r1Rol4QsJYmD5VU7e XNNapl0LlIU88NdKp4QOMMW9G+BGDBSQ/FdGiSPVPkHqcaPG+lke+63JwloOWxPJAYxpo7n5 rMFFteqG4pYkrrTdaD2ZVamyq9CFlVnQ6dg/22wqIJ9IEUaICbRBFreWpe5fdI+c9vcPEzc8 zDTK5rPw== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.84,334,1620691200"; d="scan'208,217";a="766514194" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Aug 2021 09:47:46 +0000 Received: from mail.cisco.com (xbe-aln-003.cisco.com [173.36.7.18]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 17J9ljBg030907 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Thu, 19 Aug 2021 09:47:46 GMT Received: from xfe-rcd-002.cisco.com (173.37.227.250) by xbe-aln-003.cisco.com (173.36.7.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 19 Aug 2021 04:47:45 -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.15; Thu, 19 Aug 2021 04:47:45 -0500 Received: from NAM12-MW2-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.15 via Frontend Transport; Thu, 19 Aug 2021 04:47:45 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i8Eb4eXiVhEpq5+9twUCa5Q0XdBEl82Hw3zjMrcPLuO1RnwT1IemgZng69yHcxawLnjPTjailPevOc9K3B9JLxi1Z7olzb34fNF6Db1q2Bx6eGwCiuMlz5CkR/V/zS6OP86hxiNLFtOHNFpHqdfI8rJTioi/TW+h2+dyOCJhl//TsCcGKXHOKEkxEU/Z/rX30rD6gZwRcZ/YYHb5j8K8PalIY0af77yj9Oz/x7sI9LmCXezGeWn7iGGeZIBWA10xaWR/j17xOmrjvWV8K2ihN9UTtJBq/tya+DX66Gf0UmZ1E8jlCH6mqP2M4Cj75IbBXso+SPfv6HcSDdxTlatM9w== 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=b6+ORGwqzFZcnJP19Ljbja0K6ZmASTbSSsMeXuzmL4Y=; b=cxVFeiSjL5iEpu3Ui4qXO4gn6wuaTkC5TCFkcB01l/hghJJBzDnQGXplBg7kh/5E/25dhoG/aef4kixwVYq2eOG5367GVpRKcS1UDflxkgWsyjcM5f9zRQQIA29KkyMbPKmC6EWXG0amt+iULylARcpWxY2Jtd/RD7UWA0Rratg0QJy9/MBGR+K92Tku/d1YN1yc7Lylr4YmhdFZ8CgrO+2HbqPA2y0s8KDzInuTCKH09CyPHd/xTLfanCOQuBfW4i0Xj8/wZDsm3O0D9O7Z4KS8iimqbtLtTJTsEkFhUagB1NnoptZPBRy9MprgDpHlBCVLc9PVDHKyUh0IqTv5eg== 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=b6+ORGwqzFZcnJP19Ljbja0K6ZmASTbSSsMeXuzmL4Y=; b=OVPAr9n5OdNHY1NBkBAoeT3FAibQJyIIYrD7MI1c2Mc6p4nvUNAQPrQx9DqKpEGnjuj2clSE+qjSUzDGGCUp+N8SUOqZaWHRBUA9ppGw0/1btuy6QLcTVqXbpdhSQV90B+yh9mN/6h4uhA/SBa8fHDJtm0fGT2KFh+aUepaDJME= Received: from DM6PR11MB3803.namprd11.prod.outlook.com (2603:10b6:5:141::30) by DM6PR11MB4363.namprd11.prod.outlook.com (2603:10b6:5:14f::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4415.19; Thu, 19 Aug 2021 09:47:43 +0000 Received: from DM6PR11MB3803.namprd11.prod.outlook.com ([fe80::68d9:b44b:b6c1:21af]) by DM6PR11MB3803.namprd11.prod.outlook.com ([fe80::68d9:b44b:b6c1:21af%6]) with mapi id 15.20.4415.024; Thu, 19 Aug 2021 09:47:43 +0000 From: "Huimin She (hushe)" To: "roll@ietf.org" CC: "roll-chairs@ietf.org" Thread-Topic: [Roll] Review of draft-ietf-roll-enrollment-priority-05 Thread-Index: AQHXlN9BE7+Pe0GmLEC3OwAqijuyxg== Date: Thu, 19 Aug 2021 09:47:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e37d7720-2b74-42f7-4252-08d962f66472 x-ms-traffictypediagnostic: DM6PR11MB4363: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +btgtkanUuHkqOO0huRz0wqSvGVM+PZOe64iTPb3tsOqymOgsoNtK8d+EsY7SRF6c0FDO3htMuvS1CbfnMBtf49TdjN3LdjS9gjykdMHeay/ynr2awXZNiY2JdTw34mnSQnv8uxhQ/44QCdlE2GdvIr9ADV8lusizT1oUzsV9Ib/ynLLSrxy3BsZZsqpXp3WiWp4hE5Fy5+9TonFX51fYimF3W1dBdA+LBcqHdFXoESDedwKAuk91zB96WQNPnMmaGfz2ejL9D33WTtllDq4xv/jXgr5/VDy7SnkeTEFTGqLFCFMrF4doCH3IFPYgUpjgM8CNTF7dRUldND5XNLVE5HdUL6byHMQZiEuzyDAOWvve0teDXPhDvH/oK3oRvGa5wb/ZJIdSPeeffs+0HPZHIpzZV8RIi1mPzOKOImu5Z97pAbD/uKM4J6xSnWGHwKpmEfr/iJgRD3ncBwboa8eoG38RcPY1TJ3iZf8InaX8ibM7V+qIOJcuYX0Hxv+UZtm79E/Ahi8klV8vr/N/s7YEeRRlekGu0QvklC7Y5uSqWTi+kodT7x7s2R3sX3b20SxjyLLfa177rUsfYMJqbpZARWczcUosAtwr/XcqEovkXVbLd0Ev+9jIagweCyv5Dpl0M8kGETq/TXhOSKzy1RFsyrrW/bn2rzXTG7WlT9aRIBHSzUHcmbA5d/XEVVFLEtolVGDuyAAMOtTOELEsSoEjA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3803.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(396003)(376002)(346002)(366004)(39860400002)(76116006)(450100002)(38100700002)(52536014)(45080400002)(91956017)(55016002)(71200400001)(7696005)(478600001)(53546011)(8676002)(66556008)(66946007)(66476007)(66446008)(64756008)(30864003)(6506007)(9686003)(5660300002)(86362001)(316002)(33656002)(186003)(83380400001)(122000001)(4326008)(6916009)(8936002)(2906002)(38070700005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?2SNsj+gxceEM/dvEirvTwGCawVtwjV+ygZDQ4LlVa46f28y14sfJ+cHh?= =?Windows-1252?Q?tRhW10j2YU/RJW0RqtSC2i1xf93JoPQ9YDLCG7GSjfRwajnYxiTF/+vd?= =?Windows-1252?Q?Gg0l5VRvdbv25RL8dc/W0PjaYD5nVp5qG5cvnrtlXD7UhWvUwfK3GZe1?= =?Windows-1252?Q?umBH9k/xG+Vb4Q3sDD8/W57ecapngZ+YSYmhp30aFoKHnhwXCc4f4PFZ?= =?Windows-1252?Q?wdq75+PJ6CGVceqTLfq+rDngTDe8UgMSmJoe+y1C2YID6R4LwaeE4zlt?= =?Windows-1252?Q?VcHbTHd/koo9qJkFpeDRrtBmj1bxTv80mL0VvZLgyOS3DsCNmqUhV6BL?= =?Windows-1252?Q?Ar8f5k5Sxdg9/2C0Cz9QzSseD85AytS2MyjizgaXehT7T+VFX/is1Uw5?= =?Windows-1252?Q?NdA+osfobL4Z1z1vl/NrNU6LmH1ODk6OFij487Tp/vF/L6GrJGdJRQKQ?= =?Windows-1252?Q?+vu7ZVWX7zIjGCf26tUZZRYMRHp7IOCrJcMsfFerZaByG74gse88cEnb?= =?Windows-1252?Q?ukkDhpE6NWRN3PRozwojWoXuDGYE5MHDgN6FkAg1+5ehBaSgmFliX5Tw?= =?Windows-1252?Q?vNasTNURSS9zxuklFcdSdt8Uub0T9bq/UjZYCZLbCxGRTiB/HeTmaUm8?= =?Windows-1252?Q?iZRifb087WrSRaM0uSe3RNqUSj1JXO4vU5aHgWU4HYj9O2qWK75hx+ng?= =?Windows-1252?Q?J68KBmE2EL33b5QVtL6aMbqeSkC+H2OaT28gRfp11Db5nLzoaLzAu2E4?= =?Windows-1252?Q?JkfP4SS2X44ktFFysr63IHK/GH8aWObczkZO2pdpQ5N+xSquzXwB1AR9?= =?Windows-1252?Q?iahF9UXxaa/OxSJLv7VQLgQA+aVdeZwdAfOo+t8Mfs3X5HCmRLIrFdWh?= =?Windows-1252?Q?mq2H/CeyuOOaWlV8vQVEv0dxeG9qF2w1oD2Yw0wU+1xW1euYyBALaLHO?= =?Windows-1252?Q?KlgEc2H0nDQzGeIl5xnPgU/NwVfEvyRSwyYGK+D+HwlQfg9KjcV5uFWO?= =?Windows-1252?Q?AT5RN2QK/ckyCHUzC08ePLPugKur2lCgy3AWhUJdmGlnAfEG2aeY6vep?= =?Windows-1252?Q?dw37PWq5fhLpjKMruDCZCCeNWqJtIZKvwP9LDgVTfq5aE7z4CIPbB6J0?= =?Windows-1252?Q?Y0doTcUmD1L9Gu+J85mdYOCT5r3qTnO6nago0FFitcTy3ZHmZClSEwTL?= =?Windows-1252?Q?Bm1BkS+HNxR4rWSdpj3F9Rtjn/1P1eWBlM8MPQZi0V8euV+Q2TsRhAPE?= =?Windows-1252?Q?dL+V3ecucl70GJ6kD3lnAXN8ORssVP+zPkLi+urenBJeniiJbeAa8nxe?= =?Windows-1252?Q?ZvEQkt13Xc+MJMWP9Mg6FabRlZB7ahdARiKLyIkoTBsItCXXFAt3QJFi?= =?Windows-1252?Q?/LNZQ6hkrS8GcwZqxIdqZ9bW71XJV40ROm96YDCwSTnwExzoegg7dn3M?= =?Windows-1252?Q?grhLGvWJoc8/vpKuf4Q8Vj6MExyW87zPA3DBvKW6ozGSCgxd2zTfYp6D?= =?Windows-1252?Q?+1F5Vimor/4O2gXBUeYVKyPp6XX9ig=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR11MB3803DC294871CE93A6FCA8F6A3C09DM6PR11MB3803namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3803.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e37d7720-2b74-42f7-4252-08d962f66472 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Aug 2021 09:47:43.4663 (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: KtQYyiphL/mLZPALgbuSX6jAl6aDYVJcy9+tTIaMLIBGdsp1FwkUTFqeS1I5PaKP X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4363 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.18, xbe-aln-003.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: [Roll] Review of draft-ietf-roll-enrollment-priority-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2021 09:48:52 -0000 --_000_DM6PR11MB3803DC294871CE93A6FCA8F6A3C09DM6PR11MB3803namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Thanks to Konrad for very comprehensive comments. I am in favor of the =93IDEA 1 (GLOBAL)=94. There are two reasons: 1. The min enrollment priority provides a criterion for selecting the jo= in proxy not the parent. So it is mainly meaningful for the DODAG root. I d= o not see a use case of local/flexible enrollment priority. 1. As you already discussed on it, if the min enrollment priority is loc= al/Flexible, how should a child react when receiving different values from = different children. Best regards, Huimin ---------------------------------------------------------------------- Message: 1 Date: Wed, 11 Aug 2021 23:24:36 +0200 From: Konrad Iwanicki To: Routing Over Low power and Lossy networks Cc: roll-chairs Subject: [Roll] Review of draft-ietf-roll-enrollment-priority-05 Message-ID: <9b7eabc7-e521-bf82-4087-c65e08fc9fc0@mimuw.edu.pl> Content-Type: text/plain; charset=3Dutf-8; format=3Dflowed Dear Rahul, Pascal, Michael, and all, As promised, I am sending my remarks about the enrollment priority draft, version 05, so as to point out the issues I have with the draft, thereby providing some starting point for discussion at the August interim. Sorry for the text being rather lengthy, but I wanted to highlight all major issues that came to my mind. I am not providing any editorial changes, because those below are more important at this point. PROTOCOL OPERATION WRT. FIELD MIN PRIORITY Based on your comments on my previous review, I gather that there are two different ideas on how the protocol should work, clarifying which was also the reason for the questions I put in my previous review (of the draft version 04). Unless noted otherwise, the text below refers only to the management of field min priority. In other words, let us completely ignore field DODAG_Size for a while. We will return to it later. IDEA 1 (GLOBAL) The first idea on how the min priority field should be managed is supported by Pascal, and I will refer to it as GLOBAL. Essentially, it works as follows: 1. The min priority values are generated solely by the DODAG root node; other nodes are not allowed to change these values. 2. A node extracts the value from a received option, stores it locally, and uses it as a base when computing the proxy priority for EBs, which may also account for the node's local constraints (e.g., load); however, per 1., only the originally received (and stored) value of min priority is used in the options in DIOs sent by the node. 3. An option received from ANY node can be used as the source of the min priority value but the receiving node has to be able to judge whether the received value is fresher than the one it already stores locally. 4. To this end, a lollipop sequence counter that I proposed, let's call it OSN, can be used. I suggested adding it to the option, but others suggested using some existing counters. This is immaterial for now---more on that later; instead, let us just assume that we have OSN mapped to some counter. 5. In any case, the root node bumps its OSN when it produces a new value of min priority. (This condition can also be relaxed but I'd rather not make this text longer. We can discuss this during the interim.) 6. Whenever a node receives an option with a value of OSN that is greater than its own local value of OSN, it adopts the received value of OSN and the received value of min priority as its local ones. Those values will then be sent in the options in DIOs transmitted by the node. This is a really simple and robust solution. Its main advantage is that there are normally many paths that allow a node to learn the value of min priority, which alleviates the problem of nodes that do not support the option or nodes that experience (temporal) down times, overload, and the like. The problem of the different paths being asynchronous, and hence offering different propagation times for the values of min priority, is in turn solved by OSN: the counter unambiguously discriminates between fresher and older values. The effect is that as long as each node has at least one neighbor (not necessarily a parent) that supports the option, the min priory values will be eventually consistent globally. In contrast, the main drawback of this solution is that the value of min priority is global. In particular, it does not take into account any heterogeneity in the load, available resources, etc. in different regions of the DODAG. IDEA 2 (FLEXIBLE) Michael and Rahul thus advocate an alternative idea, let's call it FLEXIBLE. In this approach, it is possible to adjust the value of min priority per node by incrementing the base value the node has originally received. Although the new version (05) of the draft does not describe this in sufficient detail, from Michael's comments I gather that the envisioned solution is something as follows: 1. The root sets a value of min priority in the option in its DIOs. 2. A non-root node obtains the value of its min priority only from an option received from its preferred parent and stores this value locally. It can then only increase the local value, for instance, accounting for its local constraints, before putting it into EBs and the options transmitted in its own DIOs to its children. In other words, the value of min priority can only grow at each hop, reflecting the local constraints of the nodes on the path upward to the root. 3. Since for each node, there is only one source of min priority values (its preferred parent), there are no conflicts. Consequently, in theory, we could omit OSN, as is the case in the current version of the draft. (This approach is wrong, as we will see shortly.) 4. To be compatible with the DIO processing rules in RFC 6550, a node receiving an option with min priority from any neighbor performs the processing according to the following rule (currently missing in the draft): "When processing the option, a node ignores the value of min priority in the option if the option does not come from the node's preferred parent." (This rule is again wrong, as we will see shortly.) 5. If the node's preferred parent does not support the option, the node assumes a default value (0x40) for its local min priority. This value, potentially increased to account for the node's local constraints, is put in the options in the DIOs transmitted by the node to its children. The main advantage of this approach is that the min priority value can be adjusted in a DODAG subtree. The approach thus offers much more flexibility in configuring the values: an entire subtree that is overloaded or experiences other problems can adopt a higher min priority values so as to deflect enrollment traffic to other parts of the DODAG. A disadvantage is in turn that the approach precisely defines the path along which a node has to learn its value. PROBLEMS WITH IDEA 2 (AND A POSSIBLE SOLUTION) However, because of the existence of just a single path for propagating min priority value to each node, FLEXIBLE, as presented hitherto, is wrong. To explain, an important use-case, mentioned also in the present version of that draft, is disabling enrollment in an entire DODAG. This is done by the DODAG root setting its min priority value to 0x7f. Now suppose the DODAG root has done this and that there exists a node, let's call it X, in the DODAG that does not support the option. The children of node X would thus adopt values 0x40+delta (depending on their local constraints) as their min priority values. Since 0x40+delta need not be equal to 0x7f, an entire subtree of node X need not disable enrollment, which is invalid. In general, in FLEXIBLE, nodes that do not support the option are a major problem, as their ancestors disregard any decisions of upstream nodes, including the root. The problem can be solved as follows. - We use multiple paths for propagating min priority information but one of them is preferred by each node (the one through the node's preferred parent). - To ensure consistency, we do employ the aforementioned OSN. Again, for simplicity let's assume that it is incremented whenever the DODAG root produces a new value of min priority but, like in GLOBAL, this condition can be relaxed. - There is no default value (0x40) a node ever adopts for its min priority. (Apart perhaps from the value accompanying the initial OSN value.= ) - Each node locally stores: * the last value of OSN * the accompanying value of min priority * a bit, let's call it PB, indicating whether the above values come from the node's preferred parent (1) or not (0) - In contrast, to the present version of the draft, we maintain the following invariant: "For a given OSN value, the value of min priority at any node is greater than or equal to the value of min priority at the root node." This is to ensure that no node, including the children of a node that does not support the option, is able to override the root's setting of min priority down for a given value of OSN. In particular, the invariant ensures that if the root disables enrollment globally, then so will all nodes (under the same assumptions on connectivity as in GLOBAL). Given these points, the specific rules for processing the option are as follows: 1. If a node receives an option with a greater value of OSN than its local one, then eventually it adopts the received values of OSN and min priority as local ones, and sets PB appropriately (i.e., to 1 if the option is received from its preferred parent or 0 otherwise). It does not have to do this immediately. In particular, it may wait for a while to receive the option with the greater OSN from its preferred parent. Nevertheless, eventually it MUST adopt the greater OSN (and an accompanying min priority). 2. If a node receives an option with the same value of OSN as its local one then: a. if the option is received from its preferred parent, then it adopts the value of min priority from the option and sets PB to 1. b. otherwise, i. if its local PB is 1, then it ignores the received option; ii. if its local PB is 0, then it sets its local min priority to the minimum of its local min priority and the value of min priority from the option 3. If a node receives an option with a smaller value of OSN than its local one, then it ignores the received option. 4. If a node changes its preferred parent, then it sets its PB to 0. 5. If a node sends the option in its own DIO, then it puts in the option its local value of min priority or a greater value (e.g., taking into account the node's local constraints). It can never sent the option with a lower value of min priority than its local one. This should do what I would expect from FLEXIBLE. However, I wrote this up in a haste, so it would be great if somebody verified the above algorithm. As a side note, the algorithm suggests that FLEXIBLE is indeed a bit more involved than GLOBAL, so a decision should be made, which of them to put in the draft. FURTHER ISSUES UNCOVERED IN THE DRAFT OR TO BE DISCUSSED AT THE INTERIM Irrespective of the decision whether to settle down on GLOBAL or FLEXIBLE, I believe that the following issues also have to be covered in the draft (and discussed during the interim). 1. Should DODAG_Size be part of the option? I mentioned this in my previous review and there has been some discussion already. I would just like to add one observation to that discussion: whereas min priority can follow either GLOBAL or FLEXIBLE, I believe there is an agreement that DODAG_Size should follow GLOBAL when it comes to propagating its value in the network. This information may influence our decision on which of the approaches to adopt for min priority and whether to put DODAG_Size in the option at all or move it to another one. 2. Which counter to use as OSN? I proposed a dedicated counter, which I believe is a clean solution. However, there are other possibilities. I also believe that we agreed that DTSN from DIO base is not the best choice. In my view, nor is DODAGVersion but we can discuss this. 3. How do changes to min priority (and OSN) affect DIO Trickle timers? This is currently not covered in the draft. However, I would imagine that some decisions regarding min priority should be propagated fast in a DODAG, and hence require Trickle timer resets. In particular, I would expect that disabling enrollment globally should be disseminated as soon as possible. Therefore, if I were to suggest anything, I would say that a change by a node of min priority to the maximal value (0x7f) from a lower one MUST entail a Trickle timer reset. In turn, a change from the maximal value to a smaller one MAY/SHOULD entail a Trickle timer reset. Other changes are, at least in my view, not that important, but this can and should be discussed. 4. How does a (temporal) lack of a preferred parent affect the proxy priority of the node in EBs (and in general, the node's behavior)? This is also ignored in the draft but it may happen that a node does not have any preferred parent for a while. In this case, it is unable to handle any enrollments. What should it do? I would expect that it would advertise the maximal proxy priority in EBs. However, should it also modify its local min priority? I would probably be against. Plus there are smaller issues I mentioned earlier, and I probably forgot something. In any case, sorry again for such long a text but I hope it may help during the interim. Best, -- - Konrad Iwanicki. ------------------------------ Message: 2 Date: Thu, 12 Aug 2021 09:47:16 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Cc: roll-chairs Subject: Re: [Roll] Review of draft-ietf-roll-enrollment-priority-05 Message-ID: Content-Type: text/plain; charset=3D"iso-8859-1" Hello Konrad, This is great explanations of both options and how they could be made to wo= rk. What we need to add is, what do we want them for, which use case are we se= rving? GLOBAL serves the need for a node to compare the load of the current DODAG = with that of other DODAGs it could jump to. The use case is balancing DODAG= s. FLEXIBLE gives an indication of load of a preferred path. What would be the= use of that? - in storing mode it could indicate the capability of creating DAO state. B= ut you'll find looking at it that you'd need a lot more than good or bad. I= f a node moves to another parent and has 100 children it needs to know that= the new parent and its path up to the root have 100 rooms left. OK, it wou= ld split the DAOs between 2 parents, but if the bottleneck is up there wher= e the paths from the parents cross, it fails. Bottom line, hard problem tha= t we avoided so far. - in any mode, it could indicate the throughput load. But then: * usually (P2MP or MP2P with homogeneous radios) that overload affects pr= imarily the root's radio space, so there is no benefit in increasing the mi= nimum, the root's one is the worst already. * there's the need to normalize the increment, IOW to explain by what the= min value should be increased by the 6LRs and when so the result down ther= e is comparable between preferred parent chains. Like the Rank computation = which imposes a single OF, you need to impose a single operation throughout= . From there, all the problems of updating OFs, using multiple OFs, etc... * the real need would be to rebalance the tree, but rebalancing a tree in= a distributed protocol is another hard problem, subject to loops So what is FLEXIBLE for? Convince me we need it and I'll support doing both= . On the side, I completely agree with you sequence counter in any case. The = counter should follow section 7 of RFC 6550, including freshness assertion,= etc... in which case there's little additional to describe. Keep safe, Pascal > -----Original Message----- > From: Roll On Behalf Of Konrad Iwanicki > Sent: mercredi 11 ao?t 2021 23:25 > To: Routing Over Low power and Lossy networks > Cc: roll-chairs > Subject: [Roll] Review of draft-ietf-roll-enrollment-priority-05 > > Dear Rahul, Pascal, Michael, and all, > > As promised, I am sending my remarks about the enrollment priority draft, > version 05, so as to point out the issues I have with the draft, thereby > providing some starting point for discussion at the August interim. Sorry > for the text being rather lengthy, but I wanted to highlight all major > issues that came to my mind. I am not providing any editorial changes, > because those below are more important at this point. > > > PROTOCOL OPERATION WRT. FIELD MIN PRIORITY > > Based on your comments on my previous review, I gather that there are two > different ideas on how the protocol should work, clarifying which was als= o > the reason for the questions I put in my previous review (of the draft > version 04). > > Unless noted otherwise, the text below refers only to the management of > field min priority. In other words, let us completely ignore field > DODAG_Size for a while. We will return to it later. > > > IDEA 1 (GLOBAL) > > The first idea on how the min priority field should be managed is > supported by Pascal, and I will refer to it as GLOBAL. Essentially, it > works as follows: > > 1. The min priority values are generated solely by the DODAG root node; > other nodes are not allowed to change these values. > > 2. A node extracts the value from a received option, stores it locally, > and uses it as a base when computing the proxy priority for EBs, which ma= y > also account for the node's local constraints (e.g., load); however, per > 1., only the originally received (and stored) value of min priority is > used in the options in DIOs sent by the node. > > 3. An option received from ANY node can be used as the source of the min > priority value but the receiving node has to be able to judge whether the > received value is fresher than the one it already stores locally. > > 4. To this end, a lollipop sequence counter that I proposed, let's call i= t > OSN, can be used. I suggested adding it to the option, but others > suggested using some existing counters. This is immaterial for now---more > on that later; instead, let us just assume that we have OSN mapped to som= e > counter. > > 5. In any case, the root node bumps its OSN when it produces a new value > of min priority. (This condition can also be relaxed but I'd rather not > make this text longer. We can discuss this during the interim.) > > 6. Whenever a node receives an option with a value of OSN that is greater > than its own local value of OSN, it adopts the received value of OSN and > the received value of min priority as its local ones. Those values will > then be sent in the options in DIOs transmitted by the node. > > This is a really simple and robust solution. Its main advantage is that > there are normally many paths that allow a node to learn the value of min > priority, which alleviates the problem of nodes that do not support the > option or nodes that experience (temporal) down times, overload, and the > like. The problem of the different paths being asynchronous, and hence > offering different propagation times for the values of min priority, is i= n > turn solved by OSN: the counter unambiguously discriminates between > fresher and older values. The effect is that as long as each node has at > least one neighbor (not necessarily a parent) that supports the option, > the min priory values will be eventually consistent globally. > > In contrast, the main drawback of this solution is that the value of min > priority is global. In particular, it does not take into account any > heterogeneity in the load, available resources, etc. in different regions > of the DODAG. > > > IDEA 2 (FLEXIBLE) > > Michael and Rahul thus advocate an alternative idea, let's call it > FLEXIBLE. In this approach, it is possible to adjust the value of min > priority per node by incrementing the base value the node has originally > received. Although the new version (05) of the draft does not describe > this in sufficient detail, from Michael's comments I gather that the > envisioned solution is something as follows: > > 1. The root sets a value of min priority in the option in its DIOs. > > 2. A non-root node obtains the value of its min priority only from an > option received from its preferred parent and stores this value locally. > It can then only increase the local value, for instance, accounting for > its local constraints, before putting it into EBs and the options > transmitted in its own DIOs to its children. In other words, the value of > min priority can only grow at each hop, reflecting the local constraints > of the nodes on the path upward to the root. > > 3. Since for each node, there is only one source of min priority values > (its preferred parent), there are no conflicts. Consequently, in theory, > we could omit OSN, as is the case in the current version of the draft. > (This approach is wrong, as we will see shortly.) > > 4. To be compatible with the DIO processing rules in RFC 6550, a node > receiving an option with min priority from any neighbor performs the > processing according to the following rule (currently missing in the > draft): "When processing the option, a node ignores the value of min > priority in the option if the option does not come from the node's > preferred parent." (This rule is again wrong, as we will see shortly.) > > 5. If the node's preferred parent does not support the option, the node > assumes a default value (0x40) for its local min priority. This value, > potentially increased to account for the node's local constraints, is put > in the options in the DIOs transmitted by the node to its children. > > The main advantage of this approach is that the min priority value can be > adjusted in a DODAG subtree. The approach thus offers much more > flexibility in configuring the values: an entire subtree that is > overloaded or experiences other problems can adopt a higher min priority > values so as to deflect enrollment traffic to other parts of the DODAG. > A disadvantage is in turn that the approach precisely defines the path > along which a node has to learn its value. > > > PROBLEMS WITH IDEA 2 (AND A POSSIBLE SOLUTION) > > However, because of the existence of just a single path for propagating > min priority value to each node, FLEXIBLE, as presented hitherto, is > wrong. > > To explain, an important use-case, mentioned also in the present version > of that draft, is disabling enrollment in an entire DODAG. This is done b= y > the DODAG root setting its min priority value to 0x7f. Now suppose the > DODAG root has done this and that there exists a node, let's call it X, i= n > the DODAG that does not support the option. The children of node X would > thus adopt values 0x40+delta (depending on their local > constraints) as their min priority values. Since 0x40+delta need not be > equal to 0x7f, an entire subtree of node X need not disable enrollment, > which is invalid. > > In general, in FLEXIBLE, nodes that do not support the option are a major > problem, as their ancestors disregard any decisions of upstream nodes, > including the root. The problem can be solved as follows. > > - We use multiple paths for propagating min priority information but one > of them is preferred by each node (the one through the node's preferred > parent). > > - To ensure consistency, we do employ the aforementioned OSN. Again, for > simplicity let's assume that it is incremented whenever the DODAG root > produces a new value of min priority but, like in GLOBAL, this condition > can be relaxed. > > - There is no default value (0x40) a node ever adopts for its min > priority. (Apart perhaps from the value accompanying the initial OSN > value.) > > - Each node locally stores: > * the last value of OSN > * the accompanying value of min priority > * a bit, let's call it PB, indicating whether the above values come > from the node's preferred parent (1) or not (0) > > - In contrast, to the present version of the draft, we maintain the > following invariant: > "For a given OSN value, the value of min priority at any node is > greater than or equal to the value of min priority at the root node." > This is to ensure that no node, including the children of a node that > does not support the option, is able to override the root's setting of mi= n > priority down for a given value of OSN. In particular, the invariant > ensures that if the root disables enrollment globally, then so will all > nodes (under the same assumptions on connectivity as in GLOBAL). > > Given these points, the specific rules for processing the option are as > follows: > > 1. If a node receives an option with a greater value of OSN than its loca= l > one, then eventually it adopts the received values of OSN and min priorit= y > as local ones, and sets PB appropriately (i.e., to 1 if the option is > received from its preferred parent or 0 otherwise). It does not have to d= o > this immediately. In particular, it may wait for a while to receive the > option with the greater OSN from its preferred parent. > Nevertheless, eventually it MUST adopt the greater OSN (and an > accompanying min priority). > > 2. If a node receives an option with the same value of OSN as its local > one then: > a. if the option is received from its preferred parent, then it adopts > the value of min priority from the option and sets PB to 1. > b. otherwise, > i. if its local PB is 1, then it ignores the received option; > ii. if its local PB is 0, then it sets its local min priority to the > minimum of its local min priority and the value of min priority from the > option > > 3. If a node receives an option with a smaller value of OSN than its loca= l > one, then it ignores the received option. > > 4. If a node changes its preferred parent, then it sets its PB to 0. > > 5. If a node sends the option in its own DIO, then it puts in the option > its local value of min priority or a greater value (e.g., taking into > account the node's local constraints). It can never sent the option with = a > lower value of min priority than its local one. > > This should do what I would expect from FLEXIBLE. However, I wrote this u= p > in a haste, so it would be great if somebody verified the above algorithm= . > > As a side note, the algorithm suggests that FLEXIBLE is indeed a bit more > involved than GLOBAL, so a decision should be made, which of them to put > in the draft. > > > FURTHER ISSUES UNCOVERED IN THE DRAFT OR TO BE DISCUSSED AT THE INTERIM > > Irrespective of the decision whether to settle down on GLOBAL or FLEXIBLE= , > I believe that the following issues also have to be covered in the draft > (and discussed during the interim). > > 1. Should DODAG_Size be part of the option? > > I mentioned this in my previous review and there has been some discussion > already. I would just like to add one observation to that > discussion: whereas min priority can follow either GLOBAL or FLEXIBLE, I > believe there is an agreement that DODAG_Size should follow GLOBAL when i= t > comes to propagating its value in the network. This information may > influence our decision on which of the approaches to adopt for min > priority and whether to put DODAG_Size in the option at all or move it to > another one. > > 2. Which counter to use as OSN? > > I proposed a dedicated counter, which I believe is a clean solution. > However, there are other possibilities. I also believe that we agreed tha= t > DTSN from DIO base is not the best choice. In my view, nor is DODAGVersio= n > but we can discuss this. > > 3. How do changes to min priority (and OSN) affect DIO Trickle timers? > > This is currently not covered in the draft. However, I would imagine that > some decisions regarding min priority should be propagated fast in a > DODAG, and hence require Trickle timer resets. In particular, I would > expect that disabling enrollment globally should be disseminated as soon > as possible. Therefore, if I were to suggest anything, I would say that a > change by a node of min priority to the maximal value (0x7f) from a lower > one MUST entail a Trickle timer reset. In turn, a change from the maximal > value to a smaller one MAY/SHOULD entail a Trickle timer reset. > Other changes are, at least in my view, not that important, but this can > and should be discussed. > > 4. How does a (temporal) lack of a preferred parent affect the proxy > priority of the node in EBs (and in general, the node's behavior)? > > This is also ignored in the draft but it may happen that a node does not > have any preferred parent for a while. In this case, it is unable to > handle any enrollments. What should it do? I would expect that it would > advertise the maximal proxy priority in EBs. However, should it also > modify its local min priority? I would probably be against. > > Plus there are smaller issues I mentioned earlier, and I probably forgot > something. In any case, sorry again for such long a text but I hope it ma= y > help during the interim. > > Best, > -- > - Konrad Iwanicki. > --_000_DM6PR11MB3803DC294871CE93A6FCA8F6A3C09DM6PR11MB3803namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi,

 

Thanks to Konrad for very compr= ehensive comments.

 

I am in favor of the =93= IDEA 1 (GLOBAL)=94. There are two reasons:<= /span>

  1. The min enrollment priority provides a criterion for s= electing the join proxy not the parent. So it is mainly meaningful for the = DODAG root. I do not see a use case of local/flexible enrollment priority.<= /span>

 

  1. As you already discussed on it, if the min enrollment = priority is local/Flexible, how should a child react when receiving differe= nt values from different children.

 

Best regards,=

Huimin

 

----------------------------------------------------= ------------------

Message: 1
Date: Wed, 11 Aug 2021 23:24:36 +0200
From: Konrad Iwanicki <iwanicki@mimuw.edu.pl>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Cc: roll-chairs <roll-chairs@ietf.org>
Subject: [Roll] Review of draft-ietf-roll-enrollment-priority-05
Message-ID: <9b7eabc7-e521-bf82-4087-c65e08fc9fc0@mimuw.edu.pl>
Content-Type: text/plain; charset=3Dutf-8; format=3Dflowed

Dear Rahul, Pascal, Michael, and all,

As promised, I am sending my remarks about the enrollment priority
draft, version 05, so as to point out the issues I have with the draft, thereby providing some starting point for discussion at the August
interim. Sorry for the text being rather lengthy, but I wanted to
highlight all major issues that came to my mind. I am not providing any editorial changes, because those below are more important at this point.

PROTOCOL OPERATION WRT. FIELD MIN PRIORITY

Based on your comments on my previous review, I gather that there are
two different ideas on how the protocol should work, clarifying which
was also the reason for the questions I put in my previous review (of
the draft version 04).

Unless noted otherwise, the text below refers only to the management of field min priority. In other words, let us completely ignore field
DODAG_Size for a while. We will return to it later.


IDEA 1 (GLOBAL)

The first idea on how the min priority field should be managed is
supported by Pascal, and I will refer to it as GLOBAL. Essentially, it
works as follows:

1. The min priority values are generated solely by the DODAG root node; other nodes are not allowed to change these values.

2. A node extracts the value from a received option, stores it locally, and uses it as a base when computing the proxy priority for EBs, which
may also account for the node's local constraints (e.g., load); however, per 1., only the originally received (and stored) value of min priority is used in the options in DIOs sent by the node.

3. An option received from ANY node can be used as the source of the min priority value but the receiving node has to be able to judge whether
the received value is fresher than the one it already stores locally.

4. To this end, a lollipop sequence counter that I proposed, let's call it OSN, can be used. I suggested adding it to the option, but others
suggested using some existing counters. This is immaterial for
now---more on that later; instead, let us just assume that we have OSN
mapped to some counter.

5. In any case, the root node bumps its OSN when it produces a new value of min priority. (This condition can also be relaxed but I'd rather not make this text longer. We can discuss this during the interim.)

6. Whenever a node receives an option with a value of OSN that is
greater than its own local value of OSN, it adopts the received value of OSN and the received value of min priority as its local ones. Those
values will then be sent in the options in DIOs transmitted by the node.
This is a really simple and robust solution. Its main advantage is that there are normally many paths that allow a node to learn the value of
min priority, which alleviates the problem of nodes that do not support the option or nodes that experience (temporal) down times, overload, and the like. The problem of the different paths being asynchronous, and
hence offering different propagation times for the values of min
priority, is in turn solved by OSN: the counter unambiguously
discriminates between fresher and older values. The effect is that as
long as each node has at least one neighbor (not necessarily a parent)
that supports the option, the min priory values will be eventually
consistent globally.

In contrast, the main drawback of this solution is that the value of min priority is global. In particular, it does not take into account any
heterogeneity in the load, available resources, etc. in different
regions of the DODAG.


IDEA 2 (FLEXIBLE)

Michael and Rahul thus advocate an alternative idea, let's call it
FLEXIBLE. In this approach, it is possible to adjust the value of min
priority per node by incrementing the base value the node has originally received. Although the new version (05) of the draft does not describe
this in sufficient detail, from Michael's comments I gather that the
envisioned solution is something as follows:

1. The root sets a value of min priority in the option in its DIOs.

2. A non-root node obtains the value of its min priority only from an
option received from its preferred parent and stores this value locally. It can then only increase the local value, for instance, accounting for its local constraints, before putting it into EBs and the options
transmitted in its own DIOs to its children. In other words, the value
of min priority can only grow at each hop, reflecting the local
constraints of the nodes on the path upward to the root.

3. Since for each node, there is only one source of min priority values (its preferred parent), there are no conflicts. Consequently, in theory, we could omit OSN, as is the case in the current version of the draft.
(This approach is wrong, as we will see shortly.)

4. To be compatible with the DIO processing rules in RFC 6550, a node
receiving an option with min priority from any neighbor performs the
processing according to the following rule (currently missing in the
draft): "When processing the option, a node ignores the value of min <= br> priority in the option if the option does not come from the node's
preferred parent." (This rule is again wrong, as we will see shortly.)=

5. If the node's preferred parent does not support the option, the node assumes a default value (0x40) for its local min priority. This value,
potentially increased to account for the node's local constraints, is
put in the options in the DIOs transmitted by the node to its children.

The main advantage of this approach is that the min priority value can
be adjusted in a DODAG subtree. The approach thus offers much more
flexibility in configuring the values: an entire subtree that is
overloaded or experiences other problems can adopt a higher min priority values so as to deflect enrollment traffic to other parts of the DODAG. A disadvantage is in turn that the approach precisely defines the path
along which a node has to learn its value.


PROBLEMS WITH IDEA 2 (AND A POSSIBLE SOLUTION)

However, because of the existence of just a single path for propagating min priority value to each node, FLEXIBLE, as presented hitherto, is wrong.=

To explain, an important use-case, mentioned also in the present version of that draft, is disabling enrollment in an entire DODAG. This is done by the DODAG root setting its min priority value to 0x7f. Now suppose
the DODAG root has done this and that there exists a node, let's call it X, in the DODAG that does not support the option. The children of node X would thus adopt values 0x40+delta (depending on their local
constraints) as their min priority values. Since 0x40+delta need not be equal to 0x7f, an entire subtree of node X need not disable enrollment, which is invalid.

In general, in FLEXIBLE, nodes that do not support the option are a
major problem, as their ancestors disregard any decisions of upstream
nodes, including the root. The problem can be solved as follows.

- We use multiple paths for propagating min priority information but one of them is preferred by each node (the one through the node's preferred parent).

- To ensure consistency, we do employ the aforementioned OSN. Again, for simplicity let's assume that it is incremented whenever the DODAG root
produces a new value of min priority but, like in GLOBAL, this condition can be relaxed.

- There is no default value (0x40) a node ever adopts for its min
priority. (Apart perhaps from the value accompanying the initial OSN value.= )

- Each node locally stores:
   * the last value of OSN
   * the accompanying value of min priority
   * a bit, let's call it PB, indicating whether the above values= come
from the node's preferred parent (1) or not (0)

- In contrast, to the present version of the draft, we maintain the
following invariant:
     "For a given OSN value, the value of min prio= rity at any node is
greater than or equal to the value of min priority at the root node."<= br>    This is to ensure that no node, including the children of a no= de that
does not support the option, is able to override the root's setting of
min priority down for a given value of OSN. In particular, the invariant ensures that if the root disables enrollment globally, then so will all nodes (under the same assumptions on connectivity as in GLOBAL).

Given these points, the specific rules for processing the option are as follows:

1. If a node receives an option with a greater value of OSN than its
local one, then eventually it adopts the received values of OSN and min priority as local ones, and sets PB appropriately (i.e., to 1 if the
option is received from its preferred parent or 0 otherwise). It does
not have to do this immediately. In particular, it may wait for a while to receive the option with the greater OSN from its preferred parent.
Nevertheless, eventually it MUST adopt the greater OSN (and an
accompanying min priority).

2. If a node receives an option with the same value of OSN as its local one then:
   a. if the option is received from its preferred parent, then i= t
adopts the value of min priority from the option and sets PB to 1.
   b. otherwise,
     i. if its local PB is 1, then it ignores the recei= ved option;
     ii. if its local PB is 0, then it sets its local m= in priority to
the minimum of its local min priority and the value of min priority from the option

3. If a node receives an option with a smaller value of OSN than its
local one, then it ignores the received option.

4. If a node changes its preferred parent, then it sets its PB to 0.

5. If a node sends the option in its own DIO, then it puts in the option its local value of min priority or a greater value (e.g., taking into
account the node's local constraints). It can never sent the option with a lower value of min priority than its local one.

This should do what I would expect from FLEXIBLE. However, I wrote this up in a haste, so it would be great if somebody verified the above
algorithm.

As a side note, the algorithm suggests that FLEXIBLE is indeed a bit
more involved than GLOBAL, so a decision should be made, which of them
to put in the draft.


FURTHER ISSUES UNCOVERED IN THE DRAFT OR TO BE DISCUSSED AT THE INTERIM

Irrespective of the decision whether to settle down on GLOBAL or
FLEXIBLE, I believe that the following issues also have to be covered in the draft (and discussed during the interim).

1. Should DODAG_Size be part of the option?

I mentioned this in my previous review and there has been some
discussion already. I would just like to add one observation to that
discussion: whereas min priority can follow either GLOBAL or FLEXIBLE, I believe there is an agreement that DODAG_Size should follow GLOBAL when it comes to propagating its value in the network. This information may
influence our decision on which of the approaches to adopt for min
priority and whether to put DODAG_Size in the option at all or move it
to another one.

2. Which counter to use as OSN?

I proposed a dedicated counter, which I believe is a clean solution.
However, there are other possibilities. I also believe that we agreed
that DTSN from DIO base is not the best choice. In my view, nor is
DODAGVersion but we can discuss this.

3. How do changes to min priority (and OSN) affect DIO Trickle timers?

This is currently not covered in the draft. However, I would imagine
that some decisions regarding min priority should be propagated fast in a DODAG, and hence require Trickle timer resets. In particular, I would expect that disabling enrollment globally should be disseminated as soon as possible. Therefore, if I were to suggest anything, I would say that a change by a node of min priority to the maximal value (0x7f) from a
lower one MUST entail a Trickle timer reset. In turn, a change from the maximal value to a smaller one MAY/SHOULD entail a Trickle timer reset. Other changes are, at least in my view, not that important, but this can and should be discussed.

4. How does a (temporal) lack of a preferred parent affect the proxy
priority of the node in EBs (and in general, the node's behavior)?

This is also ignored in the draft but it may happen that a node does not have any preferred parent for a while. In this case, it is unable to
handle any enrollments. What should it do? I would expect that it would advertise the maximal proxy priority in EBs. However, should it also
modify its local min priority? I would probably be against.

Plus there are smaller issues I mentioned earlier, and I probably forgot something. In any case, sorry again for such long a text but I hope it
may help during the interim.

Best,
--
- Konrad Iwanicki.



------------------------------

Message: 2
Date: Thu, 12 Aug 2021 09:47:16 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Cc: roll-chairs <roll-chairs@ietf.org>
Subject: Re: [Roll] Review of draft-ietf-roll-enrollment-priority-05
Message-ID:
        <CO1PR11MB488177A3BBB15404F81= 2521FD8F99@CO1PR11MB4881.namprd11.prod.outlook.com>
       
Content-Type: text/plain; charset=3D"iso-8859-1"

Hello Konrad,

This is great explanations of both options and how they could be made to wo= rk.

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

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

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

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

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

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

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

Keep safe,

Pascal



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

--_000_DM6PR11MB3803DC294871CE93A6FCA8F6A3C09DM6PR11MB3803namp_-- From nobody Thu Aug 19 11:31:52 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 2D87B3A149D; Thu, 19 Aug 2021 11:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi 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 ldf-ZAOvqgiU; Thu, 19 Aug 2021 11:31:37 -0700 (PDT) Received: from meesny.iki.fi (meesny.iki.fi [IPv6:2001:67c:2b0:1c1::201]) (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 AE18A3A149C; Thu, 19 Aug 2021 11:31:36 -0700 (PDT) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen@iki.fi) by meesny.iki.fi (Postfix) with ESMTPSA id 9A4A520106; Thu, 19 Aug 2021 21:31:28 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1629397888; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GPznc+uQoXTkGsbikoZwzPlsEO+blbxlJ7irBPHpwog=; b=a0LzN0vg1/d7TcprRbvKF2tzCdcu8fmqlYSGUBiaieCbUWK5EaRIVF6c69IIzMtc3t50yl xxZI24v15V4VhFz7pCWJMz9cp8T8+N6cVveu8ESKMdmvJXqravvBwovixudxT44Yjq3b8H C7KcyfFQq2jFUgsQ0ElFQZgABPmFb04= Received: by fireball.acr.fi (Postfix, from userid 15204) id 5E7AF25C12D8; Thu, 19 Aug 2021 21:31:28 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <24862.41856.351274.966681@fireball.acr.fi> Date: Thu, 19 Aug 2021 21:31:28 +0300 From: Tero Kivinen To: Charlie Perkins Cc: secdir@ietf.org, draft-ietf-roll-aodv-rpl.all@ietf.org, last-call@ietf.org, roll@ietf.org In-Reply-To: <8b572d7a-fd1a-9055-7052-057bb56ce720@earthlink.net> References: <161643127376.6337.10029863442550466574@ietfa.amsl.com> <8b572d7a-fd1a-9055-7052-057bb56ce720@earthlink.net> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 1 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1629397888; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GPznc+uQoXTkGsbikoZwzPlsEO+blbxlJ7irBPHpwog=; b=HrYjGaVS8bE4iIZ96Tqg0seca0AQihUiwSp4w/CHkWRAuciQVr5V1zFUFi9jSaFfoorSVX Vhq3GwtpWz7BitOJoJyiHZ+AG/CG1mhKA6DrJvt3xIYUpFu2Nja7FWPL8cRTtY3iWZmOQ8 UzmUpgbzXqXf9KXzGdFMe1ks6vh8qvg= ARC-Seal: i=1; s=meesny; d=iki.fi; t=1629397888; a=rsa-sha256; cv=none; b=a/7JkK7SJ3jaCuIdCQ1xYGEfWOGI6c0jWWkG/P6xchLSsMLuwvJ3LHKzvHIC8YBFZQeLUP UsMyJy1wt5ZBt7b1ietREgsT2mD+kDzf1TssgeXL1rWF88HJQNxD9Mx+GO1JTg3C3XzfmA +HGgJOQR4F4GVmcWaXD770U9KgUgMxM= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen@iki.fi smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: Re: [Roll] Secdir last call review of draft-ietf-roll-aodv-rpl-09 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, 19 Aug 2021 18:31:42 -0000 Charlie Perkins writes: > Hello Tero, >=20 > Thanks for your comments, useful as always.=A0 Please excuse the unus= ually=20 > long > delay it has taken for us to respond to your comments.=A0 Please see = a bit of > follow-up below. Changes look good.=20 > On 3/22/2021 9:41 AM, Tero Kivinen via Datatracker wrote: > > The title of the draft has some acronyms which are not expanded=20= > (AODV, P2P) > > and if you expand them the title comes way too long. I would propo= se=20 > a usable > > title, which might not need to use all possible acronyms, but woul= d=20 > better > > explain what this document is trying to do. >=20 > How about "Supporting Asymmetric Links in Low Power Networks"=3F Repl= acing=20 > "LLNs" by "Low Power Networks" is probably O.K. because lossy is almo= st=20 > implicit given low power (or, often, reality). I think that title is good.=20 --=20 kivinen@iki.fi From nobody Fri Aug 20 08:52: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 1A0543A125D for ; Fri, 20 Aug 2021 08:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.697 X-Spam-Level: X-Spam-Status: No, score=-0.697 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 9rJceerq8mJl for ; Fri, 20 Aug 2021 08:51:53 -0700 (PDT) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (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 3EA633A125C for ; Fri, 20 Aug 2021 08:51:53 -0700 (PDT) Received: by mail-ua1-x92e.google.com with SMTP id m39so4292293uad.9 for ; Fri, 20 Aug 2021 08:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cVGM2n0LJ/4/bxV10DzA6NIgkNy3e6ltIe3lnX4IFkQ=; b=IVzaDcLDpqm5yFRHtZh1dnCEx1evrE/sfrD7I2nZyiaDlQKHW/l/+5E1S3EurXIg+M cAhVVtpb77s6Mv00G68vaiE5RT4WD+V/82/CdP97497bgEkqjLFXFm/edGwdAlxMlk1i MZp5dMFNP4sabxqMPwfIsMhHKimDXYVAMsA1zgV+yoYUsKWA1YAmQiH0a2nBJwXBoQzN GYa/CbIKXV/CQTJI3X7yBVuBO0nhUwkZo77BN0IxwvZ5w+2Dkk9kBcoxjTy1U0yFwauM +WCNSK7FeaANHP0meAj5xp4nkaWfIVdodfOIFxzgPhNkt7i3Maw8pgui4hNKCKMlQ4ay 2dog== 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:cc; bh=cVGM2n0LJ/4/bxV10DzA6NIgkNy3e6ltIe3lnX4IFkQ=; b=CoxKpX74GZ8I1CUSwgqUBPM1r2sJ1Vd4jKYJRqbYz+Zptq7kaDp4Cua7PMm2tCY9Gt ArxcUXVTi6guHqV/nStuUIP0sqYJceJkuJkZpYiff2PyPdimEjMVX2D1J5Q9RxHbUqM4 fdMggy7M9HmUcoLDIPIBbzaSEjwuvXzaSSty8jqPm/s1V7UcJoAVMDG4ZVFKR0AKZQ9d UFe/DVe0io3cpHUaLUic9gKw0scPSSm4FgnoPGgjqWKtUiDnL0LUZr2mCzbO4qlUoAqH FnFVZWazS/7RXQwHSAT2tqp0t3Tq03AeGQdIIFo5Ok6lVqnNwtH4uTVeZUfSRmYtLnH7 CwLw== X-Gm-Message-State: AOAM531d5gk6C/k60Oa4Yhd7Hwx+v24DekZhc8f/EuSP85ObYrSiPqRt jgJR/ASkVNyKk4gHwEHDT7rtJfOJvSWYTbQMGf7UPtwjKiw= X-Google-Smtp-Source: ABdhPJwgn1SaNqeQVsUMdanA+cOHLHHfEKt78pG7yDi8sjEN4OeHmHdTwHByYZH7kknvJlfWOejyB6pBHW+g3UuwNyg= X-Received: by 2002:ab0:3303:: with SMTP id r3mr16475831uao.17.1629474710231; Fri, 20 Aug 2021 08:51:50 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ines Robles Date: Fri, 20 Aug 2021 18:51:14 +0300 Message-ID: To: roll Content-Type: multipart/alternative; boundary="00000000000046202505c9ffa544" Archived-At: Subject: [Roll] Roll at IETF 112 - Request to fill a survey X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2021 15:51:58 -0000 --00000000000046202505c9ffa544 Content-Type: text/plain; charset="UTF-8" Dear all, In order to help us assess the need for a ROLL session at the IETF 112 meeting, would you please fill the following form *by 15th September.* https://www.surveymonkey.com/r/GDTJGJT (estimated time to fill it: 2 minutes) Thank you in advance, Ines and Dominique --00000000000046202505c9ffa544 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 112 meeting, would you please f= ill the following form=C2=A0by 15th September.
=C2=A0
https://www= .surveymonkey.com/r/GDTJGJT=C2=A0(estimated time to fill it: 2 minutes)=

Thank you in advance,

Ines and Dominique=C2=A0
--00000000000046202505c9ffa544-- From nobody Fri Aug 20 17:48: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 498F83A1453 for ; Fri, 20 Aug 2021 17:48: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, 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 fEgwo8hl0Mbv for ; Fri, 20 Aug 2021 17:48:10 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01C863A1450 for ; Fri, 20 Aug 2021 17:48:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 97383389F3 for ; Fri, 20 Aug 2021 20:53:23 -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 7dxwD5kZ9Sco for ; Fri, 20 Aug 2021 20:53:18 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 94315389F2 for ; Fri, 20 Aug 2021 20:53:18 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B13D3EF for ; Fri, 20 Aug 2021 20:48:02 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Date: Fri, 20 Aug 2021 20:48:02 -0400 Message-ID: <17073.1629506882@localhost> Archived-At: Subject: Re: [Roll] Roll at IETF 112 - 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: Sat, 21 Aug 2021 00:48:17 -0000 Ines Robles wrote: > In order to help us assess the need for a ROLL session at the IETF 112 > meeting, would you please fill the following form *by 15th September.* > https://www.surveymonkey.com/r/GDTJGJT (estimated time to fill it: 2 > minutes) I don't feel strongly about having a meeting at IETF112. If it were in-person, then I would think it very important. I prefer the IETF112 schedule be less packed. I would like to have a series of virtual interim meetings. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Sat Aug 21 22:14:12 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 7F5593A098D for ; Sat, 21 Aug 2021 22:14:10 -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, MSGID_FROM_MTA_HEADER=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=iisc.ac.in 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 GN4N-sUG_fwx for ; Sat, 21 Aug 2021 22:14:04 -0700 (PDT) Received: from IND01-MA1-obe.outbound.protection.outlook.com (mail-eopbgr1380044.outbound.protection.outlook.com [40.107.138.44]) (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 7D6D03A098B for ; Sat, 21 Aug 2021 22:14:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GND0yiN/TN4pykBov+vpc60rEUdsqpt12/G/OJ0wLyPRGqYUKXjJ1O4kIrTGCcfkAp5js8nK68fSSNwHeY6LU2ZOOsQkYiCjvuEI7VipWaTkoNTEA93jVSLJ3oEn+1RK+XBZJxr+UzsDqjBCKP0CkH4DRFMraqiXYlgZ12exRXMHB4nU5eyMw5na+P2hTBb2LWi4SQPzmzkGiw89jtZkP15qRhrl/f3XOvueFIioTt2CrimSqdNimloKidwjtAr5IW1SIrpU4PCM/hNulU5LfeknM4hefO5lYItf2PreXT261W0GAzlAufv022Vumv26xqV5zpjKt+9KJOx9jFoClQ== 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=MxMqAdOYPVAVK6lZVdJbCbkQI6wtqv0ll273yLC13r4=; b=eNswmghMSY+gQXgq7M8WQLETFO/j84/LP4XlvuXpRY2OAMXLaSjI5tRNNF2eudjkJt8Z5ejG4FkEG1zTisWD1H0Ia7Iip2oiojwPscHU6xf+SXC0YPqzJ9w+3ub0rQK7QsjPdPi0nJSXPmNNb2fkcwgzqGwc4o2LUdfQLnXuHmBt/g6BggXg/4+1osNtIUJ1xLrxQqsN50NOMy8bZuvepJHQdlLIjK9gUm07UpWynY5n9hV42g6eAbS1iluQbBfGdFnQRkiLkYG9+eLYCGhWjbjW4O5bpRKsjs/dNSgucImT/DRnd36M85cJMzw15SK+qhZ1YdtElHLGTi11kKs+kQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iisc.ac.in; dmarc=pass action=none header.from=iisc.ac.in; dkim=pass header.d=iisc.ac.in; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iisc.ac.in; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MxMqAdOYPVAVK6lZVdJbCbkQI6wtqv0ll273yLC13r4=; b=jx4TmoMf7IR7N+JyjfKlLV82Ltk85JlLzDjBFECGY8vNPMY0SpO370kknhEhqYWESBZmuMeBJQmtn1PhfN0XqnozoI2Z32qxG7pfTCQJigIv+jNTlLJldZ1y3SYzW93bSsM5jAPXM8KFg8lzCPigBLGXBDoIUS/1YB7mOV+eAYc= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=iisc.ac.in; Received: from MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:37::23) by MA1PR01MB3804.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:7c::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.19; Sun, 22 Aug 2021 05:13:57 +0000 Received: from MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM ([fe80::6096:2bb9:fc3a:cd39]) by MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM ([fe80::6096:2bb9:fc3a:cd39%5]) with mapi id 15.20.4436.023; Sun, 22 Aug 2021 05:13:57 +0000 Date: Sun, 22 Aug 2021 10:43:55 +0530 From: "S.V.R.Anand" To: roll Message-ID: <20210822051345.GA3910@iisc.ac.in> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-ClientProxiedBy: MAXPR01CA0072.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:49::14) To MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:37::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from iisc.ac.in (49.206.10.139) by MAXPR01CA0072.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:49::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.19 via Frontend Transport; Sun, 22 Aug 2021 05:13:56 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d0ae870e-feb7-42f2-8cb1-08d9652ba481 X-MS-TrafficTypeDiagnostic: MA1PR01MB3804: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: zdYe5kpCt93bn08Cjf9SRepZ4J74M90zDi+IqifXxrdAoH67OJAi63bS246W6jK97b7UJthLaThugJqksXzpNDQXkca61PltakvGAuoposNo/QsqeJVBHGXjR44g/LDwXslblFQabxadBAFNHYIsXqT5RZ7xHi90UoLenz3n+maK9y656Ce3uiwciccz5YNZXE7rgRxUeAE4l9dgygEhh7EFTZuSi2IUEQ+xLRjd+K+R1SYRk3iGY+coQ2ZUdiNGboKA1XFdYpX3AKNSS0P9CHpsgFGTJSNxKGu40bi08VTMTnalbu70fzGiEw1ra4/IvlqCE7d3koZO7J8dTfNoYt0R0LR0nyXMnAQ8KEaDSAD9bSxwKkD6xpSwD2TkVB/e6tDZQG0XtMJPWzvsHpW3F2DZ8ZQOL2tunXYxs9NRTm5kgFCh21CYXxwKgvXUDDejaHt3oOocavDAhqRwGFu7xl0H1T5SMFlT/0+uqg7HwPG3IU4LKooNx64zO7Uha9cWnmU+tzMXTC/SodwYmlXFwHs7+vKtvKihpWE2i0veVadHaUST0bVu2DXptiMC6Gzc8PpFe7++kPSehIGNX3MN2zuXKaUhZYtOEb+4wz5j8aSRJ+teDkwuybbIT6bfuN12HXpOn2xgxdQ88kiaAIblh6Cv/XKHDF9MQAzNnJqRrLlsS1KT8ZRCmhQ/8Dfvh5XJtbfR/RKapg3fk2zyIxTywA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(39860400002)(346002)(376002)(396003)(136003)(186003)(2616005)(956004)(2906002)(66946007)(83380400001)(8676002)(786003)(1006002)(33656002)(5660300002)(8936002)(36756003)(55016002)(26005)(7696005)(6916009)(478600001)(52116002)(1076003)(66556008)(316002)(55236004)(66476007)(38100700002)(86362001)(38350700002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?in+8mwLuCped8G0+zazYIcHsHm+ANP1YHZYXAIADjRCGWzQxxROsa01n5s/G?= =?us-ascii?Q?RUBPhKm6wLpPHihTBRUavd7EOlPCbiLiPXtiPKRhRsBLw6L30jnpkJvMba5g?= =?us-ascii?Q?eoAQDKsfjHuS3iFpmSLSHswdfCzuba7ov376uHbrwPc2fhq5WbA3AobT1WbH?= =?us-ascii?Q?umxXkUO/Ph+SyOcNsi013PPQenn9kt16BNqhRH6PZMJG/ROIVZpkRJEJGalr?= =?us-ascii?Q?KdPpJj/yf9ScycoNPk3VVDhKOakNq8H0tCjcprsbVRa6YGIh5h2TamJQPa78?= =?us-ascii?Q?fe4o3+d/VDf4IksHAVcMHztgeTgCf+hXI4hDTtOSuKO2ULO1I6RcZtwqXljD?= =?us-ascii?Q?T9QkGKcfaObpveeR6tAD4VBU7za10aMP+QjYq9bFXx5FewigCB9eJc1psJFv?= =?us-ascii?Q?qlMER6BtNW37ieEkp0te3p8rY6zNMRWwSEeqNiQ/GqPTtmG64YteUYirC6vV?= =?us-ascii?Q?VXl2OpCCP4forfoXCFWPjlSlgQHPXDX0Givcbw9oPCQ/mkaaFgdJiteNl2lc?= =?us-ascii?Q?i0XtaIR3fXE6evx9E4stiy9j8z6EUohnDSwkB0FxvZcf8YbRe+cIHwwExhZi?= =?us-ascii?Q?/O9YDJNP1Y7fsReMnbgyLsV8cYj+dOPkMQAUSpEF79rLNQNZ0jpd57kl2cDV?= =?us-ascii?Q?zmKaUW/RS/J7V7G3+kMaApRxwCTKAkOjLWnWtPC+c0ZXtxz0x5yPVFaEYjKi?= =?us-ascii?Q?4Jp151i9fvlqwdUQ8gq20Qlmeh6GwUzpzkBg+mdgnctk3LI39AfAUg5vVent?= =?us-ascii?Q?b21R1VF2+KubvJWswM/iNgGiXOnKYX30dVxaSVICwlqLSOttOClIuj28+Xqv?= =?us-ascii?Q?QU9rDbE60GmyiyDEOya0sT8K0NNjktOLTjs2ZuBn95ZaAMv9j61v2Be/+iME?= =?us-ascii?Q?1gtngZBxXPSl3XlGuaRMBrvzkcn1rO6Tk8LyoC1pW/Xn75kI36wmsrAnmmkh?= =?us-ascii?Q?P+8xg3nPYnE8ScYCVi3LG0ighv983ESTrVAaQzf+zjJj3/tWVJ7Ov2vMoGQF?= =?us-ascii?Q?DnEr6fiTms+A3X8SGzm2CZiAYWWsHT78jgPMe4QHoPjGEr09u0U67/ui7LTq?= =?us-ascii?Q?WNyYDNT6B9mJyGdlN3P1ZSDaZKOMsA8HhN+it+uk1nv7PbL56FaCCKpxLbqP?= =?us-ascii?Q?3OKHP8EJNFSo8aITltDCaxMxa0nmDwOnl9QUWog25M7sScghjJdTjZcEHcph?= =?us-ascii?Q?dx8Y3t+fZcl+GpHsaUEIvA47pQSURvanNjR+z65v07mnbo3fxqEa5q74Mh6e?= =?us-ascii?Q?B/Flkcz+kkZ0gdMnp7OxTo5Sb4YmW8dOdYowEidYKyGciWfEH+B9o86UX6CM?= =?us-ascii?Q?y+SUPuORYyzcjwvhIhwjc+pT?= X-OriginatorOrg: iisc.ac.in X-MS-Exchange-CrossTenant-Network-Message-Id: d0ae870e-feb7-42f2-8cb1-08d9652ba481 X-MS-Exchange-CrossTenant-AuthSource: MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Aug 2021 05:13:56.9417 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 6f15cd97-f6a7-41e3-b2c5-ad4193976476 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 7WQUTMlSeuPqeg0fIXo1XNccxuEvIU6q4GAOvD1xj2Ps2Ee7pF7qKhIZtCF4vTA28bqpe5lqTGZdpEkqBffsJA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MA1PR01MB3804 Archived-At: Subject: [Roll] Review of draft-ietf-roll-dao-projection 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: Sun, 22 Aug 2021 05:14:11 -0000 Dear Authors, Thanks a lot to the authors for writing up this important draft towards building a deterministic network and thereby aligning ourselves to RAW architecture. I thoroughly enjoyed reading the draft :) Hope the following feedback will be helpful. Regards Anand For an effective operation of P-DAO route projection, one of the keys requirements is the presence of network monitoring mechanisms for LLNs in place for letting PCE have a complete view of the network state. I am not sure if we can assume that such OAM mechanisms are already in place for LLNs as the track setup and its maintenance are closely dependent on these. The effectiveness of the external route computation by PCE is tightly coupled with network resources required for monitoring the network state, stability of the wireless links and delay in obtaining the network state information, and so on. Strictly speaking, this important functionality is a pre-requisite for implementing the draft. I list down few questions that came to mind after reading the draft. - Does the draft allow for the co-existence of centrally orchestrated tracks and distributed RPL operate within the same network ? Since draft does not say explicitly, is it reasonable to expect that both can be present together ? If the answer is yes, then the draft needs to mention the effect of PCE on RPL managed routes, if PCE controls network resources for the entire network. - Curious question closely related to the above. If one decides to use PCE in conjunction with P-DAO to centrally manage the entire network and thereby aligning ourselves close to RAW architecture (Refer to Profile 3 and above of Section 8), and not use distributed routing at all, full-blown RPL seems to offer minimal benefits here. Why not use the compute and memory for the purpose of implementing RAW mechanisms ? - There could be non-negligible indeterministic delays in setting up on-demand tracks before the data starts flowing. Can the draft touch upon the possible ways to minimize these delays ? Should we have dedicated tracks for signaling purposes ? - 6TiSCH has been mentioned just in the introduction. It would be nice to associate it with the P-DAO track installation process. A 6TiSCH track needs to be setup depending on the application bandwidth and delay requirements before sending P-DAO message. In some sense there is a dependency of one on the other. - Can the scope of the draft be extend to mobile scenarios, for instance, networked robotics applications ? These present additional challenges in the form of frequent topological changes causing flurry of network state, and track updates. A short note on the issues that need to be addressed to support mobility could be useful. - There could be situations where the Root can decide to modify the already installed routes asynchronously to maintain the Objective Function/QoS of the tracks. What is the consequence of this action on the ongoing data that is already in transit ? ---------------------------------------------------------------------- Section 1. Introduction The text needs to be re-structured to make the flow smooth. The current text starts off with RPL, abruptly introduces 6TiSCH, moves to DetNet and PCE. One suggestion. The text can upfront state that IoT applications that require deterministic network behavior are well supported by centrally orchestrated network route and bandwidth resource management over PCE. Then introduce 6TiSCH, followed by how RPL is an enabler for route installation. The term "Root" in the Introduction attains special meaning. Is the capitalization required here ? 3.1 --- "The Track Ingress is signaled in the DODAGID field of the Projected DAO Base Object; that field is elided in the case of the main RPL Instance." Shouldn't it be "global RPL Instance" ? 6.1 New P-DAO Request Control Message ------------------------------------- Is there a timeout for getting PDR-ACK message ? If so, what is the value of the re-transmission interval ? One would have assumed to see QoS specification as part of the PDR sent out by Track Ingress node to establish Track. The Root will then come up with an appropriate route and bandwidth allocation that meets the required QoS. After the Track is setup, what if Track Ingress wants to request for additional or less network resources as per the application requirements ? Does it mean tear down the existing Track and sending new PDR all over ? Is there a way of requesting for additional resources ? 6.3 Via Information Options --------------------------- I suppose we can assume that these options are part of PDR-ACK Control Message. 7.1 ---- Expand GUA and ULA in their first occurrence. 8. Profiles ------------ OLD: "This sections described profiles that can be implemented separately and can be used to discriminate what an implementation can and cannot do." NEW: "This section describes profiles..." From nobody Mon Aug 23 07:11:56 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 B1C7C3A1CAF for ; Mon, 23 Aug 2021 07:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.596 X-Spam-Level: X-Spam-Status: No, score=-9.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=HDcGA9Of; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=nVYjdGz+ 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 sSgGQzcS01mX for ; Mon, 23 Aug 2021 07:11:49 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86D0B3A1CB1 for ; Mon, 23 Aug 2021 07:11:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9903; q=dns/txt; s=iport; t=1629727909; x=1630937509; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=qcO4Y1Vg5SilIOX0v7HJrZbRrt6aAoZZUjLpyJ3TUz0=; b=HDcGA9Of3gnWQWXzRCvrAgDwizAOgZ5gH1QoF69KT8Zkv6CJIWlDO2zL 9Q5YvfkOZtq1zfspdEnK0TjKw+nvfR2H+QbEne622rbSlJ+bE93Vo6vux dXcfplE+oBVPFMYKqGVyeeXYnLJHozS/kiE9ggMy1JS3uE3i/JVf3qF+A U=; IronPort-PHdr: =?us-ascii?q?A9a23=3ANBrIFRT/vzXMy2dcECXxLXEoi9pso6fLVj580?= =?us-ascii?q?XJvo7NDbqrl+I7tbwTT5vRo2VnOW4iTq/dJkPHfvK2oX2scqY2Av3YPfN0pN?= =?us-ascii?q?VcFhMwakhZmDJuDDkv2f//ncyJ8G95NBxdp+nihOh1TH8DzL1TZvny162sUH?= =?us-ascii?q?RPyfQp4L+j4AMjclcOyguuz4JbUJQ5PgWnVXA=3D=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3A9O5vLaytw4rC0FVr7R0gKrPxdOgkLtp133?= =?us-ascii?q?Aq2lEZdPULSK2lfpGV8sjziyWatN9IYgBepTnyAtj/fZq6z+803WBxB8biYO?= =?us-ascii?q?CCgguVxe5ZnPPfK7OLIVyEygcw79YET0E6MqyNMbEYt7e43ODbKadb/DDvys?= =?us-ascii?q?nB7o2yowYPPGNXguNbnnpE422gYypLrXx9dOME/e2nl6x6TlSbCBAqR/X+Ik?= =?us-ascii?q?NAc/nIptXNmp6jSwUBHQQb5A6Hii7twKLmEjCDty1uEQ9n8PMHyyzoggb57q?= =?us-ascii?q?Ksv7WQ0RnHzVLe6JxQhZ/I1sZDPsqRkcIYQw+czzpAJb4RH4FqjgpF5t1H22?= =?us-ascii?q?xayeUkZC1QZ/ib3kmhOV1dZyGdgDUIngxesUMKgmXo8EcL6faJNA7STfAx2L?= =?us-ascii?q?6wtnDimhUdVBYW6tMW44vRjeslMTrQ2Cv6/NTGTBdsiw69pmcji/caizhFXZ?= =?us-ascii?q?IZc6I5l/1TwKp5KuZKIMvB0vFsLACuNrCq2N9GNVeBK3zJtGhmx9KhGnw1Ax?= =?us-ascii?q?edW0AH/siYySJfknx1x1YRgJV3pAZOyLstD51fo+jUOKVhk79DCscQcKJmHe?= =?us-ascii?q?8EBc+6EHbETx7AOH+bZV7nCKYEMXTQrIOf2sR42Mi6PJgTiJcikpXIV11V8W?= =?us-ascii?q?Y0ZkL1EMWLmIZG9xjcKV/NFQgFCvsurqSRn4eMCoYDHRfzPWzGovHQ1cn3WP?= =?us-ascii?q?erKcpbEKgmd8PeEQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C2CABwqyNh/5tdJa1agQmBWYFTKSg?= =?us-ascii?q?Hd1o3MYgPA4U5iAQDj3SKS4JTA1QLAQEBDQEBKgsMBAEBhGoCgjkCJTcGDgE?= =?us-ascii?q?CBAEBARIBAQUBAQECAQYEgREThTsIJQ2GQgEBAQECAQEBECgGAQEsDAQLAgE?= =?us-ascii?q?IEiQQJwsXDgIEEwgaglCCVQMOIQEOnQIBgToCih94gTOBAYIHAQEGBASFChi?= =?us-ascii?q?CNAMGgTqCfoJzU4cxJxyBSUSBFAFDgmI+gmIBAYFig0uCLoRBCRFbBhcnJgQ?= =?us-ascii?q?DFRoRECIuCwIDbQMOAR4GAQ8eAgorD5EXExMHqmeBDwqDKp5wEqBChja2LgQ?= =?us-ascii?q?PDQEBhGUCBAIEBQIOAQEGgXclgVlwFTuCaVAZD4M3jA8BB4JEhRSFSnM4AgY?= =?us-ascii?q?LAQEDCY5qAQE?= X-IronPort-AV: E=Sophos;i="5.84,344,1620691200"; d="scan'208";a="654313940" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Aug 2021 14:05:57 +0000 Received: from mail.cisco.com (xbe-rcd-004.cisco.com [173.37.102.19]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 17NE5tVi029942 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for ; Mon, 23 Aug 2021 14:05:56 GMT Received: from xfe-rcd-003.cisco.com (173.37.227.251) by xbe-rcd-004.cisco.com (173.37.102.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 23 Aug 2021 09:05:55 -0500 Received: from xfe-rtp-003.cisco.com (64.101.210.233) by xfe-rcd-003.cisco.com (173.37.227.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 23 Aug 2021 09:03:11 -0500 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-003.cisco.com (64.101.210.233) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Mon, 23 Aug 2021 10:03:11 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R3kGd4Ca97rBH3SZ9XokvtMlN02OXzO6dAZ7vuEi6Q53/NXrCb3H0KAD21VECE25o5bsDWJM+sXLkdy473zpOLG1twC+RVjtJeQvRDntK54mnrxCA5FbdER/sr8mhoIJ+S6ARMBQgrYcgQJ1ECodQyaWE/JXehLXjdUy076AUdlsbPRn76sb9BZ68QjVrM5E4hiFzeLyM7TRTWSZpN+ihSUbXEreSqzPG6EjBbqrMxvxpJtxZ189J2uY4f5xUKYvnAWEAO0urTps9Sq5yy5ZU01fpOij7GFA57YOQ3S4uUB6DKEREFGxUt7oiJiJibCoI+RmqqTl4QUIuq/C6eo1Mw== 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=4CTQiScq1vz5fq7ZawSWc7Vox6Nfg9DMGlR3UnGF0bs=; b=NJX4/r+Y4bbVEXHEdhnm7GTyoFhI8odzKVr1Ur65Vs2p3Stq8QYJD75QJ8ks4q38s+YMx0uG9vsp/L4AIC5R8afp9ClzocEdZJjlKGsdMfZY+eM0PIrVgV6kIHxhjn3T+nPXe524Yuglovd8LcTkE1WSHd8rkP6mkwi0TaxexcYOp3NKh25+FdYwbeU3y6lJ8H3HzKQgg2UcmI4h24JSEffHLUL5C55OljfGruTxoOsFevITRLqxzDJuQyQB0hHTOXfjmQ/FH9S7KyPhtngXR0fWsgNvj8VE2wx7bMCoGommTTlGf/yVnYVBliX7oz3hUZA/L+H7Ja0mlhYiaOH8Nw== 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=4CTQiScq1vz5fq7ZawSWc7Vox6Nfg9DMGlR3UnGF0bs=; b=nVYjdGz+crh8g8lvP0zUr5AxudOO1UTp6WY6kR/CYBhwi/LHXSAMG6oEdSyieP4Udxb8EJIJ+y5fGd56XjZP1D6a8dH5rx6tkQCYv0zO5OKu/IUzzdVqKTXxW8jbOWRF/ennTHsYccjuQtBmvfpEZ2pVtRHEHv6YGkaE/oYMoBY= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by CO1PR11MB5139.namprd11.prod.outlook.com (2603:10b6:303:95::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.19; Mon, 23 Aug 2021 14:03:10 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::487e:47b8:314f:189a]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::487e:47b8:314f:189a%8]) with mapi id 15.20.4436.024; Mon, 23 Aug 2021 14:03:10 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Review of draft-ietf-roll-dao-projection Thread-Index: AQHXlxSTAPML4x4cU0Sn5jf1yiT0lquBCZ5Q Date: Mon, 23 Aug 2021 14:02:56 +0000 Deferred-Delivery: Mon, 23 Aug 2021 14:02:46 +0000 Message-ID: References: <20210822051345.GA3910@iisc.ac.in> In-Reply-To: <20210822051345.GA3910@iisc.ac.in> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a30215ba-b10f-427d-2382-08d9663ebd72 x-ms-traffictypediagnostic: CO1PR11MB5139: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: LLTvnQy/kL4ssV32YTToePgmZ4RLTfAzweuIC6sE4frKEsSPnIjnklIxEg8wlmqHB+qmA3F/o7EOa034Kqm1zEbMYMtZd1rxvsJ+ZfCAJXZOjH05Dn0iajFCGYOouh1OQ34bqgQn/2TEnhRePvAkVgXJUiWbNcvEuFloHptch92Qp/83PQnA1KzuE/Rg7O7aU60nqK5z4B1tEnXt2Ax99/hT0v1J+9ISaoZ7IFyZPyBOInR8ujA545EydIgM1IGsTIltWwmLTPCr25UAQG3+tm8OsZ9M7h3Pjp/kYbGQyfaGAehB89h46Sjo951h6zz4V7HyEtigQ51dkMdL81k+FVMmxxI2769I0YyPpjjI4DmEYMFk63G8yv9S2N34XaAQ+LaRJEM1qqQql5RVeGtx8LjOvnCFS+8DDntm01H9Qc7J4Iuq4vFUJ+i2XjjTSN3WysSQtok91V3T9K3EnrabmrSeUa7qzxNZuF3dOdAV1vZXvwQtF/W2rA2VqtZ9fjgyzUPng8B2B/GzTj1qcbotzkDA63uHQqwCc7c78Kj1UxbcBMghNjEspUEIhEgtD64fSlN3nYq1kdQbiDQ5Ey5BpEo5f+ehCu5ElVp4IByXlbypr0b34NIe2ku7kU56fC0Hubt/tLvidc/5+20xg561BnZ86jKZaYGj9OSH4DyqSq3uoX5v0s/Fjxpp4+Y4Tv2XLZ523KeSbr8Eu4bey+GylLPMtFFOs9Rxp9nLVsNXiEy4SVOlVlQSd5aIpRTYjqVJY5rUnFJA68Ij/lEhfLPZpC3HkER1znIF/8WMnIlrpAU= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB4881.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(39860400002)(346002)(396003)(376002)(366004)(76116006)(8676002)(66476007)(6506007)(66946007)(66446008)(52536014)(33656002)(71200400001)(7696005)(66556008)(38070700005)(122000001)(55016002)(26005)(5660300002)(86362001)(6916009)(8936002)(478600001)(966005)(186003)(9686003)(2906002)(83380400001)(316002)(64756008)(38100700002)(6666004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?Q121tOyLgK2a5y/+7hSgCLBl4yxWoGzXA4leUZGBvXg8UdcVpvwtPdTrPFOl?= =?us-ascii?Q?Ydm83A/Ie4xwnmfRIwve/ESmxtYHRdECH0f5ajYGg270UKB2LK3bQjc0Vuy2?= =?us-ascii?Q?qdUKY2+DgiQQBDIORgNPXOONyklNB7sz9zN9P8Jpd+EIKWmVNdh5K2tjmNuc?= =?us-ascii?Q?Oev8O5j8x8CQu5o81O9BVb5C2oZts3DuxNAC9yxtn6qlwv6uyf7joWW8QL0p?= =?us-ascii?Q?DUFMClppVZS6h3cWdSyjMtFtb2SADdIf4csQew8Ceju/NbUGLi7Hzitg0P54?= =?us-ascii?Q?4AQl2Ar4sVsTV35iJLE5QrLgzmoD1CJnYWzwsYiJSGPMMz6a1+3dbn/RQpyz?= =?us-ascii?Q?Yfw6coDiiae+cwwO9YHL/cJw/++pe+v+mREGWJRS01Ts+oUg6rXoGQR5CkLr?= =?us-ascii?Q?Q9gQSxOZhGwaGoh+Es60dHyT9jS0MfQRoGxrPB0q2tRZ0OdsAe0+9TDmZ9p8?= =?us-ascii?Q?gCla5gvlon00rg7vTTXM35luv4FKFaKsBagGmB562LygcgVZvnad0HTxpiAt?= =?us-ascii?Q?PcTtUI/zvU5JB6Uk2YOOiydOCHmUTN0AOc7U3cljCUN4ef2tsRxLnLojXSrx?= =?us-ascii?Q?qhUckyI0di7W+yqLAP9/uymsunBWRr1Nw79mS+DBoQbJeJbsQuvbmoAohrN6?= =?us-ascii?Q?dTPJ5FkQpWQRdUk3rPqdzHgrnKqmyoS/yHSmVxhk84YE5F5TGsxWHNOlY/j4?= =?us-ascii?Q?SzZOIpssdXy9cWaV1LNLJUfMJTqA95+hrz2oTIiwALbBAJBACgABHZrbFl/w?= =?us-ascii?Q?jO8LbYn+RtrkHVqVAnrcwWx1nD7eZgV+kCp0hkw5y9MDGMz9OUgE7xMW9U6+?= =?us-ascii?Q?I+OA019D70zeKfI1UER034jTO11A3nhGGn5pn4nPD/KRV1vx4SMNFE4orq3V?= =?us-ascii?Q?fmwDB+Kfr1Wo+VigG36tI1nKoIUwhoCDiC4fZxlT6bfPJu55my4CDncOyAKE?= =?us-ascii?Q?oAAcl5E0cinG0LeeQ0DY6UhrfBLwRyqT/rt82oa0IhX1POvBFb+qkGFH3iaH?= =?us-ascii?Q?4W726yFoq7NvazIUjkoJ9QrHoTx6Yiz6PNVzKVdMFI97TNhMBumbhxJnIXMP?= =?us-ascii?Q?JvrFLpsRGTBuPfkGt7kQn26Nt5mkMM1UFU3VBHFKlnA6+VzskFnmVDNGj2BE?= =?us-ascii?Q?rilMML49uJBFzx8yYZ08zY8eaW9Xr5sKj04nVNwPSSJDL+b6w38TTwDnGOHY?= =?us-ascii?Q?vdhSwPEfxcMkHgajuJGGEJP+lHAzgv8a02YRtjWYNnhVq3D1YLWlp21BRL/j?= =?us-ascii?Q?xT95npqqpuGZjXKCcwQY80NicS4D+7PD9ARXAZD71Lljj+faSUvagvTyyInL?= =?us-ascii?Q?psBGCyNVRkxtj1YpkoaIx7xb?= 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: a30215ba-b10f-427d-2382-08d9663ebd72 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Aug 2021 14:03:09.9436 (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: AKomvMDfCkeNP98R++vrXOpa9RSt7fZhMMccPOgnzrFvcejq+UfnroyLJpVIi+Z1cLWOHfuhB4SSG/VxAuIqwA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB5139 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.19, xbe-rcd-004.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [Roll] Review of draft-ietf-roll-dao-projection X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 14:11:55 -0000 Hello Anand, Good to hear from you, been a while. Many thanks for your review! Let's see below: =20 > Thanks a lot to the authors for writing up this important draft towards > building a deterministic network and thereby aligning ourselves to RAW > architecture. I thoroughly enjoyed reading the draft :) Neat, thanks! =20 > For an effective operation of P-DAO route projection, one of the keys > requirements is the presence of network monitoring mechanisms for LLNs > in place for letting PCE have a complete view of the network state. I Very true... > am not sure if we can assume that such OAM mechanisms are already in > place for LLNs as the track setup and its maintenance are closely > dependent on these. That too. The combo of this draft and RAW assumes that the PCE gets long te= rm stats and availability information, and computes routes based on that. The effectiveness of the external route computation > by PCE is tightly coupled with network resources required for > monitoring the network state, stability of the wireless links and delay > in obtaining the network state information, and so on. Strictly > speaking, this important functionality is a pre-requisite for > implementing the draft. Yes; the PCE computation can be proprietary since it is inside the box so a= rguably the missing link is the metrics and formats to be reported. Should = we do that in the same doc (complexity rising) or should we separate a new = draft like RFC 6551 vs 6550? I'm tempted to do the latter. For now the PCE can live with existing link-related network management info= rmation to compute its routes. >=20 > I list down few questions that came to mind after reading the draft. >=20 > - Does the draft allow for the co-existence of centrally orchestrated > tracks and distributed RPL operate within the same network ? Since > draft does not say explicitly, is it reasonable to expect that both > can > be present together ? If the answer is yes, then the draft > needs to mention the effect of PCE on RPL managed routes, if PCE > controls network resources for the entire network. =20 Well, the assumption is that the root is really a proxy for the PCE, turnin= g whatever abstraction the PCE uses into RPL. See the intro:=20 " This document specifies protocol extensions to RPL [RPL] that enable the Root of a main DODAG to install centrally-computed routes inside the DODAG on behalf of a PCE. " If your question is what if both the Root and an external PCE compute route= s, well that's beyond this work. This would mean syncing and negotiating th= e use of constrained resources. > - Curious question closely related to the above. If one decides to use > PCE in > conjunction with P-DAO to centrally manage the entire network and > thereby > aligning ourselves close to RAW architecture (Refer to Profile 3 and > above of Section 8), and not use distributed routing at all, > full-blown RPL seems to offer minimal benefits here. Why not use the > compute > and memory for the purpose of implementing RAW mechanisms ? I think that's the same point that the Root is really a proxy forwarding in= RPL parlance the abstract route decisions by the PCE. This is enables a si= mpler operation with less code in the devices. >=20 > - There could be non-negligible indeterministic delays in setting up > on-demand tracks > before the data starts flowing. Can the draft touch upon the possible > ways to > minimize these delays ? Should we have dedicated tracks for signaling > purposes ? Oh, interesting. Usually such thing happens with a net priority QoS. Mainta= ining dedicated tracks may be fragile, since they would be needed to repair= themselves. True that the draft says nothing about that. I agree it should= . Any suggestion?=20 > - 6TiSCH has been mentioned just in the introduction. It would be nice > to associate > it with the P-DAO track installation process. A 6TiSCH track needs to > be > setup depending on the application bandwidth and delay requirements > before > sending P-DAO message. In some sense there is a dependency of one on > the other. There is indeed. I can add more words on that too. This can be done togethe= r with your other suggestions below. > - Can the scope of the draft be extend to mobile scenarios, for > instance, networked > robotics applications ? These present additional challenges in the > form of > frequent topological changes causing flurry of network state, and > track updates. > A short note on the issues that need to be addressed to support > mobility could > be useful. I've worked on interesting techniques that could apply. What strikes me is = that you're describing an applicability draft as opposed to modifying the s= pecification. Could some of your proposals actually become the subject of y= et another draft, this time on applicability of P-DAO? >=20 > - There could be situations where the Root can decide to modify the > already > installed routes asynchronously to maintain the Objective > Function/QoS of the tracks. > What is the consequence of this action on the ongoing data that is > already in > transit ? We're in RAW territory here. I'd say that the PCE/Root only updates segment= s at a time so the parallel ways still operate nominally and enable the con= tinuous service. One the additional path is installed, the Root can swap th= e Track (the source routed thingy) to use the new segments. All in all, wit= h the redundancy that we can expect here, it seems doable to do it live. > ---------------------------------------------------------------------- >=20 > Section 1. Introduction >=20 > The text needs to be re-structured to make the flow smooth. The current > text starts off with RPL, abruptly introduces 6TiSCH, moves to DetNet > and PCE. >=20 > One suggestion. The text can upfront state that IoT applications that > require deterministic network behavior are well supported by centrally > orchestrated network route and bandwidth resource management over PCE. > Then introduce 6TiSCH, followed by how RPL is an enabler for route > installation. >=20 > The term "Root" in the Introduction attains special meaning. Is the > capitalization required here ? Great suggestion, I'll work on it. >=20 > 3.1 > --- >=20 > "The Track Ingress is signaled in the DODAGID field of the Projected > DAO Base Object; that field is elided in the case of the main RPL > Instance." >=20 > Shouldn't it be "global RPL Instance" ? It's still the main, and it's true that the main is a global in the use cas= es I have in mind.=20 Basically the Tracks are built within a larger DODAG that encompasses the n= odes in the Tracks and allows to configure them. >=20 > 6.1 New P-DAO Request Control Message > ------------------------------------- >=20 > Is there a timeout for getting PDR-ACK message ? If so, what is the > value of the re-transmission interval ? There must be but the value can be very different with use cases; same as R= PL we avoid giving values here. >=20 > One would have assumed to see QoS specification as part of the PDR sent > out by Track Ingress node to establish Track. The Root will then come > up with an appropriate route and bandwidth allocation that meets the > required QoS. Yes. We probably need to define a QoS level for the whole signaling. >=20 > After the Track is setup, what if Track Ingress wants to request for > additional or less network resources as per the application > requirements ? Does it mean tear down the existing Track and sending > new PDR all over ? Is there a way of requesting for additional > resources ? Again RAW territory. There is no concept of distributing the load so we can= add / remove resources and do load balancing as well as PAREO. There is no= text on policies at all, whether that describes using network coding etc..= . I agree with the need, and would think that this belongs to RAW. Here we = set up the routes but not the ingress policies. At the moment every packet for which the Track is the route is injected in = the Track and flooded. RAW can add: - a subTrack selected by the PSE within the Track (already in the archi) - load balancing and network coding so as to use more bandwidth in parallel= (can add text in the archi)=20 For ROLL: if the RAW policies can do load balancing, I agree that the PDR /= PDR ack should indicate the required resources and the requested changes. = Same point as before, it might makes sense to make all the metrics and sizi= ng a separate draft (the RFC 6551 of the day), to reduce the complexity / l= oad on this one. >=20 > 6.3 Via Information Options > --------------------------- >=20 > I suppose we can assume that these options are part of PDR-ACK Control > Message. The idea was that the PDR ACK to the Track Ingress indicates the trackID, a= nd that a non-storing P-DAO to the Track Ingress for that Track ID has the = SR-VIOs. Are you suggesting a change? >=20 > 7.1 > ---- >=20 > Expand GUA and ULA in their first occurrence. Will do >=20 > 8. Profiles > ------------ >=20 > OLD: "This sections described profiles that can be implemented > separately and can be used to discriminate what an implementation can > and cannot do." >=20 > NEW: "This section describes profiles..." >=20 OK I'll be editing once we agree on the details like the 2 drafts that your di= scussion seems to siuggest. Take care, Anand. Pascal > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Mon Aug 23 10:09: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 9664F3A183E for ; Mon, 23 Aug 2021 10:09:41 -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, MSGID_FROM_MTA_HEADER=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=iisc.ac.in 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 MwTzLTMpv_hR for ; Mon, 23 Aug 2021 10:09:35 -0700 (PDT) Received: from IND01-MA1-obe.outbound.protection.outlook.com (mail-eopbgr1380051.outbound.protection.outlook.com [40.107.138.51]) (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 A1BE43A182C for ; Mon, 23 Aug 2021 10:09:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OCaHV6qIrk4AAtUZ2xuDBBYn8nk0CpcNCljD61D8nlGYOIuUwPrD3Q3hG+nUkwdn28tdB3YuIKQs9OdFeq6Zxp93IuxWtnAloxduQPT+ESYtFuPezEY1csHS5PJOLjKvOhqNsCwoZxRtBSZLYhJt2mOPmH8i/FfNRgZHgd2Xl4XH2oLzjhI7kVIvaQIo5FPf8plyE7/eCddjGkt9T3R2yNxdjoOTY0JWdBAlO7rLGSdWsfTx8szxmF+QhKfxoLNHcjHs+ssnRgI7njisLTP1vXhr1y3NbLz8Rd8UEtLBz0mPNm7j3tmMqweT68q6foq2aZECzYf5TVaKNzvtoDPQqw== 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=HCq8pEmII3lV6iEVFp0FSzGO01wf5S7OQJpZdhFhhy8=; b=dQTsCKfU6cVxoFifU4Ss6E/z0lBGCNX/jq3cm5lN1GT5W2qSqcwzv7BXTieNQ2c4FDLpuhOQ+wSsccYc1F/DJKQOMy9VFHQ5/8HM/jYL0DAF7GSNsoNSEZv7ZtOVkrQXMKAmRyRE2oIBTnHbRpMDRdc9RsvrNqQw31vaoIi64w0oKWfhJC8OKVd4I3aVETAvDohdw2CNninPlum/mIQkb5qM0S24sA4jvhPFtbgivfZ2XPc9WSWk9iTcHE1c4+SJbXdufsYOfQOeN385DnxpkX5adwSqd2WQ1+dgqoDiQ3+iCsWG+zQXaSamwcOca4glRTwzQcI+AzfMMDfdQtjjEg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iisc.ac.in; dmarc=pass action=none header.from=iisc.ac.in; dkim=pass header.d=iisc.ac.in; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iisc.ac.in; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HCq8pEmII3lV6iEVFp0FSzGO01wf5S7OQJpZdhFhhy8=; b=tGuzty6GM6HG3N0MEYQF3bOgxCyWeWrol3L9WnD1Ed+rl7f9lqH5AGMIB0+MihvjeThxQAOcdxckQuZIlQeliGKr6w/wuzgBJFEgcDOcRsuN2n4O/oYk4qtTPruVT51goPov3SwRfpV+VbK3tJXbi64hGSgm/p7guklwS9rcKUk= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=iisc.ac.in; Received: from MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:37::23) by MAXPR0101MB1547.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:12::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.19; Mon, 23 Aug 2021 17:09:28 +0000 Received: from MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM ([fe80::6096:2bb9:fc3a:cd39]) by MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM ([fe80::6096:2bb9:fc3a:cd39%5]) with mapi id 15.20.4436.024; Mon, 23 Aug 2021 17:09:28 +0000 Date: Mon, 23 Aug 2021 22:39:26 +0530 From: "S.V.R.Anand" To: Routing Over Low power and Lossy networks Message-ID: <20210823170926.GA4577@iisc.ac.in> References: <20210822051345.GA3910@iisc.ac.in> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-ClientProxiedBy: MA1PR01CA0151.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:71::21) To MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:37::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from iisc.ac.in (49.206.10.139) by MA1PR01CA0151.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:71::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.19 via Frontend Transport; Mon, 23 Aug 2021 17:09:28 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d51abbcc-43a9-4865-cc2f-08d96658c420 X-MS-TrafficTypeDiagnostic: MAXPR0101MB1547: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: BCGN9uloHCIdtW/eCsIxzz+mo8KBVKMTEItueY3L+66hzhiGTODgfFghEsdm+/JqwBBCtRyBr/pKDSnrZVbzuxD+WW9Xydt8WhBaBobDqz9sW7iTffZZjV8faod4z0QlqaHJhoJuJbVT/XfVP48zxwGwOPbgf8/tWKrK9Wk5Zt4E17Z3S4DcX7HoSrKBFAn8AusAr3FXDo0O8HgyGXZyF8btBz+kJtXco5ffDG7LqG9YwyRLurBk+/3Ao/14xfqTuFyXPN2o3auFFHTtjaVPNW1pnjeX/xBH3CPWbJklNMOuDESdrQsHUawcQNaYEzt8FETbcnbLNcL+ekzYpInrQWyvYaISDULSTAioL19C1UZlA8Wbb8BtSbE6jFn1gv3GpRdAAWwl/BFeTpdUZFW/XsDzv3G1C1VPD46EtzQ4yDy/k3NejT4w6Q3wREOK52N0ub8FO6x0SnQkCZG2wU6kCqvy0SPPdH4wuzX/VJqcKwtZSdGO86M1il3IwhBjh6O6J5KxooicwLCFNcYrK8e6cVopviifOLnomxM8TlbwynUsPz4lnPypNdyI71pdmktyhAMJIXA1VS+SjA9EudjDACvn3TyLpbo2pj2wws6W7IGt5psNw2FQcUSDSkTrM1R9vAyqpPMN2yfBLVGYg/Bf/+++OUIc1HIgr9h5DO/XvDBqJJD20V5Ape3+6Az9LbYF/CCuCJ0LeGKS1ECScbzMh4Zmum4NUKrK29IuamE37f13KTa8OMhOvJ11WBQYl+cfvhMQjs2VlA1eKaIx07BAXw== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(136003)(346002)(39850400004)(366004)(376002)(396003)(2616005)(956004)(52116002)(7696005)(83380400001)(316002)(786003)(30864003)(2906002)(478600001)(36756003)(86362001)(1006002)(6916009)(26005)(38350700002)(38100700002)(55016002)(5660300002)(66476007)(66556008)(66946007)(186003)(33656002)(8936002)(966005)(1076003)(55236004)(53546011)(8676002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?v6MUmrpMkyby635KNuw2YlHtvMsvLUP/FUnKx1kZw+j4n7GbOku762iktDD/?= =?us-ascii?Q?k976Ze8cNk2kDnBPrkvT4+oESiJUDtN8ZW7bTS4QVnah7A3Kd0HJ4iHrR3rj?= =?us-ascii?Q?miYYLhB8q4qTU2iTchJMkwDPNiQMOy+M5IsPDsH2gUR4HbTf3fE1VE+Wa8VN?= =?us-ascii?Q?l9dbKAvwvK3X8Gbzs6kCNHC5+ro7O8ATPukZNvIE75DEbrY2GYNstgvgI/1p?= =?us-ascii?Q?Jo0fy+U92sfguzTG9G0GOLsYlrQ7qlnqU5Uj3Z49TKUtE5vECVAp9C2V6TOk?= =?us-ascii?Q?qNWF0HX1Tpg4FG+3PdAFUo8VtuIXQxmy7yOwV1bgmwGktpKGar2ItyEKkHH2?= =?us-ascii?Q?c+B6g8/yHizYCCvwTobT8iI0FXc3Ul2FK5R+pD3fu/47TyqmKEyyhCYzuhxy?= =?us-ascii?Q?l4f9qXzZLLWbfRQQ3nrB/RbABFbRrtzC4J+k6BszJbRpxLn02ULR2Ynwd8EY?= =?us-ascii?Q?uLds0AKH4LsHeTE+MHedZgxF3ldH8YGeYT6yhRdY1RwPQ5xMT7wyx650Ojnd?= =?us-ascii?Q?Y0VYD2o+wyxqhPVMwc3770809EP2vDXfRyoFpMmEXWcnDlbeMfUlIUVlz1iR?= =?us-ascii?Q?b/ikni/d0qzuEBjdQvoDVEo2VqAlbm2HhF+SsHfE73ovQGlq+ZnmO3L3mMX8?= =?us-ascii?Q?BZS0iTOHtstuT7PfmuLoUD1dj6iDtKWbUKC8J1OSyS/CgQFcAtilbe4Itoar?= =?us-ascii?Q?4jq3GPFOjTHAmMRFjyMj4J/BvL5ewvvBGkgG0Motafh73qDqJo2DvXZYhxO4?= =?us-ascii?Q?H/MmbAjFJe6bDLNFZT9oGVVYuAravJ6dYfPCxDMfgd0fKgoqDi0TeBRcCH5z?= =?us-ascii?Q?pYdgMY3U3qti6YLNkXKyMeKej4Mm3LonexllucXcswUsmHi5Eur53CL1jO/J?= =?us-ascii?Q?g2PM7y1xgh2+ix3jOvPA1c/YUzlLHx1h2/IwzdQsrWsXRLrncxUjISOvfHjU?= =?us-ascii?Q?hhxEyOollQfciwLJt+bThCXuKaB0moUaryvmIvhntMzbcTl0kRCh3W20zFvM?= =?us-ascii?Q?IiiYnieGjradynvTA16DESv8BmvP8yBfntx7KXB0eN6+08hgPRYM+Wihh5jW?= =?us-ascii?Q?hDL4+QrOErK0zypdJaZC1vye90wJ/Z92B9Hv2tArn5zEL6k/Vib36dG0nwW4?= =?us-ascii?Q?d+1gunyjMnsH3T2tGeAjoauTL4hrvfx1fDak/5LJs8pNMT+HMf4PLPrDPpGT?= =?us-ascii?Q?Sxz98BF6/VjY73CZ9OGiq5Zib3RNIYji8wCYTkgTv6ccY9RVb/zzR/B9j1sI?= =?us-ascii?Q?bTatlc+jOMBassQa/otZtds0BPghamWEIvUUBRt0cPl6xyB2VZSoc6eKUcZc?= =?us-ascii?Q?ba4MuH1+q2ejC1iLj7L77qYe?= X-OriginatorOrg: iisc.ac.in X-MS-Exchange-CrossTenant-Network-Message-Id: d51abbcc-43a9-4865-cc2f-08d96658c420 X-MS-Exchange-CrossTenant-AuthSource: MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Aug 2021 17:09:28.4723 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 6f15cd97-f6a7-41e3-b2c5-ad4193976476 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: WZaaPN/Ht5pcLzCdWPSI/hEBd6rpua9AR+QNHdLPZwE3gXf8ZP2yzRomZ5GVE9W9SDNarL7KWDyxTu7uwZn4fg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MAXPR0101MB1547 Archived-At: Subject: Re: [Roll] Review of draft-ietf-roll-dao-projection X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 17:09:52 -0000 Hello Pascal, Thank you very much for quickly responding to my review. We are almost in sync. Let me present my thoughts to some of your responses below. Regards Anand On 21-08-23 14:02:56, Pascal Thubert (pthubert) wrote: > > > Hello Anand, > > Good to hear from you, been a while. Many thanks for your review! > > Let's see below: > > > > Thanks a lot to the authors for writing up this important draft towards > > building a deterministic network and thereby aligning ourselves to RAW > > architecture. I thoroughly enjoyed reading the draft :) > > Neat, thanks! > > > > For an effective operation of P-DAO route projection, one of the keys > > requirements is the presence of network monitoring mechanisms for LLNs > > in place for letting PCE have a complete view of the network state. I > > Very true... > > > > am not sure if we can assume that such OAM mechanisms are already in > > place for LLNs as the track setup and its maintenance are closely > > dependent on these. > > That too. The combo of this draft and RAW assumes that the PCE gets long term stats and availability information, and computes routes based on that. > > > The effectiveness of the external route computation > > by PCE is tightly coupled with network resources required for > > monitoring the network state, stability of the wireless links and delay > > in obtaining the network state information, and so on. Strictly > > speaking, this important functionality is a pre-requisite for > > implementing the draft. > > Yes; the PCE computation can be proprietary since it is inside the box so arguably the missing link is the metrics and formats to be reported. Should we do that in the same doc (complexity rising) or should we separate a new draft like RFC 6551 vs 6550? I'm tempted to do the latter. > > For now the PCE can live with existing link-related network management information to compute its routes. > > > > > > I list down few questions that came to mind after reading the draft. > > > > - Does the draft allow for the co-existence of centrally orchestrated > > tracks and distributed RPL operate within the same network ? Since > > draft does not say explicitly, is it reasonable to expect that both > > can > > be present together ? If the answer is yes, then the draft > > needs to mention the effect of PCE on RPL managed routes, if PCE > > controls network resources for the entire network. > > Well, the assumption is that the root is really a proxy for the PCE, turning whatever abstraction the PCE uses into RPL. > See the intro: > " This document > specifies protocol extensions to RPL [RPL] that enable the Root of a > main DODAG to install centrally-computed routes inside the DODAG on > behalf of a PCE. > " > > If your question is what if both the Root and an external PCE compute routes, well that's beyond this work. This would mean syncing and negotiating the use of constrained resources. Yes, as you noted, my question is the latter where both Root and PCE are in operation. There will be a continuous churning of the RPL maintained routes whenever PCE re-provisions network resources for its own purposes. It is hard to maintain the objective functions of the RPL instances. How do we then resolve this possible situation in the context of current work ? Once the proposed mechanism allows for the co-existence of centralized and distributed routing mechanisms, then we need to worry about protecting RPL routes. Can the draft say something about it so that implementors are aware of the scope of the work ? > > > > - Curious question closely related to the above. If one decides to use > > PCE in > > conjunction with P-DAO to centrally manage the entire network and > > thereby > > aligning ourselves close to RAW architecture (Refer to Profile 3 and > > above of Section 8), and not use distributed routing at all, > > full-blown RPL seems to offer minimal benefits here. Why not use the > > compute > > and memory for the purpose of implementing RAW mechanisms ? > > I think that's the same point that the Root is really a proxy forwarding in RPL parlance the abstract route decisions by the PCE. This is enables a simpler operation with less code in the devices. > > > > > > - There could be non-negligible indeterministic delays in setting up > > on-demand tracks > > before the data starts flowing. Can the draft touch upon the possible > > ways to > > minimize these delays ? Should we have dedicated tracks for signaling > > purposes ? > > Oh, interesting. Usually such thing happens with a net priority QoS. Maintaining dedicated tracks may be fragile, since they would be needed to repair themselves. True that the draft says nothing about that. I agree it should. Any suggestion? > One suggestion is to identify and maintain dedicated reliable signaling tracks with minimal resources to cater to latency critical tracks that may be setup in near or far future. These special signaling tracks, as decided by application requirements, can use redundancy so that the tracks are always available. > > > > - 6TiSCH has been mentioned just in the introduction. It would be nice > > to associate > > it with the P-DAO track installation process. A 6TiSCH track needs to > > be > > setup depending on the application bandwidth and delay requirements > > before > > sending P-DAO message. In some sense there is a dependency of one on > > the other. > > There is indeed. I can add more words on that too. This can be done together with your other suggestions below. > > > > > - Can the scope of the draft be extend to mobile scenarios, for > > instance, networked > > robotics applications ? These present additional challenges in the > > form of > > frequent topological changes causing flurry of network state, and > > track updates. > > A short note on the issues that need to be addressed to support > > mobility could > > be useful. > > > I've worked on interesting techniques that could apply. What strikes me is that you're describing an applicability draft as opposed to modifying the specification. Could some of your proposals actually become the subject of yet another draft, this time on applicability of P-DAO? > I agree with your view. What about P-DAO for mobility as an independent draft ? There you might want to describe the techniques you have developed. I am not in favor stuffing-in all the interesting opportunities into the current draft. Can you introduce a "Scope" section where the applicability of P-DAO is mentioned ? > > > > > - There could be situations where the Root can decide to modify the > > already > > installed routes asynchronously to maintain the Objective > > Function/QoS of the tracks. > > What is the consequence of this action on the ongoing data that is > > already in > > transit ? > > We're in RAW territory here. I'd say that the PCE/Root only updates segments at a time so the parallel ways still operate nominally and enable the continuous service. One the additional path is installed, the Root can swap the Track (the source routed thingy) to use the new segments. All in all, with the redundancy that we can expect here, it seems doable to do it live. > Yes, RAW territory indeed. I am strictly going by the abstract of the draft :) Since Root/PCE does not know if the track is currently engaged, route modification which includes deletion of the routing entry can potentially result in data loss if we don't do what you suggested above. I think including some text helps in answering a natural "what if" question that I got. > > > > ---------------------------------------------------------------------- > > > > Section 1. Introduction > > > > The text needs to be re-structured to make the flow smooth. The current > > text starts off with RPL, abruptly introduces 6TiSCH, moves to DetNet > > and PCE. > > > > One suggestion. The text can upfront state that IoT applications that > > require deterministic network behavior are well supported by centrally > > orchestrated network route and bandwidth resource management over PCE. > > Then introduce 6TiSCH, followed by how RPL is an enabler for route > > installation. > > > > The term "Root" in the Introduction attains special meaning. Is the > > capitalization required here ? > > Great suggestion, I'll work on it. > > > > > 3.1 > > --- > > > > "The Track Ingress is signaled in the DODAGID field of the Projected > > DAO Base Object; that field is elided in the case of the main RPL > > Instance." > > > > Shouldn't it be "global RPL Instance" ? > > It's still the main, and it's true that the main is a global in the use cases I have in mind. > Basically the Tracks are built within a larger DODAG that encompasses the nodes in the Tracks and allows to configure them. > > > > > > 6.1 New P-DAO Request Control Message > > ------------------------------------- > > > > Is there a timeout for getting PDR-ACK message ? If so, what is the > > value of the re-transmission interval ? > > There must be but the value can be very different with use cases; same as RPL we avoid giving values here. > > > > > > > One would have assumed to see QoS specification as part of the PDR sent > > out by Track Ingress node to establish Track. The Root will then come > > up with an appropriate route and bandwidth allocation that meets the > > required QoS. > > Yes. We probably need to define a QoS level for the whole signaling. > > > > > > After the Track is setup, what if Track Ingress wants to request for > > additional or less network resources as per the application > > requirements ? Does it mean tear down the existing Track and sending > > new PDR all over ? Is there a way of requesting for additional > > resources ? > > Again RAW territory. There is no concept of distributing the load so we can add / remove resources and do load balancing as well as PAREO. There is no text on policies at all, whether that describes using network coding etc... I agree with the need, and would think that this belongs to RAW. Here we set up the routes but not the ingress policies. > > At the moment every packet for which the Track is the route is injected in the Track and flooded. RAW can add: > - a subTrack selected by the PSE within the Track (already in the archi) > - load balancing and network coding so as to use more bandwidth in parallel (can add text in the archi) > > > For ROLL: if the RAW policies can do load balancing, I agree that the PDR / PDR ack should indicate the required resources and the requested changes. Same point as before, it might makes sense to make all the metrics and sizing a separate draft (the RFC 6551 of the day), to reduce the complexity / load on this one. > > > > > > > 6.3 Via Information Options > > --------------------------- > > > > I suppose we can assume that these options are part of PDR-ACK Control > > Message. > > The idea was that the PDR ACK to the Track Ingress indicates the trackID, and that a non-storing P-DAO to the Track Ingress for that Track ID has the SR-VIOs. Are you suggesting a change? > > > > > 7.1 > > ---- > > > > Expand GUA and ULA in their first occurrence. > > Will do > > > > > 8. Profiles > > ------------ > > > > OLD: "This sections described profiles that can be implemented > > separately and can be used to discriminate what an implementation can > > and cannot do." > > > > NEW: "This section describes profiles..." > > > > OK > > I'll be editing once we agree on the details like the 2 drafts that your discussion seems to siuggest. > > Take care, Anand. > > Pascal > > > _______________________________________________ > > 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 Tue Aug 24 07:14:01 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 E17393A0E8E for ; Tue, 24 Aug 2021 07:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=kCYX+5WY; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=wN5I2VJn 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 eJXxQlln23R6 for ; Tue, 24 Aug 2021 07:13:53 -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 7F68D3A0E90 for ; Tue, 24 Aug 2021 07:13:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1630; q=dns/txt; s=iport; t=1629814433; x=1631024033; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=hd3WNNpJ9UTj8qHFD41hdoS0eK/GVQxv8308VMIgt04=; b=kCYX+5WYjcwnZwWfc+2UFko3SK9OU77cb2aH8jscZQTygke8lnTWmbKe PAK40Tv2JHYzFuibhz/VyHDejE7XIUumuKtpy6yNOzsw1O1kj0QmlbALq +aJ7EkbIgQwAFDwoZbTR47S2Acg1CRaQ8wLQ9zeZg4QWhYoXcWhz/4TvM Q=; X-IPAS-Result: =?us-ascii?q?A0DHDQAj/iRh/4QNJK1agQmBWYFTKSgHd1o3MYRHg0gDh?= =?us-ascii?q?TmIBQOaRYJTA1QLAQEBDQEBKgsMBAEBgXWCdQIXghQCJTcGDgECBAEBAQEDA?= =?us-ascii?q?gMBAQEBAQEDAQEFAQEBAgEGBIERE4VoDYZCAQEBAQIBAQEQBgsRDAEBLAwEC?= =?us-ascii?q?wIBCBgCAiYCAgIlCxUQAgQTIoJPAYJVAw4hAQ6cagGBOgKKH3qBMYEBggcBA?= =?us-ascii?q?QYEBIJRgjkYgjQJgRAqgn6EEIZoJxyBSUSBFScMEII2MD5rGQF/XgEBAoFeg?= =?us-ascii?q?xc2gi6GeBAgAVsLC4FJlT2oPgqDKp5ZBSeDZYtkly9DhjSvPByEZwIEAgQFA?= =?us-ascii?q?g4BAQaBdyWBWXAVOyoBgj4JRxkPjjeBDwEIgW9UhRSFSnMCNgIGAQoBAQMJj?= =?us-ascii?q?x4BAQ?= IronPort-PHdr: A9a23:q0vSOhUdyKf4NIU5pniYcRgAQ/HV8K3mAWYlg6HPw5pPf7ituZP4M x+X6fZsiQrPWoPWo7JBhvHNuq/tEWoH/d6asX8EfZANMn1NicgfkwE6RsLQD0r9Ia3rYjA0W sNYWwwt83SyK0MAHsH4ahXbqWGz6jhHHBL5OEJ1K+35F5SUgd6w0rW5+obYZENDgz/uCY4= IronPort-HdrOrdr: A9a23:lVpgbqD4kUU6gT7lHegNsceALOsnbusQ8zAXPh9KKCC9I/b3qy nxppsmPEfP+UossQIb6K+90c67MDLhHP9OkMcs1NKZPDUO11HYVL2KgbGSpgEIXheOi9K1tp 0QM5SWaueAdmSS5PySiGLTfrpQo6jkzEnrv5al854Hd3AMV0gU1XYBNu/tKDwReOApP+tcKL Osou584xawc3Ueacq2QlMfWfLYmtHNnJX6JTYbGh8O8mC1/HCVwY+/NyLd8gYVUjtJz7tn23 PCiRbF6qKqtOz+4gPA1lXU849dlLLau5l+7Y23+40owwfX+0GVjbdaKvu/VfcO0biSAWMR4Z 3xStEbTpxOAj3qDzqISFDWqnfdOX4Vmg7fIBmj8CHeSQiTfkNnNyKH7rgpLycxonBQzO1Uwe ZF2XmUuIFQCg6FlCPh58LQXxUvjUasp2E++NRjxUC3fLFuIIO5l7Zvt3+90a1waB7S+cQiCq 1jHcvc7PFZfReTaG3YpHBmxJipUm4oFhmLT0AesojNugIm0ExR3g8d3ogSj30A/JUyR91N4P nFKL1hkPVLQtUNZaxwCe8dSY+8C3DLQxjLLGWOSG6XWZ0vKjbIsdr68b817OaldNgBy4Yzgo 3IVBdCuWs7ayvVeISzNV1wg2bwqUCGLHvQI+1llupEU4zHNc3W2He4OSMTeuOb0oAiPvE= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.84,347,1620691200"; d="scan'208";a="754762997" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Aug 2021 14:13:50 +0000 Received: from mail.cisco.com (xbe-rcd-002.cisco.com [173.37.102.17]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 17OEDoou031628 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for ; Tue, 24 Aug 2021 14:13:50 GMT Received: from xfe-rcd-003.cisco.com (173.37.227.251) by xbe-rcd-002.cisco.com (173.37.102.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 24 Aug 2021 09:13:49 -0500 Received: from xfe-aln-001.cisco.com (173.37.135.121) by xfe-rcd-003.cisco.com (173.37.227.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 24 Aug 2021 09:13:49 -0500 Received: from NAM12-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.15 via Frontend Transport; Tue, 24 Aug 2021 09:13:49 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jl9eor/aAYHQThEieP70CXY6sw+94HUs5bs80K4b29nT2AQZDVxM7xKM9bD04iy6crQRzpl54ywTcn0d4GG4fiZj7s1FTw2fDRrULSnO65dVyJKnsjZkmVP70mNzSIwhWnI2l6K5LJH/LD8ADOuzDf7HmZljWZ+b2UDsGtQIYIFF9emC166/5LPp+m11N8M8w4SympYSFmrCIqEae+BTHITafs8EEsTsp6fUAMQiH1toJT+YplsSUzGA8xrgglx5WLOvoHyh40RZLDPqpEDMZB3dodm0aruRyeRHZH/bEtUjiYbMIgLjMi5WdQkMm8DF20zSgvP5kwttOJbdip2abQ== 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=hd3WNNpJ9UTj8qHFD41hdoS0eK/GVQxv8308VMIgt04=; b=WTGslUwttYpP1uoMO7rU5koQFMyJHhWlimhue8TJHXKJowTjvafuwDZgqXgX/A1PUa6detqzrzFAaK+W5YdYWPLX8ZuPvuTCDH2Rs4K6uR00g1CV5Yck2xLW9WRCYcl/Ws/+6tX3IFmjZQZOP+BycE2m8hGJdA/ZWNZr5qnnqoMnWAhpZZyzxB09NZk/Old+FXi7V6eKssx2KheuEmdz6hZQTiO6fDaNVgEsVde/+QAT/8B+yZeS52Sj4B7WphvXVi2yf7POL5oJU35aomTj44akoRKdAsns+rvnOVWeew2qRZPYQ1Cj7T4L7lJ5Gh9YMuRpSz6MbZr0E1vSNpy0bw== 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=hd3WNNpJ9UTj8qHFD41hdoS0eK/GVQxv8308VMIgt04=; b=wN5I2VJnTbD9pG9T82ET/3jE4eWDvuq9wfLaEZElHBGanawQ/H3W+I/CZcIYunYz+0SFPmugtKFesoWdiyJ46JP3Lbk5Ob+VEY1kbnmKEiagBWjaSWsEKo2TX9+bRTik6zRHDDsB7HnyvQTti3NMqwj3BTiYJ9UiNODrglZ6QWA= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by CO1PR11MB4932.namprd11.prod.outlook.com (2603:10b6:303:98::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.25; Tue, 24 Aug 2021 14:13:48 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::1526:a53e:e787:6b8]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::1526:a53e:e787:6b8%7]) with mapi id 15.20.4436.025; Tue, 24 Aug 2021 14:13:48 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Roll at IETF 112 - Request to fill a survey Thread-Index: AQHXldtnY93CAazEk0Os0B4HdBvrP6t9IKwAgAWYILs= Date: Tue, 24 Aug 2021 14:13:48 +0000 Message-ID: <91CD5858-87D7-4C1E-8708-3B4C325F3042@cisco.com> References: <17073.1629506882@localhost> In-Reply-To: <17073.1629506882@localhost> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6c143200-5ada-4d82-0383-08d967096468 x-ms-traffictypediagnostic: CO1PR11MB4932: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 4daP6ZoupX33H+5DuozJOOBWdytk3kv/guiaZq2MlwR4wIz5EdwwxXJnOHV9z238oWByizgMPwQPgRcl6rkHJISObNL1syly0+MM0GFIiO+sHl1qQRsNwceZgFPE6BEFbpxn8o7A9IS9AWa5vo1Bi0jxz4odSKIoJCQk/8yxKW7nz9RcXq+/W/cekDoCwYVBPTI2HSDNRFGTnzJ+H6NxhDmDosDhkOTk+JRW7jeICNVns5Kfs6MlawwAuPCujF/32PvPtB9pxNhNYFIvFQLPwkr2CWDpT/GDWUQYxyVF/FJAzQ9u5FOKpGyhZ8nQSTnYMJhcsz0PVGjUso9Celo8M/Xog56wdruuA1Jtmwlb/XRSkh67qv2oH3RpJC9V8qRhsC7uquu6Wtti9QoEFFth+rCO6pdLEg8X/yUSSgdBpkg/6n9Cv+V2c44mkgu8xvjvj6o97S3O8k2YGdRkDrz1DfCvX7omu/Gi+NTsjLfE19P8eNju4BUdeGNNGL4sN8QqWdoqaDSyWAbn2k7XnVTQTiMTE+D3UL+SK5on2hk42XV9A8gOK3sJ7WwscBMG1qFjqdmjFTOVGRL4QlyjMl8LOxXtDqb2OPCmBX0PXfONxTVneTHKjOZ0sbZbraqja2WMvP+bZLIqvs2EfgAFEDe7zGEMArqEge+zLfpBeA3lcisMxE1oIxMmPJ44VsAqKYegCl8/TEYo2zxAC1No1Sh0V9YQEES47Iek1NFL5aDMUPHARsBktKLYFUPtz/WREZrMrsdvSVpmCwOgTmXhK5oJknk4gWAqv37BIru6cFZF0V881AsaoBYLTWyXGmlHf6Yr5aSqRWlrdgJt63ZfBYmduw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB4881.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(39860400002)(346002)(396003)(366004)(376002)(66476007)(66556008)(64756008)(66446008)(86362001)(8676002)(66946007)(2616005)(66574015)(83380400001)(76116006)(6506007)(91956017)(38070700005)(6486002)(6916009)(5660300002)(316002)(33656002)(122000001)(36756003)(966005)(478600001)(38100700002)(71200400001)(2906002)(186003)(6512007)(8936002)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?dW9xY2REMGlsbUxUNUdxZVQxRlp1MFBXb2tYQVRSR2g2MmJBOW5TKzIxQmho?= =?utf-8?B?cjJQdGgydkRyRzdFb0Zvd0lrZHRqWTZMNGpwQ1lJcUN3VEU2ZUxybzBkQW1y?= =?utf-8?B?ZjF5cXZNS0dPSno2S3ZCa1BLSE14OXVnekNReEZpVFRwRWFKNjBSK3VSMDFz?= =?utf-8?B?eWU0d21FOFkrS25MOHJPd3NPUlpzZUcxOXlaTmFabXYyUnltTCtiVDNtTUxN?= =?utf-8?B?ekZjNFh3Vk03ZndKNmluNG5BdkRnL01nZkJ0cUpJN1kvanZMa2tQenorVDVB?= =?utf-8?B?V0NZOUJsaW14a25DVVlyQ3BkWHNaT1c2NjFLSVd3TVZ0czdMUy9BdEVxRVdv?= =?utf-8?B?SGFpenNERHp0c1BkUWJoNUFSL25MWXF5c1ViOGJsdFQwQlpCakhWelM3Wkh3?= =?utf-8?B?V3ZWZHVrdWI5Y1Nrem41VVNIbk1CYU9WUVZyK0tmd1RUSDVtZnVlb2M0TUJ4?= =?utf-8?B?ZFRKZm5JRGJ2bUo4WVl6ODE0cE9WZlJEcW1jakltVDZmd3lkTmcwN0N0aFRm?= =?utf-8?B?cUFLZHkwbmtjbDhUKzVwd2c5b05zQzFweFA0cXZHWEQraVliZUxZQTZMb05I?= =?utf-8?B?YnpoVHJ4MHh0RUxqZ3Z4dWM2OU44UWVQVzVTa25tK2VpbTNkaVFMblNYKzdY?= =?utf-8?B?UHZlc0RkR05DTTBuT2xMSDkzNWtPSDZkS3JoT3NtV1BYaTRxbS95NXZzRERx?= =?utf-8?B?SVkzdHhwMm5CNlg5LzlOaGpldTRqSVpvSkxJd0R6aDBLQXBPZjQ1Rm9BdW9H?= =?utf-8?B?MHV6RDMyY0lRVjM1UWhPaGhXdC9iOW5xeUdyNHhoWDFiQmp0ZnUyNjllRnFt?= =?utf-8?B?LzZmV3QxWmFYQlpLMS91ZHQrN3Q0NjZoRXZrY3FUODE3M1dHdC9yakswVnJj?= =?utf-8?B?YXJRdVNjUEc1NzhqMFE2dVZLc3MwOGlOMEhmSkY0QWZVYWw5R3hZLzR1UHZn?= =?utf-8?B?ckpBVE5td3FUUGtFQnVabUJYL21KVEhKVHZxZXA5WTMwb2RrTFlOdzhPRllP?= =?utf-8?B?SHF6QjlucE1jOVdvaDJVTGpMcnd6UHV5WG5xazFxcnluQ3hsN1FidTBwbHZQ?= =?utf-8?B?Wm1Id3pmWWJFc2FmSGx6UGRUSnlUVjg4WUhrdnhoVTR4bnUydXhtbWFpMTFR?= =?utf-8?B?UzExYkIwWmZvRlVLL1Rzb2NRbWh6OVovNjd5Q1VPbFZ1U3BWemlWdVEvWVE3?= =?utf-8?B?RlJaOVUreVk1Z0dlYXBjdU9FRXJHQ0NlckVRcW5hd09XUEl6aUJ4RmNOOXI2?= =?utf-8?B?Rld6clBTSUo3blMvYi8wdU1qaXZJclRRbnp6YTJlVUhiUTVmaytNckRXbWZM?= =?utf-8?B?OC9IOXhHWTZ6WHdNWjZXdy9FTmNaU0xlcnQzSnRCN1hjdG5hbXNmNmFSeGNU?= =?utf-8?B?czFTMitBeHN6bzYzOXdUZnVjV1FQOUFDMXhqdkpFdVV6NzlVbEZza0R1UWtv?= =?utf-8?B?QkU3eW01ekl0Q04vWXozZGcvWXczR2laTEdkcE5sc1BZcnJCTERHUXN1TGFa?= =?utf-8?B?cGNId1RNQytLQWcveUZMcUZxRDBubTZPTllET2s4WWoxbU9tTGd4RGNUenA5?= =?utf-8?B?ZXBuL2J6Y3A3dEN4UDJGZi9aWHROUEdPVGlMNFNzUDIyQUFBSUdDeFJ0SVhC?= =?utf-8?B?SUFDY2FCejI5N0FXelRqRXBSYjVaTHNRUFFnbExRU1UrZDJPVFJYbEcrNklT?= =?utf-8?B?U2RvWHVSblF5QTFMU3BhMDIrejB6TjZQUGZZa2t5eWZwbW9ybGpaZnh0bXQ3?= =?utf-8?B?bWlDK1orZHhzcWNHTkwrR2NRR1ptTVgvRTlLWXFFK0hBeTIyeG1VeFdCYzg1?= =?utf-8?B?ZUVGUEhTSmJHQzlNRDNjWXlGOTZVbkMrM1k1OVAwbXM3OXVuNGFJM0pRbGh5?= =?utf-8?Q?lKUN77smqHyEg?= 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: 6c143200-5ada-4d82-0383-08d967096468 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2021 14:13:48.4469 (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: q4fs7ZNxv/Ak330Mw0Q58q1HWWC+TY2jkXT9jyBCk1UHv8FlUpA7v5tE9uNJ4nSTK9SjTW2gyNugHvzDnR1NHA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB4932 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.17, xbe-rcd-002.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [Roll] Roll at IETF 112 - 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: Tue, 24 Aug 2021 14:14:00 -0000 QWdyZWVkIHdpdGggTWljaGFlbCANCg0KV2UgaGF2ZSB0byBwcm9ncmVzcyBlbnJvbGxtZW50IGFu ZCBEQU8gcHJvamVjdGlvbiBhbmQgYSBxdWljayBzZXJpZXMgb2YgaW50ZXJpbSB3aWxsIGhlbHAg dXMgYmV0dGVy4oCmDQoNCg0KUmVnYXJkcywNCg0KUGFzY2FsDQoNCj4gTGUgMjEgYW/Du3QgMjAy MSDDoCAwMjo0OCwgTWljaGFlbCBSaWNoYXJkc29uIDxtY3JAc2FuZGVsbWFuLmNhPiBhIMOpY3Jp dCA6DQo+IA0KPiDvu79JbmVzIFJvYmxlcyA8bWFyaWFpbmVzcm9ibGVzPTQwZ29vZ2xlbWFpbC5j b21AZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KPj4gSW4gb3JkZXIgdG8gaGVscCB1cyBhc3Nlc3Mg dGhlIG5lZWQgZm9yIGEgUk9MTCBzZXNzaW9uIGF0IHRoZSBJRVRGIDExMg0KPj4gbWVldGluZywg d291bGQgeW91IHBsZWFzZSBmaWxsIHRoZSBmb2xsb3dpbmcgZm9ybSAqYnkgMTV0aCBTZXB0ZW1i ZXIuKg0KPiANCj4+IGh0dHBzOi8vd3d3LnN1cnZleW1vbmtleS5jb20vci9HRFRKR0pUIChlc3Rp bWF0ZWQgdGltZSB0byBmaWxsIGl0OiAyDQo+PiBtaW51dGVzKQ0KPiANCj4gSSBkb24ndCBmZWVs IHN0cm9uZ2x5IGFib3V0IGhhdmluZyBhIG1lZXRpbmcgYXQgSUVURjExMi4NCj4gSWYgaXQgd2Vy ZSBpbi1wZXJzb24sIHRoZW4gSSB3b3VsZCB0aGluayBpdCB2ZXJ5IGltcG9ydGFudC4NCj4gSSBw cmVmZXIgdGhlIElFVEYxMTIgc2NoZWR1bGUgYmUgbGVzcyBwYWNrZWQuDQo+IA0KPiBJIHdvdWxk IGxpa2UgdG8gaGF2ZSBhIHNlcmllcyBvZiB2aXJ0dWFsIGludGVyaW0gbWVldGluZ3MuDQo+IA0K PiAtLQ0KPiBdICAgICAgICAgICAgICAgTmV2ZXIgdGVsbCBtZSB0aGUgb2RkcyEgICAgICAgICAg ICAgICAgIHwgaXB2NiBtZXNoIG5ldHdvcmtzIFsNCj4gXSAgIE1pY2hhZWwgUmljaGFyZHNvbiwg U2FuZGVsbWFuIFNvZnR3YXJlIFdvcmtzICAgICAgICB8ICAgIElvVCBhcmNoaXRlY3QgICBbDQo+ IF0gICAgIG1jckBzYW5kZWxtYW4uY2EgIGh0dHA6Ly93d3cuc2FuZGVsbWFuLmNhLyAgICAgICAg fCAgIHJ1Ynkgb24gcmFpbHMgICAgWw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gUm9sbCBtYWlsaW5nIGxpc3QNCj4gUm9sbEBpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCg== From nobody Tue Aug 24 10:51:04 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 BFE383A0909 for ; Tue, 24 Aug 2021 10:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, 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 JqYSV1SWeW6r for ; Tue, 24 Aug 2021 10:50:56 -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 EA53C3A0908 for ; Tue, 24 Aug 2021 10:50:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id EA63A38A6E for ; Tue, 24 Aug 2021 13:56:20 -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 Bm-9vYOyd80A for ; Tue, 24 Aug 2021 13:56:13 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 0B2BC38A6C for ; Tue, 24 Aug 2021 13:56:13 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A861B16E for ; Tue, 24 Aug 2021 13:50:43 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: <20210822051345.GA3910@iisc.ac.in> References: <20210822051345.GA3910@iisc.ac.in> 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] Review of draft-ietf-roll-dao-projection 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, 24 Aug 2021 17:51:03 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable S.V.R.Anand wrote: > Thanks a lot to the authors for writing up this important draft towar= ds > building a deterministic network and thereby aligning ourselves to RAW > architecture. I thoroughly enjoyed reading the draft :) ... > For an effective operation of P-DAO route projection, one of the keys > requirements is the presence of network monitoring mechanisms for LLN= s in place > for letting PCE have a complete view of the network state. I am not s= ure if we > can assume that such OAM mechanisms are already in place for LLNs as = the track > setup and its maintenance are closely dependent on these. I think that this is a good point. We do need that telemetry. At the stupidest side of things, the root can assume a group of identical 6= LN (same resources), and given an initial non-storing mode, knows most of enti= re topology, and knows that the FIB is empty. I think that any PCE needs to communicate with the RPL ROOT to translate, as Pascal suggested. That protocol is probably missing. Maybe we can adapt P-DAO into a proxy version, and we should probably think about that now. The telemetry protocol is, I think, tied up/related to capex. Is it the same reply process, or a protocol that capex discovers, I'm not sure. I know that the telemetry has been done by a view vendors in proprietary fashion, and going back 10 years, we talked about SNMP for that too. > I list down few questions that came to mind after reading the draft. > - Does the draft allow for the co-existence of centrally orchestrated > tracks and distributed RPL operate within the same network ? Since > draft does not say explicitly, is it reasonable to expect that both c= an > be present together ? If the answer is yes, then the draft > needs to mention the effect of PCE on RPL managed routes, if PCE > controls network resources for the entire network. I think that yes, but only via the PCE talking to the DODAG root. > - Curious question closely related to the above. If one decides to us= e PCE in > conjunction with P-DAO to centrally manage the entire network and the= reby > aligning ourselves close to RAW architecture (Refer to Profile 3 and > above of Section 8), and not use distributed routing at all, > full-blown RPL seems to offer minimal benefits here. Why not use the = compute > and memory for the purpose of implementing RAW mechanisms ? There is a bootstrap of the connectivity. There is also an onboarding challenge. There is a recovery from failure issue. But, if you can keep the "SDN"^WPCE controller path alive without RPL, then please... write a draft :-) > - There could be non-negligible indeterministic delays in setting up = on-demand tracks > before the data starts flowing. Can the draft touch upon the possible= ways to > minimize these delays ? Should we have dedicated tracks for signaling= purposes ? Perhaps the biggest issue here is not that the delay could be indeterminate, but rather that I'm not sure we have a positive confirmation that it has be= en done. > - 6TiSCH has been mentioned just in the introduction. It would be nic= e to associate > it with the P-DAO track installation process. A 6TiSCH track needs to= be > setup depending on the application bandwidth and delay requirements b= efore > sending P-DAO message. In some sense there is a dependency of one on > the other. Can we use the P-DAO message being forwarded as indication to kick creation of the track? > - Can the scope of the draft be extend to mobile scenarios, for insta= nce, networked > robotics applications ? These present additional challenges in the fo= rm of > frequent topological changes causing flurry of network state, and tra= ck updates. > A short note on the issues that need to be addressed to support mobil= ity could > be useful. I think that RPL has a challenge with this kind of mobile situation. > - There could be situations where the Root can decide to modify the a= lready > installed routes asynchronously to maintain the Objective Function/Qo= S of the tracks. > What is the consequence of this action on the ongoing data that is al= ready in > transit ? Two things can happen: it gets there (possibly via the Root), or it finds a loop, and causes repair. =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+93Q3WUFAmElMXMACgkQgItw+93Q 3WVadAf/VmgaA9fPbo11teTsJpoE0Fj9TyJ2nrTY6IwaSEZnuuX9WEhW56JI6bdk XgljbJW0KKNDgqAZ6FMshXrY4fDWkOmM/oltTJrj3qVDEgRl3mDPL7Q2ryUB7QjF AKLHC+mtYAqCc5M+/0/aPkvcmO4DUWWeZ84oR8YpHb3tL/UlQPRNU3txHU4j2Wum aCifp9PlVb/StnXsONqv5ysJFdUwrWk1+AXzAeCzxJaGr9DbhZo6/+vRJ5/84+0N 4kumUJZJ8jUWrR6VooWTZJcEGmLKinZWhw4aFhR3JSEsNIoGLD/8s+xlwl46aA89 vtOPpwIlmu7/v47jqzns9wLsVW7mww== =YW5m -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 25 09:05: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 7CC7A3A0D71 for ; Wed, 25 Aug 2021 09:05:45 -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 ERBxyLu9-ywg for ; Wed, 25 Aug 2021 09:05:35 -0700 (PDT) Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (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 BD3CF3A0D6B for ; Wed, 25 Aug 2021 09:05:35 -0700 (PDT) Received: by mail-vs1-xe29.google.com with SMTP id b30so5471892vsj.3 for ; Wed, 25 Aug 2021 09:05:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+Z2HQkbY9hjsqiUW0DEXACEF5eZcJndZ1PyVvCu5pAE=; b=GhLsk5+V4MItAPM/1iX6v3+3NLcD/MiWp8xcP9BEH70Ziiy0veEo7HGbn5VQLitR0T WGk5os4s0DPV6I+LXP4gQrXqlyLeZ27rmNaB9dFOM+bzma8Lq3RUEYsCnrZKcJpoHVw2 KwTYfSqjxyHSDms3NuEHUYAOdR5FVANae9BAfdSThlyA07CiXyB8TUqsOjTCg/DzATeo QbhClImf9G8qE4VSyy/ttylqRCzhQoUxwkORWf2iSqzepgZrWxIyfWPYKvz4ZAJnLg6z +waN+Bz6US1619RgHntTlulcyX17AlayJQuy98LYj6u3hQg7NY1SLesOgcIKY00YCVnz mRJg== 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:cc; bh=+Z2HQkbY9hjsqiUW0DEXACEF5eZcJndZ1PyVvCu5pAE=; b=oPaFNsMHoz/eKfT6vbIOveqOAajr7jt13dwzdqJF82X9L7JnD3lHre5V3Ul0J+kP1B wXyH73yoJJdoCZPRd/B5AiY1t5pU+bHJ8etA0O03tkVL7lE/2WcWvHk0w+bZEanxbGS5 jKdfb36l6y+eHUVyMdcXdOa+mGMf84AqEICcUB0G77GX7jZtOGIqQkaGlbdBm+fjVKGr 8dOG9WwWCCP0pr/UKM5KPoR5jrtQKxLfB9ith4eIDqlMkVoIrI0hpbNYQgdkoz+xLZ+b M9XrRggubSKIVi0z81hwb+I3ki1dShaBqFvhyriJ5kZi5zEl4FcGltXVsoiNpviUrbnp 2gYw== X-Gm-Message-State: AOAM530MddA5+bK0lkI7tYtQ0iEVCNeIttcqyTdRVx6xmJPab5S9UU9m aKQ8MhwNLbaq9mwhsXwgXe2XJKxaODlYzMKxccc3PGER5zk= X-Google-Smtp-Source: ABdhPJyVhqnGgcyO21qT/S3RU7ivBT16GK9yHWvDVnxRNF76EsZbwdvugw0wbxNuQHkZnoSn9+WvtWrCTidLKJtWdfg= X-Received: by 2002:a67:df85:: with SMTP id x5mr33899666vsk.3.1629907533680; Wed, 25 Aug 2021 09:05:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ines Robles Date: Wed, 25 Aug 2021 19:04:57 +0300 Message-ID: To: roll Content-Type: multipart/alternative; boundary="0000000000008fd5fa05ca646bac" Archived-At: Subject: Re: [Roll] ROLL Interim Meeting - 31th August - Agenda and meeting details 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, 25 Aug 2021 16:05:46 -0000 --0000000000008fd5fa05ca646bac Content-Type: text/plain; charset="UTF-8" Dear all, This is a kind reminder of the meeting next week. Dear presenter, if you haven't yet done so, please send us the slides or upload them into the data tracker. Thank you and Best regards, Ines and Dominique On Tue, Aug 10, 2021 at 9:50 PM Ines Robles wrote: > Dear all, > > Please find below the agenda for the interim meeting > > > https://datatracker.ietf.org/meeting/interim-2021-roll-02/materials/agenda-interim-2021-roll-02-roll-01-01.txt > > Presenters, please *by 25th August, *send us the slides in pdf, or > alternatively you can upload them in here : > https://datatracker.ietf.org/meeting/interim-2021-roll-02/session/roll. > > Link to the CodiMD: > https://codimd.ietf.org/notes-ietf-interim-2021-roll-02-roll > > Link to Webex : > https://ietf.webex.com/ietf/j.php?MTID=m0f82035057cfa91a3d4a625639f73c02 > > Note that you can find the provided information (CodiMD, Webex Link, > Jabber, icalendar) also in the top right corner of the meeting page [ > https://datatracker.ietf.org/meeting/interim-2021-roll-02/session/roll] > > Comments welcome, > > Thank you and best regards, > > Ines and Dominique. > > On Wed, Jun 30, 2021 at 1:10 PM Ines Robles < > mariainesrobles@googlemail.com> wrote: > >> Dear all, >> >> Thank you very much for filling the doodle. The date selected is 31th >> August at 3pm UTC. >> >> Please let us know if you would like to Present a topic by 30th July >> specifying: >> >> - Topic >> - Duration >> - Presenter. >> >> Further meeting details (webex, codimd, etc.) will be provided later. >> >> Thank you very much in advance, >> >> Ines and Dominique. >> >> >> On Mon, Jun 7, 2021 at 12:57 PM Ines Robles < >> mariainesrobles@googlemail.com> wrote: >> >>> Dear all, >>> >>> We would like to organize an interim meeting. Thus, we kindly request to >>> let us know your availability by filling the following doodle by *12th >>> June. * >>> >>> https://doodle.com/poll/nd3z4wyar6tqudcv?utm_source=poll&utm_medium=link >>> >>> Thank you very much in advance, >>> >>> Ines and Dominique. >>> >> --0000000000008fd5fa05ca646bac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

This is = a kind reminder of the meeting next week.

Dear pre= senter, if you haven't yet done so, please send us the slides=C2=A0or u= pload them into the data tracker.

Thank you and Be= st regards,

Ines and Dominique



On Tue, Aug 10, 2021 at 9:50 PM Ines Robles <mariainesrobles@googlemail.com&= gt; wrote:
Dear all,

Please find b= elow the agenda for the interim meeting


Presenters, please=C2=A0<= b>by 25th August,=C2=A0send us the slides in pdf, or alternatively you = can upload them in here :=C2=A0 https://datatrack= er.ietf.org/meeting/interim-2021-roll-02/session/roll.=C2=A0
=


Note that you can find the provided information (CodiMD, Webex Link, Jabbe= r, icalendar) also in the top right corner of the meeting page [https://datatracker.ietf.org/meeting/interim-2021-roll-02/se= ssion/roll]

Comments welcome,

Thank you and best regards,

Ines and Domi= nique.=C2=A0

On Wed, Jun 30, 2021 at 1:10 PM Ines Robles <mariainesroble= s@googlemail.com> wrote:
Dear all,

Thank you very much for filling the doodle. The date selected is 31= th August at 3pm UTC.=C2=A0

Please let us know if = you would like to Present a topic by 30th July specifying:

- Topic
- Duration
- Presenter.

=
Further meeting details (webex, codimd, etc.) will be provided l= ater.=C2=A0

Thank you very much in advance,

Ines and Dominique.=C2=A0

=
On Mon= , Jun 7, 2021 at 12:57 PM Ines Robles <mariainesrobles@googlemail.com> = wrote:
Dear all,

We would like to organize an inte= rim meeting. Thus, we kindly request to let us know your availability by fi= lling the following doodle by 12th June.=C2=A0

=
=

Thank you very much in advance,

Ines and Dominique.=C2=A0
--0000000000008fd5fa05ca646bac-- From nobody Wed Aug 25 09:41: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 DCD733A131D for ; Wed, 25 Aug 2021 09:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.69 X-Spam-Level: X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=iisc.ac.in 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 kphoFG9RNY6e for ; Wed, 25 Aug 2021 09:41:22 -0700 (PDT) Received: from IND01-BO1-obe.outbound.protection.outlook.com (mail-eopbgr1390079.outbound.protection.outlook.com [40.107.139.79]) (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 F395F3A1333 for ; Wed, 25 Aug 2021 09:41:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QXBR9i04kPLPtEzmNvaJpeHnDPpvmFCIK82nlCfOZM+283SE65dHa3hmTRLStw67A+7Je5QSgvU0r0ktnlb9BMqIiBcYWpcXtEbSfKByQvl1gXJbTraLEFqD5Kek1oi4+6LSVUpfzbE+pHGD61JDAZ7rTHRwxtkdqAWrtlSKRTQaG8WBTlG4LFLvHH0eVYJw9PrPw8tirpDoIbv3qeqck2bGElocKRlEtQ2EQxjs8JIy2h6uLehIiBGjbQLhIhcZVSG3FFfICg5SHd/yjz+UOejJ0mn6BNHAqy3LAbNS0hoCU53mdG3syAH/+NI4xgGknj/XJYzVkbsQB/h/y9PVWg== 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=cb7jNQbwYN/YKKAJppJhx7npzJjuJuSV9WDnR1mOadw=; b=ckpUNCzdT4TLtg+L2xAQesjm4jnwDZKAkt5h7su6Bz5nJtmE4Vh0Yd3H6ZECihJPoCFd2nwn86Som9Gy6ZlJadBmMJ1fMGlGqFo8Bmq4Q7cTbuG+o7AxKmd7/ZyQctuH4el7MW0LmcdoxC9LNuHFccPLiFuavYz0v9B1AE0jC8VI68VEq62cTxo60PRztmAcCpdn7LaIEsyYypzyXuDO8q3XH5zg0tfseN5HA3+64leGhB1zM22h8flYqcEZSHN+rwxKK3bDyj8KFjTOaxsMB7J6JFqJc3beAFc9I1OMrcnVNAh090dSZW6hNDagUFZTsruQX8V2b2hDSrBG4tyhMQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iisc.ac.in; dmarc=pass action=none header.from=iisc.ac.in; dkim=pass header.d=iisc.ac.in; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iisc.ac.in; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cb7jNQbwYN/YKKAJppJhx7npzJjuJuSV9WDnR1mOadw=; b=PVXJTMv+zuajsIJGoJsgjuHkyaYLKt32SZQiroZw1F+SppZ9d8YzBy+r2EbeWUmPkeL9JJ7PVeK1unh8Rz6Dnx0hjaSVARHxspPqWaU3tzCdSCx4qTbQBXCZExKcwhcg60mSGu3CsWMI0nm0Q8ichnDTiOZjxqX4xLju5WAdhLQ= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=iisc.ac.in; Received: from MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:37::23) by MA1PR01MB0634.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:7::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.22; Wed, 25 Aug 2021 16:41:04 +0000 Received: from MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM ([fe80::6096:2bb9:fc3a:cd39]) by MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM ([fe80::6096:2bb9:fc3a:cd39%5]) with mapi id 15.20.4457.019; Wed, 25 Aug 2021 16:41:03 +0000 Date: Wed, 25 Aug 2021 22:11:01 +0530 From: "S.V.R.Anand" To: Routing Over Low power and Lossy networks Message-ID: <20210825164051.GA5889@iisc.ac.in> References: <20210822051345.GA3910@iisc.ac.in> <24891.1629827443@localhost> Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <24891.1629827443@localhost> User-Agent: Mutt/1.5.24 (2015-08-30) X-ClientProxiedBy: MAXPR0101CA0029.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:d::15) To MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:37::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from iisc.ac.in (49.206.10.139) by MAXPR0101CA0029.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:d::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.17 via Frontend Transport; Wed, 25 Aug 2021 16:41:03 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d4571198-bfca-412b-9a8f-08d967e720b9 X-MS-TrafficTypeDiagnostic: MA1PR01MB0634: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: V179ARggCpsxMY8rA6MUkT2mlFL8QaOD+znLbjp9kG61PqYRODgpw4c7BL5pjaaBSvKSY8a/7QOmmkCzwnmWbbUpS3Jon/wZFIkF2JjGSiX4Iz1kt4Sdh8NoqTzpu2XtxWn3q/rU+hkHhszNpzZROYwVtmNxgm6hJM+vZmTXrGz84R2P6Z6/k9o19CocBetoU9HriGk3a616/gp+/1gcrps8mAgwQRjLSOD5EehCptpdAapcrN8MQQiE7RYGDjtf+LAuFG73NvBQp+NkeTFDt/V15vsuQthox3rGXtQ/0LRZABAdd2BwL5FGOK+o2xL1XptmCcbPE+vLAKT8ZsLXyzYUQAKXsE5bhRHq+t2/b84WYHy8nY+WCXim3EZgZFaJFC4n5naGfA0trSO89HnLygshxPJBaq2tyhBM73LJDCm+4hS8W7DOwjJEkJmQSq/vLkFnXQf6/Fk1nj5sXi2z6ePt45+D2uJCV9hYjkTBHTEE9RsSB2B5p3IVP7frNJyikQaHxgpZ5iBIxXvlkU5ExqzdV9hx96CYZW5c2jxuD/8hCZr7D0W87ixW9VOILtJrdEt4DJqaedbGHoyM29ZT43ilJS1sk2mGZn6xeFux4wvC0/IYxaiDjBGpEAwNpW26SOWZxeGt/AUjLAaEtYxSICDQOHAZDyaSQhiODXkff0pTDQpobPfPQ7g8MP2PnBUY6t6QItKAeePX5W9PZGw/Iamh56vAdh4F1ZBcHTjANfdor6pM00+VBf0A1zTMt+m4rjRYm2fkasSDL0Mzm9cYYg== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(396003)(39850400004)(376002)(366004)(136003)(346002)(316002)(786003)(5660300002)(7696005)(66574015)(186003)(6916009)(55236004)(52116002)(966005)(26005)(1006002)(2906002)(33656002)(956004)(8676002)(83380400001)(53546011)(86362001)(66946007)(36756003)(55016002)(66556008)(478600001)(38100700002)(2616005)(8936002)(66476007)(1076003)(38350700002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?iso-8859-1?Q?t3c/cXWlkuntWlFCcv+HnH1HKjehHdznF6+eaeSO9RWVtcI0/Qy4O3XvjF?= =?iso-8859-1?Q?HtkziBKRkl3v2nNJPWz+2vruAfeH/G4QSMa2/+CSLBueNKu1UD7DDx8w/p?= =?iso-8859-1?Q?i6QO5YwP/Dxt/pxKToXD16VoeXTV+26WLCc8FJymTryirDfY5N8cH3x7CV?= =?iso-8859-1?Q?XcHuv9ynm0qZiBYFhfyVnHLmyFPo0AM2rFg2YznsLizcRPJtJCpT5tjqD2?= =?iso-8859-1?Q?nV8+8AzJtSStfYhCrXcCHB8BMGXlah9merYTrQ74lc7+QVg+cXvf+ACKM2?= =?iso-8859-1?Q?Z6WiOCzmKDXG1rT+ycYXaaAz8xOiOiQW0fpStUk6xqs1WVRL827BKojftt?= =?iso-8859-1?Q?8EIRoToie5dDK8DlKAV4XF4OaHbdC/EexWsxsc8WkuRLSgz1Al3wkzTMx3?= =?iso-8859-1?Q?+D8DqXkjcw6NM9KEY6QG5YhQcV4nvpEiXDUbOHc62tEA0bY7d5xZW2O55T?= =?iso-8859-1?Q?2py88QkzeD9RDmcIpk43f0E4JwaNiqwVlcWnrAh/7MtZ4vuqsCTjBz6Kig?= =?iso-8859-1?Q?yf8hrTN72Sq6vbsd1DyQRegazVegillfmze/w2dQmHgTuSuDhjcYTi2GnN?= =?iso-8859-1?Q?rZl1JNGazmbJzLyYmIBvCZXM/MifIPKoZXW2mArAzQsrjybvh0IGlAHeQ+?= =?iso-8859-1?Q?3u+w/dgju4Jr9t2e1RpxCfGmOhtWzVW619+un3RsLkghc5u1MEIclMcDBV?= =?iso-8859-1?Q?4IAZ2v5ncpJheHZsc/b2ge7dTsDorN7OtLU8X6+prLgFi8EpwV32Y5tq2V?= =?iso-8859-1?Q?cLAnTzWwU8i9F7qyB3pBqF25g4kg++oGnBHOj3tlfmJaDLInknt8Vc8zSy?= =?iso-8859-1?Q?ElAr1aMTyXjrHEIbb6zkf9Vuh3nT7fk/zjygbvlEiB2BvqOY8Stemd2dTL?= =?iso-8859-1?Q?HOU352kG6QgqFiJW6Jz2cw8hYoFXGijh/kW2f3Uf69OplWqOJeek8uQFqf?= =?iso-8859-1?Q?Hdf/ggUJH3pnVg3+h+Hi4/GZkoJjDPoweAIpvMrw/C1TQC/ALJEsId/Pi0?= =?iso-8859-1?Q?dXCZXSeKxfBzSvTMGMNHYr15hzMQqozQEU17wlfiJDsTOuUXgJNQrLm4+i?= =?iso-8859-1?Q?ynGikAGyxA7Mab7QHSrxuGQstl0xv2ZgrCQ5VThJm9QVfA6BlRm1m2/kb8?= =?iso-8859-1?Q?saKQzorsZTXYd2Jd+Ioj/fQwgDDTilAQv/Xu4GcnR704Psqg67S9tXRGyO?= =?iso-8859-1?Q?g14hnI2LHdVK0xYG36oCG/w0fDNjfdCupehUL7VVrb0R/NYy4ARLMF86jU?= =?iso-8859-1?Q?xAsMiP67KGU3cO0s1v7BJWYztBPXADscl+RoSf3/n2Awm+svWkhXBTd65Q?= =?iso-8859-1?Q?FvFkoFxQsdRWc1LJjCJGaYMLbLgfKAXxpSwex/PFMDw0nyGRitVI2xou31?= =?iso-8859-1?Q?eYUEBIQhVf?= X-OriginatorOrg: iisc.ac.in X-MS-Exchange-CrossTenant-Network-Message-Id: d4571198-bfca-412b-9a8f-08d967e720b9 X-MS-Exchange-CrossTenant-AuthSource: MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Aug 2021 16:41:03.8783 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 6f15cd97-f6a7-41e3-b2c5-ad4193976476 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: lxt1AxMZEBX2tIvgJqOQjYj4AB636S4sQ2lCPA7IOlQNtK2xD1XMvbADMbUtqHwEju/yTc9hv1fP8ZlncDSANg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MA1PR01MB0634 Archived-At: Subject: Re: [Roll] Review of draft-ietf-roll-dao-projection 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, 25 Aug 2021 16:41:28 -0000 Hello Michael, Very interesting points! Few additional thoughts in-line. Regards Anand On 21-08-24 13:50:43, Michael Richardson wrote: > > > S.V.R.Anand wrote: > > Thanks a lot to the authors for writing up this important draft towards > > building a deterministic network and thereby aligning ourselves to RAW > > architecture. I thoroughly enjoyed reading the draft :) > > ... > > For an effective operation of P-DAO route projection, one of the keys > > requirements is the presence of network monitoring mechanisms for LLNs in place > > for letting PCE have a complete view of the network state. I am not sure if we > > can assume that such OAM mechanisms are already in place for LLNs as the track > > setup and its maintenance are closely dependent on these. > > I think that this is a good point. We do need that telemetry. > At the stupidest side of things, the root can assume a group of identical 6LN > (same resources), and given an initial non-storing mode, knows most of entire > topology, and knows that the FIB is empty. Thanks. I feel telemetry is very essential to manage an operational network, in general. For this draft it is a critical requirement. In our lab we developed an in-band OAM telemetry scheme for LLNs that we named it Co-iOAM. The idea is very simple but it has been very effective in monitoring a real-world deployment of RPL/6LoWPAN network that we setup. ["Co-iOAM: In-situ telemetry metadata transport for resource constrained networks within IETF standards framework", https://ieeexplore.ieee.org/abstract/document/8328276] > > I think that any PCE needs to communicate with the RPL ROOT to translate, as > Pascal suggested. That protocol is probably missing. > Maybe we can adapt P-DAO into a proxy version, and we should probably think > about that now. > > The telemetry protocol is, I think, tied up/related to capex. > Is it the same reply process, or a protocol that capex discovers, I'm not > sure. I know that the telemetry has been done by a view vendors in > proprietary fashion, and going back 10 years, we talked about SNMP for that > too. > > > I list down few questions that came to mind after reading the draft. > > > - Does the draft allow for the co-existence of centrally orchestrated > > tracks and distributed RPL operate within the same network ? Since > > draft does not say explicitly, is it reasonable to expect that both can > > be present together ? If the answer is yes, then the draft > > needs to mention the effect of PCE on RPL managed routes, if PCE > > controls network resources for the entire network. > > I think that yes, but only via the PCE talking to the DODAG root. > > > - Curious question closely related to the above. If one decides to use PCE in > > conjunction with P-DAO to centrally manage the entire network and thereby > > aligning ourselves close to RAW architecture (Refer to Profile 3 and > > above of Section 8), and not use distributed routing at all, > > full-blown RPL seems to offer minimal benefits here. Why not use the compute > > and memory for the purpose of implementing RAW mechanisms ? > > There is a bootstrap of the connectivity. > There is also an onboarding challenge. > There is a recovery from failure issue. But, if you can keep the "SDN"^WPCE > controller path alive without RPL, then please... write a draft :-) I see your point. Apart from the functionality that you listed, perhaps RPL can be used carry telemetry data. PCE-only is still possible, but would prefer to use RPL for the above reasons. > > > - There could be non-negligible indeterministic delays in setting up on-demand tracks > > before the data starts flowing. Can the draft touch upon the possible ways to > > minimize these delays ? Should we have dedicated tracks for signaling purposes ? > > Perhaps the biggest issue here is not that the delay could be indeterminate, > but rather that I'm not sure we have a positive confirmation that it has been > done. While reading the draft I too had the doubt regarding the positive confirmation. But then if Track Ingress Node does not receive PDR-ACK to its PDR, I would assume it would request again. Further, no news from the Ingress node can be interpreted as successful track setup. > > > - 6TiSCH has been mentioned just in the introduction. It would be nice to associate > > it with the P-DAO track installation process. A 6TiSCH track needs to be > > setup depending on the application bandwidth and delay requirements before > > sending P-DAO message. In some sense there is a dependency of one on > > the other. > > Can we use the P-DAO message being forwarded as indication to kick creation > of the track? > > > - Can the scope of the draft be extend to mobile scenarios, for instance, networked > > robotics applications ? These present additional challenges in the form of > > frequent topological changes causing flurry of network state, and track updates. > > A short note on the issues that need to be addressed to support mobility could > > be useful. > > I think that RPL has a challenge with this kind of mobile situation. I too think so. But PCE can come up with few tricks to manage the mobility, independent of RPL. This was not covered in the current draft but I am certain Pascal is ready with few techniques already :) > > > - There could be situations where the Root can decide to modify the already > > installed routes asynchronously to maintain the Objective Function/QoS of the tracks. > > What is the consequence of this action on the ongoing data that is already in > > transit ? > > Two things can happen: it gets there (possibly via the Root), or it finds a > loop, and causes repair. > > -- > 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 Wed Aug 25 10:03: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 AC1D93A0929 for ; Wed, 25 Aug 2021 10:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=F0jpQSHt; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=JD/5JHqL 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 vghVFbHsabxA for ; Wed, 25 Aug 2021 10:03:06 -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 5C71D3A0925 for ; Wed, 25 Aug 2021 10:03:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13215; q=dns/txt; s=iport; t=1629910986; x=1631120586; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Dij0GF5wFAcEv6IVKjVyj/n2vGKt96mHm3Lz9kFxjI8=; b=F0jpQSHtIjyIHn/xJpXoexmRO0UlMy5N8zLlt8Tk0GVCJn9FSe2BwBve dc+xZn2xgeTC+lPNu/AKJg2fM7xCkT+l1dz6A0LuATZqc+B8EYLaJZC4t tXYOE5OZEHRobOrP/uGYOpzRxNi8YFYAu2JHKR5djIIemLAMXeKlq6Cdj o=; X-IPAS-Result: =?us-ascii?q?A0AyAgC2diZhl4wNJK1QCoEJgVmBUyMGKIFYEyQxiA8Dh?= =?us-ascii?q?TmIBgOPeopMgS4UgREDVAsBAQENAQFBBAEBhGoCgiwCJTQJDgECBAEBAQEDA?= =?us-ascii?q?gMBAQEBBQEBBQEBAQIBBgQUAQEBAQEBAQGBCIU7CCUNhkIBAQEBAgESKAYBA?= =?us-ascii?q?TAIDwIBCBIkEDIXDgIEGxqCT4JWAw4hAZ44AYE6AoofeIEzgQGCBwEBBgQEh?= =?us-ascii?q?QoYgjQJgTqCfoJ0U4c0JxyCDYEUAUOCZj6ECwwTHINLgi6FGwkRWx0nJgQDC?= =?us-ascii?q?iUZKi4HBgNALQMGBAQBBh4BBAsgCgkiD5EUBC2rfQqDKp50EoNli2SXMLYcF?= =?us-ascii?q?AQEC4R0AgQCBAUCDgEBBoFhOYFbcBU7gmlQGQ+DN4sCgQ0BBwICA4I9il50O?= =?us-ascii?q?AIGCwEBAwmNHIJHAQE?= IronPort-PHdr: A9a23:K5Z2ExWKD4PdKyQKObciQtN5i4fV8K3mAWYlg6HPw5pPf7ituZP4M x+X6fZsiQrPWoPWo7JBhvHNuq/tEWoH/d6asX8EfZANMn1NicgfkwE6RsLQD0r9Ia3rYjA0W sNYWwwt83SyK0MAHsH4ahXbqWGz6jhHHBL5OEJ1K+35F5SUgd6w0rW5+obYZENDgz/uCY4= IronPort-HdrOrdr: A9a23:iQ+i3ar2W4fGCRfOynFGUcYaV5tzLNV00zEX/kB9WHVpm5Oj9v xGzc506farslkssSkb6K+90dq7MA3hHPlOkMks1NaZLUjbUQ6TTL2KgrGSuwEJlUfFh5VgPM tbAs1D4ZjLfCRHZKXBkUqF+rQbsaO6GcmT7I+0pRoAPGIaCZ2IrT0JdzpzeXcGIzWucKBJba Z0kfA3wQZIF05nCviTNz0gZazuttfLnJXpbVotHBg88jSDijuu9frTDwWY9g12aUIM/Z4StU z+1yDp7KSqtP+2jjXG0XXI0phQkNz9jvNeGc23jNQPIDmEsHfsWG0hYczHgNkGmpDo1L8Yqq iUn/7mBbUq15rlRBDznfIq4Xi67N9h0Q659bbSuwqTnSWwfkNLNyMGv/MFTvMcgHBQ4+2VF8 lwrj6kXtNsfGD9tTW46N7SWx5wkE2o5XIkjO4IlnRaFZATcblLsOUkjQ5o+bo7bWnHAbocYa NT5QDnlYFrWELfa2qcsnhkwdSqUHh2FhCaQlIassjQ1zRNhnh2w0YR2cRaxx47hd0AYogB4/ 6BPrVjlblIQMNTZaVhBP0ZSc/yDmDWWxrDPG+bPFyiHqAaPHDGrYLx/dwOla2XUY1NyIF3lI XKUVteu2J3c0XyCdeW1JkO6RzJSHXVZ0Wk9iif3ekxhlTYfsukDcSuciFaryKQmYRoPiSAYY fABHt/OY6WEVfT X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.84,351,1620691200"; d="scan'208";a="741476916" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Aug 2021 17:03:04 +0000 Received: from mail.cisco.com (xbe-rcd-007.cisco.com [173.37.102.22]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 17PH33VK019608 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for ; Wed, 25 Aug 2021 17:03:03 GMT Received: from xfe-rcd-005.cisco.com (173.37.227.253) by xbe-rcd-007.cisco.com (173.37.102.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Wed, 25 Aug 2021 12:03:03 -0500 Received: from xfe-aln-005.cisco.com (173.37.135.125) by xfe-rcd-005.cisco.com (173.37.227.253) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Wed, 25 Aug 2021 12:03:02 -0500 Received: from NAM04-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-005.cisco.com (173.37.135.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Wed, 25 Aug 2021 12:03:02 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=obu3y+47vJFQvoxWgTt2WeJ+RRQ8/UyaPZc4iFSvsbgm7ZK0Q13/bGd+m+ChmY1F7Dfw9/aufn0HEMQfKusfnrXj6MT9rfFUKh/CEb2XNW1j1rHIFC9st1O8sb3ApoRBuu6ysW5OQTY24Rtdv5neTX4w3FmKq+vo/X2/C6/vnzpppxzAC7JS+acPcp+mH4k35FQeZ+M73LBz8r4134kLpzoQRoNot0MSCc4yhIzad53LcalFjofMdeYmO3ePMhtJEJFPyRw4+iSgB0CdmlSQXnqL5AYxRZWbwtt/7+/QfXHJnXSg6M5AsKv9ATDB06f5W/XC413d94Pk/qo+mWlnLw== 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=fur1KiW7wTzgdLd+bnT+JVBC/WIsU7SDFi2aAN5xEl8=; b=XaB1gLF/rGpJFr++069fugoZY0YCcMx8GVHjqp5gBNNjh29SJUYECtcln2M8BG3MkQL66/IcmvBa2+eCOI3aJynBxEBAJlvYAMurbeUBoJrIpr/9UHUw0yWLGBhI7qDxpctHpYm5AOnu+pv2BNT0IsVWspOa/vYw8ujHWLF5Ky8wedTT2EZHEvxpFMfQqjbIPhiLX0LeJDvJ1wT7/RuklhwEhjKu3uJ+zeZMM2+IJ4DWPYqvXl2e4gDumMB8csgeFO5FXX8zRk2XJx5unO/mad8WX1hUT3khWwWfw74+7/Is7yq23yONt3ntnA/i8vSVgZv0EevvWB8JWnmrcHTAlw== 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=fur1KiW7wTzgdLd+bnT+JVBC/WIsU7SDFi2aAN5xEl8=; b=JD/5JHqLctvXEflq5fSNmE0N8kHzLVcDzmdxD1e3C7ufPd8QGYlws69krJH+H7hm7i720983Iv9fnXcEzfhvrNUi8/X6JIuGGS94l+l/mOYCqDJ2kFETTwx35MVgQdUWCoZt++AcRt4ymiGy3c4rSq29CBX6dp//DsqvVUdAdlE= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MWHPR11MB1277.namprd11.prod.outlook.com (2603:10b6:300:29::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.17; Wed, 25 Aug 2021 17:03:01 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::1526:a53e:e787:6b8]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::1526:a53e:e787:6b8%7]) with mapi id 15.20.4436.027; Wed, 25 Aug 2021 17:03:01 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Review of draft-ietf-roll-dao-projection Thread-Index: AQHXlxSTAPML4x4cU0Sn5jf1yiT0lquBCZ5QgABLeQCAAvMXsA== Date: Wed, 25 Aug 2021 17:02:54 +0000 Deferred-Delivery: Wed, 25 Aug 2021 17:02:20 +0000 Message-ID: References: <20210822051345.GA3910@iisc.ac.in> <20210823170926.GA4577@iisc.ac.in> In-Reply-To: <20210823170926.GA4577@iisc.ac.in> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 548a6cce-1175-4e9f-9ce2-08d967ea3259 x-ms-traffictypediagnostic: MWHPR11MB1277: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: j6PwEKpQgdWAkSfUsETvgAK+s4+n4/8KFaJid/bI914XRbj7vfGfzVMczLoSGn84X9i8OwD9sj70X2LMVHRWc8eZc45uPjyYufZRXrms2myxdNqr+T8IzInDx4M6aGg7OPOn58oLbAr5rdWSiijMOvrfTvS8vy3BdI8seL2bKiCdxb9Bz24/Sb/7RKY9gCp54awqbWVkPbWFnVMD/upoRsudLrk7N2/Xq8jWfW5NZhUr0wuTtL9+jmcCpjbsk+Kf/pEk75k2usshrwSmQtyEgg8fZayxS9hFyfNLBJvLlyTTFMCrZVDRHLq8vO7FdUesFxK/bvX3p8lDYiuCtbAMOfN07AKVa6K6ZxpBx0Sot74INkFFtrR85/YLtH1e7E2kBSiPB4IZ0YwpmtlY13zHRY6QWtgv6xj5k9rD+A1kUX04Uh9xWaRcrQ0OkyxxAtcoaYNbGSSHMl9iBy4CrGkcJCV2HvllLQKsCsg2oWG7ATyZ8rrem06pk86W9yx3K5BqEAZDrWnyxPdFlb38vswUznRgjUsXX6nQ+AOkWURXPwufLzKTp9UMjHXpyYOotpxVIvGTZotkOfRexSSKWMtR94fqhe3GJec0CCLxf3098C7zw9E/hWqDqSTbqcKvUrBU9dsvEi7SrijUW9mdhWbf6kwXZd7p3ysTSjdB0rte484tnTPG6MTbyTE9t0YkPTiAot50sh5tdMhFSXx1aGQSHw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB4881.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(8676002)(83380400001)(2906002)(316002)(6666004)(55016002)(38100700002)(186003)(122000001)(86362001)(76116006)(6506007)(8936002)(66556008)(508600001)(33656002)(6916009)(66446008)(66476007)(7696005)(66946007)(38070700005)(9686003)(30864003)(71200400001)(5660300002)(64756008)(52536014); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?8H5Y3k9N+SyIGVPIthcnCXac9qTboCrpGbB0V5SEXQaTKBW8MxYOXQPHsHmv?= =?us-ascii?Q?A2zIn2kBV7+p87EwY1uDNlzbTe+MJeHY27FnD2q53B8Gh+YyPr9dZ6pZXIUD?= =?us-ascii?Q?cMwkrSXJ4hXxdg4FOeO+gDwTRVazAECRZ+cq2ARc2eM1IFEgAHUkHE9NU5rU?= =?us-ascii?Q?cKxgokJbjQXU7j/BY/AvC2RajeOHuGpTj+iqRAe7FQKrBZbZZhM8Q67bJmZL?= =?us-ascii?Q?R1d3wnK+NWhVIQYSzgPaTuFfy9dP5E6kth50dM7i7i2ZV7fVJ0Ire4UQ7YBy?= =?us-ascii?Q?2cl3lJ6gpyjufnxfRmfk26T8AVgRdXLedauR8jQ7Pzbqg/iMHGTvDaBO5gWu?= =?us-ascii?Q?9fakSvM+tJpawiMtwyIMoNG2AtbWTR093qJk4b14xFpK7BfD2yJ4sHlcdQvV?= =?us-ascii?Q?pH73lGpelT5yNoYm0r7/Nv4fQsnBz0P+nnEou7lOytTWm2gBIPPSj98Qcdu0?= =?us-ascii?Q?7/NUE3q1BCy6kMwi5+NrkUfKal3pH1IUiBiKzw2uFrMNwcJkZ1OENC2HCjub?= =?us-ascii?Q?3WubwxXI86AwyVQX2gibuE9uCejRCaKtd/6dcuZEcnrc0zFqkXRwvchx0IaL?= =?us-ascii?Q?Jd1Hf/1XI7G0FU1erUF8CiW40PDCAzW2RA/nGqxmCwXR8GaRwMg1T3cqnjcJ?= =?us-ascii?Q?Tzx1KxJUCuBHiSwoEOYF+eozacF0SfZ0HSHotVsy7rthnraOcCPn0BJ0wjsP?= =?us-ascii?Q?LuZafDW5ckFajO4SurroXdkgouJEotAbWzr3JnvRkiQTlNygUE9jq9Y1Gbhr?= =?us-ascii?Q?KEGukeML1JRzepS6ZdwGi5sno5Eg2W006SRjm1YnaqwbBnOUipwaM53mGX+Q?= =?us-ascii?Q?1UZGZnhPZkThXb0dhKj8ZLHhoHZ3pg+/eXZ6YR2NTD5nc2vZLDc3bDmbAtcy?= =?us-ascii?Q?++jq0isTU4lHprsYzxgTG66MQ+7rr/O3C4T17bTHh5EvJ7iaS8FTuklKHe0o?= =?us-ascii?Q?8Zs9wPYb6J9PdbhjStiBgQELE23sFT6iB1PokN8t2lh/VMsorq0XpcOUaRzq?= =?us-ascii?Q?BTtkrsVQGDbhf9TkkoCrSttTBVSlVLwYVgBggOW3kDtdE61XyhM558ZjYZ+6?= =?us-ascii?Q?82mke9EJUryzVadYxUXpe/ksvCWbA5R/q0LaZa9fahYSK2XuUDUHYbAGPJJ1?= =?us-ascii?Q?piXsy3MpkXFoKgsM+6vqnCqbbgOVV+o7bR+w5bdNknkSvKiY1/sI6mUupvbD?= =?us-ascii?Q?kPpmMIuWtb7EHsobOcX5QW2kjNk9hvg4r1AIGJqW2zrezulVtLxT5k0xBHGq?= =?us-ascii?Q?5yle1iH3+GsuI6aCtvFlDhtxCkBYe3oMVjC2RSZOwZLYJ95m/3h6Y4TQUrJk?= =?us-ascii?Q?MOeD3sWS7bUSrLAKznynHygwuKiV+ETW1l5loEBac6LhhfoQ2wGwI4TPnqSY?= =?us-ascii?Q?5lZG4mmgfoLa5ZcSCmXPQlLNrSB4?= 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: 548a6cce-1175-4e9f-9ce2-08d967ea3259 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2021 17:03:01.2615 (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: JM+8vtfI9+82XDnhTrupDqWPn1OCQkaXX7DplqbUI1i7KDJpeC+8y9x/Blp0HH6u2+rXPqfCBXbSWmoPxz3jiA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1277 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.22, xbe-rcd-007.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [Roll] Review of draft-ietf-roll-dao-projection 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, 25 Aug 2021 17:03:12 -0000 Hello again Anand I added text in the intro to cover some of our discussion as follows : " There specification considers that there's a unique PCE with full view of the network. Distributing the function for a large network is out of scope. This specification uses the RPL Root as a proxy to the PCE. The PCE may be collocated with the Root, or may reside in an external Controller. In that case, the protocol between the Root and the PCE is out of scope and abstracted by / mapped to RPL inside the DODAG. The algorithm to compute the paths and the protocol used by an external PCE to obtain the topology of the network from the Root are also out of scope. The effectiveness of the route computation by the PCE depends on the quality of the metrics that are reported from the RPL network. Which metrics are used and how they are reported is out of scope, but the expectation is that they are mostly of statistical nature, and provide visibility on link throughput, latency, stability and availability over relatively long periods, more in [RAW-ARCHI]. " Please let me know if you're OK with that text; > > > > > For an effective operation of P-DAO route projection, one of the > > > keys requirements is the presence of network monitoring mechanisms > > > for LLNs in place for letting PCE have a complete view of the > > > network state. I > > > > Very true... > > > > > > > am not sure if we can assume that such OAM mechanisms are already in > > > place for LLNs as the track setup and its maintenance are closely > > > dependent on these. > > > > That too. The combo of this draft and RAW assumes that the PCE gets lon= g > term stats and availability information, and computes routes based on tha= t. > > > > > > The effectiveness of the external route computation > > > by PCE is tightly coupled with network resources required for > > > monitoring the network state, stability of the wireless links and > > > delay in obtaining the network state information, and so on. > > > Strictly speaking, this important functionality is a pre-requisite > > > for implementing the draft. > > > > Yes; the PCE computation can be proprietary since it is inside the box = so > arguably the missing link is the metrics and formats to be reported. Shou= ld > we do that in the same doc (complexity rising) or should we separate a ne= w > draft like RFC 6551 vs 6550? I'm tempted to do the latter. > > > > For now the PCE can live with existing link-related network management > information to compute its routes. > > > > All this is covered by the text above > > > > > > I list down few questions that came to mind after reading the draft. > > > > > > - Does the draft allow for the co-existence of centrally orchestrated > > > tracks and distributed RPL operate within the same network ? Since > > > draft does not say explicitly, is it reasonable to expect that > > > both can > > > be present together ? If the answer is yes, then the draft > > > needs to mention the effect of PCE on RPL managed routes, if PCE > > > controls network resources for the entire network. > > > > Well, the assumption is that the root is really a proxy for the PCE, > turning whatever abstraction the PCE uses into RPL. > > See the intro: > > " This document > > specifies protocol extensions to RPL [RPL] that enable the Root of a > > main DODAG to install centrally-computed routes inside the DODAG on > > behalf of a PCE. > > " > > > > If your question is what if both the Root and an external PCE compute > routes, well that's beyond this work. This would mean syncing and > negotiating the use of constrained resources. >=20 > Yes, as you noted, my question is the latter where both Root and PCE are = in > operation. There will be a continuous churning of the RPL maintained rout= es > whenever PCE re-provisions network resources for its own purposes. It is > hard to maintain the objective functions of the RPL instances. How do we > then resolve this possible situation in the context of current work ? Onc= e > the proposed mechanism allows for the co-existence of centralized and > distributed routing mechanisms, then we need to worry about protecting RP= L > routes. Can the draft say something about it so that implementors are awa= re > of the scope of the work ? For one thing the PCE may run inside or outside the Root device, but there = can be only one, and the new text clarifies that. About the relationship of the 2 types of routes, this is like TE routes in = a SP network, and multi topology routing. We have to ensure that we're not = creating loop, and ultimately provide policies to select traffic that is in= jected in Tracks; in the context of this draft, we're just adding routes th= at have a highest precedence and go all the way to the destination, so we g= et there quickly in non-storing mode, and we know there's no loop in storin= g mode. Remote LFA would avoid that constraint at the expense of higher com= plexity. I added " This specification enables to combine one or more Projected Routes into a DODAG called a Track, that is traversed to reach the Targets. When the main RPL domain is operated in non-storing mode, a Track provides reachability to one or more destinations within the DODAG, which bypasses the Root and improves the latency for the redirected flows. Note that this specification does not provide policies to decide which flows go in which Track. Routes to specific destinations over a Track are always more specific than the default via the Root, and any packet reaching the Track Ingress for a destination that is reachable over the Track will be injected in the Track. " > > > - Curious question closely related to the above. If one decides to > > > use PCE in > > > conjunction with P-DAO to centrally manage the entire network and > > > thereby > > > aligning ourselves close to RAW architecture (Refer to Profile 3 an= d > > > above of Section 8), and not use distributed routing at all, > > > full-blown RPL seems to offer minimal benefits here. Why not use > > > the compute > > > and memory for the purpose of implementing RAW mechanisms ? > > > > I think that's the same point that the Root is really a proxy forwardin= g > in RPL parlance the abstract route decisions by the PCE. This is enables = a > simpler operation with less code in the devices. > > > > > > > > > > - There could be non-negligible indeterministic delays in setting up > > > on-demand tracks > > > before the data starts flowing. Can the draft touch upon the > > > possible ways to > > > minimize these delays ? Should we have dedicated tracks for > > > signaling purposes ? > > > > Oh, interesting. Usually such thing happens with a net priority QoS. > Maintaining dedicated tracks may be fragile, since they would be needed t= o > repair themselves. True that the draft says nothing about that. I agree i= t > should. Any suggestion? > > >=20 > One suggestion is to identify and maintain dedicated reliable signaling > tracks with minimal resources to cater to latency critical tracks that ma= y > be setup in near or far future. These special signaling tracks, as decide= d > by application requirements, can use redundancy so that the tracks are > always available. >=20 I added " This specification extends the DAO message with the Projected DAO (P-DAO); a P-DAO message signals a Projected Route to one or more Targets using the new CMOs presented therein. This provides a RPL- based signaling to build the Tracks as designed in the 6TiSCH Architecture [6TiSCH-ARCHI]. The Track may be set up for many reasons, including as a bypass to lower the load at the Root, or to enable urgent traffic to flow more directly. The signaling should not be stuck behind high traffic levels. The expectation is that the P-DAO message is sent as high QoS level, above that of data traffic, typically the Network Control precedence." I'm not convinced by Tracks to configure Tracks. Quis custodiet ipsos custo= des? This addresses also your comment below: =20 > > > - 6TiSCH has been mentioned just in the introduction. It would be > > > nice to associate > > > it with the P-DAO track installation process. A 6TiSCH track needs > > > to be > > > setup depending on the application bandwidth and delay > > > requirements before > > > sending P-DAO message. In some sense there is a dependency of one > > > on the other. > > > > There is indeed. I can add more words on that too. This can be done > together with your other suggestions below. > > > > > > > > > - Can the scope of the draft be extend to mobile scenarios, for > > > instance, networked > > > robotics applications ? These present additional challenges in the > > > form of > > > frequent topological changes causing flurry of network state, and > > > track updates. > > > A short note on the issues that need to be addressed to support > > > mobility could > > > be useful. > > > > > > I've worked on interesting techniques that could apply. What strikes me > is that you're describing an applicability draft as opposed to modifying > the specification. Could some of your proposals actually become the subje= ct > of yet another draft, this time on applicability of P-DAO? > > >=20 > I agree with your view. Let's keep a note to start that doc asap. >=20 > What about P-DAO for mobility as an independent draft ? There you might > want to describe the techniques you have developed. >=20 > I am not in favor stuffing-in all the interesting opportunities into the > current draft. Can you introduce a "Scope" section where the applicabilit= y > of P-DAO is mentioned ? >=20 > > > > > > > > - There could be situations where the Root can decide to modify the > > > already > > > installed routes asynchronously to maintain the Objective > > > Function/QoS of the tracks. > > > What is the consequence of this action on the ongoing data that is > > > already in > > > transit ? > > > > We're in RAW territory here. I'd say that the PCE/Root only updates > segments at a time so the parallel ways still operate nominally and enabl= e > the continuous service. One the additional path is installed, the Root ca= n > swap the Track (the source routed thingy) to use the new segments. All in > all, with the redundancy that we can expect here, it seems doable to do i= t > live. > > >=20 > Yes, RAW territory indeed. I am strictly going by the abstract of the dra= ft > :) >=20 > Since Root/PCE does not know if the track is currently engaged, route > modification which includes deletion of the routing entry can potentially > result in data loss if we don't do what you suggested above. > I think including some text helps in answering a natural "what if" questi= on > that I got. >=20 >=20 OK, I'm adding a "Maintaining a Track" section as follows: " 7.4. Maintaining a Track Adding or rerouting a Track may affect the traffic that is transported over the Track, e.g., packets can be misordered if the new path is faster than the old. For critical flows that require timely and/or in-order delivery, it might be necessary to deploy the PAREO functions [RAW-ARCHI] over a highly redundant Track. This specification allows to add subTracks to a Track by sending a non-storing mode P-DAO to the ingress associated to the same TrackID, and a new Segment ID. It is also possible to replace a subTrack by sending a non-storing mode P-DAO to the ingress with the same Segment ID as the replaced subTrack and an incremented Segment Sequence. This specification also allows to add Segments to an existing Track by first installing the new Segment(s) with one Storing-Mode P-DAO each associated to the same TrackID, and then joining with a subTrack signaled by a non-storing mode P-DAO to the ingress and also associated to the same TrackID. That subTrack may be an addition to the Track or a replacement, as indicated above. A misbehaving Segment may be modified by injecting a new Storing-Mode P-DAO, with the same SegmentID and an incremented Segment Sequence. The new Segment MUST be installed with the full new path from the Segment Ingress to Egress, both included. When a node that is on both the old and the new Segments this updates the state associated to the path. Once the new segment is installed, the sequences of nodes that are no more in the Segment MUST be removed one contiguous sequence at a time, with the one or more nodes listed in the SF-VIO, and a Segment Lifetime of 0. Nodes along the sequence clean up their state and pass the message to the previous node in the list; the first is the list sends the DAO-ACK back to the Root. " Are we getting there? Keep safe; Pascal From nobody Wed Aug 25 12:01:01 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 196BD3A0B55 for ; Wed, 25 Aug 2021 12:00:51 -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 JPBY_lmiOwPD for ; Wed, 25 Aug 2021 12:00:45 -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 8DF023A0A8C for ; Wed, 25 Aug 2021 12:00:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 2032D38B14 for ; Wed, 25 Aug 2021 15:06:12 -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 x3uJ20EHZ50S for ; Wed, 25 Aug 2021 15:06:05 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 65B0438B10 for ; Wed, 25 Aug 2021 15:06:05 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3731A6A7 for ; Wed, 25 Aug 2021 15:00:32 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: <20210825164051.GA5889@iisc.ac.in> References: <20210822051345.GA3910@iisc.ac.in> <24891.1629827443@localhost> <20210825164051.GA5889@iisc.ac.in> 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] Review of draft-ietf-roll-dao-projection 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, 25 Aug 2021 19:01:00 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable S.V.R.Anand wrote: > In our lab we developed an in-band OAM telemetry scheme for LLNs that= we > named it Co-iOAM. The idea is very simple but it has been very effect= ive > in monitoring a real-world deployment of RPL/6LoWPAN network that we > setup. > ["Co-iOAM: In-situ telemetry metadata transport for resource constrai= ned > networks within IETF standards framework", > https://ieeexplore.ieee.org/abstract/document/8328276] Behind a paywall. Is this suitable for an RFC? =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+93Q3WUFAmEmk08ACgkQgItw+93Q 3WWhOgf/QXGZCWXlDCOp2u1MyURyU0I2lMb/+uU6thGK1fud0H5IAkCRvejVC62/ JaRO8bqoO4IbsGICEiDoBrTwWxHdS9/oSwoxZpCqMRQUpsRdgx5CuiSgizdG4brO 8oOsSbxPaAz13oTP7RhhYOMFJaAeigQ3jwNs4hExJsBF58BivHOV9DHvDkEf1xlM KKF9loeq48tyqt/MwlSWicql29byUaR1cvtk2kkEVnzjNa/ymCmMTtzssrl9lzMM uuCblf3xltBqBCEWlYDIYSADDTlUVj2MCdaxuhXdgmP9hLn8V3zAvNppuj7JEpf2 DxQXKAFx8mwDnKfyG1oUULGjoaCdUA== =t2q2 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 26 09:10:28 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 AE3BD3A082F for ; Thu, 26 Aug 2021 09:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 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, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iisc.ac.in 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 p1FhtIyJLy4y for ; Thu, 26 Aug 2021 09:10:20 -0700 (PDT) Received: from IND01-MA1-obe.outbound.protection.outlook.com (mail-eopbgr1380081.outbound.protection.outlook.com [40.107.138.81]) (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 E605F3A081F for ; Thu, 26 Aug 2021 09:10:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PTBE7LQPXGTglFOu3Pvz1LLCxrQQ8oWA33AbuVcXYaVuqiIga5QH5z6x0qiRHmqY1FZIb6FHi9byVJC2+w4euhtypHquC5hW1jA641BbfEd/jS9+jdwra8Dp6WNTgSsQ5D7TY+Z8ZS5NeQt41UwR6sS8IlfwqLoV9RwHcknhJpn8yIQouYUt65USVl4yBkCZ8WCdzgH+1nqn9Y5RWeA59Yvo3OAlomCymfbCT17Il+m/XLLYfO9H7kwaPyjbjVGWfqPq9S+o7R6YFewuLB36xCDf3NHyMmNPXtH086U4c/r0RcnOOZwNeJIfG1YFfLaRc8hlUoS5SvZiaBtDnz+SLA== 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=BpqyG04nczuH6wv0X7Nhs2j+2wYFC4Gsyq+tV8BPdwU=; b=EZFlbTT4u3/HSotLEnMpiweNYfcjfrglZEdqWm+yWBkAr88QcVGygbxIwW/du5CKqCVMAq2+X/7GOwK0OFeTiX9jANb96Wwb2O7Ssye9vPga/2mpzXw2DPnA9bLpWpuUaLiLA3sxzW0aWmESSS4/KzBSCMhNQiSZNFsjwEkIa+G6FoS9SrnBz7KAbiOMEYowYymBlWvbrleFeoCoa1TxUNFqehSbnuO5Kzzj6EsLaEkZUB2xf26nnJyo7xzJQivS+79KhKZ3R/74gXLbwUTYOAA90hwXReFjKbmR9Wf/VVV3VEH1dheB3VLkJ93CK03A4p1qMSlP5lCrVKYKldmDWg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iisc.ac.in; dmarc=pass action=none header.from=iisc.ac.in; dkim=pass header.d=iisc.ac.in; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iisc.ac.in; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BpqyG04nczuH6wv0X7Nhs2j+2wYFC4Gsyq+tV8BPdwU=; b=nELsLQeQj8RpxQwHgfIV8Sfz5LI0O5fmJT66rgBbVCj/z+GyI5YgJgCKjE29Y6tvDgyNFongzYXG0tCl2L//qXpHy4qIR+1+ZQ91RXPko4LglUWBpFGw5MRNkSwhyCAqdSOhwM87tIf1X68jiKz6XER/KYMMgZIO4P42KUkJZig= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=iisc.ac.in; Received: from MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:37::23) by MAXPR01MB2175.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:53::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.23; Thu, 26 Aug 2021 16:10:16 +0000 Received: from MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM ([fe80::6096:2bb9:fc3a:cd39]) by MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM ([fe80::6096:2bb9:fc3a:cd39%5]) with mapi id 15.20.4457.020; Thu, 26 Aug 2021 16:10:16 +0000 Date: Thu, 26 Aug 2021 21:40:13 +0530 From: "S.V.R.Anand" To: Routing Over Low power and Lossy networks Message-ID: <20210826161012.GA4367@iisc.ac.in> References: <20210822051345.GA3910@iisc.ac.in> <20210823170926.GA4577@iisc.ac.in> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-ClientProxiedBy: MA1PR0101CA0040.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:22::26) To MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:37::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from iisc.ac.in (49.206.10.139) by MA1PR0101CA0040.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:22::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.20 via Frontend Transport; Thu, 26 Aug 2021 16:10:15 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: adb72ad4-b7b4-47f8-44f1-08d968abfdb9 X-MS-TrafficTypeDiagnostic: MAXPR01MB2175: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: vxjnPpWFbIAqBoEKDTfq4tIwl+Lqi+AvvxLC5mnpKPFY2WzoNfyFxPsiykvl/3Wh2cP8+NQLaReeQLW4HkoQb7FWjx+T/0PtARu/ctcjsxMWKQLB3NWT+ieFppmQq5CImCWFHR8p3V/mCgbT12738esUCD7TcbLuQOK+ymJVqGsR9FROSynUBXGnm5ClY0BkWhCtF7Oo4H5WOUWHdZ43flZzv6tuUIpUVe4BbCLer6huk9RwSZinZYZfNVsL6J0uqXz5WxATNedzi48GS3XtEy1nf8X7CkluZXnCnCdv/XDIHOmIBZxCp0Og10vVx6z2QpbCFRL/LeVLhwjlGBIEOXD4PCZPyRPKJg7c2OW20xazwCRIsqXhADNUbZ+NKMtPKmtzMx3NV93a+L1RSSk6SS8fuwOuPz2b4Yo8SRHyirGq74Xlt40jFDQfKLf0TXppi5hfkDQMLcwNnmwlxBVmBF36QDTDqspi6pkZNZtcgXxYLeLpaLzMvI57fFr45Zmov20Q3cmJ8ZNijd2Mce5pshnzNkEEd6gb2m4bKjsjgbrK4mm+L0kjOR8Tpbo1gwjm6MDElRrR+GHRnnL7cHDb70O4+hM/NGvlBrx15mb3mljAwVu4cDGvkl6VQexmw+IZRk0SV5D7Cck6OpnwrHbsuBTxUMH/4ikazj8Cqlqd8x8YIVTxzWwP8YwNUDrULIpMlH1QUa2fA2De5ckEG6k2MdqT5HWu2+1qv1MUA3bzQ/p2W/Exy9ZuKVUdWsn9QNYqIvz3Ylj2hw5aC3QpXHoiLg== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(376002)(39830400003)(396003)(136003)(346002)(366004)(66556008)(55236004)(53546011)(26005)(1076003)(52116002)(7696005)(186003)(1006002)(8676002)(66476007)(66946007)(786003)(5660300002)(316002)(55016002)(36756003)(6916009)(966005)(8936002)(83380400001)(30864003)(2906002)(2616005)(956004)(86362001)(38350700002)(38100700002)(33656002)(478600001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?RGQEuumxB+36idKktO5IzWiICnrnOyDlaI3hD1ADiV49OcMIIkVb2i1GPBVk?= =?us-ascii?Q?tEfv12VmAEeypQpmrHxPuAtB6/ECz+yfl4my9x+uiCyG9dTcF4Szyx2nx6DU?= =?us-ascii?Q?Negue1v18+SR/v+CJrg5uDbUTcpvg4qyBueEdwc1VzbWB6MizbnSXnITOS0k?= =?us-ascii?Q?G6RA6fwCav/f5Br0+wyu0UUaIxUiX96MleY52wFBGf/Fwk7PWn/nuj168PRS?= =?us-ascii?Q?y+GnnlSO/TUqptoV1Amk4cUmx8FMK1bIVU1/cGGpn0HT1RYO5f+eYTPSwcYu?= =?us-ascii?Q?lrSTIFWyW5OoJmCD9HaDx5D2dLcmmLQPJNGmlNW17w8ZqZlwUrAFqWmsi6gT?= =?us-ascii?Q?2FvR8EpF54e/f8aJwB8nl4Zax6n0JzsKvtDzkm7E4kMRYqxxq9kKV3VPFq5z?= =?us-ascii?Q?V+h83dVTPmKN1M0ML2M08lmSxawaMtyq8PrRcQh2s6CsAK9HczowvJH3lNqh?= =?us-ascii?Q?2yK56yu5kdzWrPn6ykXbSdjVlTjz03Ce14ytIM8Lsyqu4q+4c3eDOoGvyS+d?= =?us-ascii?Q?nnzG0EpHBzzl1nSgvQK/UVJIisWu5dzDK53zgxLGtb6fb+ZYi2O+4nRIPegy?= =?us-ascii?Q?i3k90WTjw3hnktzJa4neo+G7yoogQPHJyGC873I3USgSXzhZSiN7UIVqsIi2?= =?us-ascii?Q?Bbh2rPVZzewNzBNPbsTbSvkunmdCmHZ3YMf9MoI0X/cxRJiLNx8amKUV6rKF?= =?us-ascii?Q?r7NhnKdyqTRw57YxRj9cvX46GM4TIOVR73R+QW3gxBdoiFz+RVh3wi+0xdh5?= =?us-ascii?Q?1ofTb4K/S6HoV1iiy35idnY0D3BiKmhp3wtPCzhCIdTBkWsgtXP2pySF8OYU?= =?us-ascii?Q?vaUqdoHTlR3znxtd6nptTTohniLRiJ8xFcjkB0Hi1WKF205hQGBFo1iUbRCN?= =?us-ascii?Q?lrZR6IpwJdSETZ204RFu2ugoYTvAZAXAmmOTQr/dzhxFAs13kp3YJXWc7c99?= =?us-ascii?Q?Ro04zmOcAXBFo2Cf4CYLMAF/AhDpWhfBVeqCADcOuMbeS1sEGPFiZKb6zpUp?= =?us-ascii?Q?tFkwsrlf8HGSZMXmPQTrbTUjkgHFEDjgXnL647yeQlM12w3wcyExZV1wFc1l?= =?us-ascii?Q?rD44TJKaIy+MEz0RtKtjTN6rpqMK1jYEUYwI8HtQDKXOyR5ZWthCC7Be84ZD?= =?us-ascii?Q?bnfV/GFGdsMHx4t56FlWo1HpbjWnxFy0PeQefmERRiKQ6jATyVxWKw3crpOc?= =?us-ascii?Q?xAE0uLyciUDqPc8N7Ucvmry3dFhYxYCrMHJ2XF4JJ5FxVZ5zzIRhG0fdsiXb?= =?us-ascii?Q?GHj71Hq85R0tbZ/03L0I4wnVRP49QbPdKQGj54wCQ5UneODjdWOT3IdbWfME?= =?us-ascii?Q?+3VmaeUUohFaA3h6Veg5HtWq?= X-OriginatorOrg: iisc.ac.in X-MS-Exchange-CrossTenant-Network-Message-Id: adb72ad4-b7b4-47f8-44f1-08d968abfdb9 X-MS-Exchange-CrossTenant-AuthSource: MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Aug 2021 16:10:15.8427 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 6f15cd97-f6a7-41e3-b2c5-ad4193976476 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: DZCRIUpg2ZnLiTWWHZp2t0MF44TFoRQFFWcARDjYN7qgduQ3cs3MfEFeKhnva3PaTeW7Ru1A4FdnWNSW9vuq0A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MAXPR01MB2175 Archived-At: Subject: Re: [Roll] Review of draft-ietf-roll-dao-projection 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, 26 Aug 2021 16:10:27 -0000 Hello Pascal, Thank you very much! All the changes look good to me except one specific point mentioned in-line for which you might want to provide additional text. Regards Anand On 21-08-25 17:02:54, Pascal Thubert (pthubert) wrote: > > > Hello again Anand > > I added text in the intro to cover some of our discussion as follows : > " > > There specification considers that there's a unique PCE with full > view of the network. Distributing the function for a large network > is out of scope. This specification uses the RPL Root as a proxy to > the PCE. The PCE may be collocated with the Root, or may reside in > an external Controller. In that case, the protocol between the Root > and the PCE is out of scope and abstracted by / mapped to RPL inside > the DODAG. > > The algorithm to compute the paths and the protocol used by an > external PCE to obtain the topology of the network from the Root are > also out of scope. The effectiveness of the route computation by the > PCE depends on the quality of the metrics that are reported from the > RPL network. Which metrics are used and how they are reported is out > of scope, but the expectation is that they are mostly of statistical > nature, and provide visibility on link throughput, latency, stability > and availability over relatively long periods, more in [RAW-ARCHI]. > " > Please let me know if you're OK with that text; The above text looks fine. > > > > > > > > For an effective operation of P-DAO route projection, one of the > > > > keys requirements is the presence of network monitoring mechanisms > > > > for LLNs in place for letting PCE have a complete view of the > > > > network state. I > > > > > > Very true... > > > > > > > > > > am not sure if we can assume that such OAM mechanisms are already in > > > > place for LLNs as the track setup and its maintenance are closely > > > > dependent on these. > > > > > > That too. The combo of this draft and RAW assumes that the PCE gets long > > term stats and availability information, and computes routes based on that. > > > > > > > > > The effectiveness of the external route computation > > > > by PCE is tightly coupled with network resources required for > > > > monitoring the network state, stability of the wireless links and > > > > delay in obtaining the network state information, and so on. > > > > Strictly speaking, this important functionality is a pre-requisite > > > > for implementing the draft. > > > > > > Yes; the PCE computation can be proprietary since it is inside the box so > > arguably the missing link is the metrics and formats to be reported. Should > > we do that in the same doc (complexity rising) or should we separate a new > > draft like RFC 6551 vs 6550? I'm tempted to do the latter. > > > > > > For now the PCE can live with existing link-related network management > > information to compute its routes. > > > > > > > > All this is covered by the text above > > > > > > > > > I list down few questions that came to mind after reading the draft. > > > > > > > > - Does the draft allow for the co-existence of centrally orchestrated > > > > tracks and distributed RPL operate within the same network ? Since > > > > draft does not say explicitly, is it reasonable to expect that > > > > both can > > > > be present together ? If the answer is yes, then the draft > > > > needs to mention the effect of PCE on RPL managed routes, if PCE > > > > controls network resources for the entire network. > > > > > > Well, the assumption is that the root is really a proxy for the PCE, > > turning whatever abstraction the PCE uses into RPL. > > > See the intro: > > > " This document > > > specifies protocol extensions to RPL [RPL] that enable the Root of a > > > main DODAG to install centrally-computed routes inside the DODAG on > > > behalf of a PCE. > > > " > > > > > > If your question is what if both the Root and an external PCE compute > > routes, well that's beyond this work. This would mean syncing and > > negotiating the use of constrained resources. > > > > Yes, as you noted, my question is the latter where both Root and PCE are in > > operation. There will be a continuous churning of the RPL maintained routes > > whenever PCE re-provisions network resources for its own purposes. It is > > hard to maintain the objective functions of the RPL instances. How do we > > then resolve this possible situation in the context of current work ? Once > > the proposed mechanism allows for the co-existence of centralized and > > distributed routing mechanisms, then we need to worry about protecting RPL > > routes. Can the draft say something about it so that implementors are aware > > of the scope of the work ? > > > > For one thing the PCE may run inside or outside the Root device, but there can be only one, and the new text clarifies that. > About the relationship of the 2 types of routes, this is like TE routes in a SP network, and multi topology routing. We have to ensure that we're not creating loop, and ultimately provide policies to select traffic that is injected in Tracks; in the context of this draft, we're just adding routes that have a highest precedence and go all the way to the destination, so we get there quickly in non-storing mode, and we know there's no loop in storing mode. Remote LFA would avoid that constraint at the expense of higher complexity. > > I added > > " > This specification enables to combine one or more Projected Routes > into a DODAG called a Track, that is traversed to reach the Targets. > When the main RPL domain is operated in non-storing mode, a Track > provides reachability to one or more destinations within the DODAG, > which bypasses the Root and improves the latency for the redirected > flows. Note that this specification does not provide policies to > decide which flows go in which Track. Routes to specific > destinations over a Track are always more specific than the default > via the Root, and any packet reaching the Track Ingress for a > destination that is reachable over the Track will be injected in the > Track. > > " It certainly is an important text. But I am not sure if it addresses my concern which has to do with topology changes that can occur in the RPL DODAG due to frequent changes in the available radio resources because of track management activities by PCE. The RPL ranks will undergo changes causing path recomputation so as to maintain the OFs of the RPL Instances in operation. Am I missing something while reading your modified text ? > > > > > - Curious question closely related to the above. If one decides to > > > > use PCE in > > > > conjunction with P-DAO to centrally manage the entire network and > > > > thereby > > > > aligning ourselves close to RAW architecture (Refer to Profile 3 and > > > > above of Section 8), and not use distributed routing at all, > > > > full-blown RPL seems to offer minimal benefits here. Why not use > > > > the compute > > > > and memory for the purpose of implementing RAW mechanisms ? > > > > > > I think that's the same point that the Root is really a proxy forwarding > > in RPL parlance the abstract route decisions by the PCE. This is enables a > > simpler operation with less code in the devices. > > > > > > > > > > > > > > - There could be non-negligible indeterministic delays in setting up > > > > on-demand tracks > > > > before the data starts flowing. Can the draft touch upon the > > > > possible ways to > > > > minimize these delays ? Should we have dedicated tracks for > > > > signaling purposes ? > > > > > > Oh, interesting. Usually such thing happens with a net priority QoS. > > Maintaining dedicated tracks may be fragile, since they would be needed to > > repair themselves. True that the draft says nothing about that. I agree it > > should. Any suggestion? > > > > > > > One suggestion is to identify and maintain dedicated reliable signaling > > tracks with minimal resources to cater to latency critical tracks that may > > be setup in near or far future. These special signaling tracks, as decided > > by application requirements, can use redundancy so that the tracks are > > always available. > > > > I added > > " > This specification extends the DAO message with the Projected DAO > (P-DAO); a P-DAO message signals a Projected Route to one or more > Targets using the new CMOs presented therein. This provides a RPL- > based signaling to build the Tracks as designed in the 6TiSCH > Architecture [6TiSCH-ARCHI]. The Track may be set up for many > reasons, including as a bypass to lower the load at the Root, or to > enable urgent traffic to flow more directly. The signaling should > not be stuck behind high traffic levels. The expectation is that the > P-DAO message is sent as high QoS level, above that of data traffic, > typically the Network Control precedence." > > I'm not convinced by Tracks to configure Tracks. Quis custodiet ipsos custodes? > This addresses also your comment below: > > > > > - 6TiSCH has been mentioned just in the introduction. It would be > > > > nice to associate > > > > it with the P-DAO track installation process. A 6TiSCH track needs > > > > to be > > > > setup depending on the application bandwidth and delay > > > > requirements before > > > > sending P-DAO message. In some sense there is a dependency of one > > > > on the other. > > > > > > There is indeed. I can add more words on that too. This can be done > > together with your other suggestions below. > > > > > > > > > > > > > - Can the scope of the draft be extend to mobile scenarios, for > > > > instance, networked > > > > robotics applications ? These present additional challenges in the > > > > form of > > > > frequent topological changes causing flurry of network state, and > > > > track updates. > > > > A short note on the issues that need to be addressed to support > > > > mobility could > > > > be useful. > > > > > > > > > I've worked on interesting techniques that could apply. What strikes me > > is that you're describing an applicability draft as opposed to modifying > > the specification. Could some of your proposals actually become the subject > > of yet another draft, this time on applicability of P-DAO? > > > > > > > I agree with your view. > > Let's keep a note to start that doc asap. > > > > > What about P-DAO for mobility as an independent draft ? There you might > > want to describe the techniques you have developed. > > > > I am not in favor stuffing-in all the interesting opportunities into the > > current draft. Can you introduce a "Scope" section where the applicability > > of P-DAO is mentioned ? > > > > > > > > > > > > > - There could be situations where the Root can decide to modify the > > > > already > > > > installed routes asynchronously to maintain the Objective > > > > Function/QoS of the tracks. > > > > What is the consequence of this action on the ongoing data that is > > > > already in > > > > transit ? > > > > > > We're in RAW territory here. I'd say that the PCE/Root only updates > > segments at a time so the parallel ways still operate nominally and enable > > the continuous service. One the additional path is installed, the Root can > > swap the Track (the source routed thingy) to use the new segments. All in > > all, with the redundancy that we can expect here, it seems doable to do it > > live. > > > > > > > Yes, RAW territory indeed. I am strictly going by the abstract of the draft > > :) > > > > Since Root/PCE does not know if the track is currently engaged, route > > modification which includes deletion of the routing entry can potentially > > result in data loss if we don't do what you suggested above. > > I think including some text helps in answering a natural "what if" question > > that I got. > > > > > > OK, I'm adding a "Maintaining a Track" section as follows: > > " > > 7.4. Maintaining a Track > > Adding or rerouting a Track may affect the traffic that is > transported over the Track, e.g., packets can be misordered if the > new path is faster than the old. For critical flows that require > timely and/or in-order delivery, it might be necessary to deploy the > PAREO functions [RAW-ARCHI] over a highly redundant Track. > > This specification allows to add subTracks to a Track by sending a > non-storing mode P-DAO to the ingress associated to the same TrackID, > and a new Segment ID. It is also possible to replace a subTrack by > sending a non-storing mode P-DAO to the ingress with the same Segment > ID as the replaced subTrack and an incremented Segment Sequence. > > This specification also allows to add Segments to an existing Track > by first installing the new Segment(s) with one Storing-Mode P-DAO > each associated to the same TrackID, and then joining with a subTrack > signaled by a non-storing mode P-DAO to the ingress and also > associated to the same TrackID. That subTrack may be an addition to > the Track or a replacement, as indicated above. > A misbehaving Segment may be modified by injecting a new Storing-Mode > P-DAO, with the same SegmentID and an incremented Segment Sequence. > The new Segment MUST be installed with the full new path from the > Segment Ingress to Egress, both included. When a node that is on > both the old and the new Segments this updates the state associated > to the path. > > Once the new segment is installed, the sequences of nodes that are no > more in the Segment MUST be removed one contiguous sequence at a > time, with the one or more nodes listed in the SF-VIO, and a Segment > Lifetime of 0. Nodes along the sequence clean up their state and > pass the message to the previous node in the list; the first is the > list sends the DAO-ACK back to the Root. > " > Looks good :) > Are we getting there? > > Keep safe; > > Pascal > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Thu Aug 26 23:03: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 107633A1B2D for ; Thu, 26 Aug 2021 23:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.69 X-Spam-Level: X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=iisc.ac.in 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 JXjy13f6XXeW for ; Thu, 26 Aug 2021 23:03:33 -0700 (PDT) Received: from IND01-BO1-obe.outbound.protection.outlook.com (mail-eopbgr1390071.outbound.protection.outlook.com [40.107.139.71]) (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 C4F983A1B38 for ; Thu, 26 Aug 2021 23:03:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=d/k38AZXNx5fTSsm0ipDFVbdeWWjGTfBpIK+BUjoYI2ko3yuu90fC8p9HIbPx92kD5clW7qa7d4VJRPHIOmjRWiVBypykCfR9xoCjRZLdvCa2grPF4rN+GyY6BkStbFqt+tAQf6HFxH+rjK06mzJhP27QqoXH5cZ3I41w0AYnAt7M7vFFQQe6pV57h4bn2ZezccKzVELlfbUyjrNgL0PwpRojq+PBX23p4tfGHMZLP8ggW07/0uKj1z9TtEh4X+XyGZLu0bESiCiyba3IMUKYWwZS8WuqSovt1GDd9e2TYNrPcpqDUAYgZY0cV6aZ7Dx3IkW2iKngfF1gQ1J+8kdWw== 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=5cZWxqurGGtGTxmteFapy/AVeEHqOovIk6CgSj7RnZU=; b=fTUSlHKM7jibBfaPU/KPUVCfMyn28QpOL+O6cKTaaCqHkJ60FaalxqiU2Qyp7lDJRseIvasJWXx67rYpTT9HBHALi5mvmuNKRN2Q9WsQJ1e/W+9xhu+ytymddr55RW6hP2iNdcKtiQ3LDOeuyeJJ8sfJYLvIc7KobDPTgeZ/l9C+7KwwmFuVQjsSX3fnUNcxnYKTNYZa4+ouBiH/yPa0KkuWpSHPeV3xBh4UikM4Lj+hsnc67XjCFf6RAdrKfPhpoGu49mvNDeXvAms5uZz4IPwC7jtSrFnZNjs0ipyW9ZjW6XddUe/KEMK4Ggn7ZWUay5C8wttVyb5ifbLpZHHoOg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iisc.ac.in; dmarc=pass action=none header.from=iisc.ac.in; dkim=pass header.d=iisc.ac.in; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iisc.ac.in; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5cZWxqurGGtGTxmteFapy/AVeEHqOovIk6CgSj7RnZU=; b=orhlobpSQitgDsC76kpqMem5NsNYRu5bRlYlBWxmMRVoYSjQolUI1vOWVyD5Bn7A/P3COnhGZfWNlJGfOBKytYilj5RGrE+nYaibJZMPdcdZbL8zOUlwAS+KKC14uctR5b7NG/sDrPgbAUZ9027pp3KsmyHG+BOuaB8x1Id9uH8= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=iisc.ac.in; Received: from MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:37::23) by MAXPR01MB2224.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:4f::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.20; Fri, 27 Aug 2021 06:03:26 +0000 Received: from MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM ([fe80::6096:2bb9:fc3a:cd39]) by MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM ([fe80::6096:2bb9:fc3a:cd39%5]) with mapi id 15.20.4457.020; Fri, 27 Aug 2021 06:03:26 +0000 Date: Fri, 27 Aug 2021 11:33:15 +0530 From: "S.V.R.Anand" To: Routing Over Low power and Lossy networks Message-ID: <20210827060315.GA28747@iisc.ac.in> References: <20210822051345.GA3910@iisc.ac.in> <24891.1629827443@localhost> <20210825164051.GA5889@iisc.ac.in> <31748.1629918032@localhost> Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <31748.1629918032@localhost> User-Agent: Mutt/1.5.24 (2015-08-30) X-ClientProxiedBy: PN1PR0101CA0014.INDPRD01.PROD.OUTLOOK.COM (2603:1096:c00:e::24) To MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:37::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from iisc.ac.in (14.139.128.15) by PN1PR0101CA0014.INDPRD01.PROD.OUTLOOK.COM (2603:1096:c00:e::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.17 via Frontend Transport; Fri, 27 Aug 2021 06:03:26 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7b2766e1-93d2-4bc8-4445-08d969206297 X-MS-TrafficTypeDiagnostic: MAXPR01MB2224: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Gbl/zXnSgCQv9NvPJXtTYlINjSHXhLpj5FSG8jRZ6HpYHdq1SrRoiHHYQdDE5xvI1JmNstCBqUfHl0mYEWTKsGVXygib2mXk56dAVCaHczY/P/X+u75UtjHos0WT9rAAVVgTk/7aQcLJ37/ClJNB7Q+lqGht7HS3PEsHuBUlmRPCJ889AzMiFIIq5dgtJ9CazvBKZCOfA1vkTezBYaLTzH20KbEqgUORAsBiKWLneuWhYCQ3Qz3/DwtfkG3Gy8puBVf7GisYQ90L2WpQVsL4tNo7OJ8K6bmAUp8JUUn6NsB6za/UxMsWnzohYjgMX77QZMJDMJ9kIGgxCtA1W/VCODKXHpZcpvME0f6yz/5e6mEtzDF2ZkG+ndD0jrhVH+jE3VRfXCHMJKo6H6OydnZ6FKOd4tQhs3+6eeJAZiQAu8CqKIzQfRdPaPCFuJbLr4wOKZMMLttgGmNSBgB5kFfLpj3HKGwi2va78EHPdjOfxuqLMC0wbQvKFPWUAZtVkqA/FYzUFFsOHBsD1QKtqIpeEvMqAMmZ91grvWYmyyWOEMi6CVkm1zEKv1lsGmiCBusw38Ub9XXSbl3+P/nxBikAhJyTKwRhzRVtMh7gkvLSnmHgdUaXokV4Ys2wtBt/+qFo7JaDPDKTnydf9b2cx3c8f65KftTM82MwWG/sRo0epG4Jld4iz4UiP0H+xBkU5/qSeykbIVKnSVM5AlWllnHJvkHrXfsXuh0W/qwzj/MUJTLUnMfUobRDYPRoRP+dYvn5mSXYO6mO11ZS8YBMhquMUA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(39850400004)(346002)(396003)(366004)(376002)(136003)(6916009)(2616005)(786003)(86362001)(8936002)(1076003)(2906002)(1006002)(6666004)(8676002)(38350700002)(316002)(38100700002)(66556008)(956004)(66946007)(66476007)(36756003)(55016002)(478600001)(186003)(966005)(26005)(7696005)(52116002)(33656002)(5660300002)(66574015); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?iso-8859-1?Q?4iigGnMBeEyRrMv69+NbeCIQxaZzfdxmIQzg/CinCQw9nFrFrT+b2hAUxd?= =?iso-8859-1?Q?zcskYzJWUGb9YA2vQRGBRKpoxirdKnsZ/5Uo7s5wd5AG2MGhYxGGnEQx/w?= =?iso-8859-1?Q?giUHB401iyDzMvyp3bJOViTUFdx0KK4zN50zo/Om/Kzh0w8deOLzb8N4fN?= =?iso-8859-1?Q?etYRcbg+SVskIRcZnKFsC0A62Vz6k5nuQ4rUL93AnYpORBZaCUsWCszrT5?= =?iso-8859-1?Q?QNgs348jRydnBo3vOmLctMoqoB6sdEdars7Z2IdBpUWLBO/mInr4CBUdED?= =?iso-8859-1?Q?pYNr8Z/zc+LlHYFxzw/bmbyUC/BH/jc3ZTr6uw0WYtYDoASYS/CDobd956?= =?iso-8859-1?Q?19YdK9B6gVK4SSWdIJWvKdV+MVgbJicP88A9Pg65ZJroz3ndbUMzWSL3J+?= =?iso-8859-1?Q?0OEnvVBsNihQElcNyhUKXawfyQlXB3sKVW+SYT3iex5n8GYZzDHTglKoyN?= =?iso-8859-1?Q?9lv0v4kI85wMtIJtu7Oj8/ZjmP/ju+bL7QKWsvTw1COYVS8pIjESs68w2z?= =?iso-8859-1?Q?Ssce2NW7Tmz9sd/4e45t3MGnJ8Bz97nIIIpMbR5QKDqoX7NerAGrS96TL/?= =?iso-8859-1?Q?u5WsNMhzChYA83RKfwTOvNZSd2V7QeXyNmOd6NKLkrLpG5Vpvg8gqIRnHJ?= =?iso-8859-1?Q?NChIiJ7KY0EJ8OCC353qmMKKjDe+964/WSZ25BV1pHpr0KDA8AHix5fEug?= =?iso-8859-1?Q?z4oOjK5yaErunZP5cfY7wkZXtxC9sqv4BpKeO8euTm3ELMFAGK3QnBEdUA?= =?iso-8859-1?Q?quAVp+sgyg+ULxNfsTJkW7OkHGuQq1bRJVWcqeld+Oo2KQeitVeBVqql2G?= =?iso-8859-1?Q?uq2StajyL5q3ZY9XvAZm9LbtypNHlz3hJFwz9FiRI4n2wJmzQuiSWZtmS+?= =?iso-8859-1?Q?9k2uYm92YFzSRa8bScIgk5iBcV7rwCEEA15zy77JMvf7P9O5xtqdUOPbxL?= =?iso-8859-1?Q?Q80yKgKfO0kStujbK0LmQ/19QbTjB2yeawqXXw/r1WYDyHNIr8BOce3V4Y?= =?iso-8859-1?Q?Ix/rLPqekJ5CWB+UKw2HBiUMto6f+JQ1+F3yIWdpttH3K0GD/FYrV6drIq?= =?iso-8859-1?Q?e2+IYgmvjAbpnESJLzzZ0p/YoA+H8JJD6znRVb0lvarkfIoBWCBw4B4tXw?= =?iso-8859-1?Q?Jl1g6TUIYR6st231hLVPg/M1qr0AdLf5TaNJj8NvmFQmKi0LzBipmCK+mD?= =?iso-8859-1?Q?/NftxsrCWXHof5qblh0g4/gN5J84VzO8IdUODj8W4Bm96cN8mrLluB1j3p?= =?iso-8859-1?Q?2Bo7zai+ehBMDOQhIOJGw/3bdu8hPA5oWIeBdlAEguWw6TyO//VgJS4JHX?= =?iso-8859-1?Q?CdmYNsqRkXNbx2RqohBFf0zyarb2rzjKSdPH9bh0d659r3E8OKQ7QghqOR?= =?iso-8859-1?Q?TClmUkw/rU?= X-OriginatorOrg: iisc.ac.in X-MS-Exchange-CrossTenant-Network-Message-Id: 7b2766e1-93d2-4bc8-4445-08d969206297 X-MS-Exchange-CrossTenant-AuthSource: MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Aug 2021 06:03:26.4665 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 6f15cd97-f6a7-41e3-b2c5-ad4193976476 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: TCaszP/O3jQYNcbIro/Sed2N3Q+FHBAVJtFsDsdWaGg/i5EAafT3RfmxVcm6dMNQyciy/u/b4fvK0n92LDW/Nw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MAXPR01MB2224 Archived-At: Subject: Re: [Roll] Review of draft-ietf-roll-dao-projection 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, 27 Aug 2021 06:03:39 -0000 Hello Michael, and all, At the time of writing the paper, we also wrote up first-cut version of the draft. But we never got to publish it in any of the working groups. I will be very happy to share the draft, which is still in the nascent form, and get initial feedback on whether it is suitable for an RFC. Regards Anand On Wed, Aug 25, 2021 at 03:00:32PM -0400, Michael Richardson wrote: > > > S.V.R.Anand wrote: > > In our lab we developed an in-band OAM telemetry scheme for LLNs that we > > named it Co-iOAM. The idea is very simple but it has been very effective > > in monitoring a real-world deployment of RPL/6LoWPAN network that we > > setup. > > > ["Co-iOAM: In-situ telemetry metadata transport for resource constrained > > networks within IETF standards framework", > > https://ieeexplore.ieee.org/abstract/document/8328276] > > Behind a paywall. > Is this suitable for an RFC? > > > -- > 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 Aug 27 00:47:58 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 78D183A223E for ; Fri, 27 Aug 2021 00:47:56 -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 aw-3E8TSJuWb for ; Fri, 27 Aug 2021 00:47:50 -0700 (PDT) Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (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 CF20E3A2233 for ; Fri, 27 Aug 2021 00:47:49 -0700 (PDT) Received: by mail-ua1-x92f.google.com with SMTP id 75so2972767uav.8 for ; Fri, 27 Aug 2021 00:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w1MfAP4B5HuPflfmzOUuksuQNwuo77CdeNMZKvKE63I=; b=TWkodVG1vX9HG1TEdTklssSWpVg2wBQllR2G9E1XA4xwKr76rfEJD8kFAvVBvc+5wl 0P8xIC/u80mqmfXfvLHcpRnUmgbrIbjJaWdXb781MGG61fQao2Xe3okC8WNecRH61QT4 6Kz52WSx5sALcFmDZojWShfK7jBYkfHHu38ccC6YiDcl2JaL8b/5AKHO0sLmtG9YsQjL z+rB0GB18nsXu9BgNFdVsD/L7oxFj/Moxlp4dem1g3mbHo/soPq/zRSca4BDKB/5h5Jc dG9iskwdzyKVx6ec4/aPn7OU+LaOOi0CUh68sAWEDYdi2m5EwqF7ktIkhZxnRieflSc0 uXoQ== 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:cc; bh=w1MfAP4B5HuPflfmzOUuksuQNwuo77CdeNMZKvKE63I=; b=E6C4ZhijsDMMvaw9hupWgmFloZ+6hETNLp2130pukH5NeY/VvzVpfL220ZhG8e3baH OCRDe7bDyKo/o92urEbvd5g+q7VT09eU/Xjsz9PKOKQ98en5Pk+BPMLfjJWRxtanVSY1 GJYafGPS+01dwGNb++zVXDMI3Ojc6CYl+znJqN0eDIa/UYZMGUs9vqsa24+0B5LodCXe dcZ478E7vtb8/z/PuZBkGo9R61f+0y1yufTnMD6ezxB7S+UE1srgRv5WaRkImCwVVThT qOQREgFsqQ+qEROQHcjnVEcZKvGhHUiUPqG1AynePjefEWMlvrmDvOfYkcAKbpodZ4oK v+Hg== X-Gm-Message-State: AOAM533JpUyETS4pdtM+Mgl78xb8xry1Gao27LtVYtGy7hEymaLD+MIY q/PsfKNYKQnC/7ClUsbLbJQpxFt1alEsjMp/Z+9aW+XZSaU= X-Google-Smtp-Source: ABdhPJwORy4dnH/HQen3XnRZaHRh6FHC+P06xvWjTpts0ZJ38xE9fK+7AUAT4Ef88AF1I2FniVIKJdfuM4t289GGnxc= X-Received: by 2002:ab0:42c6:: with SMTP id j64mr5526938uaj.51.1630050467712; Fri, 27 Aug 2021 00:47:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ines Robles Date: Fri, 27 Aug 2021 10:47:11 +0300 Message-ID: To: roll Content-Type: multipart/alternative; boundary="00000000000018111e05ca85b337" Archived-At: Subject: Re: [Roll] ROLL Interim Meeting - 31th August - Agenda and meeting details 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, 27 Aug 2021 07:47:57 -0000 --00000000000018111e05ca85b337 Content-Type: text/plain; charset="UTF-8" Dear all, We have updated the meeting to have it with Meetecho. Thus, please find below the updated meeting materials: Meetecho Link: https://meetings.conf.meetecho.com/interim/?short=e89314d3-d762-4877-8f84-1108420ad8a4 CodiMD: https://codimd.ietf.org/notes-ietf-interim-2021-roll-02-roll Slides: https://datatracker.ietf.org/meeting/interim-2021-roll-02/session/roll Comments welcome, Thank you and best regards, Ines On Wed, Aug 25, 2021 at 7:04 PM Ines Robles wrote: > Dear all, > > This is a kind reminder of the meeting next week. > > Dear presenter, if you haven't yet done so, please send us the slides or > upload them into the data tracker. > > Thank you and Best regards, > > Ines and Dominique > > > > On Tue, Aug 10, 2021 at 9:50 PM Ines Robles < > mariainesrobles@googlemail.com> wrote: > >> Dear all, >> >> Please find below the agenda for the interim meeting >> >> >> https://datatracker.ietf.org/meeting/interim-2021-roll-02/materials/agenda-interim-2021-roll-02-roll-01-01.txt >> >> Presenters, please *by 25th August, *send us the slides in pdf, or >> alternatively you can upload them in here : >> https://datatracker.ietf.org/meeting/interim-2021-roll-02/session/roll. >> >> Link to the CodiMD: >> https://codimd.ietf.org/notes-ietf-interim-2021-roll-02-roll >> >> Link to Webex : >> https://ietf.webex.com/ietf/j.php?MTID=m0f82035057cfa91a3d4a625639f73c02 >> >> Note that you can find the provided information (CodiMD, Webex Link, >> Jabber, icalendar) also in the top right corner of the meeting page [ >> https://datatracker.ietf.org/meeting/interim-2021-roll-02/session/roll] >> >> Comments welcome, >> >> Thank you and best regards, >> >> Ines and Dominique. >> >> On Wed, Jun 30, 2021 at 1:10 PM Ines Robles < >> mariainesrobles@googlemail.com> wrote: >> >>> Dear all, >>> >>> Thank you very much for filling the doodle. The date selected is 31th >>> August at 3pm UTC. >>> >>> Please let us know if you would like to Present a topic by 30th July >>> specifying: >>> >>> - Topic >>> - Duration >>> - Presenter. >>> >>> Further meeting details (webex, codimd, etc.) will be provided later. >>> >>> Thank you very much in advance, >>> >>> Ines and Dominique. >>> >>> >>> On Mon, Jun 7, 2021 at 12:57 PM Ines Robles < >>> mariainesrobles@googlemail.com> wrote: >>> >>>> Dear all, >>>> >>>> We would like to organize an interim meeting. Thus, we kindly request >>>> to let us know your availability by filling the following doodle by *12th >>>> June. * >>>> >>>> https://doodle.com/poll/nd3z4wyar6tqudcv?utm_source=poll&utm_medium=link >>>> >>>> Thank you very much in advance, >>>> >>>> Ines and Dominique. >>>> >>> --00000000000018111e05ca85b337 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

We have updated the meeti= ng to have it with Meetecho. Thus, please find below the updated meeting ma= terials:




Comments welcome,
Thank you and best regards,

Ines

On Wed, Aug 25, 2021 at 7:04 PM Ines Robles <mariainesrobles@googlemail.com> wrote:
<= /div>
Dear all,

This is a kind reminder of t= he meeting next week.

Dear presenter, if you haven= 't yet done so, please send us the slides=C2=A0or upload them into the = data tracker.

Thank you and Best regards,

Ines and Dominique



On T= ue, Aug 10, 2021 at 9:50 PM Ines Robles <mariainesrobles@googlemail.com>= ; wrote:
Dear all,

Please find bel= ow the agenda for the interim meeting


Presenters, please=C2=A0= by 25th August,=C2=A0send us the slides in pdf, or alternatively you ca= n upload them in here :=C2=A0 https://datatracker= .ietf.org/meeting/interim-2021-roll-02/session/roll.=C2=A0


N= ote that you can find the provided information (CodiMD, Webex Link, Jabber,= icalendar) also in the top right corner of the meeting page [https://datatracker.ietf.org/meeting/interim-2021-roll-02/sess= ion/roll]

Comments welcome,

Thank you and best regards,

Ines and Domini= que.=C2=A0

On Wed, Jun 30, 2021 at 1:10 PM Ines Robles <mariainesrobles@g= ooglemail.com> wrote:
Dear all,

=
Thank you very much for filling the doodle. The date selected is 31th = August at 3pm UTC.=C2=A0

Please let us know if you= would like to Present a topic by 30th July specifying:

- Topic
- Duration
- Presenter.

Further meeting details (webex, codimd, etc.) will be provided late= r.=C2=A0

Thank you very much in advance,
=

Ines and Dominique.=C2=A0

On Mon, J= un 7, 2021 at 12:57 PM Ines Robles <mariainesrobles@googlemail.com> wro= te:
Dear all,

We would like to organize an interim = meeting. Thus, we kindly request to let us know your availability by fillin= g the following doodle by 12th June.=C2=A0

<= br>
Thank you very much in advance,

Ines= and Dominique.=C2=A0
--00000000000018111e05ca85b337-- From nobody Fri Aug 27 08:56:40 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 5C1B13A1286; Fri, 27 Aug 2021 08:56:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163007978725.4704.7941798098222821047@ietfa.amsl.com> Date: Fri, 27 Aug 2021 08:56:27 -0700 Archived-At: Subject: [Roll] Routing Over Low power and Lossy networks (roll) WG Virtual Meeting: 2021-08-31 CHANGED 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, 27 Aug 2021 15:56:28 -0000 MEETING DETAILS HAVE CHANGED. SEE LATEST DETAILS BELOW. The Routing Over Low power and Lossy networks (roll) WG will hold a virtual interim meeting on 2021-08-31 from 18:00 to 19:30 Europe/Helsinki (15:00 to 16:30 UTC). Agenda: +-----------------------------------------------------------------------------------------------------+ | IETF - ROLL Interim Meeting | | | | 15:00 to 16:30 UTC - Tuesday 31th August | | | | Material: | | https://datatracker.ietf.org/meeting/interim-2021-roll-02/session/roll | | https://github.com/roll-wg/ROLL-Interim-Meeting | | | | Etherpad: https://codimd.ietf.org/notes-ietf-interim-2021-roll-02-roll | | | +---------------+----------+---------------------------------------------------------+----------------+ | Time | Duration | Draft/Topic | Presenter | +---------------+----------+---------------------------------------------------------+----------------+ | 15:00 - 15:05 | 5 min | WG Status | Ines/Dominique | +---------------+----------+---------------------------------------------------------+----------------+ | 15:05 - 15:35 | 30 min | draft-ietf-roll-enrollment-priority | Michael/Pascal | +---------------+----------+---------------------------------------------------------+----------------+ | 15:35 - 16:05 | 30 min | draft-iwanicki-roll-rnfd | Konrad | +---------------+----------+---------------------------------------------------------+----------------+ | 16:05 - 16:25 | 20 min | draft-ietf-roll-dao-projection | Pascal | +---------------+----------+---------------------------------------------------------+----------------+ | 16:25 - 16:30 | 5 min | Open Floor | Everyone | +---------------+----------+---------------------------------------------------------+----------------+ Information about remote participation: https://meetings.conf.meetecho.com/interim/?short=e89314d3-d762-4877-8f84-1108420ad8a4 From nobody Fri Aug 27 13:16: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 990733A153C for ; Fri, 27 Aug 2021 13:15:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 7.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163009535761.19977.6178979468276774777@ietfa.amsl.com> Date: Fri, 27 Aug 2021 13:15:57 -0700 From: IETF Secretariat Archived-At: Subject: [Roll] Milestones changed for roll WG 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, 27 Aug 2021 20:15:58 -0000 Changed milestone "Initial submission of Common Ancestor Objective Functions and Parent Set DAG Metric Container Extension to the IESG", resolved as "Done". URL: https://datatracker.ietf.org/wg/roll/about/ From nobody Sun Aug 29 02:41:14 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 C92AE3A0A41 for ; Sun, 29 Aug 2021 02:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=TzGnEwE5; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=MF8doNB0 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 mNQWrp1c5H7l for ; Sun, 29 Aug 2021 02:41:01 -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 74D973A0A40 for ; Sun, 29 Aug 2021 02:41:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3502; q=dns/txt; s=iport; t=1630230061; x=1631439661; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=H7Y0NT9YwDHjbJlZUHhDZX5i+Iz+PPRRopsZWgwy4F4=; b=TzGnEwE5/07Bo1CRYrskKmoSH2yjyNb+x0JPrZJtq3bRk9liTSwArbN3 BDS2d5Rn8a8ppbtLJDzGq61+FLbAr5cG+Alz9JLfqVJ7k+hmzOhvQAP9C eR3u0R7FLFykY+42CEkVgRbMUgJn67DQCj7YeyvAxRaLyGxd2AVIMSHwX U=; X-IPAS-Result: =?us-ascii?q?A0D4BQD6VCthl4kNJK1aHgEBCxIMQIMsUX5aNzGER4NIA?= =?us-ascii?q?4U5iAYDjBODZ4pQglMDVAsBAQENAQEqCwwEAQGBeYIwRQIXghoCJTgTAQIEA?= =?us-ascii?q?QEBAQMCAwEBAQEFAQEFAQEBAgEGBBQBAQEBAQEBAYEIhWgNhkIBAQEBAgEBA?= =?us-ascii?q?RAREQwBASwMBAsCAQgYAgImAgICJQsVEAIEEyKCTwGCVQMOIQEOnnkBgToCi?= =?us-ascii?q?h96gTGBAYIIAQEGBASBNgETQUaCORiCNAMGgRAqgn+CdFNKhmonHIFJRIE8H?= =?us-ascii?q?IJmPoJiAQEChHU2gi6FfoFFBAMvIVtCNz9klQOoU4MrikCUHAUog2WLZpc2o?= =?us-ascii?q?lqTXwiEfwIEAgQFAg4BAQaBeCKBW3AVOyoBgj5QGQ+OIBmDWYUUhUp0AgE1A?= =?us-ascii?q?gYBCgEBAwmSQgE?= IronPort-PHdr: A9a23:WjFdRBcY23JuLsUO3ULhfh/ilGM/qYqcDmcuAtIPir9SfOKk5Zuxd EDc5PA4iljPUM2b7v9fkOPZvujmXnBI+peOtn0OMfkuHx8IgMkbhUosVciCD0CoLfP2YWo9B ssRHFNg9muwZE5SHsu2blbOo3q0uDgVHBi3NQd8KunvXIDIiMHi3OGp8JqVaAJN11KA IronPort-HdrOrdr: A9a23:dotCAK6d9hsNjoHKOAPXwWmBI+orL9Y04lQ7vn2ZFiY1TiXIra 6TdaoguiMc0AxhJE3I6urwR5VoJkmstKKdgLNhc4tKOTOHhILGFvAb0WKP+UyEJ8S6zJ8h6U 4CSdk/NDSTNykAsS+S2mDReLxMrKjlgcKVbKXlvg1QpGpRGsZdBnJCe3+m+zpNNW977PQCZf 6hz/sCgwDlVWUcb8y9CHVAdfPEvcf3mJXvZgNDLwI76SGV5AnYq4LSIly95FMzQjlPybAt/S zuiAri/JiutPm911v1y3LT1ZJLg9Hso+EzRvBky/JlbwkEuDzYI7iJaIfy+gzdZ9vfsWrCpe O85yvI+f4Ds085MFvF+icFkDOQrgrGo0WSuGNwx0GT+/AQgFkBepZ8bUUzSGqF16NohqAN7I tbm22erJZZFhXGgWD04MXJTQhjkg6urWMlivN7tQ0UbWIyUs4YkWUkxjIfLH7AJlOP1Kk3VO 11SM3M7vdfdl2XK3jfo2l02dSpGnA+BA2PTEQOstGcl2E+pgE082IIgMgE2nsQ/pM0TJdJo+ zCL6RzjblLCssbd7h0CusNSda+TmbNXRXPOmSPJkmPLtBLB1vd75rspLkl7uCjf5IFiJM0hZ TaSVtd8XU/fkr/YPf+laGjMiq9NllVeA6dhf22y6IJyIEUdYCbRhFrEmpe4PdIi89vd/HmZw == X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.84,361,1620691200"; d="scan'208";a="743076296" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Aug 2021 09:41:00 +0000 Received: from mail.cisco.com (xbe-rcd-003.cisco.com [173.37.102.18]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 17T9f0DB025790 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for ; Sun, 29 Aug 2021 09:41:00 GMT Received: from xfe-aln-005.cisco.com (173.37.135.125) by xbe-rcd-003.cisco.com (173.37.102.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Sun, 29 Aug 2021 04:40:59 -0500 Received: from xfe-aln-004.cisco.com (173.37.135.124) by xfe-aln-005.cisco.com (173.37.135.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Sun, 29 Aug 2021 04:40:59 -0500 Received: from NAM10-BN7-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.15 via Frontend Transport; Sun, 29 Aug 2021 04:40:59 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gaWAIWm2zEjk+csNgtizD8bELSl3nyyuJGRpZiwmqC5DRTQ9Z7LWzdRZMHrLeMTt8vp8X2wtZca9QGkEa/I0fxf5+mt9TehzW1G4dYFs+i5R82RG5ct/lezdgWwzDlTo8qH1fHbWzD8k/Bghl/A0jaoYTLpEFci9Po+FZOsDHZ37uIOy/r/shbAS4QkcZOTwPB/PvhQz0/y+wWPQiMv3KAv6nqCd9XE7fa6lFCGYrCcj0qUdOc6EgpLb0tdAANAWWQuhSPU3g2kUhpE1s73EVLCmG3BzkgAX5o2d4rsPbBKHfMFQ+8wg/+Pl7CHw33xA6dSvseI11F05zK7AAnhTEw== 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=H7Y0NT9YwDHjbJlZUHhDZX5i+Iz+PPRRopsZWgwy4F4=; b=kEo9dNiJBtaN05i3tjqMTzz3Wiz28aWRpvDt15zDI2wJlO28TGUiog3gPxSBDI+rq/k1MFUzn1oiHbRPgUu1xAuthVCTR9L1r4J9NBjYL/Mw4Q75Iy1G1vHQcdDuGwebRlA4WW80kQ5j7TFTH4//VJB3a4LH3ves5SetL+nERdmot8U1QhSeDZot2Z5eaXIcpcF39VHwY3T6n3M/QUpIE0EF5It+zpWGJMvQjJlRH2lAR0IUiXRXQJ141Xj0rBUoNkJd4Tgpkv6mkcW0eMYYiKldtM7lQ0csCAmFX4vutZK50VEzflKVr82Ho6i/Jw3SiQM/v5MHl1FZ4xVtCm7mFg== 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=H7Y0NT9YwDHjbJlZUHhDZX5i+Iz+PPRRopsZWgwy4F4=; b=MF8doNB02pdzVq6m7sL4m+UU1gban6BenXKk68vQk4OKOBGug2S7++mGdtJB8bdZwQZQ/8z+8A51dAAR6q21OygHP57RSutrPUMM+1xAUnRk8x8jQe42S0nrLlNp9BJhCKYTkIjpPhrHDDY1SrnaK4Dh1mt66yuKxp7bHuKyy5c= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MWHPR11MB2064.namprd11.prod.outlook.com (2603:10b6:300:27::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.22; Sun, 29 Aug 2021 09:40:57 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::b1cb:f7f8:b63e:b6ee]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::b1cb:f7f8:b63e:b6ee%6]) with mapi id 15.20.4457.023; Sun, 29 Aug 2021 09:40:57 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Review of draft-ietf-roll-dao-projection Thread-Index: AQHXmwk5APML4x4cU0Sn5jf1yiT0lquKPd0E Date: Sun, 29 Aug 2021 09:40:57 +0000 Message-ID: <42FCD4BA-3E56-4D86-ABDD-667CBED7D29D@cisco.com> References: <20210822051345.GA3910@iisc.ac.in> <24891.1629827443@localhost> <20210825164051.GA5889@iisc.ac.in> <31748.1629918032@localhost> <20210827060315.GA28747@iisc.ac.in> In-Reply-To: <20210827060315.GA28747@iisc.ac.in> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0ca3eef4-af94-482a-3271-08d96ad11a9e x-ms-traffictypediagnostic: MWHPR11MB2064: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Xl5U0L7eVlq9iOH0GCcDGrRuEbUXVR/i6gEes0B6bPszqmKW2jqpYFPmceWuz0+SRvpRsa77ypzGXpFkD3vRvrvpSGRFMndzJqXy6asyYe4ijeHULi/ESIufSO1pFiMOmoe+pwYv4iNm89KO1hTPatyHlKD+4Yxp2BpGM15Bk19HjiNg0yngbDmiQ3k+/j3txWFnTm5pEV7Xy4WPYnGL/YWYv4SWyy5v86BVS+56VMTU+oIVEJvs9iTGlH8E+5KRkgjhowQgguKXivk3Xzz48Mejny3yQiHU4vbRhjq6LNaVJr2AJ5WMV0s/3MAcHOnzcCpoyuWANCUP+YtnZ0NFlPUCnQdsnj00mGiiOOaSTqKGWkXKC0T2TTX2JAIbYMpcqnXukia3hmkOJH1vfj9RCwjiI3U44dTZp43SmNLqkuoZw+tbCCj5GTpWzsPF1YLjWunXVcYN1azZgAt901ki/EdVs9Xx3fpKpwOwAKVF5OqTBoaT6B38BS6HGSlGwbfjHQoSA8eNQW7FIJGClEOSgwm3l6jhz0oZdw5nmSjlqpuCkumIM7kYX6YRYrWx7k7YcQtG3/GkzkptEy2Sd/i2HffYPNEdaOtVNltIbNl0PSToToyMCEIXsB4zSewK36fu1LOXQMUZXl4lkA8CSQjzKIWTKgHQKtiKFzXKIwl0d9DDaPEGlHoO1J5c0bWf3vS/DtY5/pqMtSkBGUDGiZULAQ5hk0v8GoHge0P+H9RDklCiyXVpEEfuKSkglMRHwjfvggpAB951nJjmVzEMCZgXtsQmKqB9ztPjEQblRaFItSd0iy+IoA6s+UGvQruTcz0TuKE6RKvCJjYfiYRb12mNRR29XMPo3lLTfYEaURzGtxg= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB4881.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(396003)(376002)(39860400002)(366004)(346002)(36756003)(6916009)(478600001)(966005)(66476007)(316002)(2906002)(66446008)(33656002)(76116006)(8936002)(66556008)(6512007)(83380400001)(8676002)(86362001)(122000001)(6506007)(64756008)(66946007)(6486002)(91956017)(38100700002)(38070700005)(71200400001)(5660300002)(2616005)(66574015)(186003)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?SFl1UGxYRSt0UkRyM2laUDlWd0tzSmIvc0JrdkpCMjYxVktwMUNpU3RBU3Uv?= =?utf-8?B?ZC9NUnBhYlZrem5KS2VQcDhQWjJHNzQzaWhDM3MvVmVrcnliekJJb2NCcXdQ?= =?utf-8?B?TllvR3pNbEdzb085akFFUWIxWWJabWN3UGxkR0lyOGZNaUZTUW1ocTdWUmtK?= =?utf-8?B?Y1hwWVpxbjZZdkQyZmlUSEUwNXcvdW15RS9qdUpSUWpmamMrYTQyU2NBQ1JZ?= =?utf-8?B?dVplai9SM3c0ZWszdFJGeGNFSndxdFEvR0JKT1hsS1JJOExmeEZBaS9HWXQ4?= =?utf-8?B?VVVvV3JlVUsrRWh3d1VyTSsrUFVhZVBTeTJacFBRbG53QzhxcldDR0tMR2tC?= =?utf-8?B?cVVjRTh3QTNyM21iSkZVRGgzcjZ0WVI5TnZYdms5RmVhUTNlR2lDWjRJRHU3?= =?utf-8?B?dTdadGtsc25Fa1puSWluRllUb1M1UzNzR3Irdjdwb3cvVDZKNG5jWG1lMDMy?= =?utf-8?B?S1o5dW14cjNvMFVLWlBObzJ0T0VVTjh6MW1CanZxYkt2M2NvR1JnS0tReG1s?= =?utf-8?B?YktrOWg2OC9NQy81R1doSXRzcEtRYUVaeWVpMjljYThXWHErSzc5OXhkbEdn?= =?utf-8?B?WkxsVlVhajh2U0N5bWJKU3JFN3lpd0RsaE9TdTJQbmVjYlVLNHNoWWNnQ3ZQ?= =?utf-8?B?RkMxVUpNZm1ZRENGUkFmR1pLU1IrQXJmZm5jVE5zaGhKQy9tNWlyVHR4aFh3?= =?utf-8?B?VTdTRDB0bkUxa1E1elZHNHB2ZU1xOTh0eWt2R29xN2hlWDBNdTlhTThwNnow?= =?utf-8?B?VWpzdHg1UittTHZIbklTVThkSWpJSWRpakw1YzRES1hSbU1wRGlDVTlaK2di?= =?utf-8?B?SjVvMWxRZEtVcFh1V29zNW95WVpuNTRsZmFTbHpVNmlqalBDZm1hb0JsYWtr?= =?utf-8?B?alBqa0VGYThHbmZwRnkzaDZ4SmdTa0NZYzNBcmk2U2JmelN2emJORURXTzIr?= =?utf-8?B?enprV2FCNTNHMHduN3hrZWc3MDJCQmx5V0tOejZmQ2hCditkZGx0d3o4Y2N3?= =?utf-8?B?QVFNZG9SeUF3VXVJaVY0SnFPQXFsSmtGckpyOGlYVFAvSGlFRkt1RG5BZmQ4?= =?utf-8?B?YWhoOWNDdHYyOU45bGcybEx6cVRUcmlkQWJiaHhNQnNHV3hVVkZ0a09wUDBw?= =?utf-8?B?eVhxZk1uZ2l4aWVCYjBKMGpITkhEN3BabXdheGIvb2RMb2ZYRDhEUitSTmQ2?= =?utf-8?B?VFZiWGhYOVlESmQ2KzZtQm82bGxZRmVTTVJ5a1I1bUxDNERYOGZsaHduYzhF?= =?utf-8?B?cXlMdnhIeDhlMmw1dUE3K1NEb1RsV25WTklOSnhtaTdVcVczUEpTazdlQnor?= =?utf-8?B?ZUtXNDk4RzltQnVXSTNGaytCYjVMd2tHQ09OaGVUSlBnSXFKVWVLSUxxRG5x?= =?utf-8?B?MmFCNytXaWJ3NDdZYXhHTFFLR1pkNE5VMWJyWU55MU5LU0c3Sy9ERUE4OTM4?= =?utf-8?B?WVJvRm9aVVZ0bEJ1WHVHTXlUSTF0R3V6NHJxcWp5REMxNlFON21ZOVRrLzJh?= =?utf-8?B?SnE2dzlTaXROZ2VweUV0TWM5RlBjMXEvTEhXZFBoNHdlSExOQzNNTzdEbFRJ?= =?utf-8?B?SnBIcmNwN25weG81OXRFQ3VYVWw5aFZFSm9KcVdDZ2VqSGJicjIyNnhjZmk3?= =?utf-8?B?MWpJM1hGQXFJWmdObGpYdkRmNnpLWndEbXY3V0lhV2ZnY2Q5S0V3bmpvRkRu?= =?utf-8?B?a3RaRVUwZ1pERU1LbHRiRHVTS3ZaeFVSclA4THdWb3EwVENxOFc3SkRNdi84?= =?utf-8?B?V1M1NmhJTXBMblc4TmRHT0g1MCtMajl1V1ZUTHRtZW0zOEsvc1hVakxGaGpj?= =?utf-8?B?a1g2UEtaUk9KajMzaFh2RVJrWTFVK0I3SWF2ZnhBbTF5V1NFNXRYaldLS05S?= =?utf-8?Q?3QOa4SPGCNC2g?= 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: 0ca3eef4-af94-482a-3271-08d96ad11a9e X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2021 09:40:57.4928 (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: vqvBMv6ViZzPvanmFMsJkufkApWOM2PCehtXINXAyWJAxxpdthjZ8Cr7xH8XXyyLIhWFOyctevSAzoDgHXaFoA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB2064 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.18, xbe-rcd-003.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [Roll] Review of draft-ietf-roll-dao-projection 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: Sun, 29 Aug 2021 09:41:09 -0000 SGVsbG8gQW5hbmQsDQoNCkNlcnRhaW5zIHRoZSBtYWluIERBRyB3aWxsIHVuZGVyZ28gY2hhbmdl cyBhbmQgdHJhbnNpZW50IGxvY2FsaXplZCBmYWlsdXJlcy4gDQoNClNpbmNlIHRoZXJlIGlzIG5v IG9iamVjdGl2ZSBvZiBSQVcgb24gdGhlIG1haW4gREFHIHdl4oCZcmUgb2suIEluIHRob3NlIHRy YW5zaWVudCB0aW1lcyB0aGUgUm9vdCB3aWxsIG5vdCBiZSBhYmxlIHRvIHNlZSB0cm91YmxlIGlu IGEgVHJhY2sgYW5kIHRoZSBUcmFjayB3aWxsIGhhdmUgdG8gc3Vydml2ZSBvbiBpdHMgcmVkdW5k YW5jeS4NCg0KUlBMIGFscmVhZHkgZW5hYmxlcyByZWR1bmRhbmN5IGJldHdlZW4gdGhlIHJvb3Qg YW5kIGEgbm9kZSwgaXTigJlzIHVwIHRvIHRoZSByb290IHRvIHNlbGVjdCBvbmUgb2YgdGhlIHBv c3NpYmxlIHNvdXJjZSByb3V0ZSBwYXRoIHRoYXQgaXQgc2Vlcy4NCg0KSWYgdGhlIFJvb3QgY29t cGxldGVseSBsb29zZXMgY29ubmVjdGl2aXR5IHRvIGEgbm9kZSBpbiBhIFRyYWNrLCBpdCBtYXkg bm90IGJlIGFibGUgdG8gY2xlYW4gaXQgaW5zdGFudGx5IGJ1dCBpdCBjYW4gcm91dGUgYXJvdW5k IGl0LiBJIGhhdmUgYSBsb3Qgb2YgbmV3IHRleHQgb24gbWFpbnRlbmFuY2UgdGhhdCB3ZeKAmWxs IGRpc2N1c3MgaXQgYXQgdGhlIGludGVyaW0uDQoNCldoYXQgSSBkbyBub3Qgc2VlIGlzIHRoZSBu ZWVkIGZvciBleHRyYSB3b3JrIHRvIHByb3RlY3QgdGhlIHBhdGggZnJvbSB0aGUgcm9vdCB0byB0 aGUgbm9kZSwgYnV0IEkgYWdyZWUgdGhhdCB3ZSBjb3VsZCBpbmRpY2F0ZSB0aGF0IHRoZSBub2Rl IHNob3VsZCBhZHZlcnRpc2UgbW9yZSB0aGFuIG9uZSBwYXJlbnQgYW5kIHRoZSByb290IHNob3Vs ZCByZXRyeSBvdmVyIGRpdmVyc2UgU1IgcGF0aHMsIGlmIHRoYXTigJlzIHlvdXIgcG9pbnQ/DQoN ClBsZWFzZSBsZXQgbWUga25vdywgSeKAmWQgd2lzaCB0byBwdWJsaXNoIE1vbmRheSA6KQ0KDQpL ZWVwIHNhZmUsDQoNClBhc2NhbA0KDQo+IExlIDI3IGFvw7t0IDIwMjEgw6AgMDg6MDQsIFMuVi5S LkFuYW5kIDxhbmFuZHN2cj00MGlpc2MuYWMuaW5AZG1hcmMuaWV0Zi5vcmc+IGEgw6ljcml0IDoN Cj4gDQo+IO+7v0hlbGxvIE1pY2hhZWwsIGFuZCBhbGwsDQo+IA0KPiBBdCB0aGUgdGltZSBvZiB3 cml0aW5nIHRoZSBwYXBlciwgd2UgYWxzbyB3cm90ZSB1cCBmaXJzdC1jdXQgdmVyc2lvbiBvZiB0 aGUNCj4gZHJhZnQuIEJ1dCB3ZSBuZXZlciBnb3QgdG8gcHVibGlzaCBpdCBpbiBhbnkgb2YgdGhl IHdvcmtpbmcgZ3JvdXBzLg0KPiANCj4gSSB3aWxsIGJlIHZlcnkgaGFwcHkgdG8gc2hhcmUgdGhl IGRyYWZ0LCB3aGljaCBpcyBzdGlsbCBpbiB0aGUgbmFzY2VudCBmb3JtLCBhbmQNCj4gZ2V0IGlu aXRpYWwgZmVlZGJhY2sgb24gd2hldGhlciBpdCBpcyBzdWl0YWJsZSBmb3IgYW4gUkZDLg0KPiAN Cj4gUmVnYXJkcw0KPiBBbmFuZA0KPiANCj4+IE9uIFdlZCwgQXVnIDI1LCAyMDIxIGF0IDAzOjAw OjMyUE0gLTA0MDAsIE1pY2hhZWwgUmljaGFyZHNvbiB3cm90ZToNCj4+IA0KPj4gDQo+PiBTLlYu Ui5BbmFuZCA8YW5hbmRzdnI9NDBpaXNjLmFjLmluQGRtYXJjLmlldGYub3JnPiB3cm90ZToNCj4+ PiBJbiBvdXIgbGFiIHdlIGRldmVsb3BlZCBhbiBpbi1iYW5kIE9BTSB0ZWxlbWV0cnkgc2NoZW1l IGZvciBMTE5zIHRoYXQgd2UNCj4+PiBuYW1lZCBpdCBDby1pT0FNLiBUaGUgaWRlYSBpcyB2ZXJ5 IHNpbXBsZSBidXQgaXQgaGFzIGJlZW4gdmVyeSBlZmZlY3RpdmUNCj4+PiBpbiBtb25pdG9yaW5n IGEgcmVhbC13b3JsZCBkZXBsb3ltZW50IG9mIFJQTC82TG9XUEFOIG5ldHdvcmsgdGhhdCB3ZQ0K Pj4+IHNldHVwLg0KPj4gDQo+Pj4gWyJDby1pT0FNOiBJbi1zaXR1IHRlbGVtZXRyeSBtZXRhZGF0 YSB0cmFuc3BvcnQgZm9yIHJlc291cmNlIGNvbnN0cmFpbmVkDQo+Pj4gbmV0d29ya3Mgd2l0aGlu IElFVEYgc3RhbmRhcmRzIGZyYW1ld29yayIsDQo+Pj4gaHR0cHM6Ly9pZWVleHBsb3JlLmllZWUu b3JnL2Fic3RyYWN0L2RvY3VtZW50LzgzMjgyNzZdDQo+PiANCj4+IEJlaGluZCBhIHBheXdhbGwu DQo+PiBJcyB0aGlzIHN1aXRhYmxlIGZvciBhbiBSRkM/DQo+PiANCj4+IA0KPj4gLS0NCj4+IE1p Y2hhZWwgUmljaGFyZHNvbiA8bWNyK0lFVEZAc2FuZGVsbWFuLmNhPiAgIC4gbyBPICggSVB2NiBJ w7hUIGNvbnN1bHRpbmcgKQ0KPj4gICAgICAgICAgIFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3JrcyBJ bmMsIE90dGF3YSBhbmQgV29ybGR3aWRlDQo+PiANCj4+IA0KPj4gDQo+PiANCj4gDQo+IA0KPiAN Cj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBS b2xsIG1haWxpbmcgbGlzdA0KPj4gUm9sbEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBSb2xsIG1haWxpbmcgbGlzdA0KPiBSb2xsQGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0K From nobody Sun Aug 29 03:27:27 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 92F103A0791 for ; Sun, 29 Aug 2021 03:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 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, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iisc.ac.in 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 mKaEdwFI7JNN for ; Sun, 29 Aug 2021 03:27:17 -0700 (PDT) Received: from IND01-BO1-obe.outbound.protection.outlook.com (mail-eopbgr1390085.outbound.protection.outlook.com [40.107.139.85]) (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 8855A3A0789 for ; Sun, 29 Aug 2021 03:27:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LIwWiSEaqQxEQEHS7cwFx6mokVKLhL7FYjiaJiLE2deL09daZS/9qA3NYbOQigB/8qy6NhGYmKNZRpry+PgT8W/itytrJ50CPpbxWn9PWv6zt8N87tZHmAkWrdYuUFSeM+mcYFelLPoezo115T1uORJxa/W2fsmlxOJ9hTnB8l46OgcaNtGtz4RS36g7x3wwNfUnFF3cc4r7K+XN8LitwBTJyLz+VHBTem6wTH72aDYsoiyXq3DRw0Un2ZebwKw7kw8WdkE3WVZLcXmwdI7Km/TbdZE3oxxrwwopd715lg6wdtsprSFYlSVltQjGSlOQaXuJTydQ2Fj8dqDKU3WvNw== 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=udhyyL0TJQN/wvIFk/kNBYeE3sbS3Wj6COIwjM0l454=; b=dEgFmUGg0kQ9akM8G0JWuNzuJW/QhLOlRxrt4fDa/PCGdZCHSVvZo6H9QmQ13/+Zxd1UjbVw6941UEeF/m2T4dZ3Wng+aKV4TL7TeH7rdE7H+B5Vl+fNTaiHJng7nIl5BOVcpAEPtiSSefVU/m116mGH1mluBE4UE9KuFrPeXZKwQeVtlTUqfbj/qBpbuWULGll8THOwSTC8TJNzimRhbyXe7XpFoJ5TW1CrtA3sw586LOMP9VqQfFcOLEFD2MM0pnM7OnVdLb6Vs1soIPwJmMDxY69Nn9AMxWTpSEyNILV7TY3q3O2AFeZuM54z1n+cwYcYt5anWHYAluQYR0fuFw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iisc.ac.in; dmarc=pass action=none header.from=iisc.ac.in; dkim=pass header.d=iisc.ac.in; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iisc.ac.in; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=udhyyL0TJQN/wvIFk/kNBYeE3sbS3Wj6COIwjM0l454=; b=B7zNOX3K/VonexETPz+rJujWg0pnA2Qi/IWIfP846pJp29duwSBYWlJiJ8E61sWHrnfRImegkxeO/pihVOhNcYYEIFJKnDgPXTv/HOr9Ol5P0zc71ZL27wxThawBmPCJev5B2hb9PsVMpcG+2g+F3lfMdDI1OUYg5xBraEq5wzM= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=iisc.ac.in; Received: from MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:37::23) by MA1PR01MB0956.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:3::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.17; Sun, 29 Aug 2021 10:27:08 +0000 Received: from MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM ([fe80::6096:2bb9:fc3a:cd39]) by MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM ([fe80::6096:2bb9:fc3a:cd39%5]) with mapi id 15.20.4457.024; Sun, 29 Aug 2021 10:27:07 +0000 Date: Sun, 29 Aug 2021 15:57:05 +0530 From: "S.V.R.Anand" To: Routing Over Low power and Lossy networks Message-ID: <20210829102704.GA3466@iisc.ac.in> References: <20210822051345.GA3910@iisc.ac.in> <24891.1629827443@localhost> <20210825164051.GA5889@iisc.ac.in> <31748.1629918032@localhost> <20210827060315.GA28747@iisc.ac.in> <42FCD4BA-3E56-4D86-ABDD-667CBED7D29D@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <42FCD4BA-3E56-4D86-ABDD-667CBED7D29D@cisco.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-ClientProxiedBy: MAXPR0101CA0055.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:e::17) To MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:37::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from iisc.ac.in (49.206.10.139) by MAXPR0101CA0055.INDPRD01.PROD.OUTLOOK.COM (2603:1096:a00:e::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.17 via Frontend Transport; Sun, 29 Aug 2021 10:27:07 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: cb92f8c0-5811-41df-6dbf-08d96ad78d5f X-MS-TrafficTypeDiagnostic: MA1PR01MB0956: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Dw7uA6Subh9bBnylPiBmLqYVutU+45afCQdfWySEHq+6UQBCC3FNYcmpudhewgdQxr6OtOONTYV7zni5gCDvirYlon1dfAUeaCq2UwTPFt+4mI3PT42UbrsJqUCB5NliTqKw56zaAqUhkxDT3sNTLU8SE75RZG2ijOdAqK/pgcaYiLxX5DuMLKFR+n3eRd5rMIY0/8j0CC3WzkMxMo/sRYcqMs1ByLrgTn2X8nquh67CwQkQpb1Y60YSryoFoXcdvfQSwvyXeRzCd6GYVnBIptR/Gq0uMPDFoUWzF4N8FInhgQSK+0jVpAln5jFfHDXcBQEEvjjQAoEEECcC0JdamFvWC8/fvYz0Fjy+zaps5eoTuA5gicVUwiWJOjhEpu6apjamSRYBhFNeaypkixVhS7+XR73UdX2hKvxB1GkiedhwQyXWskq4rBVaK/wcjWhYLKi7WYUa7Htj37cC1rpcMLYGCW/c7Wjtuq2zl4vZKcdOz/SbIuf74A8kZPOsJ5CyiYab6TR2OL/0B0dZrJXdf6q7Fjb2wIriJkPURTDErL/mKbYrfWjoglOY62PmWL9LfGJYn9z78Kp8EMES6vp/QQPq0J1VK1fuSDmsUBtVXo+GIutMvOZJ0V1ddAX9qQlJ/RRJvDZnB+l++H0FFM5Pcfl46HUJb1rusrA+bbVP7UdDYCbDDmfZHK1MVnx32jpCL0G09Txxt2G3ja/UE2/lEQxTuqUO9d7hbFtoWVdAe+qcjqX2ROV5hI9Aln7wY6BLDYKvncorCpIdPXsXmjtl1w== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(376002)(346002)(136003)(366004)(396003)(39850400004)(1006002)(52116002)(7696005)(5660300002)(8936002)(83380400001)(786003)(186003)(53546011)(66574015)(33656002)(55016002)(1076003)(55236004)(36756003)(316002)(2616005)(956004)(2906002)(86362001)(8676002)(38350700002)(6916009)(38100700002)(26005)(66946007)(66556008)(66476007)(478600001)(966005); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Wi9pYVIxRGhhN0xIc1F5RWRpbUtLMi9PSEV3cDg1MVE0ckNnRHdLSTlpUGpR?= =?utf-8?B?eWR3R2ZnSk1yeEFuR1FMU3JvbjVndXFEYjU2UFdWVmphSHVocTZmQjVJR1Uz?= =?utf-8?B?eHAvSVZ4eFNGeWdBWlNRdG5Bb2xZRGFPbHBjYWYvR1NUQmxmd2ROaDNRZUFx?= =?utf-8?B?ZC84YkNkL04vMFcydXJ3ajh1eCswODhRWkRtZ2ZjUUFEMlR5YjRWZ1dNUGhq?= =?utf-8?B?bWZmbUh0cFpTclE5SStPakt3UkRTMXphakVyWDFyQXY2Z2xoY21xKzFHRHMv?= =?utf-8?B?Sk9xTmgvbmszRXFNamZHTEloRFhCaHVNWUZoT2lJd0FJVTd2NVh0dHVHb1V4?= =?utf-8?B?TjFxUzBUdWZqbFQrMkd6K0MzaVFGdVI1SjRxcjZiYkxNZmMrSFRTWkdXTGV6?= =?utf-8?B?NXJaa091c0dqWDVIRjFzUU9GNGl4SStxaTk0d2lMbjJaRTFkeDc5QXJ6N1E4?= =?utf-8?B?MnFnTFZ6a0xLek1NNm0wR2RxckN6UEN6MGVDaW15OWZuM05XdFRQVlJGYnAw?= =?utf-8?B?Qllad1d4b3dlQ1pKeTZrTFdMUEZ1WHVrbmhZU0JpRWVjZVpvdkl6WEEyaUZs?= =?utf-8?B?NWUyNFUwemRHMVdDR0dXUWxBRHNZSmg5cEdaVENGdnhDcHRzYjlHVWhpS0V1?= =?utf-8?B?UHYrN1FZZGdENlJPV0R3YVNzTlQ5L0duNmloQTJmdTVYVjNJdDZKZ2VOcmpt?= =?utf-8?B?d1poRVo4NVFQcTZNdXBQRVNJQjlFa0MyZ0gvNGRGcTFCVlRYN1B0NHlZTjdp?= =?utf-8?B?RklTdXhKZElSR2NXZmhoUDFFbm11K0VIaHdzandqVGdvZjJESkVSbDhmdlJC?= =?utf-8?B?b1IrL081OThSeW1UWEpBNnlMTGh0c2kwUTc5bWtaQksybzFvS0xSVVZpOGxw?= =?utf-8?B?ZW10UGRyM3hYQTBJS2xkUjZTalVwNU1hZVFPUlUrMXhXbk00RVlEMGRyZ3E3?= =?utf-8?B?UEN4TWtXUlVMZ2VQNmZkTUxGWm5keDB0SXl1T2FRZzBTOU81U3VET3hvY0xY?= =?utf-8?B?STJzSzh1OGNvRkRPdG5kVnk5YklYSEg0Tk5rNHF2OGZFSjR2WUcrUTdldFJN?= =?utf-8?B?MmVoWW1tbWJYYnpXQk14bXpraFlXOThqcHJkUit0c0dTZ2ZCRFBTdEZmTmt6?= =?utf-8?B?K3MySkIxOWg4SWFmcGxHTFNtZCtxcmJBcmVXanVSb1BlVkZnSHZjbytHb2dY?= =?utf-8?B?bEZCMzV5RnpOKzdxNGVNY1NzV0RKeERuaHh0YjNwKzZqSkV5MTlRVmIyWmFH?= =?utf-8?B?ZGRlQkdSWXR6V0VnemFTcU81L3hqTUhjWTJsTG1rRGVhNldZSTZHQUMxYXRE?= =?utf-8?B?VXBtSlVwbEtWT1lmeUlpV1IrSGw2dVQ5RUQxMU8ydHdVcHdDcDd1aTRLQ3Z6?= =?utf-8?B?MHVERVRrMGZORWZ0NHV3MUhuS1R6aDN6R1NYb3N0b3VKR3plUGhzWU9wOVpY?= =?utf-8?B?RDdjakM2c3cvYUxTcjZKNGR5ZStyTkRrekJkUW1pRDk4SzdUVXg3ckZncFNM?= =?utf-8?B?RXJheXdJVnhXeXdkUlRUTEJTS0xwWXZUM0FMdXlybC9uSm96MWZQMG5CVnFl?= =?utf-8?B?V3hDNkh5eE5nSXJ5ZDRWUUs3MDVNSE00RVNENFJEYTdaL3lXZVpmM1g1c2hV?= =?utf-8?B?aFlCSm9BWDR1TzBHeENTbVBFbFJvdWtoUE5qdGlMN1h0U1l3bGNkRFU1Nnhu?= =?utf-8?B?U2dLOEZ5RjJkZ0pHMzFEYmRROUtyandQaEYwM2JnZ2w2VVZVRWFHcmJSdWJD?= =?utf-8?Q?iKPOnZSbaj4L97LP0ntWaS6ZgkLHEidZTaMEoQV?= X-OriginatorOrg: iisc.ac.in X-MS-Exchange-CrossTenant-Network-Message-Id: cb92f8c0-5811-41df-6dbf-08d96ad78d5f X-MS-Exchange-CrossTenant-AuthSource: MA1PR01MB2218.INDPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Aug 2021 10:27:07.3399 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 6f15cd97-f6a7-41e3-b2c5-ad4193976476 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: P8TH2TmmCPkivYn4P0ZZ6/gDB28Ip/oHt/bcihvOXJd5n10mPVZ+1DcRc65Ntmke43anO2l71SIIm4nyXNBJow== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MA1PR01MB0956 Archived-At: Subject: Re: [Roll] Review of draft-ietf-roll-dao-projection 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: Sun, 29 Aug 2021 10:27:25 -0000 Hello Pascal, Thank you very much for addressing my concern and you can proceed with the publication without further delay :) > What I do not see is the need for extra work to protect the path from the root to the node, but I agree that we could indicate that the node should advertise more than one parent and the root should retry over diverse SR paths, if that’s your point? > Yes, the above indicative text will be very helpful as we are not ignoring the coupling effect. While the draft need not go into the specifics of all the possibilties, I feel bringing out the core issue is important. Regards Anand On 21-08-29 09:40:57, Pascal Thubert (pthubert) wrote: > > > Hello Anand, > > Certains the main DAG will undergo changes and transient localized failures. > > Since there is no objective of RAW on the main DAG we’re ok. In those transient times the Root will not be able to see trouble in a Track and the Track will have to survive on its redundancy. > > RPL already enables redundancy between the root and a node, it’s up to the root to select one of the possible source route path that it sees. > > If the Root completely looses connectivity to a node in a Track, it may not be able to clean it instantly but it can route around it. I have a lot of new text on maintenance that we’ll discuss it at the interim. > > What I do not see is the need for extra work to protect the path from the root to the node, but I agree that we could indicate that the node should advertise more than one parent and the root should retry over diverse SR paths, if that’s your point? > > Please let me know, I’d wish to publish Monday :) > > Keep safe, > > Pascal > > > Le 27 août 2021 à 08:04, S.V.R.Anand a écrit : > > > > Hello Michael, and all, > > > > At the time of writing the paper, we also wrote up first-cut version of the > > draft. But we never got to publish it in any of the working groups. > > > > I will be very happy to share the draft, which is still in the nascent form, and > > get initial feedback on whether it is suitable for an RFC. > > > > Regards > > Anand > > > >> On Wed, Aug 25, 2021 at 03:00:32PM -0400, Michael Richardson wrote: > >> > >> > >> S.V.R.Anand wrote: > >>> In our lab we developed an in-band OAM telemetry scheme for LLNs that we > >>> named it Co-iOAM. The idea is very simple but it has been very effective > >>> in monitoring a real-world deployment of RPL/6LoWPAN network that we > >>> setup. > >> > >>> ["Co-iOAM: In-situ telemetry metadata transport for resource constrained > >>> networks within IETF standards framework", > >>> https://ieeexplore.ieee.org/abstract/document/8328276] > >> > >> Behind a paywall. > >> Is this suitable for an RFC? > >> > >> > >> -- > >> 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 > > > > _______________________________________________ > > 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 Sun Aug 29 15:26: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 40B433A1B0D; Sun, 29 Aug 2021 15:26:52 -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, HEADER_FROM_DIFFERENT_DOMAINS=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 pJefKGLQsGlM; Sun, 29 Aug 2021 15:26:40 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 069E53A1B06; Sun, 29 Aug 2021 15:26:34 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 93B40548053; Mon, 30 Aug 2021 00:26:20 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 88FC34400EF; Mon, 30 Aug 2021 00:26:20 +0200 (CEST) Date: Mon, 30 Aug 2021 00:26:20 +0200 From: Toerless Eckert To: Routing Over Low power and Lossy networks , draft-ietf-roll-dao-projection.all@ietf.org Message-ID: <20210829222620.GA6858@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [Roll] IOTdir Review of draft-ietf-roll-dao-projection-19 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: Sun, 29 Aug 2021 22:26:52 -0000 draft: draft-ietf-roll-dao-projection-19 Review-source: IOTdir Reviewer: Toerless Eckert Review result: Technology ready, Text has various issues, mostly difficult to understand. Dear Authors Thanks a lot for this work. This is cool technology, it has the ability to provide very flexible and wide range of path steering and header optimizations for RPL networks. Overview: I am not sure i understand all finer details due likely to some impedance mismatch between the expected RPL expertise of the text and mine, but i think that the proposed technology is sound and has on the technoloy (not text) side only few details that may need to be added (missing guidance or references on timers, maybe MTU handling if that is not supposed to be well-known, etc.). If there is any technological gap, then it is me hoping that this could be a solution for the RFC8994 A.9.4 problem, but alas this solution does not support establishment of additional routes for storage mode DODAGs. Too bad. Especially because its not quite clear to me why that would not be possible to easily do as well. But in understand how that RPL profile may not have been of any interest for this work. As i am not an expert for RPL, but mostly familia with only basic use of RPL, i am not sure how much of an expert a reader of this document is expected to be to be able to read, understand and vet this text. I think i and other RPL beginners would be able to understand the text and vet potential gotches better if more explanations where given, and my feedback indicates this accordingly. But i will not claim whether such explanations are always deemed necessary for the target audience. The mayor issue in the text is that it front-loads a lot of details that are then hard to understand and open questions are only answered much later. For example, packet encoding is put first in the document, as opposed to (as i have observed it in more RFCs) at the end. Then the text follows with processing description, and only finally with what i consider to be a complete description of how the pieces interact through examples. As mentioned in the details, i think the order should be as much as possible top-down, starting with sufficienly complex examples that introduce the technology to the extend that the main concepts are used in the example. E.g.: sequential or complex track, sements, destinations, targets. I only performed very opportunistic spell check, please do one yourself. Please run idnits check too, it complains about the abstract for me. Appended draft with numbered lines and non-numbered line feedback/comments. Cheers & thanks again Toerless 5 ROLL P. Thubert, Ed. 6 Internet-Draft Cisco Systems 7 Updates: 6554 (if approved) R.A. Jadhav 8 Intended status: Standards Track Huawei Tech 9 Expires: 28 January 2022 M. Gillmore 10 Itron 11 27 July 2021 12 13 14 Root initiated routing state in RPL 15 draft-ietf-roll-dao-projection-19 ... 135 1. Introduction 136 137 RPL, the "Routing Protocol for Low Power and Lossy Networks" [RPL] 138 (LLNs), is a generic Distance Vector protocol that is well suited for 139 application in a variety of low energy Internet of Things (IoT) 140 networks. RPL forms Destination Oriented Directed Acyclic Graphs 141 (DODAGs) in which the Root often acts as the Border Router to connect 142 the RPL domain to the Internet. The Root is responsible to select ^^^^^^^^^^^^^^^ Really ? What is the "often" case where e.g.: at least nodes in the RPL network can reach nodes across the Internet ? Aka: from my understanding, the common deployment would attach to other limited domain (RFC8799) networks, for example if i correctly glean from rfc9030, but not "the Internet". Otherwise, please provide a reference to justify "often ... to the Internet". Aka: suggest to replace Internet with "other network" or maybe "a backbone". 142 the RPL domain to the Internet. The Root is responsible to select 143 the RPL Instance that is used to forward a packet coming from the 144 Internet into the RPL domain and set the related RPL information in Same comments about "the Internet". 147 The "6TiSCH Architecture" [6TiSCH-ARCHI] also leverages the 148 "Deterministic Networking Architecture" [RFC8655] centralized model 149 whereby the device resources and capabilities are exposed to an 150 external controller which installs routing states into the network 151 based on some objective functions that reside in that external 152 entity. With DetNet and 6TiSCH, the component of the controller that The DetNet architecture has a lot more aspects for which i am not sure, that 6TiSCH matches them (have not gone fully through 6TiSCH-ARCHI). Aka: DetNet as of today implies the per-hop,per-flow IntServ architecture, but no DiffServ for DetNet service hops. Is this what 6TiSCH-ARCHI does as well ? If not, then maybe change to "levereges the aspects of the ..." to make the claim more scoped to what the paragraph describes. 152 entity. With DetNet and 6TiSCH, the component of the controller that 153 is responsible of computing routes is called a Path Computation 154 Element ([PCE]). 155 156 Based on heuristics of usage, path length, and knowledge of device 157 capacity and available resources such as battery levels and 158 reservable buffers, the PCE with a global visibility on the system 159 can compute direct Peer to Peer (P2P) routes that are optimized for 160 the needs expressed by an objective function. This document "Based on heuristics" has one doubt whether the result is deerministic. Not saying heuristics may not play a role, but maybe fnd a better wording. "global visibility" sounds like weather satellites. More specifically when reading, i wonder if the scope of the discussion in this document can be constraint to a single RPL network, or if it is important to understand that the mechanisms of this document a also enabling more "interesting" paths. Aka: If the following is one of the cases for which this drafts work is in support of, then i would really like to see this type of picture and explanation added as something like a reference picture with explanation: Client11 Client21 ClientN1 | | | PCE RPL-network1 RPL-network2 RPL-networkN | Root1 Rtr1b Root2 Rtr2b ... RootN RtrNb | | | | | | | .................................................................. Backbone Network, L2 / L3, e.g.: -+----------+---------+----------+--------+-----------+-------+---- Aka: The PCE can calculate paths between clients in this internetwork. An example path between Client11 and ClientN1 is composed of the projected path between Client11 and one of the nodes connecting RPL-network1 to the backbone, e.g.: Rtr1b, a path through the backbone, and finally a path through RPL-networkN, again including the choice of edge router to the backbone, e.g.: RtrNb. I guess if the solution does not support RtrIb, then its explanation could more easily be constrained to just a single RPL-network. 160 the needs expressed by an objective function. This document This statement is confusing. Without this draft, the objective functions result in specific paths, and these paths are insufficient, so the PCE also uses this drafts mechanism to achieve better paths. So the objective function clearly was not sufficient. Besides, the objective function is very specific to parameters used in distributed path calculation, not PCE. In my mind, there is some goal/objective for the path to be calculated, and this objective is achieved by OF to create DODAG and paths, and if those paths are insufficient, then and a controller can achieve that objective by defining a but when the controller determinses that it can not solely be achieved through objective function parameters, then it starts using this drafts mechanism... 160 the needs expressed by an objective function. This document Suggest new paragraph before "This" 161 specifies protocol extensions to RPL [RPL] that enable the Root of a 162 main DODAG to install centrally-computed routes inside the DODAG on 163 behalf of a PCE. 172 173 This specification expects that the main RPL Instance is operated in 174 RPL Non-Storing Mode of Operation (MOP) to sustain the exchanges with 175 the Root. In that Mode, the Root has enough information to build a ^ Only ? 176 basic DODAG topology based on parents and children, but lacks the ^ still 177 knowledge of siblings. This document adds the capability for nodes Aka: in storing mode the root would even have less information, right ? 178 to advertise sibling information in order to improve the topological 179 awareness of the Root. 180 181 As opposed to the classical RPL operations where routes are injected 182 by the Target nodes, the protocol extensions enable the Root of a 183 DODAG to project the routes that are needed onto the nodes where they 184 should be installed. This specification uses the term Projected 185 Route to refer to those routes. Projected Routes can be used to 186 reduce the size of the source routing headers with loose source 187 routing operations down the main RPL DODAG. Projected Routes can 188 also be used to build transversal routes for route optimization and 189 Traffic Engineering purposes, between nodes of the DODAG. 190 191 A Projected Route may be installed in either Storing and Non-Storing 192 Mode, potentially resulting in hybrid situations where the Mode of 193 the Projected Route is different from that of the main RPL Instance. 194 A Projected Route may be a stand-alone end-to-end path or a Segment 195 in a more complex forwarding graph called a Track. 197 The concept of a Track was introduced in the 6TiSCH architecture, as 198 a potentially complex path with redundant forwarding solutions along 199 the way. Please add a reference to the spec that introduced Track. Where is "stand-alone" introduced ? If elswhere, add reference, otherwise say its introduced here. Also, everything else is capitalized, maybe you want to capitalize also Stand Alone. 199 With this specification, a Track is a DODAG formed by a RPL 200 local Instance that is rooted at the Track Ingress. If there is a 201 single Track Egress, then the Track is reversible to form another 202 DODAG by reversing the direction of each edge. A node at the ingress 203 of more than one Segment in a Track may use one or more of these 204 Segments to forward a packet inside the Track. The last sentence is using the term Segment to explain something new, but the term Segment was not sufficiently defined in before. Other than that a Segment can be or is always (?) a Projected Route, but Projected Route is also undefined. 206 The "Reliable and Available Wireless (RAW) Architecture/Framework" 207 [RAW-ARCHI] defines the Path Selection Engine (PSE) that adapts the 208 use of the path redundancy within a Track to defeat the diverse 209 causes of packet loss. 210 211 The PSE is a dataplane extension of the PCE; it controls the 212 forwarding operation of the packets within a Track, using Packet ARQ, 213 Replication, Elimination, and Overhearing (PAREO) functions over the 214 Track segments, to provide a dynamic balance between the reliability 215 and availability requirements of the flows and the need to conserve 216 energy and spectrum. 217 218 The time scale at which the PCE (re)computes the Track can be long, 219 using long-term statistical metrics to perform global optimizations 220 at the scale of the whole network. Conversely, the PSE makes 229 forwarding decisions at the time scale of one or a small collection 230 of packets, based on a knowledge that is limited in scope to the 231 Track itself, so it can be refreshed at a fast pace. I would suggest to restructure this. Before going into the RPL details as you do in before, maybe start with the problem to be solved. Which seems to be a mechanism to support packet replication, traversal over alternative paths and duplicate elimination (and seemingly more). 6TiSCH introduced Tracks as the concept for redundant paths, RAW inroduced PAREO. This document introduces one solution to to build Tracks with RPL und a mechanism called Projected Routes. Something like that to have a more logical sequence of explanations, top to bottom. 233 Projected Routes must be used with the parsimony to limit the amount Parsimony in he sense you use it, was never used in RFCs, rc871 used law of parsimony. Suggest to reword for easier reading. For example, "Care must be taken that state installed for projected routes fit in each devices resources". Is the amount of traffic solely a responsibility of the installation of projected routes ? Isn't this also responsibility of the PSE ? (just guessing, haven't read up on it). 234 of state that is installed in each device to fit within the device 235 resources, and to maintain the amount of rerouted traffic within the 237 capabilities of the transmission links. The methods used to learn 237 the node capabilities and the resources that are available in the 238 devices and in the network are out of scope for this document. 239 240 This specification uses the RPL Root as a proxy to the PCE. The PCE 241 may be collocated with the Root, or may reside in an external 242 Controller. 243 244 In that case, the PCE exchanges control messages with the Root over a ^^^^ the latter 245 Southbound API that is out of scope for this specification. The ^ PCE 246 algorithm to compute the paths and the protocol used by an external 247 PCE to obtain the topology of the network from the Root are also out 248 of scope. In his AD review for draft-ietf-bier-te-arch, Alvaro asked me to provide examples for such topology discovery. YOu can of course wait out if this will happen for his doc too, i personally have no strong opinions, but if you need example text, see draft-ietf-bier-te-arch, 3.2.1.1, Third paragraph. Personally, i do not like the conditioning that a southbound API is supposedly only necessary when the PCE is external from the RPL Root. IMHO, there always needs to be at least an informat model for Projected Routes. Which you may agree on, but its not mentioned. PCE and RPL Root can just be independent software entities on the same node. 260 2.2. Glossary 261 262 This document often uses the following acronyms: 263 264 CMO: Control Message Option 265 DAO: Destination Advertisement Object 266 DAG: Directed Acyclic Graph 267 DODAG: Destination-Oriented Directed Acyclic Graph; A DAG with only 268 one vertex (i.e., node) that has no outgoing edge (i.e., link) 269 LLN: Low-Power and Lossy Network 270 MOP: RPL Mode of Operation 271 P-DAO: Projected DAO 272 P-Route: Projected Route 273 PDR: P-DAO Request 274 RAN: RPL-Aware Node (either a RPL Router or a RPL-Aware Leaf) 275 RAL: RPL-Aware Leaf 276 RH: Routing Header 285 RPI: RPL Packet Information 286 RTO: RPL Target Option 287 RUL: RPL-Unaware Leaf 288 SIO: RPL Sibling Information Option 289 SR-VIO: A Source-Routed Via Information Option, used in Non-Storing- 290 Mode P-DAO messages. 291 TIO: RPL Transit Information Option 292 SF-VIO: A Via Information Option, used in Storing-Mode P-DAO 293 messages. 294 VIO: A Via Information Option; it can be a SF-VIO or an SR-VIO. I had a hard time remembering SR-VIO and SF-VIO throughout the text. Maybe SM-VIO and NSM-VIO would be easier to remember and better because they explicitly refer to the explanation (Storing Mode, Non-Storing Mode). I'll spare you the request for a full Terminology section for these terms with references, maybe others will do so. It would make sense though to move the terms newly introduced in this doc, such as P-Route , P-DAO and the like into section 2.3 and rename 2.3 to "New terms". Derived terms like P-Route can of course stay concise. 296 2.3. Other Terms ... 327 3. Extending RFC 6550 You have tagged this draft as an Update to RFC6550. You should IMHO have a section where you summarize what that exactly entails, ideally call "Updated to RFC6550". AFAIK, we do not have a good formal structure for such update description, Mirja tried to propose some more keywords, but so far, Update can mean anything. I would suggest to summarize what type of update this is by making statements answering the following type of questions (maybe i forgot some). These statements are also useful when they are answering the questions below with No. I leave it up to you if you feel this would be good to go here in the beginnin, or if you'd rather want to summarize it in the end of the document. Questions: Does this document specify any functionality that is REQUIREDS or RECOMMENDED for implementations of RFC6550 ? If so, please detail them. Else, this can be called a fully OPTIONAL update for RFC6550. Will implementations supporting this RFC continue to be backward compatible with all prior RFCs, RFC6550 and related ? If not, please describe any changes in interoperability. Does this RFC introduce any functional extensions to RFC6550 or other RFC through mechanisms other than pre-defined extension points ? Are any pre-defined extension points of RFC6550 or other RFC used, which are not already IANA registries ? If so, please include references to the original RFC section where that extension point was described. (first time i am trying to formalize these type of question...) IMHO outside the scope of documenting the "Update" flag is mixed deployment. If there is no text for that, would be good to add that somehwere. Update section wouldn't be a bad place. 341 3.1. Projected DAO At this point i am worried whether i am correctly guessing at the forwarding plane behavior of projected routes, because i felt it was presented in the Intro section mostly en-passant, but it is hard to follow the document with the correct explanation of how forwarding works. What i figured from the Intro is that Projected Routes would allow the root to specify a loose path in the RH, even though only non-storing mode is used. Whenever a RPL node then sees a next-op in the RH it looks for a projected Route towards that next-hop and hmm... just forwards the packet to the first next hop on the projeted route ? Or it needs to change the routing header to prepend the projected route ? And i have absolutely no idea what interactions there are between PSE and Projected routes in the forwarding plane.. Section 9 has some signalling examples. Maybe it would be good to create some introductory example that shows the relevant forwarding plane aspects. 343 Section 6 of [RPL] introduces the RPL Control Message Options (CMO), 344 including the RPL Target Option (RTO) and Transit Information Option 345 (TIO), which can be placed in RPL messages such as the Destination 346 Advertisement Object (DAO). 346 This specification extends the DAO 347 message with the Projected DAO (P-DAO); a P-DAO message signals a 348 Projected Route to one or more Targets using the new CMOs presented 349 therein. This is confusing. If i am guessing right, i would suggest to write: This specification defines a new CMO carrying a Projected Route. When this Projected Route CMO is included in a DAO message, this is called a Projected DAO (P-DAO). I do not get the "signals _a_ Projected Route to one or _more_ Targets". How can a single P-DAO be signalled to more than one recipient ? 349 This specification enables to combine one or more Projected 350 Routes into a DODAG called a Track, that is traversed to reach the 351 Targets. 352 353 The Track is assimilated with the DODAG formed for a Local RPL 354 Instance. The local RPLInstanceID of the Track is called the 355 TrackID, more in Section 7.2. A P-DAO message for a Track signals 356 the TrackID in the RPLInstanceID field. The Track Ingress is 357 signaled in the DODAGID field of the Projected DAO Base Object; that 358 field is elided in the case of the main RPL Instance. The Track 359 Ingress is the Root of the Track, as shown in Figure 1. How about the text here first finishes up the specification of the P-DAO CMO before explaining some, but likely not all details of how this stuff works together ? 360 361 This specification defines the new "Projected DAO" (P) flag. The 'P' 362 flag is encoded in bit position 2 (to be confirmed by IANA) of the 363 Flags field in the DAO Base Object. The Root MUST set it to 1 in a 364 Projected DAO message. Otherwise it MUST be set to 0. It is set to 365 0 in legacy implementations as specified respectively in Sections 366 20.11 and 6.4 of [RPL]. . 367 368 0 1 2 3 369 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | TrackID |K|D|P| Flags | Reserved | DAOSequence | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | | 374 + + 375 | | 376 + IPv6 Address of the Track Ingress + 377 | | 378 + + 379 | | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Option(s)... 382 +-+-+-+-+-+-+-+-+ 383 384 Figure 1: Projected DAO Base Object 385 386 New fields: 387 388 TrackID: In the case of a P-DAO, the RPLInstanceID field is called 397 TrackID. This is a naming convenience but does not change the 398 semantics and format of the RPLInstanceID that is used as TrackID. Maybe then stick to calling it RPLInstanceID in the ASCII and not calling it a new field (nitpicking). 400 P: 1-bit flag (position to be confirmed by IANA). 401 402 The 'P' flag is set to 1 by the Root to signal a Projected DAO, 403 and it is set to 0 otherwise. 404 405 In RPL Non-Storing Mode, the TIO and RTO are combined in a DAO 406 message to inform the DODAG Root of all the edges in the DODAG, which 407 are formed by the directed parent-child relationships. Options may 408 be factorized; multiple RTOs may be present to signal a collection of 409 children that can be reached via the parent(s) indicated in the 410 TIO(s) that follows the RTOs. This specification generalizes the 411 case of a parent that can be used to reach a child with that of a 412 whole Track through which both children and siblings of the Track 413 Egress are reachable. This again seems to be mixing larger logical behavior explanation into what probably should be just the spec for the new message encodings here. See how you can decouple the larger system explamnations from the encoding spec. 415 New CMOs called the Via Information Options (VIO) are introduced for 416 use in P-DAO messages as a multihop alternative to the TIO. One VIO a) Add forward pointer to section defining VIO b I get the feeling as if the whole mentioning of TIO and RTO above should simply go in a separate chapter for RPL experts with a title like "Why are TIO and RTO not sufficient". Or "How to combine TIO/RTO with SF-VIO" etc.. but try to stick to topic at hand here. Feeble minded readers like myself can only balance a limited number of partially understood terms in the air at the same time. 417 is the Stateful VIO (SF-VIO); the SF-VIO installs Storing-Mode ^ a ? 418 Projected Route along a strict segment. The other is the Source- ^ s ? 419 Routed VIO (SR-VIO); the SR-VIO installs a Non-Storing-Mode Projected 420 Route at the Track Ingress, which uses that state to encapsulate a 421 packet with a Routing Header (RH) to the Track Egress. Question... If i just use basic RPL with non-storing mode, i already need an RH. And that is let's say a strict path. So after the first hop of that RH, my next hop is actually a track ingres for which i have SR-VIO. Does this mean i need to do a full new IPv6 encap of the packet to insert the new RH for the track ? If so: a) i'd say: "to encapsulate the packet into an IPv6 packe with a new RH to the track egress. b) What about MTU issues due to the encap ? Can not find word MTU in text. 423 Like in a DAO message, the RTOs can be factorized in a P-DAO, but the 424 Via Information Options cannot. 424 A P-DAO contains one or more RTOs ^ MUST/SHOULD/MAY ? 425 that indicate the destinations that can be reached via the Track, and 426 exactly one VIO that signals a sequence of nodes . In Non-Storing ^ That form the track ? root ....... Track-Ingres ...(Track Midpoints)... Track-Egres ..... Destination1 ... ... DestinationN P-DAO has: one RTO for each DestinationI one VIO for the Track: Midpoints,Egres Semantic: When packet reaches Track-Ingres, it checks whether destination or next-hop is one of the DestinationI, if so, then use the track. If SR-VIO, then encap IPv6/RH, if SF-VIO, then just forward to first hop on track, which will also have installed the right state for the track... Something like this with picture would make the whole concept so much easier to understand (to me). 427 Mode, the Root sends the P-DAO to the Track Ingress where the source- 428 routing state is stored. In Storing Mode, the P-DAO is sent to the 429 Track Egress and forwarded along the Segment in the reverse 430 direction, installing a Storing Mode state to the Track Egress at 431 each hop. In both cases the Track Ingress is the owner of the Track, 432 and it generates the P-DAO-ACK when the installation is successful. How would the root know whether in storing node all the track midpoints did successfully install the necessary track state ? If not, hen it would be worth pointing out how storing mode may end up being less reliable ? 434 3.2. Sibling Information Option Is there any reason why we wouldn't first want to have the VIO section here so a feeble minded reader could pop off some open definitions of the stack and declare understanding victory on whats explaind so far ? To answe my own question, i think your structure is around whatever RFC is supposedly extended by a new semantic introduced, but that results in terrible flow of reading. I would strongly suggest to reshuffle the text from the most simple cases to the most complex cases and have separate short sections summarizing for each affected RFC how it is extended usin the template questions above, using references to the main specification part. 436 This specification adds another CMO called the Sibling Information 437 Option (SIO) that is used by a RPL Aware Node (RAN) to advertise a 438 selection of its candidate neighbors as siblings to the Root, more in 439 Section 6.4. The sibling selection process is out of scope. The 440 expectation is that a node reports a Sibling Address in a SIO based 441 on an active address registration [RFC8505] from that sibling for 442 that address with the 'R' flag not set in the EARO. The node may 443 assess the liveliness of the sibling at any time by performing a 444 registration for one of its own addresses, either a link local or a 453 global one, depending on whether the node expects the sibling to 454 perform a matching advertisement in its own SIO. I am not even going to try to understand this without a prior graphical example use case on how this would be used. 456 3.3. P-DAO Request 457 458 Two new RPL Control Messages are also introduced, to enable a RAN to 459 request the establishment of a Track between self as the Track 460 Ingress Node and a Track Egress. The RAN makes its request by 461 sending a new P-DAO Request (PDR) Message to the Root. The Root 462 confirms with a new PDR-ACK message back to the requester RAN, see 463 Section 6.1 for more. The split between this text and 6.1 is weird and IMHO not helpfull. Merge. WHats ven the logic to split some explanations out into section 6 and leave others (P-DAO for example) here ? I would also like some motivational example of what would make a RAN send out a P-DAO Request. Could it be that the RAN is a PSE ingres ? I am asking, because this looks like a request where it might be highly desirable to have more contextual information in the request than just the few fields defined in 6.1. How about a 32 bit policy-ID field or the like.. But just guessing. Something for the PCE to match up PSE stuff it established with P-DAO requests it receives later. Unless you feel strongly that association is unambiguous now. 463 A positive PDR-ACK indicates that the Track 464 was built and that the Roots commits to maintain the Track for the 465 negotiated lifetime. In the case of a complex Track, each Segment is 466 maintained independently and asynchronously by the Root, with its own 467 lifetime that may be shorter, the same, or longer than that of the 468 Track. I guess those different liftimes are not meant to make the solution more fragile by randomnly expiring timers for different parts of a track, but because the the parts of a projected routes affected can only change when they expire ? In any case, an explanation of the semantic impact of lifetimes would be useful. 468 The Root may use an asynchronous PDR-ACK with an negative 469 status to indicate that the Track was terminated before its time. And if that happens, what should a RAN do that has some configuration telling it to request the P-DAO ? Sounds like the need for the definition of some exponential back-off re-request scheme ? Also, when the request is just renewed upon timeout, but the reply changes, i figure that the impact in stateful mode may be some inconsistent forwarding while the track midpoints update their routes. No issue i guess in stateless. Would be useful to mention. Not sure if/what countermeasures for consistency RPL already provides. If it does, would be good to mention. 471 3.4. Extending the RPI 472 473 Sending a Packet within a RPL Local Instance requires the presence of 474 the abstract RPL Packet Information (RPI) described in section 11.2. 475 of [RPL] in the outer IPv6 Header chain (see [USEofRPLinfo]). The 476 RPI carries a local RPLInstanceID which, in association with either 477 the source or the destination address in the IPv6 Header, indicates 478 the RPL Instance that the packet follows. 479 480 This specification extends [RPL] to create a new flag that signals 481 that a packet is forwarded along a projected route. 482 483 Projected-Route 'P': 1-bit flag. It is set to 1 if this packet is 484 sent over a projected route and set to 0 otherwise. This leaves me guessing when and how this applied. I can see how this would be applicable to both stateful and stateless Projected route operastions, but in either case, the forwarding plane behavior needs to be explained, ideall with example for each (of the two?) cases. Also: Please add forward pointer to next section saying "For concrete encoding of the P flag, see section 4.". 486 4. Extending RFC 6553 I think this RFC MUST claim to be an update to RFC6553, because the P-flag added to this concrete RPI RFC exhausts a non-IANA extension point, and the only way to formally avoid that any other RFCs could collide (and allocate the same bit) is to make this RFC an update to RFC6553. Same logic also applies to update for RFC6550 and P-DAO P flag. Just to be save, claim also update to RFC9008 to given how you mention it, and we obviously want this RFC to also apply to RPI headers with 0x23. 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Option Type | Opt Data Len | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 |O|R|F|P|0|0|0|0| RPLInstanceID | SenderRank | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | (sub-TLVs) | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 519 Figure 2: Extended RPL Option Format 520 521 Option Type: 0x23 or 0x63, see [USEofRPLinfo] 522 523 Opt Data Len: See [RFC6553] ^ unchanged, 524 525 'O', 'R' and 'F' flags: See [RFC6553]. Those flags MUST be set to 0 526 by the sender and ignored by the receiver if the 'P' flag is set. 527 528 Projected-Route 'P': 1-bit flag as defined in Section 3.4. 529 530 RPLInstanceID: See [RFC6553]. Indicates the TrackId if the 'P' flag 531 is set. Add 'see also section 3.1' ? 533 SenderRank: See [RFC6553]. This field MUST be set to 0 by the 534 sender and ignored by the receiver if the 'P'flag is set. Would you mind to add expanation as to what can happen when this passes via a router not supporting this RFC and therefore ignoring the P flag but interpreting the other fields ? 536 5. Extending RFC 8138 537 538 Section 6.3 of [RFC8138] presents the formats of the 6LoWPAN Routing 539 Header of type 5 (RPI-6LoRH) that compresses the RPI for normal RPL ^ in the IANA "Critical 6LoWPAN Routing Header Type Registry" 540 operation. The format of the RPI-6LoRH is not suited for Projected 541 routes since the O,R,F flags are not used and the Rank is unknown and 542 ignored. 543 544 This specification introduces a new 6LoRH, the P-RPI-6LoRH, with a 545 type of 7. The P-RPI-6LoRH header is usually a a Critical 6LoWPAN ^ ^^^ | in the IANA "Critical 6LoWPAN Routing Header Type Registry" 546 Routing Header, but it can be elective as well if an SRH-6LoRH is ^^^^^^^^^^^^^^^^^^^ also use type TBD1 from the IANA "Electivce 6LoWPAN Routing Header Type Registry" https://www.iana.org/assignments/_6lowpan-parameters/_6lowpan-parameters.xhtml#critical-6lowpan-routing-header-type Elective Type 7 is already gone. If you want to get the same numbers for elective and critical yo may want to also revisit to choose 7 for critical. Who made you be so adventerous to write an actual number 7 into the draft without an early allocation anyhow ? How about asking for an early allocation ? 547 present and controls the routing decision. 548 549 The P-RPI-6LoRH is designed to compress the RPI along RPL Projected 550 Routes. It sformat is as follows: ^^^ 551 565 0 1 2 566 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 |1|0|E| Length | 6LoRH Type 7 | RPLInstanceID | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 571 572 Figure 3: P-RPI-6LoRH Format 573 574 Elective 'E': See [RFC8138]. The 'E' flag is set to 1 to indicate 575 an Elective 6LoRH, meaning that it can be ignored when forwarding. Please explain length or point to RFC8138 (inchanged from RFC8318, section XX.YY). Please DO NEVER include the assicned number into the field, just write "6LoRH Type". Explain in text that is the assined type for criical or elective depending on E flag. Explain that RPLInstanceID is the TrackID (see section 3.1 ?) Or if not, what it is. 577 6. New RPL Control Messages and Options 578 579 6.1. New P-DAO Request Control Message 580 581 The P-DAO Request (PDR) message is sent by a Node in the main DODAG 582 to the Root. It is a request to establish or refresh a Track where 583 this node is Track Ingress. The source IPv6 address of the PDR 584 signals the Track Ingress of the requested Track, and the TrackID is 585 indicated in the message itself. One and only one RPL Target Option 586 MUST be present in the message. The RTO signals the Track Egress, 587 more in Section 7.1. 588 589 The RPL Control Code for the PDR is 0x09, to be confirmed by IANA. Correct form is TBDi (TBD2 ?) instead of 0x09. If you are not in a hurry, all TBDi can be resolved during IANA/RFC-editor procss. If you want to lock in a number get an early allocation first. 590 The format of PDR Base Object is as follows: 591 592 0 1 2 3 593 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | TrackID |K|R| Flags | ReqLifetime | PDRSequence | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Option(s)... 598 +-+-+-+-+-+-+-+-+ 599 600 Figure 4: New P-DAO Request Format 601 602 TrackID: 8-bit field indicating the RPLInstanceID associated with 603 the Track. 604 605 K: The 'K' flag is set to indicate that the recipient is expected to 606 send a PDR-ACK back. 607 608 R: The 'R' flag is set to request a Complex Track for redundancy. 609 610 Flags: Reserved. The Flags field MUST initialized to zero by the 611 sender and MUST be ignored by the receiver 612 613 614 615 616 Thubert, et al. Expires 28 January 2022 [Page 11] 617 618 Internet-Draft DAO Projection July 2021 619 620 621 ReqLifetime: 8-bit unsigned integer. The requested lifetime for the 622 Track expressed in Lifetime Units (obtained from the DODAG 623 Configuration option). 624 625 A PDR with a fresher PDRSequence refreshes the lifetime, and a 626 PDRLifetime of 0 indicates that the track should be destroyed. ... It would be sent for example when the function for which the Node requested the track is deactivated. ?! 628 PDRSequence: 8-bit wrapping sequence number, obeying the operation 629 in section 7.2 of [RPL]. The PDRSequence is used to correlate a 630 PDR-ACK message with the PDR message that triggered it. It is 631 incremented at each PDR message and echoed in the PDR-ACK by the 632 Root. 633 634 6.2. New PDR-ACK Control Message 635 636 The new PDR-ACK is sent as a response to a PDR message with the 'K' 637 flag set. The RPL Control Code for the PDR-ACK is 0x0A, to be 638 confirmed by IANA. Its format is as follows: Same IANA/TBD concern as above. 639 640 0 1 2 3 641 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | TrackID | Flags | Track Lifetime| PDRSequence | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | PDR-ACK Status| Reserved | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Option(s)... 648 +-+-+-+-+-+-+-+ 649 650 Figure 5: New PDR-ACK Control Message Format 651 652 TrackID: The RPLInstanceID of the Track that was created. The value 653 of 0x00 is used to when no Track was created. ^^ Same question as in before. Any standardized logic what to do in case of 0x00 failure, if not, then why not. 654 655 Flags: Reserved. The Flags field MUST initialized to zero by the 656 sender and MUST be ignored by the receiver 657 658 Track Lifetime: Indicates that remaining Lifetime for the Track, 659 expressed in Lifetime Units; the value of zero (0x00) indicates 660 that the Track was destroyed or not created. 661 662 PDRSequence: 8-bit wrapping sequence number. It is incremented at 663 each PDR message and echoed in the PDR-ACK. according to section 7.2 of [RPL] ?! 665 PDR-ACK Status: 8-bit field indicating the completion. The PDR-ACK ^ status 666 Status is substructured as indicated in Figure 6: 676 677 0 1 2 3 4 5 6 7 678 +-+-+-+-+-+-+-+-+ 679 |E|R| Value | 680 +-+-+-+-+-+-+-+-+ 681 682 Figure 6: PDR-ACK status Format 683 684 E: 1-bit flag. Set to indicate a rejection. When not set, the 685 value of 0 indicates Success/Unqualified acceptance and other 686 values indicate "not an outright rejection". 687 R: 1-bit flag. Reserved, MUST be set to 0 by the sender and 688 ignored by the receiver. 689 Status Value: 6-bit unsigned integer. Values depending on the 690 setting of the 'E' flag, see Table 27 and Table 28. 691 692 Reserved: The Reserved field MUST initialized to zero by the sender ^ be 693 and MUST be ignored by the receiver 694 695 6.3. Via Information Options 696 697 A VIO signals the ordered list of IPv6 Via Addresses that constitutes 698 the hops of either a Serial Track or a Segment of a more Complex 699 Track. A VIO MUST contain at least one Via Address, and a Via 700 Address MUST NOT be present more than once, otherwise the VIO MUST be 701 ignored. If i understand it correctly, for the SR-VIO, the sequence of addresses would ultimately end up in the RPL steering header of packets. I browsed through RFC8754 and think i can not find a similar exclusion. So a justification why this optimization is done for SF-VIO would be good if you really want to keep it. For SF-VIO, this seems to be taken apart and every node listed creates a next-hop route. So if the same node is addressed twice, it could become confused, which instance of its own address to choose to install the route, right ? And what does "ignore" mean anyhow, e.g.: would the Target Options still be acted upon ? It rather sounds to me as if you would want the whole Projected DAO message to be rejected ? Is duplicate address the only case of a "broken" projected DAO that you can discover and reject ? E.g.: can nodes have multiple addresses ? Such as anycast addresses ? Would be good to elaborate about such "broken" projected DAO more if there are different cases of it. 701 The format of the Via Information Options is as follows: 732 733 0 1 2 3 734 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | Type | Option Length | Flags | SegmentID | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 |Segm. Sequence | Seg. Lifetime | SRH-6LoRH header | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | | 741 + + 742 . . 743 . Via Address 1 . 744 . . 745 + + 746 | | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | | 749 . .... . 752 | | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 | | 753 + + 754 . . 755 . Via Address n . add (n <= 15) ? 756 . . 757 + + 758 | | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 761 762 Figure 7: VIO format (uncompressed form) 763 764 Option Type: 0x0B for SF-VIO, 0x0C for SR-VIO (to be confirmed by 765 IANA) Same concern as prior illegal occupations of IANA codepoints in this spec ;-)) 767 Option Length: In bytes; variable, depending on the number of Via 768 Addresses and the compression. Something like total size of the Option ... in bytes ? Is this semantic mandated by prior RFC ? If it could count differently, it could allow for more than 15 hops, although i have no idea if that would be relevant. 770 SegmentID: 8-bit field that identifies a Segment within a Track or 771 the main DODAG as indicated by the TrackID field. The value of 0 772 is used to signal a Serial Track, i.e., made of a single segment. Another basic signaling element not yet explained, so somewhat mysterious here 774 Segment Sequence: 8-bit unsigned integer. The Segment Sequence 775 obeys the operation in section 7.2 of [RPL] and the lollipop 776 starts at 255. 777 778 When the Root of the DODAG needs to refresh or update a Segment in 779 a Track, it increments the Segment Sequence individually for that 780 Segment. 781 789 The Segment information indicated in the VIO deprecates any state 790 for the Segment indicated by the SegmentID within the indicated 791 Track and sets up the new information. 792 793 A VIO with a Segment Sequence that is not as fresh as the current 794 one is ignored. 795 796 A VIO for a given DODAGID with the same (TrackID, SegmentID, 797 Segment Sequence) indicates a retry; it MUST NOT change the 798 Segment and MUST be propagated or answered as the first copy. 799 800 Segment Lifetime: 8-bit unsigned integer. The length of time in 801 Lifetime Units (obtained from the Configuration option) that the 802 Segment is usable. 803 804 The period starts when a new Segment Sequence is seen. The value 805 of 255 (0xFF) represents infinity. The value of zero (0x00) 806 indicates a loss of reachability. 807 808 A P-DAO message that contains a VIO with a Segment Lifetime of 809 zero is referred as a No-Path P-DAO in this document. 810 811 SRH-6LoRH header: The first 2 bytes of the (first) SRH-6LoRH as 812 shown in Figure 6 of [RFC8138]. A 6LoRH Type of 4 means that the 813 VIA Addresses are provided in full with no compression. 814 815 Via Address: An IPv6 address along the Segment. 816 817 In a SF-VIO, the list is a strict path between direct neighbors, 818 from the Segment Ingress to Egress, both included. The router 819 that processes an SF-VIO MAY create additional routing state 820 towards the nodes after self via the node immediately after self 821 in the SF-VIO, but in case of memory shortage the routes to the 822 Targets have precedence since they are the ones that the router 823 commits to store. Again, i am at a lack of understanding the base theory of operations of forwarding, I have Track Ingres, Track Egres, Destinations, Target and somehow i have Segments with addresses, wheree i do not know how Segment Ingres and Segment Egres may or may not map to Track Ingres/Egres, Destinations or Targets. Picture me this, please ? ;-)) So, what exactly does the routing state look like ? whats the lookup ? Something like (RPLInstanceID==TrackID, Destination) ? Or rather: What is the example scenario when a the above described additional routing state to the nodes after self would would be used ? 825 In an SR-VIO, the list includes the egress but not the ingress 826 node. It starts at the first hop and ends at a Track Egress. In Seems like a mayor difference in flexiblity of stateful vs. stateless operations than ? No segment layer with SR-VIO ? 827 that case, the Track Egress MUST be considered as an implicit 828 Target, so it MUST NOT be listed it in a RPL Target Option. The 829 list in an SR-VIO may be loose, provided that each listed node has 830 a path to the next listed node, e.g., via a segment or another 831 Track. But you are not telling me you would want to create the freedom to have stateless operation rely on routing state created by SF-VIO where you said it might not exist in case of memory shortage which the stateless encapsulator would know nothing about, right ? 833 In the case of a SF-VIO, or if [RFC8138] is not used in the data 834 packets, then the Root MUST use only one SRH-6LoRH per Via 835 Information Option, and the compression is the same for all the 836 addresses, as shown in Figure 7. I do not see any address compression in Figure 7, nor was compression mentioned so far. Do you mean figure 7 in section 5.1 of [RFC8138] ? 845 In case of an SR-VIO, and if [RFC8138] is in use in the main 846 DODAG, then the Root SHOULD optimize the size of the SR-VIO; Any example how ? 846 more 847 than one SRH-6LoRH may be present, e.g., if the compression level 848 changes inside the Segment and different SRH-6LoRH Types are 849 required. That rather sounds as if those are cases where optimiation would no be possible ? 849 The content of the SR-VIO starting at the first SRH- 850 6LoRH header is thus verbatim the one that the Track Ingress 851 places in the packet encapsulation to reach the Track Ingress. Example with picture would help. 853 6.4. Sibling Information Option 854 855 The Sibling Information Option (SIO) provides indication on siblings 856 that could be used by the Root to form Projected Routes. One or more 857 SIO(s) may be placed in the DAO messages that are sent to the Root in 858 Non-Storing Mode. Is this some poor-mans (little signaling) form of signaling to help the root do some topology discovery ? If so, then it probably would be something that needs to go to the PCE, right ? Maybe this type of high level explanation in the tex would be helpful. If i am guessing wrong then i even understand less. 859 860 The format of the SIO is as follows: 861 862 0 1 2 3 863 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | Type | Option Length |Comp.|B|D|Flags| Opaque | 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | Step of Rank | Reserved | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | | 870 + + 871 . . 872 . Sibling DODAGID (if the D flag not set) . 873 . . 874 + + 875 | | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | | 878 + + 879 . . 880 . Sibling Address . 881 . . 882 + + 883 | | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 886 Figure 8: Sibling Information Option Format 887 888 Option Type: 0x0D (to be confirmed by IANA) You're maxing out your repeat offender penalty of illegal IANA code point misappropriation ;-) 890 Option Length: In bytes, the size of the option. 891 892 Compression Type: 3-bit unsigned integer. This is the SRH-6LoRH 901 Type as defined in figure 7 in section 5.1 of [RFC8138] that 902 corresponds to the compression used for the Sibling Address and 903 its DODAGID if resent. The Compression reference is the Root of ^ p ? 904 the main DODAG. 905 906 Reserved for Flags: MUST be set to zero by the sender and MUST be 907 ignored by the receiver. 908 909 B: 1-bit flag that is set to indicate that the connectivity to the 910 sibling is bidirectional and roughly symmetrical. In that case, 911 only one of the siblings may report the SIO for the hop. If 'B' How would they do that (decide which one reports the SIO ?). 911 only one of the siblings may report the SIO for the hop. If 'B' 912 is not set then the SIO only indicates connectivity from the 913 sibling to this node, and does not provide information on the hop 914 from this node to the sibling. I hope there is a simple way to do 'B' or more of a benefit than just cutting down reporting data by 50%. Any standardized mechanism ? 916 D: 1-bit flag that is set to indicate that sibling belongs to the 917 same DODAG. When not set, the Sibling DODAGID is indicated. 918 919 Flags: Reserved. The Flags field MUST initialized to zero by the ^ be 920 sender and MUST be ignored by the receiver 921 922 Opaque: MAY be used to carry information that the node and the Root 923 understand, e.g., a particular representation of the Link 924 properties such as a proprietary Link Quality Information for 925 packets received from the sibling. An industrial Alliance that 926 uses RPL for a particular use / environment MAY redefine the use 927 of this field to fit its needs. Is there a prior RPL example of such a field ? Pointer to that wold be useful. I hav a hard time seeing how this would not result in all type of misinterpretation unless the industrial alliance whose registration space is to be used for Upaque is unambigously derivable from the device (type) or link (type). I would prefer to add MUST be set to 0 and be ignored upon receiving and go on saying, IETF specification MUST NOT use or define this field, but non-IETF specification may use it. Aka: why not give such external specs the same starting ground (0-filled) that we give our own extension points. But again: pre-existing examples of BCP spec text for such an Opaque field would be helpful. 929 Step of Rank: 16-bit unsigned integer. This is the Step of Rank 930 [RPL] as computed by the Objective Function between this node and 931 the sibling. 932 933 Reserved: The Reserved field MUST initialized to zero by the sender 934 and MUST be ignored by the receiver 935 936 Sibling DODAGID: 2 to 16 bytes, the DODAGID of the sibling in a 937 [RFC8138] compressed form as indicated by the Compression Type 938 field. This field is present if and only if the D flag is not 939 set. 940 941 Sibling Address: 2 to 16 bytes, an IPv6 Address of the sibling, with 942 a scope that MUST be make it reachable from the Root, e.g., it 943 cannot be a Link Local Address. The IPv6 address is encoded in 944 the [RFC8138] compressed form indicated by the Compression Type 945 field. 956 957 An SIO MAY be immediately followed by a DAG Metric Container. In ^ "A for consonant start of TLA" 958 that case the DAG Metric Container provides additional metrics for 959 the hop from the Sibling to this node. 960 961 7. Projected DAO Given how this section seems to describe what the title of the doc is, maybe it should also be named that way "Root initiated routing state". 962 963 This draft adds a capability to RPL whereby the Root of a main DODAG Define what a "main DODAG" is. I guess its a DODAG not created by the mechanisms of this draft, but also: what are non-main DODAGs ? Or is the opposite just the projected DAO ? 964 installs a Track as a collection of Projected Routes, using a 965 Projected-DAO (P-DAO) message to maintain each individual route. The What is an individual route ? 966 P-DAO signals a collection of Targets in the RPL Target Option(s) 967 (RTO). Those Targets can be reached via a sequence of routers 968 indicated in a VIO. A P-DAO message MUST contain exactly one VIO, 969 which is either a SF-VIO or an SR-VIO, and MUST follow one or more 970 RTOs. There can be at most one such sequence of RTO(s) and an Via 971 Information Option. A track is identified by a tuple DODAGID, ^ in a P-DAO Also, is "at most" correct ? How about there MUST be exactly one sequece of one or more RTO followed vy one VIO ? Or is it valid to have no RTO, or no VIO ? 972 TrackID and each route within a Track is indexed by a SegmentID. So, IMHO, this whole section 7 needs to come before section 3, because it is here where you start defining the functionality from higher layer, but then section 3 goes into the encoding details. I observe that all RFCs i remember have the order of starting wih the overall functionality and bring the encoding details of messages later (but then i am forgetfull of what i have read and also say this because as my comments before will show, i struggled to make head & tails out of how the pieces fit together). 973 974 A P-DAO MUST be sent from the address of the Root that serves as 975 DODAGID for the main DODAG. It MUST be sent to a GUA or a ULA of Expand GUA, ULA, provide reference for ULA, and/or add to initial list of terms in doc. 976 either the ingress or the egress of the Segment, more below. If the 977 'K' Flag is present in the P-DAO, and unless the P-DAO does not reach 978 it, the ingress of the Segment is the node that acknowledges the 979 message, using a DAO-ACK that MUST be sent back to the address that 980 serves as DODAGID for the main DODAG. Sentence too convoluted. Try to make two out of it. You are not using the same term here as in 974, so this makes one wonder if the DAO-ACK is to be sent back to the same address it was sent from or not. If it is meant to be sent back to the same address, why not say "sent back to the address of the root, which the P-DAO was sent from". 982 Like a classical DAO message, a P-DAO causes a change of state only 983 if it is "new" per section 9.2.2. "Generation of DAO Messages" of 984 the RPL specification [RPL]; this is determined using the Segment 985 Sequence information from the VIO as opposed to the Path Sequence ^ in the P-DAO 986 from a TIO. Also, a Segment Lifetime of 0 in a VIO indicates that ^ in the DAO. 987 the projected route associated to the Segment is to be removed. 988 989 There are two kinds of operation for the Projected Routes, the 990 Storing Mode and the Non-Storing Mode. 991 992 * The Non-Storing Mode is discussed in Section 7.3.2. A Non-Storing 993 Mode P-DAO carries an SR-VIO with the loose list of Via Addresses ^ steering 994 that forms a source-routed Segment to the Track Egress. The 995 recipient of the P-DAO is the Track Ingress; it MUST install a 996 source-routed state to the Track Egress and reply to the Root 997 directly using a DAO-ACK message if requested to. 998 999 * The Storing Mode is discussed in Section 7.3.1. A Storing Mode 1000 P-DAO carries a SF-VIO with the strict list of Via Addresses from ^n ^ steering 1001 the ingress to the egress of the Segment in the data path order. 1002 The routers listed in the Via Addresses, except the egress, MUST 1003 install a routing state to the Target(s) via the next Via Address 1004 in the SF-VIO. In normal operations, the P-DAO is propagated 1013 along the chain of Via Routers from the egress router of the path 1014 till the ingress one, which confirms the installation to the Root 1015 with a DAO-ACK message. In 976 you point to further below as to where the P-DAO is to be sent. But hen in the bullet points 992 and 999 you do not explicitly say tha the SR-VIO is sent to the track ingres and that the SF-VIO is sent to the track egres. Please add such sentences accordingly. I think the description of ACK processing from 976++ fits better here after, given how its an additional detail happening after the P-DAO is processed according to the two bullet points above. Q: If in the SF-VIO case, the egress does not install any state, then why send the P-DAO to it instead of to the pre-ultimate hop ? Explanation might be helpful in the text. 1016 1017 In case of a forwarding error along a Projected Route, an ICMP error Arre we talking about the forwaring of data packets that are following a projected route, or processing error of the P-DAO ? Please be specific. An example of a forwarding error would help. I suspect it is the data packets. Is there also any other error for processing of the P-DAO other than missing ACK ? Aka: wha exactly happens in the duplicate address in VIO If lets say the root was too stsupid to figure it out ? 1018 is sent to the Root with a new Code "Error in Projected Route" (See 1019 Section 11.13). The Root can then modify or remove the Projected 1020 Route. The "Error in Projected Route" message has the same format as 1021 the "Destination Unreachable Message", as specified in RFC 4443 1022 [RFC4443]. 1023 1024 The portion of the invoking packet that is sent back in the ICMP 1025 message SHOULD record at least up to the RH if one is present, and 1026 this hop of the RH SHOULD be consumed by this node so that the ^^^^ ^^^^ which hop ? The hop that has problems and wants to generate the ICMP error? 1027 destination in the IPv6 header is the next hop that this node could 1028 not reach. if a 6LoWPAN Routing Header (6LoRH) [RFC8138] is used to So ultimately, you want the root to be able to figure out from the ICMP, which nodeA can not reach a next-hop nodeB, right ? WOuld be good to say that, but the description of how to achieve this by messing with the ICMP error reported original packet stub still escapes me. Is that "consumed by" procedure already done some place else ? If so, hen a reference to prior way how this is done would be good. If not, then elaborating a bit more to make it easier to understand would help. 1028 not reach. if a 6LoWPAN Routing Header (6LoRH) [RFC8138] is used to 1029 carry the IPv6 routing information in the outer header then that 1030 whole 6LoRH information SHOULD be present in the ICMP message. How would a root then figure out nodeA/nodeB ? 1031 1032 The sender and exact operation depend on the Mode and is described in 1033 Section 7.3.2 and Section 7.3.1 respectively. 1034 1035 7.1. Requesting a Track 1036 1037 A Node is free to ask the Root for a new Track for which it will be 1038 Ingress at any time. This is done with a PDR message, that indicates for which it wants to be ingres ? E.g.: no idea what "will be at any time" means. 1039 the desired TrackID and the duration for which the Track should be 1040 established. Upon a PDR, the Root MAY install the necessary An example of why the node would generate it, and where it has the TrackID from would help here. 1041 Segments, in which case it answers with a PDR-ACK indicating the 1042 granted Track Lifetime. All the Segments MUST be of a same mode, 1043 either Storing or Non-Storing. All the Segments MUST be created with 1044 the same TrackID and the same DODAGID signaled in the P-DAO. 1045 1046 The Root is free to design the Track as it wishes, and to change the 1047 Segments overtime to serve the Track as needed, without notifying the 1048 resquesting Node. The Segment Lifetime in the P-DAO messages does ^ Presumably, a requesting node would likely also be the ingres of one P-DAO of the track, right ? But establishment of the track via P-DAO is only related to the PDR/PDR-ACK in the root ? Might be useful to have some place a higher level description of "initiation" models, and point to it. Aka: the way i figure, initiation can come from PCE and go through root, no other nodes involved. Or it comes somehow via PDR initiaor... but how/why. Also "free to " is a bit of a misnomer, right ? Aka: If the root is free, then it should also be able to notify the requesting node, but there really is no other notification than acknowledging in PDR-ACK acceptance to take care of the request or to indicate failure of it. Aka, write maybe: "The root designs the Track as it wishes.... there are no notifications to the requesting node when changing the track". 1049 not need to be aligned to the Requested Lifetime in the PDR, or 1050 between P-DAO messages for different Segments. The Root may use 1051 shorter lifetimes for the Segments and renew them faster than the 1052 Track is, or longer lifetimes in which case it will need to tear down 1053 the Segments if the Track is not renewed. 1054 1055 When the Track Lifetime that was returned in the PDR-ACK is close to 1056 elapse, the resquesting Node needs to resend a PDR using the TrackID 1057 in the PDR-ACK to extend the lifetime of the Track, else the Track 1058 will time out and the Root will tear down the whole structure. How close ? Any guidance ? 1068 1069 If the Track fails and cannot be restored, the Root notifies the 1070 resquesting Node asynchronously with a PDR-ACK with a Track Lifetime ^ 1071 of 0, indicating that the Track has failed, and a PDR-ACK Status 1072 indicating the reason of the fault. 1073 1074 7.2. Identifying a Track 1075 1076 RPL defines the concept of an Instance to signal an individual 1077 routing topology but does not have a concept of an administrative 1078 distance, which exists in certain proprietary implementations to sort 1079 out conflicts between multiple sources of routing information within 1080 one routing topology. 1081 1082 This draft leverages the RPL Instance model as follows: ... to sort out conflicts between multiple sources of routing information ?? aka: tie the text together, the way it is written it is confusing. It also seems as if it would be better to high level answer how P-DAO avoids the need for administrative distances here, instead of letting readers try to figure it out from all the details of the following bullet points, because those bullet points explain a lot more, so the whole administative distance stuff will get lost. The way i see it is that P-DAO do not require administrative distance because a) They will be preferred because of prefixlength vs. default route to root when used within pre-existing RPLinstance. b) They can be explicitly indicated through their own RPLinstance called TrackID in the RPL packet header, therefore not colliding with routes from pre-existing RPLinstances. 1083 1084 * The Root MAY use P-DAO messages to add better routes in the main 1085 (Global) Instance in conformance with the routing objectives in 1086 that Instance. To achieve this, the Root MAY install an Storing- What actually happens if those P-DAO routes are not in conformance with the routing objectives of that instance ? Anything worse than that the routing objective does not well express what the routes are doing ? I am asking, because i would assume that the routing objectives likely will never be able to express all the characteristics that may come out of a bunch of Tracks. Therefore i fear that this conformance sentence is somewhat career limiting to P-DAOs. But i am not sure about the overall framework. Is there some form of policy framework, whereby traffic may choose one out of multiple instances, and what you really want to say is that Tracks should be assigned to the track that best matches what the Track attempts to improve upon so that traffic choosing one out of multiple insances can continue to do so, and track will improve the desired outcome ? Aka: Motivating this setnence, maybe in the way i am imagining it (if correct) might help. And it might also better capture the goal of choosing a particular instance for a track than referring to the formal routing objectives instead of maybe the informal intent of an instance, which may be constituted from the routing objectives of DAOs and the traffic engineered objectives of P-DAOs. 1086 that Instance. To achieve this, the Root MAY install an Storing- ^ just a - storing is spoken with consonant first. 1087 Mode P-Route along a path down the main Non-Storing Mode DODAG. 1088 This enables a loose source routing and reduces the size of the 1089 Routing Header, see Appendix A.1. 1090 1091 When adding an Storing-Mode P-Route to the main RPL Instance, the ^ just a 1092 Root MUST set the RPLInstanceID field of the P-DAO message (see 1093 section 6.4.1. of [RPL]) to the RPLInstanceID of the main DODAG, 1094 and MUST NOT use the DODAGID field. A Projected Route provides a Whats the significance of the DODAGID here ? What would happen if it was set ? 1095 longer match to the Target Address than the default route via the 1096 Root, so it is preferred. 1097 1098 Once the Projected Route is installed, the intermediate nodes 1099 listed in the SF-VIO after first one (i.e. The ingress) can be 1100 elided from the RH in packets sent along the Segment signaled in 1101 the P-DAO. The resulting loose source routing header indicates 1102 (one of) the Target(s) as the next entry after the ingress. 1103 1104 * The Root MAY also use P-DAO messages to install a specific (say, 1105 Traffic Engineered) path as a Serial or as a Complex Track, to a Serial Track and Complex Track are not defined/explained yet. See comments earlier that you need to start off with pictured examples from which to much more easily define such terms. 1106 particular endpoint that is the Track Egress. In that case, the 1107 Root MUST install a Local RPL Instance (see section 5 of [RPL]), 1108 and the Local RPLInstanceID is called TrackID. Do i need a separate RPL instance to loosely tie together multiple sequential SF-VIO ? Lets say i have 20 hops in stateless. I figure i have 3 segments of 5 hops each that ae often used. So i establish separate tracks for each of them, and then my routing headers in the future would be able to be reduced by 3 * 5 = 15 hops, aka: having 3 loose hops tied together by 5 strict hops. 1109 1110 In that case, the TrackID MUST be unique for the Global Unique 1111 IPv6 Address (GUA) or Unique-Local Address (ULA) of the Track You where missing those expansions in before, so here they would now be redundant when you fix them up in before. 1112 Ingress that serves as DODAGID for the Track. The Track Ingress 1113 owns the namespace of its TrackIDs, so it can pick any unused 1114 value to request a new Track with a PDR. The Root is aware of all The root of the main DODAG, or main RPL instance or the like ? Aka: There may be multiple roots for different instances/dodags, right ? 1115 the active Tracks, so it can also pick any unused value to form 1116 Tracks without a PDR. To avoid a collision of the Root and the 1125 Track Ingress picking the same value at the same time, it is 1126 RECOMMENDED that the Track Ingress starts allocating the ID value 1127 of the Local RPLInstanceID (see section 5.1. of [RPL]) used as 1128 TrackIDs with the value 0 incrementing, while the Root starts with 1129 63 decrementing. 1131 This way, a Track is uniquely identified by the tuple (DODAGID, 1132 TrackID) where the TrackID is always represented with the D flag 1133 set to 0. Explain where the D flag is, first time i think its used in the text. I think i may be confused about the namespace and its limitations or at least not well educaed by the text ;-) So the track ingres IPv6 serves as DODAGID. So every node can have up to 64 - N Tracks, where N is the number of non-rack RPL instances for which the node is the root ? Would be good to write this out explicitly (or accordingly corrected if wrong). 1135 The Track Egress Address and the TrackID MUST be signaled in the 1136 P-DAO message as shown in Figure 1. 1137 1138 7.3. Installing a Track 1139 1140 A Storing-Mode P-DAO contains an SF-VIO that signals the strict 1141 sequence of consecutive nodes to form a segment between a segment 1142 ingress and a segment egress (both included). It installs a route of 1143 a higher precedence along the segment towards the Targets indicated 1144 in the Target Options. The segment is included in a DODAG indicated Ok, now i am getting confused again by this text. "higher precendence - than what ? Also, is there a definition of precedence in the context of RPL ? If so, reference to definition would be good. Previously you only used precedence related to priority to store/maintain a route, which i guess is a differrent meaning of the word than here. In 7.2, it sounded as if there would be no pre-existing route to the target other than through the root because of prefix-length. If that is what you mean here, and unless precedence has a well defined meaning, maybe just replace precedence with prefix-length. It is also not quite clear to me if tracks can never be installed into storing-mode RPL instances where they could not conflict with equal-prefix-length "native" routes. AFAIK, the spec only said the main RPLinstance must be non-storing mode. Can there nit be other, storing mode RPL instances ? But of course, i am likely confused... 1144 in the Target Options. The segment is included in a DODAG indicated 1145 by the P-DAO Base Object, that may be the one formed by the main RPL 1146 Instance, or a Track associated with a local RPL Instance. A Track 1147 Egress is signaled as a Target in the P-DAO, and as the last entry is 1148 an SF-VIO of a last segment towards that Egress. 1149 1150 A Non-Storing-Mode P-DAO signals a strict or loose sequence of nodes ^ contains an SR-VIO to... 1151 between the Track Ingress (excluded) and a Track Egress (included). 1152 It installs a source-routed path of a higher precedence within the ^^^^^^^^^^ same consideration as above 1153 Track indicated by the P-DAO Base Object, towards the Targets 1154 indicated in the Target Options. The source-routed path requires a 1155 Source-Routing header which implies an encapsulation to add the SRH ^^^^^^^^^^^ Same consideration as much earlier, e.g.: encapsulate into new IPv4 with SRH ?! 1156 to an existing packet. 1157 1158 The next entry in the sequence must be either a neighbor of the 1159 previous entry, or reachable as a Target via another Projected Route, 1160 either Storing or Non-Storing. If it is reachable over a Storing 1161 Mode Projected Route, the next entry in the loose sequence is the 1162 Target of a previous segment and the ingress of a next segment; the 1163 segments are associated with the same Track, which avoids the need of 1164 an encapsulation. Conversely, if it is reachable over a Non-Storing 1165 Mode Projected Route, the next loose source routed hop of the inner 1166 Track is a Target of a previous Track and the ingress of a next 1167 Track, which requires a de- and a re-encapsulation. This is a game of blindfold chess. Pictured examples of the two cases described would help a lot to understand and verify the points made/claimed here. 1181 A Serial Track is installed by a single Projected Routes that signals ^ 1182 the sequence of consecutive nodes, either in Storing or Non-Storing 1183 Mode. If can be a loose Non-Storing Mode Projected Route, in which ^ 1184 case the next loose entry must recursively be reached over a Serial 1185 Track. Please check whats standard *-Storing-Mode or *-Storing Mode - and make text consistent. 1186 1187 A Complex Track can be installed as a collection of Projected Routes 1188 with the same DODAGID and Track ID. The Ingress of a Non-Storing If this is turned around, does it become the still missing definition of a complex track ? Multiple projected routes can be installed into a single (DODAGID,TrackID). This leads to Sequential or Complex Tracks ?? 1188 with the same DODAGID and Track ID. The Ingress of a Non-Storing 1189 Mode Projected Route must be the owner of the DODAGID. The Ingress 1190 of a Storing Mode Projected Route must be either the owner of the 1191 DODAGID, or the egress of a preceding Storing Mode Projected Route in 1192 the same Track. In the latter case, the Targets of the Projected 1193 Route must be Targets of the preceding Projected Route to ensure that 1194 they are visible from the track Ingress. 1195 1196 7.3.1. Storing-Mode P-Route Please go back through the text and replace all instances of Projected Route after the first occurance with P-Route. You use both terms randomnly interchanged, which is confusing. Better to stick to the abbreviation only. I also observe, that i would be much less confused about the text if this high-level explanation was preceeding the detailed explanation earlier in the beginning of section 7. Please think how to resort the text of section 7 so it starts with the pictures and high-level explanation and then goes into the more formal detail spec. 1198 Profile 1 extends RPL operation in a Non-Storing Mode network with Without further explanation, the first unexplained use of Profile is derailing and confusing. Suggest to just delete the mentioning of profiles and just define them in Section 8. 1199 Storing-Mode Projected Routes that install segments along the main 1200 DODAG and enable to loose source routing between the Root and the 1201 targets. 1202 1203 7.3.1.1. Installing a Storing-Mode P-Route 1204 1205 As illustrated in Figure 9, a P-DAO that carries a SF-VIO enables the 1206 Root to install a stateful route towards a collection of Targets 1207 along a Segment between a Track Ingress and a Track Egress using a 1208 projected DAO Message. 1209 1210 ------+--------- 1211 | Internet 1212 | 1213 +-----+ 1214 | | Border Router 1215 | | (RPL Root) 1216 +-----+ | ^ | 1217 | | DAO | ACK | 1218 o o o o | | | 1219 o o o o o o o o o | ^ | Projected . 1220 o o o o o o\ o o o o | | DAO | Route . 1221 o o o o \o--o o o o | ^ | . 1222 o o o o o \o o o v | DAO v . 1223 o o LLN T1 T2 o | 1224 o o o o o Loose Source Route Path | 1225 o o o o From Root To Destination v 1226 1227 Figure 9: Projecting a route Do you think you can visualise an example P-route into the picture ? I started a bit of bit of it above.. 1228 1237 In order to install the relevant routing state along the Segment , 1238 the Root sends a unicast P-DAO message to the Track Egress router of 1239 the routing Segment that is being installed. The P-DAO message 1240 contains a SF-VIO with the direct sequence of Via Addresses. The SF- ^^^^^^ strict 1241 VIO follows one or more RTOs indicating the Targets to which the 1242 Track leads. The SF-VIO contains a Segment Lifetime for which the In this explanation it would be helpful to explain conditions for targets, e.g.: Target must either be direc neighbor of the P-Route egres, or be Target of some P-Route2 with the P-Route egres as its ingres. Right ? 1243 state is to be maintained. 1244 1245 The Root sends the P-DAO directly to the egress node of the Segment. 1246 In that P-DAO, the destination IP address matches the last Via 1247 Address in the SF-VIO. This is how the egress recognizes its role. 1248 In a similar fashion, the ingress node recognizes its role as it 1249 matches first Via Address in the SF-VIO. 1250 1251 The Egress node of the Segment is the only node in the path that does 1252 not install a route in response to the P-DAO; it is expected to be 1253 already able to route to the Target(s) on its own. If one of the 1254 Targets is not known, the node MUST answer to the Root with a 1255 negative DAO-ACK listing the Target(s) that could not be located 1256 (suggested status 10 to be confirmed by IANA). So complex/sequential Tracks need to be established from destination to source. What happens with a track when th egress looses routing information for a destination ? (if thats answere elsehwhere, a pointer to that section would be helpfull here). 1258 If the egress node can reach all the Targets, then it forwards the 1259 P-DAO with unchanged content to its loose predecessor in the Segment Shouldn't that be strict instead of loose ? If it was loose, how would that loose predecessor know how to send the data packets to the successor without adding another encap/RH if the underlying main RPL instance was NSM ? 1260 as indicated in the list of Via Information options, and recursively 1261 the message is propagated unchanged along the sequence of routers 1262 indicated in the P-DAO, but in the reverse order, from egress to 1263 ingress. 1264 1265 The address of the predecessor to be used as destination of the 1266 propagated DAO message is found in the Via Address the precedes the 1267 one that contain the address of the propagating node, which is used 1268 as source of the message. 1269 1270 Upon receiving a propagated DAO, all except the Egress Router MUST 1271 install a route towards the DAO Target(s) via their successor in the 1272 SF-VIO. The router MAY install additional routes towards the VIA 1273 Addresses that are the SF-VIO after the next one, if any, but in case 1274 of a conflict or a lack of resource, the route(s) to the Target(s) 1275 have precedence. 1276 1277 If a router cannot reach its predecessor in the SF-VIO, the router 1278 MUST answer to the Root with a negative DAO-ACK indicating the 1279 successor that is unreachable (suggested status 11 to be confirmed by 1280 IANA). 1281 1282 The process continues till the P-DAO is propagated to ingress router ^until 1283 of the Segment, which answers with a DAO-ACK to the Root. The Root 1284 always expects a DAO-ACK, either from the Track Ingress with a 1293 positive status or from any node along the segment with a negative 1294 status. If the DAO-ACK is not received, the Root may retry the DAO 1295 with the same TID, or tear down the route. 1296 1297 7.3.1.2. Maintaining and Tearing Down a Storing-Mode P-Route 1298 1299 A Segment Lifetime of 0 in a VIO is used to clean up the state. The ^ P-route state 1300 P-DAO is forwarded as described above, but the DAO is interpreted as 1301 a No-Path DAO and results in cleaning up existing state as opposed to 1302 refreshing an existing one or installing a new one. 1303 1304 Note that the continuity of the segment may be broken; this happens 1305 if the bidirectional connectivity between contiguous hops of the 1306 segment is lost. In that case the Root needs to send the projected 1307 DAO to one or more intermediate node(s) as opposed to the egress 1308 node, indicating a portion of segment that is being replaced or 1309 cleaned up. At the extreme, the P-DAO updates only one node, in 1310 which case it contains only one VIO. Hmm... how does this work given how the egres is meant to not install route state, so if you want to fix up some intermediate segments, then the egres of that fixup VIO, which is not the final egres of the full VIO would from the prior explanation have to invoke its function of checking the targets reachability, but not to establish storing mode state. Some more explanation here might be helpful. I think his can work, but i think the egres of a fixup VIO needs to be careful and behave differently to a non-fixup actual track egres. 1311 1312 In case of a forwarding error along an Storing-Mode P-Route, the node 1313 that fails to forward SHOULD send an ICMP error with a code "Error in 1314 Projected Route" to the Root. Failure to do so may result in packet 1315 loss and wasted resources along the Projected Route that is broken. 1316 1317 7.3.2. Non-Storing-Mode P-Route 1318 1319 As illustrated in Figure 10, a P-DAO that carries an SR-VIO enables 1320 the Root to install a source-routed path from a Track Ingress towards 1321 a Target along the main DODAG. 1349 1349 ------+--------- 1350 | Internet 1351 | 1352 +-----+ 1353 | | Border Router 1354 | | (RPL Root) 1355 +-----+ | P ^ ACK 1356 | Track | DAO | 1357 o o o o Ingress X V | X 1358 o o o o o o o X o X Source 1359 o o o o o o o o X o o X Routed 1360 o o ° o o o o X o X Segment 1361 o o o o o o o o X Track X 1362 o o o o o Egress 1363 1364 o o o o 1365 o o o o 1366 destination 1367 1368 LLN 1369 1370 Figure 10: Projecting a Non-Storing Route So there is some attempt here to visualize the P-Route, but it mentions destination and not target, so i am again confused about the difference of those terms... Would be good to show Target(s) in the picture. 1372 When forwarding a packet to a destination for which the router which router ? The Track ingres ? 1373 determines that routing happens via a Track Target, the router "via a track target" sounds as if destination is different from trac target. What is the routing information from which that router can determine that a destination is reachable via a target ? The P-Route only signals targets, right ? 1374 inserts the Source Routing Header in the packet with the final 1375 destination at the Track Egress. encapsulates the packet with a new IPv6/SRH header ? Now it sounds as if final destination is the same as track egres, so not even target... even more confused now. 1376 1377 In order to signal the Segment, the router encapsulates the packet 1378 with an IP-in-IP header and a Routing Header as follows: It seems as if we're not discussing installation of non-storing P-Routes at all, but immediately skip to data-plane for non-storing P-Routes ? I would suggest to have even if a very short section for installation of the non-storing P-Route in one subsection and then aother subsection for the data-plane. The storing mode text above does not seem to have a dedicated data-plane subsecton too, so quite inconsistent... 1379 1380 * In the uncompressed form the source of the packet is this router, this router... 1381 the destination is the first Via Address in the SR-VIO, and the RH 1382 is a Source Routing Header (SRH) [RFC6554] that contains the list 1383 of the remaining Via Addresses terminating by the Track Egress. 1384 1385 * The preferred alternate in a network where 6LoWPAN Header 1386 Compression [RFC6282] is used is to leverage "IPv6 over Low-Power 1387 Wireless Personal Area Network (6LoWPAN) Paging Dispatch" 1388 [RFC8025] to compress the RPL artifacts as indicated in [RFC8138]. 1389 1390 In that case, the source routed header is the exact copy of the 1391 (chain of) SRH-6LoRH found in the SR-VIO, also terminating by the 1392 Track Egress. The RPI-6LoRH is appended next, followed by an IP- 1393 in-IP 6LoRH Header that indicates the Ingress Router in the 1394 Encapsulator Address field, see as a similar case Figure 20 of 1395 [TURN-ON_RFC8138]. I will trust this is correct, as i can not verify this quickly due to my lack of this encap details. 1404 1405 In the case of a loose source-routed path, there MUST be either a 1406 segment for the same Track to the loose next hop, on which case the 1407 packet is forwarded to the next hop along that segment, a common 1408 neighbor with the loose next hop, on which case the packet is 1409 forwarded to that neighbor, or another Track to the loose next hop 1410 for which this node or a neighbor is Ingress. In the latter case, 1411 another encapsulation takes place and the process possibly recurses; 1412 otherwise the packet is dropped. I can not comment on this because i am still lost as to the semantic of segment given he absence of any illustrative pictures for multi-segment Tracks so far in the document. 1414 In case of a forwarding error along a Source Route path, the node 1415 that fails to forward SHOULD send an ICMP error with a code "Error in 1416 Source Routing Header" back to the source of the packet, as described 1417 in section 11.2.2.3. of [RPL]. Upon this message, the encapsulating 1418 node SHOULD stop using the source route path for a period of time and How long should that period be. Elaborate for how the encapsulating node should determine the period. 1419 it SHOULD send an ICMP message with a Code "Error in Projected Route" 1420 to the Root. Failure to follow these steps may result in packet loss 1421 and wasted resources along the source route path that is broken. 1422 1423 7.4. Forwarding Along a Track In 7.3.2 you already detail parts of this. Again, i would strongly suggest to revert order, with this section first, before getting into the currently earlier stated details. 1425 This draft leverages the RPL Forwarding model follows: 1426 1427 * In the data packets, the Track DODAGID and the TrackID MUST be 1428 respectively signaled as the IPv6 Source Address and the 1429 RPLInstanceID field of the RPI that MUST be placed in the outer 1430 chain of IPv6 Headers. I think an outer chain(mail) can be found as an armor on medieval knights, but in our case i think it is the outer header of the packets chain of IPv6 headers. 1432 The RPI carries a local RPLInstanceID called the TrackID, which, 1433 in association with the DODAGID, indicates the Track along which 1434 the packet is forwarded. 1435 1436 The D flag in the RPLInstanceID MUST be set to 0 to indicate that 1437 the source address in the IPv6 header is set ot the DODAGID, more ^^ 1438 in Section 7.4. This is section 7.4. 1439 1440 * This draft conforms the principles of [USEofRPLinfo] with regards ^ to 1441 to packet forwarding and encapsulation along a Track. 1442 1443 - In that case, the Track is the DODAG, the Track Ingress is the In the case where the Track is the main DODAG ... ? 1444 Root, and the Track Egress is a RAL, and neighbors of the Track Is there any reason why to say RAL instead of node ? First time you use RAL, so wondering. 1445 Egress that can be reached via the Track are RULs. The 1446 encapsulation rules in [USEofRPLinfo] apply. Not sure what RFC editor says, but given how RAL/RUL are first mentioned here, even though they are listed in glossary, expanding them here can not hurt. I think you may want to find a place early in he document where you want to say that "node" without qualification in this doc mean RAN, maybe also add to glossary. It would be helpfull to clariy what i think this section wants to say without hoping that readers can / want to deduce it from [UseofRPLinfo]. How about the following table: Node role Supported node type Track ingres RAN Track midpoint RAN Track egres RAN, RAL Neighbor of track egres RAN, RAL, RUL (hope this is roughly ok, else fix up). 1448 - If the Track Ingress is the originator of the packet and the 1449 Track Egress is the destination of the packet, there is no need 1450 for an encapsulation. 1451 1459 1460 1461 - So the Track Ingress must encapsulate the traffic that it did 1462 not originate, and add an RPI in any fashion. 1463 1464 A packet that is being routed over the RPL Instance associated to 1465 a first Non-Storing Mode Track MAY be placed (encapsulated) in a 1466 second Track to cover one loose hop of the first Track. On the I can not follow this explanation without an example picture. When reading it, the first thing that comes to mind is that it sounds as if i could have sequential second Tracks in different RPL Instances, but it is unclear whether this is is a predondition of this case of whether its irrelevant. 1466 second Track to cover one loose hop of the first Track. On the 1467 other hand, a Storing Mode Track must be strict and a packet that 1468 it placed in a Storing Mode Track MUST follow that Track till the :%s/\/until/g Don't speak emacs. 1469 Track Egress. 1470 1471 When a Track Egress extracts a packet from a Track (decapsulates 1472 the packet), the Destination of the inner packet MUST be either 1473 this node or a direct neighbor, or a Target of another Segment of 1474 the same Track for which this node is ingress, otherwise the 1475 packet MUST be dropped. .... and (see reference) ICMP must be raied according to... etc. pp ?! This last paragraph should really be as early in the document as possible. 1476 1477 All properties of a Track operations are inherited form the main RPL 1478 Instance that is used to install the Track. For instance, the use of 1479 compression per [RFC8138] is determined by whether it is used in the 1480 main instance, e.g., by setting the "T" flag [TURN-ON_RFC8138] in the 1481 RPL configuration option. Can there be multiple main instances ? If so, that should be mentioned and maybe an example given. 1482 1483 8. Profiles 1484 1485 This document provides a set of tools that may or may not be needed 1486 by an implementation depending on the type of application it serves. 1487 This sections described profiles that can be implemented separately 1488 and can be used to discriminate what an implementation can and cannot 1489 do. 1490 1491 Profile 0 Profile 0 is the legacy support of [RPL] Non-Storing Mode. 1492 It provides the minimal common functionality that must be 1493 implemented as a prerequisite to all the Track-supporting 1494 profiles. The other Profiles extend Profile 0 with selected 1495 capabilities that this specification introduces on top. Is this profile a term estblished outside this document already, then please do provide reference. If it is only introuced in this document, then what exactly needs to be implemented for it ? Let me guss: This is a new definition in this document, and it refers to nodes that do not implement anything from this draft, but only RPL NSM acccording to (fill in, best with section), and to deploy any of this documents technology, ALL RAL in the network MUST implement Profile 0 or better. Or maybe not... Maybe only RAL that are used to pass P-Route traffic MUST be Profile 0 or better ?! If i am guessing right than my prior paragraphs text might be a better starting point with less gussing. 1496 1497 Profile 1 (Storing-Mode P-Route Segments along the main DODAG) Profi 1498 le 1 does not create new paths; it combines Storing and Non- 1499 Storing Modes to balance the size of the routing header in the 1500 packet and the amount of state in the intermediate routers in a 1501 Non-Storing Mode RPL DODAG. You should be able to state exactly what part of this spec a node MUST/SHOULD implement to be in compliance with Profile 1. Same is true for the other profiles. Might be difficult to structure the documents into subsections such that you can list those subsections that are required (incrementally) for each Profile, but otherwise its really hard to figure out if or if not an implementation is compliant with a profile. 1503 Profile 2 (Non-Storing-Mode P-Route Segments along the main DODAG) P 1504 rofile 2 extends Profile 0 with Strict Source-Routing Non-Storing- Can you try to persuade tools to not split words (P rofile) ? 1505 Mode Projected Routes along the main DODAG. Profile 2 provides 1506 the same capability to compress the SRH in packets down the main 1507 DODAG as Profile 1, but it require an encapsulation, in order to 1508 insert an additional SRH between the loose source routing hops. 1509 1517 Profile 3 Profile 3 and above build Tracks that do not necessarily 1518 follow the main DODAG. In order to form the best path possible, ^ ? DODAG ? "best possible" is unexplained. Might be good to give (maybe textual is sufficient) the most simple example of how an additional DODAG/TrackID would be limited if it can not support Sibling Information Option. This might be obvious to RPL experts of course.. 1519 those Profiles require the support of Sibling Information Option 1520 to inform the Root of additional possible hops. Profile 3 extends 1521 Profile 1 with additional Storing-Mode Projected Routes that 1522 install segments that do not follow the main DODAG. If the 1523 Segment Ingress (in the SF-VIO) is the same as the IPv6 Address of 1524 the Track Ingress (in the projected DAO base Object), the P-DAO 1525 creates an implicit Track between the Segment Ingress and the 1526 Segment Egress. 1527 1528 Profile 4 Profile 4 extends Profile 2 with Strict Source-Routing 1529 Non-Storing-Mode Projected Routes to form Tracks inside the main 1530 DODAG. A Track is formed as one or more strict source source 1531 routed paths between the Root that is the Track Ingress, and the 1532 Track Egress that is the last node Why is this Profile 4 when Profile 3 says that all further profiles do not necessarily follow the main DODAG ? Aka: What would not work if you where to make 4 become eg.: 2.5 ? 1534 Profile 5 Profile 5 Combines Profile 4 with Profile 1 and enables to 1535 loose source routing between the Ingress and the Egress of the 1536 Track. As in Profile 1, Storing-Mode Projected Routes connect the 1537 dots in the loose source route. 1538 1539 Profile 6 Profile 6 Combines Profile 4 with Profile 2 and also 1540 enables to loose source routing between the Ingress and the Egress 1541 of the Track. How about a table where rows are features, columns profiles and intersections checkmarks ? Right now i am lost in the details. 1542 1543 9. Example Track Signaling 1544 1545 The remainder of the section provides an example of how a Track can 1546 be signaled 1547 1548 ===> F 1549 A ===> B ===> C ===> D===> E < 1550 ===> G 1551 1552 1553 Figure 11: Reference Track 1554 1555 A is Track ingress, E is track Egress. C is stitching point. F and First time "stitching point" is used. Can you avoid a new term here ? Else explain. 1556 G are E's neighbors, "external" to the Track, and reachable from A 1557 over the Track A->E. I guess this is a two-segment Track with one segment A-...>C and one segment C-...>E. What is the "<" after E good for ? Why use the same symbol ===> for track and for getting from E to F, G ? Are F and G Targets and/or destinations ? Please introduce those terms into the example. How about indicating both the physical connectivity with "---" and the track with "===>" Also show / disinguish the two segments accordingly through better ASCII graphics. 1558 1559 In a general manner we want: 1560 1561 * P-DAO 1 signals C==>B==>E I hope B should be D, else i am heck more confused. Please say what this signaling establishes. We learned in before that a P-DAO has not only a VIO, but also some targets. So what are the targets of this P-DAO ? 1562 1563 * P-DAO 2 signals A==>B==>C Likewise 1573 * P-DAO 3 signals F and G via the A==>E Track What does hthis mean ? Whats the entry, whats the exit ? whats the VIO, whats the target of P-DAO 3 ? 1575 P-DAO 3 being loose, it can only be non-storing. Note that since the 1576 Root is always the ingress of a Track, and all SR-VIOs are now Track, ^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^ Which root ? the root of the main DODA ? I don't parse the second ^^^^ either. 1577 the Root being signaled in the DAO base object can now be elided in 1578 the VIA list in SR-VIO. This enables the construction by the main 1579 root of the RFC 8138 optimized SRH-6LoRH in the SR-VIO, to be placed 1580 as is in the packet by the Root. I can not follow that paragraph. Would it be posible to constrain the example to not also include the SRH-6LoRH complexity, given how its an option ? One step at a time ? 1581 1582 9.1. Using Storing-Mode Segments 1583 1584 A==>B==>C and C==>D==>E are segments of a same Track. Note that the See above. his explanation comes too late. 1585 storing mode signaling imposes strict continuity in a segment. One ^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^ steering So i am confused if actually the storing mode signaling imposes that strict steering. I guess if i start from the egres, and it wants to forward the P-DAO to the prior hop node in the VIO, if that prior hop is a neighbor, then it would send the P-DAO directly to that neighbor, but if it is not a direct neighbor, it would need to go through the root. I guess this is 101 knowledge from RFC6550, so if i had the time to read anothe 150 pages, i might be able to deduce that, but i guess it wouldn't hurt to put the same explanation into th text, e.g.: P-DAO must be sent directly from each segment node to its prior segment node, and in a non-storing DODAG, this is only possible if they are neighbors. Also: One of the fundamental explanations missing is the definition of the relationship between a segment and a P-Route. The way i figure, a P-DAO is (segment, {targets}) and represents a set of P-routes { targetI -> segment } targetI in {targets}). And then definition of tracks as composed of sequences of P-routes constructed from likely trees of P-DAO Or something like that... 1586 benefit of strict routing is that loops are avoided along the Track. As long as the underlying topology does not change and direct neigbors start to becom non-diret neighbors. In which case i think the segment wold need to be immediately invalidated. But the question raised in before about ICMP errors is valid, especially when i think about path divesity forwarding. In path diversity you often do NOT want to have traffic triggered errors, but jus sit out the error, even if that trafic gets dropped somehwere along the path. Any desirable repair to do on the topolocy could/should come ffom non-traffic trigers, such as neighbor tracking to the management plane. Is there any way for traffic itself in the Routing information header to indicate if it does or does not want to get ICMP indications when it fails to get forwarded ? That would be ideal to distingish between non-redundant and redundant traffic ICMP reaction... 1587 1588 9.1.1. Stitched Segments Sequential ? 1589 1590 Storing-Mode P-DAO 1 and 2 are sent to E and C, as follows: 1591 1592 +===============+==============+==============+ 1593 | Field | P-DAO 1 to E | P-DAO 2 to C | 1594 +===============+==============+==============+ 1595 | Mode | Storing | Storing | 1596 +---------------+--------------+--------------+ 1597 | Track Ingress | A | A | 1598 +---------------+--------------+--------------+ 1599 | TrackID | (A, 129) | (A, 129) | 1600 +---------------+--------------+--------------+ 1601 | VIO | C, D, E | A, B, C | 1602 +---------------+--------------+--------------+ 1603 | Targets | E, F, G | E, F, G | 1604 +---------------+--------------+--------------+ 1605 1606 Table 1: P-DAO Messages Please add a line showing the SegmentID of the VIO so its clear how the P-DAO are distinguished. I guess that is the identifier used, right ? If this example is pimped up as asked for above, it would make a good intro example, although it does not cover all options. But at last the fact that the track ingres for the secnd (C,D,E) segment is still A was not clear to me in before. Also, i guess that if the track was more of a tree, then the targets of some earlier segments wold be a superset of the targets of later segments at a branching point. 1608 As a result the RIBs are set as follows: 1609 1629 +======+=============+=========+=============+==========+ 1630 | Node | Destination | Origin | Next Hop(s) | TrackID | 1631 +======+=============+=========+=============+==========+ 1632 | E | F, G | P-DAO 1 | Neighbor | (A, 129) | But E would know about F and G alrady before P-DAO 1, so i wonder... he example didn't call out which DODAG we're forwarding across. I guess this is a sequental Track, which the example also does not say. In any case, instead of saying just "Destination", it would be good to say Destination in which context in the table. "Destination in RPLInstance TrackID1 ???" Q: If this is not in the main DODAG, but in that TrackID1 DODAG, and we didn't send any P-DAO yet. Can we actually send/deliver packets ? I guess no, right ? So what seems to happen is that we first have some F, G neighbor information from the main DODAG, and because of P-DAO 1, this information is inherited into the forwarding for TrackID1 DODAG ? That would be good to show, or explain. Also, given how you previously whee pointing out that these routes are used over routes to the node because of prefix-length, should the entries in the destination not rather read F/128, G/128, likewise for all the other entries below ? Or does RPL imply fixed /128 unless its a /0 ? default route to the root ? Also: TrackID is 129 i think. (A, 129) seems to be the DODAG (Identifier?). So maybe rename or rewrite accordingly. 1633 +------+-------------+---------+-------------+----------+ 1634 | D | E | P-DAO 1 | Neighbor | (A, 129) | 1635 +------+-------------+---------+-------------+----------+ 1636 | " | F, G | P-DAO 1 | E | (A, 129) | 1637 +------+-------------+---------+-------------+----------+ 1638 | C | D | P-DAO 1 | Neighbor | (A, 129) | 1639 +------+-------------+---------+-------------+----------+ 1640 | " | E, F, G | P-DAO 1 | D | (A, 129) | 1641 +------+-------------+---------+-------------+----------+ 1642 | B | C | P-DAO 2 | Neighbor | (A, 129) | 1643 +------+-------------+---------+-------------+----------+ 1644 | " | E, F, G | P-DAO 2 | C | (A, 129) | 1645 +------+-------------+---------+-------------+----------+ 1646 | A | B | P-DAO 2 | Neighbor | (A, 129) | 1647 +------+-------------+---------+-------------+----------+ 1648 | A | E, F, G | P-DAO 2 | B | (A, 129) | 1649 +------+-------------+---------+-------------+----------+ 1650 1651 Table 2: RIB setting 1652 1653 E recognizes that it is the Track Egress because it is both a Target 1654 and a Segment Endpoint. ... of P-DAO 1 ? What would happen if E was not listed as a Target in P-DAO 2 ? Would that impact the ability to deliver packets to F, G via (A, 129) ? If so, why ? If its possible to deliver to (F,G) without indicating E in target list, hen i think the statement is wrong. And i can't see how the logic works. Lets assume C has a neighbor H, so now we set the targets for P-DAO 2 to E,F,G,H. How would the notion of including C into this target list help C to decide wheher to deliver packets to H directly instead of leting them maybe go through further segments ? Aka: It seems to me that if the logic is that if you are sement endpoint, and any track egres for that segments P-DAO is a neighbor in the main dodag, then you do forward directly to that target. Yes/No/Maybe ? ;-)) Also: I think there should be some "Punt" line in the FIB on E for E as a target. And it seems to me that that Punt line would be created by including the segment endpoint into the target list. Maybe one does not want to be able to address a segment endpoint via the Track DODAG... 1656 Packets originated by A to E, F, or G, do not require an ^^^ from a source X via 1657 encapsulation. In any fashion, the outer headers of the packets that ^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ remove how about "any additional encapsulation beside the one outer encapsulation required for non-storage-mode" ? Because immediately following you do write and show that outer encapsulation header. 1657 encapsulation. In any fashion, the outer headers of the packets that 1658 are forwarded along the Track have the following settings: 1659 1660 +========+===================+===================+================+ 1661 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1662 +========+===================+===================+================+ 1663 | Outer | A | E, F or G | (A, 129) | 1664 +--------+-------------------+-------------------+----------------+ 1665 | Inner | X != A | E, F or G | N/A | 1666 +--------+-------------------+-------------------+----------------+ Maybe add note: The Inner header is only required for X != A. 1667 1668 Table 3: Packet header settings 1669 1670 As an example, say that A has a packet for F. Using the RIB above: 1671 1672 * From P-DAO 2: A forwards to B and B forwards to C. 1673 1674 * From P-DAO 1: C forwards to D and D forwards to E. 1675 1676 * From Neighbor Cache Entry: C delivers the packet to F. ^ E ? But see above, your FIB shows that E -> F as part of (A, 129), whereas the neighbor cache entry is probably independent of 129, right ? So one of those statements (table or neighbor-cache-entry) is wrong. 1685 9.1.2. External routes ^^^^^^^^^^^^^^^ New term not used in before. Explain. 1687 Storing-Mode P-DAO 1 and 2, and Non-Storing-Mode P-DAO 3, are sent to 1688 E, C and A, respectively, as follows: 1689 1690 +===============+==============+==============+==============+ 1691 | | P-DAO 1 to E | P-DAO 2 to C | P-DAO 3 to A | 1692 +===============+==============+==============+==============+ 1693 | Mode | Storing | Storing | Non-Storing | 1694 +---------------+--------------+--------------+--------------+ 1695 | Track Ingress | A | A | A | 1696 +---------------+--------------+--------------+--------------+ 1697 | TrackID | (A, 129) | (A, 129) | (A, 129) | 1698 +---------------+--------------+--------------+--------------+ 1699 | VIO | C, D, E | A, B, C | E | 1700 +---------------+--------------+--------------+--------------+ 1701 | Targets | E | E | F, G | 1702 +---------------+--------------+--------------+--------------+ Some explanation about the purpose of this example would be useful. Seems to be something like. In this example, we want to avoid creating state for F,G on B,C,D. We do this by using the two storing mode segmnts P-DAO1 and P-DAO 2 to reach E and a non-storing segment P-DAO 3 to reach F and G. I am not clear why P-DAO 3 needs to be non-storing though. What would happen if the only change to above was to indicate P-DAO 3 as storing ? aka: why would B,C,D need to bother about any Target list of segments that they are not on ? 1704 Table 4: P-DAO Messages 1705 1706 As a result the RIBs are set as follows: 1707 1708 +======+=============+=========+=============+==========+ 1709 | Node | Destination | Origin | Next Hop(s) | TrackID | 1710 +======+=============+=========+=============+==========+ 1711 | E | F, G | P-DAO 1 | Neighbor | (A, 129) | ^^^^^^^ Shouldn't this be P-DAO 3 ?? 1712 +------+-------------+---------+-------------+----------+ 1713 | D | E | P-DAO 1 | Neighbor | (A, 129) | 1714 +------+-------------+---------+-------------+----------+ 1715 | C | D | P-DAO 1 | Neighbor | (A, 129) | 1716 +------+-------------+---------+-------------+----------+ 1717 | " | E | P-DAO 1 | D | (A, 129) | 1718 +------+-------------+---------+-------------+----------+ 1719 | B | C | P-DAO 2 | Neighbor | (A, 129) | 1720 +------+-------------+---------+-------------+----------+ 1721 | " | E | P-DAO 2 | C | (A, 129) | 1722 +------+-------------+---------+-------------+----------+ 1723 | A | B | P-DAO 2 | Neighbor | (A, 129) | 1724 +------+-------------+---------+-------------+----------+ 1725 | A | E | P-DAO 2 | B | (A, 129) | 1726 +------+-------------+---------+-------------+----------+ 1727 | A | F, G | P-DAO 3 | E | (A, 129) | 1728 +------+-------------+---------+-------------+----------+ 1729 1730 Table 5: RIB setting 1731 1741 Packets from A to E do not require an encapsulation. In any fashion, ^^^^^^^^^^^^^ ^^^^^^^^^^^^^^ delete Inner Header 1742 the outer headers of the packets that are forwarded along the Track 1743 have the following settings: 1744 1745 +========+===================+====================+================+ 1746 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1747 +========+===================+====================+================+ 1748 | Outer | A | E | (A, 129) | 1749 +--------+-------------------+--------------------+----------------+ 1750 | Inner | X | E (X != A), F or G | N/A | 1751 +--------+-------------------+--------------------+----------------+ 1752 1753 Table 6: Packet header settings 1754 1755 As an example, say that A has a packet for F. Using the RIB above: 1756 1757 * From P-DAO 3: A encapsulates the packet the Track signaled by ^ for ^ (A,129) 1758 P-DAO 3, with the outer header above. Now the packet destination 1759 is E. ^ of the Outer Header 1760 1761 * From P-DAO 2: A forwards to B and B forwards to C. 1762 1763 * From P-DAO 1: C forwards to D and D forwards to E; E decapsulates 1764 the packet. ^ because it is the destination of the Outer Header ?? AND ? a valid target for (A, 129) ??? (see question above 1765 1766 * From Neighbor Cache Entry: C delivers packets to F or G. 1767 1768 9.1.3. Segment Routing New term not used in before in this doc, define, reference (RFC8402 ?), etc. pp. 1770 Storing-Mode P-DAO 1 and 2, and Non-Storing-Mode P-DAO 3, are sent to 1771 E, B and A, respectively, as follows: Again: Please add purpose/goal of this example. If you did improve initial picture to show segments, then of course these ar different now. 1773 +===============+==============+==============+==============+ 1774 | | P-DAO 1 to E | P-DAO 2 to B | P-DAO 3 to A | 1775 +===============+==============+==============+==============+ 1776 | Mode | Storing | Storing | Non-Storing | 1777 +---------------+--------------+--------------+--------------+ 1778 | Track Ingress | A | A | A | 1779 +---------------+--------------+--------------+--------------+ 1780 | TrackID | (A, 129) | (A, 129) | (A, 129) | 1781 +---------------+--------------+--------------+--------------+ 1782 | VIO | C, D, E | A, B | C, E | 1783 +---------------+--------------+--------------+--------------+ 1784 | Targets | E | B, C | F, G | 1785 +---------------+--------------+--------------+--------------+ 1786 1787 Table 7: P-DAO Messages Does this example only work with B being the exit node for P-DAO2, or could it equally work if we kept P-DAO 2 unchanged, ending at C, but the target only being C ? I am guessing it could be, given how C would also need to look into P-DAO1 route towards E, right ? Aka: Minimal change over prior example might make it easier.. 1797 As a result the RIBs are set as follows: 1798 1799 +======+=============+=========+=============+==========+ 1800 | Node | Destination | Origin | Next Hop(s) | TrackID | 1801 +======+=============+=========+=============+==========+ 1802 | E | F, G | P-DAO 1 | Neighbor | (A, 129) | 1803 +------+-------------+---------+-------------+----------+ 1804 | D | E | P-DAO 1 | Neighbor | (A, 129) | 1805 +------+-------------+---------+-------------+----------+ 1806 | C | D | P-DAO 1 | Neighbor | (A, 129) | 1807 +------+-------------+---------+-------------+----------+ 1808 | " | E | P-DAO 1 | D | (A, 129) | 1809 +------+-------------+---------+-------------+----------+ 1810 | B | C | P-DAO 2 | Neighbor | (A, 129) | 1811 +------+-------------+---------+-------------+----------+ 1812 | A | B | P-DAO 2 | Neighbor | (A, 129) | 1813 +------+-------------+---------+-------------+----------+ 1814 | " | C | P-DAO 2 | B | (A, 129) | 1815 +------+-------------+---------+-------------+----------+ 1816 | " | E, F, G | P-DAO 3 | C, E | (A, 129) | 1817 +------+-------------+---------+-------------+----------+ 1818 1819 Table 8: RIB setting 1820 1821 Packets from A to E do not require an encapsulation, but carry a SRH a third header instead of encap ? 1822 via C. In any fashion, the outer headers of the packets that are 1823 forwarded along the Track have the following settings: 1824 1825 +========+===================+====================+================+ 1826 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | ^^^^^^^^^^^^^^^^^ the SRH for th Outer Header is not just an Pv6 Dest. Addr. 1827 +========+===================+====================+================+ 1828 | Outer | A | C till C then E | (A, 129) | 1829 +--------+-------------------+--------------------+----------------+ 1830 | Inner | X | E (X != A), F or G | N/A | 1831 +--------+-------------------+--------------------+----------------+ 1832 1833 Table 9: Packet header settings 1834 1835 As an example, say that A has a packet for F. Using the RIB above: 1836 1837 * From P-DAO 3: A encapsulates the packet the Track signaled by 1838 P-DAO 3, with the outer header above. Now the destination in the 1839 IPv6 Header is C, and a SRH signals the final destination is E. 1840 1841 * From P-DAO 2: A forwards to B and B forwards to C. 1842 1843 * From P-DAO 3: C processes the SRH and sets the destination in the 1844 IPv6 Header to E. 1845 1853 * From P-DAO 1: C forwards to D and D forwards to E; E decapsulates 1854 the packet. 1855 1856 * From the Neighbor Cache Entry: C delivers packets to F or G. 1857 1858 9.2. Using Non-Storing-Mode joining Tracks 1859 1860 A==>B==>C and C==>D==>E are Tracks expressed as non-storing P-DAOs. 1861 1862 9.2.1. Stitched Tracks sequential Tracks ? 1864 Non-Storing Mode P-DAO 1 and 2 are sent to C and A respectively, as 1865 follows: 1866 1867 +===============+==============+==============+ 1868 | | P-DAO 1 to C | P-DAO 2 to A | 1869 +===============+==============+==============+ 1870 | Mode | Non-Storing | Non-Storing | 1871 +---------------+--------------+--------------+ 1872 | Track Ingress | C | A | 1873 +---------------+--------------+--------------+ 1874 | TrackID | (C, 131) | (A, 129) | 1875 +---------------+--------------+--------------+ 1876 | VIO | D, E | B, C | 1877 +---------------+--------------+--------------+ 1878 | Targets | F, G | E, F, G | 1879 +---------------+--------------+--------------+ WOuld it be possible for both DAO to have the same number (129) given how they are disambiguated by the source address ? If so i think it would strenthen the example by doing so and highlighting that these are not the same Tracks anymore, even if they reuse the same TrackID. 1880 1881 Table 10: P-DAO Messages 1882 1883 As a result the RIBs are set as follows: 1884 1885 1886 1887 1888 1889 1890 1891 1892 1893 1894 1895 1896 1897 1898 1899 1900 1901 1902 1903 1904 Thubert, et al. Expires 28 January 2022 [Page 34] 1905 1906 Internet-Draft DAO Projection July 2021 1907 1908 1909 +======+=============+=========+=============+==========+ 1910 | Node | Destination | Origin | Next Hop(s) | TrackID | 1911 +======+=============+=========+=============+==========+ 1912 | E | F, G | ND | Neighbor | Any | 1913 +------+-------------+---------+-------------+----------+ 1914 | D | E | ND | Neighbor | Any | 1915 +------+-------------+---------+-------------+----------+ 1916 | C | D | ND | Neighbor | Any | 1917 +------+-------------+---------+-------------+----------+ 1918 | " | E, F, G | P-DAO 1 | D, E | (C, 131) | 1919 +------+-------------+---------+-------------+----------+ 1920 | B | C | ND | Neighbor | Any | 1921 +------+-------------+---------+-------------+----------+ 1922 | A | B | ND | Neighbor | Any | 1923 +------+-------------+---------+-------------+----------+ 1924 | " | C, E, F, G | P-DAO 2 | B, C | (A, 129) | 1925 +------+-------------+---------+-------------+----------+ 1926 1927 Table 11: RIB setting 1928 1929 Packets from A to E, F and G do not require an encapsulation, though 1930 it is preferred that A encapsulates and C decapsulates. Either way, 1931 they carry a SRH via B and C, and C needs to encapsulate to E, F, or 1932 G to add an SRH via D and E. The encapsulating headers of packets 1933 that are forwarded along the Track between C and E have the following 1934 settings: 1935 1936 +========+===================+===================+================+ 1937 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1938 +========+===================+===================+================+ 1939 | Outer | C | D till D then E | (C, 131) | 1940 +--------+-------------------+-------------------+----------------+ 1941 | Inner | X | E, F, or G | N/A | 1942 +--------+-------------------+-------------------+----------------+ 1943 1944 Table 12: Packet header settings 1945 1946 As an example, say that A has a packet for F. Using the RIB above: 1947 1948 * From P-DAO 2: A encapsulates the packet with destination of F in 1949 the Track signaled by P-DAO 2. The outer header has source A, 1950 destination B, an SRH that indicates C as the next loose hop, and 1951 a RPI indicating a TrackId of 129 from A's namespace. 1952 1953 * From the SRH: Packets forwarded by B have source A, destination C 1954 , a consumed SRH, and a RPI indicating a TrackId of 129 from A's 1955 namespace. C decapsulates. 1956 1965 * From P-DAO 1: C encapsulates the packet with destination of F in 1966 the Track signaled by P-DAO 1. The outer header has source C, 1967 destination D, an SRH that indicates E as the next loose hop, and 1968 a RPI indicating a TrackId of 131 from C's namespace. E 1969 decapsulates. 1970 1971 9.2.2. External routes sequential tracks with external routes ? 1972 1973 Non-Storing Mode P-DAO 1 is sent to C and Non-Storing Mode P-DAO 2 1974 and 3 are sent A, as follows: 1975 1976 +===============+==============+==============+==============+ 1977 | | P-DAO 1 to C | P-DAO 2 to A | P-DAO 3 to A | 1978 +===============+==============+==============+==============+ 1979 | Mode | Non-Storing | Non-Storing | Non-Storing | 1980 +---------------+--------------+--------------+--------------+ 1981 | Track Ingress | C | A | A | 1982 +---------------+--------------+--------------+--------------+ 1983 | TrackID | (C, 131) | (A, 129) | (A, 141) | 1984 +---------------+--------------+--------------+--------------+ 1985 | VIO | D, E | B, C | E | 1986 +---------------+--------------+--------------+--------------+ 1987 | Targets | E | E | F, G | 1988 +---------------+--------------+--------------+--------------+ 1989 1990 Table 13: P-DAO Messages 1991 1992 As a result the RIBs are set as follows: 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 Thubert, et al. Expires 28 January 2022 [Page 36] 2017 2018 Internet-Draft DAO Projection July 2021 2019 2020 2021 +======+=============+=========+=============+==========+ 2022 | Node | Destination | Origin | Next Hop(s) | TrackID | 2023 +======+=============+=========+=============+==========+ 2024 | E | F, G | ND | Neighbor | Any | 2025 +------+-------------+---------+-------------+----------+ 2026 | D | E | ND | Neighbor | Any | 2027 +------+-------------+---------+-------------+----------+ 2028 | C | D | ND | Neighbor | Any | 2029 +------+-------------+---------+-------------+----------+ 2030 | " | E | P-DAO 1 | D, E | (C, 131) | 2031 +------+-------------+---------+-------------+----------+ 2032 | B | C | ND | Neighbor | Any | 2033 +------+-------------+---------+-------------+----------+ 2034 | A | B | ND | Neighbor | Any | 2035 +------+-------------+---------+-------------+----------+ 2036 | " | C, E | P-DAO 2 | B, C | (A, 129) | 2037 +------+-------------+---------+-------------+----------+ 2038 | " | F, G | P-DAO 3 | E | (A, 141) | 2039 +------+-------------+---------+-------------+----------+ 2040 2041 Table 14: RIB setting 2042 2043 The encapsulating headers of packets that are forwarded along the 2044 Track between C and E have the following settings: 2045 2046 +========+===================+===================+================+ 2047 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 2048 +========+===================+===================+================+ 2049 | Outer | C | D till D then E | (C, 131) | 2050 +--------+-------------------+-------------------+----------------+ 2051 | Middle | A | E | (A, 141) | 2052 +--------+-------------------+-------------------+----------------+ 2053 | Inner | X | E, F or G | N/A | 2054 +--------+-------------------+-------------------+----------------+ 2055 2056 Table 15: Packet header settings 2057 2058 As an example, say that A has a packet for F. Using the RIB above: 2059 2060 * From P-DAO 3: A encapsulates the packet with destination of F in 2061 the Track signaled by P-DAO 3. The outer header has source A, 2062 destination E, and a RPI indicating a TrackId of 141 from A's 2063 namespace. This recurses with: 2064 2065 * From P-DAO 2: A encapsulates the packet with destination of E in 2066 the Track signaled by P-DAO 2. The outer header has source A, 2067 destination B, an SRH that indicates C as the next loose hop, and 2068 a RPI indicating a TrackId of 129 from A's namespace. 2069 2070 2071 2072 Thubert, et al. Expires 28 January 2022 [Page 37] 2073 2074 Internet-Draft DAO Projection July 2021 2075 2076 2077 * From the SRH: Packets forwarded by B have source A, destination C 2078 , a consumed SRH, and a RPI indicating a TrackId of 129 from A's 2079 namespace. C decapsulates. 2080 2081 * From P-DAO 1: C encapsulates the packet with destination of E in 2082 the Track signaled by P-DAO 1. The outer header has source C, 2083 destination D, an SRH that indicates E as the next loose hop, and 2084 a RPI indicating a TrackId of 131 from C's namespace. E 2085 decapsulates. 2086 2087 9.2.3. Segment Routing segment routing with exernal routes ? 2088 2089 Non-Storing Mode P-DAO 1 is sent to C and Non-Storing Mode P-DAO 2 2090 and 3 are sent A, as follows: 2091 2092 +===============+==============+==============+==============+ 2093 | | P-DAO 1 to C | P-DAO 2 to A | P-DAO 3 to A | 2094 +===============+==============+==============+==============+ 2095 | Mode | Non-Storing | Non-Storing | Non-Storing | 2096 +---------------+--------------+--------------+--------------+ 2097 | Track Ingress | C | A | A | 2098 +---------------+--------------+--------------+--------------+ 2099 | TrackID | (C, 131) | (A, 129) | (A, 141) | 2100 +---------------+--------------+--------------+--------------+ 2101 | VIO | D, E | B | C, E | 2102 +---------------+--------------+--------------+--------------+ 2103 | Targets | | C | F, G | 2104 +---------------+--------------+--------------+--------------+ 2105 2106 Table 16: P-DAO Messages 2107 2108 As a result the RIBs are set as follows: 2109 2110 2111 2112 2113 2114 2115 2116 2117 2118 2119 2120 2121 2122 2123 2124 2125 2126 2127 2128 Thubert, et al. Expires 28 January 2022 [Page 38] 2129 2130 Internet-Draft DAO Projection July 2021 2131 2132 2133 +======+=============+=========+=============+==========+ 2134 | Node | Destination | Origin | Next Hop(s) | TrackID | 2135 +======+=============+=========+=============+==========+ 2136 | E | F, G | ND | Neighbor | Any | 2137 +------+-------------+---------+-------------+----------+ 2138 | D | E | ND | Neighbor | Any | 2139 +------+-------------+---------+-------------+----------+ 2140 | C | D | ND | Neighbor | Any | 2141 +------+-------------+---------+-------------+----------+ 2142 | " | E | P-DAO 1 | D, E | (C, 131) | 2143 +------+-------------+---------+-------------+----------+ 2144 | B | C | ND | Neighbor | Any | 2145 +------+-------------+---------+-------------+----------+ 2146 | A | B | ND | Neighbor | Any | 2147 +------+-------------+---------+-------------+----------+ 2148 | " | C | P-DAO 2 | B, C | (A, 129) | 2149 +------+-------------+---------+-------------+----------+ 2150 | " | E, F, G | P-DAO 3 | C, E | (A, 141) | 2151 +------+-------------+---------+-------------+----------+ 2152 2153 Table 17: RIB setting 2154 2155 The encapsulating headers of packets that are forwarded along the 2156 Track between A and B have the following settings: 2157 2158 +========+===================+===================+================+ 2159 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 2160 +========+===================+===================+================+ 2161 | Outer | A | B till D then E | (A, 129) | 2162 +--------+-------------------+-------------------+----------------+ 2163 | Middle | A | C | (A, 141) | 2164 +--------+-------------------+-------------------+----------------+ 2165 | Inner | X | E, F or G | N/A | 2166 +--------+-------------------+-------------------+----------------+ 2167 2168 Table 18: Packet header settings 2169 2170 The encapsulating headers of packets that are forwarded along the 2171 Track between B and C have the following settings: 2172 2173 2174 2175 2176 2177 2178 2179 2180 2181 2182 2183 2184 Thubert, et al. Expires 28 January 2022 [Page 39] 2185 2186 Internet-Draft DAO Projection July 2021 2187 2188 2189 +========+===================+===================+================+ 2190 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 2191 +========+===================+===================+================+ 2192 | Outer | A | C | (A, 141) | 2193 +--------+-------------------+-------------------+----------------+ 2194 | Inner | X | E, F or G | N/A | 2195 +--------+-------------------+-------------------+----------------+ 2196 2197 Table 19: Packet header settings 2198 2199 The encapsulating headers of packets that are forwarded along the 2200 Track between C and E have the following settings: 2201 2202 +========+===================+===================+================+ 2203 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 2204 +========+===================+===================+================+ 2205 | Outer | C | D till D then E | (C, 131) | 2206 +--------+-------------------+-------------------+----------------+ 2207 | Middle | A | E | (A, 141) | 2208 +--------+-------------------+-------------------+----------------+ 2209 | Inner | X | E, F or G | N/A | 2210 +--------+-------------------+-------------------+----------------+ 2211 2212 Table 20: Packet header settings 2213 2214 As an example, say that A has a packet for F. Using the RIB above: 2215 2216 * From P-DAO 3: A encapsulates the packet with destination of F in 2217 the Track signaled by P-DAO 3. The outer header has source A, 2218 destination C, an SRH that indicates E as the next loose hop, and 2219 a RPI indicating a TrackId of 141 from A's namespace. This 2220 recurses with: 2221 2222 * From P-DAO 2: A encapsulates the packet with destination of C in 2223 the Track signaled by P-DAO 2. The outer header has source A, 2224 destination B, and a RPI indicating a TrackId of 129 from A's 2225 namespace. B decapsulates forwards to C based on a sibling 2226 connected route. 2227 2228 * From the SRH: C consumes the SRH and makes the destination E. 2229 2230 * From P-DAO 1: C encapsulates the packet with destination of E in 2231 the Track signaled by P-DAO 1. The outer header has source C, 2232 destination D, an SRH that indicates E as the next loose hop, and 2233 a RPI indicating a TrackId of 131 from C's namespace. E 2234 decapsulates. 2235 Sorry, i skipped mostly across 1883 to here, running out of time. 2245 10. Security Considerations 2246 2247 It is worth noting that with [RPL], every node in the LLN is RPL- 2248 aware and can inject any RPL-based attack in the network. This draft I guss even RUL nodes, which i think came after rfc6550 could be nasty too and inject RPL messages. 2249 uses messages that are already present in RPL [RPL] with optional 2250 secured versions. The same secured versions may be used with this 2251 draft, and whatever security is deployed for a given network also 2252 applies to the flows in this draft. 2253 2254 The LLN nodes depend on the 6LBR and the RPL participants for their 2255 operation. A trust model must be put in place to ensure that the 2256 right devices are acting in these roles, so as to avoid threats such 2257 as black-holing, (see [RFC7416] section 7). This trust model could 2258 be at a minimum based on a Layer-2 Secure joining and the Link-Layer 2259 security. This is a generic 6LoWPAN requirement, see Req5.1 in 2260 Appendix B.5 of [RFC8505]. 2261 2262 In a general manner, the Security Considerations in [RPL], and 2263 [RFC7416] apply to this specification as well. The Link-Layer 2264 security is needed in particular to prevent Denial-Of-Service attacks 2265 whereby a rogue router creates a high churn in the RPL network by 2266 constantly injected forged P-DAO messages and using up all the 2267 available storage in the attacked routers. Seems like the answer is no. 2268 2269 Additionally, the trust model could include a role validation (e.g., 2270 using a role-based authorization) to ensure that the node that claims 2271 to be a RPL Root is entitled to do so. That trust should propagate 2272 from egress to ingress in the case of a Storing Mode P-DAO. In ANIMA i am pondering to get role-based certificates to enable something like this. Is there any existing solution for this ? If not, then it would be good to mention this as a gap. In general, the whole PCE based routing model does put more reliance of a trustworthy PCE into the solution, but it eliminates a lot of security attacks coming from the normal peer-2-peer routing model (i am just making this argument in my bier-te draft, ask me again, when i have read BenK's feedback ;-). But when like it seems in this solution, one mixes the tradtional non-role based signaling with PCE input then it looks like a bigge gap than in before, because now these new routes allow to potentially create even more black holes than may have been possible in before (not quite sure). In any case, you can also mention that you did try to eliminate one new type of attack by injection of duplicate addresses in tracks by mandating to discover such issue. Not sure though if this is the best set of heuristics that nodes could apply to self-defend themslfes and further hops from incorrect new messages. Miht be worth to ponder. 2273 2274 11. IANA Considerations I am not going to read this (out of time). I would suggest as mentione din before to replace all numbers with TBDi and then strongly consider early IANA allocation. That would also help a lot to resolve any possible issues with any of the registration asks by mean of the IANA/expert review ensueing. 2276 11.1. New Elective 6LoWPAN Routing Header Type 2277 2278 This document updates the IANA registry titled "Elective 6LoWPAN 2279 Routing Header Type" that was created for [RFC8138] and assigns the 2280 following value: 2281 2282 +=======+=============+===============+ 2283 | Value | Description | Reference | 2284 +=======+=============+===============+ 2285 | 7 | P-RPI-6LoRH | This document | 2286 +-------+-------------+---------------+ 2287 2288 Table 21: New Elective 6LoWPAN 2289 Routing Header Type 2290 2291 2292 2293 2294 2295 2296 Thubert, et al. Expires 28 January 2022 [Page 41] 2297 2298 Internet-Draft DAO Projection July 2021 2299 2300 2301 11.2. New Critical 6LoWPAN Routing Header Type 2302 2303 This document updates the IANA registry titled "Critical 6LoWPAN 2304 Routing Header Type" that was created for [RFC8138] and assigns the 2305 following value: 2306 2307 +=======+=============+===============+ 2308 | Value | Description | Reference | 2309 +=======+=============+===============+ 2310 | 7 | P-RPI-6LoRH | This document | 2311 +-------+-------------+---------------+ 2312 2313 Table 22: New Critical 6LoWPAN 2314 Routing Header Type 2315 2316 11.3. New Subregistry For The RPL Option Flags 2317 2318 IANA is required to create a subregistry for the 8-bit RPL Option 2319 Flags field, as detailed in Figure 2, under the "Routing Protocol for 2320 Low Power and Lossy Networks (RPL)" registry. The bits are indexed 2321 from 0 (leftmost) to 7. Each bit is tracked with the following 2322 qualities: 2323 2324 * Bit number (counting from bit 0 as the most significant bit) 2325 2326 * Indication When Set 2327 2328 * Reference 2329 2330 Registration procedure is "Standards Action" [RFC8126]. The initial 2331 allocation is as indicated in Table 26: 2332 2333 +============+======================+===============+ 2334 | Bit number | Indication When Set | Reference | 2335 +============+======================+===============+ 2336 | 0 | Down 'O' | [RFC6553] | 2337 +------------+----------------------+---------------+ 2338 | 1 | Rank-Error (R) | [RFC6553] | 2339 +------------+----------------------+---------------+ 2340 | 2 | Forwarding-Error (F) | [RFC6553] | 2341 +------------+----------------------+---------------+ 2342 | 3 | Projected-Route (P) | This document | 2343 +------------+----------------------+---------------+ 2344 2345 Table 23: Initial PDR Flags 2346 2347 2348 2349 2350 2351 2352 Thubert, et al. Expires 28 January 2022 [Page 42] 2353 2354 Internet-Draft DAO Projection July 2021 2355 2356 2357 11.4. New RPL Control Codes 2358 2359 This document extends the IANA Subregistry created by RFC 6550 for 2360 RPL Control Codes as indicated in Table 24: 2361 2362 +======+=============================+===============+ 2363 | Code | Description | Reference | 2364 +======+=============================+===============+ 2365 | 0x09 | Projected DAO Request (PDR) | This document | 2366 +------+-----------------------------+---------------+ 2367 | 0x0A | PDR-ACK | This document | 2368 +------+-----------------------------+---------------+ 2369 2370 Table 24: New RPL Control Codes 2371 2372 11.5. New RPL Control Message Options 2373 2374 This document extends the IANA Subregistry created by RFC 6550 for 2375 RPL Control Message Options as indicated in Table 25: 2376 2377 +=======+============================+===============+ 2378 | Value | Meaning | Reference | 2379 +=======+============================+===============+ 2380 | 0x0B | Stateful VIO (SF-VIO) | This document | 2381 +-------+----------------------------+---------------+ 2382 | 0x0C | Source-Routed VIO (SR-VIO) | This document | 2383 +-------+----------------------------+---------------+ 2384 | 0x0D | Sibling Information option | This document | 2385 +-------+----------------------------+---------------+ 2386 2387 Table 25: RPL Control Message Options 2388 2389 11.6. SubRegistry for the Projected DAO Request Flags 2390 2391 IANA is required to create a registry for the 8-bit Projected DAO 2392 Request (PDR) Flags field. Each bit is tracked with the following 2393 qualities: 2394 2395 * Bit number (counting from bit 0 as the most significant bit) 2396 2397 * Capability description 2398 2399 * Reference 2400 2401 Registration procedure is "Standards Action" [RFC8126]. The initial 2402 allocation is as indicated in Table 26: 2403 2404 2405 2406 2407 2408 Thubert, et al. Expires 28 January 2022 [Page 43] 2409 2410 Internet-Draft DAO Projection July 2021 2411 2412 2413 +============+========================+===============+ 2414 | Bit number | Capability description | Reference | 2415 +============+========================+===============+ 2416 | 0 | PDR-ACK request (K) | This document | 2417 +------------+------------------------+---------------+ 2418 | 1 | Requested path should | This document | 2419 | | be redundant (R) | | 2420 +------------+------------------------+---------------+ 2421 2422 Table 26: Initial PDR Flags 2423 2424 11.7. SubRegistry for the PDR-ACK Flags 2425 2426 IANA is required to create an subregistry for the 8-bit PDR-ACK Flags 2427 field. Each bit is tracked with the following qualities: 2428 2429 * Bit number (counting from bit 0 as the most significant bit) 2430 2431 * Capability description 2432 2433 * Reference 2434 2435 Registration procedure is "Standards Action" [RFC8126]. No bit is 2436 currently defined for the PDR-ACK Flags. 2437 2438 11.8. Subregistry for the PDR-ACK Acceptance Status Values 2439 2440 IANA is requested to create a Subregistry for the PDR-ACK Acceptance 2441 Status values. 2442 2443 * Possible values are 6-bit unsigned integers (0..63). 2444 2445 * Registration procedure is "Standards Action" [RFC8126]. 2446 2447 * Initial allocation is as indicated in Table 27: 2448 2449 +-------+------------------------+---------------+ 2450 | Value | Meaning | Reference | 2451 +-------+------------------------+---------------+ 2452 | 0 | Unqualified acceptance | This document | 2453 +-------+------------------------+---------------+ 2454 2455 Table 27: Acceptance values of the PDR-ACK Status 2456 2457 11.9. Subregistry for the PDR-ACK Rejection Status Values 2458 2459 IANA is requested to create a Subregistry for the PDR-ACK Rejection 2460 Status values. 2461 2462 2463 2464 Thubert, et al. Expires 28 January 2022 [Page 44] 2465 2466 Internet-Draft DAO Projection July 2021 2467 2468 2469 * Possible values are 6-bit unsigned integers (0..63). 2470 2471 * Registration procedure is "Standards Action" [RFC8126]. 2472 2473 * Initial allocation is as indicated in Table 28: 2474 2475 +-------+-----------------------+---------------+ 2476 | Value | Meaning | Reference | 2477 +-------+-----------------------+---------------+ 2478 | 0 | Unqualified rejection | This document | 2479 +-------+-----------------------+---------------+ 2480 2481 Table 28: Rejection values of the PDR-ACK Status 2482 2483 11.10. SubRegistry for the Via Information Options Flags 2484 2485 IANA is requested to create a Subregistry for the 5-bit Via 2486 Information Options (Via Information Option) Flags field. Each bit 2487 is tracked with the following qualities: 2488 2489 * Bit number (counting from bit 0 as the most significant bit) 2490 2491 * Capability description 2492 2493 * Reference 2494 2495 Registration procedure is "Standards Action" [RFC8126]. No bit is 2496 currently defined for the Via Information Options (Via Information 2497 Option) Flags. 2498 2499 11.11. SubRegistry for the Sibling Information Option Flags 2500 2501 IANA is required to create a registry for the 5-bit Sibling 2502 Information Option (SIO) Flags field. Each bit is tracked with the 2503 following qualities: 2504 2505 * Bit number (counting from bit 0 as the most significant bit) 2506 2507 * Capability description 2508 2509 * Reference 2510 2511 Registration procedure is "Standards Action" [RFC8126]. The initial 2512 allocation is as indicated in Table 29: 2513 2514 2515 2516 2517 2518 2519 2520 Thubert, et al. Expires 28 January 2022 [Page 45] 2521 2522 Internet-Draft DAO Projection July 2021 2523 2524 2525 +============+===================================+===============+ 2526 | Bit number | Capability description | Reference | 2527 +============+===================================+===============+ 2528 | 0 | Connectivity is bidirectional (B) | This document | 2529 +------------+-----------------------------------+---------------+ 2530 2531 Table 29: Initial SIO Flags 2532 2533 11.12. New Destination Advertisement Object Flag 2534 2535 This document modifies the "Destination Advertisement Object (DAO) 2536 Flags" registry initially created in Section 20.11 of [RPL] . 2537 2538 Section 3.1 also defines one new entry in the Registry as follows: 2539 2540 +---------------+------------------------+-----------+ 2541 | Bit Number | Capability Description | Reference | 2542 +---------------+------------------------+-----------+ 2543 | 2 (suggested) | Projected DAO (P) | THIS RFC | 2544 +---------------+------------------------+-----------+ 2545 2546 Table 30: New Destination Advertisement Object 2547 (DAO) Flag 2548 2549 11.13. Error in Projected Route ICMPv6 Code 2550 2551 In some cases RPL will return an ICMPv6 error message when a message 2552 cannot be forwarded along a Projected Route. This ICMPv6 error 2553 message is "Error in Projected Route". 2554 2555 IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6 Message 2556 Types. ICMPv6 Message Type 1 describes "Destination Unreachable" 2557 codes. This specification requires that a new code is allocated from 2558 the ICMPv6 Code Fields Registry for ICMPv6 Message Type 1, for "Error 2559 in Projected Route", with a suggested code value of 8, to be 2560 confirmed by IANA. 2561 2562 12. Acknowledgments 2563 2564 The authors wish to acknowledge JP Vasseur, Remy Liubing, James 2565 Pylakutty and Patrick Wetterwald for their contributions to the ideas 2566 developed here. 2567 2568 13. Normative References 2569 2570 2571 2572 2573 2574 2575 2576 Thubert, et al. Expires 28 January 2022 [Page 46] 2577 2578 Internet-Draft DAO Projection July 2021 2579 2580 2581 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2582 Requirement Levels", BCP 14, RFC 2119, 2583 DOI 10.17487/RFC2119, March 1997, 2584 . 2585 2586 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2587 Control Message Protocol (ICMPv6) for the Internet 2588 Protocol Version 6 (IPv6) Specification", STD 89, 2589 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2590 . 2591 2592 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 2593 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 2594 DOI 10.17487/RFC6282, September 2011, 2595 . 2596 2597 [RPL] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 2598 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 2599 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 2600 Low-Power and Lossy Networks", RFC 6550, 2601 DOI 10.17487/RFC6550, March 2012, 2602 . 2603 2604 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 2605 Power and Lossy Networks (RPL) Option for Carrying RPL 2606 Information in Data-Plane Datagrams", RFC 6553, 2607 DOI 10.17487/RFC6553, March 2012, 2608 . 2609 2610 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 2611 Routing Header for Source Routes with the Routing Protocol 2612 for Low-Power and Lossy Networks (RPL)", RFC 6554, 2613 DOI 10.17487/RFC6554, March 2012, 2614 . 2615 2616 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2617 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2618 May 2017, . 2619 2620 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2621 Writing an IANA Considerations Section in RFCs", BCP 26, 2622 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2623 . 2624 2625 14. Informative References 2626 2627 2628 2629 2630 2631 2632 Thubert, et al. Expires 28 January 2022 [Page 47] 2633 2634 Internet-Draft DAO Projection July 2021 2635 2636 2637 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 2638 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 2639 2014, . 2640 2641 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 2642 J. Martocci, "Reactive Discovery of Point-to-Point Routes 2643 in Low-Power and Lossy Networks", RFC 6997, 2644 DOI 10.17487/RFC6997, August 2013, 2645 . 2646 2647 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 2648 and M. Richardson, Ed., "A Security Threat Analysis for 2649 the Routing Protocol for Low-Power and Lossy Networks 2650 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 2651 . 2652 2653 [6TiSCH-ARCHI] 2654 Thubert, P., Ed., "An Architecture for IPv6 over the Time- 2655 Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)", 2656 RFC 9030, DOI 10.17487/RFC9030, May 2021, 2657 . 2658 2659 [RAW-ARCHI] 2660 Thubert, P., Papadopoulos, G. Z., and L. Berger, "Reliable 2661 and Available Wireless Architecture/Framework", Work in 2662 Progress, Internet-Draft, draft-ietf-raw-architecture-00, 2663 12 July 2021, . 2665 2666 [TURN-ON_RFC8138] 2667 Thubert, P., Ed. and L. Zhao, "A Routing Protocol for Low- 2668 Power and Lossy Networks (RPL) Destination-Oriented 2669 Directed Acyclic Graph (DODAG) Configuration Option for 2670 the 6LoWPAN Routing Header", RFC 9035, 2671 DOI 10.17487/RFC9035, April 2021, 2672 . 2673 2674 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 2675 "Deterministic Networking Architecture", RFC 8655, 2676 DOI 10.17487/RFC8655, October 2019, 2677 . 2678 2679 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 2680 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 2681 RFC 8025, DOI 10.17487/RFC8025, November 2016, 2682 . 2683 2684 2685 2686 2687 2688 Thubert, et al. Expires 28 January 2022 [Page 48] 2689 2690 Internet-Draft DAO Projection July 2021 2691 2692 2693 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 2694 "IPv6 over Low-Power Wireless Personal Area Network 2695 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 2696 April 2017, . 2697 2698 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 2699 Perkins, "Registration Extensions for IPv6 over Low-Power 2700 Wireless Personal Area Network (6LoWPAN) Neighbor 2701 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 2702 . 2703 2704 [USEofRPLinfo] 2705 Robles, M.I., Richardson, M., and P. Thubert, "Using RPI 2706 Option Type, Routing Header for Source Routes, and IPv6- 2707 in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008, 2708 DOI 10.17487/RFC9008, April 2021, 2709 . 2710 2711 [PCE] IETF, "Path Computation Element", 2712 . 2713 2714 Appendix A. Applications I wouldn't call this applications, its more like optimiations goals or the like 2715 2716 A.1. Loose Source Routing Optimizing packet size vs. routing state via Loose Source Routing 2718 A RPL implementation operating in a very constrained LLN typically 2719 uses the Non-Storing Mode of Operation as represented in Figure 12. 2720 In that mode, a RPL node indicates a parent-child relationship to the 2721 Root, using a Destination Advertisement Object (DAO) that is unicast 2722 from the node directly to the Root, and the Root typically builds a 2723 source routed path to a destination down the DODAG by recursively 2724 concatenating this information. 2725 2726 ------+--------- 2727 | Internet 2728 | 2729 +-----+ 2730 | | Border Router 2731 | | (RPL Root) 2732 +-----+ ^ | | 2733 | | DAO | ACK | 2734 o o o o | | | Strict 2735 o o o o o o o o o | | | Source 2736 o o o o o o o o o o | | | Route 2737 o o o o o o o o o | | | 2738 o o o o o o o o | v v 2739 o o o o 2740 LLN 2741 2742 2743 2744 Thubert, et al. Expires 28 January 2022 [Page 49] 2745 2746 Internet-Draft DAO Projection July 2021 2747 2748 2749 Figure 12: RPL Non-Storing Mode of operation 2750 2751 Based on the parent-children relationships expressed in the non- 2752 storing DAO messages,the Root possesses topological information about 2753 the whole network, though this information is limited to the 2754 structure of the DODAG for which it is the destination. A packet 2755 that is generated within the domain will always reach the Root, which 2756 can then apply a source routing information to reach the destination 2757 if the destination is also in the DODAG. Similarly, a packet coming 2758 from the outside of the domain for a destination that is expected to 2759 be in a RPL domain reaches the Root. 2760 2761 It results that the Root, or then some associated centralized 2762 computation engine such as a PCE, can determine the amount of packets 2763 that reach a destination in the RPL domain, and thus the amount of 2764 energy and bandwidth that is wasted for transmission, between itself 2765 and the destination, as well as the risk of fragmentation, any 2766 potential delays because of a paths longer than necessary (shorter 2767 paths exist that would not traverse the Root). 2768 2769 As a network gets deep, the size of the source routing header that 2770 the Root must add to all the downward packets becomes an issue for 2771 nodes that are many hops away. In some use cases, a RPL network 2772 forms long lines and a limited amount of well-Targeted routing state 2773 would allow to make the source routing operation loose as opposed to 2774 strict, and save packet size. Maybe ad to be more explicit: And example of such well-targeted routing state is what is needed to reach the neared loose steerig hops. 2774 Limiting the packet size is directly 2775 beneficial to the energy budget, but, mostly, it reduces the chances 2776 of frame loss and/or packet fragmentation, which is highly 2777 detrimental to the LLN operation. Because the capability to store a 2778 routing state in every node is limited, the decision of which route 2779 is installed where can only be optimized with a global knowledge of 2780 the system, a knowledge that the Root or an associated PCE may 2781 possess by means that are outside of the scope of this specification. 2782 2783 This specification enables to store a Storing Mode state in 2784 intermediate routers, which enables to limit the excursion of the 2785 source route headers in deep networks. Once a P-DAO exchange has 2786 taken place for a given Target, if the Root operates in non Storing 2787 Mode, then it may elide the sequence of routers that is installed in 2788 the network from its source route headers to destination that are 2789 reachable via that Target, and the source route headers effectively 2790 become loose. 2791 2792 2793 2794 2795 2796 2797 2798 2799 2800 Thubert, et al. Expires 28 January 2022 [Page 50] 2801 2802 Internet-Draft DAO Projection July 2021 2803 2804 2805 A.2. Transversal Routes 2806 2807 RPL is optimized for Point-to-Multipoint (P2MP) and Multipoint-to- 2808 Point (MP2P), whereby routes are always installed along the RPL DODAG 2809 respectively from and towards the DODAG Root. Transversal Peer to 2810 Peer (P2P) routes in a RPL network will generally suffer from some 2811 elongated (stretched) path versus the best possible path, since 2812 routing between 2 nodes always happens via a common parent, as 2813 illustrated in Figure 13: That figure needs to be improved if anyone who doesn't know what a transversal route is is expected to understand it. Just paint a picture with the minimum number of nodes to show a transversal route not part of the DODAG. Figure 14 is kinda ok., but in 13 its really unclear where traffic flows and why. Also: Is there any RPL messaging that would allow for the Root to have enough knowledge about transversal connectibity not part of the DODAG, which it could then tell the PCE ? If not, then for fairness, it would be good to highlight this as a gap for the solution. 2815 * In Storing Mode, unless the destination is a child of the source, 2816 the packets will follow the default route up the DODAG as well. 2817 If the destination is in the same DODAG, they will eventually 2818 reach a common parent that has a route to the destination; at 2819 worse, the common parent may also be the Root. From that common 2820 parent, the packet will follow a path down the DODAG that is 2821 optimized for the Objective Function that was used to build the 2822 DODAG. 2823 2824 * in Non-Storing Mode, all packets routed within the DODAG flow all 2825 the way up to the Root of the DODAG. If the destination is in the 2826 same DODAG, the Root must encapsulate the packet to place an RH 2827 that has the strict source route information down the DODAG to the 2828 destination. This will be the case even if the destination is 2829 relatively close to the source and the Root is relatively far off. 2830 2831 2832 ------+--------- 2833 | Internet 2834 | 2835 +-----+ 2836 | | Border Router 2837 | | (RPL Root) 2838 +-----+ 2839 X 2840 ^ v o o 2841 ^ o o v o o o o o 2842 ^ o o o v o o o o o 2843 ^ o o v o o o o o 2844 S o o o D o o o 2845 o o o o 2846 LLN 2847 2848 Figure 13: Routing Stretch between S and D via common parent X 2849 2850 It results that it is often beneficial to enable transversal P2P 2851 routes, either if the RPL route presents a stretch from shortest 2852 path, or if the new route is engineered with a different objective, 2853 2854 2855 2856 Thubert, et al. Expires 28 January 2022 [Page 51] 2857 2858 Internet-Draft DAO Projection July 2021 2859 2860 2861 and that it is even more critical in Non-Storing Mode than it is in 2862 Storing Mode, because the routing stretch is wider. For that reason, 2863 earlier work at the IETF introduced the "Reactive Discovery of 2864 Point-to-Point Routes in Low Power and Lossy Networks" [RFC6997], 2865 which specifies a distributed method for establishing optimized P2P 2866 routes. This draft proposes an alternate based on a centralized 2867 route computation. 2868 2869 ------+--------- 2870 | Internet 2871 | 2872 +-----+ 2873 | | Border Router 2874 | | (RPL Root) 2875 +-----+ 2876 | 2877 o o o o 2878 o o o o o o o o o 2879 o o o o o o o o o o 2880 o o o o o o o o o 2881 S>>A>>>B>>C>>>D o o o 2882 o o o o 2883 LLN 2884 2885 Figure 14: Projected Transversal Route 2886 2887 This specification enables to store source-routed or Storing Mode 2888 state in intermediate routers, which enables to limit the stretch of 2889 a P2P route and maintain the characteristics within a given SLA. An 2890 example of service using this mechanism oculd be a control loop that 2891 would be installed in a network that uses classical RPL for 2892 asynchronous data collection. In that case, the P2P path may be 2893 installed in a different RPL Instance, with a different objective 2894 function. 2895 2896 Authors' Addresses 2897 2898 Pascal Thubert (editor) 2899 Cisco Systems, Inc 2900 Building D 2901 45 Allee des Ormes - BP1200 2902 06254 Mougins - Sophia Antipolis 2903 France 2904 2905 Phone: +33 497 23 26 34 2906 Email: pthubert@cisco.com 2907 2908 2909 2910 2911 2912 Thubert, et al. Expires 28 January 2022 [Page 52] 2913 2914 Internet-Draft DAO Projection July 2021 2915 2916 2917 Rahul Arvind Jadhav 2918 Huawei Tech 2919 Kundalahalli Village, Whitefield, 2920 Bangalore 560037 2921 Karnataka 2922 India 2923 2924 Phone: +91-080-49160700 2925 Email: rahul.ietf@gmail.com 2926 2927 2928 Matthew Gillmore 2929 Itron, Inc 2930 Building D 2931 2111 N Molter Road 2932 Liberty Lake, 99019 2933 United States 2934 2935 Phone: +1.800.635.5461 2936 Email: matthew.gillmore@itron.com 2937 2938 2939 2940 2941 2942 2943 2944 2945 2946 2947 2948 2949 2950 2951 2952 2953 2954 2955 2956 2957 2958 2959 2960 2961 2962 2963 2964 2965 2966 2967 2968 Thubert, et al. Expires 28 January 2022 [Page 53] From nobody Mon Aug 30 04:32:07 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 4AFA93A080C for ; Mon, 30 Aug 2021 04:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=iP2DAODP; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Hdt0wXb7 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 StryYHzOy6Oh for ; Mon, 30 Aug 2021 04:31:58 -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 E0A343A080A for ; Mon, 30 Aug 2021 04:31:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7250; q=dns/txt; s=iport; t=1630323117; x=1631532717; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=IqUxC51amFRzON3yisoHXEk1n7y5Q8fQMh4mtDBVveA=; b=iP2DAODP8jBrkzE2YiaXwKuwa4ZdSce3Ive1oM39sCUeiglpQULNDyd1 HcQ67HNCacLbG5FMZOIGDbVxUY3fXTM5hZC8FrU9kRM7MLA7VeR6IwIKJ g/QUGUTykB24g2f8mVNlWai0sztnRIE4LvCQipgk/mim9vJrWMJHsj0SR 0=; X-IPAS-Result: =?us-ascii?q?A0AkAAACwSxhl4sNJK1aHQEBAQEJARIBBQUBQIFFCAELA?= =?us-ascii?q?YFSIy5+WjcxhEeDSAOEWWCIBQOPfYpNgS6BJQNUCwEBAQ0BASoLDAQBAYF5g?= =?us-ascii?q?jBFAheCGgIlNAkOAQIEAQEBAQMCAwEBAQEFAQEFAQEBAgEGBBQBAQEBAQEBA?= =?us-ascii?q?YEIhWgNhkIBAQEBAwEBEBERDAEBLAwLBAIBCBEEAQEBAgImAgICJQsVCAgCB?= =?us-ascii?q?BMIGoJPAYJVAy8BDp8AAYE6AoofeoExgQGCCAEBBgQEgTYBE0GCfxiCNAMGg?= =?us-ascii?q?RAqAYJ+gnRTSoZqJxyBSUSBFERUghI+gmIBAQKBQCAVD4JxNoIuhX2BRQQDC?= =?us-ascii?q?hUQISA7IB0FLwgXKGSVA5Yqkh8KgyuKQJQ3EoNli2aXNqJak18EBBiEZwIEA?= =?us-ascii?q?gQFAg4BAQaBYTmBW3AVO4JpUBkPjiAZg1mFFIVKdAIBNQIGAQoBAQMJkg4BA?= =?us-ascii?q?Q?= IronPort-PHdr: A9a23:RTrQFR9TfoIh/v9uWDnoyV9kXcBvk7T5IgBT7YAo2PpCcaWmqpLlO kGXpfBgl0TAUoiT7fVYw/HXvKbtVS1lg96BvXkOfYYKW0oDjsMbzA0tHMDDDlf0f7bmaiUgF 5FEU1lot3iwLUlSHpP4YFvf6n2/5DIfAFPxLw1wc+/0AYXVyc+w0rPaxg== IronPort-HdrOrdr: A9a23:3IRJx6jf/3qbLK6K0L3sOydjgHBQX4J23DAbv31ZSRFFG/FwyP rOoB1L73HJYWgqN03IwerwR5VoMkmsi6KdhrNhfYtKPTOW+VdASbsD0WKM+UyZJ8VxnNQtrp uIH5IObeEYSGIK8foSgzPIUOrIouP3ipxA7N22pxwGIG0aCNAD0+46MHfnLqQcfnggOXNNLu vk2iMxnUvHRZ14VLXeOlA1G8z44/HbnpPvZhALQzQ97hOVsD+u4LnmVzCFwxY3SVp0sPUf2F mAtza8yrSosvm9xBOZ/XTU9Y5qlNzozcYGLNCQi/ISNi7nhm+TFcFcsvy5zXQISdOUmRAXee r30k4d1gNImivsl1SO0FzQMs/boW0TAjHZuAWlaDDY0L3ErXoBerp8bMRiA0bkA45KhqAi7E qNtFjp66a/RCmw7xjV9pzGUQpnmVGzpmdnmekPj2ZHWY9bc7NJq5cDlXklXavoMRiKo7zPKt MeRv00JcwmBm+yfjTcpC1i0dasVnM8ElOPRVUDoNWc13xTkGpix0UVycQDljNYnahNBKVs9q DBKOBlhbtORsgZYeZ0A/oAW9K+DijITQjXOGyfLFz7HOUMOm7LqZTw/LIpjdvaNKAg3d83gt DMQVlYvWk9dwbnDtCPxoRC9lTXTGC0TV3Wu4ljDlhCy/TBrZ/QQGO+oXwV4r6dSsQkc7vmsq yISeBr6tfYXB/TJbo= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.84,363,1620691200"; d="scan'208";a="737473422" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Aug 2021 11:31:56 +0000 Received: from mail.cisco.com (xbe-rcd-003.cisco.com [173.37.102.18]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 17UBVupn018007 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for ; Mon, 30 Aug 2021 11:31:56 GMT Received: from xfe-aln-003.cisco.com (173.37.135.123) by xbe-rcd-003.cisco.com (173.37.102.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 30 Aug 2021 06:31:56 -0500 Received: from xfe-rtp-004.cisco.com (64.101.210.234) by xfe-aln-003.cisco.com (173.37.135.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 30 Aug 2021 06:31:55 -0500 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-004.cisco.com (64.101.210.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Mon, 30 Aug 2021 07:31:55 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Nv77sCCKhs1Nd4pAPLebRb7w/U6kLyZ1OBPJMILwUtueCYRWRkaqihf/CIHhTelbjyuOC1cJjlff6AaJG3qShhTPI8GORhW7IDvmA5MAAjM9MZxivndy2c6bcaGZK0OxWphCC8b66qYktbGx/mzoglqwwZbOPU8MWbVzH5A30WqSVzKeDDSZB8DCA7h2KVwJ4/MJ8I6vEqE7bgN56cHu5uddz+gux3R3qVKYsq7sDCa28e/m9O/FUvvALFmFpMCNKMATAT2rDYKPpy5rC4d4EAO6Oy9C5GGI/1RzlvEX+CqgrQP9Woj7eSIfrACiUFoZlgUMNS5ECauvSwwGTd9WLA== 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=IqUxC51amFRzON3yisoHXEk1n7y5Q8fQMh4mtDBVveA=; b=YptAYAReX1s9/pJCVEvK9sKieDnzwiqHLaXLwaiWg/UgMf3Lh6vcztZOtmKzLlykTyq17xrZKdMov7AkWPn/MpXVRM9Gp+SXTvG8dUInv04fuQZbYpR0WlJLVsruy/Xzq6I0iO0Re9v55mOmg0Y28JqpF/8U1qj5jT2wXrWD0IF0RBqZZQxLcwxWCZGLQ2HCOKYFONvbuSdxvnwPo6qCX9NFXWgCJAxXcDOaE+HbRxP5kxi76zGDezgoaAEucf9koc2AEvJ5HZrp9POe9yaQS+6h8MguMioXNuv88t/o4tjZTfHpvoCM/QdEOLWpn4qZoWzuMWz6/uIJq7Oz9xLi7Q== 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=IqUxC51amFRzON3yisoHXEk1n7y5Q8fQMh4mtDBVveA=; b=Hdt0wXb7pCK6zCOxiHf4pJNL8P8dkAm4Fu/xB/VO5h5gCz4nn+FRIGI0OuvR0PKujGslEDFXQjrbULtCEhl5EzmGgsP/X1T1xzPAkJNNofLWPTkEMv5gX2B8QHnOVIy7qbj77i4IlaS78uOjM0CfLcNdhTffNGLKGK8GFbm25zY= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MWHPR11MB1822.namprd11.prod.outlook.com (2603:10b6:300:111::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.25; Mon, 30 Aug 2021 11:31:54 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::b1cb:f7f8:b63e:b6ee]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::b1cb:f7f8:b63e:b6ee%6]) with mapi id 15.20.4457.024; Mon, 30 Aug 2021 11:31:54 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Review of draft-ietf-roll-dao-projection Thread-Index: AQHXmwk5APML4x4cU0Sn5jf1yiT0lquKPd0EgAAM44CAAZBhYA== Date: Mon, 30 Aug 2021 11:31:32 +0000 Deferred-Delivery: Mon, 30 Aug 2021 10:22:36 +0000 Message-ID: References: <20210822051345.GA3910@iisc.ac.in> <24891.1629827443@localhost> <20210825164051.GA5889@iisc.ac.in> <31748.1629918032@localhost> <20210827060315.GA28747@iisc.ac.in> <42FCD4BA-3E56-4D86-ABDD-667CBED7D29D@cisco.com> <20210829102704.GA3466@iisc.ac.in> In-Reply-To: <20210829102704.GA3466@iisc.ac.in> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 05356250-be7a-4e67-beec-08d96ba9c4cd x-ms-traffictypediagnostic: MWHPR11MB1822: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: etKRYWl9ZqAxOgd+HJcSqqJDSAcltdINXvOL5vK1/QpXEOUK5n7wKK2Qh5GWISManq2DDx5lQl9DZ5remVk3SHgJMuIA1c/zvmlLUrpHcL726f731SnwRAQUlSJurIpqC8Hbs44h430BB7Db5iLWKmZIpskYIztBpNT/FYlMO4cKV5dfKQy5bD85VtAQVnzIhgZI7nNW53+k3K2Mi6lfHdYgEdNTXsp3gEtLv7N8SjFQcVJizFL1OfDcXlToyw7f3vBru3vF+Q9Dww/IbJB8kYoEYmtfZUVSNsFsRK0vuNQg+ScpaWxtqD+PsginQLuv0wRf9aTJhDrv0wU8w5S7LUpUs4YDF4aQS7vQw37/NFMXgKI55/B5rFX8ZcvQkwfc5ZHkO39F+K4URWdStyFo9N7E86hG+MvyM33P1DuGL2ZPinqxEkNjz94ZsQTt8U5So8wLKnC/oWSL8OQZsYbojXEvPaMkncEVN6ycSTXo1TLs93R04YNUSdalFW9JUYtsp+oAzr5eLr2g9saNvU+1IRJgift7iWdwSTkx7b6ZVsp573z4p0QT09J0cwMHbBMpHhpI9DL6bhITVKHbFQlStiPtK84w4GV7PTV41GtiDpFgNKt8tfG9KYhuK/u0qCP4O95gPez7U46Et9aMhuIg1BagD8rD+rKH3QX1Bw0BFqHemlq2DiXHqdPoM6m7u5aOAKWdE4KqHchu/vDe/FUnJcNvzg6nBzTe+9sVeWsyrkGY7dv741QBs5d5nxcycoB1N/fPDCkrSFaETNkBn3KRONrUNpHWT5YYbdC6amE1pXBqRTsZ8F/6dUMIslbfO4nrYLB8TMFwhimLTeKJB7PvEw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB4881.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(52536014)(6666004)(508600001)(38070700005)(83380400001)(966005)(66574015)(8676002)(316002)(76116006)(66476007)(6506007)(7696005)(66446008)(2906002)(66946007)(66556008)(5660300002)(6916009)(71200400001)(186003)(38100700002)(86362001)(9686003)(122000001)(53546011)(8936002)(55016002)(33656002)(64756008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?SXA3T3FuQ2ZxYWgyTGJacFJrbzFGOWpneFlxUlNBREdwZkN0YlpKei9oODVZ?= =?utf-8?B?OFExRUFsL1dpZFpVK0QwMEk2aE5wcmRCUUZTK3FTLzNUNHNvazZJcnM1WURY?= =?utf-8?B?ZEhVRlUrWWZYdXNDWWJub3MrdmlyN3plQ0tQTVhqTWlWWnViQnNGclRib29Q?= =?utf-8?B?QVZtdHFmb1RSaE52MnprcTdFZVZnTDcxU2NjM2ZhU0lMOTlCZWErcHdqZjNG?= =?utf-8?B?WjcwTURzak1xYjY2MXBsYW5HMFk4TndnZUxhRzdmb29mWThLbVlmMjJQZkhO?= =?utf-8?B?MGUzMnNwc2RBakJZTG1kZ0NuRXBpeHphNEFrTUxFZUo2R0E4aDdISitzSHJt?= =?utf-8?B?cWlqcXlMSExGampRdWhyRGR2S0FOZENsM09KUTQrazRZWFRWOGN2VElQTHlt?= =?utf-8?B?UWxiUHpNd2ZrTXMyQWhIMUZ4d0pPQUtWV3Q2SnVSRExicWUyMmZXM2tDcjgv?= =?utf-8?B?K2ltczZPYWxxdkZmRStvUGRFM0ZoTzNLcWNHbGt5RUkxZjNJckxGa1FUQVVn?= =?utf-8?B?Qis3cnRRQ3djYkowSFFFK3hpU0I4RzFXbTd0a28rbGEwQnlUQkhURTY2YVht?= =?utf-8?B?UVpVUVg0YmExMlFIanNJMHFwUDVnd3M1ZVFobjVNd3lsWkNCdSt2ZkE4dDJ0?= =?utf-8?B?R1g0T2xDTlU4dnpVT2dla0JaUXg4NjZDWmNXdjkzd0Y0MnhPRGttMmtaOFNF?= =?utf-8?B?WDFqWEF2TUt4dG90NEN3c0JhVEFzZ0ZiODhkR1FpSWxHUUZLUVR3Y09MWXM4?= =?utf-8?B?WXdyUGlmZXRobU00M2kzNmQxRG1PdnprNS9ZQXhtc0xTTlRIbHFmYWJzZEln?= =?utf-8?B?T1AwRURzMkZVWXRxZU44MndXRUNkNHdwS3NmQ0Qvc3hZelBaVE53ZkRQdE5Q?= =?utf-8?B?MjFBb0ZNWnZBV3lidXZpbWE0RnY3VUJrQXJjZVNSVXczdEhBVTdUQTJ4UnhH?= =?utf-8?B?OUlkaVV4NDl5bUlBOFZCNGlBOTJRYTQ0bHY5cXIydG9JVlBMdDJCT2NBaHBF?= =?utf-8?B?VXBoTDhrRVBrRTFublVvQXI3TUxRQU1xZURqb3QrMytlcHlnS29NUXZTVnFx?= =?utf-8?B?YTh4d1k4c2VWZmFOS2s0TFUrZ0NxOEV3eDRiWEhHOE9wdStpaW1XOVlSWGNh?= =?utf-8?B?dUZZSTlzcVdkQXFHMmpGQ2h2RWZOUmhnRlJXQ3Q3L3dIOGl3Q2FEeEpCb1pX?= =?utf-8?B?VExTNndoNkw0S3dMREhnMmNQRStvemRjc2dSWXVKdXEwQjZuYmhLWmdaQnhR?= =?utf-8?B?bm5CcGxTWktjemFRQ2s3TnFFWW1jdWQvd0Yyd1I3U1hxbmNrRHFya0VKK21E?= =?utf-8?B?RklNS2pZMng4ckRmSXlFcGFYVlphNVNudHR4T1lFMlowUDdyTXdJS1RzMm1O?= =?utf-8?B?S3pMeUdTVjNoSnVzaFUxOGJQZmdKWUVmRjdHN1gwK2t3WHhmT2ZXT0Qrdyts?= =?utf-8?B?V05PQjQ4aGR3WCtsVlUwVDIxTjVTOElVa2lnbWI2TGU1WEJDbWJhb1UrTXMv?= =?utf-8?B?MnQwMlVsMHZlTkdxMkgwVXhvbG0yWEw3S3ZHUVNRQVBrbVgya0p4ZnhERG44?= =?utf-8?B?dzhpNVo0ZDNjVHlmVkczZW5XdjdiOVVoY05hSjFTY1diaUswN0lGZFI4SW02?= =?utf-8?B?QjU0S3ZiZUZVdCtwVnhPa2s4VTJUZEZDVnlsN01iOXZBa1phMVp5dEFKV282?= =?utf-8?B?aVBPYUdZZUdlRTJ3d0VUaHQ2REkzU1p0UmE2MUlaWEVLTTNXUWdkcVZRL3lZ?= =?utf-8?B?R3lMVTZKQVpibDUyYjdaMTlrOE9kcG80SGxOZzNPd25tRkQzVC9Idnh6WFFw?= =?utf-8?B?SzdSR254SkVTZ3FCOVRLR0Q3R1M2WWdVR1ZjUTZaWkJhSXlHT05DSjFyTGhk?= =?utf-8?Q?e4/f2dDKhehqy?= 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: 05356250-be7a-4e67-beec-08d96ba9c4cd X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2021 11:31:54.3804 (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: 0EaH564L9+KEo+583F2td8Hy3pZJifrheFPWFyGgZ5KqBHuf1W9+T80SM+Y0vceG20PVdPRUsDYU7XFVTJgMZQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1822 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.18, xbe-rcd-003.cisco.com X-Outbound-Node: alln-core-6.cisco.com Archived-At: Subject: Re: [Roll] Review of draft-ietf-roll-dao-projection X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2021 11:32:05 -0000 VmVyeSBDb29sIEFuYW5kIQ0KDQpJIGFkZGVkOg0KDQoNCiIgRXh0ZW5kaW5nIFJGQyA2NTUwDQoN CiAgIFRoaXMgc3BlY2lmaWNhdGlvbiBleHRlbmRzIFJQTCBbUlBMXSB0byBlbmFibGUgdGhlIFJv b3QgdG8gaW5zdGFsbA0KICAgZWFzdC13ZXN0IHJvdXRlcyBpbnNpZGUgYSBtYWluIERPREFHIHRo YXQgaXMgb3BlcmF0ZWQgYXMgbm9uLXN0b3JpbmcNCiAgIG1vZGUuICBBIFByb2plY3RlZCBEQU8g KFAtREFPKSBtZXNzYWdlIGNvbnRhaW5zIGEgbmV3IFZpYSBJbmZvcm1hdGlvbg0KICAgT3B0aW9u IHRoYXQgY2FuIGJlIHNlZW4gYXMgYSBtdWx0aWhvcCBUcmFuc2l0IEluZm9ybWF0aW9uIE9wdGlv biBhbmQNCiAgIGluc3RhbGxzIGEgc3RyaWN0IG9yIGEgbG9vc2Ugc2VxdWVuY2Ugb2YgaG9wcyB0 byBmb3JtIGEgdHJhY2sgU2VnbWVudA0KICAgb3IgYSBUcmFjayBMZWcuIEEgUC1EQU8gUmVxdWVz dCAoUERSKSBtZXNzYWdlIGVuYWJsZXMgYSBUcmFjayBJbmdyZXNzDQogICB0byByZXF1ZXN0IHRo ZSBUcmFjayBmcm9tIHRoZSBSb290LiAgSW4gdGhlIGNvbnRleHQgb2YgdGhpcw0KICAgc3BlY2lm aWNhdGlvbiwgdGhlIGluc3RhbGxlZCByb3V0ZSBhcHBlYXJzIGFzIGEgbW9yZSBzcGVjaWZpYyBy b3V0ZQ0KICAgdG8gdGhlIFRyYWNrIHRhcmdldHMsIGFuZCB0aGUgVHJhY2sgaW5ncmVzcyByb3V0 ZXMgYWxsIHRoZSBwYWNrZXRzDQogICB0b3dhcmRzIHRoZSB0YXJnZXRzIGFyZSByb3V0ZWQgdmlh IHRoZSBUcmFjay4NCg0KICAgVG8gZW5zdXJlIHRoYXQgdGhlIFBEUiBhbmQgUC1EQU8gbWVzc2Fn ZXMgY2FuIGZsb3cgYXQgYWxsIHRpbWUsIGl0IGlzDQogICBSRUNPTU1FTkRFRCB0aGF0IHRoZSBu b2RlcyBpbnZvbHZlZCBpbiBhIFRyYWNrIG1hbnRhaW4gbXVsdGlwbGUNCiAgIHBhcmVudHMgaW4g dGhlIG1haW4gRE9EQUcsIGFkdmVydGlzZSB0aGVtIGFsbCB0byB0aGUgUm9vdCwgYW5kIHVzZQ0K ICAgdGhlbSBpbiB0dXJuIHRvIHJldHJ5IHNpbWlsYXIgcGFja2V0cy4gIEl0IGlzIGFsc28gUkVD T01NRU5ERUQgdGhhdA0KICAgdGhlIFJvb3QgdXNlcyBkaXZlcnNlIHNvdXJjZSByb3V0ZSBwYXRo cyB0byByZXRyeSBzaW1pbGFyIG1lc3NhZ2VzIG90DQogICB0aGUgbm9kZXMgaW4gdGhlIFRyYWNr Lg0KDQoiDQoNClRha2UgY2FyZSwNCg0KUGFzY2FsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogUm9sbCA8cm9sbC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2Yg Uy5WLlIuQW5hbmQNCj4gU2VudDogZGltYW5jaGUgMjkgYW/Du3QgMjAyMSAxMjoyNw0KPiBUbzog Um91dGluZyBPdmVyIExvdyBwb3dlciBhbmQgTG9zc3kgbmV0d29ya3MgPHJvbGxAaWV0Zi5vcmc+ DQo+IFN1YmplY3Q6IFJlOiBbUm9sbF0gUmV2aWV3IG9mIGRyYWZ0LWlldGYtcm9sbC1kYW8tcHJv amVjdGlvbg0KPiANCj4gSGVsbG8gUGFzY2FsLA0KPiANCj4gVGhhbmsgeW91IHZlcnkgbXVjaCBm b3IgYWRkcmVzc2luZyBteSBjb25jZXJuIGFuZCB5b3UgY2FuIHByb2NlZWQgd2l0aCB0aGUNCj4g cHVibGljYXRpb24gd2l0aG91dCBmdXJ0aGVyIGRlbGF5IDopDQo+IA0KPiA+IFdoYXQgSSBkbyBu b3Qgc2VlIGlzIHRoZSBuZWVkIGZvciBleHRyYSB3b3JrIHRvIHByb3RlY3QgdGhlIHBhdGggZnJv bSB0aGUNCj4gcm9vdCB0byB0aGUgbm9kZSwgYnV0IEkgYWdyZWUgdGhhdCB3ZSBjb3VsZCBpbmRp Y2F0ZSB0aGF0IHRoZSBub2RlIHNob3VsZA0KPiBhZHZlcnRpc2UgbW9yZSB0aGFuIG9uZSBwYXJl bnQgYW5kIHRoZSByb290IHNob3VsZCByZXRyeSBvdmVyIGRpdmVyc2UgU1INCj4gcGF0aHMsIGlm IHRoYXTigJlzIHlvdXIgcG9pbnQ/DQo+ID4NCj4gDQo+IFllcywgdGhlIGFib3ZlIGluZGljYXRp dmUgdGV4dCB3aWxsIGJlIHZlcnkgaGVscGZ1bCBhcyB3ZSBhcmUgbm90IGlnbm9yaW5nDQo+IHRo ZSBjb3VwbGluZyBlZmZlY3QuIFdoaWxlIHRoZSBkcmFmdCBuZWVkIG5vdCBnbyBpbnRvIHRoZSBz cGVjaWZpY3Mgb2YgYWxsDQo+IHRoZSBwb3NzaWJpbHRpZXMsIEkgZmVlbCBicmluZ2luZyBvdXQg dGhlIGNvcmUgaXNzdWUgaXMgaW1wb3J0YW50Lg0KPiANCj4gUmVnYXJkcw0KPiBBbmFuZA0KPiAN Cj4gT24gMjEtMDgtMjkgMDk6NDA6NTcsIFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkgd3JvdGU6 DQo+ID4NCj4gPg0KPiA+IEhlbGxvIEFuYW5kLA0KPiA+DQo+ID4gQ2VydGFpbnMgdGhlIG1haW4g REFHIHdpbGwgdW5kZXJnbyBjaGFuZ2VzIGFuZCB0cmFuc2llbnQgbG9jYWxpemVkDQo+IGZhaWx1 cmVzLg0KPiA+DQo+ID4gU2luY2UgdGhlcmUgaXMgbm8gb2JqZWN0aXZlIG9mIFJBVyBvbiB0aGUg bWFpbiBEQUcgd2XigJlyZSBvay4gSW4gdGhvc2UNCj4gdHJhbnNpZW50IHRpbWVzIHRoZSBSb290 IHdpbGwgbm90IGJlIGFibGUgdG8gc2VlIHRyb3VibGUgaW4gYSBUcmFjayBhbmQgdGhlDQo+IFRy YWNrIHdpbGwgaGF2ZSB0byBzdXJ2aXZlIG9uIGl0cyByZWR1bmRhbmN5Lg0KPiA+DQo+ID4gUlBM IGFscmVhZHkgZW5hYmxlcyByZWR1bmRhbmN5IGJldHdlZW4gdGhlIHJvb3QgYW5kIGEgbm9kZSwg aXTigJlzIHVwIHRvDQo+IHRoZSByb290IHRvIHNlbGVjdCBvbmUgb2YgdGhlIHBvc3NpYmxlIHNv dXJjZSByb3V0ZSBwYXRoIHRoYXQgaXQgc2Vlcy4NCj4gPg0KPiA+IElmIHRoZSBSb290IGNvbXBs ZXRlbHkgbG9vc2VzIGNvbm5lY3Rpdml0eSB0byBhIG5vZGUgaW4gYSBUcmFjaywgaXQgbWF5DQo+ IG5vdCBiZSBhYmxlIHRvIGNsZWFuIGl0IGluc3RhbnRseSBidXQgaXQgY2FuIHJvdXRlIGFyb3Vu ZCBpdC4gSSBoYXZlIGEgbG90DQo+IG9mIG5ldyB0ZXh0IG9uIG1haW50ZW5hbmNlIHRoYXQgd2Xi gJlsbCBkaXNjdXNzIGl0IGF0IHRoZSBpbnRlcmltLg0KPiA+DQo+ID4gV2hhdCBJIGRvIG5vdCBz ZWUgaXMgdGhlIG5lZWQgZm9yIGV4dHJhIHdvcmsgdG8gcHJvdGVjdCB0aGUgcGF0aCBmcm9tIHRo ZQ0KPiByb290IHRvIHRoZSBub2RlLCBidXQgSSBhZ3JlZSB0aGF0IHdlIGNvdWxkIGluZGljYXRl IHRoYXQgdGhlIG5vZGUgc2hvdWxkDQo+IGFkdmVydGlzZSBtb3JlIHRoYW4gb25lIHBhcmVudCBh bmQgdGhlIHJvb3Qgc2hvdWxkIHJldHJ5IG92ZXIgZGl2ZXJzZSBTUg0KPiBwYXRocywgaWYgdGhh dOKAmXMgeW91ciBwb2ludD8NCj4gPg0KPiA+IFBsZWFzZSBsZXQgbWUga25vdywgSeKAmWQgd2lz aCB0byBwdWJsaXNoIE1vbmRheSA6KQ0KPiA+DQo+ID4gS2VlcCBzYWZlLA0KPiA+DQo+ID4gUGFz Y2FsDQo+ID4NCj4gPiA+IExlIDI3IGFvw7t0IDIwMjEgw6AgMDg6MDQsIFMuVi5SLkFuYW5kDQo+ IDxhbmFuZHN2cj00MGlpc2MuYWMuaW5AZG1hcmMuaWV0Zi5vcmc+IGEgw6ljcml0IDoNCj4gPiA+ DQo+ID4gPiDvu79IZWxsbyBNaWNoYWVsLCBhbmQgYWxsLA0KPiA+ID4NCj4gPiA+IEF0IHRoZSB0 aW1lIG9mIHdyaXRpbmcgdGhlIHBhcGVyLCB3ZSBhbHNvIHdyb3RlIHVwIGZpcnN0LWN1dCB2ZXJz aW9uDQo+ID4gPiBvZiB0aGUgZHJhZnQuIEJ1dCB3ZSBuZXZlciBnb3QgdG8gcHVibGlzaCBpdCBp biBhbnkgb2YgdGhlIHdvcmtpbmcNCj4gZ3JvdXBzLg0KPiA+ID4NCj4gPiA+IEkgd2lsbCBiZSB2 ZXJ5IGhhcHB5IHRvIHNoYXJlIHRoZSBkcmFmdCwgd2hpY2ggaXMgc3RpbGwgaW4gdGhlDQo+ID4g PiBuYXNjZW50IGZvcm0sIGFuZCBnZXQgaW5pdGlhbCBmZWVkYmFjayBvbiB3aGV0aGVyIGl0IGlz IHN1aXRhYmxlIGZvciBhbg0KPiBSRkMuDQo+ID4gPg0KPiA+ID4gUmVnYXJkcw0KPiA+ID4gQW5h bmQNCj4gPiA+DQo+ID4gPj4gT24gV2VkLCBBdWcgMjUsIDIwMjEgYXQgMDM6MDA6MzJQTSAtMDQw MCwgTWljaGFlbCBSaWNoYXJkc29uIHdyb3RlOg0KPiA+ID4+DQo+ID4gPj4NCj4gPiA+PiBTLlYu Ui5BbmFuZCA8YW5hbmRzdnI9NDBpaXNjLmFjLmluQGRtYXJjLmlldGYub3JnPiB3cm90ZToNCj4g PiA+Pj4gSW4gb3VyIGxhYiB3ZSBkZXZlbG9wZWQgYW4gaW4tYmFuZCBPQU0gdGVsZW1ldHJ5IHNj aGVtZSBmb3IgTExOcw0KPiA+ID4+PiB0aGF0IHdlIG5hbWVkIGl0IENvLWlPQU0uIFRoZSBpZGVh IGlzIHZlcnkgc2ltcGxlIGJ1dCBpdCBoYXMgYmVlbg0KPiA+ID4+PiB2ZXJ5IGVmZmVjdGl2ZSBp biBtb25pdG9yaW5nIGEgcmVhbC13b3JsZCBkZXBsb3ltZW50IG9mDQo+ID4gPj4+IFJQTC82TG9X UEFOIG5ldHdvcmsgdGhhdCB3ZSBzZXR1cC4NCj4gPiA+Pg0KPiA+ID4+PiBbIkNvLWlPQU06IElu LXNpdHUgdGVsZW1ldHJ5IG1ldGFkYXRhIHRyYW5zcG9ydCBmb3IgcmVzb3VyY2UNCj4gPiA+Pj4g Y29uc3RyYWluZWQgbmV0d29ya3Mgd2l0aGluIElFVEYgc3RhbmRhcmRzIGZyYW1ld29yayIsDQo+ ID4gPj4+IGh0dHBzOi8vaWVlZXhwbG9yZS5pZWVlLm9yZy9hYnN0cmFjdC9kb2N1bWVudC84MzI4 Mjc2XQ0KPiA+ID4+DQo+ID4gPj4gQmVoaW5kIGEgcGF5d2FsbC4NCj4gPiA+PiBJcyB0aGlzIHN1 aXRhYmxlIGZvciBhbiBSRkM/DQo+ID4gPj4NCj4gPiA+Pg0KPiA+ID4+IC0tDQo+ID4gPj4gTWlj aGFlbCBSaWNoYXJkc29uIDxtY3IrSUVURkBzYW5kZWxtYW4uY2E+ICAgLiBvIE8gKCBJUHY2IEnD uFQNCj4gY29uc3VsdGluZyApDQo+ID4gPj4gICAgICAgICAgIFNhbmRlbG1hbiBTb2Z0d2FyZSBX b3JrcyBJbmMsIE90dGF3YSBhbmQgV29ybGR3aWRlDQo+ID4gPj4NCj4gPiA+Pg0KPiA+ID4+DQo+ ID4gPj4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4+IFJvbGwgbWFpbGluZyBsaXN0DQo+ID4g Pj4gUm9sbEBpZXRmLm9yZw0KPiA+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcm9sbA0KPiA+ID4NCj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+ID4gPiBSb2xsIG1haWxpbmcgbGlzdA0KPiA+ID4gUm9sbEBpZXRm Lm9yZw0KPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQo+ ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBS b2xsIG1haWxpbmcgbGlzdA0KPiA+IFJvbGxAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IFJvbGwgbWFpbGluZyBsaXN0DQo+IFJvbGxAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQo= From nobody Mon Aug 30 07:50: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 2BD243A153B for ; Mon, 30 Aug 2021 07:50:45 -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 m2kmfngyCVS0 for ; Mon, 30 Aug 2021 07:50:39 -0700 (PDT) Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (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 099253A1534 for ; Mon, 30 Aug 2021 07:50:38 -0700 (PDT) Received: by mail-ua1-x92f.google.com with SMTP id 37so7937603uau.13 for ; Mon, 30 Aug 2021 07:50:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=XCGlJZZp6w7CHVgSl/vgBA32hUKHZ4VRpVNmj+JA6vQ=; b=u5P0Q2IHSn9FnLUcoHQhW9JOL6p6BoW55YKA4qCcu/f8wfpTIEY0C06+FKSIL+JDu8 nUQkSyhbSJ8PqU3+37vXWZ0Ox0JYMKCcbUmtZacdhsrrLCgTfTYj087k+DUJqvd88TpA HDMqDYDK6Lt8t+d3AcpbsZLmKhCVp9kGqfEpueJrIsz3d80MdkL2sB/tnJSrFORPxybN 4u0bl14vQNXH0ZJbzSBkYCYUvssd8WVF7llvXj3PEcrI05e8i7Kqpb8K2h8skAyoQdD9 Obj6xkiA7G/uS9YIddD0MgdN1nB7wWimPQT0bl3bZj168RE7Ixku6Xjx1Ixq9nzALD+5 mV1Q== 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=XCGlJZZp6w7CHVgSl/vgBA32hUKHZ4VRpVNmj+JA6vQ=; b=BPgDgJ+EyayhL4G0/qnWXupV/13qVfZR40HlxsDmgIuHv4rsBXKx5F08Va/fdpdIOo mQXenHFQ1BsHVU425lUvES3ic1XZpD3bqlq+B+e1S9buLPdSIG1SBIHAbhEWlXxoeW12 STX7sZgNNy3lE7aSrz1GWpIsu/dl0fmZMQuMSqssQ4STv3B4+c3mF7nwYddnvSwb51Ir YKJhLtr03omgcLZw8FkOsNl0TaNLzMnQjKVTZ8Cl8FE1U68iYZKPZm1XZs9AsAL8EcyQ humJrr8gsSuIX6ZoAEFavk1lDRPFzPpPxzdBZN5qtnUVMPM7DrKuiH9IwP4YsZTeSddo 1mfw== X-Gm-Message-State: AOAM533GXAXVXIfi7oYUEVwmAQAU/z3vMzMjFOPXUp4RRC/NcTikAcD+ YKiUwK7jpSIFRP120SMsn53RyDMOIYp28B6CmYx/gJXq X-Google-Smtp-Source: ABdhPJwMnXCrKEQl7W2TZdgcXjbymmipgTyFXsYXiPW4mxzyAcFWIegPbUqh6Fl0PKv9axAgpsbVs67j2NxI1C6Mr1U= X-Received: by 2002:ab0:42c6:: with SMTP id j64mr14856235uaj.51.1630335037405; Mon, 30 Aug 2021 07:50:37 -0700 (PDT) MIME-Version: 1.0 References: <163033223438.8507.13442799687479808565@ietfa.amsl.com> <00a001d79da8$bf30ec40$3d92c4c0$@yahoo.com> In-Reply-To: <00a001d79da8$bf30ec40$3d92c4c0$@yahoo.com> From: Ines Robles Date: Mon, 30 Aug 2021 17:50:01 +0300 Message-ID: To: roll Content-Type: multipart/alternative; boundary="000000000000c4ff0905cac7f452" Archived-At: Subject: [Roll] NomCom 2021-2022 Call for Nominations X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2021 14:50:45 -0000 --000000000000c4ff0905cac7f452 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FYI, -----Original Message----- From: ietf On Behalf Of NomCom Chair 2021 Sent: Monday, August 30, 2021 10:04 To: IETF Announcement List Cc: ietf@ietf.org Subject: NomCom 2021-2022 Call for Nominations Finally! The moment we've all been waiting for: C A L L F O R N O M I N A T I O N S ! ! ! The 2021-22 IETF Nominating Committee (NomCom) is seeking nominations from now until Monday, October 11, 2021. The open positions and more information are found at the NomCom web site: https://datatracker.ietf.org/nomcom/2021/ They are also included below for convenience. Nominations may be made by selecting the Nominate link at the top of the NomCom 2021 home page, or by visiting the following URL: https://datatracker.ietf.org/nomcom/2021/nominate/ Self-nomination is welcome! Note: Nominations made using the web tool require an ietf.org datatracker account. You can create a datatracker ietf.org account if you don't have one already by visiting the following URL: https://datatracker.ietf.org/accounts/create/ If you are unable to use the web form, nominations may instead be made by email to nomcom-2021 at ietf dot org. If using email, please include the word "Nominate" in the Subject and indicate in the email who is being nominated, their email address (to confirm acceptance of the nomination), and the position for which you are making the nomination. If you are nominating someone other than yourself, please tell us if we may tell the nominee that you were the one who made the nomination. If you wish to nominate someone via email for more than one position, please use separate emails to do so. Willing nominees will be asked to fill out a questionnaire specific to the position for which they are nominated. The finalized questionnaires will be available no later than Monday, September 6, 2021 (preliminary versions are already posted) and have a submission deadline of Monday, October 18, 2021. NomCom 2021-22 will follow the policy for "Open Disclosure of Willing Nominees" described in BCP 10/RFC 8713: "The list of nominees willing to be considered for positions under review in the current NomCom cycle is not confidential". Willing nominees for each position will be listed in a publicly accessible way, e.g., anyone with a datatracker account may access the lists. Additionally, the nomination form asks if we may share your own name with the nominee. In all other ways, the confidentiality requirements of BCP 10 remain in effect. All feedback and all NomCom deliberations will remain confidential and will not be disclosed. There is a field on the form you can mark in order to allow the NomCom to tell the nominee that you were the one who made the nomination. This defaults to =E2=80=9Cno=E2=80=9D - so if you don't mark the field we won=E2= =80=99t tell. In order to ensure time to collect sufficient community feedback about each of the willing nominees, nominations must be received by the NomCom on or before Monday, October 11, 2021. Please submit your nominations as early as possible for the sake of your nominees. Note that nominations should not wait for nominee management permission, as it is easier to decline the nomination than put one in late. The NomCom appoints individuals to fill open slots on the IAB, IESG, the IETF Trust and the LLC Board: ART AD: 1 position INT AD: 1 position OPS AD: 1 position RTG AD: 1 position SEC AD: 1 position TSV AD: 1 position IETF Trust: 1 position IETF LLC: 1 position IAB: 6 positions The list of people and posts whose terms end with the March 2022 IETF meeting, and thus the positions for which this NomCom is responsible, is: [An asterisk (*) next to a person's name indicates they do not intend to accept renomination.] LLC Board (3-year term) Jason Livingood IETF Trust (3-year term) Kathleen Moriarty IAB (2-year term) Ben Campbell * Cullen Jennings Mirja K=C3=BChlewind Jared Mauch Tommy Pauly Jiankang Yao IESG (2-year term) Murray Kucherawy, ART AD Erik Kline, INT AD Robert Wilton, OPS AD Martin Vigoureux, RTG AD Benjamin Kaduk, SEC AD * Martin Duke, TSV AD Please be resourceful in identifying possible candidates for these positions, as developing our talent is a very crucial requirement for the IETF, and also, please consider accepting a nomination. You'll find extensive information about specific positions, in individual tabs at: https://datatracker.ietf.org/nomcom/2021/requirements/ In addition to nominations, the NomCom seeks community input on the positions themselves. We need and welcome the community's views and input on the jobs within each organization. If you have ideas on the positions=E2= =80=99 responsibilities (more, less, different), please let us know. Please send suggestions and feedback about this to nomcom-2021 at ietf dot org. Thank you for your help in identifying qualified nominees! Thanks, Gabriel Montenegro IETF NomCom Chair 2021-22 nomcom-chair-2021 at ietf dot org --000000000000c4ff0905cac7f452 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

FYI,

-----Original Message-----
From: ietf <i= etf-bounces@ietf.org> On Behalf Of NomCom Chair 2021
Sent: Monday, August 30, 2021 10:04
To: IETF Announcement List <ietf-announce@ietf.org>
Cc: ietf@ietf.org Subject: NomCom 2021-2022 Call for Nominations

Finally! The moment we've all been waiting for:

=C2=A0 =C2=A0C A L L=C2=A0 =C2=A0 =C2=A0 =C2=A0F O R=C2=A0 =C2=A0 =C2=A0 = =C2=A0N O M I N A T I O N S=C2=A0 ! ! !

The 2021-22 IETF Nominating Committee (NomCom) is seeking nominations from = now until Monday, October 11, 2021.

The open positions and more information are found at the NomCom web site:
https://datatracker.ietf.org/nomcom/2021/

They are also included below for convenience.

Nominations may be made by selecting the Nominate link at the top of the No= mCom 2021 home page, or by visiting the following URL:

https://datatracker.ietf.org/nomcom/2021/nominate/=

Self-nomination is welcome!

Note:=C2=A0 Nominations made using the web tool require an ietf.org datatracker a= ccount. You can create a datatracker ietf.org account if you don't have one a= lready by visiting the following URL:

https://datatracker.ietf.org/accounts/create/

If you are unable to use the web form, nominations may instead be made by e= mail to nomcom-2021 at ietf dot org. If using email, please include the wor= d "Nominate"
in the Subject and indicate in the email who is being nominated, their emai= l address (to confirm acceptance of the nomination), and the position for w= hich you are making the nomination. If you are nominating someone other tha= n yourself, please tell us if we may tell the nominee that you were the one= who made the nomination. If you wish to nominate someone via email for mor= e than one position, please use separate emails to do so.

Willing nominees will be asked to fill out a questionnaire specific to the = position for which they are nominated. The finalized questionnaires will be= available no later than Monday, September 6, 2021 (preliminary versions ar= e already posted) and have a submission deadline of Monday, October 18, 202= 1.

NomCom 2021-22 will follow the policy for "Open Disclosure of Willing = Nominees" described in BCP 10/RFC 8713: "The list of nominees wil= ling to be considered for positions under review in the current NomCom cycl= e is not confidential". Willing nominees for each position will be lis= ted in a publicly accessible way, e.g., anyone with a datatracker account m= ay access the lists. Additionally, the nomination form asks if we may share= your own name with the nominee. In all other ways, the confidentiality req= uirements of BCP
10 remain in effect. All feedback and all NomCom deliberations will remain = confidential and will not be disclosed.

There is a field on the form you can mark in order to allow the NomCom to t= ell the nominee that you were the one who made the nomination. This default= s to =E2=80=9Cno=E2=80=9D - so if you don't mark the field we won=E2=80= =99t tell.

In order to ensure time to collect sufficient community feedback about each= of the willing nominees, nominations must be received by the NomCom on or = before Monday, October 11, 2021.

Please submit your nominations as early as possible for the sake of your no= minees. Note that nominations should not wait for nominee management permis= sion, as it is easier to decline the nomination than put one in late.

The NomCom appoints individuals to fill open slots on the IAB, IESG, the IE= TF Trust and the LLC Board:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 ART AD: 1 position
=C2=A0 =C2=A0 =C2=A0 =C2=A0 INT AD: 1 position
=C2=A0 =C2=A0 =C2=A0 =C2=A0 OPS AD: 1 position
=C2=A0 =C2=A0 =C2=A0 =C2=A0 RTG AD: 1 position
=C2=A0 =C2=A0 =C2=A0 =C2=A0 SEC AD: 1 position
=C2=A0 =C2=A0 =C2=A0 =C2=A0 TSV AD: 1 position
=C2=A0 =C2=A0 =C2=A0 =C2=A0 IETF Trust: 1 position
=C2=A0 =C2=A0 =C2=A0 =C2=A0 IETF LLC: 1 position
=C2=A0 =C2=A0 =C2=A0 =C2=A0 IAB: 6 positions

The list of people and posts whose terms end with the March 2022 IETF meeti= ng, and thus the positions for which this NomCom is responsible, is:

[An asterisk (*) next to a person's name indicates they do not intend t= o accept renomination.]

=C2=A0 =C2=A0 =C2=A0 =C2=A0 LLC Board (3-year term)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jason Livingood

=C2=A0 =C2=A0 =C2=A0 =C2=A0 IETF Trust (3-year term)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Kathleen Moriarty
=C2=A0 =C2=A0 =C2=A0 =C2=A0 IAB (2-year term)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ben Campbell *
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Cullen Jennings
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mirja K=C3=BChlewin= d
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jared Mauch
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Tommy Pauly
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jiankang Yao

=C2=A0 =C2=A0 =C2=A0 =C2=A0 IESG (2-year term)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Murray Kucherawy, A= RT AD
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Erik Kline, INT AD<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Robert Wilton, OPS = AD
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Martin Vigoureux, R= TG AD
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Benjamin Kaduk, SEC= AD *
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Martin Duke, TSV AD=

Please be resourceful in identifying possible candidates for these position= s, as developing our talent is a very crucial requirement for the IETF, and= also, please consider accepting a nomination. You'll find extensive in= formation about specific positions, in individual tabs at:

https://datatracker.ietf.org/nomcom/2021/requi= rements/

In addition to nominations, the NomCom seeks community input on the positio= ns themselves. We need and welcome the community's views and input on t= he jobs within each organization. If you have ideas on the positions=E2=80= =99 responsibilities (more, less, different), please let us know.

Please send suggestions and feedback about this to nomcom-2021 at ietf dot = org.

Thank you for your help in identifying qualified nominees!

Thanks,

Gabriel Montenegro
IETF NomCom Chair 2021-22
nomcom-chair-2021 at ietf dot org


--000000000000c4ff0905cac7f452-- From nobody Mon Aug 30 19:46: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 91FE73A2D00; Mon, 30 Aug 2021 19:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 L4t1yaKNgI7t; Mon, 30 Aug 2021 19:45:43 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 65F2D3A2CFE; Mon, 30 Aug 2021 19:45:41 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 17V2jOjE024372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 30 Aug 2021 22:45:29 -0400 Date: Mon, 30 Aug 2021 19:45:24 -0700 From: Benjamin Kaduk To: Charlie Perkins Cc: The IESG , draft-ietf-roll-aodv-rpl@ietf.org, roll-chairs@ietf.org, roll@ietf.org, Ines Robles , aretana.ietf@gmail.com Message-ID: <20210831024524.GR96301@kduck.mit.edu> References: <161913172006.16574.8625402788675096789@ietfa.amsl.com> <54ab3f3d-3220-6fbb-a01f-8effc87a5f10@earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <54ab3f3d-3220-6fbb-a01f-8effc87a5f10@earthlink.net> Archived-At: Subject: Re: [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 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, 31 Aug 2021 02:45:49 -0000 Hi Charlie, Please also excuse my delay in responding. There's a number of your points that need no further reply, so I'll spare you the repeated "sounds good"/"ok"/etc. and reply inline only as needed. On Wed, Aug 18, 2021 at 01:46:17PM -0700, Charlie Perkins wrote: > Hello Benjamin, > > Please excuse the unusually long delay it has taken for us to respond to > your comments. > > Regarding the following: > > > >  Benjamin Kaduk Discuss > > Discuss (2021-04-22) > > > 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. > > Thank you very much for pointing out this inconsistency.  Once we > decided that > the 'S' bit was not explicitly needed in the RREP option, we should have > changed this wording, but we just missed it.  Instead of referring to > the 'S' > bit of the RREP, the text has to instead refer to a status bit in the > internal > data structure for the RREQ-Instance, which we also called the 'S' bit. Ah, in an internal data structure for the instance! That changes a number of my other comments, I think; it's unfortunate that you have to reply to so many coments made under a flawed assumption. > > <===== Text added after the last para of Step 1 of 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. > >       When a router joins the RREQ-Instance, it also associates within >       its data structure for the RREQ-Instance the information about >       whether or not the RREQ has the S-bit set to 1. This information >       associated to RREQ-Instance is known as the S-bit of the >       RREQ-Instance. It will be used later during the RREP-DIO message >       processing (Section 6.4) for RPLInstance pairing as described >       in Section 6.3.3. > > ... > <=== Text added to Step 1 of 6.4.===> > > 6.4.  Receiving and Forwarding Route Reply > >    Upon receiving a RREP-DIO, a router which does not belong to the >    RREP-Instance goes through the following steps: > >    Step 1: > >       If the S-bit of the RREQ-Instance is set to 1, the router MUST >       proceed to step 2. > >       If the S-bit of the RREQ-Instance is set to 0, the router MUST >       determine whether the downward direction of the link (towards the >       TargNode) over which the RREP-DIO is received satisfies the >       Objective Function, and the router's Rank would not exceed the >       MaxRank limit.  If so, the router joins the DODAG of the RREP- >       Instance.  The router that transmitted the received RREP-DIO is >       selected as the preferred parent.  Afterwards, other RREP-DIO >       messages can be received. > > > > 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. > > We are reviewing every instance of this wording, and have made the suggested > correction where appropriate. > > > > 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. > > This is intended to be resolved by maintaining the 'S' bit status in the > RREQ-Instance. Yes, that sounds like it should work (I am slowly paging the protocol back into my brain as I go through the email). > > >            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.) > > Given the maintenance of the 'S' bit status in the RREQ-Instance, it should > not be necessary to make the determination based on whether or not the > message > was received as a multicast. Right, there's no need to use multicast vs unicast as a proxy for the S bit state. I assume that also disambiguates how to handle the gratuitous RREP case, though I haven't remembered enough of the protocol yet in order to work through it for myself. > > > 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. > > The point of the shift parameter is to be able to "modify" the value of the > RPLInstanceID so that a unique association can be made between RREQ-Instance > and RREP-Instance. We are confident that having 64 values to choose from > will > enable the node to make the unique association. Yes, having 64 values available should be fine. My comment relates to *which* 64 values those are. I was looking at how the RPL Instance ID is encoded in an 8-bit field, which would let it range from 0 to 255; if we add a 0-to-63 bit shift to such a value then it wraps if the resulting value woule exceed 255, rather than 63. However, as I now go back to look at RFC 6550 it seems that there is (at least sometimes?) additional structure within that 8-bit field, and there are only 64 instance ID values available for *local* RPLInstanceID usage. In my latter comment about the same topic you seemed to agree with the "rollover at 255" interpretation, so maybe this should get some further investigation. > > > Comment (2021-04-22) > > > 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.) > > We will use your wording when adding additional text to the Introduction. > AODV-RPL can be used alongside RPL and add routes to the existing > RPL-discovered routes.  However, there does not seem to be much value in > maintaining two routing protocols even if they are compatible. > > > > 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? > > Routes are intended to last long enough to support the applications > running on > the OrigNode and TargNode that required the route.  The same considerations > apply to RPL, and so we expected that AODV-RPL would use the same mechanism > for route longevity that is used by RPL. > > Your explanation for route lifetime is fine to me.  In addition, DODAG > lifetime cannot be lower than the route lifetime since that could lead to > stale information as observed. > > > > 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. > > Agreed.  It isn't useful. "P2P routes discoverable by native RPL" is better. > > > > 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. > > It is intended to allow for the shift parameter.  §6.3.3 clearly states > "the RREQ-Instance and the RREP-Instance in the same route discovery MUST > be paired using the RPLInstanceID." Accordingly, we modify the text as > follows. > >    "The RPLInstanceID in RREP-DIO MUST be paired to the one in the > associated >     RREQ-DIO message as described in §6.3.3." I'm happy to see the uniform applicability clarified (by removing "typically"). I would caution against writing "MUST be paired", though, since that would result in having the same requirement made using normative language in two different places in the text, which has a risk of the two statements inadvertently making slightly different requirements. Since this is already saying "as described in §6.3.3", it could be written as a declarative statement like "the RPLInstanceID in the RREP-DIO is 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? > > Yes, as long as the node receiving an RREQ or RREP message can valuate > whether > or not the link bearing an incoming message satisfies the OF. I'll leave it up to you as to whether such scenarios are worth mentioning here -- I have no sense for how practical or likely they would be. > > >>    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? > > It is possible when the links are symmetric. > > > 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). > > Yes, other options are allowed. We will clarify this point by > referring to Section 4.3 which says, "A RREQ-DIO message MUST carry at > least one ART Option.  A RREP-DIO message MUST carry exactly one ART > Option. > Otherwise, the message MUST be dropped." > > > Who sets the S bit, and can it change as the DODAG is being constructed? > > ("See Section 5" would be fine.) > > Only the OrigNode sets the 'S' bit. To be fully explicit: I think that this section's text describing the S bit should either say that itself or refer to Section 5 for more detail on its handling. > > >>    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? > > Yes, the measure time duration depends on each node's ability to keep > track of the time. > > > >>    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. > > Good point!  Yes, the TargNode can join if the rank is less than or > equal to MaxRank. > > > > 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" > > O.K. > > > >>    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? > > Both the DODAGs are part of the same route discovery, and RPLInstanceID > requires that both DODAGs be alive.  There can however be a route with > asymmetric data traffic profile between OrigNode and TargNode.  In this > case, it is possible that the data occupancy times of the two DODAGs are > different.  The OrigNode should consider this factor while fixing the > duration.  The L-value for the RREQ-Instance has to be larger than the > L value for the RREP-Instance. At least the last bit (L for RREQ-Instance > L for RREP-Instance) seems like a protocol constraint that should be documented in the RFC. How much supporting discussion to include with that is probably not something I'm the right person to answer. > > >>    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)? > > Yes, that is the requirement. > > > > > 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? > > The RREQ carries the destination sequence number for the last OF-compliant > route that OrigNode stored to the TargNode - i.e., the downstream route. > > > > Also, should we say that zero is used if there is no known > information about > > the sequence number of TargNode (and not otherwise)? > > Agreed. > > > >>    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. > > Agreed. > > > >>    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). > > Address field is 128 bits for IPv6 addresses. > > > > 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.) > > How about, "indication to the contrary is received"? That's probably a more clear way to state what the nodes are going to do. With my question I was trying to ask whether there was any processing or protocol activity that occurred prior to the indication that a given link is symmetric, that might have erroneously relied on the assumption of symmetric links. If so, how would that get unwound safely? > > >>    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? > > Yes, both of your statements are correct.  We will try to devise more exact > wording, or if you have a suggestion that would be appreciated. My attempt at a minimal change would be to insert "indicated" or "recorded" before "route from the OrigNode", but that may be missing some subtlety. > > > > > 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"? > > Good idea. > > > >>    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)? > > Yes, because in the symmetric case unicast RREP is specified. Ah, yes. Sorry to have missed that. > > >>    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.) > > Section 6.3.1 says: > >    "For a symmetric route, the RREP-DIO message is unicast to the next hop >     according to the accumulated address vector (H=0) or the route > entry (H=1)." > > > >>             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. > > We will describe Figure 5 by with the help of link asymmetry detection > methods discussion given in the same section, Section 5. The proposed text: > >    As shown in the Figure 5, an intermediate router determines the 'S' bit >    value RREQ-DIO should carry with the help of link asymmetry detection >    methods discussed in Section 5. It is expected that the intermediate >    router has already made the link asymmetry decision by the time RREQ-DIO >    arrives. > > > 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. > > O.K. > > > >>    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? > > It is also needed to put in the correct OF and other values specific to > the desired route.  If those are all the same, just incrementing the > sequence number is fine. > > > > 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. > > It is supposed to mean that the node always checks the upstream link, and > joins if the OF is satisfied.  If the OF is not satisfied, [not sure if there was supposed to be more here. I do see that the "determine into the upward direction" got fixed in response to Warren (and John), which would presumably help me some as well.] > >>       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? > > Yes, we will use that terminology. > > > > 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. > > I don't see what is wrong about using L=0 to disallow the delay. I don't know that it's wrong per se, but there's no motivation presented for it. In some sense it feels backwards to allow delay for the case where there's a finite lifetime but not allow delay for a DODAG that will be around indefinitely. If there's a reason to disallow delays here, that may weill be reasonable, but I couldn't say why based on just what I read here. There would still need to be some bound on the delay, of course, but there are plenty of ways to pick that, with the maximum allowed delay for a nonzero L value perhaps being the most natural. > > > 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. > > That is a good point.  It has to be the RREP-Instance corresponding to the > RREQ-DIO. > > > > >>    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 behavior should be the same. > > > >>    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? > > It should have said, "except for the value of the 'S' bit associated > with the RREP-instance". > > > > 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). > > > When preparing the RREP-DIO, a TargNode could find the RPLInstanceID > candidate > for the RREP-Instance is already occupied by another RPL Instance from an > earlier route discovery operation which is still active.   This unlikely > case > might happen if 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 which denotes Objective Function of the DODAG, > MUST NOT > be used again.  Reusing the same RPLInstanceID for two distinct > DODAGs originated with the same DODAGID (TargNode address) would prevent > intermediate routers to distinguish between these DODAGs (and their > associated > Objective Functions).  RPLInstanceID collisions do not occur across > RREQ-DIOs; > the DODAGID equals the OrigNode address and is sufficient to > disambiguate between DODAGs. > > > > >>    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? > > You are correct.  It should say 255 instead of 63. > > > >>    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.) > > Correct again. > > > > 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? > > > Right, it should have been RREP-Instance, not RREQ-Instance as shown. > But in fact, we do not need this conditional check at all. Processing > the newly arriving RREP-DIO even if the router has already joined > RREP-Instance can result in better downward route to TargNode. Ah, good point! > > >    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! > > Correct again.  This should refer to the S-bit of the associated Instance. > > > >>       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) > > Check. > > > >>    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.) > > Check. > > > > > 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. > > Yes. > > >>    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. > > Agreed.  These requirements belong better in the main body text. > Thanks for all the replies, and the pending updates, Ben > > On 4/22/2021 3:48 PM, Benjamin Kaduk via Datatracker wrote: > > 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 Tue Aug 31 02:27: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 F171E3A3C8D for ; Tue, 31 Aug 2021 02:27:38 -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 rJ1yw4rmzcLA for ; Tue, 31 Aug 2021 02:27:33 -0700 (PDT) Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) (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 DCEBA3A1BEB for ; Tue, 31 Aug 2021 02:27:32 -0700 (PDT) Received: by mail-ua1-x929.google.com with SMTP id x6so9346651uai.11 for ; Tue, 31 Aug 2021 02:27:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Wpvil0ds2+gYRTYWlCo+uh8uClEQD7fAgZB/yrclqbs=; b=TBImOMrGqOpsda9gVWmHS/+361yj40cQqMbhctVOuzrdeqQ9B2AHJzy/eXqPCzJhvO R0y+MCTDXqu5nP/xIlZUUM5ps6BPSVUiAa0HgniBeh6x/Vf4SnHLyKfNsknAH6I4S1Df +7KBEOJlbZiREB1aK3Nanyc88rtQmS8Ti7TFuFoHgv/ebxuu+MUGE6kTkWT9IzKr0hLw ghxMeO8pwQRgJO23EAzMuxfBqIUiey1op0BTUVsOFxFDjxz1os0TVMy+z1/kUjD6PVD3 M2QT00HezXsgqbqpncaetNSj9glkVw+GGpZEqfIKppXgVgfF7GXNYDcZs1QhDNDbK4aK iBCQ== 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:cc; bh=Wpvil0ds2+gYRTYWlCo+uh8uClEQD7fAgZB/yrclqbs=; b=NlcThInrxGi4GXhqIFU2OFfUegwsAaJhUJGxIKRcDaK4Uh9LSwV/eVhIcnUHdAHObU COFnodSVOdUeTzB+maOugFoJyHZHijuIgoJrX4DwuRzs7dwG1/AUB6++5msCxp2Kcri5 5QMnwKCJto/TD7Ym3hjRT6ZM7Y1HjFLWyCxPvX9DuTS8SsfNUX32Pnz6Rzi20XrzTAkb TSvn8DdmgIXBsJMJOwsQHBU+a751QSWUixsoz7EOuGDbqD7GTV/v5wHCq0SHLTaIhopj qTIUqehnFkxHTDhQX4j3FU0l7bbfH+uWdzqbgSh5wk8sS9Dj9lXavR+Dne2FwRudsq0Q YVUw== X-Gm-Message-State: AOAM533j+QW5E0keJV6mxcmi9C+kt4nVveaXArfIezV6xNv3USdjIF3K RnMvBtP3/DKv26ZogqAH0n/vKjJFlKF6aTyCi9C28Mv8+zA= X-Google-Smtp-Source: ABdhPJy1vQ/Fz6Hhy/oPZJwjCa2hDBpy6EF18LqKkBgv+10feP5Sdt9SL6wCSFyvTb7cJ9UYS7yBTvi3ttQeR67RMuQ= X-Received: by 2002:ab0:2bc1:: with SMTP id s1mr17495237uar.56.1630402050091; Tue, 31 Aug 2021 02:27:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ines Robles Date: Tue, 31 Aug 2021 12:26:53 +0300 Message-ID: To: roll Content-Type: multipart/alternative; boundary="000000000000096f4605cad78fbc" Archived-At: Subject: Re: [Roll] ROLL Interim Meeting - 31th August - Agenda and meeting details 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, 31 Aug 2021 09:27:39 -0000 --000000000000096f4605cad78fbc Content-Type: text/plain; charset="UTF-8" Dear all, This is a kind reminder of the roll interim meeting, please find below the link to the complete set of slides for today's meeting. https://datatracker.ietf.org/meeting/interim-2021-roll-02/materials/slides-interim-2021-roll-02-sessa-completeset-roll-interim-20210831-00.pdf Additional meeting materials: https://datatracker.ietf.org/meeting/interim-2021-roll-02/session/roll Comments welcome, Thank you, Ines and Dominique On Fri, Aug 27, 2021 at 10:47 AM Ines Robles wrote: > Dear all, > > We have updated the meeting to have it with Meetecho. Thus, please find > below the updated meeting materials: > > Meetecho Link: > https://meetings.conf.meetecho.com/interim/?short=e89314d3-d762-4877-8f84-1108420ad8a4 > > CodiMD: https://codimd.ietf.org/notes-ietf-interim-2021-roll-02-roll > > Slides: > https://datatracker.ietf.org/meeting/interim-2021-roll-02/session/roll > > Comments welcome, > > Thank you and best regards, > > Ines > > On Wed, Aug 25, 2021 at 7:04 PM Ines Robles < > mariainesrobles@googlemail.com> wrote: > >> Dear all, >> >> This is a kind reminder of the meeting next week. >> >> Dear presenter, if you haven't yet done so, please send us the slides or >> upload them into the data tracker. >> >> Thank you and Best regards, >> >> Ines and Dominique >> >> >> >> On Tue, Aug 10, 2021 at 9:50 PM Ines Robles < >> mariainesrobles@googlemail.com> wrote: >> >>> Dear all, >>> >>> Please find below the agenda for the interim meeting >>> >>> >>> https://datatracker.ietf.org/meeting/interim-2021-roll-02/materials/agenda-interim-2021-roll-02-roll-01-01.txt >>> >>> Presenters, please *by 25th August, *send us the slides in pdf, or >>> alternatively you can upload them in here : >>> https://datatracker.ietf.org/meeting/interim-2021-roll-02/session/roll. >>> >>> Link to the CodiMD: >>> https://codimd.ietf.org/notes-ietf-interim-2021-roll-02-roll >>> >>> Link to Webex : >>> https://ietf.webex.com/ietf/j.php?MTID=m0f82035057cfa91a3d4a625639f73c02 >>> >>> Note that you can find the provided information (CodiMD, Webex Link, >>> Jabber, icalendar) also in the top right corner of the meeting page [ >>> https://datatracker.ietf.org/meeting/interim-2021-roll-02/session/roll] >>> >>> Comments welcome, >>> >>> Thank you and best regards, >>> >>> Ines and Dominique. >>> >>> On Wed, Jun 30, 2021 at 1:10 PM Ines Robles < >>> mariainesrobles@googlemail.com> wrote: >>> >>>> Dear all, >>>> >>>> Thank you very much for filling the doodle. The date selected is 31th >>>> August at 3pm UTC. >>>> >>>> Please let us know if you would like to Present a topic by 30th July >>>> specifying: >>>> >>>> - Topic >>>> - Duration >>>> - Presenter. >>>> >>>> Further meeting details (webex, codimd, etc.) will be provided later. >>>> >>>> Thank you very much in advance, >>>> >>>> Ines and Dominique. >>>> >>>> >>>> On Mon, Jun 7, 2021 at 12:57 PM Ines Robles < >>>> mariainesrobles@googlemail.com> wrote: >>>> >>>>> Dear all, >>>>> >>>>> We would like to organize an interim meeting. Thus, we kindly request >>>>> to let us know your availability by filling the following doodle by *12th >>>>> June. * >>>>> >>>>> >>>>> https://doodle.com/poll/nd3z4wyar6tqudcv?utm_source=poll&utm_medium=link >>>>> >>>>> Thank you very much in advance, >>>>> >>>>> Ines and Dominique. >>>>> >>>> --000000000000096f4605cad78fbc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

This is a kind reminder o= f the roll interim meeting, please find below the link to the complete set = of slides for today's meeting.=C2=A0

Comments welcome,

Thank you,

Ines and Dominique

On Fri, Aug 27, 2021 at 10:47 = AM Ines Robles <maria= inesrobles@googlemail.com> wrote:
Dear all,

= We have updated the meeting to have it with Meetecho. Thus, please find bel= ow the updated meeting materials:




Comments welcome,
<= div>
Thank you and best regards,

Ine= s

On Wed, Aug 25, 2021 at 7:04 PM Ines Robles <mariainesrobles@googlemail= .com> wrote:
Dear all,

This= is a kind reminder of the meeting next week.

Dear= presenter, if you haven't yet done so, please send us the slides=C2=A0= or upload them into the data tracker.

Thank you an= d Best regards,

Ines and Dominique

<= /div>


On Tue, Aug 10, 2021 at 9:50 PM Ines Robles <mariainesrobl= es@googlemail.com> wrote:
Dear all,

Please find below the agenda for the interim meeting

Pre= senters, please=C2=A0by 25th August,=C2=A0send us the slides in pdf,= or alternatively you can upload them in here :=C2=A0 https://datatracker.ietf.org/meeting/interim-2021-roll-02/session/roll= .=C2=A0


Link to Webex :=C2=A0https:= //ietf.webex.com/ietf/j.php?MTID=3Dm0f82035057cfa91a3d4a625639f73c02

Note that you can find the provided information (Cod= iMD, Webex Link, Jabber, icalendar) also in the top right corner of the mee= ting page [https://datatracker.ietf.org/meeting/i= nterim-2021-roll-02/session/roll]

Comments wel= come,

Thank you and best regards,

Ines and Dominique.=C2=A0

On Wed, Jun 30, 2021 at 1:10 PM Ine= s Robles <mariainesrobles@googlemail.com> wrote:
Dear= all,

Thank you very much for filling the doodle. Th= e date selected is 31th August at 3pm UTC.=C2=A0

P= lease let us know if you would like to Present a topic by 30th July specify= ing:

- Topic
- Duration
- Pres= enter.

Further meeting details (webex, codimd, etc= .) will be provided later.=C2=A0

Thank you very mu= ch in advance,

Ines and Dominique.=C2=A0
=


On Mon, Jun 7, 2021 at 12:57 PM Ines Robles <mariainesrobles@g= ooglemail.com> wrote:
Dear all,

We would lik= e to organize an interim meeting. Thus, we kindly request to let us know yo= ur availability by filling the following doodle by 12th June.=C2=A0<= /div>


--000000000000096f4605cad78fbc--