<?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="info" docName="draft-zhou-srv6ops-am-deployment-status-00"
     ipr="trust200902">
  <front>
    <title abbrev="AM Deployment Status">Alternate Marking Deployment Status
    and Considerations</title>

    <author fullname="Tianran Zhou" initials="T." surname="Zhou">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>156 Beiqing Rd.</street>

          <city>Beijing</city>

          <code>100095</code>

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

        <email>zhoutianran@huawei.com</email>
      </address>
    </author>

    <author fullname="Zhenbin Li" initials="Z." surname="Li">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>156 Beiqing Rd.</street>

          <city>Beijing</city>

          <code>100095</code>

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

        <email>lizhenbin@huawei.com</email>
      </address>
    </author>

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

    <area>OPS Area</area>

    <workgroup>srv6ops</workgroup>

    <abstract>
      <t>Operators have started the deployment of Alternate Marking in their
      networks for different scenarios. This document introduces several
      deployment cases of Alternate Marking in operator networks. Some
      considerations about the Alternate Marking deployments are also
      collected.</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>The <xref target="RFC9341">Alternate Marking</xref> and <xref
      target="RFC9342">Multipoint Alternate Marking</xref>define the Alternate
      Marking technique that is a hybrid performance measurement method, per
      <xref target="RFC7799">RFC7799</xref> classification of measurement
      methods. This method is based on marking consecutive batches of packets
      and it can be used to measure packet loss, latency, and jitter on live
      traffic.</t>

      <t>The <xref target="RFC9343">IPv6 AltMark Option</xref> applies the
      Alternate Marking Method to IPv6, and defines an Extension Header Option
      to encode the Alternate Marking Method for both the Hop-by-Hop Options
      Header and the Destination Options Header.</t>

      <t>While the IPv6 AltMark Option implements the basic alternate marking
      methodology, the <xref target="RFC9343">Enhanced Alternate
      Marking</xref> defines extended data fields for the AltMark Option and
      provides enhanced capabilities to overcome some challenges and enable
      future proof applications.</t>

      <t>Operators have started the deployment of Alternate Marking in their
      networks for different scenarios. This document introduces several
      deployment cases of Alternate Marking in operator networks. Some
      considerations about the Alternate Marking deployments are also
      collected.</t>
    </section>

    <section title="Deployment Status">
      <t/>

      <section title="China Mobile Guangdong">
        <t>Scenario: Root cause analysis for 5G, when the access speed is not
        qualifed.</t>

        <t>Data Plane: MPLS.</t>
      </section>

      <section title="China Mobile Guizhou">
        <t>Scenario: Realtime error detection for key areas.</t>

        <t>Data Plane: MPLS.</t>
      </section>

      <section title="China Unicom Beijing">
        <t>Scenario: Service assurance for the private converged transport
        network for 2022 Winter Olympics in Beijing.</t>

        <t>Data Plane: MPLS.</t>
      </section>

      <section title="South Africa MTN">
        <t>Scenario: Fault location for mobile transport network from base
        station to mobile core network.</t>

        <t>Data Plane: IPv6.</t>
      </section>

      <section title="Bahrain STC">
        <t>Scenario: Service assurance for mobile transport network.</t>

        <t>Data Plane: IPv6.</t>
      </section>

      <section title="Guangdong e-Government Network">
        <t>Scenario: Service assurance for online services and datacenter
        interconnection.</t>

        <t>Data Plane: IPv6.</t>
      </section>

      <section title="Industrial and Commercial Bank of China">
        <t>Scenario: Service assurance for campus private WAN.</t>

        <t>Data Plane: IPv6.</t>
      </section>
    </section>

    <section title="Deployment Cases">
      <t/>

      <section title="Mobile Transport Network ">
        <t>The mobile transport network is a large-scale network. It has
        various access modes and carries various mobile transport services
        (such as high definition video) that pose higher requirements on link
        connectivity and performance. Alternate Marking is deployed to quickly
        demarcates and locates faults and replays faults on demand, improving
        SLA experience and O&amp;M efficiency.</t>

        <t>In this scenario, edge-to-edge performance measurement is performed
        firstly. The hop-by-hop measurement is triggered when the base station
        flow performance degrades to the pre-defined threshold. The controller
        summarizes the reported hop-by-hop measurement data for path
        restoration and fault locating. This solution offers the following
        benefits:</t>

        <t><list style="symbols">
            <t>Detailed performance data of service flows can be monitored
            from different dimensions, such as base station flows, data flows,
            and signaling flows. In addition, this solution supports
            clustering to process base station flow faults and quickly
            demarcate poor-quality services, preventing multiple faults of
            numerous base station flows from triggering a lot of per hop
            measurements.</t>

            <t>If a fault occurs outside the transport network, this solution
            can quickly and accurately prove that the fault is not due to the
            network. If a fault occurs within the transport network, this
            solution can quickly locate the faulty network element or link,
            improving network operation efficiency.</t>

            <t>Based on the real-time performance data of base stations across
            the entire network, a big data-based intelligent O&amp;M system
            can be constructed to implement high-precision SLA awareness in
            real time and multi-dimensional visualization for base station
            services. It can also analyze and evaluate potential network
            risks, and optimize network resources to implement automatic and
            intelligent O&amp;M.</t>
          </list></t>
      </section>

      <section title="Private Line Service for Cloud Access">
        <t>Enterprises use private line to access cloud services. The wide
        coverage of the mobile transport network can provide the cloud access
        service more conveniently. E2E collaborative management can facilitate
        the network deployment, operations.</t>

        <t>Alternate Marking can apply to VPN service analysis and assurance
        for the cloud access, including site-to-site private line,
        site-to-cloud private line, and cloud interconnection scenarios.
        Alternate Marking ensures E2E high reliability and implements
        minute-level fault locating through visualized O&amp;M. This solution
        offers the following benefits:</t>

        <t><list style="symbols">
            <t>Analyzes and locates faults of a VPN flow and queries the E2E
            performance of the VPN service flow by granularity ranging from
            year to minute, including the maximum traffic rate, maximum
            one-way delay, and maximum packet loss rate.</t>

            <t>Queries E2E VPN service information based on the VPN name, VPN
            type, and service status. If multiple segments of service flows
            exist, the status value of the segment with the lowest quality is
            used.</t>

            <t>Implements E2E multi-dimensional exception identification,
            network health visualization, intelligent fault diagnosis, and
            fault self-healing in a closed-loop manner.</t>
          </list></t>
      </section>

      <section title="Financial WAN">
        <t>In the financial industry, tier-2 banks, branches, subsidiaries,
        and external organizations first connect to tier-1 banks, which
        aggregate service traffic and then connect to the bank core network to
        implement mutual access between them and the head office data center.
        In this case, the concept of centralized management for finacial WAN
        is of particular importance.</t>

        <t>By using SRv6 technology, the financial WAN can quickly and easily
        establish basic network connections between the cloud and various
        access points, ensuring efficient service provisioning. In terms of
        O&amp;M capabilities, the financial industry has high requirements on
        the SLA assurance. So the financial WAN faces higher requirements due
        to the diverse array of branch service types brought about by the
        development of banking services. For example, in addition to
        traditional production and office services, other services such as
        security protection, IoT, and public cloud services are now prevalent.
        In this scenario, Alternate Marking can apply to tunnels. And this
        solution offers the following benefits:</t>

        <t><list style="symbols">
            <t>In SRv6 scenarios, tunnel-level Alternate Marking can apply to
            measure the quality of each SRv6 segment list and select the
            optimal path. The path currently in use is periodically compared
            with the optimal path, implementing intelligent traffic
            steering.</t>

            <t>One core controller is deployed to perform centralized O&amp;M
            for the entire financial WAN and implement the E2E management and
            scheduling.</t>
          </list></t>
      </section>
    </section>

    <section title="Deployment Considerations">
      <t>Based on the Alternate Marking deployment collected in section 2,
      this section describes some operational considerations.</t>

      <section title="Tunneling Support">
        <t>In carrier networks, it is common for user traffic to traverse
        various tunnels for QoS, traffic engineering, or security. Both the
        uniform mode and the pipe mode for tunnel support are required. The
        uniform mode treats the nodes in a tunnel uniformly as the nodes
        outside of the tunnel on a path. In contrast, the pipe mode abstracts
        all the nodes between the tunnel ingress and egress as a circuit so no
        nodes in the tunnel is visible to the nodes outside of the tunnel.
        With such flexibility, the operator can either gain a true end-to-end
        visibility or apply a hierarchical approach which isolates the
        monitoring domain between customer and provider.</t>
      </section>

      <section title="Deployment Automation">
        <t>Standard approaches that automate the function configuration could
        either be deployed in a centralized fashion or a distributed fashion.
        The draft <xref target="I-D.ydt-ippm-alt-mark-yang"/> provides a YANG
        model for Alternate Marking configuration. It is also helpful to
        provide standards-based approaches for configuration in various
        network environments. For example, in Segment Routing (SR) networks,
        extensions to BGP or Path Computation Element Communication Protocol
        (PCEP) can be defined to distribute SR policies with Alternate Marking
        information, so that telemetry behavior can be enabled automatically
        when the SR policy is applied. <xref target="I-D.ietf-pce-pcep-ifit"/>
        defines extensions to PCEP to configure SR policies for Alternate
        Marking. <xref target="I-D.ietf-idr-sr-policy-ifit"/> defines
        extensions to BGP for the same purpose. In the future, other
        approaches for hardware and software-based functions can be
        development to enhance the programmability and flexibility.</t>
      </section>

      <section title="Capability Discovery">
        <t>The Alternate Marking Method MUST be deployed in a controlled
        domain for security and compatibility reasons. Before adding the
        alternate marking information, the marking node must know if there is
        an unmarking node when the flow goes out the controlled domain.
        Otherwise, the alternate marking information will leak to other domain
        and cause potential damage. <xref
        target="I-D.ietf-idr-bgp-ifit-capabilities"/> defines a new BGP Router
        Capability Code to advertise the Alternate Marking capabilities.
        Within an Alternate Marking deployment domain, capability
        advertisement from the tail node to the head node assists the head
        node to determine whether the Alternate Marking Option can be
        encapsulated in data packets. Such advertisement helps mitigating the
        leakage threat and facilitating the deployment of Alternate Marking on
        a per-service and on-demand basis.</t>
      </section>
    </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>TBD</t>
    </section>

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

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

      <?rfc include="reference.RFC.9341"?>

      <?rfc include="reference.RFC.9342"?>

      <?rfc include="reference.RFC.9343"?>

      <?rfc include="reference.RFC.7799"?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.I-D.ydt-ippm-alt-mark-yang'?>

      <?rfc include='reference.I-D.ietf-pce-pcep-ifit'?>

      <?rfc include='reference.I-D.ietf-idr-sr-policy-ifit'?>

      <?rfc include='reference.I-D.ietf-idr-bgp-ifit-capabilities'?>
    </references>
  </back>
</rfc>
