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

[Saku Ytti]

On (2012-01-27 15:50 +0800), Mark Tinka wrote:

> The problem with trying to provide any kind of QoS to 
> Internet access customers is that if you can do it, it will 
> most probably only be possible in the egress direction, as 
> QoS scheduling is mostly on the egress portion of router 
> interfaces anyway.

As you mentioned, with SCU/DCU/QPPB, it's not that hard.

So in JNPR you'd originate some PA blocks with magic community, and then in
peering edge, there would be firewall filter which would match DCU and set
qos class. It's fairly simple and low amount of config line overhead.
Unfortunately QPPB is not supported in 7600 which is quite commonly used in
peering.

> scheduling toward a specific customer this way. Yes, you 
> could do things like DCU and QPPB, but this can get very 
> complicated very quickly, particularly if you have very 
> strong and dynamic peering, and you need to turn these 
> features for only a sub-set of your customers and not all.

Controlling it via BGP announcement and you never need to touch peering,
once you've set it up.
The feature is there and has been for >decade in IOS for good reason, there
are some people who really have customers who are not created equal and
some needs to have higher privilege to live during congestion than others.

I fully accept that there are lot of businesses where all customers are
created equal, and dropping one INET packet is same as any other. But if
this is not the case, I welcome people to rethink the assumption that
customers who pay 300USD for 2Mbps L3MPLS VPN with centralized INET access
should be treated same way as customer who pays <2000USD for 6Gbps IP
Transit.

-- 
  ++ytti