Adding Commit Upload Rate Field to Circuit Model

[Atomicbeast101]

NetBox version

v4.5.4

Feature type

Data model extension

Proposed functionality

Changes to make to include Commit Upload Rate field:

• Update Circuit Model class to include commit_upload_rate.
• Update CircuitTable Table class to include commit_upload_rate.
• Update following Form classes to include commit_upload_rate (reuse CircuitCommitRateChoices for NumberWithOptions widget options):
  • CircuitForm
  • CircuitFilterForm
  • CircuitBulkEditForm
  • CircuitImportForm
• Update CircuitSerializer Serializer class to include commit_upload_rate.
• Update CircuitFilterSet FilterSet's Meta class to include commit_upload_rate field.
• Update CircuitFilter model in GraphQL to include commit_upload_rate.

Outside of core changes, there's some changes to make for testing:

• Update CircuitTestCase Views class to include commit_upload_rate.
• Update CircuitTestCase FilterSet class to include commit_upload_rate.

There was a previous request for this but it hasn't been responded by requester so it got closed with no action. Hence why I'm submitting another one that follows the standard practice.

Use case

Having a built-in commit upload rate field for Circuit table will make it easier for companies that have a process where they have port and access speeds (port being the max supported bandwidth it provides and access being the actual bandwidth configured to use; gives flexibility for increasing bandwidth without having to replace the circuit). Circuit Termination has both download and upload fields while Circuit doesn't, so it seems to make sense to include the missing upload field there.

Plus, the other reason is with big companies that uses SDWAN technology, they would have a mix of MPLS/Internet/LTE/Broadband connections that wouldn't have symmetrical speeds to provide diversity to sites to help reduce network outages.

Custom field could be used for tracking the upload commit rate, however, it would show the commit rate value automatically converted to human-friendly (1Gbps or 10Mbps, for example) while the custom field's upload rate would show the full value in Kbps.

Database changes

Adding a new field called Commit Upload Rate (Kbps) (commit_upload_rate) to Circuit model and setting order to appear below existing Commit Rate (Kbps) (commit_rate) field.

External dependencies

N/A

[jeremystretch]

Why is the existing upstream_speed attribute on a circuit termination not sufficient for this purpose? Additionally, a circuit itself has no inherent orientation regarding upstream/downstream, so it would not be clear to which direction the attribute applies.

[Atomicbeast101]

Why is the existing upstream_speed attribute on a circuit termination not sufficient for this purpose? Additionally, a circuit itself has no inherent orientation regarding upstream/downstream, so it would not be clear to which direction the attribute applies.

Some companies have a thing called port and access speeds. Port is the bandwidth that it's capable of going up to based on hardware limitations while access is the actual bandwidth that is set for use. I figured the port bandwidth details being stored in Circuits table would make sense as it contains info about what capabilities that particular circuit can do.

[zndrr]

Would benefit from this also. We generally have wholesale circuits delivered with prescribed asymmetric bandwidth (download/upload), and are often independent of our own configured bandwidth; which we represent on the circuit-terminations and/or interfaces.

As we need to capture this asymmetry, we're using a custom field on circuit. Adding a "commit_upload_rate" native field would allow us to capture up/down natively.

[pheus]

I agree with the point already raised that Circuit has no inherent direction. Because of that, adding commit_upload_rate at the circuit level would force users to infer which value represents upstream vs. downstream, and we generally should not build that kind of ambiguity into the core model.

For asymmetric services, CircuitTermination is the better fit because it already provides directional fields such as port_speed and upstream_speed. And if a connected interface is intentionally operating at a speed different from its physical type, that should be documented on the interface itself.

[zndrr]

Appreciate the input. I do however respectfully disagree. Sold circuits do often inherently have a direction and that exhibits in asymmetric bandwidth characteristics. GPON/FttH/DSL circuits are examples of this. Often Cable (coax) as well.
Their API's and/or specsheets generally provide said bandwidth characteristics, so it is defined in the product sold.

We won't configure CircuitTermination until our endpoints are determined, since they're not yet ready for network configuration. We also often define termination bandwidth independent of what is sold to us to avoid shaping quirks with our upstreams.

commit_rate already exists, so I don't think it a stretch to consider another field to capture the directions when they aren't symmetric in nature.
Am rather passionate about this, as it would lead to better UX for us. Native and CustomFields don't group together on pages.

As an aside, if something similar to ModuleTypeProfile, existed for Circuit (CircuitTypeProfile / CircuitProfile?), this would also solve many issues for us. Our circuits can often be generalised in to "CircuitPlans" as dictated by our providers, which include templatised bandwidth characteristics. Pushing boundaries here now though, sorry.

[pheus]

Thanks for taking the time to explain your workflow. I think the disconnect here is that I’m referring specifically to the current NetBox Circuit model, not to whether real-world services can be asymmetric. I fully agree that many provider circuits are sold with distinct upstream/downstream characteristics.

My concern is that, as already pointed out above, the NetBox Circuit object itself has no inherent traffic direction. A and Z identify the two ends of the circuit, but they do not mean upstream and downstream. Because of that, adding commit_upload_rate to Circuit would still leave the model ambiguous: upload relative to which end?

I understand that your workflow may defer creating CircuitTermination objects until endpoints are known. However, to me that points to a broader workflow or modeling need rather than a good fit for making the core Circuit model directional. A termination can already be created without attaching an interface, and the circuit status can be used to indicate that it is not yet ready for use.

Likewise, if the actual configured bandwidth differs from what was sold by the provider, I would expect that to be documented on the relevant interface rather than on the circuit itself.

At this stage, I think this has moved beyond implementation details for this FR and into broader model design. For that reason, I’d be inclined to close this request as not a fit for the current Circuit model. If there’s interest in exploring something larger (for example circuit plans/profiles or pre-termination service characteristics) a GitHub Discussion would be the better place to work through that and, if needed, come back later with a more complete proposal.

[jeremystretch]

I agree with @pheus . The existing port_speed and upstream_speed fields on the CircuitTermination model exist to serve this purpose, and accurately convey direction as context. Adding these to the Circuit model wouldn't make sense.