This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[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: </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 ]