Hi Phil -As there are quite a number of items in your message, I've copied into the stream and will reply to several of your itemsThanks for your document. This certainly was helpful in understanding the use cases that NaaS intends to address many of which I am sure our company already does with current software. However, I am looking for more of a concrete model for service and resource configuration that I am just not seeing in the Open API specifications, nor in your document.
TMF Open APIs are not about service and resource configuration standards but rather a standard pattern for enabling the various business functions (e.g., activation). Things like a standard service models are found in other standards -- MEF is really good example of a standard service definition. There are also some catalyst examples of using TMF Open APIs to facilitate the control of an MEF defined service.Further, as I've dug into the APIs I am a bit confused and lookin for others who might be able to help both on the desire to have payload definitions within the service or resource configuration APIs the map to BBF standards.
In looking the TMF 909A, TR640 and the Swagger document I am finding it difficult to know what interface definitions for the APIs are actually correct. As a simple example here are two representations of a POST for service creation and I have no clue which one is correct. I may need some pointers in the near future:
<u5:p></u5:p>
TR640 - POST /api/activation/service
TR909A - POST https://...../naas/activationAndConfiguration/1.0.0/service
Base path from Swagger. /DSEntityProvisioning/api/ActivationAndConfiguration/v2
Two items. The "activiation" versus "activationAndConfiguration" is a bug in the standard --- the latter is correct and there is an open JIRA ticket to correct the 640 text. The text I have bolded on each item is the routing (or API gateway information) and the non-bold is the relative path for the HREF. The bolder part is not consistent across the various documents, so we using the ..../naas in the 909 document to try to make it clear.
I am quite confused.
Further, I am a bit confused, though Dave has tried to clarify the relationship between TMF 640, 641, 664 and 909, so may have questions later.
As for service assurance, I am also looking at whether I can leverage TMF 653 and 656 along with BBF standards like TR-69 and the TR-98 and 181 object models as well at TR-355, TR-383, and WT-385. While I appreciate abstraction at the service layer at some point we need a concrete model to work with to configure resources and pull state information from network, CPE and other service delivery components.
At least as used in the 909 standard, 653 and 656 are used to abstract resource problems into service problems. The key concept of NaaS is hiding the resources from the consumer. I suspect you are more interested at the resource level and should look a number of resource focused standards (I don't recall all the number but there is alarm management, SLA, etc.).
I hope this provides some insight
Regards,
Corey
------------------------------
Corey Clinger
Network as a Service Architect
Telstra
------------------------------
Original Message:
Sent: Nov 15, 2018 18:59
From: Phil Fine
Subject: Network Resource APIs
Johanne,
Thanks for your document. This certainly was helpful in understanding the use cases that NaaS intends to address many of which I am sure our company already does with current software. However, I am looking for more of a concrete model for service and resource configuration that I am just not seeing in the Open API specifications, nor in your document.
Further, as I've dug into the APIs I am a bit confused and lookin for others who might be able to help both on the desire to have payload definitions within the service or resource configuration APIs the map to BBF standards.
In looking the TMF 909A, TR640 and the Swagger document I am finding it difficult to know what interface definitions for the APIs are actually correct. As a simple example here are two representations of a POST for service creation and I have no clue which one is correct. I may need some pointers in the near future:
<u5:p></u5:p>
TR640 - POST /api/activation/service
TR909A - POST https://...../naas/activationAndConfiguration/1.0.0/service
Base path from Swagger. /DSEntityProvisioning/api/ActivationAndConfiguration/v2
I am quite confused.
Further, I am a bit confused, though Dave has tried to clarify the relationship between TMF 640, 641, 664 and 909, so may have questions later.
As for service assurance, I am also looking at whether I can leverage TMF 653 and 656 along with BBF standards like TR-69 and the TR-98 and 181 object models as well at TR-355, TR-383, and WT-385. While I appreciate abstraction at the service layer at some point we need a concrete model to work with to configure resources and pull state information from network, CPE and other service delivery components.
Any help is appreciated.
Thanks
,
<u5:p></u5:p><u5:p></u5:p><u5:p></u5:p><u5:p></u5:p><u5:p></u5:p><u5:p></u5:p><u5:p></u5:p>
------------------------------
Phil Fine
National Information Solutions Cooperative, Inc.
Original Message:
Sent: Nov 09, 2018 10:20
From: Johanne Mayer
Subject: Network Resource APIs
Hi Phil, as Dave mentioned we are completing a Network as a Service component suite that may be useful for you if you are looking for APIs at the service level. Telstra has contributed this component suite and is using this suite between our OSS and our network domains and between our network domains.
NaaS is about network domains exposing their services hiding the resource level from the OSS so the network domains have more agility in how the service will be composed. It now provides us with the ability to change from PNF to VNF, or change resource vendors without impacting our OSS and BSS. The network domains are becoming more operational (we call them Operational Domain Management) and are responsible for the complete lifecycle of the services. Hence the resource level APIs and management will be within a domain only and can be different by technology as that information will be passed in the TMF API payload.
If you have access to the API project level, you can review TMF909 NaaS Component Suite under the 18.5 work in progress folder. I attach the NaaS API component suite profile document.
Best regards.... Johanne
------------------------------
Johanne Mayer
Telstra Corporation
Original Message:
Sent: Nov 09, 2018 06:08
From: Dave Milham
Subject: Network Resource APIs
Phil,
Two APIs to look at in this context are :
Bote are REST based using of SID models and are general purpose and extensible .
Using the Design Guidelines TMF 630 these can be extended for specific cases such as those that you list above .
However I am not aware that we have published such extensions for these examples.
But it may be that members have done this and may be willing to share?
Nevertheless the topic is of quite a bit of current interest as we are developing a Network as a Service (NaaS) proposition for the current release and it might be something that a member contribution could be included in the current release due in about a month .
------------------------------
Dave Milham
TM Forum Chief Architect, TM Forum
Original Message:
Sent: Nov 08, 2018 20:25
From: Phil Fine
Subject: Network Resource APIs
All,
I am searching for two specific APIs regarding network resource configuration and management. Specifically, I am looking to see if BBF, TMF or MEF have created one or both of the following RESTful or SOAP APIs:
- NBI API aligning with BBF TR-131 requirements, but exposed as a RESTful representation of functions based on the TR-98 or TR181 object models
- NBI APIs (e.g. RESTConf) based on BBF TR-355, TR-383, or WT-385 that are defined to sit on platforms like ODL or any other SDN like platform.
Our company automates service delivery and assurance and having a standard API (ideally RESTful) would make network service automation much simpler. The best models I have seen are TR-69 and TR-355 from a resource configuration and management, but I am looking for a well defined API for OSS layer integration of access and CPE components of the service delivery chain.
Thanks,
Phil
------------------------------
Phil Fine
National Information Solutions Cooperative, Inc.
------------------------------