Assign ASN to prefix and device #6161

@github-actions[bot] commented on GitHub (May 3, 2022):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@github-actions[bot] commented on GitHub (May 3, 2022): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).

adam commented

@peterbaumert commented on GitHub (May 5, 2022):

I agree with @PieterL75 as ASNs, prefixes, devices are already part of netbox it makes sense that one can actually tie them together properly, Currently i can add a Site for an ASN or add it to a RIR. But at least the Sites part is not accurate, so why not change this to actually reflect real world usage?

@peterbaumert commented on GitHub (May 5, 2022): I agree with @PieterL75 as ASNs, prefixes, devices are already part of netbox it makes sense that one can actually tie them together properly, Currently i can add a Site for an ASN or add it to a RIR. But at least the Sites part is not accurate, so why not change this to actually reflect real world usage?

adam commented

@DanSheps commented on GitHub (May 9, 2022):

Real world, they aren't tied to prefixes either, they are tied to routing instances on devices, so I can see the use case for a device, but not for a prefix.

As Jeremy mentioned, this can be achieved with custom object fields.

@DanSheps commented on GitHub (May 9, 2022): Real world, they aren't tied to prefixes either, they are tied to routing instances on devices, so I can see the use case for a device, but not for a prefix. As Jeremy mentioned, this can be achieved with custom object fields.

adam commented

@PieterL75 commented on GitHub (May 9, 2022):

I tend to disagree an that Daniel.
Public ip addresses are bound to asn numbers (RIR/LIR)
Internally we also assign prefixes to asns...

And a asn is used on a device, not assigned to it. One device can have multiple asns ( different vrf, underlays, overlays, ...)

@PieterL75 commented on GitHub (May 9, 2022): I tend to disagree an that Daniel. Public ip addresses are bound to asn numbers (RIR/LIR) Internally we also assign prefixes to asns... And a asn is used on a device, not assigned to it. One device can have multiple asns ( different vrf, underlays, overlays, ...)

adam commented

@jeremystretch commented on GitHub (May 9, 2022):

Public ip addresses are bound to asn numbers (RIR/LIR)

There is no direct correlation between the two types of records. A prefix can be advertised via any ASN belonging to the organization to which it has been allocated.

@jeremystretch commented on GitHub (May 9, 2022): > Public ip addresses are bound to asn numbers (RIR/LIR) There is no direct correlation between the two types of records. A prefix can be advertised via any ASN belonging to the organization to which it has been allocated.

adam commented

@PieterL75 commented on GitHub (May 9, 2022):

Prefix are bound to ASNs and will they only be announced over one AS (in most use cases).
Typically you'll create a ROA (RPKI) record to digitally sign the link between an prefix and an AS, so that it cannot be announced by any other AS than the one you own.

I don't see many use cases to announce one prefix with multiple ASN's (except for migration and anycast purposes)

@PieterL75 commented on GitHub (May 9, 2022): Prefix are bound to ASNs and will they only be announced over one AS (in most use cases). Typically you'll create a ROA (RPKI) record to digitally sign the link between an prefix and an AS, so that it cannot be announced by any other AS than the one you own. I don't see many use cases to announce one prefix with multiple ASN's (except for migration and anycast purposes)

adam commented

@PieterL75 commented on GitHub (May 16, 2022):

I don't understand why this FR is such a problem. It reflects how ASN really work for ISP's and MSP's.
How can I keep track in netbox of what prefixes we announce under what ASN ?
How can I keep track of what device has what ASN in my ebgp vxlan underlay ?

@PieterL75 commented on GitHub (May 16, 2022): I don't understand why this FR is such a problem. It reflects how ASN really work for ISP's and MSP's. How can I keep track in netbox of what prefixes we announce under what ASN ? How can I keep track of what device has what ASN in my ebgp vxlan underlay ?

adam commented

@jcralbino commented on GitHub (May 31, 2022):

In a modern datacenter the BGP is also used provide connectivity to other routing devices, one use case is this one https://datatracker.ietf.org/doc/html/rfc7938

Even in a Datacenter where ACI is deployed is the recommended option for External Connectivity integration with other routing devices.

I believe we that assigning ASN to a device is something to be part of the Core in order to model real modern data center environments.

@jcralbino commented on GitHub (May 31, 2022): In a modern datacenter the BGP is also used provide connectivity to other routing devices, one use case is this one https://datatracker.ietf.org/doc/html/rfc7938 Even in a Datacenter where ACI is deployed is the recommended option for External Connectivity integration with other routing devices. I believe we that assigning ASN to a device is something to be part of the Core in order to model real modern data center environments.

adam commented

@PieterL75 commented on GitHub (May 31, 2022):

@jeremystretch can you remove the pending closure tag?
This does feel like there is traction from the community to have asns relate to devices and prefixes

@PieterL75 commented on GitHub (May 31, 2022): @jeremystretch can you remove the pending closure tag? This does feel like there is traction from the community to have asns relate to devices and prefixes

adam commented

@DanSheps commented on GitHub (Jun 1, 2022):

I don't understand why this FR is such a problem. It reflects how ASN really work for ISP's and MSP's. How can I keep track in netbox of what prefixes we announce under what ASN ? How can I keep track of what device has what ASN in my ebgp vxlan underlay ?

To be very blunt, no it doesn't; at least not to prefixes (devices I can see). What you want is something that models routing.

@jeremystretch can you remove the pending closure tag? This does feel like there is traction from the community to have asns relate to devices and prefixes

There is 1 upvote on the main description, this isn't traction from the community.

@DanSheps commented on GitHub (Jun 1, 2022): > I don't understand why this FR is such a problem. It reflects how ASN really work for ISP's and MSP's. How can I keep track in netbox of what prefixes we announce under what ASN ? How can I keep track of what device has what ASN in my ebgp vxlan underlay ? To be very blunt, no it doesn't; at least not to prefixes (devices I can see). What you want is something that models routing. > @jeremystretch can you remove the pending closure tag? This does feel like there is traction from the community to have asns relate to devices and prefixes There is 1 upvote on the main description, this isn't traction from the community.

adam commented

@jeremystretch commented on GitHub (Jun 1, 2022):

There are two components to this FR:

Relating prefixes to ASNs
Relating devices to ASNs

Regarding the first part, as I noted above, there is no direct relationship between a prefix and an ASN in reality; the ASN(s) associated with a prefix are a function of the devices/sites advertising it. So, we're not going to implement this.

Regarding the second part, while I agree that it makes sense to model a relationship between devices and ASNs, more consideration needs to be invested into how and when this should be implemented. I don't think it makes sense to introduce a direct relationship now without any planning with respect to potential future modeling of routing adjacencies and policies. (For example, a BGP router may be configured to advertise different ASNs to different peers. Your proposed implementation would not support this.) This is part of a much larger discussion we have yet to hold concerning the modeling of routing topologies in general.

Of course, if you want to model direct relationships between ASNs and prefixes or devices right now, you can do so in NetBox v3.2 using custom fields.

@jeremystretch commented on GitHub (Jun 1, 2022): There are two components to this FR: 1. Relating prefixes to ASNs 2. Relating devices to ASNs Regarding the first part, as I noted above, there is no direct relationship between a prefix and an ASN in reality; the ASN(s) associated with a prefix are a function of the devices/sites advertising it. So, we're not going to implement this. Regarding the second part, while I agree that it makes sense to model a relationship between devices and ASNs, more consideration needs to be invested into how and when this should be implemented. I don't think it makes sense to introduce a direct relationship now without any planning with respect to potential future modeling of routing adjacencies and policies. (For example, a BGP router may be configured to advertise different ASNs to different peers. Your proposed implementation would not support this.) This is part of a much larger discussion we have yet to hold concerning the modeling of routing topologies in general. Of course, if you want to model direct relationships between ASNs and prefixes or devices right now, you can do so in NetBox v3.2 using custom fields.

adam commented

@PieterL75 commented on GitHub (Jun 1, 2022):

Prefixes are linked to ASN's... ex: https://bgp.he.net/AS16591#_prefixes
This is in the ISP/MSP world of course. I can imagine that most companies take public IPs from ISP and don't care about the ASN their prefix is linked to. In our case that is real world, and I can imagine that there will be a lot of future customers that think the same.

One device should be able to contain multiple AS numbers. Each VRF/RI can have its own AS, and you can also 'pretend' to be another ASN.

I do follow that you see this as a part of a bigger discussion to implement routing/asn/route protocols/... more detailed.

Too bad that you as maintainer downvote this discussion. We can/may/must differ on opinion.

I'll take the customfield approach for now, but that one lacks the searchability and deeper insigths.

Pieter

PS: I'm not native English, so please don't think I'm rude or anything... Just trying to express my thoughts :-S

@PieterL75 commented on GitHub (Jun 1, 2022): Prefixes are linked to ASN's... ex: https://bgp.he.net/AS16591#_prefixes This is in the ISP/MSP world of course. I can imagine that most companies take public IPs from ISP and don't care about the ASN their prefix is linked to. In our case that is real world, and I can imagine that there will be a lot of future customers that think the same. One device should be able to contain multiple AS numbers. Each VRF/RI can have its own AS, and you can also 'pretend' to be another ASN. I do follow that you see this as a part of a bigger discussion to implement routing/asn/route protocols/... more detailed. Too bad that you as maintainer downvote this discussion. We can/may/must differ on opinion. I'll take the customfield approach for now, but that one lacks the searchability and deeper insigths. Pieter PS: I'm not native English, so please don't think I'm rude or anything... Just trying to express my thoughts :-S

adam commented

https://github.com/peering-manager/peering-manager/discussions/498

@jcralbino commented on GitHub (Jun 1, 2022):

Although I would like to have this implemented in netbox , association of a BGP ASN to device I do understand that providing only they it may lack in providing what will be a

future modeling of routing adjacencies and policies

I have stumbled at some point on this tool Peering Manager, that is sharing the same technology stack , being a django app.

Maybe it could be interesting to see how netbox and Peering manager can integrate better and complement their models

Here is one of the discussion within that project that may be relevant here

@jcralbino commented on GitHub (Jun 1, 2022): Although I would like to have this implemented in netbox , association of a BGP ASN to device I do understand that providing only they it may lack in providing what will be a > future modeling of routing adjacencies and policies I have stumbled at some point on this tool Peering Manager, that is sharing the same technology stack , being a django app. Maybe it could be interesting to see how netbox and Peering manager can integrate better and complement their models Here is one of the discussion within that project that may be relevant here https://github.com/peering-manager/peering-manager/discussions/498

adam commented

@jeremystretch commented on GitHub (Jul 27, 2022):

I think further discussion is needed to figure out where this overlaps and/or conflicts with #9828.

@jeremystretch commented on GitHub (Jul 27, 2022): I think further discussion is needed to figure out where this overlaps and/or conflicts with #9828.

adam commented

@nickper commented on GitHub (Aug 15, 2022):

I'm also throwing my opinion into this.
For us an assignment to an device is not good enough. We actually do ASN rewrites in our core router for our clients.
For now we use the solution of a custom field on the aggregate where we note the ASN.

Problem is that on our new stredged DC platform that uses a bgp overlay with different asn's per pop, and the private 10.x.x.x space for between pop communication. This custom field setup doesn't suffice anymore.

A coupling to prefixes would be nice to have in that case. (as an optional field ofc)

When I look to RPKI in relation to Aggregate/prefixes, I would say that it is better to relate it to Prefixes instead of aggregates.
I see aggregates as ranges provides by the LIR, which in turn can turned into smaller Prefixes/subnets for their respective purposes.
These can have different ASN's, most specific announcements etc. So a linkage between RPKI and prefixes would also be more logical.

@nickper commented on GitHub (Aug 15, 2022): I'm also throwing my opinion into this. For us an assignment to an device is not good enough. We actually do ASN rewrites in our core router for our clients. For now we use the solution of a custom field on the aggregate where we note the ASN. Problem is that on our new stredged DC platform that uses a bgp overlay with different asn's per pop, and the private 10.x.x.x space for between pop communication. This custom field setup doesn't suffice anymore. A coupling to prefixes would be nice to have in that case. (as an optional field ofc) When I look to RPKI in relation to Aggregate/prefixes, I would say that it is better to relate it to Prefixes instead of aggregates. I see aggregates as ranges provides by the LIR, which in turn can turned into smaller Prefixes/subnets for their respective purposes. These can have different ASN's, most specific announcements etc. So a linkage between RPKI and prefixes would also be more logical.

adam commented

@ThomasADavis commented on GitHub (Sep 21, 2022):

I just opened an issue for this, not realizing it's already under discussion..

We need ASN's assigned to devices for VXLAN/EVPN usage. Spines have the same ASN - and there can be multiple spine switches. Leafs need their own ASN assigned, different from the each other and the spines.

I simply would like to see the ASN's assigned to devices show up on the devices page..

Currently using the custom field with the ASN object, but there's no way I know of to have the custom field show both in the device view and the ASN view. Assigning multiple objects to the custom field assigned objects/models doesn't tie the ASN object custom field to the device object custom field - they are two different custom fields.

@ThomasADavis commented on GitHub (Sep 21, 2022): I just opened an issue for this, not realizing it's already under discussion.. We need ASN's assigned to devices for VXLAN/EVPN usage. Spines have the same ASN - and there can be multiple spine switches. Leafs need their own ASN assigned, different from the each other and the spines. I simply would like to see the ASN's assigned to devices show up on the devices page.. Currently using the custom field with the ASN object, but there's no way I know of to have the custom field show both in the device view and the ASN view. Assigning multiple objects to the custom field assigned objects/models doesn't tie the ASN object custom field to the device object custom field - they are two different custom fields.

adam commented

@cyberndj commented on GitHub (Oct 31, 2022):

Howdy,
I was going through our company and our IPAM info doing some adds arround ASNs, Aggregates and Prefixes and I would like to share my thoughts. For context, here is how I am viewing the following terms:

RIR - An agency that assigns Aggregates/Prefixes and AS-Numbers to companies.
ASN - a collection of connected (IP) routing prefixes Wikipedia
Aggregates - A collection of different IP Prefixes
Prefixes- A collection of specific IP addresses in sequence
Providers - A company that owns/controls different ASN's and/or Aggregates/Prefixes

The NetBox BGP Plugin (https://github.com/k01ek/netbox-bgp) can be a good plugin to help managing the more detailed requests from others regarding what ASNs/Prefixes are being assigned to a device and how they are peered/configured with other ASNs/Devices. The plugin might also be a better place for RPKI's/ROI's than NetBox Core. I believe the plugin was recently updated to use the NetBox Core Prefix/RIR/Aggregates/ASN items vs its plugin specific items.
When I added Aggregates I noticed that the different prefixes I had configured showed up in a usage view like prefixes with child objects.
Aggregates and ASN's both require a RIR to be configured.
While looking at RIRs, only Aggregates show up, but not ASNs.

Some things that make me go hmmm......

I have seen a Prefix be apart of two different ASN's ie, a /29 is part of ASN for a regional ISP (ie a /22 Aggregate), but also falls into a parent ASN for a more national company like Century Link (ie a /13 Aggregate)
Similar observation, in @PieterL75's Google Fiber link, there are two Aggregates (136.58.96.0/19 & 136.32.0.0/11) listed for the same prefix (136.58.112.0/20) listed for the same ASN (16591).
NetBox Aggregates do not support parent/child relationships like prefixes do.
I don't see any assignment of ASN's to Providers.

Possible Solution 1

Assign Aggregates to ASNs and/or Providers (/ipam/aggregates/#/edit)
Have ASN's show up as assigned in RIR's and Providers
Allow parent/child Aggregates

Possible Solution 2

Remove Aggregates completely.
Add option for Prefix status to be Aggregate (/ipam/prefixes/#)
Allow Prefixes to be assigned to ASNs and/or Providers (/ipam/prefixes/#)
Show an assigned ASN section under Providers (/circuits/providers/#)
Show a section of Prefixes for ASNs (/ipam/asns/#)
Move RIRs and ASNs to Prefixes section in the side menu

I also noticed that the ASN field for Providers has a depreciation note. That is a good touch and possibly can be done if solution 2 is accepted.

I know this might not appease all use cases or be a perfect solution, but hopefully it will get us all closer to real-world usage.
Thanks!
-Jake

@cyberndj commented on GitHub (Oct 31, 2022): Howdy, I was going through our company and our IPAM info doing some adds arround ASNs, Aggregates and Prefixes and I would like to share my thoughts. For context, here is how I am viewing the following terms: RIR - An agency that assigns Aggregates/Prefixes and AS-Numbers to companies. ASN - a collection of connected (IP) routing prefixes [Wikipedia](https://en.wikipedia.org/wiki/Autonomous_system_(Internet)) Aggregates - A collection of different IP Prefixes Prefixes- A collection of specific IP addresses in sequence Providers - A company that owns/controls different ASN's and/or Aggregates/Prefixes - The NetBox BGP Plugin (https://github.com/k01ek/netbox-bgp) can be a good plugin to help managing the more detailed requests from others regarding what ASNs/Prefixes are being assigned to a device and how they are peered/configured with other ASNs/Devices. The plugin might also be a better place for RPKI's/ROI's than NetBox Core. I believe the plugin was recently updated to use the NetBox Core Prefix/RIR/Aggregates/ASN items vs its plugin specific items. - When I added Aggregates I noticed that the different prefixes I had configured showed up in a usage view like prefixes with child objects. - Aggregates and ASN's both require a RIR to be configured. - While looking at RIRs, only Aggregates show up, but not ASNs. Some things that make me go hmmm...... - I have seen a Prefix be apart of two different ASN's ie, a /29 is part of ASN for a regional ISP (ie a /22 Aggregate), but also falls into a parent ASN for a more national company like Century Link (ie a /13 Aggregate) - Similar observation, in @PieterL75's Google Fiber link, there are two Aggregates (136.58.96.0/19 & 136.32.0.0/11) listed for the same prefix (136.58.112.0/20) listed for the same ASN (16591). - NetBox Aggregates do not support parent/child relationships like prefixes do. - I don't see any assignment of ASN's to Providers. Possible Solution 1 - Assign Aggregates to ASNs and/or Providers (/ipam/aggregates/#/edit) - Have ASN's show up as assigned in RIR's and Providers - Allow parent/child Aggregates Possible Solution 2 - Remove Aggregates completely. - Add option for Prefix status to be Aggregate (/ipam/prefixes/#) - Allow Prefixes to be assigned to ASNs and/or Providers (/ipam/prefixes/#) - Show an assigned ASN section under Providers (/circuits/providers/#) - Show a section of Prefixes for ASNs (/ipam/asns/#) - Move RIRs and ASNs to Prefixes section in the side menu I also noticed that the ASN field for Providers has a depreciation note. That is a good touch and possibly can be done if solution 2 is accepted. I know this might not appease all use cases or be a perfect solution, but hopefully it will get us all closer to real-world usage. Thanks! -Jake

adam commented

@github-actions[bot] commented on GitHub (Dec 31, 2022):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Dec 31, 2022): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).

adam commented

@nickper commented on GitHub (Jan 10, 2023):

@cyberndj I think for some of your findings you should create an bug report.

For reference to the rest, I tested the custom object links in v3.3.10 (already released in 3.2) and that seems to be sufficient for me. It is a better solution than a custom field.

@nickper commented on GitHub (Jan 10, 2023): @cyberndj I think for some of your findings you should create an bug report. For reference to the rest, I tested the custom object links in v3.3.10 (already released in 3.2) and that seems to be sufficient for me. It is a better solution than a custom field.

adam commented

@tgreer commented on GitHub (Mar 19, 2023):

Can I just add that assigning ASN to Prefixes is most sensible. I have multiple devices advertising the same routes under the same ASN, sometimes in different sites.

@tgreer commented on GitHub (Mar 19, 2023): Can I just add that assigning ASN to Prefixes is most sensible. I have multiple devices advertising the same routes under the same ASN, sometimes in different sites.

adam commented

@jeremystretch commented on GitHub (May 2, 2023):

After reviewing this yet again, I'm convinced it does not make sense to implement any of the proposed relationships directly among ASNs, devices, and prefixes, because doing so ignores the very real implications and caveats of routing policy. A device, for instance, can advertise different prefixes as originating from different ASNs. Conversely, a prefix can "belong" to one ASN or to multiple ASNs: Either condition can be valid or invalid depending on the configured policy. An implementation which purposely ignores these details precludes a great degree of functionality and would be a disservice to our users.

Instead, I propose that these ideas be implemented in a separate plugin expressly designed to model routing policy. We can achieve much greater flexibility by introducing an intermediate object representative of routing policy to correlate ASNs, devices, and prefixes, while simultaneously unlocking additional functionality around routing metrics, filter lists, etc.

@jeremystretch commented on GitHub (May 2, 2023): After reviewing this yet again, I'm convinced it does not make sense to implement any of the proposed relationships directly among ASNs, devices, and prefixes, because doing so ignores the very real implications and caveats of routing policy. A device, for instance, can advertise different prefixes as originating from different ASNs. Conversely, a prefix can "belong" to one ASN or to multiple ASNs: Either condition can be valid or invalid depending on the configured policy. An implementation which purposely ignores these details precludes a great degree of functionality and would be a disservice to our users. Instead, I propose that these ideas be implemented in a separate plugin expressly designed to model routing policy. We can achieve much greater flexibility by introducing an intermediate object representative of routing policy to correlate ASNs, devices, and prefixes, while simultaneously unlocking additional functionality around routing metrics, filter lists, etc.

adam commented

@jeremystretch commented on GitHub (May 4, 2023):

#11844 was raised to propose the assignment of ASNs to aggregates as well. Folding that into this discussion.

@jeremystretch commented on GitHub (May 4, 2023): #11844 was raised to propose the assignment of ASNs to aggregates as well. Folding that into this discussion.

adam commented

@PieterL75 commented on GitHub (May 24, 2023):

Lets get the discussion going then.
I would like to the possibility to link an ASN to

device
prefix
aggregate

Justification
Device:
In EVPN each device is assigned a dedicated ASN. This ASN is used in config generations for EVPN

Prefix:
We have several ASNs that announce their prefixes to the internet. Being able to assing an ASN to a prefix, helps us to document this.
These prefixes are also linked to the ASN in the LIR portals (RIPE)

Aggregate:
Aggregates are super-prefixes that are handed out by a LIR. In the LIR portal, these aggregates are typically linked to the owners ASN.

I noticed that there is plugin request for ROA records. Implementing this FR, would benefit that plugin to only store the ROA records, and not the ASN logic

@PieterL75 commented on GitHub (May 24, 2023): Lets get the discussion going then. I would like to the possibility to link an ASN to - device - prefix - aggregate Justification Device: In EVPN each device is assigned a dedicated ASN. This ASN is used in config generations for EVPN Prefix: We have several ASNs that announce their prefixes to the internet. Being able to assing an ASN to a prefix, helps us to document this. These prefixes are also linked to the ASN in the LIR portals (RIPE) Aggregate: Aggregates are super-prefixes that are handed out by a LIR. In the LIR portal, these aggregates are typically linked to the owners ASN. I noticed that there is plugin request for ROA records. Implementing this FR, would benefit that plugin to only store the ROA records, and not the ASN logic

adam commented

@DanSheps commented on GitHub (May 24, 2023):

Honestly, I think that all of these "Routing Policy" settings should be in a plugin. It makes the most sense as not everyone will want/need to model routing policy.

@DanSheps commented on GitHub (May 24, 2023): Honestly, I think that all of these "Routing Policy" settings should be in a plugin. It makes the most sense as not everyone will want/need to model routing policy.

adam commented

@peterbaumert commented on GitHub (May 24, 2023):

Honestly, I think that all of these "Routing Policy" settings should be in a plugin. It makes the most sense as not everyone will want/need to model routing policy.

But then everything else regarding routing, like RIRs, ASNs, etc should be remove from core as well. So either model all or none in core and the rest to a plugin.

@peterbaumert commented on GitHub (May 24, 2023): > Honestly, I think that all of these "Routing Policy" settings should be in a plugin. It makes the most sense as not everyone will want/need to model routing policy. But then everything else regarding routing, like RIRs, ASNs, etc should be remove from core as well. So either model all or none in core and the rest to a plugin.

adam commented

@cyberndj commented on GitHub (May 24, 2023):

Howdy,
Some thoughts...

not everyone will want/need to model routing policy.
I think that this is a bad take because essentially, you (aka devs) are making an "forced-out" approach onto everyone. For those that don't want to do this type of modeling, the answer is to just not to make the association.

While the plugin idea is an option, the suggestion to move it comes across as...laziness to make the best product available. Like @peterbaumert put it

either model all or none

...but by adding the models/relationships, you are supporting the plugins to do more of their routing specific stuff by making the core models standardized.

The core premise of NetBox which is "the leading solution for modeling and documenting modern networks" and "the ideal 'source of truth'". Adding the relationship will let different companies model what their networks are and help solidify their own network truth. For those that don't want to utilize the relationships, they don't have to. Therefore, the "opt-in" approach should be implemented.

v/r
Jake

@cyberndj commented on GitHub (May 24, 2023): Howdy, Some thoughts... >not everyone will want/need to model routing policy. I think that this is a bad take because essentially, you (aka devs) are making an "forced-out" approach onto everyone. For those that don't want to do this type of modeling, the answer is to just not to make the association. While the plugin idea is an option, the suggestion to move it comes across as...laziness to make the best product available. Like @peterbaumert put it > either model all or none ...but by adding the models/relationships, you are supporting the plugins to do more of their routing specific stuff by making the core models standardized. The core premise of NetBox which is "the leading solution for modeling and documenting modern networks" and "the ideal 'source of truth'". Adding the relationship will let different companies model what their networks are and help solidify their own network truth. For those that don't want to utilize the relationships, they don't have to. Therefore, the "opt-in" approach should be implemented. v/r Jake

adam commented

@jeremystretch commented on GitHub (May 24, 2023):

But then everything else regarding routing, like RIRs, ASNs, etc should be remove from core as well.

These were added to address unrelated use cases.

@jeremystretch commented on GitHub (May 24, 2023): > But then everything else regarding routing, like RIRs, ASNs, etc should be remove from core as well. These were added to address unrelated use cases.

adam commented

@PieterL75 commented on GitHub (May 24, 2023):

Still wondering why an ASN can be linked to a Site... Never saw a building with AS12345 on it :-)

@PieterL75 commented on GitHub (May 24, 2023): Still wondering why an ASN can be linked to a Site... Never saw a building with AS12345 on it :-)

adam commented

@jeremystretch commented on GitHub (May 24, 2023):

If you consider use cases beyond your own it will make sense.

@jeremystretch commented on GitHub (May 24, 2023): If you consider use cases beyond your own it will make sense.

adam commented