RFC 9015
BGP Control Plane for the Network Service Header in Service Function Chaining
RFC 9015: BGP Control Plane for the Network Service Header in Service Function Chaining 🎀
Part 1 of 15 💖
okay bestie, let's start with the title block 🦋 This is RFC 9015, an IETF document. It's on the Standards Track, so it's a real Internet standard, not just a vibe 💅 It was published in June 2021, and its ISSN is 2070-1721. The authors are A. Farrel (Old Dog Consulting), J. Drake, E. Rosen (Juniper Networks), J. Uttaro (AT&T), and L. Jalil (Verizon). It doesn't obsolete or update anything, since its header doesn't list any RFCs it replaces or changes 🫶
The Table of Contents is below, copied exactly so you can see how the whole thing is laid out 🌸
1. Introduction
1.1. Requirements Language
1.2. Terminology
2. Overview
2.1. Overview of Service Function Chaining
2.2. Control Plane Overview
3. BGP SFC Routes
3.1. Service Function Instance Route (SFIR)
3.1.1. SFIR Pool Identifier Extended Community
3.1.2. MPLS Mixed Swapping/Stacking Extended Community
3.2. Service Function Path Route (SFPR)
3.2.1. The SFP Attribute
3.2.2. General Rules for the SFP Attribute
4. Mode of Operation
4.1. Route Targets
4.2. Service Function Instance Routes
4.3. Service Function Path Routes
4.4. Classifier Operation
4.5. Service Function Forwarder Operation
4.5.1. Processing with "Gaps" in the SI Sequence
5. Selection within Service Function Paths
6. Looping, Jumping, and Branching
6.1. Protocol Control of Looping, Jumping, and Branching
6.2. Implications for Forwarding State
7. Advanced Topics
7.1. Correlating Service Function Path Instances
7.2. Considerations for Stateful Service Functions
7.3. VPN Considerations and Private Service Functions
7.4. Flow Specification for SFC Classifiers
7.5. Choice of Data Plane SPI/SI Representation
7.5.1. MPLS Representation of the SPI/SI
7.6. MPLS Label Swapping/Stacking Operation
7.7. Support for MPLS-Encapsulated NSH Packets
8. Examples
8.1. Example Explicit SFP with No Choices
8.2. Example SFP with Choice of SFIs
8.3. Example SFP with Open Choice of SFIs
8.4. Example SFP with Choice of SFTs
8.5. Example Correlated Bidirectional SFPs
8.6. Example Correlated Asymmetrical Bidirectional SFPs
8.7. Example Looping in an SFP
8.8. Example Branching in an SFP
8.9. Examples of SFPs with Stateful Service Functions
8.9.1. Forward and Reverse Choice Made at the SFF
8.9.2. Parallel End-to-End SFPs with Shared SFF
8.9.3. Parallel End-to-End SFPs with Separate SFFs
8.9.4. Parallel SFPs Downstream of the Choice
8.10. Examples Using IPv6 Addressing
8.10.1. Example Explicit SFP with No Choices
8.10.2. Example SFP with Choice of SFIs
8.10.3. Example SFP with Open Choice of SFIs
8.10.4. Example SFP with Choice of SFTs
9. Security Considerations
10. IANA Considerations
10.1. New BGP AF/SAFI
10.2. "SFP attribute" BGP Path Attribute
10.3. "SFP Attribute TLVs" Registry
10.4. "SFP Association Type" Registry
10.5. "Service Function Chaining Service Function Types"
Registry
10.6. Flow Specification for SFC Classifiers
10.7. New BGP Transitive Extended Community Type
10.8. "SFC Extended Community Sub-Types" Registry
10.9. New SPI/SI Representation Sub-TLV
10.10. "SFC SPI/SI Representation Flags" Registry
11. References
11.1. Normative References
11.2. Informative References
Acknowledgements
Contributors
Authors' AddressesAbstract ✨
This document is all about using BGP as a control plane for networks that support service function chaining 🦋 It brings in a brand-new BGP address family called the "Service Function Chain (SFC) Address Family Identifier / Subsequent Address Family Identifier" (SFC AFI/SAFI), and it comes with two Route Types. The first one is originated by a node to say "hey, I host this particular instance of a specific service function." That Route Type also includes "instructions" for sending a packet to that hosting node in a way that tells everyone the service function has to be applied to the packet 🎀 The second Route Type is used by a controller to advertise the paths of "chains" of service functions. It gives each path its own unique designator, so the paths can be used together with the Network Service Header (NSH) defined in RFC 8300 🔥
This document adopts the service function chaining architecture described in RFC 7665 💜
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). If you want more details on Internet Standards, check out Section 2 of RFC 7841 🫶
Info about the current status of this document, any errata, and how to give feedback on it lives at https://www.rfc-editor.org/info/rfc9015 🔗
Copyright Notice
Copyright (c) 2021 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) as they stand on the date this document was published. Please read these documents carefully, because they spell out your rights and restrictions when it comes to this document 📜 Any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License.
1. Introduction ✨
Okay, so, as [RFC7498] explains, delivering end-to-end services can mean a packet has to go through a whole series of Service Functions (SFs) in a specific order 💖 Think WAN and application accelerators, Deep Packet Inspection (DPI) engines, firewalls, TCP optimizers, and server load balancers. This is what's called "service function chaining" 🔗 Deploying and maintaining it in production networks comes with a bunch of issues, and we're about to go through them.
Historically, if a packet needed to travel through a certain service chain, the nodes hosting those service functions had to be placed in the network topology so the packet could not reach its final destination without first passing through every service function in the right order. Honestly, that's a lot of pressure on where things sit 😭 It made it hard to adapt a service function chain to changes in the topology (like link or node failures), to network utilization, or to offered service load. These topology restrictions on where service functions could go caused the following issues:
- Configuring or changing a service function chain is operationally complex, and it may require changes to the network topology.
- Alternate or redundant service functions may need to be co-located with the primary service functions.
- When there's more than one path between source and destination, forwarding may be asymmetric. Supporting bidirectional service function chains with simple routing methods and protocols can get tricky without adding extra mechanisms for traffic steering or traffic engineering 🙈
To fix these issues, the service function chaining architecture describes service function chains that are built in their own overlay network (the service function overlay network). That overlay coexists with other overlay networks over a common underlay network [RFC7665] 🦋 A service function chain is a sequence of service functions that packet flows meeting specified criteria will pass through. Main character energy 👑
This document describes the use of BGP as a control plane for networks that support service function chaining 💜 It introduces a new BGP address family called the "Service Function Chain (SFC) Address Family Identifier / Subsequent Address Family Identifier" (SFC AFI/SAFI), with two Route Types. One Route Type is originated by a node to advertise that it hosts a particular instance of a specified service function. That Route Type also gives "instructions" on how to send a packet to the hosting node in a way that indicates the service function has to be applied to the packet 🎀 The other Route Type is used by a controller (a centralized network component responsible for planning and coordinating service function chaining within the network) to advertise the paths of "chains" of service functions. It gives each such path a unique designator, so the paths can be used together with the Network Service Header (NSH) [RFC8300] ✨
This document adopts the service function chaining architecture described in [RFC7665] 🌸
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. 📜
1.2. Terminology 🧚
This document uses the following terms from [RFC7665]:
- Bidirectional Service Function Chain
- Classifier
- Service Function (SF)
- Service Function Chain (SFC)
- Service Function Forwarder (SFF)
- Service Function Instance (SFI)
- Service Function Path (SFP)
- SFC branching
Additionally, this document uses the following terms from [RFC8300]:
- Network Service Header (NSH)
- Service Index (SI)
- Service Path Identifier (SPI)
This document introduces the following terms:
- Service Function Instance Route (SFIR): A new BGP Route Type advertised by the node that hosts an SFI. It describes the SFI and announces how to forward a packet to the node through the underlay network. 🦋
- Service Function Overlay Network: The logical network made up of classifiers, SFFs, and SFIs, connected by paths or tunnels running through underlay transport networks. 🌈
- Service Function Path Route (SFPR): A new BGP Route Type originated by controllers to advertise the details of each SFP. 💅
- Service Function Type (SFT): An indication of the function and features of an SFI. ✨
2. Overview 🌸
This section gives an overview of service function chaining in general and of the control plane this document defines. Once you've read it, you might find it helpful to skim Section 8 for some simple worked examples 💖
2.1. Overview of Service Function Chaining ✨
okay bestie, let's get into it 🫖💅 In [RFC8300], a Service Function Chain (SFC) is an ordered list of Service Functions (SFs). A Service Function Path (SFP) tells you which instances of SFs are acceptable to walk through when an SFC gets instantiated in a service function overlay network 🦋. The Service Path Identifier (SPI) is a 24-bit number that identifies one specific SFP, and the Service Index (SI) is an 8-bit number that identifies one specific point along that path 💜. So within a particular SFP (picked out by its SPI), the SI tells you which service function you're at and where that SF sits in the order 🧚.
Within a specific SFP, an SI points to a set of one or more SFs, and each of those SFs can be backed by one or more Service Function Instances (SFIs). So an SI can be a choice of SFIs across one or more service function types, which is giving flexibility 🌈. And if you deploy multiple SFIs for a single SF, you get load balancing and redundancy, which is so iconic 👑.
A special functional element called a "classifier" lives at each ingress point to a service function overlay network 🌸. Its job is to assign the packets of a given packet flow to a specific SFP. It does this by comparing specific fields in the packet's header against local policy, which may be customer/network/service specific. The classifier picks an SFP and sets the SPI to match. Then it sets the SI to the value for the first hop in that SFP, and prepends a Network Service Header (NSH) [RFC8300] carrying the assigned SPI/SI to the packet 🎀. Also, bestie, the classifier and the node hosting the first SF in an SFP don't need to be in the same spot in the service function overlay network ✨.
Here's the tricky part 😭 Once the NSH is on the packet, nodes in the underlay network can have a hard time finding the original packet fields they'd normally use to spread traffic across equal-cost multipath (ECMP) forwarding. So it is recommended that the node prepending the NSH also provide some form of entropy indicator that the underlay network can use. How that indicator gets generated and supplied, and how an SFF generates a new entropy indicator when it forwards a packet to the next SFF, are out of scope for this document 🙈.
The Service Function Forwarder (SFF) receives a packet from the previous node in an SFP, strips off the packet's link layer or tunnel encapsulation, and hands the packet and the NSH to the SFI for processing 🫶. The SFI has no knowledge of the SFP at all, which is kinda wild but also very on-brand for the design 💀.
When the SFF gets the packet and the NSH back from the SFI, it must select the next SFI along the path using the SPI and SI in the NSH. It may also have to choose between multiple SFIs (possibly of different SFTs), as described in Section 5 📚. In the normal case the SPI stays the same and the SI has been decremented to point at the next SF along the path 🍓. But other things can happen if the SF changes the NSH through a process of reclassification:
- The SI in the NSH may indicate:
- A previous SF in the path. This is known as "looping" (see Section 6) 🔁.
- An SF further down the path. This is known as "jumping" (again, see Section 6) 🦘.
- The SPI and the SI may point to an SF on a different SFP. This is known as "branching" (see Section 6) 🌿.
Such modifications are limited to within the same service function overlay network. In other words, an SPI is only known within the scope of that service function overlay network 🧸. And the new SI value gets interpreted in the context of the SFP identified by the SPI, so it's all connected 🔗.
As described in [RFC8300], an SPI that is unknown or not valid is treated as an error, and the SFF drops the packet. Such errors should be logged, and those logs are subject to rate limits 🚨.
Also as described in [RFC8300], if an SFF receives an SI that is unknown in the context of the SPI, it can reduce the value to the next meaningful SI in the SFP indicated by the SPI 🪄. If no such value exists, or if the SFF doesn't support reducing the SI, the SFF drops the packet and should log the event. Those logs are also subject to rate limits 💅.
Then the SFF selects an SFI that provides the SF denoted by the SPI/SI and forwards the packet to the SFF that supports that SFI 🚀.
[RFC8300] makes it clear that the intended scope is use within a single provider's operational domain 🏠.
Now, this document adopts the service function chaining architecture described in [RFC7665] and adds a control plane to support the functions, as described in Section 2.2 💜. The big star of this solution is the controller 👑. It's a network component responsible for planning SFPs within the network. It gathers information about the availability of SFIs and SFFs, instructs the control plane about which SFPs to program, and instructs the classifiers how to assign traffic flows to individual SFPs 🌟.
2.2. Control Plane Overview 🎀
okay so to make the stuff in Section 2.1 actually happen, this doc brings in the Service Function Type (SFT) 💅. It's basically the category of SF that an SFF supports, like "firewall." There's an IANA registry of service function types introduced in Section 10.5, and it lines up with types used in other work, like [BGP-LS-SR] ✨. An SFF can support SFs of multiple different SFTs, and it can support multiple SFIs of each SF. Main character energy 👑
The SFT registry (see Section 10.5) is split into three ranges, each with its own assignment policy per [RFC8126] 🌈:
- The special-purpose SFT range is assigned through Standards Action 🔒. Those values are for special SFC operations, and they don't apply to the types of SF that may form part of the SFP.
- The First Come First Served range tracks SFT values assigned by any party that defines an SF type 🍓. Reference through an Internet-Draft is desirable, but not required.
- The Private Use range isn't tracked by IANA 🧚. It's mainly for private networks where the meaning of the SFT values is tracked locally and controlled by a local administrator.
It's giving that most SFT values will come from the First Come First Served space 💖. That keeps everything interoperable, especially when software and hardware from different vendors live in the same network, or when two networks get merged 🫶. Operators of private networks can still build their own SFs and run their network off their own list of SFT values, which is valid and iconic 🦋.
This document also introduces a new BGP AFI/SAFI (values 31 and 9, respectively) for "SFC Routes" 🌸. There are two SFC Route Types defined here: the Service Function Instance Route (SFIR) and the Service Function Path Route (SFPR) ✨. Section 3 goes into detail, but the short version is that the Route Type gets indicated by a subfield in the Network Layer Reachability Information (NLRI) 💅.
- The SFIR is advertised by the node that provides access to the service function instance (i.e., the SFF) 🚪. It describes one particular instance of one particular SF (i.e., an SFI), plus how to forward a packet to it through the underlay network, meaning IP address and encapsulation info 💜.
- SFPRs are originated by controllers 🧠. One SFPR is originated for each SFP, and it specifies:
- A. the SPI of the path,
- B. the sequence of SFTs and/or SFIs that the path consists of, and
- C. for each such SFT or SFI, the SI that represents it in the identified path.
This whole approach assumes there's an underlay network that gives connectivity between SFFs and controllers 🌐. The SFFs are grouped to form one or more service function overlay networks, and SFPs get built through those overlays 🦋. We also assume the controllers have BGP connectivity to all SFFs and all classifiers within each service function overlay network 🫶.
When choosing the next SFI in a path, the SFF uses the SPI and SI, plus the SFT, to pick among the SFIs 🎯. It might apply something like a load-balancing algorithm, or use direct knowledge of the underlay network topology, as described in Section 4 🔥.
Then the SFF encapsulates the packet using the encapsulation specified by the SFIR of the selected SFI, and forwards it 📦. See Figure 1 👀.
So honestly, the SFF is a portal in the underlay network that you go through to reach a particular SFI 🚪✨.
Figure 1 is the reference model for the service function chaining architecture 🗺️. There are four SFFs (SFF-1 through SFF-4) connected by tunnels across the underlay network 🚇. Packets arrive at a classifier and get channeled along SFPs to destinations reachable through SFF-4 💅.
SFF-1 and SFF-4 each have one instance of one SF attached (SFa and SFe) 🌷. SFF-2 has two types of SF attached: one instance of one type (SFc) and three instances of the other (SFb) 🍓. SFF-3 has just one instance of an SF (SFd), but here the type of SFd is the same as the type of SFb (SFTx) 💜.
This figure shows how load balancing works, by creating several SFPs that satisfy the same SFC 🎀. Say an SFC needs to include SFa, an SF of type SFTx, and SFc 🧁. A bunch of SFPs can be built using any instance of SFb, or using SFd 🌈. Load balancing can happen in two places:
- The classifier can spread different flows onto different SFPs, to share the load across the network and across SFIs 🌊.
- SFF-2 can spread different flows (on the same SFP) across different instances of SFb, to share the processing load 🧠.
Quick note, for convenience and clarity, Figure 1 only shows a few tunnels between SFFs 🙈. There could be a full mesh of tunnels, or, more likely, a selection of tunnels connecting key SFFs so SFPs can get built and load and traffic can be balanced across the network ⭐. The figure also doesn't show any controllers. Each one would have BGP connectivity to the classifier and all of the SFFs 👑.
Packets
| | |
------------
| |
| Classifier |
| |
------+-----
|
---+--- --------- -------
| | Tunnel | | | |
| SFF-1 |===============| SFF-2 |=========| SFF-4 |
| | | | | |
| | -+-----+- | |
| | ,,,,,,,,,,,,,,/,, \ | |
| | ' .........../. ' ..\...... | |
| | ' : SFb / : ' : \ SFc : | |
| | ' : ---+- : ' : --+-- : | |
| | ' : -| SFI | : ' : | SFI | : | |
| | ' : -| ----- : ' : ----- : | |
| | ' : | ----- : ' ......... | |
| | ' : ----- : ' | |
| | ' ............. ' | |--- Dests
| | ' ' | |--- Dests
| | ' ......... ' | |
| | ' : ----- : ' | |
| | ' : | SFI | : ' | |
| | ' : --+-- : ' | |
| | ' :SFd | : ' | |
| | ' ....|.... ' | |
| | ' | ' | |
| | ' SFTx | ' | |
| | ',,,,,,,,|,,,,,,,,' | |
| | | | |
| | ---+--- | |
| | | | | |
| |======| SFF-3 |====================| |
---+--- | | ---+---
| ------- |
....|.... ....|....
: | SFa: : | SFe:
: --+-- : : --+-- :
: | SFI | : : | SFI | :
: ----- : : ----- :
......... .........
Figure 1: The Service Function Chaining Architecture Reference ModelAs mentioned before, [RFC8300] makes it clear that the mechanisms it defines are meant for use within a single provider's operational domain 🏠. That takes some pressure off the control plane function 💅.
Section 5.2 of [RFC7665] lays out the functions a control plane provides for a service function chaining network 📋. The functions are split into six items, and the first four are fully covered by the mechanisms in this document 💖:
- Visibility of all SFs and the SFFs through which they are reached 👀.
- Computation of SFPs and programming into the network 🛠️.
- Selection of SFIs explicitly in the SFP or dynamically within the network 🎯.
- Programming of SFFs with forwarding path information 📡.
The fifth and sixth items in the RFC 7665 list are about the use of metadata 🧾. They're more on the sidelines for the control plane mechanisms defined here, but Section 4.4 talks about them 🫶.
3. BGP SFC Routes 🧚
This document defines a new AFI/SAFI for BGP, called "SFC", with an NLRI described in this section 💜.
The format of the SFC NLRI is shown in Figure 2 🎀.
+---------------------------------------+
| Route Type (2 octets) |
+---------------------------------------+
| Length (2 octets) |
+---------------------------------------+
| Route Type specific (variable) |
+---------------------------------------+
Figure 2: The Format of the SFC NLRIThe "Route Type" field decides how the rest of the Route Type specific SFC NLRI gets encoded 🔑.
The "Length" field tells you the length, in octets, of the "Route Type specific" field of the SFC NLRI 📏.
This document defines the following Route Types:
- Service Function Instance Route (SFIR) 📍
- Service Function Path Route (SFPR) 🛤️
An SFIR is used to identify an SFI 🪪. An SFPR defines a sequence of SFs (each of which has at least one instance advertised in an SFIR) that form an SFP 🧵.
The detailed encoding and procedures for these Route Types are covered in the subsequent sections 📚.
The SFC NLRI is carried in BGP [RFC4271] using BGP Multiprotocol Extensions [RFC4760], with an Address Family Identifier (AFI) of 31 and a Subsequent Address Family Identifier (SAFI) of 9 🚀. The "NLRI" field in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute holds the SFC NLRI, encoded as specified above 💅.
For two BGP speakers to exchange SFC NLRIs, they MUST use BGP capabilities advertisements, so they both know they can properly process those NLRIs 🤝. This is done as specified in [RFC4760], using capability code 1 (Multiprotocol BGP) with an AFI of 31 and a SAFI of 9 🫶.
The "nexthop" field of the MP_REACH_NLRI attribute of the SFC NLRI MUST be set to a loopback address of the advertising SFF 🌸.
3.1. Service Function Instance Route (SFIR) 🎀
Okay so the SFIR is the route that says "hey, I host a service function instance!" 💖 Figure 3 shows its Route Type specific NLRI, aka the layout of the route's main fields:
+--------------------------------------------+
| Route Distinguisher (RD) (8 octets) |
+--------------------------------------------+
| Service Function Type (2 octets) |
+--------------------------------------------+
Figure 3: SFIR Route Type Specific NLRISo [RFC4364] defines a Route Distinguisher (RD) as a two-byte "Type" field plus a six-byte "Value" field, and it defines RD types 0, 1, and 2 ✨ For the SFIR, the RD MUST be of type 0, 1, or 2. No other types, bestie 🙅♀️
If two SFIRs come from different administrative domains (but still inside the same provider's operational domain), they MUST have different RDs 🧚 And it gets extra specific for VPNs: SFIRs from different VPNs (different service function overlay networks) MUST have different RDs, and those RDs MUST be different from any non-VPN SFIRs. Main character energy for keeping everything separate 👑
The SFT tells you what an SF can do, like a classifier, a firewall, or a load balancer 💅 There can be several SFIs that offer the same service function, so it's a whole crowd. Each node hosting an SFI MUST originate an SFIR for each type of SF it hosts (as indicated by the SFT value), and it MAY advertise an SFIR for each instance of each type of SF. A minimal advertisement lets you build valid SFPs and leaves picking the SFI to the local SFF. A detailed advertisement can get a bit much for scaling, but it lets a controller that builds an SFP make an explicit choice of SFI 🦋
Also, a node can advertise all of its SFIs for one SFT in one shot using normal BGP UPDATE packing 📦 All the SFIRs in one Update share a common Tunnel Encapsulation and Route Target (RT) attribute. See also Section 3.2.1.
The SFIR for a given SFI has an NLRI with the "RD" field set to an RD as specified above, and the "SFT" field set to identify that SFI's SFT. The values for "SFT" come from a registry administered by IANA (see Section 10) 🌈 A BGP UPDATE with one or more SFIRs MUST also include a tunnel encapsulation attribute [RFC9012]. If a data packet needs to go to an SFI in one of the SFIRs, it gets encapsulated the way the tunnel encapsulation attribute says, then sent through the underlay network. Lowkey so cool 🫶
Note that the tunnel encapsulation attribute MUST contain enough information for the advertising SFF to figure out which overlay or VPN network a received packet is transiting. Why? Because the [SPI, SI] in a received packet is specific to one particular overlay or VPN network. Don't skip this one, it's giving "important" 🚨
3.1.1. SFIR Pool Identifier Extended Community 🍓
This document defines a new transitive Extended Community [RFC4360] of type 0x0b called the "SFC Extended Community" ✨ When it's used with Sub-Type 1, it's called the "SFIR Pool Identifier extended community". It MAY be included in SFIR advertisements, and it's used to show which pool of SFIRs an SFIR belongs to. An SFIR can be in more than one pool, so multiple of these extended communities can show up on a single SFIR advertisement. Pool party 🎉
SFIR pools let you group SFIRs for pretty much any reason. Possible uses include control plane scalability and stability 💜 A pool identifier can also be included in an SFPR to indicate a set of SFIs that are acceptable at a specific point on an SFP (see Sections 3.2.1.3 and 4.3).
The SFIR Pool Identifier Extended Community is encoded in 8 octets, like this (Figure 4):
+--------------------------------------------+
| Type = 0x0b (1 octet) |
+--------------------------------------------+
| Sub-Type = 1 (1 octet) |
+--------------------------------------------+
| SFIR Pool Identifier value (6 octets) |
+--------------------------------------------+
Figure 4: The SFIR Pool Identifier Extended CommunityThe SFIR Pool Identifier value is a 6-octet field in network byte order, and the value is unique within the scope of an overlay network. So pool identifiers need to be centrally managed, which fits with how SFIs get assigned to pools 🧠
3.1.2. MPLS Mixed Swapping/Stacking Extended Community 🦋
As we said in Section 3.1.1, this document defines a new transitive Extended Community of type 0x0b called the "SFC Extended Community" ✨ When it's used with Sub-Type 2, it's called the "MPLS Mixed Swapping/Stacking Labels Extended Community". It's encoded like Figure 5 shows, and it holds a pair of MPLS labels: an SFC Context Label and an SF Label, as described in [RFC8595]. Each label is 20 bits, encoded in a 3-octet (24-bit) field with 4 trailing bits that MUST be set to zero 🔢
+--------------------------------------------+
| Type = 0x0b (1 octet) |
+--------------------------------------------|
| Sub-Type = 2 (1 octet) |
+--------------------------------------------|
| SFC Context Label (3 octets) |
+--------------------------------------------|
| SF Label (3 octets) |
+--------------------------------------------+
Figure 5: The MPLS Mixed Swapping/Stacking Labels Extended CommunityIt's assumed that each SFF has one or more globally unique SFC Context Labels, and that the context-label space and the SPI-address space are disjoint. In other words, a label value can't be used for both an SFC context and an SPI, and you can tell from knowing the label spaces whether a label means an SFC context or an SPI 🌸
If an SFF supports SFP Traversal with an MPLS Label Stack, it MUST include this Extended Community with the SFIRs that it advertises.
See Section 7.6 for how this Extended Community gets used 💖
3.2. Service Function Path Route (SFPR) 🛤️
Figure 6 shows the Route Type specific NLRI of the SFPR, which is the route that describes a whole path ✨
+-----------------------------------------------+
| Route Distinguisher (RD) (8 octets) |
+-----------------------------------------------+
| Service Path Identifier (SPI) (3 octets) |
+-----------------------------------------------+
Figure 6: SFPR Route Type Specific NLRISame RD deal as before: [RFC4364] defines the RD as a two-byte "Type" field plus a six-byte "Value" field, and it defines RD types 0, 1, and 2. For the SFPR, the RD MUST be of type 0, 1, or 2 💅
All SFPs MUST be associated with an RD, and provisioning decides which RD goes with which SFP. If two SFPRs come from different controllers, they MUST have different RDs. Also, SFPRs from different VPNs (i.e., in different service function overlay networks) MUST have different RDs, and those RDs MUST be different from any non-VPN SFPRs 🫶
The Service Path Identifier is defined in [RFC8300], and it's the value that goes in the "Service Path Identifier" field of the NSH of any packet sent on this SFP. One or more controllers are expected to originate these routes in order to set up a service function overlay network 🌈
The SFP is described in a new BGP Path attribute, the SFP attribute. Section 3.2.1 shows the format of that attribute.
3.2.1. The SFP Attribute 👑
[RFC4271] defines BGP Path attributes. This document introduces a new Optional Transitive Path attribute called the "SFP attribute", with value 37 💜 The first SFP attribute MUST be processed, and subsequent instances MUST be ignored.
The common fields of the SFP attribute are set like this:
- The Optional bit is set to 1 to indicate that this is an optional attribute.
- The Transitive bit is set to 1 to indicate that this is a transitive attribute.
- The Extended Length bit is set if the length of the SFP attribute is encoded in one octet (set to 0) or two octets (set to 1), as described in [RFC4271].
- The Attribute Type Code is set to 37.
The content of the SFP attribute is a series of Type-Length-Value (TLV) constructs. Some TLVs may include Sub-TLVs. All TLVs and Sub-TLVs have a common format:
Type: A single octet indicating the type of the SFP attribute TLV. Values are taken from the registry described in Section 10.3.Length: A two-octet field indicating the length of the data following the "Length" field, counted in octets.Value: The contents of the TLV.
The formats of the TLVs defined in this document are shown in the following sections. Here are the presence rules and meanings, bestie 🧚
- The SFP attribute contains a sequence of zero or more Association TLVs. That is, the Association TLV is OPTIONAL. Each Association TLV provides an association between this SFPR and another SFPR. Each associated SFPR is indicated using the RD it's advertised with (we say the SFPR-RD to avoid ambiguity).
- The SFP attribute contains a sequence of one or more Hop TLVs. Each Hop TLV contains all of the information about a single hop in the SFP.
- Each Hop TLV contains an SI value and a sequence of one or more SFT TLVs. Each SFT TLV contains an SFI reference for each instance of an SF that's allowed at this hop of the SFP for the specific SFT. Each SFI is indicated using the RD it's advertised with (we say the SFIR-RD to avoid ambiguity).
Section 6 of [RFC4271] describes how to handle malformed BGP attributes, or ones that are in error in some way. [RFC7606] revises BGP error handling specifically for the UPDATE message, gives guidelines for authors of documents that define new attributes, and revises the error-handling procedures for a number of existing attributes. This document introduces the SFP attribute, so it defines error handling as follows 🚨
- When parsing a message, an unknown Attribute Type Code, or a length that suggests the attribute is longer than the remaining message, is treated as a malformed message, and the "treat-as-withdraw" approach is used as per [RFC7606].
- When parsing a message that contains an SFP attribute, the following cases count as errors:
- Optional bit is set to 0 in the SFP attribute.
- Transitive bit is set to 0 in the SFP attribute.
- Unknown "TLV Type" field found in the SFP attribute.
- TLV length that suggests the TLV extends beyond the end of the SFP attribute.
- Association TLV contains an unknown SFPR-RD.
- No Hop TLV found in the SFP attribute.
- No Sub-TLV found in a Hop TLV.
- Unknown SFIR-RD found in an SFT TLV.
- The errors listed above are handled like this:
- 1, 2, 4, 6, 7: The attribute MUST be treated as malformed and the "treat-as-withdraw" approach used as per [RFC7606].
- 3: Unknown TLVs MUST be ignored, and message processing MUST continue.
- 5, 8: The absence of an RD to correlate with is nothing more than a soft error. The receiver SHOULD store the information from the SFP attribute until a corresponding advertisement is received. 🥺
3.2.1.1. The Association TLV ✨
okay so the Association TLV is an optional TLV in the SFP attribute 🎀 It MAY be present multiple times, and each one links this SFP to another SFP that shows up in a different SFPR. Here's what it looks like:
+--------------------------------------------+
| Type = 1 (1 octet) |
+--------------------------------------------|
| Length (2 octets) |
+--------------------------------------------|
| Association Type (1 octet) |
+--------------------------------------------|
| Associated SFPR-RD (8 octets) |
+--------------------------------------------|
| Associated SPI (3 octets) |
+--------------------------------------------+
Figure 7: The Format of the Association TLVHere's the breakdown 💅
Typeis set to 1 to say "hey, this is an Association TLV" 🦋Lengthcounts the octets in theAssociation TypeandAssociated SFPR-RDfields. Its value is 12.- The
Association Typefield says what kind of association it is. These values live in an IANA registry (see Section 10.4). Right now only one is defined in this document: Type 1 means two unidirectional SFPs get paired up to form a bidirectional SFP 👯♀️ An SFP attribute SHOULD NOT have more than one Association TLV with Association Type 1. If there's more than one, the first one MUST be processed and the rest MUST be ignored 🙈 Also, documents that define new association types have to spell out the presence rules for their own Association TLVs. Associated SFPR-RDholds the RD of the associated SFP, the one that was advertised in an SFPR.Associated SPIholds the SPI of the associated SFP, again as advertised in an SFPR.
Now the "nope, ignore that" cases 🙅♀️ Association TLVs with an unknown Association Type SHOULD be ignored. Association TLVs whose Associated SFPR-RD matches the RD of the SFPR they're sitting in SHOULD be ignored too. And if the Associated SPI doesn't match the SPI advertised in the SFPR that Associated SFPR-RD points to, the Association TLV SHOULD be ignored. For all three of these, an implementation MAY reject the SFP attribute as malformed and use the "treat-as-withdraw" approach per [RFC7606]. Heads up though, implementors, that approach might make your implementation less flexible if this protocol gets extended later 🧚
One thing to remember: when two SFPRs point at each other with the Association TLV, one of them is gonna arrive before the other 🫶 So processing an association MUST NOT be rejected just because the Associated SFPR-RD is unknown, because it might just not have shown up yet.
If you want more on how SFPRs get correlated, check out Section 7.1 🌸
3.2.1.2. The Hop TLV 🍓
There's one Hop TLV in the SFP attribute for every hop in the SFP. The format is shown in Figure 8. At least one Hop TLV MUST be present in an SFP attribute 💜
+--------------------------------------------+
| Type = 2 (1 octet) |
+--------------------------------------------|
| Length (2 octets) |
+--------------------------------------------|
| Service Index (1 octet) |
+--------------------------------------------|
| Hop Details (variable) |
+--------------------------------------------+
Figure 8: The Format of the Hop TLVThe fields, bestie:
Typeis set to 2 to mark a Hop TLV 🌈Lengthcounts the octets in theService IndexandHop Detailsfields.- The Service Index is defined in [RFC8300]. It's the value in the "Service Index" field of the NSH, and it's what an SFF looks at to figure out which next SFI a packet should go to 🔥
Hop Detailsis a sequence of one or more Sub-TLVs.
Every hop of the SFP might need a specific type of SF to run, and that type gets indicated inside the Sub-TLVs of the Hop TLV ✨ At least one Sub-TLV MUST be present. This document defines the SFT Sub-TLV (see Section 3.2.1.3) and the MPLS Swapping/Stacking Sub-TLV (see Section 3.2.1.4), and other Sub-TLVs could show up in the future 🦋 The SFT Sub-TLV lists which SF types are acceptable at a given hop, and for each type it lets you control which SFIs of that type get picked. The MPLS Swapping/Stacking Sub-TLV tells you what kind of SFC encoding to use in an MPLS label stack 💅
If there's no Hop TLV in an SFP attribute, it's a malformed attribute. Not it 💀
3.2.1.3. The SFT Sub-TLV 🎀
The SFT Sub-TLV MAY be included in the list of Sub-TLVs of the Hop TLV. Here's the format in Figure 9. The Hop Sub-TLV holds a list of SFIR-RD values, and each one comes from the advertisement of an SFI. Together they make a list of acceptable SFIs of the indicated type 🫶
+--------------------------------------------+
| Type = 3 (1 octet) |
+--------------------------------------------|
| Length (2 octets) |
+--------------------------------------------|
| Service Function Type (2 octets) |
+--------------------------------------------|
| SFIR-RD List (variable) |
+--------------------------------------------+
Figure 9: The Format of the SFT Sub-TLVThe fields:
Typeis set to 3 to mark an SFT Sub-TLV 🌸Lengthcounts the octets in theService Function TypeandSFIR-RD Listfields.- The SFT value is the category (type) of SF that gets run at this hop. The types are the ones advertised for the SFs the SFFs support. SFT values 1-31 are special-purpose, and their meanings are defined by whatever documents describe them. The "Change Sequence" value is defined in Section 6.1 of this document ✨
- The hop description gets more specific than just the SFT. For each SFT at each hop, you list the SFIs that can be used there. The SFIs are identified by their SFIR-RDs from the SFI advertisements in the SFIRs. Heads up: if the list has one or more SFIR Pool Identifiers, then the SFIR-RD list gets effectively expanded to include the SFIR-RD of every SFIR advertised with each of those Pool Identifiers 👑 An SFIR-RD of value zero has a special meaning, covered in Section 5. Every entry is eight octets long, and you can work out how many entries there are from the
Lengthfield 🧚 - An SFIR-RD is of type 0, 1, or 2 (see Section 3.1), so the high-order octet of an RD in an SFIR-RD List is always
0x00. The high-order octet of an SFIR Pool Identifier (an Extended Community withTypefield0x0b) is always nonzero, though. That's how the node reading the SFIR-RD list can tell the two kinds of list entry apart 🔥
3.2.1.4. MPLS Swapping/Stacking Sub-TLV 💜
The MPLS Swapping/Stacking Sub-TLV (Type value 4) is a zero-length Sub-TLV. It's OPTIONAL in the Hop TLV, and you use it when the data representation is MPLS (see Section 7.5). When it's there, it tells the classifier that's imposing an MPLS label stack that this hop should use an {SFC Context Label, SF label} pair instead of an {SPI, SF} label pair. See Section 7.6 for more details 🦋
3.2.1.5. SFP Traversal With MPLS Label Stack TLV 🌈
The SFP Traversal With MPLS Label Stack TLV (Type value 5) is a zero-length TLV that can ride along in the SFP attribute. It tells the classifier and the SFFs on the SFP that an MPLS label stack with label swapping/stacking should be used for packets going across the SFP 🎀 All of the SFFs at each of the SFP's hops MUST have advertised an MPLS Mixed Swapping/Stacking Extended Community (see Section 3.1.2) for the SFP to count as usable 🙈
3.2.2. General Rules for the SFP Attribute 🌸
It's totally possible for the same SFI, the one described by an SFIR, to show up in more than one SFPR ✨
When two SFPRs have the same SPI but different SFPR-RDs, there are three possible reasons:
- Two or more controllers are originating SFPRs for the same SFP. In this case the content of the SFPRs is identical, and the duplication is there to make sure they get received and to give you controller redundancy 🫶
- The content of the advertised SFP is transitioning, and the advertisements may come from one or more controllers. In this case the SFPRs' content will be different 🦋
- The SPI got reused because of a configuration error. Oops 💀
In none of these cases is there any way for the receiving SFF to know which SFPR to process, and the SFPRs could arrive in any order 🤷♀️ So at any point in time, when multiple SFPRs have the same SPI but different SFPR-RDs, the SFF MUST use the SFPR with the numerically lowest SFPR-RD, where the RDs are read as 8-octet integers in network byte order 👑 The SFF SHOULD log this occurrence to help with debugging 🔥
Also, a controller that wants to change the content of an SFP is RECOMMENDED to use a new SPI and create a new SFP. That way the classifiers can move packet flows over to the new SFP before the SFPR for the old SFP gets withdrawn. This avoids any race conditions with SFPR advertisements 🧚
And finally, a controller SHOULD NOT reuse an SPI after it has withdrawn the SFPR that used it, until at least a configurable amount of time has passed. This timer SHOULD have a default of one hour ⏰💅
4. Mode of Operation 🎀
This document describes using BGP as a control plane to create and manage a service function overlay network 💖
4.1. Route Targets 👑
The main feature this document introduces is the ability to create multiple service function overlay networks by using Route Targets (RTs) [RFC4364] 🌈
Every BGP UPDATE containing an SFIR or SFPR carries one or more RTs. Which RT a particular SFIR or SFPR carries is decided by the provisioning of the route's originator ✨
Every node in a service function overlay network is configured with one or more import RTs. So each SFF imports only the SFPRs with matching RTs, which lets you build multiple service function overlay networks or instantiate SFCs within a Layer 3 Virtual Private Network (L3VPN) or Ethernet VPN (EVPN) instance (see Section 7.3) 🦋 An SFF that has a presence in multiple service function overlay networks (that is, one that imports more than one RT) will usually keep separate forwarding state for each overlay network 🫶
4.2. Service Function Instance Routes
okay so the SFIR (see Section 3.1) is basically the advert that says "hey, this specific SFI exists and here's where it lives" 📍🦋 It has three parts:
- The RT, the one we just talked about 💅
- A Service Function Type (SFT), which is the kind of service the function provides (like "firewall") 🔥
- A Route Distinguisher (RD) that's unique to a specific overlay 🌈
4.3. Service Function Path Routes
The SFPR (see Section 3.2) describes one specific path through an SFC 🛤️ It carries the Service Path Identifier (SPI), which is what names the SFP in the NSH in the data plane 🧚 It also has a sequence of Service Indexes (SIs). Each SI points at a hop in the SFP, and each hop is a choice between one or more SFIs 💖
As described in this document, each SFP route is identified in the service function overlay network by an RD and an SPI. The SPI is unique within a single VPN instance supported by the underlay network 🎀
The SFPR advertisement is made up of:
- An RT as described in Section 4.1.
- A tuple that identifies the SFPR.
- An RD that identifies an advertisement of an SFPR.
- The SPI that uniquely identifies this path within the VPN instance distinguished by the RD. This SPI also shows up in the NSH.
- A series of SIs. Each SI is used in the context of a particular SPI and identifies one or more SFs (told apart by their SFTs). For each SF, it identifies a set of SFIs that instantiate that SF. The values of the SI show the order the SFs run in, within the SFP represented by the SPI 🔢
- The SI is used in the NSH to identify the entries in the SFP. The SI values only mean something relative to one specific path. They don't carry any other meaning beyond the order of the SFs in the path, and they're assumed to be monotonically decreasing from the start of the path to the end [RFC8300] 📉
- Each SI is tied to a set of one or more SFIs that can handle the indexed SF in the path. Each member of that set has:
- The RD used in an SFIR advertisement of the SFI.
- The SFT that says what type of function it is, as used in that same SFIR advertisement of the SFI.
Here's the summary, where "SFPR-RD" and "SFIR-RD" are the two different RDs, and "*" means multiplier 🧮
RT, {SFPR-RD, SPI}, m * {SI, {n * {SFT, p * SFIR-RD} } }Where:
RT: Route TargetSFPR-RD: The Route Descriptor of the SFPR advertisementSPI: Service Path Identifier used in the NSHm: The number of hops in the SFPn: The number of choices of SFT for a specific hopp: The number of choices of SFI for a given SFT in a specific hopSI: Service Index used in the NSH to indicate a specific hopSFT: The Service Function Type used in the same advertisement of the SFIRSFIR-RD: The Route Descriptor used in an advertisement of the SFIR
So yeah, there can be multiple SFTs at a single hop, as described in Section 5 ✨
Note that the values of SI come from the set {255, ..., 1} and they're monotonically decreasing within the SFP. SIs MUST appear in order within the SFPR (i.e., monotonically decreasing) and MUST NOT appear more than once. Gaps MAY appear in the sequence, as described in Section 4.5.1. Malformed SFPRs MUST be discarded, and they MUST cause any previous instance of the SFPR (same SFPR-RD and SPI) to be discarded too 🚫
Malformed SFPRs get thrown out, and they also wipe out the older copy of the same SFPR (same SFPR-RD and SPI). Don't let a bad one sneak in 😭
Note that if the SFIR-RD list in an SFT TLV contains one or more SFIR Pool Identifiers, then in the expression above, "p" is the sum of two things: the number of individual SFIR-RD values, plus the sum, for each SFIR Pool Identifier, of the number of SFIRs advertised with that Pool Identifier. In other words, the SFIR-RD list is effectively expanded to include the SFIR-RD of every SFIR advertised under each SFIR Pool Identifier in the list 🧩
The choice of SFI is explained further in Section 5. Also, an SFIR-RD value of zero has special meaning, which gets covered in that section too 👑
4.4. Classifier Operation
As shown in Figure 1, the classifier is the component that assigns packets to an SFP 🚦
The classifier is responsible for figuring out which packet flow a packet belongs to. The mechanism it uses for that is out of the scope of this document, but it might include inspecting the packet header 🔍 The classifier has been told (by the controller or through some other configuration mechanism -- see Section 7.4) which flows go to which SFPs. That means it can impose an NSH on each packet and initialize the NSH with the SPI of the selected SFP and the SI of its first hop 🎯
Note that the instructions delivered to the classifier may include info about the metadata to encode (and the format for that encoding) on packets classified to a particular SFP. As mentioned in Section 2.2, this is the fifth element of control plane functionality described in [RFC7665] 🧠 Those instructions are outside the scope of this specification (but see Section 7.4), and so are instructions to other service function chaining elements on how to interpret metadata (the sixth element of control plane functionality described in [RFC7665]) 🙈
4.5. Service Function Forwarder Operation
Every packet sent to an SFF gets sent encapsulated in an NSH 📦 The NSH has an SPI and an SI in it. The SPI tells you which SFPR advertisement announced the SFP, and the SPI/SI pair points at one specific hop in one specific path. That pair maps to the RD/SFT of a particular SFIR advertisement 🗺️
When an SFF gets an SFPR advertisement, it first checks whether to import the route by looking at the RT 👀 If the SFPR gets imported, the SFF then figures out whether it's on the SFP by looking for its own SFIR-RDs, or any SFIR-RD with value zero, in the SFPR. For each occurrence in the SFP, the SFF creates forwarding state for incoming packets, and forwarding state for outgoing packets that have already been processed by the specified SFI 🔁
The SFF also creates local forwarding state for packets it receives from other SFFs. This state links the SPI/SI in the NSH of the received packet to one or more specific local SFIs, identified by the SFIR-RD/SFT. If several local SFIs match, that's because a single advertisement was made for a set of equivalent SFIs. In that case, the SFF may use local policy (such as load balancing) to decide which SFI gets the received packet ⚖️
The SFF also creates next-hop forwarding state for packets that come back from the local SFI and need to go to the next hop in the SFP. There may be a choice of next hops, as described in Section 4.3. The SFF could install forwarding state for all the potential next hops, or it could just pick a subset to install. If it makes a choice, that choice will be as described in Section 5 🌸
The installed forwarding state can change over time, reacting to changes in the underlay network and to the availability of particular SFIs 📶 Note that the forwarding state describes how one SFF sends packets to another SFF, but not how those packets get routed through the underlay network. SFFs may be connected by tunnels across the underlay, or packets may be addressed to the next SFF and routed through the underlay. Either way, sending across the underlay requires encapsulating the packets with a header for transport in the underlay network 🚀
Note that SFFs only create and store forwarding state for the SFPs they're included in. They don't keep state for every SFP that gets advertised 🙅♀️
An SFF may also install forwarding state to support looping, jumping, and branching. The protocol mechanism for explicit control of looping, jumping, and branching uses a specific reserved SFT value at a given hop of an SFPR, and it's described in Section 6.1 🦋
4.5.1. Processing with "Gaps" in the SI Sequence
The behavior of an SF, as described in [RFC8300], is to decrement the value of the "SI" field in the NSH by one before returning a packet to the local SFF for further processing. So there's a good reason to assume the SFP is made of a series of SFs, each one with an SI value one less than the one before it 🪜
BUT there's an advantage to having nonsuccessive SIs in an SPI 🤭 Think about an SPI that needs an SF inserted or removed. Removing one would leave a "gap" in the sequence of SIs. Inserting one would only work if a gap already existed where the new SF, with its new SI value, could go. Otherwise, all the "downstream" SFs would need to be renumbered 😩
Sure, that renumbering could be done, but it would cause major disruption to the SFC, since every SFF along the SFP would get "reprogrammed". So, to get dynamic modification of an SFP (and even in-service modification), it's desirable to make those changes without changing the SIs of the elements that were there before. That gives much more consistent and predictable behavior during the convergence period, when otherwise the change would have to be fully propagated first 💫
Another approach says any change to an SFP just creates a new SFP that gets a new SPI. All you'd need is to give the classifier a new instruction, and traffic would switch over to the new SFP with the new set of SFs. This approach is practical, but it ignores the fact that the SFP may be referenced by other SFPs (through "branch" instructions) and used by many classifiers. In those cases, the matching configuration changes from a new SPI could ripple out widely and create room for errors that are really hard to trace 😵💫
Therefore, while this document requires that the SI values in an SFP are monotonically decreasing, it makes no assumption that the SI values are sequential. Configuration tools may apply that rule, but they're not required to. To support this, an SFF SHOULD process as follows when it receives a packet:
- If the SI indicates a known entry in the SFP, the SFF MUST process the packet as normal, looking up the SI and determining which local SFI to deliver the packet to. ✅
- If the SI does not match an entry in the SFP, the SFF MUST reduce the SI value to the next (smaller) value present in the SFP and process the packet using that SI. ⬇️
- If there is no smaller SI (i.e., if the end of the SFP has been reached), the SFF MUST treat the SI value as not valid, as described in [RFC8300]. 🛑
This makes the behavior described in this document a superset of the function in [RFC8300]. In other words, an implementation that strictly follows RFC 8300 and performs SI decrements in units of one is perfectly in line with the mechanisms defined here 🫶
SFF implementations MAY choose to only support contiguous SI values in an SFP. Such an implementation will not support receiving an SI value that isn't present in the SFP, and it will discard those packets as described in [RFC8300] 🧹
5. Selection within Service Function Paths ✨
Okay bestie, so back in Section 2 we said the SPI/SI that comes back from an SFI to the SFF can leave the SFF with a choice 🦋: a choice of next-hop SFTs, and a choice of SFIs for each SFT. The SPI points to an SFPR, the SI points to an entry in that SFPR, and each entry is a set of one or more SFT/SFIR-RD pairs. The SFF MUST choose one of these, identify the SFF that supports the chosen SFI, and send the packet to that next-hop SFF. 💅
The choice may be offered for load balancing across multiple SFIs, or for picking between different actions that a specific hop in the SFP needs. Different SFT values can show up at one hop in an SFP for a couple of reasons:
- There may be multiple instances of similar service functions that are told apart by different SFT values. For example, firewalls made by vendor A and vendor B may need different SFT values because, even though they do similar things, they don't behave exactly the same 🧱. Some SFPs might limit the choice of SF at a given hop by naming the SFT for vendor A, while other SFPs don't care which vendor's SF gets used, so they can say that either SFT is fine ✨.
- There may be an obvious branch in an SFP, like the processing after a firewall. Admitted packets keep going along the SFP, but suspicious packets get diverted to a "penalty box" 📦. In this case, the next hop in the SFP is indicated with two different SFT values.
In the typical case, the SFF picks a next-hop SFF by looking at the whole set of SFFs that support the SFs identified by the SI (that set was advertised in individual SFIR advertisements) 🗺️. It finds the one or more that are "nearest" in the underlay network, then chooses between those next-hop SFFs using its own load-balancing algorithm.
An SFI can influence this choice by passing extra information back along with the packet and NSH 🎀. That information can push local policy at the SFF to favor a particular next-hop SFF (maybe one that is not the nearest in the underlay), or it can influence the load-balancing algorithm.
This selection applies to the normal case, and it also applies to looping, jumping, and branching (see Section 6).
Suppose an SFF in a particular service function overlay network (identified by a particular import RT, RT-z) needs to forward an NSH-encapsulated packet whose SPI is SPI-x and whose SI is SI-y. Here's what it does:
- It looks for an installed SFPR that carries RT-z and has SPI-x in its NLRI. If there is none, then such packets cannot be forwarded 😭.
- From the SFP attribute of that SFPR, it finds the Hop TLV with SI value set to SI-y. If there is no such Hop TLV, then such packets cannot be forwarded.
- It then finds the "relevant" set of SFIRs by going through the list of SFT TLVs contained in the Hop TLV, like this:
- A. An SFIR is relevant if it carries RT-z, the SFT in its NLRI matches the SFT value in one of the SFT TLVs, and the RD value in its NLRI matches an entry in the list of SFIR-RDs in that SFT TLV.
- B. If an entry in the SFIR-RD list of an SFT TLV contains the value zero, then an SFIR is relevant if it carries RT-z and the SFT in its NLRI matches the SFT value in that SFT TLV. So basically, any SFIR in the service function overlay network defined by RT-z with the correct SFT is relevant 🌈.
- C. If a pool identifier is in use, then an SFIR is relevant if it is a member of the pool.
Each of the relevant SFIRs identifies a single SFI and contains a tunnel encapsulation attribute that says how to send a packet to that SFI 🚇. For a particular packet, the SFF chooses one particular SFI from the set of relevant SFIRs, and that choice is made according to local policy.
A typical policy might be to figure out the set of SFIs that are closest and then load balance among them. But that's not the only possible policy, so don't think it's the only option 🙈.
So, any time an SFF selects its next hop, it chooses from the intersection of the set of next-hop RDs contained in the SFPR and the RDs contained in the SFF's local set of SFIRs (in other words, based on the "relevance" determination above). If that intersection is null, the SFPR is unusable 💀. The same goes for the controller that originated the SFPR: when this condition applies there, it SHOULD either withdraw the SFPR or re-advertise it with a new set of RDs for the affected hop 🔁.
6. Looping, Jumping, and Branching 🔄
As described in Section 2, an SFI or an SFF can make a packet "loop back" to a previous SF on a path so that a sequence of functions can be re-run 🔁. This is achieved simply by replacing the SI in the NSH with a higher value, instead of decreasing it like normal, to figure out the next hop in the path.
Section 2 also describes how an SFI or SFF can make a packet "jump forward" to an SF on a path that isn't the immediate next SF in the SFP ⏩. This is achieved simply by replacing the SI in the NSH with a lower value than the one you'd get by decreasing it by the normal amount.
A more complicated option for moving packets from one SFP to another is described in [RFC8300] and Section 2, where it's called "branching" 🌿. This lets an SFI or SFF choose among downstream treatments for packets based on local policy and the output of the local SF. Branching works by changing the SPI in the NSH to indicate the new path, and setting the SI to indicate the point in that path where the packets enter.
Heads up, bestie: the NSH does not include a marker that says whether a specific packet has already been around a loop before. So the use of NSH metadata [RFC8300] may be required to prevent infinite loops 🌀😵💫.
6.1. Protocol Control of Looping, Jumping, and Branching
If the SFT value in an SFT TLV in an SFPR is the special-purpose SFT value "Change Sequence" (see Section 10), that's a signal that the SFF may make a loop, jump, or branch according to local policy and the information returned by the local SFI 🎯.
In this case, the SPI and SI of the next hop are encoded in the eight bytes of an entry in the SFIR-RD list, like this:
3 bytes SPI
1 byte SI
4 bytes Reserved (SHOULD be set to zero and ignored)If the SI in this encoding is not part of the SFPR indicated by the SPI in this encoding, that's an explicit error. It SHOULD be detected by the SFF when it parses the SFPR 🚨. The SFPR SHOULD NOT cause any forwarding state to be installed in the SFF, and packets received with the SPI that indicates this SFPR SHOULD be silently discarded 🫥.
If the SPI in this encoding is unknown, the SFF SHOULD NOT install any forwarding state for this SFPR, but it MAY hold the SFPR pending receipt of another SFPR that does use the encoded SPI ⏳.
If the SPI matches the current SPI for the path, this is a loop or a jump. In this case, if the SI is greater than or equal to the current SI, it's a loop 🔁. If the SPI matches and the SI is less than the next SI, it's a jump ⏩.
If the SPI indicates another path, this is a branch, and the SI indicates the point at which to enter that path 🌿.
The "Change Sequence" SFT is just another SFT that may appear in a set of SFI/SFT tuples within an SI, and it gets selected the same way described in Section 5 💅.
Note that special-purpose SFTs MUST NOT be advertised in SFIRs. If one of these SFIRs is received, it SHOULD be ignored 🙅♀️.
6.2. Implications for Forwarding State
Support for looping and jumping requires that the SFF has forwarding state established to an SFF that provides access to an instance of the appropriate SF. That means the SFF must have seen the relevant SFIR advertisements, and must have known that it needed to create the forwarding state 🧠. This is a matter of local configuration and implementation. For example, an implementation could be configured to install forwarding state for specific looping or jumping ⚙️.
Support for branching requires that the SFF has forwarding state established to an SFF that provides access to an instance of the appropriate entry SF on the other SFP. That means the SFF must have seen the relevant SFIR and SFPR advertisements, and must have known that it needed to create the forwarding state. This is also a matter of local configuration and implementation. For example, an implementation could be configured to install forwarding state for specific branching (identified by SPI and SI) 🌸.
7. Advanced Topics 🌈
This section highlights several advanced topics that were introduced elsewhere in this document 👑.
7.1. Correlating Service Function Path Instances
It's often useful to create bidirectional SFPs so packet flows can traverse the same set of SFs, but in reverse order 🔀. The catch is that packets on SFPs in the data plane (per [RFC8300]) don't carry a direction indicator, so each direction has to use a different SPI 🙃.
As described in Section 3.2.1.1, an SFPR can contain one or more correlators encoded in Association TLVs. If the Association Type indicates "Bidirectional SFP", then the SFP advertised in the SFPR is one direction of a bidirectional pair of SFPs. The other one in the pair is advertised in the SFPR with the RD carried in the Associated SFPR-RD field of the Association TLV 💞. The SPI carried in the Associated SPI field of the Association TLV gives you a cross-check against the SPI advertised in that SFPR ✅.
As noted in Section 3.2.1.1, when SFPRs reference each other, one SFPR advertisement will be received before the other. So processing an association requires that the first SFPR not be rejected just because the Associated SFPR-RD it carries is unknown 🫶. The SFP defined by the first SFPR is valid, and it SHOULD be available for use as a unidirectional SFP, even if its partner was never advertised 🦋.
And in error cases where SFPR-a associates with SFPR-b, but SFPR-b associates with SFPR-c so that a bidirectional pair can't be formed, the individual SFPs are still valid and SHOULD be available for use as unidirectional SFPs. An implementation SHOULD log this situation, because it represents a controller error 🚩.
A bidirectional SFP can be programmed into the classifiers by the controller 🎛️. Alternatively, a classifier can look at incoming packets on a bidirectional packet flow, extract the SPI from the received NSH, and look up the SFPR to find the reverse-direction SFP to use when it sends packets 🔍.
See Section 8 for an example of how this works 💖.
7.2. Considerations for Stateful Service Functions ✨
Okay so some service functions are stateful 🧠, which means they build and maintain state from their configuration or from the packet flows they handle 💅. For those, it can be super important (or straight up necessary) that every packet in a flow keeps going through the same instance of that service function, so the state can be used and doesn't have to get rebuilt 🫶.
For bidirectional SFPs, it may be necessary to hit the same instances of a stateful SF in both directions. A firewall is the classic example 🔥.
This gets tricky when there are multiple parallel instances of an SF, and the SFF could normally just pick one as a load-balancing or local-policy call 🤔.
For the forward-direction SFP, the goal is that the same SF choice gets made for all packets of a flow under normal network conditions 💖. It might be possible to guarantee that the SFF load-balancing is stable and repeatable, but a controller building SFPs might not want to trust that 🙈. So the controller can build a bunch of more specific SFPs, each traversing one specific instance of the stateful SFs 🦋. Then the load-balancing choice gets handed to the classifier, and the classifier picks which instance a flow uses just by picking which SFP that flow rides ✨.
For bidirectional SFPs where the same instance of a stateful SF must be traversed in both directions, leaving the choice of SFI as a local choice is not enough, even if the load balancing is stable 😭. The decision points in the forward and reverse directions would need to coordinate, and that's hard to pull off in every case, except where the same SFF makes the choice in both directions 🥺.
Heads up: this approach definitely increases the amount of SFP state in the network (aka there are more SFPs) 📈. You can mitigate that a bit by carefully building SFPs out of a concatenation of other SFPs 🧩.
Section 8.9 has some simple examples of SFPs for stateful SFs 📚.
7.3. VPN Considerations and Private Service Functions 🎀
Likely deployments include reserving specific SF instances for specific customers, or letting customers deploy their own SFs within the network 🏢. Building SFs in those environments means you need suitable identifiers, so the SFFs can tell which SFIs they're allowed to use and which they're not 🔐.
This is kind of like a problem in how VPNs get supported, and it's solved in a similar way 💜. The "RT" field is used to indicate a set of SFs from which all choices must be made 👑.
7.4. Flow Specification for SFC Classifiers 🌊
[RFC8955] defines a set of BGP routes that can identify the packets in a given flow using fields in each packet's header, plus a set of actions (encoded as Extended Communities) that can disposition those packets 📡. This document lets SFC classifiers use these mechanisms by defining a new action Extended Community called "Flow Specification for SFC Classifiers", identified by the value 0x0d 🎯.
Note that implementing this section means controllers or classifiers talking directly to each other, so the classifier knows how to place packets onto an SFP 🤝. To keep classifier implementations simple, and to avoid mixing up the purposes of different Extended Communities, a controller MUST NOT include other action Extended Communities at the same time as a "Flow Specification for SFC Classifiers" Extended Community 🙅♀️. A "Flow Specification for SFC Classifiers" Traffic Filtering Action Extended Community advertised with any other Traffic Filtering Action Extended Community MUST be treated as malformed in line with [RFC8955], and result in the flow-specification UPDATE message being handled as "treat-as-withdraw", according to [RFC7606], Section 2 ⚠️.
To put the flow specification into context: when multiple service function chaining overlays are present in one network, each FlowSpec update MUST be tagged with the route target of the overlay or VPN network it's meant for 🗺️.
This Extended Community is encoded as an 8-octet value, as shown in Figure 10 🧩.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x80 | Sub-Type=0x0d | SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI (cont.) | SI | SFT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: The Format of the Flow Specification for SFC
Classifiers Extended CommunityThe Extended Community carries the Service Path Identifier (SPI), Service Index (SI), and Service Function Type (SFT), as defined elsewhere in this document 💫. So each action Extended Community defines the entry point (not necessarily the first hop) into a specific SFP. That means, for example, different flows can enter the same SFP at different points 🚪.
Note that, according to [RFC8955], a given flow-specification update may include multiple of these action Extended Communities. If a given action Extended Community does not contain an installed SFPR with the specified {SPI, SI, SFT}, it MUST NOT be used for dispositioning the packets of the specified flow 🚫.
The normal case of packet classification for service function chaining sees a packet enter the SFP at its first hop 🥇. In that case the SI in the Extended Community is superfluous, and the SFT may be unnecessary too. To handle these cases, a special meaning is assigned to an SI of zero (not a valid value) and an SFT of zero (a reserved value in the registry, see Section 10.5) 🧠.
- If an SFC Classifiers Extended Community is received with SI = 0, then it means that the first hop of the SFP indicated by the SPI MUST be used.
- If an SFC Classifiers Extended Community is received with SFT = 0, then there are two subcases:
- If there is a choice of SFT in the hop indicated by the value of the SI (including SI = 0), then SFT = 0 means there is a free choice of which SFT to use, according to local policy).
- If there is no choice of SFT in the hop indicated by the value of SI, then SFT = 0 means that the value of the SFT at that hop, as indicated in the SFPR for the indicated SPI, MUST be used.
One of the filters the flow specification may describe is the VPN the traffic belongs to 🎟️. And, as noted above, to put the indicated SPI into context when multiple SFC overlays are present in one network, each FlowSpec update MUST be tagged with the route target of the overlay or VPN network it's meant for 💅.
Future extensions might give the classifier instructions about what metadata to add to the packets it classifies for forwarding on a specific SFP 🔮. That's outside the scope of this document, though 🙃.
7.5. Choice of Data Plane SPI/SI Representation 🦋
This document ties together the control and data planes of a service function chaining overlay network through the SPI/SI that's nominally carried in the NSH of a given packet 🔗. But when the NSH isn't ubiquitously deployed, it's also possible to use alternative data plane representations of the SPI/SI, carrying the identical semantics in other protocol fields, such as MPLS labels [RFC8595] 🏷️.
This document defines a new Sub-TLV for the tunnel encapsulation attribute [RFC9012], the SPI/SI Representation Sub-TLV of type 16 🎀. This Sub-TLV MAY be present in each Tunnel TLV contained in a tunnel encapsulation attribute when the attribute is carried by an SFIR. The "Value" field of this Sub-TLV is a two-octet field of flags, numbered counting from the most significant bit. Each flag describes how the originating SFF expects to see the SPI/SI represented in the data plane for packets carried in the tunnels described by the Tunnel TLV 🧃.
The following bits are defined by this document and are tracked in an IANA registry described in Section 10.10 📋:
- Bit 0: If this bit is set, the NSH is to be used to carry the SPI/SI in the data plane.
- Bit 1: If this bit is set, two labels in an MPLS label stack are to be used as described in Section 7.5.1.
If a given Tunnel TLV does not contain an SPI/SI Representation Sub-TLV, then it MUST be processed as if such a Sub-TLV is present with Bit 0 set and no other bits set. That is, the absence of the Sub-TLV SHALL be interpreted to mean that the NSH is to be used 🥰.
If a given Tunnel TLV contains an SPI/SI Representation Sub-TLV with a "Value" field that has no flag set, then the tunnel indicated by the Tunnel TLV MUST NOT be used for forwarding SFC packets 🙅♀️. If a given Tunnel TLV contains an SPI/SI Representation Sub-TLV with both bit 0 and bit 1 set, then the tunnel indicated by the Tunnel TLV MUST NOT be used for forwarding SFC packets either 🚫. The meaning and rules for the presence of other bits are to be defined in future documents, but implementations of this specification MUST set other bits to zero and ignore them on receipt 🧹.
If a given Tunnel TLV contains more than one SPI/SI Representation Sub-TLV, then the first one MUST be considered and subsequent instances MUST be ignored 👀.
Note that the MPLS representation of the logical NSH may be used even if the tunnel is not an MPLS tunnel. Conversely, MPLS tunnels may be used to carry other encodings of the logical NSH (specifically, the NSH itself) 🔁. It is a requirement that both ends of a tunnel over the underlay network know that the tunnel is used for service function chaining, and know what form of NSH representation is used. The signaling mechanism described here allows coordination of this information 🤝.
7.5.1. MPLS Representation of the SPI/SI 💜
If bit 1 is set in the SPI/SI Representation Sub-TLV, then labels in the MPLS label stack are used to indicate SFC forwarding and processing instructions, achieving the semantics of a logical NSH ✨. The label stack is encoded as shown in [RFC8595] 🏷️.
7.6. MPLS Label Swapping/Stacking Operation 🧚
Okay bestie, so when a classifier builds an MPLS label stack for an SFP, it starts at that SFP's last hop 💅. If the last hop needs an {SPI, SI} label pair for label swapping, it pushes the SI (set to the SI value of the last hop) and the SFP's SPI onto the MPLS label stack. If the last hop needs a {context label, SFI label} label pair for label stacking instead, it picks a specific SFIR and pushes that SFIR's SFI label and context label onto the stack ✨
Then the classifier walks back through the SFP one hop at a time 🔙. For each hop, if that hop needs an {SPI, SI} and there's already an {SPI, SI} at the top of the stack, the SI just gets set to the SI value of the current hop. If there isn't an {SPI, SI} at the top, it pushes the SI (set to the SI value of the current hop) and the SFP's SPI onto the stack 🫶
And if the hop needs a {context label, SFI label}, it selects a specific SFIR and pushes that SFIR's SFI label and context label onto the MPLS label stack 🌸
7.7. Support for MPLS-Encapsulated NSH Packets 🦋
[RFC8596] describes how to transport SFC packets using the NSH over an MPLS transport network. This document supports signaling that this approach is in use, and it does so like this:
- A "BGP Tunnel Encapsulation Attribute" Sub-TLV is included with the codepoint 10 (representing "MPLS Label Stack") from the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry defined in [RFC9012].
- An "SFP Traversal With MPLS Label Stack" TLV is included containing an "SPI/SI Representation" Sub-TLV with bit 0 set and bit 1 cleared.
In this case, the MPLS label stack that an SFF builds to forward a packet to the next SFF on the SFP will consist of the labels needed to reach that SFF 🛤️. If label stacking is used, it will also include the labels advertised in the MPLS Label Stack Sub-TLV, plus the labels still left in the stack that are needed to traverse the rest of the SFP 💜
8. Examples 🎀
Most of the examples in this section use IPv4 addressing 🌈. But there's nothing special about IPv4 in the mechanisms described in this document, so they work just as well for IPv6. A few examples using IPv6 addressing are provided in Section 8.10 ✨
Assume we have a service function overlay network with four SFFs (SFF1, SFF2, SFF3, and SFF4) 🧩. The SFFs have addresses in the underlay network like this:
SFF1 192.0.2.1
SFF2 192.0.2.2
SFF3 192.0.2.3
SFF4 192.0.2.4Each SFF provides access to some SFIs from the four SFTs, SFT=41, SFT=42, SFT=43, and SFT=44, like so:
SFF1 SFT=41 and SFT=42
SFF2 SFT=41 and SFT=43
SFF3 SFT=42 and SFT=44
SFF4 SFT=43 and SFT=44The service function network also has a controller with address 198.51.100.1 🖥️.
This example service function overlay network is shown in Figure 11 🦋:
--------------
| Controller |
| 198.51.100.1 | ------ ------ ------ ------
-------------- | SFI | | SFI | | SFI | | SFI |
|SFT=41| |SFT=42| |SFT=41| |SFT=43|
------ ------ ------ ------
\ / \ /
--------- ---------
---------- | SFF1 | | SFF2 |
Packet --> | | |192.0.2.1| |192.0.2.2|
Flows --> |Classifier| --------- --------- -->Dest
| | -->
---------- --------- ---------
| SFF3 | | SFF4 |
|192.0.2.3| |192.0.2.4|
--------- ---------
/ \ / \
------ ------ ------ ------
| SFI | | SFI | | SFI | | SFI |
|SFT=42| |SFT=44| |SFT=43| |SFT=44|
------ ------ ------ ------
Figure 11: Example Service Function Overlay NetworkThe SFFs advertise routes to the SFIs they support 📣. These advertisements contain RDs that are set according to the network operator's configuration model. In all of these IPv4 examples, we use RDs of Type 1, so the available six octets get split up as four octets for the IPv4 address of the advertising SFF, and two octets that are a local index of the SFI 🍓. This scheme is picked purely for convenience of documentation, and an operator is totally free to use any other scheme, as long as it conforms to the definitions of SFIR and SFPR in Sections 3.1 and 3.2 💅.
So we see the following SFIRs advertised:
RD = 192.0.2.1/1, SFT = 41
RD = 192.0.2.1/2, SFT = 42
RD = 192.0.2.2/1, SFT = 41
RD = 192.0.2.2/2, SFT = 43
RD = 192.0.2.3/7, SFT = 42
RD = 192.0.2.3/8, SFT = 44
RD = 192.0.2.4/5, SFT = 43
RD = 192.0.2.4/6, SFT = 44Note that the addressing used for communicating between SFFs is taken from the tunnel encapsulation attribute of the SFIR, and not from the SFIR-RD 👀.
8.1. Example Explicit SFP with No Choices 🎯
Let's look at the following SFPR:
SFP1: RD = 198.51.100.1/101, SPI = 15,
[SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, SFT = 43, RD = 192.0.2.2/2]The SFP consists of an SF of Type 41 located at SFF1, followed by an SF of Type 43 located at SFF2. This path is fully explicit, so each SFF is offered no choice in forwarding packets along the path 🔒.
SFF1 will receive packets on the path from the classifier and will identify the path from the SPI (15). The initial SI will be 255, so SFF1 will deliver the packets to the SFI for SFT 41 🚀.
When the packets are returned to SFF1 by the SFI, the SI will be decreased to 250 for the next hop. SFF1 has no flexibility in choosing which SFF supports the next-hop SFI, so it will forward the packet to SFF2. SFF2 will send the packets to the SFI that supports SFT 43 before forwarding the packets to their destinations 🏁.
8.2. Example SFP with Choice of SFIs 🎲
SFP2: RD = 198.51.100.1/102, SPI = 16,
[SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, SFT = 43, {RD = 192.0.2.2/2,
RD = 192.0.2.4/5 } ]In this example, the path also consists of an SF of Type 41 located at SFF1, and this is followed by an SF of Type 43. However, this time the SI = 250 offers a choice between the SFI located at SFF2 and the SFI located at SFF4 👯.
SFF1 will receive packets on the path from the classifier and will identify the path from the SPI (16). The initial SI will be 255, so SFF1 will deliver the packets to the SFI for SFT 41 🌟.
When the packets are returned to SFF1 by the SFI, the SI will be decreased to 250 for the next hop. SFF1 now has a choice of next-hop SFFs to execute the next hop in the path. It can forward packets to either SFF2 or SFF4 to execute a function of Type 43. It uses its local load-balancing algorithm to make this choice 🧠. The chosen SFF will send the packets to the SFI that supports SFT 43 before forwarding the packets to their destinations.
8.3. Example SFP with Open Choice of SFIs 🌍
SFP3: RD = 198.51.100.1/103, SPI = 17,
[SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, SFT = 44, RD = 0]In this example, the path also consists of an SF of Type 41 located at SFF1, followed by an SI with an RD of zero and an SF of Type 44. This means a choice can be made between any SFF that supports an SFI of Type 44 🫧.
SFF1 will receive packets on the path from the classifier and will identify the path from the SPI (17). The initial SI will be 255, so SFF1 will deliver the packets to the SFI for SFT 41 🐣.
When the packets are returned to SFF1 by the SFI, the SI will be decreased to 250 for the next hop. SFF1 now has a free choice of next-hop SFFs to execute the next hop in the path, selecting between all SFFs that support SFs of Type 44. Looking at the SFIRs it has received, SFF1 knows that SF Type 44 is supported by SFF3 and SFF4 🔍. SFF1 uses its local load-balancing algorithm to make this choice. The chosen SFF will send the packets to the SFI that supports SFT 44 before forwarding the packets to their destinations 🎀.
8.4. Example SFP with Choice of SFTs 🦄
SFP4: RD = 198.51.100.1/104, SPI = 18,
[SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, {SFT = 43, RD = 192.0.2.2/2,
SFT = 44, RD = 192.0.2.3/8 } ]This example provides a choice of SF type in the second hop of the path. The SI of 250 indicates a choice between SF Type 43 located at SF2 and SF Type 44 located at SF3 🧁.
SFF1 will receive packets on the path from the classifier and will identify the path from the SPI (18). The initial SI will be 255, so SFF1 will deliver the packets to the SFI for SFT 41 🌷.
When the packets are returned to SFF1 by the SFI, the SI will be decreased to 250 for the next hop. SFF1 now has a free choice of next-hop SFFs to execute the next hop in the path, selecting between all SFFs that support an SF of Type 43 and SFF3, which supports an SF of Type 44. These may be completely different functions that get executed depending on specific conditions, or they may be similar functions identified with different type identifiers (such as firewalls from different vendors) 🔥. SFF1 uses its local policy and load-balancing algorithm to make this choice, and it may use additional information passed back from the local SFI to help inform its selection. The chosen SFF will send the packets to the SFI that supports the chosen SFT before forwarding the packets to their destinations 💖.
8.5. Example Correlated Bidirectional SFPs 🔁
SFP5: RD = 198.51.100.1/105, SPI = 19,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/106, Assoc-SPI = 20,
[SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, SFT = 43, RD = 192.0.2.2/2]
SFP6: RD = 198.51.100.1/106, SPI = 20,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/105, Assoc-SPI = 19,
[SI = 254, SFT = 43, RD = 192.0.2.2/2],
[SI = 249, SFT = 41, RD = 192.0.2.1/1]This example shows two SFPs being correlated to form a bidirectional SFP, as described in Section 7.1 💞.
The controller advertises two SFPRs. They have different SPIs (19 and 20), so they're known to be separate SFPs, but they both have Association TLVs with Association Type set to 1, which indicates bidirectional SFPs. Each has an "Associated SFPR-RD" field containing the value of the other SFPR-RD, so the two SFPs get correlated as a bidirectional pair 🧦.
As you can see from the SFPRs in this example, the paths are symmetric: the hops in SFP5 appear in reverse order in SFP6 🪞✨
8.6. Example Correlated Asymmetrical Bidirectional SFPs ✨
SFP7: RD = 198.51.100.1/107, SPI = 21,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/108, Assoc-SPI = 22,
[SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, SFT = 43, RD = 192.0.2.2/2]
SFP8: RD = 198.51.100.1/108, SPI = 22,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/107, Assoc-SPI = 21,
[SI = 254, SFT = 44, RD = 192.0.2.4/6],
[SI = 249, SFT = 41, RD = 192.0.2.1/1]okay so asymmetric bidirectional SFPs are a thing too 💅 this example has a pair of SFPs with different SPIs (21 and 22) that are correlated the same way as the one in Section 8.5 🦋
BUT the difference is that the two directions are NOT the same path 👀 both paths include a hop of SF Type 41, but SFP7 also has a hop of SF Type 43 at SFF2, while SFP8 has a hop of SF Type 44 at SFF4. so the forward and reverse trips go through different functions, and that's totally the point 🌸
8.7. Example Looping in an SFP 🔁
SFP9: RD = 198.51.100.1/109, SPI = 23,
[SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, SFT = 44, RD = 192.0.2.4/5],
[SI = 245, {SFT = 1, RD = {SPI=23, SI=255, Rsv=0},
SFT = 42, RD = 192.0.2.3/7 } ]looping and jumping are explained in Section 6 🧚 and this example is an SFP with an explicit loop-back instruction, presented as a choice inside an SFP hop 💖
the first two hops (SI = 255 and SI = 250) are totally normal 🌈 the packets get delivered to SFF1 and SFF4 in turn, for SFs of Type 41 and 44 respectively.
the third hop (SI = 245) is where it gets spicy 🌶️ SFF4 gets a choice of next hop. it can either forward the packets to SFF3 for an SF of Type 42 (that's the second choice), or it can loop back (the first one) 🙈
the loop-back entry in the SFPR for SI = 245 uses the special-purpose SFT value 1 ("Change Sequence") ✨ inside this hop, the RD is read as encoding the SPI and SI of the next hop (see Section 6.1). here the SPI is 23, which means this is a loop or branch, i.e., the next hop is on the same SFP 🔁 and the SI is 255, which is higher than the current SI (245), so yep, that's a loop 💜
SFF4 must make a choice between these two next hops. so the packet either goes to SFF3 with the NSH SI decreased to 245, or it loops back to SFF1 with the NSH SI reset to 255. the choice is made using local policy, info passed back by the local SFI, and details in the packets' metadata that are used to prevent infinite looping 🔥
8.8. Example Branching in an SFP 🌿
SFP10: RD = 198.51.100.1/110, SPI = 24,
[SI = 254, SFT = 42, RD = 192.0.2.3/7],
[SI = 249, SFT = 43, RD = 192.0.2.2/2]
SFP11: RD = 198.51.100.1/111, SPI = 25,
[SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, SFT = 1, RD = {SPI=24, SI=254, Rsv=0}]branching works a lot like looping (and jumping), which you can see in Section 8.7 🦋 the big difference is that there are two SFPs involved this time 👯♀️
SFP10 is the normal path, with packets forwarded to SFF3 and SFF2 for SFs of Type 42 and 43 🍓
SFP11 starts off normal (SFF1 for an SF of Type 41), but then SFF1 processes the next hop and finds a "Change Sequence" special-purpose SFT 👀 the "SFIR-RD" field has an SPI of 24, which points to SFP10 and not the current SFP. the SI in the SFIR-RD is 254, so SFF1 knows that it must set the SPI/SI in the NSH to 24/254 and send the packets to the right SFF, as advertised in the SFPR for SFP10 (that's SFF3) 💅
8.9. Examples of SFPs with Stateful Service Functions 🧁
this section has some examples of setting up SFPs when there's a choice of service functions at a particular hop, and when the choice has to stay consistent in both directions 🫶 the scenarios that lead to this requirement are talked about in Section 7.2.
8.9.1. Forward and Reverse Choice Made at the SFF 🎀
picture the topology in Figure 12 😍 there are three SFFs lined up neatly in a row, and the one in the middle (SFF2) supports three SFIs, all of SFT 42. SFF2 can use these three instances to load balance so no single one gets swamped 💪
------ ------ ------ ------ ------
| SFI | | SFIa | | SFIb | | SFIc | | SFI |
|SFT=41| |SFT=42| |SFT=42| |SFT=42| |SFT=43|
------ ------\ ------ /------ ------
\ \ | / /
--------- --------- ---------
---------- | SFF1 | | SFF2 | | SFF3 |
--> | |..|192.0.2.1|...|192.0.2.2|...|192.0.2.3|-->
--> |Classifier| --------- --------- ---------
| |
----------
Figure 12: Example Where Choice Is Made at the SFFthis leads to these SFIRs getting advertised 📣
RD = 192.0.2.1/11, SFT = 41
RD = 192.0.2.2/11, SFT = 42 (for SFIa)
RD = 192.0.2.2/12, SFT = 42 (for SFIb)
RD = 192.0.2.2/13, SFT = 42 (for SFIc)
RD = 192.0.2.3/11, SFT = 43the controller can make one forward SFP (SFP12), giving SFF2 the choice of which SFI to use for the SFT 42 function 🌸 the load-balancing choice between the three SFIs is assumed to be within what the SFF can do, and if the SFs are stateful, it's assumed the SFF knows that and load balances in a stable, flow-dependent way ✨
SFP12: RD = 198.51.100.1/112, SPI = 26,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/113, Assoc-SPI = 27,
[SI = 255, SFT = 41, RD = 192.0.2.1/11],
[SI = 254, SFT = 42, {RD = 192.0.2.2/11,
192.0.2.2/12,
192.0.2.2/13 }],
[SI = 253, SFT = 43, RD = 192.0.2.3/11]the reverse SFP (SFP13) can also be made like this, using the association with the forward SFP and giving the load-balancing choice to SFF2 too 🔄 this is safe even when the SFs of Type 42 are stateful, because SFF2 does the load balancing in both directions and can use the same algorithm to make sure packets from the same flow use the same SFI, no matter which way they're going 🫶
SFP13: RD = 198.51.100.1/113, SPI = 27,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/112, Assoc-SPI = 26,
[SI = 255, SFT = 43, RD = 192.0.2.3/11],
[SI = 254, SFT = 42, {RD = 192.0.2.2/11,
192.0.2.2/12,
192.0.2.2/13 }],
[SI = 253, SFT = 41, RD = 192.0.2.1/11]how an SFF knows that an attached SFI is stateful is out of scope for this document 🙈 it's assumed this will be part of how SFIs get registered as local to SFFs. Section 7.2 has more notes about keeping stateful SFIs coordinated in bidirectional SFPs 💜
in general, load balancing and picking the same SFIs in both directions of a bidirectional SFP can be handled by using SFPs that are precisely specified (naming the exact SFIs to use), plus setting up the classifiers at each end so the matching pair of SFPs gets used 💖
8.9.2. Parallel End-to-End SFPs with Shared SFF 🧚
the mechanism in Section 8.9.1 might not be what you want, because it puts a lot of functional expectations on SFF2 to load balance with proper flow identification, stability, and equality in both directions 😭 so it can be nicer to leave flow classification to the classifier and let it decide the load balancing, which means it also decides the SFI choice 🦋
take the network graph in Figure 12 with the same set of SFIRs from Section 8.9.1 🌈 here the controller could specify three forward SFPs, each with its own associated reverse SFP. every bidirectional pair uses a different SFI for the SF of Type 42 ✨ the controller can tell the classifier how to spread traffic across the three bidirectional SFPs, or it can treat them as a group and leave the classifier in charge of balancing the load 💅
SFP14: RD = 198.51.100.1/114, SPI = 28,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/117, Assoc-SPI = 31,
[SI = 255, SFT = 41, RD = 192.0.2.1/11],
[SI = 254, SFT = 42, RD = 192.0.2.2/11],
[SI = 253, SFT = 43, RD = 192.0.2.3/11]
SFP15: RD = 198.51.100.1/115, SPI = 29,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/118, Assoc-SPI = 32,
[SI = 255, SFT = 41, RD = 192.0.2.1/11],
[SI = 254, SFT = 42, RD = 192.0.2.2/12],
[SI = 253, SFT = 43, RD = 192.0.2.3/11]
SFP16: RD = 198.51.100.1/116, SPI = 30,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/119, Assoc-SPI = 33,
[SI = 255, SFT = 41, RD = 192.0.2.1/11],
[SI = 254, SFT = 42, RD = 192.0.2.2/13],
[SI = 253, SFT = 43, RD = 192.0.2.3/11]
SFP17: RD = 198.51.100.1/117, SPI = 31,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/114, Assoc-SPI = 28,
[SI = 255, SFT = 43, RD = 192.0.2.3/11],
[SI = 254, SFT = 42, RD = 192.0.2.2/11],
[SI = 253, SFT = 41, RD = 192.0.2.1/11]
SFP18: RD = 198.51.100.1/118, SPI = 32,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/115, Assoc-SPI = 29,
[SI = 255, SFT = 43, RD = 192.0.2.3/11],
[SI = 254, SFT = 42, RD = 192.0.2.2/12],
[SI = 253, SFT = 41, RD = 192.0.2.1/11]
SFP19: RD = 198.51.100.1/119, SPI = 33,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/116, Assoc-SPI = 30,
[SI = 255, SFT = 43, RD = 192.0.2.3/11],
[SI = 254, SFT = 42, RD = 192.0.2.2/13],
[SI = 253, SFT = 41, RD = 192.0.2.1/11]8.9.3. Parallel End-to-End SFPs with Separate SFFs ✨
Okay so in Sections 8.9.1 and 8.9.2, the SFI choice hangs off the same SFF 💅. But it's also possible for each SFI to hang off a different SFF, like in Figure 13 🦋. Here's the tricky part: coordinating the forward and reverse choices gets really hard unless SFF1 and SFF3 are doing some kind of coordinating together 🙈. So it would be totally normal to go with end-to-end parallel SFPs instead, the way Section 8.9.2 explains.
------
| SFIa |
|SFT=42|
------
------ |
| SFI | ---------
|SFT=41| | SFF5 |
------ ..|192.0.2.5|..
| ..: --------- :..
---------.: :.---------
---------- | SFF1 | --------- | SFF3 |
--> | |..|192.0.2.1|....| SFF6 |....|192.0.2.3| -->
--> |Classifier| ---------: |192.0.2.6| :---------
| | : --------- : |
---------- : | : ------
: ------ : | SFI |
:.. | SFIb | ..: |SFT=43|
:.. |SFT=42| ..: ------
: ------ :
:.---------.:
| SFF7 |
|192.0.2.7|
---------
|
------
| SFIc |
|SFT=42|
------Figure 13: Second Example with Parallel End-to-End SFPs
Okay, so here we get five SFIRs advertised, like this 🌸:
RD = 192.0.2.1/11, SFT = 41
RD = 192.0.2.5/11, SFT = 42 (for SFIa)
RD = 192.0.2.6/11, SFT = 42 (for SFIb)
RD = 192.0.2.7/11, SFT = 42 (for SFIc)
RD = 192.0.2.3/11, SFT = 43In this setup, the controller could specify three forward SFPs, each with its own matching reverse SFP 🎀. Every bidirectional pair uses a different SFF and SFI for the middle hop (the one for an SF of Type 42). The controller can tell the classifier how to put traffic on those three bidirectional SFPs, or it can treat them as a group and let the classifier handle the load balancing ⚖️.
SFP20: RD = 198.51.100.1/120, SPI = 34,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/123, Assoc-SPI = 37,
[SI = 255, SFT = 41, RD = 192.0.2.1/11],
[SI = 254, SFT = 42, RD = 192.0.2.5/11],
[SI = 253, SFT = 43, RD = 192.0.2.3/11]
SFP21: RD = 198.51.100.1/121, SPI = 35,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/124, Assoc-SPI = 38,
[SI = 255, SFT = 41, RD = 192.0.2.1/11],
[SI = 254, SFT = 42, RD = 192.0.2.6/11],
[SI = 253, SFT = 43, RD = 192.0.2.3/11]
SFP22: RD = 198.51.100.1/122, SPI = 36,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/125, Assoc-SPI = 39,
[SI = 255, SFT = 41, RD = 192.0.2.1/11],
[SI = 254, SFT = 42, RD = 192.0.2.7/11],
[SI = 253, SFT = 43, RD = 192.0.2.3/11]
SFP23: RD = 198.51.100.1/123, SPI = 37,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/120, Assoc-SPI = 34,
[SI = 255, SFT = 43, RD = 192.0.2.3/11],
[SI = 254, SFT = 42, RD = 192.0.2.5/11],
[SI = 253, SFT = 41, RD = 192.0.2.1/11]
SFP24: RD = 198.51.100.1/124, SPI = 38,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/121, Assoc-SPI = 35,
[SI = 255, SFT = 43, RD = 192.0.2.3/11],
[SI = 254, SFT = 42, RD = 192.0.2.6/11],
[SI = 253, SFT = 41, RD = 192.0.2.1/11]
SFP25: RD = 198.51.100.1/125, SPI = 39,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/122, Assoc-SPI = 36,
[SI = 255, SFT = 43, RD = 192.0.2.3/11],
[SI = 254, SFT = 42, RD = 192.0.2.7/11],
[SI = 253, SFT = 41, RD = 192.0.2.1/11]8.9.4. Parallel SFPs Downstream of the Choice 🧚
The parallel SFP mechanism from Section 8.9.3 totally works and could be practical in lots of environments 💜. That said, scaling can get messy 😭, because you end up holding a huge pile of state (that's the SFP knowledge, meaning the SFPR advertisements you keep around). This happens when there are tons of possible SFIs (think tens of instances of the same stateful SF) or when a path has several choices of stateful SF. One way to soften that is to use SFP fragments that get combined into the end-to-end SFPs 🫶.
The example here is intentionally simple, but it gets the main idea across 🌈. Figure 14 looks a lot like the one in Section 8.9.3, except it adds an extra first hop ✨.
------
| SFIa |
|SFT=43|
------
------ ------ |
| SFI | | SFI | ---------
|SFT=41| |SFT=42| | SFF5 |
------ ------ ..|192.0.2.5|..
| | ..: --------- :..
--------- ---------.: :.---------
------ | SFF1 | | SFF2 | --------- | SFF3 |
-->|Class-|.|192.0.2.1|.|192.0.2.2|....| SFF6 |....|192.0.2.3|-->
-->| ifier| --------- ---------: |192.0.2.6| :---------
------ : --------- : |
: | : ------
: ------ : | SFI |
:.. | SFIb | ..: |SFT=44|
:.. |SFT=43| ..: ------
: ------ :
:.---------.:
| SFF7 |
|192.0.2.7|
---------
|
------
| SFIc |
|SFT=43|
------Figure 14: Example with Parallel SFPs Downstream of Choice
Here are the six SFIs, all advertised 🍓:
RD = 192.0.2.1/11, SFT = 41
RD = 192.0.2.2/11, SFT = 42
RD = 192.0.2.5/11, SFT = 43 (for SFIa)
RD = 192.0.2.6/11, SFT = 43 (for SFIb)
RD = 192.0.2.7/11, SFT = 43 (for SFIc)
RD = 192.0.2.3/11, SFT = 44Okay, so SFF2 is where the load-balancing choice actually happens 👑. That means the "tail-end" SFPs get built like this. Each one starts at a different SFF that gives access to an SF of Type 43.
SFP26: RD = 198.51.100.1/126, SPI = 40,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/130, Assoc-SPI = 44,
[SI = 255, SFT = 43, RD = 192.0.2.5/11],
[SI = 254, SFT = 44, RD = 192.0.2.3/11]
SFP27: RD = 198.51.100.1/127, SPI = 41,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/131, Assoc-SPI = 45,
[SI = 255, SFT = 43, RD = 192.0.2.6/11],
[SI = 254, SFT = 44, RD = 192.0.2.3/11]
SFP28: RD = 198.51.100.1/128, SPI = 42,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/132, Assoc-SPI = 46,
[SI = 255, SFT = 43, RD = 192.0.2.7/11],
[SI = 254, SFT = 44, RD = 192.0.2.3/11]Now we can build an end-to-end SFP that includes the load-balancing choice 🔥. The choice SFF2 makes is written as entering one of those three "tail-end" SFPs.
SFP29: RD = 198.51.100.1/129, SPI = 43,
[SI = 255, SFT = 41, RD = 192.0.2.1/11],
[SI = 254, SFT = 42, RD = 192.0.2.2/11],
[SI = 253, {SFT = 1, RD = {SPI=40, SI=255, Rsv=0},
RD = {SPI=41, SI=255, Rsv=0},
RD = {SPI=42, SI=255, Rsv=0} } ]Even though the load-balancing choice happens somewhere other than the initial classifier, the reverse SFPs can still be built cleanly with zero ambiguity 🦋. The three reverse paths look like this.
SFP30: RD = 198.51.100.1/130, SPI = 44,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/126, Assoc-SPI = 40,
[SI = 255, SFT = 44, RD = 192.0.2.4/11],
[SI = 254, SFT = 43, RD = 192.0.2.5/11],
[SI = 253, SFT = 42, RD = 192.0.2.2/11],
[SI = 252, SFT = 41, RD = 192.0.2.1/11]
SFP31: RD = 198.51.100.1/131, SPI = 45,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/127, Assoc-SPI = 41,
[SI = 255, SFT = 44, RD = 192.0.2.4/11],
[SI = 254, SFT = 43, RD = 192.0.2.6/11],
[SI = 253, SFT = 42, RD = 192.0.2.2/11],
[SI = 252, SFT = 41, RD = 192.0.2.1/11]
SFP32: RD = 198.51.100.1/132, SPI = 46,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/128, Assoc-SPI = 42,
[SI = 255, SFT = 44, RD = 192.0.2.4/11],
[SI = 254, SFT = 43, RD = 192.0.2.7/11],
[SI = 253, SFT = 42, RD = 192.0.2.2/11],
[SI = 252, SFT = 41, RD = 192.0.2.1/11]8.10. Examples Using IPv6 Addressing 🌈
okay so this section is giving IPv6 examples, and bestie, the big reveal is that there is nothing special or clever about using IPv6 addresses instead of IPv4 ones 💅 the examples work the exact same way.
The reference network for these IPv6 examples is based on the one described at the top of Section 8 and shown in Figure 11. 🦋
Let's say we have a service function overlay network with four SFFs (SFF1, SFF3, SFF3, and SFF4). 🧚 Their addresses in the underlay network are:
SFF1 2001:db8::192:0:2:1
SFF2 2001:db8::192:0:2:2
SFF3 2001:db8::192:0:2:3
SFF4 2001:db8::192:0:2:4Each SFF gives access to some SFIs from the four service function types SFT=41, SFT=42, SFT=43, and SFT=44, just like before 🍓
SFF1 SFT=41 and SFT=42
SFF2 SFT=41 and SFT=43
SFF3 SFT=42 and SFT=44
SFF4 SFT=43 and SFT=44The service function network also has a controller with the address 2001:db8::198:51:100:1. 👑
This example overlay is shown in Figure 15. ✨
------------------------
| Controller |
| 2001:db8::198:51:100:1 |
------------------------
------ ------ ------ ------
| SFI | | SFI | | SFI | | SFI |
|SFT=41| |SFT=42| |SFT=41| |SFT=43|
------ ------ ------ ------
\ / \ /
------------------- -------------------
| SFF1 | | SFF2 |
|2001:db8::192:0:2:1| |2001:db8::192:0:2:2|
------------------- -------------------
----------
Packet --> | | -->
Flows --> |Classifier| -->Dest
| | -->
----------
------------------- -------------------
| SFF3 | | SFF4 |
|2001:db8::192:0:2:3| |2001:db8::192:0:2:4|
------------------- -------------------
/ \ / \
------ ------ ------ ------
| SFI | | SFI | | SFI | | SFI |
|SFT=42| |SFT=44| |SFT=43| |SFT=44|
------ ------ ------ ------Figure 15: Example Service Function Overlay Network
The SFFs advertise routes to the SFIs they support. 📣 These advertisements carry RDs that are set according to the network operator's configuration model. Note that in an IPv6 network, the RD isn't big enough to hold the full IPv6 address, because only six octets are available. 🙈 So, in all of these IPv6 examples, we use RDs of Type 1, where the six available octets are split into four octets for the IPv4 address of the advertising SFF and two octets that are a local index of the SFI.
We've also picked an IPv6 addressing scheme where the low-order four octets of the IPv6 address match an IPv4 address of the advertising node. 💖 This is purely for convenience in the docs, and an operator is totally free to use any other scheme, as long as it conforms to the definitions of SFIR and SFPR in Sections 3.1 and 3.2. Operators, you do you! 🫶
Observant readers will notice that this makes the BGP advertisements in these examples exactly the same as in the previous examples. The only difference is that the advertising SFFs and controller now have IPv6 addresses. 🤓
So, the following SFIRs get advertised.
The SFFs advertise routes to the SFIs they support, so we see the following SFIRs:
RD = 192.0.2.1/1, SFT = 41
RD = 192.0.2.1/2, SFT = 42
RD = 192.0.2.2/1, SFT = 41
RD = 192.0.2.2/2, SFT = 43
RD = 192.0.2.3/7, SFT = 42
RD = 192.0.2.3/8, SFT = 44
RD = 192.0.2.4/5, SFT = 43
RD = 192.0.2.4/6, SFT = 44Note that the addressing used for communicating between SFFs comes from the tunnel encapsulation attribute of the SFIR, and not from the SFIR-RD. 🎀
8.10.1. Example Explicit SFP with No Choices
Let's look at the following SFPR, which is similar to the one in Section 8.1. 🌸
SFP1: RD = 198.51.100.1/101, SPI = 15,
[SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, SFT = 43, RD = 192.0.2.2/2]The SFP is made up of an SF of Type 41 at SFF1, followed by an SF of Type 43 at SFF2. This path is fully explicit, so each SFF gets zero choice about how to forward a packet along the path. Very rigid, very literal, very iconic. 🧱
SFF1 receives packets on the path from the classifier and identifies the path from the SPI (15). The initial SI is 255, so SFF1 delivers the packets to the SFI for SFT 41.
When the packets come back to SFF1 from the SFI, the SI drops to 250 for the next hop. SFF1 has no flexibility in choosing which SFF supports the next-hop SFI, so it forwards the packet to SFF2. SFF2 then sends the packets to the SFI that supports SFT 43 before forwarding them to their destinations. Done and dusted! ✅
8.10.2. Example SFP with Choice of SFIs
SFP2: RD = 198.51.100.1/102, SPI = 16,
[SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, SFT = 43, {RD = 192.0.2.2/2,
RD = 192.0.2.4/5 } ]Okay, this one is lowkey the same vibe as Section 8.2. The path still has an SF of Type 41 at SFF1, followed by an SF of Type 43, but this time the SI = 250 hop gives a choice between the SFI at SFF2 and the SFI at SFF4. ✨
SFF1 receives packets on the path from the classifier and identifies the path from the SPI (16). The initial SI is 255, so SFF1 delivers the packets to the SFI for SFT 41.
When the packets come back to SFF1 from the SFI, the SI drops to 250 for the next hop. Now SFF1 has a choice of next-hop SFFs to run the next hop. It can forward the packets to either SFF2 or SFF4 to run a function of Type 43. It uses its local load-balancing algorithm to decide. The chosen SFF then sends the packets to the SFI that supports SFT 43 before forwarding them to their destinations. 🎯
8.10.3. Example SFP with Open Choice of SFIs
SFP3: RD = 198.51.100.1/103, SPI = 17,
[SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, SFT = 44, RD = 0]This one, like Section 8.3, has an SF of Type 41 at SFF1, followed by an SI with an RD of zero and an SF of Type 44. That means a choice can be made between any SFF that supports an SFI of Type 44. Main character energy 🦋
SFF1 receives packets on the path from the classifier and identifies the path from the SPI (17). The initial SI is 255, so SFF1 delivers the packets to the SFI for SFT 41.
When the packets come back to SFF1 from the SFI, the SI drops to 250 for the next hop. SFF1 now has a free choice of next-hop SFFs, picking from all SFFs that support SFs of Type 44. By looking at the SFIRs it has received, SFF1 knows that SFT 44 is supported by SFF3 and SFF4. SFF1 uses its local load-balancing algorithm to pick one. The chosen SFF sends the packets to the SFI that supports SFT 44 before forwarding them to their destinations. 💜
8.10.4. Example SFP with Choice of SFTs
SFP4: RD = 198.51.100.1/104, SPI = 18,
[SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, {SFT = 43, RD = 192.0.2.2/2,
SFT = 44, RD = 192.0.2.3/8 } ]This example is similar to Section 8.4, and it gives a choice of SF type for the second hop in the path. The SI of 250 means a choice between SF Type 43 located through SF2 and SF Type 44 located at SF3. 🌈
SFF1 receives packets on the path from the classifier and identifies the path from the SPI (18). The initial SI is 255, so SFF1 delivers the packets to the SFI for SFT 41.
When the packets come back to SFF1 from the SFI, the SI drops to 250 for the next hop. SFF1 now has a free choice of next-hop SFFs, selecting between all SFFs that support an SF of Type 43 and SFF3, which supports an SF of Type 44. These could be totally different functions that run depending on specific conditions, or they could be similar functions with different type identifiers (like firewalls from different vendors). 🔥 SFF1 uses its local policy and load-balancing algorithm to choose, and it may use additional information passed back from the local SFI to help inform its selection. The chosen SFF sends the packets to the SFI that supports the chosen SFT before forwarding them to their destinations. Iconic decision-making, honestly. 👑
9. Security Considerations 🔒✨
okay bestie, this is the serious part, so let's go 🫶 The mechanisms in this document use BGP for the control plane. That means techniques like the ones in [RFC5925] can help authenticate BGP sessions, and so the messages between BGP peers. It gets way harder to spoof updates (which could be used to install bogus SFPs or advertise false SIs) or withdrawals 🙈
Further discussion of security considerations for BGP can be found in the BGP specification itself [RFC4271] and the security analysis for BGP [RFC4272]. [RFC5925] talks about why the TCP MD5 signature option isn't appropriate for protecting BGP sessions. [RFC6952] covers BGP keying and authentication issues 🔑
Also, this document depends on other documents that specify BGP Multiprotocol Extensions, plus the documents that define the attributes carried by BGP UPDATEs of the SFC AFI/SAFI. [RFC4760] points out that using AFI/SAFI doesn't change the underlying security issues that already exist in BGP. Extra security measures are covered in [RFC9012] 💅
This document does not fundamentally change the security behavior of BGP deployments. That depends a lot on how the network operator sees risk in their own network. The mechanisms here are scoped to a single domain, as implied by [RFC8300] and noted in Section 2.1 of this document. Using BGP within one domain can help a network operator make easier and more consistent decisions about which security measures to apply. The domain boundary, which BGP enforces by definition, is also a safeguard that stops SFC programming from leaking in either direction at the boundary 🛡️
Service function chaining gives attackers a real opportunity 😭 Packets can be diverted from their normal paths through the network, packets can be made to run unexpected functions, and the functions instantiated in software can be subverted. This specification doesn't change the fact that service function chaining exists, though. Security issues specific to service function chaining are covered in [RFC7665] and [RFC8300] 🌸
This document defines a control plane for service function chaining. Obviously, that's an attack vector for an SFC system, because an attack on this control plane could make the system misbehave. So the security of the BGP system is critically important to the security of the whole service function chaining system 👑 The control plane mechanisms are very similar to the ones used for BGP/MPLS IP VPNs described in [RFC4364], so the security considerations in that document (Section 13) give good guidance for securing service function chaining systems that rely on this specification. The big one to focus on is the need to securely distinguish between messages meant for controlling different SFC overlays. That's similar to needing to tell different VPNs apart. Section 19 of [RFC7432] also has useful guidance on using BGP in a similar environment ✨
Here's another thing to keep in mind: a service function chaining system that uses the procedures in this document also needs communication between a controller and the SFC network elements (specifically the SFFs and classifiers). That communication includes instructing the classifiers using BGP mechanisms (see Section 7.4), so using BGP security is strongly recommended 🔐 It also covers other ways of programming the classifier and instructing the SFFs and SFs. For example, binding SFs to an SFF, or causing tunnels to be established between SFFs. This document doesn't cover those latter mechanisms, so their security is out of scope. Still, these communications are an attack vector on the service function chaining system too, so attention must be paid to making sure they're secure 🚨
There's an intrinsic assumption in service function chaining systems that nodes announcing support for specific SFs actually offer those functions, and that the SFs themselves aren't attacked or subverted. This matters a lot when SFs are implemented as software that can be updated. Protection against this sort of concern is part of the security of any service function chaining system, so it's outside the scope of the control plane mechanisms in this document 🧚
Similarly, there's a vulnerability if a rogue or subverted controller announces SFPs, especially if that controller "takes over" an existing SFP and changes its contents. That's like a rogue BGP speaker entering a routing system, or even a Route Reflector becoming subverted 😱 The protection mechanisms, same as above, include securing BGP sessions and protecting software loads on the controllers 💜
In an environment where there's concern that rogue controllers might get introduced to the network and inject false SFPRs or take over and change existing SFPRs, it is RECOMMENDED that each SFF and classifier be configured with the identities of authorized controllers. That way, the announcement of an SFPR by any other BGP peer would be rejected 🙅♀️
Lastly, Section 3.2.2 makes two operational suggestions that have implications for the stability and security of the mechanisms in this document 🦋
- That modifications to active SFPs not be made.
- That SPIs not be immediately reused.
10. IANA Considerations 🌈
10.1. New BGP AF/SAFI
IANA maintains the "Address Family Numbers" registry. IANA has assigned a new Address Family Number from the "Standards Action" range called "BGP SFC" (31), with this document as a reference 🎀
IANA maintains the "Subsequent Address Family Identifiers (SAFI) Parameters" registry. IANA has assigned a new SAFI value from the "Standards Action" range called "BGP SFC" (9), with this document as a reference ✨
10.2. "SFP attribute" BGP Path Attribute
IANA maintains a registry of "Border Gateway Protocol (BGP) Parameters" with a subregistry of "BGP Path Attributes". IANA has assigned a new Path attribute called "SFP attribute" with a value of 37 and with this document as a reference 💅
10.3. "SFP Attribute TLVs" Registry
IANA maintains a registry of "Border Gateway Protocol (BGP) Parameters". IANA has created a new subregistry called the "SFP Attribute TLVs" registry 🍓
Valid values are in the range 0 to 65535.
- Values 0 and 65535 are marked "Reserved".
- Values 1 through 65534 are to be assigned according to the "First Come First Served" policy [RFC8126].
This document is a reference for this registry.
The registry tracks:
- Type
- Name
- Reference
- Registration Date
The registry is initially populated as follows:
+======+=========================+===========+===================+
| Type | Name | Reference | Registration Date |
+======+=========================+===========+===================+
| 1 | Association TLV | RFC 9015 | 2020-09-02 |
+------+-------------------------+-----------+-------------------+
| 2 | Hop TLV | RFC 9015 | 2020-09-02 |
+------+-------------------------+-----------+-------------------+
| 3 | SFT TLV | RFC 9015 | 2020-09-02 |
+------+-------------------------+-----------+-------------------+
| 4 | MPLS Swapping/Stacking | RFC 9015 | 2020-09-02 |
+------+-------------------------+-----------+-------------------+
| 5 | SFP Traversal With MPLS | RFC 9015 | 2020-09-02 |
+------+-------------------------+-----------+-------------------+
Table 1: SFP Attribute TLVs Subregistry Initial Contents10.4. "SFP Association Type" Registry
IANA maintains a registry of "Border Gateway Protocol (BGP) Parameters". IANA has created a new subregistry called the "SFP Association Type" registry 🦄
Valid values are in the range 0 to 65535.
- Values 0 and 65535 are marked "Reserved".
- Values 1 through 65534 are assigned according to the "First Come First Served" policy [RFC8126].
This document is given as a reference for this registry.
The new registry tracks:
- Association Type
- Name
- Reference
- Registration Date
The registry should initially be populated as follows:
+==================+===================+===========+============+
| Association Type | Name | Reference | Date |
+==================+===================+===========+============+
| 1 | Bidirectional SFP | RFC 9015 | 2020-09-02 |
+------------------+-------------------+-----------+------------+
Table 2: SFP Association Type Subregistry Initial Contents10.5. "Service Function Chaining Service Function Types" Registry 💅
okay bestie, IANA is making a brand-new top-level registry called "Service Function Chaining Service Function Types" 🎀✨
Valid values run from 0 to 65535, so the whole 16-bit range is fair game 🧚
- Values 0 and 65535 are marked "Reserved". 🔒
- Values 1 through 31 are to be assigned by "Standards Action" [RFC8126], and they're called the "special-purpose SFT values" ⭐
- Values 32 through 64495 are assigned under the "First Come First Served" policy [RFC8126] 🍓
- Values 64496 through 65534 are for Private Use, and IANA is not supposed to record them 🙈
This document is given as a reference for this registry 📖
The registry tracks four things:
- Value
- Name
- Reference
- Registration Date
The registry starts out populated like this, and it's giving organized 🦋
+=============+===================+=============+============+
| Value | Name | Reference | Date |
+=============+===================+=============+============+
| 0 | Reserved | RFC 9015 | 2020-09-02 |
+-------------+-------------------+-------------+------------+
| 1 | Change Sequence | RFC 9015 | 2020-09-02 |
+-------------+-------------------+-------------+------------+
| 2-31 | Unassigned | | |
+-------------+-------------------+-------------+------------+
| 32 | Classifier | RFC 9015, | 2020-09-02 |
| | | [BGP-LS-SR] | |
+-------------+-------------------+-------------+------------+
| 33 | Firewall | RFC 9015, | 2020-09-02 |
| | | [BGP-LS-SR] | |
+-------------+-------------------+-------------+------------+
| 34 | Load balancer | RFC 9015, | 2020-09-02 |
| | | [BGP-LS-SR] | |
+-------------+-------------------+-------------+------------+
| 35 | Deep packet | RFC 9015, | 2020-09-02 |
| | inspection engine | [BGP-LS-SR] | |
+-------------+-------------------+-------------+------------+
| 36 | Penalty box | RFC 9015, | 2020-09-02 |
| | | [RFC8300] | |
+-------------+-------------------+-------------+------------+
| 37 | WAN accelerator | RFC 9015, | 2020-09-02 |
| | | [RFC7665], | |
| | | [RFC8300] | |
+-------------+-------------------+-------------+------------+
| 38 | Application | RFC 9015, | 2020-09-02 |
| | accelerator | [RFC7665] | |
+-------------+-------------------+-------------+------------+
| 39 | TCP optimizer | RFC 9015, | 2020-09-02 |
| | | [RFC7665] | |
+-------------+-------------------+-------------+------------+
| 40 | Network Address | RFC 9015, | 2020-09-02 |
| | Translator | [RFC7665] | |
+-------------+-------------------+-------------+------------+
| 41 | NAT44 | RFC 9015, | 2020-09-02 |
| | | [RFC7665], | |
| | | [RFC3022] | |
+-------------+-------------------+-------------+------------+
| 42 | NAT64 | RFC 9015, | 2020-09-02 |
| | | [RFC7665], | |
| | | [RFC6146] | |
+-------------+-------------------+-------------+------------+
| 43 | NPTv6 | RFC 9015, | 2020-09-02 |
| | | [RFC7665], | |
| | | [RFC6296] | |
+-------------+-------------------+-------------+------------+
| 44 | Lawful intercept | RFC 9015, | 2020-09-02 |
| | | [RFC7665] | |
+-------------+-------------------+-------------+------------+
| 45 | HOST_ID injection | RFC 9015, | 2020-09-02 |
| | | [RFC7665] | |
+-------------+-------------------+-------------+------------+
| 46 | HTTP header | RFC 9015, | 2020-09-02 |
| | enrichment | [RFC7665] | |
+-------------+-------------------+-------------+------------+
| 47 | Caching engine | RFC 9015, | 2020-09-02 |
| | | [RFC7665] | |
+-------------+-------------------+-------------+------------+
| 48-64495 | Unassigned | | |
+-------------+-------------------+-------------+------------+
| 64496-65534 | Reserved for | | |
| | Private Use | | |
+-------------+-------------------+-------------+------------+
| 65535 | Reserved, not to | RFC 9015 | 2020-09-02 |
| | be allocated | | |
+-------------+-------------------+-------------+------------+
Table 3: Service Function Chaining Service Function Types
Registry Initial Contents10.6. Flow Specification for SFC Classifiers 🌈
IANA keeps a registry of "Border Gateway Protocol (BGP) Extended Communities", and inside it there's a subregistry called "Generic Transitive Experimental Use Extended Community Sub-Types". IANA has just added a new subtype to it, and this is the entry 🎀
"Flow Specification for SFC Classifiers" with a value of 0x0d and
with this document as the reference.10.7. New BGP Transitive Extended Community Type 🦋
Same registry family here! IANA maintains "Border Gateway Protocol (BGP) Extended Communities" and its subregistry "BGP Transitive Extended Community Types" 💜 IANA has assigned a brand-new type, and it goes like this:
SFC (Sub-Types are defined in the "SFC Extended Community Sub-
Types" registry) with a value of 0x0b and with this document as
the reference.10.8. "SFC Extended Community Sub-Types" Registry 🧚
IANA maintains the "Border Gateway Protocol (BGP) Parameters" registry, and inside it IANA has created a new subregistry called the "SFC Extended Community Sub-Types" registry ✨
IANA has included this note, which is super important, so read it carefully 👑
| This registry contains values of the second octet (the "Sub-
| Type" field) of an extended community when the value of the
| first octet (the "Type" field) is set to 0x0b.The allocation policy for this registry is First Come First Served 💅 Valid values are 0 to 255. The value 0 is reserved and should not be allocated 🙈
IANA has filled this registry with the following entries:
+==========+==========================+===========+============+
| Sub-Type | Name | Reference | Date |
| Value | | | |
+==========+==========================+===========+============+
| 0 | Reserved | RFC 9015 | |
+----------+--------------------------+-----------+------------+
| 1 | SFIR pool identifier | RFC 9015 | 2020-09-02 |
+----------+--------------------------+-----------+------------+
| 2 | MPLS Label Stack Mixed | RFC 9015 | 2020-09-02 |
| | Swapping/Stacking Labels | | |
+----------+--------------------------+-----------+------------+
| 3-255 | Unassigned | | |
+----------+--------------------------+-----------+------------+
Table 4: SFC Extended Community Sub-Types Subregistry
Initial Contents10.9. New SPI/SI Representation Sub-TLV 🍓
IANA has assigned a codepoint from the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry for the "SPI/SI Representation Sub-TLV". It has a value of 16, and this document is the reference 🌸
10.10. "SFC SPI/SI Representation Flags" Registry 🔥
IANA maintains the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry, and it has created an associated registry called the "SFC SPI/SI Representation Flags" registry 💖
Bits are to be assigned by Standards Action. The field is 16 bits long, and bits are counted from the most significant bit as bit zero 🧠
IANA has populated the registry like this:
+=======+=================+===========+
| Value | Name | Reference |
+=======+=================+===========+
| 0 | NSH data plane | RFC 9015 |
+-------+-----------------+-----------+
| 1 | MPLS data plane | RFC 9015 |
+-------+-----------------+-----------+
Table 5: SFC SPI/SI Representation
Flags Registry Initial Contents11. References ✨
11.1. Normative References ✨
These are the must-reads 📚 Every one is a reference the document leans on, so you'll want them handy.
[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.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, https://www.rfc-editor.org/info/rfc4271.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006, https://www.rfc-editor.org/info/rfc4360.
[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.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, https://www.rfc-editor.org/info/rfc4760.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, https://www.rfc-editor.org/info/rfc7432.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, https://www.rfc-editor.org/info/rfc7606.
[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.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, https://www.rfc-editor.org/info/rfc8126.
[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.
[RFC8595] Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based Forwarding Plane for Service Function Chaining", RFC 8595, DOI 10.17487/RFC8595, June 2019, https://www.rfc-editor.org/info/rfc8595.
[RFC8596] Malis, A., Bryant, S., Halpern, J., and W. Henderickx, "MPLS Transport Encapsulation for the Service Function Chaining (SFC) Network Service Header (NSH)", RFC 8596, DOI 10.17487/RFC8596, June 2019, https://www.rfc-editor.org/info/rfc8596.
[RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. Bacher, "Dissemination of Flow Specification Rules", RFC 8955, DOI 10.17487/RFC8955, December 2020, https://www.rfc-editor.org/info/rfc8955.
[RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, "The BGP Tunnel Encapsulation Attribute", RFC 9012, DOI 10.17487/RFC9012, April 2021, https://www.rfc-editor.org/info/rfc9012.
11.2. Informative References 🧚
These are the extra-credit reads 💜 Good to know, not required.
[BGP-LS-SR] Dawra, G., Filsfils, C., Talaulikar, K., Clad, F., Bernier, D., Uttaro, J., Decraene, B., Elmalky, H., Xu, X., Guichard, J., and C. Li, "BGP-LS Advertisement of Segment Routing Service Segments", Work in Progress, Internet-Draft, draft-dawra-idr-bgp-ls-sr-service-segments-05, 15 February 2021, https://tools.ietf.org/html/draft-dawra-idr-bgp-ls-sr-service-segments-05.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, https://www.rfc-editor.org/info/rfc3022.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, DOI 10.17487/RFC4272, January 2006, https://www.rfc-editor.org/info/rfc4272.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, https://www.rfc-editor.org/info/rfc5925.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, https://www.rfc-editor.org/info/rfc6146.
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, https://www.rfc-editor.org/info/rfc6296.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, https://www.rfc-editor.org/info/rfc6952.
[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for Service Function Chaining", RFC 7498, DOI 10.17487/RFC7498, April 2015, https://www.rfc-editor.org/info/rfc7498.
Acknowledgements 🫶
Huge thank-yous to Tony Przygienda, Jeff Haas, and Andy Malis for the helpful comments 💖, and to Joel Halpern for discussions that made this document so much better ✨. Yuanlong Jiang gave a super useful review and caught some important issues 👀. Stephane Litkowski did an exceptionally good and detailed Document Shepherd review 👑.
Andy Malis contributed the text that formed the basis of Section 7.7 🎀.
Brian Carpenter and Martin Vigoureux gave useful reviews during IETF Last Call 🌸. Thanks also to Sheng Jiang, Med Boucadair, Ravi Singh, Benjamin Kaduk, Roman Danyliw, Adam Roach, Alvaro Retana, Barry Leiba, and Murray Kucherawy for review comments 💅. Ketan Talaulikar provided helpful discussion of the SFT codepoint registry 🦋.
Ron Bonica kept us honest on the difference between an RD and an RT 🍓, and Benjamin Kaduk kept us on message about the difference between an RD and an Extended Community 💜.
Contributors 🌈
Stuart Mackie, Juniper Networks
Email: wsmackie@juinper.net
Keyur Patel, Arrcus, Inc.
Email: keyur@arrcus.com
Avinash Lingala, AT&T
Email: ar977m@att.com
Authors' Addresses ⭐
Adrian Farrel, Old Dog Consulting
Email: adrian@olddog.co.uk
John Drake, Juniper Networks
Email: jdrake@juniper.net
Eric Rosen, Juniper Networks
Email: erosen52@gmail.com
Jim Uttaro, AT&T
Email: ju1738@att.com
Luay Jalil, Verizon
Email: luay.jalil@verizon.com
📦 where this page comes from
- ietf: rfc9015 2021-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms