ROLC Overview
yakov@watson.ibm.com Wed, 08 March 1995 14:27 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02933;
8 Mar 95 9:27 EST
Received: from maelstrom.acton.timeplex.com by IETF.CNRI.Reston.VA.US
id aa02926; 8 Mar 95 9:27 EST
Received: from watson.ibm.com (watson.ibm.com [129.34.139.4]) by
maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with SMTP id JAA23024 for
<rolc@acton.timeplex.com>; Wed, 8 Mar 1995 09:17:56 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: yakov@watson.ibm.com
Message-Id: <199503081417.JAA23024@maelstrom.acton.timeplex.com>
Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 4037;
Wed, 08 Mar 95 09:18:51 EST
Date: Wed, 8 Mar 95 09:18:51 EST
To: Juha.Heinanen@lohi.dat.tele.fi
cc: rolc@acton.timeplex.com
Subject: ROLC Overview
Ref: Your note of Wed, 8 Mar 1995 09:36:48 +0200 Juha, >one could also separate the next hop resolution problem from the >address resolution problem. Yes. This may be a viable alternate. >when I saw about two years ago that NHRP has its problems, I proposed a >simple, scalable protocol called NBMA ARP... > >now two years have passed and we don't have anything ! Not exactly. We have an example (granted, long overdue) how NHRP can produce a persistent loop in the router-to-router case. We also have a proposal (described in two I-Ds) about how to do next hop resolution for the case of exterior routers -- note that in contrast with NHRP, this proposal doesn't produce persistent looping. Yakov.
- ROLC Overview j.garrett
- Re: ROLC Overview Juha Heinanen
- ROLC Overview yakov
- Re: ROLC Overview Curtis Villamizar
- Re: ROLC Overview Curtis Villamizar
- ROLC Overview yakov