- ripe-list - mailman.ripe.net

Mailing List for NCC Referrals to Network Service Providers
by Daniel Karrenberg 13 Jul '92

13 Jul '92

As a NIC of the last resort the NCC is getting requests from prospective European Internet users on how to connect and consequently which service provider to use. Of course we strive to give complete and unbiased information to people contacting us. Thus far we have been working with a list of service providers based on information sent to us after earlier polls. This is cumbersome because: The list is sparsely populated and never up-to-date. Entries often do not have comparable information. People calling on the phone often want a specific recommendation and cannot understand that we are not able to give that as the NCC has to remain impartial vis a vis the different providers. In order to overcome those problems I propose to get any requesters into contact with all potential suppliers as quickly as possible. The best way to achieve this is to set up a mailing list of all IP service providers and to post all referral requests that reach the NCC on that list. This way all providers get the address of the prospective customer at the same time and can get in touch with them however they see fit. The whole process is streamlined and the NCC stays out of the loop as much as possible to avoid any bias. The proposed name of the list is ip-provs(a)ripe.net. Any IP service provider can subscribe to it by sending a request to ip-provs-request(a)ripe.net. The list is *not* intended for any discussion whatsoever. If anyone in RIPE thinks this should not be done, please speak up so that a discussion can be started. If no serious objections are recieved the NCC will proceed as described. Daniel

1 0

Re: IAB's proposals in response to the work of the ROAD group
by bob＠informatics.rutherford.ac.uk 10 Jul '92

10 Jul '92

COMMENTS ON IAB STATEMENT The following is a set of initial comments regarding the recent statement from the IAB suggesting the adoption of TUBA and CIDR as a practical way forward in solving the impending scaling problems as the Internet grows. The comments are a result of discussions in the Joint Network Team's IP Technical Advisory Group (which advises the JNT on technical issues affecting the operation of the IP service over JANET, amongst other things), but the overall conclusions are mine, made in the context of managing the JANET IP service. Of course, comments at this stage can only be preliminary, as most people here have not had sufficient exposure to the technical arguments as yet. I'm sure this situation will change as we study the pros and cons more deeply. Bob Day Manager, JANET IP Service Joint Network Team, UK 1. We believe that it is a sensible policy to try to set the technical work in a defined direction; if it is necessary to act in the short term then this should be done using technology that is sufficiently mature that it will be reliable in practice, and relatively inexpensive to deploy. 2. We believe that if ISO CLNP is used as a replacement for IP to alleviate the scaling problem then it is important that attempts are not made to "improve" it, and hence to depart from the Base Standard (and preferably not to introduce a new profile, if an existing one can be used instead). Given that we see the use of ISO protocols as a desirable strategic goal, it would be counter-productive to introduce non-standard variants at this stage in the life of CLNP. 3. We have serious concerns, however, about the technical suitability of CLNP to replace IP in the longer term. These revolve around the suitability of CLNP for mapping onto high-performance networks (ATM in particular), and whether CLNP has associated with it a sufficiently functional routing capability to really solve the routing problems of the global Internet in the longer term. Therefore we would not like to see CLNP as a long term goal at the expense of a better network protocol (whatever this might turn out to be). This implies that the resource put into deploying CLNP should be kept as low as possible -- ie by using existing products without expensive developments and "enhancements", and concentrating the bulk of resources on a technically more far-reaching solution. 4. We have some concern that the details of the TUBA proposal are not sufficiently worked out, even at the top level. In particular it is not clear at this stage that the simple model described of hosts determining the capability of other hosts via the DNS takes into account the problems of intervening regional networks that do not support TUBA. Without some strategy at this level, as well as at host level there seems to be a danger of either unreachability or excessive traffic due to failures using CLNP followed by retries using IP. 5. We will support the use of classless addressing on the JANET IP Network as soon as we can do so. However, we note that there may be cases where an attached site network cannot use classless addressing itself due to limitations of its equipment (and of money to do anything about it), and suggest that the NICs should take this into account when assessing a request for a Class B network number -- ie it may not just be a matter of number of hosts that determines a site's requirement, but also one of the technology it has available.

1 0

Re: IAB's proposals in response to the work of the ROAD group
by Denis.Russell＠newcastle.ac.uk 09 Jul '92

09 Jul '92

>Since there has been only one (positive) reaction so far, may I conclude >that RIPE as a whole is supporting the IAB position? I am wondering >how many people have read it and thought "If I don't oppose it is clear >that I agree". So please if you are in favour or of RIPE supporting this, >send me a personal mail message. I'll count them and report back to the list. > >Daniel Daniel, I don't think that I can either support or oppose the IAB position. I have been following the Big-Internet discussion for a few weeks now, and I still don't believe that I sufficiently understand all the issues to give a considered opinion. This applies both to "purely technical" issues, and "mainly operational/political" issues, and all issues in between. (I'm not even sure this is a one-dimensional space :-)). There does not even seem to be any consensus on Big-Internet on how urgently "a solution" is required. Although the need for a solution to the class-B shortage is widely recognized, there is a wide diversity of opinion about how much time interim solutions like CIDR would buy, and thus exactly how urgent the, a, next stage is. The IAB proposals produced a deluge of opinion and dissent on Big-Internet and Ietf over the last weekend. Discounting the bigotry :-), some hard issues emerged. For example, of the two urgent matters, address exhaustion and routing table explosion, there is nothing in the IAB proposal about routing table explosion (i.e. routing aggregation, etc), and Jon Crowcroft has pointed out that if certain accepted NSAP allocation schemes are assumed, then only 5 bytes of CLNS addressing are left. Some believe that adopting CLNP to get 5 addressing bytes rather than 4, and no solution to routing table explosion doesn't look like a good way forwards. This has lead onto a discussion of exactly what the IAB proposal actually means. One extreme is "CLNP standard exactly, together with accepted NSAP allocation", another extreme is "well take IP as a starting point and CLNP is a step forward. Where do we go from there", and, needless to say, all points in between. There have been various messages trying to clear up this confusion, and discussing the implication of various points in this spectrum of interpretation. The above is not deliberately my opinion, but an attempt to summarise my understanding of a very active list. The discussion archives of a little while ago contained 884474 bytes, and that is just for this month. Most of it must be the message storm over the IAB proposal. I must have missinterpreted something if not many things. Please refer back to Big-Internet for the actual discussion. I believe that it is extremely important and urgent that a short-term fix be put into place - presumably CIDR. I believe that it is also extremely important and urgent to decide on the next steps. It is urgent enough that we will probably have to choose a pragmatic "interim" next step that might fall short of a "theoretical best" (though some believe that the next change to the Internet will have to be the last). However, I believe that it is *not* yet clear that "adopting CLNP" - whatever that actually means, is the best choice. It might actually be completely irrelevant. I would hope that the undoubted discussion at next week's IETF will generate more light than heat. (After all, our Internet community prides itself in that doesn't it? That's why we are more successful than others, isn't it?). Only coming OUT of the IETF can we hope to make a decision on this. While it would be nice to be able to take a recommendation in, I don't believe we should. "If you can keep your head when all about are losing their's..." Kipling. Sorry for the long message. Denis. PS Wish I was going to the IETF - sounds like it will be very interesting. :-( Denis Russell email: Denis.Russell(a)Ncl.AC.UK Computing Service Tel: (+44) 91 222 8243 The University Fax: (+44) 91 222 8232 Claremont Road Telex: 53 65 4 UNINEW G Newcastle upon Tyne NE1 7RU ENGLAND

1 0

IAB's proposals in response to the work of the ROAD group
by Daniel Karrenberg 09 Jul '92

09 Jul '92

Friends, Below you find a summary of the IAB (now called Internet *Architecture* Board after moving under the wings of the Internet Society) proposals in response to the ROAD group work which we discussed at the last RIPE meeting. Personally I think that this is a very sound proposal and that RIPE should endorse it. Discussion welcome. Daniel ------- Forwarded Message Date: Wed, 1 Jul 92 19:55:36 EDT From: "Lyman Chapin" <lyman(a)BBN.COM> Subject: IAB proposals for CIDR and IPv7 A summary of the IAB's proposals in response to the work of the ROAD group. ------------------------------------------------------------------------ During its meeting in Kobe, Japan on June 18 and 19, the IAB reviewed the draft report of the ROAD group concerning the problems of "running out of IP network numbers" and "Internet routing table size explosion", and a companion report from the IESG of "IESG Deliberations on Routing and Addressing". The IAB's analysis of the many possibilities suggested by these two reports led it to the following conclusions, which are docu- mented in an internet-draft entitled "IP Version 7": 1) The ROAD group's work, compiled over a period of four months, makes it very clear that the problems of too few IP addresses and too many Internet routes are real and immediate, and represent a clear and present danger to the future successful growth of the worldwide Internet. The IAB was therefore unable to agree with the IESG recommendation to pursue an additional six-month program of further analysis before deciding on a plan for dealing with the ROAD problems. The detailed design, engineering, and deployment work must begin now, and it is therefore imperative that the efforts of the Internet community be focussed on a common goal. 2) The IETF should aggresively pursue the work to engineer CIDR ("classless inter-domain routing", described in RFC 1338), including the extensions to the inter-AD routing protocols to support variable-length masks/prefixes, and the associated address administration paradigm. 3) Since CIDR postpones, but does not prevent, the eventual exhaustion of the 32-bit IP address space, the IETF should also aggressively pursue a detailed technical and organizational plan for using CLNP (the OSI internetwork protocol defined by the ISO 8473 standard, which uses 160-bit addresses) as the basis for a new version of IP (which we have dubbed "IP version 7"), succeeding over time the current version of IP (version 4) in the Internet. An initial description of how CLNP could be used for this purpose within the current TCP/IP architecture and with the existing Internet applications is described in RFC 1347. 4) CLNP has larger addresses than IP, but like IP it lacks features that are expected to be necessary to support future Internet appli- cations and services. The IAB therefore also encourages the pursuit of research in areas such as policy-based routing, route preallocation and cacheing, and deterministic end-to-end QOS mainten- ance (for real-time and other delay-variance sensitive traffic). It is important to understand that (3) above does NOT mean "adopting OSI" or "migrating to OSI" or "converting the Internet to use GOSIP protocols". The IAB recommends only that a new version of IP (IPv7), with much wider addresses and a more extensible header, be based on the existing CLNP. IPv7 is intended to be deployed within the current Internet TCP/IP architecture, not as part of an "OSI stack". There are, of course, many issues that must be resolved before CIDR and IPv7 can actually be deployed in the operational Internet. No one should imagine that there is not still a great deal of work to be done, notwith- standing the efforts that have already been expended by several of the IETF working groups and by the members of the ROAD group over the past year. In recommending that the ROAD problems be addressed by a combination of CIDR, IPv7, and further research, the IAB has deliberately chosen NOT to recommend any of the possible alternatives, so as to present a single focal point for the community consisting of what we believe to be the best technical solutions to the problems. This should not be construed as a blanket "condemnation" of the alternative proposals that have been floated in various parts of the IETF. However, we believe that the normal IETF process of "let a thousand [proposals] bloom", in which the "right choice" emerges gradually and naturally from a dialectic of deployment and experimentation, would in this case expose the community to too great a risk that the Internet will drown in its own explosive success before the process had run its course. The IAB does not take this step lightly, nor without regard for the Internet traditions that are unavoidably offended by it. We look forward to a lively discussion of these conclusions during the upcoming IETF meeting in Boston. - Lyman Chapin IAB chair ------- End of Forwarded Message

2 2

Congratulations
by Sylvain Langlois 08 Jul '92

08 Jul '92

I've just grab the 1st issue of the RIPE NCC Quarterly Report and browse through it. You all deserve loud applause for producing such a high quality report. Thanks for all this *VERY* useful information! Sylvain ---------------- Sylvain.Langlois(a)der.edf.fr

1 0

RIPE NCC Quarterly Report, Issue 1 available
by Daniel Karrenberg 08 Jul '92

08 Jul '92

The first quarterly report of the RIPE NCC is available now. It contains details about NCC activities during the second quarter of this year. The management summary section is attached below. The document is available from the RIPE document store in both PostScript and ASCII form. The document name is ripe-ncc-02. The FTP filenames are: ASCII: ~ftp/ripe/docs/lpr/ripe-ncc-02.lpr PostScript: ~ftp/ripe/docs/ps/ripe-ncc-02.ps Note that the PostScript version is not only much nicer looking but also contains graphics not representable in the ASCII version. Hardcopies of the report will be sent to all organisations contributing to the funding of the NCC. We welcome any comments you might have about the contents or the format of this report. Regards Daniel Karrenberg NCC Manager ------------------------- Management Summary A good and quick start The RIPE NCC formally started operations in April 1992 with the NCC man- ager. He was joined in May by the network engineer and the network administrator. During March, even before the official start of activities, the office space was organised and the computing equipment was installed. This enabled the NCC to provide core services from day one. The first two months of operation with the full staff com- plement were used to quickly establish a comprehensive set of services, as specified in the NCC activity plan. Some of these were a continuation of services that hitherto had been provided elsewhere. An orderly and timely transition to the NCC of these services was carried out with help of all those who had been involved with their provision. Recently, the NCC has established a number of new services. Detailed information about all the activities can be found in "Activities". As expected general set-up and training activities also con- sumed resources during this phase. Since these activities are operational overheads, they will not be detailed below. Priorities During this start-up phase, priority was given to establish- ing those activities which can be both quickly initiated and produce results. Activities needing a longer set-up time and/or those which need considerable guidance from RIPE have been postponed until a basic service level is achieved and recognised by the community. Important Topics The section on "Important Topics" highlights issues around future charging models for NCC services and the mapping activity. Outlook The NCC will use the next three months to consolidate the current achievements and to stimulate consensus building in RIPE about priorities for the longer term activities. These will then be started in the third quarter of NCC operations following the next RIPE meeting.

1 0

Networking in Malta ?
by Daniel Karrenberg 02 Jul '92

02 Jul '92

If you know about networking in Malta, please reply to Joseph Galea <joe(a)comp.vuw.ac.nz>. ------- Forwarded Message Date: Thu, 02 Jul 1992 10:30:26 +1200 From: Joseph Galea <joe(a)comp.vuw.ac.nz> To: dfk(a)ripe.net Subject: Networking in Malta Hi Daniel, At the moment I am in New Zealand working at a University which has a very sound networking environment. This September I will be returning to Malta and while I am still here I thought of getting some information as to what has happened networking wise so far, if any, in Malta. I intend to convey any valuable information to people who are concerned with the Maltese educational institutions, the major two of which are the University and the Polythec. No educational institution can afford to remain isolated from the rest of the world! If nothing has been done so far, I understand that funding could be a problem for the local authorities. I would be grateful if you could send me any information. Cheers Joseph Galea ------- End of Forwarded Message

1 0