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