Subject: Can SD-WAN integrating with SR solve some of the problems discussed in draft-ietf-rtgwg-net2cloud-problem-statement?

From: Linda Dunbar <[email-masked]>
Date: Fri, 4 Oct 2019 16:28:21 +0000

Darren,  Clarence, Gaurav, Xiaohu, Daniel, Pablo, and Francois,

Since your draft-dukes-spring-sr-for-sdwan-02 describes on how SR enables underlay SLA to Software-Defined WAN (SDWAN), we want to get your feedback on the https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-problem-statement/ which discusses the problems associated with using SD-WAN to interconnect Hybrid Cloud DCs. The draft focuses on the network problems that many enterprises face when they have workloads & applications & data split among different data centers, especially for those enterprises with multiple sites that are already interconnected by VPNs (e.g., MPLS L2VPN/L3VPN,, and/or SR).
Want your feedback on whether SD-WAN integrating with SR can solve some of the problems discussed in the draft?
SD-WAN interconnection of branch offices is not as simple as it appears. For an enterprise with multiple sites, using SD-WAN overlay paths among sites requires each CPE to manage all the addresses that local hosts have the potential to reach, i.e., map internal VPN addresses to appropriate SD-WAN paths. This is similar to the complexity of Frame Relay based VPNs, where each CPE needed to maintain mesh routing for all destinations if they were to avoid an extra hop through a hub router. Even though SD-WAN CPEs can get assistance from a central controller (instead of running a routing protocol) to resolve the mapping between destinations and SD-WAN paths, SD-WAN CPEs are still responsible for routing table maintenance as remote destinations change their attachments, e.g., the dynamic workload in other DCs are de-commissioned or added.
Even though originally envisioned for interconnecting branch offices, SD-WAN offers a very attractive way for enterprises to connect to Cloud DCs.
The SD-WAN for interconnecting branch offices and the SD-WAN for interconnecting to Cloud DCs have some differences:

  *   SD-WAN for interconnecting branch offices usually have two end-points (e.g., CPEs) controlled by one entity (e.g., a controller or management system operated by the enterprise).
  *   SD-WAN for Cloud DC interconnects may consider CPEs owned or managed by the enterprise, while remote end-points are being managed or controlled by Cloud DCs (For the ease of description, let's call such CPEs asymmetrically-managed CPEs).
  *   Cloud DCs may have different entry points (or devices) with one entry point that terminates a private direct connection (based upon a leased line for example) and other entry points being devices terminating the IPsec tunnels, as shown in Figure 2.

Thank you very much.
Linda Dunbar