idnits 2.17.1 draft-song-opsawg-ifit-framework-03.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. 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 (July 8, 2019) is 1754 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 405 == Outdated reference: A later version (-16) exists of draft-song-ippm-postcard-based-telemetry-04 == Outdated reference: A later version (-13) exists of draft-song-mpls-extension-header-02 -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSAWG H. Song, Ed. 3 Internet-Draft Futurewei 4 Intended status: Informational Z. Li 5 Expires: January 9, 2020 T. Zhou 6 Huawei 7 F. Qin 8 China Mobile 9 J. Shin 10 SK Telecom 11 J. Jin 12 LG U+ 13 July 8, 2019 15 In-situ Flow Information Telemetry Framework 16 draft-song-opsawg-ifit-framework-03 18 Abstract 20 In-situ Flow Information Telemetry (iFIT) is a framework for applying 21 on-path data plane telemetry techniques such as In-situ OAM (iOAM) 22 and Postcard-Based Telemetry (PBT). It enumerates several key 23 components and describes how these components are assembled to 24 achieve a complete working solution for on-path user traffic 25 telemetry in carrier networks. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 31 "OPTIONAL" in this document are to be interpreted as described in BCP 32 14 [RFC2119][RFC8174] when, and only when, they appear in all 33 capitals, as shown here. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on January 9, 2020. 51 Copyright Notice 53 Copyright (c) 2019 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Smart Flow and Data Selection . . . . . . . . . . . . . . . . 5 70 3. Export Data Reduction . . . . . . . . . . . . . . . . . . . . 5 71 4. Dynamic Network Probe . . . . . . . . . . . . . . . . . . . . 6 72 5. Encapsulation and Tunnel Modes . . . . . . . . . . . . . . . 6 73 6. On-demand Technique Selection and Integration . . . . . . . . 7 74 7. Summary and Future Work . . . . . . . . . . . . . . . . . . . 7 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 76 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 77 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 78 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 79 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 12.1. Normative References . . . . . . . . . . . . . . . . . . 8 81 12.2. Informative References . . . . . . . . . . . . . . . . . 8 82 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 85 1. Introduction 87 Application-aware network operation is important for user SLA 88 compliance, service path enforcement, fault diagnosis, and network 89 resource optimization. In-situ OAM (IOAM) 90 [I-D.brockners-inband-oam-data] and PBT 91 [I-D.song-ippm-postcard-based-telemetry] provide the direct on-path 92 experience of user traffic. These techniques are invaluable for 93 application-aware network operations in not only data center and 94 enterprise networks but also carrier networks. 96 However, successfully applying such techniques in carrier networks 97 poses several practical challenges: 99 o C1: IOAM and PBT incur extra packet processing which may strain 100 the network data plane. The potential impact on the forwarding 101 performance creates an unfavorable "observer effect" which not 102 only damages the fidelity of the measurement but also defies the 103 purpose of the measurement. 105 o C2: IOAM and PBT can generate a huge amount of OAM data which may 106 claim too much transport bandwidth and inundate the servers for 107 data collection, storage, and analysis. Increasing the data 108 handling capacity is technically viable but expensive. 110 o C3: The currently defined set of data is essential but limited. 111 As the network operation evolves to become intent-based and 112 automatic, and the trends of network virtualization, network 113 convergence, and packet-optical integration continue, more data 114 will be needed in an on-demand and interactive fashion. 115 Flexibility and extensibility on data acquiring must be 116 considered. 118 o C4: If we were to apply IOAM and PBT in today's carrier networks, 119 we must provide solutions to tailor the provider's network 120 deployment base and support an incremental deployment strategy. 121 That is, we need to come up with encapsulation schemes for various 122 predominant protocols such as Ethernet, IPv4, and MPLS with 123 backward compatibility and properly handle various transport 124 tunnels. 126 o C5: Applying only a single underlying telemetry technique may lead 127 to defective result. For example, packet drop can cause the lost 128 of the flow telemetry data and the packet drop location and reason 129 remains unknown if only IOAM is used. A comprehensive solution 130 needs the flexibility to switch between different underlying 131 techniques and adjust the configurations and parameters at 132 runtime. 134 To address these challenges, we propose a framework based on our 135 prototype experience which can help to build a workable data-plane 136 telemetry solution. We name the framework "In-situ Flow Information 137 Telemetry" (iFIT) to reflect the fact that this framework is 138 dedicated to the on-path telemetry data about user/application flow 139 experience. In future, other related data plane OAM techniques such 140 as IPFPM [RFC8321] can also be integrated into iFIT to provide richer 141 capabilities. The network architecture that applies iFIT is shown in 142 Figure 1. The key components of iFIT is listed as follows: 144 o Smart flow and data selection policy to address C1. 146 o Export data reduction to address C2. 148 o Dynamic network probe to address C3. 150 o Encapsulation and tunnel modes to address C4. 152 o On-demand technique selection to address C5. 154 +---------------------------------+ 155 | | 156 | iFIT Applications | 157 | | 158 +---------------------------------+ 159 ^ ^ 160 | | 161 V | 162 +------------+ +-----+-----+ 163 | | | | 164 | Controller | | Collector | 165 | | | | 166 +-----:------+ +-----------+ 167 : ^ 168 :configuration |telemetry data 169 : | 170 ...............:.....................|.......... 171 : : : | : 172 : +---------:---+-------------:---++---------:---+ 173 : | : | : | : | 174 V | V | V | V | 175 +------+-+ +-----+--+ +------+-+ +------+-+ 176 usr pkts | iFIT | | Path | | Path | | iFIT | 177 ====>| Head |====>| Node |==//==>| Node |====>| End |====> 178 | Node | | A | | B | | Node | 179 +--------+ +--------+ +--------+ +--------+ 181 Figure 1: iFIT Architecture 183 In the remaining of the document, we provide the detailed discussion 184 of the iFIT's components. 186 2. Smart Flow and Data Selection 188 In most cases, it is impractical to enable the data collection for 189 all the flows and for all the packets in a flow due to the potential 190 performance and bandwidth impacts. Therefore, a workable solution 191 must select only a subset of flows and flow packets to enable the 192 data collection, even though this means the loss of some information. 194 In data plane, the Access Control List (ACL) provides an ideal means 195 to determine the subset of flow(s). 196 [I-D.song-ippm-ioam-data-validation-option] describes how one can set 197 a sample rate or probability to a flow to allow only a subset of flow 198 packets to be monitored, how one can collect different set of data 199 for different packets, and how one can disable or enable data 200 collection on any specific network node. The document further 201 introduces enhancement to IOAM to allow any node to accept or deny 202 the data collection in full or partially. 204 Based on these flexible mechanisms, iFIT allows applications to apply 205 smart flow and data selection policies to suit the requirements. The 206 applications can dynamically change the policies at any time based on 207 the network load, processing capability, focus of interest, and any 208 other criteria. We have developed some adaptive algorithm which can 209 limit the performance impact and yet achieve the satisfactory 210 telemetry data density. 212 3. Export Data Reduction 214 The flow telemetry data can catch the dynamics of the network and the 215 interactions between user traffic and network. Nevertheless, the 216 data inevitably contain redundancy. It is advisable to remove the 217 redundancy from the data in order to reduce the data transport 218 bandwidth and server processing load. 220 In addition to efficiently encode the export data (e.g., IPFIX 221 [RFC7011] or protobuf [1]), iFIT can also cache the data and send the 222 accumulated data in batch if the data is not time sensitive. Various 223 deduplication and compression techniques can be applied on the batch 224 data. 226 From the application perspective, an application may only be 227 interested in some special events which can be derived from the 228 telemetry data. For example, in case that the forwarding delay of a 229 packet exceeds a threshold or a flow changes its forwarding path is 230 of interest, it is unnecessary to send the original raw data to the 231 data collecting and processing servers. Rather, iFIT takes advantage 232 of the in-network computing capability of network devices to process 233 the raw data and only push the event notifications to the subscribing 234 applications. 236 4. Dynamic Network Probe 238 Due to the limited data plane resource, it is unlikely one can 239 provide all the data all the time. On the other hand, the data 240 needed by applications may be arbitrary but ephemeral. It is 241 critical to meet the dynamic data requirements with limited resource. 243 Fortunately, data plane programmability allows iFit to dynamically 244 load new data probes. These on-demand probes are called Dynamic 245 Network Probes (DNP) [I-D.song-opsawg-dnp4iq]. DNP is the technique 246 to enable probes for customized data collection in different network 247 planes. When working with IOAM or PBT, DNP is loaded to the data 248 plane through incremental programming or configuration. The DNP can 249 effectively conduct data generation, processing, and aggregation. 251 DNP introduces enough flexibility and extensibility to iFIT. It can 252 implement the optimizations for export data reduction motioned in the 253 previous section. It can also generate custom data as required by 254 today and tomorrow's applications. 256 5. Encapsulation and Tunnel Modes 258 Since MPLS and IPv4 network are still prevalent in carrier networks. 259 iFIT provides solutions to apply IOAM and PBT in such networks. 260 PBT-M [I-D.song-ippm-postcard-based-telemetry] does not introduce new 261 headers to the packets so the trouble of encapsulation for IOAM and 262 PBT-I is avoided. If IOAM or PBT-I is preferred, 263 [I-D.song-mpls-extension-header] provides a means to encapsulate the 264 extra header using an MPLS extension header. As for IPv4, it is 265 possible to encapsulate the IOAM or PBT-I header in an IP option. 266 For example, RAO [RFC2113] can be used to indicate the presence of 267 the new header. 269 In carrier networks, it is common for user traffic to traverse 270 various tunnels for QoS, traffic engineering, or security. iFIT 271 supports both the uniform mode and the pipe mode for tunnel support 272 as described in [I-D.song-ippm-ioam-tunnel-mode]. With such 273 flexibility, the operator can either gain a true end-to-end 274 visibility or apply a hierarchical approach which isolates the 275 monitoring domain between customer and provider. 277 6. On-demand Technique Selection and Integration 279 With multiple underlying data collection and export techniques at its 280 disposal, iFIT can flexibly adapt to different network conditions and 281 different application requirements. 283 For example, depending on the types of data that are of interest, 284 iFIT may choose either IOAM or PBT to collect the data; if an 285 application needs to track down where the packets are lost, it may 286 switch from IOAM to PBT. 288 iFIT can further integrate multiple data plane monitoring and 289 measurement techniques together and present a comprehensive data 290 plane telemetry solution to network operating applications. 292 7. Summary and Future Work 294 iFIT is a framework for applying on-path data plane telemetry 295 techniques. Combining with algorithmic and architectural components, 296 iFIT framework enables a practical telemetry solution based on two 297 basic on-path traffic data collection patterns: passport (e.g., IOAM 298 trace and e2e modes) and postcard (e.g., PBT). 300 The operation of iFIT differs from both active OAM and passive OAM as 301 defined in [RFC7799]. It does not generate any active probe packets 302 or passively observe unmodified user packets. Instead, it modifies 303 selected user packets to collect useful information about them. 304 Therefore, the iFIT operation can be considered the third mode of 305 OAM, hybrid OAM, which can provide more flexible and accurate network 306 OAM. 308 There are many more challenges and corresponding solutions for iFIT 309 that we did not cover in the current version of this document. For 310 example, how the telemetry data are stored, analyzed, and visualized; 311 how the telemetry data interfaces and work with the network operation 312 applications which run machine learning and big data analytic 313 algorithms; and ultimately, how iFIT can support closed control loops 314 for autonomous networking? A complete iFIT framework should also 315 consider the cross-domain operations. We leave these topics for 316 future revisions. 318 8. Security Considerations 320 No specific security issues are identified other than those have been 321 discussed in IOAM and PBT drafts. 323 9. IANA Considerations 325 This document includes no request to IANA. 327 10. Contributors 329 TBD. 331 11. Acknowledgments 333 TBD. 335 12. References 337 12.1. Normative References 339 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 340 Requirement Levels", BCP 14, RFC 2119, 341 DOI 10.17487/RFC2119, March 1997, 342 . 344 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 345 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 346 May 2016, . 348 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 349 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 350 May 2017, . 352 12.2. Informative References 354 [I-D.brockners-inband-oam-data] 355 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 356 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 357 P., Chang, R., and d. daniel.bernier@bell.ca, "Data Fields 358 for In-situ OAM", draft-brockners-inband-oam-data-07 (work 359 in progress), July 2017. 361 [I-D.song-ippm-ioam-data-validation-option] 362 Song, H. and T. Zhou, "In-situ OAM Data Validation 363 Option", draft-song-ippm-ioam-data-validation-option-02 364 (work in progress), April 2018. 366 [I-D.song-ippm-ioam-tunnel-mode] 367 Song, H., Li, Z., Zhou, T., and Z. Wang, "In-situ OAM 368 Processing in Tunnels", draft-song-ippm-ioam-tunnel- 369 mode-00 (work in progress), June 2018. 371 [I-D.song-ippm-postcard-based-telemetry] 372 Song, H., Zhou, T., Li, Z., Shin, J., and K. Lee, 373 "Postcard-based On-Path Flow Data Telemetry", draft-song- 374 ippm-postcard-based-telemetry-04 (work in progress), June 375 2019. 377 [I-D.song-mpls-extension-header] 378 Song, H., Li, Z., Zhou, T., and L. Andersson, "MPLS 379 Extension Header", draft-song-mpls-extension-header-02 380 (work in progress), February 2019. 382 [I-D.song-opsawg-dnp4iq] 383 Song, H. and J. Gong, "Requirements for Interactive Query 384 with Dynamic Network Probes", draft-song-opsawg-dnp4iq-01 385 (work in progress), June 2017. 387 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 388 DOI 10.17487/RFC2113, February 1997, 389 . 391 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 392 "Specification of the IP Flow Information Export (IPFIX) 393 Protocol for the Exchange of Flow Information", STD 77, 394 RFC 7011, DOI 10.17487/RFC7011, September 2013, 395 . 397 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 398 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 399 "Alternate-Marking Method for Passive and Hybrid 400 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 401 January 2018, . 403 12.3. URIs 405 [1] https://developers.google.com/protocol-buffers/ 407 Authors' Addresses 409 Haoyu Song (editor) 410 Futurewei 411 2330 Central Expressway 412 Santa Clara 413 USA 415 Email: hsong@futurewei.com 416 Zhenbin Li 417 Huawei 418 156 Beiqing Road 419 Beijing, 100095 420 P.R. China 422 Email: lizhenbin@huawei.com 424 Tianran Zhou 425 Huawei 426 156 Beiqing Road 427 Beijing, 100095 428 P.R. China 430 Email: zhoutianran@huawei.com 432 Fengwei Qin 433 China Mobile 434 No. 32 Xuanwumenxi Ave., Xicheng District 435 Beijing, 100032 436 P.R. China 438 Email: qinfengwei@chinamobile.com 440 Jongyoon Shin 441 SK Telecom 442 South Korea 444 Email: jongyoon.shin@sk.com 446 Jaewhan Jin 447 LG U+ 448 South Korea 450 Email: daenamu1@lguplus.co.kr