Nebius Adopts SRv6 to Unify Data Center and WAN Traffic

@Scale

Deploying Segment Routing over IPv6 eliminates protocol translation bottlenecks while delivering scalable traffic engineering and inline security across cloud interconnects.

AI-assisted summary of Building Scalable AI Cloud Interconnects with SRv6 | Alexey Gorovoy, Nebius — original source. Check the original for full context.

Source published: 2026-09-13

Detailed notes

## Background Published on YouTube by @Scale on August 27, 2026, this presentation features Alexey Gorovoy from Nebius explaining how to build scalable AI cloud interconnects using SRv6. According to the page description, the session showcases Nebius' evolving customer cloud interconnect architecture, demonstrating how SRv6 bridges virtual cloud environments and physical network edges to provide end-to-end VPN and Traffic Engineering services without protocol translation.

## TL;DR Alexey Gorovoy details how Nebius evolved its infrastructure to meet exploding, multi-terabit bandwidth demands and dynamic inline security requirements for AI workloads. By replacing traditional hybrid stacks (VXLAN/EVPN in the data center and MPLS-SR in the WAN) with a unified SRv6 uSID architecture, Nebius eliminated complex stitching gateways and VRF terminations on intermediate hardware. The presentation covers their implementation using VPP-based Cloud Gateways, the integration of service-aware firewalls via SR-TE policies, key migration learnings such as RFC 8950 compliance, and future roadmap plans for custom TE controllers and complete legacy protocol replacement.

## Atmosphere & style The session is clear, structured, and deeply technical, carrying the pragmatic tone of a network engineer sharing production-tested architectural solutions. It feels like an engaging white-board style tech talk where complex operational hurdles—such as domain-stitching choke points—are dismantled methodically in favor of elegant engineering design. Gorovoy maintains a focused, authoritative delivery, balancing high-level architectural motivation with precise practical insights.

## Key takeaways - [00:05](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=5s) Nebius is an AI-native cloud provider designed to give AI customers a full-stack environment to train, build, and deploy models on large-scale GPU clusters. - [00:05](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=5s) Traditional interconnect architectures rely on separate protocol stacks across WAN, backbone, and data center domains, creating performance bottlenecks and operational complexity at translation boundaries. - [02:16](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=136s) Customer interconnect requirements shifted from best-effort internet data ingestion to dedicated private links with multi-terabit bandwidth and inline security services. - [05:30](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=330s) Nebius moved away from VXLAN/EVPN and MPLS-SR because VXLAN lacks native Traffic Engineering and MPLS-SR is ill-suited for host-centric data center environments. - [05:30](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=330s) Using separate protocols requires stitching gateways that cause vendor inconsistency, hardware performance hits, and forced VRF terminations. - [05:30](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=330s) SRv6 unifies data center and WAN transport into a single IPv6-based encapsulation, eliminating protocol translation while providing end-to-end Traffic Engineering. - [08:17](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=497s) SRv6 micro-segmentation (uSID) compresses multiple Segment IDs into a single 128-bit IPv6 destination address, keeping header overhead minimal for host software routers. - [08:17](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=497s) Underlay networks remain stateless standard IPv6 routers without needing to maintain customer VRFs or perform translation. - [08:17](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=497s) Nebius transitioned security services from SRv6-unaware firewalls attached via proxy service leaves to SRv6 service-aware firewalls that scale dynamically across the IPv6 network. - [11:59](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=719s) Nebius selected Vector Packet Processing (VPP) for its Cloud Gateway software to achieve high-performance SRv6 packet processing on compute hosts. - [11:59](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=719s) Dual-stack migrations can occur smoothly by enabling IS-IS version 6 with SRv6 extensions alongside existing IPv4/MPLS topologies. - [11:59](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=719s) Advertising BGP VPNv4 routes over an IPv6 next-hop infrastructure requires strict compliance with RFC 8950. - [15:02](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=902s) Future engineering initiatives include expanding SRv6 across DCI/internet edges, building native SRv6 firewalls, and developing an dynamic in-house TE controller.

## Detailed walkthrough ### [00:05](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=5s) Evolving Customer Cloud Interconnect Architecture with SRv6

Alexey Gorovoy, a network engineer at Nebius, introduces his presentation on how the company is evolving its customer cloud interconnect architecture using SRv6 (Segment Routing over IPv6) as a foundational building block. Nebius is an AI-focused cloud provider specializing in high-performance hardware and software development, building large-scale GPU clusters, and operating an AI-native cloud computing platform designed to give AI customers a full-stack environment to train, build, and deploy models.

To set the stage, Alexey frames the broader cloud industry challenge: cloud providers routinely offer private interconnect solutions to link customer premises to virtual cloud environments. These private links require strict tenant isolation, predictable bandwidth, and seamless security integration. In traditional cloud architectures, traffic passing from the customer edge to a virtual machine (VM) must cross disparate network domains—such as the WAN edge, backbone core, data center fabric, and compute host. Because each domain traditionally relies on its own separate protocol stack optimized in isolation, connecting them end-to-end introduces friction, protocol translation points, complex service boundaries, and performance bottlenecks.

- **Speaker:** Alexey Gorovoy, Network Engineer at Nebius. - **Company Core Focus:** Large-scale GPU cluster building, AI-native cloud computing platform development, and full-stack AI infrastructure. - **Core Requirements for Customer Interconnects:** Tenant isolation, guaranteed predictable bandwidth, and integrated network security services. - **Traditional Interconnect Pitfalls:** Domain-specific protocol stacks that require stitching and translation at domain boundaries, creating operational and scale bottlenecks.

---

[02:16](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=136s) Legacy Network Architecture and Its Scaling Limits

Nebius operates a global footprint spanning multiple data center regions across Europe and the United States, tied together via a private backbone alongside independent local internet connections and Points of Presence (PoPs). Originally, customer interconnect demands were relatively modest and localized: customers primarily needed to ingest large datasets into the Nebius cloud during initial onboarding. Because data was ingested locally into a specific region via the public internet and stored for subsequent model training, traffic rarely traversed inter-region backbones.

Under this initial design, Nebius built its frontend and data center infrastructure heavily around IPv6. Compute clusters, storage arrays, and cloud services operated natively on IPv6. The architecture relied on two key in-house software functions built on open-source software: the **Cloud Gateway** (serving as the exit/entry point for customer VMs using a VXLAN/EVPN stack) and an in-house **Firewall**. Across the private WAN backbone, Nebius employed traditional MPLS Segment Routing (MPLS-SR) to deliver Layer 3 VPN services to reach the internet. While this hybrid setup (VXLAN/EVPN in the data center, MPLS-SR in the WAN) worked initially, changing customer requirements exposed major scaling limits:

- **Demand Shift:** Customers moved from best-effort public internet ingestion to requesting dedicated, private, ultra-high-bandwidth interconnect links. - **Exploding Scale:** Bandwidth demands scaled rapidly from tens of gigabits to hundreds of gigabits, reaching multi-terabit requirements in certain customer deployments. - **Integrated Services:** Customers increasingly required inline security services—such as end-to-end encryption and mandatory firewall inspection—embedded directly into the transport path. - **Protocol Boundary Bottlenecks:** Extending high-bandwidth customer VPNs with dynamic Traffic Engineering (TE) from a remote WAN PoP across the backbone into the data center host exposed the VXLAN-to-MPLS stitching point as a severe operational and performance choke point.

---

[05:30](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=330s) Choosing SRv6 over Legacy Protocol Stacks

To build a seamless bridge between virtual cloud environments and physical edge networks, Nebius re-evaluated its end-to-end protocol choices. While VXLAN with EVPN is widely adopted across vendor hardware and open-source tooling, it lacks native Traffic Engineering (TE) capabilities; inserting dynamic service chains (like firewalls) into VXLAN overlays requires inflexible and complex routing workarounds. Conversely, while MPLS-SR offers robust Traffic Engineering across WAN domains, it is ill-suited and rarely deployed natively inside host-based data center environments.

Using two separate protocol stacks requires intermediary "stitching gateways" that translate headers and terminate VRFs between domains. In practice, these translation gateways suffer from inconsistent vendor feature support, severe hardware performance degradation, and massive architectural complexity. SRv6 solves these issues by offering an elegant compromise: it maintains a lightweight "IP-in-IP style" overlay format while delivering powerful, end-to-end Segment Routing Traffic Engineering (SR-TE) capabilities that span seamlessly from physical WAN routers to virtualized compute hosts.

- **VXLAN/EVPN Limitations:** Broad multi-vendor interoperability, but lacks granular native Traffic Engineering, making dynamic service insertion rigid. - **MPLS-SR Limitations:** Excellent WAN traffic steering, but practically inapplicable inside host-centric data center fabrics. - **Stitching Gateway Drawbacks:** Vendor implementation gaps, platform hardware performance hits, high operational complexity, and forced VRF termination on middleboxes. - **The SRv6 Solution:** Unifies data center and WAN transport into a single IPv6-based encapsulation, eliminating stitching points while preserving flexible TE capabilities.

---

[08:17](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=497s) Key Use Cases: SRv6 uSID Overlay and Firewall Insertion

Nebius implemented SRv6 micro-segmentation (**uSID**) to deliver Layer 3 VPN multi-tenancy across its entire fleet. By deploying SRv6 endpoint functionality solely at the domain edges—the Cloud Gateway on the hypervisor side and the Border Router at the physical network edge—both ends act as standard L3VPN Provider Edge (PE) nodes. Underlay networks simply route standard IPv6 locator prefixes without needing to maintain customer VRFs or perform protocol translation. Furthermore, uSID technology compresses multiple Segment IDs into a single 128-bit IPv6 destination address header. By keeping locator allocations clean and capping active segments to six or fewer, Nebius completely avoids inserting additional Segment Routing Headers (SRH), significantly reducing header overhead and optimizing processing performance for host-based software routers.

For security, Nebius initially deployed an **SRv6-unaware firewall service**. In this mode, standard firewalls connect to the data center fabric via dedicated SRv6-enabled "service leaf" proxy nodes. These service leaves advertise Node and Adjacency SIDs that Cloud Gateways and Border Routers reference within SR-TE policies to steer specific customer traffic through the firewall. Moving forward, Nebius is transitioning toward **SRv6 service-aware firewalls**, removing proxy node dependencies so firewall instances can attach anywhere on the IPv6 routed network and scale out dynamically on a per-tenant, per-application, or per-segment basis.

---

[11:59](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=719s) Production Implementation Experience and Migration Lessons

Transitioning to SRv6 provided key practical insights across interoperability, host software selection, and dual-stack migration strategies:

- **Vendor Interoperability:** Testing and production deployments confirmed robust uSID interoperability across diverse hardware switching platforms in the Nebius backbone. - **VPP Host Datapath:** For its Cloud Gateway software, Nebius selected **FD.io VPP (Vector Packet Processing)** as the foundation, allowing flexible, high-performance SRv6 packet processing and custom network programming directly on host servers. - **Dual-Stack Migration Path:** Traditional IPv4/MPLS networks can migrate smoothly with minimal service disruption. Operators can enable IPv6 routing alongside IS-IS version 6 with SRv6 extensions while leaving existing IPv4/MPLS IS-IS topologies intact during transition. - **RFC 8950 Compliance:** When advertising BGP VPNv4 routes over an IPv6 next-hop infrastructure, network equipment must strictly support RFC 8950 (IPv6 Next Hop Address Encoding for BGP-4). - **Locator Address Architecture:** Carefully designing the IPv6 locator block is critical, as the locator layout dictates the available headroom for future Traffic Engineering SIDs inside the uSID container.

---

[15:02](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=902s) Conclusion and Future Roadmap

Alexey concludes by emphasizing that SRv6 successfully eliminates domain boundaries between WAN and data center environments. By concentrating policy at the network edges (Cloud Gateways and Border Routers), intermediate switches remain stateless underlay routers that no longer carry VRF state or execute protocol translation. Complex service insertions—such as mandatory firewall checks—are simplified into clear SR-TE policy definitions applied at the edge.

Looking ahead, Nebius is focusing its engineering roadmap on three main initiatives: 1. **Broader Infrastructure Rollout:** Expanding SRv6 into Data Center Interconnect (DCI) and internet edge domains to completely replace residual VXLAN and legacy MPLS stacks. 2. **Native SRv6 Firewall Development:** Enhancing Nebius' in-house software firewall to natively interpret SRv6 headers, enabling seamless, granular auto-scaling across the compute fabric. 3. **Custom TE Controller:** Developing an in-house dynamic Traffic Engineering controller to program path provisioning and SR policies on demand, replacing static network configurations.

Finally, Alexey highlights a joint **IETF draft** co-authored by Nebius, Cisco, and industry partners, encouraging other cloud operators to review the document as a practical reference architecture for solving modern multi-domain cloud interconnect challenges.

## Notable quotes > [00:05](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=5s) building large-scale GPU clusters, and operating an AI-native cloud computing platform designed to give AI customers a full-stack environment to train, build, and deploy models — Alexey Gorovoy

> [00:05](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=5s) cloud providers routinely offer private interconnect solutions to link customer premises to virtual cloud environments — Alexey Gorovoy

> [00:05](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=5s) Because each domain traditionally relies on its own separate protocol stack optimized in isolation, connecting them end-to-end introduces friction, protocol translation points, complex service boundaries, and performance bottlenecks — Alexey Gorovoy

> [02:16](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=136s) traffic rarely traversed inter-region backbones — Alexey Gorovoy

> [02:16](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=136s) extending high-bandwidth customer VPNs with dynamic Traffic Engineering (TE) from a remote WAN PoP across the backbone into the data center host exposed the VXLAN-to-MPLS stitching point as a severe operational and performance choke point — Alexey Gorovoy

> [05:30](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=330s) inserting dynamic service chains (like firewalls) into VXLAN overlays requires inflexible and complex routing workarounds — Alexey Gorovoy

> [05:30](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=330s) it maintains a lightweight "IP-in-IP style" overlay format while delivering powerful, end-to-end Segment Routing Traffic Engineering (SR-TE) capabilities that span seamlessly from physical WAN routers to virtualized compute hosts — Alexey Gorovoy

> [08:17](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=497s) Underlay networks simply route standard IPv6 locator prefixes without needing to maintain customer VRFs or perform protocol translation — Alexey Gorovoy

> [08:17](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=497s) By keeping locator allocations clean and capping active segments to six or fewer, Nebius completely avoids inserting additional Segment Routing Headers (SRH) — Alexey Gorovoy

> [08:17](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=497s) removing proxy node dependencies so firewall instances can attach anywhere on the IPv6 routed network and scale out dynamically on a per-tenant, per-application, or per-segment basis — Alexey Gorovoy

> [11:59](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=719s) Operators can enable IPv6 routing alongside IS-IS version 6 with SRv6 extensions while leaving existing IPv4/MPLS IS-IS topologies intact during transition — Alexey Gorovoy

> [15:02](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=902s) By concentrating policy at the network edges (Cloud Gateways and Border Routers), intermediate switches remain stateless underlay routers that no longer carry VRF state or execute protocol translation — Alexey Gorovoy

## Mentioned Alexey Gorovoy, Nebius, @Scale, SRv6, IPv6, IPv4, VXLAN, EVPN, MPLS, MPLS-SR, Cloud Gateway, uSID, SR-TE, FD.io VPP, IS-IS, BGP, RFC 8950, Cisco, IETF

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

中文简报

Nebius采用SRv6统一数据中心与广域网流量部署基于IPv6的分段路由（SRv6）消除了协议转换瓶颈，同时在云互联中实现可扩展的流量工程与在线安全能力。 Alexey Gorovoy详细介绍了Nebius如何演进其基础设施，以满足AI工作负载爆炸式增长的多太比特（multi-terabit）带宽需求与动态在线安全要求。通过采用统一的SRv6 uSID架构取代传统的混合协议栈（数据中心使用VXLAN/EVPN，广域网使用MPLS-SR），Nebius消除了中间硬件上复杂的拼接网关和VRF终结。演讲涵盖了他们采用基于VPP的云网关的具体实现、通过SR-TE策略集成业务感知防火墙、遵循RFC 8950等关键迁移经验，以及开发定制TE控制器并彻底替换遗留协议的未来路线图规划。随着客户互联需求从公网数据导入转向具备内联安全检查的多太比特（multi-terabit）专用私有链路，Nebius 早期采用的“数据中心 VXLAN/EVPN + 广域网 MPLS-SR”混合架构遭遇了严重的扩展瓶颈。 (2:16) 为消除跨网络域协议转换网关带来的性能损耗与运维复杂度，Nebius 选用 SRv6 统一数据中心与 WAN 的传输架构，实现跨虚拟计算节点到物理网络边缘的端到端流量工程（SR-TE）。 (5:30) Nebius 落地了 SRv6 uSID（微分段）技术，将多个 Segment ID 压缩至单个 128 位 IPv6 目的地址中以规避额外的 SRH 报头开销，使中间 Underlay 路由器保持无状态且无需维护 VRF。 (8:17) 在生产实践中，Nebius 基于 FD.io VPP 构建了主机端 Cloud Gateway 数据平面，后续将进一步推进原生 SRv6 防火墙扩展与自研动态流量工程控制器的研发。 (11:59)

Reading summary

Alexey Gorovoy of Nebius argues that legacy multi-protocol cloud interconnects fail under multi-terabit AI workloads, and demonstrates how unifying host and WAN networks under an end-to-end SRv6 architecture eliminates protocol translation bottlenecks while preserving granular traffic engineering. Scaling Limits of Hybrid Interconnect Architectures (2:16) Nebius initially handled customer traffic by ingesting datasets over the public internet directly into localized regions, relying on an internal IPv6 fabric alongside host-level Cloud Gateways running VXLAN/EVPN and an MPLS Segment Routing (MPLS-SR) WAN. However, customer requirements shifted dramatically toward dedicated, private interconnects with bandwidth requirements scaling from tens of gigabits to multi-terabit capacities, alongside demands for inline firewalling and encryption. This growth exposed severe architectural limitations at domain boundaries. While VXLAN/EVPN provided multi-vendor data center support, it lacked native Traffic Engineering (TE) for dynamic service routing. Conversely, MPLS-SR offered WAN traffic steering but was impractical to run directly on compute hypervisors. Interconnecting these environments required stitching gateways that terminated Virtual Routing and Forwarding (VRF) instances and translated headers, introducing operational complexity, vendor incompatibilities, and significant hardware throughput penalties. End-to-End Transport Using SRv6 uSID (8:17) To eliminate intermediate stitching gateways, Nebius adopted Segment Routing over IPv6 (SRv6) micro-segmentation (uSID) as a unified transport layer spanning from physical WAN edge routers to host hypervisors. Under this model, host Cloud Gateways and physical Border Routers function as Layer 3 VPN Provider Edge (PE) nodes, while intermediate fabric switches operate strictly as stateless IPv6 underlay routers without maintaining customer VRFs or translation tables. The uSID implementation packs multiple segment identifiers into a single 128-bit IPv6 destination address container. Gorovoy notes that by structuring locator allocations cleanly and capping active path segments to six or fewer, Nebius transmits routed traffic without appending an extra Segment Routing Header (SRH). This header compression minimizes packet overhead and reduces processing burdens on host-based software routers. Inline Security Chaining via SR-TE (8:17) Embedding security services directly into network paths presented another challenge for legacy overlays. Nebius initially integrated an SRv6-unaware firewall service by attaching firewall appliances to the fabric via dedicated service leaf proxy nodes. These proxies advertise Node and Adjacency SIDs, allowing Cloud Gateways and Border Routers to steer tenant traffic through inspection points using SR-TE policy paths. To eliminate the hardware proxy bottleneck, Nebius is shifting toward SRv6 service-aware firewalls. In this target architecture, firewall instances interpret SRv6 headers natively and attach anywhere across the standard IPv6 routed fabric, enabling granular, dynamic scaling on a per-tenant, per-application, or per-segment basis without requiring dedicated physical redirection nodes. Host Datapaths and Protocol Migration Prerequisites (11:59) Deploying SRv6 into production highlighted critical software and protocol prerequisites. On compute hosts, Nebius implemented its Cloud Gateway data path using FD.io Vector Packet Processing (VPP), which provided the software routing performance and programmability necessary to process SRv6 encapsulations directly on server hardware. For the migration strategy, Gorovoy explains that operators can transition from IPv4/MPLS backbones with minimal downtime by enabling dual-stack routing with IS-IS version 6 SRv6 extensions alongside existing topologies. Crucially, backbone equipment must support RFC 8950 to advertise BGP VPNv4 routes across IPv6 next-hop infrastructure. Additionally, network teams must carefully design their IPv6 locator blocks in advance, as locator allocation structures establish the maximum headroom available for future traffic engineering segments inside the uSID container. Gorovoy concludes that SRv6 successfully flattens network domain barriers and simplifies intermediate fabric state, but notes ongoing work remains: Nebius is currently expanding SRv6 to its Data Center Interconnect and internet edges, developing native SRv6 software firewalls, deploying an in-house dynamic TE controller, and promoting a multi-operator reference architecture via a joint IETF draft co-authored with Cisco.

精炼阅读摘要

Nebius网络工程师Alexey Gorovoy指出，随着人工智能客户对互联带宽的需求从数十吉比特（Gbps）暴增至多太比特（Tbps），传统在数据中心与广域网之间采用多协议拼接的架构已面临严重的扩展性与运维瓶颈。为此，Nebius引入基于IPv6的段路由（SRv6）作为统一传输基础，消除了跨网络域的协议转换，实现了端到端的流量工程与微租户隔离。 AI高带宽需求引发的传统架构瓶颈 (2:16) Alexey介绍，Nebius是一家专注于AI的云服务商，其基础设施分布于欧洲和美国的多个数据中心，早期主要依赖本地公网将大规模数据集导入特定区域用于模型训练，跨区域骨干网流量有限。当时的数据中心内部基于原生IPv6构建，计算节点出入口依赖开源软件开发的云网关（采用VXLAN/EVPN技术栈）和自研防火墙，而广域网私有骨干网则运行传统MPLS-SR来提供三层虚拟专用网（L3VPN）服务。随着客户从公网导入转向要求低延迟、高隔离的专用高带宽私网互联，业务流量迅速由数十Gbps跃升至数百Gbps乃至多太比特级别，并要求直接在传输路径中嵌入端到端加密与强制防火墙检查等内联安全服务。在这种场景下，将带有动态流量工程（TE）的客户VPN从远端广域网接入点（PoP）经骨干网延伸至数据中心计算节点时，VXLAN与MPLS之间的边界协议转换网关暴露为严重的性能与运维瓶颈。选择SRv6统一端到端传输层 (5:30) 为了连接虚拟云环境与物理边缘网络，Nebius重新评估了底层协议架构。Alexey分析指出，虽然数据中心广泛采用的VXLAN/EVPN具备良好的多厂商兼容性，但其缺乏原生的流量工程能力，插入动态服务链（如防火墙）时需借助僵硬且复杂的路由迂回机制；而MPLS-SR虽然在广域网中具备出色的流量调度能力，却难以原生部署于以计算节点为核心的主机数据中心网络中。两套独立协议共存迫使网络部署中介“拼接网关”来执行报头翻译并终结VRF。在实际运行中，不同网络设备厂商在拼接特性上的支持参差不齐，且报文转换会导致严重的硬件转发性能下降。SRv6通过提供轻量级“IP-in-IP”样式的封装，统一了数据中心与广域网的传输协议，不仅消除了中间转换网关，还实现了从广域网物理路由器直达虚拟化计算主机的端到端段路由流量工程（SR-TE）。 uSID压缩与服务链防火墙编排 (8:17) Nebius采用了SRv6微段（uSID）技术在全网提供三层VPN多租户支持。该架构将SRv6端点功能严格限制在网络边缘——即管理程序侧的云网关与物理网络边缘的边界路由器，两者共同充当标准的L3VPN提供商边缘（PE）节点。中间的底层承载网络仅需依据标准IPv6定位器（Locator）前缀进行无状态路由转发，无需维护任何客户VRF或执行协议转换。通过uSID技术，多个段标识符（SID）被压缩进单个128位的IPv6目的地址报头中；Nebius将活跃段数量控制在6个以内，彻底避免了额外插入段路由报头（SRH），显著降低了报头开销并优化了软件路由器的处理性能。在网络安全服务集成方面，Nebius最初采用“非SRv6感知型”防火墙方案，即通过具备SRv6能力的专用服务叶子节点作为代理连接防火墙，并在SR-TE策略中引用节点与邻接SID引导流量经过检查。目前，Nebius正转向“SRv6服务感知型”防火墙体系，摆脱对代理叶子节点的依赖，使防火墙实例能够灵活接入IPv6网络的任意位置，并按租户、应用或网段实现细粒度的动态水平扩展。生产部署实践与平滑迁移经验 (11:59) 在SRv6的实际生产落地过程中，Nebius积累了多项关键工程经验。首先，骨干网多厂商硬件交换平台的多样化测试与上线证明了uSID技术的互操作性。在主机侧，Nebius选用开源FD.io VPP（矢量数据包处理）作为云网关的数据平面基石，依托其灵活性与高性能在服务器主机上直接执行SRv6报文处理与自定义网络编排。对于存量网络的迁移，Nebius验证了在不中断服务的情况下进行双栈平滑过渡的可行性：运维团队在保留既有IPv4/MPLS IS-IS拓扑的同时，并行启用支持SRv6扩展的IPv6 IS-IS路由。此外，Alexey强调网络设备必须严格支持RFC 8950标准，以实现通过IPv6下一跳通告BGP VPNv4路由；同时必须在规划阶段审慎设计IPv6定位器地址块结构，以确保为未来uSID容器内部的流量工程预留充足的编码余量。 Alexey总结指出，SRv6通过将复杂的网络策略收敛至边缘节点，使中间网络还原为无状态底层，大幅降低了跨域互联与服务链插入的复杂度。Nebius后续的工程演进重点包括：将SRv6全面推广至数据中心互联（DCI）与互联网边缘以彻底替换传统协议栈、开发能够原生解析SRv6报头的自研软件防火墙，以及构建自研动态流量工程控制器取代静态配置。此外，Nebius与Cisco等合作伙伴联合发布了相关IETF草案，以期为行业提供多域云互联的参考架构。

Detailed notes — zh

## Background 该视频由 @Scale 频道于 2026 年 9 月 3 日发布在 YouTube 平台，主讲人为来自新兴云厂商 Nebius 的网络工程师 Alexey Gorovoy。页面介绍表明，本次分享聚焦于 Nebius 不断演进的客户云互联架构，展示其如何以 SRv6 作为核心基石打通虚拟云环境与物理网络边缘，从而在无需跨域协议转换的前提下实现端到端 VPN 与流量工程服务。 ## TL;DR 演讲深入剖析了 Nebius 在承载超大规模 AI 计算需求时，传统“数据中心 VXLAN + 骨干网 MPLS-SR”双域协议拼接架构带来的性能与运维瓶颈。为此，Nebius 创新性地采用 SRv6 Micro-SID（uSID）构建统一互联底座，将策略集中于边缘的自研 VPP 云网关与边界路由器，使中间承载网彻底蜕变为无状态的纯 IPv6 转发核心。内容详尽阐释了端到端 L3VPN、非感知与原生 SRv6 防火墙服务链的高效编排，并分享了兼顾多厂商互通与双栈平滑迁移的关键工程实践。未来，Nebius 将继续推进全域去 VXLAN/MPLS 化、自研动态 TE 控制器，并协同 IETF 共同推广此跨域极简互联范式。 ## Atmosphere & style 整场演讲呈现出极为严谨、硬核且务实的一线工程复盘基调。主讲人 Alexey 的讲解逻辑缜密、节奏紧凑，没有空泛的概念包装，而是直面真实生产环境中的架构痛点、厂商兼容瓶颈与暗坑细节。观看过程宛如旁听一场高水准的大厂内部网络架构攻坚复盘，既洋溢着技术极客抽丝剥茧的纯粹探索，又透露出面向 AI 规模化浪潮重塑基础设施底座的深厚工程自信。 ## Bulletin - [00:05](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=5s) Nebius 重构其 AI 云互联架构，全面采用 SRv6 作为端到端统一底座，彻底替代传统跨 WAN 与 DC 的 MPLS-SR 与 VXLAN 拼接网关方案。 - [08:17](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=497s) 借助 SRv6 Micro-SID（uSID）技术，Nebius 将多段路由指令压缩进单个 128 位 IPv6 目的地址，免除额外分段路由头（SRH）开销，显著优化软件网关性能。 - [12:06](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=726s) 主机侧云网关采用开源 FD.io VPP 自研构建，实现高度灵活的 SRv6 SID 编程能力，并在生产环境中成功验证了多硬件厂商的高水平互操作性。 - [16:08](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=968s) Nebius 联合 Cisco 等产业伙伴推进 IETF 架构草案，未来计划在全网范围彻底淘汰 VXLAN 与传统 MPLS，并上线自研动态流量工程控制器。 ## Key takeaways - [02:16](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=136s) AI 大模型训练与推理对云互联提出新要求，需要数百 Gbps 至 Tbps 级别的确定性带宽、强租户隔离与端到端内置安全能力。 - [05:30](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=330s) 传统的“数据中心内部 VXLAN EVPN + 骨干网 MPLS-SR”双域割裂架构，因拼接网关的协议转换和 VRF 终结而沦为性能与运维的严重瓶颈。 - [05:30](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=330s) SRv6 兼具纯净 IP-in-IP 叠加封装与原生流量工程（TE）调度能力，成为打通虚拟化云环境与物理网络边缘的理想统一技术底座。 - [08:17](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=497s) 端到端 L3VPN 方案仅在网络边缘节点（物理 Border 路由器与自研 Cloud Gateway）终结 SRv6，中间物理网络退化为无状态的纯 IPv6 路由承载网。 - [08:17](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=497s) SRv6 Micro-SID（uSID）将转发段紧凑压入单一 IPv6 目的地址，避免插入 SRH 带来的报头膨胀，降低了基于 CPU 运转的虚拟化网关的计算与内存负载。 - [10:12](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=612s) 在 SRv6 非感知模式下，利用连接防火墙集群的 SRv6 Service Leaf 交换机充当代理节点，通过 SR-TE 策略实现传统四层/七层防火墙的动态服务链编排。 - [11:29](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=689s) 演进至原生 SRv6 感知型防火墙后，可彻底移除专用代理节点，防火墙实例可挂载至任意纯 IPv6 网络，实现按租户、分段或微服务颗粒度的弹性水平扩展。 - [12:06](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=726s) 从存量 IPv4/MPLS 迁移采用双栈平滑推进法：底层开启 IPv6 路由，控制面部署 IS-ISv6 与原有 IS-IS 并存，在不中断现网业务的前提下渐进切换流量。 - [13:43](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=823s) 工程落地需严格遵循 RFC 8950 标准以正确传递 IPv6 下一跳的 VPNv4 路由，并跨域保全 SRv6 Locator 属性与规划好 SID 容器地址空间。 - [15:02](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=902s) SRv6 架构哲学强调策略集中于网络边缘（Edge-driven Policy），使中间传输核心彻底无状态化，消除了跨域缝合与多厂商绑定的复杂度。 - [16:08](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=968s) Nebius 后续演进将推广 SRv6 至 DCI 与互联网边缘以全面淘汰 VXLAN/MPLS，并构建自研集中式控制器实现全自动、实时的动态流量工程调度。 ## Detailed walkthrough ### [00:05](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=5s) Nebius 与云互联面临的多域网络挑战演讲者 Alexey Gorovoy 作为 Nebius 的网络工程师，开场便表达了在大会分享的荣幸，并切入核心议题：Nebius 如何重塑其客户云互联（Customer Cloud Interconnect）架构，以及为何将 SRv6（Segment Routing over IPv6）选作底层基石技术。为了提供背景信息，Alexey 首先介绍了 Nebius 这家在软硬件领域拥有深厚技术积累的新兴云厂商。Nebius 专注于构建大规模 GPU 集群以及自研的 AI 原生云计算平台，向 AI 领域客户提供从底层基础设施到上层模型构建、训练及推理运行的全栈技术服务，力求让客户在统一的平台上完成所有工作。随后，Alexey 将视角扩展到整个云计算行业的通用背景。绝大多数公有云提供商都会提供某种形态的云互联解决方案，其实质是从客户本地机房（Customer Premises）延伸至云服务商网络的专用私网连接。此类业务具备三大核心基本需求：严格的租户隔离（Tenant Isolation）、可预测的确定性带宽（Predictable Bandwidth）以及内置的端到端安全性（Integrated Security）。然而，流量从互联接入点到达客户在云内的虚拟环境，往往必须跨越多个异构网络域，包括网络边缘（Edge）、核心骨干（Core WAN）、数据中心矩阵（DC Fabric），最终抵达物理云主机。传统上，每一个网络域都是基于各自最适配的技术栈独立建设的。Alexey 指出，这些技术在其各自的单一域内运行良好，"单独来看并无任何不妥"，但当需要进行端到端无缝集成时，问题就接踵而至了。不同域之间形成了清晰的业务边界与协议转换点，演变为运维复杂度和系统吞吐功能的致命瓶颈。这也正是 Nebius 着手重构架构所要消除的制约因素。 - **Nebius 业务定位**：专注超大规模 GPU 集群与 AI 原生云平台的软硬件全栈研发。 - **云互联核心诉求**：多租户隔离、低抖动与高吞吐的确定性带宽、全路径网络安全策略。 - **多域架构痛点**：Edge、WAN Core 与 DC Fabric 之间协议割裂，协议翻译网关带来运维与性能双重瓶颈。 ### [02:16](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=136s) 初始网络架构与 AI 工作负载下的扩展极限 Nebius 目前在欧洲与美国运营着多座数据中心，各区域之间通过自建的私有骨干网互联，同时各站点也能直接或通过邻近的电信 PoP 点独立接入公共互联网。在业务开展初期，客户互联的主要需求非常简单：仅仅是将海量数据集从客户本地搬迁至 Nebius 云端对象存储，供后续的模型训练使用。当时这些数据迁移均通过公网互联网传输，流量在特定区域内本地消化，从不横跨跨区域骨干网。这种模式在早期运转良好，因为超大规模的数据传输通常只发生在客户刚入驻（Onboarding）的阶段，这也直接决定了 Nebius 前端网络的初始设计。 Nebius 是 IPv6 网络协议的坚定拥护者与早期践行者。不仅数据中心内部的 Fabric 交换矩阵完全运行在 IPv6 之上，计算集群、存储系统以及外围各类基础服务也均基于原生 IPv6 构建。在其基础设施中，有两个关键组件在此次重构中扮演核心角色：云网关（Cloud Gateway）与防火墙（Firewall）。两者皆为 Nebius 团队基于开源组件自主研发的纯软件功能组件。其中 Cloud Gateway 的主要职责是充当客户虚拟机（VM）流向外部世界的出口。在此前的网络设计中，Nebius 在数据中心内部采用 VXLAN EVPN 协议栈，在私有广域骨干网则部署 MPLS-SR（Segment Routing over MPLS），并在二者之上构建跨广域网与数据中心的 L3VPN 业务，以保障虚拟机能安全可靠地访问公网。然而，随着 AI 业务的爆发，这种以区域为中心且依赖公网的连接模型迅速遭遇了瓶颈。首先，客户不再接受 Best-effort（尽力而为）的公网传输，强烈要求获得专属且带宽绝对可预测的专线互联；其次，业务请求的专线容量呈现指数级跃升，直接跨入数百 Gbps 级别，甚至在部分场景下高达数个 Tbps；第三，端到端加密（End-to-End Encryption）与可选的防火墙深度检测（Firewall Inspection）等高级安全能力，被强制要求内置进互联网络服务之中。面对从远端 PoP 点跨越骨干网、穿透数据中心 Fabric 并直达 Cloud Gateway 和计算主机的海量流量，原先在两套完全不同的协议栈（DC 内的 VXLAN 与 WAN 的 MPLS-SR）之间进行桥接的做法，使协议拼接网关迅速变成了吞吐能力与网络运维的灾难性瓶颈。 ```mermaid flowchart LR accTitle: Nebius 传统双协议栈拼接痛点 accDescr: 展示流量从远端 PoP 点跨越 MPLS 广域网进入 VXLAN 数据中心时面临的协议拼接网关瓶颈。 subgraph WAN ["WAN 广域网域 (MPLS-SR)"] POP["远端 PoP 边缘节点"] BB["骨干路由器 (Backbone)"] POP --> BB end subgraph Stitching ["协议拼接网关 (瓶颈点)"] GW["Stitching Gateway (MPLS-SR ↔ VXLAN EVPN 转换 VRF 终结 / 硬件性能受限)"] end subgraph DC ["数据中心域 (IPv6 Fabric + VXLAN)"] CGW["自研 Cloud Gateway"] VM["客户虚拟机 / GPU 计算节点"] CGW --> VM end BB --> GW GW --> CGW ``` ### [05:30](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=330s) 架构求变：为何将 SRv6 作为统一技术底座为了彻底重构骨干网与边缘的演进方向，Nebius 推出了全新的“客户云互联解决方案”（Customer Cloud Interconnect Solution）。这项方案不仅是一个新增的网络连接产品，更是一套重新定义了云平台与物理网络分界线的全新网络架构，核心目标是在虚拟化云环境与物理网络边缘之间构筑一条高性能桥梁。为此，新架构必须同时具备跨越数据中心与广域网的多租户延展能力，并全面集成流量工程（Traffic Engineering, TE）机制，以支持灵活高效的服务链编排（Service Chaining）与带宽管理。在技术选型评估中，团队深入复盘了现有的两套协议栈。VXLAN EVPN 固然拥有无可比拟的生态优势，被各大芯片交换机厂商与开源社区广泛支持，极易集成于各类异构环境；但其致命弱点在于原生缺乏流量工程能力，如果要在数据中心内将流量动态、细粒度地牵引至防火墙等中间件服务，往往需要设计极其繁琐且僵化的路由策略。反观广域网使用的 MPLS-SR，虽然流量工程功能十分强大，却几乎无法无缝下沉并应用到以太/IPv6 占主导的数据中心 Fabric 内部。如果继续维持这种“数据中心 VXLAN + 骨干网 MPLS-SR”的双域割裂架构，就必须引入专用的拼接网关（Stitching Gateway）。 Alexey 详细剖析了拼接网关带来的三大不可承受之重： - **厂商兼容性缺失**：异构厂商设备的实现差异可能导致特定的跨协议拼接功能根本不受支持； - **硬件芯片吞吐降级**：协议头部剥离再封装以及跨域转换逻辑极大侵蚀线速转发性能，导致设备性能断崖式下跌； - **系统架构复杂度激增**：中间设备必须强行终结所有客户的 VRF，并在控制面与数据面进行深度的协议映射，极大地增加了网络的脆弱性。正是基于这些痛点，Nebius 最终选定了 SRv6。Alexey 强调，SRv6 汲取了两套体系的精髓：“它兼取了两家之长”，既保持了纯净、轻量的 IP-in-IP 叠加层封装形态，又在网络内部原生嵌入了极其强大的流量工程调度能力，让端到端统一协议栈成为可能。 ### [08:17](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=497s) 核心场景一：基于 SRv6 Micro-SID 的端到端 L3VPN 架构在新架构下的首个核心落地场景，是基于 SRv6 Micro-SID（uSID）构建的跨域 L3VPN 叠加网络。由于 Nebius 既有的物理网络底座本身就运行着纯 IPv6 路由体系，因此方案的实施路径异常清晰而优雅：仅需在网络的最边缘节点开启 SRv6 功能。这些边缘终结节点分别是云侧的自研 Cloud Gateway，以及物理网络边缘侧的 Internet Border（互联网边界路由器）。通过将 Cloud Gateway 与 Internet Border 直接作为 L3VPN 的 Provider Edge（PE）节点，Nebius 彻底剔除了架构中间所有繁重的协议翻译网关与 VRF 终结过程。底层的整个数据中心与骨干网物理网络，退化为仅负责底座连通性的纯净 IPv6 路由网络，只需提供 IPv6 Locator 前缀的端到端可达性即可。 ```mermaid flowchart LR accTitle: 基于 SRv6 uSID 的端到端 L3VPN accDescr: 展示流量仅在边缘的 Cloud Gateway 和 Border Router 终结 SRv6，中间承载网仅做纯 IPv6 转发。 subgraph EdgePhysical ["物理网络边缘"] Border["Internet Border 路由器 (SRv6 PE 节点)"] end subgraph Underlay ["纯净底座网络 (IPv6 Routed Underlay)"] WAN["骨干路由器 (P Nodes) 仅按 IPv6 Locator 转发"] Spine["DC Spine / Leaf 无状态无感知纯 IPv6 转发"] WAN --- Spine end subgraph EdgeCloud ["云内软件边缘"] CGW["自研 Cloud Gateway (SRv6 PE 节点)"] Host["GPU 训练宿主机 / VM"] CGW --- Host end Border <===> WAN Spine <===> CGW ``` 在此基础上，Alexey 特别赞扬了 Micro-SID（uSID）技术的精妙之处。传统的 SRv6 或 MPLS 往往需要额外的协议报头来携带长长的标签栈或 VNI，而 uSID 巧妙地将多个 Segment ID 紧凑地压缩压入单个 IPv6 目的地址（Destination Address, DA）字段中。这意味着在大多数网络拓扑下，完全不需要插入额外的分段路由头（Segment Routing Header, SRH）。Alexey 解释道，只要团队做好 IP 地址规划，将路径中的段数量控制在 6 个以内，单个 128 位 IPv6 目的地址就完全足以容纳所有转发指令，这在绝大多数工程实践中都绰绰有余。这一特性彻底规避了引入 SRH 带来的巨大数据包开销，对于依赖主机 CPU 运转的虚拟化软件路由器（如 Cloud Gateway）而言，显著释放了数据包处理的计算性能与内存带宽。 ### [10:12](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=612s) 核心场景二：SRv6 非感知模式下的动态防火墙服务链编排架构演进的第二个关键场景，是将防火墙深度安全检测动态串接至客户的云互联路径中。在当前落地的初级阶段，Nebius 采用了“SRv6 非感知服务模式”（SRv6 Unaware Service Mode）。在此模式下，防火墙设备本身无需支持任何 SRv6 协议栈，它依然以传统的四层/七层流量检测设备形态运行，只负责标准的报文检查。为了实现将特定客户流量精准引流（Traffic Steering）至非感知防火墙并完成服务链编排（Service Chaining），Nebius 引入了代理节点（Proxy Nodes）。在具体拓扑中，这一角色由连接防火墙集群的专用 SRv6 Service Leaf 交换机承担。这些 Service Leaf 节点本身全面使能了 SRv6，并在控制面通告对应的 Node SID（节点段标识符）与 Adjacency SID（邻接段标识符），使其能够作为显式路径的一部分被后续的流量工程策略引用。整个服务链的端到端调度过程，完全依赖在网络边缘节点（即 Cloud Gateway 与 Border Router）上动态下发的 SR-TE（SRv6 Traffic Engineering）策略。当带有特定安全需求的流量进入边缘时，PE 节点根据预设策略，压入包含 Service Leaf 与防火墙邻接的 uSID 序列；流量在途经数据中心底座到达 Service Leaf 后，由该代理节点剥离外部 SRv6 封装，以原生格式转交给防火墙进行安全检查；检查通过后，再由代理节点重新封装并沿既定路径转发给终点。借由这一机制，Nebius 成功在不改造传统安全设备的前提下，基于 SR-TE 构建了高度灵活、可随需编排的端到端服务链体系，并以此为跳板迈向下一阶段的目标架构。 ### [11:29](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=689s) 迈向原生 SRv6 防火墙：消除专用代理并实现精细化扩容在探讨网络安全与服务编排时，演讲者指出当前演进的关键一步是构建“原生支持 SRv6 的服务感知型防火墙”（SRv6 Service-Aware Firewall）。过去，在网络中插入安全检测服务往往极度依赖专用的代理节点（Dedicated Proxy Nodes）来进行引流和报文解包封装，这不仅拖慢了转发效率，还成了网络横向扩展的严重瓶颈。而借助 SRv6 的内生能力，团队彻底移除了对专用代理节点的依赖，防火墙实例可以直接挂载到云基础设施中任何普通的纯 IPv6 路由网络上。这种解耦为云上网络带来了前所未有的弹性。安全团队不再需要针对特定机架或特定拓扑定制复杂的旁路布线，而是能够按业务分段（Segment）、特定租户（Customer）乃至单个特定微服务或应用，以极高颗粒度对防火墙资源进行水平弹性扩展（Scale-out）。网络中间层只需将带有特定 SRv6 SID 的报文路由至防火墙服务节点，即可在无缝转发的同时完成端到端安全策略的实施。 ### [12:06](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=726s) 生产落地经验：多厂商互通、VPP 云网关与低风险双栈迁移演讲者进一步分享了 Nebius 在真实生产环境中落地 SRv6 的一手工程经验。随着 SRv6 微指令（Micro-SID / uSID）逐渐完成标准化，该技术生态已日臻成熟。在经历了大量的前期测试、概念验证（PoC）以及与不同网络设备主流厂商的深度评估后，团队在生产部署中成功验证了“跨多硬件厂商平台的高水平互操作性”，彻底打破了过去私有技术容易导致的厂商绑定困境。而在主机侧的客户云网关（Customer Cloud Gateway）选型上，团队评估了多种开源组件，最终选定 FD.io VPP（Vector Packet Processing）作为核心底座，打造了自研的高性能云网关，借助 VPP 在主机端获得了极其灵活的 SRv6 SID 编程能力。针对许多仍然运行在传统 IPv4 / MPLS 网络基础之上的团队，演讲者专门分享了最具借鉴意义的平滑迁移策略。迁移的核心在于“双栈（Dual-Stack）推进法”，该方案对现有运行中的业务影响极低： - **无侵入启用 IPv6 路由**：底层物理拓扑保持不动，仅在现有设备上开启 IPv6 双栈路由支持； - **协议平滑拓展**：在路由协议层面，部署集成 SRv6 扩展的 IS-ISv6，与现网承载 SR-MPLS 的原有 IS-IS IPv4 拓扑并存互不干扰； - **业务渐进切换**：新老控制平面共存，使得团队可以在不中断存量 IPv4 流量的前提下，将新业务和互联流量逐步导入 SRv6 管道。 ```mermaid flowchart LR accTitle: SRv6 端到端云互联与服务链架构 accDescr: 展示了从客户 VPC 通过 VPP 边缘网关、经由纯 IPv6 传输核心直达原生防火墙与远程数据中心的流程。 subgraph DC_Edge["数据中心边缘 (DC Edge)"] VPC["租户虚拟机 / 容器"] VPP_GW["自研 VPP 云网关\n(SRv6 uSID 封装)"] end subgraph Transit_Core["传输核心 (Transit Core)"] Core_Rtrs["无状态 IPv6 路由核心\n(无需维护 VRF / 协议转换)"] end subgraph Service_WAN["服务链与跨域连接 (WAN / Service)"] FW["原生 SRv6 防火墙\n(动态服务插入)"] Remote_DC["远端数据中心 / 专线边界\n(RFC 8950 VPNv4 终结)"] end VPC --> VPP_GW VPP_GW --> Core_Rtrs Core_Rtrs --> FW FW --> Core_Rtrs Core_Rtrs --> Remote_DC ``` ### [13:43](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=823s) 关键工程考量：RFC 8950 规范、跨域 Locator 互通与地址空间规划尽管技术路线清晰，演讲者还是坦诚指出了几个在实际落地中必须踩准的“暗坑”与关键工程要点： - **严格遵循 RFC 8950 规范**：由于互联场景需要在 IPv6 基础设施上承载并传递带有 IPv6 下一跳（IPv6 Next-Hop）的 VPNv4 路由，所选厂商的固件和系统实现必须严格符合 RFC 8950 标准，否则跨协议族的路由下发和报文封装会出现隐蔽的解析失败。 - **跨域 SRv6 Locator 路由保全**：架构横跨“数据中心（DC）”与“广域网（WAN）”两大管理域。在两个域之间分发 SRv6 Locator 地址段时，必须保持其 Locator 的属性和可达性完整无损，只有这样才能建立端到端的 BGP EVPN/VPN 会话并正确解析下一跳路由。 - **前瞻性的 Locator 地址空间设计**：演讲者特别告诫，“Locator 的地址空间规划至关重要”。IPv6 目的地址本身充当了“SID 容器”（SID Container），其前缀长度与编址结构直接决定了未来在单个地址容器内为流量工程（Traffic Engineering）和微指令留出的堆叠空间与扩展上限。总结这段探索，演讲者感慨道，实际测试证明 SRv6 特性已经完全成熟，架构设计具有高度的多厂商互通性，并且存在一条已经被充分验证、切实可行的平滑演进路径。 ### [15:02](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=902s) 架构哲学与运维简化：边缘策略集中与解耦中间传输在对整个方案进行升华总结时，演讲者带领大家回顾了最初面临的挑战：一个横跨多个技术域的云互联难题。架构设计自始至终的核心目标，是在不把各个网络域之间的边界搞得异常复杂的前提下，端到端地保留多租户隔离、带宽控制和服务链插入能力。而 SRv6 正是通过“通用的 IPv6 服务模型”和“策略完全集中于网络边缘（Edge-driven Policy）”交出了一份优异的答卷。这一模式带来了革命性的运维简化： - **中间传输网络彻底无状态化**：沿途的中继路由设备不再需要做繁琐的协议转换，也不再需要维护跨域的复杂 VRF 缝合（VRF Stitching）； - **服务链动态敏捷变更**：当需要插入诸如防火墙之类的安全服务时，网络管理员或编排系统只需要在域边缘节点更新 SR 转发策略即可，中间网络对此完全不感知； - **解耦消除技术域依赖**：中间核心网络的极简设计，赋予了基础设施团队摆脱厂商和技术域绑定、自由扩展网络吞吐的大规模扩展自由。 ### [16:08](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=968s) 未来路线图：全域去 VXLAN/MPLS、自研控制器与 IETF 协同展望未来，Nebius 的网络演进正全力聚焦于两大前沿阵地： - **更广阔的基础设施全域覆盖**：团队正着手在数据中心互联（DCI）和互联网边界（Internet Edge）等更多域全面上线 SRv6，最终目标是“彻底取代对 VXLAN 和传统 MPLS 服务协议栈的依赖”，实现全网数据面协议体系的大一统。 - **服务生态内生演进**：紧接着防火墙服务链的规划，Nebius 正在将自身内部纯自研的防火墙产品彻底改造为原生 SRv6 防火墙，以期在未来获得极致细粒度的弹性伸缩能力。 - **自研动态流量工程控制器**：研发团队正全力构建一套自研的集中式控制器，用于流量工程（TE）和路径动态编排，推动网络策略从目前的半静态配置迈向全自动化、实时的动态流量调度。在演讲尾声，演讲者热情地呼吁同行关注 Nebius 联合 Cisco 及其他行业客户共同起草的 IETF 架构草案。他坚信，这套基于 SRv6 打造的跨域端到端极简互联架构，绝非单一公司的个例尝试，而是为当今广大云服务商和 AI 基础设施构建者解决了一类非常普遍且棘手的通用难题。 ## Notable quotes > [00:05](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=5s) 单独来看并无任何不妥 — Alexey Gorovoy > [05:30](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=330s) 它兼取了两家之长 — Alexey Gorovoy > [11:29](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=689s) 原生支持 SRv6 的服务感知型防火墙 — Alexey Gorovoy > [12:06](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=726s) 跨多硬件厂商平台的高水平互操作性 — Alexey Gorovoy > [13:43](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=823s) Locator 的地址空间规划至关重要 — Alexey Gorovoy > [15:02](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=902s) 通用的 IPv6 服务模型 — Alexey Gorovoy > [15:02](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=902s) 策略完全集中于网络边缘（Edge-driven Policy） — Alexey Gorovoy > [16:08](https://www.youtube.com/watch?v=nX4asnbuVPQ&t=968s) 彻底取代对 VXLAN 和传统 MPLS 服务协议栈的依赖 — Alexey Gorovoy ## Mentioned Alexey Gorovoy, Nebius, @Scale, SRv6, Micro-SID (uSID), Segment Routing Header (SRH), VXLAN EVPN, MPLS-SR, L3VPN, Cloud Gateway, FD.io VPP, RFC 8950, IS-ISv6, BGP EVPN, Cisco, IETF ## Video description 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. Watch to learn 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 the @Scale series here: https://atscaleconference.com/ [Source](https://www.youtube.com/watch?v=nX4asnbuVPQ)

Source quotes

[0:05] Alexey Gorovoy: 单独来看并无任何不妥 [5:30] Alexey Gorovoy: 它兼取了两家之长 [11:29] Alexey Gorovoy: 原生支持 SRv6 的服务感知型防火墙 [12:06] Alexey Gorovoy: 跨多硬件厂商平台的高水平互操作性 [13:43] Alexey Gorovoy: Locator 的地址空间规划至关重要 [15:02] Alexey Gorovoy: 通用的 IPv6 服务模型 [15:02] Alexey Gorovoy: 策略完全集中于网络边缘（Edge-driven Policy） [16:08] Alexey Gorovoy: 彻底取代对 VXLAN 和传统 MPLS 服务协议栈的依赖

Source quotes

[0:05] Alexey Gorovoy: building large-scale GPU clusters, and operating an AI-native cloud computing platform designed to give AI customers a full-stack environment to train, build, and deploy models [0:05] Alexey Gorovoy: cloud providers routinely offer private interconnect solutions to link customer premises to virtual cloud environments [0:05] Alexey Gorovoy: Because each domain traditionally relies on its own separate protocol stack optimized in isolation, connecting them end-to-end introduces friction, protocol translation points, complex service boundaries, and performance bottlenecks [2:16] Alexey Gorovoy: traffic rarely traversed inter-region backbones [2:16] Alexey Gorovoy: extending high-bandwidth customer VPNs with dynamic Traffic Engineering (TE) from a remote WAN PoP across the backbone into the data center host exposed the VXLAN-to-MPLS stitching point as a severe operational and performance choke point [5:30] Alexey Gorovoy: inserting dynamic service chains (like firewalls) into VXLAN overlays requires inflexible and complex routing workarounds [5:30] Alexey Gorovoy: it maintains a lightweight "IP-in-IP style" overlay format while delivering powerful, end-to-end Segment Routing Traffic Engineering (SR-TE) capabilities that span seamlessly from physical WAN routers to virtualized compute hosts [8:17] Alexey Gorovoy: Underlay networks simply route standard IPv6 locator prefixes without needing to maintain customer VRFs or perform protocol translation [8:17] Alexey Gorovoy: By keeping locator allocations clean and capping active segments to six or fewer, Nebius completely avoids inserting additional Segment Routing Headers (SRH) [8:17] Alexey Gorovoy: removing proxy node dependencies so firewall instances can attach anywhere on the IPv6 routed network and scale out dynamically on a per-tenant, per-application, or per-segment basis [11:59] Alexey Gorovoy: Operators can enable IPv6 routing alongside IS-IS version 6 with SRv6 extensions while leaving existing IPv4/MPLS IS-IS topologies intact during transition [15:02] Alexey Gorovoy: By concentrating policy at the network edges (Cloud Gateways and Border Routers), intermediate switches remain stateless underlay routers that no longer carry VRF state or execute protocol translation

Original transcript

[0:05] Good afternoon. My name is Alexo and I'm [0:07] a network engineer at Nadus. It's an [0:09] honor to be here with you today and I'm [0:11] excited to share the case study on how [0:14] we are evolving our customer cloud [0:16] interconnect architecture and [0:17] specifically how we're using SR6 as a [0:20] foundation technology for that. Before [0:22] we start, let me briefly introduce who [0:24] we are. Navis is a new cloud company [0:27] with a deep expertise in hardware and [0:28] software development. We build large [0:30] scale GPU clusters and we develop an AI [0:34] native cloud computing platform. So we [0:36] create a full stack of technologies that [0:38] provides our AI customers with [0:39] everything they need to build, train and [0:42] run their models and apps all in one [0:44] place. [0:46] Before I jump into neighbor specific use [0:48] case, let's broader industry context. [0:51] Most cloud providers expose some form of [0:54] a cloud interconnect solution which is [0:56] basically a private connection from [0:58] customer premises into the cloud [1:00] providers network and the fundamental [1:03] requirements are the following. It's a [1:05] tenant isolation predictable bandwidth [1:07] and integrated security from the [1:10] interconnect point to get to the [1:12] customer virtual cloud environment. [1:13] Traffic typically has to cross multiple [1:15] network domains like edge core data [1:18] center fabric all the way to the cloud [1:20] host and traditionally each of those [1:23] domains has been built with a separate [1:25] technology st optimized for its own [1:27] requirements and there is nothing prompt [1:29] with those technologies individually. [1:31] However, the problem is that they do not [1:33] always integrate cleanly and to add and [1:36] which creates service boundaries, [1:38] protocol translation points and [1:41] potential operational and functional [1:43] bottlenecks. So in this talk I'll share [1:46] how we at neighbors approach this [1:48] problem and how this solution helps us [1:52] eliminating those constraints. [1:55] First I'll show the architecture we [1:57] started with and then why it stopped [2:00] scaling for the new interconnect demands [2:04] and then I will specifically focus on [2:07] why SRV6 is usable for that architecture [2:10] and basically how we did that and share [2:13] some implementation experience. [2:16] So let's get started. I'd like to begin [2:18] with a brief overview of our current [2:20] network architecture. [2:22] So being a global service provider [2:25] company, we operate a network consisting [2:27] of several data centers across Europe [2:30] and the US. So those regions are [2:32] interconnected with a private backbone, [2:34] but also each side is independently [2:37] connected to the internet either [2:39] directly or via the closest [2:41] telecommunication point of presence. And [2:44] from the customer interconnect [2:45] standpoint, the major demand from the [2:47] beginning was simply moving big customer [2:50] data sets from their premises into [2:53] neighbors cloud, store them locally for [2:55] further AI model training activities and [2:58] we used public internet for that. So [3:01] customer traffic would always stay local [3:03] for a particular region and never [3:05] traverses inter region back. That model [3:08] worked well while most of the large data [3:11] movement happened only once during the [3:14] customer on boarding and that's also [3:16] shaped how we designed our front end [3:18] network. So let's take a closer look on [3:21] it. We at NAS are strong supporters and [3:24] practitioners of IPv6 network protocol. [3:26] So not only our data center fabric but [3:29] also other infrastructure components [3:31] like compute clusters, storage and the [3:34] rest of services function over IPvac. [3:37] Two key components of our infrastructure [3:39] that I would like specifically to [3:40] mention because they are relevant for [3:42] this solution are the cloud gateway and [3:45] the firewall. So those two are in-house [3:48] developed software functions built based [3:51] on the open-source components. The [3:53] primary goal of the cloud gateway is [3:56] being an exit point for the customers [4:00] virtual machines to the outside world [4:02] and to interconnect those we use gigs [4:05] ADPM protocol stack and then in our [4:08] private band we use MLS segment routing. [4:12] On top of that, we provide layer TDPM [4:14] service across both web and data center [4:17] domain to simply connect custom virtual [4:20] machines to the internet in a secured [4:23] and reliable way. And for the regional [4:25] connectivity model, that was manageable, [4:28] but the requirements started changing. [4:32] First, customers increasingly wanted [4:34] dedicated and predictable band members [4:37] rather than best effort internet [4:38] connectivity. Second, the requested [4:41] capacity moved into hundreds of [4:43] gigabits, in some cases multiple [4:45] terabits. And third, security functions [4:48] such as end-to-end encryption, optional [4:51] firewall inspection increasingly had to [4:53] become part of the connectivity service. [4:56] That changes the problem significantly [4:58] as we had to start building dedicated [5:01] high bandwidth customer interconnects [5:03] and carry this traffic from a remote [5:06] point of presence across the backbone [5:09] through the data center and all the way [5:11] to the cloud gateway to the cloud host. [5:14] To do that efficiently, we need VPN and [5:17] traffic engineering capabilities across [5:19] both domains. But having two different [5:22] protocol STS the stitching point between [5:25] them becomes both an operational and [5:28] functional bottleneck. [5:30] So let me introduce the customer cloud [5:33] interconnect solution and it's not only [5:36] a new connectivity service but also a [5:39] new architecture that changes how we [5:41] evolve our backbone and edge [5:43] connectivity but also rein the boundary [5:46] between the cloud and the physical [5:48] network. And the goal is to build an [5:50] efficient bridge between the virtual [5:52] cloud environment and the physical [5:53] network age while extending customer [5:56] multi-tenency capabilities across the [5:58] data center and when incorporating [6:01] traffic engineering for efficient [6:04] service chaining creation and when this [6:06] management [6:09] those requirements are what led us to [6:12] SRV6 at the fundamental technology for [6:15] this architecture. So let's take a look [6:18] at why SRV6 fit this architecture and [6:20] then how we actually use it. [6:24] Evaluating our current protocol stack, [6:26] we came to the following conclusions. [6:28] One of the big slang VPN strong [6:30] advantage is its wide adoption across [6:32] multiple vendors and also open source [6:34] based products which makes it easier to [6:37] integrate different hardware and [6:39] software components in a diverse [6:41] environment like ours. However, the lack [6:44] of native traffic engineering [6:46] capabilities limits its ability to [6:48] support the injection of different [6:50] network services like firewall on a [6:52] granular and a dynamic fashion and [6:54] usually to achieve that with VXLAM. So [6:57] that would require a specific and [6:59] unflexible routing design. While MLSSR [7:02] has those capabilities in the V domain, [7:05] they are barely applicable in the data [7:08] center domain. So here we are having two [7:11] separate domains with two separate [7:12] protocol STS one in the data center and [7:14] another one in the van domains and so to [7:17] interconnect those efficiently that [7:19] would require a specific stitching [7:21] gateway functionality and that raises a [7:24] whole set of new challenges on its own. [7:28] First of all, the functionality might [7:29] simply be not supported across different [7:31] vendor implementations or the particular [7:34] implementations might impact the [7:36] hardware performance of a particular [7:39] platform and then increases the overall [7:41] complexity of the end to-end [7:43] architecture due to protocol translation [7:46] and the requirement to terminate the [7:50] customer BRS on intermediate devices. So [7:54] that's basically why we believe that [7:56] SRV6 addresses all of those concerns. It [8:00] takes the best out of both worlds. So [8:04] staying a simple lightweight basically [8:07] IP and IP based encapsulation overlay [8:10] but still incorporating powerful traffic [8:13] engineering capabilities within it. [8:17] So let's explore our first use case [8:20] which is overlay with S surv 6 micro [8:22] seat. As I mentioned before we use LGVPN [8:26] service to provide multi-enum capability [8:28] for customer virtual machines and then [8:31] the solution is pretty straightforward. [8:34] So taking advantage of our current IPv6 [8:37] routed network, we only adding segment [8:40] route EP6 functionality at the edge [8:43] points of those domains which are the [8:45] cloud gateway on the cloud side and then [8:47] the internet border on the physical [8:49] network edge layer. So being NH points [8:52] of the network they both act as a [8:54] traditional layer TDPM provider edge [8:57] nodes and then we completely eliminate [9:00] any protocol translation and VRS [9:02] stitching in between. The underlying [9:05] infrastructure is simply IPv6 routed [9:07] network providing reachability of the [9:10] IPv6 locator prefixes. [9:16] So I would also like to highlight that [9:18] the g that the elegance of micro [9:20] technology specifically is that it [9:23] compresses multiple segment ids into a [9:26] single IPv6 destination address header. [9:29] So it does not require extra protocol [9:31] headers like with DX1 or NLS where we [9:35] need to carry label stack or VNIS. There [9:39] are cases though when SRH header might [9:42] come into play. But if you manage your [9:44] IP allocation right and do not exceed [9:48] more than six signalant that basically [9:50] could feed the single IQ6 destination [9:53] address which typically is more than [9:55] enough. Um so there won't be any need [9:57] for the SR to come up. So micro seed [10:01] helps greatly reduce the packet overhead [10:03] which is important for the overall [10:05] performance especially for hostbased [10:08] virtual routers and their processing [10:10] performance. [10:12] Let's take a look at our second use case [10:14] which is firewall service. We started [10:17] with SRV6 unaware service mode which [10:20] basically means that the firewall itself [10:23] is SRV6 unaware. So it continue operates [10:28] at the normal inspection function and to [10:31] be able to steer the traffic through the [10:33] firewall to build the service chain in [10:35] that mode we need a soal proxy nodes [10:40] which are in our case in our solution [10:42] are srv6 a dedicated srv6 enabled [10:46] service list which connect those [10:48] firewall to the data center [10:49] infrastructure. So the service leaves or [10:52] the proxy nodes they have the note and [10:55] adjacency seats enabled so they could be [10:58] later referred inside the traffic [11:00] engineering policy. So to steal traffic [11:03] from the firewall, we instantiate [11:06] traffic engineering policies on the edge [11:08] points of the domains which are as I [11:10] mentioned earlier the cloud gateway and [11:13] the border router. And yeah, this is [11:16] basically how we can build an end toend [11:20] service chaining [11:22] function based on the SRT policies. [11:27] However, the target goal is to move [11:29] towards the SRV6 service aware firewall. [11:33] basically removing the dependency on the [11:35] dedicated proxy nodes. Hence allowing to [11:38] scale out the firewall service being [11:40] able to attach it anywhere in the cloud [11:42] infrastructure to a simple IPv6 routed [11:45] network which will greatly helped to [11:49] scale on the granular fashion the [11:52] firewall service per segment customer or [11:55] any specific service or application. [11:59] Then moving further let me share some [12:01] implementation experience what we [12:03] achieved so far and where we are going. [12:06] So SRV6 micro seat becoming a [12:10] standardized technology has becoming [12:13] more and more mature and through [12:15] multiple testings and proof of concepts [12:17] and evaluating with different vendors [12:19] and then further later on in the [12:21] production deployments we were able to [12:24] confirm a decent interperability across [12:27] different hardware vendor platforms [12:30] which we use in our production [12:31] environment and then for a customer [12:34] gateway functionality [12:36] We also evaluated multiple open-source [12:40] components and we chose the VPP for that [12:44] and based on that we created our own [12:48] custom cloud gateway and basically the [12:51] VPP provides us with possibility to do [12:54] any sRBC snapper programming [12:56] capabilities on the host side. From the [13:00] migration perspective, I would also like [13:02] to highlight because it might be [13:04] important for a lot of networks or [13:07] domains operating in the traditional NOS [13:11] IPv4 based infrastructure. So it's all [13:14] about the dual stack implementation [13:16] basically. So it's relatively easy with [13:20] a limited impact to implement SRV6 in [13:23] your existing infrastructure because we [13:25] just enable IPv6 routing dual stack [13:29] inmenting ISIS version 6 with SRV6 [13:33] extensions in it but still keeping the [13:35] ISIS4 topology for instance with [13:38] Mossbased segment routing extensions. [13:43] There are still some practical [13:44] considerations though which I would like [13:47] to highlight. So as we start propagating [13:51] VPN before routes or IPv6 infrastructure [13:54] this IPv6 next talk it's important that [13:57] your particular implementation of the [13:59] product should be complying with the RFC [14:01] 8950. [14:03] And then [14:05] since we deal with two domains here, the [14:07] data center and the valve, it's [14:10] important that the SRB6 locator [14:13] capabilities stay preserved while we're [14:16] distributing the locator addresses [14:17] between both domains so that it will [14:20] allow to build an end to end BPM BGP [14:23] session and resolve the routes. Very [14:26] important part also mentioned to point [14:29] out is that the with SRV6 the locator [14:32] address space design matters and is very [14:35] important because it affects how much [14:38] room we can have for a future traffic [14:40] engineering scale within your [14:43] destination IPv6 address or seat [14:46] container as as we call it. So the main [14:49] lessons learned are that the feature is [14:52] mature, design is interoperable and we [14:56] were able to confirm there is a clear [14:58] validated approach for migration. [15:02] To conclude, I would like to highlight [15:05] it one more time. We started with a [15:07] cloud interconnect problem that crossed [15:09] several technology domains and our goal [15:12] was to preserve multi-tenency benders [15:15] control and service in centure insertion [15:17] capabilities end to end without making [15:19] the boundaries between those domains [15:22] very complex. SRV6 gives us past doing [15:26] that with a common IPv6 based service [15:29] model and with policy concentrated at [15:32] the network edges. It offers operational [15:34] simplicity. [15:36] Intermediate devices no longer need to [15:38] perform protocol translation or maintain [15:41] specific VRF stitching. A service change [15:45] such as a firewall in session can be [15:48] expressed as an SR policy changed only [15:50] at the edge points of the the domain. [15:55] So that helps to keep the middle of the [15:56] network simple and it gives us more [15:58] freedom to scale out without [16:00] dependencies on different domains [16:03] specifically [16:06] just to give you some sneak peek of [16:08] where we are targeting to. So our [16:12] current work is focused on two areas. [16:14] First of all is just broader [16:16] infrastructure enablement. We would like [16:18] also to enable SR6 and our other network [16:21] domains like DCI and internet edge and [16:25] completely replacing our dependence on [16:28] VXL and NOS service texts. And the [16:31] second is a service evolution. As I [16:34] mentioned earlier in my firewall [16:36] insertion use case, you want the [16:39] firewall itself to become SR6 enabled, [16:42] which would allow us to basically scale [16:45] it out more granularly. So considering [16:48] that firewall is also our in-houseuilt [16:52] product, we would like to invest more [16:54] into developing the SRP6 functionality [16:58] in this product and use it in future. [17:01] And finally, we are working toward a [17:03] customer controller, a custom controller [17:06] for traffic engineering and pass [17:08] provisioning so that these policies can [17:10] be managed dynamically rather than [17:12] static network configuration. [17:16] I would also like to encourage you to [17:19] take a look at the ITF draft that we [17:21] came up with together with our partners [17:24] from Cisco and all the customer other [17:27] customers joining us in this document [17:30] because we strongly believe that this [17:34] solution might address a very very [17:36] common tasks that is relevant for a lot [17:40] cloud providers today. [17:44] So that's it from my side. Thank you for [17:46] your attention.