"AND NOT" in as-expression
Good morning all, After tinkering around with import-via/export-via attributes, I realised that "AND NOT" is not supported in the as-expression part of peering specifications, although it is described in RFC2622 (along with the semantically equivalent EXCEPT) and included in example (6) of page 25. e.g. currently: import: from AS-AMS-IX-PEERS and not AS6777 accept ANY is not supported, while import: from AS-AMS-IX-PEERS except AS6777 accept ANY is. I have raised a ticket with RIPE NCC about it. Also, Job Snijders was kind enough to act quickly and provide patches for both irrtoolset and whois: https://github.com/RIPE-NCC/whois/pull/237 http://irrtoolset.isc.org/ticket/48 Kind regards, Aris Lambrianidis AMS-IX
On Mon, May 12, 2014 at 10:01:44AM +0200, Aris Lambrianidis wrote:
After tinkering around with import-via/export-via attributes, I realised that "AND NOT" is not supported in the as-expression part of peering specifications, although it is described in RFC2622 (along with the semantically equivalent EXCEPT) and included in example (6) of page 25.
e.g. currently:
import: from AS-AMS-IX-PEERS and not AS6777 accept ANY
is not supported, while
import: from AS-AMS-IX-PEERS except AS6777 accept ANY
is.
I have raised a ticket with RIPE NCC about it. Also, Job Snijders was kind enough to act quickly and provide patches for both irrtoolset and whois: https://github.com/RIPE-NCC/whois/pull/237 http://irrtoolset.isc.org/ticket/48
My question to the community is: does this break your programs or procedures? Kind regards, Job
On 14 May 2014, at 14:20 , Job Snijders <job@instituut.net> wrote:
My question to the community is: does this break your programs or procedures?
Kind regards,
Job
My follow up question, which actually is indirectly related, is if anyone is willing to share an opinion, as to whether "OR" can/should be used implicitly in as-expressions, besides filter expressions. This currently seems to not be the case (the RIPE test database doesn't accept it) and I wonder whether I am interpreting the RFC incorrectly or if it's something that can be considered valid and thus, honored. Kind regards, Aris Lambrianidis AMS-IX
Dear Aris, On Wed, May 21, 2014 at 04:59:11PM +0200, Aris Lambrianidis wrote:
On 14 May 2014, at 14:20 , Job Snijders <job@instituut.net> wrote:
My follow up question, which actually is indirectly related, is if anyone is willing to share an opinion, as to whether "OR" can/should be used implicitly in as-expressions, besides filter expressions.
This currently seems to not be the case (the RIPE test database doesn't accept it) and I wonder whether I am interpreting the RFC incorrectly or if it's something that can be considered valid and thus, honored.
What Aris proposes is the following, instead of writing this: import: from AS-ANY except ( AS1 OR AS2 OR AS3 ) accept ANY One can compress as following: import: from AS-ANY except ( AS1 AS2 AS3 ) accept ANY In other words: when AS or AS-SETS are grouped together, an implicit OR is inserted between the individual AS expressions. This is slightly different compared to what one is allowed to do inside filter-expressions. However, I oppose this proposal for the following reasons: - this is NOT specified in any RFC (most specifically rfc2622) - allowing this type of syntax is merely syntactic sugar - this change is NOT backwards compatible with existing RPSL parsers - a simple workaround exists: use AS-SETS * better readability * easier to maintain in an automated fashion Therefor, I recommend the following policy structure if one wants to exclude a set of ASNs from a specific import or export statement: as-set: AS-EXCLUDED-ASNS members: AS1 members: AS2 members: AS3 aut-num: xxx import: from AS-ANY except AS-EXCLUDED-ASNS accept ANY Kind regards, Job
Hi all, I'd like to withdraw my patch and I propose we continue not accepting 'AND NOT' in as-expressions in import/export context. There are a few reasons: - lack of responses from the list, no consensus. - we've been running the internet for 10+ years without 'AND NOT' in as-expressions. - a different method already exists today: one can use 'EXCEPT' Kind regards, Job On Wed, May 14, 2014 at 02:20:09PM +0200, Job Snijders wrote:
On Mon, May 12, 2014 at 10:01:44AM +0200, Aris Lambrianidis wrote:
After tinkering around with import-via/export-via attributes, I realised that "AND NOT" is not supported in the as-expression part of peering specifications, although it is described in RFC2622 (along with the semantically equivalent EXCEPT) and included in example (6) of page 25.
e.g. currently:
import: from AS-AMS-IX-PEERS and not AS6777 accept ANY
is not supported, while
import: from AS-AMS-IX-PEERS except AS6777 accept ANY
is.
I have raised a ticket with RIPE NCC about it. Also, Job Snijders was kind enough to act quickly and provide patches for both irrtoolset and whois: https://github.com/RIPE-NCC/whois/pull/237 http://irrtoolset.isc.org/ticket/48
My question to the community is: does this break your programs or procedures?
participants (2)
-
Aris Lambrianidis -
Job Snijders