swinog

swinog@lists.swinog.ch

7 participants
3000 discussions

DNSSEC Root KSK Rollover this weekend
by Oli Schacher 13 Oct '26

13 Oct '26

Hi everyone, Just a reminder that the next DNSSEC root Key Signing Key (KSK) rollover is coming up on 11 October 2026. For those operating DNSSEC-validating resolvers, it might be worth double-checking that your resolvers have picked up the new KSK-2024 trust anchor (key tag 38696) through standard software updates or RFC5011. There's a handy test provided by Cloudflare to check whether your resolvers are ready: https://dnstest.dev/ksk-2024/ Cheers, Oli

4 3

SwiNOG #42 - Agenda Published
by Simon Ryf 12 Oct '26

12 Oct '26

Dear SwiNOG community, The Agenda for SwiNOG #42 - Tuesday 20th & Wednesday 21st of October 2026 is published! https://www.swinog.ch/meetings/swinog42<https://www.swinog.ch/meetings/swinog42/> 📋 SwiNOG #42 - Agenda 📅 Day 1 - Tuesday, October 20 12:00 🍽 Lunch & Networking (60 min) 13:00 Welcome & Opening 13:10 Dominik Haenni | Zurich Forensic Science Institute Reality, Rewritten: AI as Forger and Investigator 13:55 Daniel Schatzmann Automating Target Discovery in the gNMIc Operator 14:20 Mischa Diehm | narrowin On-prem LLM Cluster for Network and Security Analyses 14:45 Remi Locherer | Arista Networks Networking for AI 15:10 ☕Coffee Break (40 min) 15:50 Simon Schlauri | Ronzani Schlauri Attorneys Internet Domain Blocking: Current Legal Situation and Outlook 16:20 Yannick Gautier | Nokia From Connectivity to Cyber Resilience: Defense in Depth 16:50 Marco Martinez | Swisscom Managing IP Allocation with an Open-Source DDI 17:15 Pascal Gloor | /dev/true Who are you? 17:25 Closing Day 1 17:30 🍽 Apéro & Dinner 19:00 🤖 Guided Museum Visit 📅 Day 2 - Wednesday, October 21 09:00 Welcome & Opening Day 2 09:05 Claudio Jeker | RSSF Beyond RPKI Origin Validation: BGP Roles & ASPA 09:30 Tobias Bühler | NetFabric From Lab to Production: The Hard Parts of Agentic NetOps 09:55 Alexander North | Swisscom The Cloud-Native Advantage: Intent-based Network Automation 10:20 ☕ Coffee Break (30 min) 10:50 Fabian Schulz | Swisscom The Accidental Platform Team: Kubernetes Operators 11:15 Martin Winter | NetDEF / FRRouting FRRouting Open Discussion 11:35 Fiona Weber | WDZ / Wobcom Small BNGs 12:00 Gianpaolo Del Matto | THE PHINTAGE COLLECTOR Retro Networks 12:20 Andrew Vieyra | CommunityRack.org CommunityRack - New Focus, New Projects, More Bits! 12:40 Thomas Fritz | Rheintal IX Rheintal IX Update 12:55 Arist Volger | SwissIX SwissIX Update 13:00 Closing Day 2 🍽 13:05 Lunch & Networking 🤝 13:30 1:1 Meetings & Personal Networking 📍 Location ENTER Technikwelt Solothurn Gewerbestrasse 4, 4552 Derendingen 🚌 Optional shuttle bus available from Solothurn railway station. 🎟 Registration For late registration - please contact us at swinog-core(a)swinog.ch Already a big "Thank You" to our Sponsors 🥇 Gold Sponsor SwissIX and supporters AWS Emitec AG Flexoptix Nokia 🛠 Tool Sponsor NIX.CZ Looking forward to seeing you all at SwiNOG #42!

1 0

Swisscom BBCS-F, XGS-PON packetloss resulting in slow TCP sessions?
by Benoit Panizzon 08 Oct '26

08 Oct '26

Hi Gang We are seeing an issue with one of our BBCS-F customers which we can not quite explain. So I wonder if you also experience the same issue with 'some' of your customers. * Swisscom Profile 1G/1G. * ZyXEL PM7300 Bridge (also swapped for Nokia Bridge or FritzBox) * PPPoE session terminated on Linux Notebook (also tested with Windows behind FritzBox). * Testing with iperf3 Result Upstream: ~900 Mbit/s as expected. Result Downstream: 1 TCP Session: ~280 Mbit/s not OK 5 TCP Session: ~500 Mbit/s not OK 10 TCP Session: ~800 MBit/s acceptable Iperf3 shows a slightly increased number of TCP retransmits. iperf3 UDP test with pushing 800Mbit/s shows about 0.2% packetloss. Well, this somehow explains why 1 TCP session does not get up to speed. Customer is working with an applications downloading large data junks from the cloud - using one TCP session at the time - of course he is not happy. Exact same set-up on another BBCS-F 1G/1G service, in a neighboring town reaches ~900Mbit/s in UP and DOWN with just one TCP session - less packetloss with UDP less retransmits. Case opened with Swisscom FAN-port was switched. Case closed. Issue got slightly better but still not acceptable. Case re-opened meeting with Swisscom/Cablex tech on customer site. He connects his test-device which shows 900Mbit/s Downstream. Our tech checks this test-device and finds out, it opens 100 concurrent TCP connections to a Swisscom Speed-Test servers - our tech asked to Swisscom tech to please re-test in a more realistic scenario, 1 to 2 TCP session. Swisscom tech does so, download speed drops to below 300 Mbit/s, upload speed is fine, confirming our measurements. So we persuaded Swisscom the issue is real, they will continue to investigate and hopefully find and fix the cause right? Case closed: Resolution: Test was performed by 'standard' Swisscom Speed-Test opening 100 concurrent TCP connections. Proof was provided that there is no speed issue with 'standard' customer behavior. Customer has to open multiple TCP connections to reach advertised speed which Swisscom considers to be the way Customers have to use their service. I managed to re-open the case to more deeply investigate, why this is the issue with this one customer and not with our reference service about 3km away reaching 900Mbit/s down with just one TCP connection. So out of curiosity: Do others also observe this 'one TCP connection slow because of slight packetloss' issue with some BBCS-F customers? Is there known cause and solution? Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

1 0

SwiNOG #42: full program online, registration closes Monday 09:00
by Roman Hochuli 08 Oct '26

08 Oct '26

Dear SwiNOG community, The full program for SwiNOG #42 is online: https://www.swinog.ch/meetings/swinog42/ The essentials: - When: Tuesday, October 20 (from 12:00) to Wednesday, October 21, 2026 - Where: Enter Technikwelt Solothurn, Gewerbestrasse 4, Derendingen - Fee: CHF 150 to 220 (incl. social event) - Registration closes: Monday, October 12, 09:00 The lineup (single track): - Tobias Bühler (NetFabric): From Lab to Production: The Hard Parts of Agentic NetOps - Gianpaolo Del Matto (The Phintage Collector): Retro Networks - Mischa Diehm (narrowin): On-prem LLM cluster for network and security analyses - Thomas Fritz (Rheintal IX): Rheintal IX Update - Yannick Gautier (Nokia): From Connectivity to Cyber Resilience: Defense in Depth for the Connected Enterprise - Pascal Gloor (/dev/true): Who are you? - Dominik Haenni (Zurich Forensic Science Institute): Reality, Rewritten: AI as Forger and Investigator - Claudio Jeker (RSSF): Beyond RPKI Origin Validation: what do we gain with RFC 9234 (BGP Roles) and ASPA - Remi Locherer (Arista Networks): Networking for AI - Marco Martinez (Swisscom): Managing IP Allocation with an Open-Source DDI - Alexander North (Swisscom): The Cloud-Native Advantage: Intent-based Network Automation - Daniel Schatzmann: Automating Target Discovery in the gNMIc Operator - Simon Schlauri (Ronzani Schlauri Attorneys): Internet Domain Blocking: Current Legal Situation and Outlook on the Current Revision of the Telecommunications Act - Fabian Schulz (Swisscom): The Accidental Platform Team: Kubernetes Operators at Swisscom - Andrew Vieyra (CommunityRack.org): CommunityRack: New focus, new projects, more bits! - Arist Volger (SwissIX): SwissIX: the mandatory 5' update before lunch - Fiona Weber (WDZ / Wobcom): Small BNGs - Martin Winter (NetDEF / FRRouting): FRRouting Open Discussion Day 1 ends with an apero, followed by dinner, networking and a guided tour of the Enter museum (social event ticket required). New this time: bilateral meetings on day 2 On the afternoon of the second day, we set aside dedicated time and space for bilateral meetings. To help you make the most of it, SwiNOG is using NIX.CZ Meet for the first time. It's a well-established meeting tool already used at many other industry conferences. You can see who's attending, request meetings and fix your slots in advance, so you arrive with a plan rather than hunting people down in the hallway. All registered participants will receive an invitation email for the tool soon, which is one more reason to register before Monday. Many thanks to NIX.CZ for providing the tool. Getting there: Solothurn is about an hour from Bern and 1h20 from Zurich. There's a shuttle bus from Solothurn station to the venue (CHF 20, add it during registration; regular public transport tickets aren't valid on it). Parking is available on site. Thank you to our sponsors SwiNOG is run by volunteers and stays affordable thanks to the support of our sponsors. A big thank you to: - Gold Sponsor: SwissIX - Supporters: Emitec AG, Flexoptix, Nokia - Tool Sponsor: NIX.CZ If you've been on the fence, now is the time, and bring your colleagues along. https://register.swinog.ch See you in Solothurn! SwiNOG Core Team

1 0

Hardware, Netzwerk abzugeben, 6 St. HPE P10115-B21 neuwertig
by Mueller Urs SBB CFF FFS 29 Sep '26

29 Sep '26

Hello / Hallo Wir haben aus einem Fehlkauf folgende Ware abzugeben: * 6 Stück HPE P10115-B21 Broadcom 57414 10/25GbE Dualport SFP28 OCP3 Adapter zB für HPE DL 3xx Gen 11 * Aus Originallieferung in Server ausgebaut, nie benutzt * In Antistatikbeuteln und Schachteln (der bei uns danach eingebauten BCM 57608) Angebote bitte direkt off liste. Wir sind ein verarmter Bundesbetrieb (Schuldenlast, siehe Suchmaschine) und brauchen Geld 😉 Grüsse, Urs SBB AG Konzernsicherheit Bollwerk 10, 3000 Bern 65 Mobil +41 79 433 21 67<tel:+41794332167> urs.bf.mueller(a)sbb.ch<mailto:urs.bf.mueller@sbb.ch> / www.sbb.ch<http://www.sbb.ch/> C2 - Intern: Diese Informationen sind vertraulich zu behandeln und dürfen nur im geschäftlichen Kontext verwendet werden. Eine Weitergabe an Dritte ist nur in Abstimmung mit der SBB zulässig. // C2 – Interno: Queste informazioni devono essere trattate in modo confidenziale e possono essere utilizzate solo in ambito aziendale. La trasmissione a terzi è consentita solo previo accordo con le FFS. // C2 – Interne: Ces informations doivent être traitées de manière confidentielle et ne doivent être utilisées que dans le contexte des affaires. Un transfert à des tiers est permis uniquement sous réserve de l’accord des CFF. // C2 - Internal: - This information is to be treated as confidential and may only be used for business purposes. Disclosure to third parties is only permitted with the prior agreement of SBB.

2 1

PCH 2026 global peering survey
by Bill Woodcock 29 Sep '26

29 Sep '26

tl;dr: the survey is at https://pch.net/survey Background: Every five years, beginning in 2011, PCH has conducted a comprehensive global survey characterizing Internet peering agreements. They are the only ones of their kind, and are relied upon not only by network operators, but also by legislators and regulators throughout the world to understand the Internet interconnection landscape. Our write-ups of the prior surveys can be found here: https://www.pch.net/resources/Papers/peering-survey/PCH-Peering-Survey-2011… https://www.pch.net/resources/Papers/peering-survey/PCH-Peering-Survey-2016… https://www.pch.net/resources/Papers/peering-survey/PCH-Peering-Survey-2021… …and video of the NANOG presentation of the 2016 results is here: https://www.youtube.com/watch?v=lPuoBmxyXMc At the time of the 2011 survey, we committed to repeating the survey every five years, to provide time-series data about the direction peering trends take. We’re now conducting the fourth iteration of the survey. Among other things, the surveys have helped establish a better understanding of trends in: • The increasingly uniform global norms of interconnection • National preferences within the network operator community for country of governing law • The long tail of small networks which don’t yet support IPv6 routing • The significance of multilateral peering agreements in the density of the interconnection mesh These findings, particularly the first, have been invaluable in giving regulators in the vast majority of the world’s countries a data-driven basis for refraining from prescriptively regulating Internet interconnection. They have demonstrated in objective terms that the Internet self-regulates in a way that’s more globally uniform and closely harmonized than any coordination of national regulatory bodies could accomplish. Participation: The survey is global in scope, and our goal is to reflect the diversity of peering agreements in the world. Your participation ensures that your norms and ways of doing business are represented accurately and proportionately in the dataset. If you don’t participate, the way you do business will be less well-represented in the data, and will seem less normal to regulators and policy-makers. We’re interested in large ISPs and small ISPs, ISPs in Afghanistan and in Zimbabwe, bilateral agreements and multilateral, private and public. Our intent is to be as comprehensive as possible. In 2011, the responses we received represented 41% of the world’s ISPs, across 96 countries; in 2016, 65% of the world’s ISPs, across 148 countries; in 2021, 76% of the world’s ISPs across 192 countries. Our aim is to be equally inclusive this year. Since our principal method of soliciting participation is via NOG mailing lists, I’m afraid many of you will see this message several times, on different lists, for which we apologize in advance. Privacy: In 2011, 2016, and 2021, we promised to collect the smallest set of data necessary to answer the questions, to perform the analysis immediately, and not to retain the data after the analysis was accomplished. In that way, we ensured that the privacy of respondents was fully protected. We did as we said, no data was leaked, and the whole community benefited from the trust that was extended to us. We ask for your trust again now as we make the same commitment to protect the privacy of all respondents, using the same process as was successfully employed the last three times. We are asking for no more data than is absolutely necessary. We will perform the analysis immediately upon receiving all of the data. We will delete the data once the analysis has been performed. The Survey: We would like to know your Autonomous System Number, and the following five pieces of information relative to each other AS you peer with: • Your peer’s ASN (peers only, not upstream transit providers or downstream customers) • Whether a written and signed peering agreement exists (the alternative being a less formal arrangement, such as a "handshake agreement") • Whether the terms are roughly symmetric (the alternative being that they describe an agreement with different terms for each of the two parties, such as one compensating the other, or one receiving more or fewer than full customer routes) • What jurisdiction of governing law is defined, if any • Whether IPv6 routes are being exchanged (this year, we’ll still assume that IPv4 are) The easiest way for us to receive the information is as a tab-text or CSV file or an Excel spreadsheet, consisting of rows with the following columns: Your ASN: Integer Peer ASN: Integer Written agreement: Boolean [true,1,yes,y] or [false,0,no,n] Symmetric: Boolean [true,1,yes,y] or [false,0,no,n] Governing Law: ISO 3166 two-letter country-code, or empty IPv6 Routes: Boolean [true,1,yes,y] or [false,0,no,n] For instance: 42 <tab> 715 <tab> false <tab> true <tab> us <tab> true <cr> 42 <tab> 3856 <tab> true <tab> true <tab> us <tab> true <cr> We need the ASNs so we can avoid double-counting a single pair of peers when we hear from both of them, and so that when we hear about a relationship in responses from both peers we can see how closely the two responses match, an important check on the quality of the survey. As soon as we've collated the data, we'll strip the ASNs to protect privacy, and only the final aggregate statistics will be published. We will never disclose any ASN or any information about any ASN. We'd like to finish collecting data in the first week of October, about two weeks from now. If you’re peering with an MLPA route-server, you’re welcome to include just the route-server’s ASN, if that’s easiest, rather than trying to include each of the peer ASNs on the other side of the route-server. Either way is fine. If all of your sessions have the same characteristics, you can just tell us what those characteristics are once, your own ASN once, and give us a simple list of your peer ASNs. If your number of peers is small enough to be pasted or typed into an email, rather than attached as a file, and that’s simpler, just go ahead and do that. If you have written peering agreements that are covered by non-disclosure agreements, or if your organizational policy precludes disclosing your peers, but you’d still like to participate in the survey, please let us know, and we’ll work with whatever information you’re able to give us and try to ensure that your practices are statistically represented in our results. If you're able to help us, please email me the data in whatever form you can. If you need a non-disclosure, we're happy to sign one. Finally, if there are questions you’d like us to try to answer when we analyze the data, please suggest them, and if there are any additional questions you’d like us to include in future iterations of the survey, please let us know so that we can consider including them in the 2031 survey. Please respond by submitting your survey at https://pch.net/survey or emailing it to me directly (woody(a)pch.net, not replying to the NOG mailing list), by the second week of October. Thank you for considering participating. We very much appreciate it, and we look forward to returning the results to the community. -Bill Woodcock Secretary General Packet Clearing House

1 0

CHNUG #4 – Rapperswil, August 26
by Severin Dellsperger 19 Aug '26

19 Aug '26

Hi all, At SwiNOG #41, I introduced CHNUG, the Swiss Network User Group. We're now hosting our fourth meetup on August 26 in Rapperswil, at OST. Expect three technical talks: * Network Monitoring with the gNMIc Operator | Roman Weber and Valentino Diller (OST) * Managing IP Allocation with an Open-Source DDI | Marco Martinez * What's Next for Nornir: Project Update and Roadmap | Damien Garros (OpsMill) The event is free to attend and includes a burger party afterwards. More info and registration: https://events.chnug.ch/event/5/chnug-4 Looking forward to seeing some of you there. Best, Severin Severin Dellsperger Senior Network and Research Engineer P central +41 58 257 44 99<tel:+41582574499> P direct +41 58 257 44 76<tel:+41582574476> severin.dellsperger(a)ost.ch<mailto:severin.dellsperger@ost.ch> OST – Eastern Switzerland University of Applied Sciences INS – Institute for Network and Security | Oberseestrasse 10 | 8640 Rapperswil | Switzerland | www.ost.ch<http://www.ost.ch>

1 0

Contact to mail.swisscom.com (or sharedit.ch / itoper.local) postmaster?
by Benoit Panizzon 31 Jul '26

31 Jul '26

Hi We have one customer with their MX on mail.swisscom.com. Since about two months, our customer experiences huge delays (we talk about days and even weeks) when receiving our emails (mostly affected: PDF Invoices but also happened with other simple text test emails without attachments). From what I see from a header of an affected email delayed 48 hours, supplied by the customer, the delay happens 'internally' between: mail.swisscom.com (sg007451.sharedit.ch) and pps.reinject (sg007430.itoper.local [127.0.0.1]) Our customer was not yet able to get a contact at Swisscom to explain the cause and to find the cause or how fix it (also because there seem to be several parties, including government involved in running this service and it's not clear which party is in charge. An request for help to the RIPE contact for the IP range remained unanswered. Have others observed similar issues? I could imagine all PDF emails somehow get quarantined and have to manually be release by 'some human', but our customer is not aware of such a functionality. Does anyone how know operates sharedit.ch or itoper.local and cold start an investigation? Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

2 1

### SwiNOG #41 (2026-04-28) - Call for Papers ###
by Simon Ryf 24 Jul '26

24 Jul '26

Dear SwiNOG community, Please forward me to whomever you think should know about our community and the upcoming event. This is the official Call for Paper email. Please submit your proposal via https://www.swinog.ch/cfp/ The 41st meeting of the Swiss Network Operators Group (SwiNOG) will be held in Berne on top of the Gurten on Tuesday April 28th, 2026. Location: https://wego.here.com/l/46.91963060309784,7.439032069847434 Important Dates for http://www.swinog.ch/meetings/swinog41/ 30.01.2026 Call for Papers 02.02.2026 Registration opens -> https://register.swinog.ch/ 29.03.2026 Publication of preliminary agenda 19.04.2026 Registration closes 24.04.2026 Deadline for all slides 28.04.2026 Meeting Day Topics for Presentations/Talks Please re-submit your paper if you're still up with a topic which you have submitted earlier. The number and length of presentations per session is not fixed, although we prefer it to be between 5 to 30 minutes. Here is a non-exhaustive list of typical SwiNOG meeting topics: * Security, DDOS Mitigation, * IPv6 * Open-Source- / GitHub projects * International view of the internet (incidents, outages, measurements) * Routing & Peering * Applications (DNS, Web, Network Virtualization, Orchestration, Monitoring etc.) * Takeaways from your projects / troubleshooting-sessions * Legal issues (BÜPF, etc.) * Telecommunication politics (Net Neutrality, Incumbent monopoly, etc.) * Off-Topic if you think the audience will enjoy Feel free to talk to us about any kind of topic and collaboration! Or you can always start a discussion on the list - I'm sure people join in. Or join our telegram group at https://t.me/SWINOG Language of Slides and Talks The whole day will be hold in English, therefore we kindly ask you to produce your presentation in English. Submission Guidelines * All submissions must have a strong technical bias and must not be promotional. * We also welcome lightning talks (3-5 Minutes). If entertaining – they can also be completely off-topic. * Presentations should be suitable for a target audience of technicians from varied backgrounds, working for companies whose sizes may vary considerably. * Presentation will be published (PDF) on the SwiNOG website after the event (if confirmed/permitted by the speaker). * On request we publish modified slides (removed confidential content, etc.) * Presentations should be suitable for a target audience of technicians from varied backgrounds, working for companies whose sizes may vary considerably. To submit a proposal for a presentation, please fill in the form at https://www.swinog.ch/cfp/ We also welcome suggestions for specific presentations which you feel would be valuable to the SwiNOG community and we try to chase a speaker for it. Greetings, Simon SwiNOG Core Team swinog-core(a)swinog.ch<mailto:swinog-core@swinog.ch> General Information (SwiNOG Community) The Swiss Network Operators Group (SwiNOG) is an informal group of people who are concerned with engineering and operation of the Swiss Internet. SwiNOG exists to enhance the quality of Internet services available in Switzerland. It does this by fostering the free exchange of technical ideas and information between different companies and organisations. SwiNOG is a community for professionals who are operating, designing, or researching the Internet. It provides a technical forum where those working on, with and for the Internet can come together to solve problems with every aspect of their (net)work. The meeting is designed to provide an opportunity for the exchange of information among network operators, engineers, researchers, and other professionals close to the network community. More information about SwiNOG can be found at http://www.swinog.ch<http://www.swinog.ch/> Information about the meeting will be published at http://www.swinog.ch/meetings/swinog41/ General Information (SwiNOG Organisation) The SwiNOG Organisation Association is a non-profit association under article 60 and further of the swiss civil law. It manages the SwiNOG community ressources (domain, web, mailing-lists, etc..) and organises SwiNOG meetings. Contact: SwiNOG Organisation 8000 Zurich Switzerland

1 1

BGP/RPKI hygiene checker + monitoring for small operators (free check, FR/EN)
by N&R consulting 22 Jul '26

22 Jul '26

Hi all, first post here from a neighbour in France, so a quick intro: I run Sentinelle Routage, a small French BGP/RPKI monitoring service aimed at small and mid-size operators (hijack/leak alerts, RPKI-invalid detection, ROA hygiene, loss of visibility). Two things that might be useful to this list: - A free, no-signup checker that grades an ASN's routing hygiene (ROA coverage, RPKI-invalids, overly permissive maxLength per RFC 9319, IRR consistency): https://sentinelle-routage.fr (EN available) - A sample of the monitoring report we generate (fictional network, RFC 5398/5737 resources): https://sentinelle-routage.fr/rapport-exemple.pdf Under the hood it runs on RIS data (RISwhois + RIS Live, used with attribution) and a self-hosted Routinator instance, no RIPEstat involved. Feedback from operators here is very welcome, especially on the maxLength/RFC 9319 warnings: too noisy, or useful? Some background on why we flag overly permissive maxLength: https://sentinelle-routage.fr/roa-maxlength.html Best, Abdelaziz El Borgi N&R Consulting / Sentinelle Routage https://sentinelle-routage.fr

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

swinog