Capabilities Negotiation with BGP-4
draft-chandra-bgp4-cap-neg-00
| Document | Type | Expired Internet-Draft (individual) | |
|---|---|---|---|
| Authors | John Scudder , Ravi Chandra | ||
| Last updated | 1997-07-17 | ||
| Stream | (None) | ||
| Formats |
Expired & archived
plain text
htmlized
pdfized
bibtex
|
||
| 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) |
https://www.ietf.org/archive/id/draft-chandra-bgp4-cap-neg-00.txt
Abstract
Currently BGP-4 [BGP-4] requires that when a BGP speaker receives an OPEN message with one or more unrecognized Optional Parameters, the speaker must terminate BGP peering. This complicates introduction of new capabilities in BGP. This document defines new Optional Parameter, called Capabilities, that is expected to facilitate introduction of new capabilities in BGP by providing graceful capability negotiation. The proposed parameter is backward compatible - a router that supports the parameter can maintain BGP peering with a router that doesn't support the parameter.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)