idnits 2.17.1 draft-song-multicast-telemetry-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 1, 2019) is 1637 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'A' is mentioned on line 179, but not defined -- Looks like a reference, but probably isn't: '0' on line 178 -- Looks like a reference, but probably isn't: '1' on line 179 == Unused Reference: 'RFC4687' is defined on line 347, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-bier-oam-requirements-08 == Outdated reference: A later version (-03) exists of draft-ioametal-ippm-6man-ioam-ipv6-deployment-02 == Outdated reference: A later version (-16) exists of draft-song-ippm-postcard-based-telemetry-06 == 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-03 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Song, Ed. 3 Internet-Draft M. McBride 4 Intended status: Informational Futurewei Technologies 5 Expires: May 4, 2020 G. Mirsky 6 ZTE Corp. 7 November 1, 2019 9 Requirement and Solution for Multicast Traffic Telemetry 10 draft-song-multicast-telemetry-01 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 addressed with new modifications that adapt to the 17 multicast scenario. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 23 "OPTIONAL" in this document are to be interpreted as described in BCP 24 14 [RFC2119][RFC8174] when, and only when, they appear in all 25 capitals, as shown here. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 4, 2020. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Requirements for Multicast Traffic Telemetry . . . . . . . . 3 63 3. Issues of Existing Techniques . . . . . . . . . . . . . . . . 3 64 4. Proposed Modifications to Existing Techniques . . . . . . . . 4 65 4.1. Per-hop postcard . . . . . . . . . . . . . . . . . . . . 4 66 4.2. Per-section postcard . . . . . . . . . . . . . . . . . . 5 67 5. Considerations for Different Multicast Protocols . . . . . . 6 68 5.1. Application in PIM . . . . . . . . . . . . . . . . . . . 6 69 5.2. Application in P2MP . . . . . . . . . . . . . . . . . . . 7 70 5.3. Application in BIER . . . . . . . . . . . . . . . . . . . 7 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 73 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 74 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 77 10.2. Informative References . . . . . . . . . . . . . . . . . 9 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 80 1. Introduction 82 Multicast traffic is an important traffic type in today's Internet. 83 Multicast provides services that are often real time (e.g., online 84 meeting) or have strict QoS requirements (e.g., IPTV, Market Data). 85 Multicast packet drop and delay can severely affect the application 86 performance and user experience. 88 It is important to monitor the performance of the multicast traffic. 89 Existing OAM techniques cannot gain direct and accurate information 90 about the multicast traffic. New on-path telemetry techniques such 91 as In-situ OAM [I-D.brockners-inband-oam-data] and Postcard-based 92 Telemetry [I-D.song-ippm-postcard-based-telemetry] provide promising 93 means to directly monitor the network experience of multicast 94 traffic. However, multicast traffic has some unique characteristics 95 which pose some challenges on efficiently applying such techniques. 97 This document describes the requirement for multicast traffic 98 telemetry and shows the issues of the existing on-path telemetry 99 techniques. We then propose modifications to make these techniques 100 adapt to the multicast application. 102 2. Requirements for Multicast Traffic Telemetry 104 Multicast traffic is forwarded through a multicast tree. With PIM 105 and P2MP (MLDP, RSVP-TE) the forwarding tree is established and 106 maintained by the multicast routing protocol. With BIER, no state is 107 created in the network to establish a forwarding tree, instead, a 108 bier header provides the necessary information for each packet to 109 know the egress points. Multicast packets are only replicated at 110 each tree branch node for efficiency. 112 There are several requirements for multicast traffic telemetry, a few 113 of which are: 115 o Reconstruct and visualize the multicast tree through data plane 116 monitoring. 118 o Gather the multicast packet delay and jitter performance. 120 o Find the multicast packet drop location and reason. 122 o Gather the VPN state and tunnel information in case of P2MP 123 multicast. 125 In order to meet these requirements, we need the ability to directly 126 monitor the multicast traffic and derive data from the multicast 127 packets. The conventional OAM mechanisms, such as multicast ping and 128 trace, may not be sufficient to meet these requirements. 130 3. Issues of Existing Techniques 132 On-path Telemetry techniques that directly retrieve data from 133 multicast traffic's live network experience are ideal to address the 134 above mentioned requirements. The representative techniques include 135 In-situ OAM (IOAM) [I-D.brockners-inband-oam-data] and Postcard-based 136 Telemetry (PBT) [I-D.song-ippm-postcard-based-telemetry]. However, 137 unlike unicast, multicast poses some unique challenges to applying 138 these techniques. 140 Multicast packets are replicated at each branch node in the 141 corresponding multicast tree. Therefore, there are multiple copies 142 of a packets in the network. 144 If IOAM is used for on-path data collection, the partial trace data 145 will also be replicated into multiple copies. The end result is that 146 each copy of the multicast packet has a complete trace. Most of the 147 data is redundant. Data redundancy introduces unnecessary header 148 overhead, wastes network bandwidth, and complicates the data 149 processing. In case the multicast tree is large, and the path is 150 long, the redundancy problem becomes severe. 152 PBT can be used to eliminate such data redundancy, because each node 153 on the tree only sends a postcard covering local data. However, PBT 154 cannot track the tree branches properly so it can bring confusion 155 about the multicast tree topology. For example, Node A has two 156 branches, one to Node B and one to node D, and Node B leads to Node C 157 and Node D leads to Node E. From the received postcard, one cannot 158 tell whether or not Node C(E) is the next hop of Node B(D). 160 The fundamental reason for this problem is that there is not an 161 identifier (either implicit or explicit) to correlate the data on 162 each branch. 164 4. Proposed Modifications to Existing Techniques 166 We propose two solutions to address the above issues. One is built 167 on PBT and requires augmentation to the instruction header of PBT-I; 168 the other combines the IOAM trace mode and PBT for an optimized 169 solution. 171 4.1. Per-hop postcard 173 The straightforward way to mitigate PBT's multiple tree tracking 174 weakness is to augment it with a branch identifier field. Note that 175 this only works for the PBT-I variation where an instruction header 176 is present. To make the branch identifier globally unique, the 177 branch node ID plus an index is used. For example, if Node A has two 178 branches, one to Node B and one to Node C, Node A will use [A, 0] as 179 the branch identifier for the branch to B, and [A, 1] for the branch 180 to C. The identifier is unchanged and carried with the multicast 181 packet until the next branch node. Each postcard needs to include 182 the branch identifier in the export data. The branch identifier, 183 along with the other fields such as flow ID and sequence number, is 184 sufficient for the data analyzer to reconstruct the topology of the 185 multicast tree. 187 Figure 1 shows an example of this solution. "P" stands for the 188 postcard packet. The square brackets contains the branch identifier. 189 The curly brace contains the telemetry data about a specific node. 191 P:[A,0]{A} P:[A,0]{B} P:[B,1]{D} P:[B,0]{C} 192 ^ ^ ^ ^ 193 : : : : 194 : : : : 195 : : : +-:-+ 196 : : : | | 197 : : +---:----->| C |--... 198 +-:-+ +-:-+ | : | | 199 | | | |----+ : +---+ 200 | A |------->| B | : 201 | | | |--+ +-:-+ 202 +---+ +---+ | | | 203 +-->| D |--.... 204 | | 205 +---+ 207 Figure 1: Per-hop Postcard 209 4.2. Per-section postcard 211 The second solution is a combination of the IOAM trace mode and PBT. 212 To avoid data redundancy at each branch node, the trace data 213 accumulated, to that point, is exported by a postcard before the 214 packet is replicated. In this case, each branch still needs to 215 maintain some identifier to help correlate the postcards for each 216 tree section. The natural way to accomplish this is to simply carry 217 the branch node's data (including its ID) in the trace of each 218 branch. This is also necessary because each replicated multicast 219 packet can have different telemetry data pertaining to this 220 particular copy (e.g., node delay, egress timestamp, and egress 221 interface). As a consequence, the local data exported by each branch 222 node can only contain partial data (e.g., ingress interface and 223 ingress timestamp). 225 Figure 2 shows an example in a segment of a multicast tree. Node B 226 and D are two branch nodes and they will export a postcard covering 227 the trace data for the previous section. The end node of each path 228 will also need to export the data of the last section as a postcard. 230 P:{A,B'} P:{B,C,D} 231 ^ ^ 232 : : 233 : : 234 : : {D} 235 : : +--... 236 : +---+ +---+ | 237 : {B} | |{B,C}| |--+ 238 : +-->| C |---->| D | 239 +---+ +---+ | | | | |--+ 240 | | {A} | |--+ +---+ +---+ | 241 | A |---->| B | +--... 242 | | | |--+ +---+ {D} 243 +---+ +---+ | | |{B,E} 244 +-->| E |--... 245 {B} | | 246 +---+ 248 Figure 2: Per-section Postcard 250 There is no need to modify the IOAM trace mode header format. We 251 just need to configure the branch node to export the postcard and 252 refresh the IOAM header and data. 254 5. Considerations for Different Multicast Protocols 256 MTRACEv2 [RFC8487] provides an active probing approach for the 257 tracing of an IP multicast routing path. Mtrace can also provide 258 information such as the packet rates and losses, as well as other 259 diagnostic information. New on-path telemetry techniques will 260 enhance Mtrace, and other existing OAM solutions, with more granular 261 and realtime network status data through direct measurements. There 262 are various multicast protocols that are used to forward the 263 multicast data. Each will require their own unique on-path telemetry 264 solution. 266 5.1. Application in PIM 268 PIM-SM [RFC7761] is the most widely used multicast routing protocol 269 deployed today. Of the various PIM modes (PIM-SM, PIM-DM, BIDIR-PIM, 270 PIM-SSM), PIM-SSM is the preferred method due to its simplicity and 271 removal of network source discovery complexity. With all PIM modes, 272 control plane state is established in the network in order to forward 273 multicast UDP data packets. But with PIM-SSM, the discovery of 274 multicast sources is performed outside of the network via HTTP, SDN, 275 etc. IP Multicast packets fall within the range of 224.0.0.0 through 276 239.255.255.255. The telemetry solution will need to work within 277 this address range and provide telemetry data for this UDP traffic. 279 The proposed solutions for encapsulating the telemetry instruction 280 header and metadata in IPv4/IPv6 UDP packets are described in 281 [I-D.herbert-ipv4-udpencap-eh] and 282 [I-D.ioametal-ippm-6man-ioam-ipv6-deployment]. 284 5.2. Application in P2MP 286 Multicast Label Distribution Protocol (MLDP) and P2MP RSVP-TE are 287 commonly used within a Multicast VPN (MVPN) environment. MLDP 288 provides extensions to LDP to establish point-to-multipoint (P2MP) 289 and multipoint-to-multipoint (MP2MP) label switched paths (LSPs) in 290 MPLS networks. P2MP RSVP-TE provides extensions to RSVP-TE for 291 establish traffic-engineered P2MP LSPs in MPLS networks. The 292 telemetry solution will need to be able to follow these P2MP paths. 293 The telemetry instruction header and data should be encapsulated into 294 MPLS packets on P2MP paths. A corresponding proposal is described in 295 [I-D.song-mpls-extension-header]. 297 5.3. Application in BIER 299 BIER [RFC8279] adds a new header to multicast packets and allows the 300 multicast packets to be forwarded according to the header only. By 301 eliminating the requirement of maintaining per multicast group state, 302 BIER is more scalable than the traditional multicast solutions. 304 OAM Requirements for BIER [I-D.ietf-bier-oam-requirements] lists many 305 of the requirements for OAM at the BIER layer which will help in the 306 forming of on-path telemetry requirements as well. 308 There is also current work to provide solutions for BIER forwarding 309 in ipv6 networks. For instance, a solution, BIER in Non-MPLS IPv6 310 Networks [I-D.xie-bier-ipv6-encapsulation], proposes a new bier 311 Option Type codepoint from the "Destination Options and Hop-by-Hop 312 Options" IPv6 sub-registry. This is similar to what IOAM proposes 313 for IPv6 transport. 315 Depending on how the BIER header is encapsulated into packets with 316 different transport protocols, the method to encapsulate the 317 telemetry instruction header and metadata also varies. It is also 318 possible to make the instruction header and metadata a part of the 319 BIER header itself, such as in a TLV. 321 6. Security Considerations 323 No new secuirty issues are identified other than those discovered by 324 the IOAM and PBT drafts. 326 7. IANA Considerations 328 The document makes no request of IANA. 330 8. Contributors 332 TBD 334 9. Acknowledgments 336 TBD 338 10. References 340 10.1. Normative References 342 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 343 Requirement Levels", BCP 14, RFC 2119, 344 DOI 10.17487/RFC2119, March 1997, 345 . 347 [RFC4687] Yasukawa, S., Farrel, A., King, D., and T. Nadeau, 348 "Operations and Management (OAM) Requirements for Point- 349 to-Multipoint MPLS Networks", RFC 4687, 350 DOI 10.17487/RFC4687, September 2006, 351 . 353 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 354 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 355 Multicast - Sparse Mode (PIM-SM): Protocol Specification 356 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 357 2016, . 359 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 360 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 361 May 2017, . 363 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 364 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 365 Explicit Replication (BIER)", RFC 8279, 366 DOI 10.17487/RFC8279, November 2017, 367 . 369 [RFC8487] Asaeda, H., Meyer, K., and W. Lee. Ed., "Mtrace Version 2: 370 Traceroute Facility for IP Multicast", RFC 8487, 371 DOI 10.17487/RFC8487, October 2018, 372 . 374 10.2. Informative References 376 [I-D.brockners-inband-oam-data] 377 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 378 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 379 P., Chang, R., and d. daniel.bernier@bell.ca, "Data Fields 380 for In-situ OAM", draft-brockners-inband-oam-data-07 (work 381 in progress), July 2017. 383 [I-D.herbert-ipv4-udpencap-eh] 384 Herbert, T., "IPv4 Extension Headers and UDP Encapsulated 385 Extension Headers", draft-herbert-ipv4-udpencap-eh-01 386 (work in progress), March 2019. 388 [I-D.ietf-bier-oam-requirements] 389 Mirsky, G., Nordmark, E., Pignataro, C., Kumar, N., 390 Aldrin, S., Zheng, L., Chen, M., Akiya, N., and S. 391 Pallagatti, "Operations, Administration and Maintenance 392 (OAM) Requirements for Bit Index Explicit Replication 393 (BIER) Layer", draft-ietf-bier-oam-requirements-08 (work 394 in progress), August 2019. 396 [I-D.ioametal-ippm-6man-ioam-ipv6-deployment] 397 Bhandari, S., Brockners, F., Mizrahi, T., Kfir, A., Gafni, 398 B., Spiegel, M., Krishnan, S., and M. Smith, "Deployment 399 Considerations for In-situ OAM with IPv6 Options", draft- 400 ioametal-ippm-6man-ioam-ipv6-deployment-02 (work in 401 progress), September 2019. 403 [I-D.song-ippm-postcard-based-telemetry] 404 Song, H., Zhou, T., Li, Z., Shin, J., and K. Lee, 405 "Postcard-based On-Path Flow Data Telemetry", draft-song- 406 ippm-postcard-based-telemetry-06 (work in progress), 407 October 2019. 409 [I-D.song-mpls-extension-header] 410 Song, H., Li, Z., Zhou, T., and L. Andersson, "MPLS 411 Extension Header", draft-song-mpls-extension-header-02 412 (work in progress), February 2019. 414 [I-D.xie-bier-ipv6-encapsulation] 415 Xie, J., Geng, L., McBride, M., Asati, R., and S. 416 Dhanaraj, "Encapsulation for BIER in Non-MPLS IPv6 417 Networks", draft-xie-bier-ipv6-encapsulation-03 (work in 418 progress), July 2019. 420 Authors' Addresses 422 Haoyu Song (editor) 423 Futurewei Technologies 424 2330 Central Expressway 425 Santa Clara 426 USA 428 Email: hsong@futurewei.com 430 Mike McBride 431 Futurewei Technologies 432 2330 Central Expressway 433 Santa Clara 434 USA 436 Email: mmcbride@futurewei.com 438 Greg Mirsky 439 ZTE Corp. 441 Email: gregimirsky@gmail.com