Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Ramin, If I understand what you are proposing I partially support it.
1) I support moving the position of EEEen and slow wake bits.
2) I support in principle of having vendor specific bits. But if I understand what you are proposing, it looks like you want to exchange another message after
the OAM, depth, precoder, etc message are exchanged. This I do not support as it just add complexity for no real reason.
How many vendor specific bits are really needed? I can’t imagine needing more than 8 bits.
If that is the case why don’t we define octet 8 to be vendor specific bits instead of reserved.
Let me know if you are ok with this modification. Thanks, William From: Ramin Farjad <Ramin.Farjad@xxxxxxxxxxxx> Colleagues, Please find attached our late comment on Vendor specific filed in the infofield exchange.
Thanks Ramin Page 141 149.4.2.4.5 PHY Capability Bits The format of PHY capability bits is Oct10<0> = OAMen, Oct10<2:1> = InterleaverDepth, Oct10<4:3> = PrecodeSel, Oct10<5> = SlowWakeRequest, Oct10<6> = EEEen and Oct10<7> = VendorSpecificMessage.
EEEen and OAMen indicate EEE and MultiGBASE-T1 OAM capability enable, respectively. The PHY shall indicate the sup-port of these two optional capabilities by setting the corresponding capability bits. When the VendorSpecificMessage bit is set to 1 then the
remaining 23 bits of the MSG24 field is vendor specific data. Otherwise when VendorSpecificMessage=0, the remaining bits shall be reserved and set to 0. Table 149–12a—PHY Capability Bits when VendorSpecificMessage=0
Table 149–12b—PHY Capability Bits when VendorSpecificMessage=1
To unsubscribe from the STDS-802-3-NGAUTO list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGAUTO&A=1 To unsubscribe from the STDS-802-3-NGAUTO list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGAUTO&A=1 |