The Routing Over Large Clouds Mailing List Archive by date

Cell Relay Retreat>List Archive>month:1995-Nov> msg00185



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

NHRP v6 - hardware type / address type

  • From: Bruce Cole <bcole@cisco.com>
  • Date: Wed, 29 Nov 1995 15:23:04 -0800
  • Cc: Bruce Cole <bcole@cisco.com>, rolc@nexen.com, James Luciani <luciani@nexen.com>
  • X-Orig-Sender: owner-rolc@nexen.com

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

Could break if you try to use a single ar$hrd value to represent multi-point
tunnel interfaces.  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.

> >>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.
Augment the list as appropriate.
Axe the ar$shtl/ar$sstl bits.
Done.
(This was my original proposal.)