IPPM                                                        T. Zhou, Ed.
Internet-Draft                                          G. Fioccola, Ed.
Intended status: Standards Track                                  ZB. Li
Expires: May 3, 2020                                              Huawei
                                                                  S. Lee
                                                                   LG U+
                                                             M. Cociglio
                                                          Telecom Italia
                                                        October 31, 2019

                   Enhanced Alternate Marking Method


   This document defines data fields for the alternate marking with
   enough space.  The main idea is that more information can be
   considered within the alternate marking field to facilitate the
   efficiency and ease the deployment.  The definition aims to be
   general, even if for some protocols there can be dedicated solutions.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   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 May 3, 2020.

Zhou, et al.               Expires May 3, 2020                  [Page 1]

Internet-Draft         enhanced-alternate-marking           October 2019

Copyright Notice

   Copyright (c) 2019 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.  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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Data Fields Format  . . . . . . . . . . . . . . . . . . . . .   3
   3.  Deployment Considerations . . . . . . . . . . . . . . . . . .   4
   4.  Implementing Multipoint Alternate Marking . . . . . . . . . .   5
   5.  Implementation Status . . . . . . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   8.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   6
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   6
     10.2.  Informative References . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   The Alternate Marking [RFC8321] technique is an hybrid performance
   measurement method, per [RFC7799] classification of measurement
   methods.  Because this method is based on marking consecutive batches
   of packets.  It can be used to measure packet loss, latency, and
   jitter on live traffic.

   For the basic Alternate Marking method, bits are needed to record the
   mark.  For some protocols (e.g.  MPLS, BIER, SFC, NVO3) dedicated
   solutions have been presented ([I-D.ietf-mpls-rfc6374-sfl],
   [I-D.ietf-bier-pmmm-oam], [I-D.mirsky-sfc-pmamm],
   [I-D.fmm-nvo3-pm-alt-mark]), but there are ongoing discussions on
   this matter.

   However, in most of the protocols, no additional bit can be used or
   proposed, and that blocks the wide deployment of the alternate

Zhou, et al.               Expires May 3, 2020                  [Page 2]

Internet-Draft         enhanced-alternate-marking           October 2019

   marking technique.  In addition, the basic Alternate Marking method
   is limited with the scalability issue for further extension, i.e,
   more measurements in addition to existing use.

   This document defines data fields for the alternate marking with
   enough space, in particular for PBT (Postcard-based Telemetry).  More
   information can be considered within the alternate marking field to
   facilitate the efficiency and ease the deployment.

   Specifically, the flow identifier is applied as an enhancement for
   the basic Alternate Marking when determining packet loss and packet
   delay measurement.  The flow identifier helps the data plane to
   identify the specific flow, hence to do the processing with respect
   to the Alternate Marking.  It also simplifies the export by directly
   being encapsulated as the index for the associated metrics.

   PBT-M [I-D.song-ippm-postcard-based-telemetry] is an variation of PBT
   with packet Marking.  One marking bit is set in the user packet at
   the path head node, if its path-associated data need to be collected.
   At each PBT-aware node, if the mark is detected, a postcard (i.e.,
   the dedicated telemetry packet triggered by a marked user packet) is
   generated and sent to a collector.  The postcard contains the data
   requested by the management plane.  As an example, the requested data
   can be configured by the management plane through data set templates
   (as in IPFIX [RFC7011]).  This alternate marking bit can choose user
   packet on demand, e.g., periodically or triggered by condition meet,
   for telemetry.

2.  Data Fields Format

   The following figure shows the data fields format for enhanced
   alternate marking.  This data is expected to be encapsulated to
   specific transports.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   |           FlowMonID                   |L|D|M|    Reserved     |


   o  FlowMonID - 20 bits unsigned integer.  The FlowMon identifier
      field is to uniquely identify a monitored flow within the
      measurement domain.  The field is set at the ingress node.  The
      FlowMonID can be uniformly assigned by the central controller or
      algorithmically generated by the ingress node.  The latter
      approach cannot guarantee the uniqueness of FlowMonID but it may

Zhou, et al.               Expires May 3, 2020                  [Page 3]

Internet-Draft         enhanced-alternate-marking           October 2019

      be preferred for local or private network, where the conflict
      probability is small due to the large FlowMonID space.

   o  L - Loss flag as defined in [RFC8321];

   o  D - Delay flag as defined in [RFC8321];

   o  M - Marking bit as defined in PBT-M

   o  Reserved - is reserved for further use.  These bits MUST be set to

3.  Deployment Considerations

   The previous section introduces the AltMark Data Fields, based on the
   deployment experience and gives a practice to apply alternate

   The introduction of the flow identification is important for some

      Firstly, it helps to reduce the per node configuration.
      Otherwise, each node needs to configure the ACLs for all the
      monitored flows.  And, with Flow ID, there may be different
      granularity for flow definition.

      Secondly, it simplifies the counters handling, because hardware is
      hard to pull out and match the flow tuples defined by ACLs,
      especially in tunnels.

      Thirdly, it eases the data export encapsulation and correlation
      for the collectors.

   The deployment practice gives the motivation for this document.  It
   aims to do general deployment considerations and tries to avoid the
   relation to specific protocols.  Anyway it is important to mention
   that, even for specific protocols where a dedicated solution exits,
   the considerations of this document are always valid.

   In some circumstances, the conclusion is to build a separate header
   that is light-weighted but can address the existing requirement in
   carrier network performance measurement.

   While the AltMark Data Fields can take more information than the only
   marking bits, it is important to consider how to carry it in the
   encapsulation protocol.  This enhanced proposal supports more

Zhou, et al.               Expires May 3, 2020                  [Page 4]

Internet-Draft         enhanced-alternate-marking           October 2019

   interesting and powerful use cases and address the in-band
   performance measurement approach.

   In IPv6 ([I-D.fz-6man-ipv6-alt-mark]), the way to mitigate the
   compatibility with non-capable devices is considered.  AltMark Data
   Fields could be encapsulated in the DOH or SRH, so that the
   intermediate node will not drop packets.

4.  Implementing Multipoint Alternate Marking

   There are some considerations to do on how to manage the general
   Multipoint Alternate Marking application in order to get more
   adaptable performance measurement.

   [I-D.ietf-ippm-multipoint-alt-mark] introduces the network clustering
   approach for Alternate Marking: the network clusters partition can be
   done at different levels to perform the needed degree of detail.  The
   Network Management can use an intelligent strategy: it can start
   without examining in depth, and, in case of problems (i.e.  measured
   packet loss or too high delay), various filtering criteria can be
   specified in order to perform a detailed analysis by using different
   combination of clusters or, at the limit, a per-flow measurement.

   So, the more general implementation of Multipoint Alternate Marking
   needs an intelligent and flexible Alternate Marking algorithm.  For
   this purpose, [I-D.song-opsawg-ifit-framework] introduces a telemetry
   framework and describes the closed loop between Nodes, Telemetry Data
   Collector and Network Management.

5.  Implementation Status

   [Note: This entire section should be removed by RFC Editor before the
   RFC publication.]

   This section records the status of known implementations of the
   protocol defined by this specification at the time of posting of this
   Internet-Draft, and is based on a proposal described in [RFC7942].
   The description of implementations in this section is intended to
   assist the IETF in its decision processes in progressing drafts to
   RFCs.  Please note that the listing of any individual implementation
   here does not imply endorsement by the IETF.  Furthermore, no effort
   has been spent to verify the information presented here that was
   supplied by IETF contributors.  This is not intended as, and must not
   be construed to be, a catalog of available implementations or their
   features.  Readers are advised to note that other implementations may
   exist.  According to RFC 7942, "this will allow reviewers and working
   groups to assign due consideration to documents that have the benefit
   of running code, which may serve as evidence of valuable

Zhou, et al.               Expires May 3, 2020                  [Page 5]

Internet-Draft         enhanced-alternate-marking           October 2019

   experimentation and feedback that have made the implemented protocols
   more mature.  It is up to the individual working groups to use this
   information as they see fit".

   Huawei implemented the proposal described in this document based on
   the NE40E router.  The device can process the data fields in the
   network processor in the fast path.  Together with Huawei NCE
   controller, the solution can provide very high precision per hop
   packet loss detection and delay measurement.  The product is ready
   for MPLS based network and tested with LG U+, China Mobile and China
   Unicom in mobile backhaul.  The IPv6 and SRv6 based demonstration is
   also implemented.  Please contact Tianran Zhou
   (zhoutianran@huawei.com) for the details.

6.  Security Considerations


7.  IANA Considerations

   This document has no request to IANA.

8.  Contributors

   List of Contributors:

      Zhenqiang Li, China Mobile, lizhenqiang@chinamobile.com

9.  Acknowledgements

   The authors of this document would like to thank Haoyu Song for the
   PBT-M contribution.

10.  References

10.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,

   [RFC7011]  Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
              "Specification of the IP Flow Information Export (IPFIX)
              Protocol for the Exchange of Flow Information", STD 77,
              RFC 7011, DOI 10.17487/RFC7011, September 2013,

Zhou, et al.               Expires May 3, 2020                  [Page 6]

Internet-Draft         enhanced-alternate-marking           October 2019

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

   [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", BCP 205,
              RFC 7942, DOI 10.17487/RFC7942, July 2016,

   [RFC8321]  Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli,
              L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
              "Alternate-Marking Method for Passive and Hybrid
              Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321,
              January 2018, <https://www.rfc-editor.org/info/rfc8321>.

10.2.  Informative References

              Fioccola, G., Mirsky, G., and T. Mizrahi, "Performance
              Measurement (PM) with Alternate Marking in Network
              Virtualization Overlays (NVO3)", draft-fmm-nvo3-pm-alt-
              mark-03 (work in progress), October 2018.

              Fioccola, G., Zhou, T., and M. Cociglio, "IPv6 Application
              of the Alternate Marking Method", draft-fz-6man-ipv6-alt-
              mark-00 (work in progress), July 2019.

              Mirsky, G., Zheng, L., Chen, M., and G. Fioccola,
              "Performance Measurement (PM) with Marking Method in Bit
              Index Explicit Replication (BIER) Layer", draft-ietf-bier-
              pmmm-oam-06 (work in progress), July 2019.

              Fioccola, G., Cociglio, M., Sapio, A., and R. Sisto,
              "Multipoint Alternate Marking method for passive and
              hybrid performance monitoring", draft-ietf-ippm-
              multipoint-alt-mark-02 (work in progress), July 2019.

              Bryant, S., Chen, M., Li, Z., Swallow, G., Sivabalan, S.,
              Mirsky, G., and G. Fioccola, "RFC6374 Synonymous Flow
              Labels", draft-ietf-mpls-rfc6374-sfl-04 (work in
              progress), July 2019.

Zhou, et al.               Expires May 3, 2020                  [Page 7]

Internet-Draft         enhanced-alternate-marking           October 2019

              Mirsky, G., Fioccola, G., and T. Mizrahi, "Performance
              Measurement (PM) with Alternate Marking Method in Service
              Function Chaining (SFC) Domain", draft-mirsky-sfc-pmamm-08
              (work in progress), June 2019.

              Song, H., Zhou, T., Li, Z., Shin, J., and K. Lee,
              "Postcard-based On-Path Flow Data Telemetry", draft-song-
              ippm-postcard-based-telemetry-06 (work in progress),
              October 2019.

              Song, H., Li, Z., Zhou, T., Qin, F., Chen, H., Jin, J.,
              and J. Shin, "In-situ Flow Information Telemetry", draft-
              song-opsawg-ifit-framework-06 (work in progress), October

Authors' Addresses

   Tianran Zhou (editor)
   156 Beiqing Rd.
   Beijing  100095

   Email: zhoutianran@huawei.com

   Giuseppe Fioccola (editor)
   Riesstrasse, 25
   Munich  80992

   Email: giuseppe.fioccola@huawei.com

   Zhenbin Li
   156 Beiqing Rd.
   Beijing  100095

   Email: lizhenbin@huawei.com

Zhou, et al.               Expires May 3, 2020                  [Page 8]

Internet-Draft         enhanced-alternate-marking           October 2019

   Shinyoung Lee
   LG U+
   71, Magokjungang 8-ro, Gangseo-gu
   Republic of Korea

   Email: leesy@lguplus.co.kr

   Mauro Cociglio
   Telecom Italia
   Via Reiss Romoli, 274
   Torino  10148

   Email: mauro.cociglio@telecomitalia.it

Zhou, et al.               Expires May 3, 2020                  [Page 9]