Re: BGP full feed for testing purposes

[Łukasz Bromirski]

Blazej,

> On 5 Aug 2020, at 23:13, Blažej Krajňák  wrote:
> 
> Hi Lukasz,
> 
> your feed is working well. Feed from Poland to me to Slovakia is better than 
> expected :) It's my first live BGP full feed ever so I really appreciate you.
> Will this instance run for a longer time?

Yep. I have no reasons to drop it.

Right now I have like 5 to 10 sessions in peak, most people come, get feed,
reset session couple of times and go away.

I’m finishing writing some short ‘howto’ style doc to explain how to use
this feed for egress traffic engineering when you have multiple ISPs and
no BGP with them.

— 
./

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 08 Aug, 2020

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  815787
Prefixes after maximum aggregation (per Origin AS):  311122
Deaggregation factor:  2.62
Unique aggregates announced (without unneeded subnets):  393770
Total ASes present in the Internet Routing Table: 68891
Prefixes per ASN: 11.84
Origin-only ASes present in the Internet Routing Table:   59209
Origin ASes announcing only one prefix:   24676
Transit ASes present in the Internet Routing Table:9682
Transit-only ASes present in the Internet Routing Table:297
Average AS path length visible in the Internet Routing Table:   4.4
Max AS path length visible:  42
Max AS path prepend of ASN ( 22394)  38
Prefixes from unregistered ASNs in the Routing Table:   814
Number of instances of unregistered ASNs:   815
Number of 32-bit ASNs allocated by the RIRs:  32895
Number of 32-bit ASNs visible in the Routing Table:   27110
Prefixes from 32-bit ASNs in the Routing Table:  125271
Number of bogon 32-bit ASNs visible in the Routing Table:10
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:447
Number of addresses announced to Internet:   2845089792
Equivalent to 169 /8s, 148 /16s and 160 /24s
Percentage of available address space announced:   76.8
Percentage of allocated address space announced:   76.8
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.5
Total number of prefixes smaller than registry allocations:  272740

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   215275
Total APNIC prefixes after maximum aggregation:   63096
APNIC Deaggregation factor:3.41
Prefixes being announced from the APNIC address blocks:  209158
Unique aggregates announced from the APNIC address blocks:85948
APNIC Region origin ASes present in the Internet Routing Table:   10784
APNIC Prefixes per ASN:   19.40
APNIC Region origin ASes announcing only one prefix:   3036
APNIC Region transit ASes present in the Internet Routing Table:   1589
Average APNIC Region AS path length visible:4.6
Max APNIC Region AS path length visible: 27
Number of APNIC region 32-bit ASNs visible in the Routing Table:   5864
Number of APNIC addresses announced to Internet:  769281664
Equivalent to 45 /8s, 218 /16s and 78 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-141625
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:240074
Total ARIN prefixes after maximum aggregation:   110262
ARIN Deaggregation factor: 2.18
Prefixes being announced from the ARIN address blocks:   237316
Unique aggregates announced from the ARIN address blocks:115821
ARIN Region origin ASes present in the Internet Routing Table:18560
ARIN Prefixes per ASN:12.79
ARIN 

Re: ISPs are hit hardest by COVID-19 disruption

[Rafael Possamai]

This reminded me of a quote I read a long time ago: "Most people use statistics 
like a drunk man uses a lamppost; more for support than illumination"

Re: ISPs are hit hardest by COVID-19 disruption

[Blake Hudson]

The findings from Thousand Eyes seems reasonable and data driven, but Mr 
Barker's article on that report seems to have reached the wrong 
conclusions and added a sensational headline that doesn't jive with the 
data at all (IMO).


My take on the Thousand Eyes findings: ISP's performed more planned 
upgrades in March-June than they did in January. Covid may have been a 
kick in the butt for ISPs to finish projects that were already in the 
works or start new upgrade projects. Nothing to see here.



On 8/6/2020 9:20 PM, Hank Nussbacher wrote:


https://betanews.com/2020/08/04/isps-covid-19-disruption/


Really?


-Hank


Caveat: The views expressed above are solely my own and do not express 
the views or opinions of my employer

Re: Has virtualization become obsolete in 5G?

[Mark Tinka]

On 7/Aug/20 14:40, sro...@ronan-online.com wrote:

> I can promise 100% that in LARGE US 5G carriers this is exactly what
> is happening. Virtual CU’s and DU’s, running on traditional
> virtualization platforms and in containers.
>
> An entire multi-vendor containerized 5G which replaces the 4G EPC is
> also in testing, and close to production deployment.
>
> The only non-virtualized devices in the RAN network would be the Radio
> Units (RU).

With any luck, we shall see an "experience preso" at a NOG near us, some
time.

This would certainly be most interesting for the community.

Mark.

Re: Has virtualization become obsolete in 5G?

[sronan]

I can promise 100% that in LARGE US 5G carriers this is exactly what is 
happening. Virtual CU’s and DU’s, running on traditional virtualization 
platforms and in containers.

An entire multi-vendor containerized 5G which replaces the 4G EPC is also in 
testing, and close to production deployment.

The only non-virtualized devices in the RAN network would be the Radio Units 
(RU).



> On Aug 7, 2020, at 5:15 AM, Mark Tinka  wrote:
> 
>  
> 
> On 7/Aug/20 09:35, Etienne-Victor Depasquale wrote:
> 
>> 5G introduced a number of functional units (RU, DU and CU) in the radio 
>> access network and disaggregation is flexible. Service intelligence doesn't 
>> need to come from the core; it may be far out in the edge. At the RU, there 
>> is packetized data ready for transmission over eCPRI to the DU. In this 
>> webinar (@6:07), there's a bit of a projection about use of service 
>> intelligence.
> 
> In my old, the plan is what happens :-).
> 
> Mark.

Re: Has virtualization become obsolete in 5G?

[Mark Tinka]

On 7/Aug/20 09:35, Etienne-Victor Depasquale wrote:

> 5G introduced a number of functional units (RU, DU and CU) in the
> radio access network and disaggregation is flexible. Service
> intelligence doesn't need to come from the core; it may be far out in
> the edge. At the RU, there is packetized data ready for transmission
> over eCPRI to the DU. In this webinar
>  (@6:07),
> there's a bit of a projection about use of service intelligence.

In my old age, the plan is what happens :-).

Mark.

Re: Has virtualization become obsolete in 5G?

[Mark Tinka]

On 7/Aug/20 09:35, Etienne-Victor Depasquale wrote:

> 5G introduced a number of functional units (RU, DU and CU) in the
> radio access network and disaggregation is flexible. Service
> intelligence doesn't need to come from the core; it may be far out in
> the edge. At the RU, there is packetized data ready for transmission
> over eCPRI to the DU. In this webinar
>  (@6:07),
> there's a bit of a projection about use of service intelligence.

In my old, the plan is what happens :-).

Mark.

Re: Has virtualization become obsolete in 5G?

[Etienne-Victor Depasquale]

>
> Well, I doubt the radio has any service intelligence. It's just a conduit.
> Depending on why two devices on the same radio have to communicate, a
> cleverer system deep in the core would need to process that before handing
> it back to the radio network.
>
5G introduced a number of functional units (RU, DU and CU) in the radio
access network and disaggregation is flexible. Service intelligence doesn't
need to come from the core; it may be far out in the edge. At the RU, there
is packetized data ready for transmission over eCPRI to the DU. In this
webinar  (@6:07),
there's a bit of a projection about use of service intelligence.

Cheers,

Etienne

On Thu, Aug 6, 2020 at 10:21 AM Mark Tinka  wrote:

>
>
> On 5/Aug/20 18:34, Etienne-Victor Depasquale wrote:
>
>
> Release 16 is just out and if it has delivered the 5G vision,
> latency between devices connected over the same radio interface
> (which I take to mean the same gNB),
> is now < 1 ms.
> Isn't that a good improvement?
>
>
> Well, I doubt the radio has any service intelligence. It's just a conduit.
> Depending on why two devices on the same radio have to communicate, a
> cleverer system deep in the core would need to process that before handing
> it back to the radio network.
>
> Of course, it makes the case for deploying services at each base station
> to localize services, but that could get expensive for an entire radio
> network, particularly within a 100km Metro where fibre latency will remain
> at ±1ms anyway.
>
> Not to mention that with the exception of things like cars in a traffic
> jam or on the same piece of highway, the chances of two devices talking to
> each other over the same radio can't always be guaranteed.
>
>
>
> I understand that this is a key enabler for driverless cars (real-time,
> automated vehicle navigation) - the V2I part of V2X.
>
>
> I look forward to seeing this.
>
>
>
> Here's one blogger who agrees with you
> 
> (@19:46) about coverage - and count me in.
> But, I guess, it's fair to say that this is the chicken-and-egg conundrum
> :)
>
>
> The video won't play. Could be my browser.
>
> Anyway, time will tell. I see 5G roll-out density like rolling out fibre
> in places only where the postal service can get to. But I hope I'm wrong.
>
> Mark.
>


-- 
Ing. Etienne-Victor Depasquale
Assistant Lecturer
Department of Communications & Computer Engineering
Faculty of Information & Communication Technology
University of Malta
Web. https://www.um.edu.mt/profile/etiennedepasquale