Summary

  • RFC 1863 proposed redundant BGP/IDRP route servers whose load-ranked delays made one server most likely to claim a client, but it explicitly said the coordination algorithm could not eliminate races.
  • An informed client list recorded a server's advertisement responsibility, not client acknowledgement, best-path selection, route installation or working reachability. Duplicate-safe client behavior remained necessary.
  • Failure takeover depended on live sessions, shared list state, another delayed claim and a Hold Time budget. RFC 4223 later recorded that implementations of this specific proposal did not exist and moved it to Historic.

Two senders for one supposedly assigned client

Imagine three servers connected to the same border router. They have agreed that only one should normally send it the full routing stream. A new session appears. Each server consults its local copies of the cluster's lists. None yet sees the client assigned elsewhere. If all three act immediately, redundancy has produced three senders rather than one.

RFC 1863, published in October 1995, did not disguise this as a solved consensus problem. It proposed a delay. Servers ordered their informed client lists by current client count and then by identifying address. A server's position N produced a delay of (N-1) × DelayGranularity. The least-loaded server would usually wait least and was therefore, in the RFC's careful words, most probable to win.

Probability was doing useful engineering work, not creating authority. At timer expiry, the server scanned the lists again. If a new LIST message showed that another server had claimed the peer, it stayed silent. Otherwise it added the peer to its own list, scheduled a fresh LIST message and began sending updates. The second scan narrowed the race window; it did not make the cluster a single serial machine.

The scaling problem was connection count, not information volume

The proposal began with full mesh. Border routers within a routing domain, and routers adjacent across a common switched fabric, could require numerous direct BGP or IDRP sessions. RFC 1863 placed route servers between them. Clients maintained sessions with one or more assigned servers, while a server relayed external routes and their attributes.

The document called this virtual peering. A client was meant to receive the same routing information it could have received from direct peers and apply its own selection criteria and local policy. The server did not select a best route for distribution; it relayed what it acquired. This mattered because the proposal reduced connection-management overhead without reducing the routing database each client had to hold.

That boundary prevents a familiar inflation. Fewer sessions were not fewer routes. A server's successful relay was not a client's best-path decision. A selected route was not an installed forwarding entry, and an installed entry was not proof that packets reached a useful destination. The architecture moved one burden while leaving the downstream evidence chain intact.

Informed was a responsibility claim, not an acknowledgement

Two or more route servers could form a cluster. Clients connected to all of them for redundancy. Inside the cluster, servers exchanged complete LIST messages naming the clients to which each was providing routing information. Every server kept a separate list for every peer server and one for itself.

The word informed invites too much confidence. A client's presence in the list meant that one server believed it had responsibility for sending updates to that client. The LIST message came from that server, not from the client. It did not acknowledge that a particular UPDATE arrived, that the client retained it, that its policy selected it or that traffic followed it.

The distinction also shaped startup. In Initiation state a server accepted connections and received and processed routing updates, but sent none. It waited for a five-minute suggested initiation timer or for its configured intra-cluster sessions and their LIST messages. A live TCP or BGP/IDRP session therefore did not itself authorize advertisement activity. The server needed a sufficiently current picture of cluster responsibility before entering Active state.

The client was the last containment layer

RFC 1863 acknowledged that its reconciliation algorithm did not completely prevent races. A client might receive routing updates from more than one route server. That possibility was not treated as a contradiction of the design; it was handed to another safety rule.

When a client received a route with attributes completely identical to a route previously learned from another server in the same cluster, it was advised to replace the older copy without triggering a new advertisement. This could avoid duplicate storage and reduce a route flap when one server session disappeared.

But the rule was deliberately narrow. Completely identical attributes supplied the comparison boundary. Routes that merely reached the same prefix were not automatically interchangeable. Nor did replacement decide that the route was true, fresh or operationally better. It only made duplicate delivery of an identical candidate less disruptive.

The redundancy claim therefore rested on both sides of the connection. Servers tried to converge on one sender. Clients remained capable of surviving the period in which the attempt was incomplete. Calling the first part an election and omitting the second would erase the actual safety design.

A failure created a new timed claim

When one server lost its session with another member of the cluster, it considered the clients in the failed server's informed list. It could take responsibility only where it still had an established client session and no active server list already named that client. Even then, it ran the ordinary new-client procedure, including the delay and second scan.

Takeover was thus not a transfer token passed at failure time. It was a conditional reconstruction from surviving observations. The failed server's old list was discarded only after responsibilities were reconciled. A list could guide recovery without becoming timeless ownership evidence.

RFC 1863 tied this sequence to BGP/IDRP Hold Time. Maximum DelayTimer plus the inter-server Hold Time was recommended to remain below two-thirds of the smallest client-facing Hold Time. In the RFC's three-server example, a 90-second client Hold Time supported a 30-second intra-cluster Hold Time and 15-second DelayGranularity.

The arithmetic expressed an operational promise: detect the failed server, wait through the ordered race and resume sending before the client's session state expires. Meeting the formula could reduce a route flap. It could not prove that every required update was current, that the client accepted it or that data-plane service continued.

Origin labels without a security claim

Central relaying risked hiding which border router had supplied a route. RFC 1863 introduced an optional non-transitive ADVERTISER attribute carrying that router's identifying address. Clients processed the update as if received directly from the named border router; absence of the attribute meant the route server itself was assumed to be the advertiser.

That was a protocol interpretation rule, not authentication. The RFC's Security Considerations section said security issues were not discussed. ADVERTISER preserved a claimed source across the relay so that client policy could act. It did not prove the source controlled the identifier, authorized the route or remained uncompromised.

For hierarchical route-server clusters, RCID_PATH recorded cluster identifiers traversed and allowed a server to suppress a route returning toward a cluster already in the path. The attribute was removed before updates went to ordinary border-router clients. It was loop-control state inside the server topology, not an end-to-end provenance certificate.

Historic because the proposal did not run

The RFC Editor record now marks RFC 1863 Historic. RFC 4223 supplied the unusually direct reason in 2005: implementations of the RFC 1863 route-server design did not exist, and it was not used as an alternative to full mesh.

That conclusion must stay within its noun. RFC 4223 explicitly excluded other uses of route server and expected them to continue. It named BGP route reflectors, confederations and private AS numbers as current alternatives. RFC 2796 and its successor RFC 4456 describe route reflection, where a reflector selects a best path and carries different loop-control attributes. RFC 3065 describes confederations. These were not quiet deployments of RFC 1863 under new labels.

Nonimplementation is also not proof that every mechanism was technically unsound. It is stronger and narrower evidence: the specification's elegant race containment never acquired the operating observations that could validate its timings, failure cases or incentives. The paper design remained a proposal.

What the record can honestly prove

RFC 1863 left a disciplined chain of partial receipts. A session showed adjacency. A LIST entry showed one server's current responsibility claim. A shorter timer improved its chance of acting first. A second scan reduced stale decisions. An identical-route replacement contained duplicate delivery. A Hold Time budget protected the interval in which failure detection and reassignment had to finish.

None of those receipts was the outcome. Useful reachability required current routes, correct policy, successful selection and installation, working next-hop resolution and a viable data path. The proposal did not erase those actors by concentrating sessions.

Its final historical receipt came ten years later: no implementation existed for the specific design. That did not make the design meaningless. It made the boundary visible. A specification can explain how failure ought to be contained; only running code can show whether the containment survives clocks, loss, partitions and operators.

Sources