Re: ipv6nd-02.txt & autoconfig

"Eric W. Gray" <gray@ctron.com> Mon, 13 May 1996 16:06 UTC

Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14490; 13 May 96 12:06 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14486; 13 May 96 12:06 EDT
Received: from guelah.nexen.com by CNRI.Reston.VA.US id aa09394; 13 May 96 12:06 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 MAA06282; Mon, 13 May 1996 12:06:47 -0400 (EDT)
Received: (from root@localhost) by maelstrom.nexen.com (8.7.3/8.7.3) id LAA28007 for ip-atm-out; Mon, 13 May 1996 11:58:32 -0400 (EDT)
Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id LAA27998 for <ip-atm@nexen.com>; Mon, 13 May 1996 11:58:29 -0400 (EDT)
Received: from gatekeeper.ctron.com (ctron.com [134.141.197.25]) by nexen.nexen.com (8.7.3/8.7.3) with SMTP id LAA14202 for <ip-atm@nexen.com>; Mon, 13 May 1996 11:58:27 -0400 (EDT)
Received: (from news@localhost) by gatekeeper.ctron.com (8.6.12/8.6.9) id LAA04481 for <ip-atm@nexen.com>; Mon, 13 May 1996 11:58:24 -0400
Received: from stealth.ctron.com(134.141.5.107) by gatekeeper via smap (V1.3mjr) id sma004438; Mon May 13 11:58:11 1996
Received: from olympus.ctron.com by stealth.ctron.com (4.1/SMI-4.1) id AA27410; Mon, 13 May 96 11:50:12 EDT
Received: from blarney (blarney.ctron.com [134.141.66.40]) by olympus.ctron.com (8.6.12/8.6.9) with ESMTP id LAA14974 for <ip-atm@nexen.com>; Mon, 13 May 1996 11:58:03 -0400
Received: from blarney by blarney via SMTP (940816.SGI.8.6.9/930416.SGI) id LAA06001; Mon, 13 May 1996 11:58:26 -0400
Message-Id: <31975C1E.7D55@ctron.com>
Date: Mon, 13 May 1996 11:58:22 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Eric W. Gray" <gray@ctron.com>
Organization: Cabletron Systems, Inc.
X-Mailer: Mozilla 2.0 (X11; I; IRIX 5.3 IP12)
Mime-Version: 1.0
To: IP-ATM Working Group <ip-atm@nexen.com>
Cc: Eric Gray <gray@ctron.com>
Subject: Re: ipv6nd-02.txt & autoconfig
References: <9605091659.AA07972@dogfish.zk3.dec.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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

This has somehow become a discussion of the use of SEL in ATM
addresses (doesn't follow from heading exactly).

	A little of what I've run into WRT the use of SEL.  It is up
to the end station how (and even if) this is used.  Therefore, unless
you somehow have control of a really large number of implementers, it
doesn't make (a lot of) sense to speculate on the philosophy of SEL 
usage.

	An application will want to use a different value for SEL any
time that it wants to register or advertise a service that requires a
unique ATM address - if the default SEL has already been used for that
purpose (with some other service).  That service might be support for 
multiple protocol specific addresses for any given protocol.  It might
also be for multiple service entities within the same protocol.

	An application might also want to use a different value for SEL
if it wants to avoid sticky situations that might arise as a result of
some clever user's efforts to re-use an existing connection rather than
establish a new one by forcing this user to treat the address as if it
were a completely different physical entity.

	In any case, SEL cannot be used unless the NIC (and its drivers)
allows an application to set/advertise its value (e.g. via calling party
address in setup and add party messages) and "register" to be notified
of incoming calls to that address.  Where-ever this capability exists,
however, philosophy will have little to do with its use.

--
Eric Gray