Redefining ELI considered harmful; NPL considered harmful
Stewart Bryant
University of Surrey 5GIC
sb@stewartbryant.com
John Drake
Juniper Networks
jdrake@juniper.net
Tony Li
Juniper Networks
tony.li@tony.li
07 April 2022
MPLS Working Group
Recent work on MPLS Network Actions (MNA) has produced two drafts that propose to redefine the MPLS Entropy Label Indicator (ELI) for use with MNA. [I-D.jags-mpls-ext-hdr] [I-D.gandhi-mpls-ioam] This work also proposes the use of a Network Programming Label (NPL) as another option for use with MNA. This document considers both of these options harmful in the sense of [GOTO].
Introduction
Recent work on MPLS Network Actions (MNA) has produced two drafts that propose to redefine the MPLS Entropy Label Indicator (ELI) for use with MNA. [I-D.jags-mpls-ext-hdr] [I-D.gandhi-mpls-ioam] This work also proposes the use of a Network Programming Label (NPL) as another option for use with MNA. This document considers both of these options harmful in the sense of [GOTO].
Requirement Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
On the Redefinition of ELI
In [I-D.jags-mpls-ext-hdr], there are six claims of advantages to reusing ELI versus using a new Special Purpose Label (SPL) or a NPL.
Backward Compatiblity
An important consideration when contemplating the use of ELI is the question of backward compatibility. There are two risks with reuse of ELI that need to be articulated.
Risk of Bit Reuse
As part of the proposal to reuse ELI, the TC and TTL fields of the Entropy Label (EL) Label Stack Entry (LSE) will be reused to provide fields for the In-Stack Extension Header Length (IL) and Entropy Label Control fields (ELC).
[RFC6790] says the following regarding these fields:
- The TTL for the EL MUST be zero to ensure that it is not used inadvertently for forwarding. The TC for the EL may be any value.
This proposal violates the first constraint. There is a small, but not inconsequential risk that an implementation will actually check the TTL field and change its behavior if the value is non-zero.
Risk of additional LSEs
[RFC6790] defines the Entropy Label as containing two LSEs, one containing the ELI and one containing the EL.
This proposal also suggests adding additional LSEs after these two LSEs. If a legacy Label Switch Router (LSR) sees the ELI and decides to remove it from the label stack, then it will only remove the first two LSEs, leaving any additional LSEs on the label stack and effectively corrupting it, with unknown consequences.
This is a significant and unacceptable risk.
Signalling the use of the MNA label stack will avoid this problem, but it also implies that the MNA label stack will not be seen by legacy LSRs.
Risk of Bottom of Stack (BOS) data
If the MNA label stack implies that there is BOS data after the label stack, and a legacy LSR processes the packet, then it will be unaware of the BOS data and risks processing the BOS data as part of the payload.
This is another significant and unacceptable risk.
Claim 1: Faster Deployment
The first claim is that reusing the ELI will speed deployment:
- Faster deployment in an existing network that has EL already deployed with an incremental benefit (e.g., incremental signaling extension for ELI capability).
To understand this claim, consider the deployment cycle for MNA. The steps that we, as a community, must undertake are:
1. Reach rough consensus. We must determine what we will do for MNA. This will become a set of Internet drafts.
2. Develop software. We must write forwarding plane and signalling code in accordance with the above drafts. There may be some overlap between draft development and software development.
3. Testing. Software for a production network requires a significant testing effort.
4. Deployment. Even given production ready software, it must be deployed throughout a substantial portion of an operator network. To have significant field experience, multiple operators will have to do this in parallel. As software upgrades are frequently service impacting, they require scheduling maintenance windows and are not done frequently. Further, systems are typically upgraded individually, as failures from mass upgrades can lead to mass downtime.
Based on previous experience, this entire process is likely to take around three to five years, depending on operator urgency. However, the magnitude of this effort is not the issue, the claim is that using ELI would help shorten this process.
Using ELI will not help shorten the consensus process appreciably. There are many issues that need to be resolved. Using ELI will not shorten the development cycle at all. Writing code for ELI or another SPL will take the same amount of time. Similarly, there are no advantages to reusing ELI during testing.
Finally, we must consider whether using ELI can impact the deployment time scale. As noted in Section 2.1.2 and Section 2.1.3, exposing an ELI label stack with added LSEs or BOS data is not compatible with legacy LSRs. To avoid this, an operator would have to restrict their use of the MNA label stack to only functions that could be encoded without additional LSEs or BOS data. While this is not impossible, it greatly limits the functionality that can be deployed and creates an enormous operational burden on the network operator because they must enable some, but not all MNA related functionality. If they enable the wrong set of functions, their traffic will be lost. This seems very limiting and fragile.
This is an unacceptable combination of risk and burden.
Signaling cannot alleviate this. Signaling would direct traffic around legacy nodes, which would not be different than using a new SPL. As such, the reuse of the ELI does not seem to add significant benefits to shorten the deployment time cycle.
Claim 2: Smaller label stack
The second claim is that reusing the ELI will result in a smaller label stack:
- Single label for Entropy in the MPLS header which helps with keeping label stack size smaller.
If we use a new SPL to indicate a MNA label stack and entropy is one of the defined functions within the MNA label stack, then this is not true. There is no need to have both a MNA label stack and an ELI simultaneously. All proposals on the table are already taking this approach.
This claim is false.
Claim 3: No new hardware
The third claim is:
- When EL is already enabled in the network, the proposed scheme does not require hardware to support an additional SPL indicator.
This claim is either suggesting that (a) an additional SPL indicator is burdensome, or (b) that hardware is required to support a new SPL indicator, or (c) both.
If point (a) is the interpretation, then it must be noted that there are already many SPLs allocated and in use. One more is not a significant difference and this is a trivial claim.
If point (b) is the interpretation, then we must consider legacy hardware. Many implementations have used microcode to process the label stack. Adding an additional SPL is a microcode and not a hardware change. There are possibly some implementations that do process a label stack in pure hardware. These implementations would need a spin to support MNA, regardless of whether or not a new SPL is used. We must focus MNA deployment on the microcoded implementations.
Claim 3 is irrelevant.
Claim 4: Save an SPL
Claim 4 states:
- Save a new Special Purpose Label and related protocol extensions to signal its capability in LDP, RSVP-TE, BGP, IS-IS, OSPF, BGP-LS, etc.
This claim makes two sub-claims. First, reusing ELI would save us from allocating another SPL. This is true, but the risks described in Section 2.1.2 and Section 2.1.3 more than offset this small benefit.
Second, the claim is that reusing ELI would avoid making a signaling change. The development of MNA will already require that we make signaling changes. To avoid backward compatibility problems, we will end up signaling each and every function explicitly. Saving the signaling effort for a separate SPL is inconsequential in this light.
Claim 5: Consistent hashing
Claim 5 states:
- An intermediate node can compute ECMP hash with the EL field and avoid inconsistent load-balancing of traffic flow that can happen when MPLS Extension Header alters the label stack.
If we use a new SPL, this will also be true. The MNA substack will contain support for an entropy action and the ISD will contain an EL field. Transit nodes will be able to hash on this EL field.
Claim 5 is incorrect, as it not an advantage. It is exactly the same as a new SPL.
Claim 6: Smaller label stack
Claim 6 states:
- Reduce MPLS Label stack size when EL is enabled for ECMP hashing when MPLS Extension Header is also used. As there is only one field for EL in the MPLS Header, it simplifies the MPLS header processing.
Assuming our MNA solution includes EL as part of its label stack, this is always true, regardless of SPL.
Claim 6 is false.
On the use of Network Programming Labels (NPL)
NPL is not defined in an IETF document that the authors could find. An external reference [TDC] says:
- Network programming labels may be allocated from the global SR Global Block (SRGB) for SR Multiprotocol Label Switching (SR-MPLS) by a Software Defined Networking (SDN) controller.
This would seem to imply that an NPL is specific to an SR solution. However, the MNA requirements [I-D.bocci-mpls-miad-adi-requirements] section 3.1.1, requirement 12 says:
- Data plane mechanisms for ADIs MUST be independent of the control plane type (LDP, RSVP, BGP, static, IGP, etc).
This would seem to be contradictory.
If the NPL is an arbitrary label selected and and configured by the network operator, this would seem to be an undue burden on the operator. The purpose of standards is to avoid having unique items that must be managed intependently.
Conclusion
This document has shown that the use of ELI or NPL to initiate MNA processing has significant risks and limitations. While some may be willing to accept the risks on their behalf, the decisions that must be made will affect all players in the industry and must be commensurate with everyone's risk tolerance. Accordingly, reusing ELI would seem to be a poor choice and that the industry would be better served if we simply used a new SPL.

Normative References

Informative References
[GOTO]

Go To Statement Considered Harmful
Edsger W. Dijkstra
Mathematisch Centrum, Amsterdam
1968
DOI 10.1145/362929.362947
in Communications of The Association for Computing Machinery
volume 11
number 3
pages 147-148
[TDC]

Network Programming for Performance and Liveness Monitoring In Segment Routing Networks
Clarence Filsfils
Rakesh Gandhi
May 2019
Technical Disclosure Commons
[I-D.jags-mpls-ext-hdr]
[I-D.gandhi-mpls-ioam]
[RFC2119]
[RFC8174]
[RFC6790]
[I-D.bocci-mpls-miad-adi-requirements]