Andrea Mazzini shows the 2021-01-26 TAPI Additional Call - Meeting Notes, use case 1g.
- Last week Ramon Casellas indicated that it could be possible to stretch the Restconf by specifying in the same POST more distinct roots.
- In case, the POST response should include n x HTTP Header Locations.
- Reaffirmed that Restconf prescribes that identifiers must be defined by the Client. It is not foreseen Server assignment of identifiers.
- More general discussion on how the ConnectivityService creation is coded in the "Minimum subset required of TAPI RESTCONF Data API" table of RIA.
- Eventually agreed that the current POST is correct with respect to Restconf specifications:
- /tapi-common:context/tapi-connectivity:connectivity-context/
- Considering REST, the above expression would indicate a modification of ALL the content of "connectivity-context", i.e. a complete replacement of the whole "connectivity-service" list. In Restconf, the above expression indicates an ADDITION of the specified node to the "connectivity-service" list.
See https://tools.ietf.org/html/rfc8040#appendix-B.2, where "artist" is the new "connectivity-service" and "library" is the "connectivity-context":
B.2.1. Create New Data Resources
To create a new "artist" resource within the "library" resource, the client might send the following request:
POST /restconf/data/example-jukebox:jukebox/library HTTP/1.1
Host: example.com
Content-Type: application/yang-data+json
{
"example-jukebox:artist" : [
{
"name" : "Foo Fighters"
}
]
}
If the resource is created, the server might respond as follows:
HTTP/1.1 201 Created
Date: Thu, 26 Jan 2017 20:56:30 GMT
Server: example-server
Location: https://example.com/restconf/data/\
example-jukebox:jukebox/library/artist=Foo%20Fighters
Last-Modified: Thu, 26 Jan 2017 20:56:30 GMT
ETag: "b3830f23a4c"
- Then long discussion on the best way to provide server constraints of a ConnectivityService.
- Andrea Mazzini presents a possible simplification of CSEP provisioning, where a new class, "ServerConstraint" is composed by CSEP:
- In this way it is possible to recycle the technology specific augmentations of the generic CSEP without the need of additional CSEP instances, e.g.:
- Karthik Sethuramanand Ramon Casellas highlight that the proposed approach is limited to the constraints expressed by CSEP augments. There are also e.g. routing and resilience constraints which may refer to server layer of the ConnectivityService under provisioning.
- Karthik Sethuramanand Ramon Casellas agree that the bottom-up provisioning is still preferable for complex multi-layer provisioning scenarios.
- Andrea Mazzini recalls that regarding top-down provisioning, there is a requirement to create also server ConnectivityServices because:
- Alignment to bottom-up provisioning - if a given layer protocol foresees the ConnectivityService, then the ConnectivityService shall be instantiated regardless top-down/bottom up provisioning style.
- Editing capability of automatically created server layer connectivities.
- Karthik Sethuraman points out that the best way to fulfil the above requirements is to provision all the ConnectivityServices, client and server one(s) together.
- Using only "constraints" to drive the creation of server ConnectivityServices leads to two ways to edit a server ConnectivityService:
- by constraints associated to client ConnectivityService, and
- directly on the server ConnectivityService once it is created.
- Andrea Mazzini post-meeting note: as already discussed on previous calls, it is not possible to provision a tree of ConnectivityServices, because the server ConnectivityService(s) may support other future client ConnectivityService(s). In other words, the tree structure does not work for ConnectivityServices.
- Some conclusions:
- For Use Cases 1g and 2b check whether TAPI 2.1.3 can support them through simple amendments (or even just name-value pairs)
- If not, i.e. the modifications to 2.1.3 appear complex, then remove these Use Cases from 2.1.3 scope.
- In general, for simple constraints it may be preferable to use mechanisms like the CSEP "ServerConstraint" presented above.
- Post meeting note: Two-stage constraining of a server ConnectivityService:
- first stage at provisioning time of client ConnectivityService (few details),
- second stage at editing time of created server ConnectivityService (full details).
- Explore the provisioning of more ConnectivityServices in one operation, currently there are two possible solutions:
- combine more ConnectivityServices / "roots" in same Post,
- introduce the Order model.
Additional notes:
- Allowing two distinct MCG CSEP instances may be a temporary solution for 2.1.3, but to be evaluated the forward compatibility.
- Defining dedicated data structures for server layer constraints may be more forward compatible but to be evaluated the detailed impact on 2.1.3 version.
