I think we strongly agree that we want t inject non-protocol specific
routing information at C rather tan D. Is it consistent with your model
to think of C as talking to the RIB manager?
Yours,
Joel
On 2/26/2013 1:30 PM, Russ White wrote:
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
