OSPF vs IS-IS

Fri Aug 12 00:16:58 UTC 2011

On Thu, Aug 11, 2011 at 5:19 PM, Randy Bush <randy at 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