I appear that I may have accidentally mis-represented the 802.3
position, apologies if that is the case, my comments were based on
on my recollection of one of the 802.3 YANG meetings. Possibly I
didn't get the gist of what had been discussed. Please see
further clarification inline ...
On 22/09/2017 19:49, Geoff Thompson
OK. It is really frame sizes up to approx 9216 (or higher, since
some hardware wants to handle 9K client frame size + any
encapsulation and tunneling overheads) that I am considering here.
in the 802.3 WG YANG alias)
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
The current value of frame size is 2000, not 1518, see
OK. But, the specific counters in question are not 802.3 counters.
802.3 has always accommodated larger frames and frame
sizes (even though significantly larger frames weaken the
CRC protection). See: 22.214.171.124.1a.
For the counters that you imagine, the appropriate
constant would be maxEnvelopeFrameSize, not
maxBasicFrameSize. See: 126.96.36.199. 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:
be broken by the presence of jumbo frames
include counters that would differentiate and count jumbo
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 !!
There are the counters defined in the RMON MIB, RFC 2819, which
AFAIK was never taken into 802.3 ownership:
The following counters are defined in RFC 2819:
So the issues that I am trying to allude to are:
(i) I don't think that there are any clause 30 registers that define
these counters, and I thought that we wanted all of the 802.3 YANG
to map to clause 30 registers?
(ii) Because the RMON registers end at 1518, then in my experience
what happens after 1518 has quite a lot of variance in
implementation. I have seen variance in different MAC ASICs in
different linecards for the same product line.
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
In my experience these hardware to count the RMON histogram counters
have been baked in the MAC ASIC and are fixed, perhaps some of the
hardware used FPGAs. For high speed linecards (e.g. 1+ Terabit/s),
I don't think that you can count any of these packets in software,
perhaps in the ucode.
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.
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
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.
I think that there are probably 3 sensible ways that this can be
1) Use fixed counters, as defined above, up to 1518 octets, and then
allow the implementation to define additional counters above this.
In this case I still think that it is useful to recommend particular
bucket sizes for the counters above 1518.
2) Define a full set of fixed counters (e.g. up to 10K octets), but
acknowledge that many hardware implementations that support jumbo
frames would not be able to populate these counters above 1518
octets because they don't match the buckets in the hardware. I
don't like this approach since I think that it will be incompatible
with a lot of existing hardware.
3) Define a generic structure that is list of entries, where each
entry contains (octet-range-min, octet-range-max, pkt-count). Then
in the description of the list say something like: Recommended
category ranges are 64-64, 65-127, 128-255, 256-511, 512-1023,
1024-1518, 1519-2047, 2048-4095, 4096-9215, 9216-max. And relate
back to the RFC 2819 historical set of counters etc.
From a software perspective, I prefer approach 3 over approach 1
because the code handling all the counters can be more generic.
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.
stats that I still see missing are:
traffic engineering scenarios we find them very
useful in understanding the network behavior.
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
Are there specific RMON counters that you think
should be included?
19/09/2017 22:11, Shemail, Ahmed wrote:
saw your draft for IEEE 802.3 Ethernet Interfaces
noticed that some of the RMON equivalent stats
have made into your draft but most others did not
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?
Shemail | Software
Engineer, PS&A | Ciena
ashemail@xxxxxxxxx | 5050
Innovation Drive | Ottawa, ON.
Direct +1.613.670.4649 | Fax