[eix-wg] RIPE 46 EIX minutes - full
- Date: Tue, 20 Apr 2004 16:10:59 +0200
Greetings
Here are the final minutes from the RIPE 46 meeting - we are still waiting
for one presentation but we propose to approve these minutes at the RIPE48
meeting next month.
Thanks
Fearghas
RIPE 46 EIX WG minutes - Wednesday, 5 September 2003
Chaired by: Mike Hughes mike@localhost, WG Co-Chair
Scribe: Carsten Schiefner carsten@localhost
Location: St. Johns II
Attendees: 108
Abstract
========
Trends to be seen were:
- steady growth
- GE or even 10 GE deployed more and more, FE not even available any
longer at some IXPs
- IPv6 widely deployed
- the larger IXP tend to have multiple locations
- ongoing evaluation of IXPs' current setup and exploration of future
possibilities => no stand-still
- some IXPs also host ccTLD secondaries
- one IXP consortium also pursues social exchange to foster the
co-operation and collaboration with Eastern European IXPs and ISPs
There was a brief discussion re. the issue of IPv6 address space not
being allowed to be globally advertised by the respective policy.
Demand was expressed to alingn and harmonise the policy with both, the
other RIRs and existing IPv4 policies. Furthermore, it was suggeted to
continue this discussion on the mailing list.
2nd session (after lunch) covered the following presentations:
- an update on Euro-IX, the IXP association. Euro-IX intends to support
the developement of Quagga with some funds, Quagga is the successor
of Zebra, a route server. Also, Euro-IX is about to deploy a peering
matrix that will easily give acces to information on which AS is
present where.
- on the Inter-Provider Traffic Analyzer. This tool uses past data and
statistical calculations to detect anomalies in traffic patterns.
Useful to become aware of short term glitches, the tool operates on
the physical layer.
- the anycast deployments of the F, I and K root servers by Netnod, ISC,
and the RIPE NCC, respectively. The slightly different strategies were
explained which were felt as a strength. However, it was also felt
that some coordination would be useful to prevent deployment only at
places that have an excellent coverage already anyways.
- a brief reminder of the global IXP database maintained by Packet
Clearing House and its need to get updates to remain uptodate. It was
explicitly mentioned that it also carries "gossip" and not only
verified information.
The last agenda item covered input/output with the Address Policy and
the NCC Services WGs which there was none of.
1st session: 11:00 - 12:30
==========================
Audio archive:
mms://webcast.ripe.net/ripe46/eix-1a.wma
A. Administrative stuff
- apologies from Fearghas McKay, WG Chair
- agenda approved as proposed:
http://www.ripe.net/ripe/meetings/ripe-46/agendas/eix.html
B. IXP presentations
- Trends to be seen in the presentations from eleven European IXPs
were:
* steady growth
* GE or even 10 GE deployed more and more, FE not even available
any longer at some IXPs
* IPv6 widely deployed
* the larger IXP tend to have multiple locations
* ongoing evaluation of IXPs' current setup and exploration of
future possibilities => no stand-still
* some IXPs also host ccTLD secondaries
* one IXP consortium also pursues social exchange to foster the
co-operation and collaboration with Eastern European IXPs and
ISPs
- Netnod, .se - by Kurt Erik Lindqvist:
http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-eix-netnod.pdf
* update on Netnod and its activities
* update on technical equipment available at the respective sites
* update on (planned) developments in both, administrative and
technical areas
* update on statistics and traffic patterns
* there were no questions from the audience, one observation
though: use IP phones to contact not just Netnod, but also
other IXPs and providers
- AMS-IX, .nl - by Henk Steenman:
http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-eix-amsix.pdf
* overview of facts and figures
* overview of the three main VLAN services: Peering, GRX and MDX
* other services are VLANs for Closed User Groups and for Private
Interconnect, furthermore the hosting of secondary ccTLD servers
* overview of the current infrastructure and a typical traffic
pattern during a week
* progress:
+ renumbering all connections from a /24 to /23
+ migration to a next generation platform, replacing the current
circle architecture by a star based one. This will provide
better scalability and stability and allow to offer trunked
x * 1 GE and 10 GE connections
+ overview of the new topology
* next AMS-IX tech meeting to be held in the morning of 24
September, the general meeting in the afternoon, including the
election of new board members
? Will the two switches be in the same building?
! No, they will be in different buildings, about 25 km apart.
- INEX, .ie - by Brian Boyle:
http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-eix-inex.pdf
* overview of facts and figures:
+ modeled on LINX
* INEX services are IP switching and a framework to facilitate
peering and transit, furthermore statistics
* INEX news are a new GM, Barry Rhodes, IPv6-readiness, GE enabled,
and a new tariff system
* the statistics show a steady growth annd considerably less
traffic during weekends
* overview of the different types of charges and the organisation
itself
? When was IPv6 started?
! No detailed information, but earlier this year.
- TELEHOUSE/CERN (NYIIX/LAIIX/CIXP), .us & .ch - by Akio Sugeno &
Paolo Moroni:
http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-eix-cern.pdf
* overview of NYIIX and LAIIX facts and figures
* f.root-servers.net instances deployed recently at both locations
* second NYIIX site in operation since July 2003
* customers tend to privately peer via NYIIX as L2 transport became
recently considerably cheaper than in-building peering
* customers join NYIIX via EoMPLS from very remote places
* overview of CIXP facts, figures and recent operational issues
* inter-site VLAN services and access to an NTP server are
available to CIXP members, IPv6 is about to be deployed
* no link or relationship to Zurich based Telehouse Internet
Exchange (TIX)
? Were there any operational issues at NYIIX associated with the
recent power outage in the north-east of the US?
! No - NYIIX runs back-up generators.
? Is there any concern by the building management running the
in-building peering facilities that customers actually use a
competitor?
! No information.
- N-IX, .de - by Kurt Kayser:
http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-eix-nix.pdf
* overview of facts and figures:
+ only GE ports offered
+ private VLANs recommended, e.g. to deliver on SLAs
* overview of fees, eight carriers in house
* 2nd location in planning
* summary
+ medium sized regional exchange
+ no membership
+ extremly low costs
+ maximum performance
* no issues with n-ix.cz because of name clash
* there were no questions from the audience
- ECIX, .de - by Jan Czmok:
* ECIX formerly known as Berlin Internet Exchange
* name change necessary to accomodate some changes
* ECIX is active in Berlin and Dusseldorf, both location are up and
running and ready for peering
* member of IKO
* aim is to provide local exchange for ISPs
* ECIX members sum up to currently five, more to come
* IPv4 and v6 ready
* FE and GE, SX or LX, available
* more information available on the website at:
http://www.ecix.de/
* IKO stands for "Internet-Knoten Osteuropa". It is meant to build
social networks amongst and with individuals from carriers
operating in eastern European countries, in particular those
accessing the European Union
* IKO was founded in 2003 and currently has twelve members
* main office in Berlin, branch office in Wroclaw
* more information available on the website at:
http://www.iko-ev.org/
? What is a social network?
! Intent is to create awareness amongst ISPs and carriers in regard
to cooperation across borders; currently most of the traffic from
eastern European countries is seen to be routed via Scandinavia
on one or two routes. Alternative and additional peeerings are
about to be deployed in collaboration with people working at
carriers and IXPs. Aim is a more diverse structure.
? What are the associated costs and fees for IKO?
! [by Stefan Wahl] Currently being set, will not be a threshold.
Basically meant to cover costs occuring from meetings etc. Check
the website.
? Are the two exchange locations connected in some sense or the
other?
! No, they are complete separate. Berlin is focussed on eastern
Europe, when Dusseldorf is ment to be a local/regional exchange.
- MIX, .it - by Valeria Rossi:
http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-eix-mix.pdf
* overview of facts and figures
* fully operational IPv6 test bed since May 2003, dedicated VLAN
for four testing members
* Routing Information Service and Test Traffic Measurement to be
installed in September 2003
* MIX will also host an instance of i.root-servers.net
* other services currently deployed are an NTP service, the Traffic
Analyser (see separate presentation), a Member Statistics History
and Multicast
* there were no questions from the audience
- Xchangepoint, .uk - by Keith Mitchell:
http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-eix-wg-update.pdf
* overview of facts and figures:
+ European expansion funding secured
+ new CEO: Richard Almeida
+ LoNAP interconnect extended
* expansion to Netherlands and Germany initially, decision where
to go live first (Amsterdam or Frankfurt) to be expected soon
* feedback on preferred cities or sites welcome
* overview of locations (current and planned) and customer base,
growth and services they use
* Xchangepoint will not connect cities!
* overview of the interconnect with LoNAP:
+ to date only point-to-point private VLANs
+ 12 XchangePoint customers and 8 LoNAP members participating:
total 29 VLANs
* presentation slotted in for the 2nd session on the new European
Union telco regulation that came into force in July 2003:
postponed to RIPE 47 as it is quite a bit of reading regarding
access and dominant market position etc. IXPs will probably not
be exempted. However, commenting would be too premature at this
very moment
* there were no questions from the audience
[chairmanship passed on to Christian Panigl]
- LINX, .uk - by Mike Hughes:
http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-eix-linx.pdf
* overview of facts and figures
* overview of next year's pricing scheme:
+ increased weight towards traffic, lesss weight on mere ports
+ membership and joining fees be reduced by 25%
* other developments include:
+ electronic voting by the LINX members
+ members' request to deploy optional(!) multi-lateral route
reflectors
+ the possibility to deploy BENTO
* enabling anycast for i.root-servers.net (LINX hosts its first and
so far only instance) went smooth
* secondarying ccTLDs such as .at. and be
* there were no questions from the audience
[chairmanship taken back from Christian Panigl]
- NIX, .cz - by Josef Chomyn:
http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-eix-nixcz.pdf
* overview of facts, figures and conditions, e.g. the difference
between members (legal entities in the Czech Republic) and
customers (others)
* outline of the 2004 fee structure
* outline of the Cisco-based infrastructure
* IPv6-ready. NIX wants to have public servers, e.g. a web server,
on the IPv6 network - according to the current policy this is not
possible as IXP /48s should not be publically annnounced
* developments include a traffic analyser as a result of a diploma
thesis (suprising results, revealed a lot of unwanted traffic
caused by misconfigurations on the members' side and the
replacement of Linux-based routers with Cisco for NIX' own AS and
infrastructure
? (Bill Woodcock) IPv6 space allocated to IXPs should not be
announced to anywhere else on the Internet. Current efforts to
harmonise policies across the four RIRs - APNIC recently removed
this requirement. What is the feeling of the audience about it?
! (Keith Mitchell) Policies should be harmonised. However, to his
understanding the current RIPE policy is not prohibitive, but
merely states that global routability is not ensured.
! (Lars-Johan Liman) Announcing an IXP's network can create quite
complicated error situations, policy should follow operational
issues.
! (Arien Vijn) Ditto, issues were to solved at AMS-IX only´
yesterday resulting from a global announcement.
! (Keith Mitchell) Should be up to the IXP operator to decide,
rather than to the registry. Also it would seem to be logical to
have a similar IPv4 policy, too. Harmonisation seems to be
necessary.
! (Mike Hughes) Ditto - tell your customers to defend themselves
against more specific routes.
! (Bernard Tuy) No more specific prefixes than /32s should be
announced - so the /48s of IXPs just can't be announced according
to the policy.
! (Mike Hughes) /32 rule is assignment policy that doesn't say
anything about announcements. Do not mix up policy and
operational issues!
? (Ruediger Volk) Are the servers supposed to sit on the peering
network or is a separate network envisaged? If former is pursued:
better keep out of it!
! (Josef Chomyn) Servers migrated from various ISPs to IXP location
one by one. With IPv4 there is no problem: a /24 for the peering
mesh, another /24 for the servers acting as a customer towards
the IXP. This just not possible with IPv6. What to do?
! (Mike Hughes) This appears to be an address policy issue that
may need to be reviewed. Discussion should continue on the
mailing list if needed.
! (Henk Steenman) Take addresses from more than one connected ISPs
and assign multiple addresses to each server. AMS-IX did so and
can provide a document outlining this.
2nd session: 14:00 - 15:30
==========================
Audio archive:
mms://webcast.ripe.net/ripe46/eix-2a.wma
- LoNAP, .uk - by James Rice:
* LoNAP established in 1998, now in three premises
* 100 Mbit and 1 Gbit connections available
* switching fabric is Cisco based
* several VLANs defined, such as for IPv4 multicast
* fee structure on a per-year basis, includes ports an VLANs
* one-off joining fee, includes the cabling etc.
* LoNAP has 42 members at the moment, slightly increasing
* multicast fabric collapsed into a VLAN
* IPv6: three members peering with the route collector at the
moment, on the same peering fabric in a separate VLAN
* point-to-point private VLANs with Xchangepoint to be expanded to
IPv6 as well
* there were no questions from the audience
- Euro-IX - by Serge Radovcic:
http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-eix-euroix.pdf
* about Euro-IX itself: aims etc.
* overview of facts and figures
* IXPs to join Euro-IX: contact Serge or Christian Panigl
* the database on the website lists more than 1,300 IXP peers now
* an IXP peering matrix is about to be deployed soon that will
easily give acces to information on which AS is present where
* information on the switches being used by member IXPs to be found
on the members-only pages
* Fearghas McKay represented Euro-IX at the 2nd Latin American
Regional NAP meeting in Buenos Aires, Argentina
+ some Latin American NAPs expressed interest in visiting
European IXPs
* announcement of the 3rd Euro-IX Forum on 3rd and 4th of November
in Lisbon, Portugal
* Euro-IX' General Meeting to be held in conjunction with the Forum
+ three board seats becoming vacant to be filled
! (Christian Panigl) Euro-IX intends to support the developement of
Quagga with some funds, Quagga is the successor of Zebra, a route
server
- Inter-Providers Traffic Analyzer - by Matheo Labanti:
http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-eix-mix-analyzer.pdf
* a tool that uses past data and statistical calculations to
detect anomalies and failures in traffic patterns
* Useful to become aware of short term glitches
* the tool operates on the physical layer
* brief overview of the components and how they work together; full
blown presentation to be given during Euro-IX Forum in November
* examples were shown
* there were no questions from the audience
- Anycasting f.root-servers.net - by Joao Damas:
http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-dn-f-root.pdf
* it is about improving DNS infrastructure and user experience, but
not about competition
* technical setup explained in detail at:
http://www.isc.org/tn/isc-tn-2003-1.txt
* distinction between 'global nodes' (no restrictions on BGP
announcements) and 'local nodes' (“no-export” community), the
latter preferrably to be installed at IXPs. Reason is that (D)DoS
attacks often do not affect su much the box itself, but the
bandwidth of a particular ISP. This setup ensures that even if
one ISP goes down, the others still get the service
* explanation of the general deployment scheme: black box principle
connected to the IXP with several servers inside, one of them
acting only as a monitoring and control box with OOB accces from
a Management Transit Provider to the consoles of the servers
* all nodes announce f's /24 and AS; additionally they have a
second /24 and AS each, provided by the Management Transit
Provider, to access them separately
* two global nodes in San Francisco and Palo Alto with OSPF load
balancing
* various local ones on all five continents already deployed, more
to come
* there were no questions from the audience
- Anycasting i.root-servers.net - by Kurt Erik Lindqvist:
http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-eix-rootserver.pdf
* i is operated by Autonomica, a 100% subsidiary of Netnod
* again, anycast deployment is no race to outcompete other root
server operators
* plan 20 have 20 - 25 instances for i within a year
* two strategies: operated by Netnod itself with own equipment, but
also in cooperation with Packet Clearing House
* two types of nodes: at IXPs and with ISPs, focus is on IXPs. ISPs
would be large Tier 1 providers
* site should provide about eight units rack space, power and
hands-on-site; preferrably also a prefix and some bandwidth from
the local host to manage the node
* no “no-export” communities, up to the peers to decide about their
announcement strategies. pros and cons for this, though
* Netnod provides the hardware, but decided not to publish the
detailed technical setup
* plans to provide anycast for any TLD out of this infrastructure
* short desription of where instances are currently deployed and
what is planned for the near future
? (Henk Steenman) Criterias to pick a loctaion?
! No real criteria, traffic flow analysis could be one. However, it
turned out to be almost impossible for Netnod to do. So major
"Internet impact" sites are a pick, but also where a local
community will benefit from the deployment
? (Christian Panigl) One reason for anycasting is to catch (D)DoS
attacks. Woudn't it make sense to have instances close to where
these attacks mainly originate from?
! That is why Netnod goes to large IXPs and Tier 1 providers to
pick up the traffaic as early - or close to the source,
respectively - as possible. Another incentive to go to places
with higher RTTs
? Financial aspects?
! No investment by the local host neede, all is paid for by Netnod,
except for costs such as rack space, power or transit
- Anycasting k.root-servers.net - by Andrei Robachevsky:
http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-eix-k-anycast.pdf
* two instances deployed at LINX and AMS-IX
* cluster of two servers with NSD and a sniffer box
* global reachability
* funded by the RIPE NCC, AMS-IX provides 1G port
* objectives are the improvement of access to k, the impact
isolation of an “external” (D)DoS attack and the impact
localisation of a “local” one
* locations likely to be IXPs, hosted and fully funded by a neutral
party with an open peering policy
* operations exclusively performed by the RIPE NCC
* single box solution, capable of handling six times the average
load, with DNS server, router and sniffer
* also here, next to the service network (local, but also global if
coordinated) there is a management network
* announcement of a more in-depth discussion later this day and a
next day's presentation on technical setup and experience gained
? (Keith Mitchell) Own AS per instance?
! Own AS for k, regardless the instance.
? (Rob Blokzijl) Coordination amongst the operators? All tend to go
to large IXPs: does that create complications?
! Actually not. One of the goals is to mitigate (D)DoS attacks, so
an attack only on k will not harm i - even in the same location.
Also, the models are different.
! (Rob Blokzijl) Differences in approach are a strength, also
deployment for local communities.
! (Kurt Erik Lindqvist) Some level of coodination. However, only
three present here, but more actually doing anycast.
! (Rob Blokzijl) Good development, also for political reasons:
makes it impossible to hijack or take dwon the root.
! (Lars-Johan Leman) Some overlap is good, but not a total overlap.
The own interests of the IXPs would prevent this anyways by
balancing it out.
! (Keith Mitchell) Coordination could be organised by ICANN's
RSSAC, also off-line security should be considered.
! (Lars-Johan Leman) RSSAC has been incapable to give advise, that
is why the operatorts themselves do it.
! (Andrei Robachevsky) IXPs to ccordinate location of two instances
themselves, considering the type of service they host.
? How much for a k instance and how many are planned?
! (Andrei Robachevsky) In the order of EUR 5,000 per box, some 15,
maybe even 20 planned. Global reachability as a requirement will
come at a later stage, then probably at net topologically
aequidistant locations.
! (Joao Damas) Aequidistance might be a problem.
- IXP database - by Bill Woodcock:
http://www.pch.net/resources/data/exchange-points/
* Packet Clearing House mainatines and publishes an EXCEL
spreadsheet covering all IXPs around the planet
* regularly updated, request to send in updates
* carries also gossip, not only hard facts as it is sometimes hard
to find out about an IXP
* there were no questions from the audience
- No exchange with either Address Policy WG or NCC Services WG.
- No AOB.
End of RIPE 46 EIX WG meeting.
|
you are here: RIPE -> RIPE Maillists > Archives
