Re: Comments on ipv6nd-02.txt

[Grenville Armitage <[e-mail]>]

	[..]
>>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.)

	[..]
>>The point was only that I think the ATM NSAPA should stand on its own
>>merits too. If we force ESI to be unique, MAC-like, then the UNI 3.0
>>format for DCC and ICD address formats starts looking cramped. That
>>would make those formats less useful on their own, e.g. for cut-through.

I'm sorry, but in the context of IPv6 over ATM your comments seem
orthogonal (And if I recall, you were given a thread on this issue
a few months ago. Like it or not, the ESI is not required to be anything
but flat by the UNI standards. It doesn't have to be a MAC address,
but under UNI 3.0 or 3.1 it is required to be unique, nothing more).
Apologies if I'm missing an obvious tangent here.

	[..]
>>> But why assume they're in NSAPA format?
>>
>>To try to make things manageable in IP over ATM? Or to get rocks thrown
>>at me? That was part of the idea: focus on ATM rather than generic NBMA.

E.164 numbers in native format are potentially just as 'ATM' as NSAP format
addresses are, at least in the public arena (you know, the telcos whose
methods you like to champion on the odd occasion :)

cheers,
gja