In the referenced message, Craig A. Huegen said:
==>Return the 172.16.0.0/16 block to the registry (ARIN, APNIC, RIPE or if
==>no one else IANA) and apply for multiple appropriately sized CIDR blocks
==>under the current registry allocation guidelines.While I fully agree with this approach to deal with the issues mentioned,
it will only exhaust the new address space more quickly. Why should we
give up on 128/2?/cah
When the blocks are returned to the registries, the registries may use them
for allocation at their current prefix boundaries (/19 generally) just as
they are doing with 24,61,62,63,64,65,66. I'ld say the vast majority
of those who filter do so based at minimum on the minimum registry allocation
guidelines.
cf BCP4
To add to Sean's solution, I believe it would not be outside the realm
of possibility that a RiR would not require an entity to return first, ask
second. Working with them on sizing an appropriate block, and setting up
a generous renumbering schedule would probably be entirely possible.
To add another potential solution, since both of the entities mentioned
are, in effect, part of the same organization, set up (a/multiple) GRE
tunnels for sending data between the two orgs. Then announce the larger
aggregate from the better connected of the two.