SRv6 Service Function Chaining Deployment

2.1. 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) defined in [RFC8402].¶

• SRv6 defined in [RFC8986].¶

• Headend, Color, and SR Policy defined in [RFC9256].¶

• SFC, Service Function, and Service Function Chain defined in [RFC7665].¶

• Path Computation Client (PCC) and Path Computation Element (PCE) are defined in [RFC4655] and [RFC5440], respectively.¶

• PCEP extensions for SR are defined in [RFC8664], with SR Policy candidate path extensions further specified in [RFC9862].¶

• BGP-LS defined in [RFC9552].¶

• BGP Flow Specification defined in [RFC8955].¶

• Forwarding Plane, Control Plane, Management Plane, Application Plane defined in [RFC7426].¶

• NFV Infrastructure (NFVI), Virtualized Infrastructure Manager (VIM), and Virtualized Network Function Manager (VNFM) defined in [RFC8568].¶

• Service Segment described in [I-D.draft-ietf-spring-sr-service-programming].¶

• SRv6 SFC architecture, including the Service Function Manager (SFM) and End.AN, described in [I-D.draft-watal-spring-srv6-sfc-sr-aware-functions].¶

2.2. 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.¶

4.1. 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.¶

4.2. Data Centers

Three geographically distributed data centers in Sapporo, Kanagawa, and Okinawa were selected to evaluate service chaining over a wide-area network. Each data center provides NFV Infrastructure (NFVI).¶

4.3. Video Source Sites

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

4.4. NFV Infrastructure and Virtualized Infrastructure Manager

A virtualized infrastructure was deployed at each selected data center to host SR-aware service functions. Each site operates OpenStack as the Virtualized Infrastructure Manager (VIM).¶

5.1. 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, and SR Policy provisioning.¶

• The management plane deploys and configures service functions.¶

• The forwarding plane forwards traffic through SR-aware service functions.¶

This architecture enables dynamic deployment and operation of SRv6 service function chains while preserving the existing forwarding infrastructure.¶

                      +----------------------+
                      |  Application Plane   |
                      +------+------+--------+
                             |      |
                             |      |
            +----------------+      +-----------------+
            |                                         |
 +----------v-----------+                   +---------v---------+
 |    Control Plane     |                   | Management Plane  |
 +----------+-----------+                   +-------------------+
            |                                         |
            +----------------+      +-----------------+
                             |      |
                      +------v------v------+
                      |  Forwarding Plane  |
                      +--------------------+

5.2. Forwarding Plane

The forwarding plane consists of the backbone and the SR-aware service functions deployed at geographically distributed data centers.¶

Traffic is steered through a sequence of service functions using SRv6 segment lists. Service functions implement the End.AN behavior to process packets and forward them to the next segment in the service chain.¶

The forwarding infrastructure operates on existing backbone routers without requiring modifications, enabling incremental deployment of SRv6 SFC services.¶

The forwarding plane is responsible for packet forwarding and service function execution, while service orchestration and policy decisions are handled by the upper planes.¶

5.3. Control Plane

The control plane is responsible for topology collection, path computation, and SR Policy provisioning.¶

A Path Computation Element (PCE) uses a Traffic Engineering Database (TED) for topology and resource information.¶

A BGP daemon performs two functions:¶

• collecting topology information via BGP-LS, including Service Segment advertisements¶

• distributing traffic classification rules via BGP Flow Specification¶

5.4. Management Plane

The management plane is responsible for deploying, configuring, and managing the lifecycle of SR-aware service functions.¶

The management plane consists of the following three logically distinct functions:¶

• Virtualized Network Function Manager (VNFM): defined in [RFC8568], responsible for the lifecycle management of service functions, including issuing instantiation, scaling, and termination requests.¶

• VIM: defined in [RFC8568], responsible for controlling and managing the underlying NFVI compute, storage, and network resources, and for fulfilling the lifecycle requests issued by the VNFM. Service functions are instantiated on this NFVI, as illustrated in Figure 4.¶

• Service Function Manager (SFM): defined in [I-D.draft-watal-spring-srv6-sfc-sr-aware-functions], responsible for SRv6-specific service configuration after a service function instance becomes operational, including Service SID assignment and endpoint behavior configuration, as illustrated in Figure 5.¶

Each service function instance operates its own BGP-LS speaker (e.g., implemented as an embedded agent or sidecar process) and advertises its configured Service SID directly to the control plane once the SFM-driven configuration described above is complete.¶

The management plane supports reconfiguration and removal of service functions throughout their operational lifecycle.¶

5.5. 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 MAY include closed-loop automation functions that operate on telemetry feedback from the control and management planes.¶

Such mechanisms provide policy refinement and intent optimization based on observed service and network conditions.¶

These functions are logically separated from the control and management planes and operate at a higher level of abstraction.¶

6.1. 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 tailend nodes¶

• optional traffic classification rules¶

• the required sequence of service functions¶

• optional service constraints, such as latency requirements¶

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

6.2. Network Function Deployment

If one or more requested service functions are not currently available, new service functions are deployed.¶

Deployment may be triggered either by an explicit operator request or automatically based on operational policies, such as resource utilization or closed-loop service management.¶

6.3. Service SID Allocation

After service function deployment and initialization, Service SID allocation is performed by the management plane before BGP-LS advertisement, as described in Section 9.1.¶

6.4. Topology Collection

Topology information is continuously collected via BGP-LS independently of individual service requests.¶

Once the service function has completed initialization and health verification, and the Service SID has been configured with the corresponding End.AN behavior, the VNF itself, acting as a BGP-LS speaker, advertises its Service SID information via the BGP-LS extension defined in [I-D.draft-ietf-idr-bgp-ls-sr-service-segments], which is currently under standardization.¶

Until this advertisement is received, or if the advertisement is withdrawn, the service function is not included in the TED and is not considered during path computation.¶

The SFM is responsible for monitoring the operational state of service function instances. When a service function becomes unavailable or is no longer eligible for traffic steering, the SFM MUST withdraw the corresponding Service SID advertisement via BGP-LS.¶

Service SID advertisements SHOULD be withdrawn when the corresponding service function becomes unavailable or is no longer eligible for path computation.¶

Failure to withdraw stale Service SID information may result in incorrect path computation. The same applies if service function availability is not reflected in the TED in a timely manner: traffic may be steered to non-operational or invalid service functions.¶

The control plane maintains the TED based on received BGP-LS advertisements and withdrawals.¶

6.5. 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.¶

6.6. SR Policy Provisioning

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

6.7. Flow Classification

If traffic classification is requested, BGP Flow Specification rules are installed, as shown in Figure 6, associating each traffic flow with its SR Policy by Color, to ensure that only the selected traffic flows traverse the deployed service function chain. Installation ordering relative to SR Policy provisioning is discussed in Section 9.5.¶

6.8. Traffic Steering

Once the SR Policy and Flow Specification rules shown in Figure 6 are installed, the SR source node begins steering matching traffic through the selected service functions.¶

6.9. Monitoring

Operational status is continuously monitored throughout the service lifecycle using telemetry collected from both the network and infrastructure.¶

Monitoring data is used to verify service availability and support operational troubleshooting.¶

In addition, operators MAY verify correct traffic steering using SR path tracing or in-band telemetry mechanisms.¶

6.10. Service Update and Removal

The deployed system supports updates throughout the service lifecycle.¶

Typical operations include:¶

• modifying service function chains¶

• removing service function chains¶

• redeploying failed service functions¶

• removing service functions¶

Service updates are performed while maintaining consistency between the forwarding, control, management, and application planes.¶

7.1. 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, together with 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.¶

7.2. Service Deployment

Video streams from the video source sites described in Section 4.3 were dynamically steered through SR-aware service functions deployed in the Sapporo, Kanagawa, and Okinawa data centers.¶

The service functions performed video switching, transcoding, 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 and the corresponding information was advertised via BGP-LS.¶

7.3. 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 existing cloud infrastructure.¶

• SR Policies and Flow Specification rules were automatically generated.¶

• Operators manage services through an intent-based interface, without requiring awareness of low-level network details, thereby reducing operational complexity.¶

• Newly deployed service functions became available for path computation once Service SID advertisement (Section 6.4) was completed.¶

7.4. Scalability Considerations

This deployment demonstrated that the architecture can scale incrementally by deploying additional SRv6-capable service function nodes without changing the overall control architecture.¶

Once the application, control, and management components are deployed, additional SR-aware service functions can be instantiated or removed using the VIM's native scaling mechanisms.¶

These service functions become available for path computation without requiring manual updates to the controller configuration.¶

8.1. Service Verification and Observability

Verifying end-to-end service correctness required more than monitoring SR Policy status or the operational state of service functions.¶

In the deployed video processing service, it also required application-layer verification, comparing input and output video streams at the video source sites in Chiba and Kanagawa with the corresponding output from the service function chain, to confirm that traffic was processed correctly.¶

This experience indicates that, for content-modifying services, application-layer verification is a necessary complement to network- and infrastructure-layer monitoring, and cannot be replaced by monitoring SR Policy or service function status alone.¶

8.2. Latency-Aware Service Function Placement

This section addresses the placement of SR-aware service functions. For control-, management-, and application-plane component placement, see Section 9.2.¶

Because data centers are geographically distributed, inter-site latency has a measurable impact on service performance.¶

For latency-sensitive applications such as real-time video processing, cumulative path latency across multiple sites is an important consideration for service function placement.¶

In the deployed system, service function placement was determined manually based on operator knowledge of the network topology and latency characteristics.¶

While the underlying architecture supports adding service function nodes incrementally (Section 7.4), this manual placement decision process becomes increasingly difficult to manage as the number of deployment sites increases.¶

This experience led to the operational recommendations in Section 9.2, which describe latency-aware and topology-aware approaches to service function placement.¶

8.3. Service Orchestration Timing and Consistency Issues

Correct service operation depends on the relative timing among service function readiness, Service SID advertisement, SR Policy provisioning, and Flow Specification installation.¶

Service SID advertisement may occur before control-plane state (e.g., BGP-LS updates and TED synchronization) has fully converged. In such cases, service functions may become eligible for path computation before downstream SR Policy provisioning is completed.¶

Similarly, Flow Specification rules may be installed before the corresponding SR Policy becomes operational. This can result in transient traffic misclassification or blackholing, particularly when an existing SR Policy is modified or replaced.¶

Synchronization delays between the management plane (VNFM and SFM), control plane (PCE and BGP-LS), and forwarding plane may further introduce temporary inconsistencies in service availability information.¶

These issues motivated the operational sequencing recommendations described in Section 9.5.¶

8.4. Multi-domain State Correlation Limitations

The deployed system spans multiple VIM domains distributed across geographically separated data centers.¶

As a result, operational state is distributed across network, cloud, and application layers, each observed using independent monitoring tools. There is no unified mechanism to correlate SR Policy state, service function status, and application-layer verification results (Section 8.1) across these domains.¶

Consequently, troubleshooting required manual correlation of information from multiple sources, including control-plane telemetry, NFVI-level monitoring, and application-level validation. This lack of integrated observability increased the time required to diagnose service degradation and failure scenarios, particularly when issues spanned multiple layers of the architecture.¶

A unified multi-layer observability framework, capable of correlating network, cloud, and application states using consistent identifiers, is essential for efficient operation of SRv6 SFC deployments at scale.¶

9.1. Service SID Allocation

Building on the Service SID allocation described in Section 6.3, Service SID uniqueness within the SR domain MUST be ensured. Uniqueness is ensured at two distinct levels, corresponding to the Locator and Function fields of an SRv6 SID [RFC8986].¶

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. Within a given Locator, however, the Function field associated with a specific End.AN behavior MUST be uniquely assigned so as not to collide with other service functions sharing the same Locator.¶

Because this Function value assignment is not visible to the routing and forwarding plane, it SHOULD be coordinated by the management plane (e.g., the SFM) prior to advertisement. It SHOULD also be verified against the current TED maintained by the control plane via BGP-LS, to prevent collisions across data centers and service functions.¶

A centralized allocation mechanism SHOULD be used, where the SFM queries the current TED via the control plane to determine available Function space, and assigns Function values accordingly before advertisement, thereby preventing address collisions across data centers and simplifying multi-site service deployment.¶

9.2. System Component Placement

Because this deployment spans geographically distributed data centers, the placement of service functions and control, management, and application plane components has an impact on system performance and scalability.¶

Service function placement affects both path latency and traffic load distribution across the SR domain. As discussed in Section 8.2, placement SHOULD be based on measured inter-site latency between ingress points (e.g., video source sites), data centers, and egress points (e.g., the production system), rather than static assumptions. It SHOULD further consider NFVI resource availability at each data center and the current load distribution of already deployed service functions, to avoid overloading specific data centers. The VIM's native scaling mechanisms (Section 7.4) MAY be used to instantiate or remove service function instances in response to these decisions.¶

Placement of control, management, and application plane components also requires careful consideration, but the relevant constraint depends on interaction frequency. Interactions between the application plane and the control and management planes (e.g., service deployment, configuration, SR Policy provisioning, and path computation requests) occur repeatedly throughout the service lifecycle.¶

In contrast, interactions between operators and the application plane (e.g., service requests and status queries) are less frequent, so greater physical separation is acceptable. Therefore, co-location of the application plane with the control and management planes SHOULD be prioritized over proximity to operators or video source sites.¶

In the described deployment, the application plane, VNFM, SFM, and the control plane (Pola PCE and GoBGP) were co-located at the Kanagawa data center to minimize inter-component latency.¶

However, each data center operates an independent VIM instance (OpenStack) to manage its local NFVI resources, as described in Section 4.4.¶

The VNFM interacts with these per-site VIM instances to issue lifecycle requests, thereby providing operators with a logically centralized management view across the distributed VIM instances.¶

A logically centralized controller and management architecture SHOULD be used to ensure consistent path computation, service configuration, and policy enforcement across the SR domain. For large-scale deployments, a hierarchical controller and management model MAY be used to improve scalability while preserving global policy consistency.¶

9.3. Failure Recovery

Failure recovery follows the mechanisms defined in [I-D.draft-watal-spring-srv6-sfc-sr-aware-functions].¶

In operational deployments, fast reroute at the forwarding plane can maintain connectivity, but service-level state consistency is not guaranteed during failover events. During failover, traffic may be redirected to a different service function instance that does not share the same processing state.¶

Therefore, service functions MUST be designed to tolerate such state inconsistencies, for example through buffering, state re-synchronization, idempotent processing, or other application-specific recovery mechanisms.¶

9.4. Observability

A multi-layer observability framework SHOULD include:¶

• SRv6 topology and SR Policy state¶

• Flow classification and traffic steering behavior¶

• Service function health and availability¶

• Virtual infrastructure resource utilization¶

This framework SHOULD include a unified telemetry system spanning both network and cloud domains, enabling cross-layer analysis for rapid fault detection and diagnosis.¶

For content-modifying services (e.g., video processing), application-layer verification MAY also be required to compare input and output streams.¶

9.5. Operational Sequencing

Automated orchestration SHOULD ensure correct sequencing of:¶

1. Service function instantiation¶

2. Service SID assignment and service configuration¶

3. Readiness verification¶

4. BGP-LS advertisement¶

5. SR Policy provisioning¶

6. Flow Specification installation¶

In addition, operators SHOULD apply the following practices to avoid impacting existing traffic during deployment or updates.¶

New services SHOULD be assigned distinct SR Policy colors whenever possible, so that Flow Specification rules for those services do not affect existing traffic during deployment.¶

When an existing SR Policy is modified or replaced, Flow Specification rules SHOULD be updated only after the replacement SR Policy has been successfully provisioned and verified as operational.¶

Operators SHOULD verify service readiness and SR Policy operability before enabling or updating Flow Specification rules for traffic steering.¶

12.1. Normative References

[I-D.draft-watal-spring-srv6-sfc-sr-aware-functions]

Mishima, W. and Y. Fukagawa, "SRv6 SFC Architecture with SR-aware Functions", Work in Progress, Internet-Draft, draft-watal-spring-srv6-sfc-sr-aware-functions-05, 4 July 2026, <https://datatracker.ietf.org/doc/html/draft-watal-spring-srv6-sfc-sr-aware-functions-05>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC4655]

Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <https://www.rfc-editor.org/rfc/rfc4655>.

[RFC5440]

Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <https://www.rfc-editor.org/rfc/rfc5440>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8231]

Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, <https://www.rfc-editor.org/rfc/rfc8231>.

[RFC8281]

Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, <https://www.rfc-editor.org/rfc/rfc8281>.

[RFC8402]

Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/rfc/rfc8402>.

[RFC8568]

Bernardos, CJ., Rahman, A., Zuniga, JC., Contreras, LM., Aranda, P., and P. Lynch, "Network Virtualization Research Challenges", RFC 8568, DOI 10.17487/RFC8568, April 2019, <https://www.rfc-editor.org/rfc/rfc8568>.

[RFC8986]

Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, <https://www.rfc-editor.org/rfc/rfc8986>.

[RFC9256]

Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", RFC 9256, DOI 10.17487/RFC9256, July 2022, <https://www.rfc-editor.org/rfc/rfc9256>.

12.2. Informative References

[I-D.draft-ietf-idr-bgp-ls-sr-service-segments]

Dawra, G., Filsfils, C., Talaulikar, K., Clad, F., Bernier, D., Uttaro, J., Decraene, B., Elmalky, H., Xu, X., Guichard, J., and C. Li, "BGP-LS Advertisement of Segment Routing Service Segments", Work in Progress, Internet-Draft, draft-ietf-idr-bgp-ls-sr-service-segments-02, 5 November 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-sr-service-segments-02>.

[I-D.draft-ietf-spring-sr-service-programming]

Abdelsalam, A., Xu, X., Filsfils, C., Bernier, D., Li, C., Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and S. Salsano, "Service Programming with Segment Routing", Work in Progress, Internet-Draft, draft-ietf-spring-sr-service-programming-12, 3 November 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-service-programming-12>.

[RFC7426]

Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, DOI 10.17487/RFC7426, January 2015, <https://www.rfc-editor.org/rfc/rfc7426>.

[RFC7665]

Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, <https://www.rfc-editor.org/rfc/rfc7665>.

[RFC8664]

Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., and J. Hardwick, "Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing", RFC 8664, DOI 10.17487/RFC8664, December 2019, <https://www.rfc-editor.org/rfc/rfc8664>.

[RFC8955]

Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. Bacher, "Dissemination of Flow Specification Rules", RFC 8955, DOI 10.17487/RFC8955, December 2020, <https://www.rfc-editor.org/rfc/rfc8955>.

[RFC9552]

Talaulikar, K., Ed., "Distribution of Link-State and Traffic Engineering Information Using BGP", RFC 9552, DOI 10.17487/RFC9552, December 2023, <https://www.rfc-editor.org/rfc/rfc9552>.

[RFC9862]

Koldychev, M., Sivabalan, S., Sidor, S., Barth, C., Peng, S., and H. Bidgoli, "Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing (SR) Policy Candidate Paths", RFC 9862, DOI 10.17487/RFC9862, October 2025, <https://www.rfc-editor.org/rfc/rfc9862>.