draft-ietf-idr-dynamic-cap-01.txt   draft-ietf-idr-dynamic-cap-02.txt 
Network Working Group Enke Chen Network Working Group Enke Chen
Internet Draft Redback Networks Internet Draft Redback Networks
Expiration Date: June 2002 Srihari R. Sangli Expiration Date: October 2002 Srihari R. Sangli
Procket Networks Procket Networks
Dynamic Capability for BGP-4 Dynamic Capability for BGP-4
draft-ietf-idr-dynamic-cap-01.txt draft-ietf-idr-dynamic-cap-02.txt
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 except that the right to all provisions of Section 10 of RFC2026 except that the right to
produce derivative works is not granted. produce derivative works is not granted.
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-
skipping to change at page 3, line 9 skipping to change at page 3, line 9
| Capability Value (variable) | | Capability Value (variable) |
+------------------------------+ +------------------------------+
The value of the Action field is 0 for advertising a capability, and The value of the Action field is 0 for advertising a capability, and
1 for removing a capability. 1 for removing a capability.
The triple <Capability Code, Capability Length, Capability Value> is The triple <Capability Code, Capability Length, Capability Value> is
the same as defined in [BGP-CAP], and it specifies a capability for the same as defined in [BGP-CAP], and it specifies a capability for
which the "Action" shall be applied. which the "Action" shall be applied.
6. Operation 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 A BGP speaker that is willing to receive the CAPABILITY message from
its peer should advertise the Dynamic Capability to the peer using its peer should advertise the Dynamic Capability to the peer using
BGP Capabilities advertisement [BGP-CAP]. BGP Capabilities advertisement [BGP-CAP].
A BGP speaker may send a CAPABILITY message to its peer only if it A BGP speaker may send a CAPABILITY message to its peer only if it
has received the Dynamic Capability from its peer. has received the Dynamic Capability from its peer.
The Dynamic Capability itself can not be revised dynamically via a The Dynamic Capability itself can not be revised dynamically via a
CAPABILITY message. The lifetime of the Dynamic Capability is the CAPABILITY message. The lifetime of the Dynamic Capability is the
skipping to change at page 3, line 33 skipping to change at page 4, line 16
shall update the capabilities previously received from that peer shall update the capabilities previously received from that peer
based on the "Action" in the message, and then function in accordance based on the "Action" in the message, and then function in accordance
with the revised capabilities for the peer. Any unrecognized with the revised capabilities for the peer. Any unrecognized
capabilities in the message should be ignored. capabilities in the message should be ignored.
It is noted that the dynamic capability update may not be feasible It is noted that the dynamic capability update may not be feasible
and should be disallowed for some capabilities. One example is the and should be disallowed for some capabilities. One example is the
four-byte AS number capability [BGP-4BYTE-AS] as its dynamic update four-byte AS number capability [BGP-4BYTE-AS] as its dynamic update
could introduce ambiguity in parsing the UPDATE messages. could introduce ambiguity in parsing the UPDATE messages.
7. IANA Considerations 8. 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 has speaker supports the Dynamic Capability. The Capability code has
been assigned by IANA per RFC 2842. been assigned by IANA per RFC 2842.
8. Intellectual Property Considerations 9. Intellectual Property Considerations
Cisco Systems may seek patent or other intellectual property Cisco Systems may seek patent or other intellectual property
protection for some of all of the technologies disclosed in this protection for some of all of the technologies disclosed in this
document. If any standards arising from this document are or become document. If any standards arising from this document are or become
protected by one or more patents assigned to Cisco Systems, Cisco protected by one or more patents assigned to Cisco Systems, Cisco
intends to disclose those patents and license them on reasonable and intends to disclose those patents and license them on reasonable and
non-discriminatory terms. non-discriminatory terms.
9. Security Considerations 10. Security Considerations
This extension to BGP does not change the underlying security issues. This extension to BGP does not change the underlying security issues.
10. Acknowledgments 11. 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 and Chandrashekhar Appanna for their review Farinacci, Pedro Marques and Chandrashekhar Appanna for their review
and comments. and comments. We also would like to thank Bruno Rijsman for
suggesting the initial text for the Error Handling section.
11. References 12. References
[BGP-4] Y. Rekhter, and T. Li, "A Border Gateway Protocol 4 (BGP-4)", [BGP-4] Y. Rekhter, and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771, March 1995. RFC 1771, March 1995.
[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-4BYTE-AS] Q. Vohra, E. Chen, "BGP support for four-octet AS [BGP-4BYTE-AS] Q. Vohra, E. Chen, "BGP support for four-octet AS
number space", Work in Progress, <draft-ietf-idr-as4bytes-04.txt>, number space", Work in Progress, <draft-ietf-idr-as4bytes-04.txt>,
September 2001. September 2001.
12. Author Information 13. Author Information
Enke Chen Enke Chen
Redback Networks, Inc. Redback Networks, Inc.
350 Holger Way 350 Holger Way
San Jose, CA 95134 San Jose, CA 95134
e-mail: enke@redback.com e-mail: enke@redback.com
Srihari R. Sangli Srihari R. Sangli
Procket Networks, Inc. Procket Networks, Inc.
1100 Cadillac Court 1100 Cadillac Court
 End of changes. 

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