- Routing-wg - lists.nordu.net

Survey for Routing Working Group Members
by Meade, Brenna 14 May '24

14 May '24

HI Routing Working Group Members! We have created the following survey to understand more about the members of the group and what we should be focusing on going forward. If you get the chance feel fill out the following survey. Results will be discussed in upcoming RWG meetings. https://docs.google.com/forms/d/e/1FAIpQLSdGFRCADvT3AbNPI1dkQFURcboFtfzJCLS… <https://docs.google.com/forms/d/e/1FAIpQLSdGFRCADvT3AbNPI1dkQFURcboFtfzJCLS…> Brenna Meade Routing Working Group Co-Chair International Networks @ Indiana University

1 1

looking at published customer cones vs. ground truth..
by Steven Wallace 15 Apr '24

15 Apr '24

Greetings, Internet2 doesn’t explicitly filter routes it receives from NREN peers. It does apply standard sanity checks, but all legitimate routes are accepted. It is common practice among NRENs to exchange their customers’ routes AND routes heard from other NRENs. Internally, we sometimes refer to the entire collection of NREN routes as ITN (International Transit Network). This practice of offering mutual transit has served the NREN community by providing redundancy and allowing for more sparse interconnection points. For example, Internet2 becomes a transit AS interconnecting networks that land on the east and west coasts of the US. However, not explicitly filtering routes among the NRENs has downsides. Last week, an NREN unintentionally announced many non-NREN routes to Internet2. The number of routes announced triggered a shutdown of the BGP session, and the increase in Internet2’s route table size caused a network in the US to shut down its peering with Internet2. Explicitly filtering routes received from our NREN peer would have mitigated this incident. Building a filter based on a peer’s as-cone could be a reasonable standard practice to improve routing security if NRENs only exchanged their customer routes. An approach that might fit our needs better could include a published as-set representing the customer as-cone for each NREN, plus the RPSL (I’m not an RPSL expert, but I assume this is possible) needed to convey which customer and transit routes to accept from a peer. Another approach might be to maintain an as-cone for the entire ITN, and use that as the basis for a filter. There are approximately 2,600 ASs in the ITN. I’m not a BGP expert, but I’d like to support a conversation among the NRENs to explore options and, potentially, to recommend best practices to improve our collective routing security while maintaining our transit policies. I’ve generated some data to spark the conversation. Firstly, I need to say that if Internet2 were in this list, it would show “No AS-SET for Internet2 (AS11537).” We’re reluctant to publish such an as-set as there isn’t a well-understood interpretation of how it would be used among NRENs. If Internet2 published its as-cone via an as-set, would other networks apply prefix filters based on this as-set and reject routes from the other NRENs that are part of the ITN? Based on routing data from bgp.nsrc.org and sources like the IRRs and peeringdb, here’s a list of NRENs that peer with Internet2, their as-set, and the count of ASs received that fall outside of the as-set. I’m sure I’ve made errors. Please let me know if you see anything in error. Steve AARNET (AS7575) as-set="AS7575:AS-CUSTOMER" count of origins outside customer cone 1 out of 96 origins seen. list of origins outside customer cone [10906] AMPATH (AS20080) as-set="AS-AS20080-TRANSIT" count of origins outside customer cone 6 out of 23 origins seen. list of origins outside customer cone [28609, 263076, 262441, 19611, 27676, 263358] ANKABUT (AS47862) as-set="AS47862" count of origins outside customer cone 9 out of 9 origins seen. list of origins outside customer cone [59968, 50602, 58283, 51182, 61137, 47862, 57143, 52216, 50811] No AS-SET for APAN (AS7660) CANARIE (AS6509) as-set="AS6509:AS-CANARIE" count of origins outside customer cone 1 out of 150 origins seen. list of origins outside customer cone [577] CEDIA (AS61468) as-set="AS61468:AS-CEDIATRANSITMIEMBROS" count of origins outside customer cone 3 out of 16 origins seen. list of origins outside customer cone [27947, 22724, 61468] CERN (AS513) as-set="AS-CERNEXT" count of origins outside customer cone 0 out of 0 origins seen. CERNET (AS23911) as-set="AS4538:AS-CUSTOMERS-V6" count of origins outside customer cone 0 out of 0 origins seen. CSTNET (AS7497) as-set="AS7497:AS-CUSTOMERS" count of origins outside customer cone 0 out of 1 origins seen. No AS-SET for CUDI (AS18592) No AS-SET for CUDI (AS28569) No AS-SET for ENSTINET (AS6879) GEANT (AS20965) as-set="AS-GEANTNRN" count of origins outside customer cone 57 out of 533 origins seen. list of origins outside customer cone [38272, 138369, 138371, 327944, 138378, 327947, 328076, 12812, 328212, 24348, 37661, 24349, 24350, 328224, 328353, 24352, 24353, 24355, 24357, 24358, 37288, 24361, 24362, 24363, 24364, 328752, 24369, 24370, 24371, 327992, 4538, 199354, 329410, 328647, 328648, 328903, 209098, 132553, 11340, 6736, 37074, 328530, 37717, 328662, 328663, 133465, 8670, 49248, 133475, 23910, 21612, 329326, 328054, 328439, 328184, 328702, 24575] No AS-SET for GOREX (AS35889) No AS-SET for HBKU (AS34945) No AS-SET for JGNX (AS17934) KACST (AS8895) as-set="RIPE::AS8895:AS-KACST" count of origins outside customer cone 0 out of 7 origins seen. KREONET2 (AS17579) as-set="AS1237:AS-KREONET" count of origins outside customer cone 0 out of 36 origins seen. No AS-SET for NEAAR (AS396390) NKN (AS9885) as-set="AS-NIC-NKN-BGP-PEERS" count of origins outside customer cone 2 out of 106 origins seen. list of origins outside customer cone [152576, 132124] NORDUNET (AS2603) as-set="AS-NORDUNET" count of origins outside customer cone 3 out of 154 origins seen. list of origins outside customer cone [200264, 9113, 48670] OMREN (AS206350) as-set="AS206350" count of origins outside customer cone 2 out of 2 origins seen. list of origins outside customer cone [28885, 206350] QFN (AS29384) as-set="AS29384" count of origins outside customer cone 1 out of 1 origins seen. list of origins outside customer cone [29384] REANNZ (AS38022) as-set="RADB::AS-REANNZ-MEMBERS" count of origins outside customer cone 1 out of 32 origins seen. list of origins outside customer cone [3477] REDCLARA (AS27750) as-set="AS27750:AS-MEMBERS" count of origins outside customer cone 37 out of 41 origins seen. list of origins outside customer cone [52224, 263683, 262156, 27790, 263186, 264724, 265884, 61476, 28068, 263204, 4270, 61486, 10671, 264630, 61496, 5692, 263235, 52424, 28107, 27981, 28109, 264785, 270033, 27993, 52442, 52314, 264798, 20191, 27875, 265700, 23140, 27750, 27883, 264687, 26610, 27897, 27770] RNP (AS1916) as-set="RADB::AS-RNP" count of origins outside customer cone 4 out of 79 origins seen. list of origins outside customer cone [268744, 61612, 28157, 28222] SINET (AS2907) as-set="JPIRR::as2907:as-sinet" count of origins outside customer cone 26 out of 122 origins seen. list of origins outside customer cone [1921, 18183, 38296, 7577, 7588, 9264, 7472, 17713, 7610, 4538, 4158, 63555, 45259, 3662, 24151, 11096, 7650, 17764, 24302, 38254, 7539, 18422, 137207, 1659, 3836, 4605] No AS-SET for SINGAREN (AS23864) No AS-SET for STARLIGHT (AS10764) SURFNET (AS1103) as-set="AS-SURFNET" count of origins outside customer cone 0 out of 25 origins seen. TENET (AS2018) as-set="AS-TERTIARY" count of origins outside customer cone 0 out of 5 origins seen. No AS-SET for TRANSPAC (AS22388) TWAREN (AS7539) as-set="AS7539:AS-TWAREN" count of origins outside customer cone 0 out of 8 origins seen. UBUNTUNET (AS36944) as-set="AS-UBUNTUNET" count of origins outside customer cone 1 out of 21 origins seen. list of origins outside customer cone [327945] Steven Wallace Director - Routing Integrity Internet2 ssw(a)internet2.edu

5 8

Re: crafting a recommended practice for how NREN publish their as-cones
by David Farmer 04 Apr '24

04 Apr '24

On Wed, Apr 3, 2024 at 8:50 AM Mark Prior <mrp(a)mrp.net> wrote: > On 3/4/2024 20:37, Michael Lambert wrote: > >> On 2 Apr 2024, at 16:24, David Farmer <farmer(a)umn.edu> wrote: > >> > >> I had a thought. > >> > >> Does GREN or GNA-G have an ASN? > >> If not we/it could probably get one. > >> > >> My suggestion would be to use that ASN for a set of globally agreed to > communities and to create an as-set that represents the entirety of the > Global NREN community. > > > > I have to admit I have philosophical issues with the idea of obtaining > an ASN just to use in tagging without any real plans for having it appear > in an AS path in the routing table. > > > > Well it does provide uniqueness, and there are plenty of assigned ASN > not in the routing table.. > > Mark. > There are alternatives, but I don't think they are any more palatable; - We could choose a private ASN and overload it with our specifications. We would need to ensure the communities were stripped when leaving the Global R&E community since uniqueness isn't guaranteed. - We could register well-known BGP communities with IANA, using the first come, first serve range specified RFC1997. https://www.iana.org/assignments/bgp-well-known-communities/bgp-well-known-… Those options only work for BGP communities. We really shouldn't use private use or other reserved ASNs in the IRR. However, now that we have 32-bit ASNs, they really aren't a limited resource anymore. A registered ASN is the right answer, in my opinion. Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================

1 0

crafting a recommended practice for how NREN publish their as-cones
by Steven Wallace 03 Apr '24

03 Apr '24

Based on the feedback from this list, I’ve put together a rough draft of a best practice. Anyone can add comments to the Google Doc. If you’d like to edit the document directly, please send me your email, and I’ll add you to the document’s authors. https://docs.google.com/document/d/1hKCo75qrC_21TdlQULCTgA5ApFCgBTSPo7tecgD…

6 18

Agenda for the March RWG Meeting
by Meade, Brenna 18 Mar '24

18 Mar '24

Agenda for March Routing Working Group 1. Welcome to RWG 2024 2. Goals for 2024 3. Changes to the RWG 4. Open Discussion 5. Best practice subgroups 6. Upcoming Meetings 1. April 23 12 am UTC 2. May 21 12 pm UTC 3. June TNC -Join the GNA-G meeting 4. Remote – APAN 58 Please let me know if you would like to add anything to the agenda. Brenna Meade RWG Co-Chair

2 1

Slides from APAN56 In Person Routing Working Group
by Meade, Brenna 06 Sep '23

06 Sep '23

Hi all, Here are the slides from the August in person Routing Working Group meeting at APAN56. I will be reaching out to many of you about the new cases discussed in the August meeting. https://docs.google.com/presentation/d/1976v-mNqF7ZT0lKMpsTs5UtbV76LdgV9-FV… <https://docs.google.com/presentation/d/1976v-mNqF7ZT0lKMpsTs5UtbV76LdgV9-FV…> There is a recording but I have not received access to it yet but I will send it out when I do. All presentations from past APANs can be found here https://drive.google.com/drive/folders/1qYEZkhH1WM9I6KSH03uDoDfxAsbowciB?us… <https://drive.google.com/drive/folders/1qYEZkhH1WM9I6KSH03uDoDfxAsbowciB?us…> You all received an invite to the September Routing Working Group meeting at TechEx23, September 21, 12:30 – 1:30 Central. Online accessibility will be sent out closer to the date. Thanks! Brenna Meade Senior Network Architect International Network at Indiana University --

1 0

Routing Working Group August Meeting
by Meade, Brenna 20 Aug '23

20 Aug '23

Hello Routing Working Group, Reminder! The meeting is being held at APAN56 during the Tuesday at 11 am session (GMT+5:30) There is a free registration for online users. Link: https://apan56.apan.net/registration/ <https://apan56.apan.net/registration/> Remote access can be found here https://apan-net.zoom.us/j/82068023337?pwd=d2hFVFNhbE5QK3Q3TE90RFhtUFFOUT09 <Original URL:
https://apan-net.zoom.us/j/82068023337?pwd=d2hFVFNhbE5QK3Q3TE90RFhtUFFOUT09

Click to follow link.> Thanks! Brenna Meade Senior Network Architect Routing Working Group Co-Chair International Network at Indiana University --

1 0

Cancelled: May Routing Working Group Meeting
by Meade, Brenna 15 May '23

15 May '23

Hello Routing Working Group, I have had a significant number of members of the group reach out to say they will miss this week’s meeting. So, I am going to cancel. Please reach out if you have new cases or questions. I will be sending out invites to upcoming meetings this week. Upcoming Meetings: June Meeting – In Person @ TNC July Meeting – Personar 5.0.1 Thanks! Brenna Meade Routing Working Group Co-Chair

1 0

New Meeting Zoom Room
by Addleman, Hans C 18 Apr '23

18 Apr '23

Hi All, Please use the following zoom room for this meeting as it seems I can't gain control of the current zoom room. https://iu.zoom.us/my/addlema

1 0

SC23 NRE Call for Participation
by Meade, Brenna 27 Mar '23

27 Mar '23

Hello, Please find the attached call for participation for Network Research Exhibitions for the SC23 conference in Denver this November. More information about SC23 can be found here: https://sc23.supercomputing.org/<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsc23.supe…> https://sc23.supercomputing.org/scinet/network-research-exhibition/<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsc23.supe…> Any questions can be directed to nre-xnet-leads(a)scinet.supercomputing.org<mailto:nre-xnet-leads@scinet.supercomputing.org> Please feel free to forward to your email lists, networks, and anyone else who may be interested in submitting an NRE proposal. Thank you ! NRE / XNET Leads Debbie Fligor Andrew Lee Brenna Meade

1 0

2025

2024

2023

2022

2021

Routing-wg