idnits 2.17.1 draft-wijnands-bier-mld-lan-election-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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 8, 2016) is 2847 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-08) exists of draft-ietf-bier-architecture-02 == Outdated reference: A later version (-03) exists of draft-pfister-bier-mld-00 ** Downref: Normative reference to an Informational RFC: RFC 2291 ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BIER Working Group IJ. Wijnands 3 Internet-Draft P. Pfister 4 Intended status: Standards Track Cisco Systems 5 Expires: January 9, 2017 J. Zhang 6 Juniper Networks 7 July 8, 2016 9 Generic Multicast Router Election on LAN's 10 draft-wijnands-bier-mld-lan-election-01.txt 12 Abstract 14 When a host is connected to multiple multicast capable routers, each 15 of these routers is a candidate to process the multicast flow for 16 that LAN, but only one router should be elected to process it. This 17 document proposes a generic multicast router election mechanism using 18 Internet Group Management Protocol (IGMP) and Multicast Listener 19 Discovery (MLD) that can be used by any Multicast Overlay Signalling 20 Protocol (MOSP). Having such generic election mechanism removes a 21 dependency on Protocol Independent Multicast (PIM). 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 9, 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. Terminology and Definitions . . . . . . . . . . . . . . . . . 3 59 3. Specification of Requirements . . . . . . . . . . . . . . . . 4 60 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 61 4.1. Receiver side . . . . . . . . . . . . . . . . . . . . . . 4 62 4.2. Sender side . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 6. DF Election Mechanism Requirements . . . . . . . . . . . . . 7 65 7. The DF Election mechanism . . . . . . . . . . . . . . . . . . 8 66 7.1. Highest Random Weight . . . . . . . . . . . . . . . . . . 8 67 7.2. The DF Hello Message . . . . . . . . . . . . . . . . . . 8 68 7.3. The Designated Announcer . . . . . . . . . . . . . . . . 9 69 7.3.1. DAL Hello Option . . . . . . . . . . . . . . . . . . 9 70 7.3.2. A new Candidate DF . . . . . . . . . . . . . . . . . 9 71 7.3.3. A candidate DF goes down . . . . . . . . . . . . . . 10 72 7.4. DA Inconsistency . . . . . . . . . . . . . . . . . . . . 11 73 8. The Hello Message Packet Format . . . . . . . . . . . . . . . 11 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 75 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 76 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 77 12. Normative References . . . . . . . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 80 1. Introduction 82 Hosts connected to Local Area Networks (LAN) use Internet Group 83 Management Protocol (IGMP) [RFC4605] or Multicast Listener Discovery 84 (MLD) [RFC3810] to report their interest in a particular multicast 85 flow. A multicast flow is identified by a Group or a combination of 86 Group and Source address. Routers connected to a LAN listen to these 87 membership reports and signal that information to the Multicast 88 Overlay Signalling Protocol (MOSP). When a host is connected to 89 multiple routers, each of these routers is a candidate to forward the 90 multicast flow onto that LAN, but only one of them should forward the 91 packets for a given flow to avoid duplication of Multicast packets. 92 A similar requirement exists for hosts that are sending multicast 93 traffic and are connected to multiple routers on a LAN. If multiple 94 routers accept the multicast packets from the LAN, duplication may 95 occur and/or routing loops may be created. 97 Protocol Independent Multicast (PIM) [RFC4601] is a MOSP and has a 98 built-in mechanism to elect a Designated Router (DR) on the receiver 99 LAN and a Designated Forwarder (DF) on the senders LAN. The DR/DF 100 election avoids duplication and looping of multicast packets. Other 101 existing or candidate MOSPs, like Border Gateway Protocol (BGP) 102 [RFC6514], Multi-point Label Distribution Protocols (mLDP) [RFC6826], 103 Locator ID Seperation Protocol (LISP) [RFC6830] and IGMP/MLD 104 [I-D.pfister-bier-mld] have no embedded LAN DR/DF election mechanism. 105 These MOSPs still rely on PIM to perform DR/DF election on LANs. 107 With the introduction of mLDP and Bit Indexed Explicit Replication 108 (BIER) [I-D.ietf-bier-architecture], there is no dependency on PIM to 109 transport multicast packets through the network. Having a dependency 110 on PIM just for DR/DF election is undesirable if PIM is not selected 111 as the MOSP. This document proposes a generic DR/DF election which 112 can be used by any MOSP without having a dependency on PIM. It 113 potentially allows for different MOSPs to coexistence on single LANs. 115 2. Terminology and Definitions 117 Readers of this document are assumed to be familiar with the 118 terminology and concepts of the documents listed as Normative 119 References. For convenience, some of the more frequently used terms 120 appear below. 122 LAN: 123 Local Area Network. 125 IGMP: 126 Internet Group Management Protocol. 128 MLD: 129 Multicast Listener Discovery. 131 mLDP: 132 Multipoint LDP. 134 PIM: 135 Protocol Independent Multicast. 137 ASM: 138 Any Source Multicast. 140 RP: 141 The PIM Rendezvous Point. 143 LISP: 144 Locator ID Seperation Protocol. 146 BIER: 147 Bit Indexed Explicit Replication. 149 MOSP: 150 Multicast Overlay Signalling Protocol. This is a protocol that is 151 (potentially) capable of announcing multicast flow membership 152 across the network between multicast routers. For example PIM, 153 mLDP, BGP, IGMP, MLD and LISP. 155 DF: 156 A Designated Forwarder is responsible for accepting a multicast 157 packet from a LAN. 159 DR: 160 A Designated Router is responsible for forwarding a multicast 161 packet onto a LAN. 163 DA: 164 A Designated Announcer is a router that is responsible for 165 announcing a list of candidate Designated Forwarders. 167 DAL: 168 A Designated Announcer List is generated by the DA and holds the 169 candidate Designated Forwarders. 171 3. Specification of Requirements 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in [RFC2119]. 177 4. Problem Statement 179 In the following sections we describe the requirements for DR/DF 180 election in more detail for hosts that are multicast senders and 181 receivers connected to multiple routers on a single LAN. 183 4.1. Receiver side 185 Consider the network below in Topology1. 187 +---- MOSP ----+ 188 LAN2 189 ( R3 ) -| 190 LAN1 / | 191 S H1-|-( R1 )--( R2 ) |- H2 (joined G) 192 \ | 193 ( R4 ) -| 195 Figure 1 197 Suppose that H2 on LAN2 is joining a multicast Group G. The MOSP 198 runs between R1, R3 and R4. Both R3 and R4 will receive the IGMP/MLD 199 report, but only one of these should become the DR. One might 200 consider that this problem can be detected and resolved by the MOSP. 201 The MOSP could be enhanced to allow R1 to detect that both R2 and R4 202 are connected to the same LAN, and select only to forward the 203 multicast flow to R3. That would solve the problem in the above 204 topology, but would fail in the topology below: 206 +---- MOSP ----+ 207 LAN2 208 ( R3 ) -| 209 LAN1 / | 210 S H1-|-( R1 )--( R2 ) |- H2 (joined G) 211 \ | 212 ( R4 ) -| 213 | 214 - LAN3 215 | 216 H3 (joined G) 218 Figure 2 220 Consider that H3 on LAN3 joined the same multicast Group G. Since H3 221 is singly connected to R4, router R1 needs to forward the multicast 222 flow to R4 in order for H3 to receive the packets. R4 does not have 223 enough information to determine whether or not to forward on LAN2 for 224 H2 when it receives the multicast packets due to H3. In other words, 225 R4 needs DR state to avoid sending packets to H2 on LAN2. 227 4.2. Sender side 229 Consider the network below in Topology3. 231 +---- MOSP ----+ 232 LAN1 233 |- ( R1 ) 234 | \ LAN2 235 S H1 -| ( R3 ) -- ( R4 ) -|- H2 (joined G) 236 | / 237 |- ( R2 ) 239 Figure 3 241 H1 is directly connected via a LAN1 to R1 and R2. H2 joins a 242 multicast Group G, without specifying the Source. This is called Any 243 Source Multicast (ASM). The MOSP signals R4s interest in Group G to 244 R1 and R2. Note that there is no PIM deployed in this network and 245 there is no Rendezvous Point (RP) that is a target for this receiving 246 this Group membership. R4 has no information which routers in this 247 network have multicast packets to sent for this Group. Since this is 248 ASM, there may be multiple senders for this Group and H2 wants to 249 receive them all. For that reason, R4 will use the MOSP to announce 250 the membership to all edge nodes in the network (R1 and R2). This 251 poses a potential problem since R1 and R2 are both directly connected 252 to the Source S. If both R1 and R2 will forward the multicast 253 packets to R4, H2 will receive duplicate packets. This is a problem 254 that only occurs when a Source is dually connected to two or more 255 routers connected to the sam LAN. This problem can be resolved by 256 doing a Designated Forwarder (DF) election, similar to the DR 257 election. If R1 and R2 are aware they are directly connected, an 258 election will cause only one of them to forward the multicast packets 259 into the network for a given (S,G) flow. 261 5. Proposal 263 As explain in Section 4, it is desirable to have a generic DR/DF 264 election mechanism that can be used by existing and candidate MOSPs. 265 Also, if a mix of MOSPs is used in the network, it is not obvious 266 which MOSP is responsible for electing the DR/DF. If a single DR/DF 267 is to be elected, and each MOSP does its own election, the MOSPs have 268 to negotiate among each other who will be responsible for DR/DF on a 269 LAN. Independent of the MOSP, a single router connected to the LAN 270 should be elected. It seems inefficient and unpractical to have each 271 MOSP implement its own DR/DF election mechanism. 273 There is a process in the router that all the MOSPs depend on for 274 Group membership discovery, that is the IGMP/MLD process. The DR/DF 275 election is typically based on the Group address or Group and Source 276 address of the multicast flow. This information is available in the 277 IGMP/MLD process. In this document we propose to enhance the IGMP/ 278 MLD protocol to allow a DR/DF election among multicast routers 279 connected to a LAN. As soon as a router is elected as DR/DF, it can 280 select the MOSP that will be responsible to deliver the multicast 281 flow to this router, and onwards onto the LAN(s). 283 IGMP/MLD has support for electing a Membership Querier based on the 284 lowest IP address of the multicast routers sending out Membership 285 Queries. It would be possible to use the elected Membership Querier 286 as the DR/DF on a LAN. However, the authors believe that the 287 Membership Querier procedures are not robust and extensible enough to 288 be used DR/DF for election on LANs. For example, if a new multicast 289 router becomes active on a LAN, it will immediately assume the role 290 of a Membership Querier, which can lead to duplication and/or looping 291 of packets if also used as DR/DF. This duplication/looping will last 292 until it learns about other Membership queriers with a lower IP 293 address. Having two Membership queriers on the LAN has limited 294 impact on the IGMP/MLD protocol it self, it would only cause more 295 Membership Reports to be received. 297 The election mechanism for the DR and the DF is very similar. In 298 fact, when a DF is elected, it MUST always be used as the DR as well 299 to avoid multicast packet looping. The procedures in this document 300 always elect a DF on the LAN, and for that reason will always be the 301 DR. In the sections that follow, we don't refer to the DR anymore. 302 Everywhere where we reference DF, we implicitly mean it applies to 303 both the DR and DF. 305 6. DF Election Mechanism Requirements 307 When electing a DF on the LAN, it is important to have a single DF 308 for a given Multicast flow at all times. If during the election 309 process (or changes to it), there is no DF, it will cause traffic 310 loss to the end user. If there are two (or more) DFs at the same 311 time, it may cause traffic duplication or even loops. Since the 312 election is done among different routers, it is not so trivial to 313 guarantee that there will never be inconsistency in the DF election. 314 There is also a tradeoff between the complexity introduced and the 315 incremental benefit it brings. The procedures in this document are 316 designed to detect inconsistency and recover from it as fast as 317 possible. During inconsistency, we prefer traffic loss over possible 318 duplication or looping of multicast packets. 320 When there are multiple candidate DF routers on the LAN, it is 321 beneficial to load-balance the traffic over the different candidate 322 DFs. This helps to distribute the bandwidth usage among the routers, 323 reduce the impact of a router failure and shorten the failover time 324 when changing the DF for effected flows. For that reason the DF 325 procedures MUST support DF election per multicast group address. 327 7. The DF Election mechanism 329 7.1. Highest Random Weight 331 The method proposed to select a DF is based on the Highest Random 332 Weight (HRM) as described in [RFC2291]. The paragraph below is 333 mostly taken (and modified) from [RFC2291]. 335 The router computes the weight for EACH candidate DF by performing a 336 hash over the Group address that identifies the flow, as well as over 337 the address of the candidate DF. The router then chooses the 338 candidate DF with the highest resulting weight value. This has the 339 advantage of minimizing the number of flows affected by a candidate 340 DF addition or deletion (only 1/N of them), but is approximately N 341 times as expensive as a modulo-N hash. 343 In order to get a good distribution of the Group addresses over the 344 candidate DFs, it is important we choose a good Pseudorandom function 345 to calculate the Weight. The Weight is calculated using the Group 346 (G) IP address and the Candidate DF (CDF) IP address. 348 Weight(G, CDF) = 349 (1103515245((1103515245.G+12345)XOR CDF)+12345)(mod 2^31) 351 If multiple Candidate DFs end up with the same highest weight, the DF 352 with the lowest IP address MUST be selected. 354 If every candidate DF on the LAN uses the same HRW algorithm to 355 select the DF for a particular Group out of the same list of 356 candidate DFs, they all will reach the same conclusion and there will 357 be no inconsistency. It is very important every router on the LAN 358 has the same list of candidate DFs. The mechanism proposed in this 359 draft to generate a consistent list is based on the new Hello 360 message. 362 7.2. The DF Hello Message 364 In order to discover the candidate DFs we need a mechanism to learn 365 them. We introduce a new (IGMP/MLD) message type called the DF 366 Hello. Routers on a LAN that are candidate DFs periodically send DF 367 Hellos. The message format is specified later in a later revision 368 document. Based on the DF Hellos it is possible to generate a list 369 of candidate DFs. However, it is challenging to keep the candidate 370 DF list synchronized between the routers when DFs are added or 371 removed from the list as each router will do that based on its own 372 scheduling. Especially when candidate DFs timeout, it is very likely 373 this happens at different times and opens up the opportunity for 374 inconsistency. Also, when a new candidate DF is added to the network 375 and one of the routers did not get the initial DF Hello message, its 376 candidate DF list will be out of sync until the next DF Hello is 377 received, leading to a inconsistent candidate DF list for a 378 relatively long period. In order to help synchronize the candidate 379 DF List we elect a Designated Announcer (DA). 381 7.3. The Designated Announcer 383 The router that will act as the Designated Announcer is determined by 384 the Priority value as included in the Hello message, using the IP 385 address as tiebreaker. The router with the highest priority is 386 preferred, if there are multiple routers with the same priority, the 387 router with the highest IP address is preferred. The DA determines 388 which routers from the Hello List (HL) are included in the Designated 389 Announcer List (DAL). By default all the routers in the HL are 390 considered to be included in the DAL. It is however possible to 391 filter certain candidates and not include these in the list based on 392 some sort of preference. 394 7.3.1. DAL Hello Option 396 The DAL is sent out by the DA as an Option included in its Hello 397 message. In order to reliably transmit the Hello Message with the 398 DAL option, a DAL sequence number is included in the packet along 399 with an acknowledgement flag for each router in the DAL. Every 400 router in the DAL MUST respond by triggering a Hello message 401 including this sequence number. If the DA has not received a 402 response within a given timeout from certain routers in the DAL it 403 will re-transmit the Hello message with the Acknowledgement flag not 404 set for the routers that have not responded. The routers on the LAN 405 that see their IP address in the DAL without the acknowledgement flag 406 set will re-transmit their Hello. This process continues until the 407 DA has received a response from all the routers in the DAL. Using 408 this mechanism we minimize the time an inconsistency can occur when a 409 router has missed a Hello message that includes that DAL. 411 7.3.2. A new Candidate DF 413 When a new candidate DF becomes active on the LAN, it first has to 414 learn if there are other candidate DFs on the LAN. Learning about 415 other candidate DFs is accelerated by setting the Learn Flag in the 416 Hello message. Routers on the LAN that receive a Hello with the 417 Learn Flag set will trigger a Hello message in response. After the 418 learning delay the new DF assumes all candidate DFs on the LAN have 419 responded and the Hello List is complete. There are three different 420 scenarios the new DF has to consider. 422 7.3.2.1. The Hello List is empty 424 When the HL is empty, the new DF will become the DA with only its own 425 address in the DAL. The DF will start to act as DF for all the 426 groups. 428 7.3.2.2. The New DF is not the DA 430 When there are other candidate DFs on the LAN, the Hello List is 431 populated. If the new DF is not the DA, it will have to wait for the 432 DA to include its address in the DAL. As soon as it sees its own 433 address in the ADA with the acknowledgement flag not set, it will 434 trigger a Hello message with the DAL sequence number and start to act 435 as DF. Note, it is likely that new DFs IP address is already 436 included in the first Hello message it receives from the DA. 438 7.3.2.3. The New DF is the DA 440 After the Learning delay the new router may find it self having the 441 highest Priority and will be the new ADA. Note, we prefer the DA to 442 be deterministic so the new DF will take over the role of the DA. 443 The DF which is currently the DA will have seen the Hello message 444 from the new DF and will realize this is the new DA. The current DA 445 MUST respond by sending a Hello message without the DAL in it. All 446 the routers on the LAN will now know that the current DA is going 447 away. The candidate DFs MAY continue to use the old DAL until the 448 new DAL list is received from the new DA. The new DF will create the 449 DAL list based on its Hello List and send out a Hello message, 450 following the procedures as described above. If during a transition 451 of the DA a router detects inconsistency between the received DAL and 452 the perceived DA, the router stops using the current DAL and waits 453 until the inconsistency is resolved. This inconsistency may have 454 occurred due to missing a DF Hello message (also see section DA 455 inconsistency). 457 7.3.3. A candidate DF goes down 459 When a DF goes down there are 2 different scenarios to consider. 461 7.3.3.1. The DF was the DA 463 When a DF goes down, due to a failure or an operator removing it from 464 the LAN, the routers on the LAN will eventually detect this because 465 the Holdtime for that DF will expire. This does not have an 466 immediate effect on the DF procedures because the DF is chosen from 467 the DAL, originated by the DA. A candidate DF MUST NOT take any 468 action based on a candidate DF going down, but MUST wait for the DA 469 to sent out a new DAL list. This will ensure that all candidate DFs 470 on the LAN will start to use the new DAL at the same time and avoid 471 any discrepancies due to routers expiring the timer associated with 472 the DF that went down. 474 7.3.3.2. The DF was the DA 476 If the DF that goes down is the DA, a new DA has to be elected. 477 Note, every candidate DF on the LAN is a potential candidate to 478 become the new DA. The new DA is chosen based on the Hello List 479 using the Designated Announcer election procedures. It is possible a 480 candidate DF receives the DAL from the new DA before it detected the 481 current DA is down. This may be due to a race condition where timers 482 on the candidate DF expire at different times. We use the procedures 483 as described in section (DA inconsistency). 485 7.4. DA Inconsistency 487 A candidate DF that receives a DAL from a router that it does not 488 consider to be the active DA MUST immediately stop acting as a DF. 489 The candidate DF MUST wait for the DA inconsistency to be resolved 490 before it is allowed to resume its role as candidate DF. This will 491 cause traffic to be blocked for the multicast groups this DF is 492 responsible for, but it will not cause traffic duplication and/or 493 loops due to other DFs using a different DAL list. The inconsistency 494 can be resolved due to the following events. 496 o The active DA expires. 498 o A Hello is received from the active DA without a DAL. 500 When the candidate DF detects that there is only one candidate DF 501 that has announced the DAL and it is considered to be the DA, the 502 inconsistency is resolved and the DF can resume its role as DF for 503 the Groups it is responsible for. 505 8. The Hello Message Packet Format 507 The format of the Hello Message is included on the next revision of 508 this document. 510 9. Security Considerations 512 TBD. 514 10. IANA Considerations 516 TBD. 518 11. Acknowledgments 520 Many thanks to Neale Ranns and Greg Shepherd for their comments on 521 this draft. 523 12. Normative References 525 [I-D.ietf-bier-architecture] 526 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and 527 S. Aldrin, "Multicast using Bit Index Explicit 528 Replication", draft-ietf-bier-architecture-02 (work in 529 progress), July 2015. 531 [I-D.pfister-bier-mld] 532 Pfister, P., Wijnands, I., and M. Stenberg, "BIER Ingress 533 Multicast Flow Overlay using Multicast Listener Discovery 534 Protocols", draft-pfister-bier-mld-00 (work in progress), 535 July 2015. 537 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 538 Requirement Levels", BCP 14, RFC 2119, 539 DOI 10.17487/RFC2119, March 1997, 540 . 542 [RFC2291] Slein, J., Vitali, F., Whitehead, E., and D. Durand, 543 "Requirements for a Distributed Authoring and Versioning 544 Protocol for the World Wide Web", RFC 2291, 545 DOI 10.17487/RFC2291, February 1998, 546 . 548 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 549 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 550 DOI 10.17487/RFC3810, June 2004, 551 . 553 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 554 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 555 Protocol Specification (Revised)", RFC 4601, 556 DOI 10.17487/RFC4601, August 2006, 557 . 559 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 560 "Internet Group Management Protocol (IGMP) / Multicast 561 Listener Discovery (MLD)-Based Multicast Forwarding 562 ("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605, 563 August 2006, . 565 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 566 Encodings and Procedures for Multicast in MPLS/BGP IP 567 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 568 . 570 [RFC6826] Wijnands, IJ., Ed., Eckert, T., Leymann, N., and M. 571 Napierala, "Multipoint LDP In-Band Signaling for Point-to- 572 Multipoint and Multipoint-to-Multipoint Label Switched 573 Paths", RFC 6826, DOI 10.17487/RFC6826, January 2013, 574 . 576 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 577 Locator/ID Separation Protocol (LISP)", RFC 6830, 578 DOI 10.17487/RFC6830, January 2013, 579 . 581 Authors' Addresses 583 IJsbrand Wijnands 584 Cisco Systems 585 De Kleetlaan 6a 586 Diegem 1831 587 Belgium 589 Email: ice@cisco.com 591 Pierre Pfister 592 Cisco Systems 593 Paris 594 France 596 Email: pierre.pfister@darou.fr 598 Jeffrey Zhang 599 Juniper Networks 600 10 Technology Park Dr. 601 Westford MA 01886 602 US 604 Email: zzhang@juniper.net