[rrg] BGP scaling limit?

[Danny McPherson]

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