Re: [Q] BGP filtering policies

[Henry Yen <henry () AegisInfoSys com>]

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