Re: NHRP v6 - hardware type / address type

[Grenville Armitage <[e-mail]>]

>>If you use multiple values, you're basically
>>admitting that ar$hrd should represent address type.  If so, then the
>>need for the flag bit in the ar$shtl and ar$sstl fields goes away.

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. 

	[..]
>> >>For these GRE tunnels, you could conceivably have your choice of network
>>> >>layers to use as the underlying delivery protocol.  In this case, these
>>> >>network layers are your address type.
>>> 
>>> Cool.
>>> 	ar$hrd = X, GRE tunnel, address type <blah.1>
>>> 	ar$hrd = Y, GRE tunnel, address type <blah.2>
>>> 	ar$hrd = Z, GRE tunnel, address type <blah.3>
>>> 	etc.
>>
>>ar$hrd = rfc1700 address family numbers.

Are we going in circles here? That's not what I wrote above.

>>Augment the list as appropriate.

What do you mean - include media identification? 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).

gja