Re: Purge packet - questions

[Andrew Smith <[e-mail]>]

> From [e-mail] Tue Oct 24 19:40:01 1995
> Date: Tue, 24 Oct 95 21:58:23 EDT
> From: [e-mail]
> To: [e-mail]
> Cc: [e-mail]
> Subject: Purge packet - questions

Russell,

> This change adds a great deal of flexibility to this purge feature...

Is it flexibility for flexibility's sake you are looking for or do you have some
reason for it e.g. a reduction in control traffic?

> >3. A client now *must* index by destination (match on wildcarded destination
> >to be more exact) and cannot use request-id for acting on the purge. Correct?
> 
> True, if the request-id in the Purge is zero.
> The client must have a match on both the
> destination and request-id if the request-id is non-zero.

Do all wildcard Purges will contain zero request-id? (I've still not
seen any text from you describing the semantics of wildcard purge).

Do you think that any reduction in control packets outweighs the (potential) extra 
processing involved in doing a wildcard destination lookup rather than a request-id 
lookup? Do you think that you will often have one NHS being able to coalesce multiple
purges together back to the same requester - can you describe a scenario where that
is likely? 

> I would expect intermediate nodes that have cache entries that match
> the Purge destination/mask would purge those entries.

... and remember which way(s) to forward the Purge: it has to be forwarded back
along the same path that the original response messages went, rather than the
current routing path, doesn't it? It is precisely when routing is changing that
the purges are most useful and the caches in intermediate nodes most useless, right?.

> >If the latter, then doesn't the purger have to send separate purges to each
> >possible intermediate node that might have cached the previous response? Ugly.

Is this true? [ NHRP sounds more and more like a real routing protocol by 
the minute .... ]


It may well be that the mask is a useful feature - I'm just playing devil's
advocate here (as usual) in order to see a better justification for its 
inclusion: the shorter the spec is, the better for everyone so long as it does 
its job, so any feature really needs good reasons, not to mention good explanatory 
text: I've not seen much so far and you did issue a "mini-last-call" on its inclusion.

> >
> >Andrew
> >
> 
> -- Russell
> 

Andrew


********************************************************************************
Andrew Smith					TEL:	[phone]
Technology Synergy Unit				FAX:	[phone]
Bay Networks, Inc.				E-m:	[e-mail]
Santa Clara, CA
********************************************************************************