Re: [Roll] do capabilities need to understood, can they be added?

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

Hello Michael and all

> The point of introducing the NAO was that it would have different rules
> about where it goes?

Yes. Thinking out loud:

What we have today
---------------------------

- DAG configuration information to signal activation of a feature as we build a DAG are fine with a DIO and configuration option (e.g., flag day using capability blah such as use RFC 8138 compression or place ROVR in DAO). It could indicate, as RFC 6551 says, that " the constraint specified in the body of the object is optional". It is not as efficient as a global on/off switch when all nodes need to act "transactionally", see the discussion in turnon-rfc-8138 about turning off again. IOW, we do not have reliable-multicast communication to set something on/off dynamically on all nodes. 
- DAG constraints to build a DAG are fine in a DIO with a RFC 6551 Node Metric/Constraint Objects in the DAG Metric Container Option. We could extend the Node State and Attribute (NSA) object to add constraints in capabilities (e.g., do not join as a router if you do not have capability blah such as RFC 8138 compression). Note that RFC 6551 does not deal with "capabilities" but it discusses "characteristics" such as battery type and level. 
- NSA in DIO could also be a vessel to disseminate DAG level capabilities in addition to making them constraints as above (e.g., the capability to proxy the EDAR at the Root for RUL could be exposed in the NSA as well). Once we used NSA to place constraints as well as expose some capabilities, it makes sense to use it in the capability query/response mechanism that we are after.
- DAO is not sequenced with / synchronized to DIO. There's a slight attempt with DTSN but you cannot say I have all the DAOs from all nodes based on DIO blah. IOW DIO / DAO is not designed as an asynchronous query/response mechanism. Achieving something like DUAL in EIGRP looked too hard in an unreliable / never converged LLN. Still does.

A new message model
------------------------------

I think the messages need to change because of different semantics and flows. Semantics because we care about nodes as opposed to DAG (DIO) or Destinations (DAO); think, like, in OSPF a Router LSA is different from a Link LSA.  And flows look different because we appear to need a reliable multicast, either Root to all nodes or a parent to all its children. Today we do not have a message that a parent sends to all the children and it expects all the children to answer. Because it's hard to do on a LLN. How do we know who all the children are? How does the parent retry when 90% of the known children have answered? A series of unicasts or a broadcast again? What about the root?

Today a change in the configuration is trickled in DIOs that are propagated down, which means it is slowly disseminated, it does not take effect quickly to all, and it spreads. It eventually reaches all the live nodes but we do not know when. And DIO is about DAG. 
But if we used DIO to query node capabilities, then we could not do unicast retries hops away. DIO does not work like that. That's when it starts feeling like an abuse. And trickling a new DIO to all because we are missing one answer in the whole DODAG seems extreme. OTOH, a new Node Information Query that can be unicast, multicast one hop down or recursively all the way down would do the trick. The query would indicate what the root (or parent) wants to know. It could even provide the value at the querier. The response would be a unicast NAO. 
We could even have a child use a NIQ unicast to a parent or the root, who would reply unicast to the querier or multicast NAO to all children. Parents could aggregate NAOs for children towards the grandparent.

Diffusion like DUAL is probably still too hard, as it was when we designed DIO. We should probably shoot for something that hits most nodes, that is mostly reliable. This generally works when turning something on like RFC 8138 compression. Those who did not see the knob do not compress but that works. And then if really important find a way to unicast and then garage the nodes who did not respond. E.g., do not install P-DAO routes in nodes that did not respond to capability queries.

A new container/option?
---------------------------------

I thought we could extend the existing Node Metric/Constraint objects to add capabilities but I'm not adamant about it. Just that there are things already there and that we need. Like signaling constraints, whether they are mandatory or not, and describing node characteristics. The 'O'verload bit in NSA looks like something we need to get inspiration from, though we need to understand if the overload has to do with forwarding, Storing Mode routes, P-Dao states, or whatever else. The DAG Metric Container is really related to distributed routing decisions. We need to maintain a map of the DODAG with capabilities for centralized route computation P-DAO and the likes. It's a stretch, not a gigantic one.

The NIQ/NAO would transport the same NSAs. It would also produce neighborhood information, e.g. the number of P-DAO routes that can be stored - or just P-DAO storage "overload".

What do you think?

Pascal

> -----Original Message-----
> From: Roll <[e-mail]> On Behalf Of Michael Richardson
> Sent: lundi 2 septembre 2019 20:04
> To: Routing Over Low power and Lossy networks <[e-mail]>
> Subject: Re: [Roll] do capabilities need to understood, can they be added?
> 
> 
> Pascal Thubert (pthubert) <[e-mail]> wrote:
>     > In addition to the below I took a refresh look at RFC 6551.
> 
>     > https://tools.ietf.org/html/rfc6551#section-3.1 provides a shell for
> capabilities such as those that we are after.
>     > And
>     > https://tools.ietf.org/html/rfc6551#section-3.2 discusses how to handle
>     > a resource that varies over time and is subject to consumption and
>     > exhaustion. Storage of routes for P-DAO has similarities with that.
> 
>     > All in all I'm thinking that we could extend Node Metric/Constraint
>     > Objects and how they are used for DODAG formation. We could for
>     > instance use the metric container as defined for DIO and create at
>     > least one new message to report to the asker for the reasons below.
> 
> So, we'd (ab)use node metrics to provide information from children to
> parents (and possibly to root) on what the node can do?
> 
> They (DAG Metric Containers) are options, and live in DIOs or DAOs, so
> would still be limited as to how they flow up/down the DAG.  This just
> changes how we encapsulate the options, but does not change the rules on
> where the information flows.
> 
> The point of introducing the NAO was that it would have different rules
> about where it goes?
> 
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
> -= IPv6 IoT consulting =-