Summary

  • draft-ietf-idr-bgpls-inter-as-topology-ext-46 proposes a new BGP-LS Inter-AS Link NLRI and descriptors so a controller can correlate advertisements from opposite sides of an interconnection.
  • A complete edge is derived from source IGP or local configuration, BGP-LS export, policy, identifier consistency, timing and the controller's matching rule. A valid pair does not prove current liveness, capacity or packet delivery.
  • Leaders should require a bounded correlation receipt that preserves both inputs, their provenance and age, the pairing decision and the downstream forwarding observation as separate evidence.

One line is the product of a join

Inside each IGP domain, a BGP-LS speaker can already export nodes, links and prefixes. The gap appears at the border. The two ASBRs know about their interconnection, but the IGP does not generally run across it. A controller can receive the topology of domain A and the topology of domain B while still having no structured edge joining them.

Revision 46 of BGP-LS Extensions for Inter-AS Topology Retrieval proposes that missing representation. It defines Inter-AS Link NLRI type 7 and three descriptors: Remote AS Number, IPv4 Remote ASBR ID and IPv6 Remote ASBR ID. Information can be sourced from OSPF Inter-AS TE advertisements under RFC 5392 or IS-IS Inter-AS Reachability under RFC 9346, then mapped into BGP-LS under the wider rules of RFC 9552.

The important word is correlate. The draft says an Inter-AS link is normally represented by information learned from each side. The controller compares the local and remote AS numbers, ASBR identifiers, BGP-LS Instance Identifiers and, where available, interface or link identifiers. If they align, it constructs one edge. If they do not, it may show an unpaired or incomplete link.

That edge is useful. It is also a new assertion made by the consumer. Neither side transmitted a universal link object whose identity settled the question by itself.

The two reports can have different parents

The main procedure begins in an IGP. An ASBR originates the Inter-AS information; a BGP-LS speaker receives it and builds the NLRI; import and export policy determines whether the consumer sees it. The source protocol remains visible through Protocol-ID.

The draft also permits an alternative. An ASBR that speaks BGP-LS can originate the Inter-AS NLRI from a directly connected interface or static route, marking the source as Direct or Static configuration. The controller then aligns sides using AS numbers and address information.

Two advertisements can therefore look compatible while having different operational ancestry. One may change when an OSPF LSA changes. The other may change only when an operator edits configuration. One may have an IGP flooding history; the other may have a configuration-commit history. A paired topology edge that records only the final descriptors discards this distinction.

The minimum receipt should keep it. For each side, preserve a stable reference or digest of the received advertisement, source protocol, BGP-LS Instance Identifier, local and remote AS and ASBR identifiers, optional interface identifiers, arrival time, age and withdrawal state. Then record the exact rule that paired them and the policy version that admitted them.

This is an editorial proposal, not a requirement in the Internet-Draft. Its purpose is not to create a central allocator for topology. It is to make a local inference reviewable.

Valid syntax is the first receipt, not the last

The evidence chain has at least nine stages:

  1. The interconnection and its router configuration exist.
  2. OSPF, IS-IS or local configuration describes one side.
  3. A BGP-LS speaker receives that state and constructs an NLRI.
  4. Policy allows the advertisement to reach the consumer.
  5. The consumer parses and normalizes the descriptors.
  6. It correlates two perspectives into an edge.
  7. A topology snapshot admits that edge for calculation.
  8. A controller computes and programs a path that uses it.
  9. Packets traverse the intended interconnection and the service meets its objective.

A green result at one stage cannot answer the next. An allocated codepoint proves that implementations have a common number. A parsed NLRI proves that bytes fit the schema. A matched pair proves that two statements satisfy a rule. None proves that the link is up, that its advertised metric is current, that the path was installed or that traffic arrived.

The draft is careful about its own status. Revision 46 is an active IDR working-group Internet-Draft dated 29 September 2026. It is not an RFC, and its source packet contains no public deployment, interoperability test or measured forwarding result. The IANA registry shows early allocations for type 7 and TLVs 270–272. Early allocation enables code. It does not certify the operational chain.

Asymmetric filtering creates believable incompleteness

The extension can be deployed incrementally. Not every router must understand it. The originators, BGP-LS speakers and consumers involved in the path do. That is operationally sensible, but it creates several ways for one side to arrive without the other.

The source IGP may omit a descriptor. One BGP-LS speaker may be upgraded and the other may not. An export policy may filter one NLRI. A session may lag. One side may be withdrawn while the other remains. Two ASBR identifiers may disagree even though operators believe the cables are the same.

Revision 46 tells operators to inspect each layer: confirm the information on both ASBRs, find it in the OSPF or IS-IS advertisements, verify that the BGP-LS speakers received and exported it, compare the local and remote identifiers, and inspect policy. It encourages implementations to expose whether correlation succeeded.

That last status should not be compressed into a binary “link present.” Useful states include paired, unpaired, conflicting, stale, withdrawing and unsupported. An incomplete edge is evidence in its own right. It may reveal a policy boundary or update race, not merely bad data.

Time can fabricate agreement

Correlation also needs a snapshot boundary. Suppose side A's advertisement is received at 09:00 and side B's at 09:04. At 09:02, A changes its remote identifier and withdraws the old report, but the withdrawal is delayed. At 09:04, the controller can hold two records that match even though they were never simultaneously current.

The draft does not prescribe one universal aging or acceptance policy. That is appropriate for a protocol extension serving different operational systems. It also means the consumer owns the decision. A receipt should state the observation times, accepted freshness window, withdrawal handling and topology snapshot identifier. Otherwise “the reports matched” can conceal a temporal join that no network state ever supported.

The same problem appears after a link fails. Keeping the edge briefly may prevent route churn. Removing it immediately may reduce blackholing. Either choice can be defensible. The governance failure is to hide it inside an opaque confidence score while downstream path computation treats the edge as an ordinary fact.

The map is sensitive and still incomplete

The draft focuses on multiple ASes under one administrative entity—a controlled environment spanning backbone, metro and data-centre domains. It warns that the descriptors reveal critical interconnection information and should remain inside the controlled domain or be filtered before leaving it.

Auditability does not require publishing the whole map. A receipt can retain internal digests and scoped references, with access controls and limited retention, while allowing an authorized reviewer to reconstruct the decision. The minimum shared evidence should be narrow enough to protect topology and complete enough to distinguish source failure, export filtering and consumer mismatch.

Even a perfectly protected receipt remains a map receipt. It is not a service receipt. The multi-domain traffic-engineering scenario in RFC 8735 explains why the controller needs an inter-domain view to calculate a path. Calculation is followed by programming, convergence and forwarding. Those events require their own evidence.

A test that can falsify the picture

Heng Lu's Running Code Primary principle suggests a stronger acceptance test than parser conformance. Feed two independent implementations a controlled sequence: matching half-links, mismatched remote ASBR IDs, one-sided filtering, reordered updates, a delayed withdrawal and a static/direct report paired with an IGP-derived report. Record which edges each implementation creates, degrades and removes, and why.

The test should compare more than final topology. It should compare receipts: the inputs selected, the correlation rule, the snapshot boundary and the transition reason. If two controllers draw the same line for different reasons, apparent interoperability may disappear at the first failure.

Minimum Initial Specification also argues against overreach. Standardize enough evidence for systems to compare and challenge the join. Let local operators choose storage, remediation and path policy. The common rule need not become a common controller.

The result is a humbler but more useful statement. “The controller has a complete Inter-AS link” should mean: it received these two bounded advertisements, from these sources and times, applied this matching and freshness rule, found no unresolved conflict, admitted the edge to this topology snapshot, and can point separately to any path and forwarding result that followed.

That sentence is longer than a line on a map. It is also the first one another operator can audit.

Sources

  1. BGP-LS Extensions for Inter-AS Topology Retrieval, revision 46
  2. Revision history
  3. RFC 9552 — Distribution of Link-State and Traffic Engineering Information Using BGP
  4. RFC 5392 — OSPF Inter-AS traffic-engineering extensions
  5. RFC 9346 — IS-IS Inter-AS traffic-engineering extensions
  6. RFC 8735 — Multi-domain traffic-engineering scenario
  7. IANA BGP-LS Parameters
  8. Lu Heng — Minimum Initial Specification, Localized Future Decision
  9. Lu Heng — On Reality Layers
  10. Lu Heng — Running Code Primary
  11. Revision 46 HTML
  12. Revision 46 plain text
  13. Official diff from revision 45 to 46
  14. RFC 7426 — SDN terminology
  15. RFC 9086 — BGP-LS Egress Peer Engineering