o Does not require any particular alignment of the PDU fields.
o Uses Type-Length-Value (TLV) encoded packets to advertise the routing information. The TLVs that are not supported/recognized are ignored by other IS-IS routers.
o LSPs are flooded intact with unrecognized TLV information making it very extensible. IPv6, GMPLS, etc. support is provided by simply adding a few more TLVs.
o TLVs can be nested as sub-TLVs providing even more flexibility for future extensions. Though the base spec does not use them but the newer drafts and RFCs have started using them (TE extensions, etc).
o Uses fixed format packets with all fields aligned at 32-bit boundaries for faster processing of the OSPF packets (doesn’t really matter anymore as the CPUs are really fast these days!). This was primarily done because OSPF was meant to be an IPv4 only protocol.
o The downside of the above is that the packet formats are not at all extensible. We had to come out with OSPFv3 when we wanted to provide support for IPv6.
o It uses Link State Advertisements (LSAs) for advertising the routing information and the original specification called for dropping any unrecognized LSA type.
o LSAs of type 9, 10 and 11 have been introduced for advertising other application specific information and enough vendors now support this so that they are likely to get from one side of the network to the other.
o Since the unrecognized LSA types are not flooded to neighbors it makes it very difficult to extend OSPF. This in turn means that all the OSPF routers must be upgraded network-wide to make the new extensions work.
o The new RFCs (Traffic Engineering, GMPLS extensions, etc) written for OSPF now support TLV encoding.
o Exhibits implicit opaque LSA behaviour i.e. unrecognized LSA types are flooded to the neighbors making it more extensible that OSPFv2
o Designed in a way which makes it easily extensible to any other layer 3 protocol suite.