Re: [Roll] Extension point for node information

Dear Roll,

Please find this e-mail as a friendly reminder.
This is the e-mail that Aris mentioned during his presentation. 

We are looking forward for your feedbacks.

Best,
Georgios and Aris

____________________________________

Georgios Z. Papadopoulos, Ph.D.
Associate Professor, IMT Atlantique, Rennes

web: 	 www.georgiospapadopoulos.com <http://www.georgiospapadopoulos.com/>
twitter: 	@gzpapadopoulos <https://twitter.com/gzpapadopoulos?ref_src=twsrc%5Etfw&ref_url=http://georgiospapadopoulos.com/>
____________________________________

> On May 30, 2018, at 00:30, Remous-Aris Koutsiamanis <aris@ariskou.com> wrote:
> 
> 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
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll