The Routing Over Large Clouds Mailing List Archive by date

[Eric Gray <gray@ctron.com>]

Russell,

	Re: your question -

> 
> Eric/Jim,
> 
> >>>  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.
> 
> Is there a need or requirement that some clients not participate in
> the purge portion of NHRP?
>

Interesting question.  Do you suspect that I ask to dispense with acknowledgement
so that I can ignore the protocol?  I can't answer for Jim (but suspect he would
answer the same), but I believe - if you scan through my previous messages - you
will find it expressly stated that any component receiving a purge should act on
it (to remove cache entries invalidated by the purge) and this certainly would
qualify as participating in the purge portion of NHRP.  I also would support the
idea that any component that becomes aware of routing changes affecting otherwise
valid information which that component has distributed elsewhere must take all
reasonable options available to it to ensure that the invalidity is likewise
distributed - and this would also qualify as participation.  The issue is in the
definition of "reasonable options" - I don't think that hammering on a busy
component is a "reasonable option".

Can you imagine how busy a network administrator gets when there is a major
network failure?  If you can, then add to it a management imposed requirement
that each user can resubmit a trouble ticket an arbitrary number of times if he
or she is not responded to in a timely fashion.  Now what does you administrator
look like?


							Eric Gray

> 
> -- Russell