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] 2023-04 Proposal Accepted (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Tore Anderson
tore at fud.no
Tue Apr 16 12:55:12 CEST 2024
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
- 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] 2023-04 Proposal Accepted (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]