Ah, but the quote is about using Dijkstra algorithm (which OSPF does) to calculate shortest paths using a link cost which (really should have the word "may") using available bandwidth among other things. This quote shouldn't be taken to assume OSPF actually always uses available bandwidth computing link cost.
If you're considering OSPF (v2) you should really look at RFC 2328 which has things like:
The cost of a route is described by a single dimensionless metric.
Which means the cost isn't really tied to any attribute. It's whatever you want it to be. However, in your topology, if you want cost to some how to represent bandwidth, sure you can, but that's not part of the OSPF standard. Cisco does use bandwidth to auto calculate OSPF cost but again not all vendors do (and those that do often use a larger default base bandwidth [Cisco uses 100 Mbps, other vendors might use gig]; also don't overlook you can assign a cost manually to an interface to be whatever you want. NB: on some vendor's devices, if you don't want a cost of one, you must do this.
Interface output cost(s)
The cost of sending a data packet on the interface, expressed in
the link state metric. This is advertised as the link cost for
this interface in the router-LSA. The cost of an interface must
be greater than zero.
The only mention of "bandwidth" in this RFC is:
The OSPF Working Group of the IETF has extended this work in
developing the OSPF protocol. The Designated Router concept has
been greatly enhanced to further reduce the amount of routing
traffic required. Multicast capabilities are utilized for
additional routing bandwidth reduction. An area routing scheme
has been developed enabling information
hiding/protection/reduction. Finally, the algorithms have been
tailored for efficient operation in TCP/IP internets.
Dijkstra's algorithm is mentioned multiple times when the RFC describes computing shortest path tree.
BTW, I also quickly looked at RFC 2328's updated RFCs, but I didn't notice any that change the above.
Also BTW, there can be an issue with auto calculating OSPF cost using some bandwidth base. This happen when you have a large range of bandwidths, say from 10g to fractional T1, and a "deep" topology. Basically, the OSPF counter fills and you get the same path costs even when they are not equal. (Or the converse, if the default is less bandwidths being use, all links of that cost, or better, appear equal.).
Then there are situations where you have other reasons for "engineering" one path vs. another, where using just available bandwidths would not be suitable. So, it's really "good" that OSPF standard doesn't actually tie any attribute to link cost.
