RFC 8595
An MPLS-Based Forwarding Plane for Service Function Chaining
An MPLS-Based Forwarding Plane for Service Function Chaining 🦋
- RFC number and title: RFC 8595, An MPLS-Based Forwarding Plane for Service Function Chaining 🎀
- Authors: A. Farrel (Old Dog Consulting), S. Bryant (Futurewei), J. Drake (Juniper Networks) 💅
- Stream: Internet Engineering Task Force (IETF) 🌸
- Category: Standards Track ⭐
- ISSN: 2070-1721
- Date: June 2019 📅
- Obsoletes and updates: the title block doesn't list anything this document obsoletes or updates 🙈
Abstract ✨
okay so this doc is all about how we can do Service Function Chaining (SFC) over an MPLS network 🧚 the trick is that we don't use the NSH itself. instead, we take the NSH's fields and map them onto the fields in the MPLS label stack. it's like a logical NSH wearing MPLS labels as a disguise 🎭 this doesn't deprecate or replace the NSH, bestie. it just admits that some networks are brownfield (old and already built), so there might be a need for an interim deployment of SFC functionality there 🫶
Status of This Memo 🌈
this is an Internet Standards Track document. ✨
it's a product of the IETF, so it represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 👑 if you want more info on Internet Standards, check out Section 2 of RFC 7841 📚
for the current status, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc8595 💌
Copyright Notice 💜
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 (https://trustee.ietf.org/license-info), as they stood on the publication date. please read these carefully, because they explain your rights and restrictions for this document 🙏 and if you pull Code Components out of this document, they have to include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions. they come without warranty, as the Simplified BSD License describes 🔥
Table of Contents 🍓
1. Introduction ....................................................3
2. Requirements Language ...........................................4
3. Choice of Data-Plane SPI/SI Representation ......................4
4. Use Case Scenarios ..............................................5
4.1. Label Swapping for Logical NSH .............................5
4.2. Hierarchical Encapsulation .................................5
4.3. Fine Control of Service Function Instances .................6
4.4. Micro Chains and Label Stacking ............................6
4.5. SFC and Segment Routing ....................................6
5. Basic Unit of Representation ....................................6
6. MPLS Label Swapping .............................................7
7. MPLS Label Stacking ............................................10
8. Mixed-Mode Forwarding ..........................................12
9. A Note on Service Function Capabilities and SFC Proxies ........13
10. Control-Plane Considerations ..................................14
11. Use of the Entropy Label ......................................14
12. Metadata ......................................................15
12.1. Indicating Metadata in User Data Packets .................16
12.2. In-Band Programming of Metadata ..........................18
12.2.1. Loss of In-Band Metadata ..........................21
13. Worked Examples ...............................................22
14. Implementation Notes ..........................................26
15. Security Considerations .......................................26
16. IANA Considerations ...........................................28
17. References ....................................................29
17.1. Normative References .....................................29
17.2. Informative References ...................................30
Acknowledgements ..................................................31
Contributors ......................................................31
Authors' Addresses ................................................321. Introduction 🎀
okay bestie, Service Function Chaining (SFC) is the process of directing packets through a network so they get acted on by an ordered set of abstract Service Functions (SFs) before they reach the intended destination ✨ the architecture for SFC is defined in [RFC7665] 📖
when you apply a particular service function chain to traffic picked out by a service classifier, that traffic needs to be steered through an ordered set of SFs in the network 🦋 this ordered set is called a Service Function Path (SFP). the traffic gets passed between Service Function Forwarders (SFFs), which are in charge of delivering packets to the SFs and forwarding them on to the next SFF 💅
to steer the selected traffic between SFFs and to the right SFs, the service classifier has to attach information to each packet 🧚 this info tells you which SFP the packet is being forwarded on, and therefore which SFs it must be delivered to. it also shows how far the packet has already gotten along the SFP 🌸
the Network Service Header (NSH) [RFC8300] was defined to carry the info SFC needs in packets 💖 you can insert the NSH into packets, and it holds various info, including a Service Path Identifier (SPI), a Service Index (SI), and a Time To Live (TTL) counter 🍓
Multiprotocol Label Switching (MPLS) [RFC3031] is a widely deployed forwarding technology 🌈 it uses labels placed in a packet's label stack to identify the forwarding actions to take at each hop through a network. those actions can include swapping or popping labels, and using labels to figure out the next hop. labels can also set up the context the packet gets forwarded under 🫶 in lots of cases, MPLS gets used as a tunneling technology to carry packets between SFFs through networks 🚇
so this document describes how SFC can be achieved in an MPLS network by using a logical representation of the NSH in an MPLS label stack 🔥 this works for all forms of MPLS forwarding where labels are looked up at each hop and get swapped or popped [RFC3031]. it doesn't deprecate or replace the NSH, but it does acknowledge that there may be a need for an interim deployment of SFC functionality in brownfield networks 🏚️➡️✨ the mechanisms here are a compromise between the full function you get with the NSH and the perks of reusing the MPLS forwarding paradigms you already have. heads up: the approach defined here does not include the O bit defined in [RFC8300], and it has some limits on how metadata gets used, as described in Section 12 ⚠️
Section 4 gives a quick overview of several use case scenarios that show how the MPLS label operations (swapping, popping, stacking) relate to the MPLS encoding of the logical NSH described here 💅
it's assumed you already know the terms and concepts from [RFC7665] and [RFC8300], bestie 🧠
oh, and one of the features of the SFC architecture in [RFC7665] is the "SFC proxy" 🙈 it exists to include legacy SFs that can't process NSH-encapsulated packets. this same issue applies just as much to MPLS-encapsulated packets that carry a logical representation of an NSH, so we talk about it more in Section 9 💜
2. 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 read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, just like this 🎀
3. Choice of Data-Plane SPI/SI Representation 🦋
[RFC8300] defines the NSH that can be used in a bunch of environments, but this document gives you a mechanism for when the NSH isn't ubiquitously deployed ✨ in that case, you can use an alternative data-plane representation of the SPI/SI by carrying the identical semantics in MPLS labels 🌸
to pick the right mechanism for encoding and carrying SFC info between SFFs, it may be necessary to configure the capabilities and choices either across the whole Service Function Overlay Network or on a hop-by-hop basis 🧚 here's the big requirement: both ends of a tunnel over the underlay network (so, a pair of SFFs that are adjacent in the SFP) have to know that the tunnel is used for SFC, and they have to know which form of NSH representation is in use 🔥 a control-plane signaling approach for these objectives is provided using BGP in [BGP-NSH-SFC] 💌
also, the encoding of the SFC info is independent of the tunneling technology used between SFFs 🫶 so an MPLS representation of the logical NSH (as defined here) may be used even when the tunnel between a pair of SFFs isn't an MPLS tunnel. and the other way around: MPLS tunnels may carry other encodings of the logical NSH, specifically the NSH itself 🍓
4. Use Case Scenarios ✨
okay so there are five scenarios you can look at for using an MPLS encoding to support SFC 🌈 they're laid out in the subsections below 💅
4.1. Label Swapping for Logical NSH 🔁
the main use case for SFC is described in [RFC7665] and delivered using the NSH. as [RFC8300] explains, the NSH uses an encapsulation with a position indicator that gets modified at each SFC hop along the chain to show the next hop 🦋
the label-swapping scenario basically swaps the NSH out for an MPLS encapsulation, as described in Section 6 💖 the MPLS labels encode the same info as the NSH, forming a logical NSH. the labels get modified (swapped per [RFC3031]) at each SFC hop along the chain to point at the next hop. the processing and the forwarding state for a chain (meaning the actions to take on a received label) get programmed into the network using a control plane or management plane 🧠
4.2. Hierarchical Encapsulation 🪆
[RFC8459] describes an architecture for hierarchical encapsulation using the NSH 🌸 it lets you partition SFC domains for administrative reasons, and it allows concatenation of service function chains under the control of a service classifier 👑
the same function can be achieved in an MPLS network using an MPLS encoding of the logical NSH, plus label stacking as defined in [RFC3031] and described in Section 7 🧚 in this model, swapping is used per Section 4.1 to navigate one chain. when the end of the chain is reached, the final label gets popped, revealing the label for another chain. so the primary mode is swapping, but stacking is used to let the ingress classifier control concatenation of service function chains 🎀
4.3. Fine Control of Service Function Instances
Okay so, a service function chain (the one from Section 4.1) gives you some wiggle room in picking which service function instances you hit along the way. 🦋 But sometimes a service classifier wants to be the boss and actually constrain that choice! Bestie, the trick is chain concatenation: the first chain ends right at the point of choice, the next label in the stack names the exact service function instance to run, and then the label after that starts a brand new chain. So you get a mix of label swapping and stacking, and it's giving control freak energy in the best way 💅✨
4.4. Micro Chains and Label Stacking
Okay this one is the ultimate extension of Section 4.2 🌸 You make every concatenated chain as short as humanly possible: just one SF. Each label in the stack points at the next SF to run, and the network gets programmed through the control plane or the management plane so it knows how to route to that next (aka first) hop in each chain, exactly like it would for the scenarios in Sections 4.1 and 4.2. Iconic, honestly 🧚
This scenario is functionally identical to Segment Routing (SR) in an MPLS network (known as SR-MPLS) used for SFC, as described in Section 4.5, and everything said in that section applies here too 🫶
4.5. SFC and Segment Routing
SR-MPLS uses a stack of MPLS labels to encode the path and the network functions a packet should go through. 💜 It's achieved by applying control-plane and management-plane techniques to program the MPLS forwarding plane, and by imposing labels on packets when they enter the SR-MPLS network. If you want an implementation proposal for doing SFC with SR-MPLS, check out [SR-Srv-Prog]. This document won't dig into it any further 🙈
- Basic Unit of Representation
Okay so when an MPLS label stack is carrying a logical NSH, there's a basic unit of representation 🎀 It's made of two MPLS labels, shown below. You can have this unit show up one or more times in the label stack, as the later sections explain.
To carry the same info as the NSH, two MPLS label stack entries get used. One carries a label that gives context within the SFC scope (the SFC Context Label), and the other carries a label that says which SF gets actioned (the SF Label). Here's the two-label unit in Figure 1 🌈
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFC Context Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SF Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The Basic Unit of MPLS Label Stack for SFCNow the fields of these two label stack entries are encoded like this:
Label: The Label fields hold the values of the SFC Context Label and the SF Label, encoded as 20-bit integers. What these Label fields actually mean depends on whether the label stack entries are used for MPLS label swapping (see Section 6) or MPLS label stacking (see Section 7). 🦋
TC: The TC bits have no meaning in this case. They SHOULD be set to zero in both label stack entries when a packet is sent and MUST be ignored on receipt. 🙈
S: The "Bottom of Stack" bit has its usual MPLS meaning. It MUST be clear in the SFC Context Label stack entry. In the SF Label stack entry, it MUST be clear in all cases except when the label is the bottom of the stack, and then it MUST be set. 💅
TTL: The TTL field in the SFC Context Label stack entry SHOULD be set to 1. The TTL in the SF Label stack entry (called the SF TTL) gets set according to whether it's used for MPLS label swapping (see Section 6) or MPLS label stacking (see Section 7), and it's there to help mitigate packet loops. 🔥
Next up, the sections that follow show how this basic unit can be used for SFC in both the MPLS label-swapping case and the MPLS label-stacking case. To keep things simple, they don't cover metadata, which gets its own treatment in Section 12. 🧚
- MPLS Label Swapping
Okay so this section explains how the basic unit of MPLS label stack for SFC (introduced in Section 5) gets used when MPLS label swapping is happening. The use case for this approach was introduced in Section 4.1. 🌸
As you can see in Figure 2, the top of the label stack holds the labels needed to deliver the packet across the MPLS tunnel between SFFs. Basically any MPLS encapsulation works (MPLS, MPLS in UDP, MPLS in GRE, and MPLS in Virtual Extensible Local Area Networks (VXLANs) or the Generic Protocol Extension for VXLAN (GPE))! So the tunnel technology doesn't have to be MPLS, but MPLS is shown here for simplicity ✨
An entropy label [RFC6790] may also be present, as described in Section 11. 💜
---------------
~ Tunnel Labels ~
+---------------+
~ Optional ~
~ Entropy Label ~
+---------------+ - - -
| SPI Label |
+---------------+ Basic unit of MPLS label stack for SFC
| SI Label |
+---------------+ - - -
| |
~ Payload ~
| |
---------------
Figure 2: The MPLS SFC Label StackUnder these labels (or other encapsulation) sits a single instance of the basic unit of MPLS label stack for SFC. On top of what Section 5 says about these label stack entries, the following meanings apply 🎀
SPI Label: The Label field of the SFC Context Label stack entry holds the SPI, encoded as a 20-bit integer. The semantics of the SPI are exactly as defined in [RFC8300]. Heads up though: an SPI as defined by [RFC8300] can be encoded in 3 octets (i.e., 24 bits), but the Label field only has room for 20 bits, and it reserves the values 0 through 15 as "special-purpose labels" [RFC7274]. So a system using the MPLS representation of the logical NSH MUST NOT assign SPI values greater than 2^20 - 1 or less than 16. 😭
SI Label: The Label field of the SF Label stack entry holds the value of the SI, exactly as defined in [RFC8300]. The SI only needs 8 bits, and to avoid overlapping with the special-purpose label range of 0 through 15 [RFC7274], the SI lives in the top (most significant) 8 bits of the Label field, with the low-order 12 bits set to zero. 🌈
TC: The TC fields work as described in Section 5. 💅
S: The S bits work as described in Section 5. 💅
TTL: The TTL field in the SPI Label stack entry SHOULD be set to 1, as stated in Section 5. The TTL in the SF Label stack entry gets decremented once for each forwarding hop in the SFP (that is, once for each SFF transited), so it mirrors the TTL field in the NSH. 🦋
Okay, the following processing rules apply to the Label fields:
- When a classifier inserts a packet onto an SFP, it sets the SPI Label to indicate the identity of the SFP, and it sets the SI Label to indicate the first SF in the path. 🧚
- When a component of the SFC system processes a packet, it uses the SPI Label to identify the SFP and the SI Label to figure out which SFF or instance of an SF (an SFI) to deliver the packet to. Under normal circumstances (except for branching and reclassification, see [BGP-NSH-SFC]), the SPI Label value is preserved on all packets. The SI Label value gets modified by SFFs and through reclassification to point at the next hop along the SFP. 🫶
The following processing rules apply to the TTL field of the SF Label stack entry, and they're derived from Section 2.2 of [RFC8300]:
- When a classifier places a packet onto an SFP, it MUST set the TTL to a value between 1 and 255. It SHOULD set this according to the expected length of the SFP (i.e., the number of SFs on the SFP), but it MAY set it to a larger value according to local configuration. The maximum TTL value supported in an NSH is 63, so the practical limit here may also be 63. 🌸
- When an SFF receives a packet from any component of the SFC system (classifier, SFI, or another SFF), it MUST discard any packets with TTL set to zero. It SHOULD log such occurrences but MUST apply rate limiting to any such logs. 💀
- An SFF MUST decrement the TTL by one each time it performs a lookup to forward a packet to the next SFF. 🍓
- If an SFF decrements the TTL to zero, it MUST NOT send the packet and MUST discard the packet. It SHOULD log such occurrences but MUST apply rate limiting to any such logs. 😭
- SFIs MUST ignore the TTL but MUST mirror it back to the SFF unmodified along with the SI (which may have been changed by local reclassification). 👑
- If a classifier along the SFP makes any change to the intended path of the packet, including for looping, jumping, or branching (see [BGP-NSH-SFC]), it MUST NOT change the SI TTL of the packet. In particular, each component of the SFC system MUST NOT increase the SI TTL value, otherwise loops may go undetected. Bestie, that's the whole loop-detection safety net 🙏💖
7. MPLS Label Stacking ✨
okay so this section is all about how that basic unit of MPLS label stack for SFC (the one from Section 5 🎀) gets used when you're doing MPLS label stacking to carry info about the SFP and the SFs that need to run 🧚. The use case scenarios for this vibe are in Section 4 💅.
Figure 3 is literally the whole look 😭. The top of the stack holds the labels that get the packet across the MPLS tunnel between SFFs 🚇. Any MPLS encapsulation may be used 🌈.
-------------------
~ Tunnel Labels ~
+-------------------+
~ Optional ~
~ Entropy Label ~
+-------------------+ - - -
| SFC Context Label |
+-------------------+ Basic unit of MPLS label stack for SFC
| SF Label |
+-------------------+ - - -
| SFC Context Label |
+-------------------+ Basic unit of MPLS label stack for SFC
| SF Label |
+-------------------+ - - -
~ ~
+-------------------+ - - -
| SFC Context Label |
+-------------------+ Basic unit of MPLS label stack for SFC
| SF Label |
+-------------------+ - - -
| |
~ Payload ~
| |
-------------------Figure 3: The MPLS SFC Label Stack for Label Stacking
An entropy label [RFC6790] can also show up here, as covered in Section 11 🦋.
Under those labels you get one or more instances of the basic unit of MPLS label stack for SFC 💖. On top of the field interpretation from Section 5, these are the meanings you need to vibe with 👑:
- SFC Context Label: the
Labelfield of this entry carries a label that delivers SFC context 🎀. It holds the SPI as a 20-bit integer, using the semantics exactly as defined in [RFC8300] 💜. Heads up, bestie: a system using the MPLS representation of the logical NSH MUST NOT assign SPI values greater than 2^20 - 1 or less than 16 🙈. This label can also carry other SFC context-specific semantics, like how to read the SF Label, or how to forward the packet to the node that offers the SF, but only if that's configured and coordinated with the controller that programs the labels for the SFP ✨. - SF Label: the
Labelfield of this entry says which SFI is up next for the packet 🫶. It can be scoped globally or inside the context of the SFC Context Label right before it, and it comes from the range 16 ... 2^20 - 1 🍓. - TC: the
TCfields work the way Section 5 describes 💅. - S: the
Sbits work the way Section 5 describes 🔥. - TTL: the
TTLfields in the SFC Context Label entry and the SF Label entry SHOULD be set to 1, like Section 5 says 😭, but they MAY be set to larger values if the label is asking for a forwarding operation toward the node that hosts the SF 🌸.
Now the processing rules for the Label fields 🧚:
- When a classifier inserts a packet onto an SFP, it adds a stack with one or more instances of the basic unit of MPLS label stack for SFC 💅. Together, that stack defines the SFs to be actioned, which means it defines the SFP the packet will walk through 👑.
- When a component of the SFC system processes a packet, it reads the top basic unit of label stack for SFC to figure out which SFI the packet goes to next 🦋. When an SFF gets a packet, it checks the top basic unit of MPLS label stack for SFC to decide where to send it next 🚀. If the next recipient is a local SFI, the SFF strips the basic unit of MPLS label stack for SFC before forwarding 🫧.
8. Mixed-Mode Forwarding 🌈
The earlier sections are all about homogeneous networks, where SFC forwarding is either all label swapping or all label popping (stacking) 🍭. That simplification makes the mechanisms way easier to explain 💖.
Real life is messier though 😭. As Section 4.2 explains, some use cases mix label swapping and stacking at the same time 🎀. It's also totally possible for different parts of the network to swap or pop, so an end-to-end service chain has to use a combo of both techniques 💜. And a classifier might be happy to use an SFP that a control plane or management plane already installed in the network, so it would use label swapping 🦋. But there might be a point in that SFP where you can pick between SFIs (maybe for load balancing) 🫶. In that case the classifier can want to take control of that choice by using a specific entry on the label stack, as Section 4.3 describes 👑.
When an SFF gets a packet with an MPLS label stack, it checks the context of the incoming interface, plus the SFP the top label points to, to figure out whether it's dealing with an {SPI, SI} label pair for label swapping or a {context label, SFI index} label pair for label stacking 🔥. Then it picks the right SFI to send the packet to ✨. When the packet comes back from the SFI, there are four cases to think about 💅:
- If the current hop requires an
{SPI, SI}and the next hop requires an{SPI, SI}, it sets the SPI Label according to the SFP to be traversed 🧚, picks an instance of the SF to run at the next hop, sets the SI Label to the SI value of the next hop 🍓, and tunnels the packet to the SFF for that SFI 🚇. - If the current hop requires an
{SPI, SI}and the next hop requires a{context label, SFI Label}, it pops the{SPI, SI}from the top of the MPLS label stack and tunnels the packet to the SFF indicated by the context label 🌸. - If the current hop requires a
{context label, SFI Label}, it pops the{context label, SFI Label}from the top of the MPLS label stack 🫧.- If the new top of the MPLS label stack contains an
{SPI, SI}label pair, it selects an SFI to use at the next hop and tunnels the packet to the SFF for that SFI 💖. - If the new top of the MPLS label stack contains a
{context label, SFI Label}, it tunnels the packet to the SFF indicated by the context label 🦋.
- If the new top of the MPLS label stack contains an
9. A Note on Service Function Capabilities and SFC Proxies 🧚
The idea of an "SFC proxy" comes from [RFC7665] 💜. An SFC proxy sits logically between an SFF and an SFI that is not "SFC aware" 🎀. Those SFIs can't handle the SFC encapsulation (NSH or MPLS) and need it stripped off the packets they process 😭. Lots of legacy SFIs that used to be deployed as "bumps in the wire" fall into this group until they get upgraded to be SFC aware 🕰️.
The job of an SFC proxy is to remove the SFC encapsulation and then put it back on 🫶. That way the SFF can process things as if it's talking to an SFC-aware SFI, and the SFI never sees the SFC encapsulation 👑. Honestly the proxy's job is the same whether you're using NSH or the MPLS encapsulation from this document 💅. The only difference (obviously) is that different encapsulation bytes get removed and reimposed 🌈.
The SFC proxy is a logical function, not a fixed box 🦋. It could be its own physical component on the path from the SFF to the SFI 🚇, or it could live on the same device as the SFF, or it could be part of the SFI 🍭. That choice is purely an implementation choice ✨.
Also, delivering metadata (see Section 12) needs special handling if an SFC proxy is in use 🙈. That's true whether you're using NSH or the MPLS encoding in this document 🫧. How it works depends on how (or if) each non-SFC-aware SFI can receive metadata 🔥.
10. Control-Plane Considerations 👑
For a packet to get forwarded along an SFP, a few functional elements have to run 🧚:
- Discovery/advertisement of SFIs 🔍
- Computation of the SFP 🧮
- Programming of classifiers 🎀
- Advertisement of forwarding instructions 📣
There are different ways to pull this off 💖. One is a fully centralized model, where SFFs report to a central controller which SFIs they support 🏰. The central controller computes the SFP and programs the classifiers 💅, and (if the label-swapping approach is taken) it installs forwarding state in the SFFs that lie on the SFP 🫶.
Or you can use a dynamic control plane, like the one described in [BGP-NSH-SFC] 🦋. In that setup, the SFFs use the control plane to advertise the SFIs they support 📡. A central controller computes the SFP and programs the classifiers 👑, and (if the label-swapping approach is taken) the central controller uses the control plane to advertise the SFPs, so SFFs on the SFP can install the forwarding state they need 🚀.
11. Use of the Entropy Label 🌊
Entropy is used in ECMP situations to make sure packets from the same flow take the same path 💜. That way you avoid jitter or reordering inside a flow 🫧.
Entropy is usually worked out by hashing on specific header fields, like the "five-tuple" in the IP and transport headers 🔐. But when an MPLS label stack is present, the stack can get so deep that some processors can't figure out the entropy hash properly 😭. The fix is the entropy label described in [RFC6790] 🎀.
When you want entropy for packets carried in MPLS tunnels over the underlay network, it is RECOMMENDED that an entropy label be included in the label stack right after the tunnel labels and before the SFC Labels 💖, as shown in Figures 2 and 3 🧚.
If an entropy label is present in an MPLS payload, it is RECOMMENDED that the initial classifier use that value in an entropy label it inserts into the label stack when the packet is forwarded (on the first tunnel) to the first SFF 🦋. In that case, you don't need to remove the entropy label from the payload 🫶.
12. Metadata 💌
Metadata is defined in [RFC7665] as providing "the ability to exchange context information between classifiers and SFs, and among SFs." 🧠 [RFC8300] explains how this context info can be encoded straight into fields that are part of the NSH encapsulation ✨.
Sections 12.1 and 12.2 explain how metadata gets tied to user data packets, and how metadata can be exchanged between SFC nodes in the network, when you're using an MPLS encoding of the logical representation of the NSH 📦.
Real talk, the MPLS encoding is less functional than using NSH directly 🙈. Both methods support metadata that is "per-SFP" or "per-flow" (see [RFC8393] for definitions of these terms) 🍓. But "per-packet" metadata (where the metadata has to ride on each packet because it changes from one packet to the next, even on the same flow or SFP) is only supported with NSH, not with the mechanisms in this document 😭💅.
12.1. Indicating Metadata in User Data Packets 💖
okay so in the MPLS version of the logical NSH, metadata gets carried by an SFC Metadata Label 🎀. That label uses the extended special-purpose label construct from [RFC7274], so you end up with three label stack entries, as shown in Figure 4 ✨:
- The Extension Label (value 15).
- An extended special-purpose label called the Metadata Label Indicator (MLI) (value 16).
- The Metadata Label (ML).
----------------
| Extension = 15 |
+----------------+
| MLI |
+----------------+
| Metadata Label |
----------------Figure 4: The MPLS SFC Metadata Label
The Metadata Label value is an index into a table of metadata 🧚 that gets programmed into the network using in-band or out-of-band mechanisms. Out-of-band options can include management-plane and control-plane solutions (like [BGP-NSH-SFC]), but those are out of scope for this document 🙈. The in-band mechanism is described in Section 12.2.
The SFC Metadata Label (as a set of three labels, as indicated in Figure 4) may be present zero, one, or more times in an MPLS SFC packet 💅. For MPLS label swapping, the SFC Metadata Labels go immediately after the basic unit of MPLS label stack for SFC, as shown in Figure 5. For MPLS label stacking, they go at the bottom of the label stack, as shown in Figure 6.
----------------
~ Tunnel Labels ~
+----------------+
~ Optional ~
~ Entropy Label ~
+----------------+
| SPI Label |
+----------------+
| SI Label |
+----------------+
| Extension = 15 |
+----------------+
| MLI |
+----------------+
| Metadata Label |
+----------------+
~ Other ~
| Metadata |
~ Label Triples ~
+----------------+
| |
~ Payload ~
| |
----------------Figure 5: The MPLS SFC Label Stack for Label Swapping with Metadata Label
-------------------
~ Tunnel Labels ~
+-------------------+
~ Optional ~
~ Entropy Label ~
+-------------------+
| SFC Context Label |
+-------------------+
| SF Label |
+-------------------+
~ ~
+-------------------+
| SFC Context Label |
+-------------------+
| SF Label |
+-------------------+
| Extension = 15 |
+-------------------+
| MLI |
+-------------------+
| Metadata Label |
+-------------------+
~ Other ~
| Metadata |
~ Label Triples ~
+-------------------+
| |
~ Payload ~
| |
-------------------Figure 6: The MPLS SFC Label Stack for Label Stacking with Metadata Label
12.2. In-Band Programming of Metadata 🦋
okay so there's a way to send metadata tied to an SFP without needing a payload packet, and that's described in [RFC8393] 🌸. The same approach works in an MPLS network where the NSH is logically represented by an MPLS label stack.
The packet header is formed exactly as previously described in this document, so the packet follows the SFP through the SFC network ✨. The twist is that instead of payload data, metadata goes after the bottom of the MPLS label stack. An extended special-purpose label signals that the metadata is there, so you get three label stack entries:
- The Extension Label (value 15).
- An extended special-purpose label called the Metadata Present Indicator (MPI) (value 17).
- The Metadata Label (ML) that is associated with this metadata on this SFP and can be used to indicate the use of the metadata as described in Section 12.
The MPI, if present, goes immediately after the last basic unit of MPLS label stack for SFC 🍓. The resulting label stacks are shown in Figure 7 for the MPLS label-swapping case and Figure 8 for the MPLS label-stacking case.
---------------
~ Tunnel Labels ~
+---------------+
~ Optional ~
~ Entropy Label ~
+---------------+
| SPI Label |
+---------------+
| SI Label |
+---------------+
| Extension = 15|
+---------------+
| MPI |
+---------------+
| Metadata Label|
+---------------+
| |
~ Metadata ~
| |
---------------Figure 7: The MPLS SFC Label Stack for Label Swapping Carrying Metadata
-------------------
~ Tunnel Labels ~
+-------------------+
~ Optional ~
~ Entropy Label ~
+-------------------+
| SFC Context Label |
+-------------------+
| SF Label |
+-------------------+
| SFC Context Label |
+-------------------+
| SF Label |
+-------------------+
~ ~
+-------------------+
| SFC Context Label |
+-------------------+
| SF Label |
+-------------------+
| Extension = 15 |
+-------------------+
| MPI |
+-------------------+
| Metadata Label |
+-------------------+
| |
~ Metadata ~
| |
-------------------Figure 8: The MPLS SFC Label Stack for Label Stacking Carrying Metadata
In both cases, the metadata is formatted as a TLV, as shown in Figure 9 🫶.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Metadata Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Metadata ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 9: The Metadata TLV
The fields of this TLV work like this 👑:
Length: The length of the metadata carried in the Metadata field, in octets, not including any padding.Metadata Type: The type of the metadata present. Values for this field are taken from the "NSH MD Types" registry maintained by IANA and defined in [RFC8300], and encoded with the most significant bit first.Metadata: The actual metadata, formatted as described in whatever document defines the metadata. This field is end-padded with zero to 3 octets of zeroes to take it up to a 4-octet boundary.
12.2.1. Loss of In-Band Metadata 🥺
Heads up, bestie: in-band metadata exchange is vulnerable to packet loss 💀. That's a risk from network faults, and it's also an attack vulnerability.
If packets that arrive at an SFF use an MLI that does not have an entry in the metadata table, an alarm can be raised, and the packet can be discarded or processed without the metadata, according to local configuration. This gives some long-term mitigation, but it's not an ideal solution 🙈.
Retransmitting metadata packets at a configurable interval gives further mitigation against loss. It's a relatively cheap approach, but it's only a partial solution, because there may still be a window during which the metadata has not been received 🌈.
Lost metadata can be a big deal when the metadata applicable to a specific MPI is being changed. This could result in out-of-date metadata being applied to a packet. If this is a concern, it is RECOMMENDED that a new MPI be used to install a new entry in the metadata table, and the packets in the flow should be marked with the equivalent new MLI 🔥.
Finally, if an application that requires metadata is sensitive to this potential loss or attack, it SHOULD NOT use in-band metadata distribution, but it SHOULD rely on control-plane or management-plane mechanisms ⭐. Those approaches can use a more sophisticated protocol that includes confirmation of delivery, and they can perform verification or inspection of entries in the metadata table 💜.
13. Worked Examples ✨
okay so this section is where we stop being abstract and just watch packets do their thing 🎀 it sticks to the simple versions of networks that run purely on label swapping or purely on label stacking. real deployments can mix both and go mixed-mode, like we talked about in Section 4 and Section 8 💅
Let's look at the simple MPLS SFC overlay network in Figure 10 🦋 A packet gets classified for an SFP that sends it through two SFs (SFa and SFb), which are reached through two SFFs (SFFa and SFFb, respectively). The packet finally gets delivered to the destination, D 💖
+---------------------------------------------------+
| MPLS SFC Network |
| |
| +---------+ +---------+ |
| | SFa | | SFb | |
| +----+----+ +----+----+ |
| ^ | | ^ | | |
| (2)| | |(3) (5)| | |(6) |
| (1) | | V (4) | | V (7) |
+----------+ ---> +----+----+ ----> +----+----+ ---> +-------+
|Classifier+------+ SFFa +-------+ SFFb +------+ D |
+----------+ +---------+ +---------+ +-------+
| |
+---------------------------------------------------+Figure 10: Service Function Chaining in an MPLS Network
okay so let's say the SFP gets computed and given an SPI value of 239 🌸 the forwarding details for it get distributed (maybe using the mechanisms of [BGP-NSH-SFC]) so the SFFs are programmed with the instructions they need 🧚
Here's how the packet moves through it 👑
- The classifier assigns the packet to the SFP and slaps on two label stack entries that make up a single basic unit of MPLS SFC representation 💅
- The higher label stack entry has a label carrying the SPI value of 239.
- The lower label stack entry has a label carrying the SI value of 255.
More labels might get added to tunnel the packet from the classifier to SFFa, so the chain is literally built on top of tunnels 🫶
- When the packet reaches SFFa, SFFa strips any labels tied to the tunnel from the classifier to SFFa 💀 Then it checks the top labels and matches the SPI/SI to figure out the packet should go to SFa. The packet goes to SFa unmodified ✨
- SFa does its job and sends the packet back to SFFa 🙌
- SFFa changes the SI in the lower label stack entry to 254 and uses the SPI/SI to look up where to send it next 😭 The packet goes out with two label stack entries:
- The higher label stack entry has a label carrying the SPI value of 239.
- The lower label stack entry has a label carrying the SI value of 254.
More labels might get imposed to tunnel the packet from SFFa to SFFb 🦋
- When the packet reaches SFFb, SFFb strips any labels tied to the tunnel from SFFa. It checks the top labels, matches the SPI/SI, and sees the packet should go to SFb. The packet goes to SFb unmodified 🍓
- SFb does its thing and returns the packet to SFFb 🔥
- SFFb changes the SI in the lower label stack entry to 253 and uses the SPI/SI to look up the forwarding instructions. It figures out it's the last SFF in the SFP, so it strips the two SFC Label stack entries and forwards the payload toward D using the payload protocol. main character ending 👑🌈
Now for the other setup, in Figure 11 💫 A packet gets classified for an SFP that sends it through two SFs (SFx and SFy), reached through two SFFs (SFFx and SFFy, respectively). It's still delivered to the destination, D 🎀
+---------------------------------------------------+
| MPLS SFC Network |
| |
| +---------+ +---------+ |
| | SFx | | SFy | |
| +----+----+ +----+----+ |
| ^ | | ^ | | |
| (2)| | |(3) (5)| | |(6) |
| (1) | | V (4) | | V (7) |
+----------+ ---> +----+----+ ----> +----+----+ ---> +-------+
|Classifier+------+ SFFx +-------+ SFFy +------+ D |
+----------+ +---------+ +---------+ +-------+
| |
+---------------------------------------------------+Figure 11: Service Function Chaining Using MPLS Label Stacking
so in this version the SFP gets computed and given an SPI value of 239 too 🧁 BUT the forwarding state for the SFP never gets distributed or installed in the network. Instead it rides along on each individual packet inside the MPLS label stack. it's giving self-contained 🦋
Here's the tea 🫖
- The classifier assigns the packet to the SFP and slaps on two basic units of MPLS SFC representation to describe the full SFP 💅
- The top basic unit is made of two label stack entries:
- The higher label stack entry has a label carrying the SFC context.
- The lower label stack entry has a label carrying the SF indicator for SFx.
- The lower basic unit is also made of two label stack entries:
- The higher label stack entry has a label carrying the SFC context.
- The lower label stack entry has a label carrying the SF indicator for SFy.
- The top basic unit is made of two label stack entries:
Further labels might get imposed to tunnel the packet from the classifier to SFFx ✨
- When the packet reaches SFFx, SFFx strips any labels tied to the tunnel from the classifier 💖 Then it checks the top labels and matches the context/SF values to see that the packet should go to SFx. The packet goes to SFx unmodified 🌸
- SFx performs its designated function and returns the packet to SFFx 🙌
- SFFx strips the top basic unit of MPLS SFC representation, which reveals the next one 🫶 It uses those revealed context/SF values to figure out how to route the packet to the next SFF, SFFy. It sends the packet out with just one basic unit of MPLS SFC representation, made of two label stack entries:
- The higher label stack entry has a label carrying the SFC context.
- The lower label stack entry has a label carrying the SF indicator for SFy.
Further labels might get imposed to tunnel the packet from SFFx to SFFy 🦋
- When the packet reaches SFFy, SFFy strips any labels tied to the tunnel from SFFx. It checks the top labels, matches the context/SF values, and sees the packet should go to SFy. The packet goes to SFy unmodified 🍓
- SFy does its job and returns the packet to SFFy 🔥
- SFFy strips the top basic unit of MPLS SFC representation, revealing the payload packet 👑 Then it forwards the payload toward D using the payload protocol. slay, the end 💅🌈
14. Implementation Notes 🧚
okay so it's not an IETF spec's job to describe the guts of an implementation 🙈 the exception is when internals directly affect the bits on the wire and change how likely interoperability is, or when config or security options directly change how useful an implementation is 💅
BUT, since this document wants to admit that brownfield MPLS networks might need an interim SFC deployment, this section shares some observations about how an SFF could use MPLS features that existing routers already have 🏠✨ It is not meant to be definitive or technically complete. It's more of a vibe check, aka indicative 💜
Let's think about how an incoming MPLS packet gets routed to a particular Virtual Routing and Forwarding (VRF) system inside a Layer 3 Virtual Private Network (L3VPN) [RFC4364] 🎀 In that case the top MPLS label tells you which VRF system to use for routing the payload 🌈
You can take a similar approach with the label-swapping SFC technique from Section 6 🦋 The SFC Context Label can identify a routing table specific to the SFP. The SF Label can then be looked up in the context of that routing table to decide which SF to send the packet to and how to forward it to the next SFF 💖
Advanced features (like metadata) are not inspected by SFFs 🙈 The packets get passed to SFIs that are MPLS-SFC aware, or to SFC proxies, and those components are responsible for handling all metadata issues 🫶
Of course, a real implementation might make a bunch of optimizations on top of this approach 🔥 But this section should give you hints about how MPLS-based SFC could be achieved with relatively small modifications to deployed MPLS devices ✨ iykyk, it's the brownfield glow-up we've been waiting for 🌸
15. Security Considerations ✨
Okay so, security is literally the most important part of this whole thing, bestie 🔐💅. Discussion of the security properties of SFC networks lives in [RFC7665] 🦋. More security discussion for the NSH and how it gets used is in [RFC8300] 💜. Those documents do the analysis, and they lay out a set of security requirements and recommendations. The normative security requirements from those documents apply to this specification too 🫶. BUT, and this is a big but, those documents do not describe any mechanisms for actually securing NSH systems 😭.
It is fundamental to the SFC design that the classifier is a fully trusted element 👑. The classification decision process is not visible to the other elements, and its output is treated as accurate. So the classifier is responsible for deciding what processing the packet gets, including, for example, firewall functions 🔥. It is also fundamental to the MPLS design that packets get routed through the network using the path specified by the node that imposes the labels, and that the labels get swapped or popped correctly 🌸. When an SF is not encapsulation aware, the encapsulation may be stripped by an SFC proxy. That means a packet might exist as a native packet (maybe IP) on the path between the SFC proxy and the SF 🧚. This is an intrinsic part of the SFC design, though, and the design needs to define how a packet is protected in that environment 💀.
SFC components get configured and enabled through a management system or a control plane. This document does not make any assumptions about which mechanisms are used 🍓. Deployments should still be aware that vulnerabilities in the management plane or control plane of an SFC system mean vulnerabilities in the whole SFC system 🙈. So control-plane solutions (such as [BGP-NSH-SFC]) and management-plane mechanisms must include security measures that operators can enable to protect their SFC systems 🫶✨.
An analysis of the security of MPLS systems is in [RFC5920] 📚. It also notes that the MPLS forwarding plane has no built-in security mechanisms 😬. Some proposals to add encryption to the MPLS forwarding plane have been suggested [MPLS-Opp-Sec], but no mechanisms had been agreed upon at the time this document was published 🥲. Also, MPLS does not provide any cryptographic integrity protection on the MPLS headers 💀. So the procedures in this document rely on three basic principles, and I'm going to list them out for you 💜:
- The MPLS network is often considered to be a closed network, so insertion, modification, or inspection of packets by an outside party is not possible 🔒. MPLS networks are operated with closed boundaries, so MPLS-encapsulated packets are not admitted to the network, and MPLS headers are stripped before packets are forwarded out of the network 🚪. This matters a LOT in the SFC context, because [RFC7665] notes that "The architecture described herein is assumed to be applicable to a single network administrative domain." 🏠 Furthermore, [RFC8300] states that packets originating outside the SFC-enabled domain MUST be dropped if they contain an NSH, and packets exiting the SFC-enabled domain MUST be dropped if they contain an NSH 🚫. These constraints apply equally to the use of MPLS to encode a logical representation of the NSH 🧚♀️.
- The underlying transport mechanisms (such as Ethernet) between adjacent MPLS nodes may offer security mechanisms that can be used to defend packets "on the wire" 🛡️.
- The SFC-capable devices participating in an SFC system are responsible for verifying and protecting payload packets and their contents, as well as providing any other security capabilities that might be required in the particular system 👑💖.
Also, where a tunnel is used to link two non-MPLS domains, the tunnel design needs to specify how the tunnel is secured 🚨.
So yeah, this design relies on the underlying technologies to address the potential security vulnerabilities 🫠. It documents the necessary protections (or the risk of their absence) above 📝. It does NOT include any native security mechanisms in-band with the MPLS encoding of the NSH functionality 🙅♀️.
Note that configuration elements of this system, such as programming the table of metadata (see Section 12), must also be adequately secured 🔐. Those mechanisms are not in scope for this protocol specification though 🤷♀️.
No known new security vulnerabilities over the SFC architecture [RFC7665] and the NSH specification [RFC8300] are introduced by this design 🎉. If issues are discovered in the future, it is expected that they will be addressed through modifications to control or management components of any solution, or through changes to the underlying technology 🔧✨.
16. IANA Considerations 🎀
IANA has made allocations from the "Extended Special-Purpose MPLS Label Values" subregistry of the "Special-Purpose Multiprotocol Label Switching (MPLS) Label Values" registry, as follows 🧾:
Value | Description | Reference
-------+-----------------------------------+--------------
16 | Metadata Label Indicator (MLI) | RFC 8595
17 | Metadata Present Indicator (MPI) | RFC 859517. References 📚
17.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>.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, DOI 10.17487/RFC6790, November 2012,
<https://www.rfc-editor.org/info/rfc6790>.
[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>.
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300,
DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc8300>.
[RFC8393] Farrel, A. and J. Drake, "Operating the Network Service
Header (NSH) with Next Protocol "None"", RFC 8393,
DOI 10.17487/RFC8393, May 2018,
<https://www.rfc-editor.org/info/rfc8393>.17.2. Informative References
[BGP-NSH-SFC]
Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L.
Jalil, "BGP Control Plane for NSH SFC", Work in Progress,
draft-ietf-bess-nsh-bgp-control-plane-11, May 2019.
[MPLS-Opp-Sec]
Farrel, A. and S. Farrell, "Opportunistic Security in
MPLS Networks", Work in Progress,
draft-ietf-mpls-opportunistic-encrypt-03, March 2017.
[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>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364,
February 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<https://www.rfc-editor.org/info/rfc5920>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665>.
[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>.
[RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair,
"Hierarchical Service Function Chaining (hSFC)", RFC 8459,
DOI 10.17487/RFC8459, September 2018,
<https://www.rfc-editor.org/info/rfc8459>.
[SR-Srv-Prog]
Clad, F., Ed., Xu, X., Ed., Filsfils, C., Bernier, D., Li,
C., Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W.,
and S. Salsano, "Service Programming with Segment
Routing", Work in Progress,
draft-xuclad-spring-sr-service-programming-02, April 2019.Acknowledgements 🫶
This document derives ideas and text from [BGP-NSH-SFC]. The authors are grateful to all those who contributed to the discussions that led to that work: Loa Andersson, Andrew G. Malis, Alexander (Sasha) Vainshtein, Joel Halpern, Tony Przygienda, Stuart Mackie, Keyur Patel, and Jim Guichard. Loa Andersson provided helpful review comments 💖.
Thanks to Loa Andersson, Lizhong Jin, Matthew Bocci, Joel Halpern, and Mach Chen for reviews of this text 🌷. Thanks to Russ Mundy for his Security Directorate review, and to S Moonesamy for useful discussions 🍓. Thanks also to Benjamin Kaduk, Alissa Cooper, Eric Rescorla, Mirja Kuehlewind, Alvaro Retana, and Martin Vigoureux for comprehensive reviews during IESG evaluation 🙌.
The authors would like to be able to thank the authors of [SR-Srv-Prog] and [RFC8402], whose original work on service chaining and on identifying services using Segment Identifiers (SIDs), and conversations with whom, helped clarify the application of SR-MPLS to SFC 🧚✨.
Particular thanks to Loa Andersson for conversations and advice about working group process 👑.
Contributors 🌈
The following individual contributed text to this document 💜:
Andrew G. Malis
Email: agmalis@gmail.comAuthors' Addresses 🦋
Adrian Farrel
Old Dog Consulting
Email: adrian@olddog.co.uk
Stewart Bryant
Futurewei
Email: stewart.bryant@gmail.com
John Drake
Juniper Networks
Email: jdrake@juniper.netThat's the whole RFC, bestie! 🌈💖 We made it through all six parts, and you are officially an NSH and MPLS legend now 👑✨
📦 where this page comes from
- ietf: rfc8595 2019-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms