D should be the correct answer since router target filtering needs to be configured on the RRs and the PEs requesting it.

Normally, for the RT-Constrain feature to function properly, it must be broadly deployed throughout a network. If this is not the case, the feature is less useful, because the RT-Constrain BGP speaker facing a non-RT-Constrain speaker must advertise a default RT-Constrain route to the other RT-Constrain speakers on behalf of the peer that does not support the feature. This effectively removes the resource saving benefits of the feature in portions of the network where it is not supported since a default RT-Constrain route causes the PE router and all intervening PE routers to need to receive all VPN routes.

route target filtering is configured on RR and respective PE to filter out unwanted routes in PE

D is most correct. Configure the family on both sides of the BGP to enable this feature. I think B you can statically do it without BGP negotiation. But D is most correct to me.

Answer D: https://www.juniper.net/documentation/us/en/software/junos/vpn-l3/topics/topic-map/l3-vpns-route-target-filtering.html#id-example-configuring-bgp-route-target-filtering-for-vpns

so is D the correct answer ?

Route Target needs to be configured on PE and RR... PE will advertise to RR required target: communities and RR will advertise 0/0 to request all VPN routes from PE.

I think the family route-target -filtering needs to be negotiated between the RR and PE's

shouldn't you enable RT filtering on RR AND PE devices?