Re: Hurricane Maria: Summary of communication status - and lack of

[Javier J]

This is great to hear Nicholas.

On Mon, Oct 2, 2017 at 5:55 PM, Nicholas Harland  wrote:

> Hi Sean,
>
> Thank you for all of your updates. I am just catching up on them because I
> only recently got back from the virgin islands. I am one of those
> volunteers working in the USVI. St John specifically. We are building out a
> wireless network, and had our first hotspot up in Cruz Bay 4 days after
> Maria, with connectivity to NPS/FEMA/Red Cross/St John Rescue/Fire/Police
> just a few days after that.
>
> If there are technical minded and physically able bodied people would like
> to join the effort on St John, even just for a 1-2 week rotation, I would
> be happy to discuss what we need in terms of support and can make all
> arrangements on the island for housing etc. Getting some relief and fresh
> minds in would be a great help as our team is primarily St John residents
> who have been on the island through both hurricanes and have had to deal
> with their own personal situations while also trying to get internet up
> where it's needed.
>
> St John was hit directly by Irma, infrastructure was completely destroyed,
> but it's a very small island and so the humanitarian situation there is
> much more stable than Puerto Rico, but many of the resources that were
> assisting on STJ are now rightfully being diverted to SJU. You could expect
> to sleep somewhere that has a generator running overnight, have access to
> refrigeration/freezer (though cannot open fridge during day). Food/water
> situation is fine there, we have a beach volleyball game on Sundays, more
> generators are appearing on the island and some businesses are opening.
>
> Regards,
>
> Nick Harland
>
>
>
>
> On Sun, Sep 24, 2017 at 2:13 PM, Sean Donelan  wrote:
>
> > On Sun, 24 Sep 2017, Mike Hammett wrote:
> >
> >> There are a bunch of WISPs waiting to go rebuild, but waiting for the
> >> clearance to do so.
> >>
> >
> > I'm not sure what clearances they are waiting for.  If they are already
> in
> > Puerto Rico, self-sufficient, and respect curfews and other emergency
> > responders, they should be able to start local restoration and recovery
> > activities.
> >
> > Several local ISPs and communication providers have announced open public
> > WiFi hotspots outside their Puerto Rico offices during non-curfew hours.
> > I've also seen reports from individuals volunteering on the Virigin
> Islands
> > setting up internet access.
> >
> > If they are not already on the island, most Puerto Rican airports and
> > ports are still closed to non-military or relief activities. There is no
> > U.S. mail or freight service. Only one airport was open for limited
> > commercial flights.  They will need to bring everything neccessary to
> > support themselves, including food, water, shelter, etc.
> >
> > Managing volunteers who want to help is difficult in all disasters.
> Unless
> > they have training how to survive and take care of themselves in such a
> > situation, letting in outside well-meaning volunteers sometimes become
> > additional people who need to rescue.
> >
> > WISPs already on Puerto Rico or U.S. Virigin Islands, with resources for
> > recovery and restoration of communications; can contact the FCC
> Operations
> > Center, (202) 418-1122, fccoperationcen...@fcc.gov
> >
> > http://transition.fcc.gov/Daily_Releases/Daily_Business/2017
> > /db0920/DA-17-913A1.pdf
> >
> >
>

Re: Question about Customer Population by ASN for Canada

[Randy Bush]

> Labs.APNIC has a pretty cool system to measure this kind of stuff by
> deploying specially crafted google ads, see "How Big is that Network?"

which should have been titled "how many eyeballs in that network"

Re: Question about Customer Population by ASN for Canada

[Geoff Huston]

> On 3 Oct 2017, at 7:17 am, Eric Dugas  wrote:
> 
> For some reason my previous email was empty.
> 
> What I wrote:
> 
> "Some of these numbers are largely inflated...
> 
> e.g. Teksavvy at 937,855 estimated users. How can they have 937,855 users
> if they "only" have 686,848 IPv4 (https://bgp.he.net/AS5645)?
> 
> Also, Allstream/Zayo AS15290 has a lot of IPs but it's mostly corps/govs.
> So it's a mix of inflated and false positives.

I wish there was better public data we could use here to generate these numbers.

But there is a dearth of such numbers that are vaguely current relatively 
inclusive
and not completely stupid.

So we use the ad placement mechanism as an indirect pointer to user count. Its 
very rough,
and at best one can say that there are large, medium and small eyeball 
networks, and
to a first order the algorithm appears to identify networks into these three 
categories.

I am not trying to tie in address density here - I’m not even sure that would 
be wise
because, as you well know, NATs hide all kinds of sins and virtues.

Geoff

Re: Hurricane Maria: Summary of communication status - and lack of

[Nicholas Harland]

Hi Sean,

Thank you for all of your updates. I am just catching up on them because I
only recently got back from the virgin islands. I am one of those
volunteers working in the USVI. St John specifically. We are building out a
wireless network, and had our first hotspot up in Cruz Bay 4 days after
Maria, with connectivity to NPS/FEMA/Red Cross/St John Rescue/Fire/Police
just a few days after that.

If there are technical minded and physically able bodied people would like
to join the effort on St John, even just for a 1-2 week rotation, I would
be happy to discuss what we need in terms of support and can make all
arrangements on the island for housing etc. Getting some relief and fresh
minds in would be a great help as our team is primarily St John residents
who have been on the island through both hurricanes and have had to deal
with their own personal situations while also trying to get internet up
where it's needed.

St John was hit directly by Irma, infrastructure was completely destroyed,
but it's a very small island and so the humanitarian situation there is
much more stable than Puerto Rico, but many of the resources that were
assisting on STJ are now rightfully being diverted to SJU. You could expect
to sleep somewhere that has a generator running overnight, have access to
refrigeration/freezer (though cannot open fridge during day). Food/water
situation is fine there, we have a beach volleyball game on Sundays, more
generators are appearing on the island and some businesses are opening.

Regards,

Nick Harland




On Sun, Sep 24, 2017 at 2:13 PM, Sean Donelan  wrote:

> On Sun, 24 Sep 2017, Mike Hammett wrote:
>
>> There are a bunch of WISPs waiting to go rebuild, but waiting for the
>> clearance to do so.
>>
>
> I'm not sure what clearances they are waiting for.  If they are already in
> Puerto Rico, self-sufficient, and respect curfews and other emergency
> responders, they should be able to start local restoration and recovery
> activities.
>
> Several local ISPs and communication providers have announced open public
> WiFi hotspots outside their Puerto Rico offices during non-curfew hours.
> I've also seen reports from individuals volunteering on the Virigin Islands
> setting up internet access.
>
> If they are not already on the island, most Puerto Rican airports and
> ports are still closed to non-military or relief activities. There is no
> U.S. mail or freight service. Only one airport was open for limited
> commercial flights.  They will need to bring everything neccessary to
> support themselves, including food, water, shelter, etc.
>
> Managing volunteers who want to help is difficult in all disasters. Unless
> they have training how to survive and take care of themselves in such a
> situation, letting in outside well-meaning volunteers sometimes become
> additional people who need to rescue.
>
> WISPs already on Puerto Rico or U.S. Virigin Islands, with resources for
> recovery and restoration of communications; can contact the FCC Operations
> Center, (202) 418-1122, fccoperationcen...@fcc.gov
>
> http://transition.fcc.gov/Daily_Releases/Daily_Business/2017
> /db0920/DA-17-913A1.pdf
>
>

Re: Question about Customer Population by ASN for Canada

[Geoff Huston]

> On 3 Oct 2017, at 6:57 am, Jacques Latour  wrote:
> 
> Hi all!
> 
> I'm working on our IPv6 and DNSSEC adoption report for Canada and the data I 
> use comes largely from APNIC (https://stats.labs.apnic.net/dnssec/CA) and 
> (https://stats.labs.apnic.net/ipv6/CA).
> 
> Labs.APNIC has a pretty cool system to measure this kind of stuff by 
> deploying specially crafted google ads, see "How Big is that Network?"  
> https://labs.apnic.net/?p=526, and APNIC is able to assess the population 
> behind a network based on ad placement distribution. See 
> https://stats.labs.apnic.net/cgi-bin/aspop?c=CA for Canada.
> 
> The question I have is why does OVH come #6 with an estimated population of 
> 1,480,927 behind its ASN? Remember these are actual placement of ads.  Should 
> I count those users as part of my stats?
> 
> RankASN AS Name CC  Users (est.)% of country% of Internet 
>   Samples
> 1   AS812   ROGERS-CABLE - Rogers Cable Communications Inc. 
> CA 5,420,034   16.72 
>   0.16555,718
> 2   AS577   BACOM - Bell Canada 
> CA 4,474,012   13.8  
>   0.132   458,722
> 3   AS6327  SHAW - Shaw Communications Inc. 
> CA 3,708,414   11.44 
>   0.109   380,225
> 4   AS852   ASN852 - TELUS Communications Inc.  
> CA 2,914,405   8.99  
>   0.086   298,815
> 5   AS5769  VIDEOTRON - Videotron Telecom Ltee  
> CA 2,189,946   6.76  
>   0.065   224,536
> 6   AS16276 OVH CA   
>   1,480,927   4.570.044   151,840
> 7   AS15290 ALLST-15290 - Allstream Corp.   
> CA 1,272,374   3.93  
>   0.038   130,457
> 8   AS855   CANET-ASN-4 - Bell Aliant Regional Communications, Inc. 
> CA 1,211,485   3.74  
>   0.036   124,214
> 9   AS7992  COGECOWAVE - Cogeco Cable   
> CA 1,112,002   3.43  
>   0.033   114,014
> 10  AS5645  TEKSAVVY - TekSavvy Solutions, Inc. 
> CA 967,401 2.980.029 
>   99,188
> 11  AS11260 EASTLINK-HSI - EastLink 
> CA 695,598 2.150.021 
>   71,320
> 12  AS47027 SEASIDE-COMM - Seaside Communications, Inc. 
> CA 425,561 1.310.013 
>   43,633
> 13  AS803   SASKTEL - Saskatchewan Telecommunications   
> CA 392,186 1.210.012 
>   40,211
> 14  AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD.   
> CA 370,348 1.140.011 
>   37,972


Let me explain our system in a little more detail.

When we serve an ad we note the origin AS of the Ad. Now we assume (probably 
wrongly but we have no better data) that the ad’s are smeared evenly across the 
user population of each country. So we assume that the relative weight of ad 
placement within an AS is proportionate to the relative number of users in that 
same country. So if AS 131072 receives 50% of the Ads in a country then we 
assume that AS131072 holds one half of the number of users of the same country. 
Thats the first piece of data and the first assumption

The second assumption is that your government is not lying! That means that 
whatever stats your government lodged with the ITU-T relating to the number of 
Internet users in your country we believe. (and we actually use the world 
population data to update these numbers to represent the estimated user 
population today.)

Mashing the two togeether gives the table per country that you are citing here.

So your question is “:Why is Google delivering 4.57% of the ads in Canada into 
a network ASN that is the ASN registered against OVH”

OVH is an overlay network, but its certainly clear that it is used by a lot of 
folk and Google appear to find their users to be an attractive target to ad 
placement. So we get a high placement count of Ads coming from OVH and we 
geolocate those users to CA. Maybe there is a geolocation issue and IVH should 
not be CA. Of there really are a lot of eyeballs behind OVH in Canada.

regards,

   Geoff

Re: Hurricane Maria: Summary of communication status - and lack of

[Sean Donelan]

On Mon, 2 Oct 2017, Sean Donelan wrote:

On Sun, 1 Oct 2017, valdis.kletni...@vt.edu wrote:

I haven't seen any reports of a Teamster union refusal. I *have* seen
reports that only 10-30% of truck drivers are operational, because of
one or more of:


You're lucky. The bots have been pushing this very hard for several days. I 
don't know the local context or groups involved. There are at least two 
different groups


Snopes has published an article debunking this.  But bots are still 
pushing it.



Did Puerto Rico's Teamsters Union Go on Strike During Hurricane Maria 
Relief Efforts?
Reports that truck drivers are on strike in Puerto Rico are false -- 
Teamsters have asked mainland truckers to distribute supplies in the U.S. 
territory.


http://www.snopes.com/puerto-rico-teamsters/

RE: Question about Customer Population by ASN for Canada

[Jacques Latour]

Right, forgot to mention, it's population, not IP addresses, the average is 2.2 
person / household in Canada I believe.

> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Harald
> Koch
> Sent: October 2, 2017 4:34 PM
> To: NANOG list 
> Subject: Re: Question about Customer Population by ASN for Canada
> 
> On 2 October 2017 at 16:17, Eric Dugas 
> wrote:
> >
> >
> > e.g. Teksavvy at 937,855 estimated users. How can they have 937,855
> > users if they "only" have 686,848 IPv4 (https://bgp.he.net/AS5645)?
> >
> 
> I have one IPv4 and five users in my household...
> 
> --
> Harald
> (teksavvy customer)

Re: Question about Customer Population by ASN for Canada

[Harald Koch]

On 2 October 2017 at 16:17, Eric Dugas  wrote:
>
>
> e.g. Teksavvy at 937,855 estimated users. How can they have 937,855 users
> if they "only" have 686,848 IPv4 (https://bgp.he.net/AS5645)?
>

I have one IPv4 and five users in my household...

-- 
Harald
(teksavvy customer)

Re: Question about Customer Population by ASN for Canada

[Eric Dugas]

For some reason my previous email was empty.

What I wrote:

"Some of these numbers are largely inflated...

e.g. Teksavvy at 937,855 estimated users. How can they have 937,855 users
if they "only" have 686,848 IPv4 (https://bgp.he.net/AS5645)?

Also, Allstream/Zayo AS15290 has a lot of IPs but it's mostly corps/govs.
So it's a mix of inflated and false positives.

Eric"

Eric

On October 2, 2017 at 4:15:53 PM, Filip Hruska (f...@fhrnet.eu) wrote:

Hi,

There are various reasons that might be causing this:
* Lots of VPNs on OVH network
* OVH offers "desktop-as-a-service" and from what I understand it's
quite popular
* OVH is also a home ISP - just in France though; but not sure if/how
APNIC separated OVH as an ISP and OVH as a server provider.
I think it's all under the same ASN (might be wrong though)
* There are some scrapers on the OVH network - definitely not half a
million though


Best Regards,
Filip Hruska

Dne 10/2/17 v 22:05 Stephen Fulton napsal(a):
> Hi Jack,
>
> As OVH is a data centre, I find that extraordinary if eyeballs were
> the cost.  VPN's may be popular but that seems excessive. Probably
> bots of some sort, scraping the internet.
>
> -- Stephen
>
> On 2017-10-02 3:57 PM, Jacques Latour wrote:
>> Hi all!
>>
>> I'm working on our IPv6 and DNSSEC adoption report for Canada and the
>> data I use comes largely from APNIC
>> (https://stats.labs.apnic.net/dnssec/CA) and
>> (https://stats.labs.apnic.net/ipv6/CA).
>>
>> Labs.APNIC has a pretty cool system to measure this kind of stuff by
>> deploying specially crafted google ads, see "How Big is that
>> Network?"  https://labs.apnic.net/?p=526, and APNIC is able to assess
>> the population behind a network based on ad placement distribution.
>> See https://stats.labs.apnic.net/cgi-bin/aspop?c=CA for Canada.
>>
>> The question I have is why does OVH come #6 with an estimated
>> population of 1,480,927 behind its ASN? Remember these are actual
>> placement of ads.  Should I count those users as part of my stats?
>>
>> RankASN AS Name CC  Users (est.)% of country % of
>> Internet   Samples
>> 1   AS812   ROGERS-CABLE - Rogers Cable Communications Inc.
>> CA 5,420,034
>> 16.72   0.16555,718
>> 2   AS577   BACOM - Bell Canada
>> CA 4,474,012
>> 13.80.132   458,722
>> 3   AS6327  SHAW - Shaw Communications Inc.
>> CA 3,708,414
>> 11.44   0.109   380,225
>> 4   AS852   ASN852 - TELUS Communications Inc.
>> CA 2,914,405
>> 8.990.086   298,815
>> 5   AS5769  VIDEOTRON - Videotron Telecom Ltee
>> CA 2,189,946
>> 6.760.065   224,536
>> 6   AS16276 OVH
>> CA 1,480,927
>> 4.570.044   151,840
>> 7   AS15290 ALLST-15290 - Allstream Corp.
>> CA 1,272,374
>> 3.930.038   130,457
>> 8   AS855   CANET-ASN-4 - Bell Aliant Regional Communications,
>> Inc. CA
>> 1,211,485   3.740.036   124,214
>> 9   AS7992  COGECOWAVE - Cogeco Cable
>> CA 1,112,002
>> 3.430.033   114,014
>> 10  AS5645  TEKSAVVY - TekSavvy Solutions, Inc.
>> CA 967,401 2.98
>> 0.029   99,188
>> 11  AS11260 EASTLINK-HSI - EastLink
>> CA 695,598 2.15
>> 0.021   71,320
>> 12  AS47027 SEASIDE-COMM - Seaside Communications, Inc.
>> CA 425,561 1.31
>> 0.013   43,633
>> 13  AS803   SASKTEL - Saskatchewan Telecommunications
>> CA 392,186 1.21
>> 0.012   40,211
>> 14  AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD.
>> CA 370,348 1.14
>> 0.011   37,972
>>
>> Jack
>>
>>
>>
>>
>

-- 
Best Regards,
Filip Hruska
Linux System Administrator

Re: Question about Customer Population by ASN for Canada

[Filip Hruska]

Hi,

There are various reasons that might be causing this:
* Lots of VPNs on OVH network
* OVH offers "desktop-as-a-service" and from what I understand it's 
quite popular
* OVH is also a home ISP - just in France though; but not sure if/how 
APNIC separated OVH as an ISP and OVH as a server provider.

I think it's all under the same ASN (might be wrong though)
* There are some scrapers on the OVH network - definitely not half a 
million though



Best Regards,
Filip Hruska

Dne 10/2/17 v 22:05 Stephen Fulton napsal(a):

Hi Jack,

As OVH is a data centre, I find that extraordinary if eyeballs were 
the cost.  VPN's may be popular but that seems excessive. Probably 
bots of some sort, scraping the internet.


-- Stephen

On 2017-10-02 3:57 PM, Jacques Latour wrote:

Hi all!

I'm working on our IPv6 and DNSSEC adoption report for Canada and the 
data I use comes largely from APNIC 
(https://stats.labs.apnic.net/dnssec/CA) and 
(https://stats.labs.apnic.net/ipv6/CA).


Labs.APNIC has a pretty cool system to measure this kind of stuff by 
deploying specially crafted google ads, see "How Big is that 
Network?"  https://labs.apnic.net/?p=526, and APNIC is able to assess 
the population behind a network based on ad placement distribution. 
See https://stats.labs.apnic.net/cgi-bin/aspop?c=CA for Canada.


The question I have is why does OVH come #6 with an estimated 
population of 1,480,927 behind its ASN? Remember these are actual 
placement of ads.  Should I count those users as part of my stats?


Rank    ASN AS Name CC  Users (est.)    % of country % of 
Internet   Samples
1   AS812   ROGERS-CABLE - Rogers Cable Communications Inc. 
CA 5,420,034   
16.72   0.16    555,718
2   AS577   BACOM - Bell Canada 
CA 4,474,012   
13.8    0.132   458,722
3   AS6327  SHAW - Shaw Communications Inc. 
CA 3,708,414   
11.44   0.109   380,225
4   AS852   ASN852 - TELUS Communications Inc. 
CA 2,914,405   
8.99    0.086   298,815
5   AS5769  VIDEOTRON - Videotron Telecom Ltee 
CA 2,189,946   
6.76    0.065   224,536
6   AS16276 OVH 
CA 1,480,927   
4.57    0.044   151,840
7   AS15290 ALLST-15290 - Allstream Corp. 
CA 1,272,374   
3.93    0.038   130,457
8   AS855   CANET-ASN-4 - Bell Aliant Regional Communications, 
Inc. CA 
1,211,485   3.74    0.036   124,214
9   AS7992  COGECOWAVE - Cogeco Cable 
CA 1,112,002   
3.43    0.033   114,014
10  AS5645  TEKSAVVY - TekSavvy Solutions, Inc. 
CA 967,401 2.98    
0.029   99,188
11  AS11260 EASTLINK-HSI - EastLink 
CA 695,598 2.15    
0.021   71,320
12  AS47027 SEASIDE-COMM - Seaside Communications, Inc. 
CA 425,561 1.31    
0.013   43,633
13  AS803   SASKTEL - Saskatchewan Telecommunications 
CA 392,186 1.21    
0.012   40,211
14  AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 
CA 370,348 1.14    
0.011   37,972


Jack








--
Best Regards,
Filip Hruska
Linux System Administrator

Re: Question about Customer Population by ASN for Canada

[Grzegorz Janoszka]

On 2017-10-02 21:57, Jacques Latour wrote:

The question I have is why does OVH come #6 with an estimated population of 
1,480,927 behind its ASN? Remember these are actual placement of ads.  Should I 
count those users as part of my stats?


I would say VPN - OVH has cheap servers and is quite popular in this 
industry. There are countries where many active users have to use a sort 
of VPN to access banned sites.


So they are users, but rather not from Canada.

--
Grzegorz Janoszka

Re: Question about Customer Population by ASN for Canada

[Eric Dugas]

Re: Question about Customer Population by ASN for Canada

[Stephen Fulton]

Hi Jack,

As OVH is a data centre, I find that extraordinary if eyeballs were the 
cost.  VPN's may be popular but that seems excessive.  Probably bots of 
some sort, scraping the internet.


-- Stephen

On 2017-10-02 3:57 PM, Jacques Latour wrote:

Hi all!

I'm working on our IPv6 and DNSSEC adoption report for Canada and the data I 
use comes largely from APNIC (https://stats.labs.apnic.net/dnssec/CA) and 
(https://stats.labs.apnic.net/ipv6/CA).

Labs.APNIC has a pretty cool system to measure this kind of stuff by deploying specially 
crafted google ads, see "How Big is that Network?"  
https://labs.apnic.net/?p=526, and APNIC is able to assess the population behind a 
network based on ad placement distribution. See 
https://stats.labs.apnic.net/cgi-bin/aspop?c=CA for Canada.

The question I have is why does OVH come #6 with an estimated population of 
1,480,927 behind its ASN? Remember these are actual placement of ads.  Should I 
count those users as part of my stats?

RankASN AS Name CC  Users (est.)% of country% of Internet   
Samples
1   AS812   ROGERS-CABLE - Rogers Cable Communications Inc. 
CA 5,420,034   16.72   
0.16555,718
2   AS577   BACOM - Bell Canada 
CA 4,474,012   13.8
0.132   458,722
3   AS6327  SHAW - Shaw Communications Inc. 
CA 3,708,414   11.44   
0.109   380,225
4   AS852   ASN852 - TELUS Communications Inc.  
CA 2,914,405   8.99
0.086   298,815
5   AS5769  VIDEOTRON - Videotron Telecom Ltee  
CA 2,189,946   6.76
0.065   224,536
6   AS16276 OVH CA 
1,480,927   4.570.044   151,840
7   AS15290 ALLST-15290 - Allstream Corp.   
CA 1,272,374   3.93
0.038   130,457
8   AS855   CANET-ASN-4 - Bell Aliant Regional Communications, Inc. 
CA 1,211,485   3.74
0.036   124,214
9   AS7992  COGECOWAVE - Cogeco Cable   
CA 1,112,002   3.43
0.033   114,014
10  AS5645  TEKSAVVY - TekSavvy Solutions, Inc. 
CA 967,401 2.980.029   
99,188
11  AS11260 EASTLINK-HSI - EastLink 
CA 695,598 2.150.021   
71,320
12  AS47027 SEASIDE-COMM - Seaside Communications, Inc. 
CA 425,561 1.310.013   
43,633
13  AS803   SASKTEL - Saskatchewan Telecommunications   
CA 392,186 1.210.012   
40,211
14  AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD.   
CA 370,348 1.140.011   
37,972

Jack

Question about Customer Population by ASN for Canada

[Jacques Latour]

Hi all!

I'm working on our IPv6 and DNSSEC adoption report for Canada and the data I 
use comes largely from APNIC (https://stats.labs.apnic.net/dnssec/CA) and 
(https://stats.labs.apnic.net/ipv6/CA).

Labs.APNIC has a pretty cool system to measure this kind of stuff by deploying 
specially crafted google ads, see "How Big is that Network?"  
https://labs.apnic.net/?p=526, and APNIC is able to assess the population 
behind a network based on ad placement distribution. See 
https://stats.labs.apnic.net/cgi-bin/aspop?c=CA for Canada.

The question I have is why does OVH come #6 with an estimated population of 
1,480,927 behind its ASN? Remember these are actual placement of ads.  Should I 
count those users as part of my stats?

RankASN AS Name CC  Users (est.)% of country% of Internet   
Samples
1   AS812   ROGERS-CABLE - Rogers Cable Communications Inc. 
CA 5,420,034   16.72   
0.16555,718
2   AS577   BACOM - Bell Canada 
CA 4,474,012   13.8
0.132   458,722
3   AS6327  SHAW - Shaw Communications Inc. 
CA 3,708,414   11.44   
0.109   380,225
4   AS852   ASN852 - TELUS Communications Inc.  
CA 2,914,405   8.99
0.086   298,815
5   AS5769  VIDEOTRON - Videotron Telecom Ltee  
CA 2,189,946   6.76
0.065   224,536
6   AS16276 OVH CA 
1,480,927   4.570.044   151,840
7   AS15290 ALLST-15290 - Allstream Corp.   
CA 1,272,374   3.93
0.038   130,457
8   AS855   CANET-ASN-4 - Bell Aliant Regional Communications, Inc. 
CA 1,211,485   3.74
0.036   124,214
9   AS7992  COGECOWAVE - Cogeco Cable   
CA 1,112,002   3.43
0.033   114,014
10  AS5645  TEKSAVVY - TekSavvy Solutions, Inc. 
CA 967,401 2.980.029   
99,188
11  AS11260 EASTLINK-HSI - EastLink 
CA 695,598 2.150.021   
71,320
12  AS47027 SEASIDE-COMM - Seaside Communications, Inc. 
CA 425,561 1.310.013   
43,633
13  AS803   SASKTEL - Saskatchewan Telecommunications   
CA 392,186 1.210.012   
40,211
14  AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD.   
CA 370,348 1.140.011   
37,972

Jack

Re: isp/cdn caching

[Mike Hammett]

*nods* I'm obviously a bit biased, but I have some reasoning behind it. Also, 
this is excluding large scale networks like Comcast, AT, Charter, etc. that 
do have the scale to have on-net solutions. It's also excluding remote 
locations where there may not be another node for hundreds or thousands of 
miles (Alaska, Hawaii, Caribbean, etc.) 

There are some CDNs that are pushing out on-net boxes and PNIs to networks with 
relatively low usage. We've had networks that were in the process of joining 
the IX get approached by one of the CDNs for a box right on their network. That 
network had under 1G of usage (IIRC) and was joining an IX where the CDN was 
already present. The network declined the box because they didn't want 
something else to manage and would already get the service anyway once on the 
IX. 

Also, from my understanding of multiple CDNs (nothing really proprietary, just 
whatever's been made public) is that different nodes have different content. 
The more traffic a node gets, the more likely they are to have the content the 
end user seeks. Some CDNs also have different platforms on different boxes. If 
an ISP has one box, they may not even have access to all of the platforms that 
would be available in a several box deployment. In these cases, an IX makes 
more sense. 

We've also had CDNs go the PNI route to a network. Sure, a PNI beats an IX in 
that it cuts out a middle man (fiscally and point of failure). However, if the 
networks wouldn't use a substantial portion of the IX port in the first place, 
it's an extra cost that small networks may not have room for or have to choose 
between a PNI and an IX. 


Per the last message, Cloudflare seems to have a similar philosophy. Join 
existing infrastructure where it makes sense, deploy additional nodes 
otherwise. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Tom Paseka via NANOG"  
To: "Marco Slater"  
Cc: "NANOG list"  
Sent: Monday, October 2, 2017 1:21:10 PM 
Subject: Re: isp/cdn caching 

Hi, 

Cloudflare does deploy caches, however we usually look to do so in unique 
locations, ie. where an ISPs network isn't already in reach of one of our 
existing deployments/peering points. 

You can email peer...@cloudflare.com directly if seeking this. 

-Tom 

On Fri, Sep 29, 2017 at 7:22 AM, Marco Slater  wrote: 

> Do they publicly have any more info on this? 
> 
> I thought CloudFlare didn’t consider doing that because of their vast 
> coverage and peering arrangements provided by their PoPs. 
> 
> Regards, 
> Marco Slater 
> 
> > On 29 Sep 2017, at 14:38,  < 
> michalis.bersi...@hq.cyta.gr> wrote: 
> > 
> > I think that Cloudflare has a caching solution, but I think they have 
> strict requirements towards the isp in order to install them on their 
> premises. 
> > 
> > Best Regards, 
> > 
> > Michalis Bersimis 
> > 
> > -Original Message- 
> > From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Aaron Gould 
> > Sent: Thursday, September 28, 2017 6:25 PM 
> > To: Nanog@nanog.org 
> > Subject: isp/cdn caching 
> > 
> > Hi, I've been aware of a few caching providers for a few years now, but 
> I'm learning of others as time goes on. which makes me curious if there are 
> more springing up and gaining popularity. I'm speaking of ISP-type caching 
> whereas the cache provider sends hardware servers and perhaps a switch to 
> the local ISP to install locally in their network. Can someone please send 
> a simple list of what they know is the current players in this ISP Caching 
> space? I'll list the ones I know about and you please let me know of 
> others. This seems to be an evolving/growing thing and I'm curious of 
> where we are today for significant providers and possibly up-and-coming 
> ones that I should know about. (amazon prime has my wondering also.) 
> > 
> > 
> > 
> > Google (GGC) 
> > 
> > Netflix (OCA) 
> > 
> > Akamai (AANP) 
> > 
> > Facebook (FNA) 
> > 
> > Apple (I heard this isn't isp-located like the others, but unsure) 
> > 
> > ? others ? 
> > 
> > ? others ? 
> > 
> > ? others ? 
> > 
> > 
> > 
> > -Aaron Gould 
> > 
> 
> 

Re: isp/cdn caching

[Tom Paseka via NANOG]

Hi,

Cloudflare does deploy caches, however we usually look to do so in unique
locations, ie. where an ISPs network isn't already in reach of one of our
existing deployments/peering points.

You can email peer...@cloudflare.com directly if seeking this.

-Tom

On Fri, Sep 29, 2017 at 7:22 AM, Marco Slater  wrote:

> Do they publicly have any more info on this?
>
> I thought CloudFlare didn’t consider doing that because of their vast
> coverage and peering arrangements provided by their PoPs.
>
> Regards,
> Marco Slater
>
> > On 29 Sep 2017, at 14:38,  <
> michalis.bersi...@hq.cyta.gr> wrote:
> >
> > I think that Cloudflare has a caching solution, but I think they have
> strict requirements towards the isp in order to install them on their
> premises.
> >
> > Best Regards,
> >
> > Michalis Bersimis
> >
> > -Original Message-
> > From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Aaron Gould
> > Sent: Thursday, September 28, 2017 6:25 PM
> > To: Nanog@nanog.org
> > Subject: isp/cdn caching
> >
> > Hi, I've been aware of a few caching providers for a few years now, but
> I'm learning of others as time goes on. which makes me curious if there are
> more springing up and gaining popularity.  I'm speaking of ISP-type caching
> whereas the cache provider sends hardware servers and perhaps a switch to
> the local ISP to install locally in their network.  Can someone please send
> a simple list of what they know is the current players in this ISP Caching
> space?  I'll list the ones I know about and you please let me know of
> others.  This seems to be an evolving/growing thing and I'm curious of
> where we are today for significant providers and possibly up-and-coming
> ones that I should know about.  (amazon prime has my wondering also.)
> >
> >
> >
> > Google (GGC)
> >
> > Netflix (OCA)
> >
> > Akamai (AANP)
> >
> > Facebook (FNA)
> >
> > Apple (I heard this isn't isp-located like the others, but unsure)
> >
> > ? others ?
> >
> > ? others ?
> >
> > ? others ?
> >
> >
> >
> > -Aaron Gould
> >
>
>

Re: Hurricane Maria: Summary of communication status - and lack of

[Sean Donelan]

On Sun, 1 Oct 2017, valdis.kletni...@vt.edu wrote:

I haven't seen any reports of a Teamster union refusal. I *have* seen
reports that only 10-30% of truck drivers are operational, because of
one or more of:


You're lucky. The bots have been pushing this very hard for several days. 
I don't know the local context or groups involved. There are at least two 
different groups


1. Frente Amplio de Camioneros led by Victor Rodriguez

There are a couple of videos of interviews with Mr. Rodriguez. Like many 
people in Puerto Rico, Mr. Rodriguez is very upset. I don't know him well 
enough to understand if those videos were in the heat of the moment, or 
accurately reflect what's happening.



2. Union de Tronquistas de Puerto Rico local 901 afiliada I.B.T. led by 
Alexis Rodriguez


The AFL-CIO teamsters put out a statement today:
https://teamster.org/news/2017/10/teamsters-denounce-false-reports-work-stoppage-union-drivers-puerto-rico


Some of the re-posts are using a partial quote from Colonel Michael A. 
Valle, responsible for military logistics in Puerto Rico, that only 20% 
of the drivers are showing up for work. What the re-posts omitted is the 
rest of Col. Valle's quote:


“There should be zero blame on the drivers. They can’t get to work, the 
infrastructure is destroyed, they can’t get fuel themselves, and they 
can’t call us for help because there’s no communication. The will of the 
people of Puerto Rico is off the charts. The truck drivers have families 
to take care of, many of them have no food or water. They have to take 
care of their family’s needs before they go off to work, and once they do 
go, they can’t call home.”


http://www.huffingtonpost.com/entry/us-military-on-puerto-rico-the-problem-is-distribution_us_59ce5906e4b0f3c468060dee


In a disaster situation, even simple problems become much more 
complicated.  Just as important during a disaster, don't attribute to 
malice what could be a misunderstanding or communication problem. People 
in the disaster zone are under a lot of stress.

Re: Long BGP AS paths

[Tim Evens]

Yikes, my bad. In the CSV file it didn't seem so large. I setup a
dashboard where you can browse the longest as paths for the selected
time period. check out
demo-rv.snas.io:3000/dashboard/db/top-as-paths?orgId=2 [3]. Change the
time range to see those longer paths. They are no longer current in the
last hour since cogent filtered them. 

--Tim 

On 01.10.2017 14:29, Tim Evens wrote: 

> The outliers are >100. Based on several peering points, <= 60 should be
> fine. See attached CSV file that shows the top 120 distinct AS Paths
> seen for the past month. Looks like 55644 likes to prepend a lot which
> is pushing the length above 50. 
> 
> --Tim 
> 
> On 01.10.2017 09:16, marcel.duregards--- via NANOG wrote:
> What would be a recommended value for a maximum as-path filter ? 50 ? On the 
> DFZ I've only 11 prefixes longer than 30 as-path, so for safety I would also 
> assume 50 as a max is well enough. Any advice ? Regards, - Marcel On 
> 01.10.2017 00:29, William Herrin wrote: To the chucklehead who started 
> announcing a 2200+ byte AS path yesterday around 18:27 EDT, I beg of you: 
> STOP. You've triggered a bug in Quagga that's present in all versions 
> released in the last decade. Your announcement causes routers based on Quagga 
> to send a malformed update to their neighbors, collapsing the entire BGP 
> session. Every 30 seconds or so. For everyone else: please consider filtering 
> BGP announcements with stupidly long AS paths. There's no need nor excuse for 
> them to be present in the DFZ and you could have saved me a painful Saturday. 
> Cisco: router bgp XXX bgp maxas-limit 50 Juniper: 
> https://kb.juniper.net/InfoCenter/index?page=content=KB29321 [1] [1] 
> Quagga: ip as-path access-list maxas-limit50 deny
^([{},0-9]+ ){50} ip as-path access-list maxas-limit50 permit .* Regards, Bill 
Herrin .

Links:
--
[1] https://kb.juniper.net/InfoCenter/index?page=contentid=KB29321
[2]



Links:
--
[1] https://kb.juniper.net/InfoCenter/index?page=contentid=KB29321
[2]
https://kb.juniper.net/InfoCenter/index?page=contentamp;id=KB29321
[3] demo-rv.snas.io:3000/dashboard/db/top-as-paths?orgId=2

Which one(s) of SWIP, RWhois, RDAP? (Fwd: [ARIN-consult] NEW Consultation: Available Methods of Reporting Network Sub-Delegation Information)

[John Curran]

NANOGers!

Apologies (as some of you have already seen this) but it has more relevance
to network operations than most IP number policy matters, so out of 
avoidance
of any doubt, I call this to your attention.

ARIN has opened a community consultation on the question of which methods
for reporting network sub-delegations should be supported by ARIN.   If you 
have
views on this matter, please read the attached and take the time to comment 
on
the arin-consult mailing list (which is the mailing list which ARIN uses 
for discussion
of community suggestions & consultations and is open to the public.)

Thanks!
/John

John Curran
President and CEO
ARIN


Begin forwarded message:

From: ARIN >
Subject: [ARIN-consult] NEW Consultation: Available Methods of Reporting 
Network Sub-Delegation Information
Date: 2 October 2017 at 8:19:36 AM PDT
To: >


ARIN was previously requested via the ARIN Consultation and Suggestion Process 
(ACSP) to open a consultation to generate discussion about the possibility of 
sun-setting RWhois support by the ARIN organization. ARIN's initial response to 
the ACSP indicated we would open a consultation following the completion of the 
Registration Data Access Protocol (RDAP) specification inside the IETF 
processes. This work has been completed and the RFC has been published. ARIN 
took the additional step of implementing RDAP inside its own directory services 
offering with referral support to the other Regional Internet Registries 
(RIRs). With this work complete, we are following through with the formalized 
request to open a consultation on this topic.

https://www.arin.net/participate/acsp/suggestions/2013-22.html

In accordance with ARIN's Number Resource Policy Manual (NRPM), Organizations 
are required to report certain types of customer network sub-delegation 
information (reassignments and reallocations) to ARIN. Currently there are two 
reporting methods available. Both are delineated in the NRPM and supported by 
ARIN's production services. There is also a third possible method of reporting 
sub-delegation information that could be made available, but is not yet offered.

Method 1:

SWIP (currently available):  The reporting of sub-delegation information using 
ARIN's database. This can be done either by submitting a SWIP template, 
interfacing with ARIN's RESTful API, or by creating a sub-delegation inside 
ARIN Online using ARIN's SWIP-EZ functionality.

https://www.arin.net/resources/request/reassignments.html

Method 2:

RWhois (currently available):  The reporting of sub-delegation information on 
your own hosted and operated RWhois server with referral link information 
provided in ARIN Whois as part of your own organization's Whois records. In 
order for a user of ARIN's directory services to view sub-delegation 
information hosted by an RWhois server, they would have to submit a separate 
query to that RWhois server, and are not referred in an automated fashion.

https://www.arin.net/resources/request/reassignments_rwhois.html

Method 3:

RDAP:  The five RIRs currently use RDAP for referrals to each other's Whois 
data. Although the specification language of the RDAP could allow it to be used 
as a third method for the reporting of sub-delegation information to ARIN, it 
is not currently offered as an option. In order to make this option available, 
associated registry software would need to be created. This possible method 
would allow users of ARIN's directory services to view sub-delegation 
information available on customer hosted RDAP servers in an automated fashion. 
This RDAP method may also be viewed as redundant to RWhois.

https://tools.ietf.org/html/rfc7482
https://www.arin.net/resources/rdap.html

Options Going Forward

ARIN expects to continue offering Method 1 (SWIP) into the foreseeable future. 
As previously described, we are acting on a formal suggestion to consult with 
the community about the future of RWhois support, and also have potential 
options with RDAP.

  *   Question (general):

Of the three sub-delegation reporting methods listed (SWIP, RWhois, 
RDAP), which should ARIN support in the future?

  *   Question (SWIP/RESTful API specific):

The existing RESTful API allows users to report (SWIP) one 
sub-delegation at a time to be added to ARIN Whois. ShouldARIN add 
bulk-upload features to the RESTful API?

  *   Question (RWhois specific):

 As noted, RWhois servers are not referred to in an automated fashion 
when users query ARIN Whois. Should ARIN   automate referrals to RWhois servers 
from ARIN's Whois service?

  *   Question (RDAP specific):

If ARIN was to allow the reporting of network sub-delegation 
information using RDAP, associated enabling software would be required. Should 
ARIN enable this method by creating an RDAP software suite that would allow 
ARIN registrants to 

Re: AS PATH limits

[Ken Chase]

Got this reply from cogent:

"We have isolated a BGP Routing discrepancy on the Backbone. That routing has 
been removed 
from the Network."

So apparently they agree they shouldn't just accept this bogosity. Good on em.

/kc
-- 
Ken Chase - m...@sizone.org Guelph Canada

Re: Hurricane Maria: Summary of communication status - and lack of

[Jean-Francois Mezei]

On 2017-10-02 02:58, Wayne Bouchard wrote:
> Well, that's why recovery efforts in broad scale events like this have
> to go from a central point to pushing a perimiter farther and farther
> out. Create a habital, functional zone where workers can return to
> both to organize and recouperate and then go back out and push farther
> afield. 


Logic yes. But...

I have read stories of sick people in shelters dying because of lack of
electricity, lack of O2. Stories of FEMA sending water/food for only
half of population of a village.

This is where telecom plays a role.

If the shelter had comms, it could have told mayor "we need generator,
we need 5 tabks of O2 for sick people". Mayor could have sent request to
FEMA ASAP. My **guess** is that by the time FEMA got the requests, it
was too late  and people died.

In hindsight, every village should have been given a sat-phone BEFORE
the hurricane,

Ajit Pai complained about iPhone not having FM radio. But it is more
important for reverse communication from villages to headquarters/FEMA
to be able to transmit urgent needs, status reports, how much food/water
needed etc.

I suspect that if such comms had happened right off the bat, they would
have known that waiting for roads to be cleared wasn't sufficient and
taken a different philosophy for immediate help.

I think that disaster planners have made wrong assumptions about
cellular and terrestrial communications being robust enough to survive
cyclones.

Re: AS PATH limits

[Jörg Kost]

Its also happily announced onwards, e.g. by Telia:

Oct  2 07:25:09:E:BGP: From Peer ... received Long AS_PATH= AS_SEQ(2) 
1299 174 262206 262206 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 262197 
262197 262197 262197 262197 262197 262197 262197 262197 262197 ... 
attribute length (567) More than configured MAXAS-LIMIT 64


On 30 Sep 2017, at 17:09, sth...@nethelp.no wrote:

If you're on cogent, since 22:30 UTC yesterday or so this has been 
happening

(or happened).


Still happening here. I count 562 prepends (563 * 262197) in the
advertisement we receive from Cogent. I see no good reason why we
should accept that many prepends.

Steinar Haug, Nethelp consulting, sth...@nethelp.no

Re: AS PATH limits

[Baldur Norddahl]

Den 2. okt. 2017 00.44 skrev "Randy Bush" :

looks to me as if 262206 is trying a silly tactic to down-pref inbound
from cogent.  as cogent probably prefers customers to peers, it may not
be working as 262206 expected, so they keep pounding with the same
hammer hoping for a miracle.

cogent accepts it as they are being paid to do so; normal practice.

perhaps our ire should be directed at 262206, not cogent?  has anyone
tried to contact them?

randy


It is amazing how well the DFZ works given half the participants (*) have
no clue how. If that is what they want, all they need is to split that /23
into two /24 and only announce that on their other transit.

(*) I should probably include myself in that half.

Regards

Baldur

Re: Hurricane Maria: Summary of communication status - and lack of

[Wayne Bouchard]

Well, that's why recovery efforts in broad scale events like this have
to go from a central point to pushing a perimiter farther and farther
out. Create a habital, functional zone where workers can return to
both to organize and recouperate and then go back out and push farther
afield. First restoring main arteries (whether that is in the form of
roads, electrical dstribution, communications, water, or sewer) and
then branch out from there. All of that takes time. It does no good,
afterall, to repair the services in a neighborhood if the feeds into
that neighborhood aren't going to be functional for weeks.

And always remember that the first duty is to life and limb. The rest
is of far less importance until that situation has been stabilized.

On Mon, Oct 02, 2017 at 12:56:56AM -0400, Jean-Francois Mezei wrote:
> On 2017-10-02 00:32, Javier J wrote:
> 
> > I hope they do. There doesn't seem to be a shortage of FEMA, Army, etc
> > personnel on the ground or a shortage of truck drivers in the US willing to
> > help. If 80% of Truck drivers that pick up containers from the ports can't
> > make it, then this needs to be supplemented any way possible to get things
> > moving.
> 
> 
> When disaster is in focused area (Like Houston), truck drivers can
> easily return to functional cities after delivering goods to the diaster
> zone (so not a strain on food/lodging in diaster zone).
> 
> If you bring truck drivers (and telecom, electrical etc) workiers into
> Puerto Rico, they can't go home every night, so become a strain on
> shelter/food resources.
> 
> And you can't "steal" your local workers if they are busy pickup up
> their belongings from collapsed homes, waiting in long queues for food
> and caring for their families.
> 
> In 1998 Ice Storm, Bombardier in Montr??al had full power and got a lot
> of bad publicity when it threatened to fire employees who didn't show up
> for work. Seesm like mamnagement lived in areas that had power and
> didn't realise how life changes when you have no power,  queue up for
> wood provided by city etc. (and that is nothing compared to what people
> on Puerto Rico are dealing with).

---
Wayne Bouchard
w...@typo.org
Network Dude
http://www.typo.org/~web/