______________________________________________________________________

                           DRAFT TRANSCRIPT

                              IX SIG

                       Thursday 2 March 2006

                               2.00pm

______________________________________________________________________


PHILIP SMITH:

I think we should make a start. Good afternoon, everyone, and welcome
to the special interest group meeting. We have two sessions for you
this afternoon. The first session is going to be full of longer
presentations. The second session we'll hear mostly from the Internet
Exchange Point updates, within the Asia Pacific region and around
the world. Now, before we start, we've got some housekeeping. If
you have any questions for any of the presenters, I'd like to ask
you if you could please use the microphone. Use it and don't just
stand somewhere close to it because we can't really hear what's
happening. Also this session is actually broadcast on the net. So
there will be a lot of remote participants, so that they can actually
hear what's going on as well. When you ask a question, please state
your name and affiliation just again to help with identifying who
you are and to help with the stenographers.


OK, afternoon tea area - you probably worked out where it is now.
It's over there to my left, in around the two sides of the Convention
Centre. There's the APRICOT closing event tonight at 7am in the
ballroom foyer. It's at the end of the lobby area, up the front of
the ballroom. APNIC would like to remind you about the MyAPNIC and
the policy flash demo which is running all day at the APNIC help
desk. The help desk is available during the breaks. Also, check the
onsite notice board. But you just check the onsite notice board on
the APNIC website just for any late changes.

And tomorrow there's the APNIC 21 informal closing dinner. It says
it's informal but it seems to be getting more formal with more
reminders and a bigger invitation list and so forth. If you have
completed the ticket payment, please come and collect your ticket
from the help desk today. So basically from now and from tomorrow.
If you don't know about it, there are more details on the APNIC 21
website. Before we launch into the presentations, just a little bit
of administrivia. Two chairs - Che-Hoo Cheng and myself, Philip
Smith. You can reach us at sig-ixchair@apnic. The agenda for the
first 90-minute session. The special interest group had no action
items, so we can skip over that part of the agenda very quickly,
and that takes us into the first of the four presentations/activities.
The first presentation is from Nigel Titley who will be talking
about the routing aggregation policy. Or more likely the failed
social experiment at the LINX.



NIGEL TITLEY:

This will be a fairly short presentation. When Philip heard about
what we were trying to do at LINX a year ago, he invited us along
to make a presentation. It was expected to be a long presentation
with lots of drafts showing how we affected the aggregation on the
Internet and how everything was so much better. Things didn't quite
work out that way.

OK, for those of you that don't know, the LINX is the London Internet
Exchange, used to stand for the London Internet Neutral Exchange,
somewhere along the line we lost our neutrality. About 90 gigs of
peak traffic. We're a distributive exchange. We have seven locations
in London. We are Ethernet based. We were found in 1994. We're one
of the oldest Internet exchanges as well. To understand this
presentation you need to understand a bit how the LINX is organised.
It's a company limited by guarantee, which is interesting, really.

English law doesn't have the certain entity as an association, so
you have to be a Limited company. Each member of the LINX owns a
share. If the LINX goes under, you lose a pound. We're governed by
two documents. One is the Articles of Association which is a very,
very difficult change. And one is the  Memorandum of Understanding
which is easier to change, which governs how we run the LINX and
governs the rules under which the members must exist. And the sort
of things they have to do to remain to be a member of the exchange.
It's owned jointly by members and all members must comply with the
Memorandum of Understanding otherwise they're liable to be thrown
out and this has happened on one or two occasions. It's threatened
quite often.

We have thrown somebody out for one point for routing their traffic
through other members without asking. The company went bust shortly
afterwards. They were out of the country before we were able to
serve them with their breach notice. Changes are voted on by the
members. At annual general meetings and overall the things are run
by a board and staff. OK.

Back in 1994, the Internet was still a nice place, and the LINX
founders had a sense of social responsibility and in particular
there are two social responsibility clauses. One is an all routing
policy, routing policy. It must be registered in a public routing
registry. That's something like RIPE or APNIC or whatever.

The other statement was that route should be aggregated as far as
possible. Now, aggregated as far as possible? It's a terribly warm,
fuzzy statement. And at the time it sounded good and everybody sort
of understood it. But it's really not very enforceable. Furthermore,
we actually only checked it when people joined. And nobody checked
it afterwards. There was a feeling that either we should get rid
of this statement altogether or we should actually make it enforceable,
measurable and enforceable and regularly checked. Here's the reason
why we have an aggregation policy - it shows the number of prefixes
on the Internet and everyone knows the report comes from the CIDR
report run by Geoff Huston. It shows the extent of the problem.
Apart from 2001ish, which we all remember, prefixes have been
increasing steadily.  People don't aggregate properly, that's one
of the reasons they are increasing. The pink line is what we should
be seeing and the yellow line is what we are seeing which is a bit
sad. Back to the story. When we have to change policy we always go
out and ask the members. What normally happens is we ask the members
and ask them to pass the resolution and we go and do it and put it
into the  Memorandum of Understanding. LINX meeting 48 passed a
resolution to adopt a mandatory enforceable route aggregation policy.
It was a fairly close vote - 19 to 17 - but nonetheless it was a
mandate. And the council got charged with coming up with an algorithm
of enforcement. We duly went away and did. From the ISPs, autonomous
system, should be less than Nx2+3.  Where N is the minimum number
of blocks they could possibly advertise. So we multiplied it by two
to make it. We gave three on, so that small ISPs could have a bit
more slack. And at least it's measurable. And we were proposed to
reduce this in 2006 to Nx1.5+3. But anyway. OK. We now have the
rules. Somebody went away and wrote a script to look at the number
of routes people were advertising and produce a sorted list of
sinning members and we notified, identified the members that needed
to take action, the ones who would be in breach if this rule is
actually voted in. And we gave a fair amount of time for this action
and we started discussions with members. We prodded them and said,
"Do you realise you would be in breach?" The other thing we noted
was that you would need to make provision for an emergency situation
and we just apply common sense.  And then the idea was that at LINX
quarterly meetings we would publish the list and everybody would
cringe in their seats and go away and fix the networks. And this
works quite well, actually, it's surprising.

So by December '04, we had this thing in place for two or three
months, and we saw some substantial improvements. Examples here -
UPC was originally 8th on the list and they moved down to 63rd,
well inside the breach. Indeed. COLT, Entanet, Rednet, Solnet, all
moved to 0% which was very good indeed. Things could be changed was
what was proved. And the members who didn't actually exceed the two
times metric did say, "We're going to fix it." And it seemed to be
working.

One or two large ISPs said, "We have huge blocks of IP addresses,
we don't want to announce the whole /14 or whatever, would it be
OK to announce /16s?" We agreed anything shorter than a  /15 could
be broken up into /16s and that was fine. The other thing apart
from certain breach notices, people suggested that maybe making
good route aggregation could be a requirement of transit contracts.
If you were buying, if you were buying transit from somebody upstream,
you might say, "You're on breach of the LINX regulations, we won't
buy from you." We thought, maybe. And to facilitate this we put
together a BCP and produced some standardised wording for people
to have purchase contracts. All sort of gentle nudges. And other
people suggested maybe good route aggregation was a peering agreement
requirement.  And furthermore, we sort of spread the word a bit.
Euro-IX gave us a platform. Most people seemed to understand. We
made the announcement at RIPE 50, only arranged to make the
presentation at APRICOT  '06, that just shows how successful
everything has been. RIPE also has a note that says aggregation is
the responsibility of the network operators. But again they encourage
to aggregate as far as possible.

What happened? Many members actually improved their aggregation.
What came out of this actually was it was very, very surprising
that most members didn't even know how badly aggregated they were.
That they were advertising /24s and all sorts of crap all over the
shop and they didn't realise it. So providing a metric to show they
were doing this was actually quite a good thing. And they went away
and fixed the router configs and a lot of it got better. This is
where the story starts to take a bad turn. We started to get member
backlash. And it was mainly from large, badly aggregated members
who I have to say it were mostly US-based. And they decided that
an Internet exchange had no rights to be telling them how badly
aggregated they were. And they basically organised a member backlash.
Remember, at this stage, nothing had actually been voted into the
Memorandum of Understanding. Anyway, we got as far as LINX 50. The
opposition managed to get the mandatory aggregation policy thrown
out. So we had no mandatory aggregation policy. It was converted
to a BCP. And we do have one you can look at that makes recommendations
as to how you should improve your aggregation. In one sense, the
mandatory aggregation policy was a failure. It would have been nice
to improve the general aggregation across the world. There have
been some successes. Some LINX members will, even to this day, still
only appear if you meet the BCP. It did raise the profile of
aggregation amongst the members. And made them aware of how badly
aggregated a lot of them were.  And I say an online check is available
- it will be available shortly - and it will tell you whether any
particular AS meets the BCP.

And that's the end of the story.

NIGEL TITLEY:

Because it's not particularly easy to see how badly aggregated you
are, they just are unnoticed. My employer was in the top five and
it was, you know, purely the fact that we had one or two routers
that were misconfigured.

SPEAKER FROM THE FLOOR:

Merely by notification and finding the right people and continuing
down that path, without using any strongarm tactics?

NIGEL TITLEY:

That was what we hoped. We did see that indeed. But I mean, the
CIDR report has been going out for so many years.

RANDY BUSH:

That's the problem. They look at it. And if you are - sorry, Randy
Bush, IIJ, also from the US, that's what the J stands for. You write
to people in the CIDR report and they say, "We know it. It's
intentional." I would call it a success, not a failure. You succeeded
in changing it by routers. You can keep your policy.

NIGEL TITLEY:

How long will that remain?

RANDY BUSH:

Maybe it's a process, not a policy.

NIGEL TITLEY:

At least we have a BCP and you can measure it. It's likely to go
the same route as the CIDR report.

RANDY BUSH:

The measurement tool might be interesting if it could be generalised
- show me what I'm doing.

NIGEL TITLEY:

It does pull it out of...

RANDY BUSH:

Even if I'm not a LINX member?

NIGEL TITLEY:

It will be generally available. The CIDR tool does this as well as
far as I'm aware.

RANDY BUSH:

Give them a website they can go to and play.

NIGEL TITLEY:

Maybe there's some success out there.

Basically, we're actually only aiming that ISPs own routes. Not the
customers at all. We decide that was well outside anything we could
possibly do. At least to start with anyway.


SPEAKER FROM THE FLOOR:

As the topic of the day seems to be traffic engineering, I had to
ask, there is this old mythical concept as long as you're a a peer,
you can select which router you want to have. It's much harder. So,
do you think that the reason why you were still, because these are
peering sessions as far as you know, you can't guarantee.

NIGEL TITLEY:

You're still allowed.

SPEAKER FROM THE FLOOR:

Do you see the people that did as part of transit sessions or traffic
engineering or therefore refused to do this or the people who didn't
do this, was it purely because of something else?

NIGEL TITLEY:

We never really got to the bottom of the few that wouldn't aggregate.
Not all of them were American, I have to say. The opposition was
organised largely by transit companies. I won't mention the one in
particular. But it wasn't just US. There are a number of Asian
carriers who are quite badly aggregated as well. We made no headway
at all.

SPEAKER FROM THE FLOOR:

The carriers are not local to Europe, therefore might be more able
to do it - with less issues?

NIGEL TITLEY:

That is entirely possible.

PHILIP SMITH:

Any other questions for Nigel? If not, thank you very much.

APPLAUSE

OK, next speaker up is Jordi Palet, he will be giving us an
introduction to the Euro6IX project. Just a reminder for everybody
while Jordi is setting up, if you ask questions, can you state who
you are and whatever affiliation you want to announce. And try and
keep your speech reasonably slow and clear so that the stenographers
and the online listeners can hear what you're saying. Thank you.

JORDI PALET:

OK. I give already a short presentation in the last APNIC meeting
in Vietnam, and I promised to keep a bit more explanation because
we didn't have too much time that time. The first thing to say is
this project started in 2002. It was designed in 2001. So obviously
some of the concepts maybe had changed for some of the RFCs we based
the project on has changed. We finished in the middle, end of June
2005. But I think the information here is still useful for some of
the ISPs and IXs that may I consider to start running IPv6. The
basic idea of this project, Euro6IX, was to try to push the deployment
of IPv6 in Europe which at that point, 2001, was very, very, let's
say, ancient. So the idea was to try to involve the key players,
basically the main ISPs in Europe and in every country.  And start
getting real experience with IPv6 and bring IPv6 into production
services.

So the main steps for this project were basically designing and
deploying a real IPv6 network, as I just said, it was almost nothing
available, real IPv6 services at that time, I'm talking about
basically 2002. Research, some advanced services in the network
which are often not available. I mean, real IPv6 services at that
time. All the network experiences which applications that within
the project, and also involving people in the project need to be
validated in a kind of user groups and international trials, so we
tried to be as much supportive as possible to meet who weren't
involved in the project that wanted to get and try some experiences
and give their first steps which are be active in dissemination
activities and so on.

Basically, the idea was to basically promote the deployment of IPv6
in Europe, not only in Europe, we have been active in dissemination
all around the world and the members of the project consortium were
basically all the European big ISPs. We had Telecom, Vodafone,
originally Airtel but guided by Vodafone. As you can understand,
this was a research project and basically the entities that
participated were the research arms of each of these companies, not
necessarily the commercial part of the company but somehow we managed
to involve also the commercial parts of those companies. One
interesting point is that the complication of the project came out
in actually, it was March, 2001, with a very, very small group,
trying to tell the commission how we can help to move on towards
IPv6 in Europe. And there were a lot of people, mainly from university.
I think I was actually the only one not related to university. And
all these people were telling the commission we need to invest more
and more in getting students involved in IPv6. And while my idea
was that we are totally wrong, the universities are going to do
IPv6 and I'm going to train IPv6 to people. But what we need to
involve is the big ISPs and while I got, let's say, the task from
the commission, OK, you have three weeks to create a consortium and
make a project if you can make it. In three weeks I succeeded to
convince all these people which was not very easy. I think the
result was very interesting because in addition to getting the
European Commission funding, the European Commission only funds 50%
of the projects, except for universities that get 100%. We were
also convinced that the commercial parts of most of these operators
to actually donate links and to extend the project lifetime, which
originally was only three years and it then became 3.5 years, because
most of the cost of the links, instead of being brought to the
project itself was paid by the companies. They were interested in
getting and starting doing some IPv6 things. So there was also two
industrial partners, 6 WIND and Telebit, a small Danish company
guided by Ericsson. We had three universities, Technical University
of Madrid, University of Southampton, University of Murcia. And
small companies like my own companies, come from Switzerland and
taking part in activities related to portals and a lot of security
things related to certificates for example and so on. And there was
another interesting thing. The Euro-control, the European agency
somehow in control of air traffic. They decided at that time they
were still using X 25 and decided they'll move instead, let's move
to also IPv6 and while there is already some deployment in that
network of IPv6, and up to now the planes don't crash in Europe,
so I guess it's working fine.


We had also, and this is very strange - I can show later the link
for this book and you can get it - there are always, when getting
any technology in production, some little things that you need to
consider, for example, related to privacy and data protection and
so on, we had - when I finish my presentation, I will show you from
where you can download this publication. OK, this is the network.
Basically, we had one Internet changer at every main city of the
square, where this project was carried out, one in Lisbon, London,
Torino, Berlin. IPv6 links these changes and then we have different
other sites, which were participating in the project, basically,
but also ISPs external to the project or other universities or so
on. This network was connected which the rest of the IPv6 network
respond.

Other big projects like 6Net which was similar. Basically in the
research and in Europe. And actually was the one that, let's say,
put the knowledge on hands of the people to activate IPv6. Basically,
related to Internet changes within this project. The idea was,
having an infrastructure that provides interconnection services for
Layer 3, in such ways that several IXs can make data offering in
peering in some networks and for service providers and even getting
every IX, using their own TLA. So instead of being dependent on the
ISP for the address delegation, having that from the IX itself. OK.
I know you - that was an experiment. Project partners used their
own TLA to have connectivity to the IX. This is a very, very simple
picture of this idea. We have what we call the standard Internet
Exchange of customers which gets the addressing of space from the
prefix allocated to the IX directly.  So we have Layer 2. We started
four different models for this IX infrastructure from the traditional
one, to one which, the one, we define it as the best one from the
project perspective. And it's what we call the IX model C. So it
has a Layer 2 infrastructure which is fully redundant. There the
router infrastructure from the long-haul providers and the customers
and what we call the Layer 3 mediation function router which is the
real new element in this infrastructure. OK. So the idea - the place
where we come out with the idea for this structure basically comes
from the previous person of the RFC  23474 and the function role
between the ISPs and the customers. Routing is about the same as
you can see in any transit network. From that sense, it is nothing
new. You can have route servers or whatever you need to run this
infrastructure.

We built also a lot of tools to do in relation of this, before going
into the real deployment. So here is how the address assignment
works. Basically, you have two options - IPv6 addresses assigned
by the long-haul ISPs. The network itself was behaving, 6bone was
behaving like another one of those providers. And we had one of
these long-haul providers. Or the IPv6 addressing can be assigned
by the address that I explained before. Same for the routing, you
have the autonomous system within the network of IXs and you have
iBGP, nothing new. And from the service perspective, what we try
to do is also to understand how making services in the Internet
exchange can be interesting for ISPs and the customers. So making
the IX is a kind of place where this service could be concentrated
and some of the network services like DNSSEC and mobility services,
transition mechanisms, route server mechanisms, different kind of
applications like word servers, media conference, peer-to-peer
applications and also a lot of monitoring services.  The idea somehow
is also to see this kind of IX as a possible way for the ISPs to
create virtual ISPs. OK, I know they don't like.

KURT LINDQVIST:

A fee-based infrastructure that provides services to customers is
traditionally called an ISP and ISPs do the jobs of ISPs has
traditionally not been long-lived?

RANDY BUSH:

I think it's wonderful. IPv6 exchange points can do this whereas
IPv4 exchange points just switch traffic. This is a fantastic
advantage.

JORDI PALET:

I thought you don't like it. One concrete example of this Internet
Exchange which is live still - because whether the project finished,
some of the partners decided to take it down but some others decided
to keep it working and this is the case for the UK Internet Exchange,
or UK 6X which in the Layer 3, IPv6 Internet Exchange. It was the
first one in the UK to offer IPv6 services. Used commercial IPv6
services. At that time there was a lot of use of 6bone. It is not
recommended or necessary. So it's located in telehouse and an Open
Internet Exchanger and it's still following the aims of the project
of motivating the deployment of IPv6 and further understanding of
IPv6. I don't think that's needed as much but it was one of the
basic goals.  They have an Internet switch for the layer two peering,
they have switch for additional customer access mechanisms, they
have a router for the layer three functionality. They used 2001:
618:/32 used for address allocation. They have different tools via
Looking Glass, ASpath-free etc. This is the basic structure. They
have connectivity to GPRS networks and a lot of demonstration and
activities which GPRS and mobility like IPv6, they have to 6to4 and
so on. One of the services that we tried also is DNS services in
general and especially DNSSEC services from the perspective of what
you may know about DNSSEC, it's nothing new, just making the service
available from the exchange. I was trying to explain a couple of
slides. I got interrupted and forgot about it.  The idea was to
from this perspective, you can create, let's say Y box and virtual
ISPs. You have several ISPs sharing some infrastructure. They can
probably lower their cost if they can put together most of their
service and of course that has good advantages from the perspective
of saving costs but it has disadvantages in the sense that they are
competing or they are, let's say, less competitive from the customer
because the customer is not tied to the address of an ISP because
even if he change the ISP within the same region, he will keep the
same addresses. It may be very nice from the customer perspective
but from the ISP it may be a disadvantage. I think that's the final
vision of this structure where you have all the security, quality
of service and services transition, that may be how some of them
collated in the IX itself.  I was quicker than I expected. That's
it.

KURT LINDQVIST:

I'd like to paraphrase my dear friend, Randy. I would encourage all
my competing ISPs to do this. The ones of you that want to have
remaining cash flows, if there is something useful to do about IPv6,
you would go to your local friendly RIR and ask for your ISP address
space and you leave this to your customers, the ISPs who traditional
provide services to exchange traffic over your LAN and you go on
minding your own business. Which is what the rest of us do.

JORDI PALET:

I must say that we got, of course, negative feedback but we got
some positive feedback. Actually, I remember right now I don't
remember exactly what city but someone in Canada was telling us
that they, I'm talking about two years ago or 1.5 years ago, they
said they like it a lot. And they deploy it on IX following our
model and at the moment they didn't explain and so I don't know.
Everything has good things, bad things, advantages and disadvantages.
That was a research project. The IX was a starting point for creating
this project but the important thing for the project was to all
IPv6 movement that we created around the IX and a lot of development
activities, porting of applications and, yes, the IX was an important
part but there was a lot of additional things and I cannot disclose
because that was part of the confidentiality.  And business models
following this approach and, well, I don't know what they're going
to do. If they're going to deploy it commercially or not but some
of them have very, very interesting ideas out of this model. So,
of course, it may happen, it may not, maybe some people like it or
dislike it but it's one more possibility.

BILL WOODCOCK:

The fact that someone expressed a preference for this two years ago
and hasn't explained since does not strike me as strong evidence.

JORDI PALET:

It was a joke.

RANDY BUSH:

Jordi, the truth is or at least my perception is, what we're really
looking at here is an IPv6 multi-provider deployment test bed, not
an exchange point. And so, we can make a lot of fun, but indeed if
we turn this and look at it as a v6 multi-provider deployment test
bed, then there are probably some lessons learned. It would be fun
next time, maybe not in an IX SIG but at a v6 SIG, to work out what
worked well and what didn't and why and that would be very helpful
because despite the fact we make all the jokes, many of us are
living with v6 to some extent. I'm from IIJ. To many of us, this
tunnelling stuff is hardly scary and less bad lessons we learned.
There are other things you're trying - not the marketing side - but
why some things didn't work I'd like to know and what we have to
do to make them work?

JORDI PALET:

You're right on that and probably not belong to the IX SIG because
there was something, I think I had in one of the slides and maybe
I mistaken, there was something that was a very evident learning
lesson, that if you do that, if you do this, obviously you cannot
predict the return for your traffic. That's the main learned lesson
from this model. And this is a problem that if we go into this model
or if somebody goes into this model, we need to understand that
very clearly. You cannot predict where you're getting the traffic
back. That's a very, very important lesson.

PHILIP SMITH:

Do we have any other questions or comments for Jordi? That's a bad
message to say that there is access to a Layer 3 point.

RANDY BUSH:

Pushing Layer 3 exchange points for years? When?  Want the email
now? From you, Woody.

PHILIP SMITH:

OK. Thank you very much.

Next up we have Serge Radovcic and his presentation is 'Euro-IX
Update'.

SERGE RADOVCIC:

My name is Serge Radovcic and I'm from Euro-IX. One thing I do want
to do - and I was in Mumbai in SANOG and I always try and get more
participation from the audience. And last time I had some test
questions during the presentation and people weren't allowed to
have lunch until they'd answered the test questions right and that
worked really well. Yeah? Which most people hate.

This time I've done something different. I've got a prize. Something
in this bag. It's that big and it's from - I won't tell you who
it's from but there is a prize in there. There's a spelling mistake
somewhere in the presentation so the first person who picks it up
- and please leave it to the end - gets the prize.

LOUIS LEE:

Are your slides online?

SERGE RADOVCIC:

The spelling mistake isn't. I'm glad to be back. This is my third
time here at APNIC. One of the reasons I'm here is to learn more
about the region and, while I'm here, I thought I'd give you an
update on a few of the trends and statistics that are going on in
Europe.

OK, Euro-IX was originally, and still is, called the European
Internet Exchange Association. It was formed in May 2001 as of
January last year which decided to invite IXs from outside the
region to join Euro-IX. Euro-IX is not an exchange point. We're not
an exchange point. We are an association of exchange points. So it
doesn't matter how many times I say this, people will come to me
in the coffee break and say, "How many members - how much does a
one-gig port cost at Euro-IX?" It will always happen but we're not
an exchange point.

We currently have 37 affiliated IXs, 33 of those are in Europe and
four of those are outside of Europe. Since I gave my last presentation
in Kyoto, Equinix decided to join - Bill, and you didn't even know
- SIX, Slovenia, joined, TIX in Tuscany in Florence, Italy, joined
and the latest to join outside of Europe is JPIX and we currently
have an associate member who's just filled in an application form.
I don't know why but it ends up being in the middle of the months
but once a month I do an aggregated peak traffic of the member IXPs
that do public traffic stats. That tends to be 23 European IXPs at
the moment and that comes to just over 500 gigs per second. This
time last year, it was about 272 so it's roughly an 84% increase
in the last 12 months and a 7.2 increase in the last month.

It works out to roughly 17.9 gigs per IX. We have one IX doing
around 130 to 135 gigs. There's currently 16 European member IXPs
offering a couple of high take-ups.

Of all the members, and that's including the IXs that I have outside
of the European region, we have 2,520 connectees to those 37 members.
If you go to the Euro-IX website, we have a couple of tools.

One is what we call the Euro-IX database. Basically, I get the IXs
to list the APSNs and the name of everyone that's joined. So it's
now 2,543 and you can search there and, if you want, do a search
on IXs or names or AS numbers if you're looking for particular
people.

Another little tool that we made was the IXP peering matrix so you
can also compare Euro-IX member IXPs against each other and look
for non-unique AS numbers.

So they're a couple of tools that we've got.

About 1,400 unique ASNs of people that are connected to IXPs, which
works out to 260Mbps peak traffic per customer. We hold a benchmarking
club for all our members and, in one of the sections, we had 30
IXPs fill in the benchmarking club for Euro-IX and they were all
European. The average price of a one-gig port is 850 euro. This
time last year we also did a benchmarking club and it was 880 euro
so it's not going up.

This is the make-up of our membership. We have small, medium and
very large IXPs. There are those that were established in 1993 all
the way through to 2002.

We have Cisco is the most common switcher used followed by Extreme,
Foundry and we have others also coming into the picture.

What we offer our members, our member IXPs - the usual stuff -
mailing lists, website listings, the portal, what you saw there
with the tools we offer. Probably one of the biggest values to the
members is the forums that we hold twice a year. A couple of times,
we've had more than 30 IXPs at these forums and they've proved
really successful and we'll continue doing them.

I mentioned the benchmarking club. We also have a number of information
repositories, maintenance diaries, so that people can keep an eye
on when the maintenance is occurring. The switch database, which I
think is quite useful and people, if they've got similar switches,
have a look at what software is being put on them and give the IXP
a call and say, "Did you have any trouble using that software or
switchers?" So it's quite useful. All this information is behind
the members' pages.

Plans for 2006 - well, our next forum is coming up in Dublin, Ireland
on 8th and 9th of May. We're considering taking a more active role
in public affairs, that's a discussion going on in other membership
and something we'll talk about in Dublin. We're always looking for
more and varied members from Europe and around the world and of
course we're also investigating other ways to collaborate with other
IXPs, which we'll discuss soon. If you're an IXP in the room and
you'd like to join Euro-IX or talk about the possibilities of joining
then please come and speak to me or have a look at the contact
details that I've got there up on the screen. And that's about it.

BILL WOODCOCK:

Somehow, I'm afraid that the performance metrics you're talking
about are not bits forwarded per euro. What metric did you have in
mind?

SERGE RADOVCIC:

You mean in the benchmarking club? We have about eight different
sections. It does talk about traffic. It talks about a number of
members, increasing the membership, staff issues, how much staff
costs, how many staff do these people have. We do have a lot of
models so it's hard to compare.

BILL WOODCOCK:

Bits forwarded per staff person would be an acceptable metric, I
think.

SERGE RADOVCIC:

From the information we provide, you could probably work that out.

Are there any other questions? No-one wants to claim the prize.
No-one picked the mistake.

If you are interested, the current membership fees are 4,000 euros
for a European IXP and outside Europe it's 2,500 euros. We are not
for profit. The fees are not the highest concern so, come and talk
to me if you'd like to be a member and that's it for the Euro-IX
update.

PHILIP SMITH:

OK. Thanks very much, Serge.

OK the final item on the agenda for this session is the exchange
point panel discussion. Serge is going to lead that. Che-Hoo and I
are going to move off the podium.

SERGE RADOVCIC:

I think there's four or five of you that know you should be sitting
up here. You don't need laptops or anything.

Kurtis actually won the prize.

OK. Thanks, Phil. When Phil sent out the call for presentations,
one of the topics that he had was IXP collaboration. I thought,
well, that's pretty interesting to me and I didn't notice else put
their hand up so I thought maybe I could attempt something here.

I guess one thing I want to make clear from the start is I've got
these five guys up here representing - "representing" - five different
continents but most of what they're going to say is their personal
opinions unless they express otherwise, so I don't think anyone
should be held to what they say. I'm looking to do an informal
discussion to see where we might go from all this and is it something
we want to do. I wanted to say that at the start.

OK, I had a bit of a look through the APNIC archives and I came
along this quote which I thought was a good way to start it. I think
it was during - a few years ago, I don't know who said it but I
thought it was a good way to start it up. I don't know where it
came from but I think it works well here. I want to introduce my
panel first. This is pretty much the order that I'm going to ask
the panel to talk about the regions in. Bill, German, Adiel, and
Kurtis and Gaurab. And you can see which regions they'll be talking
about (refers to slide). How much time have we got?

PHILIP SMITH:

28 minutes.

SERGE RADOVCIC:

I want to quickly talk about what collaboration is. Then we're going
to go through a tour of the world, what is going on in the five
regions around the world and then an open discussion about where
we think we might want things to go.

What is collaboration? I've got a couple of definitions. The first
one I came across was this one. I wasn't sure if this is what you
were talking about or not. (Slide reads: "traitorous cooperation
with an enemy.")

I had another look so it's definition two that we're working on
today although sometimes, through my experience in Euro-IX... yeah.

So we're looking at collaboration in the absolute broadest sense
of the word, from things that are going on as I just explained at
Euro-IX to discussions so I wanted people to keep that in mind -
we're looking at it in the broadest sense of the world.

So I'll get straight into it. We'll do a little tour of the world.
As I said, we'll start with North America. I think there's also a
portable microphone there, guys. You can give us a quick rundown
on how many IXPs there are in the region. It's on the presentation
- I hope you guys can see it. Anything specific about the IXPs in
your region and what form of collaboration in any sense of the word
is going on at the moment. So over to you, Bill.

BILL WOODCOCK:

North America has a stark division between commercial operators of
exchange facilities and non-commercial exchange facilities. To some
degree that's true everywhere but in North America it tends to be
a little bit more pronounced than most places. That has lent it
some kind of odd forms of collaboration. So instead of having
something like this forum in the US, we've got a lot of things in
which Internet Exchange, commercial operators pitch their services
to peering coordinators. So where a panel like this would be operators
of commercial exchanges and the people in the audience would, rather
than being people interested in exchange points themselves, would
be peering coordinators from ISPs and, in fact, any more, it wouldn't
be a panel with people sitting in an audience. It would be happening
on a cruise ship.

LAUGHTER

As this has sort of devolved from PAX and Equinix, each sort of
supporting, kind of contending, peering forums meet once a year, I
guess it became more than once a year each and it became a thing
where three times a year, OK. So it became too much of a hassle for
everybody, right. Nobody can go to, you know, three each of these
each year, regardless of how much vacation time they have or how
much their boss is willing to let them go do these things as part
of their jobs. So they've consolidated and I guess AMSIX and Noda
and D6 are all sort of jointly sponsoring this thing where peering
coordinators go and cruise around the Caribbean in a cruise ship
for a week or something. So I'm obviously a little bit dubious as
to the value of a week on a cruise ship instead of a week behind
the desk getting work done.

Bill will argue with me here.

BILL NORTON:

Should I do that now?

BILL WOODCOCK:

Sure. Go ahead.

BILL NORTON:

This is Bill Norton from Equinix. I understand that for peering
coordinators their job is to interact with each other. So they're
not sitting behind a desk as an alternative to doing their job.
They're actually going on this cruise to do their job face to face,
which is oftentimes much more effective than interacting with other
peering coordinators via e-mail. So that's number one. They aren't
going off on their vacation. Many of them see this as so important,
though, that they are taking vacation time in order to go on this
cruise. That's one thing.

The second thing is Josh Snowhorn actually started the initiative
of doing this on a cruise for a couple of reasons but one of which
was interesting and that is it's actually less expensive to do this
peering forum on a cruise than it is to rent a hotel with all the
catering and all the food and associated room nights and all that
kind of stuff. It's actually cheaper to do it on the cruise where
the food is already included. And the cruise liners now are bending
over backwards so that they can facilitate this business meeting,
this business interaction. So I'm just bringing this up because it
sounds like you're poo-pooing the idea as a fun cruise around the
Caribbean. And it's going to be some fun but there are also full
days of agenda here.

RANDY BUSH:

Bill, how do we become peering coordinators?

BILL WOODCOCK:

So, anyway, I say this mostly not to convey an overall large nature
of scorn, which I shouldn't and I don't need to, but to give an
idea of the tone of communication, where it's going in North America.
The fact of the matter is that we have NANOG meetings twice a year,
we have ARIN meetings twice a year. There is not really serious
discussion of Internet exchanges at those, as there is at APNIC and
at RIPE and at AfNOG and at LACNIC/NAPLA. We do have a lot of
communication about peering and very little about exchange points.
Partly that's because of the commercial nature, some degree of
commercial secrecy, the competitive nature and also the fact that
we're not really on the cutting edge of exchange point engineering
in North America in the way that, say, Seoul is, or London or
Amsterdam. We have a lot of, kind of, medium-size exchanges, where
people are not trying really to push 10 gigs through the switch too
much. We've got a few 10-gig peers in some places, the big guys are
at 10 gigs, right, nobody is doubling up or tripling up 10-gig ports
or anything like that.

So, you know, we're gradually moving from the centre of things to
becoming a backwater in terms of development of new technology and
deployment of new technology and discussion of new ideas.

So I think that's it for me.

SERGE RADOVCIC:

OK, thanks, Bill. OK, let's move now to Latin America. German.

GERMAN VALDEZ:

Regarding the effort of organisations for IXPs in Latin America,
there is an informal group called NAPLA. They have been having
meetings since 2001 and the most recent, or the most - part of the
agenda of these meetings were to experience exchange, discussing
best practices for the operation of these IXPs, reviewing procedures
of services and the organisational ways of these meetings.

Last month, from LACNIC, we started an effort to create a permanent
forum where all IXPs from Latin America be involved and can participate
and, until last month, last February, there was not any kind of way
or meeting where these organisations can experience beyond this
meeting that they had organised every year. But, after the meeting,
they lose contact and they see again the next year. The process
right now is to establish this permanent forum. They are going to
have a meeting with LACNIC in Guatemala next May. We are trying to
invite to participate the 26 IXPs that exist this the region. At
least, that's the number that we have so far. This will involve 10
countries, 10 different countries in Latin America. I highlight two
countries here, which is Cuba and Chile, which are the only IXPs
which are regulated by the government.


And one of the projects that has been discussed during this meeting
of NAPLA and are going to be discussed again in May is about regional
interconnection project. That has been the main topic in the agenda
for this meeting.

These countries which exist in IXPs are Argentina, Brazil, Chile,
Colombia, Cuba, Ecuador, Nicaragua, Panama, Paraguay and Peru. It
is interesting that in Mexico there is no IXP existing within Mexico,
mostly because there is a predominant IXP which everybody is connected
with him and also ISP can connected in a cheaper way with the United
States carriers. So the deployer of an ISP in Mexico never accomplish.
I think more or less that is the situation in Latin America.

It is important also to say that NAPLA is here to learn from other
experiences. I mean, there has been some cases in South America
where they are problems in the relationship with the associations
of the IXPs because the bylaws were not very clear or some dominant
IXPs take advantage of the situation and made some movement that
was not considered fair and, in the end, people is trying to learn
and experience on other sides of the world with other colleagues
in South America, Latin America, and I think it's a very interesting
group that is pushing to have a very well organised meeting.

SERGE RADOVCIC:

OK. Thanks, German. We'll head across the waters to Africa. Adiel.

ADIEL AKPLOGAN:

The situation in Africa is not very different from Latin America.
But one thing special in Africa is that the history, or the legacy
of the Internet itself make the exchange points set up in Africa a
bit more difficult because in most of the country there was a
monopolistic telecommunications company, which tried to peer all
the new initiatives and small ISPs. But the environment is changing
very, very rapidly and there is more and more cooperation initiatives
coming in different countries in Africa and, as soon as ISP start
talking together, they start moving from this environment to something
which is more focused on, first of all, the user needs and also for
their cost and efficient use of their cost. We know that, in our
region, we have one of the most highest connection, international
transit costs.

So they start working in our region - we have about 10 Internet
Exchange points over the 54 countries and the last one was the one
set up in Mauritius two months ago. And we have received three new
requests for IX address for new exchange points also are going to
be set up. So I will say that the situation is changing.

Two things - there is the AfrISPA, the Africa ISP Association, has
done a lot by encouraging ISP associations to set up an exchange
point where there is an ISP association. So most of the country
which are running exchange points has ISP associations so that makes
it a bit more easier.

I will say also that the WSIS process somehow has helped many
countries also to start looking at Internet in another way and in
many declarations in Africa, political declarations, fortunately,
there is a goodwill to encourage exchange points in different
countries and facilitate the set-up of local traffic exchange, which
is, for me, a good thing, because politicians still have a very
powerful influence in this area in Africa. So we will expect an
evolution on exchange points in the coming years in Africa.

Last month, the board of AfriNIC has taken the decision to allow
free IP or resource allocations to exchange points which is a way
for us to support the exchange point set-up and we are also discussions
with AfrISPA to formalise a kind of coordination for the set-up in
Africa. One of the things is to set up local exchange points and
what would be the best for the region is to move one level ahead
and set up regional exchange points allowing exchange points already
set up to be connected to each other. So that we can really maximise
the international transit cost. That is all about the exchange
points in Africa and we'll see what the upcoming year give us in
that area.

SERGE RADOVCIC:

OK. Thanks, Adiel. Shall we take a little boat north, across the
Mediterranean, to Europe and let Kurtis take that.

KURT LINDQVIST:

Right. I guess Europe is maybe, I don't know, the home of some of
the exchange point corporations that started in the EIX working
group in RIPE where exchange points got together quite long back
and discussed common issues and common problems.

One of the first results of that was the opening of the switch wish
list which was setting up a list of the exchange points collaborating,
working together on which feature sets they needed for functionality
and, of course, that more or less developed into Euro-IX which,
Serge said before, through Euro-IX, the exchange points in Europe
have quite a lot of interaction with each other. We share and discuss
quite a lot of knowledge about it, two forums a year with all the
members going to it. And there's a lot of interaction between the
IXs directly.

From our experience, we have, for example, worked together in
Amsterdam where people came together to share they're experiences.
And there's always exchange of information going on between the
exchange points in Europe.

There is also, in most of the countries, there is also various forms
of operator forums. The UK, there's an operator forum in Stockholm,
etc and, through these forums, the exchange points in the countries
would also have interaction for that particular country and do a
lot of work together. So, in Europe, there's a lot of this kind of
collaboration going on and there's a lot of interaction and exchange
of tools, resources and, to some extent, there's also been an
exchange of staff and sharing of common resources. I think that
covers it.

SERGE RADOVCIC:

OK. Thanks, Kurtis. We'll, leave the best till last. Since we're
in the Asia Pacific region. Gaurab.

GAURAB RAJ UPADHAYA:

I don't have a slide so I'll go on my piece of paper.

Most of the things are things I've learned from the APNIC IX SIG.
I just know what's happening in the IX SIG in AsiaPac. There are
two extremes in AsiaPac with countries like Japan and Korea who are
asking for 100-GbE platforms for IX traffic and there are countries
in AsiaPac which don't actually have an exchange point at all and
there are some exchange points about 7-meg and then multiple exchange
points in Japan with multiple gigabytes of traffic every day and
every second.

So when you talk about AsiaPac in terms of collaborations, I think
it is extremes from an exchange point point of view. We are not
seeing a lot of active collaboration between exchange points. One
of the forums has been at APRICOT and APNIC meetings. We have had
the IX SIG at APNIC for a while now. That's where we are. We also
have the peering track and IXP discussion track at APRICOT for a
while now. As far as I can remember back in time. That's going -
there is an increasing number of activities but, I don't know. Bill,
how many speakers from Asia did you have in the last three years?

BILL NORTON:

At where?

GAURAB RAJ UPADHAYA:

At the peering track in APRICOT.

BILL NORTON:

I don't know. You want me to look it up?

GAURAB RAJ UPADHAYA:

That would-be useful. Thanks. A lot of the speakers here are still
from outside the region when it comes to peering and things like
that.

But actually, sitting down here, I wrote down a couple of areas.
There seems to be some collaboration going on between exchange point
operations in Japan and Korea, mainly due to the high demand for
switching fabric. Last year, we had IXP switch at APRICOT and
multiple people talking there.

Second in line, I think Hong Kong is very distributed exchange point
fabric at IXs, omnipresent - everybody over the city connects to
the fibre IX and Singapore is the only place where commercial IX-ing
has actually been done outside of Japan, which is the IX in Singapore
exchange point.

Except for these three main places, all other countries more or
less seems to have not-for-profit IXs. The ones in Taiwan, Korea
are pretty big - there are multiple access points there. We have
new coming exchange points in India, Nepal, Bali and so on.

The exchange point in Australia - and there is one in the PIPE
Network with exchange points in Australia and, in New Zealand, we
have multiple exchange points operating. A lot of other things with
the exchange points - I have list here which says Thailand, Malaysia,
Philippines, all of these countries actually have multiple transit
IX operating there so all PPTs still providing IXP transit services.

The exception is Indonesia, where APJII runs a successful IX point
in Jakarta with three nodes. It seems like there's predominantly
one or two transit providers in the Middle East, basically not
really a transit point there. The NZNOG probably talks a lot about
exchange points. I've been told that at JANOG, they talk about
exchange points in general. At SANOG, we have an IXP track or people
talking about exchange points. And, as I said, at APRICOT and APNIC
at the IX SIG. That's it.

There is not a lot of collaboration happening within AsiaPac. I
think the only peering forum we had was Equinix 1, which was in
Singapore and Sydney or something like that. And PIPE Networks have
been promoting Aussie-NOG. I don't know if it's working or not
because I've been to only one, which was a couple of hours of
drinking beer, something like that.

Other forums, I don't know. So that's it.

Bill will have the numbers.

BILL NORTON:

I just had this year and last year.

GAURAB RAJ UPADHAYA:

That works.

BILL NORTON:

This year we had six speakers and Stephen Baxter was the only one
from the region. Last year, we have (counts) eight speakers and
three are from the region.

SERGE RADOVCIC:

So this year, last year we had six speakers, this year we had eight
speakers.

BILL NORTON: Other way.

GAURAB RAJ UPADHAYA:

It's there for you (points to transcript screen).

The point is we're still not getting a lot of people from the region
speaking up. I do an IX SIG presentation every six months and I
don't see a lot of people doing that. Thank you.

SERGE RADOVCIC:

OK. Thanks, Gaurab. Globally, I guess we'll do a wrap-up. The figures
according to what we did up there - these are from Bill - comes to
around 260 IXs in the world. My numbers were lower but I think it's
somewhere around that region. We can agree on that.

As I said in my presentation, Euro-IX has gone outside of Europe
now so as a form of collaboration, Euro-IX is starting to move
globally. We have four, looking to be five, IXs starting to move
globally.

PCH - they have IXP construction, information repositories - I think
this can be thrown in the same area.

The peering DB and the chat channel as well, the #IX. I guess,
because we have a few minutes to go, I'll skip a bit. I've got a
few questions up here that I'm posing to you guys.

Is there any questions from the audience? Do you mind using the
microphone, Bill?

BILL NORTON:

Bill Norton from Equinix.

I want to thank you guys for putting this together. I think, generally
speaking, there is not a whole lot of exchange operator-to-exchange
point operator cooperation. I mean, of those 260, from what I've
seen, the European exchange point operators are very sharing of
information; sharing notes on equipment, what works, what doesn't
work and so forth. Which kind of brings me to my question. Why is
it in an exchange point operator's best interest, selfish best
interest, to have more cooperation with those who may compete with
them, either directly or indirectly?

KURT LINDQVIST:

A very simple answer is that most of the European exchange don't
keep. We are not for profit.

SERGE RADOVCIC:

That's true. 80% are not for profit.

RANDY BUSH:

And you're geographically separate.

KURT LINDQVIST:

There's eight of them in London alone.

RANDY BUSH:

Yeah, yeah, yeah. Most of them are diverse.

I think there's a social physics that happens in this and many other
things and you can see it in the operating mailing lists, you can
see it so on and so forth and that is that, when there's a small
number of entities, they all communicate with each other. When there
get to be 260 of them, if it starts - it's too much noise, then
people start to localise. Look what's happening with the OG mailing
list and the OGs. There's now SANOG, NZNOG, so on and so forth.
It's trying to get the room small enough that you can have had a
reasonable conversation and that you have common interests.

And so I don't mean to discourage global organisation but I suspect
that there are enough there that what's happening is the regionals
are where the strength is going to be and, as someone who's worked
a long time to push some of the momentum southward into America
Latina and Africa, I think having cooperation in your two regions
and strength there rather than having more honkies coming down from
the north.


SERGE RADOVCIC:

I don't think I'm advocating making this a global IX. That could
be the case if that's what the IXPs want but we at Euro-IX initially
thought, "What's going on in Asia is really interesting. We want
to know more about this." And the Asians want to know more about
this. We've got a lot of experience we can share with each other
so why not join up?

BILL WOODCOCK:

What Randy is saying strikes me as right. What I may say may be an
exception is publication of research and documents, in that dragging
everybody from all over the world to a spot to talk in person and
try and get the room size right, yeah, is a difficult problem and
you may not wind up with people who have interesting things to say
and so forth.

But, on the other hand, encouraging people who do have something
interesting to say to publish it and get it on the Web where people
can find it would, I think, make a big difference. The Koreans, for
instance, I would love to see more about how it is they manage to
handle the volume of traffic they do and it's really difficult to
get anything not in Hangul out of Korea to find that out and so
you've got folks like LINX and AMS-IX doing lab work that they're
working really hard on that and a lot of the answers they want they
could have gotten from Koreans 18 months earlier.

RANDY BUSH:

I think another thing, by the way, I think a large percentage of
it is read each other's mailing lists already. How many people here
read NANOG, SANOG, and so on?

GAURAB RAJ UPADHAYA:

One other thing with Asia is also languages are so diverse in Asia
that collaboration is really, really difficult. I mean I know that
I talk to a lot of people here at APRICOT and, well, we can talk
with each other when we are here but communicating for both of us,
in a second language, English, over e-mail.

RANDY BUSH:

All talking in a non-Asian language.

GAURAB RAJ UPADHAYA:

For me, English is a second language. For a lot of participants at
APRICOT, English is not a primary language and e-mail, written
communication, is new to some people. I work in south Asia and each
time there is a problem, we've got some collaboration in Kathmandu
and I get more phone calls than I get e-mails. So there is still
an oral form of communication and e-mail really doesn't work all
the time.

KURT LINDQVIST:

I'll second what Gaurab said. I've spent some time making sure that
we can make sure we get everybody with English as a second language
to participate in discussions and as a region with more general
knowledge of English. We don't.

GAURAB RAJ UPADHAYA:

The Australians - as I experienced last year at APRICOT, the Aussies
and Kiwis speak a different form of English.

SERGE RADOVCIC:

I think I have to wind it up. I'm going to be around today and
tomorrow so if anyone is interested in chatting with me about
concepts, thoughts, criticisms, whatever, please approach me or go
to the Euro-IX website and you can send me an e-mail there to
serge@euro-ix

PHILIP SMITH:

We've run a little bit over. We've got 25 minutes before the second
session begins. We'll start off with Stephen Baxter and then we
have lots and lots of exchange point updates.

Thank you.  

[Session Two: 4:00pm] 


CHE-HOO CHENG:

Once again, slides are over there (indicates screen) and transcript
is over there (indicates screen). Because we have actually nine
talks for this session, I think we need to start on time and also
for each speaker, there will only be 10 minutes. So I think we have
to be quick. OK.

Let's start the session.

OK, this is the second session for the IX SIG. I am Che-Hoo. I'm
the co-chair of IX SIG. I think I won't go through the housekeeping
notes because Philip has already mentioned those.

OK, let's get started. Our first speaker is Stephen Baxter and he
will talk about exchange point operational experiences. 10 minutes,
Stephen. OK. Philip said you have 15 minutes.

STEPHEN BAXTER:

Very kind. Thank you. Good afternoon. As already mentioned, Stephen
Baxter from PIPE Networks. Some of you may have been in the peering
BoF yesterday, where I did some gratuitous self-promotion so I won't
do that today. I'll talk about the operational experiences that we
had starting and running PIPE Networks as well as a bit about how
we do IX operations to give you some sort of context.

A little bit about PIPE Networks. We're a company in Australia. We
run peering points. It's effectively a distributed peering point
model whereby we take peering to concentrations of IXPs. We've got
14 sites in six cities and in each of the cities, it's connected
by our own metro 10-gig on our own dark fibre so it's all good.
It's a good, stable, profitable business.

If you have any questions, please don't hesitate to talk. If I'm
going too fast for over there (indicates stenographer), I'm sorry.
That's just me.

We peer. We're effectively an MLPA exchange. We're a single
VLAN-typeset-off. There is lot of bilateral peering as well. It's
a single VLAN. We have ATM access into our peering points with a
great partner, with our business partner, to provide ATM accesses
into our peering points. We provide the routing for that to occur
and participants can get their own PBC into that so it slightly
breaks the ethernet model about it allows us to get a great critical
mass up early.

We use route servers for routing updates. We have a centrally managed
web-based route entry system and we automatically generate filter
lists on a day-by-day basis. I'm an ex-ISP operator and we can't
resist writing and building our own operational systems. The system
that runs it was written inhouse and has been maintained inhouse
ever since.

A bit of a disclaimer here (refers to slide). I'll get into stories
about what customers have done to us later on. I've removed names
to protect the guilty. The reason we can reveal this information
is because as a peering co-operator - and this might get up Bill's
nose - we're a commercial operator and we have staff that care about
our peering. So when something goes wrong, we know about it, we do
a lot of pre-emptive checking and the people I have looking after
this spend all of their time ensuring there are no accidents across
that fabric.

We're going to talk about what happens in that peering points, the
type of routers we use, switching, how we do the routing. Some other
experiences and some suggestions along the way. A lot of this is
probably common to a lot of peering points around the world and if
it is, I'm not trying to tell you how to suck eggs, but it's just
exactly what we've done.

Funnily enough, a lot of people use our peering points for transit
avoidance, least-cost routing. That might seem obvious but needs
to be stated. We're not as big as LINX but do decent peak in the
1.2-gigabit a second, a 7-day average there. In Australian terms,
it's nice, it's quite big. We don't have a lot of spurious on-net
peer-to-peer content that a lot of Australian-based operators might
receive a lot of traffic from. It's all fairly genuine traffic with
real content.

BILL WOODCOCK:

Before going on, can you explain what that is measuring?

STEPHEN BAXTER:

That is measuring the total ethernet port in and out.

BILL WOODCOCK:

Across all of your locations?

STEPHEN BAXTER:

Across all of our locations.

Transit supply. A lot of customers use PIPE as a mechanism to source
either primary sources of Internet access or secondary sources.
They do this either via a secondary BGP session across the common
VLAN or they'll nail up some sort of IP and IP tunnel, VPN sort of
GRE and some of them use sessions between Linux boxes to get that
next layer above and they use things such as the Netflow tools or
the Cisco rate limits to control how much traffic flows to a
particular peer or from a particular peer in that case.

There's a lot of layer 2 forwarding resale. In Australia, the way
you actually access a lot of the DSL and broadband offerings now
from the wholesale carriers is via MLSs and Layer 2 sessions
effectively. A lot of guys flick across the exchange fabric and
picking up less tail services - we see that delivery. Instead of
going to wholesale carriers and picking up multiple tails, they can
pick them up via the exchange points. It's an interesting use of
the peering fabric.

Inter-city high-speed, low-cost fabric - there's been a bit of
consolidation in the industry since we started, not as much as
before we started. As a result, a lot of businesses have merged and
consolidated. They'll retain their peering link in two locations
in the same city and use it as back-up or a transmission path between
the locations with the 10-gig metro rings we deployed it's easy to
do that but we don't encourage it. We try to move them on a VLAN
it shouldn't be a shared fabric for a start and it tends to skew
our peering statistics. We like to think what we're seeing on our
peering ports is actually peering traffic. Access to USENET feeds.
We make those available to read access, to our ISP's customers'
customers. We used to have a lot of Internet servers until we started
moderating the groups we carry and so they don't carry as much copy
right-protected content as they used to. As a result, the usage has
gone down.

I had another one in here where, if you had one ISP stealing another's
customers. One ISP in Brisbane found a good DoS path and it didn't
cost much to teach the other ISP a lesson. We jump on that stuff
and stop it but it was comical for an hour or so.

We use Cisco IOS-based routers. It's hard to pass up. They're primary
and secondary routers. All of our routers are in diverse locations.
While we use the same platform, they're in different physical
locations. All our locations are backed up with diverse rings as
well. We can lose a site and still get transit between the other
sites or transmission between the other sites. We use some Linux
and Quagga and Zebra based platforms on a low-value content. So we
have some free content areas where people put in mirrors and other
file transfer areas like that.  And it was a really cute solution
at the time.

Those boxes with an appropriate-sized CPU can transfer reasonable
traffic and they've been kicking along ever since. The routing table
size is 4% of the global table. If we did aggregation, I don't know
how big it would be after that. A lot of our customers aren't the
best at aggregating. I often joke that I could do it on 2,500-series
routers but, if I did, my customers would walk away so we use
7,000-series routers. We haven't deployed flap controls on the
routing table and that's good for us.

We've recently deployed a multicast framework. We've set that up.
Zero ISPs have taken advantage of that, which is a shame. We've put
a certain system out there with respect to multicast and we're
waiting for people to say if it's good or bad.

We first started using Cisco 3,500-series switches. They didn't
have any 10-gig support, which was tough when we started bursting
a gig regularly in places. We looked to replace that. We needed a
lot better port control. On the platform at the time, it wasn't
available. Spanning tree has always been an issue for us, especially
customers sending it to us. We hate that.

We ended up going to smaller locations, and they've been quite nice
until yesterday in one location which is another story.

The spanning tree control has been fantastic. Great for the price.
At the time, it was hard to pass up so we've got a lot of 10-gig
capability in the network.

Routing - the way we route is all customers have to enter routes
into a central web-based managed system. From that we actually burn
access filters every day, 7:30 in the morning and basically, if you
don't tell us you've got it, we're not going to let you route it.
It's about that simple. Each IX point has its own ASN but I don't
know if APNIC like us for that but we've got lots of AS numbers.
We use IP space from APNIC under the IXP allocation rules. We monitor
- interestingly, we monitor all the routes our customers send to
us and it's a really great tool for working out. If the customer
rings and say they're seeing routing issues, we can look at the
graph and see the dip or rise in routes and jump on the problem
quite fast. We don't mandate RIRs. The first few customers we brought
on board, basically recoiled in horror and didn't want to do it.
So we took it out. We don't require it now. All based on customer
feedback.

Some other interesting experiences. All the TCP vulnerabilities
became an issue - within a day, we issued passwords and pushed it
out automatically to the routers. We tied down that hole there. We
see a lot of cool tough that customers send them, God bless them,
a lot of our customers. A weekly or daily incident is sending us a
default route. There's never any accident - we get to see in a
system what's happened. Lots and lots of global tables. The amount
of IGP we see is staggering at times. A lot of V1 from certain
customers and all parts of the RFC 1918 address space came along,
not to mention everything from /32s onwards. You know when an ISP
de-aggregates into /32s, you're in trouble.

Some suggestions from us to peers. Don't turn on commands unless
you know what you're doing. IP verify unicast reverse path is one
of them. We ask them to take that command off if things aren't
working properly and magically it works. If you don't know what
you're doing or haven't got as much experience in routing, please
turn it off.

Critical routing solves so many issues. The BGP decision algorithm
- you shouldn't rely on it to make a commercial decision, because
it makes really poor ones. It's got all sorts of knobs and dials
that you can use to get a good commercial outcome. By default, it's
not the smartest. It's got no idea what your transit provider is
charging. Please turn off spanning tree. ACLs and communities - you
can tell us what location a route has originated from and we'll
leach that out as a community. That's good when an ISP peers in one
location so people can make intelligent decisions based on where a
route comes from if we're seeing it in more than one location.

Common aggregation policies if you're peering in transit - that's
our biggest bugbear. We exist by sending lots of traffic across a
peering point and when a provider sends us a /19, we put it down
into 32 /24s to the rest of the world, you don't see as much traffic.
They ring up and see they're propending out to the transit provider.
The smallest one always wins. I'm sorry guys. Try it again.

We had one fantastic customer who brings their secure management
network on to the IX  VLAN. Don't use spanning tree, not so much
with nuclear switchers. We'll shut your port down, it's fantastic
but you still ring us and get angry. Don't do it.

Thank you very much. That's time for me. That's how we do peering
at PIPE Networks.

CHE-HOO CHENG:

We can only take one question. No thank you.

STEPHEN BAXTER:

I'm disappointed.

CHE-HOO CHENG:

Our next speaker is from JPNAP. Ishii-san.

And please, the next speaker, Gaurab, please be ready.

TOSHINORI ISHII:

Hello. My name is Toshinori Ishii from JPNAP. I'd like to introduce
presentation from JPNAP. First of all, this is my company's
information. Internet Multifeed is one of the first Internet data
centre companies in Japan. And Multifeed started the Internet
Exchange service named JPNAP in 2001.

JPNAP is commercial Internet Exchange service in Japan, operated
by Internet Multifeed. JPNAP provides several services. It's named
JPNAP, JPNAP Osaka and JPNAP6.

JPNAP provides several special services and also an aggregation
service and traffic engineering service named PeerWatcher, that's
a BGP peer traffic graph, and IRR server and NTP server.

JPNAP is Internet-based distributed IX service. As I told you, we
have JPNAP service in Tokyo and JPNAP also have a service in Osaka
Area. Most locations have two sites each and they are interconnected.
But Tokyo and Osaka are not connected.

This is JPNAP history. We start several JPNAP services - JPNAP,
JPNAP Osaka, JPNAP6. And recent topic is JPNAP provides PeerWatcher
service and also provides IPv4/IPv6 dual stacking service. I will
talk about these topics later.

And the traffic volume of JPNAP is very huge. The peak traffic of
JPNAP is reached to 105.6 gigabits-per-second peak and JPNAP is one
of the most largest IXs in the world.

And we have about 80 ports and 40% users are already using 10-gig
interface now.

From June 2005, JPNAP provides traffic engineering service named
PeerWatcher. This service gives you traffic graph of each BGP peers
using sFlow technology.

Some ISPs operate - some smaller ISPs do not have such function on
their routers. So many ISP people are using this service to check
BGP peer traffic volume.

JPNAP provides this service to 10-gigabit ethernet customers for
free of charge.

And JPNAP also offer automatic back-up system named Optical Switch.
Optical Switch defects IX switch failure and automatically switches
to standby IX switch by optical monitoring. JPNAP provides free
backup IX port for all users, include firstly users but Optical
Switch is only suitable for optical fibre, of course.

Recently, JPNAP starts IPv4/v6 dual stack service. It's an optional
service and supports all users. It means a 10-gigabit Internet and
FE. You can use same service provider by IPv4 JPNAP network. JPNAP
also have closed users' meeting every four months. These past topics
there (refers to slide) and we have social gathering after the
meeting.

Traffic volume is still rapidly increased and JPNAP provides these
advanced services - PeerWatcher and Optical Switch and JPNAP starts
IPv4/v6 dual stack service.

And please visit our website. Thank you. Any questions?

LOUIS LEE:

Are you able to count traffic separately right now?

TOSHINORI ISHII:

Now not separated but I'm creating such future this spring. I think
so.

CHE-HOO CHENG:

That means, he will be soon.

Our next speaker is Gaurab. He is going to talk about NPIX update,
NPIX in Nepal.

GAURAB RAJ UPADHAYA:

OK, we are a couple of new - well, for those of you who haven't
been to my previous NPIX presentations, we are a Layer 2 access
point in Kathmandu. Two locations, one was the old primary location
and now we have our own facility.

Last year, we had three new companies join, all of them came in
with fibreoptics. Whatever.

Two of our existing ISPs upgraded to fibre link, dealing with DSL
and wireless connections before that. We also moved to a new building
and installed a new rack, mainly because pulling that fibre through
the - in the place we were earlier, alright, it's like we just moved
to our existing building because in the earlier building, we had
problems pulling the fibre and getting our own address space and
stuff like that. We said that rather than moving in a few years,
we'd do it now and so the new fibre is in the new building space.

We did training on BGP routing and multihoming. So I'm almost glad
to report that we no longer have any static in place finally after
two years. But there is some problems.

We've got a Looking Glass. You can see our routes at lg.pch.net.
We got a grant from the TU Foundation of Sweden. That's to install
the i-root-servers.net. I just installed it and got on a plane to
come here. I've been told that it's being tested and will get
operational maybe some time next week. The Autonomica people can
tell you more about it than I can. We've been working with people
from the local university.

Well, this is funny - I don't have an MRTG graph because I'm not
able to access our new transit line from here. We do have it on the
server locally but I can't get it to put it in my slide. Then, when
we have a Netflow project to give us a better idea of what's happening
with traffic flows. In aggregate, we see about 15Mbps of traffic
through NPIX in average on the two switches. That is actually 200%
increased over the last one year, especially after the two big
companies upgraded to fibre from wireless. We saw a huge increase
in traffic overnight.

There was a Nepali version of Linux released last year and that
basically saw a huge amount of traffic, because we had a local
mirror of the thing and people were downloading this every day for
almost a week. There was a strange amount of high traffic which
made a lot of people happy because, for many people, it was the
first time they downloaded entire CDs from the Internet in less
than half an hour.

Routing stats - we've started collecting the stats. It's currently
seeing an aggregate of slightly more than a /17, so basically we
have a /17 plus a /19 and five /24s. So there is the distribution
there of about three /19 and all sorts of things. We're still seeing
at least two providers doing longer prefixes than /24s, mainly
because of satellite VSats being used. The way it works is they've
got a box in another parts of Nepal and the VSats don't connect to
anywhere in Kathmandu. They don't announce those couple of /25s in
Kathmandu. One guy has a /28 so special cases. This is a roughly
25% increase from the previous count. In six months, we'll have a
new /19 and couple of new members. So in last year, in the year
2005, basically, the number of routes grew by 25%

All members are now using BGP, no more static routes. And, as I
said, we still have one member using a private ASN but that should
be temporary because they applied for APNIC membership so we started
with private ASN and I am told that, by now, they've got their own
AS number from APNIC and so they're over. And this is also a new
policy. We said that, for a while, we don't accept connections
unless people give an AS number. At the last member meeting, we
said we'd give three months' grace and they can come in and get
used to using BGP and running the network and we don't charge for
people for three months after they first connect. The first three
months for private ASNs.

We've got our own LAN now. This is probably a major thing. We've
got our transit LAN, our own ASN, own space, getting transit and
all that. The reason we had to do this was our network was getting
shaky because it kept having problems and also one of the necessaries
was we had to provide transit to some of the services and instead
of asking for transit every few months with a different ISP, we
said we'd go and get our own AS transit and put it together. So we
got a root server, DNS anycast servers, AS 1 and 2 installed and
we'll seen have an NTP server.

This is the target for the next six months. We'll migrate MRTG to
a better machine and put Netflow on a machine connected to the
switch. So almost everything is done. We'll create an archive of
the routing table then a big thing is we won't start anything new
before we finish all of this.

In the last meeting, there was some things about - out of the two
locations, one location is at a telco building and access to that
is very restricted. So the new members are not there so some of
them were saying, "Can we get a second location?" The thought behind
this is, though we have people coming in with fibre, it's all
overhead fibre, and the chances of vandalism and things like that
happening is reasonably higher compared to some other countries so
it's actually cheaper for the ISPs to propose a second site than
constantly upgrading one site or putting all the eggs in one basket
so, though the traffic will be small - all the international bandwidth
is pretty expensive. We're talking $2,000 per meg, one way. So,
even one meg traffic is pretty significant so we need to put more
resources and more money into it.

So, if you want to visit us, we have two general meetings a year.
You are welcome to come. Thank you.

Questions?

CHE-HOO CHENG:

Any questions?

(None)

OK. Thank you.

APPLAUSE

The next speaker is Puneet from India. He will talk about NIXI.

The speaker after this is Akito from Equinix. Please be ready.

PUNEET TIWARI:

This is the NIXI strategy between 2005 and 2010 - "The unstoppable
convergence of technologies which enable the seamless delivery of
information, communications and entertainment content is already
under way in India, thanks to the rapid push by the India Government
since 1999."

There are four revolutions under way in India. There are 882 million
people between the ages of 24 to 64 by 2020. The rural and semi-urban
initiatives are under way such as the setup of 100,000 CSCs e-choupal
by a company. There is very large potential working population of
Indians. The open source Google plans for free OIs and applications
and thin client PCs to lower cost of PC. It's a good opportunity.
We need to converge.

Thus, it is critically important to invest in a world-class NIXI
infrastructure so that connectivity and content service providers
can enable a seamless exchange of Internet content and data traffic,
so that the India-based end-user can improve their experience of
the Internet at a cost-effective price. Right now, all the NIXI are
situated in the SDPI, the software technology part of India, and,
according to information by the UNCTAD, governments should establish
a competitive milieu for ISPs, particular attention should be paid
to ISP domestic interconnection.

This is the NIXI vision - NIXI is the neutral peering and security
monitoring point for all ISPs and the Indian Government to ensure
that Internet traffic originating and destined for India should be
remaining in India. This is the main reason. And the mission is to
develop and roll out world-class backend infrastructure for all
Internet service providers in India which would deliver non-discriminatory,
efficient, security-compliant and cost-effective quality of service.

Yeah, NIXI values and culture - benchmarked to the world-class
standards for providing services which honour public-private
partnership spirit, transparency, non-competing, independent actions,
inclusiveness and unity in diversity, equitable treatment, process,
value and customer focus.

NIXI, right now, have two projects. NIXI have been given a task to
offer a .in domain name. NIXI has already registered 26,000 domain
names and the other is like 66,000 domain names, the old figure,
and NIXI has appointed 35 registrars so far and two registrars to
look after the government sector and the body that is NIC and to
resolve the dispute amongst all these companies, NIXI has appointed
an arbitrator to resolve these issues.

Just update on Internet Exchange. Internet Exchange - NIXI has got
51 connections for NIXI now. They are operating in the metros in
Calcutta and Chennai and 45 major ISPs have joined. And Mumbai has
joined and then next to Delhi is 100 MB and Chennai is third with
85 MB.

This is the roadmap for NIXI. NIXI want to establish this by 2005.
This is the roadmap (refers to slide). The present ISPI is also
acting CEO of NIXI.

OK, here's another benchmark. They are demanding that we upgrade
PPI infrastructure so that we can give ISPs a world-class service.
Right now, we have major ISPs like BSNL, VSNL, BHARTI, Reliance,
Gail, and PGCIL and Railtel are all major ISPs as well.

When Sanjay came became CEO of NIXI, he prepared a roadmap for NIXI
of what he would like to do in NIXI. Even the suggestion is required
- NIXI right now is a non-profit body set up under the Indian
Companies Act, 1950 and there is a proposal that NIXI can become a
practical body if everybody agrees.

Thanks. Any questions?

CHE-HOO CHENG:

Any questions?

BILL WOODCOCK:

Can you give us a participant breakdown on the four sites? You said
there's 51 participants for the four sites, can you say roughly how
many at each site?

PUNEET TIWARI:

We have maximum ISPs in Mumbai around 18, 19. I would think every
major ISP is already connected with - especially three NIXI nodes.
Out of the four metros, three are the major ones, like Bombay,
Mumbai, most of the major centres, and then Delhi and then Chennai.
At Chennai, we have a cable station apart from Mumbai so that is
why Chennai is catching up. For some time, we are expecting like,
Chennai will have more traffic as more ISPs will come.

BILL WOODCOCK:

So 19 in Mumbai. Do you know offhand for Delhi and Chennai?

PUNEET TIWARI:

19 in Mumbai and 18, 19 in Delhi and around 11 in Chennai. All the
information is on the NIXI website, just nixi.in. You'll find all
the information there on members, etc.

Any questions?

CHE-HOO CHENG:

Any more questions?

(None)

If not, thank you, Puneet.

The next speaker is Akito from Equinix who will talk about the
Equinix exchange update in Sydney.

The speaker next is Takabayashi-san from JPIX. Please be ready.

As a reminder for the speakers, please give all your slides to us
and then we can put them on the website.

AKITO KUROKAWA:

My name is Akito Kurokawa from Equinix and we provide collocation
exchange services in the US and Asia Pacific reaction and today I'm
going to give a very general update on our Sydney Exchange and some
of the initiatives that we'll be launching this year.

Equinix Exchange in Sydney started in 2003. We had about three
participants initially. Now we have about 18 participants and
participants include domestic and international carriers, ISPs and
content providers and, fortunately, we had some large international
content providers join our content platform recently. We also provide
collocation services, 24/7 services. We provide Fast Ethernet, MPLA
and BLPA peering and depending on if the customer requests it, we'll
have a separate VLAN for requests. We're a neutral IX and we also
provide some form of proxy peering for people who don't have an AS
so we assign private AS for those.

As for the traffic trend, we've seen some steady growth and we have
about 120 megs of traffic now on the average and we've had some
pronounced peaks in the past several months and the topology that
we use is pretty straightforward. We use Cisco and Foundry and we
have route arbiter, route server running the Quagga routing suite
and we also have a portal that provides utilisation statistics as
well as some of the collocation environments and also an integrated
ticketing system.

The initiative that I want to talk about today is Equinix exchange
extension and it's the extension of the exchange platform to the
second and third largest population centres in Australia which is
Melbourne and Brisbane. And the three sites will be connected by
ethernet backhaul provided by next-gen networks. The three sites
will be Equinix Sydney IBX and there is Melbourne Metronode Centre
and Brisbane Metronode Centre. The primary benefit is it enables
interstate peering via MLPA. It allows peers in each site to access
peers in all three sites. We do have intrasite BLPA available and
it basically allows for the usual case for peering is that you get
to reach a larger number of users, which is about probably over 80
ISPs and content providers across the three states. And we're
planning to launch this in March.

As for the topology - we have leaf nodes going to Brisbane and
Melbourne, which are L2 switches that terminate to L3 switches in
Sydney, which proxies route server routes to each of the different
sites. We don't allow BLPA across the different states. So it will
be mainly MLPA. And I think for resiliency, we'll probably be adding
more elements into this, especially the backhaul portion, in the
future. But right now, this is how we're going to start up this
exchange that is distributed across states.

Any questions?

SIMON HACKETT:

How large are the inter-capital links?

AKITO KUROKAWA:

It's shaped to 100 megs. We don't have any scaling concerns by the
traffic we're generating right now but we'll probably be able to
provision on the fly.

STEPHEN BAXTER:

What's the tariff for the extended peering?

AKITO KUROKAWA:

It will be the same as if you were to buy a port in Sydney. Oh,
sorry - can you go over there.

DONOVAN LEITCH:

The exact pricing is being worked out at the moment but basically
it will be more, basically because the benefit you're getting by
joining in Melbourne and/or Brisbane, you're seeing the benefit
immediately of access to Sydney's traffic.

STEPHEN BAXTER:

Do we know how much more?

DONOVAN LEITCH:

Not at this stage.

STEPHEN BAXTER:

It's almost March. It is March.

DONOVAN LEITCH:

It is March, yeah.

DAVID LUYER:

Do you have some system in place to eliminate connections between
ISPs in Brisbane and Melbourne abusing the WIDE area network which
happened to the prior Australian exchange that did this? So in the
prior Australian exchange to support Sydney, Melbourne and Brisbane,
it was a significant issue of abuse of WIDE area network between
Melbourne and Brisbane. So do you have a system in place to prevent
this?

AKITO KUROKAWA:

Right now we're not going to extend the L2 VLAN across the state.

DAVID LUYER:

I guess what happened in the prior exchange network was GRE tunnels
between providers to abuse this WIDE area network.

AKITO KUROKAWA:

We don't have something systematic in place yet but we'll consider
that later.

BILL WOODCOCK:

What's your definition of abuse because clearly the purpose of this
is to be used?

STEPHEN BAXTER:

But the reality is it won't last forever.

BILL WOODCOCK:

I'm not suggesting this is a good idea.

DAVID LUYER:

The definition of abuse is where related companies would peer in
Brisbane and Melbourne and then set up a GRE tunnel between the two
and this would cause, you know, at the time, a megabit which was
at that time thousands of dollars a month worth of transit to be
trucked between Melbourne and Brisbane, as an example.

STEPHEN BAXTER:

I've obviously got an agenda here but it's a valid point - the
example that David is talking about was the old Australian network
and one of the things that led to it going away was its transition
network. If that's going to take into account, is this being looked
at?

AKITO KUROKAWA:

That's definitely something we're concerned about and we'll try to
implement a system that will effectively eliminate those concerns.

CHE-HOO CHENG:

OK. Thank you, Akito.

Next speaker is Takabayashi-san from JPIX.

The speaker after next is Kurtis from Netnod. Please be ready.

TAKEJIRO TAKABAYASHI:

Good afternoon. My name is Takejiro Takabayashi and I'm representing
JPIX today.

I was at IX SIG on APNIC 19 in Kyoto and this is update from APNIC
19.

I will start from history of JPIX. Actually, we're a commercial IX
and there was a need for the commercial IX because there is only
one IX, it's an academic IX, and then a couple of major ISPs in
Japan got together and made a joint venture and we started out as
a commercial with 24-hour support and we have those collocation
service and offering cable service within the KDDI Otemachi Building,
where I think most of the traffics are in Japan.

OK. The services we are offering is that we are offering the ports.
We're layer to IX and 10-gigabit ethernet port, fast ethernet and
we started out the link aggregation and we don't have any 10GE
aggregation - we do have the link aggregation. And service types -
remote access. Because we're distributed but there is still not all
the customers, the ISPs, have access to our switch data centre,
where our switch is located, so we are accepting those ISPs router
connection by remotely. It could be dark fibre, ethernet or ATM but
ATM is almost gone.

And collocation service - it's a rack. We're offering rack service.
And we do in-house cabling.

And we have a stand-alone IPv6-IX service. It's a service but it's
only experimental and we have started this on January 2002. And
it's free if you have IPv4 port with us. And there's only FA ethernet
for this service. And traffic is not that much.  And we have 16
ISPs connected to this switch.

And optional service is value added. It's almost like Mr Ishii was
saying, almost the same as JPNAP has. We have one difference, I
guess, the MLPA with the route server exchanging service which
addressed prefixes that connects to our route servers and also we
have another type of route server which makes - which gives you
the, not statistics, but you can confirm your prefixes which you're
announcing matches IRR or not. We have RIPE and RADB replicated and
so, once you can make peer with this route server, you can check
your prefixes. And we also have NTP server and this traffic statistic
graph.

And new feature we are presenting is that traffic analysis tool
which is called sFlow and it's similar to PeerWatcher of the JPNAP,
it's our traffic viewer. It looks something like this (refers to
slide). It looks totally similar to JPNAP's.

And we have been distributed, extended to some of the sites because
of - we could go out and get, since we were only located at Otemachi
building, many customers had to have dedicated line or expensive
lines to get into the JPIX so we - what we did was to get distributed
and it says over here we have five sites right now and two at Nagoya
and Osaka.

As you can see, JPIX Osaka is stand-alone and other sites are
connected with each other. And a couple of sites are link aggregated
with 10-gig and a couple are aggregated with gigabit ports. And we
use dark fibre connection.

And basically network connection - we don't use any STPs or anything.
Just a cold standby - no not cold standby, but hot-cold standby.
Power is always on but cable is not connected.

And this is how it looks (refers to slide)

This is a simple diagram - remote access. We used to use those - I
don't know what generation they are, but they don't carry 10GbE
port and we started using, I think, since September 2003, we started
using those 10-gig - I mean, we start offering the 10-gig port with
four switches and it's running fine, I guess. Not too much problems.
We have seen some.

And here's our traffic volume right now. It's only metropolitan
area in Nagoya. It's 64-gig right now, as of February 20. And we
have number of customers around 110 and portrait yeo is most of the
customers are gigE but around 10% are 10-gig. Actually, we have 17
10-gig customers.

And that's about it.

Any questions?

STEPHEN BAXTER:

Would there be any traffic in common with the JPNAP presentation
before? Is there any commonality in there or are there common peers
that would be amongst those bandwidth numbers?

TAKEJIRO TAKABAYASHI:

You mean this slide?

STEPHEN BAXTER:

It's probably a question for the other chap from JPNAP as well. Is
there commonality between your customers and their customers?

TAKEJIRO TAKABAYASHI:

I guess so.

BILL WOODCOCK:

But they're not double-counting.

MIKE HUGHES:

One thing that's interesting - what's the backend database you're
using with that? Is it RRD or something else?

TAKEJIRO TAKABAYASHI:

For sFlow? It's SQLs.

MIKE HUGHES:

We found we were being strained by disk IO quite badly. Our network
is 15, 16 switches. What sample rate are you using on the switches?

TAKEJIRO TAKABAYASHI:

Actually, it's doing a very good job. We're using - I forget the
number - but 16-something-something. It's doubles, right?

MIKE HUGHES:

Yeah. It's doubles, right.

TAKEJIRO TAKABAYASHI:

I forget the exact number but it increases the sampling link can
handle. It just often backs up.

MIKE HUGHES:

So it's not a variable sampling rate?

TAKEJIRO TAKABAYASHI:

Right now it's not. Actually, our software can figure out. It's not
actually it's only a sample so actually it doesn't really matter,
actually.

CHE-HOO CHENG:

Last question.

SERGE RADOVCIC:

Quick statement. I thought I'd get my plug in for Euro-IX. There's
28 ASNs that appear at JPIX and JPNAP. If you go to the Euro-IX
website, you can see those.

TAKEJIRO TAKABAYASHI:

Thank you, Serge. We joined Euro-IX in February.

CHE-HOO CHENG:

OK, thank you. Next speaker is Kurtis from Netnod.

KURT LINDQVIST:

I'm from Netnod, the oldest exchange in Europe. Netnod was formed
as a separate company in 1996, 1997 in December '96. This year will
be our 10-year anniversary. It was basically there was a need or a
desire to have an independent and resilient exchange point
infrastructure and to have some form of a single national exchange
of traffic. The reason for this was around the time Netnod was
created, there was an influence by the view of national security,
or national infrastructure and security. The design was heavily
influenced by this and the design choices under the way Netnod is
instructed and set-up is to handle traffic exchange between operators.
And it was also decided in Stockholm, the capital of Sweden. We
thought we'd be able to exchange traffic and have enough capacity
to exchange traffic.  The latter is probably true for us but not
carriers connecting to us but that's kind of not our problem.

At the time of creation, a search for a suitable location turned
out to be a lot more complex. The criteria for doing the split with
the number of exchange points was that the cities needed to have
some sort of noticeable population and traffic volume and none of
Stockholm had this. There had to be some easy way to get carriers
basically transport capacity into those cities. That turned out to
be one of the hardest criteria to meet. It doesn't necessarily mean
the capacity goes into the ground by itself, especially not in 1996.
The last criteria was the exchange points were fairly spread out
right across the country. So that we could make some use of localising
traffic flows. I'll get back to that later.

The last criteria was the Swedish Government had already owned a
number of telecommunication bunkers, constructed 40 metres below
ground, they are of civilian use and they are used. These bunkers
are heavily subsidised and again based on the principle of national
infrastructure. Whatever goes in there has to be considered national
critical infrastructure, which basically means the voice exchanges,
it means us and basically subscribed to databases and generally the
stuff that goes into these bunkers. Here is a map of Sweden. Operating
in five cities. The northern most, the only one that is located in
one of those bunkers. You can save the geography lesson. There was
a fairly evenly spread out across the country and the original idea
was to localise traffic.  Sweden is a fairly long country by European
standards and we wanted to keep the response times down so there
would be a more favourite exchange of traffic. In the beginning
this turned out to be quite hard because most providers, whether
we had two locations in Stockholm and Gothenburg, all the exchanges
were in Stockholm. People ask me why and I wish I knew the answer.
I don't know. This slowly improved today, we will see the traffic
is exchanged locally and the largest growth we see is the local
exchanges, both in terms of providers and volume. Stockholm is still
the largest in terms of absolute numbers but the growth happens
outside Stockholm. The reason is the uptake of broadband connections
are so large that people don't want to back up, they want to - I
would guess - dump it locally and do hot potato routing. But it's
most likely also benefit, the peer traffic will pick the shortest
path. Something about the connecting service due to reconstruction
with these bunkers, these are undisclosed, so it's hard to find a
fibre in there. Instead, when you pay the connection fee to Stockholm,
we will get you the fibres from your regular, whoever it might be.
We will include fibres from there to the two bunkers in Stockholm.
As most of the international providers in Sweden are only present
in Stockholm, we increase the resilience behind two independent
switches in Stockholm, so when you connect to us, you'll have one
fibre repair from your location to each of the bunkers. The switches
in the bunkers are multi-connected. That's for a reason. This is
built for resilience. We don't want traffic in one switch to take
out the network, that's the idea, right, Mike?

I often, when I do this, there is - I wish you didn't have to do -
there are, you really want to keep it as little as you possibly
can. You do this basically for resilience. We happen to be the
switch vendor's most boring customer. If they can forward packets
between the ports, we're happy. That's a challenge for us. In the
other - the fibre switcher situation is quite complex. We will help
the ISPs find a fibre provider. Just like the switches in Stockholm
are not interconnected, they're completely independent of each
other. The bunker looks like this. It's a bunker. This actually is
below sea level. It's under water. Besides doing this - it was
decided at the time of creation we would do it around some critical
common infrastructure for the good of the Internet in general and
for the good of the Swedish Internet in particular.  So we actually
provide official Swedish time. This is time that is retraceable.
If your interest happens to be time, it is quite unique. It is a
requirement for telco networks that all time synchronisation is
traceable. You look forward to your standards and you're probably
quite vulnerable for attacks. We provide this - and we also run the
i.root-servers. In Sweden, we currently operate from, it doesn't
really matter, by looking at your router. But in theory you can
actually operate this from any location.

We also have a number of TLDs. We run the number of TLDs equipment
in Stockholm, around Germany as well, and whatever. There's quite
a few of them. And we run some local services. There is a bandwidth
tool provided by the government in Sweden. You can download this
tool and users can measure their available bandwidth.  There used
to be a broadband provider that claimed the customers got, let's
say, too many connections, and probably had 2-meg connections. And
they had 512 or something else. It has given, it has given the
operators at least some motivating incentive to actually provide
what they're selling. What is happening - the latest development
happened today. We are putting up each of these measurement services
today. We're doing this in all cities. Number of customers - most
in Stockholm, 36, and mix of Swedish and international carriers. A
maximum here - the peak load in 5-minute samples, it's not the
average sample rate. We're doing some 40-gig of traffic. 5-minutes
in total. This is for all the five cities. For Stockholm only, it
was a maximum around 27-27.5 gig and the rest is equally distributed
between Stockholm, Gothenburg and Malmo.


STEPHEN BAXTER:

What's the price of the fibre connection?

KURT LINDQVIST:

The price you pay includes the fibres.

STEPHEN BAXTER:

What would that be?

KURT LINDQVIST:

The way we pay the fibre is 209,000 kronors. It is 340,000 kronors.
Per year. You pay annually.

LOUIS LEE:

How well protected are the fibres protected outside the provider?

KURT LINDQVIST:

Outside there is, in the other cities there is only one switch. In
Stockholm we make sure the fibres are redundantly routed. It is
pretty obvious that the bunker outlasts the actual carriers and
from the end-users by far in case of real trouble. But we do go
through some length in making sure the fibres are redundantly routed.
That was the connection price, not the fibre price.

BILL WOODCOCK:

That includes both ports?

KURT LINDQVIST:

Both ports.

CHE-HOO CHENG:

Thank you. Next speaker is Cara Mascini.

CARA MASCINI:

OK, my name is Cara Mascini. Since we're doing the update for the
first time here, I included some background information. It will
follow. AMS-IX is a not-for-profit association which was founded
in the summer of the beginning of the '90s. We are independent and
neutral and it was, an association was formed in 1997, the exchange
started a bit earlier, and when it got larger and larger it was
decided to actually form a company, that is actually owned by the
association, for 100%. As a whole. That means the individual members
are all equal and have 100% of the shares as a whole. So no individual
shares there. At the moment, we have about 240+members, most of
which are ISBs, telecom providers, everything you can think of. A
number of mobile telecom providers because we host the GRX.


So port and member statistics. I actually included last year's at
the RIPE meeting, we always do this. We do it each half a year.
That would be taking a half year's update. You can see that we've
grown with quite a bit in the last year. Although it's not much
different than previous years. Normally the member growth and actual
port growth is linear. So since the beginning of the exchange,
there's been a linear growth of members and ports. The traffic,
though, grows exponentially, doubling every 10 months. We had in
January just over 350 ports. The most of which were GigE ports. In
2004, we launched a service and we actually had a lot of requests
for those last year. Up to the fact where it became a little bit
problematic at times.

We've also seen a lot of link aggregation. And the ports grow a bit
due to the fact we have - mostly mobile service providers connecting
to the GRX  VLAN. We have two core switches. We implemented them
at the end of 2005. And we needed them badly at that time to be
able to support the 10GE growth. We connect - we're a Foundry. And
we have seven Edge-switches at four locations. Those are scattered
throughout Amsterdam over four locations we have. Two of those are
like the original co-locations we have. They have a more academic
profile and we have commercial co-locations or data centres. You
can see there is a blue and a red, hub-spoke situation. All it is
the other core switch that is active. And the way we do that is we
use photonic switches where we connect 10MG 8.  We run to switch
from one core to the other. There is something that, whether we
should do maintenance or something should be swapped. So it's an
automatic fail over from one to the other.

Traffic and volume statistics. You look at the daily profile. We
actually do about 135 gigabits per second. It's a 5-minute average
and at night we're just under 60 gigs of traffic. The volume that
we do grew quite a lot in the last year from 12 petabytes a month.
We did one petabyte session a day for the last month. I've got some
member survey results that I wanted to share with you. We did a
member survey in the last, at the end of 2005. I've been told people
would be interested in hearing about that. We asked the new members
why they joined up with AMS-IX. Most of them chose the number of
routes that I can get at the exchange.  The existing members actually
said, "I'm staying, I keep being connected because I realise so
much savings. There's no reason to disconnect." The performance of
the network operating team, that's basically response to requests,
maintenance updates, things like that. Keeping everything stable
and alive. Most of the platform parameters that we report on -
packet loss, delay and jitter, are considered good to outstanding.
How we report on that and make this available on the website is we
use the RIPE NCC  TTM project. That measures traffic and barometers
between the switches.

The one thing that we didn't do very long ago is reporting. So we
can work on that. We will. Something else that we asked people,
that is, respondents of the survey, that how is your, what is the
establishment of peering sessions - do you have any problems with
that. Is it a good experience that you have? And most parties are
having a good experience with setting up the peering. They can fight
the peering information. It's all available online but it's sometimes
difficult to actually find. So that is that.

In terms of the paying policies that are used, most of the parties
have an open peering policy, which is kind of standard at AMS-IX.
There is a large group of carriers that has a restrictive or even
closed policy. 87% chose that they have an open or semi-open policy.

About 64% of the participants peer with more than 100 unique ASs.
And they are connected to a 4+exchanges. I excluded the ones that
chose for a 10+connected exchange, so the big guys are excluded
there. Most of the networks are connected to average 4 exchanges.
The ones that were mentioned were DE-CIX, LINX, NL-IX and Equinix.
A lot of others were mentioned but they were the main ones. The
10GE uptake up is continuously high so we're working on platform
developments and we're pushing the MGH to the edge. We're replacing
those MG8s with MG16s. We're upgrading the platform.

AMS-IX didn't have a route server for a long time and people were
asking us to set up a route server, so we did. It's not being used
that much yet. Having a route server would serve the smaller members
a lot in keeping their CPU load low or lower. And it also serves
the larger members because they get a lot of requests from the
smaller members and they don't want to set-up like a million sessions,
so they use the server for that.

We launched the support of CWDM GE interfaces. There's a lot of
developments on VoIP, ENUM and services that were looking into what
should be the position of the Exchange? Should we do anything with
it or keep clear of that? The same goes for streaming and DRM
support. It's all value-added services that we may or may not go
into ourselves and if we do, we will sort that. Any questions?

CHE-HOO CHENG:

Any questions? Thank you.

APPLAUSE

Our last speaker is Masaru Akai.

MASARU AKAI:

My name is Masaru Akai from BBIX.

This is the first time to introduce BBIX. BBIX is carrier-free IX
and any organisation that acquired global AS number in Japan is
welcome in BBIX.

And the Japanese government has adopted R value in IP Phone, so it
is important.

The IX is concentrated in Tokyo. Local ISPs exchange traffic using
IX in Tokyo or Osaka.

Traffic in the region exchanges in the region.

BBIX Tokyo has two bases, Otemachi and Nihonbashi, and you can
contact them through Equinix and BBIX. Customers collocating within
the Equinix Tokyo BBIX will be able to acquire BBIX's IX connect
service, through the Equinix Exchange service. BBIX will provide
to exchange traffic for about 5 million broadband users in Japan.

This is the yearly graph.  It shows a one-day average (refers to
slide).

These are the BBIX locations (refers to slide) - BBIXTokyo is there
and BBIX Osaka and BBIX6.

Do you have any questions?

CHE-HOO CHENG:

Any questions?

(None)

Thank you. Thank you.

APPLAUSE

OK, I want to mention two more things about tonight's closing event.
It will start at about 7pm tonight and will be held in the ballroom
foyer upstairs.

And also for the informal APNIC 21 informal closing dinner tomorrow,
people who completed ticket payment, please come to collect your
ticket from helpdesk today and tomorrow.

Thanks to all the speakers. Please hand in your slides to us so
that we can put them on the website.

That's it for this session. Thank you, everyone.

APPLAUSE