doc: Add RFC documents

1 files changed, 1581 insertions, 0 deletions

diff --git a/doc/rfc/rfc8660.txt b/doc/rfc/rfc8660.txt
new file mode 100644
index 0000000..0418d29
--- /dev/null
+++ b/doc/rfc/rfc8660.txt
@@ -0,0 +1,1581 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                  A. Bashandy, Ed.
+Request for Comments: 8660                                        Arrcus
+Category: Standards Track                               C. Filsfils, Ed.
+ISSN: 2070-1721                                               S. Previdi
+                                                     Cisco Systems, Inc.
+                                                             B. Decraene
+                                                            S. Litkowski
+                                                                  Orange
+                                                               R. Shakir
+                                                                  Google
+                                                           December 2019
+
+
+                Segment Routing with the MPLS Data Plane
+
+Abstract
+
+   Segment Routing (SR) leverages the source-routing paradigm.  A node
+   steers a packet through a controlled set of instructions, called
+   segments, by prepending the packet with an SR header.  In the MPLS
+   data plane, the SR header is instantiated through a label stack.
+   This document specifies the forwarding behavior to allow
+   instantiating SR over the MPLS data plane (SR-MPLS).
+
+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
+   https://www.rfc-editor.org/info/rfc8660.
+
+Copyright Notice
+
+   Copyright (c) 2019 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 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
+     1.1.  Requirements Language
+   2.  MPLS Instantiation of Segment Routing
+     2.1.  Multiple Forwarding Behaviors for the Same Prefix
+     2.2.  SID Representation in the MPLS Forwarding Plane
+     2.3.  Segment Routing Global Block and Local Block
+     2.4.  Mapping a SID Index to an MPLS Label
+     2.5.  Incoming Label Collision
+       2.5.1.  Tiebreaking Rules
+       2.5.2.  Redistribution between Routing Protocol Instances
+     2.6.  Effect of Incoming Label Collision on Outgoing Label
+            Programming
+     2.7.  PUSH, CONTINUE, and NEXT
+       2.7.1.  PUSH
+       2.7.2.  CONTINUE
+       2.7.3.  NEXT
+     2.8.  MPLS Label Downloaded to the FIB for Global and Local SIDs
+     2.9.  Active Segment
+     2.10. Forwarding Behavior for Global SIDs
+       2.10.1.  Forwarding for PUSH and CONTINUE of Global SIDs
+       2.10.2.  Forwarding for the NEXT Operation for Global SIDs
+     2.11. Forwarding Behavior for Local SIDs
+       2.11.1.  Forwarding for the PUSH Operation on Local SIDs
+       2.11.2.  Forwarding for the CONTINUE Operation for Local SIDs
+       2.11.3.  Outgoing Label for the NEXT Operation for Local SIDs
+   3.  IANA Considerations
+   4.  Manageability Considerations
+   5.  Security Considerations
+   6.  References
+     6.1.  Normative References
+     6.2.  Informative References
+   Appendix A.  Examples
+     A.1.  IGP Segment Examples
+     A.2.  Incoming Label Collision Examples
+       A.2.1.  Example 1
+       A.2.2.  Example 2
+       A.2.3.  Example 3
+       A.2.4.  Example 4
+       A.2.5.  Example 5
+       A.2.6.  Example 6
+       A.2.7.  Example 7
+       A.2.8.  Example 8
+       A.2.9.  Example 9
+       A.2.10. Example 10
+       A.2.11. Example 11
+       A.2.12. Example 12
+       A.2.13. Example 13
+       A.2.14. Example 14
+     A.3.  Examples for the Effect of Incoming Label Collision on an
+           Outgoing Label
+       A.3.1.  Example 1
+       A.3.2.  Example 2
+   Acknowledgements
+   Contributors
+   Authors' Addresses
+
+1.  Introduction
+
+   The Segment Routing architecture [RFC8402] can be directly applied to
+   the MPLS architecture with no change in the MPLS forwarding plane.
+   This document specifies forwarding-plane behavior to allow Segment
+   Routing to operate on top of the MPLS data plane (SR-MPLS).  This
+   document does not address control-plane behavior.  Control-plane
+   behavior is specified in other documents such as [RFC8665],
+   [RFC8666], and [RFC8667].
+
+   The Segment Routing problem statement is described in [RFC7855].
+
+   Coexistence of SR over the MPLS forwarding plane with LDP [RFC5036]
+   is specified in [RFC8661].
+
+   Policy routing and traffic engineering using Segment Routing can be
+   found in [ROUTING-POLICY].
+
+1.1.  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.
+
+2.  MPLS Instantiation of Segment Routing
+
+   MPLS instantiation of Segment Routing fits in the MPLS architecture
+   as defined in [RFC3031] from both a control-plane and forwarding-
+   plane perspective:
+
+   *  From a control-plane perspective, [RFC3031] does not mandate a
+      single signaling protocol.  Segment Routing makes use of various
+      control-plane protocols such as link-state IGPs [RFC8665]
+      [RFC8666] [RFC8667].  The flooding mechanisms of link-state IGPs
+      fit very well with label stacking on the ingress.  A future
+      control-layer protocol and/or policy/configuration can be used to
+      specify the label stack.
+
+   *  From a forwarding-plane perspective, Segment Routing does not
+      require any change to the forwarding plane because Segment IDs
+      (SIDs) are instantiated as MPLS labels, and the Segment Routing
+      header is instantiated as a stack of MPLS labels.
+
+   We call the "MPLS Control Plane Client (MCC)" any control-plane
+   entity installing forwarding entries in the MPLS data plane.  Local
+   configuration and policies applied on a router are examples of MCCs.
+
+   In order to have a node segment reach the node, a network operator
+   SHOULD configure at least one node segment per routing instance,
+   topology, or algorithm.  Otherwise, the node is not reachable within
+   the routing instance, within the topology, or along the routing
+   algorithm, which restricts its ability to be used by an SR Policy and
+   as a Topology Independent Loop-Free Alternate (TI-LFA).
+
+2.1.  Multiple Forwarding Behaviors for the Same Prefix
+
+   The SR architecture does not prohibit having more than one SID for
+   the same prefix.  In fact, by allowing multiple SIDs for the same
+   prefix, it is possible to have different forwarding behaviors (such
+   as different paths, different ECMP and Unequal-Cost Multipath (UCMP)
+   behaviors, etc.) for the same destination.
+
+   Instantiating Segment Routing over the MPLS forwarding plane fits
+   seamlessly with this principle.  An operator may assign multiple MPLS
+   labels or indices to the same prefix and assign different forwarding
+   behaviors to each label/SID.  The MCC in the network downloads
+   different MPLS labels/SIDs to the FIB for different forwarding
+   behaviors.  The MCC at the entry of an SR domain or at any point in
+   the domain can choose to apply a particular forwarding behavior to a
+   particular packet by applying the PUSH action to that packet using
+   the corresponding SID.
+
+2.2.  SID Representation in the MPLS Forwarding Plane
+
+   When instantiating SR over the MPLS forwarding plane, a SID is
+   represented by an MPLS label or an index [RFC8402].
+
+   A global SID is a label, or an index that may be mapped to an MPLS
+   label within the Segment Routing Global Block (SRGB), of the node
+   that installs a global SID in its FIB and receives the labeled
+   packet.  Section 2.4 specifies the procedure to map a global segment
+   represented by an index to an MPLS label within the SRGB.
+
+   The MCC MUST ensure that any label value corresponding to any SID it
+   installs in the forwarding plane follows the rules below:
+
+   *  The label value MUST be unique within the router on which the MCC
+      is running, i.e., the label MUST only be used to represent the SID
+      and MUST NOT be used to represent more than one SID or for any
+      other forwarding purpose on the router.
+
+   *  The label value MUST NOT come from the range of special-purpose
+      labels [RFC7274].
+
+   Labels allocated in this document are considered per-platform
+   downstream allocated labels [RFC3031].
+
+2.3.  Segment Routing Global Block and Local Block
+
+   The concepts of SRGB and global SID are explained in [RFC8402].  In
+   general, the SRGB need not be a contiguous range of labels.
+
+   For the rest of this document, the SRGB is specified by the list of
+   MPLS label ranges [Ll(1),Lh(1)], [Ll(2),Lh(2)],..., [Ll(k),Lh(k)]
+   where Ll(i) =< Lh(i).
+
+   The following rules apply to the list of MPLS ranges representing the
+   SRGB:
+
+   *  The list of ranges comprising the SRGB MUST NOT overlap.
+
+   *  Every range in the list of ranges specifying the SRGB MUST NOT
+      cover or overlap with a reserved label value or range [RFC7274],
+      respectively.
+
+   *  If the SRGB of a node does not conform to the structure specified
+      in this section or to the previous two rules, the SRGB MUST be
+      completely ignored by all routers in the routing domain, and the
+      node MUST be treated as if it does not have an SRGB.
+
+   *  The list of label ranges MUST only be used to instantiate global
+      SIDs into the MPLS forwarding plane.
+
+   A local segment MAY be allocated from the Segment Routing Local Block
+   (SRLB) [RFC8402] or from any unused label as long as it does not use
+   a special-purpose label.  The SRLB consists of the range of local
+   labels reserved by the node for certain local segments.  In a
+   controller-driven network, some controllers or applications MAY use
+   the control plane to discover the available set of Local SIDs on a
+   particular router [ROUTING-POLICY].  The rules applicable to the SRGB
+   are also applicable to the SRLB, except the SRGB MUST only be used to
+   instantiate global SIDs into the MPLS forwarding plane.  The
+   recommended, minimum, or maximum size of the SRGB and/or SRLB is a
+   matter of future study.
+
+2.4.  Mapping a SID Index to an MPLS Label
+
+   This subsection specifies how the MPLS label value is calculated
+   given the index of a SID.  The value of the index is determined by an
+   MCC such as IS-IS [RFC8667] or OSPF [RFC8665].  This section only
+   specifies how to map the index to an MPLS label.  The calculated MPLS
+   label is downloaded to the FIB, sent out with a forwarded packet, or
+   both.
+
+   Consider a SID represented by the index "I".  Consider an SRGB as
+   specified in Section 2.3.  The total size of the SRGB, represented by
+   the variable "Size", is calculated according to the formula:
+
+   size = Lh(1)- Ll(1) + 1 + Lh(2)- Ll(2) + 1 + ... + Lh(k)- Ll(k) + 1
+
+   The following rules MUST be applied by the MCC when calculating the
+   MPLS label value corresponding to the SID index value "I".
+
+      0 =< I < size.  If index "I" does not satisfy the previous
+      inequality, then the label cannot be calculated.
+
+      The label value corresponding to the SID index "I" is calculated
+      as follows:
+
+         j = 1 , temp = 0
+
+         While temp + Lh(j)- Ll(j) < I
+
+            temp = temp + Lh(j)- Ll(j) + 1
+
+            j = j+1
+
+         label = I - temp + Ll(j)
+
+   An example for how a router calculates labels and forwards traffic
+   based on the procedure described in this section can be found in
+   Appendix A.1.
+
+2.5.  Incoming Label Collision
+
+   The MPLS Architecture [RFC3031] defines the term Forwarding
+   Equivalence Class (FEC) as the set of packets with similar and/or
+   identical characteristics that are forwarded the same way and are
+   bound to the same MPLS incoming (local) label.  In Segment Routing
+   MPLS, a local label serves as the SID for a given FEC.
+
+   We define SR FEC [RFC8402] as one of the following:
+
+   *  (Prefix, Routing Instance, Topology, Algorithm) [RFC8402], where a
+      topology identifies a set of links with metrics.  For the purpose
+      of incoming label collision resolution, the same Topology
+      numerical value SHOULD be used on all routers to identify the same
+      set of links with metrics.  For MCCs where the "Topology" and/or
+      "Algorithm" fields are not defined, the numerical value of zero
+      MUST be used for these two fields.  For the purpose of incoming
+      label collision resolution, a routing instance is identified by a
+      single incoming label downloader to the FIB.  Two MCCs running on
+      the same router are considered different routing instances if the
+      only way the two instances know about each other's incoming labels
+      is through redistribution.  The numerical value used to identify a
+      routing instance MAY be derived from other configuration or MAY be
+      explicitly configured.  If it is derived from other configuration,
+      then the same numerical value SHOULD be derived from the same
+      configuration as long as the configuration survives router reload.
+      If the derived numerical value varies for the same configuration,
+      then an implementation SHOULD make the numerical value used to
+      identify a routing instance configurable.
+
+   *  (next hop, outgoing interface), where the outgoing interface is
+      physical or virtual.
+
+   *  (number of adjacencies, list of next hops, list of outgoing
+      interfaces IDs in ascending numerical order).  This FEC represents
+      parallel adjacencies [RFC8402].
+
+   *  (Endpoint, Color).  This FEC represents an SR Policy [RFC8402].
+
+   *  (Mirror SID).  The Mirror SID (see [RFC8402], Section 5.1) is the
+      IP address advertised by the advertising node to identify the
+      Mirror SID.  The IP address is encoded as specified in
+      Section 2.5.1.
+
+   This section covers the RECOMMENDED procedure for handling the
+   scenario where, because of an error/misconfiguration, more than one
+   SR FEC as defined in this section maps to the same incoming MPLS
+   label.  Examples illustrating the behavior specified in this section
+   can be found in Appendix A.2.
+
+   An incoming label collision occurs if the SIDs of the set of FECs
+   {FEC1, FEC2, ..., FECk} map to the same incoming SR MPLS label "L1".
+
+   Suppose an anycast prefix is advertised with a Prefix-SID by some,
+   but not all, of the nodes that advertise that prefix.  If the Prefix-
+   SID sub-TLVs result in mapping that anycast prefix to the same
+   incoming label, then the advertisement of the Prefix-SID by some, but
+   not all, of the advertising nodes MUST NOT be treated as a label
+   collision.
+
+   An implementation MUST NOT allow the MCCs belonging to the same
+   router to assign the same incoming label to more than one SR FEC.
+
+   The objective of the following steps is to deterministically install
+   in the MPLS Incoming Label Map, also known as label FIB, a single FEC
+   with the incoming label "L1".  By "deterministically install", we
+   mean if the set of FECs {FEC1, FEC2,..., FECk} map to the same
+   incoming SR MPLS label "L1", then the steps below assign the same FEC
+   to the label "L1" irrespective of the order by which the mappings of
+   this set of FECs to the label "L1" are received.  For example, first-
+   come, first-served tiebreaking is not allowed.  The remaining FECs
+   may be installed in the IP FIB without an incoming label.
+
+   The procedure in this section relies completely on the local FEC and
+   label database within a given router.
+
+   The collision resolution procedure is as follows:
+
+   1.  Given the SIDs of the set of FECs, {FEC1, FEC2,..., FECk} map to
+       the same MPLS label "L1".
+
+   2.  Within an MCC, apply tiebreaking rules to select one FEC only,
+       and assign the label to it.  The losing FECs are handled as if no
+       labels are attached to them.  The losing FECs with algorithms
+       other than the shortest path first [RFC8402] are not installed in
+       the FIB.
+
+       a.  If the same set of FECs are attached to the same label "L1",
+           then the tiebreaking rules MUST always select the same FEC
+           irrespective of the order in which the FECs and the label
+           "L1" are received.  In other words, the tiebreaking rule MUST
+           be deterministic.
+
+   3.  If there is still collision between the FECs belonging to
+       different MCCs, then reapply the tiebreaking rules to the
+       remaining FECs to select one FEC only, and assign the label to
+       that FEC.
+
+   4.  Install the selected FEC into the IP FIB and its incoming label
+       into the label FIB.
+
+   5.  The remaining FECs with the default algorithm (see the Prefix-SID
+       algorithm specification [RFC8402]) may be installed in the FIB
+       natively, such as pure IP entries in case of Prefix FEC, without
+       any incoming labels corresponding to their SIDs.  The remaining
+       FECs with algorithms other than the shortest path first [RFC8402]
+       are not installed in the FIB.
+
+2.5.1.  Tiebreaking Rules
+
+   The default tiebreaking rules are specified as follows:
+
+   1.  Determine the lowest administrative distance among the competing
+       FECs as defined in the section below.  Then filter away all the
+       competing FECs with a higher administrative distance.
+
+   2.  If more than one competing FEC remains after step 1, select the
+       smallest numerical FEC value.  The numerical value of the FEC is
+       determined according to the FEC encoding described later in this
+       section.
+
+   These rules deterministically select which FEC to install in the MPLS
+   forwarding plane for the given incoming label.
+
+   This document defines the default tiebreaking rules that SHOULD be
+   implemented.  An implementation MAY choose to support different
+   tiebreaking rules and MAY use one of these instead of the default
+   tiebreaking rules.  To maximize MPLS forwarding consistency in case
+   of a SID configuration error, the network operator MUST deploy,
+   within an IGP flooding area, routers implementing the same
+   tiebreaking rules.
+
+   Each FEC is assigned an administrative distance.  The FEC
+   administrative distance is encoded as an 8-bit value.  The lower the
+   value, the better the administrative distance.
+
+   The default FEC administrative distance order starting from the
+   lowest value SHOULD be:
+
+   *  Explicit SID assignment to a FEC that maps to a label outside the
+      SRGB irrespective of the owner MCC.  An explicit SID assignment is
+      a static assignment of a label to a FEC such that the assignment
+      survives a router reboot.
+
+      -  An example of explicit SID allocation is static assignment of a
+         specific label to an Adj-SID.
+
+      -  An implementation of explicit SID assignment MUST guarantee
+         collision freeness on the same router.
+
+   *  Dynamic SID assignment:
+
+      -  All FEC types, except for the SR Policy, are ordered using the
+         default administrative distance defined by the implementation.
+
+      -  The Binding SID [RFC8402] assigned to the SR Policy always has
+         a higher default administrative distance than the default
+         administrative distance of any other FEC type.
+
+   To maximize MPLS forwarding consistency, if the same FEC is
+   advertised in more than one protocol, a user MUST ensure that the
+   administrative distance preference between protocols is the same on
+   all routers of the IGP flooding domain.  Note that this is not really
+   new as this already applies to IP forwarding.
+
+   The numerical sort across FECs SHOULD be performed as follows:
+
+   *  Each FEC is assigned a FEC type encoded in 8 bits.  The type
+      codepoints for each SR FEC defined at the beginning of this
+      section are as follows:
+
+         120:  (Prefix, Routing Instance, Topology, Algorithm)
+
+         130:  (next hop, outgoing interface)
+
+         140:  Parallel Adjacency [RFC8402]
+
+         150:  SR Policy [RFC8402]
+
+         160:  Mirror SID [RFC8402]
+
+      The numerical values above are mentioned to guide implementation.
+      If other numerical values are used, then the numerical values must
+      maintain the same greater-than ordering of the numbers mentioned
+      here.
+
+   *  The fields of each FEC are encoded as follows:
+
+      -  All fields in all FECs are encoded in big endian order.
+
+      -  The Routing Instance ID is represented by 16 bits.  For routing
+         instances that are identified by less than 16 bits, encode the
+         Instance ID in the least significant bits while the most
+         significant bits are set to zero.
+
+      -  The address family is represented by 8 bits, where IPv4 is
+         encoded as 100, and IPv6 is encoded as 110.  These numerical
+         values are mentioned to guide implementations.  If other
+         numerical values are used, then the numerical value of IPv4
+         MUST be less than the numerical value for IPv6.
+
+      -  All addresses are represented in 128 bits as follows:
+
+         o  The IPv6 address is encoded natively.
+
+         o  The IPv4 address is encoded in the most significant bits,
+            and the remaining bits are set to zero.
+
+      -  All prefixes are represented by (8 + 128) bits.
+
+         o  A prefix is encoded in the most significant bits, and the
+            remaining bits are set to zero.
+
+         o  The prefix length is encoded before the prefix in an 8-bit
+            field.
+
+      -  The Topology ID is represented by 16 bits.  For routing
+         instances that identify topologies using less than 16 bits,
+         encode the topology ID in the least significant bits while the
+         most significant bits are set to zero.
+
+      -  The Algorithm is encoded in a 16-bit field.
+
+      -  The Color ID is encoded using 32 bits.
+
+   *  Choose the set of FECs of the smallest FEC type codepoint.
+
+   *  Out of these FECs, choose the FECs with the smallest address
+      family codepoint.
+
+   *  Encode the remaining set of FECs as follows:
+
+      -  (Prefix, Routing Instance, Topology, Algorithm) is encoded as
+         (Prefix Length, Prefix, routing_instance_id, Topology, SR
+         Algorithm).
+
+      -  (next hop, outgoing interface) is encoded as (next hop,
+         outgoing_interface_id).
+
+      -  (number of adjacencies, list of next hops in ascending
+         numerical order, list of outgoing interface IDs in ascending
+         numerical order) is used to encode a parallel adjacency
+         [RFC8402].
+
+      -  (Endpoint, Color) is encoded as (Endpoint_address, Color_id).
+
+      -  (IP address) is the encoding for a Mirror SID FEC.  The IP
+         address is encoded as described above in this section.
+
+   *  Select the FEC with the smallest numerical value.
+
+   The numerical values mentioned in this section are for guidance only.
+   If other numerical values are used, then the other numerical values
+   MUST maintain the same numerical ordering among different SR FECs.
+
+2.5.2.  Redistribution between Routing Protocol Instances
+
+   The following rule SHOULD be applied when redistributing SIDs with
+   prefixes between routing protocol instances:
+
+   *  If the SRGB of the receiving instance is the same as the SRGB of
+      the origin instance, then:
+
+      -  the index is redistributed with the route.
+
+   *  Else,
+
+      -  the index is not redistributed and if the receiving instance
+         decides to advertise an index with the redistributed route, it
+         is the duty of the receiving instance to allocate a fresh index
+         relative to its own SRGB.  Note that in this case, the
+         receiving instance MUST compute the local label it assigns to
+         the route according to Section 2.4 and install it in FIB.
+
+   It is outside the scope of this document to define local node
+   behaviors that would allow the mapping of the original index into a
+   new index in the receiving instance via the addition of an offset or
+   other policy means.
+
+2.5.2.1.  Illustration
+
+           A----IS-IS----B---OSPF----C-192.0.2.1/32 (20001)
+
+   Consider the simple topology above, where:
+
+   *  A and B are in the IS-IS domain with SRGB = [16000-17000]
+
+   *  B and C are in the OSPF domain with SRGB = [20000-21000]
+
+   *  B redistributes 192.0.2.1/32 into the IS-IS domain
+
+   In this case, A learns 192.0.2.1/32 as an IP leaf connected to B,
+   which is usual for IP prefix redistribution
+
+   However, according to the redistribution rule above, B decides not to
+   advertise any index with 192.0.2.1/32 into IS-IS because the SRGB is
+   not the same.
+
+2.5.2.2.  Illustration 2
+
+   Consider the example in the illustration described in
+   Section 2.5.2.1.
+
+   When router B redistributes the prefix 192.0.2.1/32, router B decides
+   to allocate and advertise the same index 1 with the prefix
+   192.0.2.1/32.
+
+   Within the SRGB of the IS-IS domain, index 1 corresponds to the local
+   label 16001.  Hence, according to the redistribution rule above,
+   router B programs the incoming label 16001 in its FIB to match
+   traffic arriving from the IS-IS domain destined to the prefix
+   192.0.2.1/32.
+
+2.6.  Effect of Incoming Label Collision on Outgoing Label Programming
+
+   When determining what outgoing label to use, the ingress node that
+   pushes new segments, and hence a stack of MPLS labels, MUST use, for
+   a given FEC, the label that has been selected by the node receiving
+   the packet with that label exposed as the top label.  So in case of
+   incoming label collision on this receiving node, the ingress node
+   MUST resolve this collision by using this same "Incoming Label
+   Collision resolution procedure" and by using the data of the
+   receiving node.
+
+   In the general case, the ingress node may not have the exact same
+   data as the receiving node, so the result may be different.  This is
+   under the responsibility of the network operator.  But in a typical
+   case, e.g., where a centralized node or a distributed link-state IGP
+   is used, all nodes would have the same database.  However, to
+   minimize the chance of misforwarding, a FEC that loses its incoming
+   label to the tiebreaking rules specified in Section 2.5 MUST NOT be
+   installed in FIB with an outgoing Segment Routing label based on the
+   SID corresponding to the lost incoming label.
+
+   Examples for the behavior specified in this section can be found in
+   Appendix A.3.
+
+2.7.  PUSH, CONTINUE, and NEXT
+
+   PUSH, NEXT, and CONTINUE are operations applied by the forwarding
+   plane.  The specifications of these operations can be found in
+   [RFC8402].  This subsection specifies how to implement each of these
+   operations in the MPLS forwarding plane.
+
+2.7.1.  PUSH
+
+   As described in [RFC8402], PUSH corresponds to pushing one or more
+   labels on top of an incoming packet then sending it out of a
+   particular physical interface or virtual interface, such as a UDP
+   tunnel [RFC7510] or the Layer 2 Tunneling Protocol version 3 (L2TPv3)
+   [RFC4817], towards a particular next hop.  When pushing labels onto a
+   packet's label stack, the Time-to-Live (TTL) field [RFC3032]
+   [RFC3443] and the Traffic Class (TC) field [RFC3032] [RFC5462] of
+   each label stack entry must, of course, be set.  This document does
+   not specify any set of rules for setting these fields; that is a
+   matter of local policy.  Sections 2.10 and 2.11 specify additional
+   details about forwarding behavior.
+
+2.7.2.  CONTINUE
+
+   As described in [RFC8402], the CONTINUE operation corresponds to
+   swapping the incoming label with an outgoing label.  The value of the
+   outgoing label is calculated as specified in Sections 2.10 and 2.11.
+
+2.7.3.  NEXT
+
+   As described in [RFC8402], NEXT corresponds to popping the topmost
+   label.  The action before and/or after the popping depends on the
+   instruction associated with the active SID on the received packet
+   prior to the popping.  For example, suppose the active SID in the
+   received packet was an Adj-SID [RFC8402]; on receiving the packet,
+   the node applies the NEXT operation, which corresponds to popping the
+   topmost label, and then sends the packet out of the physical or
+   virtual interface (e.g., the UDP tunnel [RFC7510] or L2TPv3 tunnel
+   [RFC4817]) towards the next hop corresponding to the Adj-SID.
+
+2.7.3.1.  Mirror SID
+
+   If the active SID in the received packet was a Mirror SID (see
+   [RFC8402], Section 5.1) allocated by the receiving router, the
+   receiving router applies the NEXT operation, which corresponds to
+   popping the topmost label, and then performs a lookup using the
+   contents of the packet after popping the outermost label in the
+   mirrored forwarding table.  The method by which the lookup is made,
+   and/or the actions applied to the packet after the lookup in the
+   mirror table, depends on the contents of the packet and the mirror
+   table.  Note that the packet exposed after popping the topmost label
+   may or may not be an MPLS packet.  A Mirror SID can be viewed as a
+   generalization of the context label in [RFC5331] because a Mirror SID
+   does not make any assumptions about the packet underneath the top
+   label.
+
+2.8.  MPLS Label Downloaded to the FIB for Global and Local SIDs
+
+   The label corresponding to the global SID "Si", which is represented
+   by the global index "I" and downloaded to the FIB, is used to match
+   packets whose active segment (and hence topmost label) is "Si".  The
+   value of this label is calculated as specified in Section 2.4.
+
+   For Local SIDs, the MCC is responsible for downloading the correct
+   label value to the FIB.  For example, an IGP with SR extensions
+   [RFC8667] [RFC8665] downloads the MPLS label corresponding to an Adj-
+   SID [RFC8402].
+
+2.9.  Active Segment
+
+   When instantiated in the MPLS domain, the active segment on a packet
+   corresponds to the topmost label and is calculated according to the
+   procedure specified in Sections 2.10 and 2.11.  When arriving at a
+   node, the topmost label corresponding to the active SID matches the
+   MPLS label downloaded to the FIB as specified in Section 2.4.
+
+2.10.  Forwarding Behavior for Global SIDs
+
+   This section specifies the forwarding behavior, including the
+   calculation of outgoing labels, that corresponds to a global SID when
+   applying the PUSH, CONTINUE, and NEXT operations in the MPLS
+   forwarding plane.
+
+   This document covers the calculation of the outgoing label for the
+   top label only.  The case where the outgoing label is not the top
+   label and is part of a stack of labels that instantiates a routing
+   policy or a traffic-engineering tunnel is outside the scope of this
+   document and may be covered in other documents such as
+   [ROUTING-POLICY].
+
+2.10.1.  Forwarding for PUSH and CONTINUE of Global SIDs
+
+   Suppose an MCC on router "R0" determines that, before sending the
+   packet towards a neighbor "N", the PUSH or CONTINUE operation is to
+   be applied to an incoming packet related to the global SID "Si".  SID
+   "Si" is represented by the global index "I" and owned by the router
+   Ri.  Neighbor "N" may be directly connected to "R0" through either a
+   physical or a virtual interface (e.g., UDP tunnel [RFC7510] or L2TPv3
+   tunnel [RFC4817]).
+
+   The method by which the MCC on router "R0" determines that the PUSH
+   or CONTINUE operation must be applied using the SID "Si" is beyond
+   the scope of this document.  An example of a method to determine the
+   SID "Si" for the PUSH operation is the case where IS-IS [RFC8667]
+   receives the Prefix-SID "Si" sub-TLV advertised with the prefix "P/m"
+   in TLV 135, and the prefix "P/m" is the longest matching network
+   prefix for the incoming IPv4 packet.
+
+   For the CONTINUE operation, an example of a method used to determine
+   the SID "Si" is the case where IS-IS [RFC8667] receives the Prefix-
+   SID "Si" sub-TLV advertised with prefix "P" in TLV 135, and the top
+   label of the incoming packet matches the MPLS label in the FIB
+   corresponding to the SID "Si" on router "R0".
+
+   The forwarding behavior for PUSH and CONTINUE corresponding to the
+   SID "Si" is as follows:
+
+   *  If neighbor "N" does not support SR or advertises an invalid SRGB
+      or a SRGB that is too small for the SID "Si", then:
+
+      -  If it is possible to send the packet towards neighbor "N" using
+         standard MPLS forwarding behavior as specified in [RFC3031] and
+         [RFC3032], forward the packet.  The method by which a router
+         decides whether it is possible to send the packet to "N" or not
+         is beyond the scope of this document.  For example, the router
+         "R0" can use the downstream label determined by another MCC,
+         such as LDP [RFC5036], to send the packet.
+
+      -  Else, if there are other usable next hops, use them to forward
+         the incoming packet.  The method by which the router "R0"
+         decides on the possibility of using other next hops is beyond
+         the scope of this document.  For example, the MCC on "R0" may
+         chose the send an IPv4 packet without pushing any label to
+         another next hop.
+
+      -  Otherwise, drop the packet.
+
+   *  Else,
+
+      -  Calculate the outgoing label as specified in Section 2.4 using
+         the SRGB of neighbor "N".
+
+      -  Determine the outgoing label stack
+
+         o  If the operation is PUSH:
+
+            +  Push the calculated label according to the MPLS label
+               pushing rules specified in [RFC3032].
+
+         o  Else,
+
+            +  swap the incoming label with the calculated label
+               according to the label-swapping rules in [RFC3031].
+
+         o  Send the packet towards neighbor "N".
+
+2.10.2.  Forwarding for the NEXT Operation for Global SIDs
+
+   As specified in Section 2.7.3, the NEXT operation corresponds to
+   popping the topmost label.  The forwarding behavior is as follows:
+
+   *  Pop the topmost label
+
+   *  Apply the instruction associated with the incoming label that has
+      been popped
+
+   The action on the packet after popping the topmost label depends on
+   the instruction associated with the incoming label as well as the
+   contents of the packet right underneath the top label that was
+   popped.  Examples of the NEXT operation are described in Appendix A.1
+
+2.11.  Forwarding Behavior for Local SIDs
+
+   This section specifies the forwarding behavior for Local SIDs when SR
+   is instantiated over the MPLS forwarding plane.
+
+2.11.1.  Forwarding for the PUSH Operation on Local SIDs
+
+   Suppose an MCC on router "R0" determines that the PUSH operation is
+   to be applied to an incoming packet using the Local SID "Si" before
+   sending the packet towards neighbor "N", which is directly connected
+   to R0 through a physical or virtual interface such as a UDP tunnel
+   [RFC7510] or L2TPv3 tunnel [RFC4817].
+
+   An example of such a Local SID is an Adj-SID allocated and advertised
+   by IS-IS [RFC8667].  The method by which the MCC on "R0" determines
+   that the PUSH operation is to be applied to the incoming packet is
+   beyond the scope of this document.  An example of such a method is
+   the backup path used to protect against a failure using TI-LFA
+   [FAST-REROUTE].
+
+   As mentioned in [RFC8402], a Local SID is specified by an MPLS label.
+   Hence, the PUSH operation for a Local SID is identical to the label
+   push operation using any MPLS label [RFC3031].  The forwarding action
+   after pushing the MPLS label corresponding to the Local SID is also
+   determined by the MCC.  For example, if the PUSH operation was done
+   to forward a packet over a backup path calculated using TI-LFA, then
+   the forwarding action may be sending the packet to a certain neighbor
+   that will in turn continue to forward the packet along the backup
+   path.
+
+2.11.2.  Forwarding for the CONTINUE Operation for Local SIDs
+
+   A Local SID on router "R0" corresponds to a local label.  In such a
+   scenario, the outgoing label towards next hop "N" is determined by
+   the MCC running on the router "R0", and the forwarding behavior for
+   the CONTINUE operation is identical to the swap operation on an MPLS
+   label [RFC3031].
+
+2.11.3.  Outgoing Label for the NEXT Operation for Local SIDs
+
+   The NEXT operation for Local SIDs is identical to the NEXT operation
+   for global SIDs as specified in Section 2.10.2.
+
+3.  IANA Considerations
+
+   This document has no IANA actions.
+
+4.  Manageability Considerations
+
+   This document describes the applicability of Segment Routing over the
+   MPLS data plane.  Segment Routing does not introduce any change in
+   the MPLS data plane.  Manageability considerations described in
+   [RFC8402] apply to the MPLS data plane when used with Segment
+   Routing.  SR Operations, Administration, and Maintenance (OAM) use
+   cases for the MPLS data plane are defined in [RFC8403].  SR OAM
+   procedures for the MPLS data plane are defined in [RFC8287].
+
+5.  Security Considerations
+
+   This document does not introduce additional security requirements and
+   mechanisms other than the ones described in [RFC8402].
+
+6.  References
+
+6.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>.
+
+   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
+              Label Switching Architecture", RFC 3031,
+              DOI 10.17487/RFC3031, January 2001,
+              <https://www.rfc-editor.org/info/rfc3031>.
+
+   [RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
+              Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
+              Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
+              <https://www.rfc-editor.org/info/rfc3032>.
+
+   [RFC3443]  Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing
+              in Multi-Protocol Label Switching (MPLS) Networks",
+              RFC 3443, DOI 10.17487/RFC3443, January 2003,
+              <https://www.rfc-editor.org/info/rfc3443>.
+
+   [RFC5462]  Andersson, L. and R. Asati, "Multiprotocol Label Switching
+              (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
+              Class" Field", RFC 5462, DOI 10.17487/RFC5462, February
+              2009, <https://www.rfc-editor.org/info/rfc5462>.
+
+   [RFC7274]  Kompella, K., Andersson, L., and A. Farrel, "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., "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>.
+
+   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
+              Decraene, B., Litkowski, S., and R. Shakir, "Segment
+              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
+              July 2018, <https://www.rfc-editor.org/info/rfc8402>.
+
+6.2.  Informative References
+
+   [FAST-REROUTE]
+              Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B.,
+              Francois, P., Voyer, D., Clad, F., and P. Camarillo,
+              "Topology Independent Fast Reroute using Segment Routing",
+              Work in Progress, Internet-Draft, draft-ietf-rtgwg-
+              segment-routing-ti-lfa-01, 5 March 2019,
+              <https://tools.ietf.org/html/draft-ietf-rtgwg-segment-
+              routing-ti-lfa-01>.
+
+   [RFC4817]  Townsley, M., Pignataro, C., Wainner, S., Seely, T., and
+              J. Young, "Encapsulation of MPLS over Layer 2 Tunneling
+              Protocol Version 3", RFC 4817, DOI 10.17487/RFC4817, March
+              2007, <https://www.rfc-editor.org/info/rfc4817>.
+
+   [RFC5036]  Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
+              "LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
+              October 2007, <https://www.rfc-editor.org/info/rfc5036>.
+
+   [RFC5331]  Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
+              Label Assignment and Context-Specific Label Space",
+              RFC 5331, DOI 10.17487/RFC5331, August 2008,
+              <https://www.rfc-editor.org/info/rfc5331>.
+
+   [RFC7510]  Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
+              "Encapsulating MPLS in UDP", RFC 7510,
+              DOI 10.17487/RFC7510, April 2015,
+              <https://www.rfc-editor.org/info/rfc7510>.
+
+   [RFC7855]  Previdi, S., Ed., Filsfils, C., Ed., Decraene, B.,
+              Litkowski, S., Horneffer, M., and R. Shakir, "Source
+              Packet Routing in Networking (SPRING) Problem Statement
+              and Requirements", RFC 7855, DOI 10.17487/RFC7855, May
+              2016, <https://www.rfc-editor.org/info/rfc7855>.
+
+   [RFC8287]  Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya,
+              N., Kini, S., and M. Chen, "Label Switched Path (LSP)
+              Ping/Traceroute for Segment Routing (SR) IGP-Prefix and
+              IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data
+              Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017,
+              <https://www.rfc-editor.org/info/rfc8287>.
+
+   [RFC8403]  Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N.
+              Kumar, "A Scalable and Topology-Aware MPLS Data-Plane
+              Monitoring System", RFC 8403, DOI 10.17487/RFC8403, July
+              2018, <https://www.rfc-editor.org/info/rfc8403>.
+
+   [RFC8661]  Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
+              Decraene, B., and S. Litkowski, "Segment Routing MPLS
+              Interworking with LDP", RFC 8661, DOI 10.17487/RFC8661,
+              December 2019, <https://www.rfc-editor.org/info/rfC8661>.
+
+   [RFC8665]  Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler,
+              H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
+              Extensions for Segment Routing", RFC 8665,
+              DOI 10.17487/RFC8665, December 2019,
+              <https://www.rfc-editor.org/info/rfc8665>.
+
+   [RFC8666]  Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions
+              for Segment Routing", RFC 8666, DOI 10.17487/RFC8666,
+              December 2019, <https://www.rfc-editor.org/info/rfc8666>.
+
+   [RFC8667]  Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C.,
+              Bashandy, A., Gredler, H., and B. Decraene, "IS-IS
+              Extensions for Segment Routing", RFC 8667,
+              DOI 10.17487/RFC8667, December 2019,
+              <https://www.rfc-editor.org/info/rfc8667>.
+
+   [ROUTING-POLICY]
+              Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and
+              P. Mattes, "Segment Routing Policy Architecture", Work in
+              Progress, Internet-Draft, draft-ietf-spring-segment-
+              routing-policy-05, 17 November 2019,
+              <https://tools.ietf.org/html/draft-ietf-spring-segment-
+              routing-policy-05>.
+
+Appendix A.  Examples
+
+A.1.  IGP Segment Examples
+
+   Consider the network diagram of Figure 1 and the IP addresses and IGP
+   segment allocations of Figure 2.  Assume that the network is running
+   IS-IS with SR extensions [RFC8667], and all links have the same
+   metric.  The following examples can be constructed.
+
+                                +--------+
+                               /          \
+                R0-----R1-----R2----------R3-----R8
+                              | \        / |
+                              |  +--R4--+  |
+                              |            |
+                              +-----R5-----+
+
+                   Figure 1: IGP Segments -- Illustration
+
+          +-----------------------------------------------------------+
+          | IP addresses allocated by the operator:                   |
+          |                      192.0.2.1/32 as a loopback of R1     |
+          |                      192.0.2.2/32 as a loopback of R2     |
+          |                      192.0.2.3/32 as a loopback of R3     |
+          |                      192.0.2.4/32 as a loopback of R4     |
+          |                      192.0.2.5/32 as a loopback of R5     |
+          |                      192.0.2.8/32 as a loopback of R8     |
+          |              198.51.100.9/32 as an anycast loopback of R4 |
+          |              198.51.100.9/32 as an anycast loopback of R5 |
+          |                                                           |
+          | SRGB defined by the operator as [1000,5000]               |
+          |                                                           |
+          | Global IGP SID indices allocated by the operator:         |
+          |                      1 allocated to 192.0.2.1/32          |
+          |                      2 allocated to 192.0.2.2/32          |
+          |                      3 allocated to 192.0.2.3/32          |
+          |                      4 allocated to 192.0.2.4/32          |
+          |                      8 allocated to 192.0.2.8/32          |
+          |                   1009 allocated to 198.51.100.9/32       |
+          |                                                           |
+          | Local IGP SID allocated dynamically by R2                 |
+          |                     for its "north" adjacency to R3: 9001 |
+          |                     for its "east" adjacency to R3 : 9002 |
+          |                     for its "south" adjacency to R3: 9003 |
+          |                     for its only adjacency to R4   : 9004 |
+          |                     for its only adjacency to R1   : 9005 |
+          +-----------------------------------------------------------+
+
+        Figure 2: IGP Address and Segment Allocation -- Illustration
+
+   Suppose R1 wants to send IPv4 packet P1 to R8.  In this case, R1
+   needs to apply the PUSH operation to the IPv4 packet.
+
+   Remember that the SID index "8" is a global IGP segment attached to
+   the IP prefix 192.0.2.8/32.  Its semantic is global within the IGP
+   domain: any router forwards a packet received with active segment 8
+   to the next hop along the ECMP-aware shortest path to the related
+   prefix.
+
+   R2 is the next hop along the shortest path towards R8.  By applying
+   the steps in Section 2.8, the outgoing label downloaded to R1's FIB
+   corresponding to the global SID index "8" is 1008 because the SRGB of
+   R2 = [1000,5000] as shown in Figure 2.
+
+   Because the packet is IPv4, R1 applies the PUSH operation using the
+   label value 1008 as specified in Section 2.10.1.  The resulting MPLS
+   header will have the "S" bit [RFC3032] set because it is followed
+   directly by an IPv4 packet.
+
+   The packet arrives at router R2.  Because top label 1008 corresponds
+   to the IGP SID index "8", which is the Prefix-SID attached to the
+   prefix 192.0.2.8/32 owned by Node R8, the instruction associated with
+   the SID is "forward the packet using one of the ECMP interfaces or
+   next hops along the shortest path(s) towards R8".  Because R2 is not
+   the penultimate hop, R2 applies the CONTINUE operation to the packet
+   and sends it to R3 using one of the two links connected to R3 with
+   top label 1008 as specified in Section 2.10.1.
+
+   R3 receives the packet with top label 1008.  Because top label 1008
+   corresponds to the IGP SID index "8", which is the Prefix-SID
+   attached to the prefix 192.0.2.8/32 owned by Node R8, the instruction
+   associated with the SID is "send the packet using one of the ECMP
+   interfaces and next hops along the shortest path towards R8".
+   Because R3 is the penultimate hop, we assume that R3 performs
+   penultimate hop popping, which corresponds to the NEXT operation; the
+   packet is then sent to R8.  The NEXT operation results in popping the
+   outer label and sending the packet as a pure IPv4 packet to R8.
+
+   In conclusion, the path followed by P1 is R1-R2--R3-R8.  The ECMP
+   awareness ensures that the traffic is load-shared between any ECMP
+   path; in this case, it's the two links between R2 and R3.
+
+A.2.  Incoming Label Collision Examples
+
+   This section outlines several examples to illustrate the handling of
+   label collision described in Section 2.5.
+
+   For the examples in this section, we assume that Node A has the
+   following:
+
+   *  OSPF default admin distance for implementation=50
+
+   *  IS-IS default admin distance for implementation=60
+
+A.2.1.  Example 1
+
+   The following example illustrates incoming label collision resolution
+   for the same FEC type using MCC administrative distance.
+
+   FEC1:
+
+   Node A receives an OSPF Prefix-SID Advertisement from Node B for
+   198.51.100.5/32 with index=5.  Assuming that OSPF SRGB on Node A =
+   [1000,1999], the incoming label is 1005.
+
+   FEC2:
+
+   IS-IS on Node A receives a Prefix-SID Advertisement from Node C for
+   203.0.113.105/32 with index=5.  Assuming that IS-IS SRGB on Node A =
+   [1000,1999], the incoming label is 1005.
+
+   FEC1 and FEC2 both use dynamic SID assignment.  Since neither of the
+   FECs are of type 'SR Policy', we use the default admin distances of
+   50 and 60 to break the tie.  So FEC1 wins.
+
+A.2.2.  Example 2
+
+   The following example Illustrates incoming label collision resolution
+   for different FEC types using the MCC administrative distance.
+
+   FEC1:
+
+   Node A receives an OSPF Prefix-SID Advertisement from Node B for
+   198.51.100.6/32 with index=6.  Assuming that OSPF SRGB on Node A =
+   [1000,1999], the incoming label on Node A corresponding to
+   198.51.100.6/32 is 1006.
+
+   FEC2:
+
+   IS-IS on Node A assigns label 1006 to the globally significant Adj-
+   SID (i.e., when advertised, the L-Flag is clear in the Adj-SID sub-
+   TLV as described in [RFC8667]).  Hence, the incoming label
+   corresponding to this Adj-SID is 1006.  Assume Node A allocates this
+   Adj-SID dynamically, and it may differ across router reboots.
+
+   FEC1 and FEC2 both use dynamic SID assignment.  Since neither of the
+   FECs are of type 'SR Policy', we use the default admin distances of
+   50 and 60 to break the tie.  So FEC1 wins.
+
+A.2.3.  Example 3
+
+   The following example illustrates incoming label collision resolution
+   based on preferring static over dynamic SID assignment.
+
+   FEC1:
+
+   OSPF on Node A receives a Prefix-SID Advertisement from Node B for
+   198.51.100.7/32 with index=7.  Assuming that the OSPF SRGB on Node A
+   = [1000,1999], the incoming label corresponding to 198.51.100.7/32 is
+   1007.
+
+   FEC2:
+
+   The operator on Node A configures IS-IS on Node A to assign label
+   1007 to the globally significant Adj-SID (i.e., when advertised, the
+   L-Flag is clear in the Adj-SID sub-TLV as described in [RFC8667]).
+
+   Node A assigns this Adj-SID explicitly via configuration, so the Adj-
+   SID survives router reboots.
+
+   FEC1 uses dynamic SID assignment, while FEC2 uses explicit SID
+   assignment.  So FEC2 wins.
+
+A.2.4.  Example 4
+
+   The following example illustrates incoming label collision resolution
+   using FEC type default administrative distance.
+
+   FEC1:
+
+   OSPF on Node A receives a Prefix-SID Advertisement from Node B for
+   198.51.100.8/32 with index=8.  Assuming that OSPF SRGB on Node A =
+   [1000,1999], the incoming label corresponding to 198.51.100.8/32 is
+   1008.
+
+   FEC2:
+
+   Suppose the SR Policy Advertisement from the controller to Node A for
+   the policy identified by (Endpoint = 192.0.2.208, color = 100) that
+   consists of SID-List=<S1, S2> assigns the globally significant
+   Binding-SID label 1008.
+
+   From the point of view of Node A, FEC1 and FEC2 both use dynamic SID
+   assignment.  Based on the default administrative distance outlined in
+   Section 2.5.1, the Binding SID has a higher administrative distance
+   than the Prefix-SID; hence, FEC1 wins.
+
+A.2.5.  Example 5
+
+   The following example illustrates incoming label collision resolution
+   based on FEC type preference.
+
+   FEC1:
+
+   IS-IS on Node A receives a Prefix-SID Advertisement from Node B for
+   203.0.113.110/32 with index=10.  Assuming that the IS-IS SRGB on Node
+   A = [1000,1999], the incoming label corresponding to 203.0.113.110/32
+   is 1010.
+
+   FEC2:
+
+   IS-IS on Node A assigns label 1010 to the globally significant Adj-
+   SID (i.e., when advertised, the L-Flag is clear in the Adj-SID sub-
+   TLV as described in [RFC8667]).
+
+   Node A allocates this Adj-SID dynamically, and it may differ across
+   router reboots.  Hence, both FEC1 and FEC2 both use dynamic SID
+   assignment.
+
+   Since both FECs are from the same MCC, they have the same default
+   admin distance.  So we compare the FEC type codepoints.  FEC1 has FEC
+   type codepoint=120, while FEC2 has FEC type codepoint=130.
+   Therefore, FEC1 wins.
+
+A.2.6.  Example 6
+
+   The following example illustrates incoming label collision resolution
+   based on address family preference.
+
+   FEC1:
+
+   IS-IS on Node A receives a Prefix-SID Advertisement from Node B for
+   203.0.113.111/32 with index=11.  Assuming that the IS-IS SRGB on Node
+   A = [1000,1999], the incoming label on Node A for 203.0.113.111/32 is
+   1011.
+
+   FEC2:
+
+   IS-IS on Node A receives a Prefix-SID Advertisement from Node C for
+   2001:DB8:1000::11/128 with index=11.  Assuming that the IS-IS SRGB on
+   Node A = [1000,1999], the incoming label on Node A for
+   2001:DB8:1000::11/128 is 1011.
+
+   FEC1 and FEC2 both use dynamic SID assignment.  Since both FECs are
+   from the same MCC, they have the same default admin distance.  So we
+   compare the FEC type codepoints.  Both FECs have FEC type
+   codepoint=120.  So we compare the address family.  Since IPv4 is
+   preferred over IPv6, FEC1 wins.
+
+A.2.7.  Example 7
+
+   The following example illustrates incoming label collision resolution
+   based on prefix length.
+
+   FEC1:
+
+   IS-IS on Node A receives a Prefix-SID Advertisement from Node B for
+   203.0.113.112/32 with index=12.  Assuming that IS-IS SRGB on Node A =
+   [1000,1999], the incoming label for 203.0.113.112/32 on Node A is
+   1012.
+
+   FEC2:
+
+   IS-IS on Node A receives a Prefix-SID Advertisement from Node C for
+   203.0.113.128/30 with index=12.  Assuming that the IS-IS SRGB on Node
+   A = [1000,1999], the incoming label for 203.0.113.128/30 on Node A is
+   1012.
+
+   FEC1 and FEC2 both use dynamic SID assignment.  Since both FECs are
+   from the same MCC, they have the same default admin distance.  So we
+   compare the FEC type codepoints.  Both FECs have FEC type
+   codepoint=120.  So we compare the address family.  Both are a part of
+   the IPv4 address family, so we compare the prefix length.  FEC1 has
+   prefix length=32, and FEC2 has prefix length=30, so FEC2 wins.
+
+A.2.8.  Example 8
+
+   The following example illustrates incoming label collision resolution
+   based on the numerical value of the FECs.
+
+   FEC1:
+
+   IS-IS on Node A receives a Prefix-SID Advertisement from Node B for
+   203.0.113.113/32 with index=13.  Assuming that IS-IS SRGB on Node A =
+   [1000,1999], the incoming label for 203.0.113.113/32 on Node A is
+   1013.
+
+   FEC2:
+
+   IS-IS on Node A receives a Prefix-SID Advertisement from Node C for
+   203.0.113.213/32 with index=13.  Assuming that IS-IS SRGB on Node A =
+   [1000,1999], the incoming label for 203.0.113.213/32 on Node A is
+   1013.
+
+   FEC1 and FEC2 both use dynamic SID assignment.  Since both FECs are
+   from the same MCC, they have the same default admin distance.  So we
+   compare the FEC type codepoints.  Both FECs have FEC type
+   codepoint=120.  So we compare the address family.  Both are a part of
+   the IPv4 address family, so we compare the prefix length.  Prefix
+   lengths are the same, so we compare the prefix.  FEC1 has the lower
+   prefix, so FEC1 wins.
+
+A.2.9.  Example 9
+
+   The following example illustrates incoming label collision resolution
+   based on the Routing Instance ID.
+
+   FEC1:
+
+   IS-IS on Node A receives a Prefix-SID Advertisement from Node B for
+   203.0.113.114/32 with index=14.  Assume that this IS-IS instance on
+   Node A has Routing Instance ID = 1000 and SRGB = [1000,1999].  Hence,
+   the incoming label for 203.0.113.114/32 on Node A is 1014.
+
+   FEC2:
+
+   IS-IS on Node A receives a Prefix-SID Advertisement from Node C for
+   203.0.113.114/32 with index=14.  Assume that this is another instance
+   of IS-IS on Node A but Routing Instance ID = 2000 is different and
+   SRGB = [1000,1999] is the same.  Hence, the incoming label for
+   203.0.113.114/32 on Node A is 1014.
+
+   These two FECs match all the way through the prefix length and
+   prefix.  So the Routing Instance ID breaks the tie, and FEC1 wins.
+
+A.2.10.  Example 10
+
+   The following example illustrates incoming label collision resolution
+   based on the topology ID.
+
+   FEC1:
+
+   IS-IS on Node A receives a Prefix-SID Advertisement from Node B for
+   203.0.113.115/32 with index=15.  Assume that this IS-IS instance on
+   Node A has Routing Instance ID = 1000.  Assume that the prefix
+   advertisement of 203.0.113.115/32 was received in the IS-IS Multi-
+   topology advertisement with ID = 50.  If the IS-IS SRGB for this
+   routing instance on Node A = [1000,1999], then the incoming label of
+   203.0.113.115/32 for topology 50 on Node A is 1015.
+
+   FEC2:
+
+   IS-IS on Node A receives a Prefix-SID Advertisement from Node C for
+   203.0.113.115/32 with index=15.  Assume that it has the same Routing
+   Instance ID = 1000, but 203.0.113.115/32 was advertised with IS-IS
+   Multi-topology ID = 40, which is different.  If the IS-IS SRGB on
+   Node A = [1000,1999], then the incoming label of 203.0.113.115/32 for
+   topology 40 on Node A is also 1015.
+
+   Since these two FECs match all the way through the prefix length,
+   prefix, and Routing Instance ID, we compare the IS-IS Multi-topology
+   ID, so FEC2 wins.
+
+A.2.11.  Example 11
+
+   The following example illustrates incoming label collision for
+   resolution based on the algorithm ID.
+
+   FEC1:
+
+   IS-IS on Node A receives a Prefix-SID Advertisement from Node B for
+   203.0.113.116/32 with index=16.  Assume that IS-IS on Node A has
+   Routing Instance ID = 1000.  Assume that Node B advertised
+   203.0.113.116/32 with IS-IS Multi-topology ID = 50 and SR algorithm =
+   0.  Assume that the IS-IS SRGB on Node A = [1000,1999].  Hence, the
+   incoming label corresponding to this advertisement of
+   203.0.113.116/32 is 1016.
+
+   FEC2:
+
+   IS-IS on Node A receives a Prefix-SID Advertisement from Node C for
+   203.0.113.116/32 with index=16.  Assume that it is the same IS-IS
+   instance on Node A with Routing Instance ID = 1000.  Also assume that
+   Node C advertised 203.0.113.116/32 with IS-IS Multi-topology ID = 50
+   but with SR algorithm = 22.  Since it is the same routing instance,
+   the SRGB on Node A = [1000,1999].  Hence, the incoming label
+   corresponding to this advertisement of 203.0.113.116/32 by Node C is
+   also 1016.
+
+   Since these two FECs match all the way through in terms of the prefix
+   length, prefix, Routing Instance ID, and Multi-topology ID, we
+   compare the SR algorithm IDs, so FEC1 wins.
+
+A.2.12.  Example 12
+
+   The following example illustrates incoming label collision resolution
+   based on the FEC numerical value, independent of how the SID is
+   assigned to the colliding FECs.
+
+   FEC1:
+
+   IS-IS on Node A receives a Prefix-SID Advertisement from Node B for
+   203.0.113.117/32 with index=17.  Assume that the IS-IS SRGB on Node A
+   = [1000,1999]; thus, the incoming label is 1017.
+
+   FEC2:
+
+   Suppose there is an IS-IS Mapping Server Advertisement (SID / Label
+   Binding TLV) from Node D that has range = 100 and prefix =
+   203.0.113.1/32.  Suppose this Mapping Server Advertisement generates
+   100 mappings, one of which maps 203.0.113.17/32 to index=17.
+   Assuming that it is the same IS-IS instance, the SRGB = [1000,1999]
+   and hence the incoming label for 1017.
+
+   Even though FEC1 comes from a normal Prefix-SID Advertisement and
+   FEC2 is generated from a Mapping Server Advertisement, it is not used
+   as a tiebreaking parameter.  Both FECs use dynamic SID assignment,
+   are from the same MCC, and have the same FEC type codepoint=120.
+   Their prefix lengths are the same as well.  FEC2 wins based on its
+   lower numerical prefix value, since 203.0.113.17 is less than
+   203.0.113.117.
+
+A.2.13.  Example 13
+
+   The following example illustrates incoming label collision resolution
+   based on address family preference.
+
+   FEC1:
+
+   SR Policy Advertisement from the controller to Node A.  Endpoint
+   address=2001:DB8:3000::100, color=100, SID-List=<S1, S2>, and the
+   Binding-SID label=1020.
+
+   FEC2:
+
+   SR Policy Advertisement from controller to Node A.  Endpoint
+   address=192.0.2.60, color=100, SID-List=<S3, S4>, and the Binding-SID
+   label=1020.
+
+   The FEC tiebreakers match, and they have the same FEC type
+   codepoint=140.  Thus, FEC2 wins based on the IPv4 address family
+   being preferred over IPv6.
+
+A.2.14.  Example 14
+
+   The following example illustrates incoming label resolution based on
+   the numerical value of the policy endpoint.
+
+   FEC1:
+
+   SR Policy Advertisement from the controller to Node A.  Endpoint
+   address=192.0.2.70, color=100, SID-List=<S1, S2>, and Binding-SID
+   label=1021.
+
+   FEC2:
+
+   SR Policy Advertisement from the controller to Node A.  Endpoint
+   address=192.0.2.71, color=100, SID-List=<S3, S4>, and Binding-SID
+   label=1021.
+
+   The FEC tiebreakers match, and they have the same address family.
+   Thus, FEC1 wins by having the lower numerical endpoint address value.
+
+A.3.  Examples for the Effect of Incoming Label Collision on an Outgoing
+      Label
+
+   This section presents examples to illustrate the effect of incoming
+   label collision on the selection of the outgoing label as described
+   in Section 2.6.
+
+A.3.1.  Example 1
+
+   The following example illustrates the effect of incoming label
+   resolution on the outgoing label.
+
+   FEC1:
+
+   IS-IS on Node A receives a Prefix-SID Advertisement from Node B for
+   203.0.113.122/32 with index=22.  Assuming that the IS-IS SRGB on Node
+   A = [1000,1999], the corresponding incoming label is 1022.
+
+   FEC2:
+
+   IS-IS on Node A receives a Prefix-SID Advertisement from Node C for
+   203.0.113.222/32 with index=22.  Assuming that the IS-IS SRGB on Node
+   A = [1000,1999], the corresponding incoming label is 1022.
+
+   FEC1 wins based on the lowest numerical prefix value.  This means
+   that Node A installs a transit MPLS forwarding entry to swap incoming
+   label 1022 with outgoing label N and to use outgoing interface I.  N
+   is determined by the index associated with FEC1 (index=22) and the
+   SRGB advertised by the next-hop node on the shortest path to reach
+   203.0.113.122/32.
+
+   Node A will generally also install an imposition MPLS forwarding
+   entry corresponding to FEC1 for incoming prefix=203.0.113.122/32
+   pushing outgoing label N, and using outgoing interface I.
+
+   The rule in Section 2.6 means Node A MUST NOT install an ingress MPLS
+   forwarding entry corresponding to FEC2 (the losing FEC, which would
+   be for prefix 203.0.113.222/32).
+
+A.3.2.  Example 2
+
+   The following example illustrates the effect of incoming label
+   collision resolution on outgoing label programming on Node A.
+
+   FEC1:
+
+   SR Policy Advertisement from the controller to Node A.  Endpoint
+   address=192.0.2.80, color=100, SID-List=<S1, S2>, and Binding-SID
+   label=1023.
+
+   FEC2:
+
+   SR Policy Advertisement from controller to Node A.  Endpoint
+   address=192.0.2.81, color=100, SID-List=<S3, S4>, and Binding-SID
+   label=1023.
+
+   FEC1 wins by having the lower numerical endpoint address value.  This
+   means that Node A installs a transit MPLS forwarding entry to swap
+   incoming label=1023 with outgoing labels, and the outgoing interface
+   is determined by the SID-List for FEC1.
+
+   In this example, we assume that Node A receives two BGP/VPN routes:
+
+   *  R1 with VPN label=V1, BGP next hop = 192.0.2.80, and color=100
+
+   *  R2 with VPN label=V2, BGP next hop = 192.0.2.81, and color=100
+
+   We also assume that Node A has a BGP policy that matches color=100
+   and allows its usage as Service Level Agreement (SLA) steering
+   information.  In this case, Node A will install a VPN route with
+   label stack = <S1,S2,V1> (corresponding to FEC1).
+
+   The rule described in Section 2.6 means that Node A MUST NOT install
+   a VPN route with label stack = <S3,S4,V1> (corresponding to FEC2.)
+
+Acknowledgements
+
+   The authors would like to thank Les Ginsberg, Chris Bowers, Himanshu
+   Shah, Adrian Farrel, Alexander Vainshtein, Przemyslaw Krol, Darren
+   Dukes, Zafar Ali, and Martin Vigoureux for their valuable comments on
+   this document.
+
+Contributors
+
+   The following contributors have substantially helped the definition
+   and editing of the content of this document:
+
+   Martin Horneffer
+   Deutsche Telekom
+   Email: Martin.Horneffer@telekom.de
+
+   Wim Henderickx
+   Nokia
+   Email: wim.henderickx@nokia.com
+
+   Jeff Tantsura
+   Email: jefftant@gmail.com
+
+   Edward Crabbe
+   Email: edward.crabbe@gmail.com
+
+   Igor Milojevic
+   Email: milojevicigor@gmail.com
+
+   Saku Ytti
+   Email: saku@ytti.fi
+
+Authors' Addresses
+
+   Ahmed Bashandy (editor)
+   Arrcus
+
+   Email: abashandy.ietf@gmail.com
+
+
+   Clarence Filsfils (editor)
+   Cisco Systems, Inc.
+   Brussels
+   Belgium
+
+   Email: cfilsfil@cisco.com
+
+
+   Stefano Previdi
+   Cisco Systems, Inc.
+   Italy
+
+   Email: stefano@previdi.net
+
+
+   Bruno Decraene
+   Orange
+   France
+
+   Email: bruno.decraene@orange.com
+
+
+   Stephane Litkowski
+   Orange
+   France
+
+   Email: slitkows.ietf@gmail.com
+
+
+   Rob Shakir
+   Google
+   United States of America
+
+   Email: robjs@google.com