draft-ietf-idr-dynamic-cap-02.txt   draft-ietf-idr-dynamic-cap-03.txt 
Network Working Group Enke Chen Network Working Group Enke Chen
Internet Draft Redback Networks Internet Draft Redback Networks
Expiration Date: October 2002 Srihari R. Sangli Expiration Date: June 2003 Srihari R. Sangli
Procket Networks Procket Networks
Dynamic Capability for BGP-4 Dynamic Capability for BGP-4
draft-ietf-idr-dynamic-cap-02.txt draft-ietf-idr-dynamic-cap-03.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 2, line 21 skipping to change at page 2, line 21
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. Dynamic Capability 4. 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 set to 0. 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 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.
5. Capability Message 5. 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
skipping to change at page 3, line 9 skipping to change at page 3, line 10
| 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. Error Handling 6. Operation
A new NOTIFICATION error code is defined: 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.
7 CAPABILITY Message Error 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.
which has the following error subcodes: 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.
1 Invalid Action Value The Dynamic Capability itself can not be revised dynamically via a
2 Invalid Capability Length CAPABILITY message. The lifetime of the Dynamic Capability is the
3 Malformed Capability Value duration of the BGP session in which the capability is advertised.
If the Action field of a received CAPABILITY message is other than 0 It is also noted that the dynamic capability revision may not be
or 1, then a NOTIFICATION message with the error subcode "Invalid feasible and should be disallowed for some capabilities. One example
Action Value" MUST be sent and the data field of the NOTIFICATION is the four-byte AS number capability [BGP-4BYTE-AS] as its dynamic
message MUST contain the erroneous Action field. update could introduce ambiguity in parsing the UPDATE messages.
If the Capability Length field of a received CAPABILITY message is 7. Error Handling
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 This document defines a new NOTIFICATION error code:
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 Error Code Symbolic Name
A BGP speaker that is willing to receive the CAPABILITY message from 7 CAPABILITY Message Error
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 The following error subcodes are defined as well:
has received the Dynamic Capability from its peer.
The Dynamic Capability itself can not be revised dynamically via a Subcode Symbolic Name
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 1 Invalid Action Value
shall update the capabilities previously received from that peer 2 Invalid Capability Length
based on the "Action" in the message, and then function in accordance 3 Malformed Capability Value
with the revised capabilities for the peer. Any unrecognized 4 Unsupported Capability Code
capabilities in the message should be ignored.
It is noted that the dynamic capability update may not be feasible If a BGP speaker detects an error while processing a CAPABILITY
and should be disallowed for some capabilities. One example is the message, it MUST send a NOTIFICATION message with Error Code
four-byte AS number capability [BGP-4BYTE-AS] as its dynamic update CAPABILITY Message Error. If any of the defined error subcode is
could introduce ambiguity in parsing the UPDATE messages. 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.
8. 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.
9. 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.
10. 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.
11. 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, Chandrashekhar Appanna, Derek Yeung, Bruno
and comments. We also would like to thank Bruno Rijsman for Rijsman and John Scudder for their review and comments.
suggesting the initial text for the Error Handling section.
12. 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
 End of changes. 

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