> 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." 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." 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. At least that's my 2c. :-) Russ _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
