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

[Lou Berger <[e-mail]>]

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

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;-)

>
> 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.
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 <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     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…
>
>             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 ...
>
>     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
>         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.
>
>
>         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.
>
>
>     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
>
>
>         Cheers,
>         R.
>
>
>
>         _______________________________________________
>         spring mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/spring
>         <https://www.ietf.org/mailman/listinfo/spring>
>
>
>     _______________________________________________
>     spring mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/spring
>     <https://www.ietf.org/mailman/listinfo/spring>
>
>