<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? 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
