idnits 2.17.1 draft-song-ippm-postcard-based-telemetry-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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** There are 4 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 272 has weird spacing: '...stcards gen p...' == Line 480 has weird spacing: '...stcards gen p...' -- The document date (December 11, 2018) is 1955 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.clemm-netconf-push-smart-filters-ps' is defined on line 589, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-udp-pub-channel' is defined on line 609, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-yang-push' is defined on line 614, but no explicit reference was found in the text == Unused Reference: 'I-D.sambo-netmod-yang-fsm' is defined on line 632, but no explicit reference was found in the text == Unused Reference: 'I-D.song-ippm-ioam-tunnel-mode' is defined on line 643, but no explicit reference was found in the text == Unused Reference: 'I-D.talwar-rtgwg-grpc-use-cases' is defined on line 658, but no explicit reference was found in the text == Unused Reference: 'RFC6241' is defined on line 676, 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 -- Obsolete informational reference (is this intentional?): RFC 2925 (Obsoleted by RFC 4560) Summary: 2 errors (**), 0 flaws (~~), 18 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 T. Zhou 4 Intended status: Standards Track Z. Li 5 Expires: June 14, 2019 Huawei 6 J. Shin 7 SK Telecom 8 December 11, 2018 10 Postcard-based In-band Flow Data Telemetry 11 draft-song-ippm-postcard-based-telemetry-01 13 Abstract 15 The Postcard-Based Telemetry (PBT) allows network OAM applications to 16 collect telemetry data about any user packet. Unlike similar 17 techniques such as in-situ OAM (IOAM), PBT does not require user 18 packets to carry the telemetry data, but directly exports the 19 telemetry data from the data collecting node to a collector through 20 separated OAM packets called postcards. Two variations of PBT are 21 described: one requires inserting an instruction header to user 22 packets to guide the data collection and the other only marks the 23 user packets or configure the flow filter to invoke the data 24 collection. PBT provides an alternative to IOAM and address several 25 implementation and deployment challenges of it. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on June 14, 2019. 44 Copyright Notice 46 Copyright (c) 2018 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. PBT-M: Postcard-based Telemetry with Packet Marking . . . . . 4 63 2.1. New Requirements . . . . . . . . . . . . . . . . . . . . 4 64 2.2. Solution Description . . . . . . . . . . . . . . . . . . 6 65 2.3. New Challenges . . . . . . . . . . . . . . . . . . . . . 7 66 2.4. Considerations on PBT-M Design . . . . . . . . . . . . . 7 67 2.4.1. Packet Marking . . . . . . . . . . . . . . . . . . . 7 68 2.4.2. Flow Path Discovery . . . . . . . . . . . . . . . . . 8 69 2.4.3. Packet Identity for Export Data Correlation . . . . . 8 70 2.5. Avoid Packet Marking through Node Configuration . . . . . 9 71 3. PBT-I: Postcard-based Telemetry with Instruction Header . . . 9 72 3.1. Solution Description . . . . . . . . . . . . . . . . . . 10 73 3.2. PBT-I Telemetry Instruction Header . . . . . . . . . . . 11 74 3.3. Considerations on PBT-I Design . . . . . . . . . . . . . 12 75 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 77 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 78 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 79 8. Informative References . . . . . . . . . . . . . . . . . . . 13 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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 in-band 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 in-band flow data are from and about 97 the live user traffic, which complement with the data acquired 98 through other passive and active OAM mechanisms such as IPFIX 99 [RFC7011] and ICMP [RFC2925]. 101 In-band Network Telemetry (INT) was designed to cater this need. in- 102 situ OAM (iOAM) [I-D.brockners-inband-oam-requirements] represents 103 the related standardization efforts. In essence, INT augments user 104 packets with instructions to tell each network node on their 105 forwarding paths what data to collect. The requested data are 106 inserted into and travel along with the user packets. Some end nodes 107 are responsible to strip off the data trace and export it to a data 108 collector for processing. 110 While the concept is simple and straightforward, INT faces several 111 technical challenges: 113 o Issue 1: INT header and data processing needs to be done in data 114 plane fast path. It may interfere with the normal traffic 115 forwarding (e.g., leading to forwarding performance degradation) 116 and lead to inaccurate measurements (e.g., resulting in longer 117 latency measurements than usual). This undesirable "observer 118 effect" is problematic to carrier networks where stringent SLA 119 must be observed. 121 o Issue 2: INT may significantly increase the user packet's original 122 size by adding the instruction header and data at each traversed 123 node. The longer the forwarding path and the more the data 124 collected, the larger the packet will become. The size may exceed 125 the path MTU so either INT cannot apply or the packet needs to be 126 fragmented. Limiting the data size or path length reduces the 127 effectiveness of INT. On the other hand, the INT header and data 128 can be deeply embedded in a packet due to various transport 129 protocol and tunnel configurations. The required deep packet 130 header inspection and processing may be infeasible to some data 131 plane fast path where only a limited number of header bytes are 132 accessible. 134 o Issue 3: INT requires attaching an instruction header to user 135 packets to inform network nodes what types of data to collect. 136 Due to the header overhead constraint and hardware-friendly 137 consideration, TLV is undesirable for data type encoding. 138 Instead, iOAM use a bitmap where each bit indicates one pre- 139 defined data type [I-D.ietf-ippm-ioam-data]. However, new use 140 cases may require new data types. The current allocated 16-bit 141 bitmap limits the data type scalability. The proposed bitmap 142 extension in [I-D.song-ippm-ioam-data-extension] provides a method 143 to support more data types but it also increases the iOAM header 144 size. 146 o Issue 4: INT header need to be encapsulated into user packets for 147 transport. [I-D.brockners-inband-oam-transport] has discussed 148 several encapsulation approaches for different transport 149 protocols. However, it is difficult to encapsulate extra header 150 in MPLS and IPv4 networks which happens to be the most widely 151 deployed and where the path-associated telemetry data is most 152 wanted by operators. The proposed NVGRE encapsulation for IPv4 in 153 [I-D.brockners-inband-oam-transport] requires a tunnel to be built 154 between each pair of nodes which may be unrealistic for plain IP 155 networks. 157 o Issue 5: The INT header and data are vulnerable to eavesdropping 158 and tampering as well as DoS attack. Extra protective measurement 159 is difficult on the fast data path. 161 o Issue 6: Since INT only exports the telemetry data at the 162 designated end node, if the packet is dropped in the network, the 163 data will be lost as well. It cannot pinpoint the packet drop 164 location which is required for fault diagnosis. 166 The above issues are inherent to the INT-based solutions. 167 Nevertheless, the path-associated data acquired by INT are valuable 168 for network operators. Therefore, alternative approaches which can 169 collect the same data but avoid or mitigate the above issues are 170 desired. This document provides a new approach named Postcard-Based 171 Telemetry (PBT) with two different implementation variations, each 172 having its own trade-off and addressing some or all of the above 173 issues. The basic idea of PBT is simple: at each node, instead of 174 inserting the collected data into the user packets, the data are 175 directly exported through dedicated OAM packets. Such "postcard" 176 approach is in contrast to the "passport stamps" approach adopted by 177 INT [DOI_10.1145_2342441.2342453]. The OAM packets or postcards can 178 be transported in band or out of band, independent of the original 179 user packets. 181 2. PBT-M: Postcard-based Telemetry with Packet Marking 183 This section describes the first variation of PBT. PBT-M aims to 184 address all the challenges of INT listed above and introduce some new 185 benefits. We first list all the design requirements of PBT-M. 187 2.1. New Requirements 189 o Req. 1: We should avoid augmenting user packets with new headers 190 or introducing new data plane protocols. This helps to alleviate 191 or eliminate the issue 1, 2, 4, and 5. We expect the OAM data 192 collecting signaling remains in data plane. Simple packet marking 193 techniques suffice to serve this purpose. It is also possible to 194 configure the OAM data collecting from the control plane. 196 o Req. 2: We should make the scheme extensible for collecting 197 arbitrary new data to support possible future use cases. The data 198 set to be collected is preferred to be configured through 199 management plane or control plane. Since there is no limitation 200 on the types of data, any data including those generated by 201 customized DNPs [I-D.song-opsawg-dnp4iq] can be collected. Since 202 there is no size constraints any more, it is free to use the more 203 flexible TLV for data type definition. This addresses the issue 2 204 and 3. 206 o Req. 3: We should avoid interfering the normal forwarding and 207 affecting the forwarding performance when conducting data plane 208 OAM tasks. Hence, the collected data are better to be transported 209 independently by dedicated OAM packets through in-band or out-of- 210 band channels. The data collecting, processing, assembly, 211 encapsulation, and transport are therefore decoupled from the 212 forwarding of the corresponding user packets and can be performed 213 in data plane slow path if necessary. This addresses the issue 1, 214 4, and 5. 216 o Req. 4: The data collected from each node is not necessarily 217 identical, depending on application requirements and node 218 capability. Data for different operation modes can be collected 219 at the same time. These requirements are either impossible or 220 very difficult to be supported by INT in which data types 221 collected per node are supposed to be identical and for a single 222 mode. 224 o Req. 5: The flow's path-associated data can be sensitive and the 225 security concerns need to be carefully addressed. Sending OAM 226 data with independent packets also makes it easy to secure the 227 collected data without exposing it to unnecessary entities. For 228 example, the data can be encrypted before being sent to the 229 collector so passive eavesdropping and man-in-the-middle attack 230 can both be deterred. This addresses the issue 5. 232 o Req. 6: Even if a user packet under inspection is dropped in 233 network, the OAM data that have been collected should still be 234 exported and help to diagnose the packet drop location and reason. 235 This addresses the issue 6. 237 2.2. Solution Description 239 In light of the above discussion, the sketch of the proposed 240 solution, PBT-M, is as follows. The user packet, if its path- 241 associated data need to be collected, is marked at the path head 242 node. At each PBT-aware node, a postcard (i.e., the dedicated OAM 243 packet triggered by a marked user packet) is generated and sent to a 244 collector. The postcard contains the data requested by the 245 management plane. The requested data are configured by the 246 management plane through data templates (as in IPFIX [RFC7011]) or 247 other means. Once the collector receives all the postcards for a 248 single user packet, it can infer the packet's forwarding path and 249 analyze the data set. The path end node is configured to unmark the 250 packets to its original format if necessary. 252 The overall architecture of PBT-M is depict in Figure 1. 254 +------------+ +-----------+ 255 | Network | | Telemetry | 256 | Management |(-------| Data | 257 | | | Collector | 258 +-----:------+ +-----------+ 259 : ^ 260 :configurations |postcards (OAM pkts) 261 : | 262 ...............:.....................|........ 263 : : : | : 264 : +---------:---+-----------:---+--+-------:---+ 265 : | : | : | : | 266 V | V | V | V | 267 +------+-+ +-----+--+ +------+-+ +------+-+ 268 usr pkts | Head | | Path | | Path | | End | 269 ====>| Node |====>| Node |====>| Node |====>| Node |====> 270 | | | A | | B | | | 271 +--------+ +--------+ +--------+ +--------+ 272 gen postcards gen postcards gen postcards gen postcards 273 mark usr pkts unmark usr pkts 275 Figure 1: Architecture of PBT-M 277 Next we discuss the details of the PBT-M solution and the potential 278 standard gaps. 280 2.3. New Challenges 282 Although PBT-M solves the issues of INT, it does introduce a few new 283 challenges. 285 o Challenge 1: A user packet needs to be marked in order to trigger 286 the path-associated data collection. Since we do not want to 287 augment user packets with any new header fields (i.e., Req. 1), we 288 must take advantage of the existing header fields. 290 o Challenge 2: Since the packet header will not carry OAM 291 instructions any more, the data plane devices need to be 292 configured to know what data to collect. However, in general, the 293 forwarding path of a flow packet (due to ECMP or dynamic routing) 294 is unknown beforehand. Configuring the data set for each flow at 295 all data plane devices is expensive in terms of configuration load 296 and data plane resources. 298 o Challenge 3: Due to the variable transport latency, the dedicated 299 OAM packets for a single packet may arrive at the collector out of 300 order or be dropped in networks for some reason. In order to 301 infer the packet forwarding path, the collector needs some 302 information from the OAM packets to identify the user packet 303 affiliation and the order of path node traversal. 305 2.4. Considerations on PBT-M Design 307 To address the above challenges, we propose several design details of 308 PBT-M. 310 2.4.1. Packet Marking 312 Instead of stuffing new header fields into user packets, it is 313 preferred to reuse some existing header fields. To trigger the path- 314 associated data collection, usually a single bit is sufficient. 315 While no such bit is available, other packet marking techniques are 316 needed. we discuss three possible application scenarios. 318 o IPv4. IPFPM [I-D.ietf-ippm-alt-mark] is an IP flow performance 319 measurement framework which also requires a single bit for packet 320 coloring. The difference is that IPFPM does in-network 321 measurement while PBT only collects and exports data at network 322 nodes (i.e., the data analysis is done at the collector). IPFPM 323 suggests to use some reserved bit of the Flag field or some unused 324 bit of the TOS field. Actually, IPFPM can be considered a subcase 325 of PBT so the same bit can be used for PBT. The management plane 326 is responsible to configure the actual operation mode. 328 o SFC NSH. The OAM bit in NSH header can be used to trigger the 329 path-associated data collection [I-D.ietf-sfc-nsh]. PBT does not 330 add any other metadata to NSH. 332 o MPLS. Instead of choosing a header bit, we take advantage of the 333 synonymous flow label [I-D.bryant-mpls-synonymous-flow-labels] 334 approach to mark the packets. A synonymous flow label indicates 335 the path-associated data should be collected and forwarded through 336 a postcard. 338 2.4.2. Flow Path Discovery 340 By default, all PBT-aware nodes are configured to react to the marked 341 packets by exporting some basic data such as node ID and TTL before a 342 data set template for that flow is configured. This way, the 343 management plane can learn the flow path. 345 If the management plane wants to collect the path-associated data for 346 some flow, it configures the head node(s) with a probability or time 347 interval for the flow packet marking. When the first marked packet 348 is forwarded in the network, the PBT-aware nodes will export the 349 basic data to the collector. Hence, the flow path is identified. If 350 other types of data need to be collected, the management plane can 351 further configure the data set template to the target nodes. The 352 PBT-aware nodes would collect and export data accordingly if the 353 packet is marked and a data set template is present. 355 If for any reason, the flow path is changed. The new path nodes can 356 be learnt immediately by the collector, so the management plane 357 controller can be informed to configure the new path nodes. The 358 outdated configuration can be automatically timed out or explicitly 359 revoked by the management plane controller. 361 2.4.3. Packet Identity for Export Data Correlation 363 The collector needs to correlate all the OAM packets for a single 364 user packet. Once this is done, the TTL (or the timestamp, if the 365 network time is synchronized) can be used to infer the flow 366 forwarding path. The key issue here is to uniquely identify the user 367 packet affiliation of the OAM packet. 369 The first possible approach is to include the flow ID plus the user 370 packet ID in the OAM packets. The user packet ID can be some unique 371 information pertaining to a user packet (e.g., the sequence number of 372 a TCP packet). 374 If the packet marking interval is long enough, then the flow ID 375 itself is enough to identify the user packet. That is, we can assume 376 all the exported OAM packets for the same flow during a short period 377 of time belong to the same user packet. 379 If the network is synchronized, then the flow ID plus the timestamp 380 at each node can also infer the packet identity. However, some 381 errors may occur under some circumstances. For example, if two 382 consecutive user packets from the same flows are both marked and one 383 exported OAM packet from a node is lost, then it is difficult for the 384 collector to decide which user packet the remaining OAM packet 385 belongs to. In many cases, such rare errors may be tolerable. 387 2.5. Avoid Packet Marking through Node Configuration 389 It is possible to avoid needing to mark user packets yet still 390 allowing in-band flow data collection. We could simply configure the 391 Access Controll List (ACL) to filter out the set of target flows. 392 This approach has two potential issues: (1) Since the packet 393 forwarding path is unknown in advance, one needs to configure all the 394 nodes in a network to capture the complete data set; (2) If a node 395 cannot collect data for all the filtered packets of a flow, it needs 396 to determine which packets to sample independently, so the collector 397 may not be able to receive the full set of postcards for a same user 398 packet. 400 Nevertheless, since this approach does not require to touch the user 401 packets at all, it has its unique merits: (1) User can freely choose 402 any nodes as vatage points for data collection; (2) No need to worry 403 that any "modified" user packets to leak out of the PBT domain; (3) 404 It has the minimum impact to the forwarding of the user traffic. 406 3. PBT-I: Postcard-based Telemetry with Instruction Header 408 Since PBT-M has some challenges as listed in Section 2.3, this 409 section describes another variation of PBT, which essentially 410 compromises some of the design requirements listed in Section 2.1, 411 yet retains most of the benefits of PBT. 413 PBT-I can be seen as a trade-off between INT/iOAM and PBT-M. PBT-I 414 needs to add a fixed length instruction header to user packets for 415 OAM data collection. However, the collected data will be exported 416 through dedicated OAM packets. On the one hand, PBT-I violates the 417 Req. 1 in Section 2.1. It also makes it harder to meet the Req. 2. 418 On the other hand, the overhead of the instruction header is under 419 control and user packets will not inflate with path length or 420 telemetry data amount. We also introduce an optimization to mitigate 421 the impact on Req. 2. In return, PBT-I addresses all the challenges 422 of PBT-M: 424 o There is no need to find an existing header field to mark a user 425 packet. The encapsulation of the PBT-I instruction header can use 426 the same method for iOAM. So far, the iOAM header encapsulation 427 methods have been defined for several protocols, including IPv6, 428 VXLAN-GPE, NSH, SRv6 429 [I-D.brockners-inband-oam-transport],[I-D.ietf-sfc-ioam-nsh], 430 GENEVE [I-D.brockners-ippm-ioam-geneve], and GRE 431 [I-D.weis-ippm-ioam-gre]. [I-D.song-mpls-extension-header] 432 describes the approach to encapuslate the instruction header into 433 MPLS packets. 435 o There is no need to configure the nodes about the data to be 436 collected since the data set information is carried in the 437 instruction header. Instead of using a bitmap to indicate the 438 data set as in IOAM, here we adopt a more scalable way which uses 439 a template ID to indicate the data set. 441 o The instruction header contains enough information to help 442 correlate the OAM packets belonging to a user packets. Even 443 better, new fields are added to track the flow and the packet, so 444 any packet under inspection can be easily identified even in 445 tunnels and the collector can easily check if any user packet 446 under inspection or its OAM data packet is missing. 448 3.1. Solution Description 450 The sketch of the proposed solution, PBT-I, is as follows. If the 451 path-associated data need to be collected for a user packet, an 452 instruction header named Telemetry Instruction Header (TIH) is 453 inserted into the packet at the path head node. At each PBT-aware 454 node, a postcard is generated and sent to a collector. Once the 455 collector receives all the postcards for a single user packet, it can 456 combine and analyze the data set. The path end node is configured to 457 remove the TIH. 459 The overall architecture of PBT-I is depict in Figure 2. 461 +-----------+ 462 | Telemetry | 463 | Data | 464 | Collector | 465 +-----------+ 466 ^ 467 |postcards (OAM pkts) 468 | 469 | 470 | 471 +--------------+------+-------+--------------+ 472 | | | | 473 | | | | 474 +---+----+ +---+----+ +---+----+ +---+----+ 475 usr pkts | Head | | Path | | Path | | End | 476 ====>| Node |====>| Node |====>| Node |====>| Node |====> 477 | | | A | | B | | | 478 +--------+ +--------+ +--------+ +--------+ 479 insert TIH remove TIH 480 gen postcards gen postcards gen postcards gen postcards 482 Figure 2: Architecture of PBT-I 484 3.2. PBT-I Telemetry Instruction Header 486 The proposed format of TIH is shown in Figure 3. 488 0 0 0 1 1 2 2 3 489 0 7 8 5 6 3 4 1 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Next Header | TIH Length | Reserved | Hop Count | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Flow ID | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Flow ID | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Sequence Number | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Data Set ID | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 Figure 3: TIH Format 504 o Next Header: the 8-bit indicator indicating the next protocol 505 after TIH. 507 o TIH Length: the 8-bit Instruction Header Length field. The value 508 is in the unit of 4-octet words. 510 o Hop Count: the 8-bit Hop Count field. It is used to count the 511 hops of the TIH-aware nodes, starting for 0 and incremented by 1 512 at each PBT-aware node. 514 o Flow ID: the 64-bit flow ID field. If the actual flow ID is 515 shorter than 64 bits, it is right aligned with the leading bits 516 being filled with 0. The field is set at the head node. 518 o Sequence Number: the 32-bit sequence number starting from 0 and 519 increasing by 1 for each following monitored packet from the same 520 flow at the head node. 522 o Data Set ID: This field defines the set of data that are required 523 to be collected at each node. It can be further partitioned into 524 two subfields, the name space ID and the data template ID, for 525 hierarchical scalability. 527 3.3. Considerations on PBT-I Design 529 4. Security Considerations 531 Several security issues need to be considered. 533 o Eavesdrop and tamper: the OAM packets can be encrypted and 534 authenticated. 536 o DoS attack: PBT can be limited to a single administration domain, 537 or the enforce mark or instruction header are checked at the 538 domain edge. The node can rate limit the extra traffic incurred 539 by the OAM data. 541 5. IANA Considerations 543 TBD. 545 6. Contributors 547 TBD. 549 7. Acknowledgments 551 TBD. 553 8. Informative References 555 [DOI_10.1145_2342441.2342453] 556 Handigol, N., Heller, B., Jeyakumar, V., MaziA(C)res, D., 557 and N. McKeown, "Where is the debugger for my software- 558 defined network?", Proceedings of the first workshop on 559 Hot topics in software defined networks - HotSDN '12, 560 DOI 10.1145/2342441.2342453, 2012. 562 [I-D.brockners-inband-oam-requirements] 563 Brockners, F., Bhandari, S., Dara, S., Pignataro, C., 564 Gredler, H., Leddy, J., Youell, S., Mozes, D., Mizrahi, 565 T., Lapukhov, P., and r. Chang, "Requirements for In-situ 566 OAM", draft-brockners-inband-oam-requirements-03 (work in 567 progress), March 2017. 569 [I-D.brockners-inband-oam-transport] 570 Brockners, F., Bhandari, S., Govindan, V., Pignataro, C., 571 Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes, 572 D., Lapukhov, P., and R. Chang, "Encapsulations for In- 573 situ OAM Data", draft-brockners-inband-oam-transport-05 574 (work in progress), July 2017. 576 [I-D.brockners-ippm-ioam-geneve] 577 Brockners, F., Bhandari, S., Govindan, V., Pignataro, C., 578 Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes, 579 D., Lapukhov, P., and R. Chang, "Geneve encapsulation for 580 In-situ OAM Data", draft-brockners-ippm-ioam-geneve-01 581 (work in progress), June 2018. 583 [I-D.bryant-mpls-synonymous-flow-labels] 584 Bryant, S., Swallow, G., Sivabalan, S., Mirsky, G., Chen, 585 M., and Z. Li, "RFC6374 Synonymous Flow Labels", draft- 586 bryant-mpls-synonymous-flow-labels-01 (work in progress), 587 July 2015. 589 [I-D.clemm-netconf-push-smart-filters-ps] 590 Clemm, A., Voit, E., Liu, X., Bryskin, I., Zhou, T., 591 Zheng, G., and H. Birkholz, "Smart filters for Push 592 Updates - Problem Statement", draft-clemm-netconf-push- 593 smart-filters-ps-00 (work in progress), October 2017. 595 [I-D.ietf-ippm-alt-mark] 596 Fioccola, G., Capello, A., Cociglio, M., Castaldelli, L., 597 Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 598 "Alternate Marking method for passive and hybrid 599 performance monitoring", draft-ietf-ippm-alt-mark-14 (work 600 in progress), December 2017. 602 [I-D.ietf-ippm-ioam-data] 603 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 604 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 605 P., Chang, R., and d. daniel.bernier@bell.ca, "Data Fields 606 for In-situ OAM", draft-ietf-ippm-ioam-data-00 (work in 607 progress), September 2017. 609 [I-D.ietf-netconf-udp-pub-channel] 610 Zheng, G., Zhou, T., and A. Clemm, "UDP based Publication 611 Channel for Streaming Telemetry", draft-ietf-netconf-udp- 612 pub-channel-01 (work in progress), November 2017. 614 [I-D.ietf-netconf-yang-push] 615 Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen- 616 Nygaard, E., Bierman, A., and B. Lengyel, "YANG Datastore 617 Subscription", draft-ietf-netconf-yang-push-12 (work in 618 progress), December 2017. 620 [I-D.ietf-sfc-ioam-nsh] 621 Brockners, F., Bhandari, S., Govindan, V., Pignataro, C., 622 Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes, 623 D., Lapukhov, P., and R. Chang, "NSH Encapsulation for In- 624 situ OAM Data", draft-ietf-sfc-ioam-nsh-00 (work in 625 progress), May 2018. 627 [I-D.ietf-sfc-nsh] 628 Quinn, P., Elzur, U., and C. Pignataro, "Network Service 629 Header (NSH)", draft-ietf-sfc-nsh-28 (work in progress), 630 November 2017. 632 [I-D.sambo-netmod-yang-fsm] 633 Sambo, N., Castoldi, P., Fioccola, G., Cugini, F., Song, 634 H., and T. Zhou, "YANG model for finite state machine", 635 draft-sambo-netmod-yang-fsm-00 (work in progress), October 636 2017. 638 [I-D.song-ippm-ioam-data-extension] 639 Song, H. and T. Zhou, "In-situ OAM Data Type Extension", 640 draft-song-ippm-ioam-data-extension-00 (work in progress), 641 October 2017. 643 [I-D.song-ippm-ioam-tunnel-mode] 644 Song, H., Li, Z., Zhou, T., and Z. Wang, "In-situ OAM 645 Processing in Tunnels", draft-song-ippm-ioam-tunnel- 646 mode-00 (work in progress), June 2018. 648 [I-D.song-mpls-extension-header] 649 Song, H., Li, Z., Zhou, T., and L. Andersson, "MPLS 650 Extension Header", draft-song-mpls-extension-header-01 651 (work in progress), August 2018. 653 [I-D.song-opsawg-dnp4iq] 654 Song, H. and J. Gong, "Requirements for Interactive Query 655 with Dynamic Network Probes", draft-song-opsawg-dnp4iq-01 656 (work in progress), June 2017. 658 [I-D.talwar-rtgwg-grpc-use-cases] 659 Specification, g., Kolhe, J., Shaikh, A., and J. George, 660 "Use cases for gRPC in network management", draft-talwar- 661 rtgwg-grpc-use-cases-01 (work in progress), January 2017. 663 [I-D.weis-ippm-ioam-gre] 664 Weis, B., Brockners, F., crhill@cisco.com, c., Bhandari, 665 S., Govindan, V., Pignataro, C., Gredler, H., Leddy, J., 666 Youell, S., Mizrahi, T., Kfir, A., Gafni, B., Lapukhov, 667 P., and M. Spiegel, "GRE Encapsulation for In-situ OAM 668 Data", draft-weis-ippm-ioam-gre-00 (work in progress), 669 March 2018. 671 [RFC2925] White, K., "Definitions of Managed Objects for Remote 672 Ping, Traceroute, and Lookup Operations", RFC 2925, 673 DOI 10.17487/RFC2925, September 2000, 674 . 676 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 677 and A. Bierman, Ed., "Network Configuration Protocol 678 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 679 . 681 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 682 "Specification of the IP Flow Information Export (IPFIX) 683 Protocol for the Exchange of Flow Information", STD 77, 684 RFC 7011, DOI 10.17487/RFC7011, September 2013, 685 . 687 Authors' Addresses 689 Haoyu Song (editor) 690 Huawei 691 2330 Central Expressway 692 Santa Clara, 95050 693 USA 695 Email: haoyu.song@huawei.com 697 Tianran Zhou 698 Huawei 699 156 Beiqing Road 700 Beijing, 100095 701 P.R. China 703 Email: zhoutianran@huawei.com 705 Zhenbin Li 706 Huawei 707 156 Beiqing Road 708 Beijing, 100095 709 P.R. China 711 Email: lizhenbin@huawei.com 713 Jongyoon Shin 714 SK Telecom 715 South Korea 717 Email: jongyoon.shin@sk.com