Summary

  • RFC 9234 joins BGP Role with OTC processing; the attribute is not a context-free route-leak label.
  • A compliant receiver adds OTC when it receives an unmarked route from a Provider, Peer or Route Server, so before-ingress and after-ingress views can legitimately differ.
  • Role negotiation may be asymmetric during incremental deployment, while complex relationships and non-unicast address families sit outside the ordinary procedure.
  • Operators should preserve an operational route-scope evidence record that separates captured view, Role agreement, OTC synthesis, local eligibility and end-to-end scope states.

Imagine a route-monitoring panel that turns green whenever an UPDATE contains no OTC attribute. One captured update arrives from a transit provider without OTC, and the panel labels it leak-free. Yet the capture was taken before the receiving router’s ingress procedure. That router is precisely where RFC 9234 requires a missing OTC attribute to be added with the remote provider’s ASN.

Nothing failed in the protocol. The failure is in the evidence model: a pre-processing snapshot was treated as an end-to-end verdict.

RFC 7908 defines a route leak as propagation beyond intended scope. That scope normally lives in distributed export and filtering policies, often expressed through pairwise provider, customer and peer relationships. Its taxonomy is a working classification rather than an exhaustive account of every possible leak. One path attribute can carry useful relationship provenance, but its absence at one point cannot reconstruct the intended scope, every prior processing action or the set of neighbors that actually received the route.

OTC is an optional transitive path attribute, type code 35, with a four-octet value and a strict operational purpose. Once a route has been sent to a Customer, Peer or Route Server Client, it should subsequently go only to Customers. RFC 9234 defines concrete ingress and egress rules around that purpose. A sender advertising an unmarked route to a Customer, Peer or Route Server Client must add OTC. A route carrying OTC and arriving from a Customer or Route Server Client is a leak and becomes ineligible. A Peer-originated route is also a leak when OTC names an ASN other than the Peer’s ASN.

A route that already carries OTC must not be propagated to Providers, Peers or Route Servers, and once OTC is set its value must be preserved unchanged.

Those are powerful rules. They are powerful because the observer knows the session Role, direction and processing context—not because four missing octets mean “safe”.