max. prefix length

Fri Apr 26 21:31:42 UTC 1996

-----BEGIN PGP SIGNED MESSAGE-----

> >Is there a consensus on the maximum network prefix length that can be accepted
> >for announcement between full-routing BGp speakers ?
> 
> I would think it would be a /1, although I admit I've not actually
> tried it.  :-)

Is there a consensus on what _can_ be accepted?  Well, probably not.

Depending on where you're connected and what you're trying
to accomplish, there may be practical limits to the
usefulness of certain prefix lengths.

Technically, anything between a /0 (which, Paul, would be
the minimum length ;> ) and a /32 is supported by BGP4.

Most large networks won't accept a /0 (which is the ultimate
default); some of our peers filter out anything shorter than a /8.

A number of large networks, including Sprint and MCI,
filter out anything longer than 24 bits.  I suspect that
if someone started announcing significant numbers of /32s
(host routes), we would see more such filtering.

A number of networks do no filtering at all.

Sprint currently filters announcements from its
non-customers as follows:

	in the classical "A" space: accept nothing longer than /8   [*]
	in the classical "B" space: accept nothing longer than /16
	in newer "C" space:
		in 206/8: accept nothing longer than /19
		in 207/8 - 223/8: accept nothing longer than /18 [*]
		in 194/8: accept nothing longer than /18 [*]

(The things tagged with [*] are "soft"-ish policies.  When
technical ways emerge that will let us relax our filters
to a degree (in the "C" space, to come more in-line with
the registries' windowed allocation schemes; in "A" space,
to allow very large subnets, like /12s in the "A" space
perhaps), then we may do so.

One of the things under test now is progressive dampening
penalties across the entire address space.  The idea is
that the longer an unstable prefix happens to be, the
longer it will be suppressed when it regains stability.

Right now, in the initial testing, we're penalizing /24s
such that if three flaps occur in 45 minutes, we suppress
the unstable /24 for three hours after it becomes stable
again.  

All other prefixes, including /23s, are suppressed for
much less time (the shorter the prefix, the less
"aggressively" dampened).  The general idea is to make it
worthwhile for people to consider doing aggregation even
as simple as coalescing neighbouring /24s into a /23, or
to renumber into an more aggregatable block, unless your
announcement is _very_ stable.)

	Sean.

P.S.: There are a depressing number of prefixes (some 25
	or so, ALL of them /24s) that behave like these
	two.  Please, folks, run BGP dampening code on your routers.

SL-MAE-E>sh ip bgp 198.68.161.0
BGP routing table entry for 198.68.161.0/24, version 138091
Paths: (3 available, best #3)
  3830 4388 3703, (suppressed due to dampening)
    192.41.177.170 from 192.41.177.170 (204.157.228.1)
      Origin incomplete, metric 1, localpref 90, valid, external
      Dampinfo: penalty 6296, flapped 958 times in 17:20:54, reuse in 04:14:00

SL-MAE-E>sh ip bgp 198.184.184.0
BGP routing table entry for 198.184.184.0/24, version 737871
Paths: (1 available, no best path, advertised over EBGP)
  690 1321 2386, (suppressed due to dampening)
    192.41.177.140 from 192.41.177.140 (140.222.147.62)
      Origin incomplete, metric 1, localpref 90, valid, external
      Dampinfo: penalty 6288, flapped 405 times in 08:08:01, reuse in 04:14:00

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: PGP Public Key in ftp://ftp.sprintlink.net/engineer/smd/pgpkey

iQCVAwUBMYFAtESWYarrFs6xAQEBIAP/ejJNi7QOv+rUbnmcAVloFM40DJpsjg+P
Fw8xDof+4jjVO4Iv7J5V/uqgzKdY1Xt/oi8L+mLH3TeF4o5D/Go274xP+rUfiUcU
NAahWl/lt0RMSVYQENQ8nVXOTBwGsJ98F6gSWbVm9SYiGq5fiIG4Y0H7l8FT4b9v
XibRTwlHtl0=
=VdrR
-----END PGP SIGNATURE-----