RFC 8660

Segment Routing with the MPLS Data Plane

📅 published December 2019, from ietf

Segment Routing with the MPLS Data Plane 🦋

Part 1 of 7 💖

Okay bestie, this is RFC 8660, and it's an IETF Standards Track doc (category: Standards Track, status: Internet Standards Track 🎀). It came out in December 2019 and the ISSN is 2070-1721. The main authors are A. Bashandy (Ed.) from Arrcus, C. Filsfils (Ed.) from Cisco Systems, S. Previdi from Cisco Systems, B. Decraene and S. Litkowski from Orange, and R. Shakir from Google. The header doesn't list anything it obsoletes or updates, so it's standing on its own ✨

Abstract ✨

Okay so Segment Routing (SR) is built on source routing. A node steers a packet through a set of instructions called segments, and it does that by sticking an SR header onto the front of the packet. In the MPLS data plane, that SR header is just a label stack 🧚 This document is the spec for the forwarding behavior that lets SR run over MPLS, which is called SR-MPLS 💜

Status of This Memo

This is an Internet Standards Track document 🌈

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 7841 💅

You can find out the current status of this doc, any errata, and how to send feedback at https://www.rfc-editor.org/info/rfc8660 🔥

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

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can read at https://trustee.ietf.org/license-info (as they stood when this was published). Please actually read them, because they explain what rights and restrictions you have with this doc 🙈 Any Code Components pulled out of this document have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They also come with no 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 ✨

Okay so the Segment Routing architecture [RFC8402] can be applied straight onto the MPLS architecture, with no change to the MPLS forwarding plane. This document is the forwarding-plane behavior that lets SR work on top of the MPLS data plane (SR-MPLS) 🦋 It does not cover control-plane behavior. That lives in other docs, like [RFC8665], [RFC8666], and [RFC8667] 🎀

The SR problem statement is written up in [RFC7855] 🧚

Running SR over the MPLS forwarding plane alongside LDP [RFC5036] is specified in [RFC8661] 💜

Policy routing and traffic engineering with SR are covered 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 into the MPLS architecture defined in [RFC3031], from both the control-plane and the forwarding-plane points of view 💅

  • From a control-plane perspective, [RFC3031] doesn't mandate a single signaling protocol. SR uses a bunch of control-plane protocols, like the link-state IGPs [RFC8665] [RFC8666] [RFC8667]. The flooding mechanisms of link-state IGPs fit really 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 doesn't need any change to the forwarding plane, because Segment IDs (SIDs) get instantiated as MPLS labels, and the Segment Routing header gets instantiated as a stack of MPLS labels 🫶

We call the "MPLS Control Plane Client (MCC)" any control-plane entity that installs forwarding entries in the MPLS data plane. Local configuration and policies applied on a router are examples of MCCs 🔥

Here's the deal with node segments: to get a node segment to reach the node, a network operator SHOULD configure at least one node segment per routing instance, topology, or algorithm. If they don't, the node isn't reachable within that routing instance, topology, or algorithm, which limits 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 doesn't prohibit having more than one SID for the same prefix. In fact, allowing multiple SIDs for one prefix means you can have different forwarding behaviors (like different paths, different ECMP and Unequal-Cost Multipath (UCMP) behaviors, and so on) for the same destination 💖

Instantiating Segment Routing over the MPLS forwarding plane fits right in with this idea. An operator can assign multiple MPLS labels or indices to the same prefix, then assign a different forwarding behavior 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 pick a particular forwarding behavior for a particular packet by applying the PUSH action to that packet with the matching SID 🦋

2.2. SID Representation in the MPLS Forwarding Plane 🧚

When SR is instantiated 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 for mapping 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 doesn't need to 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 doesn't 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 doesn't use a special-purpose label. The SRLB is the range of local labels the node reserves 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 that apply to the SRGB also apply to the SRLB, except that 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

okay so this subsection is all about how you get the actual MPLS label number from a SID index 🎀 The index value comes from an MCC like IS-IS [RFC8667] or OSPF [RFC8665]. This section ONLY covers the index-to-label math 💅 Once you have the label, it gets downloaded to the FIB, sent out with a forwarded packet, or both. Iconic multitasking ✨

So say your SID is the index "I", and you've got an SRGB (see Section 2.3) 🌸 First you figure out the total size of the SRGB, called "Size", with this 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 it calculates the MPLS label value for 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 for SID index "I" gets calculated like this:

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)

If you want to see a router calculating labels and forwarding traffic with this exact procedure, check out Appendix A.1 🦋

2.5. Incoming Label Collision

Okay bestie, so the MPLS Architecture [RFC3031] defines the term Forwarding Equivalence Class (FEC) as the set of packets with similar and/or identical characteristics that get forwarded the same way and are bound to the same MPLS incoming (local) label 🌈 In Segment Routing MPLS, a local label acts as the SID for a given FEC. It's giving main character energy ✨

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 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 end up 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. Not me being relieved 🙈

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 goal of the following steps is to deterministically install a single FEC with the incoming label "L1" in the MPLS Incoming Label Map, also known as the label FIB. By "deterministically install", we mean that 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" no matter what order the mappings of this set of FECs to the label "L1" arrive in. 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 goes like this:

  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 no matter what order the FECs and the label "L1" are received in. In other words, the tiebreaking rule MUST be deterministic. 🫶

  1. If there is still a 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. ✨
  2. Install the selected FEC into the IP FIB and its incoming label into the label FIB. 💅
  3. 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 ✨

okay so when two FECs are fighting over the same incoming label, here's how the tiebreak goes 💅

  1. Find the lowest administrative distance among the competing FECs. (More on that below 🦋) Then filter out every competing FEC with a higher administrative distance.
  2. If more than one competing FEC is still standing after step 1, pick the smallest numerical FEC value. The numerical value comes from the FEC encoding described later in this section.

These rules deterministically pick which FEC gets installed in the MPLS forwarding plane for the given incoming label. Same inputs, same winner, every time 👑

Here's the part that matters most. This doc defines a set of default tiebreaking rules, and those are the ones you SHOULD implement 🎀 An implementation MAY choose to support different tiebreaking rules, and it MAY use one of those instead of the defaults. But to keep MPLS forwarding consistent when a SID gets misconfigured, the network operator MUST deploy routers that use the same tiebreaking rules within an IGP flooding area 😭

Every FEC gets an administrative distance. It's an 8-bit value, and lower means better, periodt 💖

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, and 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, since it 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]

These numerical values are here 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:
      • The IPv6 address is encoded natively.
      • 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.
      • A prefix is encoded in the most significant bits, and the remaining bits are set to zero.
      • 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 with 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 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. 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 that prefix. Within the SRGB of the IS-IS domain, index 1 corresponds to the local label 16001. So, 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 therefore a stack of MPLS labels) MUST use, for a given FEC, the label that the receiving node selected when that packet arrived with the label exposed as the top label. So if an incoming label collision happens on that receiving node, the ingress node MUST resolve the collision by using this same "Incoming Label Collision resolution procedure" and 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. That's 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. Still, 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. Nobody wants that, bestie 💀

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. Their specifications can be found in [RFC8402]. This subsection explains how to implement each of these operations in the MPLS forwarding plane 💖

2.7.1. PUSH 🎀

As described in [RFC8402], PUSH means pushing one or more labels on top of an incoming packet, then sending it out of a particular physical interface or virtual interface towards a particular next hop. Virtual interfaces include things like a UDP tunnel [RFC7510] or the Layer 2 Tunneling Protocol version 3 (L2TPv3) [RFC4817]. 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, since 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 means 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 means 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 pops the topmost label, and then sends the packet out of the physical or virtual interface (for example, the UDP tunnel [RFC7510] or the L2TPv3 tunnel [RFC4817]) towards the next hop corresponding to the Adj-SID 🫶

2.7.3.1. Mirror SID

okay bestie, Mirror SIDs are giving main character energy 💖. If the active SID in a packet is a Mirror SID (see [RFC8402], Section 5.1) that the receiving router allocated, the router does the NEXT operation, which means it pops the topmost label. Then it does a lookup on what's left after that outermost label is gone, but in the mirrored forwarding table 🦋. How the lookup happens, and what gets done to the packet after it, depends on the packet's contents and on the mirror table. ngl that's the fun part 🔥.

Also, the packet exposed after popping the top label may or may not be an MPLS packet 🙈. That's the wild part. A Mirror SID is basically a generalization of the context label in [RFC5331], because it doesn't assume anything about the packet underneath the top label ✨.

2.8. MPLS Label Downloaded to the FIB for Global and Local SIDs

so the label for a global SID "Si" 🌸, which is represented by the global index "I" and downloaded to the FIB, is what matches packets whose active segment (and so their topmost label) is "Si". The value of that label gets calculated the way Section 2.4 says 🧚.

For Local SIDs, the MCC is the one responsible for downloading the correct label value to the FIB 💅. For example, an IGP with SR extensions [RFC8667] [RFC8665] downloads the MPLS label that matches an Adj-SID [RFC8402] 🫶.

2.9. Active Segment

when SR is running in the MPLS domain, the active segment on a packet is the topmost label 🎀. It gets calculated using the procedures in Sections 2.10 and 2.11 💖. When a packet shows up at a node, the topmost label for the active SID should match the MPLS label that got downloaded to the FIB, like Section 2.4 says ✨.

2.10. Forwarding Behavior for Global SIDs

this section is the forwarding behavior for global SIDs 👑. It covers the calculation of outgoing labels too, and it applies when you're doing PUSH, CONTINUE, and NEXT in the MPLS forwarding plane 🦋.

Quick heads up: this document only covers the outgoing label for the top label 🙈. If the outgoing label isn't the top label and it's part of a label stack that sets up a routing policy or a traffic-engineering tunnel, that's outside this document's scope. It might get covered somewhere else, like [ROUTING-POLICY] 🧚.

2.10.1. Forwarding for PUSH and CONTINUE of Global SIDs

okay so picture this 🌈. An MCC on router "R0" decides that, before it sends a packet to a neighbor "N", the PUSH or CONTINUE operation has to be applied to an incoming packet related to the global SID "Si" ✨. SID "Si" is represented by the global index "I" and is owned by router Ri 💜. Neighbor "N" can be directly connected to "R0" through a physical interface or a virtual one, like a UDP tunnel [RFC7510] or an L2TPv3 tunnel [RFC4817] 🎀.

How the MCC on "R0" figures out that PUSH or CONTINUE has to be applied with SID "Si" is beyond this document's scope 🙈. One example for PUSH is when IS-IS [RFC8667] gets the Prefix-SID "Si" sub-TLV advertised with the prefix "P/m" in TLV 135, and "P/m" is the longest matching network prefix for the incoming IPv4 packet 💅.

For CONTINUE, one example is when IS-IS [RFC8667] gets 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 that corresponds to SID "Si" on router "R0" 🫶.

Here's the forwarding behavior for PUSH and CONTINUE with SID "Si" 🍓:

  • If neighbor "N" doesn't support SR, or it advertises an invalid SRGB, or an SRGB that's too small for SID "Si", then:
    • If it's possible to send the packet towards neighbor "N" using standard MPLS forwarding as specified in [RFC3031] and [RFC3032], then forward the packet. How a router decides whether it's possible to send to "N" is beyond this document's scope 🌸. For example, router "R0" can use a downstream label that some other MCC figured out, like one from LDP [RFC5036], to send the packet 🦋.
    • Else, if there are other usable next hops, use them to forward the incoming packet. How router "R0" decides it can use other next hops is also beyond scope 💖. For example, the MCC on "R0" might choose to send an IPv4 packet without pushing any label to another next hop ✨.
    • Otherwise, drop the packet 💀.
  • Else,
    • Calculate the outgoing label the way Section 2.4 says, using the SRGB of neighbor "N" 🧚.
    • Determine the outgoing label stack:
      • If the operation is PUSH:
        • Push the calculated label according to the MPLS label pushing rules in [RFC3032] 👑.
      • Else,
        • swap the incoming label with the calculated label using the label-swapping rules in [RFC3031] 🔥.
      • Send the packet towards neighbor "N" 🫶.

2.10.2. Forwarding for the NEXT Operation for Global SIDs

like we said in Section 2.7.3, the NEXT operation means popping the topmost label 💅. The forwarding behavior goes:

  • Pop the topmost label
  • Apply the instruction that goes with the incoming label that just got popped ✨

what happens to the packet after the pop depends on that instruction, and also on whatever's right underneath the top label that got popped 🦋. Examples of the NEXT operation are in Appendix A.1 🌈.

2.11. Forwarding Behavior for Local SIDs

this section covers forwarding for Local SIDs when SR runs over the MPLS forwarding plane 🎀.

2.11.1. Forwarding for the PUSH Operation on Local SIDs

so suppose an MCC on router "R0" decides that the PUSH operation should be applied to an incoming packet using the Local SID "Si" before it goes to neighbor "N" 💖. Neighbor "N" is directly connected to R0 through a physical or virtual interface, like a UDP tunnel [RFC7510] or an L2TPv3 tunnel [RFC4817] 🌸.

An example of a Local SID like this is an Adj-SID that IS-IS [RFC8667] allocates and advertises 🧚. How the MCC on "R0" decides that PUSH should be applied to the incoming packet is beyond this document's scope 🙈. One example of that method is a 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 ✨. So the PUSH operation for a Local SID is the same as the label push operation for any MPLS label [RFC3031] 💜. The forwarding action after pushing the MPLS label for the Local SID is also decided by the MCC 👑. For example, if PUSH was done to forward a packet over a backup path that TI-LFA calculated, the forwarding action might be sending the packet to a certain neighbor, which then keeps forwarding it 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 that case, the outgoing label towards next hop "N" is decided by the MCC running on router "R0" 💅. The forwarding behavior for CONTINUE is the same as 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 exactly the same as the NEXT operation for global SIDs, which is in Section 2.10.2 🌈.

3. IANA Considerations

this one's chill 🌸. This document has no IANA actions ✨.

4. Manageability Considerations

this document describes where Segment Routing applies over the MPLS data plane 🦋. SR doesn't change anything in the MPLS data plane at all 💖. The manageability considerations in [RFC8402] apply to the MPLS data plane when it's 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

okay, this part is serious bestie 🚨. This document doesn't add any extra security requirements or mechanisms beyond the ones in [RFC8402] 🔐. So whatever security stuff applies there is still the thing to lean on here 🫶.

6. References

6.1. Normative References

here are the normative references, all listed in full 📚:

   [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 ✨

Okay bestie, these are the optional reading list 📚 Each entry gives the full details, so you can track down the source yourself.

Appendix A. Examples 🎀

A.1. IGP Segment Examples 🦋

Okay so picture this: we've got the network diagram in Figure 1 and the IP addresses and IGP segment allocations in Figure 2. The network is running IS-IS with SR extensions [RFC8667], and every link has the same metric. That's the setup, and from there we can build some examples 💖

                                +--------+
                               /          \
                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 ✨

Now let's say R1 wants to send IPv4 packet P1 to R8. 🚀 R1 has to apply the PUSH operation to that IPv4 packet.

Remember that SID index 8 is a global IGP segment tied to the IP prefix 192.0.2.8/32. Its meaning is global across the whole IGP domain: any router that gets a packet carrying active segment 8 forwards it to the next hop on the ECMP-aware shortest path to that prefix 💅

R2 is the next hop on the shortest path toward R8. Using the steps in Section 2.8, the outgoing label that gets downloaded into R1's FIB for global SID index 8 is 1008, because R2's SRGB is [1000,5000], as shown in Figure 2.

Since the packet is IPv4, R1 applies the PUSH operation with label value 1008, as described in Section 2.10.1. The resulting MPLS header will have the "S" bit [RFC3032] set, because it's followed directly by an IPv4 packet 🎀

The packet shows up at router R2. Top label 1008 corresponds to IGP SID index 8, which is the Prefix-SID attached to the prefix 192.0.2.8/32 owned by Node R8. So the instruction tied to that 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 and sends the packet to R3 over one of the two links connected to R3, still with top label 1008, as described in Section 2.10.1 🦋

R3 receives the packet with top label 1008. That label corresponds to IGP SID index 8 again, the Prefix-SID for 192.0.2.8/32 owned by Node R8, so the instruction 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 R3 does penultimate hop popping, which is the NEXT operation. The packet then goes to R8. The NEXT operation pops the outer label and sends the packet on as a pure IPv4 packet to R8 🌸

So the path P1 takes is R1-R2--R3-R8. The ECMP awareness means the traffic gets load-shared across every ECMP path. In this case, that's the two links between R2 and R3 👑

A.2. Incoming Label Collision Examples 💜

This section walks through a few examples of the label collision handling described in Section 2.5. Let's get into it 🧚

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 🍓

This example shows incoming label collision resolution for the same FEC type, using the 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 the 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 the IS-IS SRGB on Node A = [1000,1999], the incoming label is 1005.

FEC1 and FEC2 both use dynamic SID assignment. Since neither FEC is 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 🌈

This example shows 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 the OSPF SRGB on Node A = [1000,1999], the incoming label on Node A for 198.51.100.6/32 is 1006.

FEC2:

IS-IS on Node A assigns label 1006 to the globally significant Adj-SID (meaning that when it's advertised, the L-Flag is clear in the Adj-SID sub-TLV, as described in [RFC8667]). So the incoming label for this Adj-SID is 1006. Node A allocates this Adj-SID dynamically, and it may differ across router reboots 🙈

FEC1 and FEC2 both use dynamic SID assignment. Since neither FEC is 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 ⭐

This example shows incoming label collision resolution by 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 the OSPF SRGB on Node A = [1000,1999], the incoming label for 198.51.100.7/32 is 1007.

FEC2:

The operator configures IS-IS on Node A to assign label 1007 to the globally significant Adj-SID (meaning that when it's 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 ✨

okay so this one shows how incoming label collisions get resolved using the FEC type default administrative distance 💅

FEC1: OSPF on Node A gets a Prefix-SID Advertisement from Node B for 198.51.100.8/32 with index=8. If the OSPF SRGB on Node A is [1000,1999], then the incoming label for 198.51.100.8/32 is 1008 🌸

FEC2: the SR Policy Advertisement from the controller to Node A, for the policy identified by (Endpoint = 192.0.2.208, color = 100) with SID-List=<S1, S2>, assigns the globally significant Binding-SID label 1008 👀

From Node A's point of view, both FEC1 and FEC2 use dynamic SID assignment. Using the default administrative distance from Section 2.5.1, the Binding SID has a higher administrative distance than the Prefix-SID, so FEC1 wins 👑

A.2.5. Example 5 🦋

this one is about incoming label collisions getting resolved by FEC type preference 🫶

FEC1: IS-IS on Node A gets a Prefix-SID Advertisement from Node B for 203.0.113.110/32 with index=10. If the IS-IS SRGB on Node A is [1000,1999], then the incoming label for 203.0.113.110/32 is 1010 ✨

FEC2: IS-IS on Node A assigns label 1010 to the globally significant Adj-SID. When it's 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 be different across router reboots. So both FEC1 and FEC2 use dynamic SID assignment 🌈

Both FECs come from the same MCC, which means they have the same default admin distance. So we compare the FEC type codepoints. FEC1 has codepoint=120, while FEC2 has codepoint=130. Therefore, FEC1 wins 💖

A.2.6. Example 6 💜

this one shows incoming label collision resolution based on address family preference 🧚

FEC1: IS-IS on Node A gets a Prefix-SID Advertisement from Node B for 203.0.113.111/32 with index=11. If the IS-IS SRGB on Node A is [1000,1999], then the incoming label on Node A for 203.0.113.111/32 is 1011 🍓

FEC2: IS-IS on Node A gets a Prefix-SID Advertisement from Node C for 2001:DB8:1000::11/128 with index=11. If the IS-IS SRGB on Node A is [1000,1999], then the incoming label on Node A for 2001:DB8:1000::11/128 is 1011 🎀

Both FEC1 and FEC2 use dynamic SID assignment. They come from the same MCC, so they have the same default admin distance, and then we compare the FEC type codepoints. Both FECs have codepoint=120, so we compare the address family. IPv4 is preferred over IPv6, so FEC1 wins 🔥

A.2.7. Example 7 🌸

this one is incoming label collision resolution based on prefix length 🙈

FEC1: IS-IS on Node A gets a Prefix-SID Advertisement from Node B for 203.0.113.112/32 with index=12. If IS-IS SRGB on Node A is [1000,1999], then the incoming label for 203.0.113.112/32 on Node A is 1012 ⭐

FEC2: IS-IS on Node A gets a Prefix-SID Advertisement from Node C for 203.0.113.128/30 with index=12. If the IS-IS SRGB on Node A is [1000,1999], then the incoming label for 203.0.113.128/30 on Node A is 1012 🫶

Both FECs use dynamic SID assignment and come from the same MCC, so they have the same default admin distance. We compare the FEC type codepoints, and both have codepoint=120. Next we compare the address family. Both are in the IPv4 address family, so we move on to the prefix length. FEC1 has prefix length=32, and FEC2 has prefix length=30, so FEC2 wins 🦋

A.2.8. Example 8 🍓

this one resolves the collision based on the numerical value of the FECs 🧁

FEC1: IS-IS on Node A gets a Prefix-SID Advertisement from Node B for 203.0.113.113/32 with index=13. If IS-IS SRGB on Node A is [1000,1999], then the incoming label for 203.0.113.113/32 on Node A is 1013 💅

FEC2: IS-IS on Node A gets a Prefix-SID Advertisement from Node C for 203.0.113.213/32 with index=13. If IS-IS SRGB on Node A is [1000,1999], then the incoming label for 203.0.113.213/32 on Node A is 1013 💀

Both FECs use dynamic SID assignment and come from the same MCC, so they have the same default admin distance. We compare the FEC type codepoints, and both have codepoint=120. Then we compare the address family. Both are in the IPv4 address family, so we compare the prefix length. The prefix lengths are the same, so we compare the prefix itself. FEC1 has the lower prefix, so FEC1 wins 👑

A.2.9. Example 9 🌈

this one uses the Routing Instance ID to break the tie 🎀

FEC1: IS-IS on Node A gets a Prefix-SID Advertisement from Node B for 203.0.113.114/32 with index=14. Assume this IS-IS instance on Node A has Routing Instance ID = 1000 and SRGB = [1000,1999]. So the incoming label for 203.0.113.114/32 on Node A is 1014 ✨

FEC2: IS-IS on Node A gets a Prefix-SID Advertisement from Node C for 203.0.113.114/32 with index=14. Assume this is another instance of IS-IS on Node A, with Routing Instance ID = 2000, which is different, and SRGB = [1000,1999], which is the same. So 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 the prefix. So the Routing Instance ID breaks the tie, and FEC1 wins 🫶

A.2.10. Example 10 🧚

this one uses the topology ID to settle things 🦋

FEC1: IS-IS on Node A gets a Prefix-SID Advertisement from Node B for 203.0.113.115/32 with index=15. Assume this IS-IS instance on Node A has Routing Instance ID = 1000. Assume the prefix advertisement for 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 is [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 gets a Prefix-SID Advertisement from Node C for 203.0.113.115/32 with index=15. Assume 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 is [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, the prefix, and the Routing Instance ID, we compare the IS-IS Multi-topology ID. So FEC2 wins 💜

A.2.11. Example 11 🔥

this one resolves the collision based on the algorithm ID 🧠

FEC1: IS-IS on Node A gets a Prefix-SID Advertisement from Node B for 203.0.113.116/32 with index=16. Assume IS-IS on Node A has Routing Instance ID = 1000. Assume Node B advertised 203.0.113.116/32 with IS-IS Multi-topology ID = 50 and SR algorithm = 0. Assume the IS-IS SRGB on Node A is [1000,1999]. So the incoming label corresponding to this advertisement of 203.0.113.116/32 is 1016 🌈

FEC2: IS-IS on Node A gets a Prefix-SID Advertisement from Node C for 203.0.113.116/32 with index=16. Assume it is the same IS-IS instance on Node A, with Routing Instance ID = 1000. Also assume 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 is [1000,1999]. So 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, the prefix, the Routing Instance ID, and the Multi-topology ID, we compare the SR algorithm IDs. So FEC1 wins ✨

A.2.12. Example 12 🎀

this one shows resolution based on the FEC numerical value, no matter how the SID was assigned to the colliding FECs 🙈

FEC1: IS-IS on Node A gets a Prefix-SID Advertisement from Node B for 203.0.113.117/32 with index=17. Assume the IS-IS SRGB on Node A is [1000,1999], so 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 it is the same IS-IS instance, the SRGB = [1000,1999], and so the incoming label is 1017 🧁

Even though FEC1 comes from a normal Prefix-SID Advertisement and FEC2 is generated from a Mapping Server Advertisement, the origin is not used as a tiebreaking parameter. Both FECs use dynamic SID assignment, come from the same MCC, and have the same FEC type codepoint=120. Their prefix lengths are the same too. 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 💅

this one is collision resolution based on address family preference again, but this time with SR Policies 💫

FEC1: SR Policy Advertisement from the controller to Node A, with Endpoint address=2001:DB8:3000::100, color=100, SID-List=<S1, S2>, and the Binding-SID label=1020 🌙

FEC2: SR Policy Advertisement from the controller to Node A, with Endpoint address=192.0.2.60, color=100, SID-List=<S3, S4>, and the Binding-SID label=1020 ⭐

The FEC tiebreakers match, and both have FEC type codepoint=140. So FEC2 wins, because the IPv4 address family is preferred over IPv6 👑

A.2.14. Example 14 🦋

last one in this group: this shows resolution based on the numerical value of the policy endpoint 🥹

FEC1: SR Policy Advertisement from the controller to Node A, with 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, with 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. So 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 has examples showing how incoming label collision affects which outgoing label gets selected, as described in Section 2.6 ✨

A.3.1. Example 1

okay so this one is about how the incoming label resolution changes the outgoing label 🦋✨

FEC1 first: IS-IS on Node A gets a Prefix-SID Advertisement from Node B for 203.0.113.122/32 with index=22. If the IS-IS SRGB on Node A is [1000,1999], the incoming label comes out to 1022 🌸

FEC2 next: IS-IS on Node A gets a Prefix-SID Advertisement from Node C for 203.0.113.222/32 with index=22. Same SRGB, [1000,1999], so the incoming label is also 1022 👀

Now the tiebreaker: FEC1 wins because it has the lowest numerical prefix value 🏆 So Node A installs a transit MPLS forwarding entry that swaps incoming label 1022 for outgoing label N and uses outgoing interface I. The value of N comes from the index tied to FEC1 (index=22) plus 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 for FEC1, matching incoming prefix 203.0.113.122/32, pushing outgoing label N and using outgoing interface I. Generally, so don't freak if your implementation looks a little different 🫶

And here's the part that matters: the rule in Section 2.6 means Node A MUST NOT install an ingress MPLS forwarding entry for FEC2, which is the losing FEC for prefix 203.0.113.222/32. No ingress entry for the loser, period 🚫💀

A.3.2. Example 2

This one is the same collision drama, but for outgoing label programming on Node A 🎀

FEC1: an SR Policy Advertisement from the controller to Node A with Endpoint address=192.0.2.80, color=100, SID-List=<S1, S2>, and Binding-SID label=1023.

FEC2: another SR Policy Advertisement from the controller to Node A with 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 🥇 So Node A installs a transit MPLS forwarding entry that swaps incoming label=1023 for outgoing labels, and the outgoing interface comes from the SID-List for FEC1 ✨

Now let's add some BGP/VPN routes to the mix 🧚

R1 has VPN label=V1, BGP next hop=192.0.2.80, and color=100.

R2 has VPN label=V2, BGP next hop=192.0.2.81, and color=100.

Node A also has a BGP policy that matches color=100 and allows it to be used as Service Level Agreement (SLA) steering information. Given all that, Node A will install a VPN route with label stack=<S1,S2,V1>, which corresponds 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>, which corresponds to FEC2. So FEC2 gets benched, no exceptions 🙅‍♀️

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 🫶🌈 the people who made this doc better, iykyk

Contributors

The following contributors have substantially helped the definition and editing of the content of this document. They're the real MVPs 👑

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

📦 where this page comes from