Re: NHRP protocol modifications and clarifications

[Bruce Cole <[e-mail]>]

> ROLCers,
> 
>   In developing NHRP, I have come up with a few proposals for protocol
> changes and a few clarifications I'd like to see in the draft.
> 
> 1) The client and server, even in the same box, should have different IP addresses
> otherwise there is no easy way to differentiate where received messages should go.

I see no need for this.  Requiring multiple network layer addresses in order to
provide for address resolution seems excessively complex.  A single process
can demux the NHRP packets.  By looking at the various fields which
you need to look at anyways, (NHRP packet type, network layer addresses,
request ID, etc.) one can already determine what to do with the packet.

> 2) The NHRP Purge packet currently has two fields of interest: the Source
> Address, and the Request ID, which is matched to the corresponding
> NHRP request from that particular source.  When a source receives a
> Purge packet, it must then search its cache to find the entry with the
> matching Request ID.  This is the only time that the cache must be
> searched using the Request ID.  Unless you build an index of request
> IDs as a part of the cache, this can potentially be an expensive
> search.  And the Purge is probably something you won't see unless
> things are already going wrong and you really need those cycles
> elsewhere ...

I had that problem too.

> I would like to propose adding the Destination Address to the Purge
> packet format, using the same exact syntax as the Request and Reply
> packets (Request ID, Destination Address, and Source Address, in that
> order).

Sounds good.

> That way, an implementation only has to search on, and index,
> one field, the Destination Address, which you already have to be able
> to quickly search on anyway.

At the time of the purge, the destination address field should be able to
contain an aggregated address.  (We wouldn't want to require the NHRP
responder to remember all the de-aggregated destination addresses from each
request).

Assuming this is what happens, you would still have to pay attention to
the request ID, as the destination address field may be ambiguous.

> 5) A protocol mechanism is needed for client to send purge to server because it 
> is going offline... i.e., it wants a graceful death.

I don't see this as a NEED, but it might be nice.  Cache entries will expire
anyways, and the higher layer protocols should be able to detect when a
station goes away without the help of an address resolution protocol.

> 6) Extensions should be in numerical order to facilitate parsing.  The spec 
> says it need not be.

I think the spec has it right.  By adding such rules, you increase
the amount of sanity checking which a station should perform, and increase
the chances for pathological cases.  I believe the intent of the statement
"any particular extension type may occur only once in an NHRP packet" was
just to relieve implementations from having to worry about extensions that 
are spread up into multiple TLVs.

> 7) Prefix Length Extension should be followed by a 24 bit unused field because
> "Each extension is padded with zero octets to a 32 bit boundary."

I don't really care, but would like to point out that these extra bytes need
not be part of the TLV proper.  You already have to deal with alignment for
other variable length TLVs...