Re: Comments on ipv6nd-02.txt

[Grenville Armitage <[e-mail]>]

Albert,

thanks for the review.

	[..]
>>In my opinion, one reason for this state
>>of affairs is that IP over ATM proposals are invariably IP over generic
>>NBMA net proposals.

	[..]
>>Perhaps we should consider ATM more specifically.

As an aside, I'm tempted to agree with you there. But that'll get
bricks thrown at me, so perhaps I shouldn't :)

	[..]
>>On page 7, I would simplify the rules for mapping ATM numbers with
>>IPv6 numbers. I would require the following:
>>
>>1. A single IPv6 interface is directly related to a single ATM interface.
>>
>>2. The 48 ESI bits of the NSAPA are used to form the unique, non-
>>routable part of the IPv6 address.

Unfortunately these two points can contradict each other in practise. The
I-D specifically notes the use of the SEL field to construct logical
ATM interfaces, upon which separate IP interfaces may be layered.
Point 1 above then requires both ESI+SEL to identify the associated
IP/ATM interface. Thats more than 48 bits. If you are using logical
ATM interfaces to support virtual hosts, and each host is on the
same LLG, you need unique link-local tokens that are more unique
than the ESI alone can be.

That's why some suggestions have involved hashing functions, which
is complicated but at least allows the magic 48 bit token width to
be retained.

>>3. Use of the ESI bits includes cases in which E.164 is encapsulated
>>in the NSAPA frame. This has the added advantage that a single E.164
>>number can service multiple IPv6 (and ATM) addresses.
>>
>>4. Something needs to be done to the DCC and ICD NSAPA formats to leave
>>a reasonable number of bits for the routable prefix. (I understand that
>>ANSI is still mandating the UNI 3.0 formats for US NSAPAs?) If this is
>>the case, then making ESI a flat field would seriously bite into the
>>number of hierarchical bits available.

Its not clear to me what point 4 above has to do with IPv6. Regardless
of the technology, IPv6 does not require that the lower part of
IPv6 addresses are in any way routable. The ESI is flat. You cannot
change that, because you cannot change how the link-local token
for Ethernet, Fddi, etc cases are chosen (they're flat too).

>>I believe that a scheme in which a few well-known VCIs (VPI = 0) be
>>assigned to servers for a Link Local Group (LLG), as discussed
>>previously, could be of value for neighbor discovery. Something like
>>this:
>>
>>1. The host that has just been powered up listens on VPI = 0, VCI = x.
>>
>>2. Over this channel, the LLG server periodically transmits the IPv6
>>routing prefix, perhaps even the ATM NSAPA routing prefix, and its
>>own ATM address.

Well-known VCIs have some problems in scaling beyond a small number
of switches. Also, the key aspect of your model above seems to imply
that VCI=x is associated with a given LLG server, i.e. a given LLG.
This makes it hard to overlay multiple LLGs across even a single
switch ATM network, let alone a multi-switch network. You'd need
a mapping from VCI to LLG (and server). More administration rather
than less. Suddenly the VCI isn't well-known (but derived), and
you limit the mobility of hosts (who may want to attached/dettach/
reattach to any switch in the ATM network, and yet still be part
of the same LLG).

	[..]

>>On page 8, I would simplify the neighbor discovery address options.
>>Specifically, if the addresses in question are assumed to be NSAPAs,
>>why not delete the Length, Number Type and Length (NTL), and Subaddress
>>Type and Length (STL) fields? This would result in a nice, clean
>>format:
>>
>>[Type][ATM number][ATM subaddress]
>>
>>where the ATM address is by definition 20 bytes long (and, of course,
>>the first byte in the ATM address, AFI, already identifies the format
>>of that address).

But why assume they're in NSAPA format?

cheers,
gja