Dear colleagues, I completed the review of two of my action items and generated comments as follows Technical | Yes | 389 | 14.4.11.2 | 16 | This comment addresses Action Item #35, i.e., "What happens when aPoeStatus is set to enabled, but the UNI does not support the PoE function? Need to support querying the ONU capability separately in addition to enabling/disabling the feature." | As defined today, attribute aPoeStatus (0xDB/0x08-21) is defined as a R/W attribute, which allows the NMS (via OLT) to query the status or set the status of the PoE function. As such, it does read a bit in an odd manner, specifically when considering the existing values: enabled/disabled, which are more of a status (read operation) then the state change (write operation). There a number of changes that should be done to this attribute to improved its definition - see tf4_2108_hajduczenia_01.pdf for details, specifically:
- convert the existing attribute into a R/O mechanism to read the status of the PoE function on the given UNI port, including the addition of a new return value of "not_supported" to cover the cases where PoE is not supported.
- create a new action to set the PoE function on the given UNI port, with clear information that the attempt to enable the PoE on a port will cause the ONU to simply ignore the request - there is no need to raise any alarms. The OLT may as well read the status again and confirm whether the PoE was enabled or not, if the OLT chooses to perform an action without checking the capability of the given port to begin with. | Technical | Yes | 389 | 14.4.11.1 | 1 | This comment addresses Action Item #34, i.e., "What happens when aEeeStatus is set to enabled, but the UNI does not support the EEE function? Need to support querying the ONU capability separately in addition to enabling/disabling the feature." | As defined today, attribute aEeeStatus (0xDB/0x08-20) is defined as a R/W attribute, which allows the NMS (via OLT) to query the status or set the status of the EEE function. As such, it does read a bit in an odd manner, specifically when considering the existing values: enabled/disabled, which are more of a status (read operation) then the state change (write operation). There a number of changes that should be done to this attribute to improved its definition - see tf4_2108_hajduczenia_02.pdf for details, specifically:
- convert the existing attribute into a R/O mechanism to read the status of the EEE function on the given UNI port, including the addition of a new return value of "not_supported" to cover the cases where EEE is not supported.
- create a new action to set the PoE function on the given UNI port, with clear information that the attempt to enable the EEE on a port will cause the ONU to simply ignore the request - there is no need to raise any alarms. The OLT may as well read the status again and confirm whether the EEE was enabled or not, if the OLT chooses to perform an action without checking the capability of the given port to begin with. |
The tow contributions references in the description are attached for reference. In my mind, the proposed changes address the issues with existing attributes and allow for the target behavior we need, i.e., poll interface status for the given feature and then toggle it, as needed, using the newly defined action. Any comments / feedback would be appreciated Marek
To unsubscribe from the STDS-1904-4-TF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-4-TF&A=1 |