Purge packet - questions

[Andrew Smith <[e-mail]>]

> Date: Tue, 24 Oct 95 12:44:11 EDT
> To: [e-mail], [e-mail]
> Cc: [e-mail]
> Subject: Destination Address Mask in IP-specific part of Purge packet
> Ref:  My note of Thu, 19 Oct 95 09:37:11 EDT

Russell,

> Apparently there is no strong opposition for this proposal; please
> add this to the version-5 draft.  Thanks!

Hold on, hold on ... I'm not quite clear on exactly what are the mechanisms
involved here (the packet format is the easy bit). Do you have a list of the
exact changes?

> I propose that a destination address mask field be added to the
> IP-specific part of the Purge packet.  With this feature, a much
> more efficient purge can be performed; a single Purge packet can purge
> a large number of cache entries, instead of sending a
> large number of Purge packets...
> I have not heard a strong technical reason against this proposal.
> If there is one, please tell me; otherwise, let's add it.

Some clarifications needed please:

1. Is this just a control-traffic argument or do the wildcard-purge 
packets carry more semantics than just a string of simple-purge packets?

2. Presumably the only purges that can be condensed together are those from
one particular NHS to one particular requester, correct?

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?

4. Doesn't this feature suffer from some of the same "state scaling" problems at
intermediate nodes that caused the group to question the utility of the destination 
prefix extension? Or are you assuming that purge messages not be interpreted
by intermediate nodes and are just a private responder->requester interaction?
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.

> >From a NHRP protocol standpoint, this Purge mask field should be
> independent from the destination prefix extension found in
> Request/Reply packets.
>
> Here are the only arguments I've heard against this proposal, but I
> do not think they are strong enough to stop this proposal:
>  1) If a client uses the destination to purge his cache, a mask does not
>     complicate things.  An additional bit-wise AND operation does not
>     complicate a client.

It's more than just that one operation but I agree it's not much extra for a
client which was doing destination address matches anyway.

>  2) If the purge feature is only an optimization (an option that is not
>     really required), then this should not add additional overhead in
>     a minimal client implementation because these implementations
>     can ignore Purge packets (only an optimization).

This sounds like an interoperability can-o'worms. Or at least a very-suboptimal-
performance can-o'worms. Shouldn't acting on a "purge" be mandatory? I'm more
concerned about correctly functioning clients than minimal clients.

Have I missed something in the "Purge" discussion or are these valid concerns
that have not yet been discussed on this list.


[ BTW, I would like to see the "current" draft - what we
are discussing here are changes to the changes to draft-04 based on discussions
at the last IETF. What is the current ETA of draft-05? ]


> -- Russell
> 

Andrew 



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