Re: nhrp-05 ????? - Destination Prefix Extension

[[e-mail]]

Bruce/Andrew,
 
   First, would I be correct in assuming that we have reached a consensus 
on the fact that the Request ID is going to be removed from the Purge 
Packet?  I feel that we have, but I just want to be clear about that.

> To: [e-mail] (Andrew Smith)
> Cc: [e-mail], [e-mail]
> Subject: Re: nhrp-05 ????? - Destination Prefix Extension 
> In-Reply-To: Your message of "Thu, 02 Nov 1995 11:28:03 PST."
> Date: Thu, 02 Nov 1995 17:50:22 -0800
> From: Bruce Cole <[e-mail]>
> 
> > > > > 6. Proposal to add prefix mask to purge packet
> > > > 
> > > > The consensus on item #6 follows:
> > > > Allow the destination prefix extension to be sent in Purge packets.
> > > 
> > > I saw no disagreement to this proposal, and it seems like a sensible
> > > compromise.  Objections?
> > 
> > I tried to argue against this proposal merely on the grounds of not
> > having seen any real justification that it would save much traffic in 
> > realistic scenarios and that nobody seemed to have evaluated the overall
> > system impact very thoroughly. Are we operating on the "guilty until proven 
> > innocent" principle here?
> 
> Certainly not.  Consensus on this item didn't seem clear, which is why
> I hadn't listed it as a seemingly resolved issue in the first place.
> Your disagreement seemed to be that it was unclear what the
> semantics are for a purge with an associated mask.  The subsequent proposal
> to simply allow the destination prefix extension to be included in purge
> packets seemed to go undisputed.  So I asked if there were objections...
> 
> Shall we first further discuss what we think the semantics are for a mask
> that is included in a purge request?  It doesn't look like we have that
> clearly defined yet.  I could tell you what I think it means :)
> 

I would certainly agree that we have not reached a consensus on the issue
of a mask, but I feel that we have a good discussion going here.  Here
is my two cents worth.

> > But, if we are going to adopt the mask stuff at all then I proposestrongly 
> > that we add it's support in receivers as MANDATORY citing both the"options 
> > are bad" and the "be liberal in what you accept" principles.

> For a station to efficiently support cache invalidation requests that include
> a network mask, the cache should be tree based instead of a simple
> linked list/hash table.  Basically you're requiring all NHRP stations to
> support aggregation of NBMA information, and a sophisticated cache.  I
> think this is a bit of a leap over current requirements.

   I think that we need to include the ablility to support a mask.  Not only
would this reduce the traffic load (which is probably not the best argument 
for something like this), but will also add flexability to the spec that 
allows for some innovations in the implementations.  The mask would give 
a server the ability to purge as little as a single station, or as much as
the entire client cache with one message simply by changing the mask field.
   I agree with Andrew and would like to see it as a MANDATORY part of 
the spec.  I think this feature would add a great deal of flexability
without requiring too much additional work on the client side.  While this 
would require that the client have the ability to support aggregate address,
this is not really a hardship IMHO.  Also, this does not to be a highly 
optimized function because it would not happen (hopefully) very often.
   I propose put the mask in the mandatory part of the purge packet and 
requiring all client to support it.  This gets us away from any discussions 
of the semantics of placing extensions in the purge packet, which is kind 
of messy anyway.  


- chris