Also, the report based on ASN tends to miss JVNC etc... which can be aggregated by their transit provider at the peering/exchange locations.

Oops. I meant to say "the report based on next-hop", not "the report based on ASN". Sorry... Avi

Perhaps this is just a small error that has to be accepted in your measurements, but we are dual homed and require both the aggregate and the specific.

...

2) When an AS advertises both an aggregate and a specific, the specific is 'dropped' by the aggregator. If the input is: {205.89.10.128/17, 205.89.10.130}, the output will be: {205.89.10.128/17} (205.89.10.130 will be dropped).

The 205.88.10.128 was a random example. I hope that's not you :) There are no "value" judgements made by the tool - it's just suggesting aggregates. And if we see an aggregate and a specific, both set to the same next-hop, it's quite likely that it's the same AS announcing both routes, and that they (your transit provider(s)) could do the aggregation themselves - but the tool *is* deficient in that right now it doesn't consider AS-paths. As an example, picking an IP for branch.com (198.111.253.37): Our route table has: *> 198.111.252.0 192.41.177.145 <--- agis *> 198.111.252.0/22 192.41.177.181 <--- mci *> 198.111.253.0 192.41.177.145 <--- agis *> 198.111.255.0 192.41.177.145 <--- agis So if 198.111.252/23 is suggested as an aggregate for the 192.41.177.145 (AGIS) target, that's because it looks like AGIS could in fact announce 198.111.22.0/23 instead of 198.111.252/0 and 198.111.253.0. Avi

[Please take any other responses just to cidrd. This is copied to big-inet and nanog so people will see the followup request. I just wanted the announcement to go out maximally, but the details and responses are of no interet to nanog as a whole...]

...

Our route table has: *> 198.111.252.0 192.41.177.145 <--- agis *> 198.111.252.0/22 192.41.177.181 <--- mci *> 198.111.253.0 192.41.177.145 <--- agis *> 198.111.255.0 192.41.177.145 <--- agis

This isn't what agis is supposed to be announcing, I'll have to ask them again to announce 198.111.252/22. There's a couple less routes already :-).

Once that is fixed, further aggregation of 198.111.252.0 (say into 198.111/16, as a non real example) would change our routing (in ways we don't want it changed), even with your "next hop the same" criteria because of the additional meaning that specifics have in terms of priority.

Well, we only see 198.111.252, 253, and 255 from AGIS, so there's no danger of AGIS over-aggregating even if they combined 252 & 253...

I agree that your tool is usefull in identifying _potential_ savings.

That's all it's for. Avi

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

In message <m0tK97D-000Nj7C@aero.branch.com>, Jon Zeeff writes:

I wouldn't mind if aggregation was done automatically unless the route was specifically registered somewhere as being a "don't aggregate" route. In other words, let people indicate if it wasn't a mistake.

...

load splitting across providers (usually load split by AS path filtering or more simply by AS path length). There is no way to tell a mistake from this being done intentionally.

A glance at the IRR is all it takes to find a dual homed site and determined that even though primary connectivity is through the same path as the aggregate an alternate path goes through another path. The answer there is often to aggregate anyway and pass the dual homed exceptions as explicit component routes. Problems can arise if there is no aut-num object for the AS in question, or the object is not accurate, or the routes in question don't have their own AS and are not registered correctly. Of course, if you can't be bothered registering in the IRR correctly, you have to accept the consequences. In the context of ANS's scheme after determining that something could be aggregated we would mark the aggregate with the community ANSAGGREGATE and the components with the community ANSCOMPONENTS. The rest is (not yet deployed, and not quite completely coded) magic. The aggregate would be formed in the next config run. There is also plan to use ANSPROXYAGGR and ANSPROXYCOMP but marking other peoples route objects (the components of a proxy aggregate) with a community is a hard thing to do if not in the maintainer list for the object. Curtis

Curtis Villamizar (curtis@ans.net) on November 27:

[lots deleted] Another way of estimating what can be aggregated is by determining from how many places all of the components of an aggregate could be heard in all backup situations. In some cases it might be reasonable to drop some degree of alternate connectivity (fourth or fifth preferred paths) and allow a number of holes (specifically aggregated components). In principle this could be done algorithmically using the IRR. In practice, you need to check with some of the parties involved to make sure registered information (particialrly aut-num AS peerings) are accurate beforehand.

Using the IRR you (or we) can select candidates for aggregation and then make sure the aggregation can really be asfely done. This is a little different in than you estimate in that it the viewpoint is what can we aggregate, rather than what might we see better aggregated in the future. The bgp paths at major interconnects could form a useful sanity check, making sure that AS paths do not conflict with IRR AS peering information for any candidate for aggregation. [lots deleted]

Actually we are working on such a tool, that we call CIDR assistant. A pre-alpha release of this tool will be available before/during the IETF, and there will be a discussion of this tool in the RPS wg. This tool considers the topology and the policies registered in the IRR before suggesting potential aggregations. The amount of policy/topology that is considered is configurable. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California http://www.isi.edu/div7/people/cengiz