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