RE: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure
/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 --------------------------------------------------------
Hi, On Mon, Jan 12, 2004 at 03:56:25PM -0000, Daniel Monteith wrote:
I am sure we are getting to the stage when route table size is not so much of an issue anymore.
Routing table size is more an issue than ever. 129k prefixes, LOTS of useless garbage, and still growing. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57882 (57753) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Agreed Gert, but we have about 65K by filtering on minalloc sizes ... André At 17:35 12.01.2004, Gert Doering wrote:
Hi,
On Mon, Jan 12, 2004 at 03:56:25PM -0000, Daniel Monteith wrote:
I am sure we are getting to the stage when route table size is not so much of an issue anymore.
Routing table size is more an issue than ever.
129k prefixes, LOTS of useless garbage, and still growing.
Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57882 (57753)
SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
-------------------------------------------------------- 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 --------------------------------------------------------
/24 if only
heck, why not /32?
I am sure we are getting to the stage when route table size is not so much of an issue anymore.
why are you sure, and for what values of "we"? randy, who is sad to be old enough that he's not sure of anything
----- Original Message ----- From: "Randy Bush" <randy@psg.com> To: "Daniel Monteith" <DanielMo@InterXion.com> Cc: <address-policy-wg@ripe.net> Sent: Monday, January 12, 2004 4:40 PM Subject: RE: [address-policy-wg] RIPE Access Policy Change Request to allow allocations to critical infrastructure
/24 if only
heck, why not /32?
Filtering on /32 shouldn't be a huge problem. I count 4 294 967 296 /32's. That's the upper limit and it's really not that much. If we did permit /32's, a router could for instance aggregate incoming chunks of matching netblocks into fewer ones in order to decrease workload and memory usage etc... Without thinking too hard, this number is also the same if we filter on /32 with IPv6. But we are talking about filtering on /48 these days so that's a bigger challenge. Permitting /32 would atleast solve the problem with anycast. Joergen Hovland
Randy and all, Randy Bush wrote:
/24 if only
heck, why not /32?
I am sure we are getting to the stage when route table size is not so much of an issue anymore.
why are you sure, and for what values of "we"?
randy, who is sad to be old enough that he's not sure of anything
I am sure as aging is a debilitating all of us will eventually face it's ravages, you will be wise enough to seriously consider retirement. Soon perhaps? Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== CEO/DIR. Internet Network Eng. SR. Eng. Network data security Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 214-244-4827 or 214-244-3801
participants (6)
-
Andre Chapuis -
Daniel Monteith -
Gert Doering -
Jeff Williams -
Jørgen Hovland -
Randy Bush