Re: [c-nsp] telemetry on IOS XE
Yes I did #sh run | inc netconf netconf-yang #show platform software yang-management process confd: Running nesd : Running syncfd : Running ncsshd : Running dmiauthd : Running nginx: Running ndbmand : Running pubd : Running gnmib: Not Running On Sat, Jun 20, 2020 at 12:02 AM Dave Bell wrote: > Have you enabled netconf-yang? > > On Fri, 19 Jun 2020 at 20:46, Robert Hass wrote: > >> Hi >> I'm trying to run telemetry on IOS XE (Catalyst 9300) but without lack. >> >> My config: >> >> test#sh run | sec tele >> telemetry ietf subscription 1 >> encoding encode-kvgpb >> filter xpath >> /process-cpu-ios-xe-oper:cpu-usage/cpu-utilization/five-seconds >> source-address 10.0.0.147 >> source-vrf Mgmt-vrf >> stream yang-push >> update-policy periodic 500 >> receiver ip address 10.0.3.16 12345 protocol grpc-tcp >> >> But it's not working: >> #show telemetry ietf subscription all >> The process for the command is not responding or is otherwise unavailable >> >> Any ideas ? >> >> Running IOS XE 17.02.01 >> >> Rob >> ___ >> 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/
Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
> > One of the advantages cited for SRv6 over MPLS is that the packet contains >> a record of where it has been. >> > Not really ... packets are not tourists in a bus. First there are real studies proving that most large production networks for the goal of good TE only need to place 1, 2 or 3 hops to traverse through. Rest is the shortest path between those hops. Then even if you place those node SIDs you have no control which interfaces are chosen as outbound. There is often more then one IGP ECMP path in between. You would need to insert adj. SIDs which does require pretty fine level of controller's capabilities to start with. I just hope that no one sane proposes that now all packets should get encapsulated in a new IPv6 header while entering a transit ISP network and carry long list of hop by hop adjacencies it is to travel by. Besides even if it would it would be valid only within given ASN and had no visibility outside. Thx, R. ___ 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/
Re: [c-nsp] telemetry on IOS XE
Have you enabled netconf-yang? On Fri, 19 Jun 2020 at 20:46, Robert Hass wrote: > Hi > I'm trying to run telemetry on IOS XE (Catalyst 9300) but without lack. > > My config: > > test#sh run | sec tele > telemetry ietf subscription 1 > encoding encode-kvgpb > filter xpath > /process-cpu-ios-xe-oper:cpu-usage/cpu-utilization/five-seconds > source-address 10.0.0.147 > source-vrf Mgmt-vrf > stream yang-push > update-policy periodic 500 > receiver ip address 10.0.3.16 12345 protocol grpc-tcp > > But it's not working: > #show telemetry ietf subscription all > The process for the command is not responding or is otherwise unavailable > > Any ideas ? > > Running IOS XE 17.02.01 > > Rob > ___ > 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/
[c-nsp] telemetry on IOS XE
Hi I'm trying to run telemetry on IOS XE (Catalyst 9300) but without lack. My config: test#sh run | sec tele telemetry ietf subscription 1 encoding encode-kvgpb filter xpath /process-cpu-ios-xe-oper:cpu-usage/cpu-utilization/five-seconds source-address 10.0.0.147 source-vrf Mgmt-vrf stream yang-push update-policy periodic 500 receiver ip address 10.0.3.16 12345 protocol grpc-tcp But it's not working: #show telemetry ietf subscription all The process for the command is not responding or is otherwise unavailable Any ideas ? Running IOS XE 17.02.01 Rob ___ 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/
Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
Hi, On Fri, Jun 19, 2020 at 03:05:50PM +0200, 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... [..] > > I'd like to hear what Gert thinks, though. I'm sure he has a special > place for the word "Catalyst" :-). 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. I've been told Merak is very nice... if all you're interested in is "sell to Enterprise customers and make lots of cash". gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ 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/
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:> ___ 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/
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. ___ 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/
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:> ___ 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/
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. ___ 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/
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.*) ___ 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/
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. ___ 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/
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-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 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-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:> ___ 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/
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 >> 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 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-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/ > . ___ 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/
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 ___ 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/
Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
On Fri, 19 Jun 2020 at 14:23, Benny Lyne Amorsen via cisco-nsp wrote: > Per-packet overhead is hefty. Is that a problem today? For us it is in DDoS scenario, we have customers whose product is to ingest DDoS and send clean out, so we need to deliver the bad traffic to them. With large per-packet overhead attacker gets huge leverage, as they inject pure IP, then we add overhead, and we need that overhead capacity everywhere to transport it. I'd say the fundamental metrics are a) tunnel must be LEM only on a small on-chip database b) tunnel header must be narrow c) tunnel header must be transistor cheap to parse (wattage, yield) d) all traffic in core must be tunneled -- ++ytti ___ 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/
Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
On 19/Jun/20 13:11, Robert Raszuk wrote: > > > For us, the PTX1000/10002 make absolute sense, and are options we are > > If you ever need some TE in your network just make sure it can run > SR-MPLS (segment endpoint functions) as it turns out that sweet spots > for flow engineering is very often in forcing it to traverse some > specific core boxes. In 2015, we had a customer that wanted EoMPLS services that simulated EoDWDM behaviour, i.e., if the path failed, don't automatically re-route, which is what LDP does by default. So, reluctantly, we built a bunch of RSVP-TE tunnels, but only because it was short-term, the money was great, and there was a migration path toward EoDWDM. As soon as they migrated, we ditched RSVP. All our network runs only on LDP. I can't stand RSVP :-). Granted, SR-TE is meant to be a lot more hassle-free than RSVP-TE was, but I still wouldn't do it, as I can throw bandwidth at the problem. At a previous job, we ran p2mp RSVP-TE to deliver IPTV Multicast in NG-MVPN infrastructure. We'd began testing our migration to p2mp mLDP, so we can dump RSVP, but then I had to bail and move on. Mark. ___ 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/
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. ___ 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/
Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
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 > 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 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-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/
Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
--- Begin Message --- 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? --- End Message --- ___ 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/
Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
On Fri, 19 Jun 2020 at 14:04, Mark Tinka wrote: > Even Cisco sort of went down this path with the CRS-3 when they - very > briefly - sold the so-called CRS LSP (Label Switch Processor) forwarding > engine: 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. 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. 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. -- ++ytti ___ 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/
Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
> For us, the PTX1000/10002 make absolute sense, and are options we are If you ever need some TE in your network just make sure it can run SR-MPLS (segment endpoint functions) as it turns out that sweet spots for flow engineering is very often in forcing it to traverse some specific core boxes. r. On Fri, Jun 19, 2020 at 1:04 PM Mark Tinka wrote: > > > On 19/Jun/20 12:29, Robert Raszuk wrote: > > Saku, > > > > What you are saying is technically true but not realistically important. > > > > Why - the answer is history of PTX. > > > > It was originally designed and architected on the very basis of hardware > > cost and performance when you would only need to switch at rates MPLS. > > > > Well real world showed that you can't sell such box and IP switching has > > been added to data plane there. > > > > Bottom line - I doubt you will find any vendor (from OEM to big ones) > which > > can afford to differentiate price wise boxes which would do line rate > MPLS > > and any thing less then line rate for IP. And as such IP clearly brings a > > lot of value for simplification of control plane and route aggregation > and > > IMHO is a good (well best) universal transport today for all types of > > services from WAN via Campus to DCs (or even MSDCs). > > I would agree to some extent. > > Even Cisco sort of went down this path with the CRS-3 when they - very > briefly - sold the so-called CRS LSP (Label Switch Processor) forwarding > engine: > > > > https://www.insight.com/en_US/shop/product/CRS-LSP/CISCO%20SYSTEMS/CRS-LSP/Cisco-CRS3-Label-Switch-Processor--control-processor/ > > The goal was a packet processor cheaper than both the MSC and FP data > planes that had been shipping at the time. The LSP card had reduced IP > and QoS scale, as the idea was that all the heavy-lifting would be done > in MPLS. > > But, as with the ASR14000 and ME2600X boxes, the LSP card didn't last > long. I guess Cisco figured the FP was a better option, as more and more > traffic started leaving VPN's for the cloud and CDN's. > > For us, the PTX1000/10002 make absolute sense, and are options we are > clearly looking at for fixed form factor core platforms as we seek > cheaper 100Gbps ports than we can currently get for the CRS (or even the > MX and ASR9000). > > For us, a low-scale IP services box or line card for the core is > something we are very interested in. We don't need rich IP services in > that area of the network, nor do we need rich MPLS services either. > Simple, low-scale IP/MPLS will do. > > But for data centre operators who may be anti-MPLS, the vendors will be > stuck between how they develop for them and how they develop for network > operators, for some time to come. > > Mark. > > ___ > 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/
Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
On 19/Jun/20 12:29, Robert Raszuk wrote: > Saku, > > What you are saying is technically true but not realistically important. > > Why - the answer is history of PTX. > > It was originally designed and architected on the very basis of hardware > cost and performance when you would only need to switch at rates MPLS. > > Well real world showed that you can't sell such box and IP switching has > been added to data plane there. > > Bottom line - I doubt you will find any vendor (from OEM to big ones) which > can afford to differentiate price wise boxes which would do line rate MPLS > and any thing less then line rate for IP. And as such IP clearly brings a > lot of value for simplification of control plane and route aggregation and > IMHO is a good (well best) universal transport today for all types of > services from WAN via Campus to DCs (or even MSDCs). I would agree to some extent. Even Cisco sort of went down this path with the CRS-3 when they - very briefly - sold the so-called CRS LSP (Label Switch Processor) forwarding engine: https://www.insight.com/en_US/shop/product/CRS-LSP/CISCO%20SYSTEMS/CRS-LSP/Cisco-CRS3-Label-Switch-Processor--control-processor/ The goal was a packet processor cheaper than both the MSC and FP data planes that had been shipping at the time. The LSP card had reduced IP and QoS scale, as the idea was that all the heavy-lifting would be done in MPLS. But, as with the ASR14000 and ME2600X boxes, the LSP card didn't last long. I guess Cisco figured the FP was a better option, as more and more traffic started leaving VPN's for the cloud and CDN's. For us, the PTX1000/10002 make absolute sense, and are options we are clearly looking at for fixed form factor core platforms as we seek cheaper 100Gbps ports than we can currently get for the CRS (or even the MX and ASR9000). For us, a low-scale IP services box or line card for the core is something we are very interested in. We don't need rich IP services in that area of the network, nor do we need rich MPLS services either. Simple, low-scale IP/MPLS will do. But for data centre operators who may be anti-MPLS, the vendors will be stuck between how they develop for them and how they develop for network operators, for some time to come. Mark. ___ 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/
Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
On Fri, 19 Jun 2020 at 13:29, Robert Raszuk wrote: Hey, > What you are saying is technically true but not realistically important. > > Why - the answer is history of PTX. I think this is interesting anecdote, but not much more. > It was originally designed and architected on the very basis of hardware cost > and performance when you would only need to switch at rates MPLS. > > Well real world showed that you can't sell such box and IP switching has been > added to data plane there. IP switching was there day 1, just not at DFZ scale in Broadway. But indeed, they got DFZ scale at Paradise, using off-chip HMC. Which is bad in numerous ways, not just because it costs a lot (there is either 2 or 3 HMC chip for every PE chip, so like double the front-plate without HMC) but it also makes the device fragile. There are 6 PE chips per LC, so 3*6 18 HMC chips, any of these HMC chips gets any problem and it's a full linecard reload of 15-20min. Even though 2/3 of the HMC chips are just delay buffer, and could be reloaded locally without impacting anything else. The remaiing 1/3 is lookup tables, and it can be argued it's cheaper to reload whole linecard than figure out how to resynchornise the FIB. Anyhow this design adds your cost, removes your ports and increases your outages. > Bottom line - I doubt you will find any vendor (from OEM to big ones) which > can afford to differentiate price wise boxes which would do line rate MPLS > and any thing less then line rate for IP. And as such IP clearly brings a lot > of value for simplification of control plane and route aggregation and IMHO > is a good (well best) universal transport today for all types of services > from WAN via Campus to DCs (or even MSDCs). Maybe I'm naive, but I believe we can learn. -- ++ytti ___ 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/
Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
Saku, What you are saying is technically true but not realistically important. Why - the answer is history of PTX. It was originally designed and architected on the very basis of hardware cost and performance when you would only need to switch at rates MPLS. Well real world showed that you can't sell such box and IP switching has been added to data plane there. Bottom line - I doubt you will find any vendor (from OEM to big ones) which can afford to differentiate price wise boxes which would do line rate MPLS and any thing less then line rate for IP. And as such IP clearly brings a lot of value for simplification of control plane and route aggregation and IMHO is a good (well best) universal transport today for all types of services from WAN via Campus to DCs (or even MSDCs). Cheers, R. On Fri, Jun 19, 2020 at 9:36 AM Saku Ytti wrote: > On Thu, 18 Jun 2020 at 22:25, Benny Lyne Amorsen via cisco-nsp > wrote: > > > > > I don't understand the point of SRv6. What equipment can support IPv6 > > > routing, but can't support MPLS label switching? > > > This probably does not change anything for SRv6, as that too will likely > > be an extra cost license. It makes non-MPLS tunnelling solutions very > > attractive though, since you can get away with a very "cost-effective" > > core and only require smarts in the edge. > > 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. > > 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. > > -- > ++ytti > ___ > 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/
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. ___ 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/
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 ___ 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/
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. ___ 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/
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 ___ 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/
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. ___ 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/
Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
On Thu, 18 Jun 2020 at 22:25, Benny Lyne Amorsen via cisco-nsp wrote: > > I don't understand the point of SRv6. What equipment can support IPv6 > > routing, but can't support MPLS label switching? > This probably does not change anything for SRv6, as that too will likely > be an extra cost license. It makes non-MPLS tunnelling solutions very > attractive though, since you can get away with a very "cost-effective" > core and only require smarts in the edge. 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. 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. -- ++ytti ___ 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/
Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
On 18/Jun/20 21:02, Benny Lyne Amorsen via cisco-nsp wrote: > It makes non-MPLS tunnelling solutions very > attractive though, since you can get away with a very "cost-effective" > core and only require smarts in the edge. Such as? Mark. ___ 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/