On Sun, Nov 8, 2015 at 6:36 AM, Alia Atlas <[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. > > It's hard to get a protocol built here just by throwing requirements over the wall. Standards track documents should be past the experimentation stage (although that is far too common in the IETF). There should be multiple vendors saying "This is how we solved this problem. Use our solution." There are several distinct problems here. (1) what is an edit overlap? This is actually a hard problem. Obviously duplicates of running datastore instances overlap, but not so obvious are the shared ancestor nodes or data model specific interactions between disjoint objects. This needs to be solved even if there was only 1 client, because running and ephemeral datastores can overlap. (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. A workaround is to implement a single client, which itself is a broker, and handles all the caching. It will try to delete the old data and add the backup in 1 step. The alternative will be around 1 sec. latency to install the backup. Regards, > Alia > Andy > > On Thu, Nov 5, 2015 at 12:57 PM, Andy Bierman <[email protected]> wrote: > >> >> >> On Thu, Nov 5, 2015 at 12:10 AM, Russ White <[email protected]> wrote: >> >>> >>> > First, is the case of two I2RS clients modifying the same "thing" >>> > something we consider normal and desirable, or is it an error. The >>> earlier >>> > discussions was that it is an error. In discussing the many different >>> kinds of >>> > direct and indirect collateral issues that arise, we concluded that we >>> could >>> > not expect the I2RS agent to be able to determine the "right" thing to >>> do >>> in >>> > the general case. >>> >>> So, assume the following -- >>> >>> 1. A local BGP process installs a route, 10.1.1.0/24 via 192.168.100.1 >>> 2. In order to move traffic off a "hot link" in a fabric, a >>> client/controller installs a route, 10.1.1.0/24 via 192.168.200.1 >>> 3. An attack vector is detected in a flow destined to some host on >>> 10.1.1.0/24 that causes a separate client/controller to install a route, >>> 10.1.1.0/24 via 192.168.150.1 for five seconds >>> >>> If I were the operator who owned this network, I wouldn't call this an >>> "error." I would call this "normal operation," -- in fact, the ability >>> to do >>> the above would be the very reason I would deploy I2RS on the network in >>> the >>> first place. Further, I would expect the entire process to unwind >>> properly >>> and _quickly_. I don't care how it happens, I just want the removal of >>> the >>> second client's route to leave the first client's in the table as the >>> current route, and the removal of the first client's path leave the BGP >>> route as the best path. To go farther, why are there client priorities at >>> all if this is an "error?" If all overwrites of "ephemeral state" are an >>> error, the agent should simply reject any attempt to overwrite any such >>> state. >>> >>> >> >> I agree that a priority override is not an error. In a multi-client >> environment, >> client A is not going to know about the other clients added to the system. >> This is true whether the clients are primary or secondary behind a broker. >> >> The notification to a client that some or all of its data was just >> overridden >> is a separate matter from whether the client wants all or part of its >> data to be removed or altered. >> >> One proposal to the design team is the notion that the server >> supports an advertised (static) number of clients (max client panes). >> Each client must be assigned a priority, such that every client >> has its own pane, so adding a valid edit does not fail. Activating >> the edit is a separate matter. Each client can flush all or part of its >> own pane. >> >> >> :-) >>> >>> Russ >>> >>> >> >> Andy >> >> >> _______________________________________________ >> i2rs mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/i2rs >> >> >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
