RIPE 28

Report of Meeting, 24th September 1997

A. Preliminaries

Joachim Schmitz opened the working group, introduced himself, passed the attenders' list around, and asked for a volunteer scribe. Julia Edwards volunteered as scribe. There were 75 participants in the session.

The working group agreed upon the minutes of the previous meeting, and accepted the draft agenda earlier circulated on the mailing list.

Review of actions RIPE 27

Action 26.R3: J. Schmitz - open.

To finalize the hierarchical authorization for route objects together with the Routing WG

Action 27.R1: Carol Orange, RIPE NCC - suggested to be closed.

To implement cross notification in the RR with modifications as agreed at the meeting of the 27th RIPE Routing WG.

Action 27.R2: Carol Orange, RIPE NCC - suggested to be closed.

To implement aut-num authorisation in the RR

Action 27.R3: RIPE NCC - closed.

To ask Tony Bates to send a copy of his regular CIDR report to the general RIPE mailing list as well.

Action 27.R4: Task Force (Tony Barber, Sean Doran, Daniel Karrenberg and Christian Panigl) - suggested to be closed.

To write proposal document and circulate to the RIPE Routing WG mailing list for discussion as soon as possible.

B. Current developments

A glance at IETF activities shows two important groups

RIDE - Registry Information Data Exchange

Chairs: David Kessens, Dhaval Shah
http://www.isi.edu/~davidk/ride

There have been 2 BOF sessions up to now, and it will become an IETF working group soon. Major objective of the group is how registries can exchange data from their databases.

RPS - Routing Policy Systems

Chairs: Daniel Karrenberg, Cengiz Allaettinoglu
http://www.ietf.org/html.charters/rps-charter.html

This is already a working group with considerable work being done. Major objective is a formalized and extensible description of routing policies on the Internet.

One of the results from the RPS working group is RPSL, the Routing Policy Specification Language. It goes far beyond the possibilities offered by RIPE-181, and it is planned to implement it at RIPE. To give the RIPE community an overview of the current situation and of planned activities a joint session of the Routing and DB working groups will be held this RIPE meeting.

RPSL Transition Session

Featuring issues around RPSL and its implementation
25 September 1997, 9:00am

C. Report from RIPE NCC (Carol Orange)

There are currently two important topics regarding routing issues the RIPE NCC is working on. On the one hand RPSL has a lot of attention where the RPSL Transition Session is meant to give an overview. Work on this field at the current stage consists of coordination for the most part, but in the near future database coding will be the most important item. On the other hand the notification schemes discussed with the Routing WG are currently implemented.

D. Authorisation/Notification with Route Objects in the RIPE DB

• Cross Notification (Carol Orange)

  Cross notification got approval to be implemented at the last RIPE meeting. Implementation has actually started but has not yet finished due to restricted manpower. Chris Fletcher has been working on it and cross notification will be available on the RIPE Test DB in October.

• Aut-num Authorization revisited (Joachim Schmitz)

  Joachim Schmitz again summarized several questions on aut-num authorization. Some of those had already been decided in a previous wg session but the discussion led to final consensus in all points. The results summarized are

  • If aut-num objects carry "mnt-route" attributes specifying maintainers, only those listed are allowed to add route objects of same origin
  • If no "mnt-route" attributes are present, anybody may add route objects of same origin
  • Independently from "mnt-route" attributes, maintainers of route objects may always delete them
  
  However, these rules at this time can only be enforced for one single registry. There is no mechanism in place which prevents someone to register the routes he wants with another registry if it does not work for the one he originally intended to use. This again triggered some discussion and the results are
  • aut-num authorization will not be delayed because of this issue
  • coordination among registries is vital
  
  The RIPE NCC was asked to approach the other registries to discuss this item.

  Action 28.R1: Carol Orange, RIPE NCC

  Contact other RR on the topic of distributed authorization

• Hierarchical Authorization revisited (Joachim Schmitz)

  The current state is that anybody may add route objects for any origin, except for control by aut-num authorization. A second hierarchy may be applied as well, based on IP prefixes like it exists for inetnum objects. This would mean that route objects of different origins for given IP address ranges could only be handled if properly authorized.

  However, authorization only makes sense if it is enforced. As a consequence, additional restrictions are imposed. The question now is whether these can be accepted.

  Cons:

  • Restrictions hinder current practice. Why should route objects be registered by anyone if the administrative effort is too high? Routers in real life do not depend on registration. Going this way leads to a weakened IRR.
  • Domains and IP address space (inetnum objects) are tied to ownership immediately calling for control. Yet, who "owns" routes?
  
  Pros:
  • Routing and filters may be built from registry data calling for a tighter control of route objects because invalid registry data directly impacts real world routing if router configs are generated from them.
  • Owning address space is worthless if it is not used. Usage is reflected in route objects making them important beyond mere technical operation.
  
  Unfortunately, even though there was some discussion on this topic, no real consensus was found. The general idea is that for the time being there is no demand to implement a hierarchical scheme based upon IP prefixes.

E. Route Flap Dampening (Christian Panigl)

Christian Panigl had sent out the paper from the task force on route flap dampening the week before. It had been read by many people. To summarize, he gave an overview of the current dampening parameters and recommendations

• never start dampening before the 4th flap in a row
• /24 will then be dampened for 1 hour
• /22 and /23 : max: 45 min and min: 30 min
• all else: max:30min, min: 10min
• exceptions: 'golden networks': root dns

He then added some related recommendations with regard to configurations of Cisco routers

• no ip bgp fast-external-fallover
• clear ip bgp soft

He had some feedback on this first version of the paper. He then asked on how to proceed, especially on the idea to present this as a RIPE document. Daniel Karrenberg offered his editorial help, after the feedback received was incorporated in the paper. As a RIPE document it will be an official RIPE recommendation, and as such may lead to further development, e.g. to place it as an informational RFC.

F. PAIR: Policy Ana lysis of Internet Routing (Jake Khuon)

PAIR consists of a series of web based tools to help understand and diagnose problems with IRR policy and announcements seen at the RSng Route Servers. It is built upon route servers, and users may see routing problems as they appear at the route servers.

Other tools exist which partly have the functionality of PAIR. However, PAIR is more and comprises various functions in one shell providing a simple and uniform interface.

Some of the functions include

• compare announced route AS origins to register route objects
• compare route announcements to registered routes
• suggest route aggregation

Routes are classified according to a color scheme

• green: registered in the IRR and announced
• red: registered but not announced
• grey: announced but not registered

Work has been in progress for 5 months now. Much of proposed functionality is not yet implemented but will be done in the near future. PAIR will be continuously developed. For further reference see

Homepage: http://www.rsng.net/pair/
RSCV: http://www.rsng.net/rs-views/

G. Reports from other WGs

There was no current input from other WGs.

H. AOB

Since there was no AOB the meeting was closed.

Agenda

- Routing Working Group Meeting -

Agenda for RIPE-28, September 1997, Amsterdam

A. Preliminaries (Joachim Schmitz)

• introduction
• participants' list
• volunteering of scribe
• agenda bashing
• RIPE 27 minutes
• actions from earlier meetings

B. Current Developments (Joachim Schmitz)

• ietf
• rpsl
• rpsl transition session

C. Report from the RIPE NCC (Daniel Karrenberg)

D. Authorisation/Notification with Route Objects

• implementations in database software (Carol Orange)
• aut-num authorisation revisited (Joachim Schmitz)
• hierarchical authorisation of route objects revisited (Joachim Schmitz)
• discussion

E. Route Flap Dampening Parameters (Christian Panigl)

• report from the task force
• the route flap dampening paper

F. PAIR - Overview and Introduction (Jake Khuon)

Y. General Input from Other WGs

Z. AOB

Summary of Actions

Action 26.R3: J. Schmitz

To finalize the hierarchical authorization for route objects together with the Routing WG

Action 27.R1: Carol Orange, RIPE NCC

To implement cross notification in the RR with modifications as agreed at the meeting of the 27th RIPE Routing WG.

Action 27.R2: Carol Orange, RIPE NCC

To implement aut-num authorisation in the RR

Action 27.R4: Task Force (Tony Barber, Sean Doran, Daniel Karrenberg and Christian Panigl).

To write up the results on route flap dampening in a RIPE document

Action 28.R1: Carol Orange, RIPE NCC

Contact other RR on the topic of distributed authorization

Julia Edwards, Joachim Schmitz
01/18/98