Alternate-Marking Method for Passive and Hybrid Performance Monitoring
RFC 8321

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: cpignata@cisco.com, ippm-chairs@ietf.org, ippm@ietf.org, Carlos Pignataro <cpignata@cisco.com>, draft-ietf-ippm-alt-mark@ietf.org, spencerdawkins.ietf@gmail.com, The IESG <iesg@ietf.org>, rfc-editor@rfc-editor.org
Subject: Document Action: 'Alternate Marking method for passive and hybrid performance monitoring' to Experimental RFC (draft-ietf-ippm-alt-mark-14.txt)

The IESG has approved the following document:
- 'Alternate Marking method for passive and hybrid performance monitoring'
  (draft-ietf-ippm-alt-mark-14.txt) as Experimental RFC

This document is the product of the IP Performance Measurement Working Group.

The IESG contact persons are Mirja K├╝hlewind and Spencer Dawkins.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark/


Technical Summary

   This document describes a method to perform packet loss, delay and
   jitter measurements on live traffic.  This method is based on
   Alternate Marking (Coloring) technique.  A report on the operational
   experiment done at Telecom Italia is explained in order to give an
   example and show the method applicability.  This technique can be
   applied in various situations as detailed in this document and could
   be considered passive or hybrid depending on the application.

Working Group Summary

  The WG process as it relates to this document has been smooth and 
  without major controversies. The WGLC was also smooth, and the
  editors have been very responsive and diligent in incorporating all
  the WGLC comments in a timely fashion.

  While the document contain a single Editor, it lists more than five
  authors. The history and rationale for that is as follows: the ideas
  on this methodology originated and were introduced to the IETF
  from two I-Ds: draft-cociglio-mboned-multicast-pm and 
  draft-tempia-opsawg-p3m. Most recently, draft-tempia-opsawg-p3m
  targeted the IPPM WG, and was renamed to draft-tempia-ippm-p3m.
  After adotpion in IPPM, it merged with the descriptive portions of
  draft-chen-ippm-coloring-based-ipfpm-framework (the architectural
  portions were deamed out of scope for IPPM. This union added more
  value to the work because it completed the technical explanation of
  the methodology.  Consequently new authors joined the draft after
  this merge.

Document Quality

  There is both significant and broad support for the methods defined
  in this document. This manifests itself in the number of protocols
  that are producing specifications (in other working groups) utilizing
  these methods natively with them. For example, BIER, MPLS, etc. 
  This document has 12 other documents currently referencing it, as
  per <https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark/referencedby/>.
  Further, there are many vendors (chip vendors, networking software 
  vendors, etc.) either with implementations, roadmaps, or plans
  to implement these methods.

Personnel

  Carlos Pignataro is the Document Shepherd.
  Spencer Dawkins is the Responsible Area Director.

RFC Editor Note

OLD

  o  no interoperability issues: the features required to experiment
      and test the method (as described in Section 5.1) are available on
      all current routing platforms.  Both a centarlized or distributed
      solution can be used to harvest data from the routers.

NEW

  o  no interoperability issues: the features required to experiment
      and test the method (as described in Section 5.1) are available on
      all current routing platforms.  Both a centralized or distributed
      solution can be used to harvest data from the routers.

OLD

  Traffic coloring could be done by R1 itself or it is already done
   before.  R1 needs two counters, C(A)R1 and C(B)R1, on its egress
   interface: C(A)R1 counts the packets with color A and C(B)R1 counts
   those with color B.  As long as traffic is colored A, only counter
   C(A)R1 will be incremented, while C(B)R1 is not incremented; vice
   versa, when the traffic is colored as B, only C(B)R1 is incremented.
   C(A)R1 and C(B)R1 can be used as reference values to determine the
   packet loss from R1 to any other measurement point down the path.
   Router R2, similarly, will need two counters on its ingress
   interface, C(A)R2 and C(B)R2, to count the packets received on that
   interface and colored with color A and B respectively.  When an A
   block ends, it is possible to compare C(A)R1 and C(A)R2 and calculate
   the packet loss within the block; similarly, when the successive B
   block terminates, it is possible to compare C(B)R1 with C(B)R2, and
   so on for every successive block.

NEW

  Traffic coloring can be done by R1 itself if the traffic is not already
   colored.  R1 needs two counters, C(A)R1 and C(B)R1, on its egress
   interface: C(A)R1 counts the packets with color A and C(B)R1 counts
   those with color B.  As long as traffic is colored A, only counter
   C(A)R1 will be incremented, while C(B)R1 is not incremented; vice
   versa, when the traffic is colored as B, only C(B)R1 is incremented.
   C(A)R1 and C(B)R1 can be used as reference values to determine the
   packet loss from R1 to any other measurement point down the path.
   Router R2, similarly, will need two counters on its ingress
   interface, C(A)R2 and C(B)R2, to count the packets received on that
   interface and colored with color A and B respectively.  When an A
   block ends, it is possible to compare C(A)R1 and C(A)R2 and calculate
   the packet loss within the block; similarly, when the successive B
   block terminates, it is possible to compare C(B)R1 with C(B)R2, and
   so on for every successive block.

OLD

  The privacy concerns of network measurement are limited because the
   method only relies on information contained in the header or
   encapsulation without any release of user data.Although information
   in the header or encapsulation is metadata that can be used to
   compromise the privacy of users, the limited marking technique in
   this document seems unlikely to substantially increase the existing
   privacy risks from header or encapsulation metadata.It might be
   theoretically possible to modulate the marking to serve as a covert
   channel, but it would have a very low data rate if it is to avoid
   adversely affecting the measurement systems that monitor the marking.

NEW

  The privacy concerns of network measurement are limited because the
   method only relies on information contained in the header or
   encapsulation without any release of user data. Although information
   in the header or encapsulation is metadata that can be used to
   compromise the privacy of users, the limited marking technique in
   this document seems unlikely to substantially increase the existing
   privacy risks from header or encapsulation metadata. It might be
   theoretically possible to modulate the marking to serve as a covert
   channel, but it would have a very low data rate if it is to avoid
   adversely affecting the measurement systems that monitor the marking.