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 Raszuk <[e-mail]>]

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.