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