Re: ipv6nd-02.txt & autoconfig

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Fri, 10 May 1996 02:15 UTC

Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28499; 9 May 96 22:15 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa28495; 9 May 96 22:15 EDT
Received: from guelah.nexen.com by CNRI.Reston.VA.US id aa19143; 9 May 96 22:15 EDT
Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id WAA20856; Thu, 9 May 1996 22:09:09 -0400 (EDT)
Received: (from root@localhost) by maelstrom.nexen.com (8.7.3/8.7.3) id WAA16329 for ip-atm-out; Thu, 9 May 1996 22:00:24 -0400 (EDT)
Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id WAA16320 for <ip-atm@nexen.com>; Thu, 9 May 1996 22:00:20 -0400 (EDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id VAA20811 for <ip-atm@nexen.com>; Thu, 9 May 1996 21:59:34 -0400 (EDT)
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-Id: <199605100147.KAA14070@necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA14070; Fri, 10 May 1996 10:47:03 +0900
Subject: Re: ipv6nd-02.txt & autoconfig
To: Grenville Armitage <gja@bellcore.com>
Date: Fri, 10 May 1996 10:47:02 -0000
Cc: manfredi@engr05.comsys.rockwell.com, gja@bellcore.com, ip-atm@nexen.com, gja@thumper.bellcore.com
In-Reply-To: <199605091817.OAA20030@thumper.bellcore.com>; from "Grenville Armitage" at May 9, 96 2:17 pm
X-Mailer: ELM [version 2.3 PL11]
X-Orig-Sender: owner-ip-atm@nexen.com
Precedence: bulk
X-Info: Submissions to ip-atm@nexen.com
X-Info: [Un]Subscribe requests to majordomo@nexen.com
X-Info: Archives via http://cell-relay.indiana.edu/cell-relay/archives/IPATM/IPATM.html

Gja;

> Such an elegant argument for flattening the NSAPA addressing space
> is unexpected. By not allowing the SEL to be used during
> call SETUP at the ATM level, you're mandating that different logical
> entities layered over a physical ATM NIC _must_ use different ESIs.

What?

By mandating different logical entities (applications?) use
different SEL bytes, we can have only 256 different logical
entities per a host.

But 256 is not large enough.

Different logical entities layered over a physical ATM NIC should
be allowed to use the same ESI and different VPI/VCIs.

And then, for obvious merits of simplicity, there is no reason not
to mandate that different applications over a physical ATM NIC
_must_ use the same ESI.

> That sounds like flattening a perfectly good hierachy.

If you think OSI hierarchy is perfectly good, use it with native
ATM. Rest of us who use IP will flatten unnecessarily hierarchies.

						Masataka Ohta