Hi Sander,
The proposed text in 2.9 makes it clear that separate locations with different routing policies should be considered separate End Sites. Next, the proposed text in 7.1 makes it clear that having multiple End Sites qualifies for an assignment larger than /48.
However, it states that this is done «to avoid fragmentation». But doesn't the fact that those separate End Sites are defined to have different routing policies make the fragmentation happen anyway? In the global routing table: yes In ACLs and IPAM etc: no
It all depends what you are working on :)
Yeah, ok, I can see that. Well, in an IPAM you'd normally want to track which prefix belongs at which site, so you'll need separate entries for each prefix anyway. You'd also get a few more inet6num objects in the database (but the same number of route6 objects), but disk is cheap. All in all it seems like the actual benefit of this part proposal is not too big and the benefits do not extend to the community at large (like limiting DFZ growth would). Another thing occurred to me though. With the current fee structure, an organisation with several sites would contribute €50 *per site* to to the RIPE NCC's budget. With this proposal, as I understand it, a huge organisation with 30000 sites could get a PI /33, advertise 30000 /48s into the DFZ, and all it'd cost them is just €50 per year. Good for the PI holder of course, but not so good for the community. It would certainly make economic sense for us as a public cloud provider to terminate our LIR membership and go for this new PI, since it explicitly allows hosting customer VMs and such (if it weren't for the fact that we were also dependent on IPv4). I wonder if this has been considered, as it is not being discussed in the proposal. I think I will wait for the impact analysis before I decide where I stand on this part of the proposal.
Another thing I find strange is the reference to layer-2 connectivity in 2.9 and 7.1.1. This seems oddly technology-specific to me. Is it the intention that two End Sites (with different routing policies) interconnected with an L2VPN should be treated differently than two End Sites (with different routing policies) interconnected with an L3VPN? Looks that way, but why? IIRC this is about the history of treating multiple sites that are connected on layer-2 as a single end-site. As that has caused confusion in the past, the new text explicitly states that a layer-2 connection does not automatically mean “single end-site”.
I wasn't aware of that history. Current policy does not mention «layer 2» at all, so I wonder where that came from. Are layer 2 connectivity (like L2VPNs) and layer 3 connectivity (like L3VPNs) treated differently today? Do we want that tomorrow, if so why? If it shouldn't matter, I'd prefer some kind of technology-agnostic term to be used here, like simply «connectivity». Tore