The text is very unclear about whether an entire LLDPDU should be discarded if the mandatory end of LLDPDU TLV is not present. The End Of LLDPDU TLV is considered a Mandatory TLV, but we appear to relax the discard rules if this TLV is missing as described in clause 9.2.7.7.1. There is some confusion created by the text in 6.6.1 and 8.2. Assuming it is our intent to accpet a frame that does not have an End of LLDPDU TLV, then we should consider the recommended changes. Another alternative is to make it clear that you must discard the LLDPDU if the End of LLDPDU TLV is not present, but this might have more impact on existing implementations, so I've chosen the hard road here.
The text in 6.6.1 states:
6.6.1 LLDPDU and TLV error handling
The LLDPDU is checked to ensure that it contains the correct sequence of mandatory TLVs and then each optional TLV is validated in succession. LLDPDUs and TLVs that contain detectable errors are discarded. TLVs that are not recognized, but that also contain no basic format errors, are assumed to be valid and are stored for possible later retrieval by network management (see 9.2.7.7.1 and 9.2.7.4).
The LLDPDUs that contain detectable errors are discarded statement would make one think you should chuck the frame and increment statsFramesDiscardedTotal, but there is no other specific rule for that in clause 9.2.7.7.1.
Also, the normative definition of the LLDPDU format says you must have the End of LLPDU TLV.
8.2 LLDPDU format
The LLDPDU shall contain the following ordered sequence of three mandatory TLVs followed by zero or more optional TLVs plus an End Of LLDPDU TLV, as shown in Figure 8-1:
a) Three mandatory TLVs shall be included at the beginning of each LLDPDU and shall be in the order shown.
1) Chassis ID TLV
2) Port ID TLV
3) Time To Live TLV
b) Optional TLVs as selected by network management (may be inserted in any order).
NOTE 1-"Optional" in the sense that they are not required for LLDP operation; however, their presence could be required by other system elements that use LLDP.
c) The End Of LLDPDU TLV shall be the last TLV in the LLDPDU.
Clearly the End of LLDPDU TLV shall be present in the frame on transmission. However, the definition of the counter doesn't say anything about incrementing the frame if the 4th mandatory TLV isn't present. In my opinion, it is our intention to salvage as much useful information as possible if the frame is otherwise good, but our rules should be more clear.
9.2.6.2 statsFramesDiscardedTotal
This counter provides a count of all LLDPDUs received and then discarded for any of the following reasons:
a) One or more of the three mandatory TLVs at the beginning of the LLDPDU is missing, out of order, or contains an out of range information string length.
b) There is insufficient space in the remote systems MIB to store the LLDPDU.
The detailed text that really describes how to validate a received frame is found in 9.2.7.7.1 and beyond. This is where we specifically indicate when the counters are supposed to be updated. Nowhere in this part of the text do we increment the statsFramesDiscardedTotal counter if the End of LLDPDU TLV is missing.
9.2.7.7.1 LLDPDU validation
The receive module processes each incoming LLDPDU as it is received. The statsFramesInTotal counter for the port is incremented and the LLDPDU is checked to verify the presence of the three mandatory TLVs at the beginning of the LLDPDU as defined in 8.2.
.... irrelevant items removed, so refer to the standard text ....
h) If the end of the LLDPDU has been reached, the MSAP identifier, rxTTL, and all validated TLVs are passed to the LLDP management entity for LLDP remote systems MIB updating.
So, I conclude you would not discard the frame or increment the counter because the detailed text for the state machine procedure does not tell you to. Also, this is one of those situations where we want to make sure people put the right info on the frame when sending it, but we will accept it anyway if it isn't present at reception.