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

[adamv0025 at netconsultings.com]

> Of Mark Tinka
> Sent: Tuesday, October 02, 2018 11:56 AM
> 
> 
> 
> On 2/Oct/18 12:48, Saku Ytti wrote:
> 
> > You tell to them DSCP values do not affect forwarding or queueing
> > behaviour in your network.
> 
> If only the whole Internet was ran by just one AS.
> 
Mark, it's a simple premise based on live and let live. 

MPLS enabled core network allows operators to treat the traffic the way they
want regardless of what QOS markings the traffic is arriving with at the AS
borders. 
You just take whatever comes in on your internet ports and dump it in your
MPLS core BE class, you don't need to care what the DSCP markings are on
various packets within your BE pipe, noise in noise out, let the chips fall
where they may.
So I'd encourage everyone, if you can, be part of the solution not part of
the problem (especially with regards to the BCP-38 and uRPF mentioned)

This is achievable because MPLS (as a form of tunnelling) allows you to
maintain various independent queuing models.
So by definition from the MPLS core perspective I couldn't care less about
what's going on at the edge, but of course the business logic (not the QOS
markings I mind you) forces me to pay attention to QOS markings on packets
that enter through some types of links. That's why usually MPLS core only
cares about whether it was voice, business-in-contract,
business-out-of-contract or internet traffic in order to perform scheduling
on core links. 

Now, I'm aware that there are cases were you have to bleach certain DSCP
markings at ingress -this is in cases where the internet traffic is carried
in native IPv4/6 core as you mentioned.
That's where in fact, at ingress to your core, you should bleach DSCP
marking you're using internally (but that's a necessary evil).  

adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::