idnits 2.17.1 draft-song-opsawg-ifit-framework-04.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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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 (September 6, 2019) is 1693 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 476 == Unused Reference: 'RFC8321' is defined on line 468, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-herbert-ipv4-eh-01 == Outdated reference: A later version (-07) exists of draft-kumar-ippm-ifa-01 == Outdated reference: A later version (-15) exists of draft-mirsky-ippm-hybrid-two-step-03 == 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 == Outdated reference: A later version (-14) exists of draft-zhou-ippm-enhanced-alternate-marking-03 -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) Summary: 2 errors (**), 0 flaws (~~), 9 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: March 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 September 6, 2019 15 In-situ Flow Information Telemetry Framework 16 draft-song-opsawg-ifit-framework-04 18 Abstract 20 Unlike the existing active and passive OAM techniques, the emerging 21 on-path flow telemetry techniques provide unmatched visibility into 22 user traffic, showing great application potential not only for 23 today's network OAM but also for future's automatic network 24 operation. Summarizing the current industry practices that addresses 25 the deployment challenges and application requirements, we provide a 26 closed-loop framework, named In-situ Flow Information Telemetry 27 (iFIT), for efficiently applying a family of underlying on-path flow 28 telemetry techniques in various network environments. The framework 29 enumerates several key architectural components and describes how 30 these components are assembled together to achieve a complete and 31 closed-loop working solution for on-path flow telemetry. Following 32 such a framework allows better scalability, fosters application 33 innovations, and promotes both vertical and horizontal 34 interoperability. 36 Requirements Language 38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 39 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 40 "OPTIONAL" in this document are to be interpreted as described in BCP 41 14 [RFC2119][RFC8174] when, and only when, they appear in all 42 capitals, as shown here. 44 Status of This Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at https://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on March 9, 2020. 61 Copyright Notice 63 Copyright (c) 2019 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (https://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the Simplified BSD License. 76 Table of Contents 78 1. Requirements and Challenges . . . . . . . . . . . . . . . . . 3 79 2. iFIT Framework Overview . . . . . . . . . . . . . . . . . . . 4 80 3. Smart Flow and Data Selection . . . . . . . . . . . . . . . . 6 81 4. Export Data Reduction . . . . . . . . . . . . . . . . . . . . 6 82 5. Dynamic Network Probe . . . . . . . . . . . . . . . . . . . . 7 83 6. Encapsulation and Tunnel Modes . . . . . . . . . . . . . . . 7 84 7. On-demand Technique Selection and Integration . . . . . . . . 8 85 8. Summary and Future Work . . . . . . . . . . . . . . . . . . . 8 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 87 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 88 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 89 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 90 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 91 13.1. Normative References . . . . . . . . . . . . . . . . . . 9 92 13.2. Informative References . . . . . . . . . . . . . . . . . 9 93 13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 11 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 96 1. Requirements and Challenges 98 Application-aware network operation is important for user SLA 99 compliance, service path enforcement, fault diagnosis, and network 100 resource optimization. A family of on-path flow telemetry 101 techniques, including In-situ OAM (IOAM) 102 [I-D.brockners-inband-oam-data], PBT 103 [I-D.song-ippm-postcard-based-telemetry], IFA [I-D.kumar-ippm-ifa], 104 Enhanced AM [I-D.zhou-ippm-enhanced-alternate-marking], and HTS 105 [I-D.mirsky-ippm-hybrid-two-step], are emerging, which can provide 106 flow information on the entire forwarding path on a per-packet basis 107 in real time. These techniques are very different from the previous 108 active and passive OAM schemes in that they directly modify the user 109 packets and can gain visibility on every user packet. Given the 110 unique characteristics of such techniques, we categorize these on- 111 path telemetry techniques as the hybrid OAM type III, supplementing 112 the classification defined in [RFC7799]. 114 These techniques are invaluable for application-aware network 115 operations not only in data center and enterprise networks but also 116 in carrier networks which may cross multiple domains. Carrier 117 network operators have shown strong interests in utilizing such 118 techniques for various purposes. For example, it is vital for the 119 operators who offer the bandwidth intensive, latency and loss 120 sensitive services such as video streaming and gaming to closely 121 monitor the relevant flows in real time as the indispensable first 122 step for any further measure. 124 However, successfully applying such techniques in carrier networks 125 poses several practical challenges: 127 o C1: On-path flow telemetry incurs extra packet processing which 128 may strain the network data plane. The potential impact on the 129 forwarding performance creates an unfavorable "observer effect" 130 which not only damages the fidelity of the measurement but also 131 defies the purpose of the measurement. 133 o C2: On-path flow telemetry can generate a huge amount of OAM data 134 which may claim too much transport bandwidth and inundate the 135 servers for data collection, storage, and analysis. Increasing 136 the data handling capacity is technically viable but expensive. 138 o C3: The collectible data defined currently are essential but 139 limited. As the network operation evolves to become intent-based 140 and automatic, and the trends of network virtualization, network 141 convergence, and packet-optical integration continue, more data 142 will be needed in an on-demand and interactive fashion. 144 Flexibility and extensibility on data defining and acquiring must 145 be considered. 147 o C4: If we were to apply some on-path telemetry technique in 148 today's carrier networks, we must provide solutions to tailor the 149 provider's network deployment base and support an incremental 150 deployment strategy. That is, we need to come up with 151 encapsulation schemes for various predominant protocols such as 152 Ethernet, IPv4, and MPLS with backward compatibility and properly 153 handle various transport tunnels. 155 o C5: Applying only a single underlying telemetry technique may lead 156 to defective result. For example, packet drop can cause the lost 157 of the flow telemetry data and the packet drop location and reason 158 remains unknown if only In-situ OAM trace option is used. A 159 comprehensive solution needs the flexibility to switch between 160 different underlying techniques and adjust the configurations and 161 parameters at runtime. 163 2. iFIT Framework Overview 165 To address these challenges, we propose a framework based on multiple 166 network operators' requirements and the common industry practice, 167 which can help to build a workable on-path flow telemetry solution. 168 We name the framework "In-situ Flow Information Telemetry" (iFIT) to 169 reflect the fact that this framework is dedicated to the on-path 170 telemetry data about user/application flow experience. As a solution 171 framework, iFIT works a level higher than any specific OAM 172 techniques, be it active, passive, or hybrid. The framework is built 173 up on a few architectural components. By assembling these components 174 together, a closed-loop is formed to provide a complete solution for 175 a particular static, dynamic, and interactive telemetry applications. 177 iFIT is an open framework. It does not enforce any implementation 178 details for each component. Users are free to pick one or more 179 underlying techniques and design their own algorithms and 180 architectures to fit in each component and make all the components 181 work in concert. 183 The network architecture that applies iFIT is shown in Figure 1. The 184 iFIT domain is confined between the iFIT head nodes and the iFIT end 185 nodes. An iFIT domain may cross multiple network domains. iFIT 186 support two basic on-path telemetry data collection modes: passport 187 mode (e.g., IOAM trace option and IFA), in which telemetry data are 188 carried in user packets and exported at the iFIT end nodes, and 189 postcard mode (e.g., PBT), in which each node in the iFIT domain may 190 export telemetry data through independent OAM packets. Note that the 191 boundary between the two modes can be blurry. An application only 192 need to mix the two modes. 194 The key components of iFIT is listed as follows: 196 o Smart flow and data selection policy to address C1. 198 o Export data reduction to address C2. 200 o Dynamic network probe to address C3. 202 o Encapsulation and tunnel modes to address C4. 204 o On-demand technique selection to address C5. 206 +---------------------------------+ 207 | | 208 | iFIT Applications | 209 | | 210 +---------------------------------+ 211 ^ ^ 212 | | 213 V | 214 +------------+ +-----+-----+ 215 | | | | 216 | Controller | | Collector | 217 | | | | 218 +-----:------+ +-----------+ 219 : ^ 220 :configuration |telemetry data 221 : | 222 ...............:.....................|.......... 223 : : : | : 224 : +---------:---+-------------:---++---------:---+ 225 : | : | : | : | 226 V | V | V | V | 227 +------+-+ +-----+--+ +------+-+ +------+-+ 228 usr pkts | iFIT | | Path | | Path | | iFIT | 229 ====>| Head |====>| Node |==//==>| Node |====>| End |====> 230 | Node | | A | | B | | Node | 231 +--------+ +--------+ +--------+ +--------+ 233 Figure 1: iFIT Architecture 235 In the remaining of the document, we provide the detailed discussion 236 of the iFIT's components. 238 3. Smart Flow and Data Selection 240 In most cases, it is impractical to enable the data collection for 241 all the flows and for all the packets in a flow due to the potential 242 performance and bandwidth impacts. Therefore, a workable solution 243 must select only a subset of flows and flow packets to enable the 244 data collection, even though this means the loss of some information. 246 In data plane, the Access Control List (ACL) provides an ideal means 247 to determine the subset of flow(s). 248 [I-D.song-ippm-ioam-data-validation-option] describes how one can set 249 a sample rate or probability to a flow to allow only a subset of flow 250 packets to be monitored, how one can collect different set of data 251 for different packets, and how one can disable or enable data 252 collection on any specific network node. The document further 253 introduces enhancement to IOAM to allow any node to accept or deny 254 the data collection in full or partially. 256 Based on these flexible mechanisms, iFIT allows applications to apply 257 smart flow and data selection policies to suit the requirements. The 258 applications can dynamically change the policies at any time based on 259 the network load, processing capability, focus of interest, and any 260 other criteria. We have developed some adaptive algorithm which can 261 limit the performance impact and yet achieve the satisfactory 262 telemetry data density. 264 4. Export Data Reduction 266 The flow telemetry data can catch the dynamics of the network and the 267 interactions between user traffic and network. Nevertheless, the 268 data inevitably contain redundancy. It is advisable to remove the 269 redundancy from the data in order to reduce the data transport 270 bandwidth and server processing load. 272 In addition to efficiently encode the export data (e.g., IPFIX 273 [RFC7011] or protobuf [1]), iFIT can also cache the data and send the 274 accumulated data in batch if the data is not time sensitive. Various 275 deduplication and compression techniques can be applied on the batch 276 data. 278 From the application perspective, an application may only be 279 interested in some special events which can be derived from the 280 telemetry data. For example, in case that the forwarding delay of a 281 packet exceeds a threshold or a flow changes its forwarding path is 282 of interest, it is unnecessary to send the original raw data to the 283 data collecting and processing servers. Rather, iFIT takes advantage 284 of the in-network computing capability of network devices to process 285 the raw data and only push the event notifications to the subscribing 286 applications. 288 5. Dynamic Network Probe 290 Due to the limited data plane resource, it is unlikely one can 291 provide all the data all the time. On the other hand, the data 292 needed by applications may be arbitrary but ephemeral. It is 293 critical to meet the dynamic data requirements with limited resource. 295 Fortunately, data plane programmability allows iFit to dynamically 296 load new data probes. These on-demand probes are called Dynamic 297 Network Probes (DNP) [I-D.song-opsawg-dnp4iq]. DNP is the technique 298 to enable probes for customized data collection in different network 299 planes. When working with IOAM or PBT, DNP is loaded to the data 300 plane through incremental programming or configuration. The DNP can 301 effectively conduct data generation, processing, and aggregation. 303 DNP introduces enough flexibility and extensibility to iFIT. It can 304 implement the optimizations for export data reduction motioned in the 305 previous section. It can also generate custom data as required by 306 today and tomorrow's applications. 308 6. Encapsulation and Tunnel Modes 310 Since MPLS and IPv4 network are still prevalent in carrier networks. 311 iFIT provides solutions to apply the on-path flow telemetry 312 techniques in such networks. PBT-M 313 [I-D.song-ippm-postcard-based-telemetry] does not introduce new 314 headers to the packets so the trouble of encapsulation for a new 315 header is avoided. In case a technique that requires a new header is 316 preferred, [I-D.song-mpls-extension-header] provides a means to 317 encapsulate the extra header using an MPLS extension header. As for 318 IPv4, it is possible to encapsulate the new header in an IP option. 319 For example, RAO [RFC2113] can be used to indicate the presence of 320 the new header. A recent proposal [I-D.herbert-ipv4-eh] that 321 introduces the IPv4 extension header may lead to a long term 322 solution. 324 In carrier networks, it is common for user traffic to traverse 325 various tunnels for QoS, traffic engineering, or security. iFIT 326 supports both the uniform mode and the pipe mode for tunnel support 327 as described in [I-D.song-ippm-ioam-tunnel-mode]. With such 328 flexibility, the operator can either gain a true end-to-end 329 visibility or apply a hierarchical approach which isolates the 330 monitoring domain between customer and provider. 332 7. On-demand Technique Selection and Integration 334 With multiple underlying data collection and export techniques at its 335 disposal, iFIT can flexibly adapt to different network conditions and 336 different application requirements. 338 For example, depending on the types of data that are of interest, 339 iFIT may choose either IOAM or PBT to collect the data; if an 340 application needs to track down where the packets are lost, it may 341 switch from IOAM to PBT. 343 iFIT can further integrate multiple data plane monitoring and 344 measurement techniques together and present a comprehensive data 345 plane telemetry solution to network operating applications. 347 8. Summary and Future Work 349 iFIT is a framework for applying on-path data plane telemetry 350 techniques. Combining with algorithmic and architectural schemes 351 that fit into the framework components, iFIT framework enables a 352 practical telemetry solution based on two basic on-path traffic data 353 collection modes: passport and postcard. 355 The operation of iFIT differs from both active OAM and passive OAM as 356 defined in [RFC7799]. It does not generate any active probe packets 357 or passively observe unmodified user packets. Instead, it modifies 358 selected user packets to collect useful information about them. 359 Therefore, the iFIT operation can be considered the hybrid type III 360 mode, which can provide more flexible and accurate network OAM. 362 More challenges and corresponding solutions for iFIT may need to be 363 covered. For example, how iFIT can fit in the big picture of 364 autonomous networking and support closed control loops. A complete 365 iFIT framework should also consider the cross-domain operations. We 366 leave these topics for future revisions. 368 9. Security Considerations 370 No specific security issues are identified other than those have been 371 discussed in the drafts on on-path flow information telemetry. 373 10. IANA Considerations 375 This document includes no request to IANA. 377 11. Contributors 379 TBD. 381 12. Acknowledgments 383 TBD. 385 13. References 387 13.1. Normative References 389 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 390 Requirement Levels", BCP 14, RFC 2119, 391 DOI 10.17487/RFC2119, March 1997, 392 . 394 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 395 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 396 May 2016, . 398 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 399 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 400 May 2017, . 402 13.2. Informative References 404 [I-D.brockners-inband-oam-data] 405 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 406 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 407 P., Chang, R., and d. daniel.bernier@bell.ca, "Data Fields 408 for In-situ OAM", draft-brockners-inband-oam-data-07 (work 409 in progress), July 2017. 411 [I-D.herbert-ipv4-eh] 412 Herbert, T., "IPv4 Extension Headers and Flow Label", 413 draft-herbert-ipv4-eh-01 (work in progress), May 2019. 415 [I-D.kumar-ippm-ifa] 416 Kumar, J., Anubolu, S., Lemon, J., Manur, R., Holbrook, 417 H., Ghanwani, A., Cai, D., Ou, H., and L. Yizhou, "Inband 418 Flow Analyzer", draft-kumar-ippm-ifa-01 (work in 419 progress), February 2019. 421 [I-D.mirsky-ippm-hybrid-two-step] 422 Mirsky, G., Lingqiang, W., and G. Zhui, "Hybrid Two-Step 423 Performance Measurement Method", draft-mirsky-ippm-hybrid- 424 two-step-03 (work in progress), April 2019. 426 [I-D.song-ippm-ioam-data-validation-option] 427 Song, H. and T. Zhou, "In-situ OAM Data Validation 428 Option", draft-song-ippm-ioam-data-validation-option-02 429 (work in progress), April 2018. 431 [I-D.song-ippm-ioam-tunnel-mode] 432 Song, H., Li, Z., Zhou, T., and Z. Wang, "In-situ OAM 433 Processing in Tunnels", draft-song-ippm-ioam-tunnel- 434 mode-00 (work in progress), June 2018. 436 [I-D.song-ippm-postcard-based-telemetry] 437 Song, H., Zhou, T., Li, Z., Shin, J., and K. Lee, 438 "Postcard-based On-Path Flow Data Telemetry", draft-song- 439 ippm-postcard-based-telemetry-04 (work in progress), June 440 2019. 442 [I-D.song-mpls-extension-header] 443 Song, H., Li, Z., Zhou, T., and L. Andersson, "MPLS 444 Extension Header", draft-song-mpls-extension-header-02 445 (work in progress), February 2019. 447 [I-D.song-opsawg-dnp4iq] 448 Song, H. and J. Gong, "Requirements for Interactive Query 449 with Dynamic Network Probes", draft-song-opsawg-dnp4iq-01 450 (work in progress), June 2017. 452 [I-D.zhou-ippm-enhanced-alternate-marking] 453 Zhou, T., Fioccola, G., Li, Z., Lee, S., Cociglio, M., and 454 Z. Li, "Enhanced Alternate Marking Method", draft-zhou- 455 ippm-enhanced-alternate-marking-03 (work in progress), 456 July 2019. 458 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 459 DOI 10.17487/RFC2113, February 1997, 460 . 462 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 463 "Specification of the IP Flow Information Export (IPFIX) 464 Protocol for the Exchange of Flow Information", STD 77, 465 RFC 7011, DOI 10.17487/RFC7011, September 2013, 466 . 468 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 469 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 470 "Alternate-Marking Method for Passive and Hybrid 471 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 472 January 2018, . 474 13.3. URIs 476 [1] https://developers.google.com/protocol-buffers/ 478 Authors' Addresses 480 Haoyu Song (editor) 481 Futurewei 482 2330 Central Expressway 483 Santa Clara 484 USA 486 Email: haoyu.song@futurewei.com 488 Zhenbin Li 489 Huawei 490 156 Beiqing Road 491 Beijing, 100095 492 P.R. China 494 Email: lizhenbin@huawei.com 496 Tianran Zhou 497 Huawei 498 156 Beiqing Road 499 Beijing, 100095 500 P.R. China 502 Email: zhoutianran@huawei.com 504 Fengwei Qin 505 China Mobile 506 No. 32 Xuanwumenxi Ave., Xicheng District 507 Beijing, 100032 508 P.R. China 510 Email: qinfengwei@chinamobile.com 512 Jongyoon Shin 513 SK Telecom 514 South Korea 516 Email: jongyoon.shin@sk.com 517 Jaewhan Jin 518 LG U+ 519 South Korea 521 Email: daenamu1@lguplus.co.kr