The sFlow frame_length field isn't intended to be vague. If you are seeing non-conforming sFlow implementations, please raise the issue with the vendor so they can fix the issue.
Verifying that the frame_length and stripped fields are correctly implemented is one of the tests performed by the sFlow Test tool and running the tool can be helpful in persuading a vendor that they are out of compliance:
/* Raw Packet Header */
/* opaque = flow_data; enterprise = 0; format = 1 */
struct sampled_header {
header_protocol protocol; /* Format of sampled header */
unsigned int frame_length; /* Original length of packet before
sampling.
Note: For a layer 2 header_protocol,
length is total number of octets
of data received on the network
(excluding framing bits but
including FCS octets).
Hardware limitations may
prevent an exact reporting
of the underlying frame length,
but an agent should attempt to
be as accurate as possible. Any
octets added to the frame_length
to compensate for encapsulations
removed by the underlying hardware
must also be added to the stripped
count. */
v1.00 sFlow.org [Page 35]
FINAL sFlow Version 5 July 2004
unsigned int stripped; /* The number of octets removed from
the packet before extracting the
header<> octets. Trailing encapsulation
data corresponding to any leading
encapsulations that were stripped must
also be stripped. Trailing encapsulation
data for the outermost protocol layer
included in the sampled header must be
stripped.
In the case of a non-encapsulated 802.3
packet stripped >= 4 since VLAN tag
information might have been stripped off
in addition to the FCS.
Outer encapsulations that are ambiguous,
or not one of the standard header_protocol
must be stripped. */
opaque header<>; /* Header bytes */
}
To top it off, both the sFlow and IPFIX specs are sufficiently vague about the meaning of the "frame size", so vendors can implement whatever they want (include/exclude padding, include/exclude FCS). This implies that you shouldn't trust these fields.