[j-nsp] Use cases for IntServ in MPLS backbones

[James Bensley]

On Tue, 2 Oct 2018 at 10:10, Saku Ytti <saku at ytti.fi> wrote:
>
> Hey James,

Hi Saku

> > 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.
>
> Have you considered full or short pipe? It would be nice if we'd
> transport DSCP bits as-is, when we don't have to care about them.
> Far-ends may be able to utilise them for improved UX if we don't strip
> them.

Yeah in the short pipe model we can map traffic from a transit/peering
port into a best-effort class across the core and leave the DSCP
markings as is. Caveat: this is depending on your tin. If I remember
correctly we had some old tin that gave you the choice of queuing
based on received DSCP and then pushing on our core DSCP/EXP at egress
but not queuing based upon them, or scrubbing the incoming DSCP value
and then queuing on ingress DSCP (which would now be 0). So in the
former case, Internet traffic could freely drop into and congest an
LLQ on these old boxen. So yeah, tin permitting, short pipe FTW in my
opinion. Also most people run multi-vendor networks, I think short
pipe is an easy way forward for multi-vendor QoS.

That is what I was eluding to here (perhaps not very clearly):

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

Cheers,
James.