Network Working Group Zhang Internet-Draft Giuliano Intended status: Informational Juniper Networks Expires: January 13, 2014 Pacella Verizon Schiller Google July 12, 2013 Global Table Multicast with BGP-MVPN Procedures draft-zzhang-l3vpn-mvpn-global-table-mcast-00.txt Abstract This document describes a way to implement Global Table Multicast, aka Internet Multicast, using BGP encodings and procedures for MVPN as specified in [RFC6514]. No protocol modification/extension is required. This is purely for informational and clarifying purposes only. 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 January 13, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. 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 Zhang, et al. Expires January 13, 2014 [Page 1] Internet-Draft Global Table Multicast with BGP-MVPN July 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Considerations for GTM with BGP-MVPN . . . . . . . . . . . 6 3.2. IBGP session between MBRs and non-MBRs . . . . . . . . . . 6 3.3. Non-BGP UMH Routes or BGP UMH routes not originated by the MBRs . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Zhang, et al. Expires January 13, 2014 [Page 2] Internet-Draft Global Table Multicast with BGP-MVPN July 2013 1. Introduction [RFC6513] and [RFC6514] specify procedures and encodings to implement Multicast for L3VPNs (MVPN). [RFC6513] specifies general concepts and procedures that apply to PIM-based and/or BGP-based C-Multicast State Signaling (referred to PIM-MVPN and BGP-MVPN respectively), and [RFC6514] specifies BGP procedures and encodings used by both PIM- MVPN and BGP-MVPN. While [RFC6513] and [RFC6514] assume the context of VPN, they can be used to implement Global (vs. VRF) Table Multicast as well, without any protocol modification/extension, even though the RFCs do not explicitly mention it. Consider a provider network in which the "core" part of it uses MPLS P2MP LSPs or Ingress Replication over either P2P LSPs (with RSVP-TE) or MP2P LSPs (with LDP) instead of PIM to carry multicast traffic among the MPLS Border Routers (MBRs) of the core. Those MBRs run PIM on interfaces connected to other routers outside the core. This document describes how Global Table Multicast can be implemented using BGP-MVPN procedures. We start with a simple reference scenario below, and also discuss one slightly different scenario and another special one. With Global Table Multicast (GTM) implemented by BGP-MVPN procedures, most of the features/characteristics of BGP-MVPN apply, including scaling, aggregation, flexible choice of provider tunnels, wild-card S-PMSI, support for PIM-DM/ASM/SSM/Bidir as PE-CE multicast protocol, support for both IPv4 and IPv6 with IPv4 infrastructure, support for unsolicited flooded data, including support for BSR as RP-to-group mapping protocols, etc. While it is different from the GTM procedure specified in [seamless-mcast], the two can co-exist. In the rest of the document, the term MBR (MPLS Border Router) is used to denote a router that runs BGP-MVPN procedures for Global Table Multicast, analogous to a PE in a true VPN Environment. In other words, MBRs border the BGP-MVPN domain, which could even be inter-AS. Zhang, et al. Expires January 13, 2014 [Page 3] Internet-Draft Global Table Multicast with BGP-MVPN July 2013 2. Requirements Language 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]. Zhang, et al. Expires January 13, 2014 [Page 4] Internet-Draft Global Table Multicast with BGP-MVPN July 2013 3. Operation In the simplest reference scenario, PIM runs between the MBRs and their adjacent non-MBRs, and the MBRs advertise to each other Reverse Path Forwarding (RPF) routes to multicast sources via iBGP (with or without RRs in the middle) with Next Hop set to themselves. The routes are learned from routers outside of the core via eBGP or IGP. Note that with BGP-MVPN, the RPF routes are referred to as UMH (Upstream Multicast Hop) Routes. In this document the two terms are used interchangeably. Conceptually and functionally, those MBRs resemble MVPN PEs: connections to other routers outside the core can be treated as PE-CE interfaces and MVPN procedures can run among the PEs (i.e., MBRs) for Discovery, Tunnel Binding, and Multicast State Signaling. RFC 6514 specifies that MCAST-VPN I/S-PMSI A-D routes and Source Active A-D routes carry certain Route Targets, allowing them to be imported into appropriate VRFs. By default, the Route Targets are the same as for unicast routing, but any configured set of Route Targets can be used. For GTM using procedures in this document, Route Targets are used to associate the A-D routes with GTM the same way as a configured set of Route Targets are used as specified in RFC 6514. By default, an (auto-)configured Route Target is used: an IPv4 Address Specific Extented Community with both the Global and Local Administrative Fields being 0. RFC 6514 specifies that MCAST-VPN routes carry a Route Distinguisher (RD). For GTM, it SHOULD be possible to configure an RD that is used only for MCAST-VPN A-D routes for the global table. The RD can be defaulted to a special 64-bit all-zero value (denoted as RD 0:0). Note that RD 0:0 is not valid as a VRF RD, and unlike in [seamless-mcast] the use of RD 0:0 per this docuement does not modify the semantics of any BGP route in which it appears. Obviously, while using RD 0:0 per this document, the GTM procedures specified in [seamless-mcast] cannot be used for the global table. Unlike in VPN case, the unicast routes in global table are not advertised with RDs. As a result, for C-multicast routes, the above mentioned configured RD value (including the special RD 0:0) is used when the originating MBR and the Upstream MBR is in the same AS. For comparison, RFC 6514 specifies in section 11.1.3 that the RD of the VPN-IP route is used. Additionally, due to the lack of RD in the unicast route advertisements, an egress PE may not receive all advertisements from all the MBRs that a multicast source or RP is multi-homed to. This may be the case even when BGP add-path is used. As a result, the Zhang, et al. Expires January 13, 2014 [Page 5] Internet-Draft Global Table Multicast with BGP-MVPN July 2013 Single Forwarder Selection procedure in RFC 6513 may not guarantee that all egress MBRs select the same Upstream MBR. Therefore, procedures in Section 9.1.1 of RFC 6513 MUST be used to ensure that an egress PE only forward traffic sent by the Upstream MBR that it selects. When an MBR advertises UMH routes via BGP over the core, it attaches a VRF Route Import Extended Community and Source AS Extended Community. as specified in Section 7 of RFC 6514. When constructing the C-multicast Import RT as specified in Section 7 of [RFC6514], it is RECOMMENDED that the Local Administrator field is set to 0, though an implementation MAY use any value that can uniquely associate it to the global routing table (vs. a VRF). 3.1. Considerations for GTM with BGP-MVPN The following should be considered when using BGP-MVPN for GTM. o As mentioned above, Single Forwarder Selection procedure cannot be used. This is a limitation when multiple MBRs may be the Upstream MBR for the same source or RP. o There are potentially many more MBRs for GTM than PEs for a particular VPN. As a result, use of inclusive tunnels should be avoided (or with fan-out reduced by using tunnel segmentation as specified in [seamless-mcast]). o Internet providers often make extensive use of BGP communities (ie, adding, deleting, modifying communities throughout a network). As such, care should be taken to avoid deleting or modifying the VRF Route Import Extended Community and Source AS Extended Community. 3.2. IBGP session between MBRs and non-MBRs In the simple reference scenario above, it is assumed that the MBRs learn UMH routes from non-MBRs via eBGP or IGP. This assumption helps illustrate the analogy to a true VPN environment. In a different deployment scenario, the MBRs could have learned the UMH routes over iBGP sessions to non-MBRs. If the MBRs act as RRs and reflect the UMH routes to other MBRs with polices to attach VRF Route Import Extended Community and Source AS Extended Community, BGP-MVPN procedures can still be used as described earlier. Even if the MBRs do not act as RRs, the scenario could be considered analogous to what [RFC6368] describes. As long as MBRs re-advertise those UMH routes with the above mentioned communities, BGP-MVPN procedures can be used as described earlier. Note that they do not even need to use the push/pop procedures in [RFC6368] - the only requirement is for the Zhang, et al. Expires January 13, 2014 [Page 6] Internet-Draft Global Table Multicast with BGP-MVPN July 2013 MBRs to re-advertise the routes learned over iBGP sessions from non- MBRs to other MBRs over iBGP sessions. 3.3. Non-BGP UMH Routes or BGP UMH routes not originated by the MBRs With true MVPN, the PEs advertise the UMH routes themselves as VPN-IP routes, and attach a VRF Route Import Extended Community that has the C-multicast Import RT value for the VRF associated with the routes. The VRF Route Import Extended Community is extracted by egress PEs and attached to their C-Multicast Routes as Route Target Extended Community to control the distribution to and importation by relevant upstream PEs. With Global Table Multicast, in both the simple reference scenario and the above mentioned variance, the MBRs do (re-)advertise the UMH routes as required for BGP-MVPN. However, in other situations, it is possible that the UMH routes are not advertised by the MBRs via BGP at all, hence they may not carry the VRF Route Import Extended Community. Consider the following example: |---- Site 1 -------| EBGP src----R3------R1/CE1 -------MBR1/PE1 \ /| |\ / | | \IBGP / | | \ / | | \ / | | X | | / \ | | / \ | | /mesh \ | |/ \ | / \| rcv----R4------R2/CE2 -------MBR2/PE2 EBGP |---- Site 2 -------| There is a full-mesh of IBGP sessions among provider routers R1/MBR1/ MBR2/R2. EBGP sessions run between R3/R1 and between R4/R2. MBR1/ MBR2 run BGP-MVPN procedures for Global Table Multicast. R1 learns of BGP route to the source from R3 and advertises it to MBRx/R2. Zhang, et al. Expires January 13, 2014 [Page 7] Internet-Draft Global Table Multicast with BGP-MVPN July 2013 Because R1 does not run MVPN, MBR2's route to the source (learned from R1 instead of MBR1) does not have the VRF Route Import Extended Community. Therefore, it would not be able to correctly attach a Route Target Extended Community corresponding to MBR1 in its C-Multicast Routes. To handle that situation, MBR2 performs the following recursively to potentially identify the Upstream MBR and derive a VRF Route Import Extended Community. Note that the route in the following procedure is either the UMH-eligible route for the source itself, or the route to the Next Hop of the BGP route in the previous recursion. o If the route is a BGP route with a VRF Route Import Extended Community, that VRF Route Import Extended Community is used. o If the route is a BGP route without a VRF Route Import Extended Community, get the route to the Next Hop and recurse. o If the route is an IGP route with a RSVP-TE LSP as next hop, and the LSP endpoint is a MBR (MBR1 in the above example) that advertises an Intra-AS I-PMSI or an S-PMSI A-D route, a VRF Route Import Extended Community is constructed as MBR_addr:0 to be associated with the UMH-eligible route, where the MBR_addr is the Originating Router's IP Address of the Intra-AS I-PMSI or S-PMSI A-D route. Constructing the VRF Route Import as MBR_addr:0 by an egress MBR in the above special situation explains why it is RECOMMENDED that the Local Administrator is set to 0 when an upstream MBR constructs its C-Multicast Import RT - the zero value is a special value agreed on apriori by all (vs. a local value that is normally picked by the upstream MBR and signaled via the VRF Route Import Extended Community). If the above procedure does not produce a usable VRF Route Import Extended Community, then the UMH route is considered a local route (vs. a remote route that is associated with an Upstream MBR). If the UMH is indeed remote (over the core) but considered as local by the above procedure, then the above scenario will obviously not work. Note that the above procedure is necessary only if the MBRs (that run MVPN procedures) do not advertise the UMH routes via BGP and include VRF Route Import Extended Community in such routes. The egress MBRs can obtain/derive the VRF Route Import Extended Community as long as the UMH-eligible route is or resolves recursively to one of the folllowing: Zhang, et al. Expires January 13, 2014 [Page 8] Internet-Draft Global Table Multicast with BGP-MVPN July 2013 o A BGP route that carries a VRF Route Import Extended Community (this route could even be to an MBR and advertised by the MBR itself). Or, o An IGP route with a RSVP-TE LSP as next hop, and the LSP endpoint matches the Originating Router's IP Address of an Intra-AS I-PMSI or S-PMSI A-D route. Zhang, et al. Expires January 13, 2014 [Page 9] Internet-Draft Global Table Multicast with BGP-MVPN July 2013 4. Security Considerations This document raises no new security issues. Security considerations for the base protocols are covered in [RFC6514], [RFC4601], and [RFC5294]. Zhang, et al. Expires January 13, 2014 [Page 10] Internet-Draft Global Table Multicast with BGP-MVPN July 2013 5. IANA Considerations This document has no IANA considerations. This section should be removed by the RFC Editor prior to final publication. Zhang, et al. Expires January 13, 2014 [Page 11] Internet-Draft Global Table Multicast with BGP-MVPN July 2013 6. Acknowledgements The authors would like to thank Rahul Aggarwal, Yakov Rehkter and Eric Rosen for their comments and suggestions. Zhang, et al. Expires January 13, 2014 [Page 12] Internet-Draft Global Table Multicast with BGP-MVPN July 2013 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", RFC 6513, 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, February 2012. [RFC6625] Rosen, E., Rekhter, Y., Hendrickx, W., and R. Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", RFC 6625, May 2012. 7.2. Informative References [RFC6368] Marques, P., Raszuk, R., Patel, K., Kumaki, K., and T. Yamagata, "Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 6368, September 2011. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [RFC5294] Savola, P. and J. Lingard, "Host Threats to Protocol Independent Multicast (PIM)", RFC 5294, August 2008. [seamless-mcast] Rekhter, Y., "Inter-Area P2MP Segmented LSPs", draft-ietf-mpls-seamless-mcast-06.txt. Zhang, et al. Expires January 13, 2014 [Page 13] Internet-Draft Global Table Multicast with BGP-MVPN July 2013 Authors' Addresses Jeffrey Zhang Juniper Networks 10 Technology Park Dr. Westford, MA 01886 US Email: zzhang@juniper.net Lenny Giuliano Juniper Networks 2251 Corporate Park Drive Herndon, VA 20171 US Email: lenny@juniper.net Dante J. Pacella Verizon Verizon Communications 22001 Loudoun County Parkway Ashburn, VA 20147 US Email: dante.j.pacella@verizonbusiness.com Jason Schiller Google 1818 Library Street Suite 400 Reston, VA 20190 US Email: jschiller@google.com Zhang, et al. Expires January 13, 2014 [Page 14]