RIPE 50

• content to the Chair of the working group.
• format to webmaster@ripe.net.

RIPE Meeting 50 in Stockholm
Thursday 5 May 2005 - 09:00 - 10:45
Scribe: Rene Wilhelm

A. Administration

- Minutes of previous meeting approved
- No open action items on the group

B. RIS update - Andrei Robachevsky

- RRC13 at the Moscow-IX is online
- RRC08 moved to Palo Alto IX and was renamed RRC14 to avoid confusion.
- In total 13 remote route collectors with ~450 peers
- IPv6 search has been enabled on RIS tools
- Beacon experiment continues
- myASn is a success, 550 users

- Future work items:
o Improve RIS db performance
o Revisit myASn, consider user use cases, integrate into LIR portal

Question: have RIPE NCC thought about using certifcates for authentication, to list the rightfull owner
Andrei: we are looking at it, but no planning yet. First are routing security developments, see what happens there, then see what RIRs do

Geoff Huston: authentication of resources can have use by itself already, without waiting for routing security. Does the community think this is what RIPE NCC should be doing?

Assume RIPE NCC have member certificates, this public key matches that member; as the member has resources, the resources would become extention of the member. You would be saying: RIPE NCC have performed an allocation and that member is the current controller of the resources. When you next go to your upstream and say "please route", you sign with your key and the upstream can check you are the rightfull owner. RFC 3779 as an extension to existing member certificate

Andrei: we issue certificates to individuals representing members or to consultants. We cannot devote a lot of resources this year.

Gert Doering: usefull task for RIPE NCC to investigate how much work it is, how it can be implemented. It does not effect address policy that much, may need to transfer certificates, but that's mostly technical.

Joao: can I have a show of hands, how many are aware of what the discussion is about? [only a fraction of attendees raised their hand] Let's bring people who can explain certficates, what these are about, how they work. to the next RIPE Meeting (october 2005) and continue the discussion then.

C. Discussion of topics covered in Philip Smith' talks in the plenary

1. Route Flap Dampening: where to now?

http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-wed-flap-damping.pdf

- should RIPE-229 be declared obsolete? should it be modified?
- is flap damping bad for your network?
- needed at the internet edge (=ISPs not providing transit to any other AS) ?
- needed in the internet core?
Show of hands: how many folk are using vendor defaults, how many RIPE-229?

--> RIPE-229: most, vendor defaults: few, nothing at all: few

Ruediger Volk: a few years ago there was a problem which got solved by damping flapping routes; learning that measures taken can make things worse, we should evaluate if problem still exists. It might be useful to put put something in place to deal with excessive misbehaviour, but you don't want damping to happen in the typical transit provider.

Kurtis Lindqvist: flap damping applies to certain networks, certain parts of the world. Add warnings to the document when and when not to use it.

Christian Panigl: make it not a real recommendation, but a descriptive document, what damping is good for. Like Ruediger, don't want flap damping happening in the core. Flap damping is bad when it is too agressive.

Philip Smith: should we make seperate sections, recommendations to edge providers? recommendations to core providers? And be as descriptive as possible?

Iljitsch Van Beijnum (via Jabber): flap damping doesn't work against flapping customers!

Christian: it's working as long as BGP itself is stable; if routes behind the session are flapping it works fine. If bgp session itself is flapping you have different mechanisms to find out and obtain statistics.

Kurtis: don't put labels, just be as descriptive as possible, if your characteristics match these criteria, take those actions.

Ruediger: change the wording, flap damping is an option which has its use in certain places. Documents are now driving things that shouldn't be done.

Joao: should anything be done on the status of RIPE-229 now? We cannot change an existing RIPE Document, can only publish a new document and make old documents obsolete. Do we wait for next one to be ready before obsoleting the current one?

Ruediger: that depends on the timing, if it takes many years to come out with a new document obsolete RIPE-229 right now. If the new document will come out before the end of the year, leave it in place.

Christian: can we have volunteers to work with us until the next ripe meeting? [ ... no hands were raised ...] Let's obsolete it.
If there are no volunteers to work on it, flap damping is obviously not important enough. Obsolete RIPE-229 and have it in the history archives.

Joao: any comments on that?

Kurtis: obsoleting the document won't change the problem in the network

Joao: at least we would not have wrong information out there

Philip: let's see what we can do in the next few months, not everyone is here, let's decide in the October RIPE meeting.

2. Deaggration practices

http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-wed-aggregation.pdf

Proposal to introduce a routing-wg work item
Aim: document aggregation recommendations for isps

Gert Doering: those who participate in the discussion are not the ones leaking all the more specifics. How much good would it do to put out a document? Some folk do it on purpose, knowing it shouldn't be done, ISPs should talk to downstreams not to deaggregate; threaten to depeer if they do not aggregate, or not respond at all.

Geoff Huston: Community pressure, address policies no longer seem to work. Proxy aggregation doesn't work very well either; you are not sure if my specifics have leaked around you. Would be nice if market could regulate, currently there are no costs on the poluter.

Mike Hughes: LINX members voted the LINX as being a good place for community pressure.

Ruediger Volk: going for depeering is not the right level. Keep your own address space highly aggregated. Setup some kind of prefix length routing policy. Other people can point to it, if they are deaggrating don't be surprised if they have less than optimal connectivity because of deaggregation. Need some tools for getting info from the registries?

Geoff: the CIDR report is huge, has info for each AS how the announcements compare to allocations

Ruediger: have something that rules out /24 deaggration for space out of /20 or /19 allocations already helps

Joao: At this time, not much to be done. Pain is not high enough.

Geoff: when falling over a cliff, life is fine when falling.

D. Discussion about IPv6 BGP filtering BCP (Gert Doering)

What sort of BGP filers are usefull for IPv6?

http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-ipv6-bgp-filtering-bcp.pdf

Ruediger Volk: max prefixes is a crude heuristic, sometimes there are legitimate reasons for large number of prefixes.

Daniel Roesen via IRC: less-specifics don't hurt, only more-specifics can be harmful, so don't filter greater-or-equal. Many IPv6 players out there currently have no real concept of "upstream", "peer" and "downstream"

E. Active BGP probing. (Lorenzo Colitti, University of Roma Tre - RIPE NCC)

http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-routing-bgp-probing.pdf

Lorenzo presents the techniques he and his colleagues at Roma Tre University have developed to help ISPs find out how their prefixes could be announced in case of network faults and how other ASes treat their prefixes. Based on active BGP probing and announcing large AS-sets, these techniques have been successfully tested in the IPv6 Internet.

Because of time constraints (the session was already 15 minutes over time) Joao asks those with questions to approach Lorezno over coffee.