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

Andrew Smith <asmith@baynetworks.com> Sat, 04 November 1995 00:12 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29913; 3 Nov 95 19:12 EST
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa29909; 3 Nov 95 19:12 EST
Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id SAA14275; Fri, 3 Nov 1995 18:45:21 -0500
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id SAA02614 for rolc-out; Fri, 3 Nov 1995 18:55:14 -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 SAA02605 for <rolc@nexen.com>; Fri, 3 Nov 1995 18:55:11 -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 SAA14198 for <rolc@nexen.com>; Fri, 3 Nov 1995 18:42:04 -0500
Received: from pobox.synoptics.com ([134.177.1.95]) by lightning.synoptics.com (4.1/SMI-4.1) id AA15109; Fri, 3 Nov 95 15:48:58 PST
Received: from milliways-le0.engwest (milliways-le0.synoptics.com) by pobox.synoptics.com (4.1/SMI-4.1) id AA18045; Fri, 3 Nov 95 15:50:21 PST
Received: by milliways-le0.engwest (4.1/SMI-4.1) id AA03055; Fri, 3 Nov 95 15:50:20 PST
Date: Fri, 3 Nov 95 15:50:20 PST
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Andrew Smith <asmith@baynetworks.com>
Message-Id: <9511032350.AA03055@milliways-le0.engwest>
To: debruin@raleigh.ibm.com
Subject: Re: nhrp-05 ????? - Destination Prefix Extension
Cc: rolc@nexen.com
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 debruin@raleigh.ibm.com Fri Nov  3 08:36:31 1995
> From: debruin@raleigh.ibm.com
> Date: Fri, 3 Nov 1995 11:31:50 -0500
> To: asmith@BayNetworks.COM, bcole@cisco.com
> Subject: Re: nhrp-05 ????? - Destination Prefix Extension
> Cc: debruin@raleigh.ibm.com, gardo@vnet.ibm.com, rolc@nexen.com

Chris,

>    I think that we need to include the ablility to support a mask.  Not only
> would this reduce the traffic load (which is probably not the best argument 
> for something like this),

That would be, for me, the *only* reason to include this feature!

> but will also add flexability to the spec that 
> allows for some innovations in the implementations.  

Come on - what are we building here, a research toy or a robust
protocol for our customers to use in real networks?

>    I agree with Andrew and would like to see it as a MANDATORY part of 
> the spec.  I think this feature would add a great deal of flexability
> without requiring too much additional work on the client side. 

I see flexibility as a bug, not a feature.
...
>    I propose put the mask in the mandatory part of the purge packet and 
> requiring all client to support it.  This gets us away from any discussions 
> of the semantics of placing extensions in the purge packet, which is kind 
> of messy anyway.  

Well, at least we reach the same conclusion :-)

> 
> - chris
>

Andrew


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