RFC 8663

MPLS Segment Routing over IP

📅 published December 2019, from ietf

MPLS Segment Routing over IP 💖

RFC 8663 🎀 Standards Track, ISSN 2070-1721, December 2019 Published by the Internet Engineering Task Force (IETF) 🌸 Authors: X. Xu (Alibaba, Inc), S. Bryant (Futurewei Technologies), A. Farrel (Old Dog Consulting), S. Hassan (Cisco), W. Henderickx (Nokia), Z. Li (Huawei) 👑 The header doesn't list anything this RFC obsoletes or updates ✨

Abstract 🌸

okay so MPLS Segment Routing (SR-MPLS) is a way of source routing a packet through an MPLS data plane. The sender basically stacks MPLS labels onto the packet to spell out the path, plus any packet-specific instructions it should carry out along the way 🧚. SR-MPLS can be used to make a source-routing mechanism that works across MPLS, IPv4, and IPv6 data planes, and it does this by treating an MPLS label stack as the source-routing instruction set. The best part is that it changes nothing in the SR-MPLS specs and still plays nicely with SR-MPLS implementations 💅.

This document explains how SR-MPLS-capable routers and IP-only routers can live together and interoperate smoothly, using SR-MPLS label stacks plus IP encapsulation or tunneling such as MPLS-over-UDP, which is defined in RFC 7510 🦋.

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 give feedback on it can be found at https://www.rfc-editor.org/info/rfc8663 🔗

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.  Terminology
2.  Use Cases
3.  Procedures of SR-MPLS-over-IP
  3.1.  Forwarding Entry Construction
    3.1.1.  FIB Construction Example
  3.2.  Packet-Forwarding Procedures
    3.2.1.  Packet Forwarding with Penultimate Hop Popping
    3.2.2.  Packet Forwarding without Penultimate Hop Popping
    3.2.3.  Additional Forwarding Procedures
4.  IANA Considerations
5.  Security Considerations
6.  References
  6.1.  Normative References
  6.2.  Informative References
Acknowledgements
Contributors
Authors' Addresses

1. Introduction ✨

okay so MPLS Segment Routing (SR-MPLS) [RFC8660] is a way of source routing a packet through an MPLS data plane. The sender imposes a stack of MPLS labels that partially or completely spell out the path the packet takes, plus any instructions to run on it as it moves through the network 🛤️. SR-MPLS uses that MPLS label stack to encode a sequence of source-routing instructions. This can power a source-routing mechanism that works across MPLS, IPv4, and IPv6 data planes. It changes nothing in the SR-MPLS specs and still allows interworking with SR-MPLS implementations 🫶. To be specific, the source-routing instructions in a source-routed packet can all be encoded in one uniform MPLS label stack, no matter whether the underlay is IPv4, IPv6 (including Segment Routing for IPv6 (SRv6) [RFC8354]), or MPLS 🌈.

This document explains how SR-MPLS-capable routers and IP-only routers can seamlessly coexist and interoperate, using SR-MPLS label stacks plus IP encapsulation or tunneling such as MPLS-over-UDP [RFC7510] 🦋.

Section 2 covers the different use cases for tunneling SR-MPLS over IP. Section 3 walks through a typical application scenario and how the packet forwarding happens 🧚.

1.1. Terminology 📖

This memo uses the terms defined in [RFC3031] and [RFC8660].

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. Use Cases 🦋

Tunneling SR-MPLS over IPv4 and/or IPv6 tunnels (including SRv6) is useful in at least the use cases below. In every case, you can enable it with an IP tunneling mechanism like MPLS-over-UDP, as described in [RFC7510] ✨. The tunnel you pick MUST have its remote endpoint (destination) address equal to the address of the next node capable of SR-MPLS that's identified as being on the SR path, which is the egress of the active segment 🎯. The local endpoint (source) address is set to an address of the encapsulating node. [RFC7510] gives further advice on how to set the source address if the UDP zero-checksum mode is used with MPLS-over-UDP. Using UDP as the encapsulation can be especially handy because it doesn't care what the underlying transport is 🌸.

  • Incremental deployment of SR-MPLS can be made easier by tunneling SR-MPLS packets across parts of a network that aren't SR-MPLS, as Figure 1 shows 🍓. This shows how islands of SR-MPLS can be connected across a legacy network, and it may be especially useful for joining sites (such as data centers) 🏝️.
                   ________________________
       _______    (                        )    _______
      (       )  (        IP Network        )  (       )
     ( SR-MPLS )(                            )( SR-MPLS )
    (  Network  )(                          )(  Network  )
   (         --------                          --------         )
   (        | Border |    SR-in-UDP Tunnel    | Border |        )
   (        | Router |========================| Router |        )
   (        |   R1   |                        |   R2   |        )
   (         --------                          --------         )
    (           ) (                              ) (           )
     (         )   (                            )   (         )
      (_______)     (                          )     (_______)
                     (________________________)

       Figure 1: SR-MPLS-over-UDP to Tunnel between SR-MPLS Sites
  • If the encoding of entropy [RFC6790] is desired, IP-tunneling mechanisms that allow entropy to be encoded can be used. An example is MPLS-over-UDP encapsulation [RFC7510], where the source port of the UDP header serves as the entropy field 💎. This helps maximize the use of Equal-Cost Multipath (ECMP) and/or Link Aggregation Groups (LAGs), especially when the entropy-label mechanism is hard to use 🧠. This is different from [RFC4023], where MPLS-over-IP doesn't provide an entropy mechanism. Refer to [RFC8662]) for more discussion about using entropy labels in SR-MPLS 📚.
  • Tunneling MPLS over IP gives you a technology that enables Segment Routing (SR) in an IPv4 and/or IPv6 network where the routers don't support SRv6 capabilities [IPv6-SRH] and where MPLS forwarding isn't an option 🌈. This is shown in Figure 2 🧚.
                 __________________________________
              __(           IP Network             )__
           __(                                        )__
          (               --        --        --         )
     --------   --   --  |SR|  --  |SR|  --  |SR|  --   --------
    | Ingress| |IR| |IR| |  | |IR| |  | |IR| |  | |IR| | Egress|
 -->| Router |===========|  |======|  |======|  |======| Router|-->
    |   SR   | |  | |  | |  | |  | |  | |  | |  | |  | |   SR  |
     --------   --   --  |  |  --  |  |  --  |  |  --   --------
          (__             --        --        --       __)
             (__                                    __)
                (__________________________________)

   Key:
     IR : IP-only Router
     SR : SR-MPLS-capable Router
     == : SR-MPLS-over-UDP Tunnel

           Figure 2: SR-MPLS Enabled within an IP Network

3. Procedures of SR-MPLS-over-IP 🛠️

This section describes how to build forwarding information base (FIB) entries and the forwarding behavior that lets you deploy SR-MPLS when some routers in the network are IP only (meaning they don't support SR-MPLS) 🌸. Heads up: the examples in Sections 3.1.1 and 3.2 assume that OSPF or IS-IS is enabled. In reality, other discovery and advertisement mechanisms could be used too, including other routing protocols (such as BGP) or a central controller 🎀.

3.1. Forwarding Entry Construction ✨

Okay so this subsection is all about how to build the forwarding information base (FIB) entry 🧚 on an SR-MPLS-capable router when some or all of the next hops along the shortest path towards a prefix Segment Identifier (Prefix-SID) are IP-only routers. Section 3.1.1 walks through a real example with OSPF or IS-IS, so bestie, peek at that too 🫶

Let's say router A gets a labeled packet whose top label is L(E). That label matches the Prefix-SID SID(E) for prefix P(E), which router E advertised. Now suppose the i-th next-hop router (called NHi) on the shortest path from router A to SID(E) is not SR-MPLS capable, but both A and E are. Here's the process, no cap 💅

  • Router E is SR-MPLS capable, so it advertises a Segment Routing Global Block (SRGB). The SRGB is defined in [RFC8402]. There are a bunch of ways that advertisement can happen, including IGPs, BGP, and configuration/management protocols. For example, see [DC-GATEWAY].
  • When Router E advertises the Prefix-SID SID(E) of prefix P(E), it MUST also advertise the egress endpoint address and the encapsulation type of any tunnel used to reach E. This information gets flooded domain wide 🌈
  • If A and E are in different routing domains, then the information MUST be flooded into both domains. How that happens depends on the advertisement mechanism being used. The goal is for router A to know the characteristics of router E, the one that originated the advertisement of SID(E) 🎀
  • Router A programs the FIB entry for prefix P(E) that corresponds to SID(E), depending on whether a pop or swap action is advertised for the prefix. The resulting action may be:
    • pop the top label
    • swap the top label to a value equal to SID(E) plus the lower bound of the SRGB of E

Once the FIB is constructed, a router can use it to figure out how to process packets. It encapsulates the packets according to the appropriate encapsulation advertised for the segment, and then sends them towards the next hop NHi. Slay 🦋

3.1.1. FIB Construction Example 💅

This section is non-normative and gives a worked example of how a FIB might be built using OSPF and IS-IS extensions. It's based on the process described in Section 3.1 🌸

  • Router E is SR-MPLS capable, so it advertises a Segment Routing Global Block (SRGB) using [RFC8665] or [RFC8667].
  • When Router E advertises the Prefix-SID SID(E) of prefix P(E), it also advertises the encapsulation endpoint address and the tunnel type of any tunnel used to reach E using [ISIS-ENCAP] or [OSPF-ENCAP].
  • If A and E are in different domains, then the information is flooded into both domains and any intervening domains.
    • The OSPF Tunnel Encapsulations TLV [OSPF-ENCAP] or the IS-IS Tunnel Encapsulation Type sub-TLV [ISIS-ENCAP] is flooded domain wide.
    • The OSPF SID/Label Range TLV [RFC8665] or the IS-IS SR-Capabilities sub-TLV [RFC8667] is advertised domain wide so that router A knows the characteristics of router E.
    • When router E advertises the prefix P(E):
      • If router E is running IS-IS, it uses the extended reachability TLV (TLVs 135, 235, 236, 237) and associates the IPv4/IPv6 or IPv4/IPv6 Source Router ID sub-TLV(s) [RFC7794].
      • If router E is running OSPF, it uses the OSPFv2 Extended Prefix Opaque Link-State Advertisement (LSA) [RFC7684] and sets the flooding scope to Autonomous System (AS) wide.
    • If router E is running IS-IS and advertises the IS-IS Router CAPABILITY TLV (TLV 242) [RFC7981], it sets the "Router ID" field to a valid value or includes an IPv6 TE Router ID sub-TLV (TLV 12), or it does both. The "S" bit (flooding scope) of the IS-IS Router CAPABILITY TLV (TLV 242) is set to "1".
  • Router A programs the FIB entry for prefix P(E) corresponding to SID(E) depending on whether a pop or swap action is advertised for the prefix, as follows:
    • If the No-PHP (NP) Flag in OSPF or the Persistent (P) Flag in IS-IS is clear:
      • pop the top label
    • If the No-PHP (NP) Flag in OSPF or the Persistent (P) Flag in IS-IS is set:
      • swap the top label to a value equal to SID(E) plus the lower bound of the SRGB of E

When the router forwards a packet according to the constructed FIB entry, it encapsulates the packet according to the encapsulation advertised using the mechanisms described in [ISIS-ENCAP] or [OSPF-ENCAP]. Then it sends the packet towards the next hop NHi 🫧

Note that [RFC7510] specifies the use of port number 6635 to indicate that the payload of a UDP packet is MPLS, and port number 6636 for MPLS-over-UDP utilizing DTLS. However, [ISIS-ENCAP] and [OSPF-ENCAP] provide dynamic protocol mechanisms to configure the use of any Dynamic Port for a tunnel that uses UDP encapsulation. Nothing in this document prevents the use of an IGP or any other mechanism to negotiate the use of a Dynamic Port when UDP encapsulation is used for SR-MPLS. But if no such mechanism is used, then the port numbers specified in [RFC7510] are used 🍓

3.2. Packet-Forwarding Procedures 🦋

[RFC7510] specifies an IP-based encapsulation for MPLS, i.e., MPLS-over-UDP. This approach is for situations where IP-based encapsulation for MPLS is required and fine-grained load balancing of MPLS packets over IP networks across ECMP and/or LAGs is also needed. This section explains the forwarding procedure when UDP encapsulation is adopted for SR-MPLS-over-IP. Other encapsulation and tunneling mechanisms can be applied using similar techniques, but for clarity, this section uses UDP encapsulation as the example 💜

Nodes that are SR-MPLS capable can process SR-MPLS packets. Not all of the nodes in an SR-MPLS domain are SR-MPLS capable. Some nodes may be "legacy routers" that can't handle SR-MPLS packets but can forward IP packets. A node capable of SR-MPLS MAY advertise its capabilities using the IGP as described in Section 3. There are six types of nodes in an SR-MPLS domain 👑

  • Domain ingress nodes that receive packets and encapsulate them for transmission across the domain. Those packets may be any payload protocol, including native IP packets or packets that are already MPLS encapsulated.
  • Legacy transit nodes that are IP routers but that are not SR-MPLS capable (i.e., are not able to perform Segment Routing).
  • Transit nodes that are SR-MPLS capable but that are not identified by a SID in the SID stack.
  • Transit nodes that are SR-MPLS capable and need to perform SR-MPLS routing because they are identified by a SID in the SID stack.
  • The penultimate node capable of SR-MPLS on the path that processes the last SID on the stack on behalf of the domain egress node.
  • The domain egress node that forwards the payload packet for ultimate delivery.

3.2.1. Packet Forwarding with Penultimate Hop Popping 🌈

The description in this section assumes that the label associated with each Prefix-SID is advertised by the owner of the Prefix-SID as a Penultimate Hop-Popping (PHP) label. That is, if one of the IGP flooding mechanisms is used, the NP-Flag in OSPF or the P-Flag in IS-IS associated with the Prefix-SID is not set 🧚

      +-----+       +-----+       +-----+       +-----+       +-----+
      |  A  +-------+  B  +-------+  C  +-------+  D  +-------+  H  |
      +-----+       +--+--+       +--+--+       +--+--+       +-----+
                       |             |             |
                       |             |             |
                    +--+--+       +--+--+       +--+--+
                    |  E  +-------+  F  +-------+  G  |
                    +-----+       +-----+       +-----+


           +--------+
           |IP(A->E)|
           +--------+                 +--------+        +--------+
           |  UDP   |                 |IP(E->G)|        |IP(G->H)|
           +--------+                 +--------+        +--------+
           |  L(G)  |                 |  UDP   |        |  UDP   |
           +--------+                 +--------+        +--------+
           |  L(H)  |                 |  L(H)  |        |Exp Null|
           +--------+                 +--------+        +--------+
           | Packet |     --->        | Packet |  --->  | Packet |
           +--------+                 +--------+        +--------+

Figure 3: Packet-Forwarding Example with PHP

In the example shown in Figure 3, routers A, E, G, and H are capable of SR-MPLS, while the remaining routers (B, C, D, and F) are only capable of forwarding IP packets. Routers A, E, G, and H advertise their Segment Routing related information, such as via IS-IS or OSPF 🦋

Now let's say router A (the Domain ingress) wants to send a packet to router H (the Domain egress) via the explicit path {E->G->H}. Router A imposes an MPLS label stack on the packet that corresponds to that explicit path. Since the next hop toward router E is only IP capable (B is a legacy transit node), router A replaces the top label (the one that indicated router E) with a UDP-based tunnel for MPLS (i.e., MPLS-over-UDP [RFC7510]) to router E, and then sends the packet. In other words, router A pops the top label and then encapsulates the MPLS packet in a UDP tunnel to router E 💖

When the IP-encapsulated MPLS packet arrives at router E (which is a transit node capable of SR-MPLS), router E strips the IP-based tunnel header and then processes the decapsulated MPLS packet. The top label indicates that the packet must be forwarded toward router G. Since the next hop toward router G is only IP capable, router E replaces the current top label with an MPLS-over-UDP tunnel toward router G and sends it out. That is, router E pops the top label and then encapsulates the MPLS packet in a UDP tunnel to router G 🌸

When the packet arrives at router G, router G strips the IP-based tunnel header and then processes the decapsulated MPLS packet. The top label indicates that the packet must be forwarded toward router H. Since the next hop toward router H is only IP capable (D is a legacy transit router), router G would replace the current top label with an MPLS-over-UDP tunnel toward router H and send it out. However, since router G reaches the bottom of the label stack (G is the penultimate node capable of SR-MPLS on the path), this would leave the original packet that router A wanted to send to router H encapsulated in UDP as if it was MPLS (i.e., with a UDP header and destination port indicating MPLS), even though the original packet could have been any protocol. That is, the final SR-MPLS label has been popped, exposing the payload packet 😭

To handle this, when a router (here, router G) pops the final SR-MPLS label, it inserts an explicit NULL label [RFC3032] before encapsulating the packet in an MPLS-over-UDP tunnel toward router H and sending it out. That is, router G pops the top label, discovers it has reached the bottom of the stack, pushes an explicit NULL label, and then encapsulates the MPLS packet in a UDP tunnel to router H ✨

3.2.2. Packet Forwarding without Penultimate Hop Popping

okay so this is the no-PHP version 💖 Figure 4 walks through a packet when the label that the Prefix-SID owner advertises for each Prefix-SID is not a Penultimate Hop-Popping (PHP) label. That's the case when the NP-Flag in OSPF or the P-Flag in IS-IS on that Prefix-SID is set 🎀. Apart from the PHP function, the router roles are exactly the same as in Section 3.2.1 ✨.

     +-----+       +-----+       +-----+        +-----+        +-----+
     |  A  +-------+  B  +-------+  C  +--------+  D  +--------+  H  |
     +-----+       +--+--+       +--+--+        +--+--+        +-----+
                      |             |              |
                      |             |              |
                   +--+--+       +--+--+        +--+--+
                   |  E  +-------+  F  +--------+  G  |
                   +-----+       +-----+        +-----+

          +--------+
          |IP(A->E)|
          +--------+                 +--------+
          |  UDP   |                 |IP(E->G)|
          +--------+                 +--------+        +--------+
          |  L(E)  |                 |  UDP   |        |IP(G->H)|
          +--------+                 +--------+        +--------+
          |  L(G)  |                 |  L(G)  |        |  UDP   |
          +--------+                 +--------+        +--------+
          |  L(H)  |                 |  L(H)  |        |  L(H)  |
          +--------+                 +--------+        +--------+
          | Packet |     --->        | Packet |  --->  | Packet |
          +--------+                 +--------+        +--------+

Figure 4: Packet-Forwarding Example without PHP 🦋

So the vibe is that the SR-MPLS label for each segment just chills in place until the end of that segment 🧚. That's where it gets popped and the next instruction gets processed. Main character energy for that label, honestly 💅

3.2.3. Additional Forwarding Procedures

Non-MPLS Interfaces: Okay so the last two sections were mostly about Prefix-SIDs, but tunneling SR-MPLS packets is also useful in a different case 🌸. When the top label of a received SR-MPLS packet points to an Adjacency SID, and the adjacent node for that Adjacency SID can't do MPLS forwarding but can still process SR-MPLS packets, the top label gets swapped for an IP tunnel toward that adjacent node. Then the packet goes out over the link that the Adjacency SID points to 🫶.

When to Use IP-Based Tunnels: The last two sections assume that an MPLS-over-UDP tunnel is used when the next hop toward the next segment isn't MPLS enabled 💜. But plot twist: even when the next hop IS MPLS capable, an MPLS-over-UDP tunnel toward the next segment could still be used instead, because of local policies ✨. Say, for example, in the Figure 4 setup, F is now a transit node that's capable of SR-MPLS and everything else stays the same 🎀. F isn't identified by a SID in the stack, and the local policy prefers an MPLS-over-UDP tunnel over an MPLS LSP. So router E swaps the current top label for an MPLS-over-UDP tunnel toward router G and sends it out 🦋. (Note that if an MPLS LSP was preferred, the packet would just be forwarded as native SR-MPLS 💅.)

IP Header Fields: When an MPLS packet gets encapsulated in UDP, the result is then encapsulated in IP for transmission 🌈. IPv4 or IPv6 can be used, depending on what the network supports. The address fields are set as described in Section 2 🌸. For the other IP header fields, like the ECN field [RFC6040], the Differentiated Services Code Point (DSCP) [RFC2983], or the IPv6 Flow Label, the operator's policy SHOULD be the thing that decides how they're configured on each UDP-encapsulated segment 💖. They may be copied from the header of the incoming packet. They may be promoted from the header of the payload packet. They may be set according to instructions programmed to be associated with the SID. Or they may be configured based on the outgoing interface and payload 🫶. The TTL field setting in the encapsulating packet header is handled as described in [RFC7510], which refers to [RFC4023] 🧚.

Entropy and ECMP: When an MPLS packet is encapsulated with an IP tunnel header that can encode entropy (like [RFC7510]), the matching entropy field (the source port, in the case of a UDP tunnel) MAY be filled with an entropy value. The encapsulator generates that value to uniquely identify a flow 💜. What counts as a flow is decided locally by the encapsulator though, so it's kind of a personal choice 🙈. For example, if the MPLS label stack has at least one entropy label and the encapsulator can read that entropy label, the entropy label value could be copied straight into the source port of the UDP header ✨. If not, the encapsulator may have to do a hash on the whole label stack, or on the five-tuple of the SR-MPLS payload if the payload is determined to be an IP packet 😭. To avoid recalculating the hash or hunting for the entropy label every time the packet gets encapsulated in a UDP tunnel, it MAY be desirable to keep the entropy value from the incoming packet (that's the UDP source port value). You'd keep it when stripping the UDP header and reuse it as the entropy value of the outgoing packet 💅.

Congestion Considerations: Section 5 of [RFC7510] gives a detailed look at congestion in MPLS-over-UDP systems, and it builds on Section 3.1.3 of [RFC8085], which covers the congestion implications of UDP tunnels 🌊. All of those considerations apply to SR-MPLS-over-UDP tunnels as described in this document. In particular, it should be noted that the traffic carried in SR-MPLS flows is likely to be IP traffic 🦋.

4. IANA Considerations

This document has no IANA actions. 🌸 Nothing to register here, bestie, so we're all good ✨.

5. Security Considerations

Okay this section is SERIOUS, so pay attention 😭🚨

The security considerations of [RFC8354] (which redirects the reader to [RFC5095]) and [RFC7510] apply here 🔥. DTLS [RFC6347] SHOULD be used wherever security is needed on an SR-MPLS-over-UDP segment, including when the IP segment crosses the public Internet or some other untrusted environment 🔐. [RFC8402] covers security considerations for Segment Routing, and Section 8.1 of [RFC8402] is especially relevant to SR-MPLS 💜.

It's hard for an attacker to push a raw MPLS-encoded packet into a network. Operators also have a lot of experience keeping these packets out at network boundaries. For example, they exclude all packets revealed to be carrying an MPLS packet as the payload of IP tunnels 🧱. More on MPLS security can be found in [RFC5920] 🎀.

It's easy for a network ingress node to spot any attempt to smuggle an IP packet into the network, because it would see that the UDP destination port was set to MPLS. Such filtering SHOULD be applied 🛡️. But heads up: if the mechanisms described in [RFC8665] or [RFC8667] are applied, a wider variety of UDP port numbers might be in use, which makes port filtering harder 🙈.

SR packets that don't have a destination address terminating in the network would be carried transparently. They would pose no different security risk to the network under consideration than any other traffic 🌈.

Where control-plane techniques are used (as described in Section 3), it's important that these protocols are adequately secured for the environment they run in, as discussed in [RFC6862] and [RFC5920] 👑.

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

[RFC4023]  Worster, T., Rekhter, Y., and E. Rosen, Ed.,
           "Encapsulating MPLS in IP or Generic Routing Encapsulation
           (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005,
           <https://www.rfc-editor.org/info/rfc4023>.

[RFC5095]  Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
           of Type 0 Routing Headers in IPv6", RFC 5095,
           DOI 10.17487/RFC5095, December 2007,
           <https://www.rfc-editor.org/info/rfc5095>.

[RFC6040]  Briscoe, B., "Tunnelling of Explicit Congestion
           Notification", RFC 6040, DOI 10.17487/RFC6040, November
           2010, <https://www.rfc-editor.org/info/rfc6040>.

[RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
           Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
           January 2012, <https://www.rfc-editor.org/info/rfc6347>.

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

[RFC7684]  Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
           Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
           Advertisement", RFC 7684, DOI 10.17487/RFC7684, November
           2015, <https://www.rfc-editor.org/info/rfc7684>.

[RFC7794]  Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and
           U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4
           and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794,
           March 2016, <https://www.rfc-editor.org/info/rfc7794>.

[RFC7981]  Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions
           for Advertising Router Information", RFC 7981,
           DOI 10.17487/RFC7981, October 2016,
           <https://www.rfc-editor.org/info/rfc7981>.

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

[RFC8660]  Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
           Litkowski, S., and R. Shakir, "Segment Routing with the
           MPLS Data Plane", RFC 8660, DOI 10.17487/RFC8660, December
           2019, <https://www.rfc-editor.org/info/rfc8660>.

6.2. Informative References ✨

okay bestie, these are the informative references, the "go read this if you want the deep dive" pile 📚💅 they're not required reading to implement the spec, but they're the receipts 🧾

Acknowledgements 🙏

Huge thanks to Joel Halpern, Bruno Decraene, Loa Andersson, Ron Bonica, Eric Rosen, Jim Guichard, Gunter Van De Velde, Andy Malis, Robert Sparks, and Al Morton for their insightful comments on this document. 🫶

Additional thanks to Mirja Kuehlewind, Alvaro Retana, Spencer Dawkins, Benjamin Kaduk, Martin Vigoureux, Suresh Krishnan, and Eric Vyncke for careful reviews and resulting comments. 🌸

Contributors 💜

These are the people who helped shape the document, and they're all absolutely iconic 👑

Ahmed Bashandy
Individual
Email: abashandy.ietf@gmail.com

Clarence Filsfils
Cisco
Email: cfilsfil@cisco.com

John Drake
Juniper
Email: jdrake@juniper.net

Shaowen Ma
Mellanox Technologies
Email: mashaowen@gmail.com

Mach Chen
Huawei
Email: mach.chen@huawei.com

Hamid Assarpour
Broadcom
Email:hamid.assarpour@broadcom.com

Robert Raszuk
Bloomberg LP
Email: robert@raszuk.net

Uma Chunduri
Huawei
Email: uma.chunduri@gmail.com

Luis M. Contreras
Telefonica I+D
Email: luismiguel.contrerasmurillo@telefonica.com

Luay Jalil
Verizon
Email: luay.jalil@verizon.com

Gunter Van De Velde
Nokia
Email: gunter.van_de_velde@nokia.com

Tal Mizrahi
Marvell
Email: talmi@marvell.com

Jeff Tantsura
Apstra, Inc.
Email: jefftant.ietf@gmail.com

Authors' Addresses 🦋

And last but definitely not least, the authors who put this whole thing together ✨🧚

Xiaohu Xu
Alibaba, Inc

Email: xiaohu.xxh@alibaba-inc.com


Stewart Bryant
Futurewei Technologies

Email: stewart.bryant@gmail.com


Adrian Farrel
Old Dog Consulting

Email: adrian@olddog.co.uk


Syed Hassan
Cisco

Email: shassan@cisco.com


Wim Henderickx
Nokia

Email: wim.henderickx@nokia.com


Zhenbin Li
Huawei

Email: lizhenbin@huawei.com
📦 where this page comes from