--- 1/draft-ietf-ippm-ioam-direct-export-05.txt 2021-08-08 04:13:25.690199601 -0700 +++ 2/draft-ietf-ippm-ioam-direct-export-06.txt 2021-08-08 04:13:25.722200403 -0700 @@ -1,30 +1,30 @@ IPPM H. Song Internet-Draft Futurewei Intended status: Standards Track B. Gafni -Expires: January 13, 2022 Nvidia +Expires: February 9, 2022 Nvidia T. Zhou Z. Li Huawei F. Brockners Cisco S. Bhandari, Ed. Thoughtspot R. Sivakolundu Cisco T. Mizrahi, Ed. Huawei - July 12, 2021 + August 8, 2021 In-situ OAM Direct Exporting - draft-ietf-ippm-ioam-direct-export-05 + draft-ietf-ippm-ioam-direct-export-06 Abstract In-situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information. Specifically, IOAM allows telemetry data to be pushed into data packets while they traverse the network. This document introduces a new IOAM option type called the Direct Export (DEX) option, which is used as a trigger for IOAM data to be directly exported or locally aggregated without being pushed into in-flight data packets. The @@ -38,21 +38,21 @@ 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." - This Internet-Draft will expire on January 13, 2022. + This Internet-Draft will expire on February 9, 2022. Copyright Notice Copyright (c) 2021 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 @@ -66,30 +66,31 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Requirement Language . . . . . . . . . . . . . . . . . . 3 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 3. The Direct Exporting (DEX) IOAM Option Type . . . . . . . . . 3 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1.1. DEX Packet Selection . . . . . . . . . . . . . . . . 5 3.1.2. Responding to the DEX Trigger . . . . . . . . . . . . 5 3.2. The DEX Option Format . . . . . . . . . . . . . . . . . . 6 - 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 - 4.1. IOAM Type . . . . . . . . . . . . . . . . . . . . . . . . 7 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 + 4.1. IOAM Type . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. IOAM DEX Flags . . . . . . . . . . . . . . . . . . . . . 8 - 5. Performance Considerations . . . . . . . . . . . . . . . . . 8 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 - 7.2. Informative References . . . . . . . . . . . . . . . . . 10 - Appendix A. Hop Limit and Hop Count in Direct Exporting . . . . 10 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 + 4.3. IOAM DEX Extension-Flags . . . . . . . . . . . . . . . . 8 + 5. Performance Considerations . . . . . . . . . . . . . . . . . 9 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 + 7.2. Informative References . . . . . . . . . . . . . . . . . 11 + Appendix A. Hop Limit in Direct Exporting . . . . . . . . . . . 11 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction IOAM [I-D.ietf-ippm-ioam-data] is used for monitoring traffic in the network, and for incorporating IOAM data fields into in-flight data packets. IOAM makes use of four possible IOAM options, defined in [I-D.ietf-ippm-ioam-data]: Pre-allocated Trace Option, Incremental Trace Option, Proof of Transit (POT) Option, and Edge-to-Edge Option. @@ -252,96 +253,148 @@ to prevent nested exporting and/or exporting loops. A transit IOAM node that does not support the DEX option SHOULD ignore it. A decapsulating node that does not support the DEX option MUST remove it, along with any other IOAM options carried in the packet if such exist. 3.2. The DEX Option Format The format of the DEX option is depicted in Figure 2. The length of - the DEX option is either 8 octets or 16 octets, as the Flow ID and - the Sequence Number fields (summing up to 8 octets) are optional. It - is assumed that the lower layer protocol indicates the length of the - DEX option, thus indicating whether the two optional fields are - present. + the DEX option is at least 8 octets. The DEX option MAY include one + or more optional fields. The existence of the optional fields is + indicated by the corresponding flags in the Extension-Flags field. + Two optional fields are defined in this document, the Flow ID and the + Sequence Number fields. Every optional field MUST be exactly 4 + octets long. Thus, the Extension-Flags field explicitly indicates + the length of the DEX option. Defining a new optional field requires + an allocation of a corresponding 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 | + | Namespace-ID | Flags |Extension-Flags| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IOAM-Trace-Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flow ID (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: DEX Option Format Namespace-ID A 16-bit identifier of the IOAM namespace, as defined in [I-D.ietf-ippm-ioam-data]. - Flags A 16-bit field, comprised of 16 one-bit subfields. + Flags An 8-bit field, comprised of 8 one-bit subfields. Flags are allocated by IANA, as defined in Section 4.2. + Extension-Flags An 8-bit field, comprised of 8 one-bit subfields. + Extension-Flags are allocated by IANA, as defined in + Section 4.3. Every bit in the Extension-Flag field + that is set to 1 indicates the existence of a + corresponding optional 4-octet field. An IOAM node + that receives a DEX option with an unknown flag set + to 1 MUST ignore the corresponding optional field. + IOAM-Trace-Type A 24-bit identifier which specifies which data fields should be exported. The format of this field is as defined in [I-D.ietf-ippm-ioam-data]. Specifically, - bit 23, which corresponds to the Checksum Complement - data field, should be assigned to be zero by the IOAM + the bit that corresponds to the Checksum Complement + data field should be assigned to be zero by the IOAM encapsulating node, and ignored by transit and decapsulating nodes. The reason for this is that the Checksum Complement is intended for in-flight packet modifications and is not relevant for direct exporting. Reserved This field SHOULD be ignored by the receiver. - Flow ID A 32-bit 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 uniformly - assigned by a central controller or algorithmically - generated by the encapsulating node. The latter - approach cannot guarantee the uniqueness of Flow ID, - yet the conflict probability is small due to the - large Flow ID space. The Flow ID can be used to - correlate the exported data of the same flow from - multiple nodes and from multiple packets. + Optional fields The optional fields, if present, reside after the + Reserved field. The order of the optional fields is + according to the respective bits that are enabled in + the Extension-Flags field. Each optional field is 4 + octets long. - Sequence Number A 32-bit sequence number starting from 0 and - increasing by 1 for each following monitored packet - from the same flow at the encapsulating node. The - Sequence Number, when combined with the Flow ID, + 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 uniformly assigned by a central controller + or algorithmically generated by the encapsulating + node. The latter approach cannot guarantee the + uniqueness of Flow ID, yet the conflict probability + is small due to the large Flow ID space. The Flow ID + can be used to correlate the exported data of the + same flow from multiple nodes and from multiple + packets. + + Sequence Number An optional 32-bit sequence number starting from 0 + and increasing by 1 for each following monitored + packet from the same flow at the encapsulating node. + The Sequence Number, when combined with the Flow ID, provides a convenient approach to correlate the exported data from the same user packet. 4. IANA Considerations 4.1. IOAM Type The "IOAM Type Registry" was defined in Section 7.2 of [I-D.ietf-ippm-ioam-data]. IANA is requested to allocate the following code point from the "IOAM Type Registry" as follows: TBD-type IOAM Direct Export (DEX) Option Type If possible, IANA is requested to allocate code point 4 (TBD-type). 4.2. IOAM DEX Flags IANA is requested to define an "IOAM DEX Flags" registry. This - registry includes 16 flag bits. Allocation should be performed based - on the "RFC Required" procedure, as defined in [RFC8126]. + registry includes 8 flag bits. Allocation is based on the "RFC + Required" procedure, as 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. + + 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 is requested to define an "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 "RFC Required" procedure, as defined in + [RFC8126]. + + Bit 0 "Flow ID [RFC XXXX] [RFC Editor: please replace with the RFC + number of the current document]" + + Bit 1 "Sequence Number [RFC XXXX] [RFC Editor: please replace with + the RFC number of the current document]" + + 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. + + Description: Brief description of the newly registered bit. + + Reference: Reference to the document that defines the new bit. 5. Performance Considerations The DEX option triggers IOAM data to be collected and/or exported packets to be exported to a receiving entity (or entities). In some cases this may impact the receiving entity's performance, or the performance along the paths leading to it. Therefore, the performance impact of these exported packets is limited by taking two measures: at the encapsulating nodes, by @@ -406,22 +459,22 @@ thus limiting the scope of the threats above and their affect. This is a fundamental assumption with respect to the security aspects of IOAM, as further discussed in [I-D.ietf-ippm-ioam-data]. 7. References 7.1. Normative References [I-D.ietf-ippm-ioam-data] Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields - for In-situ OAM", draft-ietf-ippm-ioam-data-12 (work in - progress), February 2021. + for In-situ OAM", draft-ietf-ippm-ioam-data-14 (work in + progress), June 2021. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . @@ -432,76 +485,58 @@ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 7.2. Informative References [I-D.ietf-ippm-ioam-flags] Mizrahi, T., Brockners, F., Bhandari, S., Sivakolundu, R., Pignataro, C., Kfir, A., Gafni, B., Spiegel, M., and J. - Lemon, "In-situ OAM Flags", draft-ietf-ippm-ioam-flags-04 - (work in progress), February 2021. + Lemon, "In-situ OAM Flags", draft-ietf-ippm-ioam-flags-05 + (work in progress), July 2021. [I-D.song-ippm-postcard-based-telemetry] Song, H., Mirsky, G., Filsfils, C., Abdelsalam, A., Zhou, T., Li, Z., Shin, J., and K. Lee, "Postcard-based On-Path Flow Data Telemetry using Packet Marking", draft-song- - ippm-postcard-based-telemetry-09 (work in progress), - February 2021. + ippm-postcard-based-telemetry-10 (work in progress), July + 2021. [I-D.spiegel-ippm-ioam-rawexport] Spiegel, M., Brockners, F., Bhandari, S., and R. Sivakolundu, "In-situ OAM raw data export with IPFIX", - draft-spiegel-ippm-ioam-rawexport-04 (work in progress), - November 2020. + draft-spiegel-ippm-ioam-rawexport-05 (work in progress), + July 2021. [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, . -Appendix A. Hop Limit and Hop Count in Direct Exporting +Appendix A. Hop Limit in Direct Exporting In order to help correlate and order the exported packets, it is possible to include the Hop_Lim/Node_ID data field in exported packets; if the IOAM-Trace-Type [I-D.ietf-ippm-ioam-data] has the Hop_Lim/Node_ID bit set, then exported packets include the Hop_Lim/ Node_ID data field, which contains the TTL/Hop Limit value from a lower layer protocol. An alternative approach was considered during the design of this document, according to which 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 starts from 0 at the encapsulating node and be incremented by each IOAM transit node that supports the DEX option. In this approach the Hop Count field value would also be included in the exported packet. - The main advantage of the Hop_Lim/Node_ID approach is that it - provides information about the current hop count without requiring - each transit node to modify the DEX option, thus simplifying the data - plane functionality of Direct Exporting. The main advantage of the - Hop Count approach that was considered is that it counts the number - of IOAM-capable nodes without relying on the lower layer TTL, - especially when the lower layer cannot prvide the accurate TTL - information, e.g., Layer 2 Ethernet or hierarchical VPN. The Hop - Count approach would also explicitly allow to detect a case where an - IOAM-capable node fails to export packets. It would also be possible - to use a flag to indicate an optional Hop Count field, which enables - to control the tradeoff. On one hand it would address the use cases - that the Hop_Lim/Node_ID cannot cover, and on the other hand it would - not require transit switches to update the option if it was not - supported or disabled. For the sake of simplicity the Hop Count - approach was not pursued, and this field is not incorporated in the - DEX header. - Authors' Addresses Haoyu Song Futurewei 2330 Central Expressway Santa Clara 95050 USA Email: haoyu.song@futurewei.com