From cengiz at ISI.EDU Sat Oct 1 00:57:37 1994 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Fri, 30 Sep 1994 16:57:37 -0700 Subject: Implementation of RIPE-181++ In-Reply-To: <9409271345.AA14526@mature.ripe.net> References: <199409262059.QAA13894@merit.edu> <9409271345.AA14526@mature.ripe.net> Message-ID: <199409302357.AA10682@chl.isi.edu> Tony Bates (Tony.Bates at ripe.net) on September 27: > This is correct and what I had said in words before I believe. The > tricky bit and something I am going to try to add into RIPE-81++ is > some text descibing the interaction a little better and making sure no > ambiguity is there. > I will try to do this later today and send that prtion of the text. Did you do it? I did not see any more discussion on this. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute cengiz at isi.edu University of Southern California -------- Logged at Sat Oct 1 20:20:47 MET 1994 --------- From Tony.Bates at ripe.net Sat Oct 1 20:20:39 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Sat, 01 Oct 1994 20:20:39 +0100 Subject: Implementation of RIPE-181++ In-Reply-To: Your message of Fri, 30 Sep 1994 16:57:37 MST. <199409302357.AA10682@chl.isi.edu> Message-ID: <9410011920.AA19876@mature.ripe.net> cengiz at ISI.EDU (Cengiz Alaettinoglu) writes: * * Tony Bates (Tony.Bates at ripe.net) on September 27: * > This is correct and what I had said in words before I believe. The * > tricky bit and something I am going to try to add into RIPE-81++ is * > some text descibing the interaction a little better and making sure no * > ambiguity is there. * > I will try to do this later today and send that prtion of the text. * * Did you do it? I did not see any more discussion on this. * No sorry - not yet - been tied with other things. I''ll try to have something by monday. * Cengiz --Tony. -------- Logged at Mon Oct 3 18:13:17 MET 1994 --------- From Tony.Bates at ripe.net Mon Oct 3 17:32:42 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Mon, 03 Oct 1994 17:32:42 +0100 Subject: Implementation of RIPE-181++ In-Reply-To: Your message of Fri, 30 Sep 1994 16:57:37 MST. <199409302357.AA10682@chl.isi.edu> Message-ID: <9410031632.AA26824@mature.ripe.net> Okay, I went round this a few times with Marten today and added a load of stuff then took it out again. Please comment on this. Still not sure if this makes sense. Here's the text...I would rather we just made it - ALL polices should be explicitly mention and the sum of interas policiy must equal global as policy. ==Tony. ..... Descriptions of interas policies do not replace the global pol- icy described in as-in, as-out and other policy attributes which should be specified too. If the global policy mentions more routes than the combined local policies then local preferences for these routes are assumed to be equal for all links. ripe-181.txt October, 1994 ^L - 28 - Any route specified in interas-in/out and not specified in as-in/out is assumed not accepted/announced between the ASes concerned. Diag- nostic tools should flag this inconsistency as an error. It should be noted that if an interas-in or interas-out policy is specified then it is mandatory to specify the corresponding global policy in the as-in or as-out line. Please note there is no relevance in the cost associated with as-in and the preferences used in interas-in. The interaction of interas-in/interas-out with as-in/as-out Although stated above, the rules associated with policy described in terms of interas-in and interas-out with respect to as-in and as-out are worthy of clarification for implementation. When using interas-in or interas-out policy descriptions, one must always make sure the set of policies described between two ASes is always equal to or a sub-set of the policy described in the global as-in or as-out policy. When a sub-set is described remember the remaining routes are implicitly shared across all connections. When defining interas based policy one should always ensure that any possible ambiguites are not present by explicitly defining your pol- icy with respect to the global as-in and as-out policy. If we look at a simple example, taking just in-bound announcements to simplify things. If we have the following global policy: aut-num: AS1 as-in: from AS2 10 accept AS100 OR {10.0.0.0/8} Suppose there are three connections (here connections can mean peer sessions or physical connections) between them, known as L1-R1, L2- R2 and L3-R3 respectively. The actual policy of these connections is to accept AS100 equally on these three links and just route 10.0.0.0/8 on L3-R3. Then the interas-in policy should be written as: interas-in: from AS2 L1 R1 (pref=100) accept AS100 interas-in: from AS2 L2 R2 (pref=100) accept AS100 interas-in: from AS2 L3 R3 (pref=100) accept AS100 OR {10.0.0.0/8} Whilst this may at first sight seem obvious, the problem arises when not all connections are mentioned. For example, if we specified only an interas-in line for L3-R3 as below: aut-num: AS1 as-in: from AS2 10 accept AS100 OR {10.0.0.0/8} interas-in: from AS2 L3 R3 (pref=100) accept AS100 OR {10.0.0.0/8} then the policy for the other links according to the rules above ripe-181.txt October, 1994 ^L - 29 - would mean they were equal to the global policy minus the sum of the local policies (i.e. ((AS100 OR {10.0.0.0/0}) / (AS100 OR {10.0.0.0/0})) = empty) which in this case would mean nothing is accepted on conections L1-R1 and L2-R2 which is incorrect. If we for example, we only registered the policy for link L2-R2 (i.e. accept AS100), according to the rules above, the derived pol- icy for both L1-R1 and L3-R3 would be as follows: interas-in: from AS2 L1 R1 (pref=100) accept {10.0.0.0/8} interas-in: from AS2 L3 R3 (pref=100) accept {10.0.0.0/8} This is derived as the set of global policies minus the set of interas-in policies (in this case just accept AS100 as it was the L2-R2 interas-in policy we registered) with equal cost for the remaining connectiosn. This again is clearly incorrect. We strongly recommend that you always mention all policies for all interas connections explicitly, to avoid these possible errors. One should always ensure the set of the interas policies is equal to the global policy. It should also be noted there is no direct realtionship between the cost used in as-in and the preference used in interas-in. -------- Logged at Tue Oct 4 10:20:24 MET 1994 --------- From Daniel.Karrenberg at ripe.net Tue Oct 4 10:20:07 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 04 Oct 1994 10:20:07 +0100 Subject: Implementation of RIPE-181++ In-Reply-To: Your message of Mon, 03 Oct 1994 17:32:42 MET. <9410031632.AA26824@mature.ripe.net> Message-ID: <9410040920.AA07723@reif.ripe.net> > Tony Bates writes: The text looks very good. > I would rather we just > made it - ALL polices should be explicitly mention and the sum of > interas policiy must equal global as policy. The reason I don't like this is that I expect many of the interas policies to be a limited set of exceptions to the global policy. To repeat: If the interas policies differ in complex ways, it is really worth considering to split the AS in question. For reasons refer to many a discussion on bgpd. Should we mention this? Here are my suggested changes, feel free: > The interaction of interas-in/interas-out with as-in/as-out > > Although stated above, the rules associated with policy described in s/stated/formally defined/ > terms of interas-in and interas-out with respect to as-in and as-out > are worthy of clarification for implementation. > > When using interas-in or interas-out policy descriptions, one must > always make sure the set of policies described between two ASes is > always equal to or a sub-set of the policy described in the global > as-in or as-out policy. When a sub-set is described remember the > remaining routes are implicitly shared across all connections. It is an error for the interas policies to describe a superset of the global policies, i.e. to announce or accept more routes than the global policies. > When defining interas based policy one should always ensure that any When defining complex interas based policies it is advisable to ensure ... > possible ambiguites are not present by explicitly defining your pol- > icy with respect to the global as-in and as-out policy. > > If we look at a simple example, taking just in-bound announcements > to simplify things. If we have the following global policy: > > > aut-num: AS1 > as-in: from AS2 10 accept AS100 OR {10.0.0.0/8} > > Suppose there are three connections (here connections can mean peer > sessions or physical connections) between them, known as L1-R1, L2- Suppose there are three peerings between AS1 and AS2, known .... > R2 and L3-R3 respectively. The actual policy of these connections is > to accept AS100 equally on these three links and just route > 10.0.0.0/8 on L3-R3. The simple way to mention this exception is to just specify an interas policy for L3-R3: interas-in: from AS2 L3 R3 (pref=100) accept {10.0.0.0/8} The implicit rule that all routes not mentioned in interas policies are accepted on all links with equal preference ensures the desired result. The same policy can be written explicitly as: > interas-in: from AS2 L1 R1 (pref=100) accept AS100 > interas-in: from AS2 L2 R2 (pref=100) accept AS100 > interas-in: from AS2 L3 R3 (pref=100) accept AS100 OR {10.0.0.0/8} > > Whilst this may at first sight seem obvious, the problem arises when > not all connections are mentioned. For example, if we specified only > an interas-in line for L3-R3 as below: > > aut-num: AS1 > as-in: from AS2 10 accept AS100 OR {10.0.0.0/8} > interas-in: from AS2 L3 R3 (pref=100) accept AS100 OR {10.0.0.0/8} > > then the policy for the other links according to the rules above > would mean they were equal to the global policy minus the sum of the > local policies (i.e. ((AS100 OR {10.0.0.0/0}) / (AS100 OR > {10.0.0.0/0})) = empty) which in this case would mean nothing is > accepted on conections L1-R1 and L2-R2 which is incorrect. Another example: If we only registered the policy for link L2-R2: interas-in: from AS2 L2 R2 (pref=100) accept AS100 The implicit policy for both L1-R1 and L3-R3 would be as follows: interas-in: from AS2 L1 R1 (pref=100) accept {10.0.0.0/8} interas-in: from AS2 L3 R3 (pref=100) accept {10.0.0.0/8} > This is derived as the set of global policies minus the set of > interas-in policies (in this case just accept AS100 as it was the > L2-R2 interas-in policy we registered) with equal cost for the > remaining connectiosn. This again is clearly incorrect. s/incorrect/not what was intended./ > We strongly recommend that except in simple cases you always mention > all policies for all > interas connections explicitly, to avoid these possible errors. One > should always ensure the set of the interas policies is equal to the > global policy. > > It should also be noted there is no direct realtionship between the > cost used in as-in and the preference used in interas-in. -------- Logged at Tue Oct 4 11:03:59 MET 1994 --------- From Tony.Bates at ripe.net Tue Oct 4 11:03:50 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Tue, 04 Oct 1994 11:03:50 +0100 Subject: Implementation of RIPE-181++ In-Reply-To: Your message of Tue, 04 Oct 1994 10:20:07 MET. <9410040920.AA07723@reif.ripe.net> Message-ID: <9410041003.AA29592@mature.ripe.net> Daniel Karrenberg writes: * Okay, thanks for your changes. I have incorperated them and added a small note on the slitting ASes. Find below he revised text. --Tony. P.S. Today is really the last day to comment before we send this document out as ripe-181. The interaction of interas-in/interas-out with as-in/as-out Although formally defined above, the rules associated with policy described in terms of interas-in and interas-out with respect to as-in and as-out are worthy of clarification for implementation. When using interas-in or interas-out policy descriptions, one must always make sure the set of policies described between two ASes is always equal to or a sub-set of the policy described in the global as-in or as-out policy. When a sub-set is described remember the remaining routes are implicitly shared across all connections. It is an error for the interas policies to describe a superset of the glo- bal policies, i.e. to announce or accept more routes than the global policies. When defining complex interas based policies it is advisable to ensure that any possible ambiguities are not present by explicitly defining your policy with respect to the global as-in and as-out policy. If we look at a simple example, taking just in-bound announcements to simplify things. If we have the following global policy: aut-num: AS1 as-in: from AS2 10 accept AS100 OR {10.0.0.0/8} Suppose there are three peerings between AS1 and AS2, known as L1- R1, L2-R2 and L3-R3 respectively. The actual policy of these connec- tions is to accept AS100 equally on these three links and just route 10.0.0.0/8 on L3-R3. The simple way to mention this exception is to just specify an interas policy for L3-R3: interas-in: from AS2 L3 R3 (pref=100) accept {10.0.0.0/8} The implicit rule that all routes not mentioned in interas policies are accepted on all links with equal preference ensures the desired result. The same policy can be written explicitly as: interas-in: from AS2 L1 R1 (pref=100) accept AS100 interas-in: from AS2 L2 R2 (pref=100) accept AS100 interas-in: from AS2 L3 R3 (pref=100) accept AS100 OR {10.0.0.0/8} ripe-181.txt October, 1994 ^L - 29 - Whilst this may at first sight seem obvious, the problem arises when not all connections are mentioned. For example, if we specified only an interas-in line for L3-R3 as below: aut-num: AS1 as-in: from AS2 10 accept AS100 OR {10.0.0.0/8} interas-in: from AS2 L3 R3 (pref=100) accept AS100 OR {10.0.0.0/8} then the policy for the other links according to the rules above would mean they were equal to the global policy minus the sum of the local policies (i.e. ((AS100 OR {10.0.0.0/0}) / (AS100 OR {10.0.0.0/0})) = empty) which in this case would mean nothing is accepted on connections L1-R1 and L2-R2 which is incorrect. Another example: If we only registered the policy for link L2- R2: interas-in: from AS2 L2 R2 (pref=100) accept AS100 The implicit policy for both L1-R1 and L3-R3 would be as follows: interas-in: from AS2 L1 R1 (pref=100) accept {10.0.0.0/8} interas-in: from AS2 L3 R3 (pref=100) accept {10.0.0.0/8} This is derived as the set of global policies minus the set of interas-in policies (in this case just accept AS100 as it was the L2-R2 interas-in policy we registered) with equal cost for the remaining connection. This again is clearly not what was intended. We strongly recommend that you always mention all policies for all interas connections explicitly, to avoid these possible errors. One should always ensure the set of the interas policies is equal to the global policy. Clearly if interas policies differ in complex ways it is worth considering splitting the AS in question into separate ASes. However, this is beyond the direct scope of this document. It should also be noted there is no direct relationship between the cost used in as-in and the preference used in interas-in. -------- Logged at Wed Sep 7 01:08:13 MET DST 1994 --------- From dsj at merit.edu Tue Oct 4 15:55:09 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Tue, 4 Oct 1994 10:55:09 -0400 Subject: Last gasp on Communities Message-ID: <199410041455.KAA28616@merit.edu> Pardon me for dragging up this "Community" issue one last time. I think Marten's comments below do make this all clear, but I'll take this last chance again to make sure that I'm not misunderstanding, now that the documentation is about to become final. If I want to create a community: 1) I must create and register the Community object. 2) I then ask the maintainers of the Route objects which should be in that community to add my new community name to their Route comm-list attributes. 3) I get a mail message each time the new community name is added to or deleted from any Route object. If this is correct, you might want to add a few sentences like these to the Auth document. (Or, if this doesn't belong in the Auth document, it really ought to be written down somewhere, including in the upcoming training courses). --Dale > * Auth (p 9) says: > * > * Note that this rule changes the level of membership control > * exercised by community and AS guardians have with respect > * to the "guardian file" method. Control is now by notification > * after the fact. > * > * This implies that anyone entering or modifying a Route object can > * mark it as belonging to any community he wishes--and that the community > * owner just gets email afterword. It also sounds to me (without further > * explanation somewhere) as though someone wanting to create a new > * community would have to find all of the owners of all of the routes > * that should belong to that community, and would have to contact them > * out-of-band with messages saying "I've just created this new community > * COMM_GOODGUYS, would you mind editing all of the following routes to > * include COMM_GOODGUYS in their comm-list attribute?". To create the > * NSFNET community in your example, we would have to make out-of-band > * requests to the 464 ASs that are currently submit have registered > * NSFNET routes in the PRDB, asking each of them to modify their > * entries > > Basically yes, they would have to. Or, with the current implementation > of the authorisation, just send it in with the correct community, > and the proper maintainer will receive the request. I still think > that community based policies should be avoided as much as possible, > simply because they won't scale, and will provide more surprises than > solutions. To me I think you are still thinking of the current NSFnet > way of doing things. Personally I do not think there'll be communities > with thousands of routes actually being used for routing. It'll be AS > based more than anything else. Keeping communities is simply a pain. > Add some aggregation, and community based routing is even more of a > problem. > > * for us. It would also imply that the Guardians still need to keep a > * file of who they think *should* be members of their community, though > * now this file has moved from being a Guardian File hosted on a Routing > * Registry machine to being something that keep privately for their own > * use. > > Yes. > > * Am I still misunderstanding? Is there a section of the new drafts > * that > > Noop. > > * I've missed, or a new document that will explain this that will be out > * soon? Sorry to be pushy on this; we need to be coding this functionality > * this week in order to configure the Route Servers, and we're trying as > * hard as we can to do it within the RIPE-181 framework. > * > * If I do have this right, the Community structure seems unusable for > * storing net lists for use in local configuration generation. The best > * solution I can see for adding the functionality we need would be the > * one Rick suggested Friday: add a new object for that purpose which > * could be used with the experimental DBSELECTOR to come up with specific > * net lists. This is essentially what Laurent has implemented in alc, > * except that those lists are in private files that only alc knows about, > * rather than being part of the Routing Registry that is visible through > * whois, ftp dumps, etc. Again, assuming I'm not still misunderstanding > * the new community implementation, does this sound like the most > * RIPE-181-like implmentation we can come up with for storing local > * routing info for our 40K registered routes, while still making that > * information available as part of the registry? Any other ideas? > > Well, do you really think you will need communities with 40+ thousand > nets? The reason for creating communities is because of different > policies for various nets inside an AS. Will this still be necessary in > post NSFnet days? I'd like to see communities more as an exception, > rather than a rule .... Of course, this is my opinion. > > Now, ripe-81++ does not (or should not) contain any details on how the > ripe-81 style "guarded attributes" are maintained. We think it can be > implemented through the Notification scheme, but you may have a > different idea. I like Rick's idea, but it;s got a definate scaling > problem (if you *really* need 40K+ communities). There's other > ways (like "on-the-fly" addition of communities from files) or even > more strict ones. We took the "light-weight" approach... > > -Marten > -------- Logged at Tue Oct 4 16:36:56 MET 1994 --------- From Tony.Bates at ripe.net Tue Oct 4 16:36:39 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Tue, 04 Oct 1994 16:36:39 +0100 Subject: Last gasp on Communities In-Reply-To: Your message of Tue, 04 Oct 1994 10:55:09 -0400. <199410041455.KAA28616@merit.edu> Message-ID: <9410041536.AA00974@mature.ripe.net> "Dale S. Johnson" writes: * Pardon me for dragging up this "Community" issue one last time. I think * Marten's comments below do make this all clear, but I'll take this last * chance again to make sure that I'm not misunderstanding, now that the * documentation is about to become final. * * If I want to create a community: * * 1) I must create and register the Community object. * 2) I then ask the maintainers of the Route objects which should * be in that community to add my new community name to their * Route comm-list attributes. * 3) I get a mail message each time the new community name is added to * or deleted from any Route object. * This is right yes. * If this is correct, you might want to add a few sentences like these to * the Auth document. (Or, if this doesn't belong in the Auth document, * it really ought to be written down somewhere, including in the upcoming * training courses). * I will check with the main editor (Daniel) if he wants to add this in. Thanks for the comments on this and all documents by the way. --Tony. -------- Logged at Tue Oct 4 19:31:40 MET 1994 --------- From dsj at merit.edu Tue Oct 4 19:31:34 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Tue, 4 Oct 1994 14:31:34 -0400 Subject: Recursive AS-Macros Message-ID: <199410041831.OAA17516@merit.edu> (Sigh, last minute change): How about allowing AS-Macros to contain AS-Macros. E.g.: as-macro: AS-MCI descr: All MCINet ASs as-list: AS-MCI-EAST AS-MCI-MIDWEST AS-MCI-WEST as-macro: AS-MCI-MIDWEST descr: MCINet ASs with primary routes through CHI NAP as-list: AS233 AS237 AS266 AS267 as-macro: AS-MCI-EAST descr: MCINet ASs with primary routes through NY NAP as-list: AS560 ... ... This would require a couple of words change on Appendix C, "as-list" description (plus possibly some code modifications). This may be particularly useful for simplifying the complexity of representing policy in *both* AS-IN and INTERAS-IN formats. -------- (Or, of course, this extension could be handled with whatever normal mechanisms will be used for additions to RIPE-181 after tomorrow.) --Dale -------- Logged at Tue Oct 4 19:51:42 MET 1994 --------- From epg at merit.edu Tue Oct 4 19:51:32 1994 From: epg at merit.edu (epg at merit.edu) Date: Tue, 4 Oct 1994 14:51:32 -0400 (EDT) Subject: Implementation of RIPE-181++ In-Reply-To: <9410041003.AA29592@mature.ripe.net> from "Tony Bates" at Oct 4, 94 11:03:50 am Message-ID: <9410041851.AA05333@pepper.merit.edu> Tony and Daniel, I liked Tony's original comment about keeping it simple, and somehow the text seems more complicated than necessary - though please don't think I am complaining - you all have done a masterful job. Comments scattered after appropriate text. >Tony Bates writes: > > > Daniel Karrenberg writes: > * > Okay, thanks for your changes. I have incorperated them and added a > small note on the slitting ASes. Find below he revised text. > > > --Tony. > > P.S. Today is really the last day to comment before we send this > document out as ripe-181. > > The interaction of interas-in/interas-out with as-in/as-out > > Although formally defined above, the rules associated with policy > described in terms of interas-in and interas-out with respect to > as-in and as-out are worthy of clarification for implementation. > > When using interas-in or interas-out policy descriptions, one must > always make sure the set of policies described between two ASes is > always equal to or a sub-set of the policy described in the global > as-in or as-out policy. When a sub-set is described remember the > remaining routes are implicitly shared across all connections. It is The sentence, "When a sub-set is described remember the remaining routes are implicitly shared across all connections." has always been confusing for me. I am sure that I don't interpret this as it is meant, and can't figure out why it seems to mean something that we don't want to mean. What it says to me is, if my global policy is accept a+b+c and my subset policy is accept a+b, then the remaining route is c and it is accepted by all connections. Now, that is different than what I thought we agreed (in fact it is incorrect). Please try to clarify what it is I am missing in my intrepretion of this sentence. I really think I understand what we mean, but this sentence just doesn't jive. > an error for the interas policies to describe a superset of the glo- > bal policies, i.e. to announce or accept more routes than the global > policies. > > When defining complex interas based policies it is advisable to > ensure that any possible ambiguities are not present by explicitly > defining your policy with respect to the global as-in and as-out > policy. > > If we look at a simple example, taking just in-bound announcements > to simplify things. If we have the following global policy: > > > aut-num: AS1 > as-in: from AS2 10 accept AS100 OR {10.0.0.0/8} > > Suppose there are three peerings between AS1 and AS2, known as L1- > R1, L2-R2 and L3-R3 respectively. The actual policy of these connec- > tions is to accept AS100 equally on these three links and just route > 10.0.0.0/8 on L3-R3. The simple way to mention this exception is to > just specify an interas policy for L3-R3: > > interas-in: from AS2 L3 R3 (pref=100) accept {10.0.0.0/8} My simple policy description of L3R3 would be: interas-in: from AS2 L3 R3 (pref=100) accept {10.0.0.0/8} interas-in: from AS2 L3 R3 (pref=10) accept AS100 because the statement about the difference between as-in and interas-in is equal across all the links is easy to misinterpret. I think that we should strive to encourage folks who are explicitly stating an exception to state it explicitly. > > > The implicit rule that all routes not mentioned in interas policies > are accepted on all links with equal preference ensures the desired > result. > This still seems confusing to me, because if you have two different interas-in statements, the total subtraction from the as-in statement could result in a difference of zero, which is not what you were trying to express. Basically, I have the same problem with this statement as I did with the previously noted sentence. > The same policy can be written explicitly as: > > interas-in: from AS2 L1 R1 (pref=100) accept AS100 > interas-in: from AS2 L2 R2 (pref=100) accept AS100 > interas-in: from AS2 L3 R3 (pref=100) accept AS100 OR {10.0.0.0/8} > > Small error (it may be a typo, but it is why my previous example looks like it does). In the as-in statement we use "10" not "100." But maybe you meant to do that to stress that the preferences in as-in and interas-in are unequivilant. But if that is the case, how can you decide that the preference to accept AS100 is comparable to the preference to accept {10.0.0.0/8}. Or doesn't it matter? I would have thought that if something is unstated, it would be interpreted exactly as stated in the as-in statement. > > > ripe-181.txt October, 1994 > ^L - 29 - > > > Whilst this may at first sight seem obvious, the problem arises when > not all connections are mentioned. For example, if we specified only > an interas-in line for L3-R3 as below: > > aut-num: AS1 > as-in: from AS2 10 accept AS100 OR {10.0.0.0/8} > interas-in: from AS2 L3 R3 (pref=100) accept AS100 OR {10.0.0.0/8} > > > then the policy for the other links according to the rules above > would mean they were equal to the global policy minus the sum of the > local policies (i.e. ((AS100 OR {10.0.0.0/0}) / (AS100 OR > {10.0.0.0/0})) = empty) which in this case would mean nothing is > accepted on connections L1-R1 and L2-R2 which is incorrect. > What I think is incorrect is the statement, "remaining routes are implicitly shared across all connections." If we delete this statement we avoid all the ambiguity. The problem is in what we have stated and then how we want it to be interpreted. They are inconsistent. > Another example: If we only registered the policy for link L2- > R2: > > interas-in: from AS2 L2 R2 (pref=100) accept AS100 > > The implicit policy for both L1-R1 and L3-R3 would be as follows: > > interas-in: from AS2 L1 R1 (pref=100) accept {10.0.0.0/8} > interas-in: from AS2 L3 R3 (pref=100) accept {10.0.0.0/8} > > > This is derived as the set of global policies minus the set of > interas-in policies (in this case just accept AS100 as it was the > L2-R2 interas-in policy we registered) with equal cost for the > remaining connection. This again is clearly not what was intended. > > We strongly recommend that you always mention all policies for all > interas connections explicitly, to avoid these possible errors. One > should always ensure the set of the interas policies is equal to the > global policy. Clearly if interas policies differ in complex ways it > is worth considering splitting the AS in question into separate > ASes. However, this is beyond the direct scope of this document. > > It should also be noted there is no direct relationship between the > cost used in as-in and the preference used in interas-in. > > --Elise -------- Logged at Tue Oct 4 20:47:38 MET 1994 --------- From jyy at merit.edu Tue Oct 4 20:47:29 1994 From: jyy at merit.edu (Jessica Yu) Date: Tue, 04 Oct 1994 15:47:29 -0400 Subject: Implementation of RIPE-181++ In-Reply-To: Your message of "Tue, 04 Oct 1994 11:03:50 BST." <9410041003.AA29592@mature.ripe.net> Message-ID: <199410041947.PAA22991@merit.edu> >It should also be noted there is no direct relationship between the >cost used in as-in and the preference used in interas-in. Actually, the cost in as-in and the preference in interas-in need to be comparable. See the example below: AS1 peers with AS100 at two interconnections. AS100 include nets {a,b,c,x,y,z}. AS1 likes to do load banlancing by accepting nets a,b,c at interconnection1 (L1 R1) with preference 1 and x,y,z with preference 2. At interconnection2 (L2 R2), AS1 accepts x,y,z with preference 1 and a,b,c with preference 2. The policy expression would be as follow: aut-num: AS1 as-in: from AS100 1 accept AS100 interas-in: from AS100 L1 R1 (pref=1) accept {a,b,c} interas-in: from AS100 L1 R1 (pref=2) accept {x,y,z} interas-in: from AS100 L2 R2 (pref=1) accept {x,y,z} interas-in: from AS100 L2 R2 (pref=2) accept {a,b,c} If people do explicitly list their interas-in policy, then there is no problem. However, if people do not explicitly list them as the current version allows, then we will have a problem if the cost and pref is not comparable. aut-num: AS1 as-in: from AS100 1 accept AS100 interas-in: from AS100 L1 R1 (pref=1) accept {a,b,c} interas-in: from AS100 L2 R2 (pref=1) accept {x,y,z} This implies that interas-in: from AS100 L1 R1 (pref=1) accept {x,y,z} interas-in: from AS100 L2 R2 (pref=1) accept {a,b,c} This is incorrect policy. So for this example, either we advice people the be carefully put their cost and pref that means they are not uncomparable, or have to have them explicitly list the interas policy which needs a change to the current text. --Jessica -------- Logged at Tue Oct 4 21:12:16 MET 1994 --------- From jyy at merit.edu Tue Oct 4 21:12:00 1994 From: jyy at merit.edu (Jessica Yu) Date: Tue, 04 Oct 1994 16:12:00 -0400 Subject: Implementation of RIPE-181++ In-Reply-To: Your message of "Tue, 04 Oct 1994 11:03:50 BST." <9410041003.AA29592@mature.ripe.net> Message-ID: <199410042012.QAA25081@merit.edu> Currently, in the 81++ document, thought it is not written explicitly, it implies that if one does not list certain AS or nets in as-in/out, it means the opposite policy of what mentioned. For example, if AS1 has the policy of as-in: from AS100 1 accept AS690 AS200 means from AS100 it will only accept AS690 and AS200 and NOT rest of the ASs. as-in: from AS300 1 accept NOT (AS301 AS302) means from AS300, it will accept ANY ASs except AS301 and AS302. Same rule can not be applied to interas-in/out since according to the rule of interaction between the two set, interas-in will also accept whatever the difference between the as-in and the union of the interas-ins. This means that if an AS has the policy of NOT accepting a particular AS or routes at a particular connection, its interas-in has to always explicitly list the NOT's. as-in: from AS100 1 accept AS690 AS200 interas-in: from AS100 L1 R1 (pref=1) accept NOT AS200 (he can not say here 'interas-in: from AS100 L1 R1 (pref=1) accept AS690' and expect it implies NOT accept AS200) interas-in: from AS100 L1 R1 (pref=1) accept AS690 AS200 That is, one can not expect the same as what him gets from as-in where if he list what to accept then he does not need to list what he does not want to accept. This needs to be explained in the document. --Jessica -------- Logged at Tue Oct 4 21:25:22 MET 1994 --------- From Daniel.Karrenberg at ripe.net Tue Oct 4 21:24:58 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 04 Oct 1994 21:24:58 +0100 Subject: Implementation of RIPE-181++ In-Reply-To: Your message of Tue, 04 Oct 1994 15:47:29 -0400. <199410041947.PAA22991@merit.edu> Message-ID: <9410042024.AA09171@reif.ripe.net> > Jessica Yu writes: > >It should also be noted there is no direct relationship between the > >cost used in as-in and the preference used in interas-in. > > Actually, the cost in as-in and the preference in interas-in need to be > comparable. No. > aut-num: AS1 > as-in: from AS100 1 accept AS100 > interas-in: from AS100 L1 R1 (pref=1) accept {a,b,c} > interas-in: from AS100 L1 R1 (pref=2) accept {x,y,z} > interas-in: from AS100 L2 R2 (pref=1) accept {x,y,z} > interas-in: from AS100 L2 R2 (pref=2) accept {a,b,c} > > If people do explicitly list their interas-in policy, then there is no > problem. However, if people do not explicitly list them as the current > version allows, then we will have a problem if the cost and pref is not > comparable. > > aut-num: AS1 > as-in: from AS100 1 accept AS100 > interas-in: from AS100 L1 R1 (pref=1) accept {a,b,c} > interas-in: from AS100 L2 R2 (pref=1) accept {x,y,z} > > This implies that > > interas-in: from AS100 L1 R1 (pref=1) accept {x,y,z} > interas-in: from AS100 L2 R2 (pref=1) accept {a,b,c} It does not imply that. According to the wording it implies: interas-in: from AS100 L1 R1 (pref=some) accept AS100 interas-in: from AS100 L2 R2 (pref=some) accept AS100 Where "some" is not explicitly defined by the text but implicitly greater than all preferences mentioned in interas-in attributes. > This is incorrect policy. This is what was intended. > So for this example, either we advice people the be carefully put their > cost and pref that means they are not uncomparable, or have to have them > explicitly list the interas policy which needs a change to the current > text. For this example I would indeed advise people to say things explicitly. The implicit rules are intended for cases specifying exceptions like aut-num: AS1 as-in: from AS100 1 accept AS1 AS2 AS3 AS4 AS5 AS6 AS7 as-in: from AS100 1 accept AS31 AS32 AS33 AS34 AS35 AS36 AS37 as-in: from AS100 1 accept AS61 AS62 AS63 AS64 AS65 AS66 AS67 interas-in: from AS100 L1 R1 (pref=1) accept AS34 In such cases repeating all the AS numbers just adds noise, whereas the short form makes it immediatly obvious what the local policy deviation is. Note that in practise this will often be true for your example case as well. Daniel -------- Logged at Tue Oct 4 22:13:38 MET 1994 --------- From Tony.Bates at ripe.net Tue Oct 4 21:57:23 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Tue, 04 Oct 1994 21:57:23 +0100 Subject: Recursive AS-Macros In-Reply-To: Your message of Tue, 04 Oct 1994 14:31:34 -0400. <199410041831.OAA17516@merit.edu> Message-ID: <9410042057.AA01412@mature.ripe.net> Actually, they're already in all PRIDE tools and software. Here's one in the RIPE RR. % whois -r AS-NORDUNET as-macro: AS-NORDUNET descr: Macro with all ASes exported by NORDUnet as-list: AS-SUNET AS3224 AS2603 AS1654 AS224 AS1835 AS1850 AS1741 AS1739 as-list: AS544 AS719 AS565 AS2847 AS2380 AS3221 AS2588 AS1887 AS2895 as-list: AS3240 AS1248 guardian: staff at sunet.se tech-c: Bjorn Carlsson admin-c: Bjorn Eriksen changed: bc at sunet.se 940921 source: RIPE There is even a small PRIDE tool called maxpand to recursively expand these. % maxpand AS-NORDUNET AS224 AS544 AS565 AS719 AS1248 AS1653 AS1654 AS1739 AS1741 AS1835 AS1850 AS1887 AS2380 AS2588 AS2603 AS2831 AS2832 AS2833 AS2834 AS2835 AS2836 AS2837 AS2838 AS2839 AS2840 AS2841 AS2842 AS2843 AS2844 AS2845 AS2846 AS2847 AS2895 AS3221 AS3224 AS3240 I guessed I missed adding it to the text. I will add this in. --Tony. "Dale S. Johnson" writes: * (Sigh, last minute change): * * How about allowing AS-Macros to contain AS-Macros. E.g.: * * as-macro: AS-MCI * descr: All MCINet ASs * as-list: AS-MCI-EAST AS-MCI-MIDWEST AS-MCI-WEST * * as-macro: AS-MCI-MIDWEST * descr: MCINet ASs with primary routes through CHI NAP * as-list: AS233 AS237 AS266 AS267 * * as-macro: AS-MCI-EAST * descr: MCINet ASs with primary routes through NY NAP * as-list: AS560 ... * * ... * * This would require a couple of words change on Appendix C, "as-list" * description (plus possibly some code modifications). This may be * particularly useful for simplifying the complexity of representing * policy in *both* AS-IN and INTERAS-IN formats. * * -------- * * (Or, of course, this extension could be handled with whatever normal * mechanisms will be used for additions to RIPE-181 after tomorrow.) * * --Dale * -------- Logged at Tue Oct 4 22:32:51 MET 1994 --------- From Tony.Bates at ripe.net Tue Oct 4 22:32:44 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Tue, 04 Oct 1994 22:32:44 +0100 Subject: Implementation of RIPE-181++ In-Reply-To: Your message of Tue, 04 Oct 1994 16:12:00 -0400. <199410042012.QAA25081@merit.edu> Message-ID: <9410042132.AA01533@mature.ripe.net> Jessica Yu writes: * Currently, in the 81++ document, thought it is not written explicitly, it * implies that if one does not list certain AS or nets in as-in/out, it means * * the opposite policy of what mentioned. * For example, if AS1 has the policy of * * as-in: from AS100 1 accept AS690 AS200 * means from AS100 it will only accept AS690 and AS200 and NOT rest of the AS * s. * * as-in: from AS300 1 accept NOT (AS301 AS302) * means from AS300, it will accept ANY ASs except AS301 and AS302. * Right - this is implicit and always has been. In fact this is implicit with all rules even in life isn't it ? Its like if you are to be given something, say three bananas and three oranges and you say I want three bananas, you get three bananas. If on the other hand you say I dont want three bananas you get three oranges or am I just oversimplifying things comparing routes to fruit, but it was not seen as a problem in RIPE-81. * Same rule can not be applied to interas-in/out since according to the rule * of interaction between the two set, interas-in will also accept whatever * the difference between the as-in and the union of the interas-ins. This * means that if an AS has the policy of NOT accepting a particular AS or rout * es * at a particular connection, its interas-in has to always explicitly list th * e * NOT's. * Right - but this is obvious to me at least. * as-in: from AS100 1 accept AS690 AS200 * interas-in: from AS100 L1 R1 (pref=1) accept NOT AS200 * (he can not say here 'interas-in: from AS100 L1 R1 (pref=1) accept AS690' a * nd * expect it implies NOT accept AS200) * interas-in: from AS100 L1 R1 (pref=1) accept AS690 AS200 * * That is, one can not expect the same as what him gets from as-in where if h * e * list what to accept then he does not need to list what he does not want to * accept. This needs to be explained in the document. * Does this really need to be explained - we can spell out too much. I think it is clear what the implicit nature of the NOT or otherwise is. * --Jessica --Tony -------- Logged at Tue Oct 4 22:57:37 MET 1994 --------- From jyy at merit.edu Tue Oct 4 22:57:31 1994 From: jyy at merit.edu (Jessica Yu) Date: Tue, 04 Oct 1994 17:57:31 -0400 Subject: Implementation of RIPE-181++ Message-ID: <199410042157.RAA02554@merit.edu> >Jessica Yu writes: >* Currently, in the 81++ document, thought it is not written explicitly, it >* implies that if one does not list certain AS or nets in as-in/out, it means >* >* the opposite policy of what mentioned. >* For example, if AS1 has the policy of >* >* as-in: from AS100 1 accept AS690 AS200 >* means from AS100 it will only accept AS690 and AS200 and NOT rest of the AS >* s. >* >* as-in: from AS300 1 accept NOT (AS301 AS302) >* means from AS300, it will accept ANY ASs except AS301 and AS302. >* >Right - this is implicit and always has been. In fact this is implicit with all >rules even in life isn't it ? >Its like if you are to be given something, say three bananas and >three oranges and you say I want three bananas, you get three bananas. If on the >other hand you say I dont want three bananas you get three oranges or am I >just oversimplifying things comparing routes to fruit, but it was not seen >as a problem in RIPE-81. I am not saying this is a problem. I just trying to point out there is a different rule in this aspect between as-in/out and interas-in/out. >* Same rule can not be applied to interas-in/out since according to the rule >* of interaction between the two set, interas-in will also accept whatever >* the difference between the as-in and the union of the interas-ins. This >* means that if an AS has the policy of NOT accepting a particular AS or rout >* es >* at a particular connection, its interas-in has to always explicitly list th >* e >* NOT's. >* >Right - but this is obvious to me at least. It may be obvious to you and me since we are working on it. But it may not obvious to potential users. It does not hurt to point it out. >* as-in: from AS100 1 accept AS690 AS200 >* interas-in: from AS100 L1 R1 (pref=1) accept NOT AS200 >* (he can not say here 'interas-in: from AS100 L1 R1 (pref=1) accept AS690' a >* nd >* expect it implies NOT accept AS200) >* interas-in: from AS100 L1 R1 (pref=1) accept AS690 AS200 >* >* That is, one can not expect the same as what him gets from as-in where if h >* e >* list what to accept then he does not need to list what he does not want to >* accept. This needs to be explained in the document. >* >Does this really need to be explained - we can spell out too much. I think it >is clear what the implicit nature of the NOT or otherwise is. In my opinion, it is given the difference between the as-in/out and interas-in/ out and also if people make mistake on this, their policy will be impacted. It does not hurt to add a couple of sentences to point this out. --Jessica -------- Logged at Tue Oct 4 23:14:07 MET 1994 --------- From jyy at merit.edu Tue Oct 4 23:14:00 1994 From: jyy at merit.edu (Jessica Yu) Date: Tue, 04 Oct 1994 18:14:00 -0400 Subject: Implementation of RIPE-181++ Message-ID: <199410042214.SAA03669@merit.edu> >> Jessica Yu writes: >> >It should also be noted there is no direct relationship between the >> >cost used in as-in and the preference used in interas-in. >> >> Actually, the cost in as-in and the preference in interas-in need to be >> comparable. >No. Well, they are not competely unrelated. See below. >> aut-num: AS1 >> as-in: from AS100 1 accept AS100 >> interas-in: from AS100 L1 R1 (pref=1) accept {a,b,c} >> interas-in: from AS100 L1 R1 (pref=2) accept {x,y,z} >> interas-in: from AS100 L2 R2 (pref=1) accept {x,y,z} >> interas-in: from AS100 L2 R2 (pref=2) accept {a,b,c} >> >> If people do explicitly list their interas-in policy, then there is no >> problem. However, if people do not explicitly list them as the current >> version allows, then we will have a problem if the cost and pref is not >> comparable. >> >> aut-num: AS1 >> as-in: from AS100 1 accept AS100 >> interas-in: from AS100 L1 R1 (pref=1) accept {a,b,c} >> interas-in: from AS100 L2 R2 (pref=1) accept {x,y,z} >> >> This implies that >> >> interas-in: from AS100 L1 R1 (pref=1) accept {x,y,z} >> interas-in: from AS100 L2 R2 (pref=1) accept {a,b,c} >It does not imply that. >According to the wording it implies: >interas-in: from AS100 L1 R1 (pref=some) accept AS100 >interas-in: from AS100 L2 R2 (pref=some) accept AS100 >Where "some" is not explicitly defined by the text but implicitly >greater than all preferences mentioned in interas-in attributes. What happen if I define my policy like interas-in: from AS100 L1 R1 (pref=2) accept {x,y,z} interas-in: from AS100 L2 R2 (pref=2) accept {a,b,c} then your scheme does not work because this really needs a preference which is smaller than the ones mentioned in interas-in attributes. But even take what you said in consideration. This "some" has to be the one that does not equal and greater than the one specified in 'pref', in this case is 1. When we have such requirement, that really means the two are not completely uncomparable or no direct relashionship at all. >> This is incorrect policy. >This is what was intended. >> So for this example, either we advice people the be carefully put their >> cost and pref that means they are not uncomparable, or have to have them >> explicitly list the interas policy which needs a change to the current >> text. >For this example I would indeed advise people to say things explicitly. >The implicit rules are intended for cases specifying exceptions like >aut-num: AS1 >as-in: from AS100 1 accept AS1 AS2 AS3 AS4 AS5 AS6 AS7 >as-in: from AS100 1 accept AS31 AS32 AS33 AS34 AS35 AS36 AS37 >as-in: from AS100 1 accept AS61 AS62 AS63 AS64 AS65 AS66 AS67 >interas-in: from AS100 L1 R1 (pref=1) accept AS34 >In such cases repeating all the AS numbers just adds noise, whereas the >short form makes it immediatly obvious what the local policy deviation >is. Note that in practise this will often be true for your example case >as well. --Jessica -------- Logged at Wed Oct 5 18:46:00 MET 1994 --------- From cengiz at ISI.EDU Wed Oct 5 18:44:56 1994 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Wed, 5 Oct 1994 10:44:56 -0700 Subject: Implementation of RIPE-181++ In-Reply-To: <9410041003.AA29592@mature.ripe.net> References: <9410040920.AA07723@reif.ripe.net> <9410041003.AA29592@mature.ripe.net> Message-ID: <199410051744.AA11161@chl.isi.edu> Sorry for a late feedback. I was out sick yesterday. I have three comments: Tony Bates (Tony.Bates at ripe.net) on October 4: > > Daniel Karrenberg writes: > * > Okay, thanks for your changes. I have incorperated them and added a > small note on the slitting ASes. Find below he revised text. > > > --Tony. > > P.S. Today is really the last day to comment before we send this > document out as ripe-181. 1. It is clear from the yesterday's discussion that the interaction of interas-in/out and as-in/out is still not clear. Ripe-181 would hang itself with this document:-( > as-in or as-out policy. When a sub-set is described remember the > remaining routes are implicitly shared across all connections. It is 2. I agree with Jessica. See the example below: as-in: AS1 100 AS100 AS200 interas-in: AS1 L1-R1 (pref=100) NOT AS100 assume there is also another connection called L2-R2. In this case: Global policy: AS100 AS200 Combined local policy: NOT AS100 = ANY setminus AS100 difference: {AS100 AS200} setminus {ANY setminus AS100} = AS100 SURPRISE 1 AS100 is accepted with equal preference on both links. SURPRISE 2 AS200 is not accepted on neither of the links. If this is what is intended, the document is correct, no need for corrections. If this is not what is intended, the document is VERY WRONG. I am afraid this is the case. > The implicit rule that all routes not mentioned in interas policies > are accepted on all links with equal preference ensures the desired > result. 3. What is this preference value. A random number? The value in as-in line? If it is not a random number, document needs to say that. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute cengiz at isi.edu University of Southern California -------- Logged at Wed Oct 5 19:52:53 MET 1994 --------- From cengiz at ISI.EDU Wed Oct 5 19:52:11 1994 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Wed, 5 Oct 1994 11:52:11 -0700 Subject: as-in/out interas-in/out recommendation Message-ID: <199410051852.AA11186@chl.isi.edu> I think it is clear that the interaction of as-in/out and interas-in/out policies is still ambiguous even though all the efforts made in the last couple of weeks. I think there is no simple fix without changing the interaction. Here is a solution which is in the middle of the solutions proposed by different people (marten, tony's original, mine, elise's). Interas-in does not replace as-in. If an as specifies interas-in, it also has to specify as-in. When an as specifies interas-in policy, this interas-in policy is only valid and entered to the dbase if it is a subset of the as-in policy. If there is a L1-R1 connection between two ASs and there is an interas-in policy for this connection, only the interas-in policy apply to this connection. If there is a L1-R1 connection between two ASs and there is NO interas-in policy for this connection, as-in policies apply to this connection. That is, NO IMPLICIT SHARING OF REMAINING ROUTES. Example 1: aut-num: AS1 as-in: from AS2 10 accept AS100 OR {10.0.0.0/8} interas-in: from AS2 L1 R1 (pref=100) accept AS100 interas-in: from AS2 L2 R2 (pref=100) accept AS100 interas-in: from AS2 L3 R3 (pref=100) accept AS100 OR {10.0.0.0/8} derived policies: interas-in: from AS2 L1 R1 (pref=100) accept AS100 interas-in: from AS2 L2 R2 (pref=100) accept AS100 interas-in: from AS2 L3 R3 (pref=100) accept AS100 OR {10.0.0.0/8} Example 2: aut-num: AS1 as-in: from AS2 10 accept AS100 OR {10.0.0.0/8} interas-in: from AS2 L3 R3 (pref=100) accept {10.0.0.0/8} derived policies: interas-in: from AS2 L1 R1 (pref=10) accept AS100 OR {10.0.0.0/8} interas-in: from AS2 L2 R2 (pref=10) accept AS100 OR {10.0.0.0/8} interas-in: from AS2 L3 R3 (pref=100) accept {10.0.0.0/8} Example 3: aut-num: AS1 as-in: from AS2 10 accept AS100 OR {10.0.0.0/8} interas-in: from AS2 L1 R1 (pref=100) accept AS100 interas-in: from AS2 L2 R2 (pref=100) accept AS100 derived policies: interas-in: from AS2 L1 R1 (pref=100) accept AS100 interas-in: from AS2 L2 R2 (pref=100) accept AS100 interas-in: from AS2 L3 R3 (pref=10) accept AS100 OR {10.0.0.0/8} ADVANTAGES: It is simple. It is not ambiguous. If a policy is explicitly stated for a connection it is used as it is. DISADVANTAGES: An AS may have to specify more interas-in policies to specify the same policy. Example 3 above can be done using 1 interas-in line using the implicit sharing. Why is it simple? This is the code: $_ = $polpeers{"$as%$br%i%$peeras%$peerbr"} || $polpeers{"$as%%i%$peeras%"} || "0 NOT ANY"; Very simple, if there is an interas policy use it, if not use the as-in policy, if not use "NOT ANY". Can someone provide code for the interaction in the document? I can not because I beleive the interaction in the document is ambiguous. Even with some assumptions on the ambiguities, I bet the code will turn out more complicated. Regards. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute cengiz at isi.edu University of Southern California -------- Logged at Wed Oct 5 20:11:02 MET 1994 --------- From cengiz at ISI.EDU Wed Oct 5 20:10:45 1994 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Wed, 5 Oct 1994 12:10:45 -0700 Subject: Implementation of RIPE-181++ In-Reply-To: <3409159@toto.iv> References: <9410040920.AA07723@reif.ripe.net> <9410041003.AA29592@mature.ripe.net> Message-ID: <199410051910.AA11195@chl.isi.edu> Below example is wrong since interas-in is not a subset of as-in. Sorry. Cengiz Alaettinoglu (cengiz) on October 5: > 2. I agree with Jessica. See the example below: > > as-in: AS1 100 AS100 AS200 > interas-in: AS1 L1-R1 (pref=100) NOT AS100 > > assume there is also another connection called L2-R2. > > In this case: > Global policy: AS100 AS200 > Combined local policy: NOT AS100 = ANY setminus AS100 > difference: {AS100 AS200} setminus {ANY setminus AS100} = AS100 > > SURPRISE 1 > AS100 is accepted with equal preference on both links. > SURPRISE 2 > AS200 is not accepted on neither of the links. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute cengiz at isi.edu University of Southern California -------- Logged at Wed Oct 5 23:10:00 MET 1994 --------- From dsj at merit.edu Wed Oct 5 23:09:14 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Wed, 5 Oct 1994 18:09:14 -0400 Subject: RIPE-181 code release Message-ID: <199410052209.SAA27585@merit.edu> Marten, We're trying to schedule when we should pick up your release of the Registry Code and upgrade our system to use that as a base. Can you give us any guidance? Is an actual release pending? (I know you've had Rick looking at your development copy for a week or two). Is much likely to change in the near future? (e.g. before Oct 15? Nov 1?) --Dale -------- Logged at Wed Oct 5 23:16:22 MET 1994 --------- From Tony.Bates at ripe.net Wed Oct 5 23:16:13 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Wed, 05 Oct 1994 23:16:13 +0100 Subject: Implementation of RIPE-181++ In-Reply-To: Your message of Wed, 05 Oct 1994 10:44:56 MST. <199410051744.AA11161@chl.isi.edu> Message-ID: <9410052216.AA07249@mature.ripe.net> cengiz at ISI.EDU (Cengiz Alaettinoglu) writes: * * Sorry for a late feedback. I was out sick yesterday. * I have three comments: * * Tony Bates (Tony.Bates at ripe.net) on October 4: * > * > Daniel Karrenberg writes: * > * * > Okay, thanks for your changes. I have incorperated them and added a * > small note on the slitting ASes. Find below he revised text. * > * > * > --Tony. * > * > P.S. Today is really the last day to comment before we send this * > document out as ripe-181. * * * 1. It is clear from the yesterday's discussion that the interaction of * interas-in/out and as-in/out is still not clear. Ripe-181 would * hang itself with this document:-( * Well, perhaps this is a little strong but anyway.... * > as-in or as-out policy. When a sub-set is described remember the * > remaining routes are implicitly shared across all connections. It is * * 2. I agree with Jessica. See the example below: * * as-in: AS1 100 AS100 AS200 * interas-in: AS1 L1-R1 (pref=100) NOT AS100 * * assume there is also another connection called L2-R2. * * In this case: * Global policy: AS100 AS200 * Combined local policy: NOT AS100 = ANY setminus AS100 * difference: {AS100 AS200} setminus {ANY setminus AS100} = AS100 * Well - not quite as the local policy is greater than the global policy and would be not accepted so I am not sure if this is valid. * SURPRISE 1 * AS100 is accepted with equal preference on both links. * SURPRISE 2 * AS200 is not accepted on neither of the links. * * If this is what is intended, the document is correct, no need for * corrections. * * If this is not what is intended, the document is VERY WRONG. I am * afraid this is the case. * Not sure if this applies unless you can find another example. * > The implicit rule that all routes not mentioned in interas policies * > are accepted on all links with equal preference ensures the desired * > result. * * 3. What is this preference value. A random number? The value in as-in * line? * If it is not a random number, document needs to say that. * No - the text is clear - the pref is mapped to a relative value in...see the appendix for more details. I think this is enough. No hanging I hope ;-). --Tony. -------- Logged at Wed Oct 5 23:40:14 MET 1994 --------- From cengiz at ISI.EDU Wed Oct 5 23:39:51 1994 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Wed, 5 Oct 1994 15:39:51 -0700 Subject: Implementation of RIPE-181++ In-Reply-To: <9410052216.AA07249@mature.ripe.net> References: <199410051744.AA11161@chl.isi.edu> <9410052216.AA07249@mature.ripe.net> Message-ID: <199410052239.AA11323@chl.isi.edu> Tony Bates (Tony.Bates at ripe.net) on October 5: > No - the text is clear - the pref is mapped to a relative value > in...see the appendix for more details. I think this is enough. No > hanging I hope ;-). Please yank some text from the appendix. I still can not find this. Would you provide some code to implement this interaction? A code that uses AND/OR/NOT/SETMINUS is acceptable. But no handwaving please. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute cengiz at isi.edu University of Southern California -------- Logged at Thu Oct 6 11:15:02 MET 1994 --------- From Tony.Bates at ripe.net Thu Oct 6 11:14:54 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Thu, 06 Oct 1994 11:14:54 +0100 Subject: Implementation of RIPE-181++ In-Reply-To: Your message of Wed, 05 Oct 1994 15:39:51 MST. <199410052239.AA11323@chl.isi.edu> Message-ID: <9410061014.AA09903@mature.ripe.net> cengiz at ISI.EDU (Cengiz Alaettinoglu) writes: * * Tony Bates (Tony.Bates at ripe.net) on October 5: * > No - the text is clear - the pref is mapped to a relative value * > in...see the appendix for more details. I think this is enough. No * > hanging I hope ;-). * * Please yank some text from the appendix. I still can not find this. * Well - I guess this is the bit you need... .... is defined as follows: (=) It should be noted the parenthesis ``('' and ``)'' and the ``'' keyword must be present for this prefer- ence to be valid. currently only supports "pref". It could be expanded to other type of preference such as TOS/QOS as routing technology matures. can take one of the following values: is a positive integer used to express a rela- tive cost of routes learned. The lower the cost the more preferred the route. This value is only comparable to other interas-in attributes, not to as-in attributes. MED This indicates the AS will use the MUTLI_EXIT_DISCRIMINATOR (MED) metric, as implemented in BGP4 and IDRP, sent from its neighbor AS. NOTE: Combinations of MED and should be avoided for the same destinations. CAVEAT: The pref-type values may well be enhanced in the future as more inter-ASs routing protocols intro- duce other metrics. Any route specified in interas-in and not specified in as-in is assumed not accepted between the ASes concerned. Diagnostic tools should flag this incon- sistency as an error. It should be noted that if an interas-in policy is specified then it is mandatory to specify the corresponding global policy in the as-in line. Please note there is no relevance in the cost associated with as-in and the preferences used in interas-in. is an expression as defined in as-in above. ... While I see there are potentially some small outstanding implementation issues here, I don't think this constitutes enough of a problem to stop this being released a RIPE document today. We can always pick this up in the extensions document which is currently just a place-holder in many ways. --Tony. -------- Logged at Thu Oct 6 17:56:29 MET 1994 --------- From cengiz at ISI.EDU Thu Oct 6 17:53:19 1994 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Thu, 6 Oct 1994 09:53:19 -0700 Subject: Implementation of RIPE-181++ In-Reply-To: <9410061014.AA09903@mature.ripe.net> References: <199410052239.AA11323@chl.isi.edu> <9410061014.AA09903@mature.ripe.net> Message-ID: <199410061653.AA11920@chl.isi.edu> Tony Bates (Tony.Bates at ripe.net) on October 6: > > cengiz at ISI.EDU (Cengiz Alaettinoglu) writes: > * > * Tony Bates (Tony.Bates at ripe.net) on October 5: > * > No - the text is clear - the pref is mapped to a relative value > * > in...see the appendix for more details. I think this is enough. No > * > hanging I hope ;-). > * > * Please yank some text from the appendix. I still can not find this. > * > Well - I guess this is the bit you need... That bit does not answer my question:-( You think it does. What you think of the (pref=some) is different than what Daniel Karrenberg thinks. To me these are the signs of ambiguity. I actually have code waiting for this ambiguity to be resolved. If it is not resolved by this document I will have to implement something which will be obsoleted with an extension document. Or I will have to enforce more constraints on interas policies in RA registry. Regards. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute cengiz at isi.edu University of Southern California -------- Logged at Thu Oct 6 19:24:33 MET 1994 --------- From dsj at merit.edu Thu Oct 6 19:24:28 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Thu, 6 Oct 1994 14:24:28 -0400 Subject: Congratulations Message-ID: <199410061824.OAA10359@merit.edu> All, Congratulations on the release of RIPE-181. I know it has been a long road. --Dale -------- Logged at Fri Oct 7 18:43:54 MET 1994 --------- From cengiz at ISI.EDU Fri Oct 7 18:43:23 1994 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Fri, 7 Oct 1994 10:43:23 -0700 Subject: Ripe 181 Message-ID: <199410071743.AA12199@chl.isi.edu> Hi, I read the final Ripe 181. It looks pretty nice. Congratulations to the authors. I hope that my comments were helpful. Regards. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute cengiz at isi.edu University of Southern California -------- Logged at Fri Oct 7 18:51:33 MET 1994 --------- From Tony.Bates at ripe.net Fri Oct 7 18:51:30 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Fri, 07 Oct 1994 18:51:30 +0100 Subject: Ripe 181 In-Reply-To: Your message of Fri, 07 Oct 1994 10:43:23 MST. <199410071743.AA12199@chl.isi.edu> Message-ID: <9410071751.AA14081@mature.ripe.net> Cengiz, they were and I know we have a small outstanding issue on the interas-in. Can you for my purposes detail the issues for me one last time and lets see if we can get to the bottom of this. Thanks, --Tony. cengiz at ISI.EDU (Cengiz Alaettinoglu) writes: * * Hi, * * I read the final Ripe 181. It looks pretty nice. Congratulations to * the authors. I hope that my comments were helpful. * * Regards. * * Cengiz * * -- * Cengiz Alaettinoglu Information Sciences Institute * cengiz at isi.edu University of Southern California * -------- Logged at Mon Oct 10 20:41:46 MET 1994 --------- From dsj at merit.edu Mon Oct 10 20:41:42 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Mon, 10 Oct 1994 15:41:42 -0400 Subject: Software Release Message-ID: <199410101941.PAA28608@merit.edu> Hi, Is this still the schedule for 181 deployment? We'd like to start porting this. --Dale > Rick, > > It is not packed up or anything just yet (or documented for that > matter) but you can find the stuff on ns.ripe.net. We have set up a > test database with all the latest source in /nccfs3/testdb. It is a > similar setup as the usual database, just with all the new stuff. Few > things that have changed, but you'll have to have a look around to see > how things are now. If you have questions, let me know, I'll try and > answer them. I will pack the stuff up a bit later, there are still > some things not completely implemented or not quite working (minor > things though). > > Our current plan is to switch to the new software 2 weeks from now, > October 13th. Full support for ripe-181 will start November 21st > according to our latest plans. The time in between is time for folks > to get used to the maintainer stuff and for us to keep an eye on the > software, then Nov 21st we will transition to where we want to be. > These are the T1 and T2 times mentioned in the database transition > plans. > > Cheers, > > -Marten -------- Logged at Mon Oct 10 21:08:05 MET 1994 --------- From Tony.Bates at ripe.net Mon Oct 10 21:08:00 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Mon, 10 Oct 1994 21:08:00 +0100 Subject: Software Release In-Reply-To: Your message of Mon, 10 Oct 1994 15:41:42 -0400. <199410101941.PAA28608@merit.edu> Message-ID: <9410102008.AA22390@mature.ripe.net> Yes, We'll have a packed up version later in the week. --Tony. "Dale S. Johnson" writes: * Hi, * * Is this still the schedule for 181 deployment? We'd like to start * porting this. * * --Dale * * * > Rick, * > * > It is not packed up or anything just yet (or documented for that * > matter) but you can find the stuff on ns.ripe.net. We have set up a * > test database with all the latest source in /nccfs3/testdb. It is a * > similar setup as the usual database, just with all the new stuff. Few * > things that have changed, but you'll have to have a look around to see * > how things are now. If you have questions, let me know, I'll try and * > answer them. I will pack the stuff up a bit later, there are still * > some things not completely implemented or not quite working (minor * > things though). * > * > Our current plan is to switch to the new software 2 weeks from now, * > October 13th. Full support for ripe-181 will start November 21st * > according to our latest plans. The time in between is time for folks * > to get used to the maintainer stuff and for us to keep an eye on the * > software, then Nov 21st we will transition to where we want to be. * > These are the T1 and T2 times mentioned in the database transition * > plans. * > * > Cheers, * > * > -Marten -------- Logged at Tue Oct 11 01:32:20 MET 1994 --------- From cengiz at ISI.EDU Tue Oct 11 01:31:37 1994 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Mon, 10 Oct 1994 17:31:37 -0700 Subject: Ripe 181 In-Reply-To: <9410071751.AA14081@mature.ripe.net> References: <199410071743.AA12199@chl.isi.edu> <9410071751.AA14081@mature.ripe.net> Message-ID: <199410110031.AA14540@chl.isi.edu> Tony Bates (Tony.Bates at ripe.net) on October 7: > Cengiz, > they were and I know we have a small outstanding issue on the > interas-in. Can you for my purposes detail the issues for > me one last time and lets see if we can get to the bottom of this. Here it is: Ripe 181 on as-in: from accept is a positive integer used to express a relative cost of routes learned. The lower the cost the more pre- ferred the route. Ripe 181 on interas-in: is defined as follows: (=) can take one of the following values: is a positive integer used to express a rela- tive cost of routes learned. The lower the cost the more preferred the route. This value is only comparable to other interas-in attributes, not to as-in attributes. MED ... Any route specified in interas-in and not specified in as-in is assumed not accepted between the ASes concerned. Diagnostic tools should flag this incon- sistency as an error. It should be noted that if an interas-in policy is specified then it is mandatory to specify the corresponding global policy in the as-in line. Please note THERE IS NO RELEVANCE IN THE COST ASSOCIATED WITH AS-IN AND THE PREFERENCES USED IN INTERAS-IN. There are couple of issues which needs clarification. I will point out through examples. 1) Example topology: AS1 is connected to AS2 through L1 R1, L1 R2. AS1 is connected to AS3 through L1 R3. aut-num: AS1 as-in: from AS2 10 accept AS100 OR AS200 as-in: from AS3 11 accept AS100 OR AS200 consider L1's configuration file (gated's import proto bgp ...) preference for routes of AS100 learned from R1 is 10. preference for routes of AS100 learned from R2 is 10. preference for routes of AS100 learned from R3 is 11. preference for routes of AS200 learned from R1 is 10. preference for routes of AS200 learned from R2 is 10. preference for routes of AS200 learned from R3 is 11. I hope we agree on this. (Some one may suggest to apply a function f to all of these values, which is OK as long as it does not change the ordering.) 2) Example topology: AS1 is connected to AS2 through L1 R1, L1 R2. AS1 is connected to AS3 through L1 R3. aut-num: AS1 as-in: from AS2 10 accept AS100 OR AS200 as-in: from AS3 11 accept AS100 OR AS200 interas-in: from AS2 L1 R1 (pref=100) AS100 consider L1's configuration file (gated's import proto bgp ...) preference for routes of AS100 learned from R1 is 100. preference for routes of AS100 learned from R2: not valid. preference for routes of AS100 learned from R3 is 11. preference for routes of AS200 learned from R1 is XXX. preference for routes of AS200 learned from R2 is XXX. preference for routes of AS200 learned from R3 is 11. The routes with XXX are the excess routes, i.e. specified in as-in but missed in interas-in. The value of XXX is not specified in Ripe181. Literally speaking this means a random value. In one of your examples [Ref 1. below], you have used the value used in the other interas-in statement. Which makes: XXX = 100. Daniel [Ref 2.] suggests it should be greater than any value mentioned in an interas-in statement. Which makes: XXX >= 101. I think there is no need XXX to be relative to the other interas-in cost values. This is because the set of interas-in (AS100) routes and set of excess routes (AS200) are disjoint. There is no need the preference of these routes be comparable. On the other hand, we need to compare the preference of AS200 routes received from AS1 and received from AS2. According to the as-in, we prefer it from AS1. Hence: XXX < 11, XXX = 10 (as-in value). 3. Example topology: AS1 is connected to AS2 through L1 R1. AS1 is connected to AS3 through L1 R3. aut-num: AS1 as-in: from AS2 10 accept AS100 OR AS200 as-in: from AS3 11 accept AS100 OR AS200 interas-in: from AS2 L1 R1 (pref=101) AS100 interas-in: from AS3 L1 R3 (pref=100) AS100 consider L1's configuration file (gated's import proto bgp ...) preference for routes of AS100 learned from R1 is 101. preference for routes of AS100 learned from R3 is 100. preference for routes of AS200 learned from R1 is XXX. preference for routes of AS200 learned from R3 is YYY. Again document does not tell us about XXX and YYY for excess routes (AS200). I think XXX= 10 and YYY= 11. Also note that in this example local preferences contradict the global preferences. In this case, local preference wins? Even though this is probably what is implied, it is not explicit in the document. All that the document says you can not compare as-in cost 10 with interas-in cost 100. Anyway, it is not important which way we go (XXX=100/101/10) as administrator who specify XXX should be VERY VERY CAREFUL with interas-in anyway. But we should agree on it so that it is consistent. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute cengiz at isi.edu University of Southern California References are not important, I am including them anyway: [Ref 1.] Tony Bates (Tony.Bates at ripe.net) on October 4: > aut-num: AS1 > as-in: from AS2 10 accept AS100 OR {10.0.0.0/8} > > Suppose there are three peerings between AS1 and AS2, known as L1- > R1, L2-R2 and L3-R3 respectively. The actual policy of these connec- > tions is to accept AS100 equally on these three links and just route > 10.0.0.0/8 on L3-R3. The simple way to mention this exception is to > just specify an interas policy for L3-R3: > > interas-in: from AS2 L3 R3 (pref=100) accept {10.0.0.0/8} > > > The implicit rule that all routes not mentioned in interas policies > are accepted on all links with equal preference ensures the desired > result. > > The same policy can be written explicitly as: > > interas-in: from AS2 L1 R1 (pref=100) accept AS100 > interas-in: from AS2 L2 R2 (pref=100) accept AS100 > interas-in: from AS2 L3 R3 (pref=100) accept AS100 OR {10.0.0.0/8} [Ref 2.] Daniel Karrenberg (Daniel.Karrenberg at ripe.net) on October 4: > According to the wording it implies: > > interas-in: from AS100 L1 R1 (pref=some) accept AS100 > interas-in: from AS100 L2 R2 (pref=some) accept AS100 > > Where "some" is not explicitly defined by the text but implicitly > greater than all preferences mentioned in interas-in attributes. -------- Logged at Tue Oct 11 04:26:19 MET 1994 --------- From bmanning at ISI.EDU Tue Oct 11 04:24:35 1994 From: bmanning at ISI.EDU (bmanning at ISI.EDU) Date: Mon, 10 Oct 1994 20:24:35 -0700 (PDT) Subject: Ripe 181 In-Reply-To: <199410110031.AA14540@chl.isi.edu> from "Cengiz Alaettinoglu" at Oct 10, 94 05:31:37 pm Message-ID: <199410110324.AA02404@zed.isi.edu> It was always my thought that local preference should override global statements. -- --bill -------- Logged at Tue Oct 11 07:38:09 MET 1994 --------- From Daniel.Karrenberg at ripe.net Tue Oct 11 07:37:39 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 11 Oct 1994 07:37:39 +0100 Subject: Ripe 181 In-Reply-To: Your message of Mon, 10 Oct 1994 20:24:35 MST. <199410110324.AA02404@zed.isi.edu> Message-ID: <9410110637.AA14857@reif.ripe.net> > bmanning at ISI.EDU writes: > > It was always my thought that local preference should override global > statements. Interesting thought. Why should that be so? -------- Logged at Tue Oct 11 13:43:28 MET 1994 --------- From bmanning at ISI.EDU Tue Oct 11 13:41:40 1994 From: bmanning at ISI.EDU (bmanning at ISI.EDU) Date: Tue, 11 Oct 1994 05:41:40 -0700 (PDT) Subject: Ripe 181 In-Reply-To: <9410110637.AA14857@reif.ripe.net> from "Daniel Karrenberg" at Oct 11, 94 07:37:39 am Message-ID: <199410111241.AA02655@zed.isi.edu> ...local overrides global... Well, this is perhaps incorrect. I should perhaps state that local preference should be cast inside global preference. In this case, if I am delegated a /27 mask from a larger /24 mask, I ought to be able to override the preferences of the /24 registration. Something along the lines of BGPs longest match. In the absence of the more specific (local) preference, use the more generic (global) preference. Does this make sense? -- --bill -------- Logged at Tue Oct 11 17:21:38 MET 1994 --------- From postel at ISI.EDU Tue Oct 11 17:21:27 1994 From: postel at ISI.EDU (Jon Postel) Date: Tue, 11 Oct 1994 09:21:27 -0700 Subject: Ripe 181 Message-ID: <199410111621.AA27488@zephyr.isi.edu> Daniel: Local preference over global statements would seem to be implied by the principle of using the longest match. --jon. From dfk at ripe.net Mon Oct 10 23:38:14 1994 To: bmanning at ISI.EDU Cc: cengiz at ISI.EDU (Cengiz Alaettinoglu), Tony.Bates at ripe.net, rr-impl at ripe.net, ra-lcl at ISI.EDU Subject: Re: Ripe 181 From: Daniel Karrenberg X-Organization: RIPE Network Coordination Centre Date: Tue, 11 Oct 1994 07:37:39 +0100 Sender: Daniel.Karrenberg at ripe.net > bmanning at ISI.EDU writes: > > It was always my thought that local preference should override global > statements. Interesting thought. Why should that be so? -------- Logged at Tue Oct 11 20:12:03 MET 1994 --------- From dsj at merit.edu Tue Oct 11 20:11:58 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Tue, 11 Oct 1994 15:11:58 -0400 Subject: Indexing inet-rtr interface numbers? Message-ID: <199410111911.PAA04131@merit.edu> Marten, Tony, We noticed that you're indexing inet-rtr interface numbers. Is this something that we can safely ignore for a little while? (What tools will use this?). --Dale -------- Logged at Tue Oct 11 20:14:24 MET 1994 --------- From Tony.Bates at ripe.net Tue Oct 11 20:14:17 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Tue, 11 Oct 1994 20:14:17 +0100 Subject: Indexing inet-rtr interface numbers? In-Reply-To: Your message of Tue, 11 Oct 1994 15:11:58 -0400. <199410111911.PAA04131@merit.edu> Message-ID: <9410111914.AA25621@mature.ripe.net> prtraceroute the tool we had in mind here. If you want to ignore this that should be fine I guess. --Tony. "Dale S. Johnson" writes: * Marten, Tony, * * We noticed that you're indexing inet-rtr interface numbers. Is this * something that we can safely ignore for a little while? (What tools * will use this?). * * --Dale -------- Logged at Tue Oct 11 20:24:30 MET 1994 --------- From dsj at merit.edu Tue Oct 11 20:24:23 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Tue, 11 Oct 1994 15:24:23 -0400 Subject: Indexing inet-rtr interface numbers? Message-ID: <199410111924.PAA04993@merit.edu> AAh, this was the new way of identifying the correct AS at DMZs, huh? Guess we need it. But I guess we can wait for your release. Thanks. > prtraceroute the tool we had in mind here. If you want to ignore this > that should be fine I guess. > > --Tony. > > "Dale S. Johnson" writes: > * Marten, Tony, > * > * We noticed that you're indexing inet-rtr interface numbers. Is this > * something that we can safely ignore for a little while? (What tools > * will use this?). > * > * --Dale > -------- Logged at Wed Oct 12 16:40:35 MET 1994 --------- From dsj at merit.edu Wed Oct 12 16:40:30 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Wed, 12 Oct 1994 11:40:30 -0400 Subject: The Global Routing Registry Message-ID: <199410121540.LAA19700@merit.edu> Hi, I'm sure you guys are busy rolling out 181, but when you get a moment to breathe... Should we start talking about building the Global Registry: e.g., both of our servers returning both of our data? (Without this, of course, tools like prtraceroute will only work worldwide if run from the Merit server). I'd be interested in talking details with someone on this. On a slightly similar issue: In trying to prepare documentation and presentation, I'm stumbling over names for the Global Registry, and for the various portions therein. "RIPE.db" and "The RIPE Database" are pretty well defined at the moment. "The Global Routing Registry" ("GRR"??) seems pretty well defined intuitively. At the moment, Merit's official (but not very well filled) public routing registry is called "MERITRR", which is the name users have to append to the "source:" line to register something. This name was chosen before we were confirmed as an RA award recipient. We probably should change this to "RADB". We have dumps of the PRDB data (40K route objects, etc) in our local "PRDB.db". These are currently returned by our whois server and should be useful with prtraceroute. We expect this database will be either frozen or retired in April '95. Do you all ready have canonical names for these database components? If not, what do you think of: "Global Routing Registry" and "Routing Registry DataBase" ("RRDB") for the whole worldwide one? "RIPE" and "RA" ("RIPE.db" and "RA.db") for the names of the specific pieces that are running now. (and "PRDB"/"PRDB.db"). Similar names for new players. ? --Dale -------- Logged at Thu Oct 13 08:34:34 MET 1994 --------- From Marten.Terpstra at ripe.net Thu Oct 13 08:34:31 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Thu, 13 Oct 1994 08:34:31 +0100 Subject: Status of Marten's release (fwd) In-Reply-To: Your message of Wed, 12 Oct 1994 14:54:15 -0400. <199410121854.OAA05648@merit.edu> Message-ID: <9410130734.AA18763@rijp.ripe.net> Folks, as you know, today is the switch over for the RIPE database software here. This means I am going to be busy installing the stuff for production. Plan (and urgent request from Daniel and others) is to have some sort of packed up version by this weekend (so much for a weekend off ;-) -Marten Laurent Joncheray writes * Hi, can i have access to the new DB code? Thanks! * * Laurent * * PS: My old account on mature.ripe.net does not work anymore. * * > It is not packed up or anything just yet (or documented for that * > matter) but you can find the stuff on ns.ripe.net. We have set up a * > test database with all the latest source in /nccfs3/testdb. It is a * > similar setup as the usual database, just with all the new stuff. Few * > things that have changed, but you'll have to have a look around to see * > how things are now. If you have questions, let me know, I'll try and * > answer them. I will pack the stuff up a bit later, there are still * > some things not completely implemented or not quite working (minor * > things though). * > * > Our current plan is to switch to the new software 2 weeks from now, * > October 13th. Full support for ripe-181 will start November 21st * > according to our latest plans. The time in between is time for folks * > to get used to the maintainer stuff and for us to keep an eye on the * > software, then Nov 21st we will transition to where we want to be. * > These are the T1 and T2 times mentioned in the database transition * > plans. * > * > Cheers, * > * > -Marten * > * > -------- * > * > > From: "Dale S. Johnson" * > > To: lpj, rlr * > * > > Rick, Laurent, * > > * > > Do either of you know anything about the status of Marten's code relea * se? * > > (He is on vacation this week). * > > * > > --Dale * > * * * -- * 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 Fri Oct 21 20:11:51 MET 1994 --------- From cengiz at ISI.EDU Fri Oct 21 20:11:33 1994 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Fri, 21 Oct 1994 12:11:33 -0700 Subject: misleading diagnostic In-Reply-To: <199410211848.OAA07104@toad.merit.edu> References: <9410211307.AA27708@reif.ripe.net> <199410211848.OAA07104@toad.merit.edu> Message-ID: <199410211911.AA19222@chl.isi.edu> Rick Riolo (rlr at merit.edu) on October 21: > I have changed our conf file to have the rv's rather than rt's in the rs-view object, > and things seem to be behaving better. I can add distinct objects with keys that > are like those shown below (ie an dns address, a blank, and a number), > and I can retrieve them. Note that, however, that the retrieval with value after > the blank in the key retrieves both, but the retrieval with the number just gets > the one object. > > at any rate, I think this will server cengiz's needs, since I think he > will be adding a number to all of these if there are more than one. > is that right, cengiz? > I will just use some other seperator, perhaps a "-". > - r > > ps This works with regular whois -- -S as well, of course. > > > toad.merit.edu> /f/rrdb/dbase-beta/bin/whois -h toad -s TESTRR rs900.tra.net > rs-view: rs900.tra.net 300 > descr: Policies for view 3 of Route Server rs2.ra.net > as-in: from AS1239 0 accept NOT ANY > tech-c: elise gerich > admin-c: bill manning > guardian: bmanning at isi.edu > remarks: This entry is created by RA analysis software. > mnt-by: acts-of-god > changed: cengiz at isi.edu 940919 > changed: rlr at merit.edu 941021 > source: TESTRR > > rs-view: rs900.tra.net > descr: Policies for view 3 of Route Server rs2.ra.net > as-in: from AS1239 0 accept NOT ANY > tech-c: elise gerich > admin-c: bill manning > guardian: bmanning at isi.edu > remarks: This entry is created by RA analysis software. > mnt-by: acts-of-god > changed: cengiz at isi.edu 940919 > changed: rlr at merit.edu 941021 > source: TESTRR > > toad.merit.edu> /f/rrdb/dbase-beta/bin/whois -h toad -s TESTRR rs900.tra.net 300 > rs-view: rs900.tra.net 300 > descr: Policies for view 3 of Route Server rs2.ra.net > as-in: from AS1239 0 accept NOT ANY > tech-c: elise gerich > admin-c: bill manning > guardian: bmanning at isi.edu > remarks: This entry is created by RA analysis software. > mnt-by: acts-of-god > changed: cengiz at isi.edu 940919 > changed: rlr at merit.edu 941021 > source: TESTRR > > toad.merit.edu> > > -------- > > > From: Daniel Karrenberg > > To: Rick Riolo > > CC: cengiz at isi.edu (Cengiz Alaettinoglu), rr-impl at ripe.net > > > > > > Rick Riolo writes: > > > Daniel, > > > thanks for looking at that and noticing those problems. it didn't really h > > > ave anything > > > to do with reading or not reading the comments: I just cut, pasted and edi > > > ted another object, > > > probably rt, given the things you pointed out that I forgot to change! > > > > RT.M! ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) :-) > > > > > re REC, I don't think we will be storing records for ac and tc. (Dale?...) > > > If we don't, should we just not include the OBJ x REC line at all? > > > > I'd leave it in as a placeholder. > > > > > Am I right in thinking that the 'default' parsing in ripe81 just stops > > > at a blank, which lead to the problem cengiz observed? > > > > I don't think so although I am not absolutely sure without digging into the > > code. > > > > The problem is that the unique key identifying the object was generated > > from the "rt" attribute which probably was not present since it is not > > even allowed in "rv". Therefore the keys were equal, therefore the > > objects were equal, therefore they updated each other. > > > > Try putting rt in and see. > > > > > > Daniel Cengiz -- Cengiz Alaettinoglu Information Sciences Institute cengiz at isi.edu University of Southern California -------- Logged at Fri Oct 21 23:08:24 MET 1994 --------- From Marten.Terpstra at ripe.net Fri Oct 21 23:08:16 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Fri, 21 Oct 1994 23:08:16 +0100 Subject: misleading diagnostic In-Reply-To: Your message of Fri, 21 Oct 1994 14:48:19 -0400. <199410211848.OAA07104@toad.merit.edu> Message-ID: <9410212208.AA29982@rijp.ripe.net> Rick Riolo writes * I have changed our conf file to have the rv's rather than rt's in the rs-vie * w object, * and things seem to be behaving better. I can add distinct objects with keys * that * are like those shown below (ie an dns address, a blank, and a number), * and I can retrieve them. Note that, however, that the retrieval with value a * fter * the blank in the key retrieves both, but the retrieval with the number just * gets * the one object. Yep, if the whoisd gets multiple words as keys to look for, it will only display the objects that match all keys (ie the intersection of the individual results). -Marten -------- Logged at Sat Oct 22 05:13:52 MET 1994 --------- From Daniel.Karrenberg at ripe.net Sat Oct 22 05:13:44 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Sat, 22 Oct 1994 05:13:44 +0100 Subject: misleading diagnostic In-Reply-To: Your message of Fri, 21 Oct 1994 14:48:19 -0400. <199410211848.OAA07104@toad.merit.edu> Message-ID: <9410220413.AA28269@reif.ripe.net> > Rick Riolo writes: > I have changed our conf file to have the rv's rather than rt's in the rs-vi > ew object, > and things seem to be behaving better. I can add distinct objects with key > s that > are like those shown below (ie an dns address, a blank, and a number), > and I can retrieve them. Just like it ought to work. > Note that, however, that the retrieval with value > after the blank in the key retrieves both >but the retrieval with the number just gets the one object. This is not what the example below shows. The example shows correct behaviour: Each white space separated word in the attribute constitutes a key. On queries an object has to match all keys specified. So if you specify "rs900.tra.net" all objects with this key will be found. If you specify "rs900.tra.net" and "300" all objects with both those keys will match. Order does not matter. Qerying for "300" works likewise. Network numebrs are special. > at any rate, I think this will server cengiz's needs, since I think he > will be adding a number to all of these if there are more than one. OK. I hope we get credit for this. ;-) > > > toad.merit.edu> /f/rrdb/dbase-beta/bin/whois -h toad -s TESTRR rs900.tra.ne > t > rs-view: rs900.tra.net 300 > descr: Policies for view 3 of Route Server rs2.ra.net > as-in: from AS1239 0 accept NOT ANY > tech-c: elise gerich > admin-c: bill manning > guardian: bmanning at isi.edu > remarks: This entry is created by RA analysis software. > mnt-by: acts-of-god > changed: cengiz at isi.edu 940919 > changed: rlr at merit.edu 941021 > source: TESTRR > > rs-view: rs900.tra.net > descr: Policies for view 3 of Route Server rs2.ra.net > as-in: from AS1239 0 accept NOT ANY > tech-c: elise gerich > admin-c: bill manning > guardian: bmanning at isi.edu > remarks: This entry is created by RA analysis software. > mnt-by: acts-of-god > changed: cengiz at isi.edu 940919 > changed: rlr at merit.edu 941021 > source: TESTRR > > toad.merit.edu> /f/rrdb/dbase-beta/bin/whois -h toad -s TESTRR rs900.tra.ne > t 300 > rs-view: rs900.tra.net 300 > descr: Policies for view 3 of Route Server rs2.ra.net > as-in: from AS1239 0 accept NOT ANY > tech-c: elise gerich > admin-c: bill manning > guardian: bmanning at isi.edu > remarks: This entry is created by RA analysis software. > mnt-by: acts-of-god > changed: cengiz at isi.edu 940919 > changed: rlr at merit.edu 941021 > source: TESTRR > > toad.merit.edu> -------- Logged at Sat Oct 22 05:19:33 MET 1994 --------- From Daniel.Karrenberg at ripe.net Sat Oct 22 05:19:31 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Sat, 22 Oct 1994 05:19:31 +0100 Subject: misleading diagnostic In-Reply-To: Your message of Fri, 21 Oct 1994 12:11:33 MST. <199410211911.AA19222@chl.isi.edu> Message-ID: <9410220419.AA28300@reif.ripe.net> > cengiz at ISI.EDU (Cengiz Alaettinoglu) writes: > > I will just use some other seperator, perhaps a "-". That works too. It has the nice side effect of keeping the index smaller as well. If you do not need to retrieve all views for a box in one query this is to be preferred. If you need to retrieve all views without knowing the "numbers", the other representation provides that. Daniel -------- Logged at Tue Oct 25 17:35:50 MET 1994 --------- From dsj at merit.edu Tue Oct 25 17:35:45 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Tue, 25 Oct 1994 12:35:45 -0400 Subject: Diagnostics from 181 analysis tool Message-ID: <199410251635.MAA12037@merit.edu> Daniel, (others), FYI, here are some interesting results Cengiz and Andy got from running their analysis tool over the RIPE db. This kind of analysis could be included in prcheck, and even in syntax.pl ("Warning: this policy evaluates to 'ANY'!") Neat stuff! --Dale > From cengiz at ISI.EDU Fri Oct 21 19:50:41 1994 > Date: Fri, 21 Oct 1994 16:50:27 -0700 > To: ra-team at ISI.EDU > Subject: preliminary results from peval > > > I have partially tested the partial evaluator. > Remember the examples which I picked from Ripe database with ambiguous > use of AND/OR/NOT. > Here are the results of partial evaluation on these examples: > > peval NOT AS1729 AS1741 AS1755 > Evaluates to: > (NOT(1729 )) > > peval NOT \(AS701 AND AS174 AND AS1133 AND AS1800 AND AS2044\) > Evaluates to: > ANY > > peval AS690 AS1103 AND NOT \(AS1133 AND AS1800 AND AS286 AND AS1890\) > Evaluates to: > ((690 1103 )) > > peval AS2125 NOT \(AS286 AND AS517\) > Evaluates to: > ANY > > peval ANY AND NOT \(AS286 AS3 AS8 AS17 AS19 AS22 AS3673\) > Evaluates to: > (NOT(3 8 17 19 22 286 3673 )) > > I think one use of this tool should be to partially evaluate and > return the result back to users when new policies are entered. This > way they can detect their mistakes. > > Cengiz & Andy > > -- > Cengiz Alaettinoglu Information Sciences Institute > cengiz at isi.edu University of Southern California -------- Logged at Tue Oct 25 20:27:44 MET 1994 --------- From Marten.Terpstra at ripe.net Tue Oct 25 20:27:36 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Tue, 25 Oct 1994 20:27:36 +0100 Subject: Diagnostics from 181 analysis tool In-Reply-To: Your message of Tue, 25 Oct 1994 12:35:45 -0400. <199410251635.MAA12037@merit.edu> Message-ID: <9410251927.AA01839@rijp.ripe.net> * > I have partially tested the partial evaluator. * > Remember the examples which I picked from Ripe database with ambiguous * > use of AND/OR/NOT. * > Here are the results of partial evaluation on these examples: * > * > peval NOT AS1729 AS1741 AS1755 * > Evaluates to: * > (NOT(1729 )) Well, I do not know. Doesn't this say: AS1741 OR AS1755 OR NOT AS1729 In which case the OR NOT AS1729 is superfluous ... * > peval NOT \(AS701 AND AS174 AND AS1133 AND AS1800 AND AS2044\) * > Evaluates to: * > ANY Not true. What f there is a route orginating in all these ASes? It should be denied ..... * > * > peval AS690 AS1103 AND NOT \(AS1133 AND AS1800 AND AS286 AND AS1890\) * > Evaluates to: * > ((690 1103 )) Same here ... * > * > peval AS2125 NOT \(AS286 AND AS517\) * > Evaluates to: * > ANY And the same here. A route can be originated in AS286 and AS517 and then should be denied .... * > peval ANY AND NOT \(AS286 AS3 AS8 AS17 AS19 AS22 AS3673\) * > Evaluates to: * > (NOT(3 8 17 19 22 286 3673 )) True. -Marten -------- Logged at Tue Oct 25 22:03:40 MET 1994 --------- From dsj at merit.edu Tue Oct 25 22:03:29 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Tue, 25 Oct 1994 17:03:29 -0400 Subject: Groups running RIPE-181 Message-ID: <199410252103.RAA04998@merit.edu> FYI: Here is a list of who I understand to be running copies of RIPE-181 (or planning to): RIPE - obviously RA - Laurent has running now, and has just hit the "indexing PRDB.db" bug. CA*NET - up and running now. MCI - ?? Are they a part of the Global Registry, or a local copy only? ALTERNET - Andrew's internal dabase. Part of the Global Routing Registry? SURANET - going to run their own DSI - going to run their own to do DSI configurations APNIC - intends to DANTE - intends to? [Its not clear the RADB will have very many entries at this point!] ------------ Comments: 1) Wow! 2) There is really some work to be done to integrate these various streams of data. There is probably also some work to do to handle cross-DB checking ["sorry; that net has been registered in the MCI database"] and object reference ["NSFAUP" community is defined only in RADB, but available in all the DBs]. --Dale -------- Logged at Wed Oct 26 18:27:40 MET 1994 --------- From cengiz at ISI.EDU Wed Oct 26 18:26:52 1994 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Wed, 26 Oct 1994 10:26:52 -0700 Subject: misleading diagnostic In-Reply-To: <9410220413.AA28269@reif.ripe.net> References: <199410211848.OAA07104@toad.merit.edu> <9410220413.AA28269@reif.ripe.net> Message-ID: <199410261726.AA20914@chl.isi.edu> Thank you all for solving this. Daniel Karrenberg (Daniel.Karrenberg at ripe.net) on October 22: > > at any rate, I think this will server cengiz's needs, since I think he > > will be adding a number to all of these if there are more than one. > > OK. I hope we get credit for this. ;-) Cengiz -- Cengiz Alaettinoglu Information Sciences Institute cengiz at isi.edu University of Southern California -------- Logged at Thu Oct 27 01:26:50 MET 1994 --------- From cengiz at ISI.EDU Thu Oct 27 01:26:10 1994 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Wed, 26 Oct 1994 17:26:10 -0700 Subject: Diagnostics from 181 analysis tool In-Reply-To: <9410251927.AA01839@rijp.ripe.net> References: <199410251635.MAA12037@merit.edu> <9410251927.AA01839@rijp.ripe.net> Message-ID: <199410270026.AA21020@chl.isi.edu> Marten Terpstra (Marten.Terpstra at ripe.net) on October 25: > > * > I have partially tested the partial evaluator. > * > Remember the examples which I picked from Ripe database with ambiguous > * > use of AND/OR/NOT. > * > Here are the results of partial evaluation on these examples: > * > > * > peval NOT AS1729 AS1741 AS1755 > * > Evaluates to: > * > (NOT(1729 )) > > Well, I do not know. Doesn't this say: > > AS1741 OR AS1755 OR NOT AS1729 > > In which case the OR NOT AS1729 is superfluous ... My first thoughts: Actually AS1741 and AS1755 are superfluous since they are included in NOT AS1729 (see the example in Ripe-181). My second thoughts after your explanation for "AND": "AS1741 OR AS1755 OR NOT AS1729" can not be further simplified because either "AS1741 AND AS1729" or "AS1755 AND AS1729" may be non-empty. Hence the example in Ripe-181 is wrong. I think when Tony wrote that text, the route-AS relation was still many to 1. > > * > peval NOT \(AS701 AND AS174 AND AS1133 AND AS1800 AND AS2044\) > * > Evaluates to: > * > ANY > > Not true. What f there is a route orginating in all these ASes? It > should be denied ..... You are right. That is "AS701 AND AS174" may not be empty since the route-AS relation is now many to many (i.e. a route may belong to more than one AS). Actually I was under the impression that a route belonged to one AS till last Sunday when I talk to Dale and Rick on this. Dale told me that new text was added recently for this. And I have been reading only the appendices in the last few versions of Ripe-181. peval can handle this form of evaluation as well. We will evaluate ASnumbers symbolicly (just like macros and community names) until level 4 where everything become network lists. Thanks, Cengiz -- Cengiz Alaettinoglu Information Sciences Institute cengiz at isi.edu University of Southern California -------- Logged at Thu Oct 27 15:14:18 MET 1994 --------- From dsj at merit.edu Thu Oct 27 15:14:13 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Thu, 27 Oct 1994 10:14:13 -0400 Subject: Diagnostics from 181 analysis tool Message-ID: <199410271414.KAA04833@merit.edu> >From the text description of the Route Object (ripe-181 5. p12): "Special cases: There can only be a single orginating AS in each route object. However in today's Internet sometimes a route is injected by more than one AS. This situation is potentially dangerous as it can create conflicting routing policies for that route and requires coordination between the originating ASes. In the routing registry this is represented by multiple route objects. This is a departure from the one route (net), one AS principle of the RIPE-81 routing registry. The consequences for the different tools based in the routing registry will need to be evaluated and possibly additional consistency checking of the database is needed." As far as I have been able to figure (and I've raised this before on this list) there are only three situations where a single Route will be mapped to more than one AS: 1) A Proxy Aggregate is being created simultaneously by too peers of an AS or of a region. 2) One (or more) of the "identical" aggregates is marked "withdrawn" (e.g. something once announced by ASX has moved to ASY; ASX continues to register it with the "withdrawn" attribute for historical documentation.) 3) There is a detectable mistake in the database (not entirely unlikely while we work out the complications of multiple geographically dispersed portions of the Global Routing Registry). Can we all agree that "withdrawn" routes should be specifically excluded from all normal policy analysis and configuration file generation? That eliminates condition #2. I think we should also eliminate consideration of #3: This kind of problem needs to be solved, but not by the analysis tools or config file generators. That leaves only condition #1: dual proxy aggregation. Assume ASA and ASB are creating proxy aggregate P for their neighbor ASC. Any policy specifying "ASA OR ASB" will get P. Any policy specifying "NOT( ASA OR ASB )" will not get P. Neither of these cases is troublesome. Any policy specifying "ASA AND ASB" will select *only* those Proxy Aggregates being created by both ASA and ASB. Any policy specifying "ASA AND NOT ASB" will select ASA, setminus the shared proxy aggregate P. These are *only* useful when someone specifically wants to detect the situation of dual proxy aggregation, and to tailor his policy around that situation. Proposal: --------- How about if we keep the problem of Dual Proxy Aggregation in mind, and prepare to change our code to deal with it sometime in the future when we figure out what is really needed to handle it. But for the time being, unless somebody can find holes in the arguments above, I'd say we continue to code config file generators (and Route Servers) assuming that users will either be willing to accept *all* versions of a Proxy Aggregate, or that they will want none of them. We can even detect the few expressions that are probably empty (ASA AND ASanything_else) and issue warnings. We *do* need options in the parser to handle these cases, so we can do analysis on them later. But for the normal applications lets postpone this complicating factor, and support a level of analysis where ASA AND ASB --> NULL. Have I goofed in this analysis? --Dale =========================================================================== > > Marten Terpstra (Marten.Terpstra at ripe.net) on October 25: > > > > * > I have partially tested the partial evaluator. > > * > Remember the examples which I picked from Ripe database with ambiguous > > * > use of AND/OR/NOT. > > * > Here are the results of partial evaluation on these examples: > > * > > > * > peval NOT AS1729 AS1741 AS1755 > > * > Evaluates to: > > * > (NOT(1729 )) > > > > Well, I do not know. Doesn't this say: > > > > AS1741 OR AS1755 OR NOT AS1729 > > > > In which case the OR NOT AS1729 is superfluous ... > > My first thoughts: > Actually AS1741 and AS1755 are superfluous since they are included in > NOT AS1729 (see the example in Ripe-181). > > My second thoughts after your explanation for "AND": > "AS1741 OR AS1755 OR NOT AS1729" can not be further simplified because > either "AS1741 AND AS1729" or "AS1755 AND AS1729" may be non-empty. > > Hence the example in Ripe-181 is wrong. > I think when Tony wrote that text, the route-AS relation was still many > to 1. > > > > > * > peval NOT \(AS701 AND AS174 AND AS1133 AND AS1800 AND AS2044\) > > * > Evaluates to: > > * > ANY > > > > Not true. What f there is a route orginating in all these ASes? It > > should be denied ..... > > You are right. That is "AS701 AND AS174" may not be empty since the > route-AS relation is now many to many (i.e. a route may belong to more > than one AS). > > Actually I was under the impression that a route belonged to one AS > till last Sunday when I talk to Dale and Rick on this. Dale told me > that new text was added recently for this. And I have been reading only > the appendices in the last few versions of Ripe-181. > > peval can handle this form of evaluation as well. We will evaluate > ASnumbers symbolicly (just like macros and community names) until > level 4 where everything become network lists. > > Thanks, > > Cengiz > > -- > Cengiz Alaettinoglu Information Sciences Institute > cengiz at isi.edu University of Southern California > > -------- Logged at Thu Oct 27 22:31:39 MET 1994 --------- From lpj at merit.edu Thu Oct 27 22:31:33 1994 From: lpj at merit.edu (Laurent Joncheray) Date: Thu, 27 Oct 1994 17:31:33 -0400 (EDT) Subject: PGP implementation in the RIPE DB software Message-ID: <199410272131.RAA10116@merit.edu> I've ported PGP into the RIPE DB software has an authentification method for the maitainer stuff. Here is a summary of what i did so far. If you're interested in that work and want me to include my extention into the RIPE DB software please let me know. It's working and really easy to use. -- Laurent PS: all files available on request. ----------------------------------------------------------------------------- PGP implementation in the RIPE software. Summary. lpj. 10/27/94 Authentication of the maintainer using pgp is defined by the 'auth' attribute. The value is 'PGP-FROM '. Example: mntner: LPJ descr: The Boss admin-c: DK58 tech-c: MT2 tech-c: TB230 upd-to: lpj at merit.edu mnt-nfy: lpj at merit.edu auth: PGP-FROM lpj at merit.edu mnt-by: LPJ changed: lpj at merit.edu 941026 The user 'lpj at merit.edu' should have registered is pgp public key in the RR. He should signe all updated sent by mail to the RR with his secret key. Implementation: The mail is piped through two processes: 'pgp.pl' and 'dbupdate. 'dbupdate' is the RIPE tool to process updated from the mail. 'pgp.pl' is a perl script which checks the validity of the signature and 'unsignes' the mail. If the signature is ok pgp.pl add a new line in the mail header with the user ID of the pgp certifyed sender. It also add an error code. For example after processing by pgp.pl the mail looks like: From: Laurent Joncheray Subject: test 26 To: lpj at fox.merit.edu Date: Thu, 27 Oct 1994 13:00:04 -0400 (EDT) X-pgp-signature: lpj at merit.edu X-pgp-error: 0 [...] All the pgp envelop has been stripped. pgp.pl reads the signed mail from std in and writes the unsigned mail to std out. The dbupdate tool authenticates the maintainer by comparing the 'X-pgp-signature' line with the PGP user ID provided in the auth attribute of the maintainer object. How to generate a secret/public key C.f. [PGP]. Sum up: use 'pgp -kg' How to register a public key C.f. [PGP]. Sum up: generate the public key from you key ring by using 'pgp -kxa '. Send to the RR manager. The RR call the user to check the public key (with the key's fingerprint) and certify it. A.O.B The RR needs to agree on who owns the public keys (Here it's the user id under which dbupdate is run). Files: src/syntax.pl: hacked version to support the PGP-FROM authentication method. src/maintainer.pl: hacked version to support the PGP-FROM authentication method. src/pgp.pl: the PGP mail filter. src/dbupdate.sh: a sh script which pipes the mail through pgp.pl and dbupdate[.pl] doc/ripe-120++.txt: modified version of ripe-120.txt with support of the PGP-FROM method README.PGP: this file References: [PGP] MIT PGP 2.6.1, ftp://net-dist.mit.edu/pub/PGP/README :-) -------- Logged at Fri Oct 28 17:50:14 MET 1994 --------- From epg at merit.edu Fri Oct 28 17:49:59 1994 From: epg at merit.edu (Elise Gerich) Date: Fri, 28 Oct 1994 12:49:59 -0400 (EDT) Subject: PGP implementation in the RIPE DB software In-Reply-To: <199410272131.RAA10116@merit.edu> from "Laurent Joncheray" at Oct 27, 94 05:31:33 pm Message-ID: <199410281650.MAA23370@merit.edu> Laurent, This is great news! --Elise >Laurent Joncheray writes: > > I've ported PGP into the RIPE DB software has an authentification > method for the maitainer stuff. Here is a summary of what i did so far. > If you're interested in that work and want me to include my extention > into the RIPE DB software please let me know. It's working and really > easy to use. > -- > Laurent > > PS: all files available on request. > > ----------------------------------------------------------------------------- > > PGP implementation in the RIPE software. Summary. > lpj. 10/27/94 > > Authentication of the maintainer using pgp is defined by > the 'auth' attribute. The value is 'PGP-FROM '. Example: > > mntner: LPJ > descr: The Boss > admin-c: DK58 > tech-c: MT2 > tech-c: TB230 > upd-to: lpj at merit.edu > mnt-nfy: lpj at merit.edu > auth: PGP-FROM lpj at merit.edu > mnt-by: LPJ > changed: lpj at merit.edu 941026 > > The user 'lpj at merit.edu' should have registered is pgp public > key in the RR. He should signe all updated sent by mail to the RR with > his secret key. > > Implementation: > > The mail is piped through two processes: 'pgp.pl' and 'dbupdate. > 'dbupdate' is the RIPE tool to process updated from the mail. 'pgp.pl' > is a perl script which checks the validity of the signature and > 'unsignes' the mail. If the signature is ok pgp.pl add a new line in > the mail header with the user ID of the pgp certifyed sender. It also > add an error code. For example after processing by pgp.pl the mail looks > like: > > From: Laurent Joncheray > Subject: test 26 > To: lpj at fox.merit.edu > Date: Thu, 27 Oct 1994 13:00:04 -0400 (EDT) > X-pgp-signature: lpj at merit.edu > X-pgp-error: 0 > > [...] > > All the pgp envelop has been stripped. pgp.pl reads the signed mail from > std in and writes the unsigned mail to std out. The dbupdate tool > authenticates the maintainer by comparing the 'X-pgp-signature' line with > the PGP user ID provided in the auth attribute of the maintainer object. > > How to generate a secret/public key > > C.f. [PGP]. Sum up: use 'pgp -kg' > > How to register a public key > > C.f. [PGP]. Sum up: generate the public key from you key ring > by using 'pgp -kxa '. > Send to the RR manager. > The RR call the user to check the public key (with the key's fingerprint) > and certify it. > > A.O.B > The RR needs to agree on who owns the public keys (Here it's the > user id under which dbupdate is run). > > Files: > src/syntax.pl: hacked version to support the PGP-FROM authentication > method. > src/maintainer.pl: hacked version to support the PGP-FROM > authentication method. > src/pgp.pl: the PGP mail filter. > src/dbupdate.sh: a sh script which pipes the mail through pgp.pl > and dbupdate[.pl] > doc/ripe-120++.txt: modified version of ripe-120.txt with support of > the PGP-FROM method > README.PGP: this file > > References: > > [PGP] MIT PGP 2.6.1, ftp://net-dist.mit.edu/pub/PGP/README :-) > > -------- Logged at Tue Nov 1 18:25:58 MET 1994 --------- From dsj at merit.edu Thu Oct 13 13:42:37 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Thu, 13 Oct 1994 08:42:37 -0400 Subject: Status of Marten's release (fwd) Message-ID: <199410131242.IAA04156@merit.edu> Good Luck for a easy install, Marten! And congratulations! --Dale > Folks, > > as you know, today is the switch over for the RIPE database software > here. This means I am going to be busy installing the stuff for > production. Plan (and urgent request from Daniel and others) is to > have some sort of packed up version by this weekend (so much for a > weekend off ;-) > > -Marten -------- Logged at Thu Oct 13 17:50:00 MET 1994 --------- From Daniel.Karrenberg at ripe.net Thu Oct 13 17:49:50 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 13 Oct 1994 17:49:50 +0100 Subject: Ripe 181 In-Reply-To: Your message of Mon, 10 Oct 1994 17:31:37 MST. <199410110031.AA14540@chl.isi.edu> Message-ID: <9410131649.AA17420@reif.ripe.net> > cengiz at ISI.EDU (Cengiz Alaettinoglu) writes: Cengiz, Sorry for the late reply. I was too busy to take the time to re-think this properly and write down an answer. But now here goes: The as-in attributes define an ordered list of peerings: - per route accepted - per peer AS The interas-in attributes *refine* this list - per route accepted - per peer AS - per external peering Thus (as you rightly note) it does not make sense to compare preferences between different routes (ASes) accepted. It also does not make sense to compare local (interas-in) preferences between different peer ASes! The preferences between the peers are defined in as-in. The local preferences only differentiate between different peerings to the same AS. A suitable algorithm to derive gated preferences would be for all ASes referenced in as-in attributes build an ordered list of peers by preference for all ASes referenced in interas-in attributes ERROR if ordered list for route cannot be found replace the peer entry in the ordered list above by an ordered list of peering sessions to this peer for all ordered lists thus generated output preference statements with increasing integers per list element - for any specific peering mentioned - for all peerings to the neighbor if no specific peering is mentioned > 2) > Example topology: > AS1 is connected to AS2 through L1 R1, L1 R2. > AS1 is connected to AS3 through L1 R3. > > aut-num: AS1 > as-in: from AS2 10 accept AS100 OR AS200 Makes lists: AS100: AS2 AS200: AS2 > as-in: from AS3 11 accept AS100 OR AS200 AS100: AS2 AS3 AS200: AS2 AS3 > interas-in: from AS2 L1 R1 (pref=100) AS100 AS100: AS2/L1R1 AS3 AS200: AS2 AS3 > preference for routes of AS100 learned from R1 is 100. > preference for routes of AS100 learned from R2: not valid. > preference for routes of AS100 learned from R3 is 11. > preference for routes of AS200 learned from R1 is XXX. > preference for routes of AS200 learned from R2 is XXX. > preference for routes of AS200 learned from R3 is 11. preference for routes of AS100 learned from R1 1 preference for routes of AS100 learned from R3 2 preference for routes of AS200 learned from R1 1 preference for routes of AS200 learned from R2 1 preference for routes of AS200 learned from R3 2 > The value of XXX is not specified in Ripe181. Literally speaking this > means a random value. ripe-181 says that the preferences are equal across all peerings to the sam neighbor and consistent with as-in (global) policy. In this case the preference value in interas-in is not relevant and can be undefined. This does not mean that a configuration tool cannot derive an appropriate value depending on the output language. > In one of your examples [Ref 1. below], you have used > the value used in the other interas-in statement. Which makes: > XXX = 100. > Daniel [Ref 2.] suggests it should be greater than any value mentioned > in an interas-in statement. Which makes: > XXX >= 101. My brain was disengaged when I wrote this and it fell into the same trap as Cengiz. The value is immaterial > On the other hand, we need to compare the preference of AS200 routes > received from AS1 and received from AS2. According to the as-in, we > prefer it from AS1. Hence: > XXX < 11, XXX = 10 (as-in value). Indeed, see above. > 3. > Example topology: > AS1 is connected to AS2 through L1 R1. > AS1 is connected to AS3 through L1 R3. > > aut-num: AS1 > as-in: from AS2 10 accept AS100 OR AS200 AS100: AS2 AS200: AS2 > as-in: from AS3 11 accept AS100 OR AS200 AS100: AS2 AS3 AS200: AS2 AS3 > interas-in: from AS2 L1 R1 (pref=101) AS100 AS100: AS2/L1R1 AS3 AS200: AS2 AS3 > interas-in: from AS3 L1 R3 (pref=100) AS100 AS100: AS2/L1R1 AS3/L1R3 AS200: AS2 AS3 > consider L1's configuration file (gated's import proto bgp ...) > preference for routes of AS100 learned from R1 is 101. > preference for routes of AS100 learned from R3 is 100. > preference for routes of AS200 learned from R1 is XXX. > preference for routes of AS200 learned from R3 is YYY. preference for routes of AS100 learned from R1 1 preference for routes of AS100 learned from R3 2 preference for routes of AS200 learned from R1 1 preference for routes of AS200 learned from R3 2 > Again document does not tell us about XXX and YYY for excess routes > (AS200). I think XXX= 10 and YYY= 11. Which is not necessary. > Also note that in this example local preferences contradict the global > preferences. The way this is defined they cannot. Daniel -------- Logged at Thu Oct 13 18:00:59 MET 1994 --------- From Daniel.Karrenberg at ripe.net Thu Oct 13 18:00:48 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 13 Oct 1994 18:00:48 +0100 Subject: Ripe 181 In-Reply-To: Your message of Tue, 11 Oct 1994 09:21:27 MST. <199410111621.AA27488@zephyr.isi.edu> Message-ID: <9410131700.AA17450@reif.ripe.net> > postel at ISI.EDU (Jon Postel) writes: > > Daniel: > > Local preference over global statements would seem to be implied by > the principle of using the longest match. Jon, see my reply to Bill. This was not the discussion taking place. -------- Logged at Thu Oct 13 18:01:00 MET 1994 --------- From Daniel.Karrenberg at ripe.net Thu Oct 13 18:00:09 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 13 Oct 1994 18:00:09 +0100 Subject: Ripe 181 In-Reply-To: Your message of Tue, 11 Oct 1994 05:41:40 MST. <199410111241.AA02655@zed.isi.edu> Message-ID: <9410131700.AA17438@reif.ripe.net> > bmanning at ISI.EDU writes: > Well, this is perhaps incorrect. I should perhaps state that local preferen > ce > should be cast inside global preference. In this case, if I am delegated > a /27 mask from a larger /24 mask, I ought to be able to override the > preferences of the /24 registration. Something along the lines of BGPs > longest match. In the absence of the more specific (local) preference, > use the more generic (global) preference. > > Does this make sense? It does. But it is not relevant for the local/global discussion at hand. This does not concern "specificness" of routes as in "longest match". It concerns local variations of policy (across peerings to the same neighbor) over the global policy (between different neighbors). ------------ You raise an interesting point iabout counter intuitive behaviour of CIDR though: AS1 is connected to AS2 and AS3 AS1 policy says to prefer all routes learned from AS2 over anything learned from AS3 AS3 announces a more specific route inside a route announced by AS2. According to CIDR rules the more specific route takes precedence. My gut says that some properties of BGP-4/IDRIP may actually depend on this. Those specifying the routing policy would probably want less specific route to take precedence because they do not trust AS3 as much. ------------- For RIPE-181 this is a non issue, since it describes preferences between exactly equal routes (length *and* prefix) only. Daniel -------- Logged at Thu Oct 13 18:15:13 MET 1994 --------- From Marten.Terpstra at ripe.net Thu Oct 13 18:14:47 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Thu, 13 Oct 1994 18:14:47 +0100 Subject: Ripe 181 In-Reply-To: Your message of Thu, 13 Oct 1994 18:00:09 MET. <9410131700.AA17438@reif.ripe.net> Message-ID: <9410131714.AA19988@rijp.ripe.net> * You raise an interesting point iabout counter intuitive behaviour * of CIDR though: * * AS1 is connected to AS2 and AS3 * * AS1 policy says to prefer all routes learned from AS2 over anything * learned from AS3 * * AS3 announces a more specific route inside a route announced by AS2. * * According to CIDR rules the more specific route takes precedence. * My gut says that some properties of BGP-4/IDRIP may actually depend on this. * * Those specifying the routing policy would probably want less specific route * to take precedence because they do not trust AS3 as much. If you would use the RR properly then also the more specifics would be included in the network list generated for routes from AS2. If this is not the case, then it would not accept the more specific from either AS2 or AS3 (which is fine, it will use the less specific with better preference from AS2), or when it is present, it will accept it from AS2 over AS3 (which is als fine). Ie the more specific must be in the RR to make this work. If one only filters on AS paths or origins, this would indeed give the counter intuitive result. Ergo, always filter using netlists if you are not sure what your neighbours are doing.... -Marten -------- Logged at Thu Oct 13 19:49:31 MET 1994 --------- From cengiz at ISI.EDU Thu Oct 13 19:46:41 1994 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Thu, 13 Oct 1994 11:46:41 -0700 Subject: Ripe 181 In-Reply-To: <9410131649.AA17420@reif.ripe.net> References: <199410110031.AA14540@chl.isi.edu> <9410131649.AA17420@reif.ripe.net> Message-ID: <199410131846.AA18392@chl.isi.edu> Let me make sure I understand this right. There are cascade of two orderings. A router L1 prefers a route from its peer R1 over its other peer R2 if 1) R1's AS != R2's AS and the as-in preference of this route via R1's AS is less than or equal to the as-in preference of this route via R2's AS 2) R1's AS == R2's AS and the interas-in preference of this route via R1 is less than or equal to the interas-in preference of this route via R2. This is almost but not equivalent to the following: Assume all preference values are in the range 0...Range a route is accepted from a peer with gated preference of as-in preference * Range + interas-in preference (in addition you map smallest of these numbers to 1, next smallest to 2 and so on). Is this right? The cascade of two orderings is news to me. Having a cascade has pros and cons. Some minor comments below: Daniel Karrenberg (Daniel.Karrenberg at ripe.net) on October 13: > ... > It also does not make sense to compare local (interas-in) preferences > between different peer ASes! The preferences between the peers are defined > in as-in. The local preferences only differentiate between different > peerings to the same AS. I wish these were the words in Ripe-181. There would not be any confusion. > > A suitable algorithm to derive gated preferences would be > > > for all ASes referenced in as-in attributes > > build an ordered list of peers by preference > > for all ASes referenced in interas-in attributes > > ERROR if ordered list for route cannot be found > > replace the peer entry in the ordered list above > by an ordered list of peering sessions to this peer > > for all ordered lists thus generated > > output preference statements with increasing integers > per list element > - for any specific peering mentioned > - for all peerings to the neighbor if no specific > peering is mentioned > > > > > 2) > > Example topology: > > AS1 is connected to AS2 through L1 R1, L1 R2. > > AS1 is connected to AS3 through L1 R3. > > > > aut-num: AS1 > > as-in: from AS2 10 accept AS100 OR AS200 > > Makes lists: > > AS100: AS2 > AS200: AS2 > > > as-in: from AS3 11 accept AS100 OR AS200 > > AS100: AS2 AS3 > AS200: AS2 AS3 > > > interas-in: from AS2 L1 R1 (pref=100) AS100 > > AS100: AS2/L1R1 AS3 > AS200: AS2 AS3 > > > preference for routes of AS100 learned from R1 is 100. > > preference for routes of AS100 learned from R2: not valid. > > preference for routes of AS100 learned from R3 is 11. > > preference for routes of AS200 learned from R1 is XXX. > > preference for routes of AS200 learned from R2 is XXX. > > preference for routes of AS200 learned from R3 is 11. > > preference for routes of AS100 learned from R1 1 > preference for routes of AS100 learned from R3 2 > preference for routes of AS200 learned from R1 1 > preference for routes of AS200 learned from R2 1 > preference for routes of AS200 learned from R3 2 > > > The value of XXX is not specified in Ripe181. Literally speaking this > > means a random value. > > ripe-181 says that the preferences are equal across all peerings > to the sam neighbor and consistent with as-in (global) policy. In this case > the preference value in interas-in is not relevant and can be undefined. > This does not mean that a configuration tool cannot derive an appropriate > value depending on the output language. Ripe-181 does not say they are consistent. It says there is no relevance. > > > In one of your examples [Ref 1. below], you have used > > the value used in the other interas-in statement. Which makes: > > XXX = 100. > > Daniel [Ref 2.] suggests it should be greater than any value mentioned > > in an interas-in statement. Which makes: > > XXX >= 101. > > My brain was disengaged when I wrote this and it fell into the same > trap as Cengiz. The value is immaterial Exactly. This is because our brains read and interpret the ripe-181 document where the cascade of two orderings is neither explicit nor implicit. There is one problem that I foresee with your algorithm. You are trying to come-up with one total ordering (per route) whereas your input has cascade of two partial orderings. What do you do below: aut-num: AS1 as-in: from AS2 10 accept AS100 as-in: from AS3 10 accept AS100 interas-in: from AS2 L1R1 10 accept AS100 interas-in: from AS2 L1R2 11 accept AS100 interas-in: from AS3 L1R3 12 accept AS100 interas-in: from AS3 L1R4 13 accept AS100 Obviously there is no total ordering with these values. A partial ordering is fine as long as gated is concerned. However, I am not 100% sure that one can come up with "one" partial ordering unless you compare interas-in preferences for different ASs (i.e. 10 with 12). Gated does not support two partial orderings. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute cengiz at isi.edu University of Southern California -------- Logged at Fri Oct 14 12:31:04 MET 1994 --------- From Marten.Terpstra at ripe.net Fri Oct 14 12:31:00 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Fri, 14 Oct 1994 12:31:00 +0100 Subject: Database transition step 1 completed Message-ID: <9410141131.AA20822@rijp.ripe.net> Dear all, I am pleased to say that the first step of the RIPE database transition has been succesfully completed yesterday. Up till now, one minor and one major bug have been found and fixed and the database seems stable. Those who daily ftp the ripe database from ftp.ripe.net may have found that it was not there this morning. This was a simple typo in one of my scripts and has been fixed. The ftpable files (the complete database in ripe/dbase/ripe.db and the split versions in ripe/dbase/split) are currently generated at around 5:30 (AM for the US folks ;-) Dutch time, which is currently UTC+1. All database files ara available as uncompressed and compressed (both normal compress and gzip) versions. The generation time can be changed if you think there is a need (earlier, not later). Those who run a secondary copy of the database may find that the latest ftpable database takes much longer to index. This is because the database now includes large provider blocks, and the old software is not good at handling large blocks. The current plan is to have a beta release of the software (with some documentation on the changes) ready this weekend, so you can pick up this software and use it to index the RIPE database. This version will have all of the classless and other features as per the database transition plan (T1). As far as conflicts/problems in the guardian files are concerned, most of them have been resolved. There are some 15 guardian files left with problems. These guardians will be approached to correct these problems. If you have questions/comments/bugs, please report to me personally, or to any of the above lists if you think they are interesting for a larger audience. Regards, -Marten -------- Logged at Fri Oct 14 15:10:26 MET 1994 --------- From Daniel.Karrenberg at ripe.net Fri Oct 14 15:10:13 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 14 Oct 1994 15:10:13 +0100 Subject: Ripe 181 In-Reply-To: Your message of Thu, 13 Oct 1994 11:46:41 MST. <199410131846.AA18392@chl.isi.edu> Message-ID: <9410141410.AA19019@reif.ripe.net> > Let me make sure I understand this right. > > There are cascade of two orderings. > A router L1 prefers a route from its peer R1 > over its other peer R2 if > 1) R1's AS != R2's AS > and the as-in preference of this route via R1's AS > is less than or equal to > the as-in preference of this route via R2's AS > 2) R1's AS == R2's AS > and the interas-in preference of this route via R1 > is less than or equal to > the interas-in preference of this route via R2. s/or equal// Right. > This is almost but not equivalent to the following: > Assume all preference values are in the range 0...Range > a route is accepted from a peer with gated preference of > as-in preference * Range + interas-in preference It is not equivalent because this orders by interas-in preference across ASes if the as-in preferences are equal. See below. > Is this right? The cascade of two orderings is news to me. > Having a cascade has pros and cons. I do not see the cons. It forces consistency and works well when interas-in only deals with exceptions, i.e. the normal case. > I wish these were the words in Ripe-181. There would not be any > confusion. Me too, but nothing is perfect. We will put a better explanation in the PRIDE guide. > Ripe-181 does not say they are consistent. It says there is no > relevance. It is good enough for a spec, not for a tutorial. > There is one problem that I foresee with your algorithm. You are > trying to come-up with one total ordering (per route) whereas your > input has cascade of two partial orderings. > > What do you do below: > > aut-num: AS1 > as-in: from AS2 10 accept AS100 > as-in: from AS3 10 accept AS100 > interas-in: from AS2 L1R1 10 accept AS100 > interas-in: from AS2 L1R2 11 accept AS100 > interas-in: from AS3 L1R3 12 accept AS100 > interas-in: from AS3 L1R4 13 accept AS100 > > Obviously there is no total ordering with these values. > A partial ordering is fine as long as gated is concerned. > However, I am not 100% sure that > one can come up with "one" partial ordering > unless you compare interas-in preferences for different ASs > (i.e. 10 with 12). The intention of this is clear: Globally accept from AS2 and AS3 with equal preference. Locally prefer L1R1 over L1R2 from AS2. Locally prefer L1R3 over L1R4 from AS2. So the partial ordering is L1R1 = L1R3 < L1R2 = L1R4 Easy to derive too. Another way of putting it is to say that the interas-in attributes above are fully equivalent to: interas-in: from AS2 L1R1 1 accept AS100 interas-in: from AS2 L1R2 2 accept AS100 interas-in: from AS3 L1R3 1 accept AS100 interas-in: from AS3 L1R4 2 accept AS100 > Gated does not support two partial orderings. Nor does any other router configuration language, it does not make much sense. Is this clear now? Daniel -------- Logged at Fri Oct 14 19:29:15 MET 1994 --------- From cengiz at ISI.EDU Fri Oct 14 19:28:39 1994 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Fri, 14 Oct 1994 11:28:39 -0700 Subject: Ripe 181 In-Reply-To: <9410141410.AA19019@reif.ripe.net> References: <199410131846.AA18392@chl.isi.edu> <9410141410.AA19019@reif.ripe.net> Message-ID: <199410141828.AA25820@chl.isi.edu> Thanks for more clarification. It clarified enough so that I can continue my implementation. More comments below. Daniel Karrenberg (Daniel.Karrenberg at ripe.net) on October 14: > > This is almost but not equivalent to the following: > > Assume all preference values are in the range 0...Range > > a route is accepted from a peer with gated preference of > > as-in preference * Range + interas-in preference > > It is not equivalent because this orders by interas-in preference > across ASes if the as-in preferences are equal. See below. Exactly. > > There is one problem that I foresee with your algorithm. You are > > trying to come-up with one total ordering (per route) whereas your > > input has cascade of two partial orderings. > > > > What do you do below: > > > > aut-num: AS1 > > as-in: from AS2 10 accept AS100 > > as-in: from AS3 10 accept AS100 > > interas-in: from AS2 L1R1 10 accept AS100 > > interas-in: from AS2 L1R2 11 accept AS100 > > interas-in: from AS3 L1R3 12 accept AS100 > > interas-in: from AS3 L1R4 13 accept AS100 > > > > Obviously there is no total ordering with these values. > > A partial ordering is fine as long as gated is concerned. > > However, I am not 100% sure that > > one can come up with "one" partial ordering > > unless you compare interas-in preferences for different ASs > > (i.e. 10 with 12). > > The intention of this is clear: > > Globally accept from AS2 and AS3 with equal preference. > > Locally prefer L1R1 over L1R2 from AS2. > > Locally prefer L1R3 over L1R4 from AS2. > > So the partial ordering is > > L1R1 = L1R3 < L1R2 = L1R4 > > Easy to derive too. > Is this clear now? Not quite. This only works when you have two to choose from. If you have more: interas-in: from AS2 L1R1 1 accept AS100 interas-in: from AS2 L1R2 2 accept AS100 interas-in: from AS3 L1R3 1 accept AS100 interas-in: from AS3 L1R4 2 accept AS100 interas-in: from AS3 L1R5 3 accept AS100 i.e. L1R1 < L1R2 and L1R3 < L1R4 < L1R5 hence there are two possible orderings: 1. L1R1 = L1R3 < L1R2 = L1R4 < L1R5 2. L1R1 = L1R3 < L1R4 < L1R2 = L1R5 Choosing either of them means some comparison of interas-in preferences across AS's. After some local discussion here, we decided to go with 1. Since it is easier to compute: o renumber interas-in preferences so that the smallest preference value is now 1, next smallest is 2, ... o compare interas-in preferences across AS's as well to get the final ordering. as-in preference * Range + interas-in preference No need to maintain ordered lists per route. (Actually with equal preferences ordered lists in your algorithm are actually ordered graphs). Folks, please let me know if there are problems with this approach. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute cengiz at isi.edu University of Southern California -------- Logged at Sun Oct 16 17:20:57 MET 1994 --------- From Daniel.Karrenberg at ripe.net Sun Oct 16 17:20:43 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Sun, 16 Oct 1994 17:20:43 +0100 Subject: Ripe 181 In-Reply-To: Your message of Fri, 14 Oct 1994 11:28:39 MST. <199410141828.AA25820@chl.isi.edu> Message-ID: <9410161620.AA20165@reif.ripe.net> > cengiz at ISI.EDU (Cengiz Alaettinoglu) writes: > > > So the partial ordering is > > > > L1R1 = L1R3 < L1R2 = L1R4 > > > > Easy to derive too. > > Is this clear now? > > Not quite. This only works when you have two to choose from. > If you have more: > > interas-in: from AS2 L1R1 1 accept AS100 > interas-in: from AS2 L1R2 2 accept AS100 > interas-in: from AS3 L1R3 1 accept AS100 > interas-in: from AS3 L1R4 2 accept AS100 > interas-in: from AS3 L1R5 3 accept AS100 > > i.e. > L1R1 < L1R2 and L1R3 < L1R4 < L1R5 > hence there are two possible orderings: > 1. L1R1 = L1R3 < L1R2 = L1R4 < L1R5 > 2. L1R1 = L1R3 < L1R4 < L1R2 = L1R5 > > Choosing either of them means some comparison of interas-in > preferences across AS's. > > After some local discussion here, we decided to go with 1. > Since it is easier to compute: > o renumber interas-in preferences so that the smallest > preference value is now 1, next smallest is 2, ... > o compare interas-in preferences across AS's as > well to get the final ordering. > as-in preference * Range + interas-in preference > > No need to maintain ordered lists per route. (Actually with equal > preferences ordered lists in your algorithm are actually ordered > graphs). > > Folks, please let me know if there are problems with this approach. This is how I would do it. Since I do not expect this to be exercised much in practise, much less that it will really matter at all, I do not care much either. Daniel Daniel -------- Logged at Tue Oct 18 17:51:24 MET 1994 --------- From dsj at merit.edu Tue Oct 18 17:51:15 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Tue, 18 Oct 1994 12:51:15 -0400 Subject: dbase dist once more Message-ID: <199410181651.MAA27654@merit.edu> Marten, Thanks enormously for making this code available, and for passing the prdb.db through it. Your letting us at early versions of the code has made it possible for us to get the PRDB dumps converted to 181 format, (including the right internal names), and to hack our old implemtation to recognize those new names. Rick has also been able to peek at the dbserver implementation and adjust his thinking (if not his dbserver code, yet). I will be able to look at syntax.pl to check about integrating our yacc parser there (and handling multiple-line attributes). Unfortunately the Route Server machines arrived Friday as well as your software distribution; we've shipped Laurent off to California to help with the initial system administration of those machines so that we can get them out to the NAPs. Laurent should be back sometime this week, at which point he can begin bringing up your new distribution. (Our new Routing Registry machine also arrived, so we even have a spiffy new place to put it). Thanks again for making this stuff avaiable to us, and for beginning to look at our data. --Dale PS: > Thursday yet, and it works fine). If you have cycles to make a faster > indexing program (I am thinking of Laurents programming skills here) > I'd be interested. No doubt a C program could do all of this faster. Rick has written a similar C program, though I think he then replaced it by moving to Perl-5. Rick? ========================================================================== > From marten at ripe.net Fri Oct 14 14:45:22 1994 > To: dsj at merit.edu, lpj at merit.edu, rlr at merit.edu > Subject: DB release > Cc: Tony Bates , Daniel Karrenberg > From: Marten Terpstra > Date: Fri, 14 Oct 1994 19:45:16 +0100 > Sender: Marten.Terpstra at ripe.net > > > Folks, > > I have put together a dbase distribution (of some sort) with some > updated documentation. The docs are nowhere near complete but all > modules are in there, and it explains how to do classless indexes and > all. > > The distribution is not up for ftp yet for anyone, I would like you > all to have a look at it first. Plan is to announce it to a sligly > wider audience on Sunday or Monday or so. > > You can find it in my home directory on fox.merit.edu. If you want to > see what things look like when they are installed, have a look on > ns.ripe.net in /dbase (or /nccfs3/dbase) which is where this is > currently running. > > The indexing is not particulary fast, but in my view, it does not need > to be. Once the guarded attribute procedure is gone, cleaning would > only be needed once a week or so. > > I'll be here most of tomorrow and sunday (for PRIDE guide stuff) so if > you have questions, shoot. I'll be in the first half of next week, > then I am off to Interop in Paris for just over a week. I'll try and > answer and clarify if I can anyways. > > I have some hints on how to improve things if you have different DBM > linked in with perl, but I am too tired now ;-) It basically now > recognizes the 1K bucket size max for the SUN supplied version of DBM > and will generate overflow files if it needs to put in more data than > 1K for a certain key (needed for classless tree). The 1K limit is now > hardcoded in cldb.pl. > > Also (I keep coming up with new things here) if you run a cleandb, you > do not have to do a classless index again. The classless indexes do > NOT contain file offsets, but point to the unique key of the various > objects which does not change when doing a cleandb. It basically will > recognize IP numbers (in whatever format) and will do a recursive > lookup. First from IP address to a certain (set of) unique keys, and > then it will lookup these keys like it would normally do.Classless > cleaning only needs to be done once a week or so. Have a look with > showdbm and you'll see what I mean. > > -Marten > > PS Tony and Daniel, if you want to try and install, you can find it in > /nccfs3/dbase.dist/dbase-beta.tar.gz. ---------------------------- > From marten at ripe.net Sun Oct 16 13:26:28 1994 > To: dsj at merit.edu, lpj at merit.edu, rlr at merit.edu > Subject: dbase dist once more > Cc: Tony Bates , Daniel Karrenberg > From: Marten Terpstra > Date: Sun, 16 Oct 1994 18:26:23 +0100 > Sender: Marten.Terpstra at ripe.net > > > Folks, > > I just put a new version of dbase-beta.tar.gz in my home dir on fox. > The last version did not index inet-rtr interface addresses properly. > That is fixed. There is one problem however which I do not understand > yet. I tried to index the prdb you have on fox, and for some reason > the DBM index grew to 170 Mbytes and I ran out of disk space. This is > strange because I also have indexed the complete Internic database > (80,000+ nets) and that had a normal size DBM file. I am talking about > the real size of the DBM file, not the size ls reports. The only > different is that you have routes, internic only nets. We tried on > another machine as well (I thought it could have to do with disk > fragmnentation or whatever) with the same results..... It is the > classless index that generates this massive file. It is probably the > dbm version we use (the standard sun one) but I have not been able to > do a test with another dbm just yet. Please have a go and see what it > does for you .... > > -Marten > > PS I also took the same file, only used the "rt:" lines and indexed > and that went fine. The difference there is that if there is a origin, > the key is the route, a tab, and then the origin. I do not understand > why this would make such a different .... I'll play some more when I > have the time. I ran out of disk space 1000 routes before the end ;-( > > PPS The classless indexing is quite slow, however it needs to be done > once every week or so only (I have not classless reindexed ours since > Thursday yet, and it works fine). If you have cycles to make a faster > indexing program (I am thinking of Laurents programming skills here) > I'd be interested. No doubt a C program could do all of this faster. ------------------- -------- Logged at Tue Oct 18 18:20:54 MET 1994 --------- From Tony.Bates at ripe.net Tue Oct 18 18:20:08 1994 From: Tony.Bates at ripe.net (Tony Bates) Date: Tue, 18 Oct 1994 18:20:08 +0100 Subject: dbase dist once more In-Reply-To: Your message of Tue, 18 Oct 1994 12:51:15 -0400. <199410181651.MAA27654@merit.edu> Message-ID: <9410181720.AA19174@mature.ripe.net> "Dale S. Johnson" writes: * Marten, * * Thanks enormously for making this code available, and for passing the * prdb.db through it. Your letting us at early versions of the code has * made it possible for us to get the PRDB dumps converted to 181 format, Dale, one small comment on this. I notice you are using mail addresses in the tech-c and admin-c for the prdb dumps. This is in fact illegal syntax. Just a minor nit. * (including the right internal names), and to hack our old implemtation * to recognize those new names. Rick has also been able to peek at the * dbserver implementation and adjust his thinking (if not his dbserver * code, yet). I will be able to look at syntax.pl to check about integrating * our yacc parser there (and handling multiple-line attributes). * This is something I would like to see if we can. The code right now for syntax.pl is pretty nasty (I did all this mess and I cant code so that will explain this ;-)).We can talk off line about this if you need a hand to get the pasrer in there. The main thing it needs to do is also produce useful messages upon ERROR or WARNING which if I remember the original way you did this made it quite difficult to do. AS nicer way would be to pass the whole object to the pasrer perhaps. * Unfortunately the Route Server machines arrived Friday as well as * your software distribution; we've shipped Laurent off to California * to help with the initial system administration of those machines so * that we can get them out to the NAPs. Laurent should be back sometime * this week, at which point he can begin bringing up your new * distribution. (Our new Routing Registry machine also arrived, so we * even have a spiffy new place to put it). * sounds great - we would appreciate some others getting into the code and seeing where we can get speed ups as Marten mentioned already. * Thanks again for making this stuff avaiable to us, and for beginning * to look at our data. * * --Dale * * PS: * > Thursday yet, and it works fine). If you have cycles to make a faster * > indexing program (I am thinking of Laurents programming skills here) * > I'd be interested. No doubt a C program could do all of this faster. * * Rick has written a similar C program, though I think he then replaced it * by moving to Perl-5. Rick? * * ========================================================================== * * * > From marten at ripe.net Fri Oct 14 14:45:22 1994 * > To: dsj at merit.edu, lpj at merit.edu, rlr at merit.edu * > Subject: DB release * > Cc: Tony Bates , Daniel Karrenberg * > From: Marten Terpstra * > Date: Fri, 14 Oct 1994 19:45:16 +0100 * > Sender: Marten.Terpstra at ripe.net * > * > * > Folks, * > * > I have put together a dbase distribution (of some sort) with some * > updated documentation. The docs are nowhere near complete but all * > modules are in there, and it explains how to do classless indexes and * > all. * > * > The distribution is not up for ftp yet for anyone, I would like you * > all to have a look at it first. Plan is to announce it to a sligly * > wider audience on Sunday or Monday or so. * > * > You can find it in my home directory on fox.merit.edu. If you want to * > see what things look like when they are installed, have a look on * > ns.ripe.net in /dbase (or /nccfs3/dbase) which is where this is * > currently running. * > * > The indexing is not particulary fast, but in my view, it does not need * > to be. Once the guarded attribute procedure is gone, cleaning would * > only be needed once a week or so. * > * > I'll be here most of tomorrow and sunday (for PRIDE guide stuff) so if * > you have questions, shoot. I'll be in the first half of next week, * > then I am off to Interop in Paris for just over a week. I'll try and * > answer and clarify if I can anyways. * > * > I have some hints on how to improve things if you have different DBM * > linked in with perl, but I am too tired now ;-) It basically now * > recognizes the 1K bucket size max for the SUN supplied version of DBM * > and will generate overflow files if it needs to put in more data than * > 1K for a certain key (needed for classless tree). The 1K limit is now * > hardcoded in cldb.pl. * > * > Also (I keep coming up with new things here) if you run a cleandb, you * > do not have to do a classless index again. The classless indexes do * > NOT contain file offsets, but point to the unique key of the various * > objects which does not change when doing a cleandb. It basically will * > recognize IP numbers (in whatever format) and will do a recursive * > lookup. First from IP address to a certain (set of) unique keys, and * > then it will lookup these keys like it would normally do.Classless * > cleaning only needs to be done once a week or so. Have a look with * > showdbm and you'll see what I mean. * > * > -Marten * > * > PS Tony and Daniel, if you want to try and install, you can find it in * > /nccfs3/dbase.dist/dbase-beta.tar.gz. * * ---------------------------- * * > From marten at ripe.net Sun Oct 16 13:26:28 1994 * > To: dsj at merit.edu, lpj at merit.edu, rlr at merit.edu * > Subject: dbase dist once more * > Cc: Tony Bates , Daniel Karrenberg * > From: Marten Terpstra * > Date: Sun, 16 Oct 1994 18:26:23 +0100 * > Sender: Marten.Terpstra at ripe.net * > * > * > Folks, * > * > I just put a new version of dbase-beta.tar.gz in my home dir on fox. * > The last version did not index inet-rtr interface addresses properly. * > That is fixed. There is one problem however which I do not understand * > yet. I tried to index the prdb you have on fox, and for some reason * > the DBM index grew to 170 Mbytes and I ran out of disk space. This is * > strange because I also have indexed the complete Internic database * > (80,000+ nets) and that had a normal size DBM file. I am talking about * > the real size of the DBM file, not the size ls reports. The only * > different is that you have routes, internic only nets. We tried on * > another machine as well (I thought it could have to do with disk * > fragmnentation or whatever) with the same results..... It is the * > classless index that generates this massive file. It is probably the * > dbm version we use (the standard sun one) but I have not been able to * > do a test with another dbm just yet. Please have a go and see what it * > does for you .... * > * > -Marten * > * > PS I also took the same file, only used the "rt:" lines and indexed * > and that went fine. The difference there is that if there is a origin, * > the key is the route, a tab, and then the origin. I do not understand * > why this would make such a different .... I'll play some more when I * > have the time. I ran out of disk space 1000 routes before the end ;-( * > * > PPS The classless indexing is quite slow, however it needs to be done * > once every week or so only (I have not classless reindexed ours since * > Thursday yet, and it works fine). If you have cycles to make a faster * > indexing program (I am thinking of Laurents programming skills here) * > I'd be interested. No doubt a C program could do all of this faster. * * ------------------- -------- Logged at Tue Oct 18 18:53:47 MET 1994 --------- From dsj at merit.edu Tue Oct 18 18:53:44 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Tue, 18 Oct 1994 13:53:44 -0400 Subject: dbase dist once more Message-ID: <199410181753.NAA03900@merit.edu> Tony, > > "Dale S. Johnson" writes: > * Marten, > * > * Thanks enormously for making this code available, and for passing the > * prdb.db through it. Your letting us at early versions of the code has > * made it possible for us to get the PRDB dumps converted to 181 > format, > > Dale, > one small comment on this. I notice you are using mail > addresses in the tech-c and admin-c for the prdb dumps. This is in > fact illegal syntax. Just a minor nit. Thanks for pointing this out; This should be fixed in tomorrow morning's data. (Well, tomorrow noon, Amsterdam time). I do want to get this stuff in legal shape. (We'll see how long it takes Elise to object to being Administrative Contact for 79 ANS routers :-) ). Maybe we should run this at midnight, so it is available in Europe at 6:am? This would improve the immediacy of the data for independently-made updates (when we finally get very many of these), but it would delay the PRDB-based updates by 18 hours, since these are usually run around 06:00 EST. We have a lot of missing mandatory fields, for things for which we simply don't have the data. (Particularly contact data). Any advice on how you would like us to cope with this? > * (including the right internal names), and to hack our old implemtation > * to recognize those new names. Rick has also been able to peek at the > * dbserver implementation and adjust his thinking (if not his dbserver > * code, yet). I will be able to look at syntax.pl to check about integrating > * our yacc parser there (and handling multiple-line attributes). > * > This is something I would like to see if we can. The code right now > for syntax.pl is pretty nasty (I did all this mess and I cant code so > that will explain this ;-)).We can talk off line about this if you need a > hand to get the pasrer in there. The main thing it needs to do is also > produce useful messages upon ERROR or WARNING which if I remember the > original way you did this made it quite difficult to do. AS nicer way > would be to pass the whole object to the pasrer perhaps. Ok; off-line. --Dale -------- Logged at Tue Oct 18 21:37:07 MET 1994 --------- From dsj at merit.edu Tue Oct 18 21:37:03 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Tue, 18 Oct 1994 16:37:03 -0400 Subject: Definitive Names for RIPE-181 Databases Message-ID: <199410182037.QAA17415@merit.edu> Daniel, Tony, Marten, What do you think of the following names for referring to various parts of the "Global Routing Registry"? As we try to write up PR and documentation and prepare presentations (like for NANOG next Monday) not having canonical names for things is starting to get in the way. Do you all ready have standards for some of these that I've missed along the way? (I have no desire to break existing tradition): GRR, GRRDB, "Global Routing Registry" -- The set of global interworking routing registries including RIPE.db, RA.db, and all others that interchange data. Analysis tools work on the GRR in order to get a full routing view, rather than just on a single administrative piece of the GRR, such as the RA.db or RIPE.db. [I personally think "GRR" is an aggressive and ugly acronym, but I strongly like the term "Global Routing Registry"] RIPE.db, "The RIPE Database" -- Ripe's database. RRDB, "Routing Registry Data Base": (One name we are using now). A nice name, but it *sounds* global, and this is confusing when it really means "Just the Routing Arbiter's portion of the Global Routing Registry". I am proposing that we stop using this term, and replace it by others. RADB, "RA.db", "Routing Arbiter DataBase" -- the official internal and external name of the "raw" database run by the Routing Arbiter. (Currently "MERITRR"). PGRR, "Processed Global Routing Registry" -- Suggested name for what has been referred to as the "cooked", "sanitized", "fixed", "processed" database: the set of processed data that is used to produce the Route Server configuration files. Note that the content of this will include processed versions of the RADB+RIPEDB+CANETDB+MCIDB plus more stuff generated by Cengiz's View Generator. (I can fill you in more on what this is about, if it isn't clear). MCI and CA*Net intend to run RIPE-181 registries, and will probably have their own database names like "MCI" and "CANET" MERITRR - This is the name currently used in templates to specify Merit's current port of RIPE, I propose replacing this by "RADB". (This name was chosen last February, before NSF's choice of RA awardees could be talked about). PRDB.db - The RA database in RIPE format that has been dumped from PRDB information. This will go away sometime. PRDB, "The PRDB itself" -- The Informix-based NSFNET/ANS Policy Routing Database, which is going away even sooner. --Dale -------- Logged at Wed Oct 19 02:48:24 MET 1994 --------- From epg at merit.edu Wed Oct 19 02:48:17 1994 From: epg at merit.edu (epg at merit.edu) Date: Tue, 18 Oct 94 21:48:17 EDT Subject: dbase dist once more Message-ID: <9410190148.AA07256@pepper.merit.edu> >Thanks for pointing this out; This should be fixed in tomorrow morning's >data. (Well, tomorrow noon, Amsterdam time). I do want to get this stuff >in legal shape. (We'll see how long it takes Elise to object to being >Administrative Contact for 79 ANS routers :-) ). Surely you jest....but this could be fun - you did say administrative contact for ANS routers...their network may never be the same ;-) -------- Logged at Thu Oct 20 18:33:22 MET 1994 --------- From cengiz at ISI.EDU Thu Oct 20 18:31:37 1994 From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Date: Thu, 20 Oct 1994 10:31:37 -0700 Subject: misleading diagnostic Message-ID: <199410201731.AA07309@chl.isi.edu> Below is an update request and reply from the database. It contains three objects: *rv: rs900.ra.net 3 *rv: rs900.ra.net 30 *rv: rs900.ra.net 300 Reply is Update Ok for all three objects. I checked the database it only contains the last one (the first two are marked with XX). I guess blanks in the key field caused this. What is more interesting entry with "*rv: rs2.ra.net 3" is also deleted as a result of this query. ------- start of digest (2 messages) (RFC 934 encapsulation) ------- From: cengiz at ISI.EDU (Cengiz Alaettinoglu) To: dbupdate Cc: Cengiz Alaettinoglu Date: Thu, 20 Oct 1994 10:18:18 -0700 Message-Id: <199410201718.AA07301 at chl.isi.edu> *rv: rs900.ra.net 3 *de: Policies for view 3 of Route Server rs2.ra.net *ai: from AS1239 0 accept NOT ANY *tc: elise gerich *ac: bill manning *gd: bmanning at isi.edu *rm: This entry is created by RA analysis software. *mb: acts-of-god *ch: cengiz at isi.edu 940919 *so: PISITEST *rv: rs900.ra.net 30 *de: Policies for view 3 of Route Server rs2.ra.net *ai: from AS1239 0 accept NOT ANY *tc: elise gerich *ac: bill manning *gd: bmanning at isi.edu *rm: This entry is created by RA analysis software. *mb: acts-of-god *ch: cengiz at isi.edu 940919 *so: PISITEST *rv: rs900.ra.net 300 *de: Policies for view 3 of Route Server rs2.ra.net *ai: from AS1239 0 accept NOT ANY *tc: elise gerich *ac: bill manning *gd: bmanning at isi.edu *rm: This entry is created by RA analysis software. *mb: acts-of-god *ch: cengiz at isi.edu 940919 *so: PISITEST ------------------------------ From: Merit-RR Database Management To: cengiz at ISI.EDU (Cengiz Alaettinoglu) Subject: Re: Date: Thu, 20 Oct 1994 13:20:11 -0400 Message-Id: <199410201720.NAA04620 at fox.merit.edu> Your e-mail: From: cengiz at ISI.EDU (Cengiz Alaettinoglu) Subject: Date: Thu, 20 Oct 1994 10:18:18 -0700 Msg-Id: <199410201718.AA07301 at chl.isi.edu> has been processed by the database software and produced the following output: Update OK: [rs-view] rs900.ra.net 3 Update OK: [rs-view] rs900.ra.net 30 Update OK: [rs-view] rs900.ra.net 300 No error/warnings were found in your database update. Congratulations. Sincerely Yours, Merit-RR Database Maintenance Department ------- end ------- Cengiz -- Cengiz Alaettinoglu Information Sciences Institute cengiz at isi.edu University of Southern California -------- Logged at Thu Oct 20 18:47:11 MET 1994 --------- From rlr at merit.edu Thu Oct 20 18:47:03 1994 From: rlr at merit.edu (Rick Riolo) Date: Thu, 20 Oct 1994 13:47:03 -0400 Subject: perl5 (.000) officially released Message-ID: <199410201747.NAA05988@toad.merit.edu> attached is an ancmnt for the new perl5 official release. we will be installing this at merit in the next week or two. (but keeping a perl4 around too...) I have used perl5 for the radbserver because it allows me to tie associative arrays to a variety of db packages (including user defined ones), including ndbm, gdbm, and DB. Right now I am using gdbm: it seems fast enough and allows me to go beyound the 1K (or 2K, i forget) limit of (n)dbm. Clients of the radbserver need only perl4, and the clients we are producing need only perl4. perl5 has a lot of new features...so get with the program ;-) - r From lwall at netlabs.com Wed Oct 19 18:18:57 1994 From: lwall at netlabs.com (Larry Wall) Date: 19 Oct 1994 17:18:57 GMT Subject: Perl 5.0 Official Release Notice Message-ID: <383ke1$79k@csnews.cs.Colorado.EDU> Table of Contents for this Message: Intro New Features List New Documentation List Getting Source and Documentation Extension Modules WWW Info Known Bugs Bug Reports FAQ ------------------------------------------------------------ Intro: After years of loving craftsmanship by many otherwise sane folks, release 5 of Perl is now officially launched into production. The new release provides many new features and an extremely high level of compatibility with previous versions. But more importantly, Perl is now philosophically committed to the notions of extensibility and reusability, so that the language itself can stabilize. Perl 5.0 should configure and build straight out of the box (as it were) on virtually any UNIX system, and even on VMS, too! Ports to other architectures (MS-DOS, Windows/NT) are in the works. Have the appropriate amount of fun, Larry Wall lwall at netlabs.com Wednesday, 19 October 1994 (tsc) ------------------------------------------------------------ New Features: cleaner and more portable configuration and build process greatly simplified grammar and faster, tighter interpreter numerous legibility enhancements optional compile-time restrictions on dubious constructs greatly improved diagnostics both lexical and dynamic scoping anonymous data types: scalars, lists, hash table, functions arbitrarily nested data structures modularity and reusability object-oriented programming package constructors and destructors embeddibility and extensibility dynamic loading of C libraries a POSIX 1003.1 compliant interface multiple simultaneous DBM implementations (dbm, sdbm, ndbm, gdbm, berkeley db) operator overloading on arithmetic types supplied: Complex, BigInt, and BigFloat regular expression enhancements extensions: curses, X11 support via Sx (Athena, Xlib) and Tk ------------------------------------------------------------ New Documentation: The once onerous Perl man page has been broken up into many different pieces, suitable for viewing with the standard man interface or via HTML. The following separate sections are included: perl Perl overview perldata Perl data structures perlsyn Perl syntax perlop Perl operators and precedence perlre Perl regular expressions perlrun Perl execution and options perlfunc Perl builtin functions perlvar Perl predefined variables perlsub Perl subroutines perlmod Perl modules perlref Perl references and nested data structures perlobj Perl objects perlbot Perl OO tricks and examples perldebug Perl debugging perldiag Perl diagnostic messages (*ALL* of them, w/ explanations!) perlform Perl formats perlipc Perl interprocess communication perlsec Perl security perltrap Perl traps for the unwary (includes perl4 vs perl5) perlstyle Perl style guide perlapi Perl application programming interface perlguts Perl internal functions for those doing extensions perlcall Perl calling conventions from C perlovl Perl overloading semantics perlbook Perl book information Furthermore, there is documentation on the standalone programs and the all Perl library modules. A pre-formatted postscript version of these is available in one piece (240 pages); see the "Docs" ftp entries below. ------------------------------------------------------------ Getting Source and Documentation: North America ftp://ftp.cis.ufl.edu/pub/perl/src/5.0/perl5.000.tar.gz ftp://prep.ai.mit.edu/pub/gnu/perl5.000.tar.gz ftp://ftp.uu.net/languages/perl/perl5.000.tar.gz ftp://ftp.khoros.unm.edu/pub/perl/perl5.000.tar.gz ftp://ftp.cbi.tamucc.edu/pub/duff/Perl/perl5.000.tar.gz ftp://ftp.metronet.com/perlinfo/source/perl5.000.tar.gz ftp://genetics.upenn.edu/perl5/perl5_000.zip Europe ftp://ftp.cs.ruu.nl/pub/PERL/perl5.0/perl5.000.tar.gz ftp://ftp.funet.fi/pub/languages/perl/ports/perl5/perl5.000.tar.gz ftp://ftp.zrz.tu-berlin.de/pub/unix/perl/perl5.000.tar.gz ftp://src.doc.ic.ac.uk/packages/perl5/perl5.000.tar.gz http://src.doc.ic.ac.uk/packages/perl5/perl5.000.tar.gz gopher://src.doc.ic.ac.uk/0/packages/perl5/perl5.000.tar.gz Australia ftp://sungear.mame.mu.oz.au/pub/perl/src/5.0/perl5.000.tar.gz Docs: http://www.metronet.com/0/perlinfo/perl5/manual/perl.html ftp://ftp.uu.net/languages/perl/PerlDoc.ps.gz ftp://prep.ai.mit.edu/pub/gnu/PerlDoc.ps.gz ftp://ftp.cbi.tamucc.edu/pub/duff/Perl/PerlDoc.ps.gz ftp://www.metronet.com/pub/perlinfo/perl5/manual/PerlDoc.ps.gz ftp://ftp.zrz.tu-berlin.de/pub/unix/perl/PerlDoc.ps.gz (Europe) ftp://ftp.cs.ruu.nl/pub/PERL/perl5.0/PerlDoc.ps.gz (Europe) ftp://sungear.mame.mu.oz.au/pub/perl/doc/PerlDoc.ps.gz (Oz) Email access: The following is a list of known ftpmail sites. Please attempt to use the site closest to you with the ftp archive closest to it. Many of these sites already have perl on them. For information on how to use one of these sites, send email containing the word "help" to the address. United States: Massachusetts: ftpmail at decwrl.dec.com New Jersey: bitftp at pucc.princeton.edu North Carolina: ftpmail at sunsite.unc.edu Europe/UK: Germany: ftpmail at ftp.uni-stuttgart.de bitftp at vx.gmd.de UK: ftpmail at doc.ic.ac.uk Australia: ftpmail at cs.uow.edu.au Henk P Penning* suggests that if you are in Europe you should try the following (if you are in Germany or the UK, you should probably use one of the servers listed above): Email: Send a message to 'mail-server at cs.ruu.nl' containing: begin path your_email_address send help send PERL/INDEX end The path-line may be omitted if your message contains a normal From:-line. You will receive a help-file and an index of the directory that contains the Perl stuff. You should probably ask for something like these: send PERL/perl5.000.tar.gz send PERL/PerlDoc.ps.gz *PLEASE* use email ftp access only has a last recourse, and please wait as long as possible before sending in your request, so the load on the server is spread over a longer period. ------------------------------------------------------------ Extension Modules: Tk (as in tcl/tk, but sans tcl) ftp://ftp.cis.ufl.edu/pub/perl/src/tkperl/tkperl5a4.tar.gz ftp://ftp.khoros.unm.edu/pub/perl/extensions/tkperl5a4.tar.gz ftp://ftp.metronet.com/pub/perlinfo/perl5/tkperl/tkperl5a4.tar.gz ftp://ftp.cs.ruu.nl/pub/PERL/perl5.0/tkperl5a4.tar.gz ftp://black.ox.ac.uk/src/ALPHA/tkperl5a4.tar.gz (try 5a5 everywhere after 2pm UST Thu 20 Oct 1994, as in) ftp://sable.ox.ac.uk/pub/perl/tkperl5a5.tar.gz Curses (standard C library) ftp://ftp.ncsu.edu/pub/math/wsetzer/cursperl5a6.tar.gz ftp://ftp.metronet.com/pub/perlinfo/perl5/cursperl5a6.tar.gz ftp://ftp.cs.ruu.nl/pub/PERL/perl5.0/cursperl5a6.tar.gz Msql (SQL) ftp://ftp.zrz.TU-Berlin.DE/pub/unix/perl/MsqlPerl-a1.tgz ftp://ftp.khoros.unm.edu/pub/perl/extensions/MsqlPerl-a1.tgz ftp://ftp.metronet.com/pub/perlinfo/perl5/MsqlPerl5-a1.tgz ftp://ftp.cs.ruu.nl/pub/PERL/perl5.0/MsqlPerl-a1.tar.gz Sx (Athena & Xlib) ftp://ftp.pasteur.fr/pub/Perl/Sx.tar.gz ftp://ftp.khoros.unm.edu/pub/perl/extensions/Sx.tar.gz ftp://ftp.metronet.com/pub/perlinfo/perl5/Sx.tar.gz ftp://ftp.cs.ruu.nl/pub/PERL/perl5.0/PerlDoc.ps.gz Database (Oracle, Sybase, Informix, Ingress, etc) ftp://ftp.demon.co.uk:/pub/perl/db ftp::/ftp.cis.ufl.edu//pub/perl/scripts/db ------------------------------------------------------------ WWW Info: Web access to random perl information is found here: General: http://www.metronet.com/perlinfo/perl5.html Full on-line hypertextual PerlDoc: http://www.metronet.com/0/perlinfo/perl5/manual/perl.html http://www.mit.edu:8001/perl/perl.html (might just be gamma) ------------------------------------------------------------ Known Bugs: The README says it's a pre-release. Workaround: ignore this sentence. Installs perl0.000 and sperl0.000 instead of 5.000. Workaround: rename the files. The debugger appears to be broken on "my" variables; Workaround: none yet Recursive signal handlers eventually core dump. Workaround: ease up on the ^C key. The following code misbehaves: print ++$_ . "\n" until /0/; Workaround: initialize your variable Destructors can clobber $@ on exit from an eval Workaround: local $@; eval {...}; ------------------------------------------------------------ Bug Reports: The best place to send your bug is to the Perl Porters mailing list . You may subscribe to the list in the customary fashion via mail to . Feel free to post your bugs to the comp.lang.perl newsgroup as well, but do make sure they still go to the mailing list. To enhance your chances of getting any bug you report fixed: 1. Try to narrow the problem down to as small a piece of code as possible. If you can get it down to 1 line of Perl then so much the better. 2. Include a copy of the output from the myconfig script from the Perl source distribution in your posting. ------------------------------------------------------------ FAQ: The Perl Frequently Asked Questions list (in somewhat antiquated form, especially now that Perl 5.0 is out) may be found here, amongst other places: ftp://ftp.cis.ufl.edu/pub/perl/doc/faq.gz ftp://sungear.mame.mu.oz.au/pub/perl/doc/faq.gz ftp://ftp.cs.ruu.nl/pub/PERL/FAQ.gz -------- Logged at Thu Oct 20 21:23:20 MET 1994 --------- From dsj at merit.edu Thu Oct 20 21:23:00 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Thu, 20 Oct 1994 16:23:00 -0400 Subject: RADB data file location moved Message-ID: <199410202023.QAA25282@merit.edu> FYI: If anyone has been using the database dumps from the RADB, note that the ftp location of these files has just changed. Used to be: rrdb.merit.edu:pub/meritrr/dbase Now: ftp.ra.net:pub/radb/dbase --Dale -------- Logged at Fri Oct 21 13:18:58 MET 1994 --------- From Daniel.Karrenberg at ripe.net Fri Oct 21 13:18:55 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 21 Oct 1994 13:18:55 +0100 Subject: misleading diagnostic In-Reply-To: Your message of Thu, 20 Oct 1994 10:31:37 MST. <199410201731.AA07309@chl.isi.edu> Message-ID: <9410211218.AA27434@reif.ripe.net> > cengiz at ISI.EDU (Cengiz Alaettinoglu) writes: > > Below is an update request and reply from the database. > It contains three objects: > *rv: rs900.ra.net 3 > *rv: rs900.ra.net 30 > *rv: rs900.ra.net 300 > Reply is Update Ok for all three objects. > > I checked the database it only contains the last one (the first two > are marked with XX). I guess blanks in the key field caused this. I do not know what the "rv" object is. Can you send the config fragment for this? My guess is that your the rv attribute is parsed only to the first blank. Assuning that UNIQ is set to rv this means the updates concerned the same object. In this case the DB software did the right thing in acknowledgin all updates as successful. > What is more interesting entry with "*rv: rs2.ra.net 3" is also > deleted as a result of this query. Query or update? Daniel -------- Logged at Fri Oct 21 13:29:00 MET 1994 --------- From rlr at merit.edu Fri Oct 21 13:28:52 1994 From: rlr at merit.edu (Rick Riolo) Date: Fri, 21 Oct 1994 08:28:52 -0400 Subject: misleading diagnostic In-Reply-To: Your message of "Fri, 21 Oct 1994 13:18:55 BST." <9410211218.AA27434@reif.ripe.net> Message-ID: <199410211228.IAA06478@toad.merit.edu> Here is the config fragment for this local object (rv = rs-view = route-server-view): OBJ rv ATSQ rv de ai ao it io tc ac gd rm mb ch so OBJ rv MAND rv mb ch so OBJ rv OPT de ai ao it io tc ac gd rm OBJ rv MULT de ai ao it io rm mb ch OBJ rv SORT 12 OBJ rv UNIQ rt OBJ rv KEYS rt OBJ rv REC We didn't make any changes to any parsing/checking of the current (ripe81) routines (since we plan to move to ripe181 with our syntax checker soon), so we just got the 'default' parsing, I guess. In general in ripe181, do you think there would be a problem with allowing blanks in a key attribute? if so, we can use some other character. thanks. - r -------- > From: Daniel Karrenberg > To: cengiz at isi.edu (Cengiz Alaettinoglu) > CC: Rick Riolo , rr-impl at ripe.net > > > cengiz at ISI.EDU (Cengiz Alaettinoglu) writes: > > > > Below is an update request and reply from the database. > > It contains three objects: > > *rv: rs900.ra.net 3 > > *rv: rs900.ra.net 30 > > *rv: rs900.ra.net 300 > > Reply is Update Ok for all three objects. > > > > I checked the database it only contains the last one (the first two > > are marked with XX). I guess blanks in the key field caused this. > > > I do not know what the "rv" object is. > Can you send the config fragment for this? > > My guess is that your the rv attribute is parsed only to the first blank. > Assuning that UNIQ is set to rv this means the updates concerned the same > object. In this case the DB software did the right thing in acknowledgin all > updates as successful. > > > What is more interesting entry with "*rv: rs2.ra.net 3" is also > > deleted as a result of this query. > > Query or update? > > > Daniel -------- Logged at Fri Oct 21 13:33:45 MET 1994 --------- From Daniel.Karrenberg at ripe.net Fri Oct 21 13:33:43 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 21 Oct 1994 13:33:43 +0100 Subject: misleading diagnostic In-Reply-To: Your message of Fri, 21 Oct 1994 08:28:52 -0400. <199410211228.IAA06478@toad.merit.edu> Message-ID: <9410211233.AA27514@reif.ripe.net> > Rick Riolo writes: > Here is the config fragment for this local object > (rv = rs-view = route-server-view): Nice do you have the definition written up? After reading the comments in the config file you could have figured out the follwoing: > OBJ rv ATSQ rv de ai ao it io tc ac gd rm mb ch so > OBJ rv MAND rv mb ch so > OBJ rv OPT de ai ao it io tc ac gd rm > OBJ rv MULT de ai ao it io rm mb ch > OBJ rv SORT 12 should be unique > OBJ rv UNIQ rt OBJ rv UNIQ rv > OBJ rv KEYS rt OBJ rv KEYS rv > OBJ rv REC Maybe ? OBJ rv REC tc ac > In general in ripe181, do you think there would be a problem with allowing > blanks > in a key attribute? if so, we can use some other character. No. They are allowed if you don't do anything special. I just did not have enough info to know. > - r > > -------- > > > From: Daniel Karrenberg > > To: cengiz at isi.edu (Cengiz Alaettinoglu) > > CC: Rick Riolo , rr-impl at ripe.net > > > > > > cengiz at ISI.EDU (Cengiz Alaettinoglu) writes: > > > > > > Below is an update request and reply from the database. > > > It contains three objects: > > > *rv: rs900.ra.net 3 > > > *rv: rs900.ra.net 30 > > > *rv: rs900.ra.net 300 > > > Reply is Update Ok for all three objects. > > > > > > I checked the database it only contains the last one (the first two > > > are marked with XX). I guess blanks in the key field caused this. > > > > > > I do not know what the "rv" object is. > > Can you send the config fragment for this? > > > > My guess is that your the rv attribute is parsed only to the first blank. > > Assuning that UNIQ is set to rv this means the updates concerned the same > > object. In this case the DB software did the right thing in acknowledgin > all > > updates as successful. > > > > > What is more interesting entry with "*rv: rs2.ra.net 3" is also > > > deleted as a result of this query. > > > > Query or update? > > > > > > Daniel -------- Logged at Fri Oct 21 13:48:08 MET 1994 --------- From rlr at merit.edu Fri Oct 21 13:48:02 1994 From: rlr at merit.edu (Rick Riolo) Date: Fri, 21 Oct 1994 08:48:02 -0400 Subject: misleading diagnostic In-Reply-To: Your message of "Fri, 21 Oct 1994 13:33:43 BST." <9410211233.AA27514@reif.ripe.net> Message-ID: <199410211248.IAA06506@toad.merit.edu> Daniel, thanks for looking at that and noticing those problems. it didn't really have anything to do with reading or not reading the comments: I just cut, pasted and edited another object, probably rt, given the things you pointed out that I forgot to change! re REC, I don't think we will be storing records for ac and tc. (Dale?...) If we don't, should we just not include the OBJ x REC line at all? Am I right in thinking that the 'default' parsing in ripe81 just stops at a blank, which lead to the problem cengiz observed? - r -------- > From: Daniel Karrenberg > To: Rick Riolo > CC: cengiz at isi.edu (Cengiz Alaettinoglu), rr-impl at ripe.net > > > Rick Riolo writes: > > Here is the config fragment for this local object > > (rv = rs-view = route-server-view): > > Nice do you have the definition written up? > > > After reading the comments in the config file you could have figured > out the follwoing: > > > OBJ rv ATSQ rv de ai ao it io tc ac gd rm mb ch so > > OBJ rv MAND rv mb ch so > > OBJ rv OPT de ai ao it io tc ac gd rm > > OBJ rv MULT de ai ao it io rm mb ch > > OBJ rv SORT 12 > should be unique > > OBJ rv UNIQ rt > OBJ rv UNIQ rv > > OBJ rv KEYS rt > OBJ rv KEYS rv > > OBJ rv REC > Maybe ? > OBJ rv REC tc ac > > > > > In general in ripe181, do you think there would be a problem with allowing > > blanks > > in a key attribute? if so, we can use some other character. > > No. They are allowed if you don't do anything special. > > I just did not have enough info to know. > > > - r > > > > -------- > > > > > From: Daniel Karrenberg > > > To: cengiz at isi.edu (Cengiz Alaettinoglu) > > CC: Rick Riolo , rr-impl at ripe.net > > > > > > > > > cengiz at ISI.EDU (Cengiz Alaettinoglu) writes: > > > > > > > > Below is an update request and reply from the database. > > > > It contains three objects: > > > > *rv: rs900.ra.net 3 > > > > *rv: rs900.ra.net 30 > > > > *rv: rs900.ra.net 300 > > > > Reply is Update Ok for all three objects. > > > > > > > > I checked the database it only contains the last one (the first two > > > > are marked with XX). I guess blanks in the key field caused this. > > > > > > > > > I do not know what the "rv" object is. > > > Can you send the config fragment for this? > > > > > > My guess is that your the rv attribute is parsed only to the first blank. > > > Assuning that UNIQ is set to rv this means the updates concerned the same > > > object. In this case the DB software did the right thing in acknowledgin > > all > > > updates as successful. > > > > > > > What is more interesting entry with "*rv: rs2.ra.net 3" is also > > > > deleted as a result of this query. > > > > > > Query or update? > > > > > > > > > Daniel -------- Logged at Fri Oct 21 14:07:49 MET 1994 --------- From Daniel.Karrenberg at ripe.net Fri Oct 21 14:07:46 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 21 Oct 1994 14:07:46 +0100 Subject: misleading diagnostic In-Reply-To: Your message of Fri, 21 Oct 1994 08:48:02 -0400. <199410211248.IAA06506@toad.merit.edu> Message-ID: <9410211307.AA27708@reif.ripe.net> > Rick Riolo writes: > Daniel, > thanks for looking at that and noticing those problems. it didn't really h > ave anything > to do with reading or not reading the comments: I just cut, pasted and edi > ted another object, > probably rt, given the things you pointed out that I forgot to change! RT.M! ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) :-) > re REC, I don't think we will be storing records for ac and tc. (Dale?...) > If we don't, should we just not include the OBJ x REC line at all? I'd leave it in as a placeholder. > Am I right in thinking that the 'default' parsing in ripe81 just stops > at a blank, which lead to the problem cengiz observed? I don't think so although I am not absolutely sure without digging into the code. The problem is that the unique key identifying the object was generated from the "rt" attribute which probably was not present since it is not even allowed in "rv". Therefore the keys were equal, therefore the objects were equal, therefore they updated each other. Try putting rt in and see. Daniel -------- Logged at Fri Oct 21 19:48:42 MET 1994 --------- From rlr at merit.edu Fri Oct 21 19:48:19 1994 From: rlr at merit.edu (Rick Riolo) Date: Fri, 21 Oct 1994 14:48:19 -0400 Subject: misleading diagnostic In-Reply-To: Your message of "Fri, 21 Oct 1994 14:07:46 BST." <9410211307.AA27708@reif.ripe.net> Message-ID: <199410211848.OAA07104@toad.merit.edu> I have changed our conf file to have the rv's rather than rt's in the rs-view object, and things seem to be behaving better. I can add distinct objects with keys that are like those shown below (ie an dns address, a blank, and a number), and I can retrieve them. Note that, however, that the retrieval with value after the blank in the key retrieves both, but the retrieval with the number just gets the one object. at any rate, I think this will server cengiz's needs, since I think he will be adding a number to all of these if there are more than one. is that right, cengiz? - r ps This works with regular whois -- -S as well, of course. toad.merit.edu> /f/rrdb/dbase-beta/bin/whois -h toad -s TESTRR rs900.tra.net rs-view: rs900.tra.net 300 descr: Policies for view 3 of Route Server rs2.ra.net as-in: from AS1239 0 accept NOT ANY tech-c: elise gerich admin-c: bill manning guardian: bmanning at isi.edu remarks: This entry is created by RA analysis software. mnt-by: acts-of-god changed: cengiz at isi.edu 940919 changed: rlr at merit.edu 941021 source: TESTRR rs-view: rs900.tra.net descr: Policies for view 3 of Route Server rs2.ra.net as-in: from AS1239 0 accept NOT ANY tech-c: elise gerich admin-c: bill manning guardian: bmanning at isi.edu remarks: This entry is created by RA analysis software. mnt-by: acts-of-god changed: cengiz at isi.edu 940919 changed: rlr at merit.edu 941021 source: TESTRR toad.merit.edu> /f/rrdb/dbase-beta/bin/whois -h toad -s TESTRR rs900.tra.net 300 rs-view: rs900.tra.net 300 descr: Policies for view 3 of Route Server rs2.ra.net as-in: from AS1239 0 accept NOT ANY tech-c: elise gerich admin-c: bill manning guardian: bmanning at isi.edu remarks: This entry is created by RA analysis software. mnt-by: acts-of-god changed: cengiz at isi.edu 940919 changed: rlr at merit.edu 941021 source: TESTRR toad.merit.edu> -------- > From: Daniel Karrenberg > To: Rick Riolo > CC: cengiz at isi.edu (Cengiz Alaettinoglu), rr-impl at ripe.net > > > Rick Riolo writes: > > Daniel, > > thanks for looking at that and noticing those problems. it didn't really h > > ave anything > > to do with reading or not reading the comments: I just cut, pasted and edi > > ted another object, > > probably rt, given the things you pointed out that I forgot to change! > > RT.M! ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) ;-) :-) > > > re REC, I don't think we will be storing records for ac and tc. (Dale?...) > > If we don't, should we just not include the OBJ x REC line at all? > > I'd leave it in as a placeholder. > > > Am I right in thinking that the 'default' parsing in ripe81 just stops > > at a blank, which lead to the problem cengiz observed? > > I don't think so although I am not absolutely sure without digging into the > code. > > The problem is that the unique key identifying the object was generated > from the "rt" attribute which probably was not present since it is not > even allowed in "rv". Therefore the keys were equal, therefore the > objects were equal, therefore they updated each other. > > Try putting rt in and see. > > > Daniel -------- Logged at Wed Nov 16 20:16:45 MET 1994 ---------