Because the time required to support such a loop is too long to make this work useful in the control plane. We don't have seconds to compute and install an lfa, for instance, or to redirect a ddos stream to a cleaner
Further, if you think having "planes of configuration," is complex, wait until you try to troubleshoot a muiltistate instability problem with a several second loop time as multiple clients discover, then react to, what other clients are doing. No-one has a "full state set," hence there is no way to either understand what the state should be, or what parts are interacting. Bottom line -- you can either see the complexity for what it is and manage it, or you can try to throw it over the wall fir someone else to deal with. The second option doesn't really solve the complexity. In fact, it make the problem much worse. Being able to see the potential states in a single place is a crucial piece of the manageability puzzle here. Russ Sent from my Windows Phone -----Original Message----- From: "Joel M. Halpern" <[email protected]> Sent: 11/8/2015 12:15 PM To: "Andy Bierman" <[email protected]>; "Alia Atlas" <[email protected]> Cc: "Russ White" <[email protected]>; "[email protected]" <[email protected]>; "Susan Hares" <[email protected]> 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]>> 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
