[c-nsp] Extended Route Target Community Bug - Solved!

[Nathan Ward]

On 27/09/2023 at 4:15:31 PM, Mark Tinka <mark at 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.