idnits 2.17.1 draft-song-ippm-ioam-data-validation-option-02.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 (April 16, 2018) is 2173 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: October 18, 2018 April 16, 2018 7 In-situ OAM Data Validation Option 8 draft-song-ippm-ioam-data-validation-option-02 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 October 18, 2018. 38 Copyright Notice 40 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 60 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 62 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 63 7. Informative References . . . . . . . . . . . . . . . . . . . 6 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. It is also possible 107 that, due to the privacy concern or capability issues, a node cannot 108 satisfy the data request indicated in the iOAM header. In these 109 cases, it would rather deny some requests than drop user traffic. 110 This case can be realized by adding some auxiliary fields in the iOAM 111 header. 113 More examples are listed in Section 2.2. 115 2. In-situ OAM Sampling and Data Validation 117 Based on the observation in Section 1, the source edge node should be 118 able to define either the period or the probability to add the iOAM 119 header to the selected flow packet. In this way, only a subset of 120 the flow/sec packets would carry the OAM data, which not only reduces 121 the overall iOAM data quantity but also reduces the processing work 122 load of the network nodes. 124 Different data type bitmap templates can also be defined and used 125 selectively. For example, template A includes a subset of data and 126 template B includes another subset of data. The two templates can be 127 used in the iOAM header for a flow alternately or in any predefined 128 pattern. This is also an effective way to reduce the node processing 129 load. 131 2.1. Valid Node Bitmap and Valid Data Bitmap 133 It is possible that even an iOAM capable node will not add data to 134 the node data list as requested. In some cases, a node can be too 135 busy to handle the data request or some types of the requested data 136 is not available due to privacy and capability reasons. Therefore, 137 we propose to add two bitmaps, a valid node bitmap and a valid data 138 bitmap, to the iOAM specification. 140 The Node Valid Bitmap (NVB) is inserted before the Node Data List as 141 shown in Figure 1. Each bit in the NVB corresponds to a hop on the 142 packet's forwarding path. The bits are listed in the same order as 143 the hop on the packet's forwarding path. The bitmap is set to all 144 one at first. If a hop cannot add data to the Node Data List, the 145 corresponding bit in the NVB is cleared to 0. The bit location for a 146 hop can be calculated from the length field (e.g, the bit index is 147 equal to SSize-RHop).The valid node data items in the node data list 148 is equal to the number of 1's in the NVB. 150 0 1 2 3 151 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 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Base OAM Trace Type |NodeLen| Flags | Octets-left | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Node Valid Bitmap (NVB) | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | | 158 | Node Data List [] | 159 | | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 Figure 1: iOAM Header Format with Node Valid Bitmap (NVB) 164 NVB allows the head node to invalidate some nodes in advance. For 165 example, if the head node wants to exclude the odd-numbered nodes 166 from adding iOAM data, it can set all the corresponding bits to 0. 167 Then at each node, if it finds its corresponding bit in the NVB is 0, 168 it will simply skip the iOAM processing. 170 In addition to NVB, for each node data in the node data list, a Data 171 Valid Bitmap (DVB) is added before the node data. The number of bits 172 in the DVB is equal to the number of 1's in the OAM Trace Type 173 bitmaps (excluding the next trace type bitmap indicator bits). When 174 the bit is set, the corresponding data is valid in the node; 175 otherwise, the corresponding data is invalid so the management plane 176 should ignore it after the data is collected. 178 The size of the DVB can be padded to two or four bytes, which allow 179 up to 16 or 32 types of data to be included in a node. The node data 180 list format with the enhanced DVB is shown in Figure 2. 182 0 1 2 3 183 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 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Data Valid Bitmap (DVB) | Padding | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | | 188 | Node Data List [i] | 189 | | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 Figure 2: iOAM Node Data with Data Valid Bitmap (DVB) 194 2.2. Use Cases 196 We give some examples to show the usefulness of in-situ OAM sampling 197 and data validation features. 199 o An application needs to track a flow's forwarding path and knows 200 the path will not change frequently, so it sets a low sampling 201 rate to periodically insert the iOAM header to request the node 202 ID. 204 o In a heterogeneous data plane, some nodes support to provide data 205 x but the other nodes do not support it. However, an application 206 is still interested in collecting data x if available. In this 207 case, iOAM header can still be configured to ask for data x but 208 the nodes that cannot provide the data simply invalidates it by 209 resetting the corresponding bit in the valid data bitmap. 211 o Multiple sampling rate and multiple data request schema can be 212 defined for a flow based on applications requirements and the data 213 property, so for a flow packet, there can be no iOAM header or 214 different iOAM headers. The node does not need to process all 215 data all the time. 217 o For security reason, a node decides to not participate in the iOAM 218 data collection. While it processes the other iOAM header fields 219 as usual, it does not set the node valid bit in the Node Valid 220 Bitmap and add node data to the Node Data List. 222 o To reduce the node processing load, the head node alternately uses 223 two NVBs with one of them invalidating all the even-numbered nodes 224 and the other invalidating all the odd-numbered nodes. Therefore, 225 a node only needs to process the iOAM for every two packets of the 226 flow. 228 3. Security Considerations 230 There is no extra security considerations beyond those have been 231 identified by in-situ OAM protocol. 233 4. IANA Considerations 235 This memo includes no request to IANA. 237 5. Acknowledgments 239 We would like to thank Frank Brockners, Carlos Pignataro, Shwetha 240 Bhandari, and Tal Mizrahi for helpful comments and suggestions. 242 6. Contributors 244 The document is inspired by numerous discussions with James N. 245 Guichard. He also provided significant comments and suggestions to 246 help improve this document. 248 7. Informative References 250 [I-D.brockners-inband-oam-requirements] 251 Brockners, F., Bhandari, S., Dara, S., Pignataro, C., 252 Gredler, H., Leddy, J., Youell, S., Mozes, D., Mizrahi, 253 T., <>, P., and r. remy@barefootnetworks.com, 254 "Requirements for In-situ OAM", draft-brockners-inband- 255 oam-requirements-02 (work in progress), October 2016. 257 [I-D.ietf-ippm-ioam-data] 258 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 259 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 260 P., Chang, R., and d. daniel.bernier@bell.ca, "Data Fields 261 for In-situ OAM", draft-ietf-ippm-ioam-data-00 (work in 262 progress), September 2017. 264 Authors' Addresses 266 Haoyu Song (editor) 267 Huawei 268 2330 Central Expressway 269 Santa Clara, 95050 270 USA 272 Email: haoyu.song@huawei.com 273 Tianran Zhou 274 Huawei 275 156 Beiqing Road 276 Beijing, 100095 277 P.R. China 279 Email: zhoutianran@huawei.com