# How CNCF Projects United Two Countries' Engineers (NTT/SK Telecom) > [!question] Lingering Questions > - Latency across the 2,000km cluster is never mentioned — physically bounded near 10ms round trip before switching, and that's the number that decides distributed-training viability. Why is it omitted from a talk reporting bandwidth twice? > - Both reported measurements are Tokyo–Osaka, plausibly the shortest of eight site pairs. Is that representative, or best-case? > [!tip] Article Ideas > - "A shared technical vocabulary removes the need for a mediating party" — the collaboration claim (two telecoms designing "as equals across border" via shared CNCF tooling) is a genuinely under-argued case for open standards as a substitute for vendor mediation; worth developing with a concrete instance of what the shared stack resolved that proprietary tooling would have blocked. > [!link] Cross Reference > - [[Open Source Governance MOC]] — shared open tooling functioning as common ground between two national operators > - [[AI Cost & Tokenomics MOC]] — second of three KubeCon Japan 2026 talks in this batch naming physical (power/land) constraints on AI infrastructure — cross-reference [[Infinite Agents, Finite Kubernetes (SoftBank)]] and [[Large-Scale Edge Management with Kubernetes (PowerX)]] > [!quote] Vocabulary > - **KubeVirt** — CNCF project for running VMs on Kubernetes; chosen here specifically to run existing workloads unmodified while retaining tenant isolation ## Author's thesis NTT Docomo Business and SK Telecom operate eight data centers more than 2,000km apart as one combined GPU cluster over a wide-area L2 network, using KubeVirt so tenants stay isolated and workloads run unmodified — a response to a physical wall of power and land availability in Japan. The stated finding, foregrounded over the architecture itself, is that shared open source tooling let two national telecoms design the system "as equals across a border." ## Key arguments (≤3) 1. **The constraint is physical, not computational**: AI demand hits a wall of power and land, not chip availability — acute in land-limited Japan — so the response inverts the usual model (distribute rather than concentrate). 2. **KubeVirt was chosen for compatibility, not performance**: enabling unmodified workloads inside VMs, inherited from SK Telecom's existing Petasus AI Cloud, is what let two organizations reuse a proven pattern rather than invent one. 3. **The collaboration is presented as the actual finding**: shared open tooling gave two national telecoms a common language to negotiate architecture directly, without a vendor mediating or setting terms. ## Claim atoms ### Shared open tooling let two telecoms design as equals > [!quote] ID:rw_01kysr3rf7gqj2k0pr7a562exb > source brought us together. Communities and Cuba gives us a shared language. So, two teams could design as equal across border. **Where/why**: The talk's deliberate pivot from architecture to collaboration — the claim the speaker calls "the real story." (Auto-captions garble Kubernetes as "Cuba" and KubeVirt as "QBot" throughout.) Plausible and unevidenced — no specific instance is given of what the shared stack resolved that proprietary tooling would have blocked. ## Permanent candidates - **A shared technical vocabulary removes the need for a mediating party** — when two organizations already speak the same open technical stack, they can negotiate architecture directly as peers, because no vendor holds the position of translating or setting terms between them. Strong candidate: directly relevant to FAIR's technical-independence argument and to any federated-governance thinking in the vault. ## Processing checklist - [ ] Find the CNCF case study referenced in the talk for the latency and topology detail the talk itself omits - [x] Connect into the relevant MOC — [[3. Resources/MOCs/Open Source Governance MOC]] ## Links - [[3. Resources/MOCs/Open Source Governance MOC]] — shared open source tooling as the mechanism enabling cross-organization technical collaboration - [[3. Resources/MOCs/AI Cost & Tokenomics MOC]] — physical (power/land) constraint framing on AI infrastructure - [[3. Resources/Literature Notes/How CNCF Projects United Two Countries' Engineers (NTT-SK Telecom)]] — source video (KubeCon + CloudNativeCon Japan 2026)