<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="exp" docName="draft-liu-srv6ops-problem-summary-01"
     ipr="trust200902">
  <front>
    <title abbrev="Abbreviated-Title">SRv6 Deployment and Operation Problem
    Summary</title>

    <author fullname="Yisong Liu" initials="Y." surname="Liu">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <code/>

          <country>China</country>
        </postal>

        <email>liuyisong@chinamobile.com</email>
      </address>
    </author>

    <author fullname="Daniel Voyer" initials="D." surname="Voyer">
      <organization>Bell Canada</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <code/>

          <country/>
        </postal>

        <email>daniel.voyer@bell.ca</email>
      </address>
    </author>

    <author fullname="Thomas Graf" initials="T." surname="Graf">
      <organization>Swisscom</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country/>
        </postal>

        <phone/>

        <facsimile/>

        <email>Thomas.Graf@swisscom.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Zoltan Miklos" initials="Z." surname="Miklos">
      <organization>MTN</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country/>
        </postal>

        <phone/>

        <facsimile/>

        <email>Zoltan.Miklos@mtn.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Luis Contreras" initials="L." surname="Contreras">
      <organization>Telefonica</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country/>
        </postal>

        <phone/>

        <facsimile/>

        <email>luismiguel.contrerasmurillo@telefonica.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Nicolai Leymann" initials="N." surname="Leymann">
      <organization>Deutsche Telekom</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country/>
        </postal>

        <phone/>

        <facsimile/>

        <email>N.Leymann@telekom.de</email>

        <uri/>
      </address>
    </author>

    <author fullname="Linjian Song" initials="L." surname="Song">
      <organization>Alibaba, Inc</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country/>
        </postal>

        <phone/>

        <facsimile/>

        <email>linjian.slj@alibaba-inc.com</email>

        <uri/>
      </address>
    </author>


    <author fullname="Satoru Matsushima" initials="S." surname="Matsushima">
      <organization> SoftBank</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country/>
        </postal>

        <phone/>

        <facsimile/>

        <email>satoru.matsushima@g.softbank.co.jp</email>

        <uri/>
      </address>
    </author>

    <author fullname="Chongfeng Xie" initials="C." surname="Xie">
      <organization> China Telecom</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country/>
        </postal>

        <phone/>

        <facsimile/>

        <email>xiechf@chinatelecom.cn</email>

        <uri/>
      </address>
    </author>


    <author fullname="Xinxin Yi" initials="X." surname="Yi">
      <organization> China Unicom</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country/>
        </postal>

        <phone/>

        <facsimile/>

        <email>yixx3@chinaunicom.cn</email>

        <uri/>
      </address>
    </author>

    <author fullname="Weiqiang Cheng" initials="W." surname="Cheng">
      <organization> China Mobile</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country/>
        </postal>

        <phone/>

        <facsimile/>

        <email>chengweiqiang@chinamobile.com</email>

        <uri/>
      </address>
    </author>

    <date day="18" month="March" year="2024"/>

    <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>

    <note title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <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, and enhanced security, its
      deployment and operation come with certain challenges. 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>

    <section title="Simplified Inter-domain Implementation">
      <t>While traditional inter-domain implementations in service provider
      networks often rely on MPLS and leverage Option A. Option A has
      scalability limitations and is complex to deploy and maintain. 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 from the following 2 aspects:
      1) SRv6naturally support end-to-end inter-domain by utilizing IPv6 route
      reachability; 2) IPv6 route aggregation reduces the number of SRv6
      locators distribution for inter-domain deployment. However it requests
      further work to deal with the challenges of SRv6 inter-domain
      deployments including: </t>

      <t>DOP-1 How to deploy SRv6 inter-domain in the existing MPLS network,
      which requires consideration of existing mechanism and potential
      migration strategies.</t>

      <t>DOP-2 Utilizing SRv6 compression techniques in inter-domain scenario
      to further optimize bandwidth usage, which requires effective IPv6
      address planning and block allocation strategies to achieve optimal
      aggregation benefits.</t>

      <t>Also, protocol extension is out of scope and only implementation experience is considered to deal with these challenges. </t>

    </section>

    <section title="SRv6 Data Plane Visualization">
      <t>Network visualization is a critical aspect for service providers,
      especially when implementing new technologies like SRv6. It provides
      essential insights into network traffic flow, resource utilization, and
      potential performance bottlenecks. Visualizing the SRv6 data plane
      requests further work in the aspects described next.</t>

      <section title="Leveraging Existing Frameworks with new parameters">
        <t>The existing IETF work on data collection formats can be leveraged
        for SRv6 data plane visualization. Further work is necessary to define
        SRv6-specific customization information; For example:</t>

        <t>DOP-3 Reuse Telemetry Framework: The telemetry framework, used for
        collecting and transmitting network telemetry data, offers a solid
        foundation. While specific content and parameters need to be defined
        to capture SRv6-specific information relevant for visualization.</t>

        <t>DOP-4 Reuse Netconf/Yang Framework: SRPING already defines the Yang
        Model for protocol extension; for better operation and maintenance of
        SRv6 network, the Yang Model for information collection, status
        notification, failure handling and recovery may also be required.</t>
      </section>

      <section title="Optimizing Network Analysis and Performance">
        <t>Once data is collected from network devices using the defined
        format, several techniques can be employed to utilize this information
        for network analysis and performance optimization for SRv6, especially
        traffic engineering. This brings the need for:</t>

        <t>DOP-5 Identification of techniques for performance optimization in
        operational scenarios.</t>
      </section>
    </section>

    <section title="SRv6 Security Considerations">
      <t>Ongoing advancements in SRv6 security protocols and best practices
      are crucial for maintaining robust security posture in SRv6 deployments.
      Network operators should stay updated with the latest security
      recommendations and implement appropriate security measures to safeguard
      their SRv6 networks. The main method to prevent external traffic from
      exposing and tampering the SRv6 path is to use policy to filter the SRv6
      SID prefix. The detailed solutions could refer to
      draft-liu-spring-srv6-security-experience. Other potential security
      issues are being identified in <xref
      target="I-D.bdmgct-spring-srv6-security"/>, but further work is needed
      to define ways of mitigation. In general terms,it is needed more work
      for:</t>

      <t>DOP-6 Addressing of security considerations in SRv6 operations.</t>
    </section>

    <section title="IPv6 Address Assignment for SRv6">
      <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. Further work is requested including: SRv6 SID Block
      Assignment, SRv6 SID Assignment for P2P and P2MP, SRv6 Node ID
      Assignment, SRv6 Function ID Assignment and so on. Some initial work
      could refer to <xref target="I-D.liu-srv6ops-sid-address-assignment"/>.
      In summary:</t>

      <t>DOP-7 Efficient assignment of addresses and identifiers.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document makes no request of IANA.</t>

      <t>Note to RFC Editor: this section may be removed on publication as an
      RFC.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t/>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t/>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"
?>
    </references>

    <references>
      <?rfc include='reference.I-D.bdmgct-spring-srv6-security'?>

      <?rfc include='reference.I-D.liu-srv6ops-sid-address-assignment'?>
    </references>
  </back>
</rfc>
