TI API: Resource modification #296
Conversation
Resource modification while action is still in progress: camaraproject#291
FabrizioMoggio
requested review from
gunjald,
Kevsy,
crissancas,
nicolacdnll,
gainsley and
javierlozallu
as code owners
|
It is used: GENERIC_409_DENIED_WAIT |
| traffic filter based on IP, Port and Protocol can be used. I this way it is | ||
| also possible to redirect different users to different interfaces. | ||
| Here are some possible intents: | ||
| 1) activate the optimal routing for the closest EAS instance: the TI API |
There was a problem hiding this comment.
A question on 1) when we say "activate the optimal routing for the closest EAS instance".
Does it mean that if the TI API (step 1) is triggered by a UE application and after that it may need to wait for the TI resource state to become "active". Once the state is "active" the UE application can assume that the UE may been moved to the optimal UPF near to the given EAS serving that location which is the job of the TI API.
Now in this active state the UE application can find endpoint of the EAS instance (i.e. appId) by using the Application Endpoint discovery API (step 2) which I presume that will deliver the EAS instance which is optimal or closest to UE as the earlier call to TI API was successful and hence due to right UPF assignment the traffic will be automatically optimally routed to EAS.
The above explanation is in relation to ongoing discussion #293 and written to clarify following points,
- The UE can only send traffic to an EAS whose IP is available to it before starting any traffic towards the EAS
- Once a packet has been generated with a given destination IP, this packet can only be processed by the host or an application (EAS) on that host
- There may be multiple routes between a given set of source and destination address with different traits in terms of QoS
My understanding is that TI API is mainly concerned with point 3 where it can attempt or influence network to reselect a UPF for a UE which can optimally serve a given UE trying to access an EAS in its current location.
Any traffic from UE via this UPF to an EAS which is hosted to an edge cloud accessible via this UPF is assumed to be on "optimal routed".
Hence once the TI API is successful then the UE needs to determine the EAS IP via other ways to as explained above but it is not the TI API task to deliver the EAS endpoints to UE.
I may be repeating the statements but only objective is to understand what actions are to be done in my API client application and what is to be taken care in the TI API implementation.
If require I may prepare few slides to explain and get your views.
There was a problem hiding this comment.
Hi @gunjald @FabrizioMoggio , If you want, Deepak could prepare few slides and I can reserve some slot on our meeting and disscus about this topic. Maybe tomorrow is a lit bit hasty, next meeting on october first, could fit for you??
There was a problem hiding this comment.
According to my understanding of the "story" described by @gunjald, his conclusion is correct.
- The optimal routing is active only when the TI API invokes the callback to inform the API Consumer about the "active" status
- From that moment the Service can instruct the App Client on which is the destination for the communication flow.
- That destination must be the same used in the TI API invocation.
- with: TI API: destination EAS IP address #294. The task for the Service will be easier
- When the App Client generates a flow toward that destination the network had already setup the optimal routing.
@JoseMConde for sure we can discuss about this in the next Edge Cloud call
One note: is this discussion preventing to approve this PR? The text we are commenting was already in the YAML, just moved to improve readability. The actual value of this PR is in the new error introduced (GENERIC_409_DENIED_WAIT) that prevents the modification of a requested intent while it is still under implementation. I suggest to approve this PR and we can open a new issue related to this discussion if required.
There was a problem hiding this comment.
Hi @FabrizioMoggio,
You are totally right, we can approve this PR and open a new issue with this topic. I also agree with you about the conclusions of the Deepak's explanation, but maybe It makes sense to open this issue to see what the rest of the group thinks about it.
Could you do it for me??
Thanks. :)
| code: CONFLICT | ||
| message: A specified resource duplicate entry found. | ||
| GENERIC_409_DENIED_WAIT: | ||
| description: Specific conflict situation that is relevant in |
There was a problem hiding this comment.
This text must be updated and specialized for the TI API
|
Are you fine with the usage of error 409? |
Resource modification while action is still in progress.
What type of PR is this?
What this PR does / why we need it:
The PR improves the error handling when the API Consumer invokes the TI API for the same Device-AppId if the previous requests are not completed yet.
Which issue(s) this PR fixes:
Resource modification while action is still in progress: #291