On Mon, Oct 6, 2014 at 9:32 AM, Jeffrey Haas <[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. 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
