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

Optical / Transport layer interfaces addition in interface type #9810

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

Originally created by @tadew7 on GitHub (Jun 6, 2024).

NetBox version

v4.0.3

Feature type

Data model extension

Proposed functionality

Currently we can select electrical layer interfaces in Netbox. They could be Eth or SDH interface. For DWDM or Optical transport layer. There are some optical layer interfaces and connectivity persists. OTN layers are OPU, ODU, OTU, OCH, OMS, OTS and two types of supervisory channels (OSC, ESC). Is it possible to add or customize OTN layers in the interface type. At least an option such as optical / WDM in interface type would be great.

Use case

In that case we can perfectly model DWDM / optical transport equipment and its connectivity in Netbox.

Database changes

Need to add in Interface type Field. No change in other section.

External dependencies

No response

Originally created by @tadew7 on GitHub (Jun 6, 2024). ### NetBox version v4.0.3 ### Feature type Data model extension ### Proposed functionality Currently we can select electrical layer interfaces in Netbox. They could be Eth or SDH interface. For DWDM or Optical transport layer. There are some optical layer interfaces and connectivity persists. OTN layers are OPU, ODU, OTU, OCH, OMS, OTS and two types of supervisory channels (OSC, ESC). Is it possible to add or customize OTN layers in the interface type. At least an option such as optical / WDM in interface type would be great. ### Use case In that case we can perfectly model DWDM / optical transport equipment and its connectivity in Netbox. ### Database changes Need to add in Interface type Field. No change in other section. ### External dependencies _No response_
adam commented 2025-12-29 21:23:02 +01:00
Author
Owner
Copy Link

@PaulR282 commented on GitHub (Jun 11, 2024):

https://plugin-ideas.netbox.dev/ideas/PLUGINS-I-35

This plugin idea exists. I think it should fulfill your requirements once it is developed.

@PaulR282 commented on GitHub (Jun 11, 2024): https://plugin-ideas.netbox.dev/ideas/PLUGINS-I-35 This plugin idea exists. I think it should fulfill your requirements once it is developed.
adam commented 2025-12-29 21:23:02 +01:00
Author
Owner
Copy Link

@sleepinggenius2 commented on GitHub (Jun 11, 2024):

The plugin would help with modeling the connection piece, but not the interface piece, as plugins cannot currently add new interface types to the built-in interface type choices, although that is something that would be cool to have support for. I'm currently modeling our optical transport/ROADM network and have definitely been hit by this limitation. I've ended up with a lot of Virtual and Other type interfaces and we ultimately added a custom field to the Interface model to further clarify the type. Unfortunately, that cannot be set as part of a device or module type, and having an extra column in the table not only takes space, but users have to remember to add it, so it's a bit of a cumbersome solution, but workable for now. With the ability for plugins to inject columns into tables now, there are some options to address things through that mechanism, but I haven't explored that yet.

The one limitation I currently see with this proposal is that for something like the OTU layer (and ultimately ODU and OPU), do you break out separate types for the different OTUk values? Knowing it's OTU is great, but being able to differentiate between OTU2 and OTU2e or OTU4/OTUC2/OTUC4 would also be important. Yes, you could use the speed field, but do you use the data rate or signal rate, and it's non-trivial to remember that OTU2 is 10/10.7 Gbps versus OTU2e is 10.5/11.1 Gbps. Also, for an ODU2, the date rate is ~10.0372739240506 Gbps and ODU2e is ~10.3995253164557 Gbps, which nobody is ever going to remember.

@sleepinggenius2 commented on GitHub (Jun 11, 2024): The plugin would help with modeling the connection piece, but not the interface piece, as plugins cannot currently add new interface types to the built-in interface type choices, although that is something that would be cool to have support for. I'm currently modeling our optical transport/ROADM network and have definitely been hit by this limitation. I've ended up with a lot of Virtual and Other type interfaces and we ultimately added a custom field to the Interface model to further clarify the type. Unfortunately, that cannot be set as part of a device or module type, and having an extra column in the table not only takes space, but users have to remember to add it, so it's a bit of a cumbersome solution, but workable for now. With the ability for plugins to inject columns into tables now, there are some options to address things through that mechanism, but I haven't explored that yet. The one limitation I currently see with this proposal is that for something like the OTU layer (and ultimately ODU and OPU), do you break out separate types for the different OTUk values? Knowing it's OTU is great, but being able to differentiate between OTU2 and OTU2e or OTU4/OTUC2/OTUC4 would also be important. Yes, you could use the speed field, but do you use the data rate or signal rate, and it's non-trivial to remember that OTU2 is 10/10.7 Gbps versus OTU2e is 10.5/11.1 Gbps. Also, for an ODU2, the date rate is ~10.0372739240506 Gbps and ODU2e is ~10.3995253164557 Gbps, which nobody is ever going to remember.
adam commented 2025-12-29 21:23:03 +01:00
Author
Owner
Copy Link

@jeffgdotorg commented on GitHub (Jun 11, 2024):

This feature sounds highly valuable, particularly to service providers. We'll need to draw on the knowledge of the community for understanding of the particulars, as the core developers all find this topic area fascinating but also well outside our expertise.

@PaulR282 good spotting on the ideas board, though I agree with @sleepinggenius2 there's likely to be some foundational work needed in core NetBox to give OTN a proper representation.

@tadew7 please do take a look at the plugin idea linked above in comments. Then please come back here and revise your issue body to flesh it out a bit more. I can see this FR spawning a long-running conversation.

@jeffgdotorg commented on GitHub (Jun 11, 2024): This feature sounds highly valuable, particularly to service providers. We'll need to draw on the knowledge of the community for understanding of the particulars, as the core developers all find this topic area fascinating but also well outside our expertise. @PaulR282 good spotting on the ideas board, though I agree with @sleepinggenius2 there's likely to be some foundational work needed in core NetBox to give OTN a proper representation. @tadew7 please do take a look at the plugin idea linked above in comments. Then please come back here and revise your issue body to flesh it out a bit more. I can see this FR spawning a long-running conversation.
adam commented 2025-12-29 21:23:03 +01:00
Author
Owner
Copy Link

@sleepinggenius2 commented on GitHub (Jun 12, 2024):

@jeffgdotorg There was talk a few months back about setting up a service provider working group, but I never saw anything come of it. I think this would be a perfect item to cover in a forum like that. I'm available on Slack, if I can help with that effort.

@sleepinggenius2 commented on GitHub (Jun 12, 2024): @jeffgdotorg There was talk a few months back about setting up a service provider working group, but I never saw anything come of it. I think this would be a perfect item to cover in a forum like that. I'm available on Slack, if I can help with that effort.
adam commented 2025-12-29 21:23:03 +01:00
Author
Owner
Copy Link

@jeffgdotorg commented on GitHub (Jun 12, 2024):

@sleepinggenius2 agreed! I don't know how to find you on NetDev Slack but I'm easy to track down there, please reach out.

@jeffgdotorg commented on GitHub (Jun 12, 2024): @sleepinggenius2 agreed! I don't know how to find you on NetDev Slack but I'm easy to track down there, please reach out.
adam commented 2025-12-29 21:23:03 +01:00
Author
Owner
Copy Link

@tadew7 commented on GitHub (Jun 12, 2024):

@sleepinggenius2 Thank you for your reply. I do agree. Adding device and module type would be helpful but if it is difficult then we can skip that. From user end I would know based on interface type that it is optical/ transport equipment.

Yes, we do break separate types of ODUk based on user's requirement. To be honest we are more concerned to add optical layer interfaces of DWDM layer. Because technically we can express ODUk to different data rate to like ~10G, ~40G, ~100G etc. And adding different types of ODUk (ODU 0, 1, 2, 2e, 3, 3e2, 4, flex) interfaces could make it clumsy.

But when signal convert to optical layer then it hard to express. So, we could keep it like that in a simplex from.

Electrical Layer:

  1. ODUk interface (if possible, to show ODUk grooming)
  2. OTUk
    These are sub-layer of OCH.

Optical Layer:

  1. OCH (this refers to optical channel / Lambda in WDM layer)
  2. OMS (this refers to WDM multiplexing signal)
  3. OTS (refers to entire optical transport section / exit interface to line fiber)

In addition, we can provision for adding supervisory signal. In DWDM we use any one of below two types of signals.

  1. OSC
  2. ESC

@jeffgdotorg I have shared some outline here. We can follow RFC 3591 to make it standardize for all.
https://datatracker.ietf.org/doc/html/rfc3591

But if we need more technical details, then I can find out some documents which are available online.
Please reach out for any issues. Happy to help.

@tadew7 commented on GitHub (Jun 12, 2024): @sleepinggenius2 Thank you for your reply. I do agree. Adding device and module type would be helpful but if it is difficult then we can skip that. From user end I would know based on interface type that it is optical/ transport equipment. Yes, we do break separate types of ODUk based on user's requirement. To be honest we are more concerned to add optical layer interfaces of DWDM layer. Because technically we can express ODUk to different data rate to like ~10G, ~40G, ~100G etc. And adding different types of ODUk (ODU 0, 1, 2, 2e, 3, 3e2, 4, flex) interfaces could make it clumsy. But when signal convert to optical layer then it hard to express. So, we could keep it like that in a simplex from. Electrical Layer: 1. ODUk interface (if possible, to show ODUk grooming) 2. OTUk These are sub-layer of OCH. Optical Layer: 1. OCH (this refers to optical channel / Lambda in WDM layer) 4. OMS (this refers to WDM multiplexing signal) 5. OTS (refers to entire optical transport section / exit interface to line fiber) In addition, we can provision for adding supervisory signal. In DWDM we use any one of below two types of signals. 1. OSC 2. ESC @jeffgdotorg I have shared some outline here. We can follow RFC 3591 to make it standardize for all. https://datatracker.ietf.org/doc/html/rfc3591 But if we need more technical details, then I can find out some documents which are available online. Please reach out for any issues. Happy to help.
adam commented 2025-12-29 21:23:04 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jun 26, 2024):

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 (Jun 26, 2024): 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:23:04 +01:00
Author
Owner
Copy Link

@tadew7 commented on GitHub (Jun 26, 2024):

Hi everyone! Would you please share if you guys need any details?

@tadew7 commented on GitHub (Jun 26, 2024): Hi everyone! Would you please share if you guys need any details?
adam commented 2025-12-29 21:23:04 +01:00
Author
Owner
Copy Link

@jeffgdotorg commented on GitHub (Jul 3, 2024):

This FR will certainly need detailing and breaking down into smaller sub-issues, but it aligns with our roadmap and already captures some good conversation so I'm backlogging it.

@jeffgdotorg commented on GitHub (Jul 3, 2024): This FR will certainly need detailing and breaking down into smaller sub-issues, but it aligns with our roadmap and already captures some good conversation so I'm backlogging it.
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: medium 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#9810
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?