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

[[e-mail]]

Bruce,

Here is an except from the draft:
>
> D
> "Discretionary."  If set, and the NHS does not recognize the type
> code, the extension may safely be ignored.  If clear, and the NHS
> does not recognize the type code, the NHRP request is considered in
> error.  (See below for details.)
>
I understand this to mean the NHS can ignore the extension (meaning in
the Request packet only).  I thought the reason that an extension was
put into a Request packet was because the client supported that
extension.  The above text says, "if the *NHS* does not recognize..."
Is there another section of the draft that I need to read where it
indicates that a client can put a discretionary extension in a Request
packet but ignore it when receiving the extension in the Reply packet?

If the client can ignore the extension on a purge and at the same time
put the extension in the Request packet, then why should a server
ever send a purge?

>> > 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?
>>
>> You must be thinking that a client can ignore the destination mask
>> extension in the Reply but always use it in the Purge?
>
>Actually, I believe the client can ignore the extension on either the reply or
>the purge packet, since the discretionary bit is set.
>
>> That makes
>> sense to me, but in the past I've always thought it was wrong for
>> a requester to put an extension in a Request and ignore it in the Reply.
>
>Yes, it would seem likely that if a client included the extension in a
>request, it would be able to actually process it in reply and purge packets.

 I proposed these R and P flags because I thought a client must use the
 extension in the Reply when it supplied it in the Request. The client
 sends the extension to the server so that the server knows which
 extensions the client supports. A client that implements a simple cache
 that does not contain mask information (destination address only) should
 be allowed to receive a Purge with a mask.

 However, any one of the following will address my concern:
>
>> 1) Add clarifying text in NHRP to show that a client can safely send
>>    the destination prefix extension in a Request packet, optionally
>>    ignore the extension in Reply packets, but must always use
>>    the extension in Purge packets (never ignored).
>
>Why couldn't the mask extension be ignored in the purge packet (by the
>receiving station)?
>
 2) Flags in the extension define the packet types where this extension
    is supported (my R and P bit proposal).

 3) Add another extension that only applies to the Purge packet.

 4) Do not put the mask in an extension. Simply, add a mask alongside
    the destination field in the mandatory, protocol-specific part of
    the Purge packet. A mask of all F's is equivalent to no mask.

 Any one of these four will work for us.

-- Russell