[8023-POEP] Draft 3.1 - Loss of Communication
Colleagues
This is an attempt
to fix Section 33.7. There are a lot of inconsistencies with the topic "Loss of
Communication". There are also multiple comments dealing with loss of
communication.
Here are
the issues that have been pointed out
1) One of the
scenarios that lead to loss of communication is when "Management frame
communication" is not established after power-on. Loss of communication cannot
happen if communication has not been established to begin
with.
2) The section
speaks about updating MIB variables directly. I think the convention that we
follow is that the system sets state variables. The state variables in-turn map
into MIB variables. Atleast this is the convention that has been followed in
Section 33.6.6.2
3) Multiple senior
members feel that power-cycling the PD when LLDP TTL expires might be too
drastic a step. We had one comment during the last review cycle and we have at
least 3 late comments dealing with this. The recommendation is to get rid
of the option to power-cycle the PD based on expiration of TTL timers. The
decision to power-cycle must be left to the higher layer protocols/software. We
have an umbrella statement that permits the PSE to power-cycle the PD at any
time.
4) There might not
be a lot of value in sending the Loss of communication information in the TLV
between the systems. The PD cannot do much with this information. The PSE could
choose to take action if the PD indicates that it has lost communication with
the PSE. Not sure how probable is the situation where the link from PD to PSE is
working but the link from the PSE to PD is not working. This condition can be
detected by the PSE if the PD does not mirror the values back and this
condition persists for a long time. We could do away with the "Loss of
communication" field in the TLV and make it simpler. We have a couple
of late comments that deal with this.
5) The aLostCommunication MIB
variables are defined as counters but used as Boolean in section
33.6.6.2
I have attached a
proposed comprehensive fix for the issues mentioned above. Please go through it
and let me know if you have any feedback. If we adopt this then we end up
resolving the following comments:
# 145, Late # 10,
Late # 5, Late # 16, Late # 12, Late # 2, Late # 9, Late # 8, Late
# 11
Please treat this as
the contribution against my comment # 145
Thanks
Anoop
Attachment:
vetteth_loss_comms.pdf
Description: vetteth_loss_comms.pdf