idnits 2.17.1 draft-gafni-ippm-ioam-additional-data-fields-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-ippm-ioam-data]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 02, 2020) is 1268 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-10 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ippm B. Gafni 3 Internet-Draft Nvidia 4 Intended status: Standards Track H. Liu 5 Expires: May 6, 2021 R. Miao 6 Alibaba Group 7 M. Spiegel 8 Barefoot Networks, an Intel 9 company 10 November 02, 2020 12 Additional data fields for IOAM Trace Option Types 13 draft-gafni-ippm-ioam-additional-data-fields-00 15 Abstract 17 In-situ Operations, Administration, and Maintenance (IOAM) records 18 operational and telemetry information in the packet while the packet 19 traverses a path between two points in the network. This document 20 discusses additional data fields and associated data types to be 21 added to the IOAM data fileds described in [I-D.ietf-ippm-ioam-data]. 22 In-situ OAM data fields can be encapsulated into a variety of 23 protocols such as NSH, Segment Routing, Geneve, IPv6 (via extension 24 header), or IPv4. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 6, 2021. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 63 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Additional Data Fields . . . . . . . . . . . . . . . . . . . 3 65 3.1. IOAM Trace Option-Types Ammendments . . . . . . . . . . . 3 66 3.2. The Additional IOAM Node Data Fields and Associated 67 Formats . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 70 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 72 6.2. Informative References . . . . . . . . . . . . . . . . . 5 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 75 1. Introduction 77 In-situ Operations, Administration, and Maintenance (IOAM) records 78 operational and telemetry information in the packet while the packet 79 traverses a path between two points in the network. This document is 80 adding additional data fields that can be reported by the network as 81 part of IOAM. 83 2. Conventions 85 2.1. Requirements Language 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 89 "OPTIONAL" in this document are to be interpreted as described in BCP 90 14 [RFC2119] [RFC8174] when, and only when, they appear in all 91 capitals, as shown here. 93 2.2. Abbreviations 95 Abbreviations used in this document: 97 IOAM: In-situ Operations, Administration, and Maintenance 99 3. Additional Data Fields 101 This draft extends [I-D.ietf-ippm-ioam-data] with additional data 102 fields. The additional suggested data fields are: 104 o Transmitted Bytes from an interface 106 o Speed of an interface 108 o Interface errors 110 The addition of these new data fields is intended to help network 111 operators to better manage their networks, where more data is 112 requried with regards to the activity and quality of the network 113 ports. For example, one framework that may take advantage of these 114 new data fileds is HPCC, which is proposed at 115 [I-D.pan-tsvwg-hpccplus]. This section discusses the needed 116 ammendments to the IOAM Trace header and the format of the added data 117 fields themselves. 119 3.1. IOAM Trace Option-Types Ammendments 121 IOAM Trace Option-Types and their headers are defined in section 4.4 122 of [I-D.ietf-ippm-ioam-data]. As shown in section 4.4.1, the trace 123 option header includes an IOAM-Trace-Type which is a "A 24-bit 124 identifier which specifies which data types are used in this node 125 data list". In order to extend [I-D.ietf-ippm-ioam-data] it is 126 required to allocate respective bits specifying the additional data 127 fields to be added to the packet. This draft is asking for the 128 allocation of additional 2 bits: 130 Bit 12 When set indicates presence of Transmitted Bytes from an 131 interface. 133 Bit 13 When set indicates presence of Speed of an interface and 134 Interface errors. 136 Section 3.2 describes the new suggested data types and their formats. 138 3.2. The Additional IOAM Node Data Fields and Associated Formats 140 The Data fields and associated data types for each of the additional 141 IOAM Data Fields are shown below: 143 Transmitted Bytes from an interface: 4-octet field defined as 144 follows: 146 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 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | tx_bytes | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 tx_bytes: 4-octet unsigned integer field. This field indicates 152 how many bytes have been transmitted from the egress interface 153 the packet is going out from. Note that this field may wrap 154 around. As an example, for a 100Gbps port this field may wrap 155 around within less than 3 seconds. This field is usable to 156 determine the amount of data going through the path a flow is 157 going through. Following multiple packets traversing the same 158 interface, together with a timestamp, allows a network operator 159 to gauge the amount of traffic going through the interface in 160 total and relative to the flow it tracks. This data in turn 161 may help to better control the traffic and take decisions 162 related to the performance of the flow and the network. 164 Speed of an interface and Total errors of an interface: 4-octet 165 field defined as follows: 167 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 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | interface_| interface_errors | 170 | speed | | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 interface_speed: 6 bits unsigned integer field. This field 174 indicates the current operational speed of the interface. The 175 procedure to allocate, manage and map the interface_speed 176 values into the actual speed is beyond the scope of this 177 document. This field is usable to detect whether a packet or a 178 flow is going through a path which has enough capacity compared 179 to the expectation of the operator. Changes in the speed of 180 the connectivty may require changing routing decisions or 181 troubleshooting the links under consideration. When an 182 operator intends to take a decision about the amount of data to 183 transmit per flow, this data is helpful as well to track. 185 interface_errors: 26 bits unsigned integer field. This field 186 inciates how many errors, such as packet drops due to CRC 187 errors, have been detected on the interface used to deliver the 188 packet. This data is helpful in order to understand the risk 189 associated with the packet, or the flow it belongs to, as it 190 shows the quality of the interfaces it uses as part of its path 191 in the network. It can also point out potential issues that 192 other packets from the same flow might have experienced. 194 4. Security Considerations 196 TBD 198 5. IANA Considerations 200 TBD 202 6. References 204 6.1. Normative References 206 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 207 Requirement Levels", BCP 14, RFC 2119, 208 DOI 10.17487/RFC2119, March 1997, 209 . 211 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 212 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 213 May 2017, . 215 6.2. Informative References 217 [I-D.ietf-ippm-ioam-data] 218 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 219 for In-situ OAM", draft-ietf-ippm-ioam-data-10 (work in 220 progress), July 2020. 222 [I-D.pan-tsvwg-hpccplus] 223 Miao, R., Liu, H., Pan, R., Lee, J., Kim, C., Gafni, B., 224 and Y. Shpigelman, "HPCC++: Enhanced High Precision 225 Congestion Control", draft-pan-tsvwg-hpccplus-02 (work in 226 progress), September 2020. 228 Authors' Addresses 229 Barak Gafni 230 Nvidia 231 350 Oakmead Parkway, Suite 100 232 Sunnyvale, CA 94085 233 U.S.A. 235 Email: gbarak@nvidia.com 237 Hongqiang H. Liu 238 Alibaba Group 239 108th Ave NE, Suite 800 240 Bellevue, WA 98004 241 U.S.A. 243 Email: hongqiang.liu@alibaba-inc.com 245 Rui Miao 246 Alibaba Group 247 525 Almanor Ave, 4th Floor 248 Sunnyvale, CA 94085 249 USA 251 Email: miao.rui@alibaba-inc.com 253 Mickey Spiegel 254 Barefoot Networks, an Intel 255 company 256 4750 Patrick Henry Drive 257 Santa Clara, CA 95054 258 US 260 Email: mickey.spiegel@intel.com