Summary

  • A reachable BGP NEXT_HOP remains necessary, but tunnels and segment-routing services can make another endpoint, context and datastore decisive for actual forwarding.
  • The proposed path-resolution tuple keeps resolvability, preference, metric and tracking in one context; leaders should require that atomic receipt and verify installation and delivery separately.

One address, several forwarding realities

Classical BGP selection has a compact intuition: determine whether NEXT_HOP is reachable, obtain the interior cost to it, and use that evidence while choosing a path. RFC 4271 rests on the speaker being able to ascertain such a cost. That model becomes less reliable when an advertised route is carried through GRE, MPLS, an SR Policy or an SRv6 service. The control-plane address can be alive while the forwarding object that matters is absent, undesirable or measured by a different system.

Revision 00 of BGP Best Path Selection Based on Next Hop Resolution was published on 24 September 2026 as an IDR working-group Internet-Draft. It is Standards Track work in progress and would update RFC 4271 if approved; it is not an RFC, a deployment mandate or evidence of broad implementation.

The draft names a useful unit of accountability: the path-resolution tuple. A tuple contains a resolution key and, optionally, a resolution context. The key is the object to be resolved for that candidate BGP path. It may be the ordinary NEXT_HOP, a Tunnel Egress Endpoint carried under RFC 9012, or an SRv6 service SID defined by RFC 9252. The context identifies or parameterizes the procedure and datastore: for example, a Tunnel Encapsulation attribute, a Color extended community or SRv6 sub-TLV information other than the SID.

This distinction makes two superficially similar requests non-equivalent. Resolving {N1, C1} through an SR Policy is not the same observation as resolving {N1} through an ordinary next-hop lookup. Even when the key is identical, a different context—or no context—means a different resolution request.

The atomicity rule is the real control

The most important sentence in the proposal is architectural rather than algorithmic: resolvability, preference, metric and tracking for a path must refer to the same resolution. An implementation must not take a green reachability result from one context and attach a cheaper metric returned by another. That composite record may be numerically attractive, but it describes no forwarding path that any subsystem actually resolved.

Resolution constraints narrow the eligible routes or datastores. They may require a particular tunnel type, prohibit resolution over an aggregate or impose an ordered classful-transport scheme. A constraint is not another tuple component; it is the local rule governing how that tuple may be satisfied.

The ordinary NEXT_HOP check remains. The proposal adds a check for the path-resolution tuple, subject to those constraints, and permits the extra behavior to be enabled by configuration. This matters operationally: the new mechanism does not license an operator to ignore a broken conventional next hop simply because a tunnel-specific object still resolves.

Metrics create the next trap. A value returned for one tuple may be IGP cost; another may mean latency; a third resolution may provide no cost at all. Equal-looking numbers need not share a scale. Revision 00 therefore proposes a local numerical resolution-key preference, where lower is preferred, to order unlike mechanisms before cost is compared. After that preference filter, the internal cost must come from the tuple itself. A resolvable tuple without a metric should receive the maximum allowed cost, not a conveniently borrowed value.

Keep eight receipts apart

A defensible path decision needs more than a best-path log line.

The advertisement receipt preserves the exact route, NEXT_HOP and tunnel or segment-routing attributes. The tuple receipt records the key, context and derivation rule. The constraint receipt identifies the local policy and eligible datastore. The resolution receipt binds reachability, preference, metric, forwarding data and observation time in one atomic result.

The selection receipt shows the candidate set, preference filtering, comparable-cost step and final choice. The tracking receipt identifies subscriptions for both ordinary NEXT_HOP and every context-distinct tuple, including non-best candidates. The installation receipt observes what reached the RIB, FIB and encapsulation state. The delivery receipt measures the packet path and service outcome.

None can substitute for the next. A selected path may fail to install. A programmed tunnel may send traffic somewhere unexpected. A reachable SID says nothing by itself about application success. The draft describes risks such as congestion, drops and misrouting, but these are problem statements, not measurements of current networks or proof that the proposal cures them.

Tracking must preserve identity

Resolution changes after selection. The draft therefore expects a BGP speaker to track both the ordinary next hop and the tuple. Loss of either resolution, or a change in tuple-derived metric, should cause reevaluation of every affected prefix.

The subscription key matters. Identical resolution keys with different contexts must remain distinct. Tracking only the current best path is insufficient because a non-best candidate may become eligible without a fresh advertisement. An implementation that deduplicates {N1, C1} and {N1} into one watcher has discarded the very evidence boundary the tuple was introduced to preserve.

Minimum standard, local choice

The proposal fits Heng Lu's argument for a minimum initial specification with localized future decisions. A common rule can define tuple identity and prohibit cross-context evidence mixing without centralizing which transport an operator should prefer. Operators still choose constraints, preference values and rollout timing inside their own administrative domains.

That separation also reflects his distinction between authority and belief. An advertisement is authoritative evidence of what a speaker announced; a resolver result is evidence of what a particular routing system found. Neither compels belief that packets followed the intended path. Running-Code Primacy supplies the final discipline: implementation claims require versioned software, atomic logs, programmed state and packet observation, not merely a clean diagram or a published draft.

The design should also stay separate from the transport-class mechanism in RFC 9830. Color can participate in a tuple's context, but this draft's leadership problem is not whether color import and SLA policy are correct. It is whether all inputs to one BGP decision describe the same resolution event.

Draft status and limits

Revision 00 recommends consistent selection configuration among BGP speakers in one administrative domain. Consistency can reduce divergent decisions; it cannot prove that forwarding state matches control-plane intent. The draft says the mechanism adds no security considerations beyond existing NEXT_HOP use, but bad constraints, stale datastores and inconsistent preferences remain operational hazards.

The text may change before standardization. Implementations may not exist, may differ, or may expose too little evidence to verify atomicity. The proposal is nevertheless valuable now because it identifies the exact forbidden shortcut: do not assemble one apparent path from facts obtained about different paths.

Sources