Summary

  • The 28 October revision of an individual elastic bandwidth-aware routing draft replaces two return triggers with conditions that describe traffic already back on its primary path.
  • The proposal defines fallback as moving traffic from alternate paths to that primary path. It supplies no pre-move observation or estimate that would let a local node satisfy its new first condition.

A way around the jam, then a locked exit

Picture a link that still looks connected but has lost half its capacity because one member of a bundle has failed. The shortest route keeps sending traffic through it. The revised elastic-routing proposal gives a local load-balancing node a response: watch utilization, calculate alternate paths and move selected flows across them when the congested link crosses a configured threshold. Segment Routing strict paths carry the detour; unequal-cost multipath weights reflect available bandwidth and utilization. The central traffic-engineering controller can take longer to optimize the network while the local node acts.

That is the sell. The return trip is where the text trips over its own feet.

Section 4.4 defines traffic fallback as moving traffic from load-balancing alternate paths back to the primary path. Then it lists the conditions for that fallback. Condition 1 requires that all traffic has already switched back and that utilization of the primary path remains below a Post-restore Threshold. Condition 2 requires Condition 1 to remain true for a configurable Restore Period. An outcome of the move has become its admission ticket.

The July version 00 took a different route. It offered a measured threshold on the congested link or a dynamic judgment that the local link could carry all traffic without congestion, sustained for a configurable period. The October text deletes those two trigger methods. Its overview still says traffic falls back when conditions such as utilization dropping below a restore threshold are met, but the detailed procedure now asks the node to check the state after the return.

Perhaps the authors intend a prediction: calculate what utilization would be if every diverted flow came back. Perhaps they expect a trial move, a reservation or staged re-entry. The current §4.4 specifies none of those steps. A node can measure its primary link while traffic is split, but that reading alone cannot show the post-return load. The missing fact is a defined pre-return test. Add one, and the circular reading disappears.

This is a current individual Internet-Draft, not an adopted standard. Its significance is more immediate than a deployed failure claim. The proposal wants local nodes to take control during congestion; the return rule is the moment those nodes must decide for themselves when to stop. A control loop that describes the desired state but omits the decision that reaches it is a proposal with a hole exactly where its local autonomy should operate.

Sources