NANC 419

User Prioritization of Recovery-Related Notifications

Origination Date :03/15/2007

Originator:AT&T

Description:

The existing NPAC Notification Priority process only allows a certain type of notification to have a different priority from another type.  Using this method, however, SOAs cannot distinguish between the reasons for a certain type of notification.  For example, a Status Attribute Value Change notification could indicate that all LSMSs successfully responded and a pending SV is moving to active, or it could indicate that a discrepant LSMS has just completed recovery and a partial-failure SV is moving to active.

As a result, an SP that is recovering SVs could cause the activating SOA to experience unintended delays in receiving notifications for different activities because the recovery process generates its own set of notifications.  This unintended delay could happen hours after the initial activity, when the SOA is otherwise relatively lightly loaded, causing confusion to the SOA users.

Proposed Resolution:

Add a new scenario to the list of notification priorities (42 listed in the FRS, Appendix C).  The new one will be specific to notifications generated as a result of recovery requests (not to be confused with notification recovery).  This will allow notifications generated where the reason is recovery to have a lower priority than the same notification generated where the reason is a SOA GUI user working real-time with a customer request.

In the example above, notification L-11.0 A1 would have a lower priority in a recovery-related SV activate scenario where one LSMS failed the initial SV activate download, but successfully recovered that SV activate download at a later time, whereas a different instance of notification L-11.0 A1 would have a higher priority in a regular SV activate scenario where all LSMSs successfully processed the SV activate download.

Jun ’07 LNPAWG con call:

The change order was accepted by the LNPAWG during the call.  Detailed requirements will begin to be developed.

Jul ’07 LNPAWG meeting:

Upon further discussion, it was agreed that instead of just one new notification that would be generated as a result of a recovery request, the type of activity (activate, modify, disconnect) should also be accounted for in the proposed solution.  The group will discuss the complexity of different types of activity, and whether this is needed and/or confusing to manage.  With this new ability to “change the order”, the issue of out-of-sequence notifications needs to be discussed as well.

Sep ’07 LNPAWG meeting:

All participants were not available to discuss this at this time.  Discussion will carry forward into the Nov ’07 meeting.

Nov ’07 LNPAWG meeting:

After a brief discussion, it was agreed that no solid business case could be identified for keeping this at the “type of activity” level, so instead of one each for activate, modify, and disconnect, just a single recovery notification will be used for all three types.

Final Resolution:

Related Release:

TBD

Status: Open