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

[Andrew Smith <[e-mail]>]

> To: [e-mail]
> Cc: [e-mail], [e-mail], [e-mail], [e-mail],
>         [e-mail]
> Subject: Re: nhrp-05 ????? - Destination Prefix Extension
> Date: Wed, 01 Nov 1995 11:58:22 -0800
> From: Bruce Cole <[e-mail]>

Bruce,

> > > 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?

> > Add two flags to the destination prefix extension that define which
> > packet types that it supports for the destination prefix extension.
> 
> Here, you must be referring to the R and P bits that you proposed to
> add to the destination prefix extension.  I saw no response to that
> proposal, but...
> 
> Personally, I think it makes *NO* sense.  Why would a client indicate
> that it does not support this extension in purge packets, and why
> would the responding station care to know this?
> 
> Firstly, for the client to be able to parse the NHRP purge packet in
> the first place, it would have to be conforming to the newer draft of
> the NHRP protocol.  So there is no need to worry about backwards
> compatibility here...  Secondly, this extension is already defined as
> "Discretionary = 1", so implementations are already aware that the
> extension may not be handled by the receiving station.

Indeed, there can be no "backwards compatibility" argument made for a 
protocol still in internet-draft form.

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. In this case 
the added protocol complexity outweighs any "simple client" argument. If it
is in the protocol at all, we should mark this extension as "Discretionary = 0" 
and be done with it.

BTW, I think these NHRP client complexity arguments are bogus when compared to
the complexity of any ATM signaling client that might sit below NHRP!


Andrew


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