[routing-wg] RPSL

The position of the DBTF is it's asking the routing working group for 
its opinion on the future of RPSL in the RIPE database.

It is clear that there are data quality issues in some areas, but also 
that there is a good deal of data in the IRRDB which is operationally 
valuable.

It would also be great to hear from other RIR IRRs about their position 
on this, but this is possibly a separate issue. Similarly for any 
engagement with the IETF.

Nick

> ripedenis--- via routing-wg <mailto:routing-wg at ripe.net>
> 14 May 2020 at 15:29
> This is exactly the point I am making George. I am not saying the RIPE 
> Database is special. Exactly the opposite. So if there is a problem 
> with using RPSL in the RIPE Database I assume it is likely all IRRs 
> have the same problem. So should the IETF look at this issue or is it 
> reasonable to change the way routing data is processed or handled only 
> in the RIPE IRR?
>
> cheers
> denis
>
> co-chair DB-WG
>
> On Thursday, 14 May 2020, 16:16:13 CEST, George Michaelson 
> <ggm at algebras.org> wrote:
>
>
> The RIPE DB's RPSL is not special in any regard Denis. Its one BGP
> configuration space after all.
>
> If the observations about the RIPE IRR are true, then is it not
> equally likely they hold at other IRR too?
>
> So I think a reasonable approach here might be to take observations
> about object types, complexity, usage, and ask other IRR if they also
> see these behaviours?
>
> -George
>
>
> On Fri, May 15, 2020 at 12:00 AM ripedenis--- via routing-wg
> <routing-wg at ripe.net <mailto:routing-wg at ripe.net>> wrote:
> >
> > Hi Gert
> >
> > You are right, this has been an issue for many years. It is not only 
> the problem of parsing RPSL but also an issue with people 
> understanding it as a language and applying it correctly. But should 
> this be an issue taken up by the IETF? Or do you think the RIPE 
> Database could/should do something different to all other IRRs?
> >
> > cheers
> > denis
> >
> > co-chair DB-WG
> >
> >
> > On Thursday, 14 May 2020, 14:45:11 CEST, Gert Doering 
> <gert at space.net <mailto:gert at space.net>> wrote:
> >
> >
> > Hi,
> >
> > On Thu, May 14, 2020 at 09:52:06AM +0000, ripedenis--- via 
> routing-wg wrote:
> > > Just a comment on the RPSL issue from the RIPE 80 session today. 
> RPSL has little to do with the accuracy of data in the RIPE IRR. RPSL 
> is just a language. Assuming you understand the language, it is your 
> choice whether or not you maintain your data and keep it accurate and 
> up to date.
> >
> >
> > Right.
> >
> > That said, the data quality regarding import: and output: lines in the
> > RIPE DB is so poor that "bad and useless" is not halfway sufficient
> > to describe its badness.
> >
> > I think import/export is beyond repair - it is too complex to correctly
> > parse, and at the same time not expressive enough to describe policy
> > precisely enough ("export to AS X as peer, no further upstreaming 
> permitted"
> > vs. "export to AS Y as upstream, further distribution expected").
> >
> > Gert Doering
> >        -- NetMaster
> > --
> > have you enabled IPv6 on something today...?
> >
> > SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer
> > Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. 
> Grundner-Culemann
> > D-80807 Muenchen HRB: 136055 (AG Muenchen)
> > Tel: +49 (0)89/32356-444       USt-IdNr.: DE813185279
> George Michaelson <mailto:ggm at algebras.org>
> 14 May 2020 at 15:15
> The RIPE DB's RPSL is not special in any regard Denis. Its one BGP
> configuration space after all.
>
> If the observations about the RIPE IRR are true, then is it not
> equally likely they hold at other IRR too?
>
> So I think a reasonable approach here might be to take observations
> about object types, complexity, usage, and ask other IRR if they also
> see these behaviours?
>
> -George
>
>
> On Fri, May 15, 2020 at 12:00 AM ripedenis--- via routing-wg
>
>
> ripedenis--- via routing-wg <mailto:routing-wg at ripe.net>
> 14 May 2020 at 15:00
> Hi Gert
>
> You are right, this has been an issue for many years. It is not only 
> the problem of parsing RPSL but also an issue with people 
> understanding it as a language and applying it correctly. But should 
> this be an issue taken up by the IETF? Or do you think the RIPE 
> Database could/should do something different to all other IRRs?
>
> cheers
> denis
>
> co-chair DB-WG
>
>
> On Thursday, 14 May 2020, 14:45:11 CEST, Gert Doering <gert at space.net> 
> wrote:
>
>
> Hi,
>
> On Thu, May 14, 2020 at 09:52:06AM +0000, ripedenis--- via routing-wg 
> wrote:
> > Just a comment on the RPSL issue from the RIPE 80 session today. 
> RPSL has little to do with the accuracy of data in the RIPE IRR. RPSL 
> is just a language. Assuming you understand the language, it is your 
> choice whether or not you maintain your data and keep it accurate and 
> up to date.
>
>
> Right.
>
> That said, the data quality regarding import: and output: lines in the
> RIPE DB is so poor that "bad and useless" is not halfway sufficient
> to describe its badness.
>
> I think import/export is beyond repair - it is too complex to correctly
> parse, and at the same time not expressive enough to describe policy
> precisely enough ("export to AS X as peer, no further upstreaming 
> permitted"
> vs. "export to AS Y as upstream, further distribution expected").
>
> Gert Doering
>         -- NetMaster
> -- 
> have you enabled IPv6 on something today...?
>
> SpaceNet AG   Vorstand: Sebastian v. Bomhard, Michael Emmer
> Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen                HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444        USt-IdNr.: DE813185279
> Gert Doering <mailto:gert at space.net>
> 14 May 2020 at 13:45
> Hi,
>
> Right.
>
> That said, the data quality regarding import: and output: lines in the
> RIPE DB is so poor that "bad and useless" is not halfway sufficient
> to describe its badness.
>
> I think import/export is beyond repair - it is too complex to correctly
> parse, and at the same time not expressive enough to describe policy
> precisely enough ("export to AS X as peer, no further upstreaming 
> permitted"
> vs. "export to AS Y as upstream, further distribution expected").
>
> Gert Doering
> -- NetMaster
> ripedenis--- via routing-wg <mailto:routing-wg at ripe.net>
> 14 May 2020 at 10:52
> Colleagues
>
> Just a comment on the RPSL issue from the RIPE 80 session today. RPSL 
> has little to do with the accuracy of data in the RIPE IRR. RPSL is 
> just a language. Assuming you understand the language, it is your 
> choice whether or not you maintain your data and keep it accurate and 
> up to date.
>
> If we were to change from RPSL to something else the data would not 
> necessarily be of any better quality. But it would be 'non standard' 
> compared to all the other IRRs. Changing RPSL, as a means of inputting 
> and outputting routing data, is not something that can be considered 
> unilaterally within the RIPE Database.
>
> Perhaps a different question to ask could be, "is all the routing 
> information contained in the RIPE Database still meaningful, useful 
> and necessary (regardless of the language)?".
>
> cheers
> denis
>
> co-chair DB-WG

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/routing-wg/attachments/20200514/f01e18ec/attachment-0001.html>