Re: 60ms cross continent

[Mike Lyon]

For the IoT/M2M stuff that doesn’t require huge amounts of data, there is  a 
Silicon Valley startup that is deploying cube sats for just that.

Swarm Technologies

https://www.swarm.space/

-Mike

> On Jul 8, 2020, at 19:49, Denys Fedoryshchenko  
> wrote:
> 
> On 2020-07-08 10:05, Mark Tinka wrote:
>>> On 7/Jul/20 21:58, Eric Kuhnke wrote:
>>> Watching the growth of terrestrial fiber (and PTP microwave) networks
>>> going inland from the west and east African coasts has been
>>> interesting. There's a big old C-band earth station on the hill above
>>> Freetown, Sierra Leone that was previously the capital's only link to
>>> the outside world. Obsoleted for some years now thanks to the
>>> submarine cable and landing station. I imagine they might keep things
>>> live as a backup path with a small C-band transponder MHz commit and
>>> SCPC modems linked to an earth station somewhere in Europe, but not
>>> with very much capacity or monthly cost.
>>> The landing station in Mogadishu had a similar effect.
>> The early years of submarine fibre in Africa always had satellite as a
>> backup. In fact, many satellite companies that served Africa with
>> Internet prior to submarine fibre were banking on subsea and terrestrial
>> failures to remain relevant. It worked between 2009 - 2013, when
>> terrestrial builds and operation had plenty of teething problems. Those
>> companies have since either disappeared or moved their services over to
>> fibre as well.
>> In that time, it has simply become impossible to have any backup
>> capacity on satellite anymore. There is too much active fibre bandwidth
>> being carried around and out of/into Africa for any satellite system to
>> make sense. Rather, diversifying terrestrial and submarine capacity is
>> the answer, and that is growing quite well.
>> Plenty of new cable systems that are launching this year, next year and
>> the next 3 years. At the moment, one would say there is sufficient
>> submarine capacity to keep the continent going in case of a major subsea
>> cut (like we saw in January when both the WACS and SAT-3 cables got cut
>> at the same time, and were out for over a month).
>> Satellite earth stations are not irrelevant, however. They still do get
>> used to provide satellite-based TV services, and can also be used for
>> media houses who need to hook up to their network to broadcast video
>> when reporting in the region (even though uploading a raw file back home
>> over the Internet is where the tech. has now gone).
>> Mark.
> 
> I don't think traditional satellites have much future as backbone. Only as 
> broadcasting media.
> Most are still acting as dumb RF converters, but we can't expect much more 
> from them.
> On geostationary orbit, it is not only expensive to bring each additional kg, 
> but also they
> need to keep it simple as possible, as it is all above van allen belt, and it 
> needs to run there
> without any maintenance for 7+ years.
> So if SpaceX managed to squeeze in their satellites at least basic processing 
> (and seems they did),
> it will improve satellite capabilities (and competitiveness) greatly.
> The only thing i hope, if they had space for some M2M IoT stuff, similar to 
> ORBCOMM.
> 

Re: 60ms cross continent

[Denys Fedoryshchenko]

On 2020-07-08 10:05, Mark Tinka wrote:

On 7/Jul/20 21:58, Eric Kuhnke wrote:

Watching the growth of terrestrial fiber (and PTP microwave) networks
going inland from the west and east African coasts has been
interesting. There's a big old C-band earth station on the hill above
Freetown, Sierra Leone that was previously the capital's only link to
the outside world. Obsoleted for some years now thanks to the
submarine cable and landing station. I imagine they might keep things
live as a backup path with a small C-band transponder MHz commit and
SCPC modems linked to an earth station somewhere in Europe, but not
with very much capacity or monthly cost.

The landing station in Mogadishu had a similar effect.


The early years of submarine fibre in Africa always had satellite as a
backup. In fact, many satellite companies that served Africa with
Internet prior to submarine fibre were banking on subsea and 
terrestrial

failures to remain relevant. It worked between 2009 - 2013, when
terrestrial builds and operation had plenty of teething problems. Those
companies have since either disappeared or moved their services over to
fibre as well.

In that time, it has simply become impossible to have any backup
capacity on satellite anymore. There is too much active fibre bandwidth
being carried around and out of/into Africa for any satellite system to
make sense. Rather, diversifying terrestrial and submarine capacity is
the answer, and that is growing quite well.

Plenty of new cable systems that are launching this year, next year and
the next 3 years. At the moment, one would say there is sufficient
submarine capacity to keep the continent going in case of a major 
subsea

cut (like we saw in January when both the WACS and SAT-3 cables got cut
at the same time, and were out for over a month).

Satellite earth stations are not irrelevant, however. They still do get
used to provide satellite-based TV services, and can also be used for
media houses who need to hook up to their network to broadcast video
when reporting in the region (even though uploading a raw file back 
home

over the Internet is where the tech. has now gone).

Mark.


I don't think traditional satellites have much future as backbone. Only 
as broadcasting media.
Most are still acting as dumb RF converters, but we can't expect much 
more from them.
On geostationary orbit, it is not only expensive to bring each 
additional kg, but also they
need to keep it simple as possible, as it is all above van allen belt, 
and it needs to run there

without any maintenance for 7+ years.
So if SpaceX managed to squeeze in their satellites at least basic 
processing (and seems they did),

it will improve satellite capabilities (and competitiveness) greatly.
The only thing i hope, if they had space for some M2M IoT stuff, similar 
to ORBCOMM.

Re: L2VPN/L2transport, Cumulus Linux & hardware suggestion

[Valdis Klētnieks]

(re-adding Adam's text that didn't get quoted, but matters)

On Wed, 08 Jul 2020 13:49:56 +0300, Saku Ytti said:
> On Wed, 8 Jul 2020 at 13:46, Radu-Adrian Feurdean
>  wrote:
> On Wed, Jul 8, 2020, at 00:09, Adam Thompson wrote:
> > > Good luck with tunnelling LACP, no matter what boxes you have - LACP
> > > has (de facto) hard jitter requirements of under 1msec, or you'll be
> > > getting TCP resets coming out your ears due to mis-ordered packets.
> > Errr sorry, but at the latest news, TCP was supposed to handle out of
> > order packets and reorder them before sending them to upper layer.
> Yes, however new reno and the like are tuned for practical Internet.
> Practical Internet has lot more packet loss than reordering, so TCP
> algorithm considers any amount of reordering a packet loss, causing an
> immediate resend, destroying your performance.

There's a difference between a TCP *resend*, and a *RESET*.

Triggering a resend on a re-order is reasonably sane, sending an RST isn't


pgpP8nAK8OtkD.pgp
Description: PGP signature

Spoofer Report for NANOG for Jun 2020

[CAIDA Spoofer Project]

In response to feedback from operational security communities,
CAIDA's source address validation measurement project
(https://spoofer.caida.org) is automatically generating monthly
reports of ASes originating prefixes in BGP for systems from which
we received packets with a spoofed source address.
We are publishing these reports to network and security operations
lists in order to ensure this information reaches operational
contacts in these ASes.

This report summarises tests conducted within usa, can.

Inferred improvements during Jun 2020:
ASNName   Fixed-By
14525  OMNIFICENT-NET 2020-06-07
10745  ARIN-ASH-CHA   2020-06-12
63018  DEDICATED  2020-06-22
23473  PAVLOVMEDIA2020-06-29

Further information for the inferred remediation is available at:
https://spoofer.caida.org/remedy.php

Source Address Validation issues inferred during Jun 2020:
ASNName   First-Spoofed Last-Spoofed
209CENTURYLINK-US-LEGACY-QWEST   2016-08-16   2020-06-25
6128   CABLE-NET-1   2016-09-03   2020-06-30
7459   GRANDECOM-AS1 2016-09-26   2020-06-11
20412  CLARITY-TELECOM   2016-09-30   2020-06-29
6181   FUSE-NET  2016-10-10   2020-06-29
11427  TWC-11427-TEXAS   2016-10-21   2020-06-22
174COGENT-1742016-10-21   2020-06-30
32440  LONI  2016-11-03   2020-06-28
12083  WOW-INTERNET  2016-11-09   2020-06-28
39939  RISE-CO-AS39939   2016-11-11   2020-06-27
30036  MEDIACOM-ENTERPRISE-BUSINESS  2016-11-16   2020-06-29
9009   M247  2017-01-10   2020-06-21
63296  AWBROADBAND   2017-09-01   2020-06-30
20448  VPNTRANET-LLC 2018-09-20   2020-06-12
8047   GCI   2019-04-11   2020-06-25
33387  NOCIX 2019-06-06   2020-06-27
46300  HSC-WAP   2019-10-30   2020-06-26
21859  ZNET  2019-12-26   2020-06-18
239UTORONTO  2020-01-28   2020-06-27
13614  ALLWEST   2020-03-16   2020-06-30
26335  MTSU  2020-03-20   2020-06-15
7859   PAIR-NETWORKS 2020-04-03   2020-06-27
5078   ONENET-AS-1   2020-04-06   2020-06-30
29844  SENAWAVE  2020-05-22   2020-06-04
11650  PLDI  2020-05-25   2020-06-24
6391   URBAN-15  2020-05-29   2020-06-30
5690   VIANET-NO 2020-06-12   2020-06-25
21565  AS21565   2020-06-21   2020-06-27
395723 LIGHTSPEEDHOSTING12020-06-22   2020-06-25
11525  HRTC  2020-06-27   2020-06-29

Further information for these tests where we received spoofed
packets is available at:
https://spoofer.caida.org/recent_tests.php?country_include=usa,can_block=1

Please send any feedback or suggestions to spoofer-i...@caida.org

[NANOG-announce] Hoping to attend NANOG 80?

[NANOG News]

*Share your insights!*

The health and safety of the NANOG community is our top priority, and your
feedback is extremely valuable in our efforts to continue providing the
safest conference experiences possible. Planning to attend NANOG 80? We'd
love to hear your thoughts!

Take Survey 
___
NANOG-announce mailing list
NANOG-announce@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce

Hoping to attend NANOG 80?

[NANOG News]

*Share your insights!*

The health and safety of the NANOG community is our top priority, and your
feedback is extremely valuable in our efforts to continue providing the
safest conference experiences possible. Planning to attend NANOG 80? We'd
love to hear your thoughts!

Take Survey 

Re: 60ms cross continent

[Mark Tinka]

On 8/Jul/20 15:21, Paul Nash wrote:
> When we started TICSA (Internet Africa/Verizon/whatever), we went with a 9600 
> bps satellite link to New Jersey specifically because the SAT-2 fibre had 
> just been installed and traffic was being moved off satellite.  The satellite 
> folk were getting *very* nervous, and gave us a heavily discounted service 
> provided we had a 5-year contract that specified that they service *had* to 
> run over satellite.  Job insurance.
>
> As our requirements grew, we added fibre connections.  Eventually the telco 
> canceled the satellite connection as they were starting to focus on VSAT.

There's no denying... they well-and-truly made their money :-).

If I think back to what we paid for 192Kbps up, 320Kbps down, it may
make all the grown folk on this list cry in :-).

Mark.

Re: 60ms cross continent

[Paul Nash]

When we started TICSA (Internet Africa/Verizon/whatever), we went with a 9600 
bps satellite link to New Jersey specifically because the SAT-2 fibre had just 
been installed and traffic was being moved off satellite.  The satellite folk 
were getting *very* nervous, and gave us a heavily discounted service provided 
we had a 5-year contract that specified that they service *had* to run over 
satellite.  Job insurance.

As our requirements grew, we added fibre connections.  Eventually the telco 
canceled the satellite connection as they were starting to focus on VSAT.

paul

> On Jul 8, 2020, at 3:05 AM, Mark Tinka  wrote:
> 
> 
> 
> On 7/Jul/20 21:58, Eric Kuhnke wrote:
>> Watching the growth of terrestrial fiber (and PTP microwave) networks
>> going inland from the west and east African coasts has been
>> interesting. There's a big old C-band earth station on the hill above
>> Freetown, Sierra Leone that was previously the capital's only link to
>> the outside world. Obsoleted for some years now thanks to the
>> submarine cable and landing station. I imagine they might keep things
>> live as a backup path with a small C-band transponder MHz commit and
>> SCPC modems linked to an earth station somewhere in Europe, but not
>> with very much capacity or monthly cost.
>> 
>> The landing station in Mogadishu had a similar effect.
> 
> The early years of submarine fibre in Africa always had satellite as a
> backup. In fact, many satellite companies that served Africa with
> Internet prior to submarine fibre were banking on subsea and terrestrial
> failures to remain relevant. It worked between 2009 - 2013, when
> terrestrial builds and operation had plenty of teething problems. Those
> companies have since either disappeared or moved their services over to
> fibre as well.
> 
> In that time, it has simply become impossible to have any backup
> capacity on satellite anymore. There is too much active fibre bandwidth
> being carried around and out of/into Africa for any satellite system to
> make sense. Rather, diversifying terrestrial and submarine capacity is
> the answer, and that is growing quite well.
> 
> Plenty of new cable systems that are launching this year, next year and
> the next 3 years. At the moment, one would say there is sufficient
> submarine capacity to keep the continent going in case of a major subsea
> cut (like we saw in January when both the WACS and SAT-3 cables got cut
> at the same time, and were out for over a month).
> 
> Satellite earth stations are not irrelevant, however. They still do get
> used to provide satellite-based TV services, and can also be used for
> media houses who need to hook up to their network to broadcast video
> when reporting in the region (even though uploading a raw file back home
> over the Internet is where the tech. has now gone).
> 
> Mark.
> 

Re: L2VPN/L2transport, Cumulus Linux & hardware suggestion

[Adam Thompson]

I do run the 7280SR2-48YC6, but I don't do VPLS or pseudowires on them right 
now so I can't help directly with that.


Based on my experience with Arista so far, it'll be perfectly-well documented, 
just for a different platform, and in a blog post instead of in the user 
manual.  :-(


(Note to anyone from Arista lurking on the list: your User Manual sucks rocks 
because it's wildly incomplete.  Please put some of the effort that goes into 
those EOS Central blog posts, into the manual instead.)


As to the Juniper, I'm a client on a Juniper-based VPLS system, and the only 
thing it consistently intercepts is LLDP... which I'm actually OK with, mostly. 
 Other BPDUs and other Ethernet protocols get passed through (that we've 
tested, so far).  We have heard of some feature limitations on the EX4650, no 
CCC is unfortunate.  I don't have any experience with the QFX series as an 
operator or customer so can't comment.


Adam Thompson
Consultant, Infrastructure Services
[1593169877849]
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only)
athomp...@merlin.mb.ca
www.merlin.mb.ca


From: NANOG  on behalf of 
Jürgen Jaritsch 
Sent: Tuesday, July 7, 2020 5:05:03 PM
To: nanog@nanog.org
Subject: AW: L2VPN/L2transport, Cumulus Linux & hardware suggestion

Dear Adam,

yeah, forget about LACP - the bigger problem is all the LLDP and STP stuff,
that gets interpreted at the UNI port. LACP is a bad example - but there are
many other frames and protocols, which must work. Could be that a customer
wants to run MPLS+LDP on his VLL (for whatever reason ...).

> For your requirements, although I hesitate to recommend them for
enterprise/carrier use, Miktotik's EoIP protocol does a much better job of
this than most "carrier-grade" implementations.

Not at wirespeed ... and not without causing other issues (single thread
load, etc).

> Juniper has the EX4650 that matches your h/w specs,...  Not 100% sure the
Juniper EX does 25G, now that I think of it.

Yeah, EX4650 it does: 48x 1/10/25G + 6x 100G + MPLS
It also supports Ethernet over MPLS (at least they say here:
https://www.juniper.net/documentation/en_US/junos/topics/topic-map/mpls-over
view.html#id-mpls-feature-support-on-qfx-series-and-ex4600-switches) but at
some of their sites they mention, that MPLS-based CCC are not support:
https://www.juniper.net/documentation/en_US/junos/topics/topic-map/mpls-over
view.html#jd0e2531

" ... MPLS-based circuit cross-connects (CCC) are not supported—only
circuit-based pseudowires are supported. ..."

There is also the QFX5120-48Y - 48x 1/10/25G + 8x 100G + MPLS
In the past QFX wasn't the best idea for MPLS topics ... has this changed?

> and Arista has, oh, at least half a dozen boxes of various spec that
comply, too.

Yeah, I already know them (do have some older 7050S). The call it "VXLAN P2P
Pseudowire", but there is absolutely nothing in there CLI documentation :(.
Looks like the feature is only support on the 7280 platform.

Possible options:
7280SR2-48YC6

Do you have any experience with what they call "VXLAN P2P Pseudowire"? I
can't even find a config example on the net :(


thanks & best regards
Jürgen






-Ursprüngliche Nachricht-
Von: Adam Thompson [mailto:athomp...@merlin.mb.ca]
Gesendet: Dienstag, 7. Juli 2020 23:09
An: Jürgen Jaritsch ; nanog@nanog.org
Betreff: RE: L2VPN/L2transport, Cumulus Linux & hardware suggestion

Good luck with tunnelling LACP, no matter what boxes you have - LACP has (de
facto) hard jitter requirements of under 1msec, or you'll be getting TCP
resets coming out your ears due to mis-ordered packets.

For your requirements, although I hesitate to recommend them for
enterprise/carrier use, Miktotik's EoIP protocol does a much better job of
this than most "carrier-grade" implementations.

Otherwise, Juniper and Arista both come to mind, Juniper has the EX4650 that
matches your h/w specs, and Arista has, oh, at least half a dozen boxes of
various spec that comply, too.  Not 100% sure the Juniper EX does 25G, now
that I think of it.

Adam Thompson
Consultant, Infrastructure Services
MERLIN
100 - 135 Innovation Drive
Winnipeg, MB, R3T 6A8
(204) 977-6824 or 1-800-430-6404 (MB only) mailto:athomp...@merlin.mb.ca
http://www.merlin.mb.ca

> -Original Message-
> From: NANOG  On
Behalf
> Of Jürgen Jaritsch
> Sent: Tuesday, July 7, 2020 3:15 PM
> To: mailto:nanog@nanog.org
> Subject: L2VPN/L2transport, Cumulus Linux & hardware suggestion
>
> Dear folks,
>
> have anyone already tried to run VXLAN/EVPN + “Bridge Layer 2 Protocol
> Tunneling” on Cumulus Linux as an replacement for classic MPLS
> L2VPN/VPWS (“xconnect”, l2circuit, VLL) ?
>
> I need to provide transparent Ethernet P2P virtual leased lines to my
> customers and these have to support stuff like LLDP, STP, LACP, etc.
> The transport L2 network is not THAT 

Re: L2VPN/L2transport, Cumulus Linux & hardware suggestion

[Saku Ytti]

On Wed, 8 Jul 2020 at 14:56, Adam Thompson  wrote:

> If jitter were defined anywhere vis-à-vis LACP, it would be _de jure_, not 
> _de facto_ as I said.

I suspect the de-facto domain you think of has modest population. As
jitter would only matter in case where protocol measures delay and
artificially adds static delay to compensate. This is not the case for
LACP (some balancing solutions do latency compensation), jitter is
immaterial.

> Yes, if you have *guaranteed* that TCP sessions hash uniquely to a single 
> link in your network, you might be able to successfully tunnel LACP (or 
> EtherChannel, or any other L1 link-bonding technique).  The last time I 
> attempted to do this on my network, I discovered that guarantee wasn't nearly 
> as ironclad as I expected.  I don't remember the gory details, at this 
> remove, sorry.  Maybe it wasn't TCP?  Maybe it wasn't the default hashing 
> algorithm? Dunno.

Jitter on software device connected directly has order of magnitude
higher jitter than operator pseudowire across globe, so adding tunnel
or not adding tunnel is not at all indicative of amount of jitter,
which still is not a metric that LACP cares about.

Internet works, because hashing works, it's not perfect, but it's good
enough that in practical Internet most links you traverse are relying
on hash to work, be it ECMP or LAG.


-- 
  ++ytti

Re: L2VPN/L2transport, Cumulus Linux & hardware suggestion

[Adam Thompson]

If jitter were defined anywhere vis-à-vis LACP, it would be _de jure_, not _de 
facto_ as I said.

Yes, if you have *guaranteed* that TCP sessions hash uniquely to a single link 
in your network, you might be able to successfully tunnel LACP (or 
EtherChannel, or any other L1 link-bonding technique).  The last time I 
attempted to do this on my network, I discovered that guarantee wasn't nearly 
as ironclad as I expected.  I don't remember the gory details, at this remove, 
sorry.  Maybe it wasn't TCP?  Maybe it wasn't the default hashing algorithm? 
Dunno.

-Adam

On Jul. 8, 2020 00:48, Saku Ytti  wrote:
Hey Adam,

On Wed, 8 Jul 2020 at 00:11, Adam Thompson  wrote:

> Good luck with tunnelling LACP, no matter what boxes you have - LACP has (de 
> facto) hard jitter requirements of under 1msec, or you'll be getting TCP 
> resets coming out your ears due to mis-ordered packets.

Can you elaborate on this? Where is LACP jitter defined and for what
purpose? We push packets around the globe in sub 200us jitter on any
given day, so 1000us isn't for us a particularly hard goal.

Only reason why I could imagine someone would care about jitter here
is if protocol measures delay (LACP doesn't) and relies on delay to
remain static and then balances per-packet or per-byte or otherwise
between multiple links.
However we of course put all packets from given TCP session to always
same LACP interface, so from TCP session POV, each LACP is exactly a 1
interface. Per-packet balancing on LACP is possible via a special
configuration, but anyone who does it, doesn't care about reordering,
no matter of jitter, because even in very stable jitter, the paths may
be unequal length and cause reordering.

LACP hellos are sent every 1s when in fast mode with 3s keepalive,
which also isn't particularly tight. We do have customers running LACP
over MPLS pseudowires over great distances.

--
  ++ytti

Re: L2VPN/L2transport, Cumulus Linux & hardware suggestion

[Mark Tinka]

On 8/Jul/20 12:42, Radu-Adrian Feurdean wrote:
> Errr sorry, but at the latest news, TCP was supposed to handle out of 
> order packets and reorder them before sending them to upper layer.
> Not to mention hashing that almost systematically makes that all packets of 
> the same TCP stream will be sent on the same link in an LAG (also on most if 
> not all ECMP implementations). 

True, but TCP is unaware about if the interface is a LAG or a native
port. It's just another tube.

We tested per-packet load balancing on the MX Trio line cards. The
traffic spread is perfect, but the OoO experience is atrocious.

Either settle for per-flow load balancing, move to a faster native port,
or stick with ECMP at the IP layer.

For instance, this is why we don't do LACP for backbones anymore. It is
far more reliable to have individual IP links, and let ECMP do its thing.

The only place we run LAG's in our network is 802.1Q trunks between
router and switch. But the moment those get to 4x 10Gbps, we go native
100Gbps (which has the added benefit of making per-service policing on
the router easier).

Mark.

Re: L2VPN/L2transport, Cumulus Linux & hardware suggestion

[Saku Ytti]

On Wed, 8 Jul 2020 at 13:46, Radu-Adrian Feurdean
 wrote:

> Errr sorry, but at the latest news, TCP was supposed to handle out of 
> order packets and reorder them before sending them to upper layer.
> Not to mention hashing that almost systematically makes that all packets of 
> the same TCP stream will be sent on the same link in an LAG (also on most if 
> not all ECMP implementations).

Yes, however new reno and the like are tuned for practical Internet.
Practical Internet has lot more packet loss than reordering, so TCP
algorithm considers any amount of reordering a packet loss, causing an
immediate resend, destroying your performance.

However, as you state TCP will only ever see single port LACP interfaces.

-- 
  ++ytti

Re: L2VPN/L2transport, Cumulus Linux & hardware suggestion

[Radu-Adrian Feurdean]

On Wed, Jul 8, 2020, at 00:09, Adam Thompson wrote:
> Good luck with tunnelling LACP, no matter what boxes you have - LACP 
> has (de facto) hard jitter requirements of under 1msec, or you'll be 
> getting TCP resets coming out your ears due to mis-ordered packets.

Errr sorry, but at the latest news, TCP was supposed to handle out of order 
packets and reorder them before sending them to upper layer.
Not to mention hashing that almost systematically makes that all packets of the 
same TCP stream will be sent on the same link in an LAG (also on most if not 
all ECMP implementations). 

> Miktotik 
> "carrier-grade" 

. 

Re: CGNAT Opensource with support to BPA, EIM/EIF, UPnP-PCP

[Mark Tinka]

On 7/Jul/20 19:23, JORDI PALET MARTINEZ via NANOG wrote:

>  
>
> There was, long time ago, something developed by ISC, but I think
> never completed and not updated …
>
>  
>
> 464XLAT is always a solution and becomes much cheaper, than CGN from
> vendors, even if you need to replace the CPEs. I’m doing that now with
> 25.000.000 subscribers … (slowed down by the Covid-19).
>

I have to agree... as "transition" tech. goes, 464XLAT is the least
intrusive solution, because as more of your customers acquire IPv6, the
demands you put on your 464XLAT systems reduce, naturally. It also means
you don't have to carry out yet-another transition to get the full IPv6
experience.

Mark.

Re: L2VPN/L2transport, Cumulus Linux & hardware suggestion

[Mark Tinka]

On 7/Jul/20 23:09, Adam Thompson wrote:
> Good luck with tunnelling LACP, no matter what boxes you have - LACP has (de 
> facto) hard jitter requirements of under 1msec, or you'll be getting TCP 
> resets coming out your ears due to mis-ordered packets.

Hmmh - this is odd.

We once provided a customer with an EoMPLS pw between Johannesburg and
London, which tunneled a number of L2CP's, including LACP.

Worked well, and I'd say jitter varied but never exceeded 20ms.

Mark.

Re: 60ms cross continent

[Mark Tinka]

On 7/Jul/20 21:58, Eric Kuhnke wrote:
> Watching the growth of terrestrial fiber (and PTP microwave) networks
> going inland from the west and east African coasts has been
> interesting. There's a big old C-band earth station on the hill above
> Freetown, Sierra Leone that was previously the capital's only link to
> the outside world. Obsoleted for some years now thanks to the
> submarine cable and landing station. I imagine they might keep things
> live as a backup path with a small C-band transponder MHz commit and
> SCPC modems linked to an earth station somewhere in Europe, but not
> with very much capacity or monthly cost.
>
> The landing station in Mogadishu had a similar effect.

The early years of submarine fibre in Africa always had satellite as a
backup. In fact, many satellite companies that served Africa with
Internet prior to submarine fibre were banking on subsea and terrestrial
failures to remain relevant. It worked between 2009 - 2013, when
terrestrial builds and operation had plenty of teething problems. Those
companies have since either disappeared or moved their services over to
fibre as well.

In that time, it has simply become impossible to have any backup
capacity on satellite anymore. There is too much active fibre bandwidth
being carried around and out of/into Africa for any satellite system to
make sense. Rather, diversifying terrestrial and submarine capacity is
the answer, and that is growing quite well.

Plenty of new cable systems that are launching this year, next year and
the next 3 years. At the moment, one would say there is sufficient
submarine capacity to keep the continent going in case of a major subsea
cut (like we saw in January when both the WACS and SAT-3 cables got cut
at the same time, and were out for over a month).

Satellite earth stations are not irrelevant, however. They still do get
used to provide satellite-based TV services, and can also be used for
media houses who need to hook up to their network to broadcast video
when reporting in the region (even though uploading a raw file back home
over the Internet is where the tech. has now gone).

Mark.