Multicast On-path Telemetry using IOAM
draft-ietf-mboned-multicast-telemetry-03

MBONED                                                           H. Song
Internet-Draft                                                M. McBride
Intended status: Standards Track                  Futurewei Technologies
Expires: 6 January 2023                                        G. Mirsky
                                                               ZTE Corp.
                                                               G. Mishra
                                                            Verizon Inc.
                                                               H. Asaeda
                                                                    NICT
                                                                 T. Zhou
                                                                  Huawei
                                                             5 July 2022

                 Multicast On-path Telemetry using IOAM
                draft-ietf-mboned-multicast-telemetry-03

Abstract

   This document discusses the requirements of on-path telemetry for
   multicast traffic using In-situ OAM.  Applying In-situ OAM for
   multicast telemetry presents some unique challenges.  This document
   provides the solutions based on the In-situ OAM trace option and
   direct export option to support the telemetry data correlation and
   the multicast tree reconstruction without collecting redundant data.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119][RFC8174] when, and only when, they appear in all
   capitals, as shown here.

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

Song, et al.             Expires 6 January 2023                 [Page 1]
Internet-Draft             Multicast Telemetry                 July 2022

   This Internet-Draft will expire on 6 January 2023.

Copyright Notice

   Copyright (c) 2022 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 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.  Requirements for Multicast Traffic Telemetry  . . . . . . . .   3
   3.  Issues of Existing Techniques . . . . . . . . . . . . . . . .   4
   4.  Modifications to Existing Solutions . . . . . . . . . . . . .   5
     4.1.  Per-hop postcard using IOAM DEX . . . . . . . . . . . . .   5
     4.2.  Per-section postcard for IOAM Trace . . . . . . . . . . .   7
   5.  Considerations for Different Multicast Protocols  . . . . . .   8
     5.1.  Application in PIM  . . . . . . . . . . . . . . . . . . .   8
     5.2.  Application of MVPN X-PMSI Tunnel Encapsulation
           Attribute . . . . . . . . . . . . . . . . . . . . . . . .   9
     5.3.  Application in BIER . . . . . . . . . . . . . . . . . . .   9
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   8.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  10
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  10
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     10.2.  Informative References . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   Multicast traffic is used across operator networks to support
   residential broadband customers, private MPLS customers and used with
   corporate intranet internal customers.  Multicast provides real time
   interactive online meetings or podcasts, IPTV and financial markets
   real-time data, which all have a reliance on UDP's unreliable
   transport.  End to end QOS, therefore, should be a critical component
   of multicast deployment in order to provide a good end user viewing
   experience.  If a packet is dropped, and that packet happens to be a

Song, et al.             Expires 6 January 2023                 [Page 2]
Internet-Draft             Multicast Telemetry                 July 2022

   reference frame (I-Frame) in the video feed, the client receiver of
   the multicast feed goes into buffering mode resulting in a frozen
   window.  Multicast packet drops and delay can severely affect the
   application performance and user experience.

   It is important to monitor the performance of the multicast traffic.
   New on-path telemetry techniques such as In-situ OAM (IOAM)
   [RFC9197], IOAM Direct Export (DEX)
   [I-D.ietf-ippm-ioam-direct-export] IOAM Marking-based Postcard (MBP)
   [I-D.song-ippm-postcard-based-telemetry], and Hybrid Two-Step (HTS)
   [I-D.mirsky-ippm-hybrid-two-step] are useful and complementary to the
   existing active OAM performance monitoring methods, provide promising
   means to directly monitor the network experience of multicast
   traffic.  However, multicast traffic has some unique characteristics
   which pose some challenges on efficiently applying such techniques.

   The IP Multicast (S,G) data is identical from one branch to another
   on its way to multiple receivers.  When adding IOAM trace data to
   multicast packets, redundant data will be collected for the same
   original multicast packet.  This is because each replicated packet
   keeps the telemetry data for its entire forwarding path and the
   replicated packets all share some common path segments.  Such
   redundancy consumes more network bandwidth unnecessarily.
   Alternatively, it could be more efficient to collect the telemetry
   data using solutions such as IOAM DEX to eliminate the data
   redundancy.  However, the current postcard-based direct export
   solution does not have a branch identifier, making telemetry data
   correlation and multicast-tree reconstruction difficult.

   This draft proposes a set of solutions to the IOAM data redundancy
   problem.  The requirements for multicast traffic telemetry are
   discussed along with the issues of the existing on-path telemetry
   techniques.  We propose modifications to make these techniques adapt
   to multicast in order for the original multicast tree to be correctly
   reconstructed while eliminating redundant data.

2.  Requirements for Multicast Traffic Telemetry

   Multicast traffic is forwarded through a multicast tree.  With PIM
   and P2MP (MLDP, RSVP-TE) the forwarding tree is established and
   maintained by the multicast routing protocol.  With BIER, no state is
   created in the network to establish a forwarding tree; instead, a
   bier header provides the necessary information for each packet to
   know the egress points.  Multicast packets are only replicated at
   each tree branch node for efficiency.

   There are several requirements for multicast traffic telemetry, a few
   of which are:

Song, et al.             Expires 6 January 2023                 [Page 3]
Internet-Draft             Multicast Telemetry                 July 2022

   *  Reconstruct and visualize the multicast tree through data plane
      monitoring.

   *  Gather the multicast packet delay and jitter performance.

   *  Find the multicast packet drop location and reason.

   *  Gather the VPN state and tunnel information in case of P2MP
      multicast.

   In order to meet these requirements, we need the ability to directly
   monitor the multicast traffic and derive data from the multicast
   packets.  The conventional OAM mechanisms, such as multicast ping and
   trace, are not sufficient to meet these requirements.

3.  Issues of Existing Techniques

   On-path Telemetry techniques that directly retrieve data from
   multicast traffic's live network experience are ideal to address the
   above mentioned requirements.  The representative techniques include
   In-situ OAM (IOAM) Trace option [RFC9197], IOAM Direct Export (DEX)
   option [I-D.ietf-ippm-ioam-direct-export], and IOAM Marking-based
   Postcard (MBP) [I-D.song-ippm-postcard-based-telemetry].  However,
   unlike unicast, multicast poses some unique challenges to applying
   these techniques.

   Multicast packets are replicated at each branch node in the
   corresponding multicast tree.  Therefore, there are multiple copies
   of the original multicast packet in the network.

   If the IOAM trace option is used for on-path data collection, the
   partial trace data will also be replicated into the copy each branch.
   The end result is that, at the multicast tree leaves, each copy of
   the multicast packet has a complete trace.  Most of the data,
   however, is redundant.  Data redundancy introduces unnecessary header
   overhead, wastes network bandwidth, and complicates the data
   processing.  In case the multicast tree is large, and the path is
   long, the redundancy problem becomes severe.

   The postcard-based solutions, including the IOAM DEX and MBP, can be
   used to eliminate such data redundancy, because each node on the tree
   only sends a postcard covering local data.  However, they cannot
   track the tree branches properly so it can bring confusion about the
   multicast tree topology.  For example, in a multicast tree, Node A
   has two branches, one to Node B and the other to node C, and Node B
   leads to Node D and Node C leads to Node E.  From the received
   postcards, one cannot tell whether or not Node D(E) is the next hop
   of Node B(C).

Song, et al.             Expires 6 January 2023                 [Page 4]
Internet-Draft             Multicast Telemetry                 July 2022

   The fundamental reason for this problem is that there is not an
   identifier (either implicit or explicit) to correlate the data on
   each branch.

4.  Modifications to Existing Solutions

   We provide two solutions to address the above issues.  One is based
   on IOAM DEX and requires an extension to the instruction header of
   the IOAM DEX Option.  The second solution combines the IOAM trace
   option and postcards for redundancy removal.

4.1.  Per-hop postcard using IOAM DEX

   One way to mitigate PBT's multiple tree tracking weakness is to
   augment it with a branch identifier field.  Note that this works for
   the IOAM DEX option but not for MBP because the IOAM DEX option has
   an instruction header which can be used to hold the branch
   identifier.  To make the branch identifier globally unique, the
   branch node ID plus an index is used.  For example, Node A has two
   branches, one to Node B and the other to Node C.  Node A will use [A,
   0] as the branch identifier for the branch to B, and [A, 1] for the
   branch to C.  The identifier is unchanged for each multicast tree
   instance and carried with the multicast packet until the next branch
   node.  Each postcard needs to include the branch identifier in the
   export data.  The branch identifier, along with the other fields such
   as flow ID and sequence number, is sufficient for the data analyzer
   to reconstruct the topology of the multicast tree.

   Figure 1 shows an example of this solution.  "P" stands for the
   postcard packet.  The square brackets contains the branch identifier.
   The curly brace contains the telemetry data about a specific node.

Song, et al.             Expires 6 January 2023                 [Page 5]
Internet-Draft             Multicast Telemetry                 July 2022

     P:[A,0]{A}  P:[A,0]{B} P:[B,1]{D}  P:[B,0]{C}   P:[B,0]{E}
          ^            ^          ^        ^           ^
          :            :          :        :           :
          :            :          :        :           :
          :            :          :      +-:-+       +-:-+
          :            :          :      |   |       |   |
          :            :      +---:----->| C |------>| E |-...
        +-:-+        +-:-+    |   :      |   |       |   |
        |   |        |   |----+   :      +---+       +---+
        | A |------->| B |        :
        |   |        |   |--+   +-:-+
        +---+        +---+  |   |   |
                            +-->| D |--...
                                |   |
                                +---+

                         Figure 1: Per-hop Postcard

   Each branch fork node needs to generate the branch ID for each branch
   in its multicast tree instance and include it in the IOAM DEX option
   header so the downstream node can learn it.  The branch ID contains
   two parts: the branch fork node ID and a unique branch index.

   Conforming to the node ID specification in IOAM [RFC9197], the node
   ID is a 3-octet unsigned integer.  The branch index is a one-octet
   unsigned integer.  So the branch ID is 4-octet long, as shown in
   Figure 2.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 node_id                       |  branch index |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 2: Multicast Branch ID format

   Figure 3 shows that the branch ID is carried as an optional field
   after the flow ID and sequence number optional fields in the IOAM DEX
   option header.  A bit "M" (The third bit in the Extension-Flags
   field) is reserved to indicate the presence of the branch ID field.
   If "M" is set to 1, the optional multicast branch ID field is
   present; otherwise it is absent.

Song, et al.             Expires 6 January 2023                 [Page 6]
Internet-Draft             Multicast Telemetry                 July 2022

           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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Namespace-ID           |     Flags     |F|S|M|Ext-Flags|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               IOAM-Trace-Type                 |   Reserved    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Flow ID (optional)                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Sequence Number  (Optional)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Multicast Branch ID (optional)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 3: Carry Branch ID in IOAM DEX option header

   Once a node gets the branch ID information from the upstream, it MUST
   carry this information in its telemetry data export postcards, so the
   original multicast tree can be correctly reconstructed based on the
   postcards.

4.2.  Per-section postcard for IOAM Trace

   The second solution is a combination of the IOAM trace option and the
   postcard-based telemetry.  To avoid data redundancy at each branch
   node, the trace data accumulated, to that point, is exported by a
   postcard before the packet is replicated.  In this case, each branch
   still needs to maintain some identifier to help correlate the
   postcards for each tree section.  The natural way to accomplish this
   is to simply carry the branch node's data (including its ID) in the
   trace of each branch.  This is also necessary because each replicated
   multicast packet can have different telemetry data pertaining to this
   particular copy (e.g., node delay, egress timestamp, and egress
   interface).  As a consequence, the local data exported by each branch
   node can only contain partial data (e.g., ingress interface and
   ingress timestamp).

   Figure 4 shows an example in a segment of a multicast tree.  Node B
   and D are two branch nodes and they will export a postcard covering
   the trace data for the previous section.  The end node of each path
   will also need to export the data of the last section as a postcard.

Song, et al.             Expires 6 January 2023                 [Page 7]
Internet-Draft             Multicast Telemetry                 July 2022

                P:{A,B'}            P:{B1,C,D'}
                   ^                     ^
                   :                     :
                   :                     :
                   :                     :    {D1}
                   :                     :    +--...
                   :        +---+      +---+  |
                   :   {B1} |   |{B1,C}|   |--+ {D2}
                   :    +-->| C |----->| D |-----...
       +---+     +---+  |   |   |      |   |--+
       |   | {A} |   |--+   +---+      +---+  |
       | A |---->| B |                        +--...
       |   |     |   |--+   +---+             {D3}
       +---+     +---+  |   |   |{B2,E}
                        +-->| E |--...
                       {B2} |   |
                            +---+

                       Figure 4: Per-section Postcard

   There is no need to modify the IOAM trace option header format as
   specified in [RFC9197].  We just need to configure the branch nodes
   to export the postcards and refresh the IOAM header and data (e.g.,
   clear the node data list and reset the Remaining Length filed).

5.  Considerations for Different Multicast Protocols

   MTRACEv2 [RFC8487] provides an active probing approach for the
   tracing of an IP multicast routing path.  Mtrace can also provide
   information such as the packet rates and losses, as well as other
   diagnostic information.  New on-path telemetry techniques will
   enhance Mtrace, and other existing OAM solutions, with more granular
   and realtime network status data through direct measurements.  There
   are various multicast protocols that are used to forward the
   multicast data.  Each will require their own data-plane on-path
   telemetry method based on the solutions aforementioned.

5.1.  Application in PIM

   PIM-SM [RFC7761] is the most widely used multicast routing protocol
   deployed today.  Of the various PIM modes (PIM-SM, PIM-DM, BIDIR-PIM,
   PIM-SSM), PIM-SSM is the preferred method due to its simplicity and
   removal of network source discovery complexity.  With all PIM modes,
   control plane state is established in the network in order to forward
   multicast UDP data packets.  All PIM modes utilize network based
   source discovery except for PIM-SSM, which utilizes application based
   source discovery.  IP Multicast packets fall within the range of

Song, et al.             Expires 6 January 2023                 [Page 8]
Internet-Draft             Multicast Telemetry                 July 2022

   224.0.0.0 through 239.255.255.255.  The telemetry solution will need
   to work within this address range and provide telemetry data for this
   UDP traffic.

   The proposed solutions for encapsulating the telemetry instruction
   header and metadata in IPv6 UDP packets is described in
   [I-D.ietf-ippm-ioam-ipv6-options].

5.2.  Application of MVPN X-PMSI Tunnel Encapsulation Attribute

   Multipoint Label Distribution Protocol (mLDP), P2MP RSVP-TE, Ingress
   Replication (IR), PIM MDT SAFI with GRE Transport, are commonly used
   within a Multicast VPN (MVPN) environment utilizing MVPN procedures
   Multicast in MPLS/BGP IP VPNs [RFC6513] and BGP Encoding and
   Procedures for Multicast in MPLS/BGP IP VPNs [RFC6514].  MLDP LDP
   Extension for P2MP and MP2MP LSPs [RFC6388] provides extensions to
   LDP to establish point-to-multipoint (P2MP) and multipoint-to-
   multipoint (MP2MP) label switched paths (LSPs) in MPLS networks.
   P2MP RSVP-TE provides extensions to RSVP-TE RSVP-TE for P2MP LSPs
   [RFC4875] for establish traffic-engineered P2MP LSPs in MPLS
   networks.  Ingress Replication (IR) P2MP Trees Ingress Replication
   Tunnels in Multicast VPNs [RFC7988] using unicast replication from
   parent node to child node over MPLS Unicast Tunnel.  PIM MDT SAFI
   Multicast in BGP/MPLS IP VPNs [RFC6037]utilizes PIM modes PIM-SSM,
   PIM-SM, PIM-BIDIR control plane with GRE transport data plane in the
   core for X-PMSI P-Tree using MVPN procedures.  Replication SID SR
   Replication Segment for Multi-point Service Delivery
   [I-D.ietf-spring-sr-replication-segment] replication segments for
   P2MP multicast service delivery in Segment Routing SR-MPLS networks.
   The telemetry solution will need to be able to follow these P2MP and
   MP2MP paths.  The telemetry instruction header and data should be
   encapsulated into MPLS packets on P2MP and MP2MP paths.  A
   corresponding proposal is described in
   [I-D.song-mpls-extension-header].

5.3.  Application in BIER

   BIER [RFC8279] adds a new header to multicast packets and allows the
   multicast packets to be forwarded according to the header only.  By
   eliminating the requirement of maintaining per multicast group state,
   BIER is more scalable than the traditional multicast solutions.

   OAM Requirements for BIER [I-D.ietf-bier-oam-requirements] lists many
   of the requirements for OAM at the BIER layer which will help in the
   forming of on-path telemetry requirements as well.

Song, et al.             Expires 6 January 2023                 [Page 9]
Internet-Draft             Multicast Telemetry                 July 2022

   There is also current work to provide solutions for BIER forwarding
   in ipv6 networks.  For instance, a solution, BIER in Non-MPLS IPv6
   Networks [I-D.xie-bier-ipv6-encapsulation], proposes a new bier
   Option Type codepoint from the "Destination Options and Hop-by-Hop
   Options" IPv6 sub-registry.  This is similar to what IOAM proposes
   for IPv6 transport.

   Depending on how the BIER header is encapsulated into packets with
   different transport protocols, the method to encapsulate the
   telemetry instruction header and metadata also varies.  It is also
   possible to make the instruction header and metadata a part of the
   BIER header itself, such as in a TLV.

6.  Security Considerations

   No new security issues are identified other than those discovered by
   the IOAM, PBT and HTS drafts.

7.  IANA Considerations

   The document requests a new extension flag registration in the "IOAM
   DEX Extension-Flags" registry, as described in Section 4.1.

   Bit 2 "Multicast Branch ID [RFC XXXX] [RFC Editor: please replace
   with the RFC number of the current document]".

8.  Contributors

   TBD

9.  Acknowledgments

   The authors would like to thank Frank Brockners for the comments and
   advice.

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,
              <https://www.rfc-editor.org/info/rfc2119>.

Song, et al.             Expires 6 January 2023                [Page 10]
Internet-Draft             Multicast Telemetry                 July 2022

   [RFC4687]  Yasukawa, S., Farrel, A., King, D., and T. Nadeau,
              "Operations and Management (OAM) Requirements for Point-
              to-Multipoint MPLS Networks", RFC 4687,
              DOI 10.17487/RFC4687, September 2006,
              <https://www.rfc-editor.org/info/rfc4687>.

   [RFC4875]  Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
              Yasukawa, Ed., "Extensions to Resource Reservation
              Protocol - Traffic Engineering (RSVP-TE) for Point-to-
              Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
              DOI 10.17487/RFC4875, May 2007,
              <https://www.rfc-editor.org/info/rfc4875>.

   [RFC6037]  Rosen, E., Ed., Cai, Y., Ed., and IJ. Wijnands, "Cisco
              Systems' Solution for Multicast in BGP/MPLS IP VPNs",
              RFC 6037, DOI 10.17487/RFC6037, October 2010,
              <https://www.rfc-editor.org/info/rfc6037>.

   [RFC6388]  Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
              Thomas, "Label Distribution Protocol Extensions for Point-
              to-Multipoint and Multipoint-to-Multipoint Label Switched
              Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011,
              <https://www.rfc-editor.org/info/rfc6388>.

   [RFC6513]  Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
              BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
              2012, <https://www.rfc-editor.org/info/rfc6513>.

   [RFC6514]  Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
              Encodings and Procedures for Multicast in MPLS/BGP IP
              VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
              <https://www.rfc-editor.org/info/rfc6514>.

   [RFC7761]  Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
              Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
              Multicast - Sparse Mode (PIM-SM): Protocol Specification
              (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
              2016, <https://www.rfc-editor.org/info/rfc7761>.

   [RFC7988]  Rosen, E., Ed., Subramanian, K., and Z. Zhang, "Ingress
              Replication Tunnels in Multicast VPN", RFC 7988,
              DOI 10.17487/RFC7988, October 2016,
              <https://www.rfc-editor.org/info/rfc7988>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Song, et al.             Expires 6 January 2023                [Page 11]
Internet-Draft             Multicast Telemetry                 July 2022

   [RFC8279]  Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
              Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
              Explicit Replication (BIER)", RFC 8279,
              DOI 10.17487/RFC8279, November 2017,
              <https://www.rfc-editor.org/info/rfc8279>.

   [RFC8487]  Asaeda, H., Meyer, K., and W. Lee, Ed., "Mtrace Version 2:
              Traceroute Facility for IP Multicast", RFC 8487,
              DOI 10.17487/RFC8487, October 2018,
              <https://www.rfc-editor.org/info/rfc8487>.

   [RFC9197]  Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi,
              Ed., "Data Fields for In Situ Operations, Administration,
              and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197,
              May 2022, <https://www.rfc-editor.org/info/rfc9197>.

10.2.  Informative References

   [I-D.ietf-bier-oam-requirements]
              Mirsky, G., Kumar, N., Chen, M., and S. Pallagatti,
              "Operations, Administration and Maintenance (OAM)
              Requirements for Bit Index Explicit Replication (BIER)
              Layer", Work in Progress, Internet-Draft, draft-ietf-bier-
              oam-requirements-11, 15 November 2020,
              <https://www.ietf.org/archive/id/draft-ietf-bier-oam-
              requirements-11.txt>.

   [I-D.ietf-ippm-ioam-direct-export]
              Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F.,
              Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ
              OAM Direct Exporting", Work in Progress, Internet-Draft,
              draft-ietf-ippm-ioam-direct-export-07, 13 October 2021,
              <https://www.ietf.org/archive/id/draft-ietf-ippm-ioam-
              direct-export-07.txt>.

   [I-D.ietf-ippm-ioam-ipv6-options]
              Bhandari, S. and F. Brockners, "In-situ OAM IPv6 Options",
              Work in Progress, Internet-Draft, draft-ietf-ippm-ioam-
              ipv6-options-07, 6 February 2022,
              <https://www.ietf.org/archive/id/draft-ietf-ippm-ioam-
              ipv6-options-07.txt>.

Song, et al.             Expires 6 January 2023                [Page 12]
Internet-Draft             Multicast Telemetry                 July 2022

   [I-D.ietf-spring-sr-replication-segment]
              (editor), D. V., Filsfils, C., Parekh, R., Bidgoli, H.,
              and Z. Zhang, "SR Replication Segment for Multi-point
              Service Delivery", Work in Progress, Internet-Draft,
              draft-ietf-spring-sr-replication-segment-08, 1 July 2022,
              <https://www.ietf.org/archive/id/draft-ietf-spring-sr-
              replication-segment-08.txt>.

   [I-D.mirsky-ippm-hybrid-two-step]
              Mirsky, G., Lingqiang, W., Zhui, G., Song, H., and P.
              Thubert, "Hybrid Two-Step Performance Measurement Method",
              Work in Progress, Internet-Draft, draft-mirsky-ippm-
              hybrid-two-step-13, 25 April 2022,
              <https://www.ietf.org/archive/id/draft-mirsky-ippm-hybrid-
              two-step-13.txt>.

   [I-D.song-ippm-postcard-based-telemetry]
              Song, H., Mirsky, G., Filsfils, C., Abdelsalam, A., Zhou,
              T., Li, Z., Mishra, G., Shin, J., and K. Lee, "In-Situ OAM
              Marking-based Direct Export", Work in Progress, Internet-
              Draft, draft-song-ippm-postcard-based-telemetry-12, 12 May
              2022, <https://www.ietf.org/archive/id/draft-song-ippm-
              postcard-based-telemetry-12.txt>.

   [I-D.song-mpls-extension-header]
              Song, H., Li, Z., Zhou, T., Andersson, L., and Z. Zhang,
              "MPLS Extension Header", Work in Progress, Internet-Draft,
              draft-song-mpls-extension-header-06, 10 January 2022,
              <https://www.ietf.org/archive/id/draft-song-mpls-
              extension-header-06.txt>.

   [I-D.xie-bier-ipv6-encapsulation]
              Xie, J., Geng, L., McBride, M., Asati, R., Dhanaraj, S.,
              Zhu, Y., Qin, Z., Shin, M., Mishra, G., and X. Geng,
              "Encapsulation for BIER in Non-MPLS IPv6 Networks", Work
              in Progress, Internet-Draft, draft-xie-bier-ipv6-
              encapsulation-10, 22 February 2021,
              <https://www.ietf.org/archive/id/draft-xie-bier-ipv6-
              encapsulation-10.txt>.

Authors' Addresses

   Haoyu Song
   Futurewei Technologies
   2330 Central Expressway
   Santa Clara,
   United States of America
   Email: hsong@futurewei.com

Song, et al.             Expires 6 January 2023                [Page 13]
Internet-Draft             Multicast Telemetry                 July 2022

   Mike McBride
   Futurewei Technologies
   2330 Central Expressway
   Santa Clara,
   United States of America
   Email: mmcbride@futurewei.com

   Greg Mirsky
   ZTE Corp.
   Email: gregimirsky@gmail.com

   Gyan Mishra
   Verizon Inc.
   Email: gyan.s.mishra@verizon.com

   Hitoshi Asaeda
   National Institute of Information and Communications Technology
   4-2-1 Nukui-Kitamachi, Tokyo
   184-8795
   Japan
   Email: asaeda@nict.go.jp

   Tianran Zhou
   Huawei
   Email: zhoutianran@huawei.com

Song, et al.             Expires 6 January 2023                [Page 14]