Time to revise RFC 1771

Wed Jun 27 06:56:36 UTC 2001

On Tue, Jun 26, 2001 at 09:32:10PM -0700, Sean Donelan wrote:
>
> I would prefer we try to maintain the BGP sessions.  But if you think
> your peer's protocol implementation is flawed, cycling the BGP session
> is unlikely to fix the software.  It just makes things worse as you
> announce and withdrawl sections of the route table repeatedly.  Shutdown
> the session (and keep it down) and wait for human intervention.

Well not to play Dr. Obvious, but to quote a spec people claim to be
following:

         If a BGP speaker detects an error, it shuts down the connection
         and changes its state to Idle. Getting out of the Idle state
         requires generation of the Start event.  If such an event is
         generated automatically, then persistent BGP errors may result
         in persistent flapping of the speaker.  To avoid such a
         condition it is recommended that Start events should not be
         generated immediately for a peer that was previously
         transitioned to Idle due to an error. For a peer that was
         previously transitioned to Idle due to an error, the time
         between consecutive generation of Start events, if such events
         are generated automatically, shall exponentially increase. The
         value of the initial timer shall be 60 seconds. The time shall
         be doubled for each consecutive retry.

So if you want to see it used, get on your vendor about it...

Also, RFC1771 is pretty out of date, the "least incorrect" reference
currently available is:

http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-12.txt

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
PGP Key ID: 0x138EA177  (67 29 D7 BC E8 18 3E DA  B2 46 B3 D8 14 36 FE B6)