BGP's Early Design: How Autonomous Systems Began Exchanging Routes

The Border Gateway Protocol emerged from a problem that was larger than choosing a route inside one network. By the late 1980s, the Internet joined separately administered networks that had their own internal topologies, operators, and priorities. A gateway needed to learn which destinations were reachable through neighboring administrative domains without pretending that every network shared one central routing authority. BGP’s first published design, RFC 1105 in June 1989, described an experimental approach for exchanging network reachability among Autonomous Systems. Its history is best understood as the development of an inter-domain contract, not as the invention of every routing mechanism used on the Internet today.

An Autonomous System, or AS, is an administrative routing domain, not simply a synonym for one building, company, router, or physical network. The early BGP document framed the protocol around exchanging reachability and the sequence or relationship of systems through which traffic might travel. It also made a policy boundary explicit: an AS could decide whether to use or advertise a route. That institutional problem remains central to inter-domain routing even though BGP’s message formats, attributes, and operational practices have changed substantially since the first version.

Why the older exterior gateway model needed revision

The Exterior Gateway Protocol described in RFC 904 provided a way for autonomous systems to exchange information, and it was used in the NSFNET environment. EGP was useful, but the Internet’s scale and topology were changing. A simple reachability exchange did not capture all the path information needed to reason about loops and administrative policy among a growing number of independently operated networks. A replacement needed to convey more than a claim that a destination existed somewhere beyond a neighbor.

RFC 1105 describes BGP as an inter-AS routing protocol built on experience with EGP and with NSFNET operations. Its stated purpose was to exchange network reachability plus information about the ASs that traffic would transit. That information allowed a system to construct a graph of AS connectivity, detect some routing loops, and apply AS-level policy. This is an early form of path-aware inter-domain routing, but its details should not be retroactively described as if the 1989 protocol already had every modern BGP attribute or behavior.

The distinction between internal and external routing was also important. A network might use one protocol to compute paths inside its own AS and a different mechanism to coordinate with neighboring ASs. Internal topology could remain under local control while BGP conveyed the external view required for interconnection. RFC 1105 discussed internal BGP-speaking systems as one way for multiple gateways in an AS to maintain consistent information. The exact architecture evolved, but the division between interior routing and inter-domain exchange became foundational.

A protocol transported by a reliable session

The first BGP proposal used a reliable transport connection. RFC 1105’s initial implementation used TCP, while its text left open the possibility of another reliable transport. The point was to avoid rebuilding fragmentation, acknowledgment, retransmission, and sequencing mechanisms inside the routing protocol. BGP could focus on its own control messages and on interpreting routing information.

This was a design choice with operational consequences. A BGP peer relationship was not a broadcast conversation where any router automatically learned the whole Internet. Two configured peers established a session and exchanged protocol messages over that connection. A routing update described reachability and path context; it was not a packet forwarding instruction for each application flow. Routers separately installed selected routes into forwarding state after applying local policy and comparing alternatives.

An early routing message could include more structure than a flat destination list. The first BGP version encoded a gateway and link-type information reflecting a hierarchical relationship between peers, and its update data enabled construction of an AS connectivity graph. Later revisions changed the representation and refined how path information was conveyed. Treating a modern AS_PATH as a byte-for-byte feature of RFC 1105 would be inaccurate; the durable continuity is the use of inter-AS path context to support loop avoidance and policy-aware selection.

The protocol changed through published revisions

RFC 1105 was explicitly experimental and was quickly replaced. RFC 1163, published in 1990, obsoleted it and documented BGP-2. RFC 1267, published in 1991, documented BGP-3 and obsoleted RFC 1163. The succession matters: “BGP” was not a frozen 1989 design that remained unchanged while the Internet grew. The RFC record shows revisions addressing an active protocol and operational environment.

One major architectural shift was the adoption of CIDR, Classless Inter-Domain Routing. The early Internet had relied heavily on class-based address boundaries, and growth made route-table scale and allocation efficiency increasingly important. BGP-4 was specified in RFC 1654 in 1994 with support for advertising network-layer reachability information that included prefix and length, enabling classless routing and aggregation. This did not mean every network migrated instantly or that aggregation was always safe; operators had to ensure that summarized advertisements accurately represented reachable address space.

The modern base protocol is described in RFC 4271, which was published in 2006 and obsoleted RFC 1771. It is not a direct restatement of BGP-1. It defines a path-vector protocol among BGP speakers, with path attributes and policy-mediated route selection. Current Internet routing also depends on later specifications, implementation choices, operational conventions, address registries, and local configuration. A historian should use each RFC for claims about the edition it defines rather than projecting current feature names backward.

Policy is part of the architecture

BGP’s job is not to discover one objectively best path according to a universal metric. The protocol supplies information that a speaker can evaluate in light of local policy. An AS may prefer one provider, avoid another route, restrict which prefixes it advertises, or treat customer and peer relationships differently. The same destination can therefore have different preferred routes in two networks without either network violating a globally shared shortest-path rule.

That flexibility is necessary in a network of autonomous organizations, but it means routing correctness depends on configuration as well as protocol implementation. A route can be technically well-formed but inconsistent with an operator’s intent. A mistaken announcement may propagate farther than the organization expected if neighboring policy accepts it. Conversely, filtering and route selection may suppress a route that another operator sees as available. This institutional character explains why BGP history cannot be reduced to an algorithmic contest between shortest-path calculations.

The AS path concept provides useful loop information, but it is not a complete proof that an advertisement is truthful, authorized, or safe to use. The protocol’s design allows policy, but does not automatically encode the business relationship or validate ownership claims. Later security and validation mechanisms address some of these concerns, and they should be discussed as later additions rather than implied capabilities of the original experimental RFC.

Reading the early specifications responsibly

To compare BGP versions, begin with the RFC header and status. RFC 1105 is experimental, RFC 1163 and RFC 1267 describe subsequent protocol revisions, and RFC 1654 introduces the early BGP-4 specification. RFC 4271 is the later base standard. The obsoletes and obsoleted-by relationships help establish chronology, but they do not by themselves prove when equipment deployed each version or how an individual carrier configured it.

Next compare the message and path sections rather than relying on a modern textbook summary. Identify what the particular RFC calls a gateway, peer, AS, route, or path. Note changes to address representation, update behavior, and attributes between versions. Then use contemporaneous network reports or router documentation to establish deployment. An RFC defines a protocol proposal or standard; it is not evidence that every Internet router adopted it on publication day.

The durable legacy

BGP helped make an Internet of independently administered networks operationally scalable by defining how those domains could exchange reachability and path context. The design also acknowledged that reachability decisions live inside organizations with their own policies. It did not erase those differences, centrally calculate all routes, or guarantee that every announced path was optimal.

Its evolution illustrates how Internet protocols mature: an experimental document is implemented, operators expose limitations, successive RFCs revise the model, and changes in address allocation and network scale create new requirements. BGP’s 1989 origins matter because they reveal the original interconnection problem, while the later specifications show that today’s routing system is the product of sustained revision rather than a single finished invention.

Related:

Sources: