Network Working Group Enke Chen Internet Draft Redback Networks Expiration Date: October 2002 Srihari R. Sangli Procket Networks Dynamic Capability for BGP-4 draft-ietf-idr-dynamic-cap-02.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-02.txt April 2002 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 set to 0. 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 1 for removing a capability. Chen & Sangli [Page 2] Internet Draft draft-ietf-idr-dynamic-cap-02.txt April 2002 The triple is the same as defined in [BGP-CAP], and it specifies a capability for which the "Action" shall be applied. 6. Error Handling A new NOTIFICATION error code is defined: 7 CAPABILITY Message Error which has the following error subcodes: 1 Invalid Action Value 2 Invalid Capability Length 3 Malformed Capability Value If the Action field of a received CAPABILITY message is other than 0 or 1, then a NOTIFICATION message with the error subcode "Invalid Action Value" MUST be sent and the data field of the NOTIFICATION message MUST contain the erroneous Action field. If the Capability Length field of a received CAPABILITY message is incorrect for a Capability Code, then a NOTIFICATION message with the error subcode "Invalid Capability Length" MUST be sent and the data field of the NOTIFICATION message MUST contain the Capability Code and the Capability Length fields. If the Capability Value field of a received CAPABILITY message is malformed (the definition of "malformed" depends on the Capability Code), then a NOTIFICATION message with the error subcode "Malformed Capability Value" MUST be sent and the data field of the NOTIFICATION message MUST contain the Capability Code, Capability Length, and the Capability Value fields. 7. Operation A BGP speaker that is willing to receive the CAPABILITY message from its peer should advertise the Dynamic Capability to the peer using BGP Capabilities advertisement [BGP-CAP]. A BGP speaker may send a CAPABILITY message to its peer only if it has received the Dynamic Capability from its peer. 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. Chen & Sangli [Page 3] Internet Draft draft-ietf-idr-dynamic-cap-02.txt April 2002 Upon receiving a CAPABILITY message from its peer, the BGP speaker shall update the capabilities previously received from that peer based on the "Action" in the message, and then function in accordance with the revised capabilities for the peer. Any unrecognized capabilities in the message should be ignored. It is noted that the dynamic capability update 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. 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 Cisco Systems may seek patent or other intellectual property protection for some of all of the technologies disclosed in this document. If any standards arising from this document are or become protected by one or more patents assigned to Cisco Systems, Cisco intends to disclose those patents and license them on reasonable and non-discriminatory terms. 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 and Chandrashekhar Appanna for their review and comments. We also would like to thank Bruno Rijsman for suggesting the initial text for the Error Handling section. Chen & Sangli [Page 4] Internet Draft draft-ietf-idr-dynamic-cap-02.txt April 2002 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, , September 2001. 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 5]