Joel, Andy, and Alia.
Due to a lengthy post-IETF illness, I am catching up on email threads (11/8 to 11/27). This message is a bit longer to respond to multiple threads. <WG chair hat on> The specific WG agreement was to focus the first release of the I2RS protocol on control loop with changes and errors. Our purpose in doing this was to get the I2RS simple protocol with the following: · netconf/restconf with configuration and query/response · secondary feeds (netconf pub/sub, netconf traceability, IPFIX, google protocol buffers), · protocol independent models (RIB, FB-RIB, and Topology models, and · initial protocol dependent modules. The WG’s goal was to enable useful applications to be built with these tools. Completing 2015’s work At IETF 94, I indicated that I2RS 2015-2016 would be wrapping up the initial set of documents(problem, architecture, problem statement, and I2RS protocol requirements) in December. I2RS will wrap up the initial protocol module drafts (RIB, Topology (RIB, Topology (L2 and L3) and FB-RIB) in December. Our goal in early 2016 is to get implementations of I2RS agents that support these protocol-independent modules. 2016 Approved New work In 2016, we will also review protocol specific I2RS modules and application drafts. 2016 Possible Work If individuals want to work on proposal to include backup/cache issues in a second I2RS protocol, I am willing to have a small group create such a proposal and initial concept drafts. Jeff, I and Alia and I would sit down with the individuals working and review their ideas. After the AD approves, we can bring to the WG as something that should go in the charter. After listening to Russ and Andy’s concerns, it is important to capture the operators input, protocol issues (NETCONF, RESTCONF and other protocols), and implementation issues. I’m interested in getting this discussions started now so that we can provide these early concepts as ideas to the I2RS protocol design team. <WG hat off> Thanks for all your thoughts and emails this last few weeks. Each email has helped me gain a larger understanding of the problem. Sue -----Original Message----- From: Joel M. Halpern [mailto:[email protected]] Sent: Sunday, November 08, 2015 12:16 PM To: Andy Bierman; Alia Atlas Cc: Russ White; [email protected]; Susan Hares Subject: Re: [i2rs] Conversation on Priority and Panes Aince the working group agreement and the request Alia is making is NOt to store backup / cache, but to use the control loop to deal with changes and errors, I do not follow what your comment 2 is raising? Yours, Joel On 11/8/15 11:51 AM, Andy Bierman wrote: > > > On Sun, Nov 8, 2015 at 6:36 AM, Alia Atlas <[email protected] > < <mailto:[email protected]> mailto:[email protected]>> wrote: > > Hi Russ & Andy, > > I certainly understand the desire for different behavior when a > priority override happens. > However, this is one area where the working group was extremely > clear. Sue and I had > ideas of store-if-not-best and handling overwrites and so on. There > was a very clear > push back against any such complexity. Feel free to take a read > through the archive. > > While it is tempting to expand the scope and functionality of I2RS > to handle this as not > an error, I would ask that we respect the WG consensus and get > agreement and implementations > going on the basics. > > We have a serious case of too many saying "This is an interesting > soup. Let's watch it." and > far too few people putting wood on the fire and experimenting. > ... > (2) what needs to happen in the client and server to make the backup > data active? > It concerns me that the implementations of proprietary I2RS use > caching instead of introducing a distributed control loop here. If > you think caching is hard, just wait until you try to get 10X - 100X > faster performance out of your notification system to implement a > tight control loop. There is complexity in both approaches. The > pub/sub work is brand new as well, so it will not be stable for > awhile. ...
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
