From nobody Thu Feb 3 07:35:48 2022 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A19C3A092D; Thu, 3 Feb 2022 07:35:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: aretana.ietf@gmail.com, dominique.barthel@orange.com, roll-chairs@ietf.org, roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.44.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164390254560.12521.5148569617130077622@ietfa.amsl.com> Date: Thu, 03 Feb 2022 07:35:46 -0800 Archived-At: Subject: [Roll] roll - New Meeting Session Request for IETF 113 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2022 15:35:47 -0000 A new meeting session request has just been submitted by Dominique Barthel, a Chair of the roll working group. --------------------------------------------------------- Working Group Name: Routing Over Low power and Lossy networks Area Name: Routing Area Session Requester: Dominique Barthel Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 25 Conflicts to Avoid: Chair conflict: anima manet cellar asdf 6tisch core ace lake lpwan raw Technology overlap: rtgarea 6lo 6man lwig cbor t2trg bier Key participant conflict: detnet rtgwg intarea iotops Can't meet: Wednesday morning, Wednesday early afternoon, Friday morning People who must be present: Michael Richardson Dominique Barthel Alvaro Retana Ines Robles Resources Requested: Special Requests: most likely, both chairs are going to be remote. --------------------------------------------------------- From nobody Thu Feb 3 10:19:01 2022 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 885433A1399; Thu, 3 Feb 2022 10:18:59 -0800 (PST) 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmcgLqE4zPyL; Thu, 3 Feb 2022 10:18:55 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00:e000:2bb::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5CB03A1390; Thu, 3 Feb 2022 10:18:53 -0800 (PST) Received: from dooku.sandelman.ca (cpef81d0f835a73-cmf81d0f835a70.sdns.net.rogers.com [174.115.215.42]) by relay.sandelman.ca (Postfix) with ESMTPS id 0E2DC1F44B; Thu, 3 Feb 2022 18:18:51 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id ECC411A0406; Thu, 3 Feb 2022 13:18:48 -0500 (EST) From: Michael Richardson To: anima@ietf.org cc: roll@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Date: Thu, 03 Feb 2022 13:18:48 -0500 Message-ID: <225387.1643912328@dooku> Archived-At: Subject: [Roll] p2p RPL connections and ACP/RFC8994 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, 03 Feb 2022 18:19:00 -0000 --=-=-= Content-Type: text/plain Today I am reloading some switches with a new TCAM partitioning. It turned out that some new (to us) equipment had zero space allocated for IPv6 multicast groups, which was really causing us a lot of mysterious stuff where ND just wouldn't work. ("show sdm prefer" if someone is finding this email later on...) For one switch, we had an out-of-band access to get to the console/craft so I could do this remotely. For a second switch, it turned out that I had no way to get to the console server that didn't go through that switch. (There was a goal of having a separate mgmt network, but it was hard to convince STP that loops weren't involved. My STP-fu is low) So of course, I look forward to using ACP/RFC8994 for this. While RPL ought to be able to route around a failing/restarting switch, and in theory, if the switch knows it is going down, it can do appropriate DAO messages to remove itself from the DODAG. But, I'd want to make sure that I wasn't going through the switch before starting the maintenance. Some kind of "protect" marking. It occured to me that p2p-rpl could perhaps do this if it could express the right metric being "does not traverse device X". Or now we think we can replace this with aodv-rpl. I'm wondering if anyone has any thoughts on about to express this metric? Is a metric the right thing to do? I doubt that this has utility in sensor LLNs, but I think that RFC8994 ACPs would definitely like to have this. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAEBCgAdFiEEow/1qDVgAbWL2zxYcAKuwszYgEMFAmH8HIgACgkQcAKuwszY gEMPlgv/UvtUsis+nYAX/LnKPh/pDaKVVfsq+bU3cLEuQzgQNqLDlqI3x2xDfGzK B+Uwp0Db9+oXnN7o0tnf3YHQ0a6okw+5Q+W9NhX6ahXa5w4q+Lpu7AWjHHOriKwG Jcm6L89K3zlw5PjklfCw13Z4aQuoslmj3aUnME9M9zzcMzbHlH0sI6H3pp8vj6OV /5gMrKiK7ZoJ9pstObvQ2tzceWNPRtDBXyrhX2lo52NKGo6/N+t3WiEMeqctU4rm XPXmBgPxU8Ut1yl7RoZWg5BGvWCulrSeG+w1IVTnT91Mq42NKg2itI957lADfS2K cqVkLoPqcy9czBWoqBUGxUqY3jik8DnC27YckwqElxwo8ZwQLhtrKUcpl5OP+h97 MOtUJfRR7tprWuQU/VnDrECPvi6W1EyhCCBlYfAxjiqSH9ol0J7vzrUApeG8yGBh n21cWMPWzCtUpIdlWm/vTu+VHSMJpYC56af/uKpVgrwjMIZ6D6bYEX9O/qoMO8f5 owFRfeIV =kcNi -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Feb 6 23:05:39 2022 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBFD3A07D4; Sun, 6 Feb 2022 23:05:37 -0800 (PST) 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 aer6tNF_VKIR; Sun, 6 Feb 2022 23:05:30 -0800 (PST) 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 4B8093A07D7; Sun, 6 Feb 2022 23:05:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by duch.mimuw.edu.pl (Postfix) with ESMTP id CC6D460097896; Mon, 7 Feb 2022 08:05:23 +0100 (CET) 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 wAj6_Bka1AqO; Mon, 7 Feb 2022 08:05:21 +0100 (CET) Received: from [IPV6:2a02:a311:813e:880:fce8:f3:4ae1:bd31] (unknown [IPv6:2a02:a311:813e:880:fce8:f3:4ae1:bd31]) (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; Mon, 7 Feb 2022 08:05:20 +0100 (CET) Message-ID: <51f1c414-0e02-f09f-83a2-6efb6a19a352@mimuw.edu.pl> Date: Mon, 7 Feb 2022 08:05:20 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 From: Konrad Iwanicki Reply-To: Routing Over Low power and Lossy networks To: roll@ietf.org Cc: roll-chairs@ietf.org References: Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Roll] Review of draft-ietf-roll-aodv-rpl-12 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2022 07:05:37 -0000 Dear authors, I have the following remarks regarding the draft. (The comments are based solely on the contents of the draft. I did not review the change log nor any meeting proceedings.) # Major issues / questions: 1. For garbage-collecting RREQ- and RREP-DODAGs that are no longer necessary, a timeout solution is used: the L field in the RRE(Q|P) messages. Although this is not formulated explicitly in the draft, from the format of the messages, I assume that the timeout is counted locally and independently by each node, from the moment it joins the corresponding DODAG. In particular, depending among others on the network topology, the configuration of Trickle, and the underlying link-layer, a node may start a timeout for a DODAG after another has already left this DODAG. This is dangerous as it may lead to situations in which information about a DODAG is never garbage-collected because nodes that leave the DODAG may rejoin it upon hearing information from other nodes that are still in the DODAG. I would opt for an alternative solution or at least some poisoning- or grace-period based approach. In addition, it would be nice to have in the draft a potential risk analysis regarding the configuration parameters of the solution. 2. What is the rationale behind deleting by TargNode the DIO ART Option containing its address (and then taking address set intersections when propagating the DIOs)? What problem do these mechanisms aim to solve? A node can still receive DIOs along multiple paths. It should be able to choose the "most desirable one". Deleting the target address and using the intersection mechanism described in Sect. 6.2.2. may actually preclude this behavior if the "most desirable path" for a TargNode is not the one it obtains first. For example, consider the following circular network: A1 - OR - B1 | | A2 B2 | | T1 - T2 - B3 with OR = OrigNode, T1 = TargNode1, T2 = TargNode2, and (A|B)* acting as intermediate routers. Suppose that the path over nodes B* is the most desirable one for both T1 and T2. Now, consider the following scenario. T1 receives an RREQ-DIO first from A2 and joins the RREQ-DODAG. It then propagates the DIO to T2 but with ART Option with its own address (T1) removed. In effect T2 also joins the RREQ-DODAG, remembering however that the last RREQ-DIO contained only T2. Now, T2 finally receives an RREQ-DIO from B3. It does not propagate to T1 this path because: (1) it removes its own address from the DIO and (2) the address of T1 is not included because of taking the intersection of the address sets T2 received in the DIOs along the two paths. In effect, T1 will never learn the most desirable path. Is this what is expected to happen or am I missing something? Again, it is not clear to me what the goal of the removal and intersection is. In the end, original RPL creates routes from multiple targets (all nodes) to the root, so why does this protocol require dynamically removing the targets? 3. A related concern applies to Sect. 6.2.6., more specifically, to the second statement: "If, on the other hand, TargNode was already associated with the RREQ-Instance, it takes no further action and does not send an RREP-DIO." To me, it implies that TargNode replies with RREP-DIO to the first RREQ that results in its joining the corresponding RREQ-DODAG. In particular, if it learns about a better path to OrigNode, it does not use this path instead of the first path it joined. Again, am I missing something or is this intentional? If so, it seems somewhat conflicting with the second paragraph of Sect. 6.3, which allows the node to wait for RREP_WAIT_TIME before replying. Trying to combine these two sections, my understanding would be that TargNode sends an RREP to the best path that it is able to learn within the RREP_WAIT_TIME. If this was the intention, then what is the rationale behind setting the default RREP_WAIT_TIME to 0 for L = 0? This would imply that for an RREQ-DODAG that is to be maintained infinitely long, only the first path to OrigNode learned by TargNode is considered. In general, why not introduce into the protocol algorithms for TargNode to update its path when it learns a better one? This would also require updating RREP propagation, which is again done only for the first received message (per Sect. 6.4). 4. It is not entirely clear to me how Trickle timers govern transmissions of multicast RREQ/RREP DIOs. In particular, when the timers are reset? How is this policy influenced by the fact that, in line with my previous comments, in principle a node reacts only the first RREQ/RREP DIOs that cause its joining the corresponding DODAGs. Perhaps a bit extended discussion of these issues could be provided in Sect. 8. 5. There is also no discussion in the draft of a situation in which a node has no resources to join a RREQ- or RREP-DODAG. While in the case of RPL, this is arguably not that relevant, in the proposed protocol, there may be many concurrent DODAGs, and hence it is intuitively more likely that some nodes may lack resources to handle all DODAGs. # Smaller issues / nits: Page 4, definition of "AODV": add a space between "Routing" and "[RFC3561]". Page 4, definition of "DODAG RREQ-Instance": "control message transmission" (hard to parse) => "transmission of control messages" Page 4, definition of "DODAG RREP-Instance": the same as above Page 6, text ""RREQ-DIO message" means the DIO message from OrigNode to TargNode" is confusing as DIO messages are link-local. Changing this to ""RREQ-DIO message" means a DIO message from OrigNode toward TargNode" may sound better. The same applies to the next statement. Page 8, definition of "L": "the time" => "time" Page 8, definition of "MaxRank" is confusing. The name would suggest that this is the maximal allowed value, whereas the text implies that this is the minimal disallowed value. Perhaps the name "MaxRank" could be changed to something else, like "RankLimit". Page 8, "Other nodes MUST NOT join RREQ instance if its own Rank would be" => "Any other node MUST NOT join..." Page 9, definition of "L": "The lifetime of the RREP-Instance MUST be shorter than the lifetime of the RREQ-Instance to which it is paired. What if the lifetime of the RREQ-Instance is infinite? In general, why such a requirement? Page 14, the last paragraph, text starting from "It does this..." is unclear to me. What happens in the end with MaxUseRank? (This is the first and only paragraph where this symbol occurs.) Page 18, the last paragraph: term "shift" is somewhat misleading (to me it describes bit shifts: right shift, left shift). Perhaps "offset" or "delta" would be better. Page 18, the last paragraph: The text starting with "In RREP-DIO option, the Shift field..." seems confusing. More specifically, it is not clear to me what is shifted/offset: (1) does the receiving node have to offset the RPLInstanceID in the RREP-DIO to obtain the RPLInstanceId in the RREQ-DIO OR (2) is the RPLInstanceID in the RREP-DIO equal to the RPLInstanceID in the RREQ-DIO but the receiving node should offset the former so as to avoid conflicts? I guess it is (1) but am not sure based on the text. In particular, what "original" means there? Page 18, the last paragraph: "would prevent intermediate routers to distinguish" => "would prevent intermediate routers from distinguishing". Page 20, Sect. 6.4.4., "Otherwise In case of an asymmetric route" => "Otherwise, in case of an asymmetric route" Page 20, Sect. 7, the second paragraph: "is at least as large" as what? As the sequence number in the RREQ-DIO message? Rather than / in addition to Appendix A, perhaps citing relevant scientific papers may be informative? That seems all given the time I had. Hope that the review helps. Best, -- - Konrad Iwanicki. From nobody Mon Feb 7 05:22:38 2022 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 257843A00F7; Mon, 7 Feb 2022 05:22:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.613 X-Spam-Level: X-Spam-Status: No, score=-2.613 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.714, 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 JYpdizZ6knD4; Mon, 7 Feb 2022 05:22:31 -0800 (PST) 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 D8D4E3A0E65; Mon, 7 Feb 2022 05:22:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by duch.mimuw.edu.pl (Postfix) with ESMTP id 64C7661D8F065; Mon, 7 Feb 2022 14:22:23 +0100 (CET) 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 tz0afAms71C1; Mon, 7 Feb 2022 14:22:21 +0100 (CET) Received: from [IPV6:2001:6a0:5001:2:e9a9:c685:f5c1:45c3] (unknown [IPv6:2001:6a0:5001:2:e9a9:c685:f5c1:45c3]) (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; Mon, 7 Feb 2022 14:22:19 +0100 (CET) Message-ID: <9c2e872a-7e7c-1e3b-dd6d-d3cd0681f33a@mimuw.edu.pl> Date: Mon, 7 Feb 2022 14:22:19 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Content-Language: en-US To: Routing Over Low power and Lossy networks References: <30208.1637590535@localhost> <74673648-79a7-9611-5b71-b089a9a3e37e@mimuw.edu.pl> <76746.1637774741@dooku> <9C03FC6E-05D6-45FB-99C5-8BC84193C3AD@cisco.com> <327.1637873630@localhost> Cc: roll-chairs From: Konrad Iwanicki In-Reply-To: <327.1637873630@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Roll] enrollment priority 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, 07 Feb 2022 13:22:36 -0000 Hi all, Since after reviewing the AODV draft I was already in the "draft mode", I created a pull request on GitHub for roll-enrollment-priority. It should cover all major issues that we discussed apart from the math for computing the Enhanced Beacon Join priority from the base priority value because I believe there were no conclusions on this issue. (Sorry if I forgot about anything.) I also tried to do little copy-editing to keep the change small. In summary, the major changes are as follows: - I extended the option with a sequence counter and a bit for resetting trickle timer on demand. I also reordered some fields to better -- in my view -- fit the current contents of the option. - Described the processing of the option, notably taking into account the sequence counter and the trickle bit. - Did some minor updates in the compatibility section to reflect that a node may learn the min priority value over multiple paths. Hope that the changes will help push the draft further. Best, -- - Konrad Iwanicki. On 25/11/2021 21:53, Michael Richardson wrote: > > Pascal Thubert \(pthubert\) wrote: > > (https://mailarchive.ietf.org/arch/msg/roll/2MaZ4wXLVzJbmLC-LO6c--DsbWQ/) > > Konrad Iwanicki wrote: > konrad> - How do changes to min priority (and OSN) affect DIO Trickle timers? > konrad> [OSN == the lollipop sequence counter] > > konrad> I think that if we have the counter, that increments the OSN reset the trickle > konrad> timer, but Pascal suggests an additional bit to reset the > konrad> trickle? > > pt> Some casual updates do not deserve to be flooded faster than normal > pt> stable DIO. But emergency and network control ones should. So we need a > pt> trigger to say that this DIO message should reset trickle. May that bit > pt> should not be in that option. It could be more generically used in > pt> DIOs. > > mcr> We can certainly build these rules into enrollment priority option. > mcr> But, I wonder if resetting trickle has general application, and should actually be > mcr> signaled by inclusion of a new DIO option. > > pt> Oups i read this after thinking the same. I agree. > > okay, I'll include this. > > konrad> - How does a (temporal) lack of a preferred parent affect the proxy > konrad> priority of the node in EBs (and in general, the node's behavior)? > > mcr> If the node can't send traffic up to the root, then I think that it should > mcr> turn off EBs until it can. > > pt> Yes; at least advertise 7F for the priority if it needs to beacon for other reasons > > I agree, 7F (infinite) if it needs to beacon. > Should it even beacon if it has no feasible parents? > > mcr> In a 6tisch situation, it is likely that the lack of a preferred parent is > mcr> probably due to falling out of the schedule. > > pt> Yes > > Pascal> A node that does not have a feasible parent should poison or > Pascal> detach. It does not make sense for a detached node to take > Pascal> visitors. So probably it should beacon a join priority of 0x7F. > > mcr> Does detach mean to send a DIO with infinite rank? > > pt> Poison means that. Detaching means forming its own dodag with the G > pt> bit not set (not grounded) > > mcr> I'm undecided if it should send a beacon at all. > mcr> https://github.com/roll-wg/draft-ietf-roll-enrollment-priority/issues/11 > > There seem to be a number of parts to a decision tree here. > > I will start more threads. > > -- > 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 Mon Feb 7 06:33:45 2022 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4E73A0847; Mon, 7 Feb 2022 06:33:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.09 X-Spam-Level: X-Spam-Status: No, score=-7.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, RCVD_IN_DNSWL_HI=-5, 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 (2048-bit key) header.d=sandelman.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsX4F4xR_9mT; Mon, 7 Feb 2022 06:33:33 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 865BC3A087B; Mon, 7 Feb 2022 06:33:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id A9DFD389F0; Mon, 7 Feb 2022 09:41:02 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id atrqsHIF2Llg; Mon, 7 Feb 2022 09:41:01 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id A33EB389E9; Mon, 7 Feb 2022 09:41:01 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1644244861; bh=fAEwplniOj14xgJeUuB0/DjYZR0FPwaRyQZ5OfgD7tM=; h=From:To:cc:Subject:In-Reply-To:References:Date:From; b=UNuf7wWcRJnfLjTY8MfZanc4DtNPZtsxGItbLEjV99D3xv99XnHlQifHSMRcCf66O zqiFIrbozDGOHxGfOmlN8vFx89oayEsnDqhDFlCTr0QI1ajGMjU+DAv0+glwv/s8NH N1DANhUmnwUIpYwHg04IEH+NDBcZgYOpyGbPS3QUlhxF91YIC+DGDXCuNFvEFecWqQ 0M5s3VnxNRzatDHC8DgpGzcdjXMBE1Cv+F0vtbWxlI+qv8YOpnggBT4ItUG8ktXwre K/pUjiwfEtr77SAgvoJpvkVZsD4jfj5Z6MGYMcyNyD4uRZFFSfHM+awvkDnBLwpnSY 4uMtz1fRWaenA== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DAD0059A; Mon, 7 Feb 2022 09:33:27 -0500 (EST) From: Michael Richardson To: Konrad Iwanicki cc: Routing Over Low power and Lossy networks , roll-chairs In-Reply-To: <9c2e872a-7e7c-1e3b-dd6d-d3cd0681f33a@mimuw.edu.pl> References: <30208.1637590535@localhost> <74673648-79a7-9611-5b71-b089a9a3e37e@mimuw.edu.pl> <76746.1637774741@dooku> <9C03FC6E-05D6-45FB-99C5-8BC84193C3AD@cisco.com> <327.1637873630@localhost> <9c2e872a-7e7c-1e3b-dd6d-d3cd0681f33a@mimuw.edu.pl> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] enrollment priority 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, 07 Feb 2022 14:33:41 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Konrad Iwanicki wrote: > Since after reviewing the AODV draft I was already in the "draft mode= ", I > created a pull request on GitHub for roll-enrollment-priority. It > should Oh, thank you. I have been tied up on other issues. > - I extended the option with a sequence counter and a bit for resetti= ng > trickle timer on demand. I also reordered some fields to better -- in= my view > -- fit the current contents of the option. > - Described the processing of the option, notably taking into account= the > sequence counter and the trickle bit. > - Did some minor updates in the compatibility section to reflect that= a node > may learn the min priority value over multiple paths. > Hope that the changes will help push the draft further. Good. I'll merge and post the document this week. =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----- iPMEAQEKAB0WIQSk7ZHEG9TCGBNASfm/sjw/rPYc8wUCYgEttwAKCRC/sjw/rPYc 84hpBf4wOTtvus4niHSpSxo9a9cGCUs+Nx94s3Wb72AtrGrrF0n1ALrkOoKLIFO4 okQ9SacJKefk5H71w0hEs3bb6CnCDXJs9WwyrOHtIdKNJGgyKrJF0CJydo0nISxw O10lBbP6Fo68vdkCuX5+oedD0PZPux3F1iuFIjwdJKmqOwEuRcr/e2TClBVBMGCR SIleCHwTeDNuT2stZ6o3tEeDG4zS9x5rokeELLHYbQRbJ6CaF+DazAvvgZmESTVS XKQvJ+A= =HmMH -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Feb 8 02:13:07 2022 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982693A0A13 for ; Tue, 8 Feb 2022 02:13:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 I2UzoXQHP63u for ; Tue, 8 Feb 2022 02:13:02 -0800 (PST) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 C4A523A0DF4 for ; Tue, 8 Feb 2022 02:13:02 -0800 (PST) Received: by mail-pf1-x435.google.com with SMTP id g8so8156977pfq.9 for ; Tue, 08 Feb 2022 02:13:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LXPHHkUxmGEWOIBfdEs78V396XR+qIuT67XEfc6ibI0=; b=Q6ZHXNynZ9rPqvPZTIxG/Sjw2CLtZh3HjQOWU1sXJ2pWOovuCzhLbve+B5jEid4Avy xZhz2wjM6vrg01gt2jpcWAwCaJz2qLbOzBwD4yCZJu8U6SWH68gv3dvpcBVAK1nS7PGV wvqBrLPRfZ+bQjMkxmWA6FGubp4czQI8XrlYBl0iMvkqqbfAeGl+7T/r36IcfVTZ3L0y 1GiH/xtsEBC+EdxMRLYtQ8YLSSrpiA9rDUJ1NOZyQGUY4mXi6IskwjqVCmQXSYHfSlSc vY48A0mipNDwI/8fuwMSJQ9NK/KJ+W6lqr8L4cSKsv//aj2lUVt89UqKR5tFfNtvXOkD kxlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LXPHHkUxmGEWOIBfdEs78V396XR+qIuT67XEfc6ibI0=; b=KakI9eNqdDTb87DJlz42sxBRO2lYWtx3YIPRiqXa1m7HQGG9GQLvsHeijaWi88wOFg lIXVdgiR3Jc61CCJRt7AFyw6/fICBrXVXmVyG6FVSnyQI5K2GJOcR8glcO6PbtnJEYcz D/If35lPoMH93RRPQBUmg2xivSCJWUyX08Z680DNWN4RUwvI34vgew5oiQl7eQiJLAzm 0xuSewoLCzyEimFlahppKSrwiWQjKrSuyO80rJvc+wYWGeZjNORW0Z+myHaCz3iOYVGH vqmVDHOS++cN25PZxJVFmEJiv+wq2UFywntJPRtiMRn7AHIZImsJ1KHvu7LApJ6AVI2i RbKQ== X-Gm-Message-State: AOAM5331mfDO8T0pAniJCyOrDU8zdKuJKxI5V5V3wemoQtNzlU0rhBiG k038+Fi8rxhHLXbaABU5W2Was+XsOAr6iUBWso0= X-Google-Smtp-Source: ABdhPJxkkM4EdZGqGxWnoO3ysSYgg/Tp0tqm6VUvY0ISn2B0PfuYrXTDh46avz+SxVyjOpypwhpjb0GFKTNjPRWTjm0= X-Received: by 2002:a05:6a00:1682:: with SMTP id k2mr3654043pfc.11.1644315179717; Tue, 08 Feb 2022 02:12:59 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Pascal Thubert Date: Tue, 8 Feb 2022 11:12:49 +0100 Message-ID: To: "roll-wg/draft-ietf-roll-enrollment-priority" Cc: "roll-wg/draft-ietf-roll-enrollment-priority" , ROLL WG Content-Type: multipart/alternative; boundary="0000000000002f991905d77ef649" Archived-At: Subject: Re: [Roll] [roll-wg/draft-ietf-roll-enrollment-priority] Propose changes to reflect major points of our discussion (PR #14) 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, 08 Feb 2022 10:13:05 -0000 --0000000000002f991905d77ef649 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Rahul RPL should not be tweaked to fix ND problems. If you problem is a number of neighbors then we need to look at how you use RFC 8505 and whether something is missing there. What you can already do is trial and error. the 50th child sends a NS(EARO) and the parent rejects with a bad status. Sadly we have " 6LBR Registry Saturated " but not " 6LR Registry Saturated " Also we are missing the capability to indicate in the RA that the NCE is getting saturated. Maybe all that deserves a draft at 6lo? Pascal Le mar. 8 f=C3=A9vr. 2022 =C3=A0 04:46, Rahul Jadhav a =C3=A9crit : > Regarding the scenario -- I don't know if I got it correctly -- but if yo= u > wanted to cut off nodes joining specific 6LRs (e.g., those having 40 > neighbor entries or more), you could have such 6LRs advertise a maximal > value (0x7f) of their Enhanced Beacon Join priorities. You need not chang= e > the global min priority for that. Or did I misunderstood your example? > > Enhanced Beacon Join priorities works only for 6tisch scenarios. RPL has > multiple different link layers it works for. They all face similar issues= . > My deployment scenario was using 802.15.4 link layer without tisch. > > =E2=80=94 > Reply to this email directly, view it on GitHub > , > or unsubscribe > > . > You are receiving this because you are subscribed to this thread.Message > ID: github.com> > --=20 Pascal --0000000000002f991905d77ef649 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Rahul

RPL should not b= e tweaked to fix ND problems. If you problem is a number of neighbors then = we need to look at how you use RFC 8505 and whether something is missing th= ere.
What you can already do is trial and error. the 50th child s= ends a NS(EARO) and the parent rejects with a bad status. Sadly we have
" 
6LBR Registry Saturated                    

"
but not " 
6LR Registry Saturated                    

"
Also we are missing the capability to indicate in the RA t= hat the NCE is getting saturated.
Maybe all that deserves a draft= at 6lo?

Pascal


<= /div>

Le=C2=A0mar. 8 f=C3=A9vr. 2022 =C3=A0=C2=A004:46, Rahul Jadhav <notifications@github.com> a= =C3=A9crit=C2=A0:

Regarding the scenario -- I don't know if I got it corr= ectly -- but if you wanted to cut off nodes joining specific 6LRs (e.g., th= ose having 40 neighbor entries or more), you could have such 6LRs advertise= a maximal value (0x7f) of their Enhanced Beacon Join priorities. You need = not change the global min priority for that. Or did I misunderstood your ex= ample?

Enhanced Beacon Join priorities works only for 6tisch scena= rios. RPL has multiple different link layers it works for. They all face si= milar issues. My deployment scenario was using 802.15.4 link layer without = tisch.

=E2=80=94
Reply to t= his email directly, view = it on GitHub, or unsu= bscribe.
You are receiving this because you are subscribed to this t= hread.3D""Message ID: <roll-wg= /draft-ietf-roll-enrollment-priority/pull/14/c1032184406@github.com>



--
Pascal
--0000000000002f991905d77ef649-- From nobody Thu Feb 10 08:55:57 2022 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7616D3A0E12 for ; Thu, 10 Feb 2022 08:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=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=sandelman.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFoDkuJiASk1 for ; Thu, 10 Feb 2022 08:55:50 -0800 (PST) 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 954623A0121 for ; Thu, 10 Feb 2022 08:55:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 1313438A11 for ; Thu, 10 Feb 2022 12:03:34 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id YoZ5tGkPAoHJ for ; Thu, 10 Feb 2022 12:03:32 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 562F8389B6 for ; Thu, 10 Feb 2022 12:03:32 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1644512612; bh=UfZV8zSJOSSiWTAQx0Q7RwoabWGcUN1OG9TbJJcDkVc=; h=From:To:Subject:In-Reply-To:References:Date:From; b=JLpPaVeHdWAJYd2uoRqlL1cRpgipY0psmfolRc+3PDwFzFuYwsi/O8moXvIOOCk5L mFFhTaOoUujd53X7x4s6gCrUszkB27YEfbb10m4vbbT2plYeiNjCBskYUV2x1gAIWa dbZGihMutgk5aRQSBurOLjB8j3/Eg1527uQ7K7YsuGirH/wvUsWm3eGTC4/3qrsr3m cGaMwKzhjVXfcy8z8Ij00k6Fcmrf1mLPnv1peokww99Y+YrClMvFoiNc8bih6xq1jY OsmUcTMEI8PlukeGMsXTMzKLNrRlMFNf7UIsKA8UqfFP9mr29x2kqEXfhqavUv5N6J +yiPk8rUGHbQg== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C9E2CA0 for ; Thu, 10 Feb 2022 11:55:46 -0500 (EST) 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 Archived-At: Subject: [Roll] Proposed changes to roll-enrollment-priority to reflect major points of our discussion (PR #14) 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, 10 Feb 2022 16:55:56 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I want to alert the list fo the discussion that is occuring at: https://github.com/roll-wg/draft-ietf-roll-enrollment-priority/pull/14 Pascal has wisely decided to reply by email, and CC'ed the list, and I'd prefer that we continued on the list. Rahul wrote in the github: > Also, I am having second thoughts about not allowing the 6LRs to modify > min-priority. My primary use-case for this draft is no more > supported. Following is my use-case: > Consider that we have a homogenous deployment (deployment with all nodes > having similar resources) and let's say those resources are "relatively" > constrained. > For e.g., in my practical deployment I had space for 50 neighbor entries > and 50 routing entries. I had to cut-off nodes joining a 6LR if that 6LR > already has crossed the threshold of 40 entries. > With this draft, I was hoping to set the min-priority at the 6LR to block > others from joining "this 6LR", but other 6LRs could have been > available. With relatively constrained nodes and sufficiently dense > deployment, this condition is always produced. Pascal has asked on the list whether we are trying to fix something in RPL that is really about NCE exhaustion: Pascal Thubert wrote: PT> RPL should not be tweaked to fix ND problems. If you problem is a n= umber of PT> neighbors then we need to look at how you use RFC 8505 and whether PT> something is missing there. PT> What you can already do is trial and error. the 50th child sends a = NS(EARO) PT> and the parent rejects with a bad status. Sadly we have PT> " ... PT> Also we are missing the capability to indicate in the RA that the N= CE is PT> getting saturated. PT> Maybe all that deserves a draft at 6lo? But, if we are doing Storing mode RPL (and maybe in the future of PDAO that will die), then it's not just NCE exhaustion that is the problem. It's a combination of NCE exhaustion and routing entries up the DODAG to the root that the issue. That's why we needed for any 6LR to make itself less desireable for new devices. I wonder if we really have two problems, which calls for two different solutions? =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----- iPMEAQEKAB0WIQSk7ZHEG9TCGBNASfm/sjw/rPYc8wUCYgVDkgAKCRC/sjw/rPYc 88C4Bf4/pFucaOyJxIbsO9i6PhewIzigo2WqBCyj4DroLWesMz4KAnt8zzK4bSZG uc6I+zl+BRjnH+fXKBMf5DGfmsiVrizlFAbg4bc5UZ2iPNRv01Msj+erCu4uUZXc 5ikNujPK92uQjXgXEckfZ3RItvFcgTzFHD8zvPIgKPkeSeT/5tmINNypwJAoB4LL 6csPWu1n05WkdVWhBTiZBPrtq4ua7sm9v/HO73ATcG2vOXURfxYdLFTuaWu9Q41Z 72L6EOo= =S84m -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Feb 10 11:59:19 2022 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA1A3A105F for ; Thu, 10 Feb 2022 11:59:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=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=sandelman.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oe6EvuYqCOTS for ; Thu, 10 Feb 2022 11:59:12 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F3BB3A1083 for ; Thu, 10 Feb 2022 11:59:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id F144538A06 for ; Thu, 10 Feb 2022 15:06:53 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id H3Emop2_yY8Q for ; Thu, 10 Feb 2022 15:06:52 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id C1BE9389FA for ; Thu, 10 Feb 2022 15:06:52 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1644523612; bh=r4SG4XR4QZi8oiv8Je59yZ9cM0UKiKyh6aI5InkvMOY=; h=From:To:Subject:In-Reply-To:References:Date:From; b=Yg7DBdCpVHQM9YC6GZ3Lmetc6gDjayuwkUZDuTDGDUQjuscCz1Kl+q+YO9H7YJNdz vJEn6MxpLtmstEKwDiQHSrg5d9EpJjXLfuqakwMJMP+HvK1m6vi9gK2MrGSibzVfbG z7HJ63eiHMOpO1OdhjOMW/SLgMMHu9Z9BRZT64Yw+xCl4Z5sjO3I5X1T5kntDe1vRl uApXWPJ0jJikDM9SzCVnWkTSbnzgGvUx3VzNzCE6cs/fhMXuEtzgAcrsC4p0//UL5/ ZnrjSqc0gKZLZbpGTQ7CeGkBZllbleUOlr/ZGF2Qbhhz2rHrlc3kkK4jxmu3OEXs07 gKDSnWhUxhWTg== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D76A7A0 for ; Thu, 10 Feb 2022 14:59:06 -0500 (EST) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: <19341.1644512146@localhost> References: <19341.1644512146@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] Proposed changes to roll-enrollment-priority to reflect major points of our discussion (PR #14) 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, 10 Feb 2022 19:59:17 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Michael Richardson wrote: > I want to alert the list fo the discussion that is occuring at: > https://github.com/roll-wg/draft-ietf-roll-enrollment-priority/pull/14 To simplify what text is being discussed, I've accepted all of Konrad's editorial comments into the main github branch. At this point, I wonder if we shouldn't have two options: > 1. propagating base priority settings in the DODAG, > 2. advertising the actual priorities of individual nodes. =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----- iPMEAQEKAB0WIQSk7ZHEG9TCGBNASfm/sjw/rPYc8wUCYgVuigAKCRC/sjw/rPYc 87lTBf42fwzI4RJGKvhkyXSkRFShQ+ZMhtbJOXpoHKrwKAnWdUnGNP5WjNGcwplP ialT24vnW4D40XzimnP9eED/G8yGGHikjXWicFFrJZr7l6EJkFMk6dDp/CC9zi9r FpUO2PLL4KV8Z5fWImSa60yZ1wOi7/a63wJ40iKhju2Iih3gRAbUqK7UiofQl6za drf4Vrdnq04FhqY30d/jpIARBnl3XTzSAEbUsmf1wX5ruRMdD5HsHJs15ES5TwAH Wqz3bkA= =1eNY -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Feb 11 07:19:33 2022 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91DFD3A09A4 for ; Fri, 11 Feb 2022 07:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 SONa9r3AQ7Fp for ; Fri, 11 Feb 2022 07:19:29 -0800 (PST) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 998D23A094E for ; Fri, 11 Feb 2022 07:19:29 -0800 (PST) Received: by mail-wr1-x42b.google.com with SMTP id v12so15880588wrv.2 for ; Fri, 11 Feb 2022 07:19:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:from:mime-version:date:subject:message-id :references:to; bh=wZ+RuqXD9r0VqysROje3YBRqG9Pz05T2ct596xSTfUU=; b=kUsf+c9DZe+9+054MssqFrPVuZ9U8BEzGQ7tMuMhchOAcFPdExex18ji06zuBUGYAN QsMbLbKE0aixwt9momBb1SmIo7Sz13BDQfBzBcvCEA6KVIBmf/QaGTNq3Gbv49VKdLL8 5Mnvjzsa4lpbenYs5wLt7P0goTZHpOeemufoStUOPdwHKT8jhVUMuBuJkEVXdq0PTfco k6bbbFZM1TznihbZqdo/9fROcKi6pXGRM5ddvIhMOHLM0K1GnEpZKUc47yVmly44NF8h tCsFwD0jkAm6zWTOIOfcAHBa59KUtD03B1uINlqor/9FgQdJsyonRFbu0UUodtCh6MZ5 aAeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:content-transfer-encoding:from:mime-version:date :subject:message-id:references:to; bh=wZ+RuqXD9r0VqysROje3YBRqG9Pz05T2ct596xSTfUU=; b=Qpupz7KB+oUEm7Hcth7cBLN0vzECMsZe9+w5iCNobSeQQ0G9fkuBM23Awrc4yAYa7e s40HAa3gtWbgIqEQ0Mq1U5XqS8JhX4F8YM3LNpn9VWQmEqiiAKvI53UOGkl/dD7G4qfc 3a8pacS+yXbGpS4TafBLOKwUel1uI92sgTernvsuaR/fGWZ5ht6dg6DKZ/i57uOW5qji j39gyJuxOzwJ+LicbF6dU536I9hW9oU2colBrfAsgsSnotsKxCrEw1TWkiSy0f84LdAQ Z1PPqLYhAr3C2M6mpr40jdx/xlXU+CQ/zzbSSMLDADwkdvKQidl5CmV9pCIV9kFbAgQ/ KM7A== X-Gm-Message-State: AOAM532FizLM8EchS9XGCK4fpATjK+ZAqTTy/joAXAgrFc98hr10x0wL OtTutv170rBeYkaiNy1l4F8+znl4N5E= X-Google-Smtp-Source: ABdhPJx9Bqo28Dq1q25pqcUgEJYffMCG7BGYBl9yPNVv3qHHk7TQ6KJo8SIZDxKhLQdC4Sn+QsN1Vw== X-Received: by 2002:a5d:61d0:: with SMTP id q16mr1771483wrv.615.1644592764428; Fri, 11 Feb 2022 07:19:24 -0800 (PST) Received: from smtpclient.apple ([217.67.148.21]) by smtp.gmail.com with ESMTPSA id f2sm3610187wri.49.2022.02.11.07.19.23 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Feb 2022 07:19:23 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-155CF975-F1EB-40FA-ADCD-5028402AF666 Content-Transfer-Encoding: 7bit From: Pascal Thubert Mime-Version: 1.0 (1.0) Date: Fri, 11 Feb 2022 16:19:22 +0100 Message-Id: References: <6C895AAD-89D5-4D59-8990-4491FE012B74@gmail.com> To: ROLL WG X-Mailer: iPhone Mail (19D50) Archived-At: Subject: [Roll] NCE vs DAO state saturation [was: roll-wg/draft-ietf-roll-enrollment-priority] Propose changes to reflect major points of our discussion (PR #14)] 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, 11 Feb 2022 15:19:32 -0000 --Apple-Mail-155CF975-F1EB-40FA-ADCD-5028402AF666 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Replying from my phone gets me surprising destinations. Retry to the list: > De: Pascal Thubert > Date: 11 f=C3=A9vrier 2022 =C3=A0 14:20:54 UTC+1 > =C3=80: roll-wg/draft-ietf-roll-enrollment-priority > Cc: roll-wg/draft-ietf-roll-enrollment-priority , Push > Objet: NCE vs DAO state saturation [was: roll-wg/draft-ietf-roll-enrollmen= t-priority] Propose changes to reflect major points of our discussion (PR #1= 4)] >=20 > =EF=BB=BFDear all=20 >=20 > It appears reasonably easy and much needed to adapt rfc 8505 for sleeping n= odes and NCE saturation, both of which should start at 6lo though we must im= pact rfc 9010 as well. >=20 > OTOH the saturation of the DAO state in storing mode is a hard problem. Ba= sically a distributed asynchronous protocol that would overall balance a tre= e and even worse a dodag with possibly non equal loads.=20 >=20 > Worst case is that any router may be the single child of the root. Which m= eans that that node should have as much state as the root itself. If that=E2= =80=99s so then any node should be able to store the whole network. >=20 > We designed storing mode with all that in mind and left it at that. >=20 > If there=E2=80=99s such a hard value for the size of the dodag then this d= raft is already sufficient for discouraging joins beyond the hard value. >=20 > The DAO projection work enables a hybrid mode where the amount of state in= each node is supervised by a controller to optimize the value of the state t= hat is installed, within the capabilities of each node, though the capabilit= ies are for now know by an external mechanism.=20 >=20 > We can probably do more and I=E2=80=99d love to see research on that, but l= et us first complete the steps that we have taken, what do you think ? >=20 > Pascal >=20 >>> Le 10 f=C3=A9vr. 2022 =C3=A0 22:47, Konrad Iwanicki a =C3=A9crit : >>>=20 >> =EF=BB=BF >> @konrad-iwanicki pushed 1 commit. >>=20 >> 8710275 editos and typos from Konrad Iwanicki >> =E2=80=94 >> View it on GitHub or unsubscribe. >> You are receiving this because you are subscribed to thi --Apple-Mail-155CF975-F1EB-40FA-ADCD-5028402AF666 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Replying from my phone gets me surprisi= ng destinations. Retry to the list:

De: Pascal Thubert <pascal.thubert@gmail.com>
= Date: 11 f=C3=A9vrier 2022 =C3=A0 14:20:54 UTC+1
=C3=80: roll-= wg/draft-ietf-roll-enrollment-priority <noreply@github.com>
Cc:<= /b> roll-wg/draft-ietf-roll-enrollment-priority <draft-ietf-roll-enrollme= nt-priority@noreply.github.com>, Push <push@noreply.github.com>
= Objet: NCE vs DAO state saturation [was: roll-wg/draft-ietf-roll-e= nrollment-priority] Propose changes to reflect major points of our discussio= n (PR #14)]

=EF=BB=BFDear all 

It appears reasonably easy a= nd much needed to adapt rfc 8505 for sleeping nodes and NCE saturation, both= of which should start at 6lo though we must impact rfc 9010 as well.
<= div>
OTOH the saturation of the DAO state in storing mode is a= hard problem. Basically a distributed asynchronous protocol that would over= all balance a tree and even worse a dodag with possibly non equal loads.&nbs= p;

Worst case is that any router may be the single c= hild of the root. Which means that that node should have as much state as th= e root itself. If that=E2=80=99s so then any node should be able to store th= e whole network.

 We designed storing mode wit= h all that in mind and left it at that.

If there=E2= =80=99s such a hard value for the size of the dodag then this draft is alrea= dy sufficient for discouraging joins beyond the hard value.

The DAO projection work enables a hybrid mode where the amount of s= tate in each node is supervised by a controller to optimize the value of the= state that is installed, within the capabilities of each node, though the c= apabilities are for now know by an external mechanism. 

<= /div>
We can probably do more and I=E2=80=99d love to see research on th= at, but let us first complete the steps that we have taken, what do you thin= k ?

Pascal

Le 10 f=C3=A9vr. 2022 =C3=A0 22:47, K= onrad Iwanicki <notifications@github.com> a =C3=A9crit :

<= /blockquote>
=EF=BB=BF

@konrad-iw= anicki pushed 1 commit.

  • 8= 710275 editos and typos from Konrad Iwanicki

=E2=80= =94
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed= to thiMessage ID: <roll-wg/draft-ietf-r= oll-enrollment-priority/pull/14/push/9067439638@gi= thub.com>

= --Apple-Mail-155CF975-F1EB-40FA-ADCD-5028402AF666-- From nobody Fri Feb 18 15:42:24 2022 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 656F93A159E; Fri, 18 Feb 2022 15:42:01 -0800 (PST) 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43YnCfYUtjVu; Fri, 18 Feb 2022 15:41:58 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2387F3A15AD; Fri, 18 Feb 2022 15:41:58 -0800 (PST) Received: from client-0015.vpn.uni-bremen.de (client-0015.vpn.uni-bremen.de [134.102.107.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4K0pBT2sgYzDCbq; Sat, 19 Feb 2022 00:41:53 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 666920512.776317-593cfbe88ec439f54eb99e78358c7c0d Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Message-Id: Date: Sat, 19 Feb 2022 00:41:53 +0100 To: 6lo@ietf.org, 6tisch@ietf.org, lp-wan@ietf.org, lwip@ietf.org, roll@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: [Roll] Constrained Node/Network Cluster @ IETF113: DRAFT AGENDA 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, 18 Feb 2022 23:42:13 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF113. Remember that there is still quite some potential for changes. The IoT-relevant conflicts that most meet the eye this time are LPWAN/ACE (probably little actual overlap) and DRIP/ROLL/RATS (probably a little more overlap, but not that much). CFRG and ICNRG are the only RGs not on top of IoT meetings (T2TRG, like e.g. CBOR and JSONPATH, decided to go for interims instead). All times are in UTC. Note that the third and fourth weeks in March (W11 =3D pre-IETF week, W12 =3D IETF week) are Weeks of Confusion, where DST has not yet started in Europe but did already start in North America. https://datatracker.ietf.org/meeting/agenda-utc might be handy. Gr=C3=BC=C3=9Fe, Carsten SATURDAY, March 19, 2022 0830-2000 Hackathon - Grand Klimt Hall 1/2 0930-1000 Hackathon Kickoff - Grand Klimt Hall 1/2 SUNDAY, March 20, 2022 0830-1500 Hackathon - Grand Klimt Hall 1/2 (0900-1700 IETF Registration - Park Ensemble) 1300-1500 Hackathon Results Presentations - Grand Klimt Hall 1/2 (1600-1800 Welcome Reception - Grand Park Hall 1/2/3) MONDAY, March 21, 2022 0900-1100 Morning Session I G Park Hall 3 ART dispatch Dispatch WG - Joint with ARTAREA G Park Hall 1 OPS v6ops IPv6 Operations WG G Klimt Hall 2 RTG raw Reliable and Available Wireless WG G Park Hall 2 SEC dance DANE Authentication for Network Clients = Everywhere WG Park Suite 3 SEC *** teep Trusted Execution Environment = Provisioning WG 1200-1300 Afternoon session I Park Suite 8 ART sedate Serialising Extended Data About Times = and Events WG G Park Hall 2 IRTF pearg Privacy Enhancements and Assessments = Research Group Park Suite 3 SEC acme Automated Certificate Management = Environment WG Park Suite 9 SEC *** cose CBOR Object Signing and Encryption WG G Park Hall 3 TSV tsvwg Transport Area Working Group WG 1330-1530 Afternoon Session II G Klimt Hall 2 SEC *** lake Lightweight Authenticated Key Exchange = WG Park Suite 8 SEC oauth Web Authorization Protocol WG G Park Hall 1 TSV masque Multiplexed Application Substrate over = QUIC Encryption WG TUESDAY, March 22, 2022 0900-1100 Morning Session I Park Suite 9 INT 6man IPv6 Maintenance WG G Park Hall 1 RTG can Computing-Aware Networking BOF Park Suite 3 SEC *** rats Remote ATtestation ProcedureS WG G Park Hall 3 TSV quic QUIC WG 1200-1300 Afternoon session I G Park Hall 2 INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG G Park Hall 1 IRTF qirg Quantum Internet Research Group Park Suite 3 SEC *** ace Authentication and Authorization for = Constrained Environments WG Park Suite 8 SEC emu EAP Method Update WG Park Suite 9 TSV tsvarea Transport Area Open Meeting 1330-1530 Afternoon Session II G Park Hall 1 ART httpapi Building Blocks for HTTP APIs WG Park Suite 8 INT intarea Internet Area Working Group WG G Park Hall 2 IRTF irtfopen IRTF Open Meeting Park Suite 9 RTG detnet Deterministic Networking WG G Park Hall 3 SEC secdispatch Security Dispatch WG WEDNESDAY, March 23, 2022 0900-1100 Morning Session I G Klimt Hall 2 ART moq Media Over QUIC BOF Park Suite 8 INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Park Suite 9 IRTF maprg Measurement and Analysis for Protocols G Park Hall 2 RTG rtgarea Routing Area Open Meeting G Park Hall 3 SEC tls Transport Layer Security WG 1200-1300 Afternoon session I Park Suite 2 ART mediaman Media Type Maintenance WG G Park Hall 1 INT *** drip Drone Remote ID Protocol WG Park Suite 8 RTG *** roll Routing Over Low power and Lossy = networks WG Park Suite 3 SEC mls Messaging Layer Security WG G Park Hall 3 SEC *** rats Remote ATtestation ProcedureS WG G Park Hall 2 TSV taps Transport Services WG 1330-1530 Afternoon Session II Park Suite 3 RTG bier Bit Indexed Explicit Replication WG 1600-1800 IETF Plenary - Grand Park Hall 1-3 THURSDAY, March 24, 2022 0900-1100 Morning Session I G Park Hall 1 INT savnet Source Address Validation in = Intra-domain and Inter-domain Networks BOF G Park Hall 2 IRTF coinrg Computing in the Network Research Group Park Suite 9 OPS *** iotops IOT Operations WG G Park Hall 3 SEC saag Security Area Open Meeting 1200-1300 Afternoon session I G Park Hall 3 INT madinas MAC Address Device Identification for = Network and Application Services WG G Klimt Hall 2 IRTF panrg Path Aware Networking RG Park Suite 8 RTG rift Routing In Fat Trees WG Park Suite 3 SEC privacypass Privacy Pass WG G Park Hall 2 SEC *** suit Software Updates for Internet of Things = WG 1330-1530 Afternoon Session II G Klimt Hall 2 ART webtrans WebTransport WG G Park Hall 3 IRTF cfrg Crypto Forum Park Suite 2 SEC oauth Web Authorization Protocol WG FRIDAY, March 25, 2022 0900-1100 Morning Session I G Klimt Hall 2 ART *** core Constrained RESTful Environments WG G Park Hall 3 INT add Adaptive DNS Discovery WG G Park Hall 2 SEC gnap Grant Negotiation and Authorization = Protocol WG Park Suite 8 SEC openpgp Open Specification for Pretty Good = Privacy WG 1130-1330 Afternoon Session I Park Suite 3 IRTF icnrg Information-Centric Networking G Klimt Hall 2 OPS anima Autonomic Networking Integrated Model = and Approach WG G Park Hall 3 TSV tsvwg Transport Area Working Group WG (### DST STARTS IN EUROPE ON SUNDAY ###) From nobody Sat Feb 19 22:02:45 2022 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A983A0D72 for ; Sat, 19 Feb 2022 22:02:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOCr2bL3GAze for ; Sat, 19 Feb 2022 22:02:37 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BFE03A0D65 for ; Sat, 19 Feb 2022 22:02:37 -0800 (PST) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfedar24.francetelecom.fr (ESMTP service) with ESMTPS id 4K1ZbG591zz5vsm; Sun, 20 Feb 2022 07:02:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1645336954; bh=yZTFUDBR6eQq7b5vy1bM/cdstDWtduHnhIp3JlD8Wp8=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=PmOKu8IoScYiEClnqncW4grVKZphNJgGTIIsvScAEv+wqtP8ZXM0/18+w0Gs4Hvcw BNgMO3+UrL6LhOP3+dLbE1RzgwYiA4lgnrHofUnUYLK5x0a/ashj5cORyati7v4vAS s583Rhmj2Qr9iz5ON7STNktT4j+Yhbq34xs0pCQSuRML143R/GfGWTL5hHRN4mt/s7 wYS/qGYkRMQbC3DPrGDsxa5wYANr1Yw9VyhEhqBufszLS0fTjQtOXOJrRiHyE76Iwo TQ2Sx84ErzMnGJojgJQlvnirp3Hs64d+862TDSPIwxDlJSKvi4tZZQ6Qxg9jUMT2uw jdfqEpYGfW0BA== From: To: 'roll' , "iwanicki@mimuw.edu.pl" Thread-Topic: Call for adoption of " RNFD: Fast border router crash detection in RPL" Thread-Index: AdgLt8z6nGBxALo4Q5GkBp5G6uK8VQaZthqg Date: Sun, 20 Feb 2022 06:02:24 +0000 Message-ID: <5660_1645336954_6211D97A_5660_87_1_3a454988d3d9462f963cae1c03eee59e@orange.com> References: <1dd1e18428384bff9514ff4919cec3d9@orange.com> In-Reply-To: <1dd1e18428384bff9514ff4919cec3d9@orange.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.115.26.50] Content-Type: multipart/alternative; boundary="_000_3a454988d3d9462f963cae1c03eee59eorangecom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] Call for adoption of " RNFD: Fast border router crash detection in RPL" X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2022 06:02:43 -0000 --_000_3a454988d3d9462f963cae1c03eee59eorangecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, Following the call for adoption of draft-iwanicki-roll-rnfd-01 below, the c= hairs have determined that there is enough interest in the topic and willin= gness to discuss/review the technical proposals, therefore the draft is ado= pted as a WG document. @Konrad, can you please republish it as draft-ietf-roll-rnfd-00? I'm looking forward to a fruitful discussion on this topic. Best regards Dominique From: BARTHEL Dominique INNOV/IT-S Sent: 17 January 2022 16:44 To: roll Subject: Call for adoption of " RNFD: Fast border router crash detection in= RPL" Dear ROLL WG, First of all, our best wishes to you and your loved ones for 2022, hoping e= veryone is safe! Let's hope that this year will allow us to meet in person again and revive = the collaborative momentum. At the IETF112 ROLL session, we discussed the "RNFD: Fast border router cra= sh detection in RPL" draft (draft-iwanicki-roll-rnfd-01). There was no objection among the attendees to adopt the draft as a WG docum= ent, an several participants expressed their interest in the problem addres= sed. We understand that the solution to the problem might be improved furth= er with the WG' s participation. This mail starts a 2 week call for adoption for "RNFD: Fast border router c= rash detection in RPL". Please express any objections or your support in that time frame, letting u= s know if you'd be willing to contribute work or review the draft. Best regards Ines & Dominique ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_3a454988d3d9462f963cae1c03eee59eorangecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

Following the call for= adoption of draft-iwanicki-roll-rnfd-01 below, the chairs have determined = that there is enough interest in the topic and willingness to discuss/revie= w the technical proposals, therefore the draft is adopted as a WG document.

@Konrad, can you pleas= e republish it as draft-ietf-roll-rnfd-00?

I’m looking forw= ard to a fruitful discussion on this topic.

Best regards

 

Dominique

 

From: BARTHEL Dominique INNOV/IT-S
Sent: 17 January 2022 16:44
To: roll <roll@ietf.org>
Subject: Call for adoption of " RNFD: Fast border router crash = detection in RPL"

 

Dear ROLL WG,=

 

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

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

 

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

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

 

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

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

 

Best regards<= /p>

 

Ines & Dominique 

______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_3a454988d3d9462f963cae1c03eee59eorangecom_-- From nobody Tue Feb 22 00:47:06 2022 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 209B53A0112 for ; Tue, 22 Feb 2022 00:47:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GM1toF5PnLZz for ; Tue, 22 Feb 2022 00:47:00 -0800 (PST) Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) (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 9EBFA3A0124 for ; Tue, 22 Feb 2022 00:47:00 -0800 (PST) Received: by mail-yb1-xb30.google.com with SMTP id y189so17949400ybe.4 for ; Tue, 22 Feb 2022 00:47:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20210112; h=mime-version:from:date:message-id:subject:to:cc; bh=bo+mXPGCCi+ICv2jV+M6He6Px1RaQ0TDbTnQIDCYnZE=; b=ZS9lKmv/epsKNmv95BZkgdJf3FudOBljszLbROPtfcEvbxlDmeuXhWrWHYQNyNCiiX 2o24lYJ37rrwBgnt5W26D9va/RyL0fzN8vIu6jLD9aE6FPToOPqB68E25pK2BFZYa6oQ tghukx+/7UkYALe+2ALfMIeCTxRHJqY+TsQNqRb/a6IslwDFc1zGGNST59fyDE8MZr1D E0oZ2AWv3ecTfw6CHkCdoogiiM2BKU26GGW0IQl8G6g99uxn1ACZhqfa25XsMU1+rGoU XpdqnkgYgXbv7rc+knl7YIPOHsmd+dEnTqqn08aAk+winoO1u+/3wnMyZpNmQf6x2s9u ipuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=bo+mXPGCCi+ICv2jV+M6He6Px1RaQ0TDbTnQIDCYnZE=; b=YSwDf2wXA/teQdDKgQz0r/goBOFVEDhjDQTAGm37SMFIbgUsI7ZDoXQr5KdlHq9aaT YgF9ivInU6iGrGZT9IoauvIVxPs/i64sKRh97bKXiVFBuZ0w4DrSkjWY//7A/u00inpy Rg3pNnVgRJPHmRqG2mxGp4uN2L5Xg4r9ObwrT9xOxws1X5rf2p/Ddoe0hSUyg+dceo0i zu0bUf7VacmAJ5wX4VK1SGjLYeyE0X9CK2i2KFEnZBw76R0ArA/kzlJW2a7fJ3OZJfGU mM4auWjdOvERzXfjhcShzjm+bOLU/gvyaXRwY30xAMI28416f0wQKXgCjyHmg1boU6vz Facg== X-Gm-Message-State: AOAM532rzari78CSuFfE0YwGdHYkeNS/b7ruz1z5VOwgWM5srAN4Y3fR vj++eXTDZ+5cWvNQJaegAOB0p8aHtblQBqCO+mPO6NZhZBI= X-Google-Smtp-Source: ABdhPJwDMgnBPnx2BZ5nbW3sHbwR9w51CxD6gEjGy4kzg2RnCbDff8RBtg/sC5S+n5y1mAghOdfscKpPnBMh7PxiTJo= X-Received: by 2002:a25:8a0b:0:b0:61e:1688:f684 with SMTP id g11-20020a258a0b000000b0061e1688f684mr22456143ybl.323.1645519619220; Tue, 22 Feb 2022 00:46:59 -0800 (PST) MIME-Version: 1.0 From: Ines Robles Date: Tue, 22 Feb 2022 10:46:23 +0200 Message-ID: To: roll Content-Type: multipart/alternative; boundary="0000000000005fe6cd05d89764ea" Archived-At: Subject: [Roll] IETF 113 - Call for Presentations 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, 22 Feb 2022 08:47:05 -0000 --0000000000005fe6cd05d89764ea Content-Type: text/plain; charset="UTF-8" Dear all, Please let us know by 4th March if you desire to present a topic at the IETF 113. We will have a one hour time-slot. Please indicate in your request: *Topic, *Presenter, *Required time. * If you will be Onsite or Remote Thank you in advance, Ines and Dominique --0000000000005fe6cd05d89764ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

Please let us know by 4th= March if you desire to present a topic at the IETF 113. We will have a one= hour time-slot. Please indicate in your request:=C2=A0
*Topic,= =C2=A0
*Presenter,=C2=A0
*Required time.
* If= you will be Onsite or Remote

Thank you in advance= ,

Ines and Dominique
--0000000000005fe6cd05d89764ea-- From nobody Tue Feb 22 06:56:07 2022 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 968BB3A1201 for ; Tue, 22 Feb 2022 06:56:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.585 X-Spam-Level: X-Spam-Status: No, score=-9.585 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=LlNk4hEV; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=eQbccLpt 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 2MwySMcM7leL for ; Tue, 22 Feb 2022 06:55:59 -0800 (PST) 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 9DD643A11F8 for ; Tue, 22 Feb 2022 06:55:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=76494; q=dns/txt; s=iport; t=1645541759; x=1646751359; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=pDzuGQQLYXRjaNjTMTF6tZU/2u/5iyebqkiOz5kTceA=; b=LlNk4hEVEaCOKs6cdxURgvExF9x3Otvpeijj0Fcr0QvbLRQNzvM1JfLb 9GUW/fnUXLDs67OvNq7n0evFn4VfnaLIRqgf0CuhJF/8M9oxMi8AWAB3/ xXcsb6ZnCvROMTxuoxa7BbvSm4Hl9PGkmozFea7i+g76mElnv+rHpLj7r M=; IronPort-PHdr: =?us-ascii?q?A9a23=3A7L5u1xBN1wUneMQpLOHkUyQVaBdPi9zP1kY95?= =?us-ascii?q?pkmjudIdaKut9TnMVfE7PpgxFnOQc3A6v1ChuaX1sKoWWEJ7Zub9nxXdptKW?= =?us-ascii?q?kwJjMwMlFkmB8iIQUTwMP/taXk8G8JPHF9o9n22Kw5bAsH7MlbTuXa1qzUVH?= =?us-ascii?q?0aXCA=3D=3D?= IronPort-Data: =?us-ascii?q?A9a23=3AaVCmja8Dq9yNH/JUjjk5DrUDnXyTJUtcMsCJ2?= =?us-ascii?q?f8bNWPcYEJGY0x3y2dMUGiEPf+MNzChfN8jOty/9RwB7cPRmIRgQVA6qS5EQ?= =?us-ascii?q?iMRo6IpJzg2wmQcns+qw0aqoHtPt63yUfGdapBkJpPgjk31aOK59yEljfjgq?= =?us-ascii?q?ofUUYYoBAggHWeIdw954f5Ts7ZRbr9A2bBVMSvU0T/Bi5W31Gue5tJBGjl8B?= =?us-ascii?q?5RvB/9YlK+aVDsw5jTSbB3Q1bPUvyF94Jk3fcldI5ZkK7S4ENJWR86bpF241?= =?us-ascii?q?mrd+xFoAdS/n/OiKwsBQ6XZOk6FjX8+t6qK20cZ4HdslP9gcqNHMi+7iB3R9?= =?us-ascii?q?zx14M1RtYG6RB01FqbNg+8aFRJfFkmSOIUZou6dfiTv6JL7I0ruNiGEL+9VJ?= =?us-ascii?q?FsxOYkw++trDydJ7/NwFdynRnhvnMq/xLa9D+JrnMlmdZCtN4IEsXYmxjbcZ?= =?us-ascii?q?cvKiKvrG83ijeK0Fh9q7iyWIcvjWg=3D=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3A4sqTeai/aROvZYmOiuCnUPaWynBQX3d13D?= =?us-ascii?q?Abv31ZSRFFG/FwyPrOoB1L73HJYWgqN03IwerwRpVpQRvnhPlICPoqTMaftW?= =?us-ascii?q?jdySWVxeRZjbcKrAeQYBEXeIRmpN1dmsRFebjN5B1B/LnHCWqDYpcdKbu8gd?= =?us-ascii?q?2VbI7lph8HJ2wHGsIQjTuRSDzrbnGeLzM2Y6bRYaDsnvav0ADQAEj/AP7LYk?= =?us-ascii?q?UtbqzmnZnmhZjmaRkJC1oM8w+Vlw6l77b8Dlyxwgoeeykn+8ZjzUH11yjCoo?= =?us-ascii?q?mzufCyzRHRk0XJ6Y5NpdfnwtxfQOSRl8kuLCn2gArAXvUjZ1TChkF2nAic0i?= =?us-ascii?q?dvrDD+mWZmAy210QKWQoiBm2qp5+An6kd215at8y7BvZKpm72IeNtzMbszuW?= =?us-ascii?q?seSGqD16Ll1+sMjZ6iGAmixsBq5Fr77VbAzsmNWBdwmkWup30+1eYVknxESI?= =?us-ascii?q?MbLKRctIoF4SpuYdo99Q/Bmcsa+dNVfYvhDTdtACWnRmGcunMqzM2nX3w1EB?= =?us-ascii?q?vDSk8eutaN2zwTmHxi1UMXyMEWg39FrfsGOtZ5zvWBNr4tmKBFT8cQY644DO?= =?us-ascii?q?AdQdGvAmiIRR7XKmqdLVnuCalCMXPQrJz85qkz+YiRCdA15Yp3nI6EXEJTtG?= =?us-ascii?q?Y0dU6rAcqS3IdT+hSIW2m5VSSF8LAX23G4gMy0eFPGC1z2dLl1qbrUnxw2OL?= =?us-ascii?q?ytZ8qO?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A9BgAZHvlh/4UNJK1agQmBWoEhATB?= =?us-ascii?q?WB3daNzGIEAOFOYUOgwIDgROPJ4IxiDmBLhSBEQNUCwEBAQ0BATcKBAEBhQU?= =?us-ascii?q?Cg18CJTQJDgECBAEBARIBAQUBAQECAQYEgQkThTsBBCgNhkIBAQEBAgEMBgg?= =?us-ascii?q?NBhMBATcBBAsCAQgRAwEBASEBBgcyFAkIAQEEDgUIGoJjgg5XAw0hAQ6iKQG?= =?us-ascii?q?BOgKKH3iBATKBAYIIAQEGBASBOgKDURiCNwMGgTqDDoJ+VEqHCSccgUlEgRQ?= =?us-ascii?q?BQ1WBEUo3PoJjAgIYgQwcBBweBgcJgxmCLpE1ASVGDmANJREOAiAtAw0eCBU?= =?us-ascii?q?BNwoFCQECEgcPHwsLkhwbjRWBcYwBkmEKg0aJKox0iV0Vg3KMHJd5lkogoRY?= =?us-ascii?q?IDwsLhF8CBAIEBQIOAQEGgWE8gVlwFYMkURkPhWuCX4lHhRSFSnQCNgIGCwE?= =?us-ascii?q?BAwmLBgeCPwEB?= X-IronPort-AV: E=Sophos;i="5.88,333,1635206400"; d="scan'208,217";a="729274816" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Feb 2022 14:55:57 +0000 Received: from mail.cisco.com (xbe-rcd-004.cisco.com [173.37.102.19]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 21MEtvOD003811 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for ; Tue, 22 Feb 2022 14:55:57 GMT Received: from xfe-rtp-002.cisco.com (64.101.210.232) by xbe-rcd-004.cisco.com (173.37.102.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Tue, 22 Feb 2022 08:55:57 -0600 Received: from xfe-rtp-003.cisco.com (64.101.210.233) by xfe-rtp-002.cisco.com (64.101.210.232) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Tue, 22 Feb 2022 09:55:56 -0500 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-003.cisco.com (64.101.210.233) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Tue, 22 Feb 2022 09:55:56 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Py/d0giSQtQfynTHMR2sKlOJjTAoS2Mrc9I9QTxqK3ckNq4GmHAHgxX7lkh8r05vQv0G7RYnCTPiSfBZgcJWONXyA+crRIARHGl+UhUmlDnUfNZ5w+c0/x9zeLEmXAh4OxHV7UJdaxxxd/mmTGZgMl4AJnWrMiMAXEJnVSi+lNpJ8btyybdpZ320L3R6jOFevSgtKqj1BA/HNgzYme8FRwH5HfIiBMs93iz+eSvEzMer9/APpTPrx6er15LNVRRT4rTEfbLlxbhlwu+m041rHuHHmQyBUHN3dVCmCgBnnjYpVrTxMY/pZbip4iys649WpaASWR5y5zAQ3KBYFgUHPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=EfSs8WI/i6CRdvNO3YwdL25BuX+f4Gz/OrpV5fwjdGQ=; b=le03TweDLxRlkhSVVbhdWwuOwvldXZbjNbXmDmTEYVJ1EXz4Ek5YAMeT/EJ0HMPl/mH2LFmS/K3aHWx9V76mGfqkDF5DYSH15+oyf/2JlRTdWuMmM5M8x/F3p1f7ZXLzPmEctRp8XT528+YonAisPpphy7igSIbjCow4t0ey3sT6yhZtbFjUS/+lFGbZca3vL9XZdN+mBzEnYL/GVW/rDtNL8OmH7CQPSr3R6gK38e7dP+yEV7HADZrx/Cci68sN3+cRc/7LCN+y7kHRpbL6YYJYubpHXM65jgm1HmU/HGTe+itgMjGkPy/J78fJaCTvRmMiIvo4/WI69lZUzVfXqg== 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=EfSs8WI/i6CRdvNO3YwdL25BuX+f4Gz/OrpV5fwjdGQ=; b=eQbccLptEMdvDMi89SLfMvy7SDqoGlEnD6Q0OJDg4ibk/Zat/LjVpUAJYksAaBgN26I5l8bZbO1xfJoNPktTFiZfjID80Qa9+5lfTjRC5ERzWONHaVA7bbu2Gql6TYWQiEFV+F51HmFmAbv2kuUjoFJlIqFxTt/GBusZfPCYzK0= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by BN6PR11MB4178.namprd11.prod.outlook.com (2603:10b6:405:84::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5017.22; Tue, 22 Feb 2022 14:55:53 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::f515:598d:4160:b4b8]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::f515:598d:4160:b4b8%4]) with mapi id 15.20.5017.022; Tue, 22 Feb 2022 14:55:53 +0000 From: "Pascal Thubert (pthubert)" To: "ROLL WG (roll@ietf.org)" Thread-Topic: Multiple targets in PDR (Was: [Roll] review of dao-projection -22) Thread-Index: AdgJJyV6ErEZ4KG8SV+3gpNv1SjopAe1EorQ Date: Tue, 22 Feb 2022 14:55:47 +0000 Deferred-Delivery: Tue, 22 Feb 2022 14:54:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dbe1c0ad-803b-4b60-1174-08d9f6136c5e x-ms-traffictypediagnostic: BN6PR11MB4178:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 4Yw9kvXIIKnGv9E6vwPvDy/f8Pk1aCTXJSuYsm5Fqo/IP+fiqeOue1OU12JV0TnYxaUbHTStUSAvoIgGnw+wKHobOGeBNLyEafkvczNhO+g7zc3TTd3TwVtq9lIH2+Td/z6Ku7pswsNDPh1rluqv7xFKv7Hn/MsN0IPOzgUYRoWTj7w4E8FrqIuM7+YSGBE/YWse5b3fmTWJCRfkgK4F+oy+kTsPSliHWMM5BfHcsAJKrvJ9Kbl4Sp56VMbOv7EKNiJzh1a00OBjGqat4rqnH9M5mWqkBUrqG6lNH2Biq5U1QjZAWa4ZfR6aF9Ino7saQk87RwON0IXUja/a3iY2hNj4CoU95GFGufqckOkT65kWlLirBY0921m8tzIC99e3e06g1lQUBbg1HP4AweS8j5ZpVdEM5cXCfH6s9icTbl475OtwP0yW3H77toVvmAMs5LJ8CdT9LTNzwGaaJ6z0cuEYy4FTnkiekc7taZp08BByZ3jtM6GKwtkOIEuWe9mdJ9Qt185uOzD6Y5O4HoiF7eH1oEQRHbC4U9ylf989txFI2XWYaNwpLWW9Vn+DBlANnMwqOyky/TNNEN0BFPKYxTN81TKC+QDZTFkuR9ZmLUS4Lusa4SS5C2lJ/WDYzWuy6kmOkdlmULfD2ioljagRKITaWgjNo1Fk6CMw8jgxT5bZRQqsG+G+JHAMPLCHQg0QX2ryoWCcaH8vsP0Y8RQfDUaNQkRstQBWHEne4qcDqfJ/hOkGJuUqlylpGZ5peTGFqPTC2nzMyJZL/s41IWtGikrQ9MPDtuf8yc7MsbnIuYA4PD961wbMKFNo3pxlTvyhRkQYjx2yRU+snLf6gOP5zQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB4881.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(38100700002)(2906002)(122000001)(38070700005)(5660300002)(52536014)(8936002)(30864003)(66574015)(83380400001)(7696005)(6506007)(6666004)(66446008)(4326008)(66556008)(66946007)(508600001)(66476007)(8676002)(64756008)(76116006)(966005)(107886003)(6916009)(26005)(71200400001)(33656002)(186003)(166002)(9686003)(55016003)(316002)(86362001)(53546011)(579004)(559001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?6sFlpw0ckedZa5eYO46QkR6no42gUiw/ppb+fBEcAS25bhTCU/dE5GkJLv?= =?iso-8859-1?Q?5OsjWJew8/8aPz039eISyaGqrnNSuMOjTfXzpaBuozew9kPlot0Nvf2XcW?= =?iso-8859-1?Q?apwKiq4cQr0svEHk2iZm1riqjmdCTyUYKwPpkbOwBjzfE1UGhK0XjHBJS0?= =?iso-8859-1?Q?DjFizD2KzY1K4M0VO5fjNciYRHdN9N9O1odIumyv4vgitk0rwK9dHmc89Z?= =?iso-8859-1?Q?AHL4fbdbAcAPQw+ICQWjC91JIA1klznXR1rPYl9xNuqun/mT7K+sAO4kSc?= =?iso-8859-1?Q?EG9Pwud2VAQPhnkmcXVxkVKAdRMLOq7vqXDH0/DeNTuTONlsnVBPXApu9q?= =?iso-8859-1?Q?ZMbGXDgkLL4jlQeJ+bKokbQ4CGi/K8imKNIjt8iRc14GCOeq7hzwiw33sC?= =?iso-8859-1?Q?ATds2CvsFL6qAN5ZKz+H5GJavRnoHg7FSGMNgVaxXHebLyrtD0rg1AFG+b?= =?iso-8859-1?Q?uK41Os8MyiM9AQf2kF+WAdPn4KkAWCc+QdeiNPuY1T0oUT4dSTZQVSAeG/?= =?iso-8859-1?Q?5fZQWwgRNHVMLpQ3U957xZgvs4hftSorBa0wTLq+KA/+tyeTWi4yxIOVpW?= =?iso-8859-1?Q?gEjkSbLtcRim0BF42mKMmghsfAZYHvuvvbDEjKfdAuxm+dguHK5Q4iEG56?= =?iso-8859-1?Q?fINjiC4RBh+G9639zO7GBGrFtmyx3ncIkjxpGLgsqFEgySgR9FlfMPLYuH?= =?iso-8859-1?Q?CwL5/lvxpLmEDXQex2x2xn5ABAsx1FCDEkZtYfiavss8ODK7r+mXGvLO5P?= =?iso-8859-1?Q?dSpenQmON8cs9FkPrjd+Y8LCDfcHJhlQCO6Q1GT39AYURhaHLpDAjmzNeC?= =?iso-8859-1?Q?Bp3ZmC1ih2PLWdlE+dsLpPoVZa4u0zJNYBSYEfvMwb3NTlv4bzXPCCMW9x?= =?iso-8859-1?Q?848mxsL+hYqiBsdVZ1LiV5cffVnB4c4Dc/YDSVbSQgcB9NJGHE1F7IT/Jm?= =?iso-8859-1?Q?eqaeueSPsyjakVYUVGBRRm/0BSJ6Gqh1o64Ixwy9MlDrYZECqCZR4Yh6y9?= =?iso-8859-1?Q?3+nGjRsS5r+XEk1oRIViaa+o99Ws9AtRY0l0chBhpdV3F1LntHwahhozlj?= =?iso-8859-1?Q?qowFxwG04TnQxK6WOfrNuw6tY+uQhJG7W9+QLShc2jThbc9hljxX6LEo+f?= =?iso-8859-1?Q?v3oPwg6/o39KolojgaFT9KFBUUhwrnWdOkqcwgwDKGkDXQ3aHRf68Y2yHC?= =?iso-8859-1?Q?jEfxtNW2Y34pyXk9V7WCYRZ+VtlYQKuwHPLiL1WpqdJfAYvfocFwJtT1rC?= =?iso-8859-1?Q?s0ya5fXGZw0WqesRHlHkMyFDhJODJ0JvyNXAuO1c0eeCDeFOz3LKNK5gHV?= =?iso-8859-1?Q?X+fqOPjJVbI3vho7PtWLaREnhrxzRVD6gWk91CPFSicvWgHBN0KqZJzVVG?= =?iso-8859-1?Q?spol+u890x5ezCi8qEsVFR1JNHXc/AYC3/wtEPglfCQ8akmN7osy+Bbzax?= =?iso-8859-1?Q?sjhEP44VfrIBuNmOrSzvHUf0n5n9f67Ol24LNp4i/ZInWmoctWZ1xmAVuN?= =?iso-8859-1?Q?el31ivRO9jbvpljWco6cufhmEiE8ExHWIKfbsvPo6+onQ5DvPxamf/uLfj?= =?iso-8859-1?Q?Yhx19dq4K3NQ9encfkpkXzsL8Nlu6FJANzbHvQLJh33EzGwGBEmuIYoDzy?= =?iso-8859-1?Q?cmiaLYjYleDxV2gResDR8nRdyoFfG0ASctynW4i7ybx/NttfC5ZjZa7qOb?= =?iso-8859-1?Q?6t1kfEIIDLpT82XIhBE=3D?= Content-Type: multipart/alternative; boundary="_000_CO1PR11MB4881C82A091F8C6AE4B39AAFD83B9CO1PR11MB4881namp_" 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: dbe1c0ad-803b-4b60-1174-08d9f6136c5e X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2022 14:55:53.0520 (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: TPDxAONFGgINV6D0nyj5DuKCJeHrUlYvsAWvGKuDP1CGITHQwKzkp4+IBzk83HLV/fd90FBC0vEULsWBJBPBNg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB4178 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.19, xbe-rcd-004.cisco.com X-Outbound-Node: alln-core-11.cisco.com Archived-At: Subject: Re: [Roll] Multiple targets in PDR (Was: review of dao-projection -22) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2022 14:56:06 -0000 --_000_CO1PR11MB4881C82A091F8C6AE4B39AAFD83B9CO1PR11MB4881namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all: To address Li's comment, is we allow multiple targets then there can be a s= et of possible Track each leading to a subset of the listed Targets, and po= ssibly not all or all with a very bad quality / PDR. Suggestion is to accept more than one target, but focus the response on the= first target and the "best" subset of the others the root can find. IMHO, going into the details of the path quality or which subset is best ta= kes us deeper than we can go in this draft. So I suggest: OLD One and only one RPL Target Option MUST be present in the message New At least one RPL Target Option MUST be present in the message. If more t= han one RPL Target Option is present, the Root will provide a Track that rea= ches the first listed Target and a subset of the other Target; details of the subset selection are out of scope. Works? Pascal From: Pascal Thubert (pthubert) Sent: vendredi 14 janvier 2022 10:20 To: ROLL WG (roll@ietf.org) Cc: Li Zhao (liz3) Subject: Multiple targets in PDR (Was: [Roll] review of dao-projection -22) Dear all: we had this thread as part of Li's review: About : "5.1 One and only one RPL Target Option MUST be present in the mess= age." [Li] -> Is it possible to remove the limitation? It's not flexible If PDR = can only carry one RTO. For instance in figure 7, if node I requests P-Route to B&H tog= ether, Root can only push one Track I->A->B->H. Otherwise, Root may push tw= o Tracks I->A->B and I->F->G->H. If Root cannot computer one Track to multiple RTO, it can resp= onse with a special PDR-ACK Status. [PT] This was done in the interest to simplicity, and yes we can rediscuss= that. We'd need to make decisions on partially successful use cases e.g.,: * What if there's a path to only a subset? Should the root form more th= an one track? * Or deny with your special status but then what can the source do afte= r that? Try all combinations? * What is the best path to one target cannot reach all targets but a lo= wer quality path can? Should we use that one? * Maybe there could be one main target and additional desirable targets= ? In that case the Root could form the track and indicate which of the opti= onal targets are effectively reachable via the track to the main target. [Li] Maybe it depends on implement of PCE? I'd like to keep the flexibilit= y because there is a user case for street lighting. Some controllers(Ingres= s nodes) need to light the street lighting linearly with low-latency. [PT] sure, at the expense of complexity in signaling and processing in the = nodes. We need to be specific on the scenarios and status codes. The PDR f= orms a single Track since the TrackID is provided. I believe it makes sense to ask for more targets since the root can install= a Track for more than one target. Still, signaling is involved and we nee= d a story for all those questions: * What if there's a path to only a subset? Should the root form more th= an one track? * Or deny with your special status but then what can the source do afte= r that? Try all combinations? * What is the best path to one target cannot reach all targets but a lo= wer quality path can? Should we use that one? * Maybe there could be one main target and additional desirable targets= ? In that case the Root could form the track and indicate which of the opti= onal targets are effectively reachable via the track to the main target. Comments welcome! Pascal From: Roll > On Behalf = Of Li Zhao (liz3) Sent: vendredi 14 janvier 2022 2:51 To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] review of dao-projection -22 Hello Pascal, Please find my comments inline. Best regards, Li From: Roll > on behalf = of Pascal Thubert (pthubert) > Date: Friday, January 14, 2022 at 01:31 To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] review of dao-projection -22 Hello Li A great many thanks for your excellent review! Such are much needed at this= time. > [Li] -> Should it be ? > P-DAO 1 signals C=3D=3D>D=3D=3D>E-to-F,G > P-DAO 2 signals A=3D=3D>B=3D=3D>C-to-E,F,G [PT] correct, great catch! > [Li] -> What's the difference between negative status PDR-ACK and No-Path= P-DAO in section 6.5? And when to use asynchronous PDR-ACK? > In storing mode, root should use No-Path P-DAO to tear down T= rack from egress node. Is PDR-ACK still needed? > In non-storing mode, No-Path P-DAO to ingress node is also en= ough. > But the PDR-ACK Status field makes sense. Is it possible to a= dd this field in No-Path P-DAO? [PT] The no path DAO flow along the reverse path and cleans it; so the end= result would be that the Track is terminated as you figured. So yes, it co= uld be possible to add a status to the no-path DAO but remember that it is = a normal DAO not a completion (IOW not an ack). How could we justify a stat= us in all DAOs? I'm unclear why the async PDR ack is an issue. If the PDR c= an not be served, the track ingress already needs to support a PDR ack that= "terminates" a Track. To clarify that sentence we can say: " The main Root MAY indicate to the Track Ingress that the Track was termi= nated before its time and to do so, it MUST uses an asynchronous PDR-ACK with = an negative status. " Should that be more than a MAY? >>>> [Li] Yes. It's more clear. So PDR-ACK is for original PDR. And for mai= ntain or tear down case, Root should use No-Path P-DAO to terminate P-Route= . Correct? > [Li] -> Is it possible to remove the limitation? It's not flexible If PD= R can only carry one RTO. > For instance in figure 7, if node I requests P-Route to B&H t= ogether, Root can only push one Track I->A->B->H. Otherwise, Root may push = two Tracks I->A->B and I->F->G->H. > If Root cannot computer one Track to multiple RTO, it can res= ponse with a special PDR-ACK Status. [PT] This was done in the interest to simplicity, and yes we can rediscuss= that. We'd need to make decisions on partially successful use cases e.g.,: * What if there's a path to only a subset? Should the root form more th= an one track? * Or deny with your special status but then what can the source do afte= r that? Try all combinations? * What is the best path to one target cannot reach all targets but a lo= wer quality path can? Should we use that one? * Maybe there could be one main target and additional desirable targets= ? In that case the Root could form the track and indicate which of the opti= onal targets are effectively reachable via the track to the main target. >>>> [Li] Maybe it depends on implement of PCE? I'd like to keep the flexi= bility because there is a user case for street lighting. Some controllers(I= ngress nodes) need to light the street lighting linearly with low-latency. > [Li] -> Is it possible to add a flag to indicate the symmetry? Otherwise,= if A chooses B as sibling, but B doesn't choose A as sibling, Root may tre= at SIO from A as symmetry incorrectly when only receiving SIO from A. [PT] we used to have that (B Flag for bidir) but we removed it for simplifi= cation. I'm OK to add it back, but we still lake a good description of how = the node will know that the link is roughly symmetrical. >>>> [Li] Some physical layer measurements such as RSSI/LQI have forward an= d reverse direction. Can it indicate symmetrical? In layer 3, receiving DIO/NS messages from each other ind= icate symmetrical? > [Li] -> Confuse with this claim. Is it a MUST NOT if root wants to send n= otification to the requesting node when those changes happen. [PT] There's no protocol element to "send notification to the requesting no= de when those changes happen". So it's hard to say that the root MUST NOT d= o something that it cannot do. Reworded to " Note that there is no protocol element to notify to the requesting Tr= ack Ingress when changes happen deeper down the Track, so they are transp= arent to the Track Ingress. If the main Root cannot maintain an expected se= rvice level, then it needs to tear down the Track completely. " > [Li] -> Can you add some description for the collision case? E.g., node t= rusts itself than Root. [PT] I reworded to " = In a particular deployment where PDR are not used, a portion of the namespace can be administrati= vely delegated to the main Root, meaning that the main Root is authoritativ= e for assigning the TrackIDs for the Tracks it creates.. " [Li] -> Is there any difference between P-DAO-ACK and normal DAO-ACK? E.g.= any flags? Normally, root won't receive any DAO-ACK from nodes. Is it possible to add flag to distinguish P-DAO-ACK from DAO-ACK as P-DAO f= rom DAO. [PT] Done; I added a section for the P-DAO-ACK > [Li] -> Profile 0 is the Legacy support of [RPL] Non-Storing Mode. I= 'm confuse about "this enables to use Storing Mode to reduce the size of th= e Source Route Header in the most common LLN deployments." [PT] I really meant Profile 1 enables... Changing that. I guess that's it ! I submitted -23 with this, please have a look at https://www.ietf.org/rfcdi= ff?url2=3Ddraft-ietf-roll-dao-projection-23 Again many thanks! Pascal From: Roll > On Behalf = Of Li Zhao (liz3) Sent: mercredi 12 janvier 2022 10:51 To: Routing Over Low power and Lossy networks > Subject: [Roll] review of dao-projection -22 Hello Authors, Thanks for your great effort. The PDAO draft looks more clear and detailed.= Following is some concern: 3.5.2 Using Non-Storing Mode joining Tracks P-DAO 1 signals C=3D=3D>D=3D=3D>E-to-F,G P-DAO 2 signals A=3D=3D>B=3D=3D>C-to-C,F,G [Li] -> Should it be ? P-DAO 1 signals C=3D=3D>D=3D=3D>E-to-F,G P-DAO 2 signals A=3D=3D>B=3D=3D>C-to-E,F,G Otherwise RIBs in A cannot include destination to E. 4.1. Extending RFC 6550 To ensure that the PDR and P-DAO messages can flow at most times, it is REC= OMMENDED that the nodes involved in a Track =3D=3D=3Dmantain=3D=3D=3D multi= ple parents in the Main DODAG, advertise them all to the Root, and use them= in turn to retry similar packets. It is also RECOMMENDED that the Root use= s diverse source route paths to retry similar messages =3D=3D=3Dot=3D=3D=3D= the nodes in the Track.=B6 [Li] -> Typo for "mantain" and "ot"? 4.1.6. This specification defines a new flag "Projected Routes Support" (D). The DODAG Configuration option is copied unmodified from parents to childre= n. =3D=3D=3D=3Dxref target=3D'RFC6550'/>=3D=3D=3D=3D states that: [Li] -> Typo for "xref target=3D'RFC6550'/>". Why is flag named as "D"? Th= ere is no D in "Projected Routes Support"... 5.1 The Root may use an asynchronous PDR-ACK with an negative status to ind= icate that the Track was terminated before its time. [Li] -> What's the difference between negative status PDR-ACK and No-Path P= -DAO in section 6.5? And when to use asynchronous PDR-ACK? In storing mode, root should use No-Path P-DAO to tear down Track from egre= ss node. Is PDR-ACK still needed? In non-storing mode, No-Path P-DAO to ingress node is also enough. But the PDR-ACK Status field makes sense. Is it possible to add this field = in No-Path P-DAO? 5.1 One and only one RPL Target Option MUST be present in the message. [Li] -> Is it possible to remove the limitation? It's not flexible If PDR = can only carry one RTO. For instance in figure 7, if node I requests P-Route to B&H together, Root = can only push one Track I->A->B->H. Otherwise, Root may push two Tracks I->= A->B and I->F->G->H. If Root cannot computer one Track to multiple RTO, it can response with a s= pecial PDR-ACK Status. 5.4 only the router with the lowest Interface ID in its registered address = needs report the SIO, and the Root will assume symmetry. [Li] -> Is it possible to add a flag to indicate the symmetry? Otherwise, i= f A chooses B as sibling, but B doesn't choose A as sibling, Root may treat= SIO from A as symmetry incorrectly when only receiving SIO from A. 6.2 There is no notification to the requesting node when those changes hap= pen. [Li] -> Confuse with this claim. Is it a MUST NOT if root wants to send not= ification to the requesting node when those changes happen. 6.3 In a particular deployment where PDR are not used, the namespace can be= delegated to the main Root, which can assign the TrackIDs for the Tracks i= t creates without collision. [Li] -> Can you add some description for the collision case? E.g., node tru= sts itself than Root. 6.4.1 In both cases the Track Ingress is the owner of the Track, and it gen= erates the P-DAO-ACK when the installation is successful [Li] -> Is there any difference between P-DAO-ACK and normal DAO-ACK? E.g.= any flags? Normally, root won't receive any DAO-ACK from nodes. Is it possible to add flag to distinguish P-DAO-ACK from DAO-ACK as P-DAO f= rom DAO. 8 Profiles 0 and 1 are REQUIRED by all implementations that may be used in = LLNs; this enables to use Storing Mode to reduce the size of the Source Rou= te Header in the most common LLN deployments. [Li] -> Profile 0 is the Legacy support of [RPL] Non-Storing Mode. I'm= confuse about "this enables to use Storing Mode to reduce the size of the = Source Route Header in the most common LLN deployments." Best regards, Li --_000_CO1PR11MB4881C82A091F8C6AE4B39AAFD83B9CO1PR11MB4881namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear all:

 

To address Li’s comment, is we allow multiple targets = then there can be a set of possible Track each leading to a subset of the l= isted Targets, and possibly not all or all with a very bad quality / PDR.

Suggestion is to accept more than one target, but focus the = response on the first target and the “best” subset of the other= s the root can find.

IMHO, going into the details of the path quality or which su= bset is best takes us deeper than we can go in this draft.

 

So I suggest:

 

OLD

 

   On= e and only one RPL Target Option MUST be present in the message<= /span>

 

New

 

   At leas= t one RPL Target Option MUST be present in the message. If more than

   one RPL= Target Option is present, the Root will provide a Track that reaches<= /o:p>

   the fir= st listed Target and a subset of the other Target; details of the

   subset = selection are out of scope.

 

Works?

 

Pascal

 

From:= Pascal Thubert (pthubert)
Sent: vendredi 14 janvier 20= 22 10:20
To: ROLL WG (roll@ietf.org) = <roll@ietf.org>
Cc: Li Zhao (liz3) <liz3@= cisco.com>
Subject: Multiple targets in= PDR (Was: [Roll] review of dao-projection -22)

 

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

 

About : “5.1 One and only one RPL Target Option MUST b= e present in the message.”

 

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

          =   For instance in figure 7, if node I requests P-Route to B&H toge= ther, Root can only push one Track I->A->B->H. Otherwise, Root may= push two Tracks I->A->B and I->F->G->H.

          =    If Root cannot computer one Track to multiple RTO, it can resp= onse with a special PDR-ACK Status.

 

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

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

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

 

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

 

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

 

 

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

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

 

Comments welcome!

 

Pascal

 

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

 

Hello Pascal,

 

Please find my comments inline.

 

Best regards,

Li

 

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

Hello Li

 

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

 

> [Li] ->  Should it be ?

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

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

[PT] correct, great catch!

 

 

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

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

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

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

 

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

 

To clarify that sentence we can say:

“

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

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

   negative status.

“

Should that be more than a MAY?

 

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

 

 

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

>          &= nbsp;  For instance in figure 7, if node I requests P-Route to B&H= together, Root can only push one Track I->A->B->H. Otherwise, Roo= t may push two Tracks I->A->B and I->F->G->H.

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

 

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

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

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

 

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

 

 

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

 

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

 

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

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

 

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

 

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

 

“

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

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

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

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

“

 

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

 

[PT] I reworded to

“

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

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

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

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

“

 

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

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

 

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

 

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

 

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

 

I guess that’s it !

 

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

 

Again many thanks!

 

Pascal

 

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

 

Hello Authors,

 

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

 

3.5.2 Using Non-Storing Mode joining Tracks

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

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

 

   [Li] ->  Should it be ?

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

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

 

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

 

4.1. Extending RFC 6550

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

   

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

 

4.1.6.

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

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

 

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

 

 

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

 

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

In storing mode, root should = use No-Path P-DAO to tear down Track from egress node. Is PDR-ACK still neede= d?

In non-storing mode, No-Path = P-DAO to ingress node is also enough.

But the PDR-ACK Status field makes sense. Is it possible to add this field in No-Pat= h P-DAO?

 

 

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

 

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

For instance in figure 7, if = node I requests P-Route to B&H together, Root can only push one Track I= ->A->B->H. Otherwise, Root may push two Tracks I->A->B and I->F->G->H.

If Root cannot computer one T= rack to multiple RTO, it can response with a special PDR-ACK Status.

 

 

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

 

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

 

 

6.2  There is no notification to the requesting node wh= en those changes happen.

 

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

 

 

 

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

 

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

 

 

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

 

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

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

 

 

8 Profiles 0 and 1 are REQUIRED by all implementations that = may be used in LLNs; this enables to use Storing Mode to reduce the size of= the Source Route Header in the most common LLN deployments.

 

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

 

 

 

Best regards,

Li

 

 

 

 

 

 

 

 

 

 

--_000_CO1PR11MB4881C82A091F8C6AE4B39AAFD83B9CO1PR11MB4881namp_-- From nobody Thu Feb 24 00:39:08 2022 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 589E93A0BD3 for ; Thu, 24 Feb 2022 00:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.585 X-Spam-Level: X-Spam-Status: No, score=-9.585 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=IthIpzTH; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Bu7J6gV8 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 2DqaQdxFHWFq for ; Thu, 24 Feb 2022 00:38:58 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17C6E3A0BC7 for ; Thu, 24 Feb 2022 00:38:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=76969; q=dns/txt; s=iport; t=1645691938; x=1646901538; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=IdWUKDod4FnKfHBsAanT2D356Loe5FEf7jlRYJw/klo=; b=IthIpzTHGShHMM3hHtKpU0DHLhpxs2JaNK6HKqPOnhZsBC/QlkLhlEfp fIGEcKza7LG8IouiZYSeN9o/ZrTF42MCV2hofFdaAwH9aFsMkln1S2ymU txQgHo5vpkG2Yz2vQGRpIVlRfqUjhuXaZcODezrVlcWrPZeRG9CEWMxnx k=; IronPort-PHdr: =?us-ascii?q?A9a23=3A6nJxGxNQMBx3pXT2DE0l6ncDWUAX0o4cdiYZ6?= =?us-ascii?q?Zsi3rRJdKnrv5HvJ1fW6vgliljVFZ7a5PRJh6uz0ejgVGUM7IzHvCUEd5pBB?= =?us-ascii?q?BMAgN8dygonBsPNAEbnLfnsOio9GskKVFJs83yhd0ZPH8OrbFzJqXr05jkXS?= =?us-ascii?q?X3C?= IronPort-Data: =?us-ascii?q?A9a23=3Af2yzXqyitXM/eKQ//456t+cgxCrEfRIJ4+Muj?= =?us-ascii?q?C+fZmUNrF6WrkUGxmRLDG7VP/mPYTfze9l0Pt62905QvsfcnNVkGgE4pFhgH?= =?us-ascii?q?ilAwSbn6Xt1DatR0xt/paQvdWo/hyklQoSGfJBcokP0/E/3aOC79SAkjMlke?= =?us-ascii?q?5KlYAL6EnEpLeNbYH9JZSJLw4bVs6Yw6TSLK1rlVeDa+6UzDGSYNwtcaQr43?= =?us-ascii?q?U4sRCRH55wesBtA1rA3iGsiUFX2zxH5B7pHTU29wueRf2VaIgK6b76rILCR5?= =?us-ascii?q?GjV+VImDcmo1+q9eUwRSbmUNg+L4pZUc/H92V4Z+WpjieBiaad0hUR/011lm?= =?us-ascii?q?/h1yccWnZexUgwueKbLnYzxVjEJQnAjZvUbpOSvzX+X9Jb7I1f9W2Hrx/FGD?= =?us-ascii?q?UwqM8sf4OkfPI3k3ZT0MxgXZRyFwumx2r/+Fq9nh98oK4/gO4Z3h52p9hmBZ?= =?us-ascii?q?d5OfHwJa/yiCQdk4QoN?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AIbBLTq0r3x4rRTAAMA0k6gqjBQ1yeYIsim?= =?us-ascii?q?QD101hICG9Lfb4qyn+ppomPEHP5wr5AEtQ5exoS5PwPk80lKQFrbX5WI3DYO?= =?us-ascii?q?CIghrREGgP1/qG/9SkIVyCygc/79YuT0EdMqyKMbESt6+Ti2PUf6dCsbu6Ge?= =?us-ascii?q?KT9J3jJhxWPGZXgtRbnn5E43GgYytLrWd9dP4EPavZwvACiyureHwRYMj+LG?= =?us-ascii?q?ICRfL/q9rCk4+jSQIaBjY8gTP+ww+A2frfKVy1zx0eWzRAzfMJ6m7eiTH04a?= =?us-ascii?q?2lrrWS1gLc7WnO9J5b8eGRi+erRfb8yvT9GA+cyDpAV74RHoFqewpF5N1H3W?= =?us-ascii?q?xa0+UkZS1QePibpUmhOF1d6iGdpTUImAxemkMKj2Xo2EcKZafCNWkH4w0rv/?= =?us-ascii?q?MATvKR0TtRgPhslK1MxG6XrJxREFfJmzn8/cHBU1VwmlOzumdKq59Zs5Vza/?= =?us-ascii?q?pWVFZql/1WwKqVKuZ1IAvqrIQ8VOV+BsDV4/hbNVuccnDCp2FqhNihRG46EB?= =?us-ascii?q?uKSlUL/pX96UkaoFlpi08DgMAPlHYJ85wwD5FC+uTfK6xt0LVDVNUfY65xDP?= =?us-ascii?q?oIBcG3FmvOSxTRN3/6GyWsKIgXf3bW75Ln6rQ84++nPJQO0ZspgZzEFEhVsG?= =?us-ascii?q?YjEnief/FmHKc7hSwlbF/NLwgFkPsulKSRkoeMMYbWDQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A6BgDrHvlh/5tdJa1agQmBWoEhMVY?= =?us-ascii?q?Hd1o3MYgQA4U5hQ6DAgOBE48ngjGIOYEuFIERA1QLAQEBDQEBNwoEAQGFBQK?= =?us-ascii?q?DXwIlNAkOAQIEAQEBEgEBBQEBAQIBBgSBCROFOwEEKA2GQgEBAQECAQwGCA0?= =?us-ascii?q?ZAQE4BAsCAQgRAwEBASEBBgcyFAkIAQEEARIIGoJjgg5XAw0hAQ6iLQGBOgK?= =?us-ascii?q?KH3iBATKBAYIIAQEGBASBOgKDURiCNwMGgTqDDoJ+VEqHCSeCKYEUAUNVgRF?= =?us-ascii?q?KNz6CYwICGIEMHAQcHgYHCYMZgi6RNQElRg5gDSURDgIgLQMNHggVATcKBQk?= =?us-ascii?q?BAhIHDx8LC4EFAZEWG40VjXKSYQYEg0aJKox0iV0VgwVtjByXeZZKIKEWCA8?= =?us-ascii?q?LC4RfAgQCBAUCDgEBBoFhPIFZcIFugUtRGQ+Fa4JfiUeFFIVKdAI2AgYLAQE?= =?us-ascii?q?DCYsGB4I/AQE?= X-IronPort-AV: E=Sophos;i="5.88,333,1635206400"; d="scan'208,217";a="999530543" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Feb 2022 08:38:55 +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 21O8csFA019965 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for ; Thu, 24 Feb 2022 08:38:54 GMT Received: from xfe-aln-004.cisco.com (173.37.135.124) by xbe-rcd-004.cisco.com (173.37.102.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Thu, 24 Feb 2022 02:38:20 -0600 Received: from xfe-rtp-005.cisco.com (64.101.210.235) by xfe-aln-004.cisco.com (173.37.135.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Thu, 24 Feb 2022 02:38:19 -0600 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-005.cisco.com (64.101.210.235) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Thu, 24 Feb 2022 03:38:19 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kOUFZGBHjbtqyl/bY9BnQrFnuuIfLb5vV9itGaE2f5iIKlgEV4Br8m10N4c99LGdRjYxFQB1T16kaJYBAPG7Iv3K7lLiNU9zVm85CDsNfKXETYxfWIPTg77aem9xujbJIGahrmCKQOAPZPdOW5bqcT77qDxHc4fZ31aekdhbdSLboGYExPgrSB3Owa5rbisLMHbGQB8sEUQO9ktW1RwmuwXg4UPebjR7gDjIpv/Ncz62g6XmWD7pxQOIknsSTYZ6OI1aHoJXSFRqbNuUfx0ENmCTBz/x4fKIZPkSKoUjPe4iw0Nq5bg2N0RrpKIvAQiE4JoAWQFUPSMd5c1oRdgCVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=eTShnSp3qabDEfkNKAuI9TdiQe4eOOkzGvDDe8W92K8=; b=TPcUqcofmBXPDX/zP5IyuGb6MgsnFKn8dC7WVM9UMaRx0KW0To/Nb61mvgB6+jgrlC3uR+6IM73BJICiuL+EHMrM23IXx1v6DSbJC/qEVUfzCS96yYggdJ5Qr+Vaakev1f57c7epIyrayEvE5Gt+R8MQ6En/7mRRXnCf1K3VTa+98vyYUuP89g7dZroY8dx/wd48HKjtcQCt+UAYZtJFl86QEKC0IPyGRZqpK2fzzfQFR9Jxw0tbDxphNpjIFCcy64zkCVCTBU6HJ3jsRSXNDVA0g/V3Oy1zlcQJtXXCpsi9MYTNYwi1mvB5w+HMXEzJUYEghqoqunnDRi10/WPc0A== 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=eTShnSp3qabDEfkNKAuI9TdiQe4eOOkzGvDDe8W92K8=; b=Bu7J6gV8L5a3xmKW0hWLkclzuDpxhxIy8Y8cA66Q6LXYRQMOoLZSbwcclJ0robDTaxRDvDFumsUN3J7n2YjIJiM1bYG6rwn533QjReS5ECNItqjWgoeTBBNKTe5k1nZlPCVnB07mxZyRB3HFK+3+p/hp96ROXCEaMkcA9cAwgyA= Received: from PH0PR11MB4919.namprd11.prod.outlook.com (2603:10b6:510:34::12) by DM6PR11MB3113.namprd11.prod.outlook.com (2603:10b6:5:69::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4995.24; Thu, 24 Feb 2022 08:38:17 +0000 Received: from PH0PR11MB4919.namprd11.prod.outlook.com ([fe80::6d55:7f2e:6f4:2d4a]) by PH0PR11MB4919.namprd11.prod.outlook.com ([fe80::6d55:7f2e:6f4:2d4a%4]) with mapi id 15.20.5017.024; Thu, 24 Feb 2022 08:38:16 +0000 From: "Li Zhao (liz3)" To: "Pascal Thubert (pthubert)" , "ROLL WG (roll@ietf.org)" Thread-Topic: Multiple targets in PDR (Was: [Roll] review of dao-projection -22) Thread-Index: AdgJJyV6ErEZ4KG8SV+3gpNv1SjopAe1EorQAFdBsYw= Date: Thu, 24 Feb 2022 08:38:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e1151dd2-d00c-4e00-d331-08d9f77100e6 x-ms-traffictypediagnostic: DM6PR11MB3113:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: W43dTGE/2OUoIZWjDjSHGoKa/VKwvN6aCk/R7Q/zpQLEoWha41SS3qQAOK4vhuiQa7J1HFCvHnbLzssLHxH2QFTOYEplu72zmQszvnsA05F+td76c42eE6VzOymNriZRb0gwd2qkhZSTjiimCW9jwacIHs8hW3HaTsWoE8cj8IjT9EUZBzpc8JPYGQbwd+xycvD21sbzzVMkJeE3YQzH5fHVdMpAEXovYQqtSzfpbUsDCti1kCDgQRtYhQSMvSu9SjZJdnHNmhJONyvLNXzENb/IbINA55ADNB00tfqBVKWXB9qbPAJ/ovo+LVKTaMrgd3BTk9ON4Vcw2cJS9wfyqaLYPGWcIQMwZOpKchPWEHaoJQMwR/GxVVT0EmsGkQOMT154ln5haq6j3rYAS6vUtqedP/EDgEZRZUMJdLN5SFwjqqkrbZbkJ44VBNZMMU+AEL7bRYZX1KKKB5wde6VeIm1+iO3aasZbcvVbXELmuJnEwnYGYGQm9mbJ5U6/8JVfrN/CTGzis3N6NYd0Leid8ZogDMLoKKXaMLtbomwymHxb4cGpfBvnQzFw58B87HLHm/IKv42GBH9sGyvXXyvJE3b19HRmZ06fzubNS3k1L7bZdwTCOBZtNiRBtQ/axQOKPZVB+2MZZ8zlNllFra5Xcks8HKIpplBIHLcZyXCBAJIvEYlChvQyPSwYMA4jZUKYxhUfokCOMJ4hFILd0uh9OUs7RKrrODpBbv5nbWRg3DHFTaM5+Mqf5joCHDoDdto6n6ut9tRPtv8vqn31in1EAbwvfY//y8ZSNXrUTGiryrrFp+Hq1v8lHPf9KVkTQXW64+haKPxLqWqtPT3Q1E7lHf+XbLb/zRMedH2cs+LLY90= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4919.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(71200400001)(7696005)(38070700005)(966005)(53546011)(33656002)(55016003)(6506007)(508600001)(2906002)(9686003)(38100700002)(8936002)(26005)(66476007)(64756008)(91956017)(5660300002)(110136005)(86362001)(66574015)(66946007)(66446008)(8676002)(166002)(30864003)(122000001)(66556008)(52536014)(316002)(83380400001)(76116006)(186003)(88722004)(579004)(559001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?7oMr4hpPBu/5Jm6E6EwDna2PxWS9H35acEvMFaqKqVDd8DbK63OKJGgx?= =?Windows-1252?Q?cI13Ev91b+f5T1xcCAHdu/qlQLDEIDkzn/SMxWOY4/Y+WsGAZUGslS7i?= =?Windows-1252?Q?8H/koUTNgiyxW2Nrtx1+WMhmBRdX7k7grhGURoVlCB3TG7glb438ccew?= =?Windows-1252?Q?5tOwDy3PCDwfIxPsOqrlmNoQWbfmxi64M9ZkKEBpqr0FE3LT+cdy8fMw?= =?Windows-1252?Q?DewR0c2vswA4asaZygw5ZTnGYkJi/SFg+cie3I8idE931/3pDGn1ESoZ?= =?Windows-1252?Q?xmaeP2vdjPdmTDu3Ark/PqPPAj3Du30rmEtK9KRwO0qi8haqnfyLI4vz?= =?Windows-1252?Q?JEl4kjVc80F3F5TXDAS6ZXumy6BvE8UxuGS1veUEUP69oM/8Bm84sYf3?= =?Windows-1252?Q?nVBBAaX4M3v+k173NoRNkfbH9RLsG0WzHcxK+4WAGHoqktwp96HgkE9V?= =?Windows-1252?Q?YnSDIclBvJTcLBwQkr2NlOsxEqBXtXQ30V6D/+0ndJS9X6w5BhcWt2wT?= =?Windows-1252?Q?sGb4JuvJELslKXA8MPrs/vekLzgNSLbvxQNsg+i5LcCWvw8X5ZcjhaBu?= =?Windows-1252?Q?F4bbk4Ut48N+hu8GFN1ux5GnGIAKtFe+EMO80tSkq3iNjew3gpkAnSSM?= =?Windows-1252?Q?4wAFaqXIuBEIKKPwUIZWIl8uFe2gTCmbFY7CxKrTbGdashcbTTfhhVdt?= =?Windows-1252?Q?i7NWxyHFhcSNwXOTQ0gZjAZoEnRRZWwsSEGjEa+RvAQfKd1V40m5mx5c?= =?Windows-1252?Q?XMnQ36PQMHlVY9TrSsjLejhPHe6S6WosDqAhjiwcS8FWyRlHHBfTROLl?= =?Windows-1252?Q?1GagDZhj22J89UJ3RoUeMzH3ck4AEYDqyeCU8hVPUHwXBG2bx2WL9T8z?= =?Windows-1252?Q?F6LW2IDaDGEqCVKX4B2JrhOXHIYVFMdTNhwmAJOdoh/N8sqWcQsLsNVS?= =?Windows-1252?Q?TI1JcuOqUaifWj81XYZI+kzyZheZebTeJDvEKpdIAXGZvP1cg/mXdv53?= =?Windows-1252?Q?if4ntSGagvY7ytkUuA9asHLYh88K/MCvC9Tdum+U5cS4T1QWq0j7EC+4?= =?Windows-1252?Q?6Km7Of1RWN5qZTI21BnmAq3YQrf24iEp1DtsxazMTg6GSVr54gFVXqc5?= =?Windows-1252?Q?qckO73mH/Zz5qtYs4nlCLlK29Fwl1SWuPr+OXTkaKxcR1sKCBnwZKpXi?= =?Windows-1252?Q?q8/XEv7L0DXIUt3Dd61HC8F9v/PCc5k0w1aA7EusA961CENtI1U5luwe?= =?Windows-1252?Q?cWXfgheaGBttzj839R0UQLVejpxwgmkymYpQ/I683vzLnDE0XtE1yZLd?= =?Windows-1252?Q?ZaLS/g3yyLPXbVBAkFX5BwSqVb+RgGvwaY80TqkT0E1jV/aVaW8kVM4/?= =?Windows-1252?Q?6KnnNNLLN/tkYgOaFo/DDWWH1VY31lnp8jHqRr8iDRDm2wEntNQE5q7k?= =?Windows-1252?Q?BX0Y2dC3FX011qxYhNXNe5ETrw2VWWAhy7v/mW8YdtKx/tyYWFaxeVul?= =?Windows-1252?Q?FytbtuZ//30lza1OIm8DpnSGga41YEKfmA3rTxupSJbb/xuZnR8tpM+y?= =?Windows-1252?Q?Xg1uPT15qPrzVZzqatOQCEChT3ZZmdOhgWENc+jqtNmLUYgUrPXuL8ct?= =?Windows-1252?Q?OgoLLGou+2RVismtZ+AuzooTDr3AVCj/nCm5yb7YxhfuHCj2DY9B34uH?= =?Windows-1252?Q?sOP8NJDUFv0=3D?= Content-Type: multipart/alternative; boundary="_000_PH0PR11MB49196E6914CFDC288B5EA0148C3D9PH0PR11MB4919namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4919.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e1151dd2-d00c-4e00-d331-08d9f77100e6 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2022 08:38:16.6566 (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: 5F7njzeNnEfV6cObm+rSGvHzCpxq9cWWZ/UB+U4xlELa/Q99jTL8LXtgbEVZujGX X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3113 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] Multiple targets in PDR (Was: review of dao-projection -22) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2022 08:39:05 -0000 --_000_PH0PR11MB49196E6914CFDC288B5EA0148C3D9PH0PR11MB4919namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Pascal, The new proposal looks good to me. In most cases, we can use one Target Option. Meanwhile allowing multiple ta= rgets keeps the possibility of extension in future. Best regards, Li From: Pascal Thubert (pthubert) Date: Tuesday, February 22, 2022 at 22:55 To: ROLL WG (roll@ietf.org) Cc: Li Zhao (liz3) Subject: RE: Multiple targets in PDR (Was: [Roll] review of dao-projection = -22) Dear all: To address Li=92s comment, is we allow multiple targets then there can be a= set of possible Track each leading to a subset of the listed Targets, and = possibly not all or all with a very bad quality / PDR. Suggestion is to accept more than one target, but focus the response on the= first target and the =93best=94 subset of the others the root can find. IMHO, going into the details of the path quality or which subset is best ta= kes us deeper than we can go in this draft. So I suggest: OLD One and only one RPL Target Option MUST be present in the message New At least one RPL Target Option MUST be present in the message. If more t= han one RPL Target Option is present, the Root will provide a Track that rea= ches the first listed Target and a subset of the other Target; details of the subset selection are out of scope. Works? Pascal From: Pascal Thubert (pthubert) Sent: vendredi 14 janvier 2022 10:20 To: ROLL WG (roll@ietf.org) Cc: Li Zhao (liz3) Subject: Multiple targets in PDR (Was: [Roll] review of dao-projection -22) Dear all: we had this thread as part of Li=92s review: About : =935.1 One and only one RPL Target Option MUST be present in the me= ssage.=94 [Li] -> Is it possible to remove the limitation? It=92s not flexible If PD= R can only carry one RTO. For instance in figure 7, if node I requests P-Route to B&H tog= ether, Root can only push one Track I->A->B->H. Otherwise, Root may push tw= o Tracks I->A->B and I->F->G->H. If Root cannot computer one Track to multiple RTO, it can resp= onse with a special PDR-ACK Status. [PT] This was done in the interest to simplicity, and yes we can rediscuss= that. We=92d need to make decisions on partially successful use cases e.g.,: * What if there=92s a path to only a subset? Should the root form more = than one track? * Or deny with your special status but then what can the source do afte= r that? Try all combinations? * What is the best path to one target cannot reach all targets but a lo= wer quality path can? Should we use that one? * Maybe there could be one main target and additional desirable targets= ? In that case the Root could form the track and indicate which of the opti= onal targets are effectively reachable via the track to the main target. [Li] Maybe it depends on implement of PCE? I=92d like to keep the flexibil= ity because there is a user case for street lighting. Some controllers(Ingr= ess nodes) need to light the street lighting linearly with low-latency. [PT] sure, at the expense of complexity in signaling and processing in the = nodes. We need to be specific on the scenarios and status codes. The PDR f= orms a single Track since the TrackID is provided. I believe it makes sense to ask for more targets since the root can install= a Track for more than one target. Still, signaling is involved and we nee= d a story for all those questions: * What if there=92s a path to only a subset? Should the root form more = than one track? * Or deny with your special status but then what can the source do afte= r that? Try all combinations? * What is the best path to one target cannot reach all targets but a lo= wer quality path can? Should we use that one? * Maybe there could be one main target and additional desirable targets= ? In that case the Root could form the track and indicate which of the opti= onal targets are effectively reachable via the track to the main target. Comments welcome! Pascal From: Roll > On Behalf = Of Li Zhao (liz3) Sent: vendredi 14 janvier 2022 2:51 To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] review of dao-projection -22 Hello Pascal, Please find my comments inline. Best regards, Li From: Roll > on behalf = of Pascal Thubert (pthubert) > Date: Friday, January 14, 2022 at 01:31 To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] review of dao-projection -22 Hello Li A great many thanks for your excellent review! Such are much needed at this= time. > [Li] -> Should it be ? > P-DAO 1 signals C=3D=3D>D=3D=3D>E-to-F,G > P-DAO 2 signals A=3D=3D>B=3D=3D>C-to-E,F,G [PT] correct, great catch! > [Li] -> What's the difference between negative status PDR-ACK and No-Path= P-DAO in section 6.5? And when to use asynchronous PDR-ACK? > In storing mode, root should use No-Path P-DAO to tear down T= rack from egress node. Is PDR-ACK still needed? > In non-storing mode, No-Path P-DAO to ingress node is also en= ough. > But the PDR-ACK Status field makes sense. Is it possible to a= dd this field in No-Path P-DAO? [PT] The no path DAO flow along the reverse path and cleans it; so the end= result would be that the Track is terminated as you figured. So yes, it co= uld be possible to add a status to the no-path DAO but remember that it is = a normal DAO not a completion (IOW not an ack). How could we justify a stat= us in all DAOs? I=92m unclear why the async PDR ack is an issue. If the PDR= can not be served, the track ingress already needs to support a PDR ack th= at =94terminates=94 a Track. To clarify that sentence we can say: =93 The main Root MAY indicate to the Track Ingress that the Track was termi= nated before its time and to do so, it MUST uses an asynchronous PDR-ACK with = an negative status. =93 Should that be more than a MAY? >>>> [Li] Yes. It=92s more clear. So PDR-ACK is for original PDR. And for m= aintain or tear down case, Root should use No-Path P-DAO to terminate P-Rou= te. Correct? > [Li] -> Is it possible to remove the limitation? It=92s not flexible If = PDR can only carry one RTO. > For instance in figure 7, if node I requests P-Route to B&H t= ogether, Root can only push one Track I->A->B->H. Otherwise, Root may push = two Tracks I->A->B and I->F->G->H. > If Root cannot computer one Track to multiple RTO, it can res= ponse with a special PDR-ACK Status. [PT] This was done in the interest to simplicity, and yes we can rediscuss= that. We=92d need to make decisions on partially successful use cases e.g.,: * What if there=92s a path to only a subset? Should the root form more = than one track? * Or deny with your special status but then what can the source do afte= r that? Try all combinations? * What is the best path to one target cannot reach all targets but a lo= wer quality path can? Should we use that one? * Maybe there could be one main target and additional desirable targets= ? In that case the Root could form the track and indicate which of the opti= onal targets are effectively reachable via the track to the main target. >>>> [Li] Maybe it depends on implement of PCE? I=92d like to keep the fle= xibility because there is a user case for street lighting. Some controllers= (Ingress nodes) need to light the street lighting linearly with low-latency= . > [Li] -> Is it possible to add a flag to indicate the symmetry? Otherwise,= if A chooses B as sibling, but B doesn't choose A as sibling, Root may tre= at SIO from A as symmetry incorrectly when only receiving SIO from A. [PT] we used to have that (B Flag for bidir) but we removed it for simplifi= cation. I=92m OK to add it back, but we still lake a good description of ho= w the node will know that the link is roughly symmetrical. >>>> [Li] Some physical layer measurements such as RSSI/LQI have forward an= d reverse direction. Can it indicate symmetrical? In layer 3, receiving DIO/NS messages from each other ind= icate symmetrical? > [Li] -> Confuse with this claim. Is it a MUST NOT if root wants to send n= otification to the requesting node when those changes happen. [PT] There=92s no protocol element to =93send notification to the requestin= g node when those changes happen=94. So it=92s hard to say that the root MU= ST NOT do something that it cannot do. Reworded to =93 Note that there is no protocol element to notify to the requesting Tr= ack Ingress when changes happen deeper down the Track, so they are transp= arent to the Track Ingress. If the main Root cannot maintain an expected se= rvice level, then it needs to tear down the Track completely. =93 > [Li] -> Can you add some description for the collision case? E.g., node t= rusts itself than Root. [PT] I reworded to =93 = In a particular deployment where PDR are not used, a portion of the namespace can be administrati= vely delegated to the main Root, meaning that the main Root is authoritativ= e for assigning the TrackIDs for the Tracks it creates.. =93 [Li] -> Is there any difference between P-DAO-ACK and normal DAO-ACK? E.g.= any flags? Normally, root won't receive any DAO-ACK from nodes. Is it possible to add flag to distinguish P-DAO-ACK from DAO-ACK as P-DAO f= rom DAO. [PT] Done; I added a section for the P-DAO-ACK > [Li] -> Profile 0 is the Legacy support of [RPL] Non-Storing Mode. I= =92m confuse about =93this enables to use Storing Mode to reduce the size o= f the Source Route Header in the most common LLN deployments.=94 [PT] I really meant Profile 1 enables=85 Changing that. I guess that=92s it ! I submitted -23 with this, please have a look at https://www.ietf.org/rfcdi= ff?url2=3Ddraft-ietf-roll-dao-projection-23 Again many thanks! Pascal From: Roll > On Behalf = Of Li Zhao (liz3) Sent: mercredi 12 janvier 2022 10:51 To: Routing Over Low power and Lossy networks > Subject: [Roll] review of dao-projection -22 Hello Authors, Thanks for your great effort. The PDAO draft looks more clear and detailed.= Following is some concern: 3.5.2 Using Non-Storing Mode joining Tracks P-DAO 1 signals C=3D=3D>D=3D=3D>E-to-F,G P-DAO 2 signals A=3D=3D>B=3D=3D>C-to-C,F,G [Li] -> Should it be ? P-DAO 1 signals C=3D=3D>D=3D=3D>E-to-F,G P-DAO 2 signals A=3D=3D>B=3D=3D>C-to-E,F,G Otherwise RIBs in A cannot include destination to E. 4.1. Extending RFC 6550 To ensure that the PDR and P-DAO messages can flow at most times, it is REC= OMMENDED that the nodes involved in a Track =3D=3D=3Dmantain=3D=3D=3D multi= ple parents in the Main DODAG, advertise them all to the Root, and use them= in turn to retry similar packets. It is also RECOMMENDED that the Root use= s diverse source route paths to retry similar messages =3D=3D=3Dot=3D=3D=3D= the nodes in the Track.=B6 [Li] -> Typo for =93mantain=94 and =93ot=94? 4.1.6. This specification defines a new flag "Projected Routes Support" (D). The DODAG Configuration option is copied unmodified from parents to childre= n. =3D=3D=3D=3Dxref target=3D'RFC6550'/>=3D=3D=3D=3D states that: [Li] -> Typo for =93xref target=3D'RFC6550'/>=94. Why is flag named as =93= D=94? There is no D in "Projected Routes Support"=85 5.1 The Root may use an asynchronous PDR-ACK with an negative status to ind= icate that the Track was terminated before its time. [Li] -> What's the difference between negative status PDR-ACK and No-Path P= -DAO in section 6.5? And when to use asynchronous PDR-ACK? In storing mode, root should use No-Path P-DAO to tear down Track from egre= ss node. Is PDR-ACK still needed? In non-storing mode, No-Path P-DAO to ingress node is also enough. But the PDR-ACK Status field makes sense. Is it possible to add this field = in No-Path P-DAO? 5.1 One and only one RPL Target Option MUST be present in the message. [Li] -> Is it possible to remove the limitation? It=92s not flexible If PD= R can only carry one RTO. For instance in figure 7, if node I requests P-Route to B&H together, Root = can only push one Track I->A->B->H. Otherwise, Root may push two Tracks I->= A->B and I->F->G->H. If Root cannot computer one Track to multiple RTO, it can response with a s= pecial PDR-ACK Status. 5.4 only the router with the lowest Interface ID in its registered address = needs report the SIO, and the Root will assume symmetry. [Li] -> Is it possible to add a flag to indicate the symmetry? Otherwise, i= f A chooses B as sibling, but B doesn't choose A as sibling, Root may treat= SIO from A as symmetry incorrectly when only receiving SIO from A. 6.2 There is no notification to the requesting node when those changes hap= pen. [Li] -> Confuse with this claim. Is it a MUST NOT if root wants to send not= ification to the requesting node when those changes happen. 6.3 In a particular deployment where PDR are not used, the namespace can be= delegated to the main Root, which can assign the TrackIDs for the Tracks i= t creates without collision. [Li] -> Can you add some description for the collision case? E.g., node tru= sts itself than Root. 6.4.1 In both cases the Track Ingress is the owner of the Track, and it gen= erates the P-DAO-ACK when the installation is successful [Li] -> Is there any difference between P-DAO-ACK and normal DAO-ACK? E.g.= any flags? Normally, root won't receive any DAO-ACK from nodes. Is it possible to add flag to distinguish P-DAO-ACK from DAO-ACK as P-DAO f= rom DAO. 8 Profiles 0 and 1 are REQUIRED by all implementations that may be used in = LLNs; this enables to use Storing Mode to reduce the size of the Source Rou= te Header in the most common LLN deployments. [Li] -> Profile 0 is the Legacy support of [RPL] Non-Storing Mode. I= =92m confuse about =93this enables to use Storing Mode to reduce the size o= f the Source Route Header in the most common LLN deployments.=94 Best regards, Li --_000_PH0PR11MB49196E6914CFDC288B5EA0148C3D9PH0PR11MB4919namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hello Pascal,

 

The = new proposal looks good to me.

In m= ost cases, we can use one Target Option. Meanwhile allowing multiple ta= rgets keeps the poss= ibility of extension in future.

 

 

Best= regards,

Li

 

From: Pasc= al Thubert (pthubert) <pthubert@cisco.com>
Date: Tuesday, February 22, 2022 at 22:55
To: ROLL WG (roll@ietf.org) <roll@ietf.org>
Cc: Li Zhao (liz3) <liz3@cisco.com>
Subject: RE: Multiple targets in PDR (Was: [Roll] review of dao-proj= ection -22)

Dear= all:

&nbs= p;

To a= ddress Li=92s comment, is we allow multiple targets then there can be a set= of possible Track each leading to a subset of the listed Targets, and poss= ibly not all or all with a very bad quality / PDR.

Sugg= estion is to accept more than one target, but focus the response on the fir= st target and the =93best=94 subset of the others the root can find.=

IMHO= , going into the details of the path quality or which subset is best takes = us deeper than we can go in this draft.

&nbs= p;

So I= suggest:

&nbs= p;

OLD<= /span>

&nbs= p;

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

&nbs= p;

New<= /span>

&nbs= p;

   At least one RPL Target Option= MUST be present in the message. If more than

   one RPL Target Option is prese= nt, the Root will provide a Track that reaches<= o:p>

   the first listed Target and a = subset of the other Target; details of the=

   subset selection are out of sc= ope.

&nbs= p;

Work= s?

&nbs= p;

Pasc= al

&nbs= p;

F= rom: Pascal Thub= ert (pthubert)
Sent: vendredi 14 janvier 2022 10:20
To: ROLL WG (roll@ietf.org) <roll@ietf.org>
Cc: Li Zhao (liz3) <liz3@cisco.com>
Subject: Multiple targets in PDR (Was: [Roll] review of dao-projecti= on -22)

 

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

&nbs= p;

Abou= t : =935.1 One and only one RPL Target Option MUST be present in the messag= e.=94

&nbs= p;

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

&nbs= p;           For instance= in figure 7, if node I requests P-Route to B&H together, Root can only= push one Track I->A->B->H. Otherwise, Root may push two Tracks I-= >A->B and I->F->G->H.=

&nbs= p;            If Roo= t cannot computer one Track to multiple RTO, it can response with a special= PDR-ACK Status.

&nbs= p;

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

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

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

&nbs= p;

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

&nbs= p;

[PT]= sure, at the expense of complexity in signaling and processing in the node= s. We need to  be specific on the scenarios and status codes. The PDR = forms a single Track since the TrackID is provided.

&nbs= p;

&nbs= p;

I be= lieve it makes sense to ask for more targets since the root can install a T= rack for more than one target. Still,  signaling is involved and we ne= ed a story for all those questions:<= /span>

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

&nbs= p;

Comm= ents welcome!

&nbs= p;

Pasc= al

&nbs= p;

F= rom: Roll <roll-bounces@ietf.org> On Behalf Of Li Zhao (liz3)
Sent: vendredi 14 janvier 2022 2:51
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: Re: [Roll] review of dao-projection -22

 

Hell= o Pascal,

&nbs= p;

Plea= se find my comments inline.

&nbs= p;

Best= regards,

Li

&nbs= p;

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

Hell= o Li

&nbs= p;

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

&nbs= p;

>= [Li] ->  Should it be ?

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

>=             P-DAO 2= signals A=3D=3D>B=3D=3D>C-to-E,F,G<= /o:p>

[PT]= correct, great catch!

&nbs= p;

&nbs= p;

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

>=             In stor= ing mode, root should use No-Path P-DAO to tear down Track from egress node= . Is PDR-ACK still needed?

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

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

&nbs= p;

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

&nbs= p;

To c= larify that sentence we can say:

=93<= /span>

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

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

&nbs= p;  negative status.

=93<= /span>

Shou= ld that be more than a MAY?

&nbs= p;

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

&nbs= p;

&nbs= p;

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

>=             For ins= tance in figure 7, if node I requests P-Route to B&H together, Root can= only push one Track I->A->B->H. Otherwise, Root may push two Trac= ks I->A->B and I->F->G->H.<= /o:p>

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

&nbs= p;

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

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

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

&nbs= p;

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

&nbs= p;

 

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

&nbs= p;

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

&nbs= p;

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

&nbs= p;            &= nbsp;    In layer 3, receiving DIO/NS messages from each oth= er indicate symmetrical?

&nbs= p;

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

&nbs= p;

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

&nbs= p;

=93<= /span>

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

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

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

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

=93<= /span>

 

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

 

[PT]= I reworded to

=93<= /span>

&nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     In a particular deployment

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

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

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

=93<= /span>

&nbs= p;

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

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

&nbs= p;

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

&nbs= p;

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

&nbs= p;

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

&nbs= p;

I gu= ess that=92s it !

&nbs= p;

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

&nbs= p;

Agai= n many thanks!

&nbs= p;

Pasc= al

&nbs= p;

F= rom: Roll <roll-bounces@ietf.org> On Behalf Of Li Zhao (liz3)
Sent: mercredi 12 janvier 2022 10:51
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: [Roll] review of dao-projection -22

&nbs= p;

Hell= o Authors,

&nbs= p;

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

&nbs= p;

3.5.= 2 Using Non-Storing Mode joining Tracks

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

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

&nbs= p;

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

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

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

&nbs= p;

&nbs= p;   Otherwise RIBs in A cannot include destination to E.<= span lang=3D"EN-US">

&nbs= p;

4.1.= Extending RFC 6550

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

&nbs= p;  

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

&nbs= p;

4.1.= 6.

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

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

&nbs= p;

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

&nbs= p;

&nbs= p;

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

&nbs= p;

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

In storing mode, root should use No-Path P-DAO to = tear down Track from egress node. Is PDR-ACK still needed?

In non-storing mode, No-Path P-DAO to ingress node= is also enough.

But the PDR-ACK Status field makes sense. Is it possible to add this f= ield in No-Path P-DAO?

&nbs= p;

&nbs= p;

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

&nbs= p;

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

For instance in figure 7, if node I requests P-Rou= te to B&H together, Root can only push one Track I->A->B->H. O= therwise, Root may push two Tracks I->A->B and I->F->G->H.

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

&nbs= p;

&nbs= p;

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

 

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

&nbs= p;

&nbs= p;

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

 

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

 

 

 

6.3 In a particular deployment where P= DR are not used, the namespace can be delegated to the main Root, which can= assign the TrackIDs for the Tracks it creates without collision.

 

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

 

&nbs= p;

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

&nbs= p;

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

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

&nbs= p;

&nbs= p;

8 Pr= ofiles 0 and 1 are REQUIRED by all implementations that may be used in LLNs= ; this enables to use Storing Mode to reduce the size of the Source Route H= eader in the most common LLN deployments.

&nbs= p;

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

&nbs= p;

&nbs= p;

&nbs= p;

Best= regards,

Li

&nbs= p;

&nbs= p;

&nbs= p;

&nbs= p;

&nbs= p;

&nbs= p;

&nbs= p;

&nbs= p;

&nbs= p;

&nbs= p;

--_000_PH0PR11MB49196E6914CFDC288B5EA0148C3D9PH0PR11MB4919namp_-- From nobody Thu Feb 24 05:01:55 2022 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 537503A1333 for ; Thu, 24 Feb 2022 05:01:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.585 X-Spam-Level: X-Spam-Status: No, score=-14.585 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Ur9y+s0k; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Mx0uDLEV 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 nbvWVWcWQqX2 for ; Thu, 24 Feb 2022 05:01:46 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 243303A133A for ; Thu, 24 Feb 2022 05:01:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35693; q=dns/txt; s=iport; t=1645707663; x=1646917263; h=from:to:cc:subject:date:message-id:mime-version; bh=PdR3LYLz9a62DGE6nFMJC5JFEauJkgfcDdW1VQB/VPw=; b=Ur9y+s0kJgWiuv/mR1iMan9zOiO1/aEvL1lwNwmkWAt3E4IgOKc4NyXQ oLAzlycxTzhcv2eTQk3c1SEZsxF0qAPTpcfiDdQFQaXOKjSB8HOHl+BGG NNph3wH2Lf5Qe1FZ2F54ra/CqhcfddTr1rYaNU805vx2lMmxcPg/56ETR U=; IronPort-PHdr: =?us-ascii?q?A9a23=3AXUCs1x01th37qnc6smDPr1BlVkEcU/3cMg0U7?= =?us-ascii?q?88hjLRDOuSm8o/5NUPSrfNqkBfSXIrd5v4F7oies63pVWEap5rUtncEfc9AU?= =?us-ascii?q?hYfgpAQmAotSMeOFUz8KqvsaCo3VMRPXVNo5Te1K09QTc3/fFbV5Ha16G16J?= =?us-ascii?q?w=3D=3D?= IronPort-Data: =?us-ascii?q?A9a23=3A2nmPCqmBXhqXKZliTorDiP/o5gyfJERdPkR7X?= =?us-ascii?q?Q2eYbSJt1+Wr1GztxIdWGmPbPeMZGr2fNB/a4Tg8kpU7cfQmtBjTlE4+S1hQ?= =?us-ascii?q?ltH+JHPbTi7wugcHM8zwvUuxyuL1u1GAjX7BJ1yHi+0SiuFaOC79yEmjfjQH?= =?us-ascii?q?9IQNcadUsxPbV48IMseoUoLd94R2uaEsPDha++/kYqaT/73YDdJ7wVJ3lc8s?= =?us-ascii?q?Mpvnv/AUMPa41v0tnRmDRxCUcS3e3M9VPrzLonpR5f0rxU9IwK0ewrD5OnRE?= =?us-ascii?q?mLx5RwhDJaulaz2NxRTBLXTJgOJzHFRXsBOgDAb+Xd0ifl9ZaFaMBsI49mKt?= =?us-ascii?q?4gZJNFlrYCwVA0kJLHkk+UGWB4eGCZ7VUFD0O6WeSbi4ZDJlSUqdFOpmZ2CF?= =?us-ascii?q?noeJ4oc/s52DH1As/sCJ1gwgrqr7w6t6KiwRu8pjcM5IYyyZcUUu2prynfSC?= =?us-ascii?q?vNOfHwKeI2Sjfcw4dv6rpkXRqu2ixIlVAdS?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3A2+Ng1q+mwClzon5IdbVuk+Fpdb1zdoMgy1?= =?us-ascii?q?knxilNoENuE/BwxvrBoB1E73DJYW4qKQ0dcdDpAtjmfZquz+8L3WBxB8bvYO?= =?us-ascii?q?CCgguVxe5ZnPDfK7OLIVyFygcw79YET0EcMqy+MbEZt7eG3ODQKb9Jq7PrnN?= =?us-ascii?q?HK9IXjJhxWPGdXgtRbnn9E43GgYzRLrWd9dP4EPavZwvACiyureHwRYMj+LG?= =?us-ascii?q?ICRfL/q9rCk4+jSQIaBjY8gTP+ww+A2frfKVy1zx0eWzRAzfMJ6m7eiTH04a?= =?us-ascii?q?2lrrWS1gLc7WnO9J5b8eGRi+erRfb8yvT9GA+cyDpAV74RHoFqewpF5N1H3W?= =?us-ascii?q?xa0+UkZS1QePibpUmhOF1d6iGdpTUImAxemkMKj2Xo2EcKZafCNWkH4w0rv/?= =?us-ascii?q?MATvKR0TtRgPhslK1MxG6XrJxREFfJmzn8/cHBU1VwmlOzumdKq59Zs5Vza/?= =?us-ascii?q?pWVFZql/1WwKqVKuZ1IAvqrIQ8VOV+BsDV4/hbNVuccnDCp2FqhNihRG46EB?= =?us-ascii?q?uKSlUL/pX96UkaoFlpi08DgMAPlHYJ85wwD5FC+uTfK6xt0LVDVNUfY65xDP?= =?us-ascii?q?oIBcG3FmvOSxTRN3/6GyWsKIgXf3bW75Ln6rQ84++nPJQO0ZspgZzEFEhVsG?= =?us-ascii?q?YjEnief/FmHKc7hSwlbF/NLwgFkPsulKSRkoeMMYbWDQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A1BgDWHflh/5NdJa1agQmBWoEhMVY?= =?us-ascii?q?Hd1o3MYgQA4U5hQ6DAgOBE48ngjGIOYEuFIERA1QLAQEBDQEBNwoEAQGFBQK?= =?us-ascii?q?DXwIlNAkOAQIEAQEBEgEBBQEBAQIBBgSBCROFOwEEKA2GQgEBAQEDDAYVBhM?= =?us-ascii?q?BASUSAREBCBEEAQEhAQY5FAkJAQQOBQgagmOCDlcDLgEOoigBgToCih94gQE?= =?us-ascii?q?ygQGCCAEBBgQEhQ0YgjcDBoE6gw6CflRKhzAcgUlEgRQBQ1WBEUo3PoJjAgK?= =?us-ascii?q?BJBwEHCQHCYMZgi6RNiVGDmANNg4CIAIrAyseNwoOAQISBw8fCxGfRoFxjAG?= =?us-ascii?q?SYQqDRosBix2JXRWUMJNXlkogjG+UJxcLC4RfAgQCBAUCDgEBBoFhPIFZcBW?= =?us-ascii?q?DJFEZD4Vrgl+GDYM6hRSFSnQCNgIGCwEBAwmLBgeCPwEB?= X-IronPort-AV: E=Sophos;i="5.88,333,1635206400"; d="scan'208,217";a="990658422" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Feb 2022 13:00:31 +0000 Received: from mail.cisco.com (xbe-rcd-005.cisco.com [173.37.102.20]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 21OD0T3b012163 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for ; Thu, 24 Feb 2022 13:00:30 GMT Received: from xfe-rtp-004.cisco.com (64.101.210.234) by xbe-rcd-005.cisco.com (173.37.102.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Thu, 24 Feb 2022 07:00:28 -0600 Received: from xfe-aln-002.cisco.com (173.37.135.122) by xfe-rtp-004.cisco.com (64.101.210.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Thu, 24 Feb 2022 08:00:27 -0500 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-002.cisco.com (173.37.135.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Thu, 24 Feb 2022 07:00:27 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Y4Xx6STNhGOQlIdl5cduKb/Fnks/mV0fI5HKPdsCyac14kmZVYsVc/3CPI5lesgJX6HC67NOBj4Fa6qrVwUz4Env0g3IB2HVaV+5eeHTbngqY7Y84EpxXTnymmf5QfsZocUaCaauFkG1Dg57e749XALQv6ZtuXGOud4b1jiTq2jBZSWxdAUGTY1GnmVV7cuOOgBU7mX6Vo0Q/3z+W/KhgS6PGIFKM9fGruhy8vHjS8K+JXwJjMbJDJAuxCrIjf5rt6I1Pl598yzlat16mdqPcLo4syDhoKT8HW7c27sVLC5o9Su8GkJRIJsErhnjffkMpE5nzSAbON5G/TV63lzdEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=i7Q9WPz8BPu7eIArEvFUqZbmnt3ZrSjif33c6l89qGk=; b=epWIjd7q1GK9fm3eDA7Yyj+5XIKFdwSrxJErQr1P7pVBRDwsXwNOg21wAfL5hY5ptcmOLb3gHkE9oCp/jl7ytyujAuwCAG3RpbOIkTB9zPe77cMxiNNWfUCllj2foZQqmlda8LXaPI9m2NuwUuJ/vh8o7zk902vKs5xqAvwikAOb0dnVp9gl2hwReTlonCrHfzOabiFeFlEuQUxK0AR6uhcOkXcNLTWNd4KQ7LIqQK6gGJQOcUM4uZ+5273MW4BTZ1HUX4PMrnGG07Uob+eYYmi9Ofhq15gKwEGg/lOKVYoPVOlEbvbDqfmg+PQqfTAKk6RNnF1M3R5NHTJZrMhNjg== 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=i7Q9WPz8BPu7eIArEvFUqZbmnt3ZrSjif33c6l89qGk=; b=Mx0uDLEVwGTnVJaSBbij4D5MYtUpvm9rnuWiaGIHll1ADBXj69oIhY6a4ZsfP/1BMm6mvC1IlrlfzzXWTSk+PXjWZp81UcMAwOwpmMvDkkUG0fa5r0NDnp27+y5b4K1SjiqcqiShSJ9VpGJ/sua9gjowdXJmQIaEUA8Ikjo4DEg= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by DM4PR11MB5440.namprd11.prod.outlook.com (2603:10b6:5:39c::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5017.22; Thu, 24 Feb 2022 13:00:26 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::f515:598d:4160:b4b8]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::f515:598d:4160:b4b8%4]) with mapi id 15.20.5017.022; Thu, 24 Feb 2022 13:00:26 +0000 From: "Pascal Thubert (pthubert)" To: "ROLL WG (roll@ietf.org)" Thread-Topic: Reporting Links: Bidirectional vs Symmetrical (Was: review of dao-projection -22) Thread-Index: AdgpcUWc8mKMuUnWSsS5Bax1TjHaYw== Date: Thu, 24 Feb 2022 13:00:07 +0000 Deferred-Delivery: Thu, 24 Feb 2022 12:59:47 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bb4c9603-63e1-4ffa-10b8-08d9f795a052 x-ms-traffictypediagnostic: DM4PR11MB5440:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 196Z/mRcHfV087k/DveqX9gCxTiOUrDHUlVSXlI9khifBD+OzcSakAtToDuA+Z758vq4PPI74Tg907LJgNJaS9sURpRsWlcnsn5H+vUxMC7mBI/l16SdS2+GX8m+gd/Sqs4L3VeMOFDucQQxEpNTQVOZixOCden0LkZO8HiOeSzB3uAnpXETorUO08xZOAJib4ambToe2Q9YG5kZVg1Kn6B2tZl0kEbX+YL+ckNa1bIbmMVVPwnmiq3l8kMLN67Ke9PA0vfY7AQqaX792LujEQq+aieFc/FuISfxojQ24x/9vXX/8d+jpJqV9Nwb542tiaog9+w3ZInBXRpe/3uqrDpN9xF2CqmcbP/6KjpLoagTqUTbZDm+2pi0Fv7dagdGnfiKteBMvdvXT+1r3ciZTRGA/kOny4A1K/qnaUGxR7GOrCMqHcJ3BdCkFlXQVL/ULU0zB118xK+hH8wO6KqGOLFD/eElWKfNDKmNNpL5jVT6Bf0mq9dqVZ/UjzPS3GtFaQYSpDdgWacx7wvkz3y8Dj7dJRBYwETr8OjTenrKKvsLjEoaeg4R5Ke+2CX6dR1Dy34sf7oDNmXKS7z545VaQt/pq4go3Q4+fSNx5oO+5L/PoeCFsRFIYjBWou0DaWdfIZC1E/CqhshR5q8yjZZeYE/XMbuqZ8j7lnCLeJLP2gW0ny1WMMKm6MAyZ7iiAHIGEuInn/E1bxTYmY/HYD3xVG4jHSvZtyIU5ysu3PXVt+lTKVrWyf+U/uzSsv6fB19PK2BTxrMnqluVNTR1j+J8IP6GbDXcwFHxYMTnaPivimGZNaj8zb+Cd8qHDx1htuum x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB4881.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(66574015)(52536014)(5660300002)(9686003)(8936002)(107886003)(2906002)(316002)(966005)(508600001)(86362001)(33656002)(6916009)(122000001)(4326008)(38070700005)(38100700002)(66446008)(64756008)(66946007)(6666004)(66556008)(8676002)(76116006)(71200400001)(66476007)(53546011)(55016003)(83380400001)(186003)(166002)(6506007)(7696005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?maWF8r4UVZ+U6168PNOlt3+VVwmicIrRmtxNJsHNh07sjcNO4ZTGaWWtAE?= =?iso-8859-1?Q?MuPe13VZJC41fU/RWctyKAp209vxBdqzSqflhMmT652heGNuoibczkFU+q?= =?iso-8859-1?Q?z1/bRiCe0+5c/ZXEvF8SJgj3r/9Go4vPA0L4cfbl2t9iIl+orzDFsgnRSQ?= =?iso-8859-1?Q?i4pQOIAGSO14czaazIzuPPfuDqrmrCC9qx7Au5F3MxOvv79iAYVXvFOwTA?= =?iso-8859-1?Q?ZzmPObdeJ+c0ZIXTIBwEi2VvvYIc6/6YI7Rd/9TR60gXiwTejxd1EeNla2?= =?iso-8859-1?Q?QPCTTwSknQt1dmf5QxtL/R1899JfCnkFIZX+EjTKHLqQg5wiSbT/CoMtnK?= =?iso-8859-1?Q?h2xe1+1QUyarZ/1Wk/lhXRDkKvvpeSzKehi/ErLZoD38gKAQ7IM8RtGYq8?= =?iso-8859-1?Q?rzshs9KbmrCjuEeF/B4m8/XNVufJJHVsxWFNCa/boKyvhaiErdWw8LkIg2?= =?iso-8859-1?Q?E5fsjJXten6BZLYLl9eS6VEh++YAbuJ3yRF8sU+nkto4mbY3jLJFdiwqEu?= =?iso-8859-1?Q?VqPLezw/yVlUQMGs/3AB5QikzjuVcHUfAiKUsIdIBsbwa6yeUm07fxgJ+U?= =?iso-8859-1?Q?lMkr/LWvi8bKrJqlbHReKpB6ZgM20tDjQFfgqQyq1fQB8TKY/uazYZaETQ?= =?iso-8859-1?Q?4/GarJL41v8ue5V7xUZKbmZA6TsnamWe+/ZRREUEU+QNJ+R0lFA+0c5apZ?= =?iso-8859-1?Q?QlZu+gAum/Muj0ofv/jAniLcIe8GYfOYqV9ovZb+vEa2DGXovzBxHarEZE?= =?iso-8859-1?Q?AhzAOppr//pJT/JtDQWyvkHKyfeU1aaMILAZt0mMD4WB8moIKjsRstY4W9?= =?iso-8859-1?Q?sHWqCnUfzej+GrAcWV+VrwRDC1880ToBwDo9aQFCunTYRJxKeoEw4rtmY4?= =?iso-8859-1?Q?ck9XD+ewS5Ayp9bUvESPjkVQQSxO4jfzK0yjB3Xtc+Fgi5qgCg9NE3Ln5J?= =?iso-8859-1?Q?xxmZI5VI75UuPB16NCLBhlgSg6P+CJL2/lAHRonZTztwH1TliYT/nTU6pu?= =?iso-8859-1?Q?7uqXlSdZImgmQ489iWTmOpO6VNKKhdX3nrVNcncZbrDMFF5AjTUX2Ri+FK?= =?iso-8859-1?Q?7YHQyjS5DFBX2DHdOx/0ur+MhDZZ7eBtdG5plQyhp4XPICymnLoYS+Nwa5?= =?iso-8859-1?Q?iUfFD9QMacaZdeGRe6vFh13BlgcxzjL+AmENrQJVWTpkDr6B5JnQWT2VGO?= =?iso-8859-1?Q?+DSGKcZgjGVlQPSM4dNPrTkdHywJo2VZ1m1VYLnhKug5sFHOXjk2K8OaW6?= =?iso-8859-1?Q?9BQx4jg+cEXl+zP+RgS2eOrOJwyZYxBdpuCiP15eBkpTp0gazcfWy7FnVp?= =?iso-8859-1?Q?5x7uAS1b2eb85aK0qGQDfgKU11x182rreqkbIcsT6SUf2MKJwNjJrZTt0n?= =?iso-8859-1?Q?JKNofjevsuZgKgJLuZ4EECZiQonDcmJOC2KRuoVThY9viOrn7jHoC4Iq/P?= =?iso-8859-1?Q?Zr4qqg/1ukFhfkUQCw/WpTaFMoHS1b0//L5mv5Rqbr4wauOfVIg6kOhz7c?= =?iso-8859-1?Q?DafCAQptqjD4DzYj+qctWbhnW8oavkkhd2uU+mrxwCW0naS6y5YyG/FiLf?= =?iso-8859-1?Q?AjbA/ZSz/w5LO1Y8VqeTZm1eCzisKecjTyHDuCYNxshMzlLlNPrY3+1AJa?= =?iso-8859-1?Q?kxVxzegHSkk+4KSazLYiMu118lxXOk/xFMp8l9RoIaZDDnfT+hqEhwKF+G?= =?iso-8859-1?Q?ezMgI0JH2Qf0PWlzaXNR5xQdl/xjhrvUYu081j/4K9XyOO17sVYIRulk+1?= =?iso-8859-1?Q?0ObjMN7pftYaCsxc/K7xS7b0g=3D?= Content-Type: multipart/alternative; boundary="_000_CO1PR11MB48814A8896C4D3E0B79E8718D83D9CO1PR11MB4881namp_" 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: bb4c9603-63e1-4ffa-10b8-08d9f795a052 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2022 13:00:25.9525 (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: QiaitPOV+Nv+AhxOIRbQCIXIWXCdvJT/UvGrcmnHRWkrmVdT4FHQJPbVLbHnMXUnJpLW2GgjTdo1RFzJ7tOz8Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR11MB5440 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.20, xbe-rcd-005.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [Roll] Reporting Links: Bidirectional vs Symmetrical (Was: review of dao-projection -22) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2022 13:01:52 -0000 --_000_CO1PR11MB48814A8896C4D3E0B79E8718D83D9CO1PR11MB4881namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all This is now issue 11 in github https://github.com/roll-wg/dao-projection/is= sues/11 The spec alone does not provide a way to assert whether the link is bidir o= r not. Some techs may leverage existing L2 information or sync/compare their DLEP = state but that needs to be defined for a specific case/technology. So I suggest we add text like: " The SIO carries a flag (B) that is set when similar performances can be expected both directions, so the routing can consider that the informat= ion provided for one direction is valid for both? The policy that describes= the performance criteria, and how they are asserted is out of scope. In the absence of an external protocol to assert the link quality, the = flag SHOULD NOT be set. " What do you think? Pascal From: Pascal Thubert (pthubert) Sent: vendredi 14 janvier 2022 11:20 To: ROLL WG (roll@ietf.org) Cc: Li Zhao (liz3) Subject: (Was: review of dao-projection -22) Dear all: we had this thread as part of Li's review: About "5.4 only the router with the lowest Interface ID in its registered a= ddress needs report the SIO, and the Root will assume symmetry." [Li] -> Is it possible to add a flag to indicate the symmetry? Otherwise, i= f A chooses B as sibling, but B doesn't choose A as sibling, Root may treat= SIO from A as symmetry incorrectly when only receiving SIO from A. [PT] we used to have that (B Flag for bidir) but we removed it for simplifi= cation. I'm OK to add it back, but we still lake a good description of how = the node will know that the link is roughly symmetrical. [Li] Some physical layer measurements such as RSSI/LQI have forward and rev= erse direction. Can it indicate symmetrical? In layer 3, receiving DIO/NS messages from each other ind= icate symmetrical [PT] There's a nuance between bidir and symmetrical. Maybe the ping works = but the link quality is very different in both directions. If so the Rank i= ncrement computation would differ widely and we would need both sides. At the moment the text says: " B: 1-bit flag that is set to indicate that the connectivity to the sibling is bidirectional and roughly symmetrical. In that case, only one of the siblings may report the SIO for the hop. If 'B' is not set then the SIO only indicates connectivity from the sibling to this node, and does not provide information on the hop from this node to the sibling. " We need to clarify what the B flag means, when it can be set, and what is e= xpected from the Root/ PCE about path computation when it is set or not set= . Suggestions welcome; Pascal From: Roll > On Behalf = Of Li Zhao (liz3) Sent: mercredi 12 janvier 2022 10:51 To: Routing Over Low power and Lossy networks > Subject: [Roll] review of dao-projection -22 Hello Authors, Thanks for your great effort. The PDAO draft looks more clear and detailed.= Following is some concern: 3.5.2 Using Non-Storing Mode joining Tracks P-DAO 1 signals C=3D=3D>D=3D=3D>E-to-F,G P-DAO 2 signals A=3D=3D>B=3D=3D>C-to-C,F,G [Li] -> Should it be ? P-DAO 1 signals C=3D=3D>D=3D=3D>E-to-F,G P-DAO 2 signals A=3D=3D>B=3D=3D>C-to-E,F,G Otherwise RIBs in A cannot include destination to E. 4.1. Extending RFC 6550 To ensure that the PDR and P-DAO messages can flow at most times, it is REC= OMMENDED that the nodes involved in a Track =3D=3D=3Dmantain=3D=3D=3D multi= ple parents in the Main DODAG, advertise them all to the Root, and use them= in turn to retry similar packets. It is also RECOMMENDED that the Root use= s diverse source route paths to retry similar messages =3D=3D=3Dot=3D=3D=3D= the nodes in the Track.=B6 [Li] -> Typo for "mantain" and "ot"? 4.1.6. This specification defines a new flag "Projected Routes Support" (D). The DODAG Configuration option is copied unmodified from parents to childre= n. =3D=3D=3D=3Dxref target=3D'RFC6550'/>=3D=3D=3D=3D states that: [Li] -> Typo for "xref target=3D'RFC6550'/>". Why is flag named as "D"? Th= ere is no D in "Projected Routes Support"... 5.1 The Root may use an asynchronous PDR-ACK with an negative status to ind= icate that the Track was terminated before its time. [Li] -> What's the difference between negative status PDR-ACK and No-Path P= -DAO in section 6.5? And when to use asynchronous PDR-ACK? In storing mode, root should use No-Path P-DAO to tear down Track from egre= ss node. Is PDR-ACK still needed? In non-storing mode, No-Path P-DAO to ingress node is also enough. But the PDR-ACK Status field makes sense. Is it possible to add this field = in No-Path P-DAO? 5.1 One and only one RPL Target Option MUST be present in the message. [Li] -> Is it possible to remove the limitation? It's not flexible If PDR = can only carry one RTO. For instance in figure 7, if node I requests P-Route to B&H together, Root = can only push one Track I->A->B->H. Otherwise, Root may push two Tracks I->= A->B and I->F->G->H. If Root cannot computer one Track to multiple RTO, it can response with a s= pecial PDR-ACK Status. 5.4 only the router with the lowest Interface ID in its registered address = needs report the SIO, and the Root will assume symmetry. [Li] -> Is it possible to add a flag to indicate the symmetry? Otherwise, i= f A chooses B as sibling, but B doesn't choose A as sibling, Root may treat= SIO from A as symmetry incorrectly when only receiving SIO from A. 6.2 There is no notification to the requesting node when those changes hap= pen. [Li] -> Confuse with this claim. Is it a MUST NOT if root wants to send not= ification to the requesting node when those changes happen. 6.3 In a particular deployment where PDR are not used, the namespace can be= delegated to the main Root, which can assign the TrackIDs for the Tracks i= t creates without collision. [Li] -> Can you add some description for the collision case? E.g., node tru= sts itself than Root. 6.4.1 In both cases the Track Ingress is the owner of the Track, and it gen= erates the P-DAO-ACK when the installation is successful [Li] -> Is there any difference between P-DAO-ACK and normal DAO-ACK? E.g.= any flags? Normally, root won't receive any DAO-ACK from nodes. Is it possible to add flag to distinguish P-DAO-ACK from DAO-ACK as P-DAO f= rom DAO. 8 Profiles 0 and 1 are REQUIRED by all implementations that may be used in = LLNs; this enables to use Storing Mode to reduce the size of the Source Rou= te Header in the most common LLN deployments. [Li] -> Profile 0 is the Legacy support of [RPL] Non-Storing Mode. I'm= confuse about "this enables to use Storing Mode to reduce the size of the = Source Route Header in the most common LLN deployments." Best regards, Li --_000_CO1PR11MB48814A8896C4D3E0B79E8718D83D9CO1PR11MB4881namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear all

 

This is now issue 11 in github https://git= hub.com/roll-wg/dao-projection/issues/11

 

The spec alone does not provide a way to assert whether the = link is bidir or not.

Some techs may leverage existing L2 information or sync/comp= are their DLEP state but that needs to be defined for a specific case/techn= ology.

 

So I suggest we add text like:

“

    The SIO carries a flag (B) that is set wh= en similar performances can be

    expected both directions, so the routing = can consider that the information

    provided for one direction is valid for b= oth? The policy that describes the

    performance criteria, and how they are as= serted is out of scope.

    In the absence of an external protocol to= assert the link quality, the flag

    SHOULD NOT be set.

“

 

What do you think?

 

Pascal

 

From: Pascal Thubert (= pthubert)
Sent: vendredi 14 janvier 20= 22 11:20
To: ROLL WG (roll@ietf.org) = <roll@ietf.org>
Cc: Li Zhao (liz3) <liz3@= cisco.com>
Subject: (Was: review of dao= -projection -22)

 

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

 

 

About “5.4 only the router with the lowest Interface I= D in its registered address needs report the SIO, and the Root will assume = symmetry.”

 

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

 

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

 

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

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

 

[PT] There’s a nuance between bidir and symmetrical.&n= bsp; Maybe the ping works but the link quality is very different in both di= rections. If so the Rank increment computation would differ widely and we would need both sides.

 

At the moment the text says:

“

   B:  1-bit flag that is set to indicate tha= t the connectivity to the

      sibling is bidirectional and = roughly symmetrical.  In that case,

      only one of the siblings may = report the SIO for the hop.  If 'B'

      is not set then the SIO only = indicates connectivity from the

      sibling to this node, and doe= s not provide information on the hop

      from this node to the sibling= .

“

 

We need to clarify what the B flag means, when it can be set= , and what is expected from the Root/ PCE about path computation when it is= set or not set.

 

Suggestions welcome;

 

Pascal

 

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

 

Hello Authors,

 

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

 

3.5.2 Using Non-Storing Mode joining Tracks

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

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

 

   [Li] ->  Should it be ?

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

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

 

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

 

4.1. Extending RFC 6550

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

   

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

 

4.1.6.

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

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

 

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

 

 

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

 

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

In storing mode, root should = use No-Path P-DAO to tear down Track from egress node. Is PDR-ACK still needed?

In non-storing mode, No-Path = P-DAO to ingress node is also enough.

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

 

 

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

 

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

For instance in figure 7, if = node I requests P-Route to B&H together, Root can only push one Track I= ->A->B->H. Otherwise, Root may push two Tracks I->A->B and I->F->G->H.

If Root cannot computer one T= rack to multiple RTO, it can response with a special PDR-ACK Status.

 

 

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

 

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

 

 

6.2  There is no notification to the requesting node wh= en those changes happen.

 

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

 

 

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

 

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

 

 

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

 

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

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

 

 

8 Profiles 0 and 1 are REQUIRED by all implementations that = may be used in LLNs; this enables to use Storing Mode to reduce the size of= the Source Route Header in the most common LLN deployments.

 

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

 

 

 

Best regards,

Li

 

 

 

 

 

 

 

 

 

 

--_000_CO1PR11MB48814A8896C4D3E0B79E8718D83D9CO1PR11MB4881namp_-- From nobody Thu Feb 24 05:36:39 2022 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3AF3A0D9E for ; Thu, 24 Feb 2022 05:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.585 X-Spam-Level: X-Spam-Status: No, score=-14.585 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=h5e1UUqv; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=OCNh9SU/ 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 GKZMzkyA4xhj for ; Thu, 24 Feb 2022 05:36:31 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55D163A0D70 for ; Thu, 24 Feb 2022 05:36:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=78426; q=dns/txt; s=iport; t=1645709791; x=1646919391; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=xjDoFNcvikra3yhQWVF7UVhgTHP9R3Mczjw7yffPWFc=; b=h5e1UUqvyFcKBTwynGKW8PPd0JGUZX94IV3Pocfz8u78WIVY6kV4Cuwu e39jJJm8sKF2hqHO1pexCntjTbeB875tKMGJ4VhH7gbWJx72iult2Xz2Q QSZE4o8wcjUi92D4lCqCooj91ZA2nMtMVw3zli/90Q9cjfPy0wrA/B+jx I=; IronPort-PHdr: =?us-ascii?q?A9a23=3Ahmt74x0r3PaIa5YvsmDPr1BlVkEcU/3cMg0U7?= =?us-ascii?q?88hjLRDOuSm8o/5NUPSrfNqkBfSXIrd5v4F7oies63pVWEap5rUtncEfc9AU?= =?us-ascii?q?hYfgpAQmAotSMeOFUz8KqvsaCo3VMRPXVNo5Te1K09QTc3/fFbV5Ha16G16J?= =?us-ascii?q?w=3D=3D?= IronPort-Data: =?us-ascii?q?A9a23=3ABDP/k68049k46YTLMkR2DrUDk3yTJUtcMsCJ2?= =?us-ascii?q?f8bNWPcYEJGY0x3yTMeCDvQbv/eN2H0ft92YN7kp00DupWDydVrGQFv/CtEQ?= =?us-ascii?q?iMRo6IpJzg2wmQcns+qw0aqoHtPt63yUfGdapBkJpPgjk31aOK59yEljfjgq?= =?us-ascii?q?ofUUYYoBAggHWeIdw954f5Ts7ZRbr9A2bBVMSvU0T/Bi5W31Gue5tJBGjl8B?= =?us-ascii?q?5RvB/9YlK+aVDsw5jTSbB3Q1bPUvyF94Jk3fcldI5ZkK7S4ENJWR86bpF241?= =?us-ascii?q?nnS8xFoAdS/n/OrNEYLWbXVewOJjxK6WYD73UME/XN0g/19baZAAatUo23hc?= =?us-ascii?q?9RZ0MlNqJa9UxsBNazXk+NbWB5de817FfwZpOOYfyHn7aR/yGWDKRMA2c5GF?= =?us-ascii?q?kYyOaUZ9/p5R2ZU+pQlxJolBvyYr/i9zLT+Qe52i4FzasLqJ4gY/HpnyFnk4?= =?us-ascii?q?T8dacira833CRVwhV/cXvxzIMs=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AFqU0DK4vR5VFw3yRFgPXwWWBI+orL9Y04l?= =?us-ascii?q?Q7vn2ZFiY1TiXIra6TdaoguiMc0AxhJk3Jmbi7Sc69qADnhO9ICOgqTPmftW?= =?us-ascii?q?zd2FdAQ7sSlrcLTVfbalfDH4JmpMJdmu1FeaLN5DtB/IfHCWuDYqsdKbC8mc?= =?us-ascii?q?jC74qzvhQdLz2CKZsQkzuRYTzrdHGeMTM2fabRY6Dsn/avyQDQHUg/X4CePD?= =?us-ascii?q?0oTuLDr9rEmNbNehgdHSMq7wGIkHeB9KP6OwLw5GZfbxp/hZMZtUTVmQ3w4a?= =?us-ascii?q?uu99uhzAXH6mPV55NK3PP819p4AtCWgMR9EESutu/oXvUiZ1SxhkFwnAid0i?= =?us-ascii?q?dsrDAKmWZnAy1H0QKVQohym2q15+Cv6kd315ao8y7pvZKqm72LeNt9MbsbuW?= =?us-ascii?q?qcGSGptnbJe7pHofh2NiuixuhqJAKFkyLn69fSURZ20kKyvHo5iOYWy2dSSI?= =?us-ascii?q?0EddZq3MEiFW5uYdw99RjBmcoa+ShVfbfhzecTdUnfY2HSv2FpztDpVnMvHg?= =?us-ascii?q?2eSkxHvsCOyTBZkH1w0kNdnaUk7zg93YN4T4MB6/XPM6xumr0LRsgKbbhlDO?= =?us-ascii?q?NERcesEGTCTR/FLWrXK1X6E6MMPW7LtvfMkfkIzfDvfIZNwIo5mZzHXl8dvW?= =?us-ascii?q?kue1j2AcnLx5FP+gClehT0Yd0s8LAW23FUgMyJeFOwC1z3dLkHqbrWn8ki?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BzBgByHvlh/5BdJa1aHgEBCxIMQIF?= =?us-ascii?q?PC4EhATBWB3daEyQxiBADhTmFDoMCA4ETjyeCMYg5gS4UgREDVAsBAQENAQE?= =?us-ascii?q?3CgQBAYUFAoNfAiU0CQ4BAgQBAQESAQEFAQEBAgEGBIEJE4U7AQQoDYZCAQE?= =?us-ascii?q?BAQIBDAYIDQYTAQE3AQQLAgEIEQMBAQEhAQYHMhQJCAEBBA4FCBqCY4IOVwM?= =?us-ascii?q?NIQEOoisBgToCih94gQEygQGCCAEBBgQEgToCg1EYgjcDBoE6gw6CflRKhwk?= =?us-ascii?q?nHIFJRIEUAUNVgRFKNz6CYwICGIEMHAQcHgYHCYMZgi6RNQEQFUYOYA0lEQo?= =?us-ascii?q?EAiACKwMNHggVATIFDgEJAQISBw8fCwuSN40VgXGMAZJhCoNGiSqBV4sdiV0?= =?us-ascii?q?Vg3KMHJd5lkogjG+UJwgPCwuEXwIEAgQFAg4BAQaBYTyBWXAVO4JpURkPhWu?= =?us-ascii?q?CX4VWg3GFFIVKdAI2AgYLAQEDCYsGB4I/AQE?= X-IronPort-AV: E=Sophos;i="5.88,333,1635206400"; d="scan'208,217";a="974476104" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Feb 2022 13:36:29 +0000 Received: from mail.cisco.com (xbe-rcd-002.cisco.com [173.37.102.17]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 21ODaTDt009372 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for ; Thu, 24 Feb 2022 13:36:29 GMT Received: from xfe-aln-002.cisco.com (173.37.135.122) by xbe-rcd-002.cisco.com (173.37.102.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Thu, 24 Feb 2022 07:36:28 -0600 Received: from xfe-rcd-002.cisco.com (173.37.227.250) by xfe-aln-002.cisco.com (173.37.135.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Thu, 24 Feb 2022 07:36:28 -0600 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.986.14 via Frontend Transport; Thu, 24 Feb 2022 07:36:28 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KP5h5RmucUnB7p2XdvPt2HWH3MKS7cooXGbTMz4GosXezsiUUvkbgLi66F95KiSca5NokFYEWw9gplhT6pYmUTosNp2cPzit5KEZR6bchqeYtxmYaa/iyHszdVYNQsl/ceMgyNNqBhmv/ohU1v1pTGA9a3Dw1lWwS9Yy7Eb6ald5lf2DU/eCtsokn/ile9wqy7dggmugDSDhxQEpfqoM1m3alT/MLKJ6V74FDPSOkoQLhWJ9TO7kKipBH3AUBstIwJGya6P5mKe27g/4HHUoqQRdrPuthF3tcTzE4MvLZTiATY1LuHfJlc9T2BiFjMdm0CkofPB4fg40sca9ZkJqXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Vj7qO+M9OHkj0c1hCWo1cCgFJfYXcDMmsdV917ZGzrw=; b=d4KlPSMH4haPJ0Zd1bLxjiXpdGw7uduk9EOUnz9HS0Eh79+9UQajhQSNHe7C3v85VGUA6KeBzd33HbvIL7DsjgYwP4w0UrA4R2kPLoe5EGagdvuA58Rb6JfMSKICXVg6rLe1jQO8PfG8pJly1mmk681oD6kunc40MY1aWhEIBNyN2WFeGT+G9EUjSOFkic6Dp3+uCcyOzndMall6cE59neG9aa3eqjL/omxXbunxrvjIpLb+N/I/BSGXF/eHWxxtqEvVXT/cVS93055p4rNqgKkwC9JCtVRQHfPBd1JspOPJBOhEPbN+G7Gkh39ANIb31giLvFC9nVtNER5hyv9AEQ== 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=Vj7qO+M9OHkj0c1hCWo1cCgFJfYXcDMmsdV917ZGzrw=; b=OCNh9SU/be8qsxtGI4D9zEyStoHe3e3KCl+RNQtmwYzwDyvna1eV4/CVuuoBi2z5eey2HRjiON32+Zal4E73QP+NbN6Bj+DnjZ/AabriLC0FuCYvqs262c1fflRHb2m6VNtd6JlI97H/itcuv3Z26Ayshw8DovJM2BqHJKLcF/U= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MN2PR11MB4477.namprd11.prod.outlook.com (2603:10b6:208:17a::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5017.22; Thu, 24 Feb 2022 13:36:26 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::f515:598d:4160:b4b8]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::f515:598d:4160:b4b8%4]) with mapi id 15.20.5017.022; Thu, 24 Feb 2022 13:36:26 +0000 From: "Pascal Thubert (pthubert)" To: "ROLL WG (roll@ietf.org)" Thread-Topic: Asynchronous PDR-ACK procedure (Was: [Roll] review of dao-projection -22) Thread-Index: AdgJJwg/xVA9ZxIxQQavxeqMKc3l4AgSgTaA Date: Thu, 24 Feb 2022 13:36:10 +0000 Deferred-Delivery: Thu, 24 Feb 2022 13:35:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e040d2d1-eb41-4429-cea8-08d9f79aa7ce x-ms-traffictypediagnostic: MN2PR11MB4477:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: yFJ0BjmU3XlAIZXcc/l8ArZm24o4FwpwhMpIE7ZHSJElj23lJdzzltpwYa95kvtenhMc7k2jXV9dgyeTNi9KQ3bjUif/MpV/0hRQnBhDpd6M/WJ4rv8JpelXE5pUaqVO6tYEQU4CvdJLhq5Ct/z7kFuSumQxfAlqYECa2tKbApKB8AFwuYjgH5gG1RgetrcsUSea1f4E76wwbYROnVOiFDbcR65xKr8AwcCSTLBeSb9O5sAphCafg6iFr078z7A4SI/rk9YQKCjYOr6EUD58qrx1FR/rJeLV6oAoaD+qw/GTu86qTU+FubPZBrrdmHuXPWESKDJWREwwwVJ27D3NW8DRLpQnNs0ZgT+tHTR+OuB1CvddJp+iv+WmP9QplXV6vTGA8KzKx5F8gTBOHjyLnq7h+8t6ZfFMgXAmrLjm8yHa1HsumaZb9kLhgUEn+Y0BUGcm/Y1NgfBE6IhAlZW2zctYPEFIUHNGKRtACKBfcSFvw0saqh4fHJR0XkQZ+UfWdhL3QB0G6PvYIJKlpvDLwlNELF1FZzP01DTRAIcIs+g1eoy0b1jqPz4BMSPCQPxHDIBhNLGthQwIjcR0wik/w4qALAPE3vfjGVoieQ2QnuHxI6mCjFXeYkGumdtRhclfbzIFoEAQkWUewqEhk72qGjluXkWMNOMKG2t85dvdm+0cVbJsLER8Z+ZmEpgDlUtNW9prsW/3YDXpYpU0Jp83E4wRicgQZ4upqpftNq5QIcuBDvn4sdZ/G/eZ88gG83Os0Du+OQUciz0PAla6TcVOEtjgiKHFK6Im6ACnPB0RzWKOFqhzgAxNOsYu78AjDVOC x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB4881.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(9686003)(107886003)(166002)(122000001)(33656002)(38100700002)(55016003)(2906002)(186003)(83380400001)(38070700005)(30864003)(66446008)(66574015)(7696005)(66476007)(8676002)(66556008)(66946007)(76116006)(4326008)(6506007)(52536014)(8936002)(6666004)(6916009)(71200400001)(64756008)(966005)(508600001)(86362001)(316002)(53546011)(5660300002)(559001)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?exPT+ByZ9yKTmFDHBVSuKB3M5oSuB+kKHdPXqBviikK9ZpOh2a++Z3MMu1?= =?iso-8859-1?Q?JEMspsZROR8fZHIrnA6+hgFwBfEyWVsewKVAXdwnjgh5zrzawjvtt9wwwL?= =?iso-8859-1?Q?hUHbQBlZXTODkJLgBfJagD3upKRm/ZnwiV2KML2Bj7e9MNFDUOtJFrm+r4?= =?iso-8859-1?Q?uyKrKan7EeiBBnyEF3lWNED3gp921N2NttAmp1A5MOZiDScSEsXiiXPUBm?= =?iso-8859-1?Q?wWjTCqEHBjIfyfevSrgtTQ/nuhqVRf4wqNfDlOSCpEtTu7ieKhLfEI1wGW?= =?iso-8859-1?Q?pXHpfmQOm+NElUul++i/TeMUeqCXKgE070LbJUUVMjEty/LKfRdT1FRnFm?= =?iso-8859-1?Q?14YLTeKF4G0WfzZwlyFebqTXNjTdjnSzxPs4OCQ1YPLu18lIpUDmJJaxub?= =?iso-8859-1?Q?ncz+zFtN4Z2LqUgrdhQg7XaDd9pvn50CMURTB4h9f9vl2BUXuoEmv/Pn4W?= =?iso-8859-1?Q?G+DHvw0hCKdk7fIudMUasJGAt+9Qa0vOMjy+UUdf17IgoIqp7zrL5mINVD?= =?iso-8859-1?Q?i3ERKxyipscegDaBFJcIBTtug8jjJ1hJpqt3rjE8+HzVYCkIntTEnwoLJ8?= =?iso-8859-1?Q?qxvz2OBDFQsmYwJuyy+LePHcd2wtk24WrVuKUxnJ2823iJioOA6VVMk4fq?= =?iso-8859-1?Q?2RutL3tTQFhF3Qo+hv6GxsYZzdei370XAJDP7I3FpcAzTLEeLZFfnyygLh?= =?iso-8859-1?Q?wG1nPmqHS7pH4m7mKOPmTgj5ji1khVsftVzilnH2r0zkFHA3jgSQHc5Ars?= =?iso-8859-1?Q?ofVfopdduX+uPHcKpMz/tuCB02Ss0L6uSXPOO8Gzt3n/veqUAgkWAxdfC0?= =?iso-8859-1?Q?EgqvI22WV5WM2egoH52w8mLQSbkjcKfwujboVwYLbVnChlgmwT0eV+DVxp?= =?iso-8859-1?Q?nU5b3CZl+6lqJEuj6gNcqO+Cxveh+yXk5CMmopG7LDL2nShjwg79MuaRwT?= =?iso-8859-1?Q?aIk28vy/2hLB4Ac4UBPPpmF4cclVcGUKpI3hlE2QowG/nI9XXPs7LNT9WK?= =?iso-8859-1?Q?gl9Q3Nm6xmwZ/gKstrK/4eZCD/RgS2qvBoi7e4Gt6sp6cdOG97Q77E9M4n?= =?iso-8859-1?Q?YdWo69TBtNZatX2VNOAPWbWaWxwVSGr0nxaZ150LPxD/B8iCH+3wG/OOg+?= =?iso-8859-1?Q?BeD0BwcjC8+usEyhoNSTcoQIg6sEPTfTb1FmKrLT3d948MR0D2nQ4SxAU/?= =?iso-8859-1?Q?KvR4N9UvuZwwErOgB41ARNg9Py4dq4dR21hDSUtezyH77oFJmISDLZgDc6?= =?iso-8859-1?Q?qSsNFyujvIYSiMBz2iBbncA4v8aoRVTeFslkGK9fQcN4MN+l+6hxZtN3bN?= =?iso-8859-1?Q?/l3jrInCEQO5lmqshDxeySDti9TGZj7GzNrIiJC1GD2LV1SSs1Nd5ciJPx?= =?iso-8859-1?Q?rnRod6yX1W22K5UqHnUJhZJ3yiIoifnHPDgFx7lSHy4mJYm5XyuXELJlNh?= =?iso-8859-1?Q?JmVNn2NszMqKDhZXyRo/r4yXEzn2StfM8RheQdfuVewBnAHjXpBc+PCRVB?= =?iso-8859-1?Q?mvY0EEJMpwJeDjrzcvIpLPJ78jqADcSwhyXTdPez52L0Sw3Ke8ts0NRp8Z?= =?iso-8859-1?Q?PAP7TcYHQKDj7PKEaMx9pnjQRMxgKiOGOAo+CN6u5xEsFomgx+WijPTWyD?= =?iso-8859-1?Q?1BkwdrQc2Ky3Qisv50Vg46iBpPh++EHu/+Xf8CABtRMCZfCgMhTcxCOHza?= =?iso-8859-1?Q?l5O10JVdppNVkCsJ1hNgwoK9Cms4HOySX28eVF11D/rqRO2G3z8/vvhhE0?= =?iso-8859-1?Q?CJGnhOl8p29G13nF02Ox8kjz0=3D?= Content-Type: multipart/alternative; boundary="_000_CO1PR11MB488134F9D76184A3880CECBED83D9CO1PR11MB4881namp_" 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: e040d2d1-eb41-4429-cea8-08d9f79aa7ce X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2022 13:36:25.9977 (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: QyPTtHj4WymgI+EO8WfOGOQ/Cy6CAbpYhb7uAZ7LBeu0avHw6Yb7ZrpKt3c8ACTlWZEBc95QFs45NGX+nh3P7g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4477 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.17, xbe-rcd-002.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [Roll] Asynchronous PDR-ACK procedure (Was: review of dao-projection -22) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2022 13:36:37 -0000 --_000_CO1PR11MB488134F9D76184A3880CECBED83D9CO1PR11MB4881namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all This is now issue 12 in github https://github.com/roll-wg/dao-projection/is= sues/12 I see the power of an async PDR ack but have no use case for it. The questi= on was sent to the list a month ago and there was no suggestion; I propose = that we hold the odea for the day we need it and keep things ass is for now= . Objection? Keep safe; Pascal From: Pascal Thubert (pthubert) Sent: vendredi 14 janvier 2022 10:15 To: ROLL WG (roll@ietf.org) Cc: Li Zhao (liz3) Subject: Asynchronous PDR-ACK procedure (Was: [Roll] review of dao-projecti= on -22) Dear all: we had this thread as part of Li's review: > [Li] So PDR-ACK is for original PDR. And for maintain or tear down case, = Root should use No-Path P-DAO to terminate P-Route. Correct? [PT] yes: the NP DAO cleans the state in the network. It removes the Track.= The PDR ACK signals to the Ingress that it is being done and why. Maybe w= e need to explain that those 2 may be asynchronous to one another. I agree = with you that we can probably think this through a little more. * E.g., should the PDR ACK trigger a DCO (RFC 9009) ? * Could the PDR ack signal status that is not the death of the Track bu= t other stuff? Basically we need to clarify when the main Root sends an async PDR ACK, wha= t status go on there and what the reaction is by the Track Ingress based on= the status (including unknown). Comments welcome! Pascal From: Roll On Behalf Of Pascal Thubert (pthubert) Sent: vendredi 14 janvier 2022 9:18 To: Routing Over Low power and Lossy networks Subject: Re: [Roll] review of dao-projection -22 Hello Li: > [Li] Yes. It's more clear. So PDR-ACK is for original PDR. And for mainta= in or tear down case, Root should use No-Path P-DAO to terminate P-Route. C= orrect? [PT] yes: the NP DAO cleans the state in the network. It removes the Track.= The PDR ACK signals to the Ingress that it is being done and why. Maybe w= e need to explain that those 2 may be asynchronous to one another. I agree = with you that we can probably think this through a little more. E.g., shoul= d the PDR ACK trigger a DCO (RFC 9009) ? Could the PDR ack signal status th= at is not the death of the Track but other stuff? > [Li] Maybe it depends on implement of PCE? I'd like to keep the flexibil= ity because there is a user case for street lighting. Some controllers(Ingr= ess nodes) need to light the street lighting linearly with low-latency. [PT] sure, at the expense of complexity in signaling and processing in the = nodes. We need to be specific on the scenarios and status codes. The PDR f= orms a single Track since the TrackID is provided. Since signaling is invol= ved we need a story for all those questions: * What if there's a path to only a subset? Should the root form more th= an one track? * Or deny with your special status but then what can the source do afte= r that? Try all combinations? * What is the best path to one target cannot reach all targets but a lo= wer quality path can? Should we use that one? * Maybe there could be one main target and additional desirable targets= ? In that case the Root could form the track and indicate which of the opti= onal targets are effectively reachable via the track to the main target. > [Li] Some physical layer measurements such as RSSI/LQI have forward and r= everse direction. Can it indicate symmetrical? In layer 3, receiving DIO/NS messages from each other ind= icate symmetrical There's a nuance between bidir and symmetrical. Maybe the ping works but t= he link quality is very different in both directions. If so the Rank increm= ent computation would differ widely and we would need both sides. We need separate threads to solve these issues. Let me start them Keep safe! Pascal Pascal From: Roll > On Behalf = Of Li Zhao (liz3) Sent: vendredi 14 janvier 2022 2:51 To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] review of dao-projection -22 Hello Pascal, Please find my comments inline. Best regards, Li From: Roll > on behalf = of Pascal Thubert (pthubert) > Date: Friday, January 14, 2022 at 01:31 To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] review of dao-projection -22 Hello Li A great many thanks for your excellent review! Such are much needed at this= time. > [Li] -> Should it be ? > P-DAO 1 signals C=3D=3D>D=3D=3D>E-to-F,G > P-DAO 2 signals A=3D=3D>B=3D=3D>C-to-E,F,G [PT] correct, great catch! > [Li] -> What's the difference between negative status PDR-ACK and No-Path= P-DAO in section 6.5? And when to use asynchronous PDR-ACK? > In storing mode, root should use No-Path P-DAO to tear down T= rack from egress node. Is PDR-ACK still needed? > In non-storing mode, No-Path P-DAO to ingress node is also en= ough. > But the PDR-ACK Status field makes sense. Is it possible to a= dd this field in No-Path P-DAO? [PT] The no path DAO flow along the reverse path and cleans it; so the end= result would be that the Track is terminated as you figured. So yes, it co= uld be possible to add a status to the no-path DAO but remember that it is = a normal DAO not a completion (IOW not an ack). How could we justify a stat= us in all DAOs? I'm unclear why the async PDR ack is an issue. If the PDR c= an not be served, the track ingress already needs to support a PDR ack that= "terminates" a Track. To clarify that sentence we can say: " The main Root MAY indicate to the Track Ingress that the Track was termi= nated before its time and to do so, it MUST uses an asynchronous PDR-ACK with = an negative status. " Should that be more than a MAY? >>>> [Li] Yes. It's more clear. So PDR-ACK is for original PDR. And for mai= ntain or tear down case, Root should use No-Path P-DAO to terminate P-Route= . Correct? > [Li] -> Is it possible to remove the limitation? It's not flexible If PD= R can only carry one RTO. > For instance in figure 7, if node I requests P-Route to B&H t= ogether, Root can only push one Track I->A->B->H. Otherwise, Root may push = two Tracks I->A->B and I->F->G->H. > If Root cannot computer one Track to multiple RTO, it can res= ponse with a special PDR-ACK Status. [PT] This was done in the interest to simplicity, and yes we can rediscuss= that. We'd need to make decisions on partially successful use cases e.g.,: * What if there's a path to only a subset? Should the root form more th= an one track? * Or deny with your special status but then what can the source do afte= r that? Try all combinations? * What is the best path to one target cannot reach all targets but a lo= wer quality path can? Should we use that one? * Maybe there could be one main target and additional desirable targets= ? In that case the Root could form the track and indicate which of the opti= onal targets are effectively reachable via the track to the main target. >>>> [Li] Maybe it depends on implement of PCE? I'd like to keep the flexi= bility because there is a user case for street lighting. Some controllers(I= ngress nodes) need to light the street lighting linearly with low-latency. > [Li] -> Is it possible to add a flag to indicate the symmetry? Otherwise,= if A chooses B as sibling, but B doesn't choose A as sibling, Root may tre= at SIO from A as symmetry incorrectly when only receiving SIO from A. [PT] we used to have that (B Flag for bidir) but we removed it for simplifi= cation. I'm OK to add it back, but we still lake a good description of how = the node will know that the link is roughly symmetrical. >>>> [Li] Some physical layer measurements such as RSSI/LQI have forward an= d reverse direction. Can it indicate symmetrical? In layer 3, receiving DIO/NS messages from each other ind= icate symmetrical? > [Li] -> Confuse with this claim. Is it a MUST NOT if root wants to send n= otification to the requesting node when those changes happen. [PT] There's no protocol element to "send notification to the requesting no= de when those changes happen". So it's hard to say that the root MUST NOT d= o something that it cannot do. Reworded to " Note that there is no protocol element to notify to the requesting Tr= ack Ingress when changes happen deeper down the Track, so they are transp= arent to the Track Ingress. If the main Root cannot maintain an expected se= rvice level, then it needs to tear down the Track completely. " > [Li] -> Can you add some description for the collision case? E.g., node t= rusts itself than Root. [PT] I reworded to " = In a particular deployment where PDR are not used, a portion of the namespace can be administrati= vely delegated to the main Root, meaning that the main Root is authoritativ= e for assigning the TrackIDs for the Tracks it creates.. " [Li] -> Is there any difference between P-DAO-ACK and normal DAO-ACK? E.g.= any flags? Normally, root won't receive any DAO-ACK from nodes. Is it possible to add flag to distinguish P-DAO-ACK from DAO-ACK as P-DAO f= rom DAO. [PT] Done; I added a section for the P-DAO-ACK > [Li] -> Profile 0 is the Legacy support of [RPL] Non-Storing Mode. I= 'm confuse about "this enables to use Storing Mode to reduce the size of th= e Source Route Header in the most common LLN deployments." [PT] I really meant Profile 1 enables... Changing that. I guess that's it ! I submitted -23 with this, please have a look at https://www.ietf.org/rfcdi= ff?url2=3Ddraft-ietf-roll-dao-projection-23 Again many thanks! Pascal From: Roll > On Behalf = Of Li Zhao (liz3) Sent: mercredi 12 janvier 2022 10:51 To: Routing Over Low power and Lossy networks > Subject: [Roll] review of dao-projection -22 Hello Authors, Thanks for your great effort. The PDAO draft looks more clear and detailed.= Following is some concern: 3.5.2 Using Non-Storing Mode joining Tracks P-DAO 1 signals C=3D=3D>D=3D=3D>E-to-F,G P-DAO 2 signals A=3D=3D>B=3D=3D>C-to-C,F,G [Li] -> Should it be ? P-DAO 1 signals C=3D=3D>D=3D=3D>E-to-F,G P-DAO 2 signals A=3D=3D>B=3D=3D>C-to-E,F,G Otherwise RIBs in A cannot include destination to E. 4.1. Extending RFC 6550 To ensure that the PDR and P-DAO messages can flow at most times, it is REC= OMMENDED that the nodes involved in a Track =3D=3D=3Dmantain=3D=3D=3D multi= ple parents in the Main DODAG, advertise them all to the Root, and use them= in turn to retry similar packets. It is also RECOMMENDED that the Root use= s diverse source route paths to retry similar messages =3D=3D=3Dot=3D=3D=3D= the nodes in the Track.=B6 [Li] -> Typo for "mantain" and "ot"? 4.1.6. This specification defines a new flag "Projected Routes Support" (D). The DODAG Configuration option is copied unmodified from parents to childre= n. =3D=3D=3D=3Dxref target=3D'RFC6550'/>=3D=3D=3D=3D states that: [Li] -> Typo for "xref target=3D'RFC6550'/>". Why is flag named as "D"? Th= ere is no D in "Projected Routes Support"... 5.1 The Root may use an asynchronous PDR-ACK with an negative status to ind= icate that the Track was terminated before its time. [Li] -> What's the difference between negative status PDR-ACK and No-Path P= -DAO in section 6.5? And when to use asynchronous PDR-ACK? In storing mode, root should use No-Path P-DAO to tear down Track from egre= ss node. Is PDR-ACK still needed? In non-storing mode, No-Path P-DAO to ingress node is also enough. But the PDR-ACK Status field makes sense. Is it possible to add this field = in No-Path P-DAO? 5.1 One and only one RPL Target Option MUST be present in the message. [Li] -> Is it possible to remove the limitation? It's not flexible If PDR = can only carry one RTO. For instance in figure 7, if node I requests P-Route to B&H together, Root = can only push one Track I->A->B->H. Otherwise, Root may push two Tracks I->= A->B and I->F->G->H. If Root cannot computer one Track to multiple RTO, it can response with a s= pecial PDR-ACK Status. 5.4 only the router with the lowest Interface ID in its registered address = needs report the SIO, and the Root will assume symmetry. [Li] -> Is it possible to add a flag to indicate the symmetry? Otherwise, i= f A chooses B as sibling, but B doesn't choose A as sibling, Root may treat= SIO from A as symmetry incorrectly when only receiving SIO from A. 6.2 There is no notification to the requesting node when those changes hap= pen. [Li] -> Confuse with this claim. Is it a MUST NOT if root wants to send not= ification to the requesting node when those changes happen. 6.3 In a particular deployment where PDR are not used, the namespace can be= delegated to the main Root, which can assign the TrackIDs for the Tracks i= t creates without collision. [Li] -> Can you add some description for the collision case? E.g., node tru= sts itself than Root. 6.4.1 In both cases the Track Ingress is the owner of the Track, and it gen= erates the P-DAO-ACK when the installation is successful [Li] -> Is there any difference between P-DAO-ACK and normal DAO-ACK? E.g.= any flags? Normally, root won't receive any DAO-ACK from nodes. Is it possible to add flag to distinguish P-DAO-ACK from DAO-ACK as P-DAO f= rom DAO. 8 Profiles 0 and 1 are REQUIRED by all implementations that may be used in = LLNs; this enables to use Storing Mode to reduce the size of the Source Rou= te Header in the most common LLN deployments. [Li] -> Profile 0 is the Legacy support of [RPL] Non-Storing Mode. I'm= confuse about "this enables to use Storing Mode to reduce the size of the = Source Route Header in the most common LLN deployments." Best regards, Li --_000_CO1PR11MB488134F9D76184A3880CECBED83D9CO1PR11MB4881namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear all

 

This is now issue 12 in github https://git= hub.com/roll-wg/dao-projection/issues/12

 

I see the power of an async PDR ack but have no use case for= it. The question was sent to the list a month ago and there was no suggest= ion; I propose that we hold the odea for the day we need it and keep things ass is for now.

 

Objection?

 

Keep safe;

 

Pascal

 

 

From:= Pascal Thubert (pthubert)
Sent: vendredi 14 janvier 20= 22 10:15
To: ROLL WG (roll@ietf.org) = <roll@ietf.org>
Cc: Li Zhao (liz3) <liz3@= cisco.com>
Subject: Asynchronous PDR-AC= K procedure (Was: [Roll] review of dao-projection -22)

 

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

 

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

 

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

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

 

 

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

 

Comments welcome!

 

Pascal

 

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

 

Hello Li:

 

 

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

 

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

 

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

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

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

 

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

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

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

 

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

 

Keep safe!

 

Pascal

 

Pascal

 

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

 

Hello Pascal,

 

Please find my comments inline.

 

Best regards,

Li

 

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

Hello Li

 

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

 

> [Li] ->  Should it be ?

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

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

[PT] correct, great catch!

 

 

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

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

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

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

 

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

 

To clarify that sentence we can say:

“

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

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

   negative status.

“

Should that be more than a MAY?

 

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

 

 

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

>          &= nbsp;  For instance in figure 7, if node I requests P-Route to B&H= together, Root can only push one Track I->A->B->H. Otherwise, Roo= t may push two Tracks I->A->B and I->F->G->H.

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

 

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

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

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

 

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

 

 

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

 

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

 

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

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

 

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

 

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

 

“

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

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

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

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

“

 

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

 

[PT] I reworded to

“

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

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

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

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

“

 

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

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

 

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

 

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

 

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

 

I guess that’s it !

 

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

 

Again many thanks!

 

Pascal

 

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

 

Hello Authors,

 

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

 

3.5.2 Using Non-Storing Mode joining Tracks

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

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

 

   [Li] ->  Should it be ?

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

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

 

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

 

4.1. Extending RFC 6550

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

   

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

 

4.1.6.

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

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

 

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

 

 

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

 

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

In storing mode, root should = use No-Path P-DAO to tear down Track from egress node. Is PDR-ACK still neede= d?

In non-storing mode, No-Path = P-DAO to ingress node is also enough.

But the PDR-ACK Status field makes sense. Is it possible to add this field in No-Pat= h P-DAO?

 

 

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

 

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

For instance in figure 7, if = node I requests P-Route to B&H together, Root can only push one Track I= ->A->B->H. Otherwise, Root may push two Tracks I->A->B and I->F->G->H.

If Root cannot computer one T= rack to multiple RTO, it can response with a special PDR-ACK Status.

 

 

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

 

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

 

 

6.2  There is no notification to the requesting node wh= en those changes happen.

 

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

 

 

 

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

 

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

 

 

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

 

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

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

 

 

8 Profiles 0 and 1 are REQUIRED by all implementations that = may be used in LLNs; this enables to use Storing Mode to reduce the size of= the Source Route Header in the most common LLN deployments.

 

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

 

 

 

Best regards,

Li

 

 

 

 

 

 

 

 

 

 

--_000_CO1PR11MB488134F9D76184A3880CECBED83D9CO1PR11MB4881namp_-- From nobody Thu Feb 24 06:32:37 2022 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561733A07A7 for ; Thu, 24 Feb 2022 06:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.099 X-Spam-Level: X-Spam-Status: No, score=-7.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, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqZZnXnWL15I for ; Thu, 24 Feb 2022 06:32:28 -0800 (PST) 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 CBF523A079C for ; Thu, 24 Feb 2022 06:32:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id EAA2D392C2 for ; Thu, 24 Feb 2022 09:40:48 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QRbCPeLxyft0 for ; Thu, 24 Feb 2022 09:40:47 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id B937D392C0 for ; Thu, 24 Feb 2022 09:40:47 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1645713647; bh=y0MB9T1K2Jf3OhLjG3RlroKC/CMb2VKC0pcqYTPIG6c=; h=From:To:Subject:In-Reply-To:References:Date:From; b=0NV8HpSY2z9HFEs8zgJovUf5XqYF6IfTc0fU2fH5UFmItKnAum+h3vEn4vRrZq9yW L6J63/5GRc8nhfM+eblxhzoURT+Qk0lDS9n1Tkb0pOk1ELe3EW1us0Mrf+dWYbblu6 wTyVRYEWMuWHlKqn514j5WidGg8u7yKNVEtmIF5hASY8VHp3JJdf2sbSHNZTTdPjD+ c2eLa7U9NBuVp38Yl5r5RZ+cmch4I/J7hEh7k3LitSCnZPevNmhBnqGmj0XUTUM/97 /bbLfkmPL/E9OSFDORztFHlXyNU00/5UFeHM0zLYBqL8xeLxdsUYCAXEZdKmlLLZ06 taCfwyWRDPAXg== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0C7CE65 for ; Thu, 24 Feb 2022 09:32:10 -0500 (EST) 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 Archived-At: Subject: Re: [Roll] Asynchronous PDR-ACK procedure (Was: review of dao-projection -22) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2022 14:32:34 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Pascal Thubert \(pthubert\) wrote: > This is now issue 12 in github > https://github.com/roll-wg/dao-projection/issues/12 > I see the power of an async PDR ack but have no use case for it. The > question was sent to the list a month ago and there was no suggestion; > I propose that we hold the odea for the day we need it and keep things > ass is for now. Depends upon whether the root is sure that the PDR is actually supported by that node. Surely the node could also be out of resources and can't implement the PDR? =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----- iPMEAQEKAB0WIQSk7ZHEG9TCGBNASfm/sjw/rPYc8wUCYheW6QAKCRC/sjw/rPYc 81pXBgCgJXmE2lrUoqNnkXPPryms0p6tFVScVudXbVcercT1pHuFQD7/F9aybQkZ lzxwTRo2TQNCjxXI7VQVIw9uwQMlBUR3vF36b1XwmWy2gir3T1Z8mZUZX8oGuY3T 0/rx9OkycricZ8Fb7dc1fW9b1xF+lE6rfhy5PB2WnQJnm0qgfu6I3TFEFLQgfFi8 sZMteBDh9ILnfx5tWMuT/gHZWwHsDfkVdwhA2Mnw3CIY5SRrDbZdRUl23egXcGuf bPNWlWg= =NZZm -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Feb 24 06:35:59 2022 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5340D3A07B9 for ; Thu, 24 Feb 2022 06:35:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9rpGR1Szm2J for ; Thu, 24 Feb 2022 06:35:53 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F28153A07D5 for ; Thu, 24 Feb 2022 06:35:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 1CEFB391D6 for ; Thu, 24 Feb 2022 09:44:28 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id AOVtBqUDtDPn for ; Thu, 24 Feb 2022 09:44:26 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6EFAD391AA for ; Thu, 24 Feb 2022 09:44:26 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1645713866; bh=AC+ic7d8pWJTs3Mz314GAPfY7aSbkJ75ZPj/sB0SQAU=; h=From:To:Subject:In-Reply-To:References:Date:From; b=iLohkaBkoJrsPnsPH6BfGnzZIzLHUurRTf5WK+WIjwB6DV8W47NEnf7XUrN9V4RNj c0yUM5mjAVqMnWJvA1/h09fytv6ZsjI06pcxM7PNh8krpdGUTaxZWJ9m538V2pUutj GNUGQipTz1dHmMvUF/bu4UJHSttJ+7I2T5ARuW/h16AamAudv5jB82nOG6q72WUu20 TlXBsHhrhJieVYTjLaakjWqTu82NIfyH8NZ6jaUzpRms4elpbQDhEqHSM8mVVV/ZQp gXjvO2adYjbP5WAK7l9GyLU33r+aOoOHOQeYgzu76wpNV9LgJcm2LZ/+61HqvosD1Z jCC3FDT+GwtaA== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B352F65 for ; Thu, 24 Feb 2022 09:35:48 -0500 (EST) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: <12365.1645713130@localhost> References: <12365.1645713130@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] Asynchronous PDR-ACK procedure (Was: review of dao-projection -22) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2022 14:35:58 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Michael Richardson wrote: > Pascal Thubert \(pthubert\) > wrote: >> This is now issue 12 in github >> https://github.com/roll-wg/dao-projection/issues/12 >> I see the power of an async PDR ack but have no use case for it. The >> question was sent to the list a month ago and there was no suggestio= n; >> I propose that we hold the odea for the day we need it and keep thin= gs >> ass is for now. > Depends upon whether the root is sure that the PDR is actually > supported by that node. Surely the node could also be out of resourc= es > and can't implement the PDR? Ah, this is about the async-ness of this. I didn't understand that. =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----- iPMEAQEKAB0WIQSk7ZHEG9TCGBNASfm/sjw/rPYc8wUCYheXxAAKCRC/sjw/rPYc 8+2yBf4tEyRxeCeOJPXv78X6vSv5YxmoWntmwUsBk/kHEjarYUEXfiXUuub6evtH xbTxfe1kTd7ZacgwjqrtBKTKEKVo7+t2qn8+t5yD4Nd9wlMYZODcd4CMd2uZt81M rKTXWZXC3DJ0jhOsKREeCbweSjSm+wg/EgRwb+oxo2RuphWcBUQ9qGDvXseTRmF3 AzL2oUSs3uKe3j4JTHiwjydR9HCPmMrr1pds3gJBVwJcZZy98kV4HYnJZdc5oGS/ 07q9EuU= =s8BJ -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Feb 24 10:07:36 2022 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF6AB3A0D5A for ; Thu, 24 Feb 2022 10:07:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.596 X-Spam-Level: X-Spam-Status: No, score=-9.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=Mt6dLleH; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=a6RgSmoI 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 P3M4gj7MpL_d for ; Thu, 24 Feb 2022 10:07:29 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1A003A0D43 for ; Thu, 24 Feb 2022 10:07:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1774; q=dns/txt; s=iport; t=1645726049; x=1646935649; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=wyuEwHeBJbu8KkQkjHnwIQbl1lSMF9DyRyYbiepbC8U=; b=Mt6dLleHm3llv5Kay6Zg2uyazVgrwAZaowzqWtEzoFUg1t1JdoD3JHMQ mKjyPxtXtO2kfNiDCQtC7e9iKT1SP0ycVKLzqYf9imUGienfomu2pevvU oj0wgv4aQ0oV8UCFNZsUJWl2Y+8FusUobLlJWhrUJZIfZmmeFMAtH04SA I=; IronPort-PHdr: =?us-ascii?q?A9a23=3AyR9bbRywEUIQ5h3XCzPZngc9DxPP8534PQ8Qv?= =?us-ascii?q?5wgjb8GMqGu5I/rM0GX4/JxxETIUoPW57Mh6aLWvqnsVHZG7cOHt3YPI5BJX?= =?us-ascii?q?gUO3MMRmQFoCcWZCEr9efjtaSFyHMlLWFJ/uX+hNk0AE8flbFqUqXq3vlYv?= IronPort-Data: =?us-ascii?q?A9a23=3AcsNP16qANJlXYkTYO+PnA6p5p2NeBmILZxIvg?= =?us-ascii?q?KrLsJaIsI4StFCztgarIBnTOa7eYWOjLd4kPY7iph8PsJLQzdRlTgJtr31kE?= =?us-ascii?q?SNEpOPIVI+TRqvS04x+DSFioHqKZKzyU/GYRCwPZiKa9kfF3oTJ9yEmj/nSH?= =?us-ascii?q?uOkUYYoBwgoLeNaYHZ54f5cs7ZRbr5A2bBVMivV0T/Ai5S31GyNg1aYBlkpB?= =?us-ascii?q?5er83uDihhdVAQw5TTSbdgT1LPXeuJ84Jg3fcldJFOgKmVY83LTegrN8F251?= =?us-ascii?q?juxExYFENiplPPwdVcHB+SUNgmVgX0QUK+n6vRAjnVtieBga7xNMgEO1m7hc?= =?us-ascii?q?9NZkL2hsbSoVQc0NKDWhMwWUgJTFGd1OqguFLrvcCfj75TNlhOeG5fr67A0Z?= =?us-ascii?q?K0sBqUC/eJzKWBD6fJeLyoCBi1vLcreLKmTUOJggIEoK9PmedlZsXB7xjafB?= =?us-ascii?q?vEjKa0vip7ivbdwtArcTOgXdRoGW/ckVA=3D=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AGYX8cqAimEOtRtLlHegAsceALOsnbusQ8z?= =?us-ascii?q?AXPh9KKCC9I/b3qynxppsmPEfP+UkssQIb6K690c67MD3hHP9OkMYs1NKZPD?= =?us-ascii?q?UO11HYVL2LY+HZskbd8kHFh4tgPOJbAtRD4b7LfBlHZKTBkXOF+r8bqbHtms?= =?us-ascii?q?3F9ISurUuFDzsaFp2IhD0JbTpzZ3cGPTWucqBJcqZ0iPA3wwaISDAyVICWF3?= =?us-ascii?q?MFV+/Mq5ngj5T9eyMLABYh9U2nkS6owKSSKWnZ4j4uFxd0hZsy+2nMlAL0oo?= =?us-ascii?q?+5teug9xPa32jPq7xLhdrazMdZDsDksLlXFtyssHfrWG1SYczHgNkHmpDp1L?= =?us-ascii?q?/sqqiLn/4UBbU315oWRBDtnfKi4Xi57N9k0Q6S9bbRuwqSnSW+fkNgNyKE7r?= =?us-ascii?q?gpLycwLCEbzYtBOetwrhGknosSAhXakCvn4d/UExlsi0qvuHIn1fUelnpFTO?= =?us-ascii?q?IlGfVsRKEkjQto+a07bWnHAUEcYZ5TJdCZ4OwTfUKRbnjfsGUqyNuwXm4rFh?= =?us-ascii?q?PDRkQZoMSa3zVfgXg8liIjtYAit2ZF8Ih4R4hP5uzCPKgtnLZSTtUOZaY4AO?= =?us-ascii?q?saW8O4BmHEXBqJOmOPJlbsEr0BJhv22tPKyaRw4PvvdI0DzZM0lpiEWFREtX?= =?us-ascii?q?Qqc0arEsGK1I0jyGGFfIx8Z0Wa9ihz3ekNhlSnfsuYDcSqciFbr/ed?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BVAAByHvlh/5ldJa1aHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUYHAQELAYFRVgd3WjcxhEmDRwOEWWCFDoMCA5skgS6BJQN?= =?us-ascii?q?UCwEBAQ0BATUMBAEBghCCdQIXg0gCJTQJDgECBAEBARIBAQUBAQECAQYEgQk?= =?us-ascii?q?ThWgNhkIBAQEBAxIREQwBATgLBAIBCBEEAQEBAgImAgICMBUICAIEEwgagmO?= =?us-ascii?q?CZQMuAQ6iKwGBOgKKH3qBMYEBgggBAQYEBIUNGII3AwaBECoBgw2EHocHJxy?= =?us-ascii?q?BSUSBWIJnPoJjAgKBQCCDFjeCLpIhgTsGIAJ2MxM1ljOqIQqDRosBlHoVqAe?= =?us-ascii?q?WSo0PlC+FBAIEAgQFAg4BAQaBYTyBWXAVO4JpURkPjiCDcYpedAI2AgYBCgE?= =?us-ascii?q?BAwmNTAEB?= X-IronPort-AV: E=Sophos;i="5.88,333,1635206400"; d="scan'208";a="974606160" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Feb 2022 18:07:28 +0000 Received: from mail.cisco.com (xbe-aln-002.cisco.com [173.36.7.17]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 21OI7S2n014901 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for ; Thu, 24 Feb 2022 18:07:28 GMT Received: from xfe-rcd-004.cisco.com (173.37.227.252) by xbe-aln-002.cisco.com (173.36.7.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Thu, 24 Feb 2022 12:07:27 -0600 Received: from xfe-rcd-002.cisco.com (173.37.227.250) by xfe-rcd-004.cisco.com (173.37.227.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Thu, 24 Feb 2022 12:07:27 -0600 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-002.cisco.com (173.37.227.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Thu, 24 Feb 2022 12:07:27 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KQ9XpBvuSi6VqHeZvxZg9SWgN1FZbQQm0xfPLvMcOKwV0y+Ni0gzRPtKPywi95ROBG1QEXoBhHl2vjZ8LUx7ZO/IiPkvOZoWcf12w7D+0tVWHtRu1+PrWM0+ZWSXXpVZF+bvyqYg5Q8enBU686fD22F2WwuiU/Lgie7OlSyiIMUfF0PXzECsCNWcZzg5AEJFrftCVBJubjIqqMW5KrAUpYg0PU0kzd2ppTx0EaxXiGZ5r6ckwS/k3MwRswyk+QssJqousRJZegJsC/WvhukGvr4I2HwEZDEYvhpf+kfazc1pyI960zL8A4VWUCr/QcdDwDyGzoHSNzUdZ6WEE4L8AA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=wyuEwHeBJbu8KkQkjHnwIQbl1lSMF9DyRyYbiepbC8U=; b=USTZs+xgpWWpea/RrrPMC4D2J3XOONwhlfP6A80NAgVlcG8LMCX159U7pALbtZ/8iUJhcx1GtokBBCHZtd6gIVyuL5wqInEoMQySKNRM8HrpHf03PuVZNmE3SEYMztBtezM+iu0MEO6dmh6ENf8zj2utEvRr15Na3/+gvKs7+ZsNfRsFYczVa0SSqnS5eoaWr4r9JhQTapq3lsSxMWEhqGj5DhtJQy5FkyQ0sc+4ngUnvBZtlLVU9Vh6bfsXyrGKb13hLGvVhtGdZxeorwLlmVQUvLknoOk4fWcjVCFUOq5xX5JSIXWRajcNtfsAFUKx2gYfixfIp3riIfmUrnmLAg== 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=wyuEwHeBJbu8KkQkjHnwIQbl1lSMF9DyRyYbiepbC8U=; b=a6RgSmoIcn9WlZugdW2NgAnh0RVmFuUhXVprmWk/Bb4C6ISq7B4enYoxrMhBoE4qflYBWmiUxfHkGnf8Z8F2gWyKi6UCTML7qUEie7Cb0j1/0zk0ibYwQuSwgMcVmRNGKjTJ7jiDYz9VzPVz9/43blax6OzIRFZ6SHioSzEovDA= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by CY4PR1101MB2261.namprd11.prod.outlook.com (2603:10b6:910:1f::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4995.24; Thu, 24 Feb 2022 18:07:26 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::f515:598d:4160:b4b8]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::f515:598d:4160:b4b8%4]) with mapi id 15.20.5017.022; Thu, 24 Feb 2022 18:07:26 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Asynchronous PDR-ACK procedure (Was: review of dao-projection -22) Thread-Index: AQHYKYttjeYCiLTrFEalkY61eWIP/qyixIkAgAA6e0A= Date: Thu, 24 Feb 2022 18:07:12 +0000 Deferred-Delivery: Thu, 24 Feb 2022 18:06:15 +0000 Message-ID: References: <12365.1645713130@localhost> <13610.1645713348@localhost> In-Reply-To: <13610.1645713348@localhost> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9379915b-d360-44bc-615e-08d9f7c083a3 x-ms-traffictypediagnostic: CY4PR1101MB2261:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7sf6e0PSaDOdqdn+84bW1IDvfqWiXwmEgage5yPr52mBpiGOTPpX1vXN48pW7gVgK4S2yEfbNu4RX8yFlaPPJ87TR5G7slRVgq9F5X38imR7FF2Am2Sk153sPxSexIYQkOv3sT7H9sxtjYrYgKih7hGpiq8bxUR4xJXK0xBNdI1cPB5ua7xklGr+1dvitGkGRE5iafvj3WEzOX7vCnC8dTL07y+ZJldW+97c5zC6iV+KBqzbgYmHTx8VjLVVzXGN7twQe93BwitnYkxwRmyskhd2Zjzy+vEC5rWF+UODkU/wVkrYOluh6UHONV/6GKFmdLy9qUvtCNL+BUFxrBiyRx2bBQbKuU050D7nCgDTJV2w7rWPe+CcrH3A+8QTV5KieQWVh8KI7NkytNOT8BIw/VS5Dv4vkrsW5x1ZS94touYeC0YgrJAjLaP2vhV89prpfNMuJtFZDgNiyLAJWD86P48bjsDtrCbL6O48bOQKY+kZKmVm4s7lU6YM3lRI0fcPl0ZJvFpbsGxG53LSlNDq857OYgseGjuNuK8dfq6F5T/mZrFAIESPqlSTlYK7hoYH6j0ETT3EZfYTtrz7YxX4GlJcz0ixaYQVlzt/XMltPS9MyvXg+xAUESA7g2H2noLwFYA9pS6N+8H31vI7K7DOxyM7eN2Jy7GpdLfifiM9BGcTukwFUEcAxvnc+idhzPoVwTpDGC9I2QDHkF1ibT5L1jkQSq038f98w0wJMRgIcV0/jI6jrm/KkDhqLEaJk444d3DAPUPPbhAdFagNnHXD7megaoF4ytAIfd2tgDc9cpY= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB4881.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(186003)(53546011)(508600001)(71200400001)(9686003)(6666004)(64756008)(66446008)(66476007)(66946007)(966005)(6916009)(316002)(76116006)(7696005)(66556008)(86362001)(122000001)(8676002)(6506007)(66574015)(83380400001)(52536014)(38100700002)(55016003)(5660300002)(33656002)(2906002)(38070700005)(8936002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?OEdZbW5EeUx1ZisyU2hCN3ZvWGRHbEU5ZmpSejUrdElqYlUvUnp0Yy9QYmJ5?= =?utf-8?B?S1U5cmpmM3dvT21DRGFRY2FNMW45cHh5bGFpOGRWWjQ5TFBLWGFmTWlUUVE0?= =?utf-8?B?VHFKZVJNSkF0RDRRajBCNkI0WEo3N0dVRjQzdGhnbW1DOTF1QjFkRi8yZy9w?= =?utf-8?B?QUJRU0JMcFJ2U1RRRUkxTDZFa2taNmlpZmwzTHlDSDZqZlYvYTJLQ1F2MzQr?= =?utf-8?B?QS9MZHE5ckNGbm5IalhHNkg1U3R2RStxRE9qOWlHc0dSUFV2WkRtaXFTRTRH?= =?utf-8?B?R3RDTWtyWUk5b21paVZnWlhtc2VCSUdXSnZuUWdVcGU4NjJKNkZvK2piMTVG?= =?utf-8?B?M3RkdWtlWHFoOFR1NGhVWHFFUCtIWTJIR2VKS0ZYcVV5QzM4Q3l5OXVZY2Zq?= =?utf-8?B?QW1tTDduNGtDQTg5dnA5M0VzM0g3ZU9MRUd5enVDN2xJdklEVmNvbjVFY0pp?= =?utf-8?B?QkNJR09KTlh4eWRMZ0YxMWdmNENKMUFkK0dCOEl0RmVnZ0VZcG9xWGhzQndL?= =?utf-8?B?ci9KSENCODJTaFV0bjR6cWRONGN0UVgvT1lzeGhXT0ZvbHRUQjNQdUdlM3Yy?= =?utf-8?B?RFFnSXBSd1EvZ2NzcUNOdmNTNEJ4cnhnVUNYQUVRUlQwbHZ1ZDRLQzdJR2hv?= =?utf-8?B?T21LcWIxOU9uTHF5SGFOZmhKcEZJZEFTU0k0UURWTTdwbGpiS0I3dklqSThx?= =?utf-8?B?QXB3NHRmU3JCQk41K3NWWHpFSzFaSjdCWElNT3VEMmw4UjRWT0N1dFpwVWUy?= =?utf-8?B?VStQWTF2djc3TkEyQUpTa3MwRTNxd3FPSGx4Uy9jemZHS3p1VUhIMkprSWdj?= =?utf-8?B?Mjk2OElKZURVb1VCZlVOS2lLZ0pvOExJWGZGN3E2REF3WDRKZXY3cUFtNzZL?= =?utf-8?B?UzFib2lMci8zdDZFMStVRTcycGFiSEFRYzU3UE5PWUY3TkJ0ZDBvclJVS2FC?= =?utf-8?B?VVBER0lQWjVEa21uTjlBT2JiOER5NTA4d0t6MDh4dTVUeDJ6VndhZ2RicFAw?= =?utf-8?B?YnJXbHFJMFJsa0VMWHZjN3p5NlNVUmdKNzNKdm0wRXpCWjNHcmRzM3g1WWdP?= =?utf-8?B?cUhVaWFJQkhPYzBjTHovTkozYXJvUXVCenJOOFk0dG5wbms0UU55R3FOMkI4?= =?utf-8?B?Ymw5VnF1QnNBSFFqZFA3djM2SE5BMHFtNUdjbFFSbzh5dEdCU0t3bmlJMWtQ?= =?utf-8?B?cnpyM1RkQ1NheDU0ZUpWUUVUZkl4Y3VLN1hOTkhHTVl5QWtyL1QwTjVUdkNL?= =?utf-8?B?WGs4Y2w2S3U4UzJOTkhFV0hEazF2cGVLdkJ6K044SkR5WGtEQVVyaW1YblJv?= =?utf-8?B?UUI5UHkvRUZrNFA5dWxCQklEcG1LcllWM0J6QktRNXVtK2J6Sms0OGQvTEZP?= =?utf-8?B?b25XcVpvSXdZK3JsVkZIQVduYUF3cTVqS2wwM2wxbU1XYW1OSndRNDl1dkFZ?= =?utf-8?B?dE80dFpWbHUzdkNGcHFEbytHbFA0MTdQMVdGd2VaOFdYWXY1cjJhczVrUXdW?= =?utf-8?B?bFgxMk1UWHZCT1Yxc3ZjeEMxMkRCNWIyaXpEdFRJckZkc2xuSTJNTjhJcVVR?= =?utf-8?B?czNTYTJGVUtFeXZWM3FlaXEwUDQ2UjNIME1XT3pYZDJMeVE1akRIUWVUS1Mr?= =?utf-8?B?Z1doRjhscVRjWVpaaEN0TGtwRUZqQUtXS29uSXAyT2U0MFE0bHdtT3pmMStK?= =?utf-8?B?RStkVWJXOWVIU3dtaFlnWkhsVkprQk0rdFFJNjRNMUhsUFRod3EyTGoyci8r?= =?utf-8?B?L3dEWW0vSkhGK1J3S0dpY3NncWpyMHZYN3M0WnNleDZoNzZPREtSblpveWFD?= =?utf-8?B?WjBwZWJQT0U2UWxvRzNhbFoweHlaam1seEVLc01DM2NYeEhQbUVEU2tUOUpP?= =?utf-8?B?NkZhOXBBT3MvbGJCdE1nanRIYjNnSCtSZkJvTWtONGcxU0FDUzdVeVFEZEk2?= =?utf-8?B?cGtSYmJ1RytwMWlibTgrZndYcytJVXlkT2pabUFvSkhPVzhsTGY4WEFGUld5?= =?utf-8?B?WmMvN3NDRXZYV3BObHd4T282cHpnbWZXdkozKytnbTh1cHEyNlJucHlXRmUz?= =?utf-8?B?RzIzM3VJSjcrOVcrOUlGbzlSdFpXMHc3WXVWL3YzTkVmcjVjTnRvZUVCWFcv?= =?utf-8?B?L2pzd2lYR2p1QUh4bFZZWW04ZDM0OXZlMVlrU3JVQkhkdC9tQzQwOTZocHBw?= =?utf-8?B?RTh0Q3F0UUpiQlBIeTdUNUFFb3Ivd0JSU01uOVppQ1I4dEQxTkZrTVFpYzZq?= =?utf-8?B?eUV1aWFCVmQva3FQYklaZzQ4M2FBPT0=?= 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: 9379915b-d360-44bc-615e-08d9f7c083a3 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2022 18:07:26.2846 (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: w3yaTOAUglZ8rcwdQMScH+r4GDHPLnKKWP1tZqPgw9tVzlhHgCy++AYKc1r61XA8ILiHC/u2ANgVWRWcmZYaWw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1101MB2261 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.17, xbe-aln-002.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [Roll] Asynchronous PDR-ACK procedure (Was: review of dao-projection -22) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2022 18:07:35 -0000 WWVwIDopDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUm9sbCA8cm9s bC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgTWljaGFlbCBSaWNoYXJkc29uDQo+IFNl bnQ6IGpldWRpIDI0IGbDqXZyaWVyIDIwMjIgMTU6MzYNCj4gVG86IFJvdXRpbmcgT3ZlciBMb3cg cG93ZXIgYW5kIExvc3N5IG5ldHdvcmtzIDxyb2xsQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTog W1JvbGxdIEFzeW5jaHJvbm91cyBQRFItQUNLIHByb2NlZHVyZSAoV2FzOiByZXZpZXcgb2YgZGFv LQ0KPiBwcm9qZWN0aW9uIC0yMikNCj4gDQo+IA0KPiBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitp ZXRmQHNhbmRlbG1hbi5jYT4gd3JvdGU6DQo+IA0KPiANCj4gICAgID4gUGFzY2FsIFRodWJlcnQg XChwdGh1YmVydFwpIDxwdGh1YmVydD00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZz4NCj4gICAg ID4gd3JvdGU6DQo+ICAgICA+PiBUaGlzIGlzIG5vdyBpc3N1ZSAxMiBpbiBnaXRodWINCj4gICAg ID4+IGh0dHBzOi8vZ2l0aHViLmNvbS9yb2xsLXdnL2Rhby1wcm9qZWN0aW9uL2lzc3Vlcy8xMg0K PiANCj4gICAgID4+IEkgc2VlIHRoZSBwb3dlciBvZiBhbiBhc3luYyBQRFIgYWNrIGJ1dCBoYXZl IG5vIHVzZSBjYXNlIGZvciBpdC4NCj4gVGhlDQo+ICAgICA+PiBxdWVzdGlvbiB3YXMgc2VudCB0 byB0aGUgbGlzdCBhIG1vbnRoIGFnbyBhbmQgdGhlcmUgd2FzIG5vDQo+IHN1Z2dlc3Rpb247DQo+ ICAgICA+PiBJIHByb3Bvc2UgdGhhdCB3ZSBob2xkIHRoZSBvZGVhIGZvciB0aGUgZGF5IHdlIG5l ZWQgaXQgYW5kIGtlZXANCj4gdGhpbmdzDQo+ICAgICA+PiBhc3MgaXMgZm9yIG5vdy4NCj4gDQo+ ICAgICA+IERlcGVuZHMgdXBvbiB3aGV0aGVyIHRoZSByb290IGlzIHN1cmUgdGhhdCB0aGUgUERS IGlzIGFjdHVhbGx5DQo+ICAgICA+IHN1cHBvcnRlZCBieSB0aGF0IG5vZGUuICBTdXJlbHkgdGhl IG5vZGUgY291bGQgYWxzbyBiZSBvdXQgb2YNCj4gcmVzb3VyY2VzDQo+ICAgICA+IGFuZCBjYW4n dCBpbXBsZW1lbnQgdGhlIFBEUj8NCj4gDQo+IEFoLCB0aGlzIGlzIGFib3V0IHRoZSBhc3luYy1u ZXNzIG9mIHRoaXMuDQo+IEkgZGlkbid0IHVuZGVyc3RhbmQgdGhhdC4NCj4gDQo+IC0tDQo+IE1p Y2hhZWwgUmljaGFyZHNvbiA8bWNyK0lFVEZAc2FuZGVsbWFuLmNhPiAgIC4gbyBPICggSVB2NiBJ w7hUIGNvbnN1bHRpbmcgKQ0KPiAgICAgICAgICAgIFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3JrcyBJ bmMsIE90dGF3YSBhbmQgV29ybGR3aWRlDQo+IA0KPiANCj4gDQoNCg== From nobody Thu Feb 24 17:11:08 2022 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 343D53A10AC for ; Thu, 24 Feb 2022 17:10:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.585 X-Spam-Level: X-Spam-Status: No, score=-14.585 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=IfLhrOho; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=a3FAQhgK 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 v7v6LJW-ki9l for ; Thu, 24 Feb 2022 17:10:26 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CE473A0FCE for ; Thu, 24 Feb 2022 17:10:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37099; q=dns/txt; s=iport; t=1645751423; x=1646961023; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=o0ki+8ETu0dPXsvmodBvuylGnmjDSh96fj9AG3s2aaU=; b=IfLhrOhop3EAh2TMKlfi5in2F3bNTPzQIZpHbza86WUDC8PDG6GXDJQH 9gHRslJt6/mUat05S3Tk5S+z5N1jaaCLRlhjCtB0Se1xoi+iRQjPTRx8j ZonOD0QA7Cq9ziKveJU+jzlLGWuIlYYAfBvD99Av9O8wgi40qYxHzcehG 8=; IronPort-PHdr: =?us-ascii?q?A9a23=3A8xMjxRX1abm53wPSg+40oTltX7jV8K36AWYlg?= =?us-ascii?q?6HPw5pCcaWmqpLlOkGXpfBgl0TAUoiT7fVYw/HXvKbtVS1lg96BvXkOfYYKW?= =?us-ascii?q?0oDjsMbzAAlCdSOXEv8KvOiZicmHcNEAVli+XzzMUVcFMvkIVPIpXjn5j8JE?= =?us-ascii?q?RK5Pg1wdYzI?= IronPort-Data: =?us-ascii?q?A9a23=3A19L9jq4aq9OgN17yqyc9SAxRtC/FchMFZxGqf?= =?us-ascii?q?qrLsTDasY5as4F+vmseUWiPa/reYWLwf4t+b4y+ph4F6JOAxtFrHABvqX1kZ?= =?us-ascii?q?n8b8sCt6fZ1gavT04J+FiBIJa5ex512huLocYZkHhcwmj/3auK79SMkjPnRL?= =?us-ascii?q?lbBILes1h5ZFFcMpBgJ0XqPq8Zh6mJZqYDR7zGl4LsekOWHULOR4AOYB0pPg?= =?us-ascii?q?061RLyDi9yp0N8QlgRWifmmJzYynVFNZH4UDfnZw3cV3uBp8uCGq+brlNlV/?= =?us-ascii?q?0vD9BsrT9iiiLu+LgsBQ6XZOk6FjX8+t6qK20cZ4HdtlPdgcqNBNC+7iB3R9?= =?us-ascii?q?zx14NFMp8eYQgYyNaqKk+MYO/VdO3AvbPwdpeWXeBBTtuTWlSUqaUDE2fJqC?= =?us-ascii?q?Gk3MJEWvOFtDglzGVYwQNwWRgqIi+Tzy7WhR6wwwM8iN8LseogYvxldIfjiJ?= =?us-ascii?q?a5Oafj+r2/iv7e0BAsNu/0=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AcTd7uq57uoFORTmhUQPXwXeBI+orL9Y04l?= =?us-ascii?q?Q7vn2ZFiY1TiXIra6TdaoguiMc0AxhJE3I6urwR5VoIEmsuaKdhLNwAV7MZn?= =?us-ascii?q?ifhILFFvAG0WKm+UycJ8SczJ8T6U4DSdkENDSYNzET5qyWjHjaYrQdKZu8gd?= =?us-ascii?q?qVbIzlvhBQpHRRGthdBnBCe2Cm+yNNNW17LKt8MKDZyttMpjKmd3hSRN+8HG?= =?us-ascii?q?M5U+/KoMCOvI76YDYdbiRXpjWmvHeN0vrXAhKY1hARX3dk2rE561XIlAT/++?= =?us-ascii?q?GKr+y78BnBzGXehq4m2ecJi+EzRPBkuPJlaAkEuTzYIbiJnIfy+Azdldvfq2?= =?us-ascii?q?rCVuO85CvIcf4DrU85NVvF3ycFkzOQoQrGrUWSkGNxRRDY0JfErPVQMbsYuW?= =?us-ascii?q?sRSGqo12Mw+N57y65FxGSfqt5eCg7Bhj3045zSWwhtjVfcmwtorQc/tQ0XbW?= =?us-ascii?q?IlUs4YkWXfxjIgLL4QWCbhrIw3GuhnC8/RoP5QbFOBdnjc+m1i2salUHg/Fg?= =?us-ascii?q?qPBhFqgL3Z7xFG2HRii0cIzs0WmXkNsJo7Vplf/uzBdqBljqtHQMMaZb90QO?= =?us-ascii?q?0BXcy0AGrQRg+kChPZHX33UKUcf37doZ/+57s4oOmsZZwT1ZM33I/MVVtJ3F?= =?us-ascii?q?RCDX4Gyff+q6Gj3iq9MllVBw6duf22z6IJz4HBeA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A/BgDrHvlh/5tdJa1aHgErCwYMIoF?= =?us-ascii?q?agSExVgd3WjcxiA4CA4U5hQ6DAgOBE48ngjGIOYEuFIERA1QLAQEBDQEBNwo?= =?us-ascii?q?EAQGFBQKDXwIlNAkOAQIEAQEBEgEBBQEBAQIBBgSBCROFOwEEKA2GQgEBAQE?= =?us-ascii?q?DDAYVBhMBASUTDwIBCBEDAQEBIQEGBzIUCQgBAQQBEggagmOCDlcDLgEOoi0?= =?us-ascii?q?BgToCih94gQEygQGCCAEBBgQEhQ0YgjcDBoE6gw6CflRKhwkngimBFAFDVYE?= =?us-ascii?q?RSjc+gmMCAoEkHAQcHgYHCYMZgi6RNiVGDmANNg4CIAIrAyseNwoOAQISBw8?= =?us-ascii?q?fCxF/AZ5GjXKSYQYEg0aLAYsdiV0VlDCTV5ZKIIxvlCcXCwuEXwIEAgQFAg4?= =?us-ascii?q?BAQaBYTyBWXCBboFLURkPhWuCX4YNgzqFFIVKdAI2AgYLAQEDCYsGB4I/AQE?= X-IronPort-AV: E=Sophos;i="5.88,333,1635206400"; d="scan'208,217";a="999935281" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Feb 2022 01:10:21 +0000 Received: from mail.cisco.com (xbe-rcd-003.cisco.com [173.37.102.18]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 21P1AKpi026000 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for ; Fri, 25 Feb 2022 01:10:21 GMT Received: from xfe-rtp-001.cisco.com (64.101.210.231) by xbe-rcd-003.cisco.com (173.37.102.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Thu, 24 Feb 2022 19:10:02 -0600 Received: from xfe-rtp-002.cisco.com (64.101.210.232) by xfe-rtp-001.cisco.com (64.101.210.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Thu, 24 Feb 2022 20:10:01 -0500 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-002.cisco.com (64.101.210.232) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Thu, 24 Feb 2022 20:10:01 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UOYxQSUK7CskkbfbBHZmteORTLo9XEa3Z2vmtOLSi2pbshDRu9FJLlaricXtrYMsDKOpbaA5PvA8QJ7rDaoXMjKo7V0sBDEUBGI37pgBWbEsfHSFPoxpetskPjqHKmTI70aFpfCXoykVAE5gln+K01GsyXY5dZR0k7OBiD2V4KrryM+6FQe/4BYkuJuYcCREMVrk5wQ3nGkYfooKxiYI2MdmcuohMz27MOFGl8pgZsozEA4/1jpecuI/nI4rmk7cQ+DVtE+WayB9jsFNa/bWvIflLuqboJVyjID29smbP6KoVx21HjP1GtZUv4ELcE2bFltkxVz5NanOw0vkKq51Yw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=QGyMNnRqmySFYpQ3jLOS/k2FK+6oIhEPwEl2rMYr/bE=; b=KaHyUX9ZKICn2WebqypOp1mgNUcXNz9nIpZE/Q88Kyb+A9kZCiBWwMFBrMzRgedf7nFKV2HA+MUf/s67SyaHJPrL3YzZyDrOGRIteuy0eQefH7o38ST4LkdWjm4KrfLWYF2MpyGzjzf8BM3SKbUkFNi4ZsgTunMkyvhs9Jb8PZfLmn+8e3fXr2WsBNvt1af+6gLR0Pu32r87SafO42DxVFH/PBCDaWJMqZ2XMfijihOtcE3G9slOTM6e8qhyK5+CJxxMA04RdnJRNv06AqkcjviKlG/n8r7kysDZaKi5JfCZm2TT5ocby3uMYCcCxYa9aHi7ebqmtBxaWq5R15PcHQ== 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=QGyMNnRqmySFYpQ3jLOS/k2FK+6oIhEPwEl2rMYr/bE=; b=a3FAQhgK3niAU81p5EXSKsPoIvRhuSpYPCmnFDwQkfHKBSdRvSrmKxlG9DlL2dWZIrTZpcyE4Zcu0YCCw/1ECvqx1KykP35lqQxsrnQXjRbyZ9XdoWRTowgofTJILK6OPNNUDbAPoduCQxTzgWcDqr121Gm2g3PaffAH4eqr6qg= Received: from PH0PR11MB4919.namprd11.prod.outlook.com (2603:10b6:510:34::12) by DM5PR11MB1564.namprd11.prod.outlook.com (2603:10b6:4:d::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5017.22; Fri, 25 Feb 2022 01:09:59 +0000 Received: from PH0PR11MB4919.namprd11.prod.outlook.com ([fe80::6d55:7f2e:6f4:2d4a]) by PH0PR11MB4919.namprd11.prod.outlook.com ([fe80::6d55:7f2e:6f4:2d4a%4]) with mapi id 15.20.5017.024; Fri, 25 Feb 2022 01:09:59 +0000 From: "Li Zhao (liz3)" To: "Pascal Thubert (pthubert)" , "ROLL WG (roll@ietf.org)" Thread-Topic: Reporting Links: Bidirectional vs Symmetrical (Was: review of dao-projection -22) Thread-Index: AdgpcUWc8mKMuUnWSsS5Bax1TjHaYwAcilJN Date: Fri, 25 Feb 2022 01:09:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5d57773d-75e0-4eb1-7633-08d9f7fb8b52 x-ms-traffictypediagnostic: DM5PR11MB1564:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: tzx0zXo0GQbWOrszhInzUnDBoiQkEqKNKWX82NU+D68MDoZyjDNPNlhJB9kBuQOGgoeTRoC5XR+GDjVcMu6j+U1CbK2XVT1oj82ZlZMmjz0vhlTQljEK2Uv+CLSTKcsSjj8CevyHhPU3CKCrIb5iGKjANWAbr0/2OE5bNskZ5e9wEsZ/IXP/dMaUMFhAdysiWC9To9z5iC0TCIupOC/213R3GOysH+8pwe3UVIPRLEOYJngP/l2uUrSG09xHfGwqJdKRuqrusI+jGKvoZFc5ZVtUahIcsxc5fuY+Z2jegmjEbAEBVkU1qarOTlycdpt/hhhUb0glwJo1reonurvq8+6guNzMskWhi8+HYjr4muOgPa2UYyG3nmaou6b8AhGEOUBtFuB7nwi/oa68t464Tnj/BWHbdE5Jd0EVAx2mWWBvkD0dEVbIKyAe0NNTevWbZlvrKNdqfWC52MGdAEBm92ss+L8JcjpZi5GetcHKEU0s/2yOvfpWTLDF/bL8ORtClIvKTLVC2hGi11Y4oK2Sezn9FtX1QZkL71KZm/L5xOIeM102CaHxGQuFUHXRFiv5TfQS/ha5U8lXFSVvAzv4fB+awVYBMqjShoZmAOr454RRLclUjNeNDQGaGCd8HlDlO7MtH28gpSbl75zrtO5xaRFMNpNkqt6oHeCFcrV1twfE95we5agSY1cWsEZJEIroHLybQG4vOKPaCPezdAt4XAO/B+w41bGF7S/iXRgMsYXeAgzjFPwpP/g9ryD9kFZY2O0pvhK2RkC47+FCCdmvyx77OpEIquRTfTo9BhwbOTf+ofvM/yHMhN+byg2djj3PUYvnoM5H2ZE6dNTNaU69HnqVk387y3joS+2iAh13hvs= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4919.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(64756008)(110136005)(76116006)(6506007)(9686003)(66476007)(8936002)(186003)(7696005)(86362001)(26005)(8676002)(66446008)(91956017)(66556008)(38100700002)(66946007)(316002)(52536014)(66574015)(508600001)(5660300002)(71200400001)(166002)(53546011)(83380400001)(966005)(55016003)(38070700005)(122000001)(33656002)(2906002)(88722004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?GLpmoOHiotoleXltpQ+4Apl/Rgb5efQ4cC8EOLtzUMZVOFyGCRIxAhjx?= =?Windows-1252?Q?BAtVKyNN1KoDA18AhUyz/F7Ib2kG5EksIceV9U22hqyN4CQPqUXJxl0J?= =?Windows-1252?Q?950iE8shA5mMeyFJ/ZNc+mTPwOfQrnytBIKI0SV+JPA08PRQDbAriUhW?= =?Windows-1252?Q?3WwJYO2GhW8XqwCMHCkmGbvdI3bx6ocUBTGnjAla29CaDch0YDL41tDi?= =?Windows-1252?Q?T8bLExOcn5nvLRRm5gzotWjLOiodkt/gfNTmcRCR0IwufEA9t4sJibhX?= =?Windows-1252?Q?0m/8biS1xw6P80RLYW0FSQmBZ90jg/wowUj/Ws0W/GJZ+Y8tuUOMYp3G?= =?Windows-1252?Q?90ivbfflVf76Flqr9FOm4kunSK6MGNHAl1soIMYqeHdICSpOPwDEGbCJ?= =?Windows-1252?Q?sGGJPUKhs5BasfgxAevi4TqtsrE0A72P/AsKEb90+4zedjogzyd+9a+T?= =?Windows-1252?Q?lRXT4lMGaM48sfwY2KLRH5lUaW92d5PmqVgPLRP9RJKAoLQgqmWjp0Ui?= =?Windows-1252?Q?yq4lyj5GHlK7Jnpt4z8AD5wVlqKIqpUBImridIQf9c8U3+I8nj8VbdnV?= =?Windows-1252?Q?WmTwKnTu57aEfMaadA0kA46AWqIQ7tmnqV8JkSQONNwBbFaATCZ3e2Vd?= =?Windows-1252?Q?NdQw54aogCC/S3XR282L5NE6QulF7Uv1Rr/+obla47sbF7HzmIiRzFIG?= =?Windows-1252?Q?FKGqCbU7qAvY4YPbl10M/N82RWHN1F38UuDExo2gYphLtbCCInDSjYYo?= =?Windows-1252?Q?Edhdvd6Rg4Lofo8prA1FZnyumxZatfX4hb3iyjgM8y3f+ZsB1ups6/QV?= =?Windows-1252?Q?V28yaaTcZwZB9ZlIHWKSfAeyQJhFC+j579mxDHmnyQYjcp3nA9Sp7at5?= =?Windows-1252?Q?o+IUu5CVA7FOsifyF/joQVUJwBhPgK7KFusky1s0lo2MjwNO3Wt/4jv6?= =?Windows-1252?Q?x4xlztYCTmA2lVSCab7jTkRcy4urCJBf9NVTim+eG4MpsUpi9P3+ntRX?= =?Windows-1252?Q?IZX5G7zfwZJKB/OzEsZ4eP9WqrjNayGe60rBhTE+TIIFDyW5+6cr+dIs?= =?Windows-1252?Q?ynoaPh9B42HaHbVNbwvxSFkV0BZdCJ+Q9howc7lF73NdOzCxMA0Kdeop?= =?Windows-1252?Q?gEcyDl2AhTjiyZvZNKoCYUTUVUx6a3LuLxZVdKRqOlISD3ZxbpJQCb0u?= =?Windows-1252?Q?5Qmpq7QgQ0UhRujbnjnbs2gwN+JJT60ATvgmWPwfXz40p+8/7CRlXcq2?= =?Windows-1252?Q?zM5bY4i5idwIbWw3HKlTuOYxj/f7d8sFY+8un1ZyucPN9MPoj+bzsDUC?= =?Windows-1252?Q?1cR1dAtAitcR+BAGphhFN1OlCJz6mPwTYnu50AN4iyMz//KWjZAW9z83?= =?Windows-1252?Q?GzL3nZCX3nyuuWJupF/v83dd6ZVIHRe9Tgc22c6rw3APw5w3Oj70G2f3?= =?Windows-1252?Q?tyil7OHnCYEa/v/q2mv/EExqK1jk/fnhTqXI72ys7ABc43unJKW/WzJh?= =?Windows-1252?Q?/qAbRV+ninpX1fafDZxK3tRNLSsXQ490qves8MmHdxZosUuatVIkXQJ9?= =?Windows-1252?Q?RXVL9d+YHhgJFmVBZcO/DTCzz+PJbprwzp2ZDYlJI7fE24QAOdguHdlD?= =?Windows-1252?Q?SGoz08HVv94ft6aN2TPsS0iwCp0iPRLixs0ORlzmqXCZsRB8MJwn5L4Y?= =?Windows-1252?Q?C6o2iVcMza8=3D?= Content-Type: multipart/alternative; boundary="_000_PH0PR11MB49199B34A4D71A6C0E00956E8C3E9PH0PR11MB4919namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4919.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5d57773d-75e0-4eb1-7633-08d9f7fb8b52 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2022 01:09:59.4987 (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: Gs9XMdtBPPjmvPbSy2zApVUngPGVKtHrXSM8metOdFqycDhOoeMMh/evF6uqH8Ak X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1564 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.18, xbe-rcd-003.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [Roll] Reporting Links: Bidirectional vs Symmetrical (Was: review of dao-projection -22) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2022 01:10:42 -0000 --_000_PH0PR11MB49199B34A4D71A6C0E00956E8C3E9PH0PR11MB4919namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Pascal, What about the asynchronism cases? For instance, node A and B are siblings, but node A reports SIO with flag B= , node B reports SIO without flag B later. I think we have three options for this case: 1. Root trusts the latest info. 2. Root trusts the info from source node. 3. Leave it to implementation I prefer option 3 to simplify the flag definition. What do you think? Best regards, Li From: Pascal Thubert (pthubert) Date: Thursday, February 24, 2022 at 21:00 To: ROLL WG (roll@ietf.org) Cc: Li Zhao (liz3) Subject: RE: Reporting Links: Bidirectional vs Symmetrical (Was: review of = dao-projection -22) Dear all This is now issue 11 in github https://github.com/roll-wg/dao-projection/is= sues/11 The spec alone does not provide a way to assert whether the link is bidir o= r not. Some techs may leverage existing L2 information or sync/compare their DLEP = state but that needs to be defined for a specific case/technology. So I suggest we add text like: =93 The SIO carries a flag (B) that is set when similar performances can be expected both directions, so the routing can consider that the informat= ion provided for one direction is valid for both? The policy that describes= the performance criteria, and how they are asserted is out of scope. In the absence of an external protocol to assert the link quality, the = flag SHOULD NOT be set. =93 What do you think? Pascal From: Pascal Thubert (pthubert) Sent: vendredi 14 janvier 2022 11:20 To: ROLL WG (roll@ietf.org) Cc: Li Zhao (liz3) Subject: (Was: review of dao-projection -22) Dear all: we had this thread as part of Li=92s review: About =935.4 only the router with the lowest Interface ID in its registered= address needs report the SIO, and the Root will assume symmetry.=94 [Li] -> Is it possible to add a flag to indicate the symmetry? Otherwise, i= f A chooses B as sibling, but B doesn't choose A as sibling, Root may treat= SIO from A as symmetry incorrectly when only receiving SIO from A. [PT] we used to have that (B Flag for bidir) but we removed it for simplifi= cation. I=92m OK to add it back, but we still lake a good description of ho= w the node will know that the link is roughly symmetrical. [Li] Some physical layer measurements such as RSSI/LQI have forward and rev= erse direction. Can it indicate symmetrical? In layer 3, receiving DIO/NS messages from each other ind= icate symmetrical [PT] There=92s a nuance between bidir and symmetrical. Maybe the ping work= s but the link quality is very different in both directions. If so the Rank= increment computation would differ widely and we would need both sides. At the moment the text says: =93 B: 1-bit flag that is set to indicate that the connectivity to the sibling is bidirectional and roughly symmetrical. In that case, only one of the siblings may report the SIO for the hop. If 'B' is not set then the SIO only indicates connectivity from the sibling to this node, and does not provide information on the hop from this node to the sibling. =93 We need to clarify what the B flag means, when it can be set, and what is e= xpected from the Root/ PCE about path computation when it is set or not set= . Suggestions welcome; Pascal From: Roll > On Behalf = Of Li Zhao (liz3) Sent: mercredi 12 janvier 2022 10:51 To: Routing Over Low power and Lossy networks > Subject: [Roll] review of dao-projection -22 Hello Authors, Thanks for your great effort. The PDAO draft looks more clear and detailed.= Following is some concern: 3.5.2 Using Non-Storing Mode joining Tracks P-DAO 1 signals C=3D=3D>D=3D=3D>E-to-F,G P-DAO 2 signals A=3D=3D>B=3D=3D>C-to-C,F,G [Li] -> Should it be ? P-DAO 1 signals C=3D=3D>D=3D=3D>E-to-F,G P-DAO 2 signals A=3D=3D>B=3D=3D>C-to-E,F,G Otherwise RIBs in A cannot include destination to E. 4.1. Extending RFC 6550 To ensure that the PDR and P-DAO messages can flow at most times, it is REC= OMMENDED that the nodes involved in a Track =3D=3D=3Dmantain=3D=3D=3D multi= ple parents in the Main DODAG, advertise them all to the Root, and use them= in turn to retry similar packets. It is also RECOMMENDED that the Root use= s diverse source route paths to retry similar messages =3D=3D=3Dot=3D=3D=3D= the nodes in the Track.=B6 [Li] -> Typo for =93mantain=94 and =93ot=94? 4.1.6. This specification defines a new flag "Projected Routes Support" (D). The DODAG Configuration option is copied unmodified from parents to childre= n. =3D=3D=3D=3Dxref target=3D'RFC6550'/>=3D=3D=3D=3D states that: [Li] -> Typo for =93xref target=3D'RFC6550'/>=94. Why is flag named as =93= D=94? There is no D in "Projected Routes Support"=85 5.1 The Root may use an asynchronous PDR-ACK with an negative status to ind= icate that the Track was terminated before its time. [Li] -> What's the difference between negative status PDR-ACK and No-Path P= -DAO in section 6.5? And when to use asynchronous PDR-ACK? In storing mode, root should use No-Path P-DAO to tear down Track from egre= ss node. Is PDR-ACK still needed? In non-storing mode, No-Path P-DAO to ingress node is also enough. But the PDR-ACK Status field makes sense. Is it possible to add this field = in No-Path P-DAO? 5.1 One and only one RPL Target Option MUST be present in the message. [Li] -> Is it possible to remove the limitation? It=92s not flexible If PD= R can only carry one RTO. For instance in figure 7, if node I requests P-Route to B&H together, Root = can only push one Track I->A->B->H. Otherwise, Root may push two Tracks I->= A->B and I->F->G->H. If Root cannot computer one Track to multiple RTO, it can response with a s= pecial PDR-ACK Status. 5.4 only the router with the lowest Interface ID in its registered address = needs report the SIO, and the Root will assume symmetry. [Li] -> Is it possible to add a flag to indicate the symmetry? Otherwise, i= f A chooses B as sibling, but B doesn't choose A as sibling, Root may treat= SIO from A as symmetry incorrectly when only receiving SIO from A. 6.2 There is no notification to the requesting node when those changes hap= pen. [Li] -> Confuse with this claim. Is it a MUST NOT if root wants to send not= ification to the requesting node when those changes happen. 6.3 In a particular deployment where PDR are not used, the namespace can be= delegated to the main Root, which can assign the TrackIDs for the Tracks i= t creates without collision. [Li] -> Can you add some description for the collision case? E.g., node tru= sts itself than Root. 6.4.1 In both cases the Track Ingress is the owner of the Track, and it gen= erates the P-DAO-ACK when the installation is successful [Li] -> Is there any difference between P-DAO-ACK and normal DAO-ACK? E.g.= any flags? Normally, root won't receive any DAO-ACK from nodes. Is it possible to add flag to distinguish P-DAO-ACK from DAO-ACK as P-DAO f= rom DAO. 8 Profiles 0 and 1 are REQUIRED by all implementations that may be used in = LLNs; this enables to use Storing Mode to reduce the size of the Source Rou= te Header in the most common LLN deployments. [Li] -> Profile 0 is the Legacy support of [RPL] Non-Storing Mode. I= =92m confuse about =93this enables to use Storing Mode to reduce the size o= f the Source Route Header in the most common LLN deployments.=94 Best regards, Li --_000_PH0PR11MB49199B34A4D71A6C0E00956E8C3E9PH0PR11MB4919namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hello Pascal,

 

What= about the asynchronism cases?

 

For = instance, node A and B are siblings, but node A reports SIO with flag B, no= de B reports SIO without flag B later.

I th= ink we have three options for this case:

  1. Root trusts the lates= t info.
  2. Root trusts the info from source node.
  3. Leave it to implementation=

 

I pr= efer option 3 to simplify the flag definition. What do you think?

 

 

Best= regards,

Li

 

 

From: Pasc= al Thubert (pthubert) <pthubert@cisco.com>
Date: Thursday, February 24, 2022 at 21:00
To: ROLL WG (roll@ietf.org) <roll@ietf.org>
Cc: Li Zhao (liz3) <liz3@cisco.com>
Subject: RE: Reporting Links: Bidirectional vs Symmetrical (Was: rev= iew of dao-projection -22)

Dear= all

&nbs= p;

This= is now issue 11 in github https://git= hub.com/roll-wg/dao-projection/issues/11

&nbs= p;

The = spec alone does not provide a way to assert whether the link is bidir or no= t.

Some= techs may leverage existing L2 information or sync/compare their DLEP stat= e but that needs to be defined for a specific case/technology.

&nbs= p;

So I= suggest we add text like:

=93<= o:p>

&nbs= p;   The SIO carries a flag (B) that is set when similar performa= nces can be

&nbs= p;   expected both directions, so the routing can consider that t= he information

&nbs= p;   provided for one direction is valid for both? The policy tha= t describes the

&nbs= p;   performance criteria, and how they are asserted is out of sc= ope.

&nbs= p;   In the absence of an external protocol to assert the link qu= ality, the flag

&nbs= p;   SHOULD NOT be set.

=93<= o:p>

&nbs= p;

What= do you think?

&nbs= p;

Pasc= al

&nbs= p;

F= rom: Pascal Thub= ert (pthubert)
Sent: vendredi 14 janvier 2022 11:20
To: ROLL WG (roll@ietf.org) <roll@ietf.org>
Cc: Li Zhao (liz3) <liz3@cisco.com>
Subject: (Was: review of dao-projection -22)

&nbs= p;

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

&nbs= p;

&nbs= p;

Abou= t =935.4 only the router with the lowest Interface ID in its registered add= ress needs report the SIO, and the Root will assume symmetry.=94=

&nbs= p;

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

&nbs= p;

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

&nbs= p;

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

&nbs= p;            &= nbsp;    In layer 3, receiving DIO/NS messages from each oth= er indicate symmetrical

&nbs= p;

[PT]= There=92s a nuance between bidir and symmetrical.  Maybe the ping wor= ks but the link quality is very different in both directions. If so the Ran= k increment computation would differ widely and we would need both sides.

&nbs= p;

At t= he moment the text says:

=93<= o:p>

&nbs= p;  B:  1-bit flag that is set to indicate that the connectivity = to the

&nbs= p;     sibling is bidirectional and roughly symmetrical= .  In that case,

&nbs= p;     only one of the siblings may report the SIO for = the hop.  If 'B'

&nbs= p;     is not set then the SIO only indicates connectiv= ity from the

&nbs= p;     sibling to this node, and does not provide infor= mation on the hop

&nbs= p;     from this node to the sibling.=

=93<= o:p>

&nbs= p;

We n= eed to clarify what the B flag means, when it can be set, and what is expec= ted from the Root/ PCE about path computation when it is set or not set.

&nbs= p;

Sugg= estions welcome;

&nbs= p;

Pasc= al

&nbs= p;

F= rom: Roll <roll-bounces@ietf.org> On Behalf Of Li Zhao (liz3)
Sent: mercredi 12 janvier 2022 10:51
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: [Roll] review of dao-projection -22

&nbs= p;

Hell= o Authors,

&nbs= p;

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

&nbs= p;

3.5.= 2 Using Non-Storing Mode joining Tracks

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

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

&nbs= p;

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

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

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

&nbs= p;

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

&nbs= p;

4.1.= Extending RFC 6550

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

&nbs= p;  

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

&nbs= p;

4.1.= 6.

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

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

&nbs= p;

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

&nbs= p;

&nbs= p;

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

&nbs= p;

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

In storing mode, root should use No-Path P-DAO to = tear down Track from egress node. Is PDR-ACK still needed?

In non-storing mode, No-Path P-DAO to ingress node= is also enough.

But the PDR-ACK Status field makes sense. Is it possible to add this f= ield in No-Path P-DAO?

&nbs= p;

&nbs= p;

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

&nbs= p;

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

For instance in figure 7, if node I requests P-Rou= te to B&H together, Root can only push one Track I->A->B->H. O= therwise, Root may push two Tracks I->A->B and I->F->G->H.

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

&nbs= p;

&nbs= p;

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

 

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

&nbs= p;

&nbs= p;

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

 

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

 

 

6.3 In a particular deployment where P= DR are not used, the namespace can be delegated to the main Root, which can= assign the TrackIDs for the Tracks it creates without collision.

 

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

 

&nbs= p;

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

&nbs= p;

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

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

&nbs= p;

&nbs= p;

8 Pr= ofiles 0 and 1 are REQUIRED by all implementations that may be used in LLNs= ; this enables to use Storing Mode to reduce the size of the Source Route H= eader in the most common LLN deployments.

&nbs= p;

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

&nbs= p;

&nbs= p;

&nbs= p;

Best= regards,

Li

&nbs= p;

&nbs= p;

&nbs= p;

&nbs= p;

&nbs= p;

&nbs= p;

&nbs= p;

&nbs= p;

&nbs= p;

&nbs= p;

--_000_PH0PR11MB49199B34A4D71A6C0E00956E8C3E9PH0PR11MB4919namp_-- From nobody Fri Feb 25 08:20:51 2022 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA553A0C53 for ; Fri, 25 Feb 2022 08:20:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.584 X-Spam-Level: X-Spam-Status: No, score=-9.584 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=GWSfYwqY; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=O2D5HJh1 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 AaWngmywg_kC for ; Fri, 25 Feb 2022 08:20:44 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FF0B3A0963 for ; Fri, 25 Feb 2022 08:20:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=46763; q=dns/txt; s=iport; t=1645806044; x=1647015644; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=390txcg6LKOwgI0npPcUHjzLDQxYZga8aaiHVQvK74M=; b=GWSfYwqYq89onET5fYAFCJhddsAlLhDxI6oh5gNT9YGzFVmzl371PG3M RF/KsmMuguL4dZpCUl4E6yfvK9WCTMmLgjHvC5UDssQg2zg94xxfSB27t ZvPBmZ9JldVqTQ85TU5wdeJMMLdoPwbodvGPE2AcHcvLJUVwyWcnPb8MH Q=; X-IPAS-Result: =?us-ascii?q?A0APAQAyARlimIUNJK1agQmBWoEhATBWflo3RIgeA4U5h?= =?us-ascii?q?Q9dgiUDgROPKYIxiD+BLhSBEQNUCwEBAQ0BATcKBAEBhQcChA0CJTQJDgECB?= =?us-ascii?q?AEBAQEDAgMBAQEBAQEDAQEFAQEBAgEGBBQBAQEBAQEBAQkUBwYMBQ4QJ4U7A?= =?us-ascii?q?QQoDYZCAQEBAQMMBhUGEwEBJRMPAgEIEQMBAQEhAQYHMhQJCAEBBAESCBqCY?= =?us-ascii?q?gGCDlcDLgEOokcBgToCih94gQEygQGCCAEBBgQEhQsYgjcDBoE8gw+DA1VKh?= =?us-ascii?q?xMnHIFJRIEUAUNVgRFKNz6CYwICgSQcBBweBgcJgxmCLpQqEBVGDmANBy8OA?= =?us-ascii?q?gQcAisDKx43Cg4BAhIHDx8LEZ9dgXGMBpJpCoNIiwaLH4lfFZQ/k1qWUSCMc?= =?us-ascii?q?pQqFwsLhGICBAIEBQIOAQEGgWGCFXAVgyRRGQ+Fa4JfhW8egzuFFIVKdQI2A?= =?us-ascii?q?gYBCgEBAwmQRQeCQQEB?= IronPort-PHdr: A9a23:3I8pMRxq90kSeN7XCzPZngc9DxPP8534PQ8Qv5wgjb8GMqGu5I/rM 0GX4/JxxETIUoPW57Mh6aLWvqnsVHZG7cOHt3YPI5BJXgUO3MMRmQFoCcWZCEr9efjtaSFyH MlLWFJ/uX+hNk0AE8flbFqUqXq3vlYv IronPort-Data: A9a23:C3vFhqkmVeN5lp/6Ow66OrTo5gyBJkRdPkR7XQ2eYbSJt1+Wr1Gzt xIXCG7TOP2DYjeneNgjb4iz8hhXvZWGmoJnTQFpripgFltH+JHPbTi7wugcHM8zwunrFh8PA xA2M4GYRCwMZiaA4E/raNANlFEkvU2ybuKU5NXsZ2YgHWeIdA970Ug5w7Rj39Yy6TSEK1rlV e3a8pW31GCNg1aYAkpMg05UgEoy1BhakGpwUm0WPZinjneH/5UmJM53yZWKEpfNatI88thW6 Ar05OrREmvxp3/BAz4++1rxWhVirrX6ZWBihpfKMkSvqkAqm8A87ko0HKJAcG5OghmqptZwk oRN6YyIRTsnF5SZzYzxUzEAe81/FaRC/LmCKn+lvInKlgvNcmDnxLNlC0Re0Y8wo7ksRzoQs 6VDbmlWNXhvhMruqF6/YvFwhtkpIdP3FIgeoXpnizreCJ7KRLiTGPSUtIIBgGxYasZmRdX9b vAUbGZWcTeQagcUYF4SDZsVg7L97pX4W2QI9A3KzUYt2EDJywh1+LngLNSTfcaFLfi5hW6Ro mbAum/+GBxfbYXZwjue+XXqjejK9c/mZG4MPOXk79dziXGw/2oSUkwWCUuDrcW3o3frDrqzN Hco0iYpqKEz8mmiQd/8QwC0rRa4Uvg0BoE4/woStVrl90bE3+qKLjNfF2ceNrTKoOdzFGJ0i Q7Q9z/8LWU36NWopWShGqB4RN9YEQERKWIEDcPvZVRYu4C4yG3fY+6mczqOOKexituwEjbqz nXT9W41hq4YiogA0KDTEbH7b9CE+8Whou0dv1i/soeZAuVRP9fNi2uAsgKz0Bq4BNzFJmRtR VBd8yRk0MgADIuWiAuGS/gXEbei6p6taWOA3AEzR8Z+qWr9pBZPmLy8Bhkjei+F1e5ZJlfUj LP74mu9GbcKZiLxNP8rC25PI513l/CI+SvZugD8N4oSPccZmP6v9yB1bknYxHH2jEUpiskC1 WSzL66R4YIhIf0/llKeHr5FuZdyn3xW7T6DFPjTkkX8uZLDNSH9YeleajOmMLtmhJ5oVS2Iq b6zwePQlUUGOAA/CwGKmbMuwacidiBqVcir8JUMLoZu4GNOQQkcNhMY+pt5E6QNokifvr6gE q2VMqOA9GfCuA== IronPort-HdrOrdr: A9a23:iw/0F6+9x6RlUexGatxuk+Fudb1zdoMgy1knxilNoENuE/Bwxv rBoB1E73DJYW4qKQ4dcKO7Sde9qBLnhNFICOwqXYtKMzOWwFdBoutZnPDfKlHbakjDH6tmpN tdmstFeZPN5DpB/LzHCWCDer5KqrTqgcPY59s2jU0dMD2CAJsQiDuRfzzra3GeMzM2Y6bReq DsgvZvln6FQzA6f867Dn4KU6zovNvQjq/rZhYAGloO9BSOpSnA0s+6LzGomjMlFx9fy7Yr9m bI1ybj4L+4jv29whjAk0fO8pVtnsf7wNcrPr3NtiFVEESutu+bXvUlZ1SwhkFwnAhp0idsrD D4mWZjAy200QKWQoj6m2q15+Cq6kde15ar8y7pvZKkm72geNr/YPAx376wtXDimhEdVZhHod F29nPcuJxNARzamiPho9DOShFxj0Kx5WEviOgJkhVkIMEjgZJq3MQiFXluYdw99ePBmfcaOf grCNuZ6OddcFucYXyctm5zwMa0VnB2GhudWEANtsGczjATxRlCvgcl7d1amm1F+IM2SpFC6e iBOqN0lKtWRstTaa5mHu8OTca+F2SISxPRN2CZJ0jhCcg8Sj/wgo+y5K9w6PCheZQOwpd3kJ PdUElAvWp3YE7qAd3m5uwDzvkMehTKYd3A8LAq23EigMyPeFPCC1z2dGwT X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.90,136,1643673600"; d="scan'208,217";a="839695143" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Feb 2022 16:20:42 +0000 Received: from mail.cisco.com (xbe-rcd-003.cisco.com [173.37.102.18]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 21PGKgSo008449 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for ; Fri, 25 Feb 2022 16:20:42 GMT Received: from xfe-rtp-004.cisco.com (64.101.210.234) by xbe-rcd-003.cisco.com (173.37.102.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Fri, 25 Feb 2022 10:20:42 -0600 Received: from xfe-rtp-004.cisco.com (64.101.210.234) by xfe-rtp-004.cisco.com (64.101.210.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Fri, 25 Feb 2022 11:20:40 -0500 Received: from NAM02-SN1-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.986.14 via Frontend Transport; Fri, 25 Feb 2022 11:20:40 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=k4GfNU5pskF9sezgferFPjxcfERGXd7yRgIqO+x2NvYx2CS/Lylfjs6eYR30NYX2V/ISbDECZmGyz0wMzDFX9HiE2iZBSrZlKiESoXuuHTrqFKy2N4ntF0QEAojBBKKKWAKy3xL9cxW9EDLlmUoUsoMloSMsvQqo4EaleTXERq3BPExCpf5FaUJ6hPUdVw9TinqXaCi/LFtmKnUqTsvg6Ign5cZ9KviA+vLam7YhMx7j58FZEkRYVPjY233rhEY1PXSH9wIcjH6uuUHPwoTxhXvHE4d3QB62tZQ19uG6LK3z0soXJbfeWwiHgzElHJ6xiglBE1N1kC7FHYfO+AZf7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=8fRKdODoOHGOq8i69EW8U+myqOtMeDdPn5moy8pOos4=; b=MU1lxAxJ1JdOA9tzCqCUdmH4NPUirK66qMNXDbsKMQi5b20V1yo57rDtJb8DqDmN4actmQ2TeO/kW9CWFad4oua5EDjaGQZmhjahsPrjzKpqKYUj/tVEJ5KO8GBPlWz3XZ5M7FIoKc2/xf30SFZ3gYOLNH2fn544ygshzPpN3GCNygi+RhFsOHeuMzIJF+prVF+R9GhxHj+/wwJ2/CS4DDifi185Df3Ndo5dgS3alchB2l+NpwIrTe1hYJRNCqUh6rChvDThZGu1FWzlQk0XE+3azDNMHYCQ2DlxJkqkJ/aZ/PWO4kMV4UjoWFtdvqCXPtCQ2BpIA3HksmotozHIHw== 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=8fRKdODoOHGOq8i69EW8U+myqOtMeDdPn5moy8pOos4=; b=O2D5HJh1+oGZmyi6cCyuZzD2pye1UeT5+0iao8L4D0msZgLC4KcE8RYBS21Dxmo+61+Yy9YOUrEkBtP55KiEE/6OUWRmZ6Hjyu7+WNsk/Sxt8kumu53YsOMyI1WsO76A961B/HA0GxjBOTpwpkRqUL9qq4M09peyMR5ybQYcfGE= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by DM6PR11MB2841.namprd11.prod.outlook.com (2603:10b6:5:c8::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5017.26; Fri, 25 Feb 2022 16:20:38 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::f515:598d:4160:b4b8]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::f515:598d:4160:b4b8%4]) with mapi id 15.20.5017.026; Fri, 25 Feb 2022 16:20:38 +0000 From: "Pascal Thubert (pthubert)" To: "Li Zhao (liz3)" , "ROLL WG (roll@ietf.org)" Thread-Topic: Reporting Links: Bidirectional vs Symmetrical (Was: review of dao-projection -22) Thread-Index: AdgpcUWc8mKMuUnWSsS5Bax1TjHaYwAcilJNAB08/dA= Date: Fri, 25 Feb 2022 16:20:15 +0000 Deferred-Delivery: Fri, 25 Feb 2022 16:19:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 07e91b25-59ad-4068-04bc-08d9f87ac2c5 x-ms-traffictypediagnostic: DM6PR11MB2841:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1OBz2mRO3nPL5kIQjy1ArO3JEzWIhpxTRzIhFBJVzNyi3IU1TJ1a0f5KPWNVcQAC3CEHWZ3AuuD7y+t0yvydJfSaEonvDA+i+k+Faq27P3PmuTqelUf2cmUXaY8RYSLXJlc8vjbNSWXSz232B//L/ZYW4wZ4lT/q8/IzZzga8YGH3kGXNvoP1vF2NbD612c+QtyaHOltKd0lxbBAHMMFZOjOs/8nVDtL+jjTMwetq6Dw5VMJ/eLuNbn7uhRo2rh5lAlJtRmF8bkCO2yl57F4avysElKC3JYASjfuY7t9ETiWNcR38ZJWG/XkrXd/KqrqzWGi3swB8LGbxmtyFuG/6IuwQ3ZWrPC2Fbsaf5BCRPaxTPR9fNCvIBT/KPFQr9RX/FHOLfRXHFrtz4BxxttjxVTNFRdleZtUFnFVegYbl8biysmIYIuGV9IWAnXTFH8pIqr0U+zVG/Z2Qv2NPvPqedw37aCoNKfceVUn4M3u3d7pGQqAxle2BzWS2CY7LHqz6kMEAYoI1rPy754tFLHUNmX/HVUKixwMkH9iZ47fXtcgntdK2ruJ25ueb4v6zvYz08QOCAhHLLv/nOHr6S1oYaXxHx9qGPV+vh7jAvfZbR1okdK+jh5W0BJaku0fkdNvfdJ/uT8T1Z807zIfFev0kqW58jOdSV3biB7F2Fz/vIx0q5SBnjbiLLTmXtnA2a2/hSpLf96xvLIC2JPUWvsZSCFOKQFGD+tqS4KbDsXKQV3ncWVx3gS4+H0gr3a7AkIJ6K/XRDKzGMxHSuNDHj6iWRxtLigSwCcyJtw1nsrJNxwPLwzm4TEjEPBoPrcVqsFE x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB4881.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(8676002)(33656002)(166002)(55016003)(66446008)(66476007)(66556008)(66946007)(76116006)(64756008)(6506007)(52536014)(7696005)(2906002)(508600001)(53546011)(86362001)(38070700005)(8936002)(71200400001)(6666004)(38100700002)(122000001)(9686003)(5660300002)(966005)(110136005)(26005)(186003)(316002)(66574015)(83380400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?APGb7qz+yQXRA+AeNbPrNolhatQithTsViBmzuJspw9r9VUNErTVzp0bBk?= =?iso-8859-1?Q?FtXAs+E8FmdUsA8567YwsZUdpnKBYUhcT1ZytDe4BoUfK1cGNW6ns6G8dj?= =?iso-8859-1?Q?nD+no0YKjX224YZTxyaC/T/Xqe1zkRHIjqgbUtiQB0wurCgZTgz5PTnLs1?= =?iso-8859-1?Q?B6m3UoLzheuCV/33zM617cdm9j4Xxd1+OHZeT5bCmH4gP4lL4swue+EAEl?= =?iso-8859-1?Q?iU9SAvx7H0nCTM2zZCVgA70cOr84WhWSHxqpGeUvbPVpt0TcpCCAXfskRd?= =?iso-8859-1?Q?J4wV864WuiXmtK/CyAY80rdnO+1bmjGkqP6aarvWjjTIVM6nXEDNBUY4kv?= =?iso-8859-1?Q?4GMtgPoKlYjCWCDen6hH11LEE0fw0gF5cUBC6RY+pDi9UEUiD8DkZqVqX5?= =?iso-8859-1?Q?k4wl+Mfqn5URnvmfOsbG87o++iunsY8+uwBYMdG8XphLqlAMLjdTSpMlL4?= =?iso-8859-1?Q?qKQe5RTOgNuIt8MUtGWEHb/qLs+nmjFvY7a4UMGcBPgWjvg0L1cNOc3ElR?= =?iso-8859-1?Q?Oi5pK3RejEtolmAtNpFXVTz+yxZrZUAFBmDb5ZKBt7lZZxDYNhPNaEz6wu?= =?iso-8859-1?Q?MgM9Wz+78XYdgcsE+xOHnoQEAd0GreEKzOh5Ug/QuWtobh1gNQc/YjUGqM?= =?iso-8859-1?Q?qHGPO2J4BRUKvkRcWjVzHMYRvSdM61sKvDIwixsmLBteo40l9z46TTF01J?= =?iso-8859-1?Q?ppkCz7/h/2JvslKhFzsC6DkC06DZlSTqJ2LKnB1vjjhHk6vs8yEYTW92MW?= =?iso-8859-1?Q?bi8JvoSe0wOB2US+lno1IwUdB1sAUV9nVDlv2yEPlwi80fzl8fLBrcWFFm?= =?iso-8859-1?Q?KkOt7OhPo7qT0JEqc8kkuvHnOPOR5qW778Ycr0HvbeozgrFfyKGf9pQBL7?= =?iso-8859-1?Q?S5GsR/nFJw2ReeU2wCeHcm7pznTL+cIqBrTbBgRIC7FQ/fXqpjem3BgUza?= =?iso-8859-1?Q?S3DPIBkElQtTkzfrgPPTtnuSL4V+GDStPLZ0N3Y9CCIEkeiHSmarCaltgX?= =?iso-8859-1?Q?ENUaczktjiUbWNHm1DzaOcYOOC5iMSurcI5y6Q9EqZYOztd21Hb75kDSP2?= =?iso-8859-1?Q?69jYDUp4c5VhuXmjr6OAvs8jgCURA4WDebDccoM5XherkVG49PTGsNzpAN?= =?iso-8859-1?Q?PumEsnKYNwhhyVoTSIOC3EpkZNEEcrZc0fbaeDOkWFUABq/og+dqqaSTuY?= =?iso-8859-1?Q?0H5lzOEvf/EqcZC61bwZibwXXSXiIqltW8n2tPPw+u4qzc2b8Oa3IYWB/a?= =?iso-8859-1?Q?au3JZSZsrp7rcLi+/1Qw8YI5TMfD3ESJkU0Zxx1lzmFx+5mryYYs/IpnrT?= =?iso-8859-1?Q?OLnw4lBUa4sh6UxU//Rk6TG4V8dak978vgvPsGbtpPp6MqdS+3rG8Xw4t3?= =?iso-8859-1?Q?cuw5On/I2x/7KSAXnIRNcvZOnhlKGLfVMCvpSDnGRGxiuVDPRJuuZuGR8w?= =?iso-8859-1?Q?GzDlOys+etXDTAYbkSjhgdTQF7H1ZWyaJhyvFLW4dlWvtxtf8QKDmEdH3z?= =?iso-8859-1?Q?kDk5THXm7SpvdIkL7YJ8QV4hLBLx4wReIp2vucWO+7ahBYuk7RSWpwv81u?= =?iso-8859-1?Q?J06NKT9AP0wEQpXo4EmQiLEjItHL+z+8jzQJP33gwm4+3Qm/Q+z1v8mXPr?= =?iso-8859-1?Q?GtIeLweGgCWV/JefIurerU8/KiiPWjt11cJXRN7/mD1KveXJubepe5iw?= =?iso-8859-1?Q?=3D=3D?= Content-Type: multipart/alternative; boundary="_000_CO1PR11MB4881CB3B34F186F21181E895D83E9CO1PR11MB4881namp_" 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: 07e91b25-59ad-4068-04bc-08d9f87ac2c5 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2022 16:20:38.5776 (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: E1//Eo/aoiwRcnoqSeH8SLTnRnC3DMF5ue1jgU2yuaraV94G1NVLUx6xqCHWAKivhXPmSNmgRDrLTgqyzcPFTQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2841 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.18, xbe-rcd-003.cisco.com X-Outbound-Node: alln-core-11.cisco.com Archived-At: Subject: Re: [Roll] Reporting Links: Bidirectional vs Symmetrical (Was: review of dao-projection -22) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2022 16:20:49 -0000 --_000_CO1PR11MB4881CB3B34F186F21181E895D83E9CO1PR11MB4881namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Li: This is an error case that does not impact interoperation, but I agree it = is worth mentioning. I like option 2 since the source knows better. IMHO If you receive information from both sides you should ignore the B fla= g. Proposal to add: " If the SIO is effect= ively received from both sides then the B flag is ignored. " Works for you? Pascal From: Li Zhao (liz3) Sent: vendredi 25 f=E9vrier 2022 2:10 To: Pascal Thubert (pthubert) ; ROLL WG (roll@ietf.org)= Subject: Re: Reporting Links: Bidirectional vs Symmetrical (Was: review of = dao-projection -22) Hello Pascal, What about the asynchronism cases? For instance, node A and B are siblings, but node A reports SIO with flag B= , node B reports SIO without flag B later. I think we have three options for this case: 1. Root trusts the latest info. 2. Root trusts the info from source node. 3. Leave it to implementation I prefer option 3 to simplify the flag definition. What do you think? Best regards, Li From: Pascal Thubert (pthubert) > Date: Thursday, February 24, 2022 at 21:00 To: ROLL WG (roll@ietf.org) > Cc: Li Zhao (liz3) > Subject: RE: Reporting Links: Bidirectional vs Symmetrical (Was: review of = dao-projection -22) Dear all This is now issue 11 in github https://github.com/roll-wg/dao-projection/is= sues/11 The spec alone does not provide a way to assert whether the link is bidir o= r not. Some techs may leverage existing L2 information or sync/compare their DLEP = state but that needs to be defined for a specific case/technology. So I suggest we add text like: " The SIO carries a flag (B) that is set when similar performances can be expected both directions, so the routing can consider that the informat= ion provided for one direction is valid for both? The policy that describes= the performance criteria, and how they are asserted is out of scope. In the absence of an external protocol to assert the link quality, the = flag SHOULD NOT be set. " What do you think? Pascal From: Pascal Thubert (pthubert) Sent: vendredi 14 janvier 2022 11:20 To: ROLL WG (roll@ietf.org) > Cc: Li Zhao (liz3) > Subject: (Was: review of dao-projection -22) Dear all: we had this thread as part of Li's review: About "5.4 only the router with the lowest Interface ID in its registered a= ddress needs report the SIO, and the Root will assume symmetry." [Li] -> Is it possible to add a flag to indicate the symmetry? Otherwise, i= f A chooses B as sibling, but B doesn't choose A as sibling, Root may treat= SIO from A as symmetry incorrectly when only receiving SIO from A. [PT] we used to have that (B Flag for bidir) but we removed it for simplifi= cation. I'm OK to add it back, but we still lake a good description of how = the node will know that the link is roughly symmetrical. [Li] Some physical layer measurements such as RSSI/LQI have forward and rev= erse direction. Can it indicate symmetrical? In layer 3, receiving DIO/NS messages from each other ind= icate symmetrical [PT] There's a nuance between bidir and symmetrical. Maybe the ping works = but the link quality is very different in both directions. If so the Rank i= ncrement computation would differ widely and we would need both sides. At the moment the text says: " B: 1-bit flag that is set to indicate that the connectivity to the sibling is bidirectional and roughly symmetrical. In that case, only one of the siblings may report the SIO for the hop. If 'B' is not set then the SIO only indicates connectivity from the sibling to this node, and does not provide information on the hop from this node to the sibling. " We need to clarify what the B flag means, when it can be set, and what is e= xpected from the Root/ PCE about path computation when it is set or not set= . Suggestions welcome; Pascal From: Roll > On Behalf = Of Li Zhao (liz3) Sent: mercredi 12 janvier 2022 10:51 To: Routing Over Low power and Lossy networks > Subject: [Roll] review of dao-projection -22 Hello Authors, Thanks for your great effort. The PDAO draft looks more clear and detailed.= Following is some concern: 3.5.2 Using Non-Storing Mode joining Tracks P-DAO 1 signals C=3D=3D>D=3D=3D>E-to-F,G P-DAO 2 signals A=3D=3D>B=3D=3D>C-to-C,F,G [Li] -> Should it be ? P-DAO 1 signals C=3D=3D>D=3D=3D>E-to-F,G P-DAO 2 signals A=3D=3D>B=3D=3D>C-to-E,F,G Otherwise RIBs in A cannot include destination to E. 4.1. Extending RFC 6550 To ensure that the PDR and P-DAO messages can flow at most times, it is REC= OMMENDED that the nodes involved in a Track =3D=3D=3Dmantain=3D=3D=3D multi= ple parents in the Main DODAG, advertise them all to the Root, and use them= in turn to retry similar packets. It is also RECOMMENDED that the Root use= s diverse source route paths to retry similar messages =3D=3D=3Dot=3D=3D=3D= the nodes in the Track.=B6 [Li] -> Typo for "mantain" and "ot"? 4.1.6. This specification defines a new flag "Projected Routes Support" (D). The DODAG Configuration option is copied unmodified from parents to childre= n. =3D=3D=3D=3Dxref target=3D'RFC6550'/>=3D=3D=3D=3D states that: [Li] -> Typo for "xref target=3D'RFC6550'/>". Why is flag named as "D"? Th= ere is no D in "Projected Routes Support"... 5.1 The Root may use an asynchronous PDR-ACK with an negative status to ind= icate that the Track was terminated before its time. [Li] -> What's the difference between negative status PDR-ACK and No-Path P= -DAO in section 6.5? And when to use asynchronous PDR-ACK? In storing mode, root should use No-Path P-DAO to tear down Track from egre= ss node. Is PDR-ACK still needed? In non-storing mode, No-Path P-DAO to ingress node is also enough. But the PDR-ACK Status field makes sense. Is it possible to add this field = in No-Path P-DAO? 5.1 One and only one RPL Target Option MUST be present in the message. [Li] -> Is it possible to remove the limitation? It's not flexible If PDR = can only carry one RTO. For instance in figure 7, if node I requests P-Route to B&H together, Root = can only push one Track I->A->B->H. Otherwise, Root may push two Tracks I->= A->B and I->F->G->H. If Root cannot computer one Track to multiple RTO, it can response with a s= pecial PDR-ACK Status. 5.4 only the router with the lowest Interface ID in its registered address = needs report the SIO, and the Root will assume symmetry. [Li] -> Is it possible to add a flag to indicate the symmetry? Otherwise, i= f A chooses B as sibling, but B doesn't choose A as sibling, Root may treat= SIO from A as symmetry incorrectly when only receiving SIO from A. 6.2 There is no notification to the requesting node when those changes hap= pen. [Li] -> Confuse with this claim. Is it a MUST NOT if root wants to send not= ification to the requesting node when those changes happen. 6.3 In a particular deployment where PDR are not used, the namespace can be= delegated to the main Root, which can assign the TrackIDs for the Tracks i= t creates without collision. [Li] -> Can you add some description for the collision case? E.g., node tru= sts itself than Root. 6.4.1 In both cases the Track Ingress is the owner of the Track, and it gen= erates the P-DAO-ACK when the installation is successful [Li] -> Is there any difference between P-DAO-ACK and normal DAO-ACK? E.g.= any flags? Normally, root won't receive any DAO-ACK from nodes. Is it possible to add flag to distinguish P-DAO-ACK from DAO-ACK as P-DAO f= rom DAO. 8 Profiles 0 and 1 are REQUIRED by all implementations that may be used in = LLNs; this enables to use Storing Mode to reduce the size of the Source Rou= te Header in the most common LLN deployments. [Li] -> Profile 0 is the Legacy support of [RPL] Non-Storing Mode. I'm= confuse about "this enables to use Storing Mode to reduce the size of the = Source Route Header in the most common LLN deployments." Best regards, Li --_000_CO1PR11MB4881CB3B34F186F21181E895D83E9CO1PR11MB4881namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello Li:

 

This is an error case  that does not impact interoperat= ion, but I agree it is worth mentioning. I like option 2 since the source k= nows better.

IMHO If you receive information from both sides you should i= gnore the B flag.

 

Proposal to add:

“

          =              &n= bsp;            = ;            &n= bsp;      If the SIO is effectively

    received from both sides then the B flag = is ignored.

“

 

Works for you?

 

Pascal

From:= Li Zhao (liz3) <liz3@cisco.com>
Sent: vendredi 25 f=E9vrier = 2022 2:10
To: Pascal Thubert (pthubert= ) <pthubert@cisco.com>; ROLL WG (roll@ietf.org) <roll@ietf.org>=
Subject: Re: Reporting Links= : Bidirectional vs Symmetrical (Was: review of dao-projection -22)

 

Hello Pascal,

 

What about the asynchronism cases?

 

For instance, node A and B are siblings, but node A reports = SIO with flag B, node B reports SIO without flag B later.=

I think we have three options for this case:

  1. Ro= ot trusts the latest info.
  2. Root trusts the info = from source node.
  3. Leave it to implementation

 

I prefer option 3 to simplify the flag definition. What do y= ou think?

 

 

Best regards,

Li

 

 

From: Pascal Thubert (pthubert) <pthubert@cisco.com>
Date: Thursday, February 24,= 2022 at 21:00
To: ROLL WG (roll@ietf.org) <r= oll@ietf.org>
Cc: Li Zhao (liz3) <liz3@cisco.com>
Subject: RE: Reporting Links= : Bidirectional vs Symmetrical (Was: review of dao-projection -22)

Dear all

 

This is now issue 11 in github https://git= hub.com/roll-wg/dao-projection/issues/11

 

The spec alone does not provide a way to assert whether the = link is bidir or not.

Some techs may leverage existing L2 information or sync/comp= are their DLEP state but that needs to be defined for a specific case/techn= ology.

 

So I suggest we add text like:

“

    The SIO carries a flag (B) that is set wh= en similar performances can be

    expected both directions, so the routing = can consider that the information

    provided for one direction is valid for b= oth? The policy that describes the

    performance criteria, and how they are as= serted is out of scope.

    In the absence of an external protocol to= assert the link quality, the flag

    SHOULD NOT be set.

“

 

What do you think?

 

Pascal

 

From:= Pascal Thubert (pthubert)
Sent: vendredi 14 janvier 20= 22 11:20
To: ROLL WG (roll@ietf.org) <r= oll@ietf.org>
Cc: Li Zhao (liz3) <liz3@cisco.com>
Subject: (Was: review of dao= -projection -22)

 

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

 

 

About “5.4 only the router with the lowest Interface I= D in its registered address needs report the SIO, and the Root will assume = symmetry.”

 

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

 

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

 

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

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

 

[PT] There’s a nuance between bidir and symmetrical.&n= bsp; Maybe the ping works but the link quality is very different in both di= rections. If so the Rank increment computation would differ widely and we would need both sides.

 

At the moment the text says:

“

   B:  1-bit flag that is set to indicate tha= t the connectivity to the

      sibling is bidirectional and = roughly symmetrical.  In that case,

      only one of the siblings may = report the SIO for the hop.  If 'B'

      is not set then the SIO only = indicates connectivity from the

      sibling to this node, and doe= s not provide information on the hop

      from this node to the sibling= .

“

 

We need to clarify what the B flag means, when it can be set= , and what is expected from the Root/ PCE about path computation when it is= set or not set.

 

Suggestions welcome;

 

Pascal

 

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

 

Hello Authors,

 

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

 

3.5.2 Using Non-Storing Mode joining Tracks

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

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

 

   [Li] ->  Should it be ?

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

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

 

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

 

4.1. Extending RFC 6550

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

   

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

 

4.1.6.

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

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

 

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

 

 

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

 

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

In storing mode, root should = use No-Path P-DAO to tear down Track from egress node. Is PDR-ACK still neede= d?

In non-storing mode, No-Path = P-DAO to ingress node is also enough.

But the PDR-ACK Status field makes sense. Is it possible to add this field in No-Pat= h P-DAO?

 

 

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

 

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

For instance in figure 7, if = node I requests P-Route to B&H together, Root can only push one Track I= ->A->B->H. Otherwise, Root may push two Tracks I->A->B and I->F->G->H.

If Root cannot computer one T= rack to multiple RTO, it can response with a special PDR-ACK Status.

 

 

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

 

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

 

 

6.2  There is no notification to the requesting node wh= en those changes happen.

 

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

 

 

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

 

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

 

 

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

 

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

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

 

 

8 Profiles 0 and 1 are REQUIRED by all implementations that = may be used in LLNs; this enables to use Storing Mode to reduce the size of= the Source Route Header in the most common LLN deployments.

 

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

 

 

 

Best regards,

Li

 

 

 

 

 

 

 

 

 

 

--_000_CO1PR11MB4881CB3B34F186F21181E895D83E9CO1PR11MB4881namp_-- From nobody Fri Feb 25 08:28:42 2022 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC7943A0A25; Fri, 25 Feb 2022 08:28:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <164580651870.7745.10369379126387687675@ietfa.amsl.com> Date: Fri, 25 Feb 2022 08:28:38 -0800 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-dao-projection-24.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: Fri, 25 Feb 2022 16:28:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks WG of the IETF. Title : Root initiated routing state in RPL Authors : Pascal Thubert Rahul Arvind Jadhav Michael C. Richardson Filename : draft-ietf-roll-dao-projection-24.txt Pages : 84 Date : 2022-02-25 Abstract: This document extends RFC 6550, RFC 6553, and RFC 8138 to enable a RPL Root to install and maintain Projected Routes within its DODAG, along a selected set of nodes that may or may not include self, for a chosen duration. This potentially enables routes that are more optimized or resilient than those obtained with the classical distributed operation of RPL, either in terms of the size of a Routing Header or in terms of path length, which impacts both the latency and the packet delivery ratio. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-dao-projection/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-roll-dao-projection-24.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-dao-projection-24 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Fri Feb 25 08:34:19 2022 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF9B3A0A53; Fri, 25 Feb 2022 08:34:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.595 X-Spam-Level: X-Spam-Status: No, score=-9.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=NU5uf2Sk; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=p3M8xZEN 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 GwW__wfu-PES; Fri, 25 Feb 2022 08:34:12 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 969103A0AD0; Fri, 25 Feb 2022 08:34:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2169; q=dns/txt; s=iport; t=1645806852; x=1647016452; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=WfRaegRSAXdpUZrJcwG6lRGsAIwxnl4Q1VMf23UD+Fw=; b=NU5uf2SkqeWgrHw8WuDmz1lJ0Azdqxeeanrr/8ZzZ1dYQ/5XAd0jlh/x YPOIrylvh6c/RiWX9QttwBhmsQi2JjTR27L8tBne0cEjn586dVWbTPAVa EHJVLZzFIVncqpHYmSsLXLcGQUhCq3gd8tGnxYuJaEeSKbXFN5R3h+Aym c=; IronPort-PHdr: =?us-ascii?q?A9a23=3AivUnlxGroHFOJPcm9pQL9Z1GfiYY04WdBeZdw?= =?us-ascii?q?pYkircbdKOl8tyiOUHE/vxigRfPWpmT8PNLjefa8sWCEWwN6JqMqjYOJZpLU?= =?us-ascii?q?RJWhcAfhQd1BsmDBAXyJ+LraCpvGsNEWRdl8ni3PFITFtz5YgjZo2a56ngZH?= =?us-ascii?q?RCsXTc=3D?= IronPort-Data: =?us-ascii?q?A9a23=3APvHe/Kp3QoJI8awS5HLL5LYrcMReBmIxZxIvg?= =?us-ascii?q?KrLsJaIsI4StFCztgarIBmCa/vcMzD2LdB+a9mx/U5Tv8KBm4JgTQY4+CxhE?= =?us-ascii?q?3gX9ePIVI+TRqvS04x+DSFioHqKZKzyU/GYRCwPZiKa9kfF3oTJ9yEmj/nSH?= =?us-ascii?q?uOkUYYoBwgoLeNaYHZ54f5cs7ZRbr5A2bBVMivV0T/Ai5S31GyNg1aYBlkpB?= =?us-ascii?q?5er83uDihhdVAQw5TTSbdgT1LPXeuJ84Jg3fcldJFOgKmVY83LTegrN8F251?= =?us-ascii?q?juxExYFENiplPPwdVcHB+OUNgmVgX0QUK+n6vRAjnVtieBga7xNMgEO1mvhc?= =?us-ascii?q?9NZkL2hsbSoVQc0NKDWhMwWUgJTFGd1OqguFLrvcCfi6ZLIlxycG5fr67A0Z?= =?us-ascii?q?K0sBqUC/eJzKWBD6fJeLyoCBjiZgOayhbm7Q+h2newiIdXleoQFtRldIZvxZ?= =?us-ascii?q?Ro9aYrIT6OP7thC0XJtwMtPBv3ZIcEebFJSgN37S0UnEj8q5FgWxY9EXkXCT?= =?us-ascii?q?gA=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3A2ZtU56x5DW40rc94gWk7KrPxm+skLtp133?= =?us-ascii?q?Aq2lEZdPULSK2lfpGV8sjziyWatN9IYgBdpTiBUJPwJk80hqQFnrX5Wo3SEz?= =?us-ascii?q?UO2VHYYL2KiLGD/9SOIVyEygbSv50QCZSWZOeAaGSS7vyKrjVQcexQveVvmZ?= =?us-ascii?q?rA7Yy1ohsdLnAJV0gK1XYeNu/vKDwPeOAwP+tBKHPz3LsimxOQPVAsKuirDH?= =?us-ascii?q?gMWObO4/fRkoj9XBIADxk7rCGTkDKB8tfBYlml9yZbdwkK7aYp8GDDnQC8zL?= =?us-ascii?q?6kqeuHxhjV0HKWx4hKmeHm1sBICKW3+4gow3TX+0WVjbZaKvi/VQMO0aWSAZ?= =?us-ascii?q?ER4Z7xSiIbToZOArXqDyeISFXWqlDdOX0VmgHfIBej8AreSIrCNWoH4w4rv/?= =?us-ascii?q?MCTvMfgHBQ5+2UmZg7r16xpt5ZCwjNkz/64MWNXxZ2llCsqX5niuILiWdDOL?= =?us-ascii?q?FuI4O5gLZvtX+9Kq1wVB4SKbpXZNVGHYXZ/rJbYFmaZ3fWsi1mx8GtRG06Gl?= =?us-ascii?q?ODTlIZssKY3jBKlDQhpnFoifA3jzMF7tYwWpNE7+PLPuBhk6xPVNYfaeZ4CP?= =?us-ascii?q?0aScW6B2TRSVbHMX6UI17gCKYbUki94aLf8fEw/qWnaZYIxJw9lNDIV05Zr3?= =?us-ascii?q?c7fwb0BciHzPRwg2bwqaWGLEPQI+1llupEU+fHNcnW2AW4OSUTr/c=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BoBgByHvlh/5xdJa1aHgEBCxIMQIF?= =?us-ascii?q?PC4FSVgd3WjcxiBADhTmFDoMCA5skgS4UgREDVAsBAQENAQEqCwwEAQGFBQK?= =?us-ascii?q?DXwIlNAkOAQIEAQEBEgEBBQEBAQIBBgSBCROFaAEMhkIBAQEBBAEQLgEBLAs?= =?us-ascii?q?BCwYBGQQBAVYLHQkBBA4FCBqCY4JlAy4BDqIrAYE6AoofeIEzgQGCCAEBBgQ?= =?us-ascii?q?EgToCDkGDAhiCNwMGgTqDDocbhAonHIFJRIEVQ4YIAQEBAQEXgQwcIINNgi6?= =?us-ascii?q?RLC9TXQRRAhQMAjkCCTJMTUahDp5iCoNGiwGUehWoB5ZKIIxvlBOFIAIEAgQ?= =?us-ascii?q?FAg4BAQaBYTyBWXAVGiGCaVEZD44gg3GFFIVKdAI2AgYBCgEBAwmNTAEB?= X-IronPort-AV: E=Sophos;i="5.88,333,1635206400"; d="scan'208";a="975063092" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Feb 2022 16:34:11 +0000 Received: from mail.cisco.com (xbe-aln-001.cisco.com [173.36.7.16]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 21PGYB0Z013097 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 25 Feb 2022 16:34:11 GMT Received: from xfe-rtp-003.cisco.com (64.101.210.233) 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.986.14; Fri, 25 Feb 2022 10:34:11 -0600 Received: from xfe-aln-001.cisco.com (173.37.135.121) by xfe-rtp-003.cisco.com (64.101.210.233) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Fri, 25 Feb 2022 11:34:10 -0500 Received: from NAM10-DM6-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.986.14 via Frontend Transport; Fri, 25 Feb 2022 10:34:09 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=igMkeZQX40i1/EzrNXE/EaT4wfWh7MM78OJ2HyvgVohkMwByYJ4TP7ThBhf3DtWOeM8cKTSO6PMjU7fOIYk0s30BOtL0o+S5HnXa5sTgmotG6CU8XEw7ICBtgsSiiMj4z6nPx87UgiGCPqwzfI7i+vaIuhcC13rwLh0CIjJOi1BV/i9nP54JsONuNxXo52vJMBjn54CxYS7C486vyKPSRMJgoZNpSzF60HfPqED0234Dx1iCdquIWviKOUiRa2Rdt6LIW2o0TwTYSzo4nH8ZIQf8ExFDIB1mza7KCL91uQKBhIVvHrcDDW2nh+S5xwoNY5u9j92qMt7Bv1YLp/yHEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ZWyJNJjpZF3KdNgB5U+dmjtDr200PllpefNNzjFPmIY=; b=LlIN5d3w5/hwr/vQBTV4o/Po81zBcoMn2LYcbhhlZGR1vqvF8m0q29F8wX+wMMV20PukcAKJH7MIOyrCYHhJDWqGtOkiHp10pUM6932xl37F9cqqK8Bjgi+CAaQt+Lqaz2ajPGL+phmhN+aDBfYxgyAywG5X7JCqew5eB3dzhs0yqGWAAwUaxadswo9uFOoOAPEVxQs/RNrSawBo7s2RuS4+RHniztnXNDWrDthxV/4liIvPhyjwB0DFckXFoDiarNOS5GDOmipTgNpRvFwdQO1IQhltt62G249v9e+S/4NEvfm51/hNsacdTNXkf0m7EKKpTG2/s3KoAbK7y7DTog== 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=ZWyJNJjpZF3KdNgB5U+dmjtDr200PllpefNNzjFPmIY=; b=p3M8xZENg6s4xg5Z62NQHoqNF9XQCNAdDt8q9IZkTN9FMbwp9zfxr2W6a4GDytS+Cp4hDPm+H6D6XoX0VpmrNxvPWIFoqvDm00L4BPyW5QfHLZCDBJHAoUo5eQUN7ugEzex7FXovNj0VeFk/WlETZSTyUZcofCeILnMn/Z0ifSs= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by DM4PR11MB5358.namprd11.prod.outlook.com (2603:10b6:5:395::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5017.25; Fri, 25 Feb 2022 16:34:08 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::f515:598d:4160:b4b8]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::f515:598d:4160:b4b8%4]) with mapi id 15.20.5017.026; Fri, 25 Feb 2022 16:34:08 +0000 From: "Pascal Thubert (pthubert)" To: "roll-chairs@ietf.org" CC: "ROLL WG (roll@ietf.org)" Thread-Topic: draft-ietf-roll-dao-projection-24.txt is out Thread-Index: AdgqZTVcx9ow6yVMQRG8HgeRFdf1Gg== Date: Fri, 25 Feb 2022 16:33:57 +0000 Deferred-Delivery: Fri, 25 Feb 2022 16:32:58 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 013edcfd-752a-4e44-ecc9-08d9f87ca58c x-ms-traffictypediagnostic: DM4PR11MB5358:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: pmEdQs4u0vWGwAd00Rllfdwd24Aqk4jX4tfE/PWi1wCShwNMKG2hBZPYrg8I3rIUNmJnX3pvN063oQgRIHhvRBXtz5GQZSJ2DLahywrLGwkwAiaE/+AFPQjD6tnLrzZXB3wOan5Ox/E93gAyN24m9338DQnHipgf4vpcjoJvoASlJtf2peHQ8jyYOdCOKSqeLqDS1H+xcNLEcUKU6iOpfKaLCpKx2Yj9eHfrcy6Q4eLXsmUSp5ukmEl9OVGGLj0CoxQoYUDeVTteVBSkXlsdgdOOdsPaJ/u8358WmurTzUuq5luLVFoRQMK0HYXsGrXEmzzHkanZ+XOblFIsrSTtV4ycK90kkrOE13RSfzPZ0Ej7Bu3OhUzDMtwjdMBu1fVy3G43wgY58t19Mj9xtgKkoGKW4afWSnJKnOif3v80CtevgV6+Tt+7AynLl4jdLu+odFUl4fPFyIzuYXxLY5C1yhf9uTT4Gjef1NSy/5zSD+q15tjqyf+6HBQzyu9ny6XKDidd4tC3cy8AI5EjystPTEkx43auYq037W/d4GclkCAeAJ9gCUaUA0dffb1bf6VQ44CVBkoZ/ydD7Hh1yQfCbKFAIdultgGQb9Pi2NorMUGg+yB39GzrXXjui+g/7biYU/4aaEeouGYZUJnvH2V+KL7uGifGzhPCWQqM083ObgwTpBgnM6xHHBIiQ1F0OgvJ0L49nSEHvaSo03EEzTBczsiEfw6YjBNCUr/OW5TV7tKjy8pespfbry5M10L2aSxXFZCZoGzYo9zul7i3WcFfMNV9q1tcTAX3NkFddCNcBwef2qFfzzaZmyDhhDVjSuxMfdkNT+loq7e/+xCxmZKyjg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB4881.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(26005)(122000001)(2906002)(38100700002)(66574015)(8936002)(52536014)(5660300002)(6666004)(7696005)(6506007)(86362001)(4326008)(71200400001)(33656002)(8676002)(55016003)(83380400001)(38070700005)(966005)(316002)(6916009)(64756008)(66556008)(66446008)(186003)(66946007)(450100002)(66476007)(9686003)(508600001)(53546011)(76116006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?TO5EXEAA/va0uIDBPGFKZEGbZ2pT8N0anA2Uvu7699a0MbwWa+pbQehmSy?= =?iso-8859-1?Q?gE26aM2EtMmB3YaW0Tpv6JPu5GPQnDdDyX36+Bf0MQM7/vm4GuYXfgolmQ?= =?iso-8859-1?Q?ZXC52O38kR9y7UeMIAleyLuMYyn4bHNfE/vmf8hlATIvTIBQ8kgNt2ojVU?= =?iso-8859-1?Q?W9OFF0fsXgjeBTBqpy6r+pyUDM9o814ESNK3MhGNtleJA4ImysbjXgW1FI?= =?iso-8859-1?Q?JRzMvn7W7EspX3WbD+VblpB/u1dbLSh0qpT3eTtj71aUkYYHy3SVowvtwp?= =?iso-8859-1?Q?+Zm7GwjbYpaBRQvdr4pckeGde5BO/sC2vHWk4Ay8bawYJIzsbBtihZIYIx?= =?iso-8859-1?Q?C6ILzJKWgv5sjsw40q2BcceMMluWy/36AKEw/Bt9NweKRm2wHKxyFc9gLm?= =?iso-8859-1?Q?PHihl5uKbKsnbJE7jVKmYe6u4TMrd1en7FwM9PHroy/t0lB1ZK/kuRD6ok?= =?iso-8859-1?Q?LBh1aAtyh1z0x/XrARr6YcC4sTWQKBjK5J3O3wGQ4R5KT5AOrBMMuPY/b9?= =?iso-8859-1?Q?WOE2gzojuvthIEWwrSupPecuLb4CA2zZqWl08beWxTtE0xJDOtZTRQKr4E?= =?iso-8859-1?Q?fBwXxK+qzpF8nhHjCp0bbvfaJKTepExSEJEGF7/CFNEZI9yBA03hBW0Cw3?= =?iso-8859-1?Q?HtCZX5EPyB7uwGJM7oOUxHjRL6IZHOeKB6jXSwQeDWuvZC5hMwQHHoAY5+?= =?iso-8859-1?Q?DyTOKCArEBCz1He2zK5amI2d9znvUqjGpdoBsVsPYvZKvM/qBF7Qcr1eX/?= =?iso-8859-1?Q?v2Gw3ENPtdinsYYHP+MOrF8QVLfPG8CquU+/b/co4LBXAiT6sXrOFD7nP7?= =?iso-8859-1?Q?4LQmolkqMi7rD7wqwf/+EsFqKj33uP92wVI1qRjByN61DNKc5DIVoyvbBR?= =?iso-8859-1?Q?MAa1MMXcEBHfq1pXrUL6/T0R7W5nkFKSBGVmIIY6uf5YPMeNnNeSMtuoOD?= =?iso-8859-1?Q?xeGPErT7+nYbN1xdcrHk6haezrGO3onfZqALltQU8YqO6bGl+wGjv9h6nO?= =?iso-8859-1?Q?35Pf7i5EMoxgVIrKW0zm9ycFYRbrbxQ2oAaU7ZZTWnPEGhNiJERTOfX1YX?= =?iso-8859-1?Q?DdOfNE/5KGf6S/MeUvyRyLeXvZZFjc3cQscjclDdCibu9tajGcmto8LAzp?= =?iso-8859-1?Q?o/kZ6GgKdfFTiHbhPQ0iFk0xjFh+MDZznsBhPFWMTAAu21Kyz6vec5C5Q2?= =?iso-8859-1?Q?H/yjOInA0ZpnXueCfpiw1ahdmihVRJWElidLeFLROqlpnq0yIpzayBA5ED?= =?iso-8859-1?Q?ioZneXhCBCu7gK8yGNr6b3vDuiNK+eIdL0z1//H3upqmNufddFlA8G2P2W?= =?iso-8859-1?Q?BTh2os/UWfmm2Pvhb+11z0d8WGUBnzgMsUofWlOFs1s0SPm3bEoa029BO0?= =?iso-8859-1?Q?IvnMUY0sEV2IvEN8f2iRndFBQeEyAYq1NsVkE0r61R+doHG9Cqw96tiKqu?= =?iso-8859-1?Q?k2MMNP4kGZg/8FBTeoyVSXWyOj1pppQb8muOCB47wVGDvH26wxbLbKRcxs?= =?iso-8859-1?Q?LqWvOJIv5O6QPEIK95C1TtafINynlTtFNkH7+4sxVmUWsAqdyUUDDcDBVz?= =?iso-8859-1?Q?YQRmZz55vczg8KKbmYElx0ukRh6yYef31HptGiHeDIqxoovWQTxxJAX9Du?= =?iso-8859-1?Q?z691U7RUy7ysZEwACpv4kFNRazO23h31b9nH4cUFtvb91nEMrQGrLagGpp?= =?iso-8859-1?Q?9WYCXvOfXMKHkuPEylw=3D?= 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: 013edcfd-752a-4e44-ecc9-08d9f87ca58c X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2022 16:34:08.5964 (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: /LlCwq0TkdklFURVPEdEjpn03JnBahWnB/g5YKXN1ysumtJjir3TcF8DHbeqYg+yX7mt4t54bxOsKyf+j+qUTg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR11MB5358 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.16, xbe-aln-001.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: [Roll] draft-ietf-roll-dao-projection-24.txt is out 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, 25 Feb 2022 16:34:18 -0000 Dear chairs I believe that this addresses all the known issues. Also, Michael's contrib= utions are now recognized as full authorship. Based on the discussion at the previous IETF and the special issue meeting,= I believe that we are now ready for WGLC. Take care, Pascal -----Original Message----- From: Roll On Behalf Of internet-drafts@ietf.org Sent: vendredi 25 f=E9vrier 2022 17:29 To: i-d-announce@ietf.org Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-dao-projection-24.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy networks = WG of the IETF. Title : Root initiated routing state in RPL Authors : Pascal Thubert Rahul Arvind Jadhav Michael C. Richardson Filename : draft-ietf-roll-dao-projection-24.txt Pages : 84 Date : 2022-02-25 Abstract: This document extends RFC 6550, RFC 6553, and RFC 8138 to enable a RPL Root to install and maintain Projected Routes within its DODAG, along a selected set of nodes that may or may not include self, for a chosen duration. This potentially enables routes that are more optimized or resilient than those obtained with the classical distributed operation of RPL, either in terms of the size of a Routing Header or in terms of path length, which impacts both the latency and the packet delivery ratio. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-dao-projection/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-roll-dao-projection-24.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-dao-projection-24 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-dra= fts _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From nobody Fri Feb 25 13:10:19 2022 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D13313A0806 for ; Fri, 25 Feb 2022 13:10:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAuXhsU3N38O for ; Fri, 25 Feb 2022 13:10:11 -0800 (PST) Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) (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 A07B63A07F1 for ; Fri, 25 Feb 2022 13:10:11 -0800 (PST) Received: by mail-yb1-xb2f.google.com with SMTP id c6so8290135ybk.3 for ; Fri, 25 Feb 2022 13:10:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20210112; h=mime-version:from:date:message-id:subject:to:cc; bh=4YkfqiANKDSQGH+R4TC+tD7PVzWcOMtiRlKW8KrLPvw=; b=RMcC3/rGGBCObKmYZn6MkthAhW6Yr2qi0tBFNShEEIEX1dohBoxpai97jAl7Y0v39a bpLAboV5JYx1VA6lI9XRoCc2CSy+0C7wmL9Qn5KBxZQtEMzwTTxHExCfnJ1MbbakrLox 3Ws14lg3gBxhYW05AWqEhiK80d8G4241J7Nc8GyaU1CEellopSxSNrF0djhgLmP1P1ij +nM/b9N2XlO6zCGByjWTEQv/oXnV93LQuClvzt8ltwOD7XZf6V6ibvUUeqSxhPRQlH3+ YJn6hubeyyj6N2VYsCwqS4GHcbhmq+8PrLSDslsZGpLyJ1hNMVS3RoIPwz81b3HnUZIQ RN/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=4YkfqiANKDSQGH+R4TC+tD7PVzWcOMtiRlKW8KrLPvw=; b=EvOeLGKw5QszGxzn4u7jlGASWNAuMSRciNz5IVsVTqEqgGRrqXQkhQsvSyS/3SW7GE p0CYFYiO9tZ61/bJlTd2V7Lkr+MqOrAYCRUK06WP/dxx3Bf/V8hrZGwEiloYmGoGmFbD 81OJYN5Hf5WdoBX20Usx2NQTpaeHyUhvGP9QYIaZPZ3Z8hTN/fbf1Bi9T1LOEfjmWbDB x5m/6naDsGWxbczrhhma5EBOu+SNtHtBngo9uMLYrw7sSPHWRNZur39wGsBn5fWicN3t GzLZmKsK4RtRsPOYXp4l/rI4/dsA3PMPV78z2hzJs41IDbzYRIKH4x/RWW4VsVqhRcUl ailA== X-Gm-Message-State: AOAM532q1+CHzoJrit7rBCHa1DrKXGzCqknCAJw1DTYaGpwEzXVpV3+E cMWDvT2rC6hGv1VpFASEdo2Tcw4UB3G1nWfrIa+HxZ7uYUM= X-Google-Smtp-Source: ABdhPJwxzQBrnLLvQ/ROU2iOn1ImePI0rhX6KS5eIJxkK+EfR7LTlfLzv77VqDUmErhSwVjIn8TNew5KFt1CHl3suWQ= X-Received: by 2002:a25:8a0b:0:b0:61e:1688:f684 with SMTP id g11-20020a258a0b000000b0061e1688f684mr9345576ybl.323.1645823410523; Fri, 25 Feb 2022 13:10:10 -0800 (PST) MIME-Version: 1.0 From: Ines Robles Date: Fri, 25 Feb 2022 23:09:34 +0200 Message-ID: To: roll Content-Type: multipart/alternative; boundary="000000000000bf552505d8de1f90" Archived-At: Subject: [Roll] Call for reviews for draft-ietf-roll-dao-projection-24 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, 25 Feb 2022 21:10:17 -0000 --000000000000bf552505d8de1f90 Content-Type: text/plain; charset="UTF-8" Dear all, We are looking for reviews of the draft-ietf-roll-dao-projection-24. Please let us know if you are willing to review this draft by 3rd March. Thank you in advance, Ines and Dominique. --000000000000bf552505d8de1f90 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

We are looking for review= s of the draft-ietf-roll-dao-projection-24. Please let us know if you are w= illing to review this draft by 3rd March.=C2=A0

Th= ank you in advance,

Ines and Dominique.=C2=A0
--000000000000bf552505d8de1f90-- From nobody Fri Feb 25 17:36:32 2022 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B2AA13A1094; Fri, 25 Feb 2022 17:29:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: aretana.ietf@gmail.com, roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164583895371.24617.11137071000462160787@ietfa.amsl.com> Date: Fri, 25 Feb 2022 17:29:13 -0800 Archived-At: Subject: [Roll] roll - Requested session has been scheduled for IETF 113 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: Sat, 26 Feb 2022 01:29:22 -0000 Dear Dominique Barthel, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. roll Session 1 (1:00 requested) Wednesday, 23 March 2022, Afternoon session I 1300-1400 Room Name: Park Suite 8 size: 145 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/113/sessions/roll.ics Request Information: --------------------------------------------------------- Working Group Name: Routing Over Low power and Lossy networks Area Name: Routing Area Session Requester: Dominique Barthel Number of Sessions: 1 Length of Session(s): Number of Attendees: 25 Conflicts to Avoid: Can't meet: Wednesday morning, Wednesday early afternoon, Friday morning People who must be present: Alvaro Retana Dominique Barthel Ines Robles Michael Richardson Resources Requested: Special Requests: most likely, both chairs are going to be remote. --------------------------------------------------------- From nobody Sat Feb 26 10:03:17 2022 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9EB33A0B28; Sat, 26 Feb 2022 10:02:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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 KQ7vdm0sAJTn; Sat, 26 Feb 2022 10:02:56 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A54003A0B47; Sat, 26 Feb 2022 10:02:42 -0800 (PST) Received: from [192.168.217.118] (p5089ad4f.dip0.t-ipconnect.de [80.137.173.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4K5ZHM4q8zzDCbR; Sat, 26 Feb 2022 19:02:39 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 667591359.458362-6d21281aee8bf79b59bc7d942174d096 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Message-Id: <09735461-73C3-4C0B-8E1B-65634F826118@tzi.org> Date: Sat, 26 Feb 2022 19:02:39 +0100 To: 6lo@ietf.org, 6tisch@ietf.org, lp-wan@ietf.org, lwip@ietf.org, roll@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: [Roll] Constrained Node/Network Cluster @ IETF113: FINAL AGENDA 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, 26 Feb 2022 18:02:59 -0000 Here is my usual eclectic condensed agenda based on the "FINAL" AGENDA for IETF113. Remember that further agenda changes can still happen. The IoT-relevant conflicts that most meet the eye this time are LPWAN/ACE (probably little actual overlap) and DRIP/ROLL/RATS (probably a little more overlap, but not that much). CFRG and ICNRG are the only RGs not on top of IoT meetings (T2TRG, like e.g. CBOR and JSONPATH, decided to go for interims instead). In the "FINAL" agenda, DANCE is now on top of CORE; not much else has changed from a constrained node networks point of view. All times are in UTC. Note that the third and fourth weeks in March (W11 =3D pre-IETF week, W12 =3D IETF week) are Weeks of Confusion, where DST has not yet started in Europe but did already start in North America. https://datatracker.ietf.org/meeting/agenda-utc might be handy. Gr=C3=BC=C3=9Fe, Carsten (### DST in US, no DST in EU ###) SATURDAY, March 19, 2022 0830-2000 Hackathon - Grand Klimt Hall 1/2 0930-1000 Hackathon Kickoff - Grand Klimt Hall 1/2 SUNDAY, March 20, 2022 0830-1500 Hackathon - Grand Klimt Hall 1/2 (0900-1700 IETF Registration - Park Ensemble) 1300-1500 Hackathon Results Presentations - Grand Klimt Hall 1/2 (1600-1800 Welcome Reception - Grand Park Hall 1/2/3) MONDAY, March 21, 2022 0900-1100 Morning Session I G Park Hall 3 ART dispatch Dispatch WG - Joint with ARTAREA G Park Hall 1 OPS v6ops IPv6 Operations WG G Klimt Hall 2 RTG raw Reliable and Available Wireless WG Park Suite 9 SEC openpgp Open Specification for Pretty Good = Privacy WG Park Suite 8 SEC *** teep Trusted Execution Environment = Provisioning WG 1200-1300 Afternoon session I Park Suite 8 ART sedate Serialising Extended Data About Times = and Events WG G Park Hall 2 IRTF pearg Privacy Enhancements and Assessments = Research Group Park Suite 3 SEC acme Automated Certificate Management = Environment WG Park Suite 9 SEC *** cose CBOR Object Signing and Encryption WG G Park Hall 3 TSV tsvwg Transport Area Working Group WG 1330-1530 Afternoon Session II G Klimt Hall 2 SEC *** lake Lightweight Authenticated Key Exchange = WG Park Suite 8 SEC oauth Web Authorization Protocol WG G Park Hall 1 TSV masque Multiplexed Application Substrate over = QUIC Encryption WG TUESDAY, March 22, 2022 0900-1100 Morning Session I Park Suite 9 INT 6man IPv6 Maintenance WG G Park Hall 1 RTG can Computing-Aware Networking BOF Park Suite 3 SEC *** rats Remote ATtestation ProcedureS WG G Park Hall 3 TSV quic QUIC WG 1200-1300 Afternoon session I G Park Hall 2 INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG G Park Hall 1 IRTF qirg Quantum Internet Research Group Park Suite 3 SEC *** ace Authentication and Authorization for = Constrained Environments WG Park Suite 8 SEC emu EAP Method Update WG Park Suite 9 TSV tsvarea Transport Area Open Meeting 1330-1530 Afternoon Session II G Klimt Hall 2 INT intarea Internet Area Working Group WG G Park Hall 2 IRTF irtfopen IRTF Open Meeting G Park Hall 1 RTG detnet Deterministic Networking WG G Park Hall 3 SEC secdispatch Security Dispatch WG WEDNESDAY, March 23, 2022 0900-1100 Morning Session I G Klimt Hall 2 ART moq Media Over QUIC BOF Park Suite 8 INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Park Suite 9 IRTF maprg Measurement and Analysis for Protocols G Park Hall 2 RTG rtgarea Routing Area Open Meeting G Park Hall 3 SEC tls Transport Layer Security WG 1200-1300 Afternoon session I Park Suite 2 ART mediaman Media Type Maintenance WG G Park Hall 1 INT *** drip Drone Remote ID Protocol WG Park Suite 8 RTG *** roll Routing Over Low power and Lossy = networks WG Park Suite 3 SEC mls Messaging Layer Security WG G Park Hall 3 SEC *** rats Remote ATtestation ProcedureS WG G Park Hall 2 TSV taps Transport Services WG 1330-1530 Afternoon Session II Park Suite 3 RTG bier Bit Indexed Explicit Replication WG 1600-1800 IETF Plenary - Grand Park Hall 1-3 THURSDAY, March 24, 2022 0900-1100 Morning Session I G Park Hall 2 ART httpapi Building Blocks for HTTP APIs WG G Park Hall 1 INT savnet Source Address Validation in = Intra-domain and Inter-domain Networks BOF G Klimt Hall 2 IRTF coinrg Computing in the Network Research Group Park Suite 9 OPS *** iotops IOT Operations WG G Park Hall 3 SEC saag Security Area Open Meeting 1200-1300 Afternoon session I G Park Hall 3 INT madinas MAC Address Device Identification for = Network and Application Services WG G Klimt Hall 2 IRTF panrg Path Aware Networking RG Park Suite 8 RTG rift Routing In Fat Trees WG Park Suite 3 SEC privacypass Privacy Pass WG G Park Hall 2 SEC *** suit Software Updates for Internet of Things = WG 1330-1530 Afternoon Session II G Klimt Hall 2 ART webtrans WebTransport WG G Park Hall 2 INT add Adaptive DNS Discovery WG G Park Hall 3 IRTF cfrg Crypto Forum Park Suite 2 SEC oauth Web Authorization Protocol WG FRIDAY, March 25, 2022 0900-1100 Morning Session I G Klimt Hall 2 ART *** core Constrained RESTful Environments WG Park Suite 8 SEC dance DANE Authentication for Network Clients = Everywhere WG G Park Hall 2 SEC gnap Grant Negotiation and Authorization = Protocol WG G Park Hall 3 TSV tsvwg Transport Area Working Group WG 1130-1330 Afternoon Session I Park Suite 3 IRTF icnrg Information-Centric Networking G Klimt Hall 2 OPS anima Autonomic Networking Integrated Model = and Approach WG (### DST STARTS IN EUROPE ON SUNDAY ###) From nobody Sun Feb 27 18:28:36 2022 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E413A03F2 for ; Sun, 27 Feb 2022 18:28:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.595 X-Spam-Level: X-Spam-Status: No, score=-9.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-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=XOd+p6sS; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=NyOA/LFh 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 ae2hCgpC--3R for ; Sun, 27 Feb 2022 18:28:29 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAC383A0317 for ; Sun, 27 Feb 2022 18:28:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=48661; q=dns/txt; s=iport; t=1646015307; x=1647224907; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=KzG2gywTPGLEsD24YaMjjm9TKgPOBDyBUUb3MKMwZyI=; b=XOd+p6sSGXXbYxvrhG8H+dK9bg9lRgkQfqRTJwpJX2m4KF1qzy1QYFxW yeABYM2LLKXdUP3KHPgO+2MzfySxyk5oCQawk2NusscJFtcynF6bmovEb 9E4EiNEKakjf7yeIBJjZyPFOqZUwSR/cJao+sYAseR+t0qksxkqvpt74y 4=; IronPort-PHdr: =?us-ascii?q?A9a23=3Anzz57BRl4pgbeNBCWisDIOK6Rtpso7vLVj580?= =?us-ascii?q?XJvo75Nc6H2+ZPkMQSf4Ph2l1bGUM3d7O4MkOvZta3sGAliqZaMuXwPatpAA?= =?us-ascii?q?hkCj8hFkwkpGsXQD0r9IbbjZDA7G8IXUlhj8jm7PEFZFdy4aUfVpyi57CUZH?= =?us-ascii?q?VP0Mg8mTtk=3D?= IronPort-Data: =?us-ascii?q?A9a23=3A4Idy2KNWf7FDVfbvrR20lcFynXyQoLVcMsEvi?= =?us-ascii?q?/4bfWQNrUoj1zJVzDYeW2CBO/qONzOnL9gjYITi/UgB7ceGz9ZgGnM5pCpnJ?= =?us-ascii?q?55oRWUpJjg4wn8dtEp+F+WbJK5cx5hYOomowPwcFCeG/E/3auG59BGQ6InRL?= =?us-ascii?q?lbCIL+cUsxObVcMpBcJ0XqPqsZh6mJaqYHR7zCl4bsel/bi1GqNgFaYBI67B?= =?us-ascii?q?5Wr83uDtNyq0N8RU8dXifpj5DcynFFNZH4TyD3YEpf2fmVUNrbSq+fr1rq1+?= =?us-ascii?q?CbS+A0gT4r91L36aUYNBLXVOGBiiFIPBPPk2UcE93d0i/plXBYfQR8/ZzGhm?= =?us-ascii?q?9Fjk/1GtIe7TkEiOaikdOE1AkYFQ30gZ/EfkFPACT3l2SCJ9GXcdH/o6/RjE?= =?us-ascii?q?E9wOpcXktubq0kmGecwMjsBaFWIgPi7hevjDOJtnc8kasLsOesiVrhb5WmxJ?= =?us-ascii?q?Z4brVrrGc0mPeNl4Qo=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AyLjIX6Buwuh/LIrlHegTsceALOsnbusQ8z?= =?us-ascii?q?AXPh9KKCC9I/b3qynxppsmPEfP+UossQIb6K+90ci7MD/hHPtOgbX5Uo3SJD?= =?us-ascii?q?UO1FHYSb2KqLGSvgEIeBeOudK1t50QCJSWYeeYZTMR4KqKg3jbLz9j+qj8zE?= =?us-ascii?q?nCv5a4854Zd3ASV0gW1XYeNu/0KDwTeCB2Qb4CULaM7MtOoDStPV4NaN6gO3?= =?us-ascii?q?UDV+/f4/XWiZPPe3c9dlAawTjLqQntxK/xEhCe0BtbeShI260e/W/MlBG8zr?= =?us-ascii?q?m/ssu81gTX2wbontVrcZrau5t+7f63+4oowwbX+0OVjUNaKvm/VQUO0aKSAZ?= =?us-ascii?q?AR4Z7xSlkbToJOAjjqDx+ISFPWqnjdOXAVmibfIZvyuwq5nSQ/LwhKU/apzL?= =?us-ascii?q?gpAifx+g4uuspx37lM2H/cv51LDQnYlCC4/NTQUQp2/3DE6kbKvNRjxkC3a7?= =?us-ascii?q?FuIIO5bLZviH99AdMFBmb3+YonGO5hAIXV4+tXa0qTazTcsnN0yNKhU3wvFl?= =?us-ascii?q?PeK3Jy9/C9wnxThjR03kEYzMsQkjMJ8488UYBN46DBPr5znL9DQ8cKZeZ2Bf?= =?us-ascii?q?sHQ8GwFmvRKCi8el66MBDiDuUKKnjNo5n47PE84/yrYoUByN8olJHIQDpjxB?= =?us-ascii?q?gPkoLVeLqzNbFwg2LwqT+GLEfQI+lllu1EhoE=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A6BgByHvlh/5JdJa1agQmBWoEhMVY?= =?us-ascii?q?Hd1o3MYgQA4U5hQ6DAgOBE48ngjGIOYEuFIERA1QLAQEBDQEBNwoEAQGFBQK?= =?us-ascii?q?DXwIlNAkOAQIEAQEBEgEBBQEBAQIBBgSBCROFOwEEKA2GQgEBAQEDDAYVBhM?= =?us-ascii?q?BASUTDwIBCBEDAQEBHgMBBgcyFAkIAQEEARIIGoJjgg5XAy4BDqIrAYE6Aoo?= =?us-ascii?q?feIEBMoEBgggBAQYEBIUNGII3AwaBOoMOgn5USocJJ4IpgRQBQ1WBEUo3PoJ?= =?us-ascii?q?jAgKBJBwEHB4GBwmDGYIukTYQFUYOYA0HLw4CBBwCKwMrHjcKDgECEgcPHws?= =?us-ascii?q?RfwGeRo1ykmEGBINGiwGLHYldFZQwk1eWSiCMb5QnFwsLhF8CBAIEBQIOAQE?= =?us-ascii?q?GgWE8gVlwgW6BS1EZD4Vrgl+GDYM6hRSFSnQCNgIGAQoBAQMJiwYHgj8BAQ?= X-IronPort-AV: E=Sophos;i="5.88,333,1635206400"; d="scan'208,217";a="975846241" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Feb 2022 02:28:26 +0000 Received: from mail.cisco.com (xbe-aln-001.cisco.com [173.36.7.16]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 21S2SQ2s030428 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for ; Mon, 28 Feb 2022 02:28:26 GMT Received: from xfe-rtp-005.cisco.com (64.101.210.235) 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.986.14; Sun, 27 Feb 2022 20:28:00 -0600 Received: from xfe-aln-005.cisco.com (173.37.135.125) by xfe-rtp-005.cisco.com (64.101.210.235) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Sun, 27 Feb 2022 21:27:58 -0500 Received: from NAM02-BN1-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-005.cisco.com (173.37.135.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Sun, 27 Feb 2022 20:27:58 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Cj6zOmeKygqyfCCAJPdv+x1VEbA38m+jowYIOuup8ROwanixXkmgeb8isLr1UmDcp0pXGDSN/xzZGOP6s2yAsUhQHAk5hgLh305j2eLLhKYaA8MdX7JgCJxN6ITGp0Yl5hs2ZvPh9QGDhOwZ8oGYCvVO2jGQonHBamuWbHoO+8YfLZTrK6iDYWY9YVlEVWAT+escVSKiIGiKdpv9naZhbD3zcSLHXSO1dfZrJ98on/soWGEMSuriOvpKk6De8xqIVI2UKabQa0wQaSk1qWGeo2bhCh3IAE83bIlS6bw+ikUuw6pT3X7lgVMtQ1GSuAL4sOpNnwaOiafTGCjfc4sqHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Lysf/MlAYVNOkzWkR40K/jp6SOUyybAdWmE7jKx3mxA=; b=ki4W824bRZXLKYvQR3t715UPrSHykidqEnmUDHfE1rIGd1ewKtTLr6Wvpa6HVLByBXfHTKv+Ewh0Mk42lrDou3lXeby5X/2XWKyIM4pYjf7i/Bul6AQuDB7Dh+8d6j7omSoXabpm33pPtGLIdey9vqB12U+5V/7mbgHjoMsivZWhiLUo30QclLDryTCy3Yo/O+jshr7s4jSjGatyAB0lqVrHuPjoq2vjO02crri03EsN5qT/bEavxhlnbJPecx4Pv5fW/AjEzqjtVjC8voE6mFKiFrrRH5qiKpvAq0XPl4eyFJv7KvSyXpdfSf6cCbpUFkKe0xglpYzyp4ExfjDzRA== 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=Lysf/MlAYVNOkzWkR40K/jp6SOUyybAdWmE7jKx3mxA=; b=NyOA/LFhpa/m4qB2rR9w/3r3/rkHAmf8DWGm8B89s4I++9r4rf7lDg6KarC0ruVrO687ZZE+zYX2KOG7P3W0+7dirv5D0KK3xhsuNhwX+rZzmlgvM2dTe0D5EYAmF2URIOZh9u1zlbftjLHaNmZ865uqw3dFVeRbBZNHe3wYOlg= Received: from PH0PR11MB4919.namprd11.prod.outlook.com (2603:10b6:510:34::12) by DM5PR11MB1243.namprd11.prod.outlook.com (2603:10b6:3:8::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5017.26; Mon, 28 Feb 2022 02:27:56 +0000 Received: from PH0PR11MB4919.namprd11.prod.outlook.com ([fe80::6d55:7f2e:6f4:2d4a]) by PH0PR11MB4919.namprd11.prod.outlook.com ([fe80::6d55:7f2e:6f4:2d4a%4]) with mapi id 15.20.5017.026; Mon, 28 Feb 2022 02:27:56 +0000 From: "Li Zhao (liz3)" To: "Pascal Thubert (pthubert)" , "ROLL WG (roll@ietf.org)" Thread-Topic: Reporting Links: Bidirectional vs Symmetrical (Was: review of dao-projection -22) Thread-Index: AdgpcUWc8mKMuUnWSsS5Bax1TjHaYwAcilJNAB08/dAAfIcSgQ== Date: Mon, 28 Feb 2022 02:27:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 33b4c28a-be06-47a5-b5ff-08d9fa61ee3e x-ms-traffictypediagnostic: DM5PR11MB1243:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0JEvAhAqQJXk/fVhMIS8prF6/pMa9SMaOeY6Et+RVfhs20CTs78moN2pxNKtAb50uk69nqlusnuEUxNJRw+3ZU0LeSmFSu9uPZ8t8+xAHDaMYXnCLjSt/pZzaTS9/YebWQtttOlAcLmMkXPn9pBlqQ8hFetMeoj4nA0ZhHk8O7m3RONGk2jPUXvLzMQ1jBYWp4P7hRC+kWu/09eIqZyInaX6tUVXKR5XS/FJBjUbeVxA60XKsdZkfg6dFqUh2isWEyJuFo4shgxTyAK7LFBco7nD5fRGD6/3GEeSl+tsxA8jZ5j7ucn9AKsnls69XEj8gPieCdukuBoSG8/IbVdpEoccKoz3p+v6EhKlWFxc7d6RGkdpZL3QxHMyC7PJ/rCu36Nwf8GTSQGSu3XxKc55w6CiDSx7jS7oV/b6ubU+oJOvPNm5nwNaz34f5G4SudrPp9k7kv73ZZ9Y+ErWDImCGXRdUKVOlzp48Rz+J8k4LcILxMad05tiK9Kp/65V85IYr4xomgq+ifVIeXZdpE3jIHAOd+0VWiKQiwTJongh8UOFURZzmKoms4hETXh9NuVzGRTuEDS3o5Xx0wN4vfrXivOPYPUiw+F9/LtRzKKaVNitF3bizsmeZhKFodcQIbZJCBLiVjwrYPr6NkVMZlhEEHU6OqJNiQgBrYN/qJvDmbMmd2Gtc4ebl0ro78pvuTL5kvpNHPBIUldwJZRV/zEFqpCCK72l+L2trbtE9Rnid+AbU/adJSxyWaomYGcR1usW3ZV+hJPNCFor4bd/dDrVjKqPc/V/qGh3qDV0oE9LCJ2EQsPvBWzLfn4FCIGS5rV8umuAOULPnsRcf9VZBTQhLSB/q+ypgyCQCno/JeKGOdg= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4919.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(9686003)(316002)(53546011)(66574015)(7696005)(71200400001)(38070700005)(6506007)(110136005)(55016003)(86362001)(966005)(508600001)(122000001)(166002)(186003)(91956017)(52536014)(83380400001)(38100700002)(5660300002)(33656002)(64756008)(8936002)(8676002)(66946007)(66476007)(66556008)(66446008)(2906002)(76116006)(88722004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?6gge8kZcI5noeXKM0gXvfWU2dGa7EioLwL87b42YcNZgLCfiW+oAjjXw?= =?Windows-1252?Q?iAE1luEoKhpV7ttlP1okD6llm3W8AR522/qYwpBjEz0LZTBMNLgsM0bY?= =?Windows-1252?Q?YNIwFX+krfd/QrEJJnMJ4SS7GNGSaS3Qi61iEDCfg65PEQrtlTKd26ln?= =?Windows-1252?Q?lKl3Mherubd6ZBOdtygqQB8AXve67Gtj+Vq4TCz4BKDBEzlnsYwWuMCo?= =?Windows-1252?Q?/3Cr8IyDqURDOokP2XW2b+fFVoKl88Gr4oASKjmYHF22LFsNmeYF7Of2?= =?Windows-1252?Q?g6wXYPBqt6vTubnODaEyIBv/3yKtNbo+E+X+zo1jx1XA+0nbbnLtet9J?= =?Windows-1252?Q?Qz79cI90vVmikRYvk7xPdPbFE/aUfH/GmgCQ0lQCjbp50SRscl/97Xlz?= =?Windows-1252?Q?FncN0TF1AiU19hncnx6kFkbqZgaJBdDOBkHa6+s0IZSsveBtUarz9ij5?= =?Windows-1252?Q?1sYb1yDhKKB36//pijbdxZE01fCw2RXLwg6PsKTUWW9yK+n5MKa9tXDa?= =?Windows-1252?Q?HhB+Ze0kPrtRJ2eP2EVdUO4pKmZJksuktyJswyzz97ZiEZOluRmmh9LH?= =?Windows-1252?Q?P4WwCAf/37uc0kr2yN9Ea4Z9ZNzNAzlnEqIhmy07/O88R6w+LvseAiKY?= =?Windows-1252?Q?lK5/M3ouVRH/Xp1U7OUSq40RJ78LnrKiJEh+j+yxjrSN8BndivAsNorG?= =?Windows-1252?Q?iz1wdJmIpVjnm7cGYZgQhn/dFKMHOVwihs6w5yxdW+jr7O6TLosDSfaQ?= =?Windows-1252?Q?j+DuUw8V/gtH9Mvn8at/vOjVZKULKvSULx7A65gBBD5RxQob82W72Yj8?= =?Windows-1252?Q?AJGDA39QKE5X/lVhhVqNm9RaW4Is59kFsrwdsgy1zx+QyHrythJhRyWh?= =?Windows-1252?Q?0RzGAE7SrG2HfcFCMHwx0PJdVePr6cvM8uTZAb2VwWUaM1HM+D/c3asT?= =?Windows-1252?Q?5nnPPGg8C50OmgVEzhFuTcFt/jexVhNK4qoRRbGikJvb78kq8M5tDFe/?= =?Windows-1252?Q?LF6nwDowJyznU65bFCaIDjv0XdafIXodYgZV1RQpDMXG5dh/Cj1JXWg4?= =?Windows-1252?Q?IMiiAauelu49fQu4cnqbkF3E4r7ksszM9e6ls6k2lZCmQ0FsHW/5/y+x?= =?Windows-1252?Q?k8w+hxCYbL8GdG9SDwXPmXkdAvWALlkg9ENs4WEciaKdTi41QHeLzn3a?= =?Windows-1252?Q?LSYFPb3A079UPyAQ5zOGt7PEUAlUoLsqKYzlLL5L47jhFJca55zr8bs9?= =?Windows-1252?Q?v05w2v7A/Yro/5ztx25A7nNX66u+b7SUHBwF0gcustekJISPwtkE60Y7?= =?Windows-1252?Q?yE4xAYa2agAsKK4dONVqrBJxpMKEUrG3/9I2LKrKkxKnfG4CmEJRR0Hl?= =?Windows-1252?Q?T+xkzeeAEu8Mov0GxaDGTkTo2tv7HarrrK90lOCCeH0esbNQwl9p9DlR?= =?Windows-1252?Q?tfvH/0bnWOVZcGGOE+NybX9cfb0ur0WRdjVlFJGmVTFlfvqxlP4MwU3P?= =?Windows-1252?Q?WWvAG7/UfAT78ghizYg+54puGWi4H0mennmejl/lHCz5F8phNhlWsElW?= =?Windows-1252?Q?PTy64qkSio90Xs7G02EyhwCv/v+0M8X+tKCqKgfmT4bcaPYz6g2xbXWz?= =?Windows-1252?Q?3AhlYg1nFxudnEbR2rhrAwPWDY2+QVs1a2Cc51EANg0ToXfUfbh51ZMp?= =?Windows-1252?Q?61HPwd+xHTO/+3g85Ks3UkpCpkXRrPvQHWCLNxKtaebi/g+/PysqbH8S?= =?Windows-1252?Q?OgnBTnWD59ZRiMbc3KaxFhvbtE91u29i0y/+pKHm?= Content-Type: multipart/alternative; boundary="_000_PH0PR11MB4919BF12A8FA9E9E839B5C7E8C019PH0PR11MB4919namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4919.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 33b4c28a-be06-47a5-b5ff-08d9fa61ee3e X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2022 02:27:56.4089 (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: G4Rq7bJauTd9FdOWqpKkmhXSQzkQ/20mQV8X5gZJrEtrA+YhyVkbNAmobvtqLSaR X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1243 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.16, xbe-aln-001.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [Roll] Reporting Links: Bidirectional vs Symmetrical (Was: review of dao-projection -22) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2022 02:28:34 -0000 --_000_PH0PR11MB4919BF12A8FA9E9E839B5C7E8C019PH0PR11MB4919namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Pascal, It works for me. =93If the SIO is effectively received from both sides then= the B flag MUST be ignored.=94 Best regards, Li From: Pascal Thubert (pthubert) Date: Saturday, February 26, 2022 at 00:20 To: Li Zhao (liz3) , ROLL WG (roll@ietf.org) Subject: RE: Reporting Links: Bidirectional vs Symmetrical (Was: review of = dao-projection -22) Hello Li: This is an error case that does not impact interoperation, but I agree it = is worth mentioning. I like option 2 since the source knows better. IMHO If you receive information from both sides you should ignore the B fla= g. Proposal to add: =93 If the SIO is effect= ively received from both sides then the B flag is ignored. =93 Works for you? Pascal From: Li Zhao (liz3) Sent: vendredi 25 f=E9vrier 2022 2:10 To: Pascal Thubert (pthubert) ; ROLL WG (roll@ietf.org)= Subject: Re: Reporting Links: Bidirectional vs Symmetrical (Was: review of = dao-projection -22) Hello Pascal, What about the asynchronism cases? For instance, node A and B are siblings, but node A reports SIO with flag B= , node B reports SIO without flag B later. I think we have three options for this case: 1. Root trusts the latest info. 2. Root trusts the info from source node. 3. Leave it to implementation I prefer option 3 to simplify the flag definition. What do you think? Best regards, Li From: Pascal Thubert (pthubert) > Date: Thursday, February 24, 2022 at 21:00 To: ROLL WG (roll@ietf.org) > Cc: Li Zhao (liz3) > Subject: RE: Reporting Links: Bidirectional vs Symmetrical (Was: review of = dao-projection -22) Dear all This is now issue 11 in github https://github.com/roll-wg/dao-projection/is= sues/11 The spec alone does not provide a way to assert whether the link is bidir o= r not. Some techs may leverage existing L2 information or sync/compare their DLEP = state but that needs to be defined for a specific case/technology. So I suggest we add text like: =93 The SIO carries a flag (B) that is set when similar performances can be expected both directions, so the routing can consider that the informat= ion provided for one direction is valid for both? The policy that describes= the performance criteria, and how they are asserted is out of scope. In the absence of an external protocol to assert the link quality, the = flag SHOULD NOT be set. =93 What do you think? Pascal From: Pascal Thubert (pthubert) Sent: vendredi 14 janvier 2022 11:20 To: ROLL WG (roll@ietf.org) > Cc: Li Zhao (liz3) > Subject: (Was: review of dao-projection -22) Dear all: we had this thread as part of Li=92s review: About =935.4 only the router with the lowest Interface ID in its registered= address needs report the SIO, and the Root will assume symmetry.=94 [Li] -> Is it possible to add a flag to indicate the symmetry? Otherwise, i= f A chooses B as sibling, but B doesn't choose A as sibling, Root may treat= SIO from A as symmetry incorrectly when only receiving SIO from A. [PT] we used to have that (B Flag for bidir) but we removed it for simplifi= cation. I=92m OK to add it back, but we still lake a good description of ho= w the node will know that the link is roughly symmetrical. [Li] Some physical layer measurements such as RSSI/LQI have forward and rev= erse direction. Can it indicate symmetrical? In layer 3, receiving DIO/NS messages from each other ind= icate symmetrical [PT] There=92s a nuance between bidir and symmetrical. Maybe the ping work= s but the link quality is very different in both directions. If so the Rank= increment computation would differ widely and we would need both sides. At the moment the text says: =93 B: 1-bit flag that is set to indicate that the connectivity to the sibling is bidirectional and roughly symmetrical. In that case, only one of the siblings may report the SIO for the hop. If 'B' is not set then the SIO only indicates connectivity from the sibling to this node, and does not provide information on the hop from this node to the sibling. =93 We need to clarify what the B flag means, when it can be set, and what is e= xpected from the Root/ PCE about path computation when it is set or not set= . Suggestions welcome; Pascal From: Roll > On Behalf = Of Li Zhao (liz3) Sent: mercredi 12 janvier 2022 10:51 To: Routing Over Low power and Lossy networks > Subject: [Roll] review of dao-projection -22 Hello Authors, Thanks for your great effort. The PDAO draft looks more clear and detailed.= Following is some concern: 3.5.2 Using Non-Storing Mode joining Tracks P-DAO 1 signals C=3D=3D>D=3D=3D>E-to-F,G P-DAO 2 signals A=3D=3D>B=3D=3D>C-to-C,F,G [Li] -> Should it be ? P-DAO 1 signals C=3D=3D>D=3D=3D>E-to-F,G P-DAO 2 signals A=3D=3D>B=3D=3D>C-to-E,F,G Otherwise RIBs in A cannot include destination to E. 4.1. Extending RFC 6550 To ensure that the PDR and P-DAO messages can flow at most times, it is REC= OMMENDED that the nodes involved in a Track =3D=3D=3Dmantain=3D=3D=3D multi= ple parents in the Main DODAG, advertise them all to the Root, and use them= in turn to retry similar packets. It is also RECOMMENDED that the Root use= s diverse source route paths to retry similar messages =3D=3D=3Dot=3D=3D=3D= the nodes in the Track.=B6 [Li] -> Typo for =93mantain=94 and =93ot=94? 4.1.6. This specification defines a new flag "Projected Routes Support" (D). The DODAG Configuration option is copied unmodified from parents to childre= n. =3D=3D=3D=3Dxref target=3D'RFC6550'/>=3D=3D=3D=3D states that: [Li] -> Typo for =93xref target=3D'RFC6550'/>=94. Why is flag named as =93= D=94? There is no D in "Projected Routes Support"=85 5.1 The Root may use an asynchronous PDR-ACK with an negative status to ind= icate that the Track was terminated before its time. [Li] -> What's the difference between negative status PDR-ACK and No-Path P= -DAO in section 6.5? And when to use asynchronous PDR-ACK? In storing mode, root should use No-Path P-DAO to tear down Track from egre= ss node. Is PDR-ACK still needed? In non-storing mode, No-Path P-DAO to ingress node is also enough. But the PDR-ACK Status field makes sense. Is it possible to add this field = in No-Path P-DAO? 5.1 One and only one RPL Target Option MUST be present in the message. [Li] -> Is it possible to remove the limitation? It=92s not flexible If PD= R can only carry one RTO. For instance in figure 7, if node I requests P-Route to B&H together, Root = can only push one Track I->A->B->H. Otherwise, Root may push two Tracks I->= A->B and I->F->G->H. If Root cannot computer one Track to multiple RTO, it can response with a s= pecial PDR-ACK Status. 5.4 only the router with the lowest Interface ID in its registered address = needs report the SIO, and the Root will assume symmetry. [Li] -> Is it possible to add a flag to indicate the symmetry? Otherwise, i= f A chooses B as sibling, but B doesn't choose A as sibling, Root may treat= SIO from A as symmetry incorrectly when only receiving SIO from A. 6.2 There is no notification to the requesting node when those changes hap= pen. [Li] -> Confuse with this claim. Is it a MUST NOT if root wants to send not= ification to the requesting node when those changes happen. 6.3 In a particular deployment where PDR are not used, the namespace can be= delegated to the main Root, which can assign the TrackIDs for the Tracks i= t creates without collision. [Li] -> Can you add some description for the collision case? E.g., node tru= sts itself than Root. 6.4.1 In both cases the Track Ingress is the owner of the Track, and it gen= erates the P-DAO-ACK when the installation is successful [Li] -> Is there any difference between P-DAO-ACK and normal DAO-ACK? E.g.= any flags? Normally, root won't receive any DAO-ACK from nodes. Is it possible to add flag to distinguish P-DAO-ACK from DAO-ACK as P-DAO f= rom DAO. 8 Profiles 0 and 1 are REQUIRED by all implementations that may be used in = LLNs; this enables to use Storing Mode to reduce the size of the Source Rou= te Header in the most common LLN deployments. [Li] -> Profile 0 is the Legacy support of [RPL] Non-Storing Mode. I= =92m confuse about =93this enables to use Storing Mode to reduce the size o= f the Source Route Header in the most common LLN deployments.=94 Best regards, Li --_000_PH0PR11MB4919BF12A8FA9E9E839B5C7E8C019PH0PR11MB4919namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hell= o Pascal,

 

It w= orks for me. =93If the SIO is effectively received from both sides then the= B flag MUST be ignored.=94

 

 

Best= regards,

Li

 

From: Pasc= al Thubert (pthubert) <pthubert@cisco.com>
Date: Saturday, February 26, 2022 at 00:20
To: Li Zhao (liz3) <liz3@cisco.com>, ROLL WG (roll@ietf.org) &= lt;roll@ietf.org>
Subject: RE: Reporting Links: Bidirectional vs Symmetrical (Was: rev= iew of dao-projection -22)

Hell= o Li:

&nbs= p;

This= is an error case  that does not impact interoperation, but I agree it= is worth mentioning. I like option 2 since the source knows better.=

IMHO= If you receive information from both sides you should ignore the B flag.

&nbs= p;

Prop= osal to add:

=93<= /span>

&nbs= p;            &= nbsp;            &nb= sp;            =             &nb= sp;   If the SIO is effectively<= o:p>

&nbs= p;   received from both sides then the B flag is ignored.<= span lang=3D"EN-US">

=93<= /span>

&nbs= p;

Work= s for you?

&nbs= p;

Pasc= al

F= rom: Li Zhao (li= z3) <liz3@cisco.com>
Sent: vendredi 25 f=E9vrier 2022 2:10
To: Pascal Thubert (pthubert) <pthubert@cisco.com>; ROLL WG (r= oll@ietf.org) <roll@ietf.org>
Subject: Re: Reporting Links: Bidirectional vs Symmetrical (Was: rev= iew of dao-projection -22)

 

Hell= o Pascal,

&nbs= p;

What= about the asynchronism cases?

&nbs= p;

For = instance, node A and B are siblings, but node A reports SIO with flag B, no= de B reports SIO without flag B later.

I th= ink we have three options for this case:

  1. Root trusts the lates= t info.
  2. Root trusts the info from source node= .
  3. Leave it to implementation

&nbs= p;

I pr= efer option 3 to simplify the flag definition. What do you think?

&nbs= p;

&nbs= p;

Best= regards,

Li

&nbs= p;

&nbs= p;

From: Pasc= al Thubert (pthubert) <pthubert@cisco.com>
Date: Thursday, February 24, 2022 at 21:00
To: ROLL WG (roll@ietf.org) <roll@ietf.org<= /span>><= br> Cc: Li Zhao (liz3) <liz3@cisco.com>
Subject: RE: Reporting Links: Bidirectional vs Symmetrical (Was: rev= iew of dao-projection -22)

Dear= all

&nbs= p;

This= is now issue 11 in github https://github.com/roll-wg/dao-= projection/issues/11

&nbs= p;

The = spec alone does not provide a way to assert whether the link is bidir or no= t.

Some= techs may leverage existing L2 information or sync/compare their DLEP stat= e but that needs to be defined for a specific case/technology.

&nbs= p;

So I= suggest we add text like:

=93<= /span>

&nbs= p;   The SIO carries a flag (B) that is set when similar performa= nces can be

&nbs= p;   expected both directions, so the routing can consider that t= he information

&nbs= p;   provided for one direction is valid for both? The policy tha= t describes the

&nbs= p;   performance criteria, and how they are asserted is out of sc= ope.

&nbs= p;   In the absence of an external protocol to assert the link qu= ality, the flag

&nbs= p;   SHOULD NOT be set.

=93<= /span>

&nbs= p;

What= do you think?

&nbs= p;

Pasc= al

&nbs= p;

F= rom: Pascal Thub= ert (pthubert)
Sent: vendredi 14 janvier 2022 11:20
To: ROLL WG (roll@ietf.org) <roll@ietf.org>
Cc: Li Zhao (liz3) <liz3@cisco.com>
Subject: (Was: review of dao-projection -22)

&nbs= p;

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

&nbs= p;

&nbs= p;

Abou= t =935.4 only the router with the lowest Interface ID in its registered add= ress needs report the SIO, and the Root will assume symmetry.=94

&nbs= p;

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

&nbs= p;

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

&nbs= p;

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

&nbs= p;            &= nbsp;    In layer 3, receiving DIO/NS messages from each oth= er indicate symmetrical

&nbs= p;

[PT]= There=92s a nuance between bidir and symmetrical.  Maybe the ping wor= ks but the link quality is very different in both directions. If so the Ran= k increment computation would differ widely and we would need both sides.

&nbs= p;

At t= he moment the text says:

=93<= /span>

&nbs= p;  B:  1-bit flag that is set to indicate that the connectivity = to the

&nbs= p;     sibling is bidirectional and roughly symmetrical= .  In that case,

&nbs= p;     only one of the siblings may report the SIO for = the hop.  If 'B'

&nbs= p;     is not set then the SIO only indicates connectiv= ity from the

&nbs= p;     sibling to this node, and does not provide infor= mation on the hop

&nbs= p;     from this node to the sibling.

=93<= /span>

&nbs= p;

We n= eed to clarify what the B flag means, when it can be set, and what is expec= ted from the Root/ PCE about path computation when it is set or not set.

&nbs= p;

Sugg= estions welcome;

&nbs= p;

Pasc= al

&nbs= p;

F= rom: Roll <roll-bounces@ietf.org> On Behalf Of Li Zhao (liz3)
Sent: mercredi 12 janvier 2022 10:51
To: Routing Over Low power and Lossy networks <roll@= ietf.org>
Subject: [Roll] review of dao-projection -22

&nbs= p;

Hell= o Authors,

&nbs= p;

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

&nbs= p;

3.5.= 2 Using Non-Storing Mode joining Tracks

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

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

&nbs= p;

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

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

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

&nbs= p;

&nbs= p;   Otherwise RIBs in A cannot include destination to E.<= span lang=3D"EN-US">

&nbs= p;

4.1.= Extending RFC 6550

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

&nbs= p;  

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

&nbs= p;

4.1.= 6.

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

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

&nbs= p;

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

&nbs= p;

&nbs= p;

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

&nbs= p;

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

In storing mode, root should use No-Path P-DAO to = tear down Track from egress node. Is PDR-ACK still needed?

In non-storing mode, No-Path P-DAO to ingress node= is also enough.

But the PDR-ACK Status field makes sense. Is it possible to add this f= ield in No-Path P-DAO?

&nbs= p;

&nbs= p;

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

&nbs= p;

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

For instance in figure 7, if node I requests P-Rou= te to B&H together, Root can only push one Track I->A->B->H. O= therwise, Root may push two Tracks I->A->B and I->F->G->H.

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

&nbs= p;

&nbs= p;

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

 

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

&nbs= p;

&nbs= p;

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

 

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

 

 

6.3 In a particular deployment where P= DR are not used, the namespace can be delegated to the main Root, which can= assign the TrackIDs for the Tracks it creates without collision.

 

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

 

&nbs= p;

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

&nbs= p;

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

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

&nbs= p;

&nbs= p;

8 Pr= ofiles 0 and 1 are REQUIRED by all implementations that may be used in LLNs= ; this enables to use Storing Mode to reduce the size of the Source Route H= eader in the most common LLN deployments.

&nbs= p;

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

&nbs= p;

&nbs= p;

&nbs= p;

Best= regards,

Li

&nbs= p;

&nbs= p;

&nbs= p;

&nbs= p;

&nbs= p;

&nbs= p;

&nbs= p;

&nbs= p;

&nbs= p;

&nbs= p;

--_000_PH0PR11MB4919BF12A8FA9E9E839B5C7E8C019PH0PR11MB4919namp_-- From nobody Mon Feb 28 07:19:40 2022 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E247C3A12A3; Mon, 28 Feb 2022 07:19:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <164606157388.22274.8070387410458395009@ietfa.amsl.com> Date: Mon, 28 Feb 2022 07:19:33 -0800 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-enrollment-priority-06.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, 28 Feb 2022 15:19:34 -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-06.txt Pages : 9 Date : 2022-02-28 Abstract: [RFC9032] defines a method by which a potential [RFC9031] 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-06.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-enrollment-priority-06 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Mon Feb 28 07:23:51 2022 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1BA3A12B9 for ; Mon, 28 Feb 2022 07:23:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 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, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qoDgRPVi0maX for ; Mon, 28 Feb 2022 07:23:45 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B4433A12B3 for ; Mon, 28 Feb 2022 07:23:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 3AB283899C for ; Mon, 28 Feb 2022 10:32:36 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MvO7JZ_y6YiV for ; Mon, 28 Feb 2022 10:32:34 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 5F02938997 for ; Mon, 28 Feb 2022 10:32:34 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1646062354; bh=T9Wji0giGGkpkfc92NvBDYCTBkGmbGlFJrUKLY/3Z2U=; h=From:To:Subject:In-Reply-To:References:Date:From; b=ake494Q5TYc+gQIByUi7r8jBMRwJ2y1YHqEMiixMwHvI6sF45ZWLgKdmsEHrDOEnf dKw5FBJrw1q2DQwyVgP5ia+WMwVR8nX2/kgwz+ffFqIaBTGUSFKupMTtJMqpMe9Uxm 4p0UogP/ZKWz0A2MblH5UD+N9/E/MzkW8n21rcFIoKNW5Z9rPM67TwH1O4cSs0UOQf v9ghQ+hXYoHR5KL9gw8aXoZLXkWzWstKGt4GyYknrcxjRkpCFJ8V/30E09Oq69/awN 6BEcBFPWi/FReveoXIIn3V3lWtYivf04+OMaEH8HAN9saRwAVYFiZMYLhlPnDZ7DPE v0jPAKd4fNsDQ== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 77F34CA for ; Mon, 28 Feb 2022 10:23:41 -0500 (EST) 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 Archived-At: Subject: [Roll] draft-ietf-roll-enrollment-priority (was Re: IETF 113 - Call for Presentations) 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, 28 Feb 2022 15:23:50 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ines Robles wrote: > Please let us know by 4th March if you desire to present a topic at t= he > IETF 113. We will have a one hour time-slot. Please indicate in your draft-ietf-roll-enrollment-priority It seems that we should revisit (again) the question about whether we want a rank-by-rank mutable congestion metric that can communicated to pledges and long-sleepy nodes that need to rejoin. I have posted -06, since it expired while we were discussing/arguing :-) This is just a snapshot of the state of editing, and does not represent a specific proposal about how we will deal with the question. That is: https://github.com/roll-wg/draft-ietf-roll-enrollment-priority/pull/14 is still open. I think we we still need a lollipop counter to be merged. I will work on things this week, as the draft cutoff is in one week. Perhaps Rahul advance the case for a mutable metric. I'm in favour of that, but I'm also a bit lost as to what is possible/effic= ient. =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----- iPMEAQEKAB0WIQSk7ZHEG9TCGBNASfm/sjw/rPYc8wUCYhzo/QAKCRC/sjw/rPYc 8xPlBf46NON0nCcDNuWOTuisKV9L2SJhB5h386nx6c4pvtU8tQTmOzezX7XnM70d tYT9u0HvG6hv801PHfkp+FrZqFKeZCr0cnex03FCAG4ZVZkCVSbPZNGRZCgMCdMr luzGl85ZgoaM2i2LNaAnwiU8KXzBsPP2+HRDdvdsJuvC1rENknIJ0QjUqiK3gMPd Urp9aLnWP4jmV26MaZeYrgaZAcdquuUK7E/H7W9+u55DXAodEwP8Qbx7Y8zHzU4B pVPdyaw= =pgrb -----END PGP SIGNATURE----- --=-=-=--