Re: NHRP for the router-to-router case (somewhat shorter message)
Andrew Smith <asmith@baynetworks.com> Fri, 14 July 1995 23:38 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07756;
14 Jul 95 19:38 EDT
Received: from [204.249.96.18] by IETF.CNRI.Reston.VA.US id aa07752;
14 Jul 95 19:38 EDT
Received: from maelstrom.acton.timeplex.com (maelstrom.nexen.com
[204.249.97.5]) by nexen.nexen.com (8.6.12/8.6.12) with ESMTP id TAA05192;
Fri, 14 Jul 1995 19:06:52 -0400
Received: (from root@localhost) by maelstrom.acton.timeplex.com
(8.6.12/8.6.12) id TAA23339 for rolc-out; Fri, 14 Jul 1995 19:03:29 -0400
Received: from nexen.nexen.com ([204.249.96.18]) by
maelstrom.acton.timeplex.com (8.6.12/8.6.12) with ESMTP id TAA23330 for
<rolc@nexen.com>; Fri, 14 Jul 1995 19:03:27 -0400
Received: from lightning.synoptics.com (lightning.synoptics.com
[134.177.3.18]) by nexen.nexen.com (8.6.12/8.6.12) with SMTP id TAA05066 for
<rolc@nexen.com>; Fri, 14 Jul 1995 19:03:25 -0400
Received: from BayNetworks.COM ([134.177.1.95]) by lightning.synoptics.com
(4.1/SMI-4.1) id AA13626; Fri, 14 Jul 95 15:59:39 PDT
Received: from milliways-le0 (milliways-le0.synoptics.com) by BayNetworks.COM
(4.1/SMI-4.1) id AA05757; Fri, 14 Jul 95 16:00:38 PDT
Received: by milliways-le0 (4.1/2.0N) id AA16014; Fri, 14 Jul 95 16:02:33 PDT
Message-Id: <9507142302.AA16014@milliways-le0>
Date: Fri, 14 Jul 95 16:02:33 PDT
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Andrew Smith <asmith@baynetworks.com>
To: yakov@cisco.com, bcole@cisco.com, nfinn@cisco.com
Subject: Re: NHRP for the router-to-router case (somewhat shorter message)
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/
The basic issue here seems to be that the group is trying to shoe-horn one protocol (NHRP) into two very different applications: (a) the host address convergance (short-cutting routers) protocol and (b) a router-router protocol to support the former. The current draft "draft-ietf-rolc-nhrp-04" admits this by saying that router-router cases will be described in a separate specification. It seems like the (a) protocol is nearly complete (modulo a few simple things like management, auto-configuration, redundancy, scalability) and the (b) protocol is going to need a lot of the bolt-on extras that you discuss in your message. How about we make this distinction absolutely clear to the outside world? Then we can really design a (b) protocol that works properly without the artificial constraints of keeping it backward-compatible with (a). That approach would also lead to significant simplifications for the (a) protocol, in particular allowing the addressing of first-hop queries to the NHS in fabric mode (significant auto-configuration and multi-protocol benefits), rather than having to wrap them in an IPgram and having to pre-configure a default NHS. I don't believe that there is even a need to constrain the packet formats for (a) and (b) to be the same. There is also an argument to be had about whether a fully specified, 100-page document for protocol (b) is worth writing, giving the already excessive number of routing protocols already in existence (this *is* a routing protocol we are talking about, regardless of what some have claimed in the past). We could wait and have this later on when we see how many pages there are if you would prefer :-) Just my 1c worth - I hope people read this before the ROLC meeting next week. Andrew ******************************************************************************** Andrew Smith TEL: +1 408 764 1574 Technology Synergy Unit FAX: +1 408 988 5525 Bay Networks, Inc. E-m: asmith@baynetworks.com Santa Clara, CA ******************************************************************************** P.S. Instructions: 1. Light blue touch paper 2. Lob grenade 3. Cover ears 4. Wait for explosion
- Re: NHRP for the router-to-router case (somewhat … Andrew Smith
- Re: NHRP for the router-to-router case (somewhat … Juha Heinanen
- Re: NHRP for the router-to-router case (somewhat … Yakov Rekhter