Re: A connection-based Internet?

Tim Bass <bass@linux.silkroad.com> Thu, 19 December 1996 20:03 UTC

Received: from cnri by ietf.org id aa13168; 19 Dec 96 15:03 EST
Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa18897; 19 Dec 96 15:02 EST
Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA04308; Fri, 20 Dec 1996 06:51:55 +1100
Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA04279; Fri, 20 Dec 1996 06:39:31 +1100
Received: from linux.silkroad.com by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id TA10916; Fri, 20 Dec 1996 06:39:23 +1100 (from bass@linux.silkroad.com)
Received: (from bass@localhost) by linux.silkroad.com (8.7.3/8.6.9) id OAA12464; Thu, 19 Dec 1996 14:38:59 -0500
From: Tim Bass <bass@linux.silkroad.com>
Message-Id: <199612191938.OAA12464@linux.silkroad.com>
Subject: Re: A connection-based Internet?
To: Greg Minshall <minshall@ipsilon.com>
Date: Thu, 19 Dec 1996 14:38:58 -0500 (EST)
Cc: jnc@ginger.lcs.mit.edu, huitema@bellcore.com, mo@uu.net, big-internet@munnari.oz.au, flows@research.ftp.com, jkr@netstar.com, tagswitch@cisco.com
In-Reply-To: <199612191758.JAA04528@red.ipsilon.com> from "Greg Minshall" at Dec 19, 96 09:58:29 am
X-Mailer: ELM [version 2.4 PL24 PGP2]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk


Noel laments:

> and NO real objective, open-minded, thoroughgoing, from-scratch analysis 
> of the engineering good and bad points of new approaches are made. 

> Instead, they are  dismissed with an immediate, simplistic, .....

Bravo!!

Then, Greg responds:

> ...  working code is much more persuasive!

Indeed, the Root of The Problem!  EGP was 'working code' however,
Eric himself stated EGP was NOT a valid routing protocol. Yet
BGP was built on EGPs 'working code'.  Then! many pointed
out BGP was certainly flawed, concentrating on manually
configurable 'routing policies' and a core topology, basically
a 'modified-spanning-tree paradigm'; yet the working code was the
foundation for the problematic IP exterior routing protocol
of today.  Let me remind everyone, the problem with scalability
&c was documented in RFCs in the early 1980s, almost 20 years
ago, yet modifying 'working code' based on a back-o-the-
envelope, quick-and-dirty 'working code' paradigm, dominated 
(and continues to dominate) the process.

The lesson learned might be thus:

-----------------------------------------------------------------
Working code is persuasive, but not necessary the best development
track! and certainly not the best design.
-----------------------------------------------------------------

Both Noel and Greg are both correct.  The IETF audaciously
prides itself on hacking 'working code' and avoiding the 
painful but necessary step of analysis and broad peer
review on important and far reaching  issues such as 
global exterior routing paradigms.

On the other 'business reality' hand...

If 'someone' aggressively advocates a new routing paradigm, 
aggressively without broad peer review, and does it with an
quiet eye toward a patent or financial gain; we shall just
see the distasteful process repeated for the second time.

We all agree it is not difficult to design a new,  truly
scalable, hierarchical protocol that works with meshed
ADs and does not provide tacit advantages of one provider
over another in the marketplace; however what is often
in the best interest of the marketplace is rarely in
the best interest of the established businesses with a 
very real interest in growing, not diminishing, market share
and revenue.

The IETF has never been immune to commercial influences and 
there is not a period in history where commerce did not
dominate the decision making process.  Let us not be
deceived in fancying an Internet dominated by spiritual
sages and selfless actions without the motive of profit.


Best Regards,

Tim

-- 
mailto:bass@silkroad.com          voice (703) 222-4243
http://www.silkroad.com/            fax (703) 222-7320