1. Opening
Apologies were received from the following persons who were unable to attend the meeting:
1.1. Welcome
Rob Blokzijl welcomed the participants to the 17th RIPE meeting hosted by NIKHEF and held at WCW, Amsterdam
1.2. Approval of the agenda
The agenda was approved.
1.3. Papers tabled:
2. Minutes of the last meeting.
2.1. Approval of the minutes
The minutes from the 16th RIPE Meeting were approved. The action items from the 16th RIPE Meeting minutes were reviewed. The following list comprises the ongoing action items only. All other action items were closed.
3. RIPE NCC Report
3.1. Technical Report (Daniel Karrenberg)
The RIPE NCC report was given by Daniel Karrenberg. Daniel introduced Geert Jan de Groot and Geza Turchanyi, the new staff at the NCC. Geert Jan joined at the beginning of January and replaces Marten who joins Tony Bates on the PRIDE project. Geza arrived just before the meeting and will work as a trainee for six months. The details of Geza's assignments are to be determined.
NCC activities proceed smoothly although demands have increased significantly again, especially for the registry service. Since the NCC has started operations the European Internet has tripled in size and the number of service providers has increased by an order of magnitude.Daniel stressed that NCC core staffing has not been increased since then.
All additional staff has been funded from and assigned to developmentprojects (Route-Server, GISD, PRIDE). Increased demand means that more staff is indeed needed for the NCC core services. One full FTE is needed in autumn 1994 at the latest. The 1994 expenditure budget has room for this partial FTE-year. Structural funding needs to be secured for this FTE in 1195 and beyond.
Daniel also raised a possible problem concerning the future Internet connectivity of the RIPE NCC. Since SURFnet's withdrawal from EBONE connectivity of the NCC is provided by NIKHEF via SURFnet via Europanet. There is currently uncertainty concerning intra-European connectivity in the second half of 1994, especially the applicable acceptable use policies.
Some service providers have also contacted the NCC and expressed their concern about the undue commercial advantage of anyone providing exclusive access to the NCC.
The NCC is currently evaluating solutions to this problem, including buying service from more than one provider in the future. Daniel noted that there is currently no budget for this as connectivity is part of the office space rental arrangement with NIKHEF. The NCC realises that this issue is closely related to the unbiased and neutral position of the NCC.
Daniel re-stated the current policy that any service provider can connect to the NCC server network at the NCC location in order to achieve direct connectivity to the NCC.
Erik-Jan Bos commented on behalf of SURFnet that every effort would be made to ensure that their customers, including the RIPE NCC, will retain global Internet connectivity.
3.2. Financial Report (Rob Blokzijl)
Rob Blokzijl introduced the financing of the RIPE NCC for 1993 and 1994.A paper was circulated at the meeting outlining the current status of the funding providers and for the previous year. The paper detailed who the providers were and the size of contributions. Income for 1994 currently stands at 200KECU and expenditure at 260KECU. The RIPE NCC budget needs a minimum of a further 40KECU for 1994. All service providers, espe-
cially those who have not yet made any contribution to the RIPE NCC funding were encouraged to contribute.
In the following discussions, Glenn Kowack (EUnet) said that for the first day of the RIPE Meeting only, he would match 25% of any financial contribution made by any service provider up to the value of 4000 ECU.
Daniele Bovio also reminded the audience that to avoid incurring VAT when making contributions to the RIPE NCC through RARE, it is advisable to ensure that the contribution has "grant" status. All contributions should be made via Marieke Dekker at the RARE Secretariat.
Action:17.1 Glenn Kowack Volunteered to write a paper for discussion which would focus on a future funding model for the RIPE NCC.
4. RIPE NCC Activity Plan (Rob Blokzijl)
Rob Blokzijl summarised briefly the history of the RIPE NCC Activity Plan. A review of the original activity plan of the RIPE NCC (doc ID: ripe-035) was carried out in 1993 and in January 1994 the results of the review - a draft workplan was circulated for comments. New items include:
(point 4.4)
In the discussions that followed, Mike Norris queried why Point 6.4 specified a deadline for the Annual Report. It was unanimously agreed that there was no need for a deadline to be specified.
The RIPE community were urged to consider the document further prior to accepting it formally as a RIPE document (reported under "10. Points for Decision" on the agenda).
5. Joint Projects - Status and Progress
5.1. PRIDE (Tony Bates)
Tony Bates presented the current status of the PRIDE project.
Copies of the presentation slides
In summary the project is progressing well and is now running with the full staff complement. Marten Terpstra has joined the project as Project Development Officer.
5.2. Router Server (Tony Bates)
Tony Bates presented a summary of the Route Server project.
Copies of the presentation slides
6. European Engineering and Planning Group (Bernhard Stockman)
Bernhard Stockman previously circulated both the draft "Terms of Reference" and the draft "Workplan" for this working group. Both drafts were also circulated at the meeting. Bernhard introduced his new working group by referencing these documents and explaining the background to the group.
7. IP Next Generation (Brian Carpenter)
Brian Carpenter introduced the background to the technical proposals currently being considered for IP next generation. The introduction covered the following points:
Why IP next generation?
Need for decision process
Three Working Groups were/are being created:
The three proposals for IPng are:
The milestones that have been set for next generation IP are:
European input to the content of these papers is strongly encouraged. The archive site for the IPng list is <hsdndev.harvard.edu>. In the questions and discussion that followed the focus erred towards the process of deciding on the next version of IP rather than the technical issues. On the process the following comments were made:
On the technical issues:
Brian Carpenters final comment was that the large commercial vendors of networking equipment would be the major players determining the outcome of the future protocol rather than individual persons.
8. RIPE Restructuring the Organisation
Rob Blokzijl introduced why a RIPE "Restructuring BOF" was being held at the meeting. It was now felt timely to begin the process of restructuring RIPE and RIPE meetings. The task of scheduling has now become so complex that the working groups are no longer at their most productive. Furthermore, overlaps between the scheduling of the groups have become unavoidable.
Those tasked to do the work will be the RIPE chairs and the working group chairs. All those interested are invited to contribute. The discussions will be started in the BOF, and progressed via email. A final draft will be produced by the 18th RIPE meeting.
From the audience, the following comments were made:
9. Reports on Networking with CIS and Baltics
This agenda item was dropped as the speakers were unfortunately, at the last minute, unable to attend the RIPE Meeting.
10.Points for Decision
RIPE NCC Activity Plan
There were two amendments suggested to the activity plan after which the document was formally approved by RIPE. One was concerning point 3.7 Referral service provided by the RIPE NCC. It was suggested that this
should only be open to Network Service Providers who fund the RIPE NCC. Point 3.2 explicitly references the existence of the individual templates for the database objects. As these are now very out of date and about to
be superseded by another document it was felt that a reference to them should be dropped.
EEPG Terms of Reference and EEPG Workplan
The decision on the EEPG Terms of Reference and the Workplan was deferred to the next meeting: it is an integral part of the RIPE restructuring process. The EEPG Working Group was charged to start work on their highest priority work items immediately.
11. Short Announcements
11.1. EUnet
Per Bilse announcement the decommissioning of the machine "mcsun" and invited RIPE participants to enjoy a glass of champagne in the machine room at CWI.
11.2. CEEnet
Wilfried Woeber announced the birth of the CEENet Association. It is a very young association - formed 15.1.1994 in Warsaw, Poland.The "Declaration of Intent" was signed by representatives from the following countries:
Current membership (as of 15.1.1994)
Other countries are expected to join CEEnet in the near future.
Activity (amongst others)
Copies of the presentation slides
(This map is provided to depict the general lines of discussion at the time of the RIPE Meeting)
Last but not least:
Any input is very welcome!
12. Next RIPE Meetings
The scheduling of the next two meetings was discussed and the following dates and locations were agreed subject to confirmation from the local hosts in Portugal for the meeting in September:
NOTE: Subsequent to the meeting, the suggested date above for the meeting had to be changed due to scheduling problems. A new date for the September meeting was circulated to the RIPE list with a waiting period
of one week for objections. The date has now been agreed for Monday 12th September - Wednesday 14th September in Lisbon, Portugal. The offer was kindly made by Pedro Amorim on behalf of the University of Lisbon.
13. Reports from the working group parallel sessions
13.1. Local-ir Working Group (D Karrenberg)
Chair: Daniel Karrenberg
Scribes: Geert Jan de Groot, Daniel Karrenberg
13.1.1. Reports for Information
DE-NIC in Dortmund shut down, the DE-NIC is now in University of Karlsruhe.
The registries in Europe totally assign 100 C's per day on the average. With 80 IR's, this comes close to 1 C/IR/day.
A list of local-IR's has been published [RIPE-101]. It was agreed that this information should be made available via the RIPE database Daniel Karrenberg agreed to write a proposal and submit it to the local-ir and database working groups.
Action: 17.2 Daniel Karrenberg Propose (guarded) RIPE database object representing a local registry, mail to local-ir and db wg.
13.1.2. Local Registry Procedures
The address space assignment procedures have been revised as agreed at the last meeting and during subsequent e-mail exchanges. The new document is ripe-104. Most important changes: in case of a request for a block >= 32C's, 2nd opinion of the RIPE NCC is recommended, less reservation of address space recommended.
Question: How about requests having 16C and ask for 16 more? Answer: Use your judgement (as always).
It was observed that frequently organisations asking for space already have some without knowing it. All registries are reminded to cross-check this for all requests from large organisations. If there is ay doubt, the WAIS server of the database is a good source of information.
The NCC observed that more and more individual assignments are not reported back via the database in a timely fashion. The group confirmed the wording of "immediately but certainly not later than one working day after assignment". Local registries are reminded to adhere to this. The NCC will perform more stringent checks whenever the delegation of additional address space is requested by a local registry.
Address space reservation strategies were briefly discussed. It was agreed not to reserve big blocks of address space (>8 Cs) as a matter of general policy. It was felt that the real CIDR gains from such a reservation policy are minimal. After some reservations about this expressed by Yves Devillers it was decided to discuss this further and to gather some data about assignments and reservations from blocks delegated by the NCC. It was agreed that reservations should not be stored in the database but reported separately to the NCC. Wilfried Woeber volunteered to produce a format for representing assignment/reservation status of address space from delegated blocks. The NCC will collect this data and make it available to all European Internet Registries. The data will be restricted to the European Internet Registries for the time being. Generally customers should not get this information because they easily get the impression that reserved blocks have been allocated to them.
Action: 17.3 Wilfried Woeber Propose a representation address space assignment/reservation status.
It was suggested to produce a tool showing assignment/reservation status graphically. Wilfried Woeber volunteered to propose a representation with help from Willi Huber.
Action: 17.4 Wilfried Woeber Propose a graphical representation address space assignment/reservation status.
Q: Are IR's required to use 193-reserved space before asking for new 194-block? A:NO, but review the reservation after 24months. It is up to the local IR to contact the customer on this.
Autonomous System number assignment procedures are explained in the application form (Document ripe-097). the most important criterion for an AS-number assignment is that the AS number is actually used in external routing on the Internet. A secondary criterion is that the organisation should be multi-homed. AS-numbers do not need to be assigned because router configurations seem to require globally unique numbers. A need is felt to set aside some AS numbers for use in local internets not connected to the Internet.
Action: 17.5 Daniel Karrenberg Ask IANA for a default range (65530-65535 or so) in the line of the network-10 proposal
Reverse Name Service
The "Procedures for DNS Delegation in the in-addr.arpa Domain" (ripe-105) was briefly reviewed.
13.1.3. Proxy Network Entries in RIPE Database
After two reminders on the list no input was received from the proponents of proxy registration. It was the general feeling of the meeting that proxy entries should not allowed mainly for operational reasons but also to make the address space delegation process transparent. The action item to produce a recommendation was dropped. The current recommendation that the organisation address space has been assigned to has to be registered in the database.
13.1.4. Any other business
A large amount of address space currently applied for will never be connected to the Internet (internal networks). A proposal is being made to have these cases use network10.0.0.0, which cannot be connected to the Internet (this will be an RFC soon). There were some drawings on this proposal which are difficult to reflect in ASCII.
Q: Is there a procedure to stop a local-IR if found necessary? A: There is a hook to have it return the non-allocated address space per RIPE-104.
Communication between local IR's and last resort IR is sometimes poor. This needs to be sorted out locally (mailinglist).If need be, a mailing list ir-<country>@ripe.net can be set up.
A local-ir workshop will be held at next meeting: half day, May 16th, 10.00 am.
Action: 17.6 NCC To organise local-ir workshop for the 18th RIPE meeting
13.2. Database working group (Wilfried Woeber)
Chair: Wilfried Woeber
Scribe: Ruediger Volk
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.
13.2.1. 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, maintenance 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-dependencies).
13.2.2. New Database software
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.
Copies of the presentation slides
Experiences
No operational problems were mentioned. Operation of the software, including the organisational environment, is going very smooth and was generally appreciated.
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: 17.7 Wilfried Woeber, NCC To produce the necessary documentation for the new DB software.
13.2.3. 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 XYZ9999-RIPE.
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 prepending 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 initial 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.
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: 17.8 NCC To update and re-circulate the RIPE-Handle proposal and then go ahead with the implementation.
13.2.4. 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.
13.2.5. Future needs
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 guar-
dian 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 were 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: 17.9 NCC To update and re-circulate the Guarded Fields proposal and then go ahead with the implementation.
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.
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: 17.10 NCC To investigate and propose facilities for a "template mode" to support the maintaining database objects.
Syntax checkers (distributed, and/or @ the NCC)
The need for syntax-checking facilities for objects was again stated. The NCC was asked to look into providing this functionality and come up with a proposal.
Action: 17.11 NCC Investigate and propose a syntax-checking facility for the new database software.
13.2.6. New/Revised Objects
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: 17.12 Henk Steenman To update and re-circulate the "dom-prefix:"
proposal.
Action: 17.13 NCC To implement the CLNS Routing Object.
NOTE: Henk to provide the (updated) proposal for the presentations directory.
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 dif-
ferent mechanism (community?). The "connect:" attribute is no longer mandatory.
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: 17.14 Francis Dupont DNS group to review the Domain Object and come up with either a recommendation for retirement or with an updated functionality
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 database software.
13.2.7. Exchange Format
Current status
No progress has been made due to the lack of RIPE-Handles. Can be progressed after implementation of RIPE-Handles.
Recommendations for further action
As an aside - the group proposed to NOT enforce uniqueness of network names.
13.2.8. DB statistics (Domain-Object)
Having statistics about the DB coverage of domains was seen to be potentially useful. Postponed to wait for the Domain Object review by the DNS-WG.
Maintenance of e-mail and .forward for guarded objects
After evaluating possible scenarios it was decided that an automatic modification of either the "email:" attribute of a guarded object or the .forward file for the guardian's account is not desirable. Responsibility of the maintenance remains with the guardians.
13.2.9. Timing considerations for guarded objects, values, secondary DBs
Some operational issues of implementing guarded fields were reviewed. Aspects discussed in more detail were:
Action: 17.15 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: 17.16 NCC Propose and implement a mechanism to properly keep track of individual updates of objects and automatic merge/modification operations.
13.2.10. Deletions, Ownership of Objects, Interdependency
This was a more general discussion, focusing 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 maintenance. 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 analyse, 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 database 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.
AOB
None.
13.3. EEPG
Chair: Bernhard Stockman
13.3.1. Welcome
Bernhard Stockman opened the meeting and welcomed the participants. Firstly the agenda was adjusted to follow-up on the discussions of the previous day with respect to the draft "Terms of Reference" (ToR) and the draft "Workplan" documents of the EEPG. Furthermore, the order of agenda items was modified slightly to allow the DANTE routing discussions take place before the Mbone agenda point.
The discussion of the first day of the RIPE meeting concentrated on Work plan and the Terms of Reference of the EEPG. Bernhard Stockman summar ised the EEPG starting points:
The discussion on the EEPG ToR from the first RIPE meeting day continues and is summarised in points below:
Action: 17.17 Bernhard Stockman Draft a new version of the EEPG ToR and distribute this on the mailing list ASAP.
Items for the EEPG Workplan are:
Swedish Routing Lab
PRIDE (making tools)
D-GIX testing tools
Action: 17.18 Bernhard Stockman Draft a new version of the EEPG work plan and distribute this on the EEPG mailing list ASAP.
13.3.2. D-GIX/IXF
IEPG identified the global routing problem, other people sat down and just did it: MAE-East in the Washington DC area. A test Route Server was installed and managed at the GIX from RIPE NCC.
During the last IEPG MAE-East was declared a success, although the Route Server is not fully productional yet.
Havard Eidnes wrote the D-GIX pilot proposal (available for AFTP from nic.nordu.net): Use the GIX as a rubber band and use long haul carriers to make it wider. A current proposal includes locations such as:
The question is who will do what in the D-GIX:
A problem is that the Routing Registry is not fully populated. Tomaz Kalin asks about the status of the D-GIX project. Bernhard Stockman answers that a start will be made in Stockholm, since there is money available. However, the GIX partners should approve this. Erik Huizer stated that the RTC will and can raise more money for this project.
Further discussion on this issue will be on the EEPG mailing list.
13.3.3. DANTE Routing Plan
Firstly there was discussion regarding whether or not the DANTE Routing Plan should be on the agenda of the EEPG. There was a question - did other service providers present their routing plan inside a RIPE WG or
plenary? Bernard Stockman replied that he thought it was a good idea to have this information during the EEPG. The RIPE restructuring will give more guidelines for further EEPG topics.
Willem van der Scheun reported on the DANTE Routing Plan. The document describing this will be on line after some cosmetic changes to the document. An announcement will be made as soon as it is available.
Regarding the terminology, Willem explained the difference between the various terms used:
The DANTE Routing Plan covers three time periods:
The situation before 1 January 1994:
The situation after 1 January 1994 and before 1 July 1994:
Amsterdam:
London:
Geneva:
The situation after 1 July 1994 (aka the future) is not clear, open issues are:
The way all regionals in Europe connect to each other after 1 July 1994 is unclear at the moment. It is clear that all parties should cooperate and start this as soon as possible as time is running out.
13.3.4. Mbone
Tony Bates and Erik-Jan Bos discussed the Mbone situation in Europe. An overview of the tools needed and the applications available was given. Furthermore a discussion on the current multicast tunnel situation in Europe took place, in which it was clear that the current tunnel situation is far from optimal. This implies that some physical connections carry more than one multicast tunnel.
A first draft for a new tunnel topology in Europe was presented. One of the main topic with this issue is "how to keep the tunnel architecture up-to-date in the changing European Internet environment".
During the discussions following the EEPG working group report, it was agreed that there would be a new RIPE working group which would coordinate Mbone issues. Erik-Jan Bos agreed to coordinate this.
Action: 17.19 Erik-Jan Bos To coordinate work relating to the new RIPE Mbone working group for the next RIPE meeting
13.4. Connectivity (Milan Sterba)
Chair: deputised by Rob Blokzijl
Scribe: Anne Lord
13.4.1. Connectivity - Document Store
Milan Sterba sent apologies confirming that he would not be able to attend this RIPE meeting. His working group was convened by Rob Blokzijl. During the course of the meeting, Milan sent in a status report of ongoing work concerning the Connectivity Document Store.
All other work items relating to this remain open, to be progressed at the next meeting of the WG.
13.4.2. Connectivity - Russian
During this meeting there were several presentations, all of which focused on connectivity to and from Moscow. Alexey Platanov reported on the status of the Moscow fibre backbone planned by RELARN and ISF. The
backbone will initially connect to 15 institutions.
Sergei Berezhnev of Moscow State University then described the Radio MSU network. Copies of the slides may be obtained from Sergei Berezhnev.
Lee Wade (NASA Science Internet) gave a status report on the current lines and routing and the future plans of the NASA Science Internet centred around the IKI space flight centre. IKI is currently connected to three sites and a further eight are planned at 19.2 kbps.
The discussions centred around the complex routing of the Russian backbone. As the backbone will be multi-owned, with AUP policies on some of the lines, commercial traffic may be restricted.; Oleg Tabarovsky volunteered to coordinate the routing discussions.
Action: 17.20 Oleg Tabarovsky To collect data on external lines and restrictions applying to each line that will form part of the Russian back- bone.
13.5. Routing (Jean-Michel Jouanigot)
Chair:Jean-Michel Jouanigot
Scribe:Gilles Farrache
13.5.1. Previous minutes, agenda.
The previous minutes and the agenda were approved. Gilles Farrache volunteered to be scribe.
13.5.2. Ripe-81
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 is now well accepted by the community.
13.5.3. Guarded attributes (NCC)
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.
Action: 17.21 NCC Announce "Support of Guarded attributes in the RIPE database" as a RIPE document.
AS objects cannot be registered using the <[email protected]> automatic update procedure.These objects have to be sent to <[email protected]>.
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.
13.5.4. Block splitting (Marten), discussion
At the last Working Group meeting, an agreement was reached concerning 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.
13.5.5. 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.
13.5.6. 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++'.
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.
13.5.7. 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:
Implementation: Path attribute (BGP); local to an AS; associated with communities. This new idea was discussed, and a series of clarifications were made:
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.
13.5.7. Ripe-81 limitations and pending issues
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: 17.22 RIPE NCC, To implement the AS macros
13.5.8. Default route representation (Blasco), what can't we represent?
Antonio Blasco 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 imple- menting. 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: 17.23 Daniel Karrenberg Write a proposal on including an "advice" tag in the AS object
Action: 17.24 Laurent Joncheray To circulate a paper to routing wg on including the AS Path concept in ripe-81
13.5.9. Inter-AS Local Information, discussion
This extension, as well as the action attached to it (Peter Lothberg), was dropped.
13.5.10. 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.
Action: 17.25 NCC, Daniele Vannozzi To make FAQ on CIDR by Daniele available in the RIPE document store
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:
BGP4/IDPR follow on
13.6. DNS Working Group (Francis Dupont)
Chair: Francis Dupont
Scribe: Mike Norris
13.6.1. Opening
Francis Dupont opened the session. Mike Norris was appointed secretary. Francis Dupont reported CLNS support in BIND, in the form of NSAP and NSAP_PTR resource records. These were used by the CATNIP and TUBA contenders for IPng. Supporting BIND code was available from <ftp.cis- co.com>. There was no date for the release of code to support SIPP.
RP (responsible person) is now an official resource record, so people should update their software accordingly. X25, ISDN, NSAP, NSAP_PTR and AFSDB are still experimental RR BIND was at V4.9, with V4.9.2 in final beta test.
The meeting discussed entries for domain objects in the RIPE database. It was felt that this object should be retained for informational and operational reasons. It was also useful in DNS and other configurations.
On specific domain attributes, there were several proposals. Some of these were prompted by the existence of MX-only domains. In such cases, the zone-c, nserver and sub-dom attributes had no meaning. The status of these attributes should be changed from mandatory to optional.
Given the need to know the primary name server of a domain, it was recommended that there be one nserver field per name server, with the primary being the first in the list. The syntax of this entry should be modified
to:
nserver: <fully-qualified-domain-name> [<IP-address>...]
Francis Dupont announced the following new top-level domains:
Ruediger Volk had developed tools to gather DNS statistics. He would ask the NCC to make these available.
13.7. NIDUS Working Group (Nandor Horvath)
Chairman: Nandor Horvath
Scribe: Anne Lord
13.7.1. GARR on-line Network Resource Guide
Antonio Blasco Bonito gave an update on the status of the GARR on-line Network Resource Guide project. It is planned that this project will be submitted to the ISUS working group for consideration, but no formal steps have been taken yet.
At the national level, the resource guide has been implemented and an NIR interest group has been formed. The resource guide can be accessed via gopher and wais at:
13.7.2. User Services update
Joyce Reynolds gave an update on what is new in the following groups:
IETF User Services Area
There are two new FYI's now ready to be published:
ISN - FAQ for primary and secondary schools.
Update to FYI4 "Answers to Commonly asked "New Internet User" Questions".
RARE ISUS
From the RARE ISUS meetings that were held in Warsaw, Poland, October 1993 the following announcements were made:
Jill Foster has been appointed to chair INET/JENC94 User and Applications Support track
Jill Foster has resigned from ISUS as the chair.
EARNINFO
The EARNINFO group focuses on general end user issues. There are two interesting projects currently in progress:
NETFIND - Earn Pilot
"Guide to Network Resource Tools" (3rd edition) This guide will soon become an FYI document.
A trip report was filed in the Internet Monthly Report (IMR). For further information, please contact Joyce Reynolds
13.8. RIPE re-org BOF (Rob Blokzijl)
A BOF was held on the future structure and organisation of RIPE and RIPE meetings. In the discussions that took place the following issues were identified:
On the subject of work areas, it was suggested that there was a need to identify overlaps in working groups and that moreover, there should be mechanisms to allow working groups to be created and disbanded once their
specific targets had been met. It was also suggested that closed working groups should be allowed.
Action: 17.26 Rob Blokzijl, NCC create new mailing list to enable reorganisation of RIPE discussions to continue and announce to the ripe-list
Action: 17.27 ripe-chairs Summarise in a paper discussions on RIPE re-org and publish before next meeting
14. AOB
14.1. DE-NIC
Juergen Rauschenbach announced the transfer of the DE "Registry of Last Resort" transfer from Ruediger Volk at the University of Dortmund to
Sabine Dolderer and Andreas Knocke at the University of Karlsruhe - contact details as below. The new nic is funded by a consortium of German IP service providers.
org: DE-NIC
status: Registry of Last Resort
person: Sabine Dolderer
person: Andreas Knocke
address: Universitaet Karlsruhe
address: Rechenzentrum / DE-NIC
address: Postfach 6980
address: D-76128 Karlsruhe
country: Germany (de)
phone: +49 721 373723
fax-no: +49 721 32550
e-mail: [email protected]
Thanks were extended to Ruediger Volk for all the hard work he has put into running the "Last Resort" IR in the past.
14.2. Funding
To clear up any misunderstandings, Keith Mitchell from PIPEX confirmed that SWIPnet had prior to the meeting, offered to contribute 4,000 ECU to the RIPE NCC for 1994.
14.3. RARE/EARN merger
This is scheduled to take place on January 1st 1995. Currently RARE provides the legal environment for the RIPE NCC. RARE is asked to ensure that the new organisation that will emerge after the merger will continue
to provide this function.
15. Closing
Rob Blokzijl thanked the participants for attending and declared the17th RIPE meeting closed.