Most network engineers are very well versed in OSPF. Having come up through the ranks of Cisco's early NetAcad curriculum in the early 2000s, when BGP was very

Most network engineers are very well versed in OSPF. Having come up through the ranks of Cisco's early NetAcad curriculum in the early 2000s, when BGP was very rarely used in internal networks, thr content was 80% focused on IGP and large L2 design and troubleshooting. It seems to me the IGP has fallen out of favor partially due to simplicity over the right tool in the right context. I'm sure, as you state, part of that has to do with the responsible engineers lacking experience and shying away. But in many cases BGP can be slower and less forgiving where a focused IGP can add value and, most importantly control. I was part of a team running a multi-state network for an ISP around a decade ago. Even then we had a lot of design and architecture reviews of spreading BGP as far and wide as possible. But the IGPs, at regional node levels (HFC type networks) always had functionality for end user provisioning that allowed us to more easily provision and troubleshoot. While I don't agree or disagree that BGP can't be the right solution what it really comes down to is understanding the use cases compared to the protocols. I find that most engineers today only loosely understand BGP and OSPF. Fully vetted network engineers seem to be fewer and further between. I moved away from that as a role years ago but my experience in large networks and understanding those protocols, although admittedly not as well as when I was studying for the CCIE labs, has been a fundamental skill I still use day in and out. And as we move more to software defined overlays I find it coming up more and more these days.