Hi all co-authors, It seems that you are pursuing a more specific granularity-based route filtering mechanism for L2 and L3 VPNs, i.e., VPN-prefix-granularity-based route filtering. If so, why still rely on the Virtual-HUB-Spoke model [RFC7024] where different RT attributes (e.g.,RT-red-from-HUB, RT-red) need to be configured for a given VPN instance.
In fact, since we are now seeking VPN-prefix-granularity-based, rather than VPN-granularity-based, route filtering tools, it seems there is no need to confine operators with the approach proposed by RFC7024 which is actually a type of VPN-granularity-based route filtering mechanism anymore. Insteads, operators could use a more straightforward method to realize VPN-prefix-granularity-based route filtering. For example, operators could just configure a single RT (e.g., RT-red) for a given VPN instance and enable VPN-prefix-based ORF capability between BGP peers. If a PE router acting as RR-client just needs a default IP or MAC route advertised from its RR, it just needs to ask the RR to send a default VPN route associated with RT-red, if that PE router needs a host route for a given destination CE host, it just needs to ask the RR to send a host route for that CE host associated with RT-red. In this way, there is no need to ask the RR to add an additional RT when reflecting a route which is required by the PE router. Best regards, Xiaohu
