Subject: [Roll] Metrics draft, NE constraint

From: <[email-masked]>
Date: Tue, 22 Jun 2010 17:34:24 +0200

Hello all,

This post pertains to the use of Node Energy as a contraint.

The metrics draft currently says there can be only one NE subobject per
object when used as a constraint. The "Type" bit field currently has 3
possible values. Was it intended that only one type of node (mains
powered, scavenger, battery-operated) is included in an RPLL instance?
By playing the I bit, one can cleverly include two types by excluding
the third one. But this trick will no longer be possible if a fourth
value is defined for "Type".
Should we then allow several NE-subojects in an NE, and define the
combination rules ? Alternately, is there an implicit order relation on
node type, and better types than that explicitely included are all
included, while worse types than that explicitely excluded are all
excluded? 

Even if we stay with the current three values for T, I have questions.
It is not explicitely stated that the EE field is valid for constraints
but, by default, I assume this to be the case.
In which case, how do you combine the use of the EE field with
including/excluding several types of nodes?
For example, how do you include battery-powered nodes with H>90 and
scavenging nodes with H>25?
This is not possible with the current encoding.

Does anybody confirm that we want to do the kind of examples listed
above?

Thanks

Dominique

---

From: JP Vasseur <[email-masked]>
Date: Wed, 23 Jun 2010 21:17:02 +0200

Hi Dominique,

On Jun 22, 2010, at 5:34 PM, <[email-masked]> <[email-masked] 
 > wrote:

> included, while worse types than that explicitely excluded are all

Good point. Then I'd rather prefer to allow for several NE sub-objects  
than
using implicit ordering relationship.

> but, by default, I assume this to be the case.

Correct.

> This is not possible with the current encoding.

You would indeed need to include multiple objects. This can be fixed  
pretty
easily, thanks for the feed-back.

> Does anybody confirm that we want to do the kind of examples listed

Since this does not add complexity (just need to slightly change some  
rules),
always better to allow for such scenario indeed.

Thanks.

JP.

>
> Thanks
>
> Dominique
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll