Subject: Re: RFC2558 updates

From: Subrahmanya Hegde <[email-masked]>
Date: Tue, 04 Dec 2001 11:37:55 -0800

Kaj
  We have not found about SD(Signal Degrade) and SF(Signal Failure)
conditions in any objects in the MIB.

Information about SD and SF are found in Sept 2001 version of GR-253

We request that  sonetLineCurrentStatus object is extended to include SD
and SF information.

Definition in the MIB

 sonetLineCurrentStatus OBJECT-TYPE
              SYNTAX  Integer32 (1..6)
              MAX-ACCESS  read-only
              STATUS  current
              DESCRIPTION
                 "This variable indicates the
                 status of the interface.
                 The sonetLineCurrentStatus
                 is a bit map represented
                 as a sum, therefore,
                 it can represent multiple defects
                 simultaneously.
                 The sonetLineNoDefect should be
                 set if and only if
                 no other flag is set.

                 The various bit positions are:
                  1   sonetLineNoDefect
                  2   sonetLineAIS
                  4   sonetLineRDI"
               ::= { sonetLineCurrentEntry 1 }

Requested Update:

 sonetLineCurrentStatus OBJECT-TYPE
              SYNTAX  Integer32 (1..30)
              MAX-ACCESS  read-only
              STATUS  current
              DESCRIPTION
                 "This variable indicates the
                 status of the interface.
                 The sonetLineCurrentStatus
                 is a bit map represented
                 as a sum, therefore,
                 it can represent multiple defects
                 simultaneously.
                 The sonetLineNoDefect should be
                 set if and only if
                 no other flag is set.

                 The various bit positions are:
                  1   sonetLineNoDefect
                  2   sonetLineAIS
                  4   sonetLineRDI
                  8   sonetLineSD
                  16 sonetLineSF"
               ::= { sonetLineCurrentEntry 1 }

It will be great, if we can add it in Updated RFC2558.

Let me know whether it can be added.

Thanks
Subra

Kaj Tesink wrote:

> I-D Archive - Please post attached revision of RFC2558 as
> draft-ietf-atommib-sonetng-00.txt
>
> AToMMIB WG - For your consideration at next meeting
> a)  moving RFC2558 from Proposed to Draft
> b)  compatibility with the Etherwis mib
>
> Changes relative to RFC2558 are very minor and limited
> to those that have been posted several times on the list
> plus boilerplate updates.
>
> Thanks much to Mike Heard who kindly provided a sanity check
> on changes, correctness and etherwis mib consistency.
>
> Kaj
>
>   ------------------------------------------------------------------------
>
>    sonetng.txtName: sonetng.txt
>               Type: Plain Text (text/plain)

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 4 Dec 2001 13:29:12 -0800 (PST)

> Information about SD and SF are found in Sept 2001 version of GR-253

I don't have that version of GR-253 in front of me, but my recollection
is as follows:

SD = Estimated Bit Error Ratio > Signal Degrade Threshold (10^-5 to 10^-9)

SF = Estimated Bit Error Ratio > SIgnal Fail Threshold (10^-3 to 10^-5)
      OR
     Near-End Section or Line Layer Defect (LOS, LOF, AIS-L)

Error rates are determined by observing BIP-L in the B2 overhead byte,
and occur over some observation time determined by the implementation.

> We request that  sonetLineCurrentStatus object is extended to include SD

SD and SF are not really defects, they are derived conditions used
specifically to control linear APS.  The SONET APS-MIB, which recently
passed WG last call and awaits IESG action, has objects to set the
SD and SF thresholds and to monitor the number of SD and SF occurrences
(see draft-ietf-atommib-sonetaps-mib-05.txt).  So I don't really think
SD and SF belong in sonetLineCurrentStatus.

>  sonetLineCurrentStatus OBJECT-TYPE
[snip]
>  sonetLineCurrentStatus OBJECT-TYPE
[snip]
>                ::= { sonetLineCurrentEntry 1 }

Questions aside of whether SD and SF really belong in this
object, this is not one of the revisions permitted by RFC
2578 Section 10.2.  (It would have been better for these
objects to have used the BITS syntax so that they could
have been extensible, but their original definitions in
RFC 1595 pre-dated that device.)

Why don't you have a look at the APS-MIB

http://www.ietf.org/internet-drafts/draft-ietf-atommib-sonetaps-mib-05.txt

and see if the objects therein will do what you want?

Regards,

Mike

---

From: Subrahmanya Hegde <[email-masked]>
Date: Tue, 04 Dec 2001 15:23:26 -0800

Hi Heard
  Thanks for your comments.

 As per our Engineers here, SD and SF are related to
line level. It is also applicable in APS Space.

Can you review section 6.2.1.1.6.E of GR-253 and let us know whether
you still think that SD and SF need not be in 'SONET-MIB"?

Subra

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 4 Dec 2001 18:20:07 -0800 (PST)

> you still think that SD and SF need not be in 'SONET-MIB"?

The version of GR-253 that I have treats APS troubles in 6.2.1.1.6.A
through 6.2.1.1.6.E;  none of them pertain to SD or SF.  If you will
cite the relevant requirement numbers (the ones in _square brackets_,
not the R-XXX stuff) then I can be sure I have the right place, since
those numbers don't change from one edition of GR-253 to the next.

In any case, there are already objects in the APS-MIB to monitor
SD and SF.  Why do they also need to be in the SONET-MIB?

Mike

---

From: Subrahmanya Hegde <[email-masked]>
Date: Tue, 04 Dec 2001 18:23:53 -0800

> SD and SF.  Why do they also need to be in the SONET-MIB?

If SD and SF are applicable to SONET Line without APS configuration,
then it will be helpful to be in SONET MIB

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 5 Dec 2001 14:40:51 -0800 (PST)

> > On Tue, 4 Dec 2001, Subrahmanya Hegde wrote:
[ ... ]
> then it will be helpful to be in SONET MIB

This morning I was able to review section 6.2.1.1.6.E of GR-253-CORE Issue
2, Revision 2 (January 1999).  The SF- and SD-related requirements in that
section -- [1064], [1065], [1066], and [1067] -- apply specifically to
BER-based SF and SF conditions "that are used for protection switching
purposes."  Thus, they do not apply to systems without APS.

Regards,

Mike