Considering this was a design flaw we had suggested creating two separate policies: one for DC1 and another for DC2, with specific filter rules for interconnect RT’s and neighbor configurations. The following was the workaround that was shared to the customer -
Policy to leaf1 and leaf2
set policy-options policy-statement dc1_dci term term1 from family evpn
set policy-options policy-statement dc1_dci term term1 from community dci1-com
set policy-options policy-statement dc1_dci term term1 from community wan-com
set policy-options policy-statement dc1_dci term term1 from community t5-com
set policy-options policy-statement dc1-dci term term1 then accept
set policy-options policy-statement dc1-dci term term2 from family even
set policy-options policy-statement dc1-dci term term2 then reject
set community dci1-com members target:<regular-rt>
set community t5-com members target:<l3-vrf-rt>
set community wan-com members target:<inter-connn-rt>
set protocols bgp group <> neighbor <leaf1> export dc1_dci
set protocols bgp group <> neighbor <leaf2> export dc1_dci
set policy-options policy-statement dc2_dci term term1 from family evpn
set policy-options policy-statement dc2_dci term term1 from community dci2-com
set policy-options policy-statement dc2_dci term term1 from community dwan-com
set policy-options policy-statement dc2_dci term term1 from community t5-com
set policy-options policy-statement dc2-dci term term1 then accept
set policy-options policy-statement dc2-dci term term2 from family even
set policy-options policy-statement dc2-dci term term2 then reject
set community dci2-com members target:<regular-rt-pf-dc2>
set protocols bgp group <> neighbor <leaf3> export dc2_dci
set protocols bgp group <> neighbor <leaf4> export dc2_dci