Hi Russ, I would think that the most bang for the buck is to start with defining an interface to C. As you point out, messing with A is probably not a good place to start. Changes at B, D & E will likely occur much less frequently than C, and probably infrequently enough to be handled via configuration -- I2RS interfaces for these could probably come as a phase-2. C would seem to be where the most activity will be and the best place to start working. Just 2 cents from the audience.
Best regards, Aldrin On Feb 26, 2013, at 2:07 PM, Russ White wrote: > >> 1) We are (sooner or later, assuming we succeed) going to also be >> manipulating many other properties that are not shown (Queues, marking, >> firewalls, ... > > One thing at a time... :-) > >> 2) I think it is important to show processes, because I think that there >> is significant confusion as to which processes are the consumers of what >> information. > > I've redone the diagram to account for some of the comments so far... > Attached, and also at: > > http://riw.us/temp/router%20model.jpg > > - I've tried to show the difference between a policy, a local database, > and a process in this version. I don't know if it's clear, but hopefully > it is. > > - A is the direct injection of information to a routing process, without > using the "front door," through what appears to be to the routing > process a peering mechanism. > > - B is the policy the routing process uses to influence which routes are > presented to the RIB process. > > - C is an interface to the RIB process that looks, to the RIB process, > like any other routing process (whether local or remote). > > - D is the set of filters or policies the RIB uses to determine which > routes to insert in its local database, such as route filters. There > might need to be a similar point of insertion before the local database > of each routing protocol to represent route filters and such, as well. > > - E is the set of policies the RIB uses to choose among the routes in > its local database to the FIB. I'm primarily thinking of administrative > distance here, but there might be others. > > I would argue I2RS shouldn't be inserting stuff at A. I don't know of a > use case to insert stuff at C, but that could be because I'm not > imaginative enough (the only policy I know of here is administrative > distance, and I can't imagine someone want to make it so the > administrative distance is somehow reversed!). > > Is this better? Am I missing other parts? What about a policy cloud > within the routing process before the local database? Once we get this > piece sorted, I'll be glad to start adding pieces for interfaces to > interfaces. > > :-) > > Russ > <router model.jpg>_______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
