Subject: [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

From: Linda Dunbar <[email-masked]>
Date: Mon, 2 Jul 2018 21:33:46 +0000

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

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 2 Jul 2018 23:50:17 +0200

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-masked]>
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.
> 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 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-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 2 Jul 2018 22:11:04 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Monday, July 02, 2018 4:50 PM
To: Linda Dunbar <[email-masked]>
Cc: SPRING WG List <[email-masked]>
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,

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-masked]<mailto:[email-masked]>> 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.

Thank you very much.

Linda Dunbar

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 02 Jul 2018 15:36:10 -0700

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-masked]> on behalf of Linda Dunbar <[email-masked]>
Date: Monday, July 2, 2018 at 15:11
To: Robert Raszuk <[email-masked]>
Cc: SPRING WG List <[email-masked]>
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, 

Linda

Hi Linda,

Many thx,

Robert.

On Mon, Jul 2, 2018 at 11:33 PM, Linda Dunbar <[email-masked]> wrote:

Thank you very much. 

Linda Dunbar

_______________________________________________ spring mailing list [email-masked] https://www.ietf.org/mailman/listinfo/spring

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 02 Jul 2018 15:40:36 -0700

Robert,

I don’t think “pooling” is the right word, there’s an explicit relationship between underlay and overlay. 

Cheers,

Jeff

From: spring <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Monday, July 2, 2018 at 14:50
To: Linda Dunbar <[email-masked]>
Cc: SPRING WG List <[email-masked]>
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,

Many thx,

Robert.

Thank you very much. 

Linda Dunbar

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 3 Jul 2018 01:02:19 +0200

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-masked]>
wrote:

> 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)
>
>
>
> *From: *spring <[email-masked]> on behalf of Linda Dunbar <
> [email-masked]>
> *Date: *Monday, July 2, 2018 at 15:11
> *To: *Robert Raszuk <[email-masked]>
>
> *Cc: *SPRING WG List <[email-masked]>
> *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/.
>
>
>
> 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-masked] [mailto:[email-masked]] *On Behalf Of *Robert
> Raszuk
> *Sent:* Monday, July 02, 2018 4:50 PM
> *To:* Linda Dunbar <[email-masked]>
> *Cc:* SPRING WG List <[email-masked]>
> *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,
>
>
>
> 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
> 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
> _______________________________________________ spring mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/spring
>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 3 Jul 2018 01:05:24 +0200

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-masked]> wrote:

>> *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:
>> 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
>>
>>
>>
>> *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,
>>
>>
>>
>> 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.

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 02 Jul 2018 16:55:34 -0700

Robert,

“What exactly do you call by "resource allocation" in WAN ?” – anything that is not “best effort”, BW reservation, protection type, number of hops, latency, you name it…

Somehow, between ATM and now we managed to build a technology that would work in both, control and data planes 😉

TE with BW reservation is a working technology, with all the bugs, whether done as a soft state on a device and enforced in FW, aka RSVP-TE or computed on a controller and enforced by policing configuration out of band. We also know pretty well how to compute a constrain path that is loop free and with the constrains. Either way, working stuff.

While I agree with caution, there’s business push to provide technology where overlay’s business logic could interwork with underlay. 

To make my points clear – I’m not arguing with the business need but have my doubts about the technology proposed.

Cheers,

Jeff

From: <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Monday, July 2, 2018 at 16:05
To: Jeff Tantsura <[email-masked]>
Cc: Linda Dunbar <[email-masked]>, SPRING WG List <[email-masked]>
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

Sorry ... sent too soon. 

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.

Jeff,

> 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-masked]> wrote:

Hi Linda,

Cheers,

Jeff

Robert, 

Linda

Hi Linda,

Many thx,

Robert.

Thank you very much. 

Linda Dunbar

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 3 Jul 2018 10:07:31 +0200

Hello Jeff,

“What exactly do you call by "resource allocation" in WAN ?” – anything
> that is not “best effort”, BW reservation, protection type, number of hops,
> latency, you name it…
>
>
>
> Somehow, between ATM and now
> *​​*
> *we managed to build a technology that would work in both, control and
> data planes* 😉
>
> TE with BW reservation is a working technology, with all the bugs, whether
> done as a soft state on a device and enforced in FW, aka RSVP-TE or
> computed on a controller and enforced by policing configuration out of
> band. We also know pretty well how to compute a constrain path that is loop
> free and with the constrains. Either way, working stuff.
>

​It has been nearly 20 years and it seems that some marketing slides from
vendors are still in minds of many many people ...

MPLS-TE does *NOT* do any data plane reservations nor any data plane
resource allocation. It is all control plane game. Let me shock you even
more today ... what we call "Guaranteed Bandwidth TE" also does *NOT*
perform any data plane reservations. This up to current days is the most
misunderstood element (or hidden secret) of one of the technologies which
has been made available during the last two decades.

If you signal MPLS TE LSP with 5M "reservation" to check if such a path in
your network can be established such check is *ONLY* done at the control
plane (RP/RE) pools of available bandwidth (per priority level) registers
and physical interfaces nor any data plane queues are never aware of it.

Now what is a direct consequence of this is if you like to really do
control plane reservations and think of it as actual data plane you must do
it in 1:1 fashion - again all done in control plane. That means that two
fundamental conditions must be met:

A) All traffic must be sent over MPLS-LSPs - be it IPv4, IPv6, multicast
etc ... - even if I have seen 3 networks trying to do that for IPv4 no one
did it for all traffic types.

B) All traffic entering your network must be subject to very strict
admission control and excess shaped or dropped which is very hard thing to
do considering statistical multiplexing gains you count on in any IP
network (Explanation: On any single ingress node you must apply strict CAC
as you are not aware about what traffic is coming from other ingress nodes.
So you may be dropping or shaping traffic which could flow through your
network just fine end to end due to absence of competing class from
different ingress).
​
​All RSVP-TE does is traffic steering in normal steady state or during
protection. That's all. In the WAN's data plane it is all back to basic
Diff Serve at each router's data plane.

The only technology which does provide interface data plane reservation is
RSVP IntServ - but I doubt anyone here or Linda in her draft meant to use
such tool.

Why am I jumping on this here in SPRING WG list ... Well few months ago I
have witnessed a discussion where someone was arguing that SR is much worse
then MPLS-TE as it does not provide any data plane reservations. When I
tried to nicely and politely explain how confused the person is the look I
got was comparable to those green folks walking down from just arrived UFO.

So to conclude SR just like MPLS-TE does a good job in packet steering via
your domain. (SR can do actually more via embedded functions/apps). But the
fundamental difference is that SR does that steering without necessity of
number of control plane protocols and their required extensions - so does
simplify control plane significantly. Neither of those do any data plane
reservations and all bandwidth contentions need to be resolved via classic
QoS.

Cheers,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 3 Jul 2018 14:52:39 +0200

Hi Linda,

For sure there are number of SPs trying to catch-up with change in WAN
paradigm and therefor starting to offer their own SD-WAN solutions. After
all keeping customer locked is in their revenue interest.

However your proposal is a bit different. As you just stated it is SPs
trying to "attract flows".

So let's take real life example. I have created 20 global sites
interconnected over Internet using SD-WAN Sproute Networks overlay. I am
managing those 20 sites, applying different SLAs requirements, adding &
deleting sites all using their virtual controller in AWS. Works like a
charm !

Now assume I would like to cross Pacific between Asia & California using
IIJ and not Telstra. Few simple questions:

* How any ISP/SP will attract my traffic ? - I am looking what protocol and
what payload will be there to tell me that I should go via given ISP
network. Would that talk tgo my controller or directly to CPEs ?

* To get to such ISP/SP - I would need to double encapsulate my data such
that while traversing local last mile ISPs or cable operators my packets in
spite of regular routing will arrive at such ISP. So the ISP signalling
will also need to tell me a way they will recognize that those are my
streams of data.

** Note that long long time ago I had a patent entered regarding
encapsulation to special IP address with embedded 4 octet AS number such
that when packet arrives at any ingress router to such AS it will be
decapsulated automatically and routed along the path. Perhaps you could
leverage this idea in your work :)

Many thx,
Robert.

---

From: Lou Berger <[email-masked]>
Date: Tue, 3 Jul 2018 09:53:45 -0400

Hi Robert,

On 7/3/2018 4:07 AM, Robert Raszuk wrote:
> Hello Jeff,
>
>     “What exactly do you call by "resource allocation" in WAN ?” –
>     anything that is not “best effort”, BW reservation, protection
>     type, number of hops, latency, you name it…
>
>     *we managed to build a technology that would work in both, control
>     and data planes* 😉
>
>     TE with BW reservation is a working technology, with all the bugs,
>     whether done as a soft state on a device and enforced in FW, aka
>     RSVP-TE or computed on a controller and enforced by policing
>     configuration out of band. We also know pretty well how to compute
>     a constrain path that is loop free and with the constrains. Either
>     way, working stuff.
>
>
>
> ​It has been nearly 20 years and it seems that some marketing slides 
> from vendors are still in minds of many many people ...
I think this is *quite* true. There's also quiet a bit of marketing 
documents on what constitutes QoS (vs CoS).

> resource allocation. It is all control plane game. Let me shock you 
> even more today ... what we call "Guaranteed Bandwidth TE" also does 
> *NOT* perform any data plane reservations. This up to current days is 
> the most misunderstood element (or hidden secret) of one of the 
> technologies which has been made available during the last two decades.
>
This *completely* depends on which vendor and platform you choose.

 From the IETF perspective, the RFCs certainly support both reservation 
(i.e., book keeping) and *allocation* of resources, (i.e., configuration 
of data plane queuing and even per flow shaping and policing).   This is 
something that continues to be included in all TE related RFCs to date.

> If you signal MPLS TE LSP with 5M "reservation" to check if such a 
> path in your network can be established such check is *ONLY* done at 
> the control plane (RP/RE) pools of available bandwidth (per priority 
> level) registers and physical interfaces nor any data plane queues are 
> never aware of it.

again, this depends on the vendor and the platform.  Informed users 
understand this and those that care, buy equipment that satisfy their 
requirements.  I have worked on projects on both sides (vendors and 
users/providers) and some care quite a bit about the queuing behavior 
associated with TE, others are perfectly happy with TE as a path 
selection/distribution/pinning tool.

> control plane reservations and think of it as actual data plane you 
> must do it in 1:1 fashion - again all done in control plane. That 
> means that two fundamental conditions must be met:
>
> A) All traffic must be sent over MPLS-LSPs - be it IPv4, IPv6, 
> multicast etc ... - even if I have seen 3 networks trying to do that 
> for IPv4 no one did it for all traffic types.
>
> admission control and excess shaped or dropped which is very hard 
> thing to do considering statistical multiplexing gains you count on in 
> any IP network (Explanation: On any single ingress node you must apply 
> strict CAC as you are not aware about what traffic is coming from 
> other ingress nodes. So you may be dropping or shaping traffic which 
> could flow through your network just fine end to end due to absence of 
> competing class from different ingress).
> ​
> protection. That's all. In the WAN's data plane it is all back to 
> basic Diff Serve at each router's data plane.
>
> The only technology which does provide interface data plane 
> reservation is RSVP IntServ - but I doubt anyone here or Linda in her 
> draft meant to use such tool.

While this statement may be true for certain vendors, it is not true a 
*technology* or standards perspective.

>
> Why am I jumping on this here in SPRING WG list ... Well few months 
> ago I have witnessed a discussion where someone was arguing that SR is 
> much worse then MPLS-TE as it does not provide any data plane 
> reservations. When I tried to nicely and politely explain how confused 
> the person is the look I got was comparable to those green folks 
> walking down from just arrived UFO.
>

While I certainly accept that for some vendors SR-TE is just as good as 
MPLS-TE, if SR-TE is defined as only supporting path control this will 
be the first instance of a TE RFC/definition (at least that I'm aware 
of) that won't support resource allocation, i.e., *any* form of traffic 
treatment (queue) control.

> So to conclude SR just like MPLS-TE does a good job in packet steering 
> via your domain. (SR can do actually more via embedded 
> functions/apps). But the fundamental difference is that SR does that 
> steering without necessity of number of control plane protocols and 
> their required extensions - so does simplify control plane 
> significantly. Neither of those do any data plane reservations and all 
> bandwidth contentions need to be resolved via classic QoS.

There is a major difference here in what you characterize here, i.e., 
SR-TE, and how the 'TE' term is used in the existing set of RFCs.  I 
don't know how we (the IETF) want to denote this difference - I suspect 
this will depend on which WG is asked.  In this group it seems that  
some (perhaps many) are perfectly happy to have SR-TE *not* include 
actual resource allocation and traffic treatment (queue) control - I 
personally would prefer that it be included so that the part of the 
market that cares about such can be supported albeit with the need for 
users to evaluate actual vendor TE implementations as is done today.

Lou

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 3 Jul 2018 14:12:21 +0000

Hi all,

Looking at this thread I come to conclusion (probably knew that before as well) that existing RFCs dealing with MPLS-TE simply do not define whether Diff-Serv resources are or are not allocated per LSP. Specifically, RFC 3270 (not sure what else to look at) only says

<quote>

   When bandwidth requirements are signaled at the establishment of an

   L-LSP, the signaled bandwidth is obviously associated with the L-

   LSP's PSC.  Thus, LSRs which use the signaled bandwidth to perform

   admission control may perform admission control over Diff-Serv

   resources, which are dedicated to the PSC (e.g., over the bandwidth

   guaranteed to the PSC through its scheduling weight).

   When bandwidth requirements are signaled at the establishment of an

   E-LSP, the signaled bandwidth is associated collectively with the

   whole LSP and therefore with the set of transported PSCs.  Thus, LSRs

   which use the signaled bandwidth to perform admission control may

   perform admission control over global resources, which are shared by

   the set of PSCs (e.g., over the total bandwidth of the link).

<end quote>

Note that this text does not even define some optional behavior, as it does not use the IETF capitalized MAY.

Did I miss something?

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

Email:   [email-masked]

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Tuesday, July 3, 2018 4:54 PM
To: Robert Raszuk <[email-masked]>; Jeff Tantsura <[email-masked]>
Cc: SPRING WG List <[email-masked]>; Linda Dunbar <[email-masked]>
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 Robert,

> from vendors are still in minds of many many people ...

I think this is *quite* true. There's also quiet a bit of marketing documents on what constitutes QoS (vs CoS).

From the IETF perspective, the RFCs certainly support both reservation (i.e., book keeping) and *allocation* of resources, (i.e., configuration of data plane queuing and even per flow shaping and policing).   This is something that continues to be included in all TE related RFCs to date.

> never aware of it.

again, this depends on the vendor and the platform.  Informed users understand this and those that care, buy equipment that satisfy their requirements.  I have worked on projects on both sides (vendors and

users/providers) and some care quite a bit about the queuing behavior associated with TE, others are perfectly happy with TE as a path selection/distribution/pinning tool.

While I certainly accept that for some vendors SR-TE is just as good as MPLS-TE, if SR-TE is defined as only supporting path control this will be the first instance of a TE RFC/definition (at least that I'm aware

of) that won't support resource allocation, i.e., *any* form of traffic treatment (queue) control.

> bandwidth contentions need to be resolved via classic QoS.

There is a major difference here in what you characterize here, i.e., SR-TE, and how the 'TE' term is used in the existing set of RFCs.  I don't know how we (the IETF) want to denote this difference - I suspect this will depend on which WG is asked.  In this group it seems that some (perhaps many) are perfectly happy to have SR-TE *not* include actual resource allocation and traffic treatment (queue) control - I personally would prefer that it be included so that the part of the market that cares about such can be supported albeit with the need for users to evaluate actual vendor TE implementations as is done today.

Lou

spring mailing list

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 3 Jul 2018 16:17:40 +0200

Hi Lou,

>  *allocation* of resources (i.e., configuration of data plane queuing and
even per flow shaping and policing).

I will continue this topic as I do think it is quite important to be on the
same page in this WG and beyond. I guess we are at the fudamental question
what does it mean to "allocate or reserve a resource".

Clearly configuration of shaping and policing does not fall under such
definition.

Also as stated already sizing the queues is basic diffserv. Remember that
diffserv does not hard reserve anything too. It prioritizes traffic and I
have not seen any implementation which would automatically adjust queue
depths based on the reception of RSVP-RESV msg.

To me "resource allocation" brings memory of SDH containers and TDM
networks which is a bit misleading if someone even remotely tries to map it
to diffserv.

And since this is SPRING SR since day one claims full support for diffserv
both in SR-MPLS as well as SRv6 architectures.

Best,
R.

On Tue, Jul 3, 2018 at 3:53 PM, Lou Berger <[email-masked]> wrote:

> (i.e., book keeping) and *allocation* of resources, (i.e., configuration of
> data plane queuing and even per flow shaping and policing).   This is
>> The only technology which does provide interface data plane reservation
>> is RSVP IntServ - but I doubt anyone here or Linda in her draft meant to
>> use such tool.
>>
>
> MPLS-TE, if SR-TE is defined as only supporting path control this will be
> the first instance of a TE RFC/definition (at least that I'm aware of) that
> won't support resource allocation, i.e., *any* form of traffic treatment
> (queue) control.
>
>
> SR-TE, and how the 'TE' term is used in the existing set of RFCs.  I don't
> know how we (the IETF) want to denote this difference - I suspect this will
> depend on which WG is asked.  In this group it seems that  some (perhaps
> many) are perfectly happy to have SR-TE *not* include actual resource
> allocation and traffic treatment (queue) control - I personally would
> prefer that it be included so that the part of the market that cares about
> such can be supported albeit with the need for users to evaluate actual
> vendor TE implementations as is done today.
>
> Lou
>
>>
>> Cheers,
>> R.
>>
>>
>>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 3 Jul 2018 16:21:56 +0200

Hi,

Admission control is extremely important on ingress to the TE-LSPs. Without
it even the pure control plane reservation games all melt. That is also
fundamentally supported by any vendor I am ware of with MPLS-TE. For SR - I
do not know.

But this is still not what I consider data plane hard reservation over
entire LSP end to end path.

Best,
R.

On Tue, Jul 3, 2018 at 4:12 PM, Alexander Vainshtein <
[email-masked]> wrote:

> Hi all,
>
> Looking at this thread I come to conclusion (probably knew that before as
> well) that existing RFCs dealing with MPLS-TE simply do not define whether
> Diff-Serv resources are or are not allocated per LSP. Specifically, RFC
> 3270 (not sure what else to look at) only says
>
> <quote>
>
> Subject: Re: [spring] solicit feedback on draft-dunbar-sr-sdwan-over-hybrid-networks-02
> the first instance of a TE RFC/definition (at least that I'm aware
>

---

From: James N Guichard <[email-masked]>
Date: Tue, 3 Jul 2018 14:22:10 +0000

Hi Sasha,

I am also now scratching my head but reading https://datatracker.ietf.org/doc/rfc4124/ “Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering” it states in section 6.3 (Handling CLASSTYPE Object) that:

“During establishment of an LSP corresponding to the Class-Type N, the LSR MUST perform admission control over the bandwidth available for that particular Class-Type”.

I have always taken this to mean that the LSR will automatically update the queues for that bandwidth class and perform admission control in the data plane based upon the markings of the packets. If my understanding is incorrect then I would welcome correction!

Jim

From: spring [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Tuesday, July 03, 2018 10:12 AM
To: Lou Berger <[email-masked]>; Robert Raszuk <[email-masked]>; Jeff Tantsura <[email-masked]>
Cc: SPRING WG List <[email-masked]>; Linda Dunbar <[email-masked]>
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 all,

<quote>

<end quote>

Did I miss something?

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

Email:   [email-masked]<mailto:[email-masked]>

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Tuesday, July 3, 2018 4:54 PM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Jeff Tantsura <[email-masked]<mailto:[email-masked]>>
Cc: SPRING WG List <[email-masked]<mailto:[email-masked]>>; Linda Dunbar <[email-masked]<mailto:[email-masked]>>
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 Robert,

Lou

spring mailing list

---

From: Lou Berger <[email-masked]>
Date: Tue, 3 Jul 2018 10:58:48 -0400

On 7/3/2018 10:17 AM, Robert Raszuk wrote:
> Hi Lou,
>
> > *allocation* of resources (i.e., configuration of data plane queuing 
> and even per flow shaping and policing).
>
> I will continue this topic as I do think it is quite important to be 
> on the same page in this WG and beyond. I guess we are at the 
> fudamental question what does it mean to "allocate or reserve a 
> resource".
to me
reserve = bookkeeping
allocate = assign specific resource to ensure specific traffic treatment

> Clearly configuration of shaping and policing does not fall under such 

why not?  I agree it's not needed for reservation, but it is needed for 
allocation.

>
> Also as stated already sizing the queues is basic diffserv. Remember 
> that diffserv does not hard reserve anything too. It prioritizes 
> traffic and I have not seen any implementation which would 
> automatically adjust queue depths based on the reception of RSVP-RESV 
> msg.
I've seen ones that adjust based on Path;-)

> networks which is a bit misleading if someone even remotely tries to 
> map it to diffserv.
Fair enough.  Keep not every TE LSP is and E-LSP or L-LSP.

>
> And since this is SPRING SR since day one claims full support for 
> diffserv both in SR-MPLS as well as SRv6 architectures.
>

Sure - feel free to see my comments in the context of SR-TE (only) 
rather than SR with DiffServ.

Lou

> Best,
> R.
>
>
> On Tue, Jul 3, 2018 at 3:53 PM, Lou Berger <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Robert,
>
>
>         ​It has been nearly 20 years and it seems that some marketing
>         slides from vendors are still in minds of many many people ...
>
>     I think this is *quite* true. There's also quiet a bit of
>     marketing documents on what constitutes QoS (vs CoS).
>
>
>         MPLS-TE does *NOT* do any data plane reservations nor any data
>         plane resource allocation. It is all control plane game. Let
>         me shock you even more today ... what we call "Guaranteed
>         Bandwidth TE" also does *NOT* perform any data plane
>         reservations. This up to current days is the most
>         misunderstood element (or hidden secret) of one of the
>     From the IETF perspective, the RFCs certainly support both
>     reservation (i.e., book keeping) and *allocation* of resources,
>     (i.e., configuration of data plane queuing and even per flow
>     shaping and policing).   This is something that continues to be
>     included in all TE related RFCs to date.
>
>         If you signal MPLS TE LSP with 5M "reservation" to check if
>         such a path in your network can be established such check is
>         *ONLY* done at the control plane (RP/RE) pools of available
>         bandwidth (per priority level) registers and physical
>         interfaces nor any data plane queues are never aware of it.
>
>
>     understand this and those that care, buy equipment that satisfy
>     their requirements.  I have worked on projects on both sides
>     (vendors and users/providers) and some care quite a bit about the
>     queuing behavior associated with TE, others are perfectly happy
>     with TE as a path selection/distribution/pinning tool.
>
>
>         Now what is a direct consequence of this is if you like to
>         really do control plane reservations and think of it as actual
>         data plane you must do it in 1:1 fashion - again all done in
>         control plane. That means that two fundamental conditions must
>         be met:
>
>         multicast etc ... - even if I have seen 3 networks trying to
>         do that for IPv4 no one did it for all traffic types.
>
>         B) All traffic entering your network must be subject to very
>         strict admission control and excess shaped or dropped which is
>         very hard thing to do considering statistical multiplexing
>         gains you count on in any IP network (Explanation: On any
>         single ingress node you must apply strict CAC as you are not
>         aware about what traffic is coming from other ingress nodes.
>         So you may be dropping or shaping traffic which could flow
>         through your network just fine end to end due to absence of
>         ​All RSVP-TE does is traffic steering in normal steady state
>         or during protection. That's all. In the WAN's data plane it
>         is all back to basic Diff Serve at each router's data plane.
>
>         reservation is RSVP IntServ - but I doubt anyone here or Linda
>         in her draft meant to use such tool.
>
>
>     While this statement may be true for certain vendors, it is not
>     true a *technology* or standards perspective.
>
>
>         Why am I jumping on this here in SPRING WG list ... Well few
>         months ago I have witnessed a discussion where someone was
>         arguing that SR is much worse then MPLS-TE as it does not
>         provide any data plane reservations. When I tried to nicely
>         and politely explain how confused the person is the look I got
>         was comparable to those green folks walking down from just
>         arrived UFO.
>
>
>     While I certainly accept that for some vendors SR-TE is just as
>     good as MPLS-TE, if SR-TE is defined as only supporting path
>     control this will be the first instance of a TE RFC/definition (at
>     least that I'm aware of) that won't support resource allocation,
>     i.e., *any* form of traffic treatment (queue) control.
>
>
>         So to conclude SR just like MPLS-TE does a good job in packet
>         steering via your domain. (SR can do actually more via
>         embedded functions/apps). But the fundamental difference is
>         that SR does that steering without necessity of number of
>         control plane protocols and their required extensions - so
>         does simplify control plane significantly. Neither of those do
>         any data plane reservations and all bandwidth contentions need
>         to be resolved via classic QoS.
>
>
>     There is a major difference here in what you characterize here,
>     i.e., SR-TE, and how the 'TE' term is used in the existing set of
>     RFCs.  I don't know how we (the IETF) want to denote this
>     difference - I suspect this will depend on which WG is asked.  In
>     this group it seems that  some (perhaps many) are perfectly happy
>     to have SR-TE *not* include actual resource allocation and traffic
>     treatment (queue) control - I personally would prefer that it be
>     included so that the part of the market that cares about such can
>     be supported albeit with the need for users to evaluate actual
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/spring>
>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/spring>
>
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 3 Jul 2018 15:29:25 +0000

Jim,
AFAIK the checks are usually for CP only.

Thumb typed by Sasha Vainshtein

From: James N Guichard
Sent: Tuesday, July 3, 17:22
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
To: Alexander Vainshtein, Lou Berger, Robert Raszuk, Jeff Tantsura
Cc: SPRING WG List, Linda Dunbar

Hi Sasha,

Jim

Hi all,

Did I miss something?

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

-----Original Message-----
From: spring [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Tuesday, July 3, 2018 4:54 PM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>; Jeff Tantsura <[email-masked]<mailto:[email-masked]>>
Cc: SPRING WG List <[email-masked]<mailto:[email-masked]>>; Linda Dunbar <[email-masked]<mailto:[email-masked]>>
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 Robert,

Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 3 Jul 2018 11:17:14 -0400

On 7/3/2018 10:12 AM, Alexander Vainshtein wrote:
>
> Hi all,
>
> Looking at this thread I come to conclusion (probably knew that before 
> as well) that existing RFCs dealing with MPLS-TE simply do not define 
> whether Diff-Serv resources are or are not allocated per LSP. 
> Specifically, RFC 3270 (not sure what else to look at) only says
>
> <quote>
>
I don't think you can read too much on the use of lower/uppercase given 
the age of the document (look at inconsistent usage of must/MUST in the 
document for example.)

> Subject: Re: [spring] solicit feedback on 
> (i.e., book keeping) and *allocation* of resources, (i.e., 
> configuration of data plane queuing and even per flow shaping and 
> policing).   This is something that continues to be included in all TE 
> related RFCs to date.
>
> While I certainly accept that for some vendors SR-TE is just as good 
> as MPLS-TE, if SR-TE is defined as only supporting path control this 
> will be the first instance of a TE RFC/definition (at least that I'm aware
>
> don't know how we (the IETF) want to denote this difference - I 
> suspect this will depend on which WG is asked.  In this group it seems 
> that some (perhaps many) are perfectly happy to have SR-TE *not* 
> include actual resource allocation and traffic treatment (queue) 
> control - I personally would prefer that it be included so that the 
> part of the market that cares about such can be supported albeit with 
> the need for users to evaluate actual vendor TE implementations as is 
> done today.
>
> Lou
>
> >
>
> > Cheers,
>
> > R.
>
> >
>
> >
>
> >
>

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 3 Jul 2018 16:38:40 +0000

Robert,

There are two types of SD-WAN described in our draft, one is the Classis SD-WAN as defined by ONUG, which is about two CPEs multiplex MPLS Paths and paths via Public Internet, as shown in the picture below. We have another draft describing the gaps of existing protocol to address this scenario: https://datatracker.ietf.org/doc/draft-dm-net2cloud-gap-analysis/

Another SD-WAN is like the following. Digital Transformation is propelling more and more enterprises to move their workloads/Apps to cloud DCs that are geographically close to their end users to improve end-to-end latency & overall user experience, or to comply with local data protection regulations. Conversely, workloads/Apps in those Cloud DCs can be easily shutdown when their end users’ geographic base changes.
Because of the ephemeral property of the selected Cloud DCs, an enterprise or its network service provider may not have the direct links to the Cloud DCs that are optimal for hosting the enterprise’s specific workloads/Apps. Under those circumstances, SD-WAN is a very flexible choice to interconnect the enterprise on-premises data centers & branch offices to its desired Cloud DCs.

Answers to your questions are inserted below:

Sent: Tuesday, July 03, 2018 7:53 AM

Hi Linda,

For sure there are number of SPs trying to catch-up with change in WAN paradigm and therefor starting to offer their own SD-WAN solutions. After all keeping customer locked is in their revenue interest.

However your proposal is a bit different. As you just stated it is SPs trying to "attract flows".

So let's take real life example. I have created 20 global sites interconnected over Internet using SD-WAN Sproute Networks overlay. I am managing those 20 sites, applying different SLAs requirements, adding & deleting sites all using their virtual controller in AWS. Works like a charm !

Now assume I would like to cross Pacific between Asia & California using IIJ and not Telstra. Few simple questions:

* How any ISP/SP will attract my traffic ? - I am looking what protocol and what payload will be there to tell me that I should go via given ISP network. Would that talk tgo my controller or directly to CPEs ?

[Linda] we are proposing a very simple method that can traverse existing network. Basically SD-WAN controller inform the SD-WAN path Source node on the selected VPN Ingress PE. The SD-WAN Source node use a Tunnel (GRE,  NvGRE, etc) to encapsulate the “IPsec encrypted” payload to the VPN Ingress PE.

* To get to such ISP/SP - I would need to double encapsulate my data such that while traversing local last mile ISPs or cable operators my packets in spite of regular routing will arrive at such ISP. So the ISP signalling will also need to tell me a way they will recognize that those are my streams of data.
[Linda]  Yes, there is IPsec encryption between the two SD-WAN end points. There is a Tunnel encapsulation between the SD-WAN source node and the VPN Ingress PE.

** Note that long long time ago I had a patent entered regarding encapsulation to special IP address with embedded 4 octet AS number such that when packet arrives at any ingress router to such AS it will be decapsulated automatically and routed along the path. Perhaps you could leverage this idea in your work :)

[Linda] Is it possible for you to add the detailed description to the draft?

Thanks, Linda

Many thx,
Robert.

On Tue, Jul 3, 2018 at 12:11 AM, Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

Linda

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 3 Jul 2018 17:59:49 +0000

Jeff,

Replies are inserted below:

From: Jeff Tantsura [mailto:[email-masked]]
Sent: Monday, July 02, 2018 5:36 PM
To: Linda Dunbar <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: SPRING WG List <[email-masked]>
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.

[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.

[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.

[Linda] Absolutely. Thank you very much for the suggestion.

Cheers,
Jeff

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Date: Monday, July 2, 2018 at 15:11
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: SPRING WG List <[email-masked]<mailto:[email-masked]>>
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,

Linda

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Monday, July 02, 2018 4:50 PM
To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Cc: SPRING WG List <[email-masked]<mailto:[email-masked]>>
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,

Many thx,
Robert.

Thank you very much.

Linda Dunbar

_______________________________________________ spring mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/spring

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 3 Jul 2018 20:09:20 +0000

Robert, Jeff, Sasha, Jim, Lou, et al,

Thank you very much for the feedback. The main attraction of SR is indeed its Traffic steering capability, especially when there are multiple egress PEs to reach the SD-WAN end points. SR can easily force a path to traverse the explicitly selected egress node or explicit segments through the SR Domain based on the applications need.

If only using MPLS, quite some configurations are needed to force a flow to a specific egress PE.

Linda

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, July 03, 2018 3:08 AM
To: Jeff Tantsura <[email-masked]>
Cc: Linda Dunbar <[email-masked]>; SPRING WG List <[email-masked]>
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

Hello Jeff,

Somehow, between ATM and now
​​
we managed to build a technology that would work in both, control and data planes 😉
TE with BW reservation is a working technology, with all the bugs, whether done as a soft state on a device and enforced in FW, aka RSVP-TE or computed on a controller and enforced by policing configuration out of band. We also know pretty well how to compute a constrain path that is loop free and with the constrains. Either way, working stuff.

​It has been nearly 20 years and it seems that some marketing slides from vendors are still in minds of many many people ...

MPLS-TE does *NOT* do any data plane reservations nor any data plane resource allocation. It is all control plane game. Let me shock you even more today ... what we call "Guaranteed Bandwidth TE" also does *NOT* perform any data plane reservations. This up to current days is the most misunderstood element (or hidden secret) of one of the technologies which has been made available during the last two decades.

If you signal MPLS TE LSP with 5M "reservation" to check if such a path in your network can be established such check is *ONLY* done at the control plane (RP/RE) pools of available bandwidth (per priority level) registers and physical interfaces nor any data plane queues are never aware of it.

Now what is a direct consequence of this is if you like to really do control plane reservations and think of it as actual data plane you must do it in 1:1 fashion - again all done in control plane. That means that two fundamental conditions must be met:

A) All traffic must be sent over MPLS-LSPs - be it IPv4, IPv6, multicast etc ... - even if I have seen 3 networks trying to do that for IPv4 no one did it for all traffic types.

B) All traffic entering your network must be subject to very strict admission control and excess shaped or dropped which is very hard thing to do considering statistical multiplexing gains you count on in any IP network (Explanation: On any single ingress node you must apply strict CAC as you are not aware about what traffic is coming from other ingress nodes. So you may be dropping or shaping traffic which could flow through your network just fine end to end due to absence of competing class from different ingress).
​
​All RSVP-TE does is traffic steering in normal steady state or during protection. That's all. In the WAN's data plane it is all back to basic Diff Serve at each router's data plane.

The only technology which does provide interface data plane reservation is RSVP IntServ - but I doubt anyone here or Linda in her draft meant to use such tool.

Why am I jumping on this here in SPRING WG list ... Well few months ago I have witnessed a discussion where someone was arguing that SR is much worse then MPLS-TE as it does not provide any data plane reservations. When I tried to nicely and politely explain how confused the person is the look I got was comparable to those green folks walking down from just arrived UFO.

So to conclude SR just like MPLS-TE does a good job in packet steering via your domain. (SR can do actually more via embedded functions/apps). But the fundamental difference is that SR does that steering without necessity of number of control plane protocols and their required extensions - so does simplify control plane significantly. Neither of those do any data plane reservations and all bandwidth contentions need to be resolved via classic QoS.

Cheers,
R.

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 3 Jul 2018 20:25:59 +0000

Just one more point about using SR’s traffic steering capability described in our draft:
when traffic between two end points (E1<-> E2) traverse a SR domain and there are multiple egress PEs (PE-a, PE-b, etc) to reach E2, it is relatively easy for SR to steer some flows towards egress PE-a and other flows towards egress PE-b.

Linda Dunbar

From: Linda Dunbar
Sent: Tuesday, July 03, 2018 3:09 PM
To: 'Robert Raszuk' <[email-masked]>; Jeff Tantsura <[email-masked]>
Cc: SPRING WG List <[email-masked]>
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

Linda

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, July 03, 2018 3:08 AM
To: Jeff Tantsura <[email-masked]<mailto:[email-masked]>>
Cc: Linda Dunbar <[email-masked]<mailto:[email-masked]>>; SPRING WG List <[email-masked]<mailto:[email-masked]>>
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

Hello Jeff,

Cheers,
R.