NHRP & media type - a summary

[Grenville Armitage <[e-mail]>]

I sat back and contemplated this matter a little further,
and stumbled across some hidden assumptions that probably
help explain my view wrt Dave Katz' view (and others). So,
to perhaps clarify where I'm coming from, here's where
I think we stand:

Assumption #1:
	"NHRP is/is-not merely an address mapping protocol."

It appears that Dave (et al) see NHRP as purely a mapping
protocol, so it makes sense that the only identifiers you
need are the address type you're mapping FROM, and the
type you're mapping TO.

On the other hand, I've tended to view NHRP as intimately
tied to link layer connection management, with the address
mapping merely a part of the role. Consider the expected
role of NHRP messages in carrying QoS related information
in the future. I consider that NHRP request/replies will
carry media-dependent QoS parameters to aid clients in
their broader task of link connection management. Thus,
it has made perfect sense to me to have a field that conveyed
some link media-type semantics in addition to link address
type semantics. Its only at this early stage of NHRP deployment
that we can simplify NHRP to just an 'address mapping' mechanism.


Assumption #2:
	"The orginal transparent bridging of FDDI/Ethernet
	 ARP fiasco is/is-not particularly relevant."

The 'learn from history' argument also holds some weight, when
used appropriately. In the FDDI/Ethernet bridging example the
problem I see is that 'control plane' messages (ARPs generated
on either Ethernet or FDDI sides of the bridge) where being
bridged in the same way as 'user plane' messages (e.g. IP pkts).
Perhaps ARP should not have been using media-dependent codepoints,
but then again perhaps people were trying to be too transparent.
As Dave noted, a transparent 'user plane' bridge that fiddled with
ARP packets as they passed through would have avoided the problem.
This is history, but perhaps it is lesson that says more about the
errors of munging control and user planes togther, than it does
about media types in ARP messages.

Be that as it may, I was assuming a rather different model for NHRP.
In switched networks the control/user plane distinction is much clearer.
NHRP is in the control plane. The one big assumption I've been
making is that no-one will be 'transparently bridging' NHRP messages
across boundaries between NBMA networks based on different media.
The emphasis here is on transparent - I've no doubt we'll bridge
between such NBMA networks. However, to do so we use interworking units
that _actively_ 'fiddle' with link layer control plane related messaging
(call setup/teardown), and perhaps even user plane things like
encapsulations. Already our model is dissimilar to the FDDI/Ethernet
transparent bridging example.

I've assumed that NHSs will be at such boundaries. Assumption #1 above
is one reason I believe this model will end up being used. NHSs are
already expected to fiddle with NHRP message contents. NHSs will know
the media type of their attached interfaces. When required, translation
of the media/address type field will be trivial and appropriate at these
points.

I hope this email has provided food for thought.

cheers,
gja
_________________________________________________________________________
Grenville Armitage                               [e-mail]
Bellcore, 445 South St.      http://gump.bellcore.com:8000/~gja/home.html
Morristown, NJ 07960 USA          (voice) [phone] {.. 2504 (fax)}