You're viewing an archived page. It is no longer being updated.
RIPE 51
RIPE Meeting: |
51 |
Working Group: |
Routing |
Status: |
Draft |
Revision Number: |
1 |
- content to the Chair of the working group.
- format to [email protected].
Draft Minutes Routing WG at RIPE51
==================================
Thursday 11 October 2005, 14:00 - 15:30
Chair: Joao Damas
Scribe: Rene Wilhelm
A. Preliminaries (Joao Damas)
-----------------------------
- Minutes from RIPE50 routing-wg
These were approved, are now final
- Chairing of the group
Joao explained the chair and co-chair of the group agreed to switch
roles: because Joachim Schmitz often cannot make it to RIPE meetings,
they felt the group was better chaired by Joao, with Joachim providing
input in a role of co-chair. For the same reason, Joao now asks for a
second co-chair, someone who could chair the sessions at a RIPE
meeting in case Joao cannot attend (e.g. due to illness). Those
interested should talk to Joao; the new co-chair will be appointed at
the next ripe meeting.
B. Discussion on on route flap damp(en)ing - Philip Smith
----------------------------------------------------------
http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51-bgp-flap-damping.pdf
Regularly people ask about the status of RIPE 229: is there and
update? are the recommendations still valid? At the same time others
contact the authors stating the document has lost its validity, route
flap damping not being useful, counterproductive.
Philip presented the issue at RIPE50 in Stockholm, but no conclusion
was reached in the discussion that followed. So the discussion
continues here, with more people attending the meeting in Amsterdam.
- Should RIPE229 be declared obsolete? should it be modified?
- Is flap damping bad for your network?
- Is it needed at the Internet edge ?
(i.e. ISPs not providing transit to any other AS)
- Is it needed in the Internet core?
Questions/comments:
Geoff Huston: we did flap damping for the wrong reasons. we thought
edges were flapping for reasons not related to the BGP protocol, but
now we find the protocol is one of the main reasons for routes to flap
in the Internet. Flap damping doesn't work. Option 1, obsolete, is
what most people do.
Flap damping is actual harmful. not only causes you problems but elsewhere too.
If you reopen the work, ask why major vendors have different defaults.
Patrick Gilmore seconds Geoff, option 1 is much much better. From
what he has seen in the past flamp damping is more harmful, routers
with damping enabled died first in times of crisis. Is there any
reason whatsover not to declare it obsolete?
Philip: ISPs at the edge use it for stability
Geoff: If you have a prefix from two paths and one path is flapping
why wouldn't the other do the same? generally, dynamic noise in
updates depends number of peers and granularity; if you have multiple
path same prefix, would it not be a rare occurance for one to be
stable and the other not? More likely, both flap at same time.
Kurt Kaiser: combine flap damping with max prefix?
Joao notes that no one is speaking up for keeping it on as a work
item. However, he feels that just declaring RIPE 229 obsolete is not
enough; it should be accompanied by a small document which explains
why, in general, flap damping should no longer be applied and
describes the exceptions, if any, where flap damping might still be
useful. Geoff Huston and Philip Smith agree to look into this.
C. RIS update. Arife Vural, RIPE NCC.
-------------------------------------
http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51-ris-update.pdf
Arife presented an update of the status of the Routing Information
Service.
Interest in raw data is increasing, with a stable number of unique
visitors Looking Glass, ASinuse and BGPlay are most popular utitilies.
The IPv6 version of RISreport is now online
(http://www.ris.ripe.net/risreport/ipv6/)
Worked on improving RIS performance, changes to RIS infrastructure are
being prepared and will come online in a couple of weeks. This will
provide faster database replication, less time lag between receiving
BGP update and seeing it in the database. Also will allow to have more
data in the RIS DB, upto 1 year.
Joao: You are adding more and more collectors. How many are enough?
Arife: we have some offers, idea to put one in South America.
Henk Uijterwaal: we were appraoched at last RIPE meeting by LACNIC,
this week heard they have equipment, we can install when we like.
Shane Kerr: we are not sure when to say we have enough; plan to come
up with a measure to see how well covered. Not sure what users need,
time lag, history. We know people get raw data but don't know what
people do with it. If you use the RIS, come talk to us, we'd love to
hear what you're doing.
D. Route Aggregation Best Practice - Mike Hughes
---------------------------------------------------
Action as result of what happened in the LINX50 meeting in August
LINX used to have a rule regarding aggregation, "members shall
aggregate" but this rule was never actively enforced. LINX council
created a draft route aggregation policy which was discussed at
LINX50.
Member response: LINX must not interfere in routing, not adopt and
enforce a policy for route aggregation, but we do want to the right
thing. New rule: "members are encouraged to aggregate" It was
suggested to bring the draft policy to the RIPE routing-wg, where
perhaps it could be converted into a BCP document.
Opinions?
Gert Doering: I see lots of deaggregated garbage from peers; when
asked they reply "this is coming from my customer, can't control it",
but they could if they wanted to. Might be nice to have a BCP, but
unless there's some force it will not have any effect whatsoever. No
peer or depeer pressure that will work. depeering only felt if done by
a big provider, but those have other reasons than technical to
peer/depeer.
Patrick Gilmore: I'm also pessimistic, but ISP to ISP could work, a
BCP might help there.
Ruediger Volk: nothing new to add, trying to convince people to do the
right thing without a paper is not going to help. A BCP will help a
bit, but is no guarantee.
Geoff Huston: since 2002, the fraction of more specific prefixes in
the routing table is stable around 50%, but the amount of addresses is
growing from 15% to 18%.
Mike Hughes: people already said there must be some place to start
Joao will evaluate the feasibility of a BCP on route aggregation with
some volunteers, including Mike Hughes and Philip Smith.
Z. AOB
------
no other business.