]> Kanagawa Institute of Technology

Japan mishima@nw.kanagawa-it.ac.jp

Kanagawa Institute of Technology

Japan fukagawa@nw.kanagawa-it.ac.jp

Operations and Management srv6ops SRv6 Service Function Chaining Operations Deployment IPv6 This document describes the deployment and operational experience of the SRv6 Service Function Chaining (SFC) architecture described in on an academic IPv6 backbone network. The deployed system integrates SRv6 forwarding, service function management, topology collection, path computation, and flow classification to enable on-demand provisioning of SFC services via a web-based management interface. This document summarizes the deployment architecture and operational workflow, reports on deployment experience and lessons learned, and provides guidance for operators deploying SRv6 SFC services. About This Document Status information for this document may be found at . Discussion of this document takes place on the srv6ops Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Segment Routing over IPv6 (SRv6) enables packet steering through an ordered list of instructions called a segment list. Service Function Chaining (SFC) can be implemented using SRv6 to steer traffic through a sequence of service functions. The architecture of SRv6 SFC with SR-aware functions is described in . This document reports on the deployment and operational experience of this architecture on an academic IPv6 backbone network. It does not define any new protocols or protocol extensions. It describes the deployment environment, system architecture, and operational workflow, and discusses the operational benefits, challenges, lessons learned, and considerations for operators deploying SRv6 SFC services.

Terminology

Terminology Defined in Related RFCs and Internet-Drafts The following terms are used in this document as defined in the related RFCs and Internet-Drafts:

• SR and Segment Identifier (SID) are defined in .
• SRv6 is defined in .
• Headend, Color, and SR Policy are defined in .
• SFC, Service Function, and Service Function Chain are defined in .
• Path Computation Client (PCC) and Path Computation Element (PCE) are defined in .
• The Path Computation Element Communication Protocol (PCEP) is defined in .
• PCEP extensions for IPv6 Segment Routing are defined in .
• PCEP extensions for SR Policy candidate paths are defined in .
• BGP-LS is defined in .
• BGP Flow Specification is defined in and .
• Forwarding Plane, Control Plane, Management Plane, and Application Plane are defined in .
• NFV Infrastructure (NFVI), Virtualized Infrastructure Manager (VIM), and Virtualized Network Function Manager (VNFM) are defined in .
• Service Segment is described in .
• The SRv6 SFC architecture, including the Service Function Manager (SFM) and End.AN, is described in .

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 when, and only when, they appear in all capitals, as shown here.

Deployment Objectives

• Demonstrate the SRv6 SFC architecture on an academic IPv6 backbone spanning geographically distributed sites.
• Demonstrate the feasibility of incremental deployment without modifying existing transit backbone routers.
• Evaluate the operational feasibility of on-demand SFC provisioning.

Deployment Environment Figure 1 shows the physical deployment environment.

Deployment Environment

IPv6 Backbone The deployment was conducted on SINET, Japan's research and education network interconnecting universities and research institutions. SINET provides native IPv6 connectivity among geographically distributed sites.

Data Centers Three geographically distributed data centers in Hokkaido, Kanagawa, and Okinawa were selected to evaluate service chaining over a wide-area network.

Video Source Sites University-operated video source servers were located at Kanagawa, Chiba, Ishikawa, and Okinawa.

NFV Infrastructure and Virtualized Infrastructure Manager Each data center provides NFV Infrastructure (NFVI) to host SR-aware service functions and operates an independent OpenStack-based Virtualized Infrastructure Manager (VIM).

Deployment Architecture The deployment follows the SRv6 SFC architecture described in . The deployed system is organized into four logical planes: the forwarding plane, control plane, management plane, and application plane. The following subsections describe the role of each plane and its realization in the deployed system.

Overall Architecture Figure 2 illustrates the logical architecture of the deployed system.

• The application plane provides the operator interface.
• The control plane performs topology collection, path computation, SR Policy provisioning, and flow classification.
• The management plane deploys and configures service functions.
• The forwarding plane forwards traffic through SR-aware service functions.

The deployed system enables dynamic deployment and operation of SRv6 service function chains while preserving the existing forwarding infrastructure.

Logical Architecture of the Deployed System

Forwarding Plane The forwarding plane consists of the existing IPv6 backbone and SR-aware service functions deployed at geographically distributed data centers. The backbone's transit routers require no SRv6-specific modifications. Traffic is steered through a sequence of service functions using SRv6 segment lists. Each SR-aware service function is associated with an End.AN SID to process packets and forward them to the next segment in the service chain.

Control Plane The control plane is responsible for topology collection, path computation, SR Policy provisioning, and flow classification. It consists of a Path Computation Element (PCE), a Classification Rule Controller, and a BGP daemon. The PCE uses a Traffic Engineering Database (TED) containing topology and resource information to compute paths and provision SR Policies. The Classification Rule Controller generates BGP Flow Specification rules based on flow classification requirements received from the application plane. The BGP daemon provides the following functions:

• Collecting topology information via BGP-LS, including Service SID advertisements.
• Distributing BGP Flow Specification rules generated by the Classification Rule Controller to the SR source nodes.

Management Plane The management plane is responsible for deploying, configuring, and managing the lifecycle of SR-aware service functions. It consists of three logically distinct functions:

• Virtualized Network Function Manager (VNFM): defined in , responsible for managing the lifecycle of service functions, including instantiation, scaling, and termination.
• Virtualized Infrastructure Manager (VIM): defined in , responsible for managing NFVI compute, storage, and network resources. Each data center has an independent VIM. A single VNFM manages the lifecycle of service functions across all data centers, interacting with the corresponding VIMs.
• Service Function Manager (SFM): defined in , responsible for configuring SRv6-specific service parameters, including Service SID allocation and End.AN behavior, after the service function instance becomes operational (Figure 5). The allocation procedure is described in Section 9.1.

Each service function instance operates its own BGP-LS speaker (e.g., an embedded agent or sidecar process). After receiving the Service SID and End.AN configuration from the SFM, the instance advertises its Service SID to the control plane. The instance also reports the configuration result to the SFM. The management plane also supports service function reconfiguration and removal throughout the operational lifecycle of each service function.

Application Plane The application plane consists of an operator-facing web-based management interface together with the service orchestration logic. Based on operator requests, the application plane translates service requirements into intent-based service requests and coordinates the control and management planes to realize them as deployment operations. The application plane could be extended with closed-loop automation functions that use telemetry feedback from the control and management planes. These functions would operate at a higher level of abstraction and remain logically separate from the control and management planes.

Operational Workflow This section describes the operational workflow for deploying and activating an SRv6 service function chain. The workflow begins with an operator service request and concludes with traffic steering through the deployed service functions. The workflow is illustrated in Figures 4-6. The following abbreviations are used:

Abbreviations Used in Figures 4-6

In Figures 5 and 6, Ctrl represents the control-plane components described in Section 5.3 collectively. The BGP daemon handles BGP-LS topology collection and BGP Flow Specification distribution, while the PCE handles path computation and SR Policy provisioning. Figure 4 shows service function instantiation. Consistent with , the VNFM issues the lifecycle request, and the VIM allocates and provisions the underlying NFVI resources.

NF Instantiation | | | | | | Deploy | | | | | VNF | | | | |----------->| | | | | |Instantiate | | | | |----------->| | | | | |Instantiate | | | | |------------>| | | | |Instantiated | | | | |<------------| | | |Instance OK | | | | |<-----------| | | |Instance OK | | | | |<-----------| | | | | | | | ]]>

Figure 5 shows SRv6-specific service configuration after the service function becomes operational, followed by Service SID advertisement.

Service SID Configuration and Advertisement | | | | | Configure | | | | Service SID | | | |---------------->| | | | | Advertise | | | | Service SID | | | |---------------->| | | | | Update TED | |Configuration OK | | | |<----------------| | |Configuration OK | | | |<----------------| | | | | | | ]]>

Figure 6 shows SFC activation, including path computation and SR Policy provisioning, followed by optional Flow Specification installation and traffic steering.

SFC Activation and Traffic Steering | | | | | Compute Path | | | | | | | | Provision | | | | SR Policy | | | |---------------->| | | | | | | | SR Policy OK | | | |<----------------| | | SR Policy OK | | | |<----------------| | | | Request Flow | | | | Classification | | | |---------------->| | | | | FlowSpec | | | |---------------->| | | | | SFC Traffic | | | | Steering | | | |---------------->| | | | | ]]>

Service Request The operational workflow begins when an operator submits a service request through the web-based management interface. A service request typically includes:

• headend and endpoint nodes
• optional flow classification rules
• the required sequence of service functions

The application plane translates these service requirements into deployment requests for the control and management planes.

Network Function Deployment If one or more requested service functions are not currently available, new service functions are deployed. Deployment is triggered by an explicit operator request.

Topology Collection Topology information is continuously collected via BGP-LS, independently of individual service requests. After a service function instance becomes operational, the management plane configures its Service SID and End.AN behavior. Once the configuration has been applied, the instance advertises its Service SID via the BGP-LS extension described in . The instance also reports the configuration result to the SFM. A service function is included in the TED only after its advertisement is received and is excluded when the advertisement is withdrawn. The SFM monitors service function availability and eligibility for traffic steering. When an instance becomes unavailable or is no longer eligible for traffic steering, the SFM SHOULD initiate withdrawal of the corresponding Service SID advertisement without delay. For an Anycast Service SID, the affected node SHOULD withdraw only its own advertisement. The shared SID SHOULD remain available while at least one eligible instance advertises it. Stale or delayed Service SID updates may cause incorrect path computation and steer traffic to unavailable or invalid service functions.

Path Computation When a service request is received, the control plane computes an SR Policy satisfying the requested service chain based on the current network topology and the available service functions stored in the TED.

SR Policy Provisioning As illustrated in Figure 6, the computed SR Policy candidate path is provisioned to the SR source node acting as the PCC, using PCEP . The candidate path contains the SRv6 segment list representing the selected service function chain.

Flow Classification If flow classification is requested, the application plane submits the classification requirements to the Classification Rule Controller in the control plane. The Classification Rule Controller generates the corresponding BGP Flow Specification rules, which are distributed to the SR source node by the BGP daemon. The rules associate matching traffic with an SR Policy identified by the (Color, Endpoint) tuple, following the procedures specified in .

Traffic Steering Once the SR Policy is operational, the SR source node can steer traffic through the selected service functions. When flow classification is requested, traffic steering begins after the corresponding Flow Specification rules are installed. Only traffic matching the installed rules is steered through the service function chain.

Monitoring Operational status is continuously monitored throughout the service lifecycle using telemetry collected from both the network and infrastructure. Operators may also verify traffic steering using SR path tracing or in-band telemetry mechanisms. For content-modifying services, application-layer verification may be required in addition to network and infrastructure monitoring, as discussed in Sections 8.1 and 9.3.

Service Update and Removal The deployed system supports updates throughout the service lifecycle. Typical operations include:

• modifying or removing service function chains
• redeploying failed service functions
• removing service functions

When a service function becomes unavailable, the affected Service Function Node MUST stop processing packets using its Service SID, as specified in . The SFM SHOULD withdraw the corresponding Service SID advertisement as described in Section 6.3. Service updates require coordination among the forwarding, control, management, and application planes to maintain operational consistency. The ordering and verification of update operations are discussed in Section 9.4.

Deployment Experience This section describes the deployment and operational experience of the SRv6 SFC architecture. The system was deployed to support remote video production. The following subsections describe its architecture, the service it supported, and the operational behaviors and design insights observed during the deployment. This section does not specify requirements or recommendations.

Deployed System Architecture The deployment used the environment described in Section 4. The deployed system implements the following components:

• Application plane: a web-based management interface and service orchestration component.
• Control plane: Pola PCE for path computation and SR Policy provisioning, a Classification Rule Controller for generating flow classification rules, and GoBGP for BGP-LS topology collection and BGP Flow Specification distribution.
• Management plane: a VNFM, OpenStack as the VIM, and Ansible as the SFM.
• Forwarding plane: the existing backbone and distributed SR-aware service functions.

Service Deployment Video streams from the source sites described in Section 4.3 were dynamically steered through SR-aware service functions deployed in the Hokkaido, Kanagawa, and Okinawa data centers. The service functions performed video switching, transcoding, color correction, and caption insertion before forwarding the processed streams to the production system. Operators created service function chains through the web-based management interface. The management plane instantiated the distributed service functions, after which Service SIDs were assigned to the instances and the corresponding information was advertised via BGP-LS.

Operational Benefits The deployed system demonstrated several operational benefits.

• No modifications to the existing backbone infrastructure were required for deployment or operation.
• Service functions were deployed on demand using the existing NFV infrastructure.
• SR Policies and Flow Specification rules were automatically generated.
• Operators manage services through an intent-based interface without configuring low-level network details.

Scalability Considerations This deployment demonstrated that additional SR-aware service functions can be introduced without changing the overall control architecture. Once instantiated, configured, and advertised via BGP-LS, these service functions become available for path computation without requiring manual updates to the PCE's service-function configuration.

Lessons Learned This section presents operational observations and design insights gained from the deployment. It focuses on service verification and orchestration timing and consistency.

Service Verification and Observability Verifying end-to-end service correctness requires more than monitoring SR Policy status or the operational state of service functions. For the deployed video processing service, network-layer monitoring alone could not verify processing correctness; application-layer comparison of input and output video streams was needed. For service chains containing multiple content-modifying service functions, checking only the original source and final destination was insufficient to identify which function caused an incorrect result. This experience demonstrated the value of per-function application-layer verification (see Section 9.3).

Service Orchestration Timing and Consistency Issues Correct service operation depends on the ordering and timing of service function readiness, Service SID advertisement, SR Policy provisioning, and Flow Specification installation. Delays in BGP-LS propagation and TED synchronization may cause discrepancies between the actual service function state and the state used for path computation. Installing Flow Specification rules before the corresponding SR Policy becomes operational may leave the intended traffic-steering state unavailable. As specified in , a PCC does not activate the associated traffic-steering state until the SR Policy is available. Therefore, provisioning and verifying the SR Policy before distributing the corresponding Flow Specification rules is RECOMMENDED to reduce transient inconsistencies and simplify operational verification. These observations motivate the operational sequencing recommendations described in Section 9.4.

Operational Considerations SRv6 SFC deployments require coordination among the control, management, and application planes to ensure consistent service operations.

Service SID Allocation Service SID allocation MUST ensure that distinct service functions within the same SRv6 Locator do not inadvertently use the same Function value. When multiple service function instances are intentionally configured to share an Anycast Service SID, the shared SID MUST be treated as a single logical service endpoint. Such sharing MUST be explicitly coordinated to ensure that all instances provide compatible service behavior. Reachability to the node hosting a service function is provided by the SRv6 Locator assigned to that node and advertised through normal IGP/BGP routing. Transit nodes along the path only need to maintain reachability to this Locator; they are not required to be aware of the Service SIDs corresponding to individual service functions providing the End.AN behavior. In this deployment, the SFM checked which Function values were already in use and selected an available value before configuring the corresponding End.AN behavior. This approach reduces the risk of collisions with already allocated Service SIDs and provides a consistent allocation procedure across the distributed data centers.

Failure Recovery Failure recovery follows the mechanisms defined in . Fast reroute at the forwarding plane can maintain network connectivity, but does not necessarily preserve service-level state. During failover, traffic may be redirected to a different service function instance that does not share the processing state of the original instance. For stateful service functions using Anycast SIDs, operators need to consider session affinity and service-state consistency across instances. The required mechanisms depend on the service function and its processing model. Where failover is expected to preserve session or processing state, the deployment MUST provide appropriate mechanisms.

Observability Effective observability for SRv6 SFC involves monitoring multiple aspects of the system, including:

• SRv6 topology and SR Policy state
• Flow classification and traffic steering behavior
• Service function health and availability
• Virtual infrastructure resource utilization
• Application-level service processing results

For content-modifying services, application-layer verification of individual service functions SHOULD compare each function's input and output (see Section 8.1). Packet mirroring capabilities at SRv6 endpoints may provide additional information for service-level monitoring and troubleshooting. The applicability of such capabilities to SRv6 SFC deployments requires further investigation.

Operational Sequencing Automated orchestration SHOULD ensure that service functions are instantiated and configured before their Service SIDs are advertised via BGP-LS. The SFM SHOULD monitor and record the configuration results reported by service function instances. The corresponding SR Policy SHOULD be provisioned and verified before Flow Specification rules are installed to steer traffic through the service chain. When an existing SR Policy is modified or replaced, flow classification rules SHOULD be updated only after the replacement policy has been successfully provisioned and verified. These procedures help avoid transient traffic misclassification and blackholing during service deployment and updates.

Security Considerations The security considerations in , , and apply to this deployment, which relies on the SR domain trust model described in . Operators MUST ensure that SRv6 packets originating outside the trusted SR domain are not processed as SRv6 traffic at domain boundaries. This deployment provisions SR Policies to SR source nodes directly via PCEP, consistent with the PCE-initiated LSP model described in and . Without adequate protection, an attacker could inject or modify PCEP messages to provision unauthorized SR Policies. Operators SHOULD ensure that PCEP sessions used for SR Policy provisioning are protected using appropriate authentication, authorization, and integrity protection mechanisms. Because service functions are instantiated dynamically and become eligible for path computation after Service SID advertisement (see Section 6.3), operators SHOULD ensure that Service SID information is advertised only for authenticated and authorized service functions. The management plane SHOULD verify the identity and integrity of a service function instance before advertising its Service SID into the SR domain. If this verification is not performed, a rogue or compromised service function could be selected during path computation, resulting in traffic being steered to an unauthorized function. Operators SHOULD ensure that topology and Service SID information advertised via BGP-LS is protected against unauthorized modification or injection. Operators SHOULD ensure that BGP-LS topology and Service SID information is distributed only to authorized consumers. Management interfaces SHOULD be protected using mutually authenticated secure transport protocols. Operators SHOULD ensure that flow classification rules and Color values used to associate them with SR Policies are protected against unauthorized modification or injection using appropriate authentication, authorization, and integrity protection mechanisms. Unauthorized modification or compromise of flow classification rules, Color values, or SR Policies may result in unintended traffic steering, service misbehavior, or service disruption.

IANA Considerations This document has no IANA actions.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains. This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed. This memo provides information for the Internet community. This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK] RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP. The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. The extensions for stateful PCE provide active control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs) via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. This document describes the creation and deletion of PCE-initiated LSPs under the stateful PCE model. Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header. This document describes open research challenges for network virtualization. Network virtualization is following a similar path as previously taken by cloud computing. Specifically, cloud computing popularized migration of computing functions (e.g., applications) and storage from local, dedicated, physical resources to remote virtual functions accessible through the Internet. In a similar manner, network virtualization is encouraging migration of networking functions from dedicated physical hardware nodes to a virtualized pool of resources. However, network virtualization can be considered to be a more complex problem than cloud computing as it not only involves virtualization of computing and storage functions but also involves abstraction of the network itself. This document describes current research and engineering challenges in network virtualization including the guarantee of quality of service, performance improvement, support for multiple domains, network slicing, service composition, device virtualization, privacy and security, separation of control concerns, network function placement, and testing. In addition, some proposals are made for new activities in the IETF and IRTF that could address some of these challenges. This document is a product of the Network Function Virtualization Research Group (NFVRG). The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy. Segment Routing (SR) can be used to steer packets through a network using the IPv6 or MPLS data plane, employing the source routing paradigm. An SR Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). Since SR can be applied to both MPLS and IPv6 data planes, a PCE should be able to compute an SR Path for both MPLS and IPv6 data planes. The Path Computation Element Communication Protocol (PCEP) extension and mechanisms to support SR-MPLS have been defined. This document outlines the necessary extensions to support SR for the IPv6 data plane within PCEP. A Segment Routing (SR) Policy is an ordered list of instructions called "segments" that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated. An SR Policy is made of one or more Candidate Paths. This document specifies the Path Computation Element Communication Protocol (PCEP) extension to signal Candidate Paths of an SR Policy. Additionally, this document updates RFC 8231 to allow delegation and setup of an SR Label Switched Path (LSP) without using the path computation request and reply messages. This document is applicable to both Segment Routing over MPLS (SR-MPLS) and Segment Routing over IPv6 (SRv6). China Mobile China Mobile Huawei Technologies Verizon Communications Inc. Huawei Technologies BGP Flow Specification (FlowSpec) provides mechanisms to distribute traffic filtering and steering rules across BGP networks. This document specifies BGP FlowSpec procedures to steer matching traffic flows into Segment Routing (SR) Policies. It defines two modes of operation: transport steering into an SR Policy ("Mode 1"), in SR- MPLS and SRv6 networks, using BGP Extended Communities; and, in SRv6 networks, transport steering combined with an egress service action at the egress node ("Mode 2"), signaled with the BGP Prefix-SID Attribute. Informative References Software-Defined Networking (SDN) refers to a new approach for network programmability, that is, the capacity to initialize, control, change, and manage network behavior dynamically via open interfaces. SDN emphasizes the role of software in running networks through the introduction of an abstraction for the data forwarding plane and, by doing so, separates it from the control plane. This separation allows faster innovation cycles at both planes as experience has already shown. However, there is increasing confusion as to what exactly SDN is, what the layer structure is in an SDN architecture, and how layers interface with each other. This document, a product of the IRTF Software-Defined Networking Research Group (SDNRG), addresses these questions and provides a concise reference for the SDN research community based on relevant peer-reviewed literature, the RFC series, and relevant documents by other standards organizations. This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFCs) in a network. It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, with a focus on those to be standardized in the IETF. This document does not propose solutions, protocols, or extensions to existing protocols. Segment Routing (SR) enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). It depends only on "segments" that are advertised by link-state Interior Gateway Protocols (IGPs). An SR path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), an explicit configuration, or a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic-Engineering (TE) paths, as well as a Path Computation Client (PCC) to request a path subject to certain constraints and optimization criteria in SR networks. This document updates RFC 8408. This document defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute (intra-domain and inter-domain) traffic Flow Specifications for IPv4 unicast and IPv4 BGP/MPLS VPN services. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix. It also specifies BGP Extended Community encoding formats, which can be used to propagate Traffic Filtering Actions along with the Flow Specification NLRI. Those Traffic Filtering Actions encode actions a routing system can take if the packet matches the Flow Specification. This document obsoletes both RFC 5575 and RFC 7674. "Dissemination of Flow Specification Rules" (RFC 8955) provides a Border Gateway Protocol (BGP) extension for the propagation of traffic flow information for the purpose of rate limiting or filtering IPv4 protocol data packets. This document extends RFC 8955 with IPv6 functionality. It also updates RFC 8955 by changing the IANA Flow Spec Component Types registry. In many environments, a component external to a network is called upon to perform computations based on the network topology and the current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network. This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism applies to physical and virtual (e.g., tunnel) IGP links. The mechanism described is subject to policy control. Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs). This document obsoletes RFC 7752 by completely replacing that document. It makes some small changes and clarifications to the previous specification. This document also obsoletes RFC 9029 by incorporating the updates that it made to RFC 7752. LinkedIn Cisco Systems Cisco Systems Cisco Systems Bell Canada AT&T Orange Ericsson Capitalonline Futurewei Technologies Huawei Technologies Service functions are deployed as, physical or virtualized elements along with network nodes or on servers in data centers. Segment Routing (SR) brings in the concept of segments which can be topological or service instructions. Service segments are SR segments that are associated with service functions. SR Policies are used for the setup of paths for steering of traffic through service functions using their service segments. BGP Link-State (BGP-LS) enables distribution of topology information from the network to a controller or an application in general so it can learn the network topology. This document specifies the extensions to BGP-LS for the advertisement of service functions along their associated service segments. The BGP-LS advertisement of service function information along with the network nodes that they are attached to, or associated with, enables controllers compute and setup service paths in the network.

Acknowledgments The authors would like to thank Mitsuru Maruyama, Katsuhiro Sebayashi, Taisei Tanabe, Ryuta Futami, and Takashi Kurimoto for their valuable reviews. This work was partially supported by JST CRONOS (No. JPMJCS24N9).