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 <[email protected]> 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/ ----- 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/
