Summary

  • RFC 1105’s June 1989 status note says implementations of the Border Gateway Protocol already existed for Cisco routers and NSFNET Nodal Switching Systems. A public-domain implementation for gated was still being built. The document does not say how many systems were running it or how widely they exchanged routes.
  • In June 1990, RFCs 1163 and 1164 jointly described BGP as a Proposed Standard and explicitly said deployment experience might change it before full Internet Standard status. That sequence puts operating implementations in the historical record before the proposal’s standardization milestone.

That order is easy to flatten into a familiar story: a standards body publishes a protocol, then vendors implement it, then operators adopt it. RFC 1105 records a less tidy chronology. Its own status paragraph names two implementation settings in June 1989 while saying a third, public-domain gated version was still in progress. The RFC is not a deployment census. It gives no version identifiers, traffic totals, site list or test results. But it is direct contemporary evidence that BGP was being implemented as the first specification was written.

The problem the document addressed was inter-autonomous-system routing. RFC 1105 describes BGP as a way for systems to exchange network reachability along with information about the autonomous systems traffic would cross. That path information could help detect routing loops and support policy decisions at the AS level. The RFC says the design drew on EGP and NSFNET backbone experience. In other words, the proposal emerged in conversation with existing operating practice rather than from a blank page.

Its mechanics also show how provisional that first version was. RFC 1105’s opening message included a link-type field that classified a peer relationship as internal, upward, downward or horizontal in an AS hierarchy. Updates carried direction codes alongside AS numbers. The design could scan the listed AS route for loops, while the hierarchy encoded an expectation about how networks related to one another. These details belong to BGP’s first specification; they should not be read back as a complete description of the protocol used today.

By June 1990, RFC 1163 had replaced RFC 1105 and RFC 1164 supplied an application document. Together they defined a Proposed Standard. The status language is unusually useful evidence: the authors said the protocol could still be modified in response to deployment experience and encouraged implementers to report what they learned. RFC 1163’s route representation included a mandatory AS_PATH attribute enumerating the autonomous systems traffic would traverse. The revised documents describe a protocol with a different structure and a more explicit place in the standards process.

This is not proof that a named Cisco or NSFNET implementation caused a specific change between versions. The three RFCs do not map individual implementation feedback to each design revision. They do show a sequence: implementations existed in 1989; the specification was revised in 1990; and the standards text treated further operational experience as a legitimate input. RFC 1266 later examined operating experience, but its 1991 deployment report is a separate story and is covered elsewhere.

Heng Lu’s Note 65, “Running-Code Primacy,” supplies an editorial question for this history: what can functioning implementations establish that a paper proposal cannot? It is a lens, not evidence about BGP or the IETF. The primary record supports a narrower answer. By June 1989, implementation work was real enough to be named in the memo; by June 1990, the standardization documents still described the design as revisable. The evidence does not establish universal adoption, reliability, commercial success or a straight line from BGP-1 to modern BGP.

It records an early Internet engineering bargain in which a specification and running code could develop together.

Sources