Summary

  • RFC 3345 described deterministic BGP route oscillation caused by locally valid choices over partial, changing sets of visible paths.
  • The evidence is the repeating path, UPDATE and withdrawal sequence across routers—not a single node’s “best route” or proof of what packets experienced.

Analysis

The story begins with an apparent contradiction. A route reflector compares the paths it knows, follows the BGP decision process, and announces its selected route. Another reflector receives that update and also chooses according to its local information. Nothing in the sequence requires a random fault. Yet the first router can then withdraw the path that triggered the second router’s choice, receive a different set of candidates, and return to its original decision. The control plane has no stable answer because each local answer changes the information available elsewhere.

RFC 3345, an Informational document published in 2002, made this failure legible through explicit topologies and step-by-step route tables. BGP’s MULTI_EXIT_DISC attribute is ordinarily compared only between routes learned from the same neighboring AS. That rule preserves the local meaning of a provider’s preference. A full iBGP mesh gives routers visibility of exits, but does not scale indefinitely. Route reflection and AS confederations reduce the mesh; they can also produce path sets that differ by router and by moment.

In Type I churn, the RFC’s conditions include a single-level reflection or confederation design and accepted unique MED values from multiple ASes for one prefix. Its route-reflection example turns on the ordering of MED and IGP cost to NEXT_HOP. One reflector updates its choice; another’s new advertisement changes the first router’s candidate set; a withdrawal removes the path that previously influenced the decision. After the updates travel around the topology, the initial state returns. “Best” was not a global property—it was a local result based on a partial view.

Type II is a different construction, not just a larger Type I. It requires multiple route-reflection or sub-AS tiers together with the specified cross-AS MED condition. The confederation example also exposes scanner timing: a router can retain a selection until a withdrawal or periodic scan prompts recomputation. An operator who sees only the final table may miss the sequence that produced it.

The proposed workarounds reveal that the defect sits at an intersection of policy and visibility. Adjusting inter-cluster or inter-sub-AS IGP metrics can alter which path wins; refusing MED or avoiding the MED comparison step changes policy; a full mesh restores visibility at a scaling cost. RFC 3345 does not declare one answer universally safe. Its point is that local policy, a reduced advertisement set, and a global stability claim are different things.

RFC 7964 later described BGP path-diversity mechanisms, including ADD-PATH. That later work is useful context for the visibility problem, but it is not a census of deployed fixes. Nor does the 2002 analysis establish how often such cycles occur today. To prove a live case, an operator would need synchronized per-router candidate sets, attributes, best-path reasons, UPDATE and withdrawal timestamps, scanner state, and separate forwarding observations. A route-table snapshot alone is not that record.

RFC 3345’s enduring lesson is modest but consequential: a deterministic algorithm can produce a deterministic system that does not settle. Local correctness is not evidence of distributed convergence, and control-plane churn is not by itself proof of packet loss or user impact.

Sources