nhrp-05 ????? - Destination Prefix Extension

[[e-mail]]

Bruce/Andrew,
Based on all the problems we've discussed, I made a new proposal.
See the bottom of this post...

>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."
>             <[e-mail]>
>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 :)
>
>> But, if we are going to adopt the mask stuff at all then I propose strongly
>> 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.

If a client supplies the destination prefix extension in the Request
packet and the server supports it, then why not make it mandatory that
the client process the prefix on incoming NHRP packets?  As Andrew
suggested, if making the destination prefix extension mandatory
(discretionary flag=0) fixes this problem, then I think we're closer
to a consensus.

NHRP should be flexible enough to allow clients to specify which
packet types (Reply and/or Purge) are supported for the destination
prefix extension.

Therefore, why not add another extension called the "purge mask
extension" with the discretionary flag = 0.  This way the destination
prefix extension in the Reply can remain a discretionary extension.
Maybe this proposal is acceptable?  This proposal addresses the
following problems:

  1) No flags in the dest prefix extension used in Reply packets
  2) Destination Prefix Extension remains discretionary
  3) Only clients that support a purge with mask will receive this
     extension
  4) The new extension is not discretionary, never ignored...

Good night!
-- Russell