Nebius Adopts SRv6 to Unify Global AI Cloud Interconnects

Live from SCCC: Building scalable AI cloud interconnects with SRv6 | Alexey Gorovoy, Nebius — @Scale

@Scale

Deploying Segment Routing over IPv6 micro-segments eliminates legacy protocol translation bottlenecks and enables seamless end-to-end traffic engineering across data center and WAN domains.

AI-assisted summary of Live from SCCC: Building scalable AI cloud interconnects with SRv6 | Alexey Gorovoy, Nebius — original source. Check the original for full context.

Source published:

Detailed notes

## Background Published by @Scale on YouTube on August 31, 2026, this presentation features Alexey Gorovoy from Nebius speaking live from the Santa Clara Convention Center. According to the page description, the session explores Nebius' evolving architecture for customer cloud interconnects, using SRv6 to bridge virtual cloud environments with the physical network edge while providing end-to-end VPN and Traffic Engineering services without protocol translation.

## TL;DR Alexey Gorovoy outlines Nebius' transition to an SRv6-based network architecture designed to meet massive multi-terabit customer demands for AI workloads. By replacing legacy protocol translation boundaries (such as VXLAN EVPN in the data center and SR-MPLS in the WAN) with SRv6 uSID, Nebius achieves unified end-to-end L3VPN and Traffic Engineering capabilities. The presentation details their implementation using software Cloud Gateways powered by FD.io VPP, dynamic service-unaware firewall steering, and plans for native SRv6-aware firewalls and automated TE controllers.

## Atmosphere & style The presentation carries a professional, highly technical, and engineering-focused tone suitable for an architecture conference. Gorovoy delivers a clear, pragmatic breakdown of real-world networking challenges, balancing deep architectural analysis with lessons learned from production implementation. The delivery feels structured, authoritative, and forward-looking as it bridges current deployment experiences with future standards contributions.

## Key takeaways - [00:03](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=3s) Traditional customer cloud interconnects suffer from protocol boundaries and translation points between distinct edge, WAN backbone, and data center domains. - [01:54](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=114s) Nebius operates an IPv6-first infrastructure and initially handled customer dataset ingress locally over the public internet before multi-terabit connectivity demands emerged. - [03:15](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=195s) Using separate protocol stacks—VXLAN EVPN inside the data center and SR-MPLS across the WAN—created major performance bottlenecks at the Cloud Gateway translation layer. - [05:17](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=317s) Nebius selected SRv6 over VXLAN and MPLS to unify the network because it combines native overlay routing with sophisticated Traffic Engineering capabilities. - [08:00](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=480s) By adopting SRv6 uSID (Micro-Segment), instructions are encoded directly into the IPv6 destination address, eliminating extra headers like SRH, MPLS, or VXLAN to boost software router performance. - [10:32](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=632s) SRv6 Service-Unaware mode allows dynamic firewall steering via proxy nodes on Service Leaves without requiring legacy security appliances to parse SRv6 headers. - [11:57](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=717s) Nebius built its Cloud Gateway using the open-source FD.io Vector Packet Processing (VPP) framework due to its performant native SRv6 node support. - [11:57](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=717s) SRv6 uSID proved production-ready and fully interoperable across multiple hardware and software vendors, enabling incremental deployment alongside existing MPLS infrastructure. - [13:44](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=824s) Future network developments include bringing native SRv6 awareness directly to internal software firewalls and building an in-house dynamic Traffic Engineering Controller. - [13:44](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=824s) Nebius co-authored an IETF draft with Cisco detailing the architecture and uSID allocation schemes for cloud-to-edge SRv6 interconnects.

## Detailed walkthrough ### [00:03](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=3s) Introduction and Setting the Industry Context for Cloud Interconnects

Alexey Gorovoy, a network engineer at Nebius, introduces his presentation on how Nebius is evolving its customer cloud interconnect architecture using Segment Routing over IPv6 (SRv6) as a fundamental building block. Before diving into Nebius's specific implementation, he sets the broader industry context surrounding cloud connectivity. Most modern cloud providers offer interconnect solutions—private connections linking customer premises directly to the cloud provider's network. The core requirements for these connections include strict tenant isolation, predictable bandwidth, and integrated security capabilities.

To transport customer traffic from remote interconnect points across the backbone and data center into virtual cloud environments, the traffic must traverse multiple distinct network domains: the edge, the WAN backbone, and the data center fabric. Traditionally, each domain has been constructed using its own dedicated technology stack optimized for that specific environment. While there is nothing inherently wrong with these technologies individually, Gorovoy emphasizes that "they are not cleanly integrating end-to-end," which introduces protocol translation points, artificial service boundaries, and performance bottlenecks across domain edges.

- **Speaker:** Alexey Gorovoy, Network Engineer at Nebius - **Core Interconnect Requirements:** Tenant isolation, predictable bandwidth, integrated network security - **Network Domains Traversed:** Edge, WAN Backbone, Data Center - **Core Architectural Challenge:** Incompatibility between isolated per-domain technology stacks creating translation points and operational bottlenecks

[01:54](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=114s) Overview of Nebius Architecture and Initial Customer Demand

Nebius is an AI-native cloud provider building large-scale GPU clusters and developing an end-to-end AI cloud computing platform. The company builds the full technology stack to allow customers to build, train, and deploy models and applications in a single environment. Operating globally with data centers across Europe and the United States, Nebius interconnects its regions via a private backbone, while each individual site connects to the internet locally or via the nearest telecommunications Point of Presence (PoP).

In the early stages of Nebius's growth, customer interconnect demand primarily revolved around transferring massive datasets from customer premises into Nebius cloud storage for AI model training. This initial workflow relied heavily on the public internet, meaning traffic remained local to the specific region and did not traverse the inter-regional backbone. This setup functioned effectively because heavy data ingress occurred predominantly as a one-off event during initial customer onboarding.

- **Company Focus:** AI-native cloud platform and large-scale GPU infrastructure - **Footprint:** Global presence with data center regions across Europe and the US, linked by a private backbone and local telecommunications PoPs - **Initial Ingress Model:** High-volume dataset transfers over the internet, remaining local to specific regional data centers during onboarding

[03:15](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=195s) Legacy Data Center Protocol Stack and Emerging Interconnect Demands

Nebius operates as a strong advocate and practitioner of an IPv6-only foundation across its entire infrastructure, including data center fabrics, compute clusters, storage systems, and supporting services. The core network architecture relies on two in-house virtual software routers built on open-source components: the Cloud Gateway and the Firewall. The Cloud Gateway bridges virtual customer workloads to external networks using a VXLAN EVPN protocol stack within the data center, transitioning to Option A Segment Routing (SR-MPLS / MPLS) over the WAN to provide Layer 3 VPN (L3VPN) services to virtual machines.

As customer workloads matured, connectivity requirements shifted dramatically: 1. Customers demanded **predictable, dedicated bandwidth** over best-effort internet links. 2. Capacity demands escalated from gigabits into **hundreds of gigabits and multi-terabytes per second**. 3. Built-in security services, such as **end-to-end encryption and inline firewall inspection**, became mandatory.

Carrying this massive traffic across backbone and data center domains to the Cloud Gateway required seamless end-to-end VPN and Traffic Engineering (TE) capabilities. Maintaining two separate protocol stacks (VXLAN EVPN in the data center and MPLS in the WAN) meant the translation/stitching point between them became a major functional and operational bottleneck.

- **Infrastructure Foundation:** IPv6-first architecture across compute, fabric, and storage - **Proprietary Virtual Routers:** In-house Cloud Gateway and Firewall virtual routers built on open-source data planes - **Initial Data Center Stack:** VXLAN EVPN inside the data center; Option A SR-MPLS in the WAN - **Scaling Drivers:** Multi-terabit capacity requirements, guaranteed SLA bandwidth, and dynamic security service chaining

[05:17](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=317s) Evaluating Protocol Options: Why SRv6 Fits the Architecture

To eliminate the protocol translation boundary, Nebius evaluated existing overlay technologies. While VXLAN EVPN features widespread hardware vendor support and open-source adoption, it lacks native Traffic Engineering (TE) capabilities, making it rigid and inefficient for dynamic service insertion (such as steering traffic through firewalls). MPLS offers robust TE capabilities, but is poorly suited for scale within pure data center networks and software virtual routers. Bridging the two via dedicated stitching gateways introduces hardware performance hits, feature gaps between implementations, and significant operational complexity.

Nebius selected **SRv6 (Segment Routing over IPv6)** to unify the network. SRv6 combines the best of both paradigms: it operates as a standard IP-in-IP encapsulated overlay while natively embedding sophisticated Traffic Engineering capabilities directly into the packet header.

| Technology Stack | Data Center Suitability | Native Traffic Engineering | Multi-Vendor Adoption | Key Constraint | |:--- |:--- |:--- |:--- |:--- | | **VXLAN EVPN** | High | Poor / Rigid | Very High | Requires complex, rigid routing designs for service steering | | **MPLS / SR-MPLS** | Low | High | High | Unsuitable for data center fabric & software router overlays | | **SRv6** | High | High | Maturing / High | Requires IPv6 underlay support across all domains |

[08:00](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=480s) SRv6 uSID Implementation and Packet Overhead Reduction

Nebius deployed an overlay architecture using **SRv6 Micro-Segment (uSID)**. Leveraging their existing IPv6 routed underlay, SRv6 functionality was enabled strictly at the edge nodes of the network: the software Cloud Gateway on the cloud side, and physical Peering Border Routers on the physical edge. These endpoints act as traditional L3VPN Provider Edge (PE) nodes, while intermediate routers perform plain IPv6 forwarding (using BGP in the data center fabric and IS-IS across the WAN backbone).

By using SRv6, the L3VPN service remains transparent and un-stitched end-to-end, completely eliminating translation points at the Data Center Interconnect (DCI) boundary. Furthermore, by utilizing the **SRv6 uSID (Micro-Segment)** compression scheme, segment IDs are encoded directly within the standard destination IPv6 address fields. This eliminates the need for a separate Segment Routing Extension Header (SRH), MPLS label stacks, or VXLAN metadata headers. This reduction in packet encapsulation overhead drastically improves forwarding performance, particularly within software virtual routers.

- **Edge Endpoints:** Software Cloud Gateways (virtual) and Physical Peering Border Routers - **Underlay Protocols:** BGP in the data center fabric; IS-IS in the WAN domain - **Encapsulated Efficiency:** SRv6 uSID encodes segment instructions directly inside the 128-bit IPv6 destination address - **Performance Gain:** Complete elimination of extra protocol headers (SRH, VXLAN, MPLS) reduces byte overhead and speeds up software lookup pathways

[10:32](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=632s) Dynamic Service Chaining: SRv6 Service-Unaware Firewall Steering

To support inline security functions, Nebius implemented SRv6-based dynamic firewall service chaining. They initially adopted the **SRv6 Service-Unaware mode**, allowing existing firewall appliances to perform packet inspection without requiring them to support SRv6 parsing natively.

This service injection model relies on SRv6 proxy nodes located on dedicated Service Leaves within the data center fabric. These proxy nodes support Node SIDs and Adjacency SIDs that map directly to physical interfaces connected to the firewall cluster. By embedding these Adjacency SIDs into SRv6 Traffic Engineering (TE) policies programmatically instantiated at the Cloud Gateway or Border Router edges, traffic can be dynamically steered through the firewall cluster when inspection is required, or routed straight past it when unneeded.

- **Firewall Integration Mode:** SRv6 Service-Unaware mode (firewalls perform standard IP inspection without parsing SRv6 headers) - **Service Leaves & Proxy Nodes:** SRv6-enabled fabric leaves translate SRv6 paths into physical interfaces connected to firewalls - **Traffic Control:** Adjacency SIDs enable granular, policy-driven traffic steering through firewall clusters on demand

[11:57](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=717s) Implementation Lessons, Software Routers, and Interoperability

Reflecting on their technical evaluation over the past year, Nebius conducted extensive Proof-of-Concept (PoC) testing across multiple hardware vendors and open-source networking stacks. They successfully validated the multi-vendor interoperability of the SRv6 Micro-Segment (uSID) specification, giving them confidence to build out their custom Cloud Gateway software router.

For the Cloud Gateway implementation, Nebius selected the **Vector Packet Processing (VPP)** data plane framework due to its rich, performant support for native SRv6 graph nodes and control plane integration. Gorovoy notes that MPLS and SRv6 can seamlessly coexist during migration periods. Because the underlying network only requires standard IPv6 reachability, SRv6 PE capabilities can be enabled incrementally at network edges without disrupting existing infrastructure. The overall takeaway is that SRv6 uSID is production-mature, fully interoperable, and provides a clear migration path.

- **Data Plane Framework:** FD.io VPP (Vector Packet Processing) chosen for custom Cloud Gateway implementation - **Coexistence:** Seamless side-by-side operation with existing MPLS underlays/overlays - **Key Takeaways:** Mature protocol ecosystem, proven multi-vendor uSID interoperability, and low-risk edge-only deployment model

[13:44](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=824s) Architecture Summary, Future Roadmap, and IETF Standardization

Gorovoy summarizes SRv6 as bringing "simplicity and unification" to Nebius's network. By extending L3VPN and Traffic Engineering services cleanly from remote customer interconnect PoPs to virtual cloud workloads, Nebius eliminates protocol translation points, minimizes operational complexity, and scales out its border routers and Cloud Gateways independently.

Looking forward, Nebius is expanding its SRv6 footprint across additional network domains, including its Internet Edge and internal Data Center Interconnects (DCI). Furthermore, because Nebius develops its own firewall software, they plan to add **native SRv6 awareness directly to the firewall application**. This will remove the dependency on dedicated proxy service leaves, enabling granular, scale-out firewall insertion per application, domain, customer, or tenant segment anywhere in the IPv6 fabric. Nebius is also building an in-house dynamic Traffic Engineering Controller to automate real-time policy provisioning.

Finally, Gorovoy invites the networking community to review their co-authored **IETF draft** published alongside Cisco and industry peers. The draft details the architectural framework, uSID allocation schemes, and deployment nuances for interconnecting virtual cloud environments with physical network edges using SRv6.

- **Operational Impact:** Unified protocol stack reduces operational overhead and simplifies multi-tenant VPN scaling - **Future Roadmap Capabilities:** - Expansion of SRv6 to Internet Edge and internal DCI domains - Native SRv6-aware firewalls to eliminate dedicated proxy service leaves - Development of an in-house dynamic SRv6 Traffic Engineering (TE) Controller - **Standards Contribution:** Co-authored IETF draft with Cisco detailing cloud-to-edge SRv6 interconnect design architectures

<FollowUp label="Would you like a detailed breakdown of how SRv6 uSID (Micro-Segment) address encoding works?" query="Explain how SRv6 uSID (Micro-Segment) address encoding works and how it eliminates the Segment Routing Extension Header (SRH)."/>

## Notable quotes > [00:03](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=3s) they are not cleanly integrating end-to-end — Alexey Gorovoy

> [03:15](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=195s) predictable, dedicated bandwidth — Alexey Gorovoy

> [03:15](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=195s) hundreds of gigabits and multi-terabytes per second — Alexey Gorovoy

> [03:15](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=195s) end-to-end encryption and inline firewall inspection — Alexey Gorovoy

> [05:17](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=317s) SRv6 (Segment Routing over IPv6) — Alexey Gorovoy

> [08:00](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=480s) SRv6 Micro-Segment (uSID) — Alexey Gorovoy

> [10:32](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=632s) SRv6 Service-Unaware mode — Alexey Gorovoy

> [11:57](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=717s) Vector Packet Processing (VPP) — Alexey Gorovoy

> [13:44](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=824s) simplicity and unification — Alexey Gorovoy

> [13:44](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=824s) native SRv6 awareness directly to the firewall application — Alexey Gorovoy

## Mentioned Alexey Gorovoy, Nebius, SRv6, uSID, VXLAN EVPN, SR-MPLS, MPLS, IPv6, BGP, IS-IS, Vector Packet Processing (VPP), FD.io, Cisco, IETF, Cloud Gateway, Firewall, Santa Clara Convention Center, @Scale

[Source](https://www.youtube.com/watch?v=kfqO2CA9-GU)

中文简报

Nebius采用SRv6统一全球AI云互连 部署基于IPv6微段的分段路由消除了传统协议转换瓶颈，并在数据中心与广域网域之间实现了无缝端到端流量工程。 Alexey Gorovoy概述了Nebius向基于SRv6的网络架构转型的历程，该架构旨在满足AI工作负载带来的数Terabit级海量客户需求。通过使用SRv6 uSID替代传统协议转换边界（例如数据中心内部的VXLAN EVPN与广域网中的SR-MPLS），Nebius实现了统一的端到端L3VPN和流量工程能力。该演讲详细介绍了他们采用由FD.io VPP驱动的软件云网关实现、动态业务无感知防火墙引流，以及部署原生SRv6感知防火墙和自动化TE控制器的后续规划。 传统客户云互联因跨边缘、WAN 骨干网与数据中心采用不同协议栈（如 VXLAN EVPN 与 SR-MPLS），导致云网关拼接层出现严重的协议转换与性能瓶颈。 (3:15) 随着多太比特（multi-terabit）带宽与安全链需求增加，Nebius 选择 SRv6 统一网络架构，兼具原生覆盖路由与精细化流量工程（TE）能力。 (5:17) 通过采用 SRv6 uSID（微段）技术，指令直接编码在标准 128 位 IPv6 目的地址中，彻底省去 SRH、MPLS 或 VXLAN 报头，大幅提升了软件虚拟路由器的转发性能。 (8:00) 在安全集成方面，Nebius 先期采用 SRv6 Service-Unaware 模式，通过服务交换机上的代理节点与 Adjacency SID 动态引流至防火墙集群，无需防火墙原生解析 SRv6 报头。 (10:32) Nebius 基于 FD.io VPP 构建了云网关，验证了 SRv6 uSID 具备多厂商互操作性并可与现有 MPLS 平滑共存，未来计划开发原生感知 SRv6 的防火墙及动态 TE 控制器。 (11:57)

Reading summary

Alexey Gorovoy of Nebius outlines how the AI cloud provider transitioned its interconnect architecture to Segment Routing over IPv6 (SRv6) Micro-Segments (uSID) to eliminate multi-domain protocol translation and unify traffic engineering across data center fabrics and WAN backbones. Interconnect Scaling Pressures and Protocol Fragmentation (3:15) Nebius initially managed customer interconnect traffic through standard internet links, primarily accommodating one-off dataset uploads into cloud storage for AI model training. As customer workloads expanded into continuous model training and deployment across global data centers in Europe and the United States, bandwidth demands surged from gigabits to multi-terabits per second, accompanied by strict service-level agreements and mandatory inline security inspection. Handling these demands exposed structural limitations in Nebius's legacy transport design. The cloud environment relied on an IPv6-first underlay with in-house virtual software routers—the Cloud Gateway and Firewall—built on open-source platforms. However, the network maintained two disparate overlay stacks: VXLAN EVPN inside the data center fabric and Option A Segment Routing over MPLS (SR-MPLS) across the WAN. Gorovoy notes that bridging these isolated domains required protocol translation points at the Data Center Interconnect (DCI) boundary, introducing operational bottlenecks, feature discrepancies, and performance penalties. Overcoming Encapsulation Overhead with SRv6 uSID (5:17) To unify the transport layer, Nebius evaluated existing overlays. While VXLAN EVPN enjoyed broad hardware adoption, it lacked native Traffic Engineering (TE) capabilities, making policy-based path selection rigid. Conversely, MPLS-based options proved poorly suited for virtual software routers and pure data center environments. Nebius chose SRv6 because it natively integrates advanced traffic steering into standard IP-in-IP encapsulation. To counter packet encapsulation bloat, Nebius implemented the SRv6 Micro-Segment (uSID) scheme. Intermediate hops run standard IPv6 routing—using BGP within data centers and IS-IS across the WAN—while SRv6 processing is restricted entirely to edge nodes: physical Peering Border Routers and the custom Cloud Gateway running on the Vector Packet Processing (VPP) data plane framework. Because uSID embeds routing instructions directly into the 128-bit IPv6 destination address, it eliminates the need for Segment Routing Extension Headers (SRH), MPLS label stacks, or VXLAN metadata headers, sharply reducing software lookup pathways and forwarding overhead. Dynamic Service Chaining via Service-Unaware Proxies (10:32) To fulfill inline security requirements without rewriting existing firewall software, Nebius implemented an SRv6 Service-Unaware steering model. In this setup, traditional firewall appliances inspect standard IP packets without parsing SRv6 encapsulation. Steering is managed by SRv6 proxy nodes located on dedicated fabric Service Leaves. These nodes expose Node SIDs and Adjacency SIDs that map directly to the physical interfaces connected to firewall clusters. By embedding these SIDs into SRv6 Traffic Engineering policies at the ingress Cloud Gateways or border routers, the network dynamically diverts customer traffic through firewall inspection clusters when required, or routes non-inspected traffic directly to compute instances. Interoperability Validation and Architectural Evolution (11:57) Nebius validated its architecture through multi-vendor proof-of-concept testing, confirming that SRv6 uSID interoperates cleanly with major hardware vendors and coexists alongside legacy MPLS networks. Because SRv6 only requires baseline IPv6 connectivity in the transit underlay, Nebius deployed provider edge functions incrementally without re-architecting backbone switches. Nebius's ongoing roadmap includes extending SRv6 to its Internet Edge and internal data center interconnects, developing an automated in-house dynamic Traffic Engineering Controller, and building native SRv6 parsing directly into its proprietary firewall software. Gorovoy reports that native firewall awareness will eliminate the need for proxy service leaves, allowing security inspection to scale dynamically across the fabric. Nebius has also co-authored an IETF draft with Cisco detailing this virtual-to-physical interconnect framework. Nebius demonstrates that deploying SRv6 uSID at network edges creates an unstitched, multi-terabit cloud interconnect overlay across disparate network domains without upgrading intermediate transit hardware. However, maximizing the efficiency of this model still depends on upcoming software milestones, specifically automating policy control and implementing native SRv6 awareness inside security appliances to phase out physical proxy leaves.

精炼阅读摘要

Nebius网络工程师Alexey Gorovoy阐述了公司如何利用IPv6分段路由（SRv6）及微段（uSID）架构，消除传统数据中心与广域网之间的协议拼接，为大规模AI云构建端到端的互连网络。 AI负载驱动互连架构变革 (1:54) Nebius作为一家AI原生云服务商，在全球部署了大规模GPU集群，并通过私有骨干网与本地PoP节点互联各区域数据中心。在早期阶段，客户需求主要集中于模型训练前的大规模数据集导入，主要通过公网在本地数据中心终结，无需跨越骨干网。但随着客户工作负载成熟，需求迅速转向要求具有服务等级协议（SLA）保障的确定性带宽，传输规模从吉比特激增至数百吉比特乃至多太比特（Tbps），同时提出了端到端加密与内嵌防火墙检查等强制安全要求。 然而，传统跨域网络在边缘、WAN骨干网和数据中心内部采用了各自独立的协议栈。Nebius的数据中心内部依赖VXLAN EVPN连接自研的虚拟Cloud Gateway路由器，而在WAN骨干网则使用Option A SR-MPLS提供三层VPN（L3VPN）。两套协议栈在数据中心互连（DCI）边缘的协议转换与拼接，导致了严重的性能瓶颈、功能差异与运维复杂度，无法支撑AI时代动态、高吞吐的流量工程需求。 SRv6统一端到端网络栈 (5:17) 为了消除跨域转换边界，Nebius对现有覆盖网络技术进行了评估。VXLAN EVPN虽然在硬件和开源生态中普及度高，但缺乏原生流量工程（TE）能力，难以灵活实现动态服务编排；MPLS虽具备强大的流量工程能力，却难以在全IPv6纯数据中心织构以及软件虚拟路由器中横向扩展。Nebius选择以SRv6作为统一协议栈，其本质为标准IP-in-IP封装，同时原生支持将流量工程路径直接编码至报文头中，兼具两者的优势。 Nebius的底层网络全域采用纯IPv6，数据中心织构运行BGP，WAN骨干网运行IS-IS。在此基础上，SRv6功能仅需在网络边缘启用——包括物理对等边界路由器与基于FD.io VPP（矢量报文处理）框架自研的软件Cloud Gateway。中间网络节点仅执行标准IPv6转发，使L3VPN服务在端到端之间完全保持透明且无需拼接。 uSID压缩与动态服务链编排 (8:00) 在报文封装层面，Nebius引入了SRv6微段（uSID）压缩方案。uSID直接将分段指令编码到标准128位IPv6目的地址中，避免了引入额外的分段路由扩展头（SRH）、MPLS标签栈或VXLAN元数据报头。这种开销削减显著提升了报文转发性能，尤其优化了虚拟路由器软件查找路径的效率。此外，在迁移过渡期内，SRv6 PE功能可逐步在边缘上线，与现有MPLS底层无缝共存。 在安全服务集成方面，Nebius首先落地了SRv6服务无感知模式（Service-Unaware mode），使现有防火墙集群无需解析SRv6报头即可执行标准IP检测。该方案在数据中心织构的专用Service Leaf上部署SRv6代理节点，利用节点SID和邻接SID直接映射连接防火墙集群的物理接口。边缘设备可通过下发的TE策略，按需动态将流量引流至防火墙进行安全检查，或直接绕行。 未来路线与行业标准推进 (13:44) Gorovoy指出，经过硬件厂商与开源网络栈的深入概念验证（PoC），SRv6 uSID的多厂商互操作性与生产成熟度已得到验证。Nebius正在推进自研防火墙软件的原生SRv6感知改造。原生感知实现后，系统将不再依赖Service Leaf上的代理节点，从而能够在IPv6织构中的任意位置，按租户、应用或业务域粒度横向扩展并就近插入防火墙能力。 此外，Nebius正在研发自研动态SRv6流量工程控制器，以实现策略的实时自动化调配，并将SRv6扩展至互联网边缘及内部数据中心互连（DCI）。在标准生态建设方面，Nebius与Cisco等业界伙伴共同编写并提交了IETF草案，公开了SRv6在连接虚拟云环境与物理网络边缘时的架构设计、uSID分配方案及部署细节。 Nebius通过边缘部署SRv6 uSID与FD.io VPP软件网关，成功打破了数据中心与骨干网之间的协议孤岛，但其完全形态仍取决于后续原生SRv6感知防火墙的研发落地，以及自研动态流量工程控制器的实际调度表现。

Detailed notes — zh

## Background 该视频由 YouTube 频道 @Scale 于 2026 年 9 月 3 日发布，记录了 Nebius 网络工程师 Alexey Gorovoy 在圣克拉拉会议中心（SCCC）举办的现场演讲。视频简介指出，本场分享聚焦于大规模客户云互联带来的新架构挑战，展示 Nebius 如何利用 SRv6 打通虚拟云环境与物理网络边缘，实现跨数据中心与 WAN 域的端到端 VPN 和流量工程服务。 ## TL;DR 随着 AI 大模型训练对网络带宽、租户隔离与安全审查提出数 Tbps 级别的确定性需求，Nebius 早期‘DC 跑 VXLAN EVPN、WAN 跑 SR-MPLS’的架构在跨域拼接点形成了严重的性能与运维瓶颈。为此，Nebius 采用 SRv6 uSID 技术对网络边界进行重构，仅在云端软件网关（Cloud Gateway）与物理边界路由器两端启用 SRv6 PE 功能，底层纯 IPv6 网络无需感知 VPN 细节即可透传报文，彻底消除了协议转换网关。方案还通过在 Service Leaf 节点绑定 Adjacency SID，实现了面向无感知传统防火墙的动态流量工程引流，并在数据平面基于 FD.io VPP 完成了高吞吐虚拟路由器的自研与多厂商互操作性验证。未来，Nebius 计划推进防火墙原生支持 SRv6、自研动态 TE 控制器，并与思科等业界伙伴联合推进相关 IETF 标准化草案。 ## Atmosphere & style 整场演讲呈现出高度务实且条理清晰的硬核工程技术分享风格，演讲者 Alexey Gorovoy 语气沉稳笃定，以清晰的架构逻辑层层拆解痛点与破局之道。没有冗余的商业包装或空泛概念，内容紧扣协议交互细节、数据平面选型与实战踩坑经验，让人直观感受到 AI 基础设施团队直面数 Tbps 流量洪峰时的工程严谨与技术自洽。现场氛围专业而专注，结尾向开源社区与 IETF 标准化倡议的开放呼吁，更展现出顶级云网络团队推动行业标准演进的技术担当与包容胸怀。 ## Bulletin - [03:15](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=195s) Nebius 针对 AI 时代数 Tbps 级别的高确定性带宽诉求，淘汰了早期“数据中心跑 VXLAN EVPN、WAN 骨干网跑 SR-MPLS”的双协议栈架构，改用 SRv6 打造端到端统一云互联底座。 - [08:00](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=480s) 通过引入 SRv6 uSID（Micro-SID）压缩技术，全网仅需在两端边缘节点（软件 Cloud Gateway 与物理 Border Router）启用 SRv6 PE 功能，底层中间网络保持纯 IPv6 转发，彻底消除了协议转换网关与扩展头开销。 - [10:32](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=632s) Nebius 在自研云网关的数据平面选型上采用 FD.io VPP，同时通过 Service Leaf 代理接口绑定 Adjacency SID 实现了存量无感知防火墙的服务链按需引流。 - [16:12](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=972s) Nebius 联合 Cisco 及其他网络运营商共同起草了规范该架构的 IETF 标准化草案，未来演进重点包括在自研防火墙上原生支持 SRv6 以及构建动态 TE 控制器。 ## Key takeaways - [00:03](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=3s) 传统跨域云互联方案因各网络域（边缘、骨干、数据中心）采用孤立协议栈，在域边界产生大量协议转换点，成为限制全网吞吐与运维效率的结构性瓶颈。 - [01:54](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=114s) Nebius 业务初期依托纯公网进行单次重载的数据集导入且流量留在本地 Region，但随着 AI 模型训练对容量和确定性带宽要求的提升，这一模式难以为继。 - [03:15](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=195s) 单客户互联带宽飙升至数百 Gbps 乃至数 Tbps，加上端到端加密与防火墙审查的硬性需求，促使互联网络必须兼具多租户 VPN 隔离与精细化流量工程能力。 - [03:15](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=195s) 早期的“DC 跑 VXLAN EVPN、WAN 跑 SR-MPLS”组合由于协议拼接成本高且不同硬件芯片支持参差不齐，在互联边缘形成了沉重的运维与性能负担。 - [05:17](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=317s) VXLAN EVPN 缺乏原生流量工程能力，而 MPLS 难以优雅渗透进现代数据中心虚拟网关，SRv6 凭借 IP-in-IP Overlay 封装与内生源路由特性成为兼顾两者的最优解。 - [08:00](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=480s) SRv6 端到端 L3VPN 架构中，Cloud Gateway 与物理 Border Router 充当 PE 角色，底层的 DC（BGP）与 WAN（IS-IS）网络仅需保证 IPv6 可达性，实现彻底解耦。 - [08:00](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=480s) 采用 SRv6 uSID 机制可将 Segment ID 直接编码至外层 IPv6 目的地址中，避免传统 SRH 扩展头和额外标签开销，大幅降低了虚拟路由器的报文解析负担。 - [10:32](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=632s) 针对安全网元适配，Nebius 采用“SRv6 服务无感知模式”，通过 Service Leaf 将 Adjacency SID 绑定至物理接口，利用 TE Policy 实现流量的按需引流审查。 - [12:06](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=726s) 基于主流网络芯片对 uSID 互操作性的 PoC 验证，Nebius 最终采用 FD.io VPP 数据平面成功构建了可编程的自研软件 Cloud Gateway。 - [12:06](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=726s) MPLS 与 SRv6 具备平滑共存特性，由于 PE 功能仅下沉于网络最外围，现有底层基础设施无需颠覆性改造即可完成向 SRv6 的无缝过渡。 - [13:44](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=824s) 消除协议转换点不仅统一了端到端控制与数据平面，还极大简化了网络内部运维复杂度，使边界路由器与软件网关能够独立进行 Scale-Out 弹性扩容。 - [14:52](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=892s) Nebius 后续演进将把 SRv6 推广至互联网边缘（Internet Edge）与 DCI，并在自研防火墙上原生支持 SRv6 以摆脱 Service Leaf 代理瓶颈。 - [14:52](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=892s) 自研动态 TE 控制器将取代当前的静态配置策略，以实现基于全网实时状态与业务意图的智能化、自适应流量路径调度。 - [16:12](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=972s) Nebius 与 Cisco 等行业伙伴联合发布了 IETF 标准化草案，详尽定义了 SID 规范与网络模型，旨在推动行业共建下一代 AI 云网一体化互连标准。 ## Detailed walkthrough ### [00:03](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=3s) 行业背景与跨域互联的结构性瓶颈 来自 Nebius 的网络工程师 Alexey Gorovoy 在演讲开场时表明，本次分享将深入探讨 Nebius 客户云互联（Customer Cloud Interconnect）架构的演进历程，并重点解析为何选择将 SRv6 作为核心底座技术。从整个云计算行业的视角来看，绝大多数云服务商都会向企业级客户提供某种形式的专用云互联方案，本质上就是从客户机房或本地数据中心直连到云厂商骨干网络的私有通道。这类互联通常面临三大核心刚性诉求：严格的租户隔离（Tenant Isolation）、可预测的高确定性带宽（Predictable Bandwidth）以及内置的集成安全能力（Integrated Security）。 在传统网络实现中，流量必须从远端接入点出发，一路横穿广域骨干网、数据中心 Fabric，最终抵达客户在云内的虚拟环境。在这个过程中，流量势必跨越多重网络管理域，包括边缘域（Edge）、骨干域（Backbone/WAN）和数据中心域（Data Center）。历史上，每个网络域都由一套为各自运行环境量身定制的专用技术栈构建而成。Alexey 指出，单独看这些技术本身并没有任何问题，它们在各自领域都表现优异；但真正的痛点在于，当试图将它们整合成端到端的统一网络时，各协议之间根本无法无缝衔接。这种割裂必然会在交界处产生大量的“协议转换点（Protocol Translation Points）”和服务边界，最终演变成全网的吞吐与运维瓶颈。Nebius 探索新方案的核心目的，正是为了彻底消除这些架构约束。 ### [01:54](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=114s) Nebius 初始业务模型与网络架构概况 Nebius 是一家专注于大规模 GPU 集群建设与开发 AI 原生云计算平台的新兴基础设施云服务商，为客户构建、训练和推理模型提供全栈技术支持。在地域分布上，Nebius 在欧洲与美国运营着多个大型数据中心，各 Region 之间通过私有骨干网互联，而每个站点既能通过本地互联出口访问互联网，也能借助最近的电信网络 PoP 点接入公网。 在业务开展初期，客户互联的主要诉求相对简单明了：核心是将海量训练数据集从客户本地机房传输到 Nebius 云端对象存储中，以供后续的大规模模型训练使用。在这一阶段，Nebius 直接依赖公网进行传输。由于数据迁移主要发生在客户最初入驻（Onboarding）时的单次重载写入阶段，流量完全保持在特定 Region 本地，并不需要穿越跨地域骨干网。这种“单次重载、本地留存”的运作模式在初期极为有效，并深度塑造了 Nebius 最初设计的前端网络拓扑。 ```mermaid flowchart LR accTitle: 早期基于公网的数据入驻拓扑 accDescr: 客户本地数据通过公网单次导入本地数据中心，无需跨越骨干网。 subgraph Client["客户本地"] A["客户机房数据集"] end subgraph Edge["公网接入"] B["Internet / 本地 PoP"] end subgraph Region["Nebius 本地数据中心"] C["Cloud Gateway"] D["本地 GPU/存储集群"] end A --> B B --> C C --> D ``` ### [03:15](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=195s) 纯 IPv6 基因下的早期架构与破局危机 在技术架构选型上，Nebius 从成立伊始就是纯 IPv6 协议的坚定践行者。从底层数据中心 Fabric、计算集群、存储系统到上层各类服务组件，全部原生运行在 IPv6 基础之上。在该基础设施中，有两个非常关键的核心软件组件均由 Nebius 内部自主研发：云网关（Cloud Gateway）与防火墙（Firewall）。它们是基于开源组件开发的高性能软件虚拟路由器，其中云网关的核心职责就是将客户的虚拟云上工作负载连通至外部物理世界。在协议实现上，数据中心内部采用 VXLAN EVPN 协议栈，而进入 WAN 广域网后则转为 MPLS Segment Routing（SR-MPLS）。基于这套组合栈，Nebius 提供 L3VPN 服务，以安全可靠的方式将虚拟机挂载到公网。 然而，随着 AI 业务规模的井喷，客户互联的 SLA 需求发生了剧烈变化： 1. **确定性与专用带宽取代了尽力而为（Best-effort）传输**：客户不再接受基于公网的浮动抖动，要求必须具备高可靠的确定性带宽； 2. **容量爆发式增长**：单客户互联带宽需求迅速飙升至数百 Gbps，部分场景甚至达到多个 Tbps 级别； 3. **安全防护强制前置**：全链路端到端加密与可选的动态防火墙流量审查（Firewall Service Inspection）必须原生内嵌在方案中。 面对数 Tbps 级别的跨域流量互通，网络必须在跨骨干网与跨 DC 域时兼具多租户 VPN 隔离与流量工程（Traffic Engineering, TE）能力。此时，早期“DC 跑 VXLAN EVPN、WAN 跑 SR-MPLS”的双协议栈设计暴露出了致命缺陷——两套体系在数据中心互联边缘（DCI Edge）的“缝合与协议转换点（Stitching Point）”迅速演变成了无法承受的运维与性能瓶颈。 ### [05:17](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=317s) 重构网络边界：为何选定 SRv6 针对这一困局，Nebius 没有采取缝缝补补的修补策略，而是提出了一套全新的云互联架构。Alexey 强调，这并不仅仅是一次简单的网络连通性升级，而是重新定义了骨干网与边缘网的演进路径，打破了虚拟网络与物理网络之间长期存在的人为边界。架构的核心诉求是在虚拟云环境与物理网络边缘之间构筑一座高效统一的桥梁，在横跨异构网络的同时，平滑扩展多租户隔离能力与端到端流量工程能力，以实现动态服务链编排与精细化带宽管理。 在技术对比中，VXLAN EVPN 拥有极高的硬件厂商支持度和活跃的开源生态，极易在混合异构环境中落地；但其致命短板在于**缺乏原生的流量工程支持**，若想动态将流量精细化牵引至防火墙等安全服务节点，往往需要设计极其繁琐且缺乏弹性的非标准化路由方案。相反，MPLS 虽然具备成熟完备的流量工程体系，却极难优雅地渗透并下沉到现代数据中心主机与虚拟网关内部。引入专用的拼接网关（Stitching Gateway）来强行撮合两者的尝试更是代价沉重：不同芯片实现支持度参差不齐、协议二次转换直接损耗芯片转发线速性能，并给自动化运维带来沉重负担。 基于此，SRv6 脱颖而出，成为 Nebius 破局的唯一解。SRv6 在报文格式上保持了极为简洁的 IP-in-IP Overlay 封装，同时原生将先进的源路由与流量工程能力融入其中，"可以说是兼取了两个世界的最大优势"。 ### [08:00](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=480s) 场景一：基于 SRv6 uSID 的端到端 L3VPN Overlay Nebius 实施的第一个核心场景，是基于 SRv6 uSID（Micro-SID）压缩技术的端到端 L3VPN Overlay。由于全网底层已具备纯 IPv6 路由能力，整套落地逻辑变得极为简洁：Nebius 仅需在网络真正的两端边缘节点开启 SRv6 功能——在云端侧为软件实现的 Cloud Gateway，在物理网络侧则为物理对等边界路由器（Border Peering Router）。 ```mermaid flowchart LR accTitle: 基于 SRv6 的端到端跨域架构 accDescr: Cloud Gateway 与物理边界路由器作为端到端 SRv6 边缘节点，底座 IPv6 路由网络无需感知 VPN 细节。 subgraph Cloud["云端环境"] VM["客户虚拟机"] --> CGW["Cloud Gateway (SRv6 PE)"] end subgraph Core["底层纯 IPv6 Underlay"] CGW --> DCR["DC Fabric (BGP)"] DCR --> WAN["WAN 骨干网 (IS-IS)"] WAN --> BR["Border Router (SRv6 PE)"] end subgraph External["物理网络边缘"] BR --> ExtNet["客户本地 / 专线互联"] end ``` 在这套极简拓扑中，Cloud Gateway 与物理 Border Router 共同扮演传统 L3VPN 中 Provider Edge（PE）的角色。而夹在两者之间的整个中间网络，仅作为纯粹的底座 IPv6 路由转发路径： - 数据中心内部继续运行 BGP； - WAN 骨干网域内继续运行 IS-IS； - 这些底层协议的唯一核心任务，仅仅是保证 SRv6 Locator IPv6 前缀在全网具备底层的可达性。 通过这种解耦设计，上层的 VPN 业务报文在端到端传输中全程透明且保持封装结构不破，彻底消除了数据中心与 WAN 边界处所有复杂的协议转换网关与跨协议转交点。Alexey 进一步剖析了 SRv6 uSID 的封装优势：传统 MPLS 依赖外挂的多层标签栈，VXLAN 则需要携带专门的 VNI 元数据及 UDP 外层头；而 SRv6 在引入 uSID 机制后，连标准的段路由扩展头（SRH, Segment Routing Header）都可以彻底省略。所有指示转发路径的 Segment ID 均被压缩并直接编码进外层 IPv6 报文的目的地址（Destination Address）字段中。这种设计不仅大幅消减了报文头开销，更为软件虚拟路由器卸下了沉重的解包重载负担，带来了显著的报文转发吞吐提升。 ### [10:32](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=632s) 场景二：基于 SRv6 的动态防火墙服务链编排 架构落地的第二个核心场景是安全服务链的动态注入（Service Injection / Firewall Service Chaining）。考虑到存量安全网元的适配现状，Nebius 率先采用了“SRv6 服务无感知模式（SRv6 Service-Unaware Mode）”。这意味着防火墙本身保持传统的数据包检查模式运作，完全无需理解、解析或支持复杂的 SRv6 协议字段。 为了让标准防火墙平滑接入 SRv6 体系，Nebius 在数据中心 Fabric 中设立了专用的服务叶子节点（Service Leaf），作为所谓的“代理节点（Proxy Nodes）”。具体实现机制包含以下关键环节： - **SID 标记**：Service Leaf 原生支持 SRv6，并分配对应的 Node SID 与 Adjacency SID； - **接口绑定**：Service Leaf 将特定的 Adjacency SID 精确绑定到其连接防火墙的物理接口上； - **动态策略注入**：在边缘两端的 Cloud Gateway 和物理 Border Router 上下发流量工程策略（TE Policy），策略显式携带代表该防火墙接口的 Segment ID 路径； - **按需引流（Traffic Steering）**：当租户流量需要强制安全审查时，边缘节点通过 TE Policy 动态将报文引流至对应的 Service Leaf 并转交防火墙；而针对无需检查的流量，则直接走最短路径转发，无需绕经安全网元。 这种模式使网络团队既能享受 SRv6 带来的极高灵活性，又彻底解耦了底层网络演进与上层安全设备协议升级之间的依赖关系。在完成两大场景的技术方案介绍后，Alexey 进而转向讨论团队在前一年推进方案落地评估时获得的实操经验。 ### [12:06](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=726s) 概念验证与技术落地：VPP 数据平面与 MPLS/SRv6 平滑共存 Nebius 团队在过去一年中投入了大量精力进行技术预研与概念验证（PoC），针对不同网络硬件厂商的实现成熟度展开了深度测试。测试结果令人振奋：各主流厂商对 SRv6 micro-SID（uSID）的互操作性支持表现优异，这一结果给予了团队极大的信心，推动他们进一步自研定制化的虚拟路由器——云网关（Cloud Gateway）。在数据平面的选型上，团队最终选择了 FD.io VPP（Vector Packet Processing）。VPP 完美契合其软件环境，完整支持所需的全部 SRv6 可编程网络功能，从而帮助团队打通了端到端解决方案的最后一公里。 从现有架构的演进与集成视角来看，MPLS 与 SRv6 展现出了出色的共存能力。这意味着在现有生产网络中引入 SRv6 完全不需要对基础设施进行伤筋动骨的大规模改造或重配置。正如演讲者所强调的，只要底层 Underlay 网络支持标准的 IPv6 路由转发，PE（Provider Edge）功能就仅需部署在网络的最外围边缘节点上。总结整个工程落地的核心经验就是：SRv6 特性已经高度成熟，跨厂商设计具备完善的互操作性，并且存在一条经过充分验证的平滑迁移路径。 - **厂商互操作性验证**：针对多家厂商的 SRv6 micro-SID（uSID）实现进行了深度 PoC 测试，确认多厂商混合组网在协议层面高度互通。 - **软件云网关架构**：采用 VPP 数据平面构建定制化虚拟路由器，利用其强大的可编程能力终结与转发 SRv6 流量。 - **轻量化迁移代价**：Underlay 网络只需提供纯 IPv6 转发能力，中间核心节点无须感知 SRv6 状态，仅在网络边界部署 PE 节点即可完成业务承载。 --- ### [13:44](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=824s) 架构总结：端到端统一性与运营运维极简 回顾整个架构演进，SRv6 带来的核心价值可以用两个词概括：“极简”（Simplicity）与“统归”（Unification）。Nebius 最初面临的核心痛点，是如何将 VPN 业务从远端客户接入 PoP 点，跨越多个异构网络域，一路无缝延伸至客户在数据中心内部的虚拟云环境（VPC），同时还要深度兼顾多租户隔离与精细化的流量工程（Traffic Engineering）能力。SRv6 的端到端贯通彻底解决了这一难题。 更重要的是，SRv6 极大地减轻了网络团队的日常运维负担。过去因为不同网络域使用不同技术栈，运维团队必须维护协议转换节点，不仅面临复杂的跨协议管理配置，还必须同时维护两套完全独立的控制与数据平面协议。消除协议转换节点后，其余网络部分保持了纯粹与简单。正是这种网络内部的极度极简，为平台带来了极高的横向扩展能力（Scale-Out），团队可以轻松扩容边界路由器与软件云网关，向上层客户提供海量、弹性的端到端 VPN 互连服务。 ```mermaid flowchart LR accTitle: SRv6 端到端云互联架构 accDescr: 展示从远端客户 PoP 经由标准 IPv6 Underlay 直达客户虚拟云环境的 SRv6 架构 subgraph ClientEdge["网络边缘"] POP["远端 PoP 边缘路由器 (PE)"] end subgraph CoreWAN["底层传输 (Underlay)"] IPv6Core["纯 IPv6 转发网络<br/>(无协议转换 / 无状态中间节点)"] end subgraph CloudDC["AI 云数据中心"] VPPGW["VPP 虚拟云网关<br/>(支持弹性 Scale-Out)"] VPC["客户虚拟云环境 (VPC)"] end POP -->|"端到端 SRv6 封装 (VPN + TE)"| IPv6Core IPv6Core --> VPPGW VPPGW --> VPC ``` --- ### [14:52](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=892s) 未来演进：SRv6 原生防火墙与动态 TE 控制器 在展望未来演进方向时，演讲者分享了 Nebius 正在推进的几项前沿工作。目前团队主要聚焦于基础设施层面的功能使能，并正规划将 SRv6 的应用范围从现有的互连骨干扩展到更多网络域，包括互联网边缘（Internet Edge）以及数据中心互连（DCI）。在业务链注入（Service Chaining）方面，虽然目前架构基于非 SRv6 感知的服务模式（SRv6-unaware），但由于 Nebius 自研并完全掌控其内部防火墙系统，团队正积极推进在防火墙上原生支持 SRv6。 防火墙原生支持 SRv6 将带来巨大的架构飞跃：它将彻底消除对服务叶节点（Service Leaf）代理网关的依赖。一旦解除该瓶颈，Nebius 就可以在简单支持 IPv6 的网络基础底座上，按需、细粒度地在任何位置插入防火墙实例，从而面向任意具体应用、网络域、租户或流量切片实现高度灵活的独立扩展。此外，团队还在自研专属的流量工程（TE）控制器，以取代目前的静态配置方式，实现基于网络状态与业务意图的动态路径策略下发。 - **多域扩展规划**：计划将 SRv6 推广覆盖至 Internet Edge 与 DCI（Data Center Interconnect）网络场景。 - **SRv6 原生安全注入**：将 SRv6 栈原生下沉至自研防火墙，告别 Proxy 节点中转，实现安全服务链对细粒度业务切片与应用的自由编排。 - **自研动态 TE 控制器**：从静态策略配置转向集中式、智能化的 TE 控制器，支持自动化、动态的流量调度与路径工程。 --- ### [16:12](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=972s) IETF 标准化草案与社区合作倡议 在演讲的尾声，演讲者热情地向参会者推荐了 Nebius 联合思科（Cisco）团队及其他网络运营商共同提交的 IETF 标准化草案。他谦逊地指出，这项工作并非凭空“发明”了一种颠覆性的全新网络协议，而是提供了一套经过大规模实战检验的设计架构指南——清晰规范了如何利用 SRv6 将云原生虚拟环境与物理网络边缘高度统一起来，并在端到端路径上同时支持多租户 VPN 与高级流量工程特性。 该草案在技术细节上提供了极高的参考价值，详尽拆解了方案中的配置规范、各种特定 SID（Segment Identifier）的行为定义与实现细节。对于现场及观看演讲想要深入探究底层实现的工程师而言，所有未能在简短演讲中展开的硬核技术细节均可在该草案中找到对应论述。演讲者诚恳呼吁开源社区与产业界同行阅读该草案并提供宝贵反馈，更欢迎志同道合的团队加入后续的协同标准化与联合研发工作，随后演讲在全场掌声中转入现场问答环节。 - **标准化合作**：与 Cisco 及其他主流运营商联合起草 IETF Draft，系统沉淀云网一体化互连的工程经验。 - **草案核心内容**：涵盖虚拟云环境与物理边缘的连接模型、各类 SID 的定义分配与生命周期管理、端到端 VPN 与 TE 的实现参数。 - **开放协作号召**：欢迎业界专家阅读草案文档、提交反馈（Feedback），共同完善下一代 AI 云互联架构体系。 ## Notable quotes > [00:03](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=3s) 各协议之间根本无法无缝衔接。这种割裂必然会在交界处产生大量的“协议转换点”和服务边界，最终演变成全网的吞吐与运维瓶颈。 — Alexey Gorovoy > [01:54](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=114s) 单次重载、本地留存 — Alexey Gorovoy > [03:15](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=195s) 缝合与协议转换点（Stitching Point） — Alexey Gorovoy > [05:17](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=317s) 并不仅仅是一次简单的网络连通性升级，而是重新定义了骨干网与边缘网的演进路径，打破了虚拟网络与物理网络之间长期存在的人为边界。 — Alexey Gorovoy > [05:17](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=317s) 缺乏原生的流量工程支持 — Alexey Gorovoy > [05:17](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=317s) 可以说是兼取了两个世界的最大优势 — Alexey Gorovoy > [10:32](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=632s) SRv6 服务无感知模式（SRv6 Service-Unaware Mode） — Alexey Gorovoy > [10:32](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=632s) 代理节点（Proxy Nodes） — Alexey Gorovoy > [13:44](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=824s) 极简 — Alexey Gorovoy > [13:44](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=824s) 统归 — Alexey Gorovoy > [13:44](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=824s) 消除协议转换节点后，其余网络部分保持了纯粹与简单。正是这种网络内部的极度极简，为平台带来了极高的横向扩展能力 — Alexey Gorovoy > [16:12](https://www.youtube.com/watch?v=kfqO2CA9-GU&t=972s) 这项工作并非凭空“发明”了一种颠覆性的全新网络协议，而是提供了一套经过大规模实战检验的设计架构指南 — Alexey Gorovoy ## Mentioned Alexey Gorovoy, Nebius, @Scale, Santa Clara Convention Center, Cisco, IETF, FD.io VPP, SRv6, uSID, SR-MPLS, VXLAN EVPN, BGP, IS-IS, L3VPN ## Video description Alexey Gorovoy from Nebius presents "Building scalable AI cloud interconnects with SRv6" live from the Santa Clara Convention Center. Large-scale customer interconnects place new demands on network architectures, requiring predictable bandwidth, integrated network services, and consistent operation across data center and WAN domains. In this session, we present Nebius' evolving architecture for customer cloud interconnects, using SRv6 as the fundamental architectural building block to bridge virtual cloud environment with the physical network edge. We will show how this approach enables end-to-end VPN and Traffic Engineering services without protocol translation between data center and WAN domains, and share our latest implementation experience. Learn more about @Scale here: atscaleconference.com [Source](https://www.youtube.com/watch?v=kfqO2CA9-GU)

Source quotes

[0:03] Alexey Gorovoy: 各协议之间根本无法无缝衔接。这种割裂必然会在交界处产生大量的“协议转换点”和服务边界，最终演变成全网的吞吐与运维瓶颈。 [1:54] Alexey Gorovoy: 单次重载、本地留存 [3:15] Alexey Gorovoy: 缝合与协议转换点（Stitching Point） [5:17] Alexey Gorovoy: 并不仅仅是一次简单的网络连通性升级，而是重新定义了骨干网与边缘网的演进路径，打破了虚拟网络与物理网络之间长期存在的人为边界。 [5:17] Alexey Gorovoy: 缺乏原生的流量工程支持 [5:17] Alexey Gorovoy: 可以说是兼取了两个世界的最大优势 [10:32] Alexey Gorovoy: SRv6 服务无感知模式（SRv6 Service-Unaware Mode） [10:32] Alexey Gorovoy: 代理节点（Proxy Nodes） [13:44] Alexey Gorovoy: 极简 [13:44] Alexey Gorovoy: 统归 [13:44] Alexey Gorovoy: 消除协议转换节点后，其余网络部分保持了纯粹与简单。正是这种网络内部的极度极简，为平台带来了极高的横向扩展能力 [16:12] Alexey Gorovoy: 这项工作并非凭空“发明”了一种颠覆性的全新网络协议，而是提供了一套经过大规模实战检验的设计架构指南

Source quotes

[0:03] Alexey Gorovoy: they are not cleanly integrating end-to-end [3:15] Alexey Gorovoy: predictable, dedicated bandwidth [3:15] Alexey Gorovoy: hundreds of gigabits and multi-terabytes per second [3:15] Alexey Gorovoy: end-to-end encryption and inline firewall inspection [5:17] Alexey Gorovoy: SRv6 (Segment Routing over IPv6) [8:00] Alexey Gorovoy: SRv6 Micro-Segment (uSID) [10:32] Alexey Gorovoy: SRv6 Service-Unaware mode [11:57] Alexey Gorovoy: Vector Packet Processing (VPP) [13:44] Alexey Gorovoy: simplicity and unification [13:44] Alexey Gorovoy: native SRv6 awareness directly to the firewall application

Original transcript

[0:03] Good afternoon. Honored to be here with [0:05] you today. My name is Alex Graway. I'm [0:07] network engineer at Nabius and I'm [0:09] excited to share the case study on how [0:12] we are evolving our customer cloud [0:14] interconnect architecture and [0:15] specifically how we use SRV6 as a [0:19] fundamental technology. Uh for that [0:23] before we jump into neighbor specific [0:25] use case let's set a broader industry [0:27] context. So most of cloud providers [0:30] today expose some form of a cloud [0:32] interconnect solution which is basically [0:34] a private connection from customer [0:36] premises to the cloud providers network. [0:39] The fundamental requirements are tenant [0:42] isolation, predictable bandwidth and [0:44] integrated uh security and to be able to [0:48] take this uh traffic from the remote [0:50] interconnect points all the way across [0:52] the backbone data center into the [0:55] customer cloud environments. Traffic [0:57] typically has to cross multiple network [0:59] domains like edge, backbone, data center [1:02] and traditionally each of those domains [1:05] has been built with a dedicated [1:07] technology uh stack optimized for its uh [1:10] own environments and there is nothing [1:13] wrong with those technologies [1:14] individually. However, the problem is [1:16] that they are not cleanly integrating uh [1:19] end to end. So creating protocol [1:21] translation points, service boundaries [1:24] and potential bottlenecks. So in this [1:27] talk I'll share how we at neighbors [1:29] address this problem and describe the [1:31] solution which helps us eliminating uh [1:34] those constraints. First I'll show our [1:38] initial architecture we started with [1:40] then how it stopped scaling for the new [1:43] cloud interconnect requirements and [1:45] finally how SRV6 changed the design and [1:49] what we've learned implementing it. So [1:52] let's get started. [1:54] Let me give you a brief overview of our [1:56] current network architecture. So, Nabius [1:58] is a new cloud company. We build large [2:00] scale GPU clusters and we develop our AI [2:03] native cloud computing platform. So, we [2:06] create the full stack of technologies to [2:08] provide our customers with everything [2:09] they need to build, train and run their [2:11] models and apps all in one place. And [2:14] being a global company, we operate [2:16] multiple data centers across Europe and [2:19] the US. So regions are interconnected [2:21] with a private backbone but also each [2:23] site is individually connected to the [2:25] internet either locally or via the [2:28] closest telecommunication uh point of [2:30] presence and uh from the customer [2:33] interconnect uh standpoint. The major [2:36] demand from the beginning was uh [2:39] basically transferring big customers [2:42] data sets from their premises into neios [2:45] cloud store them locally and used for [2:47] further training activities and we used [2:49] internet for that. [2:52] So the traffic never traverses inter [2:53] regional uh backbone and always stayed [2:55] local for a particular um region and uh [3:00] that model worked well because the main [3:04] uh heavy data movement happened [3:06] basically only once during the customer [3:09] uh on boarding and that also shaped the [3:12] front-end network architecture we built [3:14] initially. [3:15] Let's take a closer look on this one. Um [3:18] first we at Mabis are strong supporters [3:20] and practitioners for IPv6 network [3:22] protocol. So all of our infrastructure [3:24] components including data center fabric [3:27] compute cluster storage and rest of [3:28] services function over IPv6. Two other [3:32] key components of our infrastructure are [3:34] the cloud gateway and firewall. So those [3:37] two are in-house developed software [3:40] virtual routers built based on the open [3:42] source uh components and u the primary [3:46] goal of the cloud gateways to [3:47] interconnect customer virtual workloads [3:50] to the outside world. We use VXLAN EVPN [3:53] protocol ST for that within the data [3:55] center domain and then further into the [3:57] WAN we use ALA segment routing. [4:01] So on top of those protocol stack we [4:03] provide layer GDP and service to connect [4:05] customer virtual machines to the [4:07] internet in a secured and reliable way [4:09] and that was manageable. [4:13] However, the requirements started [4:14] changing. First, customers increasingly [4:17] wanted predictable and dedicated [4:20] bandwidth um rather than best effort [4:23] internet connectivity and uh second uh [4:27] the capacity demand moved into hundreds [4:29] and in some cases multiple terabytes per [4:32] second and third security functions like [4:35] end to end encryption and optional [4:37] firewall service inspection had to [4:39] become part of a solution. So that [4:41] changed uh the problem significantly as [4:44] we had to start building large scale [4:47] customer interconnects and then carry [4:50] this uh traffic across the backbone data [4:53] center domain all the way to the cloud [4:56] gateway. To do that efficiently, we [4:59] needed VPN and traffic engineering [5:01] across uh domains. [5:05] But having two different protocol STS [5:08] the translation uh the stitching point [5:10] between them became an operational and [5:12] functional uh bottleneck. [5:17] So let me introduce the new cloud [5:20] interconnect architecture approach and [5:23] it is not just a connectivity series but [5:26] it's a new architecture that redefineses [5:29] how we uh evolve our backbone and edge [5:32] networks but also rethink the boundary [5:35] between the virtual and physical [5:37] networks. The goal was to build an [5:39] efficient bridge between virtual cloud [5:42] environment and the physical network [5:44] edge. Uh extending multi-tenant [5:47] capabilities but also traffic [5:49] engineering capabilities for efficient [5:52] service chaining creation and bandwidth [5:54] management. [5:56] So that what led us to SRV6 as a [6:01] fundamental uh building block for that [6:03] architecture. So let's take a look at [6:07] why SRB6 fits this architecture and what [6:10] we've learned implementing it. [6:15] Evaluating Kakar current protocol STS uh [6:18] we came to the following conclusions. [6:20] One of the VXLVPN strong advantages is [6:22] its wide adoption across uh different [6:25] hardware vendors but also open source [6:27] solutions. So it's really make it easier [6:31] to integrate different hardware and [6:33] software components in a diverse and [6:35] hybrid environments like ours. However, [6:38] the lack of native traffic engineering [6:39] capabilities limits its ability to [6:42] support the injection of different [6:44] network functions like firewall in a [6:46] dynamic and granular uh fction fashion. [6:50] And typically to achieve that with VXLAN [6:53] that would require a specific and [6:55] non-flexible uh routing designs. While [6:58] MLS definitely had those capabilities, [7:00] they are barely applicable in the data [7:02] center domain. So here we are with two [7:05] separate protocol STS and uh which [7:09] require a specific stitching gateway [7:12] functionality to interconnect uh both of [7:15] them which raises a whole set of new [7:18] challenges on its own. So first of all [7:20] the functionality might not be simply [7:22] available across different [7:23] implementations or the particular [7:25] implementation might impact the [7:28] performance of a hardware and it just [7:31] raises the overall complexity due to [7:34] protocol uh translation also introducing [7:36] a lot of operational uh burden on top of [7:39] that. So that's why we believe that SR6 [7:43] addresses all of those concerns. It [7:46] basically takes uh the best out of both [7:48] worlds staying as a simple IP and IP [7:52] encapsulation encapsulated overlay but [7:55] incorporating traffic engineering [7:57] capabilities uh within it. [8:00] So let's take a closer look uh at our [8:03] first use case which is overlay based on [8:05] SRV6 uh micro seat. As I mentioned [8:09] earlier, we use levpn service to [8:12] interconnect uh virtual machine to the [8:14] outside uh world and the solution is [8:17] pretty straightforward. So taking [8:19] advantage of our current IPv6 routed [8:22] network, we simply adding SRV6 [8:25] functionality on the edge points of [8:27] those networks which are the cloud [8:29] gateway on the cloud side and physical [8:31] border peering border on the physical uh [8:35] edge. So those two being an edge points [8:38] of the domain uh simply start operating [8:41] as a traditional verdpn provider uh edge [8:45] no nodes and the rest of the network in [8:48] the middle is simple IPv6 routed network [8:51] though you can still use different [8:54] routing protocols uh for that. Well in [8:57] our case we do BGP still in the data [8:58] center and ISIS in the van domain. [9:00] However, the the main uh goal of those [9:05] protocols is simply support the [9:07] reachability for the SRV6 locator IPv6 [9:11] prefixes. So on top of that we can build [9:14] VPN service which uh remains transparent [9:18] and untouched end to end. And this is [9:21] how we basically eliminate any [9:24] translation or handoff points between [9:26] different protocols uh in the middle of [9:28] our network at the DCI age. [9:34] I would also like to highlight that the [9:37] efficiency of SRV6 encapsulation is that [9:40] it allows to eliminate any additional uh [9:44] protocol layer header on top of that [9:46] like traditionally we use with MLS or [9:48] VXLAN where we need to carry uh the [9:51] label stack or the DNA uh metadata. So [9:56] uh with SRV6 especially with the new [9:59] micro seat compression method we also [10:02] eliminating the segment routing [10:04] extension header uh as well because all [10:07] the segment ids are encoded into the [10:11] destination IPv6 address uh fields. So [10:15] this greatly reduces the packet overhead [10:19] and it also uh increases the packet [10:22] performance efficiency especially for [10:25] software virtual routers. [10:32] Let's look at our second use case which [10:34] is uh service injection firewall service [10:38] chaining. So uh there are different [10:41] modes of doing it. We started with a [10:44] so-called SRV6 service unaware mode [10:47] which basically means that firewall uh [10:50] continue operates as a traditional [10:52] inspectional functional being completely [10:55] unaware of SRB6 functionality. Uh [10:58] however to be able to steer traffic [10:59] through the firewall we need to uh add a [11:03] specific so-called proxy nodes. Uh so [11:08] those are the dedicated service leaves [11:10] in our data center uh network uh design. [11:14] So being SRV6 enabled means that they uh [11:17] support the node seat and adjacency [11:19] seat. So those adjacency seat they [11:21] marked up the interfaces which connect [11:24] the firewall to the fabric. So that [11:26] means that using those segment ids we [11:28] can rely on them in our traffic [11:31] engineering policy that we instantiate [11:33] on the edge points of our network again [11:35] which are the cloud gateway and the [11:37] border router and that's basically how [11:39] we steer the traffic dynamically to the [11:43] firewall if we need it. So uh steering [11:46] kit kit through the traffic engineering [11:48] policy or routing it forward if the [11:51] inspection is not required. [11:57] Let me also share a bit of our [11:58] implementation experience with uh the [12:01] technology. So we were working on the [12:03] solution evaluation uh the previous [12:06] year. So doing multiple proof of [12:08] concepts, deep testings, evaluating [12:10] different uh vendors implementations [12:14] readiness and uh yeah we were [12:18] successfully confirmed the [12:19] interoperability of SRV6 micro seat [12:22] implementation uh across of them. So [12:24] that really encouraged us to move [12:26] forward uh with the development of our [12:29] custom virtual router uh cloud gateway. [12:32] So for this uh we picked up uh the DPP [12:36] data plane which fits our environment [12:38] because it supports all the SRV6 [12:41] programming uh functionality and that [12:44] helped us to to to finalize the the [12:47] design and build the end toend uh [12:50] solution and um [12:53] also important part from the integration [12:56] perspective uh MLS and SRV6 uh can [13:00] easily coexist [13:02] uh altogether that means that [13:04] introducing SRV6 into uh current uh [13:08] environment it's uh really easy because [13:11] it doesn't require any significant [13:14] change or reconfiguration to the [13:16] existing infrastructure because as I [13:17] mentioned above if the IPv6 routing is [13:21] already supported in the underly network [13:23] so that mean that PE functionality might [13:26] be able added only on the edge points um [13:29] of the networks so the main lesson [13:31] Lessons learned is that the feature is [13:34] mature, design is interoperable and [13:36] there are clear validated uh migration [13:40] path. [13:44] So to conclude SRV6 are all about [13:47] simplicity and unification uh for us. So [13:50] we defined the problem of extending [13:54] um the VPN service from the remote point [13:59] of presence where we interconnect with [14:01] our customers all the way to their [14:03] virtual cloud environment across [14:05] multiple domains incorporating [14:08] multi-tenency uh capabilities, traffic [14:10] engineering capabilities. So SRV6 allows [14:13] us uh doing that. It also decreases the [14:16] operational uh burden because now we [14:20] eliminate those uh translation points [14:22] that would require uh operational [14:26] changes from the management perspective [14:28] but also maintaining to separate [14:30] protocols and etc etc and so keeping the [14:35] rest of the network uh simple that's how [14:38] we basically gain the scalability [14:39] because we can can scale out now the [14:41] border routers of the cloud gateways and [14:44] providing multip multiple uh VPNs on top [14:47] of that for our customers. [14:52] I'm also excited to share some sneak [14:54] peek of the work that we are also [14:56] planning to do with that. Uh so [14:58] currently we are basically working on [15:00] our infrastructure enablement and we [15:02] also considering adding SRV6 on the [15:04] other uh network domains like internet [15:06] edge and also DCI. Uh but then regarding [15:11] the service injection as I mentioned [15:14] earlier we started with SR6 unaware [15:17] service mode but since we own the [15:19] firewall and we also develop it we are [15:22] looking forward to add the functionality [15:24] onto the firewall and that what really [15:26] helps us to scale even further because [15:30] we will eliminate the dependency on the [15:32] proxy nodes on those service leaves and [15:36] uh that means that we could start adding [15:39] firewall granularly in any part of [15:42] simple IPv6 enabled infrastructure. that [15:45] would allow us to scale it granularly [15:47] per any application or domain or [15:51] customer or segment. [15:54] And yeah, that also very important to [15:56] mention that we also looking forward to [15:58] develop uh our own traffic engineering [16:01] controller. So to keep the policy [16:03] provisioning dynamic either keeping it [16:05] as a static uh configuration [16:09] and also in the end I would like to [16:12] encourage you to [16:14] walk through the document. This is the [16:16] IETF draft that we came up with uh [16:18] partnering with uh the Cisco team and [16:22] other operators joining uh the effort [16:25] and this not like a new solution that we [16:27] basically invented there. However, it's [16:29] more of a design description on how we [16:33] can interconnect those cloud environment [16:36] with the physical network edge [16:38] incorporating all those VPN and traffic [16:40] engineering capabilities as I mentioned [16:42] earlier because we believe that it kind [16:45] of a good unified solution approach for [16:49] the cloud environments in general. And [16:52] so also in this document we described in [16:54] more details the configuration approach [16:57] all the specifics of the different seats [17:00] and all the nuances. So basically if [17:02] there are some concepts that were [17:04] unclear after my presentation all the [17:06] technical deep details could be found [17:08] with this document. So yeah, and that [17:12] would be also awesome to get some [17:14] feedback from the community and even if [17:17] you would like to join and collaborate [17:19] on that with us as well, that would be [17:21] even better. [17:24] That's it from my side. Thanks a lot for [17:26] your attention and yeah, I'm open to a [17:29] couple of questions.