Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
On 20/Jun/20 19:58, Gert Doering wrote: > The 6880/6840 products were promising at that time, but the pricing made > it uninteresting. So we kept our 6506Es for a time... We haven't done anything with them since we bought and deployed them in 2014. They are serving their purpose quite well, and when it's time for them to go, the Arista kicks. > ... and then went to Arista 7050SX2/SX3 for the "edge things" (small > routing table, lots of 10G/25G ports, small power draw, EVPN/VXLAN). > > Nice stuff like the JSON RPC API, which is nice to work with and > amazingly *fast* (compared to JunOS commit times...). And, most important, > a good TAC and a company interested in listening to their customers. We run the 7508E for core switching in large PoP's, and the 7280R for data centre access aggregation in all PoP's (this replaced our Juniper EX4550 and EX4600 platforms). We are very happy - but these are pure Layer 2 switching use-cases. > I'm a bit annoyed that the 7050SX* do not have MPLS-P support (because > we have MPLS PEs that basically "live behind" the 7050SX, and now need > to have vlans *through* them, to reach a MPLS P router). > > I do understand that the BRCM Trident is fairly limited wrt MPLS handling, > so Arista decided "better no MPLS than something which is not enough > for people" - unfortunately for us, because we only want "LDP and > single-label swap/pop", but I can accept the technical arguments to > some extent. You know how I feel about Broadcom chips :-). If Arista aren't that comfortable about them, you'd do well to take them at their word, hehe. > (As a side note, changing our network from EIGRP to OSPF for IPv4 did > not come for free, so I would have much preferred to stay in my self- > chosen vendor lock-in with Cisco. But Cisco has gone insane these days, > and new boxes like the NCS5500 come *without* EIGRP support. So they > really do not want us customers locked in...) Looking at things, it's probably cheaper for you to spend money on getting an open IGP than spending money dealing with the indecision Cisco sometimes goes through. Mark. signature.asc Description: OpenPGP digital signature
Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
On 19/Jun/20 20:19, ljwob...@gmail.com wrote: > >From the vendor standpoint, the market has never been able to agree on what > >makes a "core" application. If I have five "big" customers, I guarantee you > >that: > - one of them will need really big ACLs, even though it's a "core" box to > them. > - one of them will want to terminate high speed L2VPN circuits, even though > it's a "core" box. > - one of them will need to do hierarchical shaping and granular QoS, even > though it's a "core" box. > - one of them will want to have lots of headroom in the FIB (2-3x today's > global tables) ... even though it's a "core" box. > - one of them will want to buy something that they can "migrate out to the > edge" one day... > > Say it with me: "even though it's a "core" box" > > This puts me (as the vendor) in a super weird spot... I can try to create a > card/PID that addresses *some subset* of this, charge a lot less for it, and > hopefully sell a bunch. Or I'm left creating something that I can sell into > that broader market, but then that thing has to "do all the stuff" and I'm > going to charge for it appropriately. > > The physics dictate that "Really High Speed Silicon" does not exist which can > solve all of those things. I can solve SOME with a given chip design, but > not all. Well, if I'm honest, it's the vendors who created "tiers" back in the day, so they can sell boxes in the way they did, and still do. Ever since Ethernet became the gold standard, what a core, edge, peering, branch, e.t.c., box is has been meaningless. It was meaningless before Ethernet (I mean, to some, the Cisco 3640 was a core router, while to others it was a peering router), but it's more meaningless in the days of Ethernet. The reason the ASR9000 sells better than the CRS or NCS 6000, is the same reason the MX sells better than the PTX or T-series. It's all about Ethernet. So now, vendors who are able to build boxes that can license Ethernet ports will be the winners, because I don't have to pay the upfront capex for the entire card, and can just grow as I need. The Transport boys have been doing it for so long, why can't the IP boys do the same? The good news is, they have started. Secondly, and perhaps more importantly, if vendors can build around a single ASIC across a multitude of platforms, then there is hope. If you have to build a different ASIC for every tier of a network, you end up with the issues you raise, above. The reason the MX does so well is because in addition to being an Ethernet platform, it uses the same ASIC (since Trio, to be clear), which gives Juniper and its customers plenty of flexibility across a variety of applications. There is a lesson, here, to be learned. Mark.
Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
On 19/Jun/20 17:26, Gert Doering wrote: > There's a special place in hell for people re-using the "Catalyst" brand > name and then putting yearly renewable licenses on it. Or IOS XE. > > I'm not actually sure *which* BU is doing "Catalyst" these days, but > we're so annoyed about Cisco these days that I haven't really looked at > all these new and shiny products from all these new and shiny BUs with > all these new and shiny operating systems in quite a while. We bought the C6880-X for our core switch back in 2014. It's still humming, running plain old IOS. The upgrade path is Arista for this. I'm not sure what switching is doing over at Cisco, these days. Mark. signature.asc Description: OpenPGP digital signature
Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
> > On Jun 19, 2020, at 08:06, Mark Tinka 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.*)
Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
> Maybe this is fundamental and unavoidable, maybe some systematic bias > in human thinking drives us towards simple software and complex > hardware. how has software progressed in the last 50-70 years as compared to hardware? my watch has how many orders of magnitude of compute vs the computer which took a large room when i was but a youth? and we have barely avoided writing stacks in cobol; but we're close, assembler++. randy
Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
On Fri, Jun 19, 2020 at 10:34 AM Mark Tinka 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:>
Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
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.
Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
On Fri, Jun 19, 2020 at 9:05 AM Mark Tinka 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:>
Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
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.
Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
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.
Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
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 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 > wrote: > > > -- Forwarded message -- > From: Benny Lyne Amorsen > To: cisco-...@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 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 > > To: cisco-...@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:>
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-...@puck.nether.net> wrote: > >> >> >> -- Forwarded message -- >> From: Benny Lyne Amorsen >> To: cisco-...@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 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 >> To: cisco-...@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-...@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-...@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > .
Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
On Fri, 19 Jun 2020 at 14:26, Mark Tinka wrote: > > ASR9k also has low and high scale cards, we buy the low scale, even > > for edge. But even low scale is pretty high scale in this context. > > You're probably referring to the TR vs. SE line cards, yes? I do, correct. -- ++ytti
Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
On 19/Jun/20 13:11, Saku Ytti wrote: > ASR9k also has low and high scale cards, we buy the low scale, even > for edge. But even low scale is pretty high scale in this context. You're probably referring to the TR vs. SE line cards, yes? We would also buy TR line cards for high-touch use-cases, because, as you say, that is pretty high scale as well, already :-). I think the SE line cards are meant for high-capacity BNG terminations in a single chassis, per line card. But with most IP traffic a network is carrying being best-effort and capacity available all over the place, what's the point anymore? > > I think there would be market for on-chip only LSR/core cards. > Ultimately if you design for that day1, it won't add lot of costs to > you. Yes the BOM difference may not be that great, because ultimately > silicon is cheap and costs are in NRE. But the on-chip only cards > would have bit more ports and they'd have better availability due to > less component failures. > I would fight very hard for us buy such cards in core, if vendor would > offer them. Same here. For now, we are exploring the PTX1000/10002 machinery. I know fixed form factor boxes for a core are a bit strange, but looking at how far the tech has come, I'm feeling a lot more bullish about having a core box that isn't redundant in control planes, data planes, and all the rest. Just power supplies :-). A lot of money to be saved if the idea works. > Like the trio-in-pci full open, I think this is just marketing > failure. Vendors are wearing their DC glasses and don't see anything > else. While the big-name DC are lost cause, AMZN employs more chip > designers than JNPR, matter of time before JNPR loses amzn edge too to > internal amzn product. > > Someone with bit bolder vision on what the market could be, may have > real opportunity here. This is what I've been telling the vendors since about 2017, both IP and Transport. It's only a matter of time before the level of development happening in the cloud + content houses far surpasses what the vendors are doing, if not already. Why spend all your time, energy and resources on a market that isn't going to find use for your NRE, and can probably out-code and out-research you with one hand tied behind their back, any day? The only reason they aren't building their own core routers yet is because that's an area where they can still afford to offload development time to the vendors. The edge is where they need to badly optimize, and they will do it a lot more efficiently than the vendors can, in time, if not already. When I saw one cloud provider present their idea on collapsing an entire DWDM line card into an optic that they can code for and stick into a server, I saw the DWDM's vendor's hearts sink right across the table where I sat. This was 3 years ago. The vendors need, as you say, someone with a bold enough vision to pivot the tradition. Mark.
Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
On 19/Jun/20 10:40, Saku Ytti wrote: > Maybe this is fundamental and unavoidable, maybe some systematic bias > in human thinking drives us towards simple software and complex > hardware. > > Is there an alternative future, where we went with Itanium? Where we > have simple hardware and an increasingly complex compiler and > increasingly complex runtime making sure the program runs fast on that > simple hardware? > Instead we have two guys in tel aviv waking up in night terror every > night over confusion why does x86 run any code at all, how come it > works. And I'm at home 'hehe new intc make program go fast:)))' > > Now that we have comparatively simple compilers and often no runtime > at all, the hardware has to optimise the shitty program for us, but as > we don't get to see how the sausage is made, we think it's probably > something that is well done, robust and correct. If we'd do this in > software, we'd all have to suffer how fragile the compiler and runtime > are and how unapproachable they are. So this brings back a discussion you and I had last year about a scenario where the market shifts toward open vendor in-house silicon, sold as a PCI card one can stick in a server. Trio, ExpressPlus, Lightspeed, Silicon One, Cylon, QFP, e.t.c., with open specs. so that folk can code for them and see what happens. At the moment, everyone is coding for x86 as an NPU, and we know that path is not the cheapest or most efficient for packet forwarding. Vendors may feel a little skittish about "giving away" their IP, but I don't think it's an issue because: * The target market is folk currently coding for x86 CPU's to run as NPU's. * No one is about to run 100Gbps backbones on a PCI card. But hey, the world does surprise :-). * Writing code for forwarding traffic as well as control plane protocols is not easy. Buying a finished product from an equipment vendor will be the low-hanging fruit for most of the landscape. It potentially also has the positive side effect of getting Broadcom to raise their game, which would make them a more viable option for operators with significant high-touch requirements. As we used to say in Vladivostok, "It could be a win win" :-). Mark.
Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
On Fri, 19 Jun 2020 at 11:35, Mark Tinka wrote: > > So instead of making it easy for software to generate MPLS packets. We > > are making it easy for hardware teo generate complex IP packets. > > Bizarre, but somewhat rational if you start from compute looking out > > to networks, instead of starting from networks. > > Which I totally appreciate and, fundamentally, have nothing against. > > My concern is when we, service providers, start to get affected because > equipment manufacturers need to follow the data centre money hard, often > at our expense. This is not only in the IP world, but also in the > Transport world, where service providers are having to buy DWDM gear > formatted for DCI. Yes, it does work, but it's not without its > eccentricities. > > Cycling, over the past decade, between TRILL, OTV, SPB, FabricPath, > VXLAN, NV-GRE, ACI... and perhaps even EVPN, there is probably a lesson > to be learned. Maybe this is fundamental and unavoidable, maybe some systematic bias in human thinking drives us towards simple software and complex hardware. Is there an alternative future, where we went with Itanium? Where we have simple hardware and an increasingly complex compiler and increasingly complex runtime making sure the program runs fast on that simple hardware? Instead we have two guys in tel aviv waking up in night terror every night over confusion why does x86 run any code at all, how come it works. And I'm at home 'hehe new intc make program go fast:)))' Now that we have comparatively simple compilers and often no runtime at all, the hardware has to optimise the shitty program for us, but as we don't get to see how the sausage is made, we think it's probably something that is well done, robust and correct. If we'd do this in software, we'd all have to suffer how fragile the compiler and runtime are and how unapproachable they are. -- ++ytti
Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
On 19/Jun/20 10:18, Saku Ytti wrote: > I need to give a little bit of credit to DC people. If your world is > compute and you are looking out to networks. MPLS _is hard_, it's > _harder_ to generate MPLS packets in Linux than arbitrarily complex IP > stack. Now instead of fixing that on the OS stack, to have a great > ecosystem on software to deal with MPLS, which is easy to fix, we are > fixing that in silicon, which is hard and expensive to fix. > > So instead of making it easy for software to generate MPLS packets. We > are making it easy for hardware teo generate complex IP packets. > Bizarre, but somewhat rational if you start from compute looking out > to networks, instead of starting from networks. Which I totally appreciate and, fundamentally, have nothing against. My concern is when we, service providers, start to get affected because equipment manufacturers need to follow the data centre money hard, often at our expense. This is not only in the IP world, but also in the Transport world, where service providers are having to buy DWDM gear formatted for DCI. Yes, it does work, but it's not without its eccentricities. Cycling, over the past decade, between TRILL, OTV, SPB, FabricPath, VXLAN, NV-GRE, ACI... and perhaps even EVPN, there is probably a lesson to be learned. Mark.
Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
On Fri, 19 Jun 2020 at 11:03, Mark Tinka wrote: > MPLS has been around far too long, and if you post web site content > still talking about it or show up at conferences still talking about it, > you fear that you can't sell more boxes and line cards on the back of > "just" broadening carriage pipes. > > So we need to invent a new toy around which we can wrap a story about > "adding value to your network" to "drive new business" and "reduce > operating costs", to entice money to leave wallets, when all that's > really still happening is the selling of more boxes and line cards, so > that we can continue to broaden carriage pipes. I need to give a little bit of credit to DC people. If your world is compute and you are looking out to networks. MPLS _is hard_, it's _harder_ to generate MPLS packets in Linux than arbitrarily complex IP stack. Now instead of fixing that on the OS stack, to have a great ecosystem on software to deal with MPLS, which is easy to fix, we are fixing that in silicon, which is hard and expensive to fix. So instead of making it easy for software to generate MPLS packets. We are making it easy for hardware teo generate complex IP packets. Bizarre, but somewhat rational if you start from compute looking out to networks, instead of starting from networks. > > There are very few things that have been designed well from scratch, and > stand the test of time regardless of how much wind is thrown at them. > MPLS is one of those things, IMHO. Nearly 20 years to the day since > inception, and I still can't find another packet forwarding technology > that remains as relevant and versatile as it is simple. > > Mark. > -- ++ytti
Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
On 19/Jun/20 09:32, Saku Ytti wrote: > We need to decide if we are discussing a specific market situation or > fundamentals. Ideally we'd drive the market to what is fundamentally > most efficient, so that we pay the least amount of the kit that we > use. If we drive SRv6, we drive cost up, if we drive MPLS, we drive > cost down. > > Even today in many cases you can take a cheap L2 chip, and make it an > MPLS switch, due to them supporting VLAN swap! Which has no clue of > IPV6 or IPV4. We need a new toy. MPLS has been around far too long, and if you post web site content still talking about it or show up at conferences still talking about it, you fear that you can't sell more boxes and line cards on the back of "just" broadening carriage pipes. So we need to invent a new toy around which we can wrap a story about "adding value to your network" to "drive new business" and "reduce operating costs", to entice money to leave wallets, when all that's really still happening is the selling of more boxes and line cards, so that we can continue to broaden carriage pipes. There are very few things that have been designed well from scratch, and stand the test of time regardless of how much wind is thrown at them. MPLS is one of those things, IMHO. Nearly 20 years to the day since inception, and I still can't find another packet forwarding technology that remains as relevant and versatile as it is simple. Mark.
Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
On 18/Jun/20 02:32, Phil Bedard wrote: > I look at the basic SR via IGP extensions like VPLS vs. EVPN. If we had a > way to go back in history I'm not sure anyone would have said VPLS was a good > idea vs. EVPN. > > There were reasons back in the day why something like SR wasn't done. The > thought of global MPLS labels scared people and source routing was also evil. > So LDP was created to distribute labels hop by hop, while still relying 100% > on the IGP to do so. It kind of defies common sense when you look at it now, > but there were supposedly good reasons for it back then. > > SR-MPLS on an existing device supporting MPLS forwarding is a control-plane > change, meaning almost any device could support SR-MPLS. > > SR is meant to be data plane agnostic, the SID is just an identifier. Most > support MPLS, some support IPv6. Fair enough. There's still a whole IGP mess to sort out though, not to mention many years of field experience to bake in. Mark.
