Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!husc6!bacchus!mit-eddie!ll-xn!ames!ucbcad!ucbvax!GATEWAY.MITRE.ORG!tsuchiya
From: tsuchiya@GATEWAY.MITRE.ORG
Newsgroups: mod.protocols.tcp-ip
Subject: (none)
Message-ID: <8703161949.AA25990@jupiter.mitre.org>
Date: Mon, 16-Mar-87 14:49:53 EST
Article-I.D.: jupiter.8703161949.AA25990
Posted: Mon Mar 16 14:49:53 1987
Date-Received: Tue, 17-Mar-87 04:13:23 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 52
Approved: tcp-ip@sri-nic.arpa

Amidst all of the flaming about the scope and applicability statements
of GOSIP, I would like to throw in a quick technical suggestion.

With regards to the NSAP Address formats.

I am concerned that the single format is too narrow.
It implies a single type of hierarchy (org.net.net-address)
which may or may not reflect organizations real routing structures.
For instance, what if an organization is physically seperated into
several locations.  Then either that organization must have several
organization ids (in which case it is no longer an organization id),
or they must split up their subnet ID field to reflect the seperate
locations.  Unfortunately, if manufacturers boxes are not able to
parse elements in the subnet ID field.................

Also, while GOSIP does let DoD define its own address space, there
is still a potential problem with economics.  What if 15 vendors
decide to implement GOSIP, and 10 of them set up their NSAP
parsing code and routing tables to look like what is in GOSIP.
Suddenly, if DoD people want their own address format, they must
either go to one of the leftover vendors (less "multi-vendor")
or have a special development from one or more of the 10 vendors.
Both ways cost dollars.

The real fear here, though, is future interoperability (what's that, right?).
It is concievable to me that static routing could be made to work
with dynamic routing if one were very careful how they did things.
However, I don't see how it could work if the dynamic routing
parsed their NSAP Addresses differently than the static routing
(or indeed, if two dynamic routing schemes parsed them differently).

What I have in mind is very simple, and is essentially the
ARPA subnet-addressing scheme applied to the full address.

Have the vendors set up their routing tables, routines, and
software that downloads tables into the routers so that
every entry in the table has a mask associated with it which
says "if the NSAP to be routed matches this routing table entry
after the mask is applied, then route this way".  There should
also be a second mask which tells where the SNPA is imbedded in the
NSAP, if there is one.  The NSAP structure in GOSIP could even be
the default if someone didn't wanted to get involved in defining
their own NSAP structure.

This is a very easy way to provide a lot of generality at a very
low cost.

By the way, this idea is very much in line with the ANSI X3S3.3
(network and transport layer) philosophy on addresses and routing.

Paul Tsuchiya
tsuchiya@mitre-gateway.arpa