From jimi at dxcoms.cern.ch Thu Jun 2 15:17:33 1994 From: jimi at dxcoms.cern.ch (Jean-Michel Jouanigot) Date: Thu, 2 Jun 1994 15:17:33 +0200 (MET DST) Subject: here's as far we have got. In-Reply-To: <199405311549.LAA00680@merit.edu> from "Jessica Yu" at May 31, 94 11:48:59 am Message-ID: <9406021317.AA15149@dxcoms.cern.ch> >----- Text sent by Jessica Yu follows ------- > Concerning Jessica's concern on the interas-out metric, I > do understand Merit's point of view, and it cannot really > be implemented as a local field since it's something the > tools will need when tracing inside 690... However, I'm > not still convince it fits very well with the current > scheme... I'm puzzled. The point is that we HAVE to > find a solution! > Actually, it fits quite well to the current scheme. interas-in/interas-out is for > neighbors to communicate more routing exchange information between them. It > seems natraul to allow ASs to specify pref/metric in interas-out. Thanks! Jessica, Tony, Daniel, (probably others) Since you are all at the regional-tech, I would propose you try to agree on: 1- We keep the as-in as-out stuff as it is 2- the interas-in/out will contain the IP router addresses AND the pref metric in interas-out. Hope it's not too much :-) PS: I still do beleive what Gilles suggested (no component) is sound. -- Jean-Michel. -------- Logged at Mon Jun 6 12:07:28 MET DST 1994 --------- From Daniel.Karrenberg at ripe.net Mon Jun 6 12:07:24 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 06 Jun 1994 12:07:24 +0200 Subject: here's as far we have got. In-Reply-To: Your message of Thu, 02 Jun 1994 15:17:33 MDT. <9406021317.AA15149@dxcoms.cern.ch> Message-ID: <9406061007.AA02416@reif.ripe.net> > jimi at dxcoms.cern.ch (Jean-Michel Jouanigot) writes: > > Jessica, Tony, Daniel, (probably others) > > Since you are all at the regional-tech, I would propose you try to > agree on: > > 1- We keep the as-in as-out stuff as it is > 2- the interas-in/out will contain the IP router addresses AND the > pref metric in interas-out. > PS: I still do beleive what Gilles suggested (no component) is > sound. > -- > Jean-Michel. We sat and discussed. Here is the outcome as I recall it. I was very tired so it may not be all that accurate in the details. ----------- About as-transit and the experimental doc: All objects about which there is no consensus that they should go into 81++ should be published as "experimental" RR stuff in one separate document called RR extensions or some such. The extensions document will be updated whenever there is a new extension. ripe-81++ shall have text pointing out that possibility and a way to find the newest version of the extensions document. This text is to be proposed by the MERIT folks a.s.a.p. The extensions document should always be a collection of *all* experimental extensions being used. as-transit goes in the experimental doc. Merit writes it up. ---------- About metrics in interas-out. There were two proposals: 1) represent outgoing metric information as a preference similar to the preference in interas-in: 2) represent outgoing metric information in a separate attribute After heated discussion we agreed that the outgoing metric (MED) is to be represented in the interas-out attribute (option 1). The syntax has to be such to prevent confusion between the outgoing preference representing a metric to be generated and the incoming preference representing a static preference in accepting mroutes. The latter is a fundamental concept of the RR which should not be made obscure or confused in any way. They syntax needs to accomodate metric values for different EGPs. As a minimum it must be specified which EGP is used and which of the EGP's metrics will be set. Merit is to propose a syntax a.s.a.p. This is only concerned with generating metrics and not with registering whether and how to use received metrics. While this is sufficient to generate *local* configurations it is not enough for a routing registry. In a routing registry the recipient of such metrics must be able to register whether and how he will use received metrics. Just generating a metric is not enough. Merit is to make a proposal for this at the same time. ------------- The component attribute seems to be too confusing to be useful after all. It has two uses: registering holes and registering information about heterogeneous aggregates. We all agree that registering holes, i.e. parts of a route to which the originator has no connectivity is a good thing. Gilles has proposed a special attribute "hole:" for this to make it clearer. We agreed to use the hole attribute. The other use of component is to register heterogeneuity of routes. Some have argued that membership information (AS, community) is either used in routing or it is not. If it is, one should not aggregate routes with difeerent membership information and create heterogeneous aggregates. If one does not do this, each route will be homogeneous and the hints provided via the component attribute are not needed. Gilles has put this argument very well. If this strategy is used routing and its description in the registry will be very clear. However, we believe that this strategy will not be used exclusively. It hurts aggregation efficiency badly. We strongly believe that some ASes will want to agggregate more agressively, accepting the loss in routing granularity that they and others will suffer as a consequence. In fact We belive that we should encourage such behavior for the sake of routing efficiency and scaling. Once such inhomogeneous aggregates are created and the more speicifc homogeneous routes withdrawn there is no information left about the routing granularity that existed before. The component attribute was designed to provide the originator of heterogeneous aggregates with a way of documenting the heterogenuity. Our expectation is that this would encourage routing efficiency because people would be more confident to aggregate if they had a way to document potential problems. Unfortunately the component attribute is less than clear and authorisation is a problem too. So let us look at another way of doing this: Introduce an attribute "withdrawn:" or "not routed" to the route object in order to specify that the route specified is not really originated. This solves the authorisation problem and is also easier to understand in the first place. The only problem with it is that it may be confusing in the second instance because seeing a route object does not automatically mean that the route described is originated somewhere. This could be solved by using a new object altogether for not originated routes. RIPE folks to make the proposals a.s.a.p. This will be early next week. If we do this the new "hole:" attribute and the "withdrawn:" attribute replace component. The only problem is that we loos the DMZ interface information that used to be in ias-int:. Laurent suggested to use a new "border-router" object for this. The advantage of this obviously is clarity. Everyone understands what a border router and its interfaces are. Merit is to write this up. We agreed to - throw away component (it was overloaded and unclear) - introduce "hole:" - introduce a way to have unannounced routes - either with a new attribute to the route object - or with a new object name altogether - document DMZ interfaces with a "border-router" object Comments ? Daniel -------- Logged at Mon Jun 6 13:46:54 MET DST 1994 --------- From jimi at dxcoms.cern.ch Mon Jun 6 13:46:42 1994 From: jimi at dxcoms.cern.ch (Jean-Michel Jouanigot) Date: Mon, 6 Jun 1994 13:46:42 +0200 (MET DST) Subject: here's as far we have got. In-Reply-To: <9406061007.AA02416@reif.ripe.net> from "Daniel Karrenberg" at Jun 6, 94 12:07:24 pm Message-ID: <9406061146.AA25493@dxcoms.cern.ch> Daniel, This is very clear to me. The general idea of having a companion document is fine with me, but the users should then be aware of which extensions the various tools will or won't implement. The other unresolved issue if how these "extensions" will be registered/supported into/by the RRs... -- Jean-Michel -------- Logged at Mon Jun 6 16:24:22 MET DST 1994 --------- From Daniel.Karrenberg at ripe.net Mon Jun 6 16:24:20 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 06 Jun 1994 16:24:20 +0200 Subject: here's as far we have got. In-Reply-To: Your message of Mon, 06 Jun 1994 13:46:42 MDT. <9406061146.AA25493@dxcoms.cern.ch> Message-ID: <9406061424.AA02714@reif.ripe.net> > jimi at dxcoms.cern.ch (Jean-Michel Jouanigot) writes: > > Daniel, > > This is very clear to me. The general idea of having a > companion document is fine with me, but the users should > then be aware of which extensions the various tools will > or won't implement. A matter for the tool documentation. > The other unresolved issue if how > these "extensions" will be registered/supported into/by > the RRs... A matter for the extension document itself. Daniel -------- Logged at Tue Jun 7 08:57:05 MET DST 1994 --------- From farrache at ccpnxt5.in2p3.fr Tue Jun 7 08:56:58 1994 From: farrache at ccpnxt5.in2p3.fr (Gilles Farrache) Date: Tue, 7 Jun 94 08:56:58 MET DST Subject: here's as far we have got. Message-ID: <9406070656.AA03977@ccpnxt5.in2p3.fr.> Daniel, Is the idea of the withdrawn attribute something like : This route is announced via the aggregated route without the assent of the AS realy originating the route ? Is the main difference with hole that the route is reachable but "not recommended" ? Or am I completly wrong ? Gilles -------- Logged at Tue Jun 7 09:22:43 MET DST 1994 --------- From Daniel.Karrenberg at ripe.net Tue Jun 7 09:22:41 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 07 Jun 1994 09:22:41 +0200 Subject: here's as far we have got. In-Reply-To: Your message of Tue, 07 Jun 1994 08:56:58 +0700. <9406070656.AA03977@ccpnxt5.in2p3.fr.> Message-ID: <9406070722.AA03332@reif.ripe.net> > farrache at ccpnxt5.in2p3.fr (Gilles Farrache) writes: > Daniel, > > This route is announced via the aggregated route without the assent > of the AS realy originating the route ? Is the main difference with > hole that the route is reachable but "not recommended" ? It means: There used to be a more specific route which is now withdrawn and part of an inhomogeneous aggregate. Example: University X has a Physics Dept. with a route in community HEPNET. University X now aggregates all its routes including the HEPNET one for efficiency. The University now has the option to keep the HEPNET route in the registry with the "withdrawn" attribute so that anyone whose routing policy depends on HEPNET can see that this happened and consider asking them to announce the more specific, or can do things locally if required. Clear? Daniel -------- Logged at Tue Jun 7 09:37:34 MET DST 1994 --------- From farrache at ccpnxt5.in2p3.fr Tue Jun 7 09:37:26 1994 From: farrache at ccpnxt5.in2p3.fr (Gilles Farrache) Date: Tue, 7 Jun 94 09:37:26 MET DST Subject: here's as far we have got. Message-ID: <9406070737.AA04013@ccpnxt5.in2p3.fr.> Clear Daniel Gilles -------- Logged at Tue Jun 7 09:38:54 MET DST 1994 --------- From Daniel.Karrenberg at ripe.net Tue Jun 7 09:38:52 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 07 Jun 1994 09:38:52 +0200 Subject: here's as far we have got. In-Reply-To: Your message of Tue, 07 Jun 1994 09:37:26 +0700. <9406070737.AA04013@ccpnxt5.in2p3.fr.> Message-ID: <9406070738.AA03458@reif.ripe.net> > farrache at ccpnxt5.in2p3.fr (Gilles Farrache) writes: > Clear Daniel OK. Then we put this example in the text ;-). Daniel -------- Logged at Sat Jun 11 01:25:04 MET DST 1994 --------- From eric at enfm.utcc.utoronto.ca Sat Jun 11 01:24:46 1994 From: eric at enfm.utcc.utoronto.ca (Eric M. Carroll) Date: Fri, 10 Jun 1994 19:24:46 -0400 Subject: first time building alc under gcc Message-ID: <94Jun10.192449edt.607244@enfm.utcc.utoronto.ca> Hi, I am not on the mailing list as yet, so please reply to me. I picked up the version of alc on rrdb.merit.edu and tried to build it. After cleaning up some file locations, a prototype conflict and a typo, all in the first couple of files, I hit: gcc -g -DLEXDEBUG -DYYDEBUG -Bstatic -I/opt/gnu/include -L/opt/gnu/lib -target sun4 -c debug.c debug.c: In function `dump_htinst_obj': debug.c:296: invalid lvalue in unary `&' debug.c:304: invalid lvalue in unary `&' debug.c:312: invalid lvalue in unary `&' gcc: file path prefix `static' never used *** Error code 1 make: Fatal error: Command failed for target `debug.o' After looking at it for a minute, I thought I would ask before diving in. Do I have the most recent code version? Has anyone built this with gcc before, and are there patches to enable a clean gcc build as yet? Thanks, Eric Carroll University of Toronto Computing & Communications Network & Operations Services CA*NET/ONet Network Engineering -------- Logged at Mon Jun 13 15:24:04 MET DST 1994 --------- From lpj at merit.edu Mon Jun 13 15:23:58 1994 From: lpj at merit.edu (Laurent Joncheray) Date: Mon, 13 Jun 94 9:23:58 EDT Subject: first time building alc under gcc In-Reply-To: <94Jun10.192449edt.607244@enfm.utcc.utoronto.ca>; from "Eric M. Carroll" at Jun 10, 94 7:24 pm Message-ID: <199406131323.JAA11728@merit.edu> Hi, that's funny, on Friday i tried for the first time to build acl with gcc and i got the same errors :-) I corrected them and the new code will be released this week. Laurent PS: do you know how to get rid of those "file path prefix `static' never used" warnings? > > Hi, > > I am not on the mailing list as yet, so please reply to me. I picked up > the version of alc on rrdb.merit.edu and tried to build it. After > cleaning up some file locations, a prototype conflict and a typo, all > in the first couple of files, I hit: > > gcc -g -DLEXDEBUG -DYYDEBUG -Bstatic -I/opt/gnu/include -L/opt/gnu/lib -target sun4 -c debug.c > debug.c: In function `dump_htinst_obj': > debug.c:296: invalid lvalue in unary `&' > debug.c:304: invalid lvalue in unary `&' > debug.c:312: invalid lvalue in unary `&' > gcc: file path prefix `static' never used > *** Error code 1 > make: Fatal error: Command failed for target `debug.o' > > After looking at it for a minute, I thought I would ask before diving > in. Do I have the most recent code version? Has anyone built this > with gcc before, and are there patches to enable a clean gcc build as > yet? > > Thanks, > > Eric Carroll University of Toronto Computing & Communications > Network & Operations Services > CA*NET/ONet Network Engineering > -- 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 Mon Jun 20 22:36:36 MET DST 1994 --------- From dsj at merit.edu Mon Jun 20 22:36:32 1994 From: dsj at merit.edu (Dale S. Johnson) Date: Mon, 20 Jun 1994 16:36:32 -0400 Subject: Brainstorm on guarded information Message-ID: <199406202036.QAA21677@merit.edu> Marten, This was good--#3 is delightful. Any more thoughts or progress on this in the last month? --Dale ========================================================================= > From marten at ripe.net Thu May 19 07:48:29 1994 > Received: from ncc.ripe.net (ncc.ripe.net [192.87.45.2]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id HAA02723; Thu, 19 May 1994 07:48:27 -0400 > Received: from rijp.ripe.net by ncc.ripe.net with SMTP > id AA07470 (5.65a/NCC-2.2); Thu, 19 May 1994 13:48:23 +0200 > Received: from localhost.ripe.net by rijp.ripe.net with SMTP > id AA02896 (5.65a/NCC-2.2); Thu, 19 May 1994 13:48:23 +0200 > Message-Id: <9405191148.AA02896 at rijp.ripe.net> > To: rr-impl at ripe.net > Subject: Brainstorm on guarded information > From: Marten Terpstra > X-Organization: RIPE Network Coordination Centre > X-Phone: +31 20 592 5064 > X-Fax: +31 20 592 5090 > Date: Thu, 19 May 1994 13:48:22 +0200 > Sender: Marten.Terpstra at ripe.net > Status: RO > > > Folks, > > As said yesterday, I have written up some ideas on how to implement > the idea of guarded information. I have worked out the current > procedure in more detail than others below, simply because we have > some experience with it. You will also see this could be the most > complicated in a new ripe-81++ type scheme. We feel most for option 3 > in the text below. > > Let's have some discussion. > > -Marten > > These are some ideas on how the principle of guarded attributes and > objects can be implemented. All of this is in light of the ripe-81++ > proposal for the route and autonomous system number. It deals mainly > with the interface the guardian will have to the database, and how > guarded information will be included in the database. > > These are very rough ideas. The first thing I want to get a feel of is > what direction to go to. Details about implementation are not yet an > issue, altough of course we have to keep in mind that whatever > procedure we choose it can be implemented ;-) > > Some general remarks: > > - up till now, there has been a distinction between guarded attributes > and guarded objects. If at all possible we should look for one method > that can implemenent both. > > - we will have to find a balance between what is reasonably easy to > implement, operate and usable for guardians. > > > 1- The guarded file method > > This is basically the method as we have things now. Guarded attributes > and objects are dealt with in different ways. Guarded attributes > through the once a day examination of the files, guarded objects by > means of the authorisation. > > I can currently see a few disadvantages: > > - guarded attributes are added only once a day > - guarded attributes that change will be removed from normal updates > - scaling issues with respect to guardian accounts > - guarded objects have to be dealt with differently > > With the introduction of the route object, some more disadvantages can > be found: > > - in the current inetnum object, the "aut-sys" attribute is optional. > That means that whenever an object is send in with an aut-sys > different than the current value it can be reset or ignored. > Specifically in the case of new entries, the aut-sys will be removed. > In the route object however, the "origin" attribute is mandatory. That > means that for a new route object the origin cannot be ignored because > that would invalidate the object. > > There is of course a way around that. One way would be to leave the > once a day update mechanism and move to an on-the-fly guardian check. > That means whenever an object is send in, the referenced guardian file > is checked to see if it is allowed, and accepted if OK, bounced if > NOK. Then another problem arises, because this means you will have to > synchronize the updating of guardian files and the updating of route > objects. The file must be updated first before a route object can be > added. Some people I spoke with saw this as a problem. Solution for > this would be to put the update request on hold if NOK, through some > requeing mechanism, and bounce if after a day it still fails. Another > solution mentioned was to accept the objects, but keep them hidden, > and still do a nightly run to find all these objects and "unhide" > them. I am not too fond of either of these solutions, although the > requeueing is the best of the two. > > The complexity for the old but updated guarded file solution could get > out of hand quite quickly I would think. > > 2- Modified guarded files > > Another solution that keeps the guardian account principle could be to > change the format of the guardian file. Why should the guardian file > only contain pointers to objects and not the objects themselves. So, > in stead of guardians sending in objects and then check the files, > they simply keep a file with all their objects on the database > machine. On the database machine a daemon would scan around all > guardian files every X minutes to find files that have been changed > and update the information in that file. There can of course some > refinements in the way the file is handled but that does not change > the general principle. Advantages in my view are abvious: > > - definately guarded > - no one a night procedure > - no difficult checking for the database software > - can be refined in many ways > - the difference between guarded objects and attributes dissapears > > Disadvantages: > > - updates will not be immediate but can take X minutes > > There may be some other disadvantages, but many of them I can can be > resolved by adding refinements to the file(s) the guardian keeps and > the way the file is handled for updates. > > 3- Authentication in updates > > The perhaps most obvious solution is to do authentication on the > updates people send in. In our case there would be some authentication > in the mails people send there updates in, or even as far as per > object. This could be implemented as simple as a magic string per mail > where the string identified the guardian, or more complicated things like > PEM or what have you. My vote would be to keep this as light but > secure as possible. Obvious advantages: > > - no need for guardian accounts and files > - no special procedures for guardians, they simply send in updates as > they always would, just include some magic > - less complexity and administration for database maintainer > - the difference between guarded attributes and objects dissapears -------- Logged at Tue May 3 14:39:18 MET DST 1994 --------- From lpj at merit.edu Thu Jun 23 20:42:48 1994 From: lpj at merit.edu (Laurent Joncheray) Date: Thu, 23 Jun 94 14:42:48 EDT Subject: New Syntax Checker for the Routing Registries Message-ID: <199406231842.OAA24061@merit.edu> Hi folks, the ALC daemon now accepts updates of the DB on the fly. As a side effect it can check the syntax of the objects (without registering them) peolpe submit. Is anybody interested in hacking dbupdate so it uses alcd to check the syntax instead of the syntax.pl stuff (C.f "This is the really ugly bit")? The yacc parser ALC uses is a lot more rebust than the perl code (IMHO). The protocol to talk to alcd is very simple, we just need to send the object description (: format) and look for error messages from alcd. Laurent PS: maybe i should have sent my mail to /dev/null directly? :) -------- Logged at Thu Jun 23 21:24:15 MET DST 1994 --------- From Marten.Terpstra at ripe.net Thu Jun 23 21:24:06 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Thu, 23 Jun 1994 21:24:06 +0200 Subject: New Syntax Checker for the Routing Registries In-Reply-To: Your message of Thu, 23 Jun 1994 14:42:48 EDT. <199406231842.OAA24061@merit.edu> Message-ID: <9406231924.AA05656@rijp.ripe.net> Laurent Joncheray writes * Hi folks, the ALC daemon now accepts updates of the DB on the fly. * As a side effect it can check the syntax of the objects (without registering * them) peolpe submit. * Is anybody interested in hacking dbupdate so it uses alcd to * check the syntax instead of the syntax.pl stuff (C.f "This is the really ugl * y bit")? The yacc parser ALC uses is a lot more rebust than the * perl code (IMHO). Perhaps true in a sense, but will it also do on-the-fly corrections and suggestions on what the error can be like the syntax.pl code? Also, the mix between C and perl code makes me shiver. I generally do not like mixing all sorts of types when everything can be done with one. This is not a gripe against alc, but a very general remark. Fact is that we do not have the time to re-implement everything in C. -Marten PS a very rough prototype of classless indexing in Perl is working. We hope to have a beta classless database running the end of next week. It uses a home-made algorithm to store and find more and less specific addresses. -------- Logged at Tue Jun 28 11:52:45 MET DST 1994 --------- From Daniel.Karrenberg at ripe.net Tue Jun 28 11:51:43 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 28 Jun 1994 11:51:43 +0200 Subject: WE ARE ONE WEEK BEHIND SCHEDULE ALREADY FOR RIPE-81++ Message-ID: <9406280951.AA08812@reif.ripe.net> Can we have the text that MERIT agreed to produce so that we can finalise ripe-81++ for the comment period please. Daniel -------- Logged at Tue Jun 28 11:57:52 MET DST 1994 --------- From farrache at ccpnxt5.in2p3.fr Tue Jun 28 11:57:43 1994 From: farrache at ccpnxt5.in2p3.fr (Gilles Farrache) Date: Tue, 28 Jun 94 11:57:43 MET DST Subject: WE ARE ONE WEEK BEHIND SCHEDULE ALREADY FOR RIPE-81++ Message-ID: <9406280957.AA13963@ccpnxt5.in2p3.fr.> Daniel, Is it possible to have the part you have written in order to start the discussion ? Gilles -------- Logged at Tue Jun 28 12:48:44 MET DST 1994 --------- From Daniel.Karrenberg at ripe.net Tue Jun 28 12:48:39 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 28 Jun 1994 12:48:39 +0200 Subject: WE ARE ONE WEEK BEHIND SCHEDULE ALREADY FOR RIPE-81++ In-Reply-To: Your message of Tue, 28 Jun 1994 11:57:43 +0700. <9406280957.AA13963@ccpnxt5.in2p3.fr.> Message-ID: <9406281048.AA08837@reif.ripe.net> > farrache at ccpnxt5.in2p3.fr (Gilles Farrache) writes: > > Is it possible to have the part you have written in order to start > the discussion ? I prefer to have a discussion about a complete document at this stage. -------- Logged at Tue Jun 28 15:10:31 MET DST 1994 --------- From lpj at merit.edu Tue Jun 28 15:10:24 1994 From: lpj at merit.edu (Laurent Joncheray) Date: Tue, 28 Jun 94 9:10:24 EDT Subject: WE ARE ONE WEEK BEHIND SCHEDULE ALREADY FOR RIPE-81++ In-Reply-To: <9406280951.AA08812@reif.ripe.net>; from "Daniel Karrenberg" at Jun 28, 94 11:51 am Message-ID: <199406281310.JAA12810@merit.edu> I think Jessica sent it to you. If not i can resent it. She is on vacation for 1 week so maybe we can wait until next week before starting the game? Laurent > > Can we have the text that MERIT agreed to produce so that we can > finalise ripe-81++ for the comment period please. > > Daniel > -- Laurent Joncheray, E-Mail: lpj at merit.edu Merit Network Inc, 1071 Beal Avenue, Phone: +1 (313) 936 2065 Ann Arbor, MI 48109, USA Fax: +1 (313) 747 3745 "This is the end, Beautiful friend. This is the end, My only friend, the end" JM -------- Logged at Tue Jun 28 15:27:00 MET DST 1994 --------- From Daniel.Karrenberg at ripe.net Tue Jun 28 15:26:47 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 28 Jun 1994 15:26:47 +0200 Subject: WE ARE ONE WEEK BEHIND SCHEDULE ALREADY FOR RIPE-81++ In-Reply-To: Your message of Tue, 28 Jun 1994 09:10:24 EDT. <199406281310.JAA12810@merit.edu> Message-ID: <9406281326.AA09123@reif.ripe.net> > Laurent Joncheray writes: > I think Jessica sent it to you. If not i can resent it. She is on > vacation for 1 week so maybe we can wait until next week before > starting the game? > Laurent > I have seen nothing. If we want this agreed before the IETF we have to hurry! -------- Logged at Wed Jun 29 16:53:01 MET DST 1994 --------- From epg at merit.edu Wed Jun 29 16:52:48 1994 From: epg at merit.edu (Elise Gerich) Date: Wed, 29 Jun 1994 10:52:48 -0400 Subject: text about experimental attributes Message-ID: <199406291452.KAA07868@merit.edu> Daniel, Here is the proposed text about experimental attributes. We would hope that this would be embedded in RIPE 81 ++ --Elise --------------------proposed text--------------------- We envision that over time the requirements for describing routing policy will evolve. The routing protocols will evolve to support the requirements and the routing policy description syntax will need to evolve as well. For that purpose, a separate document will describe experimental syntax definitions for policy description. This document will be updated when new objects or attributes are proposed or modified. Two new attributes of the AS object which are proposed and supported by the Merit Routing Registry are as-transit and db-selector. as-transit describes the transit preferences of an AS. It allows an AS to describe its path preference in order to reach certain destinations. The AS(s) specified in the path preference may or may not be an immediate neighbor of the AS defined in the AS object. as-transit accommodates policy decisions involving AS path whereas as-in and as-out do not. It is not unusual for ASs to have routing policies which involve path selection based on AS. Emerging protocols like SDRP will allow an AS to choose a path independent of a neighboring ASs path choice. as-transit permits descriptions based on AS path selection. The DataBase Selector (db-selector) function allows one to take advantage of information registed in other Registries. It permits the selection of networks in a database based on their attributes. It is proposed to be used within the as-in/as-out attribute family to make the description of policy concise. For example, if an AS has the policy of not accepting any routes from country XYZ, the AS can use the db-selector to check a database which has a network and country attribute and relate that information to the information in the routing registry. The advantage of referencing another database is that the routing registry will avoid duplicating the information maintained in other imformation registries. Detailed examples and syntax are described in document xxxx. -------- Logged at Thu Jun 30 23:01:05 MET DST 1994 --------- From epg at merit.edu Thu Jun 30 23:00:52 1994 From: epg at merit.edu (Elise Gerich) Date: Thu, 30 Jun 1994 17:00:52 -0400 Subject: list of reserved words Message-ID: <199406302100.RAA25547@merit.edu> Hi, Did you all just want a list of the "sugar" words or did you also need keywords like ANY, ALL, etc? Here is a list of the "sugar." --Elise ------------------------------------------------------------------ Reserved Words The following list of words are reserved for use within the attributes of the AS object. The use of these words is solely for the purpose of clarity. All keywords must be capitalized. ACCEPT ANNOUNCE EXCLUDE FROM TO TRANSIT Examples of the usage of the reserved words are: as-in: FROM neighborAS ACCEPT route as-out: TO neighborAS ANNOUNCE route as-exclude: EXCLUDE ASpath TO destination as-transit: TRANSIT ASpath TO destination default: FROM neighborAS ACCEPT route default: TO neighborAS ANNOUNCE route -------- Logged at Fri Jul 1 22:24:48 MET DST 1994 ---------