Summary

  • RFC 5654, a September 2009 Standards Track document edited by Deborah Brungard, says its MPLS-TP requirements govern the behaviour of protocol mechanisms and procedures that serve as building blocks. It explicitly says those requirements are not implementation requirements and do not describe what functions an MPLS-TP implementation supports.
  • The document makes static and dynamic path configuration possible and says an MPLS-TP network can operate fully, including OAM and protection, without a control plane. Those are designed options and boundaries. They do not identify a current carrier choice, an installed path, a working protection state, traffic, or an SLA result.

A profile is a common surface, not a network command

The word “profile” can sound more decisive than the text warrants. It suggests a finished shape: a network that exists, devices that conform, perhaps even a service that can be sold. RFC 5654 is more careful. Its abstract says it specifies requirements of an MPLS Transport Profile. The requirements are for the behaviour of protocol mechanisms and procedures that constitute the building blocks from which the profile is constructed. The next sentence fixes the boundary: they are not implementation requirements.

The introduction makes the consequence still sharper. The document identifies what features are to be available in the MPLS toolkit and what new protocol work is required. It does not describe what functions an MPLS-TP implementation supports. It is a requirements specification, placed on the Standards Track so that ITU-T work can cite it normatively. A document may therefore be an important common reference without being an inventory of a product, a declaration of a deployed configuration, or an instruction that a carrier must select a particular operating model.

That distinction is not a drafting technicality. A toolkit describes the affordances from which a local system may be built. An implementation has its own supported functions, release choices, interoperation limits and defaults. An operator has further choices about topology, service commitments, provisioning, protection policy, migration timing and evidence. A service team then has to observe whether a particular circuit or packet flow is actually behaving as claimed. None of those later facts appears merely because an RFC names a capability that should be available.

Static, dynamic and absent control planes are different facts

RFC 5654 says that MPLS-TP transport paths may be established using static or dynamic configuration. It also says that an MPLS-TP network and its transport paths can always be operated fully, including OAM and protection capabilities, in the absence of any control plane. The text does not frame one choice as a universal deployment verdict. It preserves an operational space in which the party responsible for the network can select methods appropriate to its equipment, risk appetite, operational discipline and interoperability requirements.

The later control-plane section reinforces that separation. The RFC requires it to be possible to operate an MPLS-TP network without using a control plane. Where a control plane is used, it must support control-plane and data-plane topology independence; as a consequence, a control-plane failure does not imply a data-plane failure. It must also be capable of independent operation from particular client- or server-layer control planes.

Those statements are often most useful as warnings about inference. An available dynamic capability does not prove that dynamic control is enabled. A stated possibility for static provisioning does not prove a static configuration is present. A requirement that data-plane and control-plane failures be distinguishable does not prove either plane is healthy at a named moment. Nor does an OAM or protection requirement show that a protection switch occurred, that it was correctly configured, or that customer traffic was protected. Each assertion needs evidence from the system that owns it.

The document protects boundaries between administrative decisions

RFC 5654 also says that different administrative groups may be responsible for the same layer network or for different layer networks. It requires the possibility of hiding MPLS-TP layer addressing and other information such as topology from client layer networks. At the option of the operator, it should be possible to leak limited summarized information, such as shared-risk link groups or reachability, between layers.

This is a deliberately modest common rule. It makes a boundary available; it does not abolish the boundary. A client layer is not automatically entitled to a full lower-layer topology. An implementation does not automatically reveal an operator's administrative model. A standard gives enough structure for intended interworking, while the responsible parties decide what information is exposed and under what circumstances.

That restraint is valuable precisely because it leaves accountability legible. If a network publishes a summary, the operator can identify the source, scope, freshness and policy of that summary. If it withholds details, a reader should not reconstruct a fictitious universal topology from an RFC's possible mechanisms. A requirement for a feature is neither evidence that the feature is configured nor a license to fill a missing operational record with institutional language.

The running system still has to supply the receipts

For an actual transport claim, the evidence chain is longer than the document. An implementation record can show software version, supported functions and configuration. The management or control plane can show the intended path, the administrative owner, and any signalling or provisioning action. The forwarding plane can show installed state and counters. OAM can show what was tested, when, and against which endpoint. Protection evidence can show the triggering condition, selected action and outcome. Service evidence can then show the customer-relevant result within its stated measurement boundary.

The RFC supports none of those receipts by itself. It supplies the common vocabulary within which particular systems may be designed. It does not prove a named vendor support matrix, inventory, topology, path, flow, failure, protection event, or customer outcome. Treating the document as a substitute for those records creates an attractive but untraceable story: the standard becomes the operator, the available feature becomes a deployment, and the desired service result becomes an assumption.

This is where the text resonates with Heng Lu's distinction between a minimum common specification and localized future decisions. A coordination artifact can tell independent participants what must be portable or interoperable. It does not make a later operating choice real until participants adopt it in running systems. RFC 5654 does not claim to settle all later choices; it carefully refuses to turn a toolkit into a universal implementation mandate. Its limit is therefore part of its usefulness.

Attribute Brungard's work without borrowing authority

The RFC lists Ben Niven-Jenkins, Deborah Brungard, Malcolm Betts, Nurit Sprecher and Shigeru Ueno as editors. Brungard's IETF Datatracker profile identifies her, records her standards background and provides the public reference photo used to ground the editorial portrait. Those materials support a bounded attribution: she was an editor of this collaborative requirements document.

They do not show that she alone wrote the RFC, chose a later technology implementation, controls current IETF or ITU-T decisions, runs a carrier network, determines an operator's topology disclosure, or guarantees a transport service. The precise credit is stronger than a grander false claim. It acknowledges work on a shared architectural boundary while preserving the local authority of the people who implement, configure, observe and answer for actual networks.

Evidence limits

The sources establish what RFC 5654 requires and what it explicitly leaves outside its scope. They do not establish the present use of MPLS-TP by a particular operator, a deployment location, a live path, topology, control-plane state, OAM result, protection action, traffic flow or customer experience. The receipt chain described here is an operational reading of those boundaries, not an extra mandate embedded in the RFC.

Sources