Subject: [Idr] Protocol Action: 'Subcodes for BGP Cease Notification Message' to Proposed Standard

From: The IESG <[email-masked]>
Date: Thu, 23 Feb 2006 18:09:13 -0500

The IESG has approved the following document:

- 'Subcodes for BGP Cease Notification Message '
   <draft-ietf-idr-cease-subcode-07.txt> as a Proposed Standard

This document is the product of the Inter-Domain Routing Working Group. 

The IESG contact persons are Bill Fenner and Alex Zinin.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-cease-subcode-07.txt

Technical Summary
 
   This document defines several subcodes for the BGP Cease NOTIFICATION
   message that provide more information to aid network operators
   in correlating network events and diagnosing BGP peering issues.
 
Working Group Summary
 
   The Working Group had consensus to  publish this document as
   Proposed Standard.
 
Protocol Quality
 
   Bill Fenner reviewed this document for the IESG.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Erblichs <[email-masked]>
Date: Thu, 23 Feb 2006 18:11:25 -0800

Group,

	I like to always ask some things after the fact.

	4. Subcode Usage

  It is RECOMMENDED that a BGP speaker behave as though the
   DampPeerOscillations attribute [BGP-4] was true for this peer when
   re-trying a BGP connection after the speaker receives a Cease
   NOTIFICATION message with subcode of "Administrative Shutdown", or

   "Peer De-configured", or "Connection Rejected", or "Out of
   Resources".  An implementation SHOULD impose an upper bound on the
   number of consecutive automatic retries. Once this bound is reached,
   the implementation would stop re-trying any BGP connections until
   some administrative intervention, i.e., set the AllowAutomaticStart
   attribute [BGP-4] to FALSE.

	----

	I understand RECOMMENDED, but would a multiplicative
	backoff algorithm be a better method of consective
	retries? Why wasn't this suggested/Recommended?

	IMO, for the later is iff case #1, some type of issue occured
	that lost  all/most of TCP connections, all of the past peers
	would bombard the BGP speaker with repeated almost simultaneous
	connection retries.

	And Once a upper bound has been reached, why suggest administrative
	intervention versus a very long retry period? If this other
	implementation were used, wouldn't it still recover once the
	issue was resolved at the other BGP speaker without requiring
	manual intervention at a possibly non-local BGP speaker?

	Thanks, Mitchell Erblich

---

From: "Maneesh Chawla" <[email-masked]>
Date: Fri, 24 Feb 2006 12:55:43 +0530

Hi All,
      Just a little question : Will multiplicative back off combined with
upper bound on number of retries be helpful ?
Say , case where the administrator on the other BGP speaker has decided to
shut it for a definite and longer period of time. In such a case , the BGP
speaker would unneccessarily be sending out retries (though backed off
multiplicatively).

Thanks
Maneesh