Subject: RFC 2558 - path and VT time slot

From: David Zelig <[email-masked]>
Date: Tue, 25 Dec 2001 10:56:03 +0200

Kaj,

We find it useful to have the position of the path in SonetPathCurrentEntry
in addition to the width, since AFAIK there is no standard MIB that handle
it. 
I suggest to add to SonetPathCurrentTable the following entry:

sonetPathCurrentTimeSlot OBJECT-TYPE
   SYNTAX        Unsigned32 (1..768)
   MAX-ACCESS    read-write
   STATUS        current
   DESCRIPTION
        "this object indicates the starting
         time-slot for this SONET path within the SONET line
         and section. For OC-48, this value could range from 1
         to 48. The SONET path width must be taken into 
         consideration here. For example, in an OC-48, an
         STS-3c could not start at time-slot 47."

The same apply for VT.

Thanks
David

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 26 Dec 2001 11:30:08 -0800 (PST)

On Tue, 25 Dec 2001, David Zelig wrote:
> it.  I suggest to add to SonetPathCurrentTable the following entry:
> 

It's clearly true that if an implementation supports multiple
path layer objects per line or multiple VTs per path then there
needs to be some way to select (and report) which time slot is
used.  On the other hand, it has already been acknowledged that
the SONET-MIB is incomplete in these areas -- both the Marconi
and Corrigent implementation reports state that proprietary MIB
extensions are used to configure SONET paths, and the Marconi
implementation report states that proprietary MIB extensions
are used to configure SONET VTs.

It should be noted that there are other omissions besides the
starting time slot number that an implementation needs to
address in order to fuly specify the configuration of a SONET
path.  These include the path trace message transmitted/
expected/received in the J1 overhead byte and the path signal
label transmitted/expected/received in the C2 overhead byte.
The latter was discussed at some length last spring, and on
26 Apr 2001 Kevin Nolish made the following comment that bears
repeating here:

> I'd like to see [a C2 byte provisioning object] added, but
> I'm willing to back off in the face of determined opposition.
> If I thought that the mib was broken or made implementing
> this feature very difficult, as opposed to the mib simply
> being incomplete, I'd press harder.

My initial reaction is that if the proprietary MIB extensions
that vendors have been using to configure SONET paths and VTs
work satisfactorily, then it's probably best to leave the
SONET-MIB as is, because it will have to recycle at Proposed
Standard if SONET path and VT configuration objects are added.
An approach that would not impact the standardization status
of the SONET-MIB would be to standardize a set of path and VT
configuration objects in a separate suplemental MIB module.

Comments?

Mike

---

From: Kaj Tesink <[email-masked]>
Date: Fri, 28 Dec 2001 14:12:20 -0500

>configuration objects in a separate suplemental MIB module.

i fully agree. we would need the following:
a) detailed proposal (such as above)
b) some indication of support by some implementors

i suggest we leave 2558 as is.
in case of this addition has wider support i suggest
a separate suppl mib along mike's outline above.

kaj

>Mike

---------------------------------------
Kaj Tesink
[email-masked]
Tel. (732) 758-5254
Fax  (732) 758-2269
Telcordia Technologies
331 Newman Springs Rd
Red Bank, NJ 07701
USA
---------------------------------------