Re: Purge packet

[James Luciani <[e-mail]>]

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

An example of new text for the extension follows:

5.7.1  Destination Prefix Extension (IPv4-Specific)

   Discretionary = 1
   Type = 1
   Length = 1

   This extension is used to indicate that the information carried in an
   NHRP Reply/Purge pertains to an equivalence class of internetwork layer destination
   addresses rather than just the internetwork layer destination address 
   specified in the request.  
 
etc...


Regards,
-- Jim Luciani
__________________________________________________________________________
James V. Luciani    Ascom Nexion                    voice: [phone]
[e-mail]   289 Great Rd., Acton MA 01720   FAX: [phone]