On Jan 12, 2009, at 10:34 AM, Tony Li wrote:
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.
Well, so long as the folks designing the next generation
understand the problem and mitigate the constraints. I'm
not totally sure the former is the case, which has effects
on the latter.
BTW, AFAIK, route reflection _reduces_ the number of paths as
compared to
full-mesh IBGP. Am I missing something?
Depends on the number of RRs, where the best path
is, network architecture, etc.. The growth curves
I've seen (which I hope to be able to share soon)
illustrate that the number of iBGP paths is growing
at anywhere from 6-14x the rate of the DFZ, and
the reason is because of external factors, protocol
design issues, and implementations.
Paths that are introduced for the sake of traffic engineering are a
well
understood and self-inflicted problem.
Really? So a multi-homed AS is TE? So networks that interconnect
in 10 places result in 10 paths for each prefix and that's self-
inflicted? What's the alternative to avoiding this self-inflicted
pain?
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.
No, I'm not talking about just extraneous or covered prefixes,
that's only a tiny part of the problem I'm referring to.
Denseness of external interconnection, unique attributes,
BGP as defined today AND TE have effects on these, I'd say the
latter the least.
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.
I don't agree with this. Offer me an alternative for 10 or
more interconnections between the largest networks today?
Offer me an alternative for how those paths and the current
inter-domain routing protocol amplify (not minimize) the number
of paths.
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.
Again, TE is only a tiny part of the problem I'm referring
to here - fully dependent on ones definition of TE, of course.
-danny
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
