Maximum Prefix Limit

"Manav Bhatia" <mnvbhatia@yahoo.com> Wed, 16 January 2002 05:27 UTC

Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA21365 for <idr-archive@nic.merit.edu>; Wed, 16 Jan 2002 00:27:01 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 8F42C912AE; Wed, 16 Jan 2002 00:26:21 -0500 (EST)
Delivered-To: idr-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5CEAB912AF; Wed, 16 Jan 2002 00:26:21 -0500 (EST)
Delivered-To: idr@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 40A43912AE for <idr@trapdoor.merit.edu>; Wed, 16 Jan 2002 00:26:20 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 163D45DDCD; Wed, 16 Jan 2002 00:26:20 -0500 (EST)
Delivered-To: idr@merit.edu
Received: from smtp012.mail.yahoo.com (smtp012.mail.yahoo.com [216.136.173.32]) by segue.merit.edu (Postfix) with SMTP id 8945F5DDA0 for <idr@merit.edu>; Wed, 16 Jan 2002 00:26:19 -0500 (EST)
Received: from leased-200-20-226.bng.vsnl.net.in (HELO firewall) (203.200.20.226) by smtp.mail.vip.sc5.yahoo.com with SMTP; 16 Jan 2002 05:26:18 -0000
Message-ID: <03b001c19e4e$aa86e750$b4036c6b@Manav>
Reply-To: Manav Bhatia <mnvbhatia@yahoo.com>
From: Manav Bhatia <mnvbhatia@yahoo.com>
To: idr@merit.edu
Subject: Maximum Prefix Limit
Date: Wed, 16 Jan 2002 10:58:43 +0530
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-idr@merit.edu
Precedence: bulk

Hi,

I am working on BGP implementation of the "maximum prefix limit" feature
which is like a protection mechanism against route leaking. A warning flag
will be raised once the number of prefixes start exceeding some percentage
for the user to do something about it. If nothing happens and the limit
reaches a configured threshold then the BGP session will be torn down.

- In the current draft there is no mechanism for the other end to know of
the reason why the session went down in the first place. IF this is
achieved then the admin at the other end can take some actions to alleviate
the situation.

- Should  the BGP session be restarted after some configured Idle Timer
expiration?

This can result in consistent route flappings which is highly undesirable.

- Should the BGP session be freezed until a manual Restart is given?

- Should there be counters for individual SAFI or should there be a
consolidated one for the entire AFI?

We must have a mechanism wherein we can inform admin guys in the network
leaking routes causing an overflow for us. This issue was brought up some
time back in the list but i saw no apparent conclusion to the whole
discussion ;-)

Is there any intention of introducing a new cease sub-code in the
NOTIFICATION message which will inform both the parties of the reason why
the session was brought down!

Regards,
Manav



----
"When you are courting a nice girl an hour seems like a second. When you
sit on a red-hot cinder a second seems like an hour. That's relativity."

-Albert Einstein, on relativity




_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com