The network resides
entirely within the
Resource domain and so is managed with TMF634, TMF639, TMF664. TMF702 and TMF652.
The
Service domain contains the customer facing services (
CFS) which go into
Product Offerings. This is, done properly, an abstraction of the capabilities realized in the many technology specific subdomains of the Resource domain. Resource facing services (
RFS) may exist in the
Service domain which are technology specific bridges to the
Resource domain. While this is the transitional way of doing things a more functionally pure approach eliminates
RFS and instead includes
Resource Functions (RF) from the
Resource domain in
CFS.
Everyone struggles with the distinction between
Service and
Network Service (NS). The former is something which goes into products while the latter is represented by an
RF within the
Resource domain. For example a 5GC
Network Slice is an
RF and as such is managed in the
Resource domain (i.e. TMF664). If a CSP elects to sell
Network-Slice-as-a-Service you may
also have a
CFS for
NSaaS. An simpler example would be DNS (domain name service) which is a common
NS provided and consumed within the
Resource domain. Again, a CSP could offer
DNSaaS with a
CFS.
------------------------------
Vance Shipley
SigScale
------------------------------
Original Message:
Sent: Feb 02, 2023 02:27
From: Jonathan Goldberg
Subject: TMF702/TMF639 and Network Data Quality issues
The network would be exposed by Services (TMF638) and Resources (TMF702), which would presumably include logical, physical, and virtual (NFV) resources.
I'm not sure what would be the scope of an Entity inventory (TMF703), it could conceivably be "anything" of interest to the service provider.
Be aware that there is also a Topology Discovery API in preparation, @Yuval Stein or @Dave Milham could perhaps give more details.
Hope it helps
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
Original Message:
Sent: Feb 01, 2023 05:50
From: Jean-Christophe Nicolay
Subject: TMF702/TMF639 and Network Data Quality issues
Thanks for your response Jonathan.
The ID issue is indeed an important point to consider, but from a more general point of view, what do you think would be the best API to expose the Network ?
Should it be considered as Resources exposed via a TMF702, or a more generic Entity approched with the new (BETA) TMF703 for example ?
When checking what entities are defined in the SID, we were also considering using the Resource Performance ABE (at least for operational data and performance counters that are not necessarily modelled in our Resource model), but as far as I can tell is not yet existing as an OpenAPI.
------------------------------
Jean-Christophe Nicolay
Proximus SA
Original Message:
Sent: Jan 29, 2023 09:44
From: Jonathan Goldberg
Subject: TMF702/TMF639 and Network Data Quality issues
Hi Jean-Christophe
First, your point about the IDs of network resources is a very good one, and I don't think that we have fully considered its implications in the API team. This is so even without data quality problems. When you POST directly to the network (TMF702), what ID is returned? And how does that ID correlate to the corresponding ID in the inventory (TMF639). I plan to open a JIRA issue to highlight this (and similarly for Service - TMF640 vs TMF638).
Regarding data quality detection, you would need to invest in some reconciliation software, either built in-house or commercially (Amdocs has such software and I'm sure other vendors also have similar offerings). Given that you cannot necessarily rely on ID correlation you would need to use some other criteria, e.g. related party, to compare the actual network with the inventory. All this assumes, by the way, that you can retrieve data from the network. If your network is write-only :) then you may have problems :( .
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
Original Message:
Sent: Jan 27, 2023 06:52
From: Jean-Christophe Nicolay
Subject: TMF702/TMF639 and Network Data Quality issues
Hello,
I'm working on the implementation of the Assurance processes (data collection, data quality issues detection & correction, etc), and in that scope I'm trying to determine what is the best way to use the APIs to manage misalignment between the Network and the Resource Inventory.
A typical scenario is when we have some configuration remaining in a equipment, while having nothing documented in the Resource inventory.
How would you see this situation reflected in terms of calls towards TMF702 & TMF639 APIs ?
Should TMF702 always return the current state of the Network (that could be obtain via a FIND), and by comparing TMF702 & TMF639 responses we could determine there is a Data Quality issue ?
And if so, what kind of id should be returned in the response of the TMF702, considering it can't be linked to a TMF639 Resource because of the DQ?
Thanks for your help.
------------------------------
Jean-Christophe Nicolay
Proximus SA
------------------------------