Feature request : IP address in a VRF appears in prefix

[VictorJ76]

I my use case, I use a Prefix to store the IPs of my clients. In this prefix there are multiples IP in multiples VRF so I can't attribute the prefix a VRF and when I add an IP, she doesn't appear in the prefix.
My request is to see in the prefix the different IP in different VRF.

[jeremystretch]

That would entirely defeat the purpose of modeling a VRF. A prefix either belongs to the global table or to a VRF. If you have multiple overlapping prefixes assigned to different VRFs, each one needs to be modeled in its parent VRF separately.

[martink2]

Yes, in general I fully agree with the prefix only showing siblings in his own VRF
because thats what VRF's are meant to do.

But I would like to point out one exception where it might make sense to divert.
That would be the prefix type Container. We have a lot of /24 prefixes set aside
as containers to allocate Router ID's and corresponding /32 loopback IP's from
or others we set aside for allocating /31 for transit networks on our routers.

So we used to have a nice workflow where someone needed a transit network he would
go into the container and create a /31 from the list of available sub-prefixes and of cause
assign it to the respective VRF it is needed in. For the special case of Containers it always
worked exceptionally well for us, unfortunately the latest release introduced a functional
change so now we can see all our containers do no longer have any child prefixes thus it is
very cumbersome to figure out what has been allocated from the container and find the "next available".

If you think vrf global + type container is not the right combination to model a vrf spanning pool
for sub-prefix management I would kindly ask to provide another way to achieve this.

I can see that "vrf global" + "type container" would be a convention here to signify cross VRF relevancy of a prefix. The only other thing i could think of would be the ability to flag a Prefix
(and by inheritance/convention all sub-prefixes) as globally unique across all VRF's.

Implementation of the later would of cause be more work than just treating a certain combination
differently but it would also solve a different problem. We are currently using a lot of BGP-L3VPN
connections in our network with route-leaking across VRF's. A lot of central services are leaked
into VRF's which means we need to manage a range of prefixes which should be globally unique
as to not interfere with client VRF routes during leaking. Being able to mark a prefix as global
would make it possible to subsequently give an error message if someone tries to create the same
prefix or sub-prefix from within the unique range in another VRF.

[jeremystretch]

@martink2 Please open a new issue for your request as it is not strictly related to this one.

Edit: I believe this is the change you're referring to.