BGP Notification Cease: I'll Be Back
draft-ward-bgp4-ibb-00
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Authors | John Scudder , David Ward | ||
| Last updated | 1999-06-21 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
Many recent router architectures decouple the routing engine from the forwarding engine, so that packet forwarding can continue even if routing software is not active. The current definition of the BGP protocol does not support this. We propose a new variety of CEASE NOTIFICATION message (IBB) which indicates to a peer that the router sending the notification expects to be able to continue forwarding traffic for a certain period of time without an established BGP peering session. We also propose a new OPEN message (ICB) that if received during the HOLDTIME period, does not require conventional reestablishment of the BGP peering session. These capabilities are useful for orderly and non-intrusive routing software updates, operating system updates, AS number migration, redundancy and catastrophic event handling.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)