Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!decwrl!ucbvax!GW.UMICH.EDU!hwb
From: hwb@GW.UMICH.EDU.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re: RFC986 questions
Message-ID: <8606120220.AA02623@ucbvax.Berkeley.EDU>
Date: Wed, 11-Jun-86 22:50:38 EDT
Article-I.D.: ucbvax.8606120220.AA02623
Posted: Wed Jun 11 22:50:38 1986
Date-Received: Thu, 12-Jun-86 03:21:04 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 37
Approved: tcp-ip@sri-nic.arpa

Let me make a few comments about some of the reasons behind RFC986. The 
question of mixing or not mixing protocols is an important one, though
not really, or at least only to some extend, the issue here.

What needs to be accomplished is that existing network backbones can
be utilized for ISO protocols, which includes the ISO CLNS. It
probably does not make too much sense to have, e.g., an Arpanet and an
ISO-Arpanet existing and being disjoint at the same time. Not even
on an iterim base.  It therefore becomes necessary to utilize existing
backbones (good examples here are the Arpanet and the upcoming NSFnet)
for both protocol suites, especially since these suites do not differ
that much from each other anyway.
 
RFC985 points out quite nicely that Ethernets are some kind of lowest
common denominator to which most hosts can connect. We can probably safely
assume that most gateways drop their traffic onto a local Ethernet.
If, e.g., two gateways, which are attached to the Arpanet would talk
both IP and the ISO-CLNS, while eventually utilizing the same routing
data base local to the gateway, people could talk the ISO-CLNS accross
the country. It would not matter at all what runs on top of ISOgrams
in this case. Further routing through subsequent gateways within the
local net would obviously be a local issue here. These (sub)gateways 
would have to understand both 'gram protocols, too, and, e.g., could
distinguish between them according to different Ethernet type fields
seen on the Ethernet.

RFC986 is a draft only and probably needs further refinements so that
and Internet standard could emerge which could be given to the implementors
of gateways. Suggestions for these refinements would be welcome.
 
A small committee chaired by Phil Gross (Mitre) was furthermore tasked
with coming up with suggestions for possible scenarios for RFC986, which
will (hopefully) result in a subsequent RFC. Input for this would be
appreciated, too.
 
	-- Hans-Werner
-------