Subject: Re: RFC 2558 ( sonet mib ) question

From: "William 'Bill' Boxer" <[email-masked]>
Date: Wed, 07 Nov 2001 09:12:03 -0800

I also asked a similar question in December.  It's an area in the MIB that
certainly could be clarified.  Below your question I have cut and pasted the
response I received from C.M. Heard in December and my original question below
it...
__________________________

Unknown wrote:

> Do the values in the pathCurrentStatus variable indicate defects or
> failures?
>
> For example, there's a bit in that variable that represents sonetPathSTSAIS,
> set when there's a path AIS condition on the interface.
>
> According to the mib, an AIS defect is detected when H1 and H2 are set to
> all 1s for three contiguous frames, and cleared under one of two conditions:
>
> 1) STS Pointer set to inverted for 1 frame
>
> or
>
> 2) pointer set to normal for 3 contiguous frames.
>
> An AIS failure is declared when an AIS defect persists for 2.5 +/- 0.5
> seconds and is cleared when the defect is absent for 10 +/- 0.5 seconds.
>
> Does the sonetPathSTSAIS bit represent the state of the AIS defect or the
> AIS failure?
>
> I have analogous questions for the other status bits at the other levels of
> the sonet mib ( low_level, vt ) and for other physical layer mibs ( ds1,
> ds3)
>
> Kevin Nolish
> <mailto:[email-masked]>
>

________________________________________________________
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.

----------------
On Fri, 15 Dec 2000, William 'Bill' Boxer wrote:

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