Internet DRAFT - draft-song-mpls-eh-indicator

draft-song-mpls-eh-indicator







MPLS                                                        H. Song, Ed.
Internet-Draft                                    Futurewei Technologies
Intended status: Informational                                     Z. Li
Expires: 1 July 2023                                             T. Zhou
                                                                  Huawei
                                                            L. Andersson
                                                Bronze Dragon Consulting
                                                        28 December 2022


              Options for MPLS Extension Header Indicator
                    draft-song-mpls-eh-indicator-06

Abstract

   This document enumerates and describes the candidate schemes that can
   be used to indicate the presence of the MPLS extension header(s)
   following the MPLS label stack.  The similar schemes are also
   applicable for indicating the potential in-stack extensions.  After a
   careful evaluation of these options by comparing their pros and cons,
   it is expected that one should be chosen as the final standard scheme
   for MPLS extension indicator.

Requirements 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 BCP
   14 [RFC2119][RFC8174] when, and only when, they appear in all
   capitals, as shown here.

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 1 July 2023.




Song, et al.               Expires 1 July 2023                  [Page 1]

Internet-Draft       MPLS Extension Header Indicator       December 2022


Copyright Notice

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

   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
   2.  Dedicated Extension Header Label  . . . . . . . . . . . . . .   3
     2.1.  Special Purpose Label . . . . . . . . . . . . . . . . . .   3
     2.2.  Extension Label plus an Extended Special Purpose Label  .   4
   3.  Generic Associated Channel Extension  . . . . . . . . . . . .   4
     3.1.  GAL and Associated Channel Header . . . . . . . . . . . .   4
     3.2.  GAL and a Different Nibble Value  . . . . . . . . . . . .   5
   4.  Extend/Re-purpose MPLS Entropy Label  . . . . . . . . . . . .   6
   5.  Configured FEC Labels . . . . . . . . . . . . . . . . . . . .   7
   6.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   7.  Considerations of EHI . . . . . . . . . . . . . . . . . . . .   9
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   10. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   9
   11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   9
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     12.1.  Normative References . . . . . . . . . . . . . . . . . .   9
     12.2.  Informative References . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   The document [I-D.song-mpls-extension-header] presents the
   motivation, specification, and use cases of MPLS Extension Header
   (EH).  An indicator is needed in the MPLS label stack to indicate the
   presence of the extension header(s).  Multiple options are possible
   for this purpose.  As the discussion progresses, more options could
   emerge.

   In this document, we propound three categories of methods which can
   be further partitioned into five unique schemes.  Four of them use
   explicit data plane encoding to indicate the EH and the last one



Song, et al.               Expires 1 July 2023                  [Page 2]

Internet-Draft       MPLS Extension Header Indicator       December 2022


   implies the EH through control plane configuration.  This document
   details and compares these schemes, in order to foster further
   discussions until a final decision is made.

   The similar schemes are also applicable for indicating the potential
   in-stack MPLS extensions which are under discussion currently.

2.  Dedicated Extension Header Label

   A straightforward method is to directly encode an Extension Header
   Label (EHL) in the MPLS label stack.  Two derived schemes are as
   follows.

2.1.  Special Purpose Label

   A new special purpose label, EHL, can be used to indicate EHs.  As
   specified in [RFC7274], so far eight special purpose label values are
   still left unsigned by IANA (which are 4 to 6 and 8 to 12).  This
   single label scheme is elegant but arguably demands a scarce
   resource.  We cannot rule out the possibility of requiring more than
   one label value to differentiate EH classes (e.g., Hop-by-Hop, End-
   to-End, or both).  If this happens, it can only aggravate the
   situation.

   Another benefit of this scheme is that an EHL can potentially be
   located anywhere in an MPLS label stack.  It is easier and quicker
   for a router to figure out the existence of extension header(s) if
   the EHL is close to or at the top of the label stack.  However, if
   there are legacy devices which can reach the EHL but do not recognize
   it in a network, then for backward compatibility, the EHL must be
   located at the bottom of the stack (i.e., only the MPLS tunnel ends
   and EHL-aware nodes will look up and process it).

   The format of an EHL is the same as an MPLS label.  The first 20-bit
   label value will be assigned by IANA.  The BoS bit is used to
   indicate the location of the label.  The other fields, CoS and TTL,
   currently have no use in the context of EHL.  However, these two
   fields can potentially be used to encode other information.  If such
   code points are open for other purpose, it will make the single EHL
   idea more compelling.  E.g., the EH category and/or other
   information, if needed, can be encoded in these fields, so that only
   one special label value is needed.

   The following figure shows a potential scheme in which one bit from
   the CoS field ('H') is used to indicate the presence of HbH EHs in
   the packet.  If 'H' bit is 0, it means no HbH EH follows so a
   P-router will not need to check the EH.  The last 8 bits can be used
   to find the location of the extension headers (i.e., the first byte



Song, et al.               Expires 1 July 2023                  [Page 3]

Internet-Draft       MPLS Extension Header Indicator       December 2022


   after the MPLS label stack).  This information can help to avoid the
   scan of the label stack in case the extension headers need to be
   accessed.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                EHL (TBD)              |H|   |S|    Offset     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 1: Special EHL with EH Category Encoding

   Note that the Cos/TTL fields can be encoded to include more
   information.  For example, in addition to indicate the EH, it can
   also indicate the presence of some other label-based services (e.g.,
   EL).  If we want to explore such possibilities, we have 11 bits in
   total at our disposal.

2.2.  Extension Label plus an Extended Special Purpose Label

   [RFC7274] specifies the Extension Label (XL) with the value of 15.
   An extended special purpose label (ESPL) following XL can be used as
   EHL.  A large number of ESPL values are available for allocation.
   The XL+EHL scheme eases the concern on the reserved label space at
   the cost of one more label in the label stack.

   Except for the fact that one more label is needed, The XL+EHL scheme
   shares the same property as the single special purpose EHL scheme.

3.  Generic Associated Channel Extension

   The similar "header extension" requirement for MPLS has led to some
   proposals before.  A special Generic Associated Channel Label (GAL)
   [RFC5586] with the value of 13 has been assigned to support the
   identification of an Associated Channel Header (ACH).  We can extend
   this existing mechanism to encode the MPLS EH indicator.

3.1.  GAL and Associated Channel Header

   The ACH is located below the bottom label.  It has a 16-bit Channel
   Type field which provides abundant space to encode the MPLS EH
   indicator.  This scheme has the same header overhead as the XL+EHL
   scheme.  The format is depicted in Figure 2.








Song, et al.               Expires 1 July 2023                  [Page 4]

Internet-Draft       MPLS Extension Header Indicator       December 2022


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                GAL (13)               | EXP |1|      TTL      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |0 0 0 1|Version|   Reserved    |  Extension Header Indicator   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                     HEH and EH(s)                             |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 2: Associated Channel Header as Extension Header Indicator

   GAL has several applications already yet its heritage also has
   several limitations.  The GAL must be located at the bottom of a
   label stack for its chief use cases such as MPLS-TP.  So a router
   needs to search the entire label stack for the BoS bit and check if
   the corresponding label is GAL.  This can impact the performance when
   the label stack is deep.  A more serious concern is that [RFC5586]
   states that GAL+ACH MUST NOT be used to transport user traffic and an
   ACH is supposed to be followed by a non-service payload.

   None of these is insurmountable but it does require an overhaul of
   the existing RFC in order to extend the usage of GAL.

3.2.  GAL and a Different Nibble Value

   To avoid changing the established semantics of ACH, a variation can
   be used.  ACH starts with a nibble value "0001".  A different nibble
   value may be used to redefine the remaining part of the word.  The
   idea has been exploited by [I-D.guichard-sfc-mpls-metadata] to define
   a Metadata Channel Header (MCH) with the leading nibble value "0000".
   Similarly, we can use another nibble value (e.g., "0010") to define a
   new header, namely the MPLS Extension Header Indicator (EHI).

   The format of the GAL and EHI is depicted in Figure 3.














Song, et al.               Expires 1 July 2023                  [Page 5]

Internet-Draft       MPLS Extension Header Indicator       December 2022


   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                GAL (13)               | EXP |1|      TTL      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |0 0 1 0|Version|   Reserved    |  Extension Header Class       |<-EHI
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  |                     HEH and EH(s)                             |
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 3: Extension Header Indicator Format

   The Extension Header Class field in EHI is used to differentiate the
   extension headers.  Potentially there are three classes: Hop-by-Hop
   (HbH), End-to-End (E2E), or both.  If finally we decide to not
   differentiate the extension headers, we have the opportunity to merge
   the HEH (see [I-D.song-mpls-extension-header] for details) into EHI,
   so we can reduce the header overhead by four bytes.  The header
   format is depicted in Figure 4.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                GAL (13)               | EXP |1|      TTL      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |0 0 1 0|     EHCNT     |       EHTLEN          |      NH       |<-HEH
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  |                           EH(s)                               |
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 4: Merge HEH to EHI

4.  Extend/Re-purpose MPLS Entropy Label

   Instead of introducing a new SPL as the EH indicator, we can
   piggyback the indicator in some existing SPL to avoid claiming extra
   SPL resource and save a label overhead.  The best candidate is the
   entropy label (EL) [RFC6790].  If we can make EL default for every
   MPLS packet, we can encode the EH indicator in the unused ELI/EL
   label fields such as CoS and TTL.







Song, et al.               Expires 1 July 2023                  [Page 6]

Internet-Draft       MPLS Extension Header Indicator       December 2022


   In Figure 5 we show a possible encoding method, in which the first
   bit of the CoS field in ELI is used to indicate the presence of EH
   and the TTL field in ELI can be used to indicate the location of the
   EH.  Note that the CoS field of the EL can also be used to encode
   other information, if necessary.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                ELI (7)                |I|   |S|    Offset     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 EL                    |     |S|       0       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


             Figure 5: Special EHL with EH Category Encoding

5.  Configured FEC Labels

   It is also possible to use FEC labels to indicate the presence of
   extension headers.  An FEC label has the same forwarding semantics as
   the original label, but it also means that one or more extension
   headers exist below the label stack.

   Although this approach avoids the need of new header encoding
   standards, it introduces a good deal of complexity into the control
   plane.  Since every label needs an FEC label to indicate EH, this
   scheme also significantly reduces the available label space.  Another
   issue is that this solution may not work for incremental deployment
   where some legacy routers cannot understand and apply the FEC labels
   for EH.  Moreover, this configuration-based solution certainly makes
   the cross-domain interoperability more difficult.  Hence, this is the
   least preferred option.  We only include it here for the completeness
   of the discussion.

6.  Summary

   Evidenced by the existing and emerging use cases, MPLS networks need
   a standard way to support extension headers.  In Figure 6, we
   summarize the potential schemes that allow MPLS packets to carry
   extension headers and list the main pros and cons for each scheme.










Song, et al.               Expires 1 July 2023                  [Page 7]

Internet-Draft       MPLS Extension Header Indicator       December 2022


     +---+---------------------------+---------------------------------+
     |No.|    Description            |       Pros and Cons             |
     +---+---------------------------+---------------------------------+
     | 1 | Special purpose EHL       |+ Single label                   |
     |   |                           |+ Location freedom               |
     |   |                           |- Need standard extension        |
     |   |                           |- Use scarce resource            |
     +---+---------------------------+---------------------------------+
     | 2 | XL(15) + EHL              |+ Location freedom               |
     |   |                           |+ Established mechanism          |
     |   |                           |+ Abundant resource              |
     |   |                           |- One extra label than Option 1  |
     |   |                           |- Need standard extension        |
     +---+---------------------------+---------------------------------+
     | 3 | GAL + ACH with channel    |+ Reuse existing mechanism       |
     |   | type extension            |+ Abundant resource              |
     |   |                           |- Label location limitation      |
     |   |                           |- One more word than Option 1    |
     |   |                           |- Not for user traffic           |
     |   |                           |- Need standard extension/update |
     +---+---------------------------+---------------------------------+
     | 4 | GAL + another nibble value|+ No change to ACH semantics     |
     |   | to indicate EHs (e.g.,    |+ Potential overhead saving      |
     |   | "0010")                   |- Label location limitation      |
     |   |                           |- Hack scarce resource (nibble)  |
     |   |                           |- Need standard extension        |
     +---+---------------------------+---------------------------------+
     | 5 | Extend ELI/EL             |+ No need for new label          |
     |   |                           |- Need standard update           |
     |   |                           |- Need to make EL mandatory      |
     |   |                           |- One extra label than Option 1  |
     +---+---------------------------+---------------------------------+
     | 6 | FEC label as EH indicator |+ No need for header standard    |
     |   |                           |- Complex control plane          |
     |   |                           |- Cross-domain interoperability  |
     |   |                           |- Label space issue              |
     |   |                           |- Not for incremental deployment |
     +---+---------------------------+---------------------------------+

          Figure 6: Potential Schemes for MPLS Extension Headers

   Basically we have three groups of solutions.  The scheme 1 and 2
   introduce new labels, the scheme 3, 4, and 5 extend the existing
   solutions, and the scheme 6 relies on the control plane.  Through
   comprehensive considerations on the pros and cons of each scheme, we
   expect a working group consensus can be reached to pick the final
   winner.




Song, et al.               Expires 1 July 2023                  [Page 8]

Internet-Draft       MPLS Extension Header Indicator       December 2022


7.  Considerations of EHI

   The existence of Extension Headers will make the ECMP based on inner
   IP packet header impossible or harder.  If legacy routers need to
   conduct this kind of ECMP, the process either fails or generates
   unexpected results.  EH-aware routers can do this kind of ECMP but
   they need to skip all the EHs in order to access the inner packet
   header which may not be efficient (we make provision in HEH to help
   accelerate this process).  In this case, the Entropy Label (EL) is
   preferred for ECMP.  The Entropy Label Indicator (ELI) and EL should
   be put in front of the EHI to avoid confusing the legacy routers.

8.  Security Considerations

   TBD

9.  IANA Considerations

   If the EHL approach is adopted to indicate the presence of MPLS
   extension header(s), this document requests IANA to assign one or
   more new Special-Purpose MPLS Label Values from the Special-Purpose
   Multiprotocol Label Switching (MPLS) Label Values Registry of
   "Extension Header Label (EHL)".

10.  Contributors

   The other contributors of this document are listed as follows.

   *  James Guichard

   *  Stewart Bryant

   *  Bruno Decraene

11.  Acknowledgments

12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S. and RFC Publisher, "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>.







Song, et al.               Expires 1 July 2023                  [Page 9]

Internet-Draft       MPLS Extension Header Indicator       December 2022


   [RFC5586]  Bocci, M., Ed., Vigoureux, M., Ed., Bryant, S., Ed., and
              RFC Publisher, "MPLS Generic Associated Channel",
              RFC 5586, DOI 10.17487/RFC5586, June 2009,
              <https://www.rfc-editor.org/info/rfc5586>.

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

   [RFC7274]  Kompella, K., Andersson, L., Farrel, A., and RFC
              Publisher, "Allocating and Retiring Special-Purpose MPLS
              Labels", RFC 7274, DOI 10.17487/RFC7274, June 2014,
              <https://www.rfc-editor.org/info/rfc7274>.

   [RFC8174]  Leiba, B. and RFC Publisher, "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>.

12.2.  Informative References

   [I-D.guichard-sfc-mpls-metadata]
              Guichard, J., Pignataro, C., Spraggs, S., and S. Bryant,
              "Carrying Metadata in MPLS Networks", Work in Progress,
              Internet-Draft, draft-guichard-sfc-mpls-metadata-00, 27
              September 2013, <https://www.ietf.org/archive/id/draft-
              guichard-sfc-mpls-metadata-00.txt>.

   [I-D.song-mpls-extension-header]
              Song, H., Zhou, T., Andersson, L., Zhang, Z. J., and R.
              Gandhi, "MPLS Network Actions using Post-Stack Extension
              Headers", Work in Progress, Internet-Draft, draft-song-
              mpls-extension-header-11, 15 October 2022,
              <https://www.ietf.org/archive/id/draft-song-mpls-
              extension-header-11.txt>.

Authors' Addresses

   Haoyu Song (editor)
   Futurewei Technologies
   2330 Central Expressway
   Santa Clara,
   United States of America
   Email: haoyu.song@futurewei.com






Song, et al.               Expires 1 July 2023                 [Page 10]

Internet-Draft       MPLS Extension Header Indicator       December 2022


   Zhenbin Li
   Huawei
   156 Beiqing Road
   Beijing, 100095
   P.R. China
   Email: lizhenbin@huawei.com


   Tianran Zhou
   Huawei
   156 Beiqing Road
   Beijing, 100095
   P.R. China
   Email: zhoutianran@huawei.com


   Loa Andersson
   Bronze Dragon Consulting
   Stockholm
   Sweden
   Email: loa@pi.nu






























Song, et al.               Expires 1 July 2023                 [Page 11]