Date: Sat, 29 Sep 2001 14:58:09 -0400 (EDT) From: Paul Schultz <pschultz@pschultz.com>
if you have 64.x.x.x/15, slice it into as many /20's as you can and bloat as much as you want.. we feel this is an acceptable practice. Yet, if you're a legitimately multihomed customer wants to push out a single /24 (1 AS, 1 prefix) that is not considered acceptable.
Right.
The only kind of prefix filtering I would want to implement is something that can accomplish:
[ snip ] An interesting thought. Group BGP adverts / table updates by prefix length... get connectivity up and going, then chew on the smaller details as needed. Sort of like real-time process priorities; if you can get there, queue longer prefixes until _after_ all others have been processed.
This way I could get rid of redundant information yet at the same time not cause any trouble to smaller multihomed customers. I'm not saying that we should allow /32's to be pushed everywhere either. As you said there has to be a limit, and /24 seems to be a pretty good one if something along the lines of the above mentioned filtering algorithm could be used.
Seems to me that "saving the Internet" means strict ingress filtering[1] of downstreams and strict egress filtering[2] to peers and upstreams... which is pretty much the opposite of what Verio does. [1] Providers SHOULD filter/aggregate downstream routes, unless there's some overriding reason not to. There's enough bad BGP that trusting Joe Provider to do things right scares me. (I'm no <insert favorite NANOG routing superhuman guru> myself, but at least I know enough to speak decent BGP and to "tune" things.) [2] Want to tune inbound traffic? Fine... advertise those longer prefixes to your upstreams/peers. But don't make the rest of the Internet suffer. Communities good. Extra routes bad.
I'm sure in reality there's many reasons this would not be able to be implemented (CPU load perhaps) but it would atleast do something more than a "gross hack" that nails some offenders, not all by any means, and impacts multihomed customers who are only a portion of the problem that the current prefix filtering solution does not solve.
Filter/aggregate as close to origination as possible. "Be conservative in what you send, and liberal in what you receive." Haven't I heard that somewhere before? (Bonus points for anyone who can name the RFC without wimping out and using a search like yours truly alas had to do.) Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --------------------------------------------------------------------------- Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.