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

Andrew Smith <asmith@baynetworks.com> Thu, 02 November 1995 20:02 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20175; 2 Nov 95 15:02 EST
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa20171; 2 Nov 95 15:02 EST
Received: from maelstrom.nexen.com ([204.249.99.5]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id OAA04405; Thu, 2 Nov 1995 14:32:23 -0500
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id OAA10740 for rolc-out; Thu, 2 Nov 1995 14:40:40 -0500
Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.6.12/8.6.12) with ESMTP id OAA10725; Thu, 2 Nov 1995 14:40:35 -0500
Received: from lightning.synoptics.com (lightning.synoptics.com [134.177.3.18]) by guelah.nexen.com (8.6.12/8.6.12) with SMTP id OAA04339; Thu, 2 Nov 1995 14:27:46 -0500
Received: from pobox.synoptics.com ([134.177.1.95]) by lightning.synoptics.com (4.1/SMI-4.1) id AA17291; Thu, 2 Nov 95 11:34:32 PST
Received: from milliways-le0.engwest (milliways-le0.synoptics.com) by pobox.synoptics.com (4.1/SMI-4.1) id AA17861; Thu, 2 Nov 95 11:35:55 PST
Received: by milliways-le0.engwest (4.1/SMI-4.1) id AA01407; Thu, 2 Nov 95 11:35:54 PST
Date: Thu, 2 Nov 95 11:35:54 PST
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Andrew Smith <asmith@baynetworks.com>
Message-Id: <9511021935.AA01407@milliways-le0.engwest>
To: rolc@nexen.com, gardo@vnet.ibm.com, Russell.Gardo@nexen.com
Subject: Re: nhrp-05 ????? - Destination Prefix Extension
X-Orig-Sender: owner-rolc@nexen.com
Precedence: bulk
X-Info: Submissions to rolc@nexen.com
X-Info: [Un]Subscribe requests to rolc-request@nexen.com
X-Info: Archives for rolc via ftp://ietf.cnri.reston.va.us/ietf-mail-archive/rolc/

> From owner-rolc@nexen.com Wed Nov  1 13:55:17 1995
> From: gardo@vnet.ibm.com
> Date: Wed, 01 Nov 95 16:33:12 EST  
> To: bcole@cisco.com, genecox@vnet.ibm.com, rolc@nexen.com
> Subject: Re: nhrp-05 ????? - Destination Prefix Extension
> From: Russell.Gardo@nexen.com

Russell,
                         
> >>> "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.                                                  

Again, to avoid having options and useless checks in the code, just 
specify that the request-id field in a Purge has no meaning to a receiver.
No protocol functionality is lost by this simplification and interoperability
will be enhanced.


Andrew

P.S. I'm confused: are you now with Ascom, rather than IBM, or both? :-)


********************************************************************************
Andrew Smith					TEL:	+1 408 764 1574
Technology Synergy 				FAX:	+1 408 988 5525
Bay Networks, Inc.				E-m:	asmith@baynetworks.com
Santa Clara, CA
********************************************************************************