/24 if only :) I believe currently its the LIR initial allocation boundary that's the minimum guaranteed not to be filtered. I would welcome a move by the ISP's (mainly a couple of tier 1's) to relax this so that BGP multihoming for the small people becomes easier and more efficient. I am sure we are getting to the stage when route table size is not so much of an issue anymore. Cheers Dan -----Original Message----- From: Andre Chapuis [mailto:chapuis@ip-plus.net] Sent: Monday, January 12, 2004 3:43 PM To: Daniel Karrenberg; address-policy-wg@ripe.net Subject: Re: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure Agreed, And what about defining an address-range where every ISP opens its filter up to /29 (as an example) ? This would deal with both anycast and address-space conservation. Let's show that we (as ISPs) are not bound to the /24 forever ! André At 10:23 12.01.2004, Daniel Karrenberg wrote:
This discussion is *not* about address policy, it really is about ** routing policy! ** The goal is to get prefixes propagated. They could live in any odd part of the address space!
Routing policy is made by ISPs. (period)
In order to provide hints to ISPs making such policy I have previolusly proposed a *registry* for "special" prefixes with some general categories like:
- root server - TLD server - second level name server - internet search engine - other important prefix (see remarks section ;-) - ....
Such a registry could be provided by the RIRs and used by the ISPs when defining and implementing their routing policy. The art here is to design the categories and to decide which ones can be policed. It is easy to determine and to check regularly if a prefix contains name servers for instance. Other categories should be "self-declaration". ISPs can then decide if and how to use such a registry.
Is this something that provides added value to ISPs? Is it something that is useful for those using such prefixes?
Daniel
PS: If getting any address space at all is a problem for these applications, this needs to be addressed. Maybe it is already addressed by adjusting the "initial" usage requirements back to "nil" or some reasonable low level and reducing the initial allocation size.
This is a different discussion which belongs here, but I do not reeally follow it anymore, so pardon me if I just assume it is moving along.
-------------------------------------------------------- Andre Chapuis IP+ Backbone Engineering AS3303 Swisscom Enterprise Solutions Ltd Genfergasse 14, CH-3050 Bern +41 31 893 89 61 chapuis@ip-plus.net CCIE #6023 --------------------------------------------------------