Re: NHRP domino effect

Andrew Smith <asmith@baynetworks.com> Fri, 14 July 1995 23:24 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07374; 14 Jul 95 19:24 EDT
Received: from [204.249.96.18] by IETF.CNRI.Reston.VA.US id aa07370; 14 Jul 95 19:24 EDT
Received: from maelstrom.acton.timeplex.com (maelstrom.nexen.com [204.249.97.5]) by nexen.nexen.com (8.6.12/8.6.12) with ESMTP id RAA03883; Fri, 14 Jul 1995 17:58:47 -0400
Received: (from root@localhost) by maelstrom.acton.timeplex.com (8.6.12/8.6.12) id RAA22388 for rolc-out; Fri, 14 Jul 1995 17:53:24 -0400
Received: from nexen.nexen.com ([204.249.96.18]) by maelstrom.acton.timeplex.com (8.6.12/8.6.12) with ESMTP id RAA22379 for <rolc@nexen.com>; Fri, 14 Jul 1995 17:53:20 -0400
Received: from lightning.synoptics.com (lightning.synoptics.com [134.177.3.18]) by nexen.nexen.com (8.6.12/8.6.12) with SMTP id RAA03854 for <rolc@nexen.com>; Fri, 14 Jul 1995 17:53:18 -0400
Received: from BayNetworks.COM ([134.177.1.95]) by lightning.synoptics.com (4.1/SMI-4.1) id AA12614; Fri, 14 Jul 95 14:50:06 PDT
Received: from milliways-le0 (milliways-le0.synoptics.com) by BayNetworks.COM (4.1/SMI-4.1) id AA04629; Fri, 14 Jul 95 14:51:12 PDT
Received: by milliways-le0 (4.1/2.0N) id AA15967; Fri, 14 Jul 95 14:53:07 PDT
Message-Id: <9507142153.AA15967@milliways-le0>
Date: Fri, 14 Jul 95 14:53:07 PDT
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Andrew Smith <asmith@baynetworks.com>
To: rolc@nexen.com, yakov@cisco.com
Subject: Re: NHRP domino effect
Cc: bcole@cisco.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 owner-rolc@nexen.com Tue Jul 11 15:55:22 1995
> To: rolc@nexen.com
> Cc: bcole@cisco.com
> Subject: NHRP domino effect
> Date: Tue, 11 Jul 95 15:35:39 PDT
> From: Yakov Rekhter <yakov@cisco.com>

Yakov,

> The NHRP domino effect is clearly undesirable. 
....
> One possible solution for suppressing the domino effect would be to
> require that when a router forwards an NHRP Request, the router
> instantiates a (short-lived) state. The state just contains the route
> that was used to forward the request. If the router receives a packet,
> and the packet triggers an NHRP Request generation by the router, the
> router checks whether the route to forward the request was recently
> used to forward another request. If yes, then the router doesn't 
> generate the request (but still forwards the packet). This solution
> also requires that when a router wants to originate an NHRP Request the
> router should send the request before the data packet that triggered
> the origination of the request.

I think some router implementations might have trouble implementing 
this requirement, yours and ours included :-)


Andrew


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