idnits 2.17.1 draft-shepherd-bier-problem-statement-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 : ---------------------------------------------------------------------------- No issues found here. 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 (February 6, 2015) is 3338 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1058' is defined on line 501, but no explicit reference was found in the text == Unused Reference: 'RFC1075' is defined on line 504, but no explicit reference was found in the text == Unused Reference: 'RFC1112' is defined on line 508, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 511, but no explicit reference was found in the text == Unused Reference: 'RFC2784' is defined on line 514, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 518, but no explicit reference was found in the text == Unused Reference: 'RFC3810' is defined on line 529, but no explicit reference was found in the text == Unused Reference: 'RFC3973' is defined on line 532, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 536, but no explicit reference was found in the text == Unused Reference: 'RFC6513' is defined on line 550, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 966 (Obsoleted by RFC 988) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 12 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force G. Shepherd 2 Internet-Draft Cisco 3 Intended status: Informational A. Dolganow 4 Expires: August 10, 2015 Alcatel-Lucent 5 A. Gulko 6 Thomson Reuters 7 February 6, 2015 9 Bit Indexed Explicit Replication (BIER) Problem Statement 10 draft-shepherd-bier-problem-statement-02 12 Abstract 14 There is a need to simplify network operations for multicast 15 services. Current solutions require a tree-building control plane to 16 build and maintain end-to-end tree state per flow, impacting router 17 state capacity and network convergence times. Multi-point tree 18 building protocols are often considered complex to deploy and debug 19 and may include mechanics from legacy use-cases and/or assumptions 20 which no longer apply to the current use-cases. When multicast 21 services are transiting a provider network through an overlay, the 22 core network has a choice to either aggregate customer state into a 23 minimum set of core states resulting in flooding traffic to unwanted 24 network end-points, or to map per-customer, per-flow tree state 25 directly into the provider core state amplifying the network-wide 26 state problem. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 10, 2015. 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 64 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Deering's Multicast Model . . . . . . . . . . . . . . . . . . 5 66 4. Network Based Source Discovery . . . . . . . . . . . . . . . 7 67 5. Receiver Driven State . . . . . . . . . . . . . . . . . . . . 8 68 6. Multicast Virtual Private Networks . . . . . . . . . . . . . 9 69 7. Overlay . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 75 11.2. Informative References . . . . . . . . . . . . . . . . . 11 76 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 12 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Introduction 81 There is a need to simplify network operations for multicast 82 services. Current solutions require a tree-building control plane, 83 to build and maintain end-to-end tree state per flow, impacting 84 router state capacity and network convergence times. Multi-point 85 tree building protocols are often considered complex to deploy and 86 debug and include mechanics from legacy use-cases and/or assumptions 87 which may no longer apply to the current use-case. When multicast 88 services are transiting a provider network through an overlay, the 89 core network has a choice to either aggregate customer state into a 90 minimum set of core states resulting in flooding traffic to unwanted 91 network end-points, or to map per-customer, per-flow tree state 92 directly into the provider core state amplifying the network-wide 93 state problem. 95 This document attempts to discuss the uses, benefits and challenges 96 of the current multicast solutions and to put them in an historical 97 context to better understand why we are where we are today, and to 98 provide a framework for discussion around new solutions that may 99 address our current requirements and challenges. 101 1.1. Requirements Language 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC 2119 [RFC2119]. 107 2. Objectives 109 IP Multicast services have been widely adopted in networks where the 110 benefits of efficient, concurrent delivery of content to a 111 sufficiently large set of receivers outweighs the complexity and 112 challenges of deploying and managing the current set of multicast 113 protocols. These deployments are primarily dedicated multicast 114 islands with very little cross-domain inter-networking, and fall 115 short of the early dreams of a multicast enabled Internet. 117 Multicast began with a large set of requirements shoehorned into a 118 single, complex protocol. Over time, multicast protocols essentially 119 devolved into a set of more simple components to overcome the 120 original complexity, and to address a growing set of use cases. Many 121 of the early complexity can be avoided today by correctly selecting 122 your service model and protocols. But the standard set of protocols 123 available can still be considered overloaded for various reasons. 125 The current problems associated with the today's multicast solutions 126 can be stated as follows: 128 - Current multicast methods all require explicit tree building 129 protocols, thereby incurring a lot of state in the transit nodes. 131 - Receiver driven tree state uses Reverse Path Forwarding (RPF) to 132 build the trees toward the root which often results in multicast 133 forwarding following different paths than unicast forwarding 134 between the same two endpoints. 136 - Multicast convergence times are negatively impacted by tree 137 state. Any network transition requires unicast to first converge. 138 Once unicast has converged multicast must then recalculate RPF for 139 every tree and rebuild the trees by sending join messages toward 140 the new RPF neighbor per tree. Joins toward a common RPF neighbor 141 can be aggregated but only up to the link MTU. In large multicast 142 deployments this can result in multicast convergence times of up 143 to a minute or more. In extreme cases the active state may time 144 out before all the new joins are sent and received resulting in 145 multicast to permanently fail after a network failure event even 146 though there is a restored path. This has put an upward bound on 147 the amount of state a multicast network can support. 149 - Current multicast methods, if they are to provide optimal 150 delivery of multicast packets, require one explicitly built tree 151 per multicast flow; there is no way to aggregate flows (having one 152 state for multiple flows) without sacrificing optimal delivery. 153 In the case of Multicast Virtual Private Network (MVPN) 154 deployments, the operator is forced to choose between unwanted 155 flooded traffic across an aggregate state entry and exposing 156 customer state in the core. 158 - Some multicast solutions include data-driven events. This has 159 required specialized capabilities to be integrated into routing 160 equipment to protect the control plane from the multicast data 161 plane increasing the cost of multicast support in routing 162 equipment. 164 - Maintaining and troubleshooting multicast networks can be very 165 difficult. The available solutions are so different than unicast, 166 often revealing unique corner cases that specialized training and 167 skills, and frequently dedicated staff are required just to 168 operate multicast services on a network. 170 - Current Multicast Virtual Private Networks [RFC6513](MVPN) 171 introduced Border Gateway Protocol[RFC4271](BGP) routes for 172 neighbour discovery and Protocol Independent Multicast[RFC4601] 173 (PIM) Join/Prune propagation. In some deployments when many 174 Multicast MVPNs with many Provider Edge (PE) routers exist in a 175 network and at least some of those MVPNs have a large number of 176 customer-multicast flows, the resulting tax on BGP may be deemed 177 undesired as millions of BGP routes can easily result from 178 multicast deployments. Therefore a solution that allows large 179 MVPN scale with large number of edge PEs and c-multicast flows per 180 MVPN is desired. 182 - With the introductions of Segment Routing, some networks may 183 elect to remove the Multiprotocol Lable Switching[RFC3031](MPLS) 184 control plane and rely on Interior Gateway Protocol-only or 185 Software Defined Networking-based Segment Routing. In such 186 networks the alternative to existing mechanisms is needed for 187 multicast. Removing the MPLS control plane for unicast makes 188 little sense unless the multicast control plane also gets 189 simplified. 191 - The benefits of multi-point services are well understood, but 192 the challenges with the current solutions often result in a failed 193 cost/benefit analysis. Today only those networks with an 194 overwhelming business need have successful multicast deployments, 195 and the rest of the community have come to think of multicast as a 196 failed technology. 198 How did we get here? What follows is a semi-chronological tour 199 through the devolution of multicast protocols, solutions, and use- 200 cases, describing why earlier complexities and challenges existed, 201 and how they were overcome. This may help frame future work to 202 overcome our current challenges. 204 3. Deering's Multicast Model 206 The original Multicast Extensions to the Internet Protocol [RFC0966] 207 and Host Extensions for IP Multicasting [RFC1112]were envisioned by 208 Stephen Deering as part of his graduate work at Stanford University. 209 The need for a multi-point service model was motivated by the advent 210 and deployment of layer3 network topologies breaking existing layer2 211 applications. The need arose to create an underlay service with the 212 characteristics of a broadcast domain to allow these layer2 213 applications to continue to function without modification across a 214 layer3 infrastructure. 216 Though the community quickly saw the value and envisioned many other 217 uses for a multi-point service model, a broadcast domain remained the 218 target model for the solution and the list of requirements focused 219 around those of a broadcast domain. For simplicity the rules of this 220 underlay broadcast domain can be summed up as follows: anyone can 221 send packets into the domain; all members will receive all packets 222 sent into the domain. In order for these layer2 applications to 223 function across this broadcast domain overlay, all of the functions 224 to provide this service were loaded onto network layer. 226 This new multi-point model was called Multicast. The first multicast 227 solution adopted by the IETF was Distance Vector Multicast Routing 228 Protocol [RFC1075](DVMRP). As the name implies, DVMRP uses a 229 distance-vector routing algorithm derived from Routing Information 230 Protocol [RFC1058](RIP) in combination with the Truncated Reverse 231 Path Broadcasting (TRPB) algorithm to build and maintain tree state 232 and forward multicast packets along these distribution trees. The 233 Internet Assigned Numbers Authority (IANA) was asked to reserve a 234 portion of the global IPv4 address space for multicast destination 235 addresses required by this model, and in response 224/4 was allocated 236 as the Class D address space for IP Multicast group addresses. 238 DVMRP has no concept of a "join" message. All new source packets for 239 any given group were simply flooded downstream--essentially 240 broadcasted--following the DVMRP topology. Each leaf of the tree was 241 responsible for sending Non Membership Reports (NMR--prunes) toward 242 the source if there were no downstream receivers for the group. This 243 mechanism came to be known as flood-and-prune, and is a very 244 primitive form of network-based source discovery that all the 245 contemporary applications came to depend on. These contemporary 246 applications were inherently many-to-many either by the nature of the 247 data distribution model, or at the least depended on the many-to-many 248 nature of the network-based-source discovery mechanism. 250 DVMRP also incorporated the IETF's first specification of an 251 encapsulated overlay. It was clear that this new model would not be 252 supported by every node in the path, and an encapsulation allowed 253 early adopters to build a global multi-point, or multicast capable 254 topology as an overlay. 256 For clarity of discussion, the functions of the Deering model can be 257 described as: 259 - Tree building and maintenance 261 - Network-based source discovery 263 - Source route information 265 - Overlay mechanism - tunneling 267 DVMRP was considered over-loaded in that it carries network source 268 routing information within the protocol in parallel to any existing 269 Interior Gateway Protocol (IGP) generated local routing table. The 270 next generation goal was to focus on the multi-point services needed 271 for the model but to use the local, native routing table as needed 272 for Reverse Path Check (RPF). From this came the advent of Protocol 273 Independent Multicast Sparse Mode [RFC4601](PIM-SM) and Protocol 274 Independent Multicast Dense Mode [RFC3973](PIM-DM). PIM removed any 275 embedded source routing function from the protocol, and instead 276 relied on the exiting routing table as generated from the deployed 277 IGP. PIM also removed any overlay functionality, but retained 278 network-based source discovery as a fundamental part of the protocol. 279 Oops. 281 4. Network Based Source Discovery 283 The Deering model introduced the concept of a Group address (G) 284 representing a single broadcast domain. Any source is allowed to 285 send to the group address and the multicast routing infrastructure 286 will build tree state from every source to all interested receivers. 287 All group members only need to signal their G membership to the 288 network and the network will ensure that all source traffic sending 289 to that same group address will arrive at all group members. The 290 network-based source discovery operation providing these functions 291 was intended to provide operational constancy with a layer2 broadcast 292 domain, but comes at significant cost. 294 Allowing any source to send to a group is an obvious security 295 vulnerability. Many implementations today provide various layers of 296 access control both at the edges and core of the network just to 297 overcome the security concerns for the basic operation of the 298 multicast network. 300 Network-based source discovery methods can be grouped into two types; 301 flood and prune (DVMRP, PIM-DM), or explicit join (PIM-SM). Both 302 methods depend on the arrival of data to trigger complex network 303 functions to build and maintain the per-source distribution of data 304 for every group. Multicast is often considered complex, fragile, and 305 difficult to troubleshoot, but it is most often the network-based 306 source discovery functions that are the cause of this reputation. 308 The majority of the use-cases for multicast today are for content 309 with well-know sources. The development of Internet Group Membership 310 Protocol [RFC3376] (IGMPv3) provided a mechanism for group members to 311 signal interest in a source and a group, eliminating the need for 312 network-based source discovery, and facilitating the advent of Source 313 Specific Multicast [RFC4607] (SSM). Many operators still ask how 314 potential SSM group members learn about the sources. The answer is 315 simply to use the same mechanism in which they learned about the 316 group - out-of-band. Source (and group) discovery mechanisms are 317 better served at the application layer for most use-cases. With SSM 318 multicast content can be forwarded and constrained to a single 319 source-rooted tree, or (S,G) channel which has several key benefits: 321 - Simplified configuration and operation 323 - Elimination of rouge sources 'stealing' receivers 325 - Elimination of rouge sources consuming network resources 327 - Elimination of group address resource restrictions 329 5. Receiver Driven State 331 Today's multicast solutions are primarily receiver driven. This is a 332 logical approach in that it is the receiver that decides if and when 333 to join or leave a group or channel. Receiver driven distribution 334 trees built hop-by-hop are an efficient way to dynamically build and 335 scale very large membership fanout. It can be argued that a receiver 336 driven tree's radius can scale infinitely without impact to any 337 upstream segment or node for that tree. But it does then require 338 forwarding state for each tree, or pre-flow state. 340 The joins propagate upstream from the receiver toward the source or 341 root of the tree, following the unicast routing table. But this 342 reverse path may differ from the optimal unicast forwarding path from 343 the source to the receiver. The result is multicast traffic 344 potentially taking a different forwarding path than unicast traffic 345 between the same to network endpoints. This can often complicate 346 network and traffic engineering. 348 Each of the existing multicast solutions today, native or overlay, 349 builds and maintains forwarding state per flow, or aggregates some 350 flows into a subset of flow-states. On the surface this may look 351 like an unbounded problem, but in actuality the flow state is only 352 present along the branches of the tree, and no one router needs to 353 maintain global tree state. Router state capacity is not infinite, 354 and this coupling of receiver actions to network state is a potential 355 Denial of Service (DoS) vector. Most implementations today have 356 provided filtering and state-limiting capabilities to secure the 357 multicast infrastructure from this vulnerability. 359 Increasing multicast forwarding state can also negatively impact 360 network convergence performance. Unicast is only concerned with 361 topology, and any topology changes can converge in a relatively 362 bounded amount of time. The same topology change requires the 363 multicast protocol to rebuild the forwarding state for every active 364 flow. The resulting multicast convergence times are directly 365 dependent on the amount of flow state affected by the convergence 366 event. In extreme cases, the sending, receiving, and processing of 367 the join state for all active flows can exceed the flow state timers 368 resulting in a race condition in which convergence never occurs. 369 Today's implementations have had to incorporate various proprietary 370 solutions to improve network convergence times in large flow-state 371 multicast deployments. 373 The pros and cons of receiver driven state are as follows: 375 Pros: 377 Infinitely scales distribution radius 379 Aligns with receiver driven join model 381 Cons: 383 Potential state DoS vector 385 Host driven network events 387 Unbounded per-flow state 389 Unicast/Multicast traffic divergence 391 Non-deterministic join latency 393 Convergence times increasing with flow-state 395 6. Multicast Virtual Private Networks 397 Multicast Virtual Private Networks [RFC6513](MVPN) are solutions 398 which allow a core network to transit edge network multicast flows 399 over a core transit network to and from only those MVPN member nodes, 400 without exposing the edge network addressing into the core network 401 forwarding state. The solutions attempt to minimize core state by 402 aggregating trees per-VRF/PE. But this aggregation has the side 403 affect of sending all multicast traffic from that VRF/PE to all other 404 VRF/PE members, whether or not they have down stream flow state. 406 Various optimizations are available to selectively de-aggregate flow 407 state to better constrain the traffic distribution to only those VRF/ 408 PEs with active state. This becomes a trade off between unwanted 409 traffic and an increase in core flow state. These solutions are 410 often data driven resulting in core router state being triggered by 411 date and receiver events. 413 In addition to a potential BGP route explosion due to an MVPN 414 deployment scale as discussed in section 2, another issue with MVPN 415 relates to architectures used when MVPN deployments require both 416 video-distribution-like model, well served by point-to-multipoint 417 (P2MP) connectivity, and many-to-many model requiring Multipoint-to- 418 multipoint (MP2MP) connectivity. Today, if both models are deployed 419 in a single network, either MP2MP or a mesh of P2MP trees needs to be 420 established, or dual P2MP/MP2MP mLDP architecture may be used, or 421 MP2MP mLDP can be used for both P2MP and MP2MP connectivity. None of 422 those models is optimal as each requires a trade-off between 423 supported protocols, optimal delivery, and operational complexity. 425 7. Overlay 427 Deering had the correct insight to assume not every node in a network 428 would be capable of natively transiting multicast flows. The 429 migration to PIM was an attempt to move to a completely native model, 430 which was the right direction. But in this move it also abandoned 431 any other solution for incorporating an underlay into the topology 432 for those portions of the network which for whatever reason do not 433 support native multicast. Early deployments of PIM often 434 incorporated static Generic Routing Encapsulation [RFC2784](GRE) 435 tunnels between PIM domains in an attempt to create an inter domain 436 multicast deployment. 438 Static tunneling has it's use cases and benefits, but it is not the 439 ideal tool to dynamically stitch together a large and topologically 440 diverse receiver population. A receiver driven distribution model 441 would be better served with a receiver driving overlay mechanism. 442 This would indicate that when overlay was removed from the tree 443 building protocol it should have migrated to IGMPv3 and Multicast 444 Listener Discovery [RFC3810](MLDv2), the membership protocol, but it 445 was seen as a necessary requirement at that time. To fill this 446 requirement today Automatic Multicast Tunnels (AMT) is being 447 progressed as the overlay standard for bridging multicast interested 448 receivers over unicast only intermediate networks. 450 8. Summary 452 Multicast began with a heavily overloaded protocol DVMRP, and has 453 evolved over time by removing functionality from this all-in-one 454 solution, and off-loading certain function to either more specialized 455 protocols or existing protocols and functions. Multicast has what 456 may be the unique distinction of starting very complex, but evolving 457 through more simple stages along the way. It may be time to consider 458 the next step in the evolution toward simplicity. 460 Today we depend on receiver driven joins propagating end-to-end from 461 receivers toward sources, and maintaining per-flow state in every 462 node along the path. This state crosses administrative domains. 463 Unicast has a simple model where local specificity stays local and 464 does not directly impact the global table. Multicast state has no 465 administrative boundaries today. It may be beneficial to consider 466 the autonomy of networks in the path, and their specific topology and 467 requirements. PIM successfully utilizes the available routing table 468 for RPF checks and joins. This route table may also be considered as 469 a source of topology information for a set of receiver nodes within a 470 given network. 472 9. IANA Considerations 474 This memo includes no request to IANA. 476 All drafts are required to have an IANA considerations section (see 477 Guidelines for Writing an IANA Considerations Section in RFCs 478 [RFC5226] for a guide). If the draft does not require IANA to do 479 anything, the section contains an explicit statement that this is the 480 case (as above). If there are no requirements for IANA, the section 481 will be removed during conversion into an RFC by the RFC Editor. 483 10. Security Considerations 485 All drafts are required to have a security considerations section. 486 See RFC 3552 [RFC3552] for a guide. 488 11. References 490 11.1. Normative References 492 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 493 Requirement Levels", BCP 14, RFC 2119, March 1997. 495 11.2. Informative References 497 [RFC0966] Deering, S. and D. Cheriton, "Host groups: A multicast 498 extension to the Internet Protocol", RFC 966, December 499 1985. 501 [RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, 502 June 1988. 504 [RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance 505 Vector Multicast Routing Protocol", RFC 1075, November 506 1988. 508 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 509 RFC 1112, August 1989. 511 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 512 June 1999. 514 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 515 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 516 March 2000. 518 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 519 Label Switching Architecture", RFC 3031, January 2001. 521 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 522 Thyagarajan, "Internet Group Management Protocol, Version 523 3", RFC 3376, October 2002. 525 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 526 Text on Security Considerations", BCP 72, RFC 3552, July 527 2003. 529 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 530 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 532 [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol 533 Independent Multicast - Dense Mode (PIM-DM): Protocol 534 Specification (Revised)", RFC 3973, January 2005. 536 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 537 Protocol 4 (BGP-4)", RFC 4271, January 2006. 539 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 540 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 541 Protocol Specification (Revised)", RFC 4601, August 2006. 543 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 544 IP", RFC 4607, August 2006. 546 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 547 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 548 May 2008. 550 [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 551 VPNs", RFC 6513, February 2012. 553 Appendix A. Additional Stuff 555 This becomes an Appendix. 557 Authors' Addresses 559 Greg Shepherd (editor) 560 Cisco 561 170 W. Tasman Dr. 562 San Jose 563 US 565 Email: gjshep@gmail.com 566 Andrew Dolganow (editor) 567 Alcatel-Lucent 568 600 March Rd. 569 Ottawa, Ontario K2K 2E6 570 Canada 572 Email: andrew.dolganow@alcatel-lucent.com 574 Arkadiy Gulko (editor) 575 Thomson Reuters 577 Email: arkadiy.gulko@thomsonreuters.com