ols-909-autoneg-port-draft

[binnyjeshan]

Refer https://telecominfraproject.atlassian.net/browse/OLS-909

This will be one item for enhancement in Sprint-17, December OLS 4.2.

Currently there is no way that OLS can configure Port Speed As Auto.
If the Speed attribute is not sent on the config, its considered an exception, rather than assuming as default.
Its proposed to add a parameter called auto negotiation, so that the Speed & Duplex settings take effect when Speed is not auto-negotiated, but forced through that settings.

For a physical interface schema, auto negotiation is a fundamental attribute, because:

1. It determines whether speed/duplex are negotiated with the link partner.
2. If autoneg is enabled, the speed and duplex properties typically must not be forced (or must be ignored).
3. Many switch chips implement autoneg differently across copper vs fiber ports.

Currently since we only send Speed and Duplex, some switches keep Auto Negotiation always ON.

[mikehansen1970]

I may be mistaken but I think this was already discussed?
I had thought it would work as follows:
If speed is set then the assumption is auto negotiation is 'false' and the requested speed is forced
If speed is not set (this would be the change, allowing it to not be set) then auto negotiation is implicitly true.
To me the attribute itself seems superfluous.

[binnyjeshan]

I may be mistaken but I think this was already discussed? I had thought it would work as follows: If speed is set then the assumption is auto negotiation is 'false' and the requested speed is forced If speed is not set (this would be the change, allowing it to not be set) then auto negotiation is implicitly true. To me the attribute itself seems superfluous.

Hi @mikehansen1970

yes this is what we discussed and spoke about in an OLS Dev call 3 weeks ago.

Yesterday i had a discussion with @phwhite , and he believes adding a separate parameter would be the best way forward.

Hence i had raised this adding him in review.

Let us discuss here and close.

[phwhite]

I may be mistaken but I think this was already discussed? I had thought it would work as follows: If speed is set then the assumption is auto negotiation is 'false' and the requested speed is forced If speed is not set (this would be the change, allowing it to not be set) then auto negotiation is implicitly true. To me the attribute itself seems superfluous.

Hi @mikehansen1970

yes this is what we discussed and spoke about in an OLS Dev call 3 weeks ago.

Yesterday i had a discussion with @phwhite , and he believes adding a separate parameter would be the best way forward.

Hence i had raised this adding him in review.

Let us discuss here and close.

Hi @mikehansen1970 I have proposed to add a new parameter to maintain forward/backward compatibility, otherwise rolling out support for this would be challenging. I also think it's nice to have the ability to keep auto_neg enabled, but limit the advertised speed for debugging/troubleshooting purposes.

By having a new parameter, the original behavior is left as default and if the cloud wants to disable auto negotiation, it would provide the new parameter with a value of false.

Any specific concerns with this approach we should consider?

[mikehansen1970]

I may be mistaken but I think this was already discussed? I had thought it would work as follows: If speed is set then the assumption is auto negotiation is 'false' and the requested speed is forced If speed is not set (this would be the change, allowing it to not be set) then auto negotiation is implicitly true. To me the attribute itself seems superfluous.

Hi @mikehansen1970
yes this is what we discussed and spoke about in an OLS Dev call 3 weeks ago.
Yesterday i had a discussion with @phwhite , and he believes adding a separate parameter would be the best way forward.
Hence i had raised this adding him in review.
Let us discuss here and close.

Hi @mikehansen1970 I have proposed to add a new parameter to maintain forward/backward compatibility, otherwise rolling out support for this would be challenging. I also think it's nice to have the ability to keep auto_neg enabled, but limit the advertised speed for debugging/troubleshooting purposes.

By having a new parameter, the original behavior is left as default and if the cloud wants to disable auto negotiation, it would provide the new parameter with a value of false.

Any specific concerns with this approach we should consider?

Hi @phwhite

I don't understand the forward/backward compatibility aspect, unless you mean the fact that the client as currently written requires a speed setting?
That should probably be changed anyway, it's been somewhat cumbersome from the get go. If ODMs have cloned their own local versions of the client, they should change those if they don't pickup changes from the repository. This should then be part of release 4.2?
Should this cause confusion as to whether the speed should/shouldn't be sent it could probably be resolved by an addition to the capabilities denoting auto-negotiation supported, which would mean for that switch version if you don't send speed that's what you get?
To me the 2 values doesn't make a lot of sense, it was bad enough having to send speed. However it seems I am alone in this opinion and it's not that important to me, so I will just agree to disagree and leave it at that.

[phwhite]

Hi @phwhite

I don't understand the forward/backward compatibility aspect, unless you mean the fact that the client as currently written requires a speed setting? That should probably be changed anyway, it's been somewhat cumbersome from the get go. If ODMs have cloned their own local versions of the client, they should change those if they don't pickup changes from the repository. This should then be part of release 4.2? Should this cause confusion as to whether the speed should/shouldn't be sent it could probably be resolved by an addition to the capabilities denoting auto-negotiation supported, which would mean for that switch version if you don't send speed that's what you get? To me the 2 values doesn't make a lot of sense, it was bad enough having to send speed. However it seems I am alone in this opinion and it's not that important to me, so I will just agree to disagree and leave it at that.

Hi @mikehansen1970,

I’m referring to forward/backward compatibility in the cloud, at least for Shasta. We have multiple customer deployments, and today we avoid tailoring config pushes based on specific switch models or firmware versions. Coordinating switch firmware rollout alongside cloud updates would be extremely difficult. A couple of examples:

• If we update the cloud first: it would start omitting speed/duplex for switches where auto-neg should be enabled (which is the case for 99% of our deployments). This would fail schema validation on switches running existing firmware — including those just pulled from shelf stock.
• If we update the switch first: the switch would disable auto-neg and enforce the speed/duplex values that are currently being pushed by the cloud, again affecting most deployments — until the cloud logic is updated.

Either sequence results in breakage. This is exactly the kind of situation we’re trying to avoid — conditionals like “if this model and firmware, then do X” end up messy and fragile long-term.

Adding a new field with a sane default gives us a way to support auto-negotiation cleanly without impacting existing configs or workflows.

Hope that helps clarify the reasoning behind the request — and I want to be sure the community is aligned and comfortable with this direction.

Thanks,
Paul

[mikehansen1970]

Hi @phwhite
I don't understand the forward/backward compatibility aspect, unless you mean the fact that the client as currently written requires a speed setting? That should probably be changed anyway, it's been somewhat cumbersome from the get go. If ODMs have cloned their own local versions of the client, they should change those if they don't pickup changes from the repository. This should then be part of release 4.2? Should this cause confusion as to whether the speed should/shouldn't be sent it could probably be resolved by an addition to the capabilities denoting auto-negotiation supported, which would mean for that switch version if you don't send speed that's what you get? To me the 2 values doesn't make a lot of sense, it was bad enough having to send speed. However it seems I am alone in this opinion and it's not that important to me, so I will just agree to disagree and leave it at that.

Hi @mikehansen1970,

I’m referring to forward/backward compatibility in the cloud, at least for Shasta. We have multiple customer deployments, and today we avoid tailoring config pushes based on specific switch models or firmware versions. Coordinating switch firmware rollout alongside cloud updates would be extremely difficult. A couple of examples:

• If we update the cloud first: it would start omitting speed/duplex for switches where auto-neg should be enabled (which is the case for 99% of our deployments). This would fail schema validation on switches running existing firmware — including those just pulled from shelf stock.
• If we update the switch first: the switch would disable auto-neg and enforce the speed/duplex values that are currently being pushed by the cloud, again affecting most deployments — until the cloud logic is updated.

Either sequence results in breakage. This is exactly the kind of situation we’re trying to avoid — conditionals like “if this model and firmware, then do X” end up messy and fragile long-term.

Adding a new field with a sane default gives us a way to support auto-negotiation cleanly without impacting existing configs or workflows.

Hope that helps clarify the reasoning behind the request — and I want to be sure the community is aligned and comfortable with this direction.

Thanks, Paul

Hi @phwhite ,
I understand. I too am familiar with the challenges with switches and cloud and I can see in my mind the potential for having broken configurations in the absence of handling version based configurations.
I guess we kind of have to make the best of it, perhaps this is the way to do that.
After we get a little further along release wise perhaps we can consider a 'default' value if it is not passed in, once we are past the hump where some switches would still be expecting speed values..
Thanks,
Mike