|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: CIDR Aggregation Tool
> Avi, > > While this is useful as a metric of the degree of aggregation, it is > not sufficient to configure aggregation. This is still useful as a > means to look at where improvement may be needed. Please don't get me > wrong in pointing out that there are limits to the applicability, this > *is* useful. I should have been much more specific. There was never any intent to suggest that this was a configuration-generator... Nor was there any intent to imply that certain providers are bad or remiss or misconfigured or underconfigured... The hope was that it might be useful as something to look at (a raw generator of aggregation-possibilities). Also, I was interested in seeing how many routes could be aggregated at one peering point (not inside a provider's network, but at one edge). For example, if the processing to compute the aggregations was low, and only aggregated entries were inserted into a cache (but the actual BGP announced more specific entries were kept in the routing table), perhaps that would help if route table and/or cache table size was/is still a problem. But it seems that the current generation of technology that is out there doesn't run into a SP-cache-size wall from either a switching-speed or memory angle. > You will find that while improvement is possible, and may still even > be fairly substantial, your figures represent an optimistic estimate. Agreed. [Suggestions re: IRR deleted for brevity.] Agreed re: the IRR as well. Next on the list is to examine the Merit tools. Sigh - my nanog notes were lost when my 200LX was stolen, but I know where to find the tools... > Thanks for the information. Thanks for the feedback. > Curtis Avi
|