Network Working Group Enke Chen
Internet Draft Redback Networks
Expiration Date: January 2002 Srihari Ramachandra
Procket Networks
Dynamic Capability for BGP-4
draft-chen-bgp-dynamic-cap-01.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 & Ramachandra [Page 1]
Internet Draft draft-chen-bgp-dynamic-cap-01.txt July 2001
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 may need to be
reset, which would 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] with
Capability code <TBD> and Capability length 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
<TBD>. 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.
The triple <Capability Code, Capability Length, Capability Value> is
the same as defined in [BGP-CAP], and it specifies a capability for
Chen & Ramachandra [Page 2]
Internet Draft draft-chen-bgp-dynamic-cap-01.txt July 2001
which the "Action" shall be applied.
6. 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.
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.
7. 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.
8. Security Considerations
This extension to BGP does not change the underlying security issues.
Chen & Ramachandra [Page 3]
Internet Draft draft-chen-bgp-dynamic-cap-01.txt July 2001
9. Acknowledgments
The authors would like to thank Yakov Rekhter, Ravi Chandra, Dino
Farinacci for their review and comments.
10. References
[BGP-4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995.
[BGP-MP] Bates, T., Chandra, R., Katz, D., and Rekhter, Y.,
"Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with
BGP-4", RFC2842, May 2000.
11. Author Information
Enke Chen
Redback Networks, Inc.
350 Holger Way
San Jose, CA 95134
e-mail: enke@redback.com
Srihari Ramachandra
Procket Networks, Inc.
1100 Cadillac Court
Milpitas, CA 95035
e-mail: srihari@procket.com
Chen & Ramachandra [Page 4]