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

[Bruce Cole <[e-mail]>]

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

> 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     
>    the extension in Purge packets (never ignored).                    

Why couldn't the mask extension be ignored in the purge packet (by the
receiving station)?

> >>> "when the Request ID is zero filled the match is made             
> >>> based only on the Destination Address"...                         
> >>> I believe Andrew has already made this point in an earlier posting. 
>                                                                       
> I assume that once the missing paragraph is added, a server should be 
> able to purge by setting the request-id to zero if it chooses to purge
> without using the request-id.                                         

Yes...