Re: [RADIR] FWD: Re: Please review: draft-narten-radir-problem-statement-01.txt

> I still believe this document needs an entire section
> devoted to iBGP implications.  I.e., the fact that if there's
> indeed a problem the first place things are going to
> break is going to be in the iBGP core of the most densely
> connected networks.
> 
> The reason it's going to break there first is because of the
> richness of interconnection, both external (e.g., section 5.1)
> and internal, and perhaps more importantly, as a result of
> architectural constraints imposed by internal BGP routing
> architectures that result in anywhere from 2 to 20x the
> number of BGP paths in the internal BGP routers as opposed
> to PE devices.
> 
> There are network topology and routing architecture
> considerations, as well as protocol modifications (e.g.,
> route reflection advertisement rule sets) that can have a
> considerable impact on both churn and scale internally
> as well.
> 
> Ignoring this entirely in the document, when it's clearly
> where the most pain exists today, isn't reasonable.

My initial reaction to this is that iBGP topology considerations are an
ISP-internal matter (that's the "i" in "iBGP").

Increased iBGP complexity, just like increased cost of adding security to
the routing system (Danny's other pet peeve) is a consequence of ever-
increasing global routing system state. Adding a prargaph to the end of the
document that points out that conclusion seems like a reasonable way to
address this and other concerns.

	--Vince
_______________________________________________
RADIR mailing list
RADIR@ietf.org
https://www.ietf.org/mailman/listinfo/radir