Re: ACK of register and purge packets

[[e-mail]]

Eric,

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

This is a general argument that also applies to any other protocol that
uses Ack/Retx. Your are not suggesting that if it is possible that a network
componenet that has to wait for an acknowledgment ever goes down, then Acks/Retx
as a protocol mechanism should never be used?

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

I disagree. Acks are useful to speed up convergence. In some cases an
ACK does not make it (e.g., above scenario or a catastrophic failure),
and the protocol needs to handle it. However this does not make Acks
superfluous.

David.