RE: [Q] BGP filtering policies
If you'll look at this pointer to one of ARIN's pages, it lists the minimum allocation size for each CIDR block that IANA has given ARIN to manage. From what I've seen, most providers accept at least up to the prefix length that the RIR's are using, if not longer. http://www.arin.net/statistics/index.html#ipv4issued2002 Unfortunately, this doesn't help in your case. My company also has /14's from the traditional class A space. I know of only one case in two years where a customer reported a problem arising from holding a small assignment out of these blocks, which was ultimately corrected by renumbering the customer, a solution which does not scale well. Worst case, however, unless your UUNet connection goes down, you'll still be able to reach most places via your other transit and peering (since /24 is the closest thing to a "universal" allowed prefix length) and will have full reachability via UUNet. IMHO, accepting up to /24 in any of the space listed on the above URL is good service provider practice.
-----Original Message----- From: Henry Yen [mailto:henry@AegisInfoSys.com] Sent: Tuesday, April 09, 2002 2:11 PM To: nanog@merit.edu Subject: [Q] BGP filtering policies
We were recently assigned a /22 from UUNet in conjunction with some transit we're buying from them. The space is inside their superblock, 65.242.0.0/14. We are concerned that our route announcement of this block would be filtered out by some other providers, as it's not class C/swamp space (or even class B space for that matter). Verio's current policy, for one, indicates that this would be so.
This is of particular concern to us as our little network encompasses several physical partially-meshed locations, with a mix of varying bandwidths both upstream as well as intra-location. Traffic Engineering is what we think is a reasonable (business) approach to address our flexibility needs, and so we're trying to move to address space(s) that would be least likely to be BGP filtered.
We've asked for a different block from UUNet but the request didn't meet with success; UUNet suggested that any problems encountered as a result of this allocation could probably solved by e-mailing any NSP whose traffic interchange with us might be negatively affected (unlikely, to be sure, but still...), and would then change their filter (I'm unconvinced of this scenario).
I briefly browsed the NANOG archives, and didn't see this issue discussed recently. Have the BGP filtering policies for "most" ISP/NSP's been relaxed to the level of "accept /24's from class A (ARIN-allocated) space"? Am I mis-reading Verio's posted policy? Is there anyone from UUNet who might choose to comment? Is there something else I'm misunderstanding?
-- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York
On Tue, Apr 09, 2002 at 02:34:44AM -0500, Borchers, Mark wrote:
The CIDR section is the part you're referring to? http://www.arin.net/statistics/index.html#cidr which indicates /20.
Unfortunately, this doesn't help in your case. My company also has /14's from the traditional class A space. I know of only one case in two years where a customer reported a problem arising from holding a small assignment out of these blocks, which was ultimately corrected by renumbering the customer, a solution which does not scale well.
I don't exactly anticipate this ever happening. My observation is that the scaling will happen in the router area, i.e. as more and more smaller blocks get announced out of the class A/class B space, the ability of routers to hold more routes will tend to relax the typical filtering policies as time goes on. In other words, by the time we might encounter a problem, it'll no longer be a problem. Your comment about renumbering is most apropos; if it's not a problem for uunet to assign in swamp space now (i.e. "pre-renumbering"), then this also disappears as an issue later.
Worst case, however, unless your UUNet connection goes down, you'll
It happens more frequently than you might expect.
still be able to reach most places via your other transit and peering (since /24 is the closest thing to a "universal" allowed prefix length) and will have full reachability via UUNet. IMHO, accepting up to /24 in any of the space listed on the above URL is good service provider practice.
-----Original Message----- From: Henry Yen [mailto:henry@AegisInfoSys.com] Sent: Tuesday, April 09, 2002 2:11 PM Subject: [Q] BGP filtering policies
We were recently assigned a /22 from UUNet in conjunction with some transit we're buying from them. The space is inside their superblock, 65.242.0.0/14. We are concerned that our route announcement of this block would be filtered out by some other providers, as it's not class C/swamp space (or even class B space for that matter). Verio's current policy, for one, indicates that this would be so.
This is of particular concern to us as our little network encompasses several physical partially-meshed locations, with a mix of varying bandwidths both upstream as well as intra-location. Traffic Engineering is what we think is a reasonable (business) approach to address our flexibility needs, and so we're trying to move to address space(s) that would be least likely to be BGP filtered.
We've asked for a different block from UUNet but the request didn't meet with success; UUNet suggested that any problems encountered as a result of this allocation could probably solved by e-mailing any NSP whose traffic interchange with us might be negatively affected (unlikely, to be sure, but still...), and would then change their filter (I'm unconvinced of this scenario).
I briefly browsed the NANOG archives, and didn't see this issue discussed recently. Have the BGP filtering policies for "most" ISP/NSP's been relaxed to the level of "accept /24's from class A (ARIN-allocated) space"? Am I mis-reading Verio's posted policy? Is there anyone from UUNet who might choose to comment? Is there something else I'm misunderstanding?
-- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York
On Tue, Apr 09, 2002, Henry Yen wrote:
I don't exactly anticipate this ever happening. My observation is that the scaling will happen in the router area, i.e. as more and more smaller blocks get announced out of the class A/class B space, the ability of routers to hold more routes will tend to relax the typical filtering policies as time goes on. In other words, by the time we might encounter a problem, it'll no longer be a problem.
<topic mode=rant> Back when routers had small (relatively) small CPUs and (relatively) small amounts of RAM I'd say that the filtering (and other nice things such as flap dampening) was coined to stop these poor little routers from dying. But nowdays, routers have lots of CPU and lots of RAM. Somehow people equate this to "can hold/munge larger routing tables". Well, thats partly true. You've (practically) removed CPU and routing from the table, but the speed of light is still the same, and the routing protocols are still the same - so now what you'll be seeing is that "stability" is actually a function of your network characteristics _and_ router, rather than it mainly being the router. Transmitting 100,000 routes still takes time. Even if your time to parse and store your packet is 0, you'll still at least have the route fill delay (how long it takes for routing information to travel from your peer to you) and route propagation delay (how long it takes for your route to appear all over the internet.) Since those aren't 0, they can add up - and no amount of router CPU or router memory is going to (soley) fix it. </topic> 2c, take with some salt, etc. adrian -- Adrian Chadd "For a sucessful technology, reality must <adrian@creative.net.au> take precedence over public relations, for nature cannot be fooled" - Feynmann
On Wed, Apr 10, 2002 at 07:44:31AM +0800, Adrian Chadd wrote:
I don't exactly anticipate this ever happening. My observation is that the scaling will happen in the router area, i.e. as more and more smaller blocks get announced out of the class A/class B space, the ability of routers to hold more routes will tend to relax the typical filtering policies as time goes on. In other words, by the time we might encounter a problem, it'll no longer be a problem.
Back when routers had small (relatively) small CPUs and (relatively) small amounts of RAM I'd say that the filtering (and other nice things such as flap dampening) was coined to stop these poor little routers from dying.
But nowdays, routers have lots of CPU and lots of RAM. Somehow people equate this to "can hold/munge larger routing tables".
Speak for yourself. I think routers are hidiously under equipped with CPU and RAM, and that which you can upgrade is still sold by the vendors at insane prices the like of which you can only find in the blissful stupor of ignorant customers. There are two areas which limit the number of routes you can support. The first is the longest prefix match lookup system, which must do an increased amount of work on every packet. This has largely been eliminated in "modern" routers, through the use of specialized hardware and/or the use of an mtrie based FIB (like CEF) which uses a fixed size forwarding table and makes all lookups nearly equal in cost regardless of the number of routes (the only thing that could make this situation more difficult is more address space, like IPv6). The second is the routing protocols the the infrastructure necessary to support them. This is where you start bloating your memory usage and convergence time, which is DIRECTLY related to, you guessed it, both the lack of RAM and CPU resources, and the oh so crappy code that the vendors write. This is the area that "filter nazi's" (hi Randy) care about, not because more routes is really harmful to the internet, but because it impacts the memory usage and convergence times of their networks. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
participants (4)
-
Adrian Chadd -
Borchers, Mark -
Henry Yen -
Richard A Steenbergen