doc: Add RFC documents

1 files changed, 1291 insertions, 0 deletions

diff --git a/doc/rfc/rfc8012.txt b/doc/rfc/rfc8012.txt
new file mode 100644
index 0000000..158923c
--- /dev/null
+++ b/doc/rfc/rfc8012.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          N. Akiya
+Request for Comments: 8012                           Big Switch Networks
+Updates: 6790                                                 G. Swallow
+Category: Standards Track                                   C. Pignataro
+ISSN: 2070-1721                                                    Cisco
+                                                                A. Malis
+                                                     Huawei Technologies
+                                                               S. Aldrin
+                                                                  Google
+                                                           November 2016
+
+
+        Label Switched Path (LSP) and Pseudowire (PW) Ping/Trace
+             over MPLS Networks Using Entropy Labels (ELs)
+
+Abstract
+
+   Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) ping
+   and traceroute are methods used to test Equal-Cost Multipath (ECMP)
+   paths.  Ping is known as a connectivity-verification method and
+   traceroute is known as a fault-isolation method, as described in RFC
+   4379.  When an LSP is signaled using the Entropy Label (EL) described
+   in RFC 6790, the ability for LSP ping and traceroute operations to
+   discover and exercise ECMP paths is lost for scenarios where Label
+   Switching Routers (LSRs) apply different load-balancing techniques.
+   One such scenario is when some LSRs apply EL-based load balancing
+   while other LSRs apply load balancing that is not EL based (e.g.,
+   IP).  Another scenario is when an EL-based LSP is stitched with
+   another LSP that can be EL based or not EL based.
+
+   This document extends the MPLS LSP ping and traceroute multipath
+   mechanisms in RFC 6424 to allow the ability of exercising LSPs that
+   make use of the EL.  This document updates RFC 6790.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc8012.
+
+
+
+
+Akiya, et al.                Standards Track                    [Page 1]
+
+RFC 8012                  LSP Ping over Entropy            November 2016
+
+
+Copyright Notice
+
+   Copyright (c) 2016 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
+   (http://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 Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Terminology ................................................5
+           1.1.1. Requirements Language ...............................6
+      1.2. Background .................................................6
+   2. Multipath Type {9} ..............................................7
+   3. Pseudowire Tracing ..............................................7
+   4. Entropy Label FEC ...............................................8
+   5. DS Flags: L and E ...............................................9
+   6. New Multipath Information Type {10} ............................10
+   7. Initiating LSR Procedures ......................................12
+   8. Responder LSR Procedures .......................................14
+      8.1. IP-Based Load Balancer That Does Not Push ELI/EL ..........15
+      8.2. IP-Based Load Balancer That Pushes ELI/EL .................15
+      8.3. Label-Based Load Balancer That Does Not Push ELI/EL .......16
+      8.4. Label-Based Load Balancer That Pushes ELI/EL ..............17
+      8.5. Flow-Aware MS-PW Stitching LSR ............................18
+   9. Supported and Unsupported Cases ................................18
+   10. Security Considerations .......................................20
+   11. IANA Considerations ...........................................21
+      11.1. Entropy Label FEC ........................................21
+      11.2. DS Flags .................................................21
+      11.3. Multipath Type ...........................................21
+   12. References ....................................................22
+      12.1. Normative References .....................................22
+      12.2. Informative References ...................................22
+   Acknowledgements ..................................................23
+   Contributors ......................................................23
+   Authors' Addresses ................................................23
+
+
+
+
+
+
+Akiya, et al.                Standards Track                    [Page 2]
+
+RFC 8012                  LSP Ping over Entropy            November 2016
+
+
+1.  Introduction
+
+   [RFC4379] describes LSP traceroute as an operation where the
+   initiating LSR sends a series of MPLS echo requests towards the same
+   destination.  The first packet in the series has the TTL set to 1.
+   When the echo reply is received from the LSR one hop away, the second
+   echo request in the series is sent with the TTL set to 2.  For each
+   additional echo request, the TTL is incremented by one until a
+   response is received from the intended destination.  The initiating
+   LSR discovers and exercises ECMP by obtaining Multipath Information
+   from each transit LSR and using a specific destination IP address or
+   specific entropy label.
+
+   From here on, the notation {x, y, z} refers to Multipath Information
+   Types x, y, or z.  Multipath Information Types are defined in
+   Section 3.3 of [RFC4379] .
+
+   The LSR initiating LSP ping sends an MPLS echo request with the
+   Multipath Information.  This Multipath Information is described in
+   the echo request's DDMAP TLV and may contain a set of IP addresses or
+   a set of labels.  Multipath Information Types {2, 4, 8} carry a set
+   of IP addresses, and the Multipath Information Type {9} carries a set
+   of labels.  The responder LSR (the receiver of the MPLS echo request)
+   will determine the subset of initiator-specified Multipath
+   Information, which load balances to each downstream (outgoing)
+   interface.  The responder LSR sends an MPLS echo reply with the
+   resulting Multipath Information per downstream (outgoing interface)
+   back to the initiating LSR.  The initiating LSR is then able to use a
+   specific IP destination address or a specific label to exercise a
+   specific ECMP path on the responder LSR.
+
+   The current behavior is problematic in the following scenarios:
+
+   o  The initiating LSR sends the IP Multipath Information, but the
+      responder LSR load balances on labels.
+
+   o  The initiating LSR sends the Label Multipath Information, but the
+      responder LSR load balances on IP addresses.
+
+   o  The initiating LSR sends the existing Multipath Information to an
+      LSR that pushes ELI/EL in the label stack, but the initiating LSR
+      can only continue to discover and exercise specific paths of the
+      ECMP if the LSR that pushes ELI/EL responds with both IP addresses
+      and the associated EL corresponding to each IP address.  This is
+      because:
+
+      *  An ELI/EL-pushing LSR that is a stitching point will load
+         balance based on the IP address.
+
+
+
+Akiya, et al.                Standards Track                    [Page 3]
+
+RFC 8012                  LSP Ping over Entropy            November 2016
+
+
+      *  Downstream LSR(s) of an ELI/EL-pushing LSR may load balance
+         based on ELs.
+
+   o  The initiating LSR sends existing Multipath Information to an ELI/
+      EL-pushing LSR, but the initiating LSR can only continue to
+      discover and exercise specific paths of ECMP if the ELI/EL-pushing
+      LSR responds with both labels and the associated EL corresponding
+      to the label.  This is because:
+
+      *  An ELI/EL-pushing LSR that is a stitching point will load
+         balance based on the EL from the previous LSP and push a new
+         EL.
+
+      *  Downstream LSR(s) of ELI/EL-pushing LSR may load balance based
+         on new ELs.
+
+   The above scenarios demonstrate that the existing Multipath
+   Information is insufficient when LSP traceroute is used on an LSP
+   with entropy labels [RFC6790].  This document defines a new Multipath
+   Information Type to be used in the DDMAP of MPLS echo request/reply
+   packets for [RFC6790] LSPs.
+
+   The responder LSR can reply with empty Multipath Information if no IP
+   address set or if no label set is received with the Multipath
+   Information.  An empty return is also possible if an initiating LSR
+   sends Multipath Information of one type, IP Address or Label, but the
+   responder LSR load balances on the other type.  To disambiguate
+   between the two results, this document introduces new flags in the
+   DDMAP TLV to allow the responder LSR to describe the load-balancing
+   technique being used.
+
+   To use this enhanced method end-to-end, all LSRs along the LSP need
+   to be able to understand the new flags and the new Multipath
+   Information Type.  Mechanisms to verify this condition are outside of
+   the scope of this document.  The rest of the requirements are
+   detailed in the initiating LSR and responder LSR procedures.  Two
+   additional DS Flags are defined for the DDMAP TLV in Section 6.
+   These two flags are used by the responder LSR to describe its load-
+   balancing behavior on a received MPLS echo request.
+
+   Note that the terms "IP-Based Load Balancer" and "Label-Based Load
+   Balancer" are in context of how a received MPLS echo request is
+   handled by the responder LSR.
+
+
+
+
+
+
+
+
+Akiya, et al.                Standards Track                    [Page 4]
+
+RFC 8012                  LSP Ping over Entropy            November 2016
+
+
+1.1.  Terminology
+
+   The following abbreviations and terms are used in this document:
+
+   o  MPLS: Multiprotocol Label Switching.
+
+   o  LSP: Label Switched Path.
+
+   o  Stitched LSP: Stitched Label Switched Paths combine several LSPs
+      such that a single end-to-end LSP is realized.  [RFC6424]
+      describes LSP ping for Stitched LSPs.
+
+   o  LSR: Label Switching Router.
+
+   o  FEC: Forwarding Equivalence Class.
+
+   o  ECMP: Equal-Cost Multipath.
+
+   o  EL: Entropy Label.
+
+   o  ELI: Entropy Label Indicator.
+
+   o  GAL: Generic Associated Channel Label.
+
+   o  MS-PW: Multi-Segment Pseudowire.
+
+   o  Initiating LSR: An LSR that sends an MPLS echo request.
+
+   o  Responder LSR: An LSR that receives an MPLS echo request and sends
+      an MPLS echo reply.
+
+   o  IP-Based Load Balancer: An LSR that load balances on fields from
+      an IP header (and possibly fields from upper layers) and does not
+      consider an entropy label from an MPLS label stack (i.e., flow
+      label [RFC6391] or entropy label [RFC6790]) for load-balancing
+      purposes.
+
+   o  Label-Based Load Balancer: An LSR that load balances on an entropy
+      label from an MPLS label stack (i.e., flow label or entropy label)
+      and does not consider fields from an IP header (and possibly
+      fields from upper layers) for load-balancing purposes.
+
+   o  Label and IP-Based Load Balancer: An LSR that load balances on
+      both entropy labels from an MPLS label stack and fields from an IP
+      header (and possibly fields from upper layers).
+
+
+
+
+
+
+Akiya, et al.                Standards Track                    [Page 5]
+
+RFC 8012                  LSP Ping over Entropy            November 2016
+
+
+1.1.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+1.2.  Background
+
+   MPLS implementations employ a wide variety of load-balancing
+   techniques in terms of fields used for hash "keys".  The mechanisms
+   in [RFC4379] and updated by [RFC6424] are designed to provide
+   multipath support for a subset of techniques.  The intent of this
+   document is to provide multipath support for the supported techniques
+   that are compromised by the use of ELs [RFC6790].  Section 9
+   describes supported and unsupported cases, and it may be useful for
+   the reader to first review this section.
+
+   The Downstream Detailed Mapping (DDMAP) TLV [RFC6424] provides
+   Multipath Information, which can be used by an LSP ping initiator to
+   trace and validate ECMP paths between an ingress and egress.  The
+   Multipath Information encodings defined by [RFC6424] are sufficient
+   when all the LSRs along the path(s), between ingress and egress,
+   consider the same set of "keys" as input for load-balancing
+   algorithms, e.g., either all IP based or all label based.
+
+   With the introduction of [RFC6790], some LSRs may perform load
+   balancing based on labels while others may be IP based.  This results
+   in an LSP ping initiator that is unable to trace and validate all the
+   ECMP paths in the following scenarios:
+
+   o  One or more transit LSRs along an LSP with ELI/EL in the label
+      stack do not perform ECMP load balancing based on EL (hashes based
+      on "keys" including the IP destination address).  This scenario is
+      not only possible but quite common due to transit LSRs not
+      implementing [RFC6790] or transit LSRs implementing [RFC6790] but
+      not implementing the suggested transit LSR behavior in Section 4.3
+      of [RFC6790].
+
+   o  Two or more LSPs stitched together with at least one of these LSPs
+      pushing ELI/EL into the label stack.
+
+   These scenarios can be quite common because deployments of [RFC6790]
+   typically have a mixture of nodes that support ELI/EL and nodes that
+   do not.  There will also typically be a mixture of areas that support
+   ELI/EL and areas that do not.
+
+
+
+
+
+
+Akiya, et al.                Standards Track                    [Page 6]
+
+RFC 8012                  LSP Ping over Entropy            November 2016
+
+
+   As pointed out in [RFC6790], the procedures of [RFC4379] (and
+   consequently of [RFC6424]) with respect to Multipath Information Type
+   {9} are incomplete.  However, [RFC6790] does not actually update
+   [RFC4379].  Further, the specific EL location is not clearly defined,
+   particularly in the case of Flow-Aware Pseudowires [RFC6391].  This
+   document defines a new FEC Stack sub-TLV for the entropy label.
+   Section 2 of this document updates the procedures for the Multipath
+   Information Type {9} that are described in [RFC4379] and that are
+   applicable to [RFC6424].  The rest of this document describes
+   extensions required to restore ECMP discovery and tracing
+   capabilities for the scenarios described.
+
+   [RFC4379], [RFC6424], and this document will support IP-based load
+   balancers and label-based load balancers that limit their hash to the
+   first (top-most) or only entropy label in the label stack.  Other use
+   cases (refer to Section 9) are out of scope.
+
+2.  Multipath Type {9}
+
+   [RFC4379] defined Multipath Type {9} for the tracing of LSPs where
+   label-based load balancing is used.  However, as pointed out in
+   [RFC6790], the procedures for using this type are incomplete as the
+   specific location of the label was not defined.  It was assumed that
+   the presence of Multipath Type {9} implied that the value of the
+   bottom-of-stack label should be varied by the values indicated by the
+   multipath to determine the respective outgoing interfaces.
+
+   Section 4 defines a new FEC-Stack sub-TLV to indicate an entropy
+   label.  These labels MAY appear anywhere in a label stack.
+
+   Multipath Type {9} applies to the first label in the label stack that
+   corresponds to an EL-FEC.  If no such label is found, it applies to
+   the label at the bottom of the label stack.
+
+3.  Pseudowire Tracing
+
+   This section defines procedures for tracing Pseudowires.  These
+   procedures pertain to the use of Multipath Information Type {9} as
+   well as Type {10}.  In all cases below, when a control word is in
+   use, the N flag in the DDMAP MUST be set.  Note that when a control
+   word is not in use, the returned DDMAPs may not be accurate.
+
+   In order to trace a Pseudowire that is not flow aware, the initiator
+   includes an EL-FEC instead of the appropriate PW FEC at the bottom of
+   the FEC Stack.  Tracing in this way will cause compliant routers to
+   return the proper outgoing interface.  Note that this procedure only
+   traces to the end of the MPLS LSP that is under test and will not
+   verify the PW FEC.  To actually verify the PW FEC or in the case of a
+
+
+
+Akiya, et al.                Standards Track                    [Page 7]
+
+RFC 8012                  LSP Ping over Entropy            November 2016
+
+
+   MS-PW, to determine the next Pseudowire label value, the initiator
+   MUST repeat that step of the trace (i.e., repeating the TTL value
+   used) but with the FEC Stack modified to contain the appropriate PW
+   FEC.  Note that these procedures are applicable to scenarios where an
+   initiator is able to vary the bottom label (i.e., Pseudowire label).
+   Possible scenarios are tracing multiple Pseudowires that are not flow
+   aware on the same endpoints or tracing a Pseudowire that is not flow-
+   aware provisioned with multiple Pseudowire labels.
+
+   In order to trace a flow-aware Pseudowire [RFC6391], the initiator
+   includes an EL FEC at the bottom of the FEC Stack and pushes the
+   appropriate PW FEC onto the FEC Stack.
+
+   In order to trace through routers that are not compliant, the
+   initiator forms an MPLS echo request message and includes a DDMAP
+   with the Multipath Type {9}.  For a Pseudowire that is not flow
+   aware, it includes the appropriate PW FEC in the FEC Stack.  For a
+   flow- aware Pseudowire, the initiator includes a Nil FEC at the
+   bottom of the FEC Stack and pushes the appropriate PW FEC onto the
+   FEC Stack.
+
+4.  Entropy Label FEC
+
+   The ELI is a reserved label that has no associated explicit FEC, and
+   has the label value 7 assigned from the reserved range.  Use the Nil
+   FEC as the Target FEC Stack sub-TLV to account for ELI in a Target
+   FEC Stack TLV.
+
+   The EL is a special-purpose label with the label value being
+   discretionary (i.e., the label value is not from the reserved range).
+   For LSP verification mechanics to perform its purpose, it is
+   necessary for a Target FEC Stack sub-TLV to clearly describe the EL,
+   particularly in the scenario where the label stack does not carry ELI
+   (e.g., flow-aware Pseudowire [RFC6391]).  Therefore, this document
+   defines an EL FEC sub-TLV (33, see Section 11.1) that allows a Target
+   FEC Stack sub-TLV to be added to the Target FEC Stack to account for
+   EL.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Akiya, et al.                Standards Track                    [Page 8]
+
+RFC 8012                  LSP Ping over Entropy            November 2016
+
+
+   The Length is 4.  Labels are 20-bit values treated as numbers.
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                 Label                 |          MBZ          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                        Figure 1: Entropy Label FEC
+
+   "Label" is the actual label value inserted in the label stack; the
+   "MBZ" field MUST be zero when sent and ignored on receipt.
+
+5.  DS Flags: L and E
+
+   Two flags, L and E, are added to the DS Flags field of the DDMAP TLV.
+   Both flags MUST NOT be set in the echo request packets when sending
+   and SHOULD be ignored when received.  Zero, one, or both new flags
+   MUST be set in the echo reply packets.
+
+    DS Flags
+    --------
+
+        0 1 2 3 4 5 6 7
+       +-+-+-+-+-+-+-+-+
+       |  MBZ  |L|E|I|N|
+       +-+-+-+-+-+-+-+-+
+
+    Flag  Name and Meaning
+    ----  ----------------
+       L  Label-based load balance indicator
+          This flag MUST be cleared in the echo request.  An LSR
+          that performs load balancing on a label MUST set this
+          flag in the echo reply.  An LSR that performs load
+          balancing on IP MUST NOT set this flag in the echo
+          reply.
+
+       E  ELI/EL push indicator
+          This flag MUST be cleared in the echo request.  An LSR
+          that pushes ELI/EL MUST set this flag in the echo
+          reply.  An LSR that does not push ELI/EL MUST NOT set
+          this flag in the echo reply.
+
+
+
+
+
+
+
+
+
+Akiya, et al.                Standards Track                    [Page 9]
+
+RFC 8012                  LSP Ping over Entropy            November 2016
+
+
+   The two flags result in four load-balancing techniques, which the
+   echo reply generating LSR can indicate:
+
+   o  {L=0, E=0} LSR load balances based on IP and does not push ELI/EL.
+
+   o  {L=0, E=1} LSR load balances based on IP and pushes ELI/EL.
+
+   o  {L=1, E=0} LSR load balances based on labels and does not push
+      ELI/EL.
+
+   o  {L=1, E=1} LSR load balances based on labels and pushes ELI/EL.
+
+6.  New Multipath Information Type {10}
+
+   One new Multipath Information Type is added to be used in DDMAP TLV.
+   This new Multipath Type has the value of 10.
+
+     Key   Type                  Multipath Information
+     ---   ----------------      ---------------------
+     10    IP and Label set      IP addresses and label prefixes
+
+   Multipath Information Type {10} is comprised of three sections.  The
+   first section describes the IP address set.  The second section
+   describes the label set.  The third section describes another label
+   set, which associates to either the IP address set or the label set
+   specified in the other sections.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Akiya, et al.                Standards Track                   [Page 10]
+
+RFC 8012                  LSP Ping over Entropy            November 2016
+
+
+   Multipath Information Type {10} has the following format:
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |IPMultipathType|     IP Multipath Length       | Reserved(MBZ) |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   ~                                                               ~
+   |                  (IP Multipath Information)                   |
+   ~                                                               ~
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |LbMultipathType|    Label Multipath Length     | Reserved(MBZ) |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   ~                                                               ~
+   |                 (Label Multipath Information)                 |
+   ~                                                               ~
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | Assoc. Label Multipath Length |         Reserved(MBZ)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   ~                                                               ~
+   |            (Associated Label Multipath Information)           |
+   ~                                                               ~
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                 Figure 2: Multipath Information Type {10}
+
+   o  IPMultipathType
+
+      *  0 when "IP Multipath Information" is omitted.  Otherwise, one
+         of the IP Multipath Information values: {2, 4, 8}.
+
+   o  IP Multipath Information
+
+      *  This section is omitted when "IPMultipathType" is 0.
+         Otherwise, this section reuses the IP Multipath Information
+         from [RFC4379].  Specifically, Multipath Information for values
+         {2, 4, 8} can be used.
+
+   o  LbMultipathType
+
+      *  0 when the "Label Multipath Information" is omitted.
+         Otherwise, the Label Multipath Information value {9}.
+
+
+
+
+
+
+
+
+
+Akiya, et al.                Standards Track                   [Page 11]
+
+RFC 8012                  LSP Ping over Entropy            November 2016
+
+
+   o  Label Multipath Information
+
+      *  This section is omitted when the "LbMultipathType" is 0.
+         Otherwise, this section reuses the Label Multipath Information
+         from [RFC4379].  Specifically, the Multipath Information for
+         value {9} can be used.
+
+   o  Associated Label Multipath Information
+
+      *  "Associated Label Multipath Length" is a 16-bit field of
+         Multipath Information that indicates the length in octets of
+         the Associated Label Multipath Information.
+
+      *  "Associated Label Multipath Information" is a list of labels
+         with each label described in 24 bits.  This section MUST be
+         omitted in an MPLS echo request message.  A midpoint that
+         pushes ELI/EL labels SHOULD include "Associated Label Multipath
+         Information" in its MPLS echo reply message, along with either
+         "IP Multipath Information" or "Label Multipath Information".
+         Each specified associated label described in this section maps
+         to a specific IP address OR label described in the "IP
+         Multipath Information" section or the "Label Multipath
+         Information" section.  For example, if three IP addresses are
+         specified in the "IP Multipath Information" section, then there
+         MUST be three labels described in this section.  The first
+         label maps to the first IP address specified, the second label
+         maps to the second IP address specified, and the third label
+         maps to the third IP address specified.
+
+   When a section is omitted, the length for that section MUST be set to
+   zero.
+
+7.  Initiating LSR Procedures
+
+   The following procedure is described in terms of an EL_LSP boolean
+   maintained by the initiating LSR.  This value controls the Multipath
+   Information Type to be used in the transmitted echo request packets.
+   When the initiating LSR is transmitting an echo request packet with
+   DDMAP with a non-zero Multipath Information Type, then the EL_LSP
+   boolean MUST be consulted to determine the Multipath Information Type
+   to use.
+
+
+
+
+
+
+
+
+
+
+Akiya, et al.                Standards Track                   [Page 12]
+
+RFC 8012                  LSP Ping over Entropy            November 2016
+
+
+   In addition to the procedures described in [RFC4379], as updated by
+   Section 2 and [RFC6424], the initiating LSR MUST operate with the
+   following procedures:
+
+   o  When the initiating LSR pushes ELI/EL, initialize EL_LSP=True.
+      Else, set EL_LSP=False.
+
+   o  When the initiating LSR is transmitting a non-zero Multipath
+      Information Type:
+
+      *  If (EL_LSP), the initiating LSR MUST use the Multipath
+         Information Type {10} unless the responder LSR cannot handle
+         Type {10}.  When the initiating LSR is transmitting the
+         Multipath Information Type {10}, both "IP Multipath
+         Information" and "Label Multipath Information" MUST be
+         included, and "Associated Label Multipath Information" MUST be
+         omitted (NULL).
+
+      *  Else, the initiating LSR MAY use the Multipath Information Type
+         {2, 4, 8, 9, 10}.  When the initiating LSR is transmitting the
+         Multipath Information Type {10} in this case, "IP Multipath
+         Information" MUST be included, and "Label Multipath
+         Information" and "Associated Label Multipath Information" MUST
+         be omitted (NULL).
+
+   o  When the initiating LSR receives an echo reply with {L=0, E=1} in
+      the DS Flags with valid contents, set EL_LSP=True.
+
+   In the following conditions, the initiating LSR may have lost the
+   ability to exercise specific ECMP paths.  The initiating LSR MAY
+   continue with "best effort" in the following cases:
+
+   o  Received echo reply contains empty Multipath Information.
+
+   o  Received echo reply contains {L=0, E=<any>} DS Flags, but does not
+      contain IP Multipath Information.
+
+   o  Received echo reply contains {L=1, E=<any>} DS Flags, but does not
+      contain Label Multipath Information.
+
+   o  Received echo reply contains {L=<any>, E=1} DS Flags, but does not
+      contain Associated Label Multipath Information.
+
+   o  IP Multipath Information Types {2, 4, 8} sent, and received echo
+      reply with {L=1, E=0} in DS Flags.
+
+   o  Multipath Information Type {10} sent, and received echo reply with
+      Multipath Information Type other than {10}.
+
+
+
+Akiya, et al.                Standards Track                   [Page 13]
+
+RFC 8012                  LSP Ping over Entropy            November 2016
+
+
+8.  Responder LSR Procedures
+
+   Common Procedures:
+
+   o  The responder LSR receiving an MPLS echo request packet MUST first
+      determine whether or not the initiating LSR supports this LSP ping
+      and traceroute extension for entropy labels.  If either of the
+      following conditions are met, the responder LSR SHOULD determine
+      that the initiating LSR supports this LSP ping and traceroute
+      extension for entropy labels.
+
+      1.  Received MPLS echo request contains the Multipath Information
+          Type {10}.
+
+      2.  Received MPLS echo request contains a Target FEC Stack TLV
+          that includes the entropy label FEC.
+
+      If the initiating LSR is determined not to support this LSP ping
+      and traceroute extension for entropy labels, then the responder
+      LSR MUST NOT follow further procedures described in this section.
+      Specifically, MPLS echo reply packets:
+
+      *  MUST have the following DS Flags cleared (i.e., not set): "ELI/
+         EL push indicator" and "Label-based load balance indicator".
+
+      *  MUST NOT use the Multipath Information Type {10}.
+
+   o  The responder LSR receiving an MPLS echo request packet with the
+      Multipath Information Type {10} MUST validate the following
+      contents.  Any deviation MUST result in the responder LSR
+      considering the packet to be malformed and returning code 1
+      ("Malformed echo request received") in the MPLS echo reply packet.
+
+      *  IP Multipath Information MUST be included.
+
+      *  Label Multipath Information MAY be included.
+
+      *  Associated Label Multipath Information MUST be omitted (NULL).
+
+   The following subsections describe expected responder LSR procedures
+   when the echo reply is to include DDMAP TLVs, based on the local load
+   balance technique being employed.  In case the responder LSR performs
+   deviating load balance techniques on a per-downstream basis,
+   appropriate procedures matched to each downstream load balance
+   technique MUST be followed.
+
+
+
+
+
+
+Akiya, et al.                Standards Track                   [Page 14]
+
+RFC 8012                  LSP Ping over Entropy            November 2016
+
+
+8.1.  IP-Based Load Balancer That Does Not Push ELI/EL
+
+   o  The responder MUST set {L=0, E=0} in DS Flags.
+
+   o  If the Multipath Information Type {2, 4, 8} is received, the
+      responder MUST comply with [RFC4379] and [RFC6424].
+
+   o  If the Multipath Information Type {9} is received, the responder
+      MUST reply with Multipath Type {0}.
+
+   o  If the Multipath Information Type {10} is received, the following
+      procedures are to be used:
+
+      *  The responder MUST reply with the Multipath Information Type
+         {10}.
+
+      *  The "Label Multipath Information" and "Associated Label
+         Multipath Information" sections MUST be omitted (NULL).
+
+      *  If no matching IP address is found, then the "IPMultipathType"
+         field MUST be set to the Multipath Information Type {0} and the
+         "IP Multipath Information" section MUST also be omitted (NULL).
+
+      *  If at least one matching IP address is found, then the
+         "IPMultipathType" field MUST be set to the appropriate
+         Multipath Information Type {2, 4, 8} and the "IP Multipath
+         Information" section MUST be included.
+
+8.2.  IP-Based Load Balancer That Pushes ELI/EL
+
+   o  The responder MUST set {L=0, E=1} in DS Flags.
+
+   o  If the Multipath Information Type {9} is received, the responder
+      MUST reply with Multipath Type {0}.
+
+   o  If the Multipath Type {2, 4, 8, 10} is received, the following
+      procedures are to be used:
+
+      *  The responder MUST respond with Multipath Type {10}.  See
+         Section 6 for details of Multipath Type {10}.
+
+      *  The "Label Multipath Information" section MUST be omitted
+         (i.e., it is not there).
+
+      *  The IP address set specified in the received IP Multipath
+         Information MUST be used to determine the returned IP/Label
+         pairs.
+
+
+
+
+Akiya, et al.                Standards Track                   [Page 15]
+
+RFC 8012                  LSP Ping over Entropy            November 2016
+
+
+      *  If the received Multipath Information Type was {10}, the
+         received "Label Multipath Information" sections MUST NOT be
+         used to determine the associated label portion of the returned
+         IP/Label pairs.
+
+      *  If no matching IP address is found, then the "IPMultipathType"
+         field MUST be set to the Multipath Information Type {0} and the
+         "IP Multipath Information" section MUST be omitted.  In
+         addition, the "Associated Label Multipath Length" MUST be set
+         to 0, and the "Associated Label Multipath Information" section
+         MUST also be omitted.
+
+      *  If at least one matching IP address is found, then the
+         "IPMultipathType" field MUST be set to the appropriate
+         Multipath Information Type {2, 4, 8} and the "IP Multipath
+         Information" section MUST be included.  In addition, the
+         "Associated Label Multipath Information" section MUST be
+         populated with a list of labels corresponding to each IP
+         address specified in the "IP Multipath Information" section.
+         "Associated Label Multipath Length" MUST be set to a value
+         representing the length in octets of the "Associated Label
+         Multipath Information" field.
+
+8.3.  Label-Based Load Balancer That Does Not Push ELI/EL
+
+   o  The responder MUST set {L=1, E=0} in DS Flags.
+
+   o  If the Multipath Information Type {2, 4, 8} is received, the
+      responder MUST reply with Multipath Type {0}.
+
+   o  If the Multipath Information Type {9} is received, the responder
+      MUST comply with [RFC4379] and [RFC6424] as updated by Section 2.
+
+   o  If the Multipath Information Type {10} is received, the following
+      procedures are to be used:
+
+      *  The responder MUST reply with the Multipath Information Type
+         {10}.
+
+      *  The "IP Multipath Information" and "Associated Label Multipath
+         Information" sections MUST be omitted (NULL).
+
+      *  If no matching label is found, then the "LbMultipathType" field
+         MUST be set to the Multipath Information Type {0} and the
+         "Label Multipath Information" section MUST also be omitted
+         (NULL).
+
+
+
+
+
+Akiya, et al.                Standards Track                   [Page 16]
+
+RFC 8012                  LSP Ping over Entropy            November 2016
+
+
+      *  If at least one matching label is found, then the
+         "LbMultipathType" field MUST be set to the appropriate
+         Multipath Information Type {9} and the "Label Multipath
+         Information" section MUST be included.
+
+8.4.  Label-Based Load Balancer That Pushes ELI/EL
+
+   o  The responder MUST set {L=1, E=1} in DS Flags.
+
+   o  If the Multipath Information Type {2, 4, 8} is received, the
+      responder MUST reply with Multipath Type {0}.
+
+   o  If the Multipath Type {9, 10} is received, the following
+      procedures are to be used:
+
+      *  The responder MUST respond with the Multipath Type {10}.
+
+      *  The "IP Multipath Information" section MUST be omitted.
+
+      *  The label set specified in the received Label Multipath
+         Information MUST be used to determine the returned Label/Label
+         pairs.
+
+      *  If the received Multipath Information Type was {10} received,
+         the "Label Multipath Information" sections MUST NOT be used to
+         determine the associated label portion of the returned Label/
+         Label pairs.
+
+      *  If no matching label is found, then the "LbMultipathType" field
+         MUST be set to the Multipath Information Type {0} and the
+         "Label Multipath Information" section MUST be omitted.  In
+         addition, the "Associated Label Multipath Length" MUST be set
+         to 0, and the "Associated Label Multipath Information" section
+         MUST also be omitted.
+
+      *  If at least one matching label is found, then the
+         "LbMultipathType" field MUST be set to the appropriate
+         Multipath Information Type {9} and the "Label Multipath
+         Information" section MUST be included.  In addition, the
+         "Associated Label Multipath Information" section MUST be
+         populated with a list of labels corresponding to each label
+         specified in the "Label Multipath Information" section.  The
+         "Associated Label Multipath Length" MUST be set to a value
+         representing the length in octets of the "Associated Label
+         Multipath Information" field.
+
+
+
+
+
+
+Akiya, et al.                Standards Track                   [Page 17]
+
+RFC 8012                  LSP Ping over Entropy            November 2016
+
+
+8.5.  Flow-Aware MS-PW Stitching LSR
+
+   A stitching LSR that cross-connects flow-aware Pseudowires behaves in
+   one of two ways:
+
+   o  Load balances on the previous flow label and carries over the same
+      flow label.  For this case, the stitching LSR is to behave as
+      described in Section 8.3.
+
+   o  Load balances on the previous flow label and replaces the flow
+      label with a newly computed label.  For this case, the stitching
+      LSR is to behave as described in Section 8.4.
+
+9.  Supported and Unsupported Cases
+
+   The MPLS architecture does not define strict rules on how
+   implementations are to identify hash "keys" for load-balancing
+   purposes.  As a result, implementations may be of the following load
+   balancer types:
+
+   1.  IP-based load balancer.
+   2.  Label-based load balancer.
+   3.  Label- and IP-based load balancer.
+
+   For cases (2) and (3), an implementation can include different sets
+   of labels from the label stack for load-balancing purpose.  Thus, the
+   following sub-cases are possible:
+
+   a.  Entire label stack.
+   b.  Top N labels from label stack where the number of labels in label
+       stack is > N.
+   c.  Bottom N labels from label stack where the number of labels in
+       label stack is > N.
+
+   In a scenario where there is one flow label or entropy label present
+   in the label stack, the following further cases are possible for
+   (2b), (2c), (3b), and (3c):
+
+   1.  N labels from label stack include flow label or entropy label.
+   2.  N labels from label stack do not include flow label or entropy
+       label.
+
+
+
+
+
+
+
+
+
+
+Akiya, et al.                Standards Track                   [Page 18]
+
+RFC 8012                  LSP Ping over Entropy            November 2016
+
+
+   Also, in a scenario where there are multiple entropy labels present
+   in the label stack, it is possible for implementations to employ
+   deviating techniques:
+
+   o  Search for entropy stops at the first entropy label.
+
+   o  Search for entropy includes any entropy label found plus continues
+      to search for entropy in the label stack.
+
+   Furthermore, handling of reserved (i.e., special) labels varies among
+   implementations:
+
+   o  Reserved labels are used in the hash as any other label would be
+      (not a recommended practice).
+
+   o  Reserved labels are skipped over and, for implementations limited
+      to N labels, the reserved labels do not count towards the limit of
+      N.
+
+   o  Reserved labels are skipped over and, for implementations limited
+      to N labels, the reserved labels count towards the limit of N.
+
+   It is important to point this out since the presence of GAL will
+   affect those implementations that include reserved labels for load-
+   balancing purposes.
+
+   As can be seen from the above, there are many types of potential
+   load-balancing implementations.  Attempting to get any Operations,
+   Administration, and Maintenance (OAM) tools to support ECMP discovery
+   and traversal over all types would require fairly complex procedures.
+   Complexities in OAM tools have minimal benefit if the majority of
+   implementations are expected to employ only a small subset of the
+   cases described above.
+
+   o  Section 4.3 of [RFC6790] states that in implementations, for load-
+      balancing purposes, parsing beyond the label stack after finding
+      an entropy label has "limited incremental value".  Therefore, it
+      is expected that most implementations will be of types "IP-based
+      load balancer" or "Label-based load balancer".
+
+   o  Section 2.4.5.1 of [RFC7325] recommends that searching for entropy
+      labels in the label stack should terminate upon finding the first
+      entropy label.  Therefore, it is expected that implementations
+      will only include the first (top-most) entropy label when there
+      are multiple entropy labels in the label stack.
+
+
+
+
+
+
+Akiya, et al.                Standards Track                   [Page 19]
+
+RFC 8012                  LSP Ping over Entropy            November 2016
+
+
+   o  It is expected that, in most cases, the number of labels in the
+      label stack will not exceed the number of labels (N) that
+      implementations can include for load-balancing purposes.
+
+   o  It is expected that labels in the label stack, besides the flow
+      label and entropy label, are constant for the lifetime of a single
+      LSP multipath traceroute operation.  Therefore, deviating load-
+      balancing implementations with respect to reserved labels should
+      not affect this tool.
+
+   Thus, [RFC4379], [RFC6424], and this document support cases (1) and
+   (2a1), where only the first (top-most) entropy label is included when
+   there are multiple entropy labels in the label stack.
+
+10.  Security Considerations
+
+   While [RFC4379] and [RFC6424] already allow for the discovery and
+   exercise of ECMP paths, this document extends the LSP ping and
+   traceroute mechanisms to more precisely discover and exercise ECMP
+   paths when an LSP uses ELI/EL in the label stack.  Sourcing or
+   inspecting LSP ping packets can be used for network reconnaissance.
+
+   The extended capability defined in this document requires minor
+   additional processing for the responder and initiator nodes.  The
+   responder node that pushes ELI/EL will need to compute and return
+   multipath data including associated EL.  The initiator node will need
+   to store and handle both IP Multipath and Label Multipath
+   Information, and include destination IP addresses and/or ELs in MPLS
+   echo request packets as well as in the Multipath Information sent to
+   downstream nodes.  The security considerations of [RFC4379] already
+   cover Denial-of-Service attacks by regulating LSP ping traffic going
+   to the control plane.
+
+   Finally, the security measures described in [RFC4379], [RFC6424], and
+   [RFC6790] are applicable.  [RFC6424] provides guidelines if a network
+   operator wants to prevent tracing or does not want to expose details
+   of the tunnel and [RFC6790] provides guidance on the use of the EL.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Akiya, et al.                Standards Track                   [Page 20]
+
+RFC 8012                  LSP Ping over Entropy            November 2016
+
+
+11.  IANA Considerations
+
+11.1.  Entropy Label FEC
+
+   IANA has assigned a new sub-TLV from the "Sub-TLVs for TLV Types 1,
+   16, and 21" section from the "Multi-Protocol Label Switching (MPLS)
+   Label Switched Paths (LSPs) Ping Parameters" registry under "TLVs"
+   ([IANA-MPLS-LSP-PING]).
+
+    Sub-Type Sub-TLV Name          Reference
+    -------- ------------          ---------
+       33     Entropy label FEC     this document
+
+11.2.  DS Flags
+
+   IANA has assigned new bit numbers from the "DS Flags" subregistry
+   from the "TLVs" section of the "Multi-Protocol Label Switching (MPLS)
+   Label Switched Paths (LSPs) Ping Parameters" registry
+   ([IANA-MPLS-LSP-PING]).
+
+   Note: The "DS Flags" subregistry was created by [RFC7537].
+
+   Bit number Name                                        Reference
+   ---------- ----------------------------------------    ---------
+       5       E: ELI/EL push indicator                    this document
+       4       L: Label-based load balance indicator       this document
+
+11.3.  Multipath Type
+
+   IANA has assigned a new value from the "Multipath Type" subregistry
+   from the "TLVs" section of the "Multi-Protocol Label Switching (MPLS)
+   Label Switched Paths (LSPs) Ping Parameters" registry
+   ([IANA-MPLS-LSP-PING]).
+
+   Note: The "Multipath Type" subregistry was created by [RFC7537].
+
+    Value      Meaning                                  Reference
+    ---------- ---------------------------------------- ---------
+      10       IP and label set                         this document
+
+
+
+
+
+
+
+
+
+
+
+
+Akiya, et al.                Standards Track                   [Page 21]
+
+RFC 8012                  LSP Ping over Entropy            November 2016
+
+
+12.  References
+
+12.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,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC4379]  Kompella, K. and G. Swallow, "Detecting Multi-Protocol
+              Label Switched (MPLS) Data Plane Failures", RFC 4379,
+              DOI 10.17487/RFC4379, February 2006,
+              <http://www.rfc-editor.org/info/rfc4379>.
+
+   [RFC6424]  Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for
+              Performing Label Switched Path Ping (LSP Ping) over MPLS
+              Tunnels", RFC 6424, DOI 10.17487/RFC6424, November 2011,
+              <http://www.rfc-editor.org/info/rfc6424>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc6790>.
+
+   [RFC7537]  Decraene, B., Akiya, N., Pignataro, C., Andersson, L., and
+              S. Aldrin, "IANA Registries for LSP Ping Code Points",
+              RFC 7537, DOI 10.17487/RFC7537, May 2015,
+              <http://www.rfc-editor.org/info/rfc7537>.
+
+12.2.  Informative References
+
+   [IANA-MPLS-LSP-PING]
+              IANA, "Multi-Protocol Label Switching (MPLS) Label
+              Switched Paths (LSPs) Ping Parameters",
+              <http://www.iana.org/assignments/mpls-lsp-ping-parameters>.
+
+   [RFC6391]  Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V.,
+              Regan, J., and S. Amante, "Flow-Aware Transport of
+              Pseudowires over an MPLS Packet Switched Network",
+              RFC 6391, DOI 10.17487/RFC6391, November 2011,
+              <http://www.rfc-editor.org/info/rfc6391>.
+
+   [RFC7325]  Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A.,
+              and C. Pignataro, "MPLS Forwarding Compliance and
+              Performance Requirements", RFC 7325, DOI 10.17487/RFC7325,
+              August 2014, <http://www.rfc-editor.org/info/rfc7325>.
+
+
+
+
+
+Akiya, et al.                Standards Track                   [Page 22]
+
+RFC 8012                  LSP Ping over Entropy            November 2016
+
+
+Acknowledgements
+
+   The authors would like to thank Loa Andersson, Curtis Villamizar,
+   Daniel King, Sriganesh Kini, Victor Ji, Acee Lindem, Deborah
+   Brungard, Shawn M Emery, Scott O. Bradner, and Peter Yee for
+   performing thorough reviews and providing very valuable comments.
+
+   Carlos Pignataro would like to acknowledge his lifetime friend Martin
+   Rigueiro, with deep gratitude and esteem, for sharing his contagious
+   passion for engineering and sciences, and for selflessly teaching so
+   many lessons.
+
+Contributors
+
+   Nagendra Kumar
+   Cisco Systems, Inc.
+   Email: naikumar@cisco.com
+
+Authors' Addresses
+
+   Nobo Akiya
+   Big Switch Networks
+   Email: nobo.akiya.dev@gmail.com
+
+
+   George Swallow
+   Cisco Systems, Inc.
+   Email: swallow@cisco.com
+
+
+   Carlos Pignataro
+   Cisco Systems, Inc.
+   Email: cpignata@cisco.com
+
+
+   Andrew G. Malis
+   Huawei Technologies
+   Email: agmalis@gmail.com
+
+
+   Sam Aldrin
+   Google
+   Email: aldrin.ietf@gmail.com
+
+
+
+
+
+
+
+
+Akiya, et al.                Standards Track                   [Page 23]
+