Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [802.3ae] FW: WIS MIB list of open issues and recommendations for resolution




Mike,

Because there is becoming a likely hood that the WIS overhead definition 
will be adopted as a separate functional optical link protocol for optical 
switched networks, I would like to see more of a divorce between the WIS 
MIB and SONET.  By making references to the SONET MIB, there is still the 
perception that the WIS is part of SONET.  It is not.  Neither is it part 
of SDH.   I would like to see a totally separate set of definitions for the 
WIS MIB, not references to the SONET MIB or to the SDH MIB.  Personally, I 
think that it should be on a separate AIN branch from SONET or SDH.

Because of developments that are taking place in T1X1 and ITU regarding the 
development of a "path relay" type of "Lite LTE" or as it is known to 
802.3ae an "ELTE" as a standard, it will be better that these two MIBs not 
have references to each other.  The proposed "path relay" may well have two 
separate MIBs, or incorporate only the WIS MIB.  The "path relay" will also 
likely be part of actively managed wavelength transponders, which may be a 
lot less expensive than current LTEs or the proposed Digital Wrapper 
systems.  Over a period of time, this would make the WIS MIB a part of a 
much larger market than it has been previously believed.

Referencing any of the Existing SONET or SDH MIBs is a mistake.  Even if 
there are objects in the WIS MIB that may have the same function, and 
possibly the same "text", as objects in the SONET or SDH MIBs, they should 
be separate and inclusive within themselves.

Thank you,
Roy Bynum
Orbital View LLC

At 09:37 AM 12/31/2001 -0800, C. M. Heard wrote:
>On Thu, 27 Dec 2001, Tom Alexander wrote:
> > Roy, it looks like Dan's explanation is in general agreement with
> > the point you made in your e-mail as well. The WIS and SONET/SDH
> > MIBs are being kept separate for the reasons you mentioned.
>
>On Thu, 27 Dec 2001, Roy Bynum wrote:
> > I would take a different tack on the issue of "optional" WIS MIB
> > items.  I would prefer the stance that the MIB for the WIS is
> > restricted to the items that are included in the current draft,
> > and not include any additional "SONET" or "SDH" MIB items.  SONET
> > and SDH are specific and different protocol standards from 802.3ae.
> > The IETF should not confuse these standards, as they originate from
> > very different standards organizations[,] by trying to get creative
> > with the MIB definition for 802.3ae.
>
>On Thu, 27 Dec 2001, Dan Romascanu wrote:
> > The problem is that some of the objects that the authors of the
> > SONET MIB decided that may remain optional for their management
> > model are mandatory for a full definition and understanding of
> > the WIS interface behavior.  This is the reason for defining a
> > separate compliance statement that is stricter than the
> > compliance statement for a 'regular' SONET MIB implementation.
>
>Further elaboration may be helpful.  The draft SNMP WIS MIB in
>http://www.ietf.org/internet-drafts/draft-ietf-hubmib-wis-mib-01.txt
>defines some new WIS-specific objects but also incorporates by
>reference a specific subset of the objects in the SONET/SDH MIB.
>That subset of course exludes objects that are not relevent to the
>WIS (e.g. objects for managing SONET VTs), but it also includes as
>mandatory objects some that are considered conditionally mandatory
>or optional in the SONET/SDH MIB compliance statement (e.g. near-
>and far-end line and path layer objects).  All items listed in the
>draft SNMP WIS MIB compliance statement are mandatory, including both
>those that map to objects in the 802.3ae pWISBasic package and those
>that map to objects in the pWISOptional package (see Section 3.6 of
>the draft for details).  It was the consensus of the design team (and
>of the meeting participants at Salt Lake City) that all these objects
>need to be present to ensure effective management of the WIS.
>
>Regards (and best wishes for 2002),
>
>Mike Heard