- mice-discuss - lists.micemn.net

Re: IRR Mandatory at MICE / New Route Servers

by Richard Laager

On 2023-05-11 10:30, Chris Wopat wrote: > Can't folks just specify which IRR in their IRR entry if desired? Ie > > ARIN::AS1234 1. bgpq3 does not accept that format, at least in my limited testing. 2. IXP Manager would likely need changes to support that, specifically not passing the argument for sources to bgpq3 if a disambiguation was provided. 3. I think the more important fundamental issue is that a transit AS's as-set might need to reference customer ASes/as-sets that are in other registries. > FWIW we only use RADB but are fine if the common IRR's (but not legacy > arin) are used. > > Also is there any reason at all to use non-ARIN teritory IRR data? Do > any MICE participants have anything in RIPE for example? See #3 above. For example, someone like Hurricane Electric can't ask all of their customers worldwide to be in ARIN. Given the way this has historically developed, I don't think it's even reasonable to expect that only-RIR registries are used. -- Richard

May 11, 2023

Re: [External] Re: [MICE-DISCUSS] IRR Mandatory at MICE / New Route Servers

by Tom Krenn

Would it be safe to assume that squatting wouldn't happen in the RIR's authenticated IRRs? And that if multiple entries exist among them, that keeping them in sync or free of bad data would be on the individual participant? If so placing the authenticated RIRs above everything else seems a pretty safe bet. Order among them wouldn't really matter. Personally given that I would love to see us grab the sets from the aut-num object for the participants ASN. Seems like ignoring the routing policy in the aut-num object in favor of PeeringDB or a manual process is only half using the IRR system. (That said I understand that bgpq3 doesn't use the aut-num object.) Tom Krenn Network Architect Enterprise Architecture - Information Technology -----Original Message----- From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Chris Wopat Sent: Thursday, May 11, 2023 10:30 AM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: [External] Re: [MICE-DISCUSS] IRR Mandatory at MICE / New Route Servers CAUTION: This email was sent from outside of Hennepin County. Unless you recognize the sender and know the content, do not click links or open attachments. Can't folks just specify which IRR in their IRR entry if desired? Ie ARIN::AS1234 FWIW we only use RADB but are fine if the common IRR's (but not legacy arin) are used. Also is there any reason at all to use non-ARIN teritory IRR data? Do any MICE participants have anything in RIPE for example? --Chris On 5/11/23 10:01, Jeremy Lumby wrote: > External > > I do not see a need for per participant IRR, I would rather that they > all just default to your example below. > > *From:*MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> *On Behalf Of > *Richard Laager > *Sent:* Thursday, May 11, 2023 3:58 AM > *To:* MICE-DISCUSS(a)LISTS.IPHOUSE.NET > *Subject:* Re: [MICE-DISCUSS] IRR Mandatory at MICE / New Route > Servers > > On 2023-05-09 14:01, August Yang wrote: > > Should I reorder RADB,ARIN to be ARIN,RADB? > > Definitely. We have objects registered in all databases feasible to > prevent AS-SET squatting, which has occurred in the past, while only > RADB has the actual members listed. Turns out correct prefix list > can be generated using bgpq4 regardless of the order, so it's better > to prioritize authenticated sources. > > In thinking about this some more... Is IXP Manager's behavior of > per-participant IRR sources actually useful? In other words, what's > wrong with just setting everyone to: > ARIN,RIPE,LACNIC,APNIC,AFRINIC,RADB,LEVEL3? > > -- > > Richard > > ---------------------------------------------------------------------- > -- > > To unsubscribe from the MICE-DISCUSS list, click the following link: > https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists > .iphouse.net%2Fcgi-bin%2Fwa%3FSUBED1%3DMICE-DISCUSS%26A%3D1&data=05%7C > 01%7Ctom.krenn%40HENNEPIN.US%7C2f7c1b8d95af410486a008db5234a38e%7C8aef > df9f878046bf8fb74c924653a8be%7C0%7C0%7C638194158303151171%7CUnknown%7C > TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC > I6Mn0%3D%7C3000%7C%7C%7C&sdata=hdjzW0mk8Kd2pgvauE5I0544Xhlox3CaSJ%2FaF > NQAWWg%3D&reserved=0 > <https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist > s.iphouse.net%2Fcgi-bin%2Fwa%3FSUBED1%3DMICE-DISCUSS%26A%3D1&data=05%7 > C01%7Ctom.krenn%40HENNEPIN.US%7C2f7c1b8d95af410486a008db5234a38e%7C8ae > fdf9f878046bf8fb74c924653a8be%7C0%7C0%7C638194158303151171%7CUnknown%7 > CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV > CI6Mn0%3D%7C3000%7C%7C%7C&sdata=hdjzW0mk8Kd2pgvauE5I0544Xhlox3CaSJ%2Fa > FNQAWWg%3D&reserved=0> > > > ---------------------------------------------------------------------- > -- > > To unsubscribe from the MICE-DISCUSS list, click the following link: > https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists > .iphouse.net%2Fcgi-bin%2Fwa%3FSUBED1%3DMICE-DISCUSS%26A%3D1&data=05%7C > 01%7Ctom.krenn%40HENNEPIN.US%7C2f7c1b8d95af410486a008db5234a38e%7C8aef > df9f878046bf8fb74c924653a8be%7C0%7C0%7C638194158303151171%7CUnknown%7C > TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC > I6Mn0%3D%7C3000%7C%7C%7C&sdata=hdjzW0mk8Kd2pgvauE5I0544Xhlox3CaSJ%2FaF > NQAWWg%3D&reserved=0 > <https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist > s.iphouse.net%2Fcgi-bin%2Fwa%3FSUBED1%3DMICE-DISCUSS%26A%3D1&data=05%7 > C01%7Ctom.krenn%40HENNEPIN.US%7C2f7c1b8d95af410486a008db5234a38e%7C8ae > fdf9f878046bf8fb74c924653a8be%7C0%7C0%7C638194158303151171%7CUnknown%7 > CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV > CI6Mn0%3D%7C3000%7C%7C%7C&sdata=hdjzW0mk8Kd2pgvauE5I0544Xhlox3CaSJ%2Fa > FNQAWWg%3D&reserved=0> > -- Chris Wopat Network Engineer, WiscNet wopat(a)wiscnet.net 608-210-3965 Disclaimer: If you are not the intended recipient of this message, please immediately notify the sender of the transmission error and then promptly permanently delete this message from your computer system.

May 11, 2023

Re: IRR Mandatory at MICE / New Route Servers

by Jay Hanke

> Also is there any reason at all to use non-ARIN teritory IRR data? Do > any MICE participants have anything in RIPE for example? There are several outside the ARIN region and likely more in the future.

May 11, 2023

Re: IRR Mandatory at MICE / New Route Servers

by Chris Wopat

Can't folks just specify which IRR in their IRR entry if desired? Ie ARIN::AS1234 FWIW we only use RADB but are fine if the common IRR's (but not legacy arin) are used. Also is there any reason at all to use non-ARIN teritory IRR data? Do any MICE participants have anything in RIPE for example? --Chris On 5/11/23 10:01, Jeremy Lumby wrote: > External > > I do not see a need for per participant IRR, I would rather that they > all just default to your example below. > > *From:*MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> *On Behalf Of > *Richard Laager > *Sent:* Thursday, May 11, 2023 3:58 AM > *To:* MICE-DISCUSS(a)LISTS.IPHOUSE.NET > *Subject:* Re: [MICE-DISCUSS] IRR Mandatory at MICE / New Route Servers > > On 2023-05-09 14:01, August Yang wrote: > > Should I reorder RADB,ARIN to be ARIN,RADB? > > Definitely. We have objects registered in all databases feasible to > prevent AS-SET squatting, which has occurred in the past, while only > RADB has the actual members listed. Turns out correct prefix list > can be generated using bgpq4 regardless of the order, so it's better > to prioritize authenticated sources. > > In thinking about this some more... Is IXP Manager's behavior of > per-participant IRR sources actually useful? In other words, what's > wrong with just setting everyone to: > ARIN,RIPE,LACNIC,APNIC,AFRINIC,RADB,LEVEL3? > > -- > > Richard > > ------------------------------------------------------------------------ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > <http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1> > > > ------------------------------------------------------------------------ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > <http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1> > -- Chris Wopat Network Engineer, WiscNet wopat(a)wiscnet.net 608-210-3965

May 11, 2023

Re: IRR Mandatory at MICE / New Route Servers

by Jeremy Lumby

I do not see a need for per participant IRR, I would rather that they all just default to your example below. From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Richard Laager Sent: Thursday, May 11, 2023 3:58 AM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] IRR Mandatory at MICE / New Route Servers On 2023-05-09 14:01, August Yang wrote: Should I reorder RADB,ARIN to be ARIN,RADB? Definitely. We have objects registered in all databases feasible to prevent AS-SET squatting, which has occurred in the past, while only RADB has the actual members listed. Turns out correct prefix list can be generated using bgpq4 regardless of the order, so it's better to prioritize authenticated sources. In thinking about this some more... Is IXP Manager's behavior of per-participant IRR sources actually useful? In other words, what's wrong with just setting everyone to: ARIN,RIPE,LACNIC,APNIC,AFRINIC,RADB,LEVEL3? -- Richard _____ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS <http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1> &A=1

May 11, 2023

Re: [EXTERNAL] - Re: [MICE-DISCUSS] IRR Mandatory at MICE / New Route Servers

by Miles McCredie

I think a global list of sources would be easier to maintain and document. Is NTTCOM no longer trusted? I took a look at the AS11232 customer cone and there are a few objects in NTTCOM but it looked as though all of them also appear in another database so I don't have strong feelings that NTTCOM needs to be included. [http://images.midcocomm.com/ES_MidcoLogo.png] Miles McCredie Principal Network Engineer II-Core IP Office: 6052755192 Miles.McCredie(a)midco.com Midco.com From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Richard Laager Sent: Thursday, May 11, 2023 3:58 AM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: [EXTERNAL] - Re: [MICE-DISCUSS] IRR Mandatory at MICE / New Route Servers CAUTION: This email originated from outside of MIDCO. Do not click links or open attachments unless you recognize the sender and know the content is safe. On 2023-05-09 14:01, August Yang wrote: Should I reorder RADB,ARIN to be ARIN,RADB? Definitely. We have objects registered in all databases feasible to prevent AS-SET squatting, which has occurred in the past, while only RADB has the actual members listed. Turns out correct prefix list can be generated using bgpq4 regardless of the order, so it's better to prioritize authenticated sources. In thinking about this some more... Is IXP Manager's behavior of per-participant IRR sources actually useful? In other words, what's wrong with just setting everyone to: ARIN,RIPE,LACNIC,APNIC,AFRINIC,RADB,LEVEL3? -- Richard ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

May 11, 2023

Re: IRR Mandatory at MICE / New Route Servers

by Richard Laager

On 2023-05-09 14:01, August Yang wrote: > >> Should I reorder RADB,ARIN to be ARIN,RADB? > Definitely. We have objects registered in all databases feasible to > prevent AS-SET squatting, which has occurred in the past, while only > RADB has the actual members listed. Turns out correct prefix list can > be generated using bgpq4 regardless of the order, so it's better to > prioritize authenticated sources. In thinking about this some more... Is IXP Manager's behavior of per-participant IRR sources actually useful? In other words, what's wrong with just setting everyone to: ARIN,RIPE,LACNIC,APNIC,AFRINIC,RADB,LEVEL3? -- Richard

May 11, 2023

Re: IRR Mandatory at MICE / New Route Servers

by Richard Laager

On 2023-05-09 14:16, Jonathan Stewart wrote: > In my (limited) experience, the filter generator makes a prefix-list > using objects from all the approved IRRs that match the contents of the > AS-SET. > > In my case, that means route(6) objects from ARIN and RADB are combined > to make a prefix-list that's bigger than just ARIN or RADB-sourced objects. > > The order has not been relevant, nor specified. FWIW, MICE is going to use IXP Manager's direct bird templating, not arouteserver (like MBIX uses), so the way this works may be slightly different. -- Richard

May 10, 2023

Re: IRR Mandatory at MICE / New Route Servers

by Jonathan Stewart

On Tue, 2023-05-09 1:20 p.m., Richard Laager wrote: > I am specifically interested in feedback on this point. But please, > only real-world scenarios, no speculation ("someone might ..."). > > Background: > > * This setting is per-participant. > * Order is important. When looking for a given IRR object, the first > source that includes that object will be used. > In my (limited) experience, the filter generator makes a prefix-list using objects from all the approved IRRs that match the contents of the AS-SET. In my case, that means route(6) objects from ARIN and RADB are combined to make a prefix-list that's bigger than just ARIN or RADB-sourced objects. The order has not been relevant, nor specified. No need for NONAUTH sources, and ARIN has completely retired theirs. Cheers, Jonathan Jonathan Stewart Network Engineer LES.NET - AS18451 Desk: 1-204-666-6191 Mobile: 1-204-990-2120 130 Portage Avenue E Winnipeg, MB R3C 0A1 CANADA > * I think we want to prefer RIR-authenticated sources over others. > > Questions: > > 1. Should I reorder RADB,ARIN to be ARIN,RADB and similar for > RADB,RIPE and RADB,APNIC,ARIN? Tentative: Yes. > 2. Should I drop RIPE-NONAUTH choices? Tentative: If nobody is using > it by the end of this, I'll just remove it. > 3. Does anyone know if AFRINIC, APNIC, and LACNIC are authenticated? > 4. Does anyone know if people care about LEVEL3's IRR? Tentative: If > nobody is using it by the end of this, I'll just remove it. > 5. How do I set the source per participant? I /think/ what we want is > the following, for each participant: > > 1. I use RADB's web interface to view the specified as-set. If > the "source" of that object is an RIR registry, e.g. ARIN, I > set the source in IXP Manager to that RIR source. If the > source is RADB, I set the source to $RIR,RADB where $RIR is > the RIR that issued the participant's ASN. For example, if > someone is in the ARIN region, ARIN. If someone is in the RIPE > region, RIPE. The idea is to make it easy for them to move to > the RIR registry in the future. > 2. I manually trigger the AS and prefix update and make sure I > get results. > 3. If the source is just $RIR, I then change this to $RIR,RADB. I > manually trigger the AS and prefix update. If that second > update changed nothing, I remove RADB. If that update did > change something, then I eyeball it and make a decision. I > would be looking to detect the scenario where e.g. the as-set > is in the ARIN region but references customer ASes/as-sets > that are in RADB; in such a case, I need to allow RADB. In > contrast, if the records in RADB appear to be outdated and > someone has moved to ARIN, I would want to remove RADB. > > If that becomes too tedious, a fallback option is to set everyone > to something like ARIN,RIPE,RADB or > ARIN,RIPE,LACNIC,APNIC,AFRINIC,RADB. (The order of the RIRs is > negotiable. I don't really know much about non-ARIN IRR.) > > > On 5/9/23 11:25, Jay Hanke wrote: >> Here are the current IRR sources. Please note ARIN-NONAUTH is not >> included. >> >> whois.radb.net <http://whois.radb.net> RIPE >> whois.radb.net <http://whois.radb.net> RIPE,RIPE-NONAUTH >> whois.radb.net <http://whois.radb.net> RADB >> whois.radb.net <http://whois.radb.net> LACNIC >> whois.radb.net <http://whois.radb.net> AFRINIC >> whois.radb.net <http://whois.radb.net> APNIC >> whois.radb.net <http://whois.radb.net> LEVEL3 >> whois.radb.net <http://whois.radb.net> ARIN >> whois.radb.net <http://whois.radb.net> RADB,ARIN >> whois.radb.net <http://whois.radb.net> ALTDB >> whois.radb.net <http://whois.radb.net> RADB,RIPE >> whois.radb.net <http://whois.radb.net> RADB,APNIC,ARIN >> whois.radb.net <http://whois.radb.net> RIPE,ARIN >> >> On Tue, May 9, 2023 at 11:14 AM August Yang >> <0000001654c01f33-dmarc-request(a)lists.iphouse.net> wrote: >> >> Could you please clarify which IRR source will be included for >> filter generation? We currently rely on RADb instead of ARIN for >> our IRR records, and it would be helpful to confirm if this will >> be used with the new route servers. >> > -- > Richard > > ------------------------------------------------------------------------ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > <http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1> >

May 9, 2023

Re: IRR Mandatory at MICE / New Route Servers

by August Yang

> Should I reorder RADB,ARIN to be ARIN,RADB? Definitely. We have objects registered in all databases feasible to prevent AS-SET squatting, which has occurred in the past, while only RADB has the actual members listed. Turns out correct prefix list can be generated using bgpq4 regardless of the order, so it's better to prioritize authenticated sources. > Should I drop RIPE-NONAUTH choices? Should I drop LEVEL3? Yes and no. RIPE-NONAUTH is essentially a dead database with no editing or new objects possible while LEVEL3 is actively used and there's no advantage in excluding it. > Does anyone know if AFRINIC, APNIC, and LACNIC are authenticated? At this point all RIR databases are authenticated. On 2023-05-09 2:20 p.m., Richard Laager wrote: > I am specifically interested in feedback on this point. But please, > only real-world scenarios, no speculation ("someone might ..."). > > Background: > > * This setting is per-participant. > * Order is important. When looking for a given IRR object, the first > source that includes that object will be used. > * I think we want to prefer RIR-authenticated sources over others. > > Questions: > > 1. Should I reorder RADB,ARIN to be ARIN,RADB and similar for > RADB,RIPE and RADB,APNIC,ARIN? Tentative: Yes. > 2. Should I drop RIPE-NONAUTH choices? Tentative: If nobody is using > it by the end of this, I'll just remove it. > 3. Does anyone know if AFRINIC, APNIC, and LACNIC are authenticated? > 4. Does anyone know if people care about LEVEL3's IRR? Tentative: If > nobody is using it by the end of this, I'll just remove it. > 5. How do I set the source per participant? I /think/ what we want is > the following, for each participant: > > 1. I use RADB's web interface to view the specified as-set. If > the "source" of that object is an RIR registry, e.g. ARIN, I > set the source in IXP Manager to that RIR source. If the > source is RADB, I set the source to $RIR,RADB where $RIR is > the RIR that issued the participant's ASN. For example, if > someone is in the ARIN region, ARIN. If someone is in the RIPE > region, RIPE. The idea is to make it easy for them to move to > the RIR registry in the future. > 2. I manually trigger the AS and prefix update and make sure I > get results. > 3. If the source is just $RIR, I then change this to $RIR,RADB. I > manually trigger the AS and prefix update. If that second > update changed nothing, I remove RADB. If that update did > change something, then I eyeball it and make a decision. I > would be looking to detect the scenario where e.g. the as-set > is in the ARIN region but references customer ASes/as-sets > that are in RADB; in such a case, I need to allow RADB. In > contrast, if the records in RADB appear to be outdated and > someone has moved to ARIN, I would want to remove RADB. > > If that becomes too tedious, a fallback option is to set everyone > to something like ARIN,RIPE,RADB or > ARIN,RIPE,LACNIC,APNIC,AFRINIC,RADB. (The order of the RIRs is > negotiable. I don't really know much about non-ARIN IRR.) > > > On 5/9/23 11:25, Jay Hanke wrote: >> Here are the current IRR sources. Please note ARIN-NONAUTH is not >> included. >> >> whois.radb.net <http://whois.radb.net> RIPE >> whois.radb.net <http://whois.radb.net> RIPE,RIPE-NONAUTH >> whois.radb.net <http://whois.radb.net> RADB >> whois.radb.net <http://whois.radb.net> LACNIC >> whois.radb.net <http://whois.radb.net> AFRINIC >> whois.radb.net <http://whois.radb.net> APNIC >> whois.radb.net <http://whois.radb.net> LEVEL3 >> whois.radb.net <http://whois.radb.net> ARIN >> whois.radb.net <http://whois.radb.net> RADB,ARIN >> whois.radb.net <http://whois.radb.net> ALTDB >> whois.radb.net <http://whois.radb.net> RADB,RIPE >> whois.radb.net <http://whois.radb.net> RADB,APNIC,ARIN >> whois.radb.net <http://whois.radb.net> RIPE,ARIN >> >> On Tue, May 9, 2023 at 11:14 AM August Yang >> <0000001654c01f33-dmarc-request(a)lists.iphouse.net> wrote: >> >> Could you please clarify which IRR source will be included for >> filter generation? We currently rely on RADb instead of ARIN for >> our IRR records, and it would be helpful to confirm if this will >> be used with the new route servers. >> > -- > Richard > > ------------------------------------------------------------------------ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > <http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1> > -- Best regards August Yang

May 9, 2023

Re: IRR Mandatory at MICE / New Route Servers

by Richard Laager

I am specifically interested in feedback on this point. But please, only real-world scenarios, no speculation ("someone might ..."). Background: * This setting is per-participant. * Order is important. When looking for a given IRR object, the first source that includes that object will be used. * I think we want to prefer RIR-authenticated sources over others. Questions: 1. Should I reorder RADB,ARIN to be ARIN,RADB and similar for RADB,RIPE and RADB,APNIC,ARIN? Tentative: Yes. 2. Should I drop RIPE-NONAUTH choices? Tentative: If nobody is using it by the end of this, I'll just remove it. 3. Does anyone know if AFRINIC, APNIC, and LACNIC are authenticated? 4. Does anyone know if people care about LEVEL3's IRR? Tentative: If nobody is using it by the end of this, I'll just remove it. 5. How do I set the source per participant? I /think/ what we want is the following, for each participant: 1. I use RADB's web interface to view the specified as-set. If the "source" of that object is an RIR registry, e.g. ARIN, I set the source in IXP Manager to that RIR source. If the source is RADB, I set the source to $RIR,RADB where $RIR is the RIR that issued the participant's ASN. For example, if someone is in the ARIN region, ARIN. If someone is in the RIPE region, RIPE. The idea is to make it easy for them to move to the RIR registry in the future. 2. I manually trigger the AS and prefix update and make sure I get results. 3. If the source is just $RIR, I then change this to $RIR,RADB. I manually trigger the AS and prefix update. If that second update changed nothing, I remove RADB. If that update did change something, then I eyeball it and make a decision. I would be looking to detect the scenario where e.g. the as-set is in the ARIN region but references customer ASes/as-sets that are in RADB; in such a case, I need to allow RADB. In contrast, if the records in RADB appear to be outdated and someone has moved to ARIN, I would want to remove RADB. If that becomes too tedious, a fallback option is to set everyone to something like ARIN,RIPE,RADB or ARIN,RIPE,LACNIC,APNIC,AFRINIC,RADB. (The order of the RIRs is negotiable. I don't really know much about non-ARIN IRR.) On 5/9/23 11:25, Jay Hanke wrote: > Here are the current IRR sources. Please note ARIN-NONAUTH is not > included. > > whois.radb.net <http://whois.radb.net> RIPE > whois.radb.net <http://whois.radb.net> RIPE,RIPE-NONAUTH > whois.radb.net <http://whois.radb.net> RADB > whois.radb.net <http://whois.radb.net> LACNIC > whois.radb.net <http://whois.radb.net> AFRINIC > whois.radb.net <http://whois.radb.net> APNIC > whois.radb.net <http://whois.radb.net> LEVEL3 > whois.radb.net <http://whois.radb.net> ARIN > whois.radb.net <http://whois.radb.net> RADB,ARIN > whois.radb.net <http://whois.radb.net> ALTDB > whois.radb.net <http://whois.radb.net> RADB,RIPE > whois.radb.net <http://whois.radb.net> RADB,APNIC,ARIN > whois.radb.net <http://whois.radb.net> RIPE,ARIN > > On Tue, May 9, 2023 at 11:14 AM August Yang > <0000001654c01f33-dmarc-request(a)lists.iphouse.net> wrote: > > Could you please clarify which IRR source will be included for > filter generation? We currently rely on RADb instead of ARIN for > our IRR records, and it would be helpful to confirm if this will > be used with the new route servers. > -- Richard

May 9, 2023

Re: [External] [MICE-DISCUSS] IRR Mandatory at MICE / New Route Servers

by Richard Laager

On 5/9/23 12:54, Tom Krenn wrote: > > Will the filters be built off our aut-num object or just the as-set > listed on PeeringDB? > I /think/ they just use the as-set. Last night, I tested the underlying command against someone who does not have an aut-num, but does have route objects referencing their AS. Their prefixes were found. The underlying command is bgpq3. So if you really want to get low level, install that somewhere and run bgpq3 AS_SET_NAME and bgpq3 -6 AS_SET_NAME. IXP Manager actually runs that with more flags, but they aren't particular relevant (other than minimum prefix length). -- Richard

May 9, 2023

Re: [External] [MICE-DISCUSS] IRR Mandatory at MICE / New Route Servers

by Jay Hanke

This is what we are seeing in IXP Manager. Looks like your config got pulled from PeeringDB. Network Information =================== Name : HENNEPIN-COUNTY Primary ASN : 40382 Also Known As : Website : https://www.hennepin.us/ IRR AS-SET : AS40382:AS-MEMBERS Network Type : Government Approx IPv6 Prefixes : 100 Approx IPv4 Prefixes : 100 Looking Glass : Route Server : Created at : 2021-12-21T16:47:05Z Updated at : 2022-08-29T22:55:11Z PrefixFirst seenLast seen 137.70.0.0/16 <https://ixpmgr.micemn.net/index.php#ixpm-prefix-whois-43ffe576808e1d023202a…> 2023-03-27 00:08:07 2023-05-09 12:55:43 204.73.55.0/24 <https://ixpmgr.micemn.net/index.php#ixpm-prefix-whois-74fb2430d7d8ea4b1f390…> 2023-03-27 00:08:07 2023-05-09 12:55:43 50.217.178.0/24 <https://ixpmgr.micemn.net/index.php#ixpm-prefix-whois-4add3bae394355548a2e8…> 2023-03-27 00:08:07 2023-05-09 12:55:43 PrefixFirst seenLast seen 2606:e540::/32 <https://ixpmgr.micemn.net/index.php#ixpm-prefix-whois-62695e9e020d26faf9540…> 2023-03-27 00:08:07 2023-05-09 12:55:43 2606:e540::/36 <https://ixpmgr.micemn.net/index.php#ixpm-prefix-whois-5ed6e7f9e0a5db531a80d…> 2023-03-27 00:08:07 2023-05-09 12:55:43 On Tue, May 9, 2023 at 12:54 PM Tom Krenn < 00000015253bd7fc-dmarc-request(a)lists.iphouse.net> wrote: > Will the filters be built off our aut-num object or just the as-set listed > on PeeringDB? > > > > Tom Krenn > > Network Architect > > Enterprise Architecture - Information Technology > > [image: Hennepin County logo] > > > > > > *From:* MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> * On Behalf Of *Richard > Laager > *Sent:* Tuesday, May 9, 2023 5:20 AM > *To:* MICE-DISCUSS(a)LISTS.IPHOUSE.NET > *Subject:* [External] [MICE-DISCUSS] IRR Mandatory at MICE / New Route > Servers > > > > *CAUTION:* This email was sent from outside of Hennepin County. Unless > you recognize the sender and know the content, do not click links or open > attachments. > > [I plan to send this to MICE-ANNOUNCE too, but I want to see if anyone has > corrections.] > > MICE will soon be deploying new route servers which will require IRR > (Internet Routing Registry) records, as is a best practice at IXPs. > > *What* > > - You MUST have an as-set object listing your AS and your downstream > ASes (if any). > > > - You MUST either list that as-set in PeeringDB or email the name of > your as-set to me (off-list to rlaager(a)wiktel.com please). > > > - A route/route6 object MUST exist for each prefix you announce to the > route servers (whether originated by you or transited through you) and it > must list an Origin AS that is in your as-set. > > *When* > > - *If you are a transit AS (i.e. have ASes behind you) and don't have > an as-set object, fix this now.* Without an as-set object, your > downstream ASes announcements will be blocked (filtered) immediately when > the *first* new route server is cut in. (Granted, they will still > work through the second route server until it is upgraded.) Figure you have > 1-2 weeks at most. > - Enforcement of the route/route6 objects (for both transit and > non-transit ASes) will come later, but not a lot later. So please, start on > this now. > > *Where* > > If you are not sure *where* to create IRR records, use ARIN (assuming you > are in the ARIN region). > > *How (with ARIN)* > > 1. Login to ARIN Online. (Go to arin.net and click Login in the top > right.) > 2. On the left side, expand "Routing Security" and click "IRR". > 3. Click "as-set" at the top. > 4. Click "Create an Object". > 5. Fill in the fields: > The "AS Set Name" is what you will list in PeeringDB (or email to me). > "Description" is unparsed, but they suggest the location and have a > button to "Copy the Address from My Org ID". > "Members" is where you list your ASN and downstream ASes (if any). > 6. Click "Review". Once ready, click "Submit". > 7. Click "route/route6" at the top. > 8. Click "Create an Object". > 9. Fill in the fields: > "Prefix" is the prefix, e.g. 192.0.2.0/24. > "Origin" is your ASN. > 10. Click "Review". Once ready, click "Submit". > 11. Repeat to create additional route objects until all of your > announcements are covered. Don't forget IPv6! > > *Examples* > > Here is my as-set: https://www.radb.net/query?keywords=AS-WIKTEL > > Here is one example route: > https://www.radb.net/query?keywords=69.89.192.0%2F20 > > (I created the AS33362 one. The AS19905 one is because another AS can > originate this route for DDoS scrubbing reasons.) > > -- > > Richard > > > ------------------------------ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > > > *Disclaimer:* If you are not the intended recipient of this message, > please immediately notify the sender of the transmission error and then > promptly permanently delete this message from your computer system. > > ------------------------------ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 >

May 9, 2023

Re: [External] [MICE-DISCUSS] IRR Mandatory at MICE / New Route Servers

by Tom Krenn

Will the filters be built off our aut-num object or just the as-set listed on PeeringDB? Tom Krenn Network Architect Enterprise Architecture - Information Technology [Hennepin County logo] From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Richard Laager Sent: Tuesday, May 9, 2023 5:20 AM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: [External] [MICE-DISCUSS] IRR Mandatory at MICE / New Route Servers CAUTION: This email was sent from outside of Hennepin County. Unless you recognize the sender and know the content, do not click links or open attachments. [I plan to send this to MICE-ANNOUNCE too, but I want to see if anyone has corrections.] MICE will soon be deploying new route servers which will require IRR (Internet Routing Registry) records, as is a best practice at IXPs. What * You MUST have an as-set object listing your AS and your downstream ASes (if any). * You MUST either list that as-set in PeeringDB or email the name of your as-set to me (off-list to rlaager(a)wiktel.com<mailto:rlaager@wiktel.com> please). * A route/route6 object MUST exist for each prefix you announce to the route servers (whether originated by you or transited through you) and it must list an Origin AS that is in your as-set. When * If you are a transit AS (i.e. have ASes behind you) and don't have an as-set object, fix this now. Without an as-set object, your downstream ASes announcements will be blocked (filtered) immediately when the first new route server is cut in. (Granted, they will still work through the second route server until it is upgraded.) Figure you have 1-2 weeks at most. * Enforcement of the route/route6 objects (for both transit and non-transit ASes) will come later, but not a lot later. So please, start on this now. Where If you are not sure where to create IRR records, use ARIN (assuming you are in the ARIN region). How (with ARIN) 1. Login to ARIN Online. (Go to arin.net and click Login in the top right.) 2. On the left side, expand "Routing Security" and click "IRR". 3. Click "as-set" at the top. 4. Click "Create an Object". 5. Fill in the fields: The "AS Set Name" is what you will list in PeeringDB (or email to me). "Description" is unparsed, but they suggest the location and have a button to "Copy the Address from My Org ID". "Members" is where you list your ASN and downstream ASes (if any). 6. Click "Review". Once ready, click "Submit". 7. Click "route/route6" at the top. 8. Click "Create an Object". 9. Fill in the fields: "Prefix" is the prefix, e.g. 192.0.2.0/24. "Origin" is your ASN. 10. Click "Review". Once ready, click "Submit". 11. Repeat to create additional route objects until all of your announcements are covered. Don't forget IPv6! Examples Here is my as-set: https://www.radb.net/query?keywords=AS-WIKTEL Here is one example route: https://www.radb.net/query?keywords=69.89.192.0%2F20 (I created the AS33362 one. The AS19905 one is because another AS can originate this route for DDoS scrubbing reasons.) -- Richard ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 Disclaimer: If you are not the intended recipient of this message, please immediately notify the sender of the transmission error and then promptly permanently delete this message from your computer system.

May 9, 2023

Re: IRR Mandatory at MICE / New Route Servers

by Jay Hanke

Here are the current IRR sources. Please note ARIN-NONAUTH is not included. whois.radb.net RIPE whois.radb.net RIPE,RIPE-NONAUTH whois.radb.net RADB whois.radb.net LACNIC whois.radb.net AFRINIC whois.radb.net APNIC whois.radb.net LEVEL3 whois.radb.net ARIN whois.radb.net RADB,ARIN whois.radb.net ALTDB whois.radb.net RADB,RIPE whois.radb.net RADB,APNIC,ARIN whois.radb.net RIPE,ARIN On Tue, May 9, 2023 at 11:14 AM August Yang < 0000001654c01f33-dmarc-request(a)lists.iphouse.net> wrote: > Thank you for your efforts in making routing more secure for the entire > MICE community. > > Could you please clarify which IRR source will be included for filter > generation? We currently rely on RADb instead of ARIN for our IRR records, > and it would be helpful to confirm if this will be used with the new route > servers. > On 2023-05-09 6:19 a.m., Richard Laager wrote: > > [I plan to send this to MICE-ANNOUNCE too, but I want to see if anyone has > corrections.] > > MICE will soon be deploying new route servers which will require IRR > (Internet Routing Registry) records, as is a best practice at IXPs. > > *What* > > - You MUST have an as-set object listing your AS and your downstream > ASes (if any). > - You MUST either list that as-set in PeeringDB or email the name > of your as-set to me (off-list to rlaager(a)wiktel.com please). > - A route/route6 object MUST exist for each prefix you announce to > the route servers (whether originated by you or transited through you) and > it must list an Origin AS that is in your as-set. > > *When* > > - *If you are a transit AS (i.e. have ASes behind you) and don't have > an as-set object, fix this **now**.* Without an as-set object, your > downstream ASes announcements will be blocked (filtered) immediately when > the *first* new route server is cut in. (Granted, they will still > work through the second route server until it is upgraded.) Figure you have > 1-2 weeks at most. > - Enforcement of the route/route6 objects (for both transit and > non-transit ASes) will come later, but not a lot later. So please, start on > this now. > > *Where* > > If you are not sure *where* to create IRR records, use ARIN (assuming you > are in the ARIN region). > > *How (with ARIN)* > > 1. Login to ARIN Online. (Go to arin.net and click Login in the top > right.) > 2. On the left side, expand "Routing Security" and click "IRR". > 3. Click "as-set" at the top. > 4. Click "Create an Object". > 5. Fill in the fields: > The "AS Set Name" is what you will list in PeeringDB (or email to me). > "Description" is unparsed, but they suggest the location and have a > button to "Copy the Address from My Org ID". > "Members" is where you list your ASN and downstream ASes (if any). > 6. Click "Review". Once ready, click "Submit". > 7. Click "route/route6" at the top. > 8. Click "Create an Object". > 9. Fill in the fields: > "Prefix" is the prefix, e.g. 192.0.2.0/24. > "Origin" is your ASN. > 10. Click "Review". Once ready, click "Submit". > 11. Repeat to create additional route objects until all of your > announcements are covered. Don't forget IPv6! > > *Examples* > > Here is my as-set: https://www.radb.net/query?keywords=AS-WIKTEL > > Here is one example route: > https://www.radb.net/query?keywords=69.89.192.0%2F20 > > (I created the AS33362 one. The AS19905 one is because another AS can > originate this route for DDoS scrubbing reasons.) > > -- > Richard > > > ------------------------------ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > > -- > Best regards > August Yang > > ------------------------------ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 >

May 9, 2023

Re: IRR Mandatory at MICE / New Route Servers

by August Yang

Thank you for your efforts in making routing more secure for the entire MICE community. Could you please clarify which IRR source will be included for filter generation? We currently rely on RADb instead of ARIN for our IRR records, and it would be helpful to confirm if this will be used with the new route servers. On 2023-05-09 6:19 a.m., Richard Laager wrote: > > [I plan to send this to MICE-ANNOUNCE too, but I want to see if anyone > has corrections.] > > MICE will soon be deploying new route servers which will require IRR > (Internet Routing Registry) records, as is a best practice at IXPs. > > *What* > > * You MUST have an as-set object listing your AS and your downstream > ASes (if any). > o You MUST either list that as-set in PeeringDB or email the > name of your as-set to me (off-list to rlaager(a)wiktel.com please). > * A route/route6 object MUST exist for each prefix you announce to > the route servers (whether originated by you or transited through > you) and it must list an Origin AS that is in your as-set. > > *When* > > * *If you are a transit AS (i.e. have ASes behind you) and don't > have an /as-set/ object, fix this **/now/**.* Without an as-set > object, your downstream ASes announcements will be blocked > (filtered) immediately when the /first/ new route server is cut > in. (Granted, they will still work through the second route server > until it is upgraded.) Figure you have 1-2 weeks at most. > * Enforcement of the route/route6 objects (for both transit and > non-transit ASes) will come later, but not a lot later. So please, > start on this now. > > *Where* > > If you are not sure /where/ to create IRR records, use ARIN (assuming > you are in the ARIN region). > > *How (with ARIN)* > > 1. Login to ARIN Online. (Go to arin.net and click Login in the top > right.) > 2. On the left side, expand "Routing Security" and click "IRR". > 3. Click "as-set" at the top. > 4. Click "Create an Object". > 5. Fill in the fields: > The "AS Set Name" is what you will list in PeeringDB (or email to me). > "Description" is unparsed, but they suggest the location and have > a button to "Copy the Address from My Org ID". > "Members" is where you list your ASN and downstream ASes (if any). > 6. Click "Review". Once ready, click "Submit". > 7. Click "route/route6" at the top. > 8. Click "Create an Object". > 9. Fill in the fields: > "Prefix" is the prefix, e.g. 192.0.2.0/24. > "Origin" is your ASN. > 10. Click "Review". Once ready, click "Submit". > 11. Repeat to create additional route objects until all of your > announcements are covered. Don't forget IPv6! > > *Examples* > > Here is my as-set: https://www.radb.net/query?keywords=AS-WIKTEL > > Here is one example route: > https://www.radb.net/query?keywords=69.89.192.0%2F20 > > (I created the AS33362 one. The AS19905 one is because another AS can > originate this route for DDoS scrubbing reasons.) > > -- > Richard > > ------------------------------------------------------------------------ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > <http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1> > -- Best regards August Yang

May 9, 2023

Re: IRR Mandatory at MICE / New Route Servers

by Jay Hanke

MICE members are able to see their AS-SET entry in IXP manager but not edit the entries. If members would like to check what is currently in the system, here is the link: https://ixpmgr.micemn.net Log in with PeeringDB credentials for your network. RPKI invalids will be rejected on the new route servers upon deployment. On Tue, May 9, 2023 at 10:57 AM Andrew Hoyos <hoyosa(a)gmail.com> wrote: > > Thanks for your work on this, Richard! This is most excellent to see progress on. > > Will there be any "self-service" and/or visibility of this moving forward? (ie: IXP Manager login per member). > > Is RPKI validation part of this as well, or a future item (at least rejecting RPKI invalids from route servers)? > > > Thanks, > Andrew > > On May 9, 2023, at 5:19 AM, Richard Laager <rlaager(a)WIKTEL.COM> wrote: > > [I plan to send this to MICE-ANNOUNCE too, but I want to see if anyone has corrections.] > > MICE will soon be deploying new route servers which will require IRR (Internet Routing Registry) records, as is a best practice at IXPs. > > What > > You MUST have an as-set object listing your AS and your downstream ASes (if any). > > You MUST either list that as-set in PeeringDB or email the name of your as-set to me (off-list to rlaager(a)wiktel.com please). > > A route/route6 object MUST exist for each prefix you announce to the route servers (whether originated by you or transited through you) and it must list an Origin AS that is in your as-set. > > When > > If you are a transit AS (i.e. have ASes behind you) and don't have an as-set object, fix this now. Without an as-set object, your downstream ASes announcements will be blocked (filtered) immediately when the first new route server is cut in. (Granted, they will still work through the second route server until it is upgraded.) Figure you have 1-2 weeks at most. > Enforcement of the route/route6 objects (for both transit and non-transit ASes) will come later, but not a lot later. So please, start on this now. > > Where > > If you are not sure where to create IRR records, use ARIN (assuming you are in the ARIN region). > > How (with ARIN) > > Login to ARIN Online. (Go to arin.net and click Login in the top right.) > On the left side, expand "Routing Security" and click "IRR". > Click "as-set" at the top. > Click "Create an Object". > Fill in the fields: > The "AS Set Name" is what you will list in PeeringDB (or email to me). > "Description" is unparsed, but they suggest the location and have a button to "Copy the Address from My Org ID". > "Members" is where you list your ASN and downstream ASes (if any). > Click "Review". Once ready, click "Submit". > Click "route/route6" at the top. > Click "Create an Object". > Fill in the fields: > "Prefix" is the prefix, e.g. 192.0.2.0/24. > "Origin" is your ASN. > Click "Review". Once ready, click "Submit". > Repeat to create additional route objects until all of your announcements are covered. Don't forget IPv6! > > Examples > > Here is my as-set: https://www.radb.net/query?keywords=AS-WIKTEL > > Here is one example route: https://www.radb.net/query?keywords=69.89.192.0%2F20 > > (I created the AS33362 one. The AS19905 one is because another AS can originate this route for DDoS scrubbing reasons.) > > -- > Richard > > > ________________________________ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > > > > ________________________________ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

May 9, 2023

Re: IRR Mandatory at MICE / New Route Servers

by Andrew Hoyos

Thanks for your work on this, Richard! This is most excellent to see progress on. Will there be any "self-service" and/or visibility of this moving forward? (ie: IXP Manager login per member). Is RPKI validation part of this as well, or a future item (at least rejecting RPKI invalids from route servers)? Thanks, Andrew > On May 9, 2023, at 5:19 AM, Richard Laager <rlaager(a)WIKTEL.COM> wrote: > > [I plan to send this to MICE-ANNOUNCE too, but I want to see if anyone has corrections.] > > MICE will soon be deploying new route servers which will require IRR (Internet Routing Registry) records, as is a best practice at IXPs. > > What > > You MUST have an as-set object listing your AS and your downstream ASes (if any). > You MUST either list that as-set in PeeringDB or email the name of your as-set to me (off-list to rlaager(a)wiktel.com <mailto:rlaager@wiktel.com> please). > A route/route6 object MUST exist for each prefix you announce to the route servers (whether originated by you or transited through you) and it must list an Origin AS that is in your as-set. > When > > If you are a transit AS (i.e. have ASes behind you) and don't have an as-set object, fix this now. Without an as-set object, your downstream ASes announcements will be blocked (filtered) immediately when the first new route server is cut in. (Granted, they will still work through the second route server until it is upgraded.) Figure you have 1-2 weeks at most. > Enforcement of the route/route6 objects (for both transit and non-transit ASes) will come later, but not a lot later. So please, start on this now. > Where > > If you are not sure where to create IRR records, use ARIN (assuming you are in the ARIN region). > > How (with ARIN) > > Login to ARIN Online. (Go to arin.net and click Login in the top right.) > On the left side, expand "Routing Security" and click "IRR". > Click "as-set" at the top. > Click "Create an Object". > Fill in the fields: > The "AS Set Name" is what you will list in PeeringDB (or email to me). > "Description" is unparsed, but they suggest the location and have a button to "Copy the Address from My Org ID". > "Members" is where you list your ASN and downstream ASes (if any). > Click "Review". Once ready, click "Submit". > Click "route/route6" at the top. > Click "Create an Object". > Fill in the fields: > "Prefix" is the prefix, e.g. 192.0.2.0/24. > "Origin" is your ASN. > Click "Review". Once ready, click "Submit". > Repeat to create additional route objects until all of your announcements are covered. Don't forget IPv6! > Examples > > Here is my as-set: https://www.radb.net/query?keywords=AS-WIKTEL > > Here is one example route: https://www.radb.net/query?keywords=69.89.192.0%2F20 > > (I created the AS33362 one. The AS19905 one is because another AS can originate this route for DDoS scrubbing reasons.) > > -- > Richard > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 >

May 9, 2023

IRR Mandatory at MICE / New Route Servers

by Richard Laager

[I plan to send this to MICE-ANNOUNCE too, but I want to see if anyone has corrections.] MICE will soon be deploying new route servers which will require IRR (Internet Routing Registry) records, as is a best practice at IXPs. *What* * You MUST have an as-set object listing your AS and your downstream ASes (if any). o You MUST either list that as-set in PeeringDB or email the name of your as-set to me (off-list to rlaager(a)wiktel.com please). * A route/route6 object MUST exist for each prefix you announce to the route servers (whether originated by you or transited through you) and it must list an Origin AS that is in your as-set. *When* * *If you are a transit AS (i.e. have ASes behind you) and don't have an /as-set/ object, fix this **/now/**.* Without an as-set object, your downstream ASes announcements will be blocked (filtered) immediately when the /first/ new route server is cut in. (Granted, they will still work through the second route server until it is upgraded.) Figure you have 1-2 weeks at most. * Enforcement of the route/route6 objects (for both transit and non-transit ASes) will come later, but not a lot later. So please, start on this now. ** *Where* If you are not sure /where/ to create IRR records, use ARIN (assuming you are in the ARIN region). *How (with ARIN)* 1. Login to ARIN Online. (Go to arin.net and click Login in the top right.) 2. On the left side, expand "Routing Security" and click "IRR". 3. Click "as-set" at the top. 4. Click "Create an Object". 5. Fill in the fields: The "AS Set Name" is what you will list in PeeringDB (or email to me). "Description" is unparsed, but they suggest the location and have a button to "Copy the Address from My Org ID". "Members" is where you list your ASN and downstream ASes (if any). 6. Click "Review". Once ready, click "Submit". 7. Click "route/route6" at the top. 8. Click "Create an Object". 9. Fill in the fields: "Prefix" is the prefix, e.g. 192.0.2.0/24. "Origin" is your ASN. 10. Click "Review". Once ready, click "Submit". 11. Repeat to create additional route objects until all of your announcements are covered. Don't forget IPv6! *Examples* Here is my as-set: https://www.radb.net/query?keywords=AS-WIKTEL Here is one example route: https://www.radb.net/query?keywords=69.89.192.0%2F20 (I created the AS33362 one. The AS19905 one is because another AS can originate this route for DDoS scrubbing reasons.) -- Richard

May 9, 2023

Re: Midwest Peering Summit Info July 17-18th, 2023 Des Moines

by Joe Unger

Nevermind. False alarm. I overlooked the "Enter it now" button that is hiding in pain sight right below the Check In & Check Out windows. [image: image.png] On Mon, May 1, 2023 at 11:48 AM Joe Unger <joe(a)vaultas.com> wrote: > The Book Room Now link is working, but the Group Promo Code doesn't seem > to be working. > > Does anyone have any insight to share on that? > > Thanks, > Joe > > On Mon, May 1, 2023 at 9:29 AM Jay Hanke <jayhanke(a)southfront.io> wrote: > >> The hotel changed reservation systems. Link has been updated. >> >> The room block is very close to full. >> >> On Mon, May 1, 2023 at 9:03 AM Steve Howard <showard(a)paulbunyan.net> >> wrote: >> > >> > Richard, >> > >> > FYI, the "BOOK ROOM NOW" link on the website you referenced is broken. >> > >> > Steve >> > >> > >> > >> > On 4/28/23 21:44, Richard Laager wrote: >> > >> > I have updated the MICE website to reflect this as the next event. If >> you are planning to go and have not signed up, you should do so ASAP. >> > >> > On 3/4/23 17:57, Jay Hanke wrote: >> > >> > We're again doing the MICE summer outreach at the Midwest Peering >> Summit with several other adjacent Internet Exchanges. >> > >> > http://peeringsummit.com >> > >> > Registration for the two day meeting is $25 and includes lunch on the >> second day. We're likely going to fill the capacity of the venue well in >> advance of the event. >> > >> > We are looking for speakers/panelists as well. >> > >> > -- >> > Jay Hanke, President >> > South Front Networks >> > jayhanke(a)southfront.io >> > Phone 612-204-0000 >> > https://southfront.io/path.html >> > >> > >> > >> > ________________________________ >> > >> > To unsubscribe from the MICE-DISCUSS list, click the following link: >> > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 >> > >> > >> > >> > ________________________________ >> > >> > To unsubscribe from the MICE-DISCUSS list, click the following link: >> > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 >> > > > -- > Joe Unger > 612.709.8699 > joe(a)vaultas.com > Vaultas | *Connecting you to the Ecosystem* > vaultas.com > -- Joe Unger 612.709.8699 joe(a)vaultas.com Vaultas | *Connecting you to the Ecosystem* vaultas.com

May 1, 2023

Re: Midwest Peering Summit Info July 17-18th, 2023 Des Moines

by Joe Unger

The Book Room Now link is working, but the Group Promo Code doesn't seem to be working. Does anyone have any insight to share on that? Thanks, Joe On Mon, May 1, 2023 at 9:29 AM Jay Hanke <jayhanke(a)southfront.io> wrote: > The hotel changed reservation systems. Link has been updated. > > The room block is very close to full. > > On Mon, May 1, 2023 at 9:03 AM Steve Howard <showard(a)paulbunyan.net> > wrote: > > > > Richard, > > > > FYI, the "BOOK ROOM NOW" link on the website you referenced is broken. > > > > Steve > > > > > > > > On 4/28/23 21:44, Richard Laager wrote: > > > > I have updated the MICE website to reflect this as the next event. If > you are planning to go and have not signed up, you should do so ASAP. > > > > On 3/4/23 17:57, Jay Hanke wrote: > > > > We're again doing the MICE summer outreach at the Midwest Peering Summit > with several other adjacent Internet Exchanges. > > > > http://peeringsummit.com > > > > Registration for the two day meeting is $25 and includes lunch on the > second day. We're likely going to fill the capacity of the venue well in > advance of the event. > > > > We are looking for speakers/panelists as well. > > > > -- > > Jay Hanke, President > > South Front Networks > > jayhanke(a)southfront.io > > Phone 612-204-0000 > > https://southfront.io/path.html > > > > > > > > ________________________________ > > > > To unsubscribe from the MICE-DISCUSS list, click the following link: > > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > > > > > > > > ________________________________ > > > > To unsubscribe from the MICE-DISCUSS list, click the following link: > > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > -- Joe Unger 612.709.8699 joe(a)vaultas.com Vaultas | *Connecting you to the Ecosystem* vaultas.com

May 1, 2023

Re: Midwest Peering Summit Info July 17-18th, 2023 Des Moines

by Jay Hanke

The hotel changed reservation systems. Link has been updated. The room block is very close to full. On Mon, May 1, 2023 at 9:03 AM Steve Howard <showard(a)paulbunyan.net> wrote: > > Richard, > > FYI, the "BOOK ROOM NOW" link on the website you referenced is broken. > > Steve > > > > On 4/28/23 21:44, Richard Laager wrote: > > I have updated the MICE website to reflect this as the next event. If you are planning to go and have not signed up, you should do so ASAP. > > On 3/4/23 17:57, Jay Hanke wrote: > > We're again doing the MICE summer outreach at the Midwest Peering Summit with several other adjacent Internet Exchanges. > > http://peeringsummit.com > > Registration for the two day meeting is $25 and includes lunch on the second day. We're likely going to fill the capacity of the venue well in advance of the event. > > We are looking for speakers/panelists as well. > > -- > Jay Hanke, President > South Front Networks > jayhanke(a)southfront.io > Phone 612-204-0000 > https://southfront.io/path.html > > > > ________________________________ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > > > > ________________________________ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

May 1, 2023

Re: Midwest Peering Summit Info July 17-18th, 2023 Des Moines

by Steve Howard

May 1, 2023

Re: Call for Help: Web Design

by Richard Laager

On 4/29/23 08:27, Mike Horwath wrote: > On Fri, Apr 28, 2023 at 09:45:12PM -0500, Richard Laager wrote: >> Anyone know a web developer who could do some/all of the following? >> >> 1. The website uses Bootstrap 3.0.3, which is using jQuery 1.10.2. >> Update to modern versions of that, fixing what breaks. >> 2. At medium screen widths, the navigation comes off the navigation >> area and shows further down on the page. Fix that. >> 3. At small screen widths (including but not limited to mobile), the >> hamburger menu doesn't work quite right. The links show up, but they >> are mixed in with the page text. Fix that. >> >> The code is on GitHub here: https://github.com/micemn/mice-website > > Since this is a static site, why not go for something like Hugo and > just rebuild it into markdown files using a simple theme? I'm not against a larger redesign if someone wants to do it. We want the result to be reasonably nice looking and simple to manage. Note: It is NOT necessary to convert the participants page, as that will be transitioning to being built client side with Javascript pulling from IXP Manager. -- Richard

April 29, 2023

Re: Call for Help: Web Design

by Mike Horwath

On Fri, Apr 28, 2023 at 09:45:12PM -0500, Richard Laager wrote: > Anyone know a web developer who could do some/all of the following? > > 1. The website uses Bootstrap 3.0.3, which is using jQuery 1.10.2. > Update to modern versions of that, fixing what breaks. > 2. At medium screen widths, the navigation comes off the navigation > area and shows further down on the page. Fix that. > 3. At small screen widths (including but not limited to mobile), the > hamburger menu doesn't work quite right. The links show up, but they > are mixed in with the page text. Fix that. > > The code is on GitHub here: https://github.com/micemn/mice-website Since this is a static site, why not go for something like Hugo and just rebuild it into markdown files using a simple theme? Yes, would take some work but there isn't all that much in the site after perusing the repository. If I had more time I'd just knock it out as this is pretty small. Or maybe I'll see how yard work goes this weekend.. :) -- Mike Horwath, reachable via drechsau(a)Geeks.ORG

April 29, 2023