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. _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
