The Routing Over Large Clouds Mailing List Archive by date[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Purge packet - questions
> From gardo@VNET.IBM.COM Tue Oct 24 19:40:01 1995 > Date: Tue, 24 Oct 95 21:58:23 EDT > From: gardo@VNET.IBM.COM > To: asmith@BayNetworks.COM > Cc: rolc@nexen.com > 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: +1 408 764 1574 Technology Synergy Unit FAX: +1 408 988 5525 Bay Networks, Inc. E-m: asmith@baynetworks.com Santa Clara, CA ******************************************************************************** |
|