January 2015 - mice-discuss - lists.micemn.net

Re: UG 15 Reminder

by Hannigan, Martin

On Jan 5, 2015, at 9:58 AM, Chris Wopat <me(a)FALZ.NET> wrote: >> Date: Fri, 26 Dec 2014 10:59:18 -0600 >> From: Jason Hanke <jayhanke(a)NEUTRALPATH.NET> >> Subject: Re: UG 15 Reminder >> >> There has been a couple of requests for remote participation. >> >> Would it be possible to get a hard wired connection in the cafeteria? > > Folks, > > Curious if any progress has been made for a decent call in solution? I > had called in last meeting and it was very difficult to make out > anything. > > Thanks! > Chris Wopat +1. I'd like to be there in person and will someday get to one that doesn't collide with travel, but in the meantime a good dial solution would be great. Thanks! -M<

Jan. 5, 2015

Re: UG 15 Reminder

by Shaun Carlson

I will be sending out a meeting invite this week. I think I have a microphone solution that will work and we're working on getting a direct connect for Internet to the room to overcome the slow upload speeds that caused much of the issue last month. s *Shaun Carlson*Senior Manager of Information Technology | Arvig ph: (218) 346-8673 | em: shaun.carlson(a)arvig.com On Mon, Jan 5, 2015 at 8:58 AM, Chris Wopat <me(a)falz.net> wrote: > > Date: Fri, 26 Dec 2014 10:59:18 -0600 > > From: Jason Hanke <jayhanke(a)NEUTRALPATH.NET> > > Subject: Re: UG 15 Reminder > > > > There has been a couple of requests for remote participation. > > > > Would it be possible to get a hard wired connection in the cafeteria? > > Folks, > > Curious if any progress has been made for a decent call in solution? I > had called in last meeting and it was very difficult to make out > anything. > > Thanks! > Chris Wopat >

Jan. 5, 2015

Re: UG 15 Reminder

by Chris Wopat

> Date: Fri, 26 Dec 2014 10:59:18 -0600 > From: Jason Hanke <jayhanke(a)NEUTRALPATH.NET> > Subject: Re: UG 15 Reminder > > There has been a couple of requests for remote participation. > > Would it be possible to get a hard wired connection in the cafeteria? Folks, Curious if any progress has been made for a decent call in solution? I had called in last meeting and it was very difficult to make out anything. Thanks! Chris Wopat

Jan. 5, 2015

Re: Statistics reporting for MICE?

by Jeremy Lumby

I agree with the minimum of 24 hour notice to the list so that the members have the option of shutting down BGP ahead of time. I think if we make it much more complicated than that, then we discourage people from volunteering, and since MICE is 100% volunteer based, we would be doing ourselves a disservice. The donation was technically a personal one, however since I am a partial owner of MN VoIP, there is not much difference. I do want to reiterate my standing offer to anyone thinking about connecting to MICE, since I have not formally said it on the list. I am willing to provide free assistance to anyone interested in connecting to MICE, if it is a small entity that needs help with BGP, or a large one that does not have a local presence, and needs remote hands to get hooked up. Jeremy From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Brady Kittel Sent: Saturday, January 03, 2015 11:28 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Statistics reporting for MICE? I agree we probably need to set some standards for maintenance going forward, regardless I'd like to thank Jeremy (or is in MN VOIP?) for the equipment donated to MICE as those modules are several thousand dollars a piece and we could really use every port we can get right now. On Sat, Jan 3, 2015 at 11:00 PM, Jeremy Lumby <jlumby(a)mnvoip.com> wrote: Correct, inserting a hot swapable module essentially caused the 4200 switch to restart. From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Danny Meister Sent: Saturday, January 03, 2015 10:28 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Statistics reporting for MICE? So am I correct in understanding that there was some kind of maintenance activity on Friday afternoon? Our MICE facing port was physically down between 13:38:54 and 13:40:05 on Friday. -Danny Danny Meister – Network Engineer, Level III Atomic Data 615 North 3rd Street Minneapolis, MN 55401 612.466.2000 Main Line 612.466.2071 Direct Dial Twitter | Facebook | LinkedIn Safe. Simple. Smart. www.atomicdata.com From: Matthew Beckwell <matthewb(a)AITECH.NET> Reply-To: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> Date: Saturday, January 3, 2015 at 12:23 PM To: "MICE-DISCUSS(a)LISTS.IPHOUSE.NET" <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> Subject: Re: [MICE-DISCUSS] Statistics reporting for MICE? I'm with Andrew on his suggestion of either a formalized or gentlemen's agreement for a "heads up" with these types of activities. We experienced at least a partial outage (i.e. UDP Packet Loss) over MICE between 13:38:47 and 13:40:02 on Friday. I know this activity wasn't supposed to be service impacting-- but accidents and unexpected things happen. A heads up would give conservative members the opportunity to re-route in a controlled manner (if they desire). My personal preference would be a 24 hour notice so I could take action the night before, but I'll take what I can get (even if it's only an hour). ~Matthew Matthew Beckwell - Director of Network Operations Advanced Integrated Technologies Technical Support: 1-800-300-5408 Office: 1-952-829-5511 x204 E-Mail: matthewb(a)aitech.net On Sat, Jan 3, 2015 at 8:01 AM, Andrew Hoyos <hoyosa(a)gmail.com> wrote: I may have missed something, but I don’t recall seeing any email chatter about this happening. Unsure what the normal ops/maintenance protocol is, but I’d say when doing stuff like below (module adds/swaps), at least a heads up to mice-discuss would be in order for the benefit of all the members. Or given the growth of MICE, perhaps it’s time the steering committee should formalize something there. Thoughts from other folks? As far as the graphs, we should look at fixing the RRD files to remove that spike with the wacky/erroneous values so things look proper still. I’d be happy to help with that if anyone needs a hand. I think there may even be a Cacti plugin that does that, IIRC. -- Andrew Hoyos hoyosa(a)gmail.com > On Jan 2, 2015, at 8:28 PM, Jeremy Lumby <jlumby(a)MNVOIP.COM> wrote: > > The huge Cacti traffic spike coincided with adding a 4 port fiber module to the 4200 switch. Juniper claimed it was hot swappable, however the issues were more than they eluded to. > > This came about since I donated some modules to hold MICE over until a more permanent hardware upgrade can be picked. The good news is the 4500 now has 4 additional SFP+ ports, and the 4200 now has 4 SFP ports. This will allow some of the members that are at 1G that needed a fiber handoff to be moved to the 4200 freeing up additional 10G ports in the 4500. > > -----Original Message----- > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Richard Laager > Sent: Friday, January 02, 2015 8:06 PM > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: Re: [MICE-DISCUSS] Statistics reporting for MICE? > > I was going to say that I thought we were doing exactly that at http://micemn.net but when I pulled up the website to verify, I see that something is very wrong with the graph. > > Did anyone change something in Cacti recently? > > -- > Richard > >> On Jan 2, 2015, at 7:10 PM, Hannigan, Martin <marty(a)AKAMAI.COM> wrote: >> >> >> >> FYI, >> >> http://micelg.usinternet.com/export/graph_385.html shows in+out where http://micelg.usinternet.com/export/graph_384.html shows in/out. Which one should we use? >> >> I'd like to suggest that MICE follow OIX-1 with respect to agg and other stats: >> >> "The IXP MUST publish on a publicly available website the total sum of >> all incoming and outgoing traffic in bps from all connected networks >> on the public peering VLAN. The traffic sum MUST include the traffic on customer facing ports only and MUST be made up of 5 min average traffic measurements. A distinction MUST be made between the traffic on the public peering VLAN and any other interconnection service." >> >> Traffic "massiveness" isn't as important as how many ASNs are connected. Traffic is an unpredictable and unreliable indicator of an exchanges size and value. ASN counts are much more granular for potential peers to build a case to join. >> >> >> Best, >> >> -M< >> >> >> >> >> 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 To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Jan. 4, 2015

Re: Statistics reporting for MICE?

by Brady Kittel

I agree we probably need to set some standards for maintenance going forward, regardless I'd like to thank Jeremy (or is in MN VOIP?) for the equipment donated to MICE as those modules are several thousand dollars a piece and we could really use every port we can get right now. On Sat, Jan 3, 2015 at 11:00 PM, Jeremy Lumby <jlumby(a)mnvoip.com> wrote: > Correct, inserting a hot swapable module essentially caused the 4200 > switch to restart. > > > > *From:* MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] *On Behalf > Of *Danny Meister > *Sent:* Saturday, January 03, 2015 10:28 PM > > *To:* MICE-DISCUSS(a)LISTS.IPHOUSE.NET > *Subject:* Re: [MICE-DISCUSS] Statistics reporting for MICE? > > > > So am I correct in understanding that there was some kind of maintenance > activity on Friday afternoon? Our MICE facing port was physically down > between 13:38:54 and 13:40:05 on Friday. > > > > -Danny > > > > > > *Danny Meister* – Network Engineer, Level III > > > > Atomic Data > 615 North 3rd Street > Minneapolis, MN 55401 > 612.466.2000 Main Line > 612.466.2071 Direct Dial > > Twitter <http://twitter.com/AtomicData> | Facebook > <http://www.facebook.com/AtomicDataCenters> | LinkedIn > <http://www.linkedin.com/companies/atomic-data-centers> > > Safe. Simple. Smart. > www.atomicdata.com > > > > *From: *Matthew Beckwell <matthewb(a)AITECH.NET> > *Reply-To: *MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> > *Date: *Saturday, January 3, 2015 at 12:23 PM > *To: *"MICE-DISCUSS(a)LISTS.IPHOUSE.NET" <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> > *Subject: *Re: [MICE-DISCUSS] Statistics reporting for MICE? > > > > I'm with Andrew on his suggestion of either a formalized or gentlemen's > agreement for a "heads up" with these types of activities. > > > > We experienced at least a partial outage (i.e. UDP Packet Loss) over MICE > between 13:38:47 and 13:40:02 on Friday. > > > > I know this activity wasn't supposed to be service impacting-- but > accidents and unexpected things happen. > > > > A heads up would give conservative members the opportunity to re-route in > a controlled manner (if they desire). My personal preference would be a 24 > hour notice so I could take action the night before, but I'll take what I > can get (even if it's only an hour). > > > > ~Matthew > > > > > *Matthew Beckwell* - Director of Network Operations > Advanced Integrated Technologies > Technical Support: 1-800-300-5408 > Office: 1-952-829-5511 x204 > E-Mail: matthewb(a)aitech.net > > > > On Sat, Jan 3, 2015 at 8:01 AM, Andrew Hoyos <hoyosa(a)gmail.com> wrote: > > I may have missed something, but I don’t recall seeing any email chatter > about this happening. Unsure what the normal ops/maintenance protocol is, > but I’d say when doing stuff like below (module adds/swaps), at least a > heads up to mice-discuss would be in order for the benefit of all the > members. Or given the growth of MICE, perhaps it’s time the steering > committee should formalize something there. Thoughts from other folks? > > As far as the graphs, we should look at fixing the RRD files to remove > that spike with the wacky/erroneous values so things look proper still. I’d > be happy to help with that if anyone needs a hand. I think there may even > be a Cacti plugin that does that, IIRC. > > -- > Andrew Hoyos > hoyosa(a)gmail.com > > > > > On Jan 2, 2015, at 8:28 PM, Jeremy Lumby <jlumby(a)MNVOIP.COM> wrote: > > > > The huge Cacti traffic spike coincided with adding a 4 port fiber module > to the 4200 switch. Juniper claimed it was hot swappable, however the > issues were more than they eluded to. > > > > This came about since I donated some modules to hold MICE over until a > more permanent hardware upgrade can be picked. The good news is the 4500 > now has 4 additional SFP+ ports, and the 4200 now has 4 SFP ports. This > will allow some of the members that are at 1G that needed a fiber handoff > to be moved to the 4200 freeing up additional 10G ports in the 4500. > > > > -----Original Message----- > > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of > Richard Laager > > Sent: Friday, January 02, 2015 8:06 PM > > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > > Subject: Re: [MICE-DISCUSS] Statistics reporting for MICE? > > > > I was going to say that I thought we were doing exactly that at > http://micemn.net but when I pulled up the website to verify, I see that > something is very wrong with the graph. > > > > Did anyone change something in Cacti recently? > > > > -- > > Richard > > > >> On Jan 2, 2015, at 7:10 PM, Hannigan, Martin <marty(a)AKAMAI.COM> wrote: > >> > >> > >> > >> FYI, > >> > >> http://micelg.usinternet.com/export/graph_385.html shows in+out where > http://micelg.usinternet.com/export/graph_384.html shows in/out. Which > one should we use? > >> > >> I'd like to suggest that MICE follow OIX-1 with respect to agg and > other stats: > >> > >> "The IXP MUST publish on a publicly available website the total sum of > >> all incoming and outgoing traffic in bps from all connected networks > >> on the public peering VLAN. The traffic sum MUST include the traffic on > customer facing ports only and MUST be made up of 5 min average traffic > measurements. A distinction MUST be made between the traffic on the public > peering VLAN and any other interconnection service." > >> > >> Traffic "massiveness" isn't as important as how many ASNs are > connected. Traffic is an unpredictable and unreliable indicator of an > exchanges size and value. ASN counts are much more granular for potential > peers to build a case to join. > >> > >> > >> Best, > >> > >> -M< > >> > >> > >> > >> > >> > > > > > ------------------------------ > > 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 >

Jan. 4, 2015

Re: Statistics reporting for MICE?

by Jeremy Lumby

Correct, inserting a hot swapable module essentially caused the 4200 switch to restart. From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Danny Meister Sent: Saturday, January 03, 2015 10:28 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] Statistics reporting for MICE? So am I correct in understanding that there was some kind of maintenance activity on Friday afternoon? Our MICE facing port was physically down between 13:38:54 and 13:40:05 on Friday. -Danny Danny Meister – Network Engineer, Level III Atomic Data 615 North 3rd Street Minneapolis, MN 55401 612.466.2000 Main Line 612.466.2071 Direct Dial Twitter | Facebook | LinkedIn Safe. Simple. Smart. www.atomicdata.com From: Matthew Beckwell <matthewb(a)AITECH.NET> Reply-To: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> Date: Saturday, January 3, 2015 at 12:23 PM To: "MICE-DISCUSS(a)LISTS.IPHOUSE.NET" <MICE-DISCUSS(a)LISTS.IPHOUSE.NET> Subject: Re: [MICE-DISCUSS] Statistics reporting for MICE? I'm with Andrew on his suggestion of either a formalized or gentlemen's agreement for a "heads up" with these types of activities. We experienced at least a partial outage (i.e. UDP Packet Loss) over MICE between 13:38:47 and 13:40:02 on Friday. I know this activity wasn't supposed to be service impacting-- but accidents and unexpected things happen. A heads up would give conservative members the opportunity to re-route in a controlled manner (if they desire). My personal preference would be a 24 hour notice so I could take action the night before, but I'll take what I can get (even if it's only an hour). ~Matthew Matthew Beckwell - Director of Network Operations Advanced Integrated Technologies Technical Support: 1-800-300-5408 Office: 1-952-829-5511 x204 E-Mail: matthewb(a)aitech.net On Sat, Jan 3, 2015 at 8:01 AM, Andrew Hoyos <hoyosa(a)gmail.com> wrote: I may have missed something, but I don’t recall seeing any email chatter about this happening. Unsure what the normal ops/maintenance protocol is, but I’d say when doing stuff like below (module adds/swaps), at least a heads up to mice-discuss would be in order for the benefit of all the members. Or given the growth of MICE, perhaps it’s time the steering committee should formalize something there. Thoughts from other folks? As far as the graphs, we should look at fixing the RRD files to remove that spike with the wacky/erroneous values so things look proper still. I’d be happy to help with that if anyone needs a hand. I think there may even be a Cacti plugin that does that, IIRC. -- Andrew Hoyos hoyosa(a)gmail.com > On Jan 2, 2015, at 8:28 PM, Jeremy Lumby <jlumby(a)MNVOIP.COM> wrote: > > The huge Cacti traffic spike coincided with adding a 4 port fiber module to the 4200 switch. Juniper claimed it was hot swappable, however the issues were more than they eluded to. > > This came about since I donated some modules to hold MICE over until a more permanent hardware upgrade can be picked. The good news is the 4500 now has 4 additional SFP+ ports, and the 4200 now has 4 SFP ports. This will allow some of the members that are at 1G that needed a fiber handoff to be moved to the 4200 freeing up additional 10G ports in the 4500. > > -----Original Message----- > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Richard Laager > Sent: Friday, January 02, 2015 8:06 PM > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: Re: [MICE-DISCUSS] Statistics reporting for MICE? > > I was going to say that I thought we were doing exactly that at http://micemn.net but when I pulled up the website to verify, I see that something is very wrong with the graph. > > Did anyone change something in Cacti recently? > > -- > Richard > >> On Jan 2, 2015, at 7:10 PM, Hannigan, Martin <marty(a)AKAMAI.COM> wrote: >> >> >> >> FYI, >> >> http://micelg.usinternet.com/export/graph_385.html shows in+out where http://micelg.usinternet.com/export/graph_384.html shows in/out. Which one should we use? >> >> I'd like to suggest that MICE follow OIX-1 with respect to agg and other stats: >> >> "The IXP MUST publish on a publicly available website the total sum of >> all incoming and outgoing traffic in bps from all connected networks >> on the public peering VLAN. The traffic sum MUST include the traffic on customer facing ports only and MUST be made up of 5 min average traffic measurements. A distinction MUST be made between the traffic on the public peering VLAN and any other interconnection service." >> >> Traffic "massiveness" isn't as important as how many ASNs are connected. Traffic is an unpredictable and unreliable indicator of an exchanges size and value. ASN counts are much more granular for potential peers to build a case to join. >> >> >> Best, >> >> -M< >> >> >> >> >> 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

Jan. 4, 2015

Re: Statistics reporting for MICE?

by Danny Meister

So am I correct in understanding that there was some kind of maintenance activity on Friday afternoon? Our MICE facing port was physically down between 13:38:54 and 13:40:05 on Friday. -Danny Danny Meister - Network Engineer, Level III Atomic Data 615 North 3rd Street Minneapolis, MN 55401 612.466.2000 Main Line 612.466.2071 Direct Dial Twitter<http://twitter.com/AtomicData> | Facebook<http://www.facebook.com/AtomicDataCenters> | LinkedIn<http://www.linkedin.com/companies/atomic-data-centers> Safe. Simple. Smart. www.atomicdata.com<http://www.atomicdata.com/> From: Matthew Beckwell <matthewb(a)AITECH.NET<mailto:matthewb@AITECH.NET>> Reply-To: MICE Discuss <MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>> Date: Saturday, January 3, 2015 at 12:23 PM To: "MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>" <MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>> Subject: Re: [MICE-DISCUSS] Statistics reporting for MICE? I'm with Andrew on his suggestion of either a formalized or gentlemen's agreement for a "heads up" with these types of activities. We experienced at least a partial outage (i.e. UDP Packet Loss) over MICE between 13:38:47 and 13:40:02 on Friday. I know this activity wasn't supposed to be service impacting-- but accidents and unexpected things happen. A heads up would give conservative members the opportunity to re-route in a controlled manner (if they desire). My personal preference would be a 24 hour notice so I could take action the night before, but I'll take what I can get (even if it's only an hour). ~Matthew Matthew Beckwell - Director of Network Operations Advanced Integrated Technologies Technical Support: 1-800-300-5408 Office: 1-952-829-5511 x204 E-Mail: matthewb(a)aitech.net<mailto:matthewb@aitech.net> On Sat, Jan 3, 2015 at 8:01 AM, Andrew Hoyos <hoyosa(a)gmail.com<mailto:hoyosa@gmail.com>> wrote: I may have missed something, but I don't recall seeing any email chatter about this happening. Unsure what the normal ops/maintenance protocol is, but I'd say when doing stuff like below (module adds/swaps), at least a heads up to mice-discuss would be in order for the benefit of all the members. Or given the growth of MICE, perhaps it's time the steering committee should formalize something there. Thoughts from other folks? As far as the graphs, we should look at fixing the RRD files to remove that spike with the wacky/erroneous values so things look proper still. I'd be happy to help with that if anyone needs a hand. I think there may even be a Cacti plugin that does that, IIRC. -- Andrew Hoyos hoyosa(a)gmail.com<mailto:hoyosa@gmail.com> > On Jan 2, 2015, at 8:28 PM, Jeremy Lumby <jlumby(a)MNVOIP.COM<mailto:jlumby@MNVOIP.COM>> wrote: > > The huge Cacti traffic spike coincided with adding a 4 port fiber module to the 4200 switch. Juniper claimed it was hot swappable, however the issues were more than they eluded to. > > This came about since I donated some modules to hold MICE over until a more permanent hardware upgrade can be picked. The good news is the 4500 now has 4 additional SFP+ ports, and the 4200 now has 4 SFP ports. This will allow some of the members that are at 1G that needed a fiber handoff to be moved to the 4200 freeing up additional 10G ports in the 4500. > > -----Original Message----- > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET>] On Behalf Of Richard Laager > Sent: Friday, January 02, 2015 8:06 PM > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET<mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET> > Subject: Re: [MICE-DISCUSS] Statistics reporting for MICE? > > I was going to say that I thought we were doing exactly that at http://micemn.net but when I pulled up the website to verify, I see that something is very wrong with the graph. > > Did anyone change something in Cacti recently? > > -- > Richard > >> On Jan 2, 2015, at 7:10 PM, Hannigan, Martin <marty(a)AKAMAI.COM<mailto:marty@AKAMAI.COM>> wrote: >> >> >> >> FYI, >> >> http://micelg.usinternet.com/export/graph_385.html shows in+out where http://micelg.usinternet.com/export/graph_384.html shows in/out. Which one should we use? >> >> I'd like to suggest that MICE follow OIX-1 with respect to agg and other stats: >> >> "The IXP MUST publish on a publicly available website the total sum of >> all incoming and outgoing traffic in bps from all connected networks >> on the public peering VLAN. The traffic sum MUST include the traffic on customer facing ports only and MUST be made up of 5 min average traffic measurements. A distinction MUST be made between the traffic on the public peering VLAN and any other interconnection service." >> >> Traffic "massiveness" isn't as important as how many ASNs are connected. Traffic is an unpredictable and unreliable indicator of an exchanges size and value. ASN counts are much more granular for potential peers to build a case to join. >> >> >> Best, >> >> -M< >> >> >> >> >> ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Jan. 4, 2015

Re: Statistics reporting for MICE?

by Hannigan, Martin

> On Jan 3, 2015, at 21:12, David Farmer <farmer(a)UMN.EDU> wrote: > > On Jan 3, 2015, at 16:34, Hannigan, Martin <marty(a)AKAMAI.COM> wrote: >>>> On Jan 3, 2015, at 14:17, Steve Howard <showard(a)PAULBUNYAN.NET> wrote: >>>> On 01/02/2015 07:10 PM, Hannigan, Martin wrote: >>>> FYI, >>>> >>>> http://micelg.usinternet.com/export/graph_385.html shows in+out where http://micelg.usinternet.com/export/graph_384.html shows in/out. Which one should we use? >>>> >>>> I'd like to suggest that MICE follow OIX-1 with respect to agg and other stats: >>>> >>>> "The IXP MUST publish on a publicly available website the total sum of all incoming and outgoing traffic in bps from all connected networks on the public peering VLAN. The traffic sum MUST include the traffic on customer facing ports only and MUST be made up of 5 min average traffic >>>> measurements. A distinction MUST be made between the traffic on the public peering VLAN and >>>> any other interconnection service." >>>> >>>> Traffic "massiveness" isn't as important as how many ASNs are connected. Traffic is an unpredictable and unreliable indicator of an exchanges size and value. ASN counts are much more granular for potential peers to build a case to join. >>> >>> I think that each potential peer determines the value of an exchange >>> based upon their situation and business dynamics. For providers like us >>> that mainly serve "eyeball" customers, traffic "massiveness" is probably >>> the most important value indicator. Generally speaking, if my cost/bit >>> is cheaper or higher quality at an exchange than a transit provider, >>> then the more "massive" the better! To the overwhelming majority of our >>> members/customers it doesn't matter whether the traffic comes from one >>> ASN or a thousand ASNs. >> >> Agreed. Aside from mass of traffic and ASNs, a good measure of success (for me) is creation of PNIs. That requires traffic + ASN + good xcon costs (like 0). > > Just so the guys that need to make the graphs know what they are being asked for; are you asking for peer ASNs or origin ASNs reachable from the exchange? Or, maybe both now that I think of it. > > Happy 2015!! Twasn't me, but I think it was route count and AS count 5m/day/week/year or whatever we do. Long term, AS churn would be great too. Stagnation detection is useful. Best, -M<

Jan. 4, 2015

Re: Statistics reporting for MICE?

by David Farmer

On Jan 3, 2015, at 16:34, Hannigan, Martin <marty(a)AKAMAI.COM> wrote: >> On Jan 3, 2015, at 14:17, Steve Howard <showard(a)PAULBUNYAN.NET> wrote: >>> On 01/02/2015 07:10 PM, Hannigan, Martin wrote: >>> FYI, >>> >>> http://micelg.usinternet.com/export/graph_385.html shows in+out where http://micelg.usinternet.com/export/graph_384.html shows in/out. Which one should we use? >>> >>> I'd like to suggest that MICE follow OIX-1 with respect to agg and other stats: >>> >>> "The IXP MUST publish on a publicly available website the total sum of all incoming and outgoing traffic in bps from all connected networks on the public peering VLAN. The traffic sum MUST include the traffic on customer facing ports only and MUST be made up of 5 min average traffic >>> measurements. A distinction MUST be made between the traffic on the public peering VLAN and >>> any other interconnection service." >>> >>> Traffic "massiveness" isn't as important as how many ASNs are connected. Traffic is an unpredictable and unreliable indicator of an exchanges size and value. ASN counts are much more granular for potential peers to build a case to join. >> >> I think that each potential peer determines the value of an exchange >> based upon their situation and business dynamics. For providers like us >> that mainly serve "eyeball" customers, traffic "massiveness" is probably >> the most important value indicator. Generally speaking, if my cost/bit >> is cheaper or higher quality at an exchange than a transit provider, >> then the more "massive" the better! To the overwhelming majority of our >> members/customers it doesn't matter whether the traffic comes from one >> ASN or a thousand ASNs. > > Agreed. Aside from mass of traffic and ASNs, a good measure of success (for me) is creation of PNIs. That requires traffic + ASN + good xcon costs (like 0). Just so the guys that need to make the graphs know what they are being asked for; are you asking for peer ASNs or origin ASNs reachable from the exchange? Or, maybe both now that I think of it. Happy 2015!!! -- =============================================== 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 ===============================================

Jan. 4, 2015

Re: Statistics reporting for MICE?

by Hannigan, Martin

> On Jan 3, 2015, at 14:17, Steve Howard <showard(a)PAULBUNYAN.NET> wrote: > >> On 01/02/2015 07:10 PM, Hannigan, Martin wrote: >> FYI, >> >> http://micelg.usinternet.com/export/graph_385.html shows in+out where http://micelg.usinternet.com/export/graph_384.html shows in/out. Which one should we use? >> >> I'd like to suggest that MICE follow OIX-1 with respect to agg and other stats: >> >> "The IXP MUST publish on a publicly available website the total sum of all incoming and outgoing traffic in bps from all connected networks on the public peering VLAN. The traffic sum MUST include the traffic on customer facing ports only and MUST be made up of 5 min average traffic >> measurements. A distinction MUST be made between the traffic on the public peering VLAN and >> any other interconnection service." >> >> Traffic "massiveness" isn't as important as how many ASNs are connected. Traffic is an unpredictable and unreliable indicator of an exchanges size and value. ASN counts are much more granular for potential peers to build a case to join. > > I think that each potential peer determines the value of an exchange > based upon their situation and business dynamics. For providers like us > that mainly serve "eyeball" customers, traffic "massiveness" is probably > the most important value indicator. Generally speaking, if my cost/bit > is cheaper or higher quality at an exchange than a transit provider, > then the more "massive" the better! To the overwhelming majority of our > members/customers it doesn't matter whether the traffic comes from one > ASN or a thousand ASNs. > Agreed. Aside from mass of traffic and ASNs, a good measure of success (for me) is creation of PNIs. That requires traffic + ASN + good xcon costs (like 0). > I'd like to see us consider including ASN count and total > routes/netblocks on the MICE website. I don't know how much "real > world" value there is with the route/netblock count, but it looks nice > for marketing purposes! > > We currently see 44 ASNs and ~62,700 netblocks at MICE. I think that > these are great numbers for a relatively new exchange. > > Steve It's definitely a good start. And now with the other data centers being more visible, competitive places to do PNis too. Great stuff. Best, Martin

Jan. 3, 2015