Summary

  • RFC 1266 named three independently developed BGP implementations and separated 56 reported routers in seven autonomous systems from the 49 routers in six systems that belonged to the operational Internet.
  • Its more-than-2,000-network route set and heterogeneous hardware, bandwidth and topology were evidence for the recorded BGP-3 environment, not a census of global or later BGP deployment.
  • The report traced CA*Net’s slow convergence through congestion and dropped routing-control packets, proposed preferential treatment, and explicitly said that this unusually stressful configuration should not be treated as normal.

Seven routers changed the denominator

RFC 1266 was written to show how BGP had met the then-current requirements for advancement to Draft Standard. It did not present a badge and ask the reader to trust it. It named the parts of the receipt.

There were three codebases: cisco’s implementation on its proprietary router operating system, the public-domain gated implementation on systems including BSD and AIX, and the NSFNET implementation used on the T1 and T3 backbones. The report called them completely independent and interoperable. That is stronger evidence than three installations built from one source tree, but it is still a bounded claim. Independence does not prove that the implementations interpreted every ambiguous sentence differently, exercised every failure path, or shared no mistaken assumption.

The deployment count is unusually explicit. CA*Net contributed 10 border routers, the T1 NSFNET Backbone 20, the T3 NSFNET Backbone 15, the T3 NSFNET Test Network 7, CICNET 2, MERIT 1 and PSC 1. The total was 56 routers across seven autonomous systems.

Then the report changed scope. Only 49 routers across six autonomous systems were part of the operational Internet. The seven-router test network remained evidence, but not production evidence. A reader who repeats “56 operational routers” erases a distinction the source took care to preserve.

Diversity had more than one axis

The report did not rely on the router count alone. Its environment ranged from 56 Kbit/s links to 45 Mbit/s links, from PC/RT systems to RS/6000 machines, from dedicated cisco routers to general-purpose Unix workstations, and from sparse rings or spanning trees to dense backbone topologies. The full exterior route set carried by BGP was described as well over 2,000 networks.

Those dimensions matter because interoperability can be accidentally easy inside a narrow laboratory. Different code origins test specification clarity. Different operating systems and hardware expose assumptions about buffering and scheduling. Different link rates expose control traffic to different delay and loss. Different topologies exercise different path and loop conditions.

RFC 1164 makes the implementation work visible. TCP is a stream, so one read need not deliver a complete BGP message. A correct implementation must validate the header and length, buffer partial data and avoid hanging the routing process. Updates are incremental, so an advertised route persists until it is explicitly withdrawn or replaced. Reliable transport removes the need to reinvent acknowledgement and sequencing, but it also makes retained peer state part of correctness.

RFC 1267 describes the corresponding BGP-3 contract. A peer sends its complete table at the start of a connection and incremental changes afterwards. There is no periodic full refresh to repair silent disagreement. Consistency therefore belongs to the history of one transport connection; if the connection fails, the state machine returns to Idle and rebuilds the relationship.

This is why “the protocol ran” is not one fact. Message framing, retained updates, route selection, policy, timers and connection recovery can each succeed or fail separately.

The report recorded an operating surface, not an Internet census

RFC 1266 said BGP had been used in production since 1989, involved all three implementations and exercised all significant features. It included transit-to-stub and transit-to-transit exchange, backbone and regional environments, and multivendor operation. It also said authentication and routing-loop suppression had been exercised.

The claim is substantial, but its authority comes from the named scope. The document identifies systems, router counts, link conditions, topology classes and a contemporary route scale. It points to presentations in the Twentieth IETF Proceedings for underlying CA*Net and NSFNET details. Those references do not permit a later writer to invent raw samples, error bars or deployment percentages that the RFC does not reproduce.

Nor does the route count travel through time unchanged. “More than 2,000 networks” was evidence that the implementations handled the route set then in use. It says nothing by itself about BGP-4 tables, later path attributes, modern policy scale or current convergence.

CA*Net exposed a chain, not a villain

The sharpest operational finding came from CA*Net. Ten routers formed a ring over heavily used 56 Kbit/s links. Under congestion, many packets carrying BGP information were dropped. Lost routing information then slowed convergence.

That ordering is the finding: congestion, packet loss, slow convergence. RFC 1266 rejected the idea that replacing TCP would remove packet loss. The transport could retransmit, but it did not control the routers discarding packets, and BGP traffic had not created the underlying congestion.

The report offered two control surfaces. One was to relieve congestion, outside BGP’s control. The other was to reduce the proportion of routing packets discarded by identifying them and giving them preferential treatment. IP precedence, the well-known TCP port, or source and destination addresses could provide the classification. CA*Net used addresses.

It also considered more aggressive TCP retransmission and a smaller window to limit obsolete data. But it warned that retransmission timing was not a cure. Repeating control information more quickly does not repair the queue policy that keeps discarding it.

Preferential treatment is likewise not a result. A marking rule can change admission to a queue. To claim recovery, an operator still needs observations of loss, update processing, route selection, convergence and reachable forwarding after the policy is applied.

The exception came with its own warning label

CA*Net depended unusually heavily on BGP convergence because external-route information was not carried in its interior gateway protocol. BGP supplied information used for internal routing through the ring. RFC 1266 called this an extreme stress configuration and said its results should not be taken as the norm, because more ordinary networks would carry external-route information through an IGP.

This does not make the observation irrelevant. It makes it interpretable. An extreme case can expose a dependency sooner than an ordinary one. But it cannot silently become the median configuration, a universal TCP defect or a timeless statement about BGP.

RFC 1268 supplies the adjacent policy boundary. BGP exchanged AS paths and let local configuration control routing choices among stub, multihomed and transit systems. A route advertisement was therefore not an authorization certificate or a promise of delivery. The operational report tested the machinery available to make and carry local decisions; it did not prove every decision was legitimate or every packet reached its destination.

Sources and inference limits

These documents establish the contemporary specification, implementation guidance, usage assumptions, named implementations, reported population, route scale and CA*Net observation. They do not establish complete IETF Proceedings data, a global adoption rate, modern BGP behavior, current product conformance, present security, universal convergence, reachability, delivery or user outcome.