Subject: Some Suggestions about the RFC 2558

From: Kaj Tesink <[email-masked]>
Date: Fri, 15 Feb 2002 10:45:13 -0500

Farzad, I forward your comments to the discussionlist of the atommib wg
which is the appropriate forum to discuss these issues. See
http://www.ietf.org/html.charters/atommib-charter.html
for subscription info.

Note that 2558 is being evaluated right now and implementation experience is
being requested. Please send your implementation report to
Faye Ly <[email-masked]>
Use the compliance clause as guidance.

Some of your comments have come up before; it has been suggested to
create a "supplemental" mib module to deal with some missing functions.

Kaj

=========================================================================

Hi,

The subject of this email is that i really think that the RFC2558 shall be
revised.
I do not undrestand why it is called a SONET/SDH MIB while this MIB is 100%
SONET
oriented.

1 - All the SDH performance Monitoring parameters are missing, and these
parameters are required by
SDH standards. among them, there are :

         -be
         -bbe

2 - The path trace related configuration objects are missing:

3 - There is noway to configure the Enhanced Path RDI, while again, the
SONET Standards specifies that the
use of the Enhanced RDI "is preferred".

4 - The RFC 2558 reflects only the current defects of the SONET/SDH Signal
Hierarchy and not the failures, and
as you probably know, the management of the failure states is a requiremebnt
in both SONET/SDH standards. Even
if the failure management is missing, some of the defects which are required
by standards are also missing. Among
them, there is :

         - Path  Trace Identifier Mismatch
         - Enhanced RDI Connectivity.
         - Enhanced RDI Payload.
         - Enhanced RDI Server.

5 - The UAS management is missing.

6 - Some SES Thresholds are totaly obselete, and some others are newly
defined.

Please do not hesitate to contact me for any suggestions.

Regards

Farzad Khosravi

Kontron Canada
[email-masked]

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Kaj Tesink
Telcordia Technologies. In.
331 Newman Springs Road
Red Bank, NJ 07701
Email: kaj @research.telcordia.com
Tel: (732) 758-5254
Fax: (732) 758-4177

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

---

From: "C. M. Heard" <[email-masked]>
Date: Fri, 15 Feb 2002 20:33:30 -0800 (PST)

On Fri, 15 Feb 2002, Kaj Tesink wrote:
> which is the appropriate forum to discuss these issues.
> 
[ ... ]
> SDH standards. among them, there are :

Aka block error.  This is called EB ("errored block) in TABLE A.3/G.784.
If my understanding of what is said in G.784 is correct, this is a
performance primitive, not a performance parameter, and is not
intended to be reported directly.

>          -bbe

Aka background block error.  This is a count of EB primitives not
occurring during severely errored seconds.  It is closely analogous
to a SONET CV (coding violation).  The difference is that in SDH
errored BIP-N blocks are counted, while in SONET each parity error
is counted separately (except at the path layer, where T1.231 allows
either option).  At low error rates these will be approximately equal.

Would it be reasonable to change the text in Section 4.5 to state
that CVs are interpreted as BIP errors if sonetMediumType is set to
sonet(1) and as block errors if sonetMediumType is sdh(2)?  (There
is some suggestion that this was intended in the text of that
section that deals with SES thresholds.)

> 2 - The path trace related configuration objects are missing:

Lots of configuration options are missing;  this is one of many.
At present, they reside in vendor-specific MIBs.  If there is
sufficient interest, a supplemental MIB for configuration could
be standardized.

> SONET Standards specifies that the use of the Enhanced RDI "is preferred".
>
> Hierarchy and not the failures, and as you probably know, the management
> of the failure states is a requiremebnt in both SONET/SDH standards. Even
> by standards are also missing. Among them, there is :
> 

True.  Again, this is (for now) left to vendor-specific MIBs, and could be
standardized in a supplemental MIB (if there is sufficient interest).  The
issue of near- and far-end ERDI defects arose also for the 10G Ethernet
WIS, and the approach we took there was to define supplemental objects. See

http://www.ietf.org/internet-drafts/draft-ietf-hubmib-wis-mib-01.txt

for how the problem was addressed there.  My suggestion is that a
supplemental MIB, if one is undertaken, should probably contain MIB
objects and notifications to address SONET and SDH failures.  In most
environments these would be a lot more interesting than defects.  We
have defects objects in the WIS MIB because that was what the IEEE put
in P802.3ae Annex 30 for the WIS.

> 5 - The UAS management is missing.

Are you referring to something other than the following objects?

sonetLineCurrentUASs, sonetLineIntervalUASs, sonetFarEndLineCurrentUASs,
sonetFarEndLineIntervalUASs, sonetPathCurrentUASs, sonetPathCurrentUASs,
sonetFarEndPathCurrentUAS, sonetFarEndPathIntervalUASs, sonetVTCurrentUASs,
sonetVTIntervalUASs, sonetVTIntervalUASs, sonetVTIntervalUASs

> 6 - Some SES Thresholds are totaly obselete, and some others are newly

The obsolete ones are there deliberately, to support old implementations.
What new ones are missing?

> Please do not hesitate to contact me for any suggestions.

Thanks for bringing up these issues.

> Farzad Khosravi

Mike Heard