IGP protocol

James Bensley jwbensley at gmail.com
Wed Nov 14 13:53:54 UTC 2018


On Tue, 13 Nov 2018 at 12:09, Saku Ytti <saku at ytti.fi> wrote:
>
> On Tue, 13 Nov 2018 at 12:37, Mark Tinka <mark.tinka at seacom.mu> wrote:
>
> > Main reasons:
> >     - Doesn't run over IP.
>
> Why is this upside? I've seen on two platforms (7600, MX) ISIS punted
> on routers running ISIS without interface having ISIS.  With no
> ability to limit it, so any connected interface can DoS device with
> trivial pps rate, if ISIS is being ran.

I guess the OPs original question wasn't clear enough because, I think
most people are talking about IS-IS vs OSPF2/3 from a theoretical
protocol perspective, and you're talking from a practical vendor
implementation perspective.

>From a purely theoretical perspective I see IS-IS not running over IP
as an advantage too. No mater what routes I inject into my IGP, IS-IS
won't stop working. I may totally fsck my IP reachability but IS-IS
will still work, which means that when I fix the issue, service should
be restored quite quickly. Several networks I've seen place management
in a VRF / L3 VPN, which means that by the time you have remote
management access, everything else is already working, it's like the
last thing to come up when there's been a problem. I like the
"management in the IGP + IS-IS" design.

However, in reality the vendor implementation blows the protocol
design out of the water. You need to consider both when evaluating a
new IGP. Cisco nearly implemented a handy feature with
prefix-suppression, whereby in IOS for OSPF only one would prevent
p-t-p links being advertised into the IGP database. But they didn't
implement this for IS-IS. Then in IOS-XR they removed this feature
from OSPF and implemented it for IS-IS ?!?! So yeah, vendors
implementations are just as important and the theoretical potential of
the protocol.

Oh yeah, forgot to answer the original question. For a greenfield
deployment I'd be happy with either OSPFv3 or IS-IS as long as it's
well designed I don't see much between them, it would come down to
vendor support then.

Cheers,
James.



More information about the NANOG mailing list