draft-ietf-idr-dynamic-cap-07.txt   draft-ietf-idr-dynamic-cap-08.txt 
Network Working Group Enke Chen Network Working Group Enke Chen
Internet Draft Srihari R. Sangli Internet Draft Srihari R. Sangli
Expiration Date: December 2005 Cisco Systems Expiration Date: June 2006 Cisco Systems
Dynamic Capability for BGP-4 Dynamic Capability for BGP-4
draft-ietf-idr-dynamic-cap-07.txt draft-ietf-idr-dynamic-cap-08.txt
1. Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
2. Abstract Abstract
This document defines a new BGP capability termed "Dynamic This document defines a new BGP capability termed "Dynamic
Capability", which would allow the dynamic update of capabilities Capability", which would allow the dynamic update of capabilities
over an established BGP session. This capability would facilitate over an established BGP session. This capability would facilitate
non-disruptive capability changes by BGP speakers. non-disruptive capability changes by BGP speakers.
3. Introduction 1. Introduction
Currently BGP capabilities [BGP-CAP] are only advertised in the OPEN Currently BGP capabilities [BGP-CAP] are only advertised in the OPEN
message during the session initialization. In order to enable a new message during the session initialization. In order to enable a new
capability or remove an existing capability (such as an Address capability or remove an existing capability (such as an Address
Family support [BGP-MP]), an established session needs to be reset, Family support [BGP-MP]), an established session needs to be reset,
which may disrupt other services running over the session. which may disrupt other services running over the session.
This document defines a new BGP capability termed "Dynamic This document defines a new BGP capability termed "Dynamic
Capability", which would allow the dynamic update of capabilities Capability", which would allow the dynamic update of capabilities
over an established BGP session. This capability would facilitate over an established BGP session. This capability would facilitate
non-disruptive capability changes by BGP speakers. non-disruptive capability changes by BGP speakers.
4. Specification of Requirements 2. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC-2119]. document are to be interpreted as described in [RFC-2119].
5. Dynamic Capability 3. Dynamic Capability
The Dynamic Capability is a new BGP capability [BGP-CAP]. The The Dynamic Capability is a new BGP capability [BGP-CAP]. The
Capability Code for this capability is specified in the "IANA Capability Code for this capability is specified in the "IANA
Considerations" section of this document. The Capability Length Considerations" section of this document. The Capability Length
field of this capability is one octet. The Capability Value field field of this capability is one octet. The Capability Value field
consists of a list of capability codes (one-octet for each) for which consists of a list of capability codes (one-octet for each) for which
the dynamic revision is supported by a BGP speaker. the dynamic revision is supported by a BGP speaker.
By advertising the Dynamic Capability to a peer in the OPEN, a BGP 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 speaker conveys to the peer that the speaker is capable of receiving
and properly handling the CAPABILITY message (as defined in the next and properly handling the CAPABILITY message (as defined in the next
Section) from the peer after the BGP session has been established. Section) from the peer after the BGP session has been established.
6. Capability Message 4. Capability Message
The CAPABILITY Message is a new BGP message type with type code 6. 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 In addition to the fixed-size BGP header [BGP-4], the CAPABILITY
message contains one or more of the following tuples of capability message contains one or more of the following tuples of capability
revisions: revisions:
+------------------------------+ +------------------------------+
| Init/Ack (1 bit) | | Init/Ack (1 bit) |
+------------------------------+ +------------------------------+
| Ack Request (1 bit) | | Ack Request (1 bit) |
skipping to change at page 4, line 5 skipping to change at page 4, line 5
The Sequence Number field can be used by a BGP speaker to match an The Sequence Number field can be used by a BGP speaker to match an
acknowledgement with a capability revision that the speaker initiated acknowledgement with a capability revision that the speaker initiated
previously. previously.
Conceptually the triple <Capability Code, Capability Length, Conceptually the triple <Capability Code, Capability Length,
Capability Value> is the same as the one defined in [BGP-CAP], and it Capability Value> is the same as the one defined in [BGP-CAP], and it
specifies a capability for which the "Action" shall be applied. The specifies a capability for which the "Action" shall be applied. The
triple is optional when the Init/Ack bit is set to 1. triple is optional when the Init/Ack bit is set to 1.
7. Operation 5. Operation
A BGP speaker that is willing to receive the CAPABILITY message (for A BGP speaker that is willing to receive the CAPABILITY message (for
one or more capability codes) from its peer SHOULD use the BGP one or more capability codes) from its peer SHOULD use the BGP
Capabilities Advertisement [BGP-CAP] to advertise the Dynamic Capabilities Advertisement [BGP-CAP] to advertise the Dynamic
Capability for these capability codes. Capability for these capability codes.
A BGP speaker MAY send to its peer a CAPABILITY message to initiate A BGP speaker MAY send to its peer a CAPABILITY message to initiate
revisions for one or more capability codes only if these capability revisions for one or more capability codes only if these capability
codes are listed in the Dynamic Capability of the OPEN message codes are listed in the Dynamic Capability of the OPEN message
received from its peer. received from its peer.
skipping to change at page 5, line 31 skipping to change at page 5, line 31
For the Initiator, the capability revision SHALL take effect (for For the Initiator, the capability revision SHALL take effect (for
sending updates) immediately after the capability revision is sent, sending updates) immediately after the capability revision is sent,
and the capability revision SHALL take effect (for receiving updates) and the capability revision SHALL take effect (for receiving updates)
immediately after an acknowledgement is received from the Receiver. immediately after an acknowledgement is received from the Receiver.
For the Receiver, the capability revision SHALL take effect (for For the Receiver, the capability revision SHALL take effect (for
receiving updates) immediately after the capability revision is receiving updates) immediately after the capability revision is
received from the Initiator, and the capability revision SHALL take received from the Initiator, and the capability revision SHALL take
effect (for sending updates) immediately after an acknowledgement is effect (for sending updates) immediately after an acknowledgement is
sent. sent.
8. Error Handling 6. Error Handling
This document defines a new NOTIFICATION error code: This document defines a new NOTIFICATION error code:
Error Code Symbolic Name Error Code Symbolic Name
7 CAPABILITY Message Error 7 CAPABILITY Message Error
The following error subcodes are defined as well: The following error subcodes are defined as well:
Subcode Symbolic Name Subcode Symbolic Name
skipping to change at page 6, line 27 skipping to change at page 6, line 27
Capability Length. Capability Length.
If the Capability Value field in the CAPABILITY message is malformed If the Capability Value field in the CAPABILITY message is malformed
(the definition of "malformed" depends on the Capability Code), then (the definition of "malformed" depends on the Capability Code), then
the error subcode is set to Malformed Capability Value. the error subcode is set to Malformed Capability Value.
If the Capability Code in the CAPABILITY message is not any of the If the Capability Code in the CAPABILITY message is not any of the
capability codes advertised in the Dynamic Capability by the speaker, capability codes advertised in the Dynamic Capability by the speaker,
then the error subcode is set to Unsupported Capability Code. then the error subcode is set to Unsupported Capability Code.
9. IANA Considerations 7. IANA Considerations
This document uses a BGP capability code to indicate that a BGP This document uses a BGP capability code to indicate that a BGP
speaker supports the Dynamic Capability. The capability code needs speaker supports the Dynamic Capability. The capability code needs
to be assigned by IANA per RFC 2842. to be assigned by IANA per RFC 2842.
10. Security Considerations 8. Security Considerations
This extension to BGP does not change the underlying security issues This extension to BGP does not change the underlying security issues.
[BGP-MD5].
11. Acknowledgments 9. Acknowledgments
The authors would like to thank Yakov Rekhter, Ravi Chandra, Dino The authors would like to thank Yakov Rekhter, Ravi Chandra, Dino
Farinacci, Pedro Marques, Chandrashekhar Appanna, Derek Yeung, Bruno Farinacci, Pedro Marques, Chandrashekhar Appanna, Derek Yeung, Bruno
Rijsman and John Scudder for their review and comments. Rijsman and John Scudder for their review and comments.
12. References 10. Normative References
[BGP-4] Rekhter, Y., T. Li, and S. Hares, "A Border Gateway Protocol [BGP-4] Rekhter, Y., T. Li, and S. Hares, "A Border Gateway Protocol
4 (BGP-4)", draft-ietf-idr-bgp4-26.txt, October 2004. 4 (BGP-4)", draft-ietf-idr-bgp4-26.txt, October 2004.
[BGP-MP] T. Bates, R. Chandra, D. Katz, and Y. Rekhter, [BGP-MP] T. Bates, R. Chandra, D. Katz, and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[BGP-CAP] R. Chandra, J. Scudder, "Capabilities Advertisement with [BGP-CAP] R. Chandra, J. Scudder, "Capabilities Advertisement with
BGP-4", RFC 2842, May 2000. BGP-4", RFC 2842, May 2000.
[BGP-MD5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 11. Author Information
3", RFC 2026, October 1996.
13. Author Information
Enke Chen Enke Chen
Cisco Systems, Inc. Cisco Systems, Inc.
170 W. Tasman Dr. 170 W. Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
e-mail: enkechen@cisco.com
Email: enkechen@cisco.com
Srihari R. Sangli Srihari R. Sangli
Cisco Systems, Inc. Cisco Systems, Inc.
170 W. Tasman Dr. 170 W. Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
e-mail: rsrihari@cisco.com
14. Intellectual Property Considerations Email: rsrihari@cisco.com
12. Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 8, line 29 skipping to change at page 8, line 13
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
15. Full Copyright Notice 13. Full Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 End of changes. 21 change blocks. 
27 lines changed or deleted 22 lines changed or added

This html diff was produced by rfcdiff 1.28, available from http://www.levkowetz.com/ietf/tools/rfcdiff/