MPLS Working Group                                             S. Bryant
Internet-Draft                                 University of Surrey 5GIC
Intended status: Informational                                  J. Drake
Expires: 9 October 2022                                            T. Li
                                                        Juniper Networks
                                                            7 April 2022


       Redefining ELI considered harmful; NPL considered harmful
                    draft-li-mpls-redefining-eli-00

Abstract

   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].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 9 October 2022.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.










Bryant, et al.           Expires 9 October 2022                 [Page 1]


Internet-Draft               Redefining ELI                   April 2022


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirement Language  . . . . . . . . . . . . . . . . . .   2
   2.  On the Redefinition of ELI  . . . . . . . . . . . . . . . . .   3
     2.1.  Backward Compatiblity . . . . . . . . . . . . . . . . . .   3
       2.1.1.  Risk of Bit Reuse . . . . . . . . . . . . . . . . . .   3
       2.1.2.  Risk of additional LSEs . . . . . . . . . . . . . . .   3
       2.1.3.  Risk of Bottom of Stack (BOS) data  . . . . . . . . .   4
     2.2.  Claim 1: Faster Deployment  . . . . . . . . . . . . . . .   4
     2.3.  Claim 2: Smaller label stack  . . . . . . . . . . . . . .   5
     2.4.  Claim 3: No new hardware  . . . . . . . . . . . . . . . .   5
     2.5.  Claim 4: Save an SPL  . . . . . . . . . . . . . . . . . .   6
     2.6.  Claim 5: Consistent hashing . . . . . . . . . . . . . . .   6
     2.7.  Claim 6: Smaller label stack  . . . . . . . . . . . . . .   7
   3.  On the use of Network Programming Labels (NPL)  . . . . . . .   7
   4.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .   8
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     5.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  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].

1.1.  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.




Bryant, et al.           Expires 9 October 2022                 [Page 2]


Internet-Draft               Redefining ELI                   April 2022


2.  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.

2.1.  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.

2.1.1.  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.

2.1.2.  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.








Bryant, et al.           Expires 9 October 2022                 [Page 3]


Internet-Draft               Redefining ELI                   April 2022


2.1.3.  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.

2.2.  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.








Bryant, et al.           Expires 9 October 2022                 [Page 4]


Internet-Draft               Redefining ELI                   April 2022


   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.

2.3.  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.

2.4.  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.




Bryant, et al.           Expires 9 October 2022                 [Page 5]


Internet-Draft               Redefining ELI                   April 2022


   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.

2.5.  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.

2.6.  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.






Bryant, et al.           Expires 9 October 2022                 [Page 6]


Internet-Draft               Redefining ELI                   April 2022


   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.

2.7.  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.

3.  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.








Bryant, et al.           Expires 9 October 2022                 [Page 7]


Internet-Draft               Redefining ELI                   April 2022


4.  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.

5.  References

5.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC6790]  Kompella, K., Drake, J., Amante, S., Henderickx, W., and
              L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
              RFC 6790, DOI 10.17487/RFC6790, November 2012,
              <https://www.rfc-editor.org/info/rfc6790>.

   [I-D.bocci-mpls-miad-adi-requirements]
              Bocci, M. and S. Bryant, "Requirements for MPLS Label
              Stack Indicators and Ancillary Data", Work in Progress,
              Internet-Draft, draft-bocci-mpls-miad-adi-requirements-02,
              3 March 2022, <https://www.ietf.org/archive/id/draft-
              bocci-mpls-miad-adi-requirements-02.txt>.

5.2.  Informative References

   [I-D.jags-mpls-ext-hdr]
              Rajamanickam, J., Gandhi, R., Bhattacharya, J., Decraene,
              B., Zigler, R., Cheng, W., and L. Jalil, "MPLS Extension
              Header Encodings", Work in Progress, Internet-Draft,
              draft-jags-mpls-ext-hdr-00, 2 March 2022,
              <https://www.ietf.org/archive/id/draft-jags-mpls-ext-hdr-
              00.txt>.

   [I-D.gandhi-mpls-ioam]
              Gandhi, R., Ali, Z., Brockners, F., Wen, B., Decraene, B.,
              and V. Kozak, "MPLS Data Plane Encapsulation for In-situ



Bryant, et al.           Expires 9 October 2022                 [Page 8]


Internet-Draft               Redefining ELI                   April 2022


              OAM Data", Work in Progress, Internet-Draft, draft-gandhi-
              mpls-ioam-04, 2 March 2022,
              <https://www.ietf.org/archive/id/draft-gandhi-mpls-ioam-
              04.txt>.

   [GOTO]     Dijkstra, E. W., "Go To Statement Considered Harmful",
              DOI 10.1145/362929.362947, in Communications of The
              Association for Computing Machinery, volume 11, number 3,
              pages 147-148, 1968,
              <https://homepages.cwi.nl/~storm/teaching/reader/
              Dijkstra68.pdf>.

   [TDC]      Filsfils, C. and R. Gandhi, "Network Programming for
              Performance and Liveness Monitoring In Segment Routing
              Networks", Technical Disclosure Commons , May 2019,
              <https://www.tdcommons.org/cgi/
              viewcontent.cgi?article=3237&context=dpubs_series>.

Authors' Addresses

   Stewart Bryant
   University of Surrey 5GIC
   Email: sb@stewartbryant.com


   John Drake
   Juniper Networks
   Email: jdrake@juniper.net


   Tony Li
   Juniper Networks
   Email: tony.li@tony.li


















Bryant, et al.           Expires 9 October 2022                 [Page 9]