Hi Danny, |> I know that the internal tables are always a pain, but since |we have |> to deal |> with the global issues, the internal, private growth (self- |> inflicted ;-) has |> to necessarily be out of scope for RRG. | |That's quite odd to me, considering by today's definitions |"internal [BGP] tables" are where the routing scalability and |stability are it's worst - today, and unquestionably, the first |place things will break IF/WHEN they do, as a result of an |inter-domain routing protocol architecture that forces either |full-mesh or hierarchies such as route reflection that themselves |introduce additional paths and state in the network (even with |implicit aggregation effects).
As you point out, this is more to do with the specific protocol than it is to do with the overall routing architecture. As such, this is why it's really much more of the domain of IDR than RRG. BTW, AFAIK, route reflection _reduces_ the number of paths as compared to full-mesh IBGP. Am I missing something? |And they're not going to break because of a 100k unique |internal-only routes, they're going to break because of |an order or magnitude or more paths (and all of their overhead) |- paths introduced as a result of "global issues" and solutions |that focus on solely minimizing DFZ size, rather than looking |at where the problem is actually worst - today. Paths that are introduced for the sake of traffic engineering are a well understood and self-inflicted problem. If those folks that introduced the extra paths took equivalent interest in limiting their dispersion and cooperated in filtering unnecessary long prefixes, this could readily be addressed. In short, this is not an issue with the fundamental architecture, it's about how the architecture is being used. Thus, this is largely an operational issue. Further, if we did something to fundamentally remove the capability to traffic engineer in the future, I strongly suspect that that would be an architectural issue, most likely fatal. Regards, Tony _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
