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 protected]> 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> > > 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 protected] > > > > -----Original Message----- > From: spring [mailto:[email protected]] On Behalf Of Lou Berger > Sent: Tuesday, July 3, 2018 4:54 PM > To: Robert Raszuk <[email protected]>; Jeff Tantsura < > [email protected]> > Cc: SPRING WG List <[email protected]>; Linda Dunbar < > [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 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 > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/spring > > > > _______________________________________________ > > spring mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/spring > > ____________________________________________________________ > _______________ > > 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. > ____________________________________________________________ > _______________ >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
