L3VPN Working Group IJsbrand Wijnands Internet Draft Eric C. Rosen Intended Status: Proposed Standard Cisco Systems, Inc. Updates: 6514 Expires: March 8, 2015 Uwe Joorde Deutsche Telekom September 8, 2014 Encoding mLDP FECs in the NLRI of BGP MCAST-VPN Routes draft-ietf-l3vpn-mvpn-mldp-nlri-06.txt Abstract Many service providers offer "BGP/MPLS IP VPN" service to their customers. Existing IETF standards specify the procedures and protocols that a service provider uses in order to offer this service to customers who have IP unicast and IP multicast traffic in their VPNs. It is also desirable to be able to support customers who have MPLS multicast traffic in their VPNs. This document specifies the procedures and protocol extensions that are needed to support customers who use the Multicast Extensions to Label Distribution Protocol (mLDP) as the control protocol for their MPLS multicast traffic. Existing standards do provide some support for customers who use mLDP, but only under a restrictive set of circumstances. This document generalizes the existing support to include all cases where the customer uses mLDP, without any restrictions. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." Wijnands, et al. [Page 1] Internet Draft draft-ietf-l3vpn-mvpn-mldp-nlri-06.txt September 2014 The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright and License Notice Copyright (c) 2014 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 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 Why This Document is Needed ........................... 4 3 Encoding an mLDP FEC in the MCAST-VPN NLRI ............ 5 4 Wildcards ............................................. 7 5 IANA Considerations ................................... 7 6 Security Considerations ............................... 10 7 Acknowledgments ....................................... 10 8 Authors' Addresses .................................... 10 9 Normative References .................................. 11 10 Informative References ................................ 11 Wijnands, et al. [Page 2] Internet Draft draft-ietf-l3vpn-mvpn-mldp-nlri-06.txt September 2014 1. Introduction Many service providers (SPs) offer "BGP/MPLS IP VPN" service to their customers. When a customer has IP multicast traffic in its VPN, the service provider needs to signal the customer multicast states across the backbone. A customer with IP multicast traffic is typically using PIM ("Protocol Independent Multicast") [PIM] and/or IGMP ("Internet Group Management Protocol") [IGMP] as the multicast control protocol in its VPN. The IP multicast states of these protocols are commonly denoted as "(S,G)" and/or "(*,G)" states, where "S" is a multicast source address and "G" is a multicast group address. [MVPN-BGP] specifies the way an SP may use BGP to signal a customer's IP multicast states across the SP backbone. This is done by using "Multiprotocol BGP" Updates whose "Subsequent Address Family" (SAFI) value is "MCAST-VPN" (5). The NLRI ("Network Layer Reachability Information") field of these Updates includes a customer Multicast Source field and a customer Multicast Group field, thus enabling the customer's (S,G) or (*,G) states to be encoded in the NLRI. It is also desirable for the BGP/MPLS IP VPN service to be able to support customers who are using MPLS multicast, either instead of, or in addition to, IP multicast. This document specifies the procedures and protocol extensions needed to support customers who use mLDP ("Multicast Extensions to Label Distribution Protocol") [mLDP] to create and maintain Point-to-Multipoint (P2MP) and/or Multipoint-to- Multipoint (MP2MP) Label Switched Paths (LSPs). While mLDP is not the only protocol that can be used to create and maintain multipoint LSPs, consideration of other MPLS multicast control protocols is outside the scope of this document. When a customer is using mLDP in its VPN, the customer multicast states associated with mLDP are denoted by an mLDP "FEC Element" ("Forwarding Equivalance Class element", see [mLDP]), instead of by an (S,G) or (*,G). Thus it is necessary to have a way to encode a customer's mLDP FEC Elements in the NLRI field of the BGP MCAST-VPN routes. While [MVPN-BGP] does specify a way of encoding an mLDP FEC Element in the MCAST-VPN NLRI field, the encoding specified therein makes a variety of restrictive assumptions about the customer's use of mLDP. (These assumptions are described in section 2 of this document.) The purpose of this document is to update [MVPN-BGP] so that customers using mLDP in their VPNs can be supported even when those assumptions do not hold. Some SPs use the MVPN procedures to provide "global table multicast" service (i.e., multicast service that is not in the context of a VPN) Wijnands, et al. [Page 3] Internet Draft draft-ietf-l3vpn-mvpn-mldp-nlri-06.txt September 2014 to customers. Methods for doing this are specified in [GTM] and in [SEAMLESS-MCAST]. The procedures described in this document can be used along with the procedures of [GTM] or [SEAMLESS-MCAST] to provide global table multicast service to customers that use MPLS multicast in a global table context. 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. Why This Document is Needed An mLDP FEC Element consists of a FEC Type, a Root Node, and an Opaque Value. mLDP uses several FEC types, and in particular, uses the FEC type to distinguish between P2MP LSPs and MP2MP LSPs. Section 11.1.2 of [MVPN-BGP] ("Originating routes: mLDP as the C- multicast control protocol") states: Whenever a PE ("Provider Edge" router) receives from one of its CEs ("Customer Edge" routers) a P2MP Label Map over interface I, where X is the Root Node Address, Y is the Opaque Value, and L is an MPLS label ... the PE constructs a Source Tree Join C-multicast route whose MCAST-VPN NLRI contains X as the Multicast Source field, and Y as the Multicast Group field. In other words, the Root Node of the mLDP FEC Element appears in the Multicast Source Field, and the Opaque Value of the mLDP FEC Element appears in the Multicast Group field. This method of encoding an mLDP FEC in an MCAST-VPN NLRI can only be used if all of the following conditions hold: 1. A customer using mLDP is not also using PIM/IGMP. The encoding in [MVPN-BGP] does not specify any way in which one can determine, upon receiving a BGP Update, whether the Multicast Group field contains an IP address or whether it contains an mLDP FEC Element Opaque Value. Therefore it might not uniquely identify a customer multicast state if the customer is using both PIM/IGMP and mLDP in its VPN. 2. A customer using mLDP is using only the mLDP P2MP FEC Element, and is not using the mLDP MP2MP FEC Element. The encoding in [MVPN-BGP] does not specify any way to encode the type of the mLDP FEC Element; it just assumes it to be a Wijnands, et al. [Page 4] Internet Draft draft-ietf-l3vpn-mvpn-mldp-nlri-06.txt September 2014 P2MP FEC Element. 3. A customer using mLDP is using only an mLDP Opaque Value type for which the Opaque Value is exactly 32 bits or 128 bits long. The use of Multicast Group fields that have other lengths is declared by [MVPN-BGP] to be "out of scope" of that document (see, e.g., section 4.3 of that document). This condition holds if the customer uses only the mLDP "Generic LSP Identifier" Opaque Value type (defined in [mLDP]). However, mLDP supports many other Opaque Value types whose length is not restricted to be 32 or 128 bits. The purpose of this document is to update [MVPN-BGP] so that customers using mLDP can be supported, even when these conditions do not hold. 3. Encoding an mLDP FEC in the MCAST-VPN NLRI When mLDP is used as the customer multicast control protocol, [MVPN- BGP] presupposes that an mLDP FEC element will be encoded in the NLRI of the following three MCAST-VPN route types: - C-multicast Source Tree Join, - S-PMSI A-D route, and - Leaf A-D route. The other four MCAST-VPN route types defined in [MVPN-BGP] do not ever need to carry mLDP FEC Elements. The C-multicast Shared Tree Join route and the Source Active A-D route are used to communicate state about unidirectional shared trees; since mLDP does not have unidirectional shared trees, these routes are not used to signal mLDP states. The Intra-AS I-PMSI A-D route and the Inter-AS I-PMSI A-D route do not identify specific customer multicast states, and hence do not carry any information that is specific to the customer's multicast control protocol. This document defines three new route types: - C-Multicast Source Tree Join route for C-multicast mLDP Wijnands, et al. [Page 5] Internet Draft draft-ietf-l3vpn-mvpn-mldp-nlri-06.txt September 2014 - S-PMSI A-D route for C-multicast mLDP - Leaf A-D route for C-multicast mLDP. The term "C-multicast mLDP" in the names of these route types is intended to indicate that the NLRI of these route contains mLDP FEC elements. Each of these route types corresponds to a route type defined in [MVPN-BGP]. IANA has been requested to allocate codepoints for these three route types such that (a) the high order two bits have the value 0x01, and (b) the low order bit six bits have the same value as the codepoints for the corresponding route types from [MVPN-BGP]. In general, the procedures defined in other MVPN specifications for the C-Multicast Source Tree Join route, the S-PMSI A-D route, and the Leaf A-D route apply as well to the C-Multicast Source Tree Join route for C-multicast mLDP, the S-PMSI A-D route for C-multicast mLDP, and the Leaf A-D route for C-multicast mLDP, respectively. However, the NLRI of these three new route types is constructed differently than the NLRI of the corresponding routes from [MVPN- BGP]: the "Multicast Source Length", "Multicast Source", "Multicast Group Length", and "Multicast Group" fields are omitted, and in their place is a single mLDP FEC Element, as defined in [mLDP]. (See section 2.2 of [mLDP] for a diagram of the mLDP FEC element.) As a result, the NLRI of an S-PMSI A-D route for C-multicast mLDP will consist of a Route Distinguisher, followed by the mLDP FEC, followed by the "Originating Router's IP Address Field". The NLRI of a C-multicast Source Tree Join route for C-multicast mLDP will consist of a Route Distinguisher, followed by the Source AS, followed by the mLDP FEC. In a Leaf A-D route for C-multicast mLDP that has been derived from an S-PMSI A-D route for C-multicast mLDP, the "route key" field remains the NLRI of the S-PMSI A-D route from which it was derived. In a Leaf A-D route for C-multicast mLDP that has not been derived from an S-PMSI A-D, the "route key" field is as specified in [SEAMLESS-MCAST], except that the "Multicast Source Length", "Multicast Source", "Multicast Group Length", and "Multicast Group" fields are omitted, and in their place is a single mLDP FEC Element. Thus the route key field consists of a Route Distinguisher, an MLDP FEC element, and the IP address of the Ingress PE router. Please note that [BGP-ERR] section 4.3 ("Typed NLRI") is applicable if the Route Type field of the NLRI of a received MCAST-VPN route Wijnands, et al. [Page 6] Internet Draft draft-ietf-l3vpn-mvpn-mldp-nlri-06.txt September 2014 contains an unrecognized value. An mLDP FEC element contains an "address family" field whose value is from IANA's "Address Family Numbers" registry. The value of the "address family" field identifies the address family of the "root node address" field of the FEC element. When an mLDP FEC element is encoded into the NLRI of an a BGP update whose SAFI is MCAST-VPN, the address family of the root node address (as indicated in the FEC element) MUST "correspond to" the address family that is identified in the "Address Family Identifier" (AFI) field of that BGP update. These two "address family" fields are considered to "correspond" to each other under the following conditions: - they contain identical values, or - the BGP update's AFI field identifies IPv4 as the address family, and the mLDP FEC element identifies "Multi-Topology IPv4" as the address family of the root node, or - the BGP update's AFI field identifies IPv6 as the address family, and the mLDP FEC element identifies "Multi-Topology IPv6" as the address family of the root node. For more information about the "multi-topology" address families, see [LDP-MT] and [mLDP-MT]. 4. Wildcards [MVPN-WILDCARDS] specifies encodings and procedures that allow "wildcards" to be specified in the NLRI of S-PMSI A-D routes. A set of rules are given that specify when a customer multicast flow "matches" a given S-PMSI A-D route whose NLRI contains wildcards. However, the use of these wildcards is defined only for the case where the customer is using PIM as its multicast control protocol. The use of wildcards when the customer is using mLDP as its multicast control protocol is outside the scope of this document. 5. IANA Considerations [MVPN-BGP] does not create a registry for the allocation of new MCAST-VPN Route Type values. In retrospect, it seems that it should have done so. IANA is requested to create a new registry called "BGP MCAST-VPN Route Types", referencing this document and [MVPN-BGP]. The allocation policy should be "Standards Action". Values may be assigned from one of several ranges: Wijnands, et al. [Page 7] Internet Draft draft-ietf-l3vpn-mvpn-mldp-nlri-06.txt September 2014 - Range 0x01-0x3f: Generic/PIM Range. Values are assigned from this range when the NLRI format associated with the route type presupposes that PIM or IGMP is the C-multicast control protocol, or when the the NLRI format associated with the route type is independent of the C-multicast control protocol. - Range 0x41-0x7f: mLDP Range. Values are assigned from this range when the NLRI format associated with the route type presupposes that mLDP is the C-multicast control protocol. - Range 0x80-0xff: This range is reserved; values should not be assigned from this range. In general, whenever an assignment is requested from this registry, two codepoints should be requested at the same time: one from the Generic/PIM range and one from the mLDP range. The two codepoints should have the same low-order 5 bits. If one of the two codepoints is not actually needed, it should be registered anyway, and marked as "reserved (not to be assigned)". When the BGP MCAST-VPN Route Types registry is created, it should contain the following assignments: Wijnands, et al. [Page 8] Internet Draft draft-ietf-l3vpn-mvpn-mldp-nlri-06.txt September 2014 Value Meaning Reference 0x00 Reserved (not to be assigned) This RFC 0x01 Intra-AS I-PMSI A-D route This RFC, RFC6514 0x02 Inter-AS I-PMSI A-D route This RFC, RFC6514 0x03 S-PMSI A-D route This RFC, RFC6514 0x04 Leaf A-D route This RFC, RFC6514 0x05 Source Active A-D route This RFC, RFC6514 0x06 Shared Tree Join route This RFC, RFC6514 0x07 Source Tree Join route This RFC, RFC6514 0x08-0x3f Unassigned (Generic/PIM range) This RFC 0x40-0x42 Reserved (not to be assigned) This RFC 0x43 S-PMSI A-D route for C-multicast mLDP This RFC 0x44 Leaf A-D route for C-multicast mLDP This RFC 0x45-0x46 Reserved (not to be assigned) This RFC 0x47 Source Tree Join route for C-multicast mLDP This RFC 0x48-0x7f Unassigned (mLDP range) This RFC 0x80-0xff Reserved (not to be assigned) This RFC Wijnands, et al. [Page 9] Internet Draft draft-ietf-l3vpn-mvpn-mldp-nlri-06.txt September 2014 6. Security Considerations This document specifies a method of encoding an mLDP FEC element in the NLRI of some of the BGP Update messages that are specified in [MVPN-BGP]. The security considerations of [mLDP] and of [MVPN-BGP] are applicable, but no new security considerations are raised. 7. Acknowledgments The authors wish to thank Pradosh Mohapatra and Saquib Najam for their ideas and comments. We also thank Yakov Rekhter and Martin Vigoureux for their comments. 8. Authors' Addresses IJsbrand Wijnands Cisco Systems, Inc. De kleetlaan 6a Diegem 1831 Belgium E-mail: ice@cisco.com Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA, 01719 E-mail: erosen@cisco.com Uwe Joorde Deutsche Telekom Hammer Str. 216-226 D-48153 Muenster, Germany E-mail: Uwe.Joorde@telekom.de Wijnands, et al. [Page 10] Internet Draft draft-ietf-l3vpn-mvpn-mldp-nlri-06.txt September 2014 9. Normative References [mLDP] "Label Distribution Protocol Extensions for Point-to- Multipoint and Multipoint-to-Multipoint Label Switched Paths", Wijnands, Minei, Kompella, Thomas, RFC 6388, November 2011 [MVPN-BGP] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", Aggarwal, Rosen, Morin, Rekhter, RFC 6514, February 2012 [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels.", Bradner, RFC 2119, March 1997 10. Informative References [BGP-ERR] "Revised Error Handling for BGP UPDATE Messages", Chen, Scudder, Mohapatra, Patel, draft-ietf-idr-error-handling-14.txt, September 2014 [GTM] "Global Table Multicast with BGP-MVPN Procedures", Zhang, Giuliano, Rosen, Subramanian, Pacella, Schiller, draft-ietf-l3vpn- mvpn-global-table-mcast-00.txt, June 2014 [IGMP] "Internet Group Management Protocol, Version 3", Cain, Deering, Kouvelas, Fenner, Thyagarajan, RFC 3376, October 2002 [LDP-MT] "LDP Extensions for Multi-Topology", Zhao, et. al., RFC 7307, July 2014 [mLDP-MT] "mLDP Extensions for Multi Topology Routing", Wijnands, Raza, draft-iwijnand-mpls-mldp-multi-topology-03.txt, June 2013 [MVPN-WILDCARDS], "Wildcards in Multicast VPN Auto-Discovery Routes", Rosen, Rekhter, Hendrickx, Qiu, RFC 6625, May 2012 [PIM] "Protocol Independent Multicast - Sparse Mode (PIM-SM)", Fenner, Handley, Holbrook, Kouvelas, August 2006, RFC 4601 [SEAMLESS-MCAST] "Inter-Area P2MP Segmented LSPs", Rekhter, Aggarwal, Morin, Grosclaude, Leymann, Saad, draft-ietf-mpls-seamless- mcast-14.txt, July 2014 Wijnands, et al. [Page 11]