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

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

Hello Toerless and Michael

On you point about a storing mode main DODAG; I suggest we keep it as a side addition by having a new section about it.
What about 
"
10.  Storing-Mode Main DODAG

   This specification expects that the main DODAG is operated in Non-
   Storing Mode.  The reasons for that limitation are mostlt 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
      Projected Routes.

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

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

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