Subject: RFC 1595 - SES definition

From: Kaj Tesink <[email-masked]>
Date: Mon, 09 Nov 1998 14:46:53 +0000

Gil,

At 09:00 AM 11/9/98 +0200, [email-masked] wrote:
>Dear Sir,
>
>My name is Gil Bialik , I'm a system engineer at ECI-Telecom Israel.
>First ,I would like to thank you for your previous answers to my
>"MIB-related" questions, which we found to
>be very helpful.
>
>Our development team is currently implementing RFC 1595. While doing so we
>encountered the following
>problem :
>OC3 Severely Errored Second (SES) in the SONET/SDH section is defined in
>RFC 1595 as a second containing 16 or more section code violations
>(paragraph 3.6) or more than one SEF , or more than one LOF defects.
>ANSI T1.231 definition is : 2500 code violations (Table 14)  , or more than
>one SEF or more than one LOF defects.
>What is the reason for the difference in the code violations (CVs) count ,
>and what would you recommend us to
> implement in our system?
>
>I will be very grateful for your response ,

I'm not in a place where I can check these issues right now. I copy
this to the [email-masked] discussion list which is the
proper forum for these discussions. To subscribe see

http://www.ietf.org/html.charters/atommib-charter.html

Note also that a successor of RFC1595 is in the final stage of completion.

Anybody on the list who can help Gil? Pl copy him directly as well
as I dont know whether he is subscribed.

Hope this helps,

Kaj

>Sincerely yours ,
>Gil Bialik.

---

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Mon, 9 Nov 1998 09:27:05 -0800 (PST)

> >and what would you recommend us to

The reason for the difference is that the standards themselves have
changed since RFC1595 was published, and the replacement RFC has 
not yet been released.  But it soon will be.

In the meantime, I would advise you to download
draft-ietf-atommib-sonetng-04.txt from your nearest internet
draft repository and implement the version of the SONET-MIB
embodied in that draft.  It contains the object definition

          sonetSESthresholdSet    OBJECT-TYPE
              SYNTAX   INTEGER {
                         other(1),
                         bellcore1991(2),
                         ansi1993(3),
                         itu1995(4),
                         ansi1997(5)
                                }
              MAX-ACCESS      read-write
              STATUS          current
              DESCRIPTION
                "An enumerated integer indicating which
                 recognized set of SES thresholds that
                 the agent uses for determining severely
                 errored seconds and unavailable time.

                 other(1)
                   None of the following.

                 bellcore1991(2)
                   Bellcore TR-NWT-000253, 1991 [32], or
                   ANSI T1M1.3/93-005R2, 1993 [22].
                   See also Appendix B.

                 ansi1993(3)
                   ANSI T1.231, 1993 [31], or
                   Bellcore GR-253-CORE, Issue 2, 1995 [34]

                 itu1995(4)
                   ITU Recommendation G.826, 1995 [33]

                 ansi1997(5)
                   ANSI T1.231, 1997 [35]

                 If a manager changes the value of this
                 object then the SES statistics collected
                 prior to this change must be invalidated."
               ::= { sonetMedium 2 }

which was put in specifically to address the concern that you raise.
There are some additional enhancements which you will find useful,
such as some xyzValidData flags which are the logical complements of
the invalid  data flags required by clause 9 of T1.231.

The SONET-MIB has just recently undergone a quality review and there will
be some changes as a result, but will be mostly of an editorial nature and
will not affect your agent implementation, so it's probably OK to start
with the -04 draft.  But be sure to pick up the -05 draft as soon as it
hits the streets, and of course make sure that you refer to the new
RFC (when it is published) instead of the drafts.

Regards,

Mike
--
C. M. Heard/VVNET, Inc.
[email-masked]