Subject: RE: Optcial Interface MIB status

From: "Rishi Grover" <[email-masked]>
Date: Fri, 23 Aug 2002 17:40:29 -0700

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: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sun, 25 Aug 2002 12:48:23 +0200

Rishi, w.r.t. this comment,

> 2 parallel "entity" representations on the device. Not

The SENSOR-MIB will go into IETF Last Call any day now.
Might be good to either comment on that if this is a serious
concern by you (and possibly others).

Or, could also discuss it on the ENTMIB WG mailing list.
Can I at least forward it to that list?

Bert

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 25 Aug 2002 16:01:28 +0300

Rishi,

> Can I at least forward it to that list?

I think that you cannot avoid discussing the reasons for defining MIB objects that seem to replicate the Entity MIB, if you are to avoid comments during the Last Calls in the Working Group, and in the IESG. Is your decision to ' provide a very basic physical and logical object representation of the system' based on some missing functionality in the Entity MIB? If so I would suggest to follow Bert's advice and provide your inputs to the ENTITY MIB list. Otherwise, I would suggest that you avoid defining a new 'parallel "entity" representation on the device' and follow the approach of using the already existing standard.

Regards,

Dan

---

From: "Rishi Grover" <[email-masked]>
Date: Mon, 26 Aug 2002 15:08:12 -0700

Perhaps I was not very clear in my statement about the
SENSOR-MIB. 

Please allow me to clarify:

1. It is not because of any missing functionality in the ENTITY
MIB that I raised the issue. I believe the ENTITY MIB adequately
serves its purpose.

2. The reasons for the "basic logical and physical representation"
of our system are proprietary and legacy. As an example, it is 
not uncommon for vendors to have rack, shelf, slot, card, and 
port tables defined in their proprietary MIBs that PARTIALLY 
serve the requirements addressed by the ENTITY MIB. In most cases
this is sufficient for their purposes.

3. Having said that, obviously if this means that we cannot make use 
of existing  standards (in this case the SENSOR-MIB), we will need 
to evaluate this and see what makes most sense for us.

Regards,
Rishi

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]]
Sent: Sunday, August 25, 2002 6:01 AM
To: Wijnen, Bert (Bert); Rishi Grover; Lam, Hing-Kam (Kam); C. M. Heard;
AToMMIB Mailing List

Rishi,

Regards,

Dan