[j-nsp] JunOS RPKI/ROA database in non-default routing instance, but require an eBGP import policy in inet.0 (default:default LI:RI) to reference it.

[Jeff Haas]

[Note that I've already inquired internally about the original problem.  I don't recall the answer from top of head and don't have time for code spelunking...]

As to the point below, we get to these headaches one commit at a time.  Junos is long-lived enough that VRFs started as a hack on a system that didn't have them.  A completely new system written from scratch likely would just assume arbitrary tables that can be spaghetti configured into whatever you want to do with them.

When I was first studying the Juniper implementation of L3VPN VRFs, some of the rib-group constructs didn’t make a lot of sense to me.  It was rather clearer after discovering that when the features were released in the 9.x (?) releases that all of the niceties we have today used to be completely done at a manual level with those same rib-groups. __

While I have a lot of sympathy for Saku's pragmatism, I prefer to file off the ugly edges of old justifications when I can... but it's done one commit at a time.

-- Jeff



On 6/5/23, 3:47 AM, "juniper-nsp on behalf of Saku Ytti via juniper-nsp" <juniper-nsp-bounces at puck.nether.net <mailto:juniper-nsp-bounces at puck.nether.net> on behalf of juniper-nsp at puck.nether.net <mailto:juniper-nsp at puck.nether.net>> wrote:
I consider it a design error that NOS conceptually has two types of
instances, main instance and VRF instance. This distinction makes it
more expensive to write and maintain the NOS and it makes it more
fragile.


Juniper Business Use Only