The Routing Over Large Clouds Mailing List Archive by date

[Joel Halpern <jhalpern@newbridge.com>]

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.