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

[[e-mail]]

*** Resending note of 11/01/95 14:58                                           
                                                                               
                                                                               
SUBJECT: Re: nhrp-05 ????? - Destination Prefix Extension                      
                                                                               
Bruce,                                                                         
Thanks for the quick response.                                                 
                                                                               
> To: [e-mail]                                                       
> Cc: [e-mail], [e-mail], [e-mail],                      
> [e-mail], [e-mail]                                 
> Subject: Re: nhrp-05 ????? - Destination Prefix Extension                    
> In-Reply-To: Your message of "Wed, 01 Nov 1995 10:34:20 EST."                
>              <[e-mail]>                        
> Date: Wed, 01 Nov 1995 11:58:22 -0800                                        
> From: Bruce Cole <[e-mail]>                                           
>                                                                              
> Let me answer the two issues separately...                                   
>                                                                              
> > > 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?                                                     
>                                                                              
> > 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?                              
                                                                               
You must be thinking that a client can ignore the destination mask             
extension in the Reply but always use it in the Purge?  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.       
                                                                               
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              
   the extension in Purge packets (never ignored).                             
                                                                               
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.                                        
                                                                               
[...]                                                                          
>>> "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.