Re: ACK of register and purge packets

[Eric Gray <[e-mail]>]

David,


> 
> > > Contrast this with a Purge request.  "There is no real need for an
> > > acknowledgement here since we already have to deal with the scenario in
> > > which the purge is never sent because the station that should have sent the
> > > purge crashed."  The only true way to be sure a cache entry has been purged
> > > is for the entry to time out. BTW, you did not address this in the note you
> > > sent out a few days ago.  I had suggested the removal of the ack for purges
> > > but this was not mentioned in your note of 10/31 where you included the new
> > > v5 of the NHRP spec.
> >
> > Sorry, it was an oversight that I didn't list this as a proposal that came up
> > since the last IETF.  I didn't see any further discussion of your proposal.
> > Comments?
> 
> It seems to me that the purge can/will be used to remove cache entries that
> could cause routing loops (in router-router case), or an invalid path (in the
> host-router case), when routing outside the cloud changes. A
> reliable purge is very important for these cases. Therefore I recommmend keeping
> the Purge ack.
> 
> David.

	I think that you missed the point (maybe?); because of the scenario in which a
purge is not sent as a result of a component failure (crash), a "reliable purge"
is an unattainable goal.  This reduces the purge protocol to the status of
"optimization" and it no longer makes sense to require purge originators to repeat
purge messages until they are acknowledged.  As one member pointed out, that makes
the case where a component is being taken off-line much simpler to handle as it is
not necessary for the component to wait for acknowledgement before continuing the
power-down sequence (this could be critical for devices equiped with short-term
back-up power provided for the express purpose of allowing for a graceful power-
down). If it is not necessary to repeat purge messages until acknowledged, then an
acknowledgement becomes superfluous.



							Eric Gray