RFC 9630
Multicast On-Path Telemetry Using In Situ Operations, Administration, and Maintenance (IOAM)
🎀 RFC 9630: Multicast On-Path Telemetry Using In Situ Operations, Administration, and Maintenance (IOAM) 💖
Okay bestie, the title block first 📋✨ This one is from the IETF (Internet Engineering Task Force), and it's a Standards Track doc, so it's an official Internet Standard, not just an idea. The authors are H. Song and M. McBride from Futurewei Technologies, G. Mirsky from Ericsson, G. Mishra from Verizon Inc., H. Asaeda from NICT, and T. Zhou from Huawei Technologies. It came out in August 2024 with ISSN 2070-1721. The header doesn't list anything it obsoletes or updates, so this RFC doesn't replace or patch any earlier ones. 🦋
Abstract ✨
Okay so this doc gives you two solutions for on-path telemetry of multicast traffic using IOAM 🔥 IOAM is great for multicast, but multicast brings some unique problems 💀 The two fixes are built on the IOAM trace option and the direct export option. Together they help you correlate telemetry data and rebuild the multicast tree, and they do it without piling on duplicate data 👑
Status of This Memo 🌸
This is an Internet Standards Track document, bestie 💜
It's a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 7841.
Info about the current status of this doc, any errata, and how to send feedback lives 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) as they stand on the publication date. Please actually read these, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Revised BSD License describes 📜
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' Addresses1. Introduction 💖
IP multicast has been doing amazing things for decades 🌟 [MULTICAST-LESSONS-LEARNED] gives you a full history of how many multicast routing protocols were designed and deployed for all sorts of apps, and I'll point to a few of them here and in the Application Considerations section (Section 5). IP multicast has powered residential broadband for customers across operator networks, private MPLS customers, and internal corporate intranets 🏢 It's also behind real-time interactive online meetings, podcasts, IPTV, and real-time financial market data. All of those depend on UDP's unreliable transport 😬 So end-to-end QoS is a big deal for multicast deployments if you want a good experience for end users inside a given operational domain 💅
Real-time media streaming is where this gets dramatic 😭 If one packet inside a keyframe gets lost and forward error correction can't recover it, lots of receivers can't decode the later frames in the Group of Pictures (GoP). The result is video freezes or black screens until the next keyframe shows up. Delays that run unexpectedly long can also trigger timeouts, and you get the same mess. So multicast packet loss and delay can wreck application performance and user experience across a domain. Not cute 💀
Monitoring multicast traffic performance is essential ✨ Newer on-path telemetry techniques like IOAM [RFC9197], IOAM Direct Export (DEX) [RFC9326], IOAM Postcard-Based Telemetry - Marking (PBT-M) [POSTCARD-TELEMETRY], and Hybrid Two-Step (HTS) [HYBRID-TWO-STEP] work alongside existing active OAM performance monitoring methods, such as ICMP ping [RFC0792]. The catch is that multicast traffic has unique characteristics, and those make it hard to apply these techniques efficiently 🦋
Here's the tea ☕ For a particular (S,G) state, the IP multicast packet data stays identical across all the branches leading to multiple receivers [RFC7761]. When IOAM trace data gets added to multicast packets, every replicated packet holds telemetry for its entire forwarding path. That means common path segments get recorded over and over, and extra network bandwidth gets eaten up for nothing 🙈 On large multicast trees this redundancy is huge. IOAM DEX could fix a lot of that by cutting out the duplicates, but DEX doesn't carry a branch identifier. That makes correlating telemetry data and rebuilding the multicast tree way harder 😤
This document offers two fixes for the IOAM data-redundancy problem, and both are built on the IOAM standards 🎀 It covers the requirements for multicast traffic telemetry and the problems with the existing on-path techniques. Then it proposes changes and extensions so these techniques work for multicast. The goal is that the original multicast tree can be rebuilt correctly while redundant data gets eliminated ✨ One thing it does not cover is operational stuff, like how to turn on telemetry for just a subset of traffic so you don't overload the network or the data collector 🙅♀️
1.1. Requirements Language 🫶
Here's how the key words work in this doc: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, just like they do here 💜
2. Requirements for Multicast Traffic Telemetry 🌸
Multicast traffic gets forwarded through a multicast tree 🌳 With PIM [RFC7761] and Point-to-Multipoint (P2MP), the multicast routing protocol is what builds and maintains the forwarding tree.
These are the multicast traffic telemetry requirements that the solutions in this doc address:
- 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 🕵️♀️
To hit all of these, we need to be able to directly monitor multicast traffic and pull data out of the multicast packets themselves 🔍 The usual OAM tools, like multicast ping [RFC6450], trace [RFC8487], and RTCP [RFC3605], just aren't enough to cover everything. The telemetry methods in this doc meet the requirements by giving you granular hop-by-hop network monitoring and cutting down on data redundancy at the same time 🦋
3. Issues of Existing Techniques 🧚
On-path telemetry techniques that pull data straight from multicast traffic as it moves through the live network are the ideal fit for those requirements ✨ The main ones are the IOAM Trace option [RFC9197], the IOAM DEX option [RFC9326], and PBT-M [POSTCARD-TELEMETRY]. The problem is that, unlike unicast, multicast throws some unique curveballs at these techniques 🙃
Multicast packets get replicated at each branch fork node in the corresponding multicast tree. So the network ends up with multiple copies of the original multicast packet 👯♀️
When the IOAM trace option is used for on-path data collection, the partial trace data gets copied into the packet for each branch of the multicast tree. So by the time you reach the leaves of the tree, every copy of the packet carries a complete trace 😩 That's the redundancy problem. Most of the data (everything except what's on the final leaf branch) shows up in several copies, when only one would do. The result is unnecessary header overhead, wasted network bandwidth, and messier data processing. The bigger the multicast tree or the longer the multicast path, the worse the redundancy gets 📈
Postcard-based solutions, like IOAM DEX, can get rid of the redundancy because each node on the multicast tree sends a postcard with only its local data 💌 But these methods can't reliably track and correlate the tree branches, since there's no branching information to work with 😵💫 Take the multicast tree in Figure 1 as an example. Node B has two branches, one to Node C and one to Node D. Node C leads on to Node E, and Node D leads to Node F (not shown). With postcard-based methods, you can't tell from the received postcards alone whether Node E is the next hop of Node C or of Node D. The only way to figure it out is to correlate the exporting nodes with knowledge of the tree gathered some other way (for example, mtrace). That correlation is undesirable, because it adds extra work and complexity 🙄
The root cause is that there's no identifier, either implicit or explicit, to correlate the data on each branch 🔑
4. Modifications and Extensions Based on Existing Solutions 🌈
We've got two solutions for the issues above 💅 The first is based on IOAM DEX, and it needs an extension to the DEX Option-Type header. The second combines the IOAM trace option with postcards to remove the redundancy 🎉
Keep it coming, bestie! 💖
4.1. Per-Hop Postcard Using IOAM DEX ✨
okay so the postcard-based telemetry has this one weakness 🌳 it can't really track trees on its own. the fix is to add a branch identifier field 💅 and the IOAM DEX option is perfect for this because its DEX Option-Type header has room to hold the branch identifier 🎀 to make it globally unique, you combine the Branching Node ID with an index 🔥
say Node B has two branches, one to Node C and one to Node D 🦋 Node B can use [B, 0] as the branch identifier for the C branch and [B, 1] for the D branch. the identifier rides along with the multicast packet until the next branch fork node shows up 🧚 and every node MUST export the branch identifier from the IOAM DEX header it received in the postcards it sends 💖 the branch identifier plus the other fields, like Flow ID and Sequence Number, is enough for the data collector to rebuild the topology of the multicast tree 😭🫶
here's the picture. "P" is the postcard packet, the square brackets hold the branch identifier, and the curly braces hold the telemetry data about one 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 Postcardok now every branch fork node needs to make a unique branch identifier (aka the Multicast Branch ID) for each branch in its multicast tree instance ✨ and then pop it into the IOAM DEX Option-Type header 🎀 the Multicast Branch ID stays the same until the next branch fork node. it has two parts: the Branching Node ID and an Interface Index 👑
following the node ID spec in IOAM [RFC9197], the Branching Node ID is a 3-octet unsigned integer, and the Interface Index is a 2-octet unsigned integer 🍓 altogether the Multicast Branch ID eats 8 octets 🫶 the three unused octets MUST be set to 0. if they aren't, 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 FormatFigure 3 shows the Multicast Branch ID riding as an optional field right after the Flow ID and Sequence Number optional fields in the IOAM DEX option header 🦋 two bits, "N" and "I" (the third and fourth bits of the Extension-Flags field), are reserved to say the Multicast Branch ID is there. "N" is for the Branching Node ID and "I" is for the Interface Index 🌈 if N and I are both 1, the optional Multicast Branch ID field is present.
why two flag bits instead of one?? because [RFC9326] says each extension flag only signals a 4-octet optional data field, and the Multicast Branch ID needs more than 4 octets 🧠 the two flag bits MUST be both set or both 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 Headeronce a node gets the branch ID info from its upstream node, it MUST carry that info in the telemetry data export postcards it sends 🫶 that way the original multicast tree can be rebuilt correctly from the postcards 🎀✨
4.2. Per-Section Postcard for IOAM Trace 🦋
the second solution mixes the IOAM trace option [RFC9197] with postcard-based telemetry [IFIT-FRAMEWORK] 🌸 to avoid redundant data, each branch fork node exports the trace data gathered up to that point in a postcard before it replicates the packet 💅 each branch also needs some identifier so the postcards for each tree section can be correlated 🧚 the easiest way is to carry the branch fork node's data (including its ID) in the trace of each branch 🫶
this matters because each replicated copy can end up with different telemetry data, like node delay, egress timestamp, and egress interface 😭 so the local data a branch fork node exports can only include the stuff every replicated packet shares, like ingress interface and ingress timestamp 🌈
Figure 4 shows an example in part of a multicast tree 🍓 Node B and Node D are the branch fork nodes, and they each export a postcard covering the trace data for the previous section ✨ the end node of each path also exports its 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 Postcardgood news: there's no need to change the IOAM trace option header format as [RFC9197] defines it 🎀 we just configure the branch fork nodes and the leaf nodes to export postcards with the trace data collected so far, then refresh the IOAM header and data in the packet 🦋 that means clearing the node data list to all zeros and resetting the RemainingLen field to its initial value 💖
5. Application Considerations for Multicast Protocols 🌈
5.1. Mtrace Version 2 🔍
Mtrace version 2 (Mtrace2) [RFC8487] is a protocol that lets you trace an IP multicast routing path 💜 it gives extra info like packet rates and losses, plus other diagnostic stuff 🧠 unlike unicast traceroute, Mtrace2 traces the path the tree-building messages take from the receiver back to the source 🦋 an Mtrace2 client sends an Mtrace2 Query to a Last-Hop Router (LHR), and the LHR forwards it as an Mtrace2 Request toward the source or a Rendezvous Point (RP) after tacking on a response block 💅 every router along the way does the same thing 🫶 when the First-Hop Router (FHR) gets the Request packet, it adds its own response block, turns the Request into a Reply, and unicasts the Reply back to the Mtrace2 client 👑
new on-path telemetry techniques will level up Mtrace2 and other existing OAM solutions with more granular, real-time network status data from direct measurements ✨ there are lots of multicast protocols that forward multicast data, and each one will need 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 out there right now 👑 PIM - Source-Specific Multicast (PIM-SSM) is the preferred option though, because it's simpler and skips the whole network source discovery drama 💅 with PIM, control plane state gets set up in the network so multicast UDP data packets can be forwarded 🦋 PIM uses network-based source discovery, while PIM-SSM uses application-based source discovery 🎀
IP multicast packets live in the range 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 address ranges and provide telemetry data for this UDP traffic 🫶
a proposed way to encapsulate 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 in this document, apply just as well 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 in a Multicast VPN (MVPN) environment, using MVPN procedures like multicast in MPLS/BGP IP VPNs [RFC6513] and BGP encoding and procedures for multicast in MPLS/BGP IP VPNs [RFC6514] 🧚 mLDP LDP extensions for point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) label switched paths (LSPs) [RFC6388] extend LDP so it can set up 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 💀
okay bestie, this part is serious 😭 The schemes in this doc share the same security considerations as the IOAM trace option [RFC9197] and the IOAM DEX option [RFC9326]. The big twist is multicast. Multicast is built for packet amplification, so the amplification risk for the DEX-based scheme is greater than the unicast case 🚨 That means stricter protections are needed. Along with picking which packets get DEX turned on and limiting how fast data gets exported, you can also let only a subset of the nodes in a multicast tree process the option and export data. For example, only the branching nodes in the tree could be configured to do it 🌳✨
7. IANA Considerations 📋
IANA registered two Extension-Flags, described in Section 4.1, in the "IOAM DEX Extension-Flags" registry 🎀 Here's the table:
+=====+=====================================+===========+
| Bit | Description | Reference |
+=====+=====================================+===========+
| 2 | Multicast Branching Node ID | This RFC |
+-----+-------------------------------------+-----------+
| 3 | Multicast Branching Interface Index | This RFC |
+-----+-------------------------------------+-----------+
Table 1: IOAM DEX Extension-Flags8. References 📚
8.1. Normative References
These are the must-read ones, the ones the doc is built on 🫶
[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
These ones are the extra reading, the deep-dive playlist 🌈
[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 🫶
Huge thank-you to 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 💖 The whole squad showed up for this one ✨
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📦 where this page comes from
- ietf: rfc9630 2024-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms