Re: [Roll] IOTdir Review of draft-ietf-roll-dao-projection-19

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Toerless;

Needless to say, I'm moving on with your review comments. This is a very deep review, for which I'm utterly grateful.
The aresponse implies that I reshuffle the doc quite a bit. 
I actually had to do it several times already, and I'm only half way through. 

Please be patient, that's a big lot of work, to be interspersed with other duties.

To your points below:

> >
> >    On the other hand, since RPL is a Layer-3 protocol, its applicability
> >    extends beyond LLNs, e.g., on wired networks, as used by the ANIMA
> >    Autonomic Control Plane (ACP) [RFC8994].  In a powered and wired
> >    network, where the memory to store the needed routes is easily
> >    available, Storing Mode usually makes more sense than Non-Storing as
> >    i reduces the route stretch and lowers the load on the Root.
> 
> I think there where more reasons we used to choose the ACP profile, and
> those reasons might apply to other wired network uses of RPL as well
> (IMHO):
> 
> | RPL routing information headers may not be available on all type of
> | wired network infrastructures, especially not in high-speed routers.
> | Opeating without it requires single root storage mode. These networks,
> | RPL with storage mode requires fewer resources than alternative
> | protocols like OSPF, ISIS, BABEL or RIP but at the expense of higher
> | route stretch than shortest path routes to any destination as in those
> protocols.
> | P-DAO allows to add for  example such routes to especially important
> | destinations such as in RFC8994 A.9.4.
> 






> >    In that
> >    case, the control path between the Root and the LLN nodes is highly
> >    available compared to LLNs, and the nodes can be reached to maintain
> >    the Projected Routes at most times.  This section specifies the
> >    additions that are needed in Storing Mode.
> >
> >    In Storing Mode, the Root misses the Child to Parent relationship
> >    that forms the main DODAG, as well as the sibling information.  To
> >    provide that knowledge the nodes in the network MUST send additional
> >    DAO messages that are unicast to the Root as Non-Storing DAO messages
> >    are.
> >
> >    In the DAO message, the originating router advertises a set of
> >    neighbor nodes using Sibling Information Options, regardless of the
> >    relative position in the DODAG of the advertised node vs. this
> >    router.  To advertise a neighbor node, the router MUST have an active
> >    Address Registration from that node using [RFC8505], for an address
> >    (ULA or GUA) that serves as identifier for the node.
> >
> >    The DAO message MUST be formed as follows:
> >
> >    *  The originating router is identified by the source address of the
> >       DAO.  That address MUST be the one that this router registers to
> >       neighbor routers so the Root can correlate the DAOs from those
> >       routers when they advertise this router as their neighbor.  The
> >       DAO contains one or more sequences of one Transit Information
> >       Option and one or more Sibling Information Options.  There is no
> >       RPL Target Option so the Root is not confused into adding a
> >       Storing Mode Router to the target.
> >
> >    *  The TIO is formed as in Storing Mode, and the Parent Address is
> >       not present.  The Path Sequence and Path Lifetime fields are
> >       aligned with the values used in the Address Registration of the
> >       node(s) advertised in the SIO, as explained in Section 9.1. of
> >       [RFC9010].  Having similar values in all nodes allows to factorise
> >       the TIO for multiple SIOs as done with [RPL].
> >
> >    *  The TIO is followed by one or more SIOs that provide an address
> >       (ULA or GUA) of the advertised neighbor router.  As opposed to
> >       Non-Storing Mode, this includes both siblings and parents.
> > "
> >
> > Works?
> 
> If i read it correctly, the missing functionality is all about the required
> additional reporting so the root (and controller behind it) has enough
> topology information to calculate desirable P-DAO, but there is no change
> needed for actual P-DAO, e.g.: existing P-DAO could be used to install the
> desired additional routes into the default intance ?!

This is correct as long as you can have an RPI in the data packets. 
When you do not, the main instance has to be assumed. 

The reasons we focused the spec on NS Mode are:
- simpler spec
- better applicability in LLNs (compress SRH)
- less topology to upload

In SM, the PDR and Track structure and datapath signaling would remain the same.
What changes is the the TIO is the SM form, and 


> 
> As for the details of above explanatoin, i don't yet understand the details
> of those SIO/TIO enough to vet if there is no gap ;-(


In NS mode the TIO provides the parent address in the DAO. In Storing Mode no such thing.

Reworked section:
"


8.  Storing-Mode Main DODAG

   This specification expects that the main DODAG is operated in Non-
   Storing Mode.  The reasons for that limitation are mostly related to
   LLN operations, power and spectrum conservation:

   *  In Non-Storing Mode The Root already possesses the DODAG topology,
      so the additional topological information is reduced to the
      siblings.

   *  The downwards routes are updated with unicast messages to the
      Root, which ensures that the Root can reach back to the LLN nodes
      after a repair faster than in the case of Storing Mode.  Also the
      Root can control the use of the path diversity in the DODAG to
      reach to the LLN nodes.  For both reasons, Non-Storing Mode
      provides better capabilities for the Root to maintain the
      P-Routes.

   *  When the main DODAG is operated in Non-Storing Mode, P-Routes
      enable loose Source Routing, which is only an advantage in that
      mode.  Storing Mode does not use Source Routing Headers, and does
      not derive the same benefits from this capability.

   On the other hand, since RPL is a Layer-3 routing protocol, its
   applicability extends beyond LLNs to a generic IP network.  RPL
   requires fewer resources than alternative IGPs like OSPF, ISIS,
   EIGRP, BABEL or RIP at the expense of a route stretch vs. the
   shortest path routes to a Destination that those protocols compute.
   Projected Routes add the capability to install shortest and/or
   constrained routes to special destinations such as discussed in
   section A.9.4. of the ANIMA ACP [RFC8994].

   In a powered and wired network, when enough memory to store the
   needed routes is available, the RPL Storing Mode proposes a better
   trade-off than the Non-Storing, as it reduces the route stretch and
   lowers the load on the Root.  In that case, the control path between
   the Root and the LLN nodes is highly available compared to LLNs, and
   the nodes can be reached to maintain the P-Routes at most times.

   This section specifies the additions that are needed to support
   Projected Routes when the main DODAG is operated in Storing Mode.  As
   long as the RPI can be processed adequately by the dataplane, the
   changes to this specification are limited to the DAO message.  The
   Track structure, routes and forwarding operations remain the same.

   In Storing Mode, the Root misses the Child to Parent relationship
   that forms the main DODAG, as well as the sibling information.  To
   provide that knowledge the nodes in the network MUST send additional
   DAO messages that are unicast to the Root as Non-Storing DAO messages
   are.

   In the P-DAO message, the originating router advertises a set of
   neighbor nodes using Sibling Information Options, regardless of the
   relative position in the DODAG of the advertised node vs. this
   router.  To advertise a neighbor node, the router MUST have an active
   Address Registration from that node using [RFC8505], for an address
   (ULA or GUA) that serves as identifier for the node.

   The DAO message MUST be formed as follows:

   *  The originating router is identified by the source address of the
      DAO.  That address MUST be the one that this router registers to
      neighbor routers so the Root can correlate the DAOs from those
      routers when they advertise this router as their neighbor.  The
      DAO contains one or more sequences of one Transit Information
      Option and one or more Sibling Information Options.  There is no
      RPL Target Option so the Root is not confused into adding a
      Storing Mode Router to the target.

   *  The TIO is formed as in Storing Mode, and the Parent Address is
      not present.  The Path Sequence and Path Lifetime fields are
      aligned with the values used in the Address Registration of the
      node(s) advertised in the SIO, as explained in Section 9.1. of
      [RFC9010].  Having similar values in all nodes allows to factorise
      the TIO for multiple SIOs as done with [RPL].

   *  The TIO is followed by one or more SIOs that provide an address
      (ULA or GUA) of the advertised neighbor node.

   But the RPL routing information headers may not be supported on all
   type of routed network infrastructures, especially not in high-speed
   routers.  When the RPI is not be supported in the dataplane, RPL can
   only operate as a single topology (the main DODAG).  In that case,
   the Tracks MUST be installed using the main RPL Instance as TrackID,
   and the routes along the Tracks are alternate routes to those
   available along the main DODAG.  They MAY conflict with routes to
   children and MUST take precedence in the routing table.  The targets
   MUST be adjacent to the Track Egress to avoid loops that may form if
   the packet is reinjected in the main DODAG.

"

Works?

Keep safe,

Pascal


> 
> Cheers
>    Toerless
> 
> > Pascal
> >
> > > -----Original Message-----
> > > From: Pascal Thubert (pthubert)
> > > Sent: jeudi 2 septembre 2021 17:33
> > > To: Routing Over Low power and Lossy networks <[e-mail]>
> > > Cc: [e-mail]
> > > Subject: RE: [Roll] IOTdir Review of
> > > draft-ietf-roll-dao-projection-19
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Roll <[e-mail]> On Behalf Of Michael Richardson
> > > > Sent: jeudi 2 septembre 2021 17:14
> > > > To: Routing Over Low power and Lossy networks <[e-mail]>
> > > > Cc: [e-mail]
> > > > Subject: Re: [Roll] IOTdir Review of
> > > > draft-ietf-roll-dao-projection-19
> > > >
> > > >
> > > > Toerless Eckert <[e-mail]> wrote:
> > > >     > 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
> > > >
> > > > I also thought it could help.
> > >
> > > It will be out decision to add that to the draft or not. It's feasible.
> > > That will be in my answer to Toerless. Sadly it takes time.
> > >
> > > >
> > > >     > 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.
> > > >
> > > > I think that the text may be the problem.
> > > > Last I checked, the intention is to support both adding
> > > > non-storing routes to storing mode, and storing routes to non-storing
> mode.
> > > > My view was that we were finally unifying the two modes into a
> > > > kind of hybrid.
> > >
> > > We still are but for now the draft does not play in a storing mode
> > > DODAG because it is lacking the DODAG topology.
> > > Which can be alleviated by calling parents siblings and sending
> > > non-storing DAOs to the root even in storing mode for both siblings and
> parents.
> > > We are already doing that mix for external routes...
> > > Please keep that point alive.
> > >
> > >
> > > >
> > > >     > 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 agree.
> > > > I also suspect that we need more implementator feedback.
> > > >
> > >
> > >
> > > Same here this is a great review and it entails a significant update
> work.
> > > I'm on it but cannot spend all the time I'd wish.
> > >
> > > Keep safe;
> > >
> > > Pascal
> > _______________________________________________
> > Roll mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/roll
> 
> --
> ---
> [e-mail]