Network Working Group Enke Chen Internet Draft Redback Networks Expiration Date: May 2001 Yakov Rekhter Cisco Systems List of the Current BGP Documents draft-chen-bgp-reference-00.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. 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 lists the most recent RFCs and Internet Drafts that are related to the BGP protocol and its applications. It is expected that this document will be updated on a on-going basis. Chen & Rekhter [Page 1] Internet Draft draft-chen-bgp-reference-00.txt November 2000 3. Introduction This document lists the most recent RFCs and Internet Drafts that are related to the BGP protocol and its applications. It is expected that this document will be updated on a on-going basis. 4. Protocol Specification Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP-4)", Work in Progress, , April 2000. This document contains the base protocol specifications. S. Willis, J. Burruss, J. Chu, "Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2", RFC 1657, July 1994. This document describes managed objects used for managing the Border Gateway Protocol Version 4. R. Chandra, P. Traina, T. Li, "BGP Communities Attribute", RFC 1997, August 1996. This document describes an extension to BGP which may be used to pass additional information to both neighboring and remote BGP peers. The intention of the proposed technique is to aid in policy administration and reduce the management complexity of maintaining the Internet. A. Heffernan, "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998. This document describes a TCP extension to enhance security for BGP. It defines a new TCP option for carrying an MD5 [RFC1321] digest in a TCP segment. This digest acts like a signature for that segment, incorporating information known only to the connection end points. Since BGP uses TCP as its transport, using this option in the way described in this paper significantly reduces the danger from certain security attacks on BGP. T. Bates, R. Chandra, E. Chen, "BGP Route Reflection - An Alternative to Full Mesh IBGP", RFC 2796, April 2000. BGP, as originally defined, requires that all BGP speakers within a single AS must be fully meshed. This represents a serious Chen & Rekhter [Page 2] Internet Draft draft-chen-bgp-reference-00.txt November 2000 scaling problem. This document describes the use and design of a method known as "Route Reflection" to alleviate the the need for "full mesh" IBGP. P. Traina, D. McPherson, J. Scudder, "Autonomous System Confederations for BGP", Work in Progress, , October 2000. BGP, as originally defined, requires that all BGP speakers within a single AS must be fully meshed. This represents a serious scaling problem. This document describes an extension to BGP which may be used to create a confederation of autonomous systems that is represented as a single autonomous system to BGP peers external to the confederation, thereby removing the "full mesh" requirement. The intention of this management complexity of maintaining a large autonomous system. C. Villamizar, R. Chandra, R. Govindan, "BGP Route Flap Damping", RFC 2439, November 1998. To maintain scalability of a routed internet, it is necessary to reduce the amount of change in routing state propagated by BGP in order to limit processing requirements. The primary contributors of processing load resulting from BGP updates are the BGP decision process and adding and removing forwarding entries. A BGP implementation must be prepared for a large volume of routing traffic. A BGP implementation cannot rely upon the sender to sufficiently shield it from route instabilities. The mechanisms described in this document are designed to prevent sustained oscillations. These mechanisms allow routing instability to be contained at an AS border router bordering the instability. R. Chandra, J. Scudder, "Capabilities Advertisement with BGP-4", RFC 2842, May 2000. This document defines new Optional Parameter, called Capabilities, that is expected to facilitate introduction of new capabilities in BGP by providing graceful capability advertisement without requiring that BGP peering be terminated. Chen & Rekhter [Page 3] Internet Draft draft-chen-bgp-reference-00.txt November 2000 T. Bates, R. Chandra, D. Katz, Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. E. Chen, "Route Refresh Capability for BGP-4", RFC 2918, September 2000. This document defines a new Border Gateway Protocol (BGP) capability termed 'Route Refresh Capability', which would allow the dynamic exchange of route refresh request between BGP speakers and subsequent re-advertisement of the respective Adj-RIB-Out. One possible application of this capability is to facilitate non- disruptive routing policy changes. E. Chen, Y. Rekhter, "Cooperative Route Filtering Capability for BGP-4", Work in Progress, , November 2000. This document defines a BGP-based mechanism that allows a BGP speaker to send to its BGP peer a set of route filters that the peer would use to constrain/filter its outbound routing updates to the speaker. E. Chen, S. Ramachandra, "Address Prefix Based Outbound Route Filter for BGP-4", Work in Progress, , October 2000. This document defines a new Outbound Router Filter type for BGP, termed "Address Prefix Outbound Route Filter", that can be used to perform address prefix based route filtering. This ORF-type supports prefix length or range based matching, wild-card based address prefix matching, as well as the exact address prefix matching for address families. S. Ramachandra, Y. Rekhter, R. Fernando, J. Scudder, E. Chen, "Graceful Restart Mechanism for BGP", Work in Progress, , November 2000. This document proposes a mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart. An Chen & Rekhter [Page 4] Internet Draft draft-chen-bgp-reference-00.txt November 2000 End-of-RIB marker is specified and can be used to convey routing convergence information. A new BGP capability, termed "Graceful Restart Capability", is defined which would allow a BGP speaker to express its ability to preserve forwarding state during BGP restart. Finally, procedures are outlined for temporarily retaining routing information across a TCP transport reset. P. Marques, F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC 2545, March 1999. BGP-4 Multiprotocol Extensions [BGP-MP] defines the format of two BGP attributes (MP_REACH_NLRI and MP_UNREACH_NLRI) that can be used to announce and withdraw the announcement of reachability information. This document defines how compliant systems should make use of those attributes for the purpose of conveying IPv6 routing information. E. Chen, Y. Rekhter, "BGP support for four-octet AS number space", Work in Progress, draft-chen-as4bytes-00.txt, November 2000. Currently the Autonomous System number is encoded in BGP as a two- octets field. This document describes extentions to BGP to carry the Autonomous System number as a four-octets field. S. Ramachandra, D. Tappan, "BGP Extended Communities Attribute", Work in Progress, , May 2000. The Extended Community Attribute provides two important enhancements over the existing BGP Community Attribute: (1) it provides an extended range, ensuring that communities can be assigned for a plethora of uses, without fear of overlap, and (2) the addition of a Type field provides structure for the community space. The addition of structure allows the application of policy based on the application for which the community value will be used. For example, one can filter out all communities of a particular type, or allow only certain values for a particular type of community. Without structure this can only be accomplished by explicitly enumerating all community values which will be denied or allowed. E. Rosen, et., "BGP/MPLS VPNs", Work in Progress, , July 2000. Chen & Rekhter [Page 5] Internet Draft draft-chen-bgp-reference-00.txt November 2000 This document describes a method by which a Service Provider may use an IP backbone to provide VPNs for its customers. MPLS is used for forwarding packets over the backbone, and BGP is used for distributing routes over the backbone. The primary goal of this method is to support the case in which a client obtains IP backbone services from a Service Provider or Service Providers with which it maintains contractual relationships. The client may be an enterprise, a group of enterprises which need an extranet, an Internet Service Provider, an application service provider, another VPN Service Provider which uses this same method to offer VPNs to clients of its own, etc. The method makes it very simple for the client to use the backbone services. It is also very scalable and flexible for the Service Provider, and allows the Service Provider to add value. Y. Rekhter, E. Rosen, "Carrying Label Information in BGP-4", Work in Progress, draft-ietf-mpls-bgp4-mpls-04.txt, January 2000. When BGP is used to distribute a particular route, it can be also be used to distribute an MPLS label which is mapped to that route. This document specifies the way in which this is done. The label mapping information for a particular route is piggybacked in the same BGP Update message that is used to distribute the route itself. 5. Analysis/Applications P. Traina, "Experience with the BGP-4 protocol", RFC 1773, March 1995. The purpose of this document is to document how the requirements for advancing a routing protocol to Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4). This report documents experience with BGP. This is the second of two reports on the BGP protocol. As required by the Internet Architecure Board (IAB) and the Internet Engineering Steering Group (IESG), the first report will present a performance analysis of the BGP protocol. P. Traina, "BGP-4 Protocol Analysis", RFC 1774, March 1995. The purpose of this report is to document how the requirements for advancing a routing protocol to Draft Standard have been satisfied by the Border Gateway Protocol version 4 (BGP-4). This report summarizes the key features of BGP, and analyzes the protocol with respect to scaling and performance. This is the first of two Chen & Rekhter [Page 6] Internet Draft draft-chen-bgp-reference-00.txt November 2000 reports on the BGP protocol. J. Hawkinson, T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", RFC 1930, March 1996. This document discusses when it is appropriate to register and utilize an Autonomous System (AS), and lists criteria for such. E. Chen, and T. Bates, "An Application of the BGP Community Attribute in Multi-home Routing", RFC 1998, August 1996. This document presents an application of the BGP community attribute in simplifying the implementation and configuration of routing policies in the multi-provider Internet. It shows how the community based configuration can be used to replace the AS-based customization of the BGP "LOCAL_PREF" attribute, a common method used today. Not only does the technique presented simplifies configuration and management at the provider level, it also represents a paradigm shift in that it gives the potential for the customer to control its own routing policy with respect to its service provider, as well as providing the ability for policy configuration to be done at a prefix based granularity rather than the more common AS based granularity. J. Stewart, T. Bates, R. Chandra, and E. Chen, "Using a Dedicated AS for Sites Homed to a Single Provider", RFC 2270, January 1998. With the increased growth of the Internet, the number of customers using BGP4 has grown significantly. RFC1930 outlines a set of guidelines for when one needs and should use an AS. However, the customer and service provider (ISP) are left with a problem as a result of this in that while there is no need for an allocated AS under the guidelines, certain conditions make the use of BGP4 a very pragmatic and perhaps only way to connect a customer homed to a single ISP. This paper proposes a solution to this problem in line with recommendations set forth in RFC1930. E. Chen, and J. Stewart, "A Framework for Inter-Domain Route Aggregation", RFC 2519, February 1999. This document presents a framework for inter-domain route aggregation and shows an example router configuration which 'implements' this framework. This framework is flexible and scales well as it emphasizes the philosophy of aggregation by the source, both within routing domains as well as towards upstream providers, and it also strongly encourages the use of the 'no- export' BGP community to balance the provider-subscriber need for more granular routing information with the Internet's need for Chen & Rekhter [Page 7] Internet Draft draft-chen-bgp-reference-00.txt November 2000 scalable inter-domain routing. 6. Author Information Enke Chen Redback Networks, Inc. 350 Holger Way San Jose, CA 95134 email: enke@redback.com Yakov Rekhter Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 e-mail: yakov@cisco.com Chen & Rekhter [Page 8]