Open tlohmar opened 3 months ago
Hello Thorsten.
Telefónica sees that the API could be segregated into 3 lines of work:
It is important and, in fact, it is defined in the guidelines not to have references to specific telco technologies as you are proposing so maybe there is a good oportunity to re-visit the Scope of Network Slice Booking subproject. For us, dynamic Slicing proves such an interesting technology we would like to be part of, but it is important not to focus only in this technology (which actually is only available in 5G SA), but also support 4G and 5G NSA use cases.
Hi Ricardo,
thanks for the feedback. I also see a good re-use of QOD and other CAMARA features. Would be good to first progress on the last line (Provisioning Privates Networks over public network), before suggesting changes to existing APIs. One scenario is certainly allowing “on-demand” QOD API calls for the time, when dedicated network is in available state, and for devices, which are located in the service area of the dedicated network.
maybe there is a good oportunity to re-visit the Scope of Network Slice Booking subproject
Yes. Certainly an option.
More discussions can be found here. https://github.com/camaraproject/NetworkSliceBooking/issues/39
The reason of the above two suggestions is because, when we look into the network layer, especailly the real situation of CSP network, network situations differ a lot. 1) The network requirement of parameters differ, in terms of way of composition, in terms of access situations. 2) To fulfill the NaaS Service API, network layer needs lots of adaptions. Most of the job related to dedicated network resources rely on human work.
Based on that, we can see that 1) How the service api will possibly be like? Can we really make it simple, and that means the idea is applicable, and that's great. Or will that be really very complex, since it need to include all way of dedicated networks compositions?
@ShutingQing Can you clarify if you (and the Network Slice Booking sub-project) believe there is enough of a scope overlap between this new proposal and the existing Network Slice Booking sub-project such that this proposal should be considered as a scope enhancement to Network Slice Booking?
If so, then the proposal can be made a scope enhancement to Network Slice Booking, and any new API would get its own repository, but would be discussed in the existing Network Slice Booking meetings.
If not, then a new sub-project would be created for Dedicated Networks.
My view on the differences between the proposals, and to QoD, is:
Of course, we could imagine one "super QoS API" that covers all these scenarios, but I think there is enough scope difference that these can all be considered separate APIs for the moment.
@eric-murray Thanks Eric for your info. Given on the current infomation from "Dedicated Network" material, my view on that is:
Dedicated Network focus on "Dedicated Network" Resources, and see it as a NaaS Product. From Service API layer, it's goal and direction is to include more scenarios in only one Service API. And later it will be one NaaS product selling dedicated network resources.
Network Slice Booking API see "Slice" specifically as a NaaS Product. From Service API layer, it's goal and direction is to focus on Slice related features only, and go to more functions, which are around slice, in later. And later it will be a NaaS Product selling slice.
So I agree with you that there is enough scope differences, especially from the goal and direction, and to those influences on API design, that we need to consider them as different APIs at the current moment.
Based on that, we can see that 1) How the service api will possibly be like? Can we really make it simple, and that means the idea is applicable, and that's great. Or will that be really very complex, since it need to include all way of dedicated networks compositions?
I would suggest to clarify these questions first before moving to TSC. Since currently it's like we only know the idea. "Dedicated Network" is a pretty big scope, that's good, but I'm worrying whether it's applicable or possible to include all ways of "dedicated network resolutions/situations"? From my perspective, I think it could be very hard, since the service API will be super complex. If we can not include all situations, which ways of dedicated network resources situations the API can support? This is better to figure it out.
As per TSC decision for this proposal:
Start the work in a sandbox (repo) and then with provided assets check/reassess collision/overlap with other CAMARA API (like network slicing booking API but other APIs could be affected)
Repo is to be created, @tlohmar @tanjadegroot @jgarciahospital @eric-murray (main contacts used, please include those who may be more related to this API if needed) please provide list of maintainer/codeowners (name, company, github user)
Hi @jgarciahospital
For Vodafone: Codeowner: @eric-murray Maintainer: @SteveV-Vodafone
Fixed and Mobile Networks offer the capability of separating devices in different (logical) dedicated networks. Multiple of these (logical) dedicated networks can exist on the same physical network. Often, such a dedicated network with a specific performance (e.g. speed/ latency) is only needed for a specific time duration (e.g. one hour) and at specific locations (e.g. the area of a festival), potentially ensured by an SLA. The aim of the API is to request/modify/delete a dedicated network for API consumers with above mentioned characteristics. API consumers shall also be able to handle access to this dedicated network for devices.
PR Available #59