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
...
The plugin will not do transformation or validation of paths in the case of pass-through:running
...
KPI for De-registration of 100 CM-handles
This was mentioned. Was this ever agreed, is this a valid use case that needs to be covered together with the Registration ?
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?
Agreed to do 6 parallel request combined total and divide the load to 3 parallel request 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
As provided byCsaba Kocsis 0.625 seconds/Operation
FS stated 5 parallel request for both ID search and search. CPS to run with 3 parallel each for both ID search and Search meaning a combine total of 6 parallel request
FS stated 5 parallel request for both ID search and search. CPS to test with 3 parallel each for both ID search and Search meaning a combine total of 6 parallel request
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
Jira
server
ONAP Jira
serverId
425b2b0a-557c-3c0c-b515-579789cceedb
key
CPS-455
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 :
Excerpt Include
CPS-333 Network Configuration Management (NCMP) scope for I release considerations
CPS-333 Network Configuration Management (NCMP) scope for I release considerations
Excerpt
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
...
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
...
not supported (ignored, not rejects, nice for future compatibility)
treat as 'no descendants' (low cost)
translate (insert module names) and forward
...
A spike
Jira
server
ONAP Jira
serverId
425b2b0a-557c-3c0c-b515-579789cceedb
key
CPS-455
will be executed to determine the feasibility of option 3 and decide if it can make Istanbul scope
the set of parameters associated with the RESTCONF message; see Section 3.4 of [RFC3986]. RESTCONF parameters have the familiar form of "name=value" pairs. Most 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
...
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 :
...
Excerpt
Datastore, Paths and Format Combinations for Read Operations
State
Input
Behavior
Data
Notes
#
Data-Sync
Datastore parameter
Expected Resource-Path
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.
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