Re: Latest NHRP draft

Bruce Cole <bcole@cisco.com> Thu, 25 May 1995 21:05 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08401; 25 May 95 17:05 EDT
Received: from maelstrom.acton.timeplex.com by IETF.CNRI.Reston.VA.US id aa08397; 25 May 95 17:05 EDT
Received: (from root@localhost) by maelstrom.acton.timeplex.com (8.6.12/ACTON-MAIN-1.2) id RAA01697 for rolc-out; Thu, 25 May 1995 17:01:41 -0400
Received: from greatdane.cisco.com (greatdane.cisco.com [171.69.1.141]) by maelstrom.acton.timeplex.com (8.6.12/ACTON-MAIN-1.2) with ESMTP id RAA01692 for <rolc@maelstrom.Timeplex.COM>; Thu, 25 May 1995 17:01:37 -0400
Received: from cisco.com (localhost.cisco.com [127.0.0.1]) by greatdane.cisco.com (8.6.8+c/8.6.5) with ESMTP id OAA14935; Thu, 25 May 1995 14:01:32 -0700
Message-Id: <199505252101.OAA14935@greatdane.cisco.com>
To: dhc2@gte.com
Cc: bcole@cisco.com, Robert.G.Cole@att.com, dkatz@cisco.com, rolc@maelstrom.timeplex.com
Subject: Re: Latest NHRP draft
In-Reply-To: Your message of "Thu, 25 May 1995 16:29:05 EDT." <9505252029.AA04417@minuteman.gte.com>
Date: Thu, 25 May 1995 14:01:31 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Bruce Cole <bcole@cisco.com>
X-Orig-Sender: owner-rolc@maelstrom.timeplex.com
Precedence: bulk
X-Info: Submissions to rolc@maelstrom.timeplex.com
X-Info: [Un]Subscribe requests to rolc-request@maelstrom.timeplex.com
X-Info: Archives for rolc via ftp://ietf.cnri.reston.va.us/ietf-mail-archive/rolc/

> Can you elaborate on how rate limiting would prevent
> multiple VCs from occuring when the NHRP request goes through multiple
> NHSs towards its destination.

First: I was not arguing that rate limiting prevents multiple VCs in general.

In this particular case, multiple VCs can be avoided through rate limiting.
Specifically: router B receives an NHRP request from router A.  Depending
upon packet ordering, B may or may not have already received the original
IP packet which A is trying to forward to D.  If the original IP packet
has not yet been received when B receives the NHRP request, then B
may suppress sending an NHRP request of its own, to provide rate limiting.  If
the original IP packet came first, then B probably already sent an NHRP
request of its own.  When the NHRP packet from A comes along, B may then drop
A's request due to rate limiting.

C behaves similarly.  End result is only 1 NHRP request to resolve, so only
1 VC is established.

> Does this method guarantee that multiple VCs will not occur?

No.

> If the source has multiple NHRP requests within a short period of time,
> would rate limiting affect the subsequent requests?

Yes or no depending upon rate limiting policy.  If the policy is to
allow X NHRP packet within interval Y, then subsequent requests may or
may not be dropped depending upon the values for X and Y.