Re: Colo in Africa

[Mark Tinka]

On 17/Jul/19 00:57, Sina Owolabi wrote:
> If Nigeria is a possible location, you have a few, off the top of my
> head is any telco's colo (MTN, Airtel, Glo, or 9Mobile), and there's
> RackCentre, MainOne and I think IPNX for colo (virtual and bare
> metal).

My concern about Nigeria is co-lo that isn't carrier-neutral.

AFAIK, Medallion come close to being carrier-neutral, but then bandwidth
pricing into the country becomes an issue at scale.

Mark.

Re: Performance metrics used in commercial BGP route optimizers

[Hank Nussbacher]

On 16/07/2019 20:41, Job Snijders wrote:
On Tue, Jul 16, 2019 at 3:33 PM Mike Hammett > wrote:


More like do whatever you want in your own house as long as you
don't infringe upon others.


That's where the rub is; when using "BGP optimisers" to influence 
public Internet routing, you cannot guarantee you won't infringe upon 
others.


The argument against route optimizers (assuming appropriate
ingress\egress filters) is a religious one and should be treated
as such.

There is a difference between BGP optimizers and route optimizers.  When 
was the last time you heard a complain about Akamai screwing up the 
global routing table over the past 12 years:


https://www.akamai.com/us/en/about/news/press/2007-press/akamai-introduces-advanced-communications-protocol-for-accelerating-dynamic-applications.jsp

https://developer.akamai.com/legacy/learn/Optimization/SureRoute.html

-Hank

Ztomy.com again?

[Patrick]

Anyone else seeing DNS oddities from info.net / infonet.com ?

fwdrev() {
  for ip in `dig +short A $1 @$2`; do
echo $ip `dig +short -x $ip @$2`
  done
}

fwdrev smtp.microsoft.com 8.8.8.8
131.107.115.215 smtp.microsoft.com. mailb.microsoft.com. mail2.microsoft.com.
131.107.115.214 mailc.microsoft.com. mail3.microsoft.com. smtp.microsoft.com.
205.248.106.64 ns1327.ztomy.com.
205.248.106.30 ns1327.ztomy.com.
205.248.106.32 ns1327.ztomy.com.
131.107.115.212 smtp.microsoft.com. mail1.microsoft.com.

fwdrev smtp.microsoft.com 1.1.1.1
205.248.106.30 ns1327.ztomy.com.
205.248.106.32 ns1327.ztomy.com.
205.248.106.64 ns1327.ztomy.com.
131.107.115.212 smtp.microsoft.com. mail1.microsoft.com.
131.107.115.214 mailc.microsoft.com. smtp.microsoft.com. mail3.microsoft.com.
131.107.115.215 mailb.microsoft.com. smtp.microsoft.com. mail2.microsoft.com.


dig +trace -x 205.248.106.30
...

248.205.in-addr.arpa.   86400   IN  NS  dns1.info.net.
248.205.in-addr.arpa.   86400   IN  NS  dns1.infonet.com.
248.205.in-addr.arpa.   86400   IN  NS  dnseur.info.net.
;; Received 360 bytes from 193.0.9.10#53(arin.authdns.ripe.net) in 179 ms

30.106.248.205.in-addr.arpa. 300 IN PTR ns1327.ztomy.com.
;; Received 86 bytes from 208.91.197.27#53(dns1.infonet.com) in 217 ms



Patrick

Re: Colo in Africa

[Ken Gilmour]

I feel like I'm arguing with my teenager over why the WiFi is slow.

Re: Colo in Africa

[Mike Hammett]

But cloud all of the things!! 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Seth Mattinen"  
To: nanog@nanog.org 
Sent: Tuesday, July 16, 2019 6:45:35 PM 
Subject: Re: Colo in Africa 

On 7/16/19 4:30 PM, Ken Gilmour wrote: 
> TBs of data is not really that much data on average when you average it 
> over thousands of customers. The data is summarized, There are a ton of 
> other things happening in the background that I've already explained in 
> the thread and are really irrelevant to the task at hand which is 
> finding a facility in Africa that does Bare Metal servers. I've had a 
> lot of helpful people, despite the naysayers. 
> 


I did find all of the "why not cloud" responses disappointing when you 
asked for colo of servers. On this list I would assume someone asking 
for a specific thing knows why they want it. 

Re: Colo in Africa

[Eric Kuhnke]

Without being more specific on what geographic region you want to serve, in
terms of ISPs, it's hard to say.

For example:

If you look at submarine cable topology at layer 1, and BGP sessions, AS
adjacencies between ISPs: Freetown, Sierra Leone and Monrovia, Liberia are
suburbs of London, UK.

If you want to reach major things in the west african region the two best
connected places are Accra, Ghana and Lagos, Nigeria.

On the other hand, if you put equipment topologically close to the cable
landing station in Accra it will have rather poor connectivity to the east
side of Africa. It's a big place and there is very little cross-continent
connectivity that doesn't take the long way around via submarine fiber to
Cape Town, and then up the east coast.


On Tue, Jul 16, 2019 at 7:34 AM Ken Gilmour  wrote:

> Hi Folks,
>
> I work for a Security Analytics org and we're looking to build a small POP
> in Africa. I am pretty clueless about the region so I was wondering if you
> could help guide me in the right direction for research?
>
> The challenges:
>
>1. Network needs to be able to receive millions of small PPS (as
>opposed to serving smaller numbers of larger files).
>2. Can't be cloud (need bare metal servers / colo). We use the full
>capacity of each server, all the time.
>3. Must have good connectivity to most of the rest of Africa
>4. We can initially only have one POP
>
> This is not like a normal website that we can just host on "any old
> provider", the requirements are very different.
>
> Is there a good location where we could either rent bare metal servers
> (something like Internap - preferred) or colocate servers within Africa
> that can serve most of the region?
>
> "Good" is defined as an area with stable connectivity and power, no legal
> restrictions on things like encryption, and good latency (sub 100ms) to the
> rest of Africa.
>
> Our two closest POPs are in Singapore and The Netherlands, so I'd like
> something closer to the middle that can serve the rest of Africa. Middle
> East will be deployed after Africa.
>
> I hope this is the right place to ask.
>
> Thanks!
>
> Ken
>

Re: Performance metrics used in commercial BGP route optimizers

[Christopher Morrow]

On Tue, Jul 16, 2019 at 5:22 PM Nick Hilliard  wrote:
>
> Oh I don't know about that.  There's been a pile of high profile
> incidents which have been associated with "BGP optimisers", affecting
> connectivity to huge chunks of the internet, world-wide.

How many, exactly and with a pointer/reference, have been 'not an optimizer' ?
I almost made the same post as Mr Hammett ~4 messages (his messages)
back made: "Err, all of these problems are possible without an
optimizer", except I don't really believe that it's helpful:

 "All my friends failed out, but I just got D's..."

isn't really selling this as a great plan.
I suppose if your (not nick's) story is:
   "Well, I know what I'm doing, my upstreams filter me, I'd NEVER leak..."

ok, but really no, not ok... someone 'not you' will eventually operate
part of your network and fail where you hadn't.

-chris

Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

[Christopher Morrow]

On Tue, Jul 16, 2019 at 6:28 PM Dan Hollis  wrote:
>
> On Tue, 16 Jul 2019, Michael Thomas wrote:
> > But right you are, it's ultimately the carrier who needs to care about this
> > problem at or nothing gets better.
>
> either the carrier starts dealing with it or legislation will come down to
> force the issue.

It's 2019 right? This has been happening since
~1996

Re: Colo in Africa

[Joel M Snyder]

Ken:

>Is there a good location where we could either rent bare metal servers
>(something like Internap - preferred) or colocate servers within
>Africa that can serve most of the region?

Africa is a tough nut to crack.  I have been building networks there for 
clients for decades and the first thing to understand is that Africa is 
BIG.  Geographically, you can fit the US, Europe, and Canada (and have 
room to spare).  Typical Mercator maps make it look much smaller than it 
really is.  Anyway, my point here is that you should not be thinking 
about Africa as "a region" or "a continent."


When a lot of people say "Africa," they really mean "South Africa" (the 
small country), and there is great connectivity there---but positioning 
yourself in South Africa doesn't really help you any more to get to 
Ghana (for example) than being in the Netherlands.


If you really are thinking AFRICA as in AFRICA, you probably should use 
an approach that divides it into regions.  You can break it up however 
you want, but if you start with 4 regions (Southern, Northern, Western, 
Eastern/Central) you'll have chunks that actually hold together from a 
telecoms point of view pretty well.


My best experiences (and these are about 3 years out of date) have been 
in Jo'burg (Southern), Nairobi/Addis (Eastern/Central), Ghana (Western), 
and Egypt (Northern), but there is a lot of interest and a lot of 
progress so getting some ground knowledge would be a good idea.


The real bandwidth is submarine cables that go up and down the coasts 
--- you can find some maps of these of varying accuracy and quality --- 
while actual E/W and N/S connectivity in the center of the continent is 
much more limited.


There are a number of Internet-promoting organizations in Africa---you 
can start with ISOC and Afrinic that sponsor a number of projects aimed 
at increasing capacity there, but you'll find a bunch of people trying 
to do good things.  If you are mostly interested in South Africa, 
there's NAPAfrica and SAFNOG (Southern African equivalent of NANOG) as 
information sources.


Anyway: I can get more specific, but it's hard to really offer 
super-specific advice on a vague question because, you know, Africa. 
That's a big topic.


jms


--
Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
Senior Partner, Opus One   Phone: +1 520 324 0494
j...@opus1.comhttp://www.opus1.com/jms

Re: Colo in Africa

[Valdis Klētnieks]

On Tue, 16 Jul 2019 15:54:10 -0600, Ken Gilmour said:

> We have a different use case to traditional analytics - We're aimed at
> consumers and small businesses, so instead of a SOC with one big screen
> refreshing 1 rows of only alert data every 30 seconds, we have
> thousands of individuals refreshing all of their data every 30 seconds
> because there are comparatively less alerts for individuals than
> enterprises.

Plenty of room for lots of optimizations there, especially in conjunction
with some client-side caching.  If they're generating enough *new* events
every 30 seconds to cause any significant load, they're either in the middle
of a major event (something that shouldn't happen too often)  or they have
the logging is set to be so verbose that they're likely to miss actual important
messages.


pgpBsYa0nzNW2.pgp
Description: PGP signature

Re: Colo in Africa

[Seth Mattinen]

On 7/16/19 4:30 PM, Ken Gilmour wrote:
TBs of data is not really that much data on average when  you average it 
over thousands of customers. The data is summarized, There are a ton of 
other things happening in the background that I've already explained in 
the thread and are really irrelevant to the task at hand which is 
finding a facility in Africa that does Bare Metal servers. I've had a 
lot of helpful people, despite the naysayers.





I did find all of the "why not cloud" responses disappointing when you 
asked for colo of servers. On this list I would assume someone asking 
for a specific thing knows why they want it.

Re: Colo in Africa

[Ken Gilmour]

TBs of data is not really that much data on average when  you average it
over thousands of customers. The data is summarized, There are a ton of
other things happening in the background that I've already explained in the
thread and are really irrelevant to the task at hand which is finding a
facility in Africa that does Bare Metal servers. I've had a lot of helpful
people, despite the naysayers.

Thanks!

On Tue, 16 Jul 2019 at 11:23, Valdis Klētnieks 
wrote:

> On Tue, 16 Jul 2019 10:39:59 -0600, Ken Gilmour said:
>
> > These are actual real problems we face. thousands of customers load and
> > reload TBs of data every few seconds on their dashboards.
>
> If they're reloading TBs of data every few seconds, you really should have
> been
> doing summaries during data ingestion and only reloading the summaries.
> (Overlooking the fact that for dashboards, refreshing every few seconds is
> usually pointless because you end up looking at short-term statistical
> spikes
> rather than anything that you can react to at human speeds.  If you *care*
> in
> real time that the number of probes on a port spiked to 457% of average
> for 2
> seconds you need to be doing automated responses
>
> Custom queries are more painful - but those don't happen "every few
> seconds".
>

Re: Colo in Africa

[Sina Owolabi]

If Nigeria is a possible location, you have a few, off the top of my
head is any telco's colo (MTN, Airtel, Glo, or 9Mobile), and there's
RackCentre, MainOne and I think IPNX for colo (virtual and bare
metal).

On Tue, Jul 16, 2019 at 11:48 PM Ken Gilmour  wrote:
>
> What matters is whether or not we can get a facility in Africa to provide 
> service to our customers from Bare Metal Servers :)
>
> On Tue, 16 Jul 2019 at 16:07, C. A. Fillekes  wrote:
>>
>> Are they refreshing data they've already got, though?
>> This is the classic use case for client-side caching.
>>
>> On Tue, Jul 16, 2019 at 5:56 PM Ken Gilmour  wrote:
>>>
>>> We have a different use case to traditional analytics - We're aimed at 
>>> consumers and small businesses, so instead of a SOC with one big screen 
>>> refreshing 1 rows of only alert data every 30 seconds, we have 
>>> thousands of individuals refreshing all of their data every 30 seconds 
>>> because there are comparatively less alerts for individuals than 
>>> enterprises.
>>>
>>> What you "should" do often doesn't translate to what you "do" do.
>>>
>>> On Tue, 16 Jul 2019 at 11:23, Valdis Klētnieks  
>>> wrote:

 On Tue, 16 Jul 2019 10:39:59 -0600, Ken Gilmour said:

 > These are actual real problems we face. thousands of customers load and
 > reload TBs of data every few seconds on their dashboards.

 If they're reloading TBs of data every few seconds, you really should have 
 been
 doing summaries during data ingestion and only reloading the summaries.
 (Overlooking the fact that for dashboards, refreshing every few seconds is
 usually pointless because you end up looking at short-term statistical 
 spikes
 rather than anything that you can react to at human speeds.  If you *care* 
 in
 real time that the number of probes on a port spiked to 457% of average 
 for 2
 seconds you need to be doing automated responses

 Custom queries are more painful - but those don't happen "every few 
 seconds".



-- 

cordially yours,

Sina Owolabi

+2348176469061

Re: Colo in Africa

[Ken Gilmour]

What matters is whether or not we can get a facility in Africa to provide
service to our customers from Bare Metal Servers :)

On Tue, 16 Jul 2019 at 16:07, C. A. Fillekes  wrote:

> Are they refreshing data they've already got, though?
> This is the classic use case for client-side caching.
>
> On Tue, Jul 16, 2019 at 5:56 PM Ken Gilmour  wrote:
>
>> We have a different use case to traditional analytics - We're aimed at
>> consumers and small businesses, so instead of a SOC with one big screen
>> refreshing 1 rows of only alert data every 30 seconds, we have
>> thousands of individuals refreshing all of their data every 30 seconds
>> because there are comparatively less alerts for individuals than
>> enterprises.
>>
>> What you "should" do often doesn't translate to what you "do" do.
>>
>> On Tue, 16 Jul 2019 at 11:23, Valdis Klētnieks 
>> wrote:
>>
>>> On Tue, 16 Jul 2019 10:39:59 -0600, Ken Gilmour said:
>>>
>>> > These are actual real problems we face. thousands of customers load and
>>> > reload TBs of data every few seconds on their dashboards.
>>>
>>> If they're reloading TBs of data every few seconds, you really should
>>> have been
>>> doing summaries during data ingestion and only reloading the summaries.
>>> (Overlooking the fact that for dashboards, refreshing every few seconds
>>> is
>>> usually pointless because you end up looking at short-term statistical
>>> spikes
>>> rather than anything that you can react to at human speeds.  If you
>>> *care* in
>>> real time that the number of probes on a port spiked to 457% of average
>>> for 2
>>> seconds you need to be doing automated responses
>>>
>>> Custom queries are more painful - but those don't happen "every few
>>> seconds".
>>>
>>

Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

[Dan Hollis]

On Tue, 16 Jul 2019, Michael Thomas wrote:
But right you are, it's ultimately the carrier who needs to care about this 
problem at or nothing gets better.


either the carrier starts dealing with it or legislation will come down to 
force the issue.


-Dan

Re: SHAKEN/STIR Robocall Summit - July 11 2019 at FCC

[Michael Thomas]

On 7/15/19 12:07 PM, Jay R. Ashworth wrote:

- Original Message -

From: "Christopher Morrow" 
On Thu, Jul 11, 2019 at 12:00 PM Paul Timmins  wrote:

Chris it would be trivial for this to be fixed, nearly overnight, by
creating some liability on the part of carriers for illicit use of
caller ID data on behalf of their customers.

'illicit use of caller id' - how is caller-id being illicitly used though?
I don't think it's against the law to say a different 'callerid' in the call
session, practically every actual call center does this, right?

I can speak to that, having originated calls from a call center.

Yes, of course we sent out calls with "spoofed" CNID.

But, even though only 2 or 3 or our 5 carriers* held *our* feet to the fire,
we held the clients' feet to the fire, requiring them to prove to our
satisfaction that they had adminstrative control over the numbers in question.

But it's the carrier's responsibility, properly, to do that work.



How do the clients prove that?

Way back when when we were working on mipv6 we had to work through a 
somewhat similar problem for handoffs. The ultimate answer was a return 
routability test: that is, if you can answer on the address you're 
trying to claim "ownership" for, it's good enough.


Maybe such a thing can be done in for spoofing? Even out of band spot 
checking might be adequate to keep clients honest?


But right you are, it's ultimately the carrier who needs to care about 
this problem at or nothing gets better.


Mike

Re: Colo in Africa

[C. A. Fillekes]

Are they refreshing data they've already got, though?
This is the classic use case for client-side caching.

On Tue, Jul 16, 2019 at 5:56 PM Ken Gilmour  wrote:

> We have a different use case to traditional analytics - We're aimed at
> consumers and small businesses, so instead of a SOC with one big screen
> refreshing 1 rows of only alert data every 30 seconds, we have
> thousands of individuals refreshing all of their data every 30 seconds
> because there are comparatively less alerts for individuals than
> enterprises.
>
> What you "should" do often doesn't translate to what you "do" do.
>
> On Tue, 16 Jul 2019 at 11:23, Valdis Klētnieks 
> wrote:
>
>> On Tue, 16 Jul 2019 10:39:59 -0600, Ken Gilmour said:
>>
>> > These are actual real problems we face. thousands of customers load and
>> > reload TBs of data every few seconds on their dashboards.
>>
>> If they're reloading TBs of data every few seconds, you really should
>> have been
>> doing summaries during data ingestion and only reloading the summaries.
>> (Overlooking the fact that for dashboards, refreshing every few seconds is
>> usually pointless because you end up looking at short-term statistical
>> spikes
>> rather than anything that you can react to at human speeds.  If you
>> *care* in
>> real time that the number of probes on a port spiked to 457% of average
>> for 2
>> seconds you need to be doing automated responses
>>
>> Custom queries are more painful - but those don't happen "every few
>> seconds".
>>
>

Re: Colo in Africa

[Ken Gilmour]

We have a different use case to traditional analytics - We're aimed at
consumers and small businesses, so instead of a SOC with one big screen
refreshing 1 rows of only alert data every 30 seconds, we have
thousands of individuals refreshing all of their data every 30 seconds
because there are comparatively less alerts for individuals than
enterprises.

What you "should" do often doesn't translate to what you "do" do.

On Tue, 16 Jul 2019 at 11:23, Valdis Klētnieks 
wrote:

> On Tue, 16 Jul 2019 10:39:59 -0600, Ken Gilmour said:
>
> > These are actual real problems we face. thousands of customers load and
> > reload TBs of data every few seconds on their dashboards.
>
> If they're reloading TBs of data every few seconds, you really should have
> been
> doing summaries during data ingestion and only reloading the summaries.
> (Overlooking the fact that for dashboards, refreshing every few seconds is
> usually pointless because you end up looking at short-term statistical
> spikes
> rather than anything that you can react to at human speeds.  If you *care*
> in
> real time that the number of probes on a port spiked to 457% of average
> for 2
> seconds you need to be doing automated responses
>
> Custom queries are more painful - but those don't happen "every few
> seconds".
>

Re: Performance metrics used in commercial BGP route optimizers

[Nick Hilliard]

Oh I don't know about that.  There's been a pile of high profile 
incidents which have been associated with "BGP optimisers", affecting 
connectivity to huge chunks of the internet, world-wide.


It's not unusual for a single incident to have widespread or even global 
effect, and what with the Internet playing such an important part of the 
world's economies, it's hard not to be curious about the overall 
financial impact of this sort of thing.


Nick

Ryan Hamel wrote on 16/07/2019 19:10:

Nowhere near the number as an engineer fat fingering a route. There are ISPs 
that accept routes all the way to /32 or /128, for traffic engineering with 
ease, and/or RTBH.

Ryan

-Original Message-
From: NANOG  On Behalf Of Nick Hilliard
Sent: Tuesday, July 16, 2019 11:04 AM
To: Job Snijders 
Cc: NANOG 
Subject: Re: Performance metrics used in commercial BGP route optimizers

Job Snijders wrote on 16/07/2019 18:41:

I consider it wholly inappropriate to write-off the countless hours
spend dealing with fallout from "BGP optimizers" and the significant
financial damages we've sustained as "religious arguments".


it would be interesting to see research into the financial losses experienced 
by people and organisations across the internet caused by routing outages 
relating to bgp optimisers.

Nick

Re: Colo in Africa

[Hendrik Meyburgh]

I suggest you look at the Teraco facilities, specifically the JB1 (Isando)
site. It is extremely well connected and carrier-neutral so you can choose
who you want to use.

Depending on your requirement you might need to work through a reseller. I
work for an SP in South Africa, so let me know offline if you need any help.

On Tue, Jul 16, 2019 at 4:34 PM Ken Gilmour  wrote:

> Hi Folks,
>
> I work for a Security Analytics org and we're looking to build a small POP
> in Africa. I am pretty clueless about the region so I was wondering if you
> could help guide me in the right direction for research?
>
> The challenges:
>
>1. Network needs to be able to receive millions of small PPS (as
>opposed to serving smaller numbers of larger files).
>2. Can't be cloud (need bare metal servers / colo). We use the full
>capacity of each server, all the time.
>3. Must have good connectivity to most of the rest of Africa
>4. We can initially only have one POP
>
> This is not like a normal website that we can just host on "any old
> provider", the requirements are very different.
>
> Is there a good location where we could either rent bare metal servers
> (something like Internap - preferred) or colocate servers within Africa
> that can serve most of the region?
>
> "Good" is defined as an area with stable connectivity and power, no legal
> restrictions on things like encryption, and good latency (sub 100ms) to the
> rest of Africa.
>
> Our two closest POPs are in Singapore and The Netherlands, so I'd like
> something closer to the middle that can serve the rest of Africa. Middle
> East will be deployed after Africa.
>
> I hope this is the right place to ask.
>
> Thanks!
>
> Ken
>

Re: Colo in Africa

[Valdis Klētnieks]

On Tue, 16 Jul 2019 11:13:45 -0700, Seth Mattinen said:
> On 7/16/19 10:53 AM, Akshay Kumar via NANOG wrote:
> > Then you are "doing it wrong(tm). Good luck.
>
>
> Are you saying that anyone choosing not to use "the cloud" is simply
> wrong because "cloud" is always right?

No, he's saying that if you're data-mining the same terabytes of data
every few seconds, you're doing it wrong.



pgplS2m7aiqzN.pgp
Description: PGP signature

Re: Performance metrics used in commercial BGP route optimizers

[Job Snijders]

On Tue, Jul 16, 2019 at 01:24:11PM -0500, Mike Hammett wrote:
> All of the same tragedy can happen without BGP optimizers, and does. 

I disagree. You are skipping over crucial distinction we should make
between common 'route leaks' (incorrect propagation of valid routing
information), and the poison that is 'bgp optimiser hijacks'
(propagating of invalid/nonexistent routing information).

In the first case, a simple leak of existing real routing information,
you'll often see that the outcomes of the leak have a longer AS_PATH,
and that the leaking ASN has an actual path towards the destination. In
the best case the leaked routes are ignored because they don't become
the best path, in the worst case anyone using those leaked paths suffers
from congestion.

In the second case, leaked routes that came from a so-called 'bgp
optimiser', during the leak there is no forwarding path to the actual
destination. The packets circulate in a loop and never arrive at the
intended destination. This is hard downtime for the affected prefixes.
We also often see that the AS_PATH is entirely fabricated by "BGP
optimisers", further increasing the risk of the hijacked route
announcements being used.

> BGP optimizers only harm the global Internet when route filters don't
> do their job. (Un)Fortunately, many other things also harm the global
> Internet when route filters don't do their job. Things other than BGP
> optimizers harm the global Internet more frequently via the same
> vector (lack of proper route filters). 
> 
> A given set of bugs are unlikely to affect both Optimizer edge egress
> filters and upstream ingress filters. If so, the Internet as a whole
> has much graver things to worry about. 

I believe it is a fallacy to state that "because other things can harm
the Internet" it would be somehow become OK to use a BGP optimiser. It
is not, it is extremely dangerous for those networks whose prefixes are
being 'optimised' (née hijacked).

Every day we see negative effects as a result from "bgp optimizers". We
also have observed that some of the 'bgp optimizers' have consciously
chosen to not apply even the most basic of harm reduction methods, see
https://twitter.com/JobSnijders/status/1143205986787831819

We can't stop people from deploying this type of software, the Internet
simply doesn't provide that kind of regulatory environment, but one
should be fully aware of the terrible risks involved when doing so.
Networks should be cognizant of peers they suspect are using such
software to steer traffic.

Kind regards,

Job

Re: Performance metrics used in commercial BGP route optimizers

[Töma Gavrichenkov]

Peace,

On Tue, Jul 16, 2019, 9:24 PM Mike Hammett  wrote:

> BGP optimizers only harm the global Internet when route filters don't do
> their job. (Un)Fortunately, many other things also harm the global Internet
> when route filters don't do their job.
>

That is correct; however, there are potentially harmful things that cannot
easily be avoided (so we accept the risk), and optimizers are not among
those.

E.g. there are quite a number of things which could cause an airplane to
crash yet are still allowed onboard; but this alone isn't an argument
convincing enough to allow handguns there.

--
Töma

Re: Performance metrics used in commercial BGP route optimizers

[Mike Hammett]

All of the same tragedy can happen without BGP optimizers, and does. 

BGP optimizers only harm the global Internet when route filters don't do their 
job. (Un)Fortunately, many other things also harm the global Internet when 
route filters don't do their job. Things other than BGP optimizers harm the 
global Internet more frequently via the same vector (lack of proper route 
filters). 




A given set of bugs are unlikely to affect both Optimizer edge egress filters 
and upstream ingress filters. If so, the Internet as a whole has much graver 
things to worry about. 





- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Job Snijders"  
To: "Mike Hammett"  
Cc: "Töma Gavrichenkov" , "NANOG"  
Sent: Tuesday, July 16, 2019 12:41:13 PM 
Subject: Re: Performance metrics used in commercial BGP route optimizers 



On Tue, Jul 16, 2019 at 3:33 PM Mike Hammett < na...@ics-il.net > wrote: 





More like do whatever you want in your own house as long as you don't infringe 
upon others. 




That's where the rub is; when using "BGP optimisers" to influence public 
Internet routing, you cannot guarantee you won't infringe upon others. 





The argument against route optimizers (assuming appropriate ingress\egress 
filters) is a religious one and should be treated as such. 




The argument against "BGP optimizers" is that we *cannot* assume appropriate 
ingress or egress filters. It appears to me like fallacy to suggest a line of 
reasoning ala "if you do things correctly, things won't go wrong". Clearly 
we've observed many times over that things *do* go wrong. 


Some examples: almost every year one of the major BGP vendors has a serious bug 
related to the functionality to NO_EXPORT in some release. Also, routinely we 
observe there are software defects that cause a device to behave different 
(read 'leak') than how the operator had explicitly configured the device. These 
are facts, not religious statements. 


Perhaps in a bug-free world there is room for dangerous activities, but there 
is no such thing as bug-free. And I haven't even covered the human error angle. 
We must robustly architect our networks to mitigate or dampen the negative 
effects of issues at all layers of the stack. 


I consider it wholly inappropriate to write-off the countless hours spend 
dealing with fallout from "BGP optimizers" and the significant financial 
damages we've sustained as "religious arguments". 


Kind regards, 

Job 

Re: Performance metrics used in commercial BGP route optimizers

[Job Snijders]

On Tue, Jul 16, 2019 at 6:10 PM Ryan Hamel  wrote:
>
> Nowhere near the number as an engineer fat fingering a route.

How are you able to make that assertion?

> There are ISPs that accept routes all the way to /32 or /128, for traffic 
> engineering with ease, and/or RTBH.

This strikes me as a bit of a red herring. Aren't the damaging effects
of "BGP optimisers" *amplified* (not caused!) by ISPs who accept "all
routes"? An ISP accepting incorrect routing information still is a
step below entities actively generating and distributing incorrect
routing information.

Kind regards,

Job

Re: Performance metrics used in commercial BGP route optimizers

[Töma Gavrichenkov]

On Tue, Jul 16, 2019, 6:29 PM Mike Hammett  wrote:

> assuming appropriate ingress\egress filters
>

This assumption itself is a good start for the aforementioned "security
considerations" chapter, b/c this is the assumption most of us make but
only few routinely check.

--
Töma

Re: Colo in Africa

[Seth Mattinen]

On 7/16/19 10:53 AM, Akshay Kumar via NANOG wrote:

Then you are "doing it wrong(tm). Good luck.



Are you saying that anyone choosing not to use "the cloud" is simply 
wrong because "cloud" is always right?

RE: Performance metrics used in commercial BGP route optimizers

[Ryan Hamel]

Nowhere near the number as an engineer fat fingering a route. There are ISPs 
that accept routes all the way to /32 or /128, for traffic engineering with 
ease, and/or RTBH.

Ryan

-Original Message-
From: NANOG  On Behalf Of Nick Hilliard
Sent: Tuesday, July 16, 2019 11:04 AM
To: Job Snijders 
Cc: NANOG 
Subject: Re: Performance metrics used in commercial BGP route optimizers

Job Snijders wrote on 16/07/2019 18:41:
> I consider it wholly inappropriate to write-off the countless hours 
> spend dealing with fallout from "BGP optimizers" and the significant 
> financial damages we've sustained as "religious arguments".

it would be interesting to see research into the financial losses experienced 
by people and organisations across the internet caused by routing outages 
relating to bgp optimisers.

Nick

Re: Performance metrics used in commercial BGP route optimizers

[Nick Hilliard]

Job Snijders wrote on 16/07/2019 18:41:
I consider it wholly inappropriate to write-off the countless hours 
spend dealing with fallout from "BGP optimizers" and the significant 
financial damages we've sustained as "religious arguments".


it would be interesting to see research into the financial losses 
experienced by people and organisations across the internet caused by 
routing outages relating to bgp optimisers.


Nick

Re: Colo in Africa

[Akshay Kumar via NANOG]

Then you are "doing it wrong(tm). Good luck.

On Tue, Jul 16, 2019 at 5:40 PM Ken Gilmour  wrote:

> These are actual real problems we face. thousands of customers load and
> reload TBs of data every few seconds on their dashboards. We have busy
> servers. We tried cloud. I passionately hate it. We choose to use Bare
> Metal.
>
> On Tue, 16 Jul 2019 at 10:34, Akshay Kumar  wrote:
>
>> Go look at the actual specifications for one of the metal boxes - you are
>> not going to come close to maxing anything out with the workload you
>> describe. FSB hasn't been a thing in over a decade. If you really wanted to
>> go crazy you could do some build a custom solution in FPGA on the F1s.
>>
>> It's a moot point since none of this is going to be available in time but
>> perf is a bogus reason and a lot of the times price is too.
>>
>> On Tue, Jul 16, 2019 at 5:12 PM Ken Gilmour 
>> wrote:
>>
>>> Speed is not the issue, it's IO. Also streaming 100Gbps of video is very
>>> different to streaming 100Gbps of files smaller than 100kb (average of
>>> about 30kb) the issue on the network level is the number of connections and
>>> CPU, on the server side it's IO and FSB
>>>
>>> On Tue, 16 Jul 2019 at 08:55, Akshay Kumar  wrote:
>>>
 The 2nd requirement seems artificial. The new hypervisors have come a
 long way and the overhead is minimal. Also you can run bare metal instances
 in AWS if you really need them with 100Gbps.

 Just just use the South Africa AWS region.

 On Tue, Jul 16, 2019 at 3:35 PM Ken Gilmour 
 wrote:

> Hi Folks,
>
> I work for a Security Analytics org and we're looking to build a small
> POP in Africa. I am pretty clueless about the region so I was wondering if
> you could help guide me in the right direction for research?
>
> The challenges:
>
>1. Network needs to be able to receive millions of small PPS (as
>opposed to serving smaller numbers of larger files).
>2. Can't be cloud (need bare metal servers / colo). We use the
>full capacity of each server, all the time.
>3. Must have good connectivity to most of the rest of Africa
>4. We can initially only have one POP
>
> This is not like a normal website that we can just host on "any old
> provider", the requirements are very different.
>
> Is there a good location where we could either rent bare metal servers
> (something like Internap - preferred) or colocate servers within Africa
> that can serve most of the region?
>
> "Good" is defined as an area with stable connectivity and power, no
> legal restrictions on things like encryption, and good latency (sub 100ms)
> to the rest of Africa.
>
> Our two closest POPs are in Singapore and The Netherlands, so I'd like
> something closer to the middle that can serve the rest of Africa. Middle
> East will be deployed after Africa.
>
> I hope this is the right place to ask.
>
> Thanks!
>
> Ken
>

RE: Performance metrics used in commercial BGP route optimizers

[Michel Py]

> Tom Beecher wrote :
> The most important metric for a BGP optimizer is how much it physically 
> weighs. That way you'll know
> if you can carry it to the trash pile yourself, or need to get help so you 
> don't hurt your back.

Please dispose of it in an environment friendly way. In the city I live and 
many other ones we have programs to get rid of such garbage in a proper way.
https://www.roseville.ca.us/residents/utility_exploration_center/e-waste

Stop the pollution of the routing table and the planet !

> Mark Tinka wrote :
> So I got this from BGPmon, earlier today:

Oh yeah, a /32 sourced from a private ASN without no-export.

Michel

TSI Disclaimer:  This message and any files or text attached to it are intended 
only for the recipients named above and contain information that may be 
confidential or privileged. If you are not the intended recipient, you must not 
forward, copy, use or otherwise disclose this communication or the information 
contained herein. In the event you have received this message in error, please 
notify the sender immediately by replying to this message, and then delete all 
copies of it from your system. Thank you!...

Re: Performance metrics used in commercial BGP route optimizers

[Job Snijders]

On Tue, Jul 16, 2019 at 3:33 PM Mike Hammett  wrote:

> More like do whatever you want in your own house as long as you don't
> infringe upon others.
>

That's where the rub is; when using "BGP optimisers" to influence public
Internet routing, you cannot guarantee you won't infringe upon others.


> The argument against route optimizers (assuming appropriate ingress\egress
> filters) is a religious one and should be treated as such.
>

The argument against "BGP optimizers" is that we *cannot* assume
appropriate ingress or egress filters. It appears to me like fallacy to
suggest a line of reasoning ala  "if you do things correctly, things won't
go wrong". Clearly we've observed many times over that things *do* go wrong.

Some examples: almost every year one of the major BGP vendors has a serious
bug related to the functionality to NO_EXPORT in some release. Also,
routinely we observe there are software defects that cause a device to
behave different (read 'leak') than how the operator had explicitly
configured the device. These are facts, not religious statements.

Perhaps in a bug-free world there is room for dangerous activities, but
there is no such thing as bug-free. And I haven't even covered the human
error angle. We must robustly architect our networks to mitigate or dampen
the negative effects of issues at all layers of the stack.

I consider it wholly inappropriate to write-off the countless hours spend
dealing with fallout from "BGP optimizers" and the significant financial
damages we've sustained as "religious arguments".

Kind regards,

Job

Re: Colo in Africa

[Randy Bush]

[ there is an afnog mailing list which you might find useful ]

>3. Must have good connectivity to most of the rest of Africa

unfortunately, for common values of 'most' this is a long sad tragedy.
mark's excellent reccos can get you the fancy bits.  inter-connectivity
with africa is sad.

randy

Re: Performance metrics used in commercial BGP route optimizers

[Mark Tinka]

So I got this from BGPmon, earlier today:

*

You received this email because you are subscribed to BGPmon.net.
For more details about these updates please visit:
https://portal.bgpmon.net/myalerts.php


RPKI Validation Failed (Code: 9)

Your prefix:  105.16.0.0/12:
Prefix Description:   In case of abuse, please contact ab...@seacom.mu
Update time:  2019-07-16 15:45 (UTC)
Detected by #peers:   1
Detected prefix:  105.26.205.62/32
Announced by: AS65075 (-Private Use AS-)
Upstream AS:  AS53089 (IDC TELECOM LTDA EPP, BR)
ASpath:   53089 65075
Alert details:   
https://portal.bgpmon.net/alerts.php?details_id=89182454
Mark as false alert:  https://portal.bgpmon.net/fp.php?aid=89182454
RPKI Status:  ROA validation failed: Invalid Prefix-Length +
Invalid Origin ASN, expected 37100


 
--
 *for questions regarding the change code or other question, please see:
https://portal.bgpmon.net/faq.php


Latest BGPmon news: http://bgpmon.net/blog/
  * Popular Destinations rerouted to Russia
  * Today’s BGP leak in Brazil
  * BGP leak causing Internet outages in Japan and beyond.

.

*

See why we like (not!) BGP optimizers so much?

Mark.

Re: Colo in Africa

[Valdis Klētnieks]

On Tue, 16 Jul 2019 10:39:59 -0600, Ken Gilmour said:

> These are actual real problems we face. thousands of customers load and
> reload TBs of data every few seconds on their dashboards.

If they're reloading TBs of data every few seconds, you really should have been
doing summaries during data ingestion and only reloading the summaries.
(Overlooking the fact that for dashboards, refreshing every few seconds is
usually pointless because you end up looking at short-term statistical spikes
rather than anything that you can react to at human speeds.  If you *care* in
real time that the number of probes on a port spiked to 457% of average for 2
seconds you need to be doing automated responses

Custom queries are more painful - but those don't happen "every few seconds".


pgpzB88IGf2UQ.pgp
Description: PGP signature

Re: Colo in Africa

[Valdis Klētnieks]

On Tue, 16 Jul 2019 10:11:48 -0600, Ken Gilmour said:

> Speed is not the issue, it's IO. Also streaming 100Gbps of video is very
> different to streaming 100Gbps of files smaller than 100kb (average of
> about 30kb) the issue on the network level is the number of connections and
> CPU, on the server side it's IO and FSB

The trick is to realize that 100Gbps of files smaller than 100kb can be 
remodeled
as 12 Gigabytes/sec of random 128K writes into large files.

Which isn't even that hard with modern gear, especially if you have the budget
for SSDs.


pgp_ClsU_AeWC.pgp
Description: PGP signature

Re: Colo in Africa

[Mark Tinka]

On 16/Jul/19 19:00, Ken Gilmour wrote:

>
> Our "market" is actually the US - but we're experiencing unexpected
> success across the world. A lot of our customers have selected
> "Africa" as their region when signing up and they are in various
> countries around Africa, they deserve to be served better within their
> continent at least.

Makes sense.


>
> We can't actually build POPs fast enough, so I want to throw as broad
> a net as possible with our first POP in Africa and then branch out
> from there. We have customers in South Africa, Tanzania, Nigeria,
> Egypt, Morocco and Ghana for instance. I have resources for only one
> POP in Africa currently, need to decide where to best serve as many as
> possible. We could serve Northern Africa from EU and Southern Africa
> from Singapore, but having something within the continent would be
> preferable.

If you had to go with one PoP in Africa to start, then I'd suggest
Johannesburg. The data on your side should indicate that this is where
you have the majority of the targets. From here, you can get reasonably
well to all neighboring countries, i.e., Mozambique, Swaziland, Lesotho,
Botswana, Malawi, Zambia, Zimbabwe, Namibia and Angola. Farther afield,
you will have reasonable latency to East Africa as well, which will get
you Kenya, Uganda, Tanzania, Rwanda and Burundi.

Phase 2, I'd say deploy in Nairobi, which will lower your latency for
your targets there, and reduce your load in Johannesburg.

Phase 3, I'd say Accra or Lagos, but that won't be as straight forward.

If you're serious about this, I'd say come down to AfPIF
(https://www.afpif.org/) and SAFNOG (http://www.safnog.org/), both of
which will be happening 20th - 22nd and 26th - 28th, August,
respectively. You will learn a lot by attending both meetings, and since
they are back-to-back, between Mauritius and Johannesburg, it is easy to
do travel-wise.

Otherwise, happy to offline a discussion with you if you want some
mail-time with our Sales droids :-).

Mark.

Re: Colo in Africa

[Mark Tinka]

On 16/Jul/19 18:23, Joel Jaeggli wrote:
>
>
> 100ms from most of the rest of Africa is going to be a bit dubious. If
> you draw a line horizontally through Senegal the costal stuff north of
> it can mostly be served in under 100ms from Europe.
>
> While cross border terrestrial fiber exists most networks I’ve been
> exposed to have east west and north south connectivity Via submarine
> connected networks.  This make it hard to locate one low latency spot
> in the middle.

Terrestrial capacity between most countries in Africa is too expensive,
not terribly good quality and not always the shortest path.

As Joel mentions, for the Eastern & Southern African coast, those
countries are connected by marine festoons, i.e., South Africa,
Mozambique, Tanzania, Kenya, Somalia, Djibouti and Egypt. You then get
terrestrial options running deeper into the hinterlands, and depending
on the region, the quality and price will vary.

On the west side, you can get marine festoons to South Africa, Namibia,
Angola, Nigeria, Ghana and Senegal. Pricing on that side will be a lot
higher because those have generally been club cables, unlike on the East
side where you have both club and private cables.

Just to give an idea about latency between some of the cities we operate
in Africa, have a look here:

    http://as37100.net/latencymatrix/

This should give you some idea of the problem.

Mark.

Re: Colo in Africa

[Mark Tinka]

On 16/Jul/19 17:28, Christopher Morrow wrote:

> Isn't the OP really asking here (not to have their selection of
> platform wrangled..):
>   "Where should I target my search: ZA only? is there anywhere else
> worth dropping my request?"

The easiest regions will be East (Kenya) and South (South Africa).


> and:
>   "Are there likely providers of solid colo aside from
> seacom/tinka-net or workonline/ben-net ?"

SEACOM and Workonline just do network.

For co-lo, we have solid operators in East and South:

  * Teraco - https://www.teraco.co.za/ - who will give you excellent
co-lo in Johannesburg, Cape Town and Durban.
  * iColo - https://www.icolo.io/ - who will give you excellent co-lo in
Mombasa. Nairobi is due to open by September this year.
  * Raxio - https://www.raxio.co.ug/ - who will give you excellent co-lo
in Kampala. Door open in December this year.

Teraco run NAPAfrica, which is Africa's largest exchange point by
traffic switched - https://www.napafrica.net/. They also have instances
of the INX-ZA exchange points, which are JINX (Johannesburg), DINX
(Durban) and CINX (Cape Town).

iColo will be deploying an instance of KIXP (Kenya IXP) -
https://www.tespok.co.ke/?page_id=11648 - and Asteroid -
https://www.asteroidhq.com/.

Raxio will also host an instance of the UIXP - https://www.uixp.co.ug/.

From a network standpoint, you have a few options:

  * SEACOM - AS37100
  * Workonline - AS37271
  * Liquid - AS30844
  * WIOCC - AS37662

These are the main network operators that run a good deal of network
between Europe, Eastern Africa, Southern Africa and parts of Asia-Pac.

Hope this helps.

Mark.

Re: Colo in Africa

[Ken Gilmour]

Hi Mark,

Our "market" is actually the US - but we're experiencing unexpected success
across the world. A lot of our customers have selected "Africa" as their
region when signing up and they are in various countries around Africa,
they deserve to be served better within their continent at least.

We can't actually build POPs fast enough, so I want to throw as broad a net
as possible with our first POP in Africa and then branch out from there. We
have customers in South Africa, Tanzania, Nigeria, Egypt, Morocco and Ghana
for instance. I have resources for only one POP in Africa currently, need
to decide where to best serve as many as possible. We could serve Northern
Africa from EU and Southern Africa from Singapore, but having something
within the continent would be preferable.

Thanks!

Ken

On Tue, 16 Jul 2019 at 10:52, Mark Tinka  wrote:

>
>
> On 16/Jul/19 16:33, Ken Gilmour wrote:
>
> Hi Folks,
>
> I work for a Security Analytics org and we're looking to build a small POP
> in Africa.
>
>
> Where, in Africa? It's not a small place...
>
>
>
>1. Network needs to be able to receive millions of small PPS (as
>opposed to serving smaller numbers of larger files).
>
>
> Depending on where in Africa you want to deploy, there will be a choice of
> service providers.
>
>
>
>1. Can't be cloud (need bare metal servers / colo). We use the full
>capacity of each server, all the time.
>
>
> This is possible, but will depend on where, in Africa, you want to deploy.
>
>
>
>1. Must have good connectivity to most of the rest of Africa
>
>
> This is a tricky one, but if you know where you want to be, it will help
> to give you options.
>
>
>
>1. We can initially only have one POP
>
>
> Not a problem, but where?
>
>
> This is not like a normal website that we can just host on "any old
> provider", the requirements are very different.
>
> Is there a good location where we could either rent bare metal servers
> (something like Internap - preferred) or colocate servers within Africa
> that can serve most of the region?
>
>
> Africa is huge, with varying levels of quality of connectivity. The 3 main
> regions are East Africa (Kenya leading), Southern Africa (South Africa
> leading) and West Africa (Nigeria and Ghana leading).
>
> For North Africa, your options can swing between Egypt and Morocco.
>
> But stringing all of these locations together, particularly West and North
> to East and South, will not be straight forward.
>
>
>
>
> "Good" is defined as an area with stable connectivity and power, no legal
> restrictions on things like encryption, and good latency (sub 100ms) to the
> rest of Africa.
>
>
> Yes, all 5 will be difficult at this point in time.
>
> For most of that, hosting within Eastern and Southern Africa will be your
> best bets.
>
> West Africa ticks a lot of the boxes, but it's not very straight forward
> when it comes to co-lo.
>
>
>
>
> Our two closest POPs are in Singapore and The Netherlands, so I'd like
> something closer to the middle that can serve the rest of Africa. Middle
> East will be deployed after Africa.
>
>
> Singapore is closer to Eastern & Southern Africa. Will be too far to West
> Africa unless you want to switch in Europe.
>
> The Netherlands is okay for all of Africa.
>
> The Middle East is closer to Eastern Africa. Too far for West Africa
> unless you want to switch in Europe.
>
> Mark.
>

RE: Colo in Africa

[Eric Tykwinski]

One of my favorite sites to give people:
https://thetruesize.com/

Sincerely,

Eric Tykwinski
TrueNet, Inc.
P: 610-429-8300

_

From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Mark Tinka
Sent: Tuesday, July 16, 2019 12:51 PM
To: nanog@nanog.org
Subject: Re: Colo in Africa


Where, in Africa? It's not a small place...

Re: Colo in Africa

[Mark Tinka]

On 16/Jul/19 17:08, Akshay Kumar via NANOG wrote:

> My bad. They announced that Oct 2018 so I figured they'd be close to
> it now. Yeah turns out it's mid 2020 :-(

I'd take all targets with a very large grain of salt. Experience has
shown that these things always take longer than planned... and then take
longer again, after that.

There other folk offering servers (bare and virtual) in the region. So
if you're not gung-ho on a name brand, you're in luck.

Mark.

Re: Colo in Africa

[Mark Tinka]

On 16/Jul/19 16:55, Akshay Kumar via NANOG wrote:
> The 2nd requirement seems artificial. The new hypervisors have come a
> long way and the overhead is minimal. Also you can run bare metal
> instances in AWS if you really need them with 100Gbps.

That said, there are various providers who can give you bare metal.

>
> Just just use the South Africa AWS region.

There are other local providers that can offer this. They just don't
carry the badge.

Mark.

Re: Colo in Africa

[Mark Tinka]

On 16/Jul/19 17:01, Phil Lavin wrote:

>
> They don't have a Region there at present - only an Edge location. I believe 
> one is in the works for launch next year.

You're right (as of my updates from last November).

Mark.

Re: Colo in Africa

[Mark Tinka]

On 16/Jul/19 16:33, Ken Gilmour wrote:

> Hi Folks,
>
> I work for a Security Analytics org and we're looking to build a small
> POP in Africa.

Where, in Africa? It's not a small place...


>  1. Network needs to be able to receive millions of small PPS (as
> opposed to serving smaller numbers of larger files).
>

Depending on where in Africa you want to deploy, there will be a choice
of service providers.


>  1. Can't be cloud (need bare metal servers / colo). We use the full
> capacity of each server, all the time.
>

This is possible, but will depend on where, in Africa, you want to deploy.


>  1. Must have good connectivity to most of the rest of Africa
>

This is a tricky one, but if you know where you want to be, it will help
to give you options.


>  1. We can initially only have one POP
>

Not a problem, but where?


> This is not like a normal website that we can just host on "any old
> provider", the requirements are very different.
>
> Is there a good location where we could either rent bare metal servers
> (something like Internap - preferred) or colocate servers within
> Africa that can serve most of the region?

Africa is huge, with varying levels of quality of connectivity. The 3
main regions are East Africa (Kenya leading), Southern Africa (South
Africa leading) and West Africa (Nigeria and Ghana leading).

For North Africa, your options can swing between Egypt and Morocco.

But stringing all of these locations together, particularly West and
North to East and South, will not be straight forward.



>
> "Good" is defined as an area with stable connectivity and power, no
> legal restrictions on things like encryption, and good latency (sub
> 100ms) to the rest of Africa.

Yes, all 5 will be difficult at this point in time.

For most of that, hosting within Eastern and Southern Africa will be
your best bets.

West Africa ticks a lot of the boxes, but it's not very straight forward
when it comes to co-lo.



>
> Our two closest POPs are in Singapore and The Netherlands, so I'd like
> something closer to the middle that can serve the rest of Africa.
> Middle East will be deployed after Africa.

Singapore is closer to Eastern & Southern Africa. Will be too far to
West Africa unless you want to switch in Europe.

The Netherlands is okay for all of Africa.

The Middle East is closer to Eastern Africa. Too far for West Africa
unless you want to switch in Europe.

Mark.

Re: Colo in Africa

[Ken Gilmour]

These are actual real problems we face. thousands of customers load and
reload TBs of data every few seconds on their dashboards. We have busy
servers. We tried cloud. I passionately hate it. We choose to use Bare
Metal.

On Tue, 16 Jul 2019 at 10:34, Akshay Kumar  wrote:

> Go look at the actual specifications for one of the metal boxes - you are
> not going to come close to maxing anything out with the workload you
> describe. FSB hasn't been a thing in over a decade. If you really wanted to
> go crazy you could do some build a custom solution in FPGA on the F1s.
>
> It's a moot point since none of this is going to be available in time but
> perf is a bogus reason and a lot of the times price is too.
>
> On Tue, Jul 16, 2019 at 5:12 PM Ken Gilmour  wrote:
>
>> Speed is not the issue, it's IO. Also streaming 100Gbps of video is very
>> different to streaming 100Gbps of files smaller than 100kb (average of
>> about 30kb) the issue on the network level is the number of connections and
>> CPU, on the server side it's IO and FSB
>>
>> On Tue, 16 Jul 2019 at 08:55, Akshay Kumar  wrote:
>>
>>> The 2nd requirement seems artificial. The new hypervisors have come a
>>> long way and the overhead is minimal. Also you can run bare metal instances
>>> in AWS if you really need them with 100Gbps.
>>>
>>> Just just use the South Africa AWS region.
>>>
>>> On Tue, Jul 16, 2019 at 3:35 PM Ken Gilmour 
>>> wrote:
>>>
 Hi Folks,

 I work for a Security Analytics org and we're looking to build a small
 POP in Africa. I am pretty clueless about the region so I was wondering if
 you could help guide me in the right direction for research?

 The challenges:

1. Network needs to be able to receive millions of small PPS (as
opposed to serving smaller numbers of larger files).
2. Can't be cloud (need bare metal servers / colo). We use the full
capacity of each server, all the time.
3. Must have good connectivity to most of the rest of Africa
4. We can initially only have one POP

 This is not like a normal website that we can just host on "any old
 provider", the requirements are very different.

 Is there a good location where we could either rent bare metal servers
 (something like Internap - preferred) or colocate servers within Africa
 that can serve most of the region?

 "Good" is defined as an area with stable connectivity and power, no
 legal restrictions on things like encryption, and good latency (sub 100ms)
 to the rest of Africa.

 Our two closest POPs are in Singapore and The Netherlands, so I'd like
 something closer to the middle that can serve the rest of Africa. Middle
 East will be deployed after Africa.

 I hope this is the right place to ask.

 Thanks!

 Ken

>>>

Re: Colo in Africa

[Ben Cannon]

Have you priced F1 solutions?  

-Ben Cannon
CEO 6x7 Networks & 6x7 Telecom, LLC 
b...@6by7.net 




> On Jul 16, 2019, at 9:33 AM, Akshay Kumar via NANOG  wrote:
> 
> Go look at the actual specifications for one of the metal boxes - you are not 
> going to come close to maxing anything out with the workload you describe. 
> FSB hasn't been a thing in over a decade. If you really wanted to go crazy 
> you could do some build a custom solution in FPGA on the F1s.
> 
> It's a moot point since none of this is going to be available in time but 
> perf is a bogus reason and a lot of the times price is too.
> 
> On Tue, Jul 16, 2019 at 5:12 PM Ken Gilmour  > wrote:
> Speed is not the issue, it's IO. Also streaming 100Gbps of video is very 
> different to streaming 100Gbps of files smaller than 100kb (average of about 
> 30kb) the issue on the network level is the number of connections and CPU, on 
> the server side it's IO and FSB
> 
> On Tue, 16 Jul 2019 at 08:55, Akshay Kumar  > wrote:
> The 2nd requirement seems artificial. The new hypervisors have come a long 
> way and the overhead is minimal. Also you can run bare metal instances in AWS 
> if you really need them with 100Gbps.
> 
> Just just use the South Africa AWS region.
> 
> On Tue, Jul 16, 2019 at 3:35 PM Ken Gilmour  > wrote:
> Hi Folks,
> 
> I work for a Security Analytics org and we're looking to build a small POP in 
> Africa. I am pretty clueless about the region so I was wondering if you could 
> help guide me in the right direction for research?
> 
> The challenges:
> Network needs to be able to receive millions of small PPS (as opposed to 
> serving smaller numbers of larger files).
> Can't be cloud (need bare metal servers / colo). We use the full capacity of 
> each server, all the time.
> Must have good connectivity to most of the rest of Africa
> We can initially only have one POP
> This is not like a normal website that we can just host on "any old 
> provider", the requirements are very different.
> 
> Is there a good location where we could either rent bare metal servers 
> (something like Internap - preferred) or colocate servers within Africa that 
> can serve most of the region?
> 
> "Good" is defined as an area with stable connectivity and power, no legal 
> restrictions on things like encryption, and good latency (sub 100ms) to the 
> rest of Africa.
> 
> Our two closest POPs are in Singapore and The Netherlands, so I'd like 
> something closer to the middle that can serve the rest of Africa. Middle East 
> will be deployed after Africa.
> 
> I hope this is the right place to ask.
> 
> Thanks!
> 
> Ken

Re: Colo in Africa

[Akshay Kumar via NANOG]

Go look at the actual specifications for one of the metal boxes - you are
not going to come close to maxing anything out with the workload you
describe. FSB hasn't been a thing in over a decade. If you really wanted to
go crazy you could do some build a custom solution in FPGA on the F1s.

It's a moot point since none of this is going to be available in time but
perf is a bogus reason and a lot of the times price is too.

On Tue, Jul 16, 2019 at 5:12 PM Ken Gilmour  wrote:

> Speed is not the issue, it's IO. Also streaming 100Gbps of video is very
> different to streaming 100Gbps of files smaller than 100kb (average of
> about 30kb) the issue on the network level is the number of connections and
> CPU, on the server side it's IO and FSB
>
> On Tue, 16 Jul 2019 at 08:55, Akshay Kumar  wrote:
>
>> The 2nd requirement seems artificial. The new hypervisors have come a
>> long way and the overhead is minimal. Also you can run bare metal instances
>> in AWS if you really need them with 100Gbps.
>>
>> Just just use the South Africa AWS region.
>>
>> On Tue, Jul 16, 2019 at 3:35 PM Ken Gilmour 
>> wrote:
>>
>>> Hi Folks,
>>>
>>> I work for a Security Analytics org and we're looking to build a small
>>> POP in Africa. I am pretty clueless about the region so I was wondering if
>>> you could help guide me in the right direction for research?
>>>
>>> The challenges:
>>>
>>>1. Network needs to be able to receive millions of small PPS (as
>>>opposed to serving smaller numbers of larger files).
>>>2. Can't be cloud (need bare metal servers / colo). We use the full
>>>capacity of each server, all the time.
>>>3. Must have good connectivity to most of the rest of Africa
>>>4. We can initially only have one POP
>>>
>>> This is not like a normal website that we can just host on "any old
>>> provider", the requirements are very different.
>>>
>>> Is there a good location where we could either rent bare metal servers
>>> (something like Internap - preferred) or colocate servers within Africa
>>> that can serve most of the region?
>>>
>>> "Good" is defined as an area with stable connectivity and power, no
>>> legal restrictions on things like encryption, and good latency (sub 100ms)
>>> to the rest of Africa.
>>>
>>> Our two closest POPs are in Singapore and The Netherlands, so I'd like
>>> something closer to the middle that can serve the rest of Africa. Middle
>>> East will be deployed after Africa.
>>>
>>> I hope this is the right place to ask.
>>>
>>> Thanks!
>>>
>>> Ken
>>>
>>

Re: Colo in Africa

[Graham Hayes]

On 16/07/2019 16:08, Akshay Kumar via NANOG wrote:
> My bad. They announced that Oct 2018 so I figured they'd be close to it
> now. Yeah turns out it's mid 2020 :-(
> 
> https://aws.amazon.com/blogs/aws/in-the-works-aws-region-in-south-africa/
> 

Azure does have regions in operation in South Africa [1]

1 -
https://azure.microsoft.com/en-in/global-infrastructure/services/?products=kubernetes-service,virtual-machines

> On Tue, Jul 16, 2019 at 4:02 PM Chris Knipe  > wrote:
> 
> 
> 
> On Tue, Jul 16, 2019 at 4:57 PM Akshay Kumar via NANOG
> mailto:nanog@nanog.org>> wrote:
> 
> The 2nd requirement seems artificial. The new hypervisors have
> come a long way and the overhead is minimal. Also you can run
> bare metal instances in AWS if you really need them with 100Gbps.
> 
> Just just use the South Africa AWS region.
> 
> 
> ^^ You had me for a second there.  AWS ain't operational yet in
> South Africa.  Sometime 2020/2021 only.
> 




signature.asc
Description: OpenPGP digital signature

Re: Colo in Africa

[Joel Jaeggli]

> On Jul 16, 2019, at 07:33, Ken Gilmour  wrote:
> 
> Hi Folks,
> 
> I work for a Security Analytics org and we're looking to build a small POP in 
> Africa. I am pretty clueless about the region so I was wondering if you could 
> help guide me in the right direction for research?
> 
> The challenges:
> Network needs to be able to receive millions of small PPS (as opposed to 
> serving smaller numbers of larger files).
> Can't be cloud (need bare metal servers / colo). We use the full capacity of 
> each server, all the time.
> Must have good connectivity to most of the rest of Africa
> We can initially only have one POP
> This is not like a normal website that we can just host on "any old 
> provider", the requirements are very different.
> 
> Is there a good location where we could either rent bare metal servers 
> (something like Internap - preferred) or colocate servers within Africa that 
> can serve most of the region?
> 
> "Good" is defined as an area with stable connectivity and power, no legal 
> restrictions on things like encryption, and good latency (sub 100ms) to the 
> rest of Africa.

100ms from most of the rest of Africa is going to be a bit dubious. If you draw 
a line horizontally through Senegal the costal stuff north of it can mostly be 
served in under 100ms from Europe.

While cross border terrestrial fiber exists most networks I’ve been exposed to 
have east west and north south connectivity Via submarine connected networks.  
This make it hard to locate one low latency spot in the middle.

NSRC has a project that can provide some background on terrestrial fiber.

https://afterfibre.nsrc.org/

The next best place to my mind for reach east and west is South Africa where 
you can pick up something of a diversity of transit find decent colo and pick 
up a few out of region peers if you locate near jinx or cinx which are both 
multi building connected exchanges.

> Our two closest POPs are in Singapore and The Netherlands, so I'd like 
> something closer to the middle that can serve the rest of Africa. Middle East 
> will be deployed after Africa.
> 
> I hope this is the right place to ask.
> 
> Thanks!
> 
> Ken

Re: Colo in Africa

[Ken Gilmour]

Speed is not the issue, it's IO. Also streaming 100Gbps of video is very
different to streaming 100Gbps of files smaller than 100kb (average of
about 30kb) the issue on the network level is the number of connections and
CPU, on the server side it's IO and FSB

On Tue, 16 Jul 2019 at 08:55, Akshay Kumar  wrote:

> The 2nd requirement seems artificial. The new hypervisors have come a long
> way and the overhead is minimal. Also you can run bare metal instances in
> AWS if you really need them with 100Gbps.
>
> Just just use the South Africa AWS region.
>
> On Tue, Jul 16, 2019 at 3:35 PM Ken Gilmour  wrote:
>
>> Hi Folks,
>>
>> I work for a Security Analytics org and we're looking to build a small
>> POP in Africa. I am pretty clueless about the region so I was wondering if
>> you could help guide me in the right direction for research?
>>
>> The challenges:
>>
>>1. Network needs to be able to receive millions of small PPS (as
>>opposed to serving smaller numbers of larger files).
>>2. Can't be cloud (need bare metal servers / colo). We use the full
>>capacity of each server, all the time.
>>3. Must have good connectivity to most of the rest of Africa
>>4. We can initially only have one POP
>>
>> This is not like a normal website that we can just host on "any old
>> provider", the requirements are very different.
>>
>> Is there a good location where we could either rent bare metal servers
>> (something like Internap - preferred) or colocate servers within Africa
>> that can serve most of the region?
>>
>> "Good" is defined as an area with stable connectivity and power, no legal
>> restrictions on things like encryption, and good latency (sub 100ms) to the
>> rest of Africa.
>>
>> Our two closest POPs are in Singapore and The Netherlands, so I'd like
>> something closer to the middle that can serve the rest of Africa. Middle
>> East will be deployed after Africa.
>>
>> I hope this is the right place to ask.
>>
>> Thanks!
>>
>> Ken
>>
>

Re: Colo in Africa

[Ken Gilmour]

Bingo

On Tue, 16 Jul 2019 at 09:30, Christopher Morrow 
wrote:

> Isn't the OP really asking here (not to have their selection of
> platform wrangled..):
>   "Where should I target my search: ZA only? is there anywhere else
> worth dropping my request?"
>
> and:
>   "Are there likely providers of solid colo aside from
> seacom/tinka-net or workonline/ben-net ?"
>
> On Tue, Jul 16, 2019 at 11:12 AM Akshay Kumar via NANOG 
> wrote:
> >
> > My bad. They announced that Oct 2018 so I figured they'd be close to it
> now. Yeah turns out it's mid 2020 :-(
> >
> >
> https://aws.amazon.com/blogs/aws/in-the-works-aws-region-in-south-africa/
> >
> > On Tue, Jul 16, 2019 at 4:02 PM Chris Knipe 
> wrote:
> >>
> >>
> >>
> >> On Tue, Jul 16, 2019 at 4:57 PM Akshay Kumar via NANOG 
> wrote:
> >>>
> >>> The 2nd requirement seems artificial. The new hypervisors have come a
> long way and the overhead is minimal. Also you can run bare metal instances
> in AWS if you really need them with 100Gbps.
> >>>
> >>> Just just use the South Africa AWS region.
> >>>
> >>
> >> ^^ You had me for a second there.  AWS ain't operational yet in South
> Africa.  Sometime 2020/2021 only.
> >>
>

Re: Colo in Africa

[Ken Gilmour]

Thanks for all the replies! (really fast!)

The requirement for Bare Metal is very specific. Dealing with high speed
large files is very different to dealing with high volume small files. We
regularly encounter bottlenecks at the FSB and at the IO level. Even things
like RAID slows us down, so we have to squeeze every iota of power out of
the servers that we can. Plus, most of our customers in Africa use our free
version so cost savings are also important, and so is accessibility.

On Tue, 16 Jul 2019 at 09:10, Bryan Fields  wrote:

> On 7/16/19 10:55 AM, Akshay Kumar via NANOG wrote:
> > The 2nd requirement seems artificial. The new hypervisors have come a
> long
> > way and the overhead is minimal. Also you can run bare metal instances in
> > AWS if you really need them with 100Gbps.
>
> Well the man wants bare metal, and while there's arguments for and against
> it,
> it's what he wants to buy :)
>
> That said, I'm one of those guys that likes owing my own hypervisor, don't
> need to worry about the side channel/memory/OOO execution attacks from
> rogue
> VM's if it's only my VM's on it.  Plus AWS ain't cheap either.
>
> --
> Bryan Fields
>
> 727-409-1194 - Voice
> http://bryanfields.net
>

Re: Colo in Africa

[Mike Hammett]

The cloud isn't always the right decision for the end customer. In many cases, 
it's the worst decision. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Akshay Kumar via NANOG"  
To: "Ken Gilmour"  
Cc: "North Group"  
Sent: Tuesday, July 16, 2019 9:55:12 AM 
Subject: Re: Colo in Africa 


The 2nd requirement seems artificial. The new hypervisors have come a long way 
and the overhead is minimal. Also you can run bare metal instances in AWS if 
you really need them with 100Gbps. 


Just just use the South Africa AWS region. 



On Tue, Jul 16, 2019 at 3:35 PM Ken Gilmour < ken.gilm...@gmail.com > wrote: 



Hi Folks, 


I work for a Security Analytics org and we're looking to build a small POP in 
Africa. I am pretty clueless about the region so I was wondering if you could 
help guide me in the right direction for research? 


The challenges: 


1. Network needs to be able to receive millions of small PPS (as opposed to 
serving smaller numbers of larger files). 
2. Can't be cloud (need bare metal servers / colo). We use the full 
capacity of each server, all the time. 
3. Must have good connectivity to most of the rest of Africa 
4. We can initially only have one POP 


This is not like a normal website that we can just host on "any old provider", 
the requirements are very different. 


Is there a good location where we could either rent bare metal servers 
(something like Internap - preferred) or colocate servers within Africa that 
can serve most of the region? 


"Good" is defined as an area with stable connectivity and power, no legal 
restrictions on things like encryption, and good latency (sub 100ms) to the 
rest of Africa. 


Our two closest POPs are in Singapore and The Netherlands, so I'd like 
something closer to the middle that can serve the rest of Africa. Middle East 
will be deployed after Africa. 


I hope this is the right place to ask. 



Thanks! 


Ken 

Re: Performance metrics used in commercial BGP route optimizers

[Mike Hammett]

More like do whatever you want in your own house as long as you don't infringe 
upon others. 




The argument against route optimizers (assuming appropriate ingress\egress 
filters) is a religious one and should be treated as such. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Töma Gavrichenkov"  
To: "Mike Hammett"  
Cc: "NANOG" , "Dimeji Fayomi"  
Sent: Tuesday, July 16, 2019 9:53:46 AM 
Subject: Re: Performance metrics used in commercial BGP route optimizers 





On Tue, Jul 16, 2019, 5:49 PM Mike Hammett < na...@ics-il.net > wrote: 




Most of which are bunk if you and your upstream have appropriate filters. 




True, and, while we're at it, it's okay to drink and drive a car if the 
manufacturer has built enough driver assistance systems in it. 


-- 
Töma 

Re: Colo in Africa

[Christopher Morrow]

Isn't the OP really asking here (not to have their selection of
platform wrangled..):
  "Where should I target my search: ZA only? is there anywhere else
worth dropping my request?"

and:
  "Are there likely providers of solid colo aside from
seacom/tinka-net or workonline/ben-net ?"

On Tue, Jul 16, 2019 at 11:12 AM Akshay Kumar via NANOG  wrote:
>
> My bad. They announced that Oct 2018 so I figured they'd be close to it now. 
> Yeah turns out it's mid 2020 :-(
>
> https://aws.amazon.com/blogs/aws/in-the-works-aws-region-in-south-africa/
>
> On Tue, Jul 16, 2019 at 4:02 PM Chris Knipe  wrote:
>>
>>
>>
>> On Tue, Jul 16, 2019 at 4:57 PM Akshay Kumar via NANOG  
>> wrote:
>>>
>>> The 2nd requirement seems artificial. The new hypervisors have come a long 
>>> way and the overhead is minimal. Also you can run bare metal instances in 
>>> AWS if you really need them with 100Gbps.
>>>
>>> Just just use the South Africa AWS region.
>>>
>>
>> ^^ You had me for a second there.  AWS ain't operational yet in South 
>> Africa.  Sometime 2020/2021 only.
>>

Re: Colo in Africa

[Akshay Kumar via NANOG]

Thanks for chiming in but his reason for can't be cloud was, "We use the
full capacity of each server, all the time." That ain't good reason.

They do have baremetal servers like I pointed out. We use them when for
cases where we need access to perf counters.

On Tue, Jul 16, 2019 at 4:10 PM Bryan Fields  wrote:

> On 7/16/19 10:55 AM, Akshay Kumar via NANOG wrote:
> > The 2nd requirement seems artificial. The new hypervisors have come a
> long
> > way and the overhead is minimal. Also you can run bare metal instances in
> > AWS if you really need them with 100Gbps.
>
> Well the man wants bare metal, and while there's arguments for and against
> it,
> it's what he wants to buy :)
>
> That said, I'm one of those guys that likes owing my own hypervisor, don't
> need to worry about the side channel/memory/OOO execution attacks from
> rogue
> VM's if it's only my VM's on it.  Plus AWS ain't cheap either.
>
> --
> Bryan Fields
>
> 727-409-1194 - Voice
> http://bryanfields.net
>

Re: Colo in Africa

[Akshay Kumar via NANOG]

My bad. They announced that Oct 2018 so I figured they'd be close to it
now. Yeah turns out it's mid 2020 :-(

https://aws.amazon.com/blogs/aws/in-the-works-aws-region-in-south-africa/

On Tue, Jul 16, 2019 at 4:02 PM Chris Knipe  wrote:

>
>
> On Tue, Jul 16, 2019 at 4:57 PM Akshay Kumar via NANOG 
> wrote:
>
>> The 2nd requirement seems artificial. The new hypervisors have come a
>> long way and the overhead is minimal. Also you can run bare metal instances
>> in AWS if you really need them with 100Gbps.
>>
>> Just just use the South Africa AWS region.
>>
>>
> ^^ You had me for a second there.  AWS ain't operational yet in South
> Africa.  Sometime 2020/2021 only.
>
>

Re: Colo in Africa

[Bryan Fields]

On 7/16/19 10:55 AM, Akshay Kumar via NANOG wrote:
> The 2nd requirement seems artificial. The new hypervisors have come a long
> way and the overhead is minimal. Also you can run bare metal instances in
> AWS if you really need them with 100Gbps.

Well the man wants bare metal, and while there's arguments for and against it,
it's what he wants to buy :)

That said, I'm one of those guys that likes owing my own hypervisor, don't
need to worry about the side channel/memory/OOO execution attacks from rogue
VM's if it's only my VM's on it.  Plus AWS ain't cheap either.

-- 
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net

RE: Colo in Africa

[Phil Lavin]

> just use the South Africa AWS region

They don't have a Region there at present - only an Edge location. I believe 
one is in the works for launch next year.

Re: Colo in Africa

[Chris Knipe]

On Tue, Jul 16, 2019 at 4:57 PM Akshay Kumar via NANOG 
wrote:

> The 2nd requirement seems artificial. The new hypervisors have come a long
> way and the overhead is minimal. Also you can run bare metal instances in
> AWS if you really need them with 100Gbps.
>
> Just just use the South Africa AWS region.
>
>
^^ You had me for a second there.  AWS ain't operational yet in South
Africa.  Sometime 2020/2021 only.

Re: Colo in Africa

[Akshay Kumar via NANOG]

The 2nd requirement seems artificial. The new hypervisors have come a long
way and the overhead is minimal. Also you can run bare metal instances in
AWS if you really need them with 100Gbps.

Just just use the South Africa AWS region.

On Tue, Jul 16, 2019 at 3:35 PM Ken Gilmour  wrote:

> Hi Folks,
>
> I work for a Security Analytics org and we're looking to build a small POP
> in Africa. I am pretty clueless about the region so I was wondering if you
> could help guide me in the right direction for research?
>
> The challenges:
>
>1. Network needs to be able to receive millions of small PPS (as
>opposed to serving smaller numbers of larger files).
>2. Can't be cloud (need bare metal servers / colo). We use the full
>capacity of each server, all the time.
>3. Must have good connectivity to most of the rest of Africa
>4. We can initially only have one POP
>
> This is not like a normal website that we can just host on "any old
> provider", the requirements are very different.
>
> Is there a good location where we could either rent bare metal servers
> (something like Internap - preferred) or colocate servers within Africa
> that can serve most of the region?
>
> "Good" is defined as an area with stable connectivity and power, no legal
> restrictions on things like encryption, and good latency (sub 100ms) to the
> rest of Africa.
>
> Our two closest POPs are in Singapore and The Netherlands, so I'd like
> something closer to the middle that can serve the rest of Africa. Middle
> East will be deployed after Africa.
>
> I hope this is the right place to ask.
>
> Thanks!
>
> Ken
>

Re: Performance metrics used in commercial BGP route optimizers

[Töma Gavrichenkov]

On Tue, Jul 16, 2019, 5:49 PM Mike Hammett  wrote:

> Most of which are bunk if you and your upstream have appropriate filters.
>

True, and, while we're at it, it's okay to drink and drive a car if the
manufacturer has built enough driver assistance systems in it.

--
Töma

Re: Performance metrics used in commercial BGP route optimizers

[Mike Hammett]

Most of which are bunk if you and your upstream have appropriate filters. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Töma Gavrichenkov"  
To: "Dimeji Fayomi"  
Cc: "NANOG"  
Sent: Tuesday, July 16, 2019 8:30:37 AM 
Subject: Re: Performance metrics used in commercial BGP route optimizers 




On Tue, Jul 16, 2019, 4:11 PM Dimeji Fayomi < o...@students.waikato.ac.nz > 
wrote: 



I'm doing a research on BGP route optimisation and the performance metrics used 
by commercial route optimizer appliances to select better path to a prefix. 




You may have discovered that already during your research, but just in case: 
basically, using those optimizers at full throttle is a bad practice and is 
generally discouraged. 


A research into the deep-juju of BGP optimization is roughly equivalent to a 
research about how alcohol may make you a faster driver. I.e. it's fine in 
academy but you certainly may want to emphasize security considerations in your 
paper. 


-- 
Töma 

Colo in Africa

[Ken Gilmour]

Hi Folks,

I work for a Security Analytics org and we're looking to build a small POP
in Africa. I am pretty clueless about the region so I was wondering if you
could help guide me in the right direction for research?

The challenges:

   1. Network needs to be able to receive millions of small PPS (as opposed
   to serving smaller numbers of larger files).
   2. Can't be cloud (need bare metal servers / colo). We use the full
   capacity of each server, all the time.
   3. Must have good connectivity to most of the rest of Africa
   4. We can initially only have one POP

This is not like a normal website that we can just host on "any old
provider", the requirements are very different.

Is there a good location where we could either rent bare metal servers
(something like Internap - preferred) or colocate servers within Africa
that can serve most of the region?

"Good" is defined as an area with stable connectivity and power, no legal
restrictions on things like encryption, and good latency (sub 100ms) to the
rest of Africa.

Our two closest POPs are in Singapore and The Netherlands, so I'd like
something closer to the middle that can serve the rest of Africa. Middle
East will be deployed after Africa.

I hope this is the right place to ask.

Thanks!

Ken

Re: Performance metrics used in commercial BGP route optimizers

[Töma Gavrichenkov]

On Tue, Jul 16, 2019, 4:11 PM Dimeji Fayomi 
wrote:

> I'm doing a research on BGP route optimisation and the performance metrics
> used by commercial route optimizer appliances to select better path to a
> prefix.
>

You may have discovered that already during your research, but just in
case: basically, using those optimizers at full throttle is a bad practice
and is generally discouraged.

A research into the deep-juju of BGP optimization is roughly equivalent to
a research about how alcohol may make you a faster driver.  I.e. it's fine
in academy but you certainly may want to emphasize security considerations
in your paper.

--
Töma

>

Re: Performance metrics used in commercial BGP route optimizers

[Tom Beecher]

The most important metric for a BGP optimizer is how much it physically
weighs. That way you'll know if you can carry it to the trash pile
yourself, or need to get help so you don't hurt your back.

:)

On Tue, Jul 16, 2019 at 9:21 AM Ryan Hamel  wrote:

> The answers which you seek would be considered secret sauce to these
> vendors.
>
> But you can start at running MTRs through a VRF per carrier only
> containing a default route, and looking at the results.
>
> Ryan
>
>
>
> On Tue, Jul 16, 2019 at 6:11 AM -0700, "Dimeji Fayomi" <
> o...@students.waikato.ac.nz> wrote:
>
> Hi,
>> I'm doing a research on BGP route optimisation and the performance
>> metrics used by commercial route optimizer appliances to select better path
>> to a prefix.
>>
>> I would appreciate any information about the performance metrics used in
>> commercial BGP route optimizers, white papers or any other document that
>> describes how these metrics are measured and collected by commercial route
>> optimizers.
>>
>> Thanks
>> --
>> Dimeji Fayomi
>>
>

Re: Performance metrics used in commercial BGP route optimizers

[Ryan Hamel]

The answers which you seek would be considered secret sauce to these vendors.

But you can start at running MTRs through a VRF per carrier only containing a 
default route, and looking at the results.

Ryan



On Tue, Jul 16, 2019 at 6:11 AM -0700, "Dimeji Fayomi" 
mailto:o...@students.waikato.ac.nz>> wrote:

Hi,
I'm doing a research on BGP route optimisation and the performance metrics used 
by commercial route optimizer appliances to select better path to a prefix.

I would appreciate any information about the performance metrics used in 
commercial BGP route optimizers, white papers or any other document that 
describes how these metrics are measured and collected by commercial route 
optimizers.

Thanks
--
Dimeji Fayomi

Performance metrics used in commercial BGP route optimizers

[Dimeji Fayomi]

Hi,
I'm doing a research on BGP route optimisation and the performance metrics
used by commercial route optimizer appliances to select better path to a
prefix.

I would appreciate any information about the performance metrics used in
commercial BGP route optimizers, white papers or any other document that
describes how these metrics are measured and collected by commercial route
optimizers.

Thanks
-- 
Dimeji Fayomi