MBONED H. Song
Internet-Draft M. McBride
Intended status: Standards Track Futurewei Technologies
Expires: 12 February 2023 G. Mirsky
ZTE Corp.
G. Mishra
Verizon Inc.
H. Asaeda
NICT
T. Zhou
Huawei Technologies
11 August 2022
Multicast On-path Telemetry using IOAM
draft-ietf-mboned-multicast-telemetry-04
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 12 February 2023 [Page 1]
Internet-Draft Multicast Telemetry August 2022
This Internet-Draft will expire on 12 February 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. Application Considerations for Multicast Protocols . . . . . 8
5.1. Mtrace verson 2 . . . . . . . . . . . . . . . . . . . . . 8
5.2. Application in PIM . . . . . . . . . . . . . . . . . . . 9
5.3. Application of MVPN X-PMSI Tunnel Encapsulation
Attribute . . . . . . . . . . . . . . . . . . . . . . . . 9
5.4. Application in BIER . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
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
Song, et al. Expires 12 February 2023 [Page 2]
Internet-Draft Multicast Telemetry August 2022
experience. If a packet is dropped, and that packet happens to be a
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.
Song, et al. Expires 12 February 2023 [Page 3]
Internet-Draft Multicast Telemetry August 2022
There are several requirements for multicast traffic telemetry, a few
of which are:
* 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 for 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 and correlate 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
Song, et al. Expires 12 February 2023 [Page 4]
Internet-Draft Multicast Telemetry August 2022
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).
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 the postcard-based telemetry's 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
fork node. Each node MUST export the branch identifier in the
received IOAM DEX header in the postcards it sends. The branch
identifier, along with the other fields such as flow ID and sequence
number, is sufficient for the data collector 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 12 February 2023 [Page 5]
Internet-Draft Multicast Telemetry August 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 a unique branch identifier
(i.e., branch ID) for each branch in its multicast tree instance and
include it in the IOAM DEX option header. The branch ID remains
unchanged until the next branch fork node. The branch ID contains
two parts: the branch fork node ID and an interface index.
Conforming to the node ID specification in IOAM [RFC9197], the node
ID is a 3-octet unsigned integer. The interface index is a two-octet
unsigned integer. As shown in Figure 2, the branch ID consumes 8
octets. The three unused octets must be set to 0.
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 | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 optional 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 12 February 2023 [Page 6]
Internet-Draft Multicast Telemetry August 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 12 February 2023 [Page 7]
Internet-Draft Multicast Telemetry August 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. Application Considerations for Multicast Protocols
5.1. Mtrace verson 2
Mtrace version 2 (Mtrace2) [RFC8487] is a protocol that allows the
tracing of an IP multicast routing path. Mtrace2 provides additional
information such as the packet rates and losses, as well as other
diagnostic information. Unlike unicast traceroute, Mtrace2 traces
the path that a packet would take from a source to a receiver. It is
usually initiated from an Mtrace2 client by sending an Mtrace2 Query
to a Last-Hop Router (LHR) or to a Rendezvous Point (RP). The LHR/RP
turns the Query packet into an Mtrace2 Request, appends a Standard
Response Block containing its interface addresses and packet
statistics to the Request packet, and forwards the packet towards the
source/RP. In a similar fashion, each router along the path to the
source/RP appends a Standard Response Block to the end of the Request
packet and forwards it to its upstream router. When the First-Hop
Router (FHR) receives the Request packet, it appends its own Standard
Response Block, turns the Request packet into a Reply, and unicasts
the Reply back to the Mtrace2 client.
Song, et al. Expires 12 February 2023 [Page 8]
Internet-Draft Multicast Telemetry August 2022
New on-path telemetry techniques will enhance Mtrace2, 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 unique on-path telemetry solution.
5.2. 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
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.
A proposed solution for encapsulating the telemetry instruction
header and metadata in IPv6 packets is described in
[I-D.ietf-ippm-ioam-ipv6-options].
5.3. 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
Song, et al. Expires 12 February 2023 [Page 9]
Internet-Draft Multicast Telemetry August 2022
corresponding proposal is described in
[I-D.song-mpls-extension-header].
5.4. 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.
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 trace and DEX options.
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
9. Acknowledgments
The authors would like to thank Frank Brockners, Nils Warnke, Jake
Holland, and Dino Farinacci for the comments and suggestions.
Song, et al. Expires 12 February 2023 [Page 10]
Internet-Draft Multicast Telemetry August 2022
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>.
[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>.
Song, et al. Expires 12 February 2023 [Page 11]
Internet-Draft Multicast Telemetry August 2022
[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>.
[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., Brockners, F., Bhandari, S., and T.
Mizrahi, "In-situ OAM Direct Exporting", Work in Progress,
Internet-Draft, draft-ietf-ippm-ioam-direct-export-09, 15
June 2022, <https://www.ietf.org/archive/id/draft-ietf-
ippm-ioam-direct-export-09.txt>.
Song, et al. Expires 12 February 2023 [Page 12]
Internet-Draft Multicast Telemetry August 2022
[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-08, 16 June 2022,
<https://www.ietf.org/archive/id/draft-ietf-ippm-ioam-
ipv6-options-08.txt>.
[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, 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., Zhang, Z.,
Gandhi, R., Rajamanickam, J., and J. Bhattacharya, "MPLS
Post-Stack Extension Header", Work in Progress, Internet-
Draft, draft-song-mpls-extension-header-09, 11 August
2022, <https://datatracker.ietf.org/api/v1/doc/document/
draft-song-mpls-extension-header/>.
[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>.
Song, et al. Expires 12 February 2023 [Page 13]
Internet-Draft Multicast Telemetry August 2022
Authors' Addresses
Haoyu Song
Futurewei Technologies
2330 Central Expressway
Santa Clara,
United States of America
Email: hsong@futurewei.com
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 Technologies
Beijing
China
Email: zhoutianran@huawei.com
Song, et al. Expires 12 February 2023 [Page 14]