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.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp