Re: oops -- wrong message

[Jeremy Porter <[e-mail]>]

>    There are SMP versions of UNIX available today from SUN, SCO and others 
>    that have enough power to handle route processing for the forseeable future
>
>I wasn't aware the SMP Unix had the capability to run a single process on
>multiple CPU's simultaneously, so it's not just a "plug it in and go"
>operation.
>
>Above and beyond that, even assuming we manage to split the routing up among
>several processors in the trivial way (i.e. have different processors to talk
>to different peers), now you've got several processors poking into the same
>database (to figure out who's got the best route to X), so you've got some
>"interesting" interlock issues. E.g. what % of data accesses are to shared
>data? What % of them will need to lock it? How much overhead will that lock
>take (and does your multiprocessor have hardware support for locking), etc,
>etc, etc.

This problem is well addressed in the industry.  Any modern SMP box
can handle this type of thing.  Plus its really not that hard of
an engineering effort.  With parallel solutions there would really
be very little difficulty in putting off the heat death of CIDR
by several years.  The Processing power difference and memory
utilization differences between a Cisco 7000 with a 68040) and
a 8 CPU 200mhz RISC processer SMP box is pretty high.

And even Non-SMP solutions just multiprocessing (which BTW is
what you are talking about with different peers on different CPUs).

This problem is really fairly well understood, and I don't feel
like spending 3 days explaining it again :-).  But seriously
MP and SMP solutions have been in production for years.
Even with doubling ever 4 months I don't see trouble designing
a tightly coupled or loosly couple MP/SMP machine(s) to handled
the groth for the next 3-4 years.  (two bad design cycles
are about 2 years.)

Picture a box with 20 CPU slots, currently it can handle
full load with one CPU, assuming about 80% effective utiliazation
of of SMP/MP techniques, you can withstande 4 doublings in
table growth/route-calculation/peering.  That gives us a routing
table size of something like 480,000 entries.

If growth can be slow to doubling every 12 months, this
gives us 4 years to get a radical change like IPV6
ready.

It seems pretty clear to me that there are hardware solutions
to handle the real problems of growth, but there does need
to be some effective work done to slow groth.

Three cases:
	1. multi-homing:  Internic should assign large enough
blocks for multi-homed sites for approximately 6month to 1 year
forcasts.  (i.e. each multi-homed site needs to only grow by
one CIDR block per 6 months/1 year).  This means fairly
huge allocations to large backbones.  Probably means
opening class A address space sooner.
	2. entropy of CIDR:  Major network providers should announce
a policy of non-portable address effective ASAP.  (There are
some people that may win some money by hearing me say that,
because a year ago, I would have told you of the EVILNESS
of non-portable addresses).  This means increased enginnering
costs for customers and backbones with gredards to support issues.
Also it means people like Sprint, PSI, should allow TEMPORARY
CIDR holes so that changes can be made slowly over a period of
30 days or so.
	3. Old space(/24 routes):  Audits MUST be conducted on utilization
of CIDR space by NSP, small ISPs, and by end customers, to
make sure good choices are made for allocation block sizes.
Some people would argue that if the Internic had allocated
correct sized blockes we might not be having such growth problems
with the table size.  However (this last assertion is just
my feeling based on the numbers present on big-internet).
Also allocations of /24s should be stopped.  If you are
design ing a new network, make a decision about providers
and get the allocation block.  Otherwise get a RFC1597
net and PLAN for renumbering.


I really don't see any solution to the charging for route
prefixs, althought it seems a reasonable model, because
people being what they are, would scream anti-trust
and be technical correct even if it was done to save
the net.  I don't see any techincal or polical solution
to this problem.





-- 
----------------------------------------------------------------------------
|  Jeremy Porter (512)-339-6094 Freeside Communications, Inc. [e-mail]  |
|  [e-mail]  (512)-339-4466 (data) P.O. Box 530264 Austin, TX 78753    |
----------------------------------------------------------------------------