Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [802.3_YANG] RMON equivalent stats in 802.3 Ethernet Interface YANG model



Hi Geoff,

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 wrote:
Robert-

On Sep 22, 2017, at 3:51 AMPDT, Robert Wilton <rwilton@xxxxxxxxx> wrote:

[Adding in the 802.3 WG YANG alias)

Hi Ahmed,

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.

Not true.
The current value of frame size is 2000, not 1518, see below.
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.


802.3 has always accommodated larger frames and frame sizes (even though significantly larger frames weaken the CRC protection). See: 4.2.4.2.1a.
For the counters that you imagine, the appropriate constant would be maxEnvelopeFrameSize, not maxBasicFrameSize.  See: 4.2.7.1.  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 !!
OK.  But, the specific counters in question are not 802.3 counters.

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:
     etherStatsPkts64Octets             Counter32,
     etherStatsPkts65to127Octets        Counter32,
     etherStatsPkts128to255Octets       Counter32,
     etherStatsPkts256to511Octets       Counter32,
     etherStatsPkts512to1023Octets      Counter32,
     etherStatsPkts1024to1518Octets     Counter32,

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.


(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
OK.

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.


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.

I think that there are probably 3 sensible ways that this can be implemented:

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.

Thanks,
Rob


Regards,

Geoff Thompson

Thanks,
Rob





On 20/09/2017 14:56, Shemail, Ahmed wrote:
Hi Rob,
 
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:
     etherStatsPkts64Octets
     etherStatsPkts65to127Octets
     etherStatsPkts128to255Octets
     etherStatsPkts256to511Octets
     etherStatsPkts512to1023Octets
     etherStatsPkts1024to1518Octets
 
In some traffic engineering scenarios we find them very useful in understanding the network behavior.
 
Regards,
Ahmed 
 
From: Robert Wilton [mailto:rwilton@xxxxxxxxx] 
Sent: Wednesday, September 20, 2017 6:16 AM
To: Shemail, Ahmed <ashemail@xxxxxxxxx>
Subject: Re: RMON equivalent stats in 802.3 Ethernet Interface YANG model
 

Hi Ahmed,

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?

Thanks,
Rob

On 19/09/2017 22:11, Shemail, Ahmed wrote:
Hi Robert,
 
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?
 
Regards,
 
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