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

[Pascal Thubert <[e-mail]>]

Hello again Sue

CCing Michael for your his view on your comments in particular Issue 11


Please see in line

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)
>

Actually I means that it can be E only if X is not A. When X is A, then 
it can only be F or G.

See my response in the earlier mail:

''

> 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.
"


''




> 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.

This has been possible since RPL inception. We leave it to 
implementation. I guess the knob discussion could have happened in RFC 
9008 or even RFC 6550. We're probably not at the right place here since 
this is really external to this spec.


> 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.
>
The Targets row indicates in entry in the Target record of the message.

C is implicit since it it is the last entry in the VIO so it does not 
need to be listed as a target in the target list (that would be 
repeating it and we are constrained in space). The trade off is that the 
node creates a RIB entry for the last address in the SRH even when that 
route is not needed, vs doubling the entry in the message, once in the 
VIO and once in the target list. Similarly E is implicit in PDAO 1, and 
should not be listed in row 'Targets' in Table 13. Fixing that and 
adding text:

"

Note in the above that E is an implicit Target in P-DAO 1 and so is C in 
P-DAO 2.
As Non-Storing Mode Egress nodes addresses, they not listed in the 
respective RTOs

"

Also using ( ) to indicate the implicit targets in the formulation 
description

In table 13, the mistake was E being listed as Target though it is the 
egress so implicit.  Fixed.


> 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.

I should have listed the implicit targets as well in the formulation for 
homogeneity. Done.

Also  I realize I typo'ed, having B, C in the Next Hop(s) of table 17 
instead of the Destination column. Fixed.


> 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?


Then maybe I can say " using normal longest match IP forwarding " ? RPL 
is no different, it installs routes that are used classically by forwarding.


> 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.


The idea is that the Root should compute routes without loops, and that 
loops only occur when the network is out of sync with the root.

When there's a problem forwarding, there's ICMP signaling to the Root 
that can clean up and re install.

And then there's the precedence of route types.

Happy to have this external review.


> 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.
I added (never time out)
> 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?


Hereby asking the co-authors to reread 6.7 .  If you consider that the 
Track is a RPL DODAG and the Ingress is Root, that is not really new but 
the classical RPL operation by a Root, see RFC 9008.


> Editorial issues:
> Did you choose to address these editorial issues?


I did not intend to omit anything.

PSE is not PLR, and both ARQ and PLR are in the glossary. See all the 
other points in my discussion repeated below.

"

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

 > 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.




"




> 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


Would be neat. When would you be available?


> 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.

I guess the best I Michael Richardson who is co author, and then there's 
Dominique who is chair.

Please let me know if you find I indeed missed some comments.


all the best;


Pascal

> 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