Add Service Parameters to Virtual Circuit model

[sleepinggenius2]

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

[bctiemann]

@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).

[sleepinggenius2]

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.

[github-actions]

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.