BGP Control Plane for the Network Service Header in Service Function Chaining
Extracted elements (32)
A controller changing an SFP content is RECOMMENDED to assign a new SPI rather than updating the existing SFPR, so classifiers can transition flows to the new SFP before withdrawal of the old one, eliminating race conditions between advertisement and withdrawal of SFPRs.
An SFIR-RD value of zero in an SFT TLV's SFIR-RD list has the special meaning of 'open choice': any SFIR in the overlay with the correct SFT and RT is relevant. This avoids enumerating all SFIs in the SFPR while still constraining selection to the correct SFT.
SI values in an SFP are required to be monotonically decreasing but not necessarily sequential, allowing insertion or removal of SFs without renumbering downstream SFs. Renumbering all downstream SFs would cause significant SFF disruption during convergence and is avoided by supporting SI gaps.
An SFF that strictly follows RFC 8300 by decrementing SI by exactly one per hop is fully compatible with this specification, since RFC 9015's gap-handling behavior (reducing to the next meaningful SI) is a strict superset of RFC 8300 SI handling.
The SFP Traversal With MPLS Label Stack TLV (type 5) signals that all SFFs on the SFP must use MPLS label swapping/stacking; the SFP is considered unusable unless every SFF at each hop has advertised the MPLS Mixed Swapping/Stacking Extended Community (Sub-Type 2 of the SFC Extended Community).
A BGP UPDATE containing one or more SFIRs MUST include a tunnel encapsulation attribute (RFC 9012), and that attribute MUST contain sufficient information to allow the advertising SFF to identify the overlay or VPN network of a received packet.
A controller MUST NOT include other Traffic Filtering Action Extended Communities alongside a 'Flow Specification for SFC Classifiers' Extended Community. Any such co-occurrence MUST be treated as malformed and handled as treat-as-withdraw per RFC 7606.
If a Tunnel TLV lacks an SPI/SI Representation Sub-TLV, it MUST be treated as if the Sub-TLV is present with only Bit 0 (NSH) set. If the Sub-TLV has no flags set, or both Bit 0 and Bit 1 set simultaneously, the tunnel MUST NOT be used for forwarding SFC packets.
SFP attribute errors for wrong Optional/Transitive bits, length overruns, missing Hop TLV, or missing Sub-TLV MUST be treated as malformed using treat-as-withdraw (RFC 7606). Unknown TLV types MUST be ignored and message processing MUST continue.
SI values in an SFPR MUST appear in monotonically decreasing order and MUST NOT appear more than once. Malformed SFPRs MUST be discarded along with any previous instance of the SFPR sharing the same SFPR-RD and SPI.
Special-purpose SFT values (range 1–31) MUST NOT be advertised in SFIRs. If such an SFIR is received, it SHOULD be ignored.
The nexthop field of the MP_REACH_NLRI attribute carrying SFC NLRIs MUST be set to a loopback address of the advertising SFF.
Two BGP speakers MUST use BGP capabilities advertisements (capability code 1, AFI 31, SAFI 9) to confirm mutual support for SFC NLRIs before exchanging them.
When an SFF receives a packet with an SI not present in the SFP, it MUST reduce the SI to the next smaller value present in the SFP. If no smaller SI exists, the SFF MUST treat the SI as invalid and drop the packet per RFC 8300.
When multiple SFPRs share the same SPI but have different SFPR-RDs, the SFF MUST use the SFPR with the numerically lowest SFPR-RD (treating RDs as 8-octet integers in network byte order) and SHOULD log the occurrence to assist debugging.
IANA assigned AFI 31 and SAFI 9 for the new 'SFC' BGP address family, used to carry Service Function Instance Routes (SFIR, Route Type 1) and Service Function Path Routes (SFPR, Route Type 2).
IANA assigned BGP Path Attribute code 37 for the new 'SFP attribute', an Optional Transitive attribute carrying TLV-structured service function path information.
IANA assigned BGP Transitive Extended Community type 0x0b for the 'SFC Extended Community' and created the 'SFC Extended Community Sub-Types' registry, with Sub-Type 1 (SFIR Pool Identifier) and Sub-Type 2 (MPLS Mixed Swapping/Stacking Labels) as initial entries.
IANA created the 'Service Function Chaining Service Function Types' registry split into three ranges: Standards Action for special-purpose SFT values (1–31), First Come First Served for general SFT assignments, and Private Use for locally managed values not tracked by IANA.
IANA created the 'SFC SPI/SI Representation Flags' registry for the 2-octet flags field in the SPI/SI Representation Sub-TLV (type 16 of RFC 9012 tunnel encapsulation attribute), with Bit 0 for NSH representation and Bit 1 for MPLS label stack representation.
IANA created the 'SFP Attribute TLVs' registry with initial assignments: Association TLV (1), Hop TLV (2), SFT Sub-TLV (3), MPLS Swapping/Stacking Sub-TLV (4), and SFP Traversal With MPLS Label Stack TLV (5).
The SFC mechanisms are intended for use within a single provider's operational domain (as mandated by RFC 8300), which limits the attack surface. However, BGP sessions carrying SFIR and SFPR routes must be secured to prevent unauthorized parties from advertising fraudulent SFPs or SFIs that redirect or intercept traffic flows.
The Association TLV (Type=1) in the SFP attribute has a fixed Length of 12 and carries a 1-octet Association Type, an 8-octet Associated SFPR-RD, and a 3-octet Associated SPI linking this SFPR to another SFPR.
The Flow Specification for SFC Classifiers Extended Community (Type=0x80, Sub-Type=0x0d) is 8 octets encoding a 3-octet SPI, 1-octet SI, and 2-octet SFT. SI=0 means use the first hop of the SFP; SFT=0 means free or implied choice of SFT at the indicated hop.
The Hop TLV (Type=2) contains a 1-octet Service Index (the NSH SI value for this hop) followed by one or more Sub-TLVs in the Hop Details field. At least one Hop TLV MUST be present in an SFP attribute; its absence renders the attribute malformed.
The MPLS Mixed Swapping/Stacking Labels Extended Community (Type=0x0b, Sub-Type=2) is 8 octets containing an SFC Context Label and an SF Label, each a 20-bit MPLS label encoded in a 3-octet field with 4 trailing zero bits.
The SFC NLRI consists of a 2-octet Route Type field, a 2-octet Length field indicating the length of the Route Type specific field in octets, and a variable-length Route Type specific field whose encoding depends on the Route Type.
The SFIR Pool Identifier Extended Community (Type=0x0b, Sub-Type=1) is 8 octets total: 1-octet Type, 1-octet Sub-Type, and a 6-octet Pool Identifier value in network byte order, unique within the scope of an overlay network.
The SFIR Route Type specific NLRI contains an 8-octet Route Distinguisher (RD) of type 0, 1, or 2, followed by a 2-octet Service Function Type (SFT) field identifying the category of service function hosted by the advertising SFF.
The SFP Attribute (type 37, Optional Transitive) carries a sequence of TLVs and Sub-TLVs each with a common format: 1-octet Type, 2-octet Length (octets following the Length field), and variable Value. Content includes zero or more Association TLVs and one or more Hop TLVs.
The SFPR Route Type specific NLRI contains an 8-octet Route Distinguisher (RD) of type 0, 1, or 2, followed by a 3-octet Service Path Identifier (SPI) whose value is placed in the NSH of packets sent on this SFP.
The SFT Sub-TLV (Type=3) carries a 2-octet SFT value followed by a variable-length SFIR-RD List where each entry is 8 octets. Entries with high-order octet 0x00 are SFIR-RDs (RD type 0/1/2); entries with a nonzero high-order octet are SFIR Pool Identifiers (Extended Community type 0x0b).