Sorry ... sent too soon. What exactly do you call by "resource allocation" in WAN ?
ATM PVCs ? If not all "reservations" are just control plane reservations and they *only* make any sense when you do the same for entire traffic you carry. Even worse unexpected events and vendor bugs will easily destroy your plan ! I advise a lot of caution when anyone is talking about "resource allocation" in IP networks. Thx, R. On Tue, Jul 3, 2018 at 1:02 AM, Robert Raszuk <[email protected]> wrote: > 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
