[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.

[Mark Tinka]

On 6/5/23 23:26, Jeff Haas via juniper-nsp wrote:

> [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.

I think Junos' VRF implementation is so far down the line, it makes more 
sense to just carry on with the architecture and add knobs, support and 
fixes as issues are either discovered or as customers ask for them. As 
you say, "One commit at a time".

Going back to re-do the implementation from scratch would be a 
non-starter. There is simply too much water under this bridge.

It is not unlike all the stuff you get in IOS (and IOS XE) after so many 
years of assuming so many things in the 90's and early 2000's, not least 
of which that IP is not the only protocol routers will ever run. It is 
so hard for Cisco to remove or re-do those assumptions. At some point, 
you just have to accept that picking up an OS-specific book that 
eloquently describes its eccentricities is part of the process of 
raising a network engineer.

Newer OS's like EOS, ArcOS have a cleaner, simpler and more sensible 
approach to this sort of thing because they are benefiting from all the 
good things IOS/IOS XE/IOS XR and Junos have done in the past 25+ years, 
while dropping all the bad things those OS's have also done. Where the 
older OS's still display their strength is in their maturity, especially 
of routing protocols.

In the end, pick your poison, buy the book, and be happy.

Mark.