Re: router-router NHRP

[Andrew Smith <[e-mail]>]

> From [e-mail] Mon Jul 31 14:58:07 1995
> To: Andrew Smith <[e-mail]>
> Cc: [e-mail]
> Subject: Re: router-router NHRP 
> In-Reply-To: Your message of "Mon, 31 Jul 95 14:21:53 PDT."
>              <9507312121.AA03245@milliways-le0> 
> Date: Mon, 31 Jul 95 14:54:31 PDT
> From: Yakov Rekhter <[e-mail]>

Yakov,

> There are two separate issues:
>    (a) eliminating extra IP hops across NBMA - "short-cut"
>    (b) determining the Link Layer address at the other end of the "short cut".
> 
> What makes these issues distinct is the dynamics of the information
> that is used. For solving (a) unless the ultimate destination is on the same
> NBMA, the information needed to determine a short cut is the routing (IP
> layer) information. This information is known to be fairly dynamic. For
> solving (b) we need mapping information between IP and Data Link addresses. The
> dynamics of this information is determined by how frequent an ATM node
> moves from one switch to another, or how often the node has to renumber
> (e.g. due to changing IP providers). This information is expected to be
> less dynamic than IP routing information.

That is the opposite of what Norm Finn was saying in an MPOA context a few
months back: to paraphrase, he asserted that the (b) information needed to 
respond on a "Bridging" timescale i.e. order of one Spanning-Tree convergence 
time and that this needed to be much quicker than typical "Routing" 
convergence times for (a). Hence, that routing protocol type of mechanisms 
were inadequate to deal with (b).

Unfortunately, (a) and (b) are coupled because the correct short-cuts and the
exit point to use are defined by the Link Layer address given back (the requester
knows nothing about shortcuts at all - it merely gets back the exit point's
LL address without knowing what sorts of shortcuts, if any, went into its 
calculation). I would hope that the protocol made sure that a requester always had
consistent answers to both (a) and (b), even during routing and bridging 
topology changes: this would be made more difficult if the protocol 
treated them separately.

> 
> Yakov.
> 


Andrew

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