[j-nsp] Network-control queue counter increases on ccc-configured interface

[Mark Tinka]

On Friday, January 27, 2012 03:52:43 PM Saku Ytti wrote:

> Indeed. But it still does not change anything compared to
> customer being in same or different PE. If customer is
> directly attached to your PE, you must decide right
> there how to classify, if that is TOS or L3/L4 values or
> something else, in either case, you'd still remark the
> EXP and the internal class with same value

Agree.

What I was saying was that it's not any easier "not to" 
touch the customer's markings if you run an MPLS network, 
partly because of such tricky topologies.

To avoid any of that, we just mark on DSCP, as well as EXP 
for the MPLS core portion.

> Frankly, any edge device I'd want today from Cisco or
> Juniper does support 'internal storage' of QoS group. I
> don't view it as particularly exotic feature which
> limits my choices dramatically.

I was talking about the hardware-based routers. You won't 
find this feature lacking on any (or most) of Cisco's 
software-based routers.

> Quite, as stated. However when packet ingresses 7600 you
> can decide how you colour internal DSCP. Then on egress
> you either rewrite internal DSCP to (802.1p, EXP, TOS,
> depending on encap) or you don't rewrite and leave them
> untouched.

This is possible, but imagine having to do it on thousands 
other interfaces or sub-interfaces facing other customers on 
the same box. This is, of course, assuming you want a 
uniform QoS policy across the board (which is what we strive 
for).

If you're only concerned about core-facing interfaces, then 
that's no problem. But in our case, when customers are 
purchasing strictly "local" traffic, you need to be able to 
treat it as such if it's moving from interface to interface 
on the same chassis.

> So while internal dscp isn't directly configurable like
> qos-group (I think technically it could be used so that
> you directly mark internal dscp and directly match on it
> in MQC, too bad not implemented like this), it can be
> used to a degree to accomplish same goals of not
> touching or using TOS. But I fully accept that in
> 7600/6500 you may have QoS demand which they cannot
> meet, they are not the most trivial platforms to run and
> to workaround their limitations.

Certainly agree on that :-).

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20120127/5f52a3e3/attachment.sig>