Summary

  • RFC 9832 turns an operator-defined Transport Class into a route-import and next-hop-resolution mechanism; its 32-bit Color is an index, not a universal SLA definition.
  • Color may appear in a Tunnel Encapsulation Attribute, a BGP CT Transport Class Route Target and a service route. The RFC ranks those scopes, but a compliant decision still needs evidence of the received attributes and executed policy.
  • Import into a TRDB, successful next-hop resolution, fallback, FIB programming, packet forwarding and delivered service are distinct states. No earlier state is a receipt for the next.

One number, three instructions

The seductive view of classful transport is a clean one: mark low-latency tunnels blue, attach the same blue value to a service route, and let the network join them. RFC 9832 is more disciplined than that shorthand. It defines a Transport Class as a group of tunnels that an operator judges to offer sufficiently similar traffic-engineering characteristics inside an administrative domain or among closely coordinated domains. The class has a 32-bit identifier. The document calls that identifier a Color.

The bits do not say “low latency”, “high bandwidth”, “avoid this node” or “survives one failure”. The operator supplies that meaning. Values from 1 through 4,294,967,295 are Private Use; zero is reserved for the Best-Effort Transport Class ID. Two networks can therefore use 100 without having made the same promise, measured the same variables or accepted the same fallback. Equality of integers is not equality of contracts.

Color also appears at several scopes. A Color sub-TLV in the Tunnel Encapsulation Attribute applies to a particular encapsulation choice. A Transport Class Route Target on a BGP CT route associates that transport route with a class and can select a Resolution Scheme. A Color extended community on a service route expresses the service-side mapping request. Section 7.10 establishes an explicit order from most specific to least: TEA Color sub-TLV, Transport Class RT, then service-route Color extended community.

That order resolves an ambiguity; it does not erase provenance. If an observability system stores only “effective color = 100”, it cannot show whether the winning instruction came from an encapsulation sub-TLV, a BGP CT route target or an overlay service route. It cannot show the losing values, the peer that supplied them or the policy version that evaluated them. A deterministic result without its inputs is hard to reproduce and easy to misstate.

The database is a control-plane boundary

RFC 9832 gives every Transport Class a logical Transport Route Database, or TRDB. Tunnel routes belonging to the class are collected there. A receiving BGP CT route carries RD:endpoint, a Transport Class RT and a label or equivalent identifier. The RT’s route-target role tells the receiving speaker which class database should import the route, if that class is provisioned locally.

Import is not the same as use. A TRDB may be implemented as a routing table used only for control-plane next-hop reachability. The RFC says its tunnel routes require no forwarding-plane footprint unless they resolve a next hop. This distinction matters during an incident: a route can be present in the correct class database while no service route selects it, no forwarding entry points to it, or its encapsulation is unusable on the next device.

The same Transport Class RT can play a second role as a Mapping Community. That role maps the route to one locally configured Resolution Scheme. A scheme contains one TRDB or an ordered set. The protocol next hop is looked up by longest prefix match within those databases, in order. A route in a backup TRDB is used only when preceding databases contain no match.

An operator can customize the ordered list. If no scheme exists for the received class, the Best-Effort scheme is used. If a route has no Mapping Community, best effort also resolves the next hop; for BGP CT, the route is then not added to a class TRDB. These are operationally consequential fallbacks, not harmless parser defaults. A service that still reaches its destination may have left its intended class without generating an obvious outage.

Fallback must leave a receipt

The difference between “primary unavailable” and “primary has no matching endpoint” is essential. RFC 9832’s lookup moves to the next TRDB when it finds no matching route for the endpoint in earlier databases. That tells an implementation what to do. It does not tell an assurance team why the match disappeared: tunnel down, incomplete import, RTC filtering, wrong endpoint, policy change, stale class provisioning or incompatible forwarding technology.

A useful resolution record therefore needs the received route and peer, every Color-bearing field, the effective Mapping Community, the Resolution Scheme version, the ordered TRDB list, the database that matched, the endpoint prefix, the selected tunnel and whether fallback occurred. A green “resolved” lamp discards the decision path that matters most when the customer asks why latency changed while reachability remained.

Failure remains possible after correct classification. If no selected TRDB contains a matching route, the BGP CT or service route is unresolvable. In the Best-Effort case, an unusable BGP CT route must not be propagated further. Route Target Constraint can limit distribution, and RFC 9832 requires multiple external RTC paths—not only the best one—to be considered when building an outbound filter. A missing route may therefore be a distribution fact before it is a tunnel fact.

Borders translate numbers, not outcomes

RFC 9832 explicitly supports domains that do not share a Transport Class namespace. Its non-agreeing example keeps one service Mapping Community, color:0:100500, while local schemes associate that request with color 500 in one domain, 300 in another and 100 in the third. Border speakers rewrite Transport Class RTs from 500 to 300 and then 300 to 100.

This is a strong design choice because it localizes coordination. Adjacent transport domains can agree on a mapping without forcing every service endpoint into a global mesh of color rewrites. It is also precisely why a captured number needs origin scope. transport-target:0:300 says what the receiving domain should import; it does not prove that the upstream “Gold” and local “Gold” share latency thresholds, loss budgets, protection, measurement windows or remedies.

The mapping receipt should preserve the received and emitted RTs, both local definitions, the adjacent-domain agreement, policy commit, executing border, effective time and rollback. Otherwise an incident archive may show only the final local number and silently convert a negotiated translation into a claim of universal semantics.

Resolution is not forwarding

The control plane still has work after import. When a border node readvertises a BGP CT route with next hop self in an MPLS deployment, it allocates a new label and installs a route that swaps or pops the incoming label, then pushes traffic toward the tunnel or interface that resolved the protocol next hop. Implementations may also selectively install BGP CT routes into the FIB for control-plane peering reachability.

These details make the evidence break visible. The class route can be imported; the protocol next hop can resolve; a label can be allocated; yet the expected hardware entry may be absent, stale or programmed with another encapsulation. RFC 9832’s interoperability examples go further: an MPLS-only node and an SRv6-only node cannot communicate directly without a common forwarding technology, so their received BGP CT routes remain unusable.

The final receipt is outside the color machinery. It is an observed packet path and a service measurement at the promised boundary: loss, latency, availability, protection event and measurement window. A packet arriving does not prove the low-latency class; a low average does not prove the intended path; a correctly programmed FIB does not prove the customer’s SLA. Each claim closes with different evidence.

Experimental protocol, production-grade questions

RFC 9832 is Experimental. Its publication shows a mechanism available for implementation and evaluation, not deployment, interoperability or realized service. The current errata record contains a verified editorial correction replacing three SN1 references with SN11; it does not alter the mechanism described here.

The security boundary is similarly narrow. BGP session protection can protect transport between peers; import and export policy can confine infrastructure reachability; separate SAFI 76 and the new route-target type reduce accidental mixing with service routes. None authenticates the operator’s class definition. A trusted peer can still send a syntactically correct mapping that is wrong for the agreement, and BGP CT adds another surface through which traffic may be diverted.

Heng Lu’s argument that the Internet is colorless is useful here in a literal but limited way. Efficient infrastructure is selected by what works for operators, not by labels. RFC 9832’s Color should be treated the same way: a compact local handle whose value is proven by execution and service evidence. Running-code primacy asks for received routes, policy output and FIB state. The reality-layer discipline keeps identifier, administrative meaning, control-plane result, forwarding behavior and customer outcome apart. These are BTW editorial lenses, not additional IETF requirements.

Sources