Re: SRv6 Capable NOS and Devices
On Mon Jan 17, 2022 at 09:25:47AM +0200, Mark Tinka wrote: > High-end IP routing features (which includes MPLS) have always attracted > additional costs on what are meant to be Layer 2/3 switches. Isn't the argument here that if it's in most chip sets already it might reasonably be expected to be a standard low end feature by now, along with IPv6? That it isn't may be why people are open to SRv6 (I'm assuming some are based on this discussion) - if they have to pay extra they only want to do so where they are generating revenue from it, the end points. Complexity and architectural cleanliness are not a consideration, if a vendor makes a box that does the job at the right price there is a high risk people will buy it. brandon
Re: SRv6 Capable NOS and Devices
On 1/17/22 03:52, Colton Conor wrote: I agree that pretty much all the chipsets and asics out there today support MPLS, but it's the vendor and NOS that decides whether to enable it or not, or charge more for it. That has been the case since MPLS debuted. Example, Junipers EX4600, QFX5100 and ACX5048 all have the same Broadcom Trident II+ ASIC inside. One supports full MPLS features (ACX), while the other is limited (QFX), and then the EX is even more limited. . Only difference is what Juniper has enabled or disabled in software to my knowledge. All 3 run JUNOS, just different flavors. I don't see anything wrong with that. As with any business, different products provide different functionality, and as such, come with a different price. You can't expect Cessna's turboprops to fly you 16hrs between two points, non-stop, just because it is an aeroplane. Juniper are targeting different markets and use-cases with their switches vs. their routers. To expect them to provide the same degree of MPLS capability at both ends of the spectrum is unreasonable. I'm certain that in your business, you have different products, as well, that satisfy different types of customers at different price points, with differing value delivery. Mikrotik's MPLS stack is quite limited, but I hope that will change soon in version 7 that was just released. Honestly hoping that Mikrotik kicks half these vendors in the nuts with everything they are implementing in v7 with the new linux kernel and a development team that is 3x as large. 100G switches are coming soon from them with Marvell ASICs I actually think Mikrotik should maintain their model. It works for them, and their customer base. It's terrible for support, but you also aren't paying through the nose, and the boxes do what they generally claim to do. I'd rather they did not try to take on the traditional vendors. That pond is already murky as it is. VyOS doesn't run on any ASIC based systems to my knowledge, so its just a software router. My point was MPLS is available, even on x86 platforms with open source code. You don't have to pay tons of money for it to get it anymore. Of course, if you want to run it at scale, there are other considerations beyond just the MPLS code itself, as you know. Extreme charges extra to enable MPLS in their SLX lineup. High-end IP routing features (which includes MPLS) have always attracted additional costs on what are meant to be Layer 2/3 switches. Ciena, Ribbon, and others do the same. Also Tejas, Infinera, Xtera, e.t.c., all "claim" MPLS support, but that's not their bread & butter. So yes, along with the priviledge of it being terribly implemented, you get the pleasure of paying extra for it too, with the optical vendors. Mark.
Re: SRv6 Capable NOS and Devices
I agree that pretty much all the chipsets and asics out there today support MPLS, but it's the vendor and NOS that decides whether to enable it or not, or charge more for it. Example, Junipers EX4600, QFX5100 and ACX5048 all have the same Broadcom Trident II+ ASIC inside. One supports full MPLS features (ACX), while the other is limited (QFX), and then the EX is even more limited. . Only difference is what Juniper has enabled or disabled in software to my knowledge. All 3 run JUNOS, just different flavors. Mikrotik's MPLS stack is quite limited, but I hope that will change soon in version 7 that was just released. Honestly hoping that Mikrotik kicks half these vendors in the nuts with everything they are implementing in v7 with the new linux kernel and a development team that is 3x as large. 100G switches are coming soon from them with Marvell ASICs VyOS doesn't run on any ASIC based systems to my knowledge, so its just a software router. Extreme charges extra to enable MPLS in their SLX lineup. Ciena, Ribbon, and others do the same. On Sat, Jan 15, 2022 at 1:47 PM Mark Tinka wrote: > > > > On 1/15/22 19:22, Colton Conor wrote: > > > True, but in general MPLS is more costly. It's available on limited > > devices, from limited vendors. Infact, many of these vendors, like > > Extreme, charge you if you want to enable MPLS features on a box. > > Well, I don't entirely agree. > > Pretty much all chips shipping now, either custom or merchant silicon, > will support MPLS. Whether the vendor chooses to implement it in code or > not is a whole other matter. > > If you need MPLS, chances are you can afford it. If you don't, then you > don't have to worry about it. > > For Extreme, are you referring to before or after they picked up Brocade? > > There is MPLS available in a number of cheap software suites. Even > Mikrotik provides MPLS support. Whether it works or not, I can't tell you. > > VyOS supports is too. Whether it works or not, I can't tell you. > > But I think we are long past the days of "MPLS is expensive". > > Mark.
Re: enom giving Google a bad name
On 1/16/22 11:44, Rubens Kuhl wrote: "We also discovered resolution problems that impact a few hundred domains" Tucows group, which includes a few registrars including eNom, had more than 12 million domains under management by September 2021 (last set of statistics published by ICANN). So we are talking 0,01% of customers affected, tops. Assuming small values of "few", that is correct. -- Jay Hennigan - j...@west.net Network Engineering - CCIE #7880 503 897-8550 - WB6RDV
Re: SRv6 Capable NOS and Devices
Hey Sabri, Eventually they have implemented everything ;-) Arista was a really special case, routing stack they acquired (NextHop) had no mpls (quite some time ago), 90% of their revenue was coming from IP only networks. Life is good, MS is treating me well :). Kids are growing, Marina’ business doing ok. How’s life on your side? Would love to meet, lunch or so? Cheers, Jeff > On Jan 16, 2022, at 13:19, Jeff Tantsura wrote: > > > Plane IP underlay works real well, I’m yet to see tangible proof of TE in DC > (outside of niche HPC/IB cases). > SR in DC - with overlay starting on the host SR-MPLSoUDP(RFC8663) is a > perfect representation of a working technology that works in IP environment > as well as allows end2end programming for MPLS WAN/DCI. > Here’s an example of end2end architecture that works really well - > https://datatracker.ietf.org/doc/draft-bookham-rtgwg-nfix-arch/ > > Geneve (there are some quirks as you get into implementing it) is another > example of a well designed overlay encap. > > > Cheers, > Jeff > >>> On Jan 15, 2022, at 23:54, Saku Ytti wrote: >>> >> On Sat, 15 Jan 2022 at 19:22, Colton Conor wrote: >> >>> True, but in general MPLS is more costly. It's available on limited >>> devices, from limited vendors. Infact, many of these vendors, like >>> Extreme, charge you if you want to enable MPLS features on a box >> >> Marketing, not fundamentals. DC people are driving demand for VXLAN >> and SRv6, because they assume MPLS is something scary and complex. So >> vendors implement something scary and complex to appease DC people. >> I'm sure in some years to the future, DC people will re-invent MPLS to >> simplify their stack. >> >> -- >> ++ytti
Re: SRv6 Capable NOS and Devices
Plane IP underlay works real well, I’m yet to see tangible proof of TE in DC (outside of niche HPC/IB cases). SR in DC - with overlay starting on the host SR-MPLSoUDP(RFC8663) is a perfect representation of a working technology that works in IP environment as well as allows end2end programming for MPLS WAN/DCI. Here’s an example of end2end architecture that works really well - https://datatracker.ietf.org/doc/draft-bookham-rtgwg-nfix-arch/ Geneve (there are some quirks as you get into implementing it) is another example of a well designed overlay encap. Cheers, Jeff > On Jan 15, 2022, at 23:54, Saku Ytti wrote: > > On Sat, 15 Jan 2022 at 19:22, Colton Conor wrote: > >> True, but in general MPLS is more costly. It's available on limited >> devices, from limited vendors. Infact, many of these vendors, like >> Extreme, charge you if you want to enable MPLS features on a box > > Marketing, not fundamentals. DC people are driving demand for VXLAN > and SRv6, because they assume MPLS is something scary and complex. So > vendors implement something scary and complex to appease DC people. > I'm sure in some years to the future, DC people will re-invent MPLS to > simplify their stack. > > -- > ++ytti
Re: enom giving Google a bad name
> > Because they used URL redirection services, right ? Domains under > > management are unlikely to be affected unless the registrant needs a > > domain update. > > From what I see enom's nameservers are down. "We also discovered resolution problems that impact a few hundred domains" Tucows group, which includes a few registrars including eNom, had more than 12 million domains under management by September 2021 (last set of statistics published by ICANN). So we are talking 0,01% of customers affected, tops. Rubens
Re: enom giving Google a bad name
On 16/01/2022 19:57, Rubens Kuhl wrote: On Sun, Jan 16, 2022 at 2:38 PM Hank Nussbacher wrote: Many of you might be following the enom weekend fiasco: https://twitter.com/enomsupport/status/1482621466151571456 https://twitter.com/enomsupport/status/1482707275529678849 https://enomstatus.com/ Thousands of domains have been knocked out. Because they used URL redirection services, right ? Domains under management are unlikely to be affected unless the registrant needs a domain update. From what I see enom's nameservers are down. -Hank
Re: enom giving Google a bad name
What do you mean by "takes responsibility?" When my vendor goes down, I do whatever I can to get the end user back up and running again. I take _ownership_ of the situation and work dilligently to resolve it, as best I can, within my sphere of control. However, because I cannot control how my vendor operates their business, how can I take responsiblity for its actions and operations? My option is to decide if the vendor had a bad day or if they are inept and I need to replace them. Finding them inept and NOT replacing them THEN puts the responsibility on my shoulders, IMHO. Has enom been demonstrably inept leading up to this point? Beckman On Sun, 16 Jan 2022, Hank Nussbacher wrote: But I just found out that Google is an enom reseller: So who takes responsibility when a fiasco happens like this: Google or Enom? --- Peter Beckman Internet Guy beck...@angryox.comhttps://www.angryox.com/ ---
Re: enom giving Google a bad name
On Sun, Jan 16, 2022 at 2:38 PM Hank Nussbacher wrote: > > Many of you might be following the enom weekend fiasco: > > https://twitter.com/enomsupport/status/1482621466151571456 > > https://twitter.com/enomsupport/status/1482707275529678849 > > https://enomstatus.com/ > > Thousands of domains have been knocked out. Because they used URL redirection services, right ? Domains under management are unlikely to be affected unless the registrant needs a domain update. > But I just found out that Google is an enom reseller: > > https://help.enom.com/hc/en-us/articles/115005222367-My-Domain-was-registered-through-G-Suite-Google-Apps > > "Google handles all of the billing and renewals of your domain name, > while Enom offers technical support to manage your domain." > > > So who takes responsibility when a fiasco happens like this: Google or Enom? I would imagine Google only uses Enom for TLDs that they don't carry thru Google Domains, their own registrar. And Google would also use its own URL redirection services, not Enom's. Rubens
enom giving Google a bad name
Many of you might be following the enom weekend fiasco: https://twitter.com/enomsupport/status/1482621466151571456 https://twitter.com/enomsupport/status/1482707275529678849 https://enomstatus.com/ Thousands of domains have been knocked out. But I just found out that Google is an enom reseller: https://help.enom.com/hc/en-us/articles/115005222367-My-Domain-was-registered-through-G-Suite-Google-Apps "Google handles all of the billing and renewals of your domain name, while Enom offers technical support to manage your domain." So who takes responsibility when a fiasco happens like this: Google or Enom? -Hank
Re: Open source mapping of US high voltage electrical grid
I do think the data in OpenStreetMap is undervalued. Lots of stuff there and there are a few projects that exist to better visualize that data. https://www.openrailwaymap.org/ is another using Open Street Map data. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com - Original Message - From: "Eric Kuhnke" To: "nanog@nanog.org list" Sent: Saturday, January 15, 2022 8:45:53 PM Subject: Open source mapping of US high voltage electrical grid Possibly of interest for network operators who have inter-city circuits, where the underlying carrier is something on OPGW fiber in high voltage lines. These people seem to be making an effort at mapping out high voltage lines, hydroelectric dams, substations, etc. https://openinframap.org
Re: Open source mapping of US high voltage electrical grid
Very cool, thanks, Eric. ><> nathan stratton On Sat, Jan 15, 2022 at 9:48 PM Eric Kuhnke wrote: > Possibly of interest for network operators who have inter-city circuits, > where the underlying carrier is something on OPGW fiber in high voltage > lines. > > These people seem to be making an effort at mapping out high voltage > lines, hydroelectric dams, substations, etc. > > https://openinframap.org > >
