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

On Mar 10, 2008, at 3:14 PM, Jason Schiller wrote:
>
> As far as solutions go, I believe we tried to avoid that topic in this
> draft.  I do agree that people should carefully consider the impact  
> of a
> given BGP architecture on their network, and that part of the solution
> space might include carefully crafting a network.s BGP architecture to
> meet requirements while minimizing path explosion.
>
> However, on the other hand, I think it would be unreasonable to expect
> that people could construct networks where the route-reflection  
> routing
> domains or sub-ASes are sufficiently small to prevent multi-homing,  
> have
> entry points that are equally good for all destinations, and number  
> all
> static customers out of a unique subnet for each routing
> domain.  Furthermore, each pair of routing domains will be  
> aggregated by a
> pair of routers, such that for N routing domains, there will be (the
> square root of N) + 1 levels of hierarchy.

Yes, I'm aware of all the above.

In addition, where things like network design have direct implications
on scale of the routing system, from which internal BGP speakers higher
in the hierarchy have 10-20x the number of paths that PE devices do, be
they as a result of RRs within a cluster with unique cluster IDs,  
client-client
reflection as opposed to fully meshed client groups, implementations  
that
model overly liberal specifications that distribute extraneous data  
(e.g.,
RR spec updates), effects of memory, CPU and other churn because of
suboptimal update packing (e.g., from extraneous transitive attributes),
and basic iBGP route operation itself.

Ignoring this and concerning ourselves only with what functions external
entities impose on a local routing domain is disingenuous, in particular
when this is the place where things are going to break first - NO DOUBT,
hardware, CPU, memory, churn, IO, etc. are most gated, and the only
place operators have any actual control today.

> While I beleive security is an important requirement for any routing
> protocol, I think these issues may be out of the strict scope of  
> defining
> the routing and address problem wrt the RIB and FIB size issues.

I'm not sure we agree on this, given the insecurities in today's
routing system that are oft deferred "because the routing system
is to large or to complex".  In particular, add SIDR, IRR-generated
inter-provider policy and other solutions to the mix, much less
Transport Layer security for BGP, with KMART, or TCPAO, or
MD5, and then there's soBGP, SBGP and the like.  Deployment,
or lack thereof, and applicability of all of these relates directly to
routing scalability.

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