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

[Toerless Eckert <[e-mail]>]

Thanks Pascal, looks good.

Two comments inline

On Mon, Sep 06, 2021 at 09:33:50AM +0000, Pascal Thubert (pthubert) wrote:
> 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. 

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

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 ;-(

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]