The Routing Over Large Clouds Mailing List Archive by date

[Grenville Armitage <gja@thumper.bellcore.com>]

>>> >>Media
>>> >>type to address type is a many to many mapping, so media type does not
>>> >>identify the address type.
>>
>>... And therefore your statement that the hardware type number space 
>>identifies the address type is incorrect.  This was my point.

It does. It doesn't have to identify _every_ possible address
type. That's what you're assuming I meant, and its what I did
not mean. My apologies for not being clearer on this point.

	[..]
>>> If we find a media that has 3, or 4, or 5 address types then
>>> you define ar$hrd codepoints for each address type of the same
>>> media.
>>
>>You've just defined the semantics of ar$hrd to encompass address type, yet
>>the definition in the 06 draft indicates that the number space is
>>taken from rfc1700's HARDWARE type field.

Interestingly, the hardware type used by ATMARP already applies
this exact semantic, and predates your use of afn in NHRP. If you
recall, nhrp-02 (or was it -03) used an 8 bit media type field.
The afn was only introduced in later 1994.

>>> (But as a reality check, can you name any current examples,
>>> or good reasons why such a situation would arise in the future that
>>> NHRP would be relevant to?)
>>
>>Currently we are shipping NHRP implemented over multi-point GRE tunnels.

(Which I presume would break if the afn number space was no longer
used? I can see your problem.)

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

gja