Expand the maximum length of Cable #4563

@DanSheps commented on GitHub (Feb 22, 2021):

Is the direct connect provided by you? Is it provided by a ISP? If it is from a ISP, then you should be using "circuit". If it is your own fiber that you have installed between these two datacenters (unlikely), then perhaps this might be a valid case, however it would be better to, IMO, allow representation in KMs instead of increasing the field size.

I am guessing, but I suspect your use case is you purchased fiber from someone, in which case this should be modelled as a patch going to a circuit.

@DanSheps commented on GitHub (Feb 22, 2021): Is the direct connect provided by you? Is it provided by a ISP? If it is from a ISP, then you should be using "circuit". If it is your own fiber that you have installed between these two datacenters (unlikely), then perhaps this might be a valid case, however it would be better to, IMO, allow representation in KMs instead of increasing the field size. I am guessing, but I suspect your use case is you purchased fiber from someone, in which case this should be modelled as a patch going to a circuit.

adam commented

@xkilian commented on GitHub (Feb 23, 2021):

This is a valid use-case, think of all the gas, hydro, electrical, mining, public transit, transport and other utilities that have their own WAN or MAN using black fiber networks. They have right of way, so it makes sense for them to run black fiber all over the place, same for being present in places with no fiber to be leased. Sure long runs using 40 or 80KM optics are not common, but they are there.

@xkilian commented on GitHub (Feb 23, 2021): This is a valid use-case, think of all the gas, hydro, electrical, mining, public transit, transport and other utilities that have their own WAN or MAN using black fiber networks. They have right of way, so it makes sense for them to run black fiber all over the place, same for being present in places with no fiber to be leased. Sure long runs using 40 or 80KM optics are not common, but they are there.

adam commented

@xkilian commented on GitHub (Feb 23, 2021):

Maybe having an intelligent field that can recognize that the length is either in meters or kilometers might be interesting here?

@xkilian commented on GitHub (Feb 23, 2021): Maybe having an intelligent field that can recognize that the length is either in meters or kilometers might be interesting here?

adam commented

@TheNetworkGuy commented on GitHub (Mar 1, 2021):

I mean technically you are right. But how niche would this feature be? How many telco providers will use Netbox to:

Document their infrastructure
Use cables longer than 32 kilometers
Actually document the length of those cables in the "length" field in Netbox

In our case we do rely on (ring) circuits which extend over a long distance (far more than 32KM.) But even those circuits are managed by a 3rd party who provides a circuit ID etc.

@TheNetworkGuy commented on GitHub (Mar 1, 2021): I mean technically you are right. But how niche would this feature be? How many telco providers will use Netbox to: 1. Document their infrastructure 2. Use cables longer than 32 kilometers 3. Actually document the length of those cables in the "length" field in Netbox In our case we do rely on (ring) circuits which extend over a long distance (far more than 32KM.) But even those circuits are managed by a 3rd party who provides a circuit ID etc.

adam commented

@proudbro commented on GitHub (Mar 1, 2021):

@DanSheps , yes, we have our own 60km fiber bulk cables between datacenters and there are not provaded by ISP or any other third party companies.
It's easier to represent it as Cable (we have custom field "Magistral" to emphasize importance) between two rear ports that had been created for optical patch panels.

@proudbro commented on GitHub (Mar 1, 2021): @DanSheps , yes, we have our own 60km fiber bulk cables between datacenters and there are not provaded by ISP or any other third party companies. It's easier to represent it as Cable (we have custom field "Magistral" to emphasize importance) between two rear ports that had been created for optical patch panels.

adam commented

@jeremystretch commented on GitHub (Mar 1, 2021):

it would be better to, IMO, allow representation in KMs instead of increasing the field size

Agreed, although we also need to consider the absolute length value, which is calculated and stored behind the scenes for ordering.

@jeremystretch commented on GitHub (Mar 1, 2021): > it would be better to, IMO, allow representation in KMs instead of increasing the field size Agreed, although we also need to consider the absolute length value, which is calculated and stored behind the scenes for ordering.

adam commented

@vk5tu commented on GitHub (Apr 1, 2021):

My experience with fiber plant suggests that meters is the correct unit; as that the unit everything else reports (cableloggers, OTDRs, etc). The longest fiber run you're likely to see is around 300Km, but we still want to track that in meters as then a rackmounted OTDR can compare the fiber's current distance against the installed distance recorded in Netbox. For these very long runs a fault near one of the two ends is more likely than a midspan fault, and storing the length in kilometers will disguise faults in the final 500m or so.

@vk5tu commented on GitHub (Apr 1, 2021): My experience with fiber plant suggests that meters is the correct unit; as that the unit everything else reports (cableloggers, OTDRs, etc). The longest fiber run you're likely to see is around 300Km, but we still want to track that in meters as then a rackmounted OTDR can compare the fiber's current distance against the installed distance recorded in Netbox. For these very long runs a fault near one of the two ends is more likely than a midspan fault, and storing the length in kilometers will disguise faults in the final 500m or so.

adam commented

@jeremystretch commented on GitHub (Apr 21, 2021):

It seems that the outstanding question is how best to model a long-distance fiber run (one which spans many kilometers): Is it a cable, or a circuit? The answer seems to determine whether we implement this change or #6122.

Having given this some consideration, I think it's most appropriate to treat these runs as cables, since ultimately that's exactly what they are: very long cables. I see this as distinct from a circuit, which can comprise multiple cables and devices unknown and unimportant to the NetBox user; a circuit is a more abstract end-to-end physical connection between two points.

@jeremystretch commented on GitHub (Apr 21, 2021): It seems that the outstanding question is how best to model a long-distance fiber run (one which spans many kilometers): Is it a cable, or a circuit? The answer seems to determine whether we implement this change or #6122. Having given this some consideration, I think it's most appropriate to treat these runs as cables, since ultimately that's exactly what they are: very long cables. I see this as distinct from a circuit, which can comprise multiple cables and devices unknown and unimportant to the NetBox user; a circuit is a more abstract end-to-end physical connection between two points.

adam commented

@proudbro commented on GitHub (Apr 21, 2021):

@jeremystretch , Yes, that's right. It is easier to model these sections with cables. After all a circuit also requires cables to be connected at both points of connection to devices.

@proudbro commented on GitHub (Apr 21, 2021): @jeremystretch , Yes, that's right. It is easier to model these sections with cables. After all a circuit also requires cables to be connected at both points of connection to devices.

adam commented

@julianze commented on GitHub (Apr 22, 2021):

i would like the see those "long-distance fiber´s" as curcuits.

I see the difference between just "cables" and "circuits" in the way who is providing those paths.

Long cables between two buildings on one campus, i would define this as "cable".
the ownership of those cables are mostly the company itself, which place an order for road construction or civil engineering companies to lay the cable in the ground.

Circuits which are provided through an external party should be defined as circuit, so you can model the "Provider" with all it´s useful attributes (noc, admin contact, account number) and the circuit itself has required attributes (id, contract number, install date).
Okay "commit rate" wouldn´t be required for a physical fiber because it depends on the optics.
Those cable´s are paid on a monthly/yearly fee.

We as a german internet service provider buying long-distance fibers from municipal utilities (sorry, i don´t know how "Stadtwerke" are called correctly outside germany), local or global fiber carrier. Some of them are for our backbone to connect network nodes, Partly they are used for connecting customer locations to the next network nodes.

When i model those circuits as cables, i lost the information of the provider an the above described attribtues of an circuit.

But i a agree, that especially those long-distance fiber´s are an special type of circuits, which is very similar to just cables.

@jeremystretch, we have optical patch panels between sites (server rooms are located in different cities) which connected directly by fiber cables to each other. I thought the right way to model that connection is to create cable which connected each rear port combining all front ports on every single patch panel. Why it should be circuit? Or it should and I just misunderstood the sense of circuit?

@proudbro are the cables between the different cities in you ownership or are there laid and provided through a company / ISP / carrier?
I think you model this in your use case as cables to have a valid length of the end-to-end path between the patch panels, right?

see also the question from @DanSheps :

Is the direct connect provided by you? Is it provided by a ISP? If it is from a ISP, then you should be using "circuit". If it is your own fiber that you have installed between these two datacenters (unlikely), then perhaps this might be a valid case, however it would be better to, IMO, allow representation in KMs instead of increasing the field size.

I am guessing, but I suspect your use case is you purchased fiber from someone, in which case this should be modelled as a patch going to a circuit.

@julianze commented on GitHub (Apr 22, 2021): i would like the see those "long-distance fiber´s" as curcuits. I see the difference between just "cables" and "circuits" in the way who is providing those paths. Long cables between two buildings on one campus, i would define this as "cable". the ownership of those cables are mostly the company itself, which place an order for road construction or civil engineering companies to lay the cable in the ground. Circuits which are provided through an external party should be defined as circuit, so you can model the "Provider" with all it´s useful attributes (noc, admin contact, account number) and the circuit itself has required attributes (id, contract number, install date). Okay "commit rate" wouldn´t be required for a physical fiber because it depends on the optics. Those cable´s are paid on a monthly/yearly fee. We as a german internet service provider buying long-distance fibers from municipal utilities (sorry, i don´t know how "Stadtwerke" are called correctly outside germany), local or global fiber carrier. Some of them are for our backbone to connect network nodes, Partly they are used for connecting customer locations to the next network nodes. When i model those circuits as cables, i lost the information of the provider an the above described attribtues of an circuit. But i a agree, that especially those long-distance fiber´s are an special type of circuits, which is very similar to just cables. > @jeremystretch, we have optical patch panels between sites (server rooms are located in different cities) which connected directly by fiber cables to each other. I thought the right way to model that connection is to create cable which connected each rear port combining all front ports on every single patch panel. Why it should be circuit? Or it should and I just misunderstood the sense of circuit? @proudbro are the cables between the different cities in you ownership or are there laid and provided through a company / ISP / carrier? I think you model this in your use case as cables to have a valid length of the end-to-end path between the patch panels, right? see also the question from @DanSheps : > Is the direct connect provided by you? Is it provided by a ISP? If it is from a ISP, then you should be using "circuit". If it is your own fiber that you have installed between these two datacenters (unlikely), then perhaps this might be a valid case, however it would be better to, IMO, allow representation in KMs instead of increasing the field size. > > I am guessing, but I suspect your use case is you purchased fiber from someone, in which case this should be modelled as a patch going to a circuit.

adam commented

@proudbro commented on GitHub (Apr 22, 2021):

@julianze , we have our own cables in use between two cities which roughly 40000 meters long. These optical bulk cables between fiber crosses (optical patch panels) we use ourselves for our purposes and provide individual fibers (dark fiber) to our customers. I've planned to model it as Cables but came across the lengh limitation.

At the same time we rent several wavelengths from an uplink provider between other cities (more than 800000m including many intermediate nodes like amplifiers). It is more correct to model as circuits.

@proudbro commented on GitHub (Apr 22, 2021): @julianze , we have our own cables in use between two cities which roughly 40000 meters long. These optical bulk cables between fiber crosses (optical patch panels) we use ourselves for our purposes and provide individual fibers (dark fiber) to our customers. I've planned to model it as Cables but came across the lengh limitation. At the same time we rent several wavelengths from an uplink provider between other cities (more than 800000m including many intermediate nodes like amplifiers). It is more correct to model as circuits.

adam commented

@jeremystretch commented on GitHub (Apr 22, 2021):

IMO if you own and operate the fiber itself, you care about the length and should model it as a cable. If not, meaning a provider is responsible for it, you don't care about the length (or the physical path in general), and should model it as a circuit. Does that sound reasonable?

If so, this means we:

Support longer lengths for cables
Don't add a length attribute to the Circuit model

@jeremystretch commented on GitHub (Apr 22, 2021): IMO if you own and operate the fiber itself, you care about the length and should model it as a cable. If not, meaning a provider is responsible for it, you don't care about the length (or the physical path in general), and should model it as a circuit. Does that sound reasonable? If so, this means we: 1. Support longer lengths for cables 2. Don't add a length attribute to the Circuit model

adam commented

@BarbarossaTM commented on GitHub (Apr 22, 2021):

IMO if you own and operate the fiber itself, you care about the length and should model it as a cable. If not, meaning a provider is responsible for it, you don't care about the length (or the physical path in general), and should model it as a circuit. Does that sound reasonable?

I would argue that when you rent a dark fiber (so not your own physical cable) a circuit would fit better as it has the provider relationship already in place. But as it is a darf fiber knowing the length still is necessary to chose the correct optics/WDM equipment etc. This obviously would mean both length fields are required, which would provide more flexibilty, too.

@BarbarossaTM commented on GitHub (Apr 22, 2021): > IMO if you own and operate the fiber itself, you care about the length and should model it as a cable. If not, meaning a provider is responsible for it, you don't care about the length (or the physical path in general), and should model it as a circuit. Does that sound reasonable? I would argue that when you rent a dark fiber (so not your own physical cable) a circuit would fit better as it has the provider relationship already in place. But as it is a darf fiber knowing the length still is necessary to chose the correct optics/WDM equipment etc. This obviously would mean both length fields are required, which would provide more flexibilty, too.

adam commented

@xkilian commented on GitHub (Apr 22, 2021):

As a MAN private entity, we have all three cases, and length should be provided for dark fiber runs that are rented "cables", as stated by BarbarossaTM it helps choose the right optics. The length attribute for circuits should be optional. As 90% of cases do not need it, but dark fiber runs do need it. And I agree with wholelly owned long fiber be modelled as cables.

@xkilian commented on GitHub (Apr 22, 2021): As a MAN private entity, we have all three cases, and length should be provided for dark fiber runs that are rented "cables", as stated by BarbarossaTM it helps choose the right optics. The length attribute for circuits should be optional. As 90% of cases do not need it, but dark fiber runs do need it. And I agree with wholelly owned long fiber be modelled as cables.

adam commented

@julianze commented on GitHub (Apr 25, 2021):

i think both scenarios are valid and exists out there,
So i am in favor implementing both.

May i can volunteer for #6122, but it would be my first time in developing with netbox and will probably need some support.

@julianze commented on GitHub (Apr 25, 2021): i think both scenarios are valid and exists out there, So i am in favor implementing both. May i can volunteer for #6122, but it would be my first time in developing with netbox and will probably need some support.

adam commented