Summary

  • BGP PIC reduces the local forwarding work after a qualifying failure by making many prefixes share hierarchical next-hop objects; one pathlist or pointer change can redirect them together.
  • The mechanism needs a usable alternate route before the incident. A second route, a different BGP next hop or a backup in the RIB does not by itself prove physical diversity, FIB installation, sufficient capacity or correct activation.
  • Leaders should govern the whole preauthorization chain: candidate visibility, backup eligibility, shared fate, detector thresholds, hardware hierarchy, packet-level failover and controlled return to stable routing.

At 02:14, a provider edge router loses its preferred egress. The network graph on the incident screen is still green in several places. BGP has not finished reconsidering the affected VPN routes. Yet traffic for hundreds of thousands of prefixes begins leaving through another PE.

The first operational question is usually, “How did it converge so fast?” The more important question is, “Who chose that path, and when?”

The answer may be: long before the failure. The router had already received an alternate, judged it eligible, resolved its next hop, associated it with shared forwarding objects and programmed enough state to invoke it locally. When the detector declared the primary dependency unusable, the forwarding plane changed a small number of shared objects. It did not rewrite hundreds of thousands of destination entries one by one.

That is the central idea of BGP Prefix Independent Convergence, usually shortened to BGP PIC. The name is easy to overread. It does not mean that BGP has escaped every relationship between scale and convergence. It means that a particular part of recovery—the local forwarding update after a covered failure—can be organized so that its duration does not grow with the number of affected BGP prefixes.

As of this article's publication, the IETF description is draft-ietf-rtgwg-bgp-pic-23, an active working-group Internet-Draft intended to be Informational. It is work in progress, not an RFC and not a new packet exchanged between routers. Its value is architectural: it explains how hierarchical FIB structures, recursive resolution and precomputed backup paths can make one local repair apply to a large route population.

The forwarding tree matters more than the feature name. In a flat design, every BGP prefix may carry a fully expanded set of forwarding details. If 500,000 routes resolve through the same egress and that dependency changes, the system may need to touch 500,000 leaves. The work is proportional to the route set.

In a hierarchical design, those prefix leaves point to a shared BGP pathlist. That object points to a recursively resolved IGP next-hop object, which eventually points to an adjacency, label stack or outgoing interface. Many leaves reuse the same branches. If the shared next hop changes, the forwarding manager updates the relevant branch or pointer and all dependent leaves inherit the new path.

The distinction is similar to changing the destination written on half a million envelopes versus changing one conveyor belt junction through which all of them pass. The second operation is not literally free. Hardware has to detect the event, update state and begin using the other branch. But its workload is no longer one operation per envelope.

This is why “prefix independent” is a scaling claim with a boundary. Failure detection can still take time. A route reflector can still hide the alternate. The control plane can still need to withdraw, select and advertise routes. A line card can still have programming limits. Remote routers can still converge at different speeds. Return traffic can still fail. The backup can still be congested. PIC does not abolish these stages; it removes prefix count from one especially expensive local stage when the required state already exists.

Precomputation is the price of speed. The protecting router must have more than a primary path in its useful state. It needs an alternate that is valid under policy, reachable through a different relevant dependency and installed in the forwarding chain before the incident. The failure-time decision is therefore partly a past decision.

That changes how assurance should work. A conventional post-failure route choice can be inspected as it happens: which UPDATE arrived, which attributes won and which FIB entry was written. PIC asks the operator to inspect dormant intent. The backup may sit unused for weeks. When it finally matters, the network assumes that an earlier topology, policy and resource judgment remains valid.

Candidate supply comes first. The active draft lists several ways multiple paths may become available, including ADD-PATH, best-external behavior, diverse-path distribution and distinct route distinguishers in VPN designs. These are not interchangeable guarantees. They are possible ways to prevent the protecting router from seeing only the primary.

Route reflection makes the problem concrete. A reflector normally advertises a selected path, not every path it learned. An ingress PE can support PIC in hardware and still have no useful backup because the alternative never crossed the reflector boundary. An ADD-PATH capability line is also insufficient: the direction, AFI/SAFI, sending policy, number of paths, import policy and actual Adj-RIB-In decide what arrived.

The proof is local. For each protected route family, show that the router actually retained at least one alternate with the required attributes and next-hop distinction. Counting routes at a reflector or reading a global capability summary does not prove the candidate existed where failover would occur.

Eligibility comes next. Nokia's current SR Linux documentation, for example, describes an Edge PIC backup candidate as valid, reachable and using a BGP next hop different from the primary. It then selects the best eligible backup through the applicable BGP decision process and tie-breaks. That is a coherent implementation rule. It is not a universal certificate of independence.

Two BGP next-hop addresses can resolve through the same physical fiber, the same line card, the same transport tunnel, the same power room or the same upstream provider. Two egress PEs can depend on one route reflector cluster or one shared service node. An alternate can be logically different and operationally doomed by the same event.

Fate separation must therefore be declared at the failure class being protected. For a local link failure, another interface may be sufficient. For a line-card failure, it is not. For an egress-PE failure, a second path through the same PE is irrelevant. For a provider failure, two sessions to different routers inside the same provider may offer no commercial or physical independence.

This is where Core PIC and Edge PIC help, provided they remain analytical categories rather than slogans. Core PIC deals with a failure along the interior path to a BGP next hop that remains reachable. The BGP next hop does not have to change; the IGP or transport resolution underneath it moves to another path. The shared recursive object is the point of repair.

Edge PIC deals with loss of the egress next hop or an edge dependency. The repair uses a different precomputed BGP next hop. It may also require a different VPN label, tunnel or service path. The distinction tells the operator which layer is expected to move and which dependency must be diverse.

Product interfaces do not always use these labels consistently, and feature scope can vary by address family, service and software release. A command called pic edge on one platform is not evidence that another platform, line card or VPN family has the same data structure or coverage. The active draft itself stresses that the benefit is tied to forwarding-plane design rather than a change to BGP's wire protocol.

The detector holds the activation key. PIC can prepare the backup, but it cannot use it until some component decides the primary dependency failed. Physical link state, interface drivers, IGP adjacency loss, BGP-session loss and BFD observe different things and operate on different timescales.

RFC 5880 makes the BFD boundary precise. Detection time is calculated independently in each direction from negotiated transmit intervals and a detection multiplier. The two directions can have different values. A dashboard that displays one “50 ms BFD” label may conceal what each endpoint actually negotiated and which direction can declare failure first.

Fast detection also has a cost. Congestion, control-plane starvation, filtering or an attack can make valid BFD packets disappear. RFC 5880 warns that false-down and false-up outcomes can have serious denial-of-service consequences. An aggressive timer is not simply a performance setting; it authorizes a fast forwarding change based on fewer missing observations.

The right test asks whether the detector covers the intended fault. Direct interface state may see a local fiber cut almost immediately but miss a failure several hops away. Single-hop BFD may cover the adjacency while not proving the remote service path works. Multi-hop BFD may test reachability to an endpoint but follow a path whose relationship to the protected traffic is implementation-dependent. Detection must map to the dependency represented by the shared FIB object.

Visibility can be lost inside the IGP as well. Summarization deliberately reduces detailed state across area or level boundaries. RFC 9929 defines an Unreachable Prefix Announcement partly because a component prefix covered by a summary can become unreachable without the summary being withdrawn. The RFC specifically notes fast-convergence uses such as BGP PIC. The lesson is not that every network must deploy UPA. It is that a precomputed repair cannot respond correctly to a failure hidden from its decision point.

Hardware hierarchy is another hard boundary. The draft assumes a FIB capable of recursive lookups through several levels of indirection. Some platforms support fewer levels. Their forwarding manager may flatten dependencies when programming hardware: resolving part of the chain in advance and duplicating information into more leaves.

Flattening can reduce memory lookups per packet, but it reduces sharing and consumes more FIB memory. It can weaken ECMP or PIC properties and bring prefix-count work back into some failure cases. An operator cannot infer the realized hierarchy from the control-plane route alone. The line card, ASIC generation, encapsulation stack and software release decide what was programmed.

This makes mixed fleets especially dangerous. Two routers can display the same primary and backup routes while using different hardware chains. One changes a shared object in tens of milliseconds; another rewrites a large set of flattened entries. A service-level claim must be measured on every relevant platform and route family, not inherited from the most capable chassis.

Labels and encapsulation add more state to preserve. In an L3VPN, the backup egress may require a different VPN label. The transport path may use LDP, segment routing or another tunnel. A pathlist switch that changes the egress next hop but leaves a stale or mismatched label can be fast and wrong. The validation must follow the exact label or encapsulation selected for each alternate.

Precomputed state ages. The backup may have been correct when installed, then become unsuitable because import policy changed, a route was withdrawn, recursion moved, a label changed, a next hop became partially reachable or hardware resource pressure altered what remained in the FIB. The most alarming stale state is not one visibly absent; it is one still marked ready.

Operators need an age and revalidation model. Record when the candidate was received, when eligibility was last recomputed, when the FIB object was programmed and which topology or policy version justified it. On any relevant policy, topology, software or hardware event, verify the standby chain again. “Backup present” is a state observation, not a freshness proof.

Capacity belongs in the decision. A backup can be loop-free and reachable yet unable to carry the protected traffic. If many primary next hops share one standby, a single failure can move a huge aggregate onto a link sized only for normal conditions. If multiple failures occur, independently acceptable backups can collide.

The preauthorization record should therefore name the load assumption and failure set. It should show headroom along the entire alternate path, not only on the first interface. Where economics matter, it should also record whether the alternate violates transit, peering or customer policy even though BGP considers it eligible.

RFC 5714 supplies the correct temporal model. Fast reroute invokes a local repair path after detection; it does not replace the later distributed routing transition. The repair carries packets while routing protocols advertise the failure and settle on the new topology. Once stable convergence completes, the network may move away from the temporary repair.

That creates at least six clocks: detection time, event-notification time, local FIB activation time, time to the first successful packet, control-plane convergence time and time to the final steady-state FIB. A single “convergence time” number erases who owns each delay and whether packets were actually delivered.

Measure all six. Timestamp the detector event and the hardware pathlist change. Send data-plane probes at an interval capable of seeing the loss window. Capture the outgoing interface, next hop and label stack before, during and after repair. Separately record BGP and IGP stabilization. An impressive control-plane log is not a packet-delivery result.

Return traffic needs its own evidence. A local router may switch forward traffic perfectly while the remote side continues sending replies toward the failed path. Stateful firewalls, NAT, service chains and load balancers may not preserve sessions across a new egress. End-to-end recovery is a bidirectional application property, not a synonym for local PIC activation.

A serious test matrix starts with the intended single fault but does not stop there. Cut a local interface. Break a remote transport segment while keeping the BGP next hop address nominally reachable. Remove the egress PE. Drop the BGP session. Suppress or delay BFD. Withdraw the backup first. Change policy while the primary remains healthy. Exhaust a forwarding resource. Restart a line card. Restore the primary and observe the return.

Each scenario needs an expected object-level response. Which detector fires? Which shared object changes? Which prefix leaves should remain untouched? Which backup next hop and label should become active? What packet loss and reordering budget applies? When does stable routing replace the repair? If the answer is only “traffic should recover,” the test cannot locate a failure.

The false-positive and false-negative risks are symmetrical. A false positive switches a vast prefix set quickly onto an unusable backup, amplifying one bad detector decision. A false negative leaves an apparently protected service on the failed path because the candidate was not installed, the trigger was not bound to the right object or the hardware never accepted the standby entry.

Shared state is the source of efficiency and the multiplier of error. One pointer can rescue half a million routes. The same pointer can misdirect half a million routes. The blast radius is not an implementation accident; it is the direct inverse of the optimization.

For that reason, selection and certification should be separated. Routing policy owners can define eligible candidates. Transport owners can attest physical and fate diversity. Platform owners can prove the hierarchical FIB exists on the actual hardware. Service owners can certify capacity and bidirectional behavior. An independent reviewer should approve expansion from a small cohort.

The first production artefact is a protection matrix. Its rows are failure classes; its columns are route families, platforms and services. For every cell, record the primary dependency, candidate source, chosen backup, fate-separation evidence, detector, negotiated threshold, hardware object, capacity assumption and owner.

The second artefact is a dormant-state ledger. It identifies the exact backup programmed for representative prefixes, the shared object they reference, the last revalidation time and the topology/policy epoch. It flags candidates that are merely present in the RIB but absent from hardware.

The third artefact is a timed forwarding trace. It connects detector telemetry to the pathlist or recursive-object transition and then to observed packets. It records both directions and includes the final move from repair state to converged state. This is the point at which feature configuration becomes operational evidence.

Restoration deserves the same care as failure. When the primary returns, immediately preferring it can cause reordering, oscillation or a second loss window. The original dependency may be unstable. Control-plane state may have changed during the incident. A hold-down, validation period or controlled revert may be safer than automatic symmetry.

Rollback is therefore not “remove PIC.” It means restoring the prior protection policy, withdrawing or replacing standby objects safely and proving that live traffic uses the intended steady-state path. If the topology changed during the incident, there may be no exact old state to restore.

Heng Lu's principle of minimum initial specification fits this architecture. The common mechanism can remain narrow: organize forwarding dependencies so a prepared alternate can be invoked without per-prefix rewriting. Each operator should decide locally which route families, platforms, failure classes and detector thresholds justify the trade. A useful mechanism does not need to become a universal mandate.

Running-code primacy supplies the acceptance test. The configuration says a backup exists. The RIB says it is eligible. The FIB says a hierarchy was programmed. Only packets show which adjacency, label and interface carried traffic after the failure. The farther evidence moves from running forwarding, the weaker the authority of the claim.

Practical data sovereignty also appears in an unexpected place. Owning the route-policy repository is symbolic if the operator cannot inspect the standby state embedded in proprietary forwarding hardware. Practical control means being able to query, test, age, replace and revoke the precomputed decision—and to measure the result without relying solely on the system that made it.

BGP PIC is powerful because it moves work out of the emergency. It is governable only if it moves evidence there too. The backup should not first become visible when the primary disappears. Its origin, diversity, trigger, hardware realization, capacity and expiry should already be known.

The deepest leadership decision is not whether to buy faster convergence. It is whether the organization is willing to pre-authorize a dormant route for a large fraction of its traffic, and whether anyone independent can prove that route will still be safe when the alarm finally arrives.

Sources