From Marten.Terpstra at ripe.net Mon May 3 11:23:56 1993 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Mon, 03 May 93 11:23:56 +0200 Subject: Networks being routed and not in the database ... Message-ID: <9305030923.AA18194@ncc.ripe.net> Folks, It seems again that there are some networks that ARE routed on EBONE, but are not in the RIPE database. Since these networks are from the 193.* range, they are not supposed to be used as long as they are not in the database. Taken from the procedures: " C) Full information about reassigned network numbers must be reported back to the RIPE NCC in full RIPE database format (ref ripe-13). The complete entries should be sent immediately after reassignment to . " Please take appropriate action for the following networks: 193.64.4.0 not in database 193.64.64.0 not in database 193.124.18.0 not in database 193.124.80.0 not in database 193.128.191.0 not in database 193.141.49.0 not in database 193.141.54.0 not in database 193.166.66.0 not in database -Marten From Marten.Terpstra at ripe.net Mon May 3 13:56:51 1993 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Mon, 03 May 93 13:56:51 +0200 Subject: 193.in-addr.arpa procedures -> ripe-85 Message-ID: <9305031156.AA18641@ncc.ripe.net> Folks, The 193.in-addr.arpa delegation procedures have been made into a RIPE document ripe-85. Only changes since version 1.4 are a few typos and cosmetic. You can find it as ftp.ripe.net:ripe/docs/ripe-docs/ripe-85.txt It is now version 1.5. Before asking for a block delegation, please read the document. Cheers, -Marten From Daniel.Karrenberg at ripe.net Fri May 14 10:09:04 1993 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 14 May 93 10:09:04 +0200 Subject: Supernet block sizes - recommendations? In-Reply-To: Your message of Thu, 13 May 93 10:36:36 PDT. Message-ID: <9305140809.AA18307@ncc.ripe.net> > Vince Fuller writes: > Same here. For large chunks of class C's, we send the end site directly > to the NIC. > > This somewhat defeats the goal of using CIDR to reduce routing table > explosion, since if the block comes directly from the NIC, no > aggregation can be done by the service provider which connects the site. Well it depends. If the chunks are large, reasonable aggregation still happens. No offence to Vince but we should concentrate on the lower levels of aggregation. That's where it matters most and where entropy is hopefully going to be less of a factor in the future. I have discussed this recently with some fairly senior people and to my big surprise and dismay they really thought the (achievable) object of the exercise was one supernet route per continent! :-) :-( Let me explain a little the strategy we recommend here: 1) Allocate a conservative(!) chunk size as most requestors have a tendency to stockpile. So unless they provide a good justification, they will be allocated less than requested. 2) To prevent low level entropy, "reserve" a contiguous chunk for the same requestor. Usually this is the same size as the chunk allocated. Tell the requestor that they can get (part of this) contiguous address space upon presenting documentation on how they use the first chunk. After about a year we have seen that only a small part comes back for more. 3) We plan to recycle the reserved space after 12-18 months. If we err very low in the first assignment we will have to open a new discontiguous chunk for the same organisation. So we have created two supernet routes instead of one. How big a deal is this if it happens occasionally? I deem this and acceptable tradeoff between address space usage and routing table size. Example: If we get a request for 64 Cs which is not very well substantiated we will allocate 16 or 32 and reserve the same amount. And now for something completely different..... Ways to convince people to let go of a "class" B request: Take their projected host and subnet numbers. Compute the address space usage factor and tell them: "Your own projections show that you will use only x% of the address space you request. By the Internet community's standards this too wasteful." We regularly get requests that lie in the low single digits by this standard. Of course you have to consider the proposed subnetting scheme. If they propose lots of 8-bit subnets with less than 10 hosts on them, we do suggest a different subnet size or in extreme cases even subnetting Cs. Tell them: "A scheme for classless inter-domain routing is coming. This means classes will no longer be visible soon. So why bother." Tell them that the procedure for getting Bs takes longer and requires them to provide more information to justify the request.... and keep that promise. Refer really notorious cases to the next higher level Internet Registry. They have more experience and a much thicker skin. We have been sitting on some bogus requests for a long time and I expect IANA to just sit on some indefinitely. This is really convincing and sometimes the only escape! Hope this helps some of you. Comments welcome. Daniel From aggarwal at nisc.jvnc.net Fri May 14 15:28:44 1993 From: aggarwal at nisc.jvnc.net (Vikas Aggarwal) Date: Fri, 14 May 93 9:28:44 EDT Subject: Supernet block sizes - recommendations? In-Reply-To: <9305140809.AA18307@ncc.ripe.net>; from "Daniel Karrenberg" at May 14, 93 10:09 am Message-ID: <9305141328.AA08913@nisc.jvnc.net> > Ways to convince people to let go of a "class" B request: > > Of course you have to consider the proposed subnetting scheme. If they > propose lots of 8-bit subnets with less than 10 hosts on them, we do > suggest a different subnet size or in extreme cases even subnetting Cs. > > Tell them: "A scheme for classless inter-domain routing is coming. This > means classes will no longer be visible soon. So why bother." My simple argument is usually this: Unless you are planning to have more than 255 hosts on a single subnet (which might not be a good idea in a *lot* of cases, and can also be offset by the 'secondary' addressing scheme of some router vendors), a group of class C addresses is way more flexible than a class C. Consider: 1. No more worries about 'split' subnets in wide area nets-- a definite problem in unforeseen future expansion plans. Subnet a class C on your wide area net and allocate other class C's at the end sites. This does not affect the site's routing tables (since their routers would have to carry all the subnets anyway). The large number of class C addresses is probably of more concern to ME (as a service provider) if I am not using CIDR. 2. No more worrying about variable length subnets, etc. Take a class C net, chop it up using whatever boundary wanted, and use a different mask for the other class C. Less administrative and technical headaches!! Usually these arguments do the trick-- its a matter of technical sense prevailing over 'I want a class B' pride. -vikas vikas at jvnc.net From Marten.Terpstra at ripe.net Fri May 14 16:09:23 1993 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Fri, 14 May 93 16:09:23 +0200 Subject: Mail archive Message-ID: <9305141409.AA20236@ncc.ripe.net> Folks, We have created an archive of all mail that has gone over the local-ir mailing list on ftp.ripe.net:ripe/archives/local-ir. The current directory contents is: % ls -lg ~ftp/ripe/archives/local-ir total 236 -rw-r--r-- 1 marten staff 24624 May 14 16:03 local-ir.Apr-93.Z -rw-r--r-- 1 marten staff 39879 May 14 16:02 local-ir.Dec-92.Z -rw-r--r-- 1 marten staff 15961 May 14 16:02 local-ir.Feb-93.Z -rw-r--r-- 1 marten staff 25229 May 14 16:02 local-ir.Jan-93.Z -rw-r--r-- 1 marten staff 101723 May 14 16:03 local-ir.Mar-93.Z -rw-r--r-- 1 marten staff 2740 May 14 16:01 local-ir.Nov-92.Z -rw-r--r-- 1 marten staff 15711 May 14 16:01 local-ir.Oct-92.Z -Marten From tjs at msc.edu Fri May 14 16:35:49 1993 From: tjs at msc.edu (Tim Salo) Date: Fri, 14 May 93 09:35:49 -0500 Subject: Supernet block sizes - recommendations? Message-ID: <9305141435.AA18096@uh.msc.edu> > From: aggarwal at nisc.jvnc.net (Vikas Aggarwal) > Subject: Re: Supernet block sizes - recommendations? > To: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) > Date: Fri, 14 May 93 9:28:44 EDT > Cc: regional-techs at merit.edu, local-ir at ripe.net > [...] > Usually these arguments do the trick-- its a matter of technical sense > prevailing over 'I want a class B' pride. We ought to have a better response to the claim: "I want a class B to improve performance, (because I can easily make my UNIX software use larger MTUs)." -tjs From Havard.Eidnes at runit.sintef.no Thu May 20 22:45:03 1993 From: Havard.Eidnes at runit.sintef.no (Havard Eidnes) Date: Thu, 20 May 1993 22:45:03 +0200 Subject: Supernet block sizes - recommendations? In-Reply-To: Your message of "Fri, 14 May 1993 09:35:49 CDT." <9305141435.AA18096@uh.msc.edu> Message-ID: <9305202045.AA26332@spurv> > > Usually these arguments do the trick-- its a matter of technical sense > > prevailing over 'I want a class B' pride. > > We ought to have a better response to the claim: "I want a class B to > improve performance, (because I can easily make my UNIX software use larger > MTUs)." If this is critical, you can suggest modifying the constants in /sys/netinet/in_proto.c (at least on Suns running SunOS 4.x): /* * Default TCP Maximum Segment Size - 512 to be conservative, * Higher for high-performance routers */ int tcp_default_mss = 512; Yes, bumping up tcp_default_mss will do so for all destinations (unless the final destination requests a lower mss). This is not without its problems: it may have a detrimental effect on traffic passing through paths with a lower MTU (causing fragmentation, which we know to be harmful), as well as cause extra serialization delay on slowish serial links, causing slower response time for simultaneously running interactive sessions. The correct fix is to implement MTU discovery, I guess, but not many vendors do that yet... - Havard From Daniel.Karrenberg at ripe.net Wed May 26 13:44:10 1993 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 26 May 1993 13:44:10 +0200 Subject: Local-IR Feedback on the PRIDE Project Message-ID: <9305261144.AA22225@ncc.ripe.net> Dear RIPE local-IR WG member, you chairperson has received (:-) the following request. Since this proposal is very much relevant to the local-ir WG I would appreciate your comments however short. Thank you Daniel ------- Forwarded Message Date: Wed, 26 May 1993 13:28:44 +0200 From: Daniel Karrenberg To: RIPE WG Chairpeople cc: RIPE Chairpeople Subject: PRIDE Project As you know the current route server project will end in July this year. In order to contnue work on the routing registry I have put together the following project proposal called PRIDE which I will also put in the RIPE document store shortly. Already some national members of RARE have indicated their willingness to fund part of the project provided that the RARE technical committee agrees that the project is useful, which I am confident they will do. At the same time it is neccessary that the RIPE community discusses this and comes to a position on it. Since time is pressing I would appreciate comments from you personally and your working group no later than Monday June 7th. It would be ideal if the chairpersons of the WGs and the RIPE chair could agree by then that RIPE supports this proposal, which would give it added weight. Note that I regard the proposal text to be finished and I am reluctant to make drastic changes to this version. Clarifications and additions to make it clearer as well as small additions are of course welcome. Even more welcome are offers of contributions to the funding, however small. Daniel P R I D E Policy based Routing Implementation, Deployment in Europe A Project Proposal Daniel Karrenberg Manager RIPE NCC - 2 - The Need In todays Internet environment, policy based routing technology providing routing of traffic between different network operators is a key technology. While tools are available to apply routing policy they are not used in a coordinated way if used at all. In a general mesh topology applying policy without coordination and prior simulation of the consequences will eventually lead to an unmanageable situation. This potential problem has been noted in [1] and several of the references cited therein. As an immediate measure the GIX (Global Internet Exchange) has been proposed in [2] and a proposal for a GIX routing implementation has been made in [3]. It is noteworthy that the GIX only solves part of the problem: routing consistency and connectivity at the global level. In order for the Internet to cope with its current growth, the routing problem will also need to be solved at the regional and local levels. The "RS" project (1) has recognised this by spending significant resources on establishing consensus within RIPE on how routing policies are stored in the European routing registry[4]. Once registered the information can be used to ensure proper operation of the European part of the Internet. The project is making significant progress in this area. The routing registry and tools being developed are much more general than those used and proposed so far for use in the current Internet. It is expected that the architecture will eventually allow multiple major interconnect points as envisaged in [1]. _________________________ 1) "Implementation of a Route Server for policy based routing across the GIX", a joint RARE/RIPE project currently funded by SURFnet. - 3 - In order to promote the European routing registry and the associated technology two key ingredients are needed: Implementation A set of tools for use by local network operators needs to be developed. The "RS" project deals only with the tools needed by the route server itself. While some of these can be adapted there are not sufficient resources to properly produce tools for local network operators. These tools will enable them to use the routing policy stored in the routing registry to perform such tasks as check actual routing against policies defined, ensure consistency of policies set by different operators, and simulate the effects of policy changes. DEPloyment In order to be useful the routing registry and associated tools need to be deployed rapidly by all significant network operators in the European Internet. This means there is a big need for information and training of the network operator staff, coordination of deployment and support activities. If enough information and education pressure can be applied there is a good chance that the technology will be deployed outside Europe as well. First signs of this are already visible as the CIX (Commercial Internet eXchange) association has announced their intention to deploy a route server using the RIPE routing registry technology. The urgent need for these two ingredients motivates this project proposal and has suggested the name PRIDE: Policy based Routing Implementation and Development in Europe. - 4 - The Results The tangible results of the project will be the following. Implementation In the implementation area of the project, tools will be developed, documented and made publicly available for use by network operators. A complete list of those tools cannot be specified in advance since specific needs are likely to evolve during deployment. Flexibility to meet those needs and agree about priorities with the network operators is a key element to ensure acceptance and thus the success of the project. The tools are expected to include: prcheck A tool to check the consistency of routing policies stored in the routing registry. This tool will flag if two neighbouring network operators specify conflicting or inconsistent routing information exchanges with each other and also detect global inconsistencies where possible. prpath Extract all (AS-)paths between two networks which are allowed by routing policy from the routing registry. prconn Display the connectivity a given network has according to current policies. This will of course also be able to find the set of networks a given network can not reach. prtraceroute A version of the existing traceroute tool which will be able to display whether a route in use is allowed by policy and where deviations from policy occur. The range of implementable routing policies is currently limited by the destination based routing and forwarding technology. There are efforts underway to enable forwarding decisions based on the source of packets as well as the destination. The routing registry and tools will need to both follow and influence developments of destination based routing and forwarding in IPv4 as well as next generation IP. - 5 - Deployment This is the key part of the project. Without widespread deployment of the routing registry at least in Europe the results of the "RS" project and the Implementation part of the PRIDE project will be academically interesting but not much more. The result of this part of the project is thus widespread deployment of the routing registry and associated tools as possible. The tangible results will be: - instruction and training material about the routing registry as such and the way routing policies need to be expressed for registration - delivery of the information and training to key communities in Europe - coordination of the actual deployment of the tools and especially the registration of routing policies in the routing registry - general presentation material about the routing registry - delivery of the presentation material to key communities worldwide The delivery of training and coordination and deployment will consume the bulk of the project resources. It should be noted however that the proposed resources are not sufficient for a general support or help desk function. This would need significantly more resources. Because we believe network operators will invest here in their own interest we propose to focus on targeting information and training well and to provide coordination only. The RIPE community will then form the network for mutual support as it has done successfully in the past. - 6 - The Partners In order to realise the goals of this project, close cooperation with as many service providers as possible will be necessary. European service providers are already following and influencing the developments closely through RIPE. Both the amount of input received during the design of the routing registry and the rate at which information is being registered show this works well. Worldwide contacts with groups involved in similar developments are also already established via RIPE, IEPG and IETF. The close coordination of all parties deploying route servers on the GIX and the recent announcement by the CIX association of their intention to use the RIPE routing registry technology are good examples of this. The project will exploit these already existing channels and be open to new ways of reaching the service providers in particular. All service providers will have equal access to the tools, the routing registry itself and the information and training materials. - 7 - The Resources The resources needed for the PRIDE project are estimated as follows: - 2 senior engineering staff for 12 months representing 24 FTE months. These will need renumeration equivalent to senior network engineer levels including overheads. The estimated cost of this is 84kECU. - The deployment part will necessitate significant travel for delivery of the information and training. The estimated travel cost is 20kECU. - Professional document design for the materials is desirable. It is difficult to estimate the cost for this at this point but 10kECU should be sufficient. - Computing resources. Minimally a personal WS and some storage capacity. 10kECU will be sufficient. - 1/3 of senior technical management for 12 months. Technical management of the current RS project is provided by the RIPE NCC. This withdraws resources from NCC core activities which need to be replaced. Estimated cost of this is 20kECU. The total project cost for 12 months is thus estimated at 84+20+10+10+20 = 144kECU. The above resource levels are purely for the work specified and do not include formal project management and formal (non-technical) reporting. After completion of the project and successful deployment of the routing registry, a level of maintenance effort will be needed for the tools and the routing registry. This should be a structural activity much like the current RIPE NCC core activities. In order to start up quickly the implementation part can be started first as a sub-project with one engineer. It should be noted however that without the deployment effort following, this will have only a very limited effect. - 8 - References [1] T. Kalin: "Global Network Interconnect", Amsterdam, 8 Jan. 93, EC(92)093v3 [2] G.Almes, P.Ford, P.Lothberg: "Proposal for Global Internet Connectivity", IEPG Working Document, June 1992 [3] Tony Bates, Daniel Karrenberg, Peter Lothberg, Bernhard Stockman, Marten Terpstra: "Internet Routing In a Multi Provider, Multi Path Open Environment", Document RIPE- 82, March 1993 [4] Tony Bates, Jean-Michel Jouanigot, Daniel Karrenberg, Peter Lothberg, Marten Terpstra: "Representation of IP Routing Policies in the RIPE Database", Document ripe- 81, March 1993 ------- End of Forwarded Message From Daniel.Karrenberg at ripe.net Wed May 26 23:29:26 1993 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 26 May 1993 23:29:26 +0200 Subject: RFC1466 is out at last Message-ID: <9305262129.AA23848@ncc.ripe.net> ------- Forwarded Message Date: Wed, 26 May 93 11:44:55 PDT From: "Joyce K. Reynolds" Sender: ietf-announce-request at IETF.CNRI.Reston.VA.US To: IETF-Announce:group list ; cc: jkrey at isi.edu Subject: RFC1466 on Guidelines for Management of IP Address Space - --NextPart A new Request for Comments is now available in online RFC libraries. RFC 1466: Title: Guidelines for Management of IP Address Space Author: E. Gerich Mailbox: epg at MERIT.EDU Pages: 10 Characters: 22,262 Obsoletes: RFC 1366 This document has been reviewed by the Federal Engineering Planning Group (FEPG) on behalf of the Federal Networking Council (FNC), the co-chairs of the Intercontinental Engineering Planning Group (IEPG), and the Reseaux IP Europeens (RIPE). There was general consensus by those groups to support the recommendations proposed in this document for management of the IP address space. This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-REQUEST at NIC.DDN.MIL. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to "rfc-info at ISI.EDU" with the message body "help: ways_to_get_rfcs". For example: To: rfc-info at ISI.EDU Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to NIC at NIC.DDN.MIL. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at ISI.EDU. Please consult RFC 1111, "Instructions to RFC Authors", for further information. Joyce K. Reynolds USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mail-server at nisc.sri.com" Content-Type: text/plain SEND rfc1466.txt - --OtherAccess Content-Type: Message/External-body; name="rfc1466.txt"; site="nic.ddn.mil"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain - --OtherAccess-- - --NextPart-- ------- End of Forwarded Message From Daniel.Karrenberg at ripe.net Thu May 27 14:37:42 1993 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 27 May 1993 14:37:42 +0200 Subject: RIPE NCC Review Message-ID: <9305271237.AA26239@ncc.ripe.net> As agreed at the last RIPE meeting a review of the first year of NCC operations as well as a review of the NCC activity plan will take place. The review board will consist of the RIPE chair, the RIPE WG chairpeople and the NCC manager. Any interested members of the RIPE community will also be invited to paricipate. The RIPE chair is going to announce this activity shortly. The local-ir WG has a problem here as the chairperson *is* the RIPE NCC manager. To avoid any possibilities of a conflict of interests I would appreciate if the local-ir group could agree on a different representative for this purpose. If you are prepared to represent the local-ir group in this, please identify yourself either to me or to the while group. Ragrads Daniel