On Fri, Aug 16, 2013 at 08:44:43AM -0400, Russ White wrote: > > > register for a notification when state written by client X is changed > > register for a notification when a particular state is changed > > notify when route is installed in FIB > > notify if interface utilization is over high-water threshold or under > low- > > water threshold > > The problem, I think, is that we're still not scoped narrowly enough. This > could well be a set of requirements for a network management system as much > as a set of requirements for an SDN... If we're going to be a new management > system, should we move this WG to the management area, and be done with it? > I think we need to be a little careful about what problems we take on from > day one, so we can really narrow down the work we're actually trying to do, > verses what others are already doing --I don't think we should make our > goal, "we want to be a faster NETCONF." > > So, to limit these: > > 1. So long as the state being written is _routing_ state. > 2. So long as the state being changed is _routing_ state. > 3. This must include when your route is overwritten by another process. > 4. Do we really want to consider everything measurable about an interface a > part of the "routing system," from day one? > > The fourth one is particularly bothersome. I can see where interface state > is part of the "routing state," in some broad sense --in reality, though, > everything that goes on on a "router" or a "switch" is technically part of > the "routing state," including memory fragmentation, memory utilization, > local storage read and write speeds, processor temperature, and even the > color of the box. These things are "routers" and "switches," so everything > they do somehow relates to either "routing" or "switching."
Russ, I do not see same the problem you do. Getting high-resolution, bulk statistics off of network nodes with minimal impact to the nodes is required for SDN, and I2RS is a subset of SDN. We do not have a method for doing that today. > > Hence, we need to intentionally underclaim in our scope for the moment, > focusing on a few small areas. We tried to do this with the use cases, but > that's not working so well, so maybe we need to limit our scope in more > intentional ways, like saying, "while we understand that interface state > other than simple up/down can be construed as part of the routing system, > we're simply not going to deal with that right now, because just dealing > with up/down, in combination with all the other stuff we're trying to deal > with, is enough to chew on for about the next 5 years already." > I am willing to propose a use case and draft a framework for generic bulk data collection. I do agree with taking bite-sized chunks; comparing the complexity of reading data off of network nodes and writing data to them, reading is substantially easier and it would be good to get that experience under our belt. It may help inform a decision if the two directions even need separate protocols. Rather than try and specify each and every thing we think is appropriate or necessary for I2RS to advertise, I would instead go with an approach like: - a standardized way for network nodes to publish what they have available - a standardized way for subscribers to select from that list - a method to negotiate both formatting and transport > If we don't intentionally scope ourselves, we're going to end up in the > drink --a WG that simply churns on lots of big plans, but won't ever be > actually implemented in any useful way, because no-one is going to build yet > another network management system into their boxes alongside the fourteen or > fifteen they already have. I am, it's in progress. And rather than make blanket statements one way or the other maybe we should get some operator input. Perhaps they have fifteen NMSes because the IETF has failed to give them a decent solution, and SDN is only going to exacerbate that. -Scott > > At least that's my 2c. > > :-) > > Russ > > > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
