diff --git a/content/articles/2017-03-01-sixxs-sunset.md b/content/articles/2017-03-01-sixxs-sunset.md new file mode 100644 index 0000000..38f1ef2 --- /dev/null +++ b/content/articles/2017-03-01-sixxs-sunset.md @@ -0,0 +1,406 @@ +--- +date: 2017-03-14 +title: Sunsetting SixXS +aliases: +- /s/articles/2017/03/14/sixxs-sunset.html +--- + +* Author: Pim van Pelt, Jeroen Massar +* Contact: <[staff@sixxs.net](mailto:staff@sixxs.net)> +* Date: March 2017 +* Status: Draft - Review SixXS - Review Admins - Final - **Published** + +## Summary + +SixXS will be sunset in H1 2017. All services will be turned down on **2017-06-06**, after which the +SixXS project will be retired. Users will no longer be able to use their IPv6 tunnels or subnets +after this date, and are required to obtain IPv6 connectivity elsewhere, primarily with their +Internet service provider. + +## Introduction + +SixXS (Six Access) is a free, non-profit, non-cost service for Local Internet Registries (LIR's) and +endusers. The main goal is to create a common portal to help company engineers find their way with +IPv6 networks deploying IPv6 to their customers in a rapid and controllable fashion. To reach our +goals, SixXS provides the following services: + ++ IPv6 Tunnel Broker: a versatile and high performance IPv6 tunneling router ++ Ghost Route Hunter: an IPv6 route monitoring tool and various other services to help out where needed ++ IPv6Gate HTTP Proxy: IPv6-IPv4 and IPv4-IPv6 Website Gateway + +SixXS has offered the [RIPE](http://www.ripe.net/), [ARIN](http://www.arin.net/), +[APNIC](http://www.apnic.net/), [LacNIC](http://www.lacnic.net/) and +[AfriNIC](http://www.afrinic.net/) communities pre-production deployment expertise based on the +experience gathered while running the IPng IPv6 tunnel broker since 1999 and, combined with its +successor, SixXS, gaining more than 18 years of valuable IPv6 experience. + +### Userbase + +As of March 2017, there are 38’393 7-day active users spanning 140 countries. These users configured +a total of 44’673 tunnels spanning 118 countries, and 12’632 subnet delegations (28.28%). Our peak +7DA usage was over 50’000 users. Full statistics, including distributions by country, can be found +on the SixXS website [[link](https://www.sixxs.net/misc/usage/)]. + +#### Growth + +User engagement over time (as shown in the graphs below), shows strong growth from 2001-2011, +followed by a stagnation and then decrease of new users and subnets leading through 2016. We believe +this is due to *saturation*, all users with the ability and desire to receive service, obtained an +account, a tunnel and a subnet. + +![Users/Year](/assets/sixxs-sunset/image1.png) | ![Tunnels/Year](/assets/sixxs-sunset/image2.png) + +*Images: Left - New users per year; Right - New tunnels per year*. + +Another way to visualize this data is to measure the cumulative requested subnets (which are /48 in +size). The requests for subnets naturally follows the growth of users. In recent years (2014 +onwards), requests for additional subnets were clearly tapering off - this is in line with our goal +of SixXS. Therefore, in December of 2015, new user signups were suspended. Note: this explains the +flatline of requests in the years 2016 and 2017. + +![Cumulative Requests/Year](/assets/sixxs-sunset/image3.png) +*Image: Cumulative requests over time*. + +#### Traffic + +As the project evolved, traffic initially grew significantly, with a daily average of just around +900Mbit/sec. We note the trend of traffic is on a downwards trajectory since H2 2015. We believe +this is in part due to ISPs starting to offer IPv6, which yields organic attrition of users +migrating away. This trend is in line with the goals of the project. + +Users engage with SixXS *passively* - once they set up their tunnel and configure their router or +computer, the system is largely zero-touch. Traffic is consistently diurnal with a 7:1 ratio between +peak and trough, which indicates that the traffic flowing through the system is roughly equivalent +to what access providers see. This has changed over time - in the early days of IPv6, the major use +case was NNTP and IRC, now general Internet usage with the larger content providers all support +IPv6. + +Comparing our traffic pattern to a well known Internet exchange point +[[amsix](https://ams-ix.net/technical/statistics/sflow-stats/ipv6-traffic)], we see similar changes. +Today, many of the larger content providers have offerings on IPv6 which shifts the usage of our +service also more towards HTTP (and, to a diurnal pattern). + +The following two graphs illustrate the usage: The first graph is average traffic in bits/sec +between 2012 and 2017. Second graph is average traffic in bits/sec between 2017-02-24 and +2017-03-03. + +![image](/assets/sixxs-sunset/image4.png) | ![image](/assets/sixxs-sunset/image5.png) + +*Images: Left - traffic since 2012. Right - weekly traffic pattern Feb 2017*. + +#### Footprint + +Looking at the total footprint of SixXS - In March 2017, 46 PoPs spread over 29 countries were +offered by 40 unique Internet service providers. Over the lifetime of SixXS, a total of 65 different +PoPs have been active. + +![image](/assets/sixxs-sunset/image6.png) + +*Image: Map of SixXS PoPs* + +The full list of countries hosting PoPs: Australia, Belgium, Brazil, Czech Republic, Denmark, +Estonia, Faroe Islands, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Luxembourg, +Netherlands, New Caledonia, New Zealand, Norway, Poland, Portugal, Russia, Slovenia, Sweden, +Switzerland, United Kingdom, United States and Vietnam. + +Our deployment comprises the following subnet allocations: 85x /40 which is equivalent to a total of +21’760 /48's or 1x /34 + 1x /36 + 1x /38 + 1x /40 -- to cover our usage fully would require an IPv6 +/33. We believe the SixXS footprint is one of the largest IPv6 deployments in the world, and are +incredibly proud of the accomplishments and contributions we have made to the community. + +## Rationale + +The mission of SixXS is to help prepare companies and individual users for the world of IPv6. +Started in 1999, our goals were to build a distributed tunnelbroker system, which allowed +professional and hobbyist users to learn how to operate IPv6 networks so that they would roll out +IPv6 natively across the Internet. Back in 1999, we wrote: *Our ultimate target is to conclude the +tunnel brokering service when all the end users can get [Native +IPv6](https://www.sixxs.net/faq/connectivity/?faq=native) directly from their own Internet +provider*. + +For a decade, the industry was divided into content providers and access providers engaged a chicken and egg game: + +1. Content providers claimed that investing in IPv6 rollout would be useless because there were not + sufficient numbers of large ISPs which offered it. +1. Access providers claimed that investing in IPv6 would be useless because there were not + sufficient numbers of large content providers which offered it. +1. Both content providers and access providers claimed their customers didn’t demand it and there + was no business justification in doing so. + +One *raison d’être* of SixXS is to help break this cycle by offering IPv6 connectivity to users, so +that they in turn can demand that content providers offer service over IPv6, and to companies, so +their engineers can learn the intricacies of rolling out IPv6 for their business safely. After 18 +years, here is where we stand: + +1. Content providers, largely, have switched to IPv6. Examples: Wikipedia, Google, Youtube, + Facebook, Akamai, Netflix, Microsoft, Yahoo. + +1. Access providers are starting to move on IPv6 deployments: + [18%](https://www.google.com/intl/en/ipv6/statistics.html) of the Internet has IPv6 connectivity, + roughly doubling year over year. + +1. The access providers generally still claim that there is not sufficient customer demand to + invest in IPv6. + +Today, SixXS plays an insignificant role in converting the opinion on (1), (2) and (3) and is more +recently (2016 and beyond) being quoted by several large access providers as a compelling +alternative for their few customers who asked for IPv6, along the worrying lines of *“SixXS and +Hurricane Electric offer tunnels, so we are not planning to provide native IPv6 at this time”*. + +A call to action in 2016, asking our users to call their ISP and ask about rollout plans, yielded +some reasonable engagement from SixXS users (for which we are incredibly grateful), but arguably +disappointing results from the ISPs, particularly the very large ones. Extensive data can be found +on the SixXS wiki page [[link](https://www.sixxs.net/wiki/Call_Your_ISP_for_IPv6)]. + +## Conclusion + +Building up to our conclusion, we make some critical observations: + +1. SixXS penetration has hit a point of diminishing returns (see the ‘Growth’ subsection of this + document). + +1. Content providers have shown great progress in enabling users to reach their websites via IPv6, + in our opinion formally breaking the chicken and egg problem. + +1. Access providers have shown reasonable interest in providing IPv6 to users, but some have + started to quote SixXS as a reason they do not have to show an interest. + +1. Consumers should not have to be involved in the discussion as they largely need not know, or + care, how the Internet works, as long as they can reach the Internet resources they want, when they + want them. + +Our conclusion is that SixXS is no longer able to contribute to the solution, and is hampering its +own goals of facilitating the migration of consumers to native IPv6. We have therefore decided to +shut down our services on 2017-06-06. + +## Accomplishments + +When we started in 1999, we set ourselves some pretty ambitious goals. They are described on our +website as value propositions to [ISPs](https://www.sixxs.net/faq/sixxs/?faq=isp), to +[endusers](https://www.sixxs.net/faq/sixxs/?faq=enduser) and we explain in detail [what +targets](https://www.sixxs.net/faq/sixxs/?faq=why) we want our project to achieve in order to help +the technical community. + +To the latter point ([why do this](https://www.sixxs.net/faq/sixxs/?faq=why)?), we have by far +exceeded our targets of creating 10 regional PoPs (we created 65, each using their own IPv6 address +space); we developed and rolled out a provisioning system that manipulated tunnels and subnets w/o +human intervention; gathered a wide array of statistics (traffic, latency, uptime, debugging); set +up Multicast, DNS and DNSSEC delegations; and allowed for a feature rich web- and console interface +to manage the system. + +We felt that having zero-touch PoP servers would likely yield less probability for human error to +cause outages, and we were right: in 18 years of operation we cannot remember any wide scale outages +caused by human error. + +However, we did not stop at writing solid automation. The following are notable contributions that +SixXS has made to IPv6 deployment and the Internet in general: + +1. PoPs on five major continents, missing Africa and Antarctica +1. [sixxsd](https://www.sixxs.net/faq/sixxs/?faq=sixxsd) - software based router with high performance tunneling support +1. [Heartbeat](https://www.sixxs.net/tools/heartbeat/) protocol (IANA port 3740) and [IETF draft](https://tools.ietf.org/html/draft-massar-v6ops-heartbeat-01) +1. [AYIYA](https://www.sixxs.net/tools/ayiya/) protocol (IANA port 5072) and [IETF draft](https://tools.ietf.org/html/draft-massar-v6ops-ayiya-02) +1. Community outreach (example RIPE, IETF, ISOC, AMS-IX IPv6 Awareness Day) +1. Research done with GRH (Ghost Router Hunter) to: + + Help eradicate global IPv6 routing issues (Ghost Routes) + + IPv6 Bogon Route detection + + Distributed Looking Glass and Traceroute +1. AICCU (Automatic IPv6 Connectivity Client Utility) + + Automatic setup of IPv6 connectivity providing only username + password. + + Awards of Excellence in the Implementation Award Category in the [IPv6 Application Contest 2004](http://www.v6pc.jp/apc/en/implement.html) + + Incorporated into commercial Draytek, ZyXel, Motorola CPE products +1. Heartbeat & TIC support out the box in AVM Fritz!Box +1. Very few outages over 18 years of operation +1. Pre-production access to Google and Wikipedia IPv6 servers through SixXS DNS recursors + +Over time, social and technical media picked up on SixXS activities and regularly acknowledged the +significance of the project. For example at +[Heise](https://www.heise.de/newsticker/meldung/IPv6-Tunneldienst-SixXS-nimmt-ab-sofort-keine-neuen-Teilnehmer-an-3160822.html), +Linux [Journal](http://www.linuxjournal.com/content/may-2013-issue-linux-journal-raspberry-pi), and +in [other](https://www.sixxs.net/archive/sixxs/articles/) places. + +## Acknowledgements + +As SixXS founders, we were not operating in a vacuum. We have had countless interactions with +institutions and corporations, many mentors, and like-minded engineers across the world. We wanted +to take this opportunity to call out these formative folks: + ++ [TU/e](http://www.tue.nl/) and [MCGV Stack](http://www.stack.nl/) (the genesis of IPng in 1997) ++ [Intouch](http://www.intouch.nl/) (the continuation of IPng and first sponsor of SixXS in 1999) ++ [Concepts ICT](http://www.concepts-ict.nl) (long time sponsor of SixXS, including our NOC hardware) ++ [HEAnet](http://www.heanet.ie) (long time sponsor of SixXS since 2002) ++ [BIT](http://www.bit.nl) (long time IPv6 advocate, and long time sponsor of SixXS since 2004) ++ [AMS IX](http://www.ams-ix.net) (for organizing the AMS-IX IPv6 Awareness Day in Oct 2002) ++ [ISOC](http://www.isoc.org) and Steve Deering (for inventing IPv6, and meeting us in Amsterdam) ++ [IPv6 Flag Day](http://www.worldipv6launch.org/participants/?q=1) effort (for addressing the chicken-and-egg problem) ++ [IPv6 Ops](http://lists.cluenet.de/mailman/listinfo/ipv6-ops/) (for an engineering focused mailing list) ++ [Heise](http://www.heise.de) (for their kind attention over the years) + +And lastly, we extend our gratitude to the men and women who professionally operate the network, +those who arranged the physical or virtual hardware, and those who are in a position to commit to +running all 65 [SixXS PoPs](https://www.sixxs.net/pops/)! + +## FAQ + +**Will you reconsider your decision?** + +A lot of thought has gone into this decision. While we do understand that the service SixXS provides +is very valuable to its users, we have seen the growth of IPv6 content providers as well as IPv6 +access providers is [exponentially](https://www.google.com/intl/en/ipv6/statistics.html) growing. We +are of the belief that IPv6 Tunnel Brokers are no longer facilitating access providers moving to +IPv6, and as such do not wish for the project to be continued. We will not reconsider our decision. + +**Will you hand over the project to other folks?** + +We are fairly protective of our brand and position in the community. Due to the nature of SixXS, +which rests on an open source client (aiccu) with a closed source server (sixxsd), we are not +willing to hand over the project. However, that aside, the main justification for our decision as +outlined in this document, is that we are of the belief that IPv6 Tunnel Brokers are no longer +facilitating access providers moving to IPv6, and as such do not wish for the project to be +continued. Handing it over to other folks will not allow us to satisfy our concerns. + +**Do you need help?** + +Running SixXS servers and infrastructure is very efficient and does not demand much time. The PoP +servers are stateless and can be brought up based on a Debian or Ubuntu base install in a matter of +minutes. Handling user questions is stressful at times due to the volume of requests, but overall +it’s manageable because most of our user interaction is self-service on the website. For operating +SixXS, we do not believe time is a major concern. + +That said, help can be more productively offered in the area of IPv6 deployment in Internet content +providers and access providers. If you are active in those areas, we would greatly appreciate it if +you would champion with your leadership and engineering teams to roll out IPv6 for your users! + +**What happens to the users?** + +We will mark all the tunnels and subnets as deleted on 2017-06-06 at which point they will stop +forwarding traffic. Users will not have access to IPv6 through SixXS anymore on that date. We will +return all resources to the Internet service providers, shut down the PoPs and delete all personally +identifiable data from our database. + +**What happens to the servers (PoPs)?** + +The servers will be shut down and returned to the ISPs who own them, as SixXS itself does not own +the PoP servers. The SixXS website will continue to run on private servers, mostly serving as a +tombstone documenting our efforts over the years. + +**What happens to the PII data you have?** + +In the lifetime of the project, we have taken privacy and individually identifiable information very +seriously, and to our knowledge have never suffered an information breach or leek. After +decommissioning the services we run, we will destroy all PII data, keeping only traffic statistics +at the PoP level, and general statistics of our usage, like the graphs seen in this document. + +**What happens to WHOIS entries in RIPE and APNIC databases?** + +As we mark the tunnels and subnets as deleted, our automation will automatically purge these records +(inet6num) from the RIPE and APNIC databases. We will also return the subnets SixXS operates on +behalf of the PoP owners (these /40 supernets will be returned to the LIRs). + +For user (person) records, see FAQ entry (Do I have to delete my RIR handle). + +**What is your timeline?** + +Our timeline for the sunset of our services started in early March 2017, traversing a dialog with +PoP administrators in April, notifying users at the end of April, and offering 6 weeks of time for +folks to find alternative solutions. + +On 2017-06-06 we will shut down services, and close the sunsetting project on 2017-07-01. + +**What are my alternatives?** + +Users are encouraged to call their ISP for IPv6 connectivity -- ultimately that is the best way +forward. Provided sufficient numbers of paying customers request IPv6 service, ISPs may be compelled +to invest in offering service. + +There is sometimes healthy competition. ISPs are critically interested in retaining users. If a +specific ISP offers IPv6 to users -- consider switching providers to obtain native connectivity and +making note of this with the old ISP. + +In cases where this proves infeasible, there are myriad other IPv6 Tunnel Brokers available. + +**Will you open source SixXS code?** + +We do not currently have plans to open source any code that is not already publicly available. +Although our provisioning servers and routing daemon (sixxsd) are very well thought out, they do +have some intricate dependencies on how we built SixXS. As such, offering the code base will not be +necessarily useful for others. Over time, given effort on Jeroen’s part, this may change. We cannot +make any promises at this point. + +**Can I still use www.sixxs.net as connectivity checker (smokeping et al)?** + +We are aware (simply by looking at access logs), that many users have pointed their IPv6 network +monitoring at our website. Among these users are some quite large companies as well. You can rest +assured that we will keep [www.sixxs.net](http://www.sixxs.net) running on highly available +distributed servers ongoing. It is likely that the website will become static, making it somewhat +more reliable than it already is. + +**What happens to the SixXS domains (sixxs.{com,net,org,...})?** + +While we are retiring our services, the website will remain up. All domains will remain delegated to +the current nameservers, although only www and MX will remain. In particular, the PoP hosts and +tunnel hostnames like cl-x.pop-yy.tld.sixxs.net will be removed. + +**I am hosting my nameserver, mailserver, etc on my tunnel, what happens?** + +It is quite common and entirely acceptable for folks to point NS or MX records towards their tunnel +name (cl-x.pop-yy.tld.sixxs.net). Hosting servers with content behind the tunnels is also common. +Considering the DNS entries for sixxs.net will cease to exist, and the tunnels will be +decommissioned, users are recommended to move their services to other IPv6 providers (either +colocated, natively routed to home or office connections, or behind another IPv6 Tunnel Broker if no +other options exist). + +**Do I have to delete my RIR handle (RIPE/ARIN/APNIC/LacNIC/AfriNIC)?** + +If you are using the handle for other business, obviously you should keep them. If SixXS was the +sole purpose of registering such a handle (we have required them for many years), we recommend +removing your handle from the relevant RIR database. The call is ultimately yours, as SixXS does not +own that data. + +**What happens with the ULA registry?** + +This registry was for educational purposes, and has no official status. Importantly, as ULA is +random per definition, the chance of collisions is extremely low. It is fairly straight forward to +get a prefix from one of the RIRs. While that does cost some money, it is an activity that is not +the main charter of SixXS and will be expected to continue with the RIRs. + +## Timeline + +**2017-03-01**: T-14wk +Decision made by Jeroen and Pim to start the sunset project. + +**2017-03-06**: T-13wk +Communicate to PoP admins (e-mail, referencing intent and problem statement) + +**2017-03-13**: T-12wk +Communicate to PoP admins (e-mail, details (this doc)) + +**2017-03-20**: T-11wk +Wrap up feedback from PoP admins, prepare publication to the users. +Initial backup of SixXS PoPs completed. + +**2017-03-23**: T-11wk +Publish to SixXS website. +One-time mail to all users, noting the sunset date and pointing to rationale and FAQ. + +**2017-03-29**: T-10wk +Communicate and field response from IPv6 communities, social media, et al. + +**2017-04-17**: T-7wk +Due date for converting the SixXS website to a static replica, for posterity. + +**2017-05-29**: T-1wk +Convert [info@sixxs.net](mailto:info@sixxs.net) to an autoresponder pointing at rationale+FAQ. + +**2017-06-06: (Tuesday)** +**Turn off TIC and SixXSd on PoPs**, retire IPv6Gate, shut down whois server. + +**2017-06-12**: T+1wk: +Secondary backup of SixXS PoPs completed. + +**2017-06-19**: T+2wk: +Power off SixXS PoPs, IPv6Gate, return resources + +**2017-06-26**: T+3wk: + Destroy PII data (mysql database). + +**2017-07-01**: Close out the sunset project. diff --git a/content/services.md b/content/services.md index efadf63..ecbe01d 100644 --- a/content/services.md +++ b/content/services.md @@ -11,70 +11,64 @@ menu: {{< image width="15em" float="right" src="/assets/dwdm.png" alt="DWDM spectrum" >}} -Our network consists of routers and interconnections in two main sites in the -Zurich metro: eShelter (NTT) in Ruemlang (next to the airport), and Interxion -ZUR1 in Glattbrugg. These two locations are connected with dark fiber, and we -have access to several local loop providers in both locations. For example, we -can arrange connectivity to Colozueri, Equinix ZH4 and Equinix ZH5 directly, -and using our partners (such as IP-Max, Init7, Openfactory), domestically and -to most european cities. +Our network consists of routers and interconnections in two main sites in the Zurich metro: eShelter +(NTT) in Ruemlang (next to the airport), and Interxion ZUR1 in Glattbrugg. These two locations are +connected with dark fiber, and we have access to several local loop providers in both locations. For +example, we can arrange connectivity to Colozueri, Equinix ZH4 and Equinix ZH5 directly, and using +our partners (such as IP-Max, Init7, Openfactory), domestically and to most european cities. You can read more about our network in this [informative post]({% post_url 2021-02-27-network %}). ### IP Transit -We operate [[AS8298](https://as8298.peeringdb.com/)] which announces `AS-IPNG` -for ourselves and our transit customers. We're pretty firmly connected in and -around Zurich, with a 10Gbit link to SwissIX, CommunityIX and CH-IX. We have -a diverse set of transit providers which give us good reach to the world, -including via Cogent AS174, Hurricane Electric AS6939, and for strong european -presence, we receive transit from OpenFactory AS58299, Meerfarbig AS34549, and -IP-Max AS25091. +We operate [[AS8298](https://as8298.peeringdb.com/)] which announces `AS-IPNG` for ourselves and our +transit customers. We're pretty firmly connected in and around Zurich, with a 10Gbit link to +SwissIX, CommunityIX and CH-IX. We have a diverse set of transit providers which give us good reach +to the world, including via Cogent AS174, Hurricane Electric AS6939, and for strong european +presence, we receive transit from OpenFactory AS58299, Meerfarbig AS34549, and IP-Max AS25091. -Gaining access to this wealth of IPv4 and IPv6 coverage is as easy as finding -an L2 connection to one of our points of presence, establishing a BGP session -to us, and announcing your netblock(s). We'll take it from there! +Gaining access to this wealth of IPv4 and IPv6 coverage is as easy as finding an L2 connection to +one of our points of presence, establishing a BGP session to us, and announcing your netblock(s). +We'll take it from there! You can read more about our BGP capabilities in this [informative post]({% post_url 2021-02-27-network %}). ### Local Loop Ethernet -Apropos, getting onto the internet is pretty easy if you are in a commercial -colocation facility. Of course, any internet provider will offer various -quality IPv4 and IPv6 connections with or without a static IP address. However -getting from your house to the datacenter is often the most complicated and -expensive project. At IPng, we had this challenge too -- and considering -we solved it for ourselves, we can certainly also solve it for you! With our -residential last-mile ISP collaboration (for example, ConnectionPoint, Init7, -Solnet, and Swisscom BBCS), L2 services directly to your residence or office -become easily possible. +Apropos, getting onto the internet is pretty easy if you are in a commercial colocation facility. Of +course, any internet provider will offer various quality IPv4 and IPv6 connections with or without a +static IP address. However getting from your house to the datacenter is often the most complicated +and expensive project. At IPng, we had this challenge too -- and considering we solved it for +ourselves, we can certainly also solve it for you! With our residential last-mile ISP collaboration +(for example, ConnectionPoint, Init7, Solnet, and Swisscom BBCS), L2 services directly to your +residence or office become easily possible. ## Colocation -We operate a private colocation facility in Zurich Albisrieden. The facility -has 3x200A of power and about 60m2 of floor space. Hosting one or several -machines, including Layer2 connectivity either to your own home, or to the -main internet hubs of Zurich, are easily accomplished in our colocation -facility. If more space is needed, we are regulars in most all Swiss carrier -housing facilities, and can help broker a deal that is tailored to your -needs. +We operate a private colocation facility in Zurich Albisrieden. The facility has 3x200A of power and +about 60m2 of floor space. Hosting one or several machines, including Layer2 connectivity either to +your own home, or to the main internet hubs of Zurich, are easily accomplished in our colocation +facility. If more space is needed, we are regulars in most all Swiss carrier housing facilities, and +can help broker a deal that is tailored to your needs. -You can read more about how we built our own colocation from scratch in -this [informative post]({% post_url 2022-02-24-colo %}). +You can read more about how we built our own colocation from scratch in this [informative post]({% +post_url 2022-02-24-colo %}). ## Project Design / Execution {{< image width="15em" float="right" src="/assets/pdu19.png" alt="19 inch PDU" >}} -We design things, both logical and physical. Be it two dimensional or three -dimensional, as life long tinkerers, we have a fair bit of experience in -mechanical and electrical engineering. Of course, as a network business, -designing and deploying autonomous systems and networks of any size is our home -turf. Also fundamentally understanding how a network should perform, be it -throughput, bandwidth, latency or jitter and packet loss: we've seen it all, -from ADSL lines to 300km DWDM spans. +We design things, both logical and physical. Be it two dimensional or three dimensional, as life +long tinkerers, we have a fair bit of experience in mechanical and electrical engineering. Of +course, as a network business, designing and deploying autonomous systems and networks of any size +is our home turf. Also fundamentally understanding how a network should perform, be it throughput, +bandwidth, latency or jitter and packet loss: we've seen it all, from ADSL lines to 300km DWDM +spans. For some good examples, take a look at these case studies: * [Fiber7 on LiteXchange]({{< ref "2016-10-07-fiber7-litexchange" >}}) -* [SixXS Sunset]({% post_url 2017-03-01-sixxs-sunset %}) +* [SixXS Sunset]({{< ref "2017-03-01-sixxs-sunset" >}}) * [Coloclue Loadtesting]({% post_url 2021-02-27-coloclue-loadtest %}) + +There's many more papers and opinion pieces in our [[Articles]({{< ref "articles" >}})] section. +