> Re the metric 'problem', just to be more precise in what would be needed, > we are looking a metric that grows or decreases monotonically across the > whole network.
I assume you mean in the routing space, and not in the controller/client space, correct? In terms of a distributed protocol? So, you're saying the delay could use "metrics" between 11 and 20, while the bandwidth could use "metrics" between 21 and 30, etc? And then you just add them all together? That's what IS-IS has done for years... Even BGP really only has one "metric," with following "tie breakers..." So if you have something like weight/local pref/etc, such that they occupy different "spaces" in a bit pattern (something suggested, btw, in the original wide community work, and in other places, as well), you're actually just building a single metric. You've not "solved" the multiple metric problem -- just done something a little different than EIGRP's K values to combine them into a single metric, which is where you need to be to have the ability to build a single stable SPT/DAG. > The theoretical grounds for this are in T. Griffin’s and > Sobrinho’s work on BGP-4 and that lies already a couple of years ago and that > makes the analysis much ‘easier’ (no worries about np(complete) problems, > etc.). This could be applied in I2RS at the routing protocol level. So, we > could > discuss where that sits (should be the clients, right?) and I don’t know if > that’s been already done, since I’m quite new to this list. This doesn’t apply to the problem at hand, though... You seem to be saying (clarify if wrong) -- 1. Give each client some set of bits out of a 128 bit number space (or larger, etc.) 2. Each client can have different "metrics" within their own number space 3. When a client attempts to add some ephemeral state, they use a metric within their "space" 4. The agent can just use the straight number as a relative priority for each potential piece of state This doesn't do anything different than the current concept of priority between clients, only in the current plan each client only has one priority, rather than multiples. I don't see where this relates to the problem at hand. > Now, having “solved” that part of the equation :-) , the part that interests > me > more is the conflicting clients problem, because this could be generalised to > other problem spaces in the SDN area. I do agree that agents should be able > to catch offending state before installing it and I’m looking for ways to > specify > a minimal set of features that need to be supported at protocol level. > > Anyone else interested? This is precisely where the problem lies. And this is where you're going to hit the CAP theorem in full force. There are only a few choices -- 1. Make the database eventually consistent 2. Shut down accessibility during changes 3. ?? (1) is the idea of either having the agent call back to all the clients when state they installed is overwritten or allowing the agent to locally store some state where it already has the information in hand and install it locally -- the only real difference between these two solutions is the "balance of complexity versus speed..." The entire discussion here is how much additional complexity are we actually adding by doing "panes of glass," which are just locally stored state which isn't currently installed. I'm arguing that there's minimal complexity added that you're not already going to have in the system to allow the agent to store information locally _if_ it chooses to. Jeff is arguing (I think) that the "panes of glass" concept is a coherent way of looking at this problem that will help us understand and manage the complexity in a way that makes sense. Joel is arguing (I think) that this sort of solution is out of the WG charter, and it's too complex. I _think_ I have the three general perspectives right, but I don't know if I really have so... :-) (2) is the idea of locking the database while you're changing it. This is explicitly outside the scope of I2RS entirely, given we're trying to design something that's atomic/restful. There are a lot of techniques you can use to speed up locking -- row locking, sharding, etc. -- but none of these are interesting from the I2RS perspective. :-) Russ _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
