Summary

  • RFC 9658 makes an mLDP multipoint FEC unique by adding the {MT-ID, IPA} topology-and-algorithm tuple, then applies that scope to signaling, upstream resolution, downstream-interface selection and LSP Ping.
  • Negotiated MT Multipoint Capability and an exact scoped FEC establish declared support and identity; they do not prove a common topology epoch, installed replication state, every eligible branch, packet forwarding or receiver delivery.
  • The defensible receipt chain joins topology definition, algorithm revision, capability state, FEC bytes, root resolution, branch set, labels, per-branch probes and service outcome without collapsing one layer into another.

One root can name several trees

Multipoint forwarding looks deceptively simple when described from its root. A root address and an opaque value identify the distribution intent, while labels and downstream interfaces turn that intent into a tree. Multi-Topology Routing and Flexible Algorithm complicate the picture for a good reason: one physical network can expose different permitted links, metrics and constraints to different services.

RFC 9658 makes Multipoint LDP aware of that difference. The identity of the multipoint LSP becomes more than the root. The {MT-ID, IPA} tuple is part of its Forwarding Equivalence Class. Two FECs that carry the same root and opaque value but different topology or algorithm identifiers are different MP LSPs.

That is a clean naming rule, not a delivery claim. The tuple tells each hop which routing universe should be consulted. It does not show that every hop held the same version of that universe, found the same constraints, installed the correct replication state or forwarded traffic to every leaf.

Eight reassigned bits carry an authority boundary

RFC 7307 had already defined MT IP and MT IPv6 address families for topology-scoped unicast LDP. RFC 9658 updates it by taking eight bits from a previously reserved sixteen-bit field and using them for the IGP Algorithm. The remaining reserved octet must be zero when sent and ignored when received.

The small field carries a large distinction. MT-ID selects a topology; IPA selects the computation algorithm within the relevant topology. RFC 9350 defines Flexible Algorithm as a way to construct constrained sub-topologies. The current IANA IGP Algorithm Types registry separates the familiar SPF values from the Flexible Algorithm range.

Encoding prevents one scoped FEC from being mistaken for another. It cannot prove the distributed definition behind the numeric IPA. A useful record therefore includes the tuple, the algorithm definition and revision, the topology data set and epoch, the exact FEC bytes and the time at which each router resolved them.

Capability is a promise about procedure

RFC 9658 adds MT Multipoint Capability, assigned 0x0510 in the IANA LDP Parameters registry. A speaker can advertise it in session initialization or dynamically after Dynamic Announcement from RFC 5561 has been negotiated. Its S bit announces or withdraws support.

Successful advertisement and negotiation require the speaker to support topology-scoped mLDP FECs and forwarding setup. That is meaningful interoperability evidence. It proves more than a configuration checkbox because it is exchanged between peers.

It still remains a procedural promise. It does not identify the topology database revision used for a particular FEC, show that root resolution succeeded, enumerate installed branches or prove a data-plane packet. Store the capability transition, peer identity, session epoch and software build beside the later FEC and label events. A withdrawn capability must not be interpreted automatically as withdrawal of every previously installed label, nor may old state be assumed safe merely because the session persists.

The tuple changes both sides of the branch decision

RFC 6388 defines base mLDP procedures for P2MP and MP2MP LSPs. RFC 9658 applies topology scope to the critical choices. For the upstream LSR, the root's best path must be found in the sub-topology selected by {MT-ID, IPA} before the next-hop LDP peer is chosen.

For a downstream branch, physical reachability to a neighbor is no longer sufficient. The forwarding interface is eligible only if it belongs to the same signaled sub-topology. That restriction is the point of the extension: a low-latency, administrative or resilience topology should not leak onto an interface excluded by its algorithm.

The operational receipt must capture the input and result on both sides: topology and algorithm revision, root lookup, selected upstream peer, candidate downstream interfaces, the reason each interface was admitted or rejected, the local label, replication entry and hardware-programming result. A label mapping without this context says which object was discussed, not whether its tree was faithfully realized.

Wildcards and End-of-LIB need the same scope

RFC 5918 defines typed wildcard operations over a FEC type. RFC 9658 lets those operations target multipoint FECs inside a specific {MT-ID, IPA} scope. That avoids a wildcard intended for one sub-topology silently applying to another.

RFC 5919 supplies End-of-LIB signaling. RFC 9658 permits convergence to be signaled per sub-topology using the MT Typed Wildcard MP FEC. This is valuable during restart, maintenance and bulk label exchange.

End-of-LIB is nevertheless a boundary marker in one control conversation. It is not proof that every router used the same topology epoch, that hardware accepted all entries or that every branch forwards. Record which peer, session, FEC scope and database epoch the marker closed. Otherwise “converged” becomes a word that borrows authority from a message whose domain was narrower.

A scoped ping tests a scoped question

RFC 6425 defines multipoint LSP Ping, building on the MPLS Echo machinery in RFC 8029. RFC 9658 reuses the P2MP and MP2MP FEC Stack subtypes but inserts MT IP or MT IPv6 and extends the root field with {MT-ID, IPA}. The probe can therefore ask about the intended topology-scoped multipoint FEC instead of an ambiguous root.

A successful response proves only the tested path, branch and instant under the probe's semantics. It does not prove an untested leaf, continuous packet replication, application acceptance or a customer's full multicast experience. A tree-wide claim requires a branch inventory, probe coverage, data counters and receiver observations joined to the same FEC identity.

The distinction also protects failure analysis. A scoped ping failure may be a missing FEC, wrong topology view, ineligible interface, absent label, hardware-programming fault or data-plane defect. Treating all of them as “multicast down” throws away the very scope that RFC 9658 added.

Service signaling must not outrun tree evidence

RFC 6514 uses an mLDP FEC inside the MVPN PMSI Tunnel attribute. When RFC 9658's extension is in use, that tunnel identifier must carry the MT-scoped MP FEC form. The service advertisement and transport tree can therefore share a precise topology-and-algorithm identity.

The advertisement is still not the tree. It may precede downstream label state, platform programming or receiver readiness. Keep the PMSI route, scoped FEC, label state, replication branches, counters and receiver evidence as connected but distinct records.

RFC 5036 and the MPLS security framework in RFC 5920 provide the underlying LDP and security context. Authentication and session protection matter, but an authenticated peer can still hold stale or inconsistent topology data. Security establishes who exchanged the claim; it does not make the claim's forwarding result true.

Use the tuple as a join key, not a verdict

The practical evidence model begins with the algorithm definition and topology revision. It then stores peer capabilities, session epoch and the exact scoped FEC. Root resolution produces an upstream decision. Interface evaluation produces a branch set. Label distribution and hardware programming produce installed state. Scoped probes, counters and receiver acknowledgements produce operational results.

Heng Lu's Minimum Initial Specification supports the small common vocabulary: tuple, revision, peer, label, interface, probe and result. The reality-layers discipline prevents a FEC identity or capability bit from impersonating forwarding. Running-code primacy gives the final authority to installed state and observed packets.

RFC 9658 solves an important ambiguity. It lets the network say which multipoint tree it means. Leadership's task is to ensure that “which tree” never gets reported as “the tree worked” until every required branch has supplied its own receipt.

Sources