Markdown Version | Transcript | Recording 1 | Recording 2 | Session Materials

Session Date/Time: 17 Mar 2026 03:30

SRV6OPS

Summary

The SRV6OPS working group met during IETF 125 to discuss operational experiences and deployment strategies for SRv6. This first of two sessions focused primarily on operator presentations from the cloud and industrial sectors, including Alibaba Cloud, China Mobile, and Guangdong Power Grid. The session also covered working group status and a liaison from ITU-T Study Group 11.

Key Discussion Points

1. Working Group Status and Liaison

The Chairs provided an update on the two active working group documents:

• draft-ietf-srv6ops-srv6-deployment
• draft-ietf-srv6ops-problem-summary

Dhruv Dhody presented a liaison from ITU-T Study Group 11 regarding SRv6 conformance testing. The ITU-T has provided a document for review covering various test cases. Dhruv Dhody noted that while IETF does not typically designate extensions as "core" or "optional" in the same manner, the feedback provided by BMWG and other groups has been incorporated by ITU-T. Currently, the chairs do not plan to take formal action as a working group, but encouraged individuals to review the document and reach out to the chairs or the liaison (Scott Mansfield) if a formal response is deemed necessary.

2. Operator Presentations

2.1 IPv6&SRv6 Powering Alibaba Cloud AI Computing (Alibaba)

Chen Fei presented Alibaba Cloud's transition to an IPv6-native data center (HPN7) to support AI computing.

• Challenges: Massive IPv4 demand (380 /16 blocks for 10 clusters), virtualization overhead in traditional VXLAN (impacting RDMA performance), and cross-region bandwidth contention.
• Solution: Deployment of "NetPillar," an SRv6 container network using SR-BE. It utilizes a /64 prefix per server and uses the 64-bit host portion for programmable lightweight isolation (Tenant ID and Interface ID).
• Backbone: The "Eco" network uses SRv6 for cross-region path selection. Flow labels are used to map traffic to specific paths (RDMA, high-bandwidth, or low-cost) determined by a centralized controller.
• Discussion: Mingxiang inquired about flow label generation; Chen Fei clarified that a centralized manager pushes mapping info to the servers (NetPillar). The Chair asked if VXLAN was still used; Chen Fei confirmed they use native SRv6 (SR-BE) exclusively for the container network to avoid overhead.

2.2 SRv6-Driven Security Resource Pools (China Mobile) V1

Jiaming discussed the deployment of SRv6 for Service Function Chaining (SFC) in security resource pools.

• Transition: Moving from PBR-based orchestration (limited by VLAN scales and inefficient "traffic detours" to the Security Gateway) to SRv6.
• Mechanism: The Security Gateway (SecGW) acts as the SRv6 headend. To keep SID lists short, they use an "ARNID" in the packet header to identify the tenant/instance, while the SID identifies the physical/virtual location of the Value-Added Service (VAS).
• Results: Observed a throughput increase (20G vs 15G for 1400B packets) and significantly better bandwidth efficiency (45% vs PBR's rapid degradation).
• Future Work: Needs include better reliability (granularity of VAS switchover), clustering support for VAS, and potential adoption of Compressed SID (C-SID) to reduce overhead.

2.3 SRv6 for End-to-End Services (Guangdong Power Grid)

Lugian Gang presented on the migration of China’s largest provincial power grid from IP/MPLS to SRv6.

• Architecture: A three-layer management model (Physical Network, Vendor NMS, Unified NMS) is used to handle a multi-vendor, multi-area environment.
• Case Studies:
  1. Automated SRv6 VPN deployment for high-quality video conferencing with path optimization.
  2. Application-enabled networking using "Electrical Open Harmony OS," where endpoints mark IPv6 traffic with IDs that network devices map to SRv6 tunnels.
• Discussion: Mingxiang asked about the use of standard models; Lugian Gang confirmed they use standard IETF models like L2NM and L3NM for the northbound interface, with some custom extensions. Dhruv Dhody clarified that the latency metrics mentioned for video services were round-trip measurements.

Decisions and Action Items

• ITU-T Liaison: The Working Group decided not to take formal action on the ITU-T Study Group 11 liaison at this time. Individuals are encouraged to review the conformance test cases independently.

Next Steps

• Operators are encouraged to contribute their deployment experiences and technical findings into the working group’s active drafts: draft-ietf-srv6ops-srv6-deployment and draft-ietf-srv6ops-problem-summary.
• The second session of SRV6OPS will focus on the progression and technical details of the current drafts.

Session Date/Time: 20 Mar 2026 03:30

SRV6OPS

Summary

The SRV6OPS working group met to discuss several updates to deployment guidelines and new operational considerations for SRv6. Key topics included the migration of VXLAN to SRv6, addressing schemes for compressed SIDs, inter-domain interworking models (Options A, B, and C), and specialized use cases such as RDMA/RoCEv2 load balancing and ESP-protected payloads for financial services. A recurring theme was the coordination between SRV6OPS and the SPRING working group regarding where generic SR policy operations should be documented.

Key Discussion Points

1. SRv6 Deployment Options

Michael Goralski presented updates to draft-ietf-srv6ops-srv6-deployment.

• Presentation: 1. Introduction (Note: Slides cover the deployment draft updates).
• Updates: The draft has been made less MPLS-centric to include other encapsulations. A new section on migrating from VXLAN to SRv6 was added, focusing on upgrading VTEPs and decommissioning VXLAN encapsulation.
• Discussion:
  • Pavan Beeram suggested including migration from RSVP-TE to SRv6, referencing RFC 8426 as a guide for coexistence.
  • Dhruv Dhody recommended reaching out to the BESS and NVO3 working groups for a sanity check on the VXLAN migration steps.
  • The authors clarified that direct migration (MPLS to SRv6) is generally preferred over a gradual step through SR-MPLS now that SRv6 implementations are mature.

2. Traffic Steering Considerations

Yisong Liu introduced a new draft regarding traffic steering methods for SRv6.

• Presentation: 2.2 SRv6-Driven Security Resource Pools （China Mobile）V1 (Note: Transcript discussion focused on steering methods including DSCP, FlowSpec, and Color-based steering).
• Discussion:
  • Dhruv Dhody and Bruno Decraene (SPRING Chair) noted that most of the steering mechanisms described are applicable to SR Policy in general (both SR-MPLS and SRv6).
  • Decision: The chairs recommended the authors post this to the SPRING mailing list to determine if it should be handled there as a generic SR document or remain in SRV6OPS with a specific focus on SRv6-only operational aspects.

3. SRv6 Addressing Considerations

Martin Horneffer presented updates on the addressing scheme for compressed SIDs.

• Topic: Addressing considerations for NEXT-C-SID (F3216 flavor), focusing on summarization and scalability for small to very large networks.
• Discussion:
  • Jim Guichard (AD) questioned the focus on NEXT-C-SID to the exclusion of REPLACE-C-SID. He noted that for the document to progress, it must either include both flavors or provide a consensus-based justification for focusing on only one.
  • Martin Horneffer acknowledged this and will consider adding text for both flavors.

4. SRv6 Inter-domain Interworking

Haiyang Zhu presented a proposal for inter-domain SRv6 interworking.

• Topic: Adapting MPLS VPN Options A, B, and C to SRv6 environments to handle cases where locator routes are not advertised across domains.
• Discussion:
  • Joel Halpern raised concerns regarding the administrative and trust relationships between ASes, noting that SRv6 might not be run across separate administrative domains without specific constraints.
  • Jim Guichard and Dhruv Dhody noted that cross-domain SRv6 has significant security implications that might fall under the SPRING charter. The chairs will coordinate.

5. QP-based Load Balancing for AI Computing

Jieming presented a solution for RDMA/RoCEv2 load balancing using SRv6.

• Presentation: 2.1 IPv6&SRv6 Powering Alibaba Cloud AI Computing (Alibaba)
• Technical Content: Utilizing the Queue Pair (QP) ID from RoCEv2 headers as a hash input for SRv6 policies to better distribute elephant flows in AI data centers.
• Discussion:
  • Jeff Tantsura expressed skepticism regarding the complexity, noting that QP IDs are dynamically assigned by host-side collective libraries and that the overhead of communicating these to a controller might outweigh the load-balancing benefits.

6. SRv6 Policy Selector

Funyuan presented on the SRv6 Policy Selector for composite policies.

• Presentation: 2.3. SRv6 for End-to-End Services (Guangdong Power Grid)
• Technical Content: Selecting constituent policies within a parent SR policy based on real-time quality measurements (latency, bandwidth) and defined thresholds.

7. ESP-Protected Payload over SRv6

Linda Dunbar discussed the use case for encrypted payloads within SRv6 policies.

• Topic: Using BGP tunnel encapsulation attributes to advertise IPsec/ESP sub-TLVs for SRv6 services, specifically for financial enterprise customers.
• Discussion:
  • Jeff Tantsura encouraged the authors to bring in more operator voices to the draft to satisfy the working group's focus on operational experience.

Decisions and Action Items

• Draft Migration: Authors of the Traffic Steering draft are to engage with the SPRING working group.
• Addressing Draft: Authors of the addressing draft must address the inclusion of both NEXT-C-SID and REPLACE-C-SID or justify the current focus.
• Chair Coordination: SRV6OPS chairs will meet with SPRING chairs to discuss the boundaries of work regarding inter-domain SRv6 and generic SR steering.

Next Steps

• Continue refinement of draft-ietf-srv6ops-srv6-deployment with RSVP-TE and VXLAN feedback.
• Solicit further reviews on the mailing list for all 00-level drafts presented.

Related Documents

draft-ietf-srv6ops-problem-summary, draft-ietf-srv6ops-srv6-deployment