- mice-discuss - lists.micemn.net

Re: Apple peering down

by Jeremy Lumby

Traffic doubled on their second connection to MICE when the first one went down. From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Frank Bulk Sent: Friday, May 20, 2022 11:10 AM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Apple peering down Thanks. Can someone reconcile Anthony’s statement with Jay’s statement? “Looks like MICE’s LAG Po30 to Apple went down at the same time - about 3:15am this morning.” “One of their port channels is down. Looks like the other connection picked up the slack.” Frank From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of AnthonyAnderberg(a)nuvera.net Sent: Friday, May 20, 2022 8:50 AM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Apple peering down Looks like MICE’s LAG Po30 to Apple went down at the same time - about 3:15am this morning. From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> on behalf of Frank Bulk <fbulk(a)MYPREMIERONLINE.COM> Reply-To: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> Date: Friday, May 20, 2022 at 8:48 AM To: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> Subject: [MICE-DISCUSS] Apple peering down Anyone else seeing Apple peer down over IPv4 and IPv6 since 3:18 am? May 20 03:18:10 207.32.15.14 (sxct-north-2.sxcy.fbnt.netins.net) SiouxCity-Fibernet-Arista Rib: %BGP-3-NOTIFICATION: sent to neighbor 2001:504:27::2ca:0:1 (AS714-1.micemn.net) (AS 714 APPLE-ENGINEERING, US) 4/0 (Hold Timer Expired Error/Unspecified) 0 bytes May 20 03:18:10 207.32.15.14 (sxct-north-2.sxcy.fbnt.netins.net) SiouxCity-Fibernet-Arista Rib: %BGP-5-ADJCHANGE: peer 2001:504:27::2ca:0:1 (AS714-1.micemn.net) (AS 714 APPLE-ENGINEERING, US) old state Established event HoldTime new state Idle May 20 03:18:10 207.32.15.14 (sxct-north-2.sxcy.fbnt.netins.net) SiouxCity-Fibernet-Arista Rib: %BGP-3-NOTIFICATION: sent to neighbor 206.108.255.146 (AS714-1.micemn.net) (AS 714 APPLE-ENGINEERING, US) 4/0 (Hold Timer Expired Error/Unspecified) 0 bytes May 20 03:18:10 207.32.15.14 (sxct-north-2.sxcy.fbnt.netins.net) SiouxCity-Fibernet-Arista Rib: %BGP-5-ADJCHANGE: peer 206.108.255.146 (AS714-1.micemn.net) (AS 714 APPLE-ENGINEERING, US) old state Established event HoldTime new state Idle Fran k ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 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 ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

May 20, 2022

Re: Apple peering down

by Frank Bulk

Thanks. Can someone reconcile Anthony’s statement with Jay’s statement? “Looks like MICE’s LAG Po30 to Apple went down at the same time - about 3:15am this morning.” “One of their port channels is down. Looks like the other connection picked up the slack.” Frank From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of AnthonyAnderberg(a)nuvera.net Sent: Friday, May 20, 2022 8:50 AM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Apple peering down Looks like MICE’s LAG Po30 to Apple went down at the same time - about 3:15am this morning. From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>> on behalf of Frank Bulk <fbulk(a)MYPREMIERONLINE.COM<mailto:fbulk@MYPREMIERONLINE.COM>> Reply-To: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>> Date: Friday, May 20, 2022 at 8:48 AM To: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>> Subject: [MICE-DISCUSS] Apple peering down Anyone else seeing Apple peer down over IPv4 and IPv6 since 3:18 am? May 20 03:18:10 207.32.15.14 (sxct-north-2.sxcy.fbnt.netins.net) SiouxCity-Fibernet-Arista Rib: %BGP-3-NOTIFICATION: sent to neighbor 2001:504:27::2ca:0:1 (AS714-1.micemn.net) (AS 714 APPLE-ENGINEERING, US) 4/0 (Hold Timer Expired Error/Unspecified) 0 bytes May 20 03:18:10 207.32.15.14 (sxct-north-2.sxcy.fbnt.netins.net) SiouxCity-Fibernet-Arista Rib: %BGP-5-ADJCHANGE: peer 2001:504:27::2ca:0:1 (AS714-1.micemn.net) (AS 714 APPLE-ENGINEERING, US) old state Established event HoldTime new state Idle May 20 03:18:10 207.32.15.14 (sxct-north-2.sxcy.fbnt.netins.net) SiouxCity-Fibernet-Arista Rib: %BGP-3-NOTIFICATION: sent to neighbor 206.108.255.146 (AS714-1.micemn.net) (AS 714 APPLE-ENGINEERING, US) 4/0 (Hold Timer Expired Error/Unspecified) 0 bytes May 20 03:18:10 207.32.15.14 (sxct-north-2.sxcy.fbnt.netins.net) SiouxCity-Fibernet-Arista Rib: %BGP-5-ADJCHANGE: peer 206.108.255.146 (AS714-1.micemn.net) (AS 714 APPLE-ENGINEERING, US) old state Established event HoldTime new state Idle Fran k ________________________________ 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 20, 2022

Re: Apple peering down

by AnthonyAnderberg＠nuvera.net

Looks like MICE’s LAG Po30 to Apple went down at the same time - about 3:15am this morning. From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> on behalf of Frank Bulk <fbulk(a)MYPREMIERONLINE.COM> Reply-To: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> Date: Friday, May 20, 2022 at 8:48 AM To: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> Subject: [MICE-DISCUSS] Apple peering down Anyone else seeing Apple peer down over IPv4 and IPv6 since 3:18 am? May 20 03:18:10 207.32.15.14 (sxct-north-2.sxcy.fbnt.netins.net) SiouxCity-Fibernet-Arista Rib: %BGP-3-NOTIFICATION: sent to neighbor 2001:504:27::2ca:0:1 (AS714-1.micemn.net) (AS 714 APPLE-ENGINEERING, US) 4/0 (Hold Timer Expired Error/Unspecified) 0 bytes May 20 03:18:10 207.32.15.14 (sxct-north-2.sxcy.fbnt.netins.net) SiouxCity-Fibernet-Arista Rib: %BGP-5-ADJCHANGE: peer 2001:504:27::2ca:0:1 (AS714-1.micemn.net) (AS 714 APPLE-ENGINEERING, US) old state Established event HoldTime new state Idle May 20 03:18:10 207.32.15.14 (sxct-north-2.sxcy.fbnt.netins.net) SiouxCity-Fibernet-Arista Rib: %BGP-3-NOTIFICATION: sent to neighbor 206.108.255.146 (AS714-1.micemn.net) (AS 714 APPLE-ENGINEERING, US) 4/0 (Hold Timer Expired Error/Unspecified) 0 bytes May 20 03:18:10 207.32.15.14 (sxct-north-2.sxcy.fbnt.netins.net) SiouxCity-Fibernet-Arista Rib: %BGP-5-ADJCHANGE: peer 206.108.255.146 (AS714-1.micemn.net) (AS 714 APPLE-ENGINEERING, US) old state Established event HoldTime new state Idle Fran k ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

May 20, 2022

Re: Apple peering down

by Jay Hanke

One of their port channels is down. Looks like the other connection picked up the slack. On Fri, May 20, 2022 at 8:48 AM Frank Bulk <fbulk(a)mypremieronline.com> wrote: > > Anyone else seeing Apple peer down over IPv4 and IPv6 since 3:18 am? > > > > May 20 03:18:10 207.32.15.14 (sxct-north-2.sxcy.fbnt.netins.net) SiouxCity-Fibernet-Arista Rib: %BGP-3-NOTIFICATION: sent to neighbor 2001:504:27::2ca:0:1 (AS714-1.micemn.net) (AS 714 APPLE-ENGINEERING, US) 4/0 (Hold Timer Expired Error/Unspecified) 0 bytes > > May 20 03:18:10 207.32.15.14 (sxct-north-2.sxcy.fbnt.netins.net) SiouxCity-Fibernet-Arista Rib: %BGP-5-ADJCHANGE: peer 2001:504:27::2ca:0:1 (AS714-1.micemn.net) (AS 714 APPLE-ENGINEERING, US) old state Established event HoldTime new state Idle > > May 20 03:18:10 207.32.15.14 (sxct-north-2.sxcy.fbnt.netins.net) SiouxCity-Fibernet-Arista Rib: %BGP-3-NOTIFICATION: sent to neighbor 206.108.255.146 (AS714-1.micemn.net) (AS 714 APPLE-ENGINEERING, US) 4/0 (Hold Timer Expired Error/Unspecified) 0 bytes > > May 20 03:18:10 207.32.15.14 (sxct-north-2.sxcy.fbnt.netins.net) SiouxCity-Fibernet-Arista Rib: %BGP-5-ADJCHANGE: peer 206.108.255.146 (AS714-1.micemn.net) (AS 714 APPLE-ENGINEERING, US) old state Established event HoldTime new state Idle > > > > Fran k > > > ________________________________ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 -- Jay Hanke, President South Front Networks jayhanke(a)southfront.io Phone 612-204-0000

May 20, 2022

Apple peering down

by Frank Bulk

Anyone else seeing Apple peer down over IPv4 and IPv6 since 3:18 am? May 20 03:18:10 207.32.15.14 (sxct-north-2.sxcy.fbnt.netins.net) SiouxCity-Fibernet-Arista Rib: %BGP-3-NOTIFICATION: sent to neighbor 2001:504:27::2ca:0:1 (AS714-1.micemn.net) (AS 714 APPLE-ENGINEERING, US) 4/0 (Hold Timer Expired Error/Unspecified) 0 bytes May 20 03:18:10 207.32.15.14 (sxct-north-2.sxcy.fbnt.netins.net) SiouxCity-Fibernet-Arista Rib: %BGP-5-ADJCHANGE: peer 2001:504:27::2ca:0:1 (AS714-1.micemn.net) (AS 714 APPLE-ENGINEERING, US) old state Established event HoldTime new state Idle May 20 03:18:10 207.32.15.14 (sxct-north-2.sxcy.fbnt.netins.net) SiouxCity-Fibernet-Arista Rib: %BGP-3-NOTIFICATION: sent to neighbor 206.108.255.146 (AS714-1.micemn.net) (AS 714 APPLE-ENGINEERING, US) 4/0 (Hold Timer Expired Error/Unspecified) 0 bytes May 20 03:18:10 207.32.15.14 (sxct-north-2.sxcy.fbnt.netins.net) SiouxCity-Fibernet-Arista Rib: %BGP-5-ADJCHANGE: peer 206.108.255.146 (AS714-1.micemn.net) (AS 714 APPLE-ENGINEERING, US) old state Established event HoldTime new state Idle Fran k

May 20, 2022

Please welcome Communications 1 Network to MICE!

by Jeremy Lumby

Name: Communications 1 Network Switch: SouthFront Albert Lea Port: E 7/4 ASN: 394911 IPv4: 206.108.255.195/24 IPv6: 2001:504:27:0:6:69F::1/64 Peering Contact: jkeiper(a)comm1net.net Route Servers: YES BFD: YES Welcome Aboard! Jeremy Lumby Minnesota VoIP 9217 17th Ave S #216 Bloomington, MN 55425 Main: 612-355-7740 Direct: 612-392-6814 Fax: 952-873-7425 jlumby(a)mnvoip.com

May 19, 2022

Please welcome Bluepeak to MICE!

by Jeremy Lumby

Name: Bluepeak Switch: MICE Core Port: E6/23/1 ASN: 20412 IPv4: This is a port upgrade and name change from Vast Broadband, all IP info remains the same. The new connection will be 100G IPv6: Peering Contact: neteng(a)mybluepeak.com Route Servers: Yes BFD: Yes Welcome Aboard Again! Jeremy Lumby Minnesota VoIP 9217 17th Ave S #216 Bloomington, MN 55425 Main: 612-355-7740 Direct: 612-392-6814 Fax: 952-873-7425 jlumby(a)mnvoip.com

May 11, 2022

Midwest Peering Summit 2022 Update

by Jay Hanke

As of last night, we have 80 attendees registered for the summer event. The event is free of charge to peering networks (or potentially peering networks). Pre Registration is required. You can register here: https://www.eventcreate.com/e/mwps2022 This is our discounted room block: https://reservations.travelclick.com/109230?groupID=3466891 We ask if your company is bringing sales folks that you purchase a table ($200) to help with costs. MWPS 2022 Sponsors/Exhibitors ------------------------------------ 1623 Farnam Arista Aureon 616 Bluebird Networks NocIX South Front Networks MWPS 2022 Exhibitors ------------------------------------ Aurora Fiber Optic Networks Great Plains Communications Heartland Technology Data Center Hurricane Electric Precision Group US Internet Vantage Point Solutions IX Attendees ------------------------------------ ChIX (Chicago IL) DesMoinesIX (Des Moines IA) Fiber Data Internet Exchange (Altoona, Indy, STL) KCIX (Kansas City MO) MICE (Minneapolis MN) OhioIX (Columbus OH) OmahaIX (Omaha NE) QCIX (Davenport) SiouxIX (Sioux City IA) SpringIX (Springfield MO) STLIX (St Louis MO) Attending Companies ------------------------------------ Amazon Prime Video ConnectDSM Fiber Minnesota FiberComm Involta Iowa Communication Network Google Fiber Key Cooperative Liberty Communications Mankato Networks Midco MTC Technologies MTC Communications (not the same) Ninja-IX Nuvera Optk OzarksGo RLM Underground SDN Communications Smartsource Consulting South Slope Cooperative Communications Stream Data Centers SupraNet Communications Unite Private Networks Vaultas WIN Winnebago Cooperative Telecom Association -- Jay Hanke, President South Front Networks jayhanke(a)southfront.io Phone 612-204-0000

May 9, 2022

Re: MICE Remote Switch Policy

by Richard Laager

On 5/6/22 13:02, Jeremy Lumby wrote: > > I wanted to see where this ended up. The public discussion has been > open for a very long time. I would assume anyone who was going to > chime in by now would have. > Right. The consensus seems to be that this is not ministerial; the board should exercise discretion. As far as the particular criteria, the public comment didn't seem to generate a lot of detail there. > What has the board decided on? > In terms of remote switches generally, I modified the website a bit after the board's last discussion: -<li>The remote switch operator will provide a technical proposal to the board.</li> +<li>The remote switch operator will provide a proposal to the board addressing both technical and business details. Switches dedicated to MICE are quasi-required. Proposals should address expected participation. For example, does the operator have firm commitments from e.g. 5 participants?</li> As you can see, this is still relatively "squishy". We strengthened the dedicated switch thing, but it's hard to actually say it's "required" if we're still theoretically willing to make exceptions. There's also the bit about addressing whether they have participants lined up. The approval is still subject to board approval, and it's still subjective. Having 5 participants lined up does not guarantee approval, and having less than 5 does not guarantee rejection. As far as the NOCIX proposal specifically, we tabled that at the last meeting and asked for more information. We have that now, so we can pick this back up again for a decision. -- Richard

May 6, 2022

Re: MICE Remote Switch Policy

by Aaron Wendel

I was told that I needed 5 "quality" networks committed before I could get approval. That requirement is now on the MICE website as well. I have the following networks committed but I'm not sure if they qualify as the kind of networks the board is looking for. AS50058 August Internet AS34927 IFOG GMBH AS13737 INCX Global, LLC AS11708 KCFiber AS32097 Wholesale Internet AS14004 NOCIX AS55241 Xtracts AS17019 UnReal Servers 5 of these are on our SIX extension already and all are (obviously) KCIX peers. I haven't officially submitted this list to the board as I got sidetracked getting SIX online since that had some logistical challenges. (If you want cheap transport from KC to Seattle, Sprint is the way to go.) Now that it's live, I'd like to revisit the MICE extension so you're email is very timely. Aaron On 5/6/2022 1:02 PM, Jeremy Lumby wrote: > > I wanted to see where this ended up. The public discussion has been > open for a very long time. I would assume anyone who was going to > chime in by now would have. What has the board decided on? > > *From:*Jeremy Lumby [mailto:jlumby@mnvoip.com] > *Sent:* Friday, March 25, 2022 1:22 PM > *To:* MICE Discuss > *Subject:* RE: [MICE-DISCUSS] MICE Remote Switch Policy > > Precisely why I am a fan of something in the middle. The minimum > requirements will weed out the silly proposals and save time/effort. > The public discussion will bring up issues that should be considered, > and then the board can take the discussion, and use it to make a > decision. With this being said I would say if the minimums were met, > and there was no discussion, it should just be rubber stamped by the > board. There are plenty of people who know a lot about BGP/networking > on this list so there are plenty of opportunities to bring potential > issues to light. > > I have thought a lot about running an extension switch in Minneapolis > for an IX outside of North America. When you run the cost/benefit it > just does not make any sense. I think those things would come to > light in the public discussion phase. My personal opinion is anything > outside of North America just does not make sense for the “Midwest”. > The only reason that Cogent’s product does not fall on its face is > because it does not need to stand on its own. If Cogent was not > already in those locations with their other services, it would never > have made it out of the gate. Marketing is probably the only thing > keeping it alive. > > Jeremy > > *From:*MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] *On Behalf > Of *Reid Fishler > *Sent:* Thursday, March 24, 2022 11:53 PM > *To:* MICE-DISCUSS(a)LISTS.IPHOUSE.NET > *Subject:* Re: [MICE-DISCUSS] MICE Remote Switch Policy > > The answer is somewhere in the middle. We do whats best for the > exchange, and for the internet in general. There are MANY things where > this is what was done by the community. Honest question...if someone > wants to put an extension in Rio, Brazil, do we let them? How about in > South Africa? Is there a line? An exchange has a purpose, and thats to > get everyone local to each other, on one fabric...otherwise we are > just making Cogents IX thing they sell, or any one of the number of > global fabrics. At SOME point we need to say enough is enough. I am > NOT saying we are there yet, but to allow EVERYTHING is a bit too much > in the other direction. > > Reid > > Reid > > On Fri, Mar 25, 2022 at 12:44 AM Jeremy Lumby <jlumby(a)mnvoip.com> wrote: > > I completely agree that the number of people who know very little > about BGP is growing quickly, the real question is how do you deal > with this problem. Do you not permit things across the board > because of this, meaning that the opportunity is lost for the > people that understand what they are doing? Or do you put as many > reasonable precautions in place so that when someone screws up, it > mostly just impacts them, and all of the other members maintain > granular control? > > *From:*MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] *On > Behalf Of *Reid Fishler > *Sent:* Thursday, March 24, 2022 9:12 PM > *To:* MICE-DISCUSS(a)LISTS.IPHOUSE.NET > *Subject:* Re: [MICE-DISCUSS] MICE Remote Switch Policy > > The issue is there are going to be more and more networks that are > buying these peering services that don't always know what they > are... Either by services, or because 'someone told me to'... Its > not always those in the know that buy these things... Sometimes > it's networks that DON'T know. > > Reid > > On Thu, Mar 24, 2022, 10:04 PM Jeremy Lumby <jlumby(a)mnvoip.com> wrote: > > I understand the point a little better now. I would say it > depends on the specific type of CDN. The more traditional > ones like Cloudflare and Akamai it would not be a huge > disincentive because they market themselves based on how > close/low latency they are to the end user. Other CDNs that > are delivering more of their own content like Netflix/Google > would be more grateful for the free transport, and care less > about the added latency (assuming no loss). > > -----Original Message----- > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On > Behalf Of Richard Laager > Sent: Thursday, March 24, 2022 8:46 PM > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: Re: [MICE-DISCUSS] MICE Remote Switch Policy > > On 3/24/22 18:00, Jeremy Lumby wrote: > > As for a disincentive for CDN's to connect, I have only seen > the opposite. Most CDN's will only accept a connection to the > core. The only time I have seen them connect to a remote was > for a secondary connection to gain switch diversity. > > I wasn't talking about CDNs connecting to remotes. The > concern, or at > least how I understood it, was: Imagine we put a MICE > extension in city > X. In the immediate term, that's great, as now networks in > city X can > get content from Minneapolis CDNs. But in the longer-term, it > may create > a disincentive for CDNs to go to city X. > > Counter-point: Whether CDNs come to city X is not our problem. > > -- > 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> > > > -- > > Reid Fishler > Senior Director > Hurricane Electric > +1-510-580-4178 > > ------------------------------------------------------------------------ > > 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> > -- ================================================================ Aaron Wendel Chief Technical Officer Wholesale Internet, Inc. (AS 32097) (816)550-9030 http://www.wholesaleinternet.com ================================================================

May 6, 2022

Re: MICE Remote Switch Policy

by Jeremy Lumby

I wanted to see where this ended up. The public discussion has been open for a very long time. I would assume anyone who was going to chime in by now would have. What has the board decided on? From: Jeremy Lumby [mailto:jlumby@mnvoip.com] Sent: Friday, March 25, 2022 1:22 PM To: MICE Discuss Subject: RE: [MICE-DISCUSS] MICE Remote Switch Policy Precisely why I am a fan of something in the middle. The minimum requirements will weed out the silly proposals and save time/effort. The public discussion will bring up issues that should be considered, and then the board can take the discussion, and use it to make a decision. With this being said I would say if the minimums were met, and there was no discussion, it should just be rubber stamped by the board. There are plenty of people who know a lot about BGP/networking on this list so there are plenty of opportunities to bring potential issues to light. I have thought a lot about running an extension switch in Minneapolis for an IX outside of North America. When you run the cost/benefit it just does not make any sense. I think those things would come to light in the public discussion phase. My personal opinion is anything outside of North America just does not make sense for the “Midwest”. The only reason that Cogent’s product does not fall on its face is because it does not need to stand on its own. If Cogent was not already in those locations with their other services, it would never have made it out of the gate. Marketing is probably the only thing keeping it alive. Jeremy From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Reid Fishler Sent: Thursday, March 24, 2022 11:53 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] MICE Remote Switch Policy The answer is somewhere in the middle. We do whats best for the exchange, and for the internet in general. There are MANY things where this is what was done by the community. Honest question...if someone wants to put an extension in Rio, Brazil, do we let them? How about in South Africa? Is there a line? An exchange has a purpose, and thats to get everyone local to each other, on one fabric...otherwise we are just making Cogents IX thing they sell, or any one of the number of global fabrics. At SOME point we need to say enough is enough. I am NOT saying we are there yet, but to allow EVERYTHING is a bit too much in the other direction. Reid Reid On Fri, Mar 25, 2022 at 12:44 AM Jeremy Lumby <jlumby(a)mnvoip.com> wrote: I completely agree that the number of people who know very little about BGP is growing quickly, the real question is how do you deal with this problem. Do you not permit things across the board because of this, meaning that the opportunity is lost for the people that understand what they are doing? Or do you put as many reasonable precautions in place so that when someone screws up, it mostly just impacts them, and all of the other members maintain granular control? From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Reid Fishler Sent: Thursday, March 24, 2022 9:12 PM To:MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] MICE Remote Switch Policy The issue is there are going to be more and more networks that are buying these peering services that don't always know what they are... Either by services, or because 'someone told me to'... Its not always those in the know that buy these things... Sometimes it's networks that DON'T know. Reid On Thu, Mar 24, 2022, 10:04 PM Jeremy Lumby <jlumby(a)mnvoip.com> wrote: I understand the point a little better now. I would say it depends on the specific type of CDN. The more traditional ones like Cloudflare and Akamai it would not be a huge disincentive because they market themselves based on how close/low latency they are to the end user. Other CDNs that are delivering more of their own content like Netflix/Google would be more grateful for the free transport, and care less about the added latency (assuming no loss). -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Richard Laager Sent: Thursday, March 24, 2022 8:46 PM To:MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] MICE Remote Switch Policy On 3/24/22 18:00, Jeremy Lumby wrote: > As for a disincentive for CDN's to connect, I have only seen the opposite. Most CDN's will only accept a connection to the core. The only time I have seen them connect to a remote was for a secondary connection to gain switch diversity. I wasn't talking about CDNs connecting to remotes. The concern, or at least how I understood it, was: Imagine we put a MICE extension in city X. In the immediate term, that's great, as now networks in city X can get content from Minneapolis CDNs. But in the longer-term, it may create a disincentive for CDNs to go to city X. Counter-point: Whether CDNs come to city X is not our problem. -- 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 -- Reid Fishler Senior Director Hurricane Electric +1-510-580-4178 ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

May 6, 2022

Re: MICE Node for AS112

by David Farmer

I see the IPv4 routes now. Thanks On Thu, May 5, 2022 at 8:28 AM Isaiah Olson <iolson(a)paulbunyan.net> wrote: > Thanks for pointing this out. When this was originally set up, it looks > like I had set a limit of 100,000 routes for the IPv4 BGP sessions to the > MICE route servers, which we have now exceeded. I adjusted the limits and > reconfigured, and it looks like the routes for both protocols are present > on the looking glass again. > > Isaiah Olson > Network and Systems Administrator > Paul Bunyan Communications > 1831 Anne St NW > Bemidji, MN 56601 > (218) 444-4638 > > -----Original Message----- > From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of David > Farmer > Sent: Wednesday, May 04, 2022 11:14 PM > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: [MICE-DISCUSS] MICE Node for AS112 > > I'm seeing IPv6 routes from the MICE Node for AS112, but not IPv4 routes > > > This is what the MICE Looking Glass sees; > > micemn-lg>sh bgp regexp _112_ > BGP table version is 103138859, local router ID is 206.108.255.250 > Status codes: s suppressed, d damped, h history, * valid, > best, i - > internal, > r RIB-failure, S Stale, m multipath, b backup-path, f > RT-Filter, > x best-external, a additional-path, c RIB-compressed, > Origin codes: i - IGP, e - EGP, ? - incomplete > RPKI validation codes: V valid, I invalid, N Not found > > Network Next Hop Metric LocPrf Weight Path > * 192.31.196.0 206.108.255.52 255 0 6939 112 i > *> 206.108.255.52 255 0 6939 112 i > * 192.175.48.0 206.108.255.52 255 0 6939 112 i > *> 206.108.255.52 255 0 6939 112 i > micemn-lg>sh bgp ipv6 uni regexp _112_ > BGP table version is 165890313, local router ID is 206.108.255.250 > Status codes: s suppressed, d damped, h history, * valid, > best, i - > internal, > r RIB-failure, S Stale, m multipath, b backup-path, f > RT-Filter, > x best-external, a additional-path, c RIB-compressed, > Origin codes: i - IGP, e - EGP, ? - incomplete > RPKI validation codes: V valid, I invalid, N Not found > > Network Next Hop Metric LocPrf Weight Path > *> 2001:4:112::/48 2001:504:27::70:0:1 > 0 112 i > * 2001:504:27::70:0:1 > 0 112 i > *> 2620:4F:8000::/48 > 2001:504:27::70:0:1 > 0 112 i > * 2001:504:27::70:0:1 > 0 112 i > micemn-lg> > -- > =============================================== > David Farmer mailto:Email%3Afarmer@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 > =============================================== > > ________________________________________ > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > -- =============================================== 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 ===============================================

May 5, 2022

Re: MICE Node for AS112

by Isaiah Olson

Thanks for pointing this out. When this was originally set up, it looks like I had set a limit of 100,000 routes for the IPv4 BGP sessions to the MICE route servers, which we have now exceeded. I adjusted the limits and reconfigured, and it looks like the routes for both protocols are present on the looking glass again. Isaiah Olson Network and Systems Administrator Paul Bunyan Communications 1831 Anne St NW Bemidji, MN 56601 (218) 444-4638 -----Original Message----- From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of David Farmer Sent: Wednesday, May 04, 2022 11:14 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: [MICE-DISCUSS] MICE Node for AS112 I'm seeing IPv6 routes from the MICE Node for AS112, but not IPv4 routes This is what the MICE Looking Glass sees; micemn-lg>sh bgp regexp _112_ BGP table version is 103138859, local router ID is 206.108.255.250 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path * 192.31.196.0 206.108.255.52 255 0 6939 112 i *> 206.108.255.52 255 0 6939 112 i * 192.175.48.0 206.108.255.52 255 0 6939 112 i *> 206.108.255.52 255 0 6939 112 i micemn-lg>sh bgp ipv6 uni regexp _112_ BGP table version is 165890313, local router ID is 206.108.255.250 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *> 2001:4:112::/48 2001:504:27::70:0:1 0 112 i * 2001:504:27::70:0:1 0 112 i *> 2620:4F:8000::/48 2001:504:27::70:0:1 0 112 i * 2001:504:27::70:0:1 0 112 i micemn-lg> -- =============================================== David Farmer mailto:Email%3Afarmer@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 =============================================== ________________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

May 5, 2022

MICE Node for AS112

by David Farmer

I'm seeing IPv6 routes from the MICE Node for AS112, but not IPv4 routes This is what the MICE Looking Glass sees; micemn-lg>sh bgp regexp _112_ BGP table version is 103138859, local router ID is 206.108.255.250 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path * 192.31.196.0 206.108.255.52 255 0 6939 112 i *> 206.108.255.52 255 0 6939 112 i * 192.175.48.0 206.108.255.52 255 0 6939 112 i *> 206.108.255.52 255 0 6939 112 i micemn-lg>sh bgp ipv6 uni regexp _112_ BGP table version is 165890313, local router ID is 206.108.255.250 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *> 2001:4:112::/48 2001:504:27::70:0:1 0 112 i * 2001:504:27::70:0:1 0 112 i *> 2620:4F:8000::/48 2001:504:27::70:0:1 0 112 i * 2001:504:27::70:0:1 0 112 i micemn-lg> -- =============================================== 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 ===============================================

May 5, 2022

Please welcome LTD Broadband. to MICE!

by Jeremy Lumby

Name: LTD Broadband Switch: South Front Networks Albert Lea Port: E9/1 ASN: 394330 IPv4: This is a port upgrade/move, all IP info remains the same. The new connection will be 100G IPv6: Peering Contact: coreyhauer(a)ltdbroadband.com Route Servers: No BFD: No Welcome Aboard Again! Jeremy Lumby Minnesota VoIP 9217 17th Ave S #216 Bloomington, MN 55425 Main: 612-355-7740 Direct: 612-392-6814 Fax: 952-873-7425 jlumby(a)mnvoip.com

May 3, 2022

Re: Please welcome Hennepin County to MICE!

by Doug McIntyre

On Wed, Apr 20, 2022 at 04:01:00PM -0500, Jeremy Lumby wrote: >Name: Hennepin County >Switch: MICE Core >Port: E 5/3 >ASN: 40382 >IPv4: 206.108.255.193/24 >IPv6: 2001:504:27:0:0:9DBE::1/64 >Peering Contact: peering(a)hennepin.us >Route Servers: YES >BFD: YES Added into the RR's. Welcome!

April 21, 2022

Please welcome Hennepin County to MICE!

by Jeremy Lumby

Name: Hennepin County Switch: MICE Core Port: E 5/3 ASN: 40382 IPv4: 206.108.255.193/24 IPv6: 2001:504:27:0:0:9DBE::1/64 Peering Contact: peering(a)hennepin.us Route Servers: YES BFD: YES Welcome Aboard! Jeremy Lumby Minnesota VoIP 9217 17th Ave S #216 Bloomington, MN 55425 Main: 612-355-7740 Direct: 612-392-6814 Fax: 952-873-7425 jlumby(a)mnvoip.com

April 20, 2022

Re: IPv4 BGP session to Google down

by Frank Bulk

Thanks, stable for me for 1d 14h. Frank -----Original Message----- From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Jeremy Lumby Sent: Monday, April 18, 2022 8:27 AM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] IPv4 BGP session to Google down I saw traffic come back yesterday, and got an official notice that they had solved the problem. -----Original Message----- From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Doug McIntyre Sent: Friday, April 15, 2022 5:39 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] IPv4 BGP session to Google down Google has many tickets open about the issue. Apparently they are having issues with their transport network, and they aren't getting anywhere. No idea why they and the transport can't figure out a fix after all this time. On Fri, Apr 15, 2022 at 10:32:03PM +0000, Frank Bulk wrote: >Has a ticket been opened with Google? > >Frank > >From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Jay >Hanke >Sent: Thursday, April 7, 2022 4:52 PM >To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET >Subject: Re: [MICE-DISCUSS] IPv4 BGP session to Google down > >It's been oos for almost 2 weeks. > > >On Thu, Apr 7, 2022, 4:28 PM Frank Bulk <fbulk(a)mypremieronline.com<mailto:fbulk@mypremieronline.com>> wrote: >Ok, then maybe we're the only one down. > >Frank > >-----Original Message----- >From: MICE Discuss ><MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>> >On Behalf Of Jeff Wilde >Sent: Thursday, April 7, 2022 12:02 PM >To: >MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> >Subject: Re: [MICE-DISCUSS] IPv4 BGP session to Google down > >I did not. > > >Jeff Wilde * Network Engineer * Park Region Office 218.826.6161 * >Direct 218.826.8330 * Fax 218.826.6298 > > >-----Original Message----- >From: MICE Discuss ><MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>> >On Behalf Of Frank Bulk >Sent: Thursday, April 7, 2022 11:57 AM >To: >MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> >Subject: [MICE-DISCUSS] IPv4 BGP session to Google down > >Our BGP session bounce several times last might between 10:00 and 10:07 pm Central, and then has been down from 10:21 am. > >Anyone else seeing this? I see a little drop in the graph (http://micelg.usinternet.com/cacti/graph_view.php?action=tree&tree_id=1&lea…) this morning. > >Frank Bulk >FiberNet (AS18883) > >Apr 7 10:21:55 207.32.15.14 Rib: %BGP-3-NOTIFICATION: sent to neighbor >206.108.255.167 (AS 15169) 4/0 (Hold Timer Expired Error/Unspecified) 0 >bytes Apr 7 10:21:55 207.32.15.14 Rib: %BGP-5-ADJCHANGE: peer >206.108.255.167 (AS 15169) old state Established event HoldTime new >state Idle Apr 7 10:22:00 207.32.15.14 Rib: %BGP-5-ADJCHANGE: peer >206.108.255.167 (AS 15169) old state OpenConfirm event RecvKeepAlive >new state Established Apr 7 10:22:30 207.32.15.14 Rib: >%BGP-5-ADJCHANGE: peer 206.108.255.167 (AS 15169) old state Established >event HoldTime new state Idle > >________________________________ > >To unsubscribe from the MICE-DISCUSS list, click the following link: >http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

April 19, 2022

Re: Please welcome Nsight Telservices to MICE!

by Doug McIntyre

On Sat, Apr 16, 2022 at 05:55:00PM -0500, Jeremy Lumby wrote: >Name: Nsight Telservices >Switch: MICE Core >Port: E 6/22/1 >ASN: 3663 >IPv4: 206.108.255.192/24 >IPv6: 2001:504:27:0:0:E4F::1/64 >Peering Contact: network-routing(a)nsight.com >Route Servers: YES >BFD: YES Added into the RR's. Welcome!

April 18, 2022

Re: IPv4 BGP session to Google down

by Jeremy Lumby

I saw traffic come back yesterday, and got an official notice that they had solved the problem. -----Original Message----- From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Doug McIntyre Sent: Friday, April 15, 2022 5:39 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] IPv4 BGP session to Google down Google has many tickets open about the issue. Apparently they are having issues with their transport network, and they aren't getting anywhere. No idea why they and the transport can't figure out a fix after all this time. On Fri, Apr 15, 2022 at 10:32:03PM +0000, Frank Bulk wrote: >Has a ticket been opened with Google? > >Frank > >From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Jay >Hanke >Sent: Thursday, April 7, 2022 4:52 PM >To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET >Subject: Re: [MICE-DISCUSS] IPv4 BGP session to Google down > >It's been oos for almost 2 weeks. > > >On Thu, Apr 7, 2022, 4:28 PM Frank Bulk <fbulk(a)mypremieronline.com<mailto:fbulk@mypremieronline.com>> wrote: >Ok, then maybe we're the only one down. > >Frank > >-----Original Message----- >From: MICE Discuss ><MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>> >On Behalf Of Jeff Wilde >Sent: Thursday, April 7, 2022 12:02 PM >To: >MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> >Subject: Re: [MICE-DISCUSS] IPv4 BGP session to Google down > >I did not. > > >Jeff Wilde * Network Engineer * Park Region Office 218.826.6161 * >Direct 218.826.8330 * Fax 218.826.6298 > > >-----Original Message----- >From: MICE Discuss ><MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>> >On Behalf Of Frank Bulk >Sent: Thursday, April 7, 2022 11:57 AM >To: >MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> >Subject: [MICE-DISCUSS] IPv4 BGP session to Google down > >Our BGP session bounce several times last might between 10:00 and 10:07 pm Central, and then has been down from 10:21 am. > >Anyone else seeing this? I see a little drop in the graph (http://micelg.usinternet.com/cacti/graph_view.php?action=tree&tree_id=1&lea…) this morning. > >Frank Bulk >FiberNet (AS18883) > >Apr 7 10:21:55 207.32.15.14 Rib: %BGP-3-NOTIFICATION: sent to neighbor >206.108.255.167 (AS 15169) 4/0 (Hold Timer Expired Error/Unspecified) 0 >bytes Apr 7 10:21:55 207.32.15.14 Rib: %BGP-5-ADJCHANGE: peer >206.108.255.167 (AS 15169) old state Established event HoldTime new >state Idle Apr 7 10:22:00 207.32.15.14 Rib: %BGP-5-ADJCHANGE: peer >206.108.255.167 (AS 15169) old state OpenConfirm event RecvKeepAlive >new state Established Apr 7 10:22:30 207.32.15.14 Rib: >%BGP-5-ADJCHANGE: peer 206.108.255.167 (AS 15169) old state Established >event HoldTime new state Idle > >________________________________ > >To unsubscribe from the MICE-DISCUSS list, click the following link: >http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

April 18, 2022

Re: IPv4 BGP session to Google down

by Jeff Wilde

Are you referring to this? BGP neighbor is 206.108.255.141 Remote AS 15169, local AS 25637, external link Description: --- Google --- Remote router ID 108.170.225.16 BGP state = Established, up for 4w5d Jeff Wilde * Network Engineer * Park Region Office 218.826.6161 * Direct 218.826.8330 * Fax 218.826.6298 -----Original Message----- From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Doug McIntyre Sent: Friday, April 15, 2022 5:39 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] IPv4 BGP session to Google down Google has many tickets open about the issue. Apparently they are having issues with their transport network, and they aren't getting anywhere. No idea why they and the transport can't figure out a fix after all this time. On Fri, Apr 15, 2022 at 10:32:03PM +0000, Frank Bulk wrote: >Has a ticket been opened with Google? > >Frank > >From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Jay >Hanke >Sent: Thursday, April 7, 2022 4:52 PM >To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET >Subject: Re: [MICE-DISCUSS] IPv4 BGP session to Google down > >It's been oos for almost 2 weeks. > > >On Thu, Apr 7, 2022, 4:28 PM Frank Bulk <fbulk(a)mypremieronline.com<mailto:fbulk@mypremieronline.com>> wrote: >Ok, then maybe we're the only one down. > >Frank > >-----Original Message----- >From: MICE Discuss ><MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>> >On Behalf Of Jeff Wilde >Sent: Thursday, April 7, 2022 12:02 PM >To: >MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> >Subject: Re: [MICE-DISCUSS] IPv4 BGP session to Google down > >I did not. > > >Jeff Wilde * Network Engineer * Park Region Office 218.826.6161 * >Direct 218.826.8330 * Fax 218.826.6298 > > >-----Original Message----- >From: MICE Discuss ><MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>> >On Behalf Of Frank Bulk >Sent: Thursday, April 7, 2022 11:57 AM >To: >MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> >Subject: [MICE-DISCUSS] IPv4 BGP session to Google down > >Our BGP session bounce several times last might between 10:00 and 10:07 pm Central, and then has been down from 10:21 am. > >Anyone else seeing this? I see a little drop in the graph (http://micelg.usinternet.com/cacti/graph_view.php?action=tree&tree_id=1&lea…) this morning. > >Frank Bulk >FiberNet (AS18883) > >Apr 7 10:21:55 207.32.15.14 Rib: %BGP-3-NOTIFICATION: sent to neighbor >206.108.255.167 (AS 15169) 4/0 (Hold Timer Expired Error/Unspecified) 0 >bytes Apr 7 10:21:55 207.32.15.14 Rib: %BGP-5-ADJCHANGE: peer >206.108.255.167 (AS 15169) old state Established event HoldTime new >state Idle Apr 7 10:22:00 207.32.15.14 Rib: %BGP-5-ADJCHANGE: peer >206.108.255.167 (AS 15169) old state OpenConfirm event RecvKeepAlive >new state Established Apr 7 10:22:30 207.32.15.14 Rib: >%BGP-5-ADJCHANGE: peer 206.108.255.167 (AS 15169) old state Established >event HoldTime new state Idle > >________________________________ > >To unsubscribe from the MICE-DISCUSS list, click the following link: >http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

April 18, 2022

Please welcome Nsight Telservices to MICE!

by Jeremy Lumby

Name: Nsight Telservices Switch: MICE Core Port: E 6/22/1 ASN: 3663 IPv4: 206.108.255.192/24 IPv6: 2001:504:27:0:0:E4F::1/64 Peering Contact: network-routing(a)nsight.com Route Servers: YES BFD: YES Welcome Aboard! Jeremy Lumby Minnesota VoIP 9217 17th Ave S #216 Bloomington, MN 55425 Main: 612-355-7740 Direct: 612-392-6814 Fax: 952-873-7425 jlumby(a)mnvoip.com

April 16, 2022

Re: IPv4 BGP session to Google down

by Doug McIntyre

Google has many tickets open about the issue. Apparently they are having issues with their transport network, and they aren't getting anywhere. No idea why they and the transport can't figure out a fix after all this time. On Fri, Apr 15, 2022 at 10:32:03PM +0000, Frank Bulk wrote: >Has a ticket been opened with Google? > >Frank > >From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Jay Hanke >Sent: Thursday, April 7, 2022 4:52 PM >To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET >Subject: Re: [MICE-DISCUSS] IPv4 BGP session to Google down > >It's been oos for almost 2 weeks. > > >On Thu, Apr 7, 2022, 4:28 PM Frank Bulk <fbulk(a)mypremieronline.com<mailto:fbulk@mypremieronline.com>> wrote: >Ok, then maybe we're the only one down. > >Frank > >-----Original Message----- >From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>> On Behalf Of Jeff Wilde >Sent: Thursday, April 7, 2022 12:02 PM >To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> >Subject: Re: [MICE-DISCUSS] IPv4 BGP session to Google down > >I did not. > > >Jeff Wilde * Network Engineer * Park Region >Office 218.826.6161 * Direct 218.826.8330 * Fax 218.826.6298 > > >-----Original Message----- >From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>> On Behalf Of Frank Bulk >Sent: Thursday, April 7, 2022 11:57 AM >To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> >Subject: [MICE-DISCUSS] IPv4 BGP session to Google down > >Our BGP session bounce several times last might between 10:00 and 10:07 pm Central, and then has been down from 10:21 am. > >Anyone else seeing this? I see a little drop in the graph (http://micelg.usinternet.com/cacti/graph_view.php?action=tree&tree_id=1&lea…) this morning. > >Frank Bulk >FiberNet (AS18883) > >Apr 7 10:21:55 207.32.15.14 Rib: %BGP-3-NOTIFICATION: sent to neighbor 206.108.255.167 (AS 15169) 4/0 (Hold Timer Expired Error/Unspecified) 0 bytes Apr 7 10:21:55 207.32.15.14 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.167 (AS 15169) old state Established event HoldTime new state Idle Apr 7 10:22:00 207.32.15.14 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.167 (AS 15169) old state OpenConfirm event RecvKeepAlive new state Established Apr 7 10:22:30 207.32.15.14 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.167 (AS 15169) old state Established event HoldTime new state Idle > >________________________________ > >To unsubscribe from the MICE-DISCUSS list, click the following link: >http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

April 15, 2022

Re: IPv4 BGP session to Google down

by Frank Bulk

Has a ticket been opened with Google? Frank From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Jay Hanke Sent: Thursday, April 7, 2022 4:52 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] IPv4 BGP session to Google down It's been oos for almost 2 weeks. On Thu, Apr 7, 2022, 4:28 PM Frank Bulk <fbulk(a)mypremieronline.com<mailto:fbulk@mypremieronline.com>> wrote: Ok, then maybe we're the only one down. Frank -----Original Message----- From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>> On Behalf Of Jeff Wilde Sent: Thursday, April 7, 2022 12:02 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> Subject: Re: [MICE-DISCUSS] IPv4 BGP session to Google down I did not. Jeff Wilde * Network Engineer * Park Region Office 218.826.6161 * Direct 218.826.8330 * Fax 218.826.6298 -----Original Message----- From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>> On Behalf Of Frank Bulk Sent: Thursday, April 7, 2022 11:57 AM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> Subject: [MICE-DISCUSS] IPv4 BGP session to Google down Our BGP session bounce several times last might between 10:00 and 10:07 pm Central, and then has been down from 10:21 am. Anyone else seeing this? I see a little drop in the graph (http://micelg.usinternet.com/cacti/graph_view.php?action=tree&tree_id=1&lea…) this morning. Frank Bulk FiberNet (AS18883) Apr 7 10:21:55 207.32.15.14 Rib: %BGP-3-NOTIFICATION: sent to neighbor 206.108.255.167 (AS 15169) 4/0 (Hold Timer Expired Error/Unspecified) 0 bytes Apr 7 10:21:55 207.32.15.14 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.167 (AS 15169) old state Established event HoldTime new state Idle Apr 7 10:22:00 207.32.15.14 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.167 (AS 15169) old state OpenConfirm event RecvKeepAlive new state Established Apr 7 10:22:30 207.32.15.14 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.167 (AS 15169) old state Established event HoldTime new state Idle ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

April 15, 2022

Re: Please welcome G-Core Labs S.A. to MICE!

by Doug McIntyre

On Fri, Apr 08, 2022 at 05:18:00PM -0500, Jeremy Lumby wrote: >Name: G-Core Labs S.A. >Switch: MICE Core >Port: E 4/7 >ASN: 199524 >IPv4: 206.108.255.191/24 >IPv6: 2001:504:27:0:3:0B64::1/64 >Peering Contact: noc(a)gcore.lu >Route Servers: YES >BFD: No Added into the RR's. Welcome!

April 9, 2022

Please welcome G-Core Labs S.A. to MICE!

by Jeremy Lumby

Name: G-Core Labs S.A. Switch: MICE Core Port: E 4/7 ASN: 199524 IPv4: 206.108.255.191/24 IPv6: 2001:504:27:0:3:0B64::1/64 Peering Contact: noc(a)gcore.lu Route Servers: YES BFD: No Welcome Aboard! Jeremy Lumby Minnesota VoIP 9217 17th Ave S #216 Bloomington, MN 55425 Main: 612-355-7740 Direct: 612-392-6814 Fax: 952-873-7425 jlumby(a)mnvoip.com

April 8, 2022

Re: IPv4 BGP session to Google down

by Jay Hanke

It's been oos for almost 2 weeks. On Thu, Apr 7, 2022, 4:28 PM Frank Bulk <fbulk(a)mypremieronline.com> wrote: > Ok, then maybe we're the only one down. > > Frank > > -----Original Message----- > From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Jeff > Wilde > Sent: Thursday, April 7, 2022 12:02 PM > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: Re: [MICE-DISCUSS] IPv4 BGP session to Google down > > I did not. > > > Jeff Wilde * Network Engineer * Park Region > Office 218.826.6161 * Direct 218.826.8330 * Fax 218.826.6298 > > > -----Original Message----- > From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Frank > Bulk > Sent: Thursday, April 7, 2022 11:57 AM > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: [MICE-DISCUSS] IPv4 BGP session to Google down > > Our BGP session bounce several times last might between 10:00 and 10:07 pm > Central, and then has been down from 10:21 am. > > Anyone else seeing this? I see a little drop in the graph ( > http://micelg.usinternet.com/cacti/graph_view.php?action=tree&tree_id=1&lea…) > this morning. > > Frank Bulk > FiberNet (AS18883) > > Apr 7 10:21:55 207.32.15.14 Rib: %BGP-3-NOTIFICATION: sent to neighbor > 206.108.255.167 (AS 15169) 4/0 (Hold Timer Expired Error/Unspecified) 0 > bytes Apr 7 10:21:55 207.32.15.14 Rib: %BGP-5-ADJCHANGE: peer > 206.108.255.167 (AS 15169) old state Established event HoldTime new state > Idle Apr 7 10:22:00 207.32.15.14 Rib: %BGP-5-ADJCHANGE: peer > 206.108.255.167 (AS 15169) old state OpenConfirm event RecvKeepAlive new > state Established Apr 7 10:22:30 207.32.15.14 Rib: %BGP-5-ADJCHANGE: peer > 206.108.255.167 (AS 15169) old state Established event HoldTime new state > Idle >

April 7, 2022

Re: IPv4 BGP session to Google down

by Frank Bulk

Ok, then maybe we're the only one down. Frank -----Original Message----- From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Jeff Wilde Sent: Thursday, April 7, 2022 12:02 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] IPv4 BGP session to Google down I did not. Jeff Wilde * Network Engineer * Park Region Office 218.826.6161 * Direct 218.826.8330 * Fax 218.826.6298 -----Original Message----- From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Frank Bulk Sent: Thursday, April 7, 2022 11:57 AM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: [MICE-DISCUSS] IPv4 BGP session to Google down Our BGP session bounce several times last might between 10:00 and 10:07 pm Central, and then has been down from 10:21 am. Anyone else seeing this? I see a little drop in the graph (http://micelg.usinternet.com/cacti/graph_view.php?action=tree&tree_id=1&lea…) this morning. Frank Bulk FiberNet (AS18883) Apr 7 10:21:55 207.32.15.14 Rib: %BGP-3-NOTIFICATION: sent to neighbor 206.108.255.167 (AS 15169) 4/0 (Hold Timer Expired Error/Unspecified) 0 bytes Apr 7 10:21:55 207.32.15.14 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.167 (AS 15169) old state Established event HoldTime new state Idle Apr 7 10:22:00 207.32.15.14 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.167 (AS 15169) old state OpenConfirm event RecvKeepAlive new state Established Apr 7 10:22:30 207.32.15.14 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.167 (AS 15169) old state Established event HoldTime new state Idle

April 7, 2022

Re: IPv4 BGP session to Google down

by Jeff Wilde

I did not. Jeff Wilde * Network Engineer * Park Region Office 218.826.6161 * Direct 218.826.8330 * Fax 218.826.6298 -----Original Message----- From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Frank Bulk Sent: Thursday, April 7, 2022 11:57 AM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: [MICE-DISCUSS] IPv4 BGP session to Google down Our BGP session bounce several times last might between 10:00 and 10:07 pm Central, and then has been down from 10:21 am. Anyone else seeing this? I see a little drop in the graph (http://micelg.usinternet.com/cacti/graph_view.php?action=tree&tree_id=1&lea…) this morning. Frank Bulk FiberNet (AS18883) Apr 7 10:21:55 207.32.15.14 Rib: %BGP-3-NOTIFICATION: sent to neighbor 206.108.255.167 (AS 15169) 4/0 (Hold Timer Expired Error/Unspecified) 0 bytes Apr 7 10:21:55 207.32.15.14 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.167 (AS 15169) old state Established event HoldTime new state Idle Apr 7 10:22:00 207.32.15.14 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.167 (AS 15169) old state OpenConfirm event RecvKeepAlive new state Established Apr 7 10:22:30 207.32.15.14 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.167 (AS 15169) old state Established event HoldTime new state Idle

April 7, 2022

IPv4 BGP session to Google down

by Frank Bulk

Our BGP session bounce several times last might between 10:00 and 10:07 pm Central, and then has been down from 10:21 am. Anyone else seeing this? I see a little drop in the graph (http://micelg.usinternet.com/cacti/graph_view.php?action=tree&tree_id=1&lea…) this morning. Frank Bulk FiberNet (AS18883) Apr 7 10:21:55 207.32.15.14 Rib: %BGP-3-NOTIFICATION: sent to neighbor 206.108.255.167 (AS 15169) 4/0 (Hold Timer Expired Error/Unspecified) 0 bytes Apr 7 10:21:55 207.32.15.14 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.167 (AS 15169) old state Established event HoldTime new state Idle Apr 7 10:22:00 207.32.15.14 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.167 (AS 15169) old state OpenConfirm event RecvKeepAlive new state Established Apr 7 10:22:30 207.32.15.14 Rib: %BGP-5-ADJCHANGE: peer 206.108.255.167 (AS 15169) old state Established event HoldTime new state Idle

April 7, 2022

Re: MICE Remote Switch Policy

by Justin Krejci

Jonathan, Very excellent points. Here are some reply thoughts to consider. 1. the member has their own private, long distance, layer 2 link to an IX. The member themself knows it's a long distance but most of the other members of the IX probably will not have any idea, unless they happen to infer it from latency to your router or you otherwise disclose it. 2. if the IX does a long distance layer 2 link to an official/remote switch, it would be a lot more clear to people at a glance that members on such a far away remote switch are indeed far away As suggested in an earlier post of this thread, BGP communities could be added on the route server sessions of members marking the member's routes as originating via switch X. Then you as a fellow member could choose to adjust your BGP knobs based on that data, maybe you want to not take their routes or lower your local pref for them specifically and even choose to AS prepend your routes to them or not advertise to them at all. With members individually connecting a long distance, only the members themselves are respectively aware of the fact that they are far away. For those not using route servers, they can still easily gauge the member distances if they are clearly documented as connected to switches classed as far away switches and therefore can make their own routing decisions based on that knowledge, which may include not peering with distant members at all at said IX. If geographic distance is a concern for connected/connecting members, maybe the conversation should be had on whether remote switches or individual members can be connecting from such a distance greater than XYZ distance or perhaps XYZ avg latency, as you mentioned. But now, what if I setup a router in a nearby geographic location with low latency but only have a single router and a single connection back to my main established network that is far away? I as the member look to be close to the fabric and indeed am close to the fabric, yet most of my eyeballs and/or servers are still far away, in this hypothetical situation. Though I do think, as you imply, there is a point of diminishing returns by adding more and more connectivity at increasing distances, not just in target market / brand but also in the very real operational issues that can arise from two networks taking a highly inefficient path via an IX because it is shorter AS hops than usual transit links but is much longer geographically. I have seen this happen first hand. ________________________________ From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> on behalf of Jonathan Stewart <jonathan(a)LES.NET> Sent: Tuesday, April 5, 2022 4:22 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] MICE Remote Switch Policy A bit late to the discussion, but here are my thoughts: On Thu., 2022-03-24 3:58 p.m., Richard Laager wrote: > At Wiktel, I peer with MN VoIP's far away extensions in Minneapolis. > For example, I peer at SeattleIX (SIX) in Minneapolis. This has caused > me some issues. For example, latency-sensitive gaming traffic was > tromboning > Wiktel-Minneapolis-Seattle-Chicago-Seattle-Minneapolis-Wiktel rather > than Wiktel-Chicago-Wiktel. This is the biggest issue I am concerned about. Layer-2 can't tell us how far away the peer is. BGP doesn't have knobs for varying latency across peers on the same Layer-2. The SIX example of really-remote peers, with resultant latency higher than Transit, is a performance degradation for SIX and their members, and reduces the quality of SIX, I'd argue. I would suggest that MICE have a limit, say 5 ms RTT, on latency to remote switches. Then we can say that MICE is in a geographic region, not potentially a pan-North-America layer-2. Part of MICE's identity should be its location, and the resultant low-latency across MICE itself. If MICE is in Kansas City, and KCIX is in Minneapolis, what's the difference between them? Why do they both exist if they serve the same datacentres in the same way: a Layer-2 ethernet fabric? I become confused at what problem is being solved when IXes start overlapping and becoming non-geographic, rather than limited to a metro area, or certain radius around a hub. I think there's a difference between an individual member (me) arriving over a long layer-2 link (from Winnipeg) to the IX, and the IX doing long layer-2 links themselves. The difference is that I have knowledge of and control over my long-haul links, but if the IX does it, unexpectedly long-haul paths happen without my decision to use them. Finally, I'm a big fan of what MICE has accomplished so far, I hope this message doesn't read as being overly critical. Cheers, Jonathan AS18451 - LES.NET 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

April 5, 2022

Re: MICE Remote Switch Policy

by Jonathan Stewart

A bit late to the discussion, but here are my thoughts: On Thu., 2022-03-24 3:58 p.m., Richard Laager wrote: > At Wiktel, I peer with MN VoIP's far away extensions in Minneapolis. > For example, I peer at SeattleIX (SIX) in Minneapolis. This has caused > me some issues. For example, latency-sensitive gaming traffic was > tromboning > Wiktel-Minneapolis-Seattle-Chicago-Seattle-Minneapolis-Wiktel rather > than Wiktel-Chicago-Wiktel. This is the biggest issue I am concerned about. Layer-2 can't tell us how far away the peer is. BGP doesn't have knobs for varying latency across peers on the same Layer-2. The SIX example of really-remote peers, with resultant latency higher than Transit, is a performance degradation for SIX and their members, and reduces the quality of SIX, I'd argue. I would suggest that MICE have a limit, say 5 ms RTT, on latency to remote switches. Then we can say that MICE is in a geographic region, not potentially a pan-North-America layer-2. Part of MICE's identity should be its location, and the resultant low-latency across MICE itself. If MICE is in Kansas City, and KCIX is in Minneapolis, what's the difference between them? Why do they both exist if they serve the same datacentres in the same way: a Layer-2 ethernet fabric? I become confused at what problem is being solved when IXes start overlapping and becoming non-geographic, rather than limited to a metro area, or certain radius around a hub. I think there's a difference between an individual member (me) arriving over a long layer-2 link (from Winnipeg) to the IX, and the IX doing long layer-2 links themselves. The difference is that I have knowledge of and control over my long-haul links, but if the IX does it, unexpectedly long-haul paths happen without my decision to use them. Finally, I'm a big fan of what MICE has accomplished so far, I hope this message doesn't read as being overly critical. Cheers, Jonathan AS18451 - LES.NET 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

April 5, 2022

OT: NANOG call for presentations

by steve ulrich

folks - long time lurker here. ( as well as a couple of times meatspace meeting attendee. ) apologies in advance for the off-topic email, but i'm on the NANOG program committee and we've had folks express interest in presentations regarding regional peering exchanges as well as talks regarding independent networks that have done interesting things from an operational perspective. e.g.: managing growth, novel deployment of access technologies. etc. it struck me that the folks peering at MICE or engaged in MICE operations might have great presentation ideas/material.. the next NANOG is in june in montreal, ca. but we're always looking for presentations for future NANOGs as well. NANOG has a variety of different presentation formats and we're open to suggestions. please feel free to submit an abstract online ( https://nanog.org/program/call-presentations/) and someone from the program committee thanks! -- steve ulrich (sulrich(a)botwerks.org)

April 5, 2022

Please welcome Long Lines Broadband to MICE!

by Jeremy Lumby

Name: Long Lines Broadband Switch: MICE Main Port: E6/21/1 ASN: 32867 IPv4: This is a port upgrade, all IP info remains the same. The new connection will be 100G IPv6: Peering Contact: data(a)longlines.biz Route Servers: Yes BFD: No Welcome Aboard Again! Jeremy Lumby Minnesota VoIP 9217 17th Ave S #216 Bloomington, MN 55425 Main: 612-355-7740 Direct: 612-392-6814 Fax: 952-873-7425 jlumby(a)mnvoip.com

April 4, 2022

ARIN NOAUTH

by Jay Hanke

ARIN NOAUTH (legacy IRR) is getting shut down today at 11 AM central time. There will likely be some filtering issues across the internet for networks that haven't updated their IRR. https://www.arin.net/blog/2022/02/16/Take-Action-Now-to-Prepare-for-the-ARI… -- Jay Hanke, President South Front Networks jayhanke(a)southfront.io Phone 612-204-0000

April 4, 2022

MICE RS3 deactivated

by Jay Hanke

MICE RS3 (test route server) has been powered down. Thanks! -- Jay Hanke, President South Front Networks jayhanke(a)southfront.io Phone 612-204-0000

March 31, 2022

Re: MICE Remote Switch Policy

by Reid Fishler

The Japanese IX's extend to IIX's in the US as well (LA and NY). I believe that AMSIX does as well, and LINX maybe? And then there are the things like Console Connect, Packet Exchange, etc. Reid On Fri, Mar 25, 2022 at 2:48 PM Aaron Wendel <aaron(a)wholesaleinternet.net> wrote: > I've run some numbers on IX.br and I haven't been able to make them work > yet... yet... :) > > DE-CIX Frankfurt is accessible from the DE-CIX NY switch in KC. > > Aaron > > > On 3/25/2022 1:22 PM, Jeremy Lumby wrote: > > > > Precisely why I am a fan of something in the middle. The minimum > > requirements will weed out the silly proposals and save time/effort. > > The public discussion will bring up issues that should be considered, > > and then the board can take the discussion, and use it to make a > > decision. With this being said I would say if the minimums were met, > > and there was no discussion, it should just be rubber stamped by the > > board. There are plenty of people who know a lot about BGP/networking > > on this list so there are plenty of opportunities to bring potential > > issues to light. > > > > I have thought a lot about running an extension switch in Minneapolis > > for an IX outside of North America. When you run the cost/benefit it > > just does not make any sense. I think those things would come to > > light in the public discussion phase. My personal opinion is anything > > outside of North America just does not make sense for the “Midwest”. > > The only reason that Cogent’s product does not fall on its face is > > because it does not need to stand on its own. If Cogent was not > > already in those locations with their other services, it would never > > have made it out of the gate. Marketing is probably the only thing > > keeping it alive. > > > > Jeremy > > > > *From:*MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] *On Behalf > > Of *Reid Fishler > > *Sent:* Thursday, March 24, 2022 11:53 PM > > *To:* MICE-DISCUSS(a)LISTS.IPHOUSE.NET > > *Subject:* Re: [MICE-DISCUSS] MICE Remote Switch Policy > > > > The answer is somewhere in the middle. We do whats best for the > > exchange, and for the internet in general. There are MANY things where > > this is what was done by the community. Honest question...if someone > > wants to put an extension in Rio, Brazil, do we let them? How about in > > South Africa? Is there a line? An exchange has a purpose, and thats to > > get everyone local to each other, on one fabric...otherwise we are > > just making Cogents IX thing they sell, or any one of the number of > > global fabrics. At SOME point we need to say enough is enough. I am > > NOT saying we are there yet, but to allow EVERYTHING is a bit too much > > in the other direction. > > > > Reid > > > > Reid > > > > On Fri, Mar 25, 2022 at 12:44 AM Jeremy Lumby <jlumby(a)mnvoip.com> wrote: > > > > I completely agree that the number of people who know very little > > about BGP is growing quickly, the real question is how do you deal > > with this problem. Do you not permit things across the board > > because of this, meaning that the opportunity is lost for the > > people that understand what they are doing? Or do you put as many > > reasonable precautions in place so that when someone screws up, it > > mostly just impacts them, and all of the other members maintain > > granular control? > > > > *From:*MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] *On > > Behalf Of *Reid Fishler > > *Sent:* Thursday, March 24, 2022 9:12 PM > > *To:* MICE-DISCUSS(a)LISTS.IPHOUSE.NET > > *Subject:* Re: [MICE-DISCUSS] MICE Remote Switch Policy > > > > The issue is there are going to be more and more networks that are > > buying these peering services that don't always know what they > > are... Either by services, or because 'someone told me to'... Its > > not always those in the know that buy these things... Sometimes > > it's networks that DON'T know. > > > > Reid > > > > On Thu, Mar 24, 2022, 10:04 PM Jeremy Lumby <jlumby(a)mnvoip.com> > wrote: > > > > I understand the point a little better now. I would say it > > depends on the specific type of CDN. The more traditional > > ones like Cloudflare and Akamai it would not be a huge > > disincentive because they market themselves based on how > > close/low latency they are to the end user. Other CDNs that > > are delivering more of their own content like Netflix/Google > > would be more grateful for the free transport, and care less > > about the added latency (assuming no loss). > > > > -----Original Message----- > > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On > > Behalf Of Richard Laager > > Sent: Thursday, March 24, 2022 8:46 PM > > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > > Subject: Re: [MICE-DISCUSS] MICE Remote Switch Policy > > > > On 3/24/22 18:00, Jeremy Lumby wrote: > > > As for a disincentive for CDN's to connect, I have only seen > > the opposite. Most CDN's will only accept a connection to the > > core. The only time I have seen them connect to a remote was > > for a secondary connection to gain switch diversity. > > > > I wasn't talking about CDNs connecting to remotes. The > > concern, or at > > least how I understood it, was: Imagine we put a MICE > > extension in city > > X. In the immediate term, that's great, as now networks in > > city X can > > get content from Minneapolis CDNs. But in the longer-term, it > > may create > > a disincentive for CDNs to go to city X. > > > > Counter-point: Whether CDNs come to city X is not our problem. > > > > -- > > 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> > > > > > > -- > > > > Reid Fishler > > Senior Director > > Hurricane Electric > > +1-510-580-4178 > > > > ------------------------------------------------------------------------ > > > > 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> > > > > -- > ================================================================ > Aaron Wendel > Chief Technical Officer > Wholesale Internet, Inc. (AS 32097) > (816)550-9030 > http://www.wholesaleinternet.com > ================================================================ > > -- Reid Fishler Senior Director Hurricane Electric +1-510-580-4178

March 25, 2022

Re: MICE Remote Switch Policy

by Aaron Wendel

I've run some numbers on IX.br and I haven't been able to make them work yet... yet... :) DE-CIX Frankfurt is accessible from the DE-CIX NY switch in KC. Aaron On 3/25/2022 1:22 PM, Jeremy Lumby wrote: > > Precisely why I am a fan of something in the middle. The minimum > requirements will weed out the silly proposals and save time/effort. > The public discussion will bring up issues that should be considered, > and then the board can take the discussion, and use it to make a > decision. With this being said I would say if the minimums were met, > and there was no discussion, it should just be rubber stamped by the > board. There are plenty of people who know a lot about BGP/networking > on this list so there are plenty of opportunities to bring potential > issues to light. > > I have thought a lot about running an extension switch in Minneapolis > for an IX outside of North America. When you run the cost/benefit it > just does not make any sense. I think those things would come to > light in the public discussion phase. My personal opinion is anything > outside of North America just does not make sense for the “Midwest”. > The only reason that Cogent’s product does not fall on its face is > because it does not need to stand on its own. If Cogent was not > already in those locations with their other services, it would never > have made it out of the gate. Marketing is probably the only thing > keeping it alive. > > Jeremy > > *From:*MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] *On Behalf > Of *Reid Fishler > *Sent:* Thursday, March 24, 2022 11:53 PM > *To:* MICE-DISCUSS(a)LISTS.IPHOUSE.NET > *Subject:* Re: [MICE-DISCUSS] MICE Remote Switch Policy > > The answer is somewhere in the middle. We do whats best for the > exchange, and for the internet in general. There are MANY things where > this is what was done by the community. Honest question...if someone > wants to put an extension in Rio, Brazil, do we let them? How about in > South Africa? Is there a line? An exchange has a purpose, and thats to > get everyone local to each other, on one fabric...otherwise we are > just making Cogents IX thing they sell, or any one of the number of > global fabrics. At SOME point we need to say enough is enough. I am > NOT saying we are there yet, but to allow EVERYTHING is a bit too much > in the other direction. > > Reid > > Reid > > On Fri, Mar 25, 2022 at 12:44 AM Jeremy Lumby <jlumby(a)mnvoip.com> wrote: > > I completely agree that the number of people who know very little > about BGP is growing quickly, the real question is how do you deal > with this problem. Do you not permit things across the board > because of this, meaning that the opportunity is lost for the > people that understand what they are doing? Or do you put as many > reasonable precautions in place so that when someone screws up, it > mostly just impacts them, and all of the other members maintain > granular control? > > *From:*MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] *On > Behalf Of *Reid Fishler > *Sent:* Thursday, March 24, 2022 9:12 PM > *To:* MICE-DISCUSS(a)LISTS.IPHOUSE.NET > *Subject:* Re: [MICE-DISCUSS] MICE Remote Switch Policy > > The issue is there are going to be more and more networks that are > buying these peering services that don't always know what they > are... Either by services, or because 'someone told me to'... Its > not always those in the know that buy these things... Sometimes > it's networks that DON'T know. > > Reid > > On Thu, Mar 24, 2022, 10:04 PM Jeremy Lumby <jlumby(a)mnvoip.com> wrote: > > I understand the point a little better now. I would say it > depends on the specific type of CDN. The more traditional > ones like Cloudflare and Akamai it would not be a huge > disincentive because they market themselves based on how > close/low latency they are to the end user. Other CDNs that > are delivering more of their own content like Netflix/Google > would be more grateful for the free transport, and care less > about the added latency (assuming no loss). > > -----Original Message----- > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On > Behalf Of Richard Laager > Sent: Thursday, March 24, 2022 8:46 PM > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: Re: [MICE-DISCUSS] MICE Remote Switch Policy > > On 3/24/22 18:00, Jeremy Lumby wrote: > > As for a disincentive for CDN's to connect, I have only seen > the opposite. Most CDN's will only accept a connection to the > core. The only time I have seen them connect to a remote was > for a secondary connection to gain switch diversity. > > I wasn't talking about CDNs connecting to remotes. The > concern, or at > least how I understood it, was: Imagine we put a MICE > extension in city > X. In the immediate term, that's great, as now networks in > city X can > get content from Minneapolis CDNs. But in the longer-term, it > may create > a disincentive for CDNs to go to city X. > > Counter-point: Whether CDNs come to city X is not our problem. > > -- > 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> > > > -- > > Reid Fishler > Senior Director > Hurricane Electric > +1-510-580-4178 > > ------------------------------------------------------------------------ > > 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> > -- ================================================================ Aaron Wendel Chief Technical Officer Wholesale Internet, Inc. (AS 32097) (816)550-9030 http://www.wholesaleinternet.com ================================================================

March 25, 2022

Re: MICE Remote Switch Policy

by Justin Krejci

Very interesting discussion so far. Sorry if my email gets a little rambling, it's kind of a stream of thought. I am of the opinion that there be a minimum set of objective criteria to be met for a proposed/requested remote switch. If meeting the criteria is demonstrated, then the proposal/request can be further considered with a very much subjective lens by the board and community with questions for them to answer such as: * Is this something we want because we think it will help MICE? * What do we know of the requesting organization and their history with regards to the community and MICE? * Are they in good standing financially with regards to any existing MICE invoices? * Maybe a formal or informal Q&A could be had between the requesting organization and the community via mailing list or online in conference call/bridge. * Are there sufficient technical MICE resources available (switch ports, man power, IP addresses, etc) We should not try to enumerate every single one of the objective ways in which a network/organization might fall into the "do not allow them to connect to MICE" both as a regular member and as a remote switch operator, as someone said earlier, there are too many possibilities. We should have a decent set of guidelines/requirements and then let the humans of the board and community use their own thinking and intuition to assess on a case by case basis if this is a good opportunity or is it too risky. As for the specific criteria to be objective about, we can dig into the weeds on pros and cons of far-away and close-by members and remote switches, ways to view and treat them (eg BGP communities), long-haul requirements (eg SLA, redundancies, etc), dedicated vs non-dedicated switching hardware, specific hardware capabilities required, geographic distance limits, link usage/capacity ratio, etc. but I think it is too early to work through all of the objective criteria and their solutions to problems until we actually decide we want to go down the road of having an expanded set of objective criteria and is the official track to become a remote switch operator. So for example, if we decide we are going to clamp down hard on accepting new remote switches and making remote switches very difficult to do, then the criteria question because more or less moot and we don't need spend a lot of cycles thinking them all through. It sounds like maybe we need to have a majority consensus on how to proceed. I think directly and indirectly there is a lot of data on remote switches generally and specifically far-away remote switches for IXes like MICE that can be considered. There are variables/risks to consider and there are likely accommodating solutions to those. Do we want to be strict or lax about taking on new remote switches? Do we want to only take remote switches on based on solicited requests from MICE? Do we want to only allow official MICE participant members to be able to become remote switch operators or can anyone become a remote operator? Is there a finite number of new remote switches we should consider having in total or per year how many we can take on? All sorts of possible considerations if we want to get into it. To recap, I personally think step 1 is that we should decide to have an intentionally defined set of objective criteria that if all are met then a subjective determination is made by the board including the use of solicited member/community feedback. If yes, step 2 is then to clearly define that set of objective criteria we care about. I think the elected board should be the last line of defense against making mistakes and to mitigate use of loopholes. They should be trusted to use good judgment as the final say on requests for remote switches. If something is concerning or otherwise fishy, they can ultimately deny or indefinitely delay requests until such time as they are satisfied. ________________________________ From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> on behalf of Jeremy Lumby <jlumby(a)MNVOIP.COM> Sent: Thursday, March 24, 2022 6:00 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] MICE Remote Switch Policy A few of my opinions on the topics that Richard brought up/relayed for others: For the most part I think the approval of remote switches should be discretionary. With that being said I think there should be a few stipulations. There should be minimum criteria to be met in order to even consider the proposal. My reasoning for the minimum criteria is to save time and effort since MICE is almost all volunteer based, and I am in favor of keeping it that way. I am in favor of the following minimums for a remote proposal: -Dedicated switching hardware -Minimum of 5 participants interested in connecting immediately -66% utilization upgrade threshold -Agreement that the switch operator will enforce, and keep up with MICE technical requirements -Agreement that the switch operator will cover all costs of operation including uplink, and MICE fees -Agreement that the switch operator notifies all participants that they are connecting to a remote switch, as well as is the primary source of support for connected members. If the agreed upon minimums are met then the proposal should go to the membership for discussion (for a fixed amount of time), and then the board for approval. I do feel that if board members were to vote against it, it should be for a reason that was discussed publically on the list first. On a somewhat related topic I have had a few different datacenters inquire about getting a MICE managed core switch installed. I think there should be minimum standards established for a core switch as well to save time and effort. In general I think they should be much greater than the list above. With respect to the location of a remote switch, I think distance is not an issue, and in some ways it is an advantage. When someone connects to a remote that is far from the core, everyone knows it. The location of the switch is documented on the participants page, and all of the members connecting through it are indicated as so. This gives network admin the ability to easily identify, and adjust their BGP metrics accordingly. I also like the idea that Jay proposed for communities that identify remote switch participants. If someone were to argue that distance was a negative, they would first need to propose blocking anyone connecting to the core across a long-haul circuit from outside of the metro. In cases of long-haul to the core, the only one that has a clue that it is going on is the participant themselves leaving all other members clueless. I have received several inquiries from members about high latency to certain peers who long-haul into the MICE core. I am often unsure if I can divulge their remote location to the person asking since often times the only way I know is based on the carrier listed on the cross connect tag going into the core (which is not public knowledge like the participants page is). As to the dedicated hardware requirement I would also like to state that in general I feel that if someone is serious about increasing connectivity to MICE, they are willing to spend the money for the hardware (not just trying to save on a cross connect for a friend), and also willing to spend the time to be the first line of defense when it comes to troubleshooting. Not to mention the much simpler config/troubleshooting that comes along with dedicated hardware, this all keeps the load off of the volunteers running MICE. I do not feel that any NEW minimum requirements should apply to existing switches. I think they should still be bound to their original proposals (within reason). I believe that all of those proposals would include enforcing current MICE rules on their switch (such as number of MAC addresses, and BPDU error disables) As for a disincentive for CDN's to connect, I have only seen the opposite. Most CDN's will only accept a connection to the core. The only time I have seen them connect to a remote was for a secondary connection to gain switch diversity. As for broadcast traffic I agree that it can get more dangerous across a long-haul link, however I think a larger issue is the lack of enforcement of good router config hygiene. To that point, a quarantine VLAN helps detection/enforcement before the problem gets out of hand. The complexities it leads to would be another reason to support requiring dedicated hardware for remote switches. Jeremy Lumby Minnesota VoIP 9217 17th Ave S #216 Bloomington, MN 55425 M: 612-355-7740 D: 612-392-6814 F: 952-873-7425 jlumby(a)mnvoip.com From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Richard Laager Sent: Thursday, March 24, 2022 3:59 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: [MICE-DISCUSS] MICE Remote Switch Policy I've had some discussions with the board as well as with Jay and Jeremy on these topics. The board consensus was to bring this (in general) to the membership for more input. As to the specifics, while I know others agree with at least parts of this, I'm only speaking for myself here. I'll let everyone articulate their own positions. (This disclaimer should not be read as me signaling the existance of disagreement either. I just don't want to put words in other people's mouths.) Our current policy on remote switches is here: https://micemn.net/technical.html#remotes It has the proposal presented to the membership for discussion, then the board makes a final decision. Is this decision ministerial or discretionary? That is, if the remote switch proposal checks all the boxes in our policy, is MICE "required" (supposed to) always grant it, or is the board supposed to apply some discretion? If the decision is ministerial, then why bother bringing this to the board (or for that matter, the members) all? Couldn't we save a bunch of time and hassle and simply have management (in some form, whether that's me, Jay, and/or Jeremy) approve it? If the decision is discretionary, are there particular criteria that the board should consider (above and beyond the listed criteria)? One criteria used in a discussion I had (and I can't recall which of us said it first) is "MICE's strategic interests". What would that phrase mean to you; what are some strategic interests of MICE? For a bit of an absurd example for the thought experiment, imagine that someone was proposing a MICE remote switch, but we knew their goal was to attract a bunch of members and then convert that into a competing exchange. Is that something we would have to agree to simply because they met all the objective criteria? When we were new and little, MICE certainly had an interest in making every decision in a way that would maximize additional peering. However, at this point, the calculus may be (I'd argue is) different. We are moving a lot of traffic and are important to our members / in our region. We have to be careful that our decisions do not destabilize the exchange--in multiple ways: technical, financial, or political. Either way, should we expand the list of objective criteria in the policy? Some examples: • We have previously discussed dedicated vs non-dedicated switches. As time goes along, I am more convinced than ever that MICE remote switches should be required to be dedicated. Non-dedicated switches present extra complications for configuration and troubleshooting. (Jeremy has some additional insight on this that he will share.) I think we should make it a requirement that the switch be dedicated. (Perhaps the board could still grant an exception in exceptional cases.) • Should we require that a remote switch have X number of participants committed? And if so, what is X? In my view, it hardly makes sense to have a remote switch one or two participants. They could just as well backhaul to MICE directly. The criteria for allowing new remote switches vs disconnecting existing remotes need not be the same. If we set a minimum of e.g. 5 participants, we don't necessarily need to disconnect existing remotes that don't meet that. And I think the consensus is that we would not, barring them creating some significant problem. How do we feel about far-away remote switches? (This is a live issue in the context of the proposed Kansas City remote.) Some concerns: • At Wiktel, I peer with MN VoIP's far away extensions in Minneapolis. For example, I peer at SeattleIX (SIX) in Minneapolis. This has caused me some issues. For example, latency-sensitive gaming traffic was tromboning Wiktel-Minneapolis-Seattle-Chicago-Seattle-Minneapolis-Wiktel rather than Wiktel-Chicago-Wiktel. • Is it safe to have a broadcast domain that stretches across multiple states (or half a continent, in the SIX case)? • If we take this to its logical extreme... Imagine we had a MICE extension in every datacenter in the U.S. I think that is pretty obviously untenable for a bunch of reasons. Something close to that is actually within the realm of possibility, with some of these virtual extension things that people are doing. (Reid would be able to cite who.) Granted, nobody is proposing that today, but where should we draw the line? • Far-away extensions may reduce the incentive for CDNs to install locally. Some counterpoints: • Nobody is forcing networks to use the far-away remotes. • If people choose to use them, they take their routing into their own hands. They need to understand the tromboning risk and set their own routing policy. o Counter-counterpoint: Do they? Especially smaller / less experienced networks? Have we adequately warned them? o Counter-counterpoint: The existence of these far-away peers doesn't affect just them. It also affects the other networks with which they peer. Everyone on the exchange needs to be aware of the existence of far-away participants and handle their routing policy accordingly. If there are enough far-away peers, this might tip networks into an opt-in route server policy, or even to only do bilaterals. This will disadvantage small participants. • Networks can backhaul into far-away exchanges directly. o Counter-counterpoint: But a remote switch makes this cheaper / more feasible / more common, which is literally the point of creating such a remote switch. • For a local eyeball network in Des Moines, neither MICE nor Kansas City are far-away from me. Even MICE via Kansas City is not likely to be problematic. This might be the only economically feasible way they could peer with Minneapolis content. -- Richard ________________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

March 25, 2022

Re: MICE Remote Switch Policy

by Jeremy Lumby

Precisely why I am a fan of something in the middle. The minimum requirements will weed out the silly proposals and save time/effort. The public discussion will bring up issues that should be considered, and then the board can take the discussion, and use it to make a decision. With this being said I would say if the minimums were met, and there was no discussion, it should just be rubber stamped by the board. There are plenty of people who know a lot about BGP/networking on this list so there are plenty of opportunities to bring potential issues to light. I have thought a lot about running an extension switch in Minneapolis for an IX outside of North America. When you run the cost/benefit it just does not make any sense. I think those things would come to light in the public discussion phase. My personal opinion is anything outside of North America just does not make sense for the “Midwest”. The only reason that Cogent’s product does not fall on its face is because it does not need to stand on its own. If Cogent was not already in those locations with their other services, it would never have made it out of the gate. Marketing is probably the only thing keeping it alive. Jeremy From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Reid Fishler Sent: Thursday, March 24, 2022 11:53 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] MICE Remote Switch Policy The answer is somewhere in the middle. We do whats best for the exchange, and for the internet in general. There are MANY things where this is what was done by the community. Honest question...if someone wants to put an extension in Rio, Brazil, do we let them? How about in South Africa? Is there a line? An exchange has a purpose, and thats to get everyone local to each other, on one fabric...otherwise we are just making Cogents IX thing they sell, or any one of the number of global fabrics. At SOME point we need to say enough is enough. I am NOT saying we are there yet, but to allow EVERYTHING is a bit too much in the other direction. Reid Reid On Fri, Mar 25, 2022 at 12:44 AM Jeremy Lumby <jlumby(a)mnvoip.com> wrote: I completely agree that the number of people who know very little about BGP is growing quickly, the real question is how do you deal with this problem. Do you not permit things across the board because of this, meaning that the opportunity is lost for the people that understand what they are doing? Or do you put as many reasonable precautions in place so that when someone screws up, it mostly just impacts them, and all of the other members maintain granular control? From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Reid Fishler Sent: Thursday, March 24, 2022 9:12 PM To:MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] MICE Remote Switch Policy The issue is there are going to be more and more networks that are buying these peering services that don't always know what they are... Either by services, or because 'someone told me to'... Its not always those in the know that buy these things... Sometimes it's networks that DON'T know. Reid On Thu, Mar 24, 2022, 10:04 PM Jeremy Lumby <jlumby(a)mnvoip.com> wrote: I understand the point a little better now. I would say it depends on the specific type of CDN. The more traditional ones like Cloudflare and Akamai it would not be a huge disincentive because they market themselves based on how close/low latency they are to the end user. Other CDNs that are delivering more of their own content like Netflix/Google would be more grateful for the free transport, and care less about the added latency (assuming no loss). -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Richard Laager Sent: Thursday, March 24, 2022 8:46 PM To:MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] MICE Remote Switch Policy On 3/24/22 18:00, Jeremy Lumby wrote: > As for a disincentive for CDN's to connect, I have only seen the opposite. Most CDN's will only accept a connection to the core. The only time I have seen them connect to a remote was for a secondary connection to gain switch diversity. I wasn't talking about CDNs connecting to remotes. The concern, or at least how I understood it, was: Imagine we put a MICE extension in city X. In the immediate term, that's great, as now networks in city X can get content from Minneapolis CDNs. But in the longer-term, it may create a disincentive for CDNs to go to city X. Counter-point: Whether CDNs come to city X is not our problem. -- 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 -- Reid Fishler Senior Director Hurricane Electric +1-510-580-4178 ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

March 25, 2022

Re: MICE Remote Switch Policy

by Reid Fishler

Tell that to Europe, where the market has been changed by some of the LARGER guys. Reid On Fri, Mar 25, 2022 at 12:27 PM Aaron Wendel <aaron(a)wholesaleinternet.net> wrote: > I think the landscape of peering is changing. Traditionally peering > enables lower latency and better performance by keeping local traffic > local. While that's still the case, I see more and more people looking > at remote peering as a way to gain more granularity in traffic > engineering. There's a large demand in the KC market for peering > outside the market for just that. > > SIX is just about up in KC (F You Lumen... 6 months to do an XC in your > own facility?), DE-CIX is coming to KC (active but not announced yet) > and others are in the works. There were a lot of discussions at the > KCIX table about how these exchanges coming into KC would affect the > local peering. The answer seems to be, "Not at all." The use cases > between local peering and remote peering are different enough that they > can coexist without market dilution. > > In the future, I believe IXs will be seen more like mini, focused ISPs > used by organizations looking to branch out closer to the edge where > their customers are concentrated. > > Aaron > > > > > On 3/24/2022 11:53 PM, Reid Fishler wrote: > > The answer is somewhere in the middle. We do whats best for the > > exchange, and for the internet in general. There are MANY things where > > this is what was done by the community. Honest question...if someone > > wants to put an extension in Rio, Brazil, do we let them? How about in > > South Africa? Is there a line? An exchange has a purpose, and thats to > > get everyone local to each other, on one fabric...otherwise we are > > just making Cogents IX thing they sell, or any one of the number of > > global fabrics. At SOME point we need to say enough is enough. I am > > NOT saying we are there yet, but to allow EVERYTHING is a bit too much > > in the other direction. > > > > Reid > > > > > > Reid > > > > > > On Fri, Mar 25, 2022 at 12:44 AM Jeremy Lumby <jlumby(a)mnvoip.com> wrote: > > > > I completely agree that the number of people who know very little > > about BGP is growing quickly, the real question is how do you deal > > with this problem. Do you not permit things across the board > > because of this, meaning that the opportunity is lost for the > > people that understand what they are doing? Or do you put as many > > reasonable precautions in place so that when someone screws up, it > > mostly just impacts them, and all of the other members maintain > > granular control? > > > > *From:*MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] *On > > Behalf Of *Reid Fishler > > *Sent:* Thursday, March 24, 2022 9:12 PM > > *To:* MICE-DISCUSS(a)LISTS.IPHOUSE.NET > > *Subject:* Re: [MICE-DISCUSS] MICE Remote Switch Policy > > > > The issue is there are going to be more and more networks that are > > buying these peering services that don't always know what they > > are... Either by services, or because 'someone told me to'... Its > > not always those in the know that buy these things... Sometimes > > it's networks that DON'T know. > > > > Reid > > > > On Thu, Mar 24, 2022, 10:04 PM Jeremy Lumby <jlumby(a)mnvoip.com> > wrote: > > > > I understand the point a little better now. I would say it > > depends on the specific type of CDN. The more traditional > > ones like Cloudflare and Akamai it would not be a huge > > disincentive because they market themselves based on how > > close/low latency they are to the end user. Other CDNs that > > are delivering more of their own content like Netflix/Google > > would be more grateful for the free transport, and care less > > about the added latency (assuming no loss). > > > > -----Original Message----- > > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On > > Behalf Of Richard Laager > > Sent: Thursday, March 24, 2022 8:46 PM > > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > > Subject: Re: [MICE-DISCUSS] MICE Remote Switch Policy > > > > On 3/24/22 18:00, Jeremy Lumby wrote: > > > As for a disincentive for CDN's to connect, I have only seen > > the opposite. Most CDN's will only accept a connection to the > > core. The only time I have seen them connect to a remote was > > for a secondary connection to gain switch diversity. > > > > I wasn't talking about CDNs connecting to remotes. The > > concern, or at > > least how I understood it, was: Imagine we put a MICE > > extension in city > > X. In the immediate term, that's great, as now networks in > > city X can > > get content from Minneapolis CDNs. But in the longer-term, it > > may create > > a disincentive for CDNs to go to city X. > > > > Counter-point: Whether CDNs come to city X is not our problem. > > > > -- > > 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> > > > > > > > > -- > > Reid Fishler > > Senior Director > > Hurricane Electric > > +1-510-580-4178 > > > > ------------------------------------------------------------------------ > > > > 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> > > > > -- > ================================================================ > Aaron Wendel > Chief Technical Officer > Wholesale Internet, Inc. (AS 32097) > (816)550-9030 > http://www.wholesaleinternet.com > ================================================================ > > -- Reid Fishler Senior Director Hurricane Electric +1-510-580-4178

March 25, 2022

Re: MICE Remote Switch Policy

by Jay Hanke

This would be a great panel discussion at the Peering Summit this summer. Reid/Aaron are you guys up for that? I'll find one non-mice guy to round it out. -- Jay Hanke, President South Front Networks jayhanke(a)southfront.io Phone 612-204-0000

March 25, 2022

Re: MICE Remote Switch Policy

by Aaron Wendel

I think the landscape of peering is changing. Traditionally peering enables lower latency and better performance by keeping local traffic local. While that's still the case, I see more and more people looking at remote peering as a way to gain more granularity in traffic engineering. There's a large demand in the KC market for peering outside the market for just that. SIX is just about up in KC (F You Lumen... 6 months to do an XC in your own facility?), DE-CIX is coming to KC (active but not announced yet) and others are in the works. There were a lot of discussions at the KCIX table about how these exchanges coming into KC would affect the local peering. The answer seems to be, "Not at all." The use cases between local peering and remote peering are different enough that they can coexist without market dilution. In the future, I believe IXs will be seen more like mini, focused ISPs used by organizations looking to branch out closer to the edge where their customers are concentrated. Aaron On 3/24/2022 11:53 PM, Reid Fishler wrote: > The answer is somewhere in the middle. We do whats best for the > exchange, and for the internet in general. There are MANY things where > this is what was done by the community. Honest question...if someone > wants to put an extension in Rio, Brazil, do we let them? How about in > South Africa? Is there a line? An exchange has a purpose, and thats to > get everyone local to each other, on one fabric...otherwise we are > just making Cogents IX thing they sell, or any one of the number of > global fabrics. At SOME point we need to say enough is enough. I am > NOT saying we are there yet, but to allow EVERYTHING is a bit too much > in the other direction. > > Reid > > > Reid > > > On Fri, Mar 25, 2022 at 12:44 AM Jeremy Lumby <jlumby(a)mnvoip.com> wrote: > > I completely agree that the number of people who know very little > about BGP is growing quickly, the real question is how do you deal > with this problem. Do you not permit things across the board > because of this, meaning that the opportunity is lost for the > people that understand what they are doing? Or do you put as many > reasonable precautions in place so that when someone screws up, it > mostly just impacts them, and all of the other members maintain > granular control? > > *From:*MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] *On > Behalf Of *Reid Fishler > *Sent:* Thursday, March 24, 2022 9:12 PM > *To:* MICE-DISCUSS(a)LISTS.IPHOUSE.NET > *Subject:* Re: [MICE-DISCUSS] MICE Remote Switch Policy > > The issue is there are going to be more and more networks that are > buying these peering services that don't always know what they > are... Either by services, or because 'someone told me to'... Its > not always those in the know that buy these things... Sometimes > it's networks that DON'T know. > > Reid > > On Thu, Mar 24, 2022, 10:04 PM Jeremy Lumby <jlumby(a)mnvoip.com> wrote: > > I understand the point a little better now. I would say it > depends on the specific type of CDN. The more traditional > ones like Cloudflare and Akamai it would not be a huge > disincentive because they market themselves based on how > close/low latency they are to the end user. Other CDNs that > are delivering more of their own content like Netflix/Google > would be more grateful for the free transport, and care less > about the added latency (assuming no loss). > > -----Original Message----- > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On > Behalf Of Richard Laager > Sent: Thursday, March 24, 2022 8:46 PM > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: Re: [MICE-DISCUSS] MICE Remote Switch Policy > > On 3/24/22 18:00, Jeremy Lumby wrote: > > As for a disincentive for CDN's to connect, I have only seen > the opposite. Most CDN's will only accept a connection to the > core. The only time I have seen them connect to a remote was > for a secondary connection to gain switch diversity. > > I wasn't talking about CDNs connecting to remotes. The > concern, or at > least how I understood it, was: Imagine we put a MICE > extension in city > X. In the immediate term, that's great, as now networks in > city X can > get content from Minneapolis CDNs. But in the longer-term, it > may create > a disincentive for CDNs to go to city X. > > Counter-point: Whether CDNs come to city X is not our problem. > > -- > 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> > > > > -- > Reid Fishler > Senior Director > Hurricane Electric > +1-510-580-4178 > > ------------------------------------------------------------------------ > > 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> > -- ================================================================ Aaron Wendel Chief Technical Officer Wholesale Internet, Inc. (AS 32097) (816)550-9030 http://www.wholesaleinternet.com ================================================================

March 25, 2022

Re: MICE Remote Switch Policy

by Reid Fishler

Unfortunately, alot now. They hire consultants to run things for them...and want to keep those hours VERY low if they can help it. Some of the people I have talked to have BGP/Network consultants from MSP! Reid On Fri, Mar 25, 2022 at 12:02 PM Aaron Wendel <aaron(a)wholesaleinternet.net> wrote: > How many people who have their own ASNs and IP space know nothing about > BGP? Of course the answer isn't zero but I'd have to think it's pretty > low. > > Aaron > > > On 3/24/2022 11:44 PM, Jeremy Lumby wrote: > > > > I completely agree that the number of people who know very little > > about BGP is growing quickly, the real question is how do you deal > > with this problem. Do you not permit things across the board because > > of this, meaning that the opportunity is lost for the people that > > understand what they are doing? Or do you put as many reasonable > > precautions in place so that when someone screws up, it mostly just > > impacts them, and all of the other members maintain granular control? > > > > -- Reid Fishler Senior Director Hurricane Electric +1-510-580-4178

March 25, 2022

Re: MICE Remote Switch Policy

by Aaron Wendel

How many people who have their own ASNs and IP space know nothing about BGP? Of course the answer isn't zero but I'd have to think it's pretty low. Aaron On 3/24/2022 11:44 PM, Jeremy Lumby wrote: > > I completely agree that the number of people who know very little > about BGP is growing quickly, the real question is how do you deal > with this problem. Do you not permit things across the board because > of this, meaning that the opportunity is lost for the people that > understand what they are doing? Or do you put as many reasonable > precautions in place so that when someone screws up, it mostly just > impacts them, and all of the other members maintain granular control? >

March 25, 2022

Re: MICE Remote Switch Policy

by Dean Bahls

Reasonableness. Keep that in mind and it’ll all be good. If it’s reasonable in the board’s mind to place an extension in Rio, Brazil or South Africa, then that’s what should be done. I would hope that the board doesn’t think that’s the case. Yes, there is a line, or a location….somewhere reasonably close/far away from Minneapolis. I don’t know where that is, but in general, I think you guys have a feeling for it. Dean From: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> On Behalf Of Reid Fishler Sent: Thursday, March 24, 2022 11:53 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] MICE Remote Switch Policy The answer is somewhere in the middle. We do whats best for the exchange, and for the internet in general. There are MANY things where this is what was done by the community. Honest question...if someone wants to put an extension in Rio, Brazil, do we let them? How about in South Africa? Is there a line? An exchange has a purpose, and thats to get everyone local to each other, on one fabric...otherwise we are just making Cogents IX thing they sell, or any one of the number of global fabrics. At SOME point we need to say enough is enough. I am NOT saying we are there yet, but to allow EVERYTHING is a bit too much in the other direction. Reid Reid On Fri, Mar 25, 2022 at 12:44 AM Jeremy Lumby <jlumby(a)mnvoip.com<mailto:jlumby@mnvoip.com>> wrote: I completely agree that the number of people who know very little about BGP is growing quickly, the real question is how do you deal with this problem. Do you not permit things across the board because of this, meaning that the opportunity is lost for the people that understand what they are doing? Or do you put as many reasonable precautions in place so that when someone screws up, it mostly just impacts them, and all of the other members maintain granular control? From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>] On Behalf Of Reid Fishler Sent: Thursday, March 24, 2022 9:12 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> Subject: Re: [MICE-DISCUSS] MICE Remote Switch Policy The issue is there are going to be more and more networks that are buying these peering services that don't always know what they are... Either by services, or because 'someone told me to'... Its not always those in the know that buy these things... Sometimes it's networks that DON'T know. Reid On Thu, Mar 24, 2022, 10:04 PM Jeremy Lumby <jlumby(a)mnvoip.com<mailto:jlumby@mnvoip.com>> wrote: I understand the point a little better now. I would say it depends on the specific type of CDN. The more traditional ones like Cloudflare and Akamai it would not be a huge disincentive because they market themselves based on how close/low latency they are to the end user. Other CDNs that are delivering more of their own content like Netflix/Google would be more grateful for the free transport, and care less about the added latency (assuming no loss). -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>] On Behalf Of Richard Laager Sent: Thursday, March 24, 2022 8:46 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> Subject: Re: [MICE-DISCUSS] MICE Remote Switch Policy On 3/24/22 18:00, Jeremy Lumby wrote: > As for a disincentive for CDN's to connect, I have only seen the opposite. Most CDN's will only accept a connection to the core. The only time I have seen them connect to a remote was for a secondary connection to gain switch diversity. I wasn't talking about CDNs connecting to remotes. The concern, or at least how I understood it, was: Imagine we put a MICE extension in city X. In the immediate term, that's great, as now networks in city X can get content from Minneapolis CDNs. But in the longer-term, it may create a disincentive for CDNs to go to city X. Counter-point: Whether CDNs come to city X is not our problem. -- 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 -- Reid Fishler Senior Director Hurricane Electric +1-510-580-4178 ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

March 25, 2022

Re: MICE Remote Switch Policy

by Reid Fishler

The answer is somewhere in the middle. We do whats best for the exchange, and for the internet in general. There are MANY things where this is what was done by the community. Honest question...if someone wants to put an extension in Rio, Brazil, do we let them? How about in South Africa? Is there a line? An exchange has a purpose, and thats to get everyone local to each other, on one fabric...otherwise we are just making Cogents IX thing they sell, or any one of the number of global fabrics. At SOME point we need to say enough is enough. I am NOT saying we are there yet, but to allow EVERYTHING is a bit too much in the other direction. Reid Reid On Fri, Mar 25, 2022 at 12:44 AM Jeremy Lumby <jlumby(a)mnvoip.com> wrote: > I completely agree that the number of people who know very little about > BGP is growing quickly, the real question is how do you deal with this > problem. Do you not permit things across the board because of this, > meaning that the opportunity is lost for the people that understand what > they are doing? Or do you put as many reasonable precautions in place so > that when someone screws up, it mostly just impacts them, and all of the > other members maintain granular control? > > > > *From:* MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] *On Behalf > Of *Reid Fishler > *Sent:* Thursday, March 24, 2022 9:12 PM > *To:* MICE-DISCUSS(a)LISTS.IPHOUSE.NET > *Subject:* Re: [MICE-DISCUSS] MICE Remote Switch Policy > > > > The issue is there are going to be more and more networks that are buying > these peering services that don't always know what they are... Either by > services, or because 'someone told me to'... Its not always those in the > know that buy these things... Sometimes it's networks that DON'T know. > > > > Reid > > > > On Thu, Mar 24, 2022, 10:04 PM Jeremy Lumby <jlumby(a)mnvoip.com> wrote: > > I understand the point a little better now. I would say it depends on the > specific type of CDN. The more traditional ones like Cloudflare and Akamai > it would not be a huge disincentive because they market themselves based on > how close/low latency they are to the end user. Other CDNs that are > delivering more of their own content like Netflix/Google would be more > grateful for the free transport, and care less about the added latency > (assuming no loss). > > -----Original Message----- > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of > Richard Laager > Sent: Thursday, March 24, 2022 8:46 PM > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: Re: [MICE-DISCUSS] MICE Remote Switch Policy > > On 3/24/22 18:00, Jeremy Lumby wrote: > > As for a disincentive for CDN's to connect, I have only seen the > opposite. Most CDN's will only accept a connection to the core. The only > time I have seen them connect to a remote was for a secondary connection to > gain switch diversity. > > I wasn't talking about CDNs connecting to remotes. The concern, or at > least how I understood it, was: Imagine we put a MICE extension in city > X. In the immediate term, that's great, as now networks in city X can > get content from Minneapolis CDNs. But in the longer-term, it may create > a disincentive for CDNs to go to city X. > > Counter-point: Whether CDNs come to city X is not our problem. > > -- > 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 > -- Reid Fishler Senior Director Hurricane Electric +1-510-580-4178

March 25, 2022

Re: MICE Remote Switch Policy

by Jeremy Lumby

I completely agree that the number of people who know very little about BGP is growing quickly, the real question is how do you deal with this problem. Do you not permit things across the board because of this, meaning that the opportunity is lost for the people that understand what they are doing? Or do you put as many reasonable precautions in place so that when someone screws up, it mostly just impacts them, and all of the other members maintain granular control? From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Reid Fishler Sent: Thursday, March 24, 2022 9:12 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] MICE Remote Switch Policy The issue is there are going to be more and more networks that are buying these peering services that don't always know what they are... Either by services, or because 'someone told me to'... Its not always those in the know that buy these things... Sometimes it's networks that DON'T know. Reid On Thu, Mar 24, 2022, 10:04 PM Jeremy Lumby <jlumby(a)mnvoip.com> wrote: I understand the point a little better now. I would say it depends on the specific type of CDN. The more traditional ones like Cloudflare and Akamai it would not be a huge disincentive because they market themselves based on how close/low latency they are to the end user. Other CDNs that are delivering more of their own content like Netflix/Google would be more grateful for the free transport, and care less about the added latency (assuming no loss). -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Richard Laager Sent: Thursday, March 24, 2022 8:46 PM To:MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] MICE Remote Switch Policy On 3/24/22 18:00, Jeremy Lumby wrote: > As for a disincentive for CDN's to connect, I have only seen the opposite. Most CDN's will only accept a connection to the core. The only time I have seen them connect to a remote was for a secondary connection to gain switch diversity. I wasn't talking about CDNs connecting to remotes. The concern, or at least how I understood it, was: Imagine we put a MICE extension in city X. In the immediate term, that's great, as now networks in city X can get content from Minneapolis CDNs. But in the longer-term, it may create a disincentive for CDNs to go to city X. Counter-point: Whether CDNs come to city X is not our problem. -- Richard ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

March 25, 2022

Re: MICE Remote Switch Policy

by Reid Fishler

The issue is there are going to be more and more networks that are buying these peering services that don't always know what they are... Either by services, or because 'someone told me to'... Its not always those in the know that buy these things... Sometimes it's networks that DON'T know. Reid On Thu, Mar 24, 2022, 10:04 PM Jeremy Lumby <jlumby(a)mnvoip.com> wrote: > I understand the point a little better now. I would say it depends on the > specific type of CDN. The more traditional ones like Cloudflare and Akamai > it would not be a huge disincentive because they market themselves based on > how close/low latency they are to the end user. Other CDNs that are > delivering more of their own content like Netflix/Google would be more > grateful for the free transport, and care less about the added latency > (assuming no loss). > > -----Original Message----- > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of > Richard Laager > Sent: Thursday, March 24, 2022 8:46 PM > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: Re: [MICE-DISCUSS] MICE Remote Switch Policy > > On 3/24/22 18:00, Jeremy Lumby wrote: > > As for a disincentive for CDN's to connect, I have only seen the > opposite. Most CDN's will only accept a connection to the core. The only > time I have seen them connect to a remote was for a secondary connection to > gain switch diversity. > > I wasn't talking about CDNs connecting to remotes. The concern, or at > least how I understood it, was: Imagine we put a MICE extension in city > X. In the immediate term, that's great, as now networks in city X can > get content from Minneapolis CDNs. But in the longer-term, it may create > a disincentive for CDNs to go to city X. > > Counter-point: Whether CDNs come to city X is not our problem. > > -- > Richard > >

March 25, 2022

Re: MICE Remote Switch Policy

by Jeremy Lumby

I understand the point a little better now. I would say it depends on the specific type of CDN. The more traditional ones like Cloudflare and Akamai it would not be a huge disincentive because they market themselves based on how close/low latency they are to the end user. Other CDNs that are delivering more of their own content like Netflix/Google would be more grateful for the free transport, and care less about the added latency (assuming no loss). -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Richard Laager Sent: Thursday, March 24, 2022 8:46 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] MICE Remote Switch Policy On 3/24/22 18:00, Jeremy Lumby wrote: > As for a disincentive for CDN's to connect, I have only seen the opposite. Most CDN's will only accept a connection to the core. The only time I have seen them connect to a remote was for a secondary connection to gain switch diversity. I wasn't talking about CDNs connecting to remotes. The concern, or at least how I understood it, was: Imagine we put a MICE extension in city X. In the immediate term, that's great, as now networks in city X can get content from Minneapolis CDNs. But in the longer-term, it may create a disincentive for CDNs to go to city X. Counter-point: Whether CDNs come to city X is not our problem. -- Richard

March 25, 2022