In some cases, ETH have used 2 instances, can we verify the number of instances for each use case
4
Input Load Distribution the CM-handle search and ID search
Currently has 5 parallel request between them distributed at 2.5 each. This fractional distribution isn't feasible for parallel processing; the load should be allocated as whole numbers. Load needs to be distributed at. Would it be acceptable to adjust this distribution to either 2 or 3 parallel requests each (and vice versa ) without any negative repercussions?
5
Regarding CM-handle search and ID search
FS only identified Module performance, are there any testing done towards a combined search of properties and modules in a single query
Characteristics - WIP
It is proposed that reported characteristics will be used as a baseline for NCMP when agreed and sign-off.
Operation
Concurrent requests/parallel
DMI Delay
Response size
Performance Requirement (Blue Stone tablet KPI)
Notes
Sign-Off
1
Registration of 20,000 CM-handles (in batches of 100)
1 (requests are sequential)
100 ms to get module references 1,000 ms to get module resources
N/A
11 CM-Handles/second as per Stone Tablet E2E Wich include module conversion warm-up
NCMP Budget: 22 Cm Handles/second
Batch Size: 100 (per request) Not using Module Set Tags
Time measured start of first rest-call until all cm handle states READY
1,000 unique module references.
Five different types of Nodes. So 5 requests for Module Resources. Avg 200 modules each.
De-registration is currently not mentioned in Stone Tablet KPI or FS, however we have agreed to match the performance of registration for now as de-reg is also not a priority at this point in time
This is not in control of CPS. So for performance testing our stub should simulate a 10ms delay
Assume DMI is 1.25 seconds average DMI response time for high latency, low latency =10 ms, this should also work for DMI Plugin. I.e 40ms ontop of the DMI. 1.25seconds+40ms= 1.29seconds
Optionally insert the resource path ('rp:') if it clashes with the current
8
Granularity of update scenarios (and priority)
Add child and its descendants (supported in cps core)
Add all list elements (supported in cps core)
Replace child and its descendants (supported in cps core)
Replace all list elements (pending in cps core)
Update single leaf (new)
Add list entry (new)
Priority is pass-through only so it depends on the RETSConf protocol that is supported.
In Jakarta or if required by other projects more fine-grained 'operation' datastore update options can be implemented
9
Fallback option for datastore in release I
No, explicit datastore options will be used in Istanbul
10
fields is a rest conf option, investigate is it fully supported by onap
Supported in pass-through for ONAP DMI plugin but depending on the support by the actual target. The intention is to increase support 'fields' in future requirements following RFC-8040 for operational datastore etc.
Will we combine query capabilities with update capabilities?
We have decided not to combine query capabilities with update capabilities
13
Description of header limitations
HTTP Header Limitations Some servers put size limitations on HTTP headers, making them unsuitable for storing cmHandle information.
LIMITATION NOTE: server implementations put size limits on the headers meaning header contents should be designed carefully : Apache - 8K Nginx - 4K-8K IIS - 8K-16K Tomcat - 8K – 48K
14
Will NCMP support paths for pass-through:running
The plugin will not do transformation or validation of paths in the case of pass-through:running
15
Specification of path per cm handle
DMI Plugin can take cps paths or restconf paths and it needs to specify that per cm handle when cm handle is created
16
What is the default path for NCMP
In NCMP default will always be cps path and depending on the adapter we can change it as needed per cm handle
17
Fields parameter for ncmp/operational?
The fields parameter is ignored in ncmp/operational (in Istanbul release)
18
Is specifying the datastore mandatory?
Datastore is mandatory in Istanbul release
19
Register a DMI plugin with NCMP
DMI plugin is a part of cm handle registration. The rest endpoint on NCMP can be multiple calls
20
Retrieve list of modules (names) for a cmHandle
Retrieve a list of module names for cm handle - this will be used by ncmp to get the models. - assuming ncmp model discovery is complete and it is stored in cps core, this will come from cached information
21
Where will sync be implemented?
Implement sync in the dmi plugin and then have ncmp be able to pass on the request. This is not a bulk operation
22
Config-true only support (filter out config-false data)
Use datastore 'running' to select this but filtering not supported in I for cached data
23
Enable NCMP to convert cpsPath to mutliple options(RESTConf, netConf, leave as cpsPath)
When other DMI-Plugins are realized they might need a different conversion then the default from cspPath to RESTConf. This could be configured by using a known property for each cmHandle
Not required in Istanbul. But DB model can easily be updated to cater for this when needed
24
Datastore conversion in NCMP or DMI-Plugin
DMI-Plugin will know best how to convert. This will also reduce future impacts on NCMP for new options.
NCMP will do now conversion of datastore names
25
What datastore/s (name/s) is/are supported by NCMP to referred to the cached data. 'Operational' or 'running'
'operational' would imply RO and config=false data is included. 'To also support 'running' using the same data a filter would have to be applied
Consider fallback option when user specifies ncmp/operational but data is NOT synced
NCMP will forward requests for un-synced cmHandles to the DMI Plugin (Including required transformation of resource path etc.)
27
Support for &fields parameter when using cached data
not supported (ignored, not rejects, nice for future compatibility)
treat as 'no descendants' (low cost)
use to filter cached data
&Fields parameter will be ignored for 'cached' data in Istanbul timeframe
long term expectation is to have support following RESTConf/ODL behavior as much as possible
28
Support for &fields parameter when forwarding to plugin for non-synced cmHandles
not supported (ignored, not rejects, nice for future compatibility)
treat as 'no descendants' (low cost)
translate (insert module names) and forward
A spike
CPS-455
-
Getting issue details...STATUS
will be executed to determine the feasibility of option 3 and decide if it can make Istanbul scope
29
Response for Data Sync request (in Istanbul timeframe)
The action is blocking synchronous through whole stack (in I) so response could include the data returned by the node. However this seem incorrect for an 'action' so maybe the response should just be just an acknowledgment it is 'done'
No need to return data, just HTTP Code 200 (OK) will suffice
version of the ncmp interface <path> is the target resource URI <query> is the query parameter list
Mandatory
ch/<cmHandle>
unique (string) identifier of a yang tree instance.
Mandatory
<data|operations|{ncmpAction}>
request category - yang data, rpc operation or a (non-modelled) ncmp api action. this could be data, operations or ncmpAction (e.g. 'sync-data')
Mandatory
ds/{datastore}
Mandatory
<resourceIdentifier>
the path expression identifying the resource that is being accessed by the operation. If this field is not present, then the target resource is the API itself.
Optional
<options>
Parameters with the familiar form of "name=value" pairs. Query parameters are optional to implement by the server and optional to use by the client. Each optional query parameter is identified by a URI
Optional
DMI should be able to support (/pass through) ANY parameter associated with the RESTCONF message; see Section 3.4 of [RFC3986].
Datastores
New datastores are defined for ncmp to access the CPS 'running' or 'operational' datastore. Alternatively, the request can be sent directly to the 'device' itself (bypassing CPS datastores) using one of the 'passthrough-*' datastores options as below
The new ncmp datastores required for ONAP Release I include :
CPS-333 Network Configuration Management (NCMP) scope for I release considerations
Datastore Mapping in ONAP DMI Plugin impl.
#
Incoming DS value (NCMP & DMI Rest interfaces)
Outgoing (non-NMDA RestConf controller)
Notes
1
/ds/ncmp-datastores:operational
content=all
CT + CF, RO
2
/ds/ncmp-datastores:running
content=config
CT, RW
3
/ds/ncmp-datastores:passthrough-operational
content=all
CT + CF, RO
4
/ds/ncmp-datastores:passthrough-running
content=config
CT, RW
5
/ds/<anything-else>
N/A
Not supported
Datastore, Paths and Format Combinations for Read Operations
State
Input
Behavior
Data
Notes
#
Data-Sync
Datastore parameter
Expected resourcePath
format
Accept-Header
Fields
(filter)
Data Source
Included DataNodes (config)
1
On
Not Specified
cpsPath
application/yang-data+json
N/A
Not supported
N/A
N/A
2
On
Not Specified
cpsPath
application/json
N/A
Not supported
N/A
N/A
3
Off
Not Specified
cpsPath
application/yang-data+json
N/A
Not supported
N/A
N/A
4
Off
Not Specified
cpsPath
N/A
N/A
Not supported
N/A
N/A
there are NO DataNode objects in CPS to output as JSON)
5
Off
Not Specified
other then cpsPath
N/A
N/A
Not supported
N/A
N/A
Not supported Since NCMP can only convert cpsPaths
6
On | Off
ncmp/passthrough-operational
NCMP does not parse
NCMP does not parse
depends on DMI-Plugin (supported in ONAP)
Resolve DMI plugin
Forward request to plugin
Output received response
DMI-Plugin
config + non-config
The DMI plugin may error if the RP or accept header are not supported.
The DMI plugin may forward the request without processing too.
7
On | Off
ncmp/passthrough-running
NCMP does not parse
NCMP does not parse
depends on DMI-Plugin (supported in ONAP)
Resolve DMI plugin
Forward request to plugin
Output received response
DMI-Plugin
config-only
8
On
ncmp/operational
cpsPath
application/yang-data+json
Not supported in Istanbul releases.
Considered for Kohn Release
Read from cache
output: application/yang-data+json
CPS-Core
config + non-config
NCMP/CPS-Core needs to remove DataNode wrapping
9
On
ncmp/operational
cpsPath
application/json
Not supported in Istanbul releases.
Planned for Kohn Release
Read from cache
output: application/json
CPS-Core
config + non-config
Output will use DataNode wrapping (as is from CPS-Core)
For forwarding (cached config off) dmi-reposne need to be wrapped explicitly in 'DataNode'
10
Off
ncmp/operational
cpsPath
application/yang-data+json
to be determined in spike, see issue #28
Resolve DMI plugin
Convert cpsPath to RESTConfPath*
Forward request to plugin | Read from DMI plugin
Output application/yang-data+json
DMI-Plugin
config + non-config
11
On | Off
ncmp/running
cpsPath
application/yang-data+json
to be determined in spike, see issue #28
Resolve DMI plugin
Convert cpsPath to RESTConfPath*
Forward request to plugin | Read from DMI plugin
Output application/yang-data+json
DMI-Plugin
config-only
*Note Convert cpsPath to RESTConfPath wil only support 'absolute' cpsPath for conversion no query-type paths
Get all the registered cmhandles for a given plugin
GET
{ncmpRoot}/ncmp/v1/dmiPlugins/{pluginId}/ch
Scenario : Get all cmhandles from NCMP for a given dmiPlugin. May be used for conciliation Method : GET URI : {ncmpRoot}/ncmp/v1/dmiPlugins/{dmiPlugin}/ch Header : Content-Type: application/json