Re: router-router NHRP

Robert Coltun <rcoltun@fore.com> Thu, 03 August 1995 12:46 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11508; 3 Aug 95 8:46 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa11503; 3 Aug 95 8:46 EDT
Received: from maelstrom.acton.timeplex.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id IAA03291; Thu, 3 Aug 1995 08:29:00 -0400
Received: (from root@localhost) by maelstrom.acton.timeplex.com (8.6.12/8.6.12) id IAA12902 for rolc-out; Thu, 3 Aug 1995 08:26:03 -0400
Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.acton.timeplex.com (8.6.12/8.6.12) with ESMTP id IAA12893 for <rolc@nexen.com>; Thu, 3 Aug 1995 08:26:00 -0400
Received: from fore.com (relay.fore.com [169.144.1.1]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id IAA03279 for <rolc@nexen.com>; Thu, 3 Aug 1995 08:25:37 -0400
Received: from dolphin (dolphin.fore.com [169.144.1.16]) by fore.com (8.6.11/8.6.11) with SMTP id IAA24006; Thu, 3 Aug 1995 08:22:02 -0400
Received: from marlin-atm.fore.com by dolphin (4.1/SMI-4.1) id AA09105; Thu, 3 Aug 95 08:22:04 EDT
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Robert Coltun <rcoltun@fore.com>
Received: by marlin-atm.fore.com (4.1/SMI-4.1) id AA03939; Thu, 3 Aug 95 08:22:03 EDT
Date: Thu, 3 Aug 95 08:22:03 EDT
Message-Id: <9508031222.AA03939@marlin-atm.fore.com>
To: yakov@cisco.com
Subject: Re: router-router NHRP
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/

Hi,
	The refreshing of the routed path by the source (or some
intermediate NHS) seems to be the scaling problem here. Perhaps
one way to deal with this is to have the border NHS routers keep state
of the source network or host (and perhaps the last-hop NHS)
and rather than wait for a request to revalidate the resolution,
have the NHS verify that the reverse path is correct for all
entries that relate to a changed route - if it isn't a purge is sent.
There would additionally need to be keep-alives
along the routed (NHS) path so that if a border node fails (or someone
in the NBMA routed path fails) the resolution is also purged.

I belive this is a variation on something proposed in the framework
document (to send a poisoned reverse) as you actually want to 
poison the reverse path.

Comments?

---rob