RIPE 40

R I P E  4 0   P R A G U E
Routing Working Group Session
3-October-2001 Minutes

Chair: Joao Luis Silva Damas (i p o Joachim Schmitz - JS395-RIPE)
Scribe: Matthew Williams
Participants: 88


A. Preliminaries

Joao introduced himself, welcomed us all to the meeting and then handed
out the participants' list. Matthew Williams from the RIPE-NCC volunteered
to take the minutes.

The agenda for this session and minutes from the previous meeting at RIPE39
were approved without further ado.

Action points from earlier meetings:

37.R1 on C.Panigl, P. Smith, D. Karrenberg, J. Schmitz
Updates to RIPE-210
-done-

The final draft document (v2.0) has been sent to the Routing-WG
mailing list.

37.R2 on RIS team, Henk Uijterwaal
Implement route flap analysis from RIS data
-ongoing-

39.R1 on J.Schmitz, D.Kessens
Initiate IPv6 IRR task force
-ongoing-

39.R2 on D.Karrenberg
Provide 'Golden Network' web page
-done-

The web page can be found at URL:
http://www.golden-networks.net/


B. Henk Uijterwaal: Routing Information Service, Status and Plans

Presentation available at URL:
http://www.ripe.net/ripencc/pub-services/np/Talks/0110_RIPE40

There have been some changes to the team. Three new staff members
have joined and one has left. Next year in February, a student focusing
on route flaps and/or black holes will also join the team. One of the new
functions, the Customer Liaison Engineer, will be responsible for
encouraging
more interaction between New Projects and users of its services. Two
mailing
lists, ris-ix@ripe.net and ris-users@ripe.net, have been created for this
purpose. Ris-ix will be used specifically for correspondence between
RIPE-NCC
and hosts of Route Collectors, while ris-users will be open to anyone
who uses
RIS or RIS' raw data.

Some links to research based on the RIS' data have been added to the
web site:
- Thomas Franchetti's Thesis, 'Internet Routing Analysis Provided by
the RIS Report', provides the most current technical description of the
RIS and RIS Report. It also includes some interesting practical examples
on RIS usage.
(URL: http://www.ripe.net/ris/analysis.html)

- Various plots and tables from RIPE-NCC and MAE-East data by Olaf
Mannel at the University of Saarbrucken.
(URL: http://www.net.uni-sb.de/~olafm)

- Dartmouth College/Renesys Inc's 'Global Routing Instabilities during
Code Red II and Nimda Worm Propagation'
(URL: http://www.renesys.com/projects/bgp_instability)

Currently, route collectors are present at:
- RIPE-NCC
- LINX, London
- SFINX, Paris
- AMS-IX, Amsterdam
- CIXP, Geneva
- VIX, Vienna
- NSPIXP2, Otemachi (Tokyo)

Total of 162 BGP sessions

The route collector in Tokyo, which has been deployed in collaboration with
APNIC, will provide the RIS with a view from a completely different angle.
There are further plans to install one or two more route collectors in
the US
for the same reason as mentioned above. The additional value of adding
more
boxes can be judged by studying the differences in BGP routing information
between different collectors.

There have been some improvements to the RIS since the last meeting.
It is now
possible to make queries either by AS or Prefix, which should be
clearer for the
user. The Zebra logs can now be downloaded from the web site and NTP
problems
with raw data are fixed. Two other services, ASInuse and the RIS report
have
been brought online. Immediate plans include improving the response
time of queries
and providing more FAQs and general documentation. In 2002, the RIS
team plan to
deploy additional route collectors, develop user training and implement
a graphical presentation of AS maps. The main research projects comprise
of studying route flapping, investing dark address space and
reconstructing
the Internet routing table from RIS' raw data.


C. Philip Smith: BGP Flaps

Slides available at URL:
http://www.ripe.net/ripe/meetings/archive/ripe-40/presentations/
routing-bgpflaps/

Philip Smith presented some interesting observations regarding BGP flaps
based on Geoff Huston's data at URL: http://www.telstra.net/ops/bgp/
bgp-upd-entries.html. The main focus of this study was the behavior of
different prefix sizes in today's Internet with regard to the dampening
values chosen in 1997 (RIPE-210).

Main observations when analyzing BGP updates of the last 14 days:
- Forwarding Information Base (FIB): 110k prefixes
- Average updates per hour: 713
- Average prefix size of updates: 23.05

BGP Updates per hour, sorted:
/24 - 449 updates
/23 - 51 updates
/22 - 45 updates
/19 - 41 updates
/20 - 39 updates
/16 - 35 updates
/21 - 29 updates

This means that 60% of all updates were caused by /24s. However, the route
dampening values after three flaps have remained unchanged in the update
to RIPE-210:
- /24s and longer prefixes, suppressed for 60 minutes
- /22s and /23s, suppressed for 45 minutes
- The rest are suppressed for 30 minutes

Mr Smith's preliminary conclusions were that /24s maybe should be
dampened more
aggressively and that values for /22s and /23s should be extended to
include /16s
and then the entire range from /19s to /23s. Dampening values for the rest
seem to be working satisfactory. Geoff Huston has only been collecting
data for the last couple of months,i.e. more research needs to be done.
There
will be another presentation at the next RIPE meeting.

Q: Why are /24s flapping so much?
Q: Where are the /8 flaps coming from?
A: Currently, questions like where and who cannot be answered. More
research
needs to be done before the next meeting.


D. Philip Smith: Multi-homing Document

Presentation available at URL:
http://www.ripe.net/ripe/meetings/archive/ripe-40/presentations/
routing-multihoming/

Kurt Keyser, Abha Ahuja, Joachim Schmitz and Philip Smith intend
on authoring a document for LIRs on multihoming with some
advise regarding common situations. Progress is slow at the moment.
An update will be presented at the next RIPE meeting.

Q: Is there a draft available for scrutiny?
A: Not yet, but feedback from the WG is very welcome.


E. Florent Parent: IPv6 Routing Policies using RPSL

Presentation available at URL:
http://www.ripe.net/ripe/meetings/archive/ripe-40/presentations/
ipv6-routing-rpsl-ripe40.pdf

Florent Parent gave us an update on RPSL and IPv6. At this time,
the specification for RPSL (RFC2622) does not cover
IPv6 usage for routing policies. However, there is support for
the new version of IP in RPSL. Immediate tasks will be
documenting IPv6 usage in current classes and defining new attributes
where required.

The current classes used in the 6Bone whois database are ipv6-site
and inet6num. They are both defined in an IETF draft, which can be
downloaded from: http://whois.6bone.net/~david/6bone/draft-ietf-ngtrans-
6bone-registry-xx.txt. Mr Parent went on to discuss the
implications of IPv6 routing policies when using current RPSL classes.
There is much work to be done. The next steps will be to form a task force
focusing on IPv6 RPSL, sending the current IETF draft to the mailing list
for scrutiny and adding support in RAtoolset for the new IP version.
Those interested in participating in the task force should contact
Mr Parent (email:Florent.Parent@viagenie.qc.ca).

Q: What is the name of the mailing list?
A: The chair mentioned that it is hosted by RIPE-NCC as
rpslng@ripe.net (majordomo).


F. Roger Gottsponer: How to secure your job: Implement MPLS VPNs

Presentation available at URL:
http://www.ripe.net/ripe/meetings/archive/ripe-40/presentations/
mpls-routing-ripe40/

Mr Gottsponer from Nextra in Switzerland shared with us lessons they
had learnt when implementing and running a real life MPLS/VPN network.
This presentation was instigated by the MPLS tutorial at RIPE39 and
the fact that Nextra has been running a national MPLS-VPN network for 2.5
years. The international network has been in place since one year back.

Their experiences are that MPLS provides one with lots of interesting
features, such as new customer services (VPNs) and money-saving
opportunities
through traffic engineering, but it does also make operations more
problematic. Another downside is the fact that some features may not be
'VPN-aware', i. e. NAT, firewalls. However, most problems are not
related to
technology.

Mr Gottsponer went on to talk about general concepts and the actual
deployment of MPLS/VPNs. He did mention some interesting observations
regarding using traceroute on a MPLS network and considerations when
securing your Provider Edge (PE) routers.

The problem with traceroute is that it will send an ICMP packet with a
TTL of 0 to the second router in the Label Switch Path (LSP) between the
two PE routers. Because the second router only looks at the layer 2
header, the packet will be sent all the way to the PE router at the other
end of the LSP before the ICMP TIME_EXCEEDED response is sent back to the
transmitting station. One will therefore see observe strange latencies
when
using a non-mpls-aware traceroute utility.

The second issue dealt with securing PE routers against unsolicited telnet
requests. Mr Gottsponer's main recommendations were:
- Only use host routes for network management stations
- Point host routes to null interfaces in each of the customers'
Virtual Routing Forwarding Tables (VRFs)
- Filter routing updates from customers. Do not accept all internal
address ranges.
- Use loopback addresses and IP extended access-lists on PE routers

There were no questions after the presentation.


Y. Input from other WGs

IPv6 WG:
As mentioned previously, interested parties are welcome to join the
IPv6 RPSL
task force by sending an email to: Florent.Parent@viagenie.qc.ca


Z. AOB

none


Summary of Open Action Points from the Routing WG

37.R2 on RIS team, Henk Uijterwaal
Implement route flap analysis from RIS data
-ongoing-

39.R1 on J.Schmitz, D.Kessens, F.Parent
Initiate IPv6 IRR task force
-ongoing-

40.R1 on Kurt Keyser, Abha Ahuja, Joachim Schmitz and Philip Smith
Creating a 'Multihoming Document' for LIRs
-new-


Joao Luis Silva Damas, Joachim Schmitz, Matthew Williams, October 2001