From rps-owner@ISI.EDU Tue Aug 1 05:55:29 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15470 for ; Tue, 1 Aug 2000 05:55:28 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id CAA03378 for rps-outgoing; Tue, 1 Aug 2000 02:34:01 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id CAA03373 for ; Tue, 1 Aug 2000 02:34:00 -0700 (PDT) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by nitro.isi.edu (8.9.3/8.9.3) with ESMTP id CAA20796 for ; Tue, 1 Aug 2000 02:35:01 -0700 (PDT) Received: from x17.ripe.net (x17.ripe.net [193.0.1.17]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id LAA20247 for ; Tue, 1 Aug 2000 11:34:29 +0200 (CEST) Received: from ripe.net (localhost.ripe.net [127.0.0.1]) by x17.ripe.net (8.8.8/8.8.5) with ESMTP id LAA12778 for ; Tue, 1 Aug 2000 11:34:29 +0200 (CEST) Message-Id: <200008010934.LAA12778@x17.ripe.net> X-Mailer: exmh version 2.0.2 2/24/98 To: rps@ISI.EDU Subject: RPSL questions From: Shane Kerr X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 535 4444 X-Fax: +31 20 535 4445 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 01 Aug 2000 11:34:29 +0200 Sender: owner-rps@ISI.EDU Precedence: rps-list I've been working on reality checking the RIPE routing database versus the actual state of the routing tables, and have come to the point where I'd like to compare the AS paths of visible routes with the routes registered in the database. Unfortunately, I think that this requires that my software actual analyse the relationships between the RPSL objects (previous checks could simply look at comparing origin AS's and the like). RPSL turns out to be, well, non-trivial. I have some observations and some questions. My general approach on the RPSL side is to read an entire RPSL database from a file and then manipulate it in memory - it's less than 18 Mbyte, and memory is cheap. ;) It turns out that working with the set classes is fairly difficult. For as-sets, I first go through each aut-num and add them to the appropriate as-sets where they are members by reference. Next I've done a reachability analysis for the graph of sets, so that each as-set knows every aut-num that it contains, whether by being in a members list, being a member by reference, or by being included from another as-set. Complicated, but handy for ease of use later on. For filter-sets, the problem is more difficult. One problem is that there's nothing in the RPSL specification that forbids loops in the recursive filter set name references. For example: filter-set: fltr-me filter: { 192.168.17.0/24 } or fltr-you filter-set: fltr-you filter: { 192.168.16.0/24 } or fltr-me Now, what my program does is maintain a list of traversed filter-set objects during evaluation, and abort the evaluation at that point with a warning. So what you end up with is: filter-set: fltr-me filter: { 192.168.17.0/24 } or { 192.168.16.0/24 or { } } filter-set: fltr-you filter: { 192.168.16.0/24 } or { 192.168.17.0/24 or { } } Yuck. Hmm...I suppose I'll have to fix those nested braces and remove them. Also, is there a way to group in filters? I didn't see one, and without one certain semantic operations are difficult: AS1 and not { 0.0.0.0/0 } or { 14.0.0.0/8 } (AS1 and not { 0.0.0.0/0 }) or { 14.0.0.0/8 } AS1 and not ( { 0.0.0.0/0 } or { 14.0.0.0/8 } ) Very different, yet both reasonable. I suppose they can be re-ordered to be written in the desired order based on the order of evaluation, but that could be complicated from the user point of view, and hence error-prone. Next, the handy network size operators, specifically ^-, allows for what I consider to be inconsistent recursive loops. Another example: route-set: rs-a members: 12.1.2.0/24, rs-b route-set: rs-b members: rs-a^- Okay, so what could this mean? Possibilities: route-set: rs-a members: 12.1.2.0/24 route-set: rs-b members: 12.1.2.0/24^- Or: route-set: rs-a members: 12.1.2.0/24 route-set: rs-b members: In the first case, route members are copied to all possible route-sets, and then the route set modifiers are applied. In the second case, route members are copied, then the modifiers applied, and so on repeatedly (finally evaluating to {{{{{{{12.1.2.0/24^-}^-}^-}^-}^-}^-}^-}^-, which has no members). Also, can PeerAS be modified with the caret operators? It's not specified, so to me that indicates "no", but since PeerAS is basically a macro for AS###, and AS### can be so modified, it is possible. Comments or pointers much appreciated. Thanks, Shane From rps-owner@ISI.EDU Tue Aug 1 10:21:09 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20475 for ; Tue, 1 Aug 2000 10:21:08 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id HAA17309 for rps-outgoing; Tue, 1 Aug 2000 07:04:14 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA17302 for ; Tue, 1 Aug 2000 07:04:13 -0700 (PDT) Received: from kuji.off.connect.com.au (kuji.off.connect.com.au [203.63.69.33]) by nitro.isi.edu (8.9.3/8.9.3) with ESMTP id HAA14091 for ; Tue, 1 Aug 2000 07:05:10 -0700 (PDT) Received: by kuji.off.connect.com.au (Postfix, from userid 170) id A155110B25; Tue, 1 Aug 2000 23:34:32 +0930 (CST) Received: from connect.com.au (localhost [127.0.0.1]) by kuji.off.connect.com.au (Postfix) with ESMTP id 4C5616F6C for ; Tue, 1 Aug 2000 23:34:32 +0930 (CST) To: rps@ISI.EDU Subject: Limitation with RPSL MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13658.965138666.1@connect.com.au> Date: Tue, 01 Aug 2000 23:34:27 +0930 From: Mark Prior Message-Id: <20000801140432.A155110B25@kuji.off.connect.com.au> Sender: owner-rps@ISI.EDU Precedence: rps-list Having recenty tried to use the AS sets we register as if I was a peer I discovered that there is no easy way to iterate over objects in an AS set. I have an AS set that lists all the customer ASes that provide transit to other ASes through us. This allows me to have an import statement such as from AS2764:AS-TRANSIT accept AS2764:AS-CUSTOMERS:PeerAS AND <^PeerAS+ AS2764:AS-CUSTOMERS:PeerAS+$> and so keep track of the ASes that a specific customer may transit. I can't think of a way to use these constructs from a peer of AS2764's perspective (specifically to generate AS path filters) without manually iterating each member of AS2764:AS-TRANSIT in their policy. This is obviously sub optimal for them as they would need to manually track changes in our AS2764:AS-TRANSIT object. It would seem to me that RPSL needs a foreach construct but I'm open to other suggestions on how this could be managed. Mark. From rps-owner@ISI.EDU Tue Aug 1 14:04:18 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14476 for ; Tue, 1 Aug 2000 14:04:17 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id KAA00412 for rps-outgoing; Tue, 1 Aug 2000 10:46:31 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA29542 for ; Tue, 1 Aug 2000 10:31:52 -0700 (PDT) Received: from c017.sfo.cp.net (c017-h021.c017.sfo.cp.net [209.228.12.235]) by nitro.isi.edu (8.9.3/8.9.3) with SMTP id KAA05245 for ; Tue, 1 Aug 2000 10:32:53 -0700 (PDT) Received: (cpmta 23978 invoked from network); 1 Aug 2000 10:32:23 -0700 Received: from dns.packetdesign.net (HELO mailman.packetdesign.com) (216.15.46.10) by smtp.packetdesign.com with SMTP; 1 Aug 2000 10:32:23 -0700 X-Sent: 1 Aug 2000 17:32:23 GMT Received: from localhost.localdomain.packetdesign.com ([192.168.0.254]) by mailman.packetdesign.com (8.9.3/8.9.3) with SMTP id KAA06754; Tue, 1 Aug 2000 10:31:54 -0700 (PDT) (envelope-from cengiz@packetdesign.com) From: Cengiz Alaettinoglu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14727.2474.185463.281928@localhost.localdomain> Date: Tue, 1 Aug 2000 10:32:26 -0700 (PDT) To: cengiz@packetdesign.com Cc: Shane Kerr , rps@ISI.EDU Subject: Re: RPSL questions In-Reply-To: <14727.305.549467.900394@localhost.localdomain> References: <200008010934.LAA12778@x17.ripe.net> <14727.305.549467.900394@localhost.localdomain> X-Mailer: VM 6.75 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid Reply-to: cengiz@packetdesign.com X-Organisation: USC / Information Sciences Institute X-Phone: +1 (310) 448 8219 X-Fax: +1 (310) 823 6714 Sender: owner-rps@ISI.EDU Precedence: rps-list Content-Transfer-Encoding: 7bit Here is a sample use of prtraceroute. It maps traceroute IP addresses to AS paths, and then verifies if the policies registered allow that AS path. In your approach you get the AS path directly from BGP (if I understood it correctly). You can see some valid as hops, some first choice, some second, and some hops (level3) not there. [elf prtraceroute]$ sudo ./prtraceroute -h whois.radb.net -p 43 whois.ripe.net prtraceroute to whois.ripe.net (193.0.0.129), 30 hops max, 12 byte packets 1 [AS1207] leopard-wireless.ietf.marconi.com (147.73.132.1) 177.695 ms 180.676 ms 197.479 ms 2 [AS1207] tiger.ietf.marconi.com (147.73.130.2) 336.505 ms [AS5050] nss5-ietf-a8-0-4.psc.net (192.88.115.157) 275.74 ms 190.007 ms 3 [AS7018] 12.127.244.61 (12.127.244.61) 303.297 ms 5182.99 ms [AS5050] nss5-ietf-a8-0-4.psc.net (192.88.115.157) 166.32 ms 4 [AS7018] gbr1-a30s9.n54ny.ip.att.net (12.126.7.162) 238.406 ms 175.822 ms 173.137 ms 5 [AS7018] gbr3-p70.n54ny.ip.att.net (12.122.1.149) 496.015 ms 176.086 ms 175.448 ms 6 [AS7018] gbr3-p30.wswdc.ip.att.net (12.122.2.166) 259.43 ms 199.438 ms 189.396 ms 7 [AS7018] ggr1-p360.wswdc.ip.att.net (12.123.9.49) 5270.56 ms 181.35 ms 201.312 ms 8 * 182.077 ms [AS0] posip2-3.core2.washington1.level3.net (209.0.227.97) 204.091 ms 9 [AS0] so-6-0-0.mp1.Washington1.level3.net (209.247.10.69) 197.655 ms 190.27 ms * 10 183.928 ms [AS0] so-0-0-0.mp1.Weehawken1.level3.net (209.247.8.46) 209.398 ms 200.077 ms 11 [AS0] loopback0.core1.Weehawken1.Level3.net (209.247.2.1) 209.809 ms * [AS0] so-0-0-0.mp1.Weehawken1.level3.net (209.247.8.46) 190.06 ms 12 * * [AS0] loopback0.core1.Weehawken1.Level3.net (209.247.2.1) 195.378 ms 13 [AS9057] loopback0.ams-ix.Amsterdam1.Level3.net (212.72.32.8) 15518.6 ms [AS0] 63.211.89.1 (63.211.89.1) 329.187 ms 426.964 ms 14 [AS1200] Amsterdam1.ripe.net (193.148.15.68) 669.749 ms 315.879 ms * 15 265.704 ms 268.589 ms [AS6660] fe20.pampus.ripe.net (193.0.0.246) 421.115 ms 16 [AS6660] joshua.ripe.net (193.0.0.200) 593.68 ms [AS6660] fe20.pampus.ripe.net (193.0.0.246) 5426.7 ms 263.061 ms Path taken: AS1207 AS5050 AS7018 (???) (???) (???) (???) (???) (???) AS1200 AS6660 16 AS6660 fe20.pampus.ripe.net destination -> internal 15 AS6660 fe20.pampus.ripe.net internal -> !export 14 AS1200 Amsterdam1.ripe.net import: 2 -> peer unregistered 13 AS0 63.211.89.1 !registered -> !registered 12 AS0 loopback0.core1.Weehawken1.Level3.net !registered -> !registered 11 AS0 so-0-0-0.mp1.Weehawken1.level3.net !registered -> !registered 10 AS0 so-0-0-0.mp1.Weehawken1.level3.net !registered -> !registered 9 AS0 so-6-0-0.mp1.Washington1.level3.net !registered -> !registered 8 AS0 posip2-3.core2.washington1.level3.net !registered -> !registered 7 AS7018 ggr1-p360.wswdc.ip.att.net import: 2 -> internal 6 AS7018 gbr3-p30.wswdc.ip.att.net internal -> internal 5 AS7018 gbr3-p70.n54ny.ip.att.net internal -> internal 4 AS7018 gbr1-a30s9.n54ny.ip.att.net internal -> !export 3 AS5050 nss5-ietf-a8-0-4.psc.net import: 2 -> internal 2 AS5050 nss5-ietf-a8-0-4.psc.net internal -> export 1 AS1207 leopard-wireless.ietf.marconi.com import: 1 -> internal 0 AS1207 wireless-132-136.ietf.marconi.com internal -> source Cengiz -- Cengiz Alaettinoglu Packet Design Inc. From rps-owner@ISI.EDU Tue Aug 1 14:40:07 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19035 for ; Tue, 1 Aug 2000 14:40:06 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id LAA03066 for rps-outgoing; Tue, 1 Aug 2000 11:21:55 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA00146 for ; Tue, 1 Aug 2000 10:42:14 -0700 (PDT) Received: from c017.sfo.cp.net (c017-h015.c017.sfo.cp.net [209.228.12.229]) by nitro.isi.edu (8.9.3/8.9.3) with SMTP id KAA06522 for ; Tue, 1 Aug 2000 10:43:16 -0700 (PDT) Received: (cpmta 27186 invoked from network); 1 Aug 2000 09:56:13 -0700 Received: from dns.packetdesign.net (HELO mailman.packetdesign.com) (216.15.46.10) by smtp.packetdesign.com with SMTP; 1 Aug 2000 09:56:13 -0700 X-Sent: 1 Aug 2000 16:56:13 GMT Received: from localhost.localdomain.packetdesign.com ([192.168.0.254]) by mailman.packetdesign.com (8.9.3/8.9.3) with SMTP id JAA06526; Tue, 1 Aug 2000 09:55:46 -0700 (PDT) (envelope-from cengiz@packetdesign.com) From: Cengiz Alaettinoglu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14727.305.549467.900394@localhost.localdomain> Date: Tue, 1 Aug 2000 09:56:17 -0700 (PDT) To: Shane Kerr Cc: rps@ISI.EDU Subject: Re: RPSL questions In-Reply-To: <200008010934.LAA12778@x17.ripe.net> References: <200008010934.LAA12778@x17.ripe.net> X-Mailer: VM 6.75 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid Reply-to: cengiz@packetdesign.com X-Organisation: USC / Information Sciences Institute X-Phone: +1 (310) 448 8219 X-Fax: +1 (310) 823 6714 Sender: owner-rps@ISI.EDU Precedence: rps-list Content-Transfer-Encoding: 7bit Shane, Shane Kerr (shane@ripe.net) on August 1: > I've been working on reality checking the RIPE routing database versus the > actual state of the routing tables, and have come to the point where I'd like > to compare the AS paths of visible routes with the routes registered in the > database. > > Unfortunately, I think that this requires that my software actual analyse the > relationships between the RPSL objects (previous checks could simply look at > comparing origin AS's and the like). RPSL turns out to be, well, non-trivial. If you just want to compare the origin ASes. You only need to consider the route objects: route: 128.9.0.0/16 origin: as226 and see if the BGP AS path has as226 as the last AS. I think Merit does this on a regular basis and puts the results to their web pages. I suppose this is what you used to do in the past, and now you want to do more and actually see if the two consecutive ASes in an AS path can actually occur according to the policies registered. This is a good and a novel approach. (Try to design your tool so that it is still usable if some ASes in an AS path did not register their aut-num's.) > > I have some observations and some questions. > > My general approach on the RPSL side is to read an entire RPSL database from a > file and then manipulate it in memory - it's less than 18 Mbyte, and memory is > cheap. ;) It turns out that working with the set classes is fairly difficult. > > For as-sets, I first go through each aut-num and add them to the appropriate > as-sets where they are members by reference. Next I've done a reachability > analysis for the graph of sets, so that each as-set knows every aut-num that > it contains, whether by being in a members list, being a member by reference, > or by being included from another as-set. Complicated, but handy for ease of > use later on. > > For filter-sets, the problem is more difficult. One problem is that there's > nothing in the RPSL specification that forbids loops in the recursive filter > set name references. For example: This recursive behavior is the same as the old well understood ripe-181 behavior. Basically, you should expand recursions till you hit a set that is already expanded (no matter the form it apperars). That is below both filters equal to { 192.168.17.0/24 } or { 192.168.16.0/24 } > > filter-set: fltr-me > filter: { 192.168.17.0/24 } or fltr-you > > filter-set: fltr-you > filter: { 192.168.16.0/24 } or fltr-me > > Now, what my program does is maintain a list of traversed filter-set objects > during evaluation, and abort the evaluation at that point with a warning. So > what you end up with is: > > filter-set: fltr-me > filter: { 192.168.17.0/24 } or { 192.168.16.0/24 or { } } > > filter-set: fltr-you > filter: { 192.168.16.0/24 } or { 192.168.17.0/24 or { } } > > Yuck. Hmm...I suppose I'll have to fix those nested braces and remove them. > Also, is there a way to group in filters? I didn't see one, and without one > certain semantic operations are difficult: > > AS1 and not { 0.0.0.0/0 } or { 14.0.0.0/8 } > > (AS1 and not { 0.0.0.0/0 }) or { 14.0.0.0/8 } > AS1 and not ( { 0.0.0.0/0 } or { 14.0.0.0/8 } ) > You may want to look at peval in RAToolSet, it puts any complicated policy expression into disjunctive normal form. And also look at prpath/prtraceroute's from RAToolSet. You will notice they are doing similar operations on policy as you want to do. You may want to use the RAToolSet libraries, but build your own application on top. For example, ./peval -none peval> {128.9.0.0/16} or {128.8.0.0/16} or {} ({128.8.0.0/16, 128.9.0.0/16}) peval> {128.9.0.0/16} and AS1 or {128.8.0.0/16} and AS1 ({128.8.0.0/16, 128.9.0.0/16} AND (AS1 )) (You can even have as paths and communities). > Very different, yet both reasonable. I suppose they can be re-ordered to be > written in the desired order based on the order of evaluation, but that could > be complicated from the user point of view, and hence error-prone. > > Next, the handy network size operators, specifically ^-, allows for what I > consider to be inconsistent recursive loops. Another example: > > route-set: rs-a > members: 12.1.2.0/24, rs-b > > route-set: rs-b > members: rs-a^- > > Okay, so what could this mean? Possibilities: > still the same thing, you expand recursion one level: ra-a is 12.1.2.0/24 and rs-b is 12.1.2.0/24^- > route-set: rs-a > members: 12.1.2.0/24 > > route-set: rs-b > members: 12.1.2.0/24^- > yup. > Or: > > route-set: rs-a > members: 12.1.2.0/24 > > route-set: rs-b > members: > > In the first case, route members are copied to all possible route-sets, and > then the route set modifiers are applied. In the second case, route members > are copied, then the modifiers applied, and so on repeatedly (finally > evaluating to {{{{{{{12.1.2.0/24^-}^-}^-}^-}^-}^-}^-}^-, which has no members). > > Also, can PeerAS be modified with the caret operators? It's not specified, so > to me that indicates "no", but since PeerAS is basically a macro for AS###, > and AS### can be so modified, it is possible. PeerAS^+ is valid. And it is not hard. I.e. When it is time to evaluate whether AS5 can come before AS4 in an AS path and if you are looking at AS4's import policy, AS5 is the PeerAS. P.S. A lot of these are already implemented in the RAToolSet libraries. You may benefit from them. > > Comments or pointers much appreciated. > > Thanks, > Shane Cengiz -- Cengiz Alaettinoglu Packet Design Inc. From rps-owner@ISI.EDU Wed Aug 2 07:26:06 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00116 for ; Wed, 2 Aug 2000 07:26:04 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id EAA11175 for rps-outgoing; Wed, 2 Aug 2000 04:07:43 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id EAA11170 for ; Wed, 2 Aug 2000 04:07:41 -0700 (PDT) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by nitro.isi.edu (8.9.3/8.9.3) with ESMTP id EAA07599 for ; Wed, 2 Aug 2000 04:08:43 -0700 (PDT) Received: from x17.ripe.net (x17.ripe.net [193.0.1.17]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id NAA15164; Wed, 2 Aug 2000 13:08:12 +0200 (CEST) Received: from ripe.net (localhost.ripe.net [127.0.0.1]) by x17.ripe.net (8.8.8/8.8.5) with ESMTP id NAA05351; Wed, 2 Aug 2000 13:08:12 +0200 (CEST) Message-Id: <200008021108.NAA05351@x17.ripe.net> X-Mailer: exmh version 2.0.2 2/24/98 To: cengiz@packetdesign.com cc: rps@ISI.EDU Subject: Re: RPSL questions In-reply-to: Your message of Tue, 01 Aug 2000 09:56:17 PDT. <14727.305.549467.900394@localhost.localdomain> References: <14727.305.549467.900394@localhost.localdomain> From: Shane Kerr X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 535 4444 X-Fax: +31 20 535 4445 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 02 Aug 2000 13:08:11 +0200 Sender: owner-rps@ISI.EDU Precedence: rps-list Cengiz Alaettinoglu writes: * * If you just want to compare the origin ASes. You only need to consider * the route objects: * * route: 128.9.0.0/16 * origin: as226 * * and see if the BGP AS path has as226 as the last AS. I think Merit * does this on a regular basis and puts the results to their web pages. * * I suppose this is what you used to do in the past, and now you want to * do more and actually see if the two consecutive ASes in an AS path can * actually occur according to the policies registered. This is a good * and a novel approach. (Try to design your tool so that it is still * usable if some ASes in an AS path did not register their aut-num's.) Indeed, comparing the origin AS paths took about 4 hours of work - trivial. The stage I'm at now is seeing if every single single AS-path that we see at our router is registered correctly (or rather, what parts are registered correctly). * This recursive behavior is the same as the old well understood * ripe-181 behavior. Basically, you should expand recursions till you * hit a set that is already expanded (no matter the form it * apperars). That is below both filters equal to * { 192.168.17.0/24 } or { 192.168.16.0/24 } * * > filter-set: fltr-me * > filter: { 192.168.17.0/24 } or fltr-you * > * > filter-set: fltr-you * > filter: { 192.168.16.0/24 } or fltr-me * > I argue that the behaviour is *not* the same as the RIPE-181 behaviour. There are no filter-sets or route-sets in RIPE-181, only as-sets (or as-macros, which I understand to be the same). As I mentioned in my original e-mail, handling as-set recursion is not too difficult. However, this is *not* the same as filter-set recursion, which is doing symbolic expansion in an expression. Having a set without any members is not the same as having an incomplete expression: as-set: as-foo members: as-foo filter-set: fltr-foo filter: any and (not fltr-foo) Perhaps it's just an aesthetic preference, but this as-set doesn't bother me, but the filter-set does. Also note that route-set recursion isn't the same as the RIPE-181 as-macro recursion, because of the range operators (see below). * You may want to look at peval in RAToolSet, it puts any complicated * policy expression into disjunctive normal form. And also look at * prpath/prtraceroute's from RAToolSet. You will notice they are doing * similar operations on policy as you want to do. You may want to use * the RAToolSet libraries, but build your own application on top. * * For example, * ./peval -none * peval> {128.9.0.0/16} or {128.8.0.0/16} or {} * ({128.8.0.0/16, 128.9.0.0/16}) * peval> {128.9.0.0/16} and AS1 or {128.8.0.0/16} and AS1 * ({128.8.0.0/16, 128.9.0.0/16} AND (AS1 )) Ah okay. I don't really care about conjunctive normal form or anything fancy, just the text of RFC 2622 doesn't describe parenthesis as a grouping operator (although I now notice that the filter set example uses them). The grammar defined in the appendix includes them, though. Might be nice to document them in the text, especially since grammar doesn't define semantics, just form (although I'd say it's fairly safe as is since the meaning of parenthesis is obvious). * > route-set: rs-a * > members: 12.1.2.0/24, rs-b * > * > route-set: rs-b * > members: rs-a^- * > * > Okay, so what could this mean? Possibilities: * > * * still the same thing, you expand recursion one level: * * ra-a is 12.1.2.0/24 and rs-b is 12.1.2.0/24^- Is this documented anywhere (other than the RAToolSet source code)? The description in RFC 2622 is very terse: "An address prefix or a route-set name in a members attribute can be optionally followed by a range operator." The example then given describes the ^+ operator, which is of course very simple. The effects of circular recursion are not documented at all (well, maybe buried somewhere in one of the portions after section 8, but I haven't studied those yet). * > Also, can PeerAS be modified with the caret operators? It's not specified * , so * > to me that indicates "no", but since PeerAS is basically a macro for AS### * , * > and AS### can be so modified, it is possible. * * PeerAS^+ is valid. And it is not hard. I.e. When it is time to * evaluate whether AS5 can come before AS4 in an AS path and if you are * looking at AS4's import policy, AS5 is the PeerAS. * * P.S. A lot of these are already implemented in the RAToolSet * libraries. You may benefit from them. * * Cengiz Again, it might be nice if the use of range operators on PeerAS was documented. I appreciate that much of this stuff is already implemented in the RAToolSet code. I have downloaded it, and am perusing the prtraceroute code now (even though it won't compile on either BSDi 3.1 or Solaris 7 - complaints about some Linux header file that I don't feel like looking at now). While it should be helpful to see how the libraries do things, I'd prefer to understand them at the same time. It does worry me a bit that the answer to "How does feature xyz work?" seems to be "RAToolSet does it like this". :( Even so, I'll probably steal the BGPRoute::isMatching() code, at least in part. :) Speaking of which, is the code really copyright 1994 by USC and/or IBM? I may not be able to use it then, since this is definitely for commercial purposes (at least, as long as RIPE NCC charges for services). Shane From rps-owner@ISI.EDU Wed Aug 2 13:53:08 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12055 for ; Wed, 2 Aug 2000 13:53:06 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id KAA25658 for rps-outgoing; Wed, 2 Aug 2000 10:33:18 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id KAA25625 for ; Wed, 2 Aug 2000 10:33:10 -0700 (PDT) Received: from c017.sfo.cp.net (c017-h014.c017.sfo.cp.net [209.228.12.228]) by nitro.isi.edu (8.9.3/8.9.3) with SMTP id KAA18915 for ; Wed, 2 Aug 2000 10:34:13 -0700 (PDT) Received: (cpmta 29251 invoked from network); 2 Aug 2000 10:33:42 -0700 Received: from dns.packetdesign.net (HELO mailman.packetdesign.com) (216.15.46.10) by smtp.packetdesign.com with SMTP; 2 Aug 2000 10:33:42 -0700 X-Sent: 2 Aug 2000 17:33:42 GMT Received: from localhost.localdomain.packetdesign.com ([192.168.0.254]) by mailman.packetdesign.com (8.9.3/8.9.3) with SMTP id KAA12699; Wed, 2 Aug 2000 10:33:12 -0700 (PDT) (envelope-from cengiz@packetdesign.com) From: Cengiz Alaettinoglu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14728.23419.410557.663389@localhost.localdomain> Date: Wed, 2 Aug 2000 10:33:47 -0700 (PDT) To: Shane Kerr Cc: cengiz@packetdesign.com, rps@ISI.EDU Subject: Re: RPSL questions In-Reply-To: <200008021108.NAA05351@x17.ripe.net> References: <14727.305.549467.900394@localhost.localdomain> <200008021108.NAA05351@x17.ripe.net> X-Mailer: VM 6.75 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid Reply-to: cengiz@packetdesign.com X-Organisation: USC / Information Sciences Institute X-Phone: +1 (310) 448 8219 X-Fax: +1 (310) 823 6714 Sender: owner-rps@ISI.EDU Precedence: rps-list Content-Transfer-Encoding: 7bit Shane, Please provide any clarifying text you think would make the document more clear. This kind of text is OK to add during the proposed standards stage. Disallowing mutual recursion is not an option since those two objects may be registered by different people. However the DB implementors are encouraged to disallow or warn users of these. But if the semantics are not clear when the recursion is used, as an author, I would welcome a draft paragraph on what the semantics should be. I could work from that paragraph and include it in the document. Shane Kerr (shane@ripe.net) on August 2: > * This recursive behavior is the same as the old well understood > * ripe-181 behavior. Basically, you should expand recursions till you > * hit a set that is already expanded (no matter the form it > * apperars). That is below both filters equal to > * { 192.168.17.0/24 } or { 192.168.16.0/24 } > * > * > filter-set: fltr-me > * > filter: { 192.168.17.0/24 } or fltr-you > * > > * > filter-set: fltr-you > * > filter: { 192.168.16.0/24 } or fltr-me > * > > > I argue that the behaviour is *not* the same as the RIPE-181 behaviour. There > are no filter-sets or route-sets in RIPE-181, only as-sets (or as-macros, > which I understand to be the same). As I mentioned in my original e-mail, > handling as-set recursion is not too difficult. However, this is *not* the > same as filter-set recursion, which is doing symbolic expansion in an > expression. Having a set without any members is not the same as having an > incomplete expression: > > as-set: as-foo > members: as-foo > > filter-set: fltr-foo > filter: any and (not fltr-foo) > > Perhaps it's just an aesthetic preference, but this as-set doesn't bother me, > but the filter-set does. > > Also note that route-set recursion isn't the same as the RIPE-181 as-macro > recursion, because of the range operators (see below). > > * You may want to look at peval in RAToolSet, it puts any complicated > * policy expression into disjunctive normal form. And also look at > * prpath/prtraceroute's from RAToolSet. You will notice they are doing > * similar operations on policy as you want to do. You may want to use > * the RAToolSet libraries, but build your own application on top. > * > * For example, > * ./peval -none > * peval> {128.9.0.0/16} or {128.8.0.0/16} or {} > * ({128.8.0.0/16, 128.9.0.0/16}) > * peval> {128.9.0.0/16} and AS1 or {128.8.0.0/16} and AS1 > * ({128.8.0.0/16, 128.9.0.0/16} AND (AS1 )) > > Ah okay. I don't really care about conjunctive normal form or anything fancy, > just the text of RFC 2622 doesn't describe parenthesis as a grouping operator > (although I now notice that the filter set example uses them). The grammar > defined in the appendix includes them, though. Might be nice to document them > in the text, especially since grammar doesn't define semantics, just form > (although I'd say it's fairly safe as is since the meaning of parenthesis is > obvious). Actually, the document says parenthesis can be used to change the order of evaluation. Perhaps what we need to make explicit the evaluation of a set in a recursion chain a second time terminates in an empty set, (or "not any" in case of filter set). > > * > route-set: rs-a > * > members: 12.1.2.0/24, rs-b > * > > * > route-set: rs-b > * > members: rs-a^- > * > > * > Okay, so what could this mean? Possibilities: > * > > * > * still the same thing, you expand recursion one level: > * > * ra-a is 12.1.2.0/24 and rs-b is 12.1.2.0/24^- > > Is this documented anywhere (other than the RAToolSet source code)? The > description in RFC 2622 is very terse: "An address prefix or a route-set name > in a members attribute can be optionally followed by a range operator." The > example then given describes the ^+ operator, which is of course very simple. > The effects of circular recursion are not documented at all (well, maybe > buried somewhere in one of the portions after section 8, but I haven't studied > those yet). > The document explains ^ operators as operators that take a prefix as an argument and make them a "set" of prefixes. The document also says when ^ operators are applied to a "set" of prefixes, they distribute over the members of the set. Hence the following is valid: { 128.9.160.0/24^+ }^32 { 128.9.160.0/24^+ } is a set of 512 prefixes (i.e. all more specifics of /24). You apply ^32 to all of these 512 prefixes. You get 256 prefixes as a result those are the ones with length 32. These 256 prefixes can be written as 128.9.160.0/24^32. But to get the semantics right, always think of set of prefixes. rs-foo, or AS555 also all define set of prefixes hence rs-foo^+ is also valid. If you think the document is terse on this, please let me know, or provide a paragraph. > * > Also, can PeerAS be modified with the caret operators? It's not specified > * , so > * > to me that indicates "no", but since PeerAS is basically a macro for AS### > * , > * > and AS### can be so modified, it is possible. > * > * PeerAS^+ is valid. And it is not hard. I.e. When it is time to > * evaluate whether AS5 can come before AS4 in an AS path and if you are > * looking at AS4's import policy, AS5 is the PeerAS. > * > * P.S. A lot of these are already implemented in the RAToolSet > * libraries. You may benefit from them. > * > * Cengiz > > Again, it might be nice if the use of range operators on PeerAS was > documented. I appreciate that much of this stuff is already implemented in > the RAToolSet code. I have downloaded it, and am perusing the prtraceroute > code now (even though it won't compile on either BSDi 3.1 or Solaris 7 - > complaints about some Linux header file that I don't feel like looking at > now). While it should be helpful to see how the libraries do things, I'd > prefer to understand them at the same time. > > It does worry me a bit that the answer to "How does feature xyz work?" seems > to be "RAToolSet does it like this". :( Even so, I'll probably steal the > BGPRoute::isMatching() code, at least in part. :) Please reread my email, and you will see I have not done this. I only pointed to you free (and IMO good) code that you may or may not benefit from. > > Speaking of which, is the code really copyright 1994 by USC and/or IBM? I may > not be able to use it then, since this is definitely for commercial purposes > (at least, as long as RIPE NCC charges for services). > Unless you intend to sell your BGP verification tool, ISI's view is that you can do whatever you want with it. Note that most of our users are ISP's who use them in their commercial networks. If you sell your BGP tool and make money, ISI would like to get a cut, but this is not how RIPE works. (I no longer can speak for ISI, but I dont think the view has changed). Cengiz -- Cengiz Alaettinoglu Packet Design Inc. From rps-owner@ISI.EDU Thu Aug 3 00:55:25 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10213 for ; Thu, 3 Aug 2000 00:55:25 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id VAA24953 for rps-outgoing; Wed, 2 Aug 2000 21:37:00 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id VAA24948 for ; Wed, 2 Aug 2000 21:36:57 -0700 (PDT) Received: from c017.sfo.cp.net (c017-h014.c017.sfo.cp.net [209.228.12.228]) by nitro.isi.edu (8.9.3/8.9.3) with SMTP id VAA25221 for ; Wed, 2 Aug 2000 21:38:00 -0700 (PDT) Received: (cpmta 11465 invoked from network); 2 Aug 2000 21:37:29 -0700 Received: from dns.packetdesign.net (HELO mailman.packetdesign.com) (216.15.46.10) by smtp.packetdesign.com with SMTP; 2 Aug 2000 21:37:29 -0700 X-Sent: 3 Aug 2000 04:37:29 GMT Received: from localhost.localdomain.packetdesign.com ([192.168.0.254]) by mailman.packetdesign.com (8.9.3/8.9.3) with SMTP id VAA16430; Wed, 2 Aug 2000 21:37:28 -0700 (PDT) (envelope-from cengiz@packetdesign.com) From: Cengiz Alaettinoglu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14728.63248.301543.517829@localhost.localdomain> Date: Wed, 2 Aug 2000 21:37:36 -0700 (PDT) To: Mark Prior Cc: rps@ISI.EDU Subject: Re: Limitation with RPSL In-Reply-To: <20000801140432.A155110B25@kuji.off.connect.com.au> References: <20000801140432.A155110B25@kuji.off.connect.com.au> X-Mailer: VM 6.75 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid Reply-to: cengiz@packetdesign.com X-Organisation: USC / Information Sciences Institute X-Phone: +1 (310) 448 8219 X-Fax: +1 (310) 823 6714 Sender: owner-rps@ISI.EDU Precedence: rps-list Content-Transfer-Encoding: 7bit Hi Mark, Now that the working group is closed I dont know how to handle this case. I personally think it is a good idea. We should have had it in the first place, but it was not clear it was needed. How about the following: why dont you write a personal i-d and explain us the foreach statement. We can get the discussion started on it and take it to the ADs. Cengiz -- Cengiz Alaettinoglu Packet Design Inc. From rps-owner@ISI.EDU Wed Aug 16 10:57:32 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26837 for ; Wed, 16 Aug 2000 10:57:31 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id HAA07237 for rps-outgoing; Wed, 16 Aug 2000 07:36:12 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id HAA07232 for ; Wed, 16 Aug 2000 07:36:11 -0700 (PDT) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by nitro.isi.edu (8.9.3/8.9.3) with ESMTP id HAA17241 for ; Wed, 16 Aug 2000 07:37:18 -0700 (PDT) Received: from x17.ripe.net (x17.ripe.net [193.0.1.17]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id QAA12088; Wed, 16 Aug 2000 16:36:47 +0200 (CEST) Received: from ripe.net (localhost.ripe.net [127.0.0.1]) by x17.ripe.net (8.8.8/8.8.5) with ESMTP id QAA14088; Wed, 16 Aug 2000 16:36:47 +0200 (CEST) Message-Id: <200008161436.QAA14088@x17.ripe.net> X-Mailer: exmh version 2.0.2 2/24/98 To: cengiz@packetdesign.com cc: rps@ISI.EDU Subject: Re: RPSL questions In-reply-to: Your message of Wed, 02 Aug 2000 10:33:47 PDT. <14728.23419.410557.663389@localhost.localdomain> References: <14728.23419.410557.663389@localhost.localdomain> From: Shane Kerr X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 535 4444 X-Fax: +31 20 535 4445 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Aug 2000 16:36:47 +0200 Sender: owner-rps@ISI.EDU Precedence: rps-list Cengiz, Sorry about taking so long to get back on this. Fortunately (for me) the project I'm working on probably won't require much sophisticated RPSL interpreting, at least originally. And all this after I wrote an RPSL interpreter in Perl (not complete, but it understands the current RIPE-181 to RPSL converted data). ;) Apologies if this has all been discussed before, and none of the following suggestions are meant to be taken with anything but a grain of proverb. > Disallowing mutual recursion is not an option since those two objects > may be registered by different people. However the DB implementors are > encouraged to disallow or warn users of these. But if the semantics > are not clear when the recursion is used, as an author, I would > welcome a draft paragraph on what the semantics should be. I could > work from that paragraph and include it in the document. I understood mutual recursion may be important, but I still think the semantics are not well-defined by the RFC. Again: 1. For as-sets there is no problem, because they are true sets, and set theory has no problem handling this (with no exclusion operators, you never get Russell's paradox after all). 2. For rs-sets there is a problem because it is not exactly defined what an inclusion of a more specific route, ^-, means in a recursive scenario. I would suggest that the RFC say something like you mention in your reply: "In the case of a recursive rs-set using a range operator, the range operators should be considered to apply after member sets have been added. For example: route-set: rs-louis members: 12.1.2.0/24, rs-wu route-set: rs-wu members: rs-louis^- Is the same as: route-set: rs-louis members: 12.1.2.0/24 route-set: rs-wu members: 12.1.2.0/24^-" 3. For filter-sets, first the easy addition: "Any range operator may be applied on PeerAS, the same as any other AS." Next, the more sticky problem of recursive filter-sets: "In the case of a recursive filter-set, the recursive reference is considered to be an empty list when evaluated. For example: filter-set: fltr-chmee filter: any and (not fltr-chmee) Is the same as: filter-set: fltr-chmee filter: any and (not { }) This is true no matter at which point in the evaluation of the set the recursion occurs." 4. I'd also like to see comments handled differently. I would suggest: "An attribute with a free-form value may not have a comment. The '#' character is considered part of the text." I think it would be nice to allow: person: Shane Kerr address: RIPE NCC address: Singel #258 address: 1016 AB Amsterdam address: NL Without the number being ripped off because it's a comment. People really do use the (pound|hash|sharp|number) character! 5. Another nit-picky detail. The phone specification is: + [ext. ] Unfortunately, this won't work for regions without city codes, e.g. North America. I mean, you can fake it, but it's not strictly correct. Perhaps: + [] [ext. ] It's non-ambiguous still, and could be 100% correct. :) 6. YANPD (Yet Another Nit-Picky Detail). On page 9, it reads: "The descr, tech-c, admin-c, remarks, notify, mnt-by, changed and source attributes are attributes of all RPSL classes. Their syntax, semantics, and mandatory, optional, multi-valued, or single-valued status are the same for all RPSL classes." However, it doesn't then bother to say what those are. Presumably (necessarily?) this is as defined under the maintainer class itself. I'd like to see this explicitly stated, or better yet defined before jumping in to class definitions (more on this below). These would help me, at least. Actually, having worked through the RFC, it fits in very well with the other IETF RFC's I've used to try to build software. It's very difficult. :P I think perhaps a reorgani[sz]ation would be helpful. I don't know if it is possible at this stage of the document, however. I still haven't gotten especially familiar with all of the document (esp. the advanced route stuff), but from what I have done, I can suggest: 1. Move all attribute descriptions to a single section (section 2 is fine). Perhaps put generic (i.e. date, free-form) and specific (i.e. phone, email-address) in different sub-sections. Perhaps separate out routing related (i.e. ipv4-address, address-prefix-range) from other attributes (i.e. nic-handle, dns-name), on this assumption that most folks are already familiar with a DNS name, or can at least look it up. 2. Move the mntner class into a separate section, and make the description of the contact information an appendix. The mntner objects are required, as they are used for mnt-by-ref, but the contact information is simply flavou?r text. 3. Move the description of sets to after the description of the data that the sets will contain. I found forward referencing the contents of sets stranger than forward referencing sets themselves. 4. Move the description of the predefined set objects into the description of each set type. For instance, put the description of ASx and AS-X into a subsection (with a title) of the as-set description, along with AS-ANY and PeerAS (not sure why that's not there). Put the description of RS-ANY into a subsection on route-set. 5. Move the description of filtering out of the filter-set description and either: - put it in front, after the description of attributes - make it an appendix This filtering language is used by aut-num objects after all! I found it interesting (and a pain) that routes have a key composed of multiple attributes. They are, in fact, the only class that has a composite key. Personally, I think it would be nice to eliminate this, and instead have: route: mandatory, single-valued, class key origin: mandatory, list-valued I suppose you could have the same route from different origins with different maintainers, but realistically that doesn't happen very often - I checked the routing tables to be sure. ;) Actually, I found the use of list AND multi-valued attributes to be redundant. It's not too bad, but in the code they end up getting combined into a single list, so why have both types? Someone mentioned that it might be helpful for separation of duties (i.e. one list is maintained by maintainer A, a second list by maintainer B). It seems like an explicit remark attribute would be much more helpful (better to explain what you mean than hope that people can figure it out). Shane From rps-owner@ISI.EDU Wed Aug 16 12:07:47 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28979 for ; Wed, 16 Aug 2000 12:07:46 -0400 (EDT) Received: by zephyr.isi.edu (8.9.3/8.9.3) id IAA09866 for rps-outgoing; Wed, 16 Aug 2000 08:45:58 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id DAA28720 for ; Wed, 16 Aug 2000 03:27:18 -0700 (PDT) Received: from anubis.cisnet ([194.151.41.217]) by nitro.isi.edu (8.9.3/8.9.3) with ESMTP id DAA28646 for ; Wed, 16 Aug 2000 03:28:25 -0700 (PDT) Received: from clara.net (IDENT:faz@barkley.cisnet [10.17.130.63]) by anubis.cisnet (8.9.3/8.8.7) with ESMTP id MAA26912 for ; Wed, 16 Aug 2000 12:27:54 +0200 Message-ID: <399A6C8E.F062B952@clara.net> Date: Wed, 16 Aug 2000 12:27:26 +0200 From: Farhan Memon X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.14-5.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: rps@ISI.EDU Subject: RPSL and the RIPE database Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-rps@ISI.EDU Precedence: rps-list Content-Transfer-Encoding: 7bit Hi I was wondering what the current state of the RIPE database and its relation to RPSL Does RIPE currently accept RPSL updates? Is RIPE obselete yet?when will it be? and i noticed intet-rtr objects. IS this done in RPSL or is this done in extentions to ripe? would you advise migrating our operation team to update with RPSL yet or at a later time hope you can help brgrds Faz Memon From rps-owner@ISI.EDU Thu Aug 17 11:24:58 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28509 for ; Thu, 17 Aug 2000 11:24:56 -0400 (EDT) Received: by zephyr.isi.edu (8.9.3/8.9.3) id IAA06171 for rps-outgoing; Thu, 17 Aug 2000 08:02:15 -0700 (PDT) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id IAA06166 for ; Thu, 17 Aug 2000 08:02:14 -0700 (PDT) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id IAA29992 for ; Thu, 17 Aug 2000 08:03:22 -0700 (PDT) Received: from x17.ripe.net (x17.ripe.net [193.0.1.17]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id RAA23935; Thu, 17 Aug 2000 17:02:51 +0200 (CEST) Received: from ripe.net (localhost.ripe.net [127.0.0.1]) by x17.ripe.net (8.8.8/8.8.5) with ESMTP id RAA00600; Thu, 17 Aug 2000 17:02:51 +0200 (CEST) Message-Id: <200008171502.RAA00600@x17.ripe.net> X-Mailer: exmh version 2.0.2 2/24/98 To: Farhan Memon Cc: rps@ISI.EDU Subject: Re: RPSL and the RIPE database In-reply-to: Your message of Wed, 16 Aug 2000 12:27:26 +0200. <399A6C8E.F062B952@clara.net> References: <399A6C8E.F062B952@clara.net> From: Shane Kerr X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 535 4444 X-Fax: +31 20 535 4445 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Aug 2000 17:02:50 +0200 Sender: owner-rps@ISI.EDU Precedence: rps-list Farhan, A document was just published today which should help to clarify any questions you have about the RIPE database transition. You can find this here: http://www/ripencc/pub-services/db/reimp/new-transition-v3.ps Section 4, on page 13, addresses the transition plan specifically. This is know as the re-implementation project, and the home page is here: http://www/ripencc/pub-services/db/reimp/index.html If you still have questions, please direct them to the database mailing list for this: db-beta@ripe.net -- Shane Kerr Database Software Engineer RIPE NCC +31 20 535 4427 From rps-owner@ISI.EDU Thu Aug 24 15:42:55 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22950 for ; Thu, 24 Aug 2000 15:42:54 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id MAA13207 for rps-outgoing; Thu, 24 Aug 2000 12:09:46 -0700 (PDT) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA13202 for ; Thu, 24 Aug 2000 12:09:44 -0700 (PDT) Received: from c017.sfo.cp.net (c017-h015.c017.sfo.cp.net [209.228.12.229]) by gamma.isi.edu (8.9.3/8.9.3) with SMTP id MAA09118 for ; Thu, 24 Aug 2000 12:10:55 -0700 (PDT) Received: (cpmta 15211 invoked from network); 24 Aug 2000 12:02:36 -0700 Received: from dns.packetdesign.net (HELO mailman.packetdesign.com) (216.15.46.10) by smtp.packetdesign.com with SMTP; 24 Aug 2000 12:02:36 -0700 X-Sent: 24 Aug 2000 19:02:36 GMT Received: from localhost.localdomain.packetdesign.com ([192.168.0.254]) by mailman.packetdesign.com (8.9.3/8.9.3) with SMTP id MAA37182; Thu, 24 Aug 2000 12:02:32 -0700 (PDT) (envelope-from cengiz@packetdesign.com) From: Cengiz Alaettinoglu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14757.28996.371133.441448@localhost.localdomain> Date: Thu, 24 Aug 2000 12:02:28 -0700 (PDT) To: Shane Kerr Cc: cengiz@packetdesign.com, rps@ISI.EDU Subject: Re: RPSL questions In-Reply-To: <200008161436.QAA14088@x17.ripe.net> References: <14728.23419.410557.663389@localhost.localdomain> <200008161436.QAA14088@x17.ripe.net> X-Mailer: VM 6.72 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Reply-to: cengiz@packetdesign.com X-Organisation: USC / Information Sciences Institute X-Phone: +1 (310) 448 8219 X-Fax: +1 (310) 823 6714 Sender: owner-rps@ISI.EDU Precedence: rps-list Content-Transfer-Encoding: 7bit Shane, these are excellent comments. When we re-open, you can count on seeing these in the document. I think # comments in free-text is a good point. The multi-valued/list-valued was discusses a lot, for a while we disallowed list-valued attributes to be multi-valued at the same time. Shane Kerr (shane@ripe.net) on August 16: > Cengiz, > > Sorry about taking so long to get back on this. Fortunately (for me) > the project I'm working on probably won't require much sophisticated > RPSL interpreting, at least originally. > > And all this after I wrote an RPSL interpreter in Perl (not complete, > but it understands the current RIPE-181 to RPSL converted data). ;) > > Apologies if this has all been discussed before, and none of the > following suggestions are meant to be taken with anything but a grain > of proverb. > > > Disallowing mutual recursion is not an option since those two objects > > may be registered by different people. However the DB implementors are > > encouraged to disallow or warn users of these. But if the semantics > > are not clear when the recursion is used, as an author, I would > > welcome a draft paragraph on what the semantics should be. I could > > work from that paragraph and include it in the document. > > I understood mutual recursion may be important, but I still think the > semantics are not well-defined by the RFC. Again: > > 1. For as-sets there is no problem, because they are true sets, and set > theory has no problem handling this (with no exclusion operators, you > never get Russell's paradox after all). > > 2. For rs-sets there is a problem because it is not exactly defined > what an inclusion of a more specific route, ^-, means in a recursive > scenario. I would suggest that the RFC say something like you mention > in your reply: > > "In the case of a recursive rs-set using a range operator, the range > operators should be considered to apply after member sets have been > added. For example: > > route-set: rs-louis > members: 12.1.2.0/24, rs-wu > > route-set: rs-wu > members: rs-louis^- > > Is the same as: > > route-set: rs-louis > members: 12.1.2.0/24 > > route-set: rs-wu > members: 12.1.2.0/24^-" > > 3. For filter-sets, first the easy addition: > > "Any range operator may be applied on PeerAS, the same as any other AS." > > Next, the more sticky problem of recursive filter-sets: > > "In the case of a recursive filter-set, the recursive reference is > considered to be an empty list when evaluated. For example: > > filter-set: fltr-chmee > filter: any and (not fltr-chmee) > > Is the same as: > > filter-set: fltr-chmee > filter: any and (not { }) > > This is true no matter at which point in the evaluation of the set the > recursion occurs." > > 4. I'd also like to see comments handled differently. I would suggest: > > "An attribute with a free-form value may not have a comment. The '#' > character is considered part of the text." > > I think it would be nice to allow: > > person: Shane Kerr > address: RIPE NCC > address: Singel #258 > address: 1016 AB Amsterdam > address: NL > > Without the number being ripped off because it's a comment. People > really do use the (pound|hash|sharp|number) character! > > 5. Another nit-picky detail. The phone specification is: > > + [ext. ] > > Unfortunately, this won't work for regions without city codes, e.g. > North America. I mean, you can fake it, but it's not strictly correct. > Perhaps: > > + [] [ext. ] > > It's non-ambiguous still, and could be 100% correct. :) > > 6. YANPD (Yet Another Nit-Picky Detail). On page 9, it reads: > > "The descr, tech-c, admin-c, remarks, notify, mnt-by, changed and > source attributes are attributes of all RPSL classes. Their syntax, > semantics, and mandatory, optional, multi-valued, or single-valued > status are the same for all RPSL classes." > > However, it doesn't then bother to say what those are. Presumably > (necessarily?) this is as defined under the maintainer class itself. > I'd like to see this explicitly stated, or better yet defined before > jumping in to class definitions (more on this below). > > These would help me, at least. Actually, having worked through the > RFC, it fits in very well with the other IETF RFC's I've used to try to > build software. It's very difficult. :P > > I think perhaps a reorgani[sz]ation would be helpful. I don't know if > it is possible at this stage of the document, however. I still haven't > gotten especially familiar with all of the document (esp. the advanced > route stuff), but from what I have done, I can suggest: > > 1. Move all attribute descriptions to a single section (section 2 is > fine). Perhaps put generic (i.e. date, free-form) and specific (i.e. > phone, email-address) in different sub-sections. Perhaps separate out > routing related (i.e. ipv4-address, address-prefix-range) from other > attributes (i.e. nic-handle, dns-name), on this assumption that most > folks are already familiar with a DNS name, or can at least look it up. > > 2. Move the mntner class into a separate section, and make the > description of the contact information an appendix. The mntner objects > are required, as they are used for mnt-by-ref, but the contact > information is simply flavou?r text. > > 3. Move the description of sets to after the description of the data > that the sets will contain. I found forward referencing the contents > of sets stranger than forward referencing sets themselves. > > 4. Move the description of the predefined set objects into the > description of each set type. For instance, put the description of ASx > and AS-X into a subsection (with a title) of the as-set description, > along with AS-ANY and PeerAS (not sure why that's not there). Put the > description of RS-ANY into a subsection on route-set. > > 5. Move the description of filtering out of the filter-set description and > either: > > - put it in front, after the description of attributes > - make it an appendix > > This filtering language is used by aut-num objects after all! > > I found it interesting (and a pain) that routes have a key composed of > multiple attributes. They are, in fact, the only class that has a > composite key. Personally, I think it would be nice to eliminate this, > and instead have: > > route: mandatory, single-valued, class key > origin: mandatory, list-valued > > I suppose you could have the same route from different origins with > different maintainers, but realistically that doesn't happen very > often - I checked the routing tables to be sure. ;) > > Actually, I found the use of list AND multi-valued attributes to be > redundant. It's not too bad, but in the code they end up getting > combined into a single list, so why have both types? Someone mentioned > that it might be helpful for separation of duties (i.e. one list is > maintained by maintainer A, a second list by maintainer B). It seems > like an explicit remark attribute would be much more helpful (better to > explain what you mean than hope that people can figure it out). > > Shane > > Cengiz -- Cengiz Alaettinoglu Packet Design Inc. From rps-owner@ISI.EDU Thu Aug 24 15:45:48 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23005 for ; Thu, 24 Aug 2000 15:45:47 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id MAA13613 for rps-outgoing; Thu, 24 Aug 2000 12:15:30 -0700 (PDT) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id MAA13608 for ; Thu, 24 Aug 2000 12:15:28 -0700 (PDT) Received: from c017.sfo.cp.net (c017-h015.c017.sfo.cp.net [209.228.12.229]) by gamma.isi.edu (8.9.3/8.9.3) with SMTP id MAA10012 for ; Thu, 24 Aug 2000 12:16:40 -0700 (PDT) Received: (cpmta 17944 invoked from network); 24 Aug 2000 12:09:30 -0700 Received: from dns.packetdesign.net (HELO mailman.packetdesign.com) (216.15.46.10) by smtp.packetdesign.com with SMTP; 24 Aug 2000 12:09:30 -0700 X-Sent: 24 Aug 2000 19:09:30 GMT Received: from localhost.localdomain.packetdesign.com ([192.168.0.254]) by mailman.packetdesign.com (8.9.3/8.9.3) with SMTP id MAA37249; Thu, 24 Aug 2000 12:09:27 -0700 (PDT) (envelope-from cengiz@packetdesign.com) From: Cengiz Alaettinoglu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14757.29402.320650.979121@localhost.localdomain> Date: Thu, 24 Aug 2000 12:09:14 -0700 (PDT) To: cengiz@packetdesign.com Cc: Shane Kerr , rps@ISI.EDU Subject: Re: RPSL questions In-Reply-To: <14757.28996.371133.441448@localhost.localdomain> References: <14728.23419.410557.663389@localhost.localdomain> <200008161436.QAA14088@x17.ripe.net> <14757.28996.371133.441448@localhost.localdomain> X-Mailer: VM 6.72 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Reply-to: cengiz@packetdesign.com X-Organisation: USC / Information Sciences Institute X-Phone: +1 (310) 448 8219 X-Fax: +1 (310) 823 6714 Sender: owner-rps@ISI.EDU Precedence: rps-list Content-Transfer-Encoding: 7bit Cengiz Alaettinoglu (cengiz@packetdesign.com) on August 24: > > Shane, these are excellent comments. When we re-open, you can count on > seeing these in the document. > > I think # comments in free-text is a good point. The > multi-valued/list-valued was discusses a lot, for a while we > disallowed list-valued attributes to be multi-valued at the same time. Oh, I was not clear. I meant we will not reopen the multi-valued/list-valued discussion again since it was discussed a lot. > > Shane Kerr (shane@ripe.net) on August 16: > > Cengiz, > > > > Sorry about taking so long to get back on this. Fortunately (for me) > > the project I'm working on probably won't require much sophisticated > > RPSL interpreting, at least originally. > > > > And all this after I wrote an RPSL interpreter in Perl (not complete, > > but it understands the current RIPE-181 to RPSL converted data). ;) > > > > Apologies if this has all been discussed before, and none of the > > following suggestions are meant to be taken with anything but a grain > > of proverb. > > > > > Disallowing mutual recursion is not an option since those two objects > > > may be registered by different people. However the DB implementors are > > > encouraged to disallow or warn users of these. But if the semantics > > > are not clear when the recursion is used, as an author, I would > > > welcome a draft paragraph on what the semantics should be. I could > > > work from that paragraph and include it in the document. > > > > I understood mutual recursion may be important, but I still think the > > semantics are not well-defined by the RFC. Again: > > > > 1. For as-sets there is no problem, because they are true sets, and set > > theory has no problem handling this (with no exclusion operators, you > > never get Russell's paradox after all). > > > > 2. For rs-sets there is a problem because it is not exactly defined > > what an inclusion of a more specific route, ^-, means in a recursive > > scenario. I would suggest that the RFC say something like you mention > > in your reply: > > > > "In the case of a recursive rs-set using a range operator, the range > > operators should be considered to apply after member sets have been > > added. For example: > > > > route-set: rs-louis > > members: 12.1.2.0/24, rs-wu > > > > route-set: rs-wu > > members: rs-louis^- > > > > Is the same as: > > > > route-set: rs-louis > > members: 12.1.2.0/24 > > > > route-set: rs-wu > > members: 12.1.2.0/24^-" > > > > 3. For filter-sets, first the easy addition: > > > > "Any range operator may be applied on PeerAS, the same as any other AS." > > > > Next, the more sticky problem of recursive filter-sets: > > > > "In the case of a recursive filter-set, the recursive reference is > > considered to be an empty list when evaluated. For example: > > > > filter-set: fltr-chmee > > filter: any and (not fltr-chmee) > > > > Is the same as: > > > > filter-set: fltr-chmee > > filter: any and (not { }) > > > > This is true no matter at which point in the evaluation of the set the > > recursion occurs." > > > > 4. I'd also like to see comments handled differently. I would suggest: > > > > "An attribute with a free-form value may not have a comment. The '#' > > character is considered part of the text." > > > > I think it would be nice to allow: > > > > person: Shane Kerr > > address: RIPE NCC > > address: Singel #258 > > address: 1016 AB Amsterdam > > address: NL > > > > Without the number being ripped off because it's a comment. People > > really do use the (pound|hash|sharp|number) character! > > > > 5. Another nit-picky detail. The phone specification is: > > > > + [ext. ] > > > > Unfortunately, this won't work for regions without city codes, e.g. > > North America. I mean, you can fake it, but it's not strictly correct. > > Perhaps: > > > > + [] [ext. ] > > > > It's non-ambiguous still, and could be 100% correct. :) > > > > 6. YANPD (Yet Another Nit-Picky Detail). On page 9, it reads: > > > > "The descr, tech-c, admin-c, remarks, notify, mnt-by, changed and > > source attributes are attributes of all RPSL classes. Their syntax, > > semantics, and mandatory, optional, multi-valued, or single-valued > > status are the same for all RPSL classes." > > > > However, it doesn't then bother to say what those are. Presumably > > (necessarily?) this is as defined under the maintainer class itself. > > I'd like to see this explicitly stated, or better yet defined before > > jumping in to class definitions (more on this below). > > > > These would help me, at least. Actually, having worked through the > > RFC, it fits in very well with the other IETF RFC's I've used to try to > > build software. It's very difficult. :P > > > > I think perhaps a reorgani[sz]ation would be helpful. I don't know if > > it is possible at this stage of the document, however. I still haven't > > gotten especially familiar with all of the document (esp. the advanced > > route stuff), but from what I have done, I can suggest: > > > > 1. Move all attribute descriptions to a single section (section 2 is > > fine). Perhaps put generic (i.e. date, free-form) and specific (i.e. > > phone, email-address) in different sub-sections. Perhaps separate out > > routing related (i.e. ipv4-address, address-prefix-range) from other > > attributes (i.e. nic-handle, dns-name), on this assumption that most > > folks are already familiar with a DNS name, or can at least look it up. > > > > 2. Move the mntner class into a separate section, and make the > > description of the contact information an appendix. The mntner objects > > are required, as they are used for mnt-by-ref, but the contact > > information is simply flavou?r text. > > > > 3. Move the description of sets to after the description of the data > > that the sets will contain. I found forward referencing the contents > > of sets stranger than forward referencing sets themselves. > > > > 4. Move the description of the predefined set objects into the > > description of each set type. For instance, put the description of ASx > > and AS-X into a subsection (with a title) of the as-set description, > > along with AS-ANY and PeerAS (not sure why that's not there). Put the > > description of RS-ANY into a subsection on route-set. > > > > 5. Move the description of filtering out of the filter-set description and > > either: > > > > - put it in front, after the description of attributes > > - make it an appendix > > > > This filtering language is used by aut-num objects after all! > > > > I found it interesting (and a pain) that routes have a key composed of > > multiple attributes. They are, in fact, the only class that has a > > composite key. Personally, I think it would be nice to eliminate this, > > and instead have: > > > > route: mandatory, single-valued, class key > > origin: mandatory, list-valued > > > > I suppose you could have the same route from different origins with > > different maintainers, but realistically that doesn't happen very > > often - I checked the routing tables to be sure. ;) > > > > Actually, I found the use of list AND multi-valued attributes to be > > redundant. It's not too bad, but in the code they end up getting > > combined into a single list, so why have both types? Someone mentioned > > that it might be helpful for separation of duties (i.e. one list is > > maintained by maintainer A, a second list by maintainer B). It seems > > like an explicit remark attribute would be much more helpful (better to > > explain what you mean than hope that people can figure it out). > > > > Shane > > > > > > > Cengiz > > -- > Cengiz Alaettinoglu Packet Design Inc. > > Cengiz -- Cengiz Alaettinoglu Packet Design Inc. From rps-owner@ISI.EDU Fri Aug 25 03:44:47 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13793 for ; Fri, 25 Aug 2000 03:44:47 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id AAA11942 for rps-outgoing; Fri, 25 Aug 2000 00:26:34 -0700 (PDT) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id AAA11937 for ; Fri, 25 Aug 2000 00:26:32 -0700 (PDT) Received: from philou.ch (courier@philou.ch [195.202.200.121]) by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id AAA19220 for ; Fri, 25 Aug 2000 00:27:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) (uid 1000) by philou.ch with local; Fri, 25 Aug 2000 09:27:36 +0200 Date: Fri, 25 Aug 2000 09:27:36 +0200 From: Philippe Strauss To: rps@ISI.EDU Subject: advanced refine usage Message-ID: <20000825092736.A12219@philou.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-rps@ISI.EDU Precedence: rps-list Content-Transfer-Encoding: 7bit Hello RPS users, I've beed diving into advanced RPSL topic lately (and avoided drowning for now :) for fullfilling the need of a customer. Reading and rereading RFC2622 about the refine operator, I first tought it was possible to use such a chained refine construct to fit in all routing policy we need: aut-num: AS1234 import: { # # Reject 'martians' routes and our own routes from any incoming # routing information # from AS-ANY accept ANY AND NOT AS1234:RS-MARTIANS AND NOT AS1234:RS-PROVIDER; # # NB: at this stage we treat ALL routes obviously # } refine { # # Upstreams first # from AS1234:AS-Upstream action pref=30; community.append(1234:6100); accept <^PeerAS*>; # # Zero cost peers # from AS1234:AS-Peer action pref=20; accept <^PeerAS*>; # # Customers # from AS1234:AS-Customer action community.append(1234:6000); accept <^PeerAS*$>; # # NB: Here too we consider ALL routes # } refine { # # We assign different local-pref on various peerings for # balancing purpose of outbound traffic (eBGP traffic engineering) # from AS1234:AS-PeerSwiss # 1234:6202 will be tagged on swiss peers, including private ones. action pref=10; community.append(1234:6202); accept <^PeerAS*>; # from prng-cixp action pref=11; community.append(1234:6238); accept <^PeerAS*>; # from prng-linx action pref=21; community.append(1234:6232); accept <^PeerAS*>; # from prng-amsix action pref=20; community.append(1234:6233); accept <^PeerAS*>; # from prng-decix action pref=21; community.append(1234:6234); accept <^PeerAS*>; # # Customer ability to tweak local-pref applied to their routes # in our network. # from AS1234:AS-Customer action pref=5; accept community.contains(1234:1); # from AS1234:AS-Customer action pref=6; accept community.contains(1234:2); # # NB: Here we only focus on IXP's and some customer routes # } refine { # # Tuning, peering with higher/lower local-pref than usual, # mostly for load-balancing purpose. # from AS786 195.xx.xx.xx at linx.blahblah.net action pref=19; accept ANY; # from AS5401 195.xx.xx.xx at decix.blahblah.net action pref=20; accept ANY; # # NB: Here we only focus on a sparse set of routes # } The first statement prevent route polution, the second segregate route type, the third refine peering point local-pref and customer local-pref tweaking, the fourth used only for short-term tuning. My mistake was to chain refine on such different set of routes, I mean the cartisian product will end up considering only the common set for each refine (left or right) handside, narrowing down to the sparse set of routes of AS786 and AS5401. Would it be wise/wrong/discouraged/ugly/convoluted to use a: from AS-ANY accept ANY statement at the end of statement 3 and 4, the one not focusing on all routes, and let the order precedence rule do the rest? I'm not sure of the resulting cartisian product of hum, such a mess :) an other good solution is to use one import per route-type, ie having 3 import in this case, one for upstream, one for peer, one for customer. hence the peering set in rightmost refine will always be contained in the leftmost statement, but the route pollution preventing need to be duplicated. I can live with this redudancy, but would like some feedback to 'feel' better the refine operator. some comment about the RFC: the 'nested' word may be somewhat confusing for the refine statement. chained would be better IMHO. I'm sure there is a good reason for evaluating nested or chained statement for both except and refine from right to left, but no insight is given. I missed that one at first. Otherwise, I'm impressed by the fine granularity of RPSL. will like to see the world switching to it :) Regards. -- Philippe Strauss, Telecom Consulting email: Psychiatrists say that one out of four people are mentally ill. Check three friends. If they're OK, you're it. -- From rps-owner@ISI.EDU Fri Aug 25 03:50:51 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13872 for ; Fri, 25 Aug 2000 03:50:50 -0400 (EDT) Received: by zephyr.isi.edu (8.9.3/8.9.3) id AAA12289 for rps-outgoing; Fri, 25 Aug 2000 00:37:23 -0700 (PDT) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id AAA12284 for ; Fri, 25 Aug 2000 00:37:21 -0700 (PDT) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by gamma.isi.edu (8.9.3/8.9.3) with ESMTP id AAA21326 for ; Fri, 25 Aug 2000 00:38:29 -0700 (PDT) Received: from x47.ripe.net (x47.ripe.net [193.0.1.47]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id JAA26578; Fri, 25 Aug 2000 09:37:55 +0200 (CEST) Received: from localhost (engin@localhost) by x47.ripe.net (8.8.8/8.8.5) with ESMTP id JAA20949; Fri, 25 Aug 2000 09:37:55 +0200 (CEST) X-Authentication-Warning: x47.ripe.net: engin owned process doing -bs Date: Fri, 25 Aug 2000 09:37:55 +0200 (CEST) From: Engin Gunduz X-Sender: engin@x47.ripe.net To: Cengiz Alaettinoglu cc: rps@ISI.EDU Subject: Re: RPSL questions In-Reply-To: <14757.29402.320650.979121@localhost.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rps@ISI.EDU Precedence: rps-list Hi Cengiz, On Thu, 24 Aug 2000, Cengiz Alaettinoglu wrote: > > Cengiz Alaettinoglu (cengiz@packetdesign.com) on August 24: > > > > Shane, these are excellent comments. When we re-open, you can count on > > seeing these in the document. > > > > I think # comments in free-text is a good point. The > > multi-valued/list-valued was discusses a lot, for a while we > > disallowed list-valued attributes to be multi-valued at the same time. > > Oh, I was not clear. I meant we will not reopen the > multi-valued/list-valued discussion again since it was discussed a > lot. Do you have a document which contains changes to RFC 2622 (which will possibly be incorporated into next RPSL RFC) ? Thanks, -engin > > Engin Gunduz RIPE NCC Database Group From rps-owner@ISI.EDU Fri Aug 25 19:27:51 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01650 for ; Fri, 25 Aug 2000 19:27:50 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id QAA16507 for rps-outgoing; Fri, 25 Aug 2000 16:05:07 -0700 (PDT) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id QAA16494 for ; Fri, 25 Aug 2000 16:05:03 -0700 (PDT) Received: from c017.sfo.cp.net (c017-h015.c017.sfo.cp.net [209.228.12.229]) by gamma.isi.edu (8.9.3/8.9.3) with SMTP id QAA19889 for ; Fri, 25 Aug 2000 16:06:15 -0700 (PDT) Received: (cpmta 29209 invoked from network); 25 Aug 2000 16:05:44 -0700 Received: from dns.PACKETDESIGN.NET (HELO mailman.packetdesign.com) (216.15.46.10) by smtp.packetdesign.com (209.228.12.229) with SMTP; 25 Aug 2000 16:05:44 -0700 X-Sent: 25 Aug 2000 23:05:44 GMT Received: from localhost.localdomain.packetdesign.com ([192.168.0.254]) by mailman.packetdesign.com (8.9.3/8.9.3) with SMTP id QAA47048; Fri, 25 Aug 2000 16:05:41 -0700 (PDT) (envelope-from cengiz@packetdesign.com) From: Cengiz Alaettinoglu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14758.64449.857625.946599@localhost.localdomain> Date: Fri, 25 Aug 2000 16:05:37 -0700 (PDT) To: Engin Gunduz Cc: Cengiz Alaettinoglu , rps@ISI.EDU Subject: Re: RPSL questions In-Reply-To: References: <14757.29402.320650.979121@localhost.localdomain> X-Mailer: VM 6.72 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Reply-to: cengiz@packetdesign.com X-Organisation: USC / Information Sciences Institute X-Phone: +1 (310) 448 8219 X-Fax: +1 (310) 823 6714 Sender: owner-rps@ISI.EDU Precedence: rps-list Content-Transfer-Encoding: 7bit Engin Gunduz (engin@ripe.net) on August 25: > > Hi Cengiz, > > On Thu, 24 Aug 2000, Cengiz Alaettinoglu wrote: > > > > Cengiz Alaettinoglu (cengiz@packetdesign.com) on August 24: > > > > > > Shane, these are excellent comments. When we re-open, you can count on > > > seeing these in the document. > > > > > > I think # comments in free-text is a good point. The > > > multi-valued/list-valued was discusses a lot, for a while we > > > disallowed list-valued attributes to be multi-valued at the same time. > > > > Oh, I was not clear. I meant we will not reopen the > > multi-valued/list-valued discussion again since it was discussed a > > lot. > > Do you have a document which contains changes to RFC 2622 > (which will possibly be incorporated into next RPSL RFC) ? No, only a todo list. It is almost entirely for clarification. There is also one message from you regarding rps auth. May be one of these days I can sum of the todo list. > > Thanks, > -engin > > > > > > > Engin Gunduz > RIPE NCC Database Group > > > Cengiz -- Cengiz Alaettinoglu Packet Design Inc. From rps-owner@ISI.EDU Fri Aug 25 20:22:56 2000 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02168 for ; Fri, 25 Aug 2000 20:22:56 -0400 (EDT) Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id QAA18360 for rps-outgoing; Fri, 25 Aug 2000 16:55:07 -0700 (PDT) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id QAA18309 for ; Fri, 25 Aug 2000 16:55:01 -0700 (PDT) Received: from c017.sfo.cp.net (c017-h014.c017.sfo.cp.net [209.228.12.228]) by gamma.isi.edu (8.9.3/8.9.3) with SMTP id QAA03830 for ; Fri, 25 Aug 2000 16:56:12 -0700 (PDT) Received: (cpmta 13378 invoked from network); 25 Aug 2000 16:01:46 -0700 Received: from dns.PACKETDESIGN.NET (HELO mailman.packetdesign.com) (216.15.46.10) by smtp.packetdesign.com (209.228.12.228) with SMTP; 25 Aug 2000 16:01:46 -0700 X-Sent: 25 Aug 2000 23:01:46 GMT Received: from localhost.localdomain.packetdesign.com ([192.168.0.254]) by mailman.packetdesign.com (8.9.3/8.9.3) with SMTP id QAA46987; Fri, 25 Aug 2000 16:01:44 -0700 (PDT) (envelope-from cengiz@packetdesign.com) From: Cengiz Alaettinoglu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14758.64212.446724.421547@localhost.localdomain> Date: Fri, 25 Aug 2000 16:01:40 -0700 (PDT) To: Philippe Strauss Cc: rps@ISI.EDU Subject: Re: advanced refine usage In-Reply-To: <20000825092736.A12219@philou.ch> References: <20000825092736.A12219@philou.ch> X-Mailer: VM 6.72 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Reply-to: cengiz@packetdesign.com X-Organisation: USC / Information Sciences Institute X-Phone: +1 (310) 448 8219 X-Fax: +1 (310) 823 6714 Sender: owner-rps@ISI.EDU Precedence: rps-list Content-Transfer-Encoding: 7bit Philippe Strauss (philou@philou.ch) on August 25: > Hello RPS users, > > I've beed diving into advanced RPSL topic lately (and avoided drowning for > now :) for fullfilling the need of a customer. > > Reading and rereading RFC2622 about the refine operator, I first tought > it was possible to use such a chained refine construct to fit in all > routing policy we need: > > aut-num: AS1234 > import: { > # > # Reject 'martians' routes and our own routes from any incoming > # routing information > # > from AS-ANY > accept ANY AND NOT AS1234:RS-MARTIANS AND NOT AS1234:RS-PROVIDER; > # > # NB: at this stage we treat ALL routes obviously > # > } refine { > # > # Upstreams first > # > from AS1234:AS-Upstream > action pref=30; community.append(1234:6100); > accept <^PeerAS*>; > # > # Zero cost peers > # > from AS1234:AS-Peer > action pref=20; > accept <^PeerAS*>; > # > # Customers > # > from AS1234:AS-Customer > action community.append(1234:6000); > accept <^PeerAS*$>; > # > # NB: Here too we consider ALL routes > # > } refine { > # > # We assign different local-pref on various peerings for > # balancing purpose of outbound traffic (eBGP traffic engineering) > # > from AS1234:AS-PeerSwiss > # 1234:6202 will be tagged on swiss peers, including private ones. > action pref=10; community.append(1234:6202); > accept <^PeerAS*>; > # > from prng-cixp > action pref=11; community.append(1234:6238); > accept <^PeerAS*>; > # > from prng-linx > action pref=21; community.append(1234:6232); > accept <^PeerAS*>; > # > from prng-amsix > action pref=20; community.append(1234:6233); > accept <^PeerAS*>; > # > from prng-decix > action pref=21; community.append(1234:6234); > accept <^PeerAS*>; > # > # Customer ability to tweak local-pref applied to their routes > # in our network. > # > from AS1234:AS-Customer > action pref=5; > accept community.contains(1234:1); > # > from AS1234:AS-Customer > action pref=6; > accept community.contains(1234:2); > # > # NB: Here we only focus on IXP's and some customer routes > # > } refine { > # > # Tuning, peering with higher/lower local-pref than usual, > # mostly for load-balancing purpose. > # > from AS786 195.xx.xx.xx at linx.blahblah.net > action pref=19; > accept ANY; > # > from AS5401 195.xx.xx.xx at decix.blahblah.net > action pref=20; > accept ANY; > # > # NB: Here we only focus on a sparse set of routes > # > } > > The first statement prevent route polution, the second segregate route > type, the third refine peering point local-pref and customer local-pref > tweaking, the fourth used only for short-term tuning. Even though the 4 levels, your policy is very readable thanks to comments and good names. Nice example. > > My mistake was to chain refine on such different set of routes, I mean the > cartisian product will end up considering only the common set for each > refine (left or right) handside, narrowing down to the sparse set of > routes of AS786 and AS5401. > That is correct. > Would it be wise/wrong/discouraged/ugly/convoluted to use a: > > from AS-ANY > accept ANY > > statement at the end of statement 3 and 4, the one not focusing on > all routes, and let the order precedence rule do the rest? > I'm not sure of the resulting cartisian product of hum, such a mess :) > Yes, you need this. The resulting cartasian product may have some extra stuff, but that is OK. > an other good solution is to use one import per route-type, ie having 3 > import in this case, one for upstream, one for peer, one for customer. > hence the peering set in rightmost refine will always be contained in > the leftmost statement, but the route pollution preventing need to be > duplicated. I can live with this redudancy, but would like some feedback > to 'feel' better the refine operator. > I think the first solution is cleaner. > some comment about the RFC: > the 'nested' word may be somewhat confusing for the refine statement. > chained would be better IMHO. > > I'm sure there is a good reason for evaluating nested or chained statement > for both except and refine from right to left, but no insight is given. > I missed that one at first. > > Otherwise, I'm impressed by the fine granularity of RPSL. will like to > see the world switching to it :) > I have included this in my todo list. When we next revisit the RFC, I will make these clarifications. Thank you. > > Regards. > > -- > Philippe Strauss, Telecom Consulting > email: > > Psychiatrists say that one out of four people are mentally ill. Check > three friends. If they're OK, you're it. > -- > Cengiz -- Cengiz Alaettinoglu Packet Design Inc.