Subject: failure versus defect

From: "William 'Bill' Boxer" <[email-masked]>
Date: Fri, 15 Dec 2000 10:25:31 -0800

In RFC-2558 section 3.5 about six pages are written on the definitions
of failures.  A failure being the detection of a defect for a certain
period of time.  These definitions are in agreement with Telcordia
GR-253-CORE specification.  However, when it comes to the definition of
the actual MIB variables (for the various SONET layers of
CurrentStatus), the variables are referenced in terms of "defects."

This creates a great deal of ambiguity as to what the specification is
really intending.  If the MIB variables for CurrentStatus are intended
to report the immediate condition of a SONET line (i.e. a "defect") then
why bother having section 3.5 in the specification?   The idea of
"failures" is to prevent the operator from having transitory defects
reported.  Therefore if the specifications RFC-2558 is intending
failures to be reported (rather than defects) it would seem that the
means to do this would be the MIB variables defined by the very same
specification.

    WLB

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 16 Dec 2000 02:14:44 -0800 (PST)

WLB --

You are correct, the failure definitions in Section 3.5 of RFC 2558
are not used to in the subsequent managed object definitions.  Only
the defect definitions in that section are subsequently used.

While I am inclined to agree that the status objects in the MIB that
maintain the current values of various the defects are not especially
useful, notice that adding status objects to maintain SONET failures
would still not satisfy all of the requirements in GR-253.  One would
need in addition failure notifications plus logic to ensure that only
the root cause problem results in a notification.  The latter is much
valued by network operators but it is a great deal of work to implement.

Regards,

cmh

P.S.  The definition of the line AIS failure in Section 3.5 states
that the failure begins after an AIS-L defect has been present for
20.5 +/- 0.5 seconds.  That's a typo;  it should say 2.5 +/- 0.5
seconds.  It was present in RFC 1595 also.  Kaj, please add it to
the list of fixes to be made when 2558 is considered for advancement.