Summary

  • Donald Eastlake's Routing Area Directorate early review was completed on 27 September with a “Not ready” result. That is one review of an active IDR working-group draft, not an IESG rejection or a change to BGP today.
  • Revision 13 says a next hop SHOULD be resolved in the forwarding database for the chosen data plane and that a path-availability check MAY be used. The reviewer says the text does not expressly make a failed check disqualify a route from best-path selection.
  • His other core question is which forwarding state counts: an LDP label, Segment Routing SID, tunnel or recursively resolved route need not describe the same packet path. A check against the wrong state can certify the wrong thing.

The route that attracts a packet and the mechanism that forwards it are not always the same piece of evidence. BGP can see an IP route to a next hop while traffic is meant to travel over an MPLS label-switched path. If the chosen path cannot carry packets, the routing-table answer alone is an incomplete basis for selecting and advertising the route. Revision 13 of the IDR working group's best-path draft is an attempt to sharpen that basis. Its appendix uses a provider-edge router and a nonfunctioning MPLS path to show how traffic might be drawn to an unusable route even when an alternative exists.

That is an illustrative scenario, not a report of a particular outage.

The news is a completed early review, not publication of a new standard. Donald E. Eastlake III dated his review 25 September; the Routing Area Directorate record marks it completed on 27 September and records “Not ready”. The Datatracker still shows an active working-group Internet-Draft, revision 13, with IESG state “I-D Exists” and no telechat date. The draft says it would update RFC 4271 only if approved. Earlier working-group last call and area-director review occurred in 2020; the fresh review does not erase that history or amount to a final IETF verdict.

The proposed normative text is short. Section 3 says next-hop reachability SHOULD be resolved in the forwarding database of the selected data-plane protocol. It then says a path-availability check MAY be performed using OAM associated with that same data plane. Policy chooses the data plane; the draft leaves policy and check mechanisms outside its scope. Eastlake's first objection is about a missing decision boundary. RFC 4271 already excludes an unresolvable route from the Phase 2 decision function, but revision 13 does not explicitly say that failure of either new check makes the route unresolvable for that purpose. A conclusion mentions advertisement or withdrawal, yet leaves the link to the best-path rule implicit. Eastlake proposes stronger wording. That proposed MUST is his review suggestion, not language already adopted by the draft.

Even a defined failure consequence would be under-specified if implementations consult different forwarding state. Eastlake lists possible MPLS evidence: LDP-derived entries, Segment Routing prefix SIDs, RSVP-TE or SR Policy tunnels, and recursively reached BGP labeled-unicast routes. A directly connected next hop may use an unlabeled entry. Those are not interchangeable checks. His proposed principle is to inspect the state the speaker will actually use to forward to that next hop, following the same recursion. The draft has not yet settled that wording.

There is also existing standards territory to reconcile. RFC 9012 already says a route with no feasible tunnel in its Tunnel Encapsulation attribute is unresolvable under RFC 4271. Eastlake asks what the new draft adds when that attribute selects the data plane. An overlap question is not proof of contradictory standards. He separately warns that optional liveness checks can flap, miss broken forwarding or fail while forwarding is healthy; inconsistent plain-IP decisions may create loops. Those are design risks for the working group to address, not measured failures of deployed networks.

For operators, the useful question is therefore more exact than “is the next hop reachable?” Which data plane and label or tunnel did policy select; which recursive forwarding state was tested; what was the result; and did that result actually remove the route from candidate selection? Keeping those answers together would make a future rule inspectable. It is Daniel Kade's operational interpretation of the review, not a new IETF reporting requirement. The current draft and its review do not establish how often self-blackholing happens or whether any named implementation has this fault.

Sources