Network Working Group Enke Chen
Internet Draft Redback Networks
Expiration Date: February 2004 Srihari R. Sangli
Procket Networks
Dynamic Capability for BGP-4
draft-ietf-idr-dynamic-cap-04.txt
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 except that the right to
produce derivative works is not granted.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
2. Abstract
This document defines a new BGP capability termed "Dynamic
Capability", which would allow the dynamic update of capabilities
over an established BGP session. This capability would facilitate
non-disruptive capability changes by BGP speakers.
Chen & Sangli [Page 1]
Internet Draft draft-ietf-idr-dynamic-cap-04.txt August 2003
3. Introduction
Currently BGP capabilities [BGP-CAP] are only advertised in the OPEN
message during the session initialization. In order to enable a new
capability or remove an existing capability (such as an Address
Family support [BGP-MP]), an established session needs to be reset,
which may disrupt other services running over the session.
This document defines a new BGP capability termed "Dynamic
Capability", which would allow the dynamic update of capabilities
over an established BGP session. This capability would facilitate
non-disruptive capability changes by BGP speakers.
4. Dynamic Capability
The Dynamic Capability is a new BGP capability [BGP-CAP]. The
Capability Code for this capability is specified in the "IANA
Considerations" section of this document. The Capability Length
field of this capability is one octet. The Capability Value field
consists of a list of capability codes (one-octet for each) for which
the dynamic revision is supported by a BGP speaker.
By advertising the Dynamic Capability to a peer in the OPEN, a BGP
speaker conveys to the peer that the speaker is capable of receiving
and properly handling the CAPABILITY message (as defined in the next
Section) from the peer after the BGP session has been established.
5. Capability Message
The CAPABILITY Message is a new BGP message type with type code 6.
In addition to the fixed-size BGP header [BGP-4], the CAPABILITY
message contains one or more of the following tuples:
+------------------------------+
| Action (1 octet) |
+------------------------------+
| Capability Code (1 octet) |
+------------------------------+
| Capability Length (1 octet) |
+------------------------------+
| Capability Value (variable) |
+------------------------------+
The value of the Action field is 0 for advertising a capability, and
Chen & Sangli [Page 2]
Internet Draft draft-ietf-idr-dynamic-cap-04.txt August 2003
1 for removing a capability.
The triple <Capability Code, Capability Length, Capability Value> is
the same as defined in [BGP-CAP], and it specifies a capability for
which the "Action" shall be applied.
6. Operation
A BGP speaker that is willing to receive the CAPABILITY message (for
one or more capability codes) from its peer should use BGP
Capabilities Advertisement [BGP-CAP] to advertise the Dynamic
Capability for these capability codes.
A BGP speaker may send to its peer a CAPABILITY message that contains
one or more capability codes only if these capability codes are
listed in the Dynamic Capability of the OPEN message received from
its peer.
Upon receiving a CAPABILITY message from its peer, if a capability
code in the message is listed in the Dynamic Capability advertised by
the speaker to the peer, the BGP speaker shall update the capability
previously received from that peer based on the "Action" in the
message, and then function in accordance with the revised capability
for the peer. The procedures specified in the "Error Handling"
section should be followed when an error is detected in processing
the CAPABILITY message.
The Dynamic Capability itself can not be revised dynamically via a
CAPABILITY message. The lifetime of the Dynamic Capability is the
duration of the BGP session in which the capability is advertised.
It is also noted that the dynamic capability revision may not be
feasible and should be disallowed for some capabilities. One example
is the four-byte AS number capability [BGP-4BYTE-AS] as its dynamic
update could introduce ambiguity in parsing the UPDATE messages.
Chen & Sangli [Page 3]
Internet Draft draft-ietf-idr-dynamic-cap-04.txt August 2003
7. Error Handling
This document defines a new NOTIFICATION error code:
Error Code Symbolic Name
7 CAPABILITY Message Error
The following error subcodes are defined as well:
Subcode Symbolic Name
1 Invalid Action Value
2 Invalid Capability Length
3 Malformed Capability Value
4 Unsupported Capability Code
If a BGP speaker detects an error while processing a CAPABILITY
message, it MUST send a NOTIFICATION message with Error Code
CAPABILITY Message Error. If any of the defined error subcode is
applicable, the Data field of the NOTIFICATION message MUST contain
the erroneous tuple <Action, Capability Code, Capability Length,
Capability Value> that causes the speaker to send the message.
If the Action field in the CAPABILITY message is other than 0 or 1,
then the error subcode is set to Invalid Action Value.
If the Capability Length field in the CAPABILITY message is incorrect
for a Capability Code, then the error subcode is set to Invalid
Capability Length.
If the Capability Value field in the CAPABILITY message is malformed
(the definition of "malformed" depends on the Capability Code), then
the error subcode is set to Malformed Capability Value.
If the Capability Code in the CAPABILITY message is not any of the
capability codes advertised in the Dynamic Capability by the speaker,
then the error subcode is set to Unsupported Capability Code.
Chen & Sangli [Page 4]
Internet Draft draft-ietf-idr-dynamic-cap-04.txt August 2003
8. IANA Considerations
This document uses a BGP capability code to indicate that a BGP
speaker supports the Dynamic Capability. The capability code has
been assigned by IANA per RFC 2842.
9. Intellectual Property Considerations
This section is taken from Section 10.4 of [RFC-2026].
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
Chen & Sangli [Page 5]
Internet Draft draft-ietf-idr-dynamic-cap-04.txt August 2003
10. Security Considerations
This extension to BGP does not change the underlying security issues.
11. Acknowledgments
The authors would like to thank Yakov Rekhter, Ravi Chandra, Dino
Farinacci, Pedro Marques, Chandrashekhar Appanna, Derek Yeung, Bruno
Rijsman and John Scudder for their review and comments.
12. References
[BGP-4] Y. Rekhter, and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771, March 1995.
[BGP-MP] T. Bates, R. Chandra, D. Katz, and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[BGP-CAP] R. Chandra, J. Scudder, "Capabilities Advertisement with
BGP-4", RFC 2842, May 2000.
[BGP-4BYTE-AS] Q. Vohra, E. Chen, "BGP support for four-octet AS
number space", Work in Progress, <draft-ietf-idr-as4bytes-04.txt>,
September 2001.
[RFC-2026] Bradner, S., "The Internet Standards Process -- Revision
3", RFC 2026, October 1996.
13. Author Information
Enke Chen
Redback Networks, Inc.
350 Holger Way
San Jose, CA 95134
e-mail: enke@redback.com
Srihari R. Sangli
Procket Networks, Inc.
1100 Cadillac Court
Milpitas, CA 95035
e-mail: srihari@procket.com
Chen & Sangli [Page 6]
