Passthrough Rear Port Positions

[grbeneke]

NetBox version

v3.2

Feature type

Change to existing functionality

Proposed functionality

Link port positions of 2 separate rear ports together within a device in a way that:

• Avoids the need to manually connect dummy front ports together with cables.
• Visually represents these connections as a fixed internal part of the device.
• Can be modeled as part of the device type template.

Use case

Various passive optical components such as DWDM/CWDM Optical Add-Drop Muliplexers (OADM) and splice joints have a certain number of positions which will pass-through the device in a fixed way. This is not adjustable by changing connections or configuration. There can be a significant number of individual pass-through positions which can be labour intensive to model without a template. Device cloning does not carry over patching and so effort is required for every new device.

Database changes

One possible implementation would be to create hidden dummy ports and dummy cables. A flag to denote this state would be required.

External dependencies

No response

[jeremystretch]

It might help to share a specific example of a device you're attempting to represent in NetBox, and explain why you don't believe the current model will support it.

[grbeneke]

There is a brief write up on wikipedia about OADMs: https://en.wikipedia.org/wiki/Optical_add-drop_multiplexer. There is also some technical explanation on the bottom of this product page: https://www.fs.com/products/70427.html.

The nearest way to model this right now would be to take https://github.com/netbox-community/devicetype-library/blob/master/device-types/FS/FMU-D402160M.yaml - but doubling up all the ports for an east and west side. Then to connect cables between the 30+ front ports on the east and west sides which represent the pass-through or cut-through channels.

[shatt79]

What he's talking about is support for express ports on WDMs.

In a CO, it's normal to have a high density DWDM OADM that feeds lower density OADMs down the line. For example, a 44 channel OADM that goes to a 4 channel OADM. The 40 channels that are not dropped/added at that location are expressed down the line to the next OADM. This can happen up to 11 times in this example.

It's really easy to build a pair of bookended OADMs of the same channel density. 1 rear port with 44 positions (representing the composite) and 44 front ports. Then just link the rear ports of the two OADMs together. What we can't do is tie the individual positions (channels) of a rear port to individual positions of another rear port. If we could, this would be easy. It'd just be a matter of creating a second rear port on the downstream OADM with the positions (channels) you want to express to the next OADM. It's just a cascade. Send 44, drop 4, express 40, drop 4, express 36, drop 8, express 28, etc. Each hop along the way we're dropping out a variable number of positions from the rear to the front, and sending the rest out the second rear port to the next hop where it repeats. The trick is going to be making everything line up. If I connect a device to chanel 23 on the CO mux, and drop it out on channel 23 three hops down the line, the trace will need to represent that accurately.

We have to use excel spreadsheets to document these setups (thousands of them). DWDM is more common than grey waves anymore in the ISP world. But for some reason, the F&E software companies seem to ignore it. So we're stuck with our napkins and spreadsheets. Help!

[jsenecal]

Not sure if my current use-case is related 100% but we do have a need to "split" TX and RX in some optical equipment such as Amplifiers. this could be done with the current implementation with "internal" connections I believe, or even better, if Front/Rear ports could allow for many positions (instead of limiting that to the rear ports only) this would allow for complex mappings such as "splitting" a duplex LC and "merging" it back for an interface without loosing the ability to trace individual fibers.

Trying to represent something like that:

[liamtbb]

I agree that the current model doesn't support OADM, at least as far as I can tell. I feel like OADMs are a common enough item that they should be considered essential to the Netbox model.

Creating a multiplexer device is of course not a problem, it's just front ports to a rear port. And you can make an OADM with an EAST and a WEST rear port, connecting up to the corresponding EAST/WEST front port channels being dropped, no problems there. You can then stick that OADM between a pair of multiplexers and so far, so good. However, you can't passthrough the channels NOT being dropped at the OADM.

As an example, let's say we have a pair of multiplexers with channels 21-60, and we intend to put an OADM in between them to drop channels 21-30:

[DWDM MUX CH21-60 {LINE}] <------> [{EAST} OADM CH 21-30 | OADM CH 21-30 {WEST}] <------> [{LINE} DWDM MUX CH21-60]

• All DMUX front ports correspond to the LINE rear port.
• East OADM front ports correspond to EAST rear port, West OADM front ports correspond to WEST rear port.

In this case, cable traces for channels 21-30 will work as expected, but channels 31-60 will die at the OADM. If there was an option to connect rear port positions together (e.g. EAST rear positions 31-60 connected to WEST rear positions 31-60) then we could create our own passthrough channels, not sure if that would work for all scenarios but certainly for a typical MUX<->OADM<->MUX configuration.

[DanSheps]

Anything not tied to the original FR should be a new FR.

Is the original use case perhaps solved by #9102? If so, lets close this out and hold off on any new FR's until it is tested and deployed with 3.3

[liamtbb]

Anything not tied to the original FR should be a new FR.

Is the original use case perhaps solved by #9102? If so, lets close this out and hold off on any new FR's until it is tested and deployed with 3.3

Thanks Dan, #9102 does look like it could be a suitable model for building OADM pathways, I'll wait for 3.3.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

[github-actions[bot]]

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.