Network Working Group Y. Liu
Internet-Draft China Mobile
Intended status: Informational T. Graf
Expires: 25 March 2026 Swisscom
Z. Miklos
MTN
L. Contreras
Telefonica
N. Leymann
Deutsche Telekom
25 September 2025
SRv6 Deployment and Operation Problem Summary
draft-liu-srv6ops-problem-summary-06
Abstract
This document aims to provide a concise overview of the common
problems encountered during SRv6 deployment and operation, which
provides foundations for further work, including for example of
potential solutions and best practices to navigate deployment.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on March 25, 2026.
Liu, et al. Expires March, 2026 [Page 1]
Internet-Draft SRv6 DOP September 2025
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction.....................................................3
1.1. Requirements Language.......................................3
2. SRv6 Network Migration...........................................3
2.1. SRv6 Migration from MPLS Networks...........................3
2.2. SRv6 Inter-Domain Connectivity..............................5
3. SRv6 Network Visualization.......................................6
3.1. SRv6 Path Performance Visibility............................6
3.2. Multi-source Data Troubleshooting...........................7
4. SRv6 Address Planning............................................8
5. Traffic steering to SRv6.........................................9
6. Deployment Practice for SRv6 Protection.........................10
7. Challenges of Different Network Types...........................11
7.1. Data Center Networks.......................................11
7.2. Campus Networks............................................12
8. Security Considerations.........................................13
9. References......................................................13
9.1. Normative References.......................................13
9.2. Informative References.....................................14
10. Appendix: Possible Missing DOPs for Future Consideration.......14
Contributors.......................................................16
Authors' Addresses.................................................17
Liu, et al. Expires March, 2026 [Page 2]
Internet-Draft SRv6 DOP September 2025
1. Introduction
Segment Routing over IPv6 (SRv6) is a new technology that builds
upon the existing IPv6 infrastructure to offer programmable data
plane capabilities. This allows for more granular control over
traffic forwarding, enabling flexible and scalable network designs.
While SRv6 presents numerous potential benefits, such as improved
traffic engineering, optimized resource utilization, its deployment
and operation come with certain challenges.
This document aims to provide a concise overview of the common
problems encountered during SRv6 deployments and operations, which
provides foundations for further work, including for example
potential solutions and best practices to navigate deployment . By
understanding these challenges and exploring mitigation strategies,
network administrators can make informed decisions when implementing
and managing SRv6 networks.
This document identifies a number of Deployment and Operation
Problems (DOPs) that require additional work within IETF.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. SRv6 Network Migration
2.1. SRv6 Migration from MPLS Networks
In the evolution from non-SRv6 networks to SRv6 networks, the
migration from MPLS to SRv6 represents the most typical and common
scenario. This process requires addressing the following key
challenges:
Ensuring interoperability between MPLS and SRv6 during the
transition.
Avoiding service interruptions to existing VPN services.
Supporting smooth migration paths with minimal deployment and
operational complexity.
Liu, et al. Expires March, 2026 [Page 3]
Internet-Draft SRv6 DOP September 2025
+------P1----PE2
| ...........>|
| : MPLS |
PE1 |
| : SRv6 |
| ...........>|
+-----P2----PE3
Figure 1: Intra-domain SRv6&MPLS Coexistence
SRv6 and MPLS Coexistence means a network that supports both SRv6
and MPLS in a given domain. This may be a transient state when
brownfield MPLS network upgrades to SRv6 or permanent state when
some devices are not capable of SRv6 but supports native IPv6 and
MPLS. A smooth transition from an MPLS network to an SRv6 network is
required. For instance, deploy dual-stack tunnels for VPN over MPLS
and VPN over SRv6, with MPLS and SRv6 sharing VPN instances. When
the next hop of the route is an IPv4 address, iterate through the
MPLS tunnel; when the next hop is an IPv6 address, iterate through
the SRv6 tunnel. Prefer VPN routes based on SRv6. Once the
transition is complete, the MPLS tunnel can be removed. When
operating both MPLS and SRv6 concurrently, key considerations arise
regarding how to ensure effective protection during failures, as
well as how to manage the increased complexity of performance
monitoring and optimization deployment. So it becomes critical to
address methods for reducing the complexities associated with
deployment and operational maintenance.
+-----P1------+-----P3------+-----P5------+-----P7------+
| | | | |
| | | | |
PE1 ABR ABR ABR PE2
| | | | |
| | | | |
+-----P2------+-----P4------+-----P6------+-----P8------+
<....SRv6....><.....MPLS....><....SRv6....><.....MPLS....>
<.....................EVPN/L2VPN/L3VPN...................>
Liu, et al. Expires March, 2026 [Page 4]
Internet-Draft SRv6 DOP September 2025
Figure 2: Inter-domain SRv6&MPLS Coexistence
Ensuring seamless interworking between legacy MPLS networks and
newly deployed SRv6 networks in long-term coexistence scenarios
presents significant challenges, particularly in multi-domain
architectures where each domain operates independent IGP instances
and employs a single data plane type for both overlay and underlay.
The potential cascading of MPLS and SRv6 domains introduces
complexities in guaranteeing end-to-end path quality requirements
such as latency, bandwidth, and reliability when traffic traverses
these heterogeneous data planes. Additionally, achieving rapid end-
to-end path convergence during failures requires robust mechanisms,
especially when edge nodes must perform route regeneration and re-
advertisement functions between different address families like EVPN
and VPNv4 or VPNv6, while minimizing operational complexity and
maintaining consistent service levels across such hybrid
infrastructures remains a critical operational concern.
DOP-1: How to smoothly migrate from existing MPLS networks to SRv6
while ensuring service continuity, interoperability and minimizing
deployment complexity.
2.2. SRv6 Inter-Domain Connectivity
In some cases, SRv6 networks need to extend across multiple domains,
including third-party or legacy networks that may not natively
support SRv6 or even IPv6. This inter-domain scenario introduces new
requirements and challenges:
Ensuring SRv6-based services can traverse domains where native
SRv6 or IPv6 is not supported.
Reducing complexity compared to traditional MPLS-based inter-
domain solutions.
Improving scalability and operational simplicity for service
providers.
+-----P1------+-----P3------+-----P5------+-----P7------+
| | | | |
| | | | |
PE1 ABR ABR ABR PE2
Liu, et al. Expires March, 2026 [Page 5]
Internet-Draft SRv6 DOP September 2025
| | | | |
| | | | |
+-----P2------+-----P4------+-----P6------+-----P8------+
<...........................SRv6........................>
Figure 3: Inter-domain SRv6 End to End
When migrating from BGP/MPLS VPN [RFC4364] inter-domain solutions
(Option A/B/C) to SRv6-based architectures, several operational and
technical challenges emerge. For Option A, back-to-back VRFs require
complex interface-level configurations that conflict with end-to-end
service paradigm of SRv6. For Option B, the stateful inter-AS label
mapping mechanisms become redundant when transitioning to the source
routing model of SRv6, creating protocol coexistence issues during
migration. For Option C, recursive label stacking proves
incompatible with SRv6 end to end service, necessitating Autonomous
System Border Router(ASBR) functionality redesign. Additional
challenges include maintaining service continuity during phased
migration, retraining operational staff for SRv6 troubleshooting,
and achieving consistent traffic engineering across hybrid MPLS-SRv6
domains. The IPv6 infrastructure readiness gap-particularly
regarding MTU management and ICMPv6 processing-further complicates
deployment, while the OAM mechanisms for inter-domain SRv6
operations in fault detection and performance monitoring are also
facing challenges.
DOP-2: How to achieve scalable and simplified end-to-end inter-
domain communication using SRv6, overcoming the limitations of
traditional MPLS-based solutions.
3. SRv6 Network Visualization
3.1. SRv6 Path Performance Visibility
The existing IETF data collection frameworks can be applied to SRv6
for both data plane and control plane monitoring, but currently lack
critical capabilities for measuring SRv6-specific path performance
metrics and granular traffic statistics. This significant visibility
gap fundamentally limits the ability to conduct meaningful SRv6
network analysis, either making it completely impossible or severely
compromising its effectiveness-particularly for use cases such as:
Liu, et al. Expires March, 2026 [Page 6]
Internet-Draft SRv6 DOP September 2025
Network delay and packet loss measurement: In scenarios where an
SRv6 path traverses multiple network segments (e.g., edge,
aggregation, core network), current monitoring tools are unable to
provide accurate per network segment and end-to-end delay or
packet loss data.
End-to-end path reconstruction: Traditional network monitoring
only provides hop-by-hop metrics visualization, which offers
limited capabilities for end-to-end SRv6 path optimization and
adjustment. Simply combining per-hop metrics does not accurately
reflect the actual performance of the overall path, and thus fails
to provide effective support for SRv6 path re-optimization.
These issues make service path validation, traffic forecasting, and
microsecond-level troubleshooting challenging in SRv6 networks.
DOP-3: The collection of SRv6-specific path performance data is
incomplete and inefficient, limiting end-to-end visibility of SRv6
service paths and making it difficult to validate and optimize
performance.
3.2. Multi-source Data Troubleshooting
In network fault management, a key challenge lies in the inability
to automatically correlate information from multiple monitoring
sources such as BGP Monitoring Protocol(BMP), Internet Protocol Flow
Information Export(IPFIX), and YANG-push. Currently, when a failure
occurs, operators only can manually collect and interpret data from
these isolated systems to identify the root cause. For example, in
the case of an SRv6 service interruption:
BMP can report report routing instability or BGP session changes;
IPFIX could indicate abnormal traffic drops for specific SRv6
paths or segments;
YANG-push can show abnormal resource utilization or interface
errors from device telemetry statistics.
Although each traffic provides valuable insights, the absence of a
unified correlation mechanism or common data model requires manual
cross-referencing and time-consuming analysis. This lack of
Liu, et al. Expires March, 2026 [Page 7]
Internet-Draft SRv6 DOP September 2025
automated correlation significantly delays fault detection,
diagnosis, and service recovery. Furthermore, the diversity of data
models and semantic differences in SRv6-related telemetry create
additional integration barriers.
Most current tools are unable to effectively aggregate, interpret,
and present multi-source SRv6 data in a consistent and actionable
manner, which further impacts operational efficiency and network
reliability.
DOP-4 Multi-source network data (BMP, IPFIX, YANG, etc.) lacks
automatic correlation and integration, complicating SRv6 network
operation and fault analysis, and leading to delays in
troubleshooting and recovery.
4. SRv6 Address Planning
Existing IPv6 address planning are primarily based on network types
and hierarchical administrative divisions. While effective for
traditional IPv6 deployment, such approaches are insufficient to
meet the requirements of SRv6 Segment Identifier(SID) allocation,
especially in the context of advanced capabilities such as SRv6
compression. If SRv6 SID planning simply inherits the conventional
IPv6 structure, it may lead to a fragmented SID space, complicating
end-to-end segment routing. On the other hand, deviating entirely
from the existing addressing scheme introduces significant
complexities in address management and operational consistency.
In multi-domain networks, high levels of route aggregation are
desirable for efficient SRv6 compression. However, this objective
often conflicts with existing IPv6 address planning that are
organized along administrative boundaries. Consequently, a
rethinking of SRv6 address planning is necessary to align
compression benefits with scalable network design. Strategic
allocation of SRv6 SID blocks must holistically consider both
administrative division management and route aggregation
requirements. Similarly, the distribution of NodeIDs and functions
should balance administrative practicality with optimal address
space utilization within the SRv6 architecture.
Some initial approaches and considerations for structured SRv6 SID
assignment can be found in [I-D.liu-srv6ops-sid-address-assignment],
which provides a foundation for further standardization and
operational practices.
DOP-4: Exisiting IPv6 address planning methods are insufficient to
accommodate the structural requirements of SRv6 SIDs. The inherent
complexity introduced by the SID architecture extends beyond
Liu, et al. Expires March, 2026 [Page 8]
Internet-Draft SRv6 DOP September 2025
conventional IPv6 addressing, complicating overall network planning
and integration.
DOP-5: In inter-domain deployment environments, SRv6 SID allocation
poses challenges such as inefficient utilization of address space,
impediments to route aggregation, and inconsistent compression
performance, which may undermine the efficiency gains promised by
SRv6.
5. Traffic steering to SRv6
The general purpose of traffic steering is to optimize the
allocation and transmission of network resources, ensure a balanced
distribution of network traffic, improve network performance, reduce
congestion, and increase available bandwidth to provide users with a
better network experience.
In SRv6-enabled networks, traffic steering plays a critical role,
especially in realizing advanced use cases such as service function
chaining, traffic engineering, and end-to-end SLA assurance.
However, steering traffic to SRv6 paths introduces unique
challenges, as SRv6 supports a wide range of encapsulation and
policy mechanisms, and these choices greatly affect deployment
flexibility, operational complexity, and optimization capabilities.
There are various SRv6 traffic steering methods, each with its own
unique advantages and limitations. For example:
Using BGP color community-based policy may fail to provide
sufficient granularity or flexibility for dynamic adjustment in
some enterprise scenarios.
Using flow-based steering such as flowspec may become infeasible
when facing a large number of flows, as maintaining per-flow
granularity overwhelms the control plane and devices.
Therefore, it is essential to select the appropriate SRv6 traffic
steering mechanism based on the specific application scenario. Some
initial technical considerations can refer to [I-D.geng-srv6ops-
traffic-steering-to-srv6].
When selecting network traffic steering methods, factors such as
network architecture, service requirements, resource constraints,
Liu, et al. Expires March, 2026 [Page 9]
Internet-Draft SRv6 DOP September 2025
and operational costs must be comprehensively considered, and the
selection logic varies significantly across different hierarchy
nodes. For example, delay-sensitive and bandwidth-intensive
scenarios have different requirements for traffic steering methods.
Moreover, strategies for selecting traffic steering methods differ
depending on network scale. Finally, operational complexity varies
with different steering methods, influencing operational
requirements.
DOP-6 There are various methods for SRv6 traffic steering, making it
difficult to select the appropriate method for different scenarios.
This leads to deployment complexity, especially when the chosen
method does not meet the requirements of granularity, scalability,
or operational ease. For example, using a simple color-based policy
may not support fine-grained tuning, and flowspec-based approaches
may not scale in high-flow-volume environments.
6. Deployment Practice for SRv6 Protection
Implementing reliability practices can significantly enhance the
stability and performance of networks based on SRv6. Network
failures are inevitable in the real world. Reliability practices can
help network engineers quickly identify, isolate, and fix faults,
thus minimizing impact on services.
In summary, the necessity of SRv6 reliability practices is evident
in several aspects, including improving network stability and
performance, enhancing fault handling capabilities, ensuring
security, improving compatibility and interoperability, optimizing
management and monitoring, and enhancing deployment experience.
SRv6 offers multiple protection mechanisms, with different
applications requiring different protection requirements. It is
challenging to select the most suitable protection mechanism, or a
combination of mechanisms. When multiple protection mechanisms
coexist, achieving the desired protection outcome becomes difficult,
and there is a lack of effective coordination methods. Some initial
work could refer to [I-D.liu-srv6ops-sr-protection].
Liu, et al. Expires March, 2026 [Page 10]
Internet-Draft SRv6 DOP September 2025
2 1 2 1 3
P------P------P------P------P------P------PE
/ | \ / | | \ / | | \ / | \ / | \
/ | \/ | | \/ | | \/ | \/ | \
CE1--PE | /\ | | /\ | | /\ | /\ | CE2
\ | / \ | | / \ | | / \ | / \ | /
\ |/ \| |/ \| |/ \|/ \| /
P------P------P------P------P------P------PE
AS1 AS2 AS3
Figure 4: SRv6 Protection Deployment and Networking
Protection includes path protection, intermediate node protection,
and service protection, which require different deployment
strategies based on their locations. Protection strategies vary for
nodes at different locations: for instance, location 1 involves
inter-domain link protection, location 2 intra-domain link
protection, and location 3 tail node protection.
The selection of path protection strategies also requires
consideration of factors such as network architecture, service
requirements, resource constraints, and operation expenditure.
DOP-7 SRv6 provides diverse protection mechanisms, but selecting
optimal solutions for specific applications remains challenging,
especially when coordinating multiple coexisting mechanisms
effectively.
7. Challenges of Different Network Types
SRv6 deployment faces various challenges across different network
environments, including not only carrier networks but also data
centers and campus networks. Due to the diversity of network
architectures, traffic patterns, and legacy protocol dependencies,
it is difficult to apply a single deployment guideline that meets
the unique requirements of each environment.
7.1. Data Center Networks
In large-scale data centers, which commonly adopt Clos (Spine-Leaf)
architectures, SRv6 introduces specific challenges:
The architecture relies heavily on Equal-Cost Multi-Path (ECMP)
forwarding for traffic balance. SRv6 traffic steering mechanisms,
Liu, et al. Expires March, 2026 [Page 11]
Internet-Draft SRv6 DOP September 2025
such as explicit path control or policy-based routing, must be
compatible with ECMP to avoid uneven traffic distribution.
Data centers typically have strict latency and throughput
requirements. The SRv6 header overhead may impact overall
performance and reduce effective MTU, especially in scenarios with
high-throughput workloads.
Given the massive scale of data centers, there is a strong
requirement for automatic SRv6 deployment, streamlined service
provisioning, and simplified OAM, to reduce configuration errors
and operational burdens.
7.2. Campus Networks
Campus networks present another set of SRv6 deployment challenges,
largely driven by the coexistence with traditional technologies and
operational constraints:
Existing campus networks often rely on legacy protocols such as
OSPF, VLAN, or other Layer 2 technologies. Integrating SRv6
requires careful consideration of protocol migration strategies or
long-term coexistence mechanisms.
Many campus edge devices and terminals are still IPv4-only,
leading to issues during the IPv4-to-IPv6 transition. SRv6
deployment must accommodate dual-stack operation or translation
mechanisms.
SRv6 introduces source routing capabilities, which, if improperly
secured, can become new attack surfaces. Enhanced security
mechanisms, such as policy validation and access control, are
essential.
Similar to data centers, automated deployment and monitoring tools
are needed to reduce manual intervention, simplify SRv6
operations, and improve service assurance in campus environments.
For instance, in the power grid, SRv6 is expected to provide Quality
of Service (QoS) guarantees, performance optimization, and other
Liu, et al. Expires March, 2026 [Page 12]
Internet-Draft SRv6 DOP September 2025
specialized features to meet stringent reliability and determinism
requirements based on the characteristics of power applications.
DOP-8 It is difficult to apply a single deployment guideline to meet
the diverse SRv6 requirements of different network types.
Data centers and campus networks each introduce unique constraints,
such as ECMP compatibility, performance sensitivity, legacy protocol
coordination, IPv4/IPv6 transition, and operational security, all of
which must be carefully addressed to enable successful SRv6
adoption.
8. Security Considerations
This document does not introduce additional security concerns. It
does not change the security properties of SRv6. For general SRv6
security considerations, see [I-D.ietf-spring-srv6-security].
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017
[RFC4364] E. Rosen and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006
[I-D.liu-srv6ops-sid-address-assignment] Y. Liu and Y. Zhu, "IPv6
Address Assignment for SRv6", Expired, Internet-Draft,
draft-liu-srv6ops-sid-address-assignment-01, 25 February
2025, <https://datatracker.ietf.org/doc/html/draft-liu-
srv6ops-sid-address-assignment-01>.
[I-D.geng-srv6ops-traffic-steering-to-srv6] G. Geng, Y. Liu, C. Xie
and C. Lin, "Best practices for traffic steering to SRv6",
Expired, Internet-Draft, draft-geng-srv6ops-traffic-
steering-to-srv6-00, 4 March 2024,
<https://datatracker.ietf.org/doc/html/draft-geng-srv6ops-
traffic-steering-to-srv6-00>.
Liu, et al. Expires March, 2026 [Page 13]
Internet-Draft SRv6 DOP September 2025
[I-D.liu-srv6ops-sr-protection] Y. Liu, W. Jiang, C. Lin, X. Geng
and Y. Liu, "Operational Guidance for Protection
mechanisms in SRv6 Networks", Work in Progress, Internet-
Draft, draft-liu-srv6ops-sr-protection-03, 20 March 2025,
<https://datatracker.ietf.org/doc/html/draft-liu-srv6ops-
sr-protection-03>.
[I-D.ietf-spring-srv6-security] N. Buraglio, T. Mizrahi, T. Tong, L.
M. Contreras and F. Gont, "Segment Routing IPv6 Security
Considerations", Work in Progress, Internet-Draft, draft-
ietf-spring-srv6-security-07, 18 September 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
srv6-security-07>.
9.2. Informative References
[I-D.ietf-spring-srv6-mpls-interworking] S. Agrawal, C. Filsfils, D.
Voyer, G. Dawra, Z. Li and S. Hegde, "SRv6 and MPLS
interworking", Work in Progress, Internet-Draft, draft-
ietf-spring-srv6-mpls-interworking-01, 7 July 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
srv6-mpls-interworking-01>.
10. Appendix: Possible Missing DOPs for Future Consideration
The following are potential SRv6-specific operational challenges
(DOPs) that are currently not covered in the main sections, but may
be important for future study and discussion:
DOP-X1: Compression-related operational issues: Header compression
(e.g., NEXT-CSID/REPLACE-CSID) introduces challenges in parsing,
interoperability, and troubleshooting.
DOP-X2: Operational issues related to network programmability:
Programmable SRv6 behaviors increase complexity in validation,
consistency, and rollback.
DOP-X3: SID structure and management issues: Ambiguities in
locator/function/arguments structure affect policy enforcement,
summarization, and domain boundary handling.
Liu, et al. Expires March, 2026 [Page 14]
Internet-Draft SRv6 DOP September 2025
DOP-X4: SRv6-specific control plane issues: Includes SRv6 SID
advertisement errors, SR Policy lifecycle handling, and multi-
vendor feature inconsistencies.
DOP-X5: IPv6 fragmentation handling: SRv6 header size may cause
MTU issues, requiring additional operational methods for
fragmentation detection and mitigation.
DOP-X6: Route summarization trade-offs: Locator-based
summarization may impact visibility, path granularity, and fault
localization.
DOP-X7: Common DOPs shared with SR-MPLS (out of scope): Includes
controller interaction issues, multiple SBI management, and
general SR deployment policies.
Liu, et al. Expires March, 2026 [Page 15]
Internet-Draft SRv6 DOP September 2025
Contributors
Daniel Voyer
Bell Canada
Email: Danvoyer@gmail.com
Linjian Song
Alibaba, Inc
Email: linjian.slj@alibaba-inc.com
Satoru Matsushima
SoftBank
Email: satoru.matsushima@g.softbank.co.jp
Chongfeng Xie
China Telecom
Email: xiechf@chinatelecom.cn
Xinxin Yi
China Unicom
Email: yixx3@chinaunicom.cn
Liu, et al. Expires March, 2026 [Page 16]
Internet-Draft SRv6 DOP September 2025
Authors' Addresses
Yisong Liu
China Mobile
Email: liuyisong@chinamobile.com
Thomas Graf
Swisscom
Email: Thomas.Graf@swisscom.com
Zoltan Miklos
MTN
Email: Zoltan.Miklos@mtn.com
Luis Contreras
Telefonica
Email: luismiguel.contrerasmurillo@telefonica.com
Nicolai Leymann
Deutsche Telekom
Email: N.Leymann@telekom.de
Liu, et al. Expires March, 2026 [Page 17]