Subject: sonetPathCurrentStatus from SONET-MIB

From: Subrahmanya Hegde <[email-masked]>
Date: Sun, 15 Feb 2004 13:00:08 -0800

Hi
[ I think answer for this NO-NO; sending this question to see any 
alternate solution exists]

 sonetPathCurrentStatus is defined upto range 0..62.

Is there anyway we can represent the UpperLayer alarms in these objects?
[sonetPathCurrentStatus, sonetLinceCurrentStatus]

For example: A sonet interface can have multiple paths
Each path can have ATM Cell Layer interface.
The ATM Cell Layer interface can be in Alarm[LOCD for example]

Is there anyway to represent 'sonetPathCurrentStatus' such that [I know 
its needs addition
of ranges, description etc] it contains ATM Cell Layer info. at the Path 
level?

Thanks
Subra

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 18 Feb 2004 08:30:00 -0800 (PST)

On Sun, 15 Feb 2004, Subrahmanya Hegde wrote:
> Is there anyway we can represent the UpperLayer alarms in these
> objects? [sonetPathCurrentStatus, sonetLinceCurrentStatus]
> 
> Is there anyway to represent 'sonetPathCurrentStatus' such that
> [I know its needs addition of ranges, description etc] it
> contains ATM Cell Layer info. at the Path level?

Short answer:  (a) such a modification violates SMIv2 revision
rules;  (b) ATM-MIB's atmInterfaceTCAlarmState already provides
the functionality that you want.

Here is a longer answer.

From the point of view of strict application of the SMIv2 rules on
revisions of object definitions (see RFC 2578 Section 10), it is not
legal to change the range of a subranged Integer32.  We sometimes do
it but it is generally done only to fix obvious bugs (e.g., the
specified range does not match the DESCRIPTION clause), or in cases
where no range was specified but one was enforced implicitly (e.g.,
index objects can't be negative).  We did make such a change to
sonetPathCurrentStatus in the transition from RFC 1595 to RFC 2558,
but I don't think that the "bugfix" exemption applies here, since
what is being requested is additional functionality.  It would have
been better if the various sonetXyzStatus objects had been defined
with a syntax of BITS, since one is allowed to add named bits to
such an object.  However, the sonetXyzStatus objects predate the
BITS construct, and standards-track MIB modules were not allowed to
use the then-legal but now-obsoleted BIT STRING type.

From the point of view of clean separation of function, it is
generally preferred NOT to represent higher-layer defects in
lower-layer objects, mainly because the lower layers don't know
what is happening at the higher layers -- they just carry the
bytes transparently and don't process the content.  The proper
place to look for higher-layer defects is in the higher layer
objects themselves.  Thus, sonetSectionCurrentStatus,
sonetLineCurrentStatus, and sonetPathCurrentStatus provide
defect indications at their respective layers only.  Defect status
for things above the path layer can be found in sonetVTCurrentStatus
when the payload is a VT, or in atmInterfaceTCAlarmState (see
atmInterfaceTCTable in RFC 2515's ATM-MIB) when the payload is
an ATM cell stream.

Mike Heard

---

From: Subrahmanya Hegde <[email-masked]>
Date: Wed, 18 Feb 2004 08:38:43 -0800

Mike
  Thanks for the detailed explanation. I agree with you

Subra