Vendor support for IS-IS is quite limited - many options for OSPF.
>Depends on the vendor.
I think you misunderstood his point: it's not the knobs, but the vendors. Generally, when you're trying to integrate random crap into an otherwise well-structured network, you'll find OSPF available, but very rarely IS-IS.
I run into this a lot in the security appliance space, where you want your security appliances to either learn or advertise routes internally (VPN tunnel reachability is a big reason for this), but also in devices such as load balancers and other middlebox cruft that occasionally needs to participate in routing advertisement/subscription.
Some vendors grab random open source routing protocol code that includes everything and dump it into their boxes, usually accessible via an entirely separate configuration interface; this can include IS-IS, but these implementations rarely actually work as they are usually "check list" implemented for a specific RFP or customer and never get widely tested.
The ones who actually care about making it work almost always include RIP and OSPF, with a few shout-outs to BGP. IS-IS (and OSPF v3) rarely makes the cut.
In a world where you are doing well-controlled Cisco/Juniper/etc networks with fairly homogeneous code bases, the engineers get to have this discussion. When you have to link in devices for which routing is not their primary reason to exist, your options narrow very quickly. It's not ideal; that's just the way it is.
I think you misunderstood his point: it's not the knobs, but the
vendors. Generally, when you're trying to integrate random crap into an
otherwise well-structured network, you'll find OSPF available, but very
rarely IS-IS.
We never really want to talk IS-IS with random crap - in that case
the protocol of choice would be BGP.
I run into this a lot in the security appliance space, where you want
your security appliances to either learn or advertise routes internally
(VPN tunnel reachability is a big reason for this), but also in devices
such as load balancers and other middlebox cruft that occasionally needs
to participate in routing advertisement/subscription.
...
The ones who actually care about making it work almost always include
RIP and OSPF, with a few shout-outs to BGP. IS-IS (and OSPF v3) rarely
makes the cut.
We've found that BGP works reasonably well to talk with such boxes,
and also that BGP is generally available.
In my experience/personal opinion, compared to OSPF2/3, in a large ISP,
ISIS:
- has simpler and better, less bloated code. Think ISIS on Juniper. Think
FreeBSD vs Linux.
- is more modular to introduce new features.
- has certain knobs which makes it a bit more useful for ISP (LSP
lifetime/Max number of LSP fragments, etc).
This is for a large single L1/L2/backbone area. There are at least 2 design
options I would consider before switching to multi-area ISP design.
With that said I know of at least two of the largest ISPs tat use OSPF and
many use that favor ISIS so it really comes down to ISP's preference and
NOC willingness to learn new unfamiliar protocol.
This is a feature of IS-IS. You're less likely to get random crap in
your IGP.
that alone makes a great argument for connecting to this sort of device
using bgp. Some vendors approach ospf with a hilarity-first attitude,
and at least bgp has the knobs to treat those sort of devices as if they
had a contagious disease.
