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

Andrew Smith <asmith@baynetworks.com> Fri, 03 November 1995 23:53 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29510; 3 Nov 95 18:53 EST
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa29506; 3 Nov 95 18:53 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 SAA14020; Fri, 3 Nov 1995 18:24:25 -0500
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id SAA02463 for rolc-out; Fri, 3 Nov 1995 18:34:13 -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 SAA02454 for <rolc@nexen.com>; Fri, 3 Nov 1995 18:34: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 SAA13957 for <rolc@nexen.com>; Fri, 3 Nov 1995 18:21:09 -0500
Received: from pobox.synoptics.com ([134.177.1.95]) by lightning.synoptics.com (4.1/SMI-4.1) id AA14599; Fri, 3 Nov 95 15:28:01 PST
Received: from milliways-le0.engwest (milliways-le0.synoptics.com) by pobox.synoptics.com (4.1/SMI-4.1) id AA17408; Fri, 3 Nov 95 15:29:24 PST
Received: by milliways-le0.engwest (4.1/SMI-4.1) id AA03000; Fri, 3 Nov 95 15:29:22 PST
Date: Fri, 3 Nov 95 15:29:22 PST
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Andrew Smith <asmith@baynetworks.com>
Message-Id: <9511032329.AA03000@milliways-le0.engwest>
To: gardo@vnet.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/

Russell,

> NHRP should be flexible enough to allow clients to specify which
> packet types (Reply and/or Purge) are supported for the destination
> prefix extension.

I think we should try to simplify the protocol by allowing fewer options.
I believe that the overall system complexity will be lower, even if 
individual client complexity is higher (think globally, act locally :-))
if we insist all clients behave the same in this regard.

> Therefore, why not add another extension called the "purge mask
> extension" with the discretionary flag = 0.  This way the destination
> prefix extension in the Reply can remain a discretionary extension.
> Maybe this proposal is acceptable?  This proposal addresses the
> following problems:

>   1) No flags in the dest prefix extension used in Reply packets
Good!

>   2) Destination Prefix Extension remains discretionary
Is it a feature or a bug that it is discretionary?

>   3) Only clients that support a purge with mask will receive this
>      extension
>   4) The new extension is not discretionary, never ignored...
You've effectively moved the problem back to a once-off initialisation-time
negotiation. I'd rather have no negotiation at all: make it mandatory!


> Good night!
> -- Russell
> 

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