If two BGP instances with the same encapsulation (VXLAN) are configured in the same VPLS service, different import route-targets in each BGP instance are mandatory (although this is not enforced).
BGP-EVPN Routes in Services Configured with Two BGP Instances describes the use of policies to avoid sending WAN routes (routes meant to be redistributed from DC to WAN) to the DC again and DC routes (routes meant to be redistributed from WAN to DC) to the WAN again. Those policies are based on export policy statements that match on the RFC 5512 BGP Encapsulation Extended Community (MPLS and VXLAN respectively).
When the two BGP instances are VXLAN based, the above policies matching on different BGP encapsulation extended community are not feasible because both instances advertise routes with VXLAN encapsulation. Because the export route targets in the two BGP instances must be different, the policies, to avoid sending WAN routes back to the WAN and DC routes back to the DC, can be based on export policies that prevent routes with a DC route target from being sent to the WAN peers (and opposite for routes with WAN route target).
In scaled scenarios, matching based on route targets, does not scale well. An alternative and preferred solution is to configure a default-route-tag that identifies all the BGP-EVPN instances connected to the DC, and a different default-route-tag in all the BGP-EPVPN instances connected to the WAN. Anycast Redundant Solution for Multi-Instance EVPN-VXLAN Services shows an example that demonstrates the use of default-route-tags.
Other than the specifications described in this section, the processing of MAC or IP routes and inclusive multicast Ethernet tag routes in multi-instance EVPN-VXLAN services follow the rules described in BGP-EVPN Routes in Services Configured with Two BGP Instances.