Protocol Action: Capabilities Advertisement with BGP-4 to Proposed Standard

The IESG <iesg-secretary@ietf.org> Mon, 20 March 2000 13:49 UTC

Received: from loki.ietf.org (loki [10.27.2.29]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06129; Mon, 20 Mar 2000 08:49:47 -0500 (EST)
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA09052 for ietf-123-outbound.10@ietf.org; Mon, 20 Mar 2000 08:35:02 -0500 (EST)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id IAA08922 for <all-ietf@loki.ietf.org>; Mon, 20 Mar 2000 08:19:38 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23188; Mon, 20 Mar 2000 08:19:33 -0500 (EST)
Message-Id: <200003201319.IAA23188@ietf.org>
To: IETF-Announce:;
Cc: RFC Editor <rfc-editor@isi.edu>
Cc: Internet Architecture Board <iab@isi.edu>
Cc: idr@merit.edu
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Capabilities Advertisement with BGP-4 to Proposed Standard
Date: Mon, 20 Mar 2000 08:19:33 -0500
Sender: scoya@cnri.reston.va.us


The IESG has approved the Internet-Draft 'Capabilities Advertisement with
BGP-4' <draft-ietf-idr-bgp4-cap-neg-06.txt> as a Proposed Standard.
This document is the product of the Inter-Domain Routing Working
Group.  The IESG contact persons are David Oran and Rob Coltun.


Technical Summary
 
Currently 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 a new Optional Parameter, called Capabilities,
 that is expected to facilitate introduction of new capabilities in
 BGP by providing graceful capability negotiation without requiring
 that BGP peering be terminated.


Working Group Summary

There was no significant dissent from the working group regarding
this draft. The working group supports the advancement of this document.

Protocol Quality

This draft was reviewed for the IESG by Rob Coltun. There are
multiple implementations.


Note to RFC Editor:

Please replace Section 6 (IANA Considerations) with the following text:

   Section 4 defines a Capability Optional Parameter along with an
   Capability Code field. IANA is expected to create and maintain the
   registry for Capability Code values. Capability Code value 0 is
   reserved. Capability Code values 1 through 63 are to be assigned by
   IANA using the "IETF Consensus" policy defined in RFC2434. Capability
   Code values 64 through 127 are to be assigned by IANA, using the
   "First  Come First Served" policy defined in RFC2434. Capability Code
   values 128 through 255 are for "Private Use" as defined in RFC2434.