ripedenis--- via routing-wg <mailto:[email protected]>
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
<[email protected]> 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
<[email protected] <mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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:[email protected]>
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:[email protected]>
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 <[email protected]>
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:[email protected]>
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:[email protected]>
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
