idnits 2.17.00 (12 Aug 2021) /tmp/idnits12203/draft-song-ippm-ioam-data-validation-option-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 18, 2017) is 1676 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 (-03) exists of draft-brockners-inband-oam-requirements-02 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-00 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ippm H. Song, Ed. 3 Internet-Draft T. Zhou 4 Intended status: Standards Track Huawei 5 Expires: April 21, 2018 October 18, 2017 7 In-situ OAM Data Validation Option 8 draft-song-ippm-ioam-data-validation-option-01 10 Abstract 12 This document describes several potential performance scalability and 13 capability issues when implementing in-situ OAM on heterogenous 14 target network elements. The document proposes the corresponding 15 solutions and modifications to the current in-situ OAM specification 16 to mitigate the issues. Specifically, in-situ OAM is extended with 17 data validation fields to cope with the node processing capability. 18 We provide use cases to motivate our proposal and base the 19 modifications on the current in-situ OAM header format specification. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 21, 2018. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. In-situ OAM Sampling and Data Validation . . . . . . . . . . 3 57 2.1. Valid Node Bitmap and Valid Data Bitmap . . . . . . . . . 3 58 2.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Security Considerations . . . . . . . . . . . . . . . . . . . 5 60 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 62 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 5 63 7. Informative References . . . . . . . . . . . . . . . . . . . 5 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 In-situ OAM (iOAM) [I-D.brockners-inband-oam-requirements] records 69 OAM information within user packets while the packets traverse a 70 network. The data types and data formats for in-situ OAM data 71 records have been defined in [I-D.ietf-ippm-ioam-data]. We identify 72 several scalability issues for implementing the current iOAM 73 specification and propose solutions in this draft. 75 iOAM can designate the flow to add the iOAM header and collect data 76 on the flow forwarding path. The flow can have arbitrary 77 granularity. However, processing the data can be a heavy burden for 78 the network nodes, especially when some data needs to be calculated 79 by the node (e.g., the transit delay). If the flow traffic is heavy, 80 the node may not be able to handle the iOAM processing so many 81 performance issues may occur, such as long latency and packet drop. 83 Although it is good for the OAM applications to gain the detailed 84 information on every packet at every node, in many cases, such 85 information is often repetitive and redundant. The large quantity of 86 data would also burden the management plane which needs to collect 87 and stream the data for analytics. It is also possible that some 88 nodes cannot provide the requested data at all or are unwilling to 89 provide some data for security or privacy concerns. So a trade-off 90 is needed to balance the performance impact and the data availability 91 and completeness. 93 We provide several motivating examples. To minimize the network 94 impact, a network operator decides to collect the iOAM data only for 95 initial and last flow packets (e.g., TCP packets with SYN, FIN, and 96 RST flags). 98 In another example, a head node alternates two iOAM headers with each 99 requesting a subset of iOAM data. Hence, each node on the flow path 100 only needs to handle partial data. The requests can be balanced 101 without exhausting the network nodes. 103 The above two cases can be realized by manipulating the iOAM header 104 at the domain edge. It is also possible that a node is temporarily 105 under heavy traffic load. It is in danger of dropping packets if it 106 tries to satisfy all the iOAM data requests. In this case, it would 107 rather deny some requests than drop user traffic. This case can be 108 realized by adding some auxiliary fields in the iOAM header. 110 More examples are listed in Section 2.2. 112 2. In-situ OAM Sampling and Data Validation 114 Based on the observation in Section 1, the source edge node should be 115 able to define either the period or the probability to add the iOAM 116 header to the selected flow packet. In this way, only a subset of 117 the flow/sec packets would carry the OAM data, which not only reduces 118 the overall iOAM data quantity but also reduces the processing work 119 load of the network nodes. 121 2.1. Valid Node Bitmap and Valid Data Bitmap 123 It is possible that even an iOAM capable node will not add data to 124 the node data list as requested. In some cases, a node can be too 125 busy to handle the data request or some types of the requested data 126 is not available. Therefore, we propose to add two bitmaps, a valid 127 node bitmap and a valid data bitmap, to the iOAM specification. 129 The Node Valid Bitmap (NVB) is inserted before the Node Data List as 130 shown in Figure 1. Each bit in the NVB corresponds to a hop on the 131 packet's forwarding path. The bits are listed in the same order as 132 the hop on the packet's forwarding path. The bitmap is cleared to 133 all zero at first. If a hop can add data to the Node Data List, the 134 corresponding bit in the NVB is set to 1. The bit location for a hop 135 can be calculated from the length field (e.g, the bit index is equal 136 to SSize-RHop).The valid node data items in the node data list is 137 equal to the number of 1's in the NVB. 139 0 1 2 3 140 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 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Base OAM Trace Type |NodeLen| Flags | Octets-left | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Node Valid Bitmap (NVB) | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | | 147 | Node Data List [] | 148 | | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 Figure 1: iOAM Header Format with Node Valid Bitmap (NVB) 153 In addition to NVB, for each node data in the node data list, a Data 154 Valid Bitmap (DVB) is added before the node data. The number of bits 155 in the DVB is equal to the number of 1's in the OAM Trace Type 156 bitmaps (excluding the next trace type bitmap indicator bits). When 157 the bit is set, the corresponding data is valid in the node; 158 otherwise, the corresponding data is invalid so the management plane 159 should ignore it after the data is collected. 161 The size of the DVB can be padded to two or four bytes, which allow 162 up to 16 or 32 types of data to be included in a node. The node data 163 list format with the enhanced DVB is shown in Figure 2. 165 0 1 2 3 166 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 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Data Valid Bitmap (DVB) | Padding | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | | 171 | Node Data List [i] | 172 | | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 Figure 2: iOAM Node Data with Data Valid Bitmap (DVB) 177 2.2. Use Cases 179 We give some examples to show the usefulness of in-situ OAM sampling 180 and data validation features. 182 o An application needs to track a flow's forwarding path and knows 183 the path will not change frequently, so it sets a low sampling 184 rate to periodically insert the iOAM header to request the node 185 ID. 187 o In a heterogeneous data plane, some nodes support to provide data 188 x but the other nodes do not support it. However, an application 189 is still interested in collecting data x if available. In this 190 case, iOAM header can still be configured to ask for data x but 191 the nodes that cannot provide the data simply invalidates it by 192 resetting the corresponding bit in the valid data bitmap. 194 o Multiple sampling rate and multiple data request schema can be 195 defined for a flow based on applications requirements and the data 196 property, so for a flow packet, there can be no iOAM header or 197 different iOAM headers. The node does not need to process all 198 data all the time. 200 o For security reason, a node decides to not participate in the iOAM 201 data collection. While it processes the other iOAM header fields 202 as usual, it does not set the node valid bit in the Node Valid 203 Bitmap and add node data to the Node Data List. 205 3. Security Considerations 207 There is no extra security considerations beyond those have been 208 identified by in-situ OAM protocol. 210 4. IANA Considerations 212 This memo includes no request to IANA. 214 5. Acknowledgments 216 We would like to thank Frank Brockners, Carlos Pignataro, Shwetha 217 Bhandari, and Tal Mizrahi for helpful comments and suggestions. 219 6. Contributors 221 The document is inspired by numerous discussions with James N. 222 Guichard. He also provided significant comments and suggestions to 223 help improve this document. 225 7. Informative References 227 [I-D.brockners-inband-oam-requirements] 228 Brockners, F., Bhandari, S., Dara, S., Pignataro, C., 229 Gredler, H., Leddy, J., Youell, S., Mozes, D., Mizrahi, 230 T., <>, P., and r. remy@barefootnetworks.com, 231 "Requirements for In-situ OAM", draft-brockners-inband- 232 oam-requirements-02 (work in progress), October 2016. 234 [I-D.ietf-ippm-ioam-data] 235 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 236 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 237 P., Chang, R., and d. daniel.bernier@bell.ca, "Data Fields 238 for In-situ OAM", draft-ietf-ippm-ioam-data-00 (work in 239 progress), September 2017. 241 Authors' Addresses 243 Haoyu Song (editor) 244 Huawei 245 2330 Central Expressway 246 Santa Clara, 95050 247 USA 249 Email: haoyu.song@huawei.com 251 Tianran Zhou 252 Huawei 253 156 Beiqing Road 254 Beijing, 100095 255 P.R. China 257 Email: zhoutianran@huawei.com