Subnet Management - tdb26 (NNS)

[Lorimer]

This topic is intended to capture Subnet Management activities over time for the tdb26 subnet, providing a place to ask questions and make observations about the management of this subnet.

At the time of creating this topic the current subnet configuration is as follows:

Expand

{
  "version": 44369,
  "records": [
    {
      "key": "subnet_record_tdb26-jop6k-aogll-7ltgs-eruif-6kk7m-qpktf-gdiqx-mxtrf-vb5e6-eqe",
      "version": 44369,
      "value": {
        "membership": [
          "ncr4b-rasb7-tueb3-n4uos-5nxou-3wbxv-xmyt3-wfdsd-vu4b6-5x3cp-aqe",
          "ltzjy-54bkf-bwynr-rcqst-ncpe6-qlg4x-tvhmp-73bm5-75e7u-t7c7s-eae",
          "yahq2-6rnmm-n7ubm-q76zd-256dl-5f7k6-jxx5l-njyo2-hl7tk-sqcet-6ae",
          "w2sev-mtuls-aa7m5-cdjgi-5vipg-2jn7i-4awvf-o6suu-73ebs-sw5db-kqe",
          "gvm7l-ds4n6-vkyjn-gwalp-3vdo6-qfmq7-pxhu4-zvqcu-ozvb7-qz3gr-vqe",
          "mjte3-dopva-7tttu-5hnnu-q572b-p3wwy-b56of-4q6h7-hbtf4-f3m32-tae",
          "tn2ne-tskw6-dfk3n-urdmd-krtq6-tcebq-dx2xr-kokq7-eood7-fadkg-5qe",
          "2ftux-ivgjc-t4i2d-lq5hs-myjdg-3h2pz-l2ddl-nsxfc-wlaq7-fkbc5-6ae",
          "4rpiz-7w7bf-smfm5-u7j3c-we6q7-qehxb-5lqnq-tjqsh-f7xu4-ihpao-zqe",
          "2tk2h-7snvn-clgy3-g33vp-fc57w-ptljs-xujfq-fu47q-ludhi-g7zzf-xqe",
          "noos2-mfe4u-r4gp3-jrjow-ancs2-ncakm-zi72z-zzcbg-uam7p-d4s6s-6qe",
          "jmuoq-7kbey-cbtmm-zlz6t-chwt6-dk7ly-d3jim-5nuu4-y5tou-l5egg-7qe",
          "onv2n-rm4ad-mgpnn-iiheu-6a76r-crgmo-wxpwt-dqf6y-n7gcf-5po4q-2qe",
          "5iihd-fkroy-ow5zp-hlvwz-bsgbl-mecta-kxubm-6adxr-ckcu6-prsus-fqe",
          "fd5e4-a2xzl-lxu7m-kjvn6-2arnt-jghro-rdrgx-zvvkd-j2hza-pbwl4-5qe",
          "wazkf-2xehg-y26ek-2uq64-pkrbh-6frmq-4q7lf-5gaya-44q4p-v5r5z-cqe",
          "74qsa-j6jno-nmxmb-7jpf5-u6nig-g7hgo-thvjm-6f6zu-c2ugp-krple-qae",
          "24fcm-3onfs-cykax-al4jb-gvdd3-u76zl-ht6ef-hcsbc-xwf54-xbrym-xae",
          "zpjxp-c6l3m-x54lj-47zz5-dpy6u-lpdkt-hc7pp-gdfuu-i4i7i-jpp4w-lqe",
          "q4ksz-lpvfy-ikkem-wyuaa-abopq-nmu5k-ovh6h-xfoqk-hx3x3-g2bk6-4qe",
          "rcxhc-af5ln-myck4-qrbsj-aelzk-l4hy4-o4fws-7kx57-ajldl-v6pmo-fqe",
          "u4zo2-i6nsc-mowwj-lf6az-s6rdo-caskt-a6yx6-fke5w-qyezs-lyqvn-tqe",
          "x6ufc-46e3d-cvse3-vbjz6-gkrnq-4lpvu-6lloe-l24kd-y75gq-3pmt4-tqe",
          "txh2c-fneot-jj3ys-cx355-22tvp-cw3az-ohxyy-rk7ok-d7ppu-efk4t-iqe",
          "mae7q-ggnbj-xb52f-hvest-dgqoc-whvsq-yui5d-5cys2-zeold-l5ydx-oae",
          "6hvx2-ymemx-tmykh-vxyic-bgfhv-2lcmt-3oy4x-rysuf-rnerz-vqokw-sqe",
          "p3g3j-vvhxl-luedm-woh3j-sllez-jkbzz-274bf-hyuoc-kyo5t-kwziw-eae",
          "anudy-m6vfi-lphxb-sazpy-la4ti-2hriw-c67ny-butfn-axcel-otvuh-oqe",
          "6hkcx-vz4jv-4n33r-ywdvs-sefaa-tb2on-rac6s-4csut-iyahu-zmct2-5qe",
          "tg4ec-b2g4p-h42kd-k7zvb-6rls2-i2q7l-gtr4h-ymr6v-rrez4-w6fao-oqe",
          "gj6gc-mbslq-bt63y-72b7h-xs2xw-6vyuj-frvp3-tx375-dsqx5-wem6o-vqe",
          "geihd-pwhjg-q3tno-beo64-ormih-pkjah-rrdlu-quwdk-nas5k-lmzoo-pae",
          "3rj6n-nnhqn-nad5q-y262v-fuhk4-myqv2-6qzld-ouk7q-fbsuo-l2fi3-6ae",
          "xgysg-f6alc-ft2ai-gseic-u3ohh-cvvkf-5pvjh-spcbk-gvkla-bwswo-jae",
          "5mpdi-v4qj2-64are-tbe6r-6335g-6tksh-c7uzq-w3xyz-o4p5g-rwnll-vqe",
          "gsrhr-kwp6h-y6ibc-yftud-fzi66-vg5df-subl3-wiren-uzza6-rb5fc-dae",
          "y5xp4-nnr33-qeeeg-55unp-xr7f2-mkjfv-7qwe3-zxd7k-lmqd2-mftya-7ae",
          "tm3pc-2bjsx-hhv3v-fsrt7-wotdj-nbu3t-ewloq-uporp-tacou-lupdn-oae",
          "swzzz-nct4o-kgh2s-fezeh-luamk-chexm-jsk4r-ks2qa-au63y-jtc7r-pae",
          "chm6s-bxqgk-jv6em-fbfrr-o54oi-idorx-rdpj7-asc5a-wmujl-awa77-2qe"
        ],
        "nodes": {},
        "max_ingress_bytes_per_message": 3670016,
        "max_ingress_messages_per_block": 400,
        "max_block_payload_size": 4194304,
        "unit_delay_millis": 3000,
        "initial_notary_delay_millis": 1000,
        "replica_version_id": "a3831c87440df4821b435050c8a8fcb3745d86f6",
        "dkg_interval_length": 199,
        "start_as_nns": false,
        "subnet_type": "system",
        "features": {
          "canister_sandboxing": false,
          "http_requests": false,
          "sev_enabled": false
        },
        "max_number_of_canisters": 0,
        "ssh_readonly_access": [],
        "ssh_backup_access": [
          "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIEVcbYyW9CASaIa8wh07Dvm5dCeh0P/YgRP9Kwr38gB5 consensus@10.31.0.141",
          "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAICsO2IEV96tOVfjoOj450TZr4MD8PauHqhcLYvrmRRue pfops@sf1-spm12",
          "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMz75Tyjsl6gxOJz0zHIvcQcMquIm7DHBB62ReJbRkk9 op@pyr07"
        ],
        "ecdsa_config": null,
        "chain_key_config": null
      }
    }
  ]
}

[Lorimer]

There’s an open proposal for changing subnet membership - Proposal: 131401 - ICP Dashboard (internetcomputer.org). This information is presented below:

• red marker represents a removed node
• green marker represents an added node
• highlighted patches represent the country a node sits within

Table

	Country	Data Center	Owner	Node Provider	Node
---	Germany	Munich (mu1)	q.beyond	Staking Facilities	chm6s-bxqgk-jv6em-fbfrr-o54oi-idorx-rdpj7-asc5a-wmujl-awa77-2qe
+++	Poland	Warszawa 3 (wa3)	DataHouse	Vladyslav Popov	ouffe-miylc-6zcwl-afv2d-lai62-qwzns-xtlji-p7pu2-qkx2e-x72y2-sqe
	Argentina	CABA 1 (ar1)	SyT - Servicios y Telecomunicaciones S.A.	Mariano Stoll	yahq2-6rnmm-n7ubm-q76zd-256dl-5f7k6-jxx5l-njyo2-hl7tk-sqcet-6ae
	Australia	Melbourne 2 (mn2)	NEXTDC	Icaria Systems Pty Ltd	onv2n-rm4ad-mgpnn-iiheu-6a76r-crgmo-wxpwt-dqf6y-n7gcf-5po4q-2qe
	Australia	Queensland 1 (sc1)	NEXTDC	Karel Frank	u4zo2-i6nsc-mowwj-lf6az-s6rdo-caskt-a6yx6-fke5w-qyezs-lyqvn-tqe
	Austria	South Moravian Region 1 (bn1)	Master Internet	Lukas Helebrandt	mae7q-ggnbj-xb52f-hvest-dgqoc-whvsq-yui5d-5cys2-zeold-l5ydx-oae
	Belgium	Brussels (br1)	Digital Realty	Allusion	swzzz-nct4o-kgh2s-fezeh-luamk-chexm-jsk4r-ks2qa-au63y-jtc7r-pae
	Canada	Quebec l1 (mtl1)	Leaseweb	Marvelous Web3	anudy-m6vfi-lphxb-sazpy-la4ti-2hriw-c67ny-butfn-axcel-otvuh-oqe
	Switzerland	Geneva 2 (ge2)	SafeHost	Archery Blockchain SCSp	tn2ne-tskw6-dfk3n-urdmd-krtq6-tcebq-dx2xr-kokq7-eood7-fadkg-5qe
	Switzerland	Zurich 2 (zh2)	Everyware	DFINITY Operations SA	6hkcx-vz4jv-4n33r-ywdvs-sefaa-tb2on-rac6s-4csut-iyahu-zmct2-5qe
	Switzerland	Zurich 2 (zh2)	Everyware	DFINITY Operations SA	tg4ec-b2g4p-h42kd-k7zvb-6rls2-i2q7l-gtr4h-ymr6v-rrez4-w6fao-oqe
	China	HongKong 3 (hk3)	hkcolo	Power Meta Corporation	rcxhc-af5ln-myck4-qrbsj-aelzk-l4hy4-o4fws-7kx57-ajldl-v6pmo-fqe
	China	HongKong 4 (hk4)	hkntt	Origin Game	5iihd-fkroy-ow5zp-hlvwz-bsgbl-mecta-kxubm-6adxr-ckcu6-prsus-fqe
	Costa Rica	San José 1 (cr1)	Navegalo	GeoNodes LLC	ltzjy-54bkf-bwynr-rcqst-ncpe6-qlg4x-tvhmp-73bm5-75e7u-t7c7s-eae
	Czechia	Praha 1 (pa1)	MasterDC	Ivanov Oleksandr	mjte3-dopva-7tttu-5hnnu-q572b-p3wwy-b56of-4q6h7-hbtf4-f3m32-tae
	Germany	Frankfurt 2 (fr2)	Equinix	Virtual Hive Ltd	4rpiz-7w7bf-smfm5-u7j3c-we6q7-qehxb-5lqnq-tjqsh-f7xu4-ihpao-zqe
	United Kingdom of Great Britain and Northern Ireland (the)	London 1 (ld1)	Latitude.sh	Conic Ventures	ncr4b-rasb7-tueb3-n4uos-5nxou-3wbxv-xmyt3-wfdsd-vu4b6-5x3cp-aqe
	Georgia	Tbilisi 1 (tb1)	Cloud9	George Bassadone	txh2c-fneot-jj3ys-cx355-22tvp-cw3az-ohxyy-rk7ok-d7ppu-efk4t-iqe
	India	Colombo 1 (cm1)	OrionStellar	Geodd Pvt Ltd	zpjxp-c6l3m-x54lj-47zz5-dpy6u-lpdkt-hc7pp-gdfuu-i4i7i-jpp4w-lqe
	India	Navi Mumbai 1 (nm1)	Rivram	Rivram Inc	6hvx2-ymemx-tmykh-vxyic-bgfhv-2lcmt-3oy4x-rysuf-rnerz-vqokw-sqe
	India	New Delhi 1 (nd1)	Marvelous Web3 DC	Marvelous Web3	x6ufc-46e3d-cvse3-vbjz6-gkrnq-4lpvu-6lloe-l24kd-y75gq-3pmt4-tqe
	India	Panvel 2 (pl2)	Yotta	Krishna Enterprises	w2sev-mtuls-aa7m5-cdjgi-5vipg-2jn7i-4awvf-o6suu-73ebs-sw5db-kqe
	Israel	Tel Aviv 1 (tv1)	Interhost	GeoNodes LLC	gvm7l-ds4n6-vkyjn-gwalp-3vdo6-qfmq7-pxhu4-zvqcu-ozvb7-qz3gr-vqe
	Japan	Tokyo 3 (ty3)	Equinix	Starbase	5mpdi-v4qj2-64are-tbe6r-6335g-6tksh-c7uzq-w3xyz-o4p5g-rwnll-vqe
	Korea (the Republic of)	Seoul 1 (sl1)	Megazone Cloud	Neptune Partners	2ftux-ivgjc-t4i2d-lq5hs-myjdg-3h2pz-l2ddl-nsxfc-wlaq7-fkbc5-6ae
	Lithuania	Vilnius 1 (bt1)	Baltneta	MB Patrankos šūvis	24fcm-3onfs-cykax-al4jb-gvdd3-u76zl-ht6ef-hcsbc-xwf54-xbrym-xae
	Portugal	Barreiro 1 (ba1)	Online	Maksym Ishchenko	74qsa-j6jno-nmxmb-7jpf5-u6nig-g7hgo-thvjm-6f6zu-c2ugp-krple-qae
	Singapore	Singapore (sg1)	Telin	OneSixtyTwo Digital Capital	gsrhr-kwp6h-y6ibc-yftud-fzi66-vg5df-subl3-wiren-uzza6-rb5fc-dae
	Slovenia	Ljubljana 2 (lj2)	Anonstake	Anonstake	gj6gc-mbslq-bt63y-72b7h-xs2xw-6vyuj-frvp3-tx375-dsqx5-wem6o-vqe
	Slovenia	Maribor (mb1)	Posita.si	Fractal Labs AG	tm3pc-2bjsx-hhv3v-fsrt7-wotdj-nbu3t-ewloq-uporp-tacou-lupdn-oae
	United States of America (the)	Allentown (aw1)	Tierpoint	Bigger Capital	geihd-pwhjg-q3tno-beo64-ormih-pkjah-rrdlu-quwdk-nas5k-lmzoo-pae
	United States of America (the)	Atlanta (at1)	Flexential	Goat, LLC	p3g3j-vvhxl-luedm-woh3j-sllez-jkbzz-274bf-hyuoc-kyo5t-kwziw-eae
	United States of America (the)	Boston (bo1)	INAP	DFINITY USA Research LLC	fd5e4-a2xzl-lxu7m-kjvn6-2arnt-jghro-rdrgx-zvvkd-j2hza-pbwl4-5qe
	United States of America (the)	Chicago 3 (ch3)	CyrusOne	MI Servers	2tk2h-7snvn-clgy3-g33vp-fc57w-ptljs-xujfq-fu47q-ludhi-g7zzf-xqe
	United States of America (the)	Portland (pl1)	Flexential	87m Neuron, LLC	xgysg-f6alc-ft2ai-gseic-u3ohh-cvvkf-5pvjh-spcbk-gvkla-bwswo-jae
	United States of America (the)	San Jose (sj1)	INAP	Shelburne Ventures, LLC	y5xp4-nnr33-qeeeg-55unp-xr7f2-mkjfv-7qwe3-zxd7k-lmqd2-mftya-7ae
	United States of America (the)	Tampa (tp1)	Flexential	Richard Ma	3rj6n-nnhqn-nad5q-y262v-fuhk4-myqv2-6qzld-ouk7q-fbsuo-l2fi3-6ae
	United States of America (the)	Vancouver (bc1)	Cyxtera	Blockchain Development Labs	jmuoq-7kbey-cbtmm-zlz6t-chwt6-dk7ly-d3jim-5nuu4-y5tou-l5egg-7qe
	South Africa	Cape Town 2 (ct2)	Teraco	Kontrapunt (Pty) Ltd	noos2-mfe4u-r4gp3-jrjow-ancs2-ncakm-zi72z-zzcbg-uam7p-d4s6s-6qe
	South Africa	Gauteng 2 (jb2)	Africa Data Centres	Honeycomb Capital (Pty) Ltd	wazkf-2xehg-y26ek-2uq64-pkrbh-6frmq-4q7lf-5gaya-44q4p-v5r5z-cqe
	South Africa	Gauteng 3 (jb3)	Xneelo	Wolkboer (Pty) Ltd	q4ksz-lpvfy-ikkem-wyuaa-abopq-nmu5k-ovh6h-xfoqk-hx3x3-g2bk6-4qe

The removed node is replaced with a node based in Poland. I’ve verified that this node is currently unassigned.

The proposal mentions that his change is needed due to the Munich (mu1) data centre being due for decommissioning. I have some questions about this which I’ve asked on another topic.

[Lorimer]

Hi @andrea and @bitdivine, I had some spare time this evening so I was glancing through older proposals and I noticed Proposal: 131380 - ICP Dashboard (internetcomputer.org)

This proposal updates the configuration of the NNS subnet to increase the maximum amount of ingress messages allowed in a block to 1000, and increases the DKG interval length to 499 (meaning a DKG interval and state checkpoint takes place every 500 rounds). This main goal of this proposal is to minimize configuration differences between subnets.

This proposal was rejected. Are you able to provide some context as to why? I gather that this proposal is related to lessons learned recently regarding subnet downtime.

@Manu

minimize configuration differences between the NNS subnet and other subnets

tdb26 now appears to be the only subnet with max_ingress_messages_per_block: 400 and dkg_interval_length: 199 (unless I’m mistaken).

There’s also some other config that tdb26 has which is shared with only a small number of other subnets, such as initial_notary_delay_millis: 1000 and max_ingress_bytes_per_message: 3670016. Are there plans to make these consistent across subnets too?

Thanks

[Manu]

@Lorimer

This proposal was rejected. Are you able to provide some context as to why? I gather that this proposal is related to lessons learned recently regarding subnet downtime.

Correct, this proposal was triggered by the lessons learned from the slow NNS subnet incident. It was rejected because it was submitted at a bit of an unfortunate moment, right before the Schnorr key resharing, and the longer DKG interval length would’ve had a slight negative effect on that operation. We plan to resubmit the proposal tomorrow.

@Lorimer

There’s also some other config that tdb26 has which is shared with only a small number of other subnets, such as initial_notary_delay_millis: 1000 and max_ingress_bytes_per_message: 3670016. Are there plans to make these consistent across subnets too?

We’re basically trying to unify as much as we can, but some things are challenging. Currently some NNS canisters rely on this larger max_ingress_bytes_per_message, so work is needed on that side before we can change it.

Wrt notary delays: note that this is not unique to the NNS subnet, but we have higher values for all large subnets. This value should be aligned with the amount of time it actually takes to disseminate artifacts, which in turn is dependent on the subnet size. So we’ll probably look into it more, but I expect that we may want to keep some differences there.

[stefan.schneider]

The new proposal to adjust the dkg_interval to 499 and the max_ingress_messages_per_block to 1000 is here.

[Lorimer]

Thanks for announcing this proposal @stefan.schneider.

The main goal of this proposal is to minimize configuration differences between subnets

From what I can see, once this executes all subnets will have a dkg_interval of 499 and max_ingress_messages_per_block of 1000, consistent with the objective stated in the proposal summary

[Lorimer]

@Manu

Schnorr key resharing , and the longer DKG interval length would’ve had a slight negative effect on that operation

Thanks @Manu, I take it it’s the role that the registry canister plays during key resharing that makes the tdb26 subnet particularly important during that operation. What will the plan be in the future when other keys need resharing (presumably the slight negative impact will just be accepted)?

[Lorimer]

There’s an open proposal for removing a node from this subnet (along with 2 other subnets - 5kdm2 (Application) and uzr34 (II))

• Proposal 132102

I intend to take a closer look later today after work. But for now here’s some contextual info for interested voters.

Map Description

• Red marker represents a removed node (transparent center for overlap visibility)
• Blue marker represents an unchanged node
• Highlighted patches represent the country the above nodes sit within
• Light grey markers with yellow borders are examples of unassigned nodes that would be viable candidates for joining the subnet according to formal decentralisation coefficients (so this proposal can be viewed in the context of alternative solutions that are not being used - plenty of nodes that the removed node could have been swapped with if this were a ‘Change Subnet Membership’ proposal)

Table

	Continent	Country	Data Center	Owner	Node Provider	Node	Status
---	Asia	India	Colombo 1 (cm1)	OrionStellar	Geodd Pvt Ltd	zpjxp-c6l3m-x54lj-47zz5-dpy6u-lpdkt-hc7pp-gdfuu-i4i7i-jpp4w-lqe	DOWN
	Americas	Argentina	CABA 1 (ar1)	SyT - Servicios y Telecomunicaciones S.A.	Mariano Stoll	yahq2-6rnmm-n7ubm-q76zd-256dl-5f7k6-jxx5l-njyo2-hl7tk-sqcet-6ae	UP
	Oceania	Australia	Melbourne 2 (mn2)	NEXTDC	Icaria Systems Pty Ltd	onv2n-rm4ad-mgpnn-iiheu-6a76r-crgmo-wxpwt-dqf6y-n7gcf-5po4q-2qe	UP
	Oceania	Australia	Queensland 1 (sc1)	NEXTDC	Karel Frank	u4zo2-i6nsc-mowwj-lf6az-s6rdo-caskt-a6yx6-fke5w-qyezs-lyqvn-tqe	UP
	Europe	Belgium	Brussels (br1)	Digital Realty	Allusion	swzzz-nct4o-kgh2s-fezeh-luamk-chexm-jsk4r-ks2qa-au63y-jtc7r-pae	UP
	Americas	Canada	Quebec l1 (mtl1)	Leaseweb	Marvelous Web3	anudy-m6vfi-lphxb-sazpy-la4ti-2hriw-c67ny-butfn-axcel-otvuh-oqe	UP
	Europe	Switzerland	Geneva 2 (ge2)	SafeHost	Archery Blockchain SCSp	tn2ne-tskw6-dfk3n-urdmd-krtq6-tcebq-dx2xr-kokq7-eood7-fadkg-5qe	UP
	Europe	Switzerland	Zurich 2 (zh2)	Everyware	DFINITY Operations SA	6hkcx-vz4jv-4n33r-ywdvs-sefaa-tb2on-rac6s-4csut-iyahu-zmct2-5qe	UP
	Europe	Switzerland	Zurich 2 (zh2)	Everyware	DFINITY Operations SA	tg4ec-b2g4p-h42kd-k7zvb-6rls2-i2q7l-gtr4h-ymr6v-rrez4-w6fao-oqe	UP
	Asia	China	HongKong 3 (hk3)	hkcolo	Power Meta Corporation	rcxhc-af5ln-myck4-qrbsj-aelzk-l4hy4-o4fws-7kx57-ajldl-v6pmo-fqe	UP
	Asia	China	HongKong 4 (hk4)	hkntt	Origin Game	5iihd-fkroy-ow5zp-hlvwz-bsgbl-mecta-kxubm-6adxr-ckcu6-prsus-fqe	UP
	Americas	Costa Rica	San José 1 (cr1)	Navegalo	GeoNodes LLC	ltzjy-54bkf-bwynr-rcqst-ncpe6-qlg4x-tvhmp-73bm5-75e7u-t7c7s-eae	UP
	Europe	Czechia	Praha 1 (pa1)	MasterDC	Ivanov Oleksandr	mjte3-dopva-7tttu-5hnnu-q572b-p3wwy-b56of-4q6h7-hbtf4-f3m32-tae	UP
	Europe	Czechia	South Moravian Region 1 (bn1)	Master Internet	Lukas Helebrandt	mae7q-ggnbj-xb52f-hvest-dgqoc-whvsq-yui5d-5cys2-zeold-l5ydx-oae	UP
	Europe	Germany	Frankfurt 2 (fr2)	Equinix	Virtual Hive Ltd	4rpiz-7w7bf-smfm5-u7j3c-we6q7-qehxb-5lqnq-tjqsh-f7xu4-ihpao-zqe	UP
	Europe	United Kingdom of Great Britain and Northern Ireland (the)	London 1 (ld1)	Latitude.sh	Conic Ventures	ncr4b-rasb7-tueb3-n4uos-5nxou-3wbxv-xmyt3-wfdsd-vu4b6-5x3cp-aqe	UP
	Asia	Georgia	Tbilisi 1 (tb1)	Cloud9	George Bassadone	txh2c-fneot-jj3ys-cx355-22tvp-cw3az-ohxyy-rk7ok-d7ppu-efk4t-iqe	UP
	Asia	India	Navi Mumbai 1 (nm1)	Rivram	Rivram Inc	6hvx2-ymemx-tmykh-vxyic-bgfhv-2lcmt-3oy4x-rysuf-rnerz-vqokw-sqe	UP
	Asia	India	New Delhi 1 (nd1)	Marvelous Web3 DC	Marvelous Web3	x6ufc-46e3d-cvse3-vbjz6-gkrnq-4lpvu-6lloe-l24kd-y75gq-3pmt4-tqe	UP
	Asia	India	Panvel 2 (pl2)	Yotta	Krishna Enterprises	w2sev-mtuls-aa7m5-cdjgi-5vipg-2jn7i-4awvf-o6suu-73ebs-sw5db-kqe	UP
	Asia	Israel	Tel Aviv 1 (tv1)	Interhost	GeoNodes LLC	gvm7l-ds4n6-vkyjn-gwalp-3vdo6-qfmq7-pxhu4-zvqcu-ozvb7-qz3gr-vqe	UP
	Asia	Japan	Tokyo 3 (ty3)	Equinix	Starbase	5mpdi-v4qj2-64are-tbe6r-6335g-6tksh-c7uzq-w3xyz-o4p5g-rwnll-vqe	UP
	Asia	Korea (the Republic of)	Seoul 1 (sl1)	Megazone Cloud	Neptune Partners	2ftux-ivgjc-t4i2d-lq5hs-myjdg-3h2pz-l2ddl-nsxfc-wlaq7-fkbc5-6ae	UP
	Europe	Lithuania	Vilnius 1 (bt1)	Baltneta	MB Patrankos šūvis	24fcm-3onfs-cykax-al4jb-gvdd3-u76zl-ht6ef-hcsbc-xwf54-xbrym-xae	UP
	Europe	Poland	Warszawa 3 (wa3)	DataHouse	Vladyslav Popov	ouffe-miylc-6zcwl-afv2d-lai62-qwzns-xtlji-p7pu2-qkx2e-x72y2-sqe	UP
	Europe	Portugal	Barreiro 1 (ba1)	Online	Maksym Ishchenko	74qsa-j6jno-nmxmb-7jpf5-u6nig-g7hgo-thvjm-6f6zu-c2ugp-krple-qae	UP
	Asia	Singapore	Singapore (sg1)	Telin	OneSixtyTwo Digital Capital	gsrhr-kwp6h-y6ibc-yftud-fzi66-vg5df-subl3-wiren-uzza6-rb5fc-dae	UP
	Europe	Slovenia	Ljubljana 2 (lj2)	Anonstake	Anonstake	gj6gc-mbslq-bt63y-72b7h-xs2xw-6vyuj-frvp3-tx375-dsqx5-wem6o-vqe	UP
	Europe	Slovenia	Maribor (mb1)	Posita.si	Fractal Labs AG	tm3pc-2bjsx-hhv3v-fsrt7-wotdj-nbu3t-ewloq-uporp-tacou-lupdn-oae	UP
	Americas	United States of America (the)	Allentown (aw1)	Tierpoint	Bigger Capital	geihd-pwhjg-q3tno-beo64-ormih-pkjah-rrdlu-quwdk-nas5k-lmzoo-pae	UP
	Americas	United States of America (the)	Atlanta (at1)	Flexential	Goat, LLC	p3g3j-vvhxl-luedm-woh3j-sllez-jkbzz-274bf-hyuoc-kyo5t-kwziw-eae	UP
	Americas	United States of America (the)	Boston (bo1)	INAP	DFINITY USA Research LLC	fd5e4-a2xzl-lxu7m-kjvn6-2arnt-jghro-rdrgx-zvvkd-j2hza-pbwl4-5qe	UP
	Americas	United States of America (the)	Chicago 3 (ch3)	CyrusOne	MI Servers	2tk2h-7snvn-clgy3-g33vp-fc57w-ptljs-xujfq-fu47q-ludhi-g7zzf-xqe	UP
	Americas	United States of America (the)	Portland (pl1)	Flexential	87m Neuron, LLC	xgysg-f6alc-ft2ai-gseic-u3ohh-cvvkf-5pvjh-spcbk-gvkla-bwswo-jae	UP
	Americas	United States of America (the)	San Jose (sj1)	INAP	Shelburne Ventures, LLC	y5xp4-nnr33-qeeeg-55unp-xr7f2-mkjfv-7qwe3-zxd7k-lmqd2-mftya-7ae	UP
	Americas	United States of America (the)	Tampa (tp1)	Flexential	Richard Ma	3rj6n-nnhqn-nad5q-y262v-fuhk4-myqv2-6qzld-ouk7q-fbsuo-l2fi3-6ae	UP
	Americas	United States of America (the)	Vancouver (bc1)	Cyxtera	Blockchain Development Labs	jmuoq-7kbey-cbtmm-zlz6t-chwt6-dk7ly-d3jim-5nuu4-y5tou-l5egg-7qe	UP
	Africa	South Africa	Cape Town 2 (ct2)	Teraco	Kontrapunt (Pty) Ltd	noos2-mfe4u-r4gp3-jrjow-ancs2-ncakm-zi72z-zzcbg-uam7p-d4s6s-6qe	UP
	Africa	South Africa	Gauteng 2 (jb2)	Africa Data Centres	Honeycomb Capital (Pty) Ltd	wazkf-2xehg-y26ek-2uq64-pkrbh-6frmq-4q7lf-5gaya-44q4p-v5r5z-cqe	UP
	Africa	South Africa	Gauteng 3 (jb3)	Xneelo	Wolkboer (Pty) Ltd	q4ksz-lpvfy-ikkem-wyuaa-abopq-nmu5k-ovh6h-xfoqk-hx3x3-g2bk6-4qe	UP

[Lorimer]

@Lorimer

I intend to take a closer look later today after work

I’ve rejected this proposal for numerous reasons. TLDR: It doesn’t actually fix anything, and is unjustified in violating the target IC topology, even if it’s temporary (there’s insufficient information provided in the summary to explain why they’ve proposed this removal in this way):

Expand for more details

• This proposal doesn’t fix the problem of an offline node. Instead it’s removing it from the subnet for some unexplained / unjustified reason (unjustified because it’s not transactionally replacing the node with a good one)
• ‘Remove node from subnet’ proposals are for shrinking subnets (this isn’t and shouldn’t be the intention here). ‘Change Subnet Membership’ proposals are for fixing bad nodes in a subnet (by transactionally swapping them out for good nodes) - which is the proposal type that should have been proposed, and that this proposal should (in my opinion) be superseded by (after rejecting).
• This proposal has a very poor summary (historically these types of proposals have provided much more information in the summary, such as the affected subnets, and the precise set of steps are are planned to follow the proposal). Ever since the ‘Change Subnet Membership’ proposal type was implemented, ‘Remove node from subnet’ proposals have become more or less a thing of the past (at least in this sort of scenario).
  • The proposal does not clearly state what the next steps would be (which IPv6 and IPv4 enabled nodes would be deployed as a next step?)
  • Why isn’t this being done transactionally under one proposal per subnet (why is it justifiable to ask the community to vote the subnet into a state that violates the formal target topology?)
• Accepting this proposal would leave the 3 affected subnets in a state that is in violation of the formally voted in target IC topology (and in even further violation of the topology that is likely to soon be proposed - 34 nodes instead of 28 on the II subnet)

@SvenF

• There’s only one other Subnet Management proposal proposed by this neuron historically, and it was also worthy of rejection in my opinion (currently that proposal is still open).

---

Known Neurons to follow if you're too busy to keep on top of things like this

If you found this analysis helpful and would like to follow the vote of the LORIMER known neuron in the future, consider configuring LORIMER as a followee for the Subnet Management topic.

Other good neurons to follow:

• CodeGov (will soon be committed to actively reviewing and voting on Subnet Management proposals based on those reviews)
• WaterNeuron (the WaterNeuron DAO frequently discuss proposals like this in order to vote responsibly based on DAO consensus)

[MalithHatananchchige]

Hi @Lorimer
My apologies for the very bad miscommunication and bad summary of the reason why these nodes were taken offline for IPv6 Migration. I was not aware of the independent review and will fix our communication on the forum better.

I only have communicated my intent on Element Matrix Channel

A few weeks back.

Reason for removing from subnet :
The ISP has assigned us IP addresses that are not recognized as local, even though the latency remains the same. For future proofing IC nodes we thought of going to a local IP space which would help better geolocation accuracy and abundance through local ISP providers. To address this, we’ve taken steps to acquire our own local IPv4 and IPv6 subnets. As part of this effort, we are redeploying all CM1 DC nodes from scratch. We’ve successfully migrated two nodes that were not previously in the subnet to our new IP space. Unfortunately, the nodes have to be offline as the old IP space was decommissioned.

Hope this make it clear

[Lorimer]

Thanks very much for getting in touch @MalithHatananchchige, I’ve responded below.

@Lorimer

Thanks @MalithHatananchchige, I really appreciate your reaching out and providing some clarity. This really helps, and I’m glad to see that you’re open to improving processes in the future .

Regarding the removal of the nodes from the subnet, can I ask why this was not a proposal to swap in a good node (so that the subnet topology, in terms of cardinality, is not formally modified)? I’m still of the impression that this proposal should be rejected, and replaced with a ‘Change Subnet Membership’ proposal (as highlighted there are plenty of spare nodes to swap into the network). This would then free up your CM1 nodes so that they can be removed from the wider network and redeployed with IPv4 and IPv6 addresses.

[Lorimer]

@SvenF

@MalithHatananchchige for the above reason the Foundation will reject proposal 131977 and proposal 132102 . Can I suggest you to align with me and @sat on the Element channel so we can help with submitting the node swap proposals first? After these proposals are adopted, you can then proceed with remove the nodes from the IC to upgrade the network config.

There’s now a replacement proposal for the above, currently open for voting (see below).

---

Proposal 132141

TLDR: I’ve rejected this proposal as it does not solve the offline node issue, and the payload parameters appear to contains errors.

Note that node zpjxp is included in both the nodes removed and nodes added parameters of the payload. Swapping nodes is supposed to be a transactional operation (I wouldn’t be surprised if this would fail to execute).

• My understanding is that the purpose of this proposal was supposed to be to remove the offline CM1 node so that @MalithHatananchchige and his team can remove the node from the wider IC network before redeploying with updated config. This proposal does not allow for the necessary set of steps to achieve this.

@SvenF

• swap the node that needs to be upgraded (or nodes that are unhealthy or dead and require and upgrade) for another node that is healthy.
• now that the node to be upgraded is “not active in a subnet”, to remove that node from the IC so it can be upgraded.

• The other 5 node swaps in this proposal are taking the opportunity to improve subnet decentralisation (given there’s already a need for a proposal). 5 nodes are proposed to be replaced with nodes in Romania, China, Singapore, Estonia, and the USA. However, this proposal leaves the subnet in a state that is still heavily in violation of the formally voted in IC Target Topology. There is supposed to be no more than 3 nodes in the same country, and no nodes sharing the same data center, owner, and/or node provider (not 7 nodes in one country, and 2 with the same data center, owner, and/or node provider).

• My suggestion would be to reject this proposal and resubmit one that solves the offline node problem, and gets this critical subnet back into a state that conforms to the IC target topology (else clearly explain in the proposal summary why this latter point is not feasible).

Decentralisation Stats

Subnet node distance stats (distance between any 2 nodes in the subnet) →

	Smallest Distance	Average Distance	Largest Distance
EXISTING	0 km	8030.675 km	19445.845 km
PROPOSED	0 km (NaN%)	8184.229 km (+1.9%)	19445.845 km

This proposal increases decentralisation, considered purely in terms of geographic distance (and therefore there’s a slight theoretical increase in localised disaster resilience).

Subnet characteristic counts →

	Continents	Countries	Data Centers	Owners	Node Providers
EXISTING	5	22	39	34	37
PROPOSED	5	23 (+4.3%)	38 (-2.6%)	36 (+5.6%)	36 (-2.8%)

This proposal improves decentralisation in terms of jurisdiction diversity, and data center ownership.

However, it reduces decentralisation in terms of data center and node provider diversity

Largest number of nodes with the same characteristic (e.g. continent, country, data center, etc.) →

	Continent	Country	Data Center	Owner	Node Provider
EXISTING	13	8	2	3	2
PROPOSED	13	7 (-12.5%)	2	2 (-33.33%)	2

See here for acceptable limits → Motion 125549 (note that these are due for a slight revision)

The above subnet information is illustrated below, followed by a node reference table:

Map Description

• Red marker represents a removed node (transparent center for overlap visibility)
• Green marker represents an added node
• Blue marker represents an unchanged node
• Highlighted patches represent the country the above nodes sit within (red if the country is removed, green if added, otherwise grey)

Table

	Continent	Country	Data Center	Owner	Node Provider	Node	Status
---	Europe	Switzerland	Geneva 2 (ge2)	SafeHost	Archery Blockchain SCSp	tn2ne-tskw6-dfk3n-urdmd-krtq6-tcebq-dx2xr-kokq7-eood7-fadkg-5qe	UP
---	Europe	Germany	Frankfurt 2 (fr2)	Equinix	Virtual Hive Ltd	4rpiz-7w7bf-smfm5-u7j3c-we6q7-qehxb-5lqnq-tjqsh-f7xu4-ihpao-zqe	UP
---	Asia	India	Colombo 1 (cm1)	OrionStellar	Geodd Pvt Ltd	zpjxp-c6l3m-x54lj-47zz5-dpy6u-lpdkt-hc7pp-gdfuu-i4i7i-jpp4w-lqe	DOWN
---	Asia	India	New Delhi 1 (nd1)	Marvelous Web3 DC	Marvelous Web3	x6ufc-46e3d-cvse3-vbjz6-gkrnq-4lpvu-6lloe-l24kd-y75gq-3pmt4-tqe	UP
---	Americas	United States of America (the)	Portland (pl1)	Flexential	87m Neuron, LLC	xgysg-f6alc-ft2ai-gseic-u3ohh-cvvkf-5pvjh-spcbk-gvkla-bwswo-jae	UP
---	Americas	United States of America (the)	San Jose (sj1)	INAP	Shelburne Ventures, LLC	y5xp4-nnr33-qeeeg-55unp-xr7f2-mkjfv-7qwe3-zxd7k-lmqd2-mftya-7ae	UP
+++	Asia	China	Seoul 3 (kr1)	KT	Pindar Technology Limited	5alj6-ij6fd-4efxw-chag5-7a327-7uvyj-lhait-ojze2-gxxtr-mgfkf-rae	UNASSIGNED
+++	Europe	Estonia	Tallinn 1 (ta1)	InfonetDC	Bohatyrov Volodymyr	67m4d-5jvep-mnm7z-fjsm7-7aec4-bycrw-dntq6-v4ahv-4mele-yljgc-tae	UNASSIGNED
+++	Asia	India	Colombo 1 (cm1)	OrionStellar	Geodd Pvt Ltd	zpjxp-c6l3m-x54lj-47zz5-dpy6u-lpdkt-hc7pp-gdfuu-i4i7i-jpp4w-lqe	DOWN
+++	Europe	Romania	Bucharest (bu1)	M247	Iancu Aurel	jyh32-azcnn-mwosu-urewl-m3pyx-6pmlq-lu5fu-vqjyl-gwx3j-zqrjr-gae	UNASSIGNED
+++	Asia	Singapore	Singapore 3 (sg3)	Racks Central	OneSixtyTwo Digital Capital	mf3d3-z5tww-ii4jn-zhy4f-ah3un-wpre7-edsb4-ktrb5-h7f3f-uz7rv-bqe	UNASSIGNED
+++	Americas	United States of America (the)	Houston (hu1)	TRG	43rd Big Idea Films	m2g5i-bmomq-dyjao-k642i-fsfxg-trxki-6i42q-hm6ec-xu5cd-n5jhq-sqe	UNASSIGNED
	Americas	Argentina	CABA 1 (ar1)	SyT - Servicios y Telecomunicaciones S.A.	Mariano Stoll	yahq2-6rnmm-n7ubm-q76zd-256dl-5f7k6-jxx5l-njyo2-hl7tk-sqcet-6ae	UP
	Oceania	Australia	Melbourne 2 (mn2)	NEXTDC	Icaria Systems Pty Ltd	onv2n-rm4ad-mgpnn-iiheu-6a76r-crgmo-wxpwt-dqf6y-n7gcf-5po4q-2qe	UP
	Oceania	Australia	Queensland 1 (sc1)	NEXTDC	Karel Frank	u4zo2-i6nsc-mowwj-lf6az-s6rdo-caskt-a6yx6-fke5w-qyezs-lyqvn-tqe	UP
	Europe	Belgium	Brussels (br1)	Digital Realty	Allusion	swzzz-nct4o-kgh2s-fezeh-luamk-chexm-jsk4r-ks2qa-au63y-jtc7r-pae	UP
	Americas	Canada	Quebec l1 (mtl1)	Leaseweb	Marvelous Web3	anudy-m6vfi-lphxb-sazpy-la4ti-2hriw-c67ny-butfn-axcel-otvuh-oqe	UP
	Europe	Switzerland	Zurich 2 (zh2)	Everyware	DFINITY Operations SA	6hkcx-vz4jv-4n33r-ywdvs-sefaa-tb2on-rac6s-4csut-iyahu-zmct2-5qe	UP
	Europe	Switzerland	Zurich 2 (zh2)	Everyware	DFINITY Operations SA	tg4ec-b2g4p-h42kd-k7zvb-6rls2-i2q7l-gtr4h-ymr6v-rrez4-w6fao-oqe	UP
	Asia	China	HongKong 3 (hk3)	hkcolo	Power Meta Corporation	rcxhc-af5ln-myck4-qrbsj-aelzk-l4hy4-o4fws-7kx57-ajldl-v6pmo-fqe	UP
	Asia	China	HongKong 4 (hk4)	hkntt	Origin Game	5iihd-fkroy-ow5zp-hlvwz-bsgbl-mecta-kxubm-6adxr-ckcu6-prsus-fqe	UP
	Americas	Costa Rica	San José 1 (cr1)	Navegalo	GeoNodes LLC	ltzjy-54bkf-bwynr-rcqst-ncpe6-qlg4x-tvhmp-73bm5-75e7u-t7c7s-eae	UP
	Europe	Czechia	Praha 1 (pa1)	MasterDC	Ivanov Oleksandr	mjte3-dopva-7tttu-5hnnu-q572b-p3wwy-b56of-4q6h7-hbtf4-f3m32-tae	UP
	Europe	Czechia	South Moravian Region 1 (bn1)	Master Internet	Lukas Helebrandt	mae7q-ggnbj-xb52f-hvest-dgqoc-whvsq-yui5d-5cys2-zeold-l5ydx-oae	UP
	Europe	United Kingdom of Great Britain and Northern Ireland (the)	London 1 (ld1)	Latitude.sh	Conic Ventures	ncr4b-rasb7-tueb3-n4uos-5nxou-3wbxv-xmyt3-wfdsd-vu4b6-5x3cp-aqe	UP
	Asia	Georgia	Tbilisi 1 (tb1)	Cloud9	George Bassadone	txh2c-fneot-jj3ys-cx355-22tvp-cw3az-ohxyy-rk7ok-d7ppu-efk4t-iqe	UP
	Asia	India	Navi Mumbai 1 (nm1)	Rivram	Rivram Inc	6hvx2-ymemx-tmykh-vxyic-bgfhv-2lcmt-3oy4x-rysuf-rnerz-vqokw-sqe	UP
	Asia	India	Panvel 2 (pl2)	Yotta	Krishna Enterprises	w2sev-mtuls-aa7m5-cdjgi-5vipg-2jn7i-4awvf-o6suu-73ebs-sw5db-kqe	UP
	Asia	Israel	Tel Aviv 1 (tv1)	Interhost	GeoNodes LLC	gvm7l-ds4n6-vkyjn-gwalp-3vdo6-qfmq7-pxhu4-zvqcu-ozvb7-qz3gr-vqe	UP
	Asia	Japan	Tokyo 3 (ty3)	Equinix	Starbase	5mpdi-v4qj2-64are-tbe6r-6335g-6tksh-c7uzq-w3xyz-o4p5g-rwnll-vqe	UP
	Asia	Korea (the Republic of)	Seoul 1 (sl1)	Megazone Cloud	Neptune Partners	2ftux-ivgjc-t4i2d-lq5hs-myjdg-3h2pz-l2ddl-nsxfc-wlaq7-fkbc5-6ae	UP
	Europe	Lithuania	Vilnius 1 (bt1)	Baltneta	MB Patrankos šūvis	24fcm-3onfs-cykax-al4jb-gvdd3-u76zl-ht6ef-hcsbc-xwf54-xbrym-xae	UP
	Europe	Poland	Warszawa 3 (wa3)	DataHouse	Vladyslav Popov	ouffe-miylc-6zcwl-afv2d-lai62-qwzns-xtlji-p7pu2-qkx2e-x72y2-sqe	UP
	Europe	Portugal	Barreiro 1 (ba1)	Online	Maksym Ishchenko	74qsa-j6jno-nmxmb-7jpf5-u6nig-g7hgo-thvjm-6f6zu-c2ugp-krple-qae	UP
	Asia	Singapore	Singapore (sg1)	Telin	OneSixtyTwo Digital Capital	gsrhr-kwp6h-y6ibc-yftud-fzi66-vg5df-subl3-wiren-uzza6-rb5fc-dae	UP
	Europe	Slovenia	Ljubljana 2 (lj2)	Anonstake	Anonstake	gj6gc-mbslq-bt63y-72b7h-xs2xw-6vyuj-frvp3-tx375-dsqx5-wem6o-vqe	UP
	Europe	Slovenia	Maribor (mb1)	Posita.si	Fractal Labs AG	tm3pc-2bjsx-hhv3v-fsrt7-wotdj-nbu3t-ewloq-uporp-tacou-lupdn-oae	UP
	Americas	United States of America (the)	Allentown (aw1)	Tierpoint	Bigger Capital	geihd-pwhjg-q3tno-beo64-ormih-pkjah-rrdlu-quwdk-nas5k-lmzoo-pae	UP
	Americas	United States of America (the)	Atlanta (at1)	Flexential	Goat, LLC	p3g3j-vvhxl-luedm-woh3j-sllez-jkbzz-274bf-hyuoc-kyo5t-kwziw-eae	UP
	Americas	United States of America (the)	Boston (bo1)	INAP	DFINITY USA Research LLC	fd5e4-a2xzl-lxu7m-kjvn6-2arnt-jghro-rdrgx-zvvkd-j2hza-pbwl4-5qe	UP
	Americas	United States of America (the)	Chicago 3 (ch3)	CyrusOne	MI Servers	2tk2h-7snvn-clgy3-g33vp-fc57w-ptljs-xujfq-fu47q-ludhi-g7zzf-xqe	UP
	Americas	United States of America (the)	Tampa (tp1)	Flexential	Richard Ma	3rj6n-nnhqn-nad5q-y262v-fuhk4-myqv2-6qzld-ouk7q-fbsuo-l2fi3-6ae	UP
	Americas	United States of America (the)	Vancouver (bc1)	Cyxtera	Blockchain Development Labs	jmuoq-7kbey-cbtmm-zlz6t-chwt6-dk7ly-d3jim-5nuu4-y5tou-l5egg-7qe	UP
	Africa	South Africa	Cape Town 2 (ct2)	Teraco	Kontrapunt (Pty) Ltd	noos2-mfe4u-r4gp3-jrjow-ancs2-ncakm-zi72z-zzcbg-uam7p-d4s6s-6qe	UP
	Africa	South Africa	Gauteng 2 (jb2)	Africa Data Centres	Honeycomb Capital (Pty) Ltd	wazkf-2xehg-y26ek-2uq64-pkrbh-6frmq-4q7lf-5gaya-44q4p-v5r5z-cqe	UP
	Africa	South Africa	Gauteng 3 (jb3)	Xneelo	Wolkboer (Pty) Ltd	q4ksz-lpvfy-ikkem-wyuaa-abopq-nmu5k-ovh6h-xfoqk-hx3x3-g2bk6-4qe	UP

---

Known Neurons to follow if you're too busy to keep on top of things like this

If you found this analysis helpful and would like to follow the vote of the LORIMER known neuron in the future, consider configuring LORIMER as a followee for the Subnet Management topic.

Other good neurons to follow:

• CodeGov (will soon be committed to actively reviewing and voting on Subnet Management proposals based on those reviews)
• WaterNeuron (the WaterNeuron DAO frequently discuss proposals like this in order to vote responsibly based on DAO consensus)

[Lorimer]

Proposal 132179

TLDR: I’ve adopted this proposal.

• Replaces one offline node with an up node
• Performs 5 other node swaps in order to improve decentralisation coefficients

Note that this security-critical subnet will still be in violation of the IC target topology even after this proposal passes, both in terms of the country limit and data center limit. More info here → Adjustment of IC Target Topology to Increase Subnet Size of Fiduciary and II subnets - Governance - Internet Computer Developer Forum (dfinity.org))

Decentralisation Stats

Subnet node distance stats (distance between any 2 nodes in the subnet) →

	Smallest Distance	Average Distance	Largest Distance
EXISTING	0 km	8030.675 km	19445.845 km
PROPOSED	0 km (NaN%)	8201.969 km (+2.1%)	19445.845 km

This proposal slightly increases decentralisation, considered purely in terms of geographic distance (and therefore there’s a slight theoretical increase in localised disaster resilience).

Subnet characteristic counts →

	Continents	Countries	Data Centers	Owners	Node Providers
EXISTING	5	22	39	34	37
PROPOSED	5	24 (+8.3%)	39	37 (+8.1%)	37

This proposal improves decentralisation in terms of jurisdiction and data center ownership diversity.

Largest number of nodes with the same characteristic (e.g. continent, country, data center, etc.) →

	Continent	Country	Data Center	Owner	Node Provider
EXISTING	13	8	2	3	2
PROPOSED	13	7 (-12.5%)	2	2 (-33.33333333333333%)	2

See here for acceptable limits → Motion 132136

The above subnet information is illustrated below, followed by a node reference table:

Map Description

• Red marker represents a removed node (transparent center for overlap visibility)
• Green marker represents an added node
• Blue marker represents an unchanged node
• Highlighted patches represent the country the above nodes sit within (red if the country is removed, green if added, otherwise grey)
• Light grey markers with yellow borders are examples of unassigned nodes that would be viable candidates for joining the subnet according to formal decentralisation coefficients (so this proposal can be viewed in the context of alternative solutions that are not being used)

UPDATE Having switched to a more up-to-date IP address location provider (https://www.ip2location.io/ instead of https://ip-api.com/), the mapping results are somewhat different. Interesting that there can be such significant differences. I still have questions about how the IC obtains accurate, verified, and up-to-date geolocation data for node machines - @Dylan?

Table

	Continent	Country	Data Center	Owner	Node Provider	Node	Status
---	Europe	Switzerland	Geneva 2 (ge2)	SafeHost	Archery Blockchain SCSp	tn2ne-tskw6-dfk3n-urdmd-krtq6-tcebq-dx2xr-kokq7-eood7-fadkg-5qe	UP
---	Europe	Germany	Frankfurt 2 (fr2)	Equinix	Virtual Hive Ltd	4rpiz-7w7bf-smfm5-u7j3c-we6q7-qehxb-5lqnq-tjqsh-f7xu4-ihpao-zqe	UP
---	Asia	India	Colombo 1 (cm1)	OrionStellar	Geodd Pvt Ltd	zpjxp-c6l3m-x54lj-47zz5-dpy6u-lpdkt-hc7pp-gdfuu-i4i7i-jpp4w-lqe	DOWN
---	Asia	India	New Delhi 1 (nd1)	Marvelous Web3 DC	Marvelous Web3	x6ufc-46e3d-cvse3-vbjz6-gkrnq-4lpvu-6lloe-l24kd-y75gq-3pmt4-tqe	UP
---	Americas	United States of America (the)	Portland (pl1)	Flexential	87m Neuron, LLC	xgysg-f6alc-ft2ai-gseic-u3ohh-cvvkf-5pvjh-spcbk-gvkla-bwswo-jae	UP
---	Americas	United States of America (the)	San Jose (sj1)	INAP	Shelburne Ventures, LLC	y5xp4-nnr33-qeeeg-55unp-xr7f2-mkjfv-7qwe3-zxd7k-lmqd2-mftya-7ae	UP
+++	Asia	China	Seoul 3 (kr1)	KT	Pindar Technology Limited	isegs-i4akf-kb7st-hnqjn-4col7-qxpph-pncbs-25hiy-5pwsu-nyw3x-xae	UNASSIGNED
+++	Asia	Sri Lanka	Colombo 1 (cm1)	OrionStellar	Geodd Pvt Ltd	bv2x3-p2b3h-b23rg-aoq3s-kdzo2-pipmf-5y2me-jfa4w-tb7vr-qistz-2ae	UNASSIGNED
+++	Europe	Latvia	Riga 3 (rg3)	Nano	Artem Horodyskyi	k2ovz-ptdmz-hzmkh-ntfqn-evhux-ktxz4-26jg6-qjjsa-rpgal-wkdjo-kqe	UNASSIGNED
+++	Europe	Romania	Bucharest (bu1)	M247	Iancu Aurel	jyh32-azcnn-mwosu-urewl-m3pyx-6pmlq-lu5fu-vqjyl-gwx3j-zqrjr-gae	UNASSIGNED
+++	Asia	Singapore	Singapore 3 (sg3)	Racks Central	OneSixtyTwo Digital Capital	mf3d3-z5tww-ii4jn-zhy4f-ah3un-wpre7-edsb4-ktrb5-h7f3f-uz7rv-bqe	UNASSIGNED
+++	Americas	United States of America (the)	Houston (hu1)	TRG	43rd Big Idea Films	m2g5i-bmomq-dyjao-k642i-fsfxg-trxki-6i42q-hm6ec-xu5cd-n5jhq-sqe	UNASSIGNED
	Americas	Argentina	CABA 1 (ar1)	SyT - Servicios y Telecomunicaciones S.A.	Mariano Stoll	yahq2-6rnmm-n7ubm-q76zd-256dl-5f7k6-jxx5l-njyo2-hl7tk-sqcet-6ae	UP
	Oceania	Australia	Melbourne 2 (mn2)	NEXTDC	Icaria Systems Pty Ltd	onv2n-rm4ad-mgpnn-iiheu-6a76r-crgmo-wxpwt-dqf6y-n7gcf-5po4q-2qe	UP
	Oceania	Australia	Queensland 1 (sc1)	NEXTDC	Karel Frank	u4zo2-i6nsc-mowwj-lf6az-s6rdo-caskt-a6yx6-fke5w-qyezs-lyqvn-tqe	UP
	Europe	Belgium	Brussels (br1)	Digital Realty	Allusion	swzzz-nct4o-kgh2s-fezeh-luamk-chexm-jsk4r-ks2qa-au63y-jtc7r-pae	UP
	Americas	Canada	Quebec l1 (mtl1)	Leaseweb	Marvelous Web3	anudy-m6vfi-lphxb-sazpy-la4ti-2hriw-c67ny-butfn-axcel-otvuh-oqe	UP
	Europe	Switzerland	Zurich 2 (zh2)	Everyware	DFINITY Operations SA	6hkcx-vz4jv-4n33r-ywdvs-sefaa-tb2on-rac6s-4csut-iyahu-zmct2-5qe	UP
	Europe	Switzerland	Zurich 2 (zh2)	Everyware	DFINITY Operations SA	tg4ec-b2g4p-h42kd-k7zvb-6rls2-i2q7l-gtr4h-ymr6v-rrez4-w6fao-oqe	UP
	Asia	China	HongKong 3 (hk3)	hkcolo	Power Meta Corporation	rcxhc-af5ln-myck4-qrbsj-aelzk-l4hy4-o4fws-7kx57-ajldl-v6pmo-fqe	UP
	Asia	China	HongKong 4 (hk4)	hkntt	Origin Game	5iihd-fkroy-ow5zp-hlvwz-bsgbl-mecta-kxubm-6adxr-ckcu6-prsus-fqe	UP
	Americas	Costa Rica	San José 1 (cr1)	Navegalo	GeoNodes LLC	ltzjy-54bkf-bwynr-rcqst-ncpe6-qlg4x-tvhmp-73bm5-75e7u-t7c7s-eae	UP
	Europe	Czechia	Praha 1 (pa1)	MasterDC	Ivanov Oleksandr	mjte3-dopva-7tttu-5hnnu-q572b-p3wwy-b56of-4q6h7-hbtf4-f3m32-tae	UP
	Europe	Czechia	South Moravian Region 1 (bn1)	Master Internet	Lukas Helebrandt	mae7q-ggnbj-xb52f-hvest-dgqoc-whvsq-yui5d-5cys2-zeold-l5ydx-oae	UP
	Europe	United Kingdom of Great Britain and Northern Ireland (the)	London 1 (ld1)	Latitude.sh	Conic Ventures	ncr4b-rasb7-tueb3-n4uos-5nxou-3wbxv-xmyt3-wfdsd-vu4b6-5x3cp-aqe	UP
	Asia	Georgia	Tbilisi 1 (tb1)	Cloud9	George Bassadone	txh2c-fneot-jj3ys-cx355-22tvp-cw3az-ohxyy-rk7ok-d7ppu-efk4t-iqe	UP
	Asia	India	Navi Mumbai 1 (nm1)	Rivram	Rivram Inc	6hvx2-ymemx-tmykh-vxyic-bgfhv-2lcmt-3oy4x-rysuf-rnerz-vqokw-sqe	UP
	Asia	India	Panvel 2 (pl2)	Yotta	Krishna Enterprises	w2sev-mtuls-aa7m5-cdjgi-5vipg-2jn7i-4awvf-o6suu-73ebs-sw5db-kqe	UP
	Asia	Israel	Tel Aviv 1 (tv1)	Interhost	GeoNodes LLC	gvm7l-ds4n6-vkyjn-gwalp-3vdo6-qfmq7-pxhu4-zvqcu-ozvb7-qz3gr-vqe	UP
	Asia	Japan	Tokyo 3 (ty3)	Equinix	Starbase	5mpdi-v4qj2-64are-tbe6r-6335g-6tksh-c7uzq-w3xyz-o4p5g-rwnll-vqe	UP
	Asia	Korea (the Republic of)	Seoul 1 (sl1)	Megazone Cloud	Neptune Partners	2ftux-ivgjc-t4i2d-lq5hs-myjdg-3h2pz-l2ddl-nsxfc-wlaq7-fkbc5-6ae	UP
	Europe	Lithuania	Vilnius 1 (bt1)	Baltneta	MB Patrankos šūvis	24fcm-3onfs-cykax-al4jb-gvdd3-u76zl-ht6ef-hcsbc-xwf54-xbrym-xae	UP
	Europe	Poland	Warszawa 3 (wa3)	DataHouse	Vladyslav Popov	ouffe-miylc-6zcwl-afv2d-lai62-qwzns-xtlji-p7pu2-qkx2e-x72y2-sqe	UP
	Europe	Portugal	Barreiro 1 (ba1)	Online	Maksym Ishchenko	74qsa-j6jno-nmxmb-7jpf5-u6nig-g7hgo-thvjm-6f6zu-c2ugp-krple-qae	UP
	Asia	Singapore	Singapore (sg1)	Telin	OneSixtyTwo Digital Capital	gsrhr-kwp6h-y6ibc-yftud-fzi66-vg5df-subl3-wiren-uzza6-rb5fc-dae	UP
	Europe	Slovenia	Ljubljana 2 (lj2)	Anonstake	Anonstake	gj6gc-mbslq-bt63y-72b7h-xs2xw-6vyuj-frvp3-tx375-dsqx5-wem6o-vqe	UP
	Europe	Slovenia	Maribor (mb1)	Posita.si	Fractal Labs AG	tm3pc-2bjsx-hhv3v-fsrt7-wotdj-nbu3t-ewloq-uporp-tacou-lupdn-oae	UP
	Americas	United States of America (the)	Allentown (aw1)	Tierpoint	Bigger Capital	geihd-pwhjg-q3tno-beo64-ormih-pkjah-rrdlu-quwdk-nas5k-lmzoo-pae	UP
	Americas	United States of America (the)	Atlanta (at1)	Flexential	Goat, LLC	p3g3j-vvhxl-luedm-woh3j-sllez-jkbzz-274bf-hyuoc-kyo5t-kwziw-eae	UP
	Americas	United States of America (the)	Boston (bo1)	INAP	DFINITY USA Research LLC	fd5e4-a2xzl-lxu7m-kjvn6-2arnt-jghro-rdrgx-zvvkd-j2hza-pbwl4-5qe	UP
	Americas	United States of America (the)	Chicago 3 (ch3)	CyrusOne	MI Servers	2tk2h-7snvn-clgy3-g33vp-fc57w-ptljs-xujfq-fu47q-ludhi-g7zzf-xqe	UP
	Americas	United States of America (the)	Tampa (tp1)	Flexential	Richard Ma	3rj6n-nnhqn-nad5q-y262v-fuhk4-myqv2-6qzld-ouk7q-fbsuo-l2fi3-6ae	UP
	Americas	United States of America (the)	Vancouver (bc1)	Cyxtera	Blockchain Development Labs	jmuoq-7kbey-cbtmm-zlz6t-chwt6-dk7ly-d3jim-5nuu4-y5tou-l5egg-7qe	UP
	Africa	South Africa	Cape Town 2 (ct2)	Teraco	Kontrapunt (Pty) Ltd	noos2-mfe4u-r4gp3-jrjow-ancs2-ncakm-zi72z-zzcbg-uam7p-d4s6s-6qe	UP
	Africa	South Africa	Gauteng 2 (jb2)	Africa Data Centres	Honeycomb Capital (Pty) Ltd	wazkf-2xehg-y26ek-2uq64-pkrbh-6frmq-4q7lf-5gaya-44q4p-v5r5z-cqe	UP
	Africa	South Africa	Gauteng 3 (jb3)	Xneelo	Wolkboer (Pty) Ltd	q4ksz-lpvfy-ikkem-wyuaa-abopq-nmu5k-ovh6h-xfoqk-hx3x3-g2bk6-4qe	UP

---

Known Neurons to follow if you're too busy to keep on top of things like this

If you found this analysis helpful and would like to follow the vote of the LORIMER known neuron in the future, consider configuring LORIMER as a followee for the Subnet Management topic.

Other good neurons to follow:

• CodeGov (will soon be committed to actively reviewing and voting on Subnet Management proposals based on those reviews)

• WaterNeuron (the WaterNeuron DAO frequently discuss proposals like this in order to vote responsibly based on DAO consensus)

[Lorimer]

During the course of reviewing the above proposal, I noticed something interesting…

Two nodes that already belong to this subnet (and which belong to different data centers, owners, and node providers), actually have the exact same geolocation based on their IP address (yet are regarded as completely separate entities that would be uninclined to collude)…

Country	Data Center	Owner	Node Provider	Node	Status
South Africa (-26.1379, 28.1975)	Gauteng 2 (jb2)	Africa Data Centres	Honeycomb Capital (Pty) Ltd	wazkf-2xehg-y26ek-2uq64-pkrbh-6frmq-4q7lf-5gaya-44q4p-v5r5z-cqe	UP
South Africa (-26.1379, 28.1975)	Gauteng 3 (jb3)	Xneelo	Wolkboer (Pty) Ltd	q4ksz-lpvfy-ikkem-wyuaa-abopq-nmu5k-ovh6h-xfoqk-hx3x3-g2bk6-4qe	UP

What do you make of this @SvenF, @sat, @Dylan? I think this also ties into the question of how the geolocation information displayed on the IC dashboard is obtained, validated, and kept up-to-date.

[Dylan]

@Lorimer

I think this also ties into the question of how the geolocation information displayed on the IC dashboard is obtained, validated, and kept up-to-date.

Hi @Lorimer, the latitude and longitude of a data center comes from the NNS proposals that added the data center. For the two South Africa data centers that you referenced, these are the two corresponding proposals, and the latitude and longitude in the proposals matches what’s used on the ICP Dashboard:
Add data centers: [jb2]
Add data centers: [jb3]

[Lerak]

Hi @Lorimer

You don’t have the correct coordinates in your post. The coordinates you have for these data centres are for jb1 and not to jb2 or jb3.

jb2 and jb3 are independent data centres, close to each other. The x,y coordinates on the dashboard differ from what you have and they are not the same.

jb2

Data Center: Gauteng 2

-25.93, 28.138
17 Waterloo Road, Samrand Business Park, Centurion 0187, South Africa​​

jb3

Data Center: Gauteng 3

-25.927, 28.142
21 Landmarks Avenue, Centurion, South Africa

[Lorimer]

You’re using the dashboard to ascertain where these nodes are located, which as @Dylan pointed out comes from the proposal that onboarded these nodes. How can you be sure this is the accurate and up-to-date location of these nodes?

I’ve acquired the location dynamically, using the IP address to lookup the public geolocation record for these nodes. I’d like to discover what the best approach is for accurately verifying the current location of each node (I’m not convinced historic proposal information is the best way of doing this, but would love to discuss further so that we can come to some agreement)

[Lerak]

@Lorimer

using the IP address to lookup the public geolocation record for these nodes

Your observations just shows that the public geolocation records for these nodes are not accurate. I suspect that the ISP owns big blocks IPv6 addresses and use them to allocate smaller IPv6/64 subnets to clients in data centres across the region or even country. They also buy dedicated lines between data centres and the choose where they want to break out to the rest of the internet. Node providers don’t have any influence in the upstream routing decisions ISP make.

The only why the know for sure is to do a site visit and to confirm that the node in question are indeed in the said data centre, and connected to the IC.

This is a topic under discussion in the Node Provider Working group.

[SvenF]

Hi @Lorimer the information on GPS coordinates is part of the Data Center NNS proposals, please have a look at step 9 of the NP onboarding process. It’s used as part of the dashboard, and not for decentralization calculations right now. As you can see from the onboarding process it is currently a one-time registration. What the Node Provider Working group is discussing is where the process of onboarding and monitoring/auditing node machines can be improved, this takes time of course but the group is looking at topics such as:

• Improvements in registration and validation of new Node Providers.
• Audit of data center information based on desk research.
• Monitoring to predict actual geolocation of node machines, and verify against registry information.
• Usefulness of actual Data Center site visits for auditing.

[Lorimer]

Thanks @SvenF and @Lerak. I’ll keep an eye on those discussions.

@SvenF

It’s used as part of the dashboard, and not for decentralization calculations right now

Can I ask where this information is sourced from for the decentralisation calculations? Country is one of the nakamoto coefficients that are being optimised (I gather this comes from the original proposal as well, and that it’s part of the location data?).