<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" docName="draft-liu-srv6ops-problem-summary-05" category="info" ipr="trust200902" obsoletes="" updates="" xml:lang="en" symRefs="true" sortRefs="true" tocInclude="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.28.1 -->
  <!-- Generated by id2xml 1.5.2 on 2025-05-07T07:50:53Z -->
    <front>
    <title abbrev="SRv6 Deployment and Operation Problem Su">SRv6 Deployment and Operation Problem Summary</title>
    <seriesInfo name="Internet-Draft" value="draft-liu-srv6ops-problem-summary-05"/>
    <author initials="Y." surname="Liu" fullname="Yisong Liu">
      <organization>China Mobile</organization>
      <address>
      <email>liuyisong@chinamobile.com</email>
      </address>
    </author>

    <author initials="D." surname="Voyer" fullname="Daniel Voyer">
      <organization>Bell Canada</organization>
      <address>
      <email>Danvoyer@gmail.com</email>
      </address>
    </author>

    <author initials="T." surname="Graf" fullname="Thomas Graf">
      <organization>Swisscom</organization>
    <address>
      <email>Thomas.Graf@swisscom.com</email>
      </address>
    </author>
    <author initials="Z." surname="Miklos" fullname="Zoltan Miklos">
      <organization>MTN</organization>
    <address>
      <email>Zoltan.Miklos@mtn.com</email>
      </address>
    </author>
    <author initials="L." surname="Contreras" fullname="Luis Contreras">
      <organization>Telefonica</organization>
     <address>
     <email>luismiguel.contrerasmurillo@telefonica.com</email>
      </address>
    </author>

    <author initials="N." surname="Leymann" fullname="Nicolai Leymann">
      <organization>Deutsche Telekom</organization>
      <address>
      <email>N.Leymann@telekom.de</email>
      </address>
    </author>
    <author initials="L." surname="Song" fullname="Linjian Song">
      <organization>Alibaba, Inc</organization>
      <address>
      <email>linjian.slj@alibaba-inc.com</email>
      </address>
    </author>
    <author initials="S." surname="Matsushima" fullname="Satoru Matsushima">
      <organization>SoftBank</organization>
      <address>
      <email>satoru.matsushima@g.softbank.co.jp</email>
      </address>
    </author>
    <author initials="C." surname="Xie" fullname="Chongfeng Xie">
      <organization>China Telecom</organization>
       <address>
       <email>xiechf@chinatelecom.cn</email>
       </address>
    </author>
    <author initials="X." surname="Yi" fullname="Xinxin Yi">
      <organization>China Unicom</organization>
      <address>
       <email>yixx3@chinaunicom.cn</email>
      </address>
    </author>
    <date year="2025" month="May" day="6"/>
    <abstract>
      <t>
   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.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="sect-1" numbered="true" toc="default">
      <name>Introduction</name>
      <t>
   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.</t>
      <t>
   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
   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.</t>
      <t>
   This document identifies a number of Deployment and Operation
   Problems (DOPs) that require additional work within IETF.</t>
      <section anchor="sect-1.1" numbered="true" toc="default">
        <name>Requirements Language</name>
        <t>
   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 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/> when, and only when, they appear in all
   capitals, as shown here.</t>
      </section>
    </section>
    <section anchor="sect-2" numbered="true" toc="default">
      <name>SRv6 Upgrade and Evolution</name>
      <t>
   In the evolution from non-SRV6 networks to SRv6 networks, the
   upgrade from MPLS to SRv6 represents the most typical and common
   scenario, which requires consideration of two cases:</t>
      <t>
   For SRv6 and MPLS coexistence, a smooth transition from an MPLS
   network to an SRv6 network is required, avoiding service
   interruptions. 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, remove the MPLS tunnel.</t>
      <t>
   For SRv6 and MPLS integration, the legacy MPLS network and the newly
   established SRv6 network coexist, ensuring intercommunication
   between the two networks. For instance, configure route regeneration
   and route re-advertisement functions between two address families
   (EVPN, VPN) on edge nodes.</t>
      <t>
   In some cases, SRv6 needs to traverse third-party networks that may
   not natively support SRv6 even IPv6. One of the possible methods is
   to establish tunnels between nodes that support SRv6, and create
   SRv6 BE (Bandwidth Engineering) or SRv6 TE (Traffic Engineering)
   Policy across the tunnels as overlay network.</t>
      <t>
   While traditional inter-domain implementations in service provider
   networks often rely on MPLS and leverage Option A. Option A approach
   has scalability limitations and presents relatively higher
   complexity in both deployment and maintenance. The ASBR needs to
   manage the routing of all VPNs and create VPN instances for each
   VPN.  At the same time, it requests associating separate interfaces
   and corresponding VLANs for each inter-domain VPN. SRv6 presents an
   alternative approach with E2E inter-domain solution, potentially
   leading to simplification and improved scalability. SRv6 naturally
   support end-to-end inter-domain by utilizing IPv6 route reachability
   and IPv6 route aggregation reduces the number of SRv6 locators
   distribution for inter-domain deployment.</t>
      <t>
   DOP-1 Upgrading (migration) from existing MPLS networks to SRv6, how
   to ensure interoperability, simplify deployment complexity, minimize
   network disruption, and maintain existing services with minimal
   impact.</t>
    </section>
    <section anchor="sect-3" numbered="true" toc="default">
      <name>SRv6 Network Visualization</name>
      <t>
   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 the effectiveness of
   such analysis, particularly for service chain validation, predictive
   traffic engineering, and microsecond-level performance
   troubleshooting in SRv6 deployments and operations.</t>
      <t>
   DOP-2 The collection of SRv6 network data is incomplete and
   inefficient, making it challenging to visualize the information
   effectively.</t>
      <t>
   Network data is collected through multiple channels such as BMP,
   IPFIX, and YANG push, but the lack of correlation among these
   datasets hinders effective network performance analysis and
   optimization. While various techniques can be applied to utilize the
   collected data for SRv6 network analysis and performance
   optimization (particularly for traffic engineering) once it's
   gathered in defined formats, current limitations result in delayed
   fault detection and recovery, as well as inconsistencies between
   traffic patterns and routing behaviors. Furthermore, the diversity
   of applicable data models for SRv6 creates integration challenges,
   compounded by the absence of effective methods to interpret and
   present data using existing models.</t>
      <t>
   DOP-3 Multi-source network data (BMP/IPFIX/YANG etc.) lacks
   correlation and model integration, hindering SRv6 performance
   analysis and causing delayed fault detection and recovery etc.
   challenges.</t>
    </section>
    <section anchor="sect-4" numbered="true" toc="default">
      <name>SRv6 Address Planning</name>
      <t>
   Existing IPv6 address planning approach ensures efficient address
   utilization and simplifies network management for IPv6 netowrk,
   which can't satisfy the SRv6 SID planning for service provider,
   especially considering the complexities introduced by advanced
   features like SRv6 compression. The allocation of SRv6 SID blocks
   should be strategically planned by holistically considering
   administrative division management and route aggregation
   requirements, while the distribution of NodeID and function segments
   needs to balance administrative convenience with optimal address
   space utilization based on the SRv6 SID structure. Some initial work
   could refer to <xref target="I-D.liu-srv6ops-sid-address-assignment" format="default"/>. In summary:</t>
      <t>
   DOP-4 Traditional IPv6 address planning proves inadequate for SRv6
   due to its SID structure, which introduces additional complexity in
   IPv6 architecture and complicates network planning.</t>
      <t>
   DOP-5 In inter-domain scenarios, SRv6 address allocation may cause
   address space wastage, prevent route aggregation, and fail to ensure
   compression efficiency.</t>
    </section>
    <section anchor="sect-5" numbered="true" toc="default">
      <name>Traffic steering to SRv6</name>
      <t>
   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. There are various SRv6 traffic steering
   methods, each with its own unique advantages and challenges. It is
   essential to choose the appropriate traffic steering method to SRv6
   based on specific application scenarios to ensure efficient
   operation. Some initial work could refer to <xref target="I-D.geng-srv6ops-traffic-steering-to-srv6" format="default"/>. In summary:</t>
      <t>
   DOP-6 There are various methods for SRv6 traffic steering, making it
   difficult to select the appropriate method for different scenarios,
   leading to deployment complexity.</t>
    </section>
    <section anchor="sect-6" numbered="true" toc="default">
      <name>Deployment Practice for SRv6 Protection</name>
      <t>
   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.</t>
      <t>
   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.</t>
      <t>
   SRv6 offers multiple protection mechanisms, with different
   applications requiring different protection needs. 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 <xref target="I-D.liu-srv6ops-sr-protection" format="default"/>.</t>
      <t>
   DOP-7 SRv6 provides diverse protection mechanisms, but selecting
   optimal solutions for specific applications remains challenging,
   especially when coordinating multiple coexisting mechanisms
   effectively.</t>
    </section>
    <section anchor="sect-7" numbered="true" toc="default">
      <name>Challenges of Different Network Types</name>
      <t>
   SRv6 deployment faces various challenges across different network
   environments, including not only carrier networks but also data
   centers and campus networks. Specifically, clos (Spine-Leaf)
   architecture of data center requires SRv6 path control (e.g.,
   explicit paths) compatible with ECMP to ensure traffic balance,
   while addressing performance impacts from SRv6 overhead and enabling
   automated large-scale deployment. Campus networks require SRv6
   integration with legacy protocols (e.g., OSPF/VLAN), IPv4-IPv6
   transition support, enhanced security for source routing risks, and
   automated deployment to reduce operational complexity.</t>
      <t>
   For instance, in the power grid, SRv6 is supposed to provide Quality
   of Service (QoS) guarantees, performance optimization, and other
   specialized features to meet specific demands based on the power
   application scenario.</t>
      <t>
   DOP-8 It is difficult to apply a single deployment guideline to meet
   the diverse SRv6 requirements of different network types.</t>
    </section>
    <section anchor="sect-8" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
   TBD.</t>
    </section>
    <section anchor="sect-9" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
   TBD</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="I-D.liu-srv6ops-sid-address-assignment" target="https://datatracker.ietf.org/doc/html/draft-liu-srv6ops-sid-address-assignment-01" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.liu-srv6ops-sid-address-assignment.xml">
          <front>
            <title>IPv6 Address Assignment for SRv6</title>
            <author fullname="Yisong Liu" initials="Y." surname="Liu">
              <organization>China Mobile</organization>
            </author>
            <author fullname="Yongqing Zhu" initials="Y." surname="Zhu">
              <organization>China Telecom</organization>
            </author>
            <date day="25" month="February" year="2025"/>
            <abstract>
              <t>This document provides detailed SRv6 SID assignment considerations, which could be a comprehensive guide for optimizing SRv6 SID allocation in diverse deployment scenarios.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-liu-srv6ops-sid-address-assignment-01"/>
        </reference>
        <reference anchor="I-D.geng-srv6ops-traffic-steering-to-srv6" target="https://datatracker.ietf.org/doc/html/draft-geng-srv6ops-traffic-steering-to-srv6-00" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.geng-srv6ops-traffic-steering-to-srv6.xml">
          <front>
            <title>Best practices for traffic steering to SRv6</title>
            <author fullname="Gary Geng" initials="G." surname="Geng">
              <organization>Tencent</organization>
            </author>
            <author fullname="Yisong Liu" initials="Y." surname="Liu">
              <organization>China Mobile</organization>
            </author>
            <author fullname="Chongfeng Xie" initials="C." surname="Xie">
              <organization>China Telecom</organization>
            </author>
            <author fullname="Changwang Lin" initials="C." surname="Lin">
              <organization>New H3C Technologies</organization>
            </author>
            <date day="4" month="March" year="2024"/>
            <abstract>
              <t>This document primarily describes the traffic steering towards SRv6- BE and SRv6-TE respectively, providing an overview of the main traffic steering methods for these two approaches. Furthermore, it discusses the recommended traffic steering methods for various typical scenarios.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-geng-srv6ops-traffic-steering-to-srv6-00"/>
        </reference>
        <reference anchor="I-D.liu-srv6ops-sr-protection" target="https://datatracker.ietf.org/doc/html/draft-liu-srv6ops-sr-protection-03" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.liu-srv6ops-sr-protection.xml">
          <front>
            <title>Operational Guidance for Protection mechanisms in SRv6 Networks</title>
            <author fullname="Yao Liu" initials="Y." surname="Liu">
              <organization>China Mobile</organization>
            </author>
            <author fullname="Jiang Wenying" initials="J." surname="Wenying">
              <organization>China Mobile</organization>
            </author>
            <author fullname="Changwang Lin" initials="C." surname="Lin">
              <organization>New H3C Technologies</organization>
            </author>
            <author fullname="Xuesong Geng" initials="X." surname="Geng">
              <organization>Huawei Technologies</organization>
            </author>
            <author fullname="Yisong Liu" initials="Y." surname="Liu">
              <organization>ZTE</organization>
            </author>
            <date day="20" month="March" year="2025"/>
            <abstract>
              <t>This document describes the Operational Guidance for protection of Segment Routing Over IPv6 (SRv6) networks.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-liu-srv6ops-sr-protection-03"/>
        </reference>
      </references>
    </references>
  </back>
</rfc>
