Jeff, I am not sure if I should even get into this ... but oh well why not :)
> 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. On Tue, Jul 3, 2018 at 12:36 AM, Jeff Tantsura <[email protected]> wrote: > Hi Linda, > > > > (not speaking as rtgwg chair, where you might want to present the draft) > > > > The scenario we are talking about is really - WAN (underlay/transport) > controller interworking with SD-WAN (overlay) controller. > > 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. > > > > 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) > > > > Hope this makes sense to you > > > > Cheers, > > Jeff > > > > *From: *spring <[email protected]> on behalf of Linda Dunbar < > [email protected]> > *Date: *Monday, July 2, 2018 at 15:11 > *To: *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 > > > > 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]> > 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] > https://www.ietf.org/mailman/listinfo/spring > > > > _______________________________________________ spring mailing list > [email protected] https://www.ietf.org/mailman/listinfo/spring >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
