sorry for that, but the only one I've heard about switching his core IGP is Yahoo. I've no precision, and it's really interest me. I know that there had OSPF in the DC area, and ISIS in the core, and decide to switch the core from ISIS to OSPF. Why spend so much time/risk to switch from ISIS to OSPF, _in the core_ a not so minor impact/task ? So I could guess it's for maintain only one IGP and have standardized config. But why OSPF against ISIS ? What could be the drivers? People skills (more people know OSPF than ISIS) --> operational reason ? In my understanding of both protocols, from 3 year old documentation (2012): OSPF is more or less limited to hundred routers in the backbone area. Yeah, ok, but back in 2005 I know some ISP which run 200 routers in the backbone area (only one area) w/o problem. What about today ? protocol design limitation or resources (memory+cpu) limitation ? If ressources only, as of today we can put also 1000 ospf routers in one area... Cisco recommend no more than 50 routers per area with OSPF. Is it a conservative value ? It also depend on the number of networks/router, of course. ISIS is not. ISIS scale up to thousand routers in the same area. Some docs say that ISIS converge faster due to fewer LSP traffic (compare to OSPF which generate more LSA traffic, therefore use more CPU) and better timers. Timers can also be tuned with OSPF, so I do not sea a real argument with better timers for ISIS (same story between HSRP versus VRRP with better timers for VRRP). As your doc say (reason to choose ISIS): better convergence, better security, simplicity. -Marcel On 22.10.2015 19:25, Niels Bakker wrote:

* marcel.duregards@yahoo.fr (marcel.duregards@yahoo.fr) [Thu 22 Oct 2015, 18:57 CEST]:

...

Anybody from Yahoo to share experience on IGP choice ?

What a weird way to limit your audience. This is NANOG, not Yahoo.

Otherwise, http://userpages.umbc.edu/~vijay/work/ppt/oi.pdf

-- Niels.

A lot of carriers use ISIS in the core so they can make use of the' overload bit' with a 'set-overload-bit on-startup wait-for-bgp". Keeps them from black holing Traffic while BGP reconverges., when you have millions of routes to converge it can take forever. It's also a really handy tool when you're troubleshooting or repairing a link, set the OL bit, and traffic gracefully moves, then when you're done it gracefully moves back. You can do the same thing with the Metric, and Cost in OSPF, just not quite as elegant. Largely I think it's preference, ISIS and OSPF tackle most of the same stuff just in different ways. -D -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Matthew Petach Sent: Friday, October 23, 2015 11:31 AM To: marcel.duregards@yahoo.fr Cc: nanog@nanog.org Subject: Re: IGP choice On Fri, Oct 23, 2015 at 1:41 AM, marcel.duregards@yahoo.fr <marcel.duregards@yahoo.fr> wrote:

sorry for that, but the only one I've heard about switching his core IGP is Yahoo. I've no precision, and it's really interest me. I know that there had OSPF in the DC area, and ISIS in the core, and decide to switch the core from ISIS to OSPF.

Wait, what? *checks memory* *checks routers* Nope. Definitely went the other way; OSPF -> IS-IS in the core.

Why spend so much time/risk to switch from ISIS to OSPF, _in the core_ a not so minor impact/task ? So I could guess it's for maintain only one IGP and have standardized config. But why OSPF against ISIS ? What could be the drivers? People skills (more people know OSPF than ISIS) --> operational reason ?

I'm sorry you received the wrong information, the migration was from OSPF to IS-IS, not the other way around. Thanks! Matt

On Fri, 23 Oct 2015, Pablo Lucena wrote:

...

A lot of carriers use ISIS in the core so they can make use of the' overload bit' with a 'set-overload-bit on-startup wait-for-bgp". Keeps them from black holing Traffic while BGP reconverges., when you have millions of routes to converge it can take forever. It's also a really handy tool when you're troubleshooting or repairing a link, set the OL bit, and traffic gracefully moves, then when you're done it gracefully moves back. You can do the same thing with the Metric, and Cost in OSPF, just not quite as elegant.

​That feature is also present in OSPF. 'max metric router-lsa'. ​

This is not exactly the same thing as overload-bit set, but it can be argued that setting max-metric actually makes more sense than what the overload bit does. The choice between IS-IS and OSPF depends more on soft than hard factors. OSPF support is more widespread amongst smaller equipment vendors, IS-IS is the traditional choice for large ISP core IGP, mostly due to the Cisco codebase for IS-IS happened to be more stable than OSPF around 1995, and that's when a lot of larger ISPs started running these protocols, and that stuck. There is no right or wrong IGP to run, both protocols have their quirks and pro:s and con:s. -- Mikael Abrahamsson email: swmike@swm.pp.se

And Windows Server for your routing platform of choice! -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Damien Burke Sent: Thursday, October 22, 2015 1:12 PM To: nanog@nanog.org Subject: RE: IGP choice Just use rip for *everything* Problem solved! -----Original Message----- From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Mark Tinka Sent: Thursday, October 22, 2015 11:41 AM To: marcel.duregards@yahoo.fr; nanog@nanog.org Subject: Re: IGP choice On 22/Oct/15 18:57, marcel.duregards@yahoo.fr wrote:

Hi everyone,

Anybody from Yahoo to share experience on IGP choice ? IS-IS vs OSPF, why did you switch from one to the other, for what reason ? Same question could apply to other ISP, I'd like to heard some international ISP/carriers design choice, please.

The "everything must connect to Area 0" requirement of OSPF was limiting for me back in 2008. So we moved to IS-IS. Mark.

On 22 October 2015 at 19:41, Mark Tinka <mark.tinka@seacom.mu> wrote:

The "everything must connect to Area 0" requirement of OSPF was limiting for me back in 2008.

I'm unsure if this is a serious argument, but its such a poor point today. Everything has to be connected to a level 2 in IS-IS. If you want a flat area 0 network in OSPF, go nuts. As long as you are sensible about what you put in your IGP, both IS-IS and OSPF scale very well. The differences between the two protocols are so small, that people really grasp at straws when 'proving' that one is better over the other. 'IS-IS doesn't work over IP, so its more secure'. 'IS-IS uses TLVs so new features are quicker to implement'. While these may be vaguely valid arguments, they don't hold much water. If you don't secure your routers to bad actors forming OSPF adjacencies with you, you're doing something wrong.Who is running code that is so bleeding edge that feature X might be available for IS-IS, but not OSPF? Chose whichever you and your operational team are most comfortable with, and run with it. Regards, Dave

...

The differences between the two protocols are so small, that people really grasp at straws when 'proving' that one is better over the other. 'IS-IS doesn't work over IP, so its more secure'. 'IS-IS uses TLVs so new features are quicker to implement'. While these may be vaguely valid arguments, they don't hold much water. If you don't secure your routers to bad actors forming OSPF adjacencies with you, you're doing something wrong.Who is running code that is so bleeding edge that feature X might be available for IS-IS, but not OSPF?

Chose whichever you and your operational team are most comfortable with, and run with it.

Basic point I very much agree with. However, if that was all there was to it, nobody would ever switch from OSPF to IS-IS or vice versa :-)

OSPFv3 scaled better than OSPFv2 in 2008. But multi-AF support for OSPFv3 was only developing then, so that was not a viable replacement for OSPFv2.

OSPFv2 should scale better in 2015 (I say "should" because more routers now have x86-based control planes, but I don't run OSPF so I'm hand-waving).

You're right, a single Level-2 domain in IS-IS is akin to a single Area 0 in OSPF. But those "so small" differences between the protocols in 2008 meant I was less eager to try the single area with OSPF than I was the single level with IS-IS.

Some points I've noticed - YMMV. - Needing OSPFv3 for IPv6 when you're alredy running OSPFv2 for IPv4 is less than optimal. I believe nowadays several vendors support OSPFv3 for both IPv4 and IPv6 - but this is not universal. - Probably mostly due to large operators running IS-IS, new features are more likely to show up first in IS-IS. - OSPFv3 security depends on IPsec, while IS-IS uses MD5. You could certainly argue that MD5 is starting to get long in the tooth - on the other hand, it's significantly better than nothing, and significantly less complex than IPsec. - We still have a few cases of needing OSPF towards customers. IS-IS as core IGP makes it slightly easier to ensure that core routing and customer routing are never mixed. I see no reason to mention anything about scaling, since I believe the protocols (both OSPF and IS-IS) nowadays scale to much larger topologies than we're likely to need. Steinar Haug, Nethelp consulting, sthaug@nethelp.no

It comes down to personal preference now days in my opinion. Both ISIS and OSPFv3 allow you to run multi-af using the same protocol. Both of them dont run full SPF when a stub network is added/removed (unlike OSPFv2). How about vendor support? Perhaps ISIS has the upper hand here since its been around for so long, as compared to multi-af OSPFv3. If I had to build a network from scratch that need to support v4/v6, I would go with ISIS...but thats just personal preference. Some DC gear doens't support ISIS, so I guess it depends what the network is going to support. BGP as an IGP is also an interesting option =). *Pablo Lucena* On Thu, Oct 22, 2015 at 6:07 PM, Baldur Norddahl <baldur.norddahl@gmail.com> wrote:

On 22 October 2015 at 22:57, <sthaug@nethelp.no> wrote:

...

- Needing OSPFv3 for IPv6 when you're alredy running OSPFv2 for IPv4 is less than optimal. I believe nowadays several vendors support OSPFv3 for both IPv4 and IPv6 - but this is not universal.

Our configuration is MPLS VPNv6 for IPv6. Therefore we have no native IPv6 in the backbone and no need for OSPFv3.

The IPv4 internet is MPLS VPNv4 so there should be no easy way to attack our OSPFv2 instance from outside. The attacker is simply not in the same VRF as the routing protocol.

Is this such an uncommon configuration? I am asking because nobody mentioned this in the thread.

Regards,

Baldur

You still have separate tables for IPv4 and IPv6 with isis and multi-topology still runs 2 spf calculations. On Thu, Oct 22, 2015 at 4:05 PM, <A.L.M.Buxey@lboro.ac.uk> wrote:

Hi,

...

The differences between the two protocols are so small, that people really grasp at straws when 'proving' that one is better over the other. 'IS-IS doesn't work over IP, so its more secure'. 'IS-IS uses TLVs so new features are quicker to implement'. While these may be vaguely valid arguments, they don't hold much water. If you don't secure your routers to bad actors forming OSPF adjacencies with you, you're doing something wrong.Who is running code that is so bleeding edge that feature X might be available for IS-IS, but not OSPF?

well, bleeding edge fearures in ISIS would also depend on your vendor... ours seems backwards for ISIS in most of their product line and we're always wanting more.... heck, I think they've even tried to ensure its not in their training courses either...just the briefest of mentions :/

as for IGP - ISIS - we moved to it from OSPF because we didnt want 2 seperate routing calculations and tables being kept for IPv4 and IPv6 and all routing config is under the one routing protocol.

alan

On 22/Oct/15 23:22, Bill Blackford wrote:

I don't have all the details because I don't fully understand it, but I've heard that if you're running an MPLS/RSVP core, you can only use a single OSPF area. This introduces a scalability ceiling.

Not true. The rate of development of advanced features in OSPF and IS-IS is at a similar pace today. The main issue is implementation. Some vendors will implement the new capabilities in one protocol sooner than the other. The features may eventually filter down to the other protocol, or not. It is entirely a situation specific to your vendor. For example, IIRC, LFA came to IS-IS in Junos first, and then OSPF followed (or was it the other way around, I can't remember - but support didn't come for both immediately). Same thing at Cisco. Quagga is an example of a case where IS-IS is seriously lagging behind OSPF to the point of not being useable at all. So while the spec. will have parity, your choice of vendor will be a practical factor. Mark.

On 23/Oct/15 10:48, Saku Ytti wrote:

I believe this is because you need 802.3 (as opposed to EthernetII) and rudimentary CLNS implementation, both which are very annoying from programmer point of view.

I'm not really sure what the hold-up is, but I know Mikael, together with the good folks at netDEF (Martin and Alistair) are working hard on fixing these issues. While I have not had much time to provide them with feedback on their progress, it is high on my agenda - not to mention funding support for them will only help the cause.

I hope ISIS would migrate to EthernetII and IP. From security point of view, people often state how it's better that it's not IP, but in reality, how many have verified the flip side of this proposal, how easy it is to protect yourself from ISIS attack from connected host? For some platforms the answer is, there is absolutely no way, and any connected host can bring you down with trivial amount of data.

Well, on the basis that an attack is made easier if you are running IS-IS on a vulnerable interface, in theory, an attack would be highly difficult if a vulnerable interface were not running IS-IS to begin with. But I do not have any empirical data on any attempts to attack IS-IS, successfully or otherwise. So your guess is as good as mine. Mark.

On Fri, 23 Oct 2015, Mark Tinka wrote:

I'm not really sure what the hold-up is, but I know Mikael, together with the good folks at netDEF (Martin and Alistair) are working hard on fixing these issues. While I have not had much time to provide them with feedback on their progress, it is high on my agenda - not to mention funding support for them will only help the cause.

There is running code now for IETF HOMENET using Quagga that speaks IS-IS over IPv6 (using IP proto 124) if you want to, it's configurable per-interface. I do not know at this time what the status is for mainline Quagga IS-IS, but I've sent a question about it to Netdef about it

by having multiple areas, therefore ABR which deny routers and network LSA, you introduce summarization (ABR only send summary LSA, mean subnet info, not topology info) in your network. Thus you loose informations and do not have a complete topology of your network. I guess MPLS/TE prefer to seat on top of a real topology ? On 22.10.2015 23:22, Bill Blackford wrote:

I don't have all the details because I don't fully understand it, but I've heard that if you're running an MPLS/RSVP core, you can only use a single OSPF area. This introduces a scalability ceiling.

On Thu, Oct 22, 2015 at 12:35 PM, Dave Bell <me@geordish.org> wrote:

...

On 22 October 2015 at 19:41, Mark Tinka <mark.tinka@seacom.mu> wrote:

...

The "everything must connect to Area 0" requirement of OSPF was limiting for me back in 2008.

I'm unsure if this is a serious argument, but its such a poor point today. Everything has to be connected to a level 2 in IS-IS. If you want a flat area 0 network in OSPF, go nuts. As long as you are sensible about what you put in your IGP, both IS-IS and OSPF scale very well.

The differences between the two protocols are so small, that people really grasp at straws when 'proving' that one is better over the other. 'IS-IS doesn't work over IP, so its more secure'. 'IS-IS uses TLVs so new features are quicker to implement'. While these may be vaguely valid arguments, they don't hold much water. If you don't secure your routers to bad actors forming OSPF adjacencies with you, you're doing something wrong.Who is running code that is so bleeding edge that feature X might be available for IS-IS, but not OSPF?

Chose whichever you and your operational team are most comfortable with, and run with it.

Regards, Dave

On Thu, Oct 22, 2015 at 12:35 PM, Dave Bell <me@geordish.org> wrote:

On 22 October 2015 at 19:41, Mark Tinka <mark.tinka@seacom.mu> wrote:

...

The "everything must connect to Area 0" requirement of OSPF was limiting for me back in 2008.

I'm unsure if this is a serious argument, but its such a poor point today. Everything has to be connected to a level 2 in IS-IS. If you want a flat area 0 network in OSPF, go nuts. As long as you are sensible about what you put in your IGP, both IS-IS and OSPF scale very well.

It is rather nice that IS-IS does not require level-2 to be contiguous, unlike area 0 in OSPF. It is a valid topology in IS-IS to have different level-2 areas connected by level-1 areas, though you do have to be somewhat careful about what routes you propagate into-and-back-out-of the intervening level-1 area. But other than that, yeah, the two protocols are pretty much homologous. Matt

i may have missed it, but one of my fave features of is-is is that it is a link-local non-ip protocol. hard to disrupt/attack remotely. randy