RFC 1655 (rfc1655) - Page 2 of 19
Application of the Border Gateway Protocol in the Internet
Alternative Format: Original Text Document
RFC 1655 BGP-4 Application July 1994
John Moy (Proteon) contributed Section 7 "Required set of supported
routing policies".
Scott Brim (Cornell University) contributed the basis for Section 8
"Interaction with other exterior routing protocols".
Most of the text in Section 9 was contributed by Gerry Meyer
(Spider).
Parts of the Introduction were taken almost verbatim from [3].
We would like to acknowledge Dan Long (NEARNET) and Tony Li (cisco
Systems) for their review and comments on the current version of the
document.
1. Introduction
This memo describes the use of the Border Gateway Protocol (BGP) [1]
in the Internet environment. BGP is an inter-Autonomous System
routing protocol. The network reachability information exchanged via
BGP provides sufficient information to detect routing loops and
enforce routing decisions based on performance preference and policy
constraints as outlined in RFC 1104 [2]. In particular, BGP exchanges
routing information containing full AS paths and enforces routing
policies based on configuration information.
As the Internet has evolved and grown over in recent years, it has
become painfully evident that it is soon to face several serious
scaling problems. These include:
- Exhaustion of the class-B network address space. One
fundamental cause of this problem is the lack of a network
class of a size which is appropriate for mid-sized
organization; class-C, with a maximum of 254 host addresses, is
too small while class-B, which allows up to 65534 addresses, is
too large to be densely populated.
- Growth of routing tables in Internet routers are beyond the
ability of current software (and people) to effectively manage.
- Eventual exhaustion of the 32-bit IP address space.
It has become clear that the first two of these problems are likely
to become critical within the next one to three years. Classless
inter-domain routing (CIDR) attempts to deal with these problems by
proposing a mechanism to slow the growth of the routing table and the
need for allocating new IP network numbers. It does not attempt to
solve the third problem, which is of a more long-term nature, but
Rekhter & Gross