Objective can answer:

ou requested answers to the following questions:1. What is the identified technical reason for neutron-server growing to ~13 GB RSS and getting OOM-killed in this scenario? ; Is this expected behavior at scale, or a defect?
2. Please share the relevant Bugzilla / engineering defect reference(s). ; Can you confirm whether the fix is included in RHOSP 17.1.12, planned for a future 17.1.z, or only mitigated via workaround?
3. Does upgrading from RHOSP 17.1.4 → 17.1.12 fully mitigate this behavior, reduce its probability, or not address the root cause directly?
4. Based on current findings, can scale-out on other RHOSP 17.1.x clusters proceed safely prior to upgrade, or should scale-out be blocked until remediation?

OSPRH-25565 [Refinement] : "neutron-server" process consuming most memory on all three controllers causing nodes to go down