adapt document to priority not changing through the DODAG #9
Conversation
| @@ -1,7 +1,7 @@ | |||
| --- | |||
| title: Controlling Secure Network Enrollment in RPL networks | |||
| abbrev: join-metric | |||
| docname: draft-ietf-roll-enrollment-priority-07 | |||
| docname: draft-ietf-roll-enrollment-priority-06 | |||
There was a problem hiding this comment.
the new draft version lower than previous?
There was a problem hiding this comment.
I think that I goofed incrementing the number too many times. -05 is what is posted.
6tisch-roll-enrollment-priority.mkd
Outdated
|
|
||
| As explained in {{!RFC9032}}, higher values decrease the likelyhood of an unenrolled node sending enrollment traffic via this path. | ||
|
|
||
| A network operator can set this value to the maximum value allowed, effectively disable all new enrollment traffic. | ||
|
|
||
| Updates to this option propogate slowly through the network according to the trickle algorithm that periodically sends updates. |
There was a problem hiding this comment.
If we assume that we never reset the DIO trickle timer, the option propagation in worst case may take hours or even days to propagate depending on DIO trickle timer parameters.
6tisch-roll-enrollment-priority.mkd
Outdated
| However, the term *Join Proxy* is retained with it's meaning from {{!RFC9031}}. | ||
|
|
||
|
|
||
| # Protocol Definition | ||
|
|
||
| With this specification, the following option is defined for transmission in the DIO issued by the DODAG root and it MUST be propagated down the DODAG. | ||
|
|
||
| A 6LR which would otherwise be willing to act as a *Join Proxy*, will examine the minimum priority field, and to that number, add any additional local consideration (such as upstream congestion). | ||
| A 6LR which would otherwise be willing to act as a *Join Proxy*, will examine the minimum priority field, and to that number, add any additional local consideration (such as upstream congestion, number of NCE slots available, etc.) | ||
|
|
||
| The Enrollment Priority can only be increased by each 6LR in value, to the maximum value of 0x7f. |
There was a problem hiding this comment.
Are we allowing the 6LRs to change the Enrollment priority? Based on @mcr mail, it was not allowed.
There was a problem hiding this comment.
We aren't changing the global enrollment priority, but in translating this RPL metric to the one in RFC9032, the local node is allowed to take into consideration local conditions. Perhaps this isn't worded well.
|
We need to provide the math or at least indicate the the OF’ that computes the priority in the beacon from the min I. The DIO MUST be homogeneous across DODAGs of the RPL instance…
A bientôt;
Pascal
… Le 23 nov. 2021 à 12:34, Michael Richardson ***@***.***> a écrit :
@mcr commented on this pull request.
In 6tisch-roll-enrollment-priority.mkd:
> However, the term *Join Proxy* is retained with it's meaning from {{!RFC9031}}.
# Protocol Definition
With this specification, the following option is defined for transmission in the DIO issued by the DODAG root and it MUST be propagated down the DODAG.
-A 6LR which would otherwise be willing to act as a *Join Proxy*, will examine the minimum priority field, and to that number, add any additional local consideration (such as upstream congestion).
+A 6LR which would otherwise be willing to act as a *Join Proxy*, will examine the minimum priority field, and to that number, add any additional local consideration (such as upstream congestion, number of NCE slots available, etc.)
The Enrollment Priority can only be increased by each 6LR in value, to the maximum value of 0x7f.
We aren't changing the global enrollment priority, but in translating this RPL metric to the one in RFC9032, the local node is allowed to take into consideration local conditions. Perhaps this isn't worded well.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Are you saying that you want two nodes, from two different vendors, to emit the same Enhanced Beacon priority, given the same input from the min I? |
|
Yes. Because a node that may join dag à or b should be able to judge on equal terms
A bientôt;
Pascal
… Le 24 nov. 2021 à 18:39, Michael Richardson ***@***.***> a écrit :
We need to provide the math or at least indicate the the OF’ that computes the priority in the beacon from the min I. The DIO MUST be homogeneous across DODAGs of the RPL instance… A bientôt; Pascal
Are you saying that you want two nodes, from two different vendors, to emit the same Enhanced Beacon priority, given the same input from the min I?
(I'm not saying this is bad, I'm wondering if we know enough to write this down at this point)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
already merged. |
No description provided.