RE: AS3266: BitCanal hijack factory, courtesy of many connectivity providers

[McBride, Mack]

https://bgp.he.net/AS205869#_peers

This is another chronic hijacker that is spoofing downstream ASNs and Prefixes.
They are currently hijacking 25 prefixes.  Mostly /18s,/19s and /20s.

Telcom Italia, Telia and Eurotrans Telecom are upstreams.
Of course people making money off of it aren't going to do anything about it.
Eurotrans Telecom has telia and tata as upstreams.
They are also peered with HE but HE doesn't appear to be accepting the hijacked 
routes.
Good for them.

Mack

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Radu-Adrian Feurdean
Sent: Tuesday, June 26, 2018 1:57 PM
To: nanog@nanog.org
Subject: Re: AS3266: BitCanal hijack factory, courtesy of many connectivity 
providers

On Tue, Jun 26, 2018, at 20:23, Job Snijders wrote:
> I'm very happy FranceIX apply filters - however Bitcanal is known to 
> submit fabricated/falsified IRR information to databases like RADB and 
> RIPE. I've reported this multiple times over the years to IRR database 
> operators.
> 
> In conclusion in the case of Bitcanal, most of your filtering is 
> useless (and so is mine). Participants like Bitcanal dillute the value 
> of your route servers and the IXP as a whole.

I can confirm that this mornig (~09h30 CEST, when I read the first message in 
the thread) there were no BitCanal announces received from FranceIX Paris RS. 
Not even the ones with an IRR record (the ones in 213/8). All of them were from 
transit.
E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

RE: at business ipv6

[McBride, Mack]

I will speak more generally as I don't have insight into that provider.
Last mile providers are working on ipv6 everywhere because ipv4 is expensive 
and so is CGN and MAP-T.
IPv6 can reduce the need for ipv4 addresses and translation technology.
In all likelihood the device your office is connected to is not yet ipv6 
enabled but there is a date somewhere on a calendar belonging to an engineering 
group or two.
The sales rep probably doesn't have a clue what that date is which is why he 
isn't giving you information.
He simply doesn't have it.  Nor is an engineering group likely to give it to 
sales until it is a planned maintenance.
Engineers don't like promising things they can't deliver.
Sales likes promising the moon if they know there is cheese available at some 
point in the future.

Mack

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Randy Bush
Sent: Thursday, June 21, 2018 10:20 AM
To: Nick Hilliard 
Cc: North American Network Operators' Group 
Subject: Re: at business ipv6

> Yes, one particular plotline which can explain why docsis systems do 
> this is that standard residential customers are provisioned using 
> giant broadcast domains directly on the cable, with DHCP config.
> Obviously it's more complicated because it's docsis, but lemme 
> handwave and say that this is the gist of it.  Because you're dealing 
> with giant broadcast domains, you assign IP address blocks to 
> individual CMTSs and your customers are assigned out of those ranges.
> 
> Assigning ipv6 in this context is really simple: it's part of the 
> baseline DOCSIS3.0 standard and is supported incredibly well by all 
> parts of the network.
> 
> Static addresses don't fit into this paradigm because you if you 
> configure your static customers from a single broadcast domain, then 
> they are glued to a particular CMTS and can't be moved from that CMTS 
> unless you renumber them.
> 
> This doesn't work in practice because if you want to grow your 
> network, you probably want to be able to move around chunks of your 
> cable network from one CMTS to another in order to balance out your 
> traffic.  Or you might want to split a bunch of cable nodes from one 
> CMTS to multiple, according as your traffic outgrew the capabilities 
> of a single CMTS (a node in this context is a small chunk of a cable 
> network).
> 
> One way of getting around this mess is to backhaul all your static 
> customer interfaces using mpls l2vpn PWHE up to a L3 box which just 
> handles static IP addresses.  You configure the customer's static 
> default gateway IP address on an interface on this head-end router, 
> and the customer's cable modem will have a virtual connection directly 
> to that interface.  The thing is, this virtual interface termination 
> system might or might not be tied into the entire ipv6 provisioning 
> system.  If it isn't, you're SoL.  So even if dirt-cheap residential 
> customers can get ipv6 very easily, it's different by virtue of the 
> fact that you're using static IP addresses, because they're a headache 
> for cable operators.

aha!  makes sense.

i'll settle for dynamic.  if i need static internally, i can always do
nat66 :)/2

i do not want to play how hard can we make ipv6 deployment; just want to enable 
it on a five-segment office lan.

but i am beginning to see that there may be a reason i am having problems 
getting past an account rep.

randy
E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

RE: Impacts of Encryption Everywhere (any solution?)

[McBride, Mack]

Netflix is not supposed to be cacheable by third parties for legal reasons 
that have absolutely nothing to do with routing.
Similar with most streaming services including stupid geolocation usage.
If you have sufficient eyeballs, Netflix will work with you to get a local cache
set up using their devices.  If it is just you and a half dozen neighbors they 
won't.

A far larger problem than the encryption is website design that doesn't cater to
low bandwidth links.  HTML5 is cool but marking a 10mbyte animation as 
non-cachable
and putting it on the front page of a major bank website is a misuse of 
resources.

Mack

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of William Herrin
Sent: Tuesday, June 19, 2018 9:34 AM
To: Lee Howard 
Cc: nanog@nanog.org
Subject: Re: Impacts of Encryption Everywhere (any solution?)

On Tue, Jun 19, 2018 at 10:53 AM, Lee Howard  wrote:
> On 06/17/2018 02:53 PM, Brad wrote:
>> While I agree there are unintended consequences every time 
>> advancements are made in relation to the security and stability of 
>> the Internet- I disagree we should be rejecting their 
>> implementations. Instead, we should innovate further.
>
>
> I look forward to your innovations.

The innovation I'd like to see is a multi-level streaming cache.
Here's the basic idea:

Define a network protocol such as "mlcache"

mlcache://data.netflix.com/starwars/chunk12345 is a chunk of some video that 
netflix has. It's encrypted. The client got the decryption key for that chunk 
and instructions on how to load the chunks in what order in an authenticated 
http connection.

The client does not connect to data.netflix.com. Instead, it probes an anycast 
IP address to find the nearest cache. If there is no cache, then it falls back 
on contacting data.netflix.com directly.

If the cache probe returned a unicast IP address for a nearby cache then the 
client asks the cache to retrieve that chunk instead. If lots of folks using 
the cache are watching that particular video, the cache can supply the chunk 
without asking netflix for it again.

If the cache doesn't have the chunk, it contacts the next cache upstream. If 
there is no next cache upstream, it contacts data.netflix.com directly.


The cache is not application-specific. Anything willing to talk the cache 
protocol can use it to fetch chunks of data from any server.

In principle this should work for live streams too. The head end server either 
replies "not yet" or holds the request open until the next chunk of data is 
available. The cache requests the chunk once and supplies it to all clients 
once retrieved. Keep the chunks small enough that the caching process delays 
the live stream by a second or two, no different than the television broadcasts 
do.


Regards,
Bill Herrin



--
William Herrin  her...@dirtside.com  b...@herrin.us Dirtside 
Systems . Web: 
E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

RE: Time to add 2002::/16 to bogon filters?

[McBride, Mack]

This should have been filtered before.
Lots of people improperly implemented this so it caused issues.

Mack

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of John Kristoff
Sent: Monday, June 18, 2018 3:48 PM
To: Job Snijders 
Cc: NANOG [nanog@nanog.org] 
Subject: Re: Time to add 2002::/16 to bogon filters?

On Mon, 18 Jun 2018 21:08:05 +
Job Snijders  wrote:

> TL;DR: Perhaps it is time to add 2002::/16 to our EBGP bogon filters?

Hi Job,

I've been asking people about this recently.  I don't particularly like having 
misdirected traffic or badly configured hosts sending junk to those who happen 
to be announcing addresses from this prefix.  I'm planning on adding this to a 
bogon filter here.

John
E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

RE: What are people using for IPAM these days?

[McBride, Mack]

Stone tablets are far superior when using rfc2549 networks.

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Paul Ebersman
Sent: Wednesday, June 13, 2018 6:54 AM
To: North American Network Operators' Group 
Subject: Re: What are people using for IPAM these days?

> emacs!
 vim!
>>> ed!
>> TECO!
> cat

IPAM? Meh.

Why bother? It's all there in your router/switch configs if you need to check 
it.
E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

RE: What are people using for IPAM these days?

[McBride, Mack]

Better than excel at "Two People Editing Lane"

Mack

-Original Message-
From: NANOG [mailto:nanog-bounces+c-mack.mcbride=charter@nanog.org] On 
Behalf Of Alain Hebert
Sent: Tuesday, June 12, 2018 12:20 PM
To: nanog@nanog.org
Subject: Re: What are people using for IPAM these days?

     Google Docs =D

     (Just to be annoying).

-
Alain Hebertaheb...@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443

On 06/12/18 13:17, McBride, Mack wrote:
> Excel does not go down 'Will It Scale Road'.
> It ignores the stop light and crashes at 'Two People Editing Lane'.
>
> Mack
>
> -Original Message-
> From: Stacy Hughes [mailto:ipgodd...@gmail.com]
> Sent: Tuesday, June 12, 2018 9:43 AM
> To: McBride, Mack 
> Cc: sur...@mauigateway.com; nanog@nanog.org
> Subject: Re: What are people using for IPAM these days?
>
> If you start with Excel, down Will It Scale Road, you will be sorry,  so very 
> sorry.  Especially when it comes to v6.
> Stacy
>
>> On Jun 12, 2018, at 8:13 AM, McBride, Mack  
>> wrote:
>>
>> Allocations, not IPs.  And yes if they are reasonably static an excel 
>> spreadsheet can go higher.
>>
>> Mack
>>
>> -Original Message-
>> From: NANOG
>> [mailto:nanog-bounces+c-mack.mcbride=charter@nanog.org] On Behalf 
>> Of Scott Weeks
>> Sent: Monday, June 11, 2018 2:40 PM
>> To: nanog@nanog.org
>> Subject: RE: What are people using for IPAM these days?
>>
>>
>>
>> --- c-mack.mcbr...@charter.com wrote:
>> From: "McBride, Mack" 
>>
>> If you are managing more than a thousand IPs allocations spreadsheets are 
>> not manageable for IPv4.
>> -
>>
>>
>>
>> I managed a /15, two /16s and several /24s (so, well over a quarter 
>> million IPs) on a spreadsheet for years.
>> So, that's an 'it depends' answer.
>>
>> scott
>> E-MAIL CONFIDENTIALITY NOTICE:
>> The contents of this e-mail message and any attachments are intended solely 
>> for the addressee(s) and may contain confidential and/or legally privileged 
>> information. If you are not the intended recipient of this message or if 
>> this message has been addressed to you in error, please immediately alert 
>> the sender by reply e-mail and then delete this message and any attachments. 
>> If you are not the intended recipient, you are notified that any use, 
>> dissemination, distribution, copying, or storage of this message or any 
>> attachment is strictly prohibited.
> E-MAIL CONFIDENTIALITY NOTICE:
> The contents of this e-mail message and any attachments are intended solely 
> for the addressee(s) and may contain confidential and/or legally privileged 
> information. If you are not the intended recipient of this message or if this 
> message has been addressed to you in error, please immediately alert the 
> sender by reply e-mail and then delete this message and any attachments. If 
> you are not the intended recipient, you are notified that any use, 
> dissemination, distribution, copying, or storage of this message or any 
> attachment is strictly prohibited.
>
>

E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

RE: What are people using for IPAM these days?

[McBride, Mack]

Excel does not go down 'Will It Scale Road'.
It ignores the stop light and crashes at 'Two People Editing Lane'.

Mack

-Original Message-
From: Stacy Hughes [mailto:ipgodd...@gmail.com] 
Sent: Tuesday, June 12, 2018 9:43 AM
To: McBride, Mack 
Cc: sur...@mauigateway.com; nanog@nanog.org
Subject: Re: What are people using for IPAM these days?

If you start with Excel, down Will It Scale Road, you will be sorry,  so very 
sorry.  Especially when it comes to v6.
Stacy 

> On Jun 12, 2018, at 8:13 AM, McBride, Mack  wrote:
> 
> Allocations, not IPs.  And yes if they are reasonably static an excel 
> spreadsheet can go higher.
> 
> Mack
> 
> -Original Message-
> From: NANOG 
> [mailto:nanog-bounces+c-mack.mcbride=charter@nanog.org] On Behalf 
> Of Scott Weeks
> Sent: Monday, June 11, 2018 2:40 PM
> To: nanog@nanog.org
> Subject: RE: What are people using for IPAM these days?
> 
> 
> 
> --- c-mack.mcbr...@charter.com wrote:
> From: "McBride, Mack" 
> 
> If you are managing more than a thousand IPs allocations spreadsheets are not 
> manageable for IPv4.
> -
> 
> 
> 
> I managed a /15, two /16s and several /24s (so, well over a quarter 
> million IPs) on a spreadsheet for years.
> So, that's an 'it depends' answer.
> 
> scott
> E-MAIL CONFIDENTIALITY NOTICE: 
> The contents of this e-mail message and any attachments are intended solely 
> for the addressee(s) and may contain confidential and/or legally privileged 
> information. If you are not the intended recipient of this message or if this 
> message has been addressed to you in error, please immediately alert the 
> sender by reply e-mail and then delete this message and any attachments. If 
> you are not the intended recipient, you are notified that any use, 
> dissemination, distribution, copying, or storage of this message or any 
> attachment is strictly prohibited.

E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

RE: What are people using for IPAM these days?

[McBride, Mack]

Allocations, not IPs.  And yes if they are reasonably static an excel 
spreadsheet can go higher.

Mack

-Original Message-
From: NANOG [mailto:nanog-bounces+c-mack.mcbride=charter@nanog.org] On 
Behalf Of Scott Weeks
Sent: Monday, June 11, 2018 2:40 PM
To: nanog@nanog.org
Subject: RE: What are people using for IPAM these days?



--- c-mack.mcbr...@charter.com wrote:
From: "McBride, Mack" 

If you are managing more than a thousand IPs allocations spreadsheets are not 
manageable for IPv4.
-



I managed a /15, two /16s and several /24s (so, well 
over a quarter million IPs) on a spreadsheet for years.  
So, that's an 'it depends' answer.

scott
E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

RE: Need /24 (arin) asap

[McBride, Mack]

Large providers still have to deal with geolocation, ip reputation etc.
We just have to deal with it on an exponentially larger scale.

Mack

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Mike Hammett
Sent: Monday, June 11, 2018 10:58 AM
Cc: nanog@nanog.org
Subject: Re: Need /24 (arin) asap

*nods* Having v6 does solve a lot, but the ones that are difficult to work with 
in v4 are still using v4, so you still have problems. 

I think those experiences are ones felt only by small to medium service 
providers. Large carriers, academia, hosting\datacenter, etc. don't really have 
those problems. They do have different problems, but they're fairly well known 
problems with processes laid out on how to deal with it. 

See my thread from a few weeks ago calling on people doing IP reputation or any 
sort of geolocation, filtering, blocking, etc. being more transparent. There 
are ISPs that have tried everything short of driving to the content provider's 
location and demanding resolution. 




-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com 

Midwest-IX
http://www.midwest-ix.com 

- Original Message -

From: "Ca By" 
To: "Michael Crapse" 
Cc: nanog@nanog.org
Sent: Monday, June 11, 2018 11:50:55 AM
Subject: Re: Need /24 (arin) asap 

On Mon, Jun 11, 2018 at 9:27 AM, Michael Crapse  wrote: 

> For an eyeball network, you cannot count on an IPv6 only network. 
> Because all of your "customers" will complain because they can't get 
> to hulu, or any other ipv4 only eyeball service. You still need the 
> ipv4s to operate a proper network, and good luck figuring out which 
> services are blacklisting your new /24 because the ipv4 space used to be a 
> VPN provider, and the "in"
> thing to do for these services is to block VPNs. 
> 

There are many IPv6-only eyeball networks. Definitely many examples in 
wireless (T-Mobile, Sprint, BT ) and wireline (DT with DS-Lite in Germany, 
Orange Poland ...) and even more where IPv4 NAT44 + IPv6 is used. Just 
saying, having ipv6 hedges a lot of risk associate with blacklisting and 
translation related overhead and potentially scale and cost of IPv4 
addresses. 


> 
> 
> On 11 June 2018 at 09:21, Ca By  wrote: 
> 
>> On Sun, Jun 10, 2018 at 8:43 AM Stan Ouchakov  
>> wrote: 
>> 
>> > Hi, 
>> > 
>> > Can anyone recommend transfer market brokers for ipv4 addresses? Need 
>> > clean /24 asap. ARIN's waiting list is too long... 
>> > 
>> > Thanks! 
>> > 
>> > 
>> > -Stan 
>> > 
>> > Meanwhile, FB reports that 75% of mobiles in the USA reach them via ipv6 
>> 
>> https://code.facebook.com/posts/635039943508824/how-ipv6- 
>> deployment-is-growing-in-u-s-and-other-countries/ 
>> 
>> 
>> And Akaimai reports 80% of mobiles 
>> 
>> https://blogs.akamai.com/2018/06/six-years-since-world-ipv6- 
>> launch-entering-the-majority-phases.html 
>> 
>> 
>> And they both report ipv6 is faster / better. 
>> 
> 
> 

E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

RE: What are people using for IPAM these days?

[McBride, Mack]

Using BT Diamond IPControl.
For a larger provider with a lot of blocks and multiple groups using IP space 
you can't beat it.
It has a lot of enterprise features that others lack such as automation 
call-outs and overlapping space allocations.
If you can afford it, you will not go wrong.  It really is the great.

I have also worked with spreadsheets, homegrown systems, 6connect and a few 
others.
If you are managing more than a thousand IPs allocations spreadsheets are not 
manageable for IPv4.
Structured IPv6 can be managed out of spreadsheets with little to no issues 
well beyond that since it is structured.

6connect is better than infoblox in my opinion but everyone has a different 
style of IP management.
If you are going for free or low cost there are plenty out there but they don't 
have the features of more expensive options.

+1 for a generic number management system, but I haven't seen such a thing.

Mack



-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Owen DeLong
Sent: Monday, June 11, 2018 8:45 AM
To: Steve Mikulasik 
Cc: NANOG 
Subject: Re: What are people using for IPAM these days?

I find lots of people are using either 6connect or InfoBlox.

YMMV. Both have good IPv6 support.

Owen


> On Jun 11, 2018, at 07:07 , Steve Mikulasik  wrote:
> 
> PHPIpam, but I do find there to be a lack of current documentation.

E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

RE: Intel DPDK vs Broadcom/Mellanox SDK

[McBride, Mack]

The Broadcom chips have some quirks that the Broadcom SDK handles and the DPDK 
does not.
Specifically related around port hang up after port flaps.
I am certain each chipset has quirks that are best handled by their SDK.
The vendor specific SDK is always going to work better with a their specific 
chipset.
That is just a given based on the vendor understanding their own chipset better.
But again for software switching other factors apply.

Mack

From: Kasper Adel [mailto:karim.a...@gmail.com]
Sent: Tuesday, June 05, 2018 7:31 PM
To: McBride, Mack 
Cc: NANOG list 
Subject: Re: Intel DPDK vs Broadcom/Mellanox SDK

Can you please provide examples on issues that you highlighted with broadcom? 
Are you saying i may not see the same with mellanox?

Thanks

On Monday, June 4, 2018, McBride, Mack 
mailto:c-mack.mcbr...@charter.com>> wrote:
Use the package that corresponds to the chipset in your equipment.
Ie. Broadcom/Mellanox chips use that SDK.  Intel chips use DPDK.
With white box switches using Broadcom chips you will run into issues
If you don't use the Broadcom SDK.  Obviously your mileage will vary
based on the actual application.  If it isn't a hardware switch and is CPU based
like a home router, then there are a lot more factors and the CPU factors may
outweigh the chipset factors.  You may want to look at a list related to home
routers for more guidance.

Mack

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org<mailto:nanog-boun...@nanog.org>] On 
Behalf Of Kasper Adel
Sent: Sunday, June 03, 2018 11:45 PM
To: NANOG list mailto:nanog@nanog.org>>
Subject: Intel DPDK vs Broadcom/Mellanox SDK

Hi

Anothe email thread to get some guidance on points to consider when comparing 
new platforms that advocate using DPDK as the hardware acceleration SDK vs the 
broadcom/mellanox.

The DPDK ones claim enhanced performance but every time i ask questions, i get 
the logical and typical answer of “it depends”

Thx
Kim
E-MAIL CONFIDENTIALITY NOTICE:
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.
E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

RE: ICANN GDPR lawsuit

[McBride, Mack]

There is a major difference between a directory listing service
where the primary goal is to advertise potentially protected information
and a domain registration or net block registration where the information
is secondary and its dissemination is not what you are actually requesting.
Remember peering DB has a sole purpose of disseminating names, phone
numbers and email addresses.

Mack

From: Rubens Kuhl [mailto:rube...@gmail.com]
Sent: Tuesday, June 05, 2018 1:41 PM
To: McBride, Mack 
Cc: Daniel Corbe ; Baldur Norddahl 
; nanog@nanog.org
Subject: Re: ICANN GDPR lawsuit



On Tue, Jun 5, 2018 at 4:31 PM, McBride, Mack 
mailto:c-mack.mcbr...@charter.com>> wrote:
PeeringDB is already 100% opt-in.

Domain registration is also opt-in, and still registrars, registries and ICANN 
have to change things to comply with GDPR.


Rubens

E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

RE: ICANN GDPR lawsuit

[McBride, Mack]

PeeringDB is already 100% opt-in.

Mack

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Daniel Corbe
Sent: Monday, June 04, 2018 12:56 PM
To: Baldur Norddahl 
Cc: nanog@nanog.org
Subject: Re: ICANN GDPR lawsuit

at 2:40 PM, Baldur Norddahl  wrote:

> man. 4. jun. 2018 17.31 skrev McBride, Mack :
>
>> GDPR doesn't play well with directory listing services.
>> BUT since providing contact information is exactly what a directory 
>> listing service does, It is safe to assume that this is 'essential' 
>> under GDPR.
>
> No it is very clear that publishing private information about 
> individuals is in fact not necessary to assign netblocks and domains to 
> companies.
>
> It is a little less clear when the ressource is assigned to an individual.
> But considering there already exist privacy options for domains, the 
> same solutions could be implemented for other ressource types.
>

It occurs to me that operators might want to opt-in to have their data 
published through PeeringDB.  From a purely pragmatic standpoint, I won’t peer 
with anyone I can’t reach out to and if you don’t have a 24/7 NOC chances are 
good that you’re going to get depeered the first time there’s a technical issue 
and I can’t reach you for help.

An academic exercise, for sure.   But one that would render this line of  
thinking rather moot.



E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

RE: ICANN GDPR lawsuit

[McBride, Mack]

Peering DB is also a directory service.
The only 'service' they provide is to distribute contact information.
Therefor maintaining and distributing information is in fact 'essential'.
Further, Peering DB make it easy to remove contact information.
The difference in legal systems makes Peering DB a very low risk in the EU.

Whois is more 'at risk' because it doesn't require individual information to 
maintain a net block.
BUT, most whois can be handled by role accounts and privacy guard services.
Best practice is to use role accounts.
Privacy guard deals with the now rare condition where a net block is owned by 
an individual.
Most domain name services have provided a privacy guard option for years.

Most network providers simply want an email address that works.
I don't really care if it is joe or the purple people eater as long as it gets
a response from an intelligent entity that can fix a routing issue.
For this purpose a level 1 tech capable of escalating an issue counts as
an intelligent entity.

Mack

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Owen DeLong
Sent: Monday, June 04, 2018 12:58 PM
To: Baldur Norddahl 
Cc: nanog@nanog.org
Subject: Re: ICANN GDPR lawsuit



> On Jun 3, 2018, at 22:44 , Baldur Norddahl  wrote:
> 
>> 
>> 
>> 
>> Yeah, what Niels is really leaving out here is the open question of 
>> whether or not GDPR will eventually lead to the destruction of Peering DB.
>> 
>> Owen
>> 
> 
> 
> Of course it will not. We just need to accept that only roles not 
> people are published. Those people will change job anyway and nobody updates 
> whois.
> 
> GDPR does not apply to companies, so you can still publish the owner 
> of domains and IP prefixes as company names with contact information.
> 
> Regards
> 
> Baldur
> 
>> 

Much of the information in Peering DB is people. In fact, IIRC, peering DB 
doesn’t really have “role” accounts.

Peering DB is unrelated to whois.

Owen

E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

RE: ICANN GDPR lawsuit

[McBride, Mack]

That would be real time information involving 'essential' activities.
GDPR would not prevent determining the source of an attack.
GDPR specifically doesn't protect anyone involved in criminal activity
nor contradict any regulatory requirement (which covers cyber attacks).

Mack

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Johnny Eriksson
Sent: Monday, June 04, 2018 12:24 PM
To: nanog@nanog.org
Subject: Re: ICANN GDPR lawsuit

Hank Nussbacher wrote:

> The entire whois debacle will only get resolved when some hackers 
> attack www.eugdpr.org, ec.europa.eu and some other key .eu sites.  
> When the response they get will be "sorry, we can't determine who is 
> attacking you since that contravenes GDPR", will the EU light bulb go 
> on that something in GDPR needs to be tweaked.

You seem to assume that said light bulb does in fact exist.

> -Hank

--Johnny

  /\_/\
 ( *.* )
  > ^ <
E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

RE: Intel DPDK vs Broadcom/Mellanox SDK

[McBride, Mack]

Use the package that corresponds to the chipset in your equipment.
Ie. Broadcom/Mellanox chips use that SDK.  Intel chips use DPDK.
With white box switches using Broadcom chips you will run into issues
If you don't use the Broadcom SDK.  Obviously your mileage will vary
based on the actual application.  If it isn't a hardware switch and is CPU based
like a home router, then there are a lot more factors and the CPU factors may
outweigh the chipset factors.  You may want to look at a list related to home
routers for more guidance.

Mack

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Kasper Adel
Sent: Sunday, June 03, 2018 11:45 PM
To: NANOG list 
Subject: Intel DPDK vs Broadcom/Mellanox SDK

Hi

Anothe email thread to get some guidance on points to consider when comparing 
new platforms that advocate using DPDK as the hardware acceleration SDK vs the 
broadcom/mellanox.

The DPDK ones claim enhanced performance but every time i ask questions, i get 
the logical and typical answer of “it depends”

Thx
Kim
E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

RE: ICANN GDPR lawsuit

[McBride, Mack]

GDPR doesn't play well with directory listing services.
BUT since providing contact information is exactly what a directory listing 
service does, 
It is safe to assume that this is 'essential' under GDPR.

Ie. Unlike the US, an EU judge would find it silly that you signed up for a 
directory listing
Service and were upset they listed your contact information.  Similarly keeping 
contact
Information of entities you have an ongoing peering relationship with would be 
essential.

In physical terms, a milk delivery company has to keep track of its customers 
addresses and
Billing information in order to deliver the milk and bill the customers.

GDPR doesn't want individuals information collected or retained that isn't 
essential to providing 
services, nor can you share that information without permission unless it is 
essential.
Obviously that is a one run-on sentence over simplification of a regulation 
that could take
many volumes to fully decipher.  Unlike the US, EU law is based on fairness and 
reasonableness
so generally their society is not as litigious.

Mack

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Owen DeLong
Sent: Sunday, June 03, 2018 10:00 PM
To: Rodney Joffe 
Cc: NANOG 
Subject: Re: ICANN GDPR lawsuit



> On Jun 3, 2018, at 14:17 , Rodney Joffe  wrote:
> 
> 
> 
>> On Jun 1, 2018, at 10:21 AM, niels=na...@bakker.net wrote:
>> 
>> * l...@satchell.net (Stephen Satchell) [Fri 01 Jun 2018, 14:51 CEST]:
>>> How does your shop, Niels, go about making contact with an operator that is 
>>> hijacking one of your netblocks, or is doing something weird with routing 
>>> that is causing your customers problems, or has broken BGP?
>> 
>> The same as we do now, by posting on NANOG "Can someone from ASx / 
>> largetelco.com contact me offlist?”
> 
> Seriously? You’ve been around long enough to know thats a bull$&^% answer. 
> 
> Feel free to look through the archives of *this* list and look at how many 
> times some $random handle at some $random privacy protected or generic domain 
> asks for someone from $bignetwork to contact them about a network problem.
> 
> Take you for example. You’ve been around for at least 15-20 years that I 
> recall. But I bet you that 80% of the people on NANOG have *no* idea who you 
> are or who you work for, and given the “useful" information on your website, 
> an op would have to take the time to google you - which is way above the 
> threshold of effort most people would take.
> 
> And that preassumes that the ops from the tiny little network leaking your 
> routes is actually a) subscribed here, and b) monitoring or filtering 
> appropriately. And before you talk about the fact you stated “ 
> largetelco(dot)com” I would bet that there are large telco’s who don’t have 
> op’s like us who waste their time on NANOG.
> 
> So, instead of the suggestion you provided, do you have any other suggestions 
> that are useful? I’m asking seriously, because I really do see this as a 
> problem we all have to be able to solve as operators. I believe this is 
> absolutely on-topic for one of the NANOG lists because this is a 100% 
> operational problem, that has appears to have as its only GDPR acceptable 
> solution alternative, following a manual/email thread from *your* next hop 
> network, requesting contacts/intros all the way down to the dumba$$ BGP 
> speaking edge network with a part-time routing guy/antenna installer.
> 
> /rlj
> 


Yeah, what Niels is really leaving out here is the open question of whether or 
not GDPR will eventually lead to the destruction of Peering DB.

Owen

E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

RE: ICANN GDPR lawsuit

[McBride, Mack]

If they are hijacking a netblock, it is safe to assume they will also hijack an 
ASN.
The best method of dealing with hijacking is still deaggregation and contacting
Upstreams providers from a registered whois address which should be a role 
account.

Mack

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Rodney Joffe
Sent: Sunday, June 03, 2018 3:17 PM
To: NANOG 
Subject: Re: ICANN GDPR lawsuit



> On Jun 1, 2018, at 10:21 AM, niels=na...@bakker.net wrote:
> 
> * l...@satchell.net (Stephen Satchell) [Fri 01 Jun 2018, 14:51 CEST]:
>> How does your shop, Niels, go about making contact with an operator that is 
>> hijacking one of your netblocks, or is doing something weird with routing 
>> that is causing your customers problems, or has broken BGP?
> 
> The same as we do now, by posting on NANOG "Can someone from ASx / 
> largetelco.com contact me offlist?”

Seriously? You’ve been around long enough to know thats a bull$&^% answer. 

Feel free to look through the archives of *this* list and look at how many 
times some $random handle at some $random privacy protected or generic domain 
asks for someone from $bignetwork to contact them about a network problem.

Take you for example. You’ve been around for at least 15-20 years that I 
recall. But I bet you that 80% of the people on NANOG have *no* idea who you 
are or who you work for, and given the “useful" information on your website, an 
op would have to take the time to google you - which is way above the threshold 
of effort most people would take.

And that preassumes that the ops from the tiny little network leaking your 
routes is actually a) subscribed here, and b) monitoring or filtering 
appropriately. And before you talk about the fact you stated “ 
largetelco(dot)com” I would bet that there are large telco’s who don’t have 
op’s like us who waste their time on NANOG.

So, instead of the suggestion you provided, do you have any other suggestions 
that are useful? I’m asking seriously, because I really do see this as a 
problem we all have to be able to solve as operators. I believe this is 
absolutely on-topic for one of the NANOG lists because this is a 100% 
operational problem, that has appears to have as its only GDPR acceptable 
solution alternative, following a manual/email thread from *your* next hop 
network, requesting contacts/intros all the way down to the dumba$$ BGP 
speaking edge network with a part-time routing guy/antenna installer.

/rlj

E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

RE: ICANN GDPR lawsuit

[McBride, Mack]

The whois guard solution seems workable where the registrar just forwards 
information.
It would be nice if there were corporate phone numbers as GDPR doesn't apply to 
corporations.
For routing whois information there aren't going to be many individuals and it 
would seem
that the corporations who employee individuals should be the ones protecting 
those individuals
work emails by providing a generic contact email forward.  Which is good 
practice anyway
since people leave and go on vacation and problems still happen.
And the routing whois information is a lot more relevant to most of us here.
Of course anyone posting to a public list should be aware that their email 
address is
part of that information.  Which is particularly relevant to this list.

Mack

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of William Herrin
Sent: Friday, June 01, 2018 9:24 AM
To: l...@satchell.net
Cc: nanog@nanog.org
Subject: Re: ICANN GDPR lawsuit

On Fri, Jun 1, 2018 at 8:47 AM, Stephen Satchell  wrote:
> In other words, how do you do your job in light of the GDPR 
> restrictions on accessing contact information for other network operators?
>
> Please be specific.  A lot of NOC policies and procedures will need to 
> be updated.

Publish role accounts in whois instead of personal information?

Sorry, I don't mean to break up an energetic tirade but a phone number is not 
PII when it's attached to "hostmaster" instead of "John Doe".
You and I like knowing that there's a specific person there and it certainly 
helps when auditing public policy compliance but as a technical matter contact 
doesn't have to work that way.

I noticed that Namecheap solved their GDPR problem by simply making their 
"WhoisGuard" product free.

Regards,
Bill Herrin


--
William Herrin  her...@dirtside.com  b...@herrin.us Dirtside 
Systems . Web: 
E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

RE: Impacts of Encryption Everywhere (any solution?)

[McBride, Mack]

Scott hit the nail on the head.
Hotel/café/mall wifi is generally horrible for the same reason urban 4g is 
horrible.
The backhaul and load on the available spectrum is usually excessive.
Carrier wifi is usually (but not always) equipped with decent backhaul.
However carrier wifi in stadiums usually suffers from problems with spectrum 
saturation.
Any wifi or 4G will eventually run out of available bandwidth on assigned 
spectrum.
Wifi has the advantage of being able to use smaller range restricted access 
points but
the stadium example shows why even that is limited when you have 40K people 
trying
to access the internet.

Mack

From: K. Scott Helms [mailto:kscott.he...@gmail.com]
Sent: Wednesday, May 30, 2018 11:10 AM
To: mark.ti...@seacom.mu
Cc: McBride, Mack ; b...@6by7.net; NANOG list 

Subject: Re: Impacts of Encryption Everywhere (any solution?)

Mark,

A couple of things, first that kind of utilization isn't feasible once 
penetration rates in dense areas reach certain levels.  There's a reason that 
NTT Docomo moved more than 70% of their data traffic to the 3.5 GHz band and 
that reason is that there's not (nor will there be) enough wireless spectrum to 
meet the needs of everyone with licensed space.  (That same use case is why all 
the big North American providers are looking at CBRS.) Further, 4G/5G is going 
to have trouble scaling to the kinds of network demands going forward, again 
especially in dense areas.  While it's certainly possible today to stream 
unicast video over LTE and will (for a while) even more feasible over 5G the 
physics simply aren't with the wireless world.

I'd say that your example of poor DSL performance isn't unique, it happens in 
some spots in the US, but in general wired performance has much higher 
individual and even higher aggregate capacities when correctly deployed.  I 
doubt your hotel example is a poor deployment though, it's more likely that the 
hotel owners are under paying for both the WAN connection and the WiFi 
infrastructure.


On Wed, May 30, 2018 at 1:01 PM Mark Tinka 
mailto:mark.ti...@seacom.mu>> wrote:


On 30/May/18 17:11, McBride, Mack wrote:

> In high density urban areas last mile infrastructure (mostly copper) is 
> considerably better than 4G.
> Localized carrier powered wifi is good as well but it is not and should not 
> be confused with 4G.

I think it depends on what it is you're trying to do. If your
application is linear IPTV streaming into your home, that probably isn't
a great idea for any kind of non-wired media. On the other hand, in
South Africa, where I live, it is routine to deliver video streaming
services (Netflix, Youtube, ShowMax, e.t.c.) to one's home over 4G/LTE,
to the extent that the service providers have special data plans that
support these kinds of use-cases.

In South Africa, I generally find wi-fi in the hotels to be pretty bad,
as the majority of them tend to be on ADSL backhaul, which averages
between 1Mbps - 4Mbps to support several dozen or more rooms. A few
hotels have migrated to fibre, but between guessing what last mile
they're on and how they operate the wi-fi network, I ALWAYS prefer to
tether my iPhone to my laptop and work when I'm on the road within the
country. In all major cities, my 3G/4G performs a lot more reliably,
better and predictably than most cafe, hotel or mall wi-fi. I don't even
bother when hotels offer their wi-fi vouchers upon check-in.

With my 4G services (Vodacom and MTN), I can average between 30Mbps -
55Mbps when tethering, and that's plenty enough for me. I have a decent
monthly data plan that I don't have to worry about running out. Of
course, performance isn't as great if you're in a remote part of the
country, but that's not unique to South Africa.

Mark.
E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

RE: Impacts of Encryption Everywhere (any solution?)

[McBride, Mack]

In high density urban areas last mile infrastructure (mostly copper) is 
considerably better than 4G. 
Localized carrier powered wifi is good as well but it is not and should not be 
confused with 4G.

Mack

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Ben Cannon
Sent: Wednesday, May 30, 2018 1:54 AM
To: Mark Tinka 
Cc: nanog@nanog.org list 
Subject: Re: Impacts of Encryption Everywhere (any solution?)

Thank you Mark for your excellent firsthand account.

I’ve observed this - the developing world (better? Same meaning but hey) does 
not miss copper infrastructure.  That was always bad and was always going to be 
bad now that 4G is here. There’s just zero reason now.   It’s an anchor.

-Ben

> On May 29, 2018, at 10:19 PM, Mark Tinka  wrote:
> 
> 
> 
>> On 29/May/18 20:01, Eric Kuhnke wrote:
>> 
>> The one thing that you CAN generalize about a great many developing 
>> nation telecom markets, which is different than the US and Western Europe:
>> 
>> Many urban locations have a complete absence of functioning last 
>> mile, legacy copper telecom infrastructure, which in a US city you 
>> would see used for ADSL2+ or VDSL2 or g.fast on old POTS phone lines, 
>> or
>> DOCSIS3.0/DOCSIS3.1 on 75 ohm coaxial cable TV plant. Leaving "4G" 
>> and various forms of fixed point to multipoint wireless, whether LTE 
>> based or not, as the only viable residential and SMB broadband service 
>> option.
> 
> And this is a bad thing, because?
> 
> Just because it is done differently doesn't mean it is any less 
> effective. Mobile phones have significantly overtaken all other forms 
> of physical infrastructure in most of Africa, and the amount of data 
> being generated as well as the growing rate of penetration is some of 
> the highest in the world.
> 
> MNO's have taken slightly different approaches to how they build and 
> scale for Africa (and other developing continents such as Asia) than 
> they have for other regions of the world where physical infrastructure 
> is more rife.
> 
> Personally, I'm glad that the remaining bits of copper plant in Africa 
> are losing steam as folk jump straight into 3G/4G and fibre in Africa.
> Coax was never really a hit in Africa (I know it was in Mozambique), 
> but glad we don't have to deal with that legacy either.
> 
> I am fortunate enough to live in a city where 4G/LTE is available, 
> with a reasonably-priced 100Mbps FTTH service to my house, as do many 
> others that live in major African cities where private companies are 
> not sitting around waiting for the gubbermint to catch up. Is there a 
> lot more that can and should be done? For sure! But things are happening...
> 
> Mark.
E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

RE: Geolocation issue with a twist

[McBride, Mack]

Send them an email at the listed email address.
Geolocation is always a pain.
It can take months to get it straight.

Mack
Contractor


-Original Message-
From: NANOG [mailto:nanog-bounces+c-mack.mcbride=charter@nanog.org] On 
Behalf Of Clay Stewart
Sent: Wednesday, May 23, 2018 8:50 AM
To: nanog@nanog.org
Subject: Re: Geolocation issue with a twist

 Yes, I can't find a way to contact the Geolocation eurkapi to get this 
removed, and I have to move two multi-million dollar businesses to this subnet 
like last month but afraid of impacts on their operations from email 
servers, web servers, and VOIP.  And of course, Pandora for music to their 
employees, which we know fails to work due to this issue.


On Wed, May 23, 2018 at 8:33 AM, Mike Hammett  wrote:

> Well that's lovely..,
>
> Our site is temporarily unavailable
> Please contact us at  contact...@eurekapi.com
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> --
> *From: *"Clay Stewart" 
> *To: *nanog@nanog.org
> *Sent: *Tuesday, May 22, 2018 10:39:38 PM
> *Subject: *Re: Geolocation issue with a twist
>
>
> https://scsbroadband.com/geolocation/
>
> Here is snapshot of Geolocation issue showing a Spanish ISP registered 
> with a GeoLocation database our IP block, pointed to the correct 
> location. But customers are getting railroaded with spam and failing apps 
> (due to Spain).
>
> On Tue, May 22, 2018 at 4:50 PM, Clay Stewart 
> 
> wrote:
>
> > Can someone point me for help with the following issue?
> >
> > I purchased a /24 late last year on auction which was originally 
> > owned by Cox communications in Europe. It had Geolocation in a lot 
> > of bad places, and Cox got it 'cleared' up for me.
> >
> > But there is still one issue, an ISP in Spain has it in a Geo 
> > database which is pointed to my correct location, but because it is 
> > a Spain ISP,
> the
> > block has lots of issues in block apps and redirects to spam sites.
> >
> > Attach is a snapshot with the incorrect ISP highlight and Geo 
> > database. I cannot get any info from the Geo database.
> >
> > I am new to this list, so I hope this is an appropriate question.
> >
>
>
E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

AS 205869 - BGP hijacking source

[McBride, Mack]

I am sending this notification as I have become aware that 205869 appears to be 
performing BGP hijacking and spoofing AS paths as well.
Impacted organizations may wish to contact the upstream providers of this ASN.

Mack McBride
Contractor

The contents of this message are my own and are not the opinions or nor do they 
represent my employer.
E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.