Re: Serious Juniper Hardware EoL Announcements
So there have been some developments re: this thread. As it pertains to the both the MX204 and MX10003, Juniper have made the following amendments: * EoS = 2023. * End of new features = 2024. * End of bug fixes = 2028. * End of critical features = 2028. * EoL = 2029. FWIW. Mark.
Re: Serious Juniper Hardware EoL Announcements
On 6/18/22 15:04, Robert Webb wrote: I just have one question? Why are we discussing IP allocations and IANA in an email thread about EoL Juniper gear? Something about having more time to fix other softer issues we've long ignored, since we won't be busy installing any hardware :-). Mark.
Re: Serious Juniper Hardware EoL Announcements
On 6/17/22 14:47, Saku Ytti wrote: I can't pinpoint HMC as a bad solution, yes we've had our share of HMC issues, but we've also on JNPR and some other vendors previously replaced all linecards due to memory issues, before stacked DRAMs were a thing, memories are notoriously fragile. I can pinpoint HMC as a huge risk due to no manufacturer :). The memory issues are exacerbated by needing to reload the whole linecard when one memory has issues, JNPR has now delivered on newer images fixes where you can reduce both the collateral damage and downtime by reloading individual PFEs (and connected memories). I do think HMC was a solid engineering choice, and I am a bit annoyed that it lost to HBM instead of co-existing with little different optimization points. But that doesn't excuse the situation. At the rate we are going, perhaps running Apple's M-chips for routers (to the extent possible) is not entirely unthinkable :-). Mark.
Re: Serious Juniper Hardware EoL Announcements
I just have one question? Why are we discussing IP allocations and IANA in an email thread about EoL Juniper gear? On Fri, Jun 17, 2022 at 1:26 PM Doug Barton wrote: > I don't want to glorify the idea of converting multicast space by > commenting on it, however you're wrong in several particulars about the > relationships around the IANA. > > Most notably here is the issue that in relationship to what IP addresses > can be handed out to who, and for what purpose, IANA is at the service > of the IETF. At the end of the day the IP address registries are not > that different from any of the other registries that IANA maintains on > their behalf. > > hope this helps, > > Doug (Former IANA GM) > > > On 6/14/22 8:54 PM, b...@theworld.com wrote: > > > > Just to put a little more flesh on that bone (having spent about a > > decade going to ICANN conferences): > > > > Although organized under ICANN, address allocation would generally be > > the role of IANA which would assign address blocks to RIRs for > > distribution. > > > > It's a useful distinction because IANA and the RIRs act fairly > > independently from the umbrella ICANN org unless there's some very > > specific reason for, e.g., the ICANN board to interfere like some > > notion that the allocation of these addresses would (literally) > > threaten the stability and security of the internet, or similar. > > > > Offhand (and following comments by people of competent jurisdiction) I > > can't see why IANA or the RIRs would resist this idea in > > principle. It's just more stock in trade for them, particularly the > > RIRs. > > > > Other than they (IANA, RIRs) wouldn't do this unless the IETF issued a > > formal redeclaration of the use of these addresses. > > > > Anyhow, that's roughly how the governance works in practice and has > > for over 20 years. > > > > So, I think the first major move would have to be the IETF issuing one > > or more RFCs redefining the use of these addresses which would then > > put them into the jurisdiction of IANA who could then issue them > > (probably piecewise) to the RIRs. > > > > On June 14, 2022 at 13:21 g...@toad.com (John Gilmore) wrote: > > > Dave Taht wrote: > > > > > Then it was "what can we do with what we can afford" now it's > more > > > > > like "What can we do with what we have (or can actually get)"? > > > > > > > > Like, working on better software... > > > > > > Like, deploying the other 300 million IPv4 addresses that are > currently > > > lying around unused. They remain formally unused due to three > > > interlocking supply chain problems: at IETF, ICANN, and vendors. > IETF's > > > is caused by a "we must force everyone to abandon trailing edge > > > technology" attitude. ICANN's is because nobody is sure how to > allocate > > > ~$15B worth of end-user value into a calcified IP address market > > > dominated by government-created regional monopolies doing allocation > by > > > fiat. > > > > > > Vendors have leapfrogged the IETF and ICANN processes, and most have > > > deployed the key one-line software patches needed to fully enable > these > > > addresses in OS's and routers. Microsoft is the only major vendor > > > seemingly committed to never doing so. Our project continues to > track > > > progress in this area, and test and document compatability. > > > > > > John > > > IPv4 Unicast Extensions Project > > >
Re: Serious Juniper Hardware EoL Announcements
I don't want to glorify the idea of converting multicast space by commenting on it, however you're wrong in several particulars about the relationships around the IANA. Most notably here is the issue that in relationship to what IP addresses can be handed out to who, and for what purpose, IANA is at the service of the IETF. At the end of the day the IP address registries are not that different from any of the other registries that IANA maintains on their behalf. hope this helps, Doug (Former IANA GM) On 6/14/22 8:54 PM, b...@theworld.com wrote: Just to put a little more flesh on that bone (having spent about a decade going to ICANN conferences): Although organized under ICANN, address allocation would generally be the role of IANA which would assign address blocks to RIRs for distribution. It's a useful distinction because IANA and the RIRs act fairly independently from the umbrella ICANN org unless there's some very specific reason for, e.g., the ICANN board to interfere like some notion that the allocation of these addresses would (literally) threaten the stability and security of the internet, or similar. Offhand (and following comments by people of competent jurisdiction) I can't see why IANA or the RIRs would resist this idea in principle. It's just more stock in trade for them, particularly the RIRs. Other than they (IANA, RIRs) wouldn't do this unless the IETF issued a formal redeclaration of the use of these addresses. Anyhow, that's roughly how the governance works in practice and has for over 20 years. So, I think the first major move would have to be the IETF issuing one or more RFCs redefining the use of these addresses which would then put them into the jurisdiction of IANA who could then issue them (probably piecewise) to the RIRs. On June 14, 2022 at 13:21 g...@toad.com (John Gilmore) wrote: > Dave Taht wrote: > > > Then it was "what can we do with what we can afford" now it's more > > > like "What can we do with what we have (or can actually get)"? > > > > Like, working on better software... > > Like, deploying the other 300 million IPv4 addresses that are currently > lying around unused. They remain formally unused due to three > interlocking supply chain problems: at IETF, ICANN, and vendors. IETF's > is caused by a "we must force everyone to abandon trailing edge > technology" attitude. ICANN's is because nobody is sure how to allocate > ~$15B worth of end-user value into a calcified IP address market > dominated by government-created regional monopolies doing allocation by > fiat. > > Vendors have leapfrogged the IETF and ICANN processes, and most have > deployed the key one-line software patches needed to fully enable these > addresses in OS's and routers. Microsoft is the only major vendor > seemingly committed to never doing so. Our project continues to track > progress in this area, and test and document compatability. > > John > IPv4 Unicast Extensions Project
Re: Serious Juniper Hardware EoL Announcements
On Fri, 17 Jun 2022 at 15:39, Tom Beecher wrote: > Thank you for calling out the HMC point. I think that alone is worth retiring > the platforms that were built around it. > The number of issues related the the HMC memory drivers were out of hand > early on, and lingered long past the growing pains phase. > I’m sure in the big picture, supply chain / manufacturing constraints > accelerated this, but part of me is happy to see HMC based stuff go. I can't pinpoint HMC as a bad solution, yes we've had our share of HMC issues, but we've also on JNPR and some other vendors previously replaced all linecards due to memory issues, before stacked DRAMs were a thing, memories are notoriously fragile. I can pinpoint HMC as a huge risk due to no manufacturer :). The memory issues are exacerbated by needing to reload the whole linecard when one memory has issues, JNPR has now delivered on newer images fixes where you can reduce both the collateral damage and downtime by reloading individual PFEs (and connected memories). I do think HMC was a solid engineering choice, and I am a bit annoyed that it lost to HBM instead of co-existing with little different optimization points. But that doesn't excuse the situation. -- ++ytti
Re: Serious Juniper Hardware EoL Announcements
Thank you for calling out the HMC point. I think that alone is worth retiring the platforms that were built around it. The number of issues related the the HMC memory drivers were out of hand early on, and lingered long past the growing pains phase. I’m sure in the big picture, supply chain / manufacturing constraints accelerated this, but part of me is happy to see HMC based stuff go. On Tue, Jun 14, 2022 at 12:05 Saku Ytti wrote: > On Tue, 14 Jun 2022 at 18:56, Raymond Burkholder > wrote: > > > Could you help me with HMC, BOM, YT? > > Hybrid Memory Cube, type of stacked DRAM, with shorter distance due to > stack. HMC was early contender and for some applications superior, but > HBM ended up winning the fight. > YT is the latest Trio generation, if it is acronym, I have no idea > what it is from. The EOL is about EA Trio, I believe that is from > EAgle. > > > BOM means to me BillOfMaterials, but I'm not sure I have that correct. > > Correct. > > > -- > ++ytti >
Re: Serious Juniper Hardware EoL Announcements
On Tue, 14 Jun 2022 at 21:42, Eric Kuhnke wrote: > I think the more common solution for something like that would be to use one > 100GbE port as a trunk on a MX204 or MX304 to a directly adjacent 1U 48-port > SFP+ switch in a purely L2 role used as a port expander, with dwdm/bidi/other > unique types of SFP+ optics inserted in that. It is disappointing that we are getting faceplates that are exclusively cloud optimised, and service providers are scratching their heads going 'how can i use this?'. But it may be that there simply isn't a business case to build models with different faceplates or to design yet another set of linecards. Of course the fab doesn't charge different costs for different Trio, we from cost POV, the chips always cost the ~same, if it's MX80 or MX304 (except MX304 has up-to three of them). So there isn't any real reason why you couldn't massively underutilize the chips and deliver faceplates that are optimised for different use-cases. However, JNPR does see ACX more for this role. Now VLAN aggregation isn't without its problems: a) termination router must be able to do QoS under shaper, you need to shape every VLAN to access rate and then QoS inside the shaper. There are a lot of problems here, and even if the termination router does support proper HQOS it may not support small enough burst values that the access can handle. b) you lose link state information at termination, and you need to either accept slower convergence (e.g. no BGP external fast fall over) or investigate into CFM or BFD, where BFD would require active participation from customer, which is usually not reasonable ask c) your pseudowire products will become worse, you may have MAC learning (you might be able to turn it off) limiting MAC scale, you will likely eat bunch of new frames which previously were passed, you may be able to fix it with L2PT (rewrite MAC on L2 ingress, rewrite MAC on L2 egress). And some things might become outright impossible, for example paradise chipset will drop ISIS packets with VLAN headers on the floor (technically impossible to have 802.3 and VLAN), so if your termination is paradise, your pseudowire customers can't use ISIS. d) most L2 devices have exceedingly small buffers and this solution implies many=>one traffic flow, so you're going to have to understand what amount of buffering you're going to need and how many ports you can attach there e) provisioning and monitoring complexity, as you need to have model where you decouple termination and access port, if you don't already do this, it can be quite complicated to add, there are number of complexities like how to associate these two ports for data collection and rendering, where and how to draw vlans f) if you dual attach the L2 aggregation you can create loops due to simple and complex reasons, termination may not have per-VLAN MAC filter, so adding 1 pseudowire VLAN, may disable MAC filtering for whole interface. And if you run default MAC/ARP timers (misconfig, defaults are always wrong, ARP needs to be lower than MAC, but this is universally not understood), primaryPE maybe send packets to L3 address which is in ARP, but not in MAC anymore (host down?), backupPE will receive it due to lack of MAC filtering and will forward to primaryPE, which will forward back to L2. This was just what immediately occurred to me, I'm sure I could remember more issues if I'd spent a bit more time thinking of it. L2 is hard, be it L2 LAN or L2 aggregation. And almost invariably incorrectly configured, as L2 stuff apparently works usually out-of-the-box, but is full of bees. Now the common solution vendors offer to address many of these problems is 'satellite', where the vendor takes HW and SW workarounds to reduce the problems caused by VLAN aggregation. Unfortunately the satellite story is as well regressing, Cisco doesn't have it for Cisco8k, Juniper wants to kill Fusion. Nokia and Huawei still seem to have love for provider faceplates. -- ++ytti
Re: Serious Juniper Hardware EoL Announcements
Just to put a little more flesh on that bone (having spent about a decade going to ICANN conferences): Although organized under ICANN, address allocation would generally be the role of IANA which would assign address blocks to RIRs for distribution. It's a useful distinction because IANA and the RIRs act fairly independently from the umbrella ICANN org unless there's some very specific reason for, e.g., the ICANN board to interfere like some notion that the allocation of these addresses would (literally) threaten the stability and security of the internet, or similar. Offhand (and following comments by people of competent jurisdiction) I can't see why IANA or the RIRs would resist this idea in principle. It's just more stock in trade for them, particularly the RIRs. Other than they (IANA, RIRs) wouldn't do this unless the IETF issued a formal redeclaration of the use of these addresses. Anyhow, that's roughly how the governance works in practice and has for over 20 years. So, I think the first major move would have to be the IETF issuing one or more RFCs redefining the use of these addresses which would then put them into the jurisdiction of IANA who could then issue them (probably piecewise) to the RIRs. On June 14, 2022 at 13:21 g...@toad.com (John Gilmore) wrote: > Dave Taht wrote: > > > Then it was "what can we do with what we can afford" now it's more > > > like "What can we do with what we have (or can actually get)"? > > > > Like, working on better software... > > Like, deploying the other 300 million IPv4 addresses that are currently > lying around unused. They remain formally unused due to three > interlocking supply chain problems: at IETF, ICANN, and vendors. IETF's > is caused by a "we must force everyone to abandon trailing edge > technology" attitude. ICANN's is because nobody is sure how to allocate > ~$15B worth of end-user value into a calcified IP address market > dominated by government-created regional monopolies doing allocation by > fiat. > > Vendors have leapfrogged the IETF and ICANN processes, and most have > deployed the key one-line software patches needed to fully enable these > addresses in OS's and routers. Microsoft is the only major vendor > seemingly committed to never doing so. Our project continues to track > progress in this area, and test and document compatability. > > John > IPv4 Unicast Extensions Project -- -Barry Shein Software Tool & Die| b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
Re: Serious Juniper Hardware EoL Announcements
When I last got pricing on the MX10003 in fall 2021, I was asked if I wanted pricing on something with exclusively 100GbE interfaces or with 10GbE capability. I got pricing for both options. Putting SFP+ 10GbE ports in a router of that total chassis+RE+linecard+support contract price is an *extremely* costly proposition on a dollar per port basis. Would recommend that anyone who thinks they need them to look at ways to put the 10GbE ports in some other device and attach that to the router. On Tue, 14 Jun 2022 at 14:09, Brian wrote: > From Juniper... > > "you are correct that there isn’t a native 10G SFP+ form factor offered > with the 304. > > > > QSA adapters are qualified (say for example, Nvidia), and from there it > can support native 10G Bidi, WDM, etc. The economics per-port, obviously, > get a little expensive with this approach if a lot of native 10G is needed > and breakout isn’t an option. > > > > Thanks!" > > > > Oh and also I just got the call, Juniper is forcing a Price Hike in July. > > On Tue, Jun 14, 2022 at 9:10 AM t...@pelican.org wrote: > >> > The MX204 is pure shocker! Unless the MX304 will come with a >> > license-based approach to run at MX204 pricing, that is Juniper shooting >> > themselves in the foot. >> >> Unless I'm missing a trick, the MX304 doesn't have an answer to >> installing DWDM, bidi, or other fancy optics in the SPF+ ports on the >> MX204. QSFP+ breakout to 4 x 10G is supported, but only 4 x vanilla 1310 >> optics - you'll need an external OEO solution if you want fancy 10G options. >> >> It otherwise seems a nice box on paper, although substantially more >> expensive than the MX204. >> >> Cheers, >> Tim. >> >> >>
Re: Serious Juniper Hardware EoL Announcements
>From Juniper... "you are correct that there isn’t a native 10G SFP+ form factor offered with the 304. QSA adapters are qualified (say for example, Nvidia), and from there it can support native 10G Bidi, WDM, etc. The economics per-port, obviously, get a little expensive with this approach if a lot of native 10G is needed and breakout isn’t an option. Thanks!" Oh and also I just got the call, Juniper is forcing a Price Hike in July. On Tue, Jun 14, 2022 at 9:10 AM t...@pelican.org wrote: > > The MX204 is pure shocker! Unless the MX304 will come with a > > license-based approach to run at MX204 pricing, that is Juniper shooting > > themselves in the foot. > > Unless I'm missing a trick, the MX304 doesn't have an answer to installing > DWDM, bidi, or other fancy optics in the SPF+ ports on the MX204. QSFP+ > breakout to 4 x 10G is supported, but only 4 x vanilla 1310 optics - you'll > need an external OEO solution if you want fancy 10G options. > > It otherwise seems a nice box on paper, although substantially more > expensive than the MX204. > > Cheers, > Tim. > > >
Re: Serious Juniper Hardware EoL Announcements
Matthew Petach wrote: > https://cacm.acm.org/news/257742-german-factory-fire-could-worsen-global-chip-shortage/fulltext > > That was the *sole* supplier of extreme ultraviolet lithography machines > for every major chip manufacturer on the planet. > > Chip shortages will only get worse for the next several years. The light > at the end of the tunnel is unfortunately *not* coming from an ultraviolet > lithography machine. :( It's quite trendy (but inaccurate) to declare that everything sucks, human life on the planet is ending, etc. Matthew's last paragraph seems to be one of those unduly dire conclusions, based on subsequent news after January. See: https://www.asml.com/en/news/press-releases/2022/update-fire-incident-at-asml-berlin https://www.cnbc.com/2022/01/19/asml-profit-beats-despite-berlin-fire-sees-20percent-sales-growth-in-2022-.html Those with a detailed interest in the topic can speak directly with Monique Mols, head of media relations at ASML.com, at +31 652 844 418, or Ryan Young, US media relations manager, +1 480 205 8659. Ryan confirmed to me today that the latest news is in the above links: there is expected to be no impact from the fire on ASML's extreme UV delivery schedule. He says they will provide a further update at their large annual meeting in about a month. John
Re: Serious Juniper Hardware EoL Announcements
Dave Taht wrote: > > Then it was "what can we do with what we can afford" now it's more > > like "What can we do with what we have (or can actually get)"? > > Like, working on better software... Like, deploying the other 300 million IPv4 addresses that are currently lying around unused. They remain formally unused due to three interlocking supply chain problems: at IETF, ICANN, and vendors. IETF's is caused by a "we must force everyone to abandon trailing edge technology" attitude. ICANN's is because nobody is sure how to allocate ~$15B worth of end-user value into a calcified IP address market dominated by government-created regional monopolies doing allocation by fiat. Vendors have leapfrogged the IETF and ICANN processes, and most have deployed the key one-line software patches needed to fully enable these addresses in OS's and routers. Microsoft is the only major vendor seemingly committed to never doing so. Our project continues to track progress in this area, and test and document compatability. John IPv4 Unicast Extensions Project
RE: Serious Juniper Hardware EoL Announcements
>For those who may have forgotten: > >https://cacm.acm.org/news/257742-german-factory-fire-could-worsen-global-chip-shortage/fulltext >That was the *sole* supplier of extreme ultraviolet lithography machines for >every major chip manufacturer on the planet. >Chip shortages will only get worse for the next several years. The light at >the end of the tunnel is unfortunately *not* coming from an ultraviolet >lithography machine. :( >Matt This video has a really good break down on the chip shortage as regards to everything that is not leading edge - https://www.youtube.com/watch?v=YJrOuBkYCMQ
Re: Serious Juniper Hardware EoL Announcements
On Tue, Jun 14, 2022 at 9:38 AM Adam Thompson wrote: > [Not specific to the Juniper EoLs...] > > I sort of agree with Mark: > > I've been sampling a fairly wide variety of sources in various parts of > the global supply chain, and my synthesis of what they're saying is that we > probably won't *consistently* have the ready availability of "stuff" (both > electronic and not) we had pre-pandemic, for the rest of my career > (10-15yrs), and maybe not in the lifetimes of anyone reading this today, > either. > For those who may have forgotten: https://cacm.acm.org/news/257742-german-factory-fire-could-worsen-global-chip-shortage/fulltext That was the *sole* supplier of extreme ultraviolet lithography machines for every major chip manufacturer on the planet. Chip shortages will only get worse for the next several years. The light at the end of the tunnel is unfortunately *not* coming from an ultraviolet lithography machine. :( Matt
Re: Serious Juniper Hardware EoL Announcements
On Tue, Jun 14, 2022 at 9:44 AM Shawn L via NANOG wrote: > > With the current shortages and lead times, I almost feel like I did back in > the beginning of my career --- > > > > Then it was "what can we do with what we can afford" now it's more like > "What can we do with what we have (or can actually get)"? Like, working on better software... > > > Shawn > > -Original Message- > From: "Adam Thompson" > Sent: Tuesday, June 14, 2022 12:36pm > To: "Mark Tinka" , "nanog@nanog.org" > Subject: RE: Serious Juniper Hardware EoL Announcements > > [Not specific to the Juniper EoLs...] > > I sort of agree with Mark: > > I've been sampling a fairly wide variety of sources in various parts of the > global supply chain, and my synthesis of what they're saying is that we > probably won't *consistently* have the ready availability of "stuff" (both > electronic and not) we had pre-pandemic, for the rest of my career > (10-15yrs), and maybe not in the lifetimes of anyone reading this today, > either. > > Whether those sources are accurate, their interpretation is accurate, my > synthesis is accurate, whether I'm listening to the right people in the first > place... all debatable. I sure hope the above conclusion is wrong. > > One possible upside: it might slow down the incessant upgrade hamster-wheel > we're all running on? Imagine having enough time to do your job thoroughly > and properly... Yes, I know I'm dreaming :-). > > > Adam Thompson > Consultant, Infrastructure Services > MERLIN > 100 - 135 Innovation Drive > Winnipeg, MB R3T 6A8 > (204) 977-6824 or 1-800-430-6404 (MB only) > https://www.merlin.mb.ca > Chat with me on Teams: athomp...@merlin.mb.ca > > > -Original Message- > > From: NANOG On Behalf > > Of Mark Tinka > > Sent: Tuesday, June 14, 2022 11:19 AM > > To: nanog@nanog.org > > Subject: Re: Serious Juniper Hardware EoL Announcements > > > > > > > > On 6/14/22 18:06, JASON BOTHE via NANOG wrote: > > > > > Saw this coming a mile away. With chips and technology progressing > > despite ability to manufacture, I’m certain many are going to do this. > > > > All this will do is keep these boxes off the open market, which will > > simply bump up open market prices, with no incentive for the majority > > of > > folk to buy directly from the OEM. > > > > I suspect supply chain will improve within the next 12 months, but > > then > > regress and hit a massive crunch from around Q4'23 onward. How long > > for, > > I can't say... > > > > Mark. -- FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/ Dave Täht CEO, TekLibre, LLC
Re: Serious Juniper Hardware EoL Announcements
I think the more common solution for something like that would be to use one 100GbE port as a trunk on a MX204 or MX304 to a directly adjacent 1U 48-port SFP+ switch in a purely L2 role used as a port expander, with dwdm/bidi/other unique types of SFP+ optics inserted in that. On Tue, 14 Jun 2022 at 08:08, t...@pelican.org wrote: > > The MX204 is pure shocker! Unless the MX304 will come with a > > license-based approach to run at MX204 pricing, that is Juniper shooting > > themselves in the foot. > > Unless I'm missing a trick, the MX304 doesn't have an answer to installing > DWDM, bidi, or other fancy optics in the SPF+ ports on the MX204. QSFP+ > breakout to 4 x 10G is supported, but only 4 x vanilla 1310 optics - you'll > need an external OEO solution if you want fancy 10G options. > > It otherwise seems a nice box on paper, although substantially more > expensive than the MX204. > > Cheers, > Tim. > > >
Re: Serious Juniper Hardware EoL Announcements
> On Jun 14, 2022, at 12:42 PM, Shawn L via NANOG wrote: > > With the current shortages and lead times, I almost feel like I did back in > the beginning of my career --- > > Then it was "what can we do with what we can afford" now it's more like > "What can we do with what we have (or can actually get)"? I’m definitely feeling a bit more of this - we are seeing quite a bit of mismatch as well in hardware where higher speeds are coming but without a firm consensus around optics. At least for the 400G space it seems to be largely sorted, as DR, FR and LR are all interchangeable it’s largely that receiver sensitivity which comes into scope, and the LR8 being there, but unlikely to see a lot of volume over time. Reminds me a lot of the DS3 vs OC3 vs gigE days of “what speed, how many”, but at least we have bundling figured out at this point. - Jared
Re: Serious Juniper Hardware EoL Announcements
ADVA recently launched a QSFP+ transceiver with bidi support on each of its 4x10G breakout lanes: https://www.adva.com/en/newsroom/press-releases/20220308-adva-launches-new-bidi-pluggable-to-minimize-cost-and-latency-in-access-networks As for 10G DWDM optics, it's not a very efficient way to use your ports, but you could hypothetically use a QSFP+ to SFP+ adapter like this one if you truly needed to run some in your MX304 chassis: https://www.flexoptix.net/en/transceiver/q-pct.html Best regards, Martijn From: NANOG on behalf of t...@pelican.org Sent: 14 June 2022 17:07 To: nanog@nanog.org Subject: RE: Serious Juniper Hardware EoL Announcements > The MX204 is pure shocker! Unless the MX304 will come with a > license-based approach to run at MX204 pricing, that is Juniper shooting > themselves in the foot. Unless I'm missing a trick, the MX304 doesn't have an answer to installing DWDM, bidi, or other fancy optics in the SPF+ ports on the MX204. QSFP+ breakout to 4 x 10G is supported, but only 4 x vanilla 1310 optics - you'll need an external OEO solution if you want fancy 10G options. It otherwise seems a nice box on paper, although substantially more expensive than the MX204. Cheers, Tim.
RE: Serious Juniper Hardware EoL Announcements
With the current shortages and lead times, I almost feel like I did back in the beginning of my career --- Then it was "what can we do with what we can afford" now it's more like "What can we do with what we have (or can actually get)"? Shawn -Original Message- From: "Adam Thompson" Sent: Tuesday, June 14, 2022 12:36pm To: "Mark Tinka" , "nanog@nanog.org" Subject: RE: Serious Juniper Hardware EoL Announcements [Not specific to the Juniper EoLs...] I sort of agree with Mark: I've been sampling a fairly wide variety of sources in various parts of the global supply chain, and my synthesis of what they're saying is that we probably won't *consistently* have the ready availability of "stuff" (both electronic and not) we had pre-pandemic, for the rest of my career (10-15yrs), and maybe not in the lifetimes of anyone reading this today, either. Whether those sources are accurate, their interpretation is accurate, my synthesis is accurate, whether I'm listening to the right people in the first place... all debatable. I sure hope the above conclusion is wrong. One possible upside: it might slow down the incessant upgrade hamster-wheel we're all running on? Imagine having enough time to do your job thoroughly and properly... Yes, I know I'm dreaming :-). Adam Thompson Consultant, Infrastructure Services MERLIN 100 - 135 Innovation Drive Winnipeg, MB R3T 6A8 (204) 977-6824 or 1-800-430-6404 (MB only) https://www.merlin.mb.ca Chat with me on Teams: athomp...@merlin.mb.ca > -Original Message- > From: NANOG On Behalf > Of Mark Tinka > Sent: Tuesday, June 14, 2022 11:19 AM > To: nanog@nanog.org > Subject: Re: Serious Juniper Hardware EoL Announcements > > > > On 6/14/22 18:06, JASON BOTHE via NANOG wrote: > > > Saw this coming a mile away. With chips and technology progressing > despite ability to manufacture, I’m certain many are going to do this. > > All this will do is keep these boxes off the open market, which will > simply bump up open market prices, with no incentive for the majority > of > folk to buy directly from the OEM. > > I suspect supply chain will improve within the next 12 months, but > then > regress and hit a massive crunch from around Q4'23 onward. How long > for, > I can't say... > > Mark.
RE: Serious Juniper Hardware EoL Announcements
[Not specific to the Juniper EoLs...] I sort of agree with Mark: I've been sampling a fairly wide variety of sources in various parts of the global supply chain, and my synthesis of what they're saying is that we probably won't *consistently* have the ready availability of "stuff" (both electronic and not) we had pre-pandemic, for the rest of my career (10-15yrs), and maybe not in the lifetimes of anyone reading this today, either. Whether those sources are accurate, their interpretation is accurate, my synthesis is accurate, whether I'm listening to the right people in the first place... all debatable. I sure hope the above conclusion is wrong. One possible upside: it might slow down the incessant upgrade hamster-wheel we're all running on? Imagine having enough time to do your job thoroughly and properly... Yes, I know I'm dreaming :-). Adam Thompson Consultant, Infrastructure Services MERLIN 100 - 135 Innovation Drive Winnipeg, MB R3T 6A8 (204) 977-6824 or 1-800-430-6404 (MB only) https://www.merlin.mb.ca Chat with me on Teams: athomp...@merlin.mb.ca > -Original Message- > From: NANOG On Behalf > Of Mark Tinka > Sent: Tuesday, June 14, 2022 11:19 AM > To: nanog@nanog.org > Subject: Re: Serious Juniper Hardware EoL Announcements > > > > On 6/14/22 18:06, JASON BOTHE via NANOG wrote: > > > Saw this coming a mile away. With chips and technology progressing > despite ability to manufacture, I’m certain many are going to do this. > > All this will do is keep these boxes off the open market, which will > simply bump up open market prices, with no incentive for the majority > of > folk to buy directly from the OEM. > > I suspect supply chain will improve within the next 12 months, but > then > regress and hit a massive crunch from around Q4'23 onward. How long > for, > I can't say... > > Mark.
Re: Serious Juniper Hardware EoL Announcements
This is not covid issue, these parts were EOLd before anyone knew what covid is. I don't know yet exactly what went wrong, and may not ever know as that information may not be available to even many at JNPR. On Tue, 14 Jun 2022 at 19:10, JASON BOTHE via NANOG wrote: > > Saw this coming a mile away. With chips and technology progressing despite > ability to manufacture, I’m certain many are going to do this. > > > On Jun 14, 2022, at 11:53, Raymond Burkholder wrote: > > > > On 2022-06-14 09:46, Saku Ytti wrote: > >> These EOLd are HMC devices, Micron EOLd HMC back in 2018, no one else made > >> them. > >> MX304 is a very different device than MX80, MX104, MX204. Previously > >> these were single chip very BOM optimised devices. MX304 has YT on > >> each card, which also means half of the YT capacity is spent on > >> fabric. Whereas MX80, MX104 connect ports on fabric and wan side, > >> getting 200% bps compared to fabric model. > >> Of course BOM isn't a meaningful contributor to what customers generally > >> pay. > > Holy acronym soup batman! > > > > Could you help me with HMC, BOM, YT? > > > > BOM means to me BillOfMaterials, but I'm not sure I have that correct. -- ++ytti
Re: Serious Juniper Hardware EoL Announcements
On 6/14/22 18:06, JASON BOTHE via NANOG wrote: Saw this coming a mile away. With chips and technology progressing despite ability to manufacture, I’m certain many are going to do this. All this will do is keep these boxes off the open market, which will simply bump up open market prices, with no incentive for the majority of folk to buy directly from the OEM. I suspect supply chain will improve within the next 12 months, but then regress and hit a massive crunch from around Q4'23 onward. How long for, I can't say... Mark.
Re: Serious Juniper Hardware EoL Announcements
Saw this coming a mile away. With chips and technology progressing despite ability to manufacture, I’m certain many are going to do this. > On Jun 14, 2022, at 11:53, Raymond Burkholder wrote: > > On 2022-06-14 09:46, Saku Ytti wrote: >> These EOLd are HMC devices, Micron EOLd HMC back in 2018, no one else made >> them. >> MX304 is a very different device than MX80, MX104, MX204. Previously >> these were single chip very BOM optimised devices. MX304 has YT on >> each card, which also means half of the YT capacity is spent on >> fabric. Whereas MX80, MX104 connect ports on fabric and wan side, >> getting 200% bps compared to fabric model. >> Of course BOM isn't a meaningful contributor to what customers generally pay. > Holy acronym soup batman! > > Could you help me with HMC, BOM, YT? > > BOM means to me BillOfMaterials, but I'm not sure I have that correct.
Re: Serious Juniper Hardware EoL Announcements
On Tue, 14 Jun 2022 at 18:56, Raymond Burkholder wrote: > Could you help me with HMC, BOM, YT? Hybrid Memory Cube, type of stacked DRAM, with shorter distance due to stack. HMC was early contender and for some applications superior, but HBM ended up winning the fight. YT is the latest Trio generation, if it is acronym, I have no idea what it is from. The EOL is about EA Trio, I believe that is from EAgle. > BOM means to me BillOfMaterials, but I'm not sure I have that correct. Correct. -- ++ytti
Re: Serious Juniper Hardware EoL Announcements
On 2022-06-14 09:46, Saku Ytti wrote: These EOLd are HMC devices, Micron EOLd HMC back in 2018, no one else made them. MX304 is a very different device than MX80, MX104, MX204. Previously these were single chip very BOM optimised devices. MX304 has YT on each card, which also means half of the YT capacity is spent on fabric. Whereas MX80, MX104 connect ports on fabric and wan side, getting 200% bps compared to fabric model. Of course BOM isn't a meaningful contributor to what customers generally pay. Holy acronym soup batman! Could you help me with HMC, BOM, YT? BOM means to me BillOfMaterials, but I'm not sure I have that correct.
Re: Serious Juniper Hardware EoL Announcements
On Tue, 14 Jun 2022 at 16:44, Mark Tinka wrote: > This chip shortage issue is, I think, being used as a crutch to take the p*ss. These EOLd are HMC devices, Micron EOLd HMC back in 2018, no one else made them. MX304 is a very different device than MX80, MX104, MX204. Previously these were single chip very BOM optimised devices. MX304 has YT on each card, which also means half of the YT capacity is spent on fabric. Whereas MX80, MX104 connect ports on fabric and wan side, getting 200% bps compared to fabric model. Of course BOM isn't a meaningful contributor to what customers generally pay. -- ++ytti
RE: Serious Juniper Hardware EoL Announcements
> The MX204 is pure shocker! Unless the MX304 will come with a > license-based approach to run at MX204 pricing, that is Juniper shooting > themselves in the foot. Unless I'm missing a trick, the MX304 doesn't have an answer to installing DWDM, bidi, or other fancy optics in the SPF+ ports on the MX204. QSFP+ breakout to 4 x 10G is supported, but only 4 x vanilla 1310 optics - you'll need an external OEO solution if you want fancy 10G options. It otherwise seems a nice box on paper, although substantially more expensive than the MX204. Cheers, Tim.
Serious Juniper Hardware EoL Announcements
So Juniper have gone ahead and announced the EoL of some key devices that, IMHO, are nowhere near past their prime: - MX204 (to be replaced by the MX304) - MX10003 (to be replaced by the MX304) - PTX1000 (to be replaced by the PTX10001) Re: the PTX1000, I know it is a component issue that Juniper have mentioned is the reason for EoL'ing this. We bought a fair bit in the past 2 years, and technically, there is nothing wrong with them. We are going ahead with the PTX10001 as a replacement, because it works technically and otherwise. Having both the MX10003 and MX304 in the same portfolio did not make any sense to me, and I did challenge Juniper on this over the past several weeks as to what their strategy for both platforms is. I guess we now have an answer :-\. Pity - we started buying the MX10003 last year, but I have no problem with the MX304 as long as the price continues to work. The MX204 is pure shocker! Unless the MX304 will come with a license-based approach to run at MX204 pricing, that is Juniper shooting themselves in the foot. This chip shortage issue is, I think, being used as a crutch to take the p*ss. Mark.
