North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Sprint filters (yes really)

  • From: Sean Doran
  • Date: Thu Jun 20 15:26:00 1996


Please note that the changes to Sprintlink's filtering
policies that Marc Hidalgo and I announced at NANOG have
been implemented, and should be visible as BGP sessions with
our external peers (MCI, ANS, Alternet, PSI et al.) reset
over time.

It is hoped that the changes won't be flawed, but any
oddities would be nice to know about.

The two and a half week delay in implementation is my own fault.

Note that the policy is now:

	[allow none of the RFC 1597 et succ. reserved addresses]
	in 0/8-126/8, allow no subnets of historical As
		      that were not announced in July 1995[*]
           127/8-191/8, allow nothing longer than /16 [*]
	   192/8-205/8, allow nothing longer than /24
	   206/8-223/8, allow nothing longer than /19
	   195/8 [RIPE block, 12 dec 95], allow nothing longer than /19
	[other RIPE and APNIC blocks that have begun
	being allocated from since July 1995 will also be
	filtered on the /19 boundary]

The principal change is that we used to disallow /19s in
207/8-223/8 and 195/8, and this was not in line with the minimal
allocation units performed by the three primary registries.

Please also note that we have also already accumulated
a couple of months of successful experience with
differential filtering, and will be both tightening up
the filtering in the newly unfiltered space and tweaking
the currently-used values up and down.

Very roughly speaking, the goal is that if you have a very
long prefix (like a /24), and it flaps a couple times, you
can go home for the day.  If you do even the slightest bit
of aggregation (into a /23, for example), then you are
much less likely to be dampened in the face of minor
flapping, and you will be dampened for less time.

Once you have aggregated enough addresses to comprise a
/18 or shorter prefix, you will be dampened with values 
very much in line with the default you get from Cisco's
"bgp dampening" command.

At the moment, you are much more likely to be dampened if
you are NOT a Sprint customer.  That is, the normal values
for "bgp dampening" are in place if you have a customer
connection to SprintLink or ICM.  However we will be
evaluating the engineering and operational effects that a
similar policy with respect to SprintLink customers,
as an effort to encourage some of our lazier customers
to begin doing their own aggregation wherever possible.

You may not be surprised that the success of this
differential dampening experimentation has played a large
role in the easing-up of our filtering policies.


Version: 2.6.2
Comment: PGP Public Key in

- - - - - - - - - - - - - - - - -