Summary

  • RFC 6790 lets an ingress LSR choose suitable packet fields, calculate a flow-oriented hash, and place the resulting entropy in the MPLS label stack.
  • The EL is not a forwarding label and is not signaled. Reserved label 7, the Entropy Label Indicator (ELI), must immediately precede it; inserting the pair increases stack depth by two.
  • An egress advertises capability for a tunnel, but the ingress decides whether to insert ELI and EL. A capable egress must accept packets with or without the pair.
  • Per-flow consistency matters: moving one flow between paths can produce jitter, latency variation and packet reordering.

The operational mechanism is deliberately narrow. The ingress controls the flow-key selection and the decision to impose ELI plus EL once capability is known. A transit LSR still owns its local ECMP or LAG decision. It may use the exposed entropy while retaining the ordinary forwarding topology. The EL value is not used to forward a packet, is not a route advertisement, and is not permission to establish a path, create an LSP or change routing policy. It must also not use a value from reserved labels 0 through 15; ELI value 7 is the marker that identifies the following value as entropy.

The design trades two additional stack entries for avoiding expanded per-FEC control-plane and forwarding state. That trade is useful only where the receiving and transit implementations can interpret the construction and where stack-depth, compatibility, OAM and troubleshooting consequences are acceptable. Capability signaling permits use of the encoding for the tunnel; it does not turn the entropy value into authority. The egress behavior is intentionally tolerant because packets may arrive with or without ELI and EL.

RFC 7447 changes an older signaling assumption. It deprecates the BGP Entropy Label Capability Attribute because an optional transitive attribute could cross a router that did not understand the consequence of a next-hop change and could then be relied upon incorrectly. The deprecated BGP ELCA must not be presented as the current signaling mechanism.

RFC 8012 adds entropy-aware LSP ping and traceroute procedures. Ordinary multipath information can be insufficient when some nodes balance on entropy labels and others balance on IP addresses or other labels. The enhanced procedures supply entropy-related multipath information and flags for exercising ECMP paths, but RFC 8012 leaves verification of end-to-end support for that enhanced method outside its scope. An EL-aware trace therefore does not prove that every node supports the method or that all traffic takes every measured path.

The counterfactual is limited. Without entropy labels, a transit node may hash coarse MPLS labels, inspect deeper headers when feasible, or use another load-balancing method. Those alternatives have different distribution, complexity and ordering risks; none delegates route authority to the label value. Nor does a well-distributed entropy value prove that routing policy, capacity planning or failure recovery is correct. The RFCs establish no universal deployment prevalence, utilization gain, incident-reduction rate, hash algorithm, flow-key set, operational threshold or rollout sequence.

Sources