- routing-wg - mailman.ripe.net

AlterNet now doing BGP4 w/ THEnet, PSI, NEARnet, IIJ, NSFNET, ...
by asp＠uunet.uu.net 23 Feb '94

23 Feb '94

AlterNet is now doing BGP4 with additional peers. We are now doing BGP4 with the following peers: CERN/1133 ESnet/293 EUnet/286 ICMnet/1800 IIJ/2509 NEARnet/560 PIPEX/1849 PSInet/174 SprintLink/1239 THEnet/114 TIPnet/1729 Route-Server-Europe/1879 NSFNET/690 (Both ENSS136 & ENSS134) We are not (yet) doing BGP4 with these peers: BARRNet/200 Unknown status CIX/1280 Unknown status DataNet/1759 In the process of deploying Demos/2578 Needs gated w/ BGP4 SURAnet/86 In the process of deploying UUNET-Canada/813 In the process of deploying Route-Server-Merit/183 Unknown status Here are the current CIDR routes that we are seeing: Washington.DC.Alter.Net>show ip bgp cidr BGP table version is 350917, local router ID is 137.39.4.129 Status codes: s suppressed, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *>i192.64.100.0/22 134.222.5.1 100 100 286 1891 ? *>i192.78.186.0/23 134.222.5.1 100 100 286 1891 ? *> 192.87.136.0/22 192.41.177.241 0 100 1800 1755 1128 1103 1125 i * 192.41.177.240 0 100 1800 1755 1128 1103 1125 i *> 192.91.242.0/23 192.41.177.241 0 100 1800 1755 513 i * 192.41.177.220 0 100 1800 1755 513 i *>i192.244.184.0/21 137.39.224.66 100 100 2509 2497 i *>i192.250.24.0/22 134.222.5.1 100 100 286 1890 i *>i193.0.128.0/20 137.39.1.24 100 100 704 1880 i *>i193.0.160.0/20 137.39.1.24 100 100 704 1880 i *>i193.0.192.0/20 137.39.1.24 100 100 704 1880 i *>i193.0.224.0/20 137.39.1.24 100 100 704 1880 i *> 193.10.8.0/23 192.41.177.241 0 100 1800 1755 1653 2836 i * 192.41.177.240 0 100 1800 1755 1653 2836 i *> 193.44.24.0/22 192.41.177.241 0 100 1800 1755 1653 2836 i * 192.41.177.240 0 100 1800 1755 1653 2836 i *>i193.67.128.0/22 134.222.5.1 100 100 286 1890 i *>i193.74.160.0/20 134.222.5.1 100 100 286 1891 ? *>i193.74.176.0/23 134.222.5.1 100 100 286 1891 ? *>i193.74.192.0/22 134.222.5.1 100 100 286 1891 i *>i193.74.200.0/23 134.222.5.1 100 100 286 1891 i *>i193.74.234.0/23 134.222.5.1 100 100 286 1891 i *>i193.74.236.0/23 134.222.5.1 100 100 286 1891 i *>i193.74.238.0/23 134.222.5.1 100 100 286 1891 i *>i193.74.250.0/23 134.222.5.1 100 100 286 1891 ? *>i193.78.32.0/21 134.222.5.1 100 100 286 1890 i *>i193.78.72.0/22 134.222.5.1 100 100 286 1890 i *>i193.78.104.0/22 134.222.5.1 100 100 286 1890 i *>i193.78.120.0/23 134.222.5.1 100 100 286 1890 i *>i193.242.80.0/21 134.222.5.1 100 100 286 i *> 194.12.128.0/21 192.41.177.241 0 100 1800 1755 513 i * 192.41.177.240 0 100 1800 1755 513 i * i198.84.4.0/22 137.39.1.14 0 100 100 ? *>i 137.39.1.14 0 100 100 ? * i 137.39.1.14 0 100 100 ? *> 199.1.254.0/23 144.228.1.39 100 1239 ? * 192.41.177.241 0 100 1800 1239 ? * 192.41.177.240 0 100 1800 1239 ? -- Jean-Michel

1 0

BGP4 path attribute (sorry)
by jimi＠dxcoms.cern.ch 18 Feb '94

18 Feb '94

Folks, Forget about my previous message. I did not intend to send all this stuff to the list, but just the last paragraph. Sorry again, -- Jean-Michel Another point: the previous drafts of BGP4 were introducing a "BGP path attribute" which was carried together with the route. In some recent extensions of Ripe-81, and after some discussions with Peter Lothberg and Tony Bates, it appeared to us that this could be used to "color" network advertisements and carry this information thru the Internet. Any reason why you've dropped the idea ? Yes, it tends to break aggregation. Since you can't aggregate colored routes together, it would cause people to not aggregate. This would increase the size of the routing tables. Tony -- Jean-Michel

1 0

BGP4 path attribute
by jimi＠dxcoms.cern.ch 18 Feb '94

18 Feb '94

>----- Text sent by Tony Li follows -------

1 0

BGP4/CIDR/aggregation presentations (fwd)
by jimi＠dxcoms.cern.ch 18 Feb '94

18 Feb '94

>----- Text sent by Andrew Partan follows -------

1 0

BGP4 and 9.21
by Tony Li 16 Feb '94

16 Feb '94

From: jimi(a)dxcoms.cern.ch (Jean-Michel Jouanigot) Tony, Sorry to bother you, but I have two questions concerning BGP4 and 9.21 (Feb5). I think I've discovered something odd. You should use bgp4-support instead, please. I have nothing to do with BGP4. Firstly, I'm currently playing with BGP4 on our DMZ, on which we used to run BGP3 for a while. I configured one test box as talking BGP4 with all the other boxes, some of them being in the same AS (513), some other in different ASes (1755). When I did this, I kept all the defaults in the BGP4 configurations. 2043 | | +----+ +----+ +----+ +-----+ |EBS | |H3 | |H2 | |TEST | |1755| |513 | |513 | |513 | ...... +----+ +----+ +----+ +-----+ | | | | | | | | 192.65.185.0 -------------------------------------------------- All boxes but TEST peer using BGP3. The next hop for them is always on 192.65.185.0 when they want to reach a net connected thru onother router. For TEST, things are different. Suppose TEST wants to route to 192.87.45.1: ctest1>sh ip bgp 192.87.45.1 BGP routing table entry for 192.87.45.0/255.255.255.0, version 5684 Paths: (2 available, best #1) 2043 1103 1104 193.172.24.9 from 192.65.185.5, weight 0 Origin IGP, valid, internal, best 1755 1128 1103 1104 192.65.185.4 from 192.65.185.4, metric 8481, weight 0 Origin IGP, valid, external The Prefered path is the shortest, 2043 1103 1104, but the next hop is 193.172.24.9, which happens to be the interface of 2043, but ctest1>sh ip ro 193.172.24.9 Routing entry for 193.172.24.0 (mask 255.255.255.0) Known via "bgp 513", distance 20, metric 8481 Tag 1755 Last update from 192.65.185.4 1:42:07 ago Routing Descriptor Blocks: * 192.65.185.4, from 192.65.185.4, 1:42:07 ago Route metric is 8481, traffic share count is 1 That's a bug. The routing table should always reflect the "best" route. since ctest1>sh ip bgp 193.172.24.9 BGP routing table entry for 193.172.24.0/255.255.255.0, version 8755 Paths: (1 available, best #1) 1755 1128 2043 192.65.185.4 from 192.65.185.4, metric 8481, weight 0 Origin IGP, valid, external, best OK, your going to tell me that 2043 should announce 193.172.24.0 to H3, or that we can fix this using next-hop-self or route maps, but still, it's not what I understand from the BGP4 draft: "A BGP speaker can advertise any external border router as the next hop [1], provided that the IP address of this border router was learned from one of the BGP speaker's peers, [2] and the interface associated with the IP address of this border router (as specified in the NEXT_HOP path attribute) shares a common subnet with the local and remote BGP speakers [3]." [1] this is our case [2] yes, from 1755 [3] No, the interconnection network is 192.65.185.0, and the interconnection between 2043 and 513 is in 193.172.24.0 Am I wrong ? Of course, the routes received from 1755 were all indicating a NEXT_HOP on 192.65.185.0. This question only concerns routes within 513. Another question I have is why is this new concept introduced in BGP4? What's the idea behind this? Who's using it? This is very dangerous in the sense that if a network is not announced by an external peer (2043 in my case), then all the routing is gone... Another point: the previous drafts of BGP4 were introducing a "BGP path attribute" which was carried together with the route. In some recent extensions of Ripe-81, and after some discussions with Peter Lothberg and Tony Bates, it appeared to us that this could be used to "color" network advertisements and carry this information thru the Internet. Any reason why you've dropped the idea ? Yes, it tends to break aggregation. Since you can't aggregate colored routes together, it would cause people to not aggregate. This would increase the size of the routing tables. Tony -- Jean-Michel

1 0

BGP4/CIDR/aggregation presentations
by asp＠uunet.uu.net 11 Feb '94

11 Feb '94

These are some notes that I made as I was preparing my presentations for the RegTechs meeting in San Diego Jan31/Feb 1. I have revised them (some what) in light of some of the conversations & presentations made at the RegTechs meeting. There are undoubtably holes & inaccuracies in these notes; please correct any that you see. --asp(a)uunet.uu.net (Andrew Partan) BGP4 deployment status There are not that many folks that have deployed BGP4 yet. This is not good. So far, AlterNet, Ebone, SprintLink, ICMnet, EUnet, TIPnet, PIPEX, and AS1133 (CERN) have deployed BGP4 (that I know of). ANS is behind their announced schedule. This list is incomplete (I sure hope that there are other folks out there that are running BGP4 that I do not know of). Europe seems to be further ahead than the US (I have heard that a number of European networks are using BGP4; but I don't have a list). Not all of these folks are running BGP4 between them yet - e.g.: the AlterNet/AS1133 link is still BGP3. People are not making public their BGP4 deployment plans, nor are they making their routing plans public (ala the RIPE routing registry database). Without this data, it is really hard to know when or if we can announce CIDR routes safely. There are already CIDR-routes (non A/B/C routes) that are being announced in the Internet today. When I last checked (Sunday 1/30/94), all but one of the more specific routes (the A/B/C nets) were also being announced. BGP4 is real; BGP4 works; people need to deploy it; people need to deploy it now. We still don't know all of the folks that need to deploy BGP4. We still don't know what will break if CIDR routes are used. Implementation status: Cisco code is working & deployed in most of the nets that are running BGP4. Gated code is working & deployed on AS 1133. 3com code is working on the BGP4 test net. I don't know the status of any other code. Why is it so important that we get BGP4 & CIDR working & working now? Routing table growth. 16 Meg ciscos may only be able to support 25K-30K routes. [The jury is still out on this one; cisco is continuing to improve their code to put more routes into the same amount of memory. cisco is also looking at 64 Meg routers.] Peter Lothburg took a look at his routers (Ebone & ICMnet) and found that he could only support approx 18K routes total! On ciscos (at least), the number of routes that you can support depends on how much free memory you have - memory is used for the forwarding table, the routing table, and for updates (and other things). The more destinations you see the larger your forwarding table is - so central routers (like ICMnet & Ebone) will have more memory used for forwarding tables. Routing table size is the total number of routes you have plus how many different paths you have to each of those routes (the Ebone and ICMnet see nearly every route with something like 5 paths). Routing updates use memory for both incoming updates from your peers (eBGP & iBGP) and for outgoing updates (most notably for iBGP peers - since every incoming update from an eBGP peer is (typically) sent to every iBGP peer). The more routing updates you get (the more unstable the overall network is), the more memory you will use. Central routes tend to see lots more updates (this is not entirely true since cisco's BGP4 code has some dampening of updates - they delay forwarding updates for a short while, so that if a net goes down & then back up fairly quickly, you may not see any update at all downstream). When ciscos start running out of memory, they try to conserve memory by delaying processing of incoming updates and sending of outgoing updates (rather than just hitting the wall & tipping over). This means that routing may take longer to stablize & may not ever stablize as things get really bad. In any case, Peter's routers have about 1.9 Meg free today; AlterNet routers have approx 4 Meg free - the same number of total routes, but different routing policy and (probably) fewer destinations, updates, and paths. The ANS ENSSs may only be able to support 25K routes. [ANS thinks that they can up this by another 5K routes to a total of 30K.] We are now at 16,788 routes (as of 1/30/94 17:00 EST). [17,410 as of 2/11/94, 14:00 EST.] I did some analysis of routing table growth from a number of different angles, and all pointed to running out of memory by mid summer (unless we do something). [This used 25K as the drop dead date - we should be hitting 18K in about 1.5-2 weeks.] The growth rate seems to be 1000 net every 3 weeks. [I looked at routing table sizes & growth over the last few months; also at current doubling time (9 months; ref ALE working group); also at free memory usage in my routers. All of my projections came out with approx the same drop dead date of mid summer. I also did not leave any memory for things like packets, so my dates are overly optimistic.] [I also looked at some data provided by Merit (their active net counts), and their projections agree very closely with mine - approx mid summer for 25K routes and 1000 nets every 3 weeks.] We need to attack the routing table size on a number of fronts - router vendor code changes (to use less memory per route), router hardware changes (to add more memory), changes in routing policies (things like more use of default routes & suboptimal routing), newer routing protocols (that do not need full routing tables on a large number of routers; things like route servers), and BGP4/CIDR deployment. The one that seems to be the easiest & quickest to deploy is BGP4/CIDR. The problem is that if I CIDRize my own routes, I can save about 1000 routes in my own tables (and push death off by maybe a month or so). I need you to CIDRize your routes to save space in my routing tables. I could also proxy aggregate your routes, but proxy aggregation is hard. If I hear your routes via several possible paths, and if the same aggregation is not done in the same way on all of the paths, then traffic may go over suboptimal paths (since traffic always takes a more specific route over a less specific route). Proxy aggregation is doubly hard, if I don't know about all of the possible paths that I could hear your routes over. [There was some discussion about where it was safe (or safer) to do proxy aggregation - basically it all boils down to knowing the (local) topology and lots of communication between the parties involved.] This gets to routing registries. People have to publish their routing policies in some public place so that other people can look at these policies and try to figure out if some change that they are contemplating (like announcing CIDR routes) will cause problems elsewhere in the Internet. These routing policies need to be in some common format, so that tools can use them. The only such database that I know of is the RIPE database. People should use this. Two folks from RIPE will be giving a talk on this later (Daniel Karrenburg & Tony Bates). [Merit will also be doing a routing policy database & is going to coordinate with the RIPE folks. The Merit & RIPE folks should be able to say more on this.] A bit more on proxy aggregation. If you know the local topology well enough, and if there is communications & coordinations among the people involved, you can do proxy aggregation safely. A couple of examples: BGP4 network 'B' connects to non-BGP4 stub network 'S'. S has no other connections to the rest of the world. B --- S B can do proxy aggregation of S's nets. [Note that B can probably proxy aggregate w/o even talking to S, but this is probably a bad idea.] BGP4 network 'B' connects to non-BGP4 network 'S'. 'S' has just one other connection to non-BGP4 network 'T'. T has no other connections to the rest of the world. B --- S --- T B can do proxy aggregation of S's and T's nets. BGP4 network 'A' connects to non-BGP4 network 'S'. BGP4 network 'B' connects to non-BGP4 network 'S'. S has no other connections to the rest of the world. A --- S --- B A & B can do proxy aggregation of S's nets. Note that A and B need to do the *same* proxy aggregation, or things may not work (routing follows the most specific route). There are other examples; they all depend on complete knowledge of the (local) topology and coordination between all of the parties involved. Obviously as the topology gets more complex, and the number of parties grows, this gets to be a harder & harder problem. Some of the conclusions on deployment of BGP4/CIDR People are deploying BGP4; the code seems to be working just fine. People are going to be announcing CIDR routes and doing proxy aggregation fairly shortly (like w/in the next week or so). Partially this is a matter of self defense, so that routers don't tip over. It looks like things will work, if there is a large enough BGP4 core, and if people are either part of the BGP4 core or have a default route to the BGP4 core, or have a default route to someone who has a default route to the BGP4 core (basically a path of defaults, all going towards the BGP4 core). I think that the sites that are currently doing BGP4 form a large enough core for things to work. If ANS can get things working to join the BGP4 core, then things will be better; however ANS already has code deployed that can use a default route (most likely to AS1133). It would also be very useful for the CIX-West routers to be part of the BGP4 core. I also think that everyone either is already part of the BGP4 or has a default route towards it. This point was brought up at the RegTechs meeting, and no one voiced any objections. So, I think (& hope) that we are in (more-or-less) good shape. The next step: publish your plans for BGP4 and CIDR! -- Jean-Michel

1 0

New Document available: ripe-108
by RIPE NCC Document Annoucement Service 11 Feb '94

11 Feb '94

New/Revised RIPE Document Announcement -------------------------------------- A revised/new document is available from the RIPE document store. Ref: ripe-108 Title: Support of Guarded fields within the RIPE Database Author: Tony Bates Date: 11 February 1994 Format: PS=45180 TXT=18019 bytes Obsoletes: Obsoleted by: Updates: Updated by: Old: Short content description ------------------------- This document describes an overview of the RIPE database attributes which are guarded, the procedure for updating these guarded attri- butes and the general use of "guarded" fields within the RIPE data- base. FTP Access ---------- All RIPE documents and Internet RFC`s are available via anonymous FTP from host ftp.ripe.net. Type "ftp ftp.ripe.net". Login with username "anonymous" supplying your email address as the password. After logging in, type "cd ripe/docs/ripe-docs" followed by the command "get filename". The relevant filenames for this document are: ripe-108.txt for the ASCII version ripe-108.ps for the PostScript version Electronic Mail Retrieval of Documents -------------------------------------- Documents can also be retrieved from the RIPE document store using a mail server program. For more information on how to use the program, send email to: mail-server(a)ripe.net with "send HELP" in the body text. RIPE NCC Interactive Information Server --------------------------------------- Type "telnet info.ripe.net". This is a menu driven service allows the document store to be browsed. After reading documents you are prompted as to whether you would like to receive an email copy of the document you have just read. If you would, you simply enter your email address and the document will be mailed to you. Below are details of alternative methods of access. Gopher Access ------------- The same documents are available via a "gopher" server at "gopher gopher.ripe.net". WAIS Access ----------- There is also a "WAIS" server at wais.ripe.net, where there is a WAIS index for RIPE documents "ripe-docs.src" WWW Access ---------- For those who wish to add this home page at the RIPE NCC to their own customized home pages, it can be accessed as: http://www.ripe.net MIME Mail Reader ---------------- Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RIPE document. SEND ripe/docs/ripe-docs/ripe-108.txt

1 0

Routing WG minutes 9401
by jimi＠dxcoms.cern.ch 04 Feb '94

04 Feb '94

Here are the draft minutes of the Routing WG meeting in Amsterdam. Comments welcome, -- Jean-Michel ---------------------------------------------------- RIPE Routing-WG Draft Minutes Amsterdam, Tuesday January 25th Minutes: Jean-Michel Jouanigot, Gilles Farrache (scribe) 0. Previous minutes, agenda. The previous minutes and the agenda were approved. Gilles Farrache volunteers as a scribe. 1. Ripe-81 1.1 Introduction; AS registration statistics (NCC) Tony Bates presented briefly some statistics about the Ripe-81 objects registration in the RIPE database during the plenary session. Almost 70% of the ASes in Europe are now registered. This ongoing effort should continue, and AS guardians are encouraged to check that their routing policies are well registered and kept up-to-date. Ripe-81 seem now to be well accepted within the community. 1.2 Guarded attributes (NCC) 1.2.1 Implementation (discussion, hopefully agreement) Marten Terpstra presented the implementation of the Guarded attributes in the RIPE database. The implementation was agreed. For more details, see "Support of Guarded fields within the RIPE Database", Final Draft. This document can be obtained from the RIPE NCC, and will soon be registered as a RIPE document. AS objects cannot be registered using the 'auto-dbm(a)ripe.net' automatic update procedure. These objects have to be sent to 'ripe-dbm(a)ripe.net'. When 'inetnum' object is deleted, and this network is tagged with an AS, the guardian of this AS receives a notification. This new procedures should be operational beginning of February. 1.2.2 Block splitting (Marten), discussion At the last Working Group meeting, an agreement was reached concerning 'block splitting': when one network within a block is tagged with an AS or a community, the block has to be split, and the owner of this object notified. Daniel Karrenberg expressed some concerns about this, arguing that the Database should not modify an object since the users of the database (Local Registries) may have problem to follow up these modifications. Since no better solution was found, it was agreed to confirm this decision, unless a better solution is found by the Database Working group. 1.3 Use of Ripe-81; conversion of Ripe-60 (reminder, brief) The action on Jean-Michel Jouanigot to coordinate this migration is kept open: the migration is postponed to February, when all the necessary tools in the RIPE database concerning guarded objects are implemented. 1.4 Ripe-81 enhancements A new version of the Ripe-81 document, including some extensions, was sent out on the working group list, titled 'RIPE-81++'. 1.4.1 DMZ (Description of Inter-AS Networks in the RIPE Routing Registry" (ptraceroute issue). Status (brief) This extension, proposed by Daniel Karrenberg some time ago, is already integrated in RIPE-81++, and implemented in the RIPE database by the PRIDE Project. It is now commonly used. 1.4.2 Colouring, proposal, discussion Jean-Michel Jouanigot presented a few slides explaining this new extension. Details about colouring can be found in Ripe-81++; the principles are: o Currently: 1 policy per AS; Variations = Communities o Colours : small variations within one AS; hints for CIDR aggregation; avoid network based lists o Implementation: Path attribute (BGP); local to an AS; associated with communities. This new idea was discussed, and a series of clarifications were made: o There is some kind of overlap between colours and communities, but a colour is local to an AS, and the colour information is set at the source of the network announcement, and not in the receiver of this route (network based lists based on communities). o Someone using colours for routing should trust the remote AS for colouring his networks properly when they leave its AS. o One can use both mechanisms (colours and communities) to express routing policies. It is therefore proposed to extent Ripe-81 so that it can support: as-in: AS1234 10 COM1, where COM1 is a community. o It is proposed to limit the number of colours to 16 per AS, since it is the number of bits used in the BGP path attribute today. It was observed that the latest draft of BGP4 dropped the BGP path attribute. The attendees of the coming IETF from RIPE should propose to restore it. o A network can be marked with several colours. 1.5 Ripe-81 limitations and pending issues 1.5.1 AS macros (Ripe-81 proposal), examples, discussion The idea of AS macro was already described in the Ripe-81 original document. It was agreed to accept the AS macros principle, include it in Ripe-81++ and ask the Ripe NCC to implement it. Action: RIPE NCC, to implement the AS macros 1.5.2 Default route representation (Blasco), what can't we represent ? Antonio Blaco Bonito presented his concerns about default route expression in Ripe-81 format. Jean-Michel Jouanigot presented several configurations were the routing policies can't be expressed in RIPE-81 format, since Ripe-81 does not understand the notion of AS Path. There was a long and well debated discussion about the idea of AS Path in Ripe-81. This is a known limitation of the syntax, and network operators are sometime not able to express the policies they are implementing. Such a limitation prevents Ripe-81 to be used to generate Router configurations. Two different approaches were proposed: a) Daniel Karrenberg: Add an 'advice' in the AS object, something which could express "I don't want to cross AS X". b) Laurent Joncheray: Include the AS Path concept in Ripe-81. Solution (a) goes along with RIPE-81 principles: keep it simple. But up to what point can we go in this direction ? What's the purpose of RIPE-81 if we can't generate the router configurations out of the database ? Solution (b) implies that the network topology would tied with the policies, and it may be difficult to keep the Routing policies coherent inside the database. Macros could possibly help. Since no consensus was reached, it was decided to investigate further in both directions: Action on Daniel Karrenberg: Write down a proposal for solution (a) Action on Laurent Joncheray: Write down a proposal for solution (b) 1.5.3 Inter-AS Local Information, discussion This extension, as well as the action attached to it (Peter Lothberg), was dropped. 2. Closing, AOB A FAQ on CIDR by Daniele Vannozzi was sent to the Working Group mailing list. This document was unanimously recognized as good and it was advised to be proposed as an RFC. Comments on this documents should be sent to Daniele Vannozzi, with copy to the list. The RIPE NCC will make the document available. Since RIPE is studying a possible reorganization of its working groups, the chairman asked the participants if new topics should be dealt with or if the scope/charter of the group should be changed. The following was suggested: o CIDR and Aggregation should become a high priority of the group o BGP4/IDPR follow on o The group should avoid, as much as possible, overlapping interest with other RIPE working groups, especially with the Database working group and the EEPG. ----------------------------

1 0

Guarded Attributes (IMPORTANT)
by Marten Terpstra 03 Feb '94

03 Feb '94

[Apologies for wide distribution, think it is important though] Folks, Please find below a slightly updated version of the guarded attribute procedure document. For those of you who manage an AS, please not that starting coming Monday, the aut-sys field in the network object will become guarded, and can only be updated thru the procedure described below. We have created accounts for all ASes we currently see routed in Europe, and if you do not have your account yet, please come and get it as soon as possible and check out the files we have created for you. Please send requests for these accounts to <ripe-dbm(a)ripe.net>. Also if you know some of your AS neighbors have not got their account yet, and are perhaps not on any of these lists, pass this message. If you have questions, send them to ripe-dbm(a)ripe.net as well, or directly to me. -Marten Support of Guarded fields within the RIPE Database * FINAL DRAFT * Tony Bates Document-ID: ripe-1nn 1. Introduction The RIPE database contains several significant attributes which make it well suited for use as part of operational procedures and confi- guration. Most significantly are the attributes which make up the RIPE Routing Registry (RR) as specified in RIPE-81 [1][2], namely the "aut-sys" and "comm-list" attributes. For these attributes to be of use to service providers they must be: o Properly authorised. o Efficient for both maintainers of the attributes and the main- tainers of the whole database. This document describes an overview of the RIPE database attributes which are guarded, the procedure for updating these guarded attri- butes and the general use of "guarded" fields within the RIPE data- base. 2. The Database Guarded Attributes All the guarded attributes currently supported in the RIPE database are contained within the "inetnum" or network object. However, the association corresponds to their relevant guarded database objects. If we look at a simple example this becomes clear: inetnum: 192.87.45.0 netname: RIPE-NCC descr: RIPE Network Coordination Centre descr: Amsterdam, Netherlands country: NL admin-c: Daniel Karrenberg tech-c: Marten Terpstra connect: RIPE NSF WCW ripe-1nn.txt February 3, 1994 - 2 - aut-sys: AS1104 comm-list: SURFNET ias-int: 192.87.45.80 AS1104 ias-int: 192.87.45.6 AS2122 ias-int: 192.87.45.254 AS2600 rev-srv: ns.ripe.net rev-srv: ns.eu.net notify: ops(a)ripe.net changed: tony(a)ripe.net 940110 source: RIPE This shows that the RIPE-NCC network belongs to autonomous system 1104 and is in a community known as SURFNET. This is valuable infor- mation that could easily be used for example for routing policy pur- poses (as well as other operational uses). Currently support for the following set of guarded attributes is implemented: aut-sys The "aut-sys" attribute has a direct mapping to "aut-num" objects as defined in RIPE-81. That is the Autonomous System (AS) that the network number is a part of. As defined in RIPE- 81, a network can only belong to one AS and hence the "aut-sys" attribute can only contain one AS number. The syntax of the "aut-sys" attribute is: AS<positive integer between 1 and 65535> (1). i.e. AS1104 comm-list The "comm-list" attribute has a direct mapping to "community" objects as defined in RIPE-81. A network can belong to more than one community. The syntax of "comm-list" is: Multiple text strings which cannot start with "AS" or any of the <routing policy expression> KEYWORDS defined in RIPE-81. routpr-l (2) The "routpr-l" attribute has a direct mapping to "rout-pr" objects as defined in RIPE-60 [4]. Networks can belong to more than one routing privilege. The list of networks within a rout- ing privilege represents the group of networks accepted/allowed by a set of routers described by the information in the "rout- pr" object. The syntax for "routpr-l" is as follows: _________________________ (1) This represents a change from RIPE-50 [3] where the "aut-sys" attribute was defined to be a positive integer only, not containing the string "AS" at the start. This change has been made to be consistent with the "aut-num" object syntax. ripe-1nn.txt February 3, 1994 - 3 - Multiple text strings representing the routing privilege. bdrygw-l The "bdrygw-l" attribute has a direct mapping to "bdry-gw" objects as defined in RIPE-60 [4]. Networks can belong to more than one boundary gateway. The list of networks within a boun- dary gateway represents the group of networks advertised by a set of routers described by the information in the "bdry-gw" object. The syntax for "bdrygw-l" is as follows: Multiple text strings representing the boundary gateways iden- tification. As these attributes are tightly coupled to their associated objects it makes sense for these attributes to be updated not by the network maintainer but by the maintainer of the referenced object(s). The basic premise behind this is that these attributes should be used for various operational procedures such as setting routing policy, accounting and so on. For these attributes to be used by network operators for day to day operations they need to be guarded in such a way that can be trusted and are guaranteed to be unique - with any conflicts quickly and easily resolved. The procedure for achieving this is detailed below. 3. The Basic Procedure For each of the guarded attributes detailed above, a list of all networks having this attribute is kept separately from the general database itself. These lists (also called `guarded files') will be maintained and be served as the `only' source of membership informa- tion used in the database. Normal database updates `never' change these attributes. If an update includes such an attribute and a discrepancy between the values in the update and those in the data- base is found, a diagnostic message will be sent to the originator of the update and the guarded value(s) will not be affected. The attributes as defined in these files are incorporated in the data- base once a day. To ensure proper control and authorisation, these lists will be maintained at the RIPE NCC on the same machine that contains the RIPE database. The "guardians" of the corresponding database objects will have to maintain their own guarded files. The guardians are provided with individually assigned login accounts at the RIPE NCC. The guardians can themselves decide in what manner they want to update their file. The NCC will offer interactive logins, ftp logins or any other means that might be deemed useful. _________________________ (2) It should be noted that both "routpr-l" and "bdrygw-l" attributes have been agreed to be phased out in preference of the "aut-sys" and "comm-list" attri- butes as soon as the `guarded field' mechanism is in place. ripe-1nn.txt February 3, 1994 - 4 - 3.1. Some Details As stated each guardian will be issued with an account on the cen- tral NCC machine known as `guardian.ripe.net'. This account will contain a `restricted' environment which will allow the guardian of the relevant object to update their associated guardian file (3). Wherever possible the account name issued to the guardian will be the same as the object name. For example, the guardian of the AS1104 aut-num object will receive an account known as "AS1104". With each guardian account the corresponding file will be parsed at each update run (once a day). This file will contain the list on networks associated with the object. See appendix A for details of the format and syntax of the guardian files. A tool will also be provided within the restricted environment to syntax check the guarded file to avoid against possible typos and errors. With each account, an electronic mail address (this is a mandatory attribute for all guarded objects) will be used by the NCC and data- base software. To make this flexible for the guardian a ".forward" file with the account which can be change when required. This will mean mail sent to <guardian-name(a)guardian.ripe.net> will go the to correct guardian. 3.2. How does it work ? For each of the guarded files found on `guardian.ripe.net' the data- base software will load any guarded attribute value(s) for the net- work object(s) listed in the guarded file. This will take place at the same time as the database is garbage collected (currently at 0500 MET). If a conflict is found (i.e if more than one entry exists for an attribute which can only contain one entry, currently only "aut-sys" contains this property), the current value will remain unchanged and all guardians involved in the conflict will be sent an electronic mail message informing them of the conflict. See Appendix B for an example. If no conflict is found the attribute will be updated with the guarded value. Correspondingly, to remove a guarded attribute just remove the net- work entry from the relevant guarded file and it will be deleted at the next update run. To be notified of this delete the "notify" attribute should be used. _________________________ (3) As stated, the mechanism for updating the guardi- an file will initially be by interactive login or file transfer. However, this doesn't preclude other mechan- isms in the future. ripe-1nn.txt February 3, 1994 - 5 - If a guardian file contains an entry which is not in the database then the guardian will be notified as part of the conflict handling procedure. If an update is sent to the database software using another mechan- ism (i.e. mail to auto-dbm(a)ripe.net) that contains a guarded attri- bute, this will not be allowed to change the guarded attribute. If the value of the attribute is the same as what is currently registered in the database then no warnings will be given. However, if the update contains a value for a guarded attribute that is dif- ferent to that registered in the database, a warning will be sent to the originator and the guarded value will remain unchanged. Any changes of other (unguarded) fields in the update will be checked for syntactic correctness and if they pass will go through to the database irrespective of any conflicts for the guarded fields. When through the normal database update procedure an object with guarded attributes is deleted, the guardians of these guarded attri- butes will be notified of this deletion. Only deletions will be notified in this way to guardians. For normal changes the "notify" attribute of the database should be used. Although the guarded process will run once a day as part of the database garbage collection procedure it will also be possible to, "on request to the NCC", run an emergency guarded update process for a particular guarded object. To have complete guardian accounts removed from the NCC machine, and thus all references to this guarded value, please contact the RIPE NCC at <ripe-dbm(a)ripe.net>. Removing an account and the guardian file that goes with it means that this guarded value will not be added any longer to any of the objects in the database. 4. Getting it started As this is a new (and much needed, especially for the "aut-sys" attribute) mechanism, a degree of `bootstrapping' is needed to make it easier for network providers and IRs to transition to using the guarded file procedure. The NCC has built an automated generation scheme for attributes that are known to be in use (currently, this means AS numbers). For all the AS numbers seen to be routed in Europe, accounts for the guardians have already been put in place having the guardian's mailbox point to a mailbox at the RIPE NCC. For these ASs currently guarded files are generated on a daily basis by analyzing European full routing tables. This means there could (and almost certainly will) be some conflicts within the generated guardian files. As soon as the account is handed over, the auto-generation for that guardian account stops and the mailbox is changed to the correct guardian mailbox. Guardians can of course make use of the auto- generated guarded files if they wish to check against their own records. From the moment of `hand-over' it is now the guardians responsibility to make sure their associated network(s) get the ripe-1nn.txt February 3, 1994 - 6 - correct guarded attributes by listing them in the guarded files. The advantage of having this `bootstrap' method is that it will allow population of the guarded "aut-sys" attribute to take place immediately this functionality is enabled in the RIPE database software. It also acts as an incentive for networks operators and local IR's to transition to the guarded file procedure as soon as possible. 5. Conclusion The update procedure as detailed above has the following advantages: o Authorisation of adding/deleting is guaranteed. o No need for mailing back and forth of authorisation messages. o Simple procedure for both database maintainers and guardians. o Guardians keep full control of their attribute. It allows for the addition of any number of guarded attributes in the future. It describes a simple but effective procedure for main- taining the guarded files whilst not precluding alternate mechanisms in the future. 6. References [1] Bates, T., Jouanigot, J-M., Karrenberg, D., Lothberg, P., Terpstra, M., "Representation of IP Routing Policies in the RIPE Database", RIPE-81, February 1993. [2] Bates, T., Karrenberg, D., "Description of Inter-AS Networks in the RIPE Routing Registry", RIPE-103, December 1993. [3] Karrenberg, D., "RIPE Database Template for Networks", RIPE-50, April 1992. [4] J.-M. Jouanigot, "Policy based routing within RIPE", May 1992. ripe-1nn.txt February 3, 1994 - 7 - Appendix A - Format of Guardian Files. We propose to keep the file format as simple as possible. The name of the file is identical to the name of guarded object. The format used within the file is kept simple. It allows lines to be either comments or the actual object entry that is to be guarded. A comment must contain either a semi-colon (;) or hash (#) at the beginning of the comment line. The object name entries must be exactly the same as they are in the database. Currently, the only object containing guarded attributes is the "inetnum" object so the file can contain either the `well-known' dotted quad network notation or RIPE dotted quad range notation. Here is a simple example of what the AS1104 guarded file would look like. The file would be stored in the home directory of the AS1104 account on guardian.ripe.net and be called AS1104 (told you it was simple). It would contain something like the following: # # File : AS1104 # ; An alternate comment format ; ; This file was updated jan.dijkstra(a)gouda.nl ; on 940109 ; 192.16.183.0 192.16.185.0 - 192.16.186.0 192.16.194.0 192.16.199.0 192.87.45.0 Empty lines in the file are also ignored but you are encouraged to keep the file as concise as possible. As stated above, a tool known as `checkguard' will be available to make it simple to check the syntax of the guarded file. ripe-1nn.txt February 3, 1994 - 8 - Appendix B - Example of conflict handling If a conflict occurs (e.g. by listing the same network number in more han one AS guarded file), then each of the guardians involved will be notified on the conflict by electronic mail. Let's look at a simple example. Suppose the guardians for AS1104 and AS2122 update their relevant guardian files and create a conflict by having the same network in them. For this example he network in question is "192.16.183.0". Here is the AS1104 guardian file: # 192.16.183.0 192.16.185.0 192.16.186.0 192.16.194.0 192.16.199.0 192.87.45.0 And here is the AS2122 guardian file: # 192.16.183.0 193.0.0.0 - 193.0.7.0 As you can see "192.16.183.0 exists in both files. At update time the following mails are generated. Firstly, to the guardian of AS2122. Date: Fri, 14 Jan 1994 13:22:43 +0100 Message-Id: <9401141222.AA07125(a)ns.ripe.net> From: RIPE Database Conflict Handler <ripe-dbm(a)ripe.net> Subject: Guarded attributes conflicts found To: as2122(a)ripe.net Dear Guardian, One or more conflicts have been found regarding guarded attributes in the RIPE database. Some of the conflicts concern the guarded values you are a guardian for. Please verify and correct the conflicts below. The guarded values for objects below have been set to the value they had in the database before this guarded attributes run. Kind Regards, RIPE Database Conflict Department ------ "192.16.183.0" also appears in guardian files: AS1104 And similarly to the AS1104 guardian. ripe-1nn.txt February 3, 1994 - 9 - Date: Fri, 14 Jan 1994 13:22:42 +0100 Message-Id: <9401141222.AA07121(a)ns.ripe.net> From: RIPE Database Conflict Handler <ripe-dbm(a)ripe.net> Subject: Guarded attributes conflicts found To: as1104(a)ripe.net Dear Guardian, One or more conflicts have been found regarding guarded attributes in the RIPE database. Some of the conflicts concern the guarded values you are a guardian for. Please verify and correct the conflicts below. The guarded values for objects below have been set to the value they had in the database before this guarded attributes run. Kind Regards, RIPE Database Conflict Department ------ "192.16.183.0" also appears in guardian files: AS2122 >From this you can see conflict can be quickly and easily resolved, assuming good collaboration between the guardians. The existing database entry will of course not be changed with regard to the guarded attribute) as long as there exists a conflict. ripe-1nn.txt February 3, 1994

1 0

Draft minutes 17th RIPE meeting: DB-WG
by Wilfried Woeber, UniVie/ACOnet 02 Feb '94

02 Feb '94

Dear all, this is the draft minutes of the Database-WG meeting(s) at the 17th RIPE meeting. Any input and comments welcome, especially from those being affected by these things in one way or the other :-). Best regards, Wilfried. -------------------- start of draft minutes -------------------- 17th RIPE Meeting: Draft minutes for the DB-Working-Group meeting 25.1.1993, Amsterdam. ----------------------------------------------------------------------------- Due to the scheduling (and the un-avoidable overlap) of some WG meetings, the items on the agenda were treated in a different order than originally proposed. However the minutes follow the original ordering. 0. Opening, Scribe, Admin The DB-WG meeting was opened and Ruediger Volk volunteered to take notes. As a direct result of the preceding meeting of the Routing-WG and following other discussions the proposed agenda was amended (DB statistics for Domain-Object, maintainance of e-mail attribute and .forward files for guarded objects, timing considerations for guarded objects and values, aspects of ownership of objects and deletions and inter-dependancies). 1. New Databse software 1.1 . current status Marten Terpstra gave a concise report on the current state of the "new" database software. Due to timing constraints (and the lack of documentation) there is still no official distribution of the "New DB Software". However it has already been successfully installed at a couple of sites. The slides for the presentation can be found in ftp.ripe.net:ripe/presentations/ripe-m17-marten-DB.ps.Z 1.2 . experiences No operational problems were mentioned. Operation of the software, including the organizational environment, is going very smooth and was generally appreciated. 1.3 . documentation (who, how, when, what) Documentation is still missing. A new effort is needed and will be made early February. It has to be taken into account, that Marten Terpstra will primarily work on the PRIDE project, reducing his involvement with the DB software. Action (Wilfried Woeber, NCC): produce the necessary documentation for the new DB software. 2. RIPE-Handles RIPE-Handles are urgently needed to make progress in the area of Database Exchange. Several possible methods of assigning these handles were discussed. the group reached consensus that the RIPE-Handles will be of the form RIPE-XYZ9999. It was decided that from the DB's point of view, there exists only ONE handle: the RIPE-Handle. Thus this handle is stored in the person object in the "nic-hdl:" attribute. For the initial population/conversion of the current entries, the value of the NIC-Handle will be taken and converted to a RIPE-Handle by appending the string "-RIPE". E.g. the NIC-Handle for Wilfried Woeber (WW144) will be converted to form the RIPE-Handle (WW144-RIPE). This conversion will be done only once for the inital population. There will then be a short period, when missing handles can be provided by means of "vanity-handles". After a to-be-announced flag-day, RIPE-Handles will be required for any operation on person objects in the Database. Any vanity handles used MUST be properly registered with the NCC! The same syntax has already been adopted by the JPNIC and the AUNIC. *** Please note that during the discussion (by accident) we all were talking about a prefix format *** The NCC was mandated to circulate an updated proposal, including operational aspects, and after a short review-process (e-mail), go ahead with the implementation. Action (NCC): update and re-circulate the RIPE-Handle proposal and then go ahead with the implementation. 3. PRIDE - DB Interaction Editorial comment: RIPE-81++ was treated in the Routing-WG. Currently there is no real pending issue with regard to the interaction between the PRIDE project and the RIPE-DB. After discussing possible future modifications or additions to DB objects, the NCC was mandated to go ahead and implement changes/additions to support the PRIDE project (like the hidden flags/options), unless there is a direct influence on operational aspects or changes to the user interface to the RIPE-DB. 4. Future needs 4.2 . Delete Operation vs Guarded Field interaction Various aspects of implementation of guarded objects were reviewed. With regard to possible "delete:" operation on network objects that are tagged with a guarded AS-value, consensus was to automatically notify the guardian of the AS-value. Changes to such objects do NOT generate a notification message. This functionality can be achieved by using the "notify:" attribute. The "notify:" attribute for an object is evaluated before the update is made. The technical issues of RIPE-81 was treated in the Routing-WG. Generally the transaction of deleting an object must be described. The document with the proposal for implementing guarded attributes is to be updated and recirculated for comment (e-mail, 14 days comment period). Then the NCC goes ahead with the implementation as soon as possible. Action (NCC): update and re-circulate the Guarded Fields proposal and then go ahead with the implementation. 4.3 . Phase-out of RIPE-60 stuff Jean-Michel Jouanigot continues to coordinate the migration to the RIPE-81 functionality. Any technical issues treated in the Routing-WG. 4.4 . Tools A proposal to have a certain kind of "template-mode" for checking and/or updating database objects was discussed. Several possible ways of implementing this were discussed (like a special flag for the whois-client, an interactive method at the NCC, providing a full template for further processing). Any solution proposed should be usable on most platforms. Action (NCC): investigate and propose facilities for a "template-mode" to support the maintaining database objects. 4.5 . Syntax checkers (distributed, and/or @ the NCC) The need for syntax-checking facilites for objects was again stated. The NCC was asked to look into providing this functionality and come up with a proposal. Action (NCC): Investigate and propose a syntax-checking facility for the new database software. 5. New/Revised Objects 5.1 . CLNS Routing "dom-prefix:" Henk Steenman provided an introduction to the current version of the proposal to have a database object for CLNS Routing. The only technical amendment discussed was to present the CLNP addresses in the format of xx.xxxx.xxxx.xxxx (no trailing dots). The NCC may have to review the current shell of scripts supporting the database operations for limitations in line-length. The NCC was mandated to go ahead with implementing this object after another short round of review (e-mail) of Henk's updated specification. Action (Henk Steenman): update and re-circulate the "dom-prefix:" proposal. Action (NCC): implement the CLNS Routing Object. >>>>>>>>>>>> I'm going to ask Henk to provide the (updated) proposal for the presentations directory!? 5.2 . status of "connect:" and value "LOCAL" Decision about the future of the "connect:" attribute for a Network Object was postponed after full deployment of the RIPE-81 stuff. It is expected that the "connect:" will be phased out and be replaced by a different mechanism (community?). The "connect:" attribute is no longer mandatory. 5.3 . Domain Object The status of the Domain Object was reviewed, prompted by the fact of poor coverage in the database. Again the object was felt to be useful, although currently there is little operational influence of registering (or NOT registering) domains in the database. Consensus was to ask the DNS-WG to review and maybe update the definition of the Domain Object. Action (Francis Dupont): Have the DNS group review the Domain Object and come up with either a recommendation for retirement or with an updated functionality 5.4 . others The "notify:" attribute is already implemented and is already used by the database software. The "maintainer:" attribute is already implemented but currently not used by the databse software. 6. Exchange Format 6.1 . current status No progress has been made due to the lack of RIPE-Handles. Can be progressed after implementation of RIPE-Handles. 6.2 . recommendations for further action As an aside - the group propsed to NOT enforce uniqueness of network names. 7. DB statistics (Domain-Object) Having stistics about the DB coverage of domains was seen to be potentially useful. Postponed to wait for the Domain Object review by the DNS-WG. 8. Maint. of e-mail: and .forward for guarded objects After evaluating possible szenarios it was decided that an automatic modification of either the "e-mail:" attribute of a guarded object or the .forward file for the guardian's account is not desirable. Responsibility of the maintainance remains with the guardians. 9. Timing considerations for guarded objects, values, secondary DBs Some operational issues of implementing guarded fileds were reviewed. Aspects discussed in more detail were: - timing and interlock: Some mechanism must be set up by the NCC to allow for checking the merge/update status of the current version of the database. This should allow for an automatic delay of retrieving the DB for local use and/or providing read-only copies. The NCC will come up with a technical proposal how to do this. - change control: in order to preserve the update history for databse objects a structured scheme was proposed. This method preserves the "changed:" attributes supplied by any manual update process. In addition to that any automatic up-date and/or merge operation done by the database software maintains a single related "changed:" attribute describing the "agent" performing the modification. From a formal point of view, regular maintainance and/or merge operations are NOT treated as update operations, thus e.g. they do not trigger (automatic) notification messages. Action (NCC): Propose and implement a mechanism to check the current state of the database with regard to garbage-collection and merging of guarding values. Action (NCC): Propose and implement a mechanism to properly keep track of individual updates of objects and automatic merge/modification operations. 10. Deletions, Ownership of Objects, Interdependency This was a more general discussion, focussing on issues of "ownership" of objects, inter-dependency of various components and quality of the information in the database. >From a formal point of view, there was agreement that we should stick with the concept that the responsibility for maintaining objects remains with the owner of the object. From an operational point of view it was felt necessary to perform automatic modifications to certain attributes of an objects. In the long run this could eventually lead to splitting objects along the lines of maintainance. This is for further discussion. Concern was voiced that we do not have the concept of winding down the use of methods, removing out-dated information and/or deleting objects, closing guardian's accounts, etc. It was felt that there is a need to analyze, discuss and document these issues. For the time being these aspects have to be covered in individual documents describing certain procedures, in the long run this should be an intrinsic part of the documentation. The aspect of "sanity checking" the information in the databse was shortly touched. Given the current shortage of manpower in the NCC and the important changes to be implemented in the near future this issue was postponed. Z. AOB None. -------------------- end of draft minutes --------------------

1 0