On Thu, Aug 11, 2011 at 5:19 PM, Randy Bush <randy@psg.com> wrote:
how about simpler and more stable?
ISIS is also decoupled from IP making it more robust and flexible/future-proof, as in adaptible to new protocols -- IP connectivity is not required for ISIS nodes to discover and associate with L2 connected neighbors. At the fundamental level, there are plenty of reasons to exclude OSPF from running in a SP core; when a technically superior choice is available and usable. The IP decoupling is a good example. As in, ISIS topology is independent from (non-tunneled) IP topology, which is more flexible. There is less complexity, and basic troubleshooting is facilitated favorably to OSPFv2/v3, due to the larger amount of baggage OSPF carries with it. If you need to renumber your network, including IS-IS routers', you will impact the contents of IPv4 routes transmitted and forwarding table contents, but your adjacencies do not rely on the IP protocol, and aren't dependant on neighbor IP addressing. Need to support IPv6 addresses? ISIS was trivially extended to do it. Need to support routing to MAC addresses? Again... just a new type field. OSPF requires... shall we say, more fundamental changes to attempt to extend it. More fundamental changes to a more complex protocol = more opportunities for bugs. I would encourage you to ask the opposite question: " Is there any reason to run OSPF over IS-IS in the SP core?" And the answer would be... probably not. There is not really a good technical reason to run OSPF over IS-IS in the SP core. You might have some aesthetic considerations such as wanting the SP core to run the same protocol as something else, despite its limitations. Then you will have to ask yourself if the aesthetic considerations outweigh the technical benefits. -- -JH