North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Verio Peering Question
> Date: Sat, 29 Sep 2001 14:58:09 -0400 (EDT) > From: Paul Schultz <[email protected]> > 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 <[email protected]> To: [email protected] 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 <[email protected]>, or you are likely to be blocked.
|