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
- router-router NHRP Yakov Rekhter
- Re: router-router NHRP Andrew Smith
- Re: router-router NHRP Yakov Rekhter
- Re: router-router NHRP Andrew Smith
- Re: router-router NHRP Robert Coltun
- Re: router-router NHRP Norman W. Finn
- Re: router-router NHRP Andrew Smith
- Re: router-router NHRP Curtis Villamizar
- Re: router-router NHRP Andrew G. Malis
- Re: router-router NHRP shur
- Re: router-router NHRP Dimitry Haskin
- Re: router-router NHRP Yakov Rekhter
- Re: router-router NHRP Dimitry Haskin
- Re: router-router NHRP Yakov Rekhter
- Re: router-router NHRP Dimitry Haskin
- Re: router-router NHRP Yakov Rekhter
- Re: router-router NHRP Dimitry Haskin
- Re: router-router NHRP Yakov Rekhter
- Re: router-router NHRP Dimitry Haskin
- Re: router-router NHRP Yakov Rekhter
- Re: router-router NHRP Dimitry Haskin
- Re: router-router NHRP Yakov Rekhter
- Re: router-router NHRP Dimitry Haskin
- Re: router-router NHRP Yakov Rekhter
- Re: router-router NHRP Dimitry Haskin
- Re: router-router NHRP Yakov Rekhter
- Re: router-router NHRP Dimitry Haskin
- Re: router-router NHRP Yakov Rekhter