[1519] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Policy Statement on Address Space Allocations

daemon@ATHENA.MIT.EDU (Tim Bass (@NANOG-LIST))
Thu Jan 25 12:44:22 1996

From: Tim Bass (@NANOG-LIST) <nanog@dune.silkroad.com>
To: smd@sprint.net
Date: Thu, 25 Jan 1996 12:27:16 -0500 (EST)
Cc: Daniel.Karrenberg@ripe.net, nanog@merit.edu, forrestc@imach.com,
        cidrd@IEPG.ORG, iab@isi.edu, iesg@isi.edu, iana@isi.edu,
        local-ir@ripe.net, tli@cisco.com, bass@dune.silkroad.com
In-Reply-To: <96Jan25.082047-0000_est.20608+303@chops.icp.net> from "Sean Doran" at Jan 25, 96 08:20:23 am


Sean Doran says:

> Yah, yah, Daniel, it's a giant conspiracy against you and Tim Bass.

Since my name was mentioned by Sean without provocation, please allow
me to respond briefly:

------------------ the kind and compassionate reply ------------------


It interesting that as technologists and engineers, the current
climate in internetworking works with undertones of "don't ask 
questions, because to do so is a form of heresy" against the Internet.

I have spent (a few, not enough) days in the archives of Computer Networks,
the IEEE journals, and other peer reviewed papers on hierarchical routing;
and I have seen *zero* technical justification for "turning a blind-eye"
to other less problematic hierarchical routing architectures ( the CIRD,
BGP4 paradigm is problematic.... that is why this discussion is taking 
place as we know)  In fact, I have not found one reviewed paper in a journal
that compares and contrasts, stochastically, the pros and cons of
different hierarchical routing models.

Instead of emotional overtones and name calling,
isn't it prudent to examine all hierarchical routing paradigms,
generate stochastic models, and determine the optimal way to
perform hierarchical routing (and try to avoid problematic practical
issues as well, which BTW are important ).

Hierarchical routing *does not* necessarily translate to "the BGP4,
CIDR development path forever"; but for some reason that I cannot
explain (and that Sean quips to be "the conspiracy theory" by us
engineering skeptics and CIDR heretics) the "world" refuses to take any 
other hierarchical routing architectures seriously (and many
are plausible and feasible if implemented, someone just kindly
faxed me another one, BTW).

CIDR aggregation is a flawed paradigm for long term growth of
the global infrastructure (and most of the engineers seem to
roughly agree, IMO); yet we, as technologists, are driven by the
forces of commerce to "expand the Internet as fast as possible,
keep the growth curve high, grow, grow, grow" mantra; and 
accept that "we'll just have to be satisfied with band-aid,
"change the wings in flight" engineering.

.... ladies and gentlemen, we have exactly what we want..... high 
uncontrollable growth, backwards compatibility problems, forward
scaling problems, and the same old protocol development track and
engineers and technologist in disharmony.

If you study the technical development of the current track, there
is a "missing link" that begs to be explored.  It would be kind
of "those in the CIRD camp" not to label us engineering skeptics
who seek to understand "why" as 'heretics and conspiracy theorists'.
Personally, I am just interested in answering the question "why?"
without throwing stones or casting blame.


Thank you and kind regards,


Tim

postscript:

When this thead started, I was determined to stay on the sidelines,
and avoid such a wide audience; but since I was mentioned directly
in a reply, it seems appropriate to post a  short clarifiation, 
thank your for understanding.

+------------------------------------------------------------------------+
| Tim Bass                           |                                   |
| Principal Network Systems Engineer |  "Every decoding is another       |
| The Silk Road Group, Ltd.          |                     encoding.."   |
|                                    |                                   |
| http://www.silkroad.com/           |                 David Lodge       |
|                                    |				         |
+------------------------------------------------------------------------+








home help back first fref pref prev next nref lref last post