General discussion items
Top level construct
I am missing a class that can be used by services that need to include flow domains, connectivity and endpoints. I see it as useful and flexible to allow this.
For sure the TAPI model does not deal with services (customer and resource facing) – so I think that we should keep them loosely coupled via this missing class.
So just to play with a name here, lets call it a 'Reosurce'.
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlRvbnkgRmlubmVydHkiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiVG9ueSBGaW5uZXJ0eSIsImxhbmd1YWdlIjoiZW4iLCJkaWFncmFtRGlzcGxheU5hbWUiOiIiLCJzRmlsZUlkIjoiIiwiYXR0SWQiOiIxMDM0MjM4MjIiLCJkaWFncmFtTmFtZSI6IlRvcExldmVsUmVzb3VyY2UiLCJhc3BlY3QiOiIiLCJsaW5rcyI6ImF1dG8iLCJjZW9OYW1lIjoiUHJvcG9zZWQgVG9wb2xvZ3kgSU0gU2tldGNoIiwidGJzdHlsZSI6InRvcCIsImNhbkNvbW1lbnQiOmZhbHNlLCJkaWFncmFtVXJsIjoiIiwiY3N2RmlsZVVybCI6IiIsImJvcmRlciI6dHJ1ZSwibWF4U2NhbGUiOiIxIiwib3duaW5nUGFnZUlkIjoxMDA4OTQyMTUsImVkaXRhYmxlIjpmYWxzZSwiY2VvSWQiOjEwNzI0OTcyMiwicGFnZUlkIjoiIiwibGJveCI6dHJ1ZSwic2VydmVyQ29uZmlnIjp7ImVtYWlscHJldmlldyI6IjEifSwib2RyaXZlSWQiOiIiLCJyZXZpc2lvbiI6MiwibWFjcm9JZCI6IjJhOWM5NGM4LTcxNzQtNDhjMi1iYmJkLTNmNThjMTBkMTJhMSIsInByZXZpZXdOYW1lIjoiVG9wTGV2ZWxSZXNvdXJjZS5wbmciLCJsaWNlbnNlU3RhdHVzIjoiT0siLCJzZXJ2aWNlIjoiIiwiaXNUZW1wbGF0ZSI6IiIsIndpZHRoIjoiODIxIiwic2ltcGxlVmlld2VyIjpmYWxzZSwibGFzdE1vZGlmaWVkIjoxNjMwMzMyNDI1MDAwLCJleGNlZWRQYWdlV2lkdGgiOmZhbHNlLCJvQ2xpZW50SWQiOiIifQ==
I'm not trying to describe the service model here, just show how it could relate to the resource side of the house, and why the 'Resource' is an elegant way to hide some of the complexity of what a service is really made up of.
Ownership
The parent page (Abstract Topology Model) describes a requirement for an association of a topology entity to the software that owns it for a given purpose (e.g.: LCM; Configuration)
This is also missing from the proposal. Again just the concept here – of course it needs to have relationships to FlowDomain and Connectivity. These can be managed from multiple perspectives (LCM; Configuration; Assurance; ...) by different products.
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlRvbnkgRmlubmVydHkiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiVG9ueSBGaW5uZXJ0eSIsImxhbmd1YWdlIjoiZW4iLCJkaWFncmFtRGlzcGxheU5hbWUiOiIiLCJzRmlsZUlkIjoiIiwiYXR0SWQiOiIxMDM0MjM4MjciLCJkaWFncmFtTmFtZSI6IlRvcExldmVsUmVzb3VyY2VXaXRoT3duZXIiLCJhc3BlY3QiOiIiLCJsaW5rcyI6ImF1dG8iLCJjZW9OYW1lIjoiUHJvcG9zZWQgVG9wb2xvZ3kgSU0gU2tldGNoIiwidGJzdHlsZSI6InRvcCIsImNhbkNvbW1lbnQiOmZhbHNlLCJkaWFncmFtVXJsIjoiIiwiY3N2RmlsZVVybCI6IiIsImJvcmRlciI6dHJ1ZSwibWF4U2NhbGUiOiIxIiwib3duaW5nUGFnZUlkIjoxMDA4OTQyMTUsImVkaXRhYmxlIjpmYWxzZSwiY2VvSWQiOjEwNzI0OTcyMiwicGFnZUlkIjoiIiwibGJveCI6dHJ1ZSwic2VydmVyQ29uZmlnIjp7ImVtYWlscHJldmlldyI6IjEifSwib2RyaXZlSWQiOiIiLCJyZXZpc2lvbiI6MywibWFjcm9JZCI6IjAzNWRmMTI4LTVlMTUtNGU3OC1hZjNhLTJjMjlkNTYwNmE1NSIsInByZXZpZXdOYW1lIjoiVG9wTGV2ZWxSZXNvdXJjZVdpdGhPd25lci5wbmciLCJsaWNlbnNlU3RhdHVzIjoiT0siLCJzZXJ2aWNlIjoiIiwiaXNUZW1wbGF0ZSI6IiIsIndpZHRoIjoiODIxIiwic2ltcGxlVmlld2VyIjpmYWxzZSwibGFzdE1vZGlmaWVkIjoxNjM1Nzc3ODIyMDAwLCJleGNlZWRQYWdlV2lkdGgiOmZhbHNlLCJvQ2xpZW50SWQiOiIifQ==
You could put the 'ResponsibleManagerReference' as attribute(s) of the Resource, but I think it is (1) a type of resource in its own right and (2) potentially structured information required to interface with the actual manager instance.
Intent, plans and services
The separation of concerns (services and resources) is a principle that should be enshrined in the topology model.
By its nature a service is a simplified abstraction of what is used to realize it. The implementation details typically do not matter to a customer as long as the SLA is met. Bundling the service concepts into a resource model is going to make life more complex. Where there are service specific modeling needs, lets add them to the CFS/RFS classes.
Planning can be covered by a separate instance of the model – different type of separation. Application logic is responsible for the state transition (and the update of plan and actual topology models)
Intent is a wonderful new buzzword. It is only as good as the interpreter is. Eventually the intent needs to be translated into configuration of endpoints, connectivity and flow domains. Intent is also hierarchical, it will be evolved by layers of interpreters. Of course we need to keep the reference back to the intent for traceability (and possibly in scheduling). This can be achieved by having a simple hierarchical element that is referenced by the 'Resource'. So the participation of any resource in an 'intent' can be traced and interrogated regardless of the interpreter.
eyJleHRTcnZJbnRlZ1R5cGUiOiIiLCJnQ2xpZW50SWQiOiIiLCJjcmVhdG9yTmFtZSI6IlRvbnkgRmlubmVydHkiLCJvdXRwdXRUeXBlIjoiYmxvY2siLCJsYXN0TW9kaWZpZXJOYW1lIjoiVG9ueSBGaW5uZXJ0eSIsImxhbmd1YWdlIjoiZW4iLCJkaWFncmFtRGlzcGxheU5hbWUiOiIiLCJzRmlsZUlkIjoiIiwiYXR0SWQiOiIxMDM0MjM4NTciLCJkaWFncmFtTmFtZSI6IkludGVudCIsImFzcGVjdCI6IiIsImxpbmtzIjoiYXV0byIsImNlb05hbWUiOiJQcm9wb3NlZCBUb3BvbG9neSBJTSBTa2V0Y2giLCJ0YnN0eWxlIjoidG9wIiwiY2FuQ29tbWVudCI6ZmFsc2UsImRpYWdyYW1VcmwiOiIiLCJjc3ZGaWxlVXJsIjoiIiwiYm9yZGVyIjp0cnVlLCJtYXhTY2FsZSI6IjEiLCJvd25pbmdQYWdlSWQiOjEwMDg5NDIxNSwiZWRpdGFibGUiOmZhbHNlLCJjZW9JZCI6MTA3MjQ5NzIyLCJwYWdlSWQiOiIiLCJsYm94Ijp0cnVlLCJzZXJ2ZXJDb25maWciOnsiZW1haWxwcmV2aWV3IjoiMSJ9LCJvZHJpdmVJZCI6IiIsInJldmlzaW9uIjoyLCJtYWNyb0lkIjoiYTYxYmVjYmMtYTRhYy00OTA5LThkMTAtMTNkMTMwZmQxOWEzIiwicHJldmlld05hbWUiOiJJbnRlbnQucG5nIiwibGljZW5zZVN0YXR1cyI6Ik9LIiwic2VydmljZSI6IiIsImlzVGVtcGxhdGUiOiIiLCJ3aWR0aCI6IjQ5NyIsInNpbXBsZVZpZXdlciI6ZmFsc2UsImxhc3RNb2RpZmllZCI6MTYyNTgxOTE4NDAwMCwiZXhjZWVkUGFnZVdpZHRoIjpmYWxzZSwib0NsaWVudElkIjoiIn0=
Specific named classes
ManagedFunction
I think this is a type (specialization) of FlowDomain. Basically it is hierarchical in nature, i.e. value defined by an organization or standard that may be realized by virtual machines and or containers. It will contain termination points
