RFC 9326
In Situ Operations, Administration, and Maintenance (IOAM) Direct Exporting
RFC 9326: In Situ Operations, Administration, and Maintenance (IOAM) Direct Exporting 🦋
okay bestie, this one is all about the Direct Exporting (DEX) Option-Type for IOAM, and it's giving main character energy 💅✨ Let me set the scene so you know who's who.
The authors are H. Song (Futurewei), B. Gafni (Nvidia), F. Brockners (Cisco), S. Bhandari (Thoughtspot), and T. Mizrahi (Huawei). It was published in November 2022 as a Standards Track document, which means the IETF community reviewed it and approved it for publication. ISSN 2070-1721. Iconic 👑
It doesn't obsolete or update any other RFCs, so it's a clean slate, no drama 🙈 And the title block is fully handled up top now, so you're caught up on the basics 🫶
Abstract 🌸
Okay so IOAM is the thing that records and collects operational and telemetry info, and it lets telemetry data get pushed into data packets while they're zooming through the network 🚀. This doc introduces a brand new IOAM option type called the "IOAM Direct Export (DEX) Option-Type" 🎀. The job of this option is to be a trigger, telling IOAM data to get directly exported or aggregated locally, without being shoved into in-flight data packets 💜. The exporting method and format are not covered here, so don't look for them in this one 🙈
Status of This Memo 🧚
This is an Internet Standards Track document 🔥. It's a product of the IETF, it represents the consensus of the IETF community, got public review, and was approved by the IESG. If you want more on Internet Standards, check Section 2 of RFC 7841 ✨. Current status, errata, and feedback info live at https://www.rfc-editor.org/info/rfc9326 🌈.
Copyright Notice 💖
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved 🔒. This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as in effect on the date of publication. Please review those carefully because they spell out your rights and restrictions 📜. Code Components pulled from 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 described in that license 💅.
Table of Contents 🍓
1. Introduction
2. Conventions
2.1. Requirements Language
2.2. Terminology
3. The Direct Exporting (DEX) IOAM-Option-Type
3.1. Overview
3.1.1. DEX Packet Selection
3.1.2. Responding to the DEX Trigger
3.2. The DEX Option-Type Format
4. IANA Considerations
4.1. IOAM Type
4.2. IOAM DEX Flags
4.3. IOAM DEX Extension-Flags
5. Performance Considerations
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Appendix A. Notes about the History of This Document
Acknowledgments
Contributors
Authors' Addresses1. Introduction ✨
Okay so IOAM [RFC9197] is what's used for monitoring traffic in the network and for stuffing IOAM data fields (called IOAM-Data-Fields) into in-flight data packets 📦.
IOAM has four possible IOAM-Option-Types, all defined in [RFC9197]: Pre-allocated Trace, Incremental Trace, Proof of Transit (POT), and Edge-to-Edge 🌟.
This doc defines a new IOAM-Option-Type called the "IOAM Direct Export (DEX) Option-Type" 🎀. It's used as a trigger for IOAM nodes to locally aggregate and process IOAM data, and/or export it to a receiving entity (or entities) 💌. Throughout the doc, this functionality gets called "collection" and/or "exporting" 🦋. In this context, a "receiving entity" is something living inside the IOAM domain, like a collector, analyzer, controller, decapsulating node, or a software module inside one of the IOAM nodes 🧚.
Now here's the tea ☕: even though it's called "Direct Export", whether a packet with a DEX Option-Type actually creates another packet depends on the deployment 🙈. Some deployments might just use the DEX packet to trigger local processing of Operations, Administration, and Maintenance (OAM) data. That local processing is not in scope for this document 💅.
2. Conventions 🌈
2.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.2. Terminology 🍓
Abbreviations used in this document:
- IOAM: In situ Operations, Administration, and Maintenance
- OAM: Operations, Administration, and Maintenance [RFC6291]
- DEX: Direct Exporting
3. The Direct Exporting (DEX) IOAM-Option-Type 🦋
3.1. Overview ✨
The DEX Option-Type is used as a trigger for collecting IOAM data locally or exporting it to a receiving entity (or entities) 📤. Specifically, it can trigger an IOAM node to collect IOAM data and locally aggregate it. That aggregated data can then be periodically pushed to a receiving entity, or pulled by one on-demand 🔥.
This Option-Type gets incorporated into data packets by an IOAM encapsulating node, and removed by an IOAM decapsulating node, as shown in Figure 1 🎀. Transit nodes can read it but not modify it 👀. The terms "IOAM encapsulating node", "IOAM decapsulating node", and "IOAM transit node" are defined in [RFC9197] 📖.
^
|Exported IOAM data
|
|
|
+--------------+------+-------+--------------+
| | | |
| | | |
User +---+----+ +---+----+ +---+----+ +---+----+
packets |Encapsu-| | Transit| | Transit| |Decapsu-|
--------->|lating |====>| Node |====>| Node |====>|lating |---->
|Node | | A | | B | |Node |
+--------+ +--------+ +--------+ +--------+
Insert DEX Export Export Remove DEX
option and IOAM data IOAM data option and
export data export data
Figure 1: DEX ArchitectureThe DEX Option-Type is a trigger to collect and/or export IOAM data 💫. The trigger applies to transit nodes, the decapsulating node, and the encapsulating node:
- An IOAM encapsulating node configured to incorporate the DEX Option-Type encapsulates the packets (or possibly a subset of them) it forwards with the DEX Option-Type, and MAY export and/or collect the requested IOAM data immediately 💖. Only IOAM encapsulating nodes are allowed to add the DEX Option-Type to a packet 🙅. An IOAM encapsulating node can also generate probe packets that carry the DEX Option-Type. These probes can be generated periodically or on-demand (for example, triggered by the management plane) 🧪. The specification of such probe packets is outside the scope of this document 💅.
- A transit node that processes a packet with the DEX Option-Type MAY export and/or collect the requested IOAM data 🚏.
- An IOAM decapsulating node that processes a packet with the DEX Option-Type MAY export and/or collect the requested IOAM data, and MUST decapsulate the IOAM header 🧹.
As in [RFC9197], the DEX Option-Type can be incorporated into all or a subset of the traffic forwarded by the encapsulating node, which gets discussed further in Section 3.1.1 🔍. IOAM nodes also respond to the DEX trigger by exporting and/or collecting IOAM data, either for all traversing packets that carry the DEX Option-Type, or selectively for just a subset of them. More on that in Section 3.1.2 🌸.
3.1.1. DEX Packet Selection 🍬
If an IOAM encapsulating node incorporates the DEX Option-Type into all the traffic it forwards, it could generate an excessive amount of exported data, which may overload the network and the receiving entity 😭. So an IOAM encapsulating node that supports the DEX Option-Type MUST support the ability to incorporate it selectively into a subset of the packets it forwards 🛑.
Various packet selection and sampling methods have been defined before, like [RFC7014] and [RFC5475] 📚. Similar techniques can be applied by an IOAM encapsulating node to apply DEX to a subset of the forwarded traffic ✨.
The subset of traffic forwarded or transmitted with a DEX Option-Type SHOULD NOT exceed 1/N of the interface capacity on any of the IOAM encapsulating node's interfaces 📏. This requirement applies to the total traffic carrying a DEX Option-Type, including forwarded traffic and probe packets generated by the IOAM encapsulating node 🧮. Here, N is a parameter that network operators can configure ⚙️. If there's an upper bound, M, on the number of IOAM transit nodes on any path in the network, then it is RECOMMENDED to use an N such that N >> M (that is, N is much greater than M) 🎯. The reasoning: a packet carrying a DEX Option-Type may trigger an exported packet from each IOAM transit node along the path, for a total of M exported packets 📦. So if N >> M, the number of exported packets is significantly lower than the number of data packets forwarded by the IOAM encapsulating node 🦋. If there's no prior knowledge about the network topology or size, it is RECOMMENDED to use N>100 🌈.
Part 1 of 3. More coming, so stay tuned bestie 💜🫶
3.1.2. Responding to the DEX Trigger
Okay bestie, so the DEX Option-Type is basically the packet's wishlist 🎀 It says which IOAM-Data-Fields should be exported and/or collected (see Section 3.2). Like we said earlier, the data can be collected locally, aggregated, and/or exported to a receiving entity either proactively or on-demand ✨ If the IOAM data does get exported, the format and encapsulation of that exported packet is not in the scope of this doc 📦 For example, the export format can be based on [IOAM-RAWEXPORT] 💅
An IOAM node doing DEX-triggered exporting MUST support the ability to limit the rate of exported packets 🛑 The export rate SHOULD be limited so the number of exported packets is significantly lower than the number of packets the device forwards 🌸 The exported data rate SHOULD NOT exceed 1/N of the interface capacity on any of the IOAM node's interfaces 🦋 It is RECOMMENDED to use N>100 💖 Depending on the IOAM node's architecture, the export rate may be limited to a lower number so the node doesn't get overloaded 🫶 An IOAM node MAY maintain a counter (or a set of counters) that tracks the times it gets a packet with the DEX Option-Type but doesn't collect and/or export data because of the rate limits 📊
IOAM nodes SHOULD NOT be configured to export packets over a path or a tunnel that is subject to IOAM direct exporting 🙈 Also, IOAM encapsulating nodes that can identify a packet as an IOAM exported packet MUST NOT push a DEX Option-Type into that packet. This requirement exists to stop nested exporting and/or exporting loops 🔁
Nested exports and export loops are the drama we're avoiding here, so please don't push a DEX Option-Type into an exported packet, periodt 💀
A transit or decapsulating IOAM node that gets an unknown IOAM-Option-Type ignores it (as defined in [RFC9197]). Specifically, nodes that don't support the DEX Option-Type ignore it 🧚 As [RFC9197] says, a decapsulating node removes the IOAM encapsulation and all of its IOAM-Option-Types. That includes the case where one of those options is a (possibly unknown) DEX Option-Type 🫠 Whether a node can skip over a (possibly unknown) DEX Option-Type during parsing or decapsulation depends on the specific encapsulation, which is outside the scope of this document. For example, when IOAM is encapsulated in IPv6 [IOAM-IPV6-OPTIONS], the DEX Option-Type sits in either a Hop-by-Hop options header or a Destination options header, so it can be skipped using the length field in the options header 🌈
3.2. The DEX Option-Type Format
Here's the layout, shown in Figure 2 🦋 The DEX Option-Type is at least 8 octets long. It MAY include one or more optional fields 💜 Whether each optional field is there is indicated by the matching flags in the Extension-Flags field. This doc defines two optional fields: the Flow ID and the Sequence Number ✨ Every optional field MUST be exactly 4 octets long, so the Extension-Flags field explicitly tells you the length of the DEX Option-Type 👑 Defining a new optional field requires allocating a matching flag in the Extension-Flags field, as specified in Section 4.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Namespace-ID | Flags |Extension-Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IOAM-Trace-Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow ID (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: DEX Option-Type FormatHere's what each field does 🧁
Namespace-ID: A 16-bit identifier of the IOAM namespace, as defined in [RFC9197] 🌷Flags: An 8-bit field made of 8 1-bit subfields. IANA allocates Flags, as defined in Section 4.2 🍓Extension-Flags: An 8-bit field made of 8 1-bit subfields. IANA allocates Extension-Flags, as defined in Section 4.3. Every bit in the Extension-Flags field that is set to 1 indicates that a corresponding optional 4-octet field exists. An IOAM node that receives a DEX Option-Type with an unknown flag set to 1 MUST ignore the corresponding optional field 🙅♀️IOAM-Trace-Type: A 24-bit identifier that specifies which IOAM-Data-Fields should be exported. The format of this field is as defined in [RFC9197]. The bit that corresponds to the Checksum Complement IOAM-Data-Field SHOULD be assigned to be zero by the IOAM encapsulating node, and it SHOULD be ignored by transit and decapsulating nodes. The reason is that the Checksum Complement is meant for in-flight packet modifications, so it isn't relevant for direct exporting 🧐Reserved: This field MUST be ignored by the receiver 🫧- Optional fields: If they're present, the optional fields come after the Reserved field. Their order follows the order of the respective bits (starting from the most significant bit) that are enabled in the Extension-Flags field. Each optional field is 4 octets long 🧩
Flow ID: An optional 32-bit field representing the flow identifier. If the actual Flow ID is shorter than 32 bits, it is zero padded in its most significant bits. The field is set at the encapsulating node. The Flow ID can be used to correlate the exported data of the same flow from multiple nodes and from multiple packets. Flow ID values are expected to be allocated in a way that avoids collisions. For example, random assignment of Flow ID values can be subject to collisions, while centralized allocation can avoid this problem. The specification of the Flow ID allocation method is not within the scope of this document 🦄Sequence Number: An optional 32-bit sequence number that starts from 0 and is incremented by 1 for each packet from the same flow at the encapsulating node that includes the DEX option. The Sequence Number, when combined with the Flow ID, gives you a handy way to correlate the exported data from the same user packet 🔗
4. IANA Considerations
4.1. IOAM Type
The "IOAM Option-Type" registry is defined in Section 7.1 of [RFC9197]. IANA has allocated the following code point from the "IOAM Option-Type" registry 🗂️
Code Point: 4
Name IOAM Direct Export (DEX) Option-Type
Description: Direct exporting
Reference: This document4.2. IOAM DEX Flags
IANA has created the "IOAM DEX Flags" registry. This registry includes 8 flag bits. Allocation is based on the "IETF Review" procedure defined in [RFC8126] 🍒
New registration requests MUST use the following template 📝
Bit: Desired bit to be allocated in the 8-bit Flags field of the DEX
Option-Type.
Description: Brief description of the newly registered bit.
Reference: Reference to the document that defines the new bit.4.3. IOAM DEX Extension-Flags
IANA has created the "IOAM DEX Extension-Flags" registry. This registry includes 8 flag bits. Bit 0 (the most significant bit) and bit 1 in the registry are allocated by this document and described in Section 3.2. Allocation of the other bits should be performed based on the "IETF Review" procedure defined in [RFC8126] 🌟
Bit 0: "Flow ID [RFC9326]"
Bit 1: "Sequence Number [RFC9326]"New registration requests MUST use the following template 💌
Bit: Desired bit to be allocated in the 8-bit Extension-Flags field
of the DEX Option-Type.
Description: Brief description of the newly registered bit.
Reference: Reference to the document that defines the new bit.5. Performance Considerations
The DEX Option-Type triggers IOAM data to be collected and/or packets to be exported to a receiving entity (or entities). In some cases, this may affect the receiving entity's performance, or the performance along the paths leading to it 🐢
So the performance impact of these exported packets is kept in check in two ways 🛡️ First, at the encapsulating nodes, through selective DEX encapsulation (Section 3.1.1). Second, at the transit nodes, by limiting the exporting rate (Section 3.1.2). Together, these ensure that direct exporting runs at a rate that doesn't significantly affect network bandwidth and doesn't overload the receiving entity 💪 It's also possible to load balance the exported data across multiple receiving entities, although the exporting method is not within the scope of this document ⚖️
It should be noted that in some networks, DEX data may be exported over an out-of-band network where a large volume of exported traffic doesn't compromise user traffic 🌤️ In that case, an operator may choose to disable the exporting rate limiting 🌸
6. Security Considerations 🔐
okay bestie, security is serious, but it can still be iconic 💅 The general IOAM security stuff is in [RFC9197]. The main thing is that an attacker might try to use the functionality in this doc to mess with the network 😤
An attacker could try to overload network devices by injecting synthetic packets that carry the DEX Option-Type 🚨 An on-path attacker could also sneakily add the DEX Option-Type into transit packets, or remove it from packets that already have it. Not it 🙅♀️
Forcing DEX, whether in synthetic packets or transit packets, can overload the IOAM nodes and/or the receiving entity (or entities) 😭 Since this touches lots of devices along the path, it can potentially amplify the effect on network bandwidth, on the storage of the devices collecting the data, and on the receiving entity's load. Main character drama 🎭
The amplification can get even worse in wide area networks with multiple IOAM-Domains 🌍 For example, say DEX is used in IOAM-Domain 1 to export IOAM data to a receiving entity. The exported packets from IOAM-Domain 1 can then get forwarded through IOAM-Domain 2, where they're subject to DEX too. Then the exported packets from IOAM-Domain 2 might get forwarded through another IOAM domain (or back through IOAM-Domain 1). In theory, this recursive amplification could keep going forever 🌀 yikes.
To mitigate the attacks above, the following requirements (Section 3) were defined 🛡️
- Selective DEX (Section 3.1.1) is applied by IOAM encapsulating nodes so the potential impact of DEX attacks gets limited to a small fraction of the traffic.
- Rate limiting of exported traffic (Section 3.1.2) is applied by IOAM nodes to prevent overloading attacks and to significantly limit the scale of amplification attacks.
- IOAM encapsulating nodes are required to avoid pushing the DEX Option-Type into IOAM exported packets (Section 3.1.2), which prevents some of the amplification and export loop scenarios.
Even though the exporting method is out of scope for this doc, any exporting method MUST secure the exported data from the IOAM node to the receiving entity, to protect confidentiality and guarantee integrity 🔒✨ Specifically, an IOAM node that does DEX exporting MUST send the exported data to a pre-configured trusted receiving entity that's in the same IOAM-Domain as the exporting IOAM node. Also, an IOAM node MUST gain explicit consent to export data to a receiving entity before it starts sending exported data. No surprise exports, periodt 🙅♀️
An attacker could keep track of the info sent in DEX headers as a way to do reconnaissance 🕵️♀️ This recon can be mitigated to some extent by carefully allocating the Flow ID and Sequence Number space in a way that doesn't compromise privacy aspects, such as customer identities 🫣
The integrity of the DEX Option-Type can be protected through a mechanism of the encapsulating protocol 🧚 [IOAM-DATA-INTEGRITY] introduces an integrity protection mechanism that protects the integrity of IOAM-Data-Fields, but the DEX Option-Type doesn't include IOAM-Data-Fields. So those integrity protection mechanisms aren't applicable to the DEX Option-Type 💔 As discussed in the threat analysis of [IOAM-DATA-INTEGRITY], injection or modification of IOAM-Option-Type headers are threats that IOAM doesn't address.
IOAM is assumed to be deployed in a restricted administrative domain 🏰 That limits the scope of the threats above and their effect. This is a fundamental assumption for IOAM's security aspects, as further discussed in [RFC9197] 👑
7. References 📚
7.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>.
[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>.7.2. Informative References
[IOAM-DATA-INTEGRITY]
Brockners, F., Bhandari, S., Mizrahi, T., and J. Iurman,
"Integrity of In-situ OAM Data Fields", Work in Progress,
Internet-Draft, draft-ietf-ippm-ioam-data-integrity-02, 5
July 2022, <https://datatracker.ietf.org/doc/html/draft-
ietf-ippm-ioam-data-integrity-02>.
[IOAM-IPV6-OPTIONS]
Bhandari, S. and F. Brockners, "In-situ OAM IPv6 Options",
Work in Progress, Internet-Draft, draft-ietf-ippm-ioam-
ipv6-options-09, 11 October 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-ippm-
ioam-ipv6-options-09>.
[IOAM-RAWEXPORT]
Spiegel, M., Brockners, F., Bhandari, S., and R.
Sivakolundu, "In-situ OAM raw data export with IPFIX",
Work in Progress, Internet-Draft, draft-spiegel-ippm-ioam-
rawexport-06, 21 February 2022,
<https://datatracker.ietf.org/doc/html/draft-spiegel-ippm-
ioam-rawexport-06>.
[POSTCARD-BASED-TELEMETRY]
Song, H., Mirsky, G., Filsfils, C., Abdelsalam, A., Zhou,
T., Li, Z., Graf, T., Mishra, G. S., Shin, J., and K. Lee,
"Marking-based Direct Export for On-path Telemetry", Work
in Progress, Internet-Draft, draft-song-ippm-postcard-
based-telemetry-14, 7 September 2022,
<https://datatracker.ietf.org/doc/html/draft-song-ippm-
postcard-based-telemetry-14>.
[RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F.
Raspall, "Sampling and Filtering Techniques for IP Packet
Selection", RFC 5475, DOI 10.17487/RFC5475, March 2009,
<https://www.rfc-editor.org/info/rfc5475>.
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
D., and S. Mansfield, "Guidelines for the Use of the "OAM"
Acronym in the IETF", BCP 161, RFC 6291,
DOI 10.17487/RFC6291, June 2011,
<https://www.rfc-editor.org/info/rfc6291>.
[RFC7014] D'Antonio, S., Zseby, T., Henke, C., and L. Peluso, "Flow
Selection Techniques", RFC 7014, DOI 10.17487/RFC7014,
September 2013, <https://www.rfc-editor.org/info/rfc7014>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC9322] Mizrahi, T., Brockners, F., Bhandari, S., Gafni, B., and
M. Spiegel, "In Situ Operations, Administration, and
Maintanence (IOAM) Loopback and Active Flags", RFC 9322,
DOI 10.17487/RFC9322, November 2022,
<https://www.rfc-editor.org/info/rfc9322>.Appendix A. Notes about the History of This Document 📜
This doc grew out of combining some ideas from PBT-I in [POSTCARD-BASED-TELEMETRY] with immediate exporting from early versions of [RFC9322] 🕰️
To help correlate and order the exported packets, you can include the Hop_Lim/Node_ID IOAM-Data-Field in exported packets ✨ If the IOAM-Trace-Type [RFC9197] has the Hop_Lim/Node_ID bit set, then exported packets include the Hop_Lim/Node_ID IOAM-Data-Field, which holds the TTL/Hop Limit value from a lower layer protocol. An alternative approach was considered during the design of this doc: a 1-octet Hop Count field would be included in the DEX header (presumably by claiming some space from the Flags field). The Hop Limit would start at 0 at the encapsulating node and get incremented by each IOAM transit node that supports the DEX Option-Type. In this approach, the Hop Count field value would also be included in the exported packet 🧠
Acknowledgments 🫶
The authors thank Martin Duke, Tommy Pauly, Meral Shirazipour, Colin Perkins, Stephen Farrell, Linda Dunbar, Justin Iurman, Greg Mirsky, and other members of the IPPM working group for their many helpful comments 💖
Contributors 🎀
The Editors would like to recognize the contributions of the following individuals to this document 💜
Tianran Zhou
Huawei
156 Beiqing Rd.
Beijing
100095
China
Email: zhoutianran@huawei.com
Zhenbin Li
Huawei
156 Beiqing Rd.
Beijing
100095
China
Email: lizhenbin@huawei.com
Ramesh Sivakolundu
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
United States of America
Email: sramesh@cisco.comAuthors' Addresses 💌
Haoyu Song
Futurewei
2330 Central Expressway
Santa Clara, 95050
United States of America
Email: haoyu.song@futurewei.com
Barak Gafni
Nvidia
Suite 100
350 Oakmead Parkway
Sunnyvale, CA 94085
United States of America
Email: gbarak@nvidia.com
Frank Brockners
Cisco Systems, Inc.
Hansaallee 249
40549 Duesseldorf
Germany
Email: fbrockne@cisco.com
Shwetha Bhandari
Thoughtspot
3rd Floor, Indiqube Orion, Garden Layout, HSR Layout
24th Main Rd
Bangalore 560 102
Karnataka
India
Email: shwetha.bhandari@thoughtspot.com
Tal Mizrahi
Huawei
8-2 Matam
Haifa 3190501
Israel
Email: tal.mizrahi.phd@gmail.com📦 where this page comes from
- ietf: rfc9326 2022-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms