Post by malbolge on Sept 27, 2024 16:12:48 GMT
Problem statement
There is a set of properties defined in the standard DMTF Port Schema related to port speed and negotiation thereof. These are:
- AutoSpeedNegotiationEnabled
- AutoSpeedNegotiationCapable
- CapableLinkSpeedGbps
- ConfiguredSpeedGbps
- CurrentSpeedGbps
This thread is meant to clearly define how they interact and what they mean.
Main questions are:
1. Are Port properties AutoSpeedNegotiationEnabled and AutoSpeedNegotiationCapable reductionist in that they describe/control the status of autonegotiation using "whatever means are available", or or do they have a specific meaning in respect to standards like 802.* Clause 28, 37 and 73?
2. Is ‘AutoSpeedNegotiationEnabled = 1’ the exclusive product of ConfiguredSpeedGbps containing more than one speed?
Current state:
From redfish.dmtf.org/schemas/v1/Port.v1_13_0.json:
The schema descriptors of Port properties AutoSpeedNegotiationEnabled and AutoSpeedNegotiationCapable do not mention standards defined for autonegotiation on Base-T.
Autonegotiation known as a standard described in IEEE802.3 is a feature that allows to negotiate link parameters between link partners. These parameters are not only speed but also Link flow control and duplex mode. There are standards like Clause 28, 37 and 73 defined for Base-T.
Assumptions:
1) AutoSpeedNegotiationEnabled=TRUE && LEN(ConfiguredLinksGbps)>1 is invalid.
2) AutoSpeedNegotiationEnabled=FALSE && LEN(ConfiguredLinksGbps)<=1 is invalid.
Conflict between AutoSpeedNegotiationEnabled and ConfiguredNetworkLinks
Whether a device will negotiate speed can be controlled through two properties in Port schema. AutoSpeedNegotiationEnabled (explicitly) and ConfiguredNetworkLinks (implicitly). When the device supports ConfiguredNetworkLinks, enabling AutoSpeedNegotiationEnabled will not supply the speeds which the adapter should auto-negotiate on. To achieve consistent schema behavior only one of these control methods can be used by the device.
Proposal:
Add the following to AutoSpeedNegotiationEnabled
Add the following to AutoSpeedNegotiationCapable
Rationale:
The Port schema shall allow two ways of enabling autonegotiation - either through specifying the set of allowed speeds in ConfiguredLinksGbps, or for devices that do not allow explicit speed selection through the broader AutoSpeedNegotiationEnabled. Both mechanisms cannot be used at the same time.
Why not have both at the same time?
Imagine a device is configured to a single speed, AutoSpeedNegotiationEnabled is false. The user sets autoneg to true. But the device will only negotiate one speed. So it either has to arbitrarily select some other speed, or reject the write. Conversely, if two speeds are selected and the user sets autoneg to false, the device has to remove a speed or reject the write. If the device rejects the write in both cases, the device is effectively RO.
There is a set of properties defined in the standard DMTF Port Schema related to port speed and negotiation thereof. These are:
- AutoSpeedNegotiationEnabled
- AutoSpeedNegotiationCapable
- CapableLinkSpeedGbps
- ConfiguredSpeedGbps
- CurrentSpeedGbps
This thread is meant to clearly define how they interact and what they mean.
Main questions are:
1. Are Port properties AutoSpeedNegotiationEnabled and AutoSpeedNegotiationCapable reductionist in that they describe/control the status of autonegotiation using "whatever means are available", or or do they have a specific meaning in respect to standards like 802.* Clause 28, 37 and 73?
2. Is ‘AutoSpeedNegotiationEnabled = 1’ the exclusive product of ConfiguredSpeedGbps containing more than one speed?
Current state:
From redfish.dmtf.org/schemas/v1/Port.v1_13_0.json:
"AutoSpeedNegotiationEnabled": {
"description": "Controls whether this port is configured to enable autonegotiating speed.",
"longDescription": "This property shall indicate whether the port is configured to autonegotiate speed.",
…
},
"AutoSpeedNegotiationCapable": {
"description": "An indication of whether the port is capable of autonegotiating speed.",
"longDescription": "This property shall indicate whether the port is capable of autonegotiating speed.",
…
},
"CapableLinkSpeedGbps": {
"description": "The set of link speed capabilities of this port.",
…
"longDescription": "This property shall contain all of the possible network link speed capabilities of this port.
This value includes overhead associated with the protocol.",
…
},
"ConfiguredNetworkLinks": {
"description": "The set of link speed and width pairs this port is configured to use for autonegotiation.",
…
},
"longDescription": "This property shall contain the set of link speed and width pairs to which this port is restricted for autonegotiation purposes.",
…
}
"description": "Controls whether this port is configured to enable autonegotiating speed.",
"longDescription": "This property shall indicate whether the port is configured to autonegotiate speed.",
…
},
"AutoSpeedNegotiationCapable": {
"description": "An indication of whether the port is capable of autonegotiating speed.",
"longDescription": "This property shall indicate whether the port is capable of autonegotiating speed.",
…
},
"CapableLinkSpeedGbps": {
"description": "The set of link speed capabilities of this port.",
…
"longDescription": "This property shall contain all of the possible network link speed capabilities of this port.
This value includes overhead associated with the protocol.",
…
},
"ConfiguredNetworkLinks": {
"description": "The set of link speed and width pairs this port is configured to use for autonegotiation.",
…
},
"longDescription": "This property shall contain the set of link speed and width pairs to which this port is restricted for autonegotiation purposes.",
…
}
The schema descriptors of Port properties AutoSpeedNegotiationEnabled and AutoSpeedNegotiationCapable do not mention standards defined for autonegotiation on Base-T.
Autonegotiation known as a standard described in IEEE802.3 is a feature that allows to negotiate link parameters between link partners. These parameters are not only speed but also Link flow control and duplex mode. There are standards like Clause 28, 37 and 73 defined for Base-T.
Assumptions:
1) AutoSpeedNegotiationEnabled=TRUE && LEN(ConfiguredLinksGbps)>1 is invalid.
2) AutoSpeedNegotiationEnabled=FALSE && LEN(ConfiguredLinksGbps)<=1 is invalid.
Conflict between AutoSpeedNegotiationEnabled and ConfiguredNetworkLinks
Whether a device will negotiate speed can be controlled through two properties in Port schema. AutoSpeedNegotiationEnabled (explicitly) and ConfiguredNetworkLinks (implicitly). When the device supports ConfiguredNetworkLinks, enabling AutoSpeedNegotiationEnabled will not supply the speeds which the adapter should auto-negotiate on. To achieve consistent schema behavior only one of these control methods can be used by the device.
Proposal:
Add the following to AutoSpeedNegotiationEnabled
On devices that support writes to ConfiguredLinksGbps, this field shall be read-only.
Add the following to AutoSpeedNegotiationCapable
This property describes whether the device will auto-negotiate speeds using whatever means it supports, but does not necessarily correspond to any single 802.x or other auto-negotiation standard.
Rationale:
The Port schema shall allow two ways of enabling autonegotiation - either through specifying the set of allowed speeds in ConfiguredLinksGbps, or for devices that do not allow explicit speed selection through the broader AutoSpeedNegotiationEnabled. Both mechanisms cannot be used at the same time.
Why not have both at the same time?
Imagine a device is configured to a single speed, AutoSpeedNegotiationEnabled is false. The user sets autoneg to true. But the device will only negotiate one speed. So it either has to arbitrarily select some other speed, or reject the write. Conversely, if two speeds are selected and the user sets autoneg to false, the device has to remove a speed or reject the write. If the device rejects the write in both cases, the device is effectively RO.
