draft-ietf-idr-dynamic-cap-00.txt   draft-ietf-idr-dynamic-cap-01.txt 
Network Working Group Enke Chen Network Working Group Enke Chen
Internet Draft Redback Networks Internet Draft Redback Networks
Expiration Date: February 2002 Srihari R. Sangli Expiration Date: June 2002 Srihari R. Sangli
Procket Networks Procket Networks
Dynamic Capability for BGP-4 Dynamic Capability for BGP-4
draft-ietf-idr-dynamic-cap-00.txt draft-ietf-idr-dynamic-cap-01.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 32 skipping to change at page 2, line 32
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 set to 0.
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 The CAPABILITY Message is a new BGP message type with type code 6.
<TBD>. In addition to the fixed-size BGP header [BGP-4], the In addition to the fixed-size BGP header [BGP-4], the CAPABILITY
CAPABILITY message contains one or more of the following tuples: message contains one or more of the following tuples:
+------------------------------+ +------------------------------+
| Action (1 octet) | | Action (1 octet) |
+------------------------------+ +------------------------------+
| Capability Code (1 octet) | | Capability Code (1 octet) |
+------------------------------+ +------------------------------+
| Capability Length (1 octet) | | Capability Length (1 octet) |
+------------------------------+ +------------------------------+
| Capability Value (variable) | | Capability Value (variable) |
+------------------------------+ +------------------------------+
skipping to change at page 3, line 36 skipping to change at page 3, line 36
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 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 has
to be assigned by IANA per RFC 2842. Capability Code values 1 through been assigned by IANA per RFC 2842.
63 are to be assigned by IANA using the "IETF Consensus" policy
defined in RFC2434.
8. Intellectual Property Considerations 8. 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.
skipping to change at page 4, line 36 skipping to change at page 4, line 36
[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-03.txt>, number space", Work in Progress, <draft-ietf-idr-as4bytes-04.txt>,
May 2001. September 2001.
12. Author Information 12. 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
 End of changes. 

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