Intended ontology of IPAM: VRF model in Netbox? (Meant to represent the device-local instantiation of a VRF, or the extended/multi-device routing-domain of all nodes using the same route-targets values?)

[menckend]

I can't quite suss out what the authorial intent is with the VRF model in Netbox's IPAM application. On the one-hand, it includes a route-distinguisher field, which at least suggests that it's meant to represent the device-local VRF construct (since RD values need to be at least VRF-unique by device within an MP-BPG routing domain.) On the other hand; there's no foreign key relationship to the device table, making it un-tenable to "mean"/use-as that.

Alternatively, If it's meant to represent the extended/distributed routing-domain comprised by all the MP-BGP routers swapping routes with the same import-export values. In the MPLS or EVPN use-cases, I think this would essentially be a VPN-IPv4 address family (again, in the distributed/shared sense.) If that's the intent though, the presence of the RD field seems inappropriate.

Ideally, I'd like to be able to model both usages of the "VRF" concept, but I don't want to start ice-skating up-hill if one or the other is what was originally intended by the developers.

For my part, I've tried adding a "VRF-type" custom field, so that I can have entries for the shared/distributed VRF concept. (Which I can associate individual interface objects with). And I've also considered adding a custom-field that's a reference to the device model/object. In that scenario, I might end up with:

Devices

• Device-A
  • Interface-A
    • VRF-m
  • Interface-B
    • VRF-n
• Device-B
  • Interface-A
    • VRF-m
  • Interface-B
    • VRF-n

VRFs

• VRF-m (type=distr.; rt-tg-exp=100; rt-tg-imp=100)
• VRF-n (type=distr.; rt-tg-exp=200; rt-tg-imp=200)
• VRF-o (type=local; rt-tg-exp=100; rt-tg-imp=100; device = Device-A, RD=1.2.3.4:1)
• VRF-p (type=local; rt-tg-exp=200; rt-tg-imp=200; device = Device-A, RD=1.2.3.4:2)
• VRF-q (type=local; rt-tg-exp=100; rt-tg-imp=100; device = Device-B, RD=1.2.3.5:1)
• VRF-r (type=local; rt-tg-exp=200; rt-tg-imp=200; device = Device-B, RD=1.2.3.5:2)

That let's me capture more-or-less everything I want to, but seems pretty janky to me. I think that the local-context usage is the more "important" one, in terms of modeling actual device configuration intent, but I do see the appeal in being able to easily/directly pluck a list of interfaces across dozens of different devices that are all in "the same VRF". I wonder if maybe it would make sense to lean fully into the device-local context data model, and setting the "VRF" field of the interface object to the device-local VRF object. And if we wanted to get a list of all interfaces "in the same VRF" across multiple devices, we'd need a more complex query (an outer join?) the grabbed all interfaces that were bound to VRF objects with matching route-target import/export values?

Anyone have any insights as to what the design intent is/was here? (Or any novel implementation strategies they've considered?)