]> NTT docomo Business / Kanagawa Institute of Technology

Japan w.mishima@ntt.com

NTT docomo Business / Kanagawa Institute of Technology

Japan y.fukagawa@ntt.com

Routing SPRING SRv6 SFC This document describes the architecture of Segment Routing over IPv6 (SRv6) Service Function Chaining (SFC) with SR-aware functions. This architecture provides the following benefits:

• Comprehensive management: centralized control and management of SR Policies, network topology, service functions, and network metrics.
• Simplicity: no SFC proxies, which reduces the number of nodes and address resource consumption.

About This Document Status information for this document may be found at . Discussion of this document takes place on the SPRING 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. SRv6 supports various types of segments, including Prefix Segments, Adjacency Segments, Anycast Segments, and Binding Segments. Service Function Chaining (SFC) can be used in various scenarios (e.g., FW, IPS, IDS, NAT, and DPI). SFC based on Segment Routing (SR) is described in . It defines SRv6 Endpoint Behaviors, such as End.AS, End.AD, and End.AM, that enable the use of SR-unaware functions. This document describes an architecture for SRv6 SFC with SR-aware functions, which provides comprehensive management of SRv6 network resources and 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, SR Domain, Segment ID (SID), SRv6, SR Policy, Prefix Segment, Adjacency Segment, Anycast Segment, Active Segment, and Distributed/Centralized/Hybrid Control Plane defined in .
• SR Source Node and Transit Node defined in .
• SRv6 Endpoint Behavior, and SR Segment Endpoint Node defined in .
• SFC, SFC Proxy, and Service Classification Function defined in .
• Service Segment, SR-Aware Service, SR-Unaware Service, End.AS, End.AD, End.AM, and End.AN defined in .
• Headend, Color, and Endpoint defined in .
• Quality of Service (QoS), Service Level Agreement (SLA), and Service Level Objective (SLO) defined in .
• Forwarding Plane, Control Plane, Management Plane, Application Plane defined in .
• Path Computation Client (PCC), Path Computation Element (PCE), and Traffic Engineering Database (TED) defined in .
• The Path Computation Element Communication Protocol (PCEP) is defined in .
• BGP Link-State (BGP-LS) defined in .
• BGP Flow Specification defined in and .

Newly Defined Terminology The following terms are used in this document as defined below:

• Service Function Node: an SRv6 Segment Endpoint Node that hosts SR-aware functions associated with service segments.
• SRv6 Controller: a controller consisting of a PCE and a Classification Rule Controller.
• Classification Rule Controller: a controller that distributes flow classification rules to SR source nodes.
• Service Function Manager: a manager that configures network function instances and enables SR-aware functions as service segments.

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.

Design Objectives and Assumptions

Goals and Objectives The SRv6 SFC architecture is designed with two main objectives:

• Comprehensive Management: centralized coordination of SR Policies, network topology, service functions, and network metrics. Operators need to satisfy customer service requirements, including SFC requirements (e.g., required service functions and their order) and QoS objectives (e.g., availability, latency, and bandwidth). These requirements collectively define the service intent. Realizing this service intent requires coordinated service segment provisioning, network state collection, and SR Policy computation. describes a hybrid control plane that combines distributed and centralized control. In this model, forwarding information, such as Node and Adjacency SIDs, is distributed among SR nodes through IGPs such as IS-IS and OSPF, while SR Policies and flow classification rules are managed by centralized controllers. Service segment information is configured by the management plane and can be advertised by service function nodes using BGP-LS. The SDN framework enables network abstraction and automation. An SRv6 controller can translate service intents into SR Policies and flow classification rules, coordinate service segment provisioning, monitor network and service function states, and apply protection mechanisms to meet service requirements.
• Simplicity: SR-aware functions do not require dedicated SFC proxies, reducing the number of nodes and address resource consumption. Network complexity increases operational costs, particularly when multiple protocols and additional network components are required. Using an SFC proxy may also increase forwarding overhead due to additional header manipulations.

Assumptions To achieve these objectives, this architecture is based on two main assumptions:

• Straightforward extension of the SRv6 network programming model This architecture follows the SRv6 network programming model and uses standardized protocols and mechanisms, such as BGP, PCEP, IS-IS, OSPF, TI-LFA, and Anycast SIDs, to support traffic steering, SFC, redundancy, and local protection. It can also support SR-unaware functions using appropriate SRv6 endpoint behaviors. However, it is primarily designed for SR-aware functions.
• SDN framework compliance and comprehensive management of SRv6 SFC by controllers The architecture uses standardized protocols and abstract service interfaces to support automated and intent-based management of SRv6 SFC. This also provides programmability by controlling policies that meet a user's intent, including SFC and QoS.

Overview of Architecture Figure 1 illustrates an overview of this architecture.

Overview of SRv6 SFC Architecture with SR-aware Functions

This architecture is based on and consists of the forwarding plane, control plane, management plane, and application plane.

• Forwarding Plane: classifies packets, encapsulates them with an IPv6 header and Segment Routing Header (SRH), and forwards them through SRv6 Endpoint Behaviors.
  • Provides SR-aware functions using End.AN.
  • Classifies and steers traffic flows into corresponding SR Policies using policy-based routing (PBR).
  • Provides redundancy using Anycast SIDs and local protection using Fast Reroute (FRR).
• Control Plane: makes decisions about packet forwarding and provides rules for a forwarding plane.
  • Collects link-state information, including SRv6 locators, prefixes, behaviors, and delays.
  • Calculates and provisions SR Policies.
  • Applies SR Policies to each flow by provisioning flow classification rules.
• Management Plane: deploys and monitors network functions and devices.
  • Sets up network functions.
  • Collects metrics of devices, network functions, and SFC services.
• Application Plane: provides user APIs for the control and management planes.
  • Offers an interface for operators or customers.
  • Supports intent-based networking as described in .

The components are loosely coupled and communicate using standardized protocols and abstraction layers. The detailed design of the application plane is outside the scope of this document, as its components and abstraction layers depend on network requirements and operator intent. The following sections describe the forwarding plane, control plane, and management plane in detail.

Forwarding Plane The forwarding plane realizes SFC through packet classification, SRv6 encapsulation, and service function processing within the SR domain. In this architecture, all forwarding plane components are located within the SR domain.

Forwarding Plane | Node |------------>| Node |------------>| Node |--> | | | | (S1) | | (S2) | | | +-----------+ +----------+ +----------+ | +--------------------------- SR domain ---------------------------+ ]]>

Figure 2 shows an example of SFC with two network functions. First, the SR source node classifies the flow and encapsulates it with an SRH containing the segment list <S1, S2>. Next, the service function node (S1) receives the packet and applies the network function associated with the End.AN SID S1. Finally, the service function node (S2) receives the packet and applies the network function associated with the End.AN SID S2, thus completing the SFC.

End.AN-based Service Segment Provisioning End.AN is an SRv6 Endpoint Behavior for SR-aware service functions. An implementation MAY support optional arguments to provide additional programmability for network functions. By using virtualized environments within routers or on generic servers, network functions can be provided at any node in an SR domain. This allows for scaling and flexible redundancy of network functions.

When a Network Function Becomes Unavailable When a network function becomes unavailable, the affected node MUST stop processing packets using the corresponding SID. For an Anycast SID, the affected node SHOULD withdraw its SID advertisement, allowing routing convergence to direct traffic to another available service function node. If no other service function nodes are available, packets MUST be dropped. The node MAY send an ICMPv6 message (Type 1: Destination Unreachable, Code 0: no route to destination).

Anycast Segment The concept of the Anycast Segment is introduced in . An Anycast SID allows multiple service function nodes providing the same network function to share a common SID, enabling redundancy and traffic distribution. An Anycast SID does not guarantee session continuity or state consistency across service function nodes. For stateful Service Functions, the deployment MUST provide mechanisms to maintain session affinity and ensure service state consistency across instances. When traffic is forwarded to another instance, the deployment MUST ensure that the required service state is available before packet processing. The specific mechanisms for session affinity, state synchronization, and failover are outside the scope of this document.

Fast Reroute The segment list specifies the order of service functions in an SRv6 SFC. FRR MUST preserve the order of service functions specified by the SR Policy when providing local protection for the path to an active segment. If the Active Segment is an Anycast SID, the packet MAY be forwarded to another service function node. The failure recovery mechanisms described in this section are intended to maintain network connectivity and service function node reachability. For stateful service functions, the requirements described in the Anycast Segment section also apply when FRR forwards packets to another service function node.

Service Function Chains In this architecture, each SFC is represented by an SR Policy, whose Color indicates its purpose or intent. An SFC can be realized using either strict or loose source routing. When QoS requirements are also considered, the PCE computes paths that satisfy the specified constraints. Flex-Algo SIDs MAY be used to steer traffic over paths that meet specific constraints.

Per-Flow Classification and Steering In an SR source node, which serves as the Service Classification Function, packets are classified on a per-flow basis using PBR and steered into the corresponding SR Policy. The SR source node MUST support packet classification based on the criteria specified in the flow classification rules, which may include a 5-tuple or more detailed packet information. To support comprehensive management, the Service Classification Function exposes an API for communicating with the controller.

Control Plane The control plane sets up a forwarding plane by creating SR Policies for SFC and provisioning flow classification rules to associate them with traffic flows.

Control Plane Computation | | | | Controller | | Element (PCE) | | | +------|-------+ +-^-------|--------^-+ | +--------|-----------|-------|--------|---+ Classification link-state SR Policy Service Segment Rule (BGP-LS) (PCEP) (BGP-LS) (BGP FlowSpec) | | | +--------|-----------|-------|--------|-------------------+ | +------v-----------|-------v-+ +-|-----------------+ | | | | | Service | | | | SR Source Node |----| Function | | | | | | Node | | | +----------------------------+ +-------------------+ | +------------------- Forwarding Plane --------------------+ ]]>

The SRv6 Controller consists of the following two components:

• PCE: computes SR Policies that fulfill SFC and QoS requirements from the headend to the endpoint, and provisions them to the SR source node.
• Classification Rule Controller: distributes flow classification rules that associate traffic flows with SR Policies to SR source nodes.

Path Computation Element (PCE) A PCE computes and provisions SR Policies. As an active stateful PCE , it establishes PCEP sessions with PCCs in an SR domain and manages SFC-related SR Policies under its stateful control. The PCE MUST support the computation and provisioning of SR Policies with both explicit and dynamic paths. For dynamic path computation, the PCE uses the Constrained Shortest Path First (CSPF) algorithm to compute paths that satisfy the specified service function and QoS constraints. The PCE builds a Traffic Engineering Database (TED) of the SR domain using BGP-LS and installs SR Policies via PCEP . The BGP-LS Service Segment extension can be used to advertise service segment information. The PCE uses this information, together with network topology and traffic engineering metrics, to compute SR Policies that include the required service functions.

Classification Rule Controller A Classification Rule Controller determines which SFC to apply to each traffic flow. The resulting classification rules are distributed to each SR source node using the BGP Flow Specification extension defined in . The rules associate traffic flows with SR Policies identified by their Color and Endpoint. A Color value MAY be reused with different Endpoints or in multiple FlowSpec rules that reference the same SR Policy. The SRv6 Controller is responsible for maintaining the association between traffic classification rules and SR Policies. The PCE computes and provisions SR Policies, whereas the Classification Rule Controller distributes the corresponding FlowSpec rules to SR source nodes. This separation allows traffic classification and path computation to be managed independently within the SRv6 Controller.

Handling SR Policy Unavailability The Stateful PCE monitors the state of SR Policies under its stateful control through PCEP state reporting. When an SR Policy becomes unavailable or is removed from a PCC, the PCE may take appropriate actions, such as recomputing and reprovisioning the SR Policy. FlowSpec rules may be distributed independently of the operational state of their associated SR Policies. A PCC may receive a FlowSpec route before the corresponding SR Policy becomes available. In such a case, the PCC does not activate the associated traffic-steering state until the SR Policy becomes available. The PCC MAY log this condition for operational visibility. This behavior does not require extensions to the BGP Flow Specification encoding or distribution procedures. The SRv6 Controller coordinates the PCE and the Classification Rule Controller as necessary to maintain the association between traffic classification rules and SR Policies. If the existing FlowSpec rule remains applicable to the reprovisioned SR Policy, no change to the rule is necessary. Otherwise, the Classification Rule Controller withdraws the obsolete rule before distributing an updated rule. Once the SR Policy and the corresponding FlowSpec rule are both available at the PCC, the PCC associates the traffic flows with the SR Policy using the Color and Endpoint specified in the FlowSpec rule.

Management Plane The management plane configures network function instances, enables SR-aware functions as service segments, monitors resources, and collects network metrics. The details of each manager are outside the scope of this document, as the southbound interface of the management plane may be different for each service and hardware architecture.

Management Plane

Figure 4 shows examples of managers that MAY be deployed in the management plane:

• Service Function Manager: assigns SIDs to network functions and manages their service segment configuration.
• Virtualized Network Function Manager (VNFM): manages the lifecycle of network functions.
  • It instantiates, configures, scales, heals, updates, and terminates network functions.
• Virtualized Infrastructure Manager (VIM): manages virtualized compute, storage, and network resources.
  • In SRv6 SFC, a VIM MAY manage virtualized environments hosted on generic servers or within routers.
• Network Metrics Manager: collects metrics for SR Policy calculation and evaluation.
  • Metrics are collected from multiple data sources, including IPFIX, TCP statistics, and SRv6 path tracing .
  • Metrics can be used as input for PCE path computation.

Service Function Manager The Service Function Manager configures service function nodes to enable or disable their service segments using the following parameters:

• Behavior: End.AN
• SID: The End.AN SID in IPv6 address format.
• Function Name: The type of network function.
• Action: Enable or disable.
• Management Parameters (OPTIONAL):
  • Function-specific parameters: Parameters and context associated with a particular network function.
  • Anycast Group: Identifies the group of service function nodes sharing an Anycast SID. This parameter MUST be configured when multiple nodes provide the same service function using an Anycast SID.

Security Considerations This document describes an SRv6 SFC architecture using SR-aware functions. The security considerations for SRv6 and its associated control-plane protocols also apply to this architecture. Service Function Nodes MUST validate and filter incoming SRv6 packets to prevent unauthorized access to service functions. Service function information advertised through BGP-LS SHOULD be protected against unauthorized modification or injection, as incorrect information may cause the PCE to compute inappropriate SR Policies. PCEP sessions between the PCE and PCCs SHOULD be protected against unauthorized access and modification. Flow classification rules distributed by the Classification Rule Controller SHOULD be protected against unauthorized modification or injection to prevent unintended traffic steering. Management interfaces used to configure service function instances SHOULD be protected against unauthorized access and modification. For service functions using Anycast SIDs, operators SHOULD consider the security implications of forwarding traffic to different service function instances and synchronizing service state across instances. State synchronization mechanisms SHOULD be protected against unauthorized access and modification. The security mechanisms for the underlying protocols and management interfaces are outside the scope of this document. Implementations and deployments SHOULD follow the relevant security recommendations in the corresponding specifications.

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] 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. 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. 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. Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable. 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. 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) 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. 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. Intent and Intent-Based Networking are taking the industry by storm. At the same time, terms related to Intent-Based Networking are often used loosely and inconsistently, in many cases overlapping and confused with other concepts such as "policy." This document clarifies the concept of "intent" and provides an overview of the functionality that is associated with it. The goal is to contribute towards a common and shared understanding of terms, concepts, and functionality that can be used as the foundation to guide further definition of associated research and engineering problems and their solutions. This document is a product of the IRTF Network Management Research Group (NMRG). It reflects the consensus of the research group, having received many detailed and positive reviews by research group participants. It is published for informational purposes. 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. 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 This document describes the principles of traffic engineering (TE) in the Internet. The document is intended to promote better understanding of the issues surrounding traffic engineering in IP networks and the networks that support IP networking and to provide a common basis for the development of traffic-engineering capabilities for the Internet. The principles, architectures, and methodologies for performance evaluation and performance optimization of operational networks are also discussed. This work was first published as RFC 3272 in May 2002. This document obsoletes RFC 3272 by making a complete update to bring the text in line with best current practices for Internet traffic engineering and to include references to the latest relevant work in the IETF. 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. Cisco Systems, Inc. Cisco Systems, Inc. Cisco Systems, Inc. Broadcom Alibaba, Inc SoftBank Goldman Sachs Arrcus Path Tracing provides a record of the packet path as a sequence of interface ids. In addition, it provides a record of end-to-end delay, per-hop delay, and load on each egress interface along the packet delivery path. Path Tracing allows to trace 14 hops with only a 40-bytes IPv6 Hop- by-Hop extension header. Path Tracing supports fine grained timestamp. It has been designed for linerate hardware implementation in the base pipeline.

Appendix A. Implementation Experience Note to the RFC Editor: Please remove this appendix before publication as an RFC. This appendix is informative and non-normative. Several components of the architecture have been implemented and validated in IETF Hackathons. A.1. Flow-based Service Classification The following functionality has been implemented in GoBGP:

• Advertisement of classification rules using BGP FlowSpec extensions for SRv6 Policy.

A.2. SR Policy Computation and Provisioning The following functionality has been implemented in Pola PCE:

• Centralized SR Policy computation for SFC using a stateful PCE.
• Support for explicit and dynamic SRv6 Policies with loose source routing.

A.3. Service Segment Advertisement The following functionality has been implemented in GoBGP and ExaBGP:

• Advertisement of VNF and End.AN information using BGP-LS Service Segment extensions.

A.4. Service and Infrastructure Management The following functionality has been implemented using OpenStack and Ansible:

• Deployment of VNFs.
• Provisioning of SRv6 End.AN behaviors.

Acknowledgments The authors would like to thank Mitsuru Maruyama, Katsuhiro Sebayashi, Yuma Ito, and Taisei Tanabe for their valuable reviews. This work was partially supported by NICT commissioned research (No. JPJ012368C03101) and JST CRONOS (No. JPMJCS24N9).