Robert, There are many definitions for SD-WAN in the industry. I used the one from ONUG, who claims that “SD-WAN” concept was created by them in 2013: https://www.onug.net/software-defined-wide-area-network-sd-wan/.
In terms of real time deployment, there are plenty. For example, here are some public available cases & services: https://youtu.be/JRoTXMSxtCY; http://www.verizonenterprise.com/products/networking/managed-network-services/managed-sdwan/ http://www.centurylink.com/business/networking/sd-wan.html It is CPE pooling together paths from different ISPs. The draft proposes a method for Service Provider to attract flows which would otherwise traverse public internet, to traverse its own domain. Linda From: [email protected] [mailto:[email protected]] On Behalf Of Robert Raszuk Sent: Monday, July 02, 2018 4:50 PM To: Linda Dunbar <[email protected]> Cc: SPRING WG List <[email protected]> Subject: Re: [spring] solicit feedback on draft-dunbar-sr-sdwan-over-hybrid-networks-02 proposing SD-WAN source node using UDP port to indicate to SR ingress node how to map to appropriate Binding SID Hi Linda, You mentioned in the document the below quote: "SD-WAN, as described by ONUG (Open Network User Group), is about pooling WAN bandwidth from n service providers to get better WAN bandwidth management, visibility & control." Can you provide some real life examples listing which service providers allow to be externally pooled for their available WAN bandwidth as well as what interface is used to get such pooling instantiated in place ? Once we understand above next natural question would be to ask how accurate is such pooling in the light of the observation that due to basic characteristics of the service provider's traffic patterns available bandwidth or in other words congestion usually have very transient nature ? If I were writing such document I would give up any pooling and instead use one of many available techniques to measure the end to end path quality when making at the ingress the decision of the preferred path to be taken. That is in fact what number of SD-WANs today already do without any need to make any attempts to enforce anything at the ingress to the transit journey :). Many thx, Robert. On Mon, Jul 2, 2018 at 11:33 PM, Linda Dunbar <[email protected]<mailto:[email protected]>> wrote: https://datatracker.ietf.org/doc/draft-dunbar-sr-sdwan-over-hybrid-networks/ describes a method for end-to-end (E2E) SD-WAN paths (most likely encrypted) to traverse specific list of network segments, some of which are SR enabled and others may be IP networks that do not support SR, to achieve the desired optimal E2E quality. In another word, one or both SD-WAN end points are NOT directly attached to SR PE nodes. Under many circumstances the SR's Binding SID can't be exposed to the SD-WAN source node (e.g. if the SD-WAN source node belongs to a different administrator than the one who manage/own the SR domain). The draft propose a method for SR Controller to expose a "Key" to the SD-WAN source node. The SR Ingress node will map the "Key" carried by the SD-WAN traffic/flows to their designated Binding SID. The "Key" can be carried by GRE key field, or be encoded as UDP Source Port used by SD-WAN source node to differentiate flows. We understand that UDP source port is usually used for Entropy purpose. We want to hear feedback, flaws or allergic reaction to our proposed method for some deployment scenarios like: 1) only one or two 3rd party hops are between SD-WAN end points and PE and those hops may not even use Entropy (like LTE links); or 2) Grouping Applications by UDP ports may enforce same application traverse through same route, which is acceptable by many deployment scenarios). Thank you very much. Linda Dunbar _______________________________________________ spring mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
