Internet Engineering Task Force K. Patel Internet-Draft Cisco Systems Intended status: Standards Track E. Rosen Expires: April 7, 2016 Juniper Networks Y. Rekhter October 5, 2015 BGP as an MVPN PE-CE Protocol draft-ietf-bess-mvpn-pe-ce-01 Abstract When a Service Provider offers BGP/MPLS IP VPN service to its customers, RFCs 6513 and 6514 describe protocols and procedures that the Service Provider can use in order to carry the customer's IP multicast traffic from one customer site to others. BGP can be used to carry customer multicast routing information from one Provider Edge (PE) router to another, but it is assumed that PIM is running on the interface between a Customer Edge (CE) router and a PE router. This document specifies protocols and procedures that, under certain conditions, allow customer multicast routing information to carried between PE and CE via BGP. This can eliminate the need to run PIM on the PE-CE interfaces, potentially eliminating the need to run PIM on the PE routers at all. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 7, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. Patel, et al. Expires April 7, 2016 [Page 1] Internet-Draft BGP as an MVPN PE-CE Protocol October 2015 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. C-MCAST SAFI NLRI Format . . . . . . . . . . . . . . . . . . 4 2.1. C-MCAST Join and Prune Routes . . . . . . . . . . . . . . 5 3. Exchanging C-MCAST Join Routes . . . . . . . . . . . . . . . 6 3.1. Originating C-MCAST Join Route at the CE router . . . . . 6 3.2. Receiving a C-MCAST Join Route by the CE Router . . . . . 8 3.3. Originating a C-MCAST Join Route at the PE Router . . . . 8 3.4. Receiving a C-MCAST Join Route by the PE Router . . . . . 10 4. Pruning Sources off the Shared Tree . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction When a Service Provider offers BGP/MPLS IP VPN service to its customers, [RFC6513] and [RFC6514] describe protocols and procedures that the Service Provider can use in order to carry the customer's IP multicast traffic from one customer site to others. BGP can be used to carry customer multicast routing information from one Provider Edge (PE) router to another, but it is assumed that PIM is running on the interface between a Customer Edge (CE) router and a PE router. This document specifies protocols and procedures that under certain conditions, allow customer multicast routing information to carried between PE and CE via BGP. This can eliminate the need to run PIM on the PE-CE interfaces, potentially eliminating the need to run PIM on the PE routers at all. It is however assumed that PIM is the multicast routing protocol running at the customer sites. This document defines a new SAFI known as Customer-Multicast (C-MCAST) SAFI. This SAFI is used to carry customer multicast routing information from CE to PE (and vice versa). The use of this SAFI is only defined when the AFI is either IPv4 or IPv6. The Patel, et al. Expires April 7, 2016 [Page 2] Internet-Draft BGP as an MVPN PE-CE Protocol October 2015 procedures of this document are applicable only if BGP is being used as the PE-PE control protocol for carrying customer multicast routing. It is presupposed that if these procedures are being used on any interface of a given VRF, then PIM is NOT enabled on that interface or on any other VRF interface of that same VRF. It is also assumed that if a CE is using BGP C-MCAST on its interface to one PE, then it is using BGP C-MCAST on its interfaces to all the PEs to which it is connected, and that PIM is not enabled on any of these interfaces. Throughout this document, we will use the terms "MCAST-VPN route" and "C-MCAST route" to mean routes that have the corresponding SAFI. This document assumes that a CE and a PE exchange C-MCAST routes over a direct BGP session (i.e., the C-MCAST routes do not pass through a route reflector or other third party on their way from CE to PE, or vice versa). The NLRI format of a C-MCAST route is modeled on the NLRI format of the MCAST-VPN SAFI, as defined in [RFC6514]. However, since the C-MCAST routes are always exchanged in the context of a particular VPN, Route Distinguishers (RDs) are not used. Also, C-MCAST routes are never distributed from one PE to another. Where the procedures of this document require a PE or a CE to determine the upstream neighbor for a particular multicast (*,G) or (S,G) state, the upstream neighbor is determined using the procedures of [RFC4601], rather than the procedures of [RFC6513] or [RFC6514]. That is, the upstream neighbor selected for a particular (*,G) or (S,G) is the same as it would be if PIM were being used between the PE and CE. This includes support for non-congruent multicast topologies. The upstream neighbor address determined through these procedures MUST be the same address that the upstream neighbor puts in the next hop field of BGP Updates that it sends to the "downstream" PE or CE. Note that neither the VRF Route Import Extended Community nor the Source AS Extended Community, defined in [RFC6514], are used. When following the procedures of this document, customer IP multicast traffic is sent natively from CE to PE, and vice versa. There is no encapsulation or tunneling of the multicast traffic. Therefore there is no need for C-MCAST routes corresponding to the I-PMSI A-D routes or S-PMSI A-D routes or [RFC6514]. Similarly, there is no need for the PMSI Tunnel attribute of [RFC6514]. This document does not provide a mechanism corresponding to the "PIM Assert" mechanism of [RFC4601]. It is assumed either that the PE-CE Patel, et al. Expires April 7, 2016 [Page 3] Internet-Draft BGP as an MVPN PE-CE Protocol October 2015 interfaces are point-to-point interfaces, or else that the multicast procedures in the PE and CE can determine, by examination of the layer 2 headers, the node from which a given multicast data packet was received. Support for "Dense Mode Multicast" (PIM-DM) is outside the scope of this document. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. C-MCAST SAFI NLRI Format The BGP Multiprotocol Extensions [RFC4760] allow BGP to carry routes from multiple different "AFI/SAFIs". This document defines a new a new SAFI known as a C-MCAST SAFI with a value to be assigned by the IANA. This SAFI is used along with the AFI of IPv4 (1) or IPv6 (2). The C-MCAST NLRI defined below is carried in the BGP UPDATE messages [RFC4271] using the BGP multiprotocol extensions [RFC4760] with a AFI of IPv4 (1) or IPv6 (2) assigned by IANA and a C-MCAST SAFI with a value to be assigned by the IANA. The Next hop field of MP_REACH_NLRI attribute SHALL be interpreted as an IPv4 adress whenever the length of the Next Hop address is 4 octets, and as an IPv6 address whenever the length of the Next Hop is address is 16 octets. The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix with a maximum length of 12 octers for IPv4 AFI and 36 octets for IPv6 AFI. The following is the format of the C-MCAST NLRI: +-----------------------------------+ | Route Type (1 octet) | +-----------------------------------+ | Length (1 octet) | +-----------------------------------+ | Route Type specific (variable) | +-----------------------------------+ Figure 1 The Route Type field defines encoding of the rest of the C-MCAST NLRI. (Route Type specific C-MCAST NLRI). The Length field indicates the length in octets of the Route Type specific field of C-MCAST NLRI. Patel, et al. Expires April 7, 2016 [Page 4] Internet-Draft BGP as an MVPN PE-CE Protocol October 2015 This document defines the following Route Types: 1 - Shared Tree Join Route 2 - Source Tree Join Route 4 - Source Prune A-D Route The encodings and procedures for these route types are described in the subsequent sections. The NLRI encodings are modeled after those of [RFC6514], in order to facilitate implementation in generation of MCAST-VPN routes. In order for two BGP speakers to exchange C-MCAST NLRI, they must use BGP Capabilities Advertisement [RFC5492] to ensure that they both are capable of properly processing the C-MCAST NLRI. This is done as specified in [RFC4760], by using a capability code 1 (multiprotocol BGP) with an AFI of IPv4 (1) or IPv6 (2) and a SAFI of C-MCAST with a value to be assigned by IANA. 2.1. C-MCAST Join and Prune Routes The "route type specific" part of the C-MCAST NLRI is the same for the Shared Tree Join, Source Tree Join, and Source Prune A-D Route Types. +-----------------------------------+ | Multicast Source Length (1 octet) | +-----------------------------------+ | Multicast Source (variable) | +-----------------------------------+ | Multicast Group Length (1 octet) | +-----------------------------------+ | Multicast Group (variable) | +-----------------------------------+ Figure 2 The value of the AFI field in the MP_REACH_NLRI/MP_UNREACH_NLRI that carries the C-MCAST NLRI determines whether the multicast source and multicast group addresses fields are IPv4 addresses (AFI 1) or IPv6 addresses (AFI 2). The length field of IPv4 source and group addresses is 32 bits and the length field of IPv6 addresses is 128 bits. Use of other values of the Multicast Source Length and Multicast Group Length fields is outside the scope of this document. If other values occur, or if the NLRI length is not as expected, given the AFI Patel, et al. Expires April 7, 2016 [Page 5] Internet-Draft BGP as an MVPN PE-CE Protocol October 2015 value, the NLRI should be considered to be malformed. An implementation SHOULD treat such an UPDATE as though the NLRI has been withdrawn, SHOULD log an error. In a Source Tree Join route, the Multicast Source field and the Multicast Group field identify an (S,G) multicast flow, where the IP address of S appears in the Multicast Source field and the IP address of G appears in the Multicast Group field. In a Shared Tree Join route, the Multicast Source field contains the Rendezvous Point (RP) address that is associated, at the originator of the UPDATE, with the multicast group whose address appears in the Multicast Group field. In the Source Prune route, the Multicast Source field contains the address of a source that is to be pruned from the shared tree associated with the multicast group whose address appears in the Multicast Group field. Usage of C-MCAST Join routes is described in Section 3. Usage of C-MCAST Source Prune routes is described in Section 4. 3. Exchanging C-MCAST Join Routes Multicast Routing Information is exchanged between a CE router and a PE a router using C-MCAST NLRIs. If the procedures of this draft are followed, the CE router and the PE router MUST NOT exchange PIM messages with each other. The C-MCAST routes are originated and propagated as follows. 3.1. Originating C-MCAST Join Route at the CE router Whenever a) PIM instance on a particular CE router creates a new (S,G) or (*,G) state and b) the selected upstream neighbor address for that state is a PE router to which the CE router is directly connected and with which the CE has a BGP session on whch the C-MCAST SAFI is enabled, then the CE router MUST originate a C-MCAST Source Tree Join route or a C-MCAST Shared Tree Join route. The CE router uses the procedures of [RFC4601] to determine the upstream neighbor (also called the "RPF neighbor"). Note that, unlike [RFC6513], the upstream nexthop selection procedures defined in this document are not based on the VRF Route Import Extended community [RFC6513]. The Route Type field of the NLRI is set to "Source Tree Join" if the corresponding state is (S,G), and to "Shared Tree Join" if the corresponding state is (*,G). Patel, et al. Expires April 7, 2016 [Page 6] Internet-Draft BGP as an MVPN PE-CE Protocol October 2015 The Multicast Source field of the NLRI of a C-MCAST Source Tree Join route MUST be set to the source address of the corresponding (S,G). The Multicast Source field of the NLRI of a C-MCAST Shared Tree Join route MUST be set to the address of the RP that is mapped to the corresponding (*,G) state. The Multicast Group field of the NLRI of either kind of C-MCAST Join route MUST be set to the multicast group address of the (S,G) or (*,G) state. The CE router MUST put its own IP address in the Next Hop field of either type of C-MCAST Join route. The CE router MUST attach a particular RT to the C-MCAST Join route. This RT MUST be either an IP Address Specific RT or an IPv6 Address Specific RT, depending upon whether the address of the upstream neighbor is an IPv4 address or an IPv6 address. In either case, the address of the upstream neighbor is placed in the Global Administrator field of the RT, and the Local Administrator field is set to 0. (Compare to the "C-multicast Import RT" described in section 7 of [RFC6514].) The "address of the upstream neighbor" MUST be the address that the upstream neighbor puts in the Next Hop field of BGP UPDATEs that it sends to the CE router. The CE MUST send the C-MCAST Join route on the BGP session to the PE that it has selected as the upstream neighbor for the (*,G) or (S,G) identified in the NLRI of the route. Although not required for correctness, it is RECOMMENDED that the C-MCAST Join not be sent on other BGP sessions. How this distribution constraint is met is a local matter. Policy based filtering based on the RT is one possible way to meet the constraint. Use of [RFC4684] is another. The C-MCAST Shared Tree Join is used to join the shared tree of an "Any Source Multicast" (ASM) group. The C-MCAST Source Tree Join is used in both ASM mode and in "Single Source Multicast" (SSM) mode to join a source tree. The C-MCAST Shared Tree Join can be used to join a BIDIR-PIM [RFC5015] multicast group, as long as the interface between the PE and the CE is a point-to-point interface. If a PIM instance on a particular CE router deletes its (S,G) or a (*,G) entry, and if there is a currently originated corresponding C-MCAST Join route, then that route MUST be withdrawn. The C-MCAST route is withdrawn using the MP_UNREACH_NLRI attribute. If the upstream neighbor of a (S,G) or (*,G) route changes, and if there is a currently originated corresponding C-MCAST Join route, then the RT MUST be changed to identify the new upstream neighbor, and the route MUST be advertised on the BGP session to that neighbor. Patel, et al. Expires April 7, 2016 [Page 7] Internet-Draft BGP as an MVPN PE-CE Protocol October 2015 3.2. Receiving a C-MCAST Join Route by the CE Router When a CE router receives a C-MCAST route from its PE router, it checks to see if the route carries an IP Address Specific Route Target Extended Community whose Global Administrator field contains the address that the CE puts in the Next Hop field of the BGP UPDATEs it sends to the PE router. If there is no such Route Target, the received route does not impact the CE's multicast state. Otherwise, the received route is used to create or modify the corresponding (S,G) or (*,G) state in the multicast forwarding information base (FIB). The CE-to-PE interface is stored in the outgoing interface list of the corresponding (S,G) or a (*,G) state. If the C-MCAST route is received with the Route Type of Shared Tree Join, then the CE router attaches RP address to the corresponding (*,G) state. If the CE router is connected to the multiple PE routers, it is possible that it will receive C-MCAST routes with the same NLRI from multiple PE routers. In this case, the CE router adds multiple CE- to-PE interfaces to its outgoing interface list, one for each PE router from which the given route was received. (Note that a particular CE-to-PE interface is added only if the route from the corresponding PE identifies the CE in its IP Address Specific RT.) When the last C-MCAST route for a given (S,G) or a (*,G) is withdrawn, resulting in a state where BGP C-MCAST SAFI has no route for a given (S,G) or a (*,G) state, the CE router MUST remove all the interfaces learnt via BGP from the outgoing interface list. If this results in an empty outgoing interface list then the CE router using PIM procedures MUST prune itself off the corresponding (S,G) or a (*,G) tree. 3.3. Originating a C-MCAST Join Route at the PE Router The C-MCAST routes on a PE router are originated in BGP as a result of updates in the (C-S,C-G) or (C-*,C-G) state in the associated VRF of a PE router. These states are created by BGP routes learnt from other PEs via the BGP MCAST-VPN SAFI [RFC6514], or from CEs via the C-MCAST SAFI. Whenever a) a particular VRF on a particular PE router creates a new (C-S,C-G) or a (C-*,C-G) state, b) the selected upstream neighbor address identifies a CE, and c) the PE has a direct BGP session to the CE, on which C-MCAST SAFI is enabled, then the PE router MUST originate a C-MCAST Join route from the given VRF. The PE router finds the upstream neighbor address based on the procedures of [RFC6513]. The Route Type field of the NLRI is set to "Source Tree Join" if the corresponding state is (S,G), and to "Shared Tree Join" if the corresponding state is (*,G). Patel, et al. Expires April 7, 2016 [Page 8] Internet-Draft BGP as an MVPN PE-CE Protocol October 2015 The Multicast Source field of the NLRI of a C-MCAST Source Tree Join route MUST be set to the source address of the corresponding (S,G). The multicast source address field of the NLRI of a C-MCAST Shared Tree Join route MUST be set to the address of the RP that is mapped to the corresponding (*,G) state. The Multicast Group field of the NLRI of either kind of C-MCAST Join route MUST be set to the multicast group address of the (S,G) or (*,G) state. The PE router must put its own IP address in the Next Hop field of the C-MCAST Join route. The PE router MUST attach a particular RT to the C-MCAST Join route. This RT MUST be either an IP Address Specific RT or an IPv6 Address Specific RT, depending upon whether the address of the upstream neighbor is an IPv4 address or an IPv6 address. In either case, the address of the upstream neighbor is placed in the Global Administrator field of the RT, and the Local Administrator field is set to 0. (Compare to the "C-multicast Import RT" described in section 7 of [RFC6514].) The "address of the upstream neighbor" MUST be the address that the upstream neighbor puts in the Next Hop field of BGP UPDATEs that it sends to the PE router. The PE MUST send the C-MCAST Join route on the BGP session to the CE that it has selected as the upstream neighbor for the (*,G) or (S,G) identified in the NLRI of the route. Although not required for correctness, it is RECOMMENDED that the C-MCAST Join not be sent on other BGP sessions. How this distribution constraint is met is a local matter. Policy based filtering based on the RT is one possible way to meet the constraint. Use of [RFC4684] is another. Of course, a C-MCAST route originated by a particular PE is originated in the context of a particular VRF, and MUST NOT be advertised to a particular CE unless the interface between that PE and that CE is associated with that VRF. The C-MCAST Shared Tree Join is used to join the shared tree of an "Any Source Multicast" (ASM) group. The C-MCAST Source Tree Join is used in both ASM mode and in "Single Source Multicast" (SSM) mode to join a source tree. The C-MCAST Shared Tree Join can be used to join a BIDIR-PIM [RFC5015] multicast group, as long as the interface between the PE and the CE is a point-to-point interface. If a PE router deletes its (S,G) or a (*,G) entry in the context of a particular VRF, and if there is a currently originated corresponding C-MCAST Join route from that VRF, then that route MUST be withdrawn. The C-MCAST route is withdrawn using the MP_UNREACH_NLRI attribute. If the upstream neighbor of a (S,G) or (*,G) route changes, and if Patel, et al. Expires April 7, 2016 [Page 9] Internet-Draft BGP as an MVPN PE-CE Protocol October 2015 there is a currently originated corresponding C-MCAST Join route, then the RT MUST be changed to identify the new upstream neighbor. 3.4. Receiving a C-MCAST Join Route by the PE Router When a PE router receives a C-MCAST Join route from a CE router, it checks to see if the route carries an IP Address Specific Route Target Extended Community whose Global Administrator field contains the address that the PE puts in the Next Hop field of the BGP UPDATEs it sends to the CE router. If there is no such Route Target, the received route does not impact the PE's multicast state. Otherwise, the received route is used to create or modify the corresponding (S,G) or (*,G) state in the MVPN-TIB ([RFC6514]). The PE-to-CE interface is stored in the outgoing interface list of the corresponding (S,G) or a (*,G) state. If the C-MCAST route is received with the Route Type of Shared Tree Join, then the CE router attaches RP address to the corresponding (*,G) state. If the PE router is connected to the multiple CE routers, it is possible that it will receive C-MCAST routes with the same NLRI from multiple CE routers. In this case, the PE router adds multiple PE- to-CE interfaces to its outgoing interface list, one for each CE router from which the given route was received. (Note that a particular PE-to-CE interface is added only if the route from the corresponding CE identifies the PE in its IP Address Specific RT.) When the last C-MCAST route for a given (S,G) or a (*,G) is withdrawn, resulting in a state where BGP C-MCAST SAFI has no route for a given (S,G) or a (*,G) state, the withdrawal of the route has the (S,G) or a (*,G) prune semantics. The corresponding MCAST-VPN route is withdrawn using the MP_UNREACH_NLRI attribute. 4. Pruning Sources off the Shared Tree Suppose a router, say R1, has originated a C-MCAST Source Tree Join A-D route for (*,G), and has identified another router, say R2, in that route's RT. Under certain conditions, R1 may need to prune a particular source, say S1, off the (*,G) tree. To do so, R1 originates a C-MCAST Prune Source A-D route whose NLRI contains S1 in the multicast source field and G in the multicast group field. This route MUST have the same IP Address Specific RT (identifying R2), and the same Next Hop field, as the corresponding C-MCAST Source Tree Join A-D route. This route MUST be sent on the BGP session to R2. It is RECOMMENDED that it not be sent on other BGP sessions. Note that either R1 is a CE and R2 is a PE, or vice versa. The procedures are the same in either case. When R1 no longer needs to prune S1 from the (*,G) tree, R1 MUST withdraw the (S1,G) Source Prune route. If R1 changes the RT on the (*,G) Shared Tree Join route, it MUST change the RT on all the corresponding (S,G) Source Prune routes. If Patel, et al. Expires April 7, 2016 [Page 10] Internet-Draft BGP as an MVPN PE-CE Protocol October 2015 R1 withdraws the (*,G) Shared Tree Join route, it MUST also withdraw all the corresponding (S,G) Source Prune routes. When a router withdraws a Source Tree Join route for (*,G), it MUST withdraw all its Source Prune (S,G) routes. A received Source Prune (S,G) route does not impact a router's multicast state unless there is a the router has also received a Shared Tree Join (*,G) route over the same BGP session. However, a router should handle the case where one or more Source Prune routes are received before the corresponding Shared Tree Join route. Further details will be provided in future revisions of this document. 5. IANA Considerations This document define a new SAFI called "C-MCAST SAFI". IANA is requested to allocate a code point for C-MCAST SAFI. 6. Security Considerations This extension to BGP does not change the underlying security issues inherent in the existing [RFC4271] and [RFC6514]. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, DOI 10.17487/RFC4601, August 2006, . [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, . Patel, et al. Expires April 7, 2016 [Page 11] Internet-Draft BGP as an MVPN PE-CE Protocol October 2015 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR- PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, . [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 2009, . [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, . [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, . 7.2. Informative References [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, R., Patel, K., and J. Guichard, "Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, November 2006, . Authors' Addresses Keyur Patel Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA Email: keyupate@cisco.com Eric C. Rosen Juniper Networks 10 Technology Park Drive Westford, MA 01886 USA Email: erosen@juniper.net Yakov Rekhter Patel, et al. Expires April 7, 2016 [Page 12]