[db-wg] Proxy proposal large communities

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 at 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