>    The mask can not be ignored on the purge because the client will not
> purge all the entries that the server is expecting.  Perhaps an example
> will help.  Let's suppose that a client asks for a lookup on IP address
> 9.67.5.20 and supply the destination prefix extension.  The server
> responds with the ATM address and a mask of 255.255.255.0.  Given this,
> the client should be able to get to any station on the subnet without
> asking the server again.  However, lets say the client chooses to ignore
> the mask.  What have we lost?  When the client goes to find the address of
> 9.67.5.30 another request is generated to the server.  Which of course
> comes back with the same reply as above.  So the impact is a little extra
> network traffic.
>    Now lets say something changes and the server would like to purge the
> above two entries from the client's cache.  Right now, there are several
> ways of doing this.  The server could send two purge requests using the
> Request IDs, or two purge requests using the two destination IP address.
> But wouldn't make more sense to send just one purge using a mask.  This
> purge would send something like IP address = 9.67.5.20 and mask =
> 255.255.255.0.  If the mask was ignored in this case, the cache entry for
> 9.67.5.30 would not be deleted, but the server doesn't know this.  While
> the entry in question will age out eventually, isn't the purge message
> intended to be on optimization designed to speedup convergence?

Yes, the purging function is providing an optimization.  So, in the
(unusual I imagine) case where a client handles the prefix extension in
an NHRP reply, but fails to handle the extension in a purge, we may fail
to invalidate a cache entry as quickly as possible.

We may want to explicitly recommend that if a station pays attention to the
prefix extension when creating cache entries, that it SHOULD also pay
attention to the extension when processing purge messages.  But the protocol
need not be changed to enforce this.

>    Why don't we move the mask into the mandatory part

I thought we didn't have consensus, or even a clear description of the
semantics of this.  (I'm not objecting however...)

> and remove the Request ID field

Yes, I'm all for removing this field from purge packets also.