Purge packet

[[e-mail]]

Jim,
Thanks for responding! :-)
See my reply below:

>Russel, David,
>> Russell,
>>
>>> When a client supports the "Destination Prefix Extension", what
>>> benefit is the Request-ID in the Purge packet?  Isn't this duplicate
>>> information, therefore a higher risk of error.
>>>
>>> To send the "Destination Prefix Extension" in a Purge packet,
>>> the server must remember whether that client supplied this extension
>>> in the original Request packet.  Correct?
>>>
>>> Why not remove the Request-ID from Purge packet and add a mask field to
>>> the Purge packet?  I don't think it really complicates the client to
>>> remove the Request-ID from the Purge packet.  Will servers really need to
>>> check the Request-ID in Purge packet acknowledgements?
>>>
>>> I propose that the Purge packet be changed, by removing the Request-ID
>>> and adding a mask field.
>>>
>>> -- Russell
>>>
>>I support the addition of the mask field.

>A couple of points.  Let's first keep in mind that the purge is an
>optimization! The timers on the entries are the only truely reliable
>way to remove entries.

I do not see any words about optimization in V4.  I understood that
a complete implementation would support the Purge packet; is this not
correct?
If a client does not support the purges, maybe NHRP should have a
mechanism to inform the server that a particular client does not
support purges.  This way a server could adjust the holding time for
clients that do not support the Purge packet.

>Also, the Destination Prefix Extension
>as of V4 (and alpha v5) can only be in the request and reply packets,
>(read it closely :-( ), so we need to change that if we go down
>this path.

Since NHRP is not encapsulated in IP packets and it is wrong to send
an extension in a Purge packet, I suggest the length of the Extension
part be added to the Mandatory part of the packets where extensions
are valid.

>Also, we do not want the prefix as part of the purge packet
>per se because we want to move toward a multiprotocol internetworking layer
>version of NHRP (i.e., NHRP for MPON (my new acronym for Multi-Protocol
>Over NBMA :-) )) and the internetworking protocol layer address length
>will be different from protocol to protocol which argues for a varying length
>field.

The prefix could be in the protocol-specific part.

>We also probably don't want to complicate minimum functionality clients
>and servers (you'll note that the prefix extension is a "discretionary"
>extention) so having the prefix as part of the packet per se is less desirable.

In some respects NHRP V5 makes it more complicated with *both*
Destination and Request-ID in the Purge packet.  Should the client
purge cached information when both match or either match?  Please add
any clarification if necessary.

One last comment:
If a Mask were added and the Request-ID deleted, I do not see how this
would really increase the complexity of the client or server when
performing a purge.

>Regards,
>-- Jim Luciani

Thanks for your reply and patience,
-- Russell Gardo