Subject: [Roll] Extension point for node information

From: Remous-Aris Koutsiamanis <[email-masked]>
Date: Tue, 29 May 2018 23:30:43 +0200 (CEST)

Dear all,

we are working on issues of parent selection and DODAG selection.
We have already worked on two drafts which add information to the DIO DAG
MC to support these choices.
We are debating where in the DAG MC to put information regarding node state.

In draft draft-koutsiamanis-roll-nsa-extension-01 we put the "Parent Node
Set" information (the list of a node's parent IPv6 addresses) in a new TLV
nested within the NSA metric object.
However, in draft draft-ji-roll-traffic-aware-objective-function-01 we
added the "Packet Transmission Rate" information as a new metric object
type directly withing the DAG MC as  new Routing-MC-Type (i.e., at the same
"level" as the other 6551-defined metric object like ETX, Node Energy,
etc.).
We are now debating if we maybe should re-position the "Packet Transmission
Rate" information nested withing the NSA metric object, as with "the Parent
Node Set", or not.

Both these drafts propose carrying information which is semantically
similar: information internal to a node.
We are wondering what would be more correct to do:
a) ask for new Routing-MC-Type allocation and create new metric objects.
b) ask for new NSA TLV type allocation and create as nested TLV within the
NSA metric object.

We have noted that in RFC6551 there is the NSA metric object and also a
separate node-information metric object specifically for energy, the "Node
Energy (NE) object".
It would seem that the existing NE object should be nested within the NSA
metric object if all node information is to be put within NSA.
If not, we expect that we should be able put our own additions at the same
level (i.e. use case a, above, to ask for new Routing-MC-Type allocation).
Should we do this?

If none of the above, is there a reason why an exception was made
especially for energy information?

Kind regards,
Aris