Skip to main content

Capabilities Advertisement with BGP-4
RFC 5492

Revision differences

Document history

Date Rev. By Action
2020-07-29
05 (System) Received changes through RFC Editor sync (removed Errata tag (all errata rejected))
2018-12-20
05 (System)
Received changes through RFC Editor sync (changed abstract to 'This document defines an Optional Parameter, called Capabilities, that is expected to facilitate the introduction of …
Received changes through RFC Editor sync (changed abstract to 'This document defines an Optional Parameter, called Capabilities, that is expected to facilitate the introduction of new capabilities in the Border Gateway Protocol (BGP) by providing graceful capability advertisement without requiring that BGP peering be terminated.

This document obsoletes RFC 3392. [STANDARDS-TRACK]')
2015-10-14
05 (System) Notify list changed from idr-chairs@ietf.org, draft-ietf-idr-rfc3392bis@ietf.org to (None)
2012-08-22
05 (System) post-migration administrative database adjustment to the No Objection position for Tim Polk
2009-02-25
05 Cindy Morgan State Changes to RFC Published from RFC Ed Queue by Cindy Morgan
2009-02-25
05 Cindy Morgan [Note]: 'RFC 5492' added by Cindy Morgan
2009-02-25
05 (System) RFC published
2009-01-30
05 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2009-01-29
05 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2009-01-29
05 (System) IANA Action state changed to In Progress from Waiting on Authors
2009-01-28
05 (System) IANA Action state changed to Waiting on Authors from In Progress
2009-01-27
05 (System) IANA Action state changed to In Progress from Waiting on ADs
2009-01-26
05 (System) IANA Action state changed to Waiting on ADs from In Progress
2009-01-26
05 (System) IANA Action state changed to In Progress from Waiting on Authors
2009-01-21
05 (System) IANA Action state changed to Waiting on Authors from In Progress
2009-01-14
05 (System) IANA Action state changed to In Progress
2009-01-14
05 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2009-01-14
05 Amy Vezza IESG state changed to Approved-announcement sent
2009-01-14
05 Amy Vezza IESG has approved the document
2009-01-14
05 Amy Vezza Closed "Approve" ballot
2009-01-08
05 Cindy Morgan State Changes to Approved-announcement to be sent::Point Raised - writeup needed from Waiting for AD Go-Ahead by Cindy Morgan
2009-01-08
05 Dan Romascanu [Ballot comment]
2009-01-08
05 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk
2009-01-08
05 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk
2009-01-08
05 Jari Arkko [Ballot Position Update] New position, Yes, has been recorded by Jari Arkko
2009-01-08
05 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2009-01-08
05 Chris Newman [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman
2009-01-08
05 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson
2009-01-08
05 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2009-01-08
05 Dan Romascanu [Ballot comment]
I support the DISCUSS raised by Tim.
2009-01-07
05 Pasi Eronen
[Ballot comment]
Minor nit (which could be fixed during RFC Editor processing):
The "IETF Consensus" policy has been renamed to "IETF Review"
in RFC 5226 …
[Ballot comment]
Minor nit (which could be fixed during RFC Editor processing):
The "IETF Consensus" policy has been renamed to "IETF Review"
in RFC 5226, so Section 6 should be updated accordingly.
2009-01-07
05 Pasi Eronen [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen
2009-01-07
05 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2009-01-07
05 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley
2009-01-07
05 (System) New version available: draft-ietf-idr-rfc3392bis-05.txt
2009-01-07
05 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2009-01-07
05 Russ Housley
[Ballot comment]
Elwyn Davies performed a Gen-ART Review, and he pointed out that
  there does not appear to be an IANA registry for OPEN …
[Ballot comment]
Elwyn Davies performed a Gen-ART Review, and he pointed out that
  there does not appear to be an IANA registry for OPEN message
  (optional) parameter types.  Should one be established?
2009-01-06
05 Tim Polk
[Ballot comment]
I believe a second paragraph should be added to the introduction.  The current
text reads:

  The base BGP-4 specification [RFC4271] …
[Ballot comment]
I believe a second paragraph should be added to the introduction.  The current
text reads:

  The base BGP-4 specification [RFC4271] requires that when a BGP
  speaker receives an OPEN message with one or more unrecognized
  Optional Parameters, the speaker must terminate the BGP peering.
  This complicates the introduction of new capabilities in BGP.

On first reading, I assumed this specification modified the processing rules
for unrecognized Optional Parameters.  Perhaps another paragraph to explain
the strategy would be useful.  Perhaps something along the following lines
would be useful:

  This specification defines an Optional Parameter and processing rules
  that allows BGP speakers to communicate capabilities in an OPEN message.
  BGP speakers that both support this specification can maintain the peering
  even when presented with unrecognized capabilities, so long as all capabilities
  required to support the peering are supported.
2009-01-06
04 (System) New version available: draft-ietf-idr-rfc3392bis-04.txt
2009-01-06
05 Tim Polk
[Ballot discuss]
This discuss extends the issue raised in Pekka Savola's Ops directorate review.  In addition
to clarifying the specific text Pekka highlighted,  the compliance …
[Ballot discuss]
This discuss extends the issue raised in Pekka Savola's Ops directorate review.  In addition
to clarifying the specific text Pekka highlighted,  the compliance language needs to be
reviewed and scrubbed throughout.

Two specific instances that trouble me are noted below.

From Section 3, Overview of Operation, paragraph 4:

  If a BGP speaker that supports a certain capability requires that
  this capability be used on a peering but determines that its peer
  doesn't support this capability, the speaker MAY send a NOTIFICATION
  message to the peer and terminate peering (see Section "Extensions to
  Error Handling" for more details).

Why isn't this MUST - what other options exist?  My reading of 4271 indicates
that the BGP speaker MUST send a NOTIFICATION message with the error code
OPEN Error Message.  (Section 6.2, first sentence.) Are we modifying that
requirement?  It would also seem that the BGP speaker MUST terminate
the peering. 

In Section 5, Extensions to Error Handling, paragraph 1:

  The Data field in the NOTIFICATION
  message SHOULD list the set of capabilities that cause the speaker to
  send the message.

Why isn't this a MUST?
2009-01-06
05 Tim Polk [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk
2009-01-06
05 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2009-01-05
05 David Ward Note that RFC3329 is a Draft Standard.
2009-01-05
05 David Ward Intended Status has been changed to Draft Standard from Proposed Standard
2009-01-03
05 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2008-12-31
05 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Rob Austein.
2008-12-25
05 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2008-12-24
05 Amanda Baber
IANA Last Call questions/comments:

- Where is the Capabilities Optional Parameter (2) registered?

- Where is the "Unsupported Capability" Error Subcode (7) registered?

Upon approval …
IANA Last Call questions/comments:

- Where is the Capabilities Optional Parameter (2) registered?

- Where is the "Unsupported Capability" Error Subcode (7) registered?

Upon approval of this document, IANA will make the following
changes in the "Capability Codes" registry at
http://www.iana.org/assignments/capability-codes/capability-codes.xhtml

OLD:

Reference
[RFC3392]

Value Description Reference
----- ----------- ---------
0 Reserved [RFC3392]

NEW:

Reference
[RFC3392][RFC-idr-rfc3392bis-03]

Value Description Reference
----- ----------- ---------
0 Reserved [RFC3392][RFC-idr-rfc3392bis-03]


We understand the above to be the only IANA Action for this document.
2008-12-16
03 (System) New version available: draft-ietf-idr-rfc3392bis-03.txt
2008-12-13
05 Samuel Weiler Request for Last Call review by SECDIR is assigned to Rob Austein
2008-12-13
05 Samuel Weiler Request for Last Call review by SECDIR is assigned to Rob Austein
2008-12-11
05 Amy Vezza Last call sent
2008-12-11
05 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2008-12-10
05 David Ward [Ballot Position Update] New position, Yes, has been recorded for David Ward
2008-12-10
05 David Ward Ballot has been issued by David Ward
2008-12-10
05 David Ward Created "Approve" ballot
2008-12-10
05 David Ward Last Call was requested by David Ward
2008-12-10
05 David Ward State Changes to Last Call Requested from Publication Requested by David Ward
2008-12-10
05 (System) Ballot writeup text was added
2008-12-10
05 (System) Last call text was added
2008-12-10
05 (System) Ballot approval text was added
2008-12-10
05 David Ward Draft Added by David Ward in state Publication Requested
2008-12-10
02 (System) New version available: draft-ietf-idr-rfc3392bis-02.txt
2008-11-18
01 (System) New version available: draft-ietf-idr-rfc3392bis-01.txt
2008-05-23
00 (System) New version available: draft-ietf-idr-rfc3392bis-00.txt