idnits 2.17.1 draft-song-multicast-telemetry-07.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 are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 19, 2021) is 1165 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) == Missing Reference: 'A' is mentioned on line 199, but not defined -- Looks like a reference, but probably isn't: '0' on line 199 -- Looks like a reference, but probably isn't: '1' on line 199 == Unused Reference: 'RFC4687' is defined on line 430, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4687 == Outdated reference: A later version (-14) exists of draft-ietf-bier-oam-requirements-11 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-11 == Outdated reference: A later version (-15) exists of draft-mirsky-ippm-hybrid-two-step-07 == Outdated reference: A later version (-16) exists of draft-song-ippm-postcard-based-telemetry-08 == Outdated reference: A later version (-13) exists of draft-song-mpls-extension-header-02 == Outdated reference: A later version (-10) exists of draft-xie-bier-ipv6-encapsulation-09 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MBONED H. Song 3 Internet-Draft M. McBride 4 Intended status: Standards Track Futurewei Technologies 5 Expires: July 23, 2021 G. Mirsky 6 ZTE Corp. 7 G. Mishra 8 Verizon Inc. 9 January 19, 2021 11 Multicast On-path Telemetry Solutions 12 draft-song-multicast-telemetry-07 14 Abstract 16 This document discusses the requirement of on-path telemetry for 17 multicast traffic. The existing solutions are examined and their 18 issues are identified. Solution modifications are proposed to allow 19 the original multicast tree to be correctly reconstructed without 20 unnecessary replication of telemetry information. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 26 "OPTIONAL" in this document are to be interpreted as described in BCP 27 14 [RFC2119][RFC8174] when, and only when, they appear in all 28 capitals, as shown here. 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 July 23, 2021. 47 Copyright Notice 49 Copyright (c) 2021 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Requirements for Multicast Traffic Telemetry . . . . . . . . 3 66 3. Issues of Existing Techniques . . . . . . . . . . . . . . . . 4 67 4. Proposed Modifications to Existing Techniques . . . . . . . . 4 68 4.1. Per-hop postcard using IOAM DEX . . . . . . . . . . . . . 5 69 4.2. Per-section postcard . . . . . . . . . . . . . . . . . . 7 70 5. Considerations for Different Multicast Protocols . . . . . . 8 71 5.1. Application in PIM . . . . . . . . . . . . . . . . . . . 8 72 5.2. Application in P2MP . . . . . . . . . . . . . . . . . . . 9 73 5.3. Application in BIER . . . . . . . . . . . . . . . . . . . 9 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 76 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 77 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 80 10.2. Informative References . . . . . . . . . . . . . . . . . 11 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 83 1. Introduction 85 Multicast traffic is an important traffic type in today's Internet. 86 Multicast provides services that are often real time (e.g., online 87 meeting) or have strict QoS requirements (e.g., IPTV, Market Data). 88 Multicast packet drop and delay can severely affect the application 89 performance and user experience. 91 It is important to monitor the performance of the multicast traffic. 92 Existing OAM techniques cannot gain direct and accurate information 93 about the multicast traffic. New on-path telemetry techniques such 94 as In-situ OAM [I-D.ietf-ippm-ioam-data], Postcard-based Telemetry 96 [I-D.song-ippm-postcard-based-telemetry], and Hybrid Two-Step (HTS) 97 [I-D.mirsky-ippm-hybrid-two-step] provide promising means to directly 98 monitor the network experience of multicast traffic. However, 99 multicast traffic has some unique characteristics which pose some 100 challenges on efficiently applying such techniques. 102 When a network contains multicast (p2mp) trees there will be 103 redundant data as data is replicated at branch points. The IP 104 Multicast S,G data is identical from one branch to another on it's 105 way to multiple receivers. When adding iOAM trace data, to multicast 106 packets, we enlarge data packets thus consuming more network 107 bandwidth. Instead of adding iOAM trace data, it could be more 108 efficient to collect the telemetry information using solutions, such 109 as iOAM postcard or HTS, to cut down on the redundant iOAM data. The 110 problem is that a postcard type solution doesn't have a branch 111 identifier. 113 This draft proposes a set of solutions to this iOAM data redundancy 114 problem. The requirements for multicast traffic telemetry are 115 discussed along with the issues of the existing on-path telemetry 116 techniques. We propose modifications to make these techniques adapt 117 to multicast in order for the original multicast tree to be correctly 118 reconstructed while eliminating redundant data. 120 2. Requirements for Multicast Traffic Telemetry 122 Multicast traffic is forwarded through a multicast tree. With PIM 123 and P2MP (MLDP, RSVP-TE) the forwarding tree is established and 124 maintained by the multicast routing protocol. With BIER, no state is 125 created in the network to establish a forwarding tree, instead, a 126 bier header provides the necessary information for each packet to 127 know the egress points. Multicast packets are only replicated at 128 each tree branch node for efficiency. 130 There are several requirements for multicast traffic telemetry, a few 131 of which are: 133 o Reconstruct and visualize the multicast tree through data plane 134 monitoring. 136 o Gather the multicast packet delay and jitter performance. 138 o Find the multicast packet drop location and reason. 140 o Gather the VPN state and tunnel information in case of P2MP 141 multicast. 143 In order to meet these requirements, we need the ability to directly 144 monitor the multicast traffic and derive data from the multicast 145 packets. The conventional OAM mechanisms, such as multicast ping and 146 trace, may not be sufficient to meet these requirements. 148 3. Issues of Existing Techniques 150 On-path Telemetry techniques that directly retrieve data from 151 multicast traffic's live network experience are ideal to address the 152 above mentioned requirements. The representative techniques include 153 In-situ OAM (IOAM) Trace option [I-D.ietf-ippm-ioam-data], IOAM 154 Direct Export (DEX) option [I-D.ioamteam-ippm-ioam-direct-export], 155 and Postcard-based Telemetry with Packet Marking(PBT-M) 156 [I-D.song-ippm-postcard-based-telemetry]. However, unlike unicast, 157 multicast poses some unique challenges to applying these techniques. 159 Multicast packets are replicated at each branch node in the 160 corresponding multicast tree. Therefore, there are multiple copies 161 of packets in the network. 163 If the IOAM trace option is used for on-path data collection, the 164 partial trace data will also be replicated into multiple copies. The 165 end result is that each copy of the multicast packet has a complete 166 trace. Most of the data, however, is redundant. Data redundancy 167 introduces unnecessary header overhead, wastes network bandwidth, and 168 complicates the data processing. In case the multicast tree is 169 large, and the path is long, the redundancy problem becomes severe. 171 The PBT solutions, including the IOAM DEX option and PBT-M, can be 172 used to eliminate such data redundancy, because each node on the tree 173 only sends a postcard covering local data. However, they cannot 174 track the tree branches properly so it can bring confusion about the 175 multicast tree topology. For example, Node A has two branches, one 176 to Node B and the other to node D, and Node B leads to Node C and 177 Node D leads to Node E. From the received postcards, one cannot tell 178 whether or not Node C(E) is the next hop of Node B(D). 180 The fundamental reason for this problem is that there is not an 181 identifier (either implicit or explicit) to correlate the data on 182 each branch. 184 4. Proposed Modifications to Existing Techniques 186 Two solutions are proposed to address the above issues. One is built 187 on PBT and requires augmentation or modification to the instruction 188 header of the IOAM Direct Export Option; the other combines the IOAM 189 trace option and PBT for an optimized solution. 191 4.1. Per-hop postcard using IOAM DEX 193 One way to mitigate PBT's multiple tree tracking weakness is to 194 augment it with a branch identifier field. Note that this works for 195 the IOAM DEX option but not for PBT-M because the IOAM DEX option 196 uses an instruction header. To make the branch identifier globally 197 unique, the branch node ID plus an index is used. For example, if 198 Node A has two branches, one to Node B and one to Node C, Node A will 199 use [A, 0] as the branch identifier for the branch to B, and [A, 1] 200 for the branch to C. The identifier is unchanged for each multicast 201 tree instance and carried with the multicast packet until the next 202 branch node. Each postcard needs to include the branch identifier in 203 the export data. The branch identifier, along with the other fields 204 such as flow ID and sequence number, is sufficient for the data 205 analyzer to reconstruct the topology of the multicast tree. 207 Figure 1 shows an example of this solution. "P" stands for the 208 postcard packet. The square brackets contains the branch identifier. 209 The curly brace contains the telemetry data about a specific node. 211 P:[A,0]{A} P:[A,0]{B} P:[B,1]{D} P:[B,0]{C} 212 ^ ^ ^ ^ 213 : : : : 214 : : : : 215 : : : +-:-+ 216 : : : | | 217 : : +---:----->| C |--... 218 +-:-+ +-:-+ | : | | 219 | | | |----+ : +---+ 220 | A |------->| B | : 221 | | | |--+ +-:-+ 222 +---+ +---+ | | | 223 +-->| D |--.... 224 | | 225 +---+ 227 Figure 1: Per-hop Postcard 229 Each branch fork node need to generate the branch ID for each branch 230 in its multicast tree instance and include it in the IOAM DEX option 231 header so the downstream node can learn it. The branch ID contains 232 two parts: the branch fork node ID and a unique branch index. 234 Figure 2 shows that the branch ID is carried as an optional field 235 after the flow ID and sequence number optional fields in the IOAM DEX 236 option header. A bit "M" in the Flags field is reserved to indicate 237 the presence of the branch index field. The "M" flag position will 238 be determined later after the other flags are specified in 239 [I-D.ioamteam-ippm-ioam-direct-export]. 241 0 1 2 3 242 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Namespace-ID |M| Flags | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | IOAM-Trace-Type | Reserved | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Flow ID (optional) | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Sequence Number (Optional) | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Encoded Branch ID (optional) | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 Figure 2: Carry Branch Index in IOAM DEX option header 257 To avoid introducing a new type of data field to the IOAM DEX option 258 header, we can encode the branch identifier using the existing node 259 ID data field as defined in [I-D.ietf-ippm-ioam-data]. Currently, 260 the node ID field occupies three octets. A simple solution is to 261 shorten the node ID field so a number of bits can be saved to encode 262 the branch index, as shown in Figure 3. 264 0 1 2 3 265 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Hop_Lim | node_id | branch index | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Figure 3: Encode Branch Index with Node ID Method 1 272 Another encoding method is to use the sum of the node ID and the 273 branch index as the new node ID, as shown in Figure 4. As long as 274 the node IDs are assigned with large enough gap, the telemetry data 275 analyzer can still successfully recover the original node ID and 276 branch index. 278 0 1 2 3 279 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Hop_Lim | node_id + branch index | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 Figure 4: Encode Branch Index with Node ID Method 2 286 Once a node gets the branch ID information from the upstream, it MUST 287 carry this information in its telemetry data export postcards, so the 288 original multicast tree can be correctly reconstructed based on the 289 postcards. 291 4.2. Per-section postcard 293 The second solution is a combination of the IOAM trace mode and PBT. 294 To avoid data redundancy at each branch node, the trace data 295 accumulated, to that point, is exported by a postcard before the 296 packet is replicated. In this case, each branch still needs to 297 maintain some identifier to help correlate the postcards for each 298 tree section. The natural way to accomplish this is to simply carry 299 the branch node's data (including its ID) in the trace of each 300 branch. This is also necessary because each replicated multicast 301 packet can have different telemetry data pertaining to this 302 particular copy (e.g., node delay, egress timestamp, and egress 303 interface). As a consequence, the local data exported by each branch 304 node can only contain partial data (e.g., ingress interface and 305 ingress timestamp). 307 Figure 5 shows an example in a segment of a multicast tree. Node B 308 and D are two branch nodes and they will export a postcard covering 309 the trace data for the previous section. The end node of each path 310 will also need to export the data of the last section as a postcard. 312 P:{A,B'} P:{B1,C,D'} 313 ^ ^ 314 : : 315 : : 316 : : {D1} 317 : : +--... 318 : +---+ +---+ | 319 : {B1} | |{B1,C}| |--+ {D2} 320 : +-->| C |----->| D |-----... 321 +---+ +---+ | | | | |--+ 322 | | {A} | |--+ +---+ +---+ | 323 | A |---->| B | +--... 324 | | | |--+ +---+ {D3} 325 +---+ +---+ | | |{B2,E} 326 +-->| E |--... 327 {B2} | | 328 +---+ 330 Figure 5: Per-section Postcard 332 There is no need to modify the IOAM trace mode header format. We 333 just need to configure the branch node to export the postcard and 334 refresh the IOAM header and data. 336 5. Considerations for Different Multicast Protocols 338 MTRACEv2 [RFC8487] provides an active probing approach for the 339 tracing of an IP multicast routing path. Mtrace can also provide 340 information such as the packet rates and losses, as well as other 341 diagnostic information. New on-path telemetry techniques will 342 enhance Mtrace, and other existing OAM solutions, with more granular 343 and realtime network status data through direct measurements. There 344 are various multicast protocols that are used to forward the 345 multicast data. Each will require their own unique on-path telemetry 346 solution. 348 5.1. Application in PIM 350 PIM-SM [RFC7761] is the most widely used multicast routing protocol 351 deployed today. Of the various PIM modes (PIM-SM, PIM-DM, BIDIR-PIM, 352 PIM-SSM), PIM-SSM is the preferred method due to its simplicity and 353 removal of network source discovery complexity. With all PIM modes, 354 control plane state is established in the network in order to forward 355 multicast UDP data packets. But with PIM-SSM, the discovery of 356 multicast sources is performed outside of the network via HTTP, SDN, 357 etc. IP Multicast packets fall within the range of 224.0.0.0 through 358 239.255.255.255. The telemetry solution will need to work within 359 this address range and provide telemetry data for this UDP traffic. 361 The proposed solutions for encapsulating the telemetry instruction 362 header and metadata in IPv4/IPv6 UDP packets are described in 363 [I-D.herbert-ipv4-udpencap-eh] and 364 [I-D.ioametal-ippm-6man-ioam-ipv6-deployment]. 366 5.2. Application in P2MP 368 Multicast Label Distribution Protocol (MLDP) and P2MP RSVP-TE are 369 commonly used within a Multicast VPN (MVPN) environment. MLDP 370 provides extensions to LDP to establish point-to-multipoint (P2MP) 371 and multipoint-to-multipoint (MP2MP) label switched paths (LSPs) in 372 MPLS networks. P2MP RSVP-TE provides extensions to RSVP-TE for 373 establish traffic-engineered P2MP LSPs in MPLS networks. The 374 telemetry solution will need to be able to follow these P2MP paths. 375 The telemetry instruction header and data should be encapsulated into 376 MPLS packets on P2MP paths. A corresponding proposal is described in 377 [I-D.song-mpls-extension-header]. 379 5.3. Application in BIER 381 BIER [RFC8279] adds a new header to multicast packets and allows the 382 multicast packets to be forwarded according to the header only. By 383 eliminating the requirement of maintaining per multicast group state, 384 BIER is more scalable than the traditional multicast solutions. 386 OAM Requirements for BIER [I-D.ietf-bier-oam-requirements] lists many 387 of the requirements for OAM at the BIER layer which will help in the 388 forming of on-path telemetry requirements as well. 390 There is also current work to provide solutions for BIER forwarding 391 in ipv6 networks. For instance, a solution, BIER in Non-MPLS IPv6 392 Networks [I-D.xie-bier-ipv6-encapsulation], proposes a new bier 393 Option Type codepoint from the "Destination Options and Hop-by-Hop 394 Options" IPv6 sub-registry. This is similar to what IOAM proposes 395 for IPv6 transport. 397 Depending on how the BIER header is encapsulated into packets with 398 different transport protocols, the method to encapsulate the 399 telemetry instruction header and metadata also varies. It is also 400 possible to make the instruction header and metadata a part of the 401 BIER header itself, such as in a TLV. 403 6. Security Considerations 405 No new security issues are identified other than those discovered by 406 the IOAM and PBT drafts. 408 7. IANA Considerations 410 The document makes no request of IANA. 412 8. Contributors 414 TBD 416 9. Acknowledgments 418 The authors would like to thank Frank Brockners, Tianran Zhou for the 419 comments and advice. 421 10. References 423 10.1. Normative References 425 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 426 Requirement Levels", BCP 14, RFC 2119, 427 DOI 10.17487/RFC2119, March 1997, 428 . 430 [RFC4687] Yasukawa, S., Farrel, A., King, D., and T. Nadeau, 431 "Operations and Management (OAM) Requirements for Point- 432 to-Multipoint MPLS Networks", RFC 4687, 433 DOI 10.17487/RFC4687, September 2006, 434 . 436 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 437 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 438 Multicast - Sparse Mode (PIM-SM): Protocol Specification 439 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 440 2016, . 442 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 443 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 444 May 2017, . 446 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 447 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 448 Explicit Replication (BIER)", RFC 8279, 449 DOI 10.17487/RFC8279, November 2017, 450 . 452 [RFC8487] Asaeda, H., Meyer, K., and W. Lee. Ed., "Mtrace Version 2: 453 Traceroute Facility for IP Multicast", RFC 8487, 454 DOI 10.17487/RFC8487, October 2018, 455 . 457 10.2. Informative References 459 [I-D.herbert-ipv4-udpencap-eh] 460 Herbert, T., "IPv4 Extension Headers and UDP Encapsulated 461 Extension Headers", draft-herbert-ipv4-udpencap-eh-01 462 (work in progress), March 2019. 464 [I-D.ietf-bier-oam-requirements] 465 Mirsky, G., Nainar, N., Chen, M., and S. Pallagatti, 466 "Operations, Administration and Maintenance (OAM) 467 Requirements for Bit Index Explicit Replication (BIER) 468 Layer", draft-ietf-bier-oam-requirements-11 (work in 469 progress), November 2020. 471 [I-D.ietf-ippm-ioam-data] 472 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 473 for In-situ OAM", draft-ietf-ippm-ioam-data-11 (work in 474 progress), November 2020. 476 [I-D.ioametal-ippm-6man-ioam-ipv6-deployment] 477 Bhandari, S., Brockners, F., Mizrahi, T., Kfir, A., Gafni, 478 B., Spiegel, M., Krishnan, S., and M. Smith, "Deployment 479 Considerations for In-situ OAM with IPv6 Options", draft- 480 ioametal-ippm-6man-ioam-ipv6-deployment-03 (work in 481 progress), March 2020. 483 [I-D.ioamteam-ippm-ioam-direct-export] 484 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 485 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 486 OAM Direct Exporting", draft-ioamteam-ippm-ioam-direct- 487 export-00 (work in progress), October 2019. 489 [I-D.mirsky-ippm-hybrid-two-step] 490 Mirsky, G., Lingqiang, W., Zhui, G., and H. Song, "Hybrid 491 Two-Step Performance Measurement Method", draft-mirsky- 492 ippm-hybrid-two-step-07 (work in progress), December 2020. 494 [I-D.song-ippm-postcard-based-telemetry] 495 Song, H., Zhou, T., Li, Z., Mirsky, G., Shin, J., and K. 496 Lee, "Postcard-based On-Path Flow Data Telemetry using 497 Packet Marking", draft-song-ippm-postcard-based- 498 telemetry-08 (work in progress), October 2020. 500 [I-D.song-mpls-extension-header] 501 Song, H., Li, Z., Zhou, T., and L. Andersson, "MPLS 502 Extension Header", draft-song-mpls-extension-header-02 503 (work in progress), February 2019. 505 [I-D.xie-bier-ipv6-encapsulation] 506 Xie, J., Geng, L., McBride, M., Asati, R., Dhanaraj, S., 507 Zhu, Y., Qin, Z., Shin, M., Mishra, G., and X. Geng, 508 "Encapsulation for BIER in Non-MPLS IPv6 Networks", draft- 509 xie-bier-ipv6-encapsulation-09 (work in progress), January 510 2021. 512 Authors' Addresses 514 Haoyu Song 515 Futurewei Technologies 516 2330 Central Expressway 517 Santa Clara 518 USA 520 Email: hsong@futurewei.com 522 Mike McBride 523 Futurewei Technologies 524 2330 Central Expressway 525 Santa Clara 526 USA 528 Email: mmcbride@futurewei.com 530 Greg Mirsky 531 ZTE Corp. 533 Email: gregimirsky@gmail.com 535 Gyan Mishra 536 Verizon Inc. 538 Email: gyan.s.mishra@verizon.com