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

[Saku Ytti]

On (2012-01-26 10:52 -0500), Keegan Holley wrote:

> stable.  I wouldn't use the NC queue for other traffic if you can
> avoid it and I wouldn't make this traffic best effort without figuring

Yet in INET facing router, jnpr default 95/5 split causes just that, any
user in Internet can get special 5% of privileged capacity from your
network.
Which is strictly different from csco default, which is 100% BE.

Now one could argue, that if you care about QoS enough to change the
config, more planned approach than jnpr or csco default should be pursued.
But at very least you'd probably want to to guarantee that transit and
peering interfaces cannot inject arbitrary amount of traffic to your !BE
queue.

Given that I'd need to implement QoS strategy from scratch, and that I'd
want to use only 8 values, so I can carry my QoS in EXP/801.1p, I'd do
something like this in core (SP focused):

0 -> normal INET       (e.g. transit customer traffic)
1 -> worse than normal (e.g. offsite tape backup)
2 -> important INET    (e.g. traffic to own ASN, instead of transit customer)
3 -> normal VPN        (e.g. 0 received from CPE is reset to 2)
4 -> preferred         (e.g. software required to work at office)
5 -> priority          (e.g. voice+video, [5 is default in many phones])
6 -> high demand       (e.g. internal pstn trunks etc)
7 -> network control   (e.g. IGP, LDP, iBGP, MGMT)

0         received from INET customer CPE is reset to 2
0         received from VPN/ customer CPE is reset to 3
7,6       received from INET/VPN customer is reset to 5
2,3       received from iNET/VPN customer is reset to 4

Non-QoS customer is reset to 0, 2 or 3 depending on customer type.

I'd never touch customer TOS byte and I'd never classify based on it, but would
instead use 802.1p/EXP throughout the network.
-- 
  ++ytti