RE: NHRP & media type - a summary

Paul Koning 1695 <pkoning@chipcom.com> Mon, 04 December 1995 17:00 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13259; 4 Dec 95 12:00 EST
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa13253; 4 Dec 95 12:00 EST
Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.98.5]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id LAA19816; Mon, 4 Dec 1995 11:28:57 -0500
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id LAA05735 for rolc-out; Mon, 4 Dec 1995 11:34:39 -0500
Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.6.12/8.6.12) with ESMTP id LAA05726 for <rolc@nexen.com>; Mon, 4 Dec 1995 11:34:36 -0500
Received: from chipcom.com (chipcom.com [192.41.247.9]) by guelah.nexen.com (8.6.12/8.6.12) with SMTP id LAA19736 for <rolc@nexen.com>; Mon, 4 Dec 1995 11:19:30 -0500
Received: from mailer2 (mailer2-dns.chipcom.com) by chipcom.com (4.1/SMI-4.0) id AA28728; Mon, 4 Dec 95 11:30:31 EST
Received: by mailer2 with Microsoft Mail id <30C34D12@mailer2>; Mon, 04 Dec 95 11:33:38 PST
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Paul Koning 1695 <pkoning@chipcom.com>
To: Rolc mailing list <rolc@nexen.com>
Subject: RE: NHRP & media type - a summary
Date: Mon, 04 Dec 95 11:33:00 PST
Message-Id: <30C34D12@mailer2>
Encoding: 60 TEXT
X-Mailer: Microsoft Mail V3.0
X-Orig-Sender: owner-rolc@nexen.com
Precedence: bulk
X-Info: Submissions to rolc@nexen.com
X-Info: [Un]Subscribe requests to rolc-request@nexen.com
X-Info: Archives for rolc via ftp://ietf.cnri.reston.va.us/ietf-mail-archive/rolc/

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

I hadn't considered this point, but now that you mention it, the answer
in my case is definitely NO.

There are actually various other examples in protocol  history of
mistakes of this kind, spanning a wide range of protocol capabilities.

The general point, of which the "address type" is a specific example,
is this:

There are two ways to describe X in a protocol (where X may be an
address, a request for a certain QoS, etc.)
1. By a field in the message that says "X"
2. By a field in the message that implies a variety of things, one of
   which is X.

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

It certainly may be that NHRP will convey media dependent QoS
parameters.  It is also likely, and clearly preferable, that it will convey
media INdependent QoS parameters.

Similarly, while NHRP can convey media dependent address
mappings, it is better for it to convey media independent
address mappings.

 -------------
I would like to pose a question that seems to be relevan to the
discussion: if an NHRP node receives a protocol message containing
a media type code it does not recognize, what is it expected to do?
(What does the spec say?)

1. Process the message, effectively ignoring the media type code?
2. Discard the message?

     paul