>Well, you're going to love this article. They increased the number of
>networks in the core of the Internet by 25 fold to do their BGP table
>capacity test!?
The "number of routes in the core" is not a simple number, and
they've presumably made some simplifying assumptions. As part of the
draft I'm working on, we are coming up with some ways of estimating
the load.
Let's say the number of routes in a default-free table is D.
Actually, this number will vary depending on where you measure it --
the weekly CIDR reports probe routers in Tokyo and London, and come
up with slightly different sizes.
In a large provider, you also have customer routes that are
aggregated at the edges, as well as infrastructure routes. Our
working number for the number of routes a large provider's internal
number is on the order of 1.3 to 1.5 D.
Another consideration is the number of paths per route. In other
words, how many potential paths are there from which BGP will select
one (not even beginning to get into complex policies). An informal
rule of thumb is that there average 4 paths per route.
The number of routes in the DFZ has returned to exponential growth.
I don't have a current growth curve in front of me, but when the CIDR
measures were instituted in 1991, the table was doubling every 5 to 9
months. A factor of 25 seems a little high, but, pessimistically,
doubling every 5 months would stretch us out about two years.
Historically, router capacity doubles about every 18 months.
A substantial amount of this growth, incidentally, appears to be from
more-specifics being injected for multihoming and traffic control,
rather than completely new address space. It's a real matter of
concern, because such injection is counter to the CIDR model. The
existing routing system was never really designed to support
fine-grained multihoming, and there are no short term alternatives
that won't annoy significant numbers of organizations.
>
>Nonetheless, it's a very interesting and well-written article and set of
>tests, Please do let us know what you think after reading it in detail and
>talking to the author.
>
>Thanks.
>
>Priscilla
>
>At 10:03 PM 3/12/01, Howard C. Berkowitz wrote:
>> >Hi, please have a look this site
>> >
>> >http://www.lightreading.com/testing/
>> >
>> >Have you any comment about this ? Let's us know your opinion.
>> >
>> >Thanx
>> >Si Pitung
>>
>>
>>Just started looking at it tonight. I will be speaking with its
>>author at the IETF meeting next week. I would think long and hard
>>before I'd claim any router is the "best" core router. Individual
>>numbers can be misleading.
>>
>>I have a draft out on single-router BGP convergence time,
>>http://www.isi.edu/internet-drafts/draft-berkowitz-bgpcon-00.txt. It
>>is fairly rough, but starts talking about the interactions of
>>multiple parameters. Unfortunately, the appendix giving various ISP
>>applications for BGP routers isn't in that draft, but will be in the
>>next one.
>>
>>It's misleading to think that all ISP routers need to be "core."
>>Arguably, the highest-bandwidth "core" routers inside an ISP may not
>>need to run full BGP, but have more stringent demands on OSPF, ISIS,
>>and/or MPLS. Think of RFC 2547 "P" routers.
>>
>>An ISP POP access router might have the greatest number of BGP routes
>>and paths, but not as much bandwidth requirements. If the POP router
>>primarily deals with customers, it will advertise only default and
>>partial routes to many of them. Only a small proportion of customers
>>want full routes. A POP router will also generally accept only a
>>small number of routes from customers.
>>
>>Interprovider routers at tier 1 are unlikely to need to exchange full
>>routes Such routers are bandwidth-intense, but the definition of a
>>tier 1 is that you exchange only customer routes (perhaps
>>oversimplifying, but that's close) with other tier 1 providers.
>>
>>A revised draft will be presented at the IETF next week to the
>>benchmarking methodology (BMWG) and inter-domain routing (IDR,
> >responsible for BGP). This draft is coauthored by Alvaro Retana at
>>Cisco, and Sue Hares and Padma Krishnaswamy at NextHop (the former
>>GateD organization, which is the base for quite a number of
>>implementations). Hopefully, we will also get a Juniper coauthor.
>>The plan is that it will become a BMWG working group document in the
>>standards track (well, as much as standards track applies to
>>performance measurement documents, a subtlety of the IETF process).
>>
>>--
>>"What Problem are you trying to solve?"
>>***send Cisco questions to the list, so all can benefit -- not
>>directly to me***
>>
>>Howard C. Berkowitz [EMAIL PROTECTED]
>>Technical Director, CertificationZone.com
>>Senior Mgr. IP Protocols & Algorithms, Advanced Technology Investments,
>> NortelNetworks (for ID only) but Cisco stockholder!
>>"retired" Certified Cisco Systems Instructor (CID) #93005
>>
>>_________________________________
>>FAQ, list archives, and subscription info:
>>http://www.groupstudy.com/list/cisco.html
>>Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
>
>
>________________________
>
>Priscilla Oppenheimer
>http://www.priscilla.com
>
>_________________________________
>FAQ, list archives, and subscription info:
>http://www.groupstudy.com/list/cisco.html
>Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
