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

Saku Ytti saku at ytti.fi
Fri Jan 27 02:52:43 EST 2012


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

> Well, that is assuming the link toward your customer is 
> Ethernet, 802.1Q, e.t.c., which may not be the case.

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

> Not all platforms in Cisco's arsenal support this feature. 
> So it's not always reliable when new kit is coming out. We 
> had to ask Cisco to re-spin certain ASIC's on new kit while 
> they were still in the development stage (we were in their 
> EFT program) in order to add functions such as these.

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. HQoS and ingress shaping seem
to be harder targets

> > 7600/6500 is complex (in this matter too), however you
> > can usually get even here what you want, due to internal
> > DSCP.
> 
> The EARL7 (SUP720/RSP720) doesn't support 'qos-groups'. This 
> was added in the EARL8.

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.
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.

-- 
  ++ytti


More information about the juniper-nsp mailing list