> On 1/Oct/18 12:16, adamv0...@netconsultings.com wrote: > > > Hi folks,
Hi Adam, On Mon, 1 Oct 2018 at 12:00, Mark Tinka <mark.ti...@seacom.mu> wrote: > > So we don't do any label signaling via RSVP-TE at all. > > We use DSCP, but really only for on-net traffic. > > Off-net traffic (like the Internet) is really treated as best-effort. > You can't prioritize what you can't control. Yeah so not already using RSVP means that we're not going to deploy it just to deploy an IntServ QoS model. We also use DSCP and scrub it off of dirty Internet packets. Like with many things, it depends on your requirements. Having worked for managed WAN providers where you have a infrastructure shared amongst multiple customers / stakeholders and provide WAN connectivity with over the top services like Internet and VoIP, QoS is a product most customers expect. In this scenario you typically have a set of queues and customer can access either all of them or a sub-set for a cost. In a former life we had up-to 8 classes for customers which you can simplify in your core using pipe mode or short pipe QoS models. We could offer multiple QoS levels to customers, but simplify the classes down to like 3-4 in the core, and without any need for RSVP. I feel this is a good balance between complexity/simplicity and scalability. If you don't have multiple stakeholders then IntServ becomes more appealing due to the granularity on offer, but in the shared infrastructure scenario my experience is that mapping multiple customer queues down to a fewer core queues helps to protect the control plane and LLQ traffic in a simply way that covered all stake holders, and no need for the additional signalling complexity that RSVP brings. Cheers, James. _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp