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

From: "Orly Nicklass" <[email-masked]>
Date: Sun, 6 Oct 2002 07:46:43 +0200

in lines

>  -----Original Message-----
> From: 	C. M. Heard [mailto:[email-masked]] 
> Sent:	Friday, October 04, 2002 1:22 AM
> To:	AToMMIB Mailing List
> Subject:	Re: [Fwd: Re: draft-ietf-atommib-sonetaps-mib-08.txt]
> 
> 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
> > 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.
> 
> 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.
	[Orly Nicklass]  Since a significant part of this MIB serves the case well, there is no conflict by including it in specially with a value such as "other" that can help other architectures at the same time. I requested "other" and no explicit value to avoid any potential need of re-writing any existing section of the draft. The added description in RED below make sense.
	By definition "other" is vendor specific case.

> 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:
> 
> On Wednesday, October 02, 2002 8:33 AM Jim Kuhfeld wrote:
> > 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.
> [ ... ]
> >         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 }
> 
> 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
>