Subject: RE: Some Suggestions about the RFC 2558

From: "Khosravi, Farzad" <[email-masked]>
Date: Mon, 18 Feb 2002 08:03:13 -0500

Mike,

Thank you for your answers. These issues were not intended to have some
explonation about the primitives. 

 1 ) I totally agree on the fact that eb = CV. The question is the
conformance with the SDH Standards (labels).

 2 ) By UAS management, i meant the UAS State. The management shall inform
the user that a SONET / SDH 
     line is in the UAS state (not only by incrementing the appropriated
counters). It could be reported, potentially, 
	in a failure state (because the system is unavailable during the
UAS).

 3 ) The newly SES thresholds Standards:
	G.828 : Error Performance parameters and objectives for
international, constant bit rate synchrnous digital paths.
	G.829	: Error Performance Events for SDH multiplex and regenerator
sections.

 4 ) In order to compensate theses lacks, we decided to implement an
extended MIB for each of the standard ones.   	

Thanks ...

-----Original Message-----
From: C. M. Heard [mailto:[email-masked]]
Sent: Friday, February 15, 2002 11:34 PM
To: [email-masked]
Cc: Kaj Tesink; Khosravi, Farzad; Savignac, Sylvain
Subject: Re: Some Suggestions about the RFC 2558

On Fri, 15 Feb 2002, Kaj Tesink wrote:
> Farzad, I forward your comments to the discussionlist of the atommib wg
> which is the appropriate forum to discuss these issues.
> 
[ ... ]
> 
> 1 - All the SDH performance Monitoring parameters are missing, and these
> parameters are required by
> SDH standards. among them, there are :
> 
>          -be

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.

> 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.

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
> defined.

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