Subject: RE: question regarding RFC2558

From: Ray Reno <[email-masked]>
Date: Wed, 8 Nov 2000 08:26:05 -0500

Thanks for the response.

I don't really have any problem with the xxxCurrentStatus objects reflecting
defects as opposed to failures (I do have the ability to retrieve these
directly from my hardware when needed).

I think that my problem was that I had myself made a direct association
between the ifOperStatus and the internal state of the interface in our
system (i.e., I was equating a change in ifOperStatus to be synonymous with
internally reporting a state change of the interface).  In our system, it
probably wouldn't work well to have the internal state of the interface
change potentially multiple times per second.

So, I believe that my resolution is that I break the association that I had
made between the internal state of the interface and ifOperStatus (leaving
ifOperStatus to freely track the defects reported in xxxCurrentStatus).  I
can then integrate the defects into failures for the purpose of internal
state changes.  Does this sound like an appropriate approach?

Thanks,
-Ray

-----Original Message-----
From: C. M. Heard [mailto:[email-masked]]
Sent: Tuesday, November 07, 2000 2:35 PM
To: [email-masked]
Cc: Ray Reno
Subject: Re: question regarding RFC2558

On Tue, 31 Oct 2000, Ray Reno wrote:
>
>I am an engineer currently writing a driver for a SONET/SDH interface and
>I am implementing RFC2558 as a part of that.
>
>I was hoping that you could answer a quick question for me regarding the
>'sonetXXXXXXXCurrentStatus' objects (sonetSectionCurrentStatus,
>sonetPathCurrentStatus, etc.).  Are these status fields intended to
>represent pure defects (which can change in a fraction of a second), or on
>an integrated defect (for instance, a failure as defined by ANSI
>T1.231-1997 which would change only over the course of multiple
>seconds)?  The reason I ask is that RFC2558 makes a clear correlation
>between the state of the 'sonetXXXXXXXCurrentStatus' fields and the
>ifOperStatus objects of the ifTable.
>
>So, is the associated ifOperStatus supposed to be allowed to (in a worst
>case scenario) change multiple times per second, or am I misinterpreting
>the definition of the current status objects as being pure defects when
>they really are integrated defects?

On Tue, 31 Oct 2000, Kaj Tesink replied:
>
> the preamble of the mib definition makes a terminology distinction between
> defects and failures (see e.g., LOS, LOF definitions), and the mib objects
> are defined in terms of defects. so in the terminology you use above i'd
> conclude that the objects reflect defects and not integrated defects.

I agree with this interpretation:  when polled, the xxxCurrentStatus objects
should return some approximation of the current value of each defect.

This is usually not too hard to do if the agent resides on the same machine
as the line interface devices.  In that case the device driver can provide
a call that the agent can use to retrieve the current defect values from
hardware registers or from variables that are updated by an interrupt
service routine (or even by periodic polling).

The job becomes more difficult if, as is the case in a typical SONET NE,
the agent lives on one card, e.g., a shelf controller but the line
interface devices reside elsewhere, e.g., on a line card.  In the case
the agent faces some difficult choices.  One would be to poll the line
card to get the most current status.  Another would be to use a "cached"
value obtained by periodically polling the line card.  The latter will
often cause sounds of dismay but from a practical perspective it does not
make much dufference -- after all, the value may be stale anyway one it
gets to the NMS, thanks to polling delays.

In retrospect it probably would have been better to have made these objects
report failure conditions instead of defects.  The currently standardized
SNMP stuff in RFC2558 and in RFC2863 does not cover SONET failures, which
are very important to many network operators.

Mike

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 8 Nov 2000 11:09:57 -0800 (PST)

> change potentially multiple times per second.

There are very few systems on which that would work well :)

> state changes.  Does this sound like an appropriate approach?

Yes, it does.  One other point -- if you have ifLinkUpDownTrapEnable set
to enabled(1) then you will want to make sure that you control the rate
at which linkUp and linkDown traps get generated.   On page 14 RFC 2558
suggests using the entry into and exit from available time as triggers
for these traps:

        In any case, a linkDown trap shall be sent only after the agent
        has determined for certain that the unavailable state has been
        entered, but the time on the trap will be that of the first UAS
        (i.e., 10 seconds earlier).  A linkUp trap shall be handled
        similarly.

Mike