The Routing Over Large Clouds Mailing List Archive by date

[Eric Gray <gray@ctron.com>]

Russell,

	As near as I can tell, your proposal does not impact on the storage/handling
requirements of intermediate systems.  It seems to have the greatest cost
(associated with implementation) to the purge originator that wants to send it
and offers potential traffic savings to all other system components.  The
biggest problem I see with it is it is one more thing that would need to be
changed in NHRP to decouple it from IP.  If we assume that it can be changed
(by adding a mask-length field and, possibly, mask application rules?) in a
way that allows it to be decoupled from IP-specific addressing, then it
shouldn't be a problem to add a mask to the purge message. This may be an "if"
of unknown size, however...


						Eric Gray

Russell Gardo <gardo@vnet.ibm.com> wrote:
> 
> Eric,
> Do you (or anyone) see any real bugs in this change (add a mask)?
> To summarize the change:  Add a mask field alongside the IP destination
> field in the Purge packet.  No one has pointed out any real bugs
> with this change...  This change adds *flexibility* to the purge feature.
> 
> I believe the comments you made about optimization are correct.
> 
> > Correct me if I am wrong, but I hadn't heard that any client could
> > ignore purge messages.  In saying that purge protocol is an
> > optimization, it was my understanding that the use of purge messages
> > would be useful in reducing the effect of bad information retained by
> > NHRP components but could not be relied on.  I believe that the issuer
> > of a purge message can reasonably expect it to be used by any
> > component that receives it.
> 
> -- Russell