Use BGP Roles and OTC only after both sides agree on the relationship

BGP Roles and the Only-to-Customer attribute can help prevent or detect route leaks, but the control begins with an accurate statement of the business relationship. A technically valid configuration built on the wrong relationship can reject a session or propagate the wrong policy signal.

Source fact:

IETF RFC 9234 defines BGP Roles negotiated in OPEN messages and the Only-to-Customer, or OTC, path attribute carried in UPDATE messages. The roles describe relationships such as provider, customer, peer, route server, and route-server client. The specification applies its leak-prevention and detection rules to IPv4 and IPv6 unicast address families.

When the two endpoints advertise incompatible roles, a speaker implementing the specification can treat that as a role mismatch. OTC then carries information that lets compliant speakers identify announcements inconsistent with the expected direction of customer-learned routes. The RFC permits a strict mode that rejects a session when a role is absent, but it discourages enabling strict mode by default because a session can fail after one side receives new software while the other side is not yet configured.

Boundary

RFC 9234 does not discover commercial relationships or repair ordinary import and export filters. It excludes some complex arrangements from its simplified relationship model, and effectiveness depends on implementation and adoption along relevant paths. A successfully negotiated role is not proof that the route policy, IRR objects, RPKI controls, or maximum-prefix settings are correct. Mixed vendor and mixed version environments require their own qualification.

Applicability questions

• Is every external session classified from a current contract and network design rather than a naming convention?
• Do both endpoints support the RFC for the address families in use?
• Which relationships do not fit the standard role model, including hybrid or partial-transit arrangements?
• What telemetry exposes role mismatch, received OTC, or a rejected route?
• Could a staged upgrade unexpectedly activate strict behavior or change attribute propagation?

DSE recommendation:

Build a peer register that links each session to its owner, autonomous system, address families, contractual relationship, current import/export policy, and intended BGP Role. Reconcile the classification with the remote party. In a lab or low-risk session, capture OPEN and UPDATE behavior, confirm unknown-attribute handling, and test both valid and intentionally invalid announcements.

Deploy observability before enforcement. Start with mismatch and OTC visibility where the platform permits it, then introduce rejection through approved maintenance windows. Keep explicit route filters in place. Do not enable strict mode fleet-wide until the organization has confirmed peer readiness and a session recovery procedure. Record exceptions for relationships that the model cannot represent cleanly.

Verification and evidence

Retain the approved peer register, configuration snapshots, packet captures or decoded OPEN capabilities, controlled route-test results, relevant logs, and rollback timing. Verification should demonstrate that expected routes remain reachable, an invalid relationship or leak pattern produces the planned signal, and a legacy peer continues under the documented exception. Monitor route counts and reachability before, during, and after rollout.

Official references

• IETF RFC 9234
• IETF RFC 8212, Default External BGP Route Propagation Behavior without Policies