Re: router-router NHRP

[Andrew Smith <[e-mail]>]

> From [e-mail] Mon Jul 31 13:25:03 1995
> To: [e-mail]
> Cc: [e-mail]
> Subject: router-router NHRP
> Date: Mon, 31 Jul 95 13:02:07 PDT

Yakov, Bruce,

Did you have any comments on the response I sent a few weeks 
ago (enclosed again below)?

Andrew


********************************************************************************
Andrew Smith					TEL:	[phone]
Technology Synergy Unit				FAX:	[phone]
Bay Networks, Inc.				E-m:	[e-mail]
Santa Clara, CA
********************************************************************************


> Folks,
> 
> Just before the IETF Bruce and myself sent to this list a (rather long)
> note that presents and discusses three possible alternatives on doing
> router-router NHRP. I think it would be useful to get more feedback from
> the group before trying to pick a particular alternative. So, your
> comments/suggestions on our note would be be greatly appreciated.
> Please try to make them in a timely fashion, as we would like to have
> an I-D presented to the group before the next IETF.
> 
> Many thanks in advance.
> 
> Yakov & Bruce.
> 


----- Begin Included Message -----

From [e-mail] Fri Jul 14 16:19:15 1995
Date: Fri, 14 Jul 95 16:02:33 PDT
From: Andrew Smith <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: Re: NHRP for the router-to-router case (somewhat shorter message)
Cc: [e-mail]
Content-Length: 2177

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:	[phone]
Technology Synergy Unit				FAX:	[phone]
Bay Networks, Inc.				E-m:	[e-mail]
Santa Clara, CA
********************************************************************************


----- End Included Message -----