Hello Tobias, Tore et. al, I'm glad to see some pain points such as 2.6 being updated. This has caused quite a bit of back-and-forth between me and the NCC when sponsoring PI assignments for End Users. Also a big fan of following nibble boundaries, will make domain object management and growth a lot easier. As Tobias mentioned, it would be nice if there was some kind of way to document in the RIPE DB more-specific use-cases of your PI (with the mentioned restriction making sense to me, to prevent sub-assignment), but I think this is currently out-of-scope for this proposal. Unfortunately, I do not have much more input, as most concerns and/or questions I would have had, have already been asked by others and answered by Tobias. :) @Tore: I currently hold 4x/48 PI, and I can confirm, these are charged "per ticket" and not per object. E.g: If you received 4x/48 PI in a single request from the NCC, you pay the PI fee *once* for those 4x/48PI. Lastly, I would like to mention I support the proposal and would like to see how things develop. Warm regards, Jori Vanneste On Thu, 29 Aug 2024 10:48:00 +0200 Tobias Fiebig via address-policy-wg <address-policy-wg@ripe.net> wrote:
Hello Tore,
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).
Still, it does allow for more consistent hierarchical addressing plans, easier ACL setups (as mentioned by Sander), easier (controlled) growth of networks (keep in mind that, at the moment, at least the /46 of a /48 PI is left unassigned), reduces overhead in terms of small growth, etc.
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.
First, the maximum size for PI is limited to a /36 (always smaller than the smallest allocation, at the nibble boundary).
Also, iirc, at the moment charging is based on _complete assignments_. I.e., as I understand it, that _one_ assignment process for 8192 /48 for 8192 sites in _one_ process for _one_ customer would count as _one_ assignment, and hence only cost EUR75 _once_ per year. IIRC, I even saw somebody discussing the option of batching processes to be able to offer PI sponsoring cheaper/make more profit.
However, besides that, the charging scheme is outside of scope for the assignment policy. It would be relatively easy to adjust charges for PI based on size, e.g. (numbers grabbed completely out of thin air and _ONLY_ as an example!):
/48 .0625 * Annual LIR fee (for 2025 EUR 112.50) /44 .125 * Annual LIR fee (for 2025 EUR 225.00) /40 .25 * Annual LIR fee (for 2025 EUR 450.00) /36 .5 * Annual LIR fee (for 2025 EUR 900.00)
That, again, would be a matter for the charging scheme task-force to consider.
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). With caveats:
- There are no more specific objects, and if there might be in the future, i'd assume that they would be bound to have the same ORG-ID as the main assignment holder, being purely for documentary purposes. - The fee structure might change, see above, which is a task for another WG/the membership in general. - You will likely only get a /48 per end-site, up to a maximum of a /36 if you have more than 256 sites.
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.
See above; I would argue that this specific part (connection to charging) is out of scope for the AP WG / a proposal here; But I _do_ think that there are some good ways to solve this.
I will, hence, pick this point up for the arguments part of the next version.
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».
This is the result of policy interpretation by the NCC when applying the policy. I would be happy to change the term to 'any form of internal connectivity between two sites', pending that in the impact assessment the result would be the same, i.e., no longer merging two end-sites as soon as you have a VLAN tagged between them (or, even worse, directly a DF).
With best regards, Tobias ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/