Subject: [ifmib] RFC 2495 - Managed Objects ... DS1 Question on Unavailable Seconds (fwd)

From: "C. M. Heard" <[email-masked]>
Date: Tue, 25 Sep 2001 09:19:01 -0700 (PDT)

Andrew,

I'm forwarding this message to the AToMMIB list since that's where
the trunk MIBs are currently being discussed (they are actually up
for advancement, and implementation reports are being sought).

//cmh

---------- Forwarded message ----------
Date: Mon, 24 Sep 2001 14:49:49 +1000
From: Andrew Worsley <[email-masked]>
To: [email-masked]
Subject: [ifmib] RFC 2495 -  Managed Objects ... DS1 Question on Unavailable
    Seconds

  Hi, I hope this is the most appropriate mailing list for this type of
  question. A question has come up about the exact interpretation of UAS
  (Unavailable Seconds) as defined in RFC 2495 - "Definitions of Managed
  Objects for the DS1, E1, DS2 and E2 Interface Types". 

  Basically if a failure state persists for less than 10 seconds but you have
  only a smaller period of SES (Severly Errored Seconds) the definition
  implies that the interface becomes available when the SES cease *even*
  though the fault might be still present at this time. This appears to be
  inconsistant with the requirement that UAS start as soon as a fault
  appears.

  I can quote more details if people would like, including an example. I will
  restrict myself to just reproducing the paragraph that holds the apparent
  contradiction.

     Thanks for any help people can provide

     	Andrew Worsley

    "Unavailable Seconds (UAS)
        Unavailable Seconds (UAS) are calculated by counting the number
        of seconds that the interface is unavailable.  The DS1 interface
        is said to be unavailable from the onset of 10 contiguous SESs,
        or the onset of the condition leading to a failure (see Failure
        States).  If the condition leading to the failure was
        immediately preceded by one or more contiguous SESs, then the
        DS1 interface unavailability starts from the onset of these
        SESs.  Once unavailable, and if no failure is present, the DS1
        interface becomes available at the onset of 10 contiguous
        seconds with no SESs.  Once unavailable, and if a failure is
        present, the DS1 interface becomes available at the onset of 10
        contiguous seconds with no SESs, if the failure clearing time is
        less than or equal to 10 seconds.  If the failure clearing time
        is more than 10 seconds, the DS1 interface becomes available at
        the onset of 10 contiguous seconds with no SESs, or the onset
        period leading to the successful clearing condition, whichever
        occurs later.  With respect to the DS1 error counts, all
        counters are incremented while the DS1 interface is deemed
        available.  While the interface is deemed unavailable, the only
        count that is incremented is UASs. "

_______________________________________________
ifmib mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/ifmib

---

From: "Paul Obeda" <[email-masked]>
Date: Tue, 25 Sep 2001 14:47:04 -0400

Greetings,

I think the description in RFC2495 may be misinterpreted
(at least, I believe it's not what was actually intended)
as shortening the 10 second interval for declaring UAS.
Rather, I believe the intention is to explicitly include
time prior to a failure within the pegged UAS time should
a UAS condition be declared (e.g. if a failure takes 15
seconds to declare from the onset of symptoms, and that
failure leads to a UAS declaration, then include the time
from the actual start of the failure in the UAS time, even
though this is longer than the 10 SESs).

If there is some short burst of Severely Errored Seconds (less
than 10 contiguous seconds of SES conditions), including some
transient failure condition, it gets pegged as SESs.

If the error condition persists such that there are 10 contiguous
seconds of an SES condition, it gets pegged instead* as a UAS
condition, and continues to be pegged as a UAS condition until
the onset of 10 contiguous seconds without an SES condition
(with the caveat that if the failure clearing time is longer
than 10 seconds, we may have to make further adjustments).

  * This may require some adjustments to the SES and UAS
    counts for the current and (possibly) previous intervals.

Of course, if I've misstated this then manyfolks will jump
to correct me.

Regards,

Paul

-----Original Message-----
From: C. M. Heard [mailto:[email-masked]]
Sent: Tuesday, September 25, 2001 12:19 PM
To: [email-masked]
Cc: Andrew Worsley
Subject: [ifmib] RFC 2495 - Managed Objects ... DS1 Question on
Unavailable Seconds (fwd)

Andrew,

//cmh

---------- Forwarded message ----------
Date: Mon, 24 Sep 2001 14:49:49 +1000
From: Andrew Worsley <[email-masked]>
To: [email-masked]
Subject: [ifmib] RFC 2495 -  Managed Objects ... DS1 Question on Unavailable
    Seconds

  Basically if a failure state persists for less than 10 seconds but you
have

  I can quote more details if people would like, including an example. I
will
  restrict myself to just reproducing the paragraph that holds the apparent
  contradiction.

     	Andrew Worsley