Summary

  • The IETF published revision 38 of its BGP-LS inter-AS topology proposal at 09:22:08 UTC on 19 August. Its only substantive body change from revision 37 removes Multi-Topology Identifier (TLV 263) from the proposed Inter-AS Link descriptor list.
  • The change does not remove MT-ID from BGP-LS. It changes a proposed NLRI identity set, making clean withdrawal, half-link pairing and non-default-topology handling the next implementation tests.

The most consequential line in the latest BGP-LS inter-AS topology draft is the one that is no longer there.

The IETF history record says revision 38 became available at 09:22:08 UTC on 19 August. A comparison of the official revision 38 and 37 sources finds one substantive change: the new text deletes Multi-Topology Identifier, TLV 263, from a list of fields used to describe a proposed Inter-AS Link NLRI.

This is not a generic metadata list. In BGP-LS, descriptors help form the identity of the object carried in the NLRI. The draft addresses a gap between separate IGP domains: each domain can report its own topology, but a controller also needs the links between their autonomous systems if it is to join those maps. Revision 38 proposes NLRI type 7 for that interconnection, plus TLVs for the remote AS number and the remote border router's IPv4 or IPv6 identifier.

The controller then has to bind two one-way reports into one logical link. The draft calls them half-links. Its use case places multiple ASes inside one operator's administrative domain, allowing an SDN controller to combine the domain topologies and calculate an end-to-end path. Nothing in the record proves that the calculation has been implemented or works across independent products; it describes the intended mechanism.

Revision 37 listed the existing link descriptors after the new remote-AS fields: the Local/Remote Link Identifiers TLV, IPv4 interface and neighbour address TLVs, IPv6 interface and neighbour address TLVs, and MT-ID. Revision 38 stops after the IPv6 neighbour address. The warning immediately below remains: other TLVs used as descriptors may make it harder to correlate the two half-links when producer implementations differ.

The deletion is therefore narrower than saying the IETF has abandoned multi-topology information. RFC 9552, the current BGP-LS base specification, still assigns type 263 to MT-ID. For an ordinary Link NLRI, it requires MT-ID when an IGP link belongs to a non-default topology and requires a separate NLRI for each topology identifier. Revision 38's Security Considerations also still names MT-ID among the critical inter-AS characteristics that should remain inside the operator's “walled garden” or be filtered before leaving it.

What changed is the proposed descriptor contract for the new Inter-AS Link NLRI. That distinction creates a concrete migration question. A producer following revision 37 may encode TLV 263 as part of the identity; one following revision 38 may omit it. If a consumer treats both advertisements as separate keys, one physical half-link can appear twice. If it merges too aggressively, links associated with different topologies may become indistinguishable.

RFC 9552 already supplies the hygiene rule for such transitions. When a producer adds, removes or modifies a TLV in a Link-State NLRI, it must withdraw the old NLRI. Otherwise, the specification warns, duplicate and inconsistent objects can remain in the BGP-LS table. That is a testable requirement, not evidence that revision 38 has caused a live problem.

The registry also shows why the document is not ready to be treated as a final wire contract. When checked on 19 August, the IANA BGP-LS registry said it was last updated on 7 August, labelled code point 7 Stub Link NLRI and cited revision 17. Revision 38 calls the same code point Inter-AS Link NLRI. TLVs 270–272 carry the current remote-AS and border-router names but also cite revision 17. The Datatracker status page records Version Changed - Review Needed for IANA, while the expert-review state is Expert Reviews OK.

That difference should be read as work in progress, not as a licence to choose whichever label suits an implementation. Revision 38 remains a Proposed Standard Internet-Draft submitted to the IESG. Its state moved from Revised I-D Needed to AD Followup when the new version was posted. It has not become an RFC, and the official materials available on 19 August include no interoperability report, vendor-support matrix, packet trace, deployment result or performance measurement.

For operators, the immediate value is a sharper test plan. The descriptor change affects topology identity before it affects path selection. A safe evaluation must show that a revision-37 advertisement is withdrawn, the revision-38 replacement is accepted once, both halves pair to the intended link, and links in non-default topologies remain separate. It must also show that the critical topology data does not escape the intended administrative boundary.

Sources