Routing wg draft minutes - RIPE 49

Hello,

I am hereby posting a revised version of the *draft* minutes for the  
routing wg meeting at RIPE 49 last week.

Many thanks go to the scribe, Henk Uijterwaal, of the RIPE NCC for a  
good and quick job.

Comments are welcome,
Joao Damas/(co)Chair routing-wg
ISC

Routing WG (Session 1)
======================

1. Introduction/Joao Damas (16:00-16:03).
    ------------
    Joao opens the meeting and deals with the administrative stuff. Henk
    Uijterwaal is appointed as scribe, the minutes from RIPE48 are  
approved,
    the agenda is approved.   The group has no outstanding actions.  Joao
    shows a slide with the dates of the upcoming IRR courses by the RIPE
    NCC.  These dates will be published on the web shortly.

2. Securing a core network - discussion/Michael Behringer. (16:03-16:39)
    ------------------------------------
    Slides on the web at:

      
http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-routing- 
security-discussion.pdf

    Christian Panigl briefly summarised part 2 of Michael Behringer's  
talk
    from morning EOF session.  In the morning, Michael Behringer  
presented
    some ideas to secure the core network, keeping operability in mind:

     - Transit ACL's
     - Use RFC1918 address space and no export (users cannot see the  
core and
       thus not attack it).
     - Use of a non IP-Control plane

    The chair then opened the floor for lively discussion:

    * Daniel Karrenberg: if you are protecting the core, make it  
transparent,
      the end user then sees it as 1 IP hop.  The user should never see
      RFC1918 space. Also be consistent, that will save a lot of work.
    * Joao Damas: Wild idea: use a v6 block for your IX.
    * Randy Bush:  What end user want is good service, does not want to  
run
      traceroute. End user needs to debug both paths.  Opaque blob is not
      going to let anybody debug it.
    * Michael Behringer:  This is an old discussion.  Traceroute -g and  
source
      route were considered bad too, LG's solved the problem.  While he  
agrees
      with Randy Bush' points, why not invent other tools?
    * Randy Bush: does not see benefit in using RFC1918 space to make  
core
      invisible. This hides the fact that it is an IP network, it is  
going to
      get you in trouble sooner or later. IP network should be open.
    * Daniel Karrenberg and Iljitsch van Beijnum agree with Randy Bush.
    * Pedro Marques states that you cannot prevent people from accessing  
your
      core routers without making things invisible.
    * Michael Behringer wants to see the discussion on an abstract level.
    * Pedro Marques: if you have daily DDoS attacks, filtering for  
network
      might be a good idea, not a choice, even if it breaks other things.
      Host-by-host protection does not work.
    * van Beijnum: hiding the core and making the core inaccessible  
aren't the
      same thing. The latter can be good.  If you hide the core,  
debugging
      will be the same as debugging ethernet segments.  Not funny.
    * Randy Bush DDoS problem of distributed source and target. Needs to  
be
      solved near the edge and source of DDoS.  Refers to work by  
Bellovin et
      al on push-back
    * David Reader: try traceroute to 213.249.249.129.  Lots of 1918  
space,
      his customer cannot see the site, operator of 10/8 can.  The core
      doesn't see the problem, their neighbours do.
    * Michael Behringer asked what if you get proper addresses back.   
Randy:
      now you know who to contact and what's wrong.
    * Pedro Marques: one can set-up things such that traceroute works,  
but ping
      doesn't.

    Michael concluded with: there are different views, no agreement on  
pros
    and cons. He plans to write this up and give the document away.   
People
    can then decide for themselves what to do.

3. IRR toolset handover/Shane Kerr (16:39-16:46)
    --------------------
    Slides on the web at:

http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-routing- 
irrtoolset-handover.pdf

    Shane explained that the RIPE NCC took over maintenance of the  
RAToolset
    from ISI in 2001.  The current release contains fixes to all issues  
raised
    at RIPE49 and compiles under gcc 3.x.x.

    The maintenance of this toolset does not fit with the current  
software
    model at the RIPE NCC.  The RIPE NCC has therefor agreed with ISC to  
move
    maintenance to them.   The RIPE NCC has handed over the code and all
    documentation to ISC.  The mailing list will be moved soon.

    Question from the floor:
     Randy Bush asks what licensing model will be used by ISC.  Joao  
Damas
     responds that the current license is the BSD license and that will  
not
     be changed.

4. BGP Wedgies/Tim Griffin (16:39-17:07)
    -----------

    Slides on the web at www.cambridge.intel-research.net/~tgriffin

    Tim introduced the concept of a BGP wedgie. A 3/4-wedgie is a  
situation
    where local routing policies make sense locally but interactions  
allow
    for multiple stable routes.  A full wedgie is a situation where no  
set
    of operators can find out why a set of policies result in an  
unexpected
    route.   Some examples were shown. Operators should be aware of this.
    An IETF draft (in the GROW-WG) is available.

    Comments:
    Geoff Huston: This would be easier if "depref me" was a transit
       property.  Should it be?
    Tim: if we want this to work: yes.

    Pedro Marques: one way to fix it is to get eBGP to advertise best  
route
       and best route that does not come from peer I'm talking to. (2nd  
best
       route).  This is in an old RFC.  Juniper can support this.
    Tim: this makes it easier, but does not solve general case.

    Bill Norton: what tools do you have to figure out the current
      situation, what tools would be useful?
    Tim: needs common analysis by multiple AS, not a trivial thing to  
set up.

    Daniel Karrenberg: can this be avoided with pre-pending?
    Tim: no, folks prefer customers, it will not work.

5. Measurements on intra domain routing instability/Zhang Shu  
(17:07-17:24)
    ------------------------------------------------
    Slides on the web at:

     
http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-routing- 
instability-measurements.pdf

    Zhang showed statistics on intra domain routing changes in the WIDE
    network.  Oscillations are often caused by:

      Congestion
      Link/IF failure
      Misconfiguration
      S/W bugs

    He then presented the RTANALY tool, a system to detect and visualise  
IGP
    changes.  Release early October:  
http://rtanaly.koganei.wide.ad.jp/rtanaly
    An example was shown.

    Question from the floor: How do you get the data?
    Zhang: Record them with tcpdump.

Routing WG/Session 2
====================

6. BGP network design/Pedro Marques (11:00-11:50)
    ------------------
    Slides on the web at:

     
http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-routing- 
bgp-design.pdf

    This presentation will focused on a set of frequently asked questions
    that network operators have regarding the logical design of BGP  
networks.
    These include topics such as route reflector placement on a network  
and
    BGP configuration trade-offs.  More a set of topics to generate  
discussion
    based on discussion with potential customers.

    A. How much hierarchy
       Showed an example of a wrong design aimed at keeping traffic  
local.
       IBGP would have done the same. BGP for internal traffic is  
generally a
       bad idea, it was not designed for it.

    B. Where to place route reflectors?
       Goal: reduce routing information.
       Non-goals: configuration management, scaling #tcp sessions
       A lot of people use Route Reflectors as a configuration.  
management tool.
       Wrong tool for the job. Side effects of path selection are  
usually not
       understood. Should buy a provisioning system.

    Recommendations:
     - Keep it simple.  Lowest cost solution that solves the problem
     - Avoid loosing information in the core
     - Avoid centralisation

   Cold potato: MED and what are the consequences.

   The speaker then ran out of time and briefly went through a number of
   slides:

    C. Can BGP advertise more than 1 path?
       Yes, you can. Showed config example in slides
    D. Unadvertised JunOS behaviour changes:
        6.3 incoming interface check on eBGP session (drop packet from  
non
            peer)
        7.0 TCP path MTU discovery no eBGP poison reverse to neighbour as

   Question from the floor;
    Rudiger Volk: objects against the statement that BGP can advertise  
more
       than 1 path. It doesn't.  Prefix is the key.
    Pedro: 2547 augments the key to be a route discriminator plus  
prefix.  So
       effectively it does for a number of applications.
    A discussion follows, no conclusion is reached and the discussion is  
taken
       off-line.

   Randy Bush showed a case where mixing routers from two different  
vendors
    led to huge numbers of message and slow convergence, introducing a
    min.router advert showed slower convergence, less messages though,  
not
    seen on data plane

7. Happy packets/Randy Bush (11:50-12:04)
    -------------

    Slides on the web at:

     
http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-routing- 
happy.pdf

    Randy noticed that there have been numerous publications about the
    control-plane (routing) instability.  However, what matters is the
    quality and stability of the data plane: what counts is if the data
    reaches its destination.  A huge number of BGP updates is not a  
problem
    as long as the routers can process them without falling over.

    He did an experiment with a BGP beacon and sites all over the world
    sending data to it.

    One plot showed the effect of an link cut while keeping an  
alternative
    path up.  Packets continued to arrive from half the sources.  The  
other
    half experienced a 30 second drop, even though BGP updates continued  
to
    float around in the system much longer.

    More examples were shown, bottom line was there is no correlation  
between
    BGP activity and data not arriving.  On the IP level, some  
correlation
    can (arguably) be seen.

8. RIS status and plans/Matthew Williams (12:04-12:23)
    --------------------

    Slides on the web at:

     
http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-routing- 
ris.pdf

    Matthew gave an update of the RIS project at the RIPE NCC.  
Highlights are

    * The internal reorganisation announced at RIPE48 has been  
successfully
      completed.
    * A route collector is about to be installed in Moscow.  RRC08 has  
been
      moved from MAE-WEST to the PAIX.
    * myASn v1.0 has been released.  myASn is an alarm system for BGP
      available at http://www.ris.ripe.net/myasn.html.
    * The debogonising effort has been continued.  For the new RIPE NCC
      block 85/8, it showed that initially 80% of the sites filtered the
      block, this was reduced to 17% after a few days.
    * Ongoing efforts:
      - IPv6 support.  Some tools do support IPv6, others don't as the  
RIPE
        NCC ran out of time.  New ETA is late November.   Prototypes for
        unsupported tools are available at:
        http://www.ris.ripe.net/cgi-bin/ipv6/prefixquery.cgi
      - Looking at requirements for myASn v1.1 and 2.0.
      - Future IDR work
         - Secure routing
         - Collaborate with researchers
         - Your suggestion

9. Detecting anomalies/Olaf Maennel (12:23-12:37)
    -------------------

    Slides not yet on the web.

    Olaf presented research aimed at finding the offending AS when an  
anomaly
    in BGP is detected.  He uses 3 views: time, location and prefix.  The
    method then detects the AS that is causing the problem (in about 93%)
    of the cases.

    The algorithm has been validated using simulations, RIS/Routeviews
    data (1100 feeds), formal methods.  Olaf has also checked that the
    anomalies he detected are related to events seen in syslog files from
    real routes.

    Limitations of the method are the size of the candidate set.  It is  
also
    possible that the offending AS is outside the set of processed AS's.

    Further work includes developing a Topology aware library to identify
    clusters and adding this algorithm to BGP alarm systems like myASn.
    Collaborators are Gert Doering and the RIPE NCC.

10. AOB?
     ---
    No other business.