| Internet-Draft | SRv6 Converged DC and WAN with Svc | April 2025 |
| Filsfils, et al. | Expires 5 October 2025 | [Page] |
The SRv6 Network Programming architecture allows an application to control the end-to-end journey of traffic flows through domains in a unified and stateless manner.¶
This document covers its application to the integration of data center (DC) and wide area network (WAN) architectures using SRv6 with uSID (NEXT-CSID). This eliminates the complexities and inefficiencies associated with traditional fragmented network designs. The solution enhances scalability and enables flexible stateless service insertion by unifying the DC and WAN under a single SRv6 domain.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 5 October 2025.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Data Center (DC) and Wide Area Networks (WAN) are often deployed as separate domains with distinct architectures, increasing complexity and limiting service insertion.¶
Segment Routing over IPv6 (SRv6) [RFC8986] enables a unified approach to networking by leveraging source routing.¶
SRv6 uSID (NEXT-CSID), [I-D.ietf-spring-srv6-srh-compression]) provides:¶
This document presents a converged SRv6-based solution for the integration of data center (DC) and wide area network (WAN), eliminating the complexity and inefficiencies of traditional fragmented architectures.¶
SRv6 uSID (NEXT-CSID) removes protocol translation overhead, improves scalability, and enables flexible service insertion (e.g., firewall services).¶
The document [draft-filsfils-srv6-ai-backend] documents the usage of SRv6 to optimize workloads in the AI backend.¶
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.¶
Micro-segment Identifier, formally defined as NEXT-CSID in [I-D.ietf-spring-srv6-srh-compression].¶
The term uSID (micro SID) predates the formal naming and has been widely adopted across the industry - including operators with large-scale deployments, vendors, open-source implementations, and used consistently in multi-vendor interoperability reports.¶
To maintain alignment with the formal specification while also acknowledging the widespread and practical use of the term, this document uses uSID and NEXT-CSID interchangeably.¶
The traditional data center architecture utilizes VXLAN for intra-DC communication, while the WAN employs SR-MPLS. Stitching these domains requires complex DCI gateway functions and protocol translations, which increase operational overhead and hinder service agility. These gateways translate between VXLAN and SR-MPLS.¶
+--------------------------+ +---------------+ | DC | | WAN | | | | | .--. | | | | ( )-. | +----+ +-----+ +-----+ +---+ +----+ .' ) | Host--|Leaf|--|Spine|--| DCI |--| P |--| BR |--( Internet ) | +----+ +-----+ +-----+ +---+ +----+ ( -' |<----------VXLAN--------->| |<---SR-MPLS--->| '-( ) +--------------------------+ +---------------+ '---'
This is depicted in Figure 1. The Host sends traffic towards the Internet. Upon traffic reception at the DC, it is encapsulated with VXLAN. This packet continues all the way up to the DCI, where there is protocol translation between VXLAN and SR-MPLS, requiring information that needs to be carried from one data-plane to another. Once the packet reaches the Border Router (BR), the SR-MPLS encapsulation is removed, and the packet continues up to the Internet.¶
This design presents the following challenges:¶
DCI Protocol Translation:¶
Performance Penalty: Some hardware incurs in a performance degradation.¶
Availability: Not all vendors support the functionality homogenously.¶
Scalability bottleneck: These boxes maintain VRF state, reducing scalability.¶
Complexity: Information like Group Policy Objects (GPO), tags, or context must be conveyed across and between the DCs.¶
Reliability: The increased complexity introduces additional potential points of failure.¶
Cost: The increased functionality typically incurs an additional cost.¶
Service Insertion: insertion of services, such as firewalls, require complex policies, with rigid traffic steering.¶
This results in inefficient designs. For example, in the case of firewall services, due to the rigid routing, firewalls are typically deployed as a large cluster near the network perimeter. This results in scalability challenges (i.e., stateful firewall state synchronization between instances).¶
IPv4 Loopback dependency: Many vendors still require IPv4 loopbacks on both VXLAN and SR-MPLS networks, adding unnecessary operational complexity and limiting pure IPv6 deployments.¶
The transition from a fragmented network architecture to a converged SRv6 uSID (NEXT-CSID) based end-to-end design enables seamless communication between data center (DC) workloads and the wide area network (WAN).¶
The key benefits of this architecture include:¶
Elimination of protocol translation: Removing VXLAN-to-SR-MPLS protocol conversion improves efficiency and reduces processing overhead at the DCI.¶
Enhanced scalability: The nature of SRv6 supports flexible traffic engineering with no per-flow state in the fabric.¶
Simplified service chaining: Native SRv6 capabilities enable the efficient insertion of services without requiring additional protocols or complex policy-based routing policies.¶
Optimized forwarding with minimum MTU: A simple IPv6 encapsulation allows encoding up to six instructions in the IPv6 Destination Address. If additional instructions are needed, a Segment Routing extension Header can be added to encode additional instructions.¶
IPv6-native: The architecture enables a fully IPv6-native deployment, eliminating dependencies on IPv4 loopbacks while simplifying management.¶
Service insertion typically relies on complex policy-based routing mechanisms that direct traffic through predefined service clusters, such as firewalls. These approaches often lead to scalability limitations and suboptimal traffic paths. By using SRv6 uSID (NEXT-CSID), services can be seamlessly integrated into the forwarding plane without requiring additional tunneling mechanisms or extensive policy configurations.¶
Services are inserted into the forwarding path for a specific flow simply by adding the corresponding uSID to the source routed network program. This allows:¶
Stateless steering: SRv6 uSID (NEXT-CSID) encoding removes the need for per-flow state on intermediate nodes, improving scalability.¶
Flexible service chaining: Multiple services, such as intrusion detection (IDS) or deep packet inspection (DPI), can be chained together dynamically by appending additional uSIDs.¶
Using the firewall service as an example, when a workload within the DC initiates traffic requiring inspection, the ingress node includes the necessary SIDs in the SRv6 network program. These SIDs guide the packet through the firewall, ensuring compliance with security policies. The firewall processes the traffic and forwards it along the next segment in the chain, with minimal overhead.¶
In this section we illustrate how an end-to-end SRv6 converged DC/WAN architecture operates.¶
+--------------------------------+ +-------------+ | DC | | WAN | | H11--+ | | | .--. | | | | | ( )-. | +----+ +----+ +-----+ +-----+ +---+ +---+ .' ) | |TOR1|--|Leaf|--|Spine|--| DCI |--| P |--|BR6|--( Internet ) | +----+ +----+ +-----+ +-----+ +---+ +---+ ( -' | | | | '-( ) +--------------------------------+ +-------------+ '---'
Figure 2 illustrates one DC and the WAN. The network within the DC has a spine-leaf Clos design. BGP is used as the routing protocol in the DC. The WAN network uses IS-IS as the IGP. Other routing protocols may be used in the DC and the WAN. The Border Router (BR) connects the WAN to the Internet.¶
SRv6 is enabled on nodes TOR1 and BR6. The remaining nodes are performing IPv6 forwarding, and do not require to be SRv6 enabled.¶
The operator provisions the following:¶
Hosts H11 represents a virtual workload connected to a TOR. The TOR and BR act as SRv6 Provider Edge (PE) nodes, providing SRv6 L3VPN connectivity between the hosts and the Internet. The SRv6 PEs advertise their VPN routes in BGP [RFC9252].¶
As an L3VPN PE, BR6 advertises its IPv4 and IPv6 Internet reachability in its VRF INTERNET to the TORs using BGP. The BR typically advertises its Internet reachability as a default route. A single BR is illustrated, but multiple BRs may exist for redundancy.¶
As an SRv6 L3VPN PE, BR6 advertises the VPN routes with an SRv6 L3VPN service SID of behavior End.DT4 for IPv4, End.DT6 for IPv6, or End.DT46 for both IPv4 and IPv6 [RFC8986]. BR6 advertises the SRv6 L3VPN service SID 5f00:0:6:e000:: for the Internet routes, with 5f00:0:6::/48 an SRv6 locator of BR6.¶
TOR1 is configured with a VRF named UNSECURED for unsecured connectivity. Host H11 is connected to TOR1 in VRF UNSECURED. TOR1 imports the L3VPN routes advertised by BR6 into this VRF.¶
TOR1 advertises the IPv4 and IPv6 service routes in VRF UNSECURED with an SRv6 L3VPN service SID 5f00:0:1:e001::. BR6 imports the routes of this VRF into its single local VRF INTERNET.¶
TOR1 steers a traffic flow from H11 in VRF UNSECURED to the Internet via BR6. As a result:¶
The reverse direction is symmetrical.¶
This section describes the scenario of an SRv6-unaware [I-D.ietf-spring-sr-service-programming] standalone firewall service. SR Policies [RFC9256] steer the packet flows requiring inspection through the firewall.¶
+------------------------------------+ +-----------+ | DC +-----+ | | WAN | | | FW3 | | | | | +-+-+-+ | | | .--. | in | | out | | | ( )-. | +----+ +----+ +-----+ +-+-+-+ +-----+ +---+ +---+ .' ) | |TOR1|-|Leaf|-|Spine|-| SL2 |-| DCI |-| P |-|BR6|--( Internet ) | +----+ +----+ +-----+ +-----+ +-----+ +---+ +---+ ( -' | | | | | '-( ) | H12-+ | | | '---' +------------------------------------+ +-----------+
Figure 3 illustrates the network topology with a firewall service FW3. This firewall service is connected to service leaf (SL) node SL2. The firewall FW3 is dual-connected to the SL node via an inside interface (FW3-IN) and outside interface (FW3-OUT).¶
FW3 inspects the received packets and forwards the allowed ones. FW3 inspects the inner packet and does not modify the outer IPv6 header, apart from the HL field.¶
The SL node SL2 is SRv6-enabled and advertises a locator prefix 5f00:0:2::/48.¶
SL2 allocates and installs a uA SID (5f00:0:2:e000::) directing packets to the inside interface of the firewall (FW3-IN) and a uA SID (5f00:0:2:e001::) directing packets to the outside interface of the firewall (FW3-OUT).¶
Traffic from the Host to the Internet:¶
For TOR1 to direct service traffic flows through the firewall FW3, it does the following:¶
TOR1: Encapsulates the traffic from H12 with an IPv6 header with DA 5f00:0:2:e000:6:e000:: .¶
This network program instructs the packet to go to node SL2, take the interface FW3-IN, go to node BR6, execute the VPN behavior.¶
Leaf:¶
Spine:¶
SL2:¶
FW3: Process the inner header of the packet according to security policy.¶
DCI:¶
P:¶
BR6:¶
The traffic flow from the Internet to the Host is symmetrical, with the remark that on SL2 the SID 5f00:0:2:e001 is used to xconnect the packet on the FW3-out interface.¶
This configuration ensures that forward and reverse traffic flows pass through the same firewall. The illustration is expanded in Appendix A.1 showing how this use-case is realized from a control-plane point of view leveraging the SR Policy and the notion of Color-Only BGP Destination Steering [RFC9256].¶
Note that in a typical deployment the service (e.g, Firewall) may be clustered. This is grouping multiple service instances as a single logical device. The connections are synchronized across the instances, which ensures redundancy. SRv6 uSID supports this easily by leveraging an anycast service SID. This is detailed in Appendix A.2.¶
In Appendix B we remind the difference between SRv6-aware and SRv6-unaware services, and provide considerations for each of them.¶
Gateway Removal: Eliminates stateful DCI translation, removing a critical bottleneck in traditional architectures. This leads to better performance, reliability, scalability, and lower operational costs.¶
End-to-End: Unified underlay and overlay from DC to WAN.¶
Scalability: The intermediate nodes do not maintain any per-flow state.¶
Lower MTU Tax: SRv6 uSID (NEXT-CSID) allows encoding up to six uSIDs within the IPv6 Destination Address field. This eliminates the VXLAN overhead, improving transport efficiency.¶
Flexible Service Insertion: Dynamically steer selected traffic through services (e.g., security appliances) without complex policy-based routing mechanisms. Insert services anywhere in the network and apply the policy on a per-vm, per-prefix, or per-customer basis.¶
Smaller Clusters: Due to the flexible traffic steering capabilities provided by SRv6, the operator may choose to deploy smaller service clusters (e.g., firewall clusters) distributed along the network. This drastically reduces the scaling challenge of clusters.¶
Egress Peer Engineering (EPE): SRv6 enables precise outbound traffic control, optimizing interconnection with external networks.¶
The deployment model described in this document does not require any new security mechanism aside of those defined in [RFC8986].¶
The authors would like to recognize the work of Alexey Gorovoy, Andrew Tikhonov, and Samvel Vartapetov from Nebius.¶
Alexey Gorovoy presented this use case at MPLS & SRv6 World Congress in March 2025. A recording is available here: https://www.segment-routing.net/conferences/Paris25-Nebius-Alexey-Gorovoy/¶
Figure 3 illustrates the network topology with a firewall service FW3. This firewall service is connected to service leaf (SL) node SL2. The firewall FW3 is dual-connected to the SL node via an inside interface (FW3-IN) and outside interface (FW3-OUT).¶
FW3 inspects the packets received on FW3-IN and sends the allowed packets to FW3-OUT. FW3 inspects the inner packet and does not modify the outer IPv6 header, apart from the HL field.¶
The SL node SL2 is SRv6-enabled and advertises a locator prefix 5f00:0:2::/48.¶
SL2 allocates and installs a uA SID (5f00:0:2:e000::) directing packets to the inside interface of the firewall (FW3-IN) and a uA SID (5f00:0:2:e001::) directing packets to the outside interface of the firewall (FW3-OUT).¶
For TOR1 to direct service traffic flows through the firewall FW3, TOR1 steers the packets into an SR Policy named POLTOR, with a SID list <5f00:0:2:e000::>. This SID list steers the packets to SL2, directing them into the inside interface FW3-IN of FW3. SR Policy POLTOR has a color COLFIREWALL and an IPv6 null endpoint (::) ([RFC9256]).¶
For BR6 to direct service traffic flows through the firewall FW3, BR6 steers the packets into an SR Policy named POLBR, with a SID list <5f00:0:2:e001::>. This SID list steers the packets to SL2, directing them into the outside interface FW3-OUT of FW3. SR Policy POLBR has a color COLFW3 and an IPv6 null endpoint (::).¶
The devices connected to TOR1 that require firewall inspection of their communication with the Internet, such as host H12, are placed in a VRF named SECURED on TOR1.¶
As an SRv6 L3VPN PE, TOR1 advertises the IPv4 and IPv6 service routes of VRF SECURED with an SRv6 L3VPN service SID 5f00:0:1:e000:: and a Color Extended Community ([RFC9012]) named COLFW3 for ease of reference. COLFW3 has Color-only Types Field ([draft-ietf-idr-sr-policy-safi]) set to 1 (Specific or Null Endpoint Match) to enable the routes with this color for Color-Only BGP Destination Steering ([RFC9256]).¶
BR6 imports the routes of VRF SECURED into its single local VRF INTERNET. Since the routes have a color COLFW3 of Color-only type 1, and there is an active color-only SR Policy POLBR with color COLFW3 on BR6, BR6 steers the imported routes into SR Policy POLBR.¶
Consequently, packets arriving at BR6 from the Internet, destined for H12, are encapsulated in an outer IPv6 header with a SID list <5f00:0:2:e001::, 5f00:0:1:e000::>. This SID list may be combined into a single uSID container 5f00:0:2:e001:1:e000:: in the IPv6 DA. This SID list directs the encapsulated packets through FW3 and then to TOR1.¶
BR6 advertises its VRF INTERNET routes with an SRv6 L3VPN service SID 5f00:0:6:e000:: without a Color Extended Community. TOR1 imports these VRF INTERNET routes into its local VRF SECURED. Using a local policy, TOR1 colors the routes imported into VRF SECURED with a Color Extended Community named COLFIREWALL for ease of reference. COLFIREWALL has its Color-only Types Field ([I-D.ietf-idr-sr-policy-safi]) set to 1.¶
Since the routes have a color COLFIREWALL of Color-only type 1, and there is an active color-only SR Policy POLTOR with color COLFIREWALL on TOR1, TOR1 steers the imported routes into SR Policy POLTOR.¶
Consequently, packets arriving at TOR1 from H12, destined for the Internet, are encapsulated in an outer IPv6 header with a SID list <5f00:0:2:e000::, 5f00:0:6:e000::>. This SID list may be combined into a single uSID container 5f00:0:2:e000:6:e000:: in the IPv6 DA. This SID list directs the encapsulated packets through FW3 and then to BR6.¶
Each TOR in the DC advertises its VRF SECURED routes with a Color Extended Community that identifies the firewall instance FWX it requires for external communications. The BR steers the routes it receives with this color into the appropriate firewall service.¶
Each TOR in the DC locally colors the routes imported into VRF SECURED with the color of the local SR Policy that steers egress packets through the same firewall service FWX.¶
Clustering groups multiple firewalls in a single logical device. The firewall sessions (connections) are synchronized across the devices in a cluster. This ensures seamless failover and uninterrupted traffic flows. It also allows forward and reverse traffic flows of a firewall session to be hashed on different ECMP paths, passing through different firewall cluster members. For example, for a TCP session between H12 and a server on the Internet, the forward flow may be hashed on firewall cluster member FW3, while the reverse flow may be hashed on member FW5 of the same firewall cluster.¶
All members advertise the same anycast service SIDs to leverage ECMP load-sharing across firewall cluster members. If the firewall cluster is SRv6-unaware, the SRv6 nodes in front of the firewall instances instantiate the same anycast SIDs, directing the traffic to the appropriate firewall instance.¶
For example, the service leaf nodes connected to firewall cluster members FW3 and FW5 both advertise the anycast locator 5f00:0:24::/48 and instantiate common uA SIDs 5f00:0:24:e000:: and 5f00:0:24:e001:: for the inside and outside firewall interfaces, respectively.¶
Figure 4 illustrates the network topology with a cluster firewall service with cluster members FW3 and FW5. These firewall services are connected to service leaf (SL) nodes SL2 and SL4, respectively. Each firewall is dual-connected to the SL node via an inside and outside interface.¶
+--------------------------------------+ +-----------+ | +-----+ | | | | DC +---| SL2 |---+ | | WAN | | | +-+-+-+ | | | | | | in | | out | | | | | | +-+-+-+ | | | | .--. | | | FW3 | | | | | ( )-. | +----+ +----+ +---+-+ +-----+ +-+------+ +---+ +---+ .' ) | |TOR1|-|Leaf|-|Spine| : | DCI |-| P |-|BR6|--( Internet ) | +----+ +----+ +---+-+ +-----+ +-+------+ +---+ +---+ ( -' | | | | FW5 | | | | | '-( ) |H12-+ | +-+-+-+ | | | | '---' | | in | | out | | | | | | +-+-+-+ | | | | | +---| SL4 |---+ | | | | +-----+ | | | +--------------------------------------+ +-----------+
The SL nodes SL2 and SL4 are SRv6-enabled and respectively advertise locator prefixes 5f00:0:2::/48 and 5f00:0:4::/48. In addition, SL2 and SL4 both advertise the same anycast locator prefix 5f00:0:24::/48.¶
These SL nodes allocate and install a common uA SID (5f00:0:24:e000::) directing packets to the inside interface of the firewall (FW3-IN for FW3, FW5-IN for FW5) and a common uA SID (5f00:0:24:e001::) directing packets to the outside interface of the firewall (FW3-OUT for FW3, FW5-OUT for FW5).¶
This scenario is similar to the standalone firewall scenario, with the difference being the SID list of the SR Policies to steer the traffic through the firewall service.¶
SR Policy POLTOR on TOR1, as specified in section A.1, has a SID list <5f00:0:24:e000::>. Due to the anycast locator, this SID list steers the packets to either SL2 or SL4 into the inside interface FW3-IN of FW3 or FW5-IN of FW5, respectively.¶
SR Policy POLBR on BR6, as specified in section A.1, has a SID list <5f00:0:24:e001::>. This SID list steers the packets to either SL2 or SL4, into the outside interface FW3-OUT of FW3 or FW5-OUT of FW5, respectively.¶
If the service is SRv6-unaware ([I-D.ietf-spring-sr-service-programming]), it must be connected to an SRv6-capable entity, a physical or virtual element that can handle SRv6 packets. In section 5, this entity is a physical service leaf node. The requirements for the SRv6 entity depend on the service capabilities.¶
If the service (e.g., firewall, IPS, IDS, etc.) can process the inner packets without modifying the outer IPv6 header, which may include a Segment Routing Header (SRH), it is sufficient for the connected SRv6 entity to implement uN and uA SRv6 SID behaviors ([I-D.ietf-spring-srv6-srh-compression]) to direct the packets into the service. The service returns the processed packets to the SRv6 entity, where they continue their journey to their destinations.¶
If the service cannot process encapsulated packets, proxy SRv6 SID behaviors ([I-D.ietf-spring-sr-service-programming]) must be implemented on the connected SRv6 entity. The service processes the decapsulated packet, as the proxy entity provides, and returns the processed packets to the proxy. The proxy restores the packet encapsulation and forwards the packet towards its destination.¶
The SRv6-aware Service does not depend on an additional connected SRv6 node to execute the SRv6 SID behaviors related to the service. The SRv6-aware service node is reachable via its SRv6 locator and executes the behavior of its local SID matching the outer IPv6 DA of the received packets.¶