idnits 2.17.00 (12 Aug 2021) /tmp/idnits6326/draft-mirsky-ippm-hybrid-two-step-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 : ---------------------------------------------------------------------------- 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 27, 2018) is 1544 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-01 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 Working Group G. Mirsky 3 Internet-Draft ZTE Corp. 4 Intended status: Informational W. Lingqiang 5 Expires: August 31, 2018 G. Zhui 6 ZTE Corporation 7 February 27, 2018 9 Hybrid Two-Step Performance Measurement Method 10 draft-mirsky-ippm-hybrid-two-step-00 12 Abstract 14 Development of and advancements in automation of network operations 15 brought new requirements toward measurement methodology. Among them 16 is ability to collect the instant telemetry as the packet being 17 processed by the networking elements along its path through the 18 domain. This document introduces new hybrid measurement method, 19 referred to as hybrid two-step, as it separates act of measuring and/ 20 or calculating performance metric from the act of collecting and 21 transporting telemetry. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 31, 2018. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Conventions used in this document . . . . . . . . . . . . . . 3 59 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 61 3. Problem Overview . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 68 8.2. Informative References . . . . . . . . . . . . . . . . . 6 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 71 1. Introduction 73 Successful resolution of challenges of automated network operation, 74 as part of overall life-cycle service orchestration, relies on 75 collection of accurate and timely information that reflects the state 76 of network elements on unprecedented massive, even grandiose scale. 77 Because analysis and action upon the it requires considerable 78 computing and storage resources, the network state information, also 79 referred to as telemetry, is unlikely to be processed by network 80 elements themselves but will be relayed into data lakes. The process 81 of producing telemetry information, collecting and transporting it 82 for post-processing should equally work with data flows and specially 83 inserted in the network test packets. Per [RFC7799] classification 84 such process classified as hybrid measurement method. 86 Several technical methods were proposed to enable collection of 87 telemetry information instantaneous to the packet processing. Among 88 them [P4.INT] and [I-D.ietf-ippm-ioam-data]. 90 This document introduces new hybrid measurement method, referred to 91 as Hybrid Two-step (HTS), that it separates measuring and/or 92 calculating performance metric from the collecting and transporting 93 telemetry. The hybrid two-step method extends two-step mode of 94 Residence Time Measurement (RTM) defined in [RFC8169] to on-path 95 telemetry collection and transport. 97 2. Conventions used in this document 99 2.1. Terminology 101 RTM Residence Time Measurement 103 ECMP Equal Cost Multipath 105 MTU Maximum Transmission Unit 107 HTS Hybrid Two-step 109 2.2. Requirements Language 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to be interpreted as described in BCP 114 14 [RFC2119] [RFC8174] when, and only when, they appear in all 115 capitals, as shown here. 117 3. Problem Overview 119 Performance measurements are meant to provide data that characterize 120 conditions experienced by data in the network and possibly trigger 121 operations to re-route flows, allocate additional or free excess of 122 resources. All changes to the network depend on the quality of 123 collected data and calculated based on its performance metrics. The 124 quality of measurements defined not only by resolution but by how 125 consistent are performed measurements, how predictable is the moment 126 of measurement making, of obtaining the data. Consider case of delay 127 measurement that relies on collection of time of packet arrival at 128 the ingress interface and time of packet transmission at egress 129 interface. The ideal method may read wall clock value as the very 130 first octet of the packet being received at ingress, and another 131 value, as the first octet being transmitted. That way all nodal 132 processing delays be accounted for as this method excludes packet 133 queuing. But if the measurement method requires the original packet 134 to carry either both time values of the calculated delay value, then 135 the packet must be modified on-the-fly, while being transmitted. And 136 that task may become even more challenging if the packet is 137 encrypted. As result, at egress time may be obtained before the 138 packet transmission begins, thus leaving variable delays unmeasured. 139 Similar problem may cause lower quality of, for example, information 140 that characterizes utilization of the egress interface. If unable to 141 obtain the data consistently, without variable delays for additional 142 processing, information may not accurately reflect the state at the 143 egress interface. To mitigate this problem [RFC8169] defined RTM 144 two-step mode. 146 Another challenge facing methods that collect telemetry into the 147 actual data packet is risk of exceeding size of Maximum Transmission 148 Unit (MTU), particularly if the packet traverses overlay domains or 149 VPNs. Since the fragmentation is not available at the transport 150 network, operators may have to reduce MTU size advertised to client 151 layer or risk missing telemetry data for the part, most probably the 152 latter part, of the path. 154 4. Theory of Operation 156 HTS method consists of the two phases: 158 o performing a measurement or obtaining telemetry information, one 159 or more than one type, on a node; 161 o collecting and transporting the measurement. 163 HTS uses HTS Control message to define types of measurement or 164 telemetry data collection requested from a node. HTS Control message 165 may be inserted into the data packet, as meta-data or shim, or be 166 transmitted in the specially constructed test packet. 168 To collect measurement and telemetry data from the nodes HTS method 169 uses the follow-up packet. The node that creates the HTS Control 170 message also originates the HTS follow-up packet. The follow-up 171 packet contains characteristic information, copied from the data 172 packet, sufficient for participating nodes to associate it with the 173 original packet. Exact composition of the characteristic information 174 is specific for each transport network and its definition is outside 175 the scope of this document. The follow-up packet also uses the same 176 encapsulation as the data packet. If not payload but only network 177 information used to load-balance flows in equal cost multipath 178 (ECMP), use of the network encapsulation identical to the data packet 179 should guarantee that the follow-up packet remains in-band, i.e. 180 traverses the same set of network elements, with the original data 181 packet. Only one outstanding follow-up packet may be on the node for 182 the given path. That means that if the node receives HTS Control 183 message for the flow on which it still waits for the follow-up packet 184 to the previous HTS Control message, the node will originate the 185 follow-up packet to transport the former set of the telemetry data 186 and transmit it before it transmits the follow-up packet with the 187 latest set of telemetry information. 189 5. IANA Considerations 191 This document doesn't have any IANA requirements. The section may be 192 deleted before the publication. 194 6. Security Considerations 196 Nodes that practice HTS method are presumed to share a trust model 197 that depends on the existence of a trusted relationship among them. 198 This is necessary as these nodes are expected to correctly modify 199 specific content of the data in the follow-up packet, and degree to 200 which HTS measurement is useful for network operation depends on this 201 ability. In practice, this means that those portions of messages 202 that contain the telemetry data cannot be covered by either 203 confidentiality or integrity protection. Though there are methods 204 that make it possible in theory to provide either or both such 205 protections and still allow for intermediate nodes to make detectable 206 but authenticated modifications, such methods do not seem practical 207 at present, particularly for protocols that used to measure latency 208 and/or jitter. 210 The ability to potentially authenticate and/or encrypt the telemetry 211 data for scenarios both with and without participation of 212 intermediate nodes that participate in HTS measurement is left for 213 further study. 215 While it is possible for a supposed compromised node to intercept and 216 modify the telemetry information in the follow-up packet, this is an 217 issue that exists for nodes in general - for any and all data that 218 may be carried over the particular networking technology - and is 219 therefore the basis for an additional presumed trust model associated 220 with existing network. 222 7. Acknowledgements 224 TBD 226 8. References 228 8.1. Normative References 230 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 231 Requirement Levels", BCP 14, RFC 2119, 232 DOI 10.17487/RFC2119, March 1997, 233 . 235 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 236 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 237 May 2017, . 239 8.2. Informative References 241 [I-D.ietf-ippm-ioam-data] 242 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 243 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 244 P., Chang, R., and d. daniel.bernier@bell.ca, "Data Fields 245 for In-situ OAM", draft-ietf-ippm-ioam-data-01 (work in 246 progress), October 2017. 248 [P4.INT] "In-band Network Telemetry (INT)", P4.org Specification, 249 October 2017. 251 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 252 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 253 May 2016, . 255 [RFC8169] Mirsky, G., Ruffini, S., Gray, E., Drake, J., Bryant, S., 256 and A. Vainshtein, "Residence Time Measurement in MPLS 257 Networks", RFC 8169, DOI 10.17487/RFC8169, May 2017, 258 . 260 Authors' Addresses 262 Greg Mirsky 263 ZTE Corp. 265 Email: gregimirsky@gmail.com 267 Wang Lingqiang 268 ZTE Corporation 269 No 19 ,East Huayuan Road 270 Beijing 100191 271 P.R.China 273 Phone: +86 10 82963945 274 Email: wang.lingqiang@zte.com.cn 276 Guo Zhui 277 ZTE Corporation 278 No 19 ,East Huayuan Road 279 Beijing 100191 280 P.R.China 282 Phone: +86 10 82963945 283 Email: guo.zhui@zte.com.cn