You are here: Home > Participate > Join a Discussion > RIPE Forum
RIPE Forum v1.4.1

Database Working Group

Threaded
Collapse

[db-wg] 2018-06 Proposal Implemented (RIPE NCC IRR Database Non-Authoritative Route Object Clean-up)

User Image

Ed Shryane

2020-01-06 15:26:30 CET

RIPE NCC staff member

Dear Working Group,

The RIPE NCC Database team have now implemented the 2018-06 proposal (now ripe-731), "RIPE NCC IRR Database Non-Authoritative Route Object Clean-up".

We plan to deploy this to production on Wednesday 15th January. 

A nightly job will run from that evening onwards. We expect approximately 965 route objects will be initially marked for cleanup (which will happen 2 weeks after that).

Regards
Ed Shryane
RIPE NCC



> 
> From: Petrit Hasani <phasani _at_ ripe _dot_ net>
> Subject: [policy-announce] 2018-06 Proposal Accepted (RIPE NCC IRR Database Non-Authoritative Route Object Clean-up)
> Date: 6 November 2019 at 16:03:18 GMT+1
> To: policy-announce _at_ ripe _dot_ net
> 
> Dear colleagues,
> 
> Consensus has been reached on 2018-06, "RIPE NCC IRR Database Non-Authoritative Route Object Clean-up".
> 
> This proposal aimed at creating a process to delete a non-authoritative object stored in the RIPE IRR, if it conflicts with an RPKI ROA.
> 
> You can find the full proposal at:
> https://www.ripe.net/participate/policies/proposals/2018-06
> 
> The new RIPE Document is called ripe-731 and is available at:
> https://www.ripe.net/publications/docs/ripe-731
> 
> We estimate that this proposal will take around two to three months to fully implement.
> 
> We will send another announcement once the implementation is complete and the new procedures are in place.
> 
> Thank you to everyone who provided us with your input.
> 
> Kind regards,
> 
> --
> Petrit Hasani
> Policy Officer
> RIPE NCC
> 
> 
> 
> 
> 

User Image

Ed Shryane

2020-01-16 15:14:50 CET

RIPE NCC staff member

Dear Working Group,

The Non-authoritative Route Object cleanup job ran for the first time last night. We identified 978 route(6) objects with conflicting ROA(s) which are now marked for cleanup, and emailed 269 addresses.

Regards
Ed Shryane
RIPE NCC


> On 6 Jan 2020, at 15:26, Edward Shryane via db-wg <db-wg _at_ ripe _dot_ net> wrote:
> 
> Dear Working Group,
> 
> The RIPE NCC Database team have now implemented the 2018-06 proposal (now ripe-731), "RIPE NCC IRR Database Non-Authoritative Route Object Clean-up".
> 
> We plan to deploy this to production on Wednesday 15th January. 
> 
> A nightly job will run from that evening onwards. We expect approximately 965 route objects will be initially marked for cleanup (which will happen 2 weeks after that).
> 
> Regards
> Ed Shryane
> RIPE NCC
> 
> 
> 
>> 
>> From: Petrit Hasani <phasani _at_ ripe _dot_ net phasani _at_ ripe _dot_ net>>
>> Subject: [policy-announce] 2018-06 Proposal Accepted (RIPE NCC IRR Database Non-Authoritative Route Object Clean-up)
>> Date: 6 November 2019 at 16:03:18 GMT+1
>> To: policy-announce _at_ ripe _dot_ net policy-announce _at_ ripe _dot_ net>
>> 
>> Dear colleagues,
>> 
>> Consensus has been reached on 2018-06, "RIPE NCC IRR Database Non-Authoritative Route Object Clean-up".
>> 
>> This proposal aimed at creating a process to delete a non-authoritative object stored in the RIPE IRR, if it conflicts with an RPKI ROA.
>> 
>> You can find the full proposal at:
>> https://www.ripe.net/participate/policies/proposals/2018-06 
>> 
>> The new RIPE Document is called ripe-731 and is available at:
>> https://www.ripe.net/publications/docs/ripe-731
>> 
>> We estimate that this proposal will take around two to three months to fully implement.
>> 
>> We will send another announcement once the implementation is complete and the new procedures are in place.
>> 
>> Thank you to everyone who provided us with your input.
>> 
>> Kind regards,
>> 
>> --
>> Petrit Hasani
>> Policy Officer
>> RIPE NCC
>> 
>> 
>> 
>> 
>> 
> 

Ronald F. Guilmette

2020-01-16 15:18:02 CET

In message <7747EE59-A4AD-4191-93B7-0A3B0A1C6AAC _at_ ripe _dot_ net>, 
Edward Shryane via db-wg <db-wg _at_ ripe _dot_ net> wrote:

>The Non-authoritative Route Object cleanup job ran for the first time
>last night. We identified 978 route(6) objects with conflicting ROA(s)
>which are now marked for cleanup, and emailed 269 addresses.

Praise be unto you.

Cleanliness is next to Godliness.


Regards,
rfg

Aleksi Suhonen

2020-01-31 08:04:58 CET

Hello,

On 06/01/2020 16:26, Edward Shryane via db-wg wrote:
> The RIPE NCC Database team have now implemented the 2018-06 proposal 
> (now ripe-731), "RIPE NCC IRR Database Non-Authoritative Route Object 
> Clean-up".

While I think this is a very commendable effort, I'm worried about 
resources that have been assigned directly by IANA through IETF action. 
They aren't covered by any RIR db and cannot be signed by RPKI.

I'm primarily worried about the anycast addresses that we (AS29432) 
announce: AS112 prefixes, 6to4 prefixes and Teredo prefixes. We're 
already having trouble getting those into automatic filters, and I'm 
worried that some day the route(6) objects might disappear completely.

I found the above prefixes listed at iana.org:
https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml
https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml

I strongly suspect that there may also be a few root or TLD name server 
prefixes that fall into this category, even tho they aren't listed in 
the above links.

As far as I've understood, IANA is not going to operate a RIR db or 
start maintaining their own RPKI signer. So we have to find some other 
solution. Ultimately this may need to be solved by an RFC, but I thought 
I'd start here by soliciting some ideas and opinions on what the correct 
approach should be.

Please Comment,

-- 
	+358 44 9756548 / http://www.trex.fi/
	Aleksi Suhonen / TREX Regional Exchanges Oy

	You say "potato", I say "closest-exit."

Job Snijders

2020-01-31 08:34:06 CET

On Fri, Jan 31, 2020 at 09:04:58AM +0200, Aleksi Suhonen via db-wg wrote:
> On 06/01/2020 16:26, Edward Shryane via db-wg wrote:
> > The RIPE NCC Database team have now implemented the 2018-06 proposal
> > (now ripe-731), "RIPE NCC IRR Database Non-Authoritative Route
> > Object Clean-up".
> 
> While I think this is a very commendable effort, I'm worried about
> resources that have been assigned directly by IANA through IETF
> action. They aren't covered by any RIR db and cannot be signed by
> RPKI.

If they can not be signed by RPKI, these objects will not be impacted by
clean up effort described in RIPE-731. So, I'd posit there is no reason
to worry.

> I'm primarily worried about the anycast addresses that we (AS29432)
> announce: AS112 prefixes, 6to4 prefixes and Teredo prefixes. We're
> already having trouble getting those into automatic filters, and I'm
> worried that some day the route(6) objects might disappear completely.

There is no proposal for further deletion as far as I know. Should at
some point the Internet numbers community figure out a way how to do
RPKI for such prefixes, again we wouldn't need to worry since the RPKI
ROA registrations will act as a superior successor to the IRR
registrations (and they wouldn't be in conflict).

> I found the above prefixes listed at iana.org:
> https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml
> https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml
> 
> I strongly suspect that there may also be a few root or TLD name
> server prefixes that fall into this category, even tho they aren't
> listed in the above links.
> 
> As far as I've understood, IANA is not going to operate a RIR db or
> start maintaining their own RPKI signer. So we have to find some other
> solution. Ultimately this may need to be solved by an RFC, but I
> thought I'd start here by soliciting some ideas and opinions on what
> the correct approach should be.

Until a problem has been defined, and a solution specified, I'm happy to
accomodate this type of special registration in the NTTCOM database.

Kind regards,

Job