MPLS Working Group Richard.Li Internet-Draft Katherine.Zhao Intended status: Proposed Standard Robin.Li Expires: April 20, 2014 Huawei Technologies October 20, 2013 MPLS Big Label Usecases and Requirements draft-mpls-big-label-ucase-req-00.txt Abstract This document describes usecases and requirements for MPLS big label. The MPLS label format and encoding method have been specified in [RFC 3032], the label value is represented by 20-bit space and support up to 1 million of instances. This proven technology has been widely deployed and worked fine for years. However in certain network deployment scenarios of recent years, the 20-bit MPLS label space is no longer sufficient to support the widespread adoption of network virtualization technologies. In what follows we will describe each of the usecase respectively 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 01, 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 Li, et al. Expires April 20, 2014 [Page 1] Internet-Draft MPLS Big Label Usecases and Requirements October 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirement Language . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Big Label Usecase for VPN . . . . . . . . . . . . . . . . . . 4 2.1. MPLS Based L3VPN with VXLAN . . . . . . . . . . . . . . . 4 2.2. MPLS Based L3VPN with NVGRE . . . . . . . . . . . . . . . 6 2.3. MPLS Based L2VPN . . . . . . . . . . . . . . . . . . . . . 7 3. Usecase of MRT MT and FRR . . . . . . . . . . . . . . . . . . 8 4. Usecase of Segment Routing . . . . . . . . . . . . . . . . . . 9 5. NVO3 Usecase . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Big Label Requirements . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction MPLS label format and encoding method have been specified in [RFC 3032] for more than 10 years. The MPLS label value is represented by 20-bit space that can support up to 1 million of instances. This proven technology has been widely deployed and worked fine for years. However in the recent years the widespread adoption of network virtualization especially SDN technologies are being designed and deployed in data center networks, which have culminated in a new set Li, et al. Expires April 20, 2014 [Page 2] Internet-Draft MPLS Big Label Usecases and Requirements October 2013 of requirements to the label space, a physical network can be used to support up to 16 millions of instances of virtualized overlaid networks. When the MPLS/IP L2/L3 VPN reference model is extended to interconnect multiple customer sites and data centers, the 20-bit space for MPLS label value is not readily to address the demanding of new usecases and requirements. There a few drafts have proposed the methods to expand the MPLS label space and the methods to encoding the packet. Typical drafts are following three: 1. Encoding of Big Labels in MPLS Label Stacks [1] 2. Mega Label - Expansion of MPLS Label Range in [2] 3. MPLS Context-Specific Label Space [3] However before we move onto discussions about how to expand the label space, a question for the usecases and requirements needs to be answered. Another usecases of big label could come from MRT MT FRR (Maximally Redundant Trees Multi-topology Fast Reroute) and Segment Routing applications. In what follows we will describe each of use case in L3VPN, L2VPN, MRT MT FRR and Segment Routing etc areas, and the according requirements 1.1. Requirement 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 RFC 2119 [RFC2119]. 1.2. Terminology The following terms are used in this document: VXLAN - Virtual eXtensible Local Area Network NVGRE - Network Virtualization using Generic Routing Encapsulation NVO3 - Network Virtualization Over layer 3 MPLS - Multiprotocol Label Switching VPN - Virtual private network PE - Provider Edge CE - Customer Edge VRF - Virtual Routing and Forwarding NVE - Network Virtualization Edge VTEP - VXLAN Tunnel End Point VNI - VXLAN Network Identifier (VXLAN) VSID -Virtual Subnet ID (NVGRE) VNID - Virtual Network ID (NVO3) VLAN - Virtual Local Area Network Li, et al. Expires April 20, 2014 [Page 3] Internet-Draft MPLS Big Label Usecases and Requirements October 2013 2. Big Label Usecase for VPN VPN technology allows customer to connect geographically diverse sites and data centers across core networks with ensured performance and security. There are many methods designed for VPN connectivity, this document will discuss usecases of the MPLS/IP based VPNs. In the MPLS/IP VPN reference model, at each site there are one or more Customer Edge (CE) devices, each of which is attached to one or more Provider Edge (PE) routers via some sort of attachment circuit such as PPP, Ethernet/VLAN, etc. When the MPLS IP VPNs reference model is extended to connect to a virtual network, the CE devices and PE devices on the data center site can be physically the same device: it will be both the PE device with respect to the VPN model and the NVE device with respect to the network virtualization. With different network protocol used in the data center, for example VXLAN and NVGRE as well as NVO3, the encoding method of each protocol is different but they all use 24-bit space to represent the virtual network instances, which bring up a new requirement for MPLS to support 24-bit label space. A question comes out: why we need to use one-to-one mapping between a MPLS label and virtual network id? It is true that some label sharing method was used to aggregate multiple VNIs into a single MPLS label, which saves the number of MPLS labels and avoid an one-to-one mapping between a MPLS label and virtual network id. However one-to- many mapping always involves extra algorithm like hashing/lookups etc therefor adds overhead to packet encapsulation that impacts the performance. Moreover, some deployment uses specific flow identification that does not allow the label sharing/aggregation. To ensure efficient traffic distribution in virtual network, there is a clear need to expand MPLS label space from 20-bits to 24-bits or 32- bits for gaining better performance and higher network scalability. Following sections will describe the usecases of L3VPN and L2VPN respectively. 2.1. MPLS Based L3VPN with VXLAN The Figure 1 shows a topology where customer sites are connected to a data center via L3VPN over a MPLS core network; the VXLAN protocol of [I-D.mahalingam-dutt-dcops-vxlan] is used for network overlay virtualiztion in the data center. The customer site is connected to MPLS core via CE and PE devices; while the data center is connected to MPLS core via a new device with combined functions of PE and VTEP (VXLAN Tunnel End Point), which is marked as PE-VTEP device in Figure 1. When a network device in CE site wants to send packets to a VM in the data center, the PE-VTEP device works like a gateway, the VPN header will carrier VXLAN header information accordingly. Li, et al. Expires April 20, 2014 [Page 4] Internet-Draft MPLS Big Label Usecases and Requirements October 2013 ....................... .................. . . . . CE1-| +-------+ +-------+ VXLAN . |-----| PE | MPLS |PE-VTEP| Network . CE2-| +-------+ Network +-------+ in . . . . DataCenter . Customer . . . . Sites ....................... .................. +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ | LSP label | | Outer label | +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ | L3 VPN Label | | VXLAN Header | +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ | dest VM IP | | Inner Label | +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ Packet format out of Packet format out of PE to MPLS network PE-VTEP to VXLAN network Figure 1. Interconnecting Customer Sites with VXLAN in DC The PE and PE-VTEP devices on the MPLS core perform the following functions: VPN PE functions: It uses BGP to distribute VPN routes; maintains VRFs; uses MPLS to receive and forward packets from and to the MPLS network. VXLAN VTEP functions: It originates and terminates VXLAN tunnels; runs all the necessary protocols to build and tear down the VXLAN tunnels; maintains the VXLAN tunnel forwarding states including the MAC table; L3VPN-VXLAN interworking functions: It maintains the mapping information between L3VPN label and VXLAN VNI. This mapping information is used to receive packets from the MPLS network and forward them to the VXLAN network, and receive packets from the VXLAN network and forward them to the MPLS network Because VXLAN uses 24-bits for 16 million number of VNIs, accordingly the existing 2^20 MPLS labels cannot provide one-to-one mapping for the possible virtual network instances. In order to provide one-one mapping between VPN labels and VNIs that can ensure efficient packet encapsulation and distribution of traffic across MPLS core that interconnects the customer sites with VXLAN networks, we need to Li, et al. Expires April 20, 2014 [Page 5] Internet-Draft MPLS Big Label Usecases and Requirements October 2013 expand the MPLS label space from 20-bits to at least 24-bits to support 16 million of label values. Thus in this is the usecase we need big label. 2.2. MPLS Based L3VPN with NVGRE NVGRE is another protocol designed to support the multi-tenant and massive number of virtual network instances in data center networks. NVGRE uses GRE as a method to tunnel L2 packets across MPLS/IP network, and a 24-bit segment identifier in the form of a VSID (virtual subnet ID), which allows LAN segments to scale to 16 million in each data center. NVGRE allows each LAN segment to be extended across MPLS/IP core network. NVGRE is similar to VXLAN architecturally. The Figure 2 shows a topology where customer sites are connected to a data center via L3VPN over a MPLS core network; the NVGRE protocol is used for network overlay virtualiztion in the data center. The customer site is connected to MPLS core via CE and PE devices; while the data center is connected to MPLS core via a new device with combined functions of PE and NVE (virtual network edge), which is marked as PE-NVE device in the Figure. When a network device in CE site wants to send packets to a VM in the data center, the PE-NVE device works like a gateway that maps the VPN header and NVGRE header accordingly. ....................... .................. . . . . CE1-| +-------+ +-------+ NVGRE . |-----| PE | MPLS |PE-NVE | Network . CE2-| +-------+ Network +-------+ in . . . . DataCenter . Customer . . . . Sites ....................... .................. +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+ | LSP label | | Outer label | +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+ | L3 VPN Label | |NVGRE Header(VSID) | +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+ | dest VM IP | | Inner Label | +-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+ Packet format out of Packet format out of PE to MPLS network PE-VTEP to NVGRE network Figure 2. Interconnecting Customer Sites with NVGRE in DC The Provider Edge device PE and PE-NVE device will perform the Li, et al. Expires April 20, 2014 [Page 6] Internet-Draft MPLS Big Label Usecases and Requirements October 2013 following functions: VPN PE functions: It uses BGP to distribute VPN routes; maintains VRFs; uses MPLS to receive and forward packets from and to the MPLS network. NVGRE Endpoint functions: It originates and terminates NVGRE packets; maintains the NVGRE Virtual Subnet Identifier (VSID) for NVGRE L3VPN-NVGRE Interworking Functions: It maintains the mapping information between L3VPN label and NVGRE Virtual Subnet Identifier (VSID). This mapping information is used to receive packets from the MPLS network and forward them to the NVGRE virtual network, and receive packets from the NVGRE virtual network and forward them to the MPLS network Because NVGRE uses 24-bits for 16 million number of VSIDs, accordingly we need to expand the MPLS label space from 20-bits to 24-bits. This way PE-VNE can ensure efficient distribution of traffic across MPLS core. This is the use case we need big label too. 2.3. MPLS Based L2VPN In some situation, a L2 network must be extended beyond the single data center, for example when the application and framework developed for a campus has to be shared by multiple geographic areas, spread over multiple data centers and cross long distances. Typically some customer wants server-to-server communication between a primary and backup data centers cross a MPLS core network. To ensure high speed service, secure connectivity, high availability, application mobility and cost-effective requirements, L2 VPN is a good solution to meet all of the demands. Generally the service provider's customers require a range of VLANs to handle multiple applications in case of L2VPN. VLAN Identifier (VID) uses a 12-bit field specifying the VLAN to which the frame belongs, it allows up to 4,096 VLAN intances. For this range, the current 20-bit MPLS label space is enough. However along with the increasing number of VLANs and VMs in data center, some technology such as E-VPN and Q-in-Q have been proposed to support large-scale L2VPNs with resiliency. A good example is illustrated at Figure 3 that gives a topology of data center LAN extension using L2VPN over MPLS core network. In this usecase data center uses IEEE 802.1Q-in-Q VLAN Tag Termination for intranet. Q-in-Q added another layer of VLAN tag (called "metro tag" or "PE-VLAN") to serve the purpose of VLAN space expansion. In such a Li, et al. Expires April 20, 2014 [Page 7] Internet-Draft MPLS Big Label Usecases and Requirements October 2013 way, a data center could support 4096 * 4096 allowing 16 million of VLAN IDs; therefor the 20-bit MPLS label space is no longer sufficient to provide a one-to-one mapping between the double tagged VLAN IDs and a MPLS label. The one-to-one mapping can be done by expand the MPLS label space to 24-bits as it is shown at Figure 3. .................. .................... .................. . . . . . . . Q-in-Q VLAN +-------+ +-------+ Q-in-Q VLAN . . in |PE-VLAN| MPLS |PE-VLAN| in . . DataCenter +-------+ Network +-------+ Data Center . . . . . . . .................. .................... .................. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Outer VLAN ID |Inner VLAN ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | inner label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet format out of PE-VLAN towards MPLS network Figure 3. L2VPN Data Center (Q-in-Q) cross MPLS core In Figure 3, double tagged VLAN IDs occupy 24-bit label space, it provided a usecase and requirement for MPLS big label. 3. Usecase of MRT MT and FRR In some deployment of Fast Reroute protection, the global label allocation(GLA) is used to represent a LSP for fast switchover. In the event of a link failure, traffic on an LSP is rerouted to the next-hop using a pre-configured backup LSP identified by a global MPLS label. With GLA, Protected LSP and backup LSP can be setup through same interface, any MPLS frame received will be switched based on its global label regardless its incoming interface. Together with make-before-break method it can achieve the fast traffic recovery. When the same FRR mechanism is applied to MRT MT (Maximally Redundant Trees Multi-topology) scenario, the 20-bit MPLS label space will not be sufficient. For example, assume that there are three topologies Li, et al. Expires April 20, 2014 [Page 8] Internet-Draft MPLS Big Label Usecases and Requirements October 2013 configured in a MPLS core network, each topology is colored to yellow (default), red and blue respectively. When enabling the whole network FRR by incremental deployment of LDP MT in the IP network, the MPLS label has to be globally unique in order to achieve fast reroute. Since the number of Internet route is around 500,000 based on some statistics, when MPLS labels are allocated in the yellow (default), blue and red multi-topology respectively and simultaneously, the required labels for allocation will reach 3 times 500,000 at least 1.5million, thus it exceeds the existing 20-bit MPLS label range of 1 million labels. This kind of use cases impose a requirement to the MPLS big label. 4. Usecase of Segment Routing Segment Routing is another example of the use cases that may potentially require MPLS big label. The Segment identification SID uses 32-bit space(draft-filsfils-rtgwg-segment-routing-00), it is used either for a topological instruction or a service instruction. An instruction associated with a global segment is recognized and executed by any SR-capable node in the domain. Because MPLS label space has only 20-bits, the right-most bits of the segment are encoded as a label. This implies that the SID values are allocated within a reduced 20-bit space out of the 32-bit SID space, the maximum number of segments in a routing domain is limited to 1 million not as SR was designed for 4 Billion with 32-bit SID space. It is a reasonable question if it will eventually hits the scalability issue once the size of the network increases to a certain degree. As soon as the number of segments exceed 1 million in a network domain, for example a SDN domain, the 20-bit MPLS label space will need to be expanded from 20-bit to bigger number such as 24-bits or 32-bits. 5. NVO3 Usecase NVO3 is an on-going effort to standardize solutions to data center virtualizaiton with the goal of providing viable data encapsulation and protocols across a scaling range of a few thousand VMs to several million VMs running on greater than one hundred thousand physical servers. NVO3 considers approaches to multi-tenancy that reside at the network layer rather than using traditional isolation mechanisms that rely on the underlying layer 2 technology (e.g. VLANs). Based on NVO3 framework and problem statement, NVO3 will deliver 16 million virtual networks in a physical data center. As described for L3 and L2 VPN use cases, we will need to solve the problem of associating MPLS labels to NVO3 VNIDs, thus it implies another Li, et al. Expires April 20, 2014 [Page 9] Internet-Draft MPLS Big Label Usecases and Requirements October 2013 potential use case for MPLS big label. 6. Big Label Requirements When design MPLS big label applied to the use cases described in this document, following requirements should be considered. 1. An extension to the MPLS label format of RFC 3032 should be specified for big label 2. Big label label needs 24-bit space with 16 million of labels to support interworking with VXLAN/NVGRE/NVO3; The same requirement is applicable for L2VPN in case of using Q-in-Q 3. Big label needs 32-bit space with 1 billion of labels in order to support the number of SIDs specified by Segment Routing 4. PE device in MPLS core network must advertise its big label process capability to other devices in the same routing domain 5. Every PE device must enable big label capability in order to distribute traffic using big label in the same routing domain. A mechanism needs to be specified if allowing some explicit nodes not to use big label in this routing domain. 6. PE devices must be capable to support expanded number of virtual interfaces and forwarding entries etc that could reach 16 million or 1 billion in the worst case. 7.Big label framework needs to be backward compatible. The network device supporting big label must too have capability to process regular 20-bit label. 8. The big label should work with the existing MPLS hardware architecture 7. IANA Considerations The requirements on IANA are specified in other related documents [I-D.draft-renwei-mpls-big-label] and [I-D.draft-renwei-mpls-bgp- big- label], which request a reserved label to represent Big Label Indicator and BGP capabilities for big labels. 8. Security Considerations This draft does not add any additional security implications to the BGP/MPLS IP VPNs. All existing authentication and security Li, et al. Expires April 20, 2014 [Page 10] Internet-Draft MPLS Big Label Usecases and Requirements October 2013 mechanisms for MPLS still apply. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 1999. [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001. 9.2. Informative References [1] R.Li and M.Li,"Encoding of Big Labels in MPLS Label Stacks", [draft-renwei-mpls-big-label-00] June, 2013 [2] Z.Li and L.Zheng, "Mega Label - Expansion of MPLS Label Range" [draft-li-mpls-mega-label-00] July, 2013 [3] R. Aggarwal,Y. Rekhter and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space" [RFC5331] August, 2008 [4] R.Li, K.Zhao and W.Wu, "The Use of Big Labels for BGP/MPLS IP VPN", [draft-renwei-l3vpn-big-label-00] June, 2013 [I-D.mahalingam-dutt-dcops-vxlan] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "VXLAN: A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", draft-mahalingam-dutt-dcops-vxlan-03 (work in progress), February 2013. [I-D.sridharan-virtualization-nvgre] Sridharan, M., Greenberg, A., Venkataramaiah, N., Wang, Y., Duda, K., Ganga, I., Lin, G., Pearson, M., Thaler, P., and C. Tumuluri, "NVGRE: Network Virtualization using Generic Routing Encapsulation", draft-sridharan- virtualization-nvgre-02 (work in progress), February 2013. Li, et al. Expires April 20, 2014 [Page 11] Internet-Draft MPLS Big Label Usecases and Requirements October 2013 Authors' Addresses Renwei Li Huawei Technologies 2330 Central Expressway Santa Clara, CA 95050 USA Email: renwei.li@huawei.com Katherine Zhao Huawei Technologies 2330 Central Expressway Santa Clara, CA 95050 USA Email: katherine.zhao@huawei.com Zhenbin Li Huawei Technologies Huawei Campus, No.156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com Li, et al. Expires April 20, 2014 [Page 12]