You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 25 Next »

CPS-1812 - Getting issue details... STATUS

Requirements

Functional

#Interface

Requirement


Additional InformationSign Off
1CPS-E-08.eNCMP is to merge CM Notification Subscriptions Create request for the same CM Handle & XPath(s)
  • Prevent unnecessary subscription updates to nodes already involved in a subscription to the same path
  • For possible combinations, see table below

2CPS-E-08.e

Last lights out: upon subscription Delete request only when there is no more subscription for a cm-handle & xpath combination a subscription-delete request wil be send to the relevant DMI(s)



3CPS-E-08.eAmalgamation per DMI: all subscription updates originating from a single client request should be send to a single DMI in one request (message). Of course there can be several message if more than 1 DMI is involved.The need for amalgamation / granularity of message might need to be discussed pending the required characteristics (issue #8). If a single subscriptions can contain all possible cm-handles with many cps-paths it then becomes feasible all CM-Handles refuse all paths or a specific path...  Will all that info fit in a single response message. Is that the right thing to do?!!!
4CPS-NCMP-I-01CM Handle deletion should update subscription detailsdo NOT delete dmi-subscription entry until owning subscription is deleted, see issue #4 below
5CPS-E-08.ebackward compatible with 'basic' created/delete operations.. TBDcould use versioning in API–methods and schema's to handle this?!

Error Handling


Error ScenarioExpected behaviorSign-off
1DMI Downrejected
2DMI Not responding withing 30 secpending
3create for non-existing cm handle idrejected
4delete for non-existing cm handle id(silently?) ignore
5any operation on non-existing xpathignore? (no or minimal validation, see issue #5)
6delete for non existing name/client-idTBD, should be handle in 'basic' solution
7delete for no existing cm-handle idignore? (no or minimal validation, see issue #5)
8error upon error

An error scenario on a second subscription for the same cm-handle/xpath as a previous subscription which did not complete successfully (yet)

to be discussed, see tabel below


Characteristics

#ParameterExpectationNotes
1Maximum number of cm data subscriptions

2Maximum, Average CM Handles/subscription 

3Maximum, Average XPaths/CmHandles

4Status update processing time limitBased on the numbers above working out the current state of each cm handle/xpath combination could be slow!
5


Out-of-scope

  1. CM Notification Forwarding Check: When forwarding CM Notification NCMP will not check the content to see if the is a valid active subscription. It is assumed that the DMI Plugin as acted on the 'delete subscription' request (that request is NCMPs responsibility). And of course there wil be timing issues it also possible a CM Notification was send just after the subscription-delete was send (from client) but before the whole change had acted upon that. 
  2. Retry: NCMP wil only report when actions are pending or rejected. NCMP will not implement a retry mechanism
  3. Wildcards: Wildcards or similar functionality where one string represent 0 or more xpaths is not covered as part of this requirement but it should be kept in mind as a future possibility
  4. Dynamic Topic: Topic for CM Data Notifications back to client will be hardcode for now

Assumptions

#AssumptionNotes
1Targets is a collection of xpathscan be implemented as a json array of strings
2for the DMI plugin cm-handle-id and xpath are the key to a unique subscriptionthe client-id and subscription name are not relevant for the DMI (should not be included in the request) as this would break the concept of merging!

Issues & Decisions

#IssueNotes Decision
1Is it intended that CM Notification subscription request  cover (all) descendants of the given xpath too?!e.g.. if a child is removed and there is a subscription for the parent node, will a notification be send (grandchild, child leaf updates etc.) I hope NOT!
Consider:
  • Risk of client effectively subscribing to ALL data in a cm handle by specifying top level datanode(s)
  • Complexity (i.e. cost of) of merge operation. It might even required NCMP to check relevant dat model
  • Future use of wildcards, could be a viable alternative for including descendants

2Could xpath point to an element that does not exist (yet)if not how, how can I client be informed about a create event? 
3Should NCMP support re-homing, moving of a CM Handle from one DMI to another?assume only trough delete & create 
4CM Handle Delete: Should DMI or Clients be sent a subscription update (assume no)do NOT delete dmi-subscription entry until owning subscription is deleted
(just ignore upon future delete if cm handle is gone altogether)
5Validation of xpathoptions order of implement and also performance cost!
  1. none
  2. xpath-parser
  3. model check
  4. instance check

6can DMI plugin 'reject' a subscription create (for a given cm-handle-xpath combination)As NCMP might not validate as per issue#5 the DMI=plugin or component further down might have to reject an invalid xpath...

Priyank Maheshwari 

yes currently DMI can use response to say which cm handles are not accepted i.e. rejected' (but not 'pending')

7implementation question: should 'rejected' DMI-subscriptions be storedI would think not
8Dimensioning of DB depends on #cm handles, #subscriptions and #xpaths per subscription, this could be too big for fast processing of updates! Need to agree maximum and possibly realistic average/total number of entries based on the characteristics  above
The team is blocked until this becomes clear as it wil affect the way the data needs to be modelled exactly
9Maximum (error) message sizetheoretically all cm handles and all xpaths combinations could be rejected or pending leading to a very large error message!
10can each CM-Handled have different set of xpaths(s) per subscriptionthe  current 'basic' solution only supports a common set of datastore/xpaths (filter)
11can the same cm handle/xpath have different subscriptions with different datastores, does that affect the cm data notifications send (which datastore applies)

12will migration from 'basic' be supportedPreferred to ask customers to create new subscriptions


Solution Proposals 

Current state handling for 'basic' (not merged) subscription create/delete (under development)

Scenario 1
1) Create Sub from Client: CH-1, CH-2
2) All handled by DM1
3) NCMP to DMI request Create sub:  CH-1, CH-2
DMI responds within 30 seconds: Status OK

NCMP Send message to client: Statsu OK (no list with Rejected/Pending)


Scenario 2
1) Create Sub from Client: CH-1, CH-2
2) All handled by DM1
3) NCMP to DMI request Create sub:  CH-1, CH-2
DMI does NOT respon with 30 seconds

NCMP Send messge to client: Pending [CH-1, CH-2]

Scenario 3
1) Create Sub from Client: CH-1, CH-2
2) All handled by DM1
3) NCMP to DMI request Create sub:  CH-1, CH-2
DMI responds within 30 seconds: Rejected [CH-2]

NCMP Send message to client: Rejected [CH-2]

Scenario 4:
4 different DMIs each handling 2 Cm Handles, create sub for all CHs 

Scenario 4-part a
DMI1 CH-1, CH-2 All accepted within 30 secs
DMI2 CH-3, CH-4 Mixed result witin 30 seconds e.g. Rejected [CH-4]
DMI3 CH-5, CH-6 No result after 30 seconds
DMI4 CH-7, CH-8 No result after 30 seconds

NCMP -> Client : Rejected [CH-4], Pending [ CH-5, CH-6, CH-7, CH-8 ]

4-part b
DMI3 PLugin responds after 40 seconds; status OK
NCMP -> Client : Rejected [CH-4], Pending [ CH-7, CH-8 ]

4-part c
DMI4 PLugin responds after 50 seconds; Rejected [CH-7]
NCMP -> Client : Rejected [CH-4, CH-7]

Note. The above algorithm depends ons storing (in DB using yang modelled data) a cm-handle status for each cm-handle for each subscription!

Merge → Split

  • NCMP treats a Client Subscription as one or more (small) DMI Subscriptions, each of which wil have there own state.
    Each DMI Subscription is related to 1 or more client subscriptions.
    If there is no more related client subscription the DMI Subscription can be deleted (once accepted by DMI Plugin)!

Data Model (not a great diagram...)

 

Create Combinations

Below examples demonstrate what should happen when two separate subscriptions operations are performed:

  1. an operation on subscription 'A' for client id '10
  2. an operation on subscription 'B' for client id '52'
#Existing Subscription A-10Client Create Subscription B-52 RequestDMI Create RequestData Model Before (2nd) CreateData Model After Create
1CH-1, [ /p/c1, /p/c2 ]CH-1, [ /p/c1 ]None
Client  Subscription
DMI Subscription
nameclient-idcm-handlexpathsubscribers
A10CH-1/p/c1[ A-10 ]


CH-1/p/c2[ A-10 ]
Client  Subscription
DMI Subscription
nameclient-idcm-handlexpathsubscribers
A10CH-1/p/c1[ A-10, B-35 ]
B52CH-1/p/c2[ A-10 ]
2CH-1, [ /p/c1, p/c2 ]CH-1, [ /p/c2, /p/c3 ]CH-1, [ /p/c3 ]
Client  Subscription
DMI Subscription
nameclient-idcm-handlexpathsubscribers
A10CH-1/p/c1[ A-10 ]

CH-1/p/c2[ A-10 ]
Client  Subscription
DMI Subscription
nameclient-idcm-handlexpathsubscribers
A10CH-1/p/c1[ A-10 ]
B52CH-1/p/c2[ A-10, B-35 ]

CH-1/p/c3[ B-35 ]
3CH-1, [ /p/c1]
CH-2, [ /p/c1]		CH-2, [ /p/c1]
CH-3, [ /p/c1]		CH-3, [ /p/c1]
Client  Subscription
DMI Subscription
nameclient-idcm-handlexpathsubscribers
A10CH-1/p/c1[ A-10 ]

CH-2/p/c1[ A-10 ]
Client  Subscription
DMI Subscription
nameclient-idcm-handlexpathsubscribers
A10CH-1/p/c1[ A-10 ]
B52CH-2/p/c1[ A-10, B-35 ]

CH-3/p/c1[ B-35 ]
4CH-1, [ /p/c1]CH-1, [ /p/c1/gc1 ]CH-1, [ /p/c1/gc1 ] (see issue #1)
Client  Subscription
DMI Subscription
nameclient-idcm-handlexpathsubscribers
A10CH-1/p/c1[ A-10 ]
Client  Subscription
DMI Subscription
nameclient-idcm-handlexpathsubscribers
A10CH-1/p/c1[ A-10 ]
B52CH-1/p/c1/gc1[ B-35 ]

Create 'Merge' Diagram

Below diagram shows and example for two subscriptions with party overlapping CM Handles and XPaths.

Subscription Merge Example

* Note: given the possible combinations the message to DMI needs to be able to specify different xpaths per cm-handle. So a more complex structure is needed for this even ie. an array of CM Handles objects each having their own list of (target) xpaths!

Delete Combinations

#NCMP Existing A-10NCMP Existing B-52Client Delete A-10 RequestDMI Delete RequestData Model Before BeforeData Model After Delete
1CH-1, [ /p/c1, p/c2 ]CH-1, [ /p/c1 ]CH-1, [ /p/c1, p/c2 ]CH-1, [ p/c2 ]
Client  Subscription
DMI Subscription
nameclient-idcm-handlexpathsubscribers
A10CH-1/p/c1[ A-10, B-52 ]
B52CH-1/p/c2[ A-10 ]
Client  Subscription
DMI Subscription
nameclient-idcm-handlexpathsubscribers
A10CH-1/p/c1[ A-10 ]

CH-1/p/c2[ A-10 ]
2CH-1, [ /p/c1]
CH-2, [ /p/c1]		CH-2, [ /p/c1]
CH-3, [ /p/c1]		CH-1, [ /p/c1]
CH-2, [ /p/c1]		CH-1, [ /p/c1]
Client  Subscription
DMI Subscription
nameclient-idcm-handlexpathsubscribers
A10CH-1/p/c1[ A-10 ]
B52CH-2/p/c1[ A-10, B-52]

CH-3/p/c1[ B-52 ]
Client  Subscription
DMI Subscription
nameclient-idcm-handlexpathsubscribers
B52CH-2/p/c1[ B-52 ]

CH-3/p/c1[ B-52 ]
3CH-1, [ /p/c1]

CH-1, [ /p/c1]
CH-2, [ /p/c1]		CH-1, [ /p/c1]None
Client  Subscription
DMI Subscription
nameclient-idcm-handlexpathsubscribers
A10CH-1/p/c1[ A-10 ]
B52CH-1/p/c2[ A-10, B-52 ]
Client  Subscription
DMI Subscription
nameclient-idcm-handlexpathsubscribers
B52CH-2/p/c1[ B-52 ]

Error-Upon-Error Combinations


Previous InteractionCurrent InteractionExpectationNotes
1any operation on rejected for non-existing cm-handleoperation for same non-existing cm-handlelisted in 'rejected' immediatelybehavior as normal
2create operation rejected by DMIcreate for same cm-handle/xpathtry again ?!
3create pendingcreate for same cm-handle/xpathTBD send again or just remain pending?!
4create pendingdelete for same cm-handle/xpath

5delete pendingdelete for same cm-handle/xpath
also being considered for 'basic' delete
6delete pendingcreate for same cm-handle/xpath
also being considered for 'basic' delete
7



Performance considerations

Below options (partly) explored dring CPS teem meeting could explore further once we know the characteristics, see issue #8 !

  • DMI record could reach in millions of instances
  • In memory solution (ie hazelcast) can handle 10s - 100s of Megabytes (add some sample calc)
    • still need persistence if we don't have enough intsances
  • use many small messages reduce need for amalgamation
  • amalgamated string-based solution.... 


Proposed JIRAs

PriorityComponent DescriptionJIRAEstimates
1



2



3



4



5



6



7



8



  • No labels