# Optimal Route Aggregation Evaluation

Network providers should aggregate their route announcements to the greatest practical extent.It is accepted best practice that maximal aggregation of route announcements may not always be practical, so it is suggested that network providers should announce no more than (N * 2) + 3 prefixes, where N is the number of maximally aggregatable prefixes that could originate from the AS under ideal conditions.

There are two scenarios where prefixes can be aggregated.

Firstly:

- They have the same AS path
- They are adjacent
- They are of equal size
- They can be represented by a single new larger prefix which covers exactly the same address space as the two original prefixes.

In this case, the single new larger prefix is advertised, and the two original prefixes are withdrawn.

Or secondly:

- They have the same AS path
- One of the prefixes is larger than the other prefix
- The larger prefix includes the address space of the smaller prefix

In this case, the smaller prefix is withdrawn, and the larger prefix continues to be advertised. No new prefixes are advertised.

In order to determine maximal aggregation such prefixes shall be aggregated, and the criteria above applied again. This process shall be repeated until no further prefixes can be aggregated..

For network providers with large amounts of address space, for prefixes smaller than /16, deaggregates up to /16 are considered acceptable and all such announcements, for the purposes of the aggregation calculations, will be counted as one. For example, a Network provider with a /14 is able to announce this as 4 /16s and this is counted as 1 announcement.

These guidelines on aggregation should apply at all points of observation.

# Examples of aggregation calculations

**Example #1**

If you currently advertise the following prefixes from your ASN:

10.123.4.0/24

10.123.5.0/24

10.123.6.0/23

On the first aggregation pass, you could aggregate the first two prefixes into a single /23, leaving you with:

10.123.4.0/23

10.123.6.0/23

If you then aggregate again, you’ll be able to further aggregate these together into a single /22, leaving you with:

10.123.4.0/22

However, if you were advertising the following prefixes:

10.201.5.0/24

10.201.6.0/24

Then these are already aggregated as far as possible, as although they are consecutive, and it appears that they could be replaced with a single /23, the first prefix, 10.201.5.0/24 is not on a /23 boundary.

**Example #2**

If you currently advertise the following prefixes from your ASN 65000 (with AS paths in brackets):

10.10.0.0/16 (65002 65000 i)

10.10.4.0/23 (65001 65000 i)

10.10.10.0/24 (65002 65000 i)

If you compare the first and second prefixes, then they have different AS paths, so cannot be aggregated.

If you compare the first and third prefixes, then they have same AS path, and the third prefix (the /24) is already included in the address space of the first prefix (the /16), so the third prefix should not be advertised.

Therefore, after aggregation, you should be left with just the two prefixes advertised:

10.10.0.0/16 (65002 65000 i)

10.10.4.0/23 (65001 65000 i).

**Example #3**

Consider the prefixes announced from your ASN65000:

10.10.0.0/17 (65002 65000 i)

10.10.128.0/17 (65002 65000 i)

These two prefixes:

have the same AS path

are adjacent

are of equal size.

Therefore these two prefixes can be replaced by one single aggregated prefix:

10.10.0.0/16 (65002 65000 i)

**Links**

Geoff Huston’s Paper: Analyzing the Internet’s BGP Routing Table

RFC 2519

[last modified: 14-10-2006]