The LNPA-WG's Slow Horse Subcommittee met July 10th and 11th for two
half-day sessions in Boston.

Participants

AT&T - Beth Watkins, H.L. Gowda
Bell Canada - Chris Martin
BellSouth - Wei Liu*, Ron Steen
Canadian LNP Consortium - Marian Hearn
Electric Lightwave - Dennis Robins*
Evolving Systems - Ron Stutheit
Neustar - Gene Johnston, Gustavo Hannecke
Qwest - Tommy Thompson*, Dave Garner
SBC - Charles Ryburn, Jim Atton
Sprint - Stephanie Swanson
TSE - Jean Anthony
Tekelec - Colleen Collard
Telcordia - John Malyar
Verizon - Bob Angevine, Gary Willett, Dave Marshall, Sharon Bridges
Williams Communications - Tim Bell
WorldCom - Alex Blackmore, Molly Dorsey, Steve Addicks

* participated by conference bridge

    Last Month's Minutes
Minutes from the June 13th meeting were approved as written.
   
Neustar M&P for LSMS Availability Reports
Several points were made during discussion of Neustar's second draft of
their LSMS Availability Report M&P.

*   agreed to names of reports be used in the M&P to avoid confusion

*   make clear that individual reports are prepared for each operator of
an LSMS connected NPAC

*   do not provide regional report until "appeal" percentage, if
applicable, also is available for every LSMS

*   show report schedule to reflect 28-day appeal interval

*   provide monthly report to each individual LSMS operator of its
results with four sections:

*   association log report - details

*   association log report - summary

*   LSMS % Availability (two figures: the % figure without adjustment
and the % figure adjusted to remove NPAC caused unavailability intervals)

*   display of actual calculation used to derive the two unavailability
percentage values

*   provide monthly regional report to LLCs

*   regional reports show three individual LSMS % Availability results
for each month

*   appeal % left blank if no change requested by LSMS operator

*   regional reports reflect results for past 18 months

*   regional reports show only the alias identities

*   regional reports are provided on request to any LSMS operator whose
results are shown on the report

*   regional report alias key is provided only to LLCs

Neustar agreed to revise their M&P to reflect today's discussion.  Sample
reports will be included in the revised M&P.

    LSMS Availability Reports - Next Steps

Need to amend Change Order 219 (Release 4) to lay out clearly the LSMS %
Availability reports.  At present, the change order specifies the detailed
association log report and the summary association log report, but is silent
on the individual and regional LSMS % Availability reports.  This change
will be done later this week in the LNPA-WG.  Neustar then will re-price
change order 219 and forward the new price information to the LLCs.  In the
interest of time, we are skipping the formal revised SOW request process
although appears likely to be necessary at some point.
Neustar Summary Report on NPAC Broadcast Rates - SOW 17

At June's meeting, Neustar presented summary of SOW 17 results.  (The full
SOW 17 respond could not be provided to the slow horse committee because of
Neustar's concern about the proprietary nature of the information.  We
agreed to defer decision on whether the summary would be of use in
developing an LSMS performance requirement until this month's meeting.
Today, there was consensus that the summary data is not helpful. 

However, the discussion returned to points made last fall, that the LSMS
could not be economically provided if the NPAC's broadcasts rates had no
upper bound.  Evolving Systems, supported by AT&T and Telcordia, proposed
use of flow control -- TN versus message aspect of flow control was set
aside for purposes of the discussion -- whereby NPAC broadcasts causing an
LSMS to become congested would not result in an LSMS association abort for
the LSMS's failure to respond within response timer value (currently 15
minutes for single TN broadcast, one hour for range broadcast).  This
approach would be used, however, only provided the LSMS were able to cope
with the NPAC's sustained broadcast rate (about 5 TNs/second).  (More on
this below.)

There appeared to be argument that peak value engineering not be used in the
LSMS design and that instead only a sustained broadcast rate capability be
required.  AT&T proposed change order to stop aborting.  There were also
again expressions about the need for stable NPAC broadcast rates.  The
discussion was inconclusive and the group agreed to resume the LSMS
performance requirement discussion at the next meeting.  John Malyar's
October write-up for an LSMS performance requirement will be the basis of
our discussion.  The text will be re-sent to the Slow Horse team shortly.

    SOA Performance

Neustar presented review of SOA-NPAC interactions today and discussed the
consolidation of range notifications to SOA in release 4.  The consolidated
notification -- one message, with list of all TNs -- applies only to SOAs
which are modified to accept the consolidated notifications for SVs creates
sent as ranges, however.  (note: a Create using a range does not require
that the subsequent activation also use a range.)

In response the subcommittee's questions in May, Neustar provided
description of their log data on NPAC-to-SOA messages.   The NPAC logs
provide record of all notifications so data sent to SOAs can be analyzed, to
document for example actual delays in NPAC responses to SOA.  Neustar
pointed out that even unrelated activity -- other SPs' activations and
resulting LSMS broadcasts, for example -- impact NPAC responses to SOA.
This impact is due to high priority assigned to activation work in current
NPAC requirements.  There was interest in getting a report on NPAC--to-SOA
messages, just as Neustar had provided data on NPAC broadcasts to LSMSs.

Items suggested to study were the quantity of notifications sent to each
SP's SOA, the concentration of SOA notification traffic, and the number of
times each SP's SOA goes into congestion.  However, we agreed to wait until
our August meeting to request such a report in order to adequately consider
what we wanted included in the report.

Neustar also provided a summary of its observations of SOA problems:

*   SOA stays down for long periods because provider not aware of SOA
outage; when SOA comes up, it goes into recovery for extended period and so
it cannot receive NPAC notifications for extended period.

*   Frequent SOA outages due to unstable connections result in frequent
resynchronization efforts to get missed SVs; this is apparently no longer a
problem, however.

*   SOA uses scope/filter query (bigger than/smaller than) instead of
direct query (equals) for information on a single TN.  The scope/filter
approach requires much more NPAC processing  (and more SOA processing) than
a direct query.  (NPAC is guilty of doing same scope/filter format, however,
when it queries service provider's systems.)

*   Some SOAs use queries to recover SVs instead of the more efficient
notification recovery process.

*   SOAs cannot handle NPAC notifications quickly enough; eventually the
SOA association is aborted with consequent need to go through recovery, etc.

*  Some providers are doing large range queries during heavy porting times.

Should association be dropped when NPAC's response timer expires?

There was suggestion by Evolving Systems, supported by AT&T and Telcordia,
that the NPAC no longer should abort the LSMS association upon expiration of
the NPAC's LSMS response timer.  WorldCom expressed concern that this
approach would mask an LSMS unavailability problem when caused by inability
of LSMS to keep up with NPAC.  That is, whether LSMS could not take
broadcast because it was busy or because it was off-line made little
difference from Business Need standpoint.  Furthermore, each SV would remain
in a "sending" state indefinitely, re-introducing the problem just solved
concerning the need to modify SVs in a partial failure state.  WorldCom
argued that the availability requirement then would have to be changed to
remain meaningful, to include extended congestion periods in excess of the
NPAC's normal response timer limits.  Eventually, there was consensus to
leave the availability requirement as it stood and to continue the current
NPAC practice of aborting an LSMS association after the NPAC's response
timer expires.
The same change was proposed for SOA response timer expiration.  Since SOA
unavailability does not directly impact call processing, there appears to be
less controversy around eliminating abort on failure to respond before
response timer's expiration.  This will be discussed further when SOA
requirements work resumes in September.
    Report to NANC
"Clarified the LSMS % Availability Report (individual SP and regional) requirements."

Next Meeting

The next slow horse meeting will be held at Baltimore, immediately prior to
the LNPA-WG meeting.  There will be two half-day sessions: August 14th from
1 to 5 PM and August 15th from 8:30 to noon.  The August meeting will focus
on (1.) the LSMS performance requirement and (2.) identification of
components for a one-time manual report by Neustar based on their logs of
NPAC-to-SOA traffic.  The current expectation is to complete the LSMS
performance requirements in the August and September meetings and then to
resume work on the SOA performance and availability requirements in
September.