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

[Pascal Thubert <[e-mail]>]

Dear Sue and all:

Based on this mail I made a second pass, see 
https://author-tools.ietf.org/iddiff?url1=draft-ietf-roll-dao-projection-32&url2=draft-ietf-roll-dao-projection-34 
to get it all since the beginning of Sue's review.

author-tools.ietf.org

Diff: draft-ietf-roll-dao-projection-32.txt - 
draft-ietf-roll-dao-projection-34.txt <#>

🔗 
https://author-tools.ietf.org/iddiff?url1=draft-ietf-roll-dao-projection-32&url2=draft-ietf-roll-dao-projection-34 
<https://author-tools.ietf.org/iddiff?url1=draft-ietf-roll-dao-projection-32&url2=draft-ietf-roll-dao-projection-34> 


  Again, many thanks for the in-depth review, and happy to have that 
online what when you are available

all the best

Pascal

Le 08/11/2023 à 16:05, Susan Hares a écrit :
>
> 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
>
> *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]>
> *Sent:* Wednesday, September 13, 2023 5:55 AM
> *To:* Pascal Thubert (pthubert) <[e-mail]>; Susan Hares 
> <[e-mail]>; [e-mail]; Thubert Pascal 
> <[e-mail]>
> *Cc:* [e-mail]; [e-mail]; 
> [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
>
> Status: https://datatracker.ietf.org/doc/draft-ietf-roll-dao-projection/
>
> HTML: 
> https://www.ietf.org/archive/id/draft-ietf-roll-dao-projection-33.html
>
> HTMLized: 
> https://datatracker.ietf.org/doc/html/draft-ietf-roll-dao-projection
>
> Diff: 
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-roll-dao-projection-33
>
> 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://github.com/roll-wg/dao-projection/commit/b4a5ad8237fb21642147e933ac766344329259a4 
> for the largest
>
> Pascal
>
> >
>
> > > -----Original Message-----
>
> > > From: Susan Hares via Datatracker <[e-mail]>
>
> > > Sent: Wednesday, August 23, 2023 11:56 PM
>
> > > To: [e-mail]
>
> > > Cc: [e-mail]; [e-mail];
>
> > > [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
>
> > >
>
> > >
>
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll