Network Working Group Enke Chen Internet Draft Redback Networks Expiration Date: October 2002 Yakov Rekhter Juniper Networks List of the Current BGP Documents draft-chen-bgp-reference-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. 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-03.txt April 2002 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, , January 2002. This document contains the base protocol specifications. S. Hares, J. Haas, S. Willis, J. Burruss, J. Chu, "Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4)", , March 2002. 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", , March 2002. 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-03.txt April 2002 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", RFC 3065, February 2001. 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", , February 2002. This document defines new Optional Parameter, called Capabilities, that is expected to facilitate introduction of new capabilities in BGP. T. Bates, R. Chandra, D. Katz, Y. Rekhter, "Multiprotocol Extensions for BGP-4", , April 2002. Chen & Rekhter [Page 3] Internet Draft draft-chen-bgp-reference-03.txt April 2002 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, , January 2002. 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. Sangli, "Address Prefix Based Outbound Route Filter for BGP-4", Work in Progress, , April 2002. 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. Sangli, Y. Rekhter, R. Fernando, J. Scudder, E. Chen, "Graceful Restart Mechanism for BGP", Work in Progress, , April 2002. This document proposes a mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart. An 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 Chen & Rekhter [Page 4] Internet Draft draft-chen-bgp-reference-03.txt April 2002 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. Q. Vohra, E. Chen, "BGP support for four-octet AS number space", Work in Progress, , September 2001. 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. Sangli, D. Tappan, Y. Rekhter, "BGP Extended Communities Attribute", Work in Progress, , March 2002. 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, Y. Rekhter, et al., "BGP/MPLS VPNs", Work in Progress, , January 2002. 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 Chen & Rekhter [Page 5] Internet Draft draft-chen-bgp-reference-03.txt April 2002 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", RFC 3107, May 2001. 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. K. Patel, S. Hares, "Aspath Based Outbound Route Filter for BGP-4", Work in Progress, , July 2001. This document defines a new Outbound Router Filter type for BGP, termed "Aspath Outbound Route Filter", that can be used to perform aspath based route filtering. This ORF-type supports aspath based route filtering as well as regular expression based matching, for address groups. E. Chen, S. Sangli, "Dynamic Capability for BGP-4", Work in Progress, , April 2002. 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. E. Chen, V. Gillet, "Subcodes for BGP Cease Notification Message", Work in Progress, , October 2001. This document defines several subcodes for the BGP Cease NOTIFICATION message that would provide more information to aid network operators in co-relating network events and diagnosing BGP peering issues. Chen & Rekhter [Page 6] Internet Draft draft-chen-bgp-reference-03.txt April 2002 E. Chen, J. Yuan, "AS-wide Unique BGP Identifier for BGP-4", Work in Progress, , February 2002. To accommodate situations where the current requirements for the BGP Identifier are not met, this document relaxes the definition of the BGP Identifier to be a 4-octet unsigned, non-zero integer, and relaxes the "uniqueness" requirement so that only AS-wide uniqueness of the BGP Identifiers is required. These revisions to the base BGP specification do not introduce any backward compatibility issue. 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 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 Chen & Rekhter [Page 7] Internet Draft draft-chen-bgp-reference-03.txt April 2002 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 scalable inter-domain routing. D. McPherson, V. Gill, D. Walton, and A. Retana, "BGP Persistent Route Oscillation Condition", Work in Progress, , February 2002. It has recently been discovered that in particular configurations, the BGP scaling mechanisms defined in "BGP Route Reflection - An Alternative to Full Mesh IBGP" and "Autonomous System Confederations for BGP" will introduce persistent BGP route oscillation. This document discusses the two types of persistent route oscillation that have been identified, describes when these conditions will occur, and provides some network design guidelines to avoid introducing such occurrences. Chen & Rekhter [Page 8] Internet Draft draft-chen-bgp-reference-03.txt April 2002 6. Author Information Enke Chen Redback Networks, Inc. 350 Holger Way San Jose, CA 95134 email: enke@redback.com Yakov Rekhter Juniper Networks, Inc. 1194 N. Mathilda Avenue Sunnyvale, CA 94089 e-mail: yakov@juniper.net Chen & Rekhter [Page 9]