The Routing Over Large Clouds Mailing List Archive by date

[Bruce Cole <bcole@cisco.com>]

> 
> Oh, please. You cant have it both ways.
> 
> First you observe, as though to imply that one codepoint per
> media type is (a) what we're allowed, yet (b) not enough:

I did not claim (a).  Where do you get that idea?

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

> and yet, when faced with ATM case of multiple address types you
> propose...
> 
> >>I don't see this as the only choice.  If there are 3 combinations of
> >>address and subaddress for ATM, then how about simply defining 3
> >>distinct address types?
> 
> If multiple codepoints (regardless of the number space)
> are allowed, you've answered your own first implied problem above.

I don't know what you mean by my first implied problem.

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

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

A lack of example would not change the fact that your proposed packet format
leads to confused address type semantics.

> >>It would also seem to require the NHRP spec to enumerate all the media
> >>types, specifying what these bits mean in each media's context.
> 
> Hardly. The IANA lists are quite appropriate, and there's nothing
> stopping us from saying "here's the table for NHRP, MARS, etc, where
> each ar$hrd value identifies a media and one or two addresses.
> The first named address type is represented by flag = 0 in the
> <blah blah>, the second address type .... by flag = 1 in the <blah>".

Why invent a 3rd IANA list when one of the existing lists can already
address our needs?