...
- Development Process: Should we move the current 5GFF API implementation into an open environment, where all folks can contribute? Or possibly reimplement the APIs in an open forum?
- MEC Cluster Selection Criteria: Need to add K8s version of target cluster? (See KubeCon talk on x-cloud db migration.)
- Step A: Include new user scenarios. Should Step A be done in EMCO or in a workflow? EMCO could be an AF in the 5GC architecture. RBAC considerations?
- Relocation Decision: Since the UE needs to retrystart a new connection and not cache previous DNS lookups, how do we know whether the UE will do that? IOW, in Step B, how do we decide which UE or which PDU session can be subjected to relocation?
- DNS: Today we update the app's DNS record in PowerDNS. That has 2 problems:
- A DNS update for the app implies that all UEs will be diverted to the relocated app. That is not desirable. We want to divert specific UEs to the relocated app while other UEs continue to connect to the existing app.
- Assuming DNS updates are ok: PowerDNS will not let a new entry take effect while the old entry exists. IOW, the old app instance has to die before the new entry will take effect. How do we handle that?
- Traffic Steering: How do we ensure new TCP connections in the same PDU session are directed towards the relocated app?
- For Scenario B, one option is to set up a DNS cache in the TSC for each PDU session.
- For scenario A, we should investigate whether we can program the I-UPF to update a PDU session such that existing TCP connections stay unaffected while new TCP connections are forwarded to the relocated app. Ideally, this should be implementation-independent. There is some doubt whether Free5GC supports modification of an existing PDU session.
...