- connect-wg - mailman.ripe.net

Re: [connect-wg] New on RIPE Labs: You’ve Got the Power: Sustainable Procurement and the RIPE Community
by Michael J. Oghia 02 Sep '20

02 Sep '20

Good points Michael, and that is also why I argue <https://labs.ripe.net/Members/michael_oghia/to-green-the-internet-we-need-r…> the RIPE community should take an explicit stance on the Right to Repair. Best, -Michael On Wed, Sep 2, 2020 at 3:01 PM Michael Richardson <mcr(a)sandelman.ca> wrote: > > J Scott Marcus <scott(a)scottmarcus.com> wrote: > > You would probably find some useful bits in a recent study of mine > on behalf > > of the European Parliament. > > > J. Scott Marcus (2020), “Promoting product longevity: How can the EU > product > > safety and compliance framework help promote product durability and > tackle > > planned obsolescence, foster the production of more sustainable > products, and > > achieve more transparent supply chains for consumers?”, study for > the IMCO > > Committee of the European Parliament. > > > https://www.europarl.europa.eu/RegData/etudes/STUD/2020/648767/IPOL_STU(202… > > For the rest who did not read it yet: > > "Some users always want to have the latest technology, but there is good > reason to believe that a great manyof these mobile devices are replaced (1) > because the battery has died, and cannot be replaced by the user; or (2) > because the screen has cracked, and cannot be replaced by the user, or (3) > because the manufacturer no longer is willing or able to support the > software. " > > with the caution that: > > "These same considerations hint at reasons why any prolongation of product > lifetime for passenger vehicles – a potential initiative which, > interestingly, is not visible in the Circular Economy Action Plan – might > prove to be counter-productive at this particular point in time. Any > prolongation of the lifetime of existing vehicles risks a slight delay in > the > take-up of new electric vehicles and self-driving vehicles, thus potential > delaying a technology evolution that produces benefits of its own. " > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | IoT > architect [ > ] mcr(a)sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > >

2 2

Re: [connect-wg] New on RIPE Labs: You’ve Got the Power: Sustainable Procurement and the RIPE Community
by Michael J. Oghia 31 Aug '20

31 Aug '20

Dear Michael, Thank you very much for your kind words and for this absolutely critical insight. You're right that the relatively short lifecycle of many devices is indeed a primary driver of the issue. These are such great examples as well. If it's not too much trouble for you, would you be able to add this as a comment on the post itself so that we can keep such good comments as yours centralised in one place? I don't have much to add to your comments other than fully agreeing with you and wondering if the RIPE community can work together to lobby for changes – assuming that's something we're both able and willing to do. Best, -Michael __________________ Michael J. Oghia | Advocacy & Engagement Manager Global Forum for Media Development (GFMD <https://gfmd.info>) Belgrade, Serbia (UTC+2) | Twitter <https://www.twitter.com/MikeOghia> | LinkedIn <https://www.linkedin.com/in/mikeoghia> GPG: E95D 2127 0D45 77D3 4D43 4D5A E3BA 6F23 301D 7082 On Fri, Aug 28, 2020 at 10:21 PM Michael Richardson <mcr(a)sandelman.ca> wrote: > > Thank you for this. > I think that one of the key things to reducing e-waste is to keep devices > in > productive use longer. The smartphone cycle is largely being driven by > planned obsolescence through lack of software updates. While few of us > here > are in the smartphone business, we see the same thing with CPE devices. > > No software updates means poor security, which pushes for replacement of > the > devices. > More capable devices can sustain more updates, but cost more up-front, > and there still very little relationship between price paid and number of > years of supported software updates. At least, I believe this anecdotally. > It would be nice if we had survey data to prove or disprove this belief. > Perhaps RIPE along with some of the entities you mentioned might be able to > do a confidential survey of ISPs in order to summarize the results? > > EN 303 645 and upcoming UK legislation requires that the support time for > devices to be made clear at point of purchase. See > https://www.iotsecurityfoundation.org/keep-software-updated/ for many > references. (Yes, I'm the presenter for the webinar, the first of which was > this morning) > > While the nic.cz Turris system is well supported, and very capable, I'm > not > any influence on big ISP purchasing. > What kind of software support lifespans are ISPs able to contract? > While many RIPE clueful people know about, deploy and contribute to > openwrt, > it does not seem to show up in a supported way in devices that I see either > big or small ISPs deploying. The big ones don't seem to care. The small > ones can't afford to take a risk. > > Years ago, it was the common that an ISP would buy some 12-port switching > device for it's core, and two years later (when it was too slow), would > migrate it from the core to an access aggregator, and then two years later, > it might find a few more years service as internal lab equipment, or being > used for a multi-tenant CPE. I learnt this as a switch (chip) designer. > Is this still a thing? > > In my more recent (2014-era) hands-on ISP experience, this was no longer a > thing, because the devices had all become far too specialized. Maybe SDN > is > changing this? Are there best practices in making purchase decisions that > support this migration of equipment? > {I'm reminded of: https://www.youtube.com/watch?v=NQjHJKNyoUE } > > Michael J. Oghia <mike.oghia(a)gmail.com> wrote: > > I'm happy to share an article that Mirjam and I just published on > RIPE Labs > > about sustainable procurement practices: > > > > https://labs.ripe.net/Members/michael_oghia/you-ve-got-the-power-sustainabl… > > > I wanted to post it here because I think it's relevant to this group > as > > operators, managers, and others. I'm keen to hear your thoughts, and > > encourage you to leave comments on the article so we know how to > best take > > this forward (and also gauge interest). > > > Have a good weekend,, > > -Michael > > __________________ > > > Michael J. Oghia | Advocacy & Engagement Manager > > Global Forum for Media Development (GFMD <https://gfmd.info>) > > Belgrade, Serbia (UTC+2) | Twitter < > https://www.twitter.com/MikeOghia> | > > LinkedIn <https://www.linkedin.com/in/mikeoghia> > > GPG: E95D 2127 0D45 77D3 4D43 4D5A E3BA 6F23 301D 7082 > > > ---------- Forwarded message --------- > > From: Mirjam Kuehne <mir(a)ripe.net> > > Date: Fri, Aug 28, 2020 at 2:15 PM > > > Dear colleagues, > > > Buying equipment can have an impact on environmental sustainability. > > Michael Oghia writes about issues surrounding sustainable procurement > > and how the RIPE community has the potential to make a difference: > > > > https://labs.ripe.net/Members/michael_oghia/you-ve-got-the-power-sustainabl… > > > Kind regards, > > Mirjam Kühne > > RIPE NCC > > > ---------------------------------------------------- > > Alternatives: > > > ---------------------------------------------------- > > _______________________________________________ > > connect-wg mailing list > > connect-wg(a)ripe.net > > https://lists.ripe.net/mailman/listinfo/connect-wg > > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | IoT > architect [ > ] mcr(a)sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > > > > > >

2 1

Re: [connect-wg] New on RIPE Labs: You’ve Got the Power: Sustainable Procurement and the RIPE Community
by Michael Richardson 28 Aug '20

28 Aug '20

Thank you for this. {resending from subscribed address} I think that one of the key things to reducing e-waste is to keep devices in productive use longer. The smartphone cycle is largely being driven by planned obsolescence through lack of software updates. While few of us here are in the smartphone business, we see the same thing with CPE devices. No software updates means poor security, which pushes for replacement of the devices. More capable devices can sustain more updates, but cost more up-front, and there still very little relationship between price paid and number of years of supported software updates. At least, I believe this anecdotally. It would be nice if we had survey data to prove or disprove this belief. Perhaps RIPE along with some of the entities you mentioned might be able to do a confidential survey of ISPs in order to summarize the results? EN 303 645 and upcoming UK legislation requires that the support time for devices to be made clear at point of purchase. See https://www.iotsecurityfoundation.org/keep-software-updated/ for many references. (Yes, I'm the presenter for the webinar, the first of which was this morning) While the nic.cz Turris system is well supported, and very capable, I'm not any influence on big ISP purchasing. What kind of software support lifespans are ISPs able to contract? While many RIPE clueful people know about, deploy and contribute to openwrt, it does not seem to show up in a supported way in devices that I see either big or small ISPs deploying. The big ones don't seem to care. The small ones can't afford to take a risk. Years ago, it was the common that an ISP would buy some 12-port switching device for it's core, and two years later (when it was too slow), would migrate it from the core to an access aggregator, and then two years later, it might find a few more years service as internal lab equipment, or being used for a multi-tenant CPE. I learnt this as a switch (chip) designer. Is this still a thing? In my more recent (2014-era) hands-on ISP experience, this was no longer a thing, because the devices had all become far too specialized. Maybe SDN is changing this? Are there best practices in making purchase decisions that support this migration of equipment? {I'm reminded of: https://www.youtube.com/watch?v=NQjHJKNyoUE } Michael J. Oghia <mike.oghia(a)gmail.com> wrote: > I'm happy to share an article that Mirjam and I just published on RIPE Labs > about sustainable procurement practices: > https://labs.ripe.net/Members/michael_oghia/you-ve-got-the-power-sustainabl… > I wanted to post it here because I think it's relevant to this group as > operators, managers, and others. I'm keen to hear your thoughts, and > encourage you to leave comments on the article so we know how to best take > this forward (and also gauge interest). > Have a good weekend,, > -Michael > __________________ > Michael J. Oghia | Advocacy & Engagement Manager > Global Forum for Media Development (GFMD <https://gfmd.info>) > Belgrade, Serbia (UTC+2) | Twitter <https://www.twitter.com/MikeOghia> | > LinkedIn <https://www.linkedin.com/in/mikeoghia> > GPG: E95D 2127 0D45 77D3 4D43 4D5A E3BA 6F23 301D 7082 > ---------- Forwarded message --------- > From: Mirjam Kuehne <mir(a)ripe.net> > Date: Fri, Aug 28, 2020 at 2:15 PM > Dear colleagues, > Buying equipment can have an impact on environmental sustainability. > Michael Oghia writes about issues surrounding sustainable procurement > and how the RIPE community has the potential to make a difference: > https://labs.ripe.net/Members/michael_oghia/you-ve-got-the-power-sustainabl… > Kind regards, > Mirjam Kühne > RIPE NCC > ---------------------------------------------------- > Alternatives: > ---------------------------------------------------- > _______________________________________________ > connect-wg mailing list > connect-wg(a)ripe.net > https://lists.ripe.net/mailman/listinfo/connect-wg -- Michael Richardson <mcr+IETF(a)sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-

1 0

New on RIPE Labs: You’ve Got the Power: Sustainable Procurement and the RIPE Community
by Michael J. Oghia 28 Aug '20

28 Aug '20

Hi everyone, I'm happy to share an article that Mirjam and I just published on RIPE Labs about sustainable procurement practices: https://labs.ripe.net/Members/michael_oghia/you-ve-got-the-power-sustainabl… I wanted to post it here because I think it's relevant to this group as operators, managers, and others. I'm keen to hear your thoughts, and encourage you to leave comments on the article so we know how to best take this forward (and also gauge interest). Have a good weekend,, -Michael __________________ Michael J. Oghia | Advocacy & Engagement Manager Global Forum for Media Development (GFMD <https://gfmd.info>) Belgrade, Serbia (UTC+2) | Twitter <https://www.twitter.com/MikeOghia> | LinkedIn <https://www.linkedin.com/in/mikeoghia> GPG: E95D 2127 0D45 77D3 4D43 4D5A E3BA 6F23 301D 7082 ---------- Forwarded message --------- From: Mirjam Kuehne <mir(a)ripe.net> Date: Fri, Aug 28, 2020 at 2:15 PM Dear colleagues, Buying equipment can have an impact on environmental sustainability. Michael Oghia writes about issues surrounding sustainable procurement and how the RIPE community has the potential to make a difference: https://labs.ripe.net/Members/michael_oghia/you-ve-got-the-power-sustainabl… Kind regards, Mirjam Kühne RIPE NCC

1 0

GR-IX drops RPKI invalids
by Michael Oikonomakos 06 Jul '20

06 Jul '20

Dear all, It has been a long journey but thankfully it has come to an end!!! We are happy to announce that as of today (06/07/2020) GR-IX route servers drop RPKI invalids for both our infrastructures in Athens & Thessaloniki. GR-IX [1] is a neutral and independent Internet Exchange in Greece, owned and operated by GRNET [2] (the Greek NREN). Please let us share with you the brief version of the story behind it and any lessons learned. - GRNET was an early supporter of RPKI. It started by signing ROAs for GRNET and their customers (all Greek Universities and Research Institutes). Moreover, it performed marking on each prefix received for further statistical / monitoring process. In the early days, GRNET was not dropping RPKI invalids, but put those prefixes with lower priority in their routing table. - GRNET & GR-IX were early supporters of MANRS [3] and successfully became a member of MANRS as a Network Operator & IXP respectively. - As of 10/2019, GRNET decided to start dropping invalid IPv4 and IPv6 RPKI prefixes received from GR-IX peerings and from GRNET upstream. No major issues were reported until now. - As of today, GR-IX drops invalid IPv4 & IPv6 RPKI prefixes on their route servers. We are using the BGP large communities proposed by euro-ix [4] in order to mark the prefixes accordingly. We noticed no prefix with RPKI invalid status which hasn't already been filtered by our route servers due to our strict IRRDB filtering. We would like to thank all our members (GRNET & GR-IX ones) for their help and support in this effort - either via simply signing their ROAs, or by participating in our tech mailing list and discussions we had during various fora. Internet was built of smaller or bigger ecosystems such as ours in Greece, in which we take great pride of its vibrant participation and technical expertise and are happy of being part of it. We do hope you’re staying safe and healthy during these hard times and wish you a great summer. Should you need any further information, please do contact us. Best regards, Michalis [1]: https://www.gr-ix.gr <https://www.gr-ix.gr/> [2]: https://grnet.gr/en/ <https://grnet.gr/en/> [3]: https://www.manrs.org <https://www.manrs.org/> [4]: https://www.euro-ix.net/en/forixps/large-bgp-communities/ <https://www.euro-ix.net/en/forixps/large-bgp-communities/>

2 1

To Green the Internet, We Need RIPE
by Michael J. Oghia 29 Jun '20

29 Jun '20

Hi everyone, I wrote a post <https://labs.ripe.net/Members/michael_oghia/to-green-the-internet-we-need-r…> for RIPE Labs drawing on lessons from a plenary session on ICT sustainability that I co-moderated at EuroDIG earlier this month. It offers concrete suggestions and explains why, as operators and managers, you're at the forefront of the endeavour to make the Internet more sustainable. Happy to discuss in case you have questions or would like additional resources. Best, -Michael Oghia ---------- Forwarded message --------- From: Mirjam Kuehne <mir(a)ripe.net> Date: Mon, Jun 29, 2020 at 4:14 PM Subject: [ripe-list] New on RIPE Labs: To Green the Internet, We Need RIPE To: RIPE List <ripe-list(a)ripe.net> Dear colleagues, What can you do - as a network operator and as a user - to work towards a sustainable Internet? Read Michael Oghia's RIPE Labs article on why support from the RIPE community is essential for a vision of a greener ICT ecosystem to succeed: https://labs.ripe.net/Members/michael_oghia/to-green-the-internet-we-need-r… Kind regards, Mirjam Kühne RIPE NCC

1 0

Follow up on today's Connect-WG at Ripe80
by Will van Gulik 13 May '20

13 May '20

Hi Everyone, Following up on our Connect session, here are the links that we mentionned during the session : Related to presentation #2 (Will van Gulik) : - Original court document in German : -- https://drive.google.com/open?id=13nMQkj1abja-3cPBiQWiZaybsFIUkWa5 - Automated tool translation in French : -- https://www.as2613.net/2020_Court_case_Init7_vs_Swisscom-DeepL_Translation_… Related to presentation #5 (Remco Van Mook) : Anita Nikolich suggest the following link : -- Vint Cerf had a nice opinion piece this week that was very objective: https://thehill.com/opinion/technology/497053-the-internet-isnt-broken-but-… Related to presentation #6 (Massimo Candela) : Vesna Manojlovic pointed us to some studies posted on the Ripe Labs : -- https://labs.ripe.net/covid19 -- https://labs.ripe.net/Members/romain_fontugne/network-delays-in-times-of-co… -- https://ihr.iijlab.net/ihr/en-us/covid19 Related to presentation #8 (Nurani Nimpuno) : Surveys related to the peering toolbox : -- For Networs - https://www.surveymonkey.co.uk/r/fornetworks -- For IXPs - https://www.surveymonkey.co.uk/r/forixps And if you didn't do so yet, please rate the talk ! Be safe everyone, Will van Gulik Connect-WG co-chair

1 0

Agenda for Connect-WG @ RIPE 80
by Florence Lavroff 11 May '20

11 May '20

Dear friends of the Connect WG, We are about about one week away from our first virtual Connect Working Group, which will take place on Thursday, May 14th from 1 PM to 2.45 PM local time with a 15-min coffee break from 1.45 to 2 PM. Thanks a lot for the feedback so far about the content you'd like we cover during this session. Here is our draft agenda : 1. Opening (Welcome, scribe appointment, agenda, proposed session format) - 3 min 2. Peering (dis)agreements during covid-19 times - Will Van Gulik, 15 min 3. The challenge of remote hands under covid-19 restrictions, Part I - 25 min 4. Coffee break 5. The challenge of remote hands under covid-19 restrictions, Part II - 20 min 4. Covid-19 IXP update - Bijal Sanghani, Euro-IX, 15 mins 5. Closure - 3 mins Do not forget to register for the meeting to receive your Zoom invitation. Stay safe and healthy everyone ! Best regards, Florence, Remco and Will Connect-WG co-chairs -- Florence Lavroff / lavroff(a)google.com / +31 6 11 01 55 80 Infrastructure Acquisition and Interconnect / Google EMEA

2 2

My response to Ronald Guilmette
by Elad Cohen 17 Apr '20

17 Apr '20

Hello Everyone, Please forgive me for not writing an official response in first set of Ronald's online madness months ago, I was out of hospital after full anesthesia and it took me months to get back to myself. Ronald is misery person with nothing and with no one in his life, the only joy that he have in his life - is for him to serve as the front person of the illegal anonymous organization "The Spamhaus Project". Here is a presentation that "The Spamhaus Project" wrote on themselves (in the following link) and according to it Spamhaus is an illegal anonymous organization - they receive a massive amount of illegally obtained privacy data of internet users from internet companies and internet organizations on a regular basis - and then they share it in illegal way (without any warranty) with law enforcement agencies. https://www.scribd.com/document/445894312/Spamhaus-Illegal-Private-Data-Vio… Ronald doesn't deny himself being part of "The Spamhaus Project", not only that - but his old friend Hank Nussbacher is also part of the illegal anonymous organization "The Spamhaus Project", Hank reminds me Judas Iscariot - Hank obviously have other interests - it is very sad to see a person at the age of Hank acting like a little child. All the few reports that were made were made by reporters which are connected to "The Spamhaus Project" and that are part of "The Spamhaus Project" - not only that, the source of the media reports is a person in "The Spamhaus Project" which is the owner of that illegal twitter account: https://twitter.com/underthebreach , that person is a criminal according to his own words in his own twitter account - and that person is also a master of cyber influence operations (just like what Coconut Guilmette and Cheerleader Nussbacher are doing here, to influence public opinion without any single proof) - and the owner of that twitter account is also an employee of the israeli-based company GeoEdge which financially benefit from that media report because they are a direct competitor of the company using the exact same netblock, so now I'm explaining to you that that root of this all fake story is just business competition, and in addition Coconut Guilmette also attacked the Israeli-based company Divinetworks in Nanog (Coconut Guilmette searched an unreasonable way why they received a specific grant from a global world organization and also defamed them) - so here is why he did it - the Israeli-based company Divinetworks is also a direct competitor of the Israeli-based company GeoEdge - that their employee is a criminal and the owner of the illegal twitter account https://twitter.com/underthebreach and also the "source" for the fake few media reports. In the following link you can see how a high manager in GeoEdge is highly proud in how customers attracted to him after the "low value" of competitors, if only the world would knew how that company does business. https://imgur.com/7DF1NSP That company GeoEdge is not only a criminal company in the way that they do business (because their criminal employee in "The Spamhaus Project" is the one pumped Coconut Guilmette proof-less ideas), but that company is also a criminal in the way that they are tax-evading since 2005 (they are registered in Cyprus with fake-single-owner abroad while they have more actual hidden owners in Israel that didn't pay any tax for their income since 2005, and one of the registered owners is using an international fake name and he is a professional money-laundering person, not only for that Israeli company). They (Coconut Guilmette, Cheerleader Nussbacher and their mob friends at "The Spamhaus Project") are very very afraid of me releasing all the information that I found out on the illegal anonymous organization "The Spamhaus Project" - and that is the only reason that they are attacking me personally in such way, they are trying to ruin my good name - but they didn't succeed and they will not succeed - because anyone that knows me and anyone that will personally know me - will know what they are trying to do and that what they are writing is 100% false. All the personal attack against me - is only because I dared to stood up against "The Spamhaus Project" which is intimidating and hurting many businesses online, and I would and will do it again and again and again, I'm not the kind of a misery bendover jew like Hank that will sell his values and his being for a title, a group acceptance or a few cents. Coconut Guilmette, is not only a sick person, in body and mind, but also a racist and an antisemitic, you can see in the following links his stereotypical mindset: https://imgur.com/AcmgwEX (Coconut Guilmette opinion on all Dutch people as a whole - "Dutch are any more inclined toward cybercrime") https://imgur.com/WUZvdNJ (Coconut Guilmette opinion on all Colombian Network Operators usage of the internet as a whole - "Undoubtedly drug smuggling over HTTP") https://imgur.com/a/1ULfVEC (Coconut Guilmette opinion on the City of Chicago including all of its citizens as a whole - "American city most known for its high ideals and consistantly ethical behavior, Chicago") https://imgur.com/AQCmZlk (Coconut Guilmette identified as racist in Nanog) https://imgur.com/a/Rzrbxkz (Coconut Guilmette identified as antisemitic in Nanog) Besides the above links, Coconut Guilmette is specifically calling me with two words and here he is quoting Shakespeare: https://imgur.com/AcmgwEX , the two words that Coconut Guilmette is calling me are being used in Shakespeare litrature to identify jews in an antisemitic way, Coconut Guilmette is an antisemitic, I'm very sorry to write it but Ripe is not a decisive organization towards racism or antisemitism, the Tone in Ripe management and in Ripe board and in this working group co-chairs, is a very narrow tone that only reflect the good of the people in their positions, Ripe board & management are not taking any actions for Ripe to be a multi-culture multi-national unpolitical organization that it needs to be with the tolerance to anyone and with the decisive intolerance to racism or antisemitism. The encouragement of Cheerleader Nussbacher is even worst because Cheerleader Nussbacher is encouraging someone which is a racist and an antisemitic. Hank, how more self-hating jew can you be ? to support such person only to be part of an illegal anonymous organization ? to support racism ? to support antisemitism ? And to the rest of the community, anyone that wrote to this person - "nice story, but you could say it in other words" - you are a lowlife as Hank is, you don't treat a racist or an antisemitic person with tolerance, period. Ripe is a RIR which is spread over 3 continents over many countries, Ripe members are different from each other by all means, I would expect Ripe community not to tolerate racism in any way and when Ripe members see it - to stand up - like I dared to stand up against "The Spamhaus Project". Ron, seeing a person at your age that knows to get attention only by using racism and antisemitism is sad, but seeing the lowlife Judas Iscariot cheerleading your mental illness is sadder. Here are only some of the real identities of the people behind "The Spamhaus Project": "Rob Shultz" - Rob McEwen (https://www.invaluement.com/) "Thomas Morrison" - Daniel R. Thomas (https://personal.cis.strath.ac.uk/d.thomas/) "Pete Dawes" - Ildiko Pete (https://www.cl.cam.ac.uk/~ip358/) "Vincent Hanna" - Vincent Schonau of Open-Xchange (https://www.linkedin.com/in/vincentschonau/) "Milly Fawcett" - Kelly Molloy of FarSight Security (https://www.linkedin.com/in/kelly-molloy-b886442/) Among others Commericial companies behind "The Spamhaus Project": ThreatSTOP FarSight Security Fastly Cymru Among others Keep on playing with me Coconut Guilmette and Cheerleader Nussbacher and I guarantee to you that the full list will be written here, you can hurt me as much as you please - I am not boneless and will not fold like Hank "Judas Iscariot" Nussbacher. The only reason that Coconut Guilmette returned to life in this thread - is because I wrote two days ago the real identity of "Rob Shultz" (which is Rob McEwen of https://www.invaluement.com/ ) to the co-chairs of this working group with CC to Ripe Board and to Ripe Management, I asked for the initial post of lies of Coconut Guilmette to be removed and I showed to them the relation of one of the current co-chairs of that working group to the illegal anonymous organization "The Spamhaus Project" which the poster Coconut Guilmette is related to it too. (also in the past there was a co-chair of that working group which is part of "The Spamhaus Project", Richard D G Cox, as you can see in his presentation that I linked to it above) That is the only reason (that I revealed that "Rob Shultz" from "The Spamhaus Project" is Rob McEwen) that Coconut Guilmette and Boneless Nussbacher are personally attacking me, not only that - but soon you will also see a new fake media report about me from the same reporter that used the criminal https://twitter.com/underthebreach as his source - all of it (like it was then and like they are trying to do now) - is to maneuver the subject of who are the real people behind "The Spamhaus Project" and to which internet companies and internet organizations they are connected to. "The Spamhaus Project" is an illegal anonymous organization and an unregulated organization, by being unregulated it is abused by the some of the members of it for making money, without any supervision, for example the criminal which is the owner of the illegal twitter account https://twitter.com/underthebreach that did what it did only that GeoEdge will earn a few more cents, such as Laura Atkins from WordToTheWise which is selling a Spamhaus listing removal service (https://wordtothewise.com) such as Vincent Schonau (AKA "Vincent Hanna" of "The Spamhaus Project") from Open-Xchange, a company that Spamhaus are attacking its competitors, and there are many more Spamhaus members that are using Spamhaus for their financial benefits. "The Spamhaus Project" - by being unregulated and unsupervised - is also being used as tool to attack business competitors, this is something that should wake up each and every member of the internet community. Hank, why do you let Coconut Guilmette to do the hard work for you (of defaming me) ? because you know that he have nothing in his life and a lawsuit against him will not result any financial aid ? why are you abusing his mental illness ? you know that he is not fine, why don't you help him like a good old friend ? Go ahead and write what Ron is writing so I will be able to sue you locally in Israel (I'm willing to pay you 100,000 NIS if you are right in a single thing that you wrote or that you will write against me, are you willing to do the same ? are you willing to put your money where your words are? or are you boneless that can only exploit the state of your old friend? ) I respect Ripe NCC and Respect all the members of Ripe Anti-Abuse Working Group. (P.S.: you can recognize now any member of "The Spamhaus Project" that will jump now, if he will attack me or support Ron, you can just ask him a simple question - "show us a single proof" - and you will see that no proof will be displayed, because all of it is part of an illegal "cyber influence operation" by "The Spamhaus Project" pumped by the criminal https://twitter.com/underthebreach) Respectfully, Elad

1 0

how to approach some IX resources
by Eric Andrei Băleanu | InterLAN 02 Apr '20

02 Apr '20

Hello, It seems like these days we have more time to discuss. We would like to have some input from the community about your approach regarding some IX resources. Backup ports: commonly the ISP has an aditional router connected to the backup port, in a switch other than the one where the main port is connected, with an additional configuration (another pair of IPv4/v6 adresses). Question: Do you permit balanced traffic between the main port and the backup port? Or the backup port is allowed to be use only when the main port is down? Aggregated ports: The ISP has N x 1G or N x 10G ports connected to IXP platform, same switch, LACP config. Question: Do you treat aggregated ports as "one" port? E.g. 2 x 1G ports are one 2G port? Or 2 x 10G ports are one 20G port? Please share your experiences, keep safe and stay healthy. Regards, Eric Andrei Băleanu InterLAN Internet Exchange 8 Cezar Bolliac Street, Bucharest 030912, 3rd District Phone: +40 31 710 2428 Mobile: +40 733 999 069 E-mail: eric.baleanu(a)interlan.ro <mailto:eric.baleanu@interlan.ro> www.interlan.ro <http://www.interlan.ro/> www.ronog.ro <http://www.ronog.ro/>

1 0

virtual session at RIPE 80
by Florence Lavroff 27 Mar '20

27 Mar '20

Dear friends of the Connect-WG, As you may all know by now, RIPE 80 will be a virtual meeting. While we are still working out the logistics of it with our fellow RIPE chairs, we'd like to get your feedback on what topics you'd like to discuss under what format and how long this virtual session should ideally take. We consider maintaining our 1.5 hour slot for the moment, unless you propose otherwise. We'd also like to suggest as a main topic for the working group a discussion session around the impact of covid-19 on traffic, including but not restricted to the role of IXPs during the crisis. Feel free to let us know your thoughts, Stay safe, healthy and wash your hands, Best regards, Florence, Remco and Will Connect-WG co-chairs -- Florence Lavroff / lavroff(a)google.com / +31 6 11 01 55 80 Infrastructure Acquisition and Interconnect / Google EMEA

4 3

New on RIPE Labs: Down the Black Hole: Dismantling Operational Practices of BGP Blackholing at IXPs
by Mirjam Kuehne 07 Dec '19

07 Dec '19

Dear colleagues, For those who missed Marcin Nawrocki's presentation at RIPE 79, the summary of this research is now available on RIPE Labs: Down the Black Hole: Dismantling Operational Practices of BGP Blackholing at IXPs https://labs.ripe.net/Members/marcin_nawrocki/down-the-black-hole-dismantli… Kind regards, Mirjam Kühne RIPE NCC

2 1

Fwd: Re: BEREC consultation: contribution
by Steve Nash 13 Nov '19

13 Nov '19

I have only partially absorbed all aspects of the BEREC document and EU Article61, but my impression is of some important missing elements. In particular, I have not noticed references to co-habitation of multiple NTP in one customer site. The subject of resilience seems missing. BEREC has given us a simple model on which to comment, with three levels of NTP. Rather than defining what an NTP must always be, I prefer to consider what a customer needs from the NTP regardless of its logical location. Given that we are RIPE, and given the absence of any bidirectional Public Data Communication Network other than the Internet, I focus my comments accordingly. Summary Whatever the point of delivery of the Network connection, there must be clear signalling of whether or not the provision of Network connection is functional. For Internet Access the NTP must indicate the status of its connection to the Internet. The form of the indication is considered next for each of the BEREC logical Termination Points. *BEREC connection point C:* (Where the NTP has a routing function or NAT, IP aware) The NTP must indicate via its customer port, using IETF standard routing protocol, what connections it is offering /{list of minimum customer selectable protocols?}/. It must withdraw those routing announcements as quickly as the standard allows in the event that its peer router in the network becomes unavailable. *BEREC connection point B:* (Where the connection is provided at a modem port, Ethernet or WiFi) The network must provide signalling of its status to the user. The user must be provided with: * visibility of the adjacent router(s) by routing protocol announcements from the operators router(s). The list of offered routing protocols being a required part of the service description. * the IP address delegated by the operator for the CPE, manually or by DHCP. * the permanence of the IP address delegation (Static or Dynamic) * the IP address of the adjacent router(s) in the provider's network, to enable security filtering *BEREC connection point A:* (Where the connection is by wired, optical or wireless Ethernet) The Network must offer DHCP for the customer's delegated address, and the address of the available Network router. The Network may offer IP routing protocols, as for connection point B. The physical Signal must be withdrawn at the physical layer when the Network is otherwise unable to communicate loss of routes ( for comparison consider removal of dial tone). *Other Requirements:* 1/ In cases B and C, user-configuration of the characteristics of the user port must be supported. Including Local MAC address, Local IP address, Local default router, Local routing protocol, as applicable. 2/ It must be contractually clear whether an Internet Connection service at an NTP is fully open, or in some way restricted.A fully open Internet Connection will have a public IP address capable of end to end communication with any other public Internet address on the same version of IP. This would facilitate the customer in supporting an Internet Server, if they so choose. Restrictions that make the connection less than a fully open Internet connection must be disclosed in the documentation of the connection service, and include: * Network Address Translation, either in the network (CGN) or on supplied NTP. * Blocking of access to some Internet addresses (as has sometimes been the case for open DNS resolvers). 3/ Power Supply resilience for network devices becomes increasing important. Consideration should be given to regulation of common low power battery backup supply connection for all NTP. Rationale Most homes in the EU have more than one Network by which to access the Internet, commonly one fixed and one or more mobile. The NTP of each Network must allow for the existence of others and must enable the customer to program decisions about which Network to use. Automated resilience of Internet connectivity becomes increasingly important as: * home working becomes more prevalent * critical devices such as medical appliances and alarm systems are connected in the home via the Internet Therefore resilience for Internet connectivity must be considered in regulation with respect to both Network selection and power supply resilience, as follows. *Network selection:* On the PSTN the existence of Dial-tone has been the indication of availability at the NTP. A home can easily have more than one PSTN NTP, and more than one fixed line connection to the Internet in addition to mobile. Therefore, customer owned equipment must have the opportunity to be able to directly determine, in an automated fashion, whether or not connectivity via each Internet Connection Provider is functional. Methods are dependent on the chosen logical Network Termination Point and are proposed in the Summary above. *Power supply resilience:* Logical termination equipment (e.g. modem) may be required for some physical access media. If power is not supplied from the network then the customer's domestic supply may be used. In the latter case the regulator must give consideration to backup supply standardisation. The proliferation of individual AC to DC power converters and the need for Inverters to get back to AC supply levels from battery backup is not energy efficient. Standardisation of low power DC supply to NTP devices would reduce electrical wastage and could reduce the number of manufactured components required where devices are permanently powered with DC. Steve Nash Writing my personal opinions, with the Sponsorship of NETSCOUT. On 10/10/2019 17:52, Marco Hogewoning wrote: > Dear colleagues, > > Earlier this week, BEREC (Body of European Regulators for Electronic Communications) announced a public consultation on their draft guidelines for interpreting the “network termination point (NTP)”. These guidelines have been designed in accordance with Article 61(7) of the European Electronic Communications Code to provide national regulatory authorities (NRAs) with guidance on how to interpret the EU directives and implement them in their national legislation. > > This consultation is open to the public. While the RIPE NCC has no particular position on this topic, we think it is important for the community to consider the impact of these guidelines. They could impact not only our members’ operations, but the RIPE NCC’s engagement strategy on a number of topics such as IPv6 and IoT security. > > We invite the Connect Working Group to discuss the proposed guidelines and, should it reach a rough consensus as determined by the chairs, the RIPE NCC is willing to submit that opinion as a response on behalf of the RIPE community. As we see pros and cons to either alternative, failure to reach consensus will mean we will not respond to this consultation on behalf of the RIPE community, but would instead encourage individual members to provide their own responses. > > I’ll provide a brief description of the problem space and the potential impact below, but I recommend reading the draft guidelines as they are posted on the BEREC website: > https://berec.europa.eu/eng/document_register/subject_matter/berec/regulato… > > Please note that while BEREC’s deadline is 21 November, we would need a few days to process and file the formal response and we kindly request the working group to respect close of business on 15 November as its internal deadline to reach consensus. > > Key Issues > > One of the key questions laid out in the document is whether or not the CPE or modem is part of the NTP. EU Regulation 2015/2120 states with regard to Internet access services in article 3(1): > >> “End-users shall have the right to access and distribute information and content, use and provide applications and services, and use terminal equipment of their choice […]” > The 2016 BEREC Guidelines on net neutrality rules (paragraphs 26 and 27) provide further guidance on the implementation and state: > >> “In considering whether end-users may use the terminal equipment of their choice, NRAs should assess whether an ISP provides equipment for its subscribers and restricts the end-users’ ability to replace that equipment with their own equipment, i.e. whether it provides ‘obligatory equipment’. >> >> Moreover, NRAs should consider whether there is an objective technological necessity for the obligatory equipment to be considered as part of the ISP network. If there is not, and if the choice of terminal equipment is limited, the practice would be in conflict with the Regulation.” > Not only is this subject to national definitions and implementations, it also allows for exceptions under “objective technological necessity”. Among other things, the draft guidelines go into a lot of detail with regards to the consequence of the different options that exist. > > As explained above, the RIPE NCC has no immediate position on which option is the better alternative. However, it could impact our engagement strategy in the longer term. > > There are roughly two alternative options: the modem or CPE is “obligatory” and as such will be supplied and maintained by the access provider as part of their network, or the end-user is allowed or even required to source their own equipment, which needs to be compatible with the network. > > The two different options would impact, for example, the RIPE NCC’s focus when it comes to IPv6 adoption. Although we have seen successful deployments under both scenarios, it is either the ISP that is in control and has to make the choice (which of course often means our members are deciding), or we need to somehow create awareness among end-users and engage more with manufacturers, importers and retailers to adopt equipment that supports IPv6. > > We also imagine that such a choice would impact the scale and, more importantly, the speed of IPv6 adoption. > > We also expect that if the prevailing choice would be to allow the end-user to select their own equipment, there will be an increased demand for strict standards and profiles to ensure interoperability. While the draft guidelines recognise that the CPE market is both competitive and innovative, we expect these discussions to lean towards additional certification requirements to ensure interoperability. > > In light of the current discussions about IoT security, especially in household appliances, we also see a big focus on the CPE as providing some security-related services. Several of these systems, such as SPIN and MUD/FUD, have been presented to the community. Again, a more scattered landscape where users select their own devices might make it challenging for these technologies to reach a sustainable level of adoption. > > More generally, we can expect that greater freedom of choice in selecting devices would come with some additional security challenges, where the increased variety could also lead to an increase in the variety of attack vectors and vulnerabilities. Also, as the CPE would no longer be in the ISP’s domain, we would lose the ability to quickly roll out patches and would instead have to trust the end-user or manufacturer to install updates in a timely fashion. > > Again, this is something where we would expect further discussion with regards to regulatory measures and (mandatory) certification to ensure minimum requirements are met and to protect the consumer. > > In either case, we trust the NRAs and the market to make an informed decision on the most appropriate approach and are happy to bring the RIPE community’s opinion forward to this consultation. Regardless of the outcome, we will continue to monitor these discussions and adjust our engagement strategy accordingly, both towards policymakers as well as the various market participants and, where necessary, the end-users. > > Regards, > > Marco Hogewoning > External Relations, RIPE NCC > > > _______________________________________________ > connect-wg mailing list > connect-wg(a)ripe.net > https://lists.ripe.net/mailman/listinfo/connect-wg -- Steve(a)nashfamily.me.uk is now my personal email address.

4 5

FW: [address-policy-wg] 2019-07 New Policy Proposal (Default assignment size for IXPs)
by Erik Bais 17 Oct '19

17 Oct '19

Dear Connect WG, As co-chair of the Address Policy WG, I would like to inform you at the following AP-WG proposal by Remco van Mook to adjust the default allocation size for IXP space. The discussion will be on a AP-WG mailing list and I would suggest to the Connect WG to provide your experience and input on this idea. This will have an impact on your business/operation .. we need to receive your view and insight. Regards Erik Bais On behalf of the AP-WG Chair collective On 15/10/2019, 14:43, "address-policy-wg on behalf of Marco Schmidt" <address-policy-wg-bounces(a)ripe.net on behalf of mschmidt(a)ripe.net> wrote: Dear colleagues, A new RIPE Policy proposal, 2019-07, "Default assignment size for IXPs" is now available for discussion. This proposal aims to change the default IXP assignment size from a /24 to a needs-based model, with a /27 as a minimum. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-07 As per the RIPE Policy Development Process (PDP), the purpose of this four week Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposer, with the agreement of the WG Chairs, will decide how to proceed with the proposal. We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 13 November 2019. Regards, Marco Schmidt Policy Officer RIPE NCC

1 0

BEREC consultation: Identification of the network termination point
by Marco Hogewoning 16 Oct '19

16 Oct '19

Dear colleagues, Earlier this week, BEREC (Body of European Regulators for Electronic Communications) announced a public consultation on their draft guidelines for interpreting the “network termination point (NTP)”. These guidelines have been designed in accordance with Article 61(7) of the European Electronic Communications Code to provide national regulatory authorities (NRAs) with guidance on how to interpret the EU directives and implement them in their national legislation. This consultation is open to the public. While the RIPE NCC has no particular position on this topic, we think it is important for the community to consider the impact of these guidelines. They could impact not only our members’ operations, but the RIPE NCC’s engagement strategy on a number of topics such as IPv6 and IoT security. We invite the Connect Working Group to discuss the proposed guidelines and, should it reach a rough consensus as determined by the chairs, the RIPE NCC is willing to submit that opinion as a response on behalf of the RIPE community. As we see pros and cons to either alternative, failure to reach consensus will mean we will not respond to this consultation on behalf of the RIPE community, but would instead encourage individual members to provide their own responses. I’ll provide a brief description of the problem space and the potential impact below, but I recommend reading the draft guidelines as they are posted on the BEREC website: https://berec.europa.eu/eng/document_register/subject_matter/berec/regulato… Please note that while BEREC’s deadline is 21 November, we would need a few days to process and file the formal response and we kindly request the working group to respect close of business on 15 November as its internal deadline to reach consensus. Key Issues One of the key questions laid out in the document is whether or not the CPE or modem is part of the NTP. EU Regulation 2015/2120 states with regard to Internet access services in article 3(1): > “End-users shall have the right to access and distribute information and content, use and provide applications and services, and use terminal equipment of their choice […]” The 2016 BEREC Guidelines on net neutrality rules (paragraphs 26 and 27) provide further guidance on the implementation and state: > “In considering whether end-users may use the terminal equipment of their choice, NRAs should assess whether an ISP provides equipment for its subscribers and restricts the end-users’ ability to replace that equipment with their own equipment, i.e. whether it provides ‘obligatory equipment’. > > Moreover, NRAs should consider whether there is an objective technological necessity for the obligatory equipment to be considered as part of the ISP network. If there is not, and if the choice of terminal equipment is limited, the practice would be in conflict with the Regulation.” Not only is this subject to national definitions and implementations, it also allows for exceptions under “objective technological necessity”. Among other things, the draft guidelines go into a lot of detail with regards to the consequence of the different options that exist. As explained above, the RIPE NCC has no immediate position on which option is the better alternative. However, it could impact our engagement strategy in the longer term. There are roughly two alternative options: the modem or CPE is “obligatory” and as such will be supplied and maintained by the access provider as part of their network, or the end-user is allowed or even required to source their own equipment, which needs to be compatible with the network. The two different options would impact, for example, the RIPE NCC’s focus when it comes to IPv6 adoption. Although we have seen successful deployments under both scenarios, it is either the ISP that is in control and has to make the choice (which of course often means our members are deciding), or we need to somehow create awareness among end-users and engage more with manufacturers, importers and retailers to adopt equipment that supports IPv6. We also imagine that such a choice would impact the scale and, more importantly, the speed of IPv6 adoption. We also expect that if the prevailing choice would be to allow the end-user to select their own equipment, there will be an increased demand for strict standards and profiles to ensure interoperability. While the draft guidelines recognise that the CPE market is both competitive and innovative, we expect these discussions to lean towards additional certification requirements to ensure interoperability. In light of the current discussions about IoT security, especially in household appliances, we also see a big focus on the CPE as providing some security-related services. Several of these systems, such as SPIN and MUD/FUD, have been presented to the community. Again, a more scattered landscape where users select their own devices might make it challenging for these technologies to reach a sustainable level of adoption. More generally, we can expect that greater freedom of choice in selecting devices would come with some additional security challenges, where the increased variety could also lead to an increase in the variety of attack vectors and vulnerabilities. Also, as the CPE would no longer be in the ISP’s domain, we would lose the ability to quickly roll out patches and would instead have to trust the end-user or manufacturer to install updates in a timely fashion. Again, this is something where we would expect further discussion with regards to regulatory measures and (mandatory) certification to ensure minimum requirements are met and to protect the consumer. In either case, we trust the NRAs and the market to make an informed decision on the most appropriate approach and are happy to bring the RIPE community’s opinion forward to this consultation. Regardless of the outcome, we will continue to monitor these discussions and adjust our engagement strategy accordingly, both towards policymakers as well as the various market participants and, where necessary, the end-users. Regards, Marco Hogewoning External Relations, RIPE NCC

3 2

Minutes from RIPE 78
by remco van mook 10 Oct '19

10 Oct '19

Dear all, In order to prevent another red-face moment, please find below the draft minutes from the previous meeting. I trust you will read them all carefully so we can sign off on them during our next meeting! Kind regards Remco Co-chair of Connect-WG Connect Working Group RIPE 78 22 May 2019, 11:00-12:30 WG co-Chairs: Remco van Mook, Florence Lavroff, Willem van Gullik Scribe: Rumy Spratley-Kanis 1. Opening (Welcome, scribe appointment, agenda, proposed session format) The presentation is available at: https://ripe78.ripe.net/archives/video/50/ Florence asked attendees what businesses they worked in; this was measured by a show of hands and is as follows in descending order: - IXP - ISP - Content - Enterprise - Educational network 2. The Elusive Internet Flattening: 10 Years of IXP Growth Ignacio Castro, Queen Mary University of London The presentation is available at: https://ripe78.ripe.net/archives/video/51/ Nina Bargisen (Netflix) asked if, with IXP, Ignacio meant public peering. He confirmed that he collected public peerings from the peering DB. Nina said it makes some of the conclusions confusing because when there is a big flow in an IXP, it is moved to private interconnections. These peerings should be included to assess if the Internet is getting flatter because of Internet exchanges. All operators do private interconnections, so it would be useful to adjust the methods and include these. Nina asked Ignacio to study each of the CDNs and how they route their clients because not all the CDNs do it the same way. Ignacio agreed with the comments about private peering but he felt constrained due to having to look at historical data, which doesn’t include changes in redirection strategies. Martin Levy (Cloudflare) pointed out that the graph on slide 27 doesn't tell the full story. The divergence is partly a business model of the different players and is not a reflection of the IXPs in any way. While the graph is correct, it doesn’t tell whether we are better connected today than 15 years ago. He added that the graph by itself wasn’t flattering for Internet exchanges; even if they are the saving grace for how the internet works today. He asked whether Ignacio could share any data that wasn't based on IXP data. Ignacio empathised with Martin's comment, then explained that it was very difficult to find data with the limitations that were in place. He agreed that looking at redundancy multihoming would be an extra metric that would be interesting to review. In the end, he tried to look at two relatively simple metrics that are comparable over time and easy to convey. Martin commended him on his study. Andrew Sullivan (ISOC) mentioned that he was troubled by the last discussion. The numbers and graphs seemed to contradict the work done by IXPs. This may lead to an incorrect conclusion that IXPs are not worth the investment – he did not believe this. He encouraged Ignacio to find additional numbers to show a complete picture. Ignacio mentioned that his original plan for this work was “should I build an IXP?” His intent was not to say IXPs don’t matter, his message was, that in the specific metrics he looked at, the impact was as expected, particularly with regards to path length. The impact of transit dependence was clear. Blake Willis (Zayo / iBrowse / L33) added to Nina's point about private interconnects (PNIs) saying it would be interesting if Ignacio could dig into his data and analyse when a path moved from an IXP to a PNI. This could be a way to analyse where the bigger flows are. 3. RPKI at Route Servers Follow Up Nick Hilliard, INEX The presentation is available at: https://ripe78.ripe.net/archives/video/53/ Marja Jan Matejka (CZ.NIC), a developer of Bird, mentioned that in Bird Version 2, there is a special feature called Custom Route Attribute. This feature allows you to name and use your route attribute instead of these defined contents. He suggested that this would be much faster. He asked why they weren’t doing both RPKI and IRR DB? Nick replied they do both, but they start with RPKI filtering. If it fails the RPKI validation, it will drop the prefix, and if it’s unknown, it will pass through the IRR DB. However, the ASN check has to be evaluated first, so it’s IRR DB AS check, followed by RPKI validation, followed by regular IRR DB validation if it’s RPKI unknown. A participant asked whether they also do comparison evaluations against, for instance, FRR. Nick replied that they hadn’t tried FRR because there hadn’t been a huge amount of code changes for the route server code paths in FRR. Also, there were scaling problems with Quagga. There are other issues with FRR it being more difficult to do atomic config changes and updates, and the FRR will need a little bit more work before they can use it. Aris Lambrianidis from AMSIX asked whether they had a change of heart with regards to implementing RPKI in the EU route servers. Nick said this was a good question – and for them, this was more a policy issue rather than a technical issue. They were previously sceptical about RPKI implementation because when seen from a very high level, it creates a single point of failure. If compromised, for example, at an RIR, a red button could be pressed to disable a particular prefix or set of prefixes. Before, the BGP inter-domain ecosystem was based on a peer-to-peer system with filtering arrangements between organisations, whereas now there is a top-down thing which is controlled by the RIRs. He added there had been an increase in the amount of BGP hijacking that is difficult to deal with unless you implement a tool like RPKI. Like any policy decision, it’s a balance between not implementing something that could potentially cause problems, and implementing something that could fix a problem you already have. In the last few years, RPKI has seen various changes at a policy level. There is now jurisprudence about how courts interact with organisations like the RIPE NCC about deregistering prefixes, and there is much clearer understanding from a legal point of view. So, they looked at all the issues from a technical and a policy angle and concluded that RPKI was a good way to go. Randy Bush (Internet Initiative Japan) mentioned that RPKI is a database and this means RPKI based origin validation. He added that while it will help, it is not a magic bullet. Nick confirmed and agreed with Randy. He added that if hijacks and misconfigurations were easy to solve, they would have been solved years ago. RPKI makes it more difficult to make bigger mistakes. 4. BGP Filtering on AS15169 Using IRR and Other Data Arturo Servin, Google The presentation is available at: https://ripe78.ripe.net/archives/video/56/ Ruediger Volk (Deutsche Telecom) asked why they are not considering to mark the regular RPKI evaluation early on, as marking and reporting what looks invalid would be a good idea and helpful from the beginning. Arturo replied that he and Chris have considered it and will be further discussed. Ruediger asked why they were considering RPKI as a source only for invalidating IRR data. Why not include the RPKI ROA data sets as an additional quality source of route information? Arturo replied that they will when they are ready to use it. Ruediger mentioned that if they don’t have the tools, he has them. Arturo added that RPKI only has the origin, and they need more, but they will not use one signal, they need more signals to make it reliable. Ruediger said that Arturo was only talking about acceptance, it would be nice to have a slide with what they are publishing, as authoritative information from their peers. Arturo said that his presentation was short, but they are fixing all their internal systems to ensure that data in the IRR is correct and that what is in there, is exactly what they want to announce. They are also working on publishing their ROAs. This will happen in the next quarter, along with a lot of other parts that need fixing. Ruediger replied that it would be nice to have a summary at some point. Arturo said that they have also joined MANRS. To show their commitment to fixing this problem and be part of the solution rather than just the problem, they are working with ISOC to make MANRS more successful. Cleaning up and filtering is something Google wants to do and is committed to, and so they are in the process, but it will take some time. Magnus, a remote chat participant, asked if they could open their IRR software. Arturo said they don’t have an IRR software, but they do have some tools that they use to parse the information. Chris Morrow, Arturo’s colleague from Google, replied that he had written some IRR parsing software, available on GitHub, it still needs work, but once finished, it could be used to parse the data and create filters. They will spend more time on that. Randy Bush commented on the slide “How do I peer with AS15169?” He asked if that included the transitive closure. If Randy, a BGP speaker, were not their peer, but a customer of their peer, would they accept his prefix from their peer if his prefix did not have an IRR Object? Arturo replied that they wouldn’t because there wouldn’t be any authorisation in place. Paul Hoogsteder, a remote chat participant, asked if Arturo could explain what is meant with “follow the AS/arrow maintainer”? Arturo replied that in the IRR, you have the maintainer, the AS-SET and the ASN object. They check the ASN object and check if it is an ASN they peer with. But they need to know all the routing information, which is in the AS-SET. So if someone peers with them and doesn’t put the ASN-SET in the ISP.google.com, one of the ways they find the AS-SET that has all the ASNs or all the information related to that ASN is by going to the peering DB to check the ASN-SET. Brian Dickson (GoDaddy) asked if a BGP speaker with their own AS, peering with Google directly and has RPKI but no IRR object or AS path, would Google not accept routes from them? Arturo confirmed that for now, they wouldn’t. He added that NTT has a way to export from RPKI to IRR’s, but they hadn’t decided if they were going to use it. This will be discussed. Brian asked if AS cone were to get formalized and adopted, would they use it? Plus RPKI? Arturo replied that he wasn’t sure you can put AS cone in the RPKI. All they know is that the prefix as an origin. Brian clarified AS cone if it does go into the RPKI. Arturo replied that if that were the case, including AS PA, then maybe they would adopt it. An anonymous remote chat participant asked if they were doing filtering before this, and based on what information? Arturo replied that they didn’t do any filtering, they just had the prefix, the number of prefixes – Chris will answer: Chris Morrow (Google) added that they were doing less filtering, not none. 5. Connect Update Florence Lavroff The presentation is available at: https://ripe78.ripe.net/archives/video/57/ There were no questions or comments. 6. Euro-IX Update Bijal Sanghani, Euro-IX The presentation is available at: https://ripe78.ripe.net/archives/video/58/ There were no questions or comments. 7. IXPDB and Tools Jesse Sowell, The Bush School of Government and Public Service, Texas A&M University The presentation is available at: https://ripe78.ripe.net/archives/video/59/ There were no questions or comments. 8. Offline Discussion There was no discussion 9. Closure

1 0

Working Group agenda, RIPE 79
by Florence Lavroff 02 Oct '19

02 Oct '19

Dear friends of the Connect WG, RIPE 79 is around the corner. Here is the agenda for our next Working Group session on Wednesday, October 16th from 11:00 to 12:30 : 1 Opening (Welcome, scribe appointment, agenda, proposed session format) 2 Raci #1 - Dismantling Operational Practices of BGP Blackholing at IXPs, Marcin Nawrocki, Freie Universitaet Berlin - 10 min 3 Raci #2 - Keeping state election infrastructure safe: How Cloudflare and local IXP connectivity helped a small country in Europe, Vladislav Bidikov, Faculty of Computer Science and Engineering / IXP.mk - 10 min 4 IX-API: An API for Automating Interconnection, Thomas King, DECIX - 15 min 5 IPv6 adoption on Internet Exchanges, Susan Forney, Hurricane Electric - 15 min 6 Euro-IX update - Bijal Sanghani, Euro-IX - 3 min 7 Connect update - Florence Lavroff - 3 min 8 Offline discussion 9 Closure See you in Rotterdam ! Best regards, Florence, Remco and Will Connect-WG co-chairs -- Florence Lavroff / lavroff(a)google.com / +31 6 11 01 55 80 Infrastructure Acquisition and Interconnect / Google EMEA

1 0

Call for presentations at RIPE 79
by Will van Gulik 11 Sep '19

11 Sep '19

Dear friends of the Connect WG, We are a bit more than a month away from RIPE 79, that will take place in Rotterdam, the Netherlands, from October 14th to 18th 2019. Our next Connect-WG session is scheduled for Wednesday, October 16th from 11 AMto 12.30 in the main room. If there is any topic you are interested to present during the session, please let us know ! Thanks, Kind regards, Florence, Remco and Will Connect-WG co-chairs

1 0

New on RIPE Labs: History and Impact of IXP Growth
by Mirjam Kuehne 23 Jul '19

23 Jul '19

Dear colleagues, Ignacio Castro, a fellow under the RIPE Academic Coordination Initiative at RIPE 78, wrote this interesting article on RIPE Labs: https://labs.ripe.net/Members/ignacio_castro/shaping-the-internet-history-a… Kind regards, Mirjam Kühne RIPE NCC

1 0

Agenda for Connect-WG @ RIPE 78
by Will van Gulik 01 May '19

01 May '19

Dear friends of the Connect-WG, In a few weeks, we will be in Reykjavik for RIPE 78, and we are looking forward to seeing you all there. The Connect-WG will take place Wednesday, May 22nd from 11am to 12.30am in the Main room. We will keep the same format we used during the last meeting in Amsterdam and have a small non-recorded nor live-streamed open discussion at the end of our session. Here is the agenda for the session : 1 Opening (Welcome, scribe appointment, agenda, proposed session format) 2 The Elusive Internet Flattening: 10 Years of IXP Growth by Ignacio Castro - 15 min 3 RPKI at route servers followup by Nick Hilliard (INEX) - 15 min 4 Google's peer lock implementation by Arturo Servin (Google) - 15 min 5 Connect update by Florence Lavroff - 3 min 6 Euro-IX update by Bijal Sanghani - 3 min 7 Discussion about tools for interconnect professionals - 10 min 8 Offline discussion - 10 min 9 Closure. See you all soon, Best regards, Florence Remco and Will Connect-WG co-chairs

1 0

Call for Presentations European Peering Forum 14 (EPF14)
by Siri Brenden 24 Apr '19

24 Apr '19

Call for Presentations European Peering Forum 14 (EPF14) AMS-IX, DE-CIX, LINX and Netnod are happy to host the 14th European Peering Forum (EPF) in Tallinn, Estonia from the 16th - 18th September 2019. The event will welcome up to 300 peering managers and coordinators from networks connected to the host Internet exchanges.Besides an interesting topical agenda, the three-day event accommodates room for attendees to meet on a one-to-one basis to discuss bilateral peering business opportunities. The programme committee will be looking for presentations and lightning talks related to peering and technical topics of interconnection. Your presentation should address: * Interconnection Automation * Regional Peering * Interconnection / Peering Internet Governance and Regulatory Topics * Economic and Product Trends * Peering / Interconnection strategies * Interesting findings about Peering / Interconnection * 400GE and beyond Submissions =========== Presentations must be of a non-commercial nature. Product or marketing heavy talks are strongly discouraged. Submissions of presentations should be made to the programme committee <epf-pc(a)peering-forum.eu <mailto:epf-pc@peering-forum.eu>>. Please include: * Author's name and e-mail address * Presentation title * Abstract * Slides (if available) * Time requested (max. 30 minutes incl. Q&A) Deadlines ========= Presentation Abstract Deadline 15/07/2019 12:00 UTC Final Selection of Speakers 26/07/2019 Presentation Slides Submission Deadline 02/09/2019 12:00 UTC More information about the event and other activities around EPF14 may be found at: * https://peering-forum.eu/ <https://peering-forum.eu/> * https://www.facebook.com/groups/1486607564933665/ <https://www.facebook.com/groups/1486607564933665/> Warm regards, AMS-IX, DE-CIX, LINX and Netnod

1 0

Connect update + Euro-IX update @ RIPE 78
by Florence Lavroff 23 Apr '19

23 Apr '19

Dear friends of the Connect-WG, As per the previous Connect-WG session, we'll present a Connect update and a Euro-IX update during the Connect WG at RIPE 78. The aim of the Connect update is to list on a single slide connect-relevant news, announcements, interesting publications and videos while the Euro-IX update, presented by Bijal, in copy of this mail, is focused on IXP-relevant updates. Anything you'd like us to mention ? Feel free to let us / Bijal know. Thanks, Best regards, Florence, Remco and Will Connect-WG co-chairs -- Florence Lavroff / lavroff(a)google.com / +31 6 11 01 55 80 Infrastructure Acquisition and Interconnect / Google EMEA

1 0

Input request in regards of IPv4 dust for IXP Pool usage
by Erik Bais 18 Mar '19

18 Mar '19

Dear Connect-WG, As we have been missing some of you during the RIPE77 Address Policy WG discussion, I would like to invite you to have a look in the archive of the Agenda topic of Andrea Cima of the RIPE NCC. https://ripe77.ripe.net/archives/video/2232/ ( Andrea Cima - D. IPv4 End-Game and Afterlife ) As the collective of AP-WG Chairs and the RIPE NCC, we would like some more insight from the Connect community what to do with the IPv4 dust that the RIPE NCC has in the current IPv4 pool (at the bottom.) We received some conflicting views in AP-WG during the meeting and it would be nice to get more voices than just the two in the room. There are 3 options what we might be able to do with the last scraps of IPv4 space .. ( mostly smaller than a /24 prefixes ) that are regarded as left-overs or dust as we call them. Option 1 : hand them to the last one who might come along .. The LIR that will receive them, will not be happy or get any usable routable space .. ( So this might not be a good option .. ) Option 2 : put it in the temp. pool. That is used for temporary events or research options. Option 3 : Put it in the IXP pool .. in case someone doesn't want their IXP lan to be routable on the DFZ anyway .. they might also have enough if they receive a /27 for their 10 member IXP LAN. Especially the Option 3 is what we like to hear some more discussion on .. especially from the Connect WG members.. There might be 2 views, if an IXP lan should be routable or not ??? And what is the view of the Connect community on the topics .. so that we can take that as input moving along .. It would be nice if we can some discussion on this either here ( the Connect WG ML) or on the AP-WG ML. but as all the IXP experts should be here .. both Gert and myself are happy to take the input from here to the AP-WG ML. As long as we receive your input and views. Kind regards, Erik Bais & Gert Döring Address Policy WG Chairs

2 1

Presentation for RIPE 78
by Ignacio Castro 14 Mar '19

14 Mar '19

Dear Connect Working Group, I am a RACI attendee to RIPE 78 and was wondering whether my talk would be a good fit for the WG, as suggested by the PC. The original slides that I submitted can be found here: https://www.dropbox.com/s/fimwp4e1wilb5t2/2019-02_RACI_IXP-history.pptx?dl=0 A draft of the ongoing work is also available here: https://arxiv.org/abs/1810.10963 Thank you! Ignacio Castro -----Original Message----- From: php-fpm <php-fpm(a)ripe.net> On Behalf Of RIPE 78 Programme Committee Sent: 14 March 2019 15:59 To: Ignacio Castro <i.castro(a)qmul.ac.uk> Cc: pc(a)ripe.net Subject: Presentation rejected for RIPE 78 Dear Ignacio Castro, We regret to inform you that your talk submission for RIPE 78 titled '10 Years of IXP Growth and its impact on end-to-end paths (RACI)' has not been accepted into the Plenary session. We had a tough competition for the few remaining slots and in the end another proposal won the PC's preference. The PC would suggest you reach out to the Connect-WG. The WG Chairs can be reached at connect-wg(a)ripe.net. Looking forward to your submissions for future meetings. Thank you, Maria Isabel Gandia Carriedo on behalf of the RIPE Programme Committee

1 0

[connect-wg] Call for presentations at RIPE 78
by Florence Lavroff 06 Mar '19

06 Mar '19

Dear friends of the Connect WG, RIPE 78 will take place in Reykjavík, Iceland, from May 20th to 24th 2019. Our next Connect-WG session is scheduled for Wednesday, May 22nd from 11 AM to 12.30 in the main room. If there is any topic you are interested to present during the session, please let us know ! Thanks, Kind regards, Florence, Remco and Will Connect-WG co-chairs -- Florence Lavroff / lavroff(a)google.com / +31 6 11 01 55 80 Peering and Content Distribution / Google EMEA

1 0