[routing-wg]Routing Aggregation Policy

Hi folks,

Joao asked me to forward some background to an item that I will do on
Thursday.

This is the last draft of the defunct Route Aggregation Policy that was
formulated by the LINX Council/Members, before it was rejected as a
"policy" by the LINX General Meeting in August.

I took an action from the LINX Membership at that meeting to donate what we
had to the RIPE community for re-formulation into a best practice document.

I'll give you some more background during Thursday's WG meeting, but for
now, here's the draft itself, as it stood at the point of the rejection as
an enforced policy by the Membership:

---------------------------------------------------------------------------
Revised Route Aggregation Policy
--------------------------------
A LINX member shall 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.

Prefixes are aggregatable if:

   1. They have the same AS path
   2. They are adjacent
   3. They are of equal size and are 2**N in size where N is an integer
   4. They start on "power of two" boundaries
   5. After aggregation, the result starts on a "power of two" boundary

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.
This final number of prefixes  is the maximally aggregatable prefixes
announced from that AS.

In order to ensure neutrality and to guard against bias in the measurement,
announcements shall be observed at several locations, decided from time to
time by the LINX Council.

For those members with large amounts of address space, for prefixes smaller
than /16, deaggregates up to  /16 will be permitted without penalty and all
such announcements will be considered as one, for the  purposes of
calculating the metric. For example, a member with a /14 will be able to
announce this as 4  /16s and this will be counted as 1 announcement.

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.

----------------------------------------------------------------------------

Obviously, it will need re-drafting to be more BCP-like, rather than a
policy, and don't ask me what happened to Examples 2 and 3 ;).

Thanks,
Mike
-- 
Mike Hughes     Chief Technical Officer  London Internet Exchange
mike at linx.net   http://www.linx.net/
     "Only one thing in life is certain: init is Process #1"