Summary

  • BGP-LS does not export a byte-for-byte LSDB. Producers derive node, link and prefix objects, apply policy and disclose a physical, abstracted or mixed topology to named consumers.
  • Redundant feeds do not prove freshness. Authority must be bound to producer identity, Instance-ID, source epoch, withdrawals, consumer merge rules and the verified forwarding result of any decision made from the projection.

Imagine a regional link failing between two routers. The IGP converges on both sides, but a partition prevents either BGP-LS producer from seeing the complete withdrawal state. Producer A keeps the A-to-B half-link. Producer B keeps the B-to-A half-link. Each record looks internally credible: known node descriptors, familiar metrics, a valid BGP path.

The consumer merges the two feeds. Its topology becomes tidier than reality. The broken link appears whole, a path computation engine chooses it, and an automation system asks routers to install the result. The API calls succeed. Packets stop at the gap.

This is not a hypothetical invented around an implementation bug. RFC 9552, the current BGP-LS base specification, describes the stale opposite-half-link risk when redundant producers lose reachability to originating nodes. The example reveals the protocol's essential governance boundary: BGP-LS distributes a policy-shaped account of topology. It does not notarize physical truth.

A projection leaves the LSDB behind

BGP-LS begins with link-state and traffic-engineering information, commonly learned from OSPF or IS-IS and held in an LSDB or traffic engineering database. A producer transforms that material into BGP Link-State NLRI and BGP-LS attributes. The result can describe nodes, links and prefixes, including physical and virtual structures.

The transformation matters. RFC 9552 says a BGP-LS object can combine information that originated in several LSAs or LSPs. It does not carry the source protocol's sequence numbers. Not every source field is suitable for export, and aged, malformed or ignored source material follows the source protocol's own treatment. The exported object is therefore derived evidence, not a packet capture of the LSDB.

Policy adds another deliberate difference. An operator may disclose the physical topology, an abstracted topology of aggregated nodes and virtual paths, or a mixture. Policy can also affect when updates are originated. An ALTO service may need a coarse cost map; a path computation function may need a richer traffic-engineering view. A difference from inventory is not automatically an error. It becomes an error only relative to the approved disclosure contract for that consumer and epoch.

That distinction should change incident language. “The controller had the topology” is too broad. A defensible claim names the source domain, producer, policy profile, object set, attributes, time boundary and consumer. Without those qualifiers, topology is an unowned noun.

Three roles, one directional handoff

RFC 9552 separates three roles. A producer originates BGP-LS information, usually from an underlying IGP domain, although direct or static information can also be originated. A propagator receives UPDATEs, runs the ordinary BGP Decision Process and advertises selected information onward. A consumer is the application or process that uses the result. It need not itself be a BGP speaker.

One system may perform more than one role, but the evidence must not merge them. The producer attests that a derived object entered BGP under a particular identity and policy. The propagator attests what it received, selected and advertised. The consumer attests what topology it assembled and what it did with it.

The interface from the BGP speaker to the consumer is explicitly unidirectional. A consumer must not use that handoff to inject information back for BGP-LS origination. That is a valuable separation of authority. A path optimizer may interpret topology, but interpretation does not confer the right to rewrite the disclosed evidence. If an application needs to request network change, it should do so through a distinct, authenticated southbound control surface.

This also prevents a common diagram from misleading leadership. Drawing “IGP → BGP-LS → controller” as one arrow hides at least six decisions: source acceptance, derivation, export policy, BGP selection, consumer merge and computation policy. Each can change the result independently.

Identity is a composite, not a hostname

Non-VPN BGP-LS uses AFI 16388 with SAFI 71; VPN link-state uses the same AFI with SAFI 72. RFC 4760 supplies the multiprotocol capability and MP_REACH/MP_UNREACH containers. Negotiating the family proves that the peers can exchange it. It does not prove that any particular node or link is current, complete or authorized for a consumer.

A BGP-LS key depends on more than a router name. Protocol-ID distinguishes sources such as IS-IS levels, OSPF versions, Direct and Static. The eight-octet BGP-LS Instance-ID distinguishes IGP routing instances. Node, link and prefix descriptors then incorporate domain-specific identifiers such as ASN, area, router identity and topology ID.

All producers representing one IGP domain need the same Instance-ID; different domains need unique values. Get that boundary wrong and a consumer may split one topology into duplicates or collapse distinct domains into one apparent object set. Optional descriptor choices can compound the problem when redundant producers encode the same physical thing differently.

Identity changes are withdrawals, not edits in place. If a descriptor TLV is added, removed or altered, the NLRI key changes. The producer must withdraw the old NLRI with MP_UNREACH as it announces the new one. Otherwise the consumer can retain both identities and build a topology containing a live object and its ghost.

The operational proof for a migration therefore needs a negative half. Showing the new Instance-ID or descriptor in the table is insufficient. The old key must be absent from producer state, propagator RIBs, advertised routes and the consumer's assembled graph after the agreed retention interval.

Redundancy can preserve the wrong thing

Multiple producers are attractive because one feed can survive a process, host or session failure. Their copies pass through ordinary BGP path selection. Yet a selected BGP path is evidence of protocol preference, not proof that the selected topology record is closest to current physical state.

Producers can disagree in two ways. They may describe the same object with different optional TLVs, leaving the consumer to recognize duplicates or tolerate missing attributes. More dangerously, their reachability to the underlying IGP origins may diverge. A feed can remain syntactically healthy while its knowledge becomes incomplete.

The failed-link opening shows why “two sources agree” is not a sufficient control. The consumer may not receive two full observations of one link. It may receive two complementary stale fragments and manufacture agreement while merging them. Freshness must therefore be evaluated before or during merge, using producer reachability, source-object age, topology epoch, expected withdrawals and the origin of every half-link.

RFC 9552 advises producers to withdraw information from unreachable originating nodes unless the use case explicitly requires maintaining a complete LSDB view. The exception is important. Some consumers may deliberately accept a retained view. That choice needs a named purpose, a finite freshness bound and a visible stale-state treatment. It cannot remain an undocumented default.

Missing attributes are evidence of loss

BGP-LS keeps the identifying descriptors in the NLRI and many properties in the BGP-LS Attribute. Error handling can therefore produce a state that looks deceptively clean. Under the rules referenced by RFC 7606, a malformed BGP-LS Attribute may be discarded while the NLRI is preserved.

The surviving NLRI does not prove that the consumer was intentionally told “this link has no metric.” It proves that identity survived while properties may have been lost. Monitoring must distinguish three states: attribute present, attribute deliberately absent under the disclosure policy, and attribute discarded or unavailable because of error.

Unknown or unsupported TLVs also require care. Extension rules preserve and propagate information that an intermediate system may not understand. Canonical TLV ordering prevents alternate encodings from creating ambiguous NLRI keys, but syntax alone cannot establish semantic truth. RFC 9552 deliberately leaves application-level validation to the consumer rather than turning propagators into topology judges.

Size is another source of asymmetry. Rich attribute sets can require the extended BGP message capability defined by RFC 8654. If producers or paths exclude different TLVs, or if support differs along the route, two consumers can receive objects with the same apparent identity but different usable evidence. Compare exact attribute sets, not only NLRI counts.

Transport is not permission to compute

BGP-LS can feed systems described by the PCE architecture, ALTO and other controllers. It can also carry performance metrics standardized in RFC 8571. Those uses do not pull consumer behavior into the BGP protocol contract.

A received topology object does not authorize a path computation. A computed path does not authorize installation. A successful southbound request does not prove device acceptance. A device acknowledgement does not prove label or FIB state. And installed state does not prove that packets traversed the intended path.

The evidence chain must therefore keep its handoffs visible:

  1. Preserve the source LSA/LSP identity, protocol, originating-node reachability, LSDB/TED epoch and selected derivation inputs.
  2. Record producer software, role, Protocol-ID, Instance-ID, object descriptors, abstraction policy and origination or withdrawal time.
  3. Prove AFI/SAFI capability, peer role, received and advertised UPDATEs, selected and alternate paths, attribute presence and propagation delay.
  4. Freeze the consumer's object set, duplicate rules, merge result, missing-attribute state, freshness bound and access authorization.
  5. Bind the computed path to that exact topology snapshot, constraints, algorithm or policy version and approval.
  6. Verify the southbound request, device result, installed label/FIB state, and positive and negative packet canaries.

Only the complete chain can answer why a controller acted. A dashboard screenshot taken after convergence cannot reconstruct the topology epoch that justified a decision before the failure.

Isolate the feed without pretending it is harmless

Link-state changes can be much more frequent than ordinary policy-driven BGP prefix changes. RFC 9552 warns that this update load can interfere with regular prefix distribution and recommends dedicated route reflectors or equivalent isolation. It also scopes BGP-LS distribution to one administrative domain.

Isolation is operational containment, not a trust certificate. Topology and traffic-engineering information can reveal capacity, structure and failure conditions that are commercially or mission critical. Peerings should be explicit and limited to trusted speakers. A consumer-only peer must not be allowed to send UPDATEs merely because it shares a session endpoint with a controller.

Vendor implementations expose useful but product-specific evidence. Cisco IOS XR documents BGP-LS instance and domain controls plus consumer-neighbor behavior; IOS XE documents IGP redistribution, queue throttling and inspection commands. Juniper exposes its TED-to-lsdist.0 flow, import/export policy and controller acquisition procedures. These sources show that the control surface exists in running systems. They do not make syntax, defaults or timing portable across releases.

An audit should record the exact release, inherited neighbor policy and live show output. Configuration intent without runtime evidence is only a planned disclosure.

Sources