Re: L2VPN/L2transport, Cumulus Linux & hardware suggestion

[Saku Ytti]

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: CGNAT Opensource with support to BPA, EIM/EIF, UPnP-PCP

[Mark Andrews]

> On 8 Jul 2020, at 03:23, JORDI PALET MARTINEZ via NANOG  
> wrote:
> 
> Hi Douglas,
>  
> There was, long time ago, something developed by ISC, but I think never 
> completed and not updated …

ISC did a DS-LITE implementation called AFTR.  This can be found at:

https://ftp.isc.org/isc/aftr/

> 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).
>  
> Regards,
> Jordi
> 
> @jordipalet
> 
>  
> 
>  
>  
> El 7/7/20 18:44, "NANOG en nombre de Douglas Fischer" 
>  fischerdoug...@gmail.com> escribió:
>  
> We are looking for a CGNAT solution open source based.
> 
> Yep, I know that basic CGNAT can be done with iptables / nftables, or PF / 
> IPFILTER / IPFW.
> 
> But I only know Open Source CGNAT recipes with predefined public-ports <-> 
> private IPs mapping.
> 
> What It brings two types of issues:
> A - The need to overprovision the number of private IPs (Considering Multiple 
> BNGs behind the CGN).
> B - The inability of those basic recipes to deal with incoming auxiliary 
> connections of p2p protocols (mostly used by games).
> 
> Te market solutions that I've dealt with solves those issues beautifully.
> a - Bulk-Port Allocation - BPA, avoid the need overprovisioning private 
> address that is not being used, and give us an excellent rate between public 
> IPv4 Address vs Private IP Address.
> b - The support of a framework of protocols(Ex.: UPnP, PCP, EIM/EIF, NAT-PMP, 
> etc...) ensure an acceptable quality of experience to end-users.
> 
> But, the market solution brings also some down-sides...
> - The cost, evidently.
> - The need for detouring the traffic that doesn't need CGNAT(Internal CDNs, 
> Internal Servers, etc), to stay on the license limits of those boxes, 
> sometimes brings some issues.
> 
> So, I and some friends are(for a long time) looking for an OpenSource 
> solution that can give us something near what the market solutions give.
> 
> Any of you guys ave some suggestions for that?
> 
> 
> P.S.: Yes, I know that IPv6 is the only real solution for that, but until 
> there, our customers still want to access a lot os p2p content(mostly audio 
> in game rooms, sip calls, and things like that.)
> 
> P.S.2: Yes, I also know that 464 could be a good possibility, but is not 
> possible in this scenario.
>  
> -- 
> Douglas Fernando Fischer
> Engº de Controle e Automação
> 
> **
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
> 
> This electronic message contains information which may be privileged or 
> confidential. The information is intended to be for the exclusive use of the 
> individual(s) named above and further non-explicilty authorized disclosure, 
> copying, distribution or use of the contents of this information, even if 
> partially, including attached files, is strictly prohibited and will be 
> considered a criminal offense. If you are not the intended recipient be aware 
> that any disclosure, copying, distribution or use of the contents of this 
> information, even if partially, including attached files, is strictly 
> prohibited, will be considered a criminal offense, so you must reply to the 
> original sender to inform about this communication and delete it.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

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

[Tony Wicks]

As someone who has spent quite a long time building CGNAT solutions I have some 
good news for you, there is an easy solution to your below point that works 
exceptionally well. The solution is dual stack IPv6, its trivial to route your 
IPv6 to bypass the CGNAT device you are using and pretty much all of the major 
CDN providers are fully IPv6 enabled. In the real world this halves the amount 
of traffic your CGNAT solution has to process. Gaming companies (Not Sony) 
are also starting to support V6 so that can be a win too. I’m not one of those 
V6 is the solution to everything engineers as I live in the real world, but in 
this case it absolutely is a good workable answer.

 


- The need for detouring the traffic that doesn't need CGNAT(Internal CDNs, 
Internal Servers, etc), to stay on the license limits of those boxes, sometimes 
brings some issues.

AW: L2VPN/L2transport, Cumulus Linux & hardware suggestion

[Jürgen Jaritsch]

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 big: max hops between VTEP is 4.
> 
> Anyone have suggestions for the below hardware request?
> #) 1-3U L2/L3 box
> #) 48x SFP28 / 1/10/25G
> #) 6x QSFP28 / 100G
> #) VXLAN/EVPN with L2 tunneling support or
> #) MPLS VPWS/l2circuit
> #) Dual PSU
> 
> 
> thanks & best regards
> Jürgen
> 

RE: L2VPN/L2transport, Cumulus Linux & hardware suggestion

[Adam Thompson]

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)
athomp...@merlin.mb.ca
www.merlin.mb.ca

> -Original Message-
> From: NANOG  On Behalf Of
> Jürgen Jaritsch
> Sent: Tuesday, July 7, 2020 3:15 PM
> To: 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 big: max hops between VTEP is 4.
> 
> Anyone have suggestions for the below hardware request?
> #) 1-3U L2/L3 box
> #) 48x SFP28 / 1/10/25G
> #) 6x QSFP28 / 100G
> #) VXLAN/EVPN with L2 tunneling support
> or
> #) MPLS VPWS/l2circuit
> #) Dual PSU
> 
> 
> thanks & best regards
> Jürgen
> 

Anyone from Edgecast/ Verizon Digital on here

[Rob See]

Hi, 

We are having problems with traffic to Edgecast from our netblock getting TCP 
Reset. The big thing it seems to be causing problems with is Twitter. Anyone 
else experiencing this problem, and does anyone have a contact there ? Their 
tier 1 support didn't want to talk to us because we aren't a direct customer. 

-- 
Thanks, 
-Rob 

L2VPN/L2transport, Cumulus Linux & hardware suggestion

[Jürgen Jaritsch]

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 big: max hops between VTEP is 4.

Anyone have suggestions for the below hardware request?
#) 1-3U L2/L3 box
#) 48x SFP28 / 1/10/25G
#) 6x QSFP28 / 100G
#) VXLAN/EVPN with L2 tunneling support
or
#) MPLS VPWS/l2circuit
#) Dual PSU


thanks & best regards
Jürgen

Re: 60ms cross continent

[Eric Kuhnke]

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.



On Tue, Jul 7, 2020 at 1:45 AM Mark Tinka  wrote:

>
>
> On 7/Jul/20 10:07, Eric Kuhnke wrote:
> > The most noteworthy thing I'm seeing in C band these days, is many
> > customers formerly 100% reliant upon it shifting their traffic to
> > newly built submarine fiber routes.
>
> Before most of Africa had submarine fibre, a lot of our traffic was
> carried on C-Band.
>
> In the decade preceding the arrival of submarine fibre, we reduced costs
> by moving to Inclined Orbit satellites, which were mainly operated on
> Ku-Band. So outages due to rain were a normal and accepted part of doing
> business. ISP's that maintained C-Band satellites survived rain fade,
> but had much higher operating costs.
>
> Nowadays, satellite services are generally used in remote locations, and
> for specific applications. Submarine fibre is the norm.
>
> Mark.
>

pandemic stories about network ops/engineering

[Mehmet Akcin]

hey there,

Millions of people working from home, I am sure there was a lot of hard
work from network and systems teams to build and upgrade capacity before
and during the covid19 pandemic.

I have a youtube series I am focusing on internet infrastructure and new
normal, I would like to discover new stories about how network teams have
handled unique stories during this time. Something different where you
think it's important for people to know.

I think there are many heroes who made this stay at home possible with
enabling technology and my goal is to give these individuals a little bit
visibility they deserve. For example youtube stream
https://youtu.be/wFmZadETNDQ

if you have suggestions about guests, please contact offlist.

thank you
Mehmet

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

[Jared Geiger]

DANOS 2005 seems to support a lot of your requirements.
https://danosproject.atlassian.net/wiki/spaces/DAN/pages/320634926/DANOS+2005+Release+Notes

So if you have an x86 box with supported NICS you should be able to get
some decent performance from it.

The major gotcha in this release is I think route-maps, prefix-lists,
access-lists with BGP are broken.

On Tue, Jul 7, 2020 at 9:44 AM Douglas Fischer 
wrote:

> We are looking for a CGNAT solution open source based.
>
> Yep, I know that basic CGNAT can be done with iptables / nftables, or PF /
> IPFILTER / IPFW.
>
> But I only know Open Source CGNAT recipes with predefined public-ports <->
> private IPs mapping.
>
> What It brings two types of issues:
> A - The need to overprovision the number of private IPs (Considering
> Multiple BNGs behind the CGN).
> B - The inability of those basic recipes to deal with incoming auxiliary
> connections of p2p protocols (mostly used by games).
>
> Te market solutions that I've dealt with solves those issues beautifully.
> a - Bulk-Port Allocation - BPA, avoid the need overprovisioning private
> address that is not being used, and give us an excellent rate between
> public IPv4 Address vs Private IP Address.
> b - The support of a framework of protocols(Ex.: UPnP, PCP, EIM/EIF,
> NAT-PMP, etc...) ensure an acceptable quality of experience to end-users.
>
> But, the market solution brings also some down-sides...
> - The cost, evidently.
> - The need for detouring the traffic that doesn't need CGNAT(Internal
> CDNs, Internal Servers, etc), to stay on the license limits of those boxes,
> sometimes brings some issues.
>
> So, I and some friends are(for a long time) looking for an OpenSource
> solution that can give us something near what the market solutions give.
>
> Any of you guys ave some suggestions for that?
>
>
> P.S.: Yes, I know that IPv6 is the only real solution for that, but until
> there, our customers still want to access a lot os p2p content(mostly audio
> in game rooms, sip calls, and things like that.)
>
> P.S.2: Yes, I also know that 464 could be a good possibility, but is not
> possible in this scenario.
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
>

RE: rfc4271 ORIGIN/path of default route, should the value be 0 or 2?

[Drew Weaver]

Okay,

In my use case it's just a default route being distributed by a router that has 
the full routing table to an access router in the same ASN. It's not being sent 
to other ASNs or anything of that sort.

I was just curious as to why Cisco sets it to internal and Arista sets it to 
invalid.

Thanks,
-Drew


-Original Message-
From: NANOG  On Behalf Of 
Olivier Benghozi
Sent: Tuesday, July 7, 2020 12:47 PM
To: nanog@nanog.org
Subject: Re: rfc4271 ORIGIN/path of default route, should the value be 0 or 2?

Debatable, certainly, as the Origin attribute should probably be considered as 
dead/obsolete and therefore it is probably a good practice to always set/reset 
it to internal.
A number of networks already do this (including level3 by example).

After all, the origin attribute was only designed to allow a «smooth» 
transition between EGP and BGP (that is, it was useful during a few years for a 
few networks several decades ago).

> Le 7 juil. 2020 à 15:47, Saku Ytti  a écrit :
> 
> Debatable, but:
> Internal is more accurate if you redistribute default from routing 
> protocol, such as static.
> Unknown is more accurate if you just generate it in BGP, without having it.
> 
> Functional difference is best-path selection algorithm. Origin can be 
> used to bypass hot-potato policies of peers, by forcing them to carry 
> packets longer inside their network. If your policy is hot-potato, 
> then you should reset Origin on received external routes.

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

[JORDI PALET MARTINEZ via NANOG]

Hi Douglas,

 

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).

 

Regards,

Jordi

@jordipalet

 

 

 

El 7/7/20 18:44, "NANOG en nombre de Douglas Fischer" 
 escribió:

 

We are looking for a CGNAT solution open source based.

Yep, I know that basic CGNAT can be done with iptables / nftables, or PF / 
IPFILTER / IPFW.

But I only know Open Source CGNAT recipes with predefined public-ports <-> 
private IPs mapping.

What It brings two types of issues:
A - The need to overprovision the number of private IPs (Considering Multiple 
BNGs behind the CGN).
B - The inability of those basic recipes to deal with incoming auxiliary 
connections of p2p protocols (mostly used by games).

Te market solutions that I've dealt with solves those issues beautifully.
a - Bulk-Port Allocation - BPA, avoid the need overprovisioning private address 
that is not being used, and give us an excellent rate between public IPv4 
Address vs Private IP Address.
b - The support of a framework of protocols(Ex.: UPnP, PCP, EIM/EIF, NAT-PMP, 
etc...) ensure an acceptable quality of experience to end-users.

But, the market solution brings also some down-sides...
- The cost, evidently.
- The need for detouring the traffic that doesn't need CGNAT(Internal CDNs, 
Internal Servers, etc), to stay on the license limits of those boxes, sometimes 
brings some issues.

So, I and some friends are(for a long time) looking for an OpenSource solution 
that can give us something near what the market solutions give.

Any of you guys ave some suggestions for that?


P.S.: Yes, I know that IPv6 is the only real solution for that, but until 
there, our customers still want to access a lot os p2p content(mostly audio in 
game rooms, sip calls, and things like that.)

P.S.2: Yes, I also know that 464 could be a good possibility, but is not 
possible in this scenario.

 

-- 

Douglas Fernando Fischer
Engº de Controle e Automação



**
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.

Re: rfc4271 ORIGIN/path of default route, should the value be 0 or 2?

[Olivier Benghozi]

Debatable, certainly, as the Origin attribute should probably be considered as 
dead/obsolete and therefore it is probably a good practice to always set/reset 
it to internal.
A number of networks already do this (including level3 by example).

After all, the origin attribute was only designed to allow a «smooth» 
transition between EGP and BGP (that is, it was useful during a few years for a 
few networks several decades ago).

> Le 7 juil. 2020 à 15:47, Saku Ytti  a écrit :
> 
> Debatable, but:
> Internal is more accurate if you redistribute default from routing
> protocol, such as static.
> Unknown is more accurate if you just generate it in BGP, without having it.
> 
> Functional difference is best-path selection algorithm. Origin can be
> used to bypass hot-potato policies of peers, by forcing them to carry
> packets longer inside their network. If your policy is hot-potato,
> then you should reset Origin on received external routes.

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

[Douglas Fischer]

We are looking for a CGNAT solution open source based.

Yep, I know that basic CGNAT can be done with iptables / nftables, or PF /
IPFILTER / IPFW.

But I only know Open Source CGNAT recipes with predefined public-ports <->
private IPs mapping.

What It brings two types of issues:
A - The need to overprovision the number of private IPs (Considering
Multiple BNGs behind the CGN).
B - The inability of those basic recipes to deal with incoming auxiliary
connections of p2p protocols (mostly used by games).

Te market solutions that I've dealt with solves those issues beautifully.
a - Bulk-Port Allocation - BPA, avoid the need overprovisioning private
address that is not being used, and give us an excellent rate between
public IPv4 Address vs Private IP Address.
b - The support of a framework of protocols(Ex.: UPnP, PCP, EIM/EIF,
NAT-PMP, etc...) ensure an acceptable quality of experience to end-users.

But, the market solution brings also some down-sides...
- The cost, evidently.
- The need for detouring the traffic that doesn't need CGNAT(Internal CDNs,
Internal Servers, etc), to stay on the license limits of those boxes,
sometimes brings some issues.

So, I and some friends are(for a long time) looking for an OpenSource
solution that can give us something near what the market solutions give.

Any of you guys ave some suggestions for that?


P.S.: Yes, I know that IPv6 is the only real solution for that, but until
there, our customers still want to access a lot os p2p content(mostly audio
in game rooms, sip calls, and things like that.)

P.S.2: Yes, I also know that 464 could be a good possibility, but is not
possible in this scenario.

-- 
Douglas Fernando Fischer
Engº de Controle e Automação

Re: Study on understanding email configuration quality

[Mike Hammett]

You might want to check out the mailops mailing list as well, for people a bit 
more into email. 




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

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

- Original Message -

From: "Tobias Fiebig"  
To: nanog@nanog.org 
Sent: Tuesday, July 7, 2020 6:28:10 AM 
Subject: Study on understanding email configuration quality 

Dear all, 
I am a researcher at TU Delft in the Netherlands, looking into Security & 
Protocol Adoption. 
My student Olamide is looking into how well email setups are maintained around 
the globe. 
For this, we need many people, ideally from smaller providers, i.e., with non 
gmail/hotmail/yahoo addresses, to send us emails. 

Please consider participating in this study, and sharing it in your networks. 
To help us, please follow the instructions at: 

https://www.email-security-scans.org/ 

Important caveat: If your mailer validates recipient addresses before accepting 
mails, you might be unable to send to destination addresses that are (a) only 
resolvable via IPv6 only, or (b) Have broken DNSSEC, which we use to test 
DNSSEC validation. If this is the case, please just remove the 1-3 offending 
addresses from the To: header. Please also note that our test setups will test 
whether the host delivering mails to us is an open relay. Also note that you 
may receive bounces from your mailserver for some of the destination addresses, 
e.g., if mails can not be delivered via IPv6, or if your mail-setup validates 
DANE records for our DANE test domain. We do _not_ need a copy of those 
bounces. 

In case you want to get results for a domain you operate or use early, please 
just drop me an email from the same domain and delivering servers after you 
participated, and I will share the data with you. :-) 

Met vriendelijke groet, 

Dr.-Ing. Tobias Fiebig, 
Assistant Professor / Universitair Docent 
Department Engineering Systems and Services 

Informatie- en Communicatie Technologie (ICT) 

TU Delft / Dept. ESS 
Faculty of Technology, Policy and Management (TBM) 
Building 31 
Jaffalaan 5 - room B3.170 
2628 BX Delft 

Study on understanding email configuration quality

[Tobias Fiebig]

Dear all,
I am a researcher at TU Delft in the Netherlands, looking into Security & 
Protocol Adoption.
My student Olamide is looking into how well email setups are maintained around 
the globe. 
For this, we need many people, ideally from smaller providers, i.e., with non 
gmail/hotmail/yahoo addresses, to send us emails.
 
Please consider participating in this study, and sharing it in your networks. 
To help us, please follow the instructions at:

 
https://www.email-security-scans.org/   

Important caveat: If your mailer validates recipient addresses before accepting 
mails, you might be unable to send to destination addresses that are (a) only 
resolvable via IPv6 only, or (b) Have broken DNSSEC, which we use to test 
DNSSEC validation. If this is the case, please just remove the 1-3 offending 
addresses from the To: header. Please also note that our test setups will test 
whether the host delivering mails to us is an open relay. Also note that you 
may receive bounces from your mailserver for some of the destination addresses, 
e.g., if mails can not be delivered via IPv6, or if your mail-setup validates 
DANE records for our DANE test domain. We do _not_ need a copy of those bounces.

In case you want to get results for a domain you operate or use early, please 
just drop me an email from the same domain and delivering servers after you 
participated, and I will share the data with you. :-)

Met vriendelijke groet,
 
Dr.-Ing. Tobias Fiebig,
Assistant Professor / Universitair Docent
Department Engineering Systems and Services

Informatie- en Communicatie Technologie (ICT)
 
TU Delft / Dept. ESS
Faculty of Technology, Policy and Management (TBM)
Building 31
Jaffalaan 5 - room B3.170
2628 BX  Delft

Re: 60ms cross continent

[j k]

Any idea what network protocol(s) used with Starlink?

On Tue, Jul 7, 2020, 5:08 AM Saku Ytti  wrote:

> On Tue, 7 Jul 2020 at 06:35, Harry McGregor 
> wrote:
>
> > Once the laser based inter-sat links are running (Starlink 2.0?), it
> should be lower latency vs Fiber.
>
> I understood it's not clear if this will ever happen. In local
> constellation it might, but supposedly technology does not currently
> actually exist to do it between constellations. I don't understand the
> topic at all, but I got impression that the precision of timing and
> accuracy of aiming needed is actually a very hard problem.
>
> But agreed, should sat2sat communication become possible, there are
> many legs where starlink latency will improve upon terrestrial.
>
> --
>   ++ytti
>

Re: rfc4271 ORIGIN/path of default route, should the value be 0 or 2?

[Saku Ytti]

Hey,

> I don’t believe that it has a functionality impact but I would like to know 
> which one you think follows the RFC more closely.

Debatable, but:
Internal is more accurate if you redistribute default from routing
protocol, such as static.
Unknown is more accurate if you just generate it in BGP, without having it.

Functional difference is best-path selection algorithm. Origin can be
used to bypass hot-potato policies of peers, by forcing them to carry
packets longer inside their network. If your policy is hot-potato,
then you should reset Origin on received external routes.



-- 
  ++ytti

rfc4271 ORIGIN/path of default route, should the value be 0 or 2?

[Drew Weaver]

Howdy,

I am using a multi-vendor network and validating the inter-operability.

When I announce a default route to a BGP peer using default-originate applied 
to the peer group/neighbor configuration:

in vendor A that route is sent with ORIGIN 0 (internal)
in vendor B that route is sent with ORIGIN 2 (Unknown)

Downstream it looks like this:

 Network  Next HopMetric LocPrf Weight Path
* i 0.0.0.0  192.168.27.1  100  0 ?
*>i  192.168.25.1 0100  0 i
* i  192.168.27.2  100  0 ?

I don't believe that it has a functionality impact but I would like to know 
which one you think follows the RFC more closely.

https://tools.ietf.org/html/rfc4271

thanks,
-Drew

Re: 60ms cross continent

[Saku Ytti]

On Tue, 7 Jul 2020 at 06:35, Harry McGregor  wrote:

> Once the laser based inter-sat links are running (Starlink 2.0?), it should 
> be lower latency vs Fiber.

I understood it's not clear if this will ever happen. In local
constellation it might, but supposedly technology does not currently
actually exist to do it between constellations. I don't understand the
topic at all, but I got impression that the precision of timing and
accuracy of aiming needed is actually a very hard problem.

But agreed, should sat2sat communication become possible, there are
many legs where starlink latency will improve upon terrestrial.

-- 
  ++ytti

Re: 60ms cross continent

[Mark Tinka]

On 7/Jul/20 10:07, Eric Kuhnke wrote:
> The most noteworthy thing I'm seeing in C band these days, is many
> customers formerly 100% reliant upon it shifting their traffic to
> newly built submarine fiber routes.

Before most of Africa had submarine fibre, a lot of our traffic was
carried on C-Band.

In the decade preceding the arrival of submarine fibre, we reduced costs
by moving to Inclined Orbit satellites, which were mainly operated on
Ku-Band. So outages due to rain were a normal and accepted part of doing
business. ISP's that maintained C-Band satellites survived rain fade,
but had much higher operating costs.

Nowadays, satellite services are generally used in remote locations, and
for specific applications. Submarine fibre is the norm.

Mark.

Re: 60ms cross continent

[Mark Tinka]

On 7/Jul/20 08:51, Denys Fedoryshchenko wrote:

>  
> And as Ku is often covering specific regions, often it means rainy
> days for most transponder customers.
> This is why in zones closer to equator, with their long-term monsoon,
> C-Band was only option,
> no idea about now.

In much of Africa, the largest satellite TV provider has been running on
Ku-Band into homes for several years now.

I'm not sure if they still support C-Band services for specialized
requirements. But all consumers have been on Ku-Band for a while now.

Heavy rain does cause outages, but overcasts do not.

If you are lucky to have an FTTH service and you are hit with rain, you
can turn to their app and stream the same live channels while the rain
falls.

Mark.

Re: 60ms cross continent

[Eric Kuhnke]

The most noteworthy thing I'm seeing in C band these days, is many
customers formerly 100% reliant upon it shifting their traffic to newly
built submarine fiber routes.

On Mon, Jul 6, 2020, 11:51 PM Denys Fedoryshchenko <
nuclear...@nuclearcat.com> wrote:

> On 2020-07-07 08:32, Eric Kuhnke wrote:
> > "no clouds" is overstating the effect somewhat. I've operated a number
> > of mission critical Ku band based systems that met four nines of
> > overall link uptime. The operational effect of a cloud that isn't an
> > active downpour of rain is negligible. Continual overcast of clouds is
> > not much of a problem at all, it's active rain rate in mm/hour and its
> > statistical likelihood, climate parameters of the location.
> >
> > Yes, during rain fade events, current generation VSAT modems will drop
> > all the way down to BPSK 1/2 code rate to maintain a link, with
> > corresponding effect on real world throughput in kbps each direction,
> > but entirely dropping a link is rare.
> >
> BPSK 1/2 is quite extreme. In my case it was 32APSK 8/9 at 36Mhz
> transponder
> (yes it was quite large antenna), ~140Mbit, so switching to 1/2 BPSK
> will make it
> ~16Mbit/s, which is pretty useless for telco purposes.
> For corporate, end-users, with QoS - it can be ok, but still depends on
> climatic zone.
> Remember, it is not downlink only issue, but uplink too. And depends on
> antenna elevation angle
> as well.
> Even for end-user it is not fun to have 1/10 of capacity, most likely
> means unable to do
> video conferencing anymore, for few days, just because it is few rainy
> days.
> And as Ku is often covering specific regions, often it means rainy days
> for most transponder customers.
> This is why in zones closer to equator, with their long-term monsoon,
> C-Band was only option,
> no idea about now.
>

Re: 60ms cross continent

[Denys Fedoryshchenko]

On 2020-07-07 08:32, Eric Kuhnke wrote:

"no clouds" is overstating the effect somewhat. I've operated a number
of mission critical Ku band based systems that met four nines of
overall link uptime. The operational effect of a cloud that isn't an
active downpour of rain is negligible. Continual overcast of clouds is
not much of a problem at all, it's active rain rate in mm/hour and its
statistical likelihood, climate parameters of the location.

Yes, during rain fade events, current generation VSAT modems will drop
all the way down to BPSK 1/2 code rate to maintain a link, with
corresponding effect on real world throughput in kbps each direction,
but entirely dropping a link is rare.

BPSK 1/2 is quite extreme. In my case it was 32APSK 8/9 at 36Mhz 
transponder
(yes it was quite large antenna), ~140Mbit, so switching to 1/2 BPSK 
will make it

~16Mbit/s, which is pretty useless for telco purposes.
For corporate, end-users, with QoS - it can be ok, but still depends on 
climatic zone.
Remember, it is not downlink only issue, but uplink too. And depends on 
antenna elevation angle

as well.
Even for end-user it is not fun to have 1/10 of capacity, most likely 
means unable to do
video conferencing anymore, for few days, just because it is few rainy 
days.
And as Ku is often covering specific regions, often it means rainy days 
for most transponder customers.
This is why in zones closer to equator, with their long-term monsoon, 
C-Band was only option,

no idea about now.