Re: MARS last call: packet formats (fwd)

Joel Halpern <jhalpern@newbridge.com> Wed, 15 November 1995 14:46 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13796; 15 Nov 95 9:46 EST
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa13792; 15 Nov 95 9:46 EST
Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id JAA10711; Wed, 15 Nov 1995 09:17:30 -0500
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id JAA05835 for rolc-out; Wed, 15 Nov 1995 09:28:29 -0500
Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.6.12/8.6.12) with ESMTP id JAA05826; Wed, 15 Nov 1995 09:28:23 -0500
Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by nexen.nexen.com (8.6.12/8.6.12) with ESMTP id JAA05887; Wed, 15 Nov 1995 09:25:52 -0500
Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id JAA21019; Wed, 15 Nov 1995 09:21:34 -0500
Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma021011; Wed Nov 15 09:21:04 1995
Received: from mako.us.Newbridge.com (mako.us.newbridge.com [138.120.85.99]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with SMTP id JAA17525; Wed, 15 Nov 1995 09:21:02 -0500
Received: from lobster.Newbridge.COM by mako.us.Newbridge.com (4.1/SMI-4.0) id AA00886; Wed, 15 Nov 95 09:15:41 EST
Received: by lobster.Newbridge.COM (5.0/SMI-SVR4) id AA21007; Wed, 15 Nov 1995 09:20:05 +0500
Date: Wed, 15 Nov 1995 09:20:05 +0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Joel Halpern <jhalpern@newbridge.com>
Message-Id: <9511151420.AA21007@lobster.Newbridge.COM>
To: luciani@nexen.com
Subject: Re: MARS last call: packet formats (fwd)
Cc: rolc@nexen.com
X-Sun-Charset: US-ASCII
Content-Length: 1914
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/

In a recent message, Jim objected to the separation of registration from
packet semantics in NHRP.  However, I found his message, and the set of
choices he listed, confusing.

The reason for separating registration from query/response is that the
overloading of the query message as a registration is a source of difficulty.
The actual semantics of a query for an address have nothing to do with
registration.  If a station can "have" multiple addresses, and if multiple
stations can "have" the same address, the decoupling becomes obvious.

On the other aspect, that of harmonizing packet formats, I personally
find the effort to separate syntax and semantics quite confusing.  Syntax
is the question.  My goal as a participant/user of these protocols would
be to be able to build a device which used a single query mechanism to
resolve IP addresses to ATM addresses.  The mechanims should work when
1) The destination is "local" to the source,
2) The destination is "remote" from the source,
3) The destination is unicast at a single ATM address
4) The destination is unicast, but with multiple ATM addresses
5) The destination is multicast, and each receiver I need to know about
    has one or more ATM addresses

There is no reason for the query/response protocol to distinguish these
cases.  I realize that we have gotten quite far down the road working on
the separat aspects of the problem space.  We needed to do so.  I can not
imagine trying to resolve these cases all together.  For example, we will
still have to retain the requirement that multicast queries only resolve to
destinations within a LIS, until we can get the scoping and routing issues
resolved.  But we now understand the protocol well enough to build a single
tool which is well suited to the range of uses.  This will mean that we
have a MUCH better solution.

Yours,
Joel M. Halpern				jhalpern@newbridge.com
Newbridge Networks Inc.