Skip to main content

RIPE 17 Minutes

1. Opening

Apologies were received from the following persons who were unable to attend the meeting:

  • Dmitry Volodin - DEMOS
  • Svend Moeller Nielsen - Unisource
  • Michail Popov - DEMOS
  • Michael Nowlan - IEunet
  • Sergei Kritsky - Open Contact
  • Andrey Ivanov - Open Contact
  • Milan Sterba - CESnet

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

  • Agenda for the 17th RIPE meeting
  • Working Group Agendas - one document
  • Announcement of the Amsterdam Internet Exchange
  • Draft terms of Reference for the European Engineering and Planning Group (EEPG)
  • Mailing List of the EEPG working group
  • DRAFT RIPE NCC Activity Plan
  • Announcement of the Swedish Routing Laboratory and the Stockholm d-GIX Pilot node
  • RIPE NCC Financial Contributions

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.

Action: 15.10 Daniel Karrenberg
To propose new tags "created" and "assigned" to the database working group for consideration - pending

Action: 16.6 Daniel Karrenberg
Why return unused IP address space and be a good network citizen. Daniel to find volunteer to continue the work.

Action: 16.17 Jean-Michel Jouanigot
To coordinate the transition from ripe-060 to ripe-81 format for routing description

Action: 16.18 NCC
Try to actually get the synchronisation of the various database going, using the recently agreed DB Exchange Format. Action is pending and dependant on the NIC handle.

Action: 16.21 Milan Sterba, Anne Lord
Produce the umbrella document for the CDS.

Action: 16.22 Milan Sterba
Solicit contributions to the CDS

Action: 16.23 Milan Sterba, NCC
Create the [email protected] alias and establish procedures to integrate new CDS contributions and maps to the CDS.

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:

  • the plan will remain valid for a period of two years (point 7)
  • the plan now defines how changes and amendments to the plan can be made during that 2 year period (point 7)
  • RIPE NCC involvement in Special Projects is an approved core activity (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.

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.

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?

  • Address Space expiry
  • Router table overflow
  • To support new software/hardware e.g. mobile computers, multimedia etc.

Need for decision process

  • Previously there was nothing
  • IESG appointed two directors: Scott Bradner and Allison Mankin
  • They chose a directorate to assist them (two non US members)

Three Working Groups were/are being created:

  • ALE - Address Lifetime Expectancy
  • Transition - IP transition to IPng)
  • Requirements (to write the requirements in a neutral way). Note: a European Co-chair is wanted currently for this working group.

The three proposals for IPng are:

  • CATNIP (ex TP/IX)
  • SIPP (ex SIP and PIP)
  • TUBA

The milestones that have been set for next generation IP are:

  • Feb. 1st, 1994: White Paper on Engineering Considerations (see rfc 1550)
  • March 1994: Status report to Seattle IETF
  • July 1994: Bradner and Mankin make their recommendation at the IETF in Toronto

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:

  • the July 1994 date for a recommendation was questioned as achievable.
  • a final cutoff date for "final' proposals should be set.
  • expected deployment date was questioned. It was suggested that there would be at least 15 years co-existence with IPv4.

On the technical issues:

  • flat address space was not favoured - there is a technical need for extensible addresses
  • there should be consideration of the existence of many local providers operating in any one area
  • technical simplicity is desirable
  • policy routing is of key importance

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:

  • there may be a need for a RIPE "steering committee"
  • mechanisms for creating and discharging working groups are needed

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
  • EEPG Terms of Reference
  • EEPG Work Plan

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:

  • Austria
  • Bulgaria
  • Croatia
  • Czech Republic
  • Hungary
  • Poland
  • Slovakia
  • Ukraine

Current membership (as of 15.1.1994)

  • ACOnet for Austria
  • UNICOM for Bulgaria
  • CARNet for Croatia
  • CESnet for Czechia
  • NASK for Poland
  • SANET for Slovakia
  • UARNet initiative group for Ukraine

Other countries are expected to join CEEnet in the near future.

Activity (amongst others)

  • collective treatment of international networking affairs
  • plan and provide a backbone in that region.

(This map is provided to depict the general lines of discussion at the time of the RIPE Meeting)

Last but not least:

  • each country is represented by only one organization with governmental authorization
  • CEEnet intends to become a member of relevant international networking organizations
  • currently there is no intent to collect membership fees etc., the"General Assembly" will select an organization to act as the financial clearing house

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:

  • May 16-18th, 1994 - Amsterdam
  • September 28-30, 1994 - Portugal*

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.

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.

  • Please note that during the discussion (by accident) we all were talking about a prefix format

The NCC was mandated to circulate an updated proposal, including operational aspects, and after a short review-process (e-mail), go ahead with the implementation.

Action: 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 guardian of the AS-value. Changes to such objects do NOT generate a notification message. This functionality can be achieved by using the"notify:" attribute. The "notify:" attribute for an object is evaluated before the update is made. The technical issues of RIPE-81 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 different 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:

  • timing and interlock: Some mechanism must be set up by the NCC to allow for checking the merge/update status of the current version of the data base. This should allow for an automatic delay of retrieving the DB for local use and/or providing read-only copies. The NCC will come up with a technical proposal how to do this.
  • change control: in order to preserve the update history for database objects a structured scheme was proposed. This method preserves the "changed:" attributes supplied by any manual update process. In addition to that any automatic up-date and/or merge operation done by the database software maintains a single related "changed:" attribute describing the "agent" performing the modification. From a formal point of view, regular maintenance and/or merge operations are NOT treated as update operations, thus e.g. they do not trigger (automatic) notification messages.

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:

  • EEPG does not fit as a WG into the RIPE framework entirely
  • EEPG will take on general coordination (identifies problems and fires of working groups or task forces)
  • EEPG will work in the European Internet environment

The discussion on the EEPG ToR from the first RIPE meeting day continues and is summarised in points below:

  • EEPG will not have a mandate, but is enabling and coordinating. EEPG should provide proposals and recommendations.
  • The structure for the EEPG inside RIPE is dependant on the outcome of the RIPE restructuring.
  • RIPE and EEPG could be viewed as independent bodies, although a back-to-back meeting schedule is imminent in the case that RIPE and EEPG are viewed separate.
  • EEPG could however start with RIPE. As soon as there are conflicts it could be reconsidered.
  • Both RIPE and EEPG will deal with Internet Services provision, which boils down to layers 1 to 3. Layer 7 coordination is done in Europe by groups as RARE WG-ISUS and others.
  • It is emphasized that the following aspects should be reflected in the ToR of the EEPG: EEPG will deal with "Internet Services".
  • Since EEPG has a close relationship with IEPG EEPG could move things faster on a global scale, if needed.

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:

  • Mbone coordination - should be a working group, since this is an ongoing coordination effort
  • NIC and NOC issues coordination.
  • Distributed Internet Exchange Facility. relevant topics:

Swedish Routing Lab

PRIDE (making tools)
D-GIX testing tools

  • Statistical framework
  • Proposals for DNS optimization
  • GIX liaison with the pilot
  • GIX framework spec

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:

  • Stockton, CA
  • Stockholm
  • Paris

The question is who will do what in the D-GIX:

  • D-GIX will do the software
  • PRIDE will do the data base stuff

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:

  • DANTE is the networking organization, based in Cambridge, UK.
  • EuropaNET is the IP service of DANTE, partly using EMPB, partly using Cisco routers at the EuropaNET PoPs.
  • EMPB is the pan-European network service managed by Unisource Business Networks.

The DANTE Routing Plan covers three time periods:

  • before 1 January 1994
  • after 1 January 1994 and before 1 July 1994
  • after 1 July 1994

The situation before 1 January 1994:

  • EuropaNET is EMPB plus two RBSses (located in Amsterdam and London) to Ebone (AS1128 and AS1129 are the interconnections)
  • Number of regionals using both EuropaNET and Ebone: SURFnet, SWITCH, JANET, BELNET and RedIRIS

The situation after 1 January 1994 and before 1 July 1994:

Amsterdam:

  • 512 kbit/s gateway line upgrade to 2 Mbit/s
  • 2 Mbit/s Amsterdam-Washington
  • SURFnet no longer an Ebone partner

London:

  • No connection between EMPB and Ebone any more (AS1129 deleted)
  • JANET no longer an Ebone partner
  • 1 Mbit/s London-Washington no an Ebone resource any more

Geneva:

  • 1.5 Mbit/s Geneva-Washington is DANTE (EuropaNET) resource
  • SWITCH no longer Ebone partner
  • 1 Mbit/s between Geneva and EMPB (for CERN usage)

The situation after 1 July 1994 (aka the future) is not clear, open issues are:

  • D-GIX project and other plans
  • resilient EuropaNET trans-Atlantic connectivity
  • resilient EuropaNET inter-Europe connectivity

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 backbone.

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:

  • Currently: 1 policy per AS; Variations = Communities
  • Colours: small variations within one AS; hints for CIDR aggregation; avoid network based lists

Implementation: Path attribute (BGP); local to an AS; associated with communities. This new idea was discussed, and a series of clarifications were made:

  • There is some kind of overlap between colours and communities, but a colour is local to an AS, and the colour information is set at the source of the network announcement, and not in the receiver of this route (network based lists based on communities).
  • Someone using colours for routing should trust the remote AS for colouring his networks properly when they leave its AS.
  • One can use both mechanisms (colours and communities) to express routing policies. It is therefore proposed to extent Ripe-81 so that it can support:
    • as-in: AS1234 10 COM1, where COM1 is a community.
    • It is proposed to limit the number of colours to 16 per AS, since it is the number of bits used in the BGP path attribute today.

It was observed that the latest draft of BGP4 dropped the BGP path attribute. The attendees of the coming IETF from RIPE should propose to restore it.

  • A network can be marked with several colours.

13.5.8. 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.9. 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.10. Inter-AS Local Information, discussion

This extension, as well as the action attached to it (Peter Lothberg), was dropped.

13.5.11. 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:

  • CIDR and Aggregation should become a high priority of the group

BGP4/IDPR follow on

  • The group should avoid, as much as possible, overlapping interest with other RIPE working groups, especially with the Database working group and the EEPG.

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.cisco.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:

  • AN - Netherlands Antilles
  • AZ - Azerbaijan
  • LB - Lebanon
  • MA - Morocco
  • MK - Macedonia
  • ML - Mali
  • NC - New Caledonia

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:

  • gopher nis.garr.it
  • wais nis.garr.it

13.7.2. User Services update

Joyce Reynolds gave an update on what is new in the following groups:

  • IETF User Services Area.
  • RARE ISUS working group
  • EARN Earninfo group

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:

  • scope of RIPE must be redefined
  • the scope of the working groups must be redefined
  • the status of RIPE as a player in the Internet spectrum
  • the work areas with respect to users and providers must be redefined.
  • how to progress the above points

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.