Re: Comments on ipv6nd-02.txt

bgleeson@cisco.com Sat, 11 May 1996 00:33 UTC

Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28777; 10 May 96 20:33 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa28773; 10 May 96 20:33 EDT
Received: from guelah.nexen.com by CNRI.Reston.VA.US id aa19034; 10 May 96 20:33 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 UAA29783; Fri, 10 May 1996 20:26:46 -0400 (EDT)
Received: (from root@localhost) by maelstrom.nexen.com (8.7.3/8.7.3) id UAA04569 for ip-atm-out; Fri, 10 May 1996 20:20:41 -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 UAA04560 for <ip-atm@nexen.com>; Fri, 10 May 1996 20:20:38 -0400 (EDT)
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: bgleeson@cisco.com
Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.31]) by guelah.nexen.com (8.7.3/8.7.3) with SMTP id UAA29717 for <ip-atm@nexen.com>; Fri, 10 May 1996 20:20:34 -0400 (EDT)
Received: from bgleeson-ss20.cisco.com (bgleeson-ss20.cisco.com [171.69.193.208]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with ESMTP id RAA12347; Fri, 10 May 1996 17:23:24 -0700
Received: (bgleeson@localhost) by bgleeson-ss20.cisco.com (8.6.8+c/CISCO.WS.1.1) id RAA13554; Fri, 10 May 1996 17:20:24 -0700
Date: Fri, 10 May 1996 17:20:24 -0700
Message-Id: <199605110020.RAA13554@bgleeson-ss20.cisco.com>
To: gja@bellcore.com, manfredi@engr05.comsys.rockwell.com
Subject: Re: Comments on ipv6nd-02.txt
Cc: ip-atm@nexen.com
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

Grenville,

>	[..]
>>>But isn't this ugly? The SEL was not meant to be used that way, was it?
>
>Ummm...
>
>>>To me, the SEL is only to be used by end systems,
>
>exactly!
>
>>>which would include
>>>individual virtual or logical IP hosts. (That is, allow use of ESI to
>>>denote virtual hosts, but not SEL.)
>
>The SEL field is for _internal_ routing of an incoming call
>once the physical ATM interface has been located (routed to) using
>the top 19 bytes. i.e. the top 19 bytes denote the physical host,
>and SEL can be used internally to the physical hosts (end systems)
> - aka logical ATM interfaces. This not a new idea.  (People
>might choose to have only one higher layer application associated
>with a given local, logical ATM interface, and so overload the SEL
>field with the semantics of the B-LLI and/or B-HLI fields, but
>this is just a special case.)
>

Actually I think people have overloaded the B-LLI and B-HLI with
the semantics of the SEL, leading to lots of confusion. Looking
at the SEL as providing a "logical ATM interface" is one way
of looking at it - as is identifying a service or whatever. There
isn't just one way of viewing it. What you are really doing is identifying 
the entity that invokes the Q.2931/UNI signalling entity. From ATM's
point of view this can be anything.

The BLLI is primarily for _compatibility_ checking (it identifies the
data plane encapsulation / protocol used), after you have found
the appropriate signalling user entity. It has been pushed into service
as the thing you use to identify the siganlling user entity, but this is
a mistake IMHO, as it confuses data plane encapsulation with control plane
signalling users.

For example one protocol may use multiple data plane encapsulations (e.g.
a Classical IP which uses both LLC/SNAP and "null" encapsulated VCs).
The same data plane encapsulation may be used by different protocols
(e.g. Classical IP, NHRP, MPOA, LANE V2.0, etc may all use LLC/SNAP
encapsulation). As the mapping is many to many the BLLI just doesn't do a
good job of identifying signalling user entities. 

Part of the reason this occurred I think is because the SEL field is
"small", although as you have the ability to register multiple ESIs
this shouldn't be a problem. The main reason is that the perfectly good
"subaddress" field in N-ISDN was given a totally different semantic
meaning in B-ISDN (transit network address), the reason for which 
has always totally mystified me.

time to get off my hobby-horse :-)

Bryan