Subject: RE: Last Call: Definitions of Managed Objects for SONET Linear APS Architectures to Proposed Standard

From: Michael Thatcher <[email-masked]>
Date: Thu, 03 Oct 2002 15:53:10 -0700

Orly raised 2 issues with the Sonet APS mib during IETF last call.

     (1)
     I noticed that the MIB is defined to be under transmission,
     however, since it is
     SONET related, doesn't it make more sense to put it under
     SONET like:
     :: ={sonetMIB XX }
     where XX can be 4
     instead of
     :: = { transmission XX } ?

Placing APS-MIB under SonetMIB causes two problems.  It makes the mib
dependant on the SonetMIB when currently there is no such dependancy.
The value  of  XX in {SonetMIB XX} is not defined and would require
definition in SONET-MIB or some agency to monitor/control assignment
such that any changes to SONET-MIB does not use the value of XX.  It's
not worth the effort.

     (2)
     unusual request:
     the following object
     apsConfigMode OBJECT-TYPE
            SYNTAX      INTEGER {
                                onePlusOne(1),
                                oneToN(2),
                                onePlusOneCompatible(3),
                                onePlusOneOptimized(4)
                                }
     had several changes over the cycles of the draft. Currently it
     seems like we are
     dealing with ports that are connected independent of each
     other. There are cases
     where ports are connected via Y cable, and the active port
     changed based on
     failure. It is not the APS protocol as defined by the ITU
     document but the MIB can
     serve that purpose as well. Such installation is very common
     and popular  in the
     field. Is it possible to have more options for the mode of
     switching, to support
     such? something like  others(6) could serve well  for options
     that are currently not
     defined by the STD but might be used by companies.

Jim Kuhfeld identified this as an issue raised over 2 years ago with no
response to suggested resolution.  Trying to add 'other' to
apsConfigMode has potential implications on other objects, e.g.
apsConfigRevert.   I think trying to address this during IETF last call
is not appropriate because there has been adequate time for the issue to
have been addressed in the past 2 years.

Mike Thatcher

---

From: "Faye Ly" <[email-masked]>
Date: Tue, 08 Oct 2002 12:28:11 -0700

Orly,

Do you think it is possible to use enterprise
MIB object to cover the Y-cable case?  Since
it is not currently standardized by ITU-T?
I think the main issue Mike tried to raise
is the undeterministic-ness of the object:

apsConfigRevert

with the proposed new value other(5).

Please let us know or else I would say this
issue is closed with no modification to the
SONET APS MIB.

-faye

>From: Mike Thatcher <[email-masked]>
>To: Orly Nicklass <[email-masked]>
>CC: [email-masked], [email-masked]
>Subject: Re: Last Call: Definitions of Managed Objects for SONET Linear APS 
>  Architectures to Proposed Standard
>Date: Tue, 08 Oct 2002 08:43:55 -0700
>
>Orly Nicklass wrote:
>>Erik, Faye,
>>
>>Since I did not see any significant problem raised by the list for the 
>>addition of the new value, and today is the last day of the CALL, can we 
>>close this with the improved description as suggested by Mike (see 
>>below)?,
>>
>
>I don't understand this statement.  Mike Heard had significant issues with 
>adding the new value.  I had and still have issues because it is not clear 
>what impact this change has with other objects and the fact that it's being 
>addressed during ietf last call when the issue was raised 2 years ago and 
>dropped.
>
>>As for the root of the MIB, I don't see much consensus either way.
>>
>>
>
>It seems to me that consenus is to leave it as it is.
>
>>>                         onePlusOneOptimized(4),
>>>                         other(5)
>>>     MAX-ACCESS  read-create
>>>     STATUS      current
>>>     DESCRIPTION
>>>        "The architecture of the APS group.
>>[ ... ]
>>>         other
>>>
>>>         The APS group is configured with an architecture other
>>>         that those explicitly described in this MIB.
>>           Any implementation that supports this value must         +
>>           document any restrictions that it implies with respect   +
>>           to the other objects in this MIB.                        +
>>
>>>         This object may not be modified if the associated
>>>         apsConfigRowStatus object is equal to active(1)."
>>>     DEFVAL {onePlusOne}
>>>     ::= { apsConfigEntry 3 }
>>
>>-----Original Message-----
>>From: Michael Thatcher [mailto:[email-masked]]
>>Sent: Friday, October 04, 2002 1:53 AM
>>To: [email-masked]
>>Cc: [email-masked]
>>Subject: RE: Last Call: Definitions of Managed Objects for SONET Linear
>>APS Architectures to Proposed Standard
>>
>>

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

---

From: "Orly Nicklass" <[email-masked]>
Date: Wed, 9 Oct 2002 09:29:12 +0200

Faye, 

Having it only  in the private MIB with no support of the value OTHER in the apsConfigMode causes inconsistency between objects. So this is not a good solution. 

The definition suggested by Mike resolves the issue you mention.
As for the apsConfigRevert, the way it is defined works for Y-cable just as well.

Orly

-----Original Message-----
From: Faye Ly [mailto:[email-masked]]
Sent: Tuesday, October 08, 2002 9:28 PM
To: [email-masked]; Orly Nicklass
Cc: [email-masked]; [email-masked]
Subject: Re: Last Call: Definitions of Managed Objects for SONET Linear

Orly,

apsConfigRevert

-faye

_________________________________________________________________
Join the world's largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

---

From: "Faye Ly" <[email-masked]>
Date: Mon, 14 Oct 2002 16:31:07 -0700

Orly,

But I thought Mike suggested not to add
other to the apsConfigMode and there was
no text change per this email thread.
I do agree with this approach, by the way.

-faye

>From: "Orly Nicklass" <[email-masked]>
>To: "Faye Ly" <[email-masked]>, <[email-masked]>
>CC: <[email-masked]>, <[email-masked]>
>Subject: RE: Last Call: Definitions of Managed Objects for SONET Linear APS 
>Date: Wed, 9 Oct 2002 09:29:12 +0200
>
>Faye,
>
>Having it only  in the private MIB with no support of the value OTHER in 
>the apsConfigMode causes inconsistency between objects. So this is not a 
>good solution.
>