From epg at merit.edu Fri Apr 1 19:04:41 1994 From: epg at merit.edu (epg at merit.edu) Date: Fri, 1 Apr 94 12:04:41 EST Subject: Distributed RIPE?? In-Reply-To: <199403310606.BAA05092@merit.edu>; from "Jessica Yu" at Mar 31, 94 1:06 am Message-ID: <9404011704.AA04038@pepper.merit.edu> Since I am reading my mail in reverse order, perhaps this won't make sense, but what the heck.... Dale, There was a discussion with Scott Williamson, Mark, Kosters, Tony Bates, Marten T, Bill Manning, Jon Postel, you, and me which discussed this point. It was my understanding that ScottW and MarkK agreed with the routing registry folks that address allocation/assignment registries and routing registries are different animals. Therefore, they were going to focus on the allocation/assignment registries with the rwhois project. --Elise > > > 4) Jessica and I talked about doing the "Aggregate Registry" this way; > I think that registry is probably the least suitable project for > rwhois, since rwhois needs a delegation chain (like for IP addresses) > and there isn't such a thing for aggregates. > > ***I actually suspect Bill would propose this and try to evaluate > ***pros and cons of such mechanism. > > --Jessica > -------- Logged at Mon Apr 4 23:13:57 MET DST 1994 --------- From ala at merit.edu Mon Apr 4 23:13:50 1994 From: ala at merit.edu (Andrew Adams) Date: Mon, 4 Apr 1994 17:13:50 -0400 Subject: db question Message-ID: <199404042113.RAA17652@merit.edu> Tony, Marten, Daniel, Do you guys have a way of having a test database system living decoupled from a production database system on the same machine? We have a test.db database set up which we can query with 'whois -s TESTRR' and add data to by setting the 'source' attribute to TESTRR. The problem comes when running cleandb - it checks for conflicts by looking at the guardian files named in ~/etc/asdir and mails out conflict notices to real people about problems it thinks it's found. But actually the problems are bogus 'cause it's comparing production guardian files to test data. Does this make sense? Any thoughts would be great! Thanks a lot. Andy -------- Logged at Tue Apr 5 10:47:52 MET DST 1994 --------- From Marten.Terpstra at ripe.net Tue Apr 5 10:47:34 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Tue, 05 Apr 1994 10:47:34 +0200 Subject: db question In-Reply-To: Your message of Mon, 04 Apr 1994 17:13:50 EDT. <199404042113.RAA17652@merit.edu> Message-ID: <9404050847.AA09331@fs1.ripe.net> Andrew Adams writes * * Tony, Marten, Daniel, * * Do you guys have a way of having a test database system living decoupled fro * m * a production database system on the same machine? We have a test.db databas * e * set up which we can query with 'whois -s TESTRR' and add data to by setting * the 'source' attribute to TESTRR. The problem comes when running cleandb - * it checks for conflicts by looking at the guardian files named in * ~/etc/asdir and mails out conflict notices to real people about problems * it thinks it's found. But actually the problems are bogus 'cause it's * comparing production guardian files to test data. * * Does this make sense? yes it does. This is typically one of these problems you find when actually running the stuff. I will have to change this so that you can turn on/off guarded field addition per database or set the TESTMODE variable per database ... One idea to get around this for now is to use a different config file for this test database with TESTMODE set. You can use a different config by setting the environment variable RIPEDBCNF before you run any of the programs. Sorry, this is all I can do for now, I'll look at changing the software to cater for your problem. -Marten -------- Logged at Tue Apr 5 23:34:19 MET DST 1994 --------- From dsj at merit.edu Tue Apr 5 23:34:13 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Tue, 5 Apr 1994 17:34:13 -0400 Subject: Accounts on rrdb.merit.edu Message-ID: <199404052134.RAA08587@merit.edu> Marten, Tony, Daniel, As Marten suggested last week, I've created accounts for each of you on rrdb.merit.edu. The accounts have the same names and passwords as on whois.ripe.net. Normal civilities apply... :-) (Caution, where "rrdb.merit.edu" points to keeps moving around...) --Dale -------- Logged at Wed Apr 6 11:14:54 MET DST 1994 --------- From Marten.Terpstra at ripe.net Wed Apr 6 11:14:29 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Wed, 06 Apr 1994 11:14:29 +0200 Subject: Accounts on rrdb.merit.edu In-Reply-To: Your message of Tue, 05 Apr 1994 17:34:13 EDT. <199404052134.RAA08587@merit.edu> Message-ID: <9404060914.AA11431@fs1.ripe.net> "Dale S. Johnson" writes * Marten, Tony, Daniel, * * As Marten suggested last week, I've created accounts for each of you on * rrdb.merit.edu. The accounts have the same names and passwords as on * whois.ripe.net. Normal civilities apply... :-) Thanks much Dale! We'll behave, as we always do ;-) -Marten -------- Logged at Wed Apr 6 17:57:37 MET DST 1994 --------- From lpj at merit.edu Wed Apr 6 17:57:29 1994 From: lpj at merit.edu (Laurent Joncheray) Date: Wed, 6 Apr 94 11:57:29 EDT Subject: Why a flat file? Message-ID: <199404061557.LAA27996@merit.edu> Question for the RIPE programmers: Why do you use 2 files (a dbm file for the refenreces, and a flat file for the data), instead of just one dbm file with all the data? -- Laurent -------- Logged at Wed Apr 6 18:01:32 MET DST 1994 --------- From Marten.Terpstra at ripe.net Wed Apr 6 18:01:07 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Wed, 06 Apr 1994 18:01:07 +0200 Subject: Why a flat file? In-Reply-To: Your message of Wed, 06 Apr 1994 11:57:29 EDT. <199404061557.LAA27996@merit.edu> Message-ID: <9404061601.AA12531@fs1.ripe.net> Laurent Joncheray writes * Question for the RIPE programmers: * Why do you use 2 files (a dbm file for the refenreces, and a flat file * for the data), instead of just one dbm file with all the data? It is easier to handle, much easier to make ftp-able versions, and a lot smaller. Besides you can grep through a flat file, not through a dbm file. The dbm file only contains offsets in the flat file. Generally easier without losing much speed in lookups. -Marten -------- Logged at Wed Apr 6 18:22:19 MET DST 1994 --------- From Tony.Bates at ripe.net Wed Apr 6 18:22:03 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Wed, 06 Apr 1994 18:22:03 +0200 Subject: Why a flat file? In-Reply-To: Your message of Wed, 06 Apr 1994 18:01:07 MDT. <9404061601.AA12531@fs1.ripe.net> Message-ID: <9404061622.AA04955@fs1.ripe.net> Marten Terpstra writes: * * Laurent Joncheray writes * * Question for the RIPE programmers: * * Why do you use 2 files (a dbm file for the refenreces, and a flat file * * for the data), instead of just one dbm file with all the data? * * It is easier to handle, much easier to make ftp-able versions, and a * lot smaller. Besides you can grep through a flat file, not through a * dbm file. The dbm file only contains offsets in the flat file. * Generally easier without losing much speed in lookups. * * -Marten Apart the usability by other people/programs (agrep covers a lot of sins/scripts) the size of the dbm file is likely to be enourmous as well. Of course you can easily walk the whole dbm file and produce a readable version but the offset idea seems quick enough anyway so why bother ? --Tony -------- Logged at Wed Apr 6 18:30:33 MET DST 1994 --------- From lpj at merit.edu Wed Apr 6 18:30:22 1994 From: lpj at merit.edu (Laurent Joncheray) Date: Wed, 6 Apr 94 12:30:22 EDT Subject: Why a flat file? In-Reply-To: <9404061622.AA04955@fs1.ripe.net>; from "Tony Bates" at Apr 6, 94 6:22 pm Message-ID: <199404061630.MAA00759@merit.edu> > Apart the usability by other people/programs (agrep covers a lot of > sins/scripts) the size of the dbm file > is likely to be enourmous as well. Of course you can easily walk the > whole dbm file and produce a readable version but the offset idea > seems quick enough anyway so why bother ? What happens to the flat file when you do a delete or update? What about the updated offset? How does the flat file look like just before the cleandb job? lpj -- Laurent Joncheray, E-Mail: lpj at merit.edu Merit Network Inc, 1071 Beal Avenue, Phone: +1 (313) 936 2065 Ann Arbor, MI 48109, USA Fax: +1 (313) 747 3745 "This is the end, Beautiful friend. This is the end, My only friend, the end" JM -------- Logged at Wed Apr 6 18:35:47 MET DST 1994 --------- From Marten.Terpstra at ripe.net Wed Apr 6 18:35:28 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Wed, 06 Apr 1994 18:35:28 +0200 Subject: Why a flat file? In-Reply-To: Your message of Wed, 06 Apr 1994 12:30:22 EDT. <199404061630.MAA00759@merit.edu> Message-ID: <9404061635.AA12669@fs1.ripe.net> Laurent Joncheray writes * > Apart the usability by other people/programs (agrep covers a lot of * > sins/scripts) the size of the dbm file * > is likely to be enourmous as well. Of course you can easily walk the * > whole dbm file and produce a readable version but the offset idea * > seems quick enough anyway so why bother ? * * What happens to the flat file when you do a delete or * update? What about the updated offset? How does the flat file look like * just before the cleandb job? This is what happens at a delete: - the object is looked up - the reference in the dbm file to this object is removed (therefore this object can no longer be looked up) - the first attribute (*in: for networks) is replaced by (*XX:) thereby not changing the file size and other offsets - any new objects are ALWAYS appended to the file, and offsets added to the dbm file - at cleandb the bit that reads objects will automatically skip objects that start with *XX, therefore removing all the old (removed) objects. An update is nothing more than a delete followed by an addition. -Marten -------- Logged at Wed Apr 6 22:33:19 MET DST 1994 --------- From epg at merit.edu Wed Apr 6 22:33:06 1994 From: epg at merit.edu (epg at merit.edu) Date: Wed, 6 Apr 94 16:33:06 EDT Subject: announcement Message-ID: <9404062033.AA04887@pepper.merit.edu> Hi Daniel, Are you feeling better? We really missed you at the IETF and IEPG meetings. But it was probably nice to stay home. Have you had a chance to review the announcement about the Merit Routing Registry? We would really like to make a joint announcement with RIPE and by the end of this week if possible. Bill Manning has been a cooperative guinea pig and Laurent has completed a rewrite of prtraceroute and the corresponding policy server which can reference each of our files in their native form. So we are ready to announce. Please let us know where you all stand on this. Thanks. --Elise -------- Logged at Wed Apr 6 23:01:15 MET DST 1994 --------- From GeertJan.deGroot at ripe.net Wed Apr 6 23:00:48 1994 From: GeertJan.deGroot at ripe.net (Geert Jan de Groot) Date: Wed, 06 Apr 1994 23:00:48 +0200 Subject: announcement In-Reply-To: Your message of "Wed, 06 Apr 1994 16:33:06 EDT." <9404062033.AA04887@pepper.merit.edu> Message-ID: <9404062100.AA08405@belegen.ripe.net> On Wed, 6 Apr 94 16:33:06 EDT epg at merit.edu wrote: > Hi Daniel, > Are you feeling better? We really missed you at the IETF and IEPG > meetings. But it was probably nice to stay home. Daniel's flu has traded places with angina. The antibiotica affects him badly. Could you wait till monday, so he will have the weekend additional time to recover? Judging his state over the telephone, I feel it's really appropiate to force him to stay home this week... Geert Jan -------- Logged at Wed Apr 27 23:53:06 MET DST 1994 --------- From dsj at merit.edu Wed Apr 27 23:52:42 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Wed, 27 Apr 1994 17:52:42 -0400 Subject: Merit Routing Registry questions... Message-ID: <199404272152.RAA19950@merit.edu> Jamshid, Glad to have you using the RRDB! We're still building production infrastructure for this, so its a really good time to let us know what we can build in to make you life easier. (Like you've done, below). > I believe that I can do all of the pieces necessary for this audit, > except the first step of listing out all of the networks registered > to our AS in the RRDB. (Currently, we grab the whole file from the > PRDB and do what amounts to a grep... This does not scale well!) What kinds of solution would you like to see for this? (We also generate many of the PRDB reports by "grep'ing" nets.unl.now; it takes 6 seconds with a C program, and 90 seconds with Perl.) The Routing Registry database files are less terse than nets.unl.now, so they could take a bit longer. > Can anyone comment on when this sort of functionality will be available > in the RRDB? Also, is there anything else we should be doing to get > our nets into the RRDB? We currently assume that the PRDB copies are > transferred in. Ok; we've just put the system in place to post the parts of the MERITRR for anonymous ftp: pick up rrdb.merit.edu:pub/meritrr/dbase/meritrr.db.Z and prdb.db.Z . You can pick up the most current RIPE db from ftp.ripe.net . To get the home ASs associated with AS204, look for records (blocks of lines) that include the line "*as: AS204", then print out the previous line that begins with "*in:" to get the IP address: *in: 161.224/16 <------------------------- print out this. *na: BUCKEYEPTR *de: Buckeye Pipe Line Company *de: 5002 Buckeye Road PO Box 368 *de: Emmaus *de: PA 18049, USA *cy: US *ni: 1=204 2=1206 *as: AS204 <------------------------- look for this *ch: skw at merit.edu 931113 *so: PRDB I could send a tiny perl program to do this, if it would help. > Can anyone comment on when this sort of functionality will be available > in the RRDB? Also, is there anything else we should be doing to get > our nets into the RRDB? We currently assume that the PRDB copies are > transferred in. You don't need to do anything, though you are free to add more information to the RRDB or to take control of the information that is there yourself. (Actually, we'd really appreciate your entering your AS policy information, to help us figure whether we're supporting enough syntax to describe your policy). The way we are handling this is that the MERITRR tools look at three "databases": meritrr.db (which is where all direct MERITRR updates take place), ripe.db (ftp'd from RIPE each morning), and prdb.db (a dump of a subset of the PRDB information in Routing Registry format, updated with each PRDB config run). Handling the PRDB data this way makes it automatically available to the new MERITRR tools. It also allows us to update that data regularly from the PRDB, without interfering with data that users have entered directly. If you do nothing about updating your own data, a minimum subset of your data from the PRDB will appear automatically to the MERITRR tools because of the MERITRR prdb.db database. If you would like to take more control of your registrations, you can control your own information by submitting templates (like NACRs) to auto-dbm at rrdb.merit.edu. All of the information you submit will be kept in the meritrr.db, and will be used in preference to any information that is there because it has been copied from the PRDB. (Every time that the tools look for any attribute, they look for it first in the meritrr.db, then in the ripe.db, then in the prdb.db). Because of this you could, for instance, enter network descriptions in the meritrr.db that just had administrative contact info, and let the PRDB process automatically update other information about those networks. Once you enter such data, it stays there until you change it. No automatic update process will change what you entered. Does description make sense? (Does the system, too?) Does this answer your questions? If we could interest you in entering some data into the new registry, the file rrdb.merit.edu:pub/meritrr/rr_user_doc.txt gives an overview of the process. Let us know any way we can help. --Dale ============================================ > All, > > PSC & PREPnet are in a position of needing to upgrade our configuration > software. We have automated mechanism to generate gated.conf files which > are similar to those used by ANS to generate configs from the PRDB. > The advent of CIDR has made our current mechanisms a bit unstable, so we > need to bring things up to date. > > The basics steps in our configuration are (1) do a policy audit, > (2) analyze our policy data-base and (3) write the configuration files. > The policy audit step is the part which is relevant to this list. > > Our audit consists basically of determining that our locally configured > policy for each net in each of our AS's matches the PRDB (currently) > policy for that net. Nets which do not match are flagged and corrected > either locally or in the PRDB. Since we need to rewrite this software, > and we only want to do it once, we want to move to using the RRDB instead. > > The basic thing we need to be able to do is get the list of all of the > networks registered to each of our AS's. We then look for three cases: > 1) We list the net in our policy, but the RRDB does not. > 2) The RRDB has the net with one of our AS's, but we do not. > 3) Both databases have the net, but the policies are different. > > I believe that I can do all of the pieces necessary for this audit, > except the first step of listing out all of the networks registered > to our AS in the RRDB. (Currently, we grab the whole file from the > PRDB and do what amounts to a grep... This does not scale well!) > > Can anyone comment on when this sort of functionality will be available > in the RRDB? Also, is there anything else we should be doing to get > our nets into the RRDB? We currently assume that the PRDB copies are > transferred in. > > Thanks, > > --Jamshid > > PS. We aren't yet on the rr-disc mail list, so please cc responses > to everyone until tomorrow. > -------- Logged at Wed Apr 27 23:54:54 MET DST 1994 --------- From dsj at merit.edu Wed Apr 27 23:54:52 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Wed, 27 Apr 1994 17:54:52 -0400 Subject: rr-disc@rrdb.merit.edu Message-ID: <199404272154.RAA20089@merit.edu> Daniel, Tony, Marten, I just bcc'd you on one message on rr-disc. Could I add you to that list? --Dale -------- Logged at Thu Apr 28 11:40:14 MET DST 1994 --------- From jimi at dxcoms.cern.ch Thu Apr 28 11:40:07 1994 From: jimi at dxcoms.cern.ch (Jean-Michel Jouanigot) Date: Thu, 28 Apr 1994 11:40:07 +0200 (MET DST) Subject: as-in/as-out In-Reply-To: <9404271950.AA04958@mature.ripe.net> from "Tony Bates" at Apr 27, 94 09:50:30 pm Message-ID: <9404280940.AA07408@dxcoms.cern.ch> > by accepting this we accept one agg - multi ASes is permited. The only > bit that is difficult is making sure we keep the clarity (i.e. provide > help to the policy maintainers) and make the tools work ;-). > And this is the more important thing to keep in mind, I think. Whatever syntax we may agree on, it will only help if we can have tools to use it in a real life network. -- Jean-Michel -------- Logged at Thu Apr 28 12:11:57 MET DST 1994 --------- From Marten.Terpstra at ripe.net Thu Apr 28 12:11:53 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Thu, 28 Apr 1994 12:11:53 +0200 Subject: as-in/as-out In-Reply-To: Your message of Wed, 27 Apr 1994 16:44:38 EDT. <199404272044.QAA12394@merit.edu> Message-ID: <9404281011.AA13462@fs1.ripe.net> Jessica Yu writes * Now, in stead of sending two mails, I may as well answer Jessica's * question, and you are right that this is not clear from the doc, but * we recognized that an aggregate can be aggregated at multiple places * (and legally so, although it may create a policy maintainer's * nightmare, and has all sorts of policy implications, but all that is * nothing new) and therefore origin CAN contain more than one value. * * Good. * * The "single" definition is a RIPE database like definition, which means it * can only be one line, but on that line there can be multiple origins. * * Why not allow multiple lines then? If it is single line * with multiple values, what is the devider , a space or a ','? I'd like to leave this like the communities and the current routpr and bdrygw, ie spaces, no commas. I think there is no problem with making this one multi line. -Marten -------- Logged at Thu Apr 28 16:33:20 MET DST 1994 --------- From dsj at merit.edu Thu Apr 28 16:33:18 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Thu, 28 Apr 1994 10:33:18 -0400 Subject: Couple questions Message-ID: <199404281433.KAA21142@merit.edu> Tony, > * * Does the "guardian" field actually do anything for AS objects? (Any o > * ther > * * objects?) > * > * No, it is info only. It could however in the future be used for > * automatic notification and authorisation. > * > Well - actually I use it for a script I did for generating the > guardian accounts to find the initial forwarding address. The original > idea was to use this as the forward address constantly updated from > the object but the providers at the RIPE meeting said they'd prefer > to update the forward and then the object. > > BTW: if you are interested in these scripts you have them. They are > built around our rash environment though. We're running your rash environment! (As of yesterday!) Yep, could you point us to the scripts? Thanks. --Dale -------- Logged at Thu Apr 28 17:20:14 MET DST 1994 --------- From Daniel.Karrenberg at ripe.net Thu Apr 28 17:20:03 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 28 Apr 1994 17:20:03 +0200 Subject: as-in/as-out In-Reply-To: Your message of Wed, 27 Apr 1994 13:40:28 EDT. <9404271740.AA01578@pepper.merit.edu> Message-ID: <9404281520.AA03806@reif.ripe.net> > epg at merit.edu writes: > Have just quickly browsed thru the document. Thanks for sending it. > > On the paragraph that says: > "Conceptually there can be multiple route objects with different > origins. Representing multiple proxy aggregation which to our knowledge > is not done in the Internet yet." revised version: Conceptually there can be multiple route objects for the same route with different origins. This will represent that the same route is originated by different ASes. Such entries will represent multiple proxy aggregation by *different* ASes which to our knowledge is not done in the Internet yet. We have not thoroughly investigated the consequences this added complexity will have for consistency checking and the PRIDE tools. > The NSFNET service will be doing proxy aggregation for DISA and Westnet > real soon now (the code is ready). We can do proxy to the nth level without multiple route objects. It is just when two *different* ASes announce the *same* route that we need multiple route objects. These we can accept into the registry no problem. It is just a problem that we do not know how useful the output of the tools can be in the face of this. > And it seems likely that some > multi-homed entity in the future will ask both(or more) peer ASs to > aggregate nets on their behalf. Could the unique key be route and origin, > instead of just route? How would you propose to deal with > this case? It seems shortsighted of us if we cannot accommodate proxy > aggregation. The answer is yes and the proposal intended to say so. I hope it is clearer now. Daniel -------- Logged at Thu Apr 28 17:23:34 MET DST 1994 --------- From Daniel.Karrenberg at ripe.net Thu Apr 28 17:23:24 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 28 Apr 1994 17:23:24 +0200 Subject: as-in/as-out In-Reply-To: Your message of Wed, 27 Apr 1994 13:50:39 EDT. <199404271750.NAA25864@merit.edu> Message-ID: <9404281523.AA03819@reif.ripe.net> > Jessica Yu writes: > > I assume 'origin' has the same concept as 'creator' which we defined at our > San Diego meeting. Just try to be sure. Yes. If we call it route then origin sounded better but we can change it to creator again if you like. > Does your definition above mean that one route can only have one 'origin'? No. See my response to elise. > Proxy aggregate like mentioned in your write up is not been done yet. But > it will be very soon. Proxy aggregation per-se is not a problem. It gets hairy if it is done by multiple ASes. But the registry will support that. > Proxy aggregate for multi-homed AS will be done when people get desperte to > reduce the routing table size, so does aggregation beyond AS boundary. So > it is really desirable for routing registry to be designed to anticipate th > is > will happen and be able to deal with it. If you allow one route has more t > han > one orgin, that will do it. What is the concern of doing that? The concern is not with the registry but with the usefulness of the tools. Daniel PS: Now we make a proposal that drops one-net one AS and we still get flamed. :-( ;-) Daniel -------- Logged at Thu Apr 28 17:25:40 MET DST 1994 --------- From Daniel.Karrenberg at ripe.net Thu Apr 28 17:25:36 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 28 Apr 1994 17:25:36 +0200 Subject: as-in/as-out In-Reply-To: Your message of Wed, 27 Apr 1994 21:31:12 MDT. <9404271931.AA17924@mellow.ripe.net> Message-ID: <9404281525.AA03834@reif.ripe.net> > Marten Terpstra writes: > > Now, in stead of sending two mails, I may as well answer Jessica's > question, and you are right that this is not clear from the doc, but > we recognized that an aggregate can be aggregated at multiple places > (and legally so, although it may create a policy maintainer's > nightmare, and has all sorts of policy implications, but all that is > nothing new) and therefore origin CAN contain more than one value. The > "single" definition is a RIPE database like definition, which means it > can only be one line, but on that line there can be multiple origins. Nope. Propbably it was too late last night. Per route object origin can have only one value. If multiple ASes originate the same route there will bne multiple route objects. > Daniel and Tony, please correct me if I am totally wrong, but this is > how I remember the discussion. Just did. -------- Logged at Thu Apr 28 17:31:28 MET DST 1994 --------- From Daniel.Karrenberg at ripe.net Thu Apr 28 17:31:24 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 28 Apr 1994 17:31:24 +0200 Subject: Proposal Message-ID: <9404281531.AA03885@reif.ripe.net> I'll send round another version later tonight. The question for the MERIT folks is: Does this plus the advisory cut it for your needs or do you need more extensions. If so can you propose them? The goal is to come to a common proposal for the RIPE routing wg. Daniel -------- Logged at Thu Apr 28 17:39:56 MET DST 1994 --------- From jyy at merit.edu Thu Apr 28 17:39:42 1994 From: jyy at merit.edu (Jessica Yu) Date: Thu, 28 Apr 1994 11:39:42 -0400 Subject: as-in/as-out In-Reply-To: Your message of "Thu, 28 Apr 1994 17:23:24 +0200." <9404281523.AA03819@reif.ripe.net> Message-ID: <199404281539.LAA27688@merit.edu> > Proxy aggregate for multi-homed AS will be done when people get desperte to > reduce the routing table size, so does aggregation beyond AS boundary. So > it is really desirable for routing registry to be designed to anticipate th > is > will happen and be able to deal with it. If you allow one route has more t > han > one orgin, that will do it. What is the concern of doing that? The concern is not with the registry but with the usefulness of the tools. Daniel PS: Now we make a proposal that drops one-net one AS and we still get flamed. :-( ;-) No flame,just try to point out the reality :-) It is good to know that we agree on this. Wrt to tools, there must be a way to make the tool work, right? Thanks! --jessica -------- Logged at Thu Apr 28 17:52:36 MET DST 1994 --------- From jyy at merit.edu Thu Apr 28 17:52:25 1994 From: jyy at merit.edu (Jessica Yu) Date: Thu, 28 Apr 1994 11:52:25 -0400 Subject: as-in/as-out Message-ID: <199404281552.LAA29231@merit.edu> >From Daniel: >Nope. Propbably it was too late last night. >Per route object origin can have only one value. >If multiple ASes originate the same route there will bne multiple >route objects. Why not allow one route object with multiple origins to save some overhead? Also, it will be good if you make a clear description on this part in your document. --Jessica ------- Forwarded Message Return-Path: dfk at ripe.net Received: from ncc.ripe.net (ncc.ripe.net [192.87.45.2]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id LAA26113; Thu, 28 Apr 1994 11:25:41 -0400 Received: from reif.ripe.net by ncc.ripe.net with SMTP id AA05120 (5.65a/NCC-2.2); Thu, 28 Apr 1994 17:25:37 +0200 Received: from localhost.ripe.net by reif.ripe.net with SMTP id AA03834 (5.65a/NCC-2.1); Thu, 28 Apr 1994 17:25:36 +0200 Message-Id: <9404281525.AA03834 at reif.ripe.net> To: Marten Terpstra Cc: epg at merit.edu, rr-impl at ripe.net, jimi at cernvax.cern.ch Subject: Re: as-in/as-out In-Reply-To: Your message of Wed, 27 Apr 1994 21:31:12 MDT. <9404271931.AA17924 at mellow.ripe.net> From: Daniel Karrenberg X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5065 Date: Thu, 28 Apr 1994 17:25:36 +0200 Sender: Daniel.Karrenberg at ripe.net > Marten Terpstra writes: > > Now, in stead of sending two mails, I may as well answer Jessica's > question, and you are right that this is not clear from the doc, but > we recognized that an aggregate can be aggregated at multiple places > (and legally so, although it may create a policy maintainer's > nightmare, and has all sorts of policy implications, but all that is > nothing new) and therefore origin CAN contain more than one value. The > "single" definition is a RIPE database like definition, which means it > can only be one line, but on that line there can be multiple origins. Nope. Propbably it was too late last night. Per route object origin can have only one value. If multiple ASes originate the same route there will bne multiple route objects. > Daniel and Tony, please correct me if I am totally wrong, but this is > how I remember the discussion. Just did. ------- End of Forwarded Message -------- Logged at Thu Apr 28 17:59:51 MET DST 1994 --------- From epg at merit.edu Thu Apr 28 17:59:47 1994 From: epg at merit.edu (Elise Gerich) Date: Thu, 28 Apr 1994 11:59:47 -0400 Subject: route/origin Message-ID: <199404281559.LAA29789@merit.edu> Daniel, > > > > epg at merit.edu writes: > > Have just quickly browsed thru the document. Thanks for sending it. > > > > On the paragraph that says: > > "Conceptually there can be multiple route objects with different > > origins. Representing multiple proxy aggregation which to our knowledge > > is not done in the Internet yet." > > revised version: > > Conceptually there can be multiple route objects for the > same route with different origins. > This will represent that the same route is originated by different ASes. > Such entries will represent multiple proxy aggregation by > *different* ASes which to our knowledge is not done in the Internet yet. > We have not thoroughly investigated the consequences this added > complexity will have for consistency checking and the PRIDE tools. > > > The NSFNET service will be doing proxy aggregation for DISA and Westnet > > real soon now (the code is ready). > > We can do proxy to the nth level without multiple route objects. > It is just when two *different* ASes announce the *same* route that > we need multiple route objects. These we can accept into the registry > no problem. It is just a problem that we do not know how useful the > output of the tools can be in the face of this. > > > And it seems likely that some > > multi-homed entity in the future will ask both(or more) peer ASs to > > aggregate nets on their behalf. Could the unique key be route and origin, > > instead of just route? How would you propose to deal with > > this case? It seems shortsighted of us if we cannot accommodate proxy > > aggregation. > > The answer is yes and the proposal intended to say so. I hope it > is clearer now. Let me repeat what I think has been said - just to make sure I have it straight. 1)The route object will NOT permit multiple values for the origin attribute. 2)The unique key will be route/origin, thereby permitting multiple entries for the same route in the registries. 3)The Merit Routing Registry can replace the INETNUM object with the ROUTE object. The ROUTE object is the "policy" relevant object. The INETNUM object is the assignment/allocation relevant object. As Jessica, has mentioned, our initial preference is to permit multiple values for the origin attribute. It seems cleaner to us, and would require fewer modifications to current tools (we think). We are VERY happy that we have some common aggreegment about route and origin - not flaming - just trying to have a constructive conversation :-) Will look forward to the next version of the proposal. --Elise -------- Logged at Thu Apr 28 18:00:45 MET DST 1994 --------- From dsj at merit.edu Thu Apr 28 18:00:31 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Thu, 28 Apr 1994 12:00:31 -0400 Subject: as-in/as-out Message-ID: <199404281600.MAA00194@merit.edu> > >Nope. Propbably it was too late last night. > >Per route object origin can have only one value. > >If multiple ASes originate the same route there will bne multiple > >route objects. > > Why not allow one route object with multiple origins to save > some overhead? No; if you have multiple people creating the aggregate, you might have multiple names for that route, you definitely should have multiple technical contacts, etc. Multiple objects is cleaner. --Dale -------- Logged at Thu Apr 28 18:05:33 MET DST 1994 --------- From Daniel.Karrenberg at ripe.net Thu Apr 28 18:05:24 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 28 Apr 1994 18:05:24 +0200 Subject: as-in/as-out In-Reply-To: Your message of Thu, 28 Apr 1994 11:52:25 EDT. <199404281552.LAA29231@merit.edu> Message-ID: <9404281605.AA03952@reif.ripe.net> > Jessica Yu writes: > > Why not allow one route object with multiple origins to save > some overhead? Also, it will be good if you make a clear > description on this part in your document. Multiple problems: Who maintains that route object? What if there are different components/hols making up the two routes. -------- Logged at Thu Apr 28 18:08:05 MET DST 1994 --------- From Daniel.Karrenberg at ripe.net Thu Apr 28 18:07:59 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 28 Apr 1994 18:07:59 +0200 Subject: route/origin In-Reply-To: Your message of Thu, 28 Apr 1994 11:59:47 EDT. <199404281559.LAA29789@merit.edu> Message-ID: <9404281607.AA03969@reif.ripe.net> > Elise Gerich writes: > Let me repeat what I think has been said - just to make sure I have it > straight. > > 1)The route object will NOT permit multiple values for the origin attribute Correct. > 2)The unique key will be route/origin, thereby permitting multiple entries > for the same route in the registries. Correct. > 3)The Merit Routing Registry can replace the INETNUM object with the > ROUTE object. The ROUTE object is the "policy" relevant object. The > INETNUM object is the assignment/allocation relevant object. Correct. > As Jessica, has mentioned, our initial preference is to permit > multiple values for the origin attribute. It seems cleaner > to us, and would require fewer modifications to current tools (we think). The problem with it is control. The object is guarded by the AS guardian. What if there are many? Also what if the components or even the description differ? -------- Logged at Thu Apr 28 18:08:35 MET DST 1994 --------- From Daniel.Karrenberg at ripe.net Thu Apr 28 18:08:29 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 28 Apr 1994 18:08:29 +0200 Subject: route/origin In-Reply-To: Your message of Thu, 28 Apr 1994 11:59:47 EDT. <199404281559.LAA29789@merit.edu> Message-ID: <9404281608.AA03979@reif.ripe.net> > Elise Gerich writes: > We are VERY happy that we have some common aggreegment about > route and origin - not flaming - just trying to have a constructive > conversation :-) Of course :-). -------- Logged at Thu Apr 28 20:20:24 MET DST 1994 --------- From epg at merit.edu Thu Apr 28 20:20:12 1994 From: epg at merit.edu (epg at merit.edu) Date: Thu, 28 Apr 94 14:20:12 EDT Subject: as-in/as-out In-Reply-To: <9404271502.AA00834@reif.ripe.net>; from "Daniel Karrenberg" at Apr 27, 94 5:02 pm Message-ID: <9404281820.AA01886@pepper.merit.edu> OK, back to as-in/as-out or another attribute. I did dig up all the messages (2). Here are the comments that referred specifically to as-in/as-out: tony.bates at ripe.net writes: 1) "When do you stop this list (explicit net #s) and turn it into a community list anyway just for clarity, 10, 1000, ?" as-in comment 2) "I would like to see tis metric part noted as advisory information as well and clearly that as this is all it is and not enforceable at all." as-out comment 3) "Some general things. I'm not sure the verbosity of optional 'to, announce, accept' really adds much. As an operator I want the tools to do things for me and if I need verbosity get them to pput in there. These are all directly implicted so if needed get the server to do it." as-in and as-out comments 4) "I see why you might like this but hasn't it just gone into an area of complexity you don't want in the registry. I do see it but I do not think it will be used except by a few very large transit sites and then could easily map this information in another way. The only tool where this might help is in prtraceroute I guess." gateway info for as-in and as-out comment 5) "Again this is fine except for the level of complexity it adds to the representation." db selector comment daniel.karrenberg at ripe.net writes: 1 "- I personally do not like the [to] [from] etc. syntactic sugar. Users who want a more comfortable input language, should use a local post preprocessor which we should provide. If the routing registry itself (view it as a database) provides different representations we will get lots of confusion as to the semantics. Also all tools using the RR will have to accept multiple representations which is only adding possibilities for bugs and general entropy" 2 "- The RIPE-81 as-out does *not* have a preference for a reason. I (think I) know what you want to do, BUT... Try to define the semantics in a clear, concise and understandable way! I cannot. This will also obscure the principle of what as-in and as-out really means. This will lead to confusion even if its optionality and advisory nature is clearly marked. The only gain obtainable from it is some conistency checking implementable only if the full topology is known. Rather use as-exclude and as-transit for this as these are clearly non-local attributes." 3 "- border router level - this should not go in the as-out attributes but rather be a separate set of attributes line 'link-out' 'link-in' with a requirement to have the as-in and as-out as well. this way you get an optional level of complexity." I will focus on two of the issues mentioned: as-out metrics and the gateway semantics. One of the "services" that this registry can offer is configuration generation. With the NSFNET experience and what we anticipate will be expected from the RA, this information is needed to generate the correct configuration files. So whereas this information is not binding, and it is not used by tools such as prtraceroute, it would be needed in the generation of router configurations. The border router extension solves the problem of an autonomous system that has two border routers that have different routing policies - Barrnet does this all the time. So it seemed logical to associate 'border route', 'neighbor', and 'cost' in the same attribute. In the RIPE-81 as-in attribute this added one optional value; in the RIPE-81 as-out attribute it would require making as-out syntactically consistent with as-in. The value of adding this (even if rarely used) is the ability to generate router configurations and for prtraceroute (as Tony says). --Elise -------- Logged at Thu Apr 28 21:37:13 MET DST 1994 --------- From jyy at merit.edu Thu Apr 28 21:37:05 1994 From: jyy at merit.edu (Jessica Yu) Date: Thu, 28 Apr 1994 15:37:05 -0400 Subject: as-in/as-out In-Reply-To: Your message of "Thu, 28 Apr 1994 18:05:24 +0200." <9404281605.AA03952@reif.ripe.net> Message-ID: <199404281937.PAA23181@merit.edu> >What if there are different components/hols making up the two routes. It is dangrous for two ASs make the same proxy aggregate route with different components. That is something should be avoided and perhaps outlawed. By using one route object for multiple origins, it is able to ENFORCE different ASs make consistent agggregate when they proxy for other ASs. That is a good argument for the design. Who controls? The first AS regists win. Of course, they have to cordinate when the second AS regist the same route object. If they want to update that object, they have to coordinate and they need to coordinate with each other if the make the proxy aggr for the a particular AS. --Jessica Date: Thu, 28 Apr 1994 18:05:24 +0200 To: Jessica Yu cc: epg at merit.edu, rr-impl at ripe.net, jimi at cernvax.cern.ch From: Daniel Karrenberg Subject: Re: as-in/as-out Return-Path: dfk at ripe.net In-Reply-To: Your message of Thu, 28 Apr 1994 11:52:25 EDT. <199404281552.LAA29231 at merit.edu> X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5065 Sender: Daniel.Karrenberg at ripe.net > Jessica Yu writes: > > Why not allow one route object with multiple origins to save > some overhead? Also, it will be good if you make a clear > description on this part in your document. Multiple problems: Who maintains that route object? What if there are different components/hols making up the two routes. -------- Logged at Thu Apr 28 21:46:22 MET DST 1994 --------- From jyy at merit.edu Thu Apr 28 21:46:10 1994 From: jyy at merit.edu (Jessica Yu) Date: Thu, 28 Apr 1994 15:46:10 -0400 Subject: as-in/as-out In-Reply-To: Your message of "Thu, 28 Apr 1994 12:00:31 EDT." <199404281600.MAA00194@merit.edu> Message-ID: <199404281946.PAA24412@merit.edu> > >Nope. Propbably it was too late last night. > >Per route object origin can have only one value. > >If multiple ASes originate the same route there will bne multiple > >route objects. > > Why not allow one route object with multiple origins to save > some overhead? No; if you have multiple people creating the aggregate, you might have multiple names for that route, you definitely should have multiple technical contacts, etc. Multiple objects is cleaner. --Dale There is a good reason to keep in one object see my previous message to Daniel. Also for multiple tech contacts etc. one possiability is to do a second look up to AS object using the AS number in origin field (Laurent's idea). --Jessica -------- Logged at Thu Apr 28 21:47:01 MET DST 1994 --------- From ala at merit.edu Thu Apr 28 21:46:58 1994 From: ala at merit.edu (Andrew Adams) Date: Thu, 28 Apr 1994 15:46:58 -0400 Subject: /etc/passwd/ASXX entries Message-ID: <199404281946.PAA24481@merit.edu> Hi guys. We discovered something interesting regarding /etc/passwd and /bin/mail. It turns out that the man page for /etc/passwd says that all user login names must be lower case. Now, when we had all the software running on mole.merit.edu, everything worked great. We had user names of the form "ASXX" and mail destined for these accounts (ie. generated by cleandb) found its way just great. However, when we moved things to fox.merit.edu, we ran into mail problems. (The reason that the problems only became evident today is another story.) As we all know, the way UNIX mail works is that sendmail receives a msg addressed to "ASXXX" and, if it is a local address, hands the msg off to the local mailer. In this case the local mailer is /bin/mail. /bin/mail takes to msg, parses the address to extract the user name, looks up the user name in /etc/passwd to verify that (s)he does in fact exist, and then writes the msg to /usr/spool/mail/. Well, the version of /bin/mail running on fox.merit.edu (which is much newer than the version on mole.merit.edu) seems to fold the case of the user name before looking up the entry in /etc/passwd. Thus, even though user ASXXX has an entry in /etc/passwd, mail destined to ASXXX at fox.merit.edu cannot be delivered because /bin/mail is looking for user "asXXX". Have you guys had any problems of this type before? Can you think of any things that might break if we change all our user account names to be lower case? Thanks for any info! -Andy -------- Logged at Thu Apr 28 21:58:57 MET DST 1994 --------- From Daniel.Karrenberg at ripe.net Thu Apr 28 21:58:49 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 28 Apr 1994 21:58:49 +0200 Subject: as-out metrics In-Reply-To: Your message of Thu, 28 Apr 1994 14:20:12 EDT. <9404281820.AA01886@pepper.merit.edu> Message-ID: <9404281958.AA19426@mellow.ripe.net> > One of the "services" that this registry can offer is configuration > generation. With the NSFNET experience and what we anticipate > will be expected from the RA, this information is needed to > generate the correct configuration files. But what does it mean? Either you announce something or you don't, right? Or do you mean that only the lowest cost gets announced as long as that peering stays up and if it is down the next higher cost ... Or does it mean a metric (in external routing, huh?) Or something entirely different that I don't understand? > So whereas this information > is not binding, and it is not used by tools such as prtraceroute, > it would be needed in the generation of router configurations. Whose? how? The fist question is the important one. If it is something the AS which registers it configures, it is probably OK. If it is something someone else may or may not configure it is not OK architecturally because as-in and as-out are designed to describe exactly what the AS itself configures and has authority over. Any advisory information should be put somewhere else. Daniel -------- Logged at Thu Apr 28 22:11:53 MET DST 1994 --------- From lpj at merit.edu Thu Apr 28 22:11:49 1994 From: lpj at merit.edu (Laurent Joncheray) Date: Thu, 28 Apr 94 16:11:49 EDT Subject: as-out metrics In-Reply-To: <9404281958.AA19426@mellow.ripe.net>; from "Daniel Karrenberg" at Apr 28, 94 9:58 pm Message-ID: <199404282011.QAA27499@merit.edu> Ok, i try to explain... When you have a router and you export a route to someone else (for instance an RS6000 :-) running gated), you have to configure the metric BGP is going to put in its outgoing packets. With gated it will be something like: bgp yes { [...] group type external peeras 690 metricout 5 version 4 lcladdr 35.42.1.56 { peer 140.222.51.62 gateway 35.42.1.56; }; }; The metric in as-out is *what you configure in your router* (here it is 5) So: - You have TOTAL control of it. - It is optional, so if you don't care (if you use the router's default value) then DON'T USE IT. - Some philosophers will talk about this metric as a preference or an advise for the neighbourg ASes. I don't care. My job is to generate config files for routers (included gated) so if people want to have 'metricout 31416' in their dam config file they need to specify it somewhere. And somewhere is in as-out. Laurent PS: This is only my 2 cents. > > > > One of the "services" that this registry can offer is configuration > > generation. With the NSFNET experience and what we anticipate > > will be expected from the RA, this information is needed to > > generate the correct configuration files. > > But what does it mean? > Either you announce something or you don't, right? > Or do you mean that only the lowest cost gets announced as long > as that peering stays up and if it is down the next higher cost ... > Or does it mean a metric (in external routing, huh?) > Or something entirely different that I don't understand? > > > So whereas this information > > is not binding, and it is not used by tools such as prtraceroute, > > it would be needed in the generation of router configurations. > > Whose? how? > The fist question is the important one. If it is something the > AS which registers it configures, it is probably OK. If it is > something someone else may or may not configure it is not OK > architecturally because as-in and as-out are designed to describe > exactly what the AS itself configures and has authority over. > Any advisory information should be put somewhere else. > > Daniel > -- Laurent Joncheray, E-Mail: lpj at merit.edu Merit Network Inc, 1071 Beal Avenue, Phone: +1 (313) 936 2065 Ann Arbor, MI 48109, USA Fax: +1 (313) 747 3745 "This is the end, Beautiful friend. This is the end, My only friend, the end" JM -------- Logged at Thu Apr 28 22:13:33 MET DST 1994 --------- From Daniel.Karrenberg at ripe.net Thu Apr 28 22:13:24 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 28 Apr 1994 22:13:24 +0200 Subject: border routers In-Reply-To: Your message of Thu, 28 Apr 1994 14:20:12 EDT. <9404281820.AA01886@pepper.merit.edu> Message-ID: <9404282013.AA19441@mellow.ripe.net> > epg at merit.edu writes: > 3 "- border router level - this should not go in the as-out attributes but > rather be a separate set of attributes line 'link-out' 'link-in' with > a requirement to have the as-in and as-out as well. this way you get > an optional level of complexity." > > The border router extension solves the problem of an autonomous > system that has two border routers that have different routing > policies Understood. But the differences cannot be that big. Otherwise we'd talk about different ASes. > - Barrnet does this all the time. So it seemed logical > to associate 'border route', 'neighbor', and 'cost' in the same > attribute. In the RIPE-81 as-in attribute this added one optional > value; in the RIPE-81 as-out attribute it would require making > as-out syntactically consistent with as-in. The value of adding > this (even if rarely used) is the ability to generate router > configurations and for prtraceroute (as Tony says). I agree with adding the possibility for this. It is actually a long standing action on PeterL to come up with a proposal. There is no dispute about this. What I object to is to putting this added complexity into as-in/as-out because it is another level of the ASes routing policy altogether. This is something entirely between the neighbors in a peering and not visible beyond that, right? It should be documented as such *in addition* to the generally valid routing policy. Advantages: no confusion of current users; no added complexity to worry about in as-in/as-out for ASes with homogeneous policy in border routers - the majority; clarity what the ASes common policy is and what is exit dependent; existing tools still work. Disadvatages: none that I can see Syntactic consistency -while appealing and seemingly simpler to use- is not a goal in itself in a design like this. It can actually make things more difficult to understand by adding too many "null" or "unused" options. as-in and as-out as they stand are not syntactically consistent. as-out does not have a cost. This has a reason as explained in my last message. Daniel -------- Logged at Thu Apr 28 22:22:25 MET DST 1994 --------- From Daniel.Karrenberg at ripe.net Thu Apr 28 22:22:21 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 28 Apr 1994 22:22:21 +0200 Subject: as-in/as-out In-Reply-To: Your message of Thu, 28 Apr 1994 15:37:05 EDT. <199404281937.PAA23181@merit.edu> Message-ID: <9404282022.AA19451@mellow.ripe.net> > Jessica Yu writes: > >What if there are different components/hols making up the two routes. > > It is dangrous for two ASs make the same proxy aggregate route > with different components. I know. I agree. > That is something should be avoided Certainly. > and perhaps outlawed. Internet routing and The Law. Interesting thought :-). > By using one route object for multiple origins, it is able to > ENFORCE different ASs make consistent agggregate when they proxy > for other ASs. That is a good argument for the design. By the same token proxy aggregation by different ASes is dangerous and we should ENFORCE only one route object per route. This can and will be done if people get really desperate. I can think of several scenarios for it. So we better have a possibility to register it. > Who controls? The first AS regists win. Difficult at best. > Of course, they > have to cordinate when the second AS regist the same > route object. If they want to update that object, they > have to coordinate and they need to coordinate with each > other if the make the proxy aggr for the a particular AS. I agree. But we can give them a tool to warn about inconsistencies. Same goal, less hassle. Clear divison of responsibility for registration. Daniel -------- Logged at Thu Apr 28 22:35:16 MET DST 1994 --------- From Daniel.Karrenberg at ripe.net Thu Apr 28 22:35:05 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 28 Apr 1994 22:35:05 +0200 Subject: as-out metrics In-Reply-To: Your message of Thu, 28 Apr 1994 16:11:49 EDT. <199404282011.QAA27499@merit.edu> Message-ID: <9404282035.AA19494@mellow.ripe.net> > Laurent Joncheray writes: > Ok, i try to explain... > > When you have a router and you export a route to someone else (for > instance an RS6000 :-) running gated), you have to configure the > metric BGP is going to put in its outgoing packets. With gated it will > be something like: > > bgp yes { > [...] > group type external peeras 690 > metricout 5 > version 4 > lcladdr 35.42.1.56 > { > peer 140.222.51.62 > gateway 35.42.1.56; > }; > }; > > The metric in as-out is *what you configure in your router* (here it is 5) > So: > - You have TOTAL control of it. > - It is optional, so if you don't care (if you use the router's default val > ue) > then DON'T USE IT. > - Some philosophers will talk about this metric as a preference or an advis > e > for the neighbourg ASes. I don't care. My job is to generate config files > for routers (included gated) so if people want to have 'metricout 31416' in > their dam config file they need to specify it somewhere. And somewhere is > in as-out. Explanation understood. What does the peer do with this number? Is its use defined by the protocol? My first impulse is to register this as bgp-metric: ... since it is protocol specific and needs a specific value configured rhather than a relative cost. Is this acceptable? Daniel -------- Logged at Thu Apr 28 22:46:16 MET DST 1994 --------- From Daniel.Karrenberg at ripe.net Thu Apr 28 22:46:04 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 28 Apr 1994 22:46:04 +0200 Subject: /etc/passwd/ASXX entries In-Reply-To: Your message of Thu, 28 Apr 1994 15:46:58 EDT. <199404281946.PAA24481@merit.edu> Message-ID: <9404282046.AA19560@mellow.ripe.net> I don't think much wil break if you lowercase the accounts. Some scripts will need hacking but nothing not really obvious. I'd just get the local mail delivery fixed if you do not need to distinguis case in mailbox names . If you are running sendmail it is a mailer flag. Nothing to do with /bin/mail per se. Daniel -------- Logged at Thu Apr 28 22:48:03 MET DST 1994 --------- From Daniel.Karrenberg at ripe.net Thu Apr 28 22:48:01 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 28 Apr 1994 22:48:01 +0200 Subject: draft v2 Message-ID: <9404282048.AA19574@mellow.ripe.net> It really is bedtime now. I'll try to get something out tomorrow. But I am also the Hostmaster tomorrow, so nothing much may get done. Sorry Daniel -------- Logged at Thu Apr 28 22:52:15 MET DST 1994 --------- From lpj at merit.edu Thu Apr 28 22:52:11 1994 From: lpj at merit.edu (Laurent Joncheray) Date: Thu, 28 Apr 94 16:52:11 EDT Subject: as-out metrics In-Reply-To: <9404282035.AA19494@mellow.ripe.net>; from "Daniel Karrenberg" at Apr 28, 94 10:35 pm Message-ID: <199404282052.QAA02743@merit.edu> > Explanation understood. > What does the peer do with this number? It should use it to compute the best route. But most of the routers ignore it (or, should i say, sysadmins prefer to have static preferences!) > Is its use defined by the protocol? > My first impulse is to register this as > bgp-metric: ... > since it is protocol specific and needs a specific value configured > rhather than a relative cost. > Is this acceptable? Why changing everything? ALC handle this metric correctly, i don't see any need to create another attribute. lpj -- Laurent Joncheray, E-Mail: lpj at merit.edu Merit Network Inc, 1071 Beal Avenue, Phone: +1 (313) 936 2065 Ann Arbor, MI 48109, USA Fax: +1 (313) 747 3745 "This is the end, Beautiful friend. This is the end, My only friend, the end" JM -------- Logged at Thu Apr 28 23:01:25 MET DST 1994 --------- From Daniel.Karrenberg at ripe.net Thu Apr 28 23:01:12 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 28 Apr 1994 23:01:12 +0200 Subject: as-out metrics In-Reply-To: Your message of Thu, 28 Apr 1994 16:52:11 EDT. <199404282052.QAA02743@merit.edu> Message-ID: <9404282101.AA19611@mellow.ripe.net> > Laurent Joncheray writes: > > Explanation understood. > > What does the peer do with this number? > > It should use it to compute the best route. But most of the routers > ignore it (or, should i say, sysadmins prefer to have static preferences!) > > > Is its use defined by the protocol? > > My first impulse is to register this as > > bgp-metric: ... > > since it is protocol specific and needs a specific value configured > > rhather than a relative cost. > > Is this acceptable? > > Why changing everything? ALC handle this metric > correctly, i don't see any need to create another attribute. Why? For clarity! The cost in as-in is relative. The absolute numbers do not have any meaning. It defines a static preference independent of protocol. The bgp-metric is something different, applicable only to BGP and its use by the peer is not predicatble. So to my mind it should go somewhere else. But I'll sleep over it. Daniel -------- Logged at Thu Apr 28 23:08:20 MET DST 1994 --------- From Daniel.Karrenberg at ripe.net Thu Apr 28 23:08:12 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 28 Apr 1994 23:08:12 +0200 Subject: rr-disc@rrdb.merit.edu In-Reply-To: Your message of Wed, 27 Apr 1994 17:54:52 EDT. <199404272154.RAA20089@merit.edu> Message-ID: <9404282108.AA19627@mellow.ripe.net> > "Dale S. Johnson" writes: > Daniel, Tony, Marten, > > I just bcc'd you on one message on rr-disc. Could I add you to that list You can add me. Just don't expect a commitment to participate. If I am busy it might get refiled or /dev/nulled without being read. daniel -------- Logged at Fri Apr 29 16:55:11 MET DST 1994 --------- From jyy at merit.edu Fri Apr 29 16:55:05 1994 From: jyy at merit.edu (Jessica Yu) Date: Fri, 29 Apr 1994 10:55:05 -0400 Subject: as-in/as-out Message-ID: <199404291455.KAA18965@merit.edu> >> Jessica Yu writes: > > >What if there are different components/hols making up the two routes. >> >> It is dangrous for two ASs make the same proxy aggregate route >> with different components. >I know. I agree. >> That is something should be avoided >Certainly. >> and perhaps outlawed. >Internet routing and The Law. Interesting thought :-). Believe it or not. We do have such 'law' or common commitment exist. E.g. One should not do proxy aggregate for an AS with talking to the AS. It is something that everyone knows that they should not do or else they will break things. Maybe you will have a better name for it :-) >> By using one route object for multiple origins, it is able to >> ENFORCE different ASs make consistent agggregate when they proxy >> for other ASs. That is a good argument for the design. >By the same token proxy aggregation by different ASes is dangerous >and we should ENFORCE only one route object per route. Noop, we should enforce to do coordinated proxy aggregation. ~~~~~~~~~~~ >This can and will be done if people get really desperate. >I can think of several scenarios for it. So we better >have a possibility to register it. >> Who controls? The first AS regists win. >Difficult at best. >> Of course, they >> have to cordinate when the second AS regist the same >> route object. If they want to update that object, they >> have to coordinate and they need to coordinate with each >> other if the make the proxy aggr for the a particular AS. >I agree. But we can give them a tool to warn about inconsistencies. >Same goal, less hassle. Clear divison of responsibility for registration. Agree. I thought about this as well and this is very necessary. This will partially address my concern on this. In order to close on this, let me ask the following questions: 1. Concept wise, is it better to have a given route described by one and only one route object than to have the route described by multiple object ? 2. Implementation wise, is it easier to have route be the unique key or route/origin as unique key? (query, etc) 3. Which way is easier for tool writing: one route object, multiple origins or multiple route object, one origin ? --Jessica Daniel ------- End of Forwarded Message -------- Logged at Fri Apr 29 17:24:44 MET DST 1994 --------- From jyy at merit.edu Fri Apr 29 17:24:37 1994 From: jyy at merit.edu (Jessica Yu) Date: Fri, 29 Apr 1994 11:24:37 -0400 Subject: as-out metrics In-Reply-To: Your message of "Thu, 28 Apr 1994 23:01:12 +0200." <9404282101.AA19611@mellow.ripe.net> Message-ID: <199404291524.LAA21917@merit.edu> Daniel, Viewing the previous exchange, it looks like you agree that the routes export metric is useful information and it needs to be somewhere. The difference is where it should be put, in as-out or put it in a new attributes. It seems that metric out fits naturally in as-out for the following reason: as-in describes how an AS import routes including what routes to import and what preference it accept them. as-out describes how an AS export routes including what routes to export and what metric it announce them. Both perference in as-in and metric in as-out are enforcable by the AS. So it actually make as-out more symtric to as-in by adding export metric. And it also fits the definition of as-out. Create a new attribute of bgp_metric like you suggested has someside that is: ASs have to repeat what described in as-out in order just to put metric with the different set of routes it advertised. It is really redundant to as-out. --Jessica -------- Logged at Fri Apr 29 18:35:59 MET DST 1994 --------- From Daniel.Karrenberg at ripe.net Fri Apr 29 18:35:53 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 29 Apr 1994 18:35:53 +0200 Subject: as-in/as-out In-Reply-To: Your message of Fri, 29 Apr 1994 10:55:05 EDT. <199404291455.KAA18965@merit.edu> Message-ID: <9404291635.AA07653@reif.ripe.net> > Jessica Yu writes: > > In order to close on this, let me ask the following questions: > > 1. Concept wise, is it better to have a given route described by one and on > ly one > route object than to have the route described by multiple object ? It is better to have multiple objects because the route is not a single entity if it is inserted by different ASes. The description may differ. The components may differ although this is absolutely dangerous. The responsibility and authority of maintenance of the objects can also not be handled cleanly if you mash them together. > 2. Implementation wise, is it easier to have route be the unique key or > route/origin as unique key? (query, etc) Does not matter. The database implementation already does this with persons where the unique key is person+nic-hdl. > 3. Which way is easier for tool writing: > one route object, multiple origins or > multiple route object, one origin ? I do not think it matters much. Daniel -------- Logged at Fri Apr 29 18:43:57 MET DST 1994 --------- From Daniel.Karrenberg at ripe.net Fri Apr 29 18:43:45 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 29 Apr 1994 18:43:45 +0200 Subject: as-out metrics In-Reply-To: Your message of Fri, 29 Apr 1994 11:24:37 EDT. <199404291524.LAA21917@merit.edu> Message-ID: <9404291643.AA07682@reif.ripe.net> > Jessica Yu writes: > Daniel, > > Viewing the previous exchange, it looks like you agree that the routes > export metric is useful information and it needs to be somewhere. I agree and it needs to be in the AS object as it is under the control of the announcing AS. > The > difference is where it should be put, in as-out or put it in a new > attributes. A new attribute. > It seems that metric out fits naturally in as-out for the following > reason: > > as-in describes how an AS import routes including what routes to import > and what preference it accept them. correct. > as-out describes how an AS export routes including what routes to export > and what metric it announce them. preference!=metric preference is a static preference, protocol independent. It describes routing policy in a clearly defined way. metric is protocol specific. It *may* affect routing policy in some way. > Both perference in as-in and metric in as-out are enforcable by the AS. Agreed. > So it actually make as-out more symtric to as-in by adding export > metric. And it also fits the definition of as-out. Symmetry for symmetry's sake is not necessarily a good idea. Different things should go in different places. Also what is so special about BGP metrics. What metrics are in IDRP? > Create a new attribute of bgp_metric like you suggested has someside > that is: > > ASs have to repeat what described in as-out in order just to put metric > with the different set of routes it advertised. It is really redundant > to as-out. Agreed. How widely is it really used? Is the metric maybe often defined per peer rather than per peerXAS? Daniel -------- Logged at Fri Apr 29 20:35:35 MET DST 1994 --------- From jyy at merit.edu Fri Apr 29 20:35:29 1994 From: jyy at merit.edu (Jessica Yu) Date: Fri, 29 Apr 1994 14:35:29 -0400 Subject: as-in/as-out Message-ID: <199404291835.OAA08360@merit.edu> Ok, if programs would be built to WARN people when they try to enter route object which has different components of any existing ones. I am cool with the way you want to go. I figured that there is no point to spend a lot of energy on this small difference while we have closed on the bigger difference i.e. to allow one route multiple origins. :-) --Jessica > Jessica Yu writes: > > In order to close on this, let me ask the following questions: > > 1. Concept wise, is it better to have a given route described by one and on > ly one > route object than to have the route described by multiple object ? It is better to have multiple objects because the route is not a single entity if it is inserted by different ASes. The description may differ. The components may differ although this is absolutely dangerous. The responsibility and authority of maintenance of the objects can also not be handled cleanly if you mash them together. > 2. Implementation wise, is it easier to have route be the unique key or > route/origin as unique key? (query, etc) Does not matter. The database implementation already does this with persons where the unique key is person+nic-hdl. > 3. Which way is easier for tool writing: > one route object, multiple origins or > multiple route object, one origin ? I do not think it matters much. Daniel ------- End of Forwarded Message -------- Logged at Fri Apr 29 20:52:57 MET DST 1994 --------- From jyy at merit.edu Fri Apr 29 20:52:51 1994 From: jyy at merit.edu (Jessica Yu) Date: Fri, 29 Apr 1994 14:52:51 -0400 Subject: as-out metrics Message-ID: <199404291852.OAA10059@merit.edu> > as-out describes how an AS export routes including what routes to export > and what metric it announce them. preference!=metric preference is a static preference, protocol independent. It describes routing policy in a clearly defined way. Understand. But what is the problem to have AS to express how they export the routes i.e. to express the exporting metrics ? metric is protocol specific. It *may* affect routing policy in some way. Because it may affect routing policy, it is useful for AS to regist it. After all, we are registing routing policy. > So it actually make as-out more symtric to as-in by adding export > metric. And it also fits the definition of as-out. Symmetry for symmetry's sake is not necessarily a good idea. But you were arguing that we break the symtricy of as-in and as-out by putting metric in? I am just indicating that it does not. Different things should go in different places. Also what is so special about BGP metrics. What metrics are in IDRP? It does not matter if it is bgp metric or other metric. What matters is the metric people use to export routes. It is not just bgp specific. > Create a new attribute of bgp_metric like you suggested has someside > that is: > > ASs have to repeat what described in as-out in order just to put metric > with the different set of routes it advertised. It is really redundant > to as-out. Agreed. How widely is it really used? Is the metric maybe often defined per peer rather than per peerXAS? AS which hear the same routes from different ASs or AS which advertise routes to different ASs or one AS at different connection points all has possiability to do so. we shoul have a scalable way for them to express that. Daniel --Jessica -------- Logged at Mon May 2 14:26:18 MET DST 1994 --------- From lpj at merit.edu Wed Apr 6 23:03:20 1994 From: lpj at merit.edu (Laurent Joncheray) Date: Wed, 6 Apr 94 17:03:20 EDT Subject: Questoin about keys and DBM files Message-ID: <199404062103.RAA26541@merit.edu> How many keys are there in the RIPE dbm file (ripe.db.pag)? (i tryed to print them and i filled up /tmp :( ) -- Laurent -------- Logged at Thu Apr 7 11:11:30 MET DST 1994 --------- From Marten.Terpstra at ripe.net Thu Apr 7 11:11:13 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Thu, 07 Apr 1994 11:11:13 +0200 Subject: Questoin about keys and DBM files In-Reply-To: Your message of Wed, 06 Apr 1994 17:03:20 EDT. <199404062103.RAA26541@merit.edu> Message-ID: <9404070911.AA13353@fs1.ripe.net> Laurent Joncheray writes * How many keys are there in the RIPE dbm file (ripe.db.pag)? * (i tryed to print them and i filled up /tmp :( ) You should probably increase your tmp, the file with all keys is only 3Mb (when produced with showdbm). The current database (8.3Mb) contains 111,097 keys with one or more file offsets in the flat file as value. The maximum number of offsets per key is 100, which is MAXHITS defined in addkey.pl. If there are more than 100 offsets for a key, all offsets are removed and replaced by offset -1, which means "too many hits". -Marten -------- Logged at Thu Apr 7 11:34:10 MET DST 1994 --------- From Tony.Bates at ripe.net Thu Apr 7 11:34:06 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Thu, 07 Apr 1994 11:34:06 +0200 Subject: announcement In-Reply-To: Your message of Wed, 06 Apr 1994 16:33:06 EDT. <9404062033.AA04887@pepper.merit.edu> Message-ID: <9404070934.AA08465@fs1.ripe.net> epg at merit.edu writes: * Hi Daniel, * Are you feeling better? We really missed you at the IETF and IEPG * meetings. But it was probably nice to stay home. * Elise as Geert Jan has mentioned. Unfortunately, Daniel is still away ill at the moment and not due back until next week. However, I do have a couple of questions while we're at it. * Have you had a chance to review the announcement about * the Merit Routing Registry? We would really like to make * a joint announcement with RIPE and by the end of this * week if possible. Bill Manning has been a cooperative * guinea pig... Whilst Bill may have been a good guinea pig it appears there is some misunderstanding of how this works. Here is his registered policy. [mature-tony-63] whois -h rrdb.merit.edu AS114 aut-num: AS114 descr: Priamry SESQUIENT as as-in: AS114 1 ANY as-out: AS690 ANY mas-in: from AS114:1 accept AS690 mas-out: to AS114:1 announce AS690 guardian: bmanning at rice.edu admin-c: Bill Manning tech-c: Bill Manning remarks: Is this thing on? changed: bmanning at rice.edu 940328 source: MERITRR The as-in and mas-in and mas-out make no sense at all so I'm a little worried about the clarity of the documentation. I expect it is just Bill but one problem is people are possibly likely to use this as an example for their own policies. What it should be (and I'm guessing but anyway..) is aut-num: AS114 descr: Priamry SESQUIENT as as-in: AS690 1 AS690 # You make this ANY as-out: AS690 AS114 # " mas-in: from AS690:1 accept AS690 mas-out: to AS690:1 announce AS114 It also highlighted a bug (one of many actaully ;-() in prcheck as this didn't notice this so I just fixed this in the latest verison of prcheck. I see the same problem exists in AS690 as well. I enclose the fixed prcheck output at the end. * and Laurent has completed a rewrite of prtraceroute * and the corresponding policy server which can * reference each of our files in their native form. So we * are ready to announce. Please let us know where you all stand * on this. Thanks. Is it possible we can look at these two new pieces of code ?. Of course this doesn't effect the annoucement but we are very intereted in the YAP server. * --Elise --Tony. [mature-tony-1] ./prcheck -h rrdb.merit.edu -l 6 AS114 still getting information for AS114... --- level 1 Syntax check of policy components level 1 complete - continuing... --- level 2 Semantic check of policy expressions *ERROR* in line: as-in: AS114 1 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS level 2 complete - continuing... --- level 3 Peer comparison - Getting peer info wait.. checking against peer AS690 level 3 complete - continuing... --- level 4 Syntax check of peer policy components checking peer AS690 level 4 complete - continuing... --- level 5 Semantic check of peer policy expressions checking peer AS690 *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS *ERROR* in line: as-out: AS690 ANY *REASON*: Peering is Internal ? Remote Peer equals Local AS level 5 complete - continuing... --- level 6 Policy expression comparison checking peer AS690 level 6 complete - exiting === Summary of prcheck for AS114 policy-object Testing completed to level: 6 Error(s) encountered: 71 Warning(s) encountered: 0 No of whois queries: 2 Test 1: passed Test 2: FAILED Test 3: passed Test 4: passed Test 5: FAILED Test 6: passed -------- Logged at Thu Apr 7 18:34:16 MET DST 1994 --------- From lpj at merit.edu Thu Apr 7 18:34:02 1994 From: lpj at merit.edu (Laurent Joncheray) Date: Thu, 7 Apr 94 12:34:02 EDT Subject: Of keys and MAXHANDLE Message-ID: <199404071634.MAA15169@merit.edu> Nice questions for you folks at RIPE: What hapen if i register this person?: person: as1755 manager And what happen if i register those MAXHITS persons?: person: as1755 primary manager person: as1755 secondary manager person: as1755 cool manager person: as1755 another manager person: as1755 wife manager etc.... Will Peter be happy? -- Laurent -------- Logged at Thu Apr 7 18:40:34 MET DST 1994 --------- From Marten.Terpstra at ripe.net Thu Apr 7 18:40:11 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Thu, 07 Apr 1994 18:40:11 +0200 Subject: Of keys and MAXHANDLE In-Reply-To: Your message of Thu, 07 Apr 1994 12:34:02 EDT. <199404071634.MAA15169@merit.edu> Message-ID: <9404071640.AA14178@fs1.ripe.net> Laurent Joncheray writes * Nice questions for you folks at RIPE: * What hapen if i register this person?: * person: as1755 manager * * And what happen if i register those MAXHITS persons?: * person: as1755 primary manager * person: as1755 secondary manager * person: as1755 cool manager * person: as1755 another manager * person: as1755 wife manager * etc.... * * Will Peter be happy? Don't know about Peter (he does not work for EBONE any more) but someone won't be. The database will never be any good if people really want to screw things up. I can think of a hundred ways to make the database totally useless. The point is that we have to make the assumption that people send in sensible data. The moment someone sends this in, we remove them, and give the person who send it in a VERY hard time. If maxhits would be too low, we simply increase it. -Marten PS What;s up with your stuff, we would like to have a look/play with it. -------- Logged at Thu Apr 7 18:48:00 MET DST 1994 --------- From lpj at merit.edu Thu Apr 7 18:47:52 1994 From: lpj at merit.edu (Laurent Joncheray) Date: Thu, 7 Apr 94 12:47:52 EDT Subject: Of keys and MAXHANDLE In-Reply-To: <9404071640.AA14178@fs1.ripe.net>; from "Marten Terpstra" at Apr 7, 94 6:40 pm Message-ID: <199404071647.MAA16281@merit.edu> Ok dudes, i didn't mean to be nasty :-) The only thing i like you to change to your software is: Generate a key which reflects the type of the referenced object. For instance if you make a key for an AS, you can generate the key: "*an:AS1755" instead of just "as1755". Same thing for the person: "*pn:AS1755" instead of just "as1755". So nasty people like me won't screw up other nicw people's data. -- lpj PS: seems a easy patch? and that can help me *a lot* > > > Laurent Joncheray writes > * Nice questions for you folks at RIPE: > * What hapen if i register this person?: > * person: as1755 manager > * > * And what happen if i register those MAXHITS persons?: > * person: as1755 primary manager > * person: as1755 secondary manager > * person: as1755 cool manager > * person: as1755 another manager > * person: as1755 wife manager > * etc.... > * > * Will Peter be happy? > > Don't know about Peter (he does not work for EBONE any more) but > someone won't be. The database will never be any good if people really > want to screw things up. I can think of a hundred ways to make the > database totally useless. The point is that we have to make the > assumption that people send in sensible data. The moment someone sends > this in, we remove them, and give the person who send it in a VERY > hard time. > > If maxhits would be too low, we simply increase it. > > -Marten > > PS What;s up with your stuff, we would like to have a look/play with it. > -- Laurent Joncheray, E-Mail: lpj at merit.edu Merit Network Inc, 1071 Beal Avenue, Phone: +1 (313) 936 2065 Ann Arbor, MI 48109, USA Fax: +1 (313) 747 3745 "This is the end, Beautiful friend. This is the end, My only friend, the end" JM -------- Logged at Thu Apr 7 20:23:41 MET DST 1994 --------- From Marten.Terpstra at ripe.net Thu Apr 7 20:23:20 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Thu, 07 Apr 1994 20:23:20 +0200 Subject: Of keys and MAXHANDLE In-Reply-To: Your message of Thu, 07 Apr 1994 12:47:52 EDT. <199404071647.MAA16281@merit.edu> Message-ID: <9404071823.AA08018@mellow.ripe.net> Laurent Joncheray writes * Ok dudes, i didn't mean to be nasty :-) The only thing i like * you to change to your software is: * Generate a key which reflects the type of the referenced object. For * instance if you make a key for an AS, you can generate the key: * "*an:AS1755" instead of just "as1755". Same thing for the person: * "*pn:AS1755" instead of just "as1755". So nasty people like me won't * screw up other nicw people's data. * -- lpj OK, let me try and explain the key generation in a bit more detail. For each object a set of keys is generated (eg firstname and lastname for persons) PLUS a unique key, which is only used when adding/deleting objects, never for normal lookups. The unique key for an object is defined in the config, with the addition of something special which makes it different from another object that might have the same unique key. The special bit added is the sort key (also defined in the config) with a % sign added. So, for instance for an AS the unique key would for instance be %0as1755, and a person with name AS1755 would have unique key %3as1755. The idea is basically the same. There is only one unique key per object. The reason why it is never used in queries is that from a query you (usually) cannot determine what kind of object you are looking for (person as1755 or autonomous system as1755) so that is where the normal keys are used (as1755 as key would point to both the person and the autonomous system object). When updating an object, you know the object type, so you can use the unique key to uniquely locate the object. You can see all the keys by doing a showdbm on one of the databases. We know this increases the numberof keys quite significantly, but it helps making things easier. The routines that generate the keys in the RIPE s/w are enukey.pl for the unique key, and enkeys.pl for all other keys. Is this what you are looking for? If not, could you explain why you would like to see what you propose? The change is indeed quite simple, although there might be some timing issues, but it could be done. -Marten -------- Logged at Thu Apr 7 20:48:50 MET DST 1994 --------- From lpj at merit.edu Thu Apr 7 20:48:39 1994 From: lpj at merit.edu (Laurent Joncheray) Date: Thu, 7 Apr 94 14:48:39 EDT Subject: Of keys and MAXHANDLE In-Reply-To: <9404071823.AA08018@mellow.ripe.net>; from "Marten Terpstra" at Apr 7, 94 8:23 pm Message-ID: <199404071848.OAA27382@merit.edu> Cool, that what i was looking for. If i undestand the unique key is in the format: %X where X = 0 for an AS, X = 3 for a person, etc... Except there is no relation between the number and the attribute name (*in, *an, ect...) which adds another level of pain. As for the 'normal keys' (the one without the %X), why not getting rid of then? When you look up a query, you look at the key the user provide, and you try to gess the type. For instance if the key is 35.0.0.0 i do not think the user if looking for a person name. Same thing with AS1755. And if the lookup fails you can always try another type. Laurent PS: the new prtraceroute is on merit.edu:~ftp/pub/meritrr/prtraceroute.tar.Z (anonymous FTP). The code for the ALC server (a new name for YAP :-) is not yet publicly available. Maybe next week. But if your insterested in the protocol yuo can look at the code of prtraceroute. (and no ALC server is currently running, so you won't be able to try it) > OK, let me try and explain the key generation in a bit more detail. > For each object a set of keys is generated (eg firstname and lastname > for persons) PLUS a unique key, which is only used when > adding/deleting objects, never for normal lookups. The unique key for > an object is defined in the config, with the addition of something > special which makes it different from another object that might have > the same unique key. The special bit added is the sort key (also > defined in the config) with a % sign added. So, for instance for an AS > the unique key would for instance be %0as1755, and a person with name > AS1755 would have unique key %3as1755. The idea is basically the same. > There is only one unique key per object. The reason why it is never > used in queries is that from a query you (usually) cannot determine > what kind of object you are looking for (person as1755 or autonomous > system as1755) so that is where the normal keys are used (as1755 as > key would point to both the person and the autonomous system object). > > When updating an object, you know the object type, so you can use the > unique key to uniquely locate the object. You can see all the keys by > doing a showdbm on one of the databases. We know this increases the > numberof keys quite significantly, but it helps making things easier. > The routines that generate the keys in the RIPE s/w are enukey.pl for > the unique key, and enkeys.pl for all other keys. > > Is this what you are looking for? If not, could you explain why you > would like to see what you propose? The change is indeed quite simple, > although there might be some timing issues, but it could be done. > > -Marten > -- Laurent Joncheray, E-Mail: lpj at merit.edu Merit Network Inc, 1071 Beal Avenue, Phone: +1 (313) 936 2065 Ann Arbor, MI 48109, USA Fax: +1 (313) 747 3745 "This is the end, Beautiful friend. This is the end, My only friend, the end" JM -------- Logged at Thu Apr 7 21:39:25 MET DST 1994 --------- From Marten.Terpstra at ripe.net Thu Apr 7 21:39:10 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Thu, 07 Apr 1994 21:39:10 +0200 Subject: Of keys and MAXHANDLE In-Reply-To: Your message of Thu, 07 Apr 1994 14:48:39 EDT. <199404071848.OAA27382@merit.edu> Message-ID: <9404071939.AA08060@mellow.ripe.net> Laurent Joncheray writes * Cool, that what i was looking for. If i undestand the * unique key is in the format: %X where X = 0 for an AS, * X = 3 for a person, etc... Except there is no relation between * the number and the attribute name (*in, *an, ect...) which adds another * level of pain. * As for the 'normal keys' (the one without the %X), why not getting * rid of then? When you look up a query, you look at the key the user * provide, and you try to gess the type. For instance if the key * is 35.0.0.0 i do not think the user if looking for a person name. * Same thing with AS1755. And if the lookup fails you can always try another * type. True and not true. For some of the objects the unique key corresponds to one of the normal keys. For as'es for instance. However, you would like to be able to get answers for queries that do not specify a complete key, like for instance a person's last name, a person's nic handle, a network name etc. The unique key is usually a combination of various fields of an object, and I think you would like to still find a match if only parts of that unique keys are given. In some cases, like AS numbers, and domain names for instance the unique key and normal key are always the same (except for the %X) but these are exceptions rather than rules ... We are thinking however to change the indexing for classless support, but still want to keep the same behaviour for non-IP numbers. If you have ideas, let me know. -Marten -------- Logged at Fri Apr 15 01:20:45 MET DST 1994 --------- From lpj at merit.edu Fri Apr 15 01:20:41 1994 From: lpj at merit.edu (Laurent Joncheray) Date: Thu, 14 Apr 94 19:20:41 EDT Subject: prtraceroute.pl and ALC Message-ID: <199404142320.TAA02702@merit.edu> The policy server is now running (i hope :-) on rrdb.merit.edu You can try prtraceroute.pl (ftp rrdb.merit.edu:pub/meritrr/prtraceroute.tar.Z) -- Laurent -------- Logged at Thu Apr 21 23:21:10 MET DST 1994 --------- From dsj at merit.edu Thu Apr 21 23:21:06 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Thu, 21 Apr 1994 17:21:06 -0400 Subject: When to ftp the split ripe.db? Message-ID: <199404212121.RAA15454@merit.edu> Tony, Marten, When did you say your cron jobs produce the ripe.db for FTP? We're actually picking up the split versions, if that makes any difference. Is it 07:00 Universal time? European Time? -rw-r--r-- 1 ncc 2063 Apr 21 14:28 .cache+ -rw-r--r-- 1 ncc 860 Apr 21 07:00 ripe.db.as-macro.Z -rw-r--r-- 1 ncc 40610 Apr 21 07:02 ripe.db.aut-num.Z -rw-r--r-- 1 ncc 1535 Apr 21 07:03 ripe.db.bdry-gw.Z -rw-r--r-- 1 ncc 759 Apr 21 07:03 ripe.db.community.Z -rw-r--r-- 1 ncc 1836 Apr 21 07:01 ripe.db.dom-prefix.Z -rw-r--r-- 1 ncc 321503 Apr 21 07:02 ripe.db.domain.Z -rw-r--r-- 1 ncc 1271577 Apr 21 07:04 ripe.db.inetnum.Z -rw-r--r-- 1 ncc 1413020 Apr 21 07:01 ripe.db.person.Z -rw-r--r-- 1 ncc 743 Apr 21 07:03 ripe.db.rout-pr.Z 226 Transfer complete. (I know you told me at IETF but I forgot...) --Dale -------- Logged at Thu Apr 21 23:44:43 MET DST 1994 --------- From Marten.Terpstra at ripe.net Thu Apr 21 23:44:37 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Thu, 21 Apr 1994 23:44:37 +0200 Subject: When to ftp the split ripe.db? In-Reply-To: Your message of Thu, 21 Apr 1994 17:21:06 EDT. <199404212121.RAA15454@merit.edu> Message-ID: <9404212144.AA05123@fs1.ripe.net> "Dale S. Johnson" writes * Tony, Marten, * * When did you say your cron jobs produce the ripe.db for FTP? We're * actually picking up the split versions, if that makes any difference. * Is it 07:00 Universal time? European Time? Ah yes, they are made after an update (which we run at 4am) and the 7 am is CET which is 1am Eastern. If you pick things up after 3am your time, you will be well safe for all things. Cheers from Paris, -Marten -------- Logged at Mon Apr 25 22:02:09 MET DST 1994 --------- From lpj at merit.edu Mon Apr 25 22:02:05 1994 From: lpj at merit.edu (Laurent Joncheray) Date: Mon, 25 Apr 94 16:02:05 EDT Subject: ALC on anonynous FTP (rrdb) Message-ID: <199404252002.QAA15653@merit.edu> alcd (The Routing Policy Server) is available by anonymous FTP on rrdb.merit.edu:pub/meritrr/alc.tar.Z. I've also compiled it on mature.ripe.net:src/alc. (the flex version is too old, so you need to use the provided rpdll.c file) -- Laurent -------- Logged at Tue Apr 26 00:06:33 MET DST 1994 --------- From Tony.Bates at ripe.net Tue Apr 26 00:05:08 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Tue, 26 Apr 1994 00:05:08 +0200 Subject: ALC on anonynous FTP (rrdb) In-Reply-To: Your message of Mon, 25 Apr 1994 16:02:05 EDT. <199404252002.QAA15653@merit.edu> Message-ID: <9404252205.AA21560@mature.ripe.net> Laurent Joncheray writes: * alcd (The Routing Policy Server) is available by anonymous * FTP on rrdb.merit.edu:pub/meritrr/alc.tar.Z. I've also compiled * it on mature.ripe.net:src/alc. (the flex version is too old, so you Thanks. * need to use the provided rpdll.c file) Question on flex. We are running 2.4.6 which is the latest released version I thought. Are you running a later version. * -- * Laurent Tony. -------- Logged at Tue Apr 26 17:57:41 MET DST 1994 --------- From epg at merit.edu Tue Apr 26 17:57:29 1994 From: epg at merit.edu (Elise Gerich) Date: Tue, 26 Apr 1994 11:57:29 -0400 Subject: as-in/as-out Message-ID: <199404261557.LAA07701@merit.edu> Daniel, Tony, and Marten, After our phone call last week, we (Merit) went round and round about as-in/as-out and kept coming up with the same pros and cons for having a new object or modifying the current object. What I'd like to do is present our extended syntax for as-in/as-out to the ripe-routing-wg via email prior to the RIPE meeting in May. The main reason for approaching the working group is to try to foster consistency as a community - not as the NCC or Merit. We are at greater risk of diverging further if we make a new attribute, and then you modify as-in/as-out so that it is inconsistent with the new attribute. If we work with the woking group, perhaps we can get an agreed upon extension for as-in/as-out that we both can live with. --Elise -------- Logged at Wed Apr 27 10:04:11 MET DST 1994 --------- From Daniel.Karrenberg at ripe.net Wed Apr 27 10:04:00 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 27 Apr 1994 10:04:00 +0200 Subject: as-in/as-out In-Reply-To: Your message of Tue, 26 Apr 1994 11:57:29 EDT. <199404261557.LAA07701@merit.edu> Message-ID: <9404270804.AA00631@reif.ripe.net> > Elise Gerich writes: > Daniel, Tony, and Marten, > After our phone call last week, we (Merit) went round and round > about as-in/as-out and kept coming up with the same > pros and cons for having a new object or modifying the > current object. > > What I'd like to do is present our extended syntax for > as-in/as-out to the ripe-routing-wg via email prior > to the RIPE meeting in May. That is quite OK. RIPE is an open forum. > The main reason for approaching the working group is to try > to foster consistency as a community - not as the NCC or Merit. > We are at greater risk of diverging further if we make a new > attribute, and then you modify as-in/as-out so that it is inconsistent > with the new attribute. If we work with the woking group, perhaps > we can get an agreed upon extension for as-in/as-out that we > both can live with. I think we should make another try to come up with a joint proposal. Otherwise we run the risk of having no consensus at the end of the process or -even worse- a random consensus. Tony and I have provided an extensive motivated critique of your last proposal and have never heared back. Maybe we can start off there? We will also have to add classless/aggregation support in this go. Daniel -------- Logged at Wed Apr 27 13:39:26 MET DST 1994 --------- From Tony.Bates at ripe.net Wed Apr 27 13:39:24 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Wed, 27 Apr 1994 13:39:24 +0200 Subject: astrace / prtraceroute things Message-ID: <9404271139.AA03923@mature.ripe.net> This is a two fold message due to some overlap; first about astrace. I have done some testing of astrace and found a few problems with it. 1) It or I guess alc doesn't use the ias-int attribute. This makes most of the policies wrong at the borders. 2) The "-g" support works on the destination and not first on the gateway and then the destination. So its policy decisions are based on the wrong destination for half of the trace. See below for "-g" support in prtraceroute. 3) Also, for the legend you seem to use the non-RIPE descriptions for AS names. I guess ALC stores the first one it sees and you are using NIC based data over RIPE for preference. Plus, from a "personal point of view only" the policy messages returned seem a little hard to read and currently due to the missing ias-int support are often wrong. However, as noted these are now different tools so no problems. Secondly, I have made a few changes to prtraceroute this week and wanted you to get a chance to look at the pre-release version before the next pride tools sub release. The main ones are as follows. 1) support of traceroutes "-g" option. 2) support of environment variables for alternate host and port. ala Dales suggestion. 3) support in the make for Solaris 2.* support. Solaris has a new value for SOCK_STREAM ;-(. 4) Changes to Makefile for building of the manual. 5) Chages to the manual. The major one though is the "-g". Just to show this in action. [mature-tony-123] prtraceroute -l -v -g Amsterdam1.router.surfnet.nl ns0.ja.net traceroute with AS and policy additions [Apr 27 10:02:15 UTC] from AS2122 mature.ripe.net (192.87.45.6) via AS1103 Amsterdam1.router.surfnet.nl (145.41.1.193) to AS 786 ns0.ja.net (193.63.94.20) 1 AS1104 hef-router.nikhef.nl 192.87.45.80 [D2] 19 3 2 ms 2 AS1103 Amsterdam1.router.surfnet.nl 192.87.4.18 [E1] 9 4 4 ms 3 AS1103 Amsterdam2.router.surfnet.nl 145.41.9.130 [I] 6 5 5 ms 4 AS2043 amsterdam4.empb.net 193.172.4.17 [E1] 15 11 14 ms 5 AS2043 london4.empb.net 193.172.4.34 [I] 29 35 27 ms 6 AS 786 janet-ex.london4.empb.net 193.172.27.22 [E1] 35 37 39 ms 7 AS 786 ns0.ja.net 193.63.94.20 [I] 32 90 35 ms AS Path followed: 2122 1104 1103 2043 786 AS2122 = RS Test AS at NCC (TB's box of tricks) AS1104 = NIKHEF-H AS1103 = SURFnet IP AS2043 = European Multiprotocol Backbone AS 786 = The JANET IP Service Also, notice the inconsistencies highligthed above in "astrace". [mature-tony-129] astrace -l -v -g Amsterdam1.router.surfnet.nl ns0.ja.net Connected to ALC server traceroute with AS and policy additions [Apr 27 10:07:55 UTC] from AS3333 mature.ripe.net (192.87.45.6) to AS 786 ns0.ja.net (128.86.1.20) 1 AS3333 hef-router.nikhef.nl 192.87.45.80 [INT 0 0] 5 2 2 ms 2 AS1755 Amsterdam1.router.surfnet.nl 192.87.4.18 [!RO -1 !RO -1] 60 5 5 ms 3 AS1103 Amsterdam2.router.surfnet.nl 145.41.9.130 [!RO -1 !RO -1] 71 99 17 ms 4 AS2043 amsterdam4.empb.net 193.172.4.17 [!RO -1 EXP 0] 14 10 10 ms 5 AS2043 london4.empb.net 193.172.4.34 [INT 0 0] 35 29 32 ms 6 AS2043 janet-ex.london4.empb.net 193.172.27.22 [INT 0 0] 47 36 40 ms 7 AS 786 ns0.ja.net 128.86.1.20 [!RO -1 !RO -1] 43 36 49 ms AS Path followed: 3333 1755 1103 2043 786 AS3333 = RIPE-ASNBLOCK4 AS1755 = EBONE-INTERNAL AS1103 = SURFNET-AS AS2043 = EMPB-AS AS 786 = ULCC-CISCO-AS If you are intereted in a early look at prtraceroute it is on ftp.ripe.net:pride/tools/prtraceroute.new.shar Regards, --Tony. -------- Logged at Wed Apr 27 13:46:16 MET DST 1994 --------- From Marten.Terpstra at ripe.net Wed Apr 27 13:46:14 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Wed, 27 Apr 1994 13:46:14 +0200 Subject: alc tests Message-ID: <9404271146.AA11950@fs1.ripe.net> Folks, Today and tomorrow (I'm off on Friday) I will be playing with alc. We have got a server running on whois.ripe.net, port 7667, with currently only the RIPE database loaded. Although I have seen it dump core a few times, I think most of these were actually caused by wrong modifications to the config file by me. Some early feedback and things to think about [these are mainly operational things]: - the RIPE database supports immediate updates in the whois server. People that send in ASs or networks want to test whether they have done things right almost instantly. Restarting alc every minute or so is currently the only answer, but with 40 seconds to read the RIPE database, this does not look very attractive to me. We may need to think of a way to have alc show a similar behaviour as updating the database (ie almost instantly) - When a DB file is read as a flat file, the alc process is enormously big, almost 15 Mb with only the RIPE database read. This could give some severe performance problems for other services running on the same machine. The answer is simple I know, get another box, but we don't have another box. Reading a DBM index in stead of a flat file reduces the size of alc to around 7 Mb. - aggwalk is works against the test alc server we have running - aggwalk -A only shows real attributes as defined in the config, no aliases. So in the RIPE alc server you cannot ask for aut-sys but have to ask for homeas ... That's all for now, I'll get back with more later. -Marten -------- Logged at Wed Apr 27 14:54:34 MET DST 1994 --------- From epg at merit.edu Wed Apr 27 14:54:27 1994 From: epg at merit.edu (epg at merit.edu) Date: Wed, 27 Apr 94 8:54:27 EDT Subject: alc tests In-Reply-To: <9404271146.AA11950@fs1.ripe.net>; from "Marten Terpstra" at Apr 27, 94 1:46 pm Message-ID: <9404271254.AA01354@pepper.merit.edu> Hi Marten, > > > Folks, > > Today and tomorrow (I'm off on Friday) I will be playing with alc. We > have got a server running on whois.ripe.net, port 7667, with currently > only the RIPE database loaded. Although I have seen it dump core a few > times, I think most of these were actually caused by wrong > modifications to the config file by me. Some early feedback and things > to think about [these are mainly operational things]: > > - the RIPE database supports immediate updates in the whois server. > People that send in ASs or networks want to test whether they have > done things right almost instantly. Restarting alc every minute or so > is currently the only answer, but with 40 seconds to read the RIPE > database, this does not look very attractive to me. We may need to > think of a way to have alc show a similar behaviour as updating the > database (ie almost instantly) We've been thinking about this also. In fact it was one of the problems we had even with the "translator" prior to alc. > > - When a DB file is read as a flat file, the alc process is enormously > big, almost 15 Mb with only the RIPE database read. This could give > some severe performance problems for other services running on the > same machine. The answer is simple I know, get another box, but we > don't have another box. Reading a DBM index in stead of a flat file > reduces the size of alc to around 7 Mb. > > - aggwalk is works against the test alc server we have running > > - aggwalk -A only shows real attributes as defined in the > config, no aliases. So in the RIPE alc server you cannot ask for > aut-sys but have to ask for homeas ... > > That's all for now, I'll get back with more later. > > -Marten Thanks for the feedback and have a good day off. --Elise -------- Logged at Wed Apr 27 15:09:03 MET DST 1994 --------- From epg at merit.edu Wed Apr 27 15:08:56 1994 From: epg at merit.edu (epg at merit.edu) Date: Wed, 27 Apr 94 9:08:56 EDT Subject: as-in/as-out In-Reply-To: <9404270804.AA00631@reif.ripe.net>; from "Daniel Karrenberg" at Apr 27, 94 10:04 am Message-ID: <9404271308.AA01368@pepper.merit.edu> Daniel, Daniel Karrenberg writes: > epg at merit.edu writes: > > Daniel, Tony, and Marten, > > After our phone call last week, we (Merit) went round and round > > about as-in/as-out and kept coming up with the same > > pros and cons for having a new object or modifying the > > current object. > > > > What I'd like to do is present our extended syntax for > > as-in/as-out to the ripe-routing-wg via email prior > > to the RIPE meeting in May. > > That is quite OK. RIPE is an open forum. > > > The main reason for approaching the working group is to try > > to foster consistency as a community - not as the NCC or Merit. > > We are at greater risk of diverging further if we make a new > > attribute, and then you modify as-in/as-out so that it is inconsistent > > with the new attribute. If we work with the woking group, perhaps > > we can get an agreed upon extension for as-in/as-out that we > > both can live with. > > I think we should make another try to come up with a joint proposal. > Otherwise we run the risk of having no consensus at the end of the > process or -even worse- a random consensus. > Yes, let's make another go at it. > Tony and I have provided an extensive motivated critique of your > last proposal and have never heared back. Maybe we can start off there? > Let me search my mail - I remember a note from Tony (while you were ill) but don't recollect anything else. > We will also have to add classless/aggregation support in this go. > We had been using the inetnum object to represent classless/aggregates; but that may be a problem for you all since you also need it for network assignment/allocation. Have you thought about using inetnum for the classless/aggregate object or were you leaning toward creating a new object? --Elise -------- Logged at Wed Apr 27 15:21:08 MET DST 1994 --------- From lpj at merit.edu Wed Apr 27 15:21:04 1994 From: lpj at merit.edu (Laurent Joncheray) Date: Wed, 27 Apr 94 9:21:04 EDT Subject: alc tests In-Reply-To: <9404271146.AA11950@fs1.ripe.net>; from "Marten Terpstra" at Apr 27, 94 1:46 pm Message-ID: <199404271321.JAA01598@merit.edu> Cool, i like comments... Here the answers (most of then a known problem) > - the RIPE database supports immediate updates in the whois server. > People that send in ASs or networks want to test whether they have > done things right almost instantly. Restarting alc every minute or so > is currently the only answer, but with 40 seconds to read the RIPE > database, this does not look very attractive to me. We may need to > think of a way to have alc show a similar behaviour as updating the > database (ie almost instantly) There is no (current) way to reread a DB_FLAT file. As for a DB_DBM file, since alc stores only the key the ALC protocol allows a client (in our case dbupdate) to announce a new key. In other word dbupdate can tell dynamicly alc when a new key is created, and no reread is necessary. This feature is not yet used (but works!) since i have to hack dbupdate. > - When a DB file is read as a flat file, the alc process is enormously > big, almost 15 Mb with only the RIPE database read. This could give > some severe performance problems for other services running on the > same machine. The answer is simple I know, get another box, but we > don't have another box. Reading a DBM index in stead of a flat file > reduces the size of alc to around 7 Mb. For DB_FLAT file alc store everything in memory. DB_FLAT is an old format. For a DB_DBM file alc on rrdb.merit.edu use 11 Mb for 400000 net from RIPE and 28000 from PRDB. (the 'real' memory space used is something like 5 Mb but malloc(3) is a little unefficient :-) (Try the -m option) > - aggwalk -A only shows real attributes as defined in the > config, no aliases. So in the RIPE alc server you cannot ask for > aut-sys but have to ask for homeas ... We can agree on a name... Homeas is historical. Laurent PS: Could you tell me when you get core dump? It should be fixed. -- Laurent Joncheray, E-Mail: lpj at merit.edu Merit Network Inc, 1071 Beal Avenue, Phone: +1 (313) 936 2065 Ann Arbor, MI 48109, USA Fax: +1 (313) 747 3745 "This is the end, Beautiful friend. This is the end, My only friend, the end" JM -------- Logged at Wed Apr 27 16:09:22 MET DST 1994 --------- From Marten.Terpstra at ripe.net Wed Apr 27 16:09:20 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Wed, 27 Apr 1994 16:09:20 +0200 Subject: alc tests In-Reply-To: Your message of Wed, 27 Apr 1994 09:21:04 EDT. <199404271321.JAA01598@merit.edu> Message-ID: <9404271409.AA12192@fs1.ripe.net> Laurent Joncheray writes * Cool, i like comments... Here the answers (most of then a known * problem) * * There is no (current) way to reread a DB_FLAT file. As for a DB_DBM * file, since alc stores only the key the ALC protocol allows a client (in our * case dbupdate) to announce a new key. In other word dbupdate can tell * dynamicly alc when a new key is created, and no reread is necessary. * This feature is not yet used (but works!) since i have to hack dbupdate. What needs to be changed in dbupdate to make this happen? How does it tell alc? If you tell me what to do, I can add this to the standard dist. * > - When a DB file is read as a flat file, the alc process is enormously * > big, almost 15 Mb with only the RIPE database read. This could give * > some severe performance problems for other services running on the * > same machine. The answer is simple I know, get another box, but we * > don't have another box. Reading a DBM index in stead of a flat file * > reduces the size of alc to around 7 Mb. * * For DB_FLAT file alc store everything in memory. DB_FLAT is an old * format. For a DB_DBM file alc on rrdb.merit.edu use 11 Mb for 400000 net * from RIPE and 28000 from PRDB. (the 'real' memory space used is something li * ke * 5 Mb but malloc(3) is a little unefficient :-) (Try the -m option) OK, I just noticed this, and we should keep an eye on it. * > - aggwalk -A only shows real attributes as defined in the * > config, no aliases. So in the RIPE alc server you cannot ask for * > aut-sys but have to ask for homeas ... * * We can agree on a name... Homeas is historical. Well, actually what I implied is that alc should recognize the aliases defined in the config and know what to do with them in for instance aggrwalk queries. * PS: Could you tell me when you get core dump? It should be fixed. I am not quite sure how I did it anymore. I fiddled with the config, commented some stuff out, and then got a segmentation fault. I'll try and reproduce. -Marten -------- Logged at Wed Apr 27 16:18:32 MET DST 1994 --------- From Marten.Terpstra at ripe.net Wed Apr 27 16:18:24 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Wed, 27 Apr 1994 16:18:24 +0200 Subject: as-in/as-out In-Reply-To: Your message of Wed, 27 Apr 1994 09:08:56 EDT. <9404271308.AA01368@pepper.merit.edu> Message-ID: <9404271418.AA12227@fs1.ripe.net> epg at merit.edu writes * network assignment/allocation. Have you thought about using inetnum * for the classless/aggregate object or were you leaning toward creating * a new object? * * --Elise Actually we are in the middle of a heated discussion on this, and we will very probably have a new object, and remove all routing information from the inetnum. We'll write up this (currently *very* heated discussion, I should not even be typing this now ;-) and send it round. -MT -------- Logged at Wed Apr 27 17:03:11 MET DST 1994 --------- From Daniel.Karrenberg at ripe.net Wed Apr 27 17:02:58 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 27 Apr 1994 17:02:58 +0200 Subject: as-in/as-out In-Reply-To: Your message of Wed, 27 Apr 1994 09:08:56 EDT. <9404271308.AA01368@pepper.merit.edu> Message-ID: <9404271502.AA00834@reif.ripe.net> > epg at merit.edu writes: > > Tony and I have provided an extensive motivated critique of your > > last proposal and have never heared back. Maybe we can start off there? > > > Let me search my mail - I remember a note from Tony (while you were > ill) but don't recollect anything else. ------- Date: Tue, 22 Mar 1994 13:53:02 +0100 From: Daniel Karrenberg Sender: dfk at reif.ripe.net To: Elise Gerich Cc: rr-impl at ripe.net Subject: Re: extensions for routing registry In-Reply-To: Your message of Thu, 10 Mar 1994 16:37:07 EST. <199403102137.QAA16455 at merit.edu> ------- To add to Tony's comments with which I agree. - I personally do not like the [to] [from] etc. syntactic sugar. Users who want a more comfortable input language, should use a local post/preprocessor which we should provide. If the routing registry itself (view it as a database) provides different representations we will get lots of confusion as to the semantics. Also all tools using the RR will have to accept multiple representations which is only adding possibilities for bugs and general entropy - The RIPE-81 as-out does *not* have a preference for a reason. I (think I) know what you want to do, BUT ... Try to define the semantics in a clear, concise and understandable way! I cannot. This will also obscure the principle of what as-in and as-out really means. This will lead to confusion even if its optionality and advisory nature is clearly marked. The only gain obtainable from it is some conistency checking implementable only if the full topology is known. Rather use as-exclude and as-transit for this as these are clearly non-local attributes. - Usage of communities must be clearly flagged with the potential problems w.r.t. implementability. The only way I see it implementable is network based lists, now that the BGP4 folks have withdrawn the path attribute from the spec. It also needs to be mentioned that using them can potentially hurt CIDR aggregation efficiency badly. - I like the as-exclude attribute (without syntactic sugar) It needs more language about that this can be implemented in two ways: - using path info by the AS registering the as-exclude - filtering implemented by the AS mentioned. The second is advisory in nature but should be encouraged. It needs language that filtering by the AS mentioned is quite OK based on the as-exclude etc. pp. This also means we need a way to provide server functionality of the type "tell me all ASes mentioning ASx (me) in as-exclude!" At them moment we can get this from the full database file but this does not scale. - as-transit can be quite usefule but needs a better definition of semantics It has similar problems as as-out preferences: You need the whole graph. But these are more acceptable here as as-transit is clearly not local. It also needs a section on how this can be implemented. And its advisory nature. - border router level this should not go in the as-out attributes but rather be a separate set of attributes line "link-out" "link-in" with a requirement to have the as-in and as-out as well. this way you get an optional level of complexity. Otherwise it looks fine. - database selector same problems as community In conclusion I personally would be very unhappy if you folks announced a registry using this stuff tomorrow. This needs some solid design sessions where semantics are clearly defined and we can discuss what is needed and what is fluff. Finally this needs some test as to wether people actually understand it (the same way). I strongly fear that adding too many features at this point in time can provide enough problems to make this whole RR idea fail. I do not want that to happen. Another *very worthwhile* idea is to make much more clear what is basic functionality and what is enhanced functionality. Please do not understand these remarks as antagonistic or de-valuing your work. Due to resource-sacrceness over here you are very much leading the way for extensions. I apreceiate that very much. My overwhelming concern is to not de-value the RR concept by making it overly complex. Daniel PS: I am missing the aggregate stuff. > > We will also have to add classless/aggregation support in this go. > We had been using the inetnum object to represent classless/aggregates; > but that may be a problem for you all since you also need it for > network assignment/allocation. Have you thought about using inetnum > for the classless/aggregate object or were you leaning toward creating > a new object? We have come to a basic design which we will put up for scrutiny by y'all in a while. Need to write it up. Daniel -------- Logged at Wed Apr 27 18:03:37 MET DST 1994 --------- From Tony.Bates at ripe.net Wed Apr 27 18:03:33 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Wed, 27 Apr 1994 18:03:33 +0200 Subject: alc tests In-Reply-To: Your message of Wed, 27 Apr 1994 09:21:04 EDT. <199404271321.JAA01598@merit.edu> Message-ID: <9404271603.AA04595@mature.ripe.net> Laurent Joncheray writes: * Cool, i like comments... Here the answers (most of then a known * problem) Just one other little one we found. Remember the possible flex problem you had on our machine. It appears the problem is the other way round. You rpdll.l will not go with the new flex version. We have an older version running on another machine and had no problem generating the C code. It seems they reset in RCS ids in the flex source at some point. Hence the confusion. Here's the the flex output from 2.4.6 (the latest version). flex -d -t -L -t rpdll.l > rpdll.c cc -g -DLEXDEBUG -DYYDEBUG -Bstatic -target sun4 -c rpdll.c "rpdll.c", line 671: rpdl_yyin undefined "rpdll.c", line 674: rpdl_yyout undefined "rpdll.c", line 681: warning: illegal combination of pointer and integer, op = "rpdll.c", line 726: rpdl_yytext undefined "rpdll.c", line 731: rpdl_yy_flex_debug undefined "rpdll.c", line 1009: rpdl_yyin undefined "rpdll.c", line 1015: rpdl_yyout undefined "rpdll.c", line 1026: rpdl_yyin undefined "rpdll.c", line 1155: rpdl_yytext undefined "rpdll.c", line 1242: rpdl_yyin undefined "rpdll.c", line 1278: rpdl_yytext undefined "rpdll.c", line 1382: rpdl_yytext undefined "rpdll.c", line 1408: rpdl_yytext undefined "rpdll.c", line 1422: rpdl_yyin undefined "rpdll.c", line 1458: redeclaration of rpdl_yyrestart "rpdll.c", line 1462: rpdl_yyin undefined "rpdll.c", line 1462: warning: illegal combination of pointer and integer, op = "rpdll.c", line 1504: redeclaration of rpdl_yy_load_buffer_state "rpdll.c", line 1506: rpdl_yytext undefined "rpdll.c", line 1507: rpdl_yyin undefined "rpdll.c", line 1516: redeclaration of rpdl_yy_create_buffer "rpdll.c", line 1539: warning: illegal combination of pointer and integer, op RETURN "rpdll.c", line 1562: redeclaration of rpdl_yy_init_buffer "rpdll.c", line 1720: rpdl_yyin undefined Hope this is of some help. --Tony. Anyway, as you know we have a working alc so it is not too bad but I guess this will cause problems for other running alc. -------- Logged at Wed Apr 27 18:51:12 MET DST 1994 --------- From Daniel.Karrenberg at ripe.net Wed Apr 27 18:50:54 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 27 Apr 1994 18:50:54 +0200 Subject: as-in/as-out In-Reply-To: Your message of Wed, 27 Apr 1994 09:08:56 EDT. <9404271308.AA01368@pepper.merit.edu> Message-ID: <9404271650.AA01465@reif.ripe.net> > epg at merit.edu writes: > We had been using the inetnum object to represent classless/aggregates; > but that may be a problem for you all since you also need it for > network assignment/allocation. Have you thought about using inetnum > for the classless/aggregate object or were you leaning toward creating > a new object? Here is our current thinking written up. It is not as long as it seems and it leaves a lot of open points. Comments are very much appreciated! Daniel Major Rework of the RIPE Routing Registry dfk mt tb Scope This is a proposal to achieve the following objectives w.r.t. the RIPE database. - Separate the allocation and routing registry functions into different objects. This will facilitate data management if the Internet registry and routing regis- try functions are separated (like in the US). It will make more clear what is part of the routing registry and who has authority to change allocation vs. routing data. - Add the possibility to specify aggregated routes in the Routing Registry. This is necessary because aggrega- tion information is necessary for network layer troub- leshooting. It is also necessary because aggregation influences routing policies directly. This proposal does not address the syntax of a classes address. It just assumes that the "/bits" syntax will be one of the alternatives. The Route Object There will be a new object describing a single route ori- ginated by and Autonomous system into the Internet routing mesh. It will have the following attributes: - 2 - route: [mandatory] [single] origin: [mandatory] [single] component: [optional] [multiple] comm-list: [optional] [single] [guarded] descr: [mandatory] [multiple] remarks: [optional] [multiple] notify: [optional] [multiple] maintainer: [optional] [single] changed: [mandatory] [multiple] source: [mandatory] [single] Example: route: 193.0.2/23 origin: AS1234 component: 193.0.2/24 AS1111 component: 193.0.3/24 AS2222 descr: XYZ campus aggregate changed: dfk at ripe.net 940427 source: RIPE The value of the route attribute will be a classless address. It represents the route being injected into the routing mesh. The value of the origin attribute will be an AS reference of the form AS1234 referring to an aut-num object. It represents the AS injecting this route into the routing mesh. This reference provides all the contact information for this route. The value of the component attribute will be a classless address followed by an AS reference. The component attri- butes represent the components which make up the route. Components in the same AS as the origin need not be listed. [There is some discussion needed if we should provide a pos- sibility to list holes and whether this should be mandatory. dfk thinks it should] Note that the components do not need to appear as their own route objects if they are not ori- ginated somewhere themselves. The rest of the attributes are analogous to the inetnum object. Conceptually there can be multiple route objects with dif- ferent origins. Representing multiple proxy aggregation which to our knowledge is not done in the Internet yet. We have not thoroughly investigated the consequences this added complexity will have for consistency checking and the PRIDE tools. - 3 - Update process for the route object Adding a route object will be guarded by the AS guardian files. A route object will only be added if the classless address value of the route attribute will appear in the guardian file of the origin mentioned. This guarantees that an AS has full control over the routes it announces. Any AS added or deleted from the components of a route object will be notified of the event by e-mail to the AS guardian. This guarantees that ASes are notified if some of their address space gets aggregated somewhere. Any community added or deleted from the comm-list of a route object will be notified of the event by e-mail to the com- munity guardian. Changes to the inetnum object The inetnum object will only represent the assignment of address space to an organisation. The following attributes will be deleted from the inetnum object: Obsolete: connect: [optional] [single] routpr-l: [optional] [single] [guarded] bdrygw-l: [optional] [single] [guarded] nsf-in: [optional] [single] nsf-out: [optional] [single] gateway: [optional] [single] Moved to the route object: aut-sys: [optional] [single] [guarded] comm-list: [optional] [single] [guarded] Representable as components of a route to the DMZ: ias-int: [optional] [multiple] Consequences for specifying routing policy Suppose the following universe: - 4 - route: 193.0.2/24 origin: AS1111 descr: XYZ Institute 1 changed: dfk at ripe.net 940427 source: RIPE route: 193.0.3/24 origin: AS2222 descr: XYZ Institute 2 changed: dfk at ripe.net 940427 source: RIPE route: 193.0.2/23 origin: AS1234 component: 193.0.2/24 AS1111 component: 193.0.3/24 AS2222 descr: XYZ campus aggregate changed: dfk at ripe.net 940427 source: RIPE If someone now says: aut-num: AS9999 ... as-in: AS8888 100 AS1111 they will only allow 193.0.2/24 in. aut-num: AS9999 ... as-in: AS8888 100 AS1234 will only allow 193.0.2/23 in and not the more specific com- ponents. aut-num: AS9999 ... as-in: AS8888 100 AS1234 AS1111 AS2222 will allow everything in. Now if we have aut-num: AS9999 ... as-in: AS8888 100 AS1111 and the more specific route 193.0.2/24 will be withdrawn and the corresponding route object deleted AS9999 will have lost connectivity to AS1111 unless AS9999 also takes AS1234. We will have to have tools that warn about situations like that. -------- Logged at Wed Apr 27 19:40:40 MET DST 1994 --------- From epg at merit.edu Wed Apr 27 19:40:28 1994 From: epg at merit.edu (epg at merit.edu) Date: Wed, 27 Apr 94 13:40:28 EDT Subject: as-in/as-out In-Reply-To: <9404271650.AA01465@reif.ripe.net>; from "Daniel Karrenberg" at Apr 27, 94 6:50 pm Message-ID: <9404271740.AA01578@pepper.merit.edu> Have just quickly browsed thru the document. Thanks for sending it. On the paragraph that says: "Conceptually there can be multiple route objects with different origins. Representing multiple proxy aggregation which to our knowledge is not done in the Internet yet." The NSFNET service will be doing proxy aggregation for DISA and Westnet real soon now (the code is ready). And it seems likely that some multi-homed entity in the future will ask both(or more) peer ASs to aggregate nets on their behalf. Could the unique key be route and origin, instead of just route? How would you propose to deal with this case? It seems shortsighted of us if we cannot accommodate proxy aggregation. --Elise -------- Logged at Wed Apr 27 19:50:48 MET DST 1994 --------- From jyy at merit.edu Wed Apr 27 19:50:39 1994 From: jyy at merit.edu (Jessica Yu) Date: Wed, 27 Apr 1994 13:50:39 -0400 Subject: as-in/as-out Message-ID: <199404271750.NAA25864@merit.edu> Daniel, Thanks for post the writeup. Here is my initial comment. >route: [mandatory] [single] >origin: [mandatory] [single] >component: [optional] [multiple] >comm-list: [optional] [single] [guarded] >descr: [mandatory] [multiple] >remarks: [optional] [multiple] >notify: [optional] [multiple] >maintainer: [optional] [single] >changed: [mandatory] [multiple] >source: [mandatory] [single] I assume 'origin' has the same concept as 'creator' which we defined at our San Diego meeting. Just try to be sure. Does your definition above mean that one route can only have one 'origin'? If yes, then how do you plan to handle the proxy aggregate situation where it is possible that different ASs do the proxy aggregate for the same AS and therefore one route will have two origins? Also, how do you plan to handle the cases which ASs further aggregate the routes they hear from different ASs? i.e. aggregate beyond AS boundary. E.g. AS1 aggregate routes from AS2 and AS3 to a route called route-a, and AS4 does the same thing. Now route-a has two origins AS1 and AS4 (see the diagram below). AS1 / \ AS2 AS3 \ / AS4 Proxy aggregate like mentioned in your write up is not been done yet. But it will be very soon. We have customers line up for us to do proxy aggr for them. The software is almost ready so it will be done really SOON. Proxy aggregate for multi-homed AS will be done when people get desperte to reduce the routing table size, so does aggregation beyond AS boundary. So it is really desirable for routing registry to be designed to anticipate this will happen and be able to deal with it. If you allow one route has more than one orgin, that will do it. What is the concern of doing that? Thanks! --Jessica -------- Logged at Wed Apr 27 21:31:16 MET DST 1994 --------- From Marten.Terpstra at ripe.net Wed Apr 27 21:31:12 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Wed, 27 Apr 1994 21:31:12 +0200 Subject: as-in/as-out In-Reply-To: Your message of Wed, 27 Apr 1994 13:40:28 EDT. <9404271740.AA01578@pepper.merit.edu> Message-ID: <9404271931.AA17924@mellow.ripe.net> Elise, I missed this sentence as well, and after rereading, I am not quite sure what the second sentence means. Proxy aggregation is obviously supported by components in different ASs. That is basic proxy aggregation. Now, the difficult bit comes when you do proxy proxy aggregation, ie you proxy aggregate for your customer with it's own AS, who has address space from your block, but I am your bigger transit provider and you have your own AS and your address space from my even bigger block (is this complicated or what ;-). Conceptually this can all be described with the object below. Problem with proxy^n aggregation is the consistency checking and policy derivation becomes quite difficult. I am not quite sure how many people are going to do more than one level proxy aggregation. Now, in stead of sending two mails, I may as well answer Jessica's question, and you are right that this is not clear from the doc, but we recognized that an aggregate can be aggregated at multiple places (and legally so, although it may create a policy maintainer's nightmare, and has all sorts of policy implications, but all that is nothing new) and therefore origin CAN contain more than one value. The "single" definition is a RIPE database like definition, which means it can only be one line, but on that line there can be multiple origins. Daniel and Tony, please correct me if I am totally wrong, but this is how I remember the discussion. -Marten * Have just quickly browsed thru the document. Thanks for sending it. * * On the paragraph that says: * "Conceptually there can be multiple route objects with different * origins. Representing multiple proxy aggregation which to our knowledge * is not done in the Internet yet." * * The NSFNET service will be doing proxy aggregation for DISA and Westnet * real soon now (the code is ready). And it seems likely that some * multi-homed entity in the future will ask both(or more) peer ASs to * aggregate nets on their behalf. Could the unique key be route and origin, * instead of just route? How would you propose to deal with * this case? It seems shortsighted of us if we cannot accommodate proxy * aggregation. * --Elise -------- Logged at Wed Apr 27 21:50:35 MET DST 1994 --------- From Tony.Bates at ripe.net Wed Apr 27 21:50:30 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Wed, 27 Apr 1994 21:50:30 +0200 Subject: as-in/as-out In-Reply-To: Your message of Wed, 27 Apr 1994 21:31:12 MDT. <9404271931.AA17924@mellow.ripe.net> Message-ID: <9404271950.AA04958@mature.ripe.net> Marten Terpstra writes: * * * Now, in stead of sending two mails, I may as well answer Jessica's * question, and you are right that this is not clear from the doc, but * we recognized that an aggregate can be aggregated at multiple places * (and legally so, although it may create a policy maintainer's * nightmare, and has all sorts of policy implications, but all that is * nothing new) and therefore origin CAN contain more than one value. The * "single" definition is a RIPE database like definition, which means it * can only be one line, but on that line there can be multiple origins. * * Daniel and Tony, please correct me if I am totally wrong, but this is * how I remember the discussion. * Right - we discussed this at length today. I guess the bottom line is by accepting this we accept one agg - multi ASes is permited. The only bit that is difficult is making sure we keep the clarity (i.e. provide help to the policy maintainers) and make the tools work ;-). * -Marten --Tony. -------- Logged at Wed Apr 27 22:44:45 MET DST 1994 --------- From jyy at merit.edu Wed Apr 27 22:44:38 1994 From: jyy at merit.edu (Jessica Yu) Date: Wed, 27 Apr 1994 16:44:38 -0400 Subject: as-in/as-out In-Reply-To: Your message of "Wed, 27 Apr 1994 21:31:12 +0200." <9404271931.AA17924@mellow.ripe.net> Message-ID: <199404272044.QAA12394@merit.edu> Now, in stead of sending two mails, I may as well answer Jessica's question, and you are right that this is not clear from the doc, but we recognized that an aggregate can be aggregated at multiple places (and legally so, although it may create a policy maintainer's nightmare, and has all sorts of policy implications, but all that is nothing new) and therefore origin CAN contain more than one value. Good. The "single" definition is a RIPE database like definition, which means it can only be one line, but on that line there can be multiple origins. Why not allow multiple lines then? If it is single line with multiple values, what is the devider , a space or a ','? -Marten --Jessica -------- Logged at Wed Apr 27 23:37:32 MET DST 1994 --------- From epg at merit.edu Wed Apr 27 23:37:23 1994 From: epg at merit.edu (epg at merit.edu) Date: Wed, 27 Apr 94 17:37:23 EDT Subject: as-in/as-out In-Reply-To: <9404271931.AA17924@mellow.ripe.net>; from "Marten Terpstra" at Apr 27, 94 9:31 pm Message-ID: <9404272137.AA01720@pepper.merit.edu> Thank heavens we are all in agreement about this. It's also good that we misinterpreted single. Thanks for the clarification. --Elise > > Elise, I missed this sentence as well, and after rereading, I am not > quite sure what the second sentence means. Proxy aggregation is > obviously supported by components in different ASs. That is basic > proxy aggregation. Now, the difficult bit comes when you do proxy > proxy aggregation, ie you proxy aggregate for your customer with it's > own AS, who has address space from your block, but I am your bigger > transit provider and you have your own AS and your address space from > my even bigger block (is this complicated or what ;-). Conceptually > this can all be described with the object below. Problem with proxy^n > aggregation is the consistency checking and policy derivation becomes > quite difficult. I am not quite sure how many people are going to do > more than one level proxy aggregation. > > Now, in stead of sending two mails, I may as well answer Jessica's > question, and you are right that this is not clear from the doc, but > we recognized that an aggregate can be aggregated at multiple places > (and legally so, although it may create a policy maintainer's > nightmare, and has all sorts of policy implications, but all that is > nothing new) and therefore origin CAN contain more than one value. The > "single" definition is a RIPE database like definition, which means it > can only be one line, but on that line there can be multiple origins. > > Daniel and Tony, please correct me if I am totally wrong, but this is > how I remember the discussion. > > -Marten > > * Have just quickly browsed thru the document. Thanks for sending it. > * > * On the paragraph that says: > * "Conceptually there can be multiple route objects with different > * origins. Representing multiple proxy aggregation which to our knowledge > * is not done in the Internet yet." > * > * The NSFNET service will be doing proxy aggregation for DISA and Westnet > * real soon now (the code is ready). And it seems likely that some > * multi-homed entity in the future will ask both(or more) peer ASs to > * aggregate nets on their behalf. Could the unique key be route and origin, > * instead of just route? How would you propose to deal with > * this case? It seems shortsighted of us if we cannot accommodate proxy > * aggregation. > * --Elise > -------- Logged at Tue May 24 18:41:32 MET DST 1994 ---------