- eix-wg - mailman.ripe.net

NAMEREGISTRY.COM - NICS.NET - DOMAINAMES.COM
by BucklesBW＠aol.com 10 Jun '01

10 Jun '01

DOMAIN PRICE 2000nic.net $1,000 800nic.net $1,500 888nic.net $1,500 abbreviaziones.com $3,500 abreger.com $3,000 abreviacao.com $4,500 abreviacao.net n/a abreviacao.org n/a abreviacaos.com $4,500 abreviacaos.net n/a abreviacaos.org n/a abreviacion.com $3,500 abreviaciones.com $4,000 abreviaciones.net n/a abreviar.com $3,000 abreviatura.com $4,000 abreviatura.net n/a abreviaturas.net $3,500 acronimo.net $3,500 acronyme.com $4,000 acronyme.net n/a acronymes.com $4,000 acronymes.net n/a addressmaster.com $3,500 addressregistry.com $12,000 aenic.com $1,500 afix.org $2,000 afrix.com $2,000 ahix.net $2,000 apix.org $2,500 ap-nic.net $2,000 arpanic.com $4,000 arpanic.net n/a arpanic.org n/a artsnic.com $2,500 artsnic.net n/a auix.com $3,000 auix.org n/a autonic.com $4,000 autonic.net n/a aznic.net $1,500 bankdirectory.com $10,000 banknic.net $3,000 bbnic.org $1,500 bdix.net $2,000 bdnic.org $1,500 bhnic.net $2,000 bhnic.org n/a bnnic.com $2,000 bnnic.org n/a boatnic.net $1,500 bonic.org $1,500 brnic.org $1,500 bynic.org $1,500 bznic.net $1,500 carnic.net $3,000 cctld.net $10,000 cctlds.com $15,000 cctlds.net n/a cfpnic.net $2,250 chironic.net $1,750 classifiedchannel.com $10,000 cnix.org $3,500 country-code.com $3,500 country-code.net n/a countrycode.net $4,000 countrycode.org n/a country-codes.com $3,000 countrycodes.net $4,000 countrycodes.org n/a cpanic.net $2,500 cparegistry.com $8,000 cunic.com $2,000 cunic.org n/a cyberegistry.com $5,000 cyberlocation.com $5,000 cybersecurity.com $15,000 cyberswamp.net $5,000 ddsnic.org $1,500 decimals.net $2,500 decimals.org n/a deix.net $2,000 digidomains.com $8,000 diginames.com $4,000 digitaladdress.com $5,000 digitalocation.com $5,000 digitalregistry.com $9,000 digitalwords.com $2,000 dknic.com $1,500 domainame.org $9,500 domainames.com $25,000 domainames.net n/a domainlogic.com $10,000 domainpower.com $13,000 domainshoppe.com $8,000 dznic.org $1,500 ecnic.com $3,500 ecnic.net n/a edunic.com $4,000 edunic.net n/a edunic.org n/a egnic.net $2,000 egnic.org n/a equations.net $4,000 equations.org n/a eurnic.com $3,500 eurnic.org n/a firmnic.com $2,000 firmnic.net n/a fjix.com $2,500 fjix.net n/a fjnic.com $1,500 fmnic.com $2,500 fxnic.com $1,500 gdix.net $2,000 gdnic.com $2,000 gdnic.net n/a grnic.com $1,500 gtnic.net $1,500 gzix.com $2,500 gzix.net n/a gznic.net $2,000 gznic.org n/a hbnic.com $2,500 hbnic.net n/a hbnic.org n/a healthnic.net $2,500 healthregistry.com $4,000 hillarygate.com $4,000 hlthnic.net $1,500 idix.org $2,000 ilix.net $2,000 ilnic.com $2,000 ilnic.net n/a indns.com $4,000 innic.com $4,500 innic.org n/a internetlocation.com $7,000 internetregistry.com $15,000 iprotocol.net $3,500 iqnic.net $1,750 irnic.net $2,000 irnic.org n/a iso3166.com $3,000 iso3166.net n/a iso3166code.com n/a iso-3166code.com n/a iso3166code.net n/a iso3166codes.com n/a iso-3166codes.com n/a iso3166codes.net n/a iso-3166codes.net n/a iso3166countrycode.com n/a iso-3166countrycode.com n/a iso3166countrycodes.com n/a iso-3166countrycodes.com n/a iso3166countrycodes.net n/a itldnic.net $1,500 itlds.com $13,000 itlds.net n/a iwords.net $4,000 jonic.net $1,500 jpix.org $2,000 kgnic.com $1,500 krix.org $2,000 kurzform.com $4,500 kurzform.net n/a kurzform.org n/a kwnic.com $2,500 kwnic.net n/a kwnic.org n/a laix.net $2,500 laix.org n/a lawnic.net $3,250 lawregistry.com $10,000 managedcare.org $10,000 mdnic.net $5,000 mednic.net $3,750 mednic.org n/a milnic.com $4,000 milnic.net n/a mindaddress.com $1,750 mnnic.com $1,500 moix.net $2,500 moix.org n/a movienic.org $1,500 myix.net $3,500 myix.org n/a name4sale.com $5,000 namechannel.com $6,000 namegiver.com $6,000 namehouse.com $4,000 namehut.com $6,000 namelogic.com $10,000 namemaster.com $10,000 nameregistry.com $18,000 namescape.com $10,000 nameservice.com $12,000 nameshoppe.com $6,000 namewarehouse.com $5,000 nanic.net $2,000 nanic.org n/a negatives.net $3,500 negatives.org n/a netlocation.com $10,000 newsnic.net $2,500 ngnic.net $1,500 nics.net $18,000 nlnic.com $2,000 ntlds.com $13,000 ntlds.net n/a numeral.net $3,000 numerals.net $3,000 numerals.org n/a numnic.com $1,750 numnic.net n/a orgnic.net $2,750 palabras.org $2,000 perfectdomains.com $10,000 perfectnames.com $6,000 perfectwords.com $2,000 phix.org $2,000 phnic.com $1,500 pknic.org $1,500 premierdomains.com $10,000 premiernames.com $6,000 premierwords.com $2,000 previewchannel.com $13,000 prnic.org $1,750 ptnic.net $1,500 qanic.com $1,750 qualitynames.com $6,000 qualitywords.com $2,000 recnic.org $2,000 ripe.org $6,000 ruix.com $3,000 ruix.net n/a ruix.org n/a runic.net $1,500 rxnic.com $2,750 rxnic.net n/a rxnic.org n/a sanic.org $1,500 sgix.net $3,500 sgix.org n/a shopnic.com $2,750 shopnic.net n/a siglas.net $4,000 siglas.org n/a storenic.com $2,750 storenic.net n/a strategicwords.com $2,000 superiordomains.com $10,000 superiornames.com $6,000 superiorwords.com $2,000 synic.net $1,500 thix.org $2,000 tjnic.com $2,000 tjnic.org n/a tmnic.com $3,000 tmnic.org n/a tpnic.org $1,500 trnic.org $1,500 tvdirectory.com $15,000 twnic.org $2,000 uanic.org $1,500 unnic.net $1,500 usadns.com $8,000 usadns.net n/a usaix.net $5,000 usaix.org n/a usanic.org $3,000 usanoc.com $4,000 usanoc.net n/a usnic.com $10,000 usnic.org n/a usnoc.net $4,000 uynic.com $1,500 uznic.com $1,500 venic.net $1,500 virtual-broker.com $8,000 vnix.net $2,500 vnix.org n/a vnnic.org $1,500 webword.net $5,000 wordbroker.com $2,000 wordirectory.com $4,000 wordlisting.com $3,000 wordlistings.com $3,000 wordshoppe.com $3,000 wordwarehouse.com $2,000 wordwizards.com $2,000 zaix.net $2,000 zanic.net $2,000 zanic.org n/a zjix.com $2,500 zjix.net n/a zjnic.com $2,500 zjnic.net n/a zjnic.org n/a zmnic.org $1,500 "N/A" indicates that the domain is part of a package. Contact: Brian Buckles 217-787-1701

1 0

IPv6 addresses for Exchange Points
by Mirjam Kuehne 15 May '01

15 May '01

[Apologies for multiple postings. I suggest to keep the discussion on <lir-wg(a)ripe.net> as it is related to address allocation policies]. Dear colleagues, At RIPE 39 last week in Bologna the issue of IPv6 address assignments to Internet Exchange Points was discussed (see also my mail from 24 April 2001 to these lists). There was consensus to assign a /64 to an isolated Exchange Point. It was further suggested to assign the agreed standard assignment size to a site (currently a /48) to a group of inter-connected Exchange Points. An Internet Exchange Point was defined as follows: 3 or more ASes and 3 or more separate entities attached to a LAN (the same infrastructure) for the purpose of peering and more are welcome to join. The RIPE NCC proposes to proceed with assignments for Exchange Points under the above policy. Kind Regards, Mirjam Kuehne RIPE NCC

2 1

Fwd: Re: IPv6 addresses for Exchange Points
by Fearghas McKay 09 May '01

09 May '01

--- begin forwarded text Delivered-To: lists-lir-wg-out(a)lists.ripe.net Date: Mon, 7 May 2001 17:51:56 +0200 From: Gert Doering <gert(a)space.net> To: Mirjam Kuehne <mir(a)ripe.net> Cc: lir-wg(a)ripe.net Subject: Re: IPv6 addresses for Exchange Points X-NCC-RegID: de.space Sender: owner-lir-wg(a)ripe.net Hi, On Mon, May 07, 2001 at 05:35:11PM +0200, Mirjam Kuehne wrote: > An Internet Exchange Point was defined as follows: > > 3 or more ASes and 3 or more separate entities attached to a LAN (the > same infrastructure) for the purpose of peering and more are welcome > to join. I suggest to change the wording to "a common layer 2 infrastructure" - an exchange point might be some distributed thing peering over an ATM/FR cloud or a SRP/DTP ring, which isn't really a "LAN". Policy should not be tied to special implementation techniques. Besides this, I like the proposal. As discussed with a few people after the WG, it *does* pose the risk of handing out "lots and lots" of /48s and /64s to people claiming to be an exchange point. (It's not that hard to get three ASes together over "some" medium). On the other hand: if we reserve a /35 for that, we have 2^13 /48's to hand out to "would-be IXes". So the danger of address wastage is not too big. The danger of routing deaggregation *is*... So I'd suggest another thing: add to this a big warning that this space is not "PI" (whatever that means) and that it is very likely that it will never be routeable world-wide. This should stop people wanting to use such space for something different than an exchange point from applying for it. Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster(a)Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 --- end forwarded text

1 0

Fwd: RE: IPv6 addresses for Exchange Points
by Fearghas McKay 09 May '01

09 May '01

The main discussion on this will happen on the LIR WG list - so I suggest people interested in IPV6 for IXPs should subscribe to LIR for the discussion. --- begin forwarded text Delivered-To: lists-lir-wg-out(a)lists.ripe.net From: paul.mylotte(a)bt.com To: lir-wg(a)ripe.net Subject: RE: IPv6 addresses for Exchange Points Date: Wed, 9 May 2001 17:00:44 +0100 Sender: owner-lir-wg(a)ripe.net At the RIPE 39 joint meeting it was clarified that we should cater for the support of both types of IPv6 exchanges, viz: * allocate addresses for IPv6 exchange infrastructure only (no onwards allocation in the manner of a backbone ISP). * allocate a sub TLA to the IPv6 exchange which will then act in the manner of an ISP and allocate downstream. In order to progress this, I would like to propose: * IPv6 exchanges that need addresses for the purpose of internal addressing can apply for the addresses already set aside for this purpose and held by IANA, as per RFC2928 and RFC2450. In this case a /48 allocation will be sufficient. (How IPv6 exchanges should apply for these addresses is out of scope - either direct to IANA, or IANA allocates down to RIRs first). * IPv6 exchanges that plan to onward allocate addresses in the manner of an ISP should apply via the existing mechanism. The existing mechanism is currently being reviewed and this review should take account of any changes necessary to include IPv6 exchanges explicitly desiring addresses for onward allocation as being acceptable candidates for address space. Regards, Paul P. S. Mylotte BTexact Technologies Adastral Park 01473 606333 / + 44 1473 606333 paul.mylotte(a)bt.com BTexact Technologies is a trademarkof British Telecommunications plc Registered office 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British Telecommunications plc which may be priveleged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the number or address above) immediately. > -----Original Message----- > From: Mirjam Kuehne [SMTP:mir@ripe.net] > Sent: 07 May 2001 16:35 > To: eix-wg(a)ripe.net > Cc: ipv6-wg(a)ripe.net; lir-wg(a)ripe.net > Subject: IPv6 addresses for Exchange Points > > > [Apologies for multiple postings. I suggest to keep the discussion on > <lir-wg(a)ripe.net> as it is related to address allocation policies]. > > > Dear colleagues, > > At RIPE 39 last week in Bologna the issue of IPv6 address assignments > to Internet Exchange Points was discussed (see also my mail from > 24 April 2001 to these lists). > > There was consensus to assign a /64 to an isolated Exchange Point. It > was further suggested to assign the agreed standard assignment size to > a site (currently a /48) to a group of inter-connected Exchange > Points. > > An Internet Exchange Point was defined as follows: > > 3 or more ASes and 3 or more separate entities attached to a LAN (the > same infrastructure) for the purpose of peering and more are welcome > to join. > > The RIPE NCC proposes to proceed with assignments for Exchange Points > under the above policy. > > Kind Regards, > Mirjam Kuehne > RIPE NCC > > --- end forwarded text

1 0

Euro-IX: Announcement and Invitation
by Christian Panigl, ACOnet/VIX/UniVie 09 May '01

09 May '01

Dear EIX-WG Member, dear Fellow IXP Operator, [... sorry for any duplicates ...] "Euro-IX" ( http://www.euro-ix.net/ ) was presented as a new initiative during the EIX-WG meeting at RIPE39 in Bologna last week. The slides of this presentation and further information can be found at http://www.euro-ix.net/newsevents/europresent.htm http://www.euro-ix.net/newsevents/index.htm If you are representing an Internet exchange point in Europe you are invited to join as a founder member of this association (in the course of formation) by signing a letter of intent (LOI) before 31.5.2001. Further details can be found at http://www.euro-ix.net/newmembership/index.htm A Euro-IX meeting has been scheduled for Monday, 21.5.2001, 11:00 - open end in Amsterdam aiming at drafting the Articles/Charter of the Euro-IX Association. All founder members having signed the LOI by that date are invited. Further comments on the Articles/Charter will be accepted from all founder members until 31.5.2001. After the Euro-IX presentation at RIPE39/EIX-WG we received various comments from Rob Blokzijl, Keith Mitchell, Andre Opperman and others which have been seriously considered by the initiating (charter) members of the group. We therefore want to clearly express the following statements which might be missing - at least in this clearness - in the press release and original presentation: Based on ongoing discussions at or close to various RIPE meetings a strong need was identified for co-operation between independent exchange point operators regarding technical, operational and administrative matters. Setting up an umbrella/membership organisation (association) for IXPs was after all the logical answer. In addition to the co-operative aspects a common Euro-IX web site/portal opens the opportunity to present key information about independent european Internet exchanges in a homogeneous way, facilitating the access for international ISPs who want to connect to more than one IXP in Europe. There is definitly no intention to replace the RIPE EIX working group, it's a complementary approach focussing on the needs of exchange point operators. Euro-IX and its affiliated IXPs will independently continue to give presentations to the RIPE/EIX-WG. Euro-IX will not impose any standards onto its members and is not claiming any power of representative authority on behalf of its members. Participation of all (not restricted to) european IXPs (for-profit and non-profit) is explicitly encouraged. Financial contribution (membership fees) will be used for ongoing maintenance of the portal and intranet web site, basic secretariat, research work (white papers, recommendations, ...) and intellectual IXP start-up support. All research/results/white papers produced by the association will be made freely available, with the exception of internal IXP operational issues. The initiating (charter) members are inviting all prospecting IXPs to join Euro-IX as founder members in signing a Letter of Intent (LOI) before 31.5.2001. The proposed charter/articles of the association, which will be established in The Netherlands (Amsterdam), will be circulated to all founder members (22.5.2001) for review with a deadline for comments (31.5.2001). All input will be considered and a final charter will be published shortly thereafter. All founder members having made comments and who could finally not agree with the published charter may then withdraw their membership within one week without beeing charged any membership fee. Joining the Euro-IX association is of course also possible at any later stage for any IXP. The first general assembly will take place either close to the Prague RIPE meeting (October 2001) or at latest close to the next Amsterdam RIPE meeting (January 2002). For that meeting all members are invited to suggest board members and to elect the board. In the meantime the function of the board is performed jointly by the initiating (charter) members, who may be contacted at: <board(a)euro-ix.net> or individually: Magnus Andersson, Netnod <magnus(a)netnod.se> Pascal Delmoitie, BNIX <pascal(a)belnet.be> Arnold Nipper, DE-CIX <arnold.nipper(a)de-cix.net> Christian Panigl, VIX <panigl(a)vix.at> Valeria Rossi, MIX <valeria.rossi(a)mix-it.net> John Souter, LINX <john(a)linx.net> Job Witteman, AMS-IX <job.witteman(a)ams-ix.net>

1 0

IXP Switch Wishlist Draft
by Mike Hughes 02 May '01

02 May '01

RIPE European Internet Exchange (EIX) Working Group Internet Exchange Point Switching "Wishlist" Mike Hughes <mike(a)linx.net> London Internet Exchange April 2001 ABSTRACT: --------- At the RIPE meeting held in Amsterdam in February 2000, a number of participants agreed that the group should produce a "wishlist" to guide equipment manufacturers when producing boxes aimed at the core switching market. Over the coming months, ideas were collected from the EIXP community to form the basis of this document. In Europe, most Internet Exchange Points use a shared switch fabric to which the participants connect. Organisations then arrange peering via bi-lateral peering agreements. It is not compulsory for all particpants to peer with every other participant (called multi-lateral peering). Once two participants agree to peer, they will set up BGP4 sessions between their routers connected to the Exhcange to exchange routes and traffic. In the majority of cases, the Exchange Point operator does not become involved in the routing of any traffic across the Exchange, they choose to leave this to the participants. For this reason, switched Ethernet has become one of the most common choices for Exchange Point media. The main reasons behind this are: * Cost effectiveness * Simplicity of setup * Can use standard CAT5 wiring - easy to implement and maintain * Interfaces available across a wide range of platforms With the growth of the Internet, more and more traffic is being routed to Internet Exchange points, and the importance of IXPs has grown in line with this, especially in Europe where private peering is less common than North America. The IXP operators feel that having the right tools and features implemented in the equipment they deploy will play an important part of scaling ethernet technology to meet the demands placed upon Exchange Points. This is an informational document to outline the various features which IXPs would like to see implemented in core Ethernet Switching products. SECURITY FEATURES: ------------------ a) Control of dynamic MAC learning ---------------------------------- Currently, switches are provided with two options, either statically configured or dynamically learned forwarding information. Exchange Points like to monitor and control how many MAC addresses are connected to a participant's port. The XP operator generally does not desire ad-hoc extensions connected to their network. The common way of managing this is to enforce a "router-only" or "limited MAC address" rule. This is currently controlled by statically configuring forwarding information, or not controlled, but policed by counting the number of MAC addresses learned on each port, and action taken against offenders. Static configuration of forwarding information is a somewhat inelegant option, as this increases configuration overhead, and decreases flexibility, especially in case of emergencies. We propose a configurable "maximum learning" limit, configurable on a per port basis. In this way, operators can configure participants ports according to their house rules, but retain the flexibility of dynamic learning. This feature would also have to include a "first in-last out" lockdown facility, to avoid forwarding information for valid addresses being overwritten by addresses in excess of the exchange's house rules. b) Disable acting on STP BPDU information ----------------------------------------- Many exchange operators currently deploy Spanning Tree Protocol (STP) in networks which contain redundant links/full meshing. There is however, a danger presented by STP information leaked from a participant's network. The participant may have connected a poorly configured switch/router product, and may be leaking their STP information into that of the exchange. We would wish to see a configurable option to allow STP information to be ignored, and filtered at the port, on a per port basis. c) Wire-speed ACL-type filtering based on L3 header info -------------------------------------------------------- The ability to look into the layer3 information of a packet, and selectively monitor, or filter, based on certain layer 3 criteria. d) ARP/Broadcast snooping and control ------------------------------------- Many exchange points insist on participants using IP addresses they have assigned by the exchange operator. It is desirable for the operator to be able to monitor/restrict "off-net" ARP. As Ethernet is a broadcast medium, broadcast storms have been known to bring exchanges to their knees, affecting the forwarding abilities of both the exchange's switches, and the participants' routers. Monitoring/rate limiting/control of Ethernet broadcast frames is desirable. Most exchanges also forbid the speaking of interior routing protocols across their peering network. Since these take the form of broadcase frames on ethernet, broadcast control would help monitor this type of incidence. e) Policy exception logging --------------------------- In the above paragraphs, we have asked for some policy-based tools. Operators need to know when these policies have been breached. Good logging of policy exceptions need to be implemented: * SNMP-trap * Configurable syslog (i.e. which syslog facility to write to) f) Access to management interfaces ---------------------------------- In the past, security of management interfaces on Ethernet switching products as often been lacking. CLI or web interfaces should support authentication using username/password pairs, to avoid the use of "password only" authentication which implies shared passwords. CLI interfaces should also support SSH access, using either username/password or secure key authentication. Web interfaces should be HTTPS/SSL enabled, to avoid passwords being passed in the clear over HTTP. Management interfaces should be able to perform authentication from an external source, such as TACACS, RADIUS or LDAP services, as well as providing locally held accounts (have to be retained for emergencies) All management interfaces, CLI, web and SNMP should be able to benefit from access-list control. The access lists should be able to support variable-length subnet masks. Ability to disable management interfaces on a per-VLAN basis. Many XP operators choose to configure a "management" VLAN, so that all management is done out-of-band of the core peering traffic. It is desirable to have the management interfaces to listen on the management networks only. g) Port mirroring ----------------- It is sometimes necessary to mirror participants' ports, either because a participant is suspected of some inappropriate activity, or to help obtain information to debug a problem. Not all exchange points have staff on site 24x7, and port mirroring may need to be remotely set up, without hands-on intervention on-site. The ability to allow any port to mirror any other port with a similar lower speed within the chassis would allow the operator to connect a traffic collector/analyser device to a monitoring port, and simply configure the switch to mirror a port as desired to monitoring port. SCALABILITY AND RESILIENCE -------------------------- a) Spanning Tree ---------------- Spanning Tree is currently the only dynamic solution available to operators of exchange points for dynamically managing redundant links in their architecture. There are a number of problems with Spanning Tree: * Slow convergence - especially in cases of root bridge re-election * Wasteful of reslilent/redundnant resources - redundnant links are switches off - no traffic sharing * Security concerns (highlighted above) As the routes collected at an Exchange Point can be routed all over the world, any routing instability can act like dropping a pebble in a pond, and will spread around the Internet. It's desirable to maintain stable routing sessions across Exchange Point LANs to minimise these routing flaps, because of load it places on routers, and the effects of route dampening penalties. We believe that being able to declare ports as "end-stations" should avoid them being counted in the STP calculation, enable these ports to start forwarding more rapidly, and speed overall STP convergence time. Rapid spanning tree (IEEE 802.1w) should be implemented (http://www.ieee802.org/1/pages/802.1w.html) b) Resilient Packet Ring - IEEE 802.17 -------------------------------------- This is a standards-based version of the technology currently used by Cisco called DPT (Dynamic Packet Transport). This consists of a counter- rotating ring-system, with spacial reuse and "ring wrapping" circuit protection. The Cisco version is currently implemented over SONET/SDH media, however, the standardised version is being designed to be more media agnostic, and the IEEE working group has already elected to provide support for Gigabit Ethernet and 10 Gigabit Ethernet. RPR shows promise of becoming an ideal backbone technology for use in a flat layer-2 network, such as an exchange point. It will allow for redundnant self-healing backbones, with optimal use of all interswitch capacity, without the need for STP. c) Trunking and Link-Aggregation -------------------------------- It's become increasingly common for exchange points to become multiple switch and multiple site based, and many need to deploy link aggregation to handle the volume of interswitch traffic, where it exceeds the maximum speed of a single link. Most equipment implements load-sharing using either round-robin or address-based algorithms. The address-based system generally employs a hash of source/destination MAC address. Address-based load-sharing may be preferable to minimise jitter. In exchange points, many pieces of equipment will have similar MAC addresses, especially the first and last bytes (corresponding to vendor and slot position on router). If the hash is only based on part of the address, this can result in poor efficiency of load-sharing. Load-sharing algorithms should consider the whole address when calculating the hash used. Load-sharing of broadcasts and multicast traffic should be implemented. Behaviours such as forwarding all broadcast/multicast traffic out of the "primary" port in a trunk have been observed when load-sharing using destination MAC addresses has been implemented. IEEE 803.3ad link-aggregation should be implemented. d) Multicast Control and Containment ------------------------------------ Most switches are configured with IGMP snooping for multicast control. However, in an exchange point, with only routers attched, there is no IGMP present, only PIM and MSDP, and all multicast packets are flooded out of all ports. An exchange point, however, is an ideal place for mutlicast peering to happen, inject the traffic once, and it comes out several times (as much as is needed, or in the current situation, as much as isn't needed!). Cisco developed RGMP (Router Group Management Protocol). This is a proprietary technology whereby the router can communicate to the switch which multicast groups it wishes to see. This is, however, a vendor specific feature, and a wide range of routing platforms and switching platforms are present at many exchange points - both in equipment used by the operator, and the participants. Therefore, this is not a workable solution for most exchange points, whose princples are often include "equal treatment" of participants. While it may not solve all potential issues with multicast peering, implementing PIM-SM snooping and pruning within the switches will achieve the traffic containment requirements. e) Intelligent Layer 2 Forwarding - MAC-SPF ------------------------------------------- The majority of ethernet switching products in use today are switch/router products and contain enough processing power and memory to handle sizeable routing tables. Exchange points which do not involve Multilateral peering currently need to provide a transparent layer-2 service to the participants, and Ethernet has been widely deployed to achieve this. In a bi-laterally peered XP, the XP cannot become involved in the layer- 3 routing decision process. There are a couple of reasons for this, but an overriding one is a matter of scalability. Every participant will have their own routing view. Involving the XP infrastructure in layer-3 routing decisions would need the XP to hold as many routing views as members (Yes, MPLS could be employed, how is not clear right now). With the growth in size of some exchange points, this has led to expansion to multiple sites and switches, and consequently a more complex topology. This has shown up the weaknesses in Spanning Tree. An option this group considers worth exploration is the development of a dynamic layer-2 routing protocol, to replace MAC learning and STP. A number of thoughts have been given to this, and the following ideas have been arrived at: * Retain dynamic MAC learning on "end-station" ports - added to forwarding database as usual * Replace dynamic learning on inter-switch links with a routing process - switches use some form of l2 neighbour discovery * Use existing OSPF algorithms and similar LSAs to manage the routing information This would need to interoperate between different switch vendors to allow for scalability and freedom. Currently, one issue is where and how to pursue this. It's unclear whether this should lie within the IEEE 802 LMSC or within the IETF. Many switch vendors like the sound of this idea, as it solves some problems being faced by service providers working in the MAN space, who need to provide transparent L2 transport services. However, they need to be convinced of demand and ensure interoperability. The IETF has in the past only been concerned with layer-3 and up, "IP- over-Foo". However, they are currently of the mindset that they do need do need to dig down and look at interaction between IP and the Foo it is transmitted over. This is one possible avenue for pursuing this further. f) MPLS ------- Another option for improving scalability and resilience is MPLS (Multi Protocol Label Switching). Currently, there is rather limited support for MPLS in switching products, mainly because customer demand is pushing vendors to implement this in their high-end router products first. Many high-end router products do not posess sufficient port- density for use in an IXP environment. MPLS may enable an exchange to run a layer-3 network internally, and use an existing IGP to route traffic internally, By using MPLS tags to pass the traffic between the peers on the edge of the IXP cloud, the IXP does not need to be aware of IP source and destination of the packets. PHYSICAL WISHES --------------- IXPs are high-uptime environments. The equipment used in an IXP needs to be able to satify this requirement, in terms of redundancy, and hot- swappable components. * Hot swap of management/switch fabric cards with instantaneous failover to any installed redundancy (not rebooting onto the "backup") * Full-redunancy of PSUs, and hot-swap (i.e. box should run on 50% of PSUs) * Rapid booting and card startup (after all, much functionality is implemented in the ASIC hardware) * GBIC-optics for flexibility, easy replacement, and maximised port utilisation (freedom to choose SX/LX, etc) ACKNOWLEDGEMENT AND THANKS -------------------------- Thanks are due to the "usual suspects" in the RIPE EIX Working Group, but specifically Christian Panigl, Keith Mitchell and Rick Payne, for their contributions to this document.

1 0

IPv6 addresses for Exchange Points
by Mirjam Kuehne 24 Apr '01

24 Apr '01

[Appologies for multiple postings. I suggest to keep the discussion on <lir-wg(a)ripe.net> as it is related to address allocation policies]. Dear colleagues, The RIPE NCC received a number of requests from Internet Exchange Points (IXPs) for IPv6 address space. While evaluating these requests, we realised that it is still not entirely clear what the role of an IXP is in the IPv6 world. We also noticed that the allocation criteria currently described in the 'Provisional IPv6 Assignment and Allocation Policy Document' (http://www.ripe.net/ripe/docs/ripe-196.html) do not necessarily apply to IXPs. Please find some more details regarding this issue below. We would like to discuss this with you at the upcoming RIPE Meeting in Bologna. For more information abut the schedule, please refer to the agenda of the EIX-WG and the LIR-WG: http://www.ripe.net/ripe/meetings/current/ripe-39/ Kind Regards, Mirjam Kuehne RIPE NCC ------------ PROBLEM STATEMENT: - IXPs need independent address space for their infrastructure to allow their members/customers to connect via native IPv6 - IXPs do not necessarily fulfill the current criteria: - they do not have 40 customers (in most cases IXPs do not assign address space to their members) - if IXPs are on the 6bone, they might not have a whole pTLA, but only connect to the 6bone via another ISP - they do not need a whole subTLA (a /64 or /48, depending on the case, might be enough) POSSIBLE SOLUTIONS: 1. view IXPs as a site and assign them a /48 (or /64) directly (equivalent to IPv4 PI space) 2. require IXPs to fulfill the criteria and allocate a subTLA: - either by requiring them to get 6bone experience first - or by applying the general allocation criteria and require to connect to 3 other subTLA holders OPEN ISSUES: - what about IXPs with multiple PoPs - technical criteria for exchange points

1 0

Draft RIPE 39 EIX Agenda
by Fearghas McKay 23 Apr '01

23 Apr '01

Greetings We are lined up for Tuesday afternoon, a move from our normal slot. Due to the number of presentations we will need to be agressive on timing for presentations. Any comments etc let me know. See you next week! Fearghas A. Administrative Matters - scribe - list of participants - agenda - minutes B. IXP presentations - 5-10 minutes including questions including: LINX AMSIX SFINX DECIX LoNAP Espanix NetnodIX CIX Xchange Point TIX VIX COFFEE C. Further IXP presentations, additional presentations welcome on the day. D. Multicast in IXPs - Christian Panigl E. Switching List Update - Mike Hughes F. Best Current Practice - Nic Lewis G. Arnold Nipper - a presentation on recent work in the European IXP community. H. 15 min Joint Session with IPv6 and LIR to discuss IPv6 allocations for IXPs I. AOCB --

1 0

EIX BCP document discussion
by Nic Lewis 27 Mar '01

27 Mar '01

Dear All, As agreed at RIPE38 EIX-WG, herewith a brief summary of the various documents, activities, suggestions etc that has evolved from the work carried out towards the EIX BCP project, for comment and discussion. I have (roughly) divided the summary into 3 areas, 'ISP focussed' - matters that I perceive as having use or value largely to the ISP community, (but without differentiation between what may be of use to ISPs already present at IXPs, and what may be of use to ISPs wishing to start building a presence at IXPs.), 'IXP focussed' - matters that I perceive as having use or value largely to the IXP operator community, and 'Other' - for miscellaneous stuff. This summary is not exhaustive, nor is the structure or way in which I have separated the subjects expected to be any more than a starting point, (there is substantial overlap between many of the subjects), but hopefully it will be a reasonable basis for further discussion and progress. An important note to make is that there are a number of related activities by other parties underway, some toward the same goals and some that may have influence on, or be influenced by, this work. To try and avoid duplication of effort, provide the widest scope for this work, and to give credit to the other parties, I have identified these where I am aware of them in parenthesised notes. Identification of further instances would be appreciated and any omissions are unintentional. 1 ISP focussed activities/documents ----------------------------------- 1.1 General Information: 1.1.1 Definition of an IXP (History - the original 4 'NAPs' etc?) 1.1.2 Directory of home pages (NB - B Manning 'ep.net') 1.1.3 Brief history of each IX (Relate to 1.1?) 1.1.4 Governance/Management models (Inc. affiliations with other bodies) 1.1.5 Central FAQ depository ISP focus - cf 2.1.2 below) 1.2 Procedures: 1.2.1 Membership requirements/criteria (NB - NL and other work underway) (Inc. any special legal or regulatory requirements) 1.2.2 Application processes/guides (NB - NL and other work underway) (Inc. timescale estimates, relates to location info below) 1.2.3 Co-location availability/cost indicators (Must be objective and non-preferential) 1.2.4 Central application service (possibly too ambitious?) 1.3 Current Status: 1.3.1 Costs of membership & services included (NB - NL and other work underway) 1.3.2 Membership(AS No) 'matrix' (NB - NL and other work underway) 1.3.3 Contact details, 'role' entry points (NB - NL and other work underway) 1.3.4 Locations (NB - some sensitivity here - input from operators required) 1.3.5 Access/support contacts, procedures (NB - staffed/sub-contracted etc) 1.3.6 Other services/value adds (EG Multicast, IPv6, NTP etc etc) 1.3.7 Mailing lists available, and their uses (CF 1.4.4) 1.3.8 Central peering contact list (NB - consider B Norton work) 1.4 Technical: 1.4.1 Architecture and available connection modes 1.4.2 Connection procedures, in-building (Inc. contact details of who can/will cable) 1.4.3 Connection procedures , WAN connection (carrier availability & cost indicators WRT other co-los) 1.4.4 Ticketing/trouble systems (CF 1.3.7) 1.4.5 '3D' peering matrix - AS v AS v IXP (NB - NL work underway) (CF RR consistency - Shane Kerr/Maldwyn Morris) 1.4.6 IX routing availability/mapping (CF Hermes - Andrea Carmignani/RIS - Henk Uijterwaal) 2. IXP focussed activities/documents ------------------------------------ 2.1 General Information: 2.1.1 Website translation services (NB - NL work underway) 2.1.2 Central FAQ depository (IX focus - cf 1.1.5 above) 2.1.3 Mechanism to update details in section 1) (use of XTML??) 2.1.4 Common look & feel (NB - many web sites already exhibit this to some extent) 2.1.5 'Statement of Intent' (to encourage new IXPs) 2.1.6 Common information presentation and reporting (are there standards that could be applied?) 2.2 Procedures: 2.2.1 Identification of common application requirements (NB - NL work underway) 2.2.2 Standardisation/simplification of application procedure 2.2.3 Central function to 'pre-screen' applicants (Subject to individual IX requirements) 2.3 Current Status: 2.3.1 Clearer cost indication 2.3.2 Standardised format for membership listings (auto populate IXP Current status above?) 2.3.3 Recommended or standardised email 'role entry points' 2.3.4 Extension of discussion/knowledge sharing WRT value adds 2.4 Technical 2.4.1 Shared technical knowledge base (Inc. known issues, fixes, vendor contact points etc) (CF - Mike Hughes wish list) 2.4.2 Mailing list cross posting facility? 2.4.3 IP Addressing information (NB - re-visit IXP object in RIPE Database, Antony Antony?) 2.4.4 Common trouble/ticketing system (For issues affecting multiple IXPs 3 Other considerations ---------------------- 3.1 Peering agreements (Can further work simplify things for ISPs?) 3.2 Co-lo activities in this area (Should we have more dialogue with co-lo companies as a group?) 3.3 Consider outside ripe region? (Would we/others benefit from extending the availability of this work?) (OK, so we're not likely to get MAE buy in any time soon.......) Conclusion I have not particularly tried to determine the nature of each subject, (ie is whether it is a BCP, FYI or something else) and would like the group's feedback on this, as well as the general content. No doubt some suggestions will be seen as precocious, it is hoped this will stimulate further discussion. Suggestions for additions to, or modification of, any of the above is welcome and anticipated. I would like to thank everyone from within the working group and wider RIPE community who has given me input and ideas towards this, and in particular the 'behind the scenes' support of two of my colleagues, Terry and Fredrik, whom I mention by name because they have done lots of research work towards this, but have not, as yet, been unleashed to wreak havoc in the WG. Yet. Regards, Nic

2 1

RIPE 37 - EIX-WG Minutes
by Fearghas McKay 24 Jan '01

24 Jan '01

Chair: Fearghas McKay Scribe: David Knight <dknight(a)ripe.net> Agenda: No changes to the proposed agenda Internet Exchange Reports: INEX: Internet Neutral Exchange Alex Fench (Via Networks) <afrench(a)via-net-works.com> Founded 96, operational 97 Founder members: eunet ireland heanet indigo telecom internet All members share operational tasks and nominate one board member, hence no operational staff ... 3 honorary staff. Chairman Mike Norris. Current Members: 11 Eligibility: isps only must have independent route to mae east must be rir member Fees: 635 eu joining 2857 eu annual (for 2000) Facilities: two racks in a colo two cisco switches, ups, generator, model is byob acces is digi leased lines, sdh, atm Traffic stats: avg 5.5 Mbps peak 18 Mbps Douling 11 months Prefixes 162 Upgrade planned: tender for a new facility in progress carrier class location extra space for new members and bigger / more kit all the usual stuf of any IX More info: www.inex.ie MoU App forms Tender docs ... for new facility INEX secretary: <dcurran(a)eircom.net> Questions: Switches ? cisco 29?? New Location ? members will meet the costs of moving to the new location AMSIX: Since ripe36: Increase in members from 90 to 101 Increase in routers 99 to 111 Peak traffic since ripe 36 1.6g to 2.4g Housing: sara and nikhef are full nikhef expanded by 80 cabinets by dec2000 will go to 2 new locations telecity 5000m2 global switch (they are building 31,000m2 facility by Q4 2000) In use: Foundry big iron, sara nikhef interconnected with 2 fibre pairs ordering 2 ig irons ... ipv6 ports deployd at normal rate, this will be provided as a regular service ... Port charges (unchanged): 10 500 eu p/m 100 850 eu p/m 1000 1200 eu p/m Questions: Who owns the fibre interconnects ? not amsix, amsix owns the kit which was donated amsix is the only manager of the switches rate is total summary of all isps who peer on the two switches they currently run a multicast test there is multicast mailing list, info on mcast tests on amsix site LINX: Mike Hughes <mike(a)linx.net> Network Architect Organisationl changes: Keith Mitchell has resigned Rolan Perry has been appointed as interim ceo Nick Lewis left, this sparked a reorganisation in eng at Linx Mike and Chris Fletcher become project leaders ... Frees chris and mike from support for work on large high impact projects allows progression for other team members more clearly defined job focus Traffic Levels: Recently broke the 3Gb barier Daily minimum is now over a gig www2.linx.net Rate is aggregate of all ports ... 8 switches are in service Reimplimentation of stats system ... mrtg could no longer cope Chris implemented rrdtool Graphs and pages done on the fly with cgi ... current members - 110 / 50% from UK ... member from most eu countries expansion sites: Expanding to 7 sites ... fibre is delaying things Local authority upset with amount of road dug up for fibre install London underground also in on the act, tubes sunk too close to the tunnels One site, redbus, live since feb IX europe lit an on test Guardian and interxion are almost ready, most linx kit is installed, just waiting for fibre Expanded into telehouse east building, equipped with foundry switches, this helps relieve a lot of stree on telehouse north which is very full First extreme black diamond I swith installed, very happy new technology: Scalability of a flat layer two exchange point - will it hit a barrier ? Threat of a lack of intelligence Effective handling of multicast Main strength is the simplicity However this strenght could in future become a weakness ... Looking at possibilities of usin wdm Looking into packet ring study group ... turn cisco dpt into an ieee standard supporting gE an 10gE physical transports grouper.ieee.org/groups/802/rprsg/ Projects: Seperate mcast infrastructure 17 members connected 4 or 5 actually mcasting now Steve walker <stevew(a)linx.net> organised a two day event in july, 40 attendees Workign with Cisco to develop a protool to contain mcast traffic in a layer 2 ennvironment Cisco havea loaned a catalyst 5500 Trying to get other vendors involved 90% of the kit connected to the exchange is cisco Mcast project expansion is planned They need to get people into using mcast, find that killer app Possiility of another mcast event in the future Working now with RIPE NCC on RIS project Route servers replaced by a RIS box www.ripe.net - ris site A Caida project to map the internet Caida skitter box installed, on the k-root lan Extreme switch at telecity replaced with a black diamond I Alcatel too low port density, foundry are smaller SFINX: Franck Simon - Tehnical Manager Locations: La Bourse existing 12eme second Aubervilliers newest Current status: Interconnection of second sfinx pop, suffered from bad delays due to faulty kit Links are gig, using WDM All architecture is based on cisco catalyst switces 4 switches, sfinx1 offers 10/100 others offer 1000 Managed service Hosted service only also offered Managed service is no longer offered but still provide for those who already have it aubervilliers - 50 cabinets 10 carriers 12eme 12 cabinets 3 carriers All the pops can be accesses 24/7 ... Transit not allowed and private peerings not allowed between isps on the sfinx Basic service comparable to standard ix service 2nd dns via peering with afnic Router reset can be done by sfinx staff on sfinx all isps bar one come with cisco routers New services: (only at the new pops) Stats Vlan service - possile for isps to dedicate bandwidth for speific peerings Route reflector to simplify peerings Route server, routing table chek an comparison with RIPE db NTP service IPv6 peering with renater Optional services: Extra 10/100 Gig Mcast Future: New pops will bring a big trafic increase, atm isp's ar not coming at capacity Manager sabine.jaume(a)renater.fr franck.simon(a)renater.fr Questions: Why don't you allow people to provide transit ? Want to remain a peering point If they see transit they have the right to disconect the isps involved Is the no private connect rule not contrary to IX ? People wanting to do this must do it outside the sfinx room so they might have to put in two set of kit They get a room in a colo, they povide the switch, they pay a colo operator to manage the service They bill on the physical size of the router, hence you must be in the sfinx room to peer, if you are already in the colo you must also put a seperate router in the sfinx room INXS: Intro: Is a neutral exchainge point Oldest ixp in germany Established in munich in 94 Operated by cable an wireless Open host policy - no restriction to carriers Isps may make inxs their pop in munic Requirement: Have AS num, be a LIR, must house a router at inxs, switches and lan not allowed, no oligation to peer Facilities: Standard 19" racks 4 units per member 4 units 500 DM / month Access control system Cisco catalysts are in use 6 racks now, 6 more reserved Support: 24/7 phone supprt Router reset on request Physical check of conections 24/7 access arrangeable Extended support by contract Contact: http://www.inxs.de Members area mail lists: tech-l(a)inxs.de org-l(a)inxs.de archive available on http://www.inxs.de Upstreams: cable and wireless ebone aucs - coming Carriers: colt dtag m-net lines termintate in carrier room Future services: Looking for a second switch No connect to exisiting, for independence No oligation to connect to second switch Multicast via dedicated switch by end of 2000 Out of band access Isdn dialin or telnet by end of oct 2000 Switch stats by end of oct 2000 Testing ipv6 until Jan next year Only beta ios available with ipv6 support During test phase no fees Aditional racks for ipv6 routers at inxs Only regular inxs members may take part Genereal: 32 members Inxs moved from old ECRC facilities Distributed peering point has been established Redundant gig links 22 members moved successfully 5 to be moved until 21 sep Information: www.inxs.de info(a)inxs.de Questions: They will set up an mcast mailing list Private interconnects are okay VIX: <cristian.panigl(a)univie.ac.at> Status: Individual peaks up to 90Mbps Stats worry them as they are where LINX was one year ago Perhaps this time ex year they will have the kind of traffic that linx has right now +3Gb Exchange is accessible only during ofice hours, outside office hours is best effort, no contracts available 2 outages in the last 4 years, one hour power outage, . one 2 hour switch failure Various line carriers availabe ... Near Future: Gig by q4 2000 1st vix extension at interxion, neutral colo, expected to come on line within q4 2000 Big problem is getting dark fibre in vienna for redundant multi gig trunk interconnect Improvement of service level, 24/7 service - improved redundancy Mcast environents will be driven by member interest and active participation - connections to a dedidcated fethernet hub, gets the feelin that the market is there now f mcast service. The national TV company wants to mcast Requirements: Have own AS Be a LIR Internationl connectiity independant of existing members, prefixes and peerings registered in the ripe db Charging: 10 euro p/m 10t 200 p/n 100bt charging model to be adapted, with new site ad gig Questions: Apparently catalyst 59 doesn't cope too well with mcast on an exchange point Currently 3 are taking part in mcast tests, 2 more are interested no public announcement of tests yet, working currently with internal partner, most people just want to watch for the time being, this will open up soon, when there is experience and time, it is not currently announced, nobody is excluded, special requests can join in We announce peers to other peers in the db, randy wants to announce customers not peers, peers miht be private, you dont announce peers to other peers, but you always announce customers to your peers, so why not have that documented, why ? Vix peering matrix is no longer maintained by vix, each customer can maintain their own bit They were offerin newsfeecds for their pri customers unis, etc, newsfeeds suck up too much bandwidth these days. Vix reduced the feed back to the groups of academic value As they cannot deliver a full feed anymore they do not offer newsfeeds at all now CERN CIXP: Paolo Maroni Exchange point for switzerland Colo'd with cern Non profit best effort basic fibre providers colt sig (electrical provide) mci worldom, sunrise, ... 30 isps now members The recent trend is for global isps, less local ones CERN and other research nets are connected Infrastructure: Cisco catalyst 4003, 5505 10/100/1000 port available - most isps use 100 Back to back links are allowed Extreme networks summit48 ordered Infrmal measurements show peaks between 100 - 200 Mb back to back traffic needs to be added to the global traffic Normal services of an IXP Best effort services: oob cables and lines 24/7 operations Equipment install on request Kit maintenance - card install etc, on request www site - including bgp list of contacts Infrastructure monitoring Isues: Staff unavailability Rack space - some requests have to be rejected Contact with isps - a more detailed install procedure would help Limited to cern until end of sep 2000 A new non exclusive partnership with telehouse suisse Distribute infrastructure (Gig links) already there Security in telehouse much better Allows large pops connected directly to cixp Development: New www site Split from cern external network Looking glass Mcast - some experiments on their own, so far only one request from a member, they want to get more confident with the technology before announcing it to the membership They would like to get better stats with mrtg, etc Content distro service, they are talking to people about hosting equipment Better coordination between cixp members Sec dns, ipv6 and a route server They have already ipv6 conectivity ... They have had one request for a route server ... Contact: <cixp.support(a)cern.ch> http://network.cern.ch/public/services/cixp/index.html Informal nature o the cixp seems to be working well right now ... -=-=-=--=-=-=- END OF REPORTS -=-=-=--=-=-=- BEST CURRENT PRACTICE: IXP-BCP Whats happenin ? Nick Lewis offered to edit the document Working for LINX then, during ripe36 Nick is now working for a commercial isp and does not envisage a conflict of interest, his current employer supports the internet community activity, he has done a lot of work analysing ixp's around europe and would like to share this knowledge with the community He is very keen to ontinue Does the group agree ? Yes His point of view having come from an IXP to an ISP is appreciated Rapid pace of technology will make this doc old quick -=-=-=-=-=-=-=- Suggestion to change the charter ... Suggestion from Keith - change in the wording of the new EIX Charter -=-=-=-=-=-=-=-=-= Presentaion from I-Point Holdings A Way forward for European IXP's - Annette Nabavi I-Point set up to enhance the inter-isp infrastructure in europe Through consolidation and expansion they hope to achieve this UK based holding compay, well backed by venture capital Operating companies in each ountry Want to work with all major exchange point where possible, will roll out across eu within 12 months They are not an isp, or a colo, or a telco, or an asp, or a trade association They will: Provide funding or growth Service and tehnology enhancements Consistency in all eu countries They beleive absolutely in neutrality Flexibility an fast response is vital skeleton staff model cannot last, they want to have a consistently well maintaind ix network throughout the EU Will work toward staff motivation and retention They want to ensure that service levels are maintained and inrcreased, evolution not revolution Neutrality is a key issue Will guarantee 3 independent colos in metro area No exclusive arrangements Similar approach across europe Management team includes: Annette Nabavi CEO Keith Mitchell CTO Richard Almeida Alex Bligh Advisory Committee made up of IXP / internet gurus: Rob Blokzijl among others .. Whats it all about: They want to aquire IXP's in the EU, if that is not possible they can look into setting up new indeendent IXP's .. They want to reassure that neutrality will continue ... They see benefits as funding for growth, one stop shopping service and techonology comes quicker, free of current governance model, minimum disruption to existing services. Main Venture Capitalists: Nexus Equities Nexus investments GMT Questions: Why the buyout model ? They believe its vital for customers to come directly to one company for services They will not provide conectivity between their exchange points They will roll out to eu countries (10ish) over the next 12 months The rules of current ix's seem to reflect the protectionism of the founder members investment If the company is bought out, they claim that a new owner would destroy the company by altering the neutrality position ergo the neutrality is assured They don't intend to exclude people, but how do you make bargain basement services ? Who's idea was this ? Keith Mitchell Existing ixps facing threats, colos threaten that if ixps don't work with them they will start operating as ixps themselves Its harder to stay ahead of the technology requirements with funding from current members The main problem is that every euro ix has a diferent service level, and level of information i-Point will fix this by standardising the eu ixp's Community cooperative doesn't work anymore Wih the cooperative omunity model there is not the same recourse for damages recovery Why a buyout model instead of a licensing model ? Its important that they can guarantee a fast responsive service.

1 0