Re: router-router NHRP

"Norman W. Finn" <nfinn@cisco.com> Thu, 03 August 1995 19:29 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23642; 3 Aug 95 15:29 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa23638; 3 Aug 95 15:29 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 PAA06218; Thu, 3 Aug 1995 15:09:13 -0400
Received: (from root@localhost) by maelstrom.acton.timeplex.com (8.6.12/8.6.12) id PAA21890 for rolc-out; Thu, 3 Aug 1995 15:07:05 -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 PAA21881 for <rolc@nexen.com>; Thu, 3 Aug 1995 15:07:02 -0400
Received: from foxhound.cisco.com (foxhound.cisco.com [171.69.1.171]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id PAA06183 for <rolc@nexen.com>; Thu, 3 Aug 1995 15:06:38 -0400
Received: (nfinn@localhost) by foxhound.cisco.com (8.6.8+c/8.6.5) id MAA10932; Thu, 3 Aug 1995 12:04:58 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Norman W. Finn" <nfinn@cisco.com>
Message-Id: <199508031904.MAA10932@foxhound.cisco.com>
Subject: Re: router-router NHRP
To: Andrew Smith <asmith@baynetworks.com>
Date: Thu, 3 Aug 95 12:04:57 PDT
Cc: Yakov Rekhter <yakov@cisco.com>, rolc@nexen.com
In-Reply-To: <9508030137.AA05015@milliways-le0>; from "Andrew Smith" at Aug 2, 95 6:37 pm
X-Mailer: ELM [version 2.3 PL11]
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/

Andrew Smith writes:
> 
> > From yakov@cisco.com Mon Jul 31 14:58:07 1995
> > To: Andrew Smith <asmith@BayNetworks.COM>
> > Subject: Re: router-router NHRP 
> 
> Yakov,
> 
> > There are two separate issues:
> >    (a) eliminating extra IP hops across NBMA - "short-cut"
> >    (b) determining the Link Layer address at the other end of the "short cut".
> > 
> > What makes these issues distinct is the dynamics of the information
> > that is used. For solving (a) unless the ultimate destination is on the same
> > NBMA, the information needed to determine a short cut is the routing (IP
> > layer) information. This information is known to be fairly dynamic. For
> > solving (b) we need mapping information between IP and Data Link addresses. The
> > dynamics of this information is determined by how frequent an ATM node
> > moves from one switch to another, or how often the node has to renumber
> > (e.g. due to changing IP providers). This information is expected to be
> > less dynamic than IP routing information.
> 
> That is the opposite of what Norm Finn was saying in an MPOA context a few
> months back: to paraphrase, he asserted that the (b) information needed to 
> respond on a "Bridging" timescale i.e. order of one Spanning-Tree convergence 
> time and that this needed to be much quicker than typical "Routing" 
> convergence times for (a). Hence, that routing protocol type of mechanisms 
> were inadequate to deal with (b).

If by "Link Layer address" you mean, typically, 48-bit IEEE MAC address,
then this is not what I said.  What I said is that the mapping of layer
3 address to ATM address varies on short timescales because of bridging.
The choice of exit point from the ATM cloud varies on bridging timescales
if the ATM cloud is itself involved in bridging, e.g. VLANs.

If by "Link Layer address" you mean "20-byte ATM address" then yes, that's
what I said.

-- Norm