search

netbox-community / netbox

The premier source of truth powering network automation. Open source under Apache 2. Public demo: https://demo.netbox.dev
http://netboxlabs.com/oss/netbox/
Apache License 2.0
15.32k stars 2.49k forks source link

Optical / Transport layer interfaces addition in interface type #16433

Open tadew7 opened 3 weeks ago

tadew7 commented 3 weeks ago

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

PaulR282 commented 2 weeks ago

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

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

sleepinggenius2 commented 2 weeks ago

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.

jeffgdotorg commented 2 weeks ago

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.

sleepinggenius2 commented 2 weeks ago

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

jeffgdotorg commented 2 weeks ago

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

tadew7 commented 2 weeks ago

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

github-actions[bot] commented 2 days ago

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.

tadew7 commented 2 days ago

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