SRv6OPS J. Ye, Ed. Internet Draft China Mobile Intended status: Standards Track C. Lin, Ed. Expires: May 05, 2027 New H3C Technologies November 02, 2026 SRv6 SFC Deployment Options draft-ye-srv6ops-sfc-deployment-02 Abstract This document outlines the critical factors for deploying Service Function Chaining (SFC) using Segment Routing over IPv6 (SRv6). It addresses deployment architectures, including both SRv6-aware and SRv6-unaware scenarios, and details the end-to-end provisioning lifecycle. Furthermore, it proposes reliability mechanisms and provides strategic recommendations for network operators transitioning from legacy NSH-based SFC to a modern, scalable SRv6 framework. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 05, 2027. Copyright Notice Copyright (c) 2026 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 Expire May 05, 2027 [Page 1] Internet-Draft SRv6 SFC Deployment Options November 2026 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction...................................................2 1.1. Requirements Language.....................................3 2. Terminology....................................................3 3. Deployment Options.............................................4 3.1. SRv6-Aware SFC............................................4 3.2. SRv6-Unaware SFC..........................................5 3.3. Role Definitions..........................................7 3.4. Deployment Lifecycle......................................8 4. Multi-tenancy Considerations...................................9 5. Reliability Considerations....................................10 5.1. Reliability mechanism....................................10 5.2. Fast Fault Detection:....................................14 6. Deployment Recommendations....................................14 7. IANA Considerations...........................................15 8. Security Considerations.......................................15 9. Acknowledgements..............................................15 10. References...................................................15 10.1. Normative References....................................15 10.2. Informative References..................................15 Contributors.....................................................16 Authors' Addresses...............................................17 1. Introduction Service Function Chaining (SFC) is a network architecture that orchestrates traffic through a sequence of service functions-such as firewalls, load balancers, and deep packet inspection (DPI)-to form a logical processing chain. While traditional networks rely on scattered physical or virtual appliances, SFC leverages standardized mechanisms to dynamically steer traffic, significantly enhancing network flexibility and automation. Historically, the Network Service Header (NSH) defined in [RFC8300] has been the primary encapsulation protocol for SFC. However, widespread adoption of NSH faces three significant challenges: Ye & Lin, et al. Expires May 05, 2027 [Page 2] Internet-Draft SRv6 SFC Deployment Options November 2026 Compatibility: Mainstream hardware switches and operating systems often lack native support for NSH. Scalability: Maintaining per-flow state on every Service Function Forwarder (SFF) and Service Function (SF) creates a management bottleneck as the network scales. Fragmentation: NSH often relies on overlay tunneling (e.g., VXLAN/GRE), complicating the integration between the Overlay and Underlay networks. Segment Routing over IPv6 (SRv6) offers a robust alternative. By leveraging IPv6 extension headers, SRv6 enables source-based routing where the path is encoded directly into the packet. This eliminates the need for complex state maintenance on intermediate nodes and provides end-to-end programmability. This document focuses on the practical deployment of SRv6 SFC. It moves beyond theoretical definitions to provide a comprehensive guide on: Architectural Choices: How to deploy in environments with native SRv6 support versus those requiring legacy compatibility. Operational Workflow: A step-by-step lifecycle from business request to service decommissioning. Reliability: Mechanisms to ensure high availability during failures. Best Practices: Strategic recommendations for network planners and operators. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Terminology SFC (Service Function Chaining): The process of steering traffic through an ordered sequence of service functions. SRv6 (Segment Routing over IPv6): A source-routing technology that uses IPv6 extension headers to encode paths. Ye & Lin, et al. Expires May 05, 2027 [Page 3] Internet-Draft SRv6 SFC Deployment Options November 2026 SF (Service Function): A network function that performs specific operations on traffic (e.g., firewall, NAT). SFF (Service Function Forwarder): The node responsible for steering traffic to the appropriate SF and maintaining the chain logic. SFC Proxy: A functional entity that translates between SRv6 and non- SRv6 protocols (e.g., stripping NSH or raw IP) to enable legacy SFs to participate in an SRv6 chain. SID (Segment Identifier): An IPv6 address used in SRv6 to identify a specific segment or instruction. SRH (Segment Routing Header): The IPv6 extension header carrying the segment list. SRv6-Aware SF: An SF capable of natively processing SRv6 packets (parsing SRH). SRv6-Unaware SF: An SF that cannot process SRv6 packets and requires a proxy or decapsulation. 3. Deployment Options This section discusses the key aspects to consider for SRv6 SFC deployment options. 3.1. SRv6-Aware SFC In this model, all Service Functions in the chain natively support SRv6. +-------+ +-------+ | SF 1 | | SF 2 | | | | | +---+---+ +---+---+ | | | | +--------+ +---+---+ +---+---+ Source ---+ Classi +---+ SFF 1 +----+ SFF 2 +---- Destination | fier | | | | | +--------+ +-------+ +-------+ Figure 1: SRv6 SFC Ye & Lin, et al. Expires May 05, 2027 [Page 4] Internet-Draft SRv6 SFC Deployment Options November 2026 Characteristics: No SFC Proxy is required. The SFF forwards SRv6 packets directly to the SF. The SF processes the packet, updates the SRH (if necessary), and forwards it back to the SFF or to the next hop. Advantages: Lowest latency, simplest control plane, and highest efficiency. Applicability: New deployments or networks where all SFs have been upgraded to support SRv6. 3.2. SRv6-Unaware SFC If an SF node can support SRv6, it is called an SRv6 aware SF; otherwise, it is called an SRv6 unaware SF. If there exists an SRv6 unaware SF in the network, an SFC Proxy needs to be deployed in front of it. The SRv6 proxy caches the mapping relationship between the SRH and the virtual interface connecting the SF, which is used to recover SRv6 packets based on the virtual interface when packets return from the SF. This model is designed for networks containing legacy SFs that do not support SRv6. Characteristics: An SFC Proxy is deployed immediately adjacent to the SRv6-Unaware SF. The Proxy acts as a translator, converting SRv6 packets to a format the SF can understand (e.g., raw IPv4/IPv6 or NSH) and vice versa. Advantages: Enables the integration of legacy infrastructure without immediate hardware replacement. Applicability: Incremental upgrades where replacing all SFs is not feasible. Ye & Lin, et al. Expires May 05, 2027 [Page 5] Internet-Draft SRv6 SFC Deployment Options November 2026 SRv6 unaware +-------+ | SF 1 | | | +---+---+ | | SRv6 aware +---+---+ +-------+ | SFC | | SF 2 | | Proxy | | | +---+---+ +---+---+ | | | | +--------+ +---+---+ +---+---+ Source ---+ Classi +---+ SFF 1 +----+ SFF 2 +---- Destination | fier | | | | | +--------+ +-------+ +-------+ Figure 2: SRv6 SFC with SFC Proxy SF: Functional node (FN) that performs specific operations on traffic. If it can process the SRv6, it is called SRv6-aware SF; otherwise, it is called SRv6-unaware SF. SFC Proxy: Caches the mapping relationship between SRH and the virtual interface connecting SF, which is used to recover SRv6 packets based on the virtual interface when packets return from SF. Whether to deploy the SFC Proxy depends on whether all SF nodes in the current network are SRv6-aware nodes. The choice of proxy method depends on the support status of the SF node. Below are several proxy methods available for selection. Static SR Proxy SFC: The static service chain proxy belongs to SRv6-unaware Service. Since the SF cannot identify SRv6 packets, the SFF needs to decapsulate the SRv6 packet and forward the raw data packet from the Ye & Lin, et al. Expires May 05, 2027 [Page 6] Internet-Draft SRv6 SFC Deployment Options November 2026 customer network to the SF for processing. After the SF processes the original packet, it forwards it back to the SFF node, which then decides whether to continue forwarding the packet within the SRv6 SFC network. If forwarding continues within the SRv6 SFC network, the SFF node must re-encapsulate the processed service packet with an SRv6 header based on a manually configured SID list. Dynamic SR Proxy SFC: Compared to static SR Proxy, dynamic SR Proxy has the ability to learn mapping relationship cache entries. The mapping relationship cache between SRH and the interface connecting SF is dynamically generated based on the SRH of the messages received by SFF. After enabling SFF redundant backup protection function, when the primary SFF senses that it is unreachable to SF, the SRH are not removed. Instead, SFF1 needs to carry the original SRH to the backup SFF. Masquerading SR Proxy SFC: The service chain pseudo proxy also belongs to SRv6-unaware Service. However, the SF can identify IPv6 packets, and the SFF forwards SRv6 packets directly to the SF for processing. After the SF completes the application service processing, it does not process the SRH header information of SRv6, but directly forwards the packet back to the SFF node, where the SFF processes the packet according to the normal SRv6 forwarding procedure. 3.3. Role Definitions The following roles are critical in both topologies: Classifier: The entry point of the SFC. It identifies traffic flows based on policies (e.g., 5-tuple), classifies them, and inserts the initial SRH containing the ordered list of SIDs representing the service chain. SFF (Service Function Forwarder): The core forwarding element. It receives packets with an active SID, determines the next hop (the SF or Proxy), and handles the return traffic from the SF. In the Unaware topology, the SFF manages the interaction with the Proxy. SF (Service Function): The actual application node (e.g., Firewall) that executes the business logic. In Aware Mode: It parses the SRH, executes logic, and forwards based on the next SID. Ye & Lin, et al. Expires May 05, 2027 [Page 7] Internet-Draft SRv6 SFC Deployment Options November 2026 In Unaware Mode: It receives decapsulated traffic, processes it, and returns it to the Proxy/SFF. SFC Proxy: (Required only in Unaware Mode) It maintains a mapping table between the SRH context and the virtual interface connected to the SF. Upon receiving an SRv6 packet, it strips the SRH, forwards the payload to the SF, and upon return, re-encapsulates the packet with the correct SRH to continue the chain. 3.4. Deployment Lifecycle Deploying SRv6 SFC is a structured lifecycle process comprising six key stages: 1. Service Request: The process begins with a business requirement. Stakeholders define the desired service chain (e.g., "All Web traffic must traverse Firewall -> WAF -> Load Balancer") and specify Service Level Agreements (SLAs) regarding latency, bandwidth, and availability. 2. Node Provisioning (Network Element Uplift): Physical or virtual network elements (Classifiers, SFFs, SFs, and Proxies) are deployed or activated. This stage involves configuring the Underlay network (IPv6 addressing, IGP/BGP routing) to ensure basic connectivity between all nodes before SFC logic is applied. 3. SID Allocation: Unique Segment Identifiers (SIDs) are assigned to each SF and Proxy. Static Allocation: SIDs are manually configured for stable, small- scale chains. Dynamic Allocation: A controller assigns SIDs on-demand based on real-time resource availability. A complete Segment List is generated, defining the exact traversal order of the service chain. 4. Configuration Delivery: The control plane (SDN Controller or Orchestrator) pushes the configuration to the data plane. The Classifier receives the policy and the initial Segment List. Ye & Lin, et al. Expires May 05, 2027 [Page 8] Internet-Draft SRv6 SFC Deployment Options November 2026 SFFs receive instructions on how to forward traffic to specific SIDs and handle return traffic. Proxies (if applicable) are configured with the mapping rules between SIDs and local interfaces. Verification steps ensure that all nodes have consistent views of the chain. 5. Network Monitoring: Once the chain is active, continuous monitoring is essential. Connectivity Checks: Mechanisms like BFD (Bidirectional Forwarding Detection) monitor the link between SFF and SF/Proxy. Performance Metrics: Latency, jitter, and packet loss are tracked to ensure SLA compliance. State Validation: The system verifies that packets are traversing the chain in the correct order. 6. Service Modification and Teardown: As business needs evolve, the chain must be adaptable. Modification: Adding new SFs, changing the order, or updating policies triggers a re-calculation of the Segment List and a configuration update. Teardown: When a service is retired, resources (SIDs, mappings) are released, and configurations are removed to prevent stale state accumulation. 4. Multi-tenancy Considerations During deployment, support for multi-tenancy must be considered. One approach is for the Service Function (SF) to assign different SRv6 SIDs for each tenant, with the Classifier encapsulating distinct SRv6 SID sequences per tenant. This method allows the SF to identify the tenant based on the SRv6 SID, offering simple implementation. However, its drawback is that assigning individual SRv6 SIDs for each tenant consumes significant SID resources, which must be evaluated against the number of tenants. An alternative approach is to carry tenant information within the service packet itself. This avoids the need to allocate separate SRv6 SIDs per tenant but results in a more complex system implementation. Ye & Lin, et al. Expires May 05, 2027 [Page 9] Internet-Draft SRv6 SFC Deployment Options November 2026 For instance, as in shown in figure 1, the traffic of tenant A enters vFW through a 3-layer sub-interface with VLAN 'a', while tenant B' s traffic enters through that of VLAN 'b'. With the existence of VLANs and VPN instances, vFW would be able to figure out tenants and select their exclusive vsys instances to supply service. For example, the traffic of tenant A with destined for address X would be dropped by vsys1 instance on vFW, while tenant B's traffic with destination address Y will be dropped by vsys2 instance. +------+ |vsys1 |vFW -+vsys2 | / |... | / +------+ / / +------+ / |vsys1 |vIPS +--+ +----+ |vsys2 | |GW+---+TOR1+------|... | +--+ +----+ | | \ +------+ \ \ \ +------+ \ |vsys1 |vAV -+vsys2 | |... | | | +------+ Figure 3 [I-D.draft-lin-spring-srv6-aware-context-indicator] describes how to use SRv6 SIDs as context indicator for SR-aware services. 5. Reliability Considerations This section discusses the main aspects to consider for SRv6 SFC reliability, including reliability mechanisms and fault detection. 5.1. Reliability mechanism When the Service Function (SF) is unreachable without any protection, packets requiring processing by the application service node (SF) will be dropped upon reaching the Service Function Ye & Lin, et al. Expires May 05, 2027 [Page 10] Internet-Draft SRv6 SFC Deployment Options November 2026 Forwarder (SFF), failing to be forwarded in the intended logical order or processed by the SF. To enhance the reliability of the SRv6 SFC service chain proxy, mechanisms are needed to protect the SFF and improve reliability. For example, dual-homing protection or Bypass protection can be selected to protect the SFF, or a combination of both. SF Dual-Homing Protection: Dual-homing protection refers to an SFF or SFC Proxy being dual- homed to two Services Functions (SFs), one primary and one backup. When the primary SF becomes unreachable, the service switches over to the backup SF for processing. As shown in Figure 3, when a link fault occurs between SF 1 and SFF, the packet is forwarded to SF 1' to handle the service request. As shown in Figure 3, when a link fault occurs between SF 1 and the SFC Proxy, the packet is forwarded to SF 1' to handle the service request. SRv6 aware SRv6 aware +-------+ +-------+ | SF 1 | |SF 1' | | | |Backup | +----+--+ ++--+---+ | / X / | / +--------+ +---+---+ +--------+ Source ---+ Classi +---+ SFF 1 +---+ SFF 2 +---- Destination | fier | | | | | +--------+ +-------+ +--------+ Figure 3: Dual-Homing Protection by SFF Ye & Lin, et al. Expires May 05, 2027 [Page 11] Internet-Draft SRv6 SFC Deployment Options November 2026 SRv6 unaware SRv6 unaware +-------+ +-------+ | SF 1 | |SF 1' | | | |Backup | +----+--+ ++--+---+ | / X / +---+---+/ | SFC + | Proxy | +---+---+ | | +--------+ +---+---+ +--------+ Source ---+ Classi +---+ SFF 1 +---+ SFF 2 +---- Destination | fier | | | | | +--------+ +-------+ +--------+ Figure 4: Dual-Homing Protection by SFC Proxy SF Bypass Protection: Bypass protection refers to the scenario where, in the event of a failure of the application service node SF or SFC Proxy, packets bypass that service node and no longer go through it for processing. As shown in Figure 5, when a link fault occurs between SF 1 and SFF 1, skip the service operation of SF 1 and send the packet to SF 2 to continue executing the service operation of SF 2. As shown in Figure 6, when a link fault occurs between SF 1 and the SFC Proxy, skip the service operation of SF 1 and send the packet to SF 2 to continue executing the service operation. Ye & Lin, et al. Expires May 05, 2027 [Page 12] Internet-Draft SRv6 SFC Deployment Options November 2026 SRv6 aware SRv6 aware +-------+ +-------+ | SF 1 | | SF 2 | | | | | +---+---+ +---+---+ X | | | +--------+ +---+---+ +---+---+ Source ---+ Classi +---+ SFF 1 +----+ SFF 2 +---- Destination | fier | | | | | +--------+ +-------+ +-------+ Figure 5: SF Bypass Protection by SFF SRv6 unaware +-------+ | SF 1 | | | +---+---+ X | SRv6 aware +---+---+ +-------+ | SFC | | SF 2 | | Proxy | | | +---+---+ +---+---+ | | | | +--------+ +---+---+ +---+---+ Source ---+ Classi +---+ SFF 1 +----+ SFF 2 +---- Destination | fier | | | | | +--------+ +-------+ +-------+ Figure 6: SF Bypass Protection by SFC Proxy Mixed SF Dual-Homing Protection and SF Bypass Protection: When SF dual-homing protection and Bypass protection are used together, prioritize executing the dual-homing protection procedure; switch to the Bypass protection procedure only when dual-homing protection fails. When deploying, select whether to support high availability (HA) based on the service's importance and consideration of device costs. Ye & Lin, et al. Expires May 05, 2027 [Page 13] Internet-Draft SRv6 SFC Deployment Options November 2026 5.2. Fast Fault Detection: There needs to be a fast failure detection mechanism to detect reachability between SFF and SF, or between SFF and SFC Proxy. When the SF becomes unreachable, the protection mechanism can be quickly triggered. You can choose to use BFD to detect reachability between SFF and SF, or between SFC Proxy and SR. When the SF becomes unreachable, the dual-homing protection or Bypass protection mechanism for SRv6 SFC service chain can be quickly triggered. The choice of fast fault detection method depends on the requirements for service fault response speed and deployment cost. 6. Deployment Recommendations Based on the architectural and lifecycle analysis, the following recommendations are provided for successful SRv6 SFC deployment: 1. Prioritize Stateless Architectures: For greenfield deployments, adopt Stateless SRv6 SFC exclusively. Avoiding NSH and stateful proxies reduces complexity and maximizes performance. 2. Strategic Use of Proxies: For brownfield upgrades, utilize SFC Proxies to integrate legacy SFs. This allows for a phased migration strategy where SFs can be upgraded to SRv6-aware status over time without disrupting services. 3. Multi-Tenancy Resource Planning: When supporting multiple tenants, carefully evaluate the trade-off between SID consumption and implementation complexity. For small-scale multi-tenancy, assigning unique SIDs per tenant is straightforward. For large-scale environments, consider embedding tenant identifiers within the packet payload to conserve the limited SID space, accepting the increased software complexity. 4. Tiered High Availability: Not all services require the same level of redundancy. Critical Services: MUST implement Dual-Homing to ensure zero downtime. Ye & Lin, et al. Expires May 05, 2027 [Page 14] Internet-Draft SRv6 SFC Deployment Options November 2026 Standard Services: MAY utilize Bypass Protection to maintain connectivity even if a service function fails, acknowledging a temporary loss of specific security or optimization features. 5. Automation is Mandatory: Manual configuration of SRv6 SFC is error-prone and unscalable. Operators MUST implement SDN controllers or orchestration platforms to automate the lifecycle stages from SID allocation to configuration delivery. 6. Security Hardening: Ensure that SRH headers are protected against tampering. Implement validation mechanisms to prevent unauthorized modification of the Segment List, which could redirect traffic to malicious nodes. 7. IANA Considerations TBD. 8. Security Considerations TBD. 9. Acknowledgements TBD. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 10.2. Informative References [RFC7665] Halpern, J., and C. Pignataro, "Service Function Chaining (SFC) Architecture", RFC 7665, October 2015. Ye & Lin, et al. Expires May 05, 2027 [Page 15] Internet-Draft SRv6 SFC Deployment Options November 2026 [RFC8300] Quinn, P., et al., "Network Service Header (NSH)", RFC 8300, January 2018. Contributors Ye & Lin, et al. Expires May 05, 2027 [Page 16] Internet-Draft SRv6 SFC Deployment Options November 2026 Authors' Addresses Jiaming Ye (editor) China Mobile China Email: yejiaming@chinamobile.com Changwang Lin (editor) New H3C Technologies China Email: linchangwang.04414@h3c.com Ye & Lin, et al. Expires May 05, 2027 [Page 17]