Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: utzoo!decvax!ucbvax!tcp-ip
From: Mathis@SRI-KL.ARPA
Newsgroups: mod.protocols.tcp-ip
Subject: (none)
Message-ID: <8512131806.AA22622@ucbvax.berkeley.edu>
Date: Fri, 13-Dec-85 12:35:33 EST
Article-I.D.: ucbvax.8512131806.AA22622
Posted: Fri Dec 13 12:35:33 1985
Date-Received: Fri, 13-Dec-85 20:57:50 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 37
Approved: tcp-ip@sri-nic.arpa

Dave,
   (Flame on -- better put on your fire suit)

   Of course you have chairman's perogative, but I would hate to see
the gateway task force bogged down by what, in the short term, is such
a truely operational concern that the people involved (both DCA and
BBN) should be embarrassed that this issue has surfaced and we (as
users) should be concerned that no solution has been forthcoming.
   Where is this great INOC that BBN requires implementers to discover
that the routing table is full; where is the butterfly gateway to save
us, and where is the management controls that let any random site fill
up the MILNET (core) gateways with networks without DCA approval.  On
this last point, I don't mean that DCA should "bless" every network
before it can be put on the internet; but in a situation of scare
resources (table slots) some management direction must be supplied for
the good of the MILNET/ARPANET community.  Besides, filling up a gateways
routing table with bogus networks is a great way to attack a network
(hope the Russians don't have EGP yet).
   I'm sure some back-pressure could reduce the number of networks.
(For example, SRI has 3 class-B Ethernets.  Early on, the reason for 3
Ethernet cables in the same building were political & traffic density
concerns; in retrospect we could survive with 1 network number if
appropriate back-pressure had been applied.)  If all the people that
have asked for network numbers gets their acts together and buy
gateways, the core will be in big problems.
   The main issues appear to be proper technical guidance and
operational management; for that we need the "fire fighting" task
force with proper funding and not the GADS which survives by skimming
money from research contracts.  I don't even know what more the GADS
or the IAB can do; the direction has been clear: build/install more
capable gateways (butterflys), improve the routing algorithms (SPF and
son of GGP) and implement subnets.  The GADS should spend its limited
time and energies on new internet architectures.

with 20/20 hindsight and apologies to the unjustly roasted,
Jim
-------