I can confirm that this definitely works, we run a virtual CHR instances with a rstp bridge to multiple VPLS destinations.
6.43rc appears to support forwarding low level BPDU frames such as LACP, when setting the bridge protocol mode to none, so that customers can simply bond to switch stacks.
This is handled by another overlay network, using bridges per vlan and/or point-to-point vpls pairs.
Virtual client router instance:
/interface ethernet
set [ find default-name=ether1 ] mtu=2026
/interface vlan
add comment="Cape Town - ProvderA:" interface=ether1 mtu=2022 name=vlan17 vlan-id=17
/interface vpls
add advertised-l2mtu=1992 disabled=no l2mtu=1992 mac-address=xx:xx:xx:xx:xx:xx name=\
vpls-capetown remote-peer=192.168.255.6 vpls-id=6:1
/mpls interface
set [ find default=yes ] mpls-mtu=1992
/mpls ldp
set enabled=yes lsr-id=192.168.255.1 transport-address=192.168.255.1
/mpls ldp interface
add hello-interval=1s hold-time=10s interface=vlan17
PS: We match the OSPF interface hello and hold timers, to synchronise route and LDP reconvergence.
The underlay network has much larger l2mtu support. We currently limit the MPLS interfaces to 4400 bytes, the lowest amongst our chosen providers.
Underlay's uplink interfaces have their l2mtu set to match switch or partner capabilities (typically 9000 byte jumbo frames). VLAN interface mtu is set to be the same as the interface's resulting l2mtu. VPLS interfaces are configured with 4374 byte l2mtu.