+14
−113
File changed.
Preview size limit exceeded, changes collapsed.
+4
−4
Loading
MEC apps (rnis, loc-serv, tm, dai, wais, vis, iot, sss) were all onboarded with MEEP_SCOPE_OF_LOCALITY=MEC_SYSTEM. Per ETSI GS MEC 011, MEC_SYSTEM means a service is discoverable by any app on any MEC host in the same MEC system, so mec_service_mgmt correctly skipped its per-MEP filter for every one of these services. The observable effect: querying mep2/mec_service_mgmt/v1/services returned mep1's services too (and vice versa) - the two MEPs were never actually isolated from each other's service registries. Switched these apps to MEEP_SCOPE_OF_LOCALITY=MEC_HOST across every network scenario file, restoring per-MEP service isolation. meep-federation (mec040) and meep-ams (mec021) are intentionally left at MEC_SYSTEM: federation's whole purpose is cross-system service exchange, and AMS's zone-to-MEP routing (MEEP_MEP_COVERAGE, parsed in go-apps/meep-ams/sbi/ams-sbi.go) requires it to be reachable from apps on either MEP to coordinate handover across MEP boundaries. Restricting either of these to MEC_HOST would break their documented function. Addresses rep/mec/etsi-mec-sandbox#17
File changed.
Preview size limit exceeded, changes collapsed.