SAFNOG-3: Conference Report

[Mark Tinka]

Hello all.

With the SAFNOG-3 event - recently held in Durban, South Africa - just
concluded, the SAFNOG-3 MC (Management Committee) would like to extend
its gratitude and appreciation to all the delegates, speakers, sponsors,
partners and iWeek, for your support in producing yet another successful
SAFNOG conference.

SAFNOG-3 recorded 172 registered participants, with 160 shows in Durban.
Furthermore, we attracted 1,009 unique views via the live stream
throughout the 2-day conference.

Each of the presentations that were given during the meeting are now
available online to download at:

http://www.safnog.org/#section-agenda

Videos of each of the presentations are catalogued and available on the
SAFNOG Youtube channel at:

https://www.youtube.com/channel/UCLRItGb8Y2HXIu_EUdp3Sag/playlists

High-resolution photographs of both conference days as well as the
exhibition room, closing social dinner and whisky BoF are also all
available at:

http://www.safnog.org/

For those who attended the meeting (remotely or in-person), we welcome
your feedback to help us understand what worked, what didn't, what you'd
like to see for the next meeting(s), and how we can improve. Kindly
spend some time completing the online survey for this at:

https://www.surveymonkey.com/r/G2QGX5D

SAFNOG now moves back into its normal schedule of April, with the
upcoming SAFNOG-4 meeting. Details about this event will be shared on
our mailing list and with the wider community in the coming weeks.

We look forward to seeing you all (again) in April, 2018.

Cheers,

Mark Tinka
On Behalf of the SAFNOG Management Committee

Re: BGP Optimizers (Was: Validating possible BGP MITM attack)

[Colin Petrie]

On 31/08/17 22:06, Job Snijders wrote:> I strongly recommend to turn off
those BGP optimizers, glue the ports
> shut, burn the hardware, and salt the grounds on which the BGP optimizer
> sales people walked.

Yes.

> p.s. providing a publicly available BGP looking glasses will contribute
> to proving your innocence in cases like these. Since in many cases the
> AS_PATH is a complete fabrication, we need to manually check every AS in
> the AS_PATH to see whether the AS carries the fake more-specific. A
> public looking glass speeds up this fault-finding process. If you don't
> want to host a webinterface yourself, please consider sending a BGP feed
> to the Route Views Project or RIPE RIS, or for something queryable in a
> real-time fashion the NLNOG RING Looking Glass http://lg.ring.nlnog.net/

As a RIPE RIS operator, we regularly get people complaining 'oh but we
are not advertising that prefix, your system must be broken'.

Usually it is one of these BGP-optimizer more-specifics leaking out.

Cheers,
Colin

Join RIPE NCC Hackathon Version 6, 4-5 November, Copenhagen, Denmark

[Mirjam Kuehne]

Dear colleagues,

The sixth RIPE NCC hackathon will take place on Saturday and Sunday, 4-5
November 2017 in Copenhagen, Denmark. The topic is: IPv6!

We're looking for creative thinkers: front-end developers, UI designers,
network operators, researchers, hackers and other enthusiastic coders,
to help us develop new tools that would enable deployment of IPv6 and
visualizations based on IPv6 measurements data.

All source code developed during the hackathon will be publicly licensed
and available on GitHub, and will be free for the entire community to use.


How to Apply


Interested? Learn more and apply online today!

https://atlas.ripe.net/hackathon/version6/#!application-form

*The application deadline is 9 September.*

We look forward to seeing you there!

Find out more in this RIPE Labs article:

https://labs.ripe.net/Members/becha/join-the-ripe-ncc-hackathon-version-6

Regards,
Vesna Manojlovic & Mirjam Kuhne
Community Building
RIPE NCC

100G QSFP28 DAC cables - experience

[Jiri Prochazka]

Hi folks,

I'm wondering if anyone have (either positive or negative) experience 
with 100G QSFP28 DAC cables?


Is there anyone who is using 100G DAC in large scale and would recommend 
it (which means there are no issues compared to SR4 links)?


I'm thinking about cables with lenght up to 1m, not more.

We have had quite bad experience with 10G DAC in the past - but I do not 
want to be slave of the past.





Thank you for your thoughts!



Jiri

RE: Management softwares

[Jacob Kukuk]

Splynx is what weuse, it handles billing customer service, provisioning, ect. 
https://splynx.com

On Sep 1, 2017 11:42 AM, "Jameson, Daniel"  
wrote:
Give this a look;  the webpage doesn't do it justice.  It Doesn't do 
billing/invoicing,  but does everything else on your list.

http://www.crestpt.com/fme-platforms.html

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of K MEKKAOUI
Sent: Friday, September 01, 2017 12:56 AM
To: nanog@nanog.org
Subject: Management softwares

Hi



We are a medium ISP. We are looking for Management software solutions. We are 
interested in finding a solution for billing, invoicing, scheduling, ticketing, 
provisioning and monitoring, Any suggestions or recommendations will be 
appreciated? We have been using multiple systems which do not communicate. Our 
objective is to use a single system or at least reduce the number of systems.



Thank you



KARIM M.

Re: Moving fibre trunks: interruptions?

[Jared Mauch]

Pretty much. Here is an example of permitting requirements for underground. 
Underground costs 5-12/foot (or more in urban areas) whereas aerial can be as 
low as $2/foot. 



Jared Mauch

> On Sep 1, 2017, at 6:38 PM, Ricky Beam  wrote:
> 
>> On Fri, 01 Sep 2017 15:52:40 -0400, Rod Beck 
>>  wrote:
>> I don't think there is virtually any aerial in Europe. So given the cost 
>> difference why is virtually all fiber buried on this side of the Atlantic?
> 
> Aerial is simple and fast... pull the cable through a stringer, move to the 
> next pole and repeat; when a section (about a mile) is done, it's hoisted 
> into the air and tied to the pole. The stringers are then moved to the next 
> mile of poles and the process repeats.
> 
> Buried stuff requires a great deal of planning, permitting, and insurance. 
> You have to know everything that's ever been stuffed in the ground within 
> half a mile of where you're working to avoid the inevitable cutting of 
> something important -- gas, water, sewer, power, other telcom, even vacuum 
> tube lines and subways. And then you need trenching gear to get stuff in the 
> ground, and crews to come along behind to remediate the "environmental 
> damage".
> 
> (Once the conduit is in the ground, it's a trivial matter to blow whatever 
> you need through it.)

RE: Northeast TWC/Spectrum contact?

[Jerry Cloe]

I doubt you're going to get a reply, but I will add this. Signal levels in that 
range are undoubtedly a local issue. Its either your drop, one of your 
splitters, or the tap on the pole. First thing I'd do is check with a neighbor 
thats on the same run and see what they say. That will pretty much confirm its 
something very local to you. Nex thing I'd do (if you're just refusing to call 
the cable company) is plug your modem straight into the ground block. That 
would eliminate your house wiring and your splitters.

 
If those signals were the same across the city, for all purposes, they are 
down. Almost everything is two-way, tv, phone, and of course 'net. There's no 
way they have a wide outage and don't know it. Customers may be soft on calling 
some issues, but that many, not a chance.


 
-Original message-
From:Edwin Pers 
Sent:Fri 09-01-2017 03:55 pm
Subject:Northeast TWC/Spectrum contact?
To:nanog@nanog.org; 
Hi
Can someone from TWC/Spectrum’s northeast division please contact me off list? 
AS11351 for what it’s worth

About a week ago my modem dropped from 24 bonded channels at about -6dBmV to 19 
channels ranging from -9.30 to -21.30dBmV, and I started seeing very high 
latency and packetloss. I’ve also been seeing a lot of Lost MDD’s and RCS 
Partial’s in my event log.

Haven’t put a tdr down the customer side cabling yet but I doubt that’s the 
issue, it’s only a 25’ run and a visual inspection doesn’t show anything out of 
the ordinary.

Sorry for spamming the list, but every time I’ve called TWC customer support 
lines in the past I’ve been transferred between 5-8 people who each told me to 
reboot my modem and check the cables.

Thanks for your time,
Ed Pers

Re: Moving fibre trunks: interruptions?

[Alan Buxey]

i'm sure theres plenty of aerial in europe. usually carried on e.g.
the top messenger cable on pylons   - given i've attended talks about
the issues of fixing such fibre after storms in Scotland :)

On 1 September 2017 at 20:52, Rod Beck  wrote:
> I don't think there is virtually any aerial in Europe. So given the cost 
> difference why is virtually all fiber buried on this side of the Atlantic?
>
>
> 
> From: NANOG  on behalf of Jared Mauch 
> 
> Sent: Friday, September 1, 2017 9:37 PM
> To: Michael Loftis
> Cc: Nanog@nanog.org
> Subject: Re: Moving fibre trunks: interruptions?
>
>
>
>> On Sep 1, 2017, at 3:32 PM, Michael Loftis  wrote:
>>
>> If it is in the railroad RoW they may be restricted to daylight working
>> only. Check with your provider or OSP crew.
>>
>
>
> Yup.  Railroad work is complex just because you have to coordinate with the 
> railroad owner and they have to be onsite for all work.  The cost of going 
> underground vs aerial is also astronomical in many cases.
>
> - Jared

Re: 2017 NANOG Elections General Information

[Robert Brockway]

On Tue, 5 Sep 2017, Dave Temkin wrote:


Hi NANOG Community,

Nominations are rapidly coming to a close - September 8th is the last day
to submit nominees.

Unfortunately, to follow up on my paragraph about diversity: So far, every
single candidate that has completed the nomination process is a white male.


What you're describing is a very coarse form of diversity based on 
physical characteristics.  A white man who has lived his entire life as a 
peasant in Ukraine may well have a very different outlook and life 
experience to a white man who grew up in Australia.  These two white men 
could bring quite diverse viewpoints to any situation even though they 
share some superficial characteristics.


I have always supported the most suitable candidates for any role, 
irrespective of their physical characteristics.  I will always continue to 
do so.


Rob

Re: Hurricane Irma: U.S. Virgin Islands and Puerto Rico

[Mehmet Akcin]

I have talked(briefly sms/fb) to several friends of mine who operate
critical datacenter infrastructure. What is not shot down mostlly on diesel
generators but actual impact if power isnt restored in next 5-7 days is yet
to come.

USVI and Puerto Rico will get the restoration it needs in critical
infrastrucure, no doubt I am more concerned about othet caribbean who were
impacted.

Having lived in Caribbean for years and been on many islands, i can only
imagine recovery Of services on smaller islands taking long time.

There is an effort by Martin hannigan announced on twitter and a
coordination call. Martin is active member of NANOG, Martin how can we
support/join this great initivative?



On Sat, Sep 9, 2017 at 7:03 PM Sean Donelan  wrote:

>
> 5 fatalities in U.S. Virgin Islands and Puerto Rico
>
> FCC doesn't have reliable reporting on Wireline and Cable service
> providers in either USVI or Puerto Rico.  The assumption is large numbers
> of customers are without cable or wireline service.
>
> 870,000 customers (55% of the island) without power in Puerto Rico
>
> 22,900 customers without power U.S. Vigin Islands
>
> 1 hospital closed, 25 hospitals on backup generators
>
> 29.3% of cell sites in Puerto Rico and 60.7% of cell sites in the U.S.
> Virgin Islands are out of service.
>
> 1 radio station and 2 TV stations in USVI are out of service
>
> 4 radio stations in Puerto Rico are out of service
>

Re: Internet access for security consultants - pen tests, attack traffic, bulk e-mail, etc.

[Andrew Kerr]

I work for a MSSP (Managed Security Services Provider) that provides some
of these services including vulnerability scanning and such.  If it's a
legitimate provider doing work for customers, you should never get a
complaint about their activities.  Before we do any kind of scan, we have a
contract in place with the customer and include the IP(s) we'll be scanning
from and the range of IPs we'll be scanning (assuming this is an external
scan).  If they're not getting permission from customers first, they are
almost certainly breaking laws by scanning systems they don't have
permission to, and I wouldn't host them.

Assuming  you have a legal department, just make sure that you put
something that says this type of activity will only be permitted when the
target has agreed to the scan in advance.  If you get some complaints,
investigate, and if they're breaking the contract, turf them.


On Mon, 11 Sep 2017 at 16:01 james machado  wrote:

> On Mon, Sep 11, 2017 at 3:40 PM, Sean Pedersen 
> wrote:
>
> > We were recently approached by a company that does security consulting.
> > Some
> > of the functions they perform include discovery scans, penetration
> testing,
> > bulk e-mail generation (phishing, malware, etc.), hosting fake botnets -
> > basically, they'd be generating a lot of bad network traffic. Targeted at
> > specific clients/customers, but still bad. As an ISP, this is new
> territory
> > for us and there are some concerns about potential impact, abuse reports,
> > reputation, authorization to perform such tests, etc.
> >
> >
> >
> > Does anyone have experience in this area that would be willing to offer
> > advice?
> >
> >
> > From a customer point of view:
>
> We have written agreements with our vendors on who they can and can not
> send this traffic from, where exactly it is coming from and what type of
> traffic it will be.  One reason our vendor does this is to not get on black
> hole/spam lists or to cause their ISP issues, as well as having proof that
> they are allowed to send specific traffic to specific addresses for a
> specific time period.  The test managers then know what to expect and to
> head off abuse notifications after detection of the specific traffic.  We,
> also, use this traffic to test other vendors we might have and only after
> detection we will have white lists or black lists put in place as
> warranted.
>
> I would expect the company in question to be able to provide documentation
> that could track any specific traffic back to an engagement that has the
> approval of their customer.  If they have been around for a bit they should
> have a track record and may have current IP space that could be vetted to
> see what condition it is in.  Are they leaving it or adding too it.  If
> they are leaving their current space then find out why.
>
> James
>

RE: Protocol 17 floods from Vietnam & Mexico?

[Matthew Smee]

Protocol 17 likely refers to UDP.

https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers


-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Large Hadron Collider
Sent: Wednesday, 13 September 2017 11:08 AM
To: nanog@nanog.org
Subject: Protocol 17 floods from Vietnam & Mexico?

18:04:32.391082 IP 138-122-97-251.internet.static.ientc.mx >
umbrellix.net: ip-proto-17
18:04:32.391088 IP 138-122-97-251.internet.static.ientc.mx >
umbrellix.net: ip-proto-17
18:04:32.391110 IP 115.75.50.106.35180 > umbrellix.net.10454: UDP, bad length 
65500 > 1464
18:04:32.391145 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391152 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391158 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391164 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391170 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391176 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391182 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391188 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391194 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391199 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391205 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391211 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391217 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391223 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391229 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391234 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391248 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391255 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391261 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391266 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391272 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391278 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391284 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391289 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391295 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391313 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391319 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391325 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391331 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391336 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391342 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391348 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391354 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391367 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391374 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391379 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391385 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391391 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391396 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391402 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391408 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391414 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391420 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391426 IP 115.75.50.106 > umbrellix.net: ip-proto-17

Some stupidity has me wondering... protocol 17? Huh?


Is this some attempt to exploit me while at the same time flooding me at over 
800Mbit/s?


Needless to say, I've shut my computer down to avoid going over my data 
allowance.

Re: Getting an RADB entry removed that was added by a previous peer

[João Butzke]

You tried the contact on the whois database?

route:  129.77.0.0/16
descr:  NYC-OTA LIMITED PARTNERSHIP-AS14607 (added by MAINT-AS6517)
origin: AS6517
remarks:    -
remarks:    - This route object was registered by   -
remarks:    - Reliance Globalcom Services, Inc  MAINT-AS6517 -
remarks:    - on behalf of their customer:  -
remarks:    - NYC-OTA LIMITED PARTNERSHIP-AS14607 NYC   -
remarks:    -
notify: *n...@relianceglobalcom.com*
mnt-by: MAINT-AS6517
changed: *j...@relianceglobalcom.com* 20091117
source: RADB

Best Regards, João Butzke.
Em 13/09/2017 08:05, Matthew Huff escreveu:

It appears that Reliance Globalcom  (AS6157) added an RADB entry for our prefix 
(129.77.0.0/16) when we were a peer of theirs years ago, and it was never 
removed when we ended the relationship. We are ASN 14607.

I've reached out to their support, but does anyone have a suggestion on how I 
could get this cleaned up if they don't respond?

IPv6 migration steps for mid-scale isp

[Fredrik Sallinen]

Hello,

Recently we have decided to start IPv6 migration in our network. We
have ~1K BNGs and connecting our customers to network using PPPoE.
I'd be interested in hearing from the technical community about their
experiences and recommendations on this process. I'm wondering:

Shall I go for IPv6-only deployment or dual stack?
Where to start with IPv6? (core, edge or ...)
What are the best practices for ISPs?
What are the costs and return on investment?
How to identify address CPE and legacy application issues?

Fredrik

Re: Verizon issues | Looking glass

[Tim Evens (tievens)]

Attached shows the history for Verizon from all routeviews routers/collectors 
from 9/11 00:00:00 till 9/14 03:10 UTC. 

You can see this at: 

http://demo-rv.snas.io:3000/dashboard/db/top-asns?orgId=2&var-asn_num=701&from=150517440&to=1505358900971


Grafana is for stats/analysis of the data. You can use 
http://demo-rv.snas.io:8000/#/looking-glass to browse the current RIB as well 
as history of RIB's.   The login is demo/snas. 

--Tim



On 9/13/17, 5:48 PM, "NANOG on behalf of Van Dyk, Donovan via NANOG" 
 wrote:

Hello,

Has anyone else been seeing issues today from routes being learnt through 
the Verizon network, AS 701?

Does anyone know if they have a looking glass? I can’t find one.

Thanks

--
Donovan Van Dyk
SOC Network Engineer
Fort Lauderdale, FL USA

[cid:image001.png@01D32CD1.73DBD490]
The information contained in this electronic mail transmission and its 
attachments may be privileged and confidential and protected from disclosure. 
If the reader of this message is not the intended recipient (or an individual 
responsible for delivery of the message to such person), you are strictly 
prohibited from copying, disseminating or distributing this communication. If 
you have received this communication in error, please notify the sender 
immediately and destroy all electronic, paper or other versions.

Re: 100G QSFP28 DAC cables - experience

[Hugo Slabbert]

On Wed 2017-Sep-06 09:17:39 +0200, Jiri Prochazka  wrote:


Hi folks,

I'm wondering if anyone have (either positive or negative) experience 
with 100G QSFP28 DAC cables?


Is there anyone who is using 100G DAC in large scale and would 
recommend it (which means there are no issues compared to SR4 links)?


I'm thinking about cables with lenght up to 1m, not more.

We have had quite bad experience with 10G DAC in the past - but I do 
not want to be slave of the past.


Thank you for your thoughts!

Jiri


We're deploying a decent chunk of 100G QSFP28 at the moment, but it's a mix 
of:


- a handful of 100G QSFP28 copper DACs for some switch peerlinks
- a bit >100x 100G QSFP28 AOC for interswitch links
- a lot more 100G QSFP28 -> 4x25G SFP28 copper breakouts

We're only a few weeks in at this point, so mileage may vary in the long 
run etc.


The copper peerlinks are mostly 1M with some 3M.  We've had no issues with 
them so far.


The AOC interswitch links vary more in length, but some of those are >10M 
(hence AOC rather than copper).  We've faced no issues with those.  
Granted, there is BGP with BFD running across those, so those should help 
in terms of liveness checks and such.


I mention that because where we _have_ had issues are on the 100G -> 4x25G 
copper breakouts.  Those are for 25G edge connectivity.  It's a decent 
sample size with a bit north of 600x 25G ports.  The trouble we've had 
there have been with some links showing link up on the switch and server 
side but actually failing to pass any traffic, so we need to stuff some >L1 
liveness checks on there to ensure those links are good while we sort out 
the root issue.  It is not yet clear if this is a cable fault, driver 
issue, or something firmware-ish on the NICs.


Also, fun fact: 25G only made its way into the 802.3ad bonding mode driver 
in the Linux kernel in March this year[1].


--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal

[1]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=19ddde1eeca1ee81f4add5e04da66055e09281ac


signature.asc
Description: Digital signature

Re: IPv6 migration steps for mid-scale isp

[Mikael Abrahamsson]

On Wed, 13 Sep 2017, Fredrik Sallinen wrote:


Hello,

Recently we have decided to start IPv6 migration in our network. We
have ~1K BNGs and connecting our customers to network using PPPoE.
I'd be interested in hearing from the technical community about their
experiences and recommendations on this process. I'm wondering:

Shall I go for IPv6-only deployment or dual stack?


For PPPoE with existing IPv4, go dual stack.


Where to start with IPv6? (core, edge or ...)


Core, peering, work outwards towards end users.


What are the best practices for ISPs?
What are the costs and return on investment?
How to identify address CPE and legacy application issues?


There is a lot written and presented about IPv6 deployment. People have 
been doing this in volume since around 2010, and if you search for IPv6 
deployment experience you'll find lots of presentations.


Some I found that seem relevant:

https://www.nanog.org/meetings/nanog51/presentations/Monday/aronson-pierantozzi-level3-ipv6.pdf
https://www.ietf.org/proceedings/54/slides/plenary-15.pdf
https://www.apnic.net/community/ipv6-program/ipv6-stories/
https://www.ipv6council.be/experiences-de-deploiements-ipv6/

If you prefer video form, there are lots of presentations from 
conferences, available on youtube as well.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Hurricane Irma: Florida, Puerto Rico and U.S. VI

[Dave Temkin]

Sean - I think I speak for all of us when I say thank you very much for
these updates! The concise nature of them is super helpful.

-Dave

On Wed, Sep 13, 2017 at 8:58 PM, Sean Donelan  wrote:

>
> Disclosure note: AT&T and Comcast public relations folks have been sending
> information about what they are doing for disaster recovery. I've included
> some of their information.
>
>
> From various official sources (FEMA, Dept. of Energy, FCC, NOAA, etc).
>
> Fatalities (FEMA)
>Georgia: 2
>Florida: 12
>South Carolina: 2
>Puerto Rico: 3
>U.S. Virgin Islands: 4
> Note: FEMA is slower than media reports about U.S. fatalities
>
> Non-US fatalities (AP/Reuters)
>Caribbean fatalities: Anguilla (4), Barbuda (1), British Virgin
>Islands (5), Cuba (10), French Territories (10), St. Maarten (4),
>Haiti (1)
>
> Electric Power (DOE)
>
> Florida: 3,568,499 customer outages (35% of total state customers)
> Georgia: 451,033 customer outages (11% of total state customers)
> South Carolina: 58,972 customer outages (2% of total state customers)
> North Carolina: 24,445 customer outages (<1% of total state customers)
> Puerto Rico: 117,244  customers (8% of total customers)
> U.S. Virgin Islands:
>   The airport and hospital are still energized. Besides a few smaller
>   areas, most customers on St. John and St. Thomas are without
>   power. Restoration efforts will continue as USVI WAPA works to get
>   critical facilities reenergized on the two islands.
>
>
> Water (FEMA)
>
>  U.S. Virgin Islands: 341,000 people without potable water
>  Puerto Rico: 61,980 people without potable water
>
>
> Public Safety
> Hospitals (FEMA)
> Florida: 11 closed, 204 healthcare facilities evacuated
> Puerto Rico: 1 closed, 6 on generator power
> U.S. VI: 1 closed and evacuated
>
> NOAA Weather Radio (NOAA)
> Florida: 6 out of 32 stations (18%) out of service
> Georgia: 7 out of 29 stations (24%) out of service
> U.S. VI: 1 out of 1 station (100%) out of service
>
> Public Safety Answering Points (9-1-1 centers) (FCC)
> Florida: 29 impacted (4 out of service, 9 partial service, 7
> re-routed with ALI, 8 re-routed without ALI)
> Georgia: 5 impacted (1 re-routed with ALI, 3 re-routed without ALI)
> U.S. VI: 2 impacted, without ALI/ANI
>
>
> Cable and Wireline systems (FCC)
>
> 1,040 switching centers (cable headends and central offices) out of
> service. Unknown how many are isolated, damaged or just without power.
>
> 8,190,407 subscribers out of service in Alabama, Florida and Georgia; not
> including Puerto Rico and U.S. Virgin Islands.
>
> According to Comcast: All comcast's miami-dade and broward facilities are
> on generator power. Comcast is deploy portable generators in neighborhoods
> to re-charge outside plant. Comcast has no network access beyond Marthon in
> the Florida Keys, but has crews ready when the area is accessible.
>
>
>
> Wireless Service (FCC)
>
>  Alabama: less 1% cell sites out of service
>  Florida: 18.1% cell sites out of service (3 counties over 50% OOS)
>  Georgia: 5.3% cell sites out of service
>  Puerto Rico: 10.1% cell sites out of service
>  U.S. VI: 55% cell sites out of service (St. John - 9 out of 10 OOS,
> St. Thomas 38 out of 57 OOS)
>
>
> According to AT&T: deployed 6 portable, satellite connected cell on trucks
> in the Florida Keys (Stock Island, Key West and Marathon and 2 satellite
> connected cell on trucks in Naples, Florida. The AT&T National Disaster
> Recovery Team has over 20 units deployed throughout Florida (don't know
> what that means, but sounded good).
>
>
>
> Broadcast (FCC)
>
> Television: 10 stations out of service
> Radio: 39 stations out of service
>
>
>
>

Re: 100G QSFP28 DAC cables - experience

[Tyler Conrad]

We're using a mix as well, some QSFP28 AOC, others DAC. One thing that you
need to keep in mind about the DACs is going to be the bend radius. These
things are girthy af, so make sure to either overestimate your runs
slightly, or buy one to test first.

On Thu, Sep 14, 2017 at 11:54 AM, Hugo Slabbert  wrote:

>
> On Wed 2017-Sep-06 09:17:39 +0200, Jiri Prochazka  wrote:
>
> Hi folks,
>>
>> I'm wondering if anyone have (either positive or negative) experience
>> with 100G QSFP28 DAC cables?
>>
>> Is there anyone who is using 100G DAC in large scale and would recommend
>> it (which means there are no issues compared to SR4 links)?
>>
>> I'm thinking about cables with lenght up to 1m, not more.
>>
>> We have had quite bad experience with 10G DAC in the past - but I do not
>> want to be slave of the past.
>>
>> Thank you for your thoughts!
>>
>> Jiri
>>
>
> We're deploying a decent chunk of 100G QSFP28 at the moment, but it's a
> mix of:
>
> - a handful of 100G QSFP28 copper DACs for some switch peerlinks
> - a bit >100x 100G QSFP28 AOC for interswitch links
> - a lot more 100G QSFP28 -> 4x25G SFP28 copper breakouts
>
> We're only a few weeks in at this point, so mileage may vary in the long
> run etc.
>
> The copper peerlinks are mostly 1M with some 3M.  We've had no issues with
> them so far.
>
> The AOC interswitch links vary more in length, but some of those are >10M
> (hence AOC rather than copper).  We've faced no issues with those.
> Granted, there is BGP with BFD running across those, so those should help
> in terms of liveness checks and such.
>
> I mention that because where we _have_ had issues are on the 100G -> 4x25G
> copper breakouts.  Those are for 25G edge connectivity.  It's a decent
> sample size with a bit north of 600x 25G ports.  The trouble we've had
> there have been with some links showing link up on the switch and server
> side but actually failing to pass any traffic, so we need to stuff some >L1
> liveness checks on there to ensure those links are good while we sort out
> the root issue.  It is not yet clear if this is a cable fault, driver
> issue, or something firmware-ish on the NICs.
>
> Also, fun fact: 25G only made its way into the 802.3ad bonding mode driver
> in the Linux kernel in March this year[1].
>
> --
> Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
> pgp key: B178313E   | also on Signal
>
> [1]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/
> linux.git/commit/?id=19ddde1eeca1ee81f4add5e04da66055e09281ac
>

Re: 100G QSFP28 DAC cables - experience

[Brant Ian Stevens]

+1 on this...  I'd go so far as to say skip the copper, and just go with 
active-optical for short-run interconnects.



Tyler Conrad 
September 14, 2017 at 2:12 PM
We're using a mix as well, some QSFP28 AOC, others DAC. One thing that you
need to keep in mind about the DACs is going to be the bend radius. These
things are girthy af, so make sure to either overestimate your runs
slightly, or buy one to test first.

Hugo Slabbert 
September 14, 2017 at 12:54 PM

On Wed 2017-Sep-06 09:17:39 +0200, Jiri Prochazka  wrote:


We're deploying a decent chunk of 100G QSFP28 at the moment, but it's 
a mix of:


- a handful of 100G QSFP28 copper DACs for some switch peerlinks
- a bit >100x 100G QSFP28 AOC for interswitch links
- a lot more 100G QSFP28 -> 4x25G SFP28 copper breakouts

We're only a few weeks in at this point, so mileage may vary in the 
long run etc.


The copper peerlinks are mostly 1M with some 3M.  We've had no issues 
with them so far.


The AOC interswitch links vary more in length, but some of those are 
>10M (hence AOC rather than copper).  We've faced no issues with 
those.  Granted, there is BGP with BFD running across those, so those 
should help in terms of liveness checks and such.


I mention that because where we _have_ had issues are on the 100G -> 
4x25G copper breakouts.  Those are for 25G edge connectivity.  It's a 
decent sample size with a bit north of 600x 25G ports.  The trouble 
we've had there have been with some links showing link up on the 
switch and server side but actually failing to pass any traffic, so we 
need to stuff some >L1 liveness checks on there to ensure those links 
are good while we sort out the root issue.  It is not yet clear if 
this is a cable fault, driver issue, or something firmware-ish on the 
NICs.


Also, fun fact: 25G only made its way into the 802.3ad bonding mode 
driver in the Linux kernel in March this year[1].


Jiri Prochazka 
September 6, 2017 at 3:17 AM
Hi folks,

I'm wondering if anyone have (either positive or negative) experience 
with 100G QSFP28 DAC cables?


Is there anyone who is using 100G DAC in large scale and would 
recommend it (which means there are no issues compared to SR4 links)?


I'm thinking about cables with lenght up to 1m, not more.

We have had quite bad experience with 10G DAC in the past - but I do 
not want to be slave of the past.





Thank you for your thoughts!



Jiri



--

--
Regards,
--
Brant I. Stevens, Principal & Consulting Architect
bra...@argentiumsolutions.com
d:212.931.8566, x101. m:917.673.6536. f:917.525.4759.
http://argentiumsolutions.com

RE: 100G QSFP28 DAC cables - experience

[Jameson, Daniel]

They're pretty fragile assemblies too,  I ruined about 30 of them lacing them 
in,  they need fish-paper around each cable so you don't crush the conductors 
when lacing. 

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Brant Ian Stevens
Sent: Thursday, September 14, 2017 2:05 PM
To: Tyler Conrad
Cc: NANOG
Subject: Re: 100G QSFP28 DAC cables - experience

+1 on this...  I'd go so far as to say skip the copper, and just go with 
active-optical for short-run interconnects.

> Tyler Conrad 
> September 14, 2017 at 2:12 PM
> We're using a mix as well, some QSFP28 AOC, others DAC. One thing that you
> need to keep in mind about the DACs is going to be the bend radius. These
> things are girthy af, so make sure to either overestimate your runs
> slightly, or buy one to test first.
>
> Hugo Slabbert 
> September 14, 2017 at 12:54 PM
>
> On Wed 2017-Sep-06 09:17:39 +0200, Jiri Prochazka  wrote:
>
>
> We're deploying a decent chunk of 100G QSFP28 at the moment, but it's 
> a mix of:
>
> - a handful of 100G QSFP28 copper DACs for some switch peerlinks
> - a bit >100x 100G QSFP28 AOC for interswitch links
> - a lot more 100G QSFP28 -> 4x25G SFP28 copper breakouts
>
> We're only a few weeks in at this point, so mileage may vary in the 
> long run etc.
>
> The copper peerlinks are mostly 1M with some 3M.  We've had no issues 
> with them so far.
>
> The AOC interswitch links vary more in length, but some of those are 
> >10M (hence AOC rather than copper).  We've faced no issues with 
> those.  Granted, there is BGP with BFD running across those, so those 
> should help in terms of liveness checks and such.
>
> I mention that because where we _have_ had issues are on the 100G -> 
> 4x25G copper breakouts.  Those are for 25G edge connectivity.  It's a 
> decent sample size with a bit north of 600x 25G ports.  The trouble 
> we've had there have been with some links showing link up on the 
> switch and server side but actually failing to pass any traffic, so we 
> need to stuff some >L1 liveness checks on there to ensure those links 
> are good while we sort out the root issue.  It is not yet clear if 
> this is a cable fault, driver issue, or something firmware-ish on the 
> NICs.
>
> Also, fun fact: 25G only made its way into the 802.3ad bonding mode 
> driver in the Linux kernel in March this year[1].
>
> Jiri Prochazka 
> September 6, 2017 at 3:17 AM
> Hi folks,
>
> I'm wondering if anyone have (either positive or negative) experience 
> with 100G QSFP28 DAC cables?
>
> Is there anyone who is using 100G DAC in large scale and would 
> recommend it (which means there are no issues compared to SR4 links)?
>
> I'm thinking about cables with lenght up to 1m, not more.
>
> We have had quite bad experience with 10G DAC in the past - but I do 
> not want to be slave of the past.
>
>
>
>
> Thank you for your thoughts!
>
>
>
> Jiri
>

-- 

-- 
Regards,
--
Brant I. Stevens, Principal & Consulting Architect
bra...@argentiumsolutions.com
d:212.931.8566, x101. m:917.673.6536. f:917.525.4759.
http://argentiumsolutions.com

RE: 100G QSFP28 DAC cables - experience

[Naslund, Steve]

+1 on skipping the copper and going all optical.  In my experience, the fiber 
is much less likely to have strange faults.  We also experienced copper links 
that did not perform well but were showing up.  It seems the optical modules 
are much more mature in terms of going offline properly if the signals are not 
within the parameters.  

Steven Naslund
Chicago IL

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jameson, Daniel
Sent: Thursday, September 14, 2017 3:29 PM
To: Brant Ian Stevens; Tyler Conrad
Cc: NANOG
Subject: RE: 100G QSFP28 DAC cables - experience

They're pretty fragile assemblies too,  I ruined about 30 of them lacing them 
in,  they need fish-paper around each cable so you don't crush the conductors 
when lacing. 

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Brant Ian Stevens
Sent: Thursday, September 14, 2017 2:05 PM
To: Tyler Conrad
Cc: NANOG
Subject: Re: 100G QSFP28 DAC cables - experience

+1 on this...  I'd go so far as to say skip the copper, and just go with 
active-optical for short-run interconnects.

> Tyler Conrad 
> September 14, 2017 at 2:12 PM
> We're using a mix as well, some QSFP28 AOC, others DAC. One thing that you
> need to keep in mind about the DACs is going to be the bend radius. These
> things are girthy af, so make sure to either overestimate your runs
> slightly, or buy one to test first.
>
> Hugo Slabbert 
> September 14, 2017 at 12:54 PM
>
> On Wed 2017-Sep-06 09:17:39 +0200, Jiri Prochazka  wrote:
>
>
> We're deploying a decent chunk of 100G QSFP28 at the moment, but it's 
> a mix of:
>
> - a handful of 100G QSFP28 copper DACs for some switch peerlinks
> - a bit >100x 100G QSFP28 AOC for interswitch links
> - a lot more 100G QSFP28 -> 4x25G SFP28 copper breakouts
>
> We're only a few weeks in at this point, so mileage may vary in the 
> long run etc.
>
> The copper peerlinks are mostly 1M with some 3M.  We've had no issues 
> with them so far.
>
> The AOC interswitch links vary more in length, but some of those are 
> >10M (hence AOC rather than copper).  We've faced no issues with 
> those.  Granted, there is BGP with BFD running across those, so those 
> should help in terms of liveness checks and such.
>
> I mention that because where we _have_ had issues are on the 100G -> 
> 4x25G copper breakouts.  Those are for 25G edge connectivity.  It's a 
> decent sample size with a bit north of 600x 25G ports.  The trouble 
> we've had there have been with some links showing link up on the 
> switch and server side but actually failing to pass any traffic, so we 
> need to stuff some >L1 liveness checks on there to ensure those links 
> are good while we sort out the root issue.  It is not yet clear if 
> this is a cable fault, driver issue, or something firmware-ish on the 
> NICs.
>
> Also, fun fact: 25G only made its way into the 802.3ad bonding mode 
> driver in the Linux kernel in March this year[1].
>
> Jiri Prochazka 
> September 6, 2017 at 3:17 AM
> Hi folks,
>
> I'm wondering if anyone have (either positive or negative) experience 
> with 100G QSFP28 DAC cables?
>
> Is there anyone who is using 100G DAC in large scale and would 
> recommend it (which means there are no issues compared to SR4 links)?
>
> I'm thinking about cables with lenght up to 1m, not more.
>
> We have had quite bad experience with 10G DAC in the past - but I do 
> not want to be slave of the past.
>
>
>
>
> Thank you for your thoughts!
>
>
>
> Jiri
>

-- 

-- 
Regards,
--
Brant I. Stevens, Principal & Consulting Architect
bra...@argentiumsolutions.com
d:212.931.8566, x101. m:917.673.6536. f:917.525.4759.
http://argentiumsolutions.com

Re: Hurricane Irma: Florida, Puerto Rico and U.S. VI

[Sean Donelan]

In my last summary, I made a comment I didn't know what the network 
disaster recovery team meant.



AT&T recovery efforts
   3000 recovery team members
   14 Satellite Cell on Light Truck (SatCOLT)
- 1 in Tallahassee, 2 in Naples, 4 in Florida Keys
- 1 portable cell site St. Thomas, U.S. Virgin Islands
   3 Emergency Communications Vehicles
   50 Drones
   Command trailers, hazardous materials response equipment

Verizon recovery efforts
   2 Satellite Picocels on Trailers (SPOTs) in the Florida Keys
   Refueling and generators at cell towers througout Florida
   Hundreds of portable generators
   2 Wireless Emergency Communication Centers in Naples (provide charging 
stations, phones and computers for the public to contact family and 
friends)


Sprint recovery efforts
   Sprint reports over 75% of its network is repaired in the southeast and 
Puerto Rico.


AT&T, Sprint, T-Mobile, Verizon continue to extend their wireless data, 
text and voice plans waiving overage charges in the disaster areas. 
Details are different for each carrier, so check their web sites or 
customer service.



Federal Aviation Administration recovery efforts
   Deployed emergency mobile air traffic control tower to the 
international airport on St. Thomas, U.S. Virgin Islands


   Drone authorizations
138 commercial drone operator authorizations for Hurricane Harvey
80 commercial drone operator authorizations for Hurricane Irma


Federal Communicatiosn Commission recovery efforts
Reports at least 8,258,789 cable and wireline subscribers out of 
service in Alabama, Florida and Georgia.


Strangely, the number of non-mobile switching centers increased from 
1,040 (Sept 13) to 2,188 (Sept 14).  I believe this exceeds the number of 
cable headends and central offices in Florida. So I don't know what this 
number represents or why it increased so much.



The situation is still dire in some locations, but generally the disaster 
operations have moved to recovery and restoration.  Unless something 
significant happens, this is the last summary report about Hurricane Irma 
from me.