On Tue, Apr 09, 2002 at 02:34:44AM -0500, Borchers, Mark wrote: > http://www.arin.net/statistics/index.html#ipv4issued2002
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:[EMAIL PROTECTED]] > > 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
