Re: Mellanox 100GE switches

[Scott Larson]

 Have these even hit the channel? We have their previous gen 40/56G
gear deployed which has worked really well so I've been interested in the
100G since the announcement last year but the vendors I'd typically be
buying from have only relayed that they're not currently able to get one
into my hands. They don't even show up in the Mellanox store.


*[image: userimage]Scott Larson[image: los angeles]
Lead
Systems Administrator[image: wdlogo]  [image:
linkedin]  [image: facebook]
 [image: twitter]
 [image: instagram]
T 310 823 8238 x1106
<310%20823%208238%20x1106>  |  M 310 904 8818 <310%20904%208818>*

On Mon, Feb 15, 2016 at 2:06 PM, Jay Hanke  wrote:

> Does anyone have experiences they can share regarding the Mellanox
> 100GE Ethernet switches?
>
> Thanks!
>
> Jay
>

Call for Presentations - CHI-NOG 06 (May 12th)

[Tom Kacprzynski]

*Call for Presentations*

CHI-NOG 06 - (Chicago Network Operators Group)

May 12th 2016, Chicago, IL

The Chicago Network Operators Group (CHI-NOG) is a vendor neutral
organization. Our goal is to create a regional community of network
professionals by presenting the latest technology trends, enabling
collaboration and providing networking opportunities. CHI-NOG will be
hosting its sixth annual conference May 12th, 2016 in downtown Chicago. For
more information please see http://chinog.org.

The CHI-NOG Program Committee is seeking proposals for presentations on
relevant networking technologies with a focus on the following topics:

* Network Automation/ DevOps

* Interconnection/Peering/Cloud Exchanges

* Low Latency Networks/Financial Networks

* Network Security

* Internet Monitoring

* Advanced BGP/MPLS Technologies

* Software Defined Networking

* Cloud Networking Technologies

* Network Operation

* Academic Research in Networking and Related Infrastructure Fields

* Open Source Networking Tools

* Optical Networking/Data Center Interconnect

* Data Center Fabric

* Wireless

* IPv6


*Session Format*

Each presentation is 30 minutes, which includes a questions and answers.
The duration can be extended per individual request to 60 minutes and will
be considered by the program committee. Presentations should not contain
any marketing material and should avoid discussion of commercial products
but rather focus on the underlying technology.


*Key Dates*

* Presentation Abstract Submission Deadline ---  3/15/16

* Abstract Selection 
  3/18/16

* Presentation Full Slides Submission Deadline - 4/15/16

* Final Selection -
 4/29/16

* Conference -
 5/12/16


*Submission*

Please submit presentation’s abstract proposal by filling out the
submission form  at
http://chinog.org/meetings/chi-nog-06/abstract-submission/ . Once your
presentation is selected please provide the program committee with your
photo and a short bio for web publication. All accepted speakers will
receive complimentary tickets to the conference.

The program committee is looking forward to your submission and attendance
at the conference.

Re: PCH Peering Paper

[Patrick W. Gilmore]

On Feb 16, 2016, at 9:49 AM, Livingood, Jason  
wrote:
> On 2/12/16, 8:56 PM, "NANOG on behalf of Niels Bakker"
>  wrote:
>> * bedard.p...@gmail.com (Phil Bedard) [Sat 13 Feb 2016, 01:40 CET]:
>>> I was going to ask the same thing, since even for settlement free
>>> peering between large content providers and eyeball networks there
>>> are written agreements in place.  I would have no clue on the volume
>>> percentage but it's not going to be near 99%.
>> 
>> It's much closer to 99% than to 50%, though.
> 
> Any reference on that? I¹m wondering who (if anyone) is formally measuring
> / tracking this and seeing the exact trend over time.

Niels is in a position to know what his network does. You are in a position to 
know what your network does.

My guess is Comcast requires a contract with everyone, meaning your peering 
bits are mostly (all?) contracted.

I know Akamai does not require a contract, and will only sign if the other side 
requires it. (This is not a secret.) My guess is they have a lot more 
un-contracted peering bits than Comcast.

However, let’s look at the basic premise here. A handful of networks (50? 100? 
200?) on the Internet require contracts with everyone. And if we are being 
honest with each other, about 5 of those are legacy “backbone” networks which 
have not been purchased by a broadband network. The rest are broadband networks 
guarding their monopoly positions. (Interestingly, broadband networks without 
monopoly positions to guard do not require contracts.)

The other many 1000s of networks do not require contracts to peer.

The premise above therefore devolves to: Since most of the traffic is to those 
networks, then most of the bits flow over contracted peerings.

Perhaps “most” can be argued, but obviously a significant portion of all 
peering bits flow over contracted sessions. Hopefully we can all agree on that.

And let’s also agree there are reasons to have contracts. Peering can require a 
great deal of time, effort, and money. Peering can require contracts with 
transport providers, equipment suppliers, colocation facilities, etc. I’m not 
saying everyone should have a contract for everything. I’m just saying there 
are good and valid reasons for them, at least sometimes.


But saying “most bits flow over contracts” is not the end of the story.

First, look at the three content “networks” with the most traffic - Google, 
Netflix, Akamai. All will peer without contracts. All peer at IXes. In fact, 
all are happy to exchange traffic without even an email to the other network 
(i.e. route-server peerings). Since these three networks are some of the 
largest (the largest?) on the planet, it is clear that volume alone does not 
create the requirement for a contract.

Also, let’s take the bottom 10K peering networks. They will not get peering 
with Comcast, DT, CT, Telstra, FT, etc. Meaning pretty much all their peering 
bits are over un-contracted sessions. The rest is transit.

I guess you could say the bits sent over transit will eventually hit a 
contracted peering session, since the people in the core contract their 
sessions. But does that matter to the small guys?


In summary, lots of bits flow over contracted peering sessions. But more 
sessions are not contracted. And lots of bits flow over those non-contracted 
sessions.

Going back to my original post, I was trying to show there are plenty of jobs 
for peering people who will rarely or even never sign a contract. Plus this is 
a great place to learn things like capacity planning, BGP, and other 
technologies required to do peering well. If you are good, you can learn the 
commercial underpinnings of peering.

Then if you are lucky enough to score a job with a legacy “tier one” which 
still thinks it is relevant, or a monopolistic broadband company, you can learn 
contracts after the fact. :)

-- 
TTFN,
patrick

Re: PCH Peering Paper

[Livingood, Jason]

On 2/12/16, 8:56 PM, "NANOG on behalf of Niels Bakker"
 wrote:


>* bedard.p...@gmail.com (Phil Bedard) [Sat 13 Feb 2016, 01:40 CET]:
>>I was going to ask the same thing, since even for settlement free
>>peering between large content providers and eyeball networks there
>>are written agreements in place.  I would have no clue on the volume
>>percentage but it's not going to be near 99%.
>
>It's much closer to 99% than to 50%, though.

Any reference on that? I¹m wondering who (if anyone) is formally measuring
/ tracking this and seeing the exact trend over time.

Thanks
Jason

Re: Automated alarm notification

[Eitan Adler]

On 11 February 2016 at 13:51, Frank Bulk  wrote:
> Is anyone aware of software, or perhaps a service, that will take SNMP
> traps, properly parse them, and perform the appropriate call outs based on
> certain content, after waiting 5 or 10 minutes for any alarms that don't
> clear?
>
> I looked at PagerDuty, but they don't do any SNMP trap parsing, and nothing
> with set/clear.

https://github.com/dropbox/trapperkeeper ?



-- 
Eitan Adler