Russ, Thanks for the clarifications. I am still a little fuzzy about what you mean by "...B to represent modifications to the policy the routing process uses to choose which route to present to the RIB." To use an example from BGP, maybe this could mean configuring an inbound prefix list or other type of policy filter. If so, then B is an interface to change the configuration of the routing protocol rather than the data (e.g., Adj-RIB-In contents), right? Of course, this type of configuration change affects not only what the protocol sends to the RIB, but may also affect what the protocol readvertises to its neighbors.
A link state routing protocol probably has a lot fewer "policies" one might tweek, if I'm understanding this right. Rob > -----Original Message----- > From: Russ White [mailto:[email protected]] > Sent: Tuesday, February 26, 2013 1:31 PM > To: Rob (William) Rice > Cc: [email protected] > Subject: Re: [i2rs] Router Models > > > 1. Within your Routing Process boxes, I think what you mean by "A" > > is the injection of the same type of raw data the routing process > > receives from normal protocol neighbor (e.g., LSAs for OSPF, > > paths/NLRI for BGP). By "B," I think you mean injecting items that > > are the product of the routing protocol's processing of this raw > > data (i.e., protocol-specific routes). Am I understanding you > > correctly on this? "B" is not a modification to the routing protocol > > logic itself, is it? Would it be clearer to have another box below > > the Policy cloud to represent the set of routes the protocol > > computes, with the Policy cloud representing the internal protocol > > logic that transforms the input data into routes? > > I'm using A to represent information put into the routing process like > a > peer running the same routing protocol would put information into that > routing process, and B to represent modifications to the policy the > routing process uses to choose which route to present to the RIB. > > B is not a modification to the actual algorithm the process uses to > select the best paths --that would be really, really bad. :-) > > I would argue that putting information directly into the OSPF LSA > database -- for instance, modifying a type 1 LSA to include a link that > wasn't advertised by the originator of that type 1 LSA -- would also be > "bad juju." Once you start messing with the internal data structures of > algorithms and protocols which count on the consistency and accuracy of > those data structures to make accurate and timely decisions, you're > someplace you really don't want to be. > > > 2. Does the RIB in your diagram include all routes from all sources > > or just best routes (those to be used for forwarding)? > > All the routes from all sources. The RIB would select which routes to > present to the FIB based on it's internal policy (such as admin > distance). Perhaps the "policy cloud" should really be below the RIB, > between the RIB and the FIB. > > > 3. Is the policy cloud hovering above the RIB box applying whatever > > rules the implementation uses (e.g., admin distance) to select best > > routes? Maybe also rules for filtering routes accepted from various > > sources? I'm trying to understand the difference between "C" and > > "D." > > Yes... > > > 4. Can you clarify why you think injecting at "D" is "bad juju"? > > Presumably, "D" says "x is the best route to destination N, > > regardless of anything anyone else says"? > > This is bad, IMHO, because it's mixing local policy with remote policy > in a way that's not obvious to an engineering examining the local > forwarding table, and because it bypasses the normal checks that > prevent > the formation of routing loops, unreachable next hops, overwriting > connected routes, and other things of that sort. > > If you want a route to be installed "no matter what other process > think," then the preference on the route (the "administrative > distance"), should be set to cause this particular route to be > installed > instead of any route presented by another process, within the rule set > allowed by the local RIB process. > > In general, I think overriding the internal algorithms and policies > implemented by protocols and processes is a "bad thing." We should > strive to work with and through those internal algorithms and policies, > not around them. > > :-) > > Russ > > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
