IPv7 (CLNP) a mistake

Craig Partridge <craig@aland.bbn.com> Thu, 02 July 1992 23:12 UTC

Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa09135; 2 Jul 92 19:12 EDT
Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09131; 2 Jul 92 19:12 EDT
Received: from uu2.psi.com by NRI.Reston.VA.US id aa06844; 2 Jul 92 19:13 EDT
Received: from port10.mv.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA07627; Thu, 2 Jul 92 19:09:29 -0400
Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA28811; Thu, 2 Jul 92 16:08:29 PDT
Message-Id: <9207022308.AA28811@aland.bbn.com>
To: big-internet@munnari.oz.au, iab@isi.edu, iesg@NRI.Reston.VA.US, ietf@isi.edu, road@lanl.gov
Subject: IPv7 (CLNP) a mistake
Reply-To: Craig Partridge <craig@aland.bbn.com>
From: Craig Partridge <craig@aland.bbn.com>
Date: Thu, 02 Jul 1992 16:08:29 -0700
Sender: craig@aland.bbn.com

I've read the IAB announcement, RFC 1347 and the Internet Draft, and am
afraid I view this idea of adopting CLNP as IPv7 as a disasterous idea.

First, adopting CLNP means buying into the ISO standards process.
While the Kobe announcement states that choosing CLNP is "not choosing OSI,"
it is the case that we'd be choosing to make the network layer of the Internet
protocol suite the same as the OSI protocol suite.  As such, we have
to face the painful reality that any future changes that the Internet
community wishes to see in the network layer will require ISO approval too.
ISO and the Internet community have radically different views about
the standards making process (e.g. testing before standardizing, whether
to bill for standards, and the like).  Indeed, the Internet community
decided not to join up with ANSI/ISO a few years ago because both
communities felt there were incompatibilities in their processes.
Now we're proposing to buy into the ISO process to manage our network layer.
We'll all have to learn the detailed workings of the ISO process if
we want to change the network layer -- and since it requires some
number of meetings to be ANSI/ISO accredited, we'd better all start
attending those meetings now (in addition to our IETF meetings) so
we can be prepared to defend our ideas in the ISO process.  Do we
really want to pass much (all?) of our control over the Internet
network layer to a process that the Internet community finds
incompatible?

(I've heard at least one person suggest that if ISO doesn't like
Internet-proposed changes, we'll just publish our own version of CLNP.
Ignoring ISO copyright issues about issuing a modified ISO spec [which
may or may not prove to big deal], I don't buy this idea.  First, why
even call this new network layer CLNP unless we believe we mean to keep
in sync.  Second, having an Internet and an ISO CLNP means that vendors
will have to support two versions of CLNP, which they won't like.
Consider how much folks already complain about the different GOSIPs.
We'll find ourselves in a tremendous vise to harmonize with ISO.  We've
tried that twice before, with CMIP over TCP and IS-IS.  In one case,
the idea was a complete flop but only after a waste of some years of
effort.  In neither case was the process pleasant.  I don't think we
want more of these kinds of problems.).

Second, CLNP deals with only *one* of the several issues facing IP, namely
address depletion.  At the same time, it forces us to take a giant step
back on other issues.  CLNP does *not* support multicasting.  There
are proposals in the works to add it -- but that means CLNP is about five
years behind IP on this topic.  IP multicast is working now and it has
taken a lot of effort -- it is in products (Solaris 2.0) and in
BSD (4.4 and mods are available for 4.3).  We're making good progress
on mobile host support.  Some experimental implementations under
IP are getting heavy use.  We'll have to go back to the CLNP drawing
board on those projects too.  Ideas to support multimedia applications are
fast becoming reality (witness the recent IETF multicasts on the
Internet).  If we buy CLNP we'll have to wait a few years for ISO
to approve those extensions.  With the exception of a brief mentions
about leaving space for options and making sure that multicast will
somehow be supported, the various documents don't address this issue.

In short, CLNP as IPv7 seems destined to be a technical step backwards
and to place a severe crimp on protocol innovation at a time when we
need to innovate.  (Some folks have expressed concern that the rise in
voice and multimedia on the Internet will stress IP *this* year.  To my
knowledge, no one has tried running voice over CLNP).  Are we so sure
that we should choose CLNP with all its limitations, especially now that
CIDR gives us a bit of breathing room in which to think?  Are we so sure
CLNP is the right decision that we shouldn't even consider developing at
least one other approach in parallel, just in case we discover CLNP
really is a tar baby?

Craig