Re: Proposals at ITU-T for Internet Evolution Raise Serious Concerns; According to ISOC

[bzs]

It's short and worth a read though most anyone here can skip down
about 3/4 to the paragraph beginning with "First, Washington should
consolidate..." unless you really need an explanation of why DDoS is a
problem (not a complaint, their target audience might benefit.)

It's CFR, the "Council on Foreign Relations", that venerable
institution which is chock-a-block full of politicians etc many of
whose names you probably know (like former PMs, CEOs of firms like
Blackrock and the Carlyle Group), Angelina Jolie, Fareed Zakaria, etc.

They also publish "Foreign Affairs" which I subscribe to and is
worthwhile, only $40/year, six issues. You can probably pick an issue
up at a better magazine stand (e.g., one inside a bookstore like
Barnes & Noble.)

They provoke a lot of paranoia among the paranoid who are sure they're
the star chamber for George Soros or whatever the want to plug in, the
seat of the Illuminati (TM). I doubt it.

AS TO THE LINKED ARTICLE...

I always have this problem with such articles where my brain plugs in
"sidewalks" for "internet" like "thousands of people have been
murdered on sidewalks!", "criminals often use sidewalks to commit
nefarious financial crimes!", "when are we going to finally take the
problems of sidewalks seriously?!"

There's also a hard to miss "when will Washington do something!?" as
if it's entirely in the hands of the US tho admittedly the US may have
some influence. But such is CFR.

I could go on, I often do...

On August 11, 2022 at 18:09 j...@dataplane.org (John Kristoff) wrote:
 > On Thu, 11 Aug 2022 18:33:20 -0400
 > b...@theworld.com wrote:
 > 
 > > (it's only 25 pages and you probably can skip to section 6, maybe look
 > > at section 5, the rest is mostly "what a network is" padding.)
 > 
 > On that note...
 > 
 > I found this the following to a reasonably pragmatic and thoughtful,
 > albeit US-centric, compilation of policy thinking that is not from the
 > usual communications world:
 > 
 >    
 > 
 > I reached a couple weeks ago with my PC hat on to see if someone
 > representing that thinking would be interested in giving a presentation
 > at a future NANOG.  The contacts expressed at least a willingness to
 > find someone.
 > 
 > If anyone thinks it particularly worthwhile or not for me to press a bit
 > more, shoot me an email off line with your thoughts.
 > 
 > John

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Test Bed for New Protocol Re: Proposals at ITU-T for Internet Evolution Raise Serious Concerns; According to ISOC Re: 202208121501.AYC

[Abraham Y. Chen]

Dear bzs et el.:

1) I was made aware of the referenced "New IP" efforts about two years 
ago. After watching the below online discussion video recording, in 
particular, Andrew Sullivan's comments near the end (starting at time 
marker 00:53:42) that reminded us about thefull architecture versus 
building block approaches, the super importance of incremental 
deployability and the main issue of IPv6 being formally incompatible 
with IPv4, etc., I posted a feedback there.


https://www.internetgovernance.org/2020/09/23/what-is-the-future-of-internet-architecture/

2) Essentially, I offered our EzIP RAN (Regional Area Network) 
configuration as the "New IP" test bed. So that they could have a real 
life demonstration setup going within the existing Internet environment, 
yet independent of the current operations. It could avoid spending a lot 
of efforts on conceptually convincing others by theoretical analysis and 
reasoning. We had some follow-up exchanges. But, they continued on with 
their original way.





Regards,

Abe (2022-08-12 17:08 EDT)



On 2022-08-11 18:33, b...@theworld.com wrote:

This has been going around for at least two years, makes for some
great scary, click-bait headlines ("they propose an internet kill
switch! For China!", and so forth.)

Besides the obvious question, "by what authority will they move this
forward?" many of us looked at the proposals and they're, in a word,
idiocy.

   
https://www.itu.int/en/ITU-T/studygroups/2017-2020/13/Documents/Internet_2030%20.pdf

(it's only 25 pages and you probably can skip to section 6, maybe look
at section 5, the rest is mostly "what a network is" padding.)

I don't mean I don't like it or just want to criticize it, I mean
rambling, sophomoric idiocy.

But you have to give some credit to their coming up with:

   "Holographic Avatar Centric Communications"

as a core idea.

I'd say, like we said with ISO/OSI, etc etc etc: Implement a test bed
and we'll have a look!

On August 11, 2022 at 13:59n...@nanog.org  (Nanog News) wrote:
  > Proposals at ITU-T for Internet Evolution Raise Serious Concerns; According 
to
  > ISOC
  > Huawei, Chinese Carriers, and China want to Redesign a Prominent Part of the
  > Internet via a set of “New IP” Proposals
  >
  > Any new initiative has pros and cons, but according to ISOC (Internet 
Society),
  > the “New IP” proposals are threatening and should be discussed further.
  >
  > We caught up with Hosein Badran to give us the good, bad, and ugly of the 
“New
  > IP” proposals. Badran is a senior director for ISOC and leads the 
technology,
  > policy, and advocacy initiatives in Internet access, infrastructure, and 
trust
  > domains.
  >
  > READ NOW
  >
  >




--
This email has been checked for viruses by Avast antivirus software.
www.avast.com

Weekly Global IPv4 Routing Table Report

[Routing Table Analysis Role Account]

This is an automated weekly mailing describing the state of the Global
IPv4 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 https://thyme.apnic.net.

If you have any comments please contact Philip Smith .

IPv4 Routing Table Report   04:00 +10GMT Sat 13 Aug, 2022

  BGP Table (Global) as seen in Japan.

Report Website: https://thyme.apnic.net
Detailed Analysis:  https://thyme.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  906415
Prefixes after maximum aggregation (per Origin AS):  341627
Deaggregation factor:  2.65
Unique aggregates announced (without unneeded subnets):  438270
Total ASes present in the Internet Routing Table: 73570
Prefixes per ASN: 12.32
Origin-only ASes present in the Internet Routing Table:   63137
Origin ASes announcing only one prefix:   25993
Transit ASes present in the Internet Routing Table:   10433
Transit-only ASes present in the Internet Routing Table:394
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  55
Max AS path prepend of ASN (265020)  50
Prefixes from unregistered ASNs in the Routing Table:   976
Number of instances of unregistered ASNs:   976
Number of 32-bit ASNs allocated by the RIRs:  39963
Number of 32-bit ASNs visible in the Routing Table:   33196
Prefixes from 32-bit ASNs in the Routing Table:  158224
Number of bogon 32-bit ASNs visible in the Routing Table:12
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:512
Number of addresses announced to Internet:   3071462016
Equivalent to 183 /8s, 18 /16s and 202 /24s
Percentage of available address space announced:   83.0
Percentage of allocated address space announced:   83.0
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.6
Total number of prefixes smaller than registry allocations:  307865

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   236418
Total APNIC prefixes after maximum aggregation:   67273
APNIC Deaggregation factor:3.51
Prefixes being announced from the APNIC address blocks:  231493
Unique aggregates announced from the APNIC address blocks:96306
APNIC Region origin ASes present in the Internet Routing Table:   12876
APNIC Prefixes per ASN:   17.98
APNIC Region origin ASes announcing only one prefix:   3730
APNIC Region transit ASes present in the Internet Routing Table:   1756
Average APNIC Region AS path length visible:4.6
Max APNIC Region AS path length visible: 26
Number of APNIC region 32-bit ASNs visible in the Routing Table:   8107
Number of APNIC addresses announced to Internet:  773195776
Equivalent to 46 /8s, 22 /16s and 8 /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-151865
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:264514
Total ARIN prefixes after maximum aggregation:   120926
ARIN Deaggregation factor: 2.19
Prefixes being announced from the ARIN address blocks:   264776
Unique aggregates announced from the ARIN address blocks:127575
ARIN Region origin ASes present in the Internet Routing Table:19055
ARIN Prefixes per ASN: 

Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock)

[Dave Taht]

On Wed, Mar 9, 2022 at 9:11 AM Tim Howe  wrote:
>
> On Wed, 9 Mar 2022 11:22:49 -0500
> Tom Beecher  wrote:
>
> > > It doesn't take any OS upgrades for "getting everything to work on
> > > IPv6".  All the OS's and routers have supported IPv6 for more than a
> > > decade.
> > >
> >
> > There are lots of vendors, both inside and outside the networking space,
> > that have consistently released products with non-existant or broken IPv6
> > implementations. That includes smaller startups, as well as very big
> > names. An affirmative choice is often made to make sure v4 works , get the
> > thing out the door, and deal with v6 later, or if a big client complains.
>
> This a thousand times.  Don't believe the claims of IPv6
> support until you have fully tested it.  Almost no vendor is including
> any IPv6 testing in their QA process and nobody is including it in any
> of their support staff training.  Their labs may not even have v6
> capability.  Some of our biggest vendors who have supposedly supported
> v6 for over a decade have rudimentary, show-stopping bugs.  The support
> staff at these vendors have often never even seen a customer using v6,
> and they have no idea what it looks like on their own gear.

I have worked really hard to make sure ipv6 "just works" (still) in
the upcoming openwrt 22.03 release, treating it as *my* primary ip
stack, at least.

But I spent most of my time fixing a string of fq-codel & ATF wifi
regressions on the mt76 chips and (especially) not on testing the
various encapsulations, and am out of time.

If y'all care about ipv6, please lean in, test, and file bugs on these
last release candidates before it goes final?

https://downloads.openwrt.org/releases/22.03.0-rc6/targets/

The network you save may be your own.
>
> A subset of these vendors will listen to you and fix the
> problems.  Give them your support and loyalty.  I want to name names so
> bad...
>
> --TimH



-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC

Re: IERS ponders reverse leapsecond...

[Tony Finch]

Forrest Christian (List Account)  wrote:
>
> Hopefully there will be some movement next year when they're scheduled to
> discuss it again.It's unfortunate that the first negative leap second
> is likely to occur before then.

Not that soon! There is not likely to be a leap second for 5 years or so,
based on the current projections.

The value to keep an eye on is UT1-UTC which is required by ITU TF.460 to
be between -0.9s and +0.9s; leap seconds are added by the IERS to keep it
in range. Broadcast time signals include a DUT1 value that is UT1-UTC
rounded to 0.1s precision, which must be between -0.8s and +0.8s.

DUT1 is currently 0.0s.

In the last couple of decades, DUT1 has decreased by about 1ms per day (on
average) which requires a positive leap second every few years.

In 2016, the length of day was 1.5ms greater than 24h; since then the long
term estimated LoD has been fairly steadily decreasing. It dropped below
24h at the end of 2020, and it's now 0.34ms short. (The LoD increased
slowly in the second half of 2021, but it has been decreasing all this
year.)

Depending on the threshold the IERS chooses, the current long-term LoD
estimate suggests a negative leap second some time between the end of 2026
(for a 0.5s threshold) and the end of 2029 (for a 0.9s threshold). That is
without making any more complicated predictions based on the downward
trend of the estimated long-term LoD.

These numbers come from IERS Bulletin A
https://www.iers.org/IERS/EN/Publications/Bulletins/bulletins.html
analyzed by my program
https://github.com/fanf2/bulletin-a/

My blog article from when this issue became more well known:
https://dotat.at/@/2020-11-13-leap-second-hiatus.html

My other collected links on this topic
https://dotat.at/writing/time.html

-- 
Tony Finchhttps://dotat.at/
Thames, Dover, Wight, Portland, Plymouth: Northeast 3 to 5, veering
east 2 to 4 later in Thames, Dover and Wight. Smooth or slight, but in
Plymouth slight, occasionally moderate at first in west and smooth
later in northeast. Fair. Good.

Re: 400G forwarding - how does it work?

[Masataka Ohta]

sro...@ronan-online.com wrote:


How do you propose to fairly distribute market data feeds to the > market if 
not multicast?


Unicast with randomized order.

To minimize latency, bloated buffer should be avoided
and TCP with configured small (initial) RTT should be
used.

Masataka Ohta