idnits 2.17.1 draft-ietf-bier-mvpn-05.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 date (January 10, 2017) is 2656 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force E. Rosen, Ed. 3 Internet-Draft Juniper Networks, Inc. 4 Intended status: Standards Track M. Sivakumar 5 Expires: July 14, 2017 Cisco Systems, Inc. 6 S. Aldrin 7 Google, Inc. 8 A. Dolganow 9 Nokia 10 T. Przygienda 11 Juniper Networks, Inc. 12 January 10, 2017 14 Multicast VPN Using BIER 15 draft-ietf-bier-mvpn-05 17 Abstract 19 The Multicast Virtual Private Network (MVPN) specifications require 20 the use of multicast tunnels ("P-tunnels") that traverse a Service 21 Provider's backbone network. The P-tunnels are used for carrying 22 multicast traffic across the backbone. A variety of P-tunnel types 23 are supported. Bit Index Explicit Replication (BIER) is a new 24 architecture that provides optimal multicast forwarding through a 25 "multicast domain", without requiring intermediate routers to 26 maintain any per-flow state or to engage in an explicit tree-building 27 protocol. This document specifies the protocol and procedures that 28 allow MVPN to use BIER as the method of carrying multicast traffic 29 over an SP backbone network. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on July 14, 2017. 48 Copyright Notice 50 Copyright (c) 2017 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Use of the PMSI Tunnel Attribute . . . . . . . . . . . . . . 4 67 2.1. MPLS Label . . . . . . . . . . . . . . . . . . . . . . . 5 68 2.2. Explicit Tracking . . . . . . . . . . . . . . . . . . . . 7 69 2.2.1. Using the LIR Flag . . . . . . . . . . . . . . . . . 7 70 2.2.2. Using the LIR-pF Flag . . . . . . . . . . . . . . . . 7 71 3. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 3.1. Encapsulation and Transmission . . . . . . . . . . . . . 8 73 3.2. Disposition . . . . . . . . . . . . . . . . . . . . . . . 9 74 3.2.1. At a BFER that is an Egress PE . . . . . . . . . . . 10 75 3.2.2. At a BFER that is a P-tunnel Segmentation Boundary . 10 76 4. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 10 77 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 82 8.2. Informative References . . . . . . . . . . . . . . . . . 12 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 85 1. Introduction 87 [RFC6513] and [RFC6514] specify the protocols and procedures that a 88 Service Provider (SP) can use to provide Multicast Virtual Private 89 Network (MVPN) service to its customers. Multicast tunnels are 90 created through an SP's backbone network; these are known as 91 "P-tunnels". The P-tunnels are used for carrying multicast traffic 92 across the backbone. The MVPN specifications allow the use of 93 several different kinds of P-tunnel technology. 95 Bit Index Explicit Replication (BIER) ([BIER_ARCH]) is an 96 architecture that provides optimal multicast forwarding through a 97 "multicast domain", without requiring intermediate routers to 98 maintain any per-flow state or to engage in an explicit tree-building 99 protocol. The purpose of the current document is to specify the 100 protocols and procedures needed in order to provide MVPN service 101 using BIER to transport the multicast traffic over the backbone. 103 Although BIER does not explicitly build and maintain multicast 104 tunnels, one can think of BIER as using a number of implicitly 105 created tunnels through a "BIER domain". In particular, one can 106 think of there as being one Point-to-Multipoint (P2MP) tunnel from 107 each "Bit Forwarding Ingress Router" (BFIR) to all the "Bit 108 Forwarding Egress Routers" (BFERs) in the BIER domain, where a BIER 109 domain is generally co-extensive with an IGP network. These 110 "tunnels" are not specific to any particular VPN. However, the MVPN 111 architecture provides protocols and procedures that allow the traffic 112 of multiple MVPNs to be aggregated on a single P-tunnel. In this 113 document, we specify how to use these multi-VPN aggregation 114 procedures to enable BIER to transport traffic from multiple MVPNs. 116 MVPN traffic must sometimes traverse more than one IGP domain, 117 whereas BIER only carries multicast traffic within a single IGP 118 domain. However, the MVPN specifications allow P-tunnels to be 119 "segmented", where the segmentation points may either be Autonomous 120 System Border Routers (ASBRs), as described in [RFC6514], or Area 121 Border Routers (ABRs), as described in [RFC7524]. As long as the 122 segmentation points are capable of acting as BFIRs and BFERs, BIER 123 can be used to provide some or all of the segments of a P-tunnel. 125 This revision of the document does not specify the procedures 126 necessary to support MVPN customers that are using BIDIR-PIM. Those 127 procedures will be added in a future revision. 129 This document uses the following terminology from [BIER_ARCH]: 131 o BFR: Bit-Forwarding Router. 133 o BFIR: Bit-Forwarding Ingress Router. 135 o BFER: Bit-Forwarding Egress Router. 137 This document uses the following terminology from [RFC6513]: 139 o MVPN: Multicast Virtual Private Network -- a VPN [RFC4364] in 140 which multicast service is offered. 142 o P-tunnel. A multicast tunnel through the network of one or more 143 SPs. P-tunnels are used to transport MVPN multicast data 145 o C-S: A multicast source address, identifying a multicast source 146 located at a VPN customer site. 148 o C-G: A multicast group address used by a VPN customer. 150 o C-flow: A customer multicast flow. Each C-flow is identified by 151 the ordered pair (source address, group address), where each 152 address is in the customer's address space. The identifier of a 153 particular C-flow is usually written as (C-S,C-G). 154 Sets of C-flows can be identified by the use of the "C-*" wildcard 155 (see [RFC6625]), e.g., (C-*,C-G). 157 o I-PMSI A-D Route: Inclusive Provider Multicast Service Interface 158 Auto-Discovery route. Carried in BGP Update messages, these 159 routes are used to advertise the "default" P-tunnel for a 160 particular MVPN. 162 o S-PMSI A-D route: Selective Provider Multicast Service Interface 163 Auto-Discovery route. Carried in BGP Update messages, these 164 routes are used to advertise the fact that particular C-flows are 165 bound to (i.e., are traveling through) particular P-tunnels. 167 o PMSI Tunnel attribute (PTA). This BGP attribute carried is used 168 to identify a particular P-tunnel. When C-flows of multiple VPNs 169 is carried in a single P-tunnel, this attribute also carries the 170 information needed to multiplex and demultiplex the C-flows. 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in RFC 2119 [RFC2119]. 176 2. Use of the PMSI Tunnel Attribute 178 As defined in [RFC6514], the PMSI Tunnel attribute is used to 179 identify the particular P-tunnel to which one or more multicast flows 180 are being assigned. 182 The PMSI Tunnel attribute (PTA)contains the following fields: 184 o "Tunnel Type". IANA is requested to assign a new tunnel type 185 codepoint for "BIER". This codepoint will be used to indicate 186 that the PMSI is instantiated by BIER. 188 o "Tunnel Identifier". When the "tunnel type" field is "BIER", this 189 field contains two subfields: 191 1. The first subfield is a single octet, containing the sub- 192 domain-id of the sub-domain to which the BFIR will assign the 193 packets that it transmits on the PMSI identified by the NLRI 194 of the BGP I-PMSI or S-PMSI A-D route that contains this PTA. 195 (How that sub-domain is chosen is outside the scope of this 196 document.) 198 2. The second subfield is the BFR-Prefix (see [BIER_ARCH]) of the 199 originator of the route that is carrying this PTA. This will 200 either be a /32 IPv4 address or a /128 IPv6 address. Whether 201 the address is IPv4 or IPv6 can be inferred from the total 202 length of the PMSI Tunnel attribute. 204 o "MPLS label". This field contains an upstream-assigned MPLS 205 label. It is assigned by the router that originates the BGP route 206 to which the PTA is attached. Constraints on the way in which the 207 originating router selects this label are discussed below. 209 o "Flags". When the tunnel type is BIER, two of the flags in the 210 PTA Flags field are meaningful. Details about the use of these 211 flags can be found in Section 2.2. 213 * "Leaf Info Required per Flow (LIR-pF)". This flag is 214 introduced in [EXPLICIT_TRACKING]. A BFIR SHOULD NOT set this 215 flag UNLESS it knows that all the BFERs in the BIER domain (or 216 at least all the BFERs to which it needs to transmit) support 217 this flag. (How this is known is outside the scope of this 218 document.) Procedures for the use of this flag are given in 219 Section 2.2.2 221 * "Leaf Info Required Bit". See Section 2.2.1. 223 Note that if a PTA specifying "BIER" is attached to an I-PMSI or 224 S-PMSI A-D route, the route MUST NOT be distributed beyond the 225 boundaries of a BIER domain. That is, any routers that receive the 226 route must be in the same BIER domain as the originator of the route. 227 If the originator is in more than one BIER domain, the route must be 228 distributed only within the BIER domain in which the BFR-Prefix in 229 the PTA uniquely identifies the originator. As with all MVPN routes, 230 distribution of these routes is controlled by the provisioning of 231 Route Targets. 233 2.1. MPLS Label 235 Suppose an ingress PE originates two x-PMSI A-D routes, where we use 236 the term "x-PMSI" to mean "I-PMSI or S-PMSI". Suppose both routes 237 carry a PTA, and the PTA of each route specifies"BIER". 239 o If the two routes do not carry the same set of Route Targets 240 (RTs), then their respective PTAs MUST contain different MPLS 241 label values. 243 o If the ingress PE is supporting MVPN extranet ([RFC7900]) 244 functionality, and if the two routes originate from different 245 VRFs, then the respective PTAs of the two routes MUST contain 246 different MPLS label values. 248 o If the ingress PE is supporting the "Extranet Separation" feature 249 of MVPN extranet (see Section 7.3 of [RFC7900], section ), and if 250 one of the routes carries the "Extranet Separation" extended 251 community and the other does not, then the respective PTAs of the 252 two routes MUST contain different MPLS label values. 254 o If segmented P-tunnels are being used, then the respective PTAs of 255 the two routes MUST contain different MPLS label values, as long 256 as the NLRIs are not identical. In this case, the MPLS label can 257 be used by the BFER to identify the particular C-flow to which a 258 data packet belongs, and this greatly simplifies the process of 259 forwarding a received packet to its next P-tunnel segment. This 260 is explained further below. See also Section 3. 262 When segmented P-tunnels are being used, an ABR or ASBR may receive, 263 from a BIER domain, an x-PMSI A-D route whose PTA specifies "BIER". 264 This means that BIER is being used for one segment of a segmented 265 P-tunnel. The ABR/ASBR may in turn need to originate an x-PMSI A-D 266 route whose PTA identifies the next segment of the P-tunnel. The 267 next segment may also be "BIER". Suppose an ASBR receives x-PMSI A-D 268 routes R1 and R2, and as a result originates x-PMSI A-D routes R3 and 269 R4 respectively, where the PTAs of each of the four routes specify 270 BIER. Then the PTAs of R3 and R4 MUST NOT specify the same MPLS 271 label, UNLESS both of the following conditions hold: 273 o R1 and R2 have the same "originating router" in their respective 274 NLRIs. 276 o R1 and R2 specify the same MPLS label in their respective PTAs. 278 The ABR/ASBR MUST then program its dataplane such that a packet 279 arriving with the upstream-assigned label specified in route R1 is 280 transmitted with the upstream-assigned label specified in route R3, 281 and a packet arriving with the upstream-assigned label specified in 282 route R2 is transmitted with the label specified in route R4. Of 283 course, the data plane must also be programmed to encapsulate the 284 transmitted packets with an appropriate BIER header, whose BitString 285 is determined by the multicast flow overlay. 287 2.2. Explicit Tracking 289 When using BIER to transport an MVPN data packet through a BIER 290 domain, an ingress PE functions as a BFIR (see [BIER_ARCH]). The 291 BFIR must determine the set of BFERs to which the packet needs to be 292 delivered. This can be done in either of two ways: 294 1. Using the explicit tracking mechanism based on the "Leaf Info 295 Required" flag specified in [RFC6513] and [RFC6514]. This method 296 is further described in Section 2.2.1. 298 2. Using the explicit tracking mechanism based on the LIR-pF flag 299 specified in [EXPLICIT_TRACKING]. This method, further described 300 in Section 2.2.2, may be used if (and only if) segmented 301 P-tunnels are not being used. 303 2.2.1. Using the LIR Flag 305 To determine the set of BFERs to which the packets of a given C-flow 306 must be sent, a BFIR MUST originate a (C-S,C-G) S-PMSI A-D route for 307 the given C-flow. It MUST attach a PTA to that route, and MUST set 308 the LIR flag in the PTA. Per [RFC6514], the BFERs that need to 309 receive that C-flow will respond with (C-S,C-G) Leaf A-D routes. By 310 matching the received Leaf A-D routes to the originated S-PMSI A-D 311 routes, the originator of the S-PMSI A-D route determines the set of 312 BFERs that need to receive the multicast data flow that is identified 313 in the NLRI of S-PMSI A-D route. 315 The PTA MAY specify a tunnel type ("BIER") and a non-zero MPLS label. 316 (If it specifies one of these it MUST also specify the other.) 317 Alternatively, the PTA MAY specify "no tunnel type" and a zero MPLS 318 label. In this case, the tunnel type ("BIER") and non-zero MPLS 319 label MUST be specified in an I-PMSI A-D route or in a wildcard 320 S-PMSI A-D route that "matches" (according to the rules of [RFC6625]) 321 the C-flow in question. 323 2.2.2. Using the LIR-pF Flag 325 If segmented P-tunnels are not being used, the BFIR can determine the 326 set of BFERs that need to receive the packets of a given (C-S,C-G) 327 C-flow as follows. The BFIR MUST originate a wildcard S-PMSI A-D 328 route (either (C-*,C-*), (C-*,C-G), or (C-S,C-G) and the PTA of that 329 route MUST the following settings: 331 o The LIR-pF flag MUST be set; 333 o The tunnel type MUST be set to "BIER; 334 o A non-zero MPLS label MUST be specified. 336 Per [EXPLICIT_TRACKING], a BFER that needs to receive (C-S,C-G) 337 traffic from the BFIR will respond with a Leaf A-D route. 339 A BFIR MUST NOT use this method of finding the set of BFERs needing 340 to receive a given C-flow unless it knows that all those BFERs 341 support the LIR-pF flag. How this is known is outside the scope of 342 this document. 344 This method greatly reduces the number of S-PMSI A-D routes that a 345 BFIR needs to originate; it can now originate as few as one such 346 route (a (C-*,C-*) S-PMSI A-D route), rather than one for each 347 C-flow. However, the method does not provide a way for the BFIR to 348 assign a distinct label to each C-flow. Therefore it cannot be used 349 when segmented P-tunnels are in use (see Section 3 for an 350 explanation). 352 Note: if a BFIR originates a (C-*,C-*) S-PMSI A-D route with the LIR- 353 pF flag set, but also originates a more specific wildcard route that 354 matches a particular (C-S,C-G), the BFERs will not originate Leaf A-D 355 routes for that (C-S,C-G) unless the LIR-pF flag is also set in the 356 more specific wildcard route. If the BFIR also originates a 357 (C-S,C-G) S-PMSI A-D route without the LIR flag set, the BFERs will 358 not originate Leaf A-D routes for that (C-S,C-G) unless the LIR flag 359 is also set in that route. 361 3. Data Plane 363 The MVPN application plays the role of the "multicast flow overlay" 364 as described in [BIER_ARCH]. 366 3.1. Encapsulation and Transmission 368 To transmit an MVPN data packet, an ingress PE follows the rules of 369 [RFC6625] to find the S-PMSI A-D route or I-PMSI A-D route that is a 370 "match for transmission" for that packet. (In applying the rules of 371 [RFC6625], any S-PMSI A-D route with a PTA specifying "no tunnel 372 information" is ignored.) If the matching route has a PTA specifying 373 "BIER", the (upstream-assigned) MPLS label from that PTA is pushed on 374 the packet's label stack. Then the packet is encapsulated in a BIER 375 header and forwarded, according to the procedures of [BIER_ARCH] and 376 [BIER_ENCAPS]. (See especially Section 4, "Imposing and Processing 377 the BIER Encapsulation", of [BIER_ENCAPS].) 379 In order to create the proper BIER header for a given packet, the 380 BFIR must know all the BFERs that need to receive that packet. It 381 determines this by finding all the Leaf A-D routes that correspond to 382 the S-PMSI A-D route that is the packet's match for transmission. 383 There are two different cases to consider: 385 1. The S-PMSI A-D route that is the match for transmission carries a 386 PTA that has the LIR flag set but does not have the LIR-pF flag 387 set. 389 In this case, the corresponding Leaf A-D routes are those whose 390 "route key" field is identical to the NLRI of the S-PMSI A-D 391 route. 393 2. The S-PMSI A-D route that is the match for transmission carries a 394 PTA that has the LIR-pF flag. 396 In this case, the corresponding Leaf A-D routes are those whose 397 "route key" field is derived from the NLRI of the S-PMSI A-D 398 route according to the procedures described in Section 5.2 of 399 [EXPLICIT_TRACKING]. 401 3.2. Disposition 403 When a BFER receives an MVPN multicast data packet that has been 404 BIER-encapsulated, the BIER layer passes the following information to 405 the multicast flow overlay: 407 o The BFR-prefix corresponding to the sub-domain-id and BFIR-id in 408 the BIER header. 410 o The "payload", which is an MPLS packet whose top label is an 411 upstream-assigned label. The BFR-prefix provides the "context" in 412 which the upstream-assigned label is interpreted. 414 Note that per [RFC5331], the context for an upstream-assigned 415 label is the IP address of the label assigner, which in this case 416 is the BFR-prefix of the BFIR. 418 By looking up the upstream-assigned label in the appropriate context, 419 the multicast flow overlay determines whether the BFER is an egress 420 PE for the packet. 422 Note that if segmented P-tunnels are in use, a BFER might be a 423 P-tunnel segmentation border router rather than an egress PE, or a 424 BFER might be both an egress PE and a P-tunnel segmentation border 425 router. Depending upon the role of the BFER for given packet, it may 426 need to follow the procedures of Section 3.2.1, the procedures of 427 Section 3.2.2, or both. 429 3.2.1. At a BFER that is an Egress PE 431 From looking up the packet's upstream-assigned label in the context 432 of the packet's BFIR-prefix, the egress PE determines the egress VRF 433 for the packet. From the IP header of the payload, the multicast 434 states of the VRF, the upstream-assigned label, and the BFR-prefix, 435 the egress PE can determine whether the packet needs to be forwarded 436 out one or more VRF interfaces. 438 3.2.2. At a BFER that is a P-tunnel Segmentation Boundary 440 When segmented P-tunnels are being used, a BFER that receives a BIER- 441 encapsulated MVPN multicast data packet may need to be forwarded on 442 its next P-tunnel segment. The choice of the next P-tunnel segment 443 for the packet depends upon the C-flow to which the packet belongs. 444 As long as the BFIR has assigned the MPLS label according to the 445 constraints specified in Section 2.1, the BFIR will have assigned 446 distinct upstream-assigned MPLS labels to distinct C-flows. The BFER 447 can thus select the proper "next P-tunnel segment" for a given packet 448 simply by looking up the upstream-assigned label that immediately 449 follows the BIER header. 451 4. Contributor Addresses 453 Below is a list of other contributing authors in alphabetical order: 455 IJsbrand Wijnands 456 Cisco Systems, Inc. 457 De Kleetlaan 6a 458 Diegem 1831 459 Belgium 461 Email: ice@cisco.com 463 5. Acknowledgments 465 The authors wish to thank Jeffrey Zhang for his ideas and 466 contributions to this work. 468 6. IANA Considerations 470 IANA is requested to assign a value for "BIER" from the "P-Multicast 471 Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry. The 472 reference should be this document. 474 7. Security Considerations 476 The security considerations of [BIER_ARCH], [BIER_ENCAPS], [RFC6513] 477 and [RFC6514] are applicable. 479 8. References 481 8.1. Normative References 483 [BIER_ARCH] 484 Wijnands, IJ., Rosen, E., Dolganow, A., Przygienda, T., 485 and S. Aldrin, "Multicast using Bit Index Explicit 486 Replication", internet-draft draft-ietf-bier-architecture- 487 05, October 2016. 489 [BIER_ENCAPS] 490 Wijnands, IJ., Rosen, E., Dolganow, A., Tantsura, J., and 491 S. Aldrin, "Encapsulation for Bit Index Explicit 492 Replication in MPLS Networks", internet-draft draft-ietf- 493 bier-mpls-encapsulation-06.txt, December 2016. 495 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 496 Requirement Levels", BCP 14, RFC 2119, 497 DOI 10.17487/RFC2119, March 1997, 498 . 500 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 501 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 502 2006, . 504 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 505 Label Assignment and Context-Specific Label Space", 506 RFC 5331, DOI 10.17487/RFC5331, August 2008, 507 . 509 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 510 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 511 2012, . 513 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 514 Encodings and Procedures for Multicast in MPLS/BGP IP 515 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 516 . 518 [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. 519 Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", 520 RFC 6625, DOI 10.17487/RFC6625, May 2012, 521 . 523 8.2. Informative References 525 [EXPLICIT_TRACKING] 526 Dolganow, A., Kotalwar, J., Rosen, E., and Z. Zhang, 527 "Explicit Tracking with Wild Card Routes in Multicast 528 VPN", internet-draft draft-ietf-bess-mvpn-expl-track-01, 529 December 2016. 531 [RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., 532 Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area 533 Point-to-Multipoint (P2MP) Segmented Label Switched Paths 534 (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, 535 . 537 [RFC7900] Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y., 538 and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs", 539 RFC 7900, DOI 10.17487/RFC7900, June 2016, 540 . 542 Authors' Addresses 544 Eric C. Rosen (editor) 545 Juniper Networks, Inc. 546 10 Technology Park Drive 547 Westford, Massachusetts 01886 548 United States 550 Email: erosen@juniper.net 552 Mahesh Sivakumar 553 Cisco Systems, Inc. 554 510 McCarthy Blvd 555 Milpitas, California 95035 556 United States 558 Email: masivaku@cisco.com 560 Sam K Aldrin 561 Google, Inc. 562 1600 Amphitheatre Parkway 563 Mountain View, California 564 United States 566 Email: aldrin.ietf@gmail.com 567 Andrew Dolganow 568 Nokia 569 600 March Rd. 570 Ottawa, Ontario K2K 2E6 571 Canada 573 Email: andrew.dolganow@nokia.com 575 Tony Przygienda 576 Juniper Networks, Inc. 577 1137 Innovation Way 578 San Jose, California 94089 579 United States 581 Email: prz@juniper.net