idnits 2.17.1 draft-song-ippm-postcard-based-telemetry-05.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 are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 281 has weird spacing: '...stcards gen p...' -- The document date (September 9, 2019) is 1689 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.brockners-ippm-ioam-geneve' is defined on line 471, but no explicit reference was found in the text == Unused Reference: 'I-D.clemm-netconf-push-smart-filters-ps' is defined on line 484, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-udp-pub-channel' is defined on line 504, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-yang-push' is defined on line 509, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sfc-ioam-nsh' is defined on line 515, but no explicit reference was found in the text == Unused Reference: 'I-D.sambo-netmod-yang-fsm' is defined on line 527, but no explicit reference was found in the text == Unused Reference: 'I-D.song-ippm-ioam-tunnel-mode' is defined on line 538, but no explicit reference was found in the text == Unused Reference: 'I-D.song-mpls-extension-header' is defined on line 543, but no explicit reference was found in the text == Unused Reference: 'I-D.talwar-rtgwg-grpc-use-cases' is defined on line 559, but no explicit reference was found in the text == Unused Reference: 'I-D.weis-ippm-ioam-gre' is defined on line 564, but no explicit reference was found in the text == Unused Reference: 'RFC6241' is defined on line 577, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-brockners-ippm-ioam-geneve-01 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-00 == Outdated reference: A later version (-05) exists of draft-ietf-netconf-udp-pub-channel-01 == Outdated reference: A later version (-25) exists of draft-ietf-netconf-yang-push-12 == Outdated reference: A later version (-13) exists of draft-ietf-sfc-ioam-nsh-00 == Outdated reference: A later version (-05) exists of draft-sambo-netmod-yang-fsm-00 == Outdated reference: A later version (-01) exists of draft-song-ippm-ioam-data-extension-00 == Outdated reference: A later version (-13) exists of draft-song-mpls-extension-header-01 == Outdated reference: A later version (-07) exists of draft-spiegel-ippm-ioam-rawexport-01 -- Obsolete informational reference (is this intentional?): RFC 2925 (Obsoleted by RFC 4560) Summary: 2 errors (**), 0 flaws (~~), 22 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPPM H. Song, Ed. 3 Internet-Draft Futurewei 4 Intended status: Standards Track T. Zhou 5 Expires: March 12, 2020 Z. Li 6 Huawei 7 J. Shin 8 SK Telecom 9 K. Lee 10 LG U+ 11 September 9, 2019 13 Postcard-based On-Path Flow Data Telemetry 14 draft-song-ippm-postcard-based-telemetry-05 16 Abstract 18 The Postcard-Based Telemetry (PBT) allows network OAM applications to 19 directly collect and export telemetry data about any user packet at 20 each node on the forwarding path. PBT has two variations. One 21 requires inserting an instruction header to user packets to guide the 22 data collection. This variation has been recast into an independent 23 IOAM option mode, Direct Export, and described in a standalone 24 document. This document describes the second variation, the mark 25 triggered PBT or PBT-M. PBT-M only marks the user packets or 26 configure the flow filter to invoke the data collection and postcard 27 export. It complements IOAM by addressing several specific 28 implementation and deployment challenges. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on March 12, 2020. 47 Copyright Notice 49 Copyright (c) 2019 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. PBT-M: Postcard-based Telemetry with Packet Marking . . . . . 5 66 2.1. New Requirements . . . . . . . . . . . . . . . . . . . . 5 67 2.2. Solution Description . . . . . . . . . . . . . . . . . . 6 68 2.3. New Challenges . . . . . . . . . . . . . . . . . . . . . 7 69 2.4. Considerations on PBT-M Design . . . . . . . . . . . . . 8 70 2.4.1. Packet Marking . . . . . . . . . . . . . . . . . . . 8 71 2.4.2. Flow Path Discovery . . . . . . . . . . . . . . . . . 8 72 2.4.3. Packet Identity for Export Data Correlation . . . . . 9 73 2.5. Avoid Packet Marking through Node Configuration . . . . . 9 74 3. Postcard Format . . . . . . . . . . . . . . . . . . . . . . . 10 75 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 78 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 79 8. Informative References . . . . . . . . . . . . . . . . . . . 10 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 82 1. Motivation 84 In order to gain detailed data plane visibility to support effective 85 network OAM, it is important to be able to examine the trace of user 86 packets along their forwarding paths. Such on-path flow data reflect 87 the state and status of each user packet's real-time experience and 88 provide valuable information for network monitoring, measurement, and 89 diagnosis. 91 The telemetry data include but not limited to the detailed forwarding 92 path, the timestamp/latency at each network node, and, in case of 93 packet drop, the drop location and reason. The emerging programmable 94 data plane devices allow user-defined data 95 collection[I-D.song-opsawg-dnp4iq] or conditional data collection 96 based on trigger events. Such on-path flow data are from and about 97 the live user traffic, which complement the data acquired through 98 other passive and active OAM mechanisms such as IPFIX [RFC7011] and 99 ICMP [RFC2925]. 101 In-band Network Telemetry (INT) was designed to cater this need (note 102 that although INT has been widely used, the term "in-band" here does 103 not comply with IETF's definition. "on-path" or "in-situ" may be more 104 accurate terms). in-situ OAM (IOAM) 105 [I-D.brockners-inband-oam-requirements] represents the related 106 standardization efforts. In essence, INT augments user packets with 107 instructions to tell each network node on their forwarding paths what 108 data to collect. The requested data are inserted into and travel 109 along with the user packets. Some end nodes are responsible to strip 110 off the data trace and export it to a data collector for processing. 112 While the concept is simple and straightforward, INT faces several 113 technical challenges: 115 o Issue 1: INT header and data processing needs to be done in data 116 plane fast path. It may interfere with the normal traffic 117 forwarding (e.g., leading to forwarding performance degradation) 118 and lead to inaccurate measurements (e.g., resulting in longer 119 latency measurements than usual). This undesirable "observer 120 effect" is problematic to carrier networks where stringent SLA 121 must be observed. 123 o Issue 2: INT may significantly increase the user packet's original 124 size by adding the instruction header and data at each traversed 125 node. The longer the forwarding path and the more the data 126 collected, the larger the packet will become. The size may exceed 127 the path MTU so either INT cannot apply or the packet needs to be 128 fragmented. Limiting the data size or path length reduces the 129 effectiveness of INT. On the other hand, the INT header and data 130 can be deeply embedded in a packet due to various transport 131 protocol and tunnel configurations. The required deep packet 132 header inspection and processing may be infeasible to some data 133 plane fast path where only a limited number of header bytes are 134 accessible. 136 o Issue 3: INT requires attaching an instruction header to user 137 packets to inform network nodes what types of data to collect. 138 Due to the header overhead constraint and hardware-friendly 139 consideration, TLV is undesirable for data type encoding. 140 Instead, IOAM use a bitmap where each bit indicates one pre- 141 defined data type [I-D.ietf-ippm-ioam-data]. However, new use 142 cases may require new data types. The current allocated 16-bit 143 bitmap limits the data type scalability. The proposed bitmap 144 extension in [I-D.song-ippm-ioam-data-extension] provides a method 145 to support more data types but it also increases the IOAM header 146 size. 148 o Issue 4: INT header needs to be encapsulated into user packets for 149 transport. [I-D.brockners-inband-oam-transport] has discussed 150 several encapsulation approaches for different transport 151 protocols. However, it is difficult to encapsulate extra header 152 in MPLS and IPv4 networks which happens to be the most widely 153 deployed and where the path-associated telemetry data is most 154 wanted by operators. The proposed NVGRE encapsulation for IPv4 in 155 [I-D.brockners-inband-oam-transport] requires a tunnel to be built 156 between each pair of nodes which may be unrealistic for plain IP 157 networks. 159 o Issue 5: The INT header and data are vulnerable to eavesdropping 160 and tampering as well as DoS attack. Extra protective measurement 161 is difficult on the fast data path. 163 o Issue 6: Since INT only exports the telemetry data at the 164 designated end node, if the packet is dropped in the network, the 165 data will be lost as well. It cannot pinpoint the packet drop 166 location which is required for fault diagnosis. Even worse, the 167 end node may not be aware of the lost of packet at all. 169 The above issues are inherent to the INT-based solutions. 170 Nevertheless, the on-path data acquired by INT are valuable for 171 network operators. Therefore, alternative approaches which can 172 collect the same data but avoid or mitigate the above issues are 173 desired. This document provides a new approach named Postcard-Based 174 Telemetry (PBT) with two different implementation variations, each 175 having its own trade-off and addressing some or all of the above 176 issues. The basic idea of PBT is simple: at each node, instead of 177 inserting the collected data into the user packets, the data are 178 directly exported through dedicated OAM packets. Such "postcard" 179 approach is in contrast to the "passport stamps" approach adopted by 180 INT [DOI_10.1145_2342441.2342453]. The OAM packets or postcards can 181 be generated by the node's slow path and transported in band or out 182 of band, independent of the original user packets. 184 The variation that requires an instruction header has been recast an 185 IOAM option mode named Direct Export (DX). DX is described in 186 another document and the reference will be included later. This 187 document only covers the second variation. 189 2. PBT-M: Postcard-based Telemetry with Packet Marking 191 This section describes the variation of PBT which triggers the 192 postcard export with a mark in user packets. PBT-M aims to address 193 the challenges of INT listed above and introduce some new benefits. 194 We first list all the design requirements of PBT-M. 196 2.1. New Requirements 198 o Req. 1: We should avoid augmenting user packets with new headers 199 or introducing new data plane protocols. This helps to alleviate 200 or eliminate the issue 1, 2, 4, and 5. We expect the OAM data 201 collecting signaling remains in data plane. Simple packet marking 202 techniques suffice to serve this purpose. It is also possible to 203 configure the OAM data collecting from the control plane. 205 o Req. 2: We should make the scheme extensible for collecting 206 arbitrary new data to support possible future use cases. The data 207 set to be collected is preferred to be configured through 208 management plane or control plane. Since there is no limitation 209 on the types of data, any custom data including those generated by 210 DNPs [I-D.song-opsawg-dnp4iq] can be collected. Since there is no 211 size constraints any more, it is free to use the more flexible 212 data set template for data type definition. This addresses the 213 issue 2 and 3. 215 o Req. 3: We should avoid interfering the normal forwarding and 216 affecting the forwarding performance when conducting data plane 217 OAM tasks. Hence, the collected data are better to be transported 218 independently by dedicated OAM packets through in-band or out-of- 219 band channels. The data collecting, processing, assembly, 220 encapsulation, and transport are therefore decoupled from the 221 forwarding of the corresponding user packets and can be performed 222 in data plane slow path if necessary. This addresses the issue 1, 223 4, and 5. 225 o Req. 4: The data collected from each node is not necessarily 226 identical, depending on application requirements and node 227 capability. Data for different operation modes can be collected 228 at the same time. These requirements are either impossible or 229 very difficult to be supported by INT in which data types 230 collected per node are supposed to be identical and for a single 231 mode. 233 o Req. 5: The flow's path-associated data can be sensitive and the 234 security concerns need to be carefully addressed. Sending OAM 235 data with independent packets also makes it easy to secure the 236 collected data without exposing it to unnecessary entities. For 237 example, the data can be encrypted before being sent to the 238 collector so passive eavesdropping and man-in-the-middle attack 239 can both be deterred. This addresses the issue 5. 241 o Req. 6: Even if a user packet under inspection is dropped in 242 network, the OAM data that have been collected should still be 243 exported and help to diagnose the packet drop location and reason. 244 This addresses the issue 6. 246 2.2. Solution Description 248 In light of the above discussion, the sketch of the proposed 249 solution, PBT-M, is as follows. The user packet, if its path- 250 associated data need to be collected, is marked at the path head 251 node. At each PBT-aware node, if the mark is detected, a postcard 252 (i.e., the dedicated OAM packet triggered by a marked user packet) is 253 generated and sent to a collector. The postcard contains the data 254 requested by the management plane. The requested data are configured 255 by the management plane through data set templates (as in IPFIX 256 [RFC7011]). Once the collector receives all the postcards for a 257 single user packet, it can infer the packet's forwarding path and 258 analyze the data set. The path end node is configured to unmark the 259 packets to its original format if necessary. 261 The overall architecture of PBT-M is depict in Figure 1. 263 +------------+ +-----------+ 264 | Network | | Telemetry | 265 | Management |(-------| Data | 266 | | | Collector | 267 +-----:------+ +-----------+ 268 : ^ 269 :configurations |postcards (OAM pkts) 270 : | 271 ...............:.....................|........ 272 : : : | : 273 : +---------:---+-----------:---+--+-------:---+ 274 : | : | : | : | 275 V | V | V | V | 276 +------+-+ +-----+--+ +------+-+ +------+-+ 277 usr pkts | Head | | Path | | Path | | End | 278 ====>| Node |====>| Node |====>| Node |====>| Node |====> 279 | | | A | | B | | | 280 +--------+ +--------+ +--------+ +--------+ 281 gen postcards gen postcards gen postcards gen postcards 282 mark usr pkts unmark usr pkts 284 Figure 1: Architecture of PBT-M 286 2.3. New Challenges 288 Although PBT-M solves the issues of INT, it introduces a few new 289 challenges. 291 o Challenge 1: A user packet needs to be marked in order to trigger 292 the path-associated data collection. Since we do not want to 293 augment user packets with any new header fields (i.e., Req. 1), we 294 must reuse some bit from existing header fields. 296 o Challenge 2: Since the packet header will not carry OAM 297 instructions any more, the data plane devices need to be 298 configured to know what data to collect. However, in general, the 299 forwarding path of a flow packet (due to ECMP or dynamic routing) 300 is unknown beforehand. Configuring the data set for each flow at 301 all data plane devices is expensive in terms of configuration load 302 and data plane resources. 304 o Challenge 3: Due to the variable transport latency, the dedicated 305 OAM packets for a single packet may arrive at the collector out of 306 order or be dropped in networks for some reason. In order to 307 infer the packet forwarding path, the collector needs some 308 information from the OAM packets to identify the user packet 309 affiliation and the order of path node traversal. 311 2.4. Considerations on PBT-M Design 313 To address the above challenges, we propose several design details of 314 PBT-M. 316 2.4.1. Packet Marking 318 To trigger the path-associated data collection, usually a single bit 319 from some header field is sufficient. While no such bit is 320 available, other packet marking techniques are needed. we discuss 321 three possible application scenarios. 323 o IPv4. IPFPM [I-D.ietf-ippm-alt-mark] is an IP flow performance 324 measurement framework which also requires a single bit for packet 325 coloring. The difference is that IPFPM does in-network 326 measurement while PBT only collects and exports data at network 327 nodes (i.e., the data analysis is done at the collector rather 328 than in the network nodes). IPFPM suggests to use some reserved 329 bit of the Flag field or some unused bit of the TOS field. 330 Actually, IPFPM can be considered a subcase of PBT so the same bit 331 can be used for PBT. The management plane is responsible to 332 configure the actual operation mode. 334 o SFC NSH. The OAM bit in NSH header can be used to trigger the 335 path-associated data collection [I-D.ietf-sfc-nsh]. PBT does not 336 add any other metadata to NSH. 338 o MPLS. Instead of choosing a header bit, we take advantage of the 339 synonymous flow label [I-D.bryant-mpls-synonymous-flow-labels] 340 approach to mark the packets. A synonymous flow label indicates 341 the path-associated data should be collected and forwarded through 342 a postcard. 344 2.4.2. Flow Path Discovery 346 By default, all PBT-aware nodes are configured to react to the marked 347 packets by exporting some basic data such as node ID and TTL before a 348 data set template for that flow is configured. This way, the 349 management plane can learn the flow path dynamically. 351 If the management plane wants to collect the path-associated data for 352 some flow, it configures the head node(s) with a probability or time 353 interval for the flow packet marking. When the first marked packet 354 is forwarded in the network, the PBT-aware nodes will export the 355 basic data to the collector. Hence, the flow path is identified. If 356 other types of data need to be collected, the management plane can 357 further configure the data set template to the target nodes on the 358 flow's path. The PBT-aware nodes would collect and export data 359 accordingly if the packet is marked and a data set template is 360 present. 362 If for any reason, the flow path is changed. The new path nodes can 363 be learned immediately by the collector, so the management plane 364 controller can be informed to configure the new path nodes. The 365 outdated configuration can be automatically timed out or explicitly 366 revoked by the management plane controller. 368 2.4.3. Packet Identity for Export Data Correlation 370 The collector needs to correlate all the OAM packets for a single 371 user packet. Once this is done, the TTL (or the timestamp, if the 372 network time is synchronized) can be used to infer the flow 373 forwarding path. The key issue here is to correlate all the 374 postcards for a same user packet. 376 The first possible approach is to include the flow ID plus the user 377 packet ID in the OAM packets. The flow ID can be the 5-tuple IP 378 header of the user traffic. The user packet ID can be some unique 379 information pertaining to a user packet (e.g., the sequence number of 380 a TCP packet). 382 If the packet marking interval is large enough, then the flow ID 383 itself is enough to identify the user packet. That is, we can assume 384 all the exported OAM packets for the same flow during a short period 385 of time belong to the same user packet. 387 Alternatively, if the network is synchronized, then the flow ID plus 388 the timestamp at each node can also infer the postcard affiliation. 389 However, some errors may occur under some circumstances. For 390 example, if two consecutive user packets from the same flows are both 391 marked but one exported postcard from a node is lost, then it is 392 difficult for the collector to decide which user packet the remaining 393 postcard belongs to. In many cases, such rare error has no 394 catastrophic consequence therefore is tolerable. 396 2.5. Avoid Packet Marking through Node Configuration 398 It is possible to avoid needing to mark user packets yet still 399 allowing in-band flow data collection. We could simply configure the 400 Access Control List (ACL) to filter out the set of target flows. 401 This approach has two potential issues: (1) Since the packet 402 forwarding path is unknown in advance, one needs to configure all the 403 nodes in a network to filter the flows and capture the complete data 404 set. This wastes the precious ACL resource and is not scalable. (2) 405 If a node cannot collect data for all the filtered packets of a flow, 406 it needs to determine which packets to sample independently, so the 407 collector may not be able to receive the full set of postcards for a 408 same user packet. 410 Nevertheless, since this approach does not require to touch the user 411 packets at all, it has its unique merits: (1) User can freely choose 412 any nodes as vantage points for data collection; (2) No need to worry 413 that any "modified" user packets to leak out of the PBT domain; (3) 414 It has the minimum impact to the forwarding of the user traffic. 416 No data plane standard is required to support this mode, except the 417 postcard format. 419 3. Postcard Format 421 Postcard can use the same data export format as that used by IOAM. 422 [I-D.spiegel-ippm-ioam-rawexport] proposes a raw format that can be 423 interpreted by IPFIX. 425 4. Security Considerations 427 Several security issues need to be considered. 429 o Eavesdrop and tamper: the postcards can be encrypted and 430 authenticated to avoid such security threats. 432 o DoS attack: PBT can be limited to a single administration domain. 433 The mark must be removed at the egress domain edge. The node can 434 rate limit the extra traffic incurred by postcards. 436 5. IANA Considerations 438 No requirement for IANA is identified. 440 6. Contributors 442 TBD. 444 7. Acknowledgments 446 TBD. 448 8. Informative References 450 [DOI_10.1145_2342441.2342453] 451 Handigol, N., Heller, B., Jeyakumar, V., MaziA(C)res, D., 452 and N. McKeown, "Where is the debugger for my software- 453 defined network?", Proceedings of the first workshop on 454 Hot topics in software defined networks - HotSDN '12, 455 DOI 10.1145/2342441.2342453, 2012. 457 [I-D.brockners-inband-oam-requirements] 458 Brockners, F., Bhandari, S., Dara, S., Pignataro, C., 459 Gredler, H., Leddy, J., Youell, S., Mozes, D., Mizrahi, 460 T., Lapukhov, P., and r. Chang, "Requirements for In-situ 461 OAM", draft-brockners-inband-oam-requirements-03 (work in 462 progress), March 2017. 464 [I-D.brockners-inband-oam-transport] 465 Brockners, F., Bhandari, S., Govindan, V., Pignataro, C., 466 Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes, 467 D., Lapukhov, P., and R. Chang, "Encapsulations for In- 468 situ OAM Data", draft-brockners-inband-oam-transport-05 469 (work in progress), July 2017. 471 [I-D.brockners-ippm-ioam-geneve] 472 Brockners, F., Bhandari, S., Govindan, V., Pignataro, C., 473 Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes, 474 D., Lapukhov, P., and R. Chang, "Geneve encapsulation for 475 In-situ OAM Data", draft-brockners-ippm-ioam-geneve-01 476 (work in progress), June 2018. 478 [I-D.bryant-mpls-synonymous-flow-labels] 479 Bryant, S., Swallow, G., Sivabalan, S., Mirsky, G., Chen, 480 M., and Z. Li, "RFC6374 Synonymous Flow Labels", draft- 481 bryant-mpls-synonymous-flow-labels-01 (work in progress), 482 July 2015. 484 [I-D.clemm-netconf-push-smart-filters-ps] 485 Clemm, A., Voit, E., Liu, X., Bryskin, I., Zhou, T., 486 Zheng, G., and H. Birkholz, "Smart filters for Push 487 Updates - Problem Statement", draft-clemm-netconf-push- 488 smart-filters-ps-00 (work in progress), October 2017. 490 [I-D.ietf-ippm-alt-mark] 491 Fioccola, G., Capello, A., Cociglio, M., Castaldelli, L., 492 Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 493 "Alternate Marking method for passive and hybrid 494 performance monitoring", draft-ietf-ippm-alt-mark-14 (work 495 in progress), December 2017. 497 [I-D.ietf-ippm-ioam-data] 498 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 499 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 500 P., Chang, R., and d. daniel.bernier@bell.ca, "Data Fields 501 for In-situ OAM", draft-ietf-ippm-ioam-data-00 (work in 502 progress), September 2017. 504 [I-D.ietf-netconf-udp-pub-channel] 505 Zheng, G., Zhou, T., and A. Clemm, "UDP based Publication 506 Channel for Streaming Telemetry", draft-ietf-netconf-udp- 507 pub-channel-01 (work in progress), November 2017. 509 [I-D.ietf-netconf-yang-push] 510 Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen- 511 Nygaard, E., Bierman, A., and B. Lengyel, "YANG Datastore 512 Subscription", draft-ietf-netconf-yang-push-12 (work in 513 progress), December 2017. 515 [I-D.ietf-sfc-ioam-nsh] 516 Brockners, F., Bhandari, S., Govindan, V., Pignataro, C., 517 Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes, 518 D., Lapukhov, P., and R. Chang, "NSH Encapsulation for In- 519 situ OAM Data", draft-ietf-sfc-ioam-nsh-00 (work in 520 progress), May 2018. 522 [I-D.ietf-sfc-nsh] 523 Quinn, P., Elzur, U., and C. Pignataro, "Network Service 524 Header (NSH)", draft-ietf-sfc-nsh-28 (work in progress), 525 November 2017. 527 [I-D.sambo-netmod-yang-fsm] 528 Sambo, N., Castoldi, P., Fioccola, G., Cugini, F., Song, 529 H., and T. Zhou, "YANG model for finite state machine", 530 draft-sambo-netmod-yang-fsm-00 (work in progress), October 531 2017. 533 [I-D.song-ippm-ioam-data-extension] 534 Song, H. and T. Zhou, "In-situ OAM Data Type Extension", 535 draft-song-ippm-ioam-data-extension-00 (work in progress), 536 October 2017. 538 [I-D.song-ippm-ioam-tunnel-mode] 539 Song, H., Li, Z., Zhou, T., and Z. Wang, "In-situ OAM 540 Processing in Tunnels", draft-song-ippm-ioam-tunnel- 541 mode-00 (work in progress), June 2018. 543 [I-D.song-mpls-extension-header] 544 Song, H., Li, Z., Zhou, T., and L. Andersson, "MPLS 545 Extension Header", draft-song-mpls-extension-header-01 546 (work in progress), August 2018. 548 [I-D.song-opsawg-dnp4iq] 549 Song, H. and J. Gong, "Requirements for Interactive Query 550 with Dynamic Network Probes", draft-song-opsawg-dnp4iq-01 551 (work in progress), June 2017. 553 [I-D.spiegel-ippm-ioam-rawexport] 554 Spiegel, M., Brockners, F., Bhandari, S., and R. 555 Sivakolundu, "In-situ OAM raw data export with IPFIX", 556 draft-spiegel-ippm-ioam-rawexport-01 (work in progress), 557 October 2018. 559 [I-D.talwar-rtgwg-grpc-use-cases] 560 Specification, g., Kolhe, J., Shaikh, A., and J. George, 561 "Use cases for gRPC in network management", draft-talwar- 562 rtgwg-grpc-use-cases-01 (work in progress), January 2017. 564 [I-D.weis-ippm-ioam-gre] 565 Weis, B., Brockners, F., crhill@cisco.com, c., Bhandari, 566 S., Govindan, V., Pignataro, C., Gredler, H., Leddy, J., 567 Youell, S., Mizrahi, T., Kfir, A., Gafni, B., Lapukhov, 568 P., and M. Spiegel, "GRE Encapsulation for In-situ OAM 569 Data", draft-weis-ippm-ioam-gre-00 (work in progress), 570 March 2018. 572 [RFC2925] White, K., "Definitions of Managed Objects for Remote 573 Ping, Traceroute, and Lookup Operations", RFC 2925, 574 DOI 10.17487/RFC2925, September 2000, 575 . 577 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 578 and A. Bierman, Ed., "Network Configuration Protocol 579 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 580 . 582 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 583 "Specification of the IP Flow Information Export (IPFIX) 584 Protocol for the Exchange of Flow Information", STD 77, 585 RFC 7011, DOI 10.17487/RFC7011, September 2013, 586 . 588 Authors' Addresses 590 Haoyu Song (editor) 591 Futurewei 592 2330 Central Expressway 593 Santa Clara, 95050 594 USA 596 Email: hsong@futurewei.com 598 Tianran Zhou 599 Huawei 600 156 Beiqing Road 601 Beijing, 100095 602 P.R. China 604 Email: zhoutianran@huawei.com 606 Zhenbin Li 607 Huawei 608 156 Beiqing Road 609 Beijing, 100095 610 P.R. China 612 Email: lizhenbin@huawei.com 614 Jongyoon Shin 615 SK Telecom 616 South Korea 618 Email: jongyoon.shin@sk.com 620 Kyungtae Lee 621 LG U+ 622 South Korea 624 Email: coolee@lguplus.co.kr