Subject: [Iot-directorate] IOTdir Review of draft-ietf-roll-dao-projection-19

From: Toerless Eckert <[email-masked]>
Date: Mon, 30 Aug 2021 00:26:20 +0200

draft: draft-ietf-roll-dao-projection-19
Review-source: IOTdir
Reviewer: Toerless Eckert
Review result: Technology ready, Text has various issues, mostly difficult to understand.

Dear Authors

Thanks a lot for this work.  This is cool technology, it has the 
ability to provide very flexible and wide range of path steering
and header optimizations for RPL networks. 

Overview:

I am not sure i understand all finer details due likely
to some impedance mismatch between the expected RPL expertise of the text
and mine, but i think that the proposed technology is sound
and has on the technoloy (not text) side only few details that may
 need to be added (missing guidance or references on timers,
maybe MTU handling if that is not supposed to be well-known, etc.).

If there is any technological gap, then it is me hoping that this
could be a solution for the RFC8994 A.9.4 problem, but alas this
solution does not support establishment of additional routes for
storage mode DODAGs. Too bad. Especially because its not quite clear
to me why that would not be possible to easily do as well. But
in understand how that RPL profile may not have been of any interest
for this work.

As i am not an expert for RPL, but mostly familia with only 
basic use of RPL, i am not sure how much of an expert a reader of this 
document is expected to be to be able to read, understand and vet this text.
I think i and other RPL beginners would be able to understand the text
and vet potential gotches better if more explanations where given,
and my feedback indicates this accordingly. But i will not claim
whether such explanations are always deemed necessary for the target
audience.

The mayor issue in the text is that it front-loads a lot of details
that are then hard to understand and open questions are only answered
much later. For example, packet encoding is put first in the document,
as opposed to (as i have observed it in more RFCs) at the end. Then
the text follows with processing description, and only finally with
what i consider to be a complete description of how the pieces
interact through examples. As mentioned in the details, i think the order should
be as much as possible top-down, starting with sufficienly complex
examples that introduce the technology to the extend that the
main concepts are used in the example. E.g.: sequential or complex track, 
sements, destinations, targets.

I only performed very opportunistic spell check, please do one yourself.
Please run idnits check too, it complains about the abstract for me.

Appended draft with numbered lines and non-numbered line feedback/comments.

Cheers & thanks again
    Toerless

     5	ROLL                                                     P. Thubert, Ed.
     6	Internet-Draft                                             Cisco Systems
     7	Updates: 6554 (if approved)                                  R.A. Jadhav
     8	Intended status: Standards Track                             Huawei Tech
     9	Expires: 28 January 2022                                     M. Gillmore
    10	                                                                   Itron
    11	                                                            27 July 2021
    12	
    13	
    14	                  Root initiated routing state in RPL
    15	                   draft-ietf-roll-dao-projection-19
...

   135	1.  Introduction
   136	
   137	   RPL, the "Routing Protocol for Low Power and Lossy Networks" [RPL]
   138	   (LLNs), is a generic Distance Vector protocol that is well suited for
   139	   application in a variety of low energy Internet of Things (IoT)
   140	   networks.  RPL forms Destination Oriented Directed Acyclic Graphs
   141	   (DODAGs) in which the Root often acts as the Border Router to connect
   142	   the RPL domain to the Internet.  The Root is responsible to select
                          ^^^^^^^^^^^^^^^
Really ? What is the "often" case where e.g.: at least nodes in the RPL network
can reach nodes across the Internet ? Aka: from my understanding, the common
deployment would attach to other limited domain (RFC8799) networks, for example
if i correctly glean from rfc9030, but not "the Internet". Otherwise, please
 provide a reference to justify "often ... to the Internet".

Aka: suggest to replace Internet with "other network" or maybe "a backbone".

   142	   the RPL domain to the Internet.  The Root is responsible to select
   143	   the RPL Instance that is used to forward a packet coming from the
   144	   Internet into the RPL domain and set the related RPL information in

Same comments about "the Internet".

   147	   The "6TiSCH Architecture" [6TiSCH-ARCHI] also leverages the
   148	   "Deterministic Networking Architecture" [RFC8655] centralized model
   149	   whereby the device resources and capabilities are exposed to an
   150	   external controller which installs routing states into the network
   151	   based on some objective functions that reside in that external
   152	   entity.  With DetNet and 6TiSCH, the component of the controller that

The DetNet architecture has a lot more aspects for which i am not sure, that
6TiSCH matches them (have not gone fully through 6TiSCH-ARCHI). Aka: DetNet as
of today implies the per-hop,per-flow IntServ architecture, but no DiffServ
for DetNet service hops. Is this what 6TiSCH-ARCHI does as well ?

If not, then maybe change to "levereges the aspects of the ..." to make
the claim more scoped to what the paragraph describes.

   152	   entity.  With DetNet and 6TiSCH, the component of the controller that
   153	   is responsible of computing routes is called a Path Computation
   154	   Element ([PCE]).
   155	
   156	   Based on heuristics of usage, path length, and knowledge of device
   157	   capacity and available resources such as battery levels and
   158	   reservable buffers, the PCE with a global visibility on the system
   159	   can compute direct Peer to Peer (P2P) routes that are optimized for
   160	   the needs expressed by an objective function.  This document

"Based on heuristics" has one doubt whether the result is deerministic. Not
saying heuristics may not play a role, but maybe fnd a better wording.

"global visibility" sounds like weather satellites. More specifically when
reading, i wonder if the scope of the discussion in this document can be
constraint to a single RPL network, or if it is important to understand
that the mechanisms of this document a also enabling more "interesting" paths.

Aka: If the following is one of the cases for which this drafts work is
in support of, then i would really like to see this type of picture and
explanation added as something like a reference picture with explanation:

               Client11               Client21             ClientN1
                |                      |                    |
  PCE        RPL-network1         RPL-network2         RPL-networkN     
   |        Root1     Rtr1b      Root2    Rtr2b  ...   RootN   RtrNb
   |          |         |          |        |           |       |
  ..................................................................
                       Backbone Network, L2 / L3, e.g.:
  -+----------+---------+----------+--------+-----------+-------+----

Aka: The PCE can calculate paths between clients in this internetwork.
An example path between Client11 and ClientN1 is composed of the
projected path between Client11 and one of the nodes connecting RPL-network1
to the backbone, e.g.: Rtr1b, a path through the backbone, and finally
a path through RPL-networkN, again including the choice of edge
router to the backbone, e.g.: RtrNb.

I guess if the solution does not support RtrIb, then its explanation
could more easily be constrained to just a single RPL-network.

   160	   the needs expressed by an objective function.  This document

This statement is confusing.
Without this draft, the objective functions result in specific paths,
and these paths are insufficient, so the PCE also uses this drafts
mechanism to achieve better paths. So the objective function clearly
was not sufficient. Besides, the objective function is very specific
to parameters used in distributed path calculation, not PCE.

In my mind, there is some goal/objective for the path to be calculated,
and this objective is achieved by OF to create DODAG and paths, and if
those paths are insufficient, then 
and a controller can achieve that objective by defining a
but when the controller determinses that it can not solely be achieved
through objective function parameters, then it starts using this drafts
mechanism...

   160	   the needs expressed by an objective function.  This document

Suggest new paragraph before "This"

   161	   specifies protocol extensions to RPL [RPL] that enable the Root of a
   162	   main DODAG to install centrally-computed routes inside the DODAG on
   163	   behalf of a PCE.
   172	
   173	   This specification expects that the main RPL Instance is operated in
   174	   RPL Non-Storing Mode of Operation (MOP) to sustain the exchanges with
   175	   the Root.  In that Mode, the Root has enough information to build a
                    ^ Only ?
   176	   basic DODAG topology based on parents and children, but lacks the
                                                                  ^ still
   177	   knowledge of siblings.  This document adds the capability for nodes

Aka: in storing mode the root would even have less information, right ?

   178	   to advertise sibling information in order to improve the topological
   179	   awareness of the Root.
   180	
   181	   As opposed to the classical RPL operations where routes are injected
   182	   by the Target nodes, the protocol extensions enable the Root of a
   183	   DODAG to project the routes that are needed onto the nodes where they
   184	   should be installed.  This specification uses the term Projected
   185	   Route to refer to those routes.  Projected Routes can be used to
   186	   reduce the size of the source routing headers with loose source
   187	   routing operations down the main RPL DODAG.  Projected Routes can
   188	   also be used to build transversal routes for route optimization and
   189	   Traffic Engineering purposes, between nodes of the DODAG.
   190	
   191	   A Projected Route may be installed in either Storing and Non-Storing
   192	   Mode, potentially resulting in hybrid situations where the Mode of
   193	   the Projected Route is different from that of the main RPL Instance.
   194	   A Projected Route may be a stand-alone end-to-end path or a Segment
   195	   in a more complex forwarding graph called a Track.
   197	   The concept of a Track was introduced in the 6TiSCH architecture, as
   198	   a potentially complex path with redundant forwarding solutions along
   199	   the way.

Please add a reference to the spec that introduced Track.

Where is "stand-alone" introduced ? If elswhere, add reference, otherwise
say its introduced here. Also, everything else is capitalized, maybe you want
to capitalize also Stand Alone.

   199     With this specification, a Track is a DODAG formed by a RPL
   200	   local Instance that is rooted at the Track Ingress.  If there is a
   201	   single Track Egress, then the Track is reversible to form another
   202	   DODAG by reversing the direction of each edge.  A node at the ingress
   203	   of more than one Segment in a Track may use one or more of these
   204	   Segments to forward a packet inside the Track.

The last sentence is using the term Segment to explain something new, but the
term Segment was not sufficiently defined in before. Other than that a Segment
can be or is always (?) a Projected Route, but Projected Route is also undefined.
   
   206	   The "Reliable and Available Wireless (RAW) Architecture/Framework"
   207	   [RAW-ARCHI] defines the Path Selection Engine (PSE) that adapts the
   208	   use of the path redundancy within a Track to defeat the diverse
   209	   causes of packet loss.
   210
   211	   The PSE is a dataplane extension of the PCE; it controls the
   212	   forwarding operation of the packets within a Track, using Packet ARQ,
   213	   Replication, Elimination, and Overhearing (PAREO) functions over the
   214	   Track segments, to provide a dynamic balance between the reliability
   215	   and availability requirements of the flows and the need to conserve
   216	   energy and spectrum.
   217	
   218	   The time scale at which the PCE (re)computes the Track can be long,
   219	   using long-term statistical metrics to perform global optimizations
   220	   at the scale of the whole network.  Conversely, the PSE makes
   229	   forwarding decisions at the time scale of one or a small collection
   230	   of packets, based on a knowledge that is limited in scope to the
   231	   Track itself, so it can be refreshed at a fast pace.

I would suggest to restructure this. Before going into the RPL details as you do
in before, maybe start with the problem to be solved. Which seems to be a
mechanism to support packet replication, traversal over alternative paths and
duplicate elimination (and seemingly more). 6TiSCH introduced Tracks as the
concept for redundant paths, RAW inroduced PAREO. This document introduces
one solution to to build Tracks with RPL und a mechanism called Projected Routes.

Something like that to have a more logical sequence of explanations, top to bottom.
   
   233	   Projected Routes must be used with the parsimony to limit the amount

Parsimony in he sense you use it, was never used in RFCs, rc871 used law of parsimony.
Suggest to reword for easier reading. For example, "Care must be taken that state installed for
projected routes fit in each devices resources".

Is the amount of traffic solely a responsibility of the installation of projected
routes ? Isn't this also responsibility of the PSE ? (just guessing, haven't read
up on it).

   234	   of state that is installed in each device to fit within the device
   235	   resources, and to maintain the amount of rerouted traffic within the
   237	   capabilities of the transmission links.  The methods used to learn
   237	   the node capabilities and the resources that are available in the
   238	   devices and in the network are out of scope for this document.
   239	
   240	   This specification uses the RPL Root as a proxy to the PCE.  The PCE
   241	   may be collocated with the Root, or may reside in an external
   242	   Controller.
   243	
   244	   In that case, the PCE exchanges control messages with the Root over a
              ^^^^ the latter
   245	   Southbound API that is out of scope for this specification.  The
                     ^ PCE
   246	   algorithm to compute the paths and the protocol used by an external
   247	   PCE to obtain the topology of the network from the Root are also out
   248	   of scope.

In his AD review for draft-ietf-bier-te-arch, Alvaro asked me to provide examples
for such topology discovery. YOu can of course wait out if this will happen for
his doc too, i personally have no strong opinions, but if you need example
text, see draft-ietf-bier-te-arch, 3.2.1.1, Third paragraph.

Personally, i do not like the conditioning that a southbound API is supposedly
only necessary when the PCE is external from the RPL Root. IMHO, there always
needs to be at least an informat model for Projected Routes. Which you may
agree on, but its not mentioned. PCE and RPL Root can just be independent
software entities on the same node.

   260	2.2.  Glossary
   261	
   262	   This document often uses the following acronyms:
   263	
   264	   CMO:  Control Message Option
   265	   DAO:  Destination Advertisement Object
   266	   DAG:  Directed Acyclic Graph
   267	   DODAG:  Destination-Oriented Directed Acyclic Graph; A DAG with only
   268	      one vertex (i.e., node) that has no outgoing edge (i.e., link)
   269	   LLN:  Low-Power and Lossy Network
   270	   MOP:  RPL Mode of Operation
   271	   P-DAO:  Projected DAO
   272	   P-Route:  Projected Route
   273	   PDR:  P-DAO Request
   274	   RAN:  RPL-Aware Node (either a RPL Router or a RPL-Aware Leaf)
   275	   RAL:  RPL-Aware Leaf
   276	   RH:  Routing Header
   285	   RPI:  RPL Packet Information
   286	   RTO:  RPL Target Option
   287	   RUL:  RPL-Unaware Leaf
   288	   SIO:  RPL Sibling Information Option
   289	   SR-VIO:  A Source-Routed Via Information Option, used in Non-Storing-
   290	      Mode P-DAO messages.
   291	   TIO:  RPL Transit Information Option
   292	   SF-VIO:  A Via Information Option, used in Storing-Mode P-DAO
   293	      messages.
   294	   VIO:  A Via Information Option; it can be a SF-VIO or an SR-VIO.

I had a hard time remembering SR-VIO and SF-VIO throughout the text. Maybe
SM-VIO and NSM-VIO would be easier to remember and better because they explicitly
refer to the explanation (Storing Mode, Non-Storing Mode).

I'll spare you the request for a full Terminology section for these terms with
references, maybe others will do so.

It would make sense though to move the terms newly introduced in this doc,
such as P-Route , P-DAO and the like into section 2.3 and rename 2.3 to "New terms".
Derived terms like P-Route can of course stay concise.
   
   296	2.3.  Other Terms
...

   327	3.  Extending RFC 6550

You have tagged this draft as an Update to RFC6550. You should IMHO have a
section where you summarize what that exactly entails, ideally call "Updated to RFC6550".

AFAIK, we do not have a good formal structure for such update description, Mirja
tried to propose some more keywords, but so far, Update can mean anything.

I would suggest to summarize what type of update this is by making statements
answering the following type of questions (maybe i forgot some). These statements
are also useful when they are answering the questions below with No. I leave it up to
you if you feel this would be good to go here in the beginnin, or if you'd rather
want to summarize it in the end of the document.

Questions:

Does this document specify any functionality that is REQUIREDS or RECOMMENDED
for implementations of RFC6550 ? If so, please detail them.  Else, this can be called
a fully OPTIONAL update for RFC6550.

Will implementations supporting this RFC continue to be backward compatible with
all prior RFCs, RFC6550 and related ? If not, please describe any changes in 
interoperability.

Does this RFC introduce any functional extensions to RFC6550 or other RFC
through mechanisms other than pre-defined extension points ?

Are any pre-defined extension points of RFC6550 or other RFC used, which are not
already IANA registries ?  If so, please include references to the original RFC
section where that extension point was described.

(first time i am trying to formalize these type of question...)

IMHO outside the scope of documenting the "Update" flag is mixed deployment.
If there is no text for that, would be good to add that somehwere. Update section
wouldn't be a bad place.

   341	3.1.  Projected DAO

At this point i am worried whether i am correctly guessing at the forwarding
plane behavior of projected routes, because i felt it was presented in the
Intro section mostly en-passant, but it is hard to follow the document with
the correct explanation of how forwarding works.

What i figured from the Intro is that Projected Routes would allow the root
to specify a loose path in the RH, even though only non-storing mode is used.
Whenever a RPL node then sees a next-op in the RH it looks for a projected
Route towards that next-hop and hmm... just forwards the packet to the
first next hop on the projeted route ? Or it needs to change the routing
header to prepend the projected route ?

And i have absolutely no idea what interactions there are between PSE and
Projected routes in the forwarding plane..

Section 9 has some signalling examples. Maybe it would be good to create
some introductory example that shows the relevant forwarding plane aspects.

   343	   Section 6 of [RPL] introduces the RPL Control Message Options (CMO),
   344	   including the RPL Target Option (RTO) and Transit Information Option
   345	   (TIO), which can be placed in RPL messages such as the Destination
   346	   Advertisement Object (DAO).

   346	   This specification extends the DAO
   347	   message with the Projected DAO (P-DAO); a P-DAO message signals a
   348	   Projected Route to one or more Targets using the new CMOs presented
   349	   therein.

This is confusing. If i am guessing right, i would suggest to write:

This specification defines a new CMO carrying a Projected Route. When this
Projected Route CMO is included in a DAO message, this is called a Projected DAO (P-DAO).

I do not get the "signals _a_ Projected Route to one or _more_ Targets". How can
a single P-DAO be signalled to more than one recipient ?

   349     This specification enables to combine one or more Projected
   350	   Routes into a DODAG called a Track, that is traversed to reach the
   351	   Targets.
   352	
   353	   The Track is assimilated with the DODAG formed for a Local RPL
   354	   Instance.  The local RPLInstanceID of the Track is called the
   355	   TrackID, more in Section 7.2.  A P-DAO message for a Track signals
   356	   the TrackID in the RPLInstanceID field.  The Track Ingress is
   357	   signaled in the DODAGID field of the Projected DAO Base Object; that
   358	   field is elided in the case of the main RPL Instance.  The Track
   359	   Ingress is the Root of the Track, as shown in Figure 1.

How about the text here first finishes up the specification of the P-DAO CMO
before explaining some, but likely not all details of how this stuff
works together ?

   360	
   361	   This specification defines the new "Projected DAO" (P) flag.  The 'P'
   362	   flag is encoded in bit position 2 (to be confirmed by IANA) of the
   363	   Flags field in the DAO Base Object.  The Root MUST set it to 1 in a
   364	   Projected DAO message.  Otherwise it MUST be set to 0.  It is set to
   365	   0 in legacy implementations as specified respectively in Sections
   366	   20.11 and 6.4 of [RPL]. .
   367	
   368	      0                   1                   2                   3
   369	      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   370	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   371	     |    TrackID    |K|D|P|  Flags  |   Reserved    | DAOSequence   |
   372	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   373	     |                                                               |
   374	     +                                                               +
   375	     |                                                               |
   376	     +               IPv6 Address of the Track Ingress               +
   377	     |                                                               |
   378	     +                                                               +
   379	     |                                                               |
   380	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   381	     |   Option(s)...
   382	     +-+-+-+-+-+-+-+-+
   383	
   384	                    Figure 1: Projected DAO Base Object
   385	
   386	   New fields:
   387	
   388	   TrackID:  In the case of a P-DAO, the RPLInstanceID field is called
   397	      TrackID.  This is a naming convenience but does not change the
   398	      semantics and format of the RPLInstanceID that is used as TrackID.

Maybe then stick to calling it RPLInstanceID in the ASCII and not calling it
a new field (nitpicking).
   
   400	   P:  1-bit flag (position to be confirmed by IANA).
   401	
   402	      The 'P' flag is set to 1 by the Root to signal a Projected DAO,
   403	      and it is set to 0 otherwise.
   404	
   405	   In RPL Non-Storing Mode, the TIO and RTO are combined in a DAO
   406	   message to inform the DODAG Root of all the edges in the DODAG, which
   407	   are formed by the directed parent-child relationships.  Options may
   408	   be factorized; multiple RTOs may be present to signal a collection of
   409	   children that can be reached via the parent(s) indicated in the
   410	   TIO(s) that follows the RTOs.  This specification generalizes the
   411	   case of a parent that can be used to reach a child with that of a
   412	   whole Track through which both children and siblings of the Track
   413	   Egress are reachable.

This again seems to be mixing larger logical behavior explanation into what
probably should be just the spec for the new message encodings here. See how
you can decouple the larger system explamnations from the encoding spec.
   
   415	   New CMOs called the Via Information Options (VIO) are introduced for
   416	   use in P-DAO messages as a multihop alternative to the TIO.  One VIO

a) Add forward pointer to section defining VIO

b I get the feeling as if the whole mentioning of TIO and RTO above should simply
go in a separate chapter for RPL experts with a title like "Why are TIO and RTO
not sufficient". Or "How to combine TIO/RTO with SF-VIO" etc.. but try to
stick to topic at hand here. Feeble minded readers like myself can only balance
a limited number of partially understood terms in the air at the same time.

   417	   is the Stateful VIO (SF-VIO); the SF-VIO installs Storing-Mode
                                                            ^ a ?
   418	   Projected Route  along a strict segment.  The other is the Source-
                          ^ s ?
   419	   Routed VIO (SR-VIO); the SR-VIO installs a Non-Storing-Mode Projected
   420	   Route at the Track Ingress, which uses that state to encapsulate a
   421	   packet with a Routing Header (RH) to the Track Egress.

Question... If i just use basic RPL with non-storing mode, i already
need an RH. And that is let's say a strict path. So after the first hop of that
RH, my next hop is actually a track ingres for which i have SR-VIO. Does this
mean i need to do a full new IPv6 encap of the packet to insert the new
RH for the track ? If so:

a) i'd say: "to encapsulate the packet into an IPv6 packe with a new RH to the track egress.
b) What about MTU issues due to the encap ? Can not find word MTU in text.
   
   423	   Like in a DAO message, the RTOs can be factorized in a P-DAO, but the
   424	   Via Information Options cannot. 

   424	   A P-DAO contains one or more RTOs
                  ^ MUST/SHOULD/MAY ?

   425	   that indicate the destinations that can be reached via the Track, and
   426	   exactly one VIO that signals a sequence of nodes .  In Non-Storing
                                                           ^ That form the track ?

       root ....... Track-Ingres ...(Track Midpoints)... Track-Egres ..... Destination1
                                                                     ...
                                                                     ...   DestinationN
P-DAO has:
  one RTO for each DestinationI
  one VIO for the Track: Midpoints,Egres

Semantic: When packet reaches Track-Ingres, it checks whether destination or
next-hop is one of the DestinationI, if so, then use the track. If SR-VIO,
then encap IPv6/RH, if SF-VIO, then just forward to first hop on track, 
which will also have installed the right state for the track...

Something like this with picture would make the whole concept so much
easier to understand (to me).

   427	   Mode, the Root sends the P-DAO to the Track Ingress where the source-
   428	   routing state is stored.  In Storing Mode, the P-DAO is sent to the
   429	   Track Egress and forwarded along the Segment in the reverse
   430	   direction, installing a Storing Mode state to the Track Egress at
   431	   each hop.  In both cases the Track Ingress is the owner of the Track,
   432	   and it generates the P-DAO-ACK when the installation is successful.

How would the root know whether in storing node all the track midpoints
did successfully install the necessary track state ? If not, hen it would be
worth pointing out how storing mode may end up being less reliable ? 

   434	3.2.  Sibling Information Option

Is there any reason why we wouldn't first want to have the VIO section here
so a feeble minded reader could pop off some open definitions of the stack
and declare understanding victory on whats explaind so far ?

To answe my own question, i think your structure is around whatever RFC
is supposedly extended by a new semantic introduced, but that results in
terrible flow of reading. I would strongly suggest to  reshuffle the
text from the most simple cases to the most complex cases and have
separate short sections summarizing for each affected RFC how it is
extended usin the template questions above, using references to the main
specification part.

   436	   This specification adds another CMO called the Sibling Information
   437	   Option (SIO) that is used by a RPL Aware Node (RAN) to advertise a
   438	   selection of its candidate neighbors as siblings to the Root, more in
   439	   Section 6.4.  The sibling selection process is out of scope.  The
   440	   expectation is that a node reports a Sibling Address in a SIO based
   441	   on an active address registration [RFC8505] from that sibling for
   442	   that address with the 'R' flag not set in the EARO.  The node may
   443	   assess the liveliness of the sibling at any time by performing a
   444	   registration for one of its own addresses, either a link local or a
   453	   global one, depending on whether the node expects the sibling to
   454	   perform a matching advertisement in its own SIO.

I am not even going to try to understand this without a prior graphical
example use case on how this would be used.

   456	3.3.  P-DAO Request
   457	
   458	   Two new RPL Control Messages are also introduced, to enable a RAN to
   459	   request the establishment of a Track between self as the Track
   460	   Ingress Node and a Track Egress.  The RAN makes its request by
   461	   sending a new P-DAO Request (PDR) Message to the Root.  The Root
   462	   confirms with a new PDR-ACK message back to the requester RAN, see
   463	   Section 6.1 for more.

The split between this text and 6.1 is weird and IMHO not helpfull. Merge.
WHats ven the logic to split some explanations out into section 6 and leave
others (P-DAO for example) here ?

I would also like some motivational example of what would make a RAN send
out a P-DAO Request. Could it be that the RAN is a PSE ingres ? I am asking,
because this looks like a request where it might be highly desirable to have
more contextual information in the request than just the few fields defined in
6.1. How about a 32 bit policy-ID field or the like.. But just guessing.
Something for the PCE to match up PSE stuff it established with P-DAO
requests it receives later. Unless you feel strongly that association is
unambiguous now.

   463     A positive PDR-ACK indicates that the Track
   464	   was built and that the Roots commits to maintain the Track for the
   465	   negotiated lifetime.  In the case of a complex Track, each Segment is
   466	   maintained independently and asynchronously by the Root, with its own
   467	   lifetime that may be shorter, the same, or longer than that of the
   468	   Track.

I guess those different liftimes are not meant to make the solution more fragile
by randomnly expiring timers for different parts of a track, but because the
the parts of a projected routes affected can only change when they expire ?
In any case, an explanation of the semantic impact of lifetimes would be
useful.

   468     The Root may use an asynchronous PDR-ACK with an negative
   469	   status to indicate that the Track was terminated before its time.

And if that happens, what should a RAN do that has some configuration telling
it to request the P-DAO ? Sounds like the need for the definition of some
exponential back-off re-request scheme ?

Also, when the request is just renewed upon timeout, but the reply changes,
i figure that the impact in stateful mode may be some inconsistent forwarding
while the track midpoints update their routes. No issue i guess in stateless.
Would be useful to mention. Not sure if/what countermeasures for consistency
RPL already provides. If it does, would be good to mention.

   471	3.4.  Extending the RPI
   472	
   473	   Sending a Packet within a RPL Local Instance requires the presence of
   474	   the abstract RPL Packet Information (RPI) described in section 11.2.
   475	   of [RPL] in the outer IPv6 Header chain (see [USEofRPLinfo]).  The
   476	   RPI carries a local RPLInstanceID which, in association with either
   477	   the source or the destination address in the IPv6 Header, indicates
   478	   the RPL Instance that the packet follows.
   479	
   480	   This specification extends [RPL] to create a new flag that signals
   481	   that a packet is forwarded along a projected route.
   482	
   483	   Projected-Route 'P':  1-bit flag.  It is set to 1 if this packet is
   484	      sent over a projected route and set to 0 otherwise.

This leaves me guessing when and how this applied. I can see how this would be
applicable to both stateful and stateless Projected route operastions, but in
either case, the forwarding plane behavior needs to be explained, ideall with
example for each (of the two?) cases.

Also: Please add forward pointer to next section saying "For concrete encoding
of the P flag, see section 4.".

   486	4.  Extending RFC 6553

I think this RFC MUST claim to be an update to RFC6553, because the P-flag
added to this concrete RPI RFC exhausts a non-IANA extension point, and
the only way to formally avoid that any other RFCs could collide (and allocate
the same bit) is to make this RFC an update to RFC6553. Same logic also
applies to update for RFC6550 and P-DAO P flag.

Just to be save, claim also update to RFC9008 to given how you mention it,
and we obviously want this RFC to also apply to RPI headers with 0x23.

   511	                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   512	                                     |  Option Type  |  Opt Data Len |
   513	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   514	     |O|R|F|P|0|0|0|0| RPLInstanceID |          SenderRank           |
   515	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   516	     |                         (sub-TLVs)                            |
   517	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   518	
   519	                    Figure 2: Extended RPL Option Format
   520	
   521	   Option Type:  0x23 or 0x63, see [USEofRPLinfo]
   522	
   523	   Opt Data Len:  See [RFC6553]
                         ^ unchanged, 
   524	
   525	   'O', 'R' and 'F' flags:  See [RFC6553].  Those flags MUST be set to 0
   526	      by the sender and ignored by the receiver if the 'P' flag is set.
   527	
   528	   Projected-Route 'P':  1-bit flag as defined in Section 3.4.
   529	
   530	   RPLInstanceID:  See [RFC6553].  Indicates the TrackId if the 'P' flag
   531	      is set.

Add 'see also section 3.1' ?
   
   533	   SenderRank:  See [RFC6553].  This field MUST be set to 0 by the
   534	      sender and ignored by the receiver if the 'P'flag is set.

Would you mind to add expanation as to what can happen when this passes via a router not supporting
this RFC and therefore ignoring the P flag but interpreting the other fields ?

   536	5.  Extending RFC 8138
   537	
   538	   Section 6.3 of [RFC8138] presents the formats of the 6LoWPAN Routing
   539	   Header of type 5 (RPI-6LoRH) that compresses the RPI for normal RPL
                                       ^
   in the IANA "Critical 6LoWPAN Routing Header Type Registry"

   540	   operation.  The format of the RPI-6LoRH is not suited for Projected
   541	   routes since the O,R,F flags are not used and the Rank is unknown and
   542	   ignored.
   543	
   544	   This specification introduces a new 6LoRH, the P-RPI-6LoRH, with a
   545	   type of 7.  The P-RPI-6LoRH header is usually a a Critical 6LoWPAN
                    ^                                   ^^^
                    |
   in the IANA "Critical 6LoWPAN Routing Header Type Registry"

   546	   Routing Header, but it can be elective as well if an SRH-6LoRH is
                                      ^^^^^^^^^^^^^^^^^^^
also use type TBD1 from the IANA "Electivce 6LoWPAN Routing Header Type Registry"

https://www.iana.org/assignments/_6lowpan-parameters/_6lowpan-parameters.xhtml#critical-6lowpan-routing-header-type

Elective Type 7 is already gone. If you want to get the same numbers for
elective and critical yo may want to also revisit to choose 7 for critical.

Who made you be so adventerous to write an actual number 7 into the draft without an
early allocation anyhow ? How about asking for an early allocation ?

   547	   present and controls the routing decision.
   548	
   549	   The P-RPI-6LoRH is designed to compress the RPI along RPL Projected
   550	   Routes.  It sformat is as follows:
                     ^^^
   551	
   565	                0                   1                   2
   566	                0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   567	               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   568	               |1|0|E| Length  | 6LoRH Type 7  | RPLInstanceID |
   569	               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   570	
   571	
   572	                        Figure 3: P-RPI-6LoRH Format
   573	
   574	   Elective 'E':  See [RFC8138].  The 'E' flag is set to 1 to indicate
   575	      an Elective 6LoRH, meaning that it can be ignored when forwarding.

Please explain length or point to RFC8138 (inchanged from RFC8318, section XX.YY).

Please DO NEVER include the assicned number into the field, just write "6LoRH Type".
Explain in text that is the assined type for criical or elective depending on E flag.

Explain that RPLInstanceID is the TrackID (see section 3.1 ?) Or if not, what it is.

   577	6.  New RPL Control Messages and Options
   578	
   579	6.1.  New P-DAO Request Control Message
   580	
   581	   The P-DAO Request (PDR) message is sent by a Node in the main DODAG
   582	   to the Root.  It is a request to establish or refresh a Track where
   583	   this node is Track Ingress.  The source IPv6 address of the PDR
   584	   signals the Track Ingress of the requested Track, and the TrackID is
   585	   indicated in the message itself.  One and only one RPL Target Option
   586	   MUST be present in the message.  The RTO signals the Track Egress,
   587	   more in Section 7.1.
   588	
   589	   The RPL Control Code for the PDR is 0x09, to be confirmed by IANA.

Correct form is TBDi (TBD2 ?) instead of 0x09.
If you are not in a hurry, all TBDi can be resolved during IANA/RFC-editor procss.
If you want to lock in a number get an early allocation first.

   590	   The format of PDR Base Object is as follows:
   591	
   592	      0                   1                   2                   3
   593	      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   594	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   595	     |   TrackID     |K|R|   Flags   |  ReqLifetime  | PDRSequence   |
   596	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   597	     |   Option(s)...
   598	     +-+-+-+-+-+-+-+-+
   599	
   600	                     Figure 4: New P-DAO Request Format
   601	
   602	   TrackID:  8-bit field indicating the RPLInstanceID associated with
   603	      the Track.
   604	
   605	   K:  The 'K' flag is set to indicate that the recipient is expected to
   606	      send a PDR-ACK back.
   607	
   608	   R:  The 'R' flag is set to request a Complex Track for redundancy.
   609	
   610	   Flags:  Reserved.  The Flags field MUST initialized to zero by the
   611	      sender and MUST be ignored by the receiver
   612	
   613	
   614	
   615	
   616	Thubert, et al.          Expires 28 January 2022               [Page 11]
   617	
   618	Internet-Draft               DAO Projection                    July 2021
   619	
   620	
   621	   ReqLifetime:  8-bit unsigned integer.  The requested lifetime for the
   622	      Track expressed in Lifetime Units (obtained from the DODAG
   623	      Configuration option).
   624	
   625	      A PDR with a fresher PDRSequence refreshes the lifetime, and a
   626	      PDRLifetime of 0 indicates that the track should be destroyed.

... It would be sent for example when the function for which the Node requested
the track is deactivated. ?!

   628	   PDRSequence:  8-bit wrapping sequence number, obeying the operation
   629	      in section 7.2 of [RPL].  The PDRSequence is used to correlate a
   630	      PDR-ACK message with the PDR message that triggered it.  It is
   631	      incremented at each PDR message and echoed in the PDR-ACK by the
   632	      Root.
   633	
   634	6.2.  New PDR-ACK Control Message
   635	
   636	   The new PDR-ACK is sent as a response to a PDR message with the 'K'
   637	   flag set.  The RPL Control Code for the PDR-ACK is 0x0A, to be
   638	   confirmed by IANA.  Its format is as follows:

Same IANA/TBD concern as above.

   639	
   640	      0                   1                   2                   3
   641	      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   642	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   643	     |    TrackID    |     Flags     | Track Lifetime|  PDRSequence  |
   644	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   645	     | PDR-ACK Status|                Reserved                       |
   646	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   647	     |  Option(s)...
   648	     +-+-+-+-+-+-+-+
   649	
   650	                Figure 5: New PDR-ACK Control Message Format
   651	
   652	   TrackID:  The RPLInstanceID of the Track that was created.  The value
   653	      of 0x00 is used to when no Track was created.
                              ^^

Same question as in before. Any standardized logic what to do in case of 0x00 failure,
if not, then why not.

   654	
   655	   Flags:  Reserved.  The Flags field MUST initialized to zero by the
   656	      sender and MUST be ignored by the receiver
   657	
   658	   Track Lifetime:  Indicates that remaining Lifetime for the Track,
   659	      expressed in Lifetime Units; the value of zero (0x00) indicates
   660	      that the Track was destroyed or not created.
   661	
   662	   PDRSequence:  8-bit wrapping sequence number.  It is incremented at
   663	      each PDR message and echoed in the PDR-ACK.

according to section 7.2 of [RPL] ?!

   665	   PDR-ACK Status:  8-bit field indicating the completion.  The PDR-ACK
                                                                 ^ status
   666	      Status is substructured as indicated in Figure 6:
   676	
   677	                                 0 1 2 3 4 5 6 7
   678	                                +-+-+-+-+-+-+-+-+
   679	                                |E|R|  Value    |
   680	                                +-+-+-+-+-+-+-+-+
   681	
   682	                       Figure 6: PDR-ACK status Format
   683	
   684	      E:  1-bit flag.  Set to indicate a rejection.  When not set, the
   685	         value of 0 indicates Success/Unqualified acceptance and other
   686	         values indicate "not an outright rejection".
   687	      R:  1-bit flag.  Reserved, MUST be set to 0 by the sender and
   688	         ignored by the receiver.
   689	      Status Value:  6-bit unsigned integer.  Values depending on the
   690	         setting of the 'E' flag, see Table 27 and Table 28.
   691	
   692	   Reserved:  The Reserved field MUST initialized to zero by the sender
                                             ^ be
   693	      and MUST be ignored by the receiver
   694	
   695	6.3.  Via Information Options
   696	
   697	   A VIO signals the ordered list of IPv6 Via Addresses that constitutes
   698	   the hops of either a Serial Track or a Segment of a more Complex
   699	   Track.  A VIO MUST contain at least one Via Address, and a Via
   700	   Address MUST NOT be present more than once, otherwise the VIO MUST be
   701	   ignored.

If i understand it correctly, for the SR-VIO, the sequence of addresses would
ultimately end up in the RPL steering header of packets. I browsed through
RFC8754 and think i can not find a similar exclusion. So a justification
why this optimization is done for SF-VIO would be good if you really want to keep it.

For SF-VIO, this seems to be taken apart and every node listed creates a
next-hop route. So if the same node is addressed twice, it could become
confused, which instance of its own address to choose to install the route, right ?

And what does "ignore" mean anyhow, e.g.: would the Target Options still be acted
upon ? It rather sounds to me as if you would want the whole Projected DAO message
to be rejected ?

Is duplicate address the only case of a "broken" projected DAO that you can
discover and reject ? E.g.: can nodes have multiple addresses ? Such as
anycast addresses ?

Would be good to elaborate about such "broken" projected DAO more if there are different
cases of it.

   701	   The format of the Via Information Options is as follows:
   732	
   733	        0                   1                   2                   3
   734	        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   735	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   736	       |   Type        | Option Length |     Flags     |   SegmentID   |
   737	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   738	       |Segm. Sequence | Seg. Lifetime |      SRH-6LoRH header         |
   739	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   740	       |                                                               |
   741	       +                                                               +
   742	       .                                                               .
   743	       .                     Via Address 1                             .
   744	       .                                                               .
   745	       +                                                               +
   746	       |                                                               |
   747	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   748	       |                                                               |
   749	       .                              ....                             .
   752	       |                                                               |
   751	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   752	       |                                                               |
   753	       +                                                               +
   754	       .                                                               .
   755	       .                     Via Address n                             .

add (n <= 15) ?

   756	       .                                                               .
   757	       +                                                               +
   758	       |                                                               |
   759	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   760	
   761	
   762	                  Figure 7: VIO format (uncompressed form)
   763	
   764	   Option Type:  0x0B for SF-VIO, 0x0C for SR-VIO (to be confirmed by
   765	      IANA)

Same concern as prior illegal occupations of IANA codepoints in this spec ;-))
   
   767	   Option Length:  In bytes; variable, depending on the number of Via
   768	      Addresses and the compression.

Something like total size of the Option ... in bytes ?
Is this semantic mandated by prior RFC ?  If it could count differently,
it could allow for more than 15 hops, although i have no idea if that would
be relevant.

   770	   SegmentID:  8-bit field that identifies a Segment within a Track or
   771	      the main DODAG as indicated by the TrackID field.  The value of 0
   772	      is used to signal a Serial Track, i.e., made of a single segment.

Another basic signaling element not yet explained, so somewhat mysterious here

   774	   Segment Sequence:  8-bit unsigned integer.  The Segment Sequence
   775	      obeys the operation in section 7.2 of [RPL] and the lollipop
   776	      starts at 255.
   777
   778	      When the Root of the DODAG needs to refresh or update a Segment in
   779	      a Track, it increments the Segment Sequence individually for that
   780	      Segment.
   781	
   789	      The Segment information indicated in the VIO deprecates any state
   790	      for the Segment indicated by the SegmentID within the indicated
   791	      Track and sets up the new information.
   792	
   793	      A VIO with a Segment Sequence that is not as fresh as the current
   794	      one is ignored.
   795	
   796	      A VIO for a given DODAGID with the same (TrackID, SegmentID,
   797	      Segment Sequence) indicates a retry; it MUST NOT change the
   798	      Segment and MUST be propagated or answered as the first copy.
   799	
   800	   Segment Lifetime:  8-bit unsigned integer.  The length of time in
   801	      Lifetime Units (obtained from the Configuration option) that the
   802	      Segment is usable.
   803	
   804	      The period starts when a new Segment Sequence is seen.  The value
   805	      of 255 (0xFF) represents infinity.  The value of zero (0x00)
   806	      indicates a loss of reachability.
   807	
   808	      A P-DAO message that contains a VIO with a Segment Lifetime of
   809	      zero is referred as a No-Path P-DAO in this document.
   810	
   811	   SRH-6LoRH header:  The first 2 bytes of the (first) SRH-6LoRH as
   812	      shown in Figure 6 of [RFC8138].  A 6LoRH Type of 4 means that the
   813	      VIA Addresses are provided in full with no compression.
   814	
   815	   Via Address:  An IPv6 address along the Segment.
   816	
   817	      In a SF-VIO, the list is a strict path between direct neighbors,
   818	      from the Segment Ingress to Egress, both included.  The router
   819	      that processes an SF-VIO MAY create additional routing state
   820	      towards the nodes after self via the node immediately after self
   821	      in the SF-VIO, but in case of memory shortage the routes to the
   822	      Targets have precedence since they are the ones that the router
   823	      commits to store.

Again, i am at a lack of understanding the base theory of operations of forwarding,
I have Track Ingres, Track Egres, Destinations, Target and somehow i have
Segments with addresses, wheree i do not know how Segment Ingres and Segment Egres
may or may not map to Track Ingres/Egres, Destinations or Targets.

Picture me this, please ? ;-))

So, what exactly does the routing state look like ? whats the lookup ?
Something like (RPLInstanceID==TrackID, Destination) ? Or rather: What is
the example scenario when a the above described additional routing state
to the nodes after self would would be used ?

   825	      In an SR-VIO, the list includes the egress but not the ingress
   826	      node.  It starts at the first hop and ends at a Track Egress.  In

Seems like a mayor difference in flexiblity of stateful vs. stateless operations than ?
No segment layer with SR-VIO ?

   827	      that case, the Track Egress MUST be considered as an implicit
   828	      Target, so it MUST NOT be listed it in a RPL Target Option.  The
   829	      list in an SR-VIO may be loose, provided that each listed node has
   830	      a path to the next listed node, e.g., via a segment or another
   831	      Track.

But you are not telling me you would want to create the freedom to have stateless
operation rely on routing state created by SF-VIO where you said it might
not exist in case of memory shortage which the stateless encapsulator would
know nothing about, right ?

   833	      In the case of a SF-VIO, or if [RFC8138] is not used in the data
   834	      packets, then the Root MUST use only one SRH-6LoRH per Via
   835	      Information Option, and the compression is the same for all the
   836	      addresses, as shown in Figure 7.

I do not see any address compression in Figure 7, nor was compression mentioned
so far. 

Do you mean figure 7 in section 5.1 of [RFC8138] ?

   845	      In case of an SR-VIO, and if [RFC8138] is in use in the main
   846	      DODAG, then the Root SHOULD optimize the size of the SR-VIO;

Any example how ?

   846         more
   847	      than one SRH-6LoRH may be present, e.g., if the compression level
   848	      changes inside the Segment and different SRH-6LoRH Types are
   849	      required.

That rather sounds as if those are cases where optimiation would no be possible ?

   849        The content of the SR-VIO starting at the first SRH-
   850	      6LoRH header is thus verbatim the one that the Track Ingress
   851	      places in the packet encapsulation to reach the Track Ingress.

Example with picture would help.

   853	6.4.  Sibling Information Option
   854	
   855	   The Sibling Information Option (SIO) provides indication on siblings
   856	   that could be used by the Root to form Projected Routes.  One or more
   857	   SIO(s) may be placed in the DAO messages that are sent to the Root in
   858	   Non-Storing Mode.

Is this some poor-mans (little signaling) form of signaling to help the
root do some topology discovery ? If so, then it probably would be something
that needs to go to the PCE, right ? Maybe this type of high level
explanation in the tex would be helpful. If i am guessing wrong then i even understand
less.

   859	
   860	   The format of the SIO is as follows:
   861	
   862	        0                   1                   2                   3
   863	        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   864	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   865	       |   Type        | Option Length |Comp.|B|D|Flags|    Opaque     |
   866	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   867	       |            Step of Rank       |          Reserved             |
   868	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   869	       |                                                               |
   870	       +                                                               +
   871	       .                                                               .
   872	       .       Sibling DODAGID (if the D flag not set)               .
   873	       .                                                               .
   874	       +                                                               +
   875	       |                                                               |
   876	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   877	       |                                                               |
   878	       +                                                               +
   879	       .                                                               .
   880	       .                     Sibling Address                           .
   881	       .                                                               .
   882	       +                                                               +
   883	       |                                                               |
   884	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   885	
   886	                Figure 8: Sibling Information Option Format
   887	
   888	   Option Type:  0x0D (to be confirmed by IANA)

You're maxing out your repeat offender penalty of illegal IANA code point misappropriation ;-)
   
   890	   Option Length:  In bytes, the size of the option.
   891	
   892	   Compression Type:  3-bit unsigned integer.  This is the SRH-6LoRH
   901	      Type as defined in figure 7 in section 5.1 of [RFC8138] that
   902	      corresponds to the compression used for the Sibling Address and
   903	      its DODAGID if  resent.  The Compression reference is the Root of
                             ^ p ?
   904	      the main DODAG.
   905	
   906	   Reserved for Flags:  MUST be set to zero by the sender and MUST be
   907	      ignored by the receiver.
   908	
   909	   B:  1-bit flag that is set to indicate that the connectivity to the
   910	      sibling is bidirectional and roughly symmetrical.  In that case,
   911	      only one of the siblings may report the SIO for the hop.  If 'B'

How would they do that (decide which one reports the SIO ?).

   911	      only one of the siblings may report the SIO for the hop.  If 'B'
   912	      is not set then the SIO only indicates connectivity from the
   913	      sibling to this node, and does not provide information on the hop
   914	      from this node to the sibling.

I hope there is a simple way to do 'B' or more of a benefit than just cutting
down reporting data by 50%. Any standardized mechanism ?

   916	   D:  1-bit flag that is set to indicate that sibling belongs to the
   917	      same DODAG.  When not set, the Sibling DODAGID is indicated.
   918	
   919	   Flags:  Reserved.  The Flags field MUST initialized to zero by the
                                                  ^ be
   920	      sender and MUST be ignored by the receiver
   921	
   922	   Opaque:  MAY be used to carry information that the node and the Root
   923	      understand, e.g., a particular representation of the Link
   924	      properties such as a proprietary Link Quality Information for
   925	      packets received from the sibling.  An industrial Alliance that
   926	      uses RPL for a particular use / environment MAY redefine the use
   927	      of this field to fit its needs.

Is there a prior RPL example of such a field ? Pointer to that wold be
useful. I hav a hard time seeing how this would not result in all type of
misinterpretation unless the industrial alliance whose registration space
is to be used for Upaque is unambigously derivable from the device (type)
or link (type).

I would prefer to add MUST be set to 0 and be ignored upon receiving and
go on saying, IETF specification MUST NOT use or define this field, but
non-IETF specification may use it. Aka: why not give such external specs
the same starting ground (0-filled) that we give our own extension points.

But again: pre-existing examples of BCP spec text for such an Opaque field would
be helpful.

   929	   Step of Rank:  16-bit unsigned integer.  This is the Step of Rank
   930	      [RPL] as computed by the Objective Function between this node and
   931	      the sibling.
   932	
   933	   Reserved:  The Reserved field MUST initialized to zero by the sender
   934	      and MUST be ignored by the receiver
   935	
   936	   Sibling DODAGID:  2 to 16 bytes, the DODAGID of the sibling in a
   937	      [RFC8138] compressed form as indicated by the Compression Type
   938	      field.  This field is present if and only if the D flag is not
   939	      set.
   940	
   941	   Sibling Address:  2 to 16 bytes, an IPv6 Address of the sibling, with
   942	      a scope that MUST be make it reachable from the Root, e.g., it
   943	      cannot be a Link Local Address.  The IPv6 address is encoded in
   944	      the [RFC8138] compressed form indicated by the Compression Type
   945	      field.
   956	
   957	   An SIO MAY be immediately followed by a DAG Metric Container.  In
            ^ "A for consonant start of TLA"
   958	   that case the DAG Metric Container provides additional metrics for
   959	   the hop from the Sibling to this node.
   960	
   961	7.  Projected DAO

Given how this section seems to describe what the title of the doc is,
maybe it should also be named that way "Root initiated routing state".

   962	
   963	   This draft adds a capability to RPL whereby the Root of a main DODAG

Define what a "main DODAG" is. I guess its a DODAG not created by the
mechanisms of this draft, but also: what are non-main DODAGs ? Or is the
opposite just the projected DAO ?

   964	   installs a Track as a collection of Projected Routes, using a
   965	   Projected-DAO (P-DAO) message to maintain each individual route.  The

What is an individual route ? 

   966	   P-DAO signals a collection of Targets in the RPL Target Option(s)
   967	   (RTO).  Those Targets can be reached via a sequence of routers
   968	   indicated in a VIO.  A P-DAO message MUST contain exactly one VIO,
   969	   which is either a SF-VIO or an SR-VIO, and MUST follow one or more
   970	   RTOs.  There can be at most one such sequence of RTO(s) and an Via
   971	   Information Option.  A track is identified by a tuple DODAGID,
                             ^ in a P-DAO

Also, is "at most" correct ?
How about there MUST be exactly one sequece of one or more RTO followed vy one VIO ? 
Or is it valid to have no RTO, or no VIO ?

   972	   TrackID and each route within a Track is indexed by a SegmentID.

So, IMHO, this whole section 7 needs to come before section 3, because it is
here where you start defining the functionality from higher layer, but then
section 3 goes into the encoding details. I observe that all RFCs i remember
have the order of starting wih the overall functionality and bring the encoding
details of messages later (but then i am forgetfull of what i have read and
also say this because as my comments before will show, i struggled  to make
head & tails out of how the pieces fit together).

   973	
   974	   A P-DAO MUST be sent from the address of the Root that serves as
   975	   DODAGID for the main DODAG.  It MUST be sent to a GUA or a ULA of

Expand GUA, ULA, provide reference for ULA, and/or add to initial list of terms in doc.

   976	   either the ingress or the egress of the Segment, more below.  If the
   977	   'K' Flag is present in the P-DAO, and unless the P-DAO does not reach
   978	   it, the ingress of the Segment is the node that acknowledges the
   979	   message, using a DAO-ACK that MUST be sent back to the address that
   980	   serves as DODAGID for the main DODAG.

Sentence too convoluted. Try to make two out of it.

You are not using the same term here as in 974, so this makes one wonder if
the DAO-ACK is to be sent back to the same address it was sent from or not.
If it is meant to be sent back to the same address, why not say "sent back to
the address of the root, which the P-DAO was sent from". 

   982	   Like a classical DAO message, a P-DAO causes a change of state only
   983	   if it is "new" per section 9.2.2.  "Generation of DAO Messages" of
   984	   the RPL specification [RPL]; this is determined using the Segment
   985	   Sequence information from the VIO as opposed to the Path Sequence
                                            ^ in the P-DAO
   986	   from a TIO.  Also, a Segment Lifetime of 0 in a VIO indicates that
                     ^ in the DAO.
   987	   the projected route associated to the Segment is to be removed.
   988	
   989	   There are two kinds of operation for the Projected Routes, the
   990	   Storing Mode and the Non-Storing Mode.
   991	
   992	   *  The Non-Storing Mode is discussed in Section 7.3.2.  A Non-Storing
   993	      Mode P-DAO carries an SR-VIO with the loose list of Via Addresses
                                                         ^ steering
   994	      that forms a source-routed Segment to the Track Egress.  The
   995	      recipient of the P-DAO is the Track Ingress; it MUST install a
   996	      source-routed state to the Track Egress and reply to the Root
   997	      directly using a DAO-ACK message if requested to.
   998	
   999	   *  The Storing Mode is discussed in Section 7.3.1.  A Storing Mode
  1000	      P-DAO carries a  SF-VIO with the strict  list of Via Addresses from
                             ^n                      ^ steering
  1001	      the ingress to the egress of the Segment in the data path order.
  1002	      The routers listed in the Via Addresses, except the egress, MUST
  1003	      install a routing state to the Target(s) via the next Via Address
  1004	      in the SF-VIO.  In normal operations, the P-DAO is propagated
  1013	      along the chain of Via Routers from the egress router of the path
  1014	      till the ingress one, which confirms the installation to the Root
  1015	      with a DAO-ACK message.

In 976 you point to further below as to where the P-DAO is to be sent. But hen
in the bullet points 992 and 999 you do not explicitly say tha the SR-VIO is sent
to the track ingres and that the SF-VIO is sent to the track egres. Please
add such sentences accordingly.

I think the description of ACK processing from 976++ fits better here after, given
how its an additional detail happening after the P-DAO is processed according
to the two bullet points above.

Q: If in the SF-VIO case, the egress does not install any state, then why send
the P-DAO to it instead of to the pre-ultimate hop ? Explanation might be helpful
in the text.

  1016	
  1017	   In case of a forwarding error along a Projected Route, an ICMP error

Arre we talking about the forwaring of data packets that are following a projected route,
or processing error of the P-DAO ? Please be specific. An example of a forwarding
error would help.

I suspect it is the data packets. Is there also any other error for processing of
the P-DAO other than missing ACK ? Aka: wha exactly happens in the duplicate address
in VIO If lets say the root was too stsupid to figure it out ?

  1018	   is sent to the Root with a new Code "Error in Projected Route" (See
  1019	   Section 11.13).  The Root can then modify or remove the Projected
  1020	   Route.  The "Error in Projected Route" message has the same format as
  1021	   the "Destination Unreachable Message", as specified in RFC 4443
  1022	   [RFC4443].
  1023	
  1024	   The portion of the invoking packet that is sent back in the ICMP
  1025	   message SHOULD record at least up to the RH if one is present, and
  1026	   this hop of the RH SHOULD be consumed by this node so that the
           ^^^^                                     ^^^^
which hop ? The hop that has problems and wants to generate the ICMP error?

  1027	   destination in the IPv6 header is the next hop that this node could
  1028	   not reach.  if a 6LoWPAN Routing Header (6LoRH) [RFC8138] is used to

So ultimately, you want the root to be able to figure out from the ICMP,
which nodeA can not reach a next-hop nodeB, right ? WOuld be good to say that,
but the description of how to achieve this by messing with the ICMP error
reported original packet stub still escapes me. Is that "consumed by" procedure
already done some place else ? If so, hen a reference to prior way how this is
done would be good. If not, then elaborating a bit more to make it easier to
understand would help.

  1028	   not reach.  if a 6LoWPAN Routing Header (6LoRH) [RFC8138] is used to
  1029	   carry the IPv6 routing information in the outer header then that
  1030	   whole 6LoRH information SHOULD be present in the ICMP message.

How would a root then figure out nodeA/nodeB ?

  1031	
  1032	   The sender and exact operation depend on the Mode and is described in
  1033	   Section 7.3.2 and Section 7.3.1 respectively.
  1034	
  1035	7.1.  Requesting a Track
  1036	
  1037	   A Node is free to ask the Root for a new Track for which it will be
  1038	   Ingress at any time.  This is done with a PDR message, that indicates

for which it wants to be ingres ? E.g.: no idea what "will be at any time" means.

  1039	   the desired TrackID and the duration for which the Track should be
  1040	   established.  Upon a PDR, the Root MAY install the necessary

An example of why the node would generate it, and where it has the TrackID from
would help here.

  1041	   Segments, in which case it answers with a PDR-ACK indicating the
  1042	   granted Track Lifetime.  All the Segments MUST be of a same mode,
  1043	   either Storing or Non-Storing.  All the Segments MUST be created with
  1044	   the same TrackID and the same DODAGID signaled in the P-DAO.
  1045	
  1046	   The Root is free to design the Track as it wishes, and to change the
  1047	   Segments overtime to serve the Track as needed, without notifying the
  1048	   resquesting Node.  The Segment Lifetime in the P-DAO messages does
             ^
Presumably, a requesting node would likely also be the ingres of one P-DAO of
the track, right ? But establishment of the track via P-DAO is only related to
the PDR/PDR-ACK in the root ?

Might be useful to have some place a higher level description of "initiation" models,
and point to it. Aka: the way i figure, initiation can come from PCE and go through root,
no other nodes involved. Or it comes somehow via PDR initiaor... but how/why.

Also "free to " is a bit of a misnomer, right ? Aka: If the root is free, then it
should also be able to notify the requesting node, but there really is no other
notification than acknowledging in PDR-ACK acceptance to take care of the request
or to indicate failure of it. Aka, write maybe: "The root designs the Track as it wishes....
there are no notifications to the requesting node when changing the track".

  1049	   not need to be aligned to the Requested Lifetime in the PDR, or
  1050	   between P-DAO messages for different Segments.  The Root may use
  1051	   shorter lifetimes for the Segments and renew them faster than the
  1052	   Track is, or longer lifetimes in which case it will need to tear down
  1053	   the Segments if the Track is not renewed.
  1054	
  1055	   When the Track Lifetime that was returned in the PDR-ACK is close to
  1056	   elapse, the resquesting Node needs to resend a PDR using the TrackID
  1057	   in the PDR-ACK to extend the lifetime of the Track, else the Track
  1058	   will time out and the Root will tear down the whole structure.

How close ? Any guidance ?
  
  1068	
  1069	   If the Track fails and cannot be restored, the Root notifies the
  1070	   resquesting Node asynchronously with a PDR-ACK with a Track Lifetime
             ^
  1071	   of 0, indicating that the Track has failed, and a PDR-ACK Status
  1072	   indicating the reason of the fault.
  1073	
  1074	7.2.  Identifying a Track
  1075	
  1076	   RPL defines the concept of an Instance to signal an individual
  1077	   routing topology but does not have a concept of an administrative
  1078	   distance, which exists in certain proprietary implementations to sort
  1079	   out conflicts between multiple sources of routing information within
  1080	   one routing topology.
  1081	
  1082	   This draft leverages the RPL Instance model as follows:

... to sort out conflicts between multiple sources of routing information ??
aka: tie the text together, the way it is written it is confusing.

It also seems as if it would be better to high level answer how P-DAO avoids
the need for administrative distances here, instead of letting readers try to figure it
out from all the details of the following bullet points, because those bullet points
explain a lot more, so the whole administative distance stuff will get lost.

The way i see it is that P-DAO do not require administrative distance because

a) They will be preferred because of prefixlength vs. default route to root when
   used within pre-existing RPLinstance.
b) They can be explicitly indicated through their own RPLinstance called TrackID
   in the RPL packet header, therefore not colliding with routes from pre-existing
   RPLinstances.

  1083	
  1084	   *  The Root MAY use P-DAO messages to add better routes in the main
  1085	      (Global) Instance in conformance with the routing objectives in
  1086	      that Instance.  To achieve this, the Root MAY install an Storing-

What actually happens if those P-DAO routes are not in conformance with the routing
objectives of that instance ? Anything worse than that the routing objective does
not well express what the routes are doing ?

I am asking, because i would assume that the routing objectives likely will never
be able to express all the characteristics that may come out of a bunch of Tracks.
Therefore i fear that this conformance sentence is somewhat career limiting to
P-DAOs.

But i am not sure about the overall framework. Is there some form of policy framework,
whereby traffic may choose one out of multiple instances, and what you really want
to say is that Tracks should be assigned to the track that best matches what the
Track attempts to improve upon so that traffic choosing one out of multiple
insances can continue to do so, and track will improve the desired outcome ?

Aka: Motivating this setnence, maybe in the way i am imagining it (if correct) might
help. And it might also better capture the goal of choosing a particular instance
for a track than referring to the formal routing objectives instead of maybe
the informal intent of an instance, which may be constituted from the routing
objectives of DAOs and the traffic engineered objectives of P-DAOs. 

  1086	      that Instance.  To achieve this, the Root MAY install an Storing-
                                                                     ^ just a - storing is spoken with consonant first.
  1087	      Mode P-Route along a path down the main Non-Storing Mode DODAG.
  1088	      This enables a loose source routing and reduces the size of the
  1089	      Routing Header, see Appendix A.1.
  1090	
  1091	      When adding an Storing-Mode P-Route to the main RPL Instance, the
                           ^ just a
  1092	      Root MUST set the RPLInstanceID field of the P-DAO message (see
  1093	      section 6.4.1. of [RPL]) to the RPLInstanceID of the main DODAG,
  1094	      and MUST NOT use the DODAGID field.  A Projected Route provides a

Whats the significance of the DODAGID here ? What would happen if it was set ?

  1095	      longer match to the Target Address than the default route via the
  1096	      Root, so it is preferred.
  1097	
  1098	      Once the Projected Route is installed, the intermediate nodes
  1099	      listed in the SF-VIO after first one (i.e.  The ingress) can be
  1100	      elided from the RH in packets sent along the Segment signaled in
  1101	      the P-DAO.  The resulting loose source routing header indicates
  1102	      (one of) the Target(s) as the next entry after the ingress.
  1103	
  1104	   *  The Root MAY also use P-DAO messages to install a specific (say,
  1105	      Traffic Engineered) path as a Serial or as a Complex Track, to a

Serial Track and Complex Track are not defined/explained yet. See comments
earlier that you need to start off with pictured examples from which to
much more easily define such terms.

  1106	      particular endpoint that is the Track Egress.  In that case, the
  1107	      Root MUST install a Local RPL Instance (see section 5 of [RPL]),
  1108	      and the Local RPLInstanceID is called TrackID.

Do i need a separate RPL instance to loosely tie together multiple sequential 
SF-VIO ?  Lets say i have 20 hops in stateless. I figure i have 3 segments of
5 hops each that ae often used. So i establish separate tracks for each of
them, and then my routing headers in the future would be able to be reduced
by 3 * 5 = 15 hops, aka: having 3 loose hops tied together by 5 strict hops.

  1109	
  1110	      In that case, the TrackID MUST be unique for the Global Unique
  1111	      IPv6 Address (GUA) or Unique-Local Address (ULA) of the Track

You where missing those expansions in before, so here they would now be redundant
when you fix them up in before.

  1112	      Ingress that serves as DODAGID for the Track.  The Track Ingress
  1113	      owns the namespace of its TrackIDs, so it can pick any unused
  1114	      value to request a new Track with a PDR.  The Root is aware of all

The root of the main DODAG, or main RPL instance or the like ? Aka: There may be
multiple roots for different instances/dodags, right ? 

  1115	      the active Tracks, so it can also pick any unused value to form
  1116	      Tracks without a PDR.  To avoid a collision of the Root and the
  1125	      Track Ingress picking the same value at the same time, it is
  1126	      RECOMMENDED that the Track Ingress starts allocating the ID value
  1127	      of the Local RPLInstanceID (see section 5.1. of [RPL]) used as
  1128	      TrackIDs with the value 0 incrementing, while the Root starts with
  1129	      63 decrementing.

  1131	      This way, a Track is uniquely identified by the tuple (DODAGID,
  1132	      TrackID) where the TrackID is always represented with the D flag
  1133	      set to 0.

Explain where the D flag is, first time i think its used in the text.

I think i may be confused about the namespace and its limitations or at least
not well educaed by the text ;-)

So the track ingres IPv6 serves as DODAGID. So every node can have up to 64 - N Tracks,
where N is the number of non-rack RPL instances for which the node is the root ?

Would be good to write this out explicitly (or accordingly corrected if wrong).

  1135	      The Track Egress Address and the TrackID MUST be signaled in the
  1136	      P-DAO message as shown in Figure 1.
  1137	
  1138	7.3.  Installing a Track
  1139	
  1140	   A Storing-Mode P-DAO contains an SF-VIO that signals the strict
  1141	   sequence of consecutive nodes to form a segment between a segment
  1142	   ingress and a segment egress (both included).  It installs a route of
  1143	   a higher precedence along the segment towards the Targets indicated
  1144	   in the Target Options.  The segment is included in a DODAG indicated

Ok, now i am getting confused again by this text.

"higher precendence - than what ? Also, is there a definition of precedence in the
context of RPL ? If so, reference to definition would be good. 

Previously you only used precedence related to priority to store/maintain
a route, which i guess is a differrent meaning of the word than here.

In 7.2, it sounded as if there would be no pre-existing route to the target
other than through the root because of prefix-length. If that is what you mean
here, and unless precedence has a well defined meaning, maybe just replace precedence
with prefix-length.

It is also not quite clear to me if tracks can never be installed into storing-mode
RPL instances where they could not conflict with equal-prefix-length "native" routes.
AFAIK, the spec only said the main RPLinstance must be non-storing mode. Can there nit
be other, storing mode RPL instances ?

But of course, i am likely confused...

  1144	   in the Target Options.  The segment is included in a DODAG indicated
  1145	   by the P-DAO Base Object, that may be the one formed by the main RPL
  1146	   Instance, or a Track associated with a local RPL Instance.  A Track
  1147	   Egress is signaled as a Target in the P-DAO, and as the last entry is
  1148	   an SF-VIO of a last segment towards that Egress.
  1149	
  1150	   A Non-Storing-Mode P-DAO signals a strict or loose sequence of nodes
                                   ^ contains an SR-VIO to...
  1151	   between the Track Ingress (excluded) and a Track Egress (included).
  1152	   It installs a source-routed path of a higher precedence within the
                                                        ^^^^^^^^^^ same consideration as above
  1153	   Track indicated by the P-DAO Base Object, towards the Targets
  1154	   indicated in the Target Options.  The source-routed path requires a
  1155	   Source-Routing header which implies an encapsulation to add the SRH
                                                                   ^^^^^^^^^^^

Same consideration as much earlier, e.g.: encapsulate into new IPv4 with SRH ?!

  1156	   to an existing packet.
  1157	
  1158	   The next entry in the sequence must be either a neighbor of the
  1159	   previous entry, or reachable as a Target via another Projected Route,
  1160	   either Storing or Non-Storing.  If it is reachable over a Storing
  1161	   Mode Projected Route, the next entry in the loose sequence is the
  1162	   Target of a previous segment and the ingress of a next segment; the
  1163	   segments are associated with the same Track, which avoids the need of
  1164	   an encapsulation.  Conversely, if it is reachable over a Non-Storing
  1165	   Mode Projected Route, the next loose source routed hop of the inner
  1166	   Track is a Target of a previous Track and the ingress of a next
  1167	   Track, which requires a de- and a re-encapsulation.

This is a game of blindfold chess. Pictured examples of the two cases described
would help a lot to understand and verify the points made/claimed here.

  1181	   A Serial Track is installed by a single Projected Routes that signals
                                                                  ^
  1182	   the sequence of consecutive nodes, either in Storing or Non-Storing
  1183	   Mode.  If can be a loose Non-Storing Mode Projected Route, in which
                   ^
  1184	   case the next loose entry must recursively be reached over a Serial
  1185	   Track.

Please check whats standard *-Storing-Mode or *-Storing Mode - and make text
consistent.

  1186	
  1187	   A Complex Track can be installed as a collection of Projected Routes
  1188	   with the same DODAGID and Track ID.  The Ingress of a Non-Storing

If this is turned around, does it become the still missing definition of a
complex track ?

Multiple projected routes can be installed into a single (DODAGID,TrackID).
This leads to Sequential or Complex Tracks ??

  1188	   with the same DODAGID and Track ID.  The Ingress of a Non-Storing
  1189	   Mode Projected Route must be the owner of the DODAGID.  The Ingress
  1190	   of a Storing Mode Projected Route must be either the owner of the
  1191	   DODAGID, or the egress of a preceding Storing Mode Projected Route in
  1192	   the same Track.  In the latter case, the Targets of the Projected
  1193	   Route must be Targets of the preceding Projected Route to ensure that
  1194	   they are visible from the track Ingress.
  1195	
  1196	7.3.1.  Storing-Mode P-Route

Please go back through the text and replace all instances of Projected Route
after the first occurance with P-Route. You use both terms randomnly interchanged,
which is confusing. Better to stick to the abbreviation only.

I also observe, that i would be much less confused about the text if this high-level
explanation was preceeding the detailed explanation earlier in the beginning of section 7.

Please think how to resort the text of section 7 so it starts with the pictures
and high-level explanation and then goes into the more formal detail spec.
  
  1198	   Profile 1 extends RPL operation in a Non-Storing Mode network with

Without further explanation, the first unexplained use of Profile is derailing and
confusing. Suggest to just delete the mentioning of profiles and just define them
in Section 8. 

  1199	   Storing-Mode Projected Routes that install segments along the main
  1200	   DODAG and enable to loose source routing between the Root and the
  1201	   targets.
  1202	
  1203	7.3.1.1.  Installing a Storing-Mode P-Route
  1204	
  1205	   As illustrated in Figure 9, a P-DAO that carries a SF-VIO enables the
  1206	   Root to install a stateful route towards a collection of Targets
  1207	   along a Segment between a Track Ingress and a Track Egress using a
  1208	   projected DAO Message.
  1209	
  1210	           ------+---------
  1211	                 |          Internet
  1212	                 |
  1213	              +-----+
  1214	              |     | Border Router
  1215	              |     |  (RPL Root)
  1216	              +-----+                      |     ^                   |
  1217	                 |                         | DAO | ACK               |
  1218	           o    o   o    o                 |     |                   |
  1219	       o o   o  o   o  o  o o   o          |  ^       | Projected    .
  1220	      o  o o  o o    o\  o   o  o  o       |  | DAO   | Route        .
  1221	      o   o    o  o    \o--o    o  o  o    | ^        |              .
  1222	     o  o   o  o   o        \o   o o       v | DAO    v              .
  1223	     o          o   LLN   T1   T2     o                                |
  1224	         o o   o        o     o              Loose Source Route Path |
  1225	      o       o      o    o                 From Root To Destination v
  1226	
  1227	                        Figure 9: Projecting a route

Do you think you can visualise an example P-route into the picture ? 
I started a bit of bit of it above..

  1228	
  1237	   In order to install the relevant routing state along the Segment ,
  1238	   the Root sends a unicast P-DAO message to the Track Egress router of
  1239	   the routing Segment that is being installed.  The P-DAO message
  1240	   contains a SF-VIO with the direct sequence of Via Addresses.  The SF-
                                      ^^^^^^ strict

  1241	   VIO follows one or more RTOs indicating the Targets to which the
  1242	   Track leads.  The SF-VIO contains a Segment Lifetime for which the

In this explanation it would be helpful to explain conditions for targets, e.g.:
Target must either be direc neighbor of the P-Route egres, or be Target of some 
P-Route2 with the P-Route egres as its ingres. Right ?

  1243	   state is to be maintained.
  1244	
  1245	   The Root sends the P-DAO directly to the egress node of the Segment.
  1246	   In that P-DAO, the destination IP address matches the last Via
  1247	   Address in the SF-VIO.  This is how the egress recognizes its role.
  1248	   In a similar fashion, the ingress node recognizes its role as it
  1249	   matches first Via Address in the SF-VIO.
  1250	
  1251	   The Egress node of the Segment is the only node in the path that does
  1252	   not install a route in response to the P-DAO; it is expected to be
  1253	   already able to route to the Target(s) on its own.  If one of the
  1254	   Targets is not known, the node MUST answer to the Root with a
  1255	   negative DAO-ACK listing the Target(s) that could not be located
  1256	   (suggested status 10 to be confirmed by IANA).

So complex/sequential Tracks need to be established from destination to source.
What happens with a track when th egress looses routing information for a destination ?
(if thats answere elsehwhere, a pointer to that section would be helpfull here).
  
  1258	   If the egress node can reach all the Targets, then it forwards the
  1259	   P-DAO with unchanged content to its loose predecessor in the Segment

Shouldn't that be strict instead of loose ? If it was loose, how would that loose
predecessor know how to send the data packets to the successor without adding
another encap/RH if the underlying main RPL instance was NSM ?

  1260	   as indicated in the list of Via Information options, and recursively
  1261	   the message is propagated unchanged along the sequence of routers
  1262	   indicated in the P-DAO, but in the reverse order, from egress to
  1263	   ingress.
  1264	
  1265	   The address of the predecessor to be used as destination of the
  1266	   propagated DAO message is found in the Via Address the precedes the
  1267	   one that contain the address of the propagating node, which is used
  1268	   as source of the message.
  1269	
  1270	   Upon receiving a propagated DAO, all except the Egress Router MUST
  1271	   install a route towards the DAO Target(s) via their successor in the
  1272	   SF-VIO.  The router MAY install additional routes towards the VIA
  1273	   Addresses that are the SF-VIO after the next one, if any, but in case
  1274	   of a conflict or a lack of resource, the route(s) to the Target(s)
  1275	   have precedence.
  1276	
  1277	   If a router cannot reach its predecessor in the SF-VIO, the router
  1278	   MUST answer to the Root with a negative DAO-ACK indicating the
  1279	   successor that is unreachable (suggested status 11 to be confirmed by
  1280	   IANA).
  1281	
  1282	   The process continues till the P-DAO is propagated to ingress router
                                 ^until
  1283	   of the Segment, which answers with a DAO-ACK to the Root.  The Root
  1284	   always expects a DAO-ACK, either from the Track Ingress with a
  1293	   positive status or from any node along the segment with a negative
  1294	   status.  If the DAO-ACK is not received, the Root may retry the DAO
  1295	   with the same TID, or tear down the route.
  1296	
  1297	7.3.1.2.  Maintaining and Tearing Down a Storing-Mode P-Route
  1298	
  1299	   A Segment Lifetime of 0 in a VIO is used to clean up the state.  The
                                                                    ^
                                                                    P-route state
  1300	   P-DAO is forwarded as described above, but the DAO is interpreted as
  1301	   a No-Path DAO and results in cleaning up existing state as opposed to
  1302	   refreshing an existing one or installing a new one.
  1303	
  1304	   Note that the continuity of the segment may be broken; this happens
  1305	   if the bidirectional connectivity between contiguous hops of the
  1306	   segment is lost.  In that case the Root needs to send the projected
  1307	   DAO to one or more intermediate node(s) as opposed to the egress
  1308	   node, indicating a portion of segment that is being replaced or
  1309	   cleaned up.  At the extreme, the P-DAO updates only one node, in
  1310	   which case it contains only one VIO.

Hmm... how does this work given how the egres is meant to not install route state,
so if you want to fix up some intermediate segments, then the egres of that
fixup VIO, which is not the final egres of the full VIO  would from the prior
explanation have to invoke its function of checking the targets reachability,
but not to establish storing mode state. Some more explanation here might be
helpful. I think his can work, but i think the egres of a fixup VIO needs to
be careful and behave differently to a non-fixup actual track egres.

  1311	
  1312	   In case of a forwarding error along an Storing-Mode P-Route, the node
  1313	   that fails to forward SHOULD send an ICMP error with a code "Error in
  1314	   Projected Route" to the Root.  Failure to do so may result in packet
  1315	   loss and wasted resources along the Projected Route that is broken.
  1316	
  1317	7.3.2.  Non-Storing-Mode P-Route
  1318	
  1319	   As illustrated in Figure 10, a P-DAO that carries an SR-VIO enables
  1320	   the Root to install a source-routed path from a Track Ingress towards
  1321	   a Target along the main DODAG.
  1349	
  1349	              ------+---------
  1350	                    |          Internet
  1351	                    |
  1352	                 +-----+
  1353	                 |     | Border Router
  1354	                 |     |  (RPL Root)
  1355	                 +-----+                    |  P  ^ ACK
  1356	                    |        Track          | DAO |
  1357	              o    o   o  o  Ingress X      V     |   X
  1358	          o o   o  o   o  o     o   X   o             X Source
  1359	         o  o o  o o    o   o  o    X  o  o           X Routed
  1360	         o   o    °  o     o   o   o X     o          X Segment
  1361	        o  o   o  o   o  o    o  o     X Track        X
  1362	           o  o  o  o             o     Egress
  1363	
  1364	          o       o               o    o
  1365	        o          o             o     o
  1366	                                      destination
  1367	
  1368	                          LLN
  1369	
  1370	                 Figure 10: Projecting a Non-Storing Route

So there is some attempt here to visualize the P-Route, but it mentions destination
and not target, so i am again confused about the difference of those terms...
Would be good to show Target(s) in the picture.
  
  1372	   When forwarding a packet to a destination for which the router

which router ? The Track ingres ?

  1373	   determines that routing happens via a Track Target, the router

"via a track target" sounds as if destination is different from trac target.
What is the routing information from which that router can determine that
a destination is reachable via a target ? The P-Route only signals targets, right ?

  1374	   inserts the Source Routing Header in the packet with the final
  1375	   destination at the Track Egress.

encapsulates the packet with a new IPv6/SRH header ?

Now it sounds as if final destination is the same as track egres, so not even target...
even more confused now.
  1376	
  1377	   In order to signal the Segment, the router encapsulates the packet
  1378	   with an IP-in-IP header and a Routing Header as follows:

It seems as if we're not discussing installation of non-storing P-Routes at all,
but immediately skip to data-plane for non-storing P-Routes ?

I would suggest to have even if a very short section for installation of the non-storing
P-Route in one subsection and then aother subsection for the data-plane.

The storing mode text above does not seem to have a dedicated data-plane subsecton too,
so quite inconsistent...

  1379	
  1380	   *  In the uncompressed form the source of the packet is this router,

this router...

  1381	      the destination is the first Via Address in the SR-VIO, and the RH
  1382	      is a Source Routing Header (SRH) [RFC6554] that contains the list
  1383	      of the remaining Via Addresses terminating by the Track Egress.
  1384	
  1385	   *  The preferred alternate in a network where 6LoWPAN Header
  1386	      Compression [RFC6282] is used is to leverage "IPv6 over Low-Power
  1387	      Wireless Personal Area Network (6LoWPAN) Paging Dispatch"
  1388	      [RFC8025] to compress the RPL artifacts as indicated in [RFC8138].
  1389	
  1390	      In that case, the source routed header is the exact copy of the
  1391	      (chain of) SRH-6LoRH found in the SR-VIO, also terminating by the
  1392	      Track Egress.  The RPI-6LoRH is appended next, followed by an IP-
  1393	      in-IP 6LoRH Header that indicates the Ingress Router in the
  1394	      Encapsulator Address field, see as a similar case Figure 20 of
  1395	      [TURN-ON_RFC8138].

I will trust this is correct, as i can not verify this quickly due to my lack of
this encap details.

  1404	
  1405	   In the case of a loose source-routed path, there MUST be either a
  1406	   segment for the same Track to the loose next hop, on which case the
  1407	   packet is forwarded to the next hop along that segment, a common
  1408	   neighbor with the loose next hop, on which case the packet is
  1409	   forwarded to that neighbor, or another Track to the loose next hop
  1410	   for which this node or a neighbor is Ingress.  In the latter case,
  1411	   another encapsulation takes place and the process possibly recurses;
  1412	   otherwise the packet is dropped.

I can not comment on this because i am still lost as to the semantic of segment given
he absence of any illustrative pictures for multi-segment Tracks so far in the document.
  
  1414	   In case of a forwarding error along a Source Route path, the node
  1415	   that fails to forward SHOULD send an ICMP error with a code "Error in
  1416	   Source Routing Header" back to the source of the packet, as described
  1417	   in section 11.2.2.3. of [RPL].  Upon this message, the encapsulating
  1418	   node SHOULD stop using the source route path for a period of time and

How long should that period be. Elaborate for how the encapsulating node
should determine the period.

  1419	   it SHOULD send an ICMP message with a Code "Error in Projected Route"
  1420	   to the Root.  Failure to follow these steps may result in packet loss
  1421	   and wasted resources along the source route path that is broken.
  1422	
  1423	7.4.  Forwarding Along a Track

In 7.3.2 you already detail parts of this. Again, i would strongly suggest
to revert order, with this section first, before getting into the currently
earlier stated details.

  1425	   This draft leverages the RPL Forwarding model follows:
  1426	
  1427	   *  In the data packets, the Track DODAGID and the TrackID MUST be
  1428	      respectively signaled as the IPv6 Source Address and the
  1429	      RPLInstanceID field of the RPI that MUST be placed in the outer
  1430	      chain of IPv6 Headers.

I think an outer chain(mail) can be found as an armor on medieval knights, but in our
case i think it is the outer header of the packets chain of IPv6 headers.

  1432	      The RPI carries a local RPLInstanceID called the TrackID, which,
  1433	      in association with the DODAGID, indicates the Track along which
  1434	      the packet is forwarded.
  1435	
  1436	      The D flag in the RPLInstanceID MUST be set to 0 to indicate that
  1437	      the source address in the IPv6 header is set ot the DODAGID, more
                                                           ^^
  1438	      in Section 7.4.

This is section 7.4.

  1439	
  1440	   *  This draft conforms the principles of [USEofRPLinfo] with regards
                                 ^ to
  1441	      to packet forwarding and encapsulation along a Track.
  1442	
  1443	      -  In that case, the Track is the DODAG, the Track Ingress is the

In the case where the Track is the main DODAG ... ?

  1444	         Root, and the Track Egress is a RAL, and neighbors of the Track

Is there any reason why to say RAL instead of node ? First time you use RAL, so wondering.

  1445	         Egress that can be reached via the Track are RULs.  The
  1446	         encapsulation rules in [USEofRPLinfo] apply.

Not sure what RFC editor says, but given how RAL/RUL are first mentioned here,
even though they are listed in glossary, expanding them here can not hurt.

I think you may want to find a place early in he document where you want to say
that "node" without qualification in this doc mean RAN, maybe also add to glossary.

It would be helpfull to clariy what i think this section wants to say without hoping that
readers can / want to deduce it from [UseofRPLinfo]. How about the following table:

        Node role                   Supported node type
        Track ingres                RAN
        Track midpoint              RAN
        Track egres                 RAN, RAL
        Neighbor of track egres     RAN, RAL, RUL

(hope this is roughly ok, else fix up).

  1448	      -  If the Track Ingress is the originator of the packet and the
  1449	         Track Egress is the destination of the packet, there is no need
  1450	         for an encapsulation.
  1451	
  1459	
  1460	
  1461	      -  So the Track Ingress must encapsulate the traffic that it did
  1462	         not originate, and add an RPI in any fashion.
  1463	
  1464	      A packet that is being routed over the RPL Instance associated to
  1465	      a first Non-Storing Mode Track MAY be placed (encapsulated) in a
  1466	      second Track to cover one loose hop of the first Track.  On the

I can not follow this explanation without an example picture. When reading it,
the first thing that comes to mind is that it sounds as if i could have sequential
second Tracks in different RPL Instances, but it is unclear whether this is 
is a predondition of this case of whether its irrelevant.

  1466	      second Track to cover one loose hop of the first Track.  On the
  1467	      other hand, a Storing Mode Track must be strict and a packet that
  1468	      it placed in a Storing Mode Track MUST follow that Track till the

:%s/\<till\>/until/g
Don't speak emacs.

  1469	      Track Egress.
  1470	
  1471	      When a Track Egress extracts a packet from a Track (decapsulates
  1472	      the packet), the Destination of the inner packet MUST be either
  1473	      this node or a direct neighbor, or a Target of another Segment of
  1474	      the same Track for which this node is ingress, otherwise the
  1475	      packet MUST be dropped.

.... and (see reference) ICMP must be raied according to... etc. pp ?!

This last paragraph should really be as early in the document as possible.

  1476	
  1477	   All properties of a Track operations are inherited form the main RPL
  1478	   Instance that is used to install the Track.  For instance, the use of
  1479	   compression per [RFC8138] is determined by whether it is used in the
  1480	   main instance, e.g., by setting the "T" flag [TURN-ON_RFC8138] in the
  1481	   RPL configuration option.

Can there be multiple main instances ? If so, that should be mentioned and
maybe an example given.

  1482	
  1483	8.  Profiles
  1484	
  1485	   This document provides a set of tools that may or may not be needed
  1486	   by an implementation depending on the type of application it serves.
  1487	   This sections described profiles that can be implemented separately
  1488	   and can be used to discriminate what an implementation can and cannot
  1489	   do.
  1490	
  1491	   Profile 0  Profile 0 is the legacy support of [RPL] Non-Storing Mode.
  1492	      It provides the minimal common functionality that must be
  1493	      implemented as a prerequisite to all the Track-supporting
  1494	      profiles.  The other Profiles extend Profile 0 with selected
  1495	      capabilities that this specification introduces on top.

Is this profile a term estblished outside this document already, then please
do provide reference. If it is only introuced in this document, then what
exactly needs to be implemented for it ?

Let me guss: This is a new definition in this document, and it refers to nodes
that do not implement anything from this draft, but only RPL NSM acccording to
(fill in, best with section), and to deploy any of this documents technology,
ALL RAL in the network MUST implement Profile 0 or better. Or maybe not...
Maybe only RAL that are used to pass P-Route traffic MUST be Profile 0 or better ?!

If i am guessing right than my prior paragraphs text might be a better starting
point with less gussing.

  1496	
  1497	   Profile 1 (Storing-Mode P-Route Segments along the main DODAG)  Profi
  1498	      le 1 does not create new paths; it combines Storing and Non-
  1499	      Storing Modes to balance the size of the routing header in the
  1500	      packet and the amount of state in the intermediate routers in a
  1501	      Non-Storing Mode RPL DODAG.

You should be able to state exactly what part of this spec a node MUST/SHOULD
implement to be in compliance with Profile 1. Same is true for the other profiles.
Might be difficult to structure the documents into subsections such that
you can list those subsections that are required (incrementally) for each Profile,
but otherwise its really hard to figure out if or if not an implementation is
compliant with a profile.
  
  1503	   Profile 2 (Non-Storing-Mode P-Route Segments along the main DODAG)  P
  1504	      rofile 2 extends Profile 0 with Strict Source-Routing Non-Storing-

Can you try to persuade tools to not split words (P rofile) ?

  1505	      Mode Projected Routes along the main DODAG.  Profile 2 provides
  1506	      the same capability to compress the SRH in packets down the main
  1507	      DODAG as Profile 1, but it require an encapsulation, in order to
  1508	      insert an additional SRH between the loose source routing hops.
  1509	
  1517	   Profile 3  Profile 3 and above build Tracks that do not necessarily
  1518	      follow the main DODAG.  In order to form the best path possible,
                                                                             ^ ?
DODAG ? "best possible" is unexplained. Might be good to give (maybe textual is
sufficient) the most simple example of how an additional DODAG/TrackID would
be limited if it can not support Sibling Information Option. This might be
obvious to RPL experts of course..

  1519	      those Profiles require the support of Sibling Information Option
  1520	      to inform the Root of additional possible hops.  Profile 3 extends
  1521	      Profile 1 with additional Storing-Mode Projected Routes that
  1522	      install segments that do not follow the main DODAG.  If the
  1523	      Segment Ingress (in the SF-VIO) is the same as the IPv6 Address of
  1524	      the Track Ingress (in the projected DAO base Object), the P-DAO
  1525	      creates an implicit Track between the Segment Ingress and the
  1526	      Segment Egress.
  1527	
  1528	   Profile 4  Profile 4 extends Profile 2 with Strict Source-Routing
  1529	      Non-Storing-Mode Projected Routes to form Tracks inside the main
  1530	      DODAG.  A Track is formed as one or more strict source source
  1531	      routed paths between the Root that is the Track Ingress, and the
  1532	      Track Egress that is the last node

Why is this Profile 4 when Profile 3 says that all further profiles
do not necessarily follow the main DODAG ? Aka: What would not work if
you where to make 4 become eg.: 2.5 ?
  
  1534	   Profile 5  Profile 5 Combines Profile 4 with Profile 1 and enables to
  1535	      loose source routing between the Ingress and the Egress of the
  1536	      Track.  As in Profile 1, Storing-Mode Projected Routes connect the
  1537	      dots in the loose source route.
  1538	
  1539	   Profile 6  Profile 6 Combines Profile 4 with Profile 2 and also
  1540	      enables to loose source routing between the Ingress and the Egress
  1541	      of the Track.

How about a table where rows are features, columns profiles and intersections
checkmarks ? Right now i am lost in the details.

  1542	
  1543	9.  Example Track Signaling
  1544	
  1545	   The remainder of the section provides an example of how a Track can
  1546	   be signaled
  1547	
  1548	                                                  ===> F
  1549	                   A ===> B ===> C ===> D===> E <
  1550	                                                  ===> G
  1551	
  1552	
  1553	                         Figure 11: Reference Track
  1554	
  1555	   A is Track ingress, E is track Egress.  C is stitching point.  F and

First time "stitching point" is used. Can you avoid a new term here ? Else explain.

  1556	   G are E's neighbors, "external" to the Track, and reachable from A
  1557	   over the Track A->E.

I guess this is a two-segment Track with one segment A-...>C and one segment C-...>E.

What is the "<" after E good for ?

Why use the same symbol ===> for track and for getting from E to F, G ?
Are F and G  Targets and/or destinations ? Please introduce those terms into the example.

How about indicating both the physical connectivity with "---" and the track with "===>"

Also show / disinguish the two segments accordingly through better ASCII graphics.

  1558	
  1559	   In a general manner we want:
  1560	
  1561	   *  P-DAO 1 signals C==>B==>E

I hope B should be D, else i am heck more confused.

Please say what this signaling establishes. We learned in before that a P-DAO
has not only a VIO, but also some targets. So what are the targets of this P-DAO ?

  1562	
  1563	   *  P-DAO 2 signals A==>B==>C

Likewise

  1573	   *  P-DAO 3 signals F and G via the A==>E Track

What does hthis mean ? Whats the entry, whats the exit ? whats the VIO, whats the
target of P-DAO 3 ?

  1575	   P-DAO 3 being loose, it can only be non-storing.  Note that since the
  1576	   Root is always the ingress of a Track, and all SR-VIOs are now Track,
           ^^^^^^^^^^^^^^^^^^^^^^^^^^                 ^^^^^^^^^^^^^^^^^^^^^^^^^

Which root ? the root of the main DODA ? 
I don't parse the second ^^^^ either.

  1577	   the Root being signaled in the DAO base object can now be elided in
  1578	   the VIA list in SR-VIO.  This enables the construction by the main
  1579	   root of the RFC 8138 optimized SRH-6LoRH in the SR-VIO, to be placed
  1580	   as is in the packet by the Root.

I can not follow that paragraph. Would it be posible to constrain the example
to not also include the SRH-6LoRH complexity, given how its an option ? One
step at a time ?

  1581	
  1582	9.1.  Using Storing-Mode Segments
  1583	
  1584	   A==>B==>C and C==>D==>E are segments of a same Track.  Note that the

See above. his explanation comes too late.

  1585	   storing mode signaling imposes strict continuity in a segment.  One
           ^^^^^^^^^^^^^^^^^^^^^^                ^^^^^^^^^^ steering

So i am confused if actually the storing mode signaling imposes that strict
steering. I guess if i start from the egres, and it wants to forward the P-DAO
to the prior hop node in the VIO, if that prior hop is a neighbor, then it
would send the P-DAO directly to that neighbor, but if it is not a direct
neighbor, it would need to go through the root. I guess this is 101 knowledge
from RFC6550, so if i had the time to read anothe 150 pages, i might be able
to deduce that, but i guess it wouldn't hurt to put the same explanation into
th text, e.g.: P-DAO must be sent directly from each segment node to its
prior segment node, and in a non-storing DODAG, this is only possible if
they are neighbors.

Also:
One of the fundamental explanations missing is the definition of the relationship
between a segment and a P-Route. The way i figure, a P-DAO is (segment, {targets})
and represents a set of P-routes { targetI -> segment } targetI in {targets}).

And then definition of tracks as composed of sequences of P-routes constructed
from likely trees of P-DAO

Or something like that...

  1586	   benefit of strict routing is that loops are avoided along the Track.

As long as the underlying topology does not change and direct neigbors start
to becom non-diret neighbors. In which case i think the segment wold need
to be immediately invalidated. But the question raised in before about
ICMP errors is valid, especially when i think about path divesity forwarding.
In path diversity you often do NOT want to have traffic triggered errors, but
jus sit out the error, even if that trafic gets dropped somehwere along the path.
Any desirable repair to do on the topolocy could/should come ffom non-traffic
trigers, such as neighbor tracking to the management plane.

Is there any way for traffic itself in the Routing information header to indicate
if it does or does not want to get ICMP indications when it fails to get forwarded ?
That would be ideal to distingish between non-redundant and redundant traffic
ICMP reaction...

  1587	
  1588	9.1.1.  Stitched Segments

Sequential ?

  1589	
  1590	   Storing-Mode P-DAO 1 and 2 are sent to E and C, as follows:
  1591	
  1592	              +===============+==============+==============+
  1593	              |     Field     | P-DAO 1 to E | P-DAO 2 to C |
  1594	              +===============+==============+==============+
  1595	              |      Mode     | Storing      | Storing      |
  1596	              +---------------+--------------+--------------+
  1597	              | Track Ingress | A            | A            |
  1598	              +---------------+--------------+--------------+
  1599	              |    TrackID    | (A, 129)     | (A, 129)     |
  1600	              +---------------+--------------+--------------+
  1601	              |      VIO      | C, D, E      | A, B, C      |
  1602	              +---------------+--------------+--------------+
  1603	              |    Targets    | E, F, G      | E, F, G      |
  1604	              +---------------+--------------+--------------+
  1605	
  1606	                          Table 1: P-DAO Messages

Please add a line showing the SegmentID of the VIO so its clear how
the P-DAO are distinguished. I guess that is the identifier used, right ?

If this example is pimped up as asked for above, it would make a good
intro example, although it does not cover all options. But at last the
fact that the track ingres for the secnd (C,D,E) segment is still A
was not clear to me in before.

Also, i guess that if the track was more of a tree, then the targets
of some earlier segments wold be a superset of the targets of later
segments at a branching point.

  1608	   As a result the RIBs are set as follows:
  1609	
  1629	         +======+=============+=========+=============+==========+
  1630	         | Node | Destination | Origin  | Next Hop(s) | TrackID  |
  1631	         +======+=============+=========+=============+==========+
  1632	         |  E   | F, G        | P-DAO 1 | Neighbor    | (A, 129) |

But E would know about F and G alrady before P-DAO 1, so i wonder...

he example didn't call out which DODAG we're forwarding across. I guess this
is a sequental Track, which the example also does not say. 

In any case, instead of saying just "Destination", it would be good to
say Destination in which context in the table. "Destination in RPLInstance TrackID1 ???"

Q: If this is not in the main DODAG, but in that TrackID1 DODAG,
and we didn't send any P-DAO yet. Can we actually send/deliver packets ?
I guess no, right ? So what seems to happen is that we first have some
F, G neighbor information from the main DODAG, and because of P-DAO 1,
this information is inherited into the forwarding for TrackID1 DODAG ?
That would be good to show, or explain.

Also, given how you previously whee pointing out that these routes
are used over routes to the node because of prefix-length, should the
entries in the destination not rather read F/128, G/128, likewise for all the
other entries below ? Or does RPL imply fixed /128 unless its a /0 ? default
route to the root ?

Also: TrackID is 129 i think. (A, 129) seems to be the DODAG (Identifier?).
So maybe rename or rewrite accordingly.

  1633	         +------+-------------+---------+-------------+----------+
  1634	         |  D   | E           | P-DAO 1 | Neighbor    | (A, 129) |
  1635	         +------+-------------+---------+-------------+----------+
  1636	         |  "   | F, G        | P-DAO 1 | E           | (A, 129) |
  1637	         +------+-------------+---------+-------------+----------+
  1638	         |  C   | D           | P-DAO 1 | Neighbor    | (A, 129) |
  1639	         +------+-------------+---------+-------------+----------+
  1640	         |  "   | E, F, G     | P-DAO 1 | D           | (A, 129) |
  1641	         +------+-------------+---------+-------------+----------+
  1642	         |  B   | C           | P-DAO 2 | Neighbor    | (A, 129) |
  1643	         +------+-------------+---------+-------------+----------+
  1644	         |  "   | E, F, G     | P-DAO 2 | C           | (A, 129) |
  1645	         +------+-------------+---------+-------------+----------+
  1646	         |  A   | B           | P-DAO 2 | Neighbor    | (A, 129) |
  1647	         +------+-------------+---------+-------------+----------+
  1648	         |  A   | E, F, G     | P-DAO 2 | B           | (A, 129) |
  1649	         +------+-------------+---------+-------------+----------+
  1650	
  1651	                            Table 2: RIB setting
  1652	
  1653	   E recognizes that it is the Track Egress because it is both a Target
  1654	   and a Segment Endpoint.

... of P-DAO 1 ?

What would happen if E was not listed as a Target in P-DAO 2 ? 
Would that impact the ability to deliver packets to F, G via (A, 129) ?
If so, why ?  If its possible to deliver to (F,G) without indicating E in
target list, hen i think the statement is wrong.

And i can't see how the logic works. Lets assume C has a neighbor H,
so now we set the targets for P-DAO 2 to E,F,G,H. How would the notion
of including C into this target list help C to decide wheher to deliver
packets to H directly instead of leting them maybe go through further
segments ? Aka: It seems to me that if the logic is that if you are
sement endpoint, and any track egres for that segments P-DAO is a neighbor
in the main dodag, then you do forward directly to that target.

Yes/No/Maybe ? ;-))

Also: I think there should be some "Punt" line in the FIB on E for E as
a target. And it seems to me that that Punt line would be created
by including the segment endpoint into the target list. Maybe one
does not want to be able to address a segment endpoint via the Track DODAG...

  1656	   Packets originated by A to E, F, or G, do not require an
                             ^^^ from a source X via

  1657	   encapsulation.  In any fashion, the outer headers of the packets that
           ^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^ remove

how about "any additional encapsulation beside the one outer encapsulation
required for non-storage-mode" ?

Because immediately following you do write and show that outer encapsulation header.

  1657	   encapsulation.  In any fashion, the outer headers of the packets that
  1658	   are forwarded along the Track have the following settings:
  1659	
  1660	    +========+===================+===================+================+
  1661	    | Header | IPv6 Source Addr. | IPv6 Dest.  Addr. | TrackID in RPI |
  1662	    +========+===================+===================+================+
  1663	    | Outer  |         A         |     E, F or G     |    (A, 129)    |
  1664	    +--------+-------------------+-------------------+----------------+
  1665	    | Inner  |       X != A      |     E, F or G     |      N/A       |
  1666	    +--------+-------------------+-------------------+----------------+

Maybe add note: The Inner header is only required for X != A. 

  1667	
  1668	                      Table 3: Packet header settings
  1669	
  1670	   As an example, say that A has a packet for F.  Using the RIB above:
  1671	
  1672	   *  From P-DAO 2: A forwards to B and B forwards to C.
  1673	
  1674	   *  From P-DAO 1: C forwards to D and D forwards to E.
  1675	
  1676	   *  From Neighbor Cache Entry: C delivers the packet to F.
                                         ^ E ?

But see above, your FIB shows that E -> F as part of (A, 129), whereas the neighbor
cache entry is probably independent of 129, right ? So one of those statements
(table or neighbor-cache-entry) is wrong.
  
  1685	9.1.2.  External routes
                ^^^^^^^^^^^^^^^

New term not used in before. Explain.
  
  1687	   Storing-Mode P-DAO 1 and 2, and Non-Storing-Mode P-DAO 3, are sent to
  1688	   E, C and A, respectively, as follows:
  1689	
  1690	      +===============+==============+==============+==============+
  1691	      |               | P-DAO 1 to E | P-DAO 2 to C | P-DAO 3 to A |
  1692	      +===============+==============+==============+==============+
  1693	      |      Mode     | Storing      | Storing      | Non-Storing  |
  1694	      +---------------+--------------+--------------+--------------+
  1695	      | Track Ingress | A            | A            | A            |
  1696	      +---------------+--------------+--------------+--------------+
  1697	      |    TrackID    | (A, 129)     | (A, 129)     | (A, 129)     |
  1698	      +---------------+--------------+--------------+--------------+
  1699	      |      VIO      | C, D, E      | A, B, C      | E            |
  1700	      +---------------+--------------+--------------+--------------+
  1701	      |    Targets    | E            | E            | F, G         |
  1702	      +---------------+--------------+--------------+--------------+

Some explanation about the purpose of this example would be useful.

Seems to be something like. In this example, we want to avoid creating
state for F,G on B,C,D. We do this by using the two storing mode segmnts
P-DAO1 and P-DAO 2 to reach E and a non-storing segment P-DAO 3 to reach F
and G.

I am not clear why P-DAO 3 needs to be non-storing though. What would happen
if the only change to above was to indicate P-DAO 3 as storing ? aka: why
would B,C,D need to bother about any Target list of segments that they are not on ?

  1704	                         Table 4: P-DAO Messages
  1705	
  1706	   As a result the RIBs are set as follows:
  1707	
  1708	         +======+=============+=========+=============+==========+
  1709	         | Node | Destination | Origin  | Next Hop(s) | TrackID  |
  1710	         +======+=============+=========+=============+==========+
  1711	         |  E   | F, G        | P-DAO 1 | Neighbor    | (A, 129) |
                                        ^^^^^^^

Shouldn't this be P-DAO 3 ??

  1712	         +------+-------------+---------+-------------+----------+
  1713	         |  D   | E           | P-DAO 1 | Neighbor    | (A, 129) |
  1714	         +------+-------------+---------+-------------+----------+
  1715	         |  C   | D           | P-DAO 1 | Neighbor    | (A, 129) |
  1716	         +------+-------------+---------+-------------+----------+
  1717	         |  "   | E           | P-DAO 1 | D           | (A, 129) |
  1718	         +------+-------------+---------+-------------+----------+
  1719	         |  B   | C           | P-DAO 2 | Neighbor    | (A, 129) |
  1720	         +------+-------------+---------+-------------+----------+
  1721	         |  "   | E           | P-DAO 2 | C           | (A, 129) |
  1722	         +------+-------------+---------+-------------+----------+
  1723	         |  A   | B           | P-DAO 2 | Neighbor    | (A, 129) |
  1724	         +------+-------------+---------+-------------+----------+
  1725	         |  A   | E           | P-DAO 2 | B           | (A, 129) |
  1726	         +------+-------------+---------+-------------+----------+
  1727	         |  A   | F, G        | P-DAO 3 | E           | (A, 129) |
  1728	         +------+-------------+---------+-------------+----------+
  1729	
  1730	                            Table 5: RIB setting
  1731	
  1741	   Packets from A to E do not require an encapsulation.  In any fashion,
                                                 ^^^^^^^^^^^^^   ^^^^^^^^^^^^^^  delete
                                                 Inner Header

  1742	   the outer headers of the packets that are forwarded along the Track
  1743	   have the following settings:
  1744	
  1745	   +========+===================+====================+================+
  1746	   | Header | IPv6 Source Addr. | IPv6 Dest.  Addr.  | TrackID in RPI |
  1747	   +========+===================+====================+================+
  1748	   | Outer  |         A         |         E          |    (A, 129)    |
  1749	   +--------+-------------------+--------------------+----------------+
  1750	   | Inner  |         X         | E (X != A), F or G |      N/A       |
  1751	   +--------+-------------------+--------------------+----------------+
  1752	
  1753	                     Table 6: Packet header settings
  1754	
  1755	   As an example, say that A has a packet for F.  Using the RIB above:
  1756	
  1757	   *  From P-DAO 3: A encapsulates the packet the Track signaled by
                                                     ^ for     ^ (A,129)
  1758	      P-DAO 3, with the outer header above.  Now the packet destination
  1759	      is E.
             ^ of the Outer Header
  1760	
  1761	   *  From P-DAO 2: A forwards to B and B forwards to C.
  1762	
  1763	   *  From P-DAO 1: C forwards to D and D forwards to E; E decapsulates
  1764	      the packet.
                        ^ because it is the destination of the Outer Header
         ?? AND ? a valid target  for (A, 129) ??? (see question above
  1765	
  1766	   *  From Neighbor Cache Entry: C delivers packets to F or G.
  1767	
  1768	9.1.3.  Segment Routing

New term not used in before in this doc, define, reference (RFC8402 ?), etc. pp.

  1770	   Storing-Mode P-DAO 1 and 2, and Non-Storing-Mode P-DAO 3, are sent to
  1771	   E, B and A, respectively, as follows:

Again: Please add purpose/goal of this example.

If you did improve initial picture to show segments, then of course these
ar different now.

  1773	      +===============+==============+==============+==============+
  1774	      |               | P-DAO 1 to E | P-DAO 2 to B | P-DAO 3 to A |
  1775	      +===============+==============+==============+==============+
  1776	      |      Mode     | Storing      | Storing      | Non-Storing  |
  1777	      +---------------+--------------+--------------+--------------+
  1778	      | Track Ingress | A            | A            | A            |
  1779	      +---------------+--------------+--------------+--------------+
  1780	      |    TrackID    | (A, 129)     | (A, 129)     | (A, 129)     |
  1781	      +---------------+--------------+--------------+--------------+
  1782	      |      VIO      | C, D, E      | A, B         | C, E         |
  1783	      +---------------+--------------+--------------+--------------+
  1784	      |    Targets    | E            | B, C         | F, G         |
  1785	      +---------------+--------------+--------------+--------------+
  1786	
  1787	                         Table 7: P-DAO Messages

Does this example only work with B being the exit node for P-DAO2, or could
it equally work if we kept P-DAO 2 unchanged, ending at C, but the target only being C ?
I am guessing it could be, given how C would also need to look into P-DAO1 route
towards E, right ? Aka: Minimal change over prior example might make it easier..

  1797	   As a result the RIBs are set as follows:
  1798	
  1799	         +======+=============+=========+=============+==========+
  1800	         | Node | Destination | Origin  | Next Hop(s) | TrackID  |
  1801	         +======+=============+=========+=============+==========+
  1802	         |  E   | F, G        | P-DAO 1 | Neighbor    | (A, 129) |
  1803	         +------+-------------+---------+-------------+----------+
  1804	         |  D   | E           | P-DAO 1 | Neighbor    | (A, 129) |
  1805	         +------+-------------+---------+-------------+----------+
  1806	         |  C   | D           | P-DAO 1 | Neighbor    | (A, 129) |
  1807	         +------+-------------+---------+-------------+----------+
  1808	         |  "   | E           | P-DAO 1 | D           | (A, 129) |
  1809	         +------+-------------+---------+-------------+----------+
  1810	         |  B   | C           | P-DAO 2 | Neighbor    | (A, 129) |
  1811	         +------+-------------+---------+-------------+----------+
  1812	         |  A   | B           | P-DAO 2 | Neighbor    | (A, 129) |
  1813	         +------+-------------+---------+-------------+----------+
  1814	         |  "   | C           | P-DAO 2 | B           | (A, 129) |
  1815	         +------+-------------+---------+-------------+----------+
  1816	         |  "   | E, F, G     | P-DAO 3 | C, E        | (A, 129) |
  1817	         +------+-------------+---------+-------------+----------+
  1818	
  1819	                            Table 8: RIB setting
  1820	
  1821	   Packets from A to E do not require an encapsulation, but carry a SRH
 
a third header instead of encap ?

  1822	   via C.  In any fashion, the outer headers of the packets that are
  1823	   forwarded along the Track have the following settings:
  1824	
  1825	   +========+===================+====================+================+
  1826	   | Header | IPv6 Source Addr. | IPv6 Dest.  Addr.  | TrackID in RPI |
                                          ^^^^^^^^^^^^^^^^^

the SRH for th Outer Header is not just an Pv6 Dest. Addr.

  1827	   +========+===================+====================+================+
  1828	   | Outer  |         A         |  C till C then E   |    (A, 129)    |
  1829	   +--------+-------------------+--------------------+----------------+
  1830	   | Inner  |         X         | E (X != A), F or G |      N/A       |
  1831	   +--------+-------------------+--------------------+----------------+
  1832	
  1833	                     Table 9: Packet header settings
  1834	
  1835	   As an example, say that A has a packet for F.  Using the RIB above:
  1836	
  1837	   *  From P-DAO 3: A encapsulates the packet the Track signaled by
  1838	      P-DAO 3, with the outer header above.  Now the destination in the
  1839	      IPv6 Header is C, and a SRH signals the final destination is E.
  1840	
  1841	   *  From P-DAO 2: A forwards to B and B forwards to C.
  1842	
  1843	   *  From P-DAO 3: C processes the SRH and sets the destination in the
  1844	      IPv6 Header to E.
  1845	
  1853	   *  From P-DAO 1: C forwards to D and D forwards to E; E decapsulates
  1854	      the packet.
  1855	
  1856	   *  From the Neighbor Cache Entry: C delivers packets to F or G.
  1857	
  1858	9.2.  Using Non-Storing-Mode joining Tracks
  1859	
  1860	   A==>B==>C and C==>D==>E are Tracks expressed as non-storing P-DAOs.
  1861	
  1862	9.2.1.  Stitched Tracks

sequential Tracks ?
  
  1864	   Non-Storing Mode P-DAO 1 and 2 are sent to C and A respectively, as
  1865	   follows:
  1866	
  1867	              +===============+==============+==============+
  1868	              |               | P-DAO 1 to C | P-DAO 2 to A |
  1869	              +===============+==============+==============+
  1870	              |      Mode     | Non-Storing  | Non-Storing  |
  1871	              +---------------+--------------+--------------+
  1872	              | Track Ingress | C            | A            |
  1873	              +---------------+--------------+--------------+
  1874	              |    TrackID    | (C, 131)     | (A, 129)     |
  1875	              +---------------+--------------+--------------+
  1876	              |      VIO      | D, E         | B, C         |
  1877	              +---------------+--------------+--------------+
  1878	              |    Targets    | F, G         | E, F, G      |
  1879	              +---------------+--------------+--------------+

WOuld it be possible for both DAO to have the same number (129) given how
they are disambiguated by the source address ? If so i think it would strenthen
the example by doing so and highlighting that these are not the same Tracks anymore,
even if they reuse the same TrackID.

  1880	
  1881	                          Table 10: P-DAO Messages
  1882	
  1883	   As a result the RIBs are set as follows:
  1884	
  1885	
  1886	
  1887	
  1888	
  1889	
  1890	
  1891	
  1892	
  1893	
  1894	
  1895	
  1896	
  1897	
  1898	
  1899	
  1900	
  1901	
  1902	
  1903	
  1904	Thubert, et al.          Expires 28 January 2022               [Page 34]
  1905	
  1906	Internet-Draft               DAO Projection                    July 2021
  1907	
  1908	
  1909	         +======+=============+=========+=============+==========+
  1910	         | Node | Destination | Origin  | Next Hop(s) | TrackID  |
  1911	         +======+=============+=========+=============+==========+
  1912	         |  E   | F, G        | ND      | Neighbor    | Any      |
  1913	         +------+-------------+---------+-------------+----------+
  1914	         |  D   | E           | ND      | Neighbor    | Any      |
  1915	         +------+-------------+---------+-------------+----------+
  1916	         |  C   | D           | ND      | Neighbor    | Any      |
  1917	         +------+-------------+---------+-------------+----------+
  1918	         |  "   | E, F, G     | P-DAO 1 | D, E        | (C, 131) |
  1919	         +------+-------------+---------+-------------+----------+
  1920	         |  B   | C           | ND      | Neighbor    | Any      |
  1921	         +------+-------------+---------+-------------+----------+
  1922	         |  A   | B           | ND      | Neighbor    | Any      |
  1923	         +------+-------------+---------+-------------+----------+
  1924	         |  "   | C, E, F, G  | P-DAO 2 | B, C        | (A, 129) |
  1925	         +------+-------------+---------+-------------+----------+
  1926	
  1927	                           Table 11: RIB setting
  1928	
  1929	   Packets from A to E, F and G do not require an encapsulation, though
  1930	   it is preferred that A encapsulates and C decapsulates.  Either way,
  1931	   they carry a SRH via B and C, and C needs to encapsulate to E, F, or
  1932	   G to add an SRH via D and E.  The encapsulating headers of packets
  1933	   that are forwarded along the Track between C and E have the following
  1934	   settings:
  1935	
  1936	    +========+===================+===================+================+
  1937	    | Header | IPv6 Source Addr. | IPv6 Dest.  Addr. | TrackID in RPI |
  1938	    +========+===================+===================+================+
  1939	    | Outer  |         C         |  D till D then E  |    (C, 131)    |
  1940	    +--------+-------------------+-------------------+----------------+
  1941	    | Inner  |         X         |     E, F, or G    |      N/A       |
  1942	    +--------+-------------------+-------------------+----------------+
  1943	
  1944	                      Table 12: Packet header settings
  1945	
  1946	   As an example, say that A has a packet for F.  Using the RIB above:
  1947	
  1948	   *  From P-DAO 2: A encapsulates the packet with destination of F in
  1949	      the Track signaled by P-DAO 2.  The outer header has source A,
  1950	      destination B, an SRH that indicates C as the next loose hop, and
  1951	      a RPI indicating a TrackId of 129 from A's namespace.
  1952	
  1953	   *  From the SRH: Packets forwarded by B have source A, destination C
  1954	      , a consumed SRH, and a RPI indicating a TrackId of 129 from A's
  1955	      namespace.  C decapsulates.
  1956	
  1965	   *  From P-DAO 1: C encapsulates the packet with destination of F in
  1966	      the Track signaled by P-DAO 1.  The outer header has source C,
  1967	      destination D, an SRH that indicates E as the next loose hop, and
  1968	      a RPI indicating a TrackId of 131 from C's namespace.  E
  1969	      decapsulates.
  1970	
  1971	9.2.2.  External routes

sequential tracks with external routes ?

  1972	
  1973	   Non-Storing Mode P-DAO 1 is sent to C and Non-Storing Mode P-DAO 2
  1974	   and 3 are sent A, as follows:
  1975	
  1976	      +===============+==============+==============+==============+
  1977	      |               | P-DAO 1 to C | P-DAO 2 to A | P-DAO 3 to A |
  1978	      +===============+==============+==============+==============+
  1979	      |      Mode     | Non-Storing  | Non-Storing  | Non-Storing  |
  1980	      +---------------+--------------+--------------+--------------+
  1981	      | Track Ingress | C            | A            | A            |
  1982	      +---------------+--------------+--------------+--------------+
  1983	      |    TrackID    | (C, 131)     | (A, 129)     | (A, 141)     |
  1984	      +---------------+--------------+--------------+--------------+
  1985	      |      VIO      | D, E         | B, C         | E            |
  1986	      +---------------+--------------+--------------+--------------+
  1987	      |    Targets    | E            | E            | F, G         |
  1988	      +---------------+--------------+--------------+--------------+
  1989	
  1990	                         Table 13: P-DAO Messages
  1991	
  1992	   As a result the RIBs are set as follows:
  1993	
  1994	
  1995	
  1996	
  1997	
  1998	
  1999	
  2000	
  2001	
  2002	
  2003	
  2004	
  2005	
  2006	
  2007	
  2008	
  2009	
  2010	
  2011	
  2012	
  2013	
  2014	
  2015	
  2016	Thubert, et al.          Expires 28 January 2022               [Page 36]
  2017	
  2018	Internet-Draft               DAO Projection                    July 2021
  2019	
  2020	
  2021	         +======+=============+=========+=============+==========+
  2022	         | Node | Destination | Origin  | Next Hop(s) | TrackID  |
  2023	         +======+=============+=========+=============+==========+
  2024	         |  E   | F, G        | ND      | Neighbor    | Any      |
  2025	         +------+-------------+---------+-------------+----------+
  2026	         |  D   | E           | ND      | Neighbor    | Any      |
  2027	         +------+-------------+---------+-------------+----------+
  2028	         |  C   | D           | ND      | Neighbor    | Any      |
  2029	         +------+-------------+---------+-------------+----------+
  2030	         |  "   | E           | P-DAO 1 | D, E        | (C, 131) |
  2031	         +------+-------------+---------+-------------+----------+
  2032	         |  B   | C           | ND      | Neighbor    | Any      |
  2033	         +------+-------------+---------+-------------+----------+
  2034	         |  A   | B           | ND      | Neighbor    | Any      |
  2035	         +------+-------------+---------+-------------+----------+
  2036	         |  "   | C, E        | P-DAO 2 | B, C        | (A, 129) |
  2037	         +------+-------------+---------+-------------+----------+
  2038	         |  "   | F, G        | P-DAO 3 | E           | (A, 141) |
  2039	         +------+-------------+---------+-------------+----------+
  2040	
  2041	                           Table 14: RIB setting
  2042	
  2043	   The encapsulating headers of packets that are forwarded along the
  2044	   Track between C and E have the following settings:
  2045	
  2046	    +========+===================+===================+================+
  2047	    | Header | IPv6 Source Addr. | IPv6 Dest.  Addr. | TrackID in RPI |
  2048	    +========+===================+===================+================+
  2049	    | Outer  |         C         |  D till D then E  |    (C, 131)    |
  2050	    +--------+-------------------+-------------------+----------------+
  2051	    | Middle |         A         |         E         |    (A, 141)    |
  2052	    +--------+-------------------+-------------------+----------------+
  2053	    | Inner  |         X         |     E, F or G     |      N/A       |
  2054	    +--------+-------------------+-------------------+----------------+
  2055	
  2056	                      Table 15: Packet header settings
  2057	
  2058	   As an example, say that A has a packet for F.  Using the RIB above:
  2059	
  2060	   *  From P-DAO 3: A encapsulates the packet with destination of F in
  2061	      the Track signaled by P-DAO 3.  The outer header has source A,
  2062	      destination E, and a RPI indicating a TrackId of 141 from A's
  2063	      namespace.  This recurses with:
  2064	
  2065	   *  From P-DAO 2: A encapsulates the packet with destination of E in
  2066	      the Track signaled by P-DAO 2.  The outer header has source A,
  2067	      destination B, an SRH that indicates C as the next loose hop, and
  2068	      a RPI indicating a TrackId of 129 from A's namespace.
  2069	
  2070	
  2071	
  2072	Thubert, et al.          Expires 28 January 2022               [Page 37]
  2073	
  2074	Internet-Draft               DAO Projection                    July 2021
  2075	
  2076	
  2077	   *  From the SRH: Packets forwarded by B have source A, destination C
  2078	      , a consumed SRH, and a RPI indicating a TrackId of 129 from A's
  2079	      namespace.  C decapsulates.
  2080	
  2081	   *  From P-DAO 1: C encapsulates the packet with destination of E in
  2082	      the Track signaled by P-DAO 1.  The outer header has source C,
  2083	      destination D, an SRH that indicates E as the next loose hop, and
  2084	      a RPI indicating a TrackId of 131 from C's namespace.  E
  2085	      decapsulates.
  2086	
  2087	9.2.3.  Segment Routing

segment routing with exernal routes ?
  2088	
  2089	   Non-Storing Mode P-DAO 1 is sent to C and Non-Storing Mode P-DAO 2
  2090	   and 3 are sent A, as follows:
  2091	
  2092	      +===============+==============+==============+==============+
  2093	      |               | P-DAO 1 to C | P-DAO 2 to A | P-DAO 3 to A |
  2094	      +===============+==============+==============+==============+
  2095	      |      Mode     | Non-Storing  | Non-Storing  | Non-Storing  |
  2096	      +---------------+--------------+--------------+--------------+
  2097	      | Track Ingress | C            | A            | A            |
  2098	      +---------------+--------------+--------------+--------------+
  2099	      |    TrackID    | (C, 131)     | (A, 129)     | (A, 141)     |
  2100	      +---------------+--------------+--------------+--------------+
  2101	      |      VIO      | D, E         | B            | C, E         |
  2102	      +---------------+--------------+--------------+--------------+
  2103	      |    Targets    |              | C            | F, G         |
  2104	      +---------------+--------------+--------------+--------------+
  2105	
  2106	                         Table 16: P-DAO Messages
  2107	
  2108	   As a result the RIBs are set as follows:
  2109	
  2110	
  2111	
  2112	
  2113	
  2114	
  2115	
  2116	
  2117	
  2118	
  2119	
  2120	
  2121	
  2122	
  2123	
  2124	
  2125	
  2126	
  2127	
  2128	Thubert, et al.          Expires 28 January 2022               [Page 38]
  2129	
  2130	Internet-Draft               DAO Projection                    July 2021
  2131	
  2132	
  2133	         +======+=============+=========+=============+==========+
  2134	         | Node | Destination | Origin  | Next Hop(s) | TrackID  |
  2135	         +======+=============+=========+=============+==========+
  2136	         |  E   | F, G        | ND      | Neighbor    | Any      |
  2137	         +------+-------------+---------+-------------+----------+
  2138	         |  D   | E           | ND      | Neighbor    | Any      |
  2139	         +------+-------------+---------+-------------+----------+
  2140	         |  C   | D           | ND      | Neighbor    | Any      |
  2141	         +------+-------------+---------+-------------+----------+
  2142	         |  "   | E           | P-DAO 1 | D, E        | (C, 131) |
  2143	         +------+-------------+---------+-------------+----------+
  2144	         |  B   | C           | ND      | Neighbor    | Any      |
  2145	         +------+-------------+---------+-------------+----------+
  2146	         |  A   | B           | ND      | Neighbor    | Any      |
  2147	         +------+-------------+---------+-------------+----------+
  2148	         |  "   | C           | P-DAO 2 | B, C        | (A, 129) |
  2149	         +------+-------------+---------+-------------+----------+
  2150	         |  "   | E, F, G     | P-DAO 3 | C, E        | (A, 141) |
  2151	         +------+-------------+---------+-------------+----------+
  2152	
  2153	                           Table 17: RIB setting
  2154	
  2155	   The encapsulating headers of packets that are forwarded along the
  2156	   Track between A and B have the following settings:
  2157	
  2158	    +========+===================+===================+================+
  2159	    | Header | IPv6 Source Addr. | IPv6 Dest.  Addr. | TrackID in RPI |
  2160	    +========+===================+===================+================+
  2161	    | Outer  |         A         |  B till D then E  |    (A, 129)    |
  2162	    +--------+-------------------+-------------------+----------------+
  2163	    | Middle |         A         |         C         |    (A, 141)    |
  2164	    +--------+-------------------+-------------------+----------------+
  2165	    | Inner  |         X         |     E, F or G     |      N/A       |
  2166	    +--------+-------------------+-------------------+----------------+
  2167	
  2168	                      Table 18: Packet header settings
  2169	
  2170	   The encapsulating headers of packets that are forwarded along the
  2171	   Track between B and C have the following settings:
  2172	
  2173	
  2174	
  2175	
  2176	
  2177	
  2178	
  2179	
  2180	
  2181	
  2182	
  2183	
  2184	Thubert, et al.          Expires 28 January 2022               [Page 39]
  2185	
  2186	Internet-Draft               DAO Projection                    July 2021
  2187	
  2188	
  2189	    +========+===================+===================+================+
  2190	    | Header | IPv6 Source Addr. | IPv6 Dest.  Addr. | TrackID in RPI |
  2191	    +========+===================+===================+================+
  2192	    | Outer  |         A         |         C         |    (A, 141)    |
  2193	    +--------+-------------------+-------------------+----------------+
  2194	    | Inner  |         X         |     E, F or G     |      N/A       |
  2195	    +--------+-------------------+-------------------+----------------+
  2196	
  2197	                      Table 19: Packet header settings
  2198	
  2199	   The encapsulating headers of packets that are forwarded along the
  2200	   Track between C and E have the following settings:
  2201	
  2202	    +========+===================+===================+================+
  2203	    | Header | IPv6 Source Addr. | IPv6 Dest.  Addr. | TrackID in RPI |
  2204	    +========+===================+===================+================+
  2205	    | Outer  |         C         |  D till D then E  |    (C, 131)    |
  2206	    +--------+-------------------+-------------------+----------------+
  2207	    | Middle |         A         |         E         |    (A, 141)    |
  2208	    +--------+-------------------+-------------------+----------------+
  2209	    | Inner  |         X         |     E, F or G     |      N/A       |
  2210	    +--------+-------------------+-------------------+----------------+
  2211	
  2212	                      Table 20: Packet header settings
  2213	
  2214	   As an example, say that A has a packet for F.  Using the RIB above:
  2215	
  2216	   *  From P-DAO 3: A encapsulates the packet with destination of F in
  2217	      the Track signaled by P-DAO 3.  The outer header has source A,
  2218	      destination C, an SRH that indicates E as the next loose hop, and
  2219	      a RPI indicating a TrackId of 141 from A's namespace.  This
  2220	      recurses with:
  2221	
  2222	   *  From P-DAO 2: A encapsulates the packet with destination of C in
  2223	      the Track signaled by P-DAO 2.  The outer header has source A,
  2224	      destination B, and a RPI indicating a TrackId of 129 from A's
  2225	      namespace.  B decapsulates forwards to C based on a sibling
  2226	      connected route.
  2227	
  2228	   *  From the SRH: C consumes the SRH and makes the destination E.
  2229	
  2230	   *  From P-DAO 1: C encapsulates the packet with destination of E in
  2231	      the Track signaled by P-DAO 1.  The outer header has source C,
  2232	      destination D, an SRH that indicates E as the next loose hop, and
  2233	      a RPI indicating a TrackId of 131 from C's namespace.  E
  2234	      decapsulates.
  2235	

Sorry, i skipped mostly across 1883 to here, running out of time.
  
  2245	10.  Security Considerations
  2246	
  2247	   It is worth noting that with [RPL], every node in the LLN is RPL-
  2248	   aware and can inject any RPL-based attack in the network.  This draft

I guss even RUL nodes, which i think came after rfc6550 could be nasty too and
inject RPL messages.

  2249	   uses messages that are already present in RPL [RPL] with optional
  2250	   secured versions.  The same secured versions may be used with this
  2251	   draft, and whatever security is deployed for a given network also
  2252	   applies to the flows in this draft.
  2253	
  2254	   The LLN nodes depend on the 6LBR and the RPL participants for their
  2255	   operation.  A trust model must be put in place to ensure that the
  2256	   right devices are acting in these roles, so as to avoid threats such
  2257	   as black-holing, (see [RFC7416] section 7).  This trust model could
  2258	   be at a minimum based on a Layer-2 Secure joining and the Link-Layer
  2259	   security.  This is a generic 6LoWPAN requirement, see Req5.1 in
  2260	   Appendix B.5 of [RFC8505].

  2261	
  2262	   In a general manner, the Security Considerations in [RPL], and
  2263	   [RFC7416] apply to this specification as well.  The Link-Layer
  2264	   security is needed in particular to prevent Denial-Of-Service attacks
  2265	   whereby a rogue router creates a high churn in the RPL network by
  2266	   constantly injected forged P-DAO messages and using up all the
  2267	   available storage in the attacked routers.

Seems like the answer is no.

  2268	
  2269	   Additionally, the trust model could include a role validation (e.g.,
  2270	   using a role-based authorization) to ensure that the node that claims
  2271	   to be a RPL Root is entitled to do so.  That trust should propagate
  2272	   from egress to ingress in the case of a Storing Mode P-DAO.

In ANIMA i am pondering to get role-based certificates to enable something like this.
Is there any existing solution for this ? If not, then it would be good to mention this
as a gap. In general, the whole PCE based routing model does put more reliance of a
trustworthy PCE into the solution, but it eliminates  a lot of security attacks
coming from the normal peer-2-peer routing model (i am just making this argument
in my bier-te draft, ask me again, when i have read BenK's feedback ;-).

But when
like it seems in this solution, one mixes the tradtional non-role based signaling
with PCE input then it looks like a bigge gap than in before, because now these
new routes allow to potentially create even more black holes than may have been
possible in before (not quite sure).

In any case, you can also mention that you did try to eliminate one new type of
attack by injection of duplicate addresses in tracks by mandating to discover such
issue. Not sure though if this is the best set of heuristics that nodes could
apply to self-defend themslfes and further hops from incorrect new messages. Miht
be worth to ponder.

  2273	
  2274	11.  IANA Considerations

I am not going to read this (out of time). I would suggest as mentione din before to replace
all numbers with TBDi and then strongly consider early IANA allocation. That would
also help a lot to resolve any possible issues with any of the registration asks by
mean of the IANA/expert review ensueing.

  2276	11.1.  New Elective 6LoWPAN Routing Header Type
  2277	
  2278	   This document updates the IANA registry titled "Elective 6LoWPAN
  2279	   Routing Header Type" that was created for [RFC8138] and assigns the
  2280	   following value:
  2281	
  2282	                  +=======+=============+===============+
  2283	                  | Value | Description | Reference     |
  2284	                  +=======+=============+===============+
  2285	                  |   7   | P-RPI-6LoRH | This document |
  2286	                  +-------+-------------+---------------+
  2287	
  2288	                       Table 21: New Elective 6LoWPAN
  2289	                            Routing Header Type
  2290	
  2291	
  2292	
  2293	
  2294	
  2295	
  2296	Thubert, et al.          Expires 28 January 2022               [Page 41]
  2297	
  2298	Internet-Draft               DAO Projection                    July 2021
  2299	
  2300	
  2301	11.2.  New Critical 6LoWPAN Routing Header Type
  2302	
  2303	   This document updates the IANA registry titled "Critical 6LoWPAN
  2304	   Routing Header Type" that was created for [RFC8138] and assigns the
  2305	   following value:
  2306	
  2307	                  +=======+=============+===============+
  2308	                  | Value | Description | Reference     |
  2309	                  +=======+=============+===============+
  2310	                  |   7   | P-RPI-6LoRH | This document |
  2311	                  +-------+-------------+---------------+
  2312	
  2313	                       Table 22: New Critical 6LoWPAN
  2314	                            Routing Header Type
  2315	
  2316	11.3.  New Subregistry For The RPL Option Flags
  2317	
  2318	   IANA is required to create a subregistry for the 8-bit RPL Option
  2319	   Flags field, as detailed in Figure 2, under the "Routing Protocol for
  2320	   Low Power and Lossy Networks (RPL)" registry.  The bits are indexed
  2321	   from 0 (leftmost) to 7.  Each bit is tracked with the following
  2322	   qualities:
  2323	
  2324	   *  Bit number (counting from bit 0 as the most significant bit)
  2325	
  2326	   *  Indication When Set
  2327	
  2328	   *  Reference
  2329	
  2330	   Registration procedure is "Standards Action" [RFC8126].  The initial
  2331	   allocation is as indicated in Table 26:
  2332	
  2333	           +============+======================+===============+
  2334	           | Bit number | Indication When Set  | Reference     |
  2335	           +============+======================+===============+
  2336	           |     0      | Down 'O'             | [RFC6553]     |
  2337	           +------------+----------------------+---------------+
  2338	           |     1      | Rank-Error (R)       | [RFC6553]     |
  2339	           +------------+----------------------+---------------+
  2340	           |     2      | Forwarding-Error (F) | [RFC6553]     |
  2341	           +------------+----------------------+---------------+
  2342	           |     3      | Projected-Route (P)  | This document |
  2343	           +------------+----------------------+---------------+
  2344	
  2345	                        Table 23: Initial PDR Flags
  2346	
  2347	
  2348	
  2349	
  2350	
  2351	
  2352	Thubert, et al.          Expires 28 January 2022               [Page 42]
  2353	
  2354	Internet-Draft               DAO Projection                    July 2021
  2355	
  2356	
  2357	11.4.  New RPL Control Codes
  2358	
  2359	   This document extends the IANA Subregistry created by RFC 6550 for
  2360	   RPL Control Codes as indicated in Table 24:
  2361	
  2362	          +======+=============================+===============+
  2363	          | Code | Description                 | Reference     |
  2364	          +======+=============================+===============+
  2365	          | 0x09 | Projected DAO Request (PDR) | This document |
  2366	          +------+-----------------------------+---------------+
  2367	          | 0x0A | PDR-ACK                     | This document |
  2368	          +------+-----------------------------+---------------+
  2369	
  2370	                     Table 24: New RPL Control Codes
  2371	
  2372	11.5.  New RPL Control Message Options
  2373	
  2374	   This document extends the IANA Subregistry created by RFC 6550 for
  2375	   RPL Control Message Options as indicated in Table 25:
  2376	
  2377	          +=======+============================+===============+
  2378	          | Value | Meaning                    | Reference     |
  2379	          +=======+============================+===============+
  2380	          |  0x0B | Stateful VIO (SF-VIO)      | This document |
  2381	          +-------+----------------------------+---------------+
  2382	          |  0x0C | Source-Routed VIO (SR-VIO) | This document |
  2383	          +-------+----------------------------+---------------+
  2384	          |  0x0D | Sibling Information option | This document |
  2385	          +-------+----------------------------+---------------+
  2386	
  2387	                  Table 25: RPL Control Message Options
  2388	
  2389	11.6.  SubRegistry for the Projected DAO Request Flags
  2390	
  2391	   IANA is required to create a registry for the 8-bit Projected DAO
  2392	   Request (PDR) Flags field.  Each bit is tracked with the following
  2393	   qualities:
  2394	
  2395	   *  Bit number (counting from bit 0 as the most significant bit)
  2396	
  2397	   *  Capability description
  2398	
  2399	   *  Reference
  2400	
  2401	   Registration procedure is "Standards Action" [RFC8126].  The initial
  2402	   allocation is as indicated in Table 26:
  2403	
  2404	
  2405	
  2406	
  2407	
  2408	Thubert, et al.          Expires 28 January 2022               [Page 43]
  2409	
  2410	Internet-Draft               DAO Projection                    July 2021
  2411	
  2412	
  2413	          +============+========================+===============+
  2414	          | Bit number | Capability description | Reference     |
  2415	          +============+========================+===============+
  2416	          |     0      | PDR-ACK request (K)    | This document |
  2417	          +------------+------------------------+---------------+
  2418	          |     1      | Requested path should  | This document |
  2419	          |            | be redundant (R)       |               |
  2420	          +------------+------------------------+---------------+
  2421	
  2422	                        Table 26: Initial PDR Flags
  2423	
  2424	11.7.  SubRegistry for the PDR-ACK Flags
  2425	
  2426	   IANA is required to create an subregistry for the 8-bit PDR-ACK Flags
  2427	   field.  Each bit is tracked with the following qualities:
  2428	
  2429	   *  Bit number (counting from bit 0 as the most significant bit)
  2430	
  2431	   *  Capability description
  2432	
  2433	   *  Reference
  2434	
  2435	   Registration procedure is "Standards Action" [RFC8126].  No bit is
  2436	   currently defined for the PDR-ACK Flags.
  2437	
  2438	11.8.  Subregistry for the PDR-ACK Acceptance Status Values
  2439	
  2440	   IANA is requested to create a Subregistry for the PDR-ACK Acceptance
  2441	   Status values.
  2442	
  2443	   *  Possible values are 6-bit unsigned integers (0..63).
  2444	
  2445	   *  Registration procedure is "Standards Action" [RFC8126].
  2446	
  2447	   *  Initial allocation is as indicated in Table 27:
  2448	
  2449	            +-------+------------------------+---------------+
  2450	            | Value | Meaning                | Reference     |
  2451	            +-------+------------------------+---------------+
  2452	            | 0     | Unqualified acceptance | This document |
  2453	            +-------+------------------------+---------------+
  2454	
  2455	            Table 27: Acceptance values of the PDR-ACK Status
  2456	
  2457	11.9.  Subregistry for the PDR-ACK Rejection Status Values
  2458	
  2459	   IANA is requested to create a Subregistry for the PDR-ACK Rejection
  2460	   Status values.
  2461	
  2462	
  2463	
  2464	Thubert, et al.          Expires 28 January 2022               [Page 44]
  2465	
  2466	Internet-Draft               DAO Projection                    July 2021
  2467	
  2468	
  2469	   *  Possible values are 6-bit unsigned integers (0..63).
  2470	
  2471	   *  Registration procedure is "Standards Action" [RFC8126].
  2472	
  2473	   *  Initial allocation is as indicated in Table 28:
  2474	
  2475	             +-------+-----------------------+---------------+
  2476	             | Value | Meaning               | Reference     |
  2477	             +-------+-----------------------+---------------+
  2478	             | 0     | Unqualified rejection | This document |
  2479	             +-------+-----------------------+---------------+
  2480	
  2481	              Table 28: Rejection values of the PDR-ACK Status
  2482	
  2483	11.10.  SubRegistry for the Via Information Options Flags
  2484	
  2485	   IANA is requested to create a Subregistry for the 5-bit Via
  2486	   Information Options (Via Information Option) Flags field.  Each bit
  2487	   is tracked with the following qualities:
  2488	
  2489	   *  Bit number (counting from bit 0 as the most significant bit)
  2490	
  2491	   *  Capability description
  2492	
  2493	   *  Reference
  2494	
  2495	   Registration procedure is "Standards Action" [RFC8126].  No bit is
  2496	   currently defined for the Via Information Options (Via Information
  2497	   Option) Flags.
  2498	
  2499	11.11.  SubRegistry for the Sibling Information Option Flags
  2500	
  2501	   IANA is required to create a registry for the 5-bit Sibling
  2502	   Information Option (SIO) Flags field.  Each bit is tracked with the
  2503	   following qualities:
  2504	
  2505	   *  Bit number (counting from bit 0 as the most significant bit)
  2506	
  2507	   *  Capability description
  2508	
  2509	   *  Reference
  2510	
  2511	   Registration procedure is "Standards Action" [RFC8126].  The initial
  2512	   allocation is as indicated in Table 29:
  2513	
  2514	
  2515	
  2516	
  2517	
  2518	
  2519	
  2520	Thubert, et al.          Expires 28 January 2022               [Page 45]
  2521	
  2522	Internet-Draft               DAO Projection                    July 2021
  2523	
  2524	
  2525	    +============+===================================+===============+
  2526	    | Bit number | Capability description            | Reference     |
  2527	    +============+===================================+===============+
  2528	    |     0      | Connectivity is bidirectional (B) | This document |
  2529	    +------------+-----------------------------------+---------------+
  2530	
  2531	                       Table 29: Initial SIO Flags
  2532	
  2533	11.12.  New Destination Advertisement Object Flag
  2534	
  2535	   This document modifies the "Destination Advertisement Object (DAO)
  2536	   Flags" registry initially created in Section 20.11 of [RPL] .
  2537	
  2538	   Section 3.1 also defines one new entry in the Registry as follows:
  2539	
  2540	          +---------------+------------------------+-----------+
  2541	          | Bit Number    | Capability Description | Reference |
  2542	          +---------------+------------------------+-----------+
  2543	          | 2 (suggested) | Projected DAO (P)      | THIS RFC  |
  2544	          +---------------+------------------------+-----------+
  2545	
  2546	              Table 30: New Destination Advertisement Object
  2547	                                (DAO) Flag
  2548	
  2549	11.13.  Error in Projected Route ICMPv6 Code
  2550	
  2551	   In some cases RPL will return an ICMPv6 error message when a message
  2552	   cannot be forwarded along a Projected Route.  This ICMPv6 error
  2553	   message is "Error in Projected Route".
  2554	
  2555	   IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6 Message
  2556	   Types.  ICMPv6 Message Type 1 describes "Destination Unreachable"
  2557	   codes.  This specification requires that a new code is allocated from
  2558	   the ICMPv6 Code Fields Registry for ICMPv6 Message Type 1, for "Error
  2559	   in Projected Route", with a suggested code value of 8, to be
  2560	   confirmed by IANA.
  2561	
  2562	12.  Acknowledgments
  2563	
  2564	   The authors wish to acknowledge JP Vasseur, Remy Liubing, James
  2565	   Pylakutty and Patrick Wetterwald for their contributions to the ideas
  2566	   developed here.
  2567	
  2568	13.  Normative References
  2569	
  2570	
  2571	
  2572	
  2573	
  2574	
  2575	
  2576	Thubert, et al.          Expires 28 January 2022               [Page 46]
  2577	
  2578	Internet-Draft               DAO Projection                    July 2021
  2579	
  2580	
  2581	   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
  2582	              Requirement Levels", BCP 14, RFC 2119,
  2583	              DOI 10.17487/RFC2119, March 1997,
  2584	              <https://www.rfc-editor.org/info/rfc2119>.
  2585	
  2586	   [RFC4443]  Conta, A., Deering, S., and M. Gupta, Ed., "Internet
  2587	              Control Message Protocol (ICMPv6) for the Internet
  2588	              Protocol Version 6 (IPv6) Specification", STD 89,
  2589	              RFC 4443, DOI 10.17487/RFC4443, March 2006,
  2590	              <https://www.rfc-editor.org/info/rfc4443>.
  2591	
  2592	   [RFC6282]  Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
  2593	              Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
  2594	              DOI 10.17487/RFC6282, September 2011,
  2595	              <https://www.rfc-editor.org/info/rfc6282>.
  2596	
  2597	   [RPL]      Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
  2598	              Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
  2599	              JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
  2600	              Low-Power and Lossy Networks", RFC 6550,
  2601	              DOI 10.17487/RFC6550, March 2012,
  2602	              <https://www.rfc-editor.org/info/rfc6550>.
  2603	
  2604	   [RFC6553]  Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
  2605	              Power and Lossy Networks (RPL) Option for Carrying RPL
  2606	              Information in Data-Plane Datagrams", RFC 6553,
  2607	              DOI 10.17487/RFC6553, March 2012,
  2608	              <https://www.rfc-editor.org/info/rfc6553>.
  2609	
  2610	   [RFC6554]  Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
  2611	              Routing Header for Source Routes with the Routing Protocol
  2612	              for Low-Power and Lossy Networks (RPL)", RFC 6554,
  2613	              DOI 10.17487/RFC6554, March 2012,
  2614	              <https://www.rfc-editor.org/info/rfc6554>.
  2615	
  2616	   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
  2617	              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
  2618	              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
  2619	
  2620	   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
  2621	              Writing an IANA Considerations Section in RFCs", BCP 26,
  2622	              RFC 8126, DOI 10.17487/RFC8126, June 2017,
  2623	              <https://www.rfc-editor.org/info/rfc8126>.
  2624	
  2625	14.  Informative References
  2626	
  2627	
  2628	
  2629	
  2630	
  2631	
  2632	Thubert, et al.          Expires 28 January 2022               [Page 47]
  2633	
  2634	Internet-Draft               DAO Projection                    July 2021
  2635	
  2636	
  2637	   [RFC7102]  Vasseur, JP., "Terms Used in Routing for Low-Power and
  2638	              Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
  2639	              2014, <https://www.rfc-editor.org/info/rfc7102>.
  2640	
  2641	   [RFC6997]  Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and
  2642	              J. Martocci, "Reactive Discovery of Point-to-Point Routes
  2643	              in Low-Power and Lossy Networks", RFC 6997,
  2644	              DOI 10.17487/RFC6997, August 2013,
  2645	              <https://www.rfc-editor.org/info/rfc6997>.
  2646	
  2647	   [RFC7416]  Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,
  2648	              and M. Richardson, Ed., "A Security Threat Analysis for
  2649	              the Routing Protocol for Low-Power and Lossy Networks
  2650	              (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015,
  2651	              <https://www.rfc-editor.org/info/rfc7416>.
  2652	
  2653	   [6TiSCH-ARCHI]
  2654	              Thubert, P., Ed., "An Architecture for IPv6 over the Time-
  2655	              Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)",
  2656	              RFC 9030, DOI 10.17487/RFC9030, May 2021,
  2657	              <https://www.rfc-editor.org/info/rfc9030>.
  2658	
  2659	   [RAW-ARCHI]
  2660	              Thubert, P., Papadopoulos, G. Z., and L. Berger, "Reliable
  2661	              and Available Wireless Architecture/Framework", Work in
  2662	              Progress, Internet-Draft, draft-ietf-raw-architecture-00,
  2663	              12 July 2021, <https://datatracker.ietf.org/doc/html/
  2664	              draft-ietf-raw-architecture-00>.
  2665	
  2666	   [TURN-ON_RFC8138]
  2667	              Thubert, P., Ed. and L. Zhao, "A Routing Protocol for Low-
  2668	              Power and Lossy Networks (RPL) Destination-Oriented
  2669	              Directed Acyclic Graph (DODAG) Configuration Option for
  2670	              the 6LoWPAN Routing Header", RFC 9035,
  2671	              DOI 10.17487/RFC9035, April 2021,
  2672	              <https://www.rfc-editor.org/info/rfc9035>.
  2673	
  2674	   [RFC8655]  Finn, N., Thubert, P., Varga, B., and J. Farkas,
  2675	              "Deterministic Networking Architecture", RFC 8655,
  2676	              DOI 10.17487/RFC8655, October 2019,
  2677	              <https://www.rfc-editor.org/info/rfc8655>.
  2678	
  2679	   [RFC8025]  Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power
  2680	              Wireless Personal Area Network (6LoWPAN) Paging Dispatch",
  2681	              RFC 8025, DOI 10.17487/RFC8025, November 2016,
  2682	              <https://www.rfc-editor.org/info/rfc8025>.
  2683	
  2684	
  2685	
  2686	
  2687	
  2688	Thubert, et al.          Expires 28 January 2022               [Page 48]
  2689	
  2690	Internet-Draft               DAO Projection                    July 2021
  2691	
  2692	
  2693	   [RFC8138]  Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
  2694	              "IPv6 over Low-Power Wireless Personal Area Network
  2695	              (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
  2696	              April 2017, <https://www.rfc-editor.org/info/rfc8138>.
  2697	
  2698	   [RFC8505]  Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
  2699	              Perkins, "Registration Extensions for IPv6 over Low-Power
  2700	              Wireless Personal Area Network (6LoWPAN) Neighbor
  2701	              Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
  2702	              <https://www.rfc-editor.org/info/rfc8505>.
  2703	
  2704	   [USEofRPLinfo]
  2705	              Robles, M.I., Richardson, M., and P. Thubert, "Using RPI
  2706	              Option Type, Routing Header for Source Routes, and IPv6-
  2707	              in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008,
  2708	              DOI 10.17487/RFC9008, April 2021,
  2709	              <https://www.rfc-editor.org/info/rfc9008>.
  2710	
  2711	   [PCE]      IETF, "Path Computation Element",
  2712	              <https://datatracker.ietf.org/doc/charter-ietf-pce/>.
  2713	
  2714	Appendix A.  Applications

I wouldn't call this applications, its more like optimiations goals or the like
  2715	
  2716	A.1.  Loose Source Routing

Optimizing packet size vs. routing state via Loose Source Routing
  
  2718	   A RPL implementation operating in a very constrained LLN typically
  2719	   uses the Non-Storing Mode of Operation as represented in Figure 12.
  2720	   In that mode, a RPL node indicates a parent-child relationship to the
  2721	   Root, using a Destination Advertisement Object (DAO) that is unicast
  2722	   from the node directly to the Root, and the Root typically builds a
  2723	   source routed path to a destination down the DODAG by recursively
  2724	   concatenating this information.
  2725	
  2726	              ------+---------
  2727	                    |          Internet
  2728	                    |
  2729	                 +-----+
  2730	                 |     | Border Router
  2731	                 |     |  (RPL Root)
  2732	                 +-----+                      ^     |        |
  2733	                    |                         | DAO | ACK    |
  2734	              o    o   o    o                 |     |        | Strict
  2735	          o o   o  o   o  o  o o   o          |     |        | Source
  2736	         o  o o  o o    o   o   o  o  o       |     |        | Route
  2737	         o   o    o  o     o  o    o  o  o    |     |        |
  2738	        o  o   o  o   o         o   o o       |     v        v
  2739	        o          o             o     o
  2740	                          LLN
  2741	
  2742	
  2743	
  2744	Thubert, et al.          Expires 28 January 2022               [Page 49]
  2745	
  2746	Internet-Draft               DAO Projection                    July 2021
  2747	
  2748	
  2749	                Figure 12: RPL Non-Storing Mode of operation
  2750	
  2751	   Based on the parent-children relationships expressed in the non-
  2752	   storing DAO messages,the Root possesses topological information about
  2753	   the whole network, though this information is limited to the
  2754	   structure of the DODAG for which it is the destination.  A packet
  2755	   that is generated within the domain will always reach the Root, which
  2756	   can then apply a source routing information to reach the destination
  2757	   if the destination is also in the DODAG.  Similarly, a packet coming
  2758	   from the outside of the domain for a destination that is expected to
  2759	   be in a RPL domain reaches the Root.
  2760	
  2761	   It results that the Root, or then some associated centralized
  2762	   computation engine such as a PCE, can determine the amount of packets
  2763	   that reach a destination in the RPL domain, and thus the amount of
  2764	   energy and bandwidth that is wasted for transmission, between itself
  2765	   and the destination, as well as the risk of fragmentation, any
  2766	   potential delays because of a paths longer than necessary (shorter
  2767	   paths exist that would not traverse the Root).
  2768	
  2769	   As a network gets deep, the size of the source routing header that
  2770	   the Root must add to all the downward packets becomes an issue for
  2771	   nodes that are many hops away.  In some use cases, a RPL network
  2772	   forms long lines and a limited amount of well-Targeted routing state
  2773	   would allow to make the source routing operation loose as opposed to
  2774	   strict, and save packet size.

Maybe ad to be more explicit:

And example of such well-targeted routing state is what is needed to reach the
neared loose steerig hops.

  2774	   Limiting the packet size is directly
  2775	   beneficial to the energy budget, but, mostly, it reduces the chances
  2776	   of frame loss and/or packet fragmentation, which is highly
  2777	   detrimental to the LLN operation.  Because the capability to store a
  2778	   routing state in every node is limited, the decision of which route
  2779	   is installed where can only be optimized with a global knowledge of
  2780	   the system, a knowledge that the Root or an associated PCE may
  2781	   possess by means that are outside of the scope of this specification.
  2782	
  2783	   This specification enables to store a Storing Mode state in
  2784	   intermediate routers, which enables to limit the excursion of the
  2785	   source route headers in deep networks.  Once a P-DAO exchange has
  2786	   taken place for a given Target, if the Root operates in non Storing
  2787	   Mode, then it may elide the sequence of routers that is installed in
  2788	   the network from its source route headers to destination that are
  2789	   reachable via that Target, and the source route headers effectively
  2790	   become loose.
  2791	
  2792	
  2793	
  2794	
  2795	
  2796	
  2797	
  2798	
  2799	
  2800	Thubert, et al.          Expires 28 January 2022               [Page 50]
  2801	
  2802	Internet-Draft               DAO Projection                    July 2021
  2803	
  2804	
  2805	A.2.  Transversal Routes
  2806	
  2807	   RPL is optimized for Point-to-Multipoint (P2MP) and Multipoint-to-
  2808	   Point (MP2P), whereby routes are always installed along the RPL DODAG
  2809	   respectively from and towards the DODAG Root.  Transversal Peer to
  2810	   Peer (P2P) routes in a RPL network will generally suffer from some
  2811	   elongated (stretched) path versus the best possible path, since
  2812	   routing between 2 nodes always happens via a common parent, as
  2813	   illustrated in Figure 13:

That figure needs to be improved if anyone who doesn't know what a transversal
route is is expected to understand it. Just paint a picture with the minimum
number of nodes to show a transversal route not part of the DODAG.
Figure 14 is kinda ok., but in 13 its really unclear where traffic flows and why.

Also: Is there any RPL messaging that would allow for the Root to have enough
knowledge about transversal connectibity not part of the DODAG, which it could
then tell the PCE ? If not, then for fairness, it would be good to highlight this as
a gap for the solution.
  
  2815	   *  In Storing Mode, unless the destination is a child of the source,
  2816	      the packets will follow the default route up the DODAG as well.
  2817	      If the destination is in the same DODAG, they will eventually
  2818	      reach a common parent that has a route to the destination; at
  2819	      worse, the common parent may also be the Root.  From that common
  2820	      parent, the packet will follow a path down the DODAG that is
  2821	      optimized for the Objective Function that was used to build the
  2822	      DODAG.
  2823	
  2824	   *  in Non-Storing Mode, all packets routed within the DODAG flow all
  2825	      the way up to the Root of the DODAG.  If the destination is in the
  2826	      same DODAG, the Root must encapsulate the packet to place an RH
  2827	      that has the strict source route information down the DODAG to the
  2828	      destination.  This will be the case even if the destination is
  2829	      relatively close to the source and the Root is relatively far off.
  2830	
  2831	
  2832	                      ------+---------
  2833	                       |          Internet
  2834	                       |
  2835	                    +-----+
  2836	                    |     | Border Router
  2837	                    |     |  (RPL Root)
  2838	                    +-----+
  2839	                       X
  2840	                 ^    v   o    o
  2841	             ^ o   o  v   o  o  o o   o
  2842	            ^  o o  o v    o   o   o  o  o
  2843	            ^   o    o  v     o  o    o  o  o
  2844	           S  o   o  o   D         o   o o
  2845	           o          o             o     o
  2846	                             LLN
  2847	
  2848	       Figure 13: Routing Stretch between S and D via common parent X
  2849	
  2850	   It results that it is often beneficial to enable transversal P2P
  2851	   routes, either if the RPL route presents a stretch from shortest
  2852	   path, or if the new route is engineered with a different objective,
  2853	
  2854	
  2855	
  2856	Thubert, et al.          Expires 28 January 2022               [Page 51]
  2857	
  2858	Internet-Draft               DAO Projection                    July 2021
  2859	
  2860	
  2861	   and that it is even more critical in Non-Storing Mode than it is in
  2862	   Storing Mode, because the routing stretch is wider.  For that reason,
  2863	   earlier work at the IETF introduced the "Reactive Discovery of
  2864	   Point-to-Point Routes in Low Power and Lossy Networks" [RFC6997],
  2865	   which specifies a distributed method for establishing optimized P2P
  2866	   routes.  This draft proposes an alternate based on a centralized
  2867	   route computation.
  2868	
  2869	                 ------+---------
  2870	                       |          Internet
  2871	                       |
  2872	                    +-----+
  2873	                    |     | Border Router
  2874	                    |     |  (RPL Root)
  2875	                    +-----+
  2876	                       |
  2877	                 o    o   o    o
  2878	             o o   o  o   o  o  o o   o
  2879	            o  o o  o o    o   o   o  o  o
  2880	            o   o    o  o     o  o    o  o  o
  2881	           S>>A>>>B>>C>>>D         o   o o
  2882	           o          o             o     o
  2883	                             LLN
  2884	
  2885	                   Figure 14: Projected Transversal Route
  2886	
  2887	   This specification enables to store source-routed or Storing Mode
  2888	   state in intermediate routers, which enables to limit the stretch of
  2889	   a P2P route and maintain the characteristics within a given SLA.  An
  2890	   example of service using this mechanism oculd be a control loop that
  2891	   would be installed in a network that uses classical RPL for
  2892	   asynchronous data collection.  In that case, the P2P path may be
  2893	   installed in a different RPL Instance, with a different objective
  2894	   function.
  2895	
  2896	Authors' Addresses
  2897	
  2898	   Pascal Thubert (editor)
  2899	   Cisco Systems, Inc
  2900	   Building D
  2901	   45 Allee des Ormes - BP1200
  2902	   06254 Mougins - Sophia Antipolis
  2903	   France
  2904	
  2905	   Phone: +33 497 23 26 34
  2906	   Email: [email-masked]
  2907	
  2908	
  2909	
  2910	
  2911	
  2912	Thubert, et al.          Expires 28 January 2022               [Page 52]
  2913	
  2914	Internet-Draft               DAO Projection                    July 2021
  2915	
  2916	
  2917	   Rahul Arvind Jadhav
  2918	   Huawei Tech
  2919	   Kundalahalli Village, Whitefield,
  2920	   Bangalore 560037
  2921	   Karnataka
  2922	   India
  2923	
  2924	   Phone: +91-080-49160700
  2925	   Email: [email-masked]
  2926	
  2927	
  2928	   Matthew Gillmore
  2929	   Itron, Inc
  2930	   Building D
  2931	   2111 N Molter Road
  2932	   Liberty Lake,  99019
  2933	   United States
  2934	
  2935	   Phone: +1.800.635.5461
  2936	   Email: [email-masked]
  2937	
  2938	
  2939	
  2940	
  2941	
  2942	
  2943	
  2944	
  2945	
  2946	
  2947	
  2948	
  2949	
  2950	
  2951	
  2952	
  2953	
  2954	
  2955	
  2956	
  2957	
  2958	
  2959	
  2960	
  2961	
  2962	
  2963	
  2964	
  2965	
  2966	
  2967	
  2968	Thubert, et al.          Expires 28 January 2022               [Page 53]