Makes sense overall and the high level goals are very useful to understand the design changes necessary to implement that approach 👍

I have mainly two aspects for consideration in threads below, along with misc feedback:

1. I don't understand why the tunnel source must be the Pod IP range. This seems to impose a Pod Prefix routability requirement on the network, which means that even if Cilium doesn't need to know about every destination Pod in the cluster(mesh), the network at least needs to know about the routability information of every Pod in the cluster(mesh).
2. This CFP seems to on one hand specify egress policy as a non-goal, but at the same time has quite a few details about making egress policy work (particularly around the DNS handling and ToFQDNs policy). Do you intend to expand the scope of this CFP or move those aspects into a subsequent followup?

From what I recall, some parts of this were implemented, but not all. Additionally, some other features like CiliumCIDRGroups may have some overlap which could be worth considering if this is picked up again.

At a high level I scanned through and my feeling at this point is that the core idea of reducing pressure on the ipcache bpf map by changing the model of expected data in there makes sense as a specific feature. I think there was another set of changes in this CFP that were particularly opinionated around exactly how the networking works between nodes which I would ideally split out and consider as a separate point. The latter is related to the same goal of high scalability but IMO has a different design space and implications vs. the ipcache map management problems. These two could be combined for an opinionated architecture but otherwise do not seem to be fundamentally tied to one another.

All that said, I am happy to merge this in the "Dormant" state as-is. If and when we pick this up to move it forward, consider revisiting the above feedback to scope some of the discussions.