Re: NHRP v6 - hardware type / address type

[Grenville Armitage <[e-mail]>]

>>> bruce, the precedent already exists for the ar$shtl/ar$sstl method
>>> of encoding address/subaddress combinations (rfc1577) I'm really having
>>> a hard time understanding your aversion to it. 
>>
>>I've shown that this encoding leads to confused semantics, is currently
>>ATM-centric, and does not properly address all NBMA media types.

*cough* You've _asserted_ it is confusing, but at best all you've
shown is that the text in nhrp-06 does not completely capture the
possible generality. This has nothing inherently to do with ATM.
Like I said before, any technology that allows an address/subaddress
combo is going to required something a little more fancy than a
single address type.

>>The fact
>>that rfc1577 uses ar$shtl and ar$sstl does not make these problems go away.

It means we know how to use it.

>>I've come up with a counter proposal that does not have these problems.

You end up with an entirely different, complex structure of embedding
addresses when faced with NBMA endpoints identified by address/subaddress.
Given that the subaddress may be of a _different type_ to the main
address, how complex do you think your scheme is going to end up?
Seems like no less a square wheel than ar$shtl/ar$sstl, and we end
up with supporting different parsing rules.

	[..]
>>> >>Augment the list as appropriate.
>>> 
>>> What do you mean - include media identification?
>>
>>Change the list so that there are 3 address types for ATM.
>>Add address types for GRE network layers, as necessary.

You're essentially accepting the notion that media-dependent
address types exist aren't you?

>>> That's
>>> exactly what is achieved by using the hardware type space in nhrp-06
>>> (with clearer statement of semantics added to the IANA docs
>>> as required).
>>
>>Yes, you get the same functionality, by means of:
>>    splitting the address type field into 3 fields instead of 1

Comparing apples and apples its 2 fields vs 1, or 3 vs 2 (when you
realise the implications of encoding the address/subaddress format
after discarding the ar$shtl/ar$sstl mechanism).

>>    overloading the semantics of ar$hrd

On one hand minimal semantics appear to have made the orginal
hardware type space dangerous (judging by Dave Katz' comments),
now tightening up the semantics is 'overload'. Not sure I can win
against this.

>>    creating a new IANA number space to deal with this semantic overload,
>>      through added complexity

Either the hardware type space has its semantics clarified, OR
we have a new number space with explicit media/address type
semantics. Pick one - I haven't suggested both.

gja