Conversation
A network's address space is private and nothing a consumer writes says that instances on it may reach the internet. An instance on an IPv6-only network -- which is every network by default -- cannot reach an IPv4-only destination at all, and whether tenants reach the internet is currently a node-wide deployment setting invisible to the consumer. Propose a single capability on a network that says whether its instances reach the internet and which internet they reach, and define the contract that carries it to the node. Key changes: - Add spec.egress.internet with mode, reach and addressClass, where reach names destination families rather than a translation mechanism - Report source addresses per location on the network context, carrying a stability field so a consumer knows whether the address is theirs to depend on - Hand off to the data plane through the existing VPC attachment, making egress per-network rather than per-node so that disabling it means something - Name the gaps this does not solve: shared capacity has no per-network signal, and the useful default is unsafe until egress is rate limited and attributable
Rewrite the internet egress proposal to follow the Google technical writing guidelines. The content and the proposed API are unchanged; the prose is. Key changes: - State the audience, the prerequisite knowledge, and the terms the document defines before using them - Convert passive and literary constructions to active voice, one idea per sentence, with an explicit subject for every claim - Replace bare "this" and other ambiguous pronouns with the noun they refer to - Convert prose that enumerates to tables and numbered lists, including the stability contract and the dependency list - Use sentence case and parallel phrasing for headings and list items
privateip
previously approved these changes
Sep 17, 2026
Scope the first phase of internet egress to a whole network. Per-instance control moves to a later phase, and the interface field ships accepting only Inherit so that the default is settled before consumers depend on it. Key changes: - State that the network declaration applies to every instance on the network, and record per-interface control as a non-goal - Reserve egress.internet.mode on the interface claim, accepting Inherit only, and explain why fixing the default now beats adding the field later - Note that widening the accepted values depends on per-interface routing that no component implements - Replace the open question about shipping an override with the question that actually blocks it: what identifies an interface to the node
privateip
self-requested a review
September 17, 2026 18:43
privateip
previously approved these changes
Sep 17, 2026
Replace the address class reference on a network with an InternetEgressClass that an operator defines and a consumer names. A consumer naming an address class was naming an addressing-service concept to express an outcome, which is the leak the design set out to avoid. Key changes: - Add InternetEgressClass following the ConnectorClass pattern already in this API group: a controller name, the consumer contract, and a parameters reference for implementation detail - Make sharing the operator-side decision that projects to the stability a consumer reads, so one decision produces both - Keep the class reference one-directional so the data-plane API group stays independent of this one - State that no network claims an egress address, and that the address belongs to the resource serving the class - Say plainly that the class does not filter traffic, since security groups own that question
The handoff diagram still listed addressClass as the intent a network carries after the field became a class reference.
Add the edge-side model to the design. The proposal described what a consumer declares and where intent is recorded, but not which component claims an address, which component programs a node, or what the data plane has to change to honour a per-network decision. Key changes: - Give the cell controller the address claim, and keep shards out of the addressing service so that platform credentials stay off edge nodes - State that a shard holds no list of the networks it serves, because a node stamps the identifier the data plane matches on - Walk the eight steps from an operator defining a class to a node installing a route - Name the three data-plane changes this requires: the address becomes spec, the shard instruction becomes per-network, and the data-plane identifier should be allocated rather than chosen by hand - Note that a recorded binding is what makes failover possible
The design details restated the API that the proposal already covers, so the document explained the same fields twice and ran longer than the design it carries. Key changes: - Drop the section that repeated the network fields, and move the one fact it carried, the class reference, into the proposal - Fold the handoff chain and the allocation rules into the cell section rather than describing the same path three times - Trim the class and interface sections to the decisions they record
Three tables held content that reads better in the shape the content already has: a resource is YAML, and a value paired with its meaning is a list. Key changes: - Show InternetEgressClass as a resource, including the default-class annotation and a parameters reference - List the stability values and the condition reasons instead of tabulating two columns
Settle the open question about the launch default. A network reaches no internet destination until a consumer enables egress, which makes egress a capability a consumer opts into rather than one they discover. Key changes: - State the default where a consumer declares egress, and say why an unrequested outbound path is one nobody is accountable for - Rewrite the drawback to record the cost the platform accepts rather than a decision it defers - Remove the open question the default answers
The API withholds reach: [IPv4] until a resolver and translator share a prefix, which the platform does not pair yet. The enhancement doc still described reach: [IPv6, IPv4] as available now and described enabling egress as reaching both families immediately. Correct those claims and frame IPv4 reach as phase two. Key changes: - Change both reach: [IPv6, IPv4] examples to reach: [IPv6] - Fix the egress class parametersRef to cloud.datumapis.com, since network.datumapis.com hosts no controller - State in Motivation that phase one does not solve the IPv6-only reachability problem it names, since IPv4 reach waits for phase two - Re-aim the naming-destinations argument at the future reach: [IPv4] case instead of a present one, keeping the underlying reasoning - Note that Degraded is unreachable until reach accepts two families - Say the API refuses reach: [IPv4] outright, with its validation message, rather than leaving it as merely unimplemented - Add a Non-goals entry and a Proposal note calling out the phase split Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This was referenced Sep 17, 2026
Translation moves from a shard a class selects to the shard every compute node already runs. The consumer API keeps mode and reach on the network and drops the class, and the egress address moves from the network context to the interface, because it now belongs to the node an instance attached to. Key changes: - Remove InternetEgressClass, sharing, and per-location addresses - Report the address and InternetEgressReady on the interface; the context reports a summary and the DNS64 prefix - Bind at attach time from node configuration, so egress is live when the attach completes and a node with no shard fails the attach - Make EgressShardClaim a per-attachment record with a node binder - State the cell contract as a table with one writer per resource - List the data-plane dependencies: a node translating its own traffic, a shard configured from spec, a node agent reading its shard - Correct the cell-controller-manager reference and add the data-plane design references Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This was referenced Sep 26, 2026
The claim becomes the contract between the control plane and the running node. The infrastructure provider creates and deletes it as the network's mode changes, and the node agent follows it on its sweep, so a toggle reaches a running instance without a restart. Key changes: - Name the node agent as the claim's reader and move the claim into the network API in the cell contract - Describe the sweep, the grace after attach, and what disabling does to established flows - Narrow the node agent dependency to reading its shard, since the sweep ships with this design Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A network's addresses are private, so nothing a consumer writes says whether the instances on it may reach the internet. Today that decision belongs to whoever deployed the node: invisible to the consumer, all-or-nothing for everything running there, and impossible to turn on for one network or off for another. This proposes one capability on a network saying whether its instances reach the internet, with the platform translating on the node that runs each instance and reporting on that instance's interface the address its traffic leaves from. Phase one carries IPv6, and IPv4 reach follows once the platform can deliver it.
What a consumer gets
A consumer declares the outcome, not the mechanism. They say which internet their workloads need to reach and the platform decides how, so nobody has to learn what address translation is happening on their behalf.
They can also see the address their traffic leaves from, and how far to trust it. That second part is the one doing real work: the first version shares one address among the networks on a node, so the status says plainly that it may change and is not exclusively theirs. A consumer who allow-lists a shared address at a destination has been misled by the API, not by their own mistake. When a network can hold its own address later, the same field inverts that guidance without any previously-true value becoming a lie.
Egress is live the moment an instance attaches. Everything the node needs is already on the node, so no controller sits between the attach and the first packet out.
What it does not do yet
Phase one delivers IPv6 reach, so an instance still cannot call an IPv4-only service, which is most of what a workload calls. The API refuses IPv4 rather than accepting a value the platform cannot yet deliver, so phase two adds a capability rather than an API.
Shared translation capacity carries no per-network signal, so a consumer whose connections fail gets no explanation. The design names that gap rather than inventing a limit field, because a fabricated one would mislead more than an absent one.
Test plan
Related to datum-cloud/enhancements#865
Related to datum-cloud/enhancements#791