Re: router-router NHRP

Dimitry Haskin <dhaskin@baynetworks.com> Thu, 09 November 1995 15:08 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12474; 9 Nov 95 10:08 EST
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa12470; 9 Nov 95 10:08 EST
Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id JAA09822; Thu, 9 Nov 1995 09:39:32 -0500
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id JAA01420 for rolc-out; Thu, 9 Nov 1995 09:49:19 -0500
Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.6.12/8.6.12) with ESMTP id JAA01411 for <rolc@nexen.com>; Thu, 9 Nov 1995 09:49:15 -0500
Received: from lobster.wellfleet.com (lobster.wellfleet.com [192.32.253.3]) by nexen.nexen.com (8.6.12/8.6.12) with SMTP id JAA17639 for <rolc@nexen.com>; Thu, 9 Nov 1995 09:47:10 -0500
Received: from pobox.BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA21550; Thu, 9 Nov 95 09:44:45 EST
Received: from andover.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA08958; Thu, 9 Nov 95 09:45:48 EST
Date: Thu, 9 Nov 95 09:45:48 EST
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Dimitry Haskin <dhaskin@baynetworks.com>
Message-Id: <9511091445.AA08958@pobox.BayNetworks.com>
To: yakov@cisco.com
Subject: Re: router-router NHRP
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/

Yakov,

> Subject: Re: router-router NHRP 
> Date: Wed, 08 Nov 95 18:39:00 PST
> From: Yakov Rekhter <yakov@cisco.com>
> 
> Dimitry,
> 
> > I don't believe you've answered my question on the *implication* (not
> > intention) of the "first NHRP target constraint".  To reiterate,  does
> > this constraint require that a Request can be only originated if
> > a route to the requested target is already present in the originating
> > forwarder FIB?  And if so, wouldn't it mandate a large FIB in some cases?
> 
> This constraint does not imply that the originator of a Request has to
> maintain in its FIB a route that covers precisely the same set of
> destinations as the target, priot to issuing the Request.
> For example, the originator of a Request may have in its FIB a route
> to 192.9.200/24, but may generate NHRP Request for 192.9.9.200.9
> as the target.  
> 

It seems that we fail to communicate.  I never said that your "first
constraint" requires the originator to "maintain in its FIB a route
that covers *precisely* the same set of destinations as the target".
I said (and I believe that you've just confirmed it) that it requires
the originator to carry *a* route to the target which, of cause, can
be a supperset of the target.  If we take as an example a transient
domain with a need to carry the complete Internet set of target, it can
account for circa 30,000 routes to cover the reachable destinations.

Dimitry