diff options
Diffstat (limited to 'doc/rfc/rfc9630.txt')
| -rw-r--r-- | doc/rfc/rfc9630.txt | 608 |
1 files changed, 608 insertions, 0 deletions
diff --git a/doc/rfc/rfc9630.txt b/doc/rfc/rfc9630.txt new file mode 100644 index 0000000..fc7ff4e --- /dev/null +++ b/doc/rfc/rfc9630.txt @@ -0,0 +1,608 @@ + + + + +Internet Engineering Task Force (IETF) H. Song +Request for Comments: 9630 M. McBride +Category: Standards Track Futurewei Technologies +ISSN: 2070-1721 G. Mirsky + Ericsson + G. Mishra + Verizon Inc. + H. Asaeda + NICT + T. Zhou + Huawei Technologies + August 2024 + + + Multicast On-Path Telemetry Using In Situ Operations, Administration, + and Maintenance (IOAM) + +Abstract + + This document specifies two solutions to meet the requirements of on- + path telemetry for multicast traffic using IOAM. While IOAM is + advantageous for multicast traffic telemetry, some unique challenges + are present. This document provides the solutions based on the IOAM + trace option and direct export option to support the telemetry data + correlation and the multicast tree reconstruction without incurring + data redundancy. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9630. + +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. 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 + 1.1. Requirements Language + 2. Requirements for Multicast Traffic Telemetry + 3. Issues of Existing Techniques + 4. Modifications and Extensions Based on Existing Solutions + 4.1. Per-Hop Postcard Using IOAM DEX + 4.2. Per-Section Postcard for IOAM Trace + 5. Application Considerations for Multicast Protocols + 5.1. Mtrace Version 2 + 5.2. Application in PIM + 5.3. Application of MVPN PMSI Tunnel Attribute + 6. Security Considerations + 7. IANA Considerations + 8. References + 8.1. Normative References + 8.2. Informative References + Acknowledgments + Authors' Addresses + +1. Introduction + + IP multicast has had many useful applications for several decades. + [MULTICAST-LESSONS-LEARNED] provides a thorough historical + perspective about the design and deployment of many of the multicast + routing protocols in use with various applications. We will mention + of few of these throughout this document and in the Application + Considerations section (Section 5). IP multicast has been used by + residential broadband customers across operator networks, private + MPLS customers, and internal customers within corporate intranets. + IP multicast has provided real-time interactive online meetings or + podcasts, IPTV, and financial markets' real-time data, all of which + rely on UDP's unreliable transport. End-to-end QoS, therefore, + should be a critical component of multicast deployments in order to + provide a good end-user experience within a specific operational + domain. In multicast real-time media streaming, if a single packet + is lost within a keyframe and cannot be recovered using forward error + correction, many receivers will be unable to decode subsequent frames + within the Group of Pictures (GoP), which results in video freezes or + black pictures until another keyframe is delivered. Unexpectedly + long delays in delivery of packets can cause timeouts with similar + results. Multicast packet loss and delays can therefore affect + application performance and the user experience within a domain. + + It is essential to monitor the performance of multicast traffic. New + on-path telemetry techniques, such as IOAM [RFC9197], IOAM Direct + Export (DEX) [RFC9326], IOAM Postcard-Based Telemetry - Marking (PBT- + M) [POSTCARD-TELEMETRY], and Hybrid Two-Step (HTS) [HYBRID-TWO-STEP], + complement existing active OAM performance monitoring methods like + ICMP ping [RFC0792]. However, multicast traffic's unique + characteristics present challenges in applying these techniques + efficiently. + + The IP multicast packet data for a particular (S,G) state remains + identical across different branches to multiple receivers [RFC7761]. + When IOAM trace data is added to multicast packets, each replicated + packet retains telemetry data for its entire forwarding path. This + results in redundant data collection for common path segments, + unnecessarily consuming extra network bandwidth. For large multicast + trees, this redundancy is substantial. Using solutions like IOAM DEX + could be more efficient by eliminating data redundancy, but IOAM DEX + lacks a branch identifier, complicating telemetry data correlation + and multicast tree reconstruction. + + This document provides two solutions to the IOAM data-redundancy + problem based on the IOAM standards. The requirements for multicast + traffic telemetry are discussed along with the issues of the existing + on-path telemetry techniques. We propose modifications and + extensions to make these techniques adapt to multicast in order for + the original multicast tree to be correctly reconstructed while + eliminating redundant data. This document does not cover the + operational considerations such as how to enable the telemetry on a + subset of the traffic to avoid overloading the network or the data + collector. + +1.1. 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. + +2. Requirements for Multicast Traffic Telemetry + + Multicast traffic is forwarded through a multicast tree. With PIM + [RFC7761] and Point-to-Multipoint (P2MP), the forwarding tree is + established and maintained by the multicast routing protocol. + + The requirements for multicast traffic telemetry that are addressed + by the solutions in this document are: + + * Reconstruct and visualize the multicast tree through data-plane + monitoring. + + * Gather the multicast packet delay and jitter performance on each + path. + + * Find the multicast packet-drop location and reason. + + In order to meet all of 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 [RFC6450], trace [RFC8487], and RTCP [RFC3605], are + not sufficient to meet all of these requirements. The telemetry + methods in this document meet these requirements by providing + granular hop-by-hop network monitoring along with the reduction of + data redundancy. + +3. Issues of Existing Techniques + + On-path telemetry techniques that directly retrieve data from + multicast traffic's live network experience are ideal for addressing + the aforementioned requirements. The representative techniques + include IOAM Trace option [RFC9197], IOAM DEX option [RFC9326], and + PBT-M [POSTCARD-TELEMETRY]. However, unlike unicast, multicast poses + some unique challenges to applying these techniques. + + Multicast packets are replicated at each branch fork node in the + corresponding multicast tree. Therefore, there are multiple copies + of the original multicast packet in the network. + + When the IOAM trace option is utilized for on-path data collection, + partial trace data is replicated into the packet copy for each branch + of the multicast tree. Consequently, at the leaves of the multicast + tree, each copy of the multicast packet contains a complete trace. + This results in data redundancy, as most of the data (except from the + final leaf branch) appears in multiple copies, where only one is + sufficient. This redundancy introduces unnecessary header overhead, + wastes network bandwidth, and complicates data processing. The + larger the multicast tree or the longer the multicast path, the more + severe the redundancy problem becomes. + + The postcard-based solutions (e.g., IOAM DEX) can eliminate data + redundancy because each node on the multicast tree sends a postcard + with only local data. However, these methods cannot accurately track + and correlate the tree branches due to the absence of branching + information. For instance, in the multicast tree shown in Figure 1, + Node B has two branches, one to Node C and the other to node D; + further, Node C leads to Node E, and Node D leads to Node F (not + shown). When applying postcard-based methods, it is impossible to + determine whether Node E is the next hop of Node C or Node D from the + received postcards alone, unless one correlates the exporting nodes + with knowledge about the tree collected by other means (e.g., + mtrace). Such correlation is undesirable because it introduces extra + work and complexity. + + 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 and Extensions Based on Existing Solutions + + We provide two solutions to address the above issues. One is based + on IOAM DEX and requires an extension to the DEX Option-Type header. + 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. This works + for the IOAM DEX option because the DEX Option-Type header can be + used to hold the branch identifier. To make the branch identifier + globally unique, the Branching Node ID plus an index is used. For + example, as shown in Figure 1, Node B has two branches: one to Node C + and the other to Node D. Node B may use [B, 0] as the branch + identifier for the branch to C, and [B, 1] for the branch to D. The + identifier is 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 braces contain the telemetry data about a specific node. + + 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., Multicast Branch ID) for each branch in its multicast tree + instance and include it in the IOAM DEX Option-Type header. The + Multicast Branch ID remains unchanged until the next branch fork + node. The Multicast Branch ID contains two parts: the Branching Node + ID and an Interface Index. + + Conforming to the node ID specification in IOAM [RFC9197], the + Branching Node ID is a 3-octet unsigned integer. The Interface Index + is a two-octet unsigned integer. As shown in Figure 2, the Multicast + Branch ID consumes 8 octets in total. The three unused octets MUST + be set to 0; otherwise, the header is considered malformed and the + packet MUST be dropped. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Branching Node ID | unused | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Interface Index | unused | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 2: Multicast Branch ID Format + + Figure 3 shows that the Multicast Branch ID is carried as an optional + field after the Flow ID and Sequence Number optional fields in the + IOAM DEX option header. Two bits "N" and "I" (i.e., the third and + fourth bits in the Extension-Flags field) are reserved to indicate + the presence of the optional Multicast Branch ID field. "N" stands + for the Branching Node ID, and "I" stands for the Interface Index. + If "N" and "I" are both set to 1, the optional Multicast Branch ID + field is present. Two Extension-Flag bits are used because [RFC9326] + specifies that each extension flag only indicates the presence of a + 4-octet optional data field, while we need more than 4 octets to + encode the Multicast Branch ID. The two flag bits MUST be both set + or cleared; otherwise, the header is considered malformed and the + packet MUST be dropped. + + 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|N|I|E-Flags| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IOAM-Trace-Type | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Flow ID (optional) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sequence Number (optional) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Multicast Branch ID (as shown in Figure 2) | + | (optional) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 3: Carrying the Multicast Branch ID in the IOAM DEX + Option-Type Header + + Once a node gets the branch ID information from the upstream node, 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 + [RFC9197] and the postcard-based telemetry [IFIT-FRAMEWORK]. To + avoid data redundancy, at each branch fork node, the trace data + accumulated up to this node is exported by a postcard before the + packet is replicated. In this solution, each branch also 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 fork 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 + fork node can only contain the common data shared by all the + replicated packets (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 fork 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. + + 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 fork + nodes, as well as the leaf nodes, to export the postcards that + contain the trace data collected so far and refresh the IOAM header + and data in the packet (e.g., clear the node data list to all zeros + and reset the RemainingLen field to the initial value). + +5. Application Considerations for Multicast Protocols + +5.1. Mtrace Version 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 the tree-building messages follow from the receiver to + the source. An Mtrace2 client sends an Mtrace2 Query to a Last-Hop + Router (LHR), and the LHR forwards the packet as an Mtrace2 Request + towards the source or a Rendezvous Point (RP) after appending a + response block. Each router along the path proceeds with the same + operations. When the First-Hop Router (FHR) receives the Request + packet, it appends its own response block, turns the Request packet + into a Reply, and unicasts the Reply back to the Mtrace2 client. + + New on-path telemetry techniques will enhance Mtrace2, and other + existing OAM solutions, with more granular and real-time network + status data through direct measurements. There are various multicast + protocols that are used to forward the multicast data. Each will + require its own unique on-path telemetry solution. Mtrace2 doesn't + integrate with IOAM directly, but network management systems may use + Mtrace2 to learn about routers of interest. + +5.2. Application in PIM + + PIM - Sparse Mode (PIM-SM) [RFC7761] is the most widely used + multicast routing protocol deployed today. PIM - Source-Specific + Multicast (PIM-SSM), however, is the preferred method due to its + simplicity and removal of network source discovery complexity. With + PIM, control plane state is established in the network in order to + forward multicast UDP data packets. PIM utilizes network-based + source discovery. PIM-SSM, however, utilizes application-based + source discovery. IP multicast packets fall within the range of + 224.0.0.0 through 239.255.255.255 for IPv4 and ff00::/8 for IPv6. + The telemetry solution will need to work within these IP address + ranges 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 [RFC9486]. + +5.3. Application of MVPN PMSI Tunnel Attribute + + IOAM, and the recommendations of this document, are equally + applicable to multicast MPLS forwarded packets as described in + [RFC6514]. Multipoint Label Distribution Protocol (mLDP), P2MP RSVP- + TE, Ingress Replication (IR), and PIM Multicast Distribution Tree + (MDT) SAFI with GRE Transport are all commonly used within a + Multicast VPN (MVPN) environment utilizing MVPN procedures such as + multicast in MPLS/BGP IP VPNs [RFC6513] and BGP encoding and + procedures for multicast in MPLS/BGP IP VPNs [RFC6514]. mLDP LDP + extensions for P2MP and multipoint-to-multipoint (MP2MP) label + switched paths (LSPs) [RFC6388] provide extensions to LDP to + establish point-to-multipoint (P2MP) and MP2MP LSPs in 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. + +6. Security Considerations + + The schemes discussed in this document share the same security + considerations for the IOAM trace option [RFC9197] and the IOAM DEX + option [RFC9326]. In particular, since multicast has a built-in + nature for packet amplification, the possible amplification risk for + the DEX-based scheme is greater than the case of unicast. Hence, + stricter mechanisms for protections need to be applied. In addition + to selecting packets to enable DEX and to limit the exported traffic + rate, we can also allow only a subset of the nodes in a multicast + tree to process the option and export the data (e.g., only the + branching nodes in the multicast tree are configured to process the + option). + +7. IANA Considerations + + IANA has registered two Extension-Flags, as described in Section 4.1, + in the "IOAM DEX Extension-Flags" registry. + + +=====+=====================================+===========+ + | Bit | Description | Reference | + +=====+=====================================+===========+ + | 2 | Multicast Branching Node ID | This RFC | + +-----+-------------------------------------+-----------+ + | 3 | Multicast Branching Interface Index | This RFC | + +-----+-------------------------------------+-----------+ + + Table 1: IOAM DEX Extension-Flags + +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>. + + [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>. + + [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>. + + [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>. + + [RFC9326] Song, H., Gafni, B., Brockners, F., Bhandari, S., and T. + Mizrahi, "In Situ Operations, Administration, and + Maintenance (IOAM) Direct Exporting", RFC 9326, + DOI 10.17487/RFC9326, November 2022, + <https://www.rfc-editor.org/info/rfc9326>. + +8.2. Informative References + + [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-ietf-ippm-hybrid- + two-step-01, 5 July 2024, + <https://datatracker.ietf.org/doc/html/draft-ietf-ippm- + hybrid-two-step-01>. + + [IFIT-FRAMEWORK] + Song, H., Qin, F., Chen, H., Jin, J., and J. Shin, + "Framework for In-situ Flow Information Telemetry", Work + in Progress, Internet-Draft, draft-song-opsawg-ifit- + framework-21, 23 October 2023, + <https://datatracker.ietf.org/doc/html/draft-song-opsawg- + ifit-framework-21>. + + [MULTICAST-LESSONS-LEARNED] + Farinacci, D., Giuliano, L., McBride, M., and N. Warnke, + "Multicast Lessons Learned from Decades of Deployment + Experience", Work in Progress, Internet-Draft, draft-ietf- + pim-multicast-lessons-learned-04, 22 July 2024, + <https://datatracker.ietf.org/doc/html/draft-ietf-pim- + multicast-lessons-learned-04>. + + [POSTCARD-TELEMETRY] + Song, H., Mirsky, G., Zhou, T., Li, Z., Graf, T., Mishra, + G., Shin, J., and K. Lee, "On-Path Telemetry using Packet + Marking to Trigger Dedicated OAM Packets", Work in + Progress, Internet-Draft, draft-song-ippm-postcard-based- + telemetry-16, 2 June 2023, + <https://datatracker.ietf.org/doc/html/draft-song-ippm- + postcard-based-telemetry-16>. + + [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, + RFC 792, DOI 10.17487/RFC0792, September 1981, + <https://www.rfc-editor.org/info/rfc792>. + + [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute + in Session Description Protocol (SDP)", RFC 3605, + DOI 10.17487/RFC3605, October 2003, + <https://www.rfc-editor.org/info/rfc3605>. + + [RFC6450] Venaas, S., "Multicast Ping Protocol", RFC 6450, + DOI 10.17487/RFC6450, December 2011, + <https://www.rfc-editor.org/info/rfc6450>. + + [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>. + + [RFC9486] Bhandari, S., Ed. and F. Brockners, Ed., "IPv6 Options for + In Situ Operations, Administration, and Maintenance + (IOAM)", RFC 9486, DOI 10.17487/RFC9486, September 2023, + <https://www.rfc-editor.org/info/rfc9486>. + +Acknowledgments + + The authors would like to thank Gunter Van de Velde, Brett Sheffield, + Éric Vyncke, Frank Brockners, Nils Warnke, Jake Holland, Dino + Farinacci, Henrik Nydell, Zaheduzzaman Sarker, and Toerless Eckert + for their comments and suggestions. + +Authors' Addresses + + Haoyu Song + Futurewei Technologies + 2330 Central Expressway + Santa Clara, CA + United States of America + Email: hsong@futurewei.com + + + Mike McBride + Futurewei Technologies + 2330 Central Expressway + Santa Clara, CA + United States of America + Email: mmcbride@futurewei.com + + + Greg Mirsky + Ericsson + United States of America + Email: gregimirsky@gmail.com + + + Gyan Mishra + Verizon Inc. + United States of America + Email: gyan.s.mishra@verizon.com + + + Hitoshi Asaeda + National Institute of Information and Communications Technology + Japan + Email: asaeda@nict.go.jp + + + Tianran Zhou + Huawei Technologies + Beijing + China + Email: zhoutianran@huawei.com |