The Software Defined Networking (SDN) framework has a large and varied context. Multiple components may or may not be used, OpenFlow being one of them. Some evolving SDN use cases leverage the capabilities of the OpenFlow protocol while others do not require it. OpenFlow is only one of those protocols within the SDN architecture. This post addresses the use of Border Gateway Protocol (BGP) as the transfer protocol between the SDN controller and forwarding devices. BGP and OpenFlow are monolithic, meaning they are not used simultaneously. Integrating BGP to SDN offers a number of uses cases, such as DDoS mitigation, exception routing and forwarding optimizations,graceful shutdown and integration with legacy networks. Some of these use cases are available using OpenFlow Traffic Engineering, others like graceful shutdown and integration with the legacy network are easier to accomplish with BGP SDN. Currently, there are some companies implementing the BGP/SDN flavor in production. For example, Microsoft operates a BGP SDN network with graceful shutdown and forwarding enhancements. Nuage networks andJuniper Contrail use MP-BGP to integrate their SDN architecture with legacy networks. And I’m pretty sure SD-WAN company, Viptela, have some BGP SDN route reflector design.
BGP-based SDN involves two main solution components that may be integrated into a number of existing BGP technologies. Firstly, we have an SDN controller component speaking BGP; deciding what needs to be done. Secondly, we have a BGP originator component; sending BGP updates to the SDN controller and other BGP peers. The controller could be a BGP software package running on Open Daylight. BGP originators are Linux daemons or traditional proprietary vendor devices running the BGP stack.
To create the SDN architecture these components are integrated with existing BGP technologies, such as BGP FlowSpec (RFC 5575), L3VPN (RFC4364), EVPN (RFC 7432), and BGP-LS. BGP FlowSpec distributes forwarding entries, such as ACL and PBR to the TCAM of devices. L3VPN and EVPN offer the mechanism to integrate with legacy networks and service insertion. BGP-LS extracts IGP network topology information and passes it to the SDN controller via BGP updates.
Introducing BGP into the SDN framework does not mean centralized control plane. We still have central policy, visibility, and control, but this is not a centralized control plane. A centralized control plane would involve local control plane protocols establishing adjacencies or other ties to the controller. In this case, the forwarding devices outright require the controller to forward packets; forwarding functionality is limited when the controller is down. If the BGP SDN controller is acting as a BGP route reflector, all announcements go the controller but the network runs fine without it. The controller is just adding value to the usual forwarding process. BGP-based SDN architecture augments the network, it does not replace it. Decentralization of the control plane is the only way, just look at Big Switch and NEC’s SDN design changes over the last years. Centralized control planes cannot scale.
Why use BGP?
BGP is well understood and field tested. It has been extended on many occasions to carry additional types of information, such as MAC addresses and labels. Technically, BGP can be used as a replacement for Label Distribution Protocol (LDP) in an MPLS core. Labels can be assigned to IPv6 prefixes (6PE) and label switched across an IPv4-only MPLS core. BGP is very extensible. It started with IPv4 forwarding, then address family were added for multicast and VPN traffic. The idea of using multiple addresses inside a single BGP process was widely accepted and implemented as a core technology. The entire Internet is made up of BGP and it carries over 500,000 prefixes. It’s very scalable and robust. There are some MPLS service providers carrying over 1 million customer routes.
There are many high-quality open source BGP daemon available. Quagga is one of the most popular and since Cumulus and Google’s adoption, it’s quality has improved. Quagga is a routing suite and has IGP support for IS-IS and OSPF. Also, a BIRD daemon is available. The implementation is based around Internet exchange points as the route server element. BIRD is currently carrying over 100,000 prefixes.
Using BGP on an SDN controller integrates easily with your existing network. You don’t have to replace any existing equipment, deploy the controller and implement the add-on functionality that BGP SDN offers. It enables a preferred step-by-step migration approach and not a risky big bang OpenFlow deployment.
IGP to the Controller?
Why not run OSPF or ISIS to the controller? IS-IS is extendable with TLV’s and too can carry a variety of information? The real problem is not extensibility but the lack of trust and policy control. IGP extension to the SDN controller with little controls could present a problem. OSPF simply sends LSA packets, there is no input filter. BGP is designed with policy control in mind and acts as a filter by implementing controls on individual BGP sessions. BGP offers control on the network-side and predicts what the controller can do. If the controller hits a bug or gets compromised, the blast radius is restricted. BGP gives greater policy mechanisms between the SDN controller and physical infrastructure.
SDN requires complete topology visibility. If some topology information is hidden in IGP and other NLRI in BGP, then it does not have a complete picture. If you have an existing IGP, how do you propagate this information to the BGP controller? Border Gateway Protocol Link State (BGP-LS) is cleaner than establishing an IGP peering relationship with the SDN controller.
BGP-LS is used to extract network topology information and send it to the BGP controller via BGP updates. Once again, BGPv4 is extended to provide the capability to include new Network Layer Reachability Information (NLRI) encoding format. It sends information from IS-IS or OSPF topology database through BGP updates to the SDN controller. To enhance security between the physical and SDN world, BGP-LS can configure the session to be unidirectional and stop incoming updates. Now, the SDN controller cannot leak information back into the running network. BGP-LS is a relatively new concept. It focuses on the mechanism to export IGP information and does not describe how SDN controller can use this information. Once the controller has the complete topology information it may be integrated with traffic engineer and external path computing solutions to interact with information usually only carried by an IGP database. Traffic Engineering Database (TED), which are built by ISIS and OSPF-TE extensions, are typically distributed by IGPs within the network. Previously, each node maintains its own TED but now this can be exported to a BGP RR SDN application for better visibility.
BGP Scale-Out Architectures
SDN controller will always become the scalability bottleneck. It can scale better when it’s not participating in data plane activity but eventually it will reach its limits. Every controller implementation eventually hits this point. The only way to grow is to scale out. Reachability and policy information is synchronized between individual controllers. Reachability information can be transferred and synchronized with MP-BGP; L3VPN for IP routing or EVPN for layer-2 forwarding.
Utilizing BGP between controllers offers additional benefits. Each controller can be placed in a separate availability zone and tight BGP policy controls are implemented on BGP sessions connecting those domains; offering a clean failure domain separation. An error in one available zone is not propagated to the next availability zone. BGP is a very scalable protocol and the failure domains can be as large as you want but consider that the larger the domain the longer the convergence times. Adjust the size of failure domains to meet scalability and convergence requirements.
Sourced from: http://network-insight.net/