SD-WAN’s reputation

1 Introduction

This article reviews ETSI GS MEC 002 V2.1.1 and looks back at SD-WAN from the perspective of edge computing to see how SD-WAN can "accomplish the king's affairs and win a good reputation during his lifetime and after his death."

The author has incubated cloud network products based on SD-WAN and has some basic industry background and product experience. However, the problems in this article are relatively large, and I feel a little guilty just relying on my own experience, so I did some homework in advance and tried to stand on the shoulders of giants, that is, based on the ETSI MEC use case protocol, and then "combining theoretical learning with practical experience", which is relatively more down-to-earth.

The ETSI MEC protocol introduction is a series, which is relatively dry and boring and not suitable for the platform style. If you are interested in the protocol, you can go to my personal public account. Relevant colleagues are welcome to communicate and exchange ideas.

2 Previous Life

In 2019, Gartner, the leader in the field, officially announced the social death of SDN (see the picture below), and the eulogy was somewhat tragic: SDN is Dead; Long Live SDN. The general meaning is: "SDN is dead, but its spirit will always live in our hearts, Amen."

Why did SDN die socially? The eulogy is very clear: it is not that SDN is bad, but that SDN has been deeply rooted in people's hearts. Those who should use SDN have already used it; arguing with those who don't use SDN is like looking for hair on a turtle shell - a waste of effort. Since there is no direct new market to push for in the future, if the leader does not announce its social death, won't it be easy for people with ulterior motives to use it to deceive innocent entrepreneurs and investors?

Therefore, the social demise of SDN is not due to technical concepts, but to product form.

Far from users: The main product form of SDN is DCI and the so-called elastic cloud connection based on DCI (there is also DCN, but this part is even further away from ordinary users, so it is omitted). What kind of product form is this? If we use the water pipe as an analogy, this is at least at the municipal water pipe level: the municipal water pipe transformed by SDN still needs to rely on digging trenches and burying pipes at the bottom. The revolutionary innovation is that by installing software-defined devices at the transfer points of the municipal water pipes, the size and direction of the water flow can be quickly adjusted. The infrastructure is so "fast", the direct result is that it can support the flexible reuse of pipeline resources, and then further derive new services at the operational level such as guaranteed bursts, 95 billing, and traffic packages. However, in essence, it is still a large resource pipeline based on trunk lines, so the direct users are mainly large enterprises, large operators, etc. Therefore, those who have large network assets that need to reduce costs and increase efficiency have already used SDN and are enjoying it very much; those "apparent customers" who have not yet used it actually do not really need it, or if they have sporadic needs, they can rent one from operators who have already used SDN.

Far from applications: SDN is not only far from users, but also far from applications. On large pipelines, it is difficult to identify or control the granularity of applications.

3 This Life

While the leader officially announced the social death of SDN, it strongly supported the upgrading of SD-WAN. In 2020, it even allowed it to cross over into the field of network security, declaring it a high-value field that will be adopted in the next two years (high benefit and less than two years to adopt category). This evaluation is even higher than IPS and WAF (moderate benefit and less than two years to adopt category).

SD-WAN, which inherits the spirit of SDN, can break away from the computer room limitations of SDN products and fly into ordinary people's homes, getting closer to users and applications.

Why is SD-WAN closer to users and applications than SDN? A direct answer lies in SD-WAN's CPE.

It is precisely because of the existence of CPE that SD-WAN can play its core advantages, at least the core advantages on the PPT. Suppose a company has set up a new office in Silicon Valley and needs to connect it to the corporate network. If the corporate network is built based on SD-WAN, then for the customer, all you need to do is: after receiving the CPE, power it on and plug it in, and then the corporate network is established. It's so magical.

On the product interface, CPE is one of the manufacturer's key service touchpoints (the other is the self-service portal page), so the light of ZTP must shine.

In terms of network operation and maintenance, CPE also clearly defines the boundaries of responsibility: below CPE, the customer is responsible; above CPE, the supplier is responsible.

Warning: The above is just a principle. To learn what to do when using SD-WAN for enterprise networking, please refer to Chapter 5.1 of "Understanding the SD-WAN Industry: Looking at SD-WAN from the Perspective of WAN Cloudification". I will not go into details here.

4 Behind

There is no need to be happy about SD-WAN too soon. From the comparison of the two Gartner figures from 2019-2020 above, we can see that the leader is already making arrangements for SD-WAN. That is the rapidly rising SASE in the figure, which has suddenly jumped from Innovation Trigger to Peak of Inflated Expectations.

SASE can continue to be closer to users, closer to applications, more intimate and more secure, basically satisfying all current fantasies about the future of enterprise networks.

I will be lazy here. If you want to understand the evolution logic of SD-WAN to SASE, you can refer to:

Deducing SASE from WAN cloudification: SD-WAN evolution towards IoT and edge computing

5 Lesions

At such a young age, he was arranged to die early. It must be that the leader noticed some problems. The following is a combination of experience to find the possible cause of the problem.

Regarding diseases, the theory of evolution has a very interesting view: diseases are the product of biological evolution. That is, evolution only allows benefits and risks to achieve a certain adaptation and balance in a specific environment. Any balance will be broken as the species develops (this is a bit pessimistic), so the root cause of many diseases is actually the advantages left over from the last evolution (such as obesity and diabetes). CPE may be the same for SD-WAN. While helping SD-WAN replace SDN, it has also become a hidden lesion. Some typical problems are:

1) Which box to choose ? MIPS, ARM, x86? One or several?

Choose one. If you choose a higher price, the salesperson will say the price is too outrageous and they can’t sell it to you. If you choose a lower price, the salesperson will say they have many customers who need large bandwidth and ask if they still want to make money.

Then try to choose multiple models. OK, the product manager has calculated the hardware cost, but what about the R&D cost? Can the R&D cost be estimated accurately? Does the R&D team have experience in equipment R&D? It seems that the way to make enterprise-level equipment is different from that of Internet applications. In addition, can the sales understand the pain that R&D will face? Is it just "I understand" in the rhetoric or do they really understand? In addition, choosing multiple models will further bring a series of management costs including procurement, inventory management, configuration, etc.

2) Some old equipment manufacturers may not have the first problem (because they are old wine in new bottles, so there is no choice at all, haha), but the second problem is relatively more common. SD-WAN is aimed at the 2B market, and the 2B market always needs to do PoC testing. What problems will the test bring?

It is relatively easy for established equipment manufacturers to occupy the high-end market through their inventory and brand, but the number of leading enterprises in the industry is limited after all. Are the investors behind them willing to be limited to the high-end market, or should they try the mid- and long-tail market?

If you want to try the mid- and long-tail, there will be a lot of tests, and most of these mid- and long-tail will not accept paid tests. The nightmare is about to begin: sending boxes. The warehouse management department ships -> the delivery department configures -> the logistics department ships -> the customer signs -> the delivery department arranges the customer to go online -> test guarantee -> even if your product is awesome, 50% is transferred to the merchant, and the other 50% still needs to be sent back by the customer -> the warehouse management department receives the goods -> inspection and testing -> the warehouse management department enters the warehouse. This is still a relatively simple normal process, and it has not yet involved a series of work order circulation links, water level maintenance of warehouses in various places, and some "common unexpected events", such as incorrect information provided by the customer during the proposal stage.

Can the operations team support it? The marketing department has already officially announced the standard time limits for various services. If they can support it, can they support survival or can they support leapfrog growth of the business?

3) Should we expand the customers left over from the SDN era? Some of them actually involve office scenarios. If we want to upgrade them to SD-WAN products, how should we model the cloud connection sites that were previously accessed through dedicated lines? Do we need CPE? If we don’t need CPE, the network architecture will be a bit “ugly”; if we need CPE, should we put boxes in the computer room or buy computer room resources for virtualization? If we need to buy, who will buy them? What is the operation and maintenance interface like?

The decision on each of the above issues will involve specific implementation, and once implemented, it will involve whether the company will shoulder an increasingly heavy historical burden (you can't say you support it today and then say you won't do it a few months later), which is a bit daunting.

[[408339]]

6 Mechanism

I continue to recommend the Y model: If you want to solve a concrete problem, you need to dig deeper and solve it at a more basic level. Let's switch from the customer perspective back to the manufacturer perspective.

The following is the typical system architecture of mainstream SD-WAN products.

• Subscriber Web Portal: A web-based self-service portal that is usually connected to the supplier's BSS/OSS system to form a linkage.
• Service Orchestrator: The orchestrator is responsible for orchestrating the business intent entered by users on the self-service portal into a series of network services. The interface between the service orchestrator and the self-service portal is what is commonly called the northbound interface.
• SD-WAN Controller: The controller is responsible for translating various network services into device languages ​​that network devices can understand. The interface between the controller and network devices is commonly known as the southbound interface.
• SD-WAN Edge: Network edge devices, commonly known as CPE, are devices that execute specific network policies. In some equipment vendors' solutions, there will be special and more powerful CPEs that can be placed at the POP end as local end devices.

The following is a typical network architecture of mainstream SD-WAN products.

1. Access side: The network part between CPE and POP is under the weak control of the supplier, and the quality of the underlying bearer is usually uncontrollable.
2. Backbone side: The network part between POP-POP is under the strong control of the supplier, and the quality of the underlying load is usually controllable (such as Aryaka's global Layer 2 backbone network). Of course, in theory, the backbone side is not necessary, but if the overall background is the WAN cloudification, suppliers with backbone resources will have great advantages.
3. End-to-end tunnel: A logical connection between CPEs, usually an overlay tunnel. The basic principle is as follows: between a pair of CPEs, based on the business intent entered by the user on the self-service portal (for example, connecting two branch sites), the orchestrator and controller translate the orchestration and send the device configuration to the target CPE, establishing end-to-end tunnels that support the customer's business intent.

It is these end-to-end tunnels that directly provide services to customers, and all the fancy tricks are carried out on them.

The simplest trick: some manufacturers do use this tunnel as a supplement to SDN services, that is, they are essentially selling these end-to-end tunnels; however, compared with traditional SDN services, since the access side does not have to be restricted to dedicated lines, it can greatly shorten the delivery cycle and reduce the overall cost, at least for emergency or disaster recovery. According to the author's understanding, many people have misunderstandings about SD-WAN, and the easiest misunderstanding is to limit SD-WAN to this level.

The complexity of the tricks depends on the technical foundation of each company. The more technical capabilities of the underlying support, the more tricks can be played. Of course, the premise is to match the target scenario, that is, to connect with the target market. Never envy the various functions of giant equipment manufacturers, let alone copy their homework; they may be worried about their obesity and are thinking about how to lose weight.

Why do you say that? Let's analyze the role of CPE in the above architecture:

• Traffic diversion: that is, sending traffic to a designated location, such as the best POP point, or directly to the CPE at the other end. As long as traffic diversion can be completed, there is no need to be limited to a specific implementation method.
• Traffic diversion: The closer the diversion is to the source, the higher the efficiency of the entire network and the better the user experience. The closer the semantics of the diversion are to the application and the more accurate they are, the more advanced processing can be done, the higher the efficiency of the entire network and the better the user experience. In terms of application identification and application diversion, there are basically leading companies in China. I recommend Panabit for the third time.
• Transmission security: that is, encrypting the target traffic. Most of the current mainstream CPE forms use protocols such as IPSec. IPSec naturally supports interest flows (this name is really good), so transmission security can be completed together with traffic diversion, but from a functional logic point of view, they still need to be distinguished.
• Basic security: basic firewalls, such as the traditional ACL solution based on five-tuples. I think the direct reason is that CPE brings a new network boundary, so CPE must at least ensure that it will not become a pig teammate.
• Security capabilities: refers to advanced security capabilities, such as IPS, UTM, NGFW, WAF, etc.
• Basic scheduling: For example, priority, QoS and preemption between different physical lines and tunnels. I think this is mainly because, unlike SDN products, SD-WAN products do not emphasize underlay bearer. In this case, how to serve applications well? At least at the underlay line level and overlay tunnel level, we need to support some tricks.
• Optimization capabilities: including multi-path packet replication, FEC, caching, compression, deduplication, protocol optimization or proxy, etc. Because different vendors have different basic and advanced capabilities, they are simply put in one category here. However, you may have noticed that these capabilities are becoming more and more similar to CDN capabilities.

7 Prescription

Then we can go from the lesion to the pathogenesis to the prescription. Everyone has different physiques and symptoms, and there are many similar and different medicines. Therefore, when talking about prescriptions, the more critical thing is the prescription logic. After understanding the prescription logic, the medicines of each person will basically be different. So this chapter can only be regarded as a medicine guide, and the medicine needs to be picked by yourself. Let's do some more deductions. The analysis ideas are as follows, for reference only.

1) First, confirm whether you agree: "The essence of SD-WAN is the cloudification of WAN, and its soul is applications and scenarios." If necessary, you can refer to: "Understanding the SD-WAN Industry: Looking at SD-WAN from the Perspective of WAN Cloudification". I will not repeat it here.

2) "Applications and scenarios" naturally have a characteristic: they vary greatly and cannot be generalized. In this way, higher requirements for product architecture will be derived: product architecture needs to be flexible enough to allow solution personnel to build "differentiated industry needs" with "relatively stable products" under the support of "flexible product architecture". When I wrote this sentence, I always felt that it sounded familiar. After thinking about it, isn't this also the evolution logic of 5G core network SBA?

3) Since "it is essentially the cloudification of WAN", a big part of it is to consider how to make the product customer value of cloud: agility, elasticity, and pay-as-you-go. Agility is, to a certain extent, the basis of the latter two, so let's focus on agility first.

4) Agility is the “customer value” of the cloud, so we should focus on the service touchpoints of the product.

5) As mentioned before , there are two main service touchpoints for SD-WAN products:

• Portal: self-service interface. Some customers are big shots and will not use portal for self-service, but the portal should still be provided to the big shot's butler; in addition, the word "potal" here should be broad, that is, API integration should be considered. Potal is based on the Web and naturally has the customer value of the cloud, not a bottleneck (not entirely correct, the perspective of the equipment vendor is prone to problems, but let's skip it for now).
• CPE: Through the above "lesion" analysis, it can be seen that CPE is a major bottleneck.

6) So , the crux can be concluded as follows: the nature of the product requires CPE to be flexible, but in the system model of current mainstream products, CPE has too many functions and is very inflexible, a kind of existence that people love and hate. Why does CPE have to bear such a heavy burden? It is related to the business direction we choose, that is, it is limited by the business model.

7) Therefore , the prescription can be summarized as: understand the essence of your own business model, design independent logical CPE functions for each business model; if there is a need to support multiple scenarios, then sort out all the business models that need to be supported, and ask the architect how to synthesize a product architecture that suits you. That is, consider how to integrate on the basis of sufficient analysis and construction (another subtext is: if you are limited by your ability and cannot integrate, it is recommended to give up temporarily, start with what you are most capable of doing one by one, and live leanly rather than starve to death with puffiness). After all, a relatively unified general architecture is generally grown; and when the relevant parties have the same worldview, the grown architecture is basically the same.

However, at that time, whether CPE was still called CPE or SD-WAN was still called SD-WAN was still unknown. However, as long as it is useful to society and can create value, who cares about the name?

Let's verify it again. SD-WAN can be divided into nominal market and intangible market. Previously, we analyzed the nominal market. Today, we try to get a glimpse of the whole picture through AWS. Is AWS doing SD-WAN? Yes, some people think it is "Transit Gateway + partner's SD-WAN Edge". If we raise the level of abstraction, is AWS's Lambda@Edge using SD-WAN? Is AWS's Greengrass using SD-WAN? Is AWS's Outposts using SD-WAN? Is AWS's Wavelength using SD-WAN? I think the overall architecture of these products should be in line with the above typical product architecture of SD-WAN and the typical network architecture of SD-WAN. A more extreme example is that a robot company was found to have built an SD-WAN network and called it the robot's neural network (Nerve Network). I think they can all be attributed to the implicit market, but the independent scenarios they serve are far more than the nominal market of "US$4-6 billion", so they are disdainful of saying that they are doing SD-WAN. Here is another interesting question: Why did AWS choose the "Transit Gateway + partner's CPE" route in the direction of enterprise networking that everyone is doing? Is it because AWS does not have the strength in this area? Forget it. I personally think that this is the strength of AWS product planning. The reason for choosing "Transit Gateway + partner's CPE" to implement this business direction is probably because:

• Enterprise networking is essential for 2B cloud computing and must be supported, so it must be done;
• The Transit Gateway in the enterprise network can meet the essence of the cloud and can be integrated into a larger cloud product system, so you have to do it yourself;
• The CPE in the enterprise network does not conform to the essence of the cloud, nor can it be included in the larger cloud product system. It does not conform to AWS's positioning as a cloud vendor. This part should be outsourced immediately. There are people waiting in line to do this "hard work". Why not?

Therefore, if we examine CPE again with the idea of ​​"deconstructing first and then integrating the long architecture":

• The function that CPE must retain is the ability to attract traffic;
• The second batch of functions are diversion, basic scheduling, transmission security and basic security;
• The final batch of functions will be optimization and security capabilities.

That is, in extreme cases, except for the ability to divert traffic, other functions of CPE can be selected and allocated according to the scenario.

That is, at the product level, if we want to make the product light and cloud-like, the logical functions undertaken by CPE must be light. The lighter, the less noticeable, and the more flexible the business.

Obviously, to put it directly, it is to directly select application scenarios and strip away unnecessary functions. In this regard, the most direct example is the increasing number of apps from various manufacturers. However, although they all seem to be apps, different apps may play different roles in their respective product architectures. Some are more like access points, while some are starting to become heavier like physical CPEs. In fact, you can do anything in this regard, but it is best to really know what you are doing, what you can reuse when you develop to the next stage, and so on.

Another approach is to go the other way and go heavyweight, making the CPE bigger and thicker, and then stuffing it into the POP to achieve "lightweight" through reuse. In this case, the most basic way to divert traffic is to use the end or a certain method.

Therefore, the logical CPE will be split into two parts:

• On the end side, for example, the SASE end that focuses on strong control is mainly responsible for traffic diversion, transmission security, basic security capabilities, etc.
• Towards the cloud, or the edge, the devices will be transferred to more powerful "network devices with computing" or "computing devices with network" near the center, in short, cloud-network fusion devices. In the context of the explosion of boxes on the client side, it may not be a long-term solution to add another awkward box; the evolution of the form of this box should be in line with the logic of a larger infrastructure transformation.

SASE is the direct successor of SD-WAN, but it is estimated that SASE also has the characteristics of nominal market and intangible market. Similarly, it is likely that the intangible market may be more turbulent. After combing through the use case protocol of ETSI MEC, the direction of MEC may be a greater integration background. Later, from the perspective of MEC use cases, we will further sort out this logic and look back at the technical accumulation cherished by SD-WAN, such as diversion capabilities, basic scheduling capabilities, and optimization capabilities, and how they may be inherited and carried forward to win "fame before and after death."

It is better to transition the idea of ​​“doing SD-WAN” to “using SD-WAN”, that is, to look at the larger stage where SD-WAN is needed.

8. Medicine guide

Business needs are profit needs, and architecture needs are support needs. Most startups do not have much strategic depth. Therefore, an ideal medicine is to gradually transform the product architecture to the future form while continuing the existing SD-WAN business, so that it can support itself in the present and have greater possibilities in the future.

If we follow the logic of WAN cloudification, application acceleration may be a better entry point. At that time, it was more derived from the perspective of ecology and market. Now, based on the above analysis, let's take a look at the relevant logic from the perspective of the product's business model.

The upper and lower halves in the above figure correspond to the simplified business models of enterprise networking and application acceleration. What are the differences between them?

On the surface, there are fewer business elements visible to customers:

• Enterprise networking: branch site A, branch site A CPE, branch site Z, branch site Z CPE (the reason why CPE A and Z must be distinguished is that their specifications and forms may be different);
• Application acceleration: branch site A, branch site A CPE, application Z.

Logically, the implicit business elements are simplified even more. Intranet planning, access mode, connection strategy, line strategy, legacy system support, etc. in enterprise networking can basically be excluded or limited at a low cost in application acceleration scenarios.

As a result, under the current maturity of the ecosystem and technology, enterprise networking is destined to be a non-standard product because it will inevitably touch the customer's intranet, while application acceleration is relatively easier to make a standard product. What are the functions of standard products:

• Low entry complexity: Enterprise networking only "sounds" simple, but it is not easy to do, and you will encounter a lot of practical problems; standard products are easier to enter, and note that it means entry, not being limited to it.
• All-round low replication costs (provided that there is matching architecture support), closer to the cloud form.

When deployed, what is the role of the hidden "branch site Z CPE"?

• The multiple-choice questions that were originally exposed to customers were transformed into cheat sheets that they could answer themselves.
• Get to know the logical CPE in the POP earlier (if any; but this is also in line with the SASE direction), what specific needs need to be met, and they must be different from traditional physical CPE.
• Agility is the bigger theme. The more agile you can achieve at the basic level, the greater the potential boost to upper-level businesses. That is, even a slight improvement in the direction of agility at the product system level may lead to more and greater innovations at the operational level. Such innovations may need to come from the SA team, BD team, etc. after the system is ready.

In addition, there is one point that is worth being a little relieved about: if we look at it from a larger cloud context, the enterprise intranet is being gradually hollowed out, that is, the content that originally required the formation of the intranet is gradually transforming into content that needs to be accelerated.

Therefore, application acceleration may be a better entry point for WAN cloudification.

Finally, we have to admit that not all companies may be suitable for application acceleration. The above is just an example of product analysis.

Open question: In the direction of application acceleration, can we further create a business model like the one shown below? Its benefits are very attractive: customers no longer need any CPE and can be extremely agile. If it can be realized, what limitations may there be? Can it also be applied to enterprise networks?

About the author: Zhang Yunfeng, a practitioner in cloud-network integration related industries