Verio Peering Question

Sat Sep 29 20:09:26 UTC 2001

> Date: 29 Sep 2001 12:39:27 -0700
> From: Paul Vixie <vixie at vix.com>

[ snip ]

> anyone who wants the point of equilibrium to move in the
> direction of "more routes" should be attacking the economies

"More routes" is too simplistic, at least for the "near
future".  "A greater number of useful routes" is what I think
people are supporting.

Given your point about many companies wanting to multihome, I
agree that we can easily exceed 1M routes.  See suggestion #3
below.

Of course, there are screwballs such as someone who comes to mind
who _claims_ OC-48 connectivity (not colo's bandwidth, but their
own OC-48 line)... yet is single-homed.  Supposedly they are so
happy with their upstream that they have no desire to multihome.
Frankly, I'd rather have tons of OC-3 to diverse backbones, but
my point is that not everyone wants to multihome.

How many _should_ want to?  Most everyone.  How _many_ do?  I
don't have the answer.

> which give rise to the problem rather than attacking the
> engineering solutions which are the best current known answer
> to the problem.  in other words go tell cisco/juniper/whomever
> your cool idea for a new routing protocol / route processing
> engine / cheap OC768-capable backplane and maybe they'll hire
> you to build it for them.

1. PI microallocations (e.g. /24) aligned on /19 (for example)
   boundaries.  Need more space?  Grow the subnet.  One advert
   because IP space is contiguous.

   Cost:  Change of policy at RIRs.

2. Responsibility for spam finds it way to the originating
   network.  Why not filtering and aggregation?  (No flame wars
   please... mention of spam is an analogy, not a desire to
   bring back certain flame wars after such a short while.)

   Cost:  Individual responsibility and interacting with adjacent
   ASNs.

3. I'd suggest merging "best" routes according to next-hop, but
   the CPU load would probably be a snag.  Flapping would
   definitely be a PITA, as it would involve agg/de-agg of
   netblocks.  Maybe have a waiting period before agg/de-agg when
   a route changes... after said wait (which should be longer
   than the amount of time required to damp said route), proceed
   with netblock consolidation.

   I'm mulling some refinements to this, which I'll bring up if
   the discussion takes off.  (Good idea, bad idea, flame war, I
   really don't care... if we eventually make progress, that's
   what counts.)

   Cost:  Anyone care to estimate the resources required? Any
   good algorithms for merging subnets?

Feel free to flame me for any oversights.  <excuse>I'm attempting
to multitask</excuse> and am well aware that I may have omitted
something.

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.