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