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