Add coaxial connectors for Sub Miniature type A and Sub miniature type B to support GNSS and Timing interfaces

[pobk]

NetBox version

v4.0.3

Feature type

Data model extension

Proposed functionality

NetBox does not presently support Coaxial SMA connector types. Notably SM type A and SM Type B typically used for GNSS antennas and 1PPS timing interfaces

Use case

Intel E810-XXVDA4 quad port 25Gbit ethernet cards for example, provide connectivity points for 2x SMA and 1x SMB interfaces to connect GNSS and timing infrastructure. (1PPS port.)

See adaptor features section in this brief: https://cdrdv2.intel.com/v1/dl/getContent/641626

Several routers in the diaggregated core feature GNSS and 1PPS coaxial interfaces - EdgeCore CSR440 for example.

Database changes

None

External dependencies

None

[jeremystretch]

typically used for GNSS antennas and 1PPS timing interfaces

These do not sound like network interfaces.

[pobk]

They're typically used in precision timing interfaces. 1PPS typically uses RJ45, but as I pointed out, the E810 has SM-B terminals.

These are probably more appropriate as front-port types, rather than network interfaces.

[bluikko]

Plenty of Cisco etc network devices also provide these kind of interfaces. It would be nice to be able to fully model these wide-spread network devices without local patches.

Example: Cisco NCS series routers, Juniper ACX7k and so on. It really is wide-spread.

[pobk]

Timing is becoming massive thing... PTP especially.

My logic is that just because it's serial or some other non IP related protocol, does not mean we can neglect the accurate documentation of it.

[pobk]

Also, just to add further information here...

See the most awesome timing device ever: https://www.oscilloquartz.com/en/products-and-services/ptp-grandmaster-clocks/sfp-pluggable-ptp-grandmasters/osa-5401-series

This is a niche, thing... but being able to map the connectivity required for PTP is an absolute headache in NetBox at the moment. Does that device use a SM-A or n-type? What about that high-density Wifi AP with external MIMO antenna?

[pobk]

I've changed my mind. As I mentioned elsehwere, this should be an interface. It's the externalised connectivity for a specific function within the device.

While it's not your typical IP or ethernet network interface, it is still a logical function of the device. In my case it's the external connectivity for a GNSS receiver which enables the timing circuits and oscillators on the host device I use to distribute precise time across my networks.

[jeremystretch]

There are some simple litmus tests for whether something is a network interface:

• Is it configured with a unique address?
• Does it send and/or receive packetized data?

If it doesn't meet both of these conditions, it's not treated as a network interface by NetBox.

[pobk]

There are some simple litmus tests for whether something is a network interface:

* Is it configured with a unique address?

* Does it send and/or receive packetized data?

If it doesn't meet both of these conditions, it's not treated as a network interface by NetBox.

Not to put too fine a point on it but that's a tad short sighted. Not all networks require unique addressing.

1. In this instance GNSS doesn't need unique addressing since it's a peripheral point to point connection... or point to multi-point in the sense it's then distrubuted by a powered splitters.
2. Yes the interface receives GNSS data.

[bluikko]

whether something is a network interface

I agree that PPS port maybe would not fit as a "network interface".

But maybe it doesn't need to be a network interface? I see there are currently different port categories like "Console Ports" and "Console Server Ports".
Should there be a new category "Timing Ports"? Probably not, it seems a bit specific.
But how about "Miscellaneous Ports"? Or something similar?

Take a look at modern carrier network devices, they usually have several of these kind of interfaces.

[llamafilm]

If this is considered an Interface, then what else would also be considered an Interface? The list is long — USB, HDMI, VGA, RCA, SDI, XLR, SATA, SAS, Thunderbolt, S/PDIF, AES3...

I think it would be really cool to model all these things in Netbox, but that sounds like a major shift in direction for the product. I don't see anything special about GNSS to differentiate it from all these other non-network interfaces.

[bluikko]

If this is considered an Interface, then what else would also be considered an Interface? The list is long — USB, HDMI, VGA, RCA, SDI, XLR, SATA, SAS, Thunderbolt, S/PDIF, AES3...

I think it would be really cool to model all these things in Netbox, but that sounds like a major shift in direction for the product. I don't see anything special about GNSS to differentiate it from all these other non-network interfaces.

Some of these already exist as "front port".

What differentiates them from all the other connectors in your list is that they are common in carrier network devices as listed in my earlier comment.

[llamafilm]

I like the idea of adding a generic Ports section to each device, where users can add any number of arbitrary Port Types. A Port Type would include properties like physical connector, speed, protocol, and compatible mating Port Types. When connecting cables between two ports, it would restrict the choices to compatible mates. (For example USB-C can mate with USB-B-micro but not with SATA.)

[pobk]

Just a side note, per #17000, PPS != PTP. PTP is a stupidly complex protocol. PPS is a simple sync pulse receiver. It does not include any actual information. Typically it's used to sync a servo clock or onboard oscillator circuit in a network to a common timing sync source... Think about it like the digital equivalent of a pendulum. The time might not be right, but each tick of the clock will be accurate across all clocks in an office.

[pobk]

I like the idea of adding a generic Ports section to each device, where users can add any number of arbitrary Port Types. A Port Type would include properties like physical connector, speed, protocol, and compatible mating Port Types. When connecting cables between two ports, it would restrict the choices to compatible mates. (For example USB-C can mate with USB-B-micro but not with SATA.)

I might agree with you @llamafilm, a generic ports section does sound like an appropriate way to document this stuff. Console ports, seems a little too specialised given the nature of the ports themselves... it would then allow us to document other ports that are not then included under "console"... What about RS485 ports? MODBus? DALI, KNX, Profibus/Profinet 2-wire busses, NEMA 2000. Right now, none of this stuff can be effectively modelled in NetBox.

Just because they're not IP, does not mean they're not a network.

[pobk]

Has there been any further discussion on this?

[llamafilm]

@pobk if you agree with my proposal, then would you like to rewrite this feature request as such?

[pobk]

@llamafilm, while I agree a generic ports section might be an appropriate move forward... My feature request specifically addresses the need to document SM-A/SM-B types and elaborating on a "Ports" section goes outside of the scope of my specific requirement. Not to mention you've included some detail about type-mating etc, in your description which makes me nervous about hyperfocussing on detail and functionality.

How the developers of netbox choose to address this specific feature request (including closing this FR as wontfix), is also not something I'm willing to qualify.