Thanks Joe. Yes, I meant I2RS CLIENT priority, not agent priority.
Yours,
Joel
On 7/20/16 5:30 AM, Joe Clarke wrote:
On 7/20/16 05:24, Joel M. Halpern wrote:
That wording may well lead readers to think that Ephemeral
configuration, considered as a whole, has a priority. Since that is not
true, I would like to further refine this. How about:
Req-07: Local configuration MUST have a priority that is comparable with
the I2RS Agent priority for making changes. This priority will
determine whether local configuration changes or individual ephemeral
configuration changes take precedence. The I2RS protocol MUST support
his mechanism.
I think you mean I2RS client priority? But otherwise, I like the text.
Joe
Yours,
Joel
On 7/20/16 4:05 AM, Joe Clarke wrote:
On 7/20/16 03:42, Susan Hares wrote:
Joe:
Yes - you are correct. Can you help me state this requirement -07
better?
What about:
Ephemeral-REQ-07: Ephemeral configuration and local configuration MUST
each have a priority. This priority will determine whether ephemeral
configuration or local configuration take precedence. The I2RS protocol
MUST support this mechanism.
Is this clear and correct enough?
Joe
Sue
-----Original Message-----
From: Joe Clarke [mailto:[email protected]]
Sent: Wednesday, July 20, 2016 3:40 AM
To: Susan Hares; 'Russ White'; [email protected]
Subject: Re: [i2rs] Comments on Ephemeral-REQ-07 (local config vs.
ephemeral)
On 7/20/16 02:18, Susan Hares wrote:
<WG hat off> <author hat on>
Here's text that might replace it:
Ephemeral-REQ-07: Ephemeral configuration state MUST be able to set a
priority on local configuration and ephemeral state. Based on this
priority implementations MUST be able to provide a mechanism to choose
which takes precedence. The I2RS Protocol MUST be able to support this
mechanisms.
Any thoughts?
I'm a bit confused by the first sentence. I think what you're
stating is
that both ephemeral and local configurations MUST have a priority.
This priority will determine whether ephemeral configuration or local
configuration take precedence. The I2RS protocol MUST support this
mechanism.
Am I correct in my interpretation?
Joe
Sue
-----Original Message-----
From: Russ White [mailto:[email protected]]
Sent: Wednesday, July 20, 2016 2:09 AM
To: 'Joe Clarke'; 'Susan Hares'; [email protected]
Subject: RE: [i2rs] Comments on Ephemeral-REQ-07 (local config vs.
ephemeral)
(wg chair hat off) --
I think the idea of extending I2RS priority to local config operators
(e.g., CLI)
will still work. Let's take knob 1. Knob 1 is kind of like the
on/off
switch. If I
don't want I2RS to have any effect on operational state, I'd have
this
off. In
the I2RS priority case, by default my local config could will have
the
highest
priority (let's say that's 255 to make it concrete). In this case no
ephemeral
config can win.
I wanted to extend Joe's remarks a bit... On reflection, I actually
think having priority + "this wins" bits is rather confusing, and
opens the door to all sorts of strange behavior. Say I have two items
thus --
Local config item -- priority 100
I2RS config item -- priority 200, don't overwrite bit set
If the higher priority is supposed to win, then which item should the
operator find in the resulting running config? Should it be the I2RS
version, because the priority is higher, or the local config, because
the "don't overwrite" bit is set? There doesn't seem to be any clear
way to interpret such a situation.
It's better to have a single "thing" that determines which
configuration among many wins, rather than two.
-r
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
