Subject: RE: Switchover traps in draft-ietf-atommib-sonetaps-mib-05.txt

From: Muly Ilan <[email-masked]>
Date: Sun, 10 Feb 2002 23:44:23 +0200

We also noticed this issue with the APS MIB. I agree to the proposed
description change.

There are other issues with the draft-ietf-atommib-sonetaps-mib-05 that
should be noted:

1. Ambiguous definition of lockout state

   apsChanStatusCurrent OBJECT-TYPE
       SYNTAX     BITS {
                  lockedOut(0),
                  sd(1),
                  sf(2),
                  switched(3)
               }
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
           "Indicates the current state of the port.

            lockedOut

            This bit, when applied to a working channel, indicates that
            the channel is prevented from switching to the protection line.
            When applied to the null channel, this bit indicates that no
            working channel may switch to the protection line.
<snip>

But in the definition of ApsSwitchCommand textual convention it says

        lockoutOfProtection
        Prevents any of the working channels from switching to the
protection
        line. The specified channel should be the protection channel.

Thus if the switch command with a value of 'lockout' can not be applied to a
working channel, then the description of apsChanStatusCurrent is misleading.

2. Missing wait-to-restore status bit
A working channel may be in the WTR state for a period of up to 12 minutes.
This is a relatively long time.
The apsChanStatusCurrent should include a bit that indicates this state.

3. Relation to IF-MIB
The draft does not describe the relationship with IF-MIB. In particular the
effect of ifAdminStatus/ifOperStatus on the APS state machine. For example,
what should be the apsChanStatusCurrent when ifOperStatus=down?
Initially we considered an ifOperStatus<>up to be handled like SF for the
relevant channel. But according to the Sonet MIB an RDI-L should cause
ifOperStatus=down. Thus RDI-L may result a switchover which is wrong in
unidirectional mode.
For now we use ifAdminStatus=down as an SF state for the relevant channel.

4. Clear command - missing description
Should an error message be generated when the clear command is applied to a
channel with no active switch command?
We decided not to generated an error and to record this command in
apsCommandSwitch.

5. apsConfigTable and notInService - missing description
To make any changes to an entry in the apsConfigTable that entry must first
be placed in the notInService state. It is not clear from the descriptions
whether the APS group should continue with the previous settings during the
notInService state or maybe no protection should be available in this state.
Each alternative has its own scenarios that make more sense for adopting it.

6. Exercise command failure - missing description
What should be the SNMP response when the command failed due to APS protocol
error (e.g. far-end LTE does not respond as expected)?
What should be the SNMP response when the command failed due to existing
request with higher priority? 
We decided on 'General Error' for the first case and 'Inconsistent Value'
for the second.

Muly Ilan

-----Original Message-----
From: Mickey Spiegel [mailto:[email-masked]]
Sent: Friday, February 08, 2002 5:11 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Switchover traps in draft-ietf-atommib-sonetaps-mib-05.txt

We realize that last call for this MIB ended a while ago, but we would
like to raise an issue with regard to the switchover trap defined in
draft-ietf-atommib-sonetaps-mib-05.txt.

The relevant definitions from the current draft are:

   apsChanStatusSwitchovers OBJECT-TYPE
       SYNTAX     Counter32
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
           "The number of times this channel has switched to the protection
            line. When queried with index value apsChanConfigNumber set to
0,
            which is the protection line, this object will return 0."
       ::= { apsChanStatusEntry 4 }

   apsChanStatusLastSwitchover OBJECT-TYPE
       SYNTAX     TimeStamp
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
           "The value of sysUpTime when this channel last completed a switch
            to the protection line. If this channel has never switched to
the
            protection line, or this channel is the protection line, the
value
            0  will be returned."
       ::= { apsChanStatusEntry 5 }

   <snip>

   apsEventSwitchover NOTIFICATION-TYPE
       OBJECTS { apsChanStatusSwitchovers, apsChanStatusCurrent }
       STATUS  current
       DESCRIPTION
               "An apsEventSwitchover notification is sent when the
               value of an instance of apsChanStatusSwitchovers increments."
                  ::= { apsNotificationsPrefix 1 }

With these definitions, a trap is issued whenever a switchover occurs
from the working channel to the protection line.  However, no trap is
issued if a switchover occurs from the protection line to the working
channel.  We believe this is a serious limitation, particularly when
1+1 non-revertive APS is used.

Why was it decided that apsChanStatusSwitchovers should not apply to
the protection line?

We would like to propose the following modifications:

   apsChanStatusSwitchovers OBJECT-TYPE
       SYNTAX     Counter32
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
           "When queried with index value apsChanConfigNumber other than 0,
            this object will return the number of times this channel has
            switched to the protection line.

            When queried with index value apsChanConfigNumber set to 0,
            which is the protection line, this object will return the
            number of times that any working channel has been switched
            back to the working line from this protection line."
       ::= { apsChanStatusEntry 4 }

   apsChanStatusLastSwitchover OBJECT-TYPE
       SYNTAX     TimeStamp
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
           "When queried with index value apsChanConfigNumber other than 0,
            this object will return the value of sysUpTime when this
            channel last completed a switch to the protection line. If this
            channel has never switched to the protection line, the value
            0 will be returned.

            When queried with index value apsChanConfigNumber set to 0,
            which is the protection line, this object will return the
            value of sysUpTime the last time that a working channel was
            switched back to the working line from this protection line.
            If no working channel has ever switched back to the working
            line from this protection line, the value 0 will be returned."
       ::= { apsChanStatusEntry 5 }

With these definitions, the apsEventSwitchover trap is issued whenever
a switchover occurs, either from a working channel to the protection
line, or from the protection line back to a working channel.

We also suggest that a global MIB object be added to enable or disable
generation of the traps defined in this MIB.

Mickey

---

From: Jim Kuhfeld <[email-masked]>
Date: Wed, 13 Feb 2002 14:27:08 -0800

I have added this comment and the remarks by Muly Ilan on Feb. 10, 2002
to an issues list. I believe these are the only issues that have been 
raised since the last call in May 2001. Let me know if I've missed
anything. My understanding of the status of 
draft-ietf-atommib-sonetaps-mib-05.txt follows.

An initial IESG MIB review in Oct. 2001 produced a set of issues which 
were packaged in an updated version of the 05 draft. Those updates
were submitted to the MIB reviewers for approval. Currently the atommib 
Co-chairs are reviewing the status of those updates within the IESG and
will decide what the next step will be.

Thanks.

On Wed, Feb 13, 2002 at 01:11:10PM -0800, Mickey Spiegel wrote:
> Can we please get a response to this proposal on the atommib mailing
> list?
> 
> Thanks,
> Mickey
> 
> 
> ------- Forwarded Message
> 
> Message-Id: <[email-masked]>
> cc: [email-masked], [email-masked], [email-masked]
> Date: Thu, 07 Feb 2002 19:10:54 -0800
> From: Mickey Spiegel <[email-masked]>
> 
>             line. When queried with index value apsChanConfigNumber set to 0,
>             to the protection line. If this channel has never switched to the
>             protection line, or this channel is the protection line, the value
>             0  will be returned."
> ------- End of Forwarded Message
>