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/routing-wg@ripe.net/
[routing-wg] RPKI Validator 2.19; export ROAs as RPSL route: objects
- Previous message (by thread): [routing-wg] RPKI Validator 2.19; export ROAs as RPSL route: objects
- Next message (by thread): [routing-wg] New on RIPE Labs: BGPdump2: A Tool to Read and Compare the BGP RIB Dump Files
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Tim Bruijnzeels
tim at ripe.net
Wed May 13 12:08:34 CEST 2015
> On 13 May 2015, at 11:42, Job Snijders <job at instituut.net> wrote: > > On Tue, May 12, 2015 at 03:58:31PM +0200, Alex Band wrote: >> We've been getting a lot of requests to make processed RPKI data >> easily available in existing (RPSL based) workflows. This is why we >> added the ability to export all ROAs as route: objects in the latest >> release, version 2.19. Practically, this means that running an RPSL >> export will give you almost 450,000 highly reliable, cryptographically >> validated route: objects. >> >> This functionality should be considered beta for now, because we would >> like to get your feedback on the notation and the way we de-aggregate >> ROAs into route: objects based on the specified maximum prefix length. > > Interesting! I was considering writing a script to do this, but the NCC > beat me to it! :-) > >> The format looks like this: >> >> route: 193.0.12.0/23 >> origin: AS3333 >> descr: exported from ripe ncc validator >> mnt-by: NA >> created: 2015-05-07T10:01:56Z >> last-modified: 2015-05-07T10:01:56Z >> source: ROA-RIPE-NCC-RPKI-ROOT > > Wouldn't it make sense to align the "created:" date with something more > specific to the ROA rather then the export date? sure > Another consideration might be to create a "expiry-date:" derived from > the ROA's expiry date for easy debugging purposes. Adding a new > attribute should not have adverse effects on the generation of > prefix-filters in the toolchains I am familiar with. It would require a bit more work but along that thought we could sure do something like this: created & last-modified: signing time of the ROA embedded certificate (it cannot be modified without re-signing) expiry-date: expiry date of the ROA embedded certificate last-validated: date and time of validation We haven't done anything like this yet, because we wanted to be sure that there is operational value for having this first. So please let us know! Kind regards, Tim > > Kind regards, > > Job >
- Previous message (by thread): [routing-wg] RPKI Validator 2.19; export ROAs as RPSL route: objects
- Next message (by thread): [routing-wg] New on RIPE Labs: BGPdump2: A Tool to Read and Compare the BGP RIB Dump Files
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]