Verio Peering Question

Sat Sep 29 19:42:52 UTC 2001

> Date: Sat, 29 Sep 2001 14:58:09 -0400 (EDT)
> From: Paul Schultz <pschultz at 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 at brics.com>
To: blacklist at 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 at brics.com>, or you are likely to be blocked.