How would you enforce a policy like this (Other than peer pressure)?

-----Original Message----- From: routing-wg-admin@ripe.net [mailto:routing-wg-admin@ripe.net] On Behalf Of Mike Hughes Sent: Wednesday, October 12, 2005 12:29 AM To: routing-wg@ripe.net Subject: [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@linx.net http://www.linx.net/ "Only one thing in life is certain: init is Process #1"