Subject: RE: Optcial Interface MIB status

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Fri, 6 Sep 2002 16:42:28 -0400

This is to summary the consense, base on the email discussion, for update to be done on the optical mib.

(A) Add input power to the Source and output power to the Sink for OTS, OMS, & OChGroup. 
- Define OutputPower objects in the OTS Sink tables  
  and add them to optIfOTSnSinkPreOtnPMGroup
- Define OutputPowerThreshold objects in the OTS Sink tables 
  and add them to optIfOTSnSinkPreOtnPMThresholdGroup  
- Define InputPower objects in the OTS Source tables 
  and add them to optIfOTSnSourcePreOtnPMGroup
- Define InputPowerThreshold objects in the OTS Source tables 
  and add them to optIfOTSnSourcePreOtnPMThresholdGroup

- Define OutputPower objects in the OMS Sink tables  
  and add them to optIfOMSnSinkPreOtnPMGroup
- Define OutputPowerThreshold objects in the OMS Sink tables 
  and add them to optIfOMSnSinkPreOtnPMThresholdGroup  
- Define AggregatedInputPower objects in the OMS Source tables 
  and add them to optIfOMSnSourcePreOtnPMGroup
- Define AggregatedInputPowerThreshold objects in the OMS Source tables 
  and add them to optIfOMSnSourcePreOtnPMThresholdGroup

- Define OutputPower objects in the OChGroup Sink tables  
  and add them to optIfOChGroupSinkPreOtnPMGroup
- Define OutputPowerThreshold objects in the OChGroup Sink tables 
  and add them to optIfOChGroupSinkPreOtnPMThresholdGroup  
- Define AggregatedInputPower objects in the OChGroup Source tables 
  and add them to optIfOChGroupSourcePreOtnPMGroup
- Define AggregatedInputPowerThreshold objects in the OChGroup Source tables 
  and add them to optIfOChGroupSourcePreOtnPMThresholdGroup

(B) Remove all the laser temperature objects from the OTS, OMS, OChGroup, and OCh tables. 
Delete them from the corresponding Object Groups. 

(C) Add text to explain
- The reason for not capturing laser temperature related 
  objects for the OCh, OChGroup, OMS, and OTS groups, 
- Why we choose not to expose mid-stage monitoring 
  capabilites in the MIB, 
- Rationale behind using a proprietary or SENSOR-MIB 
  to capture laser temperature
- When should OChGroup be modeled in the sytem and 
  when not

Comments and/or anything else?

Regards,
Kam

> -----Original Message-----
> From: Rishi Grover [mailto:[email-masked]]
> Sent: Friday, August 23, 2002 8:40 PM
> To: Lam, Hing-Kam (Kam); C. M. Heard; AToMMIB Mailing List
> Subject: RE: Optcial Interface MIB status
> 
> 
> Kam,
> 
> Sorry, I was sidetracked by other pressing issues 
> and just recently got a chance to catch up with the 
> email discussions relating to the OPT-IF-MIB.
> 
> Here are my comments:
> 
> Specfic Comments:
> -----------------
> 1) I am fine with your suggested approach
> which states under what circumstances the OChGroup
> should be present and when it should be absent.
> Please see my General Comment at the end of this mail.
> 
> 2) What I have found from folks who are working with 
> DWDM equipment is that their monitoring requirements
> and capabilites are quite different from one another
> i.e. there is no standard approach and/or preference.
> So I am unable to provide to the ATOMMIB list a set of 
> DWDM vendors that are consistent in their approach 
> towards monitoring.
> 
> 3) Wrt the discussion on SENSOR-MIB and the general 
> agreement to use it for measuring "non-standard" or 
> "equipment specific" objects, I think it is a good idea. 
> However from a practical standpoint, I see a v minor issue:
> 
> The implementation of the entityPhysicalGroup (in ENTITY-MIB)
> is required for agents which implement the SENSOR MIB.
> For many reasons (not relevant to this discussion), we 
> have choosen not to implement any of the ENTITY-MIB
> groups but provide a very basic physical and 
> logical object representation of the system. However 
> the SENSOR-MIB requirement may lead us to have to 
> implement the entityPhysicalGroup. This would result in 
> 2 parallel "entity" representations on the device. Not
> something desirable.
> 
> 4) I am in agreement with  removing the temperature 
> objects from ALL groups (OCh, OChGroup, OMS, OTS).
> 
> 5) As Mike has suggested, I think for completeness, 
> we should model the input power for OTSsrc and output 
> power for OTSsnk. As a side note, in our particular 
> implementation, these OTS power readings are indeed 
> "overloaded" by the input and output power readings
> for OMSsrc and OMSsnk respectively. However this may 
> not necessarily be the case in other implementations.
> 
> General Comment:
> ----------------
> It would be very helpful for the reader if we can 
> capture some of the discussed issues in these emails 
> as text in the MIB therby explaining the rationale 
> behind the decisions. For example:
> - The reason for not capturing laser temp. related 
> objects for the OCh, OChGroup, OMS, and OTS groups, 
> - Why we choose not to expose mid-stage monitoring 
> capabilites in the MIB, 
> - Rationale behind using a proprietary or SENSOR-MIB 
> to capture laser temperature
> - When should OChGroup be modeled in the sytem and 
> when not
> 
> 
> Rgds,
> Rishi 
> 
> 
> 
> -----Original Message-----
> From: Lam, Hing-Kam (Kam) [mailto:[email-masked]]
> Sent: Friday, August 09, 2002 12:19 PM
> To: 'C. M. Heard'; AToMMIB Mailing List; Rishi Grover
> Subject: RE: Optcial Interface MIB status
> 
> 
> On Monday, July 29, 2002 1:55 AM, C. M. Heard (Mike) wrote:
> > 
> > One point that I raised before but would like to raise again
> > is that it seems like the objects in the following groups
> > 
> >    optIfOMSnPostAmpPreOtnPMGroup
> >    optIfOMSnPostAmpPreOtnPMThresholdGroup
> >    optIfOMSnPreAmpPreOtnPMGroup
> >    optIfOMSnPreAmpPreOtnPMThresholdGroup
> > 
> > seem to become redundant if there are exactly corresponding
> > optIfOChGroup PM objects, which was the case in Rishi's proposal.
> > Here is why.  If there is a pre- or post-amp that covers all the
> > channels, there certainly seems to be no compelling reason to
> > prefer associating it with the OMSn layer rather than with an
> > optical channel group that that includes all of the OCh's.  The
> > OMSn layer is, after all, fundamentally associated with the OMSn
> > overhead signals and not with amplifiers and such (the functional
> > model in G.798 allows for the presence of pre- or post- amplifiers
> > in the OMSn source or sink but they are not required to be present).
> > It would -- in my opinion -- be preferable to avoid such redundancy.
> 
> The optIfOChGroup PM objects measure the banded channels (i.e., the
> channels within a band), while the optIfOMSn PM objects measure all
> channels across all bands. Therefore the groups
> 
>     optIfOMSnPostAmpPreOtnPMGroup
>     optIfOMSnPostAmpPreOtnPMThresholdGroup
>     optIfOMSnPreAmpPreOtnPMGroup
>     optIfOMSnPreAmpPreOtnPMThresholdGroup
> 
> will become redundant with the groups
> 
>     optIfOChGroupPostAmpPreOtnPMGroup
>     optIfOChGroupPostAmpPreOtnPMThresholdGroup
>     optIfOChGroupPreAmpPreOtnPMGroup
>     optIfOChGroupPreAmpPreOtnPMThresholdGroup
> 
> when (1) there is only one band and the OChGroup layer is present,
> or (2) there are multiple bands but an implementation does not wish 
> to model the banded configuration and a degenerated OChGroup 
> layer is present.
> However for these cases, the OChGroup layer should be absent. 
> In the draft
> version sent by Rishi on Wed 7/3/2002 1:42 PM, in the paragraph below
> figure 2, it states that:
> 
>    If an implementation does not wish to model the banded 
> configuration,
>    the OChGroup layer is absent and the OTN layering model 
> degenerates to
>    the description in Figure 1.
> 
> This will also answer Rishi's question on Tue 7/9/2002 1:46 AM:
> > An OChGroup models a group of lambdas associated with a particular 
> > band and a "degenerate" OChGroup in nothing but all the optical 
> > channels (if one does not want to model the banded amplifiers). 
> > Hence this begs the question "Is there a need for OMSn PM 
> parameters?"
> 
> 
> On Monday, July 29, 2002 1:55 AM, C. M. Heard (Mike) also wrote:
> > 
> > I like the idea of using the Sensor MIB for stuff that tends to
> > be very equipment specific.  I think that the best choice would
> > probably be to provide both input and output power pre-OTN PM
> > objects for any amplifier that is modelled, and relegate laser
> > temperature, mid-stage power, and any other technology-dependent
> > parameters to the Sensor MIB or a vendor MIB.
> > 
> 
> So for input and output power, is the following a proposal to
> move forward?
> 
> (1) Define OutputPower objects in the OMS Sink tables  
>     and add them to optIfOMSnSinkPreOtnPMGroup
> (2) Define OutputPowerThreshold objects in the OMS Sink tables 
>     and add them to optIfOMSnSinkPreOtnPMThresholdGroup  
> 
> (3) Define AggregatedInputPower objects in the OMS Source tables 
>     and add them to optIfOMSnSourcePreOtnPMGroup
> (4) Define AggregatedInputPowerThreshold objects in the OMS 
> Source tables 
>     and add them to optIfOMSnSourcePreOtnPMThresholdGroup
> 
> (5) Define and add the similar objects as (1) to (4) above 
> for OChGroup.
> 
> And for laser temperature:
> 
> (6) Delete the following Object Groups. 
>     optIfOMSnPostAmpPreOtnPMGroup
>     optIfOMSnPostAmpPreOtnPMThresholdGroup
>     optIfOMSnPreAmpPreOtnPMGroup
>     optIfOMSnPreAmpPreOtnPMThresholdGroup
>     optIfOChGroupPostAmpPreOtnPMGroup
>     optIfOChGroupPostAmpPreOtnPMThresholdGroup
>     optIfOChGroupPreAmpPreOtnPMGroup
>     optIfOChGroupPreAmpPreOtnPMThresholdGroup
> 
> (7) For the objects listed in the above Groups, delete them 
>     from the corresponding OMS and OChGroup tables.
>     That is, remove all the LaserTemp objects from the 
>     OMSs and OChGroup tables.
> 
> Comments?
> 
> Regards,
> Kam    
>

---

From: "C. M. Heard" <[email-masked]>
Date: Fri, 6 Sep 2002 14:49:40 -0700 (PDT)

On Fri, 6 Sep 2002, Lam, Hing-Kam (Kam) wrote:

> This is to summary the consense, base on the email discussion,
> for update to be done on the optical mib.
> 
[ ... details suppressed ... ]
> Comments and/or anything else?

Sounds good to me.

Mike