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.