OSPF was originally designed in an age when processors were much less capable, available memory was much smaller, and link bandwidths were much lower. To conserve processing power, memory, and n-the-wire bandwidth, OSPF was designed using fixed length fields (FLFs). TLVs are more difficult to process than an FLF; to process a set of FLFs, you build a structure that mimics the FLF formatting, and simple “impose” it on the memory location where you have stored the data to be decoded, as shown below.
In the FLF model, the structure can simply be imposed on the memory locations, and the values can be read directly. In the TLV model, each type code must be read to determine the kind of information and the length must be read to determine the size of the field. Only once these two items in the TLV header have been read can the actual data be related to a particular field in the resulting data structure.
In the intervening years, however, compute, storage, and network capabilities have increased dramatically; the following chart, taken from a book I’m working on, shows this growth since about the start of the “network era.”
As compute, storage, and network capabilities have increased, the arguments against using TLVs have faded into the background. Keeping with this, OSPF is moving towards a TLV based structure, slowly replacing the FLF structure it was originally designed with (OSPF TLVs!). The first big move in this direction was actually taken in RFC5340 in 2008, when OSPFv3 was designed to carry IPv6 reachability information. Two little noticed, but very important, changes were made between OSPFv2 and OSPFv3, both covered in section 2.8, LSA Format Changes.
The first of these is the removal of address (or reachability) information from network LSAs. While OSPF has always built its SPT in precisely the same way as IS-IS always has—it builds a tree, and hangs reachability off the tree. Many engineers are tricked into thinking SPF integrates reachability into the tree because “everything is IP addresses,” but this simply is not true. Changing the LSA format in this way clearly separates reachability information from topology information in OSPFv3. The second change was this: “Router interface information MAY be spread across multiple router-LSAs. Receivers MUST concatenate all the router-LSAs originated by a given router when running the SPF calculation.” Router information can now be fragmented across multiple packets.
The reason they are important is the frame a current draft that takes OSPF one step further, draft-ietf-ospf-ospfv3-lsa-extend, titled OSPFv3 LSA Extendibility. The general idea is this: build new LSA types that convert the fields that seem likely to need some form of extension in the future into TLVs. The process chosen is simple, on reflection.
Each of the existing LSA types are replicated in a new format. To differentiate between the old and the new, 0x20 (or rather 32 decimal) is added to each LSA type. Hence a type 1 router LSA becomes a type 33 extended router LSA, etc. A chart taken from the draft is below.
In each case, a number of fields have been converted to TLVs (though not all fields). Mostly the entire old LSA type has been converted into a TLV carried within the new LSA type, which allows for new TLV types within each LSA in the future. For instance, the Intra-area prefix TLV, defined in section 3.4, looks like this—
The individual fields are not TLVs; the entire “old LSA” has been put into a TLV. This allows the new inter area ruote LSA to carry new kinds of reachability information in the future by simply including new TLV types in the new LSA type. If a new address family needs to be supported, it is just a matter of creating a new TLV that can be used to describe this new reachability and putting it into the existing inter-area LSA. The LSA provides the context, while the TLV provides the data.
Migration between the old and new TLVs is managed much like migration between narrow and wide metrics in IS-IS; routers capable of generating the new LSA types do so; these new LSAs are marked so routers that do not understand them simply reflood them (they don’t process them in any way). So long as there is any router flooding the older style TLVs within the netwrk (or flooding domain, there are options for both), the new TLVs will not be used to compute loop free paths. Once all the routers in the network (or, again, flooding domain) are advertising the new TLVs, then preference can be given to the new TLVs, and, finally, the old TLVs removed from the network.
Hopefully vendors implement these new TLV based LSA formats quickly, as they will make OSPF much more extensible over the long run.