and again .....

Tracy Cox <tacox@sabre.bellcore.com> Thu, 20 February 1992 14:39 UTC

Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa22319; 20 Feb 92 9:39 EST
Received: from FENNEL.ACC.COM by NRI.NRI.Reston.VA.US id aa22311; 20 Feb 92 9:39 EST
Received: from sabre.bellcore.com by fennel.acc.com (4.1/SMI-4.1) id AA12113; Thu, 20 Feb 92 06:34:27 PST
Received: by sabre.bellcore.com (5.57/Ultrix2.4-C) id AA08829; Thu, 20 Feb 92 09:34:55 EST
Return-Path: <tacox@sabre.bellcore.com>
Received: by ginsu4 (4.1/4.7) id AA00520; Thu, 20 Feb 92 09:33:26 EST
Date: Thu, 20 Feb 1992 09:33:26 -0500
From: Tracy Cox <tacox@sabre.bellcore.com>
X-Station-Sent-From: ginsu4.bellcore.com
Message-Id: <9202201433.AA00520@ginsu4>
To: trunk-mib@acc.com
Subject: and again .....
Status: O

Subject: reply on comments, long message



Ed,

In reply to your message below:

=====================================================================
Date: Sun, 02 Feb 92 00:47:49 -0500
From: Ed Pring <pring@watson.ibm.com>

OK, now I think I understand the situation you're trying to address,
and why the current ds3 MIB definitions are a problem.  To make sure,
let me define some vocabulary and then give an example.

Its confusing to me to use the word "interface" for both host system
communications connections (the things listed by the netstat command
and in the MIB-II "interfaces" table) and for CSU serial link
connections (the things that T3 cables plug into).  Since MIB-II
has already defined "interfaces", let me call the T3 connections to
a CSU "ports" for now.  If there is a more widely accepted term,
I'll use that instead.

Suppose that we have a system with two CSUs, each of which supports
two ports, plus an ethernet adapter.  If you interpret the definitions
in the current ds3 MIB literally, then you might get values like this:

   description       ifIndex    ds3CSUIndex ds3Index
   --------------    -------    --------------------
   loopback             1
   CSU #1 port #1       2            1          2
   CSU #1 port #2       3            1          3
   ethernet             4
   CSU #2 port #1       5            2          5
   CSU #2 port #2       6            2          6

The problem is that since ds3CSUIndex is used as a table index, its
values must be unique.

If I understand your intent correctly, then I'll suggest that what
you'd really like to do is change the table index from ds3CSUIndex to
ds3Index, leaving the current definitions just as they are, and then
add a new variable for the "port" number.  Then you might have
something like this:

   description       ifIndex    ds3Index ds3CSUIndex ds3CSUPort
   --------------    -------    -------------------------------
   loopback             1
   CSU #1 port #1       2           2         1          1
   CSU #1 port #2       3           3         1          2
   ethernet             4
   CSU #2 port #1       5           5         2          1
   CSU #2 port #2       6           6         2          2

Since ds3CSUIndex and ds3CSUPort need not be unique values can be
assigned that are meaningful for the CSUs.  For example, CSUs often
have a serial number stamped on them that is software-readable; this
might be a good choice for ds3CSUIndex.  And the connectors on the
back of a CSU which supports multiple T3 links are usually labelled
"0-3" or "1-4"; these numbers might be a good choice for ds3CSUPort.

If this seems reasonable to you, then the remaining question is: What
bureaucratic process is required to change the index of a table?

And after that, is ds3NewLoopback any better than ds3Loopback?

Ed
=================================================================

Yes, I would like to change the INDEX of each table to
inclue either just ds3Index or both ds3CSUIndex and ds3Index;
thus leaving the description the same.

However, did you see my message to Colm Bergin:

==================================================
To: cbergin%dalitc@digi.lonestar.org, tacox@ginsu4, thumper!tob,
        trunk-mib@saffron.acc.com
Subject: DS3 and DS1 RFCs



Colm Bergin,

Ted Brunner from Bellcore cc'ed me on his mail
message to you about using the DS1/DS3 MIB
to manage a multiplexor or a digital cross-connect.
You were concerned that the MIBs were used only
to manage a CSU.

I am of the opinion that the DS1 MIB can be used
to manage a DS1 interface -- on any device.
To further manage a mux -- you may need other objects,
but the DS1 MIB is the minimum subset of things you need
to manage a device that has a DS1 interface.

I am trying to change the mibs to suit that need.


I would suggest you sign up to the
trunk-mib@saffron.acc.com mailing list to hear
the discussions on the DS1 and DS3 mibs.

To do that send your email info to
trunk-mib-request@saffron.acc.com

We at Bellcore are doing exactly what I described above
for our Switching System that supports SMDS.

For example, our switch has DS3 and DS1 interfaces.
On top of that interface runs the SMDS Interface Protocol
or SIP.  We support in our switch the DS1 and DS3 MIBs --
depending on the interface; and the SIP MIB --  see
draft-ietf-snmp-smdssipmib-06.txt (or 07) in internet-drafts.


So therefore, I see no reason that you could not use the
DS1 MIB to manage a portion of your mux or digital cross connect
system.

Included is your original mail message and Ted's response for
others to follow this arguement.

Thanks.

Tracy

===========================================
Tracy A. Cox
Bellcore
NVC 1C-354
331 Newman Springs Rd.
Red Bank, NJ  07701
tacox@sabre.bellcore.com email
(908) 758-2107 vmail
(908) 758-4177 fax
===========================================
Subject: Help on T1 MIB
Date: Thu, 06 Feb 92 14:22:59 -0500
From: tob@jeff.bellcore.com



Colm Bergin-
	"The T1 mib" is rfc1232, and so when you receive it you
will have what we've got, so far.  It concentrates on error
statistics associated with the transmission facility 
(eg. errored seconds, severly errored seconds, errored framing seconds)
kept on a 15minute time base.  There are also alarm states
(red and yellow) and some minimum amount of descriptive stuff
about the line (eg whether is ANSI-ESF or G704-CRC or ...)
	Now, as you have observed for the DS3 mib, this is kept by CSUs,
and you want to manage a multiplexor and a digital cross connect.
For that, this mib will not help you. 
	There is a mailing list for folks interested
in T1 and DS3 management (trunk-mib@saffron.acc.com) 
The request to join is probably (trunk-mib-request@saffron.acc.com)
Try there.
	The silver lining here is that you may be interested
in talking with other vendors to develop a mib for your line of
equipment.  This list is a good place to start looking for others.
Since I haven't really done such a thing myself,
I'm not qualified to suggest a game plan.  But if you want to 
pursue this, I'd be interested in talking, because I have an
interest in cross-connects in a different context - ATM switches.


Ted Brunner			Bellcore 
tob@thumper.bellcore.com	MRE 2P-252
201/829-4678			445 South St.
				Morristown NJ 07960-1910


------enclosed message---------

Dave,

I just recently received the reference list you posted to the SNMP mailing
list.  I was hoping to find mention of work on a MIB relating to the
management of T-1 multiplexors and digital cross connects, but in my
ignorance, I couldn't identify such a document.  I checked the DS-3
interface description, but it relates only to CSU's (I'm waiting to
receive RFC-1232 on DS-1 interfaces).

Do you know if the IETF is addressing management of such WAN devices?

Thanks for any information,

Colm Bergin
Software Engineer
Integrated Telecom Corp.
Internet: cbergin%dalitc@digi.lonestar.org


----- End Included Message -----

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

What I would prefer to do is change the ds3CSUIndex to
ds3EquipIndex (same for DS1 also).
ds3EquipIndex is just an identifier of a piece of equipment
the one or more DS3 Interfaces.

Therefore, the DS1 MIB and the DS3 MIB would be used
to monitor any type of DS1/3 interface.

I think the ds3NewLoopback is more generic
for managing just an interface.

ds3SendCode still needs work.

Let me stop here and let you digest all of this.
What do you think?  Are you following this long
message?

Tracy