Network Working Group                                         Enke Chen
Internet Draft                                         Redback Networks
Expiration Date: October 2002 June 2003                            Srihari R. Sangli
                                                       Procket Networks

                      Dynamic Capability for BGP-4

                   draft-ietf-idr-dynamic-cap-02.txt

                   draft-ietf-idr-dynamic-cap-03.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.

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 needs to be reset,
   which may 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].  The
   Capability code Code for this Capability capability is specified in the "IANA
   Considerations" section of this document.  The Capability Length
   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 set to 0. supported by a BGP speaker.

   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 6.
   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
   which the "Action" shall be applied.

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 (for
   one or more capability codes) from its peer should use BGP
   Capabilities Advertisement [BGP-CAP] to advertise the Dynamic
   Capability to the peer using
   BGP Capabilities advertisement [BGP-CAP]. for these capability codes.

   A BGP speaker may send a CAPABILITY message to its peer a CAPABILITY message that contains
   one or more capability codes only if it
   has received these capability codes are
   listed in the Dynamic Capability of the OPEN message received from
   its peer.

   The Dynamic Capability itself can not be revised dynamically via

   Upon receiving a CAPABILITY message. The lifetime of message from its peer, if a capability
   code in the Dynamic Capability message is listed in the
   duration of Dynamic Capability advertised by
   the BGP session in which speaker to the capability is advertised.

   Upon receiving a CAPABILITY message from its peer, the BGP speaker shall update the capabilities capability
   previously received from that peer based on the "Action" in the
   message, and then function in accordance with the revised capabilities capability
   for the peer. Any unrecognized
   capabilities  The procedures specified in the message "Error Handling"
   section should be ignored. followed when an error is detected in processing
   the CAPABILITY message.

   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.

   It is also noted that the dynamic capability update revision may not be
   feasible and should be disallowed for some capabilities.  One example
   is the four-byte AS number capability [BGP-4BYTE-AS] as its dynamic
   update could introduce ambiguity in parsing the UPDATE messages.

7. Error Handling

   This document defines a new NOTIFICATION error code:

     Error Code     Symbolic Name

        7           CAPABILITY Message Error

   The following error subcodes are defined as well:

     Subcode        Symbolic Name

        1           Invalid Action Value
        2           Invalid Capability Length
        3           Malformed Capability Value
        4           Unsupported Capability Code

   If a BGP speaker detects an error while processing a CAPABILITY
   message, it MUST send a NOTIFICATION message with Error Code
   CAPABILITY Message Error. If any of the defined error subcode is
   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

   This document uses a BGP Capability capability code to indicate that a BGP
   speaker supports the Dynamic Capability.  The Capability capability code has
   been assigned by IANA per RFC 2842.

9. 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.

10. Security Considerations

   This extension to BGP does not change the underlying security issues.

11. Acknowledgments

   The authors would like to thank Yakov Rekhter, Ravi Chandra, Dino
   Farinacci, Pedro Marques and Marques, Chandrashekhar Appanna Appanna, Derek Yeung, Bruno
   Rijsman and John Scudder for their review and comments. We also would like to thank Bruno Rijsman for
   suggesting the initial text for the Error Handling section.

12. References

   [BGP-4] Y. Rekhter, and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
   RFC 1771, March 1995.

   [BGP-MP] T. Bates, R. Chandra, D. Katz, and Y. Rekhter,
   "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.

   [BGP-CAP] R. Chandra, J. Scudder, "Capabilities Advertisement with
   BGP-4", RFC 2842, May 2000.

   [BGP-4BYTE-AS] Q. Vohra, E. Chen, "BGP support for four-octet AS
   number space", Work in Progress, <draft-ietf-idr-as4bytes-04.txt>,
   September 2001.

13. Author Information

   Enke Chen
   Redback Networks, Inc.
   350 Holger Way
   San Jose, CA 95134
   e-mail: enke@redback.com

   Srihari R. Sangli
   Procket Networks, Inc.
   1100 Cadillac Court
   Milpitas, CA 95035
   e-mail: srihari@procket.com