Draft minute routing @ RIPE 50

Here are the draft minutes for the routing working group meeting at  
RIPE 50, in May.

Many thanks to Rene Wilhelm of the RIPE NCC for the fine minutes.

Please review them, in particular points C1 and C2 which would  
require action from the group or at least an expression of opinions

Regards
Joao Damas
ISC

=============================
Minutes Routing WG at RIPE50
=============================

Thursday 5 May 2005, 09:00 - 10:45
Chair:   Joao Damas
Scribe:  Rene Wilhelm


A. Administrativia

    - 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 small 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 RIPE229 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?

    --> RIPE229: 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 while falling.


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

    What sort of BGP filers are usefull for IPv6?

    slides: 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 Lorenzo over coffee.

=============================