[j-nsp] Use cases for IntServ in MPLS backbones
Alexandre Snarskii
snar at snar.spb.ru
Tue Oct 2 07:21:50 EDT 2018
On Tue, Oct 02, 2018 at 01:10:14PM +0300, Saku Ytti wrote:
> Hey Mark,
>
> > We remark all incoming Internet traffic DSCP values to 0.
> >
> > A few years ago, not doing this led to issues where customers were
> > handling the DSCP values in such a way that any traffic marked as
> > such was being dropped. Took weeks to troubleshoot.
>
> Dropped by who? I as an Internet user would prefer my DSCP information
> to traverse internet, I do not ask it to be honoured.
>
> If customer has problems with DSCP, then of course they can nullify it
> in their network, or you can even sell it as service to them. But to
> nullify it for everyone seems quite big hammer, unless of course in
> your particular deployment it would be technically not possible to
> retain them.
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.
Or am I missing something ?
More information about the juniper-nsp
mailing list