Re: NHRP protocol modifications and clarifications

[James Luciani <[e-mail]>]

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

You can intuit most of the time for whom (NHC or NHS) the NHRP packets are but if you are 
in server mode and merely passing the data (TLVs not withstanding) you probably don't 
want a clumsy state machine for this.  

There are a number of error conditions for which you just cannot test without a demux 
mechanism.  If you get an error message, how do you intuit for whom it was sent?...  Lets say
it is an error case of incorrect message type.

What about the case when you have 2 or more NHCs which are co-resident with their NHS?  
You can't figure out for whom the packet was sent in this case without burdening all 
NHCs to check to their database.  Even then, it is not clear that you could resolve
the who sent the request.

I have received several notes saying that others have run into this problem and have 
either done what I suggested or used another form of demux (usually complex as opposed to 
something as simple as a separate IP address).  

I suppose that there are no interoperability questions here so a SHOULD rather than MUST 
is acceptable but what do you want to do about the statement:
    : An NHS is configured with its own identity, a set of IP address
    : prefixes that correspond to the IP addresses of the stations it
    : serves, a logical NBMA subnetwork identifier (see Section 5.7.2),
    : and in the case of "server" mode, the identities of other NHSs in
    : the same logical NBMA subnetwork.  If a served station is attached

The only reason one might not want to have separate IP addresses that I can see is when
the NHC and NHS are a single piece of code and are thus inseparable.  That would probably
not be a great design though; sort of defeats the client/server paradigm a bit.  
Also, there is nothing complex about multiple IP addresses for an interface.  This is 
especially true in this instance since an NHS will be co-resident with a router in fabric 
mode and probably in server mode as well.  Which means that the NBMA interface will have 
a strong probability of having more than one IP address associated with it anyway.

I think it is much cleaner administratively to have one IP addresses for each NHS and NHC.  
Also, let's keep in mind this is only an issue when they are co-resident.

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

I think that it is between "nice" and "need".  Having a mechanism for gracefully
leaving a network is very desirable.  Yes, the stale info will go away when the
timer pops but why go tell new requests the wrong data?  I think the amount of work
to implement this is miniscule but I would be willing to accept a SHOULD rather
than a MUST on this one: i.e., the NHS SHOULD accept a purge request from 
its NHCs which ... etc.. (see previous note).

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

I actually 'kinda' like the argument about the amount of state needed to be kept 
(which was deleted from my original message).  Yeh... It is not too much state now
with only 8 extension types but we have potentially 2^15 extension types with 
which to deal in the future.  I do agree this is a nit though.

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

Basically, you need to align on a word anyway but this makes it explicit.  
In the descriptions of the extensions which carry an NBMA address, it is stated
explicitly that the address is zero filled to a 32 bit boundary (e.g., responder
address extension etc.).  All the other extensions which have an explicit format
have implicit 32 bit boundaries.  

I think, in this case, making it explicit leaves one less avenue open for making
an error.  There is no cost here so why not?

Regards,
-- Jim Luciani
__________________________________________________________________________
James V. Luciani    ascom nexion                    voice: [phone]
[e-mail]   289 Great Rd., Acton MA 01720   FAX: [phone]