idnits 2.17.1 draft-acg-mboned-multicast-models-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 6, 2016) is 2850 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-ietf-mboned-interdomain-peering-bcp-03 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mboned M. Abrahamsson 3 Internet-Draft T-Systems 4 Intended status: Informational T. Chown 5 Expires: January 7, 2017 Jisc 6 L. Giuliano 7 Juniper Networks, Inc. 8 July 6, 2016 10 Multicast Service Models 11 draft-acg-mboned-multicast-models-00 13 Abstract 15 The draft provides a high-level overview of multicast service and 16 deployment models, principally the Any-Source Multicast (ASM) and 17 Source-Specific Multicast (SSM) models, and aims to provoke 18 discussion of applicability of the models to certain scenarios. This 19 initial draft is by no means comprehensive. Comments on the initial 20 content, and what further content would be appropriate, or indeed 21 whether the draft is of value, are welcomed. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 7, 2017. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Multicast service models . . . . . . . . . . . . . . . . . . 3 59 3. Multicast building blocks . . . . . . . . . . . . . . . . . . 4 60 3.1. Multicast addressing . . . . . . . . . . . . . . . . . . 4 61 3.2. Host signalling . . . . . . . . . . . . . . . . . . . . . 4 62 3.3. Multicast snooping . . . . . . . . . . . . . . . . . . . 4 63 4. ASM service model protocols . . . . . . . . . . . . . . . . . 5 64 4.1. Protocol Independent Multicast, Dense Mode (PIM-DM) . . . 5 65 4.2. Protocol Independent Multicast, Sparse Mode (PIM-SM) . . 5 66 4.2.1. Inter-domain PIM-SM, and MSDP . . . . . . . . . . . . 5 67 4.3. Bidirectional PIM (BIDIR-PIM) . . . . . . . . . . . . . . 6 68 4.4. IPv6 PIM-SM with Embedded RP . . . . . . . . . . . . . . 6 69 5. SSM service model protocols . . . . . . . . . . . . . . . . . 6 70 5.1. Source Specific Multicast (PIM-SSM) . . . . . . . . . . . 6 71 6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 6.1. ASM Deployment . . . . . . . . . . . . . . . . . . . . . 7 73 6.2. SSM Deployment . . . . . . . . . . . . . . . . . . . . . 7 74 6.3. Other considerations . . . . . . . . . . . . . . . . . . 8 75 6.3.1. Scalability, and multicast domains . . . . . . . . . 9 76 6.3.2. Reliable multicast . . . . . . . . . . . . . . . . . 9 77 6.3.3. Inter-domain multicast peering . . . . . . . . . . . 9 78 6.3.4. Layer 2 multicast domains . . . . . . . . . . . . . . 9 79 6.3.5. Anything else? . . . . . . . . . . . . . . . . . . . 9 80 7. Use case examples . . . . . . . . . . . . . . . . . . . . . . 10 81 8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 83 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 84 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 85 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 86 12.1. Normative References . . . . . . . . . . . . . . . . . . 10 87 12.2. Informative References . . . . . . . . . . . . . . . . . 12 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 90 1. Introduction 92 IP Multicast has been deployed in various forms, both within private 93 networks and on the wider Internet. While a number of service models 94 have been published individually, and in many cases revised over 95 time, there is, we believe, no high-level guidance in the form of an 96 Informational RFC documenting the models, their advantages and 97 disadvantages, and their appropriateness to certain scenarios. This 98 document aims to fill that gap. 100 This initial version of the document is not complete. There are 101 other topics that can be included. The aim of this initial version 102 is to determine whether this work is deemed of value within the IETF 103 mboned WG. 105 2. Multicast service models 107 The general IP multicast service model [RFC1112] is that senders send 108 to a multicast IP address, receivers express an interest in traffic 109 sent to a given multicast address, and that routers figure out how to 110 deliver traffic from the senders to the receivers. 112 The benefit of IP multicast is that it enables delivery of content 113 such that any multicast packet sent from a source to a given 114 multicast group address appears once and only once on any path 115 between a sender and an interested receiver that has joined that 116 multicast group. A reserved range of addresses (for either IPv4 or 117 IPv6) is used for multicast group communication. 119 Two high-level flavours of this service model have evolved over time. 120 In Any-Source Multicast (ASM), any number of sources may transmit 121 multicast packets, and those sources may come and go over the course 122 of a multicast session without being known a priori. In ASM, 123 receivers express interest in a given multicast group address. In 124 Source-Specific Multicast (SSM) the specific source(s) that may send 125 traffic to the group are known in advance. In SSM, receivers express 126 interest in a given multicast address and specific source(s). 128 Senders transmit multicast packets without knowing where receivers 129 are, or how many there are. Receivers are able to signal to on-link 130 routers their desire to receive multicast content sent to a given 131 multicast group, and in the case of SSM from specific sender IP 132 addresses. They may discover the group (and sender IP) information 133 in a number of different ways. They may also signal their desire to 134 no longer receive multicast traffic for a given group (and sender 135 IP). 137 Multicast routing protocols are used to establish the multicast 138 forwarding paths (tree) between a sender and a set of receivers. 139 Each router would typically maintain multicast forwarding state for a 140 given group (and potentially sender IP), such that it knows which 141 interfaces to forward (and where necessary replicate) multicast 142 packets to. 144 Multicast packet forwarding is generally not considered a reliable 145 service. It is typically unidirectional, but a bidirectional 146 multicast delivery mechanism also exists. 148 3. Multicast building blocks 150 In this section we describe general multicast building blocks that 151 are applicable to both ASM and SSM deployment. 153 3.1. Multicast addressing 155 IANA has reserved specific ranges of IPv4 and IPv6 address space for 156 multicast addressing. 158 Guidelines for IPv4 multicast address assignments can be found in 159 [RFC5771]. IPv4 has no explicit multicast address format; a specific 160 portion of the overall IPv4 address space is reserved for multicast 161 use (224.0.0.0/4). 163 Guidelines for IPv6 multicast address assignments can be found in 164 [RFC2375] and [RFC3307]. The IPv6 multicast address format is 165 described in [RFC4291]. An IPv6 multicast group address will lie 166 within ff00::/8. 168 3.2. Host signalling 170 A host wishing to signal interest in receiving (or no longer 171 receiving) multicast to a given multicast group (and potentially from 172 a specific sender IP) may do so by sending a packet using one of the 173 protocols described below on an appropriate interface. 175 For IPv4, a host may use Internet Group Management Protocol Version 2 176 (IGMPv2) [RFC2236] to signal interest in a given group. IGMPv3 177 [RFC3376] has the added capability of specifying interest in 178 receiving multicast packets from specific sources. 180 For IPv6, a host may use Multicast Listener Discovery Protocol (MLD) 181 [RFC2710] to signal interest in a given group. MLDv2 [RFC3810] has 182 the added capability of specifying interest in receiving multicast 183 packets from specific sources. 185 Further guidance on IGMPv3 and MLDv2 is given in [RFC4604]. 187 3.3. Multicast snooping 189 Is this appropriate in this document? There is discussion in 190 [RFC4541]. 192 4. ASM service model protocols 194 4.1. Protocol Independent Multicast, Dense Mode (PIM-DM) 196 PIM-DM is detailed in [RFC3973]. It operates by flooding multicast 197 messages to all routers within the network in which it is configured. 198 This ensures multicast data packets reach all interested receivers 199 behind edge routers. Prune messages are used by routers to tell 200 upstream routers to (temporarily) stop forwarding multicast for 201 groups for which they have no known receivers. 203 PIM-DM remains an Experimental protocol since its publication in 204 2005. 206 4.2. Protocol Independent Multicast, Sparse Mode (PIM-SM) 208 The most recent revision of PIM-SM is detailed in [RFC7761]. PIM-SM 209 is, as the name suggests, well-suited to scenarios where the subnets 210 with receivers are sparsely distributed throughout the network. PIM- 211 SM supports any number of senders for a given multicast group, which 212 do not need to be known in advance, and which may come and go through 213 the session. PIM-SM does not use a flooding phase, making it more 214 scalable and efficient than PIM-DM, but this means PIM-SM needs a 215 mechanism to construct the multicast forwarding tree (and associated 216 forwarding tables in the routers) without flooding the network. 218 To achieve this, PIM-SM introduces the concept of a Rendezvous Point 219 (RP) for a PIM domain. All routers in a PIM-SM domain are then 220 configured to use specific RP(s). Such configuration may be 221 performed by a variety of methods, including Anycast-RP [RFC4610]. 223 A sending host's Designated Router encapsulates multicast packets to 224 the RP, and a receiving host's Designated Router can forward PIM JOIN 225 messages to the RP, in so doing forming what is known as the 226 Rendezvous Point Tree (RPT). Optimisation of the tree may then 227 happen once the receiving host's router is aware of the sender's IP, 228 and a source-specific JOIN message may be sent towards it, in so 229 doing forming the Shortest Path Tree (SPT). Unnecessary RPT paths 230 are removed after the SPT is established. 232 4.2.1. Inter-domain PIM-SM, and MSDP 234 PIM-SM can in principle operate over any network in which the 235 cooperating routers are configured with RPs. But in general, PIM-SM 236 for a given domain will use an RP configured for that domain. There 237 is thus a challenge in enabling PIM-SM to work between multiple 238 domains, i.e. to allow an RP in one domain to learn the existence of 239 a source in another domain, such that a receiver's router in one 240 domain can know to forward a PIM JOIN towards a source's Designated 241 Router in another domain. The solution to this problem is to use an 242 inter-RP signalling protocol known as Multicast Source Discovery 243 Protocol (MSDP). [RFC3618]. 245 Deployment scenarios for MSDP are given in [RFC4611]. MSDP remains 246 an Experimental protocol since its publication in 2003. MSDP was not 247 replicated for IPv6. 249 4.3. Bidirectional PIM (BIDIR-PIM) 251 BIDIR-PIM is detailed in [RFC5015]. In contrast to PIM-SM, it can 252 establish bi-directional multicast forwarding trees between multicast 253 sources and receivers. 255 Add more... 257 4.4. IPv6 PIM-SM with Embedded RP 259 Within a single PIM domain, PIM-SM for IPv6 works largely the same as 260 it does for IPv4. However, the size of the IPv6 address (128 bits) 261 allows a different mechanism for multicast routers to determine the 262 RP for a given multicast group address. Embedded-RP [RFC3956] 263 specifies a method to embed the unicast RP IP address in an IPv6 264 multicast group address, allowing routers supporting the protocol to 265 determine the RP for the group without any prior configuration. 267 Embedded-RP allows PIM-SM operation across any network in which there 268 is an end-to-end path of routers supporting the protocol. By 269 embedding the RP address in this way, multicast for a given group can 270 operate inter-domain without the need for an explicit source 271 discovery protocol (i.e. without MSDP for IPv6). It would be 272 desirable that the RP would be located close to the sender(s) in the 273 group. 275 5. SSM service model protocols 277 5.1. Source Specific Multicast (PIM-SSM) 279 PIM-SSM is detailed in [RFC4607]. In contrast to PIM-SM, PIM-SSM 280 benefits from assuming that source(s) are known about in advance, 281 i.e. the source IP address is known (by some out of band mechanism), 282 and thus the receiver's router can send a PIM JOIN directly towards 283 the sender, without needing to use an RP. 285 IPv4 addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are 286 designated as source-specific multicast (SSM) destination addresses 287 and are reserved for use by source-specific applications and 288 protocols. For IPv6, the address prefix FF3x::/32 is reserved for 289 source-specific multicast use. 291 6. Discussion 293 In this section we discuss the applicability of the ASM and SSM 294 models described above, and their associated protocols, to a range of 295 deployment scenarios. The context is framed in a campus / enterprise 296 environment, but the draft could broaden its scope to other 297 environments (thoughts?). 299 6.1. ASM Deployment 301 PIM-DM remains an Experimental protocol, that appears to be rarely 302 used in campus or enterprise environments. Open question: what are 303 the use cases for PIM-DM today? 305 In campus scenarios, PIM-SM is in common use. The configuration and 306 management of an RP is not onerous. However, if interworking with 307 external PIM domains in IPv4 multicast deployments is needed, MSDP is 308 required to exchange information between domain RPs about sources. 309 MSDP remains an Experimental protocol, and can be a complex and 310 fragile protocol to administer and troubleshoot. MSDP is also 311 specific to IPv4; it was not carried forward to IPv6. 313 PIM-SM is a general purpose protocol that can handle all use cases. 314 In particular, it is well-suited to cases where one or more sources 315 may came and go during a multicast session. For cases where a 316 single, persistent source is used, PIM-SM has unnecessary complexity. 318 As stated above, MSDP was not taken forward to IPv6. Instead, IPv6 319 has Embedded-RP, which allows the RP address for a multicast group to 320 be embedded in the group address, making RP discovery automatic, if 321 all routers on the path between a receiver and a sender support the 322 protocol. Embedded-RP is well-suited for lightweight ad-hoc 323 deployments. However, it does rely on a single RP for an entire 324 group. Embedded-RP was run successfully between European and US 325 academic networks during the 6NET project in 2004/05. Its usage 326 generally remains constrained to academic networks. 328 BIDIR-PIM is designed, as the name suggests, for bidirectional use 329 cases. 331 6.2. SSM Deployment 333 As stated in RFC4607, SSM is particularly well-suited to 334 dissemination-style applications with one or more senders whose 335 identities are known (by some mechanism) before the application 336 begins. PIM-SSM is therefore very well-suited to applications such 337 as IP TV. 339 Some benefits of PIM-SSM are presented in RFC 4607: 341 "Elimination of cross-delivery of traffic when two sources 342 simultaneously use the same source-specific destination address; 344 Avoidance of the need for inter-host coordination when choosing 345 source-specific addresses, as a consequence of the above; 347 Avoidance of many of the router protocols and algorithms that are 348 needed to provide the ASM service model." 350 A significant benefit of SSM is its reduced complexity through 351 eliminating network-based source discovery. This means no RPs, 352 shared trees, SPT switchover, PIM registers, MSDP or data-driven 353 state creation. It is really just a small subset of PIM-SM, plus 354 IGMPv3. This makes it radically simpler to manage, troubleshoot and 355 operate. 357 SSM is considered more secure in that it supports access control, 358 i.e. you only get packets from the sources you explicitly ask for, as 359 opposed to ASM where anyone can decide to send traffic to a PIM-SM 360 group address. 362 It is often thought that ASM is required for multicast applications 363 where there are multiple sources. However, RFC4607 also describes 364 how SSM can be used instead of PIM-SM for multi-party applications: 366 "SSM can be used to build multi-source applications where all 367 participants' identities are not known in advance, but the multi- 368 source "rendezvous" functionality does not occur in the network 369 layer in this case. Just like in an application that uses unicast 370 as the underlying transport, this functionality can be implemented 371 by the application or by an application-layer library." 373 A disadvantage of SSM is that it requires hosts using SSM and (edge) 374 routers with SSM receivers to support the new(er) IGMPv3 and MLDv2 375 protocols. The slow delivery of support in some OSes has meant that 376 adoption of SSM has also been slower than might have been expected, 377 or hoped. 379 6.3. Other considerations 380 6.3.1. Scalability, and multicast domains 382 One of the challenges in wider-scale multicast deployment is its 383 scalability, if it is expected that multicast-enabled routers are 384 required to hold state for large numbers of multicast sources/groups. 386 In practice, the number of groups a given router needs to hold state 387 for is limited by the propagation of the multicast messages for any 388 given group, e.g. because only a specific connected set of routers 389 are multicast-enabled, or because multicast scope borders have been 390 configured between multicast-enabled routers for access control 391 purposes. Further, protocol policy/filters are typically used to 392 limit state, as well as access control. 394 IPv4 multicast has no explicit indication of scope boundaries within 395 its multicast address format. The prefix 239.0.0.0/8 is reserved for 396 private use within a network, as per [RFC2365], and is believed to be 397 in common usage. Other scopes within this range are defined, e.g. 398 Organizational Local Scope, but whether this is in common use is 399 unclear. 401 In contrast, IPv6 has specific flag bits reserved to indicate the 402 scope of an address, e.g. link (0x2), site (0x5), organisation (0x8) 403 or global (0xe), as described in [RFC7346]. Such explicit scoping 404 makes configuration of scope boundaries a simpler, cleaner process. 406 6.3.2. Reliable multicast 408 Do we want to go here, and if so which protocols should we mention? 409 FLUTE [RFC6726] might be one example. 411 6.3.3. Inter-domain multicast peering 413 Interdomain peering best practices are documented in 414 [I-D.ietf-mboned-interdomain-peering-bcp]. 416 6.3.4. Layer 2 multicast domains 418 Open question - do we want to look at L2 models, e.g. as might be 419 applied at an IXP? 421 6.3.5. Anything else? 423 Anything else to add here? 425 7. Use case examples 427 Aim to add 2-3 deployment examples here, if deemed useful. Perhaps 428 one PIM-SM/MSDP/Anycast-RP, one Embedded-RP, one SSM? 430 8. Conclusions 432 Do we wish to make a very strong recommendation here for the SSM 433 service model, and thus for PIM-SSM, even in multi-source 434 applications? 436 Is this document Informational or BCP? Currently assumed 437 Informational. 439 9. Security Considerations 441 Do we need general text on multicast security here, or not? 443 10. IANA Considerations 445 This document currently makes no request of IANA. 447 Note to RFC Editor: this section may be removed upon publication as 448 an RFC. 450 11. Acknowledgments 452 TBC if draft progresses... 454 12. References 456 12.1. Normative References 458 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 459 RFC 1112, DOI 10.17487/RFC1112, August 1989, 460 . 462 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 463 2", RFC 2236, DOI 10.17487/RFC2236, November 1997, 464 . 466 [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, 467 RFC 2365, DOI 10.17487/RFC2365, July 1998, 468 . 470 [RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address 471 Assignments", RFC 2375, DOI 10.17487/RFC2375, July 1998, 472 . 474 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 475 Listener Discovery (MLD) for IPv6", RFC 2710, 476 DOI 10.17487/RFC2710, October 1999, 477 . 479 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 480 Addresses", RFC 3307, DOI 10.17487/RFC3307, August 2002, 481 . 483 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 484 Thyagarajan, "Internet Group Management Protocol, Version 485 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 486 . 488 [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source 489 Discovery Protocol (MSDP)", RFC 3618, 490 DOI 10.17487/RFC3618, October 2003, 491 . 493 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 494 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 495 DOI 10.17487/RFC3810, June 2004, 496 . 498 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 499 Point (RP) Address in an IPv6 Multicast Address", 500 RFC 3956, DOI 10.17487/RFC3956, November 2004, 501 . 503 [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol 504 Independent Multicast - Dense Mode (PIM-DM): Protocol 505 Specification (Revised)", RFC 3973, DOI 10.17487/RFC3973, 506 January 2005, . 508 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 509 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 510 2006, . 512 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 513 IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, 514 . 516 [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol 517 Independent Multicast (PIM)", RFC 4610, 518 DOI 10.17487/RFC4610, August 2006, 519 . 521 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 522 "Bidirectional Protocol Independent Multicast (BIDIR- 523 PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, 524 . 526 [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for 527 IPv4 Multicast Address Assignments", BCP 51, RFC 5771, 528 DOI 10.17487/RFC5771, March 2010, 529 . 531 [RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, 532 "FLUTE - File Delivery over Unidirectional Transport", 533 RFC 6726, DOI 10.17487/RFC6726, November 2012, 534 . 536 [RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346, 537 DOI 10.17487/RFC7346, August 2014, 538 . 540 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 541 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 542 Multicast - Sparse Mode (PIM-SM): Protocol Specification 543 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 544 2016, . 546 12.2. Informative References 548 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 549 "Considerations for Internet Group Management Protocol 550 (IGMP) and Multicast Listener Discovery (MLD) Snooping 551 Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, 552 . 554 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 555 Group Management Protocol Version 3 (IGMPv3) and Multicast 556 Listener Discovery Protocol Version 2 (MLDv2) for Source- 557 Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, 558 August 2006, . 560 [RFC4611] McBride, M., Meylor, J., and D. Meyer, "Multicast Source 561 Discovery Protocol (MSDP) Deployment Scenarios", BCP 121, 562 RFC 4611, DOI 10.17487/RFC4611, August 2006, 563 . 565 [I-D.ietf-mboned-interdomain-peering-bcp] 566 Tarapore, P., Sayko, R., Shepherd, G., Eckert, T., and R. 567 Krishnan, "Use of Multicast Across Inter-Domain Peering 568 Points", draft-ietf-mboned-interdomain-peering-bcp-03 569 (work in progress), May 2016. 571 Authors' Addresses 573 Mikael Abrahamsson 574 T-Systems 575 Stockholm 576 Sweden 578 Email: mikael.abrahamsson@t-systems.se 580 Tim Chown 581 Jisc 582 Lumen House, Library Avenue 583 Harwell Oxford, Didcot OX11 0SG 584 United Kingdom 586 Email: tim.chown@jisc.ac.uk 588 Lenny Giuliano 589 Juniper Networks, Inc. 590 2251 Corporate Park Drive 591 Hemdon, Virginia 20171 592 United States 594 Email: lenny@juniper.net