- NANOG - lists.nanog.org

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it
by Brandon Butterworth 26 Jan '16

26 Jan '16

> From mark.tinka(a)seacom.mu Mon Jan 25 19:56:46 2016 > > On 25/Jan/16 21:28, Brandon Butterworth wrote: > > It is but nobody worries about that, we trust route servers at IX > > carrying way more traffic than most of these access circuits. > > Yes, but if those go belly-up, you have another exchange point to fall > back to, a bi-lateral peering session, or an upstream provider. Or all > three. Doesn't matter, if traffic is blackholed at an ix then it won't be failing over to another one. Same effect > A "critical" device falling over in my network is far worse prospect to > experience. The general case doesn't care about your network, it assumes you'd engineer that appropriately for the criticality and do something different/better if you need to. brandon

3 2

RIP Marvin Minsky
by Jay Ashworth 26 Jan '16

26 Jan '16

Lauren Weinstein passes along that AI pioneer Minsky died Sunday night in New York. He was 88. Condolences to those who knew him. http://www.nytimes.com/2016/01/26/business/marvin-minsky-pioneer-in-artific… -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

1 0

OT: ID/RFC formatting
by Jay R. Ashworth 25 Jan '16

25 Jan '16

I know we have to have a few people on here who've written technical RFCs (as opposed to 1 April ones like my RFC 2100)... Any tips on 1) how to do inline boldface and 2) what to do with ASCIIart illustrations that are too wide for the page? I'm using Stefan Santteson's nroffEdit (since I'm presently stuck on Windows), but it doesn't seem to like .B/.R or \fB / \fP for the former, and on the latter point, it's simple unclear how I should approach the thing (a four-column time-sequence diagram of a network transaction, similar to that of the four-point SIP call. Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

3 2

Call for presentations RIPE 72
by Benno Overeinder 25 Jan '16

25 Jan '16

Dear colleagues, Please find the CFP for RIPE 72 below or at https://ripe72.ripe.net/submit-topic/cfp/. The deadline for submissions is 13 March 2016. Please also note that speakers do not receive any extra reduction or funding towards the meeting fee at the RIPE Meetings. Kind regards, Benno Overeinder RIPE PC Chair https://www.ripe.net/participate/meetings/ripe-meetings/pc -------------------->>><<<-------------------- Call for Presentations A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. RIPE 72 will take place from 23-27 May 2016 in Copenhagen, Denmark. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the plenary sessions, BoFs (Birds of a Feather sessions), panels, workshops, tutorials and lightning talks at RIPE 72. See the full descriptions of the different presentation formats, https://ripe72.ripe.net/submit-topic/presentation-formats/. Proposals for plenary sessions, BoFs, panels, workshops and tutorials must be submitted for full consideration no later than 13 March 2016. Proposals submitted after this date will be considered depending on the remaining available space in the programme. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: - IPv6 deployment - Managing IPv4 scarcity in operations - Commercial transactions of IPv4 addresses - Data centre technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange Submissions RIPE Meeting attendees are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. Presenters should indicate how much time they will require. In general, the time allocated for the different presentation formats is as follows: - Plenary presentations: 20-25 minutes presentation with 5-10 minutes discussion - Tutorials: up to two hours (Monday morning) - Workshops: one hour (during evening sessions) to two hours (Monday morning) - BoFs: approximately one hour - Lightning talks: 10 minutes The following general requirements apply: - Proposals must be submitted using the meeting submission system, https://ripe72.ripe.net/submit-topic/submission-form/. - Lightning talks should also be submitted using the meeting submission system (https://ripe72.ripe.net/submit-topic/submission-form/) and can be submitted any time up to and including the meeting week. The allocation of lightning talks will be announced on short notice---in some cases on the same day but often one day prior to the time slot allocated. - Presenters who propose a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. - All presentation proposals will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For panels, proposals must contain a clear description, as well as the names of invited panellists, presenters and moderators. - Due to potential technical issues, presenters/panellists should be physically present at the RIPE Meeting. If you have any questions or requests concerning content submissions, please email pc [at] ripe [dot] net. -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/

1 0

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it
by Scott Weeks 25 Jan '16

25 Jan '16

--- nick(a)foobar.org wrote: multihop bgp means that you don't have synchronised ethernet carrier status between the provider and customer routers. This in turn means that if there's an intermediate connectivity problem, bgp will need to time out before it notices and reroutes. During this period, traffic will be black-holed. This is a crock. ------------------------------------------- Unless BFD is able to be used. https://en.wikipedia.org/wiki/Bidirectional_Forwarding_Detection scott

2 1

Equinix 350 E. Cermak
by Mike Hammett 25 Jan '16

25 Jan '16

Do any of you have excess space within Equinix at 350 E. Cermak? It needs to be both of those due to the number of cross connects to other players within Equinix 350 E. Cermak. Equinix direct is pricing full cabs at a ridiculous price. Given that we need 1/4 cab or less, it's hard to justify the full thing at those rates. Every time we think we've got someone lined up, their space is actually Equinix out in Elk Grove or 350 E. Cermak, but in TelX or Steadfast instead. I see a lot of partially filled cabinets when I walk through to our existing space. Come on now.... ;-) ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com

2 2

Cisco CMTS SNMP OID's
by Lorell Hathcock 24 Jan '16

24 Jan '16

All: Does anyone out there have some valuable OID's for a Cisco CMTS? The ones I am looking for are: Signal to Noise per upstream channel Cable Modem counts of all kinds connected / online ranging offline I opened a ticket through Cisco's help desk. I have a SmartNET contract for the unit, but they were not very helpful. The OIDs they suggested did not yield any useful data. ("0" when I know there are CMs connected, etc). Thanks in advance. Lorell Hathcock

7 7

Re: RADb Outage?
by Larry J. Blunk 24 Jan '16

24 Jan '16

Service for the RADb whois protocol has now been restored. We were experiencing extensive DDOS activity directed at the whois service host(s). Regards, Larry Blunk Merit

8 7

St. Louis Region - SCIX-STL Internet Exchange Update
by David Sandel 23 Jan '16

23 Jan '16

Good afternoon, Thank you for attending SCIX-STL Design Review meeting Friday at the T-REX !! *RECAP:* A quick recap of our Smart City Internet Exchange - STL meeting: a). Fabric # 1 will be used for service provider and data center peering. b). Fabric #2 will be used for Smart City services, sensor networks, IoE, advanced security services, innovation districts and neighborhoods. c). SCIX-STL will have several Root nameservers, approximately 300 Top Level Domain nameservers, and other standard services for the exchange *NEXT STEPS:* We are also looking for other participants or IX initiatives to join the exchange. If you, or another interested interested party would be interested to join please feel free to respond to this message. As of yesterday, we have two letters of intent in hand and several more on the way. We would also like to thank Bill Woodcock from PCH who did a great job of walking us through the issues related to the history, design, operation, maintenance and governance issues central to the success of IX's around the globe. Thank again Bill ! *THANKS TO ALL:* We look forward with great anticipation to this landmark achievement in networking the midwest and realizing the economic, social, and entrepreneurial benefits that this will bring to the our region. Have a great weekend ! Dave -- David Sandel iPhone 314-435-3658 Fax 800-640-8643 Twitter @dsandel @ Loopmediahub President Sandel & Associates LLC <http://www.sandel-associates.com/> 6900 Delmar St. Louis, MO. 63130 *The Loop Media Hub <http://loopmediahub.org>* My LinkedIn Profile <http://linkedin.com/in/smartcitymasterplanner>

1 0

Re: The IPv6 Travesty that is Cogent's refusal to peer Hurricane Electric - and how to solve it
by Brandon Butterworth 23 Jan '16

23 Jan '16

> > On Jan 21, 2016, at 1:07 PM, Matthew D. Hardeman <mhardeman(a)ipifony.com> wrote: > > Since Cogent is clearly the bad actor here (the burden being > > Cogent's to prove otherwise because HE is publicly on record as saying > > that theyd love to peer with Cogent) I'd like to peer with all tier 1's, they are thus all bad as they won't. HE decided they want to be transit free for v6 and set out on a campaign of providing free tunnels/transit/peering to establish this. Cogent, for all their faults, are free to not accept the offer. Can the Cogent bashing stop now, save it for when they do something properly bad. brandon

12 17