Greetings Team, While I haven't worked with IS-IS before but the only disadvantage I've encountered with OSPF is that it is resource intensive on the router it is running on which is why only one instance runs on any PE & P device on an ISP network. OSPF is pretty good in handling the core network routing while BGP & EGP handle the last-mile routing between PE & CE devices. BGP & EGP can run on top of OSPF. I came across this *article* <https://routingfreak.wordpress.com/2011/03/05/why-providers-still-prefer-is-is-over-ospf-when-designing-large-flat-topologies/> when scrolling the web a while back and I still want to find out if am the only one who thinks its a matter of choice between the two. Although there isn't distinct 1:1 argument, it's good we discuss it here and figure out why one prefer one over the other *(consider a huge flat network)**.* What say you ladies and gentlemen? Warm regards, Michael Bullut. --- *Cell:* *+254 723 393 114.**Skype Name:* *Michael Bullut.* *Twitter:* * @Kipsang <http://twitter.com/Kipsang/>* *Blog: http://www.kipsang.com/ <http://www.kipsang.com/>* *E-mail:* *main@kipsang.com <main@kipsang.com>* *---*
I will definitely be looking up the notes from AOL that John referenced. But working for a vendor and getting insight from multiple ISPs, here are a few of the things that I hear most frequently: 1) Network Topology support - The differences between a single OSPF backbone area and a contiguous set of Level-2 adjacencies will occasionally be a deciding factor. 2) Feature Support on a per vendor basis - Some vendors will roll new features out in one or the other protocols prior to the other. Segment Routing and some of its enhancements come to mind as being in ISIS first. 3) Layer 2 adjacencies - I think someone already mentioned that you form adjacencies at layer 2 which also means that with a single adj you can support multiple protocols (v4/v6). OSPF would require two different instances to support both. Maybe good, maybe not. Depends on your desired level of isolation between the two. 4) CPU performance is academic at this point - The SPF calculations in most networks would require next to no difference between the two protocols even if running both IPv4 and v6. End of the day, use the right tool/vendor/technology for the right job. Hope this helps, RT On Wed, Nov 9, 2016 at 12:12 PM, Michael Bullut <main@kipsang.com> wrote:
Greetings Team,
While I haven't worked with IS-IS before but the only disadvantage I've encountered with OSPF is that it is resource intensive on the router it is running on which is why only one instance runs on any PE & P device on an ISP network. OSPF is pretty good in handling the core network routing while BGP & EGP handle the last-mile routing between PE & CE devices. BGP & EGP can run on top of OSPF. I came across this *article* <https://routingfreak.wordpress.com/2011/03/05/why- providers-still-prefer-is-is-over-ospf-when-designing- large-flat-topologies/> when scrolling the web a while back and I still want to find out if am the only one who thinks its a matter of choice between the two. Although there isn't distinct 1:1 argument, it's good we discuss it here and figure out why one prefer one over the other *(consider a huge flat network)**.* What say you ladies and gentlemen?
Warm regards,
Michael Bullut.
---
*Cell:* *+254 723 393 114.**Skype Name:* *Michael Bullut.* *Twitter:* * @Kipsang <http://twitter.com/Kipsang/>* *Blog: http://www.kipsang.com/ <http://www.kipsang.com/>* *E-mail:* *main@kipsang.com <main@kipsang.com>*
*---*
Vendor support for IS-IS is quite limited - many options for OSPF. On Nov 9, 2016 8:47 PM, "RT Parrish" <routetarget@gmail.com> wrote:
I will definitely be looking up the notes from AOL that John referenced. But working for a vendor and getting insight from multiple ISPs, here are a few of the things that I hear most frequently:
1) Network Topology support - The differences between a single OSPF backbone area and a contiguous set of Level-2 adjacencies will occasionally be a deciding factor. 2) Feature Support on a per vendor basis - Some vendors will roll new features out in one or the other protocols prior to the other. Segment Routing and some of its enhancements come to mind as being in ISIS first. 3) Layer 2 adjacencies - I think someone already mentioned that you form adjacencies at layer 2 which also means that with a single adj you can support multiple protocols (v4/v6). OSPF would require two different instances to support both. Maybe good, maybe not. Depends on your desired level of isolation between the two. 4) CPU performance is academic at this point - The SPF calculations in most networks would require next to no difference between the two protocols even if running both IPv4 and v6.
End of the day, use the right tool/vendor/technology for the right job.
Hope this helps, RT
On Wed, Nov 9, 2016 at 12:12 PM, Michael Bullut <main@kipsang.com> wrote:
Greetings Team,
While I haven't worked with IS-IS before but the only disadvantage I've encountered with OSPF is that it is resource intensive on the router it is running on which is why only one instance runs on any PE & P device on an ISP network. OSPF is pretty good in handling the core network routing while BGP & EGP handle the last-mile routing between PE & CE devices. BGP & EGP can run on top of OSPF. I came across this *article* <https://routingfreak.wordpress.com/2011/03/05/why- providers-still-prefer-is-is-over-ospf-when-designing- large-flat-topologies/> when scrolling the web a while back and I still want to find out if am the only one who thinks its a matter of choice between the two. Although there isn't distinct 1:1 argument, it's good we discuss it here and figure out why one prefer one over the other *(consider a huge flat network)**.* What say you ladies and gentlemen?
Warm regards,
Michael Bullut.
---
*Cell:* *+254 723 393 114.**Skype Name:* *Michael Bullut.* *Twitter:* * @Kipsang <http://twitter.com/Kipsang/>* *Blog: http://www.kipsang.com/ <http://www.kipsang.com/>* *E-mail:* *main@kipsang.com <main@kipsang.com>*
*---*
On 10/Nov/16 04:52, Josh Reynolds wrote:
Vendor support for IS-IS is quite limited - many options for OSPF.
Depends on the vendor. Cisco have as many knobs for IS-IS as they do for OSPF. Juniper, not so much. Don't know about other vendors. At any rate, many of these knobs are not part of the original protocol spec., although they can be very useful when scaling. Mark.
Cisco is the only "real" IS-IS vendor. Juniper, Brocade, Arista, Avaya, etc you're not getting it. Any of the whitebox hardware or real SDN capable solutions, you're going to be on OSPF. On Nov 10, 2016 12:13 AM, "Mark Tinka" <mark.tinka@seacom.mu> wrote:
On 10/Nov/16 04:52, Josh Reynolds wrote:
Vendor support for IS-IS is quite limited - many options for OSPF.
Depends on the vendor.
Cisco have as many knobs for IS-IS as they do for OSPF.
Juniper, not so much.
Don't know about other vendors.
At any rate, many of these knobs are not part of the original protocol spec., although they can be very useful when scaling.
Mark.
Cisco is the only "real" IS-IS vendor.
Juniper, Brocade, Arista, Avaya, etc you're not getting it. Any of the whitebox hardware or real SDN capable solutions, you're going to be on OSPF.
Maybe you need to tell us what the other companies aren't getting? We're using IS-IS on (mostly) Juniper and Huawei, but also Alcatel/ Lucent/Nokia and Cisco. It just works. Steinar Haug, Nethelp consulting, sthaug@nethelp.no
Juniper of their own merits, but they miss many of the IS-IS features Cisco has (of course). Huawei has very "Cisco-like" code, so there's that... Can't speak for Nokia. On Nov 10, 2016 12:22 PM, <sthaug@nethelp.no> wrote:
Cisco is the only "real" IS-IS vendor.
Juniper, Brocade, Arista, Avaya, etc you're not getting it. Any of the whitebox hardware or real SDN capable solutions, you're going to be on OSPF.
Maybe you need to tell us what the other companies aren't getting? We're using IS-IS on (mostly) Juniper and Huawei, but also Alcatel/ Lucent/Nokia and Cisco. It just works.
Steinar Haug, Nethelp consulting, sthaug@nethelp.no
Josh Reynolds wrote:
Juniper of their own merits, but they miss many of the IS-IS features Cisco has (of course).
I think people were looking for specifics about the implementation deficits in the junos version which caused enough problems to justify the term "not getting it"? Nick
I prefer OSPF because it is easier to implement when you can just use a normal UDP socket instead of dealing with raw sockets... And at the day work I also prefer OSPFv2 simply because I do not need more protocols in the stack. We are running a MPLS network with the internet service in a L3VPN. IPv6 is also in the L3VPN. This means the underlying network is pure IPv4 and totally isolated from the internet. Why make it more complicated by introducing something that is not IP based? Regards, Baldur
On 10/Nov/16 21:43, Baldur Norddahl wrote:
And at the day work I also prefer OSPFv2 simply because I do not need more protocols in the stack. We are running a MPLS network with the internet service in a L3VPN. IPv6 is also in the L3VPN. This means the underlying network is pure IPv4 and totally isolated from the internet. Why make it more complicated by introducing something that is not IP based?
I'd counter that "Why not make it less complicating by removing an easily-reachable attack vector?" Sure, you can easily protect your OSPF domain from external attack, but that's something your router CPU and/or data plane would have to deal with it had to, and we've all seen situations where filters break in certain code for various reasons. Or vendors change the way filtering works in newer code without properly notifying customers about such changes. Mark.
Den 11. nov. 2016 06.41 skrev "Mark Tinka" <mark.tinka@seacom.mu>:
On 10/Nov/16 21:43, Baldur Norddahl wrote:
And at the day work I also prefer OSPFv2 simply because I do not need
more protocols in the stack. We are running a MPLS network with the internet service in a L3VPN. IPv6 is also in the L3VPN. This means the underlying network is pure IPv4 and totally isolated from the internet. Why make it more complicated by introducing something that is not IP based?
I'd counter that "Why not make it less complicating by removing an
easily-reachable attack vector?"
Sure, you can easily protect your OSPF domain from external attack, but
that's something your router CPU and/or data plane would have to deal with it had to, and we've all seen situations where filters break in certain code for various reasons. Or vendors change the way filtering works in newer code without properly notifying customers about such changes.
Mark.
No filters. There are just no routes that will take a network packet that arrive on an interface in VRF internet and move it to an interface in VRF default without adding a MPLS header to mark the VRF. With the MPLS header the packet type is no longer IPv4 but MPLS. Therefore there is no way you from the internet or from a customer link can even attempt to inject packets that would be received by the OSPF process. Since we use 10.0.0.0/8 and our vrf internet has no such route, you would just get no route to host if you tried. Regards Baldur
On 11/Nov/16 12:07, Baldur Norddahl wrote:
No filters. There are just no routes that will take a network packet that arrive on an interface in VRF internet and move it to an interface in VRF default without adding a MPLS header to mark the VRF. With the MPLS header the packet type is no longer IPv4 but MPLS.
Therefore there is no way you from the internet or from a customer link can even attempt to inject packets that would be received by the OSPF process. Since we use 10.0.0.0/8 and our vrf internet has no such route, you would just get no route to host if you tried.
Good for you. We don't run the whole "Internet in a VRF" architecture (too many moving parts), so not having our IGP being exposed to IP helps :-). Mark.
Den 11/11/2016 kl. 11.20 skrev Mark Tinka:
On 11/Nov/16 12:07, Baldur Norddahl wrote:
No filters. There are just no routes that will take a network packet that arrive on an interface in VRF internet and move it to an interface in VRF default without adding a MPLS header to mark the VRF. With the MPLS header the packet type is no longer IPv4 but MPLS.
Therefore there is no way you from the internet or from a customer link can even attempt to inject packets that would be received by the OSPF process. Since we use 10.0.0.0/8 and our vrf internet has no such route, you would just get no route to host if you tried.
Good for you.
We don't run the whole "Internet in a VRF" architecture (too many moving parts), so not having our IGP being exposed to IP helps :-).
Internet in a VRF just works and it is not at all complicated. I will recommend it for anyone which has the equipment that can do it. I do realise that not everyone can do this however. I have not studied OSPFv3 in detail but it appears that only IPv6 link local addresses are used. Since that can not be routed, I do not think OSPFv3 exposes anything to the Internet. I would probably go with OSPFv3 if I had to configure a network without VRF support. If I was coding an OSPFv3 daemon I would make it bind only to link local addresses on interfaces, which will guarantee that no traffic is received from outsiders. Regards, Baldur
On 12/Nov/16 16:07, Baldur Norddahl wrote:
I have not studied OSPFv3 in detail but it appears that only IPv6 link local addresses are used. Since that can not be routed, I do not think OSPFv3 exposes anything to the Internet. I would probably go with OSPFv3 if I had to configure a network without VRF support.
If I was coding an OSPFv3 daemon I would make it bind only to link local addresses on interfaces, which will guarantee that no traffic is received from outsiders.
OSPFv3 does, indeed, form adjacencies against the link-local scope - fe80::/10. This is unlike OSPFv2 which does the same on the configured IPv4 address. If I had to run OSPF, it would certainly be OSPFv3. Even when using it to carry IPv4 NLRI, you still need to run IPv6 on the corresponding interfaces as that is how adjacencies to support either or both address families are formed. Mark.
As with anything, it depends on what your needs are. https://pathfinder.juniper.net/feature-explorer/search-features.html Type IS-IS in the box Feature set will vary between JunOS releases. On Thu, Nov 10, 2016 at 1:23 PM, Nick Hilliard <nick@foobar.org> wrote:
Josh Reynolds wrote:
Juniper of their own merits, but they miss many of the IS-IS features Cisco has (of course).
I think people were looking for specifics about the implementation deficits in the junos version which caused enough problems to justify the term "not getting it"?
Nick
Josh Reynolds wrote:
As with anything, it depends on what your needs are.
https://pathfinder.juniper.net/feature-explorer/search-features.html
Type IS-IS in the box
Feature set will vary between JunOS releases.
Josh, you made two statements: 1. Juniper was "not getting it" and 2. "they miss many of the IS-IS features Cisco has". Could you provide details on these "many" features that Junos is missing? Linking to Juniper's feature explorer is hand-waving, and does not answer the question. Nick
I have not kept up with all of the feature differences between Cisco's implementation and the other vendors. I can only encourage others interested in this to compare the specific feature sets between the two and see if it meets their needs. What I need in an environment from an IGP may be totally different from another data center, transport, or transit network provider. If I were a vendor or one of the other I would likely have a list of what I do support, or what my competition does not support. On Thu, Nov 10, 2016 at 2:27 PM, Nick Hilliard <nick@foobar.org> wrote:
Josh Reynolds wrote:
As with anything, it depends on what your needs are.
https://pathfinder.juniper.net/feature-explorer/search-features.html
Type IS-IS in the box
Feature set will vary between JunOS releases.
Josh,
you made two statements:
1. Juniper was "not getting it" and 2. "they miss many of the IS-IS features Cisco has".
Could you provide details on these "many" features that Junos is missing? Linking to Juniper's feature explorer is hand-waving, and does not answer the question.
Nick
Josh Reynolds wrote:
I have not kept up with all of the feature differences between Cisco's implementation and the other vendors. I can only encourage others interested in this to compare the specific feature sets between the two and see if it meets their needs. What I need in an environment from an IGP may be totally different from another data center, transport, or transit network provider.
so you aren't prepared to (or can't) provide a single detail about all the many features that the junos isis implementation is apparently missing, which would justify saying that Juniper is "not getting it" Ok. Not even one? A tiny little thin one? Just... just one...? Nick
I'm sure a lot has changed with Juniper as of 2011 in regard to IS-IS support, which was the last time *I* looked. No, I do not have a list sitting ready, that catalogs in details between product lines and specific firmware versions and subversions between multiple vendors what one supports and what one does not as of Nov 11, 2016. What I can do is point you at the vendor list where you can make a comparison of that vendor to others, for the features that you need in your environment - as I'm not getting paid to maintain such lists, and they are. On Thu, Nov 10, 2016 at 2:47 PM, Nick Hilliard <nick@foobar.org> wrote:
Josh Reynolds wrote:
I have not kept up with all of the feature differences between Cisco's implementation and the other vendors. I can only encourage others interested in this to compare the specific feature sets between the two and see if it meets their needs. What I need in an environment from an IGP may be totally different from another data center, transport, or transit network provider.
so you aren't prepared to (or can't) provide a single detail about all the many features that the junos isis implementation is apparently missing, which would justify saying that Juniper is "not getting it"
Ok.
Not even one? A tiny little thin one? Just... just one...?
Nick
Josh Reynolds wrote:
I'm sure a lot has changed with Juniper as of 2011 in regard to IS-IS support, which was the last time *I* looked.
No, I do not have a list sitting ready, that catalogs in details between product lines and specific firmware versions and subversions between multiple vendors what one supports and what one does not as of Nov 11, 2016.
What I can do is point you at the vendor list where you can make a comparison of that vendor to others, for the features that you need in your environment - as I'm not getting paid to maintain such lists, and they are.
So what you're saying is that you can't even provide a single missing feature to justify trash-talking a vendor the way you did? Not even one?? Nick
I didn't "trash talk" a vendor. If I did, it would be a multi-thousand line hate fueled rant with examples and enough colorful language to make submarine crews blush. Cisco has been pushing EIGRP and IS-IS as part of their "showing" for decades. During that same time frame, the majority of the other vendors and the open source daemons have been using OSPF as their IGP offering. In the mean time, Cisco found a need to introduce more and more vendor specific features into their IS-IS offering - no different than any other vendor would do in their situation to promote the business case (better scaling, vendor lock-in, other bits). If you go looking for cross vendor compatibility with as many devices (routers, switches, servers, etc) as possible, you're going to end up with OSPF [or BGP, for the data center types that run it to edge nodes]. You will find a handful, as some have mentioned, of vendors that have adopted the open version of the protocol and have tried to add comparable/compatible features to close the gap. Since the last time I looked, I could not get the same feature sets running IS-IS in a multi-vendor environment as I could running OSPF. This was my experience at the time, based on my research and discussions with the vendors. On Nov 10, 2016 3:49 PM, "Nick Hilliard" <nick@foobar.org> wrote:
Josh Reynolds wrote:
I'm sure a lot has changed with Juniper as of 2011 in regard to IS-IS support, which was the last time *I* looked.
No, I do not have a list sitting ready, that catalogs in details between product lines and specific firmware versions and subversions between multiple vendors what one supports and what one does not as of Nov 11, 2016.
What I can do is point you at the vendor list where you can make a comparison of that vendor to others, for the features that you need in your environment - as I'm not getting paid to maintain such lists, and they are.
So what you're saying is that you can't even provide a single missing feature to justify trash-talking a vendor the way you did? Not even one??
Nick
Hi, What IGP features do you need, and for what reason? Cheers, mhLe 10 nov. 2016, à 23:04, Josh Reynolds <josh@kyneticwifi.com> a écrit: I didn't "trash talk" a vendor. If I did, it would be a multi-thousand line hate fueled rant with examples and enough colorful language to make submarine crews blush. Cisco has been pushing EIGRP and IS-IS as part of their "showing" for decades. During that same time frame, the majority of the other vendors and the open source daemons have been using OSPF as their IGP offering. In the mean time, Cisco found a need to introduce more and more vendor specific features into their IS-IS offering - no different than any other vendor would do in their situation to promote the business case (better scaling, vendor lock-in, other bits). If you go looking for cross vendor compatibility with as many devices (routers, switches, servers, etc) as possible, you're going to end up with OSPF [or BGP, for the data center types that run it to edge nodes]. You will find a handful, as some have mentioned, of vendors that have adopted the open version of the protocol and have tried to add comparable/compatible features to close the gap. Since the last time I looked, I could not get the same feature sets running IS-IS in a multi-vendor environment as I could running OSPF. This was my experience at the time, based on my research and discussions with the vendors. On Nov 10, 2016 3:49 PM, "Nick Hilliard" <nick@foobar.org> wrote: Josh Reynolds wrote: I'm sure a lot has changed with Juniper as of 2011 in regard to IS-IS support, which was the last time *I* looked. No, I do not have a list sitting ready, that catalogs in details between product lines and specific firmware versions and subversions between multiple vendors what one supports and what one does not as of Nov 11, 2016. What I can do is point you at the vendor list where you can make a comparison of that vendor to others, for the features that you need in your environment - as I'm not getting paid to maintain such lists, and they are. So what you're saying is that you can't even provide a single missing feature to justify trash-talking a vendor the way you did? Not even one?? Nick Le 10 nov. 2016 23:04, à 23:04, Josh Reynolds <josh@kyneticwifi.com> a écrit:
I didn't "trash talk" a vendor. If I did, it would be a multi-thousand line hate fueled rant with examples and enough colorful language to make submarine crews blush.
Cisco has been pushing EIGRP and IS-IS as part of their "showing" for decades. During that same time frame, the majority of the other vendors and the open source daemons have been using OSPF as their IGP offering. In the mean time, Cisco found a need to introduce more and more vendor specific features into their IS-IS offering - no different than any other vendor would do in their situation to promote the business case (better scaling, vendor lock-in, other bits).
If you go looking for cross vendor compatibility with as many devices (routers, switches, servers, etc) as possible, you're going to end up with OSPF [or BGP, for the data center types that run it to edge nodes]. You will find a handful, as some have mentioned, of vendors that have adopted the open version of the protocol and have tried to add comparable/compatible features to close the gap.
Since the last time I looked, I could not get the same feature sets running IS-IS in a multi-vendor environment as I could running OSPF. This was my experience at the time, based on my research and discussions with the vendors.
On Nov 10, 2016 3:49 PM, "Nick Hilliard" <nick@foobar.org> wrote:
Josh Reynolds wrote:
I'm sure a lot has changed with Juniper as of 2011 in regard to IS-IS support, which was the last time *I* looked.
No, I do not have a list sitting ready, that catalogs in details between product lines and specific firmware versions and subversions between multiple vendors what one supports and what one does not as of Nov 11, 2016.
What I can do is point you at the vendor list where you can make a comparison of that vendor to others, for the features that you need in your environment - as I'm not getting paid to maintain such lists, and they are.
So what you're saying is that you can't even provide a single missing feature to justify trash-talking a vendor the way you did? Not even one??
Nick
Josh Reynolds wrote:
I didn't "trash talk" a vendor. If I did, it would be a multi-thousand line hate fueled rant with examples and enough colorful language to make submarine crews blush.
I have no doubt it would be the best rant. It would be a beautiful rant. Entertaining and all as hand-waving may be, please let us know if you manage to unearth any actual facts to support the claims that you made about junos's alleged feature deficits. Nick
As cute as your impotent white knighting of one vendor is (I very much like Juniper BTW), you're absolutely ignoring my original premise and point because you got your panties in a wad over a potential triviality of an internet comment - where documentation exists, should one take the time to go through it, to find discrepancies between them. So, if you'd like to prove your point and earn brownie points with $vendor, on a feature by feature basis please take the time to consult documentation of two vendors products (you can even pick the platform and subversion release!) to refute my claim. This has nothing at all to do with the point of my statement mind you, it's simply a sidetrack that has wasted enough time already. That said, glance across the landscape as a whole of all of the routing platforms out there. Hardware AND softwsre. Which ones support bare bones IS-IS? Which ones have a decent subset of extensions? Are they comparable or compatible with others? The end result is a *very mixed bag*, with far more not supporting IS-IS at all, or only supporting the bare minimum to even go by that name in a datasheet. Thus, my point stands. If you want as much flexibility in your environment as you can have, you want OSPF or BGP as your IGP. On Nov 10, 2016 5:33 PM, "Nick Hilliard" <nick@foobar.org> wrote:
Josh Reynolds wrote:
I didn't "trash talk" a vendor. If I did, it would be a multi-thousand line hate fueled rant with examples and enough colorful language to make submarine crews blush.
I have no doubt it would be the best rant. It would be a beautiful rant.
Entertaining and all as hand-waving may be, please let us know if you manage to unearth any actual facts to support the claims that you made about junos's alleged feature deficits.
Nick
Your original point was that a list of vendors "didn't get IS-IS" but provided no details about what you are talking about. As far as all the documentation I have read, and some of the documentation you linked to, it works just fine on quite a few vendors, and a few people on this list. Your original point mentions nothing about wider OSPF adoption, which you seem to have shifted to to deflect having to provide any actual details. Are we to assume that your original point was incorrect? As far as the landscape as a whole, I have seen quite a few networks that get by with either protocol just fine, the use-case for a given network is not such a broad landscape, so I think "use the right tool for the job" seems very apt, and that you can't just say that only two protocols are suitable for all jobs. /Charles On Thu, Nov 10, 2016 at 6:00 PM, Josh Reynolds <josh@kyneticwifi.com> wrote:
As cute as your impotent white knighting of one vendor is (I very much like Juniper BTW), you're absolutely ignoring my original premise and point because you got your panties in a wad over a potential triviality of an internet comment - where documentation exists, should one take the time to go through it, to find discrepancies between them.
So, if you'd like to prove your point and earn brownie points with $vendor, on a feature by feature basis please take the time to consult documentation of two vendors products (you can even pick the platform and subversion release!) to refute my claim. This has nothing at all to do with the point of my statement mind you, it's simply a sidetrack that has wasted enough time already.
That said, glance across the landscape as a whole of all of the routing platforms out there. Hardware AND softwsre. Which ones support bare bones IS-IS? Which ones have a decent subset of extensions? Are they comparable or compatible with others? The end result is a *very mixed bag*, with far more not supporting IS-IS at all, or only supporting the bare minimum to even go by that name in a datasheet.
Thus, my point stands. If you want as much flexibility in your environment as you can have, you want OSPF or BGP as your IGP.
On Nov 10, 2016 5:33 PM, "Nick Hilliard" <nick@foobar.org> wrote:
Josh Reynolds wrote:
I didn't "trash talk" a vendor. If I did, it would be a multi-thousand line hate fueled rant with examples and enough colorful language to make submarine crews blush.
I have no doubt it would be the best rant. It would be a beautiful rant.
Entertaining and all as hand-waving may be, please let us know if you manage to unearth any actual facts to support the claims that you made about junos's alleged feature deficits.
Nick
My first post: On Nov 10, 2016 6:24 PM, "Charles van Niman" <charles@phukish.com> wrote:
Your original point was that a list of vendors "didn't get IS-IS" but provided no details about what you are talking about. As far as all the documentation I have read, and some of the documentation you linked to, it works just fine on quite a few vendors, and a few people on this list. Your original point mentions nothing about wider OSPF adoption, which you seem to have shifted to to deflect having to provide any actual details.
Are we to assume that your original point was incorrect? As far as the landscape as a whole, I have seen quite a few networks that get by with either protocol just fine, the use-case for a given network is not such a broad landscape, so I think "use the right tool for the job" seems very apt, and that you can't just say that only two protocols are suitable for all jobs.
/Charles
As cute as your impotent white knighting of one vendor is (I very much
Juniper BTW), you're absolutely ignoring my original premise and point because you got your panties in a wad over a potential triviality of an internet comment - where documentation exists, should one take the time to go through it, to find discrepancies between them.
So, if you'd like to prove your point and earn brownie points with $vendor, on a feature by feature basis please take the time to consult documentation of two vendors products (you can even pick the platform and subversion release!) to refute my claim. This has nothing at all to do with the
On Thu, Nov 10, 2016 at 6:00 PM, Josh Reynolds <josh@kyneticwifi.com> wrote: like point
of my statement mind you, it's simply a sidetrack that has wasted enough time already.
That said, glance across the landscape as a whole of all of the routing platforms out there. Hardware AND softwsre. Which ones support bare bones IS-IS? Which ones have a decent subset of extensions? Are they comparable or compatible with others? The end result is a *very mixed bag*, with far more not supporting IS-IS at all, or only supporting the bare minimum to even go by that name in a datasheet.
Thus, my point stands. If you want as much flexibility in your environment as you can have, you want OSPF or BGP as your IGP.
On Nov 10, 2016 5:33 PM, "Nick Hilliard" <nick@foobar.org> wrote:
Josh Reynolds wrote:
I didn't "trash talk" a vendor. If I did, it would be a multi-thousand line hate fueled rant with examples and enough colorful language to make submarine crews blush.
I have no doubt it would be the best rant. It would be a beautiful rant.
Entertaining and all as hand-waving may be, please let us know if you manage to unearth any actual facts to support the claims that you made about junos's alleged feature deficits.
Nick
My first post said the following: "Vendor support for IS-IS is quite limited - many options for OSPF." On Nov 10, 2016 6:24 PM, "Charles van Niman" <charles@phukish.com> wrote:
Your original point was that a list of vendors "didn't get IS-IS" but provided no details about what you are talking about. As far as all the documentation I have read, and some of the documentation you linked to, it works just fine on quite a few vendors, and a few people on this list. Your original point mentions nothing about wider OSPF adoption, which you seem to have shifted to to deflect having to provide any actual details.
Are we to assume that your original point was incorrect? As far as the landscape as a whole, I have seen quite a few networks that get by with either protocol just fine, the use-case for a given network is not such a broad landscape, so I think "use the right tool for the job" seems very apt, and that you can't just say that only two protocols are suitable for all jobs.
/Charles
As cute as your impotent white knighting of one vendor is (I very much
Juniper BTW), you're absolutely ignoring my original premise and point because you got your panties in a wad over a potential triviality of an internet comment - where documentation exists, should one take the time to go through it, to find discrepancies between them.
So, if you'd like to prove your point and earn brownie points with $vendor, on a feature by feature basis please take the time to consult documentation of two vendors products (you can even pick the platform and subversion release!) to refute my claim. This has nothing at all to do with the
On Thu, Nov 10, 2016 at 6:00 PM, Josh Reynolds <josh@kyneticwifi.com> wrote: like point
of my statement mind you, it's simply a sidetrack that has wasted enough time already.
That said, glance across the landscape as a whole of all of the routing platforms out there. Hardware AND softwsre. Which ones support bare bones IS-IS? Which ones have a decent subset of extensions? Are they comparable or compatible with others? The end result is a *very mixed bag*, with far more not supporting IS-IS at all, or only supporting the bare minimum to even go by that name in a datasheet.
Thus, my point stands. If you want as much flexibility in your environment as you can have, you want OSPF or BGP as your IGP.
On Nov 10, 2016 5:33 PM, "Nick Hilliard" <nick@foobar.org> wrote:
Josh Reynolds wrote:
I didn't "trash talk" a vendor. If I did, it would be a multi-thousand line hate fueled rant with examples and enough colorful language to make submarine crews blush.
I have no doubt it would be the best rant. It would be a beautiful rant.
Entertaining and all as hand-waving may be, please let us know if you manage to unearth any actual facts to support the claims that you made about junos's alleged feature deficits.
Nick
Maybe you didn't look hard enough? ISIS feature support in a bunch of different products has sucked for a long time vs OSPF, but that's a pretty well known and accepted fact. Generally these features are the same across multiple products from the same vendor (usually across the same OS anyway)... Just name 1 feature that was in Cisco and wasn't in other implementations........... Just one.. Something.. Does ISIS on IOS make and hand out ice cream on Fridays? I want to know if I'm missing out.. -- Tim On Thu, Nov 10, 2016 at 6:33 PM, Josh Reynolds <josh@kyneticwifi.com> wrote:
My first post said the following:
"Vendor support for IS-IS is quite limited - many options for OSPF."
On Nov 10, 2016 6:24 PM, "Charles van Niman" <charles@phukish.com> wrote:
Your original point was that a list of vendors "didn't get IS-IS" but provided no details about what you are talking about. As far as all the documentation I have read, and some of the documentation you linked to, it works just fine on quite a few vendors, and a few people on this list. Your original point mentions nothing about wider OSPF adoption, which you seem to have shifted to to deflect having to provide any actual details.
Are we to assume that your original point was incorrect? As far as the landscape as a whole, I have seen quite a few networks that get by with either protocol just fine, the use-case for a given network is not such a broad landscape, so I think "use the right tool for the job" seems very apt, and that you can't just say that only two protocols are suitable for all jobs.
/Charles
As cute as your impotent white knighting of one vendor is (I very much
Juniper BTW), you're absolutely ignoring my original premise and point because you got your panties in a wad over a potential triviality of an internet comment - where documentation exists, should one take the time to go through it, to find discrepancies between them.
So, if you'd like to prove your point and earn brownie points with $vendor, on a feature by feature basis please take the time to consult documentation of two vendors products (you can even pick the platform and subversion release!) to refute my claim. This has nothing at all to do with the
On Thu, Nov 10, 2016 at 6:00 PM, Josh Reynolds <josh@kyneticwifi.com> wrote: like point
of my statement mind you, it's simply a sidetrack that has wasted enough time already.
That said, glance across the landscape as a whole of all of the routing platforms out there. Hardware AND softwsre. Which ones support bare bones IS-IS? Which ones have a decent subset of extensions? Are they comparable or compatible with others? The end result is a *very mixed bag*, with far more not supporting IS-IS at all, or only supporting the bare minimum to even go by that name in a datasheet.
Thus, my point stands. If you want as much flexibility in your environment as you can have, you want OSPF or BGP as your IGP.
On Nov 10, 2016 5:33 PM, "Nick Hilliard" <nick@foobar.org> wrote:
Josh Reynolds wrote:
I didn't "trash talk" a vendor. If I did, it would be a multi-thousand line hate fueled rant with examples and enough colorful language to make submarine crews blush.
I have no doubt it would be the best rant. It would be a beautiful rant.
Entertaining and all as hand-waving may be, please let us know if you manage to unearth any actual facts to support the claims that you made about junos's alleged feature deficits.
Nick
Here's a start! "Support for OSPFv3 and IS-IS is various beta states currently; IS-IS for IPv4 is believed to be usable while OSPFv3 and IS-IS for IPv6 have known issues." On Nov 10, 2016 6:50 PM, "Tim Jackson" <jackson.tim@gmail.com> wrote:
Maybe you didn't look hard enough?
ISIS feature support in a bunch of different products has sucked for a long time vs OSPF, but that's a pretty well known and accepted fact. Generally these features are the same across multiple products from the same vendor (usually across the same OS anyway)...
Just name 1 feature that was in Cisco and wasn't in other implementations........... Just one.. Something.. Does ISIS on IOS make and hand out ice cream on Fridays? I want to know if I'm missing out..
-- Tim
On Thu, Nov 10, 2016 at 6:33 PM, Josh Reynolds <josh@kyneticwifi.com> wrote:
My first post said the following:
"Vendor support for IS-IS is quite limited - many options for OSPF."
On Nov 10, 2016 6:24 PM, "Charles van Niman" <charles@phukish.com> wrote:
Your original point was that a list of vendors "didn't get IS-IS" but provided no details about what you are talking about. As far as all the documentation I have read, and some of the documentation you linked to, it works just fine on quite a few vendors, and a few people on this list. Your original point mentions nothing about wider OSPF adoption, which you seem to have shifted to to deflect having to provide any actual details.
Are we to assume that your original point was incorrect? As far as the landscape as a whole, I have seen quite a few networks that get by with either protocol just fine, the use-case for a given network is not such a broad landscape, so I think "use the right tool for the job" seems very apt, and that you can't just say that only two protocols are suitable for all jobs.
/Charles
As cute as your impotent white knighting of one vendor is (I very much
Juniper BTW), you're absolutely ignoring my original premise and point because you got your panties in a wad over a potential triviality of an internet comment - where documentation exists, should one take the time to go through it, to find discrepancies between them.
So, if you'd like to prove your point and earn brownie points with $vendor, on a feature by feature basis please take the time to consult documentation of two vendors products (you can even pick the platform and subversion release!) to refute my claim. This has nothing at all to do with the
On Thu, Nov 10, 2016 at 6:00 PM, Josh Reynolds <josh@kyneticwifi.com> wrote: like point
of my statement mind you, it's simply a sidetrack that has wasted enough time already.
That said, glance across the landscape as a whole of all of the routing platforms out there. Hardware AND softwsre. Which ones support bare bones IS-IS? Which ones have a decent subset of extensions? Are they comparable or compatible with others? The end result is a *very mixed bag*, with far more not supporting IS-IS at all, or only supporting the bare minimum to even go by that name in a datasheet.
Thus, my point stands. If you want as much flexibility in your environment as you can have, you want OSPF or BGP as your IGP.
On Nov 10, 2016 5:33 PM, "Nick Hilliard" <nick@foobar.org> wrote:
Josh Reynolds wrote:
I didn't "trash talk" a vendor. If I did, it would be a multi-thousand line hate fueled rant with examples and enough colorful language to make submarine crews blush.
I have no doubt it would be the best rant. It would be a beautiful rant.
Entertaining and all as hand-waving may be, please let us know if you manage to unearth any actual facts to support the claims that you made about junos's alleged feature deficits.
Nick
Oops, forgot link. Cooking dinner :) http://www.nongnu.org/quagga/ On Nov 10, 2016 6:53 PM, "Josh Reynolds" <josh@kyneticwifi.com> wrote:
Here's a start!
"Support for OSPFv3 and IS-IS is various beta states currently; IS-IS for IPv4 is believed to be usable while OSPFv3 and IS-IS for IPv6 have known issues."
On Nov 10, 2016 6:50 PM, "Tim Jackson" <jackson.tim@gmail.com> wrote:
Maybe you didn't look hard enough?
ISIS feature support in a bunch of different products has sucked for a long time vs OSPF, but that's a pretty well known and accepted fact. Generally these features are the same across multiple products from the same vendor (usually across the same OS anyway)...
Just name 1 feature that was in Cisco and wasn't in other implementations........... Just one.. Something.. Does ISIS on IOS make and hand out ice cream on Fridays? I want to know if I'm missing out..
-- Tim
On Thu, Nov 10, 2016 at 6:33 PM, Josh Reynolds <josh@kyneticwifi.com> wrote:
My first post said the following:
"Vendor support for IS-IS is quite limited - many options for OSPF."
On Nov 10, 2016 6:24 PM, "Charles van Niman" <charles@phukish.com> wrote:
Your original point was that a list of vendors "didn't get IS-IS" but provided no details about what you are talking about. As far as all the documentation I have read, and some of the documentation you linked to, it works just fine on quite a few vendors, and a few people on this list. Your original point mentions nothing about wider OSPF adoption, which you seem to have shifted to to deflect having to provide any actual details.
Are we to assume that your original point was incorrect? As far as the landscape as a whole, I have seen quite a few networks that get by with either protocol just fine, the use-case for a given network is not such a broad landscape, so I think "use the right tool for the job" seems very apt, and that you can't just say that only two protocols are suitable for all jobs.
/Charles
As cute as your impotent white knighting of one vendor is (I very much
Juniper BTW), you're absolutely ignoring my original premise and
because you got your panties in a wad over a potential triviality of an internet comment - where documentation exists, should one take the time to go through it, to find discrepancies between them.
So, if you'd like to prove your point and earn brownie points with $vendor, on a feature by feature basis please take the time to consult documentation of two vendors products (you can even pick the platform and subversion release!) to refute my claim. This has nothing at all to do with the
On Thu, Nov 10, 2016 at 6:00 PM, Josh Reynolds <josh@kyneticwifi.com> wrote: like point point
of my statement mind you, it's simply a sidetrack that has wasted enough time already.
That said, glance across the landscape as a whole of all of the routing platforms out there. Hardware AND softwsre. Which ones support bare bones IS-IS? Which ones have a decent subset of extensions? Are they comparable or compatible with others? The end result is a *very mixed bag*, with far more not supporting IS-IS at all, or only supporting the bare minimum to even go by that name in a datasheet.
Thus, my point stands. If you want as much flexibility in your environment as you can have, you want OSPF or BGP as your IGP.
On Nov 10, 2016 5:33 PM, "Nick Hilliard" <nick@foobar.org> wrote:
Josh Reynolds wrote: > I didn't "trash talk" a vendor. If I did, it would be a multi-thousand > line hate fueled rant with examples and enough colorful language to make > submarine crews blush.
I have no doubt it would be the best rant. It would be a beautiful rant.
Entertaining and all as hand-waving may be, please let us know if you manage to unearth any actual facts to support the claims that you made about junos's alleged feature deficits.
Nick
So what about commercial implementations? -- Tim On Thu, Nov 10, 2016 at 6:54 PM, Josh Reynolds <josh@kyneticwifi.com> wrote:
Oops, forgot link. Cooking dinner :)
On Nov 10, 2016 6:53 PM, "Josh Reynolds" <josh@kyneticwifi.com> wrote:
Here's a start!
"Support for OSPFv3 and IS-IS is various beta states currently; IS-IS for IPv4 is believed to be usable while OSPFv3 and IS-IS for IPv6 have known issues."
On Nov 10, 2016 6:50 PM, "Tim Jackson" <jackson.tim@gmail.com> wrote:
Maybe you didn't look hard enough?
ISIS feature support in a bunch of different products has sucked for a long time vs OSPF, but that's a pretty well known and accepted fact. Generally these features are the same across multiple products from the same vendor (usually across the same OS anyway)...
Just name 1 feature that was in Cisco and wasn't in other implementations........... Just one.. Something.. Does ISIS on IOS make and hand out ice cream on Fridays? I want to know if I'm missing out..
-- Tim
On Thu, Nov 10, 2016 at 6:33 PM, Josh Reynolds <josh@kyneticwifi.com> wrote:
My first post said the following:
"Vendor support for IS-IS is quite limited - many options for OSPF."
On Nov 10, 2016 6:24 PM, "Charles van Niman" <charles@phukish.com> wrote:
Your original point was that a list of vendors "didn't get IS-IS" but provided no details about what you are talking about. As far as all the documentation I have read, and some of the documentation you linked to, it works just fine on quite a few vendors, and a few people on this list. Your original point mentions nothing about wider OSPF adoption, which you seem to have shifted to to deflect having to provide any actual details.
Are we to assume that your original point was incorrect? As far as the landscape as a whole, I have seen quite a few networks that get by with either protocol just fine, the use-case for a given network is not such a broad landscape, so I think "use the right tool for the job" seems very apt, and that you can't just say that only two protocols are suitable for all jobs.
/Charles
As cute as your impotent white knighting of one vendor is (I very much
Juniper BTW), you're absolutely ignoring my original premise and
because you got your panties in a wad over a potential triviality of an internet comment - where documentation exists, should one take the time to go through it, to find discrepancies between them.
So, if you'd like to prove your point and earn brownie points with $vendor, on a feature by feature basis please take the time to consult documentation of two vendors products (you can even pick the platform and subversion release!) to refute my claim. This has nothing at all to do with the
On Thu, Nov 10, 2016 at 6:00 PM, Josh Reynolds <josh@kyneticwifi.com> wrote: like point point
of my statement mind you, it's simply a sidetrack that has wasted enough time already.
That said, glance across the landscape as a whole of all of the routing platforms out there. Hardware AND softwsre. Which ones support bare bones IS-IS? Which ones have a decent subset of extensions? Are they comparable or compatible with others? The end result is a *very mixed bag*, with far more not supporting IS-IS at all, or only supporting the bare minimum to even go by that name in a datasheet.
Thus, my point stands. If you want as much flexibility in your environment as you can have, you want OSPF or BGP as your IGP.
On Nov 10, 2016 5:33 PM, "Nick Hilliard" <nick@foobar.org> wrote:
> Josh Reynolds wrote: > > I didn't "trash talk" a vendor. If I did, it would be a multi-thousand > > line hate fueled rant with examples and enough colorful language to make > > submarine crews blush. > > I have no doubt it would be the best rant. It would be a beautiful rant. > > Entertaining and all as hand-waving may be, please let us know if you > manage to unearth any actual facts to support the claims that you made > about junos's alleged feature deficits. > > Nick > >
So, we need to narrow the discussion now to only commercial solutions? This is fun and all (not really) but you can have your thread. Congrats, you win. I'm not sure what. On Nov 10, 2016 7:01 PM, "Tim Jackson" <jackson.tim@gmail.com> wrote:
So what about commercial implementations?
-- Tim
On Thu, Nov 10, 2016 at 6:54 PM, Josh Reynolds <josh@kyneticwifi.com> wrote:
Oops, forgot link. Cooking dinner :)
On Nov 10, 2016 6:53 PM, "Josh Reynolds" <josh@kyneticwifi.com> wrote:
Here's a start!
"Support for OSPFv3 and IS-IS is various beta states currently; IS-IS for IPv4 is believed to be usable while OSPFv3 and IS-IS for IPv6 have known issues."
On Nov 10, 2016 6:50 PM, "Tim Jackson" <jackson.tim@gmail.com> wrote:
Maybe you didn't look hard enough?
ISIS feature support in a bunch of different products has sucked for a long time vs OSPF, but that's a pretty well known and accepted fact. Generally these features are the same across multiple products from the same vendor (usually across the same OS anyway)...
Just name 1 feature that was in Cisco and wasn't in other implementations........... Just one.. Something.. Does ISIS on IOS make and hand out ice cream on Fridays? I want to know if I'm missing out..
-- Tim
On Thu, Nov 10, 2016 at 6:33 PM, Josh Reynolds <josh@kyneticwifi.com> wrote:
My first post said the following:
"Vendor support for IS-IS is quite limited - many options for OSPF."
On Nov 10, 2016 6:24 PM, "Charles van Niman" <charles@phukish.com> wrote:
Your original point was that a list of vendors "didn't get IS-IS" but provided no details about what you are talking about. As far as all the documentation I have read, and some of the documentation you linked to, it works just fine on quite a few vendors, and a few people on this list. Your original point mentions nothing about wider OSPF adoption, which you seem to have shifted to to deflect having to provide any actual details.
Are we to assume that your original point was incorrect? As far as the landscape as a whole, I have seen quite a few networks that get by with either protocol just fine, the use-case for a given network is not such a broad landscape, so I think "use the right tool for the job" seems very apt, and that you can't just say that only two protocols are suitable for all jobs.
/Charles
On Thu, Nov 10, 2016 at 6:00 PM, Josh Reynolds <josh@kyneticwifi.com
wrote: > As cute as your impotent white knighting of one vendor is (I very much like > Juniper BTW), you're absolutely ignoring my original premise and point > because you got your panties in a wad over a potential triviality of an > internet comment - where documentation exists, should one take the time to > go through it, to find discrepancies between them. > > So, if you'd like to prove your point and earn brownie points with $vendor, > on a feature by feature basis please take the time to consult documentation > of two vendors products (you can even pick the platform and subversion > release!) to refute my claim. This has nothing at all to do with the point > of my statement mind you, it's simply a sidetrack that has wasted enough > time already. > > That said, glance across the landscape as a whole of all of the routing > platforms out there. Hardware AND softwsre. Which ones support bare bones > IS-IS? Which ones have a decent subset of extensions? Are they comparable > or compatible with others? The end result is a *very mixed bag*, with far > more not supporting IS-IS at all, or only supporting the bare minimum to > even go by that name in a datasheet. > > Thus, my point stands. If you want as much flexibility in your environment > as you can have, you want OSPF or BGP as your IGP. > > On Nov 10, 2016 5:33 PM, "Nick Hilliard" <nick@foobar.org> wrote: > >> Josh Reynolds wrote: >> > I didn't "trash talk" a vendor. If I did, it would be a multi-thousand >> > line hate fueled rant with examples and enough colorful language to make >> > submarine crews blush. >> >> I have no doubt it would be the best rant. It would be a beautiful rant. >> >> Entertaining and all as hand-waving may be, please let us know if you >> manage to unearth any actual facts to support the claims that you made >> about junos's alleged feature deficits. >> >> Nick >> >>
Uh......... I quote:
Cisco is the only "real" IS-IS vendor.
Juniper, Brocade, Arista, Avaya, etc you're not getting it. Any of the whitebox hardware or real SDN capable solutions, you're going to be on OSPF.
Care to elaborate on any of those commercial vendors? -- Tim On Thu, Nov 10, 2016 at 7:04 PM, Josh Reynolds <josh@kyneticwifi.com> wrote:
So, we need to narrow the discussion now to only commercial solutions?
This is fun and all (not really) but you can have your thread.
Congrats, you win. I'm not sure what.
On Nov 10, 2016 7:01 PM, "Tim Jackson" <jackson.tim@gmail.com> wrote:
So what about commercial implementations?
-- Tim
On Thu, Nov 10, 2016 at 6:54 PM, Josh Reynolds <josh@kyneticwifi.com> wrote:
Oops, forgot link. Cooking dinner :)
On Nov 10, 2016 6:53 PM, "Josh Reynolds" <josh@kyneticwifi.com> wrote:
Here's a start!
"Support for OSPFv3 and IS-IS is various beta states currently; IS-IS for IPv4 is believed to be usable while OSPFv3 and IS-IS for IPv6 have known issues."
On Nov 10, 2016 6:50 PM, "Tim Jackson" <jackson.tim@gmail.com> wrote:
Maybe you didn't look hard enough?
ISIS feature support in a bunch of different products has sucked for a long time vs OSPF, but that's a pretty well known and accepted fact. Generally these features are the same across multiple products from the same vendor (usually across the same OS anyway)...
Just name 1 feature that was in Cisco and wasn't in other implementations........... Just one.. Something.. Does ISIS on IOS make and hand out ice cream on Fridays? I want to know if I'm missing out..
-- Tim
On Thu, Nov 10, 2016 at 6:33 PM, Josh Reynolds <josh@kyneticwifi.com> wrote:
My first post said the following:
"Vendor support for IS-IS is quite limited - many options for OSPF."
On Nov 10, 2016 6:24 PM, "Charles van Niman" <charles@phukish.com> wrote:
> Your original point was that a list of vendors "didn't get IS-IS" but > provided no details about what you are talking about. As far as all > the documentation I have read, and some of the documentation you > linked to, it works just fine on quite a few vendors, and a few people > on this list. Your original point mentions nothing about wider OSPF > adoption, which you seem to have shifted to to deflect having to > provide any actual details. > > Are we to assume that your original point was incorrect? As far as the > landscape as a whole, I have seen quite a few networks that get by > with either protocol just fine, the use-case for a given network is > not such a broad landscape, so I think "use the right tool for the > job" seems very apt, and that you can't just say that only two > protocols are suitable for all jobs. > > /Charles > > On Thu, Nov 10, 2016 at 6:00 PM, Josh Reynolds < josh@kyneticwifi.com> > wrote: > > As cute as your impotent white knighting of one vendor is (I very much > like > > Juniper BTW), you're absolutely ignoring my original premise and point > > because you got your panties in a wad over a potential triviality of an > > internet comment - where documentation exists, should one take the time > to > > go through it, to find discrepancies between them. > > > > So, if you'd like to prove your point and earn brownie points with > $vendor, > > on a feature by feature basis please take the time to consult > documentation > > of two vendors products (you can even pick the platform and subversion > > release!) to refute my claim. This has nothing at all to do with the > point > > of my statement mind you, it's simply a sidetrack that has wasted enough > > time already. > > > > That said, glance across the landscape as a whole of all of the routing > > platforms out there. Hardware AND softwsre. Which ones support bare bones > > IS-IS? Which ones have a decent subset of extensions? Are they comparable > > or compatible with others? The end result is a *very mixed bag*, with far > > more not supporting IS-IS at all, or only supporting the bare minimum to > > even go by that name in a datasheet. > > > > Thus, my point stands. If you want as much flexibility in your > environment > > as you can have, you want OSPF or BGP as your IGP. > > > > On Nov 10, 2016 5:33 PM, "Nick Hilliard" <nick@foobar.org> wrote: > > > >> Josh Reynolds wrote: > >> > I didn't "trash talk" a vendor. If I did, it would be a multi-thousand > >> > line hate fueled rant with examples and enough colorful language to > make > >> > submarine crews blush. > >> > >> I have no doubt it would be the best rant. It would be a beautiful > rant. > >> > >> Entertaining and all as hand-waving may be, please let us know if you > >> manage to unearth any actual facts to support the claims that you made > >> about junos's alleged feature deficits. > >> > >> Nick > >> > >> >
On 11/Nov/16 03:04, Josh Reynolds wrote:
So, we need to narrow the discussion now to only commercial solutions?
Well, they are the ones we can b*tch and moan to to fix stuff because we pay them a lot of money. I b*tched and moaned to the Quagga routing team and they showed me a place where I could donate money so they can spend more time on a protocol that they don't get a lot of demand for. I can appreciate that (and I have been slacking in making that funding available to them - mea culpa; apologies Mikael and team, I'll resurrect this). Mark.
On Thu, 10 Nov 2016 18:54:36 -0600, Josh Reynolds said:
Oops, forgot link. Cooking dinner :)
So you have *one* implementation that admits it's still somewhat lacking? Color me...... underwhelmed.
On 11/Nov/16 02:54, Josh Reynolds wrote:
Oops, forgot link. Cooking dinner :)
Quagga's IS-IS implementation limitations are well-known. But I don't recall them being in your original list of vendors that had a failed IS-IS implementation (which included Juniper). Mark.
On 11/Nov/16 02:33, Josh Reynolds wrote:
My first post said the following:
"Vendor support for IS-IS is quite limited - many options for OSPF."
Again, the only one I know that struggles is Quagga. But I've not heard any reports from anyone running Brocade, Nokia (ALU), Huawei, e.t.c. that IS-IS doesn't work or is quite limited. I can say both Cisco and Juniper have no issues at all in this area. Arista are young in the routing space, but I am confident their implementations will be up to par soon (if they aren't already). Mark.
On 11/Nov/16 02:00, Josh Reynolds wrote:
That said, glance across the landscape as a whole of all of the routing platforms out there. Hardware AND softwsre. Which ones support bare bones IS-IS? Which ones have a decent subset of extensions? Are they comparable or compatible with others? The end result is a *very mixed bag*, with far more not supporting IS-IS at all, or only supporting the bare minimum to even go by that name in a datasheet.
I (as I suppose most) would consider full spec. support of the protocol to be a bare minimum and acceptable for production. Non-spec. extensions are nice-to-have. Spec. extensions are part of the bare minimum, and would be supported. I'm all for having no configurations on a router - that way, there are fewer avenues to cause network problems. But, we do need configurations on routers to make them work. So if I don't really the knob, it's no good having it there in the first place. Mark.
On 11/Nov/16 00:03, Josh Reynolds wrote:
Since the last time I looked, I could not get the same feature sets running IS-IS in a multi-vendor environment as I could running OSPF. This was my experience at the time, based on my research and discussions with the vendors.
I'd be curious to know what features you were getting in OSPF that were unavailable in IS-IS, at the time. Mark.
I don't think Nick asked for a list, just one single thing, any one thing. To me at least, it doesn't really make sense to make the statement you did, without pointing out what can be done to improve the situation. I would be very interested to hear what network requirements are not being met with Juniper's current IS-IS implementation. /Charles On Thu, Nov 10, 2016 at 3:22 PM, Josh Reynolds <josh@kyneticwifi.com> wrote:
I'm sure a lot has changed with Juniper as of 2011 in regard to IS-IS support, which was the last time *I* looked.
No, I do not have a list sitting ready, that catalogs in details between product lines and specific firmware versions and subversions between multiple vendors what one supports and what one does not as of Nov 11, 2016.
What I can do is point you at the vendor list where you can make a comparison of that vendor to others, for the features that you need in your environment - as I'm not getting paid to maintain such lists, and they are.
On Thu, Nov 10, 2016 at 2:47 PM, Nick Hilliard <nick@foobar.org> wrote:
Josh Reynolds wrote:
I have not kept up with all of the feature differences between Cisco's implementation and the other vendors. I can only encourage others interested in this to compare the specific feature sets between the two and see if it meets their needs. What I need in an environment from an IGP may be totally different from another data center, transport, or transit network provider.
so you aren't prepared to (or can't) provide a single detail about all the many features that the junos isis implementation is apparently missing, which would justify saying that Juniper is "not getting it"
Ok.
Not even one? A tiny little thin one? Just... just one...?
Nick
On 10/Nov/16 23:53, Charles van Niman wrote:
I don't think Nick asked for a list, just one single thing, any one thing. To me at least, it doesn't really make sense to make the statement you did, without pointing out what can be done to improve the situation. I would be very interested to hear what network requirements are not being met with Juniper's current IS-IS implementation.
To be honest, none that I can think of. Many of the feature differences are vendor-specific, particularly with how you can further optimize IS-IS to handle LSP's flooding, flushing, re-calculation, throttling, e.t.c. Bottom line, Juniper fully supports the IS-IS spec., from what we see. Mark.
On 10/Nov/16 21:23, Nick Hilliard wrote:
I think people were looking for specifics about the implementation deficits in the junos version which caused enough problems to justify the term "not getting it"?
The only IS-IS implementation we struggle with is Quagga. For that, we run OSPFv2 and OSPFv3 on Quagga and redistribute that into the IS-IS core. Use-case is Anycast (DNS, NTP, TACACS+, e.t.c.) on FreeBSD. Mark.
I think people were looking for specifics about the implementation deficits in the junos version which caused enough problems to justify the term "not getting it"?
The only IS-IS implementation we struggle with is Quagga.
For that, we run OSPFv2 and OSPFv3 on Quagga and redistribute that into the IS-IS core.
Use-case is Anycast (DNS, NTP, TACACS+, e.t.c.) on FreeBSD.
We have a similar use case, and we run BGP on Quagga. Works great. Haven't seen a need for either IS-IS or OSPF on Quagga yet. For our core IGP it's IS-IS all the way. We switched from OSPF to IS-IS more than 10 years ago, and never regretted it. Steinar Haug, Nethelp consulting, sthaug@nethelp.no
On 11/Nov/16 08:22, sthaug@nethelp.no wrote:
We have a similar use case, and we run BGP on Quagga. Works great. Haven't seen a need for either IS-IS or OSPF on Quagga yet.
Two reasons for us: * IGP metrics in the IGP will determine latency-based decisions. I know BGP can infer the IGP metric, but we are just avoiding situations where this could be non-deterministic due to other BGP-things. * BGP occurs at a much higher layer in the network stack. We run the Anycast servers in the IGP domain because that is at a much more basic layer. If BGP fails, we don't want to have problems logging into our routers because it took TACACS+ with it. There have been times when BGP has run into issues but the IGP has remained alive. Via a jump host (and OoB, of course), we were able to maintain connectivity to the network to fix it because those servers are in the IGP domain. Mark.
Are you sure those other vendors don't do it too? Lol. Dual stack ISIS on Juniper is a thing of beauty...
On Nov 10, 2016, at 1:01 PM, Josh Reynolds <josh@kyneticwifi.com> wrote:
Cisco is the only "real" IS-IS vendor.
Juniper, Brocade, Arista, Avaya, etc you're not getting it. Any of the whitebox hardware or real SDN capable solutions, you're going to be on OSPF.
On Nov 10, 2016 12:13 AM, "Mark Tinka" <mark.tinka@seacom.mu> wrote:
On 10/Nov/16 04:52, Josh Reynolds wrote:
Vendor support for IS-IS is quite limited - many options for OSPF.
Depends on the vendor.
Cisco have as many knobs for IS-IS as they do for OSPF.
Juniper, not so much.
Don't know about other vendors.
At any rate, many of these knobs are not part of the original protocol spec., although they can be very useful when scaling.
Mark.
On 10/Nov/16 20:01, Josh Reynolds wrote:
Cisco is the only "real" IS-IS vendor.
Juniper, Brocade, Arista, Avaya, etc you're not getting it. Any of the whitebox hardware or real SDN capable solutions, you're going to be on OSPF.
We are quite happy with our Cisco-Juniper IS-IS interactions. Granted, IOS, IOS XE and IOS XR all have several IS-IS knobs that Juniper don't, but in all fairness, we aren't complaining. We have the right knobs in the right place on each vendor kit to run a successful IGP domain. Mark.
On 10/Nov/16 04:45, RT Parrish wrote:
1) Network Topology support - The differences between a single OSPF backbone area and a contiguous set of Level-2 adjacencies will occasionally be a deciding factor.
L2 IS-IS can be as chatty as single-area OSPF. That said, IS-IS has native tools to reduce that chatter (like PRC, and iSPF), but to be honest, I'm not sure it makes much of a difference given today's faster router CPU's.
2) Feature Support on a per vendor basis - Some vendors will roll new features out in one or the other protocols prior to the other. Segment Routing and some of its enhancements come to mind as being in ISIS first.
I've noticed that the delay between when IS-IS and/or OSPF pick up a feature the other already has is reasonable. By the time an OSPF has completed evaluating whether they need LFA, it would have been implemented in the IGP. I suppose back then, there was a much bigger between when features made it between both protocols, but things seem to be on par nowadays.
3) Layer 2 adjacencies - I think someone already mentioned that you form adjacencies at layer 2 which also means that with a single adj you can support multiple protocols (v4/v6). OSPF would require two different instances to support both. Maybe good, maybe not. Depends on your desired level of isolation between the two.
OSPFv3 can support the advertisement of IPv4 prefixes. But you'd still need an IPv6 link layer.
4) CPU performance is academic at this point - The SPF calculations in most networks would require next to no difference between the two protocols even if running both IPv4 and v6.
Agree.
End of the day, use the right tool/vendor/technology for the right job.
Agree. Mark.
On 9/Nov/16 19:12, Michael Bullut wrote:
Greetings Team,
While I haven't worked with IS-IS before but the only disadvantage I've encountered with OSPF is that it is resource intensive on the router it is running on which is why only one instance runs on any PE & P device on an ISP network. OSPF is pretty good in handling the core network routing while BGP & EGP handle the last-mile routing between PE & CE devices. BGP & EGP can run on top of OSPF. I came across this *article* <https://routingfreak.wordpress.com/2011/03/05/why-providers-still-prefer-is-is-over-ospf-when-designing-large-flat-topologies/> when scrolling the web a while back and I still want to find out if am the only one who thinks its a matter of choice between the two. Although there isn't distinct 1:1 argument, it's good we discuss it here and figure out why one prefer one over the other *(consider a huge flat network)**.* What say you ladies and gentlemen?
I've given a talk about this a couple of times since 2008. But our reasons are to choosing IS-IS are: * No requirement to home everything back to Area 0 (Virtual Links are evil). * Integrated IPv4/IPv6 protocol support in a single IGP implementation. * Single level (L2) deployment at scale. * Scalable TLV structure vs. Options structure for OSPFv2. OSPFv3 employs a TLV structure, however. * Inherent scaling features, e.g., iSPF, PRC, e.t.c. Some of these may not be available on all vendor implementations. If you're interested in reviewing the talk I gave on this, a lot more details is in there at: http://www.apricot.net/apricot2009/images/lecture_files/isis_deployment.pdf Ultimately, router CPU's are way faster now, and I could see a case for running a single-area OSPFv2. So I'd likely not be religious about forcing you down the IS-IS path. Mark.
This generally supports my own view that it depends on the topology and the real or potential scale/scope. In my experience, IS-IS is just all around better in a flat, highly interconnected environment such as an ISP or other broadly scaled network. If you have a very (almost exclusively) heirarchical structure and pretty good control over IP addressing and can use summarization effectively, then OSPF can make your core networking much simpler. On a small network that doesn't look to grow at leaps and bounds, I'd favor OSPF. On a large, complex network or a network that has the potential to grow without any sort of predefined structure (ie, more demand based), then IS-IS is probably your win. Note that this doesn't factor in multiple IS-IS levels, something I don't have a great deal of experience with. Mostly, networks I've been associated with just run one great big, gigantic level 0, though they did also experiment with other configurations. -Wayne On Thu, Nov 10, 2016 at 07:59:12AM +0200, Mark Tinka wrote:
On 9/Nov/16 19:12, Michael Bullut wrote:
Greetings Team,
???While I haven't worked with IS-IS before but the only disadvantage I've encountered with OSPF is that it is resource intensive on the router it is running on which is why only one instance runs on any PE & P device on an ISP network. OSPF is pretty good in handling the core network routing while BGP & EGP handle the last-mile routing between PE & CE devices. BGP & EGP can run on top of OSPF. I came across this *article* <https://routingfreak.wordpress.com/2011/03/05/why-providers-still-prefer-is-is-over-ospf-when-designing-large-flat-topologies/> when scrolling the web a while back and I still want to find out if am the only one who thinks its a matter of choice between the two. Although there isn't distinct 1:1 argument, it's good we discuss it here and figure out why one prefer one over the other *(consider a huge flat network)**.* What say you ladies and gentlemen?
I've given a talk about this a couple of times since 2008. But our reasons are to choosing IS-IS are:
* No requirement to home everything back to Area 0 (Virtual Links are evil).
* Integrated IPv4/IPv6 protocol support in a single IGP implementation.
* Single level (L2) deployment at scale.
* Scalable TLV structure vs. Options structure for OSPFv2. OSPFv3 employs a TLV structure, however.
* Inherent scaling features, e.g., iSPF, PRC, e.t.c. Some of these may not be available on all vendor implementations.
If you're interested in reviewing the talk I gave on this, a lot more details is in there at:
http://www.apricot.net/apricot2009/images/lecture_files/isis_deployment.pdf
Ultimately, router CPU's are way faster now, and I could see a case for running a single-area OSPFv2. So I'd likely not be religious about forcing you down the IS-IS path.
Mark.
--- Wayne Bouchard web@typo.org Network Dude http://www.typo.org/~web/
On 10/Nov/16 08:41, Wayne Bouchard wrote:
This generally supports my own view that it depends on the topology and the real or potential scale/scope. In my experience, IS-IS is just all around better in a flat, highly interconnected environment such as an ISP or other broadly scaled network. If you have a very (almost exclusively) heirarchical structure and pretty good control over IP addressing and can use summarization effectively, then OSPF can make your core networking much simpler. On a small network that doesn't look to grow at leaps and bounds, I'd favor OSPF. On a large, complex network or a network that has the potential to grow without any sort of predefined structure (ie, more demand based), then IS-IS is probably your win.
I wouldn't base the choice necessarily on the size of the network, although from experience, I'd always choose IS-IS for a large, geographically-dispersed network. What I mean to say is that I'd be happy running IS-IS on a tiny network, as much as I'd run route reflectors in a 3-router network. There isn't that much more effort to get it going compared to considering whether a Mini or a dump truck should be used to take the kids to school every morning.
Note that this doesn't factor in multiple IS-IS levels, something I don't have a great deal of experience with. Mostly, networks I've been associated with just run one great big, gigantic level 0, though they did also experiment with other configurations.
I've run multi-level IS-IS before. To be honest, I'd not recommend it. There are enough features and knobs in IS-IS to quiet the chatter associated with a single-level IS-IS deployment. Running multi-level IS-IS means you need to plan your L1/L2 intersections, figure out what to do with the ATT Bit and look at Route Leaking if you run MPLS (LDP hates route summarization). Needless to say, the Area ID of the NET is more significant in L1/L2 IS-IS than in L2-only IS-IS, as this is what is used to control LSP exchange between levels. This can get very complicated very fast in very large networks. Yep, that's 3 "very's". It's 2016, and any decent router has something-x86 going for it (or at the very least, a reasonably quick non-x86 going for it). I'd stick to single-level IS-IS. Which means L2-only, not L1-only - I know a network :-). My only real issue with IS-IS is the ST and MT (Single Topology and Multi-Topology) nuisance re: IPv6. Many vendors implement ST on turn-up, meaning you need to manually configure the MT knob. This can be painful when you haven't been clued up on MT, run an IPv4-only network and need to enable IPv6. I've gone into a bit of detail on this in my talk that I included in a previous post. Mark.
On 10/Nov/16 11:03, Randy Bush wrote:
as painful as ospf
If I did run OSPF, I'd probably do it with a single area, likely OSPFv3 with IPv4 address family support. Kinky, but it is 2016...
in a research rack with more than one router, i run is-is.
Good man :-)... Mark.
On 10 November 2016 at 05:59, Mark Tinka <mark.tinka@seacom.mu> wrote:
On 9/Nov/16 19:12, Michael Bullut wrote:
Greetings Team,
While I haven't worked with IS-IS before but the only disadvantage I've encountered with OSPF is that it is resource intensive on the router it is running on which is why only one instance runs on any PE & P device on an ISP network. OSPF is pretty good in handling the core network routing while BGP & EGP handle the last-mile routing between PE & CE devices. BGP & EGP can run on top of OSPF. I came across this *article* <https://routingfreak.wordpress.com/2011/03/05/why-providers-still-prefer-is-is-over-ospf-when-designing-large-flat-topologies/> when scrolling the web a while back and I still want to find out if am the only one who thinks its a matter of choice between the two. Although there isn't distinct 1:1 argument, it's good we discuss it here and figure out why one prefer one over the other *(consider a huge flat network)**.* What say you ladies and gentlemen?
I've given a talk about this a couple of times since 2008. But our reasons are to choosing IS-IS are:
I don't think there is much of a debate to be had any more, the gap between them is so small now (OSPFv3 and ISIS that is, no one would deploy OSPFv2 now in greenfield right?):
* No requirement to home everything back to Area 0 (Virtual Links are evil).
This is a good point I think.
* Integrated IPv4/IPv6 protocol support in a single IGP implementation.
This is in OSPv3.
* Single level (L2) deployment at scale.
Single area 0 deployment at scale? Bit of a moot point unless you compare a specific device model and specific code version in two identical deployments, its not much to do with the protocol but the vendor implementation and the brute force.
* Scalable TLV structure vs. Options structure for OSPFv2. OSPFv3 employs a TLV structure, however.
OSPv3 has this.
* Inherent scaling features, e.g., iSPF, PRC, e.t.c. Some of these may not be available on all vendor implementations.
OSPF has these too.
Ultimately, router CPU's are way faster now, and I could see a case for running a single-area OSPFv2. So I'd likely not be religious about forcing you down the IS-IS path.
Yeah this ^ I don't think there is a stronge case for either protocol. Somenoe mentioned the AOL NANOG talk about migrating from OSPF to ISIS. There was a NANOG talk recently-ish about someone migrating from OSPF to BGP. There wasn't even a need for an IGP, BGP scalled better for them (in the DC). BGP these days supports PIC and BFD etc, how much longer to IGPs have? :) James.
On 10/Nov/16 12:54, Zbyněk Pospíchal wrote:
In theory, yes. In the real world operators need MPLS label distribution, which is still not supported in many implementations.
But dual-stack protocol support in the IGP has nothing to do with MPLS. Now, if you're talking about LDPv6 or SR, then... Mark.
On 10/Nov/16 12:17, James Bensley wrote:
I don't think there is much of a debate to be had any more, the gap between them is so small now (OSPFv3 and ISIS that is, no one would deploy OSPFv2 now in greenfield right?):
Most networks that I know are greenfielding an IGP will deploy both OSPFv2 and OSPFv3. Worst case, just OSPFv2.
This is in OSPv3.
Right, but if a network does not yet want to run IPv6 (2016, anyone), then this becomes an issue as IPv6 NLRI is carried over the IPv6 transport. This could also come down to implementation. I looked at this for the first time back in Junos 9.0 (when it was still an IETF draft), and no other vendor had it yet. It has since matured and I know both Juniper and Cisco have decent code. I can't speak for other vendors, particularly if you multi-vendor.
Single area 0 deployment at scale? Bit of a moot point unless you compare a specific device model and specific code version in two identical deployments, its not much to do with the protocol but the vendor implementation and the brute force.
Like I said to Randy, if I did deploy OSPF ever (quite unlikely), there is enough CPU in today's router to, I think, run a single Area 0 for the whole thing.
OSPv3 has this.
Yep, as I did mention.
OSPF has these too.
More of them in OSPFv3 than OSPFv2. But then again, vendor-specific knobs can be had here for cheap.
Yeah this ^ I don't think there is a stronge case for either protocol.
Somenoe mentioned the AOL NANOG talk about migrating from OSPF to ISIS. There was a NANOG talk recently-ish about someone migrating from OSPF to BGP. There wasn't even a need for an IGP, BGP scalled better for them (in the DC).
BGP these days supports PIC and BFD etc, how much longer to IGPs have? :)
Sounds like you're talking about BGP-LS. If you are, then BGP-LS still requires an IGP. It's just that the IGP has a much more micro view of the network, while BGP-LS is tasked with the macro side of things. Mark.
participants (18)
-
Baldur Norddahl
-
Charles van Niman
-
David Barak
-
David Bass
-
Florian Weimer
-
James Bensley
-
Josh Reynolds
-
Mark Tinka
-
Michael Bullut
-
Michael Hallgren
-
Nick Hilliard
-
Randy Bush
-
RT Parrish
-
sthaug@nethelp.no
-
Tim Jackson
-
Valdis.Kletnieks@vt.edu
-
Wayne Bouchard
-
Zbyněk Pospíchal