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

@jeremystretch commented on GitHub (May 29, 2024):

typically used for GNSS antennas and 1PPS timing interfaces

These do not sound like network interfaces.

@jeremystretch commented on GitHub (May 29, 2024): > typically used for GNSS antennas and 1PPS timing interfaces These do not sound like network interfaces.

adam commented

@pobk commented on GitHub (Jun 5, 2024):

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

@pobk commented on GitHub (Jun 5, 2024): 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.~~

adam commented

@bluikko commented on GitHub (Jul 24, 2024):

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.

@bluikko commented on GitHub (Jul 24, 2024): 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.

adam commented

@pobk commented on GitHub (Jul 29, 2024):

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 commented on GitHub (Jul 29, 2024): 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.

adam commented

@pobk commented on GitHub (Aug 14, 2024):

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 commented on GitHub (Aug 14, 2024): 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?

adam commented

@pobk commented on GitHub (Aug 14, 2024):

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.

@pobk commented on GitHub (Aug 14, 2024): I've changed my mind. As I [mentioned elsehwere](https://github.com/netbox-community/netbox/issues/16999#issuecomment-2288259167), 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.

adam commented

@jeremystretch commented on GitHub (Aug 14, 2024):

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.

@jeremystretch commented on GitHub (Aug 14, 2024): 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.

adam commented

@pobk commented on GitHub (Aug 14, 2024):

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.

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.
Yes the interface receives GNSS data.

@pobk commented on GitHub (Aug 14, 2024): > 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.

adam commented

@bluikko commented on GitHub (Aug 15, 2024):

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.

@bluikko commented on GitHub (Aug 15, 2024): > 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.

adam commented

@llamafilm commented on GitHub (Aug 15, 2024):

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.

@llamafilm commented on GitHub (Aug 15, 2024): 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.

adam commented

@bluikko commented on GitHub (Aug 15, 2024):

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.

@bluikko commented on GitHub (Aug 15, 2024): > 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.

adam commented

@llamafilm commented on GitHub (Aug 23, 2024):

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

@llamafilm commented on GitHub (Aug 23, 2024): 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.)

adam commented

@pobk commented on GitHub (Sep 6, 2024):

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 commented on GitHub (Sep 6, 2024): 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.

adam commented