On Mon, Nov 13, 2017 at 01:11:46AM +1030, Mark Prior wrote:
On 13/11/17 00:58, Job Snijders wrote:
On Sun, 12 Nov 2017 at 15:17, Mark Prior via db-wg <db-wg@ripe.net <mailto:db-wg@ripe.net>> wrote:
Wouldn't it be better to just change the definition of community in the RPSL dictionary so that a community of <digit>+ ":" <digit>+ ":" <digit>+ is valid and then have the tools either barf if they don't understand or do "the right thing"? That would seem more consistent with the current scheme where a community can either be an integer or <digit>+ ":" <digit>+.
That goes against the documented recommendations on how to upgrade RPSL.
That's not my reading of RFC 2622 section 10.1. My suggestions seems consistent with the change to route damping mentioned in that section.
Section 10.1 says: "We recommend updating the RPSL dictionary to include appropriate rp-attribute and protocol definitions as new path attributes or router features are introduced." Large BGP Communities [RFC 8092] are a new path attribute, so a new rp-attribute should be used. Old parsers will ignore the new (to them unknown) rp-attributes. Furthermore the section states: "When changing the dictionary, full compatibility should be maintained." When an 'old' parser encounters the following: mp-export: afi ipv6.unicast to AS13105 announce AS-RCNET-V6 AND NOT community.contains(21414:0:570) It'll be seen as a syntax error, because the parameters to 'community' are already defined, and "21414:0:570" doesn't meet that definition, so that is not backwards compatible. typedef: community_elm union integer[1, 4294967200], enum[internet, no_export, no_advertise], list[2:2] of integer[0, 65535] typedef: list of community_elm Section 10 of RFC 2622 should've used a different phrasing, instead of talking about "updating the dictionary" it could've been more explicit and stated "adding or removing rp-attributes from the dictionary". Changing existing entries of the dictionary is hard. Section 10.4 sums it up. Kind regards, Job