Port auto negotiation high level design document

[Junchao-Mellanox]

Why I did this?

The IEEE 802.3 standard defines a set of Ethernet protocols that are comprised of speed rate and interface type. It allows for configuring multiple values at the same time for port provisioning and advertising to the remote side. However, on SONiC, user can configure the speed of port, and user can configure auto negotiation mode via config DB. Port attributes such as interface type, advertised speeds, advertised interface types are not supported.

The feature in this document is to address the above issues.

Related PRs:

PR title	state	context
[YANG] Enhance the port yang model with new port fields: adv_speeds, interface_type and adv_interface_types
[sonic-swss] Add port auto negotiation support to swss
Add test cases for port auto negotiation feature
[sonic-utilities] CLI support for port auto negotiation

[lguohan]

can you add link training into the requirement. enable/disable link training.

[Junchao-Mellanox]

Need collect information, and this will be added to phase 2.

[jeff-yin]

The interface type should be determined by the media that is plugged in (e.g., copper DAC, optical transceiver, etc.). Hence SONiC (i.e., xcvrd) should be able to dynamically set the interface type based on the detected media using the media_settings.json framework. That framework today is used to set pre-emphasis values, but it can/should be extended to perform other default settings such as interface type, FEC, auto-negotiation, etc.

This config could override what is defined in the platform's media_settings.json file, but care should be taken when the configured interface type differs from what is actually supported by the media (e.g., setting CR (copper type) for an optical transceiver).

[Junchao-Mellanox]

Hi @jeff-yin, thanks for the comments. As you mentioned, media_settings.json is used to set the pre-emphasis values for ports. And it handles it this way:

1. When xcvrd daemon start, it reads the media_setting.json and set pre-emphasis values to APPL_DB for each port
2. When a new cable is inserted, xcvrd will use the value in media_setting.json to set pre-emphasis value to APPL_DB for this port.

As xcvrd just reads the configuration from media_setting.json and set value to APPL_DB, xcvrd does not care what the configuration is. So if you want to use media_setting.json to specify the default value for autoneg, adv_speeds, fec and so on, nothing needs to be changed. However, there is something that user need to understand:

If we have autoneg, adv_speeds or other port configuration both in CONFIG_DB and media_settings.json, the value in media_settings.json will be used if user reboot switch, restart pmon docker or remove/insert the cable.

I suppose it means that, if user choose to configure port autoneg in media_settings.json, he/she should not configure port autoneg via CLI, or what he/she configured in CLI will lose effect after rebooting/restart pmon/re-insert SFP.

IMO, it is always good practice to use CLI/CONFIG_DB to configure port auto negotiation attributes. But user still got the option to use media_setings.json to configure them. I will add this discussion as a separate section to this design document.

[dgsudharsan]

Hi @jeff-yin, the problem i see with setting default based on standards in media_settings.json is it would break the backward compatibility. Currently SONiC is deployed with autoneg and media type not being set. Setting this automatically via media_settings.json would cause interop issues and in many cases the link will not even come up. Hence currently we can go with user configuration approach alone and later have discussion on how to implement based on standards

[lguohan]

can we show the cable interface type here?

[Junchao-Mellanox]

Hi @lguohan , could you please elaborate more about the "cable interface type" here? I guess maybe you are talking about the "type" column in the output of show interfaces status. And its value is usually something like "QSFP28 or later" or "QSFP+ or later". Or is it something in the SFP eeprom data:

Ethernet100: SFP EEPROM detected
        Application Advertisement: N/A
        Connector: No separable connector
        Encoding: 64B66B
        Extended Identifier: Power Class 3(2.5W max), CDR present in Rx Tx
        Extended RateSelect Compliance: QSFP+ Rate Select Version 1
        Identifier: QSFP28 or later
        Length Cable Assembly(m): 3
        Nominal Bit Rate(100Mbs): 255
        Specification compliance:
                Extended Specification compliance: 100G AOC (Active Optical Cable) or 25GAUI C2M AOC
        Vendor Date Code(YYYY-MM-DD Lot): 2019-02-15
        Vendor Name: Mellanox
        Vendor OUI: 00-02-c9
        Vendor PN: MFA1A00-C003
        Vendor Rev: B2
        Vendor SN: MT1907FT08074

Thanks.

[jleveque]

Looks good from my perspective. @lguohan: can you please review the responses to your comments and resolve if OK?

[lguohan]

as discussed in the sonic yang subgroup, all new hld will need sub pr to add yang model in src/sonic-yang-model, the hld approved is contingent on the approval of yang model pr.

[liat-grozovik]

as discussed in the sonic yang subgroup, all new hld will need sub pr to add yang model in src/sonic-yang-model, the hld approved is contingent on the approval of yang model pr.

Please check sonic-net/sonic-buildimage#6948

[liat-grozovik]

@dgsudharsan, @jeff-yin and @praveen-li any further comments or can we approve the HLD?
the PRs should be ready soon for review as well and better to agree on the HLD befor ethat.

[jeff-yin]

@liat-grozovik @Junchao-Mellanox -- no further comments since we reviewed the doc in the community and that was my only question from the review. Implicit approval from my side (I don't have a review/approve button here).

[Junchao-Mellanox]

Hi @lguohan, the yang model PR has been merged, could you please let me know if there is any further comment on this PR? Thanks.