[address-policy-wg] 2023-04 Proposal Accepted (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
- Previous message (by thread): [address-policy-wg] 2023-04 Proposal Accepted (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
- Next message (by thread): [address-policy-wg] Co-chair selection (was: Fwd: [ripe-list] The RIPE Chair Team Reports - April 2024)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
APEX NCC ORG
registry at apex.dp.ua
Tue Apr 16 13:14:29 CEST 2024
Hello, Tore! Thank you for quick feedback. After the example you gave - I understood the purpose of the introduction for IPv4. > I do not quite understand this use case. I believe it is not common to > split an ASSIGNED PA object into more specific ASSIGNED PA objects. To > be honest, I didn't even know that was possible. Anyway… So sorry. My mistake. > ASSIGNED PA object (for example /20) I had in mind *ALLOCATED* *PA* */20*, which divided to much /*24*, which is*ASSIGNED PA *already.* *Thank you!* * On 4/16/24 13:55, Tore Anderson wrote: > Hi there, > > * APEX NCC ORG >> >> Can you provide an example of using and registering an >> AGGREGATED-BY-LIR object for IPV4? >> Who is this for and when? >> > It has exactly the same use case as AGGREGATED-BY-LIR for IPv6. It is > primarily intended for LIRs which need to make a large number of > essentially identical assignments, which can then be aggregated into a > single database object rather than registering a bunch of redundant > objects. > > Here's an example, which represent 256 essential identical ASSIGNED PA > objects: > > inetnum: 192.0.2.0 - 192.0.2.255 > netname: CLOUDPROVIDER-CUSTOMER-VMS > descr: IP addresses dynamically assigned to virtual machines running > in CloudProvider's public cloud infrastructure # this is optional > assignment-size: 32 # this is optional > country: NO > admin-c: CLOUDPROVIDER-RIPE > tech-c: CLOUDPROVIDER-RIPE > status: AGGREGATED-BY-LIR > mnt-by: CLOUDPROVIDER-MNT > source: RIPE > > >> Is its use mandatory? >> > Not at all, feel free to ignore it and continue doing whatever you've > been doing so far. > > >> Initially, the assignment policy was discussed as an assignment for >> cloud providers. >> What should a provider do, for example, if it has a status ASSIGNED >> PA object (for example /20), >> splits it into /24 objects also like ASSIGNED PA with additional >> routes obj. for its end clients (without NAT / with NAT)? >> > I do not quite understand this use case. I believe it is not common to > split an ASSIGNED PA object into more specific ASSIGNED PA objects. To > be honest, I didn't even know that was possible. Anyway… > > >> Is it here an AGGREGATED-BY-LIR status objects? Or NOT? >> > …as I understand it, in your example, the 16 /24 ASSIGNED PA objects > have unique mnt-routes: values. If so, that means you cannot aggregate > the 16 /24s into a single AGGREGATED-BY-LIR object. > > Tore -- Best wishes, APEX NCC ORG -------------------------------- +38(056)-731-99-11, +38(067)-731-99-11, +38(050)-731-99-11, www.trifle.net -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.ripe.net/ripe/mail/archives/address-policy-wg/attachments/20240416/4cd0c54c/attachment.html>
- Previous message (by thread): [address-policy-wg] 2023-04 Proposal Accepted (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
- Next message (by thread): [address-policy-wg] Co-chair selection (was: Fwd: [ripe-list] The RIPE Chair Team Reports - April 2024)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]