[j-nsp] Use cases for IntServ in MPLS backbones
Mark Tinka
mark.tinka at seacom.mu
Tue Oct 2 08:29:11 EDT 2018
On 2/Oct/18 13:21, Alexandre Snarskii wrote:
> Retaining DSCP in juniper networks leads to consequence of not showing
> egress router in traceroute. Well, it's quite easy to classify packet
> on ingress (based on interface), and it's quite easy to mark packet
> with MPLS EXP and use this marking along the route, but at the egress
> router picture is a bit different: in normal situation with
> penultimate-hop-popping packet reaches egress router without MPLS
> encapsulation, so you have to believe external (customer's or peer's)
> marking to [mis]classify packet. Of course, you can use ultimate-hop
> popping (explicit-null) so MPLS EXP can be used at egress router too,
> but in this case egress router will not decrement ip ttl and generate
> icmp unreachable/ttl exceeded and so will not be shown in traceroutes
> making troubleshooting much harder.
And that is my point - if I want to use PHP or UHP within my network,
that should be a choice I can make not because I want to support DSCP
honouring, but for other operational reasons that have a more direct
impact on my revenue and customer experience.
There are networks that do not support MPLS. But saying that all network
that support MPLS should run it as UHP is like saying all networks that
run MPLS should do LDP.
For me, the damage of allowing off-net DSCP values vs. the harmless fix
to the general public on my network is not worth the extra time spending
on it. I'd see a lot more benefit in pushing for Internet-wide RPKI
deployment.
Mark.
More information about the juniper-nsp
mailing list