Subject: [Fwd: Re: draft-ietf-atommib-sonetaps-mib-08.txt]

From: Mike Thatcher <[email-masked]>
Date: Wed, 02 Oct 2002 09:17:05 -0700

FYI, this is a series of messages in response to the IETF last call which the 
wokring group probably should be aware.

miket

-------- Original Message --------
From: Jim Kuhfeld <[email-masked]>
Subject: Re: draft-ietf-atommib-sonetaps-mib-08.txt
To: Orly Nicklass <[email-masked]>
CC: Jim Kuhfeld <[email-masked]>,	Erik Nordmark <[email-masked]>, 
Mike Thatcher <[email-masked]>, [email-masked]

I view this as the addition of an unknown APS protocol to the APS-MIB,
which when returned in apsConfigMode means the rest of the MIB objects returned
for this group will behave in an unknown manner. Doesn't this change require
consensus from the working group?

On Wed, Oct 02, 2002 at 09:40:34AM +0300, Orly Nicklass wrote:
 > There are cases where changes  can be done at the last minute without 
additional ID, but with agreement on the content. I see this change as one that 
can fit this category.
 >
 > -----Original Message-----
 > From: Jim Kuhfeld [mailto:[email-masked]]
 > Sent: Wednesday, October 02, 2002 9:30 AM
 > To: Orly Nicklass
 > Cc: Jim Kuhfeld; Erik Nordmark; Mike Thatcher; [email-masked]
 > Subject: Re: draft-ietf-atommib-sonetaps-mib-08.txt
 >
 >
 > I do share Mike's concern that this three year old draft will now begin 
another n month cycle
 > working through a two week WG draft introduction, two week WG last call, IESG 
queue, IETF last
 > call...
 >
 > On Wed, Oct 02, 2002 at 09:11:27AM +0300, Orly Nicklass wrote:
 > > I like what you did in the description. If we want to be more specific we 
can provide an example of Y Cable, but I feel comfortable with the way it is.
 > >
 > > Erik,
 > >
 > > have you done anything with WG chair or WG itself yet?
 > > I will talk to the WG chairs.
 > >
 > > Orly
 > >
 > > -----Original Message-----
 > > From: Jim Kuhfeld [mailto:[email-masked]]
 > > Sent: Wednesday, October 02, 2002 8:33 AM
 > > To: Orly Nicklass
 > > Cc: Jim Kuhfeld; Erik Nordmark; Mike Thatcher; [email-masked]
 > > Subject: Re: draft-ietf-atommib-sonetaps-mib-08.txt
 > >
 > >
 > > I see apsConfigMode as a key field that defines the way a particular
 > > APS group will be represented in other objects in the MIB. I'm assuming
 > > that with the value other there are no expectations regarding how
 > > channels are configured or which options are valid.  Are you sure
 > > we don't need to run this change by the working group?
 > >
 > >
 > > Let me go back to my original question. How would I document the
 > > other option in the description of apsConfigMode?
 > >
 > > apsConfigMode OBJECT-TYPE
 > >     SYNTAX      INTEGER {
 > >                         onePlusOne(1),
 > >                         oneToN(2),
 > >                         onePlusOneCompatible(3),
 > >                         onePlusOneOptimized(4),
 > >                         other(5)
 > >                         }
 > >     MAX-ACCESS  read-create
 > >     STATUS      current
 > >     DESCRIPTION
 > >        "The architecture of the APS group.
 > >
 > >         onePlusOne
 > >
 > >         The 1+1 architecture permanently bridges the working
 > >         line to the protection line.
 > >
 > >         oneToN
 > >
 > >         The 1:n architecture allows one protection channel to
 > >         protect up to n working channels. When a fault is detected
 > >         on one of the n working channels that channel is bridged
 > >         over the protection channel.
 > >
 > >         onePlusOneCompatible
 > >
 > >         This refers to 1 + 1 bidirectional switching compatible with
 > >         1:n bidirectional switching as specified in ITU-T
 > >         Recommendation G.783 (04/97) section A.3.4.1. Since this
 > >         mode necessitates bidirectional switching, apsConfigDirection
 > >         must be set to bidirectional whenever onePlusOneCompatible is set.
 > >
 > >         onePlusOneOptimized
 > >
 > >         This refers to 1 + 1 bidirectional switching optimized
 > >         for a network using predominantly 1 + 1 bidirectional
 > >         switching as specified in ITU-T Recommendation G.783 (04/97)
 > >         section B.1. Since this mode necessitates bidirectional
 > >         switching, apsConfigDirection must be set to bidirectional
 > >         whenever onePlusOneOptimized is set.
 > >
 > >         other
 > >
 > >         The APS group is configured with an architecture other than
 > >         those explicitly described in this MIB.
 > >
 > >         This object may not be modified if the associated
 > >         apsConfigRowStatus object is equal to active(1)."
 > >     DEFVAL {onePlusOne}
 > >     ::= { apsConfigEntry 3 }
 > >
 > >
 > >
 > >
 > > On Wed, Oct 02, 2002 at 07:10:51AM +0300, Orly Nicklass wrote:
 > > > Since there is no reference to that, but it is commonly used, I suggested 
the value "other" for such cases. As such, I believe it does not need any 
reference, and it should not be controversial either.
 > > >
 > > > -----Original Message-----
 > > > From: Jim Kuhfeld [mailto:[email-masked]]
 > > > Sent: Tuesday, October 01, 2002 8:06 PM
 > > > To: Erik Nordmark
 > > > Cc: Mike Thatcher; Orly Nicklass; [email-masked]; [email-masked]
 > > > Subject: Re: draft-ietf-atommib-sonetaps-mib-08.txt
 > > >
 > > >
 > > > On Tue, Oct 01, 2002 at 10:33:10AM +0200, Erik Nordmark wrote:
 > > > > > My understanding is that changing the definition of apsConfigMode 
will force
 > > > > > another round of last calls to  mib working group, etc which will force >
 > > > > another  4-6 months delay (given our past experience) in getting this 
out.  >
 > > > > I don't think  it buys a whole lot to make the change.
 > > > >
 > > > > Wouldn't this merely be adding another item to the enumeration,
 > > > > which would be non-controversial in the WG?
 > > > >
 > > > > When things work well (the AD is awake, the authors crank out updated I-Ds
 > > > > quickly, and the chairs are on top of who is holding the ball)
 > > > > a non-controverial change can be done quite quickly. The only significant
 > > > > issue would be whether the co-chairs see a need for a new WG last call.
 > > >
 > > > According to my archives the ITU enhancements and Y-cable request dates 
back to
 > > > January 2000. At that time I added onePlusOneCompatible and 
onePlusOneOptimized
 > > > to the draft since I was able to locate and included references to the 
ITU specifications
 > > > which explained those applications. I was not able to locate references 
for Y-cable
 > > > in the specifications so I requested additional information. I don't see 
that any
 > > > further comments were received, so the Y-cable enumeration was not 
pursued. I still
 > > > have the question of how to document a Y-cable enumeration, so I wonder 
if this
 > > > wouldn't be something that would necessitate WG review, and for that reason
 > > > should be deferred for now.
 > > >
 > > >
 > > > On Sat, Jan 08, 2000 at 02:54:05AM +0000, [email-masked] wrote:
 > > > > 6. can we add more values in apsConfigMode? we think there should be a 
different values for 1+1
 > > > > optimised vs 1+1 compatible to 1+n (annex B and annex A respectively). 
Also we thought about
 > > > > adding path-protection and Y-cable-protection.
 > > > >
 > > >
 > > > -----------------
 > > > (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.
 > > > >   Erik

---

From: "C. M. Heard" <[email-masked]>
Date: Thu, 3 Oct 2002 15:21:32 -0700 (PDT)

On Wed, 2 Oct 2002, Mike Thatcher wrote:
> FYI, this is a series of messages in response to the IETF
> last call which the [working] group probably should be aware.

There are some comments that I'd like to make about this.  Please
note that I've trimmed down and re-ordered the quoted correspondence
to focus on the relevant points, and I've reformatted the line
breaks in the quoted text for improved readability.  Here is the
statement of the key issue, if I understand it correctly:

On Tuesday, October 01, 2002 8:06 PM Jim Kuhfeld wrote:
> According to my archives the ITU enhancements and Y-cable request
> dates back to January 2000.  At that time I added onePlusOneCompatible
> and onePlusOneOptimized to the draft since I was able to locate and
> included references to the ITU specifications which explained those
> applications.  I was not able to locate references for Y-cable in the
> specifications so I requested additional information.  I don't see 
> that any further comments were received, so the Y-cable enumeration
> was not pursued.  I still have the question of how to document a
> Y-cable enumeration, so I wonder if this wouldn't be something that
> would necessitate WG review, and for that reason
> > 6. can we add more values in apsConfigMode? we think there should be
> > a different values for 1+1 optimised vs 1+1 compatible to 1+n (annex
> > B and annex A respectively).   Also we thought about adding
> > path-protection and Y-cable-protection.
>
> -----------------
> (2)
> unusual request:
> the following object

I would STRONGLY OBJECT to adding support for Y-cable protection
architectures into the document "Definitions of Managed Objects
for SONET Linear APS architectures" on the grounds that they DO NOT
qualify as SONET Linear APS architectures and are therefore outside
the scope of the document.  The linear APS schemes that this MIB
module is intended to manage exist mainly to protect against failures
of the physical circuit between two SONET NEs, and always have the
following properties:

  1.) There exist at least two physical circuits between the two
  NEs, and each terminates on a different interface on each NE.  One
  of the circuits is a protection circuit, although it may in some
  cases be used to carry unprotected traffic when not needed (i.e.
  when none of the primary ciruits has failed).

  2.) Swithching criteria are based on SONET Line Layer defects
  (including "implied AIS" when there is a lower layer defect)
  and BER measurements made via the B2 line overhead bytes.

  3.) APS status information (and in most cases control information
  as well) is carried in the K1/K2 line overhead bytes exchanged by
  the two NEs.

Y-cable protections have NONE of these properties.  Their purpose
is to protect against failures within a transport network, and
they work like this:

  1.) There is a _single_ physical circuit between a transport NE
  and an end system of some sort (e.g., a router).  This circuit
  is connected to one interface on the end system but is connected
  via a Y-cable to two interfaces on the transport NE.  Each
  interface on the transport NE has its "high-speed" side connected
  via the transport network to a counterpart on the remote transport
  NE.  At any given time both interfaces at the local transport NE
  receive from the end system and send to the remote transport NE,
  but only one of the two sends to the end system.  Typically this
  is done by turning only one interface's transmit laser on.

  2.) Switching criteria are based on whatever internal maintenance
  information is available from the remote NE.  Often this does NOT
  involve SONET overhead;  in DWDM systems it is usually based on
  loss of received signal.  Details can vary greatly from vendor
  to vendor.

  3.) APS status information may or may not be exchanged with the
  remote NE, and if it is, it does not necessarily use the K1/K2
  line overhead bytes (these might be reserved for use by the
  end system).

In sum, the linear APS schemes that draft-ietf-atommib-sonetaps-mib-08.txt
is intended to manage are USER side protection schemes.  Y-cable protection
schemes are NETWORK side protection schemes, using different mechanisms,
and are therefore outside the scope of the document.  Now if it turned
out that the MIB objects in draft-ietf-atommib-sonetaps-mib-08.txt
happened to be useful for managing Y-cable schemes, then perhaps there
would be a case for broadening the scope of the document.  However, after
once again re-reading the draft I have concluded that such is not the case.
If I had to manage a Y-cable protection scheme I would not try to use the
objects in draft-ietf-atommib-sonetaps-mib-08.txt to do it.  I'd write a
proprietary MIB that could do the job right.

It's possible that as a separate project one might wish to make a standard
MIB for managing Y-cable protection schemes, but I don't think that would
work well in practice:  because they are not standardized, Y-cable
protection schemes vary greatly in detail from vendor to vendor, and the
management aspects are likely to differ a lot as well.

I don't know if this removes all of the motivation for adding an
"other(5)" enumeration to apsConfigMode -- it is conceivable that
there do exists other schemes besides the ones listed to which
the objects in the MIB might apply -- but I do share Jim Kuhfeld's
reservations about what it implies about the meaning of those objects.
In my opinion, the only thing we could do is state that any vendor
that uses the "other(5)" enumeration MUST document what it means.  So
I'd suggest, in answer to Jim's question, that if this enumeration is
added, we include text like that with '+' signs on the right
in the DESCRIPTION clause:

>        "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.                        +

>         apsConfigRowStatus object is equal to active(1)."

Let me hasten to add that while I could accept this, I do not like it.
When I see stuff like this in a MIB I am reviewing, I usually suggest
that it would be best left out as it does not foster interoperability.

My recommendation is to leave the draft as it is.

Mike