Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents


Jira Legacy
serverSystem Jira
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keyCPS-391

...

  1. NCMP REST Interface will follow/be inspired by RESTConf interface for easy acceptance of and transition to this interface
  2. Will follow ONAP's RESTful API Design Specification 
  3. The interface will include the concept of data-stores inspired by Network Management Datastore Architecture (NMDA) and as used in RESTConf
  4. The application should be able to easily switch between 'pass-through' and other datastores (also identical rest endpoint and responses)

References

Follow principles/patterns of RESTCONF RFC-8040 https://datatracker.ietf.org/doc/html/rfc8040
Follow principles/patterns of yang-patch RFC-8072 https://datatracker.ietf.org/doc/html/rfc8040
Follow principles/patterns of RESTCONF NMDA RFC-8527 https://datatracker.ietf.org/doc/html/rfc8527

Requirements

Note

Please note this section was added long after the implementation and focuses on characteristic only.

Issues & Decisions

...

Issues & Decisions


IssuesNotesDecisions
1KPI for De-registration of 100 CM-handlesThis was mentioned. Was this ever agreed, is this a valid use case that needs to be covered together with the Registration ?

Not priority for now, but acceptable if we match the registration req.
#2 for de-reg  
kieran mccarthy Kolawole Adebisi-Adeolokun 

2DMI delayCould we get some feedback on DMI-delays for other use cases as not mentioned in FS document
Awaiing OperationTotal CM-handles registered

Awaiting for ETH feedback AP On Kolawole Adebisi-Adeolokun and Csaba Kocsis

Characteristics - WIP

It is proposed that reported characteristics will be used as a baseline for NCMP when agreed and sign-off.


Provided

3

Number of instances


In some cases, ETH have used 2 instances, can we verify the number of instances for each use case.

Some of the req were defined per instance and resources used : Identify which of these ? 

Agreed to;

CPS use 1 instance currently, but should focus on aligning performance with 2 instances for all use case 

4Input 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

5Regarding 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


Confirmed no other testing was previously done on this.....  

CPS have the capabilities to do mixed testing. ETH tbc on if they want to consider this ( Csaba Kocsis )


Requirements

Note

Please note this section was added long after the implementation and focuses on characteristic and enhancements after this study only.


Characteristics

It is proposed that reported characteristics will be used as a baseline for NCMP when agreed and sign-off.


OperationConcurrent requests/parallelDMI Delay
Rest response
Response sizePerformance Requirement
(Blue Stone tablet KPI)
NotesSign-Off
1Registration of
100
20,000 CM-handles
20k Nodes (200 operations
(in batches of 100)1 (requests are sequential)

100 ms to get module references

1000

1,000 ms to get module resources

N/A

  • 11
NEs
  • CM-Handles/second as per Stone Tablet
  • NCMP should target 22 NEs/Second 
  • Currently without Modulesettag, when // start using Modulesettag, we'll need to revisit these numbers. 

    • Currently as per FS -
    • module references - 20k 
    • get module resources -1000 unique module ref. 
    • 5 different types of Nodes
    ST 
    • E2E Which include module conversion warm-up
    • NCMP Budget: 22 Cm Handles/second 
    1. Batch Size: 100 (per request)
      Not using Module Set Tags
    2. Time measured start of first rest-call until all cm handle states READY
    3. 1,000 unique module references.
    4. Five different types of Nodes. So 5 requests for Module Resources. Avg 200 modules each.
    5. The average size of yang resources in bytes 31.437 (32KiB)
    2De-registration of 100 CM-handles
    20k Nodes (200 operations)
    1 (requests are sequential)

    No Module delays

    N/A

    • 11 NEs/second
    • NCMP should target 22 NEs/Second 

    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




    3CM-handle ID search with Module filter
    20k Nodes
    2.

    5 parallel

    (5)TDB

    request

    N/A
    100byte*20k

    TBD will be derived when testing is done in ETH envi

    Combine test3&4 to = 5 (2.5 each)
    20,000 CM Handles i.e.
    100*20.000 = 2MB

    2 seconds/operation

    FS stated 5 parallel request for each of ID search and search, meaning a combined total of 10 parallel search requests.
    4CM-handle search with Module filter
    20k Nodes
    2.TDB
    5 parallel requestN/A
    500bytes*20k per handleTBD will be derived when testing is done in ETH envi
    20,000 CM Handles i.e.
    500*20.000 = 10MB

    15 seconds/operation

    FS stated 5 parallel request for each of ID search and search, meaning a combined total of 10 parallel search requests.
    5Synchronous single CM-handle pass-through read
    20k Nodes

    10

    Awaiting input from eth Csaba Kocsis

    4 (Parallel operations)

    300 ms

    5 KB

    25 op/sec shall not exceed

    10 request/second

    Read are done in parallel with

    WritesTDBTDB

    Write and searches.

    Note CPS will test passthrough read using both cmHandleId and alternateId.

    6Synchronous single CM-handle pass-through write (CUD)
    20k Nodes

    10

    Awaiting input from eth Csaba Kocsis 

    5kb

    13 ops/sec 

    No response is expected

    4 (Parallel operations)

    670 ms

    5 KB

    5 request/second

    No response is expected
    7Batch/Bulk Read

    60 read request with 200 cmHandles each at 1 req/second.



    150 cmhandles/second


    1. 60 request in 60 seconds overall budget for last response is 80seconds for 60 request to be processed
    2. The batch data operation is asynchronous.
    3. NCMP returns the response on the ncmp-async-m2m kafka topic.


    Notes

    1. This is for mixed TCs
    2. Single KPIs will be monitored in NCMP owned pipeline with our performance every day(2 hrs interval) - Performance
    3. Test cases 3 through 7 are to run in parallel.

    Synchronous single cm-handle pass-through (read) requests

    ...

    Expand



    Description

    Notes

    Decision

    1Priority of async calls
    In Istanbul, async calls are required only in pass-through cases. NCMP does not have to handle these requests 
    2Will we use the data node wrapper on GET rest operations?

    Currently, we wrap the response of GET operations using the data node wrapper.

    we should mainly support yang-data/json

    controlled by "accept-header"

    3In the URI will we distinguish between data and operations (RFC calls) as part of the path?

    This only applies to pass-through

    yes, we will distinguish between data and operation

    4Which query parameters will NCMP support?

    Parent data resource identifier can handle any path using the same query parameter 

    1. cpsPath
    2. RESTConf Path (pass-through)
    3. Proprietary Path (pass-through)
    5

    Yml should include return types and examples of the payload


    Legacy and new API documentation needs to include output examples.

    Task created, see 

    Jira Legacy
    serverSystem Jira
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keyCPS-401

    6camel case or dash in URI

    We will use a dash for param names e.g. cmHandle (although it has since been agreed we use 'ch' in this particular case)

    See no.3 https://restfulapi.net/resource-naming/

    7Insert /resourcePath in front of the resource path to prevent ambiguous paths<OP>/ncmp/<v{vNumber}>/ch/<cmHandle>/<data|operations|{ncmp-operation}>/ds/{datastore}/[rp:]{resourcePath}?{query}Optionally insert the resource path ('rp:') if it clashes with the current
    8Granularity of update scenarios (and priority)
    1. Add child and its descendants (supported in cps core)
    2. Add all list elements (supported in cps core)
    3. Replace child and its descendants (supported in cps core)
    4. Replace all list elements (pending in cps core)
    5. Update single leaf (new)
    6. 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

    9Fallback option for datastore in release I
    No, explicit datastore options will be used in Istanbul
    10fields 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.
    11Agree on URI syntax 

    Proposed syntax by CPS team 

    <OP>/ncmp/<v{vNumber}>/ch/<cmHandle>/<data|operations|{ncmp-operation}>/ds/{datastore}/[rp:]{resourcePath}?{query}

    review completed and proposed URI agreed 
    12Will we combine query capabilities with update capabilities?
    We have decided not to combine query capabilities with update capabilities
    13Description 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

    14Will NCMP support paths for pass-through:running

    The plugin will not do transformation or validation of paths in the case of pass-through:running

    15Specification 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
    16What 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
    17Fields parameter for ncmp/operational?
    The fields parameter is ignored in ncmp/operational (in Istanbul release)
    18Is specifying the datastore mandatory?
    Datastore is mandatory in Istanbul release
    19Register a DMI plugin with NCMP
    DMI plugin is a part of cm handle registration. The rest endpoint on NCMP can be multiple calls
    20Retrieve 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
    21Where 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
    22Config-true only support (filter out config-false data)
    Use datastore 'running' to select this but filtering not supported in I for cached data
    23Enable 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
    24Datastore conversion in NCMP or DMI-PluginDMI-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
    25What 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 appliedsee supported datastore in I : Datastores16525680
    26Consider 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.)
    27Support for &fields parameter when using cached data
    1. not supported (ignored, not rejects, nice for future compatibility)
    2. treat as 'no descendants'  (low cost)
    3. 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

    28Support for &fields parameter when forwarding to plugin for non-synced cmHandles
    1. not supported (ignored, not rejects, nice for future compatibility)
    2. treat as 'no descendants'  (low cost)
    3. translate (insert module names) and forward

    A spike 

    Jira Legacy
    serverSystem Jira
    serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
    keyCPS-455
     will be executed to determine the feasibility of option 3 and decide if it can make Istanbul scope

    29Response 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


    ...

    Expand
    #Req/usecase

    REST

    Method

     URI

    Request/Response Example
    1DMI notifies NCMP of new , deleted or changed cmhandles DMI Plugin NCMP. Including initial registrationPOST{ncmpRoot}/ncmp/v1/ch/
    Scenario : DMI notifies NCMP of new cmhandles
    Method : POST
    URI : {ncmpRoot}/ncmp/v1/ch/
    Header :
    Content-Type: application/json

    Code Block
    languagexml
    titleRequest Body
    Request Body : {
          "dmiPlugin" : "onap.dmi.plugin", 
          "createdCmHandles" : [ {   "cmHandle" : "rf4er5454",
                                     "cmHandleProperties" :
                                       { "subSystemId" : "system-001" }
                                 }, {..} ],
          "updatedCmHandles" : [ .. ],
          "removedCmHandles" : [ "node-1", "node-2" , ... ]
      }


    json attributes:

    • "dmiPlugin" resolvable servicename
    • "createdCmHandles" used for initial cm handle registrations or subsequent
      cmhandle creations
    • "updatedCmHandles"
      Used for updates to cmhandles. Same structure as for create handles
    • "removedCmHandles"  array of cmhandles that have been deleted
      from the network (no additional properties
    2Get all cm handles that support  all modules in a given list of modulesPOST

    {ncmpRoot}/ncmp/v1/ch/searches

    URI :  {ncmpRoot}/ncmp/v1/ch/searches


    The minimal requirement is if we provide the AND query impl then for OR query the client can send multiple requests


    Request Body

    Content: application/json

    Note: revision should be optional 

    {
      "modules": [
        {
        "moduleName": "", (Mandatory)
        "revision": "" (Optional)
        }
      ]
    }


    Header :
    Accept: application/json
    Response:

    Should return an array of objects as we may add more data in the future 
    {
      "cmHandles": [
        {
          "cmHandleId": "xxx"
        }
      ]
    }

    3Request (trigger) Data SyncPOST

    {ncmpRoot}/ncmp/v1/ch/<cmHandle>/syncData

    Scenario : Client requests to sync a node

    URI : {ncmpRoot}/ncmp/v1/ch/node123/syncData

    Response   : HTTP-Status code (only, no body)

    4Get model info for CMHandleGET

    {ncmpRoot}/ncmp/v1/ch/{cmHandle}/modules

    Scenario : Get the model data for CMHandle

    URI :{ncmpRoot}/ncmp/v1/ch/2334dedf/modules

    Header :
          Accept: application/json

    Response:

      [
            {
                "moduleName": "nc-notifications",
                "revision": "2008-07-14",
            },
            {
                "moduleName": "ietf-tls-server",
                "revision": "2016-11-02",
            },
            {
                "moduleName": "ietf-ssh-server",
                "revision": "2016-11-02",
            }
        ]
    5Get all the registered cmhandles for a given pluginGET{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

    Code Block
    languagexml
    titleResponse Body
    Success Response :
        HTTP/1.1 200 Ok
    Date: Thu, 26 Jan 2021 20:56:30 GMT
    Server: example-server
      { "cmHandles" : [ {
              "cmHandle" : "node-1",
              "cmHandleProperties " : { "subSystem" : "system-001" }
           } ]
       }



    ...