Designing ISP addressing schemes that scale

not sure if this is really the right place to ask this question, just after a bit of advice from someone who may have had more experience than me as there seems to be fairly slim reading about 'best practices' on the web.

I am trying to (re)design a poorly planned management addressing scheme for a rather large (and quickly growing) ISP network (OSPF and iBGP internally). multiple PoP sites across multiple regions. currently I am playing with the 10/8 RFC range, as I am using the rest of the RFC range for various other things (point to point addressing, etc). I have segregated our management network into several VRFs for particular use cases e.g. core infrastructure, customer CPE, etc, which allows me to control access between these route tables as needed.

my current proposed design allocates a /16 per geographical region, the second octet being an arbitrarily assigned area code which can contain multiple PoP sites in a given region. this is further split into /18s for the 4 individual management vrfs and further to identify the devices hanging off a particular router. for privacy's sake the VRF names are skewed, but there are valid reasons to segregate.

example:

Region: 22

Summary route: 10.22.0.0/16

​

Per-VRF Subnets:

Core Infrastructure: 10.22.0.0/18

Customer CPE: 10.22.64.0.0/18

VRF 3: 10.22.128.0/18

VRF 4: 10.22.192.0/18

​

how this looks in practice, using 2 routers and the first 2 VRFs as an example. to be clear, each site will have all 4 VRFs configured so the subnetting format won't differ between regions:

RFC Range	Region Code			Mask	Purpose
10	22	0	0	/22	Core Infra - R1
10	22	4	0	/22	Core Infra - R2
10	22	64	0	/22	CustCPE - R1
10	22	68	0	/22	CustCPE - R2

​

am I overthinking this? the only suggestion I have been given is to simply use a flat management topology, basically using a portion of 10/8 for each VRF, then using BGP communities to do the needful. I find that it is helpful to look at an IP address and be able to at least somewhat identify where the device lives in the network but that may be personal preference and not best practice.

TIA.