Re: router-router NHRP

Yakov Rekhter <yakov@cisco.com> Wed, 15 November 1995 00:49 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26670; 14 Nov 95 19:49 EST
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa26666; 14 Nov 95 19:49 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 TAA08226; Tue, 14 Nov 1995 19:14:22 -0500
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id TAA29068 for rolc-out; Tue, 14 Nov 1995 19:28:03 -0500
Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.6.12/8.6.12) with ESMTP id TAA29059 for <rolc@nexen.com>; Tue, 14 Nov 1995 19:27:57 -0500
Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by nexen.nexen.com (8.6.12/8.6.12) with ESMTP id TAA23215 for <rolc@nexen.com>; Tue, 14 Nov 1995 19:25:29 -0500
Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id QAA23311; Tue, 14 Nov 1995 16:18:55 -0800
Message-Id: <199511150018.QAA23311@hubbub.cisco.com>
To: Dimitry Haskin <dhaskin@baynetworks.com>
cc: rolc@nexen.com
Subject: Re: router-router NHRP
In-reply-to: Your message of "Tue, 14 Nov 95 18:50:25 EST." <9511142350.AA13444@pobox.BayNetworks.com>
Date: Tue, 14 Nov 95 16:18:49 PST
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Yakov Rekhter <yakov@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/

Dimitry,

> > Consider a router X within an OSPF domain, ASBR Y of that domain, and
> > router Z (outside of the OSPF domain) that peers with Y using BGP.  Z
> > advertises to Y a route to some destination D, and puts its own address
> > as the next hop. Y injects this route into OSPF.  When X originates an
> > NHRP Request for D, and the Request reaches Y, Y has a route to D, but
> > the next hop on this route is not Y, but Z. Y returns Z as the next hop
> > in the NHRP Reply. Since Y certainly sees any changes in this route, Y
> > would be able to send to X a Purge message once Y notices the changes.
> > 
> 
> Good.  But there is no text in your proposal that requires a proxy router tha
t
> replied with a third party address to send a Purge message to the originator
> of the shortcut.  The proposal should be clear on that since there are
> certain implications of such a requirement, e.g. the amount of state that nee
d
> to be saved at a proxy router, especially if such a router is a proxy for
> a good number of edge forwarders.

The text of my proposal certainly could be improved.

Yakov.