Hello vikkd1234,
This is a very good question. While I cannot speak for Cisco itself, there are general motivations behind these technologies that caused the IS-IS to be a natural choice.
Cisco's FabricPath is a technology inspired by another evolving technology, TRILL = TRansparent Interconnection of Lots of Links. Both these technologies aim at replacing the STP in switched networks with a more intelligent approach to switching frames, along with utilizing multiple paths for delivering data.
As TRILL and its Cisco incarnation, the FabricPath, are Layer2 technologies, their control-plane protocols must be fine with working directly over Layer2. It would only complicate things if another protocol, say, IP, was necessary for these fundamental control-plane protocols to work. Think of STP - it does not use IP encapsulation, rather, its BPDUs are directly encapsulated into Ethernet frames, and we have been fine with this particular approach all along.
Because of loop avoidance and convergence time reasons, both TRILL and FabricPath must use link-state protocols instead of STP to determine the active topology. If an existing link-state routing protocol shall be reused and adapted, instead of developing a completely new protocol, it must obviously be either OSPF or IS-IS.
Now, OSPF is very strongly oriented towards IP networking. It is encapsulated into IP packets and also the internal structure of its messages assumes that the addressing is either IPv4 or IPv6-based. Reusing OSPF in TRILL/FabricPath would be complicated: you would need to define new LSA types to carry L2-reachability information, and in addition, you would either have to deploy an IP layer over the switched network for OSPF to actually work, or modify OSPF extensively to work directly over Layer2. Neither of these prospects is particularly appealing. In short, adapting OSPF for TRILL/FabricPath would be a major effort with results very much resembling what IS-IS already has by its design.
With IS-IS, it is all much easier. IS-IS runs directly over Layer2, regardless of the routed protocol it is used for. Its internal messages are not "pre-formatted" for any particular address format, rather, all reachability information is recorded in the form of so-called Type-Length-Value (TLV) entries exactly specifying what kind of address is being advertised (some people go as far as to say that the IS-IS is "agnostic" about the environment it runs in). IS-IS is very easily extended by defining new TLV records that can carry any information you like, including the L2-reachability as required in TRILL/FabricPath. The IS-IS was therefore a natural choice - it does not need adapting to work directly over Layer2 because it already works that way, just new TLVs were necessary (which is simply a matter of defining their type number and internal structure) and some specific protocol behavior traits had to be modified.
RFC 6325, Section 4.2, puts it quite nicely:
TRILL uses an extension of IS-IS [ISO10589] [RFC1195] as its routing
protocol. IS-IS has the following advantages:
o It runs directly over Layer 2, so therefore it may be run without
configuration (no IP addresses need to be assigned).
o It is easy to extend by defining new TLV (type-length-value) data
elements and sub-elements for carrying TRILL information.
Please feel welcome to ask further!
Best regards,
Peter
