[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 09:46, Saku Ytti via juniper-nsp wrote:

> It is safer to put the service (internet) in VRF, and leave the main
> table for signalling and NMS, if you want to create this distinction.
> It will also make it a lot more convenient to leak between instances
> and create subInternets, like peeringInternet, to avoid peers from
> default routing to you.

I'm still in awe of operators who run their Internet and/or core network 
inside a VRF :-).

In all my years in the game, that is the one thing I have never been 
brave about. I find it cheaper and simpler to just separate functions 
with physical hardware.


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

I can see reasons for and against it, but no doubt, it does add 
complexity into the code base, even though it may "simplify" network 
operations to have the distinction.

Cisco's approach is less onerous, with simply applying the VRF wherever 
it is needed inside the global configuration. I'd imagine that is 
simpler to code for, and operationally, it is reasonably simple as well.


> General principle applies, do boring things, get boring results. Same
> reason why IPv6 continues to be 2nd class citizen and is a bad
> candidate for your NMS/signalling AFI, people don't use it, so if you
> do, you will be responsible for driving vendors to fix it. Time which
> you likely should be spending doing something else.

I, most likely, do not speak for the majority when I say we are a 
dual-stack house and signal both on IPv4 and IPv6 for just about 
everything... SSH, TACACS+, RADIUS, SNMP, NTP, ROV, DNS, Syslog, LDP, 
Netflow, e.t.c. I do remember a time when vendors did not have parity 
for this, but that was, at worst, 9 years ago.

It does take some effort to have signaling parity between IPv4 and IPv6, 
and I think that is the biggest hurdle for network operators... that 
boring is so good, it's a mission thinking about bringing some 
excitement into your life :-). It has been easier for us because we got 
the chance to greenfield our network revamp 11 years ago, so we got 
dual-stack done at the same time. I can see a complication where 
longstanding deployments are very IPv4-centric, that going back to work 
IPv6 natively in is insurmountable.

DNSSEC, RPKI, DMARC, DANE and DKIM suffer from the same inattention as IPv6.

Mark.