The Open Shortest Path First (OSPF) protocol is one of two Interior Gateway Protocol (IGP) routing protocols being standardized in the IETF. It is widely deployed in both enterprise and service-provider networks, and is the control plane protocol of choice in optical networks. The OSPF Working Group (WG) is one of the older IETF working groups and, after more than two decades, you’d think that it would be reaching maintenance mode. Yet, in fact, we are at a crossroads as we standardize flexible type-length-value (TLV)-based extension mechanisms.
For OSPFv2, we have chosen to leave the base protocol intact and originate separate link-state advertisements (LSAs) to advertise TLVs for applications such as segment routing and maximally redundant trees. The OSPFv2 Prefix/Link Attributes draft has completed WG last-call and publication has been requested. There are no less than five known implementations. There is, however, one disadvantage to this approach in that the attributes for additional applications are advertised independent of the base OSPF topology and IP reachability. Hence, implementations must correlate the base LSAs with the attribute LSAs.
For OSPFv3, a more ambitious approach is proposed in which even the base LSAs are replaced with completely TLV-based LSAs. With this encoding, all the information for a given prefix or link can be advertised in the same LSA, thereby greatly simplifying implementation and reducing network overhead. These mechanisms will position OSPFv3 as an ideal candidate for the Next Generation Interior Gateway Protocol (IGP) since OSPF has the distinct advantage over other IGPs in that information can be partitioned and advertised in multiple LSAs, as opposed to monolithic protocol data units (PDUs). With OSPFv3, when the topology or reachability changes, only the affected LSAs need to be readvertised. These mechanisms are defined in the OSPFv3 Extended LSAs draft. The discussions, reviews, and editing have gone well, and we are now waiting for implementations. There are basically two barriers to implementation. The first barrier is that OSPFv3 is not nearly as widely deployed as OSPFv2 and, as a result, there is less incentive to extend it. The second barrier is the complexity added by the protocol’s backward-compatibility mechanisms.
With these base LSA extension mechanisms, OSPF is being used to support some exciting new applications. Segment Routing is probably the most important of these as it avails the existing Multi-Protocol Label Switching (MPLS) data plane without any MPLS specific control plane protocols (i.e., no LDP or RSVP). In addition, segment routing simplifies traffic engineering and offers improved IP Fast Reroute (IPFRR) coverage because packets can be steered over any router adjacency.
Other applications using the TLV-based OSPF encodings include an IPFRR algorithm known as Maximally Redundant Trees (MRT), support of the Bit-Indexed Egress Replication (BIER) multicast data plane, and support for additional OSPF metrics in satellite networks.
Model-Driven Programmability (MDP) is a common requirement for many IETF working groups. In the OSPF WG, we formed a multivendor design team that has met weekly for almost a year to define a common OSPF YANG model. We have reached consensus, despite some significant differences in vendor configurations. One key decision was settling on the virtual routing and forwarding (VRF)-centric over the protocol-centric model. In VRF-centric model, protocol configuration for individual VRFs (aka, routing instances) are contained within that VRF rather than the being consolidated within a single routing protocol instance. Another key hierarchal decision that will impact multiple IETF models is whether to adopt a proposal from OpenConfig to group the operational state at the same level as the configuration. In the current version of the OSPF model, there are separate configuration and operational state YANG hierarchies. However, the model will likely be reorganized by the time this article is published. Since this decision impacts many YANG models, the discussion is also taking place in the NETMOD working group.
Finally, the working group is also looking at ways to scale OSPF beyond its practical limits. One such proposal is the Topology Transparent Zone (TTZ) enhancement that abstracts an arbitrary portion of an OSPF network as a full mesh of connections between the routers bordering that abstracted topology. Another is the OSPF stub neighbor proposal that optimizes LSA flooding in hub-and-spoke topologies.