-----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-----