starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Add Service Parameters to Virtual Circuit model #10631

New Issue
Open
opened 2025-12-29 21:33:55 +01:00 by adam · 5 comments
adam commented 2025-12-29 21:33:55 +01:00
Owner
Copy Link

Originally created by @sleepinggenius2 on GitHub (Jan 9, 2025).

NetBox version

v4.2.1

Feature type

Data model extension

Triage priority

N/A

Proposed functionality

Add the fields from the "Service Parameters" section of the Circuit model to the Virtual Circuit model as well. This includes the Installed, Terminates, and Commit rate (Kbps) fields. Opening this separate FR as requested in #18153.

Use case

The "Service Parameters" fields from the Circuit model are critical to be on the Virtual Circuit model, as well as the Circuit model, in order to document real world circuits. When establishing an ENNI with another operator, that would be represented as a Circuit, with associated dates and commit rate (line rate). At the same time, or at later times, OVCs could then be ordered that use that ENNI, each with their own dates and commit rate (policed), which would be represented as Virtual Circuits. A similar situation could occur with a UNI represented as a Circuit and VLAN-based EVCs (EVP-Line, EVP-LAN, EVP-Tree) represented as Virtual Circuits.

Those are probably some of the most common scenarios the majority of the NetBox customer base will encounter. In an ISP network, we also see a number of other scenarios. One is L1VCs with L1 ENNIs that could end up in the same situation, if the ODU signal is being multiplexed on the handoff. You could represent the OTU as a Circuit and the lower order ODUs as Virtual Circuits, even the higher order ODU as a Virtual Circuit, if you want. Another is SONET/TDM services that are multiplexed on a handoff, most commonly seen with M13 muxes handing off a T3/DS3 (Circuit) with multiple DS1s (Virtual Circuits) riding on it.

Database changes

Add Installed, Terminates, and Commit rate (Kbps) fields to the Virtual Circuit model, matching the existing fields from the Circuit model.

External dependencies

None

Originally created by @sleepinggenius2 on GitHub (Jan 9, 2025). ### NetBox version v4.2.1 ### Feature type Data model extension ### Triage priority N/A ### Proposed functionality Add the fields from the "Service Parameters" section of the Circuit model to the Virtual Circuit model as well. This includes the `Installed`, `Terminates`, and `Commit rate (Kbps)` fields. Opening this separate FR as requested in #18153. ### Use case The "Service Parameters" fields from the Circuit model are critical to be on the Virtual Circuit model, as well as the Circuit model, in order to document real world circuits. When establishing an ENNI with another operator, that would be represented as a Circuit, with associated dates and commit rate (line rate). At the same time, or at later times, OVCs could then be ordered that use that ENNI, each with their own dates and commit rate (policed), which would be represented as Virtual Circuits. A similar situation could occur with a UNI represented as a Circuit and VLAN-based EVCs (EVP-Line, EVP-LAN, EVP-Tree) represented as Virtual Circuits. Those are probably some of the most common scenarios the majority of the NetBox customer base will encounter. In an ISP network, we also see a number of other scenarios. One is L1VCs with L1 ENNIs that could end up in the same situation, if the ODU signal is being multiplexed on the handoff. You could represent the OTU as a Circuit and the lower order ODUs as Virtual Circuits, even the higher order ODU as a Virtual Circuit, if you want. Another is SONET/TDM services that are multiplexed on a handoff, most commonly seen with M13 muxes handing off a T3/DS3 (Circuit) with multiple DS1s (Virtual Circuits) riding on it. ### Database changes Add `Installed`, `Terminates`, and `Commit rate (Kbps)` fields to the Virtual Circuit model, matching the existing fields from the Circuit model. ### External dependencies None
adam added the type: featurenetboxneeds milestonestatus: backlogcomplexity: low labels 2025-12-29 21:33:55 +01:00
adam commented 2025-12-29 21:33:55 +01:00
Author
Owner
Copy Link

@bctiemann commented on GitHub (Feb 20, 2025):

@sleepinggenius2 Please enumerate the exact fields that would be added to VirtualCircuit, along with justification for each one (not all will be strictly relevant to VCs, Installed (date) for example).

@bctiemann commented on GitHub (Feb 20, 2025): @sleepinggenius2 Please enumerate the exact fields that would be added to `VirtualCircuit`, along with justification for each one (not all will be strictly relevant to VCs, `Installed` (date) for example).
adam commented 2025-12-29 21:33:56 +01:00
Author
Owner
Copy Link

@sleepinggenius2 commented on GitHub (Feb 20, 2025):

The following three fields are present on the Circuit model, but absent on the Virtual Circuit model and should be added to achieve parity and support real-world use cases.

Installed - Often when establishing connectivity to another operator in a new location, an ENNI (External Network Network Interface) will be established with the other operator, regardless of whether any overlying services are turned up at that time. This should be represented as a Circuit in NetBox and recorded with an Installed (date) once physical connectivity is established and the equipment links up. As a best practice, this is something my company tries to do any time we enter a new colocation facility provided by another operator. At any point after the ENNI is established, one or more OVCs (Operator Virtual Connections) may be turned up to provide services (see MEF 26.2 for reference). Each OVC is an independent entity and should be represented as a Virtual Circuit in NetBox. As an OVC can be added at any point after the ENNI is established and is a separately billable entity, it needs to have its own Installed (date).

Terminates - Just as an individual OVC can be added at any point, it can also be removed, without affecting other OVCs or the underlying ENNI, so it needs to have its own Terminates (date) as well.

Commit rate (Kbps) - An ENNI by definition is turned up at an agreed line rate between the two operators. Any OVC that is turned up on top of it can be policed independently, allowing multiple services to consume different maximum bandwidth values out of the overall line rate. It is a business decision whether to allow for over subscription of the total bandwidth, but no individual service can obviously be provisioned to exceed line rate. MEF allows for both an ingress and egress bandwidth profile to be enforced at each endpoint, so technically this could be multiple fields, but in practice a service is almost always symmetrical, so keeping the single field for parity with the Circuit model should be sufficient.

MEF is a global standards organization for an ever-increasing portfolio of services and supported by almost every equipment manufacturer and service provider, at least here in the US. Because of this, the scenarios I have outlined above should at the very least be common place among the NetBox community at large whenever they are ordering Carrier Ethernet services from an operator.

@sleepinggenius2 commented on GitHub (Feb 20, 2025): The following three fields are present on the `Circuit` model, but absent on the `Virtual Circuit` model and should be added to achieve parity and support real-world use cases. **Installed** - Often when establishing connectivity to another operator in a new location, an ENNI (External Network Network Interface) will be established with the other operator, regardless of whether any overlying services are turned up at that time. This should be represented as a `Circuit` in NetBox and recorded with an Installed (date) once physical connectivity is established and the equipment links up. As a best practice, this is something my company tries to do any time we enter a new colocation facility provided by another operator. At any point after the ENNI is established, one or more OVCs (Operator Virtual Connections) may be turned up to provide services (see [MEF 26.2](https://www.mef.net/wp-content/uploads/2016/08/MEF-26-2.pdf) for reference). Each OVC is an independent entity and should be represented as a `Virtual Circuit` in NetBox. As an OVC can be added at any point after the ENNI is established and is a separately billable entity, it needs to have its own Installed (date). **Terminates** - Just as an individual OVC can be added at any point, it can also be removed, without affecting other OVCs or the underlying ENNI, so it needs to have its own Terminates (date) as well. **Commit rate (Kbps)** - An ENNI by definition is turned up at an agreed line rate between the two operators. Any OVC that is turned up on top of it can be policed independently, allowing multiple services to consume different maximum bandwidth values out of the overall line rate. It is a business decision whether to allow for over subscription of the total bandwidth, but no individual service can obviously be provisioned to exceed line rate. MEF allows for both an ingress and egress bandwidth profile to be enforced at each endpoint, so technically this could be multiple fields, but in practice a service is almost always symmetrical, so keeping the single field for parity with the `Circuit` model should be sufficient. MEF is a global standards organization for an ever-increasing portfolio of services and supported by almost every equipment manufacturer and service provider, at least here in the US. Because of this, the scenarios I have outlined above should at the very least be common place among the NetBox community at large whenever they are ordering Carrier Ethernet services from an operator.
adam commented 2025-12-29 21:33:56 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Feb 28, 2025):

This is a reminder that additional information is needed in order to further triage this issue. If the requested details are not provided, the issue will soon be closed automatically.

@github-actions[bot] commented on GitHub (Feb 28, 2025): This is a reminder that additional information is needed in order to further triage this issue. If the requested details are not provided, the issue will soon be closed automatically.
adam commented 2025-12-29 21:33:56 +01:00
Author
Owner
Copy Link

@samk-acw commented on GitHub (Apr 15, 2025):

Would it be possible to include this FR in v4.3? I'm happy to provide the PR if assigned

@samk-acw commented on GitHub (Apr 15, 2025): Would it be possible to include this FR in v4.3? I'm happy to provide the PR if assigned
adam commented 2025-12-29 21:33:57 +01:00
Author
Owner
Copy Link

@sleepinggenius2 commented on GitHub (Aug 19, 2025):

Since we missed this for the v4.3 release, would it be possible to get this added for v4.4 while it's still in the beta cycle? I would also be happy to submit a PR, if it would help.

@sleepinggenius2 commented on GitHub (Aug 19, 2025): Since we missed this for the v4.3 release, would it be possible to get this added for v4.4 while it's still in the beta cycle? I would also be happy to submit a PR, if it would help.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label complexity: low needs milestone netbox status: backlog type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#10631
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?