On 24/09/2023 at 4:18:23 AM, Mark Tinka via cisco-nsp < [email protected]> wrote:
> This is different from how Junos does it, where import/export maps can > be used without having to explicitly define the RT in the VRF. > Further than that, in JunOS if you define an RT in a VRF with an export/import policy it has no effect. Import/export RT is just a shortcut for creating and applying a policy if no other policy exists. It doesn’t (so far as I am aware) do anything else behind the scenes. I have seen this catch out folks in the past, who either expected it to pre-filter like Cisco, or expected it to permit RTs additional to the policy. Cisco have always been like this, where the VRF import/export RTs are an additional layer of policy. I wonder if they see some performance benefit. Perhaps in XR RPL where it would maybe be more difficult to generate a list of expected RTs? It would certainly make it a lot faster to generate the list of RTs to advertise with rtfilter - though given that’s only at config commit time perhaps it’s not a big deal. It means that policy in Cisco can be shorter, which is nice I suppose. -- Nathan Ward _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
