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