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] RPSL
- Previous message (by thread): [routing-wg] RPSL
- Next message (by thread): [routing-wg] RPSL
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
George Michaelson
ggm at algebras.org
Thu May 14 16:35:02 CEST 2020
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 at yahoo.co.uk <ripedenis at 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 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> 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> 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
- Previous message (by thread): [routing-wg] RPSL
- Next message (by thread): [routing-wg] RPSL
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]