Hello, I try to be a bit more expressive in the aut-num of ASN199284, but fail to get accepted at least the valid parts by the RPSL parser. Of course, there are invalid expressions in my terms for the sake of expressiveness, i.e. - next-hop is only valid for static routes - communities must not contain the PeerAS pattern But the other parts should be accepted, i.e. - protocol OSPF - rtr-sets in router expression part It would be a cool idea to keep the formatting, or better have smart pretty printing of the RSPLng structures. Currently only the "syncupdate" Interface is able to keep the line warps, which is pretty annoying. Where can I found the currently running code and do you accept patches in this regard? Many thanks in advance Lutz Donnerhacke
Lutz Donnerhacke via db-wg wrote on 02/07/2020 15:47:
I try to be a bit more expressive in the aut-num of ASN199284, but fail to get accepted at least the valid parts by the RPSL parser. rpsl(ng) hasn't seen any significant development work since the 1990s, and the only real update since then was to support ipv6 (rfc4012 in 2005). The only functional parser out there, irrtoolset, is crippled with functional shortcomings and is basically abandonware.
You may want to think twice about whether it's worth investing time and effort in rpsl in 2020. Nick
You may want to think twice about whether it's worth investing time and effort in rpsl in 2020.
That's true, but I do need some style of machine readable documentation internally as well as an slightly competent looking aut-num object for peering purposes. So the only choices are: a) invent something new for internal usage and update the RADB in addition. b) use the existing ideas and tools. I do not have any problem in patching or rewriting software, if necessary. For solution a) I have to do everything by myself anyway, so where is the difference to b), even if I'm the only user? If the projects are abandoned, who is to contact to shift the responsibility?
Hi Lutz (and sorry for the late reply), Maybe you can have a look on “PolicyParser” located here: https://github.com/stkonst/PolicyParser <https://github.com/stkonst/PolicyParser> It hasn’t received any commit the last 4 year, however It was working well until the moment I left the NLnet Labs. And is python based, so it will be easy for reading and patching/expanding. Hope the above helps. Best regards, Stavros Konstantaras | Sr. Network Engineer | AMS-IX M +31 (0) 620 89 51 04 | T +31 20 305 8999 ams-ix.net
On 2 Jul 2020, at 17:21, Lutz Donnerhacke via db-wg <db-wg@ripe.net> wrote:
You may want to think twice about whether it's worth investing time and effort in rpsl in 2020.
That's true, but I do need some style of machine readable documentation internally as well as an slightly competent looking aut-num object for peering purposes.
So the only choices are: a) invent something new for internal usage and update the RADB in addition. b) use the existing ideas and tools.
I do not have any problem in patching or rewriting software, if necessary. For solution a) I have to do everything by myself anyway, so where is the difference to b), even if I'm the only user?
If the projects are abandoned, who is to contact to shift the responsibility?
Hi Lutz Is your problem with the RPSL syntax in an AUT-NUM you try to create in the RIPE Database, or with some RPSL parser you are using on data you have extracted from the RIPE Database? Nick, "You may want to think twice about whether it's worth investing time and effort in rpsl in 2020". Given that the discussion you tried to get going recently on the future of RPSL hardly got off the ground, then unless someone already has advanced plans on a replacement for RPSL I don't see it going away anytime soon. cheersdenis co-chair DB-WG On Thursday, 2 July 2020, 17:12:29 CEST, Nick Hilliard via db-wg <db-wg@ripe.net> wrote: Lutz Donnerhacke via db-wg wrote on 02/07/2020 15:47:
I try to be a bit more expressive in the aut-num of ASN199284, but fail to get accepted at least the valid parts by the RPSL parser. rpsl(ng) hasn't seen any significant development work since the 1990s, and the only real update since then was to support ipv6 (rfc4012 in 2005). The only functional parser out there, irrtoolset, is crippled with functional shortcomings and is basically abandonware.
You may want to think twice about whether it's worth investing time and effort in rpsl in 2020. Nick
On 02/07/2020 16:47, ripedenis--- via db-wg wrote:
Given that the discussion you tried to get going recently on the future of RPSL hardly got off the ground, then unless someone already has advanced plans on a replacement for RPSL I don't see it going away anytime soon.
As it is possibly my fault for setting Nick off on the most recent of discussions with regards to RPSL, it might be worth re-iterating now what I asked on IRC: who is still using the RPSL in aut-nums for important work? As per my understanding from the ensuing conversation, RPSL in an aut-num is used:- i) to build as-path/prefix-list filters for your peers/customers ii) as internal interconnection documentation, in lieu of other OSS As far as I know, (ii) isn't too common (I can think of a few very admirable examples) but mostly this is internal documentation that doesn't need to be publicised. In the case of (i), who in their right mind expects that data to be accurate? There's no validation happening. AS35425 had ridiculously outdated RPSL for years, and this only ever incurred emails from RIPE about reclaimed ASNs that it referenced. Parsing as-sets to find route objects, and hopefully filtering that list through some RPKI Invalid filtering, appears to me to be the correct way to do (i) as of today, and that has been the case for some time. So... The question in so much as "what do we replace RPSL with?" doesn't seem to be as pertinent, "Why are we all still collectively waving our [outdated] routing policies about in public?" Bragging rights? Eye candy? As far as I can tell, no-one is actually paying attention...! [ N.B. I realise that RPSL is optional in aut-nums, but the RIPE NCC also populate new ASNs with import/export lines, which infers that it *is* a requirement to the uninitiated. It also helps it look entirely superfluous when you forget to update it for 3 years & nothing breaks. ] Regards, -- Tom
Tom Hill via db-wg wrote on 02/07/2020 18:32:
In the case of (i), who in their right mind expects that data to be accurate?
the last time I looked at this (preso in ripe59, routing-wg) there was no discernible relationship between rpsl and what was appearing in the dfz, i.e. r looked like it was nearly 0. When there is such a serious disconnect between two data sets, it's time to question whether it's worth maintaining the data sets. Nick
* Nick wrote:
disconnect between two data sets, it's time to question whether it's worth maintaining the data sets.
I'd suggest to remove the crippled parser from the records in the first step. Even if someone tries to use the data-set, it's not even possible to bring in correct data. How do you expect an adoption under this condition? So, my primary question: Where is the source code and how to contribute? Secondary question: Can we first declare the fields as free from text fields, before removing them? Lutz
Hi Nick et al, The ripe whois database (https://github.com/RIPE-NCC/whois) has an excellent (=clean, performant and heavily tested) RPSL parser in it for java. It's minimal work to copy the package, or, since this is BSD licence, you could release a copy of it for others to use too. Cheers, Agoston On Thu, Jul 2, 2020 at 5:12 PM Nick Hilliard via db-wg <db-wg@ripe.net> wrote:
Lutz Donnerhacke via db-wg wrote on 02/07/2020 15:47:
I try to be a bit more expressive in the aut-num of ASN199284, but fail to get accepted at least the valid parts by the RPSL parser. rpsl(ng) hasn't seen any significant development work since the 1990s, and the only real update since then was to support ipv6 (rfc4012 in 2005). The only functional parser out there, irrtoolset, is crippled with functional shortcomings and is basically abandonware.
You may want to think twice about whether it's worth investing time and effort in rpsl in 2020.
Nick
Horváth Ágoston János wrote on 16/08/2020 19:57:> The ripe whois database (https://github.com/RIPE-NCC/whois) has an
excellent (=clean, performant and heavily tested) RPSL parser in it for java. It's minimal work to copy the package, or, since this is BSD licence, you could release a copy of it for others to use too.
yip but do I understand it correctly that this is a syntactic parser only? I.e. there is no semantic expression evaluator. If this is the case, you'd need a lot of glue to be able to convert rpsl expressions into structures suitable for injection into templating engines. This is the hard bit in irrtoolset that wrecked everyones' heads. Nick
Correct! I just drawing attention that while implementing the whois server, we've also checked some rpsl parsers, and most of them failed the sanity checks, even for parsing. As for interpreting the mp-export/import lines, those have a grammar that is also included in the rpsl parser in whois server, although only used for evaluating syntactic correctness. I think they also could form the basis of a more complex software. By the way, at this point a generic solution becomes impossible as everyone wants to use the resulting expression tree differently, so it's always a custom work from the grammar upwards. Cheers, Agoston On Mon, Aug 17, 2020 at 12:58 AM Nick Hilliard <nick@foobar.org> wrote:
Horváth Ágoston János wrote on 16/08/2020 19:57:> The ripe whois database (https://github.com/RIPE-NCC/whois) has an
excellent (=clean, performant and heavily tested) RPSL parser in it for java. It's minimal work to copy the package, or, since this is BSD licence, you could release a copy of it for others to use too.
yip but do I understand it correctly that this is a syntactic parser only? I.e. there is no semantic expression evaluator. If this is the case, you'd need a lot of glue to be able to convert rpsl expressions into structures suitable for injection into templating engines. This is the hard bit in irrtoolset that wrecked everyones' heads.
Nick
participants (6)
-
Horváth Ágoston János -
Lutz Donnerhacke -
Nick Hilliard -
ripedenis＠yahoo.co.uk -
Stavros Konstantaras -
Tom Hill