Re: NHRP v6 - hardware type / address type

[Bruce Cole <[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. 

I've shown that this encoding leads to confused semantics, is currently
ATM-centric, and does not properly address all NBMA media types.  The fact
that rfc1577 uses ar$shtl and ar$sstl does not make these problems go away.
I've come up with a counter proposal that does not have these problems.

I don't think that alignment of NHRP should be done at the expense of
introducing these problems into NHRP.  I don't think the NHRP protocol
should be changed in ways which haven't been discussed within ROLC.
It was agreed that NHRP/IPMC alignment was desirable, but I don't think
this is a desirable change.

> Are we going in circles here?

Yes.

> >>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.

> 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
    overloading the semantics of ar$hrd
    creating a new IANA number space to deal with this semantic overload,
      through added complexity