Jeff, Replies are inserted below:
From: Jeff Tantsura [mailto:[email protected]] Sent: Monday, July 02, 2018 5:36 PM To: Linda Dunbar <[email protected]>; Robert Raszuk <[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, (not speaking as rtgwg chair, where you might want to present the draft) [Linda] Yes, we have another draft describing the gap of existing protocols to address SD-WAN scenarios: https://datatracker.ietf.org/doc/draft-dm-net2cloud-gap-analysis/, which we would like to present to RTGwg as it touches protocols in several WGs. The scenario we are talking about is really - WAN (underlay/transport) controller interworking with SD-WAN (overlay) controller. [Linda] Yes. Resource allocation could happen by either WAN controller pre-allocating resources and then exposing them to SD-WAN controller for consumption (ala carte) or SD-WAN controller asking for a particular set of resources (on demand) and WAN controller providing these. In any case – there’s business relationship between 2 or more parties, so from functionality prospective a node that is transit (not service aware) should forward the traffic based on the destination, while node that is service aware (BSID anchor) should pop IP/UDP and lookup the BSID/steer the traffic into SR policy, using SPRING lingo. [Linda] The Resource management are completely within the operator’s domain. The draft is only to describe a way to force SD-WAN traffic to the selected Ingress PEs (and potentially the desired egress PEs). How those Ingress PEs and Egress PEs are selected is completely out of the scope of the draft. The section 3.3 describes How & Why SR is useful for those use cases. SRinUDP encap provides ability to traverse non SR /3rd party networks, BSID (has to be provided by WAN controller at the resource allocation time) is pushed by source SD-WAN node with the FEC that is associated with the particular behavior and hence doesn’t require any additional mapping, e.g BSID value is the mapping (BSID lookup yields an egress adj/tunnel) [Linda] SRinUDP is another case (which hasn’t been discussed in the draft yet, should be added in the future). The draft currently only covers SD-WAN source node encapsulate some “Key” in the tunnel between SD-WAN source node and SR Ingress node, so that SR ingress node can map the flow to its desired Binding SID. Hope this makes sense to you [Linda] Absolutely. Thank you very much for the suggestion. Cheers, Jeff From: spring <[email protected]<mailto:[email protected]>> on behalf of Linda Dunbar <[email protected]<mailto:[email protected]>> Date: Monday, July 2, 2018 at 15:11 To: Robert Raszuk <[email protected]<mailto:[email protected]>> Cc: SPRING WG List <[email protected]<mailto:[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 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]> [mailto:[email protected]] On Behalf Of Robert Raszuk Sent: Monday, July 02, 2018 4:50 PM To: Linda Dunbar <[email protected]<mailto:[email protected]>> Cc: SPRING WG List <[email protected]<mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
