Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IDEA: ASDOT notation #29

Closed
mzbroch opened this issue Mar 7, 2022 · 8 comments · Fixed by #205
Closed

IDEA: ASDOT notation #29

mzbroch opened this issue Mar 7, 2022 · 8 comments · Fixed by #205

Comments

@mzbroch
Copy link
Contributor

mzbroch commented Mar 7, 2022

Environment

  • Nautobot version: 1.5.0
  • nautobot-bgp-models version: 0.7.1

Proposed Functionality

32-bit ASN notations. Nautobot should be able to read and convert ASN between AS plain and AS dot notations.

Use Case

This enables human readable ASNs.

@cmacnevin
Copy link

Any large scale modern layer 3 data center relies on 4-byte ASNs, which are most often represented using asdot notation. Definitely agree this is a necessity.

@mzbroch
Copy link
Contributor Author

mzbroch commented Sep 9, 2022

Any large scale modern layer 3 data center relies on 4-byte ASNs, which are most often represented using asdot notation. Definitely agree this is a necessity.

We could explore how this could be implemented in a way to keep the consistency between UI/REST/GraphQL (how to support BigIntegerField (asplain) vs Char (asdot+))

@rifen
Copy link

rifen commented Jun 6, 2023

Ran into this this week! 👍🏻 Would be a great addition.

@mzbroch
Copy link
Contributor Author

mzbroch commented Aug 10, 2023

@mattmiller87 @glennmatthews

We could solve this by adding two new fields on the ASN model: as_dot and as_dot_plus that would be computed and checked in the model's clean() method. This should provide sufficient type consistency for UI / API displaying and filtering.

@glennmatthews
Copy link
Contributor

Do these even need to be database fields or can they just be computed @property items?

@mzbroch
Copy link
Contributor Author

mzbroch commented Aug 11, 2023

Do these even need to be database fields or can they just be computed @property items?

This could work too, I was concerned with filtering of computed data but this might not be an issue

@cmacnevin
Copy link

Re @mzbroch 's comment above, here's something to consider:

This isn't a request in the original ask, but it would be awesome if we could actually plan ASNs with their own view, the same way we do with prefixes. Enabling asdot notation would mean this can be hierarchical - or at least a simple two-level hierarchy - which would actually be very useful when planning data center routing space.

So what Im suggesting here is that if it's a computed field, does that make it easier or harder to do something like this?

@mzbroch
Copy link
Contributor Author

mzbroch commented May 17, 2024

This isn't a request in the original ask, but it would be awesome if we could actually plan ASNs with their own view, the same way we do with prefixes. Enabling asdot notation would mean this can be hierarchical - or at least a simple two-level hierarchy - which would actually be very useful when planning data center routing space.

As in the #205 , ASN ASDOT will be shown in the list view of ASNs , allowing for sorting as well. Although not hierarchical, this should be very similar user experience to the described above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants