Russ FYI
I understand that you sent an e-mail to the list with an attached diagram but, if so, it was way over the limit that trips my spam filters so I never got it. The archive strips attachments so there is nothing there. I accessed the URI you gave and downloaded 500kbyte which displays as 28x30 pixels of not very much. I note that it starts with ÿØÿà ... .Adobe... Exif whereas a jpeg usually starts with ÿØÿà ... JFIF There is a Lot to be Said for ASCII Art. Tom Petch ----- Original Message ----- From: "Russ White" <[email protected]> To: "Rob (William) Rice" <[email protected]> Cc: <[email protected]> Sent: Tuesday, February 26, 2013 6:30 PM > > 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 > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
