Re: [802.3_YANG] RMON counters

[Geoff Thompson <thompson@xxxxxxxx>]

Yan-

My view (and not all may agree)

The only changes to clause 30 should be changes to bring the clause up to date, that is to remedy work that has been neglected.  There should be no policy change from the original policy on what it contains.  The move to YANG from SNMP only proves the the value of the original decision to have clause 30 in the first place.

On he other hand, while the new YANG clause "should" look to 802.3.1 for guidance for what to include in terms of derived counters, registers, alarms, notifications etc. But they are free to add, delete or modify those derived items based on their utility.  Some folks may want YANG to exactly duplicate the reporting abilities of SNMP.  I am not one of them.

Best regards,

Geoff

On Dec 14, 2016, at 10:00 PMPST, Zhuangyan (Yan) <zhuangyan.zhuang@xxxxxxxxxx> wrote:

Good point. We met it again : )

It is similar to the discussion we had on PSE module in Nov. meeting, since Std 802.3.1 MIB provides extra objects/attributes which are not in CL 30. 

The statement was CL 30 provides objects/attributes that management system can access to for managing IEEE 802.3 devices. Besides, attributes derived from CL45 can also be used by management system.

So when managing 802.3 devices, we can use these *access* provided by IEEE 802.3. Otherwise, we cannot make sure if the managed devices provide accesses for some managements.

 

For this sort of discussions, the question should be whether we can have these attributes/objects in 802.3 YANG modules if they are not in CL30/45.

In general, there are cases:

1.       Objects/attributes defined in Std 802.3.1

Thanks for Geoff’s background. If CL 30 was assumed to define basic measurements while Std 802.3.1 is more functionality for management, which is a standardized implementation for SNMP management of Ethernet. I think that should not be a problem, YANG modules can also refer to objects/attributes from Std 802.3.1.

2.       Objects/attributes defined in IETF RFCs and elsewhere

We will have to achieve consensus to include these attributes into 802.3 modules.

One suggestion is that we can have the modules with set of attributes/objects from CL30/45 and 1) as basis first and include new attributes from 2) with consensus through discussions.

 

Any thoughts?

 

Ps: and yes, we would aim to provide same level of functionality as Std 802.3.1 does.

 

Best Regards,

 

Yan

 

发件人: Geoff Thompson [mailto:thompson@xxxxxxxx] 
发送时间: 2016年12月15日 3:41
收件人: STDS-802-3-YANG@xxxxxxxxxxxxxxxxx
主题: Re: [802.3_YANG] RMON counters

 

Cl. 30was never intended to be a full Mgmt standard

nor was it intended to be specific to any protocol.

 

802.3.1 was intended to fully specify a standardized implementation of SNMP management of Ethernet.

 

My understanding was that the YANG project intended to be equivalent in functionality to 802.3.1.

 

Geoff

 

 

On Dec 14, 2016, at 10:13 AMPST, Duane Remein <Duane.Remein@xxxxxxxxxx> wrote:

 

I was thinking that Eth YANG would cover Std 802.3.1 and not just Std 802.3 Cl 30. Is that not the case?

Best Regards

Duane

 

From: Marek Hajduczenia [mailto:mxhajduczenia@xxxxxxxxx] 
Sent: Wednesday, December 14, 2016 12:25 PM
To: STDS-802-3-YANG@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_YANG] RMON counters

 

I believe we discussed at some time building not just to Clause 30 but providing the same level of functionality as 802.3.1 MIBs we have for Ethernet today, which would cover RMON MIB if I am not mistaken 

 

From: Robert Wilton [mailto:rwilton@xxxxxxxxx] 
Sent: Wednesday, December 14, 2016 11:41 AM
To: STDS-802-3-YANG@xxxxxxxxxxxxxxxxx
Subject: [802.3_YANG] RMON counters

 

Hi,

Quite a lot of useful Ethernet statistics (which seem to be widely implemented, at least on our platforms) are defined in the RMON MIB, rfc2819:

I would like to consolidate these statistics with the ones defined by the Etherlike MIB as part of the basic Ethernet interface definition.  However, there are not Clause 30 objects for the counters below.  How can this be resolved?  Can we need to define new clause 30 objects for these counters? Or do these counters need to be standardized elsewhere (e.g. IETF)?

 EtherStatsEntry ::= SEQUENCE {

     etherStatsIndex                    Integer32,

     etherStatsDataSource               OBJECT IDENTIFIER,

     etherStatsDropEvents               Counter32,

     etherStatsOctets                   Counter32,

     etherStatsPkts                     Counter32,

     etherStatsBroadcastPkts            Counter32,

     etherStatsMulticastPkts            Counter32,

     etherStatsCRCAlignErrors           Counter32,

     etherStatsUndersizePkts            Counter32,

     etherStatsOversizePkts             Counter32,

     etherStatsFragments                Counter32,

     etherStatsJabbers                  Counter32,

     etherStatsCollisions               Counter32,

     etherStatsPkts64Octets             Counter32,

     etherStatsPkts65to127Octets        Counter32,

     etherStatsPkts128to255Octets       Counter32,

     etherStatsPkts256to511Octets       Counter32,

     etherStatsPkts512to1023Octets      Counter32,

     etherStatsPkts1024to1518Octets     Counter32,

     etherStatsOwner                    OwnerString,

     etherStatsStatus                   EntryStatus

Thanks,
Rob