feat(otn): replace the optical schemas with a single OTN extension

.metadata.yml

@@ -76,14 +76,6 @@ experimental/modules_routing_engine:
     information like the version. You can insert the Routing Engine into a Dcim Physical
     Device and leverage the Routing Engine type model.
   name: Modules Routing Engine
-experimental/optical_transport:
-  dependencies:
-    - base
-    - extensions/device_module
-    - extensions/cable
-  description: |
-    Comprehensive optical transport network schemas for DWDM/WDM systems (ADVA FSP 3000 and similar platforms). Covers four layers: wavelength (ITU-T G.694.1 grid, optical bands, DWDM channels), topology (logical optical nodes, passive multiplexers, fiber links), equipment (transponder/amplifier/ROADM modules, ROADM degrees, WSS cross-connects), and service (end-to-end optical services, optical paths, path segments). Not designed to be loaded together with extensions/optical_multiplexer.
-  name: Optical Transport
 experimental/qos:
   dependencies:
     - base
@@ -240,17 +232,66 @@ extensions/module_port:
 
     NOTE: port names keep NetBox's `{module}` bay-position token verbatim, because a template is not bound to a bay. Substituting it and creating the real device interfaces is a generator step once the module is installed.
   name: Module Port
-extensions/optical_multiplexer:
+extensions/otn:
   dependencies:
     - base
+    - extensions/location_site
     - extensions/transceiver
   description: |
-    This schema extension models optical add-drop multiplexers (OADM) and the wavelength division multiplexing (WDM) channels they carry, for both CWDM and DWDM. It adds an Optical Multiplexer device with front and rear interfaces, a WDM Channel node holding channel number, wavelength and frequency, and a WDM Transceiver flavour of the transceiver model tuned to a channel.
-
-    Some vendors configure tunable optics by wavelength or frequency rather than channel number; the WDM Channel node gives you a single entry in Infrahub for all three.
-
-    Not designed to be loaded together with experimental/optical_transport, which covers the same domain in more depth.
-  name: Optical Multiplexer
+    Optical transport network schemas covering the physical plant, the wavelength catalog, optical devices and their ports, pluggable optics, carriers and end-to-end services.
+  name: OTN
+  not_covered:
+    - Validation of what a schema cannot express, such as which port kind may hold
+      a pluggable, whether a mux client port binds a channel on the same plan its
+      multiplexer declares, or whether a hop's ingress and egress ports belong to
+      that hop's own element. This extension ships no checks; the schema comments
+      mark each such rule.
+    - Device types, platforms and rack elevations for optical gear, as native OTN
+      fields. Model the physical asset as a DcimPhysicalDevice and link it with OtnGenericDevice.dcim_device;
+      that edge reaches device_type, platform, position and rack_face, and a location
+      that may be a LocationRack. Nothing keeps OtnGenericDevice.site in agreement
+      with the site above that rack.
+    - Optical performance monitoring. The schema carries ratings and settings, such
+      as a port's transmit power or a mode's required OSNR, but nothing that is measured,
+      such as live power, OSNR, pre-FEC BER or an error counter. Those change continuously
+      and belong in the network management system or a time series store.
+    - Optical path budgets, including the record of design. OtnOpticalPath records
+      which elements the light crosses, in what order and across which ports, but
+      carries no loss, OSNR margin or latency for that route, so a turn-up figure
+      has nowhere to live. OtnService.max_latency_ns is a commitment on the service,
+      not a measurement of a path. Compute budgets in a planning tool such as GNPy.
+    - Frequency plans other than one fixed dense grid. OtnFrequencyGrid models a single
+      ITU-T G.694.1 fixed 50 GHz plan across the C band, from 191.35 to 196.10 THz.
+      L band, C plus L systems, flexgrid and other channel spacings are out of scope.
+    - Protection mechanisms. OtnOpticalPath.path_role marks a path as working or protect
+      and OtnDiversityGroup keeps two services apart, but nothing states the scheme,
+      so 1+1, 1:1, optical line protection, OMS protection and ODU SNCP are indistinguishable.
+      Switching thresholds and hold-off timers are out of scope with it. OtnSplitter
+      models the coupler such a scheme is built from.
+    - The OTU and OPU layers of ITU-T G.709. The model goes from the optical channel,
+      OtnOpticalCarrier, straight to the ODU, OtnContainer. Forward error correction
+      lives on OtnOpticalMode, so what an OTU would add is its section monitoring
+      and framing overhead, which are not modelled.
+  use_cases:
+    - Recording the ITU-T G.694.1 dense grid and G.694.2 coarse plan as separate kinds,
+      so a carrier pointed at the wrong plan is refused when written.
+    - Tracking pluggable optics as inventory, with the part number in this extension's
+      catalog, the serial on the library's transceiver kinds from extensions/transceiver,
+      and which optical port each unit is fitted in.
+    - Modelling the outside plant, including fiber types, conduits, spans and the
+      optical multiplex sections built over them. A section terminates on any OMS
+      endpoint, so a fixed point-to-point system built from passive multiplexers is
+      modellable without a ROADM.
+    - Cabling optical gear with extensions/cable. Every OTN port kind inherits DcimEndpoint,
+      so a DcimCable terminates on one for intra-site jumpers, through a DcimPatchPanel
+      where a panel sits in the run.
+    - Provisioning a wavelength end to end, as a service with an optical path and
+      its hops through the elements the light crosses. Each hop records what the element
+      does to the carrier and across which port pair, so a ROADM cross-connect reads
+      either from the path or from the ROADM's own ports.
+    - Modelling optical protection, with a working and a protect path on one service,
+      a diversity group that keeps two services off shared plant, and OtnSplitter
+      for the coupler that feeds both legs.
 extensions/patch_panel:
   dependencies:
     - base

base/dcim.yml

@@ -67,7 +67,7 @@ generics:
       # Duplicated from DcimGenericDevice because generics cannot inherit generics.
       # DcimModuleBay.computed_name (extensions/device_module) renders
       # {{ device__name__value }} against peer DcimPhysicalDevice, so name must resolve here.
-      # allow_override lets DcimPatchPanel and DcimOpticalMultiplexer restate it.
+      # allow_override lets DcimPatchPanel restate it.
       - name: name
         kind: Text
         unique: true

docs/docs/home.mdx

@@ -99,7 +99,6 @@ This list provides an overview of the schemas available in this repository. Each
 | **[Location Extended](./reference/location_extended.mdx)** | This schema extension is the most detailed when it comes to location, you'll find all the layers you can think of. It defines its own hierarchical Location.Rack, incompatible with the flat one extensions/rack defines, so load one or the other, not both. |
 | **[Modules Linecards](./reference/modules_linecards.mdx)** | This schema extension allows you to capture Linecard related information like the version. You can insert the Linecard into a Dcim Physical Device and leverage the Linecard type model. The Linecard can accept PIC to help configure PORT information like breakout-capabilities and configurations. |
 | **[Modules Routing Engine](./reference/modules_routing_engine.mdx)** | This schema extension allows you to capture Routing Engine related information like the version. You can insert the Routing Engine into a Dcim Physical Device and leverage the Routing Engine type model. |
-| **[Optical Transport](./reference/optical_transport.mdx)** | Comprehensive optical transport network schemas for DWDM/WDM systems (ADVA FSP 3000 and similar platforms). Covers four layers: wavelength (ITU-T G.694.1 grid, optical bands, DWDM channels), topology (logical optical nodes, passive multiplexers, fiber links), equipment (transponder/amplifier/ROADM modules, ROADM degrees, WSS cross-connects), and service (end-to-end optical services, optical paths, path segments). Not designed to be loaded together with extensions/optical_multiplexer. |
 | **[QoS](./reference/qos.mdx)** | This schema extension contains models for Quality of Service (QoS) |
 | **[Security](./reference/security.mdx)** | This schema extension contains models for implementing detailed security. |
 | **[Topology](./reference/topology.mdx)** | A schema for defining and managing network topology, strategies, and services. |
@@ -125,7 +124,7 @@ This list provides an overview of the schemas available in this repository. Each
 | **[Location Site](./reference/location_site.mdx)** | This schema extension introduces a Site node with facility, physical address, timezone and status, for deployments that want a flat list of sites without a hierarchy. It is the same Site node as in extensions/location_minimal, which adds Region, Country and Metro tiers above it. |
 | **[MLAG](./reference/mlag.mdx)** | This schema extension contains the foundations to capture Multi-Chassis Link Aggregation Groups (MLAG). It comes on top of the LAG extension. In this implementation, a MLAG interface is essentially a LAG interface but linked to a MLAG domain (instead of a device). The MLAG domain regroups devices together (usually 2) and is built over LAG interfaces used as peer-link between the devices. MLAG interfaces defined at the MLAG domain level are then spread across all devices in the domain. This is a deliberately minimal implementation of MLAG, meant to blend with models you already have. For example, in a data center fabric you might already have a LeafGroup or similar concept: have it inherit from GenericMlagDomain and add the relationships and attributes you need. Not covered yet: the layer 3 overlay for MLAG interfaces (loopback, peer address ...) and surfacing MLAG interfaces on each device in the domain. |
 | **[Module Port](./reference/module_port.mdx)** | This schema extension adds module ports: the ports a module provides, as declared by its module type - what NetBox module-type definitions list under `interfaces`, `console-ports` and `power-ports`. These are deliberately not DcimInterface objects. DcimInterface.device is a mandatory Parent, and Infrahub requires the relationships used in a uniqueness constraint to be mandatory, so an interface cannot hang off a module instead of a device. A DcimModulePort is a declaration parented by the module, carrying the port name, its category (interface, console, power, front, rear), the NetBox type slug, and power draw. NOTE: port names keep NetBox's `{module}` bay-position token verbatim, because a template is not bound to a bay. Substituting it and creating the real device interfaces is a generator step once the module is installed. |
-| **[Optical Multiplexer](./reference/optical_multiplexer.mdx)** | This schema extension models optical add-drop multiplexers (OADM) and the wavelength division multiplexing (WDM) channels they carry, for both CWDM and DWDM. It adds an Optical Multiplexer device with front and rear interfaces, a WDM Channel node holding channel number, wavelength and frequency, and a WDM Transceiver flavour of the transceiver model tuned to a channel. Some vendors configure tunable optics by wavelength or frequency rather than channel number; the WDM Channel node gives you a single entry in Infrahub for all three. Not designed to be loaded together with experimental/optical_transport, which covers the same domain in more depth. |
+| **[OTN](./reference/otn.mdx)** | Optical transport network schemas covering the physical plant, the wavelength catalog, optical devices and their ports, pluggable optics, carriers and end-to-end services. |
 | **[Patch Panel](./reference/patch_panel.mdx)** | This schema extension allows you to capture patch panel related information like rear and front interfaces and the mapping between them. You can insert the patch panel into a rack and leverage the device type model. Cassettes and other inserts are tracked as regular device modules in module bays, through extensions/device_module. The front and rear interfaces accept all sorts of connectors, so you can plug cables, circuits and cross-connects into them. |
 | **[Physical Disk](./reference/physical_disk.mdx)** | Simple schema allowing you to capture physical disk information for inventory and lifecycle management. This extension works with any kind of device: apply the DcimDeviceWithPhysicalDisks generic to a model to enable disk tracking. You might also link disks to a location, for instance to capture spares. |
 | **[PSU Module](./reference/device_module_psu.mdx)** | This schema extension adds a PSU (Power Supply Unit) flavour on top of the generic Module and Module Type from extensions/device_module, so you can track power supplies installed in a device's module bays with PSU-specific attributes such as wattage and hot-swap capability. |