Subject: status update and atommib charter

From: Kaj Tesink <[email-masked]>
Date: Mon, 14 Jun 1999 17:04:53 -0400

hi,

many of our I-Ds have made it to RFC; the remaining ones are:
- suppl atm mib        - we're doing a quality check on a revision;
                         changes are minor; hopefully this can be
                         wrapped up after this posting
- atm test mib         - waiting for completion of the test mib which
                         was quality reviewed by bert
- atm 15 min perf mib  - will be dropped due to lack of interest

since we're nearing completion of these specs we need to assess whether 
subsequently the wg needs go go into dormant/maintenance mode or whether any 
additional work should be undertaken. i have received over time several 
suggestions for additional work. 
i like to gauge the level of actual support for such work.

1. supplemental sonet/sdh mib work, including
   * support of APS/protection switching
   * assess the issue whether Counter32 statistics would be needed
     and/or the use of usrHistoryGroup style of statistics in RFC 2021
   * full support of T1.231
   there have been some off-line discussions on these topics and volunteers
   for doing the editing work seem to be available.

2. supplemental supplemental atm mib
   * full support of UNI 4.0
   this has been mentioned on several occasions but if we do this we'll need
   a volunteer editor

3. WDM mib
   this has been suggested from time to time to me but if we do this we'll need
   a volunteer editor

4. maintenance of the current rfcs 2493, 2512-2515, rfcatmtest, rfcsupplatmmib

please comment on whether work on items 1-3 would be
useful/desirable/undesirable.

based on feedback we'll revise the outdated charter accordingly

kaj

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

Kaj Tesink
Telcordia Technologies (formerly Bellcore)
Email  [email-masked]
Tel    732.758.5254
Fax    732.758.2269
Postal 331 Newman Springs Rd
       Red Bank, NJ 07701
       USA

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

---

From: "Rodney Miller" <[email-masked]>
Date: Tue, 22 Jun 1999 09:12:34 -0400

In the ATMTEST-MIB, the atmLoopbackID objectType is defined to be on a
device level (atm NE).

Shouldn't atmLoopbackID be defined on an Interface Level?

{In the atmf M4 Logical MIB, it appears that there is a
loopbackLocationCode for every interface.}

Thanks, 

rodMiller

---

From: "Umberto Bonollo" <[email-masked]>
Date: Wed, 23 Jun 1999 11:56:33 +1000

I too like the idea that the LogicalLoopbackId should be indexed
by ifIndex.

Here are some suggestions to consider:
The size should be "0|16" i.e. either zero length or
16 bytes fixed OCTET STRING (The SNMP M4 ATM MIB I've seen has the wrong
type for this: INTEGER).
There are several benefits to this:
1. There can be several connecting points (CPs's) for ingress/egress
in a switch / NE.
2. Zero length can indicate that loopback checking is disabled
in the sense of I.610 - change the Id to some
fixed 16 byte value to enable loopback.
3. Interfaces (CP's) which do not implement loopback insertion/detection
can simply boot and leave this value at zero length. Not all ATM Switches
or ATM Multiplexers allow loopback at every interface due to hardware
constraints.

-- Umberto

Umberto Bonollo ([email-masked])
Senior Computer Scientist
ATM Projects
Systems Software Department
NEC Australia

> -----Original Message-----
> From: Rodney Miller [mailto:[email-masked]]
> Sent: Tuesday, 22 June 1999 23:13
> Cc: [email-masked]
> Subject: OAM Loopback Location Code?
>
>

---

From: Kaj Tesink <[email-masked]>
Date: Thu, 24 Jun 1999 18:10:42 -0400

let me understand what you're saying:

               atmLoopbackID    OBJECT-TYPE
                    SYNTAX         OCTET STRING(SIZE(0|16))
                    MAX-ACCESS     read-write
                    STATUS         current
                    DESCRIPTION
                      "This identifier is used to identify this local
                      ATM device. The value of this object can be used
                      by other ATM devices to identify this local ATM
                      device as the device that is being requested to
                      loopback the OAM Loopback cell. The default for
                      this field is all 1's, which would indicate a
                      segment OAM Loopback Test. A zero length identifier
                      signifies that loopback checking is disabled.
                      Non-zero length identifiers of less than 16 octets 
                      signify that loopback checking is enabled and
                      are left justified, and padded with all 0's."
                   DEFVAL  { 'ffffffffffffffffffffffffffffffff'H }
                   REFERENCE
                      "I.610"
                   ::= { atmLoopbackIDEntry 1 }

whereas atmLoopbackIDEntry is an entry in an atmLoopbackIDTable which is
indexed
by ifIndex (ifIndex of the atm interface)

any other views on this?

kaj

Kaj Tesink

---

From: "Umberto Bonollo" <[email-masked]>
Date: Fri, 25 Jun 1999 11:30:19 +1000

> by ifIndex (ifIndex of the atm interface)

Yes, you are correct above and in the modified description of the
object.

Here's an example draft fragment from me
with an appropriate description (The table name is draft too).

I don't know that the "all 1's" default is useful at all
- consider omitting it and starting with loopback off.
Anyway, hope this is useful for the group.

Cheers, Umberto

Here's the fragment:

-- atmIf
--
atmIfTable OBJECT-TYPE
    SYNTAX	SEQUENCE OF AtmIfEntry
    MAX-ACCESS	not-accessible
    STATUS	current
    DESCRIPTION
	"Defines a 16 byte Logical Loopback
	Identifier (LLID) for an ATM interface - See ITU I.610."
    ::= { atmIf 1 }

atmIfEntry OBJECT-TYPE
    SYNTAX	AtmIfEntry
    MAX-ACCESS	not-accessible
    STATUS	current
    DESCRIPTION
	"An atmIf entry."
    INDEX   { ifIndex  }
    ::= { atmIfTable 1 }

AtmIfEntry ::= SEQUENCE {
    atmIfLogicalLoopbackId
	OCTET STRING
}

atmIfLogicalLoopbackId OBJECT-TYPE
    SYNTAX	OCTET STRING (SIZE (0|16))
    MAX-ACCESS	read-write
    STATUS	current
    DESCRIPTION
	"This identifier is used to identify this local
	ATM interface for loopback.
	The value of this object can be used
	by other ATM devices to identify this local ATM
	interface as the interface that is being requested to
	loopback the OAM Loopback cell.
	The default for this field is the zero length string which
	signifies that loopback at this interface is disabled.
	To enable loopback set the value to a 16 byte fixed length
	octet string. Non-zero length identifiers of less 
      than 16 octets signify that loopback checking is enabled and
      are left justified, and padded with all 0's."
    DEFVAL {''H }
    REFERENCE
       "I.610"
    ::= { atmIfEntry 1 }

> From: Kaj Tesink [mailto:[email-masked]]
> Sent: Friday, 25 June 1999 8:11
> To: [email-masked]; 'Rodney Miller'
> Subject: RE: OAM Loopback Location Code?
> 
>

---

From: Kaj Tesink <[email-masked]>
Date: Fri, 25 Jun 1999 11:42:35 -0400

>with an appropriate description (The table name is draft too).

ok, sounds like we're in sync.
as a minor improvement I suggest we could AUGMENT the atmInterfaceConfTable
of rfc2515 instead of creating a separate table for this object. 
in your fragment you use the descriptor atmIfLogicalLoopbackId;
this then becomes atmInterfaceLogicalLoopbackId

(is there a reason for the "Logical" in that descriptor;
we were not using this in the past.
also, is the reference to I.610 still current (uses now the
1995 version)

>- consider omitting it and starting with loopback off.

i tend to agree

>Anyway, hope this is useful for the group.

thanks for the help

kaj

Kaj Tesink

---

From: "Rodney Miller" <[email-masked]>
Date: Fri, 25 Jun 1999 12:12:26 -0400

That's what we were thinking here, augmenting the
atmInterfaceConfTable...
would that put this in the ATM2-MIB's atmInterfaceExtTable??

Thanks!

Rod Miller

> also, is the reference to I.610 still current (uses now the
.

---

From: Kaj Tesink <[email-masked]>
Date: Fri, 25 Jun 1999 14:42:38 -0400

>would that put this in the ATM2-MIB's atmInterfaceExtTable??

i guess it could; shouldnt make a difference

kaj

Kaj Tesink

---

From: "Umberto Bonollo" <[email-masked]>
Date: Mon, 28 Jun 1999 12:06:07 +1000

> i guess it could; shouldnt make a difference

1) My view would be that you can use the
AUGMENTS to atmInterfaceConfTable (which is OK)
but that it should remain in the ATMTEST-MIB
so that you don't have to implement/import the ATM2-MIB module.

The ATM2-MIB mainly focuses on SVCs and ILMI.
My preference is to keep the OAM stuff in separate MIB modules.
You may wish to consider this...

> >> also, is the reference to I.610 still current (uses now the

2) The reference to [ITU] "I.610" is still current. The word "Logical"
comes from "LLID" in I.610 which means "Logical Loopback Identifier"
of the OAM loopback cell. I'm OK with any name that's been put forward
thus far :-)

-- Umberto

> Sent: Saturday, 26 June 1999 1:43