NHRP purge nits

[Andrew Smith <[e-mail]>]

> From [e-mail] Wed Oct 25 09:05:48 1995
> To: [e-mail]
> Cc: [e-mail]
> Date: Wed, 25 Oct 1995 11:45:15 -0400
> From: James Luciani <[e-mail]>

Jim,

Just some mindless editorial nits ... I think some of these will help re-use of
this text for other (similar) purposes in the future.

>    Destination IP Address
>      The address of the target station (as if copied from the original
>      NHRP address resolution Request).  This field holds the address 

Do you mean NHRP Request? Let's use the precise terminology as this is the
meat of the protocol definition.

>      of the client whose routing information has (or is about to be) 
>      changed.
> 
>      In the case when the purge request comes from a client,
>      this is the address of the client.  In this case, when the NHS 
>      receives the purge its removes its entry for that client.  The 
>      NHS then initiates a purge request to each station which 
>      requested address resolution information for that client.
> 
>      In the case when the NHS notices a change in routing information 
>      for a client which has registered with it, the NHS removes its 
>      entry for that client.  It then creates a purge packet in which 
>      the Destination IP Address field is set to the address of the client.
>      The NHS then initiates a purge request to each station which 
>      requested address resolution information for that client.
> 
>    Source IP Address
>      In the case when the purge request comes from a client, this field
>      contains the address of the client.
> 
>      When a client sends a purge request to its NHS, the NHS removes the
>      client's entry from the NHS's cache.  The NHS then initiates a 
>      purge request to each station which requested address resolution 
>      information for that client.

How about "Destination Resolution" rather than "address resolution"? The
protocol is performing route selection and QoS lookups as well as address
resolution.

>      When an NHS initiates a purge (as a result of a client's request
>      or as a result of noticing a routing change), the Source IP Address 
>      field contains the address of the initiator of an NHRP address 
>      resolution Request.

Are you saying that Purge packets get forwarded by intermediate NHSs according
to their *Source* IP address fields? This is slightly backwards but OK as long
as we say that somewhere. Need some description of the forwarding rules that
NHSs use for purge packets.

....
>    When a station receives an NHRP Purge request, it MUST discard any
>    previously cached information that matches the Source Address and

Confusion here: does "station" = NHS as well as client? Do you mean 
"Source IP Address" or "Destination IP Address?". Isn't it the destination
that is getting purged, not the source?

>    Request ID (when the Request ID is zero filled the match is made
>    based only on the Source Address).

Ditto.

>    If a station receives a purge request when it does not contain a cache
>    entry for the client being purged, the receiving station MUST silently
>    discard the packet.

Does "station" apply to clients only or does this rule apply to NHSs?

>    If the station wishes to reestablish communication with the
>    destination shortly after receiving a Purge request, it should make
>    an authoritative request in order to avoid any stale cache entries
>    that might be present in intermediate NHSs.  (See section 6.2.2.)  It
>    is recommended that authoritative requests be made for the duration
>    of the holding time of the old information.

So I can't just delete a purged cache entry, I have to keep a record of it
around for its previous holding time afterwards, just in case? Or should I 
always issue authoritative requests, just to be sure? Do you think this is a 
choice that should be left to client implementors? Why don't we just say "MUST" here?

There's the usual caching problem here too - the cache is most useless
just when it would be useful, during routing topology changes and so there will
be a bunch of authoritative requests flying around at these times.


> Regards,
> -- Jim Luciani


Andrew (representing the committee for thin, readable and implementable standards :-)


********************************************************************************
Andrew Smith					TEL:	[phone]
Technology Synergy Unit				FAX:	[phone]
Bay Networks, Inc.				E-m:	[e-mail]
Santa Clara, CA
********************************************************************************