SDN empowers applications with APIs to program the network devices as shown in the diagram below. This means many of the complex protocols that make network devices (e.g. routers and switches) expensive can be decoupled from these devices and moved to the SDN controller, the SDN management and orchestration layer, and/or SDN applications. This simplifies the network devices and lowers the barrier to entry for new vendors into this market.
However, network devices still need to have sufficient interfaces for programmability. What will these interfaces look like for the WAN? There are many competing proposals in the IETF, which we are discussing this week during IETF 95 in Buenos Aires. Some of them may solve a problem here and there but will not be able to address the use cases of tomorrow. In this blog, I am going to talk about two technologies that I believe are very promising and will simplify future wide-area networking.
First, network devices need to be able to encode any path in the WAN: not just shortest paths or equal-cost-multi-paths, but any path. Segment routing solves this problem. It breaks the path of interest into shortest-path segments and encodes the segments in the packet either as an MPLS label stack or using the IPv6 segment routing option.
As a technology, it is in competition with RSVP-TE, which can also encode any path in the network. Yet having a scalable and mature RSVP-TE implementation is challenging (kudos to vendors for managing the challenges) as is operating a network with RSVP-TE. We have seen supposedly short-lived, fast-reroute paths becoming long-lived due to race conditions, not to mention excess IGP churn caused by auto-bandwidth induced updates.
Segment routing eliminates this complexity. A central SDN controller with a management and orchestration layer can better handle both race conditions and maintenance of available bandwidth in the network. Segment routing is still the new kid on the IP control plane (first production deployments are expected this year) and needs to mature for mainstream deployment. We are testing segment routing support in our SDN Platform, and it will be generally available this summer.
Second, network devices need to be told what traffic to put on the paths; in other words, service creation and policy. For example: Should the shortest-propagation-delay path be provisioned by the SDN orchestration layers for the financial-enterprise customer or for over-the-top video? How do we attach this path to the service and perhaps rate-limit video traffic when the network is starving for capacity under failures?
Policy can be very complex. In the nineties, prior to joining Packet Design, I worked on a language for specifying BGP routing policies (RPSL). BGP routing policies are one of the most complex and lengthy parts of router configurations. Knobs needed to specify one service provider’s policies are similar to but different from the next provider, yielding a slew of knobs. This means service creation and policy need a rich modeling language.
This is where the YANG modeling language comes in. Using YANG, one can define a data model for practically anything. YANG is very extensible for future needs as well. There are hundreds of YANG models available today, including one for complicated BGP policies (See OpenConfig spearheaded by Google, British Telecom, and others).
Service provider interest, network equipment, and SDN controller support for YANG models are skyrocketing. I am pleased to report that we are investing heavily in YANG models at Packet Design, both to interact with network devices and controllers and to provide YANG-based APIs to applications on top of our SDN Platform.
YANG objects are communicated to the network devices, SDN controllers (if their northbound is also YANG based), and the orchestration layer using NETCONF (XML encoded SSH transported) or RESTCONF (JSON encoded and https transported) protocols today. These two protocols may not be best suited when making tens of thousands of ephemeral-state path and policy changes a second. The IETF’s Interface to Routing System (I2RS) Working Group is looking at this during the conference this week. Meanwhile some vendors already support a binary YANG object encoding and GRPC-based transport.
Some SDN protocols of the day may become short-lived once we can set a high-volume ephemeral-state in the network. PCEP and BGP-LS are both suspects in this category. Today, PCEP is used to communicate the desired path to the network devices. However, it does a half-baked job. To communicate that one path protects another path, or a link, or a node in the network, it is being extended with “associations.” This is policy, and YANG is better suited for it than PCEP; who knows what we will want to protect tomorrow? Even the path itself can be encoded using YANG objects, making PCEP’s role questionable in the future. Our SDN Platform already supports PCEP to set up traffic engineered paths in the network.
What about BGP-LS? There are already YANG models to obtain topology from the network, both at the optical and IP layers. Hopefully, even more complicated proposals at the IETF do not see the light of day in actual networks.
Let’s keep it simple: Segment routing and YANG are all we need. The faster these two technologies mature, the faster we can get rid of other, more complex technologies from the network. It is a pity that we have to support interim solutions such as BGP-LS and PCEP until then.