Inline with EO# From: i2rs [mailto:[email protected]] On Behalf Of Alia Atlas Sent: Monday, October 06, 2014 11:02 AM To: Jeffrey Haas Cc: [email protected]; Juergen Schoenwaelder; Andy Bierman Subject: Re: [i2rs] Why do we need a datastore?
On Mon, Oct 6, 2014 at 9:32 AM, Jeffrey Haas <[email protected]<mailto:[email protected]>> wrote: On Fri, Oct 03, 2014 at 05:43:27PM -0400, Alia Atlas wrote: > Now - if we have to decide that the CLI always wins, that is one option. > I, personally, would be quite opposed to the idea that I2RS would always > win. That does not give recovery mechanisms to the operators when and > if something goes wrong. So, what is your proposal to allow CLI/local config to win over ephemeral state? If not something comparable to "option 4", what then? Jeff, It's a good question. I have been sweeping it under "implementation-specific" since it is up to an implementation to decide what collides. If we were talking about vendor-specific CLI vs. YANG models for I2RS, how would it work? At the end of the day, there has to be understanding of what internally is impacted. EO# If there isn’t some commonality or some way to control this then it becomes a nightmare for operators. I have to teach my tools that different platforms need different care and feeding upon restart. Can we at least have some 2119-style MUSTs for default and a well-structured flag for any config which deviates from that default? I can picture different abstractions or subsets being exposed for I2RS rather than CLI or NetConf-for-config. I do go more towards Russ's idea of I2RS as a routing protocol that cooperates with the other routing protocols rather than just another name for a management protocol. Regards, Alia -- Jeff
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
