> 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
