From Daniel.Karrenberg at ripe.net Wed Mar 1 09:37:10 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 01 Mar 1995 09:37:10 +0100 Subject: Routing Policy System Working Group In-Reply-To: Your message of Tue, 28 Feb 1995 13:53:55 PST. <199502282153.AA27139@cat.isi.edu> Message-ID: <9503010837.AA14327@ncc.ripe.net> > cengiz at ISI.EDU (Cengiz Alaettinoglu) writes: > > > Daniel Karrenberg (Daniel.Karrenberg at ripe.net) on February 28: > > > and RIPE pride tools will be upgraded to support RPSL > > > as an initial set of tools. > > out of scope! I mean that the WG as such is not going to write or modify any code. So this does not belong in the charter. What do you wnat the WG to do in this area? > Do you mean that the generating tools is out of scope, or upgrading > pride tools? Both. > Even if we do not build tools as a part of the wg effort, we should > still discuss what tools will be of use to the community and try to > come up with definitions for them so that anyone can implement. That would be within scope of a WG charter. It should certainly be discussed with the AD. > the database model will be based on the RIPE registry; the regsistry model will be based on the RIPE database. [sorry to be nit-picking ;-)] Daniel -------- Logged at Wed Mar 1 09:46:48 MET 1995 --------- From Daniel.Karrenberg at ripe.net Wed Mar 1 09:46:46 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 01 Mar 1995 09:46:46 +0100 Subject: Special ftp access for IRR? In-Reply-To: Your message of Tue, 28 Feb 1995 11:07:04 PST. <199502281907.AA26912@cat.isi.edu> Message-ID: <9503010846.AA14385@ncc.ripe.net> > cengiz at ISI.EDU (Cengiz Alaettinoglu) writes: > > bmanning at isi.edu (bmanning at isi.edu) on February 28: > > > > The point being that folks can and will register in multiple .db's. This > > seems to indicate that a bit more thought will need to be expended on the > > first steps as indicated above. > > > > --bill > > I think this is orthogonal to what daniel suggests. I.e. one can still > register AS1 in ripe.db and radb.db in Daniel's model. Exactly. From the source: attribute the server can determine wheter it is the master server for the registry concerned. If it is, it processes the request; if not it forwards it to the right master server. > However, if > radb gets a request from AS1 to update the copy in ripe.db, it should > 1) forward it to ripe for processing > 2) return the user a message to submit the request to ripe. > > I think we should do 2. Why this? I am curious! I strongly suggest we should do 1 as it does what the user intended. It also saves a lot of support calls. We can optionally notify the user of the forwarding action. Daniel -------- Logged at Wed Mar 1 09:48:21 MET 1995 --------- From Daniel.Karrenberg at ripe.net Wed Mar 1 09:48:19 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 01 Mar 1995 09:48:19 +0100 Subject: Special ftp access for IRR? In-Reply-To: Your message of Tue, 28 Feb 1995 11:02:21 PST. <199502281902.AA26904@cat.isi.edu> Message-ID: <9503010848.AA14420@ncc.ripe.net> > cengiz at ISI.EDU (Cengiz Alaettinoglu) writes: > We also aggreed to keep a file which includes the diffs up to the > current time. So if one wants a copy of the ripe database as current > as possible, he would get this diff. Yep! That's what I meant to say, but didn't. Daniel -------- Logged at Thu Mar 2 02:37:00 MET 1995 --------- From cengiz at ISI.EDU Thu Mar 2 02:36:34 1995 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Wed, 1 Mar 1995 17:36:34 -0800 Subject: Routing Policy System Working Group In-Reply-To: <9503010837.AA14327@ncc.ripe.net> References: <199502282153.AA27139@cat.isi.edu> <9503010837.AA14327@ncc.ripe.net> Message-ID: <199503020136.AA01758@cat.isi.edu> Daniel Karrenberg (Daniel.Karrenberg at ripe.net) on March 1: > > Even if we do not build tools as a part of the wg effort, we should > > still discuss what tools will be of use to the community and try to > > come up with definitions for them so that anyone can implement. > > That would be within scope of a WG charter. It should certainly be discussed > with the AD. I will change the charter to reflect this. > [sorry to be nit-picking ;-)] It has been useful and appreciated. Thank you. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California -------- Logged at Thu Mar 2 02:41:26 MET 1995 --------- From cengiz at ISI.EDU Thu Mar 2 02:41:01 1995 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Wed, 1 Mar 1995 17:41:01 -0800 Subject: Special ftp access for IRR? In-Reply-To: <9503010846.AA14385@ncc.ripe.net> References: <199502281907.AA26912@cat.isi.edu> <9503010846.AA14385@ncc.ripe.net> Message-ID: <199503020141.AA01775@cat.isi.edu> Daniel Karrenberg (Daniel.Karrenberg at ripe.net) on March 1: > > However, if > > radb gets a request from AS1 to update the copy in ripe.db, it should > > 1) forward it to ripe for processing > > 2) return the user a message to submit the request to ripe. > > > > I think we should do 2. > > Why this? I am curious! I think AS1 made a mistake and there is no easy way to guess AS1's intentions, other than to ask AS1. That is it may be the case that the source line was the mistake as opposed to the registry to which the update was sent. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California -------- Logged at Thu Mar 2 02:54:24 MET 1995 --------- From cengiz at ISI.EDU Thu Mar 2 02:53:50 1995 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Wed, 1 Mar 1995 17:53:50 -0800 Subject: Routing Policy System Working Group In-Reply-To: <199503020136.AA01758@cat.isi.edu> References: <199502282153.AA27139@cat.isi.edu> <9503010837.AA14327@ncc.ripe.net> <199503020136.AA01758@cat.isi.edu> Message-ID: <199503020153.AA01832@cat.isi.edu> This is the final charter that I will mail to Megan tomorrow. Last chance to make comments. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California Charter: The Routing Policy System Working Group will (1) define a language, referred to as Routing Policy Specification Language (RPSL), for describing routing policy constraints; (2) define a simple and robust distributed registry model for publishing routing policy constraints; and (3) define a set of tools for analysing registered policy constraints, for checking global consistency, for generating router configurations, and for diagnosing operational routing problems. It is expected that RPSL will enter the standards track. The RPSL will be routing protocol independent as well as router configuration format independent to support various routing protocols such as BGP, IDRP, SDRP, and various router technologies. The RPSL will be backward compatible with RIPE-181 whenever possible; the registry model will be based on the RIPE database. The working group will also instigate, review, or (if appropriate) produce additional RFCs to support other protocols such as multicasting and resource reservation. Goals and Milestones: Apr 95: BOF to discuss scope of work and WG creation Jun 95: Publish initial draft specification of RPSL Jul 95: Publish draft specification of tools and the database model Jul 95: First WG meeting Aug 95: Publish second draft specifications Begin collecting implementation experience for Standards track RFCs Dec 95: Second WG meeting Publish RPSL and Experiences RFC Jan 96: Submit RFCs for proposed standard Administrative Structure: Chair(s): Cengiz Alaettinoglu Another co-chair TBA Document Editor(s): Cengiz Alaettinoglu Internet Area Director(s) Mike O'Dell Area Advisor Mike O'Dell Mailing lists: General Discussion: rps at isi.edu To Subscribe: rps-request at isi.edu Archive: ftp.isi.edu:/pub/rps -------- Logged at Thu Mar 2 10:00:42 MET 1995 --------- From Daniel.Karrenberg at ripe.net Thu Mar 2 10:00:40 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 02 Mar 1995 10:00:40 +0100 Subject: request forwarding, was: Special ftp access for IRR? In-Reply-To: Your message of Wed, 01 Mar 1995 17:41:01 PST. <199503020141.AA01775@cat.isi.edu> Message-ID: <9503020900.AA23774@ncc.ripe.net> > cengiz at ISI.EDU (Cengiz Alaettinoglu) writes: > > Daniel Karrenberg (Daniel.Karrenberg at ripe.net) on March 1: > > > However, if > > > radb gets a request from AS1 to update the copy in ripe.db, it should > > > 1) forward it to ripe for processing > > > 2) return the user a message to submit the request to ripe. > > > > > > I think we should do 2. > > > > Why this? I am curious! > > I think AS1 made a mistake and there is no easy way to guess AS1's > intentions, other than to ask AS1. That is it may be the case that the > source line was the mistake as opposed to the registry to which the > update was sent. My argument is that the object itself is more likely to represent the intention than the address it is sent to. After years we still get people sending requests intended to the automatic mailbox to the manual one. Taking both into account I think the right thing is "forward with notification". Daniel -------- Logged at Thu Mar 2 15:43:24 MET 1995 --------- From dsj at merit.edu Thu Mar 2 15:43:00 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Thu, 2 Mar 1995 09:43:00 -0500 Subject: request forwarding, was: Special ftp access for IRR? Message-ID: <199503021443.JAA25196@home.merit.edu> Daniel, > From dfk at ripe.net Thu Mar 2 04:01:21 1995 > To: cengiz at isi.edu (Cengiz Alaettinoglu) > Cc: bmanning at isi.edu, rr-impl at ripe.net > Subject: request forwarding, was: Special ftp access for IRR? > Date: Thu, 02 Mar 1995 10:00:40 +0100 > > > > cengiz at ISI.EDU (Cengiz Alaettinoglu) writes: > > > > Daniel Karrenberg (Daniel.Karrenberg at ripe.net) on March 1: > > > > However, if > > > > radb gets a request from AS1 to update the copy in ripe.db, it should > > > > 1) forward it to ripe for processing > > > > 2) return the user a message to submit the request to ripe. > > > > > > > > I think we should do 2. > > > > > > Why this? I am curious! > > > > I think AS1 made a mistake and there is no easy way to guess AS1's > > intentions, other than to ask AS1. That is it may be the case that the > > source line was the mistake as opposed to the registry to which the > > update was sent. > > My argument is that the object itself is more likely to represent > the intention than the address it is sent to. After years we still get > people sending requests intended to the automatic mailbox to the manual > one. > > Taking both into account I think the right thing is "forward > with notification". On the other hand, if you had chosen "reject with instructions for submitting it correctly" you probably wouldn't be getting requests intended to the automatic mailbox sent to the manual one even after years have passed. I don't have a strong opinion on which we choose for the IRR (it isn't even obvious that the different registries need to do this the same), but we have had good success with few gripes by using the stronger method when we reject NACRs. --Dale -------- Logged at Thu Mar 2 16:19:55 MET 1995 --------- From enke at mci.net Thu Mar 2 16:19:45 1995 From: enke at mci.net (Enke Chen) Date: Thu, 02 Mar 1995 10:19:45 -0500 Subject: Routing Policy System Working Group In-Reply-To: Your message of "Wed, 01 Mar 1995 17:53:50 PST." <199503020153.AA01832@cat.isi.edu> Message-ID: <199503021519.KAA28496@ns.mci.net> Cengiz: I would like to suggest that some text be added to clarify the focus of the working group -- inter-domain routing. This should not exclude the possiblity of touch general intra-domain issues. For example, I am thinking of a static-route-object to better handle the increasing number of customers that need static configuration. -- Enke > Date: Wed, 1 Mar 1995 17:53:50 -0800 > From: cengiz at ISI.EDU (Cengiz Alaettinoglu) > To: cengiz at ISI.EDU (Cengiz Alaettinoglu) > CC: Daniel Karrenberg , rr-impl at ripe.net > > This is the final charter that I will mail to Megan tomorrow. Last > chance to make comments. > > Cengiz > > -- > Cengiz Alaettinoglu Information Sciences Institute > (310) 822-1511 University of Southern California > Charter: > > The Routing Policy System Working Group will (1) define a language, > referred to as Routing Policy Specification Language (RPSL), for > describing routing policy constraints; (2) define a simple and robust > distributed registry model for publishing routing policy constraints; and > (3) define a set of tools for analysing registered policy constraints, fo r > checking global consistency, for generating router configurations, and fo r > diagnosing operational routing problems. It is expected that RPSL will > enter the standards track. > > The RPSL will be routing protocol independent as well as router > configuration format independent to support various routing protocols suc h > as BGP, IDRP, SDRP, and various router technologies. The RPSL will be > backward compatible with RIPE-181 whenever possible; the registry model > will be based on the RIPE database. > > The working group will also instigate, review, or (if appropriate) produc e > additional RFCs to support other protocols such as multicasting and > resource reservation. > > Goals and Milestones: > > Apr 95: BOF to discuss scope of work and WG creation > > Jun 95: Publish initial draft specification of RPSL > > Jul 95: Publish draft specification of tools and the database model > > Jul 95: First WG meeting > > Aug 95: Publish second draft specifications > Begin collecting implementation experience for Standards track R FCs > > Dec 95: Second WG meeting > Publish RPSL and Experiences RFC > > Jan 96: Submit RFCs for proposed standard > > Administrative Structure: > > Chair(s): > Cengiz Alaettinoglu > Another co-chair TBA > > Document Editor(s): > Cengiz Alaettinoglu > > Internet Area Director(s) > Mike O'Dell > > Area Advisor > Mike O'Dell > > Mailing lists: > General Discussion: rps at isi.edu > To Subscribe: rps-request at isi.edu > Archive: ftp.isi.edu:/pub/rps -------- Logged at Thu Mar 2 16:24:07 MET 1995 --------- From lpj at merit.edu Thu Mar 2 16:23:27 1995 From: lpj at merit.edu (Laurent Joncheray) Date: Thu, 2 Mar 1995 10:23:27 -0500 (EST) Subject: Databases Synchronization Proposal Message-ID: <199503021523.KAA27308@home.merit.edu> FYI ------------------------------------------------------------------------------- Proposal for a Simple Database Synchronization Model lpj. 03-02-95. Version 0.1 Object of this memo. Dissemination of the same data among Routing Registries Databases has raised the problem of the distribution and synchronization of the data in the different registries. Either Inter Registry propagation or intra registries copy (for backup purpose) is still an open problem. Right now synchronization of databases is done by daily FTP transfer of the whole database between registries. Database are synchronized only once a day (Desynchronization Delay of less than 24 hours). The current implementation of the Routing Registries Databases is based on e-mail updates ('RIPE database model') sent to one registry. The present proposal describes a way to synchronize databases based on mail forwarding aimed to keep the desynchronization delay less than a few minutes. Model In the current scheme the user mails an update to the registry (the registry is known by its e-mail address). The mail is processed, a report is sent back to the user and eventually the data is registered into the database. (user) -- [e-mail] --> {Registry A Incoming Processing :: Database} <-- [Report] -- | FTP | V {Registry B :: Database} Within the proposed model the incoming Processing entity will forward a copy of the mail to the registry B's incoming Processing entity. In order to prevent a new report to be sent to the user by the registry B's process, the sender of the mail will be set to a special generic address ("dbadmin at Registry_A") which will be recognized by the registry B and won't generate a report to the sender. (user) -- [e-mail] --> {Registry A Incoming Processing :: Database} <-- [Report] -- | [e-mail/from = dbadmin at Registry_A] | V {Registry B Incoming Processing :: Database} The desynchronization delay is set to the mail forwarding time (less than a few minutes). The model is perfectly symmetric: the user can send the request to the registry B which will forward it to the registry A. (user) -- [e-mail] --> {Registry A Incoming Processing :: Database} <-- [Report] -- ^ | | [e-mail/from = dbadmin at Registry_A/B] | | V <-- [Report] -- (user) -- [e-mail] --> {Registry B Incoming Processing :: Database} Protocol Every registry keeps a list of neighbor registries to which forward a copy of every incoming mail. When receiving a mail the process checks if the sender is one of his neighbor registries. If so the report generation is turn off (this can be implemented by replacing the from address by /dev/null before passing the mail to the database processor -- dbupdate). The process creates a new header field which will contains all the registries name through where the mail was forwarded. The filed will look like: X-dbpath: dbadmin at Registry_A If this field already exists the process just adds its name to the list: X-dbpath: dbadmin at Registry_A, dbadmin at Registry_B The process forwards a copy of the mail to all neighbor registries which are not listed in the 'X-dbpath' field. By doing that the process prevents any loop in the registries configuration. The process also replaces the from/reply-to address by its own. Another email header field can be added too: if the X-dbtrace field exist then a report is sent to the user listed in the 'reply-to' field. This allow debugging of the path followed by a given mail by analyzing the from line and X-dbpath line of all report sent by the registries receiving the mail. It also gives the user a map off the topology of the registries. The model supposes that the database updates are time stamped and the database administrator can discart any out of date (older than the current last update time) request. Discussion If one of the registry is down, e-mail to that registry will be queued and resent when the registry is up again. This mechanism is inherent the the e-mail service. The dead registry will be resynchronized when coming up again. Loop are detected with the use of the X-dbpath field. User can send email to any registry with the assurance all registries will get updated. In case of intra registry backups (2 or more databases running for the same registry), the use of several MX record allows the administrator to split the load of the incoming mail between the databases backups. Moreover if one host is down the mailer can choose to send the mail to an alternative MX server. The model is completely symmetric, no database is privileged. A FTP transfer of the databases between registry once a week is still a safe way to resynchronize the databases in case of failure of the mail forwarding. During the FTP transfer e-mail update should be disabled. The present model does not deal with database queries (whois requests). -- Laurent Joncheray, E-Mail: lpj at merit.edu Merit Network Inc, 4251 Plymouth Rd, Suite C, Phone: +1 (313) 936 2065 Ann Arbor, MI 48105, USA Fax: +1 (313) 747 3185 "This is the end, Beautiful friend. This is the end, My only friend, the end" JM -------- Logged at Thu Mar 2 19:48:32 MET 1995 --------- From cengiz at ISI.EDU Thu Mar 2 19:48:09 1995 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Thu, 2 Mar 1995 10:48:09 -0800 Subject: Routing Policy System Working Group In-Reply-To: <199503021833.NAA07062@ns.mci.net> References: <199503021816.AA03761@cat.isi.edu> <199503021833.NAA07062@ns.mci.net> Message-ID: <199503021848.AA03906@cat.isi.edu> I have changed last paragraph to: The working group will focus on inter-domain routing protocols, but will also instigate, review, or (if appropriate) produce additional RFCs to support other protocols such as multicasting and resource reservation. I did not make interaction with intra-domain routing explicit because I think it is clear that interaction is included (e.g. the route objects). What do you think? Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California -------- Logged at Thu Mar 2 20:03:09 MET 1995 --------- From enke at mci.net Thu Mar 2 20:03:02 1995 From: enke at mci.net (Enke Chen) Date: Thu, 02 Mar 1995 14:03:02 -0500 Subject: Routing Policy System Working Group In-Reply-To: Your message of "Thu, 02 Mar 1995 10:48:09 PST." <199503021848.AA03906@cat.isi.edu> Message-ID: <199503021903.OAA08450@ns.mci.net> Cengiz: it is fine. -- Enke > Date: Thu, 2 Mar 1995 10:48:09 -0800 > From: cengiz at ISI.EDU (Cengiz Alaettinoglu) > To: Enke Chen > CC: rr-impl at ripe.net > > I have changed last paragraph to: > > The working group will focus on inter-domain routing protocols, > but will also instigate, review, or (if appropriate) produce > additional RFCs to support other protocols such as multicasting and > resource reservation. > > > I did not make interaction with intra-domain routing explicit because > I think it is clear that interaction is included (e.g. the route > objects). > > What do you think? > > Cengiz > > -- > Cengiz Alaettinoglu Information Sciences Institute > (310) 822-1511 University of Southern California -------- Logged at Fri Mar 3 14:11:51 MET 1995 --------- From GeertJan.deGroot at ripe.net Fri Mar 3 14:10:26 1995 From: GeertJan.deGroot at ripe.net (Geert Jan de Groot) Date: Fri, 03 Mar 1995 14:10:26 +0100 Subject: Databases Synchronization Proposal In-Reply-To: Your message of "Thu, 02 Mar 1995 10:23:27 EST." <199503021523.KAA27308@home.merit.edu> Message-ID: <9503031310.AA05938@ncc.ripe.net> On Thu, 2 Mar 1995 10:23:27 -0500 (EST) Laurent Joncheray wrote: > Within the proposed model the incoming Processing entity will > forward a copy of the mail to the registry B's incoming Processing > entity. In order to prevent a new report to be sent to the user by the > registry B's process, the sender of the mail will be set to a special > generic address ("dbadmin at Registry_A") which will be recognized by the > registry B and won't generate a report to the sender. [Left out the rest of the proposal for brevity] Laurent, I have been thinking on similar lines too. There is one catch, which you might want to include in your proposal. There is semantic information in the order in which updates are processed. Assume the following scenario: 1. Someone registers a Bananna object (note typo) 2. The database includes & sends ack 3. The person finds the typo 4. The person deletes Bananna 5. The person registers Banana (no typo). If these updates are also sent to a shadow copy, then one must make shure that (1) comes before (4), otherwise the delete won't work and Bananna will still be in (the databases will be out of sync) For this reason, I think that each update should have a serial number attached to it, to be issued by the primary database (yes, this smells like DNS..). The secondary should not process update 4 if it hasn't done update 3. Full database copies should maybe carry the same serial number as the last update. For database version 100, all updates with serial <= 100 can be deleted because they are already included. I can think of 2 situations that need special attention: 1. The secondary becomes temporary disconnected (network outage). In this case, newer updates (send after the network is restored) will arrive before the older ones arrive (which are queued for the next sendmail queue run). The secondary will synchonize as soon as the older updates are in. 2. An update message is lost (forever). In this case, the secondary will never catch up. One can think of making some alarm bells that ring if the serial number difference between updates and the secondary gets over a certain threshold. In this scheme, this would be the only time that one would need to install a full newer copy of the database. Given the reliability of email, I think this will not happen except under extreme circumstances. I think we should try this before people start investing effort in more elaborate schemes. On the scaling issue, I think that having 10 a 20 routing registries will certainly work with this scheme (compare with mailing lists with 100s of subscribers). If things really get out of hand, then one might think of using some reliable multicasting scheme, like Van Jacobsen's WB has. Just my 'stuiver' worth.. (we don't have cents in the Netherlands anymore ;-) Geert Jan -------- Logged at Fri Mar 3 14:38:48 MET 1995 --------- From Daniel.Karrenberg at ripe.net Fri Mar 3 14:36:54 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 03 Mar 1995 14:36:54 +0100 Subject: Databases Synchronization Proposal In-Reply-To: Your message of Fri, 03 Mar 1995 14:10:26 MET. <9503031310.AA05938@ncc.ripe.net> Message-ID: <9503031336.AA06312@ncc.ripe.net> > Geert Jan de Groot writes: > 2. An update message is lost (forever). > In this case, the secondary will never catch up. One can think of > making some alarm bells that ring if the serial number difference > between updates and the secondary gets over a certain threshold. > In this scheme, this would be the only time that one would need to > install a full newer copy of the database. > Given the reliability of email, I think this will not happen > except under extreme circumstances. If you have the ftp-able files you can even automaticlly fix it at any granularity you want. That is the idea behind them. > If things really get out of hand, then > one might think of using some reliable multicasting scheme, like > Van Jacobsen's WB has. Now *that* is an idea! -------- Logged at Fri Mar 3 15:08:13 MET 1995 --------- From lpj at merit.edu Fri Mar 3 15:08:08 1995 From: lpj at merit.edu (Laurent Joncheray) Date: Fri, 3 Mar 1995 09:08:08 -0500 (EST) Subject: Databases Synchronization Proposal In-Reply-To: <9503031310.AA05938@ncc.ripe.net> from "Geert Jan de Groot" at Mar 3, 95 02:10:26 pm Message-ID: <199503031408.JAA04667@home.merit.edu> > There is semantic information in the order in which updates are processed. > Assume the following scenario: > 1. Someone registers a Bananna object (note typo) > 2. The database includes & sends ack > 3. The person finds the typo > 4. The person deletes Bananna > 5. The person registers Banana (no typo). > > If these updates are also sent to a shadow copy, then one must make > shure that (1) comes before (4), otherwise the delete won't work > and Bananna will still be in (the databases will be out of sync) I don't get it. If the update is time stamped (as specified in my prososal) with 1 second resolution, then ordering of the update is trivial. If (1) come after (4) then it'll be rejected because it's older. As for the lost mail and desynchronisation problem, the FTP once in the while should solve the problem (as pointed out by Daniel). Laurent -- Laurent Joncheray, E-Mail: lpj at merit.edu Merit Network Inc, 4251 Plymouth Rd, Suite C, Phone: +1 (313) 936 2065 Ann Arbor, MI 48105, USA Fax: +1 (313) 747 3185 "This is the end, Beautiful friend. This is the end, My only friend, the end" JM -------- Logged at Fri Mar 3 16:34:23 MET 1995 --------- From ripe-dbm at ripe.net Fri Mar 3 16:34:20 1995 From: ripe-dbm at ripe.net (RIPE Database Manager) Date: Fri, 03 Mar 1995 16:34:20 +0100 Subject: Databases Synchronization Proposal Message-ID: <9503031534.AA07435@ncc.ripe.net> Dear Laurent, > > There is semantic information in the order in which updates are processed. > > Assume the following scenario: > > 1. Someone registers a Bananna object (note typo) > > 2. The database includes & sends ack > > 3. The person finds the typo > > 4. The person deletes Bananna > > 5. The person registers Banana (no typo). > > > > If these updates are also sent to a shadow copy, then one must make > > shure that (1) comes before (4), otherwise the delete won't work > > and Bananna will still be in (the databases will be out of sync) > > I don't get it. If the update is time stamped (as specified in my > prososal) with 1 second resolution, then ordering of the update is > trivial. If (1) come after (4) then it'll be rejected because it's older. > > As for the lost mail and desynchronisation problem, the FTP > once in the while should solve the problem (as pointed out by Daniel). But what happens if you don't receive 5 or 1 ? Time stamps are not unique. Why not use a unique serial number ? That means you can track down when you missed any E-mails. As Geert Jan explained it is vital to do the updates in the right order. You can't check this with a time stamp since you don't know if you missed any E-mail. Kind regards, David Kessens RIPE NCC Database maintainer -------- Logged at Fri Mar 3 16:39:05 MET 1995 --------- From ripe-dbm at ripe.net Fri Mar 3 16:34:20 1995 From: ripe-dbm at ripe.net (RIPE Database Manager) Date: Fri, 03 Mar 1995 16:34:20 +0100 Subject: Databases Synchronization Proposal Message-ID: <9503031534.AA07435@ncc.ripe.net> Dear Laurent, > > There is semantic information in the order in which updates are processed. > > Assume the following scenario: > > 1. Someone registers a Bananna object (note typo) > > 2. The database includes & sends ack > > 3. The person finds the typo > > 4. The person deletes Bananna > > 5. The person registers Banana (no typo). > > > > If these updates are also sent to a shadow copy, then one must make > > shure that (1) comes before (4), otherwise the delete won't work > > and Bananna will still be in (the databases will be out of sync) > > I don't get it. If the update is time stamped (as specified in my > prososal) with 1 second resolution, then ordering of the update is > trivial. If (1) come after (4) then it'll be rejected because it's older. > > As for the lost mail and desynchronisation problem, the FTP > once in the while should solve the problem (as pointed out by Daniel). But what happens if you don't receive 5 or 1 ? Time stamps are not unique. Why not use a unique serial number ? That means you can track down when you missed any E-mails. As Geert Jan explained it is vital to do the updates in the right order. You can't check this with a time stamp since you don't know if you missed any E-mail. Kind regards, David Kessens RIPE NCC Database maintainer -------- Logged at Fri Mar 3 21:34:27 MET 1995 --------- From cengiz at ISI.EDU Fri Mar 3 21:34:03 1995 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Fri, 3 Mar 1995 12:34:03 -0800 Subject: Databases Synchronization Proposal In-Reply-To: <199503021523.KAA27308@home.merit.edu> References: <199503021523.KAA27308@home.merit.edu> Message-ID: <199503032034.AA08271@cat.isi.edu> Laurant, We discussed several methods to syncronise registries in the IRR meeting in San Jose. We have talked about daily ftp's, true syncronisation via atomic updates, maintaining diff like files as explained last week by Daniel. I am glad that someone take this one step further and looked at the issues in detail. However, there are couple of important issues that were missing in your proposal. I think the most important issue is guaranteed syncronisation at a certain time. When you ftp the copy of x.db created at 8am from the master registry for x.db, you know that the copy of the x.db is as recent as 8am this morning. With the diffs, one can guarantee syncronisation upto the time of last diff in the ftp. I think having a guaranteed time on the syncronisation is very important. For example, RA configures route servers using the information received untill 2pm the previous day. With the diffs, one can syncronise all databases to 2pm, previous day. With what you suggest, no such guarantees are possible (or I missed it:-). In other words how can I get a copy of ripe database at 2pm yesterday even if the ripe database have not received all updates till 2pm yesterday because they were sent to all sorts of registries all around the world. On another point, you suggest that once a week whole ftp copies of the databases can be made to guarantee robustness for syncronisation. Where do I get a copy of ripe.db? Ripe? In your scheme they themselves do not have the most up to date data. The most up to data data is in all registries plus mail queues in all sorts of places, plus mail messages in transit between the registries. To clarify here is an example: 7:50 am RA receives add object banana to ripe database 7:51 RA adds the object and forwards it to ripe, network is down and the message is queued. 8:00 am RA ftp's ripe's copy of ripe.db. 8:05 Ripe receives mail from RA and adds object banana Are the databases syncronised? No. RA's copy of the ripe.db is missing the object banana. Also RA can not tell this, as perhaps object banana was actually deleted by sending a delete request to the registry foo. Do you want to keep track of all these transactions? That is not a simple job and perhaps two phase commit and true syncronisation is simpler. I think having a master registry is a good idea. A record should not be registered anywhere if it is not registered at the master registery. I think master registry should issue both serial numbers and time stamps. That is records of the sort: database serial-number timestamp operation object These records can be stored for future ftp as diffs or sent around via email (or both). Different registries can choose different options as well. But I think, one needs diffs and a concept of master registries to guarantee syncronisation. My 1000 Turkish Liras:-) which is only 2 cents:-( Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California -------- Logged at Fri Mar 3 22:27:44 MET 1995 --------- From GeertJan.deGroot at ripe.net Fri Mar 3 22:26:32 1995 From: GeertJan.deGroot at ripe.net (Geert Jan de Groot) Date: Fri, 03 Mar 1995 22:26:32 +0100 Subject: Databases Synchronization Proposal In-Reply-To: Your message of "Fri, 03 Mar 1995 09:08:08 EST." <199503031408.JAA04667@home.merit.edu> Message-ID: <9503032126.AA01372@ncc.ripe.net> On Fri, 3 Mar 1995 09:08:08 -0500 (EST) Laurent Joncheray wrote: > > There is semantic information in the order in which updates are processed. > > Assume the following scenario: > > 1. Someone registers a Bananna object (note typo) > > 2. The database includes & sends ack > > 3. The person finds the typo > > 4. The person deletes Bananna > > 5. The person registers Banana (no typo). > > > > If these updates are also sent to a shadow copy, then one must make > > shure that (1) comes before (4), otherwise the delete won't work > > and Bananna will still be in (the databases will be out of sync) > > I don't get it. If the update is time stamped (as specified in my > prososal) with 1 second resolution, then ordering of the update is > trivial. If (1) come after (4) then it'll be rejected because it's older. I am afraid there is a miscommunication here. if (4) arrives first, then the delete fails because the original object (1) hasn't arrived yet. Updates would silently fail as no acks are sent. If (1) arrives after this, then it will be added to the database, and it will stay there in the example. The primary doesn't have Bananna anymore, but the secondary has. By tweaking your ideas a bit as I suggested,, I think we can make things work in such a way that frequent full database transfers will not be needed at all, as long as no update is lost. Geert Jan (Dale: will make your changes tonight/tomorrow. Last train home & snow forces me to go _now_...) -------- Logged at Sun Mar 5 23:16:08 MET 1995 --------- From cengiz at ISI.EDU Sun Mar 5 23:15:31 1995 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Sun, 5 Mar 1995 14:15:31 -0800 Subject: AS path extensions Message-ID: <199503052215.AA16699@cat.isi.edu> Hi, Here is the latest document on this extension. Comments are welcome. Thanks. I do not remember if I have already sent this. I am sorry if I did so. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California %!PS-Adobe-2.0 %%Creator: dvips 5.47 Copyright 1986-91 Radical Eye Software %%Title: extensions.dvi %%Pages: 4 1 %%BoundingBox: 0 0 612 792 %%EndComments %%BeginProcSet: tex.pro /TeXDict 200 dict def TeXDict begin /N /def load def /B{bind def}N /S /exch load def /X{S N}B /TR /translate load N /isls false N /vsize 10 N /@rigin{ isls{[0 1 -1 0 0 0]concat}if 72 Resolution div 72 VResolution div neg scale Resolution VResolution vsize neg mul TR matrix currentmatrix dup dup 4 get round 4 exch put dup dup 5 get round 5 exch put setmatrix}N /@letter{/vsize 10 N}B /@landscape{/isls true N /vsize -1 N}B /@a4{/vsize 10.6929133858 N}B /@a3{ /vsize 15.5531 N}B /@ledger{/vsize 16 N}B /@legal{/vsize 13 N}B /@manualfeed{ statusdict /manualfeed true put}B /@copies{/#copies X}B /FMat[1 0 0 -1 0 0]N /FBB[0 0 0 0]N /nn 0 N /IE 0 N /ctr 0 N /df-tail{/nn 8 dict N nn begin /FontType 3 N /FontMatrix fntrx N /FontBBox FBB N string /base X array /BitMaps X /BuildChar{CharBuilder}N /Encoding IE N end dup{/foo setfont}2 array copy cvx N load 0 nn put /ctr 0 N[}B /df{/sf 1 N /fntrx FMat N df-tail} B /dfs{div /sf X /fntrx[sf 0 0 sf neg 0 0]N df-tail}B /E{pop nn dup definefont setfont}B /ch-width{ch-data dup length 5 sub get}B /ch-height{ch-data dup length 4 sub get}B /ch-xoff{128 ch-data dup length 3 sub get sub}B /ch-yoff{ ch-data dup length 2 sub get 127 sub}B /ch-dx{ch-data dup length 1 sub get}B /ch-image{ch-data dup type /stringtype ne{ctr get /ctr ctr 1 add N}if}B /id 0 N /rw 0 N /rc 0 N /gp 0 N /cp 0 N /G 0 N /sf 0 N /CharBuilder{save 3 1 roll S dup /base get 2 index get S /BitMaps get S get /ch-data X pop /ctr 0 N ch-dx 0 ch-xoff ch-yoff ch-height sub ch-xoff ch-width add ch-yoff setcachedevice ch-width ch-height true[1 0 0 -1 -.1 ch-xoff sub ch-yoff .1 add]{ch-image} imagemask restore}B /D{/cc X dup type /stringtype ne{]}if nn /base get cc ctr put nn /BitMaps get S ctr S sf 1 ne{dup dup length 1 sub dup 2 index S get sf div put}if put /ctr ctr 1 add N}B /I{cc 1 add D}B /bop{userdict /bop-hook known{bop-hook}if /SI save N @rigin 0 0 moveto}N /eop{clear SI restore showpage userdict /eop-hook known{eop-hook}if}N /@start{userdict /start-hook known{start-hook}if /VResolution X /Resolution X 1000 div /DVImag X /IE 256 array N 0 1 255{IE S 1 string dup 0 3 index put cvn put}for}N /p /show load N /RMat[1 0 0 -1 0 0]N /BDot 260 string N /rulex 0 N /ruley 0 N /v{/ruley X /rulex X V}B /V statusdict begin /product where{pop product dup length 7 ge{0 7 getinterval(Display)eq}{pop false}ifelse}{false}ifelse end{{gsave TR -.1 -.1 TR 1 1 scale rulex ruley false RMat{BDot}imagemask grestore}}{{gsave TR -.1 -.1 TR rulex ruley scale 1 1 false RMat{BDot}imagemask grestore}}ifelse B /a{ moveto}B /delta 0 N /tail{dup /delta X 0 rmoveto}B /M{S p delta add tail}B /b{ S p tail}B /c{-4 M}B /d{-3 M}B /e{-2 M}B /f{-1 M}B /g{0 M}B /h{1 M}B /i{2 M}B /j{3 M}B /k{4 M}B /w{0 rmoveto}B /l{p -4 w}B /m{p -3 w}B /n{p -2 w}B /o{p -1 w }B /q{p 1 w}B /r{p 2 w}B /s{p 3 w}B /t{p 4 w}B /x{0 S rmoveto}B /y{3 2 roll p a}B /bos{/SS save N}B /eos{clear SS restore}B end %%EndProcSet TeXDict begin 1000 300 300 @start /Fa 5 117 df<3078F06005047C830D>46 D<03CC063C0C3C181C3838303870387038E070E070E070E070E0E2C0E2C0E261E462643C380F12 7B9115>97 D<01E007100C1018083810701070607F80E000E000E000E000E000E0086010602030 C01F000D127B9113>101 D<1F800380038007000700070007000E000E000E000E001C001C001C 001C0038003800380038007000700070007000E400E400E400E40068003800091D7C9C0B>108 D<00C001C001C001C00380038003800380FFE00700070007000E000E000E000E001C001C001C00 1C00384038403840388019000E000B1A7D990E>116 D E /Fb 56 122 df<0040008001000200 06000C000C0018001800300030007000600060006000E000E000E000E000E000E000E000E000E0 00E000E000E000600060006000700030003000180018000C000C00060002000100008000400A2A 7D9E10>40 D<800040002000100018000C000C000600060003000300038001800180018001C001 C001C001C001C001C001C001C001C001C001C001C0018001800180038003000300060006000C00 0C00180010002000400080000A2A7E9E10>I<60F0F0701010101020204080040C7C830C>44 DI<60F0F06004047C830C>I<03C00C301818300C300C700E60066006E0 07E007E007E007E007E007E007E007E007E007E007E007E00760066006700E300C300C18180C30 07E0101D7E9B15>48 D<030007003F00C700070007000700070007000700070007000700070007 00070007000700070007000700070007000700070007000F80FFF80D1C7C9B15>I<07C0183020 1C400C400EF00FF80FF807F8077007000F000E000E001C001C00380070006000C0018003000601 0C01180110023FFE7FFEFFFE101C7E9B15>I<000C00000C00001C00003C00003C00005C0000DC 00009C00011C00031C00021C00041C000C1C00081C00101C00301C00201C00401C00C01C00FFFF C0001C00001C00001C00001C00001C00001C00001C0001FFC0121C7F9B15>52 D<300C3FF83FF03FC020002000200020002000200023E024302818301C200E000E000F000F000F 600FF00FF00FF00F800E401E401C2038187007C0101D7E9B15>I<03E00C301008200C20066006 600660067006780C3E083FB01FE007F007F818FC307E601E600FC007C003C003C003C003600260 04300C1C1007E0101D7E9B15>56 D<03C00C301818300C700C600EE006E006E007E007E007E007 E0076007700F300F18170C2707C700060006000E300C780C78187010203030C00F80101D7E9B15 >I<000600000006000000060000000F0000000F0000000F000000178000001780000017800000 23C0000023C0000023C0000041E0000041E0000041E0000080F0000080F0000180F80001007800 01FFF80003007C0002003C0002003C0006003E0004001E0004001E000C001F001E001F00FF80FF F01C1D7F9C1F>65 DI<001F808000E0618001801980070007800E 0003801C0003801C00018038000180780000807800008070000080F0000000F0000000F0000000 F0000000F0000000F0000000F0000000F0000000700000807800008078000080380000801C0001 001C0001000E000200070004000180080000E03000001FC000191E7E9C1E>IIII<001F808000E0618001801980070007800E00 03801C0003801C00018038000180780000807800008070000080F0000000F0000000F0000000F0 000000F0000000F0000000F000FFF0F0000F80700007807800078078000780380007801C000780 1C0007800E00078007000B800180118000E06080001F80001C1E7E9C21>I73 D<1FFF00F8007800780078007800780078007800780078 00780078007800780078007800780078007800787078F878F878F878F0F040E021C01F00101D7F 9B15>IIIII<003F800000E0E0000380380007001C000E000E001C0007003C0007 8038000380780003C0780003C0700001C0F00001E0F00001E0F00001E0F00001E0F00001E0F000 01E0F00001E0F00001E0700001C0780003C0780003C0380003803C0007801C0007000E000E0007 001C000380380000E0E000003F80001B1E7E9C20>II82 D<7FFFFFC0700F01C0600F00C0400F0040400F0040C00F0020800F0020800F0020800F0020 000F0000000F0000000F0000000F0000000F0000000F0000000F0000000F0000000F0000000F00 00000F0000000F0000000F0000000F0000000F0000000F0000000F0000001F800003FFFC001B1C 7F9B1E>84 D87 D89 D91 D93 D<1FC000307000783800781C0030 1C00001C00001C0001FC000F1C00381C00701C00601C00E01C40E01C40E01C40603C40304E801F 870012127E9115>97 DI<07E00C301878307870306000E0 00E000E000E000E000E00060007004300418080C3007C00E127E9112>I<003F00000700000700 00070000070000070000070000070000070000070000070003E7000C1700180F00300700700700 600700E00700E00700E00700E00700E00700E00700600700700700300700180F000C370007C7E0 131D7E9C17>I<03E00C301818300C700E6006E006FFFEE000E000E000E0006000700230021804 0C1803E00F127F9112>I<00F8018C071E061E0E0C0E000E000E000E000E000E00FFE00E000E00 0E000E000E000E000E000E000E000E000E000E000E000E000E000E007FE00F1D809C0D>I<0003 8003C4C00C38C01C3880181800381C00381C00381C00381C001818001C38000C300013C0001000 003000001800001FF8001FFF001FFF803003806001C0C000C0C000C0C000C06001803003001C0E 0007F800121C7F9215>II<18003C003C00180000000000 00000000000000000000FC001C001C001C001C001C001C001C001C001C001C001C001C001C001C 001C001C00FF80091D7F9C0C>I107 DIII<03F0000E1C0018060030 0300700380600180E001C0E001C0E001C0E001C0E001C0E001C06001807003803003001806000E 1C0003F00012127F9115>II<03C1000C3300180B00300F00700700700700E007 00E00700E00700E00700E00700E00700600700700700300F00180F000C370007C7000007000007 00000700000700000700000700000700003FE0131A7E9116>II<1F9030704030C010C0 10E010F8007F803FE00FF000F880388018C018C018E010D0608FC00D127F9110>I<0400040004 0004000C000C001C003C00FFE01C001C001C001C001C001C001C001C001C001C101C101C101C10 1C100C100E2003C00C1A7F9910>IIII121 D E /Fc 11 119 df<01C00003E00003E0000360000360000770000770000770000770000630000E 38000E38000E38000E38000E38001FFC001FFC001C1C001C1C003C1E00380E00FE3F80FE3F8011 177F9614>65 D68 D72 D80 D82 D<0FCC1FFC307C603CE01CE01CE01CE00070007E00 3FE00FF001F8001C001E000E600EE00EE00EF01CF838FFF0C7E00F177E9614>I<7FFF80FFFF80 E1C380E1C380E1C380E1C38001C00001C00001C00001C00001C00001C00001C00001C00001C000 01C00001C00001C00001C00001C00001C0000FF8000FF80011177F9614>I<1FC0007FF0007078 00201800001C00001C0007FC001FFC003C1C00701C00E01C00E01C00E01C00707C003FFF800F8F 8011107E8F14>97 D<07E00FF01C38301C700CE00EE00EFFFEFFFEE00060007000380E1C1E0FFC 03F00F107E8F14>101 D108 D118 D E /Fd 44 122 df<00FC000182000703000607000E02000E00000E00000E00000E 00000E0000FFFF000E07000E07000E07000E07000E07000E07000E07000E07000E07000E07000E 07000E07000E07000E07007F0FE0131A809915>12 D<00800100020004000C0008001800300030 0030006000600060006000E000E000E000E000E000E000E000E000E000E0006000600060006000 300030003000180008000C00040002000100008009267D9B0F>40 D<8000400020001000180008 000C00060006000600030003000300030003800380038003800380038003800380038003800300 0300030003000600060006000C0008001800100020004000800009267E9B0F>I<60F0F0701010 1020204080040B7D830B>44 DI<60F0F06004047D830B>I<03000700FF 000700070007000700070007000700070007000700070007000700070007000700070007000700 0700FFF00C187D9713>49 D<0F80106020304038803CC01CE01C401C003C003800380070006000 C001800100020004040804100430083FF87FF8FFF80E187E9713>I<0780186030302018601860 18601870103C303E600F8007C019F030F86038401CC00CC00CC00CC00C6008201018600FC00E18 7E9713>56 D<07801860303070306018E018E018E01CE01CE01C601C603C303C185C0F9C001C00 180018003870307060604021801F000E187E9713>I<000C0000000C0000000C0000001E000000 1E0000003F000000270000002700000043800000438000004380000081C0000081C0000081C000 0100E0000100E00001FFE000020070000200700006007800040038000400380008001C0008001C 001C001E00FF00FFC01A1A7F991D>65 DI68 D<003F020001C0C60003002E000E001E001C000E001C0006003800060078000200700002007000 0200F0000000F0000000F0000000F0000000F0000000F001FFC070000E0070000E0078000E0038 000E001C000E001C000E000E000E000300160001C06600003F82001A1A7E991E>71 D73 D76 D80 D82 D<0FC21836200E6006C006C002C002C002E00070007E003FE01FF807FC003E000E000700038003 80038003C002C006E004D81887E0101A7E9915>I91 D93 D<3F8070C070E020700070007007F01C7030707070E070E071E071E0F171FB1E3C10107E8F13> 97 DI<07F80C1C381C30087000E000E000E000E000E000E0007000300438080C 1807E00E107F8F11>I<007E00000E00000E00000E00000E00000E00000E00000E00000E00000E 0003CE000C3E00380E00300E00700E00E00E00E00E00E00E00E00E00E00E00E00E00600E00700E 00381E001C2E0007CFC0121A7F9915>I<07C01C3030187018600CE00CFFFCE000E000E000E000 6000300438080C1807E00E107F8F11>I<01F0031807380E100E000E000E000E000E000E00FFC0 0E000E000E000E000E000E000E000E000E000E000E000E000E000E007FE00D1A80990C>I<0FCE 187330307038703870387038303018602FC02000600070003FF03FFC1FFE600FC003C003C003C0 036006381C07E010187F8F13>II<18003C003C00180000000000000000000000 0000FC001C001C001C001C001C001C001C001C001C001C001C001C001C001C00FF80091A80990A >I107 DII I<07E01C38300C700E6006E007E007E007E007E007E0076006700E381C1C3807E010107F8F13> II114 D<1F2060E04020C020C020F0007F003FC01FE000F080708030C030C020F0408F800C107F8F0F> I<0400040004000C000C001C003C00FFC01C001C001C001C001C001C001C001C001C201C201C20 1C201C200E4003800B177F960F>III III E /Fe 2 51 df<0C003C00CC000C000C000C000C000C000C 000C000C000C000C000C000C00FF8009107E8F0F>49 D<1F00618040C08060C0600060006000C0 0180030006000C00102020207FC0FFC00B107F8F0F>I E /Ff 2 51 df<03000700FF00070007 000700070007000700070007000700070007000700070007000700070007007FF00C157E9412> 49 D<0F8030E040708030C038E0384038003800700070006000C00180030006000C0808081018 3FF07FF0FFF00D157E9412>I E /Fg 2 63 df<000001C00000078000001E00000078000001E0 0000078000000E00000038000000F0000003C000000F0000003C000000F0000000F00000003C00 00000F00000003C0000000F0000000380000000E0000000780000001E0000000780000001E0000 000780000001C01A1A7C9723>60 D62 D E /Fh 59 122 df<00C00001C00001C00001C00003F0000FFC003FFE00 7DCF0071C700E1C380E1C780E1C780E1C780F1C00079C0003DC0001FE0000FF80003FC0001DE00 01CF0001C70061C380F1C380F1C380E1C380E1C70071C70079DE003FFE001FF80007E00001C000 01C00001C00000C00011247D9F18>36 D<387C7C7E3E0E0E0E1C1C38F8F0C0070E789B18>39 D<007000F001E003C007800F001E001C00380038007000700070007000E000E000E000E000E000 E000E000E0007000700070007000380038001C001E000F00078003C001F000F000700C24799F18 >I<6000F00078003C001E000F000780038001C001C000E000E000E000E0007000700070007000 7000700070007000E000E000E000E001C001C0038007800F001E003C007800F00060000C247C9F 18>I<01C00001C00001C00001C000C1C180F1C780F9CF807FFF001FFC0007F00007F0001FFC00 7FFF00F9CF80F1C780C1C18001C00001C00001C00001C00011147D9718>I<7FFF00FFFF80FFFF 807FFF0011047D8F18>45 D<3078FCFC78300606778518>I<01F00007FC000FFE001F1F001C07 003803807803C07001C07001C0E000E0E000E0E000E0E000E0E000E0E000E0E000E0E000E0E000 E0F001E07001C07001C07803C03803801C07001F1F000FFE0007FC0001F000131C7E9B18>48 D<01800380038007800F803F80FF80FB8043800380038003800380038003800380038003800380 0380038003800380038003807FFCFFFE7FFC0F1C7B9B18>I<03F0000FFE003FFF007C0F807003 C0E001C0F000E0F000E06000E00000E00000E00001C00001C00003C0000780000F00001E00003C 0000780000F00001E00007C0000F80001E00E03C00E07FFFE0FFFFE07FFFE0131C7E9B18>I<07 F8001FFE003FFF007807807803C07801C03001C00001C00003C0000380000F0003FF0003FE0003 FF000007800003C00001C00000E00000E00000E0F000E0F000E0F001C0F003C07C07803FFF001F FE0003F800131C7E9B18>I<001F00003F0000770000770000E70001E70001C700038700078700 0707000E07001E07003C0700380700780700F00700FFFFF8FFFFF8FFFFF8000700000700000700 000700000700000700007FF000FFF8007FF0151C7F9B18>I<1FFF803FFF803FFF803800003800 003800003800003800003800003800003800003BF8003FFE003FFF003C07801803C00001C00000 E00000E06000E0F000E0F000E0E001C07003C07C0F803FFF001FFC0003F000131C7E9B18>I<00 7E0001FF0007FF800F83C01E03C01C03C0380180380000700000700000E1F800E7FE00FFFF00FE 0780F803C0F001C0F000E0E000E0F000E07000E07000E07000E03801C03C03C01E07800FFF0007 FE0001F800131C7E9B18>I<03F0000FFC001FFE003C0F00780780700380E001C0E001C0E001C0 E001E0E001E07001E07803E03C0FE01FFFE00FFEE003F0E00000E00001C00001C00001C0300380 780780780F00783E003FFC001FF00007C000131C7E9B18>57 D<3078FCFC783000000000000000 003078FCFC78300614779318>I<000300000780001F80003F00007E0001FC0003F00007E0001F C0003F00007E0000FC0000FC00007E00003F00001FC00007E00003F00001FC00007E00003F0000 1F8000078000030011187D9918>60 D<600000F00000FC00007E00003F00001FC00007E00003F0 0001FC00007E00003F00001F80001F80003F00007E0001FC0003F00007E0001FC0003F00007E00 00FC0000F0000060000011187D9918>62 D<00700000F80000F80000D80000D80001DC0001DC00 01DC00018C00038E00038E00038E00038E000306000707000707000707000707000FFF800FFF80 0FFF800E03800E03801C01C01C01C07F07F0FF8FF87F07F0151C7F9B18>65 D<00F8E003FEE007FFE00F07E01E03E03C01E03800E07000E07000E0700000E00000E00000E000 00E00000E00000E00000E00000E000007000007000E07000E03800E03C00E01E01C00F07C007FF 8003FE0000F800131C7E9B18>67 D<7FF800FFFE007FFF001C0F801C03C01C03C01C01E01C00E0 1C00E01C00F01C00701C00701C00701C00701C00701C00701C00701C00701C00F01C00E01C00E0 1C01E01C01C01C03C01C0F807FFF00FFFE007FF800141C7F9B18>III<7F07F0FF8FF87F07F01C01C01C01C01C01C01C01C01C01C0 1C01C01C01C01C01C01C01C01FFFC01FFFC01FFFC01C01C01C01C01C01C01C01C01C01C01C01C0 1C01C01C01C01C01C01C01C07F07F0FF8FF87F07F0151C7F9B18>72 D77 D<7E07F0FF0FF87F07F01D81C01D81C01D81C01DC1C01CC1C01CC1C01CE1C01CE1C01CE1 C01C61C01C71C01C71C01C31C01C39C01C39C01C39C01C19C01C19C01C1DC01C0DC01C0DC01C0D C07F07C0FF87C07F03C0151C7F9B18>I<0FF8003FFE007FFF00780F00700700F00780E00380E0 0380E00380E00380E00380E00380E00380E00380E00380E00380E00380E00380E00380E00380E0 0380E00380F00780700700780F007FFF003FFE000FF800111C7D9B18>II<7FF800FFFE007FFF001C0F801C03801C03C01C01C01C01C01C01C01C03C01C03801C0F 801FFF001FFE001FFE001C0F001C07001C03801C03801C03801C03801C03801C039C1C039C1C03 9C7F01F8FF81F87F00F0161C7F9B18>82 D<03F3801FFF803FFF807C0F80700780E00380E00380 E00380E000007000007800003F00001FF00007FE0000FF00000F800003C00001C00000E00000E0 6000E0E000E0E001E0F001C0F80780FFFF80FFFE00E7F800131C7E9B18>I<7FFFF8FFFFF8FFFF F8E07038E07038E07038E070380070000070000070000070000070000070000070000070000070 0000700000700000700000700000700000700000700000700000700007FF0007FF0007FF00151C 7F9B18>II89 D91 D93 D<018007C01FF07EFCF83EE00E0F067C9B18>I<7FFF00FFFF80FFFF807FFF0011047D 7F18>I<061E3E387070E0E0E0F8FC7C7C38070E789E18>I<1FE0003FF8007FFC00781E00300E00 00070000070000FF0007FF001FFF007F0700780700E00700E00700E00700F00F00781F003FFFF0 1FFBF007E1F014147D9318>I<7E0000FE00007E00000E00000E00000E00000E00000E00000E3E 000EFF800FFFC00FC1E00F80E00F00700E00700E00380E00380E00380E00380E00380E00380F00 700F00700F80E00FC1E00FFFC00EFF80063E00151C809B18>I<01FE0007FF001FFF803E078038 0300700000700000E00000E00000E00000E00000E00000E000007000007001C03801C03E03C01F FF8007FF0001FC0012147D9318>I<001F80003F80001F80000380000380000380000380000380 03E3800FFB801FFF803C1F80380F80700780700380E00380E00380E00380E00380E00380E00380 700780700780380F803C1F801FFFF00FFBF803E3F0151C7E9B18>I<01F00007FC001FFE003E0F 00380780700380700380E001C0E001C0FFFFC0FFFFC0FFFFC0E000007000007001C03801C03E03 C01FFF8007FF0001FC0012147D9318>I<001F80007FC000FFE000E1E001C0C001C00001C00001 C0007FFFC0FFFFC0FFFFC001C00001C00001C00001C00001C00001C00001C00001C00001C00001 C00001C00001C00001C00001C0007FFF007FFF007FFF00131C7F9B18>I<01E1F007FFF80FFFF8 1E1E301C0E003807003807003807003807003807001C0E001E1E001FFC001FF80039E000380000 1C00001FFE001FFFC03FFFE07801F0700070E00038E00038E00038E000387800F07E03F01FFFC0 0FFF8001FC00151F7F9318>I<7E0000FE00007E00000E00000E00000E00000E00000E00000E3E 000EFF800FFFC00FC1C00F80E00F00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00 E00E00E00E00E00E00E07FC3FCFFE7FE7FC3FC171C809B18>I<03800007C00007C00007C00003 80000000000000000000000000007FC000FFC0007FC00001C00001C00001C00001C00001C00001 C00001C00001C00001C00001C00001C00001C00001C00001C000FFFF00FFFF80FFFF00111D7C9C 18>I<7FE000FFE0007FE00000E00000E00000E00000E00000E00000E00000E00000E00000E000 00E00000E00000E00000E00000E00000E00000E00000E00000E00000E00000E00000E00000E000 7FFFC0FFFFE07FFFC0131C7E9B18>108 D<7CE0E000FFFBF8007FFFF8001F1F1C001E1E1C001E 1E1C001C1C1C001C1C1C001C1C1C001C1C1C001C1C1C001C1C1C001C1C1C001C1C1C001C1C1C00 1C1C1C001C1C1C007F1F1F00FFBFBF807F1F1F001914819318>I<7E3E00FEFF807FFFC00FC1C0 0F80E00F00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E0 7FC3FCFFE7FE7FC3FC1714809318>I<01F0000FFE001FFF003E0F803803807001C07001C0E000 E0E000E0E000E0E000E0E000E0F001E07001C07803C03C07803E0F801FFF000FFE0001F0001314 7E9318>I<7E3E00FEFF807FFFC00FC1E00F80E00F00700E00700E00380E00380E00380E00380E 00380E00380F00700F00700F80E00FC1E00FFFC00EFF800E3E000E00000E00000E00000E00000E 00000E00000E00007FC000FFE0007FC000151E809318>I<7F87E0FF9FF07FBFF803F87803F030 03E00003C00003C0000380000380000380000380000380000380000380000380000380007FFE00 FFFF007FFE0015147F9318>114 D<07F7003FFF007FFF00780F00E00700E00700E007007C0000 7FE0001FFC0003FE00001F00600780E00380E00380F00380F80F00FFFF00FFFC00E7F00011147D 9318>I<0180000380000380000380000380007FFFC0FFFFC0FFFFC00380000380000380000380 000380000380000380000380000380000380400380E00380E00380E001C1C001FFC000FF80003E 0013197F9818>I<7E07E0FE0FE07E07E00E00E00E00E00E00E00E00E00E00E00E00E00E00E00E 00E00E00E00E00E00E00E00E00E00E01E00F03E007FFFC03FFFE01FCFC1714809318>I<7F8FF0 FF8FF87F8FF01E03C00E03800E03800E0380070700070700070700038E00038E00038E00038E00 01DC0001DC0001DC0000F80000F80000700015147F9318>I<7F8FF07F9FF07F8FF0070700078E 00039E0001DC0001F80000F80000700000F00000F80001DC00039E00038E000707000F07807F8F F0FF8FF87F8FF015147F9318>120 D<7F8FF0FF8FF87F8FF00E01C00E03800E03800703800707 00070700038700038600038E0001CE0001CE0000CC0000CC0000DC000078000078000078000070 0000700000700000F00000E00079E0007BC0007F80003F00001E0000151E7F9318>I E /Fi 5 117 df<70F8F8F0E005057B840E>46 D<00F1800389C00707800E03801C03803C0380 380700780700780700780700F00E00F00E00F00E00F00E20F01C40F01C40703C40705C40308C80 0F070013147C9317>97 D<007C01C207010E011C013C013802780C7BF07C00F000F000F000F000 7000700170023804183807C010147C9315>101 D<03C01FC00380038003800380070007000700 07000E000E000E000E001C001C001C001C0038003800380038007000700070007100E200E200E2 00E200640038000A207C9F0C>108 D<018001C0038003800380038007000700FFF007000E000E 000E000E001C001C001C001C003800380038003820704070407080708031001E000C1C7C9B0F> 116 D E /Fj 32 122 df<000E00001E00007E0007FE00FFFE00FFFE00F8FE0000FE0000FE0000 FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000 FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000FE0000 FE007FFFFE7FFFFE7FFFFE17277BA622>49 D<00FF800003FFF0000FFFFC001F03FE003800FF00 7C007F80FE003FC0FF003FC0FF003FE0FF001FE0FF001FE07E001FE03C003FE000003FE000003F C000003FC000007F8000007F000000FE000000FC000001F8000003F0000003E00000078000000F 0000001E0000003C00E0007000E000E000E001C001C0038001C0070001C00FFFFFC01FFFFFC03F FFFFC07FFFFFC0FFFFFF80FFFFFF80FFFFFF801B277DA622>I<007F800003FFF00007FFFC000F 81FE001F00FF003F80FF003F807F803F807F803F807F801F807F800F007F800000FF000000FF00 0000FE000001FC000001F8000007F00000FFC00000FFF0000001FC0000007E0000007F0000007F 8000003FC000003FC000003FE000003FE03C003FE07E003FE0FF003FE0FF003FE0FF003FC0FF00 7FC07E007F807C007F003F01FE001FFFFC0007FFF00000FF80001B277DA622>I<00000E000000 1E0000003E0000007E000000FE000000FE000001FE000003FE0000077E00000E7E00000E7E0000 1C7E0000387E0000707E0000E07E0000E07E0001C07E0003807E0007007E000E007E000E007E00 1C007E0038007E0070007E00E0007E00FFFFFFF8FFFFFFF8FFFFFFF80000FE000000FE000000FE 000000FE000000FE000000FE000000FE000000FE00007FFFF8007FFFF8007FFFF81D277EA622> I<000003800000000007C00000000007C0000000000FE0000000000FE0000000000FE000000000 1FF0000000001FF0000000003FF8000000003FF8000000003FF80000000073FC0000000073FC00 000000F3FE00000000E1FE00000000E1FE00000001C0FF00000001C0FF00000003C0FF80000003 807F80000007807FC0000007003FC0000007003FC000000E003FE000000E001FE000001E001FF0 00001C000FF000001FFFFFF000003FFFFFF800003FFFFFF80000780007FC0000700003FC000070 0003FC0000E00001FE0000E00001FE0001E00001FF0001C00000FF0001C00000FF00FFFE001FFF FEFFFE001FFFFEFFFE001FFFFE2F297EA834>65 D I69 D73 D<0000FFE000000007FFFC0000003FC07F8000007F001FC00001FC0007F00003F80003F80007F0 0001FC000FF00001FE001FE00000FF001FE00000FF003FC000007F803FC000007F807FC000007F C07F8000003FC07F8000003FC07F8000003FC0FF8000003FE0FF8000003FE0FF8000003FE0FF80 00003FE0FF8000003FE0FF8000003FE0FF8000003FE0FF8000003FE0FF8000003FE0FF8000003F E07F8000003FC07FC000007FC07FC000007FC03FC000007F803FC000007F801FE00000FF001FE0 0000FF000FF00001FE0007F00001FC0003F80003F80001FC0007F00000FF001FE000003FC07F80 00000FFFFE00000000FFE000002B297CA834>79 DI82 D<007F806003FFF0E007FFF9E00F807FE01F001FE0 3E0007E07C0003E07C0001E0FC0001E0FC0001E0FC0000E0FE0000E0FE0000E0FF000000FFC000 007FFE00007FFFE0003FFFFC001FFFFE000FFFFF8007FFFFC003FFFFE000FFFFE00007FFF00000 7FF000000FF8000007F8000003F8600001F8E00001F8E00001F8E00001F8F00001F0F00001F0F8 0003F0FC0003E0FF0007C0FFE01F80F3FFFF00E0FFFE00C01FF0001D297CA826>I<01FF800007 FFF0000F81F8001FC07E001FC07E001FC03F000F803F8007003F8000003F8000003F8000003F80 000FFF8000FFFF8007FC3F800FE03F803F803F803F003F807F003F80FE003F80FE003F80FE003F 80FE003F807E007F807F00DF803F839FFC0FFF0FFC01FC03FC1E1B7E9A21>97 DI<001FF80000FFFE0003F01F0007E03F80 0FC03F801F803F803F801F007F800E007F0000007F000000FF000000FF000000FF000000FF0000 00FF000000FF000000FF0000007F0000007F0000007F8000003F8001C01F8001C00FC0038007E0 070003F01E0000FFFC00001FE0001A1B7E9A1F>I<00003FF80000003FF80000003FF800000003 F800000003F800000003F800000003F800000003F800000003F800000003F800000003F8000000 03F800000003F800000003F800000003F800001FE3F80000FFFBF80003F03FF80007E00FF8000F C007F8001F8003F8003F8003F8007F0003F8007F0003F8007F0003F800FF0003F800FF0003F800 FF0003F800FF0003F800FF0003F800FF0003F800FF0003F8007F0003F8007F0003F8007F0003F8 003F8003F8001F8003F8000F8007F80007C00FF80003F03BFF8000FFF3FF80003FC3FF80212A7E A926>I<003FE00001FFF80003F07E0007C01F000F801F801F800F803F800FC07F000FC07F0007 C07F0007E0FF0007E0FF0007E0FFFFFFE0FFFFFFE0FF000000FF000000FF0000007F0000007F00 00007F0000003F8000E01F8000E00FC001C007E0038003F81F0000FFFE00001FF0001B1B7E9A20 >I<0007F0003FFC00FE3E01F87F03F87F03F07F07F07F07F03E07F00007F00007F00007F00007 F00007F00007F000FFFFC0FFFFC0FFFFC007F00007F00007F00007F00007F00007F00007F00007 F00007F00007F00007F00007F00007F00007F00007F00007F00007F00007F00007F00007F00007 F0007FFF807FFF807FFF80182A7EA915>I<00FF81F003FFE7F80FC1FE7C1F80FC7C1F007C383F 007E107F007F007F007F007F007F007F007F007F007F007F007F003F007E001F007C001F80FC00 0FC1F8001FFFE00018FF800038000000380000003C0000003E0000003FFFF8001FFFFF001FFFFF 800FFFFFC007FFFFE01FFFFFF03E0007F07C0001F8F80000F8F80000F8F80000F8F80000F87C00 01F03C0001E01F0007C00FC01F8003FFFE00007FF0001E287E9A22>II<07000FC01FE03FE03FE03FE01FE00FC00700000000000000000000 0000000000FFE0FFE0FFE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE00FE0 0FE00FE00FE00FE00FE00FE00FE0FFFEFFFEFFFE0F2B7DAA14>I 108 D110 D<003FE00001FFFC0003 F07E000FC01F801F800FC03F800FE03F0007E07F0007F07F0007F07F0007F0FF0007F8FF0007F8 FF0007F8FF0007F8FF0007F8FF0007F8FF0007F8FF0007F87F0007F07F0007F03F800FE03F800F E01F800FC00FC01F8007F07F0001FFFC00003FE0001D1B7E9A22>II114 D<03FE300FFFF01E03F03800F0700070F00070F00070F80070FC0000FFE0007F FE007FFF803FFFE01FFFF007FFF800FFF80003FC0000FC60007CE0003CF0003CF00038F80038FC 0070FF01E0F7FFC0C1FF00161B7E9A1B>I<00700000700000700000700000F00000F00000F000 01F00003F00003F00007F0001FFFF0FFFFF0FFFFF007F00007F00007F00007F00007F00007F000 07F00007F00007F00007F00007F00007F00007F00007F03807F03807F03807F03807F03807F038 03F03803F87001F86000FFC0001F8015267FA51B>II119 DII E /Fk 16 123 df<3078FCFC7830060676851A>46 D<003E0001FF8003FFC007C1E00F00E01E0F703C3FF0387FF07070F870E07870E078E1C038E1C0 38E1C038E1C038E1C038E1C038E1C038E1C03870E07070E0707070E0387FE03C3FC01E0F000F00 3807C0F803FFF001FFE0003F00151E7E9D1A>64 D<00FF8003FFC00FFFE01F01E03C00C0780000 700000700000E00000E00000E00000E00000E000007000007000007800703C00701F01F00FFFE0 03FFC000FE0014157D941A>99 D<001FC0001FC0001FC00001C00001C00001C00001C00001C000 01C001F1C007FDC00FFFC01E0FC03C07C07803C07001C0E001C0E001C0E001C0E001C0E001C0E0 01C0E001C07003C07003C03807C03E0FC01FFFFC07FDFC01F1FC161E7E9D1A>I<01F80007FF00 0FFF801E07C03C01C07800E07000E0E00070E00070FFFFF0FFFFF0FFFFF0E00000700000700000 7800703C00701F01F00FFFE003FFC000FE0014157D941A>I<01F87C07FFFE0FFFFE1E078C1C03 803801C03801C03801C03801C03801C01C03801E07801FFF001FFE0039F8003800003800001C00 001FFF801FFFE03FFFF878007C70001CE0000EE0000EE0000EE0000E70001C78003C3E00F81FFF F007FFC001FF0017217F941A>103 D<00C00001E00001E00000C0000000000000000000000000 000000000000007FE0007FE0007FE00000E00000E00000E00000E00000E00000E00000E00000E0 0000E00000E00000E00000E00000E00000E00000E0007FFF80FFFFC07FFF80121F7C9E1A>105 D<000C001E001E000C0000000000000000000000000FFE0FFE0FFE000E000E000E000E000E000E 000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E001C601CF0 38FFF87FF01FC00F2A7E9E1A>I<7CE0E000FFFBF8007FFFF8001F1F1C001E1E1C001E1E1C001C 1C1C001C1C1C001C1C1C001C1C1C001C1C1C001C1C1C001C1C1C001C1C1C001C1C1C001C1C1C00 1C1C1C001C1C1C007F1F1F00FF9F9F807F1F1F00191580941A>109 DI<7F83F0FF8FF87FBFFC03FC3C03F01803E000 03C00003C0000380000380000380000380000380000380000380000380000380000380007FFF00 FFFF007FFF0016157E941A>114 D<07FB801FFF807FFF80780780E00380E00380E00380780000 7FC0003FFC0007FE00003F800007806001C0E001C0E001C0F003C0FC0780FFFF00EFFE00E3F800 12157C941A>I<00C00001C00001C00001C00001C00001C00001C0007FFFE0FFFFE0FFFFE001C0 0001C00001C00001C00001C00001C00001C00001C00001C00001C00001C07001C07001C07001C0 7000E0E000FFE0007FC0001F00141C7F9B1A>II<7FC3FCFFC7FE7FC3FC0E00E00E00E00700E00701C00781C00381C0 03838003C38001C38001C70000E70000E70000E600006600006E00003C00003C00003C00003800 00380000380000700000700030700078E00071E0007FC0003F80001E000017207F941A>121 D<7FFFF0FFFFF0FFFFF0E001E0E003C0E00780000F00001E00003C0000780000F00001E00003C0 000780000F00381E00383C0038780038FFFFF8FFFFF8FFFFF815157E941A>I E /Fl 36 122 df<70F8FCFC7404040404080810102040060F7C840E>44 D<01F000071C000C06001803003803803803807001C07001C07001C07001C0F001E0F001E0F001 E0F001E0F001E0F001E0F001E0F001E0F001E0F001E0F001E0F001E0F001E0F001E07001C07001 C07001C07803C03803803803801C07000C0600071C0001F00013227EA018>48 D<008003800F80F380038003800380038003800380038003800380038003800380038003800380 03800380038003800380038003800380038003800380038007C0FFFE0F217CA018>I<03F0000C 1C001007002007804003C04003C08003E0F003E0F801E0F801E0F801E02003E00003E00003C000 03C0000780000700000E00001C0000180000300000600000C00001800001000002002004002008 00201800603000403FFFC07FFFC0FFFFC013217EA018>I<1000801E07001FFF001FFE001FF800 13E00010000010000010000010000010000010000010F800130E001407001803801003800001C0 0001C00001E00001E00001E00001E07001E0F001E0F001E0E001C08001C04003C0400380200700 1006000C1C0003F00013227EA018>53 D<01F000060C000C0600180700380380700380700380F0 01C0F001C0F001C0F001E0F001E0F001E0F001E0F001E07001E07003E03803E01805E00C05E006 19E003E1E00001C00001C00001C0000380000380300300780700780600700C002018001030000F C00013227EA018>57 D<07E01838201C400E800FF00FF00FF00F000F000E001C00380030006000 C000C000800080018001000100010001000100010000000000000000000000038007C007C007C0 038010237DA217>63 D<0001800000018000000180000003C0000003C0000003C0000005E00000 05E000000DF0000008F0000008F0000010F800001078000010780000203C0000203C0000203C00 00401E0000401E0000401E0000800F0000800F0000FFFF000100078001000780030007C0020003 C0020003C0040003E0040001E0040001E00C0000F00C0000F03E0001F8FF800FFF20237EA225> 65 D<0007E0100038183000E0063001C00170038000F0070000F00E0000701E0000701C000030 3C0000303C0000307C0000107800001078000010F8000000F8000000F8000000F8000000F80000 00F8000000F8000000F800000078000000780000107C0000103C0000103C0000101C0000201E00 00200E000040070000400380008001C0010000E0020000381C000007E0001C247DA223>67 D73 D77 DI82 D<03F0200C0C601802603001E07000E0600060E00060E00060E00020E00020E00020F00000F000 007800007F00003FF0001FFE000FFF0003FF80003FC00007E00001E00000F00000F00000708000 70800070800070800070C00060C00060E000C0F000C0C80180C6070081FC0014247DA21B>I85 D<0FE0001838003C0C00 3C0E0018070000070000070000070000FF0007C7001E07003C0700780700700700F00708F00708 F00708F00F087817083C23900FC1E015157E9418>97 D<0E0000FE00001E00000E00000E00000E 00000E00000E00000E00000E00000E00000E00000E00000E00000E1F000E61C00E80600F00300E 00380E003C0E001C0E001E0E001E0E001E0E001E0E001E0E001E0E001E0E001C0E003C0E00380F 00700C80600C41C0083F0017237FA21B>I<01FE000703000C07801C0780380300780000700000 F00000F00000F00000F00000F00000F00000F000007000007800403800401C00800C0100070600 01F80012157E9416>I<0000E0000FE00001E00000E00000E00000E00000E00000E00000E00000 E00000E00000E00000E00000E001F8E00704E00C02E01C01E03800E07800E07000E0F000E0F000 E0F000E0F000E0F000E0F000E0F000E07000E07800E03800E01801E00C02E0070CF001F0FE1723 7EA21B>I<01FC000707000C03801C01C03801C07801E07000E0F000E0FFFFE0F00000F00000F0 0000F00000F000007000007800203800201C00400E008007030000FC0013157F9416>I<003C00 C6018F038F030F070007000700070007000700070007000700FFF8070007000700070007000700 07000700070007000700070007000700070007000700070007807FF8102380A20F>I<00007001 F198071E180E0E181C07001C07003C07803C07803C07803C07801C07001C07000E0E000F1C0019 F0001000001000001800001800001FFE000FFFC00FFFE03800F0600030400018C00018C00018C0 00186000306000303800E00E038003FE0015217F9518>I<0E0000FE00001E00000E00000E0000 0E00000E00000E00000E00000E00000E00000E00000E00000E00000E1F800E60C00E80E00F0070 0F00700E00700E00700E00700E00700E00700E00700E00700E00700E00700E00700E00700E0070 0E00700E00700E0070FFE7FF18237FA21B>I<1C003E003E003E001C0000000000000000000000 0000000000000E00FE001E000E000E000E000E000E000E000E000E000E000E000E000E000E000E 000E000E000E00FFC00A227FA10E>I<0E0000FE00001E00000E00000E00000E00000E00000E00 000E00000E00000E00000E00000E00000E00000E03FC0E01F00E01C00E01800E02000E04000E08 000E10000E38000EF8000F1C000E1E000E0E000E07000E07800E03C00E01C00E01E00E00F00E00 F8FFE3FE17237FA21A>107 D<0E00FE001E000E000E000E000E000E000E000E000E000E000E00 0E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E 000E00FFE00B237FA20E>I<0E1FC07F00FE60E183801E807201C00F003C00E00F003C00E00E00 3800E00E003800E00E003800E00E003800E00E003800E00E003800E00E003800E00E003800E00E 003800E00E003800E00E003800E00E003800E00E003800E00E003800E00E003800E0FFE3FF8FFE 27157F942A>I<0E1F80FE60C01E80E00F00700F00700E00700E00700E00700E00700E00700E00 700E00700E00700E00700E00700E00700E00700E00700E00700E0070FFE7FF18157F941B>I<01 FC000707000C01801800C03800E0700070700070F00078F00078F00078F00078F00078F00078F0 00787000707800F03800E01C01C00E038007070001FC0015157F9418>I<0E3CFE461E8F0F0F0F 060F000E000E000E000E000E000E000E000E000E000E000E000E000E000F00FFF010157F9413> 114 D<0F8830786018C018C008C008E008F0007F803FE00FF001F8003C801C800C800CC00CC008 E018D0308FC00E157E9413>I<02000200020002000600060006000E001E003E00FFF80E000E00 0E000E000E000E000E000E000E000E000E000E040E040E040E040E040E040708030801F00E1F7F 9E13>I<0E0070FE07F01E00F00E00700E00700E00700E00700E00700E00700E00700E00700E00 700E00700E00700E00700E00700E00F00E00F006017003827800FC7F18157F941B>II I121 D E /Fm 70 123 df<001F83E000F06E3001C078780380F8780300F0300700700007007000070070000700700007 0070000700700007007000FFFFFF80070070000700700007007000070070000700700007007000 070070000700700007007000070070000700700007007000070070000700700007007000070070 0007007000070070007FE3FF001D20809F1B>11 D<003F0000E0C001C0C00381E00701E00701E0 070000070000070000070000070000070000FFFFE00700E00700E00700E00700E00700E00700E0 0700E00700E00700E00700E00700E00700E00700E00700E00700E00700E00700E00700E07FC3FE 1720809F19>I<003FE000E0E001C1E00381E00700E00700E00700E00700E00700E00700E00700 E00700E0FFFFE00700E00700E00700E00700E00700E00700E00700E00700E00700E00700E00700 E00700E00700E00700E00700E00700E00700E00700E07FE7FE1720809F19>I<80108010801040 20606030C03FC00F000C087B9F17>21 D<7038F87CFC7EFC7E743A040204020402080408041008 1008201040200F0E7E9F17>34 D<70F8FCFC74040404080810102040060E7C9F0D>39 D<0020004000800100020006000C000C00180018003000300030007000600060006000E000E000 E000E000E000E000E000E000E000E000E000E0006000600060007000300030003000180018000C 000C000600020001000080004000200B2E7DA112>I<800040002000100008000C000600060003 00030001800180018001C000C000C000C000E000E000E000E000E000E000E000E000E000E000E0 00E000C000C000C001C001800180018003000300060006000C00080010002000400080000B2E7D A112>I<70F8FCFC74040404080810102040060E7C840D>44 DI<70F8F8 F87005057C840D>I<000100030003000600060006000C000C000C001800180018003000300030 00600060006000C000C000C00180018001800300030003000600060006000C000C000C00180018 001800300030003000600060006000C000C000C000102D7DA117>I<03F0000E1C001C0E001806 00380700700380700380700380700380F003C0F003C0F003C0F003C0F003C0F003C0F003C0F003 C0F003C0F003C0F003C0F003C0F003C07003807003807003807807803807001806001C0E000E1C 0003F000121F7E9D17>I<018003800F80F3800380038003800380038003800380038003800380 0380038003800380038003800380038003800380038003800380038007C0FFFE0F1E7C9D17>I< 03F0000C1C00100E00200700400780800780F007C0F803C0F803C0F803C02007C00007C0000780 000780000F00000E00001C0000380000700000600000C0000180000300000600400C0040180040 1000803FFF807FFF80FFFF80121E7E9D17>I<03F0000C1C00100E00200F00780F807807807807 80380F80000F80000F00000F00000E00001C0000380003F000003C00000E00000F000007800007 800007C02007C0F807C0F807C0F807C0F00780400780400F00200E001C3C0003F000121F7E9D17 >I<000600000600000E00000E00001E00002E00002E00004E00008E00008E00010E00020E0002 0E00040E00080E00080E00100E00200E00200E00400E00C00E00FFFFF0000E00000E00000E0000 0E00000E00000E00000E0000FFE0141E7F9D17>I<1803001FFE001FFC001FF8001FE000100000 10000010000010000010000010000011F000161C00180E001007001007800003800003800003C0 0003C00003C07003C0F003C0F003C0E00380400380400700200600100E000C380003E000121F7E 9D17>I<007C000182000701000E03800C07801C0780380300380000780000700000700000F1F0 00F21C00F40600F80700F80380F80380F003C0F003C0F003C0F003C0F003C07003C07003C07003 803803803807001807000C0E00061C0001F000121F7E9D17>I<03F0000C0C0010060030030020 01806001806001806001807001807803003E03003F06001FC8000FF00003F80007FC000C7E0010 3F00300F806003804001C0C001C0C000C0C000C0C000C0C000806001802001001002000C0C0003 F000121F7E9D17>56 D<03F0000E18001C0C00380600380700700700700380F00380F00380F003 C0F003C0F003C0F003C0F003C07007C07007C03807C0180BC00E13C003E3C00003800003800003 80000700300700780600780E00700C002018001070000FC000121F7E9D17>I<70F8F8F8700000 000000000000000070F8F8F87005147C930D>I<0FC0307040384038E03CF03CF03C603C003800 7000E000C001800180010003000200020002000200020002000000000000000000000007000F80 0F800F8007000E207D9F15>63 D<000100000003800000038000000380000007C0000007C00000 07C0000009E0000009E0000009E0000010F0000010F0000010F000002078000020780000207800 00403C0000403C0000403C0000801E0000801E0000FFFE0001000F0001000F0001000F00020007 800200078002000780040003C00E0003C01F0007E0FFC03FFE1F207F9F22>65 DI<000FC040007030C001C009C0038005C0070003C00E0001C0 1E0000C01C0000C03C0000C07C0000407C00004078000040F8000000F8000000F8000000F80000 00F8000000F8000000F8000000F8000000F8000000780000007C0000407C0000403C0000401C00 00401E0000800E000080070001000380020001C0040000703800000FC0001A217D9F21>I69 DI72 DI<0FFFC0007C00 003C00003C00003C00003C00003C00003C00003C00003C00003C00003C00003C00003C00003C00 003C00003C00003C00003C00003C00003C00003C00003C00203C00F83C00F83C00F83C00F03800 40780040700030E0000F800012207E9E17>I77 D I<001F800000F0F00001C0380007801E000F000F000E0007001E0007803C0003C03C0003C07C00 03E0780001E0780001E0F80001F0F80001F0F80001F0F80001F0F80001F0F80001F0F80001F0F8 0001F0F80001F0780001E07C0003E07C0003E03C0003C03C0003C01E0007800E0007000F000F00 07801E0001C0380000F0F000001F80001C217D9F23>II82 D<07E0800C1980100780300380600180600180E00180E0 0080E00080E00080F00000F000007800007F00003FF0001FFC000FFE0003FF00001F8000078000 03C00003C00001C08001C08001C08001C08001C0C00180C00380E00300F00600CE0C0081F80012 217D9F19>I<7FFFFFE0780F01E0600F0060400F0020400F0020C00F0030800F0010800F001080 0F0010800F0010000F0000000F0000000F0000000F0000000F0000000F0000000F0000000F0000 000F0000000F0000000F0000000F0000000F0000000F0000000F0000000F0000000F0000000F00 00000F0000001F800007FFFE001C1F7E9E21>II87 D89 D91 D<080410082010201040204020804080408040B85CFC7EFC7E7C3E381C0F0E7B9F17>II<1FE000303000781800781C00300E00000E00000E00000E0000FE00078E 001E0E00380E00780E00F00E10F00E10F00E10F01E10781E103867200F83C014147E9317>97 D<0E0000FE00000E00000E00000E00000E00000E00000E00000E00000E00000E00000E00000E3E 000EC3800F01C00F00E00E00E00E00700E00700E00780E00780E00780E00780E00780E00780E00 700E00700E00E00F00E00D01C00CC300083E0015207F9F19>I<03F80E0C1C1E381E380C700070 00F000F000F000F000F000F00070007000380138011C020E0C03F010147E9314>I<000380003F 8000038000038000038000038000038000038000038000038000038000038003E380061B801C07 80380380380380700380700380F00380F00380F00380F00380F00380F003807003807003803803 803807801C07800E1B8003E3F815207E9F19>I<03F0000E1C001C0E0038070038070070070070 0380F00380F00380FFFF80F00000F00000F000007000007000003800801800800C010007060001 F80011147F9314>I<007C00C6018F038F07060700070007000700070007000700FFF007000700 07000700070007000700070007000700070007000700070007000700070007007FF01020809F0E >I<0000E003E3300E3C301C1C30380E00780F00780F00780F00780F00780F00380E001C1C001E 380033E0002000002000003000003000003FFE001FFF800FFFC03001E0600070C00030C00030C0 0030C000306000603000C01C038003FC00141F7F9417>I<0E0000FE00000E00000E00000E0000 0E00000E00000E00000E00000E00000E00000E00000E3E000E43000E81800F01C00F01C00E01C0 0E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C0 FFE7FC16207F9F19>I<1C001E003E001E001C000000000000000000000000000E007E000E000E 000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E00FFC00A1F809E0C> I<00E001F001F001F000E0000000000000000000000000007007F000F000700070007000700070 00700070007000700070007000700070007000700070007000700070007000706070F060F0C061 803F000C28829E0E>I<0E0000FE00000E00000E00000E00000E00000E00000E00000E00000E00 000E00000E00000E0FF00E03C00E03000E02000E04000E08000E10000E30000E70000EF8000F38 000E1C000E1E000E0E000E07000E07800E03800E03C00E03E0FFCFF815207F9F18>I<0E00FE00 0E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E000E 000E000E000E000E000E000E000E000E000E00FFE00B20809F0C>I<0E1F01F000FE618618000E 81C81C000F00F00E000F00F00E000E00E00E000E00E00E000E00E00E000E00E00E000E00E00E00 0E00E00E000E00E00E000E00E00E000E00E00E000E00E00E000E00E00E000E00E00E000E00E00E 000E00E00E00FFE7FE7FE023147F9326>I<0E3E00FE43000E81800F01C00F01C00E01C00E01C0 0E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C0FFE7FC 16147F9319>I<01F800070E001C03803801C03801C07000E07000E0F000F0F000F0F000F0F000 F0F000F0F000F07000E07000E03801C03801C01C0380070E0001F80014147F9317>I<0E3E00FE C3800F01C00F00E00E00E00E00F00E00700E00780E00780E00780E00780E00780E00780E00700E 00F00E00E00F01E00F01C00EC3000E3E000E00000E00000E00000E00000E00000E00000E00000E 0000FFE000151D7F9319>I<03E0800619801C05803C0780380380780380700380F00380F00380 F00380F00380F00380F003807003807803803803803807801C0B800E138003E380000380000380 000380000380000380000380000380000380003FF8151D7E9318>I<0E78FE8C0F1E0F1E0F0C0E 000E000E000E000E000E000E000E000E000E000E000E000E000E00FFE00F147F9312>I<1F9030 704030C010C010C010E00078007F803FE00FF00070803880188018C018C018E030D0608F800D14 7E9312>I<020002000200060006000E000E003E00FFF80E000E000E000E000E000E000E000E00 0E000E000E000E080E080E080E080E080610031001E00D1C7F9B12>I<0E01C0FE1FC00E01C00E 01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E01C00E 03C00603C0030DC001F1FC16147F9319>III<7FC3FC0F01E00701C007018003810001C20000E40000EC 00007800003800003C00007C00004E000087000107000303800201C00601E01E01E0FF07FE1714 809318>II<3FFF380E200E201C40384078407000E001E0 01C00380078007010E011E011C0338027006700EFFFE10147F9314>I E /Fn 22 122 df45 D<00080000380000780001F8003FF800 FE7800C07800007800007800007800007800007800007800007800007800007800007800007800 007800007800007800007800007800007800007800007800007800007800007800007800007800 007800007800007800007800007800007800007800007800007800007800007800007800007800 00FC007FFFF87FFFF8152F7AAE21>49 D<003F800000FFE00003C0F80007003C000E000E000C00 0F001C00070018000780380003803800038038000380380003803C0003803C0003003E0007001F 0006001F800E000FE01C0007F0380003FC600001FEC00000FF8000003FC000007FF00001C7F800 0303FC000600FE000C007F0018001F8038000FC0700007C0700003C0600001E0E00001E0E00000 E0E00000E0E00000E0E00000E0E00000C0700000C0700001C038000180380003001C0007000F00 1E0007C0780001FFF000003F80001B307DAE21>56 D<0000030000000000030000000000030000 0000000780000000000780000000000FC0000000000FC0000000000FC00000000017E000000000 13E00000000013E00000000023F00000000021F00000000021F00000000040F80000000040F800 00000040F800000000807C00000000807C00000001807E00000001003E00000001003E00000002 003F00000002001F00000002001F00000004000F80000004000F80000004000F800000080007C0 0000080007C00000180007E000001FFFFFE000001FFFFFE00000200003F00000200001F0000020 0001F00000400001F80000400000F80000400000F800008000007C00008000007C00008000007C 00010000003E00010000003E00030000003F00030000001F00070000001F001F8000003F80FFE0 0003FFFCFFE00003FFFC2E327EB132>65 D69 D80 D82 D<007F802001FFE02007C078600F001C601E0006E03C0003 E0380001E0780000E0700000E070000060F0000060F0000060F0000020F0000020F0000020F800 0020F80000007C0000007E0000003F0000003FC000001FF800000FFF800007FFF80003FFFC0000 FFFF00000FFF800000FFC000001FE0000007E0000003F0000001F0000000F0000000F8000000F8 8000007880000078800000788000007880000078C0000078C0000070E00000F0E00000E0F00000 E0F80001C0EC000380C7000700C1F01E00807FFC00800FF0001D337CB125>I<00FE00000303C0 000C00E00010007000100038003C003C003E001C003E001E003E001E0008001E0000001E000000 1E0000001E00000FFE0000FC1E0003E01E000F801E001F001E003E001E003C001E007C001E00F8 001E04F8001E04F8001E04F8003E04F8003E0478003E047C005E043E008F080F0307F003FC03E0 1E1F7D9E21>97 D<003F800000E0E0000380380007003C000E001E001E001E001C000F003C000F 007C000F0078000F8078000780F8000780F8000780FFFFFF80F8000000F8000000F8000000F800 0000F8000000F8000000780000007C0000003C0000003C0000801E0000800E0001000F00020007 80020001C00C0000F03000001FC000191F7E9E1D>101 D<0780000000FF80000000FF80000000 0F8000000007800000000780000000078000000007800000000780000000078000000007800000 000780000000078000000007800000000780000000078000000007800000000780000000078000 00000780FE00000783078000078C03C000079001E00007A001E00007A000F00007C000F00007C0 00F000078000F000078000F000078000F000078000F000078000F000078000F000078000F00007 8000F000078000F000078000F000078000F000078000F000078000F000078000F000078000F000 078000F000078000F000078000F000078000F000078000F0000FC001F800FFFC1FFF80FFFC1FFF 8021327EB125>104 D<0F001F801F801F801F800F000000000000000000000000000000000000 00000000000780FF80FF800F800780078007800780078007800780078007800780078007800780 078007800780078007800780078007800780078007800FC0FFF8FFF80D307EAF12>I<0780FE00 1FC000FF83078060F000FF8C03C18078000F9001E2003C0007A001E4003C0007A000F4001E0007 C000F8001E0007C000F8001E00078000F0001E00078000F0001E00078000F0001E00078000F000 1E00078000F0001E00078000F0001E00078000F0001E00078000F0001E00078000F0001E000780 00F0001E00078000F0001E00078000F0001E00078000F0001E00078000F0001E00078000F0001E 00078000F0001E00078000F0001E00078000F0001E00078000F0001E00078000F0001E000FC001 F8003F00FFFC1FFF83FFF0FFFC1FFF83FFF0341F7E9E38>109 D<0780FE0000FF83078000FF8C 03C0000F9001E00007A001E00007A000F00007C000F00007C000F000078000F000078000F00007 8000F000078000F000078000F000078000F000078000F000078000F000078000F000078000F000 078000F000078000F000078000F000078000F000078000F000078000F000078000F000078000F0 00078000F000078000F0000FC001F800FFFC1FFF80FFFC1FFF80211F7E9E25>I<001FC00000F0 780001C01C00070007000F0007801E0003C01C0001C03C0001E03C0001E0780000F0780000F078 0000F0F80000F8F80000F8F80000F8F80000F8F80000F8F80000F8F80000F8F80000F8780000F0 7C0001F03C0001E03C0001E01E0003C01E0003C00F00078007800F0001C01C0000F07800001FC0 001D1F7E9E21>I<0781FC00FF860700FF8803C00F9001E007A000F007C0007807800078078000 3C0780003C0780003E0780001E0780001F0780001F0780001F0780001F0780001F0780001F0780 001F0780001F0780001F0780003E0780003E0780003C0780007C0780007807C000F007A000F007 A001E00798038007860F000781F800078000000780000007800000078000000780000007800000 07800000078000000780000007800000078000000FC00000FFFC0000FFFC0000202D7E9E25>I< 0783E0FF8C18FF907C0F907C07A07C07C03807C00007C00007C000078000078000078000078000 078000078000078000078000078000078000078000078000078000078000078000078000078000 0780000780000FC000FFFE00FFFE00161F7E9E19>114 D<01FC100E03301800F0300070600030 E00030E00010E00010E00010F00010F800007E00003FF0001FFF000FFFC003FFE0003FF00001F8 0000F880003C80003C80001CC0001CC0001CE0001CE00018F00038F00030CC0060C301C080FE00 161F7E9E1A>I<00400000400000400000400000400000C00000C00000C00001C00001C00003C0 0007C0000FC0001FFFE0FFFFE003C00003C00003C00003C00003C00003C00003C00003C00003C0 0003C00003C00003C00003C00003C00003C00003C00003C01003C01003C01003C01003C01003C0 1003C01003C01001C02001E02000E0400078C0001F00142C7FAB19>I<078000F000FF801FF000 FF801FF0000F8001F000078000F000078000F000078000F000078000F000078000F000078000F0 00078000F000078000F000078000F000078000F000078000F000078000F000078000F000078000 F000078000F000078000F000078000F000078000F000078000F000078001F000078001F0000780 01F000038002F00003C004F00001C008F800007030FF80001FC0FF80211F7E9E25>I120 DI E end %%EndProlog %%BeginSetup %%Feature: *Resolution 300 TeXDict begin %%EndSetup %%Page: 1 1 bop 92 242 a Fn(Autonomous)19 b(System)i(P)n(ath)h(Expression)e(Exten)n (t-ion)i(to)g(Rip)r(e-181)462 369 y Fm(Cengiz)16 b(Alaettino\025)-23 b(glu)444 b(Jessica)16 b(Y)l(u)339 427 y Fl(Information)f(Sciences)g (Institute)233 b(Merit)15 b(Net)o(w)o(orking)305 485 y(Univ)o(ersit)o(y)e(of) k(Southern)g(California)146 b(Univ)o(ersit)o(y)14 b(of)i(Mic)o(higan)376 543 y(Marina)g(del)g(Rey)l(,)f(CA)h(90292)233 b(Ann)16 b(Arb)q(or,)g(MI)f (?????)480 601 y Fk(cengiz at is)o(i.e)o(du)394 b(jyy at merit.)o(edu)823 703 y Fl(Marc)o(h)16 b(2,)g(1995)0 876 y Fj(1)69 b(In)n(tro)r(duction)0 978 y Fm(Rip)q(e-181)20 b([Bates)15 b Fi(et)h(al.)p Fm(,)f(1994)o(])k(is)g(a) g(language)h(to)f(sp)q(ecify)h(routing)g(p)q(olicy)h(constrain)o(ts)d(for)h (in)o(ter-domain)0 1034 y(routing)c(in)h(the)f(In)o(ternet.)20 b(Rip)q(e-181)c(allo)o(ws)f(the)g(sp)q(eci\014cation)i(of)d(b)q(oth)h (preference)h(p)q(olicy)h(constrain)o(ts)d(\(b)o(y)0 1091 y(sp)q(ecifying)19 b(as-in)f(and)f(in)o(teras-in)h(attributes\))f(and)g(access)h(con)o(trol)f(p) q(olicy)i(constrain)o(ts)d(\(b)o(y)h(sp)q(ecifying)i(as-)0 1147 y(out)14 b(and)h(in)o(teras-out)f(attributes\).)19 b(There)c(are)f (limitations)i(in)g(the)e(t)o(yp)q(es)h(of)f(preference)i(and)f(access)f(con) o(trol)0 1203 y(p)q(olicy)h(constrain)o(ts)e(that)g(can)g(b)q(e)h(describ)q (ed)h(b)o(y)f(RIPE-181)f(and)h(b)q(ecame)g(eviden)o(t)g(when)g(sev)o(eral)f (en)o(terprises)0 1260 y(tried)j(to)e(use)i(RIPE-181)f(to)g(describ)q(e)h (their)g(routing)f(p)q(olicies.)71 1316 y(One)e(suc)o(h)g(limitation)h(is)g (the)f(lac)o(k)g(of)f(abilit)o(y)i(to)e(sp)q(ecify)i(autonomous)e(system)g (path)h(expressions,)h(hence-)0 1373 y(forth)i(referred)g(to)g(as)f(AS)i (path)f(expressions,)h(in)g(the)f(p)q(olicy)i(attributes)e(\(i.e.)g(as-in,)h (in)o(teras-in,)g(as-out)f(and)0 1429 y(in)o(teras-out)j(attributes\).)31 b(This)19 b(do)q(cumen)o(t)h(extends)f(Rip)q(e-181)h(to)f(enable)h(the)f(sp)q (eci\014cation)i(of)e(AS)g(path)0 1486 y(expressions)d(in)g(these)f (attributes.)20 b(It)15 b(is)h(assumed)f(that)g(the)g(reader)g(is)h(familiar) g(with)g(Rip)q(e-181.)0 1627 y Fj(2)69 b(Extended)23 b(A)n(ttributes)0 1728 y Fm(W)l(e)g(de\014ne)g(four)f(new)h(p)q(olicy)h(attributes)e (extended-as-in,)k(extended-as-out,)f(extended-in)o(teras-in,)h(and)0 1785 y(extended-in)o(teras-out)15 b(to)f(extend)h(the)g(as-in,)g(as-out,)e (in)o(teras-in,)i(and)g(in)o(teras-out)f(attributes)g(resp)q(ectiv)o(ely)l(.) 71 1841 y(The)h(original)h(attributes)f(ha)o(v)o(e)g(the)g(follo)o(wing)h (forms)f([Bates)f Fi(et)i(al.)p Fm(,)f(1994)o(]:)72 1923 y Fh(as-in:)166 b(from)23 b()g()382 1979 y(accept)g()72 2035 y(as-out:)142 b(to)23 b()382 2092 y(announce)g()72 2148 y(interas-in:)46 b(from)23 b()g()f()g()382 2205 y(accept)h()72 2261 y(interas-out:)f(to)h ()g()f()g([])382 2318 y(announce)h(.)0 2399 y Fm(Please)16 b(refer)f(to)f(RIPE-181)i([Bates)e Fi(et)i(al.)p Fm(,)f(1994)o(])g(for)f(the)h(details)i(of)d(their)i(syn)o(tax)f(and)g(seman) o(tics.)71 2456 y(The)21 b(extended)h(attributes)f(ha)o(v)o(e)f(the)i(same)e (syn)o(tax)h(and)g(seman)o(tics)g(as)g(the)g(corresp)q(onding)h(original)0 2512 y(atributes)g(except)h(that)e(the)i Fg(<)p Fh(routing)g(policy)g (expression)p Fg(>)e Fm(is)i(extended.)42 b(That)21 b(is,)j(w)o(e)e(ha)o(v)o (e)g(the)0 2569 y(follo)o(wing)16 b(new)f(syn)o(tax)g(for)f(the)i(extended)g (attributes:)964 2693 y(1)p eop %%Page: 2 2 bop 72 60 a Fh(extended-as-in:)165 b(from)23 b()g()597 117 y(accept)g()72 173 y(extended-as-out:)141 b(to)23 b()597 229 y(announce)f ()72 286 y(extended-interas-in:)45 b(from)23 b()g()f()g()597 342 y(accept)h()72 399 y(extended-interas-out:)e(to)i()g()f()g ([])597 455 y(announce)g(.) 0 546 y Fg(<)p Fh(extended)g(routing)g(policy)g(expression)p Fg(>)16 b Fm(is)i(a)f(logical)i(com)o(bination)f(of)f(AS)h(n)o(um)o(b)q(ers,) f(AS)h(macros,)0 602 y(comm)o(unit)o(y)e(names,)h(route)f(lists,)h (prede\014ned)h(k)o(eyw)o(ords)d(\(curren)o(tly)i(only)g(the)f(k)o(eyw)o(ord) g(ANY)g(is)h(de\014ned\),)0 659 y(and)10 b(AS)h(path)f(expressions.)19 b(The)11 b(syn)o(tax)e(and)i(seman)o(tics)f(of)g Fg(<)p Fh(extended)23 b(routing)g(policy)g(expression)p Fg(>)0 715 y Fm(are)17 b(iden)o(tical)j(to) d(the)g(syn)o(tax)g(and)h(seman)o(tics)f(of)g Fg(<)q Fh(routing)23 b(policy)g(expression)p Fg(>)16 b Fm(except)i(that)f(it)h(can)0 772 y(con)o(tain)10 b(AS)h(path)f(expressions.)19 b(The)10 b(syn)o(tax)g(and)g(seman)o(tics)g(of)g Fg(<)p Fh(extended)23 b(routing)g(policy)g(expression)p Fg(>)71 828 y Fm(An)15 b(AS)h(path)f (expression)h(has)f(the)g(follo)o(wing)h(syn)o(tax:)119 919 y Fh(`<')24 b()h(`>'.)0 1009 y Fm(The)13 b(syn)o(tax)g(and)g(seman)o(tics)g(of)g(AS)g(path)g(regular)g (expressions)h(are)f(the)g(same)f(as)h(the)g(syn)o(tax)g(and)g(seman)o(tics)0 1065 y(of)19 b(AS)h(path)f(regular)h(expressions)g(used)g(in)h(Cisco)e (router)g(con\014gurations.)33 b(Please)20 b(refer)g(to)f(App)q(endix)i(1)0 1122 y(for)16 b(the)h(details.)27 b(An)17 b(AS)g(path)g(expression)h (represen)o(ts)f(the)g(set)g(of)f(routes)h(whic)o(h)h(tra)o(v)o(erses)e(a)g (sequence)i(of)0 1178 y(autonomous)c(systems)h(matc)o(hed)g(b)o(y)g(the)g(AS) h(path)f(regular)g(expression)1286 1162 y Ff(1)1307 1178 y Fm(.)71 1235 y(The)g(follo)o(wing)h(are)f(examples)h(of)f(extended)h (attributes:)72 1325 y Fh(extended-as-in:)21 b(from)j(AS1)f(5)h(accept)f (<^AS1)g(.)h(*)g(AS2$>)f(AND)g(NOT)h()72 1382 y(extended-as-out:)d(to)j (AS690)f(announce)g(\(<^AS1>)g(OR)g(<^AS2>\))g(AND)h(COMM_NSF_AUP.)0 1472 y Fm(The)16 b(\014rst)g(example)h(means)f(\\accept)g(the)g(set)g(of)g (routes)g(from)f(AS1)h(with)h(an)f Fh(AS)p 1441 1472 15 2 v 17 w(PATH)f Fm(to)h(AS2)g(that)f(do)h(not)0 1529 y(transit)e(AS3)g(with)g (preference)h(5.)k(The)14 b(second)h(example)f(means)g(announce)h(the)f(set)g (of)f(routes)h(learned)h(from)0 1585 y(AS1)g(and)h(AS2)f(whic)o(h)h(are)f(in) h(COMM)p 697 1585 14 2 v 16 w(NSF)p 802 1585 V 16 w(A)o(UP)f(to)g(AS690.)0 1728 y Fj(3)69 b(In)n(teraction)22 b(Bet)n(w)n(een)f(Extended)i(and)h (Original)d(A)n(ttributes)0 1829 y Fm(A)e(domain)h(can)g(sp)q(ecify)g(its)g (p)q(olicies)i(using)e(the)f(extended)i(and/or)d(the)i(original)g (attributes.)33 b(T)l(o)19 b(sp)q(ecify)0 1886 y(p)q(olicies)14 b(for)e(a)f(giv)o(en)i(p)q(eer)f(AS,)g(an)g(AS)g(m)o(ust)g(either)g(use)h (only)f(the)g(original)h(attributes,)f(or)f(only)i(the)f(extended)0 1942 y(attributes,)k(or)f(b)q(oth)i(the)f(original)h(and)g(the)f(extended)h (attributes)f(so)g(that)f(an)h(extended)i(attribute)e(is)g(used)0 1999 y(if)g(and)f(only)h(if)f(the)h(corresp)q(onding)g(original)g(attribute)f (is)h(used.)71 2055 y(If)j(a)g(domain)g(mixes)h(the)f(extended)h(and)f(the)g (original)h(attributes)f(for)f(a)h(p)q(eer)h(AS,)f(the)g(to)q(ols)g(that)f (do)0 2111 y(not)f(supp)q(ort)h(the)f(extended)i(attributes)e(use)h(only)g (the)g(original)g(attributes.)27 b(The)18 b(to)q(ols)f(that)g(supp)q(ort)h (the)0 2168 y(extended)j(attributes)e(use)h(only)g(the)g(extended)g (attributes)f(and)h(ignore)g(the)g(original)g(attributes)g(for)f(that)0 2224 y(p)q(eer)d(AS.)f(W)l(e)h(exp)q(ect)g(that)e(all)j(to)q(ols)e(will)i(b)q (e)f(upgraded)f(ev)o(en)o(tually)i(to)d(supp)q(ort)i(the)f(extended)i (attributes.)0 2281 y(A)o(t)e(whic)o(h)h(time,)f(original)h(attributes)f(can) g(b)q(e)h(replaced)h(b)o(y)e(the)g(extended)h(attributes.)71 2337 y(W)l(e)e(advise)i(that,)d(when)i(an)g(AS)g(mixes)g(extended)g(and)g (original)h(attributes)e(for)g(a)g(p)q(eer)i(AS,)e(the)h(original)0 2394 y(attribute)i(and)g(the)g(corresp)q(onding)g(extended)h(attribute)f (matc)o(h)f(in)i(their)f(meaning)h(\(i.e.)24 b(they)17 b(can)g(b)q(e)h(the)p 0 2435 780 2 v 52 2461 a Fe(1)293 2477 y Fd(A)111 b(router)h(can)h(c)o(hec)o (k)f(this)h(using)g(the)f Fc(AS)p 1599 2477 12 2 v 14 w(PATH)e Fd(attribute)0 2523 y(in)17 b(the)g(Border)g(Gatew)o(a)o(y)g(Proto)q(col)h ([Lougheed)c(and)g(Rekh)o(ter,)f(1989)q(])j(or)h Fc(RD)p 1183 2523 V 13 w(PATH)e Fd(attribute)j(in)f(the)g(In)o(ter-Domain)h(Routing)0 2569 y(Proto)q(col)c([Rekh)o(ter,)f(1992)q(])g(\(other)g(proto)q(cols)h(ha)o (v)o(e)g(similar)h(mec)o(hanisms\).)964 2693 y Fm(2)p eop %%Page: 3 3 bop 0 60 a Fm(same)14 b(or)g(p)q(erhaps)i(di\013eren)o(t)e(with)h(the)g(same) f(a\013ect)g(in)i(routing\).)j(Th)o(us,)14 b(if)i(for)e(an)g(extended)i (attribute)e(\(e.g.)0 117 y(extended-as-out\))i(used)g(for)f(a)g(p)q(eer)h (AS)g(there)g(is)g(no)f(matc)o(hing)h(original)g(attribute)g(\(as-out\))e (\(b)q(ecause)i(of)f(a)0 173 y(path)e(expression)h(it)g(con)o(tains\),)f(no)g (original)i(attribute)e(can)h(b)q(e)g(used)g(for)e(that)h(p)q(eer)h(AS.)f (The)h(motiv)m(ation)g(for)0 229 y(this)h(is)g(to)f(a)o(v)o(oid)g(sp)q (ecifying)i(p)q(olicies)h(partially)e(using)h(the)e(original)i(attributes)e (whic)o(h)h(ma)o(y)f(cause)h(incorrect)0 286 y(results.)20 b(Hence)c(the)g(follo)o(wing)g(examples)g(are)e(v)m(alid:)0 377 y Fh(Eg.)23 b(1.)0 434 y(aut-num:)g(AS1)0 490 y(as-in:)g(from)g(AS2)h(1)g (accept)f(ANY)0 547 y(as-out:)g(to)g(AS2)h(announce)f(ANY)0 660 y(Eg.)g(2.)0 716 y(aut-num:)g(AS1)0 773 y(extended-as-in:)f(from)h(AS2)h (1)f(accept)g(ANY)0 829 y(extended-as-out:)f(to)h(AS2)h(announce)e(ANY)0 942 y(Eg.)h(3.)0 998 y(aut-num:)g(AS1)0 1055 y(as-in:)g(from)g(AS2)h(1)g (accept)f(ANY)0 1111 y(as-out:)g(to)g(AS2)h(announce)f(ANY)0 1168 y(extended-as-in:)f(from)h(AS2)h(1)f(accept)g(ANY)0 1224 y(extended-as-out:)f(to)h(AS2)h(announce)e(ANY)71 1316 y Fm(And)c(the)h (follo)o(wing)f(example)h(is)g(not)f(v)m(alid)i(b)q(ecause)f(an)f (extended-as-out)h(attribute)f(is)g(used)h(without)0 1372 y(using)d(an)f (as-out)g(attribute.)0 1464 y Fh(Eg.)23 b(4.)0 1520 y(aut-num:)g(AS1)0 1577 y(as-in:)g(from)g(AS2)h(1)g(accept)f(ANY)0 1633 y(extended-as-in:)f (from)h(AS2)h(1)f(accept)g(ANY)0 1690 y(extended-as-out:)f(to)h(AS2)h (announce)e(ANY)i(and)f(not)h()0 1781 y Fm(Note)11 b(that,)h(it)g(is)g(at)f(the)h(discretion)h(of)f(the)f(AS)i (to)e(decide)i(what)e(is)i(matc)o(hing.)18 b(Hence)13 b(the)f(follo)o(wing)g (example,)0 1838 y(in)j(whic)o(h)f(as-out)f(do)q(es)h(not)g(re\015ect)f(the)h (exact)g(exp)q(ort)f(p)q(olicy)j(of)d(AS1,)h(will)h(b)q(e)f(accepted)h(as)e (v)m(alid.)21 b(W)l(e)14 b(allo)o(w)0 1894 y(this)i(so)e(that)h(the)g (existing)h(to)q(ols)f(can)h(function)g(and)f(pro)q(duce)h(close)g(results)g (at)e(the)i(discretion)g(of)f(the)g(AS.)0 1986 y Fh(Eg.)23 b(6.)0 2042 y(aut-num:)g(AS1)0 2099 y(as-in:)g(from)g(AS2)h(1)g(accept)f(ANY) 0 2155 y(as-out:)g(to)g(AS2)h(announce)f(ANY)g(and)h(not)f(AS10)0 2211 y(extended-as-in:)f(from)h(AS2)h(1)f(accept)g(ANY)0 2268 y(extended-as-out:)f(to)h(AS2)h(announce)e(ANY)i(and)f(not)h()0 2411 y Fj(4)69 b(Suggestions)0 2512 y Fm(W)l(e)17 b(reccomend)g(administrators)f(who)g(register)g(extended)i (attributes)e(to)g(also)g(register)h(original)g(attributes)0 2569 y(when)f(p)q(ossible)h(as)d(explained)k(in)e(Section)g(3.)964 2693 y(3)p eop %%Page: 4 4 bop 71 60 a Fm(W)l(e)21 b(allo)o(w)g(the)h(sp)q(eci\014cation)h(of)d(general) i(AS)f(path)h(expression)g(in)g(extended)g(attributes.)37 b(Ho)o(w)o(ev)o (er,)0 117 y(some)19 b(to)q(ols)f(ma)o(y)h(only)g(supp)q(ort)g(limited)i(AS)e (path)g(regular)g(expressions)h(initially)l(.)34 b(F)l(or)18 b(example,)j(at)d(the)0 173 y(time)j(of)g(writing)h(this)f(do)q(cumen)o(t,)i Fh(peval)e Fm(supp)q(orted)g(only)h(AS)f(path)h(regular)f(expressions)h(of)e (the)i(form)0 229 y(\\)p Fh(^AS-number)p Fm(")286 213 y Ff(2)304 229 y Fm(.)71 286 y(W)l(e)14 b(also)g(caution)h(that)f(sp)q(ecifying)i(AS)f (path)f(p)q(olicy)i(expressions)f(whic)o(h)h(are)e(to)q(o)f(top)q(ology)i(sp) q(eci\014c)h(can)0 342 y(ha)o(v)o(e)g(serious)g(consequences.)24 b(This)17 b(is)f(b)q(ecause)h(In)o(ternet's)f(top)q(ology)g(is)g(dynamic)h (and)g(the)f(c)o(hanges)g(in)h(the)0 399 y(top)q(ology)e(a\013ect)f(the)i (set)f(of)f(routes)h(matc)o(hed)g(b)o(y)g(these)h(expressions)g(drastically)l (.)0 536 y Fj(References)0 627 y Fb([Bates)e Fa(et)h(al.)p Fb(,)e(1994])21 b(T.)d(Bates,)h(E.)f(Geric)o(h,)g(L.)g(Jonc)o(hera)o(y)m(,)g (J-M.)g(Jouanigot,)f(D.)h(Karren)o(b)q(erg,)i(M.)d(T)m(erpstra,)i(and)46 677 y(J.)d(Y)m(u.)25 b(Represen)o(tation)18 b(of)d(IP)i(Routing)e(P)o (olicies)h(in)g(a)g(Routing)g(Registry)m(.)25 b(T)m(ec)o(hnical)16 b(Rep)q(ort)g(rip)q(e-181,)g(RIPE,)46 727 y(RIPE)e(NCC,)f(Amsterdam,)f (Netherlands,)j(Octob)q(er)g(1994.)0 801 y([Lougheed)f(and)g(Rekh)o(ter,)g (1989])21 b(K.)13 b(Lougheed)g(and)g(Y.)f(Rekh)o(ter.)17 b(Border)e(Gatew)o (a)o(y)d(Proto)q(col)h(\(BGP\).)j(Request)e(for)46 851 y(Commen)o(t)d(RF)o (C-1105,)h(Net)o(w)o(ork)i(Information)d(Cen)o(ter,)k(June)g(1989.)0 926 y([Rekh)o(ter,)f(1992])21 b(Y.)11 b(Rekh)o(ter.)k(In)o(ter-Domain)10 b(Routing)h(Proto)q(col)g(\(IDRP\).)k(Av)n(ailable)10 b(from)g(the)i (author.,)f(1992.)j(T.J.)46 976 y(W)m(atson)f(Researc)o(h)i(Cen)o(ter,)g(IBM) f(Corp.)0 1119 y Fj(A)69 b(Syn)n(tax)24 b(of)f(AS)g(P)n(ath)h(Regular)e (Expressions)0 1220 y Fm(NOTE:)12 b(It)h(w)o(as)e(not)h(clear)h(to)f(me)g (whether)g(I)h(could)h(just)e(cop)o(y)g(this)h(app)q(endix)h(from)d(cisco's)i (online)h(do)q(cumen-)0 1277 y(tation)g(for)g(cop)o(yrigh)o(t)h(reasons.)k(I) c(think)g(I)g(can,)g(since)h(they)e(also)h(copied)h(it)f(from)f(a)g(public)j (domain)e(soft)o(w)o(are)0 1333 y(called)k(rgrep\(3\).)26 b(The)18 b(safest)f(w)o(ould)g(b)q(e)i(to)e(cop)o(y)g(it)h(from)f(rgrep)g(or)g (re-write)h(it.)27 b(I)18 b(could)g(not)g(lo)q(cate)g(this)0 1390 y(soft)o(w)o(are)13 b(using)j(arc)o(hie.)21 b(An)o(y)15 b(suggestions?)p 0 2480 780 2 v 52 2507 a Fe(2)91 2523 y Fc(Peval)8 b Fd(is)k(a)f(to)q(ol)h(to)f(ev)n(aluate)h(routing)g(p)q(olicy)h(expressions) h(and)d(is)h(used)f(to)g(generate)h(router)f(con\014gurations.)19 b(Please)12 b(c)o(hec)o(k)0 2568 y(the)h Fc(Peval)e Fd(man)o(ual)j(if)g (general)g(AS)f(path)h(regular)g(expressions)h(are)e(curren)o(tly)i(supp)q (orted.)964 2693 y Fm(4)p eop %%Trailer end userdict /end-hook known{end-hook}if %%EOF -------- Logged at Mon Mar 6 11:02:08 MET 1995 --------- From Daniel.Karrenberg at ripe.net Mon Mar 6 10:49:41 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 06 Mar 1995 10:49:41 +0100 Subject: Databases Synchronization Proposal In-Reply-To: Your message of Fri, 03 Mar 1995 12:34:03 PST. <199503032034.AA08271@cat.isi.edu> Message-ID: <9503060949.AA15662@ncc.ripe.net> > cengiz at ISI.EDU (Cengiz Alaettinoglu) writes: > > I think having a master registry is a good idea. It is not only a good idea but a requirement! You usually do not have distributed notarys either. > A record should not > be registered anywhere if it is not registered at the master > registery. Definitely. If a registry receives an update for a "source:" it is not master for it can either bounce it back or send it on to the correct master with a notification back to the sender. > I think master registry should issue both serial numbers > and time stamps. That is records of the sort: > database serial-number timestamp operation object That would really catch everything. The time stamp will reflect the time of the operation made at the master registry. This will enable everyone to build a database state at a given point in time. This might also be useful for the master itself in case of emergencies! The serial numbers can be used to discover missing updates in case of unreliable transport methods like e-mail. This can then cause a re-fetch of the missing updates via another channel. > These records can be stored for future ftp as diffs or sent around via > email (or both). Exactly. > My 1000 Turkish Liras:-) which is only 2 cents:-( My 5 dutch cents (no smaller coins available). It is still slightly more than 2 US$-cents but slowly getting there ;-). Daniel -------- Logged at Mon Mar 6 16:42:52 MET 1995 --------- From bmanning at ISI.EDU Mon Mar 6 16:41:59 1995 From: bmanning at ISI.EDU (Bill Manning) Date: Mon, 6 Mar 1995 07:41:59 -0800 (PST) Subject: Databases Synchronization Proposal In-Reply-To: <9503060949.AA15662@ncc.ripe.net> from "Daniel Karrenberg" at Mar 6, 95 10:49:41 am Message-ID: <199503061542.AA00264@zephyr.isi.edu> > > > I think having a master registry is a good idea. > > It is not only a good idea but a requirement! You usually do not have > distributed notarys either. I expect that this model will not scale. My limited view sez that this looks like the hosts.txt problem that DNS was invented for. > The serial numbers can be used to discover missing updates in case of > unreliable transport methods like e-mail. This can then cause a > re-fetch of the missing updates via another channel. I expect that the use of an e-mail channel is really bad, unless we have somethign like PEM. --bill -------- Logged at Mon Mar 6 16:49:30 MET 1995 --------- From GeertJan.deGroot at ripe.net Mon Mar 6 16:49:27 1995 From: GeertJan.deGroot at ripe.net (Geert Jan de Groot) Date: Mon, 06 Mar 1995 16:49:27 +0100 Subject: Test two - please ognore again Message-ID: <9503061549.AA19851@ncc.ripe.net> Test two. Sorry folks.. -------- Logged at Mon Mar 6 17:29:05 MET 1995 --------- From GeertJan.deGroot at ripe.net Mon Mar 6 16:48:09 1995 From: GeertJan.deGroot at ripe.net (Geert Jan de Groot) Date: Mon, 06 Mar 1995 16:48:09 +0100 Subject: Test - pse ignore Message-ID: <9503061548.AA19837@ncc.ripe.net> Sorry, but there is no other way to test now. Geert Jan -------- Logged at Mon Mar 6 17:39:17 MET 1995 --------- From bmanning at ISI.EDU Mon Mar 6 17:39:02 1995 From: bmanning at ISI.EDU (Bill Manning) Date: Mon, 6 Mar 1995 08:39:02 -0800 (PST) Subject: Databases Synchronization Proposal In-Reply-To: <9503060949.AA15662@ncc.ripe.net> from "Daniel Karrenberg" at Mar 6, 95 10:49:41 am Message-ID: <199503061639.AA02428@zephyr.isi.edu> Timestamping may be valid. It would help if all participating registries were to agree to use the same timezone... (like PST) -- --bill -------- Logged at Mon Mar 6 17:44:28 MET 1995 --------- From Daniel.Karrenberg at ripe.net Mon Mar 6 17:43:32 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 06 Mar 1995 17:43:32 +0100 Subject: Databases Synchronization Proposal In-Reply-To: Your message of Mon, 06 Mar 1995 07:41:59 PST. <199503061542.AA00264@zephyr.isi.edu> Message-ID: <9503061643.AA20510@ncc.ripe.net> > bmanning at ISI.EDU (Bill Manning) writes: > > > > > I think having a master registry is a good idea. > > > > It is not only a good idea but a requirement! You usually do not have > > distributed notarys either. > > I expect that this model will not scale. My limited view sez that this > looks like the hosts.txt problem that DNS was invented for. It is not at all like hosts.txt. First and foremost: Not every host needs a copy. Queries can be done to a limited set of servers. Then: Incremental updates are possible. The number of objects is significantly lower. There reasons to have a master registry (per source:): Consistency is easier to check and maintain. Authentication is only possible to check. A registry (as in registrar, notary) function is only possible to achieve easily this way. > > The serial numbers can be used to discover missing updates in case of > > unreliable transport methods like e-mail. This can then cause a > > re-fetch of the missing updates via another channel. > > I expect that the use of an e-mail channel is really bad, unless we > have somethign like PEM. Use whatever channel/authenication is appropriate. Use FTP as backup. That's all I say. Daniel -------- Logged at Mon Mar 6 17:52:03 MET 1995 --------- From Daniel.Karrenberg at ripe.net Mon Mar 6 17:45:52 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 06 Mar 1995 17:45:52 +0100 Subject: Databases Synchronization Proposal In-Reply-To: Your message of Mon, 06 Mar 1995 08:39:02 PST. <199503061639.AA02428@zephyr.isi.edu> Message-ID: <9503061645.AA20535@ncc.ripe.net> > bmanning at ISI.EDU (Bill Manning) writes: > > Timestamping may be valid. It would help if all participating registries > were to agree to use the same timezone... (like PST) There is worldwide agreed time for such purposes. It is called UTC. It is available on all good operating systems. Daniel -------- Logged at Mon Mar 6 21:23:14 MET 1995 --------- From Daniel.Karrenberg at ripe.net Mon Mar 6 21:23:11 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 06 Mar 1995 21:23:11 +0100 Subject: AS path extensions In-Reply-To: Your message of Sun, 05 Mar 1995 14:15:31 PST. <199503052215.AA16699@cat.isi.edu> Message-ID: <9503062023.AA00486@ncc.ripe.net> General comments: I think it would be better not to let this be defined by a cisco manual. It is also more than just the regex bit. I would briefly describe it as something like "AS paths are coded textually thus ... and AS Path regular expressions use POSIX 1003.2 section 2.8 regular expressions to match them. The interesting stuff here is AS-sets etc ...... The "Interaction Between ...." section is confusing. Semantically what I would like to see: One can use only orignal or only extended attributes for a given peer AS. The semantics in this case are clear. Once can also use both kinds of attributes for a given peer AS. In this case care should be taken that the expressions are as equivalent as possible and certainly not contradictory. [This is the maximum one can ask and mucho clearer than what you have]. At this point in timew it is strongly recommended to provide original attributes for the benefit of tools that do not understand extended attributes yet. Example 4 contradicts your text in the Interaction para. The as paths are not anchored either ?!? Refer to ripe-181 when cautioning about changing and complex topologies. It explains it all. Daniel -------- Logged at Mon Mar 6 22:51:11 MET 1995 --------- From cengiz at ISI.EDU Mon Mar 6 22:50:43 1995 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Mon, 6 Mar 1995 13:50:43 -0800 Subject: AS path extensions In-Reply-To: <9503062023.AA00486@ncc.ripe.net> References: <199503052215.AA16699@cat.isi.edu> <9503062023.AA00486@ncc.ripe.net> Message-ID: <199503062150.AA20786@cat.isi.edu> Thanks. I will look into your suggestions and make the text more clear. Daniel Karrenberg (Daniel.Karrenberg at ripe.net) on March 6: > > General comments: > > I think it would be better not to let this be defined by a cisco > manual. It is also more than just the regex bit. I would briefly describe > it as something like "AS paths are coded textually thus ... and AS Path regular > expressions use POSIX 1003.2 section 2.8 regular expressions to match them. > The interesting stuff here is AS-sets etc ...... > > The "Interaction Between ...." section is confusing. > Semantically what I would like to see: > > One can use only orignal or only extended attributes for a given peer AS. > The semantics in this case are clear. > > Once can also use both kinds of attributes for a given peer AS. > In this case care should be taken that the expressions are as > equivalent as possible and certainly not contradictory. > [This is the maximum one can ask and mucho clearer than what you have]. > > At this point in timew it is strongly recommended to provide original > attributes for the benefit of tools that do not understand extended > attributes yet. > > Example 4 contradicts your text in the Interaction para. > The as paths are not anchored either ?!? > > Refer to ripe-181 when cautioning about changing and complex topologies. > It explains it all. > > Daniel > > > Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California -------- Logged at Mon Mar 6 23:21:36 MET 1995 --------- From jyy at merit.edu Mon Mar 6 23:21:27 1995 From: jyy at merit.edu (Jessica Yu (Jie Yun)) Date: Mon, 06 Mar 1995 17:21:27 -0500 Subject: AS path extensions In-Reply-To: Your message of "Mon, 06 Mar 1995 21:23:11 +0100." <9503062023.AA00486@ncc.ripe.net> Message-ID: <199503062221.RAA08269@home.merit.edu> Daniel, Thanks for the comements. >I think it would be better not to let this be defined by a cisco >manual. The reason we propose to use cisco notation for ASpath is that it has large 'installed base'. Network operators understand it and are using it. >The "Interaction Between ...." section is confusing. >Semantically what I would like to see: >One can use only orignal or only extended attributes for a given peer AS. >The semantics in this case are clear. >Once can also use both kinds of attributes for a given peer AS. >In this case care should be taken that the expressions are as >equivalent as possible and certainly not contradictory. >[This is the maximum one can ask and mucho clearer than what you have]. >At this point in timew it is strongly recommended to provide original >attributes for the benefit of tools that do not understand extended >attributes yet. Good suggestion. It does make it clear. >Example 4 contradicts your text in the Interaction para. >The as paths are not anchored either ?!? Note, Example 4 is to show an invalid object as stated in the text above it. But there is a typo afterwords: 'E.g. 6' should be 'E.g. 5'. --Jessica -------- Logged at Tue Mar 7 09:14:46 MET 1995 --------- From Daniel.Karrenberg at ripe.net Tue Mar 7 09:14:44 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 07 Mar 1995 09:14:44 +0100 Subject: AS path extensions In-Reply-To: Your message of Mon, 06 Mar 1995 17:21:27 EST. <199503062221.RAA08269@home.merit.edu> Message-ID: <9503070814.AA04199@ncc.ripe.net> > Jessica (Jie Yun) Yu writes: > > The reason we propose to use cisco notation for ASpath is that it has large > 'installed base'. Network operators understand it and are using it. I am not saying "do not use it". I am saying "do not refer to vendor documentation". > >Example 4 contradicts your text in the Interaction para. > >The as paths are not anchored either ?!? > > Note, Example 4 is to show an invalid object as stated in the text above it > . I still do not understand why it is invalid. Also: Shouldn't the paths be anhored with ^ and $? > But there is a typo afterwords: 'E.g. 6' should be 'E.g. 5'. Yep. Daniel -------- Logged at Tue Mar 7 18:52:06 MET 1995 --------- From jyy at merit.edu Tue Mar 7 18:51:57 1995 From: jyy at merit.edu (Jessica Yu (Jie Yun)) Date: Tue, 07 Mar 1995 12:51:57 -0500 Subject: AS path extensions In-Reply-To: Your message of "Tue, 07 Mar 1995 09:14:44 +0100." <9503070814.AA04199@ncc.ripe.net> Message-ID: <199503071752.MAA04683@home.merit.edu> >I am not saying "do not use it". I am saying "do not refer to vendor >documentation". Ok. >> Note, Example 4 is to show an invalid object as stated in the text above it >I still do not understand why it is invalid. Eg. 4 doesn't hasve as-out. --Jessica -------- Logged at Tue Mar 7 19:15:42 MET 1995 --------- From Daniel.Karrenberg at ripe.net Tue Mar 7 19:15:41 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 07 Mar 1995 19:15:41 +0100 Subject: AS path extensions In-Reply-To: Your message of Tue, 07 Mar 1995 12:51:57 EST. <199503071752.MAA04683@home.merit.edu> Message-ID: <9503071815.AA09695@ncc.ripe.net> > Jessica (Jie Yun) Yu writes: > > > >> Note, Example 4 is to show an invalid object as stated in the text above > it > > >I still do not understand why it is invalid. > > Eg. 4 doesn't hasve as-out. This is "not recommended" but not invalid according to two messages back? Or am I dense? Daniel -------- Logged at Wed Mar 8 20:56:40 MET 1995 --------- From curtis at ans.net Wed Mar 8 20:37:25 1995 From: curtis at ans.net (Curtis Villamizar) Date: Wed, 08 Mar 1995 14:37:25 -0500 Subject: AS path extensions In-Reply-To: Your message of "Sun, 05 Mar 1995 14:15:31 PST." <199503052215.AA16699@cat.isi.edu> Message-ID: <199503081938.OAA00804@curtis.ansremote.com> In message <199503052215.AA16699 at cat.isi.edu>, Cengiz Alaettinoglu writes: > > Hi, > > Here is the latest document on this extension. Comments are > welcome. Thanks. > > I do not remember if I have already sent this. I am sorry if I did so. > > Cengiz Cengiz, Thanks for the doc. I think the Cisco syntax is also known as the Yakov memorial AS path syntax. It is documented in the gated config section as well. See: http://www.gated.cornell.edu http://www.gated.cornell.edu//gated-R3_5Alpha_9/config_guide/aspath.html If Cisco is using a different syntax, then don't use it. Use the syntax in RFC 1164 (same as gated syntax). The gated config section describes this concisely. You can just cite the RFC or duplicate it. Curtis The gated syntax is below: [ ... ] AS path regular expressions Technically, an AS path regular expression is a regular expression with the alphabet being the set of AS numbers. An AS path regular expression is composed of one or more AS paths expressions. An AS path expressions is composed of AS path terms and AS path operators. AS path terms An AS path term is one of the following three objects: autonomous_system . ( aspath_regexp ) autonomous_system Is any valid autonomous system number, from one through 65534 inclusive. . matches any autonomous system number. ( aspath_regexp ) parentheses group subexpressions--an operator, such as * or ? works on a single element or on a regular expression enclosed in parentheses AS path operators An AS path operator is one of the following: aspath_term {m,n} aspath_term {m} aspath_term {m,} aspath_term * aspath_term + aspath_term ? aspath_term | aspath_term aspath_term {m,n} a regular expression followed by {m,n} (where m and n are both non-negative integers and m <= n) means at least m and at most n repetitions. aspath_term {m} a regular expression followed by {m} (where m is a positive integer) means exactly m repetitions. aspath_term {m,} a regular expression followed by {m,} (where m is a positive integer) means m or more repetitions. aspath_term * an AS path term followed by * means zero or more repetitions. This is shorthand for {0,}. aspath_term + a regular expression followed by + means one or more repetitions. This is shorthand for {1,}. aspath_term ? a regular expression followed by ? means zero or one repetition. This is shorthand for {0,1}. aspath_term | aspath_term matches the AS term on the left, or the AS term on the right. Last updated 1994/03/16 21:38:07. gated at gated.cornell.edu -------- Logged at Thu Mar 9 05:22:19 MET 1995 --------- From bmanning at ISI.EDU Thu Mar 9 05:19:13 1995 From: bmanning at ISI.EDU (Bill Manning) Date: Wed, 8 Mar 1995 20:19:13 -0800 (PST) Subject: Databases Synchronization Proposal In-Reply-To: <199503090217.AA14310@zen.isi.edu> from "postel@ISI.EDU" at Mar 8, 95 06:17:05 pm Message-ID: <199503090419.AA00618@zephyr.isi.edu> > > If you want to do timestamping you need synchronized clocks (use NTP) and > you need to agree to run at least your timestampers in the same time zone. > The right choice of time zone is UTC. > > --jon. All very true. However... we can't mandate that everyone particpating the the IRR run an NTP syncronized server where their portion of the DB sits. (as an aside, PST or WET is just as good as UTC nee GMT, as long as we all agree.) I expect that what we really want is something more along the lines of the work being done in the dynamic update/ Incremental transfer areas of BIND... It even includes some neato things like authentication of specific RR's. And as I recall, DNS does not require NTP syncronized servers... at least not yet :) --bill -------- Logged at Thu Mar 9 11:15:50 MET 1995 --------- From Daniel.Karrenberg at ripe.net Thu Mar 9 11:15:47 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 09 Mar 1995 11:15:47 +0100 Subject: AS path extensions In-Reply-To: Your message of Wed, 08 Mar 1995 14:37:25 EST. <199503081938.OAA00804@curtis.ansremote.com> Message-ID: <9503091015.AA25169@ncc.ripe.net> > Curtis Villamizar writes: > > If Cisco is using a different syntax, then don't use it. Use the > syntax in RFC 1164 (same as gated syntax). The gated config section > describes this concisely. You can just cite the RFC or duplicate it. It is section 4.2 in RFC1164 which defines much more than the AS path syntax. so it might be better to lift just that. Incidentally: How is this dealing with AS sets? Daniel -------- Logged at Thu Mar 9 20:04:10 MET 1995 --------- From cengiz at ISI.EDU Thu Mar 9 20:03:39 1995 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Thu, 9 Mar 1995 11:03:39 -0800 Subject: RPS BOF Message-ID: <199503091903.AA06657@cat.isi.edu> Couple of notes: 1) RPS BOF is on Thursday morning 0900-1130. At the moment is slotted for mbone coverage. 2) rps mailing list is created and I will add everyone on rr-impl and ra-team to this list. If you do not want to be included let me know. Thanks. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California -------- Logged at Fri Mar 10 04:44:04 MET 1995 --------- From curtis at ans.net Fri Mar 10 04:30:12 1995 From: curtis at ans.net (Curtis Villamizar) Date: Thu, 09 Mar 1995 22:30:12 -0500 Subject: AS path extensions In-Reply-To: Your message of "Thu, 09 Mar 1995 11:15:47 +0100." <9503091015.AA25169@ncc.ripe.net> Message-ID: <199503100331.WAA01139@curtis.ansremote.com> In message <9503091015.AA25169 at ncc.ripe.net>, Daniel Karrenberg writes: > > > Curtis Villamizar writes: > > > > If Cisco is using a different syntax, then don't use it. Use the > > syntax in RFC 1164 (same as gated syntax). The gated config section > > describes this concisely. You can just cite the RFC or duplicate it. > > It is section 4.2 in RFC1164 which defines much more than the AS path syntax. > so it might be better to lift just that. > > Incidentally: How is this dealing with AS sets? > > Daniel Good question. I'm not sure how gated deals with this, since the as_path_data seems to be an array of u_short and aspath_regex_match takes a pointer to an array of as_t (u_int16). In general, I'd say any one of the AS in the set should match at that position. Curtis -------- Logged at Fri Mar 10 13:51:32 MET 1995 --------- From Daniel.Karrenberg at ripe.net Fri Mar 10 13:47:35 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 10 Mar 1995 13:47:35 +0100 Subject: Databases Synchronization Proposal In-Reply-To: Your message of Wed, 08 Mar 1995 20:19:13 PST. <199503090419.AA00618@zephyr.isi.edu> Message-ID: <9503101250.AA06741@ncc.ripe.net> > bmanning at ISI.EDU (Bill Manning) writes: > > > > If you want to do timestamping you need synchronized clocks (use NTP) and > > you need to agree to run at least your timestampers in the same time zone > . > > The right choice of time zone is UTC. > > > > --jon. > > All very true. However... we can't mandate that everyone particpating the > the IRR run an NTP syncronized server where their portion of the DB sits. > (as an aside, PST or WET is just as good as UTC nee GMT, as long as we all > agree.) > > I expect that what we really want is something more along the lines of > the work being done in the dynamic update/ Incremental transfer areas > of BIND... It even includes some neato things like authentication of > specific RR's. And as I recall, DNS does not require NTP syncronized > servers... at least not yet :) Bill, Jon, don't do overkill yet! An expedient and sufficient soloution is to use sequence numbers to detect missing and out-of-order updates and a timestamp to be able to roughly synchronise databases in time. This does not need millisecond or even second accuracy, does it? Daniel -------- Logged at Fri Mar 10 20:42:14 MET 1995 --------- From dsj at merit.edu Fri Mar 10 20:42:06 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Fri, 10 Mar 1995 14:42:06 -0500 Subject: Whois server not returning duplicate route objects Message-ID: <199503101942.OAA10653@home.merit.edu> All, Just a quick check to see if anyone has seen this bug before before we go chasing it: The whois server we are running on whois.ra.net (RIPE code and patches--no local mods) seems to return only one route object per database, even when there are more than one (with different origin ASs) in the database. RIPE's and MCI's whois servers do not have this problem. Has anyone seen this problem before? (Details below). --Dale ===================== > I don't have any idea off hand why this should behave differently. > I dont think we have changed anything that would affect this. > > One possibility is that there is a patch that we missed. > To my knowledge I installed them all, but... > > maybe someone could write a little routine to go thru the > /ra/ripe181/lib and /bin directories and extract a table of > filename version > and then compare ours to ripes, say. > > Another possibility is that there is some flag to control > this and somehow we have a different default value. > Maybe someone could check the flags the ripe whois allows > now and see if one is relevant to this problem. > > I can look more at this next week if someone else > doens't get to it. > - r > > -------- > > > From: "Dale S. Johnson" > > To: rrgroup > > > Rick, David, > > > > Craig has just pointed up an error in the way our RIPE whois server is > > behaving. There are a number of route objects with the same prefix but > > different origin ASs. This is legal. MCI's and RIPE's whois servers > > return both instances of the object, but ours returns only one. > > > > Any ideas? > > > > > > > (dsj at radb2: 76) ripe 193.226.47.0/24 > > > inetnum: 193.226.47.0 > > > netname: IMT-NET > > > descr: Institute for Microtechnology > > > country: RO > > > admin-c: Dascalu > > > tech-c: Dascalu > > > changed: estaicut at roearn.ici.ro 931005 > > > changed: wilfried.woeber at cc.univie.ac.at 931217 > > > source: RIPE > > > > > > route: 193.226.47.0/24 <-------- first > > > descr: RNC, Romanian National Computer Network for Research and Educati > on > > > origin: AS3233 > > > mnt-by: AS3233-MNT > > > changed: estaicut at roearn.ici.ro 950222 > > > source: RIPE > > > > > > route: 193.226.47.0/24 <-------- second > > > descr: IMT-NET > > > origin: AS760 > > > mnt-by: AS760-MNT > > > changed: ripe-dbm at ripe.net 941121 > > > source: RIPE > > > > > > person: Dascalu > > > address: Institute for Microtechnology > > > address: Romanian Academy > > > address: Splaiul Independentei 313, Sector 6 > > > address: Bucarest > > > address: Romania > > > phone: +40-1-6315331 > > > fax-no: +40-1-3124661 > > > e-mail: dascalu at roearn.ici.ro > > > changed: estaicut at roearn.ici.ro 931005 > > > source: RIPE > > > > > > (dsj at radb2: 77) ra 193.226.47.0/24 > > > route: 193.226.47.0/24 > > > descr: RNC, Romanian National Computer Network for Research and Educati > on > > > origin: AS3233 <----------------- first only > > > mnt-by: AS3233-MNT > > > changed: estaicut at roearn.ici.ro 950222 > > > source: RIPE > > > > > > route: 193.226.47.0/24 > > > descr: Institute for Microtechnology > > > descr: Romanian Academy > > > descr: Splaiul Independentei 313 > > > descr: Sector 6 > > > descr: ROMANIA > > > origin: AS760 > > > comm-list: COMM_NSFNET > > > advisory: AS690 1:1133 2:1800 3:1240 > > > mnt-by: MAINT-AS760 > > > changed: nsfnet-admin at merit.edu 931217 > > > source: PRDB > > > > > > (dsj at radb2: 78) agrep -d '$$' 193.226.47.0/24 d-ripe/ripe.db > > > > > > *rt: 193.226.47.0/24 <--------- There are two in our ripe.db! > > > *de: IMT-NET > > > *or: AS760 > > > *mb: AS760-MNT > > > *ch: ripe-dbm at ripe.net 941121 > > > *so: RIPE > > > > > > *rt: 193.226.47.0/24 > > > *de: RNC, Romanian National Computer Network for Research and Education > > > *or: AS3233 > > > *mb: AS3233-MNT > > > *ch: estaicut at roearn.ici.ro 950222 > > > *so: RIPE > > > (dsj at radb2: 79) > -------- Logged at Mon Mar 13 18:55:00 MET 1995 --------- From dsj at merit.edu Mon Mar 13 18:54:54 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Mon, 13 Mar 1995 12:54:54 -0500 Subject: Status and distribution of RIPE client (etc) Message-ID: <199503131754.MAA16322@home.merit.edu> Hi, We'd like to be able to point uses to the RIPE whois client, so that they can use the "-L" and "-M" flags. 1) What is the status of the release? The copy we have from our distribution does not have an RCS ID, and it does have the disclaimer: # This is a very simple whois client, but it knows the new server arguments # No support yet, use if you wish Is there anything newer out or planned? (Or are there plans to bless this version?) 2) Where does the release live? We got ours out of the RIPE code distribution, but we probably don't want to refer end-users to that. I didn't see it in the PRIDE distribution. Does this belong under a RIPE directory, or somewhere else. [As we develop more IRR tools, how can/should we package them. Currently RIPE and PRIDE are held separate; RA/ISI and dbserver releases have ended up under different directory structures; and there are still assorted things like whois and aggis that aren't under any of these. Is there a philosophy all ready in place that I don't know of? Is it still important to keep a PRIDE identity separate from others? Suggestions for a tools repository layout?] --Dale ============ From: K.A. Long > From klong at nysernet.ORG Mon Mar 13 11:16:35 1995 > Date: Mon, 13 Mar 1995 11:15:24 -0500 > To: merit-ie at merit.edu > Subject: twain.merit.edu to radb.ra.net > > > Hi Merit folks, > > I've noticed some differences between the radb and the prdb and > I was wondering if the radb was going to have these functions > added at a later time. > > One function that I use quite a bit on twain is the 'aggis' > checker. I use that all the time to make sure that the nets get > submitted with the correct aggregate and I just cut/paste from > my screen output. The other function that is on twain but not on > radb is the 'aggchk' function. > > Both of these are quite useful to me and I'm hoping that I will > still be able to find them when the radb is the authority. > > > Thanks! > > klong -------- Logged at Mon Mar 13 19:11:32 MET 1995 --------- From dsj at merit.edu Mon Mar 13 19:11:28 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Mon, 13 Mar 1995 13:11:28 -0500 Subject: more whois Message-ID: <199503131811.NAA17120@home.merit.edu> While we're at it, it would be *really* nice if the whois -h allowed "whois -h ". --Dale > From dsj Mon Mar 13 12:54:54 1995 > To: rr-impl > Subject: Status and distribution of RIPE client (etc) > > Hi, > > We'd like to be able to point uses to the RIPE whois client, so that they > can use the "-L" and "-M" flags. > > 1) What is the status of the release? The copy we have from our > distribution does not have an RCS ID, and it does have the > disclaimer: > > # This is a very simple whois client, but it knows the new server arguments > # No support yet, use if you wish > > Is there anything newer out or planned? (Or are there plans to bless > this version?) > > 2) Where does the release live? We got ours out of the RIPE code > distribution, but we probably don't want to refer end-users to > that. I didn't see it in the PRIDE distribution. Does this > belong under a RIPE directory, or somewhere else. > > [As we develop more IRR tools, how can/should we package them. > Currently RIPE and PRIDE are held separate; RA/ISI and dbserver > releases have ended up under different directory structures; > and there are still assorted things like whois and aggis that > aren't under any of these. Is there a philosophy all ready > in place that I don't know of? Is it still important to keep > a PRIDE identity separate from others? > > Suggestions for a tools repository layout?] > > --Dale > > > ============ From: K.A. Long > > > From klong at nysernet.ORG Mon Mar 13 11:16:35 1995 > > Date: Mon, 13 Mar 1995 11:15:24 -0500 > > To: merit-ie at merit.edu > > Subject: twain.merit.edu to radb.ra.net > > > > > > Hi Merit folks, > > > > I've noticed some differences between the radb and the prdb and > > I was wondering if the radb was going to have these functions > > added at a later time. > > > > One function that I use quite a bit on twain is the 'aggis' > > checker. I use that all the time to make sure that the nets get > > submitted with the correct aggregate and I just cut/paste from > > my screen output. The other function that is on twain but not on > > radb is the 'aggchk' function. > > > > Both of these are quite useful to me and I'm hoping that I will > > still be able to find them when the radb is the authority. > > > > > > Thanks! > > > > klong -------- Logged at Mon Mar 13 23:16:29 MET 1995 --------- From cengiz at ISI.EDU Mon Mar 13 23:15:59 1995 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Mon, 13 Mar 1995 14:15:59 -0800 Subject: AS path extensions In-Reply-To: <199503081938.OAA00804@curtis.ansremote.com> References: <199503052215.AA16699@cat.isi.edu> <199503081938.OAA00804@curtis.ansremote.com> Message-ID: <199503132215.AA15414@cat.isi.edu> Curtis Villamizar (curtis at ans.net) on March 8: > Thanks for the doc. I think the Cisco syntax is also known as the > Yakov memorial AS path syntax. It is documented in the gated config > section as well. See: > > http://www.gated.cornell.edu > http://www.gated.cornell.edu//gated-R3_5Alpha_9/config_guide/aspath.html > > If Cisco is using a different syntax, then don't use it. Use the > syntax in RFC 1164 (same as gated syntax). The gated config section > describes this concisely. You can just cite the RFC or duplicate it. Curtis, Cisco is using a different syntax which is closer to grep. However, gated's as path syntax misses a feature that I think is important. Perhaps I should use the posix syntax as Daniel suggested. This mail sounds like suggestions to improve gated's as path pattern syntax. Hence I have CC'ed to gated-alpha. Here are my reasons why I do not want to use that syntax. Perhaps my understanding of gated syntax is wrong or perhaps there are undocumented features. Any suggestions are welcome. It is not possible to specify ranges, and negation of ranges (i.e. [AS1 - AS100] or [^AS1]). I do not think one can specify an as path expression for "as paths not containing AS100" without listing all 65K AS numbers in that expression. This would be "^[^AS100]*$". There are other advantages of ranges, they reduce the number of states in the compiled pattern. Apparently, gated internals do support ranges. I asked this feature to be present in our route server implementation. Ramesh hacked gated, we can now specify ranges like (AS1 - AS100), and above as path expression can be written as "(AS1 - AS99 | AS101 - AS65535)*". This is a short term fix. I think more grep like syntax is desired. Since we are at it, and you are the one who implemented as path matching in gated (correct me if I am wrong), there is another feature in gated that I had to find a fix around. Perhaps there is a better way of doing it. Again suggestions are very much appreciated. Lets say we want to import routes as follows: extended-as-in: AS1 1 as-path-exp-1 AND net-list-1 extended-as-in: AS1 2 as-path-exp-2 AND net-list-2 The ordering of these two terms in gated config file is very important since gated stops after finding the first as path match. But there can be as paths which are matched by the both expressions. That is, there is no correct ordering. My solution to this was to generate a config file with the following: import as-path-exp-1 intersection as-paths-exp-2 net-list-1 pref 1 net-list-2 setminus net-list-1 pref 2 all restrict import as-path-exp-1 net-list-1 pref 1 all restrict import as-paths-exp-2 net-list-2 pref 2 all restrict (The intersection above is a regular-expression-intersection, i.e. given two regular-expressions, it returns a regular-expression which matches the strings which are matched by both regular-expressions), and is done during the config file generation. This works. However, it is very expensive. It can create 2^n import statements in gated if there are n regular-expressions in the original expression. In practise, I do not expect a big growth since many intersections will evaluate to empty regular-expressions and need not be written to the config file. However, the computation requirements of the config file generation is still exponential. A good way to solve this would involve changes to gated. That is: 1) do not add "all restrict" by default to each import statement 2) continue looking for other as-path matches after matching an as-path and there is no explicit address prefix match 3) add an import statement with ".*" as path expression and "all restrict" network list to the end of import statements so that by default all routes are rejected. What do you think? Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California -------- Logged at Mon Mar 13 23:29:28 MET 1995 --------- From dsj at merit.edu Mon Mar 13 23:29:22 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Mon, 13 Mar 1995 17:29:22 -0500 Subject: Using the NIC for IRR contact lists Message-ID: <199503132229.RAA28365@home.merit.edu> Bill, > From bmanning at ISI.EDU Mon Mar 13 17:11:42 1995 > Subject: Re: more whois > To: dsj at merit.edu (Dale S. Johnson) > Date: Mon, 13 Mar 1995 14:10:39 -0800 (PST) > Cc: bmanning at ISI.EDU (Bill Manning) > > > Hi, > I talked w/ Andrew P. yesterday and he asked if we (the RA) could > resurect the ASxxx at ra.net ASxxx-trouble at ra.net aliases > from the old Merit archives and have a script that builds new ones > from the RADB... > > Can we do this? Your terminology has me confused, but the answer might be close to "we're all ready doing a poor man's version of this (and have long-term goals)". The "ASxxx at merit.edu" and "ASxxx-techs at merit.edu" lists that existed up to last January still exist, though they are going stale through lack of maintenance. We do have "ASxxx at ra.net" lists. They are in place now, though I'm unhappy enough with the algorithm that I haven't pushed making them public. Here's the problem: We don't maintain contact information any more under the RA. This is supposed to be a NIC job. What we would *like* to do is get the NIC to agree to give NIC handles and accept registrations from anyone who is appropriate to have an entry in the IRR, and then to use their NIC information as the contact information. (They can put their NIC handle directly in the AS/Route/Maintainer objects). Where we are today is that the only information we keep is email addresses of the contacts, as part of MAIL-FROM lines in the maintainers. Those will be stable until the PRDB gets turned off (because they are also used as the authority records for people submitting NACRs), but even they will go bad in a hurry as all the responsible ASs quickly remove their MAIL-FROM lines and replace them with something more secure (like CRYPT-PW or PGP). What gets loaded into the ASxxx at ra.net today is just the mail-from lines, but, as I say, that system is weak and about to get much weaker. The solution of record is to tie the IRR in closely with the NIC. At that point we can grep the NIC contact information to reestablish good asXXX email lists. But not until that happens. I think these lists are still real useful in the short run, so it would be really good if we could get something in place quick. --Dale -------- Logged at Tue Mar 14 02:46:51 MET 1995 --------- From dennis at mci.net Tue Mar 14 02:46:41 1995 From: dennis at mci.net (Dennis Ferguson) Date: Mon, 13 Mar 1995 20:46:41 -0500 Subject: AS path extensions In-Reply-To: Your message of "Mon, 13 Mar 1995 14:15:59 PST." <199503132215.AA15414@cat.isi.edu> Message-ID: <199503140146.UAA25354@ns.mci.net> Cengiz, > Cisco is using a different syntax which is closer to grep. However, > gated's as path syntax misses a feature that I think is important. > Perhaps I should use the posix syntax as Daniel suggested. [...] > It is not possible to specify ranges, and negation of ranges > (i.e. [AS1 - AS100] or [^AS1]). I do not think one can specify an as > path expression for "as paths not containing AS100" without listing > all 65K AS numbers in that expression. This would be > "^[^AS100]*$". There are other advantages of ranges, they reduce the > number of states in the compiled pattern. I'm currently independently reworking some of this stuff for a gated v4.0 someday. I've included negation, so the above pattern becomes (I think) "(!100)*". Ranges are not supported, not necessarily because they couldn't be supported within the syntax but rather because I'm having difficulty figuring out why one would want them other than to hack around the lack of negation. Note that your last sentence isn't true for my reimplementation (I'm not even sure it was before), ranges don't reduce the number of states in the compiled pattern compared to or'd lists. Since long lists of |'d AS numbers occur frequently, patterns of the form ( 86 | 200 | 201 | ... ) also compile to a single state in the DFA in a data structure which makes the actual match pretty fast. > AS65535)*". This is a short term fix. I think more grep like syntax is > desired. I can't figure out the grep-like part. I'm pretty sure there is nothing which can be written in grep-like syntax which can't be represented in the syntax gated uses, and I suspect the reverse probably true as well (with some proviso's, for example it isn't clear to me how one would do .* (1239 | 1240 | (86 179)) in grep without blowing it out to multiple lines, and multiple line regexp's will very likely be either harder to compile efficiently or slower to execute). I think you're complaining about features rather than syntax, features can be added to either syntax. The other thing the reimplementation does is attempt to do something with AS sets. In particular, 86 .* [200 201 .*] matches a path beginning with 86 (or a set which includes 86) and ending with a set which includes at least 200 and 201. [86] .* [200 201] matches a path with an initial sequence starting with AS 86 and ending with a set of exactly 200 and 201. > Lets say we want to import routes as follows: > extended-as-in: AS1 1 as-path-exp-1 AND net-list-1 > extended-as-in: AS1 2 as-path-exp-2 AND net-list-2 [...] > My solution to this was to generate a config file with the following: > import as-path-exp-1 intersection as-paths-exp-2 > net-list-1 pref 1 > net-list-2 setminus net-list-1 pref 2 > all restrict > import as-path-exp-1 > net-list-1 pref 1 > all restrict > import as-paths-exp-2 > net-list-2 pref 2 > all restrict I do this as import as-path-exp-1 preference 1 { net ... net ... all continue ; } ; import as-paths-exp-2 preference 2 { net ... net ... all restrict ; } ; Dennis -------- Logged at Tue Mar 14 03:53:06 MET 1995 --------- From curtis at ans.net Tue Mar 14 03:44:30 1995 From: curtis at ans.net (Curtis Villamizar) Date: Mon, 13 Mar 1995 21:44:30 -0500 Subject: AS path extensions In-Reply-To: Your message of "Mon, 13 Mar 1995 14:15:59 PST." <199503132215.AA15414@cat.isi.edu> Message-ID: <199503140245.VAA00577@curtis.ansremote.com> In message <199503132215.AA15414 at cat.isi.edu>, Cengiz Alaettinoglu writes: > > It is not possible to specify ranges, and negation of ranges > (i.e. [AS1 - AS100] or [^AS1]). I do not think one can specify an as > path expression for "as paths not containing AS100" without listing > all 65K AS numbers in that expression. This would be > "^[^AS100]*$". There are other advantages of ranges, they reduce the > number of states in the compiled pattern. Ranges would be nice. As far as reducing states, this is not the case, since gated internals automatically builds ranges where appropriate. > Apparently, gated internals do support ranges. I asked this > feature to be present in our route server implementation. Ramesh > hacked gated, we can now specify ranges like (AS1 - AS100), and above > as path expression can be written as "(AS1 - AS99 | AS101 - > AS65535)*". This is a short term fix. I think more grep like syntax is > desired. If you add ranges, POSIX and gated syntax have essentially the same capability and in many cases the same operators. In fact, could you point out which ones are different: . match anything * zero to many + one to many ? zero or one () grouping | logical OR gated also has {m,n} {m} {m,} POSIX has ^ negate [] equiv () with | - range when used within [] These would be easy to add to the parse and hook back into the asmatch code. > Since we are at it, and you are the one who implemented as path > matching in gated (correct me if I am wrong), there is another feature > in gated that I had to find a fix around. Perhaps there is a better > way of doing it. Again suggestions are very much appreciated. > > Lets say we want to import routes as follows: > extended-as-in: AS1 1 as-path-exp-1 AND net-list-1 > extended-as-in: AS1 2 as-path-exp-2 AND net-list-2 > The ordering of these two terms in gated config file is very important > since gated stops after finding the first as path match. But there can > be as paths which are matched by the both expressions. That is, there > is no correct ordering. This is not gated syntax, but extended ripe-181 with gated AS matching. Code exists for this? OK. > My solution to this was to generate a config file with the following: > import as-path-exp-1 intersection as-paths-exp-2 > net-list-1 pref 1 > net-list-2 setminus net-list-1 pref 2 > all restrict > import as-path-exp-1 > net-list-1 pref 1 > all restrict > import as-paths-exp-2 > net-list-2 pref 2 > all restrict > (The intersection above is a regular-expression-intersection, > i.e. given two regular-expressions, it returns a regular-expression > which matches the strings which are matched by both > regular-expressions), and is done during the config file generation. A union is written into aspath_merge_regex. I don't think intersection would be too hard. Somehow I don't think that is the best or easiest solution. How about: import as-path-exp-1 net-list-1 pref 1 all continue; import as-paths-exp-2 net-list-2 pref 2 all restrict; > This works. However, it is very expensive. It can create 2^n import > statements in gated if there are n regular-expressions in the original > expression. In practise, I do not expect a big growth since many > intersections will evaluate to empty regular-expressions and need not > be written to the config file. However, the computation requirements > of the config file generation is still exponential. I get it now. You are converting from extended-as-in: to gated syntax and concerned about the gated first match way of doing policy. You have to keep in mind that gated is designed to make it easy for gated to run fast at run time, and not to make your life easy. Gated will match and stop at first match to save time. If this becomes a hardship (n becomes large), the config syntax could be changed so you could make a specification like the extended ripe-181 and the machinery gets built at run time more like what gated needs to run fast. Don't ask who does this or when it gets done. > A good way to solve this would involve changes to gated. That is: > 1) do not add "all restrict" by default to each import > statement > 2) continue looking for other as-path matches after matching > an as-path and there is no explicit address prefix match > 3) add an import statement with ".*" as path expression and > "all restrict" network list to the end of import statements > so that by default all routes are rejected. > > What do you think? The code was designed to allow an action to be tagged on to the end of the search process, so you could do a single search and come up with a four byte cookie that means something to you (like a cost or restrict, or a pointer to structure with something more complex). The current termination is an empty asps_tree member in an asp_state. You could terminate with a value and implement the union so that a function is provided to merge the terminate values on an overlap. The function that merges netlists with a continue just chains structs so that an AS path that matches as-path-exp-1 and as-paths-exp-2 returns a netlist with an action of "pref 1" and a hook to a second netlist with "pref 2" and a hook to "restrict" if neither netlist matches. Much simpler to code but slightly less efficient would be to keep the current implementation and match the first AS path expression, match the netlist, then match the second AS path, and so on. > Cengiz > > -- > Cengiz Alaettinoglu Information Sciences Institute > (310) 822-1511 University of Southern California What was the question again? :-) Curtis -------- Logged at Tue Mar 14 06:24:01 MET 1995 --------- From curtis at ans.net Tue Mar 14 05:56:12 1995 From: curtis at ans.net (Curtis Villamizar) Date: Mon, 13 Mar 1995 23:56:12 -0500 Subject: AS 690 aut-num progress (LONG!!!) Message-ID: <199503140456.XAA00831@curtis.ansremote.com> Hi all, A first cut of AS 690 inbound policy is done. I think it is accurate, but haven't checked against gated configs, so I can't yet be sure. I'd like comments of the method and on some of the syntax extensions we will be using internally. In all cases where the capability exists in ripe-181, short cut syntax (like wildcards in interas-in lines) will be expanded before sending to a public database. I just partially manually rechecked the results and while doing so wrote some comments in the current output. The annotated partial aut-num object is below. Early comments please. There is one problem for which there is no way to express the requirement in ripe-181. There is no way to specify an as-in line (which is required and has no means restrict to specific peers) and no way to specify that certain destinations are not accepted at all at some peers using interas-in or as-in lines. This is need where we peer with someone at two interconnects, accept one as primary and don't accept the same set of routes from the other peering at all. The current code currently does not have the ability to make the check needed to add the reject, but if we get a syntax, adding the code would not be difficult. One method would be a post processing phase which can note that where interas-in lines are used but where some peering sessions are not covered by the interas-in lines and will be used as last resorts (unintentionally). The next step is either outbound policy or partial gated configs to check the inet-rtr objects and inbound policy. Outbound policy looks a lot easier than inbound, but I will need the extended syntax that supports AS path (at least to specify border AS that we learned the route from). I'm going to use gated syntax and not bother to call the field extended-something unless a consensus emerges real quickly. Curtis btw- the complete objects as they now stand are at: http://tweedledee.ans.net:8001/prdb-radb These are generated from a PRDB snapshot taken Feb 21. The idea is to build the tool, compare to gated configs of the same vintage, then redo the snapshot more recently and compare, then start doing real config runs from the ANS-DB and submit our stuff to the RADB. This has to be well coordinated with Merit and others. This is part of the AS 690 ripe-181 aut-num object, annotated to show how the lines are derived and why. aut-num: AS690 as-name: ASN-NSFNET-T3-RT description: ANSNET (the former NSFNET backbone) guardian: as690-guardian at ans.net tech-c: noc at ans.net admin-c: config at ans.net notify: config-notify at ans.net source: ANS This is all fixed and can easily be changed if the guesses at reasonable fields are not incorrect. The remainder of the aut-num object is then the inbound policy for AS 690. This is grouped by home AS number. remark: homeas policies: 109 : 1:3561:5 2:3561:450 3:200:8 4:200:136 + \ 1:3561:5 2:3561:450 3:200:8 4:200:136 5:1740:71 + 1:3561:5 2:3561:450 \ 3:200:8 4:200:136 5:1740:450 6:1740:71 + 1:1957 This remark lists the policies for home AS 109. There are four policies on this line, separated by plus (+). Line continuation uses the backslash. If that upsets true ripe-181 implementations, then line continuations can be removed and the very long lines submitted to the RA or other outside database. The individual policies are then treated in order of the number of routes which they cover. I've compressed some white space out in a few places to avoid some line continuations. remark: homeas policy: 109 : 1:3561:5 2:3561:450 3:200:8 4:200:136 (4/9) This line indicates that one home AS policy for AS 109 is being expressed, the policy "1:3561:5 2:3561:450 3:200:8 4:200:136" which covers four of the nine networks for AS 109. The third value in some tuples is a database index to the ENSS where the policy entry applies. remark: policy item for 109: 1:3561:5 as-in: from AS3561 1 accept AS109 except { 192.150.49/24 } interas-in: from AS3561 DNSS11 * (pref=1) accept AS109 except { 192.150.49/24 } The first item in the policy can be expressed as an AS list with one exception. All of the policies contain the tuple 1:3561:5, except one policy, 1:1957, which contains one network 192.150.49/24. Any new route objects for AS 109 will be handled by this policy entry. An as-in line is needed to cover the interas-in line. There is no way in ripe-181 to state that these nets are accepted at no other AS 3561 peering. Note that the from expression includes a wildcard. The expression "AS3561 DNSS11 *" indicates all AS 3561 peers at DNSS11. This is a ripe-181 extension and must also be expanded based on the inet-rtr object before submitting to a public database like the RA. The name DNSS11 must also be changed. DNSS in the router names must be changed to CNSS. Many of the peer routers have no names at all in the PRDB. DNS is being used to create a name translation table to address this but hasn't been applied. When it is, DNSS11 will be cnss11.t3.ans.net and the interas-in line will be a bit longer. remark: policy item for 109: 2:3561:450 interas-in: from AS3561 ENSS218 * (pref=2) accept AS109 except {192.150.49/24} remark: policy item for 109: 3:200:8 as-in: from AS200 3 accept AS109 except { 192.150.49/24 } interas-in: from AS200 ENSS128 * (pref=3) accept AS109 except {192.150.49/24} remark: policy item for 109: 4:200:136 interas-in: from AS200 ENSS144 * (pref=4) accept AS109 except {192.150.49/24} The reamining three backup preferences are expressed using the same AS expression with an exception of one network, since two of the policies simply add a fifth and sixth preference. These also require an as-in and interas-in line and suffer the same problem of not being able to negate peerings. remark: homeaspolicy:109: 1:3561:5 2:3561:450 3:200:8 4:200:136 5:1740:71 (3/9) This is the next policy. All of the policy expressions have already been covered except the fifth one. remark: policy item for 109: 5:1740:71 as-in: from AS1740 5 accept { 131.108/16 192.31.7/24 198.93.160/19 } interas-in: from AS1740 ENSS135 * (pref=5) accept \ { 131.108/16 192.31.7/24 198.93.160/19 } The first four expressions are suppressed since they are already covered by the AS109 specified in the first policy group. Only the fifth entry in this policy must be stated. A net list is used so new route objects don't inherit this. remark: homeas policy: 109 : 1:3561:5 2:3561:450 3:200:8 4:200:136 5:1740:450 \ 6:1740:71 (1/9) This is the next policy for AS 109. It has a fifth and sixth entry. remark: policy item for 109: 5:1740:450 as-in: from AS1740 5 accept { 171.68/15 } interas-in: from AS1740 ENSS218 * (pref=5) accept { 171.68/15 } remark: policy item for 109: 6:1740:71 interas-in: from AS1740 ENSS135 * (pref=6) accept { 171.68/15 } The fifth and sixth entries are both needed. They only cover one route, so one might question why this is needed at all. (Same with the previous fifth entry). One as-in line is needed to cover both interas-in entries. I don't know where else AS 1740 peers with us (if anywhere). remark: homeas policy: 109 : 1:1957 (1/9) remark: policy item for 109: 1:1957 as-in: from AS1957 1 accept { 192.150.49/24 } The reamining oddball net has a completely different policy. Since I don't know who AS 109 is or the net, I don't know if or why this makes sense. In this case we specify all peerings of AS 1957 (but there is only one anyway). remark: homeas policies: 1103 : 1:1128 2:1800 3:1133 4:1674 5:1240 + 1:1128 \ 2:1800 3:1133 4:1674 5:1240 6:701:84 7:701:64 This is the policy for home AS 1103. It has two policies that differ only in the inclusion of a sixth and seventh expression. remark: homeas policy: 1103 : 1:1128 2:1800 3:1133 4:1674 5:1240 (139/141) remark: policy item for 1103: 1:1128 as-in: from AS1128 1 accept AS1103 remark: policy item for 1103: 2:1800 as-in: from AS1800 2 accept AS1103 remark: policy item for 1103: 3:1133 as-in: from AS1133 3 accept AS1103 remark: policy item for 1103: 4:1674 as-in: from AS1674 4 accept AS1103 remark: policy item for 1103: 5:1240 as-in: from AS1240 5 accept AS1103 The first five policy entries cover 139 of the 141 entries completely and cover the entire AS. The expression of AS 1103 is similar to AS 109. There is no need for an exception list in the first policy. remark: homeas policy: 1103 : 1:1128 2:1800 3:1133 4:1674 5:1240 6:701:84 \ 7:701:64 (2/141) remark: policy item for 1103: 6:701:84 as-in: from AS701 6 accept { 130.37/16 146.50/16 } interas-in: from AS701 ENSS136 * (pref=6) accept { 130.37/16 146.50/16 } remark: policy item for 1103: 7:701:64 interas-in: from AS701 ENSS134 * (pref=7) accept { 130.37/16 146.50/16 } An as-in line and two interas-in lines is needed for AS 701. There are only two routes with this sixth and seventh entry. It would seem safe to drop these or possibly include the whole AS in the sixth and seventh backup is AS 701 doesn't mind. remark: homeas policies: 1104 : 1:1128 2:1800 3:1133 4:1674 5:1240 remark: homeas policy: 1104 : 1:1128 2:1800 3:1133 4:1674 5:1240 (5/5) remark: policy item for 1104: 1:1128 as-in: from AS1128 1 accept AS1104 remark: policy item for 1104: 2:1800 as-in: from AS1800 2 accept AS1104 remark: policy item for 1104: 3:1133 as-in: from AS1133 3 accept AS1104 remark: policy item for 1104: 4:1674 as-in: from AS1674 4 accept AS1104 remark: policy item for 1104: 5:1240 as-in: from AS1240 5 accept AS1104 Home AS 1104 is easy since it has only one policy and doesn't have any expressions requiring interas-in. remark: homeas policies: 1115 : 1:1800 2:1133 3:1240 + 1:1133 2:1674 3:1800 remark: homeas policy: 1115 : 1:1800 2:1133 3:1240 (8/15) remark: policy item for 1115: 1:1800 as-in: from AS1800 1 accept AS1115 except { 193.170.80/24 193.170.81/24 \ 193.170.82/24 193.170.83/24 193.170.84/24 193.170.85/24 193.170.86/24 } remark: policy item for 1115: 2:1133 as-in: from AS1133 2 accept AS1115 except { 193.170.80/24 193.170.81/24 \ 193.170.82/24 193.170.83/24 193.170.84/24 193.170.85/24 193.170.86/24 } remark: policy item for 1115: 3:1240 as-in: from AS1240 3 accept AS1115 except { 193.170.80/24 193.170.81/24 \ 193.170.82/24 193.170.83/24 193.170.84/24 193.170.85/24 193.170.86/24 } remark: homeas policy: 1115 : 1:1133 2:1674 3:1800 (7/15) remark: policy item for 1115: 1:1133 as-in: from AS1133 1 accept { 193.170.80/24 193.170.81/24 193.170.82/24 \ 193.170.83/24 193.170.84/24 193.170.85/24 193.170.86/24 } remark: policy item for 1115: 2:1674 as-in: from AS1674 2 accept { 193.170.80/24 193.170.81/24 193.170.82/24 \ 193.170.83/24 193.170.84/24 193.170.85/24 193.170.86/24 } remark: policy item for 1115: 3:1800 as-in: from AS1800 3 accept { 193.170.80/24 193.170.81/24 193.170.82/24 \ 193.170.83/24 193.170.84/24 193.170.85/24 193.170.86/24 } AS 1115 has two policies, some prefer Dante and others prefer ICM. This is still easy, since no interas-in lines are needed. remark: homeas policies: 1117 : 1:1800 2:1133 3:1240 remark: homeas policy: 1117 : 1:1800 2:1133 3:1240 (1/1) remark: policy item for 1117: 1:1800 as-in: from AS1800 1 accept AS1117 remark: policy item for 1117: 2:1133 as-in: from AS1133 2 accept AS1117 remark: policy item for 1117: 3:1240 as-in: from AS1240 3 accept AS1117 Home AS 1117 has one net, therefore it's hard to have more than one policy. remark: homeas policies: 1125 : 1:1800 2:1133 3:1674 4:1240 remark: homeas policy: 1125 : 1:1800 2:1133 3:1674 4:1240 (2/2) remark: policy item for 1125: 1:1800 as-in: from AS1800 1 accept AS1125 remark: policy item for 1125: 2:1133 as-in: from AS1133 2 accept AS1125 remark: policy item for 1125: 3:1674 as-in: from AS1674 3 accept AS1125 remark: policy item for 1125: 4:1240 as-in: from AS1240 4 accept AS1125 Two nets, one policy for AS 1125. remark: homeas policies: 1128 : 1:1800 2:1133 3:1674 4:1240 remark: homeas policy: 1128 : 1:1800 2:1133 3:1674 4:1240 (1/1) remark: policy item for 1128: 1:1800 as-in: from AS1800 1 accept AS1128 remark: policy item for 1128: 2:1133 as-in: from AS1133 2 accept AS1128 remark: policy item for 1128: 3:1674 as-in: from AS1674 3 accept AS1128 remark: policy item for 1128: 4:1240 as-in: from AS1240 4 accept AS1128 One net, one policy for AS 1128. remark: homeas policies: 1133 : 1:1133 remark: homeas policy: 1133 : 1:1133 (2/2) remark: policy item for 1133: 1:1133 as-in: from AS1133 1 accept AS1133 Two nets (both DMZs for Dante), one policy with one policy expression for AS 1133. remark: homeas policies: 1134 : 1:1800 2:1133 3:1674 4:1240 remark: homeas policy: 1134 : 1:1800 2:1133 3:1674 4:1240 (1/1) remark: policy item for 1134: 1:1800 as-in: from AS1800 1 accept AS1134 remark: policy item for 1134: 2:1133 as-in: from AS1133 2 accept AS1134 remark: policy item for 1134: 3:1674 as-in: from AS1674 3 accept AS1134 remark: policy item for 1134: 4:1240 as-in: from AS1240 4 accept AS1134 One net, one policy for AS 1134. remark: homeas policies: 114 : 1:3561:450 2:3561:5 3:114 + 1:114 + 1:3561:450 \ 2:3561:5 3:114 4:97 + 1:3561:450 2:3561:5 3:114 4:3354 + 1:3561:450 \ 2:3561:5 3:114 4:297:104 + 1:1240 2:1800 3:1239 Sesquinet has 6 policies and 224 networks. Blame Bill. :-) remark: homeas policy: 114 : 1:3561:450 2:3561:5 3:114 (207/224) remark: policy item for 114: 1:3561:450 as-in: from AS3561 1 accept AS114 except { 199.33.100/24 199.33.120/24 \ 199.191.41/24 162.71/16 192.195.198/24 198.64.246/24 198.64.247/24 \ 204.145.251/24 130.158/16 } interas-in: from AS3561 ENSS218 * (pref=1) accept AS114 except { \ 199.33.100/24 199.33.120/24 199.191.41/24 162.71/16 192.195.198/24 \ 198.64.246/24 198.64.247/24 204.145.251/24 130.158/16 } remark: policy item for 114: 2:3561:5 interas-in: from AS3561 DNSS11 * (pref=2) accept AS114 except { 199.33.100/24 \ 199.33.120/24 199.191.41/24 162.71/16 192.195.198/24 198.64.246/24 \ 198.64.247/24 204.145.251/24 130.158/16 } remark: policy item for 114: 3:114 as-in: from AS114 3 accept AS114 except { 199.33.100/24 199.33.120/24 \ 199.191.41/24 162.71/16 192.195.198/24 198.64.246/24 198.64.247/24 \ 204.145.251/24 130.158/16 } The most common policy covers 207 of the 224 networks. A few have additional fourth expressions. A few others may be DMZs. The policy is expressed as AS114 with a very small number of exceptions. remark: homeas policy: 114 : 1:114 (8/224) remark: policy item for 114: 1:114 as-in: from AS114 1 accept { 199.33.100/24 199.33.120/24 199.191.41/24 \ 162.71/16 192.195.198/24 198.64.246/24 198.64.247/24 204.145.251/24 } This could be DMZs with AS 690, or mistakes. If they are DMZs it would make sense to announce them via AS 114 only. remark: homeas policy: 114 : 1:3561:450 2:3561:5 3:114 4:97 (4/224) remark: policy item for 114: 4:97 as-in: from AS97 4 accept { 129.90/16 162.122/16 167.175/16 170.179/16 } This policy adds a fourth expression, a backup through JVNC, to a set of four networks. Later on we can decide if exceptions like this make sense. remark: homeas policy: 114 : 1:3561:450 2:3561:5 3:114 4:3354 (3/224) remark: policy item for 114: 4:3354 as-in: from AS3354 4 accept { 143.111/16 129.106/16 139.52/16 } This policy adds a different fourth expression, a backup through AS 3354, to three networks. remark: homeas policy: 114 : 1:3561:450 2:3561:5 3:114 4:297:104 (1/224) remark: policy item for 114: 4:297:104 as-in: from AS297 4 accept { 192.67.14/24 } interas-in: from AS297 ENSS139 * (pref=4) accept { 192.67.14/24 } And then there is one oddball that has a fourth route through AS 297 at E139 only. I'm not sure what this is. remark: homeas policy: 114 : 1:1240 2:1800 3:1239 (1/224) remark: policy item for 114: 1:1240 as-in: from AS1240 1 accept { 130.158/16 } remark: policy item for 114: 2:1800 as-in: from AS1800 2 accept { 130.158/16 } remark: policy item for 114: 3:1239 One more oddball. This one routes completely differently, with primary though SprintLand places. I'm clueless. Maybe a Sprint/Sesquinet DMZ, but that's a guess. as-in: from AS1239 3 accept { 130.158/16 } remark: homeas policies: 116 : 1:97 remark: homeas policy: 116 : 1:97 (1/1) remark: policy item for 116: 1:97 as-in: from AS97 1 accept AS116 AS 116 has one net and uses JVNC. remark: homeas policies: 1204 : 1:2149 2:174 3:1239 4:1800 5:1240 + 1:1239 \ 2:1800 3:1240 AS 1204 has two policies that are quite different. remark: homeas policy: 1204 : 1:2149 2:174 3:1239 4:1800 5:1240 (35/55) remark: policy item for 1204: 1:2149 as-in: from AS2149 1 accept AS1204 except { 136.150/16 199.29.202/23 \ 199.29.204/23 199.29.211/24 199.29.212/22 199.29.220/22 199.29.216/22 \ 198.102.1/24 198.102.2/23 199.29.6/24 199.29.7/24 199.29.8/24 199.29.196/22 \ 199.29.200/24 199.29.201/24 192.245.19/24 192.245.20/24 192.245.21/24 \ 192.245.22/24 192.245.23/24 } remark: policy item for 1204: 2:174 as-in: from AS174 2 accept AS1204 except { 136.150/16 199.29.202/23 \ 199.29.204/23 199.29.211/24 199.29.212/22 199.29.220/22 199.29.216/22 \ 198.102.1/24 198.102.2/23 199.29.6/24 199.29.7/24 199.29.8/24 199.29.196/22 \ 199.29.200/24 199.29.201/24 192.245.19/24 192.245.20/24 192.245.21/24 \ 192.245.22/24 192.245.23/24 } remark: policy item for 1204: 3:1239 as-in: from AS1239 3 accept AS1204 except { 136.150/16 199.29.202/23 \ 199.29.204/23 199.29.211/24 199.29.212/22 199.29.220/22 199.29.216/22 \ 198.102.1/24 198.102.2/23 199.29.6/24 199.29.7/24 199.29.8/24 199.29.196/22 \ 199.29.200/24 199.29.201/24 192.245.19/24 192.245.20/24 192.245.21/24 \ 192.245.22/24 192.245.23/24 } remark: policy item for 1204: 4:1800 as-in: from AS1800 4 accept AS1204 except { 136.150/16 199.29.202/23 \ 199.29.204/23 199.29.211/24 199.29.212/22 199.29.220/22 199.29.216/22 \ 198.102.1/24 198.102.2/23 199.29.6/24 199.29.7/24 199.29.8/24 199.29.196/22 \ 199.29.200/24 199.29.201/24 192.245.19/24 192.245.20/24 192.245.21/24 \ 192.245.22/24 192.245.23/24 } remark: policy item for 1204: 5:1240 as-in: from AS1240 5 accept AS1204 except { 136.150/16 199.29.202/23 \ 199.29.204/23 199.29.211/24 199.29.212/22 199.29.220/22 199.29.216/22 \ 198.102.1/24 198.102.2/23 199.29.6/24 199.29.7/24 199.29.8/24 199.29.196/22 \ 199.29.200/24 199.29.201/24 192.245.19/24 192.245.20/24 192.245.21/24 \ 192.245.22/24 192.245.23/24 } New route objects will default to the first policy which covers 35 of the 55 nets. This whole thing uses as-in but requires an except list of 20 nets. remark: homeas policy: 1204 : 1:1239 2:1800 3:1240 (20/55) remark: policy item for 1204: 1:1239 as-in: from AS1239 1 accept { 136.150/16 199.29.202/23 199.29.204/23 \ 199.29.211/24 199.29.212/22 199.29.220/22 199.29.216/22 198.102.1/24 \ 198.102.2/23 199.29.6/24 199.29.7/24 199.29.8/24 199.29.196/22 \ 199.29.200/24 199.29.201/24 192.245.19/24 192.245.20/24 192.245.21/24 \ 192.245.22/24 192.245.23/24 } remark: policy item for 1204: 2:1800 as-in: from AS1800 2 accept { 136.150/16 199.29.202/23 199.29.204/23 \ 199.29.211/24 199.29.212/22 199.29.220/22 199.29.216/22 198.102.1/24 \ 198.102.2/23 199.29.6/24 199.29.7/24 199.29.8/24 199.29.196/22 \ 199.29.200/24 199.29.201/24 192.245.19/24 192.245.20/24 192.245.21/24 \ 192.245.22/24 192.245.23/24 } remark: policy item for 1204: 3:1240 as-in: from AS1240 3 accept { 136.150/16 199.29.202/23 199.29.204/23 \ 199.29.211/24 199.29.212/22 199.29.220/22 199.29.216/22 198.102.1/24 \ 198.102.2/23 199.29.6/24 199.29.7/24 199.29.8/24 199.29.196/22 \ 199.29.200/24 199.29.201/24 192.245.19/24 192.245.20/24 192.245.21/24 \ 192.245.22/24 192.245.23/24 } The remaining 20 nets have to be listed. Again as-in lines are fine for this policy. remark: homeas policies: 1205 : 1:1133 2:1674 3:1800 + 1:1800 2:1133 3:1240 + \ 1:1133 2:1800 3:1240 remark: homeas policy: 1205 : 1:1133 2:1674 3:1800 (11/19) remark: policy item for 1205: 1:1133 as-in: from AS1133 1 accept AS1205 except { 193.170.67/24 193.170.124/24 \ 193.170.125/24 193.170.126/24 193.170.127/24 } remark: policy item for 1205: 2:1674 as-in: from AS1674 2 accept AS1205 except { 193.170.67/24 193.170.124/24 \ 193.170.125/24 193.170.126/24 193.170.127/24 193.170.96/24 193.170.97/24 \ 193.170.156/24 } remark: policy item for 1205: 3:1800 as-in: from AS1800 3 accept AS1205 except { 193.170.67/24 193.170.124/24 \ 193.170.125/24 193.170.126/24 193.170.127/24 193.170.96/24 193.170.97/24 \ 193.170.156/24 } remark: homeas policy: 1205 : 1:1800 2:1133 3:1240 (5/19) remark: policy item for 1205: 1:1800 as-in: from AS1800 1 accept { 193.170.67/24 193.170.124/24 193.170.125/24 \ 193.170.126/24 193.170.127/24 } remark: policy item for 1205: 2:1133 as-in: from AS1133 2 accept { 193.170.67/24 193.170.124/24 193.170.125/24 \ 193.170.126/24 193.170.127/24 } remark: policy item for 1205: 3:1240 as-in: from AS1240 3 accept { 193.170.67/24 193.170.124/24 193.170.125/24 \ 193.170.126/24 193.170.127/24 } remark: homeas policy: 1205 : 1:1133 2:1800 3:1240 (3/19) remark: policy item for 1205: 2:1800 as-in: from AS1800 2 accept { 193.170.96/24 193.170.97/24 193.170.156/24 } remark: policy item for 1205: 3:1240 as-in: from AS1240 3 accept { 193.170.96/24 193.170.97/24 193.170.156/24 } AS 1205 has two policies that use only as-in lines. remark: homeas policies: 1206 : 1:1206 2:204 + 1:1206 2:204 3:174 remark: homeas policy: 1206 : 1:1206 2:204 (5/6) remark: policy item for 1206: 1:1206 as-in: from AS1206 1 accept AS1206 remark: policy item for 1206: 2:204 as-in: from AS204 2 accept AS1206 remark: homeas policy: 1206 : 1:1206 2:204 3:174 (1/6) remark: policy item for 1206: 3:174 as-in: from AS174 3 accept { 132.226/16 } AS 1206 has two policies. One policy covers only one net. Hmmm.... remark: homeas policies: 1207 : 1:1207 remark: homeas policy: 1207 : 1:1207 (1/1) remark: policy item for 1207: 1:1207 as-in: from AS1207 1 accept AS1207 One net, one policy. Can't be done any other way. remark: homeas policies: 1213 : 1:1800 2:1133 3:1240 + 1:1800 2:1133 3:1674 + \ 1:1133 2:1674 3:1800 + 1:1800 2:1240 3:1133 4:1674 + 1:1133 2:1800 3:1240 remark: homeas policy: 1213 : 1:1800 2:1133 3:1240 (74/86) remark: policy item for 1213: 1:1800 as-in: from AS1800 1 accept AS1213 except { 193.1.193/24 134.226/16 \ 193.1.198/24 } remark: policy item for 1213: 2:1133 as-in: from AS1133 2 accept AS1213 except { 193.1.193/24 134.226/16 \ 193.1.209/24 193.1.198/24 } remark: policy item for 1213: 3:1240 as-in: from AS1240 3 accept AS1213 except { 140.203/16 136.201/16 136.206/16 \ 143.239/16 137.43/16 149.153/16 149.157/16 193.1/16 193.1.193/24 134.226/16 \ 193.1.209/24 } remark: homeas policy: 1213 : 1:1800 2:1133 3:1674 (8/86) remark: policy item for 1213: 3:1674 as-in: from AS1674 3 accept { 140.203/16 136.201/16 136.206/16 143.239/16 \ 137.43/16 149.153/16 149.157/16 193.1/16 } remark: homeas policy: 1213 : 1:1133 2:1674 3:1800 (2/86) remark: policy item for 1213: 1:1133 as-in: from AS1133 1 accept { 193.1.193/24 134.226/16 } remark: policy item for 1213: 2:1674 as-in: from AS1674 2 accept { 193.1.193/24 134.226/16 } remark: policy item for 1213: 3:1800 as-in: from AS1800 3 accept { 193.1.193/24 134.226/16 } remark: homeas policy: 1213 : 1:1800 2:1240 3:1133 4:1674 (1/86) remark: policy item for 1213: 2:1240 as-in: from AS1240 2 accept { 193.1.209/24 } remark: policy item for 1213: 3:1133 as-in: from AS1133 3 accept { 193.1.209/24 } remark: policy item for 1213: 4:1674 as-in: from AS1674 4 accept { 193.1.209/24 } remark: homeas policy: 1213 : 1:1133 2:1800 3:1240 (1/86) remark: policy item for 1213: 1:1133 as-in: from AS1133 1 accept { 193.1.198/24 } remark: policy item for 1213: 2:1800 as-in: from AS1800 2 accept { 193.1.198/24 } AS 1213 has four policies. These all use as-in, and some combinations of ICM and Dante and SprintLink. I don't know if there is a reason for the others, but 74 of the 86 use the same policy. remark: homeas policies: 1220 : 1:3561:450 2:3561:5 3:114 remark: homeas policy: 1220 : 1:3561:450 2:3561:5 3:114 (2/2) remark: policy item for 1220: 1:3561:450 as-in: from AS3561 1 accept AS1220 interas-in: from AS3561 ENSS218 * (pref=1) accept AS1220 remark: policy item for 1220: 2:3561:5 interas-in: from AS3561 DNSS11 * (pref=2) accept AS1220 remark: policy item for 1220: 3:114 as-in: from AS114 3 accept AS1220 AS 1220 has one policy and the whole thing uses as-in. [ ... ] Are we getting bored yet. If not look at the complete file and add your own silly comments. :-) [ ... ] Skip to AS 701 just for fun... remark: homeas policies: 701 : 1:701:84 2:701:64 + 1:1957 + 1:701:84 2:701:64 \ 3:2149 4:174 + 1:701:84 2:701:64 3:2551 + 1:701:84 2:701:64 3:97 + 1:701:84 \ 2:701:64 3:1240 4:1800 + 1:701:84 2:701:64 3:200:8 4:200:136 + 1:701:84 \ 2:701:64 4:2149 5:174 + 1:3561:5 2:3561:450 3:200:8 4:200:136 5:701:84 \ 6:701:64 + 1:701:84 2:701:64 3:3561:450 4:3561:5 5:560 + 1:701:84 2:701:64 \ 3:3561:450 4:3561:5 5:279 + 1:701:84 2:701:64 3:209 4:210 + 1:701:84 \ 2:701:64 3:3561:450 4:3561:5 5:1225:27 6:1225:18 7:1225:34 + 1:701:84 \ 2:701:64 3:1740:71 + 1:1327 2:701:84 3:701:64 + 1:701:84 2:701:64 3:195 + \ 1:97 + 1:3561:450 2:3561:5 3:560 4:701:84 5:701:64 + 1:2551 2:701:84 \ 3:701:64 + 1:701:84 2:701:64 3:174 Lots of different policies for AS 701. remark: homeas policy: 701 : 1:701:84 2:701:64 (2241/2756) remark: policy item for 701: 1:701:84 as-in: from AS701 1 accept AS701 except { 192.152.96/24 192.203.46/24 \ 192.203.47/24 198.6.129/24 198.6.130/24 192.203.75/24 198.3.7/24 198.3.8/24 \ 198.3.9/24 198.3.10/24 198.3.11/24 198.3.13/24 198.3.14/24 198.3.15/24 \ 159.201/16 192.195.103/24 192.58.100/24 192.58.101/24 192.88.206/24 \ 192.107.103/24 153.33/16 198.17.65/24 192.124.131/24 192.124.133/24 \ 192.203.206/24 192.83.157/24 192.124.148/24 192.124.149/24 128.177/16 \ 192.160.173/24 198.3.115/24 192.108.251/24 192.160.196/24 192.58.98/24 \ 192.58.99/24 198.3.123/24 198.3.163/24 198.3.164/24 198.3.165/24 \ 198.3.166/24 198.3.167/24 198.3.168/24 198.3.169/24 198.3.170/24 \ 198.3.171/24 198.3.173/24 198.3.175/24 198.3.64/24 198.3.65/24 198.3.66/24 \ 198.3.67/24 198.3.68/24 198.3.69/24 198.3.70/24 198.3.71/24 198.3.72/24 \ 198.3.73/24 198.3.74/24 198.3.75/24 198.3.76/24 198.3.77/24 198.3.78/24 \ 198.3.79/24 156.73/16 192.251.131/24 192.67.98/24 198.3.0/24 198.3.12/24 \ 198.3.134/24 198.3.152/24 198.3.153/24 198.3.154/24 198.3.155/24 \ 198.3.38/24 198.3.39/24 198.6.131/24 198.6.132/24 198.6.133/24 198.6.134/24 \ 198.6.135/24 198.6.136/24 198.6.137/24 198.6.138/24 198.6.139/24 \ 198.6.140/24 198.6.141/24 198.6.142/24 198.6.143/24 198.6.144/24 \ 198.6.145/24 198.6.146/24 198.6.147/24 198.6.148/24 198.6.149/24 \ 198.6.151/24 198.6.152/24 198.6.153/24 198.6.154/24 198.6.155/24 \ 198.6.156/24 198.6.157/24 198.6.158/24 198.6.159/24 198.6.161/24 \ 198.6.162/24 198.6.163/24 198.6.164/24 198.6.165/24 198.6.166/24 \ 198.6.167/24 198.6.168/24 198.6.169/24 198.6.170/24 198.6.171/24 \ 198.6.172/24 198.6.173/24 198.6.174/24 198.6.175/24 198.6.176/24 \ 198.6.177/24 198.6.178/24 198.6.179/24 198.6.180/24 198.6.181/24 \ 198.6.182/24 198.6.183/24 198.6.184/24 198.6.185/24 198.6.186/24 \ 198.6.187/24 198.6.188/24 198.6.189/24 198.6.190/24 198.6.191/24 \ 192.58.97/24 198.3.238/24 198.3.248/24 198.3.249/24 198.3.250/24 \ 198.3.251/24 198.4.32/24 198.4.33/24 198.4.34/24 198.4.35/24 198.4.36/24 \ 198.4.37/24 198.4.38/24 198.4.39/24 198.4.40/24 198.4.41/24 198.4.42/24 \ 198.4.43/24 198.4.44/24 198.4.45/24 198.4.46/24 198.4.47/24 157.54/16 \ 157.55/16 157.56/16 157.57/16 157.58/16 157.59/16 157.60/16 157.61/16 \ 198.3.255/24 198.4.14/24 198.4.54/24 198.4.55/24 192.101.77/24 \ 192.160.28/24 198.4.93/24 198.4.108/24 198.4.109/24 198.4.110/24 \ 198.4.111/24 198.4.112/24 198.4.113/24 198.4.114/24 198.4.115/24 \ 198.51.36/24 192.131.73/24 192.245.122/24 192.245.123/24 192.245.124/24 \ 192.245.125/24 198.136.155/24 198.4.128/24 198.4.129/24 198.4.130/24 \ 198.4.131/24 198.4.132/24 198.4.133/24 198.4.134/24 198.4.135/24 \ 198.4.136/24 198.4.137/24 198.4.138/24 198.4.139/24 198.4.140/24 \ 198.4.141/24 198.4.142/24 198.4.143/24 198.4.164/24 198.4.181/24 \ 198.4.183/24 198.4.198/24 198.4.189/24 198.4.190/24 198.4.191/24 151.139/16 \ 198.147.129/24 198.147.130/24 198.147.131/24 198.147.132/24 198.147.133/24 \ 198.206.195/24 198.4.192/24 198.4.193/24 198.4.194/24 198.4.195/24 \ 198.4.197/24 198.4.204/24 198.4.207/24 198.178.231/24 198.180.192/24 \ 147.85/16 192.234.103/24 196.1.1/24 198.4.199/24 198.4.247/24 198.5.160/24 \ 198.5.162/24 198.5.167/24 198.5.17/24 198.5.181/24 198.5.19/24 198.5.2/24 \ 162.62/16 167.8/16 198.137.232/24 198.5.183/24 198.5.185/24 198.5.186/24 \ 198.5.221/24 198.5.31/24 198.6.10/24 198.6.77/24 202.14.117/24 202.28.0/24 \ 148.174/16 198.6.2/24 198.6.8/24 202.41.129/24 198.5.21/24 199.33.236/24 \ 167.104/16 198.6.78/24 198.6.96/24 198.6.67/24 198.6.64/24 198.6.65/24 \ 198.6.224/24 204.179.169/24 198.5.255/24 198.6.118/24 198.6.119/24 \ 198.6.195/24 199.170.1/24 144.142/16 160.65/16 192.187.65/24 198.148.155/24 \ 198.187.230/24 198.6.251/24 199.170.16/24 198.6.202/24 198.6.220/24 \ 198.6.193/24 198.6.199/24 199.170.10/24 199.170.11/24 199.170.12/24 \ 199.170.13/24 199.170.14/24 199.170.15/24 199.170.8/24 199.170.9/24 \ 199.68.100/24 199.68.101/24 199.68.64/24 199.68.66/24 199.68.67/24 \ 199.68.68/24 199.68.69/24 199.68.70/24 199.68.71/24 199.68.72/24 \ 199.68.73/24 199.68.74/24 199.68.75/24 199.68.76/24 199.68.77/24 \ 199.68.78/24 199.68.79/24 199.68.80/24 199.68.81/24 199.68.82/24 \ 199.68.83/24 199.68.84/24 199.68.85/24 199.68.86/24 199.68.87/24 \ 199.68.88/24 199.68.89/24 199.68.90/24 199.68.91/24 199.68.92/24 \ 199.68.93/24 199.68.94/24 199.68.95/24 199.68.96/24 199.68.97/24 \ 199.68.98/24 199.68.99/24 192.132.217/24 192.206.205/24 192.206.206/24 \ 192.206.207/24 192.206.208/24 192.206.209/24 192.206.210/24 192.241.16/24 \ 192.241.17/24 192.241.18/24 192.241.19/24 192.241.20/24 192.241.21/24 \ 192.241.22/24 192.241.23/24 192.241.24/24 192.241.25/24 192.241.26/24 \ 192.241.27/24 192.241.28/24 192.241.29/24 192.241.30/24 192.241.31/24 \ 192.206.206/23 192.206.208/23 192.241.16/20 199.68.66/23 199.68.68/22 \ 199.68.72/21 199.68.80/20 199.68.96/22 199.68.100/23 199.170.8/21 \ 198.4.190/23 192.245.122/23 192.245.124/23 198.3.152/22 198.3.38/23 \ 198.3.64/20 198.3.8/21 198.147.130/23 198.147.132/23 198.4.108/22 \ 198.3.248/22 198.4.32/20 198.4.192/22 198.5.188/23 198.6.64/23 198.6.100/22 \ 192.187.66/23 192.187.68/22 192.187.72/21 192.187.80/20 198.6.104/21 \ 198.6.248/23 192.203.46/23 192.58.98/23 192.58.100/23 204.179.0/18 \ 204.176.146/24 199.171.53/24 198.6.196/24 204.176.36/24 204.176.37/24 \ 204.176.38/24 204.176.39/24 204.176.141/24 199.171.0/24 199.171.1/24 \ 199.171.2/24 199.171.3/24 204.177.181/24 204.176.174/24 204.177.177/24 \ 169.152/16 204.177.156/24 204.177.157/24 204.177.158/24 204.177.159/24 \ 204.177.179/24 204.177.72/24 204.177.73/24 204.177.74/24 204.177.75/24 \ 165.94/16 199.170.143/24 204.176.124/24 196.12.54/24 204.178.192/23 \ 204.179.91/24 196.10.230/24 196.13.232/24 196.6.248/24 204.179.97/24 \ 204.252.64/23 204.252.14/24 204.252.104/24 129.18/16 198.83.2/24 140.212/16 \ 134.62/16 198.211.110/24 } interas-in: from AS701 ENSS136 * (pref=1) accept AS701 except { 192.152.96/24 \ 192.203.46/24 192.203.47/24 198.6.129/24 198.6.130/24 192.203.75/24 \ 198.3.7/24 198.3.8/24 198.3.9/24 198.3.10/24 198.3.11/24 198.3.13/24 \ 198.3.14/24 198.3.15/24 159.201/16 192.195.103/24 192.58.100/24 \ 192.58.101/24 192.88.206/24 192.107.103/24 153.33/16 198.17.65/24 \ 192.124.131/24 192.124.133/24 192.203.206/24 192.83.157/24 192.124.148/24 \ 192.124.149/24 128.177/16 192.160.173/24 198.3.115/24 192.108.251/24 \ 192.160.196/24 192.58.98/24 192.58.99/24 198.3.123/24 198.3.163/24 \ 198.3.164/24 198.3.165/24 198.3.166/24 198.3.167/24 198.3.168/24 \ 198.3.169/24 198.3.170/24 198.3.171/24 198.3.173/24 198.3.175/24 \ 198.3.64/24 198.3.65/24 198.3.66/24 198.3.67/24 198.3.68/24 198.3.69/24 \ 198.3.70/24 198.3.71/24 198.3.72/24 198.3.73/24 198.3.74/24 198.3.75/24 \ 198.3.76/24 198.3.77/24 198.3.78/24 198.3.79/24 156.73/16 192.251.131/24 \ 192.67.98/24 198.3.0/24 198.3.12/24 198.3.134/24 198.3.152/24 198.3.153/24 \ 198.3.154/24 198.3.155/24 198.3.38/24 198.3.39/24 198.6.131/24 198.6.132/24 \ 198.6.133/24 198.6.134/24 198.6.135/24 198.6.136/24 198.6.137/24 \ 198.6.138/24 198.6.139/24 198.6.140/24 198.6.141/24 198.6.142/24 \ 198.6.143/24 198.6.144/24 198.6.145/24 198.6.146/24 198.6.147/24 \ 198.6.148/24 198.6.149/24 198.6.151/24 198.6.152/24 198.6.153/24 \ 198.6.154/24 198.6.155/24 198.6.156/24 198.6.157/24 198.6.158/24 \ 198.6.159/24 198.6.161/24 198.6.162/24 198.6.163/24 198.6.164/24 \ 198.6.165/24 198.6.166/24 198.6.167/24 198.6.168/24 198.6.169/24 \ 198.6.170/24 198.6.171/24 198.6.172/24 198.6.173/24 198.6.174/24 \ 198.6.175/24 198.6.176/24 198.6.177/24 198.6.178/24 198.6.179/24 \ 198.6.180/24 198.6.181/24 198.6.182/24 198.6.183/24 198.6.184/24 \ 198.6.185/24 198.6.186/24 198.6.187/24 198.6.188/24 198.6.189/24 \ 198.6.190/24 198.6.191/24 192.58.97/24 198.3.238/24 198.3.248/24 \ 198.3.249/24 198.3.250/24 198.3.251/24 198.4.32/24 198.4.33/24 198.4.34/24 \ 198.4.35/24 198.4.36/24 198.4.37/24 198.4.38/24 198.4.39/24 198.4.40/24 \ 198.4.41/24 198.4.42/24 198.4.43/24 198.4.44/24 198.4.45/24 198.4.46/24 \ 198.4.47/24 157.54/16 157.55/16 157.56/16 157.57/16 157.58/16 157.59/16 \ 157.60/16 157.61/16 198.3.255/24 198.4.14/24 198.4.54/24 198.4.55/24 \ 192.101.77/24 192.160.28/24 198.4.93/24 198.4.108/24 198.4.109/24 \ 198.4.110/24 198.4.111/24 198.4.112/24 198.4.113/24 198.4.114/24 \ 198.4.115/24 198.51.36/24 192.131.73/24 192.245.122/24 192.245.123/24 \ 192.245.124/24 192.245.125/24 198.136.155/24 198.4.128/24 198.4.129/24 \ 198.4.130/24 198.4.131/24 198.4.132/24 198.4.133/24 198.4.134/24 \ 198.4.135/24 198.4.136/24 198.4.137/24 198.4.138/24 198.4.139/24 \ 198.4.140/24 198.4.141/24 198.4.142/24 198.4.143/24 198.4.164/24 \ 198.4.181/24 198.4.183/24 198.4.198/24 198.4.189/24 198.4.190/24 \ 198.4.191/24 151.139/16 198.147.129/24 198.147.130/24 198.147.131/24 \ 198.147.132/24 198.147.133/24 198.206.195/24 198.4.192/24 198.4.193/24 \ 198.4.194/24 198.4.195/24 198.4.197/24 198.4.204/24 198.4.207/24 \ 198.178.231/24 198.180.192/24 147.85/16 192.234.103/24 196.1.1/24 \ 198.4.199/24 198.4.247/24 198.5.160/24 198.5.162/24 198.5.167/24 \ 198.5.17/24 198.5.181/24 198.5.19/24 198.5.2/24 162.62/16 167.8/16 \ 198.137.232/24 198.5.183/24 198.5.185/24 198.5.186/24 198.5.221/24 \ 198.5.31/24 198.6.10/24 198.6.77/24 202.14.117/24 202.28.0/24 148.174/16 \ 198.6.2/24 198.6.8/24 202.41.129/24 198.5.21/24 199.33.236/24 167.104/16 \ 198.6.78/24 198.6.96/24 198.6.67/24 198.6.64/24 198.6.65/24 198.6.224/24 \ 204.179.169/24 198.5.255/24 198.6.118/24 198.6.119/24 198.6.195/24 \ 199.170.1/24 144.142/16 160.65/16 192.187.65/24 198.148.155/24 \ 198.187.230/24 198.6.251/24 199.170.16/24 198.6.202/24 198.6.220/24 \ 198.6.193/24 198.6.199/24 199.170.10/24 199.170.11/24 199.170.12/24 \ 199.170.13/24 199.170.14/24 199.170.15/24 199.170.8/24 199.170.9/24 \ 199.68.100/24 199.68.101/24 199.68.64/24 199.68.66/24 199.68.67/24 \ 199.68.68/24 199.68.69/24 199.68.70/24 199.68.71/24 199.68.72/24 \ 199.68.73/24 199.68.74/24 199.68.75/24 199.68.76/24 199.68.77/24 \ 199.68.78/24 199.68.79/24 199.68.80/24 199.68.81/24 199.68.82/24 \ 199.68.83/24 199.68.84/24 199.68.85/24 199.68.86/24 199.68.87/24 \ 199.68.88/24 199.68.89/24 199.68.90/24 199.68.91/24 199.68.92/24 \ 199.68.93/24 199.68.94/24 199.68.95/24 199.68.96/24 199.68.97/24 \ 199.68.98/24 199.68.99/24 192.132.217/24 192.206.205/24 192.206.206/24 \ 192.206.207/24 192.206.208/24 192.206.209/24 192.206.210/24 192.241.16/24 \ 192.241.17/24 192.241.18/24 192.241.19/24 192.241.20/24 192.241.21/24 \ 192.241.22/24 192.241.23/24 192.241.24/24 192.241.25/24 192.241.26/24 \ 192.241.27/24 192.241.28/24 192.241.29/24 192.241.30/24 192.241.31/24 \ 192.206.206/23 192.206.208/23 192.241.16/20 199.68.66/23 199.68.68/22 \ 199.68.72/21 199.68.80/20 199.68.96/22 199.68.100/23 199.170.8/21 \ 198.4.190/23 192.245.122/23 192.245.124/23 198.3.152/22 198.3.38/23 \ 198.3.64/20 198.3.8/21 198.147.130/23 198.147.132/23 198.4.108/22 \ 198.3.248/22 198.4.32/20 198.4.192/22 198.5.188/23 198.6.64/23 198.6.100/22 \ 192.187.66/23 192.187.68/22 192.187.72/21 192.187.80/20 198.6.104/21 \ 198.6.248/23 192.203.46/23 192.58.98/23 192.58.100/23 204.179.0/18 \ 204.176.146/24 199.171.53/24 198.6.196/24 204.176.36/24 204.176.37/24 \ 204.176.38/24 204.176.39/24 204.176.141/24 199.171.0/24 199.171.1/24 \ 199.171.2/24 199.171.3/24 204.177.181/24 204.176.174/24 204.177.177/24 \ 169.152/16 204.177.156/24 204.177.157/24 204.177.158/24 204.177.159/24 \ 204.177.179/24 204.177.72/24 204.177.73/24 204.177.74/24 204.177.75/24 \ 165.94/16 199.170.143/24 204.176.124/24 196.12.54/24 204.178.192/23 \ 204.179.91/24 196.10.230/24 196.13.232/24 196.6.248/24 204.179.97/24 \ 204.252.64/23 204.252.14/24 204.252.104/24 129.18/16 198.83.2/24 140.212/16 \ 134.62/16 198.211.110/24 } remark: policy item for 701: 2:701:64 interas-in: from AS701 ENSS134 * (pref=2) accept AS701 except { 192.152.96/24 \ 192.203.46/24 192.203.47/24 198.6.129/24 198.6.130/24 192.203.75/24 \ 198.3.7/24 198.3.8/24 198.3.9/24 198.3.10/24 198.3.11/24 198.3.13/24 \ 198.3.14/24 198.3.15/24 159.201/16 192.195.103/24 192.58.100/24 \ 192.58.101/24 192.88.206/24 192.107.103/24 153.33/16 198.17.65/24 \ 192.124.131/24 192.124.133/24 192.203.206/24 192.83.157/24 192.124.148/24 \ 192.124.149/24 128.177/16 192.160.173/24 198.3.115/24 192.108.251/24 \ 192.160.196/24 192.58.98/24 192.58.99/24 198.3.123/24 198.3.163/24 \ 198.3.164/24 198.3.165/24 198.3.166/24 198.3.167/24 198.3.168/24 \ 198.3.169/24 198.3.170/24 198.3.171/24 198.3.173/24 198.3.175/24 \ 198.3.64/24 198.3.65/24 198.3.66/24 198.3.67/24 198.3.68/24 198.3.69/24 \ 198.3.70/24 198.3.71/24 198.3.72/24 198.3.73/24 198.3.74/24 198.3.75/24 \ 198.3.76/24 198.3.77/24 198.3.78/24 198.3.79/24 156.73/16 192.251.131/24 \ 192.67.98/24 198.3.0/24 198.3.12/24 198.3.134/24 198.3.152/24 198.3.153/24 \ 198.3.154/24 198.3.155/24 198.3.38/24 198.3.39/24 198.6.131/24 198.6.132/24 \ 198.6.133/24 198.6.134/24 198.6.135/24 198.6.136/24 198.6.137/24 \ 198.6.138/24 198.6.139/24 198.6.140/24 198.6.141/24 198.6.142/24 \ 198.6.143/24 198.6.144/24 198.6.145/24 198.6.146/24 198.6.147/24 \ 198.6.148/24 198.6.149/24 198.6.151/24 198.6.152/24 198.6.153/24 \ 198.6.154/24 198.6.155/24 198.6.156/24 198.6.157/24 198.6.158/24 \ 198.6.159/24 198.6.161/24 198.6.162/24 198.6.163/24 198.6.164/24 \ 198.6.165/24 198.6.166/24 198.6.167/24 198.6.168/24 198.6.169/24 \ 198.6.170/24 198.6.171/24 198.6.172/24 198.6.173/24 198.6.174/24 \ 198.6.175/24 198.6.176/24 198.6.177/24 198.6.178/24 198.6.179/24 \ 198.6.180/24 198.6.181/24 198.6.182/24 198.6.183/24 198.6.184/24 \ 198.6.185/24 198.6.186/24 198.6.187/24 198.6.188/24 198.6.189/24 \ 198.6.190/24 198.6.191/24 192.58.97/24 198.3.238/24 198.3.248/24 \ 198.3.249/24 198.3.250/24 198.3.251/24 198.4.32/24 198.4.33/24 198.4.34/24 \ 198.4.35/24 198.4.36/24 198.4.37/24 198.4.38/24 198.4.39/24 198.4.40/24 \ 198.4.41/24 198.4.42/24 198.4.43/24 198.4.44/24 198.4.45/24 198.4.46/24 \ 198.4.47/24 157.54/16 157.55/16 157.56/16 157.57/16 157.58/16 157.59/16 \ 157.60/16 157.61/16 198.3.255/24 198.4.14/24 198.4.54/24 198.4.55/24 \ 192.101.77/24 192.160.28/24 198.4.93/24 198.4.108/24 198.4.109/24 \ 198.4.110/24 198.4.111/24 198.4.112/24 198.4.113/24 198.4.114/24 \ 198.4.115/24 198.51.36/24 192.131.73/24 192.245.122/24 192.245.123/24 \ 192.245.124/24 192.245.125/24 198.136.155/24 198.4.128/24 198.4.129/24 \ 198.4.130/24 198.4.131/24 198.4.132/24 198.4.133/24 198.4.134/24 \ 198.4.135/24 198.4.136/24 198.4.137/24 198.4.138/24 198.4.139/24 \ 198.4.140/24 198.4.141/24 198.4.142/24 198.4.143/24 198.4.164/24 \ 198.4.181/24 198.4.183/24 198.4.198/24 198.4.189/24 198.4.190/24 \ 198.4.191/24 151.139/16 198.147.129/24 198.147.130/24 198.147.131/24 \ 198.147.132/24 198.147.133/24 198.206.195/24 198.4.192/24 198.4.193/24 \ 198.4.194/24 198.4.195/24 198.4.197/24 198.4.204/24 198.4.207/24 \ 198.178.231/24 198.180.192/24 147.85/16 192.234.103/24 196.1.1/24 \ 198.4.199/24 198.4.247/24 198.5.160/24 198.5.162/24 198.5.167/24 \ 198.5.17/24 198.5.181/24 198.5.19/24 198.5.2/24 162.62/16 167.8/16 \ 198.137.232/24 198.5.183/24 198.5.185/24 198.5.186/24 198.5.221/24 \ 198.5.31/24 198.6.10/24 198.6.77/24 202.14.117/24 202.28.0/24 148.174/16 \ 198.6.2/24 198.6.8/24 202.41.129/24 198.5.21/24 199.33.236/24 167.104/16 \ 198.6.78/24 198.6.96/24 198.6.67/24 198.6.64/24 198.6.65/24 198.6.224/24 \ 204.179.169/24 198.5.255/24 198.6.118/24 198.6.119/24 198.6.195/24 \ 199.170.1/24 144.142/16 160.65/16 192.187.65/24 198.148.155/24 \ 198.187.230/24 198.6.251/24 199.170.16/24 198.6.202/24 198.6.220/24 \ 198.6.193/24 198.6.199/24 199.170.10/24 199.170.11/24 199.170.12/24 \ 199.170.13/24 199.170.14/24 199.170.15/24 199.170.8/24 199.170.9/24 \ 199.68.100/24 199.68.101/24 199.68.64/24 199.68.66/24 199.68.67/24 \ 199.68.68/24 199.68.69/24 199.68.70/24 199.68.71/24 199.68.72/24 \ 199.68.73/24 199.68.74/24 199.68.75/24 199.68.76/24 199.68.77/24 \ 199.68.78/24 199.68.79/24 199.68.80/24 199.68.81/24 199.68.82/24 \ 199.68.83/24 199.68.84/24 199.68.85/24 199.68.86/24 199.68.87/24 \ 199.68.88/24 199.68.89/24 199.68.90/24 199.68.91/24 199.68.92/24 \ 199.68.93/24 199.68.94/24 199.68.95/24 199.68.96/24 199.68.97/24 \ 199.68.98/24 199.68.99/24 192.132.217/24 192.206.205/24 192.206.206/24 \ 192.206.207/24 192.206.208/24 192.206.209/24 192.206.210/24 192.241.16/24 \ 192.241.17/24 192.241.18/24 192.241.19/24 192.241.20/24 192.241.21/24 \ 192.241.22/24 192.241.23/24 192.241.24/24 192.241.25/24 192.241.26/24 \ 192.241.27/24 192.241.28/24 192.241.29/24 192.241.30/24 192.241.31/24 \ 192.206.206/23 192.206.208/23 192.241.16/20 199.68.66/23 199.68.68/22 \ 199.68.72/21 199.68.80/20 199.68.96/22 199.68.100/23 199.170.8/21 \ 198.4.190/23 192.245.122/23 192.245.124/23 198.3.152/22 198.3.38/23 \ 198.3.64/20 198.3.8/21 198.147.130/23 198.147.132/23 198.4.108/22 \ 198.3.248/22 198.4.32/20 198.4.192/22 198.5.188/23 198.6.64/23 198.6.100/22 \ 192.187.66/23 192.187.68/22 192.187.72/21 192.187.80/20 198.6.104/21 \ 198.6.248/23 192.203.46/23 192.58.98/23 192.58.100/23 204.179.0/18 \ 204.176.146/24 199.171.53/24 198.6.196/24 204.176.36/24 204.176.37/24 \ 204.176.38/24 204.176.39/24 204.176.141/24 199.171.0/24 199.171.1/24 \ 199.171.2/24 199.171.3/24 204.177.181/24 204.176.174/24 204.177.177/24 \ 169.152/16 204.177.156/24 204.177.157/24 204.177.158/24 204.177.159/24 \ 204.177.179/24 204.177.72/24 204.177.73/24 204.177.74/24 204.177.75/24 \ 165.94/16 199.170.143/24 204.176.124/24 196.12.54/24 204.178.192/23 \ 204.179.91/24 196.10.230/24 196.13.232/24 196.6.248/24 204.179.97/24 \ 204.252.64/23 204.252.14/24 204.252.104/24 129.18/16 198.83.2/24 140.212/16 \ 134.62/16 198.211.110/24 } That was the first policy covering 2241 of 2756 networks. Still the exception list of 421 nets runs a bit long. The same primary and secondary appear in all policies except the next one. remark: homeas policy: 701 : 1:1957 (421/2756) remark: policy item for 701: 1:1957 as-in: from AS1957 1 accept { 192.152.96/24 192.203.46/24 192.203.47/24 \ 198.6.129/24 198.6.130/24 192.203.75/24 198.3.7/24 198.3.8/24 198.3.9/24 \ 198.3.10/24 198.3.11/24 198.3.13/24 198.3.14/24 198.3.15/24 159.201/16 \ 192.195.103/24 192.58.100/24 192.58.101/24 192.88.206/24 192.107.103/24 \ 153.33/16 198.17.65/24 192.124.131/24 192.124.133/24 192.203.206/24 \ 192.83.157/24 192.124.148/24 192.124.149/24 128.177/16 192.160.173/24 \ 198.3.115/24 192.108.251/24 192.160.196/24 192.58.98/24 192.58.99/24 \ 198.3.123/24 198.3.163/24 198.3.164/24 198.3.165/24 198.3.166/24 \ 198.3.167/24 198.3.168/24 198.3.169/24 198.3.170/24 198.3.171/24 \ 198.3.173/24 198.3.175/24 198.3.64/24 198.3.65/24 198.3.66/24 198.3.67/24 \ 198.3.68/24 198.3.69/24 198.3.70/24 198.3.71/24 198.3.72/24 198.3.73/24 \ 198.3.74/24 198.3.75/24 198.3.76/24 198.3.77/24 198.3.78/24 198.3.79/24 \ 156.73/16 192.251.131/24 192.67.98/24 198.3.0/24 198.3.12/24 198.3.134/24 \ 198.3.152/24 198.3.153/24 198.3.154/24 198.3.155/24 198.3.38/24 198.3.39/24 \ 198.6.131/24 198.6.132/24 198.6.133/24 198.6.134/24 198.6.135/24 \ 198.6.136/24 198.6.137/24 198.6.138/24 198.6.139/24 198.6.140/24 \ 198.6.141/24 198.6.142/24 198.6.143/24 198.6.144/24 198.6.145/24 \ 198.6.146/24 198.6.147/24 198.6.148/24 198.6.149/24 198.6.151/24 \ 198.6.152/24 198.6.153/24 198.6.154/24 198.6.155/24 198.6.156/24 \ 198.6.157/24 198.6.158/24 198.6.159/24 198.6.161/24 198.6.162/24 \ 198.6.163/24 198.6.164/24 198.6.165/24 198.6.166/24 198.6.167/24 \ 198.6.168/24 198.6.169/24 198.6.170/24 198.6.171/24 198.6.172/24 \ 198.6.173/24 198.6.174/24 198.6.175/24 198.6.176/24 198.6.177/24 \ 198.6.178/24 198.6.179/24 198.6.180/24 198.6.181/24 198.6.182/24 \ 198.6.183/24 198.6.184/24 198.6.185/24 198.6.186/24 198.6.187/24 \ 198.6.188/24 198.6.189/24 198.6.190/24 198.6.191/24 192.58.97/24 \ 198.3.238/24 198.3.248/24 198.3.249/24 198.3.250/24 198.3.251/24 \ 198.4.32/24 198.4.33/24 198.4.34/24 198.4.35/24 198.4.36/24 198.4.37/24 \ 198.4.38/24 198.4.39/24 198.4.40/24 198.4.41/24 198.4.42/24 198.4.43/24 \ 198.4.44/24 198.4.45/24 198.4.46/24 198.4.47/24 157.54/16 157.55/16 \ 157.56/16 157.57/16 157.58/16 157.59/16 157.60/16 157.61/16 198.3.255/24 \ 198.4.14/24 198.4.54/24 198.4.55/24 192.101.77/24 192.160.28/24 198.4.93/24 \ 198.4.108/24 198.4.109/24 198.4.110/24 198.4.111/24 198.4.112/24 \ 198.4.113/24 198.4.114/24 198.4.115/24 198.51.36/24 192.131.73/24 \ 192.245.122/24 192.245.123/24 192.245.124/24 192.245.125/24 198.136.155/24 \ 198.4.128/24 198.4.129/24 198.4.130/24 198.4.131/24 198.4.132/24 \ 198.4.133/24 198.4.134/24 198.4.135/24 198.4.136/24 198.4.137/24 \ 198.4.138/24 198.4.139/24 198.4.140/24 198.4.141/24 198.4.142/24 \ 198.4.143/24 198.4.164/24 198.4.181/24 198.4.183/24 198.4.198/24 \ 198.4.189/24 198.4.190/24 198.4.191/24 151.139/16 198.147.129/24 \ 198.147.130/24 198.147.131/24 198.147.132/24 198.147.133/24 198.206.195/24 \ 198.4.192/24 198.4.193/24 198.4.194/24 198.4.195/24 198.4.197/24 \ 198.4.204/24 198.4.207/24 198.178.231/24 198.180.192/24 147.85/16 \ 192.234.103/24 196.1.1/24 198.4.199/24 198.4.247/24 198.5.160/24 \ 198.5.162/24 198.5.167/24 198.5.17/24 198.5.181/24 198.5.19/24 198.5.2/24 \ 162.62/16 167.8/16 198.137.232/24 198.5.183/24 198.5.185/24 198.5.186/24 \ 198.5.221/24 198.5.31/24 198.6.10/24 198.6.77/24 202.14.117/24 202.28.0/24 \ 148.174/16 198.6.2/24 198.6.8/24 202.41.129/24 198.5.21/24 199.33.236/24 \ 167.104/16 198.6.78/24 198.6.96/24 198.6.67/24 198.6.64/24 198.6.65/24 \ 198.6.224/24 204.179.169/24 198.5.255/24 198.6.118/24 198.6.119/24 \ 198.6.195/24 199.170.1/24 144.142/16 160.65/16 192.187.65/24 198.148.155/24 \ 198.187.230/24 198.6.251/24 199.170.16/24 198.6.202/24 198.6.220/24 \ 198.6.193/24 198.6.199/24 199.170.10/24 199.170.11/24 199.170.12/24 \ 199.170.13/24 199.170.14/24 199.170.15/24 199.170.8/24 199.170.9/24 \ 199.68.100/24 199.68.101/24 199.68.64/24 199.68.66/24 199.68.67/24 \ 199.68.68/24 199.68.69/24 199.68.70/24 199.68.71/24 199.68.72/24 \ 199.68.73/24 199.68.74/24 199.68.75/24 199.68.76/24 199.68.77/24 \ 199.68.78/24 199.68.79/24 199.68.80/24 199.68.81/24 199.68.82/24 \ 199.68.83/24 199.68.84/24 199.68.85/24 199.68.86/24 199.68.87/24 \ 199.68.88/24 199.68.89/24 199.68.90/24 199.68.91/24 199.68.92/24 \ 199.68.93/24 199.68.94/24 199.68.95/24 199.68.96/24 199.68.97/24 \ 199.68.98/24 199.68.99/24 192.132.217/24 192.206.205/24 192.206.206/24 \ 192.206.207/24 192.206.208/24 192.206.209/24 192.206.210/24 192.241.16/24 \ 192.241.17/24 192.241.18/24 192.241.19/24 192.241.20/24 192.241.21/24 \ 192.241.22/24 192.241.23/24 192.241.24/24 192.241.25/24 192.241.26/24 \ 192.241.27/24 192.241.28/24 192.241.29/24 192.241.30/24 192.241.31/24 \ 192.206.206/23 192.206.208/23 192.241.16/20 199.68.66/23 199.68.68/22 \ 199.68.72/21 199.68.80/20 199.68.96/22 199.68.100/23 199.170.8/21 \ 198.4.190/23 192.245.122/23 192.245.124/23 198.3.152/22 198.3.38/23 \ 198.3.64/20 198.3.8/21 198.147.130/23 198.147.132/23 198.4.108/22 \ 198.3.248/22 198.4.32/20 198.4.192/22 198.5.188/23 198.6.64/23 198.6.100/22 \ 192.187.66/23 192.187.68/22 192.187.72/21 192.187.80/20 198.6.104/21 \ 198.6.248/23 192.203.46/23 192.58.98/23 192.58.100/23 204.179.0/18 \ 204.176.146/24 199.171.53/24 198.6.196/24 204.176.36/24 204.176.37/24 \ 204.176.38/24 204.176.39/24 204.176.141/24 199.171.0/24 199.171.1/24 \ 199.171.2/24 199.171.3/24 204.177.181/24 204.176.174/24 204.177.177/24 \ 169.152/16 204.177.156/24 204.177.157/24 204.177.158/24 204.177.159/24 \ 204.177.179/24 204.177.72/24 204.177.73/24 204.177.74/24 204.177.75/24 \ 165.94/16 199.170.143/24 204.176.124/24 196.12.54/24 204.178.192/23 \ 204.179.91/24 196.10.230/24 196.13.232/24 196.6.248/24 204.179.97/24 \ 204.252.64/23 204.252.14/24 204.252.104/24 } The next policy covers 421 networks announced only via the CIX. remark: homeas policy: 701 : 1:701:84 2:701:64 3:2149 4:174 (48/2756) remark: policy item for 701: 3:2149 as-in: from AS2149 3 accept { 137.102/16 149.19/16 137.46/16 146.180/16 \ 149.74/16 149.77/16 192.246.149/24 157.126/16 198.242.36/24 198.242.61/24 \ 198.242.62/24 165.159/16 199.29.53/24 199.29.96/24 199.29.97/24 \ 199.29.98/24 199.29.99/24 199.29.100/24 199.29.101/24 199.29.102/24 \ 199.29.103/24 199.29.104/24 199.29.105/24 199.29.106/24 199.29.107/24 \ 199.29.108/24 199.29.109/24 199.29.110/24 199.29.111/24 199.29.112/24 \ 199.29.113/24 199.29.114/24 199.29.115/24 199.29.116/24 199.29.117/24 \ 199.29.118/24 199.29.119/24 199.29.120/24 199.29.121/24 199.29.122/24 \ 199.29.123/24 199.29.124/24 199.29.125/24 199.29.126/24 199.29.127/24 \ 198.153.232/24 192.40.65/24 199.98.125/24 } remark: policy item for 701: 4:174 as-in: from AS174 4 accept { 137.102/16 149.19/16 137.46/16 146.180/16 \ 149.74/16 149.77/16 192.246.149/24 157.126/16 198.242.36/24 198.242.61/24 \ 198.242.62/24 165.159/16 199.29.53/24 199.29.96/24 199.29.97/24 \ 199.29.98/24 199.29.99/24 199.29.100/24 199.29.101/24 199.29.102/24 \ 199.29.103/24 199.29.104/24 199.29.105/24 199.29.106/24 199.29.107/24 \ 199.29.108/24 199.29.109/24 199.29.110/24 199.29.111/24 199.29.112/24 \ 199.29.113/24 199.29.114/24 199.29.115/24 199.29.116/24 199.29.117/24 \ 199.29.118/24 199.29.119/24 199.29.120/24 199.29.121/24 199.29.122/24 \ 199.29.123/24 199.29.124/24 199.29.125/24 199.29.126/24 199.29.127/24 \ 198.153.232/24 192.40.65/24 199.98.125/24 } There are 48 nets with the same policy as the first set but with additional backups trough PSI. remark: homeas policy: 701 : 1:701:84 2:701:64 3:2551 (20/2756) remark: policy item for 701: 3:2551 as-in: from AS2551 3 accept { 192.235.51/24 192.235.32/24 192.235.33/24 \ 192.235.34/24 192.235.35/24 192.235.36/24 192.235.37/24 192.235.38/24 \ 192.235.39/24 192.235.40/24 192.235.41/24 192.235.42/24 192.235.43/24 \ 192.235.44/24 192.235.45/24 192.235.46/24 192.235.47/24 192.235.48/24 \ 192.235.49/24 192.235.50/24 } The are 20 nets with backup through AS 2551. remark: homeas policy: 701 : 1:701:84 2:701:64 3:97 (6/2756) remark: policy item for 701: 3:97 as-in: from AS97 3 accept { 158.118/16 192.20.225/24 149.150/16 159.70/16 \ 192.128.121/24 192.128.161/24 } There are 6 nets with backup through JVNC. remark: homeas policy: 701 : 1:701:84 2:701:64 3:1240 4:1800 (4/2756) remark: policy item for 701: 3:1240 as-in: from AS1240 3 accept { 192.83.221/24 198.3.121/24 198.3.150/24 \ 198.3.151/24 } remark: policy item for 701: 4:1800 as-in: from AS1800 4 accept { 192.83.221/24 198.3.121/24 198.3.150/24 \ 198.3.151/24 } There are 4 nets with SprintLink and ICM backup. remark: homeas policy: 701 : 1:701:84 2:701:64 3:200:8 4:200:136 (2/2756) remark: policy item for 701: 3:200:8 as-in: from AS200 3 accept { 131.106/16 198.31.14/24 } interas-in: from AS200 ENSS128 * (pref=3) accept { 131.106/16 198.31.14/24 } remark: policy item for 701: 4:200:136 interas-in: from AS200 ENSS144 * (pref=4) accept { 131.106/16 198.31.14/24 } There are two nets with barrnet backup. remark: homeas policy: 701 : 1:701:84 2:701:64 4:2149 5:174 (2/2756) remark: policy item for 701: 4:2149 as-in: from AS2149 4 accept { 147.81/16 192.26.98/24 } remark: policy item for 701: 5:174 as-in: from AS174 5 accept { 147.81/16 192.26.98/24 } There are two nets with a different variety of PSI backup. remark: homeas policy: 701 : 1:3561:5 2:3561:450 3:200:8 4:200:136 5:701:84 \ 6:701:64 (1/2756) remark: policy item for 701: 1:3561:5 as-in: from AS3561 1 accept { 129.18/16 } interas-in: from AS3561 DNSS11 * (pref=1) accept { 129.18/16 } remark: policy item for 701: 2:3561:450 interas-in: from AS3561 ENSS218 * (pref=2) accept { 129.18/16 } remark: policy item for 701: 3:200:8 as-in: from AS200 3 accept { 129.18/16 } interas-in: from AS200 ENSS128 * (pref=3) accept { 129.18/16 } remark: policy item for 701: 4:200:136 interas-in: from AS200 ENSS144 * (pref=4) accept { 129.18/16 } remark: policy item for 701: 5:701:84 as-in: from AS701 5 accept { 129.18/16 } interas-in: from AS701 ENSS136 * (pref=5) accept { 129.18/16 } remark: policy item for 701: 6:701:64 interas-in: from AS701 ENSS134 * (pref=6) accept { 129.18/16 } There is one net with primary through MCI (maybe a DMZ). remark: homeas policy: 701 : 1:701:84 2:701:64 3:3561:450 4:3561:5 5:560 \ (1/2756) remark: policy item for 701: 3:3561:450 as-in: from AS3561 3 accept { 144.212/16 } interas-in: from AS3561 ENSS218 * (pref=3) accept { 144.212/16 } remark: policy item for 701: 4:3561:5 interas-in: from AS3561 DNSS11 * (pref=4) accept { 144.212/16 } remark: policy item for 701: 5:560 as-in: from AS560 5 accept { 144.212/16 } There is one net with backup through MCI and someone else. remark: homeas policy: 701 : 1:701:84 2:701:64 3:3561:450 4:3561:5 5:279 \ (1/2756) remark: policy item for 701: 3:3561:450 as-in: from AS3561 3 accept { 192.41.177/24 } interas-in: from AS3561 ENSS218 * (pref=3) accept { 192.41.177/24 } remark: policy item for 701: 4:3561:5 interas-in: from AS3561 DNSS11 * (pref=4) accept { 192.41.177/24 } remark: policy item for 701: 5:279 as-in: from AS279 5 accept { 192.41.177/24 } There is one net with MCI and a different someone else. remark: homeas policy: 701 : 1:701:84 2:701:64 3:209 4:210 (1/2756) remark: policy item for 701: 3:209 as-in: from AS209 3 accept { 158.114/16 } remark: policy item for 701: 4:210 as-in: from AS210 4 accept { 158.114/16 } And one net with backup through AS 209 and 210. remark: homeas policy: 701 : 1:701:84 2:701:64 3:3561:450 4:3561:5 5:1225:27 \ 6:1225:18 7:1225:34 (1/2756) remark: policy item for 701: 3:3561:450 as-in: from AS3561 3 accept { 192.104.32/24 } interas-in: from AS3561 ENSS218 * (pref=3) accept { 192.104.32/24 } remark: policy item for 701: 4:3561:5 interas-in: from AS3561 DNSS11 * (pref=4) accept { 192.104.32/24 } remark: policy item for 701: 5:1225:27 as-in: from AS1225 5 accept { 192.104.32/24 } interas-in: from AS1225 ENSS130 * (pref=5) accept { 192.104.32/24 } remark: policy item for 701: 6:1225:18 interas-in: from AS1225 ENSS129 * (pref=6) accept { 192.104.32/24 } remark: policy item for 701: 7:1225:34 interas-in: from AS1225 ENSS131 * (pref=7) accept { 192.104.32/24 } One net with yet another MCI backup plan... remark: homeas policy: 701 : 1:701:84 2:701:64 3:1740:71 (1/2756) remark: policy item for 701: 3:1740:71 as-in: from AS1740 3 accept { 192.215.6/24 } interas-in: from AS1740 ENSS135 * (pref=3) accept { 192.215.6/24 } Backup through 1740. One net again. remark: homeas policy: 701 : 1:1327 2:701:84 3:701:64 (1/2756) remark: policy item for 701: 1:1327 as-in: from AS1327 1 accept { 198.83.2/24 } remark: policy item for 701: 2:701:84 as-in: from AS701 2 accept { 198.83.2/24 } interas-in: from AS701 ENSS136 * (pref=2) accept { 198.83.2/24 } remark: policy item for 701: 3:701:64 interas-in: from AS701 ENSS134 * (pref=3) accept { 198.83.2/24 } One net with primary through AS 1327. remark: homeas policy: 701 : 1:701:84 2:701:64 3:195 (1/2756) remark: policy item for 701: 3:195 as-in: from AS195 3 accept { 153.16/16 } remark: homeas policy: 701 : 1:97 (1/2756) remark: policy item for 701: 1:97 as-in: from AS97 1 accept { 140.212/16 } remark: homeas policy: 701 : 1:3561:450 2:3561:5 3:560 4:701:84 5:701:64 \ (1/2756) remark: policy item for 701: 1:3561:450 as-in: from AS3561 1 accept { 134.62/16 } interas-in: from AS3561 ENSS218 * (pref=1) accept { 134.62/16 } remark: policy item for 701: 2:3561:5 interas-in: from AS3561 DNSS11 * (pref=2) accept { 134.62/16 } remark: policy item for 701: 3:560 as-in: from AS560 3 accept { 134.62/16 } remark: policy item for 701: 4:701:84 as-in: from AS701 4 accept { 134.62/16 } interas-in: from AS701 ENSS136 * (pref=4) accept { 134.62/16 } remark: policy item for 701: 5:701:64 interas-in: from AS701 ENSS134 * (pref=5) accept { 134.62/16 } remark: homeas policy: 701 : 1:2551 2:701:84 3:701:64 (1/2756) remark: policy item for 701: 1:2551 as-in: from AS2551 1 accept { 198.211.110/24 } remark: policy item for 701: 2:701:84 as-in: from AS701 2 accept { 198.211.110/24 } interas-in: from AS701 ENSS136 * (pref=2) accept { 198.211.110/24 } remark: policy item for 701: 3:701:64 interas-in: from AS701 ENSS134 * (pref=3) accept { 198.211.110/24 } remark: homeas policy: 701 : 1:701:84 2:701:64 3:174 (1/2756) remark: policy item for 701: 3:174 as-in: from AS174 3 accept { 146.99/16 } remark: homeas policies: 71 : 1:3561:5 2:3561:450 3:200:8 4:200:136 5:2149 \ 6:174 7:560 + 1:3561:5 2:3561:450 3:200:8 4:200:136 + 1:3561:5 2:3561:450 \ 3:200:8 4:200:136 5:174 6:560 + 1:2149 2:174 3:3561:5 4:3561:450 5:200:8 \ 6:200:136 7:560 Five more policies with one network each. Seems like this could be simplified quite a bit. -------- Logged at Tue Mar 14 20:01:30 MET 1995 --------- From cengiz at ISI.EDU Tue Mar 14 20:00:49 1995 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Tue, 14 Mar 1995 11:00:49 -0800 Subject: AS path extensions In-Reply-To: <199503140146.UAA25354@ns.mci.net> References: <199503132215.AA15414@cat.isi.edu> <199503140146.UAA25354@ns.mci.net> Message-ID: <199503141900.AA17938@cat.isi.edu> Dennis, Thanks for the clarification. Dennis Ferguson (dennis at mci.net) on March 13: > Cengiz, > > > Cisco is using a different syntax which is closer to grep. However, > > gated's as path syntax misses a feature that I think is important. > > Perhaps I should use the posix syntax as Daniel suggested. > [...] > > It is not possible to specify ranges, and negation of ranges > > (i.e. [AS1 - AS100] or [^AS1]). I do not think one can specify an as > > path expression for "as paths not containing AS100" without listing > > all 65K AS numbers in that expression. This would be > > "^[^AS100]*$". There are other advantages of ranges, they reduce the > > number of states in the compiled pattern. > > I'm currently independently reworking some of this stuff for a gated v4.0 > someday. I've included negation, so the above pattern becomes (I think) > "(!100)*". Ranges are not supported, not necessarily because they couldn't > be supported within the syntax but rather because I'm having difficulty > figuring out why one would want them other than to hack around the lack > of negation. Neat. I need a clarification. Do you allow negation of any regular expression or just negation of as numbers? If you allow just the negation of as numbers, how do you represent [^100 200]*, i.e. as paths containing neither 100 nor 200? I was referring to anything that goes into "[" "]" in grep as ranges. You are probably right that expressions like [100-200] is not too useful. > > Note that your last sentence isn't true for my reimplementation (I'm not even > sure it was before), ranges don't reduce the number of states in the compiled > pattern compared to or'd lists. Since long lists of |'d AS numbers occur > frequently, patterns of the form ( 86 | 200 | 201 | ... ) also compile to > a single state in the DFA in a data structure which makes the actual match > pretty fast. Nice. > > > AS65535)*". This is a short term fix. I think more grep like syntax is > > desired. > > I can't figure out the grep-like part. I'm pretty sure there is nothing > which can be written in grep-like syntax which can't be represented in > the syntax gated uses, and I suspect the reverse probably true as well > (with some proviso's, for example it isn't clear to me how one would do > > .* (1239 | 1240 | (86 179)) > > in grep without blowing it out to multiple lines, and multiple line regexp's > will very likely be either harder to compile efficiently or slower to execute). > I think you're complaining about features rather than syntax, features can > be added to either syntax. Oh no, I am not complaining. I think the context of my message was missing. I am extending ripe-181 to allow specification of as path expression. Curtis suggested to use the gated syntax for regular expressions in my extensions. I have not picked gated's syntax because it lacked negation and ranges. > > The other thing the reimplementation does is attempt to do something with > AS sets. In particular, > > 86 .* [200 201 .*] > > matches a path beginning with 86 (or a set which includes 86) and ending with > a set which includes at least 200 and 201. > > [86] .* [200 201] > > matches a path with an initial sequence starting with AS 86 and ending with > a set of exactly 200 and 201. This is also neat. May I suggest not to use "[" and "]", because people will confuse them with grep's "[" and "]", especially if we pick "[" and "]" to mean ranges in the registry. > I do this as > > import as-path-exp-1 preference 1 { > net ... > net ... > all continue ; > } ; > import as-paths-exp-2 preference 2 { > net ... > net ... > all restrict ; > } ; This would be perfect. Is this implemented? Cengiz P.S. In Danvers IETF, there is a Routing Policy System BOF to define a language for specifying routing policies (mailing list rps at isi.edu). It is on thursday morning. -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California -------- Logged at Wed Mar 15 11:09:30 MET 1995 --------- From David.Kessens at ripe.net Wed Mar 15 11:07:42 1995 From: David.Kessens at ripe.net (David.Kessens at ripe.net) Date: Wed, 15 Mar 1995 11:07:42 +0100 (MET) Subject: Status and distribution of RIPE client (etc) In-Reply-To: <199503131754.MAA16322@home.merit.edu> from "Dale S. Johnson" at Mar 13, 95 12:54:54 pm Message-ID: <9503151007.AA21685@mature.ripe.net> A non-text attachment was scrubbed... Name: not available Type: text Size: 2750 bytes Desc: not available Url : https://www.ripe.net/mailman/private/rr-impl/attachments/19950315/2f57f9ef/attachment.ksh From David.Kessens at ripe.net Wed Mar 15 11:18:48 1995 From: David.Kessens at ripe.net (David.Kessens at ripe.net) Date: Wed, 15 Mar 1995 11:18:48 +0100 (MET) Subject: more whois In-Reply-To: <199503131811.NAA17120@home.merit.edu> from "Dale S. Johnson" at Mar 13, 95 01:11:28 pm Message-ID: <9503151018.AA21726@mature.ripe.net> A non-text attachment was scrubbed... Name: not available Type: text Size: 2806 bytes Desc: not available Url : https://www.ripe.net/mailman/private/rr-impl/attachments/19950315/9c34f80b/attachment.asc From dennis at mci.net Thu Mar 16 15:33:42 1995 From: dennis at mci.net (Dennis Ferguson) Date: Thu, 16 Mar 1995 09:33:42 -0500 Subject: AS path extensions In-Reply-To: Your message of "Tue, 14 Mar 1995 11:00:49 PST." <199503141900.AA17938@cat.isi.edu> Message-ID: <199503161433.JAA19891@ns.mci.net> Cengiz, > Neat. I need a clarification. Do you allow negation of any regular > expression or just negation of as numbers? If you allow just the > negation of as numbers, how do you represent [^100 200]*, i.e. as > paths containing neither 100 nor 200? The syntax in principle allows negation of any regular expression, and the code might some day, but because I couldn't figure out how to rewire arbitrary REs the code that exists bails out if the expression being negated looks too ugly. To answer the particular question, however, (!(100 | 200))* should work fine. >> I do this as >> >> import as-path-exp-1 preference 1 { >> net ... >> net ... >> all continue ; >> } ; >> import as-paths-exp-2 preference 2 { >> net ... >> net ... >> all restrict ; >> } ; > > This would be perfect. Is this implemented? A lot of code implementing specific functions has been written, but there is still some work to do on the gated it is supposed to run in. We tried to add a whole bunch of new stuff to the code simultaneously and ended up with a whole lot of work to do to get anything at all running. Dennis -------- Logged at Thu Mar 16 18:25:53 MET 1995 --------- From cengiz at ISI.EDU Thu Mar 16 18:25:23 1995 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Thu, 16 Mar 1995 09:25:23 -0800 Subject: AS path extensions In-Reply-To: <199503161433.JAA19891@ns.mci.net> References: <199503141900.AA17938@cat.isi.edu> <199503161433.JAA19891@ns.mci.net> Message-ID: <199503161725.AA23907@cat.isi.edu> Dennis, Thanks for the clarification. Your negation is the most powerful negation I have seen in any regular expression matching mechanism. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California -------- Logged at Thu Mar 16 23:07:02 MET 1995 --------- From cengiz at ISI.EDU Thu Mar 16 23:06:21 1995 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Thu, 16 Mar 1995 14:06:21 -0800 Subject: AS path extensions In-Reply-To: <199503140245.VAA00577@curtis.ansremote.com> References: <199503132215.AA15414@cat.isi.edu> <199503140245.VAA00577@curtis.ansremote.com> Message-ID: <199503162206.AA09858@cat.isi.edu> Curtis, Sorry that I took so long to reply. I tried to get a copy of the posix standard but failed. Someone told me gnu regexp library is posix compliant, and I looked there for the syntax. Curtis Villamizar (curtis at ans.net) on March 13: > > In message <199503132215.AA15414 at cat.isi.edu>, Cengiz Alaettinoglu writes: > > > > It is not possible to specify ranges, and negation of ranges > > (i.e. [AS1 - AS100] or [^AS1]). I do not think one can specify an as > > path expression for "as paths not containing AS100" without listing > > all 65K AS numbers in that expression. This would be > > "^[^AS100]*$". There are other advantages of ranges, they reduce the > > number of states in the compiled pattern. > > Ranges would be nice. As far as reducing states, this is not the > case, since gated internals automatically builds ranges where > appropriate. Neat. > > > Apparently, gated internals do support ranges. I asked this > > feature to be present in our route server implementation. Ramesh > > hacked gated, we can now specify ranges like (AS1 - AS100), and above > > as path expression can be written as "(AS1 - AS99 | AS101 - > > AS65535)*". This is a short term fix. I think more grep like syntax is > > desired. > > If you add ranges, POSIX and gated syntax have essentially the same > capability and in many cases the same operators. In fact, could you > point out which ones are different: > > . match anything > * zero to many > + one to many > ? zero or one > () grouping > | logical OR I think (I am not sure) | is different. In gnu regexp, foo|bar matches foo or bar. In gated, I think it matches fooar and fobar. This is a minor difference. > > gated also has > {m,n} > {m} > {m,} > > POSIX has > > ^ negate > [] equiv () with | actually posix has [] and [^] it does not have negate like Dennis has. > - range when used within [] Posix also has ^, $ to mean the beginning and end of a string. These two are not important, because posix does substring matching and gated does string matching. I.e. "9" will only match the string "9" in gated however will match any string containing 9 in posix. I think the two are equivalent. > > These would be easy to add to the parse and hook back into the asmatch > code. > > > Since we are at it, and you are the one who implemented as path > > matching in gated (correct me if I am wrong), there is another feature > > in gated that I had to find a fix around. Perhaps there is a better > > way of doing it. Again suggestions are very much appreciated. > > > > Lets say we want to import routes as follows: > > extended-as-in: AS1 1 as-path-exp-1 AND net-list-1 > > extended-as-in: AS1 2 as-path-exp-2 AND net-list-2 > > The ordering of these two terms in gated config file is very important > > since gated stops after finding the first as path match. But there can > > be as paths which are matched by the both expressions. That is, there > > is no correct ordering. > > This is not gated syntax, but extended ripe-181 with gated AS > matching. Code exists for this? OK. Some code exist that only understand the as paths of the form "AS# .*". I.e. the ones used in export filters. Full as path support will be added after IETF. > How about: > import as-path-exp-1 > net-list-1 pref 1 > all continue; > import as-paths-exp-2 > net-list-2 pref 2 > all restrict; I think "continue" is the right answer for this problem. 1> If this becomes a hardship (n becomes large), the config syntax could > be changed so you could make a specification like the extended > ripe-181 and the machinery gets built at run time more like what gated > needs to run fast. Don't ask who does this or when it gets done. Actually, Craig Labovitz of Merit was playing with this idea. I think he can input very simple ripe-181 policies to his gated and generate the machinery. Run time processing overhead was not one of his goals to optimize and it could not handle nested logical operators. > > What was the question again? :-) Thank you for your time, ideas and clarifications. > > Curtis Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California -------- Logged at Fri Mar 17 05:12:41 MET 1995 --------- From curtis at ans.net Fri Mar 17 04:42:59 1995 From: curtis at ans.net (Curtis Villamizar) Date: Thu, 16 Mar 1995 22:42:59 -0500 Subject: AS path extensions In-Reply-To: Your message of "Thu, 16 Mar 1995 14:06:21 PST." <199503162206.AA09858@cat.isi.edu> Message-ID: <199503170343.WAA01436@curtis.ansremote.com> In message <199503162206.AA09858 at cat.isi.edu>, Cengiz Alaettinoglu writes: > > What was the question again? :-) > > Thank you for your time, ideas and clarifications. Does this mean we are using gated RE syntax in the ripe-181 extensions? I hope so. Curtis -------- Logged at Fri Mar 17 17:32:32 MET 1995 --------- From dsj at merit.edu Fri Mar 17 17:30:49 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Fri, 17 Mar 1995 11:30:49 -0500 Subject: AS 690 aut-num progress (LONG!!!) Message-ID: <199503171630.LAA02552@home.merit.edu> Curtis, > There is one problem for which there is no way to express the > requirement in ripe-181. There is no way to specify an as-in line > (which is required and has no means restrict to specific peers) and no > way to specify that certain destinations are not accepted at all at > some peers using interas-in or as-in lines. This is need where we > peer with someone at two interconnects, accept one as primary and > don't accept the same set of routes from the other peering at all. There is a hack Cengiz came up with: Create a fake interas-in line for a non-existant interface, and give that line the same policy as the as-in line. (The current AS690 object in the RADB does this using local IP 0.0.0.0/32). That way any code following the spec will say "Ok; everything is accepted through the non-existant interface; I guess the other interfaces accept only what they explicitly list". --Dale -------- Logged at Fri Mar 17 20:10:04 MET 1995 --------- From cengiz at ISI.EDU Fri Mar 17 20:09:30 1995 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Fri, 17 Mar 1995 11:09:30 -0800 Subject: AS path extensions In-Reply-To: <199503170343.WAA01436@curtis.ansremote.com> References: <199503162206.AA09858@cat.isi.edu> <199503170343.WAA01436@curtis.ansremote.com> Message-ID: <199503171909.AA12044@cat.isi.edu> Curtis Villamizar (curtis at ans.net) on March 16: > Does this mean we are using gated RE syntax in the ripe-181 > extensions? I hope so. It will be posix, which is extended gated/cisco syntax. Anyone has an idea how to get a copy of the standard? Is it available on line somewhere? Thanks. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California -------- Logged at Fri Mar 17 22:50:02 MET 1995 --------- From curtis at ans.net Fri Mar 17 22:35:30 1995 From: curtis at ans.net (Curtis Villamizar) Date: Fri, 17 Mar 1995 16:35:30 -0500 Subject: AS 690 aut-num progress (LONG!!!) In-Reply-To: Your message of "Fri, 17 Mar 1995 11:30:49 EST." <199503171630.LAA02552@home.merit.edu> Message-ID: <199503172138.QAA00816@curtis.ansremote.com> In message <199503171630.LAA02552 at home.merit.edu>, "Dale S. Johnson" writes: > Curtis, > > > There is one problem for which there is no way to express the > > requirement in ripe-181. There is no way to specify an as-in line > > (which is required and has no means restrict to specific peers) and no > > way to specify that certain destinations are not accepted at all at > > some peers using interas-in or as-in lines. This is need where we > > peer with someone at two interconnects, accept one as primary and > > don't accept the same set of routes from the other peering at all. > > There is a hack Cengiz came up with: > > Create a fake interas-in line for a non-existant interface, and give > that line the same policy as the as-in line. (The current AS690 object > in the RADB does this using local IP 0.0.0.0/32). That way any code > following the spec will say "Ok; everything is accepted through the > non-existant interface; I guess the other interfaces accept only > what they explicitly list". > > --Dale Does this really do the trick? The problem is: as-in: from ASx 1 accept { x.y.z/24 } interas-in: from ASx 1.2.3.4 1.2.3.5 (pref=1) { x.y.z/24 } ?? interas-in: from ASx 2.3.4.5 2.3.4.6 (pref=NONE) { x.y.z/24 } ?? interas-in: from ASx 0.0.0.0 0.0.0.0 (pref=1) { x.y.z/24 } The first makes sense to me. Router 2.3.4.5 does not accept x.y.z/24. The second doesn't make sense. If router 1.2.3.4 accepts x.y.z/24, does that mean no other router does? If so, then this is a non-problem. On rereading, this appears to be the case. Also in the object I sent, "except" should have been "AND NOT" when used in the format "accept ASx AND NOT { x.y.z/24 }". Curtis -------- Logged at Fri Mar 17 23:08:51 MET 1995 --------- From cengiz at ISI.EDU Fri Mar 17 23:08:23 1995 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Fri, 17 Mar 1995 14:08:23 -0800 Subject: AS 690 aut-num progress (LONG!!!) In-Reply-To: <199503140456.XAA00831@curtis.ansremote.com> References: <199503140456.XAA00831@curtis.ansremote.com> Message-ID: <199503172208.AA12294@cat.isi.edu> Hi Curtis, I went over your mail, well at least the beginning part. I have to say I am impressed. I think this is a nice way of expressing AS690's policy. It is a more natural way than db_selects. However, it is not in the true ripe-181 spirit (which is OK) in that it is still on a per route/homeas basis. That is as opposed to listing all routes that you import with preference 1 form 3561 (i.e. 109, 114), you separate them so that all routes of 109 are listed next to each other. This is probably the best way considering how prdb is organized. About the oddball routes. PRDB has 45K routes registered whereas only 21K were actually active when I last checked it in January. I think these 24K routes which are no longer being announced to the ANSNet might be contributing to the oddballs. It would be nice to throw them away, and I think it would make the ANS router configs more efficient, i.e. smaller network lists. More comments below. Curtis Villamizar (curtis at ans.net) on March 13: > > Hi all, > > A first cut of AS 690 inbound policy is done. I think it is accurate, > but haven't checked against gated configs, so I can't yet be sure. > I'd like comments of the method and on some of the syntax extensions > we will be using internally. In all cases where the capability exists > in ripe-181, short cut syntax (like wildcards in interas-in lines) > will be expanded before sending to a public database. > > I just partially manually rechecked the results and while doing so > wrote some comments in the current output. The annotated partial > aut-num object is below. Early comments please. > > There is one problem for which there is no way to express the > requirement in ripe-181. There is no way to specify an as-in line > (which is required and has no means restrict to specific peers) and no > way to specify that certain destinations are not accepted at all at > some peers using interas-in or as-in lines. This is need where we > peer with someone at two interconnects, accept one as primary and > don't accept the same set of routes from the other peering at all. I can not say I understand what you mean in the above paragraph. If you do not want to accept a route, in ripe 181, you do not list it in your as-in lines. By default it is rejected. There is no explicit way of saying "reject 128.8/16". I think like gated, a preference of -1 would be useful. > > The current code currently does not have the ability to make the check > needed to add the reject, but if we get a syntax, adding the code > would not be difficult. One method would be a post processing phase > which can note that where interas-in lines are used but where some > peering sessions are not covered by the interas-in lines and will be > used as last resorts (unintentionally). > > The next step is either outbound policy or partial gated configs to > check the inet-rtr objects and inbound policy. Outbound policy looks > a lot easier than inbound, but I will need the extended syntax that > supports AS path (at least to specify border AS that we learned the > route from). I'm going to use gated syntax and not bother to call the > field extended-something unless a consensus emerges real quickly. rtconfig will work if you do not call these attributes extended-something, but all other tools will give syntax errors. I reccomend to use extended-something attributes. > > Curtis > > btw- the complete objects as they now stand are at: > http://tweedledee.ans.net:8001/prdb-radb > > These are generated from a PRDB snapshot taken Feb 21. The idea is to > build the tool, compare to gated configs of the same vintage, then > redo the snapshot more recently and compare, then start doing real > config runs from the ANS-DB and submit our stuff to the RADB. This > has to be well coordinated with Merit and others. > > > > This is part of the AS 690 ripe-181 aut-num object, annotated > to show how the lines are derived and why. > > aut-num: AS690 > as-name: ASN-NSFNET-T3-RT > description: ANSNET (the former NSFNET backbone) > guardian: as690-guardian at ans.net I think the guardian attribute is history. > tech-c: noc at ans.net > admin-c: config at ans.net > notify: config-notify at ans.net > source: ANS Ripe database reorders attributes. That is all remark lines will be moved after the (inter)?as-* lines. So the comments will be much after where they should be. I think we (i.e. rr-impl) should change this. (Dale is this right?) Ripe database will also give a syntax error to line continuations with \. Perhaps we should add this. Currently, to continue, you need to repeat the last attribute: remark: homeas policies: 109 : 1:3561:5 2:3561:450 3:200:8 4:200:136 + remark: 1:3561:5 2:3561:450 3:200:8 4:200:136 5:1740:71 + 1:3561:5 2:3561:450 remark: 3:200:8 4:200:136 5:1740:450 6:1740:71 + 1:1957 More pain with policy lines, you need to repeat everything upto the policy expression: as-in: from AS1 1 accept ANY AND NOT as-in: from AS1 1 accept AS10 is equivalent to as-in: from AS1 1 accept ANY AND NOT \ AS10 Daniel, is it too hard to support line continuations based on \? > > This is all fixed and can easily be changed if the guesses at > reasonable fields are not incorrect. > > The remainder of the aut-num object is then the inbound policy > for AS 690. This is grouped by home AS number. > > remark: homeas policies: 109 : 1:3561:5 2:3561:450 3:200:8 4:200:136 + \ > 1:3561:5 2:3561:450 3:200:8 4:200:136 5:1740:71 + 1:3561:5 2:3561:450 \ > 3:200:8 4:200:136 5:1740:450 6:1740:71 + 1:1957 > > This remark lists the policies for home AS 109. There are > four policies on this line, separated by plus (+). Line > continuation uses the backslash. If that upsets true ripe-181 > implementations, then line continuations can be removed and > the very long lines submitted to the RA or other outside database. > > The individual policies are then treated in order of the > number of routes which they cover. I've compressed some white > space out in a few places to avoid some line continuations. > > remark: homeas policy: 109 : 1:3561:5 2:3561:450 3:200:8 4:200:136 (4/9) > > This line indicates that one home AS policy for AS 109 is > being expressed, the policy "1:3561:5 2:3561:450 3:200:8 > 4:200:136" which covers four of the nine networks for AS 109. > The third value in some tuples is a database index to the ENSS > where the policy entry applies. > > remark: policy item for 109: 1:3561:5 > as-in: from AS3561 1 accept AS109 except { 192.150.49/24 } > interas-in: from AS3561 DNSS11 * (pref=1) accept AS109 except { 192.150.49/24 } Way to say "except" in ripe 181 is to say "AND NOT". AND/OR/NOT are actually set operations intersection/union/complement. except which is set-minus is equivalent to "AND NOT". > > The first item in the policy can be expressed as an AS list > with one exception. All of the policies contain the tuple > 1:3561:5, except one policy, 1:1957, which contains one > network 192.150.49/24. Any new route objects for AS 109 will > be handled by this policy entry. An as-in line is needed to > cover the interas-in line. There is no way in ripe-181 to > state that these nets are accepted at no other AS 3561 peering. I am not sure if I understand what you mean. But I think it is not true. That is: as-in: from AS3561 1 AS1 interas-in: from AS3561 ENSS218 * (pref=1) AS1 ensures that AS1 is not accepted in any other peering but ENSS218 *. There is an exception, that is if it is explicitly specified like: interas-in: from AS3561 ENSS99 * (pref=1) AS1 In which case it is also accepted on ENSS99. In other words, if you combine all routes that are accepted in interas-in lines, these routes are not imported on any other interface than the interfaces specified on the interas-in lines. Lets call this set of routes as combined-interas-in-routes. If you also combine all the routes accepted on as-in lines, and if you subtract the combined-interas-in-routes from this, the remaining routes are accepted on all peerings. I call these routes as left-over routes. > > Note that the from expression includes a wildcard. The > expression "AS3561 DNSS11 *" indicates all AS 3561 peers at > DNSS11. This is a ripe-181 extension and must also be > expanded based on the inet-rtr object before submitting to a > public database like the RA. > > The name DNSS11 must also be changed. DNSS in the router > names must be changed to CNSS. Many of the peer routers have > no names at all in the PRDB. DNS is being used to create a > name translation table to address this but hasn't been > applied. When it is, DNSS11 will be cnss11.t3.ans.net and the > interas-in line will be a bit longer. > > remark: policy item for 109: 2:3561:450 > interas-in: from AS3561 ENSS218 * (pref=2) accept AS109 except {192.150.49/24} > remark: policy item for 109: 3:200:8 > as-in: from AS200 3 accept AS109 except { 192.150.49/24 } > interas-in: from AS200 ENSS128 * (pref=3) accept AS109 except {192.150.49/24} > remark: policy item for 109: 4:200:136 > interas-in: from AS200 ENSS144 * (pref=4) accept AS109 except {192.150.49/24} > > The reamining three backup preferences are expressed using the > same AS expression with an exception of one network, since two > of the policies simply add a fifth and sixth preference. > These also require an as-in and interas-in line and suffer the > same problem of not being able to negate peerings. > > remark: homeaspolicy:109: 1:3561:5 2:3561:450 3:200:8 4:200:136 5:1740:71 (3/9) > > This is the next policy. All of the policy expressions have > already been covered except the fifth one. > > remark: policy item for 109: 5:1740:71 > as-in: from AS1740 5 accept { 131.108/16 192.31.7/24 198.93.160/19 } > interas-in: from AS1740 ENSS135 * (pref=5) accept \ > { 131.108/16 192.31.7/24 198.93.160/19 } Minor syntax problems. Ripe 181 requires four-quads, i.e. 131.108.0.0/16 instead of 131.108/16. Also, you are missing commas in your network lists: { 131.108.0.0/16, 192.31.7.0/24, 198.93.160.0/19 } > > The first four expressions are suppressed since they are > already covered by the AS109 specified in the first policy > group. Only the fifth entry in this policy must be stated. A > net list is used so new route objects don't inherit this. > [ ... ] > > Are we getting bored yet. If not look at the complete file > and add your own silly comments. :-) :-) Policy for 701 was fun. Curtis, The way you assigned preferences to interas-in lines and costs to as-in lines is interesting. In that you can impose "override as-in costs with interas-in preferences" and have the desired behavior. Without overriding, it is still the correct policy, however the preferences in the config files will reflect both the as-in costs and interas-in preferences and be different numbers than that appear on your policy. In your aut-num object, I have not seen a policy like: 1:3561:100 2:200:128 3:3561:111 which is not really expressible in ripe-181. Is this because there were not such policies or did you approximate those to something else. I hope my comments are useful. I have few more questions. I am asking these as input to RPSL design: 1) would it be easier if interas-in preferences were comparable to as-in costs and override as-in costs for the set of routes specifies in interas-in lines? 2) would it be easier if you did not need to specify an as-in to cover each interas-in line (kind of like an as-in line was there by default for each interas-in line)? 3) would it be easier if there was only as-in and no interas-in attributes but as-in allowed you to specify optional interface addresses. If the interface addresses are present, it would mean import criteria on this peering, if not present, it would mean import criteria on all other peerings? 4) any other suggestion that would have made your task easier. (I got the message that pref=reject is useful). Thanks. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California -------- Logged at Fri Mar 17 23:12:29 MET 1995 --------- From cengiz at ISI.EDU Fri Mar 17 23:11:57 1995 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Fri, 17 Mar 1995 14:11:57 -0800 Subject: AS 690 aut-num progress (LONG!!!) In-Reply-To: <199503172138.QAA00816@curtis.ansremote.com> References: <199503171630.LAA02552@home.merit.edu> <199503172138.QAA00816@curtis.ansremote.com> Message-ID: <199503172211.AA12303@cat.isi.edu> I just replied to your original message which covers these points. But, here they are again anyway. Curtis Villamizar (curtis at ans.net) on March 17: > > In message <199503171630.LAA02552 at home.merit.edu>, "Dale S. Johnson" writes: > > Curtis, > > > > > There is one problem for which there is no way to express the > > > requirement in ripe-181. There is no way to specify an as-in line > > > (which is required and has no means restrict to specific peers) and no > > > way to specify that certain destinations are not accepted at all at > > > some peers using interas-in or as-in lines. This is need where we > > > peer with someone at two interconnects, accept one as primary and > > > don't accept the same set of routes from the other peering at all. > > > > There is a hack Cengiz came up with: > > > > Create a fake interas-in line for a non-existant interface, and give > > that line the same policy as the as-in line. (The current AS690 object > > in the RADB does this using local IP 0.0.0.0/32). That way any code > > following the spec will say "Ok; everything is accepted through the > > non-existant interface; I guess the other interfaces accept only > > what they explicitly list". > > > > --Dale > > > Does this really do the trick? The problem is: > > as-in: from ASx 1 accept { x.y.z/24 } > interas-in: from ASx 1.2.3.4 1.2.3.5 (pref=1) { x.y.z/24 } with these two lines if you omit the following two lines, by definition x.y.z/24 is not accepted on 2.3.4.5 2.3.4.6 peering. > > ?? interas-in: from ASx 2.3.4.5 2.3.4.6 (pref=NONE) { x.y.z/24 } > > ?? interas-in: from ASx 0.0.0.0 0.0.0.0 (pref=1) { x.y.z/24 } > > The first makes sense to me. Router 2.3.4.5 does not accept x.y.z/24. > The second doesn't make sense. > > If router 1.2.3.4 accepts x.y.z/24, does that mean no other router > does? If so, then this is a non-problem. On rereading, this appears > to be the case. Yes. It is the case. > > Also in the object I sent, "except" should have been "AND NOT" when > used in the format "accept ASx AND NOT { x.y.z/24 }". Yes. > > Curtis Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California -------- Logged at Fri Mar 17 23:20:58 MET 1995 --------- From sbb at noc.ans.net Fri Mar 17 23:20:26 1995 From: sbb at noc.ans.net (Serpil Bayraktar) Date: Fri, 17 Mar 1995 22:20:26 UTC Subject: AS 690 aut-num progress (LONG!!!) In-Reply-To: Your message of "Fri, 17 Mar 1995 14:08:23 UTC." <199503172208.AA12294@cat.isi.edu> Message-ID: <199503172220.AA65096@knock.aa.ans.net> Cengiz, >About the oddball routes. PRDB has 45K routes registered whereas only >21K were actually active when I last checked it in January. I think >these 24K routes which are no longer being announced to the ANSNet >might be contributing to the oddballs. It would be nice to throw them >away, and I think it would make the ANS router configs more efficient, >i.e. smaller network lists. I don't have the exact figures but there are many routes that are covered by an aggregate and either not announced to AS 690 at all or announced along with the aggregate. We will try to remove these specific networks from AS 690 config files during the next couple of weeks. Serpil -------- Logged at Sat Mar 18 01:02:56 MET 1995 --------- From curtis at ans.net Sat Mar 18 00:55:49 1995 From: curtis at ans.net (Curtis Villamizar) Date: Fri, 17 Mar 1995 18:55:49 -0500 Subject: AS 690 aut-num progress (LONG!!!) In-Reply-To: Your message of "Fri, 17 Mar 1995 14:08:23 PST." <199503172208.AA12294@cat.isi.edu> Message-ID: <199503172357.SAA01127@curtis.ansremote.com> In message <199503172208.AA12294 at cat.isi.edu>, Cengiz Alaettinoglu writes: > > > Hi Curtis, > > I went over your mail, well at least the beginning part. I have to say > I am impressed. I think this is a nice way of expressing AS690's > policy. It is a more natural way than db_selects. However, it is not > in the true ripe-181 spirit (which is OK) in that it is still on a per > route/homeas basis. That is as opposed to listing all routes that you > import with preference 1 form 3561 (i.e. 109, 114), you separate them > so that all routes of 109 are listed next to each other. This is > probably the best way considering how prdb is organized. A longer term goal is to get rid of the exceptions and have a consistent policy across most if not all AS, aided by MEDs. > About the oddball routes. PRDB has 45K routes registered whereas only > 21K were actually active when I last checked it in January. I think > these 24K routes which are no longer being announced to the ANSNet > might be contributing to the oddballs. It would be nice to throw them > away, and I think it would make the ANS router configs more efficient, > i.e. smaller network lists. I though I already did this (me thinks). I ignore all routes with aconfigure or uconfigure set. > > There is one problem for which there is no way to express the > > requirement in ripe-181. There is no way to specify an as-in line > > (which is required and has no means restrict to specific peers) and no > > way to specify that certain destinations are not accepted at all at > > some peers using interas-in or as-in lines. This is need where we > > peer with someone at two interconnects, accept one as primary and > > don't accept the same set of routes from the other peering at all. > > I can not say I understand what you mean in the above paragraph. If > you do not want to accept a route, in ripe 181, you do not list it in > your as-in lines. By default it is rejected. There is no explicit way > of saying "reject 128.8/16". I'm not sure I knew what I was saying either. See exchange with Dale. > > The next step is either outbound policy or partial gated configs to > > check the inet-rtr objects and inbound policy. Outbound policy looks > > a lot easier than inbound, but I will need the extended syntax that > > supports AS path (at least to specify border AS that we learned the > > route from). I'm going to use gated syntax and not bother to call the > > field extended-something unless a consensus emerges real quickly. > > rtconfig will work if you do not call these attributes > extended-something, but all other tools will give syntax errors. I > reccomend to use extended-something attributes. OK. > > aut-num: AS690 > > as-name: ASN-NSFNET-T3-RT > > description: ANSNET (the former NSFNET backbone) > > guardian: as690-guardian at ans.net > > I think the guardian attribute is history. Spec says manditory. ? > Ripe database reorders attributes. That is all remark lines will > be moved after the (inter)?as-* lines. So the comments will be much > after where they should be. I think we (i.e. rr-impl) should change > this. (Dale is this right?) I'll submit in human readable format. Reordering is optional. :-) > Ripe database will also give a syntax error to line continuations with > \. Perhaps we should add this. Currently, to continue, you need to > repeat the last attribute: > > remark: homeas policies: 109 : 1:3561:5 2:3561:450 3:200:8 4:200:136 + > remark: 1:3561:5 2:3561:450 3:200:8 4:200:136 5:1740:71 + 1:3561:5 2:3561:450 > remark: 3:200:8 4:200:136 5:1740:450 6:1740:71 + 1:1957 Yuk. I'll just give you megalines and you can do what you want with them. I'm already postprocessing before submitting. > More pain with policy lines, you need to repeat everything upto the > policy expression: > > as-in: from AS1 1 accept ANY AND NOT > as-in: from AS1 1 accept AS10 > > is equivalent to > as-in: from AS1 1 accept ANY AND NOT \ > AS10 Megalines until resolved! > > as-in: from AS3561 1 accept AS109 except { 192.150.49/24 } > > interas-in: from AS3561 DNSS11 * (pref=1) accept AS109 except { 192.150.49/ > 24 } > > Way to say "except" in ripe 181 is to say "AND NOT". AND/OR/NOT are > actually set operations intersection/union/complement. except which is > set-minus is equivalent to "AND NOT". I noticed this a little late. > > The first item in the policy can be expressed as an AS list > > with one exception. All of the policies contain the tuple > > 1:3561:5, except one policy, 1:1957, which contains one > > network 192.150.49/24. Any new route objects for AS 109 will > > be handled by this policy entry. An as-in line is needed to > > cover the interas-in line. There is no way in ripe-181 to > > state that these nets are accepted at no other AS 3561 peering. > > I am not sure if I understand what you mean. But I think it is not > true. That is: > > as-in: from AS3561 1 AS1 > interas-in: from AS3561 ENSS218 * (pref=1) AS1 > > ensures that AS1 is not accepted in any other peering but ENSS218 *. > There is an exception, that is if it is explicitly specified like: > > interas-in: from AS3561 ENSS99 * (pref=1) AS1 > > In which case it is also accepted on ENSS99. > > In other words, if you combine all routes that are accepted in > interas-in lines, these routes are not imported on any other interface > than the interfaces specified on the interas-in lines. Lets call this > set of routes as combined-interas-in-routes. > > If you also combine all the routes accepted on as-in lines, and if you > subtract the combined-interas-in-routes from this, the remaining > routes are accepted on all peerings. I call these routes as left-over > routes. You have to look closely at the way policy is defined. For each home AS, there is one policy description (one or more as-in plus interas-in if needed that are expressed as: ... accept ASx AND NOT { ..some set of routes.. } All other policies for the home AS are expressed as: ... accept { ..some subset of above set.. } If a new route is added it falls into the policy: ... accept ASx AND NOT { ..some set of routes.. } meaning it gets the same primary, secondary, tertiary, etc, plus the same treatment relative to preferred routers for a given border AS. > > remark: policy item for 109: 5:1740:71 > > as-in: from AS1740 5 accept { 131.108/16 192.31.7/24 198.93.160/19 } > > interas-in: from AS1740 ENSS135 * (pref=5) accept \ > > { 131.108/16 192.31.7/24 198.93.160/19 } > > Minor syntax problems. Ripe 181 requires four-quads, i.e. > 131.108.0.0/16 instead of 131.108/16. Also, you are missing commas in > your network lists: { 131.108.0.0/16, 192.31.7.0/24, 198.93.160.0/19 } Thanks for pointing this out. These are easy. A different separator on the final join gets the commas and I already have functions that chop the net number or extend it back to a full quad. > :-) > > Policy for 701 was fun. It was amusing. > Curtis, > > The way you assigned preferences to interas-in lines and costs to > as-in lines is interesting. In that you can impose "override > as-in costs with interas-in preferences" and have the desired > behavior. Without overriding, it is still the correct policy, however > the preferences in the config files will reflect both the as-in > costs and interas-in preferences and be different numbers than that > appear on your policy. I'm using interas-in to break ties in as-in and putting the result in gated's preference. I'm not using cost for gated preference and preference for gated preference2. I'll recheck, but I think the policy is written such that this always works and what gated will do will match what ripe rules predict should happen. > In your aut-num object, I have not seen a policy like: > 1:3561:100 2:200:128 3:3561:111 > which is not really expressible in ripe-181. Is this because there > were not such policies or did you approximate those to something else. as-in: from AS3561 1 accept ASx interas-in: from AS3561 r100 * (pref=1) accept ASx as-in: from AS200 1 accept ASx <- **note below interas-in: from AS200 r128 * (pref=2) accept ASx interas-in: from AS3561 r111 * (pref=3) accept ASx Note: after the first time an interas-in line is used, the cost remains fixed and interas-in lines are used to express the remainder of the policy. This is the trick that makes gated rules and ripe rules come up with the same ordering but for different reasons. Gated would see the preferences. If the first entry didn't use interas-in, but the second did, cost would lock in as 2, and pref would take over from 2. > I hope my comments are useful. Yes very. Thanks. > I have few more questions. I am asking these as input to RPSL design: What's an RPSL? Sorry I'm new to this game. > 1) would it be easier if interas-in preferences were comparable to > as-in costs and override as-in costs for the set of routes > specifies in interas-in lines? Yes, but I'm managing to work around it. It's OK to keep it as is, since it reflects the way costs and type 2 externals work in OSPF and the way local_pref and MED work in BGP. > 2) would it be easier if you did not need to specify an as-in to cover > each interas-in line (kind of like an as-in line was there by > default for each interas-in line)? Yes. It would be even better if there was type of as-in with optional near and far end peer and an optional pref. I'm afraid it's too late to change this. > 3) would it be easier if there was only as-in and no interas-in > attributes but as-in allowed you to specify optional interface > addresses. If the interface addresses are present, it would mean > import criteria on this peering, if not present, it would mean > import criteria on all other peerings? Yes. > 4) any other suggestion that would have made your task easier. (I got > the message that pref=reject is useful). Not sure on this anymore. > Thanks. > > Cengiz Thanks for the comments. I'll try to keep you up to date on significant progress. Curtis -------- Logged at Mon Mar 20 14:31:57 MET 1995 --------- From lpj at merit.edu Mon Mar 20 14:31:47 1995 From: lpj at merit.edu (Laurent Joncheray) Date: Mon, 20 Mar 1995 08:31:47 -0500 (EST) Subject: PGP mods for RIPE-181 code In-Reply-To: <95Mar19.194917est.606787@enfm.utcc.utoronto.ca> from "Eric M. Carroll" at Mar 19, 95 07:48:59 pm Message-ID: <199503201331.IAA23549@home.merit.edu> I don't think RIPE has done anything. If you're interested i can put the patches/doc on our anonymous FTP server. There are pretty easy to install. Laurent In our previous episode, Eric M. Carroll said: > > Laurent, > > Have your PGP fixes been bought back by RIPE for their code? If not, > are your mods available? > > Eric Carroll University of Toronto Network & Operations Services > External Networking Facilities Management > -- Laurent Joncheray, E-Mail: lpj at merit.edu Merit Network Inc, 4251 Plymouth Rd, Suite C, Phone: +1 (313) 936 2065 Ann Arbor, MI 48105, USA Fax: +1 (313) 747 3185 "This is the end, Beautiful friend. This is the end, My only friend, the end" JM -------- Logged at Mon Mar 20 15:04:47 MET 1995 --------- From Daniel.Karrenberg at ripe.net Mon Mar 20 14:58:26 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 20 Mar 1995 14:58:26 +0100 Subject: PGP mods for RIPE-181 code In-Reply-To: Your message of Mon, 20 Mar 1995 08:31:47 EST. <199503201331.IAA23549@home.merit.edu> Message-ID: <9503201358.AA28216@ncc.ripe.net> What is needed is something that puts the public keys in the maintainer object and then verifies authenticiy of update messages. Last time I looked Laurent's stuff stored public keys locally outside the database. Has that changed? Daniel > Laurent Joncheray writes: > I don't think RIPE has done anything. If you're interested i > can put the patches/doc on our anonymous FTP server. There are pretty > easy to install. > Laurent > > In our previous episode, Eric M. Carroll said: > > > > Laurent, > > > > Have your PGP fixes been bought back by RIPE for their code? If not, > > are your mods available? > > > > Eric Carroll University of Toronto Network & Operations Services > > External Networking Facilities Management > > > > > -- > Laurent Joncheray, E-Mail: lpj at merit.edu > Merit Network Inc, 4251 Plymouth Rd, Suite C, Phone: +1 (313) 936 20 > 65 > Ann Arbor, MI 48105, USA Fax: +1 (313) 747 31 > 85 > "This is the end, Beautiful friend. This is the end, My only friend, the en > d" JM -------- Logged at Mon Mar 20 15:12:22 MET 1995 --------- From lpj at merit.edu Mon Mar 20 15:12:07 1995 From: lpj at merit.edu (Laurent Joncheray) Date: Mon, 20 Mar 1995 09:12:07 -0500 (EST) Subject: PGP mods for RIPE-181 code In-Reply-To: <9503201358.AA28216@ncc.ripe.net> from "Daniel Karrenberg" at Mar 20, 95 02:58:26 pm Message-ID: <199503201412.JAA25312@home.merit.edu> I use the mechanism provided with PGP to store the public keys, so the development and managment of public key software is already done. The storage of public key in the maintainer object is a implementation choice which has pro and cons and i prefer not been involved in such an argument. Right now the key are not in the the maintainer object, the software just authomaticly verifies the authenticity of the update messages. -- lpj In our previous episode, Daniel Karrenberg said: > > > What is needed is something that puts the public keys in the maintainer > object and then verifies authenticiy of update messages. Last time I > looked Laurent's stuff stored public keys locally outside the database. > Has that changed? > > Daniel > > > Laurent Joncheray writes: > > I don't think RIPE has done anything. If you're interested i > > can put the patches/doc on our anonymous FTP server. There are pretty > > easy to install. > > Laurent > > > > In our previous episode, Eric M. Carroll said: > > > > > > Laurent, > > > > > > Have your PGP fixes been bought back by RIPE for their code? If not, > > > are your mods available? > > > > > > Eric Carroll University of Toronto Network & Operations Services > > > External Networking Facilities Management > > > > > > > > > -- > > Laurent Joncheray, E-Mail: lpj at merit.edu > > Merit Network Inc, 4251 Plymouth Rd, Suite C, Phone: +1 (313) 936 20 > > 65 > > Ann Arbor, MI 48105, USA Fax: +1 (313) 747 31 > > 85 > > "This is the end, Beautiful friend. This is the end, My only friend, the en > > d" JM > -- Laurent Joncheray, E-Mail: lpj at merit.edu Merit Network Inc, 4251 Plymouth Rd, Suite C, Phone: +1 (313) 936 2065 Ann Arbor, MI 48105, USA Fax: +1 (313) 747 3185 "This is the end, Beautiful friend. This is the end, My only friend, the end" JM -------- Logged at Mon Mar 20 16:19:20 MET 1995 --------- From Daniel.Karrenberg at ripe.net Mon Mar 20 16:17:35 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 20 Mar 1995 16:17:35 +0100 Subject: PGP mods for RIPE-181 code In-Reply-To: Your message of Mon, 20 Mar 1995 09:12:07 EST. <199503201412.JAA25312@home.merit.edu> Message-ID: <9503201517.AA29042@ncc.ripe.net> > Laurent Joncheray writes: > I use the mechanism provided with PGP to store the public keys, > so the development and managment of public key software is already done. > The storage of public key in the maintainer object is a implementation > choice which has pro and cons and i prefer not been involved in such > an argument. Right now the key are not in the the maintainer object, the > software just authomaticly verifies the authenticity of the update > messages. Laurent, there are some practical problems with the implementation choices. You propose: > How to register a public key > > C.f. [PGP]. Sum up: generate the public key from you key ring > by using 'pgp -kxa '. > Send to the RR manager. > The RR call the user to check the public key (with the key's fingerprint) > and certify it. This introduces additional manual processing overhead that the RIPE NCC does not want now and that I am sure noone will want in the long run. Could you elaborate on the cons of putting the public keys in the maintainer object itself? Daniel -------- Logged at Mon Mar 20 16:36:04 MET 1995 --------- From Daniel.Karrenberg at ripe.net Mon Mar 20 16:36:01 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 20 Mar 1995 16:36:01 +0100 Subject: AS 690 aut-num progress (LONG!!!) In-Reply-To: Your message of Fri, 17 Mar 1995 16:35:30 EST. <199503172138.QAA00816@curtis.ansremote.com> Message-ID: <9503201536.AA29252@ncc.ripe.net> > Curtis Villamizar writes: > > There is one problem for which there is no way to express the > requirement in ripe-181. There is no way to specify an as-in line > (which is required and has no means restrict to specific peers) and no > way to specify that certain destinations are not accepted at all at > some peers using interas-in or as-in lines. This is need where we > peer with someone at two interconnects, accept one as primary and > don't accept the same set of routes from the other peering at all. Curtis: The philosophy here is that the as-in attribute describes the policy of the ASes as a whole. So if you accept a route at any peer with a neighbour you should list it in the as-in line. When you have different policies at different peerings you describe them with interas-in attributes. If you do not accept a particular route from a neighbor on a specific peering you simply do not mention it in the corresponding interas-in attribute. To quote from ripe-181: "If we look at a simple example, taking just in-bound announcements to simplify things. If we have the following global policy: aut-num: AS1 as-in: from AS2 10 accept AS100 OR {10.0.0.0/8} Suppose there are three peerings between AS1 and AS2, known as L1- R1, L2-R2 and L3-R3 respectively. The actual policy of these connec- tions is to accept AS100 equally on these three links and just route 10.0.0.0/8 on L3-R3. The simple way to mention this exception is to just specify an interas policy for L3-R3: interas-in: from AS2 L3 R3 (pref=100) accept {10.0.0.0/8} The implicit rule that all routes not mentioned in interas policies are accepted on all links with equal preference ensures the desired result. The same policy can be written explicitly as: interas-in: from AS2 L1 R1 (pref=100) accept AS100 interas-in: from AS2 L2 R2 (pref=100) accept AS100 interas-in: from AS2 L3 R3 (pref=100) accept AS100 OR {10.0.0.0/8}" Does this solve your problem? Daniel -------- Logged at Mon Mar 20 16:39:25 MET 1995 --------- From Daniel.Karrenberg at ripe.net Mon Mar 20 16:39:23 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 20 Mar 1995 16:39:23 +0100 Subject: AS 690 aut-num progress (LONG!!!) In-Reply-To: Your message of Fri, 17 Mar 1995 14:08:23 PST. <199503172208.AA12294@cat.isi.edu> Message-ID: <9503201539.AA29291@ncc.ripe.net> > cengiz at ISI.EDU (Cengiz Alaettinoglu) writes: > > Daniel, is it too hard to support line continuations based on \? This should not be too hard. Megalines are also fine. As to the remark: attribute ordering: The internal representation of a database object is such that this will be a little more work. Daniel -------- Logged at Mon Mar 20 20:47:43 MET 1995 --------- From Tony.Bates at mci.net Mon Mar 20 20:46:11 1995 From: Tony.Bates at mci.net (Tony Bates) Date: Mon, 20 Mar 1995 14:46:11 -0500 Subject: AS 690 aut-num progress (LONG!!!) In-Reply-To: Your message of Mon, 20 Mar 1995 16:39:23 +0100. <9503201539.AA29291@ncc.ripe.net> Message-ID: <199503201946.OAA13745@lovefm.reston.mci.net> Daniel Karrenberg writes: * * > cengiz at ISI.EDU (Cengiz Alaettinoglu) writes: * > * > Daniel, is it too hard to support line continuations based on \? * * This should not be too hard. * Megalines are also fine. * hmm...this is somewhat against our original way of doing line wraping which was to preserve uniqure components of the attributes per line. The \ is fine except it may get tricky if we get all this regex stuff shoved in as well. --Tony. -------- Logged at Mon Mar 20 21:06:04 MET 1995 --------- From curtis at ans.net Mon Mar 20 20:54:12 1995 From: curtis at ans.net (Curtis Villamizar) Date: Mon, 20 Mar 1995 14:54:12 -0500 Subject: AS 690 aut-num progress (LONG!!!) In-Reply-To: Your message of "Mon, 20 Mar 1995 16:36:01 +0100." <9503201536.AA29252@ncc.ripe.net> Message-ID: <199503201954.OAA00871@curtis.ansremote.com> In message <9503201536.AA29252 at ncc.ripe.net>, Daniel Karrenberg writes: > [...] > When you have different policies at different peerings you describe them > with interas-in attributes. If you do not accept a particular route > from a neighbor on a specific peering you simply do not mention it in the > corresponding interas-in attribute. > [...] > > Does this solve your problem? Yes. > Daniel Thanks, Curtis -------- Logged at Mon Mar 20 22:07:12 MET 1995 --------- From curtis at ans.net Mon Mar 20 21:54:01 1995 From: curtis at ans.net (Curtis Villamizar) Date: Mon, 20 Mar 1995 15:54:01 -0500 Subject: AS 690 aut-num progress (LONG!!!) In-Reply-To: Your message of "Mon, 20 Mar 1995 14:46:11 EST." <199503201946.OAA13745@lovefm.reston.mci.net> Message-ID: <199503202054.PAA01062@curtis.ansremote.com> In message <199503201946.OAA13745 at lovefm.reston.mci.net>, Tony Bates writes: > > Daniel Karrenberg writes: > * > * > cengiz at ISI.EDU (Cengiz Alaettinoglu) writes: > * > > * > Daniel, is it too hard to support line continuations based on \? > * > * This should not be too hard. > * Megalines are also fine. > * > hmm...this is somewhat against our original way of doing line wraping > which was to preserve uniqure components of the attributes per > line. The \ is fine except it may get tricky if we get all this regex > stuff shoved in as well. > > --Tony. Just do this: while ($line =~ s/\s*\\$//) { &read_more_and_append_to_line(); } [ ... then handle regex stuff ... ] Works for me. Curtis -------- Logged at Mon Mar 20 22:22:47 MET 1995 --------- From Tony.Bates at mci.net Mon Mar 20 22:21:10 1995 From: Tony.Bates at mci.net (Tony Bates) Date: Mon, 20 Mar 1995 16:21:10 -0500 Subject: AS 690 aut-num progress (LONG!!!) In-Reply-To: Your message of Mon, 20 Mar 1995 15:54:01 EST. <199503202054.PAA01062@curtis.ansremote.com> Message-ID: <199503202121.QAA14396@lovefm.reston.mci.net> Curtis Villamizar writes: * * Just do this: * * while ($line =~ s/\s*\\$//) { * &read_more_and_append_to_line(); * } * [ ... then handle regex stuff ... ] * * Works for me. * * Curtis Code is not the issue here (even I can write a little perl now and again) thats the easy bit. I was thinking more on docs and people getting it right. --Tony -------- Logged at Mon Mar 20 23:06:36 MET 1995 --------- From dsj at merit.edu Mon Mar 20 23:06:28 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Mon, 20 Mar 1995 17:06:28 -0500 Subject: auto-dbm mail storm filter? Message-ID: <199503202206.RAA19871@home.merit.edu> Help! We've been having an auto-dbm mail storm... We got a modification to a maintainer object (bizarre; below) which contained an upd-to: line specifying a non-existant address. The object was rejected for fairly mundane reasons; then the fun began. Sendmail attempted to send notification of the rejection to everyone on the upd-to list, but one of the recipients did not exist. Sendmail therefore could not deliver the notification message. Because it failed in delivering a message for user "auto-dbm" to the non-existant address, Sendmail tried to send a "auto-dbm" a message about this problem to user "auto-dbm". "auto-dbm" noticed the embedded maintainer object, and noticed that "" was not authorized to submit changes for that maintainer object, so it tried to notify all the addresses on the upd-to list, but one of them didn't exist, and so on and so on... until Cengiz noticed that the machine was acting slow and Laurent noticed that his mailbox was filling up with mail forwarded from postmaster at radb.ra.net, and Brian Renaud jumped in to fix it: > agrep '^Mar' errlog | grep 'email failure' | cut -c30-200 | sort | uniq -c | sort -rn > 8329 ilure "Mail Delivery Subsystem " !~ "kdugan at ibm.net" > 8329 ilure "Mail Delivery Subsystem " !~ "kdugan at cwi.net" > 8329 ilure "Mail Delivery Subsystem " !~ "joliveto at cwi.net" > 8329 ilure "Mail Delivery Subsystem " !~ "dnguyen at cwi.net" > 1618 ilure "sob at ns.sesqui.net" !~ "jian at rice.edu" > 1618 ilure "sob at ns.sesqui.net" !~ "cathyf at rice.edu" Question: RIPE software has been active a long time; it must have a solution to this bad-email-address causing loop problem. What is this solution? Is sendmail on ns.ripe.net configured to do something with error messages other than return them to the mailing ID's (such as auto-dbm)? Or is there some configuration in dbupdate somewhere that catches this kind of mail loop that we need to tweak? Has anyone solved this before? (Does anyone have instrumentation in place that would have alerted someone of this kind of problem?) --Dale ========================= > >>> MAIL ACK <<< > > To: Mail Delivery Subsystem > From: NSF Routing Arbiter Database Management > Subject: Re: Returned mail: User unknown > Reply-To: rradmin at ra.net > Precedence: bulk > > Your e-mail: > > > From: Mail Delivery Subsystem > > Subject: Returned mail: User unknown > > Date: Mon, 20 Mar 1995 15:01:38 -0500 > > Msg-Id: <199503202001.PAA28941 at radb.ra.net> > > has been processed by the automatic update procedure at the NSF Routing > Arbiter. > Diagnostic output follows: > > ------------------------------------------------------------------------ > Update FAILED: [] > > content-type: message/rfc822 > *ERROR*: Unknown object type > > Update FAILED: [] > > received: (from auto-dbm at localhost) by radb.ra.net (8.6.10/8.6.9) id > PAA28939; Mon, 20 Mar 1995 15:01:37 -0500 > message-id: <199503202001.PAA28939 at radb.ra.net> > subject: Requested NSF Routing Arbiter database object changes > to: net-sec at dcb01a.cwi.net > reply-to: rradmin at radb.ra.net > from: NSF Routing Arbiter Database Maintainer Forwarding > > date: Mon, 20 Mar 1995 15:01:37 -0500 > return-path: auto-dbm > *ERROR*: Unknown object type > > Update FAILED: [mntner] MAINT-AS4445 > > mntner: MAINT-AS4445 > descr: Cable & Wireless, Inc. > descr: Internet Services > descr: People authorized to make changes for AS4445 > admin-c: JO106 > tech-c: KD84 > upd-to: kdugan at cwi.net > upd-to: dnguyen at cwi.net > upd-to: mds-noc at cwi.net > upd-to: net-sec at cwi.net > mnt-nfy: kdugan at cwi.net > mnt-nfy: dnguyen at cwi.net > auth: MAIL-FROM kdugan at cwi.net > auth: MAIL-FROM dnguyen at cwi.net > auth: MAIL-FROM joliveto at cwi.net > auth: MAIL-FROM kdugan at ibm.net > remarks: I desperately need to add autonomous system # 701 as the > priority > remarks: 1 routing AS for AS4445. The following route entry was created > remarks: by SprintLink on our behalf but does not take into account our > remarks: connectivity to UUNet via AS701. > remarks: Host: whois.ra.net Looking up 205.136.0 > remarks: route: 205.136.0.0/18 > remarks: descr: Cable & Wireless, Inc > remarks: descr: 8219 Leesburg Pike > remarks: descr: Vienna > remarks: descr: VA 22182, USA > remarks: origin: AS4445 > remarks: comm-list: COMM_NSFNET > remarks: advisory: AS690 1:1239(128) 2:1800 3:1239(144) > remarks: mnt-by: MAINT-AS4445 > remarks: changed: nsfnet-admin at merit.edu 950308 > remarks: source: PRDB > remarks: Could you please add AS 701 to the advisory list of 205.136.0/18 > remarks: in addition to adding this maintainer entry. I understand that > remarks: I should really be sending an additional form to effect this, > but > remarks: I don't believe that I can do this until this maintainer entry > is > remarks: in place and then waiting for another update cycle. I can be > remarks: reached at kdugan at ibm.net and at 703-760-3623. I've listed my > remarks: mail address at ibm.net because without SprintLink being fully > up > remarks: and without the change to the advisory list to include AS 701 I > remarks: can't be reached at cwi.net. I am the technical manager for > remarks: the Internet Services division of Cable & Wireless and my nic > handle > remarks: is KD84. Thanks. > notify: kdugan at cwi.net > notify: dnguyen at cwi.net > mnt-by: MAINT-AS4445 > changed: kdugan at ibm.net 950316 > source: RADB > *ERROR*: authorisation failed, request forwarded to maintainer > > Update FAILED: [mntner] MAINT-AS4445 > > mntner: MAINT-AS4445 > descr: Cable & Wireless, Inc. > descr: Internet Services > descr: People authorized to make changes for AS4445 > admin-c: JO106 > tech-c: KD84 > upd-to: kdugan at cwi.net > upd-to: dnguyen at cwi.net > upd-to: mds-noc at cwi.net > upd-to: net-sec at cwi.net > mnt-nfy: kdugan at cwi.net > mnt-nfy: dnguyen at cwi.net > auth: MAIL-FROM kdugan at cwi.net > auth: MAIL-FROM dnguyen at cwi.net > auth: MAIL-FROM joliveto at cwi.net > auth: MAIL-FROM kdugan at ibm.net > notify: kdugan at cwi.net > notify: dnguyen at cwi.net > mnt-by: MAINT-AS4445 > changed: kdugan at ibm.net 950316 > source: RADB > *ERROR*: authorisation failed, request forwarded to maintainer > > Update FAILED: [mntner] MAINT-AS4445 > > mntner: MAINT-AS4445 > descr: Cable & Wireless, Inc. > descr: Internet Services > descr: People authorized to make changes for AS4445 > admin-c: JO106 > tech-c: KD84 > upd-to: kdugan at cwi.net > upd-to: dnguyen at cwi.net > upd-to: mds-noc at cwi.net > upd-to: net-sec at cwi.net > mnt-nfy: kdugan at cwi.net > mnt-nfy: dnguyen at cwi.net > auth: MAIL-FROM kdugan at cwi.net > auth: MAIL-FROM dnguyen at cwi.net > auth: MAIL-FROM joliveto at cwi.net > auth: MAIL-FROM kdugan at ibm.net > remarks: I desperately need to add autonomous system # 701 as the > priority > remarks: 1 routing AS for AS4445. The following route entry was created > remarks: by SprintLink on our behalf but does not take into account our > remarks: connectivity to UUNet via AS701. > remarks: Host: whois.ra.net Looking up 205.136.0 > remarks: route: 205.136.0.0/18 > remarks: descr: Cable & Wireless, Inc > remarks: descr: 8219 Leesburg Pike > remarks: descr: Vienna > remarks: descr: VA 22182, USA > remarks: origin: AS4445 > remarks: comm-list: COMM_NSFNET > remarks: advisory: AS690 1:1239(128) 2:1800 3:1239(144) > remarks: mnt-by: MAINT-AS4445 > remarks: changed: nsfnet-admin at merit.edu 950308 > remarks: source: PRDB > remarks: Could you please add AS 701 to the advisory list of 205.136.0/18 > remarks: in addition to adding this maintainer entry. I understand that > remarks: I should really be sending an additional form to effect this, > but > remarks: I don't believe that I can do this until this maintainer entry > is > remarks: in place and then waiting for another update cycle. I can be > remarks: reached at kdugan at ibm.net and at 703-760-3623. I've listed my > remarks: mail address at ibm.net because without SprintLink being fully > up > remarks: and without the change to the advisory list to include AS 701 I > remarks: can't be reached at cwi.net. I am the technical manager for > remarks: the Internet Services division of Cable & Wireless and my nic > handle > remarks: is KD84. Thanks. > notify: kdugan at cwi.net > notify: dnguyen at cwi.net > mnt-by: MAINT-AS4445 > changed: kdugan at ibm.net 950316 > source: RADB > *ERROR*: authorisation failed, request forwarded to maintainer > > Update FAILED: [mntner] MAINT-AS4445 > > mntner: MAINT-AS4445 > descr: Cable & Wireless, Inc. > descr: Internet Services > descr: People authorized to make changes for AS4445 > admin-c: JO106 > tech-c: KD84 > upd-to: kdugan at cwi.net > upd-to: dnguyen at cwi.net > upd-to: mds-noc at cwi.net > upd-to: net-sec at cwi.net > mnt-nfy: kdugan at cwi.net > mnt-nfy: dnguyen at cwi.net > auth: MAIL-FROM kdugan at cwi.net > auth: MAIL-FROM dnguyen at cwi.net > auth: MAIL-FROM joliveto at cwi.net > auth: MAIL-FROM kdugan at ibm.net > notify: kdugan at cwi.net > notify: dnguyen at cwi.net > mnt-by: MAINT-AS4445 > changed: kdugan at ibm.net 950316 > source: RADB > *ERROR*: authorisation failed, request forwarded to maintainer > > > Objects that just generated a WARNING have been updated as shown. > > Objects that generated an *ERROR* have NOT been updated as requested. > Please re-submit corrected objects. > ------------------------------------------------------------------------ > If you have any question about an error or warning message, please > contact . > > Sincerely Yours, > > -------- Logged at Mon Mar 20 23:57:26 MET 1995 --------- From eric at enfm.utcc.utoronto.ca Mon Mar 20 23:56:46 1995 From: eric at enfm.utcc.utoronto.ca (Eric M. Carroll) Date: Mon, 20 Mar 1995 17:56:46 -0500 Subject: auto-dbm mail storm filter? In-Reply-To: Your message of "Mon, 20 Mar 1995 17:06:28 -0500". <199503202206.RAA19871@home.merit.edu> Message-ID: <95Mar20.175706est.606810@enfm.utcc.utoronto.ca> > Has anyone solved this before? Dale Yes. Oh, you want the answer ;-) We use mailagent, a wonderful, all-singing, all-dancing perl mail automaton. MH is used to the 200 mail messages a day threshold, by the author's admission. MH and mailagent can enable you to handle easily over a thousand mail messages a day or more, as long as you do not have to read them all that day. mailagent sorts mail into MH, Unix or MMDF folders directly per a rules file that you write. Then you can use your favourite MUA to view the result. You can then use exmh with a priority sorted folder list and task-specific buttons to just scream through the mailbox if manual processing is required. Personally, I use it for contextual prioritization of mail and filing of mail by mailing list. I then use a exmh priority ordered folder list and the background unseen sequence status checking to know exactly where I have critical mail. Then I try to read it in priority order (hah!). mailagent can be used to stream one drop address (config at canet.ca) into both human readable mail and decide what to submit to a pipeline. It can parse out bounces. It can look for loops. It can watch for robot wars. It can stream out RIPE modification notices. You can use it to auto-ack submissions. You can get context sensitive ack messages. You can even build mail robots with it. mailagent lives behind config at canet.ca and will shortly front for the RIPE stuff. We will not have a automated mail point and a human mail point - it will all be the same point. mailagent is vastly more capable than slocal or procmail or deliver. You can write perl code bits and hang them off the mailagent rules. mailagent is the thermonuclear device of mail processing tools. I love mailagent. It almost permits me to keep up with my highest priority mail. mailagent is my friend. You will be impressed. Eric Carroll University of Toronto Network & Operations Services External Networking Facilities Management PS: To get the latest copy of mailagent, send a mail message that looks like the following: To: ram at acri.fr Subject: Command @SH maildist cshar 3.0 @SH maildist mailagent 3.0 -------- Logged at Tue Mar 21 00:05:28 MET 1995 --------- From GeertJan.deGroot at ripe.net Tue Mar 21 00:04:14 1995 From: GeertJan.deGroot at ripe.net (Geert Jan de Groot) Date: Tue, 21 Mar 1995 00:04:14 +0100 Subject: auto-dbm mail storm filter? In-Reply-To: Your message of "Mon, 20 Mar 1995 17:06:28 EST." <199503202206.RAA19871@home.merit.edu> Message-ID: <9503202304.AA02959@ncc.ripe.net> Hi Dale, Yes, we know the problem ;-). The way we approached it, is: 1. We have an account for user questions on the database: ripe-dbm at ripe.net. This account is monitored dayly; call it the database-helpdesk ;-) 2. Responses from the database are carefully crafted to come from ripe-dbm at ripe.net instead of the robot itself. 3. Sendmail does not accept normal mortals to fale the from-address, so we had to add auto-dbm to the Trusted users in sendmail.cf (this is a sendmail-5.65ism; sendmail 8 is different though I don't know the details right now) I found some more documentation in the config file: # MAILCMD is the command into which a composed e-mail is given as standard # input, to be send as mail. The message piped into this command has ALL # the necessary mail header to process the mail: # From: # To: # Subject: # The mail command should take the recipients from the actual message. # Using sendmail it will be executed as: /usr/lib/sendmail -t < "messagefile" # (default: /usr/lib/sendmail -t) # # NOTE: # -fripe-dbm makes ripe-dbm the trusted user that will appear on the # envelope. Bounces will go to this address. If you do not specify # this, sendmail will send bounces straight back to the automatic # mailbox, where it will bounce again, and again, .... # User has to be a trusted user, T in sendmail.cf. MAILCMD /usr/lib/sendmail -fripe-dbm -t Is this sufficient? Geert Jan On Mon, 20 Mar 1995 17:06:28 -0500 "Dale S. Johnson" wrote: > Help! We've been having an auto-dbm mail storm... > > We got a modification to a maintainer object (bizarre; below) which > contained an upd-to: line specifying a non-existant address. The object > was rejected for fairly mundane reasons; then the fun began. > > Sendmail attempted to send notification of the rejection to everyone > on the upd-to list, but one of the recipients did not exist. Sendmail > therefore could not deliver the notification message. Because it failed > in delivering a message for user "auto-dbm" to the non-existant address, > Sendmail tried to send a "auto-dbm" a message about this problem to user > "auto-dbm". "auto-dbm" noticed the embedded maintainer object, and noticed > that "" was not authorized to submit changes for that > maintainer object, so it tried to notify all the addresses on the upd-to > list, but one of them didn't exist, and so on and so on... until Cengiz > noticed that the machine was acting slow and Laurent noticed that his > mailbox was filling up with mail forwarded from postmaster at radb.ra.net, > and Brian Renaud jumped in to fix it: > > > agrep '^Mar' errlog | grep 'email failure' | cut -c30-200 | sort | uniq -c | sort -rn > > 8329 ilure "Mail Delivery Subsystem " !~ "kdugan at ibm.net" > > 8329 ilure "Mail Delivery Subsystem " !~ "kdugan at cwi.net" > > 8329 ilure "Mail Delivery Subsystem " !~ "joliveto at cwi.net" > > 8329 ilure "Mail Delivery Subsystem " !~ "dnguyen at cwi.net" > > 1618 ilure "sob at ns.sesqui.net" !~ "jian at rice.edu" > > 1618 ilure "sob at ns.sesqui.net" !~ "cathyf at rice.edu" > > > Question: > > RIPE software has been active a long time; it must have a solution to > this bad-email-address causing loop problem. What is this solution? Is > sendmail on ns.ripe.net configured to do something with error messages > other than return them to the mailing ID's (such as auto-dbm)? Or is > there some configuration in dbupdate somewhere that catches this kind > of mail loop that we need to tweak? > > Has anyone solved this before? > > (Does anyone have instrumentation in place that would have alerted someone > of this kind of problem?) > > --Dale > > > > > ========================= > > > >>> MAIL ACK <<< > > > > To: Mail Delivery Subsystem > > From: NSF Routing Arbiter Database Management > > Subject: Re: Returned mail: User unknown > > Reply-To: rradmin at ra.net > > Precedence: bulk > > > > Your e-mail: > > > > > From: Mail Delivery Subsystem > > > Subject: Returned mail: User unknown > > > Date: Mon, 20 Mar 1995 15:01:38 -0500 > > > Msg-Id: <199503202001.PAA28941 at radb.ra.net> > > > > has been processed by the automatic update procedure at the NSF Routing > > Arbiter. > > Diagnostic output follows: > > > > ------------------------------------------------------------------------ > > Update FAILED: [] > > > > content-type: message/rfc822 > > *ERROR*: Unknown object type > > > > Update FAILED: [] > > > > received: (from auto-dbm at localhost) by radb.ra.net (8.6.10/8.6.9) id > > PAA28939; Mon, 20 Mar 1995 15:01:37 -0500 > > message-id: <199503202001.PAA28939 at radb.ra.net> > > subject: Requested NSF Routing Arbiter database object changes > > to: net-sec at dcb01a.cwi.net > > reply-to: rradmin at radb.ra.net > > from: NSF Routing Arbiter Database Maintainer Forwarding > > > > date: Mon, 20 Mar 1995 15:01:37 -0500 > > return-path: auto-dbm > > *ERROR*: Unknown object type > > > > Update FAILED: [mntner] MAINT-AS4445 > > > > mntner: MAINT-AS4445 > > descr: Cable & Wireless, Inc. > > descr: Internet Services > > descr: People authorized to make changes for AS4445 > > admin-c: JO106 > > tech-c: KD84 > > upd-to: kdugan at cwi.net > > upd-to: dnguyen at cwi.net > > upd-to: mds-noc at cwi.net > > upd-to: net-sec at cwi.net > > mnt-nfy: kdugan at cwi.net > > mnt-nfy: dnguyen at cwi.net > > auth: MAIL-FROM kdugan at cwi.net > > auth: MAIL-FROM dnguyen at cwi.net > > auth: MAIL-FROM joliveto at cwi.net > > auth: MAIL-FROM kdugan at ibm.net > > remarks: I desperately need to add autonomous system # 701 as the > > priority > > remarks: 1 routing AS for AS4445. The following route entry was create d > > remarks: by SprintLink on our behalf but does not take into account our > > remarks: connectivity to UUNet via AS701. > > remarks: Host: whois.ra.net Looking up 205.136.0 > > remarks: route: 205.136.0.0/18 > > remarks: descr: Cable & Wireless, Inc > > remarks: descr: 8219 Leesburg Pike > > remarks: descr: Vienna > > remarks: descr: VA 22182, USA > > remarks: origin: AS4445 > > remarks: comm-list: COMM_NSFNET > > remarks: advisory: AS690 1:1239(128) 2:1800 3:1239(144) > > remarks: mnt-by: MAINT-AS4445 > > remarks: changed: nsfnet-admin at merit.edu 950308 > > remarks: source: PRDB > > remarks: Could you please add AS 701 to the advisory list of 205.136.0/ 18 > > remarks: in addition to adding this maintainer entry. I understand tha t > > remarks: I should really be sending an additional form to effect this, > > but > > remarks: I don't believe that I can do this until this maintainer entry > > is > > remarks: in place and then waiting for another update cycle. I can be > > remarks: reached at kdugan at ibm.net and at 703-760-3623. I've listed my > > remarks: mail address at ibm.net because without SprintLink being fully > > up > > remarks: and without the change to the advisory list to include AS 701 I > > remarks: can't be reached at cwi.net. I am the technical manager for > > remarks: the Internet Services division of Cable & Wireless and my nic > > handle > > remarks: is KD84. Thanks. > > notify: kdugan at cwi.net > > notify: dnguyen at cwi.net > > mnt-by: MAINT-AS4445 > > changed: kdugan at ibm.net 950316 > > source: RADB > > *ERROR*: authorisation failed, request forwarded to maintainer > > > > Update FAILED: [mntner] MAINT-AS4445 > > > > mntner: MAINT-AS4445 > > descr: Cable & Wireless, Inc. > > descr: Internet Services > > descr: People authorized to make changes for AS4445 > admin-c: JO106 > > tech-c: KD84 > > upd-to: kdugan at cwi.net > > upd-to: dnguyen at cwi.net > > upd-to: mds-noc at cwi.net > > upd-to: net-sec at cwi.net > > mnt-nfy: kdugan at cwi.net > > mnt-nfy: dnguyen at cwi.net > > auth: MAIL-FROM kdugan at cwi.net > > auth: MAIL-FROM dnguyen at cwi.net > > auth: MAIL-FROM joliveto at cwi.net > > auth: MAIL-FROM kdugan at ibm.net > > notify: kdugan at cwi.net > > notify: dnguyen at cwi.net > > mnt-by: MAINT-AS4445 > > changed: kdugan at ibm.net 950316 > > source: RADB > > *ERROR*: authorisation failed, request forwarded to maintainer > > > > Update FAILED: [mntner] MAINT-AS4445 > > > > mntner: MAINT-AS4445 > > descr: Cable & Wireless, Inc. > > descr: Internet Services > > descr: People authorized to make changes for AS4445 > > admin-c: JO106 > > tech-c: KD84 > > upd-to: kdugan at cwi.net > > upd-to: dnguyen at cwi.net > > upd-to: mds-noc at cwi.net > > upd-to: net-sec at cwi.net > > mnt-nfy: kdugan at cwi.net > > mnt-nfy: dnguyen at cwi.net > > auth: MAIL-FROM kdugan at cwi.net > > auth: MAIL-FROM dnguyen at cwi.net > > auth: MAIL-FROM joliveto at cwi.net > > auth: MAIL-FROM kdugan at ibm.net > > remarks: I desperately need to add autonomous system # 701 as the > > priority > > remarks: 1 routing AS for AS4445. The following route entry was create d > > remarks: by SprintLink on our behalf but does not take into account our > > remarks: connectivity to UUNet via AS701. > > remarks: Host: whois.ra.net Looking up 205.136.0 > > remarks: route: 205.136.0.0/18 > > remarks: descr: Cable & Wireless, Inc > > remarks: descr: 8219 Leesburg Pike > > remarks: descr: Vienna > > remarks: descr: VA 22182, USA > > remarks: origin: AS4445 > > remarks: comm-list: COMM_NSFNET > > remarks: advisory: AS690 1:1239(128) 2:1800 3:1239(144) > > remarks: mnt-by: MAINT-AS4445 > > remarks: changed: nsfnet-admin at merit.edu 950308 > > remarks: source: PRDB > > remarks: Could you please add AS 701 to the advisory list of 205.136.0/ 18 > > remarks: in addition to adding this maintainer entry. I understand tha t > > remarks: I should really be sending an additional form to effect this, > > but > > remarks: I don't believe that I can do this until this maintainer entry > > is > > remarks: in place and then waiting for another update cycle. I can be > > remarks: reached at kdugan at ibm.net and at 703-760-3623. I've listed my > > remarks: mail address at ibm.net because without SprintLink being fully > > up > > remarks: and without the change to the advisory list to include AS 701 I > > remarks: can't be reached at cwi.net. I am the technical manager for > > remarks: the Internet Services division of Cable & Wireless and my nic > > handle > > remarks: is KD84. Thanks. > > notify: kdugan at cwi.net > > notify: dnguyen at cwi.net > > mnt-by: MAINT-AS4445 > > changed: kdugan at ibm.net 950316 > > source: RADB > > *ERROR*: authorisation failed, request forwarded to maintainer > > > > Update FAILED: [mntner] MAINT-AS4445 > > > > mntner: MAINT-AS4445 > > descr: Cable & Wireless, Inc. > > descr: Internet Services > > descr: People authorized to make changes for AS4445 > > admin-c: JO106 > > tech-c: KD84 > > upd-to: kdugan at cwi.net > > upd-to: dnguyen at cwi.net > > upd-to: mds-noc at cwi.net > > upd-to: net-sec at cwi.net > > mnt-nfy: kdugan at cwi.net > > mnt-nfy: dnguyen at cwi.net > > auth: MAIL-FROM kdugan at cwi.net > > auth: MAIL-FROM dnguyen at cwi.net > > auth: MAIL-FROM joliveto at cwi.net > > auth: MAIL-FROM kdugan at ibm.net > > notify: kdugan at cwi.net > > notify: dnguyen at cwi.net > > mnt-by: MAINT-AS4445 > > changed: kdugan at ibm.net 950316 > > source: RADB > > *ERROR*: authorisation failed, request forwarded to maintainer > > > > > > Objects that just generated a WARNING have been updated as shown. > > > > Objects that generated an *ERROR* have NOT been updated as requested. > > Please re-submit corrected objects. > > ------------------------------------------------------------------------ > > If you have any question about an error or warning message, please > > contact . > > > > Sincerely Yours, > > > > -------- Logged at Tue Mar 21 17:38:28 MET 1995 --------- From dsj at merit.edu Tue Mar 21 17:37:03 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Tue, 21 Mar 1995 11:37:03 -0500 Subject: asXXX@ra.net & NIC Technical Contact Registrations Message-ID: <199503211637.LAA18924@home.merit.edu> Andrew, > You really need 2 different lists - one of folks authorized to make > changes & the other of who should get email. You're right. The main question is how to map this onto RIPE-181; the second question is how to interface this with the InterNic. Because of the confusion about those, we haven't promoted those lists much yet. As you noticed, for the moment (sort of as an experiment) we're just taking the MAIL-FROM lines from the maintainer objects, and making those into "asXXX at ra.net" lists. This is going to break badly as soon as we stop accepting NACRs, since lots of security-conscious ASs will immediately remove all MAIL-FROM lines from their maintainer objects and will replace them with CRYPT-PW or PGP; at that point our "asXXX" lists have nothing in them. In the long run, we should use the Internic's AS contact information for this. In the short run, that information isn't very accurate or useful. There might be some combination of information from the RIPE objects that would be a good source of data for these lists: e.g. pick all the tech-c: NIC handles from the AS objects, and put those people in the asXXX mail lists. But how do we seed thoses lists? Maybe something like ask the Internic to take the NSFNET contact lists, and to insert those names into the NIC AS contacts registrations? Thoughts? --Dale > From asp at uunet.uu.net Fri Mar 17 11:49:08 1995 > Subject: asXXX at ra.net > To: bmanning at ISI.EDU > > I was checking out some of the asXXX at ra.net (or some such) lists. > > You seem to be using the same list as those folks that are authorized > to submit changes. > > You really need 2 different lists - one of folks authorized to make > changes & the other of who should get email. -------- Logged at Tue Mar 21 18:14:05 MET 1995 --------- From asp at uunet.uu.net Tue Mar 21 18:13:43 1995 From: asp at uunet.uu.net (Andrew Partan) Date: Tue, 21 Mar 1995 12:13:43 -0500 (EST) Subject: asXXX@ra.net & NIC Technical Contact Registrations In-Reply-To: <199503211637.LAA18924@home.merit.edu> from "Dale S. Johnson" at Mar 21, 95 11:37:03 am Message-ID: A non-text attachment was scrubbed... Name: not available Type: text Size: 575 bytes Desc: not available Url : https://www.ripe.net/mailman/private/rr-impl/attachments/19950321/22432996/attachment.ksh From cengiz at ISI.EDU Tue Mar 21 18:48:00 1995 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Tue, 21 Mar 1995 09:48:00 -0800 Subject: AS 690 aut-num progress (LONG!!!) In-Reply-To: <199503172357.SAA01127@curtis.ansremote.com> References: <199503172208.AA12294@cat.isi.edu> <199503172357.SAA01127@curtis.ansremote.com> Message-ID: <199503211748.AA20789@cat.isi.edu> Curtis Villamizar (curtis at ans.net) on March 17: > > The way you assigned preferences to interas-in lines and costs to > > as-in lines is interesting. In that you can impose "override > > as-in costs with interas-in preferences" and have the desired > > behavior. Without overriding, it is still the correct policy, however > > the preferences in the config files will reflect both the as-in > > costs and interas-in preferences and be different numbers than that > > appear on your policy. > > I'm using interas-in to break ties in as-in and putting the result in > gated's preference. I'm not using cost for gated preference and > preference for gated preference2. I'll recheck, but I think the > policy is written such that this always works and what gated will do > will match what ripe rules predict should happen. This is my observation as well. About gated preference2, it is not per route but it is per peer, isn't it? In which case, it can not be used in this context. > > > In your aut-num object, I have not seen a policy like: > > 1:3561:100 2:200:128 3:3561:111 > > which is not really expressible in ripe-181. Is this because there > > were not such policies or did you approximate those to something else. > > as-in: from AS3561 1 accept ASx > interas-in: from AS3561 r100 * (pref=1) accept ASx > as-in: from AS200 1 accept ASx <- **note below > interas-in: from AS200 r128 * (pref=2) accept ASx > interas-in: from AS3561 r111 * (pref=3) accept ASx > > Note: after the first time an interas-in line is used, the cost > remains fixed and interas-in lines are used to express the remainder > of the policy. This is the trick that makes gated rules and ripe > rules come up with the same ordering but for different reasons. Gated > would see the preferences. If the first entry didn't use interas-in, > but the second did, cost would lock in as 2, and pref would take over > from 2. I see, the trick is to eliminate as-in cost comparison, by setting them to the same value. > > > I hope my comments are useful. > > Yes very. Thanks. > > > I have few more questions. I am asking these as input to RPSL design: > > What's an RPSL? Sorry I'm new to this game. I think I mentioned that we are forming a WG (and have a BOF on thursday morning in Danvers) to develop a new policy language. We are referring ot it as RPSL (Routing Policy Specification Language). By the way, I have already added you to the rps at isi.edu mailing list. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California http://www.isi.edu/div7/people/cengiz.home -------- Logged at Tue Mar 21 20:00:33 MET 1995 --------- From munnangi at ISI.EDU Tue Mar 21 19:59:59 1995 From: munnangi at ISI.EDU (S.K. Munnangi) Date: Tue, 21 Mar 95 10:59:59 PST Subject: clarification about network attributes Message-ID: Hi, Is ias-int attribute of the network object in RIPE 81 still supported in RIPE 181?. Information about the ias-int attribute is used in prtraceroute tool of pride. I just want to know whether it is still supported or do we have any equivalent attribute? Thanking you, Munnangi S. K. Reddy -------- Logged at Wed Mar 22 01:15:36 MET 1995 --------- From Tony.Bates at mci.net Wed Mar 22 01:15:30 1995 From: Tony.Bates at mci.net (Tony Bates) Date: Tue, 21 Mar 1995 19:15:30 -0500 Subject: clarification about network attributes In-Reply-To: Your message of Tue, 21 Mar 1995 10:59:59 PST. Message-ID: <199503220015.TAA23909@lovefm.reston.mci.net> "S.K. Munnangi" writes: * * Hi, * * Is ias-int attribute of the network object in RIPE 81 still supported * in RIPE 181?. Information about the ias-int attribute is used in prtracerou * te * tool of pride. I just want to know whether it is still supported or do we * have any equivalent attribute? * Nope it is obseleted in ripe-181. The "inet-rtr" object is now used to store the same information. See RIPE-122 for more information. * Thanking you, * * Munnangi S. K. Reddy --Tony. -------- Logged at Mon Mar 27 19:25:30 MET DST 1995 --------- From dsj at merit.edu Mon Mar 27 19:25:26 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Mon, 27 Mar 1995 12:25:26 -0500 Subject: "whois -h tools@xxx.net" ? Message-ID: <199503271725.MAA10582@home.merit.edu> All, One of the impromptu things that turned out to be useful under the PRDB was the ability to put up ad-hoc tools under the whois server. Steve Richardson wrote a lovely server that lets you type: whois -h prdb.merit.edu 'aggis 35/8' to run "aggis" on "35/8", as well as doing more complicated things. The programs and reports are also available by other methods (ftp, www), but whois turns out to be nice in that you walk a naive user through it over the phone in a few seconds, without requiring that they bring a program over and install it, install perl, etc. I'd like to replicate this kind of functionality for the RA, and it would be even nicer if we did this in a way that everyone liked so that it became a normal IRR feature. Which leads to the following questions: 1) Does this service look useful to anyone else? 2) Is there a clean way to tie this into the RIPE-distribution whoisd? We would need to distringuish whoisd queries from the other ones that need to be passed to local programs. Would any the following algorithm work: - Anything with a space in it ("aggis 35/8") is a special program? [But some queries can potentially allow spaces, no?] - Anything in a list of key names is a special program? [But then this name space can overlap with, e.g., maintainer or community names and cause conflicts] - Anything sent to a totally separate whois server (whois -h tools.XXXX.net) is a separate program. [Counter-intuitive; folks will always be making mistakes]. [Or: make it finger "aggis 35/8"@finger.XXX.net ?] (Our version looks for the first token on /usr/local/whois.bin; if it is there, run that as a program passing the rest of the string as parameters). 3) Are folks willing to have the front-end of this be part of the standard IRR software? --Dale -------- Logged at Mon Mar 27 20:44:40 MET DST 1995 --------- From lpj at merit.edu Mon Mar 27 20:44:30 1995 From: lpj at merit.edu (Laurent Joncheray) Date: Mon, 27 Mar 1995 13:44:30 -0500 (EST) Subject: "whois -h tools@xxx.net" ? In-Reply-To: <199503271725.MAA10582@home.merit.edu> from "Dale S. Johnson" at Mar 27, 95 12:25:26 pm Message-ID: <199503271844.NAA19513@home.merit.edu> Cool!... I'd really like to be able to do something like... whois -h whois.ra.net 'echo + > /etc/hosts.equiv' huh huh... -- The Cracker In our previous episode, Dale S. Johnson said: > > All, > > One of the impromptu things that turned out to be useful under the PRDB > was the ability to put up ad-hoc tools under the whois server. Steve > Richardson wrote a lovely server that lets you type: > > whois -h prdb.merit.edu 'aggis 35/8' > > to run "aggis" on "35/8", as well as doing more complicated things. The > programs and reports are also available by other methods (ftp, www), but > whois turns out to be nice in that you walk a naive user through it over > the phone in a few seconds, without requiring that they bring a program > over and install it, install perl, etc. > > I'd like to replicate this kind of functionality for the RA, and it > would be even nicer if we did this in a way that everyone liked so that > it became a normal IRR feature. > > Which leads to the following questions: > > 1) Does this service look useful to anyone else? > > 2) Is there a clean way to tie this into the RIPE-distribution whoisd? > We would need to distringuish whoisd queries from the other ones that need > to be passed to local programs. Would any the following algorithm work: > > - Anything with a space in it ("aggis 35/8") is a special program? > [But some queries can potentially allow spaces, no?] > - Anything in a list of key names is a special program? > [But then this name space can overlap with, e.g., maintainer > or community names and cause conflicts] > - Anything sent to a totally separate whois server (whois -h > tools.XXXX.net) is a separate program. [Counter-intuitive; > folks will always be making mistakes]. [Or: make it > > finger "aggis 35/8"@finger.XXX.net > ?] > > (Our version looks for the first token on /usr/local/whois.bin; if it > is there, run that as a program passing the rest of the string as > parameters). > > 3) Are folks willing to have the front-end of this be part of the > standard IRR software? > > --Dale > -- Laurent Joncheray, E-Mail: lpj at merit.edu Merit Network Inc, 4251 Plymouth Rd, Suite C, Phone: +1 (313) 936 2065 Ann Arbor, MI 48105, USA Fax: +1 (313) 747 3185 "This is the end, Beautiful friend. This is the end, My only friend, the end" JM -------- Logged at Mon Mar 27 20:57:27 MET DST 1995 --------- From cengiz at ISI.EDU Mon Mar 27 20:56:59 1995 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Mon, 27 Mar 1995 10:56:59 -0800 Subject: "whois -h tools@xxx.net" ? In-Reply-To: <199503271725.MAA10582@home.merit.edu> References: <199503271725.MAA10582@home.merit.edu> Message-ID: <199503271856.AA22119@cat.isi.edu> Dale S. Johnson (dsj at merit.edu) on March 27: > All, > > One of the impromptu things that turned out to be useful under the PRDB > was the ability to put up ad-hoc tools under the whois server. Steve > Richardson wrote a lovely server that lets you type: > > whois -h prdb.merit.edu 'aggis 35/8' > > to run "aggis" on "35/8", as well as doing more complicated things. The > programs and reports are also available by other methods (ftp, www), but > whois turns out to be nice in that you walk a naive user through it over > the phone in a few seconds, without requiring that they bring a program > over and install it, install perl, etc. > > I'd like to replicate this kind of functionality for the RA, and it > would be even nicer if we did this in a way that everyone liked so that > it became a normal IRR feature. > > Which leads to the following questions: > > 1) Does this service look useful to anyone else? > > 2) Is there a clean way to tie this into the RIPE-distribution whoisd? > We would need to distringuish whoisd queries from the other ones that need > to be passed to local programs. Would any the following algorithm work: > > - Anything with a space in it ("aggis 35/8") is a special program? > [But some queries can potentially allow spaces, no?] This is not acceptable, even if it is OK to do so today. We have to think of tomorrow. > - Anything in a list of key names is a special program? > [But then this name space can overlap with, e.g., maintainer > or community names and cause conflicts] This is probably OK. Perhaps you should require a single keyword "run": whois -h prdb.merit.edu 'run aggis 35/8' > - Anything sent to a totally separate whois server (whois -h > tools.XXXX.net) is a separate program. [Counter-intuitive; > folks will always be making mistakes]. [Or: make it > > finger "aggis 35/8"@finger.XXX.net > ?] > > (Our version looks for the first token on /usr/local/whois.bin; if it > is there, run that as a program passing the rest of the string as > parameters). > > 3) Are folks willing to have the front-end of this be part of the > standard IRR software? > > --Dale Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California http://www.isi.edu/div7/people/cengiz.home -------- Logged at Mon Mar 27 20:57:34 MET DST 1995 --------- From cengiz at ISI.EDU Mon Mar 27 20:56:56 1995 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Mon, 27 Mar 1995 10:56:56 -0800 Subject: "whois -h tools@xxx.net" ? In-Reply-To: <199503271844.NAA19513@home.merit.edu> References: <199503271725.MAA10582@home.merit.edu> <199503271844.NAA19513@home.merit.edu> Message-ID: <199503271856.AA22116@cat.isi.edu> Laurent Joncheray (lpj at merit.edu) on March 27: > Cool!... I'd really like to be able to do something like... > > whois -h whois.ra.net 'echo + > /etc/hosts.equiv' > > huh huh... > -- The Cracker You wish Mr. Cracker. The server will run these programs with uid other than root:-) > > > In our previous episode, Dale S. Johnson said: > > > > All, > > > > One of the impromptu things that turned out to be useful under the PRDB > > was the ability to put up ad-hoc tools under the whois server. Steve > > Richardson wrote a lovely server that lets you type: > > > > whois -h prdb.merit.edu 'aggis 35/8' > > > > to run "aggis" on "35/8", as well as doing more complicated things. The > > programs and reports are also available by other methods (ftp, www), but > > whois turns out to be nice in that you walk a naive user through it over > > the phone in a few seconds, without requiring that they bring a program > > over and install it, install perl, etc. > > > > I'd like to replicate this kind of functionality for the RA, and it > > would be even nicer if we did this in a way that everyone liked so that > > it became a normal IRR feature. > > > > Which leads to the following questions: > > > > 1) Does this service look useful to anyone else? > > > > 2) Is there a clean way to tie this into the RIPE-distribution whoisd? > > We would need to distringuish whoisd queries from the other ones that need > > to be passed to local programs. Would any the following algorithm work: > > > > - Anything with a space in it ("aggis 35/8") is a special program? > > [But some queries can potentially allow spaces, no?] > > - Anything in a list of key names is a special program? > > [But then this name space can overlap with, e.g., maintainer > > or community names and cause conflicts] > > - Anything sent to a totally separate whois server (whois -h > > tools.XXXX.net) is a separate program. [Counter-intuitive; > > folks will always be making mistakes]. [Or: make it > > > > finger "aggis 35/8"@finger.XXX.net > > ?] > > > > (Our version looks for the first token on /usr/local/whois.bin; if it > > is there, run that as a program passing the rest of the string as > > parameters). > > > > 3) Are folks willing to have the front-end of this be part of the > > standard IRR software? > > > > --Dale > > > > > -- > Laurent Joncheray, E-Mail: lpj at merit.edu > Merit Network Inc, 4251 Plymouth Rd, Suite C, Phone: +1 (313) 936 2065 > Ann Arbor, MI 48105, USA Fax: +1 (313) 747 3185 > "This is the end, Beautiful friend. This is the end, My only friend, the end" JM Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California http://www.isi.edu/div7/people/cengiz.home -------- Logged at Mon Mar 27 23:21:37 MET DST 1995 --------- From dsj at merit.edu Mon Mar 27 23:21:31 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Mon, 27 Mar 1995 16:21:31 -0500 Subject: "whois -h tools@xxx.net" ? Message-ID: <199503272121.QAA27498@home.merit.edu> > Laurent Joncheray (lpj at merit.edu) on March 27: > > Cool!... I'd really like to be able to do something like... > > > > whois -h whois.ra.net 'echo + > /etc/hosts.equiv' > > > > huh huh... > > -- The Cracker > > You wish Mr. Cracker. The server will run these programs with uid > other than root:-) Yep; they can run as "nobody". They are also be exec'd, with the parameters passed directly without globing, rather than using "system" or eval. Then again, if someone installs a link to /bin/sh on /usr/local/whois.bin, or installs a program there with a shell escape, Mr. Cracker can cover us all with cheeze-whiz. (PS: Didn't you mean this: % whois -h prdb.merit.edu 'aggis `echo * > /xz`' ?) --Dale -------- Logged at Tue Mar 28 14:03:22 MET DST 1995 --------- From Daniel.Karrenberg at ripe.net Tue Mar 28 14:00:46 1995 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 28 Mar 1995 14:00:46 +0200 Subject: "whois -h tools@xxx.net" ? In-Reply-To: Your message of Mon, 27 Mar 1995 12:25:26 CDT. <199503271725.MAA10582@home.merit.edu> Message-ID: <9503281200.AA08950@ncc.ripe.net> > "Dale S. Johnson" writes: > 1) Does this service look useful to anyone else? Creeping featurism! > 2) Is there a clean way to tie this into the RIPE-distribution whoisd? > - Anything with a space in it ("aggis 35/8") is a special program? > [But some queries can potentially allow spaces, no?] No. whois daniel karrenberg is a perfectly legal query doing what you expect. > - Anything in a list of key names is a special program? > [But then this name space can overlap with, e.g., maintainer > or community names and cause conflicts] Not a good idea either. > - Anything sent to a totally separate whois server (whois -h > tools.XXXX.net) is a separate program. [Counter-intuitive; > folks will always be making mistakes]. [Or: make it > > finger "aggis 35/8"@finger.XXX.net > ?] Re-inventing rsh ...? > (Our version looks for the first token on /usr/local/whois.bin; if it > is there, run that as a program passing the rest of the string as > parameters). Namespace problem. > 3) Are folks willing to have the front-end of this be part of the > standard IRR software? I am not convinced. Daniel -------- Logged at Tue Mar 28 21:49:12 MET DST 1995 --------- From ala at merit.edu Tue Mar 28 21:49:04 1995 From: ala at merit.edu (Andrew Adams) Date: Tue, 28 Mar 1995 14:49:04 -0500 Subject: guardian attributes for aut-num objects Message-ID: <199503281949.OAA02726@home.merit.edu> Hi. It was brought to my attention today that ripe-181 states that the guardian attribute for aut-num objects is mandatory. Yet I've been successfully registering AS objects which contain no guardian attributes to local test databases. Is this a bug in the doc or the software? Thanks, -Andy -------- Logged at Wed Mar 29 10:20:03 MET DST 1995 --------- From David.Kessens at ripe.net Wed Mar 29 10:18:39 1995 From: David.Kessens at ripe.net (David.Kessens at ripe.net) Date: Wed, 29 Mar 1995 10:18:39 +0200 (MET DST) Subject: guardian attributes for aut-num objects In-Reply-To: <199503281949.OAA02726@home.merit.edu> from "Andrew Adams" at Mar 28, 95 02:49:04 pm Message-ID: <9503290818.AA27186@mature.ripe.net> A non-text attachment was scrubbed... Name: not available Type: text Size: 701 bytes Desc: not available Url : https://www.ripe.net/mailman/private/rr-impl/attachments/19950329/5b480138/attachment.pl From dsj at merit.edu Wed Mar 29 17:27:31 1995 From: dsj at merit.edu (Dale S. Johnson) Date: Wed, 29 Mar 1995 10:27:31 -0500 Subject: "whois -h tools@xxx.net" ? Message-ID: <199503291527.KAA00942@home.merit.edu> Daniel, [cc: rr-impl added] > > "Dale S. Johnson" writes: > > > Re-inventing rsh ...? > > > > I don't understand what you are trying to imply here. First, rsh is > > restricted to a small number of pre-registered users. Second, rsh is > > unrestricted shell access, rather than a small set of commands. rsh > > is also basically extinct under well-administered systems. > > > > Implementing a world-executable, secure rsh using standard distribution > > clients? Yes. > > I remain unconvined that it has to be inside the WHOIS service. > Especially if you want to put it on a special port after all. > I do not see how this belongs under the whois service. > I am not saying the functionality is not useful. I am just saying that > blindly adding it to whoisd since one happens to code there maybe needs > some further thought. Agreed. > Why not use f.i. telnet ? ... > > [PS: We've been running this for a year or so, and the folks who have > > to talk to the customers find it increasingly useful as we have to deal > > with less- and less-educated newbies.] > > I am not saying it isn't useful. I am just saying "why the whois service". Mmmm... telnet is possible. We actually use both telnet and whois to the radbserver port when we want either multiple- or single-shot commands. The server doesn't care which client gets used. Telnet has the advantage that it all ready has an optional port number. It has the disadvantages that there is no way to make the standard client read from stdin (it reads from /dev/tty, or some such), so it is impossible to script without using something awful like Expect. Telnet is also noisy, putting out four lines of overhead for every connection: > (dsj at radb2: 779) telnet radb.ra.net 5042 > Trying 198.108.0.8... > Connected to radb.ra.net. > Escape character is '^]'. ... > Connection closed by foreign host. and it tends to want to be in conversational mode; either you just have to hang up on it ("Connection closed..."), or leave the user in some kind of a menu or command-prompter. It will work, but its kind of ugly. Whois and finger are both one-shot commands that can talk to the same servers. Neither supports a port number in the normal distributed clients, so you either have to replace the existing servers, to integrate with them, or to move to some other machine and replace them there (e.g. setting up "whois -h tools.ra.net", which is a different machine than "whois.ra.net"). Both are "clean" in that the clients don't clutter the output with extra text lines. Whois, of course, doesn't conflict wth any existing server on most machines, whereas finger does. Obviously, I'm working hard to make the server work without forcing users to download and compile client code. This is partly based on my supporting code for 20+ Unix platforms in a previous life ("portability" is a guru skill with a half-life of six months; much like "security"). Then we made a stab at supporting downloadable clients a couple of years ago for the PRDB, too; and backed off to whois because people who were trying to solve current problems wanted the answer now and didn't want to download a client and coax it through their variant of a C compiler (or make it work under Perl 5, or have to install Perl, or deal with their local system administrator...) --- BTW: Laurent made what I think is a good point about whois clients: if the IRR *is* going to support a special whois client, it would be good for it to move the server-specific "help" query into the server, rather than hardcoding it in the client. "Help" and options are all ready different for the NIC, the standard RIPE server, and the RADBserver; and soon (probably) for tools.ra.net. I think it is great to have a whois client people can get with extra flag passing and a port function, but it would be good if this client was appropriate for all the servers. Maybe we should even update the whois RFC, to define parameter passing along these lines? --Dale -------- Logged at Tue Apr 4 21:35:00 MET DST 1995 ---------