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, <draft-ietf-idr-bgp4-17.txt>, 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)", <draft-ietf-idr-bgp4-mib-09.txt>, 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", <draft-ietf-idr-rfc2385bis-01.txt>, 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",
<draft-ietf-idr-rfc2842bis-00.txt>, 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", <draft-ietf-idr-rfc2858bis-01.txt>, 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, <draft-ietf-idr-route-filter-05.txt>,
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, <draft-chen-bgp-prefix-orf-04.txt>, 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, <draft-ietf-idr-
restart-03.txt>, 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, <draft-ietf-idr-as4bytes-04.txt>, 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, <draft-ietf-idr-bgp-ext-
communities-03.txt>, 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,
<draft-ietf-ppvpn-rfc2547bis-01.txt>, 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, <draft-ietf-idr-aspath-orf-00.txt>, 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,
<draft-ietf-idr-dynamic-cap-02.txt>, 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, <draft-ietf-idr-cease-subcode-00.txt>, 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, <draft-ietf-idr-bgp-identifier-00.txt>, 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, <draft-ietf-idr-
route-oscillation-01.txt>, 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]