On Mon, Nov 13, 2017 at 11:21:05AM +0000, Nick Hilliard wrote:
Job Snijders via db-wg wrote:
On Mon, Nov 13, 2017 at 12:01 PM, Mark Prior <mrp@mrp.net> wrote:
In this particular case I would suggest that you do want the tool to complain rather than ignore the new rp-attribute.
Why would you break backwards compatibility?
as an anecdatum, either option will break irrtoolset.
So irrtoolset does not conform to these recommendation? "Any tool based on RPSL is expected to do a default action on routing policy attributes that they do not understand (e.g. issue a warning and otherwise ignore)." (RFC 2622 section 10.1) and "Any tool that uses the IRR should be designed so that it ignores attributes that it doesn't understand. Most existing tools adhere to this design principle." (RFC 2622 section 10.2) I feared as much, here is some output from the rpslcheck(1) program when run on an object containing the proposed large_community element: mp-export: afi ipv6.unicast to AS13105 announce AS-RCNET-V6 AND NOT large_community.contains(21414:0:570) ^^^^^^^^^^^^^^^^^^^^^^^^ ***Error: wrong mp-export. export: to AS6777 action large_community .= { 6777:0:6777 }; announce AS-FORTHNET ^^^^^^^^^^^^^^^ ***Error: to <peering> expected. mp-import: afi ipv6.unicast from AS8631 msk-rs2.ripn.net action large_community={31376:0:2}; pref=100; accept AS-MSKROUTESERVER ^^^^^^^^^^^^^^^ ***Error: wrong mp-import. import: from AS35082 95.128.51.234 at 95.128.51.233 action pref=500; large_community.append(29527:0:35082,29527:0:60000,29527:0:61200,29527:0:61210); accept AS-VIBUS-LONDON ^^^^^^^^^^^^^^^^^^^^^^ ***Error: from <peering> expected. Can we, based on the observation that irrtoolset will consider any extension to the RPSL rp-attribute dictionary an error, conclude that RPSL can not be extended in this direction? Or should any datapoints involving irrtoolset be ignored since the program effectively is abandonware, and doesn't comply with the recommendations regarding extensibility? Another approach would be to introduce yet another 'import/export'-style attribute, so that we'd have 'import:', 'export:', 'mp-import:', 'mp-export:', 'import-via:', 'export-via:', and now also: 'import-via-large:', 'export-via-large:'. Though this doesn't strike me as a healthy direction for growth and extendability. Kind regards, Job