Re: Ignoring purges

[[e-mail]]

>Bruce,
>
>>> 1) Add clarifying text in NHRP to show that a client can safely send
>>>    the destination prefix extension in a Request packet, optionally
>>>    ignore the extension in Reply packets, but must always use the
>>>    the extension in Purge packets (never ignored).
>>
>>Why couldn't the mask extension be ignored in the purge packet (by the
>>receiving station)?
>
>The mask extension cannot be ignored by the receiving station for the
>same reasons a station cannot ignore the Purge packet without a mask
>extension.
>How can the mask be added to the Purge packet and not be ignored by
>the receiving station?  I gave four proposals in my previous post; I'm
>sure there are other solutions.
>

   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?

   Why don't we move the mask into the mandatory part and remove the Request
ID field.  It was agree a while back that nobody was going to search their 
cache based on the Request ID and it seems to me that the tuple of {source
address, destination address, destination address mask} is sufficent to 
identify a cache entry (or entries) to be purge.


Comments???


- Chris DeBruin


>Have a nice day!
>-- Russell