IDEA: ASDOT notation

[nautobot]

IDEA: ASDOT notation

[cmacnevin]

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]

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]

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

[mzbroch]

@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]

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

[mzbroch]

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]

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?