[routing-wg]Routing Aggregation Policy

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

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