Internet DRAFT - draft-zhou-srv6ops-am-deployment-status

draft-zhou-srv6ops-am-deployment-status







srv6ops                                                          T. Zhou
Internet-Draft                                                     Z. Li
Intended status: Informational                                    Huawei
Expires: 5 September 2024                                   4 March 2024


         Alternate Marking Deployment Status and Considerations
               draft-zhou-srv6ops-am-deployment-status-00

Abstract

   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.

Requirements Language

   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 RFC 2119 [RFC2119].

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).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on 5 September 2024.

Copyright Notice

   Copyright (c) 2024 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 (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.



Zhou & Li               Expires 5 September 2024                [Page 1]

Internet-Draft            AM Deployment Status                March 2024


   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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Deployment Status . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  China Mobile Guangdong  . . . . . . . . . . . . . . . . .   3
     2.2.  China Mobile Guizhou  . . . . . . . . . . . . . . . . . .   3
     2.3.  China Unicom Beijing  . . . . . . . . . . . . . . . . . .   3
     2.4.  South Africa MTN  . . . . . . . . . . . . . . . . . . . .   3
     2.5.  Bahrain STC . . . . . . . . . . . . . . . . . . . . . . .   3
     2.6.  Guangdong e-Government Network  . . . . . . . . . . . . .   4
     2.7.  Industrial and Commercial Bank of China . . . . . . . . .   4
   3.  Deployment Cases  . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Mobile Transport Network  . . . . . . . . . . . . . . . .   4
     3.2.  Private Line Service for Cloud Access . . . . . . . . . .   5
     3.3.  Financial WAN . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Deployment Considerations . . . . . . . . . . . . . . . . . .   6
     4.1.  Tunneling Support . . . . . . . . . . . . . . . . . . . .   6
     4.2.  Deployment Automation . . . . . . . . . . . . . . . . . .   6
     4.3.  Capability Discovery  . . . . . . . . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   The Alternate Marking [RFC9341] and Multipoint Alternate Marking
   [RFC9342]define the Alternate Marking technique that is a hybrid
   performance measurement method, per RFC7799 [RFC7799] 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.

   The IPv6 AltMark Option [RFC9343] 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.





Zhou & Li               Expires 5 September 2024                [Page 2]

Internet-Draft            AM Deployment Status                March 2024


   While the IPv6 AltMark Option implements the basic alternate marking
   methodology, the Enhanced Alternate Marking [RFC9343] defines
   extended data fields for the AltMark Option and provides enhanced
   capabilities to overcome some challenges and enable future proof
   applications.

   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.

2.  Deployment Status


2.1.  China Mobile Guangdong

   Scenario: Root cause analysis for 5G, when the access speed is not
   qualifed.

   Data Plane: MPLS.

2.2.  China Mobile Guizhou

   Scenario: Realtime error detection for key areas.

   Data Plane: MPLS.

2.3.  China Unicom Beijing

   Scenario: Service assurance for the private converged transport
   network for 2022 Winter Olympics in Beijing.

   Data Plane: MPLS.

2.4.  South Africa MTN

   Scenario: Fault location for mobile transport network from base
   station to mobile core network.

   Data Plane: IPv6.

2.5.  Bahrain STC

   Scenario: Service assurance for mobile transport network.

   Data Plane: IPv6.




Zhou & Li               Expires 5 September 2024                [Page 3]

Internet-Draft            AM Deployment Status                March 2024


2.6.  Guangdong e-Government Network

   Scenario: Service assurance for online services and datacenter
   interconnection.

   Data Plane: IPv6.

2.7.  Industrial and Commercial Bank of China

   Scenario: Service assurance for campus private WAN.

   Data Plane: IPv6.

3.  Deployment Cases


3.1.  Mobile Transport Network

   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&M efficiency.

   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:

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

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

   *  Based on the real-time performance data of base stations across
      the entire network, a big data-based intelligent O&M system can be
      constructed to implement high-precision SLA awareness in real time



Zhou & Li               Expires 5 September 2024                [Page 4]

Internet-Draft            AM Deployment Status                March 2024


      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&M.

3.2.  Private Line Service for Cloud Access

   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.

   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&M.  This solution offers the following
   benefits:

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

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

   *  Implements E2E multi-dimensional exception identification, network
      health visualization, intelligent fault diagnosis, and fault self-
      healing in a closed-loop manner.

3.3.  Financial WAN

   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.

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



Zhou & Li               Expires 5 September 2024                [Page 5]

Internet-Draft            AM Deployment Status                March 2024


   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:

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

   *  One core controller is deployed to perform centralized O&M for the
      entire financial WAN and implement the E2E management and
      scheduling.

4.  Deployment Considerations

   Based on the Alternate Marking deployment collected in section 2,
   this section describes some operational considerations.

4.1.  Tunneling Support

   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.

4.2.  Deployment Automation

   Standard approaches that automate the function configuration could
   either be deployed in a centralized fashion or a distributed fashion.
   The draft [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.
   [I-D.ietf-pce-pcep-ifit] defines extensions to PCEP to configure SR
   policies for Alternate Marking.  [I-D.ietf-idr-sr-policy-ifit]
   defines extensions to BGP for the same purpose.  In the future, other



Zhou & Li               Expires 5 September 2024                [Page 6]

Internet-Draft            AM Deployment Status                March 2024


   approaches for hardware and software-based functions can be
   development to enhance the programmability and flexibility.

4.3.  Capability Discovery

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

5.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

6.  Security Considerations

   TBD

7.  Acknowledgements

   TBD

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC7799]  Morton, A., "Active and Passive Metrics and Methods (with
              Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
              May 2016, <https://www.rfc-editor.org/info/rfc7799>.




Zhou & Li               Expires 5 September 2024                [Page 7]

Internet-Draft            AM Deployment Status                March 2024


   [RFC9341]  Fioccola, G., Ed., Cociglio, M., Mirsky, G., Mizrahi, T.,
              and T. Zhou, "Alternate-Marking Method", RFC 9341,
              DOI 10.17487/RFC9341, December 2022,
              <https://www.rfc-editor.org/info/rfc9341>.

   [RFC9342]  Fioccola, G., Ed., Cociglio, M., Sapio, A., Sisto, R., and
              T. Zhou, "Clustered Alternate-Marking Method", RFC 9342,
              DOI 10.17487/RFC9342, December 2022,
              <https://www.rfc-editor.org/info/rfc9342>.

   [RFC9343]  Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R.
              Pang, "IPv6 Application of the Alternate-Marking Method",
              RFC 9343, DOI 10.17487/RFC9343, December 2022,
              <https://www.rfc-editor.org/info/rfc9343>.

8.2.  Informative References

   [I-D.ietf-idr-bgp-ifit-capabilities]
              Fioccola, G., Pang, R., Wang, S., Decraene, B., Zhuang,
              S., and H. Wang, "Advertising In-situ Flow Information
              Telemetry (IFIT) Capabilities in BGP", Work in Progress,
              Internet-Draft, draft-ietf-idr-bgp-ifit-capabilities-04,
              11 January 2024, <https://datatracker.ietf.org/doc/html/
              draft-ietf-idr-bgp-ifit-capabilities-04>.

   [I-D.ietf-idr-sr-policy-ifit]
              Qin, F., Yuan, H., Yang, S., Zhou, T., and G. Fioccola,
              "BGP SR Policy Extensions to Enable IFIT", Work in
              Progress, Internet-Draft, draft-ietf-idr-sr-policy-ifit-
              07, 20 October 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-
              policy-ifit-07>.

   [I-D.ietf-pce-pcep-ifit]
              Yuan, H., 王雪荣, Yang, P., Li, W., and G. Fioccola, "Path
              Computation Element Communication Protocol (PCEP)
              Extensions to Enable IFIT", Work in Progress, Internet-
              Draft, draft-ietf-pce-pcep-ifit-04, 8 January 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-pce-
              pcep-ifit-04>.

   [I-D.ydt-ippm-alt-mark-yang]
              Graf, T., Wang, M., Fioccola, G., Zhou, T., Min, X., Jun,
              G., Nilo, M., and L. Han, "A YANG Data Model for the
              Alternate Marking Method", Work in Progress, Internet-
              Draft, draft-ydt-ippm-alt-mark-yang-00, 29 February 2024,
              <https://datatracker.ietf.org/doc/html/draft-ydt-ippm-alt-
              mark-yang-00>.



Zhou & Li               Expires 5 September 2024                [Page 8]

Internet-Draft            AM Deployment Status                March 2024


Authors' Addresses

   Tianran Zhou
   Huawei
   156 Beiqing Rd.
   Beijing
   100095
   China
   Email: zhoutianran@huawei.com


   Zhenbin Li
   Huawei
   156 Beiqing Rd.
   Beijing
   100095
   China
   Email: lizhenbin@huawei.com

































Zhou & Li               Expires 5 September 2024                [Page 9]