Re: [Roll] Rtgdir last call review of draft-ietf-roll-dao-projection-32

[Susan Hares <[e-mail]>]

Pascal:

Your text addresses most of my comments.  I’m simply going to indicate the comments that still have issues.

I do not think technical/editorial issues #2, #4, #5b, and #6-#10.  Please note I forgot to number some of the issues.   I do not think you addressed editorial issues.  (I probably would not have until I finished the technical issues).

I remain impressed with the work on roll.
Cheers, Sue


===========

Issues #2 and #4
Just a few questions – I see you made changes to table 6 and table 9

Table 9:

Header
IPv6 Source Addr.
IPv6 Dest. Addr.
TrackID in RPI
Outer
A
C until C then E
(A, 129)
Inner
X
either E if(X!=A), or F, or G
N/A
As an example, say that A has a packet for F. Using the RIB above:

But, it is not the changes I expected.   (I suggested E if (X !=A), F, or G I think you
mean E if (X != A or X !=F or X != G)

Therefore, I’m confused by the text surrounding table 6 and table 9.

Could you explain what you mean to say by the inner line in the chart?  I’m also willing to take this offline next week after I return from IETF.


Issue #5-b


On my comment: B) What is it preferred [so] that A encapsulations and decapsulates?

You provide a good explanation of why and what preferred are.  Will this preference be indicated by a configuration knob?  If so, it might be useful to indicate that fact.



Issue #6: section 3.5.2.2, Table 13, targets, entry for P-DAO 2

Why is the entry not “C, E” since your text states “P-DAO 2 signals A ==> B ==>C to C, E”?

I do not see how you have addressed this in the text.  Would you help me out if I have missed it.



Issue-7: section 3.5.2.3, Table 16, targets, P-DAO 1 to C Why is

the entry not “E” since your text states “P-DAO 1 signals c == > D == > E -to-E”.



I do not see how you have addressed to in the text.  Again, perhaps I missed it what you changed.



Issue 8: (I did not label this issues, but we’ll use Issue #8)



Section 4.1 extending RFC 6550<https://datatracker.ietf.org/doc/rfc6550/>, paragraph 3, sentence 3 “In the context of

this specification, the installed route appears as a more specific route to the

Track targets, and the Track Ingress forward packets toward the targets via the

Track using the longest match as normal.” Normal for IP? Normal for RPL IP?



Issue 9: (I did not label this issue in the original text, but we’ll use Issue #9)



Section 4.1.4 – How are loops prevented in the multicast DAO?  This is not

really clear her or in section 3. Sections 4-7 have error handling, but I am

concerned since I am not an expert in RPL error handling.  I strongly suggest

an independent person RPL experience review this text. I am concerned about

what happens when messages drop in the midst of a switch from one Track lane to

an other or from one segment to another.



Issue 10:



Section 5 – the concept of lifetime being “infinity” for 0xFF needs a clear description.  I believe you set to a

value (even 0xFF) and then count down.  If 0xFF is a special value, then it

needs to be specified. Section 6 – Configured values should be carefully

specified rather than stated “A reasonable time” see section 6.6.1 in paragraph

3.



Issue #11:  The changes to 6.7 seem to represent either a clarification or an amendment of protocol procedures.

Have you reviewed this with an other ROLL expert?



Editorial issues:



Did you choose to address these editorial issues?

If so, I will comment on the editorial issues in the diff you sent.

If not, you may choose to discuss with John Scudder whether he feels the editorial comments are valid.



Again, I am very impressed with effort and detail you have put into this specification.



As I mentioned in the roll meeting, I apologize for the delay in responding to your edits.  We have two ways to quicken the next review:



1)      Talk over the text via zoom call

2)      Try to target specific issues.



I suspect we will differ on the value of “running code” to find procedural bugs in additions.  However, I will do my best to spot errors in the procedures.



I remain worried I will miss some important point in my review. It would be good to have another expert who has written a roll implementation to review the procedures in the next revision.



Cheerily,  Sue



From: Pascal Thubert (pthubert) <[e-mail]>
Sent: Wednesday, September 27, 2023 10:42 AM
To: Susan Hares <[e-mail]>
Subject: RE: Rtgdir last call review of draft-ietf-roll-dao-projection-32

: ) Pascal  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌
External ([e-mail]<mailto:[e-mail]>)
  Report This Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tLzExMWNlODc0NWRmM2MwNWY3MWE1MTAzNmNkNjViNDk5LzE2OTU4MjU3MzYuNDI=#key=c990b57e43cd9d55346910530e4e284b>  FAQ<https://www.godaddy.com/help/report-email-with-advanced-email-security-40813>  GoDaddy Advanced Email Security, Powered by INKY<https://www.inky.com/protection-by-inky>

: )

Pascal
From: Susan Hares <[e-mail]>
Sent: Wednesday, September 27, 2023 2:54 AM
To: Pascal Thubert (pthubert) <[e-mail]>
Subject: RE: Rtgdir last call review of draft-ietf-roll-dao-projection-32

Pascal:

My apologies for the delay in responding to you.  I have been heads-down on some IDR WG chair work.

I’ll work on this on Wed 9/27. d

Sue

From: Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, September 13, 2023 5:55 AM
To: Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>; Susan Hares <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Thubert Pascal <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: Rtgdir last call review of draft-ietf-roll-dao-projection-32



Hello again Sue



This took time, I'm sorry. There as quite a lot to do for to try to address your comments rights.

I published result of the first pass:



URL:      https://www.ietf.org/archive/id/draft-ietf-roll-dao-projection-33.txt<https://shared.outlook.inky.com/link?domain=www.ietf.org&t=h.eJxFzM0SgiAYheFbaVgHiAiKK28F-QnKxIHPbGq692LV9rxznjfa84LGEwoAWxkpPY6DRAeepHyhOpsQH45GS23WHnAtOKdlwVYnvOV0dQZiWjHnBJ6Azid0q9rq4PdnjRikYi0tQWdXptW-AjHpThljxg19J6znphG-Z1qwhktjpZg7pSiTSgyt6LkkXVtVV9UNwj67DJOJxaQq1WRr-i-fL3rCQbE.MEQCIFJ-ovauG3MfRz0CfmLnBIZdwFdKjGY5UyNzOWu2zMulAiAYi9T-mi5S_sI4atTbas7PbwjEJvDShx7IfdcKmRjSSw>

Status:   https://datatracker.ietf.org/doc/draft-ietf-roll-dao-projection/<https://shared.outlook.inky.com/link?domain=datatracker.ietf.org&t=h.eJxFzDESgyAQheGrONQBRAXFyqvgAtFoxFnWJpncPaFK-_5535tduLOxYgvRmUcpvSNH6GALKNZAUSS8S59AenSReJk4pn3n3iV-YnoEoDUdkt0qthXoCPS7qFoPxqpG5sVhyNPhX4uA9JRKKQhD32kfW6h17JXTqm4NeKPnzlqpjNVDo_vWiK4paijqScs1B6QJ1gypSCX5kv7L5ws0uEA4.MEUCIQD8fkkGbvLnrZhqzUPzd_6uFyOjnmeeh0MKEJNATnSxWwIgWgUyRLCi4lcUtSegadEkVK8euc7iZ-hf2WyVgzhti9c>

HTML:     https://www.ietf.org/archive/id/draft-ietf-roll-dao-projection-33.html<https://shared.outlook.inky.com/link?domain=www.ietf.org&t=h.eJxFzEsOgyAUQNGtGMYFRATFkVtBPoXWioFnTdp07y2jTu9NzhsdeUVTgwLAXiZKz_Mk0YEnKV-pzibEp6PRUpu1B1wPzmldsdUJ7zndnIGYNsw5CfBY0aVB98ptDn4Aa8UoFetoCTq7Mm_2FYhJD8oYM24cemE9N63wA9OCtVwaK8XSK0WZVGLsxMAl6buquqruEI7FZZhNLCZVqS5b1798vsMMQgY.MEYCIQC-gPw_ck8hqv0m9ASOgsmH6BvW9lFC1jSHw1dLczLPswIhAIdVTmyjfCveJxIN2OcZoE-0KqJp92gxhLs23ygooH30>

HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-roll-dao-projection<https://shared.outlook.inky.com/link?domain=datatracker.ietf.org&t=h.eJxFzEsSgyAQRdGtpBgHEBX8jNwKNhCMKFbbTpLK3hNGmb5b77zZhYmNNxaJjnOU0lmyhBZWj2LxFETGh3QZZKQtSYc2EC87x5wSdzbzA_PTAy15Z_cbWwu2e_rdVKV7M6hantGiP6fdvaKAvEmlFPi-a7ULDVQ6dMpqVTUGnNFzOwxSmUH3te4aI9q6qL6oB8Vr9kgTLCfkIpXkSvovny-F6EHt.MEQCIG42btv1JRC6N12uFhSrKNYNWqz--iAd9rJkinJElZt_AiBw-FZaTlcdF3a8evVJQDxDObtskXtw6MEkqdFgoWKasg>

Diff:     https://author-tools.ietf.org/iddiff?url2=draft-ietf-roll-dao-projection-33<https://shared.outlook.inky.com/link?domain=author-tools.ietf.org&t=h.eJxFzMsOgyAQheFXMayLiAhekqa-CnIptNYxMG7a9N0rq27nn_N9yJFWMlUkIO55YkwfGCBRBFhzHR36GtKdRWuj97fzt73apD3SkmiCdaVWA90TPJzBCBsVglwq8izm5vAc80YOauQty0Enl-fNvkNt4MU458YNfSetF6aRvuda8kYoY5VcunFkXI1yaGUvVN21RXVF3TEci0s4m5gNFKkkW9L_8v0Bb_pECQ.MEUCIQDM4n7CoH5BmpJo35TphyqyOc13aqDQNX4K5Es7UKjMPAIgS2AbNplr0wih4EuH6CzTPmyHp758s089JGGQ0h31NKM>



Note that your contribution will be acknowledged in the next push, sorry I failed to do it here.

Please see below:





> Reasons Not ready:



> 1) Text in

> sections 3.4 and 3.5 have logic gaps that make it difficult to

> determine if this general discussion is being implemented in section 7

> (using sections 4 and 6)





> 2) This document significantly modifies a major specification (RPL) without a prototype

> implementation that interoperates with RPL basic.   One example of how this

> impacts this document is the profile section.  The profile text has

> editorial issues that make it unclear to a reader not involved in

> writing the text.



> 3) Operational details on the two strict rules that

> prevent looping are unclear in the text.  One example is the

> “administrator defining the ordering of the RPL domain” in section

> 3.2. The text hints at what the answer might be, but it seems there are policies.

>

> Proposed resolution of comments:  Place this specification as

> experimental or await an implementation.

>



We need to open a group wide discussion on this. RPL itself shipped without experimental status and it's still there. My personal belief is we need to improve the text but could live a long time with std track. At worse will do a v2. Our experience at ROLL is that Experimental tends to do the opposite of the hoped effect and deter implementers.



In terms of impacts with RPL: The intersection is at the time of encaps and decaps to avoid loops. The rest of the time, the instances live as ships in the night to the interaction is limited.



Since we are defining underlay wormholes, all the traffic that does not match the wormhole entry criteria is not impacted.



Now, I agree that 3.4.2 was confusing and needed rework. Sorry for your pain. Let's see.



> Text in section 3.4 – Technical and/or editorial Paragraph 2 starting

> with “A track” has a “;” that confuses the text.  It is a critical

> part of the description of how the encapsulating Source IP address and

> RPI instance are set.



Suggestion:



"

   A Track typically forms an underlay to the main Instance, and is

   associated with a Local RPL Instance from which the RPLInstanceID is

   used as the TrackID.  When a packet is placed on a Track, it is

   encapsulated IP-in-IP with a RPL Option containing a RPI which

   signals the RPLInstanceID.  The encapsulating source IP address and

   RPI Instance are set to the Track Ingress IP address and local

   RPLInstanceID, respectively, more in Section 6.3.

"



> The next paragraph jumps into the Track Lane as

> an alternative to the segment in the main DODAG. It is important to

> know if the longest-best match is being per RPL instance or across all

> instances to link the packet to an ingress of a Track Lane or a

> segment.





Suggestion:



"

   A Track typically offers service protection across several lanes.  As

   a degraded form of a Track, a path made of a single lane (i.e.,

   offering no protection) can be used as an alternative to a Segment

   for forwarding along a RPL Instance.  In that case, instead of

   following native routes along the instance, the packets are

   encapsulated to signal a more specific source-routed path between the

   loose hops in the encapsulated source routing header.

"



> The last sentence in the paragraph that starts with “A track

> lane” is very confusing.  Perhaps the text makes sense to someone

> deeply embedded in the RPL community, but it is unclear from the

> knowledgeable but unfamiliar reader.





Suggestion:



"

   If the encapsulated packet follows a global instance, then the lane

   may be part that global instance as well, for instance the global

   instance of the main DODAG.  This can only be done for global

   instances because the Ingress node that encapsulates the packets over

   the lane is not the Root of the instance, so the source address of

   the encapsulated packet cannot be used to determine the Track along

   the way.

"







> Text in section 3.5 – Technical

> and/or editorial Editorial: Please place at top of the example which

> figure you are using. I assumed figure 6.  Please also indicate that “

> in a table indicates the same value.



done





> Issue-1: Section 3.5, paragraph

> 8, starting with “Loose sequences of hops” – technical/editorial

> issue. I cannot find a clear logic step due to the use of commas.  The

> problem is I need this logic to walk through the rest of the text.

> Perhaps the authors could provide a bullet point of what they are

> trying to say.





Proposed rewording:



"



   Loose sequences of hops are expressed in Non-Storing Mode; this is

   why P-DAO 3 contains a NSM-VIO.  With this specification:



   *  the DODAGID to be used by the Ingress as source address is

      signaled in the DAO base object (see Figure 8) .



   *  the via list in the VIO is encoded as an SRH-6LoRH (see

      Figure 16), and it starts with the address of the first hop node

      after the Ingress node in the loose hop sequence.



   *  the via list ends with the address of the Egress node.



   Note well:



   |  The Egress of a Non-Storing Mode P-Route is always implicitly a

   |  target; it is not listed in the RPL Target Options but still

   |  accounted for as if it was.



   Also:



   |  By design, the list of nodes in a VIO in Non-Storing Mode is

   |  exactly the list that shows in the encapsulation SRH.  So in the

   |  cases detailed below, if the Mode of the P-DAO is Non-Storing,

   |  then the VIO row can be read as indicating the SRH as well.



"



> Issue-2.  Section 3.5.1.2 Format on inner form in Table

> 6 in “E if (X !=A), F, or G I think you mean E if (X != A or X !=F or X != G). If so, please modify.  If not, please change text. This issue repeats.

>



The intention is to say that the destination address can be either

E but that happens only if X is not A, or F unconditionally, or G unconditionally.

This is because as said above, " Packets from A to E do not require an encapsulation. "



Changed to " either E if(X != A), or F, or G "



Address text above as:

"

   Packets from A to E do not require an encapsulation.  This is why in

   the tables below, E may show as IPv6 Destination Address only if the

   IPv6 Source Address X is different from A.  Conversely, the

   encapsulation is always done when the IPv6 Destination Address is F

   or G.  Other destination addresses do not match this P-Route and are

   not subject to encapsulation.

"



> Issue-3: Section 5.1.3, Table 7 Target entry for P-DAO 2 to B Why is

> the entry not “B,C” per your earlier text of  “P-DAO 2 signals A ==> B to B, C”



Good catch. It was commented out in the source, maybe a confusion between storing and non-storing mode.

Maybe we should always make the egress a target for simplicity?





> Issue-4: Section 3.5.1.3, table 9 - E if (X !=A), F, or G I think you

> mean E if (X != A or X !=F or X != G). If so, please modify the

> tabl3e.  If not, please change section.



Changed to " either E if(X != A), or F, or G "





> Issue-5: section 3.5.2.1

> Editorial/Technical: a) What does ND mean? B) What is it preferred

> that A encapsulations and C decapsulates?



A) Added

"

   As a result the RIBs are set as follows (using ND to indicate that

   the address is discovered by IPv6 Neighbor Discovery

   [RFC4861][RFC8505] or an equivalent method:

"



B) I cannot parse the question. Do you mean: Why is it ... ?

If so, the argument is the same as in RFC 9008, the egress can remove the RPI/SRH with the encaps for delivery and the RUL gets a clean packet with no RPL artifact. Now there is a typo and that's really E doing it. If that's your point, great catch.



Updated the text to



"

   Packets originated at A to E, F and G could be generated with the RPI

   and the SRH, and no encapsulation.  Alternatively, A may generate a

   native packet to the target, and then encapsulate it with an RPI and

   an SRH indicating the source-routed path leading to E, as it would

   for a packet that it routes coming from another node.  This is

   effectively the same case as for packets generated by the root in a

   RPL network in Non-Storing mode, see section 8.1.3 of [RFC9008].  The

   latter is often is preferred since it leads to a single code path,

   and the destination when it is F or G, does no understand and process

   the RPI or the SRH.



"



> Issue-6: section 3.5.2.2,

> Table 13, targets, entry for P-DAO 2 Why is the entry not “C, E” since

> your text states “P-DAO 2 signals A ==> B ==> C to C, E”?





In this case it is effectively non-storing so the egress is an implicit target.

As said above, we might consider if it would be best to always consider the egress as a target (even in storing mode) which means more rib entries vs. a smaller message and simpler spec.





> Issue-7:

> section 3.5.2.3, Table 16, targets, P-DAO 1 to C Why is the entry not

> “E” since your text states “P-DAO 1 signals c == > D == > E

> -to- E”.



Same as above; E is an implicit target since it is egress of a non-storing P-route



> Section 4.1 extending RFC 6550, paragraph 3, sentence 3 “In

> the context of this specification, the installed route appears as a

> more specific route to the Track targets, and the Track Ingress

> forward packets toward the targets via the Track using the longest match as normal.” Normal for IP?

> Normal for RPL IP?



Well for both. The FIB takes the longest match in the RIBs.





> Section 4.1.4 – How are loops prevented in the multicast DAO?  This is

> not really clear her or in section 3.



The origin of the mcast DAO provides the list of all its neighbors so it can serve as a relay between neighbors that are too far apart from one another. You'll find that concept already in MANET with NHDP, RFC 6130.



So there's no routing involved, and as long as the sender of the mcast DAO has the destination as neighbor as advertised, there can be no loop. Keep in mind that direct neighbor has precedence over indirect, which has precedence over routing.



Now if the sender loses the destination as neighbor; loops may occur. If we want to handle that case we could do a number of things, e.g: poison back to the previous hop using the RPI as we do in RPL, decrement the TTL to 2 when sending to an indirect neighbor, keep a state about the neighbor gone and drop packets till more mcast DAOs have cleaned the situation up. What do you think?



Finally: for  completeness I reread the text on loop avoidance in 6.6.2. and reworded to clarify as follows:

"

   It is known that a packet is forwarded along a Track by the source

   address and the RPI in the encapsulation.  The Track ID is used to

   identify the RIB entries associated to that Track, which, in

   intermediate nodes, correspond to the P-routes for the segments of

   the Track that the forwarding router is aware of.  The packet

   processing uses a precedence that favors self delivery or routing

   header handling when one is present, then delivery to direct

   neighbors, then to indirect neighbors, then routing along a segment

   along the Track, and finally as a last resort injecting the packet in

   another Track.



   To achieve this, the packet handling logic MUST happen in the

   following order:









Thubert, et al.           Expires 15 March 2024                [Page 66]





Internet-Draft               DAO Projection               September 2023





   *  If the destination of the packet is self:



      1.  if the header chain contains a RPL Source Route Header that is

          not fully consumed, then the packet is forwarded along the

          Track as prescribed by [RFC6554], meaning that the next entry

          in the routing header becomes the destination;



      2.  otherwise: if the packet was encapsulated, then the packet is

          decapsulated and the forwarding process recurses; else the

          packet is delivered to the stack.



   *  Otherwise, the packet is forwarded as follows:



      1.  If the destination of the packet is a direct neighbor, e.g.,

          installed by IPv6 Neighbor Discovery, then the packet the

          packet MUST be forwarded to that neighbor;



      2.  Else If the destination of the packet is an indirect neighbor,

          e.g., installed by a multicast DAO message from a common

          neighbor, see Section 4.1.4, then the packet MUST be forwarded

          to the common neighbor;



      3.  Else, if there is a RIB entry for the same Track (e.g.,

          installed by an SM-VIO in a DAO message with the destination

          as target), and the next hop in the RIB entry is a direct

          neighbor, then the packet is passed to that neighbor;



      4.  Else, if there is a RIB entry for the different Track (e.g.,

          installed by an NSM-VIO in a DAO message with the destination

          as target), then the packet is encapsulated to be forwarded

          along that Track and the forwarding process recurses;

          otherwise the packet is dropped.



      5.  To avoid loops, and as opposed to packets that were not

          encapsulated, a packet that was decapsulated from a Track MUST

          NOT be routed along the default route of the main DODAG; this

          would mean that the end-to-end path is uncontrolled.  The node

          that discovers the fault MUST discard the packet.



   The node that drops a packet for either of the reasons above MUST

   send an ICMPv6 Error message [RFC4443] to the Root, with a new Code

   "Error in P-Route" (See Section 11.15).  The Root can then repair by

   updating the broken Segment and/or Tracks, and in the case of a

   broken Segment, remove the leftover sections of the Segment using SM-

   VIOs with a lifetime of 0 indicating the section to one or more nodes

   being removed (See Section 6.6).



"



Note that there can still be a loop of Tracks, but then that's a bug in the controller.

We could have ordered the tracks to avoid that, but that would be added complexity.



> Sections 4-7 have error

> handling, but I am concerned since I am not an expert in RPL error

> handling.  I strongly suggest an independent person RPL experience

> review this text. I am concerned about what happens when messages drop

> in the midst of a switch from one Track lane to an other or from one

> segment to another.



I'll trust my co authors on that. They are some of the most knowledgeable RPL people, bot with implementation experience. Maybe we can also ask Dominique (co-chair) who also has that experience.



> Section 5 – the concept of lifetime being

> “infinity” for 0xFF needs a clear description.  I believe you set to a

> value (even 0xFF) and then count down.  If 0xFF is a special value,

> then it needs to be specified.



Added " (never time out)"



> Section 6 – Configured values should be

> carefully specified rather than stated “A reasonable time” see section 6.6.1 in paragraph 3.



That was always problematic with RPL, which deals with a large variety of environments, some with high latency. As the text says, that's what the particular network needs to drain its queues.





> =============

> Strictly Editorial issues:

> #1 Section 2.3 – missing at least PSE and ARQ.  Please do a search to

> make sure you have all the abbreviations.  I ran out of time to do that search.





done



>  Was there a reason you did not provide the original place these terms

> were defined?  Are you assuming that section 1 allows you to skip this step?



Most terms are very familiar in the RPL and radio spaces. I do not even have a clue who defined ARQ or where. For things less common to RPL people like Point of Local Repair (PSE was renamed at RAW) there's text in the first use that provides a reference.





> #2 Section 2.3.5.5:

> This section contains a single run-on sentence with unclear language.   If

> you

> mean that all Serial tracks are created from segments, you could

> include this in your definition in 2.4.5.3.  If not, please modify

> both to indicate what you mean. New:/Refers to a Segment or a lane

> that is installed with a single P-DAO and fully defines a serial Track

> installed from single Storing Mode Via Information option (SM-VIO). /



We're talking about section 3.4.5.5. The answer is the "if not". A serial track could also be a lane expressed as a strict source routed path, in which case there's no segment. Following RAW, we are removing that "serial track", just using "path". Proposed slight rewording:

"

    Refers to a Segment or a Lane that is installed with a single P-DAO that

    fully defines the path, e.g., a stand-alone segment is installed

    with a single Storing Mode Via Information option (SM-VIO) all the way

    between Ingress and Egress.

"







> #3: Section 3.2, paragraph 8 The two strict ordering rules would

> benefit from a numerical list in the order.  Here are possible text

> changes for this paragraph: New-1/ The possible forwarding methods are

> the following: 1)  to a direct next hop,  2) to an indirect neighbor

> via a common neighbor, 3) along a segment, and 4) along a track./



Done. Also indicated a reference to section 6.7.  Encapsulating and Forwarding Along a Track







> New-2/ A RPL Instance may leverage another instance if and if only if

> that other Instance is higher in the order defined by the operator.

> Higher instances [should/must?] be defined as higher if they are

> farther away from the main instance. / The text is unclear how the

> operator will know what the ordering should be.





Makes sense. I also split the 7th paragraph for more clarity.



"

Routing in a multi-topology domain may cause loops unless strict

   rules are applied.  This specification defines two strict orders to

   ensure loop avoidance when projected routes are used in a RPL domain,

   one between forwarding methods and one between RPL Instances, seen as

   routing topologies.



   The first and strict order relates to the forwarding method and the

   more specifically the origin of the information used in the next-hop

   computation.  The possible forwarding methods are: 1) to a direct

   next hop, 2) to an indirect neighbor via a common neighbor, 3) along

   a Segment, and 4) along a nested Track.  The methods are strictly

   ordered as listed above, more in Section 6.7.  A forwarding method

   may leverage any of the lower order ones, but never one with a higher

   order; for instance, when forwarding a packet along a Segment, the

   router may use direct or indirect neighbors but cannot use a Track.

   The lower order methods have a strict precedence, so the router will

   always prefer a direct neighbor over an indirect one, or a Segment

   within the current RPL Instance vs. another Track.



   The second strict and partial order is between RPL Instances.  It

   allows the RPL node to detect an error in the state installed by the

   PCE, e.g., after a desynchronization.  That order must be defined by

   the administrator for his RPL domain and defines a DODAG of underlays

   with the main Instance as Root.  The relation of RPL instances may be

   represented as a DODAG of instances where the main instance is Root.

   The rule is that a RPL Instance may leverage another RPL instance as

   underlay if and only if that other Instance is one of its descendants

   in the graph.  Supporting this method is OPTIONAL for nested Tracks

   and REQUIRED between a Track instance and the main instance.  It may

   be done using network management, or future extensions to this

   specifications.  When it is not communicated, then the RPL nodes

   consider by default that all Track instances are children of the main

   instance, and do not attempt to validate the order for nested Tracks,

   trusting the PCE implicitly.  As a result, a packet that is being

   forwarded along the main Instance may be encapsulated in any Track,

   but a packet that was forwarded along a Track MUST NOT be forwarded

   along the default route of main Instance. "





> #3 section 3.3,

> paragraph 3. Old: /Limiting the packet size is directly beneficial to

> the energy budget, but mostly, it reduces the changes of frame loss

> and packet fragmentation, which are high detrimental to the LLN

> operational.] The sentences should be rewritten as two sentences.  I

> believe you are saying: 1) reduces packet size cuts transmission time

> + reduces frame loss + packet fragmentation. You are indicating that

> reasons #2 and #3 are more important than #1.  Please just state that.



Proposed:



"

   Limiting the packet size is beneficial to the energy

   budget, directly for the current transmission, but also indirectly

   since it reduces the chances of frame loss and energy spent in

   retries, e.g., by ARQ over one hop at Layer-2, or end-to-end at upper

   layers.  Using smaller packets also reduces the chances of packet

   fragmentation, which is highly detrimental to the LLN operation, in

   particular when fragments are forwarded but not recovered, see

   [RFC8930] vs. [RFC8931] for more.

"



> Note – after section 4, my editorial review was brief so I may have

> missed some of the sentence which use the “;” in an improper way.









#4

> section 4.1.1, paragraph 3 starting “This document Amends” Unless it is clearly specified in standards, then “AMENDS” or whatever is used. #5  section 4.1.4 to end RAN is an abbreviation that is widely used.  I suggest you pick another abbreviation:

> RPLAN



RAN is a RPL term defined in rfc9008 ; I added that reference in the Terminology section.





I used 2 commits to get through this pass:

- https://github.com/roll-wg/dao-projection/commit/e1e583e25f4d400653e92d41b4961f3cd428f08c<https://shared.outlook.inky.com/link?domain=github.com&t=h.eJxFjssOwiAURH_FsNbCBS6FrvorLdw-tJaGYkw0_rvFjds5mTPzZo-0sObEppy3veF8nPP06Csf7zzFZbk8Rx66eNlSvJLPc1z5ge5z5gSEVpHEQQcthEFFTgYNvXYGBuWDlnYQ1rPzid3Kwko5phEEWuNA8n3qEu3tGl7Tbw0APNlaYzjKAocaOgShjA8GD6fjYBxaibUylZbFSsW6lbuUcuvn3cdiKigU9E8-X4QpRTg.MEQCICdh1LSbYMYPb0V1twRq_T0s5LHO7KoD7mnu-j5gc_yVAiA2bwnm3vSCFmY7OA9LObw6iJlMxrdXIDVeO709Rt8Png>

- https://github.com/roll-wg/dao-projection/commit/b4a5ad8237fb21642147e933ac766344329259a4<https://shared.outlook.inky.com/link?domain=github.com&t=h.eJxFjssOwiAQRX_FsLbSgRkoXfVXKNCH1tJQGhON_664cXtPcs59sSMtrD2xKedtbzkf5zwd_cXFO09xWarHyL2N1ZbiNbg8x5V_0X3OvEdL1jdC6qEXoFAA6mCktE4rJRGlMIKMRXY-sVsprCHHNEJNjTIg-D7ZFPZu9c_pVwMAFxqN5Afpaho0WIJaKucV9WgMB2WoEaSluqAo1lCsW7kbUu7cvLtYTAX5gv7L-wM2HUSk.MEUCIQCg6AAeNj8V-_sqFYjBvqLQPNH_Ki_72CLoxYZT5Gsj_QIgLvNn03P90VsM3jpPQ67Hp2xaUoPiahnY4Q3NlJowlGY> for the largest





Pascal

>

> > -----Original Message-----

> > From: Susan Hares via Datatracker <[e-mail]<mailto:[e-mail]>>

> > Sent: Wednesday, August 23, 2023 11:56 PM

> > To: [e-mail]<mailto:[e-mail]>

> > Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;

> > [e-mail]<mailto:[e-mail]>

> > Subject: Rtgdir last call review of draft-ietf-roll-dao-projection-32

> >

> > Reviewer: Susan Hares

> > Review result: Has Issues

> >

> > Status: Has Issues

> > Summary:

> > This specification demonstrates an amazing amount of work.  I commend

> > the authors for their creativity and their diligence in forging

> > forward on new concepts in routing. Reasons Not ready: 1) Text in

> > sections 3.4 and 3.5 have logic gaps that make it difficult to

> > determine if this general discussion is being implemented in section 7

> > (using sections 4 and 6) 2) This document significantly modifies a major

> specification (RPL) without a prototype

> > implementation that interoperates with RPL basic.   One example of how

> this

> > impacts this document is the profile section.  The profile text has

> > editorial issues that make it unclear to a reader not involved in

> > writing the text. 3) Operational details on the two strict rules that

> > prevent looping are unclear in the text.  One example is the

> > “administrator defining the ordering of the RPL domain” in section

> > 3.2. The text hints at what the answer might be, but it seems there are

> policies.

> >

> > Proposed resolution of comments:  Place this specification as

> > experimental or await an implementation.

> >

> > Text in section 3.4 – Technical and/or editorial Paragraph 2 starting

> > with “A track” has a “;” that confuses the text.  It is a critical

> > part of the description of how the encapsulating Source IP address and

> > RPI instance are set.  The next paragraph jumps into the Track Lane as

> > an alternative to the segment in the main DODAG. It is important to

> > know if the longest-best match is being per RPL instance or across all

> > instances to link the packet to an ingress of a Track Lane or a

> > segment. The last sentence in the paragraph that starts with “A track

> > lane” is very confusing.  Perhaps the text makes sense to someone

> > deeply embedded in the RPL community, but it is unclear from the

> > knowledgeable but unfamiliar reader. Text in section 3.5 – Technical

> > and/or editorial Editorial: Please place at top of the example which

> > figure you are using. I assumed figure 6.  Please also indicate that “

> > in a table indicates the same value. Issue-1: Section 3.5, paragraph

> > 8, starting with “Loose sequences of hops” – technical/editorial

> > issue. I cannot find a clear logic step due to the use of commas.  The

> > problem is I need this logic to walk through the rest of the text.

> > Perhaps the authors could provide a bullet point of what they are

> > trying to say. Issue-2.  Section 3.5.1.2 Format on inner form in Table

> > 6 in “E if (X !=A), F, or G I think you mean E if (X != A or X !=F or X

> != G). If so, please modify.  If not, please change text. This issue

> repeats.

> >

> > Issue-3: Section 5.1.3, Table 7 Target entry for P-DAO 2 to B Why is

> > the entry not “B,C” per your earlier text of  “P-DAO 2 signals A ==> B

> to B, C”

> > Issue-4: Section 3.5.1.3, table 9 - E if (X !=A), F, or G I think you

> > mean E if (X != A or X !=F or X != G). If so, please modify the

> > tabl3e.  If not, please change section. Issue-5: section 3.5.2.1

> > Editorial/Technical: a) What does ND mean? B) What is it preferred

> > that A encapsulations and C decapsulates? Issue-6: section 3.5.2.2,

> > Table 13, targets, entry for P-DAO 2 Why is the entry not “C, E” since

> > your text states “P-DAO 2 signals A ==> B ==> C to C, E”? Issue-7:

> > section 3.5.2.3, Table 16, targets, P-DAO 1 to C Why is the entry not

> > “E” since your text states “P-DAO 1 signals c == > D == > E

> > -to- E”. Section 4.1 extending RFC 6550, paragraph 3, sentence 3 “In

> > the context of this specification, the installed route appears as a

> > more specific route to the Track targets, and the Track Ingress

> > forward packets toward the targets via the Track using the longest match

> as normal.” Normal for IP?

> > Normal for RPL IP?

> > Section 4.1.4 – How are loops prevented in the multicast DAO?  This is

> > not really clear her or in section 3. Sections 4-7 have error

> > handling, but I am concerned since I am not an expert in RPL error

> > handling.  I strongly suggest an independent person RPL experience

> > review this text. I am concerned about what happens when messages drop

> > in the midst of a switch from one Track lane to an other or from one

> > segment to another. Section 5 – the concept of lifetime being

> > “infinity” for 0xFF needs a clear description.  I believe you set to a

> > value (even 0xFF) and then count down.  If 0xFF is a special value,

> > then it needs to be specified. Section 6 – Configured values should be

> > carefully specified rather than stated “A reasonable time” see section

> 6.6.1 in paragraph 3.

> > =============

> > Strictly Editorial issues:

> > #1 Section 2.3 – missing at least PSE and ARQ.  Please do a search to

> > make sure you have all the abbreviations.  I ran out of time to do that

> search.

> >  Was there a reason you did not provide the original place these terms

> > were defined?  Are you assuming that section 1 allows you to skip this

> step?

> > #2 Section 2.3.5.5:

> > This section contains a single run-on sentence with unclear language.

> If

> > you

> > mean that all Serial tracks are created from segments, you could

> > include this in your definition in 2.4.5.3.  If not, please modify

> > both to indicate what you mean. New:/Refers to a Segment or a lane

> > that is installed with a single P-DAO and fully defines a serial Track

> > installed from single Storing Mode Via Information option (SM-VIO). /

> > #3: Section 3.2, paragraph 8 The two strict ordering rules would

> > benefit from a numerical list in the order.  Here are possible text

> > changes for this paragraph: New-1/ The possible forwarding methods are

> > the following: 1)  to a direct next hop,  2) to an indirect neighbor

> > via a common neighbor, 3) along a segment, and 4) along a track./

> > New-2/ A RPL Instance may leverage another instance if and if only if

> > that other Instance is higher in the order defined by the operator.

> > Higher instances [should/must?] be defined as higher if they are

> > farther away from the main instance. / The text is unclear how the

> > operator will know what the ordering should be. #3 section 3.3,

> > paragraph 3. Old: /Limiting the packet size is directly beneficial to

> > the energy budget, but mostly, it reduces the changes of frame loss

> > and packet fragmentation, which are high detrimental to the LLN

> > operational.] The sentences should be rewritten as two sentences.  I

> > believe you are saying: 1) reduces packet size cuts transmission time

> > + reduces frame loss + packet fragmentation. You are indicating that

> > reasons #2 and #3 are more important than #1.  Please just state that.

> > Note – after section 4, my editorial review was brief so I may have

> > missed some of the sentence which use the “;” in an improper way. #4

> > section 4.1.1, paragraph 3 starting “This document Amends” Unless it is

> clearly specified in standards, then “AMENDS” or whatever is used. #5

> section 4.1.4 to end RAN is an abbreviation that is widely used.  I

> suggest you pick another abbreviation:

> > RPLAN

> >

> >