On 7/18/16 13:39, Susan Hares wrote:
Joe:
We discussed "treating "local config" (e.g., CLI changes) as an I2RS client
with its own I2RS priority" in order so that priority concept can resolve
conflict. REQ-07 is a bit broader because we tagged this to the two "Knobs"
that section 6.3.1 described. (see below) in the IETF architecture
document. If you think the priority concept can provide the support for
the two switches and use case below, could you describe it on the list.
The architecture uses the term "overwrite," but I think at least in some
cases we mean, "overlay." Anyway, I'll explain using the architecture
terms.
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.
When I turn I2RS "on", the priority of local config drops to the lowest
priority (let's say 1, again to be concrete).
Okay, that's knob 1.
Now in the case of knob 2, I want to allow local config to win
sometimes. In the example in the architecture, I may want to overwrite
ephemeral config every night at 11 pm. In this case, I can increase the
priority of local config to be higher than the last ephemeral I2RS
client write, thus overwriting that change.
Again, this allows local config to behave like an I2RS client respective
to the priority.
Joe
Your point is the last remaining point.
Sue
===============================
Section 6.3.1
=============
The policy settings in the architecture is:
Knob 1: Ephemeral configuration overwrites Local Configuration.
Knob 2: Update of Local Configuration value supersedes and
overwrites the ephemeral configuration.
Existence Updates
Policy Knob 1 Policy Knob 2
Situation
=================== ==================
Router A ephemeral has ephemeral has
Ephemeral is active
priority priority .
Router B Local Configuration Local Configuration
Ephemeral is recorded in Agent,
has priority has priority
but not used. Can be turned on by
turning knob 1 to "ephemeral has priority".
Router C ephemeral has priority Local Configuration
Nightly configuration overwrite
Ephemeral.
-----Original Message-----
From: i2rs [mailto:[email protected]] On Behalf Of Joe Clarke
Sent: Monday, July 18, 2016 10:08 AM
To: [email protected]
Subject: [i2rs] Comments on Ephemeral-REQ-07 (local config vs. ephemeral)
As I stated at the mic today, I think the way REQ-07 is written is a bit
broad. This was evidently the intent, but I have a proposal.
Can we not treat "local config" (e.g., CLI changes) as an I2RS client with
its own I2RS priority? If all players (I2RS and local config) play with the
same priority concept, then one can easily control what gets precedence.
For example, if I want to temporarily overlay ephemeral-provided changes
with local config, I could increase the local config priority. When I'm
done with that, I set the priority back. By default, the local config
priority would be the lowest value to allow for ephemeral changes to take
precedence.
I do not think this will have a negative impact on topology as I have read
it, but if this doesn't make sense in some use cases, the priority could be
ignored.
Hopefully I've described this well so that it makes sense.
Joe
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
