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

[Mark Tinka]

On 2/Oct/18 14:25, adamv0025 at netconsultings.com wrote:

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

BCP-38 is much more achievable because you don't need to do anything
more special than is supported in basic IP. In the worst case, go manual
and build ACL's if you can't support uRPF.

In order to do UHP, a network has to run MPLS, and support it up to
final edge where IP/MPLS services are delivered. I know dozens of
networks that will never run MPLS as a matter of principle, and these
are not small networks on a global scale, by any means.

On my end, I have specific reasons (other than QoS) why I need the MPLS
header popped at the penultimate hop, making UHP a non-starter for me.
That said, in practice, all customers that have requested that we honour
DSCP values have been VPN customers. I imagine there are customers that
need the same functionality when running their traffic over the general
Internet, but I haven't heard from them... and the few that I know are
probably running that in GRE in order to maintain that transparency and
avoid what intermediate networks could do to their DSCP values.

But again, your network, your rules. If anyone can write me to say that
my remarking DSCP to 0 for all Internet traffic is breaking their
network or customers on the far end of the TCP/IP session, I'll gladly
listen.

Mark.