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
