The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Feb> msg00373



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

draft-danenberg-sonet-ces-mpls-mib-00.txt

  • From: "Dave Danenberg" <dave_danenberg@litchfieldcomm.com>
  • Date: Tue, 27 Feb 2001 20:02:02 -0500
  • Cc: <mpls@UU.NET>
  • Thread-Index: AcChIg8psOPb4aQ7Q8elCetOVXk/9w==
  • Thread-Topic: draft-danenberg-sonet-ces-mpls-mib-00.txt
  • X-MIME-Autoconverted: from quoted-printable to 8bit by cell.onecall.net id UAA28312

Jim,

Thanx for your input. It sounds like you'd like to see the same sort of
statistical information from the emulated SONET that folks are
accustomed to seeing from SONET networking equipment. I like that too
(from years of developing telecomm equipment for service providers).

Although I was considering second order counts (errored seconds) or
trends (15 minute, 24 hour interval data), I decided to start with just
simple counts - and see what folks think.

Andy's CEM does not detect errors over the CEM payload, but it does
detect errors within the CEM header (the CEM MIB counts them with
mplsCemVcPerfCrctHdrErrors and mplsCemVcPerfUncrctHdrErrors). Perhaps
CEM header error rates can be extrapolated to indicate payload errors
rates. Due to the nature of CEM, other types of errors are detectable
(buffer errors, missing packets, etc). Assuming CEM equipment can
process this raw info into some nice statistics, another set of objects
can be added to the CEM MIB.

So, I'd like to include the type of statistical info you suggest as well
as your "reason for last down" idea. Would you like to see interval data
as well? 

What do you think Tom? If you agree, I can come up with another set of
objects and send it to Jim (and mpls email) for comment.

Dave


-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Jim Boyle
Sent: Tuesday, February 27, 2001 2:24 PM
To: Thomas D. Nadeau
Cc: mpls@UU.NET
Subject: Re: draft-danenberg-sonet-ces-mpls-mib-00.txt



pretend you are a service provider, a customer calls in and says he's
seeing errors on his service (in particular, bip violalations in POH). 

He is directly connected to your network via port A.
On the far end, he connects to a clec, which hands it off to you at port
Z.  He connects to a CLEC adm on port Z'.  His path terminating
equipment
(maybe a router) is port Ac, and Zc, such that the service looks like:

Ac-A-[IP]-Z-CLEC-Z'-Zc

Looking at lines Ac-A and Z-CLEC shows clean lines.

How does the operator determine if his IP network is to blame, or the
CLECs network is to blame?

i'd recomend a few things:

o) Andy's draft should have some sort of way to determine if there are
bit
errors hapenning across the IP network that affect the service
payload.  This would provide the same sort of delineation of where a
problem is occuring by looking at LOHs in more traditional transport
network.

o) your mib should include analogues to the SONET mib, such as bip-8
violations, errored seconds, etc... (working off memory here).

o) addition of a "reason for last down" might be nice.

This way, when you, as the service provider, replies that "it's not our
problem, must be the clec", they can say at least go look at it later to
see if they were telling the truth.

As usual, excellent attention paid to the configuration aspects.

regards,

Jim


On Fri, 23 Feb 2001, Thomas D. Nadeau wrote:

> 
> 	Hi,
> 
> 	FYI a new MIB for managing SONET/SDH Circuit Emulation
> Service Over MPLS has been posted. It should be available
> shortly via the IETF's web site. In the meantime, it is available
> at the following web/ftp link. As usual, comments are welcome.
> 
>
ftp://anonymous@ftp-eng.cisco.com/ftp/tnadeau/draft-danenberg-sonet-ces-
mpls-mib-00.txt
> 
> 	--Tom
>