[EFM-CU-MIB]: Performance Monitoring

"Edward Beili" <[email protected]> Sun, 13 Nov 2005 21:40:52 +0200
Newsgroups gmane.ietf.hubmib
Message-ID <[email protected]>
Hi,
Please see below my email exchange with Matt about PMs in EFM-CU-MIB. Feel free to add your opinion.
Regards,
-Edward
 
-----Original Message-----
From: Matt Squire [mailto:[email protected]]
Sent: Friday, November 11, 2005 9:36 PM
To: Edward Beili
Subject: RE: question on MIB



 

Thanks much.  All of these conversations run together for me, and it‘s hard to remember what reasons applied to which decisions.  

 

If you want another vote, I’m also in camp 2.  I just think it should be clearer how to get to all of the data for the PMs.   I wouldn’t suggest re-vamping the whole MIB and schedule to add these things.  

 

- Matt

 

  _____  

From: Edward Beili [mailto:[email protected]] 
Sent: Friday, November 11, 2005 10:08 AM
To: Matt Squire
Subject: RE: question on MIB

 

Matt,
I think it was to keep the MIB relatively small and simple to implement.
Most of the things left out were Performance Monitoring related, the argument was that all other Ethernet interfaces provide only counters without PMs, instead providing just counters (which can be used to construct PM bins and to issue threshold crossing alerts). This way simple CPU-less devices can be built with little or no memory (a lot of which is required to keep the PM data, multiplied by the number of PMEs in case of a PME aggregation).

Actually this PM business has been boiling in the back of my head for quite some time. I see 4 possible ways to go:
1. Leave things as they are now, i.e. no PMs and no explanations
2. Leave PMs out but add an explanation and a pointer to the relevant G.SHDSL MIB objects in the descriptive part of the RFC, for those wishing to implement PMs.
3. Add new PM releated objects in the MIB.
4. Scrap the PME objects and use G.SHDSL MIB instead, including it.

Personally I'm leaning towards option 2, but can see the merit in the other options as well. Note also that options 2 and 3 will certainly delay the RFC approval.

Regards,
-E.

-----Original Message-----
From:   Matt Squire [ mailto:[email protected]]
Sent:   Fri 11/11/2005 5:28 AM
To:     Edward Beili
Cc:    
Subject:        question on MIB


I had a question on the EFM Cu MIB on which my memory is failing.  Way
back when there were discussions on whether we should bring the few
parts of the SHDSL MIB not covered in the EFM Cu MIB into the EFM Cu
MIB, or keep them separate.  It seems like we decided to leave some
things in the SHDSL MIB and not bring them into the EFM Cu MIB (for
example, TCAs). 

Do you remember why we decided that? 

- Matt

_______________________________________________
Hubmib mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/hubmib