idnits 2.17.1 draft-ietf-mboned-multicast-telemetry-02.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 1 instance 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 (4 January 2022) is 842 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 206, but not defined -- Looks like a reference, but probably isn't: '0' on line 206 -- Looks like a reference, but probably isn't: '1' on line 206 == Unused Reference: 'RFC4687' is defined on line 452, but no explicit reference was found in the text == Unused Reference: 'RFC6037' is defined on line 465, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4687 ** Downref: Normative reference to an Historic RFC: RFC 6037 == Outdated reference: A later version (-15) exists of draft-ietf-bier-oam-requirements-11 == Outdated reference: A later version (-19) exists of draft-ietf-spring-sr-replication-segment-06 == Outdated reference: A later version (-15) exists of draft-mirsky-ippm-hybrid-two-step-11 == Outdated reference: A later version (-16) exists of draft-song-ippm-postcard-based-telemetry-11 == Outdated reference: A later version (-13) exists of draft-song-mpls-extension-header-05 Summary: 2 errors (**), 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: 8 July 2022 G. Mirsky 6 ZTE Corp. 7 G. Mishra 8 Verizon Inc. 9 H. Asaeda 10 NICT 11 T. Zhou 12 Huawei 13 4 January 2022 15 Multicast On-path Telemetry Solutions 16 draft-ietf-mboned-multicast-telemetry-02 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 8 July 2022. 50 Copyright Notice 52 Copyright (c) 2022 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 (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Requirements for Multicast Traffic Telemetry . . . . . . . . 3 68 3. Issues of Existing Techniques . . . . . . . . . . . . . . . . 4 69 4. Proposed Modifications to Existing Techniques . . . . . . . . 5 70 4.1. Per-hop postcard using IOAM DEX . . . . . . . . . . . . . 5 71 4.2. Per-section postcard . . . . . . . . . . . . . . . . . . 7 72 5. Considerations for Different Multicast Protocols . . . . . . 8 73 5.1. Application in PIM . . . . . . . . . . . . . . . . . . . 8 74 5.2. Application of MVPN X-PMSI Tunnel Encapsulation 75 Attribute . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 12 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 86 1. Introduction 88 Multicast traffic is used across operator networks to support 89 residential broadband customers, private MPLS customers and used with 90 corporate intranet internal customers. Multicast provides real time 91 interactive online meetings or podcasts, IPTV and financial markets 92 real-time data, which all have a reliance on UDP's unreliable 93 transport. End to end QOS, therefore, should be a critical component 94 of multicast deployment in order to provide a good end user viewing 95 experience. If a packet is dropped, and that packet happens to be a 96 reference frame (I-Frame) in the video feed, the client receiver of 97 the multicast feed goes into buffering mode resulting in a frozen 98 window. Multicast packet drops and delay can severely affect the 99 application performance and user experience. 101 It is important to monitor the performance of the multicast traffic. 102 New on-path telemetry techniques such as In-situ OAM 103 [I-D.ietf-ippm-ioam-data], Postcard-based Telemetry 104 [I-D.song-ippm-postcard-based-telemetry], and Hybrid Two-Step (HTS) 105 [I-D.mirsky-ippm-hybrid-two-step] are useful and complementary to the 106 existing active OAM performance monitoring methods, provide promising 107 means to directly monitor the network experience of multicast 108 traffic. However, multicast traffic has some unique characteristics 109 which pose some challenges on efficiently applying such techniques. 111 The IP Multicast S,G data is identical from one branch to another on 112 it's way to multiple receivers. When adding iOAM trace data, to 113 multicast packets, we enlarge data packets thus consuming more 114 network bandwidth. Instead of adding iOAM trace data, it could be 115 more efficient to collect the telemetry information using solutions, 116 such as iOAM postcard or HTS, to cut down on the redundant iOAM data. 117 The problem is that a postcard type solution doesn't have a branch 118 identifier. 120 This draft proposes a set of solutions to this iOAM data redundancy 121 problem. The requirements for multicast traffic telemetry are 122 discussed along with the issues of the existing on-path telemetry 123 techniques. We propose modifications to make these techniques adapt 124 to multicast in order for the original multicast tree to be correctly 125 reconstructed while eliminating redundant data. 127 2. Requirements for Multicast Traffic Telemetry 129 Multicast traffic is forwarded through a multicast tree. With PIM 130 and P2MP (MLDP, RSVP-TE) the forwarding tree is established and 131 maintained by the multicast routing protocol. With BIER, no state is 132 created in the network to establish a forwarding tree, instead, a 133 bier header provides the necessary information for each packet to 134 know the egress points. Multicast packets are only replicated at 135 each tree branch node for efficiency. 137 There are several requirements for multicast traffic telemetry, a few 138 of which are: 140 * Reconstruct and visualize the multicast tree through data plane 141 monitoring. 143 * Gather the multicast packet delay and jitter performance. 145 * Find the multicast packet drop location and reason. 147 * Gather the VPN state and tunnel information in case of P2MP 148 multicast. 150 In order to meet these requirements, we need the ability to directly 151 monitor the multicast traffic and derive data from the multicast 152 packets. The conventional OAM mechanisms, such as multicast ping and 153 trace, may not be sufficient to meet these requirements. 155 3. Issues of Existing Techniques 157 On-path Telemetry techniques that directly retrieve data from 158 multicast traffic's live network experience are ideal to address the 159 above mentioned requirements. The representative techniques include 160 In-situ OAM (IOAM) Trace option [I-D.ietf-ippm-ioam-data], IOAM 161 Direct Export (DEX) option [I-D.ioamteam-ippm-ioam-direct-export], 162 and Postcard-based Telemetry with Packet Marking(PBT-M) 163 [I-D.song-ippm-postcard-based-telemetry]. However, unlike unicast, 164 multicast poses some unique challenges to applying these techniques. 166 Multicast packets are replicated at each branch node in the 167 corresponding multicast tree. Therefore, there are multiple copies 168 of packets in the network. 170 If the IOAM trace option is used for on-path data collection, the 171 partial trace data will also be replicated into multiple copies. The 172 end result is that each copy of the multicast packet has a complete 173 trace. Most of the data, however, is redundant. Data redundancy 174 introduces unnecessary header overhead, wastes network bandwidth, and 175 complicates the data processing. In case the multicast tree is 176 large, and the path is long, the redundancy problem becomes severe. 178 The PBT solutions, including the IOAM DEX option and PBT-M, can be 179 used to eliminate such data redundancy, because each node on the tree 180 only sends a postcard covering local data. However, they cannot 181 track the tree branches properly so it can bring confusion about the 182 multicast tree topology. For example, Node A has two branches, one 183 to Node B and the other to node D, and Node B leads to Node C and 184 Node D leads to Node E. From the received postcards, one cannot tell 185 whether or not Node C(E) is the next hop of Node B(D). 187 The fundamental reason for this problem is that there is not an 188 identifier (either implicit or explicit) to correlate the data on 189 each branch. 191 4. Proposed Modifications to Existing Techniques 193 Two solutions are proposed to address the above issues. One is built 194 on PBT and requires augmentation or modification to the instruction 195 header of the IOAM Direct Export Option; the other combines the IOAM 196 trace option and PBT for an optimized solution. 198 4.1. Per-hop postcard using IOAM DEX 200 One way to mitigate PBT's multiple tree tracking weakness is to 201 augment it with a branch identifier field. Note that this works for 202 the IOAM DEX option but not for PBT-M because the IOAM DEX option 203 uses an instruction header. To make the branch identifier globally 204 unique, the branch node ID plus an index is used. For example, if 205 Node A has two branches, one to Node B and one to Node C, Node A will 206 use [A, 0] as the branch identifier for the branch to B, and [A, 1] 207 for the branch to C. The identifier is unchanged for each multicast 208 tree instance and carried with the multicast packet until the next 209 branch node. Each postcard needs to include the branch identifier in 210 the export data. The branch identifier, along with the other fields 211 such as flow ID and sequence number, is sufficient for the data 212 analyzer to reconstruct the topology of the multicast tree. 214 Figure 1 shows an example of this solution. "P" stands for the 215 postcard packet. The square brackets contains the branch identifier. 216 The curly brace contains the telemetry data about a specific node. 218 P:[A,0]{A} P:[A,0]{B} P:[B,1]{D} P:[B,0]{C} 219 ^ ^ ^ ^ 220 : : : : 221 : : : : 222 : : : +-:-+ 223 : : : | | 224 : : +---:----->| C |--... 225 +-:-+ +-:-+ | : | | 226 | | | |----+ : +---+ 227 | A |------->| B | : 228 | | | |--+ +-:-+ 229 +---+ +---+ | | | 230 +-->| D |--.... 231 | | 232 +---+ 234 Figure 1: Per-hop Postcard 236 Each branch fork node needs to generate the branch ID for each branch 237 in its multicast tree instance and include it in the IOAM DEX option 238 header so the downstream node can learn it. The branch ID contains 239 two parts: the branch fork node ID and a unique branch index. 241 Figure 2 shows that the branch ID is carried as an optional field 242 after the flow ID and sequence number optional fields in the IOAM DEX 243 option header. A bit "M" in the Flags field is reserved to indicate 244 the presence of the branch index field. The "M" flag position will 245 be determined later after the other flags are specified in 246 [I-D.ioamteam-ippm-ioam-direct-export]. 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Namespace-ID |M| Flags | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | IOAM-Trace-Type | Reserved | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Flow ID (optional) | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Sequence Number (Optional) | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Encoded Branch ID (optional) | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 Figure 2: Carry Branch Index in IOAM DEX option header 264 To avoid introducing a new type of data field to the IOAM DEX option 265 header, we can encode the branch identifier using the existing node 266 ID data field as defined in [I-D.ietf-ippm-ioam-data]. Currently, 267 the node ID field occupies three octets. A simple solution is to 268 shorten the node ID field so a number of bits can be saved to encode 269 the branch index, as shown in Figure 3. 271 0 1 2 3 272 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 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Hop_Lim | node_id | branch index | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 Figure 3: Encode Branch Index with Node ID Method 1 279 Another encoding method is to use the sum of the node ID and the 280 branch index as the new node ID, as shown in Figure 4. As long as 281 the node IDs are assigned with large enough gap, the telemetry data 282 analyzer can still successfully recover the original node ID and 283 branch index. 285 0 1 2 3 286 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 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Hop_Lim | node_id + branch index | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 Figure 4: Encode Branch Index with Node ID Method 2 293 Once a node gets the branch ID information from the upstream, it MUST 294 carry this information in its telemetry data export postcards, so the 295 original multicast tree can be correctly reconstructed based on the 296 postcards. 298 4.2. Per-section postcard 300 The second solution is a combination of the IOAM trace mode and PBT. 301 To avoid data redundancy at each branch node, the trace data 302 accumulated, to that point, is exported by a postcard before the 303 packet is replicated. In this case, each branch still needs to 304 maintain some identifier to help correlate the postcards for each 305 tree section. The natural way to accomplish this is to simply carry 306 the branch node's data (including its ID) in the trace of each 307 branch. This is also necessary because each replicated multicast 308 packet can have different telemetry data pertaining to this 309 particular copy (e.g., node delay, egress timestamp, and egress 310 interface). As a consequence, the local data exported by each branch 311 node can only contain partial data (e.g., ingress interface and 312 ingress timestamp). 314 Figure 5 shows an example in a segment of a multicast tree. Node B 315 and D are two branch nodes and they will export a postcard covering 316 the trace data for the previous section. The end node of each path 317 will also need to export the data of the last section as a postcard. 319 P:{A,B'} P:{B1,C,D'} 320 ^ ^ 321 : : 322 : : 323 : : {D1} 324 : : +--... 325 : +---+ +---+ | 326 : {B1} | |{B1,C}| |--+ {D2} 327 : +-->| C |----->| D |-----... 328 +---+ +---+ | | | | |--+ 329 | | {A} | |--+ +---+ +---+ | 330 | A |---->| B | +--... 331 | | | |--+ +---+ {D3} 332 +---+ +---+ | | |{B2,E} 333 +-->| E |--... 334 {B2} | | 335 +---+ 337 Figure 5: Per-section Postcard 339 There is no need to modify the IOAM trace mode header format. We 340 just need to configure the branch node to export the postcard and 341 refresh the IOAM header and data. 343 5. Considerations for Different Multicast Protocols 345 MTRACEv2 [RFC8487] provides an active probing approach for the 346 tracing of an IP multicast routing path. Mtrace can also provide 347 information such as the packet rates and losses, as well as other 348 diagnostic information. New on-path telemetry techniques will 349 enhance Mtrace, and other existing OAM solutions, with more granular 350 and realtime network status data through direct measurements. There 351 are various multicast protocols that are used to forward the 352 multicast data. Each will require their own unique on-path telemetry 353 solution. 355 5.1. Application in PIM 357 PIM-SM [RFC7761] is the most widely used multicast routing protocol 358 deployed today. Of the various PIM modes (PIM-SM, PIM-DM, BIDIR-PIM, 359 PIM-SSM), PIM-SSM is the preferred method due to its simplicity and 360 removal of network source discovery complexity. With all PIM modes, 361 control plane state is established in the network in order to forward 362 multicast UDP data packets. All PIM modes utilize network based 363 source discovery except for PIM-SSM, which utilizes application based 364 source discovery. IP Multicast packets fall within the range of 365 224.0.0.0 through 239.255.255.255. The telemetry solution will need 366 to work within this address range and provide telemetry data for this 367 UDP traffic. 369 The proposed solutions for encapsulating the telemetry instruction 370 header and metadata in IPv4/IPv6 UDP packets are described in 371 [I-D.herbert-ipv4-udpencap-eh] and 372 [I-D.ioametal-ippm-6man-ioam-ipv6-deployment]. 374 5.2. Application of MVPN X-PMSI Tunnel Encapsulation Attribute 376 Multipoint Label Distribution Protocol (mLDP), P2MP RSVP-TE, Ingress 377 Replication (IR), PIM MDT SAFI with GRE Transport, are commonly used 378 within a Multicast VPN (MVPN) environment utilizing MVPN procedures 379 Multicast in MPLS/BGP IP VPNs [RFC6513] and BGP Encoding and 380 Procedures for Multicast in MPLS/BGP IP VPNs [RFC6514]. MLDP LDP 381 Extension for P2MP and MP2MP LSPs [RFC6388] provides extensions to 382 LDP to establish point-to-multipoint (P2MP) and multipoint-to- 383 multipoint (MP2MP) label switched paths (LSPs) in MPLS networks. 384 P2MP RSVP-TE provides extensions to RSVP-TE RSVP-TE for P2MP LSPs 385 [RFC4875] for establish traffic-engineered P2MP LSPs in MPLS 386 networks. Ingress Replication (IR) P2MP Trees Ingress Replication 387 Tunnels in Multicast VPNs [RFC7988] using unicast replication from 388 parent node to child node over MPLS Unicast Tunnel. PIM MDT SAFI 389 Multicast in BGP/MPLS IP VPNs [RFC6037]utilizes PIM modes PIM-SSM, 390 PIM-SM, PIM-BIDIR control plane with GRE transport data plane in the 391 core for X-PMSI P-Tree using MVPN procedures. Replication SID SR 392 Replication Segment for Multi-point Service Delivery 393 [I-D.ietf-spring-sr-replication-segment] replication segments for 394 P2MP multicast service delivery in Segment Routing SR-MPLS networks. 395 The telemetry solution will need to be able to follow these P2MP and 396 MP2MP paths. The telemetry instruction header and data should be 397 encapsulated into MPLS packets on P2MP and MP2MP paths. A 398 corresponding proposal is described in 399 [I-D.song-mpls-extension-header]. 401 5.3. Application in BIER 403 BIER [RFC8279] adds a new header to multicast packets and allows the 404 multicast packets to be forwarded according to the header only. By 405 eliminating the requirement of maintaining per multicast group state, 406 BIER is more scalable than the traditional multicast solutions. 408 OAM Requirements for BIER [I-D.ietf-bier-oam-requirements] lists many 409 of the requirements for OAM at the BIER layer which will help in the 410 forming of on-path telemetry requirements as well. 412 There is also current work to provide solutions for BIER forwarding 413 in ipv6 networks. For instance, a solution, BIER in Non-MPLS IPv6 414 Networks [I-D.xie-bier-ipv6-encapsulation], proposes a new bier 415 Option Type codepoint from the "Destination Options and Hop-by-Hop 416 Options" IPv6 sub-registry. This is similar to what IOAM proposes 417 for IPv6 transport. 419 Depending on how the BIER header is encapsulated into packets with 420 different transport protocols, the method to encapsulate the 421 telemetry instruction header and metadata also varies. It is also 422 possible to make the instruction header and metadata a part of the 423 BIER header itself, such as in a TLV. 425 6. Security Considerations 427 No new security issues are identified other than those discovered by 428 the IOAM, PBT and HTS drafts. 430 7. IANA Considerations 432 The document makes no request of IANA. 434 8. Contributors 436 TBD 438 9. Acknowledgments 440 The authors would like to thank Frank Brockners for the comments and 441 advice. 443 10. References 445 10.1. Normative References 447 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 448 Requirement Levels", BCP 14, RFC 2119, 449 DOI 10.17487/RFC2119, March 1997, 450 . 452 [RFC4687] Yasukawa, S., Farrel, A., King, D., and T. Nadeau, 453 "Operations and Management (OAM) Requirements for Point- 454 to-Multipoint MPLS Networks", RFC 4687, 455 DOI 10.17487/RFC4687, September 2006, 456 . 458 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 459 Yasukawa, Ed., "Extensions to Resource Reservation 460 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 461 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 462 DOI 10.17487/RFC4875, May 2007, 463 . 465 [RFC6037] Rosen, E., Ed., Cai, Y., Ed., and IJ. Wijnands, "Cisco 466 Systems' Solution for Multicast in BGP/MPLS IP VPNs", 467 RFC 6037, DOI 10.17487/RFC6037, October 2010, 468 . 470 [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. 471 Thomas, "Label Distribution Protocol Extensions for Point- 472 to-Multipoint and Multipoint-to-Multipoint Label Switched 473 Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, 474 . 476 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 477 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 478 2012, . 480 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 481 Encodings and Procedures for Multicast in MPLS/BGP IP 482 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 483 . 485 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 486 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 487 Multicast - Sparse Mode (PIM-SM): Protocol Specification 488 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 489 2016, . 491 [RFC7988] Rosen, E., Ed., Subramanian, K., and Z. Zhang, "Ingress 492 Replication Tunnels in Multicast VPN", RFC 7988, 493 DOI 10.17487/RFC7988, October 2016, 494 . 496 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 497 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 498 May 2017, . 500 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 501 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 502 Explicit Replication (BIER)", RFC 8279, 503 DOI 10.17487/RFC8279, November 2017, 504 . 506 [RFC8487] Asaeda, H., Meyer, K., and W. Lee, Ed., "Mtrace Version 2: 507 Traceroute Facility for IP Multicast", RFC 8487, 508 DOI 10.17487/RFC8487, October 2018, 509 . 511 10.2. Informative References 513 [I-D.herbert-ipv4-udpencap-eh] 514 Herbert, T., "IPv4 Extension Headers and UDP Encapsulated 515 Extension Headers", Work in Progress, Internet-Draft, 516 draft-herbert-ipv4-udpencap-eh-01, 8 March 2019, 517 . 520 [I-D.ietf-bier-oam-requirements] 521 Mirsky, G., Kumar, N., Chen, M., and S. Pallagatti, 522 "Operations, Administration and Maintenance (OAM) 523 Requirements for Bit Index Explicit Replication (BIER) 524 Layer", Work in Progress, Internet-Draft, draft-ietf-bier- 525 oam-requirements-11, 15 November 2020, 526 . 529 [I-D.ietf-ippm-ioam-data] 530 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 531 for In-situ OAM", Work in Progress, Internet-Draft, draft- 532 ietf-ippm-ioam-data-17, 13 December 2021, 533 . 536 [I-D.ietf-spring-sr-replication-segment] 537 (editor), D. V., Filsfils, C., Parekh, R., Bidgoli, H., 538 and Z. Zhang, "SR Replication Segment for Multi-point 539 Service Delivery", Work in Progress, Internet-Draft, 540 draft-ietf-spring-sr-replication-segment-06, 25 October 541 2021, . 544 [I-D.ioametal-ippm-6man-ioam-ipv6-deployment] 545 Bhandari, S., Brockners, F., Mizrahi, T., Kfir, A., Gafni, 546 B., Spiegel, M., Krishnan, S., and M. Smith, "Deployment 547 Considerations for In-situ OAM with IPv6 Options", Work in 548 Progress, Internet-Draft, draft-ioametal-ippm-6man-ioam- 549 ipv6-deployment-03, 29 March 2020, 550 . 553 [I-D.ioamteam-ippm-ioam-direct-export] 554 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 555 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 556 OAM Direct Exporting", Work in Progress, Internet-Draft, 557 draft-ioamteam-ippm-ioam-direct-export-00, 12 October 558 2019, . 561 [I-D.mirsky-ippm-hybrid-two-step] 562 Mirsky, G., Lingqiang, W., Zhui, G., and H. Song, "Hybrid 563 Two-Step Performance Measurement Method", Work in 564 Progress, Internet-Draft, draft-mirsky-ippm-hybrid-two- 565 step-11, 8 July 2021, . 568 [I-D.song-ippm-postcard-based-telemetry] 569 Song, H., Mirsky, G., Filsfils, C., Abdelsalam, A., Zhou, 570 T., Li, Z., Shin, J., and K. Lee, "In-Situ OAM Marking- 571 based Direct Export", Work in Progress, Internet-Draft, 572 draft-song-ippm-postcard-based-telemetry-11, 15 November 573 2021, . 576 [I-D.song-mpls-extension-header] 577 Song, H., Li, Z., Zhou, T., Andersson, L., and Z. Zhang, 578 "MPLS Extension Header", Work in Progress, Internet-Draft, 579 draft-song-mpls-extension-header-05, 10 July 2021, 580 . 583 [I-D.xie-bier-ipv6-encapsulation] 584 Xie, J., Geng, L., McBride, M., Asati, R., Dhanaraj, S., 585 Zhu, Y., Qin, Z., Shin, M., Mishra, G., and X. Geng, 586 "Encapsulation for BIER in Non-MPLS IPv6 Networks", Work 587 in Progress, Internet-Draft, draft-xie-bier-ipv6- 588 encapsulation-10, 22 February 2021, 589 . 592 Authors' Addresses 594 Haoyu Song 595 Futurewei Technologies 596 2330 Central Expressway 597 Santa Clara, 598 United States of America 600 Email: hsong@futurewei.com 601 Mike McBride 602 Futurewei Technologies 603 2330 Central Expressway 604 Santa Clara, 605 United States of America 607 Email: mmcbride@futurewei.com 609 Greg Mirsky 610 ZTE Corp. 612 Email: gregimirsky@gmail.com 614 Gyan Mishra 615 Verizon Inc. 617 Email: gyan.s.mishra@verizon.com 619 Hitoshi Asaeda 620 National Institute of Information and Communications Technology 621 4-2-1 Nukui-Kitamachi, Tokyo 622 184-8795 623 Japan 625 Email: asaeda@nict.go.jp 627 Tianran Zhou 628 Huawei 630 Email: zhoutianran@huawei.com