Should a fixed chassis' SFP cages be module bays?

[jvobelnet]

Question

Is a transceiver cage on a fixed-form-factor device something this library should express as a module-bay?

Guidance says module bays belong to all modular components, and a pluggable transceiver is about as field-replaceable as a component gets. But the pattern is rare here: of the 4,098 device types that declare module bays, only 9 name anything transceiver-shaped — 6 UfiSpace, 2 Cisco, 1 Sophos — and no Juniper definition does. Before proposing it across a large vendor tree, it seems worth asking whether that is deliberate.

Motivation: NetBox 4.3 deprecated inventory items, and NetBox Labs' own write-up recommends modelling SFPs as modules. Doing that needs a bay per cage, and on a fixed chassis there is no line-card module to hang one off.

Example with SRX300

The definition already records which ports are cages, so nothing new has to be asserted:

interfaces:
  - name: ge-0/0/0 … ge-0/0/5
    type: 1000base-t        # RJ45, no cage
  - name: ge-0/0/6
    type: 1000base-x-sfp    # cage
  - name: ge-0/0/7
    type: 1000base-x-sfp    # cage

so the addition is:

module-bays:
  - name: Xcvr 0/0/6
    position: 0/0/6
  - name: Xcvr 0/0/7
    position: 0/0/7

Branch, if useful: https://github.com/jvobelnet/devicetype-library/tree/juniper-srx300-transceiver-bays

Junos reports the transceiver as Xcvr 6 nested under PIC 0 → FPC 0, which a flat device-type bay cannot express. Xcvr 0/0/6 keeps the slot path, so the bay's slot matches the slot in the interface name and a transceiver module can be joined to the port it feeds. Could also be 'SFP0 / SFP1', 'Transciever 6', etc.

If this is accepted, I can provide some other PR for other devices we own.

[harryajc]

@jvobelnet Most of the reason behind this is that devices have been created in this device library before the recent change in 4.3, as it is a massive undertaking to update every device in this library that has a sfp or qsfp port with the new format this hasn't been done yet. As this change would also require the creation of many module types to represent all of the different optics that users might want to use in the module-bays.

[harryajc]

Also the best way to represent optic module bays in your demoed juniper device would be

module-bays:
  - name: ge-0/0/6
    position: ge-0/0/6
  - name: ge-0/0/7
    position: ge-0/0/7

As it would need to follow device port naming so that the interfaces will lineup.

[jvobelnet]

@jvobelnet Most of the reason behind this is that devices have been created in this device library before the recent change in 4.3, as it is a massive undertaking to update every device in this library that has a sfp or qsfp port with the new format this hasn't been done yet. As this change would also require the creation of many module types to represent all of the different optics that users might want to use in the module-bays.

I understand where this is coming from and why this wasn't done before, but the doc is unclear on the way to proceed. If it's only a matter of people doing the work, then I'm happy to start on what we own in our network. I'm not sure I agree with your remark on module type, this is called Device Type Library, not Module Type Library after all :)
Nevertheless, I think it would benefit to have a note about it somewhere for people contributing, possibly linking to the decision from Netbox.

Also the best way to represent optic module bays in your demoed juniper device would be

module-bays:

• name: ge-0/0/6
  position: ge-0/0/6
• name: ge-0/0/7
  position: ge-0/0/7
  As it would need to follow device port naming so that the interfaces will lineup.

I disagree here. There are some device where the name depends from the SFP inserted (see https://www.juniper.net/documentation/us/en/hardware/mx301/topics/concept/ports.html). While it works for SRX300, it wouldn't for some other one to have the name of the module-bay set to the interface name.