idnits 2.17.1 draft-mirsky-ippm-hybrid-two-step-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 (July 2, 2018) is 2130 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-03 Summary: 0 errors (**), 0 flaws (~~), 2 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: January 3, 2019 G. Zhui 6 ZTE Corporation 7 July 2, 2018 9 Hybrid Two-Step Performance Measurement Method 10 draft-mirsky-ippm-hybrid-two-step-01 12 Abstract 14 Development of, and advancements in, automation of network operations 15 brought new requirements for measurement methodology. Among them is 16 the ability to collect instant network state as the packet being 17 processed by the networking elements along its path through the 18 domain. This document introduces a new hybrid measurement method, 19 referred to as hybrid two-step, as it separates the act of measuring 20 and/or calculating performance metric from the act of collecting and 21 transporting network state. 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 January 3, 2019. 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 . . . . . . . . . . . . . . . . . . . . . 5 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 68 8.2. Informative References . . . . . . . . . . . . . . . . . 6 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 71 1. Introduction 73 Successful resolution of challenges of automated network operation, 74 as part of, for example, overall service orchestration or data center 75 operation, relies on a timely collection of accurate information that 76 reflects the state of network elements on an unprecedented scale. 77 Because performing the analysis and act upon the collected 78 information requires considerable computing and storage resources, 79 the network state information is unlikely to be processed by network 80 elements themselves but will be relayed into the data storage 81 facilities, e.g. data lakes. The process of producing, collecting 82 network state information also referred in this document as network 83 telemetry, and transporting it for post-processing should work 84 equally well with data flows or injected in the network test packets. 85 RFC 7799 [RFC7799] describes a combination of elements of passive and 86 active measurement as a hybrid measurement. 88 Several technical methods have been proposed to enable collection of 89 network state information instantaneous to the packet processing, 90 among them [P4.INT] and [I-D.ietf-ippm-ioam-data]. 92 This document introduces Hybrid Two-Step (HTS) as a new hybrid 93 measurement method that separates measuring or calculating 94 performance metric from the collecting and transporting this 95 information. The Hybrid Two-Step method extends the two-step mode of 96 Residence Time Measurement (RTM) defined in [RFC8169] to on-path 97 network state collection and transport. 99 2. Conventions used in this document 101 2.1. Terminology 103 RTM Residence Time Measurement 105 ECMP Equal Cost Multipath 107 MTU Maximum Transmission Unit 109 HTS Hybrid Two-Step 111 Network telemetry - the process of collecting and reporting of 112 network state 114 2.2. Requirements Language 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 118 "OPTIONAL" in this document are to be interpreted as described in BCP 119 14 [RFC2119] [RFC8174] when, and only when, they appear in all 120 capitals, as shown here. 122 3. Problem Overview 124 Performance measurements are meant to provide data that characterize 125 conditions experienced by traffic flows in the network and possibly 126 trigger operational changes (e.g. - re-route of flows, or changes in 127 resource allocations). Changes to a network are determined based on 128 the performance metric information available at the time that a 129 change is to be made. The correctness of this determination is based 130 on the quality of the collected metrics data. The quality of 131 collected measurement data is defined is defined by: 133 o the resolution and accuracy of each measurement; 135 o predictability of both the time at which each measurement is made 136 and the timeliness of measurement collection data delivery for 137 use. 139 Consider the case of delay measurement that relies on collecting time 140 of packet arrival at the ingress interface and time of the packet 141 transmission at egress interface. The method may be to record a 142 local clock value on receiving the first octet of an affected message 143 at the device ingress, and again to record the clock value on sending 144 the first byte of the same message at the device egress. In this 145 ideal case, the difference between the two recorded clock times 146 corresponds to the time that the message spent in traversing the 147 device. In practice, the times actually recorded can differ from the 148 ideal case by any fixed amount and a correction may then be applied 149 to compute the same time difference taking into account the known 150 fixed time associated with the actual measurement. In this way, the 151 resulting time difference reflects any variable delay associated with 152 queuing. 154 Depending on the implementation, it may be a challenge to compute the 155 difference between message arrival and departure times and - on the 156 fly - add the necessary residence time information to the same 157 message. And that task may become even more challenging if the 158 packet is encrypted. Implementations SHOULD NOT record a message 159 departure time that may be significantly inaccurate in an effort to 160 include a correlated/computed delay value, in the same message, as a 161 result of estimating the departure time while including any variable 162 time component (such as that associated with buffering and queuing of 163 messages). A similar problem may cause a lower quality of, for 164 example, information that characterizes utilization of the egress 165 interface. If unable to obtain the data consistently, without 166 variable delays for additional processing, information may not 167 accurately reflect the state at the egress interface. To mitigate 168 this problem [RFC8169] defined RTM two-step mode. 170 Another challenge associated with methods that collect network state 171 information into the actual data packet is the risk to exceed the 172 Maximum Transmission Unit (MTU) size, particularly if the packet 173 traverses overlay domains or VPNs. Since the fragmentation is not 174 available at the transport network, operators may have to reduce MTU 175 size advertised to client layer or risk missing network state data 176 for the part, most probably the latter part, of the path. 178 4. Theory of Operation 180 The HTS method consists of the two phases: 182 o performing a measurement or obtaining network state information, 183 one or more than one type, on a node; 185 o collecting and transporting the measurement. 187 HTS uses HTS Control message to define types of measurement or 188 network state data collection requested from a node. HTS Control 189 message may be inserted into the data packet, as meta-data or shim, 190 or be transmitted in a specially constructed test packet. 192 To collect measurement and network state data from the nodes HTS 193 method uses the follow-up packet. The node that creates the HTS 194 Control message also originates the HTS follow-up packet. The 195 follow-up packet contains characteristic information, copied from the 196 data packet, sufficient for participating nodes to associate it with 197 the original packet. The exact composition of the characteristic 198 information is specific for each transport network and its definition 199 is outside the scope of this document. The follow-up packet also 200 uses the same encapsulation as the data packet. If not payload but 201 only network information used to load-balance flows in equal cost 202 multipath (ECMP), use of the network encapsulation identical to the 203 data packet should guarantee that the follow-up packet remains in- 204 band, i.e. traverses the same set of network elements, with the 205 original data packet. Only one outstanding follow-up packet may be 206 on the node for the given path. That means that if the node receives 207 HTS Control message for the flow on which it still waits for the 208 follow-up packet to the previous HTS Control message, the node will 209 originate the follow-up packet to transport the former set of the 210 network state data and transmit it before it transmits the follow-up 211 packet with the latest set of network state information. 213 5. IANA Considerations 215 This document doesn't have any IANA requirements. The section may be 216 deleted before the publication. 218 6. Security Considerations 220 Nodes that practice HTS method are presumed to share a trust model 221 that depends on the existence of a trusted relationship among nodes. 222 This is necessary as these nodes are expected to correctly modify the 223 specific content of the data in the follow-up packet, and the degree 224 to which HTS measurement is useful for network operation depends on 225 this ability. In practice, this means that those portions of 226 messages that contain the network state data cannot be covered by 227 either confidentiality or integrity protection. Though there are 228 methods that make it possible in theory to provide either or both 229 such protections and still allow for intermediate nodes to make 230 detectable but authenticated modifications, such methods do not seem 231 practical at present, particularly for protocols that used to measure 232 latency and/or jitter. 234 The ability to potentially authenticate and/or encrypt the network 235 state data for scenarios both with and without the participation of 236 intermediate nodes that participate in HTS measurement is left for 237 further study. 239 While it is possible for a supposed compromised node to intercept and 240 modify the network state information in the follow-up packet, this is 241 an issue that exists for nodes in general - for any and all data that 242 may be carried over the particular networking technology - and is 243 therefore the basis for an additional presumed trust model associated 244 with an existing network. 246 7. Acknowledgments 248 TBD 250 8. References 252 8.1. Normative References 254 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 255 Requirement Levels", BCP 14, RFC 2119, 256 DOI 10.17487/RFC2119, March 1997, 257 . 259 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 260 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 261 May 2017, . 263 8.2. Informative References 265 [I-D.ietf-ippm-ioam-data] 266 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 267 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 268 P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, 269 "Data Fields for In-situ OAM", draft-ietf-ippm-ioam- 270 data-03 (work in progress), June 2018. 272 [P4.INT] "In-band Network Telemetry (INT)", P4.org Specification, 273 October 2017. 275 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 276 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 277 May 2016, . 279 [RFC8169] Mirsky, G., Ruffini, S., Gray, E., Drake, J., Bryant, S., 280 and A. Vainshtein, "Residence Time Measurement in MPLS 281 Networks", RFC 8169, DOI 10.17487/RFC8169, May 2017, 282 . 284 Authors' Addresses 286 Greg Mirsky 287 ZTE Corp. 289 Email: gregimirsky@gmail.com 291 Wang Lingqiang 292 ZTE Corporation 293 No 19 ,East Huayuan Road 294 Beijing 100191 295 P.R.China 297 Phone: +86 10 82963945 298 Email: wang.lingqiang@zte.com.cn 300 Guo Zhui 301 ZTE Corporation 302 No 19 ,East Huayuan Road 303 Beijing 100191 304 P.R.China 306 Phone: +86 10 82963945 307 Email: guo.zhui@zte.com.cn