- routing-wg - mailman.ripe.net

draft minutes of the WG session at RIPE 25
by Schmitz＠RUS.Uni-Stuttgart.DE 08 Oct '96

08 Oct '96

Here are the draft minutes of the WG session at RIPE 25. Thanks to Mike Norris for taking them. Comments to the draft minutes are welcome, the final version will be circulated next week. Joachim ------ RIPE 25, Amsterdam Routing Working Group Report of Meeting, 23rd September 1996 1. Opening and Administrivia Willem van der Scheun, Chairman, presided and welcomed people to the meeting. There were 89 attenders. Mike Norris took minutes. 2. Agenda bashing A draft agenda of business, circulated by the Chairman in the previous week, was agreed. 3. Chairman of the Routing WG Willem announced that his day job prevented him from devoting the time necessary to chairmanship of the WG and that he was standing down. He was pleased to say that Joachim Schmitz would accept his proposal to be Chairman, and this proposal was endorsed by the meeting. Members thanked Willem for his work as Chairman and guidance of the WG. Joachim chaired the remainder of the meeting. 4. Report from the RIPE NCC Daniel Karrenberg said that the RIPE NCC planned to resume its studies of route aggregation. An exercise he had conducted earlier in 1996 and reported to RIPE 24 had revealed plenty of room for improvement. Individual reports to those responsible for over-specific routing had resulted in significant improvements. Since then, however, the aggregation situation had disimproved. Daniel's impression was that some ISPs didn't care or wouldn't take the trouble to correct matters. Further remedial action was needed and the Contributors' Committee supported the NCC in this work. Skilled staff would soon be appointed and they would help ISPs in promoting route aggregation. While neither RIPE nor the NCC could take action against any offenders, the use of peer pressure among the ISPs could be used in a positive manner to improve the position. The meeting encouraged ISPs to supply BGP data to the NCC on request for the purpose of analysing route aggregation. New Action: the NCC would report on route aggregation at RIPE 26. 5. Working Experience with Route Object Editor (ROE) ftp://ftp.ripe.net/ripe/presentations/ripe-m25-jschmitz-work-exp-roe.html Joachim Schmitz reported on his experience with ROE. This was part of the RA Toolset and had been written by Cengiz Alaettinoglu. Its purpose was to view and manipulate route objects and to compare them with operational routes. It worked on routes as objects from Internet routing registries (IRRs) and as determined from routers (by means of input BGP tables). Compiled with C++ in a Tcl/Tk environment, ROE was easy to instal. With its GUI it was easy to use. As not all IRRs were aligned in the way they worked, ROE displayed separate route registrations where appropriate. Joachim found it slow in operation, although Cengiz later indicated that this was probably due to network and server performance and not to the ROE program execution. It was also not clear to Joachim whether live or mirrored IRR data was used. He suggested that the program could be improved by allowing more configuration options and greater clarity in some of the messages. This and other feedback should be directed to Cengiz. Overall, he recommended ROE for operational use, particularly for complex routing tasks. 6. Progressive BGP route flap dampening ftp://ftp.ripe.net/ripe/presentations/ripe-m25-tbarber-bgp-damp.html Tony Barber gave a presentation on the strategies used by UUnet-Pipex to reduce the effects of route flapping and to try to prevent router table overflow. These were: - route dampening - prefix filtering - more router memory They had encountered many instabilities from peers and found that many ISPs had not deployed CIDR; this gave rise to more flapping as more routes, and particularly more specific ones, were advertised. Tony explained the parameters used for route dampening on a Cisco router. He had arrived at the following re-use times for various route sizes: /24 and greater ~160 minutes /23 and /22 ~60 minutes /21 and less ~30 minutes He recommended filtering out all prefixes more specific than /24. While route dampening consumed router memory, this was more or less balanced by a reduction in routing CPU cycles. He recommended that if route dampening was to be widely deployed in Europe, consistency was important. In this sense, the Routing WG should agree on guidelines for parameters to be used. In discussion, the following points were made: - aggregation works in reducing router load and route flapping. - route flapping is often a feature of certain autonomous systems rather than a function of prefix length. - much instability was due to configuration changes and errors as distinct from link failures. - making dampening dependent on prefix length could penalise many stable /24s. - it might be useful to discriminate against /24s in the 192.0.0.0/8 block (the swamp). - the focus should be on keeping noise out of the system rather than trying to mitigate against it once in the system. In summary, it was agreed that route dampening was an important topic and that more discussion was needed. 7. Routing Policy analysis tools http://www.isi.edu/ra/Presentations Cengiz Alaettinoglu of ISI presented a review of recent developments and updates in the RA toolset, now at version 3.4.0. The set of front-end tools used a number of back-end libraries, which made program development easier. It required RAWhoisd v3.0 and had been ported to several operating systems. Cengiz gave details of availability (URL = http://www.isi.edu/ra/RAToolSet as official reference or copies also available from ftp://ftp.isi.edu/pub/cengiz/RAToolSet-3.4.0.tar.gz or ftp://ftp.ra.net/routing.arbiter/tools/RAToolSet/RAToolSet-3.4.0.tar.gz ) and of the mailing list (ratoolset(a)isi.edu) The toolset was made available for demonstration purposes to attenders of RIPE 25. RtConfig generated the BGP access list part ofrouter configuration from route objects. It was now used in production by some major network operators. ROE was again shown, with reference to review options before submitting a changed route object. The AS object editor (AOE) was not implemented, though it was on demo at RIPE 25. CIDRAdvisor identifies 'safe' aggregates by route originators as well as aggregates for proxies. Cengiz showed the effects of using various radius values for the distance that aggregation should hold. Summary of Actions ------------------ Action 22.10 on Joachim Schmitz To trigger the discussion on the mailing list of the Routing WG, which focus to choose for a future tool development project and to come to consensus on it Action 24.4 on Joachim Schmitz To investigate the status of the CIDR FAQ and see whether additions are needed, probably by triggering a discussion on the mailing list New action on Daniel Karrenberg/RIPE NCC To report on the results from the route aggregation analysis on the 26th RIPE meeting New action on Joachim Schmitz To coordinate making the presentations at the Routing WG available Mike Norris 23/9/96 _____________________________________________________________________________ Dr. Joachim Schmitz schmitz(a)noc.dfn.de DFN Network Operation Center Rechenzentrum der Universitaet Stuttgart ++ 711 685 5553 voice Allmandring 30 ++ 711 678 8363 FAX D-70550 Stuttgart FRG (Germany) _____________________________________________________________________________

1 0

Short summary of WG session at RIPE25
by Schmitz＠RUS.Uni-Stuttgart.DE 08 Oct '96

08 Oct '96

The following short summary of the WG session at RIPE25 has already been submitted to the RIPE NCC last week. The draft minutes will be circulated this week. Joachim ----- RIPE 25 Short minutes from the Routing WG Meeting 23.9.96 16:00-18:10 89 participants Chairmen: Willem van der Scheun, Joachim Schmitz Scribe: Mike Norris * New chairman Joachim Schmitz (JS395-RIPE), schmitz(a)noc.dfn.de * Presentations Joachim Schmitz, DFN-NOC: Working Experience with ROE Tony Barber, Pipex: Experience with Progressive BGP Route Flap Dampening Cengiz Alaettinoglu, ISI: The RA ToolSet During the RIPE meeting a test installation of the RA ToolSet was accessible to the participants * Actions Action 22.10 on Joachim Schmitz To trigger the discussion on the mailing list of the Routing WG, which focus to choose for a future tool development project and to come to consensus on it Action 24.4 on Joachim Schmitz To investigate the status of the CIDR FAQ and see whether additions are needed, probably by triggering a discussion on the mailing list New action on Daniel Karrenberg/RIPE NCC To report on the results from the route aggregation analysis on the 26th RIPE meeting New action on Joachim Schmitz To coordinate making the presentations at the Routing WG available _____________________________________________________________________________ Dr. Joachim Schmitz schmitz(a)noc.dfn.de DFN Network Operation Center Rechenzentrum der Universitaet Stuttgart ++ 711 685 5553 voice Allmandring 30 ++ 711 678 8363 FAX D-70550 Stuttgart FRG (Germany) _____________________________________________________________________________

1 0

Fwd: Re: mnt-lower attribute not allowed?
by Wilfried Woeber, UniVie/ACOnet 04 Oct '96

04 Oct '96

Dear routing folks ! Just wanted to let you know that we've just started a discussion on how to properly maintain route: objects on the DB-WG list. You're more than welcome to join in on db-wg(a)ripe.net (or we could move the discussion to the routing-wg list :-)! Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Subj: Re: mnt-lower attribute not allowed? Hi Steven et.al. ! => => The AS object that matches the origin AS of a route object could be the => parent object of the route object, but then people are still able to put => route objects in with another origin AS which might not be desired by the => owner of the non-portable CIDR address space. Furthermore, a second => hierarchy exists: the IP prefix tree. => => You might want to try to formulate a proposal that is not too => complicated and also addresses the concerns of most people ... = =How about making the inetnum object the parent of the route object? =I think it would make sense to allow the "owner" of the inetnum to create =the route objects.. I'm not convinced that this is the way to go. For two major reasons: - in many environments the routing is handled differently from the address allocation. In particular, where filters or other things are (semi-)automatically derived from objects in the DB, it's certainly not feasable to have the customers ("owner" of the address space) change things without coordination. If they do, it might not reflect reality at all or it might interfere with local logistics. And there's the issue of porting PA address space for a limited amount of time to a different ISP. - I think we should come up with a concept that works as well outside the RIPE-coordinated address space and the central registry concept. I think we should . come up with a solution that works for routing-registries that do not include an address registry in the same DB, . find a solution that works uniformly across all parts of the address space (A, B, C-19[3-5], TWD, et.al.) = You can also keep the owner in the "notify:" field of =the route object, so once you delegate maintenance of the route object to =someone else, you can still keep track of what's happening with it. = =Or does this sound ludicrous? No, it made me think, thus it was a very useful approach :-) I'd favour an approach that is (conceptually) similar to the handling of domain objects - something like an upstream search based on the AS #. Although I haven't a clear picture of how it could work in reality, because the "tree" is certainly less well-defined than in the DNS namespace. Another idea would be to have a registry-pointer in the inetnum objects that identifies a articular regsitry object. This in turn could be used to describe the desired maintainance. We might want to have that linkage anyway? I'm not sure whether that meets David's criteria of "not too complicated and also addresses the concerns of most people" :-) Cheers, Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------

1 0

BGP route dampening details
by Tony Barber 03 Oct '96

03 Oct '96

I have put the text of the presentation at the last ripe routing wg at : http://www.pipex.net/people/tonyb/bgp-damp.html fot anyone who is interested. Regards --Tony

1 0

RA tools demo (still) available
by Geert Jan de Groot 30 Sep '96

30 Sep '96

Several people have asked me to keep the machine on which the RA tools were installed would be reachable after the RIPE-meeting. The machine (meeting.ripe.net) will be available for a couple of weeks after the meeting, and the demo account ('rademo', password also rademo) is still operational for those interested. Enjoy, Geert Jan

1 0

RAToolSet
by Cengiz Alaettinoglu 24 Sep '96

24 Sep '96

Hi, RAToolSet can be downloaded from http://www.isi.edu/ra/RAToolSet. Below, I am including the instructions in case some of you may want to try it out next week. My understanding is that the tools will stay installed on meeting.ripe.net (acct name rademo) for a while. Regards. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California http://www.isi.edu/~cengiz ====================================================================== Instructions for RAToolSet Demos ================================ Your feedback on these tools are greatly appreciated. You can download RAToolSet from: ftp.isi.edu:ra/RAToolSet http://www.isi.edu/ra/RAToolSet There is a mailing list ratoolset(a)isi.edu To subscribe, send mail to majordomo(a)isi.edu with body of the message containing "subscribe ratoolset". NOTE: RAToolSet is configured to connect to RAWhoisd running at meeting.ripe.net at port 5045. If you get a connect failed error, RAWhoisd probably is not running anymore. In which case you can connect to whois.ra.net by issuing: unsetenv IRR_HOST unsetenv IRR_PORT To run: 1) cd demo/data NOTE: Most of the executables are in ~cengiz/demo/bin. This directory is already in the PATH of the rademo account. Example data files are in the ~/demo/data directrory. The man pages are in ~demo/man. The MANPATH contains this directory. 2) to generate a config file for a cisco router RtConfig < ornet-gw.ra You may want to examine the file ornet-gw.ra first. This file is used in production to configure one of the routers of Oregon IX (courtesy of Dave Meyer). 3) to generate a route server config file RtConfig -config rsd < rsd.sprint.tmpl rs1.sprint.ra.net is configured using this template file every four hours. You may want to add "-h meeting -p 5055" to speed this up. (see relayd below). 4) roe roe <your-as-number> If you have a cisco bgp dump, you should load it from the file menu. You may want to try "roe AS226", there is a bgp dump file that goes with this AS in file roe_bgp_dump_as226. 5) aoe aoe <your-as-number> If you have a cisco bgp dump, you should load it from the file menu. You may want to try "aoe AS3582", there is a bgp dump file that goes with this AS in file aoe_bgp_dump_as3582. 6) CIDRAdvisor CIDRAdvisor -incl_multihomed AS226 This will not check any policies. Try: CIDRAdvisor -incl_multihomed AS226 -radius -3 to check policies of all ASes 7) peval peval -expand_all 'AS1220 AND AS226' peval will list the multihomed routes between AS1220 and AS226 8) other (9 and 10 below are more interesting) prcheck <your-as-number> pmatch AS3130 cat.isi.edu prpath AS2914 193.85.128.0/24 prtraceroute www.isi.edu we are having problems running prtraceroute on bsdi. 9) relayd is running on meeting.ripe.net on port 5055. All tools above can be run using relayd by issuing the command line options "-h meeting -p 5055". For example: RtConfig -config rsd -h meeting -p 5055 < rsd.sprint.tmpl You will see warning messages saying the data comes from a CACHE. You may also notice certain tools run faster. If you get a connect() failed, most probably somebody rebooted meeting.ripe.net, and relayd is no longer running. You can restart relayd by: relayd -c all-as.db 10) IRRv irrv Rusty's instructions: For a demo the following things can be done: 1. Select "IRR -> AS Peers" menu option and enter as3333. => this expands as3333 2. Find Ebone (as1755) and drag it into the clear 3. Expand Ebone 4. Select "IRR -> Layout -> Gater Peers" => this will collect all of Ebones singly connected peers => around Ebone * at this point you may want expand a few more ases to get the map a bit cluttered to demo the "Gather Nodes" option. following are some suggested expansions 5. Expand as3215 6. Expand as5582 7. Expand UUNet (as175?) => this will cause the uunet icon to turn yellow, indicating no => registered peer info 8. Expand 6708 9. Select "IRR -> Layout -> Group Nodes" && select 3 or 4 levels on the popup => this will group all nodes of degree 3 (or 4) reducing much => clutter. 10. Select RIPE (as3333) and pulldown the 'IRR -> IRR -> Display Autnum" menu. => this will show the '!man,as3333' query results in the text => window. 11. Select RIPE (as3333) and pulldown the 'IRR -> IRR -> Display Routes" menu. => this will show the '!gas3333' query results in the text => window. 12. You can select the 'IRR -> Geographic -> World' to show the geographic ability, although the maps should show as a backdrop, this may produce uninteresting results. *** About exec'ing commands there is an executable script ~eddy/bin/irrv that will change directories to ~eddy/bin and exec tkined. I have symbolic links for: prpath -> ~cengiz/RAToolSet/src/prpath/prpath roe -> ~cengiz/RAToolSet/src/roe/roe prtraceroute -> ~cengiz/demo/bin/prtraceroute that will get executed when the 'IRR -> tools -> ..." gets selected. after executing prtraceroute or prpath using the text log screen and hyper commands, it is safest to quit the log window if you will attempt another exec of prtraceroute or prpath. This is because tkined has a bug that jumbles subsequent hyper link commands.

1 0

Action 24.4: To investigate the status of the CIDR FAQ
by Willem van der Scheun 23 Sep '96

23 Sep '96

The CIDR FAQ is maintained by Hank Nussbacher (hank(a)vm.tau.ac.il or hank(a)ibm.net.il) It's URL is http://www.ibm.net.il/~hank/cidr.html http://www.rain.net/faqs/cidr.faq.html Last version if dated May 1996.

1 0

Proposed agenda for next meeting
by Willem van der Scheun 20 Sep '96

20 Sep '96

Dear collegues, Please find below the proposed agenda for the next meeting of the RIPE routing WG. I want to draw your attention to agenda point 3, change of chairman. If there are any objections against Joachim Schmitz taking over please let them know beforehand. Also if there are other candidates please make that known. 1. Opening & administrativa 2. Agenda bashing 3. Chairman of the Routing WG The present chairman will step down and proposes to appoint Joachim Schmitz of the DFN NOC as new chairman. 4. Report from the RIPE NCC 5. Presentation by Joachim Schmitz on working experience with ROE (route object editor). 6. Presentation by Tony Barber of Pipex on experience with Progressive BGP route dampening 7. Presentation by Cengiz Alaettinoglu of ISI on Routing Policy Analysis Tools: - RtConfig (router configuration generator) - roe (route object editor) - aoe (autonomous system object editor) - CIDRAdvisor - IRR visualisation - IRRRelayd - prpath/prtraceroute/prcheck 8. If time permits IRRRelayd - prpath/prtraceroute/prcheck 8. If time permits hands on experience with the ISI tools 9. Closing -- Willem

2 1

proposal for inet-rtr obj extensions, for multicast, etc.
by Wilfried Woeber, UniVie/ACOnet 18 Sep '96

18 Sep '96

Dear all, (to complete a long-standing RIPE action and to make progress) please find below a modified version of a document (originally by Erik-Jan Bos) which then was describing a multicast router in a routing registry. This version proposes a more generalized approach and tries to discuss some implications, benefits and compatibility issues. It is up for discussion in the relevant RIPE working groups - in particular Routing, Mbone, (IPv6??) and DataBase. Of course any input and suggestions welcome! I would like to have your comments before and at the RIPE 25 Meeting, as well as on the mailing lists. Apologies for any rough edges, inconsistencies, omissins and typos. I'm sure we're going to change and improve this text (if this is at all perceived as a useful exercise) and before it could eventually become a RIPE Document. Best regards, Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 -------------------------------------------------------------------------- --- Start of document Generalized Description of Peering Relations in a Routing Registry Erik-Jan Bos, Wilfried Woeber Document ID: ripe-nnn September, 1996 [ adapted and extended from a previous proposal titled: ] [ ] [ A Multicast Router in the Routing Registry ] [ Erik-Jan Bos ] [ Document ID: ripe-nnn ] [ May, 1995 ] **** DRAFT ** WORK IN PROGRESS ** DRAFT **** ABSTRACT This document describes an extension and generalization of concepts as documented in ripe-122 (Specifying an "Internet Router" in the Routing Registry) by which it becomes possible to define peering relations in a very general way. This approach should in particular be understood to support documentation and debugging of "overlay networks" and regular routing protocol peerings at the same time. Originally this work was started to acommodate the description of a multicast capable Internet router within a routing registry. Comments and suggestions received at RIPE DB-WG sessions and private input led to the proposal to generalize the functionality. In addition to the inet-rtr specific attributes we propose the inclusion of a url: attribute, which is already proposed as an extension to all defined objects. 1. Introduction With the growing of the Mbone worldwide, managing the Mbone becomes a complex task. The multicast-bone is already suffering from problems that used to be present in the unicast-bone several years ago, such as routing coordination (and the lack of scoping of announcements). While the Mbone is currently a focus of interest, activity, growth and coordination efforts, we expect the general concept of an overlay network that needs routing coordination to become a general issue (e.g. IPv6 tunnels). Today, registries are available for administering policies and routes and routers [1]. Tools are availble [2,3] for checking and analyzing the real world against what is registered. The Mbone in particular, and other "overlay networks" in general, could and should benefit from these technologies coming from the unicast world. The features of the specification described in this document will be usable e.g. in the RIPE Data Base, after review by the RIPE Data Base WG. After implementation tools could be developed for mapping and analyzing the various different peering environments and/or overlay meshes. Furthermore, administrative details (such as contact person) and operational information (e.g. NOC info as described in role objects) are easily administered by well known procedures and become easily retrievable. Further discussion of the basic concepts led to the idea of generalizing this approach to cater for registering all sorts of peerings, with the dynamic exchange of routing information being a secondary issue. A long-term goal should be to provide the level of configuration and debugging support that is already available for maintaining external unicast routing to a broader range of routing domains. 2. Multicast routers versus unicast routers An "Internet Router" or a "gateway" in the current version of IP (IPv4) can be defined as follows [4]: "Gateways in the Internet form a cooperative, interconnected structure. Datagrams pass from gateway to gateway until they reach a gateway that can deliver the datagram directly." This definition can be applied to both unicast and multicast routers. Since both a unicast and multicast router are fulfilling the "Internet Router" function for different natures of traffic, there is no need for a special routing registry data base object. Moreover, both functions could be present in the same box. 3. A Router specification a multi-protocol router in the Internet Because an Internet Router - can perform different types of routing at the same time, e.g. . IP unicast routing . multicast routing using DVMRP tunnels or PIM . IPv4/IPv6 or "general purpose" tunnels - in many situations there are defined or potential interactions between the routing domains documentation of these facts should be possible in the routing registry. 3.1 A Simple Router Object, IPv4-only, Current Definiton Each router is uniquely defined by by its object name, also known as the fully qualified domain name. Below is an example of a internet router object, specifying a general purpose unicast router: inet-rtr: broodjeham.surfnet.nl localas: AS1103 ifaddr: 192.87.106.102 255.255.255.192 ifaddr: 192.87.4.99 255.255.255.0 peer: 161.53.2.1 AS2108 BGP4 admin-c: Erik-Jan Bos tech-c: Henk Steenman notify: netmaster(a)surfnet.nl changed: Erik-Jan.Bos(a)surfnet.nl 950505 source: RIPE Several pieces of important information are present in this object as described in ripe-122. First of all there is the FQDN of the router, acting as object name. The Home Autonomous System Number is shown, which (currently) is only meaningful in the context of external IP routing. Furthermore, the ifaddr:-lines show that this router has two interfaces, connected to two different networks, and the masks used on these networks. Finally the peer attribute records the IP (Version 4) address for an external BGP peering and lists peering specific information, eg. the localas: of the peer router (AS2108) and the type and version of the EGP used (BGP4). 3.2 A Router for IPv4 and DVMRP, extending the current structure For a moment, let us assume that this box is at the same time used as a multicast router and has a DVMRP tunnel configured. One of the approaches would be to define a dedicated attribute to describe this configuration, say mpeer: for multicast peering. The router object would then look like the following example: inet-rtr: broodjeham.surfnet.nl localas: AS1103 ifaddr: 192.87.106.102 255.255.255.192 ifaddr: 192.87.4.99 255.255.255.0 peer: 161.53.2.1 AS2108 BGP4 mpeer: 192.87.108.13 16 1 admin-c: Erik-Jan Bos tech-c: Henk Steenman notify: netmaster(a)surfnet.nl remarks: SURFnet Multicast router changed: Erik-Jan.Bos(a)surfnet.nl 950505 source: RIPE While all the previously defined and well-known attributes would remain unchanged, the newly invented mpeer: line would be used to describe a DVMRP peering and showing it's peer's IP address, the treshold and metric. Again, the format and interpretation of the entries beyond the IP (Version 4) address would be specific for that attribute. The advantage of that approach is that there is no need to change the definition of exiting attributes, which in turn preserves the functionality of any tools written to understand the specific information. However, there is a couple of major disadvantages when proceeding in that direction - the most important ones being that - the object's definition and schema has to be changed whenever a new attribute for a differnet kind of peering is proposed - frequent changes of the objects schema would lead to incompatible versions of the software - eventually having a sizeable number of different attributes for the various peerings leeds to congestion of the namespace for attribute tags and (probably) to confusion and errors on the human part of the system - and (maybe the most important thing) there is currently no way to describe peerings that do not use IPv4 addresses to identify the peer, e.g. IPv6 and some other protocols 3.3 The Generalization of the Peer Description Concept Because of these reasons given in 3.2 we propose to change the concept of the peering description to become more general and extensible by moving the peering protocol identifier into the first part on the line and deriving the format and meaning from that. Thus the example object used here would look like the following: inet-rtr: broodjeham.surfnet.nl localas: AS1103 ifaddr: 192.87.106.102 255.255.255.192 ifaddr: 192.87.4.99 255.255.255.0 g-peer: BGP4 161.53.2.1 AS2108 g-peer DVMRP 192.87.108.13 16 1 admin-c: Erik-Jan Bos tech-c: Henk Steenman notify: netmaster(a)surfnet.nl remarks: SURFnet Multicast router changed: Erik-Jan.Bos(a)surfnet.nl 950505 source: RIPE Changing the object's schema in that way raises the issue of backwards compatibility versus "cleanliness" (tools) and compatibility of possibly different versions of the software deploied at different registries. 3.4 Backwards Compatibility Discussion For the backwards compatibility we propose to define a new attribute g-peer, "generalized peering description", and eventually make the peer: attribute obsolete - as soon as the tools have been converted to understand the new format. The disadvantage is the coexistence and/or duplicate registration of BGP4 specific information in peer: and/or g-peer: lines. An alternate approach would be to stick with the peer: attribute for the BGP4 specific information and to specify all other types of peering in g-peer: attributes. While this may be an advantage in the short term, it might add complexity for the tools in the long run by requiring them to understand different attribute formats. For the different software version issue we propose to have the implementation treat any unknown peering type (and the rest of the line) as a remark. This situation should generate a warning at the time of registration or update, and there should probably a switch to instruct the software to suppress the warning or do more stringent tests. We specifically ask the maintainers of tools which are currently relying on the peer: attribute, and the RIPE- and Internet-Community in general, for guidance about these issues! All other attributes would remain as already defined for a routing registry [1]. See next chapter for the syntax definition and concepts for extension. 4. Multiprotocol Router Syntax Definition An object for a router capable of maintaining different routing protocol (or tunnel) peerings in parallel is defined here. Each of the possible attributes are shown, on a single line. The second column defines whether the attribute must be present [mandatory] of could be present [optional]. The third column defines whether exactly one line is allowed [single] or that more than one line of the same attribute is allowed [multiple]. In case an attribute has more lines than one, the name of the attribute must be repeated on each line. inet-rtr: [mandatory] [single] localas: [mandatory] [single] ifaddr: [mandatory] [multiple] peer: [obsolete] [multiple] g-peer: [mandatory] [multiple] admin-c: [mandatory] [multiple] tech-c: [mandatory] [multiple] notify: [optional] [multiple] remarks: [optional] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] Each attribute has the following syntax: inet-rtr: The fully qualified domain name of the router. localas: The Autonomous System to which the router belongs. [Note: For the time being this is specific for the IPv4 external routing domain. It might even be useful to move that information to a g-peer: BGP4 entry?!] ifaddr: An interface IPv4 address of the router. [Note: the current draft of this proposal does not deal with necessary or desirable changes for IPv6.] peer: obsolete, potentially useful until RR tools are changed! g-peer: A peering of the router with another router, indicating the protocol and any protocol-specific information. [Note: please refer to the next section for the protocols being proposed in this draft and the proposed mechanisms for extension] Format: <protocol-ID> <peer address> <additional information> Examples: g-peer: DVMRP 192.87.108.13 16 1 g-peer: BGP4 161.53.2.1 AS2108 g-peer: IPv6-TUN IPv6-Address IPv6-specific Status: mandatory, multiple instances allowed. admin-c: Full name or uniquely assigned NIC-handle of a contact person for administrative matters. tech-c: Full name or uniquely assigned NIC-handle of a contact person for technical matters. notify: An e-mail address to which notifications of changes to this object should be send. remarks: Remarks or comments, for clarification purposes only. changed: The e-mail address and date of a change. source: Source of the information. 4.1 Discussion of Application Use of this approach has already been discussed for BGP4: g-peer: BGP4 <remote-peer address> <peer AS> example: BGP4 192.87.4.6 AS2122 localAS AS2121 or even g-peer: BGP4 <remote-peer address> <peer AS> [localAS <ASnumber>] DVMRP g-peer: DVMRP <remote-peer address> <metric> <thresh> example: DVMRP 192.87.4.6 192.87.108.13 16 1 IP-over-IP g-peer: IPv4-TUN <remote-peer address> example: IPv4-TUN 192.87.4.6 or g-peer: IPv6-TUN <remote-peer address> example: IPv6-TUN IPv6-Address 4.2 Extensions * t.b.s. * [ The gist of it should be that future extensions could be incorporated by simply editing a software configuratin file to define additional protocol types and supplying the syntax checking rules. To be discussed in more detail. ] 5. Acknowledgements This specification, being an addition to ripe-122, leans on the specification done by the author of ripe-122. Credits go to Tony Bates. Furthermore, the RIPE Mbone-WG has already done some reviewing of a previous version of this document and they receive credits as well. We are grateful for detailed suggestions received from David Kessens (ISI, then with the RIPE-NCC) and Steve Richardson (Merit). 6. Security considerations Security is not considered in this document. 7. References [1] Bates, Tony, "Specifying an Internet Router in the Routing Registry", ripe-122, October 1994. On-line at URL: ftp://ftp.ripe.net/ripe/docs/ripe-122.txt [2] PRIDE Tools Release 1. On-line at URL: ftp://ftp.ripe.net/pride/tools/pride-tools-1.tar.Z [3] Merit Inc. RRDB Tools. On-line at URL: ftp://rrdb.merit.edu/pub/meritrr [4] Douglas Comer, "Internetworking with TCP/IP", Prentice-Hall, 1988. ISBN: 0-13-470188-7. --- End of document --------------------------------------------------------------------------------

2 1

HELP! Seeking AS1800 maintainer
by FREEnet Hostmaster 26 Jul '96

26 Jul '96

Dear All! Could anybody help me to find email address of the person(s) who is responsible for routing policy of AS1800? I'm unable to find it out in databases I'm aware of, but I desperately need to discuss some routing problems with somebody who knows at least how icm-dc-1.icp.net is configured. I suspect this router is doing bogus aggregation for me. I'd be very obliged if you could help me! Thanks. Regards, --- Dimitri I. Sidelnikov FREEnet Hostmaster

3 2