We have a chain of Mikrotiks in a test lab, with VPLS and MPLS-TE tunnels.
MKT1 <--> MKT2 <--> MKT3 <--> MKT4
We have a TE tunnel and VPLS tunnel connecting MKT3 to MKT1, and the same connecting MKT4 to MKT1. On MKT4, we are using a bridge filter to set the priority for all packets entering the tunnel to MKT1 as priority 7. We have no filter on MKT3 since they should be experimental bits at that point, and the tunnel from MKT3 to MKT1 should not be prioritized.
To simulate congestion, on MKT3's interface that connects to MKT2, we implemented a queue tree with a 20Mbps limit, matching no-mark. It matches all packets and shapes to 20Mbps. However, it seems to ignore the MPLS EXP bits set by MKT4 and gives the traffic the same priority as the MKT3 traffic.
NOTE: To test this, we have a UDP packet generator on MKT4 sending to an IP of a computer plugged into the VPLS tunnel endpoint at MKT1. We have a similar UDP packet generator on MKT3 sending to the same computer. The rate of the UDP packet generator on MKT4 is the bare minimum packets per second required to create a 5Mbps rate (the guaranteed rate for the customer), but have UDP packets going through MKT3 with a much higher rate (30 or 40 Mbps). We can see the rate that packets are arriving at the tunnel endpoint at MKT1. When we start the traffic generator on MKT3, the traffic from MKT4 drops down from 5Mbps to 4.2. Disabling the traffic generator causes the MKT4 tunnel traffic to return to the customer guaranteed 5Mbps. If we try disabling and enabling the bridge filter on MKT4 that applies the priority to the packets, it has no impact on the 4.2 value, which suggests that the MPLS experimental bits are either not being set or not being honored.
I'm not sure whether this is caused by the HTB not recognizing that the EXP bits should have priority, or whether the EXP bits are not getting applied properly from the beginning.