On 27/09/2023 at 4:15:31 PM, Mark Tinka <mark@tinka.africa> wrote: > > > On 9/24/23 03:43, Nathan Ward wrote: > > My only assumption was that early versions of VRF implementation in IOS > did not expect that operators would require more fine-grained use of > import/export policies, and may just mostly rely on the RT defined in the > VRF. >
Yep - taking use cases from text books :-) Then people building records systems took that early expectation and now a bunch of records systems trying to model VRFs think that VRF is a network-wide construct, and only exports and imports a single RT. Oh, and has the same RD on every instance. Perhaps in XR RPL where it would maybe be more difficult to generate a list > of expected RTs? > > > Why would that be more difficult? > > 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. > > > I can't think of a reason why implementation in IOS XR would be more > onerous. > In JunOS you can’t use regexes or wildcards for “target:” communities. You can use wildcards in IOS-XR RT sets - so if your RPL has something like the following, without defining the RTs you care about in the VRF, you’ll generate a bunch of rtfilter[1] routes. Perhaps it could optimise and generate rtfilter routes using prefix lengths other than 0 and 96 - though I’ve never actually tested that before, so I’d be wary of how well it is implemented… :-) route-policy make-lots-of-rtfilter-routes if extcommunity rt matches-any (64496:*) then pass else drop endif end-policy IOS-XR has a more complex language than JunOS for policy, too. Without the above being an issue, it feels like jumping through parameterised RPL could make it pretty difficult to figure out all the possible RTs you might want to accept. Noting that communities can be built up from parameters. Impossible? No. More difficult? Yeah. If sticking all the possible RTs in a VRF definition is the cost of getting RPL, I think that’s a fair trade. I’m a Juniper guy mostly, but, RPL is pretty good I’ve got to admit. -- Nathan Ward [1] I have forgotten what Cisco calls constrained route distribution. rtfilter is a JunOS term and is what I call it. From memory vendors all call it different things. _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/