Proxy proposal large communities
Dear Working Group, As discussed at RIPE 75 I want to forward a request by Job Snijders on GitHub: https://github.com/RIPE-NCC/whois/issues/410 Job is asking to add a “large_community" keyword to RPSL dictionary where applicable. And provides the following example: Suggestion: name the keyword large_community mp-export: afi ipv6.unicast to AS13105 announce AS-RCNET-V6 AND NOT large_community.contains(21414:0:570) export: to AS6777 action large_community .= { 6777:0:6777 }; announce AS-FORTHNET mp-import: afi ipv6.unicast from AS8631 msk-rs2.ripn.net action large_community={31376:0:2}; pref=100; accept AS-MSKROUTESERVER 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 filter-set: fltr-as21229-export descr: Filter for AS21229 exported prefixes filter: AS-TVNETWORK AND large_community(21229:0:1) From our end I do not see any issues implementing this on the server side, but I can’t speak to how this will be treated by scripts that may parse RPSL today. Please discuss. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering and Senior Technology Officer RIPE NCC
Tim Bruijnzeels via db-wg wrote:
Job is asking to add a “large_community" keyword to RPSL dictionary where applicable.
Happy to support this if Job provides a patch for irrtoolset. Nick
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>+. I assume a router that can deal with large communities will accept standard ones in the same clauses if someone wants to do that for local use only communities. Mark. On 12/11/17 17:13, Tim Bruijnzeels via db-wg wrote:
Dear Working Group,
As discussed at RIPE 75 I want to forward a request by Job Snijders on GitHub: https://github.com/RIPE-NCC/whois/issues/410
Job is asking to add a “large_community" keyword to RPSL dictionary where applicable.
And provides the following example:
Suggestion: name the keyword large_community
mp-export: afi ipv6.unicast to AS13105 announce AS-RCNET-V6 AND NOT large_community.contains(21414:0:570) export: to AS6777 action large_community .= { 6777:0:6777 }; announce AS-FORTHNET mp-import: afi ipv6.unicast from AS8631 msk-rs2.ripn.net action large_community={31376:0:2}; pref=100; accept AS-MSKROUTESERVER 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
filter-set: fltr-as21229-export descr: Filter for AS21229 exported prefixes filter: AS-TVNETWORK AND large_community(21229:0:1)
From our end I do not see any issues implementing this on the server side, but I can’t speak to how this will be treated by scripts that may parse RPSL today.
Please discuss.
Kind regards,
Tim Bruijnzeels Assistant Manager Software Engineering and Senior Technology Officer RIPE NCC
On Sun, 12 Nov 2017 at 15:17, Mark Prior via db-wg <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. I assume a router that can deal with large communities will accept
standard ones in the same clauses if someone wants to do that for local use only communities.
Unfortunately your assumption is wrong. Kind regards, Job
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.
I assume a router that can deal with large communities will accept standard ones in the same clauses if someone wants to do that for local use only communities.
Unfortunately your assumption is wrong.
That is unfortunate. Mark.
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
In this particular case I would suggest that you do want the tool to complain rather than ignore the new rp-attribute. Mark. On 13/11/17 20:10, Job Snijders wrote:
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
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?
On 13/11/17 21:36, Job Snijders 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?
It's only broken if you include a large community formatted string in your policy and your tool doesn't support it. In that case I would like the script to break rather than load a broken configuration to a router that potentially causes chaos. Mark.
On Mon, Nov 13, 2017 at 12:16 PM, Mark Prior <mrp@mrp.net> wrote:
On 13/11/17 21:36, Job Snijders 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?
It's only broken if you include a large community formatted string in your policy and your tool doesn't support it. In that case I would like the script to break rather than load a broken configuration to a router that potentially causes chaos.
OK, but what about the tools from other people/organisations that parse your autnum object? I'm not sure why you ignore the recommendation "When changing the dictionary, full compatibility should be maintained." without offering any arguments on what the benefits for doing so are.
On 13/11/17 21:52, Job Snijders wrote:
On Mon, Nov 13, 2017 at 12:16 PM, Mark Prior <mrp@mrp.net> wrote:
On 13/11/17 21:36, Job Snijders 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?
It's only broken if you include a large community formatted string in your policy and your tool doesn't support it. In that case I would like the script to break rather than load a broken configuration to a router that potentially causes chaos.
OK, but what about the tools from other people/organisations that parse your autnum object?
I'm not sure why you ignore the recommendation "When changing the dictionary, full compatibility should be maintained." without offering any arguments on what the benefits for doing so are.
I am concerned about how a tool that doesn't understand them copes. If a clause using large communities is just ignored then it might change a restrictive export policy into an ANY without any warning. If that was likely I would prefer it to break so I would know and could fix the policy and/or tool. As for breaking other people's interpretation of your policy that is also probably a good thing for the same reason. I would be interested to know about a use case for people parsing other people's policy objects. Mark.
Hi, On Mon, Nov 13, 2017 at 10:05:55PM +1030, Mark Prior via db-wg wrote:
As for breaking other people's interpretation of your policy that is also probably a good thing for the same reason. I would be interested to know about a use case for people parsing other people's policy objects.
"see what they intend to export to me, and verify that it matches what I'm willing to import"? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Gert Doering via db-wg wrote:
On Mon, Nov 13, 2017 at 10:05:55PM +1030, Mark Prior via db-wg wrote:
As for breaking other people's interpretation of your policy that is also probably a good thing for the same reason. I would be interested to know about a use case for people parsing other people's policy objects.
"see what they intend to export to me, and verify that it matches what I'm willing to import"?
ixps sometimes like to parse other peoples' policy objects for use in route server policy building. The output from this can be hilarious though, and not in a good way either. Nick
On 14/11/17 08:06, Nick Hilliard via db-wg wrote:
Gert Doering via db-wg wrote:
On Mon, Nov 13, 2017 at 10:05:55PM +1030, Mark Prior via db-wg wrote:
As for breaking other people's interpretation of your policy that is also probably a good thing for the same reason. I would be interested to know about a use case for people parsing other people's policy objects.
"see what they intend to export to me, and verify that it matches what I'm willing to import"?
ixps sometimes like to parse other peoples' policy objects for use in route server policy building. The output from this can be hilarious though, and not in a good way either.
Sounds like madness, especially if you're dealing with one I designed :-) Mark.
Mark Prior wrote:
Sounds like madness, especially if you're dealing with one I designed
Complete madness, yes. Quite sensible to use as-set/route/route6 objects for building prefix filtering lists, but RPSL is not viable as a mechanism for handling the complexities of interdomain routing. Nick
On 14/11/17 07:59, Gert Doering wrote:
Hi,
On Mon, Nov 13, 2017 at 10:05:55PM +1030, Mark Prior via db-wg wrote:
As for breaking other people's interpretation of your policy that is also probably a good thing for the same reason. I would be interested to know about a use case for people parsing other people's policy objects.
"see what they intend to export to me, and verify that it matches what I'm willing to import"?
Two questions. 1. Are you planning on doing that via a script or by eye-balling the policy? 2. How useful is that if their export policy is announce { 0.0.0.0/0^0-24 } and community.contains(something)? Do you hunt for the import policies where community "something" is set? Mark.
Hi, On Tue, Nov 14, 2017 at 10:12:11PM +1030, Mark Prior wrote:
1. Are you planning on doing that via a script or by eye-balling the policy?
eyeballing does not scale
2. How useful is that if their export policy is announce { 0.0.0.0/0^0-24 } and community.contains(something)? Do you hunt for the import policies where community "something" is set?
We look for "which ASes are they going to announce, and which routes originate by those". This fine-grained crap is something we ignore anyway (so, a tool that parses this and warns about non-understood extentions is ok, a tool that errors out is not helpful). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On 14/11/17 23:21, Gert Doering wrote:
Hi,
On Tue, Nov 14, 2017 at 10:12:11PM +1030, Mark Prior wrote:
1. Are you planning on doing that via a script or by eye-balling the policy?
eyeballing does not scale
True but I'm somewhat amazed that you try to understand someone else's policy anyway.
2. How useful is that if their export policy is announce { 0.0.0.0/0^0-24 } and community.contains(something)? Do you hunt for the import policies where community "something" is set?
We look for "which ASes are they going to announce, and which routes originate by those".
This fine-grained crap is something we ignore anyway (so, a tool that parses this and warns about non-understood extentions is ok, a tool that errors out is not helpful).
I would suggest it's not fine-grained crap but a sensible approach to classify the prefix only once. If you want to know about the ASes I might transit to you (and thus the prefixes they might announce through me) then you should be looking for an AS set that lists them rather than trying to "understand" a routing policy. If that tool is building configuration that is automatically loaded onto my routers then I don't want it to just warn about stuff it doesn't understand. I want it to complain (bitterly) and set an error status so I can investigate it. Mark.
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. Nick
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
Job Snijders wrote:
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?
How did you come to this conclusion? irrtoolset is non rfc compliant, not the other way around. At a practical level, it's relatively easy to add a new token into the rpsl parser to shut irrtoolset up, even if it's a mess to add proper support for large communities to the code so that they actually do what you'd expect of them.
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.
No need for export-via-large. "export-via" was required because it changed the semantics of the export stanza. Nick
On 13/11/17 22:28, Nick Hilliard via db-wg wrote:
Job Snijders wrote:
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?
How did you come to this conclusion? irrtoolset is non rfc compliant, not the other way around.
At a practical level, it's relatively easy to add a new token into the rpsl parser to shut irrtoolset up, even if it's a mess to add proper support for large communities to the code so that they actually do what you'd expect of them.
As a user I'd prefer it if irrtoolset complained if it couldn't do something meaningful with a policy fragment rather than pretend everything is fine because it passed a syntax check. Mark.
Mark Prior wrote:
As a user I'd prefer it if irrtoolset complained if it couldn't do something meaningful with a policy fragment rather than pretend everything is fine because it passed a syntax check.
patches welcome! :-) Nick
On 13/11/17 22:43, Nick Hilliard wrote:
Mark Prior wrote:
As a user I'd prefer it if irrtoolset complained if it couldn't do something meaningful with a policy fragment rather than pretend everything is fine because it passed a syntax check.
patches welcome! :-)
I'm not Cengiz, that code scares me :-) Mark.
Mark Prior wrote:
On 13/11/17 22:43, Nick Hilliard wrote:
As a user I'd prefer it if irrtoolset complained if it couldn't do something meaningful with a policy fragment rather than pretend everything is fine because it passed a syntax check.
Mark Prior wrote: patches welcome! :-)
I'm not Cengiz, that code scares me :-)
It scares Cengiz too :-) Nick
participants (5)
-
Gert Doering -
Job Snijders -
Mark Prior -
Nick Hilliard -
Tim Bruijnzeels