Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
I think it's less about just the forwarding chips and more about an entire solution that someone can go and buy without having to fiddle with it. You remember the saying, "Gone are the days when men were men and wrote their own drivers"? Well, running a network is a full-time job, without having to learn how to code for hardware and protocols. There are many start-ups that are working off of commodity chips and commodity face plates. Building software for those disparate hardware systems, and then developing the software so that it can be used in commercial deployments is non-trivial. That is the leverage Cisco, Juniper, Nokia... even Huawei, have, and they won't let us forget it. Then again, if one's vision is bold enough, they could play the long game, start now, patiently build, and then come at us in 8 or so years. Because the market, surely, can't continue at the rate we are currently going. Everything else around us is dropping in price and revenue, and yet traditional routing and switching equipment continues to stay the same, if not increase. That's broken!` Mark. On 19/Jun/20 13:25, Robert Raszuk wrote:
But talking about commodity isn't this mainly Broadcom ? And is there single chip there which does not support line rate IP ? Or is there any chip which supports MPLS and cost less then IP/MPLS one ?
On Fri, Jun 19, 2020 at 1:22 PM Benny Lyne Amorsen via cisco-nsp < cisco-nsp@puck.nether.net> wrote:
---------- Forwarded message ---------- From: Benny Lyne Amorsen <benny+usenet@amorsen.dk> To: cisco-nsp@puck.nether.net Cc: Bcc: Date: Fri, 19 Jun 2020 13:12:06 +0200 Subject: Re: [c-nsp] Devil's Advocate - Segment Routing, Why? Saku Ytti <saku@ytti.fi> writes:
This is simply not fundamentally true, it may be true due to market perversion. But give student homework to design label switching chip and IPv6 switching chip, and you'll use less silicon for the label switching chip. And of course you spend less overhead on the tunnel. What you say is obviously true.
However, no one AFAIK makes an MPLS switch at prices comparable to basic layer 3 IPv6 switches. You can argue that it is a market failure as much as you want, but I can only buy what is on the market. According to the market, MPLS is strictly Service Provider, with the accompanying Service Provider markup (and then ridiculous discounts to make the prices seem reasonable). Enterprise and datacenter are not generally using MPLS, and I can only look on in envy at the prices of their equipment.
There is room for a startup to rethink the service provider market by using commodity enterprise equipment. Right now that means dumping MPLS, since that is only available (if at all) at the most expensive license level. Meanwhile you can get get low-scale BGPv6 and line-speed GRE with commodity hardware without extra licenses.
I am not saying that it will be easy to manage such a network, the tooling for MPLS is vastly superior. I am merely saying that with just a simple IPv6-to-the-edge network you can deliver similar services to an MPLS-to-the-edge network at lower cost, if you can figure out how to build the tooling.
Per-packet overhead is hefty. Is that a problem today?
---------- Forwarded message ---------- From: Benny Lyne Amorsen via cisco-nsp <cisco-nsp@puck.nether.net> To: cisco-nsp@puck.nether.net Cc: Bcc: Date: Fri, 19 Jun 2020 13:12:06 +0200 Subject: Re: [c-nsp] Devil's Advocate - Segment Routing, Why? _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ .
If y'all can deal with the BU, the Cat9k family is looking half-decent: MPLS PE/P, BGP L3VPN, BGP EVPN (VXLAN dataplane not MPLS) etc. UADP programmable pipeline ASIC, FIB ~200k, E-LLW, mandatory DNA license now covers software support... Of course you do have to deal with a BU that lives in a parallel universe (SDA, LISP, NEAT etc) - but the hardware is the right price-perf, and IOS-XE is tolerable. No large FIB today, but Cisco appears to be headed towards "Silicon One" for all of their platforms: RTC ASIC strapped over some HBM. The strategy is interesting: sell it as a chip, sell it whitebox, sell it fully packaged. YMMV On Fri, Jun 19, 2020 at 7:40 AM Mark Tinka <mark.tinka@seacom.mu> wrote:
I think it's less about just the forwarding chips and more about an entire solution that someone can go and buy without having to fiddle with it.
You remember the saying, "Gone are the days when men were men and wrote their own drivers"? Well, running a network is a full-time job, without having to learn how to code for hardware and protocols.
There are many start-ups that are working off of commodity chips and commodity face plates. Building software for those disparate hardware systems, and then developing the software so that it can be used in commercial deployments is non-trivial. That is the leverage Cisco, Juniper, Nokia... even Huawei, have, and they won't let us forget it.
Then again, if one's vision is bold enough, they could play the long game, start now, patiently build, and then come at us in 8 or so years. Because the market, surely, can't continue at the rate we are currently going. Everything else around us is dropping in price and revenue, and yet traditional routing and switching equipment continues to stay the same, if not increase. That's broken!`
Mark.
On 19/Jun/20 13:25, Robert Raszuk wrote:
But talking about commodity isn't this mainly Broadcom ? And is there single chip there which does not support line rate IP ? Or is there any chip which supports MPLS and cost less then IP/MPLS one ?
On Fri, Jun 19, 2020 at 1:22 PM Benny Lyne Amorsen via cisco-nsp <cisco-nsp@puck.nether.net> wrote:
---------- Forwarded message ---------- From: Benny Lyne Amorsen <benny+usenet@amorsen.dk> <benny+usenet@amorsen.dk> To: cisco-nsp@puck.nether.net Cc: Bcc: Date: Fri, 19 Jun 2020 13:12:06 +0200 Subject: Re: [c-nsp] Devil's Advocate - Segment Routing, Why? Saku Ytti <saku@ytti.fi> <saku@ytti.fi> writes:
This is simply not fundamentally true, it may be true due to market perversion. But give student homework to design label switching chip and IPv6 switching chip, and you'll use less silicon for the label switching chip. And of course you spend less overhead on the tunnel.
What you say is obviously true.
However, no one AFAIK makes an MPLS switch at prices comparable to basic layer 3 IPv6 switches. You can argue that it is a market failure as much as you want, but I can only buy what is on the market. According to the market, MPLS is strictly Service Provider, with the accompanying Service Provider markup (and then ridiculous discounts to make the prices seem reasonable). Enterprise and datacenter are not generally using MPLS, and I can only look on in envy at the prices of their equipment.
There is room for a startup to rethink the service provider market by using commodity enterprise equipment. Right now that means dumping MPLS, since that is only available (if at all) at the most expensive license level. Meanwhile you can get get low-scale BGPv6 and line-speed GRE with commodity hardware without extra licenses.
I am not saying that it will be easy to manage such a network, the tooling for MPLS is vastly superior. I am merely saying that with just a simple IPv6-to-the-edge network you can deliver similar services to an MPLS-to-the-edge network at lower cost, if you can figure out how to build the tooling.
Per-packet overhead is hefty. Is that a problem today?
---------- Forwarded message ---------- From: Benny Lyne Amorsen via cisco-nsp <cisco-nsp@puck.nether.net> <cisco-nsp@puck.nether.net> To: cisco-nsp@puck.nether.net Cc: Bcc: Date: Fri, 19 Jun 2020 13:12:06 +0200 Subject: Re: [c-nsp] Devil's Advocate - Segment Routing, Why? _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.nethttps://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.nethttps://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ .
-- Tim:>
On 19/Jun/20 14:50, Tim Durack wrote:
If y'all can deal with the BU, the Cat9k family is looking half-decent: MPLS PE/P, BGP L3VPN, BGP EVPN (VXLAN dataplane not MPLS) etc. UADP programmable pipeline ASIC, FIB ~200k, E-LLW, mandatory DNA license now covers software support...
Of course you do have to deal with a BU that lives in a parallel universe (SDA, LISP, NEAT etc) - but the hardware is the right price-perf, and IOS-XE is tolerable.
No large FIB today, but Cisco appears to be headed towards "Silicon One" for all of their platforms: RTC ASIC strapped over some HBM. The strategy is interesting: sell it as a chip, sell it whitebox, sell it fully packaged.
YMMV
I'd like to hear what Gert thinks, though. I'm sure he has a special place for the word "Catalyst" :-). Oddly, if Silicon One is Cisco's future, that means IOS XE may be headed for the guillotine, in which case investing any further into an IOS XE platform could be dicey at best, egg-face at worst. I could be wrong... Mark.
On Jun 19, 2020, at 08:06, Mark Tinka <mark.tinka@seacom.mu> wrote:
On 19/Jun/20 14:50, Tim Durack wrote:
If y'all can deal with the BU, the Cat9k family is looking half-decent: MPLS PE/P, BGP L3VPN, BGP EVPN (VXLAN dataplane not MPLS) etc. UADP programmable pipeline ASIC, FIB ~200k, E-LLW, mandatory DNA license now covers software support...
Of course you do have to deal with a BU that lives in a parallel universe (SDA, LISP, NEAT etc) - but the hardware is the right price-perf, and IOS-XE is tolerable.
No large FIB today, but Cisco appears to be headed towards "Silicon One" for all of their platforms: RTC ASIC strapped over some HBM. The strategy is interesting: sell it as a chip, sell it whitebox, sell it fully packaged.
YMMV
I'd like to hear what Gert thinks, though. I'm sure he has a special place for the word "Catalyst" :-).
Oddly, if Silicon One is Cisco's future, that means IOS XE may be headed for the guillotine, in which case investing any further into an IOS XE platform could be dicey at best, egg-face at worst.
I could be wrong...
never underestimate the desire of product managers and engineering teams to have their own petri dishes to swim around in. -- steve ulrich (sulrich@botwerks.*)
On 19/Jun/20 15:24, steve ulrich wrote:
never underestimate the desire of product managers and engineering teams to have their own petri dishes to swim around in.
Probably what got us (and keeps getting us) into this mess to begin with. Mark.
On Fri, Jun 19, 2020 at 9:05 AM Mark Tinka <mark.tinka@seacom.mu> wrote:
On 19/Jun/20 14:50, Tim Durack wrote:
If y'all can deal with the BU, the Cat9k family is looking half-decent: MPLS PE/P, BGP L3VPN, BGP EVPN (VXLAN dataplane not MPLS) etc. UADP programmable pipeline ASIC, FIB ~200k, E-LLW, mandatory DNA license now covers software support...
Of course you do have to deal with a BU that lives in a parallel universe (SDA, LISP, NEAT etc) - but the hardware is the right price-perf, and IOS-XE is tolerable.
No large FIB today, but Cisco appears to be headed towards "Silicon One" for all of their platforms: RTC ASIC strapped over some HBM. The strategy is interesting: sell it as a chip, sell it whitebox, sell it fully packaged.
YMMV
I'd like to hear what Gert thinks, though. I'm sure he has a special place for the word "Catalyst" :-).
Oddly, if Silicon One is Cisco's future, that means IOS XE may be headed for the guillotine, in which case investing any further into an IOS XE platform could be dicey at best, egg-face at worst.
I could be wrong...
Mark.
It could be worse: Nexus ;-( There is another version of the future: 1. SP "Silicon One" IOS-XR 2. Enterprise "Silicon One" IOS-XE Same hardware, different software, features, licensing model etc. Silicon One looks like an interesting strategy: single ASIC for fixed, modular, fabric. Replace multiple internal and external ASIC family, compete with merchant, whitebox, MSDC etc. The Cisco 8000/8200 is not branded as NCS, which is BCM. I asked the NCS5/55k guys why they didn't use UADP. No good answer, although I suspect some big customer(s) were demanding BCM for their own programming needs. Maybe there were some memory bandwidth issues with UADP, which is what Q100 HBM is the answer for. -- Tim:>
On 19/Jun/20 16:09, Tim Durack wrote:
It could be worse: Nexus ;-(
There is another version of the future:
1. SP "Silicon One" IOS-XR 2. Enterprise "Silicon One" IOS-XE
Same hardware, different software, features, licensing model etc.
All this forking weakens a vendor's position in some respects, because when BU's are presenting one company as 6,000 ones, it's difficult for buying consistency. Options are great, but when options have options, it starts to get ugly, quick. Ah well...
Silicon One looks like an interesting strategy: single ASIC for fixed, modular, fabric. Replace multiple internal and external ASIC family, compete with merchant, whitebox, MSDC etc.
That is the hope. We've been to the cinema for this one before, though. Quite a few times. So I'm not holding my breath.
The Cisco 8000/8200 is not branded as NCS, which is BCM.
Not all of it - remember the big pink elephant in the room, the NCS 6000? That is/was nPower. Again, sending customers in all sorts of directions with that box, where now ASR9000 and the new 8000 seem to be the go-to box. Someone can't make up their mind over there.
I asked the NCS5/55k guys why they didn't use UADP. No good answer, although I suspect some big customer(s) were demanding BCM for their own programming needs. Maybe there were some memory bandwidth issues with UADP, which is what Q100 HBM is the answer for.
When you're building boxes for one or two customers, things like this tend to happen. But like I've been saying for some time, the big brands competing with the small brands over merchant silicon doesn't make sense. If you want merchant silicon to reduce cost, you're better off playing with the new brands that will charge less and be more flexible. While I do like IOS XR and Junos, paying a premium for them for a chip that will struggle the same way across all vendor implementations just doesn't track. Mark.
On Fri, Jun 19, 2020 at 10:34 AM Mark Tinka <mark.tinka@seacom.mu> wrote:
On 19/Jun/20 16:09, Tim Durack wrote:
It could be worse: Nexus ;-(
There is another version of the future:
1. SP "Silicon One" IOS-XR 2. Enterprise "Silicon One" IOS-XE
Same hardware, different software, features, licensing model etc.
All this forking weakens a vendor's position in some respects, because when BU's are presenting one company as 6,000 ones, it's difficult for buying consistency.
Options are great, but when options have options, it starts to get ugly, quick.
Ah well...
Silicon One looks like an interesting strategy: single ASIC for fixed, modular, fabric. Replace multiple internal and external ASIC family, compete with merchant, whitebox, MSDC etc.
That is the hope. We've been to the cinema for this one before, though. Quite a few times. So I'm not holding my breath.
The Cisco 8000/8200 is not branded as NCS, which is BCM.
Not all of it - remember the big pink elephant in the room, the NCS 6000? That is/was nPower. Again, sending customers in all sorts of directions with that box, where now ASR9000 and the new 8000 seem to be the go-to box. Someone can't make up their mind over there.
I asked the NCS5/55k guys why they didn't use UADP. No good answer, although I suspect some big customer(s) were demanding BCM for their own programming needs. Maybe there were some memory bandwidth issues with UADP, which is what Q100 HBM is the answer for.
When you're building boxes for one or two customers, things like this tend to happen.
But like I've been saying for some time, the big brands competing with the small brands over merchant silicon doesn't make sense. If you want merchant silicon to reduce cost, you're better off playing with the new brands that will charge less and be more flexible. While I do like IOS XR and Junos, paying a premium for them for a chip that will struggle the same way across all vendor implementations just doesn't track.
Mark.
Yes, for sure NCS6K was a completely different beast, much as NCS1K, NCS2K. Not sure why the NCS naming was adopted vs. ASR, and then dropped for 8000/8200. Probably lots of battles within the Cisco conglomerate. Not defending, just observing. Either way, networks got to get built, debugged, maintained, debugged, upgraded, debugged. All while improving performance, managing CAPEX, reducing OPEX. -- Tim:>
participants (3)
-
Mark Tinka -
steve ulrich -
Tim Durack