Network Working Group Z. Li Internet-Draft M. Chen Intended status: Informational S. Zhuang Expires: April 23, 2014 Huawei Technologies October 20, 2013 An Architecture of Central Controlled Border Gateway Protocol (BGP) draft-li-idr-cc-bgp-arch-00 Abstract As the Software Defined Networks (SDN) solution develops, BGP is extended to support central control. This document introduces an architecture of using BGP for central controlling. Some use cases under this new framework are also discussed. For specific use cases, making necessary extensions in BGP are required. 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 RFC 2119 [RFC2119]. 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 23, 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 Li, et al. Expires April 23, 2014 [Page 1] Internet-Draft An Architecture of CC BGP October 2013 (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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Reference Model . . . . . . . . . . . . . . . . . . . . . 4 3.2. Deployment Mode . . . . . . . . . . . . . . . . . . . . . 4 3.3. Requirement of Protocol Extensions . . . . . . . . . . . 5 3.3.1. Building Connectivity . . . . . . . . . . . . . . . . 5 3.3.2. Roles Auto-Discovery . . . . . . . . . . . . . . . . 6 3.3.3. Establishing BGP Sessions . . . . . . . . . . . . . . 6 3.3.4. Capability Negotiation . . . . . . . . . . . . . . . 6 3.3.5. High Availability . . . . . . . . . . . . . . . . . . 6 3.3.6. Security . . . . . . . . . . . . . . . . . . . . . . 7 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Network Topology Acquirement . . . . . . . . . . . . . . 7 4.2. Simplifying Network Operation and Maintenance . . . . . . 7 4.3. MPLS Global Label Allocation . . . . . . . . . . . . . . 8 4.4. RR-Based Traffic Steering . . . . . . . . . . . . . . . . 8 4.5. Inter-Controller Applications . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction The Border Gateway Protocol (BGP) defined in [RFC 4271], is well- known as Internet inter-domain routing protocol. Multiprotocol BGP (MP-BGP) framework defined in [RFC 4760], is an extension to BGP that enables BGP to carry routing information for multiple network layers and address families. The current MP-BGP specification can provide a rich service set within a BGP enabled network, such as L2VPN, L3VPN, MVPN, EVPN,etc. There have been some BGP-based central controlled applications, such as BGP RR [RFC4456]. A route reflector (RR) is a network routing component. The purpose of the RR is concentration in that way all Li, et al. Expires April 23, 2014 [Page 2] Internet-Draft An Architecture of CC BGP October 2013 Client's forwarding routes are exchanged by the central RR Router. It offers an alternative to the logical full-mesh requirement of internal border gateway protocol (IBGP). A RR acts as a focal point for IBGP sessions. Multiple IBGP routers can only peer with a central point, rather than peer with every other router in a full mesh manner. All the other IBGP routers become route reflector clients. With the emergence of Software Defined Networks (SDN), BGP plays as an important part in a central controlled environment. 1 Building a central controlled framework for Controller and its Clients, BGP can be used to communicate between Controller and its Clients, Controller and other Controllers. The information carried by BGP includes network and service topology, network and service forwarding entries etc. 2 Many new applications are emerging under the centrally-controlled framework, such as network virtualization, global traffic engineering etc. Some new applications bring extension requirements to BGP. This document defines an architecture of Central Controlled BGP and then use cases under this framework are described. For some use cases requirements of BGP extensions are discussed. 2. Terminology BGP: Border Gateway Protocol EVPN: Ethernet VPN L2VPN: Layer 2 VPN L3VPN: Layer 3 VPN MVPN: Multicast VPN RR: Route Reflector SDN: Software-Defined Network S-EVPN: Segment-based EVPN Li, et al. Expires April 23, 2014 [Page 3] Internet-Draft An Architecture of CC BGP October 2013 3. Architecture 3.1. Reference Model +------------------------------+ +------------------------------+ | AS 1 | | AS 2 | | +------------+ | | +------------+ | | | BGP | | | | BGP | | | | Controller |----------------------| Controller | | | | (RR+) | | | | (RR+) | | | | | | | | | | | +------------+ | | +------------+ | | / \ | | / \ | | / \ | | / \ | | / \ | | / \ | | +--------+ +--------+ | | +--------+ +--------+ | | | NODE 1 | | NODE n | | | | NODE 1 | | NODE n | | | | | ...... | | | | | | ...... | | | | | BGP | | BGP | | | | BGP | | BGP | | | | CLIENT | | CLIENT | | | | CLIENT | | CLIENT | | | +--------+ +--------+ | | +--------+ +--------+ | | | | | +------------------------------+ +------------------------------+ Figure 1: An Architecture of Central Controlled BGP The figure above depicts a typical architecture of central controlled BGP. It consists of two essential network elements: BGP Controller and BGP Client. BGP Controller controls all the BGP Clients within its administrative domain by communicating with them. In the above framework, BGP Controller is placed at the same position of traditional Route Reflector (RR) [RFC4456]. Moreover from point of view of implementation BGP Controller can be considered as function-enhanced RR. So in this document, BGP Controller is named RR+ as well. 3.2. Deployment Mode BGP Controller can run on a general-purpose server or a network device. If BGP Controller runs on a network device, it MUST support both central-controlled functionality and forwarding functionality. Same as BGP Controller, BGP Client can run on a general-purpose server or a network device. It is more meaningful to decouple control plane and forwarding functionality on BGP Client because this manner enables network devices focusing on forwarding functionality. This deployment model is shown in the following figure: Li, et al. Expires April 23, 2014 [Page 4] Internet-Draft An Architecture of CC BGP October 2013 +------------------------------+ +------------------------------+ | AS 1 | | AS 2 | | +------------+ | | +------------+ | | | BGP | | | | BGP | | | | Controller |----------------------| Controller | | | | (RR+) | | | | (RR+) | | | | | | | | | | | +------------+ | | +------------+ | | / \ | | / \ | | / \ | | / \ | | / \ | | / \ | | +--------+ +--------+ | | +--------+ +--------+ | | | | | | | | | | | | | | | | ...... | | | | | | ...... | | | | | BGP | | BGP | | | | BGP | | BGP | | | |CLIENT 1| |CLIENT n| | | |CLIENT 1| |CLIENT n| | | +--------+ +--------+ | | +--------+ +--------+ | | | | | | | | | | | | | | | | | | | | | | | | | | +--------+ +--------+ | | +--------+ +--------+ | | | | | | | | | | | | | | |Forward | ...... |Forward | | | |Forward | ...... |Forward | | | | | | | | | | | | | | | | NODE 1 | | NODE n | | | | NODE 1 | | NODE n | | | +--------+ +--------+ | | +--------+ +--------+ | +------------------------------+ +------------------------------+ Figure 2: Decoupling BGP Client and Forwarding In the reference model, there are multiple BGP controllers in multiple ASes. In fact in one AS, there can also be multiple BGP controllers to control different sets of BGP clients and IBGP peers are set up between these BGP controllers. Such application scenario can refer to [I-D.ietf-mpls-seamless-mpls] in which there are multiple IGP areas which runs BGP in one AS. This document focuses on multiple BGP controller in different ASes. The requirement and use cases can also be applied to the case of multiple BGP controller in one AS. 3.3. Requirement of Protocol Extensions Building a BGP-based Central Controlled Framework needs extensions to IGP, BGP and I2RS etc. 3.3.1. Building Connectivity Li, et al. Expires April 23, 2014 [Page 5] Internet-Draft An Architecture of CC BGP October 2013 Connectivity between BGP Controller and BGP Clients in an AS can be built by extending IGP protocol. In order to simplify network operations, such connectivity SHOULD be automatically established. 3.3.2. Roles Auto-Discovery A BGP-based Central Controlled Framework consists of two basic roles: BGP Controller and BGP Client. Such roles can be auto-discovered by extending IGP protocol to flooding the role information within an AS. When IGP has finished the flooding process of role information, BGP Controller and BGP Client can establish a BGP session on demand. 3.3.3. Establishing BGP Sessions For the intra-AS case, when IGP has finished the flooding process of role information within an AS, BGP Controller and BGP Client can automatically establish a BGP session. It is not necessary to establish BGP sessions amongst BGP Clients. For the inter-AS case, the peer BGP controller SHOULD be specified to establish BGP sessions. 3.3.4. Capability Negotiation In order for BGP Controller and BGP Client to support BGP-based Central Controlled framework in a friendly way, this document suggests to defines a new BGP Central Control Capability. The Central Control Capability SHOULD be defined as per [RFC5492]. By advertising the BGP Central Control Capability to a peer, a BGP speaker conveys information if it is able to send, receive, and properly handle BGP Central Control related processes. The existing BGP capabilities should be kept in the Central Controlled framework and other new capabilities should be extended according to new applications based on the Central Controlled framework. 3.3.5. High Availability In the BGP-based Central Controlled framework, BGP Controller plays a key role. To void one-point-failure of BGP Controller, it is possible to run redundant BGP Controllers for high availability. With multiple BGP Controllers, it is important to synchronize route processing policy configuration for all of them to perform the exactly same routing decisions. When Primary BGP Controller failed, the Backup BGP Controllers will take over the work of the Primary BGP Controller. Li, et al. Expires April 23, 2014 [Page 6] Internet-Draft An Architecture of CC BGP October 2013 To ensure BGP route persistence in case of occurrence of BGP Controller failure, the new Primary BGP Controller SHOULD perform resynchronization with BGP Clients. When BGP Client loses connection with Primary BGP Controller, it SHOULD following BGP Graceful Restart routine defined in [RFC 4724] similar as a GR Helper. 3.3.6. Security In BGP-based Central Controlled framework, it SHOULD be ensured that communications between BGP Controllers and BGP Clients conform to network security policy. The communication key used on BGP Client can be configured through I2RS or other way. 4. Use Cases In BGP-based Central Controlled framework, new use cases which are difficult to be supported in traditional networks are emerging. In some specific use cases, extension and enhancement of BGP protocol are necessary. 4.1. Network Topology Acquirement In BGP-based Central Controlled framework, BGP Controller can get the topology of the whole network. Some applications such as ALTO can get network topology information from BGP Controller. The topology information of one AS can also be advertised by the controller to the other BGP Controller in the other AS. BGP has been extended to distribute link-state and traffic engineering information as defined in [I-D.ietf-idr-ls-distribution]. 4.2. Simplifying Network Operation and Maintenance The adoption of the new BGP-based Central Controlled Framework can reduce the complexity and effort of network operation and maintenance by following manners: 1. By using I2RS APIs, it would allow network operator to setup BGP policy configuration from a single central point. This helps avoid manual configuration of BGP policy on multiple BGP Clients and reduce the complexity of BGP policy configuration. 2. For network with VPN service which includes L3VPN, L2VPN, E-VPN etc, BGP Controller COULD store all the VPN user information. Use of I2RS APIs to set L3VPN configuration from BGP Controller would allow network operator no need to configure a VPN many times on different BGP Clients. Furthermore, in the new Central Controlled framework Li, et al. Expires April 23, 2014 [Page 7] Internet-Draft An Architecture of CC BGP October 2013 VPN parameters such as Route Distinguisher (RD), Route Targets (RT) can be automatically generated and the configuration between CE and PE can be generated automatically after the CE is authenticated by the Central Controller. This can simply network operations and maintenance greatly. 4.3. MPLS Global Label Allocation MPLS Global Label should be allocated in a central point to guarantee all distributed network nodes can understand meaning of a specific global label in same. The new BGP-based Central Controlled framework is particularly suitable to allocate MPLS Global Label through some necessary MP-BGP extensions. MPLS Global Label is defined in [I-D.li-mpls-global-label-framework] and related use cases are defined in [I-D.li-mpls-global-label- usecases]. The extensions of BGP for MPLS global label include: 1. A new BGP Capability called Global Label Capability is suggested to be introduced by following [RFC5492]. BGP Controller can negotiate with BGP client on this new BGP capability. 2. BGP Controller determines the COMMON label space for all its BGP Clients. 3. For each BGP client, BGP Controller allocates different MPLS Global Labels for different services and advertises the MPLS Global Labels to the BGP Client. 4. BGP Client receives the MPLS Global Labels, and generates corresponding MPLS forwarding entries. Many types of services such as VPLS[RFC4761], Multicast VPN[RFC6514], E-VPN[I-D.ietf-l2vpn-evpn] are based on MP-BGP. So making extensions to MP-BGP to allocate MPLS global label for these services is a nature way from point of network solution. The use cases of MPLS global label defined in [I-D.li-mpls-global-label-usecases] includes S-EVPN, Split Horizon in VPLS MCAST and BGP MVPN, Egress PE protection in VPN, etc. 4.4. RR-Based Traffic Steering RR-based Traffic Steering (RRTS) defined in [I-D.chen-idr-rr-based- traffic-steering-usecase], is an idea that leverages the BGP route reflection mechanism to realize traffic steering in the network, therefore the operators can conduct specific traffic to traverse Li, et al. Expires April 23, 2014 [Page 8] Internet-Draft An Architecture of CC BGP October 2013 specific path, domains and/or planes as demand. The essential of RRTS is that the concept of traffic engineering is introduced into BGP network. With the new BGP-based Central Controlled framework defined in this document, the operators can steer the network traffic easily. More detailed description could be found in [I-D.chen-idr- rr-based-traffic-steering-usecase]. 4.5. Inter-Controller Applications Information is communicated between the BGP controller to fulfill the inter-AS applications such as inter-AS VPN. Besides the inter-AS applications, there proposes a type of new application to communicate control information only between BGP Controllers to set up service directly and download necessary forwarding entry to the nodes. Thus the BGP sessions between the Controller and the node can be saved and the control functionality on the node can be saved further. This type of model is shown in the following figure. In this model, the service set up between the nodes is proxied by the BGP Controllers. +----------------------------------------------------------------+ | AS | | +------------+ +------------+ | | | BGP | | BGP | | | | Controller |--------------------| Controller | | | | (RR+) | | (RR+) | | | | | | | | | +------------+ +------------+ | | / \ / \ | | / \ / \ | | / \ / \ | | +--------+ +--------+ +--------+ +--------+ | | | | | | | | | | | | |Forward | ...... |Forward | |Forward | ...... |Forward | | | | | | | | | | | | | | NODE 1 | | NODE n | | NODE 1 | | NODE n | | | +--------+ +--------+ +--------+ +--------+ | +----------------------------------------------------------------+ Figure 3: Removing BGP Session between Controller and NODE 5. IANA Considerations This document makes no request of IANA. 6. Security Considerations TBD. Li, et al. Expires April 23, 2014 [Page 9] Internet-Draft An Architecture of CC BGP October 2013 7. References 7.1. Normative References [I-D.ietf-l2vpn-evpn] Sajassi, A., Aggarwal, R., Henderickx, W., Balus, F., Isaac, A., and J. Uttaro, "BGP MPLS Based Ethernet VPN", draft-ietf-l2vpn-evpn-04 (work in progress), July 2013. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006. [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, April 2006. [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007. [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, February 2009. [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, January 2011. [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. 7.2. Informative References Li, et al. Expires April 23, 2014 [Page 10] Internet-Draft An Architecture of CC BGP October 2013 [I-D.chen-idr-rr-based-traffic-steering-usecase] Chen, M., Zhuang, S., Zhu, Y., and S. Wang, "Use Cases of Route Reflection based Traffic Steering", draft-chen-idr- rr-based-traffic-steering-usecase-00 (work in progress), July 2013. [I-D.ietf-idr-ls-distribution] Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and TE Information using BGP", draft-ietf-idr-ls-distribution-03 (work in progress), May 2013. [I-D.ietf-mpls-seamless-mpls] Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, M., and D. Steinberg, "Seamless MPLS Architecture", draft- ietf-mpls-seamless-mpls-04 (work in progress), July 2013. [I-D.li-l2vpn-segment-evpn] Li, Z., Yong, L., and J. Zhang, "Segment-Based EVPN(S-EVPN)", draft-li-l2vpn-segment-evpn-00 (work in progress), July 2013. [I-D.li-mpls-global-label-framework] Li, Z., Zhao, Q., and T. Yang, "A Framework of MPLS Global Label", draft-li-mpls-global-label-framework-00 (work in progress), July 2013. [I-D.li-mpls-global-label-usecases] Li, Z., Zhao, Q., and T. Yang, "Usecases of MPLS Global Label", draft-li-mpls-global-label-usecases-00 (work in progress), July 2013. Authors' Addresses Zhenbin Li Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com Li, et al. Expires April 23, 2014 [Page 11] Internet-Draft An Architecture of CC BGP October 2013 Mach(Guoyi) Chen Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: mach.chen@huawei.com Shunwan Zhuang Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: zhuangshunwan@huawei.com Li, et al. Expires April 23, 2014 [Page 12]