[46736] in North American Network Operators' Group
Re: [Q] BGP filtering policies
daemon@ATHENA.MIT.EDU (Henry Yen)
Tue Apr 9 16:29:07 2002
Message-ID: <20020409162829.C6099@nntp.AegisInfoSys.com>
Date: Tue, 9 Apr 2002 16:28:29 -0400
From: Henry Yen <henry@AegisInfoSys.com>
To: "Borchers, Mark" <mborchers@splitrock.net>, nanog@merit.edu
Mail-Followup-To: "Borchers, Mark" <mborchers@splitrock.net>,
nanog@merit.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <53B67F09399475429CA50ED0FC6FA6A77A931A@hsexch01.splitrock.net>; from Borchers, Mark on Tue, Apr 09, 2002 at 02:34:44AM -0500
Errors-To: owner-nanog-outgoing@merit.edu
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: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
