[Adding in the 802.3 WG YANG alias)
Ah yes, OK.
So, there are 3 problems with this set of counters:
(i) To be properly useful they should include categories above 1518 octets, but 802.3 doesn't formally acknowledge the existence of Ethernet frames bigger than 1518 octets.
The current value of frame size is 2000, not 1518, see below.
802.3 has always accommodated larger frames and frame sizes (even though significantly larger frames weaken the CRC protection). See: 18.104.22.168.1a.
For the counters that you imagine, the appropriate constant would be maxEnvelopeFrameSize, not maxBasicFrameSize. See: 22.214.171.124. This was done to accommodate 802.1 VLAN Tags and 802.1 Encryption.
But having said that, 802.3 in general and 802.3 management projects (the early ones at least that defined the foundational material) have always been careful to not only "not break" jumbo frames, but to go beyond that and accommodate jumbo frames. All of the clause 30 basic counter definitions were VERY carefully designed to:
- not be broken by the presence of jumbo frames
- include counters that would differentiate and count jumbo frame traffic
It would be a terrible misteak to not have all of the same counters we have had in earlier 802.3 management or to have different behavior definitions for them. I was assured at the start of the YANG project that WOULD NOT HAPPEN !!
(ii) These counters are normally implemented in hardware,
That is a rash assumption. Many are hybrid implementations where only the low order portion of the counter is in hardware
and once you get above 1518 octets different hardware implementations do different things, so retrospectively applying standard values seems unfriendly ;-)
(iii) 802.3 only wants to standardize Ethernet YANG that can be mapped to the internal 802.3 management API, i.e. stuff that all implementations can reasonably be expected to support.
When this was last discussed in an 802.3 meeting the recommendation is that they get standardized in IETF instead (somewhat sidestepping the jumbo frame concern) in a more generic way. I think that I have the action of following up on this, but I may have dropped the ball.
I.e. the idea was to use a list of the octet ranges, with a description recommending some standard ranges to use up to 1518, but leaving it to the devices to report the specific ranges supported by their hardware.
No. Use the existing standardized counters and behaviors which already cover the different ranges of sizes.
On 20/09/2017 14:56, Shemail, Ahmed wrote:
Thanks for the prompt response. I found your spreadsheet attachment quite useful to understand the thought process behind the current set of stats.
Some RMON stats that I still see missing are: etherStatsPkts65to127Octets etherStatsPkts128to255Octets etherStatsPkts256to511Octets etherStatsPkts512to1023Octets etherStatsPkts1024to1518Octets
In some traffic engineering scenarios we find them very useful in understanding the network behavior.
I think that plan is that all the stats that are still relevant to Ethernet interfaces today should have been copied across. There is also the "legacy" YANG module that contains some of the Etherlike MIB stats that we think are no longer required.
Please also see the attached xls that shows the relationship between the counters, various MIBs/YANG modules etc.
Are there specific RMON counters that you think should be included?
On 19/09/2017 22:11, Shemail, Ahmed wrote:
I saw your draft for IEEE 802.3 Ethernet Interfaces YANG model
I noticed that some of the RMON equivalent stats have made into your draft but most others did not make it.
What is your view on the rest of the RMON stats? DO you think some of them will be incorporated in future extensions or do you think we won’t need them?
Ahmed Shemail | Software Engineer, PS&A | Ciena
ashemail@xxxxxxxxx | 5050 Innovation Drive | Ottawa, ON. Canada
Direct +1.613.670.4649 | Fax +1.613.599.6530