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)?". cheersdenis co-chair DB-WG
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
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? cheersdenis co-chair DB-WG On Thursday, 14 May 2020, 14:45:11 CEST, Gert Doering <gert@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
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@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@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
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? cheersdenis co-chair DB-WG On Thursday, 14 May 2020, 16:16:13 CEST, George Michaelson <ggm@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@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@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
I think there is useful work to be done in the IRR community itself, taking the input from the RIPE working group into consideration. I think passing this to the IETF at this stage would be a mistake, when in all likelihood the people who need to engage are IRR operators, which is the NCC, Merit, JPNIC, ourselves, Job and his NTT, and perhaps the 100+ people who took the NRTM feed. If it turns out that these people can usefully identify paths out e.g. syntactic constructs suitable for use in RDAP, or the subset of RPSL which is useful as a policy adjunct alongside RPKI, or even just the addition of an optional MaxLength to the route/route6 object (and the clear guidance on how to interpret them) I think that would be beneficial. -George On Fri, May 15, 2020 at 12:29 AM ripedenis@yahoo.co.uk <ripedenis@yahoo.co.uk> wrote:
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@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@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@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
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@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@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@ripe.net <mailto:routing-wg@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@space.net <mailto:gert@space.net>> wrote:
Hi,
On Thu, May 14, 2020 at 09:52:06AM +0000, ripedenis--- via
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
routing-wg wrote: 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@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@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@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@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@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
Dear all, Speaking as RIPE Routing Working Group Co-Chair (*without having consulted with the other co-chairs*) I think the routing working group in RIPE is a good platform to explore the topic at hand. I believe both Denis and Nick to be valuable contributors in the process ahead of us. I care a lot about getting the right people in the 'room', and ensuring all people involved have comitted time to work on the issue. I recognize that platforms also exist to discuss RPSL/IRR related issues (such as nanog@nanog.org, the irrd project at http://irrd.net/, *NOG lists, or grow@ietf.org) At whatever "RIPE 80" was, in the Routing Working Group session , Nick Hilliard asked for feedback from this WG. As a result, we as Routing WG we should follow-up, and I am willing to put in time. As I am one of your co-chairs, please email this list (or mail the chairs directly) if you have plans you want to share. *speaking as participant of the global Internet routing system*: I don't mind whereever we do this, but I would like all of it to be: A) publicly archived B) follow some process that all involved ahead of time understand C) COUNT ME IN Kind regards, Job On Thu, May 14, 2020 at 02:29:50PM +0000, ripedenis--- via routing-wg wrote:
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? cheersdenis co-chair DB-WG On Thursday, 14 May 2020, 16:16:13 CEST, George Michaelson <ggm@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@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@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
Hi, On Thu, May 14, 2020 at 02:00:09PM +0000, ripedenis@yahoo.co.uk wrote:
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?
Not sure this is something for the DB WG to press, indeed. I saw this mail in the routing-wg, which I find a more logical place to argue about "where do we want to go with RPSL?" - or maybe even push it to IETF. But I have no hopes for IETF, so maybe not. 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
participants (5)
-
George Michaelson -
Gert Doering -
Job Snijders -
Nick Hilliard -
ripedenis＠yahoo.co.uk