IX SIG transcript
APNIC 25
IX SIG 1600-1730
Wednesday 27 February
Table of contents
Co-chair elections
Indonesian IXP Updates
JPIX update
JPNAP update
Equinix AP update
GAURAB RAJ UPADHAYA:
How is it in the back now? Is it OK? Because now we have another session next door so we can't be too loud. Can you hear me in the back? OK. If they complain, then we'll have to...
Welcome back.
Now we are into the APNIC IX SIG. The IX SIG is the special interest group on Internet access points. APNIC IX SIG not only meets at APRICOT but also at the standalone APNIC meetings, which are every six months. So we have...generally it's for IX operators to interact with each other.
And starting with Bali, the IX SIG is now also part of the Inter-provider Relationship Stream at APRICOT, because there was a time when we were doing IX talks in two different rooms at the same time so now that won't happen again. So...
I'm Gaurab Upadhaya. I'm currently the chair of the IX SIG and Che Hoo Cheng is the co-chair. I run the Nepal Internet Exchange and Che Hoo runs the Hong Kong Internet Exchange. Well, in Hong Kong, right?
CHE HOO CHENG:
Yes.
GAURAB RAJ UPADHAYA:
So welcome, everyone.
Co-chair elections
We've got a sort of interesting agenda here.
First up we have the IX SIG co-chair elections. Since the one last year, the APNIC SIG chairs have sat together and made out...well, I'll say a TOR or Terms of Reference on chair, co-chair elections. And I was elected chair last year in Bali; and so this year we are up for co-chair elections. The chair, co-chair position is for two years. And there are a few requirements, like the person who is a candidate must be present in this room now. And then the person will also have to attend every other alternative APNIC meetings, which means that they have to be present at the IX SIG meeting at least once a year. So those are the minimum sort of basic requirements other than attending meetings and, you know, helping out with running the sessions and so on and so forth.
We haven't seen a policy proposal in the IX SIG for a while now, but we can also discuss policy proposals in the IX SIG, and then we can recommend it to the Policy SIG for adoption later. So if there are any IX-related policies that you might want to take to the APNIC policy process, then this is the place to start it. And we can have discussions on it. And we follow the standard policy process that is also part of the Policy SIG for the IX SIG. Do you want to add something?
CHE-HOO CHENG:
You want me to add something?
GAURAB RAJ UPADHAYA:
CHE-HOO has been on a lot longer than I've been here.
CHE-HOO CHENG:
Um, I think, well, this is a test for, you know, integrating the IX SIG with the Inter-provider Relationship Stream of APRICOT. And, in fact, um, I'm not quite happy with the current arrangement and I think, you know, the IX SIG should be, you know, part of the Internet Interprovider Relationship Stream, or maybe I should say it should be equal to the Interprovider Relationship Stream of APRICOT instead of being just one small session of the stream. That's my opinion. But anyway, I am about to step down so I will hand it over to my successor to, you know, pursue this objective.
I have nothing to add other than to remind you guys, if you have questions, please, um, use the mic because this session is webcast and, oh, the good thing of this being part of the APNIC program is we have webcast. But for APRICOT sessions, I don't think they have webcast.
So, Gaurab, back to you?
GAURAB RAJ UPADHAYA:
Yeah, we'll go forward with the IX elections first.
We have two candidates: Ong Wee Cheong from SDIX, which is the Singapore telecom transit IX and Raphael Ho from Equinix Asia Pacific. Actually, I'm not sure if both of them are in the room. So Ong Wee Cheong? There. And Raphael Ho? There. Great, so can I ask both of you candidates to come here and say a few words as to why people should select you as the IX SIG co-chair? So we'll go alphabetically, so Ong Wee?
Please use the microphone.
ONG WEE CHEONG:
Just a minor correction here. I'm no longer in the SDIX. I was a pioneer in Singtel who wrote out the Internet Exchange that was born in Asia together with some of my colleagues who is currently in Cisco and elsewhere. I'm right now in the satellites, still in Singtel and we have successfully launched the broadband via satellite backbones today and that's where is my background. So that's a minor correction. Because Singtel is an organisation so big and there are many groups. So just to clarify that. Thank you.
GAURAB RAJ UPADHAYA:
Can you also continue with your why we should elect you SIG co-chair? That's part of the whole thing. So come up here and maybe do the introduction.
RAPHAEL HO:
Thank you for your time, everybody. My name is Raphael Ho. I'm the director for off network operations and engineering for Equinix. As you know, Equinix is a regional exchange operator. We have three exchanges within Asia, in Australia, Japan and Singapore. And also in the US, our colleagues over there is operating very large exchanges in multiple locations, which I'll update during the Equinix updates. So, obviously, Equinix is carrier-neutral, so I do not represent any carrier organisations, which gives me a position to be more unbiased or, you know, friendly, hopefully, towards everybody and we take a neutral ground and we'll help you guys do peering.
And, as well, helping you guys do peering is my day job, because I operate the exchanges, so I'll definitely be very active in promoting the IX SIG, as well as promoting peering, during my term. Thank you.
GAURAB RAJ UPADHAYA:
Thank you. Ong Wee, will you say something?
ONG WEE CHEONG:
Well, perhaps in one or two sentences, to summarise my strengths and so far in the past, I will say since '94, to today, I think more than 13 years, I've been spending a lot of time in the regions of south Asia, central Asia, to promote peerings. I work very closely with north Asia, with network providers in terms of establish the transit within Asia, within the continent in terms of cost-savings, majority, I would say, to reduce the cost. So also established the multihoming with most of the large network providers. This is something we should encourage within the region. Thank you.
GAURAB RAJ UPADHAYA:
Thank you, Ong Wee. Yes, I put on the links there if you want to read about the candidates' statements, which is on the website. The Internet actually is working right now so I can pull it up. I thought I would do that earlier. Thank you.
So do you need time to read the whole statements? Or...?
OK, one minute. That's what I've just been indicated, so...
(Pause)
This is a very simple election I would say. It will be done with show of hands so I would like to ask you to raise your hands if you're supporting Ong Wee Cheong from Singtel to the position of the co-chair of the IX SIG.
Any votes for Ong Wee Cheong?
OK, votes for Raphael Ho?
I don't think we need to count any more, so...
LAUGHTER
Thank you to both candidates for participating. Thank you to Ong Wee especially, and thank you, Raph.
Also thank you, Che-Hoo, for serving as the IX SIG co-chair for the last six years or more? Since - I don't know - from the very beginning.
CHE-HOO CHENG:
To be frank, I didn't do much. For sure I think Raph will do a better job than me and may I hand the mic over to Raph now?
GAURAB RAJ UPADHAYA:
No, no. You get to sit here. You have one more chair.
RAPHAEL HO:
I just want to say thank you, everybody, for your support and I promise to do a good job and really bring on, bring on the peering relationships of everybody within this room and beyond to the next level and, you know, thank you very much.
GAURAB RAJ UPADHAYA:
Thank you, Raph. Your job will start from the next meeting, so CHE-HOO will sit here for a while.
So let's get back to our main agenda for today and, as I said, there are a couple of housekeeping announcements before we move ahead.
Andy, if you want to come and set up your laptop, I can... where's Andy? Oh, yes.
So while he sets up his laptop, there are some housekeeping announcements.
So the APNIC social event, which is supported by Nominum, will be held today from 1900 hours to 2100 hours at Shintori 5. Transport will be provided. Tickets look something like this. Oh, it is not required, but I think this is what is used for counting the number of people getting on the bus so that they can, you know, provide enough beer for you, right?
SPEAKER FROM THE FLOOR:
On the bus?
GAURAB RAJ UPADHAYA:
No, on the venue.
You do need to wear your badge. You need to wear the badge. This is more for counting the number of people getting on the bus from what I know of previous histories. I grabbed this so I could show it to you a few minutes ago. More information on the APNIC website.
The APRICOT closing event will be held Thursday, again from 1900 hours to 2100 hours at the Chung Shan Hall. Transport is being provided for that as well. Is that in the hotel is itself? I'm not so sure? It's not onsite. It's somewhere else, in a hill somewhere from what I've been told. I'm pretty sure that there'll be more information about this coming through tomorrow morning as well.
The APNIC informal dinner is held on Friday after the APNIC Member Meeting. Transport will be provided but if you are interested to join the informal dinner, it will cost you TWD600 and you have to pay on site.
The APNIC Helpdesk is in the Osmanthus Room, which is as you go out of this room and go left towards the end of the hallway, opposite the stairs is where the APNIC hostmasters are. So if you have anything, any issues with APNIC resource allocation, you should go and see them.
APNIC is also giving out a digital photo frame for those of you filling up a survey about the meeting. The survey form is available online at the APNIC meeting website and then you'll have to fill out the survey before the afternoon tea on Thursday, 28th of February. And winners should be announced during the last session of the day on Thursday, so by tomorrow.
Also, the usual APRICOT announcements: The slides and the latest program are generally available at the conference on apricot.net. You should start disregarding the big sign outside and actually go to the website to see the latest updates as well as the slides. As the sessions go forward, we'll try to put all the slides online as soon as possible.
Having said that, OK, we are ready with Andy with the Indonesian IX updates.
Indonesian IXP Updates
ANDY KURNIAWAN:
Hello. I need to presentate about IIX and IIXv6 development update from 2007.
Overview, I will present about the Indonesian Internet history, birth of IIX, the role of IIX during the monetary crisis in Indonesia in 1997, and IIX operation, IIXv6 development and development of NOC IIX-APJII.
APJII is Association of Indonesian Internet service providers. It was non-profit organisation founded in March 1996 at the first of national conference in Jakarta. Membership included 27 ISPs plus Indonesian University and Indosat and Telkom Indonesia.
ISPs in Indonesia in 1994. Indonet and IPTEKnet was the first operational ISPs in Indonesia. Started operating in 1994, launched before ISP licences were required from the government, used 9600bps IDD to dial up to Singapore. And the service were TELNET IRC and UUCP.
Next in 1995 RadNet was the first licensed ISP, start operating in 1995, introduced the World Wide Web. The first ISP surfing you could do in Indonesia. Indonet and other ISPs followed the models. Regulators issued a total of 27 ISP licences.
This, Indonesian Internet before IIX. All ISPs make their only peers to the tier 1 in the USA or tier 2 in Singapore.
The birth of Indonesia Internet Exchange. Initiated by APJII on June 1997. No funding was provided by government. Designed by Cisco (US) and APJII. All active ISPs contribute. Routers were granted by Cisco. Baseband modems was granted by RAD. Servers by HP and Intel. First operational on August 1997.
Seven fundamentals of IIX: A sense of belonging, relationship, giving good effect for APJII members, non-profit, do not make competition with members. Our members is ISPs; neutral and independent.
This, Indonesian Internet after IIX.
The role of IIX during the monetary crisis in 1997. The monetary crisis started a few months before the operation of IIX in 1997. The US dollar rose up to 800% towards ID Rupiah. The international bandwidth fees in US dollars. ISP is predicted to be closed down in a few moments.
This, maybe the local bandwidth from one ISP to IIX is 512Kbps. Not using the international route, ISP has saved the monthly costs.
The role of IIX during the monetary crisis. ISP was international connection has been disconnected, informed that its customers to get an access to local sites in Indonesia. IIX is used to connect one ISP member to another ISP's proxy server, give more time to ISPs to restore their international bandwidth. Not one ISP was closed during the crisis.
And then drop delay time of local sites' access from an average ping from 700 milliseconds to 7 milliseconds. New opportunities of deploying Internet-based applications due to the small delay time. Stimulating the growth of local Indonesian content. Security for e-commerce since local packets will not go through the global Internet, implementation of e-gov with local Internet traffic.
IIX routing. Members use their IP address - both IPv4 and IPv6 - and AS assigned by APNIC. Interface addresses are given to each member. The benefits of this configuration: Each ISP needs only one BGP peer, minimises the CPU load of ISP's router and minimises the investment of all ISPs.
This sample from IIX-JK. Members peer only to the IIX router. IIX is layer 2 and layer 3 infrastructure. Routes more than 1,500 announcements, prefixes IPv4, received from its members. Peering party, 49 ISPs. From more than 200 ISPs. Router utilisation is about 8%. And average traffic per day: 150 megabits per second.
This graph from CPU router of IIX-JK2.
OK, IIX operational implementation. We have one IIX day-to-day administrator with three back-up administrators from three different ISPs. The three administrators are not informed for public. Use IPv4 and IPv6 address which cannot be accessed from outside Indonesia. Use own AS number. Use BGP4 routing and static to facilitate the connected ISP. A 24-7 monitoring by the IIX and ISP administrator.
This traffic history from August 1997: First the IIX connected only five ISPs from 20 active ones, resulted in less than half a megabit per second peak traffic every day. In July 2002, IIX connected 63 ISPs of 65 active ones. Result average traffic: 250 megabits per second every day. 2004: Connected 92 ISPs with average traffic 1.2 gigabit. In 2005: connected 110 ISPs of 118 as active ones, with the average traffic 2.3 gigabits per second, with peak traffic 3.5 gigabits. 2006: IIX only connected 20 ISPs of 140 active ones. Result traffic: Only 10 megabits per second every day, with peak traffic at 30 megabits per second per day.
Maybe, this is the graph from the IIX traffic history. Reason of decreasing IIX prefix and traffic in 2005: APJII had political and business conflict with IIX-JK2 co-location operator. In 11 September 2005, the operator shutting down the power of IIX without any confirmation and reasons. The operator moving out all ISP peers to their new router that placed beside of IIX-JK2 router. And then 80% daily traffic IIX is from IIX-JK2 peers.
Next: IIX now, 2007 and 2008. IIX nodes operate in Jakarta. Three nodes in Jakarta with 49 ISPs. In Surabaya, another city in Indonesia, it's one node. In another city, Yogyakarta, and Medan, it's one node. Total ISPs connected to IIX-JK are 49 ISPs. Total prefixes announced to IIX-JK are 1,569 prefixes. That's at 1 December 2007. Total average traffic in IIX-JK are 150 megabits per second.
OK, this graph about the IIX traffic from the 2006: We had grown maybe 100 megabits per second.
Daily traffic sample from IIX. This captures the traffic of IIX-JK2 switch. It's the security reason because this graph is for government monitoring.
This is the configuration of IIX. And now IIX v6 development. In 4 March 2003, IIX received /48 IPv6 IXP allocation from APNIC. Since April 2003, IIX v6 teams collaborated APJII, CBN, Kabelvision and Indosat, launched IPv6 testbed using OSPF, RIP and BGP routing. Testbed not published until 17 May 2003. All configuration and equipment are temporary established due to the testbed.
This: Topology. This is the design of 17 May, 2003.
We make tunnel to IPv4 and IPv6.
IIX is stand-alone router which only peers to Indosat and CBN.
IIX v6 development: This production phase. December 2006, APJII change IIX-JK2 router to a new Cisco router that provided by TELKOMSEL
January: We configured with two IIX peers is best model due to production base because many ISPs not - in Indonesia, there is no content about the IPv6 so they only provide the network but there is - that's useless because there is no content. So dual stack is best model today.
In 2007, during APRICOT 2007, in Bali, BIZ.Net, one of the IIX v6 peers that does one of the IIX v6 peers tested IP-TV streaming for IIX v6 infrastructure in Bali. And now in January 2008, IIX v6 peers to APJII, IndosatM2, Indosat-INP, F-Root, CBN and D-NET.
This is the IIX v6 configuration. The F-Root is established at 21 December of 2007.
OK, NOC, this all the information. NOC IIX service, ENUM-ID testbed, ID-IP v6 infrastructure connection.
And this is our new location at Cyber Building, first floor, Jakarta.
This: IX infrastructure overview from Indonesia.
OK, any questions?
SPEAKER FROM THE FLOOR:
It seems that your exchanges in different cities are connected, right?
ANDY KURNIAWAN:
Yeah.
SPEAKER FROM THE FLOOR:
So is it one single layer 2 network or do you have layer 3 connection?
ANDY KURNIAWAN:
One single layer 2.
SPEAKER FROM THE FLOOR:
One single layer 2 for all the sites, OK. Interesting. So is it Ethernet over MPLS?
ANDY KURNIAWAN:
Sorry?
SPEAKER FROM THE FLOOR:
Is it ethernet over MPLS connection?
ANDY KURNIAWAN:
MPLS connection is provided by our members.
SPEAKER FROM THE FLOOR:
OK.
ANDY KURNIAWAN:
Thank you.
GAURAB RAJ UPADHAYA:
So we quickly switch to the second presenter from JPIX.
I'll try to pronounce your name - Takabayashi-san.
JPIX update
TAKEJIRO TAKABAYASHI:
Hello. My name is Takejiro Takabayashi from JPIX. Today I'm going to give you an update on my JPIX Japan Internet Exchange.
A little history about JPIX: We were established in July 1997, so last year was the tenth anniversary for us. And we were the first commercial IX in Japan. There was one academic IX: Once it was called NSPIXP. Now it's still running and their name is DIXIE right now. But we're the first commercial IX. So the difference between academic and commercial is that; I'm not saying better support but we have 24-hour support for members and we have some kind of a value-added service. And the service which we are providing right now is the IX port and gigabit port, fast Ethernet port and link aggregation for 10-gig and gigabit port. And also we accept remote access, so that, um, members who cannot, who are not able to get into the co-location can also connect to the JPIX. And, of course, we have co-location service and for the co-lo members we can have them with in-house cables.
Optional services, that's value-added services: We have route confirmation service that allows members can check - we have mirrored IRR database so you can check with the - what kind of prefix you have in the Whois database and a route exchange service. That's a route arbitrary, so that's the route exchange; so it just refracts the routes that peers with our route server. And NTP and SNMP traffic, it's the RRD and sFlow traffic analysis using just like Nigel was presenting for LINX. And our - JPIX is distributed but we have expanded - we have expanded some sites so that customer doesn't have to worry about the local loops; so that if there's enough members for us to get, members get benefit, we'll go out and put switch to the, that location.
And right now, we have about five sites. Unfortunately we have closed down some but now we have five sites in the Tokyo area and we say regional IX but JPIX Nagoya is connected to the Tokyo and JPIX Osaka is standalone; it's fully separated.
And geographically - OK, I'm not - I'm not used to this - OK, Tokyo area is right here and Nagoya is from here to here it's around 400 kilometres, 250 miles, around, and this is connected. And Osaka, from Tokyo to Osaka, it's around 550 kilometres, and it's not connected.
Our network configuration is very simple. And we are going to implement the IPv4 or IPv6 dual stack. We do have a native standalone IPv6 switch right now and, um, 11% of customers who is connected to this native service; but it's just an experimental service and I don't see much traffic there. And, um, but, um, everybody starts asking us for the v6 port, so we decided to go for the dual stack service, with the same switch, the production IPv4 switch. So that we're planning to deploy this on 2008 with the cooperation with Intec NetCore.
And, OK, to start this dual stack service, right now we're doing the test of a couple of things. First, we have, we were planning to write some access lists for the RAs or whatever, so, by routing each ports to the access lists, we'll have to think about the switch performance for that. It should work just fine, but we're going to run that. And, um, management system is just like how we're going to do the surveillance on the system. Route servers I'm going to talk about later. And traffic statistics, that's sFlow. That's from our point of view, sFlow was the only solution to get traffic from the dual stack system. And traffic control: That's a little bit different from an IX standpoint. Addressing: We have to think about addressing too.
And, um, configuration of major vendors' routers. We'll check the major routers, Inter, including our switch. So if we can provide you with some kind of a sample configuration or whatever, that may be helpful so we may do that. And, um, well, if it's useful enough for BCP, then we may try to go for BCP.
And this is - Traffic Viewer - is one of our value-added services, using the traffic analysis, using sFlow. And this is the user interface; and after logging in, you choose whatever router - your router first - OK, you choose your router and then you can choose the options. You can check your traffic between your router to your neighbour, or your peer and you can check the percentage between the, each peers that your interface has and reporting gives you the report of the statistics. That how much your neighbour is using for maximum peaks or volume of the selected target time and you can check how much your traffic is going to the EJS.
You see these tables, traffics. It's fibre net and for using this arrow, you can sort by names, you can sort by AS numbers, IP address, you can sort the traffic volume or packet volume. And this is how the graph comes out.
And many people say it's useful and, um, the hardware spec was not good enough so it was very slow. So we have upgraded new hardware and we tuned some software too, so it's more useful right now. I mean, from March 11 it's going to be more useful.
And, um, this is traffic volume, not current, but when it was February 8, so 20 days ago. It was 85 gig. And once, over here, around October or November 2007, we had once got this spike, once got to the 100 gig and then it just went down and just came up, coming up again. So I don't know what happened in October/November, but I've seen that other IXs has also seen this spike too; so something was going on, I guess.
And number of customers: 115. That is the largest member in Japan. And the port ratio; this is just staying with the member numbers, so it doesn't count 10-gig ports between our sites, but only members. About 70% of the members are still gigabit Internet port and 23% is 10 gigabit Ethernet. So still gigabit Ethernet is our...is still winning.
And this year, what we are going to do? What's next? Is that this time...It's time? OK.
OK, we want to implement 4-octet AS and IPv6 to the route exchange service; that's the route arbitrator and it's already implemented; and we're going to start running this system on March 2008, which is, I mean, middle of March 2008. And IX connection using network cloud carrier service. That is, um, we are going to cooperate with carriers that can provide the stable network that will connect with us without any problems, storms, or whatever. So we're going to do that. And optical switch installation for resiliency, we're going to just install the AB switch, the robotic switch, for all the customers, fibre customers.
Thank you.
GAURAB RAJ UPADHAYA:
Thank you, Takabayashi-san.
APPLAUSE
Any questions?
SPEAKER FROM THE FLOOR:
I have one quick question about the peak traffic. You mentioned 85 gig. Is it a five-minute peak? OK, thank you.
And we forgot to thank Andy also. Thank you, Andy.
APPLAUSE
GAURAB RAJ UPADHAYA:
The slides from this session are now on the conference.apricot.net/slides directory. You can grab it from them. Don't try to do all at the same time. It will probably break again.
JPNAP update
KATSUYASU TOYAMA:
Hello. My name is Katsuyasu Toyama from JPNAP.
And today I'd like to talk about JPNAP update but also I'd like to focus; briefly explain the update part, and also I would like to talk about an availability model of exchange point and availability of JPNAP, OK?
So first, I would like to briefly introduce JPNAP. Takabayashi-san said that JPIX is the commercial exchange point in Japan and also JPNAP is a commercial exchange point in Japan so commercial quality is provided to the ISPs in Japan, OK?
And our exchange point has been available since 2001, just a few years later than JPIX. And we have currently three locations. JPNAP Tokyo I and Tokyo II and Osaka, there are three sites. And these locations, the provider can use for redundancy, for geographical redundancy, the provider can use Tokyo and Osaka and also for the localised risk, providers can use the Tokyo I and Tokyo II. And JPNAP Tokyo II started a trial in this January and also soon the full service will be available. OK.
And Takabayashi-san said that JPIX is 85 gigabit at peak and currently the JPNAP is 145 gigabits at peak, so the largest traffic exchange in Japan, OK?
So a point will be asked later to me or the marketing person from JPNAP is in this room, OK?
So I'd like to talk about presenting an availability model of exchange point, OK.
So, as you know, the exchange point is a very important infrastructure for the providers. So 24/7, it should be available to the customers. So the configuration, or the network architecture, and all the ports for the customers are up and running all the time and there are no packet loss in the core network or the exchange point network, so I think that this is situation, this state, is an availability state. I think that this is - this can - we can define availability of Internet Exchange, OK?
So the not available cases is just like this. Of course, the exchange point network has failed or the switch itself failed is 'not available', but also if only one switch of the port to the customer is not available, that just means that all the services is not available, completely available. This is because this ISP-A, the port for ISP-A is down means affected to the customers, other customers who peer with ISP-A but also and potentially these customers have a possibility to peer with this ISP-A so only one port is down means that ISP exchange point services is not available, I think. OK?
And also, the exchange point in the inside exchange point, the exchange point can be regarded as a very high pipe for the providers. Of course, not unlimited bandwidth can be prepared for the network, but enough bandwidth is; if we prepare enough bandwidth, the providers can regard this as a very high pipe. And, in this case, inside a switch, if there is a packet loss or a link failure in the switch cloud, this service is not complete. So some packet loss or link failure is offered inside a network; this is not available, I think. OK. So these are, I think, the definition of the availability of an exchange point. Again, I summarised all the ports for the customer are up and no packet loss and no link failure in the switch cloud, OK.
So, from this point, JPNAP provided some kind of solution to improve availability.
The first part is a switches and network are redundant. This is our user configuration, OK? We also prepared redundant switches, OK. And so the customers can have a main port and also a backup port. And the second one is an optical switch. This switch can instantaneously change the main port to the backup port, and this switch is always watching the light from the port of the switch; and if the light is going down, it immediately switch to the back-up site. So the time to change to the backup port is in tens of milliseconds, OK?
So this is not...This optical switch works for not only the port failure, but also in the case of the maintenance we can use this one as...We can use this function and change the main port to the backup and reboot these switches or some kind of maintenance in the network. So this one is an important one, OK?
And I'd like to just a case study about the JPNAP. This half year from the July 2007 to December 2007, approximately a half year, we've had...There are several unavailable cases, unavailable events. And this light green one is switch trouble, and this one the maintenance work, and some ones are human error. And some of these events led to the unavailable of the JPNAP.
But the effect of improving the - our solution's effect to show that our - to show, to show solution of the JPNAP, I'd like to focus in on the maintenance work. And this is a very typical one, so it's very good, I think. And if we did not have a redundant network, the IX service would not be available during the maintenance work. So we have four times maintenance works, and one of them is not affected because of the online insertion and the removal can be done so this is not affected to the users. But other maintenance is just like removing a line cards or replacing it, or software upgraded, so this one is affected to the availability of the exchange point if we did not have the redundant network.
So of the total of the time of the impact is, in this case, nine hours and 22 minutes, OK?
And if we only had a redundant switch network, at the time, we have a main port and a backup port. So when we do a maintenance work of removing the main port and from the customers' cable, removing the main port and put...insert again to the backup port, by manually, it takes, for each customer's, such kind of a work takes approximately 30 seconds. So each time, approximately, 10 or 20 and five customers are affected so the downtime is, in this case it's five minutes and in this case it's 10 minutes and in this case it's two minutes and 30 seconds; so totally 17 minutes and 30 seconds would be affected.
But, we have an optical switch for the customer ports, as I said, so we can change the customer's port, so the downtime is approximately only one second, maybe less than one second.
So, to summarise, the downtime in the first case where there is no redundancy, it's nine hours and 23, so the downtime, comparing to the total is 0.0831%. And from the availability point of view, this number. And the second case is 0.0026% and the third case - and this is the current JPNAP configuration - this is 0.0001% downtime, OK? But, as I showed you in the table, the actual availability, including the outage during this period, is 92.9897%. So I've just added some outages here, OK? `
And, as I said, in this case, we have only maintenance work, but if there were the switch port failure, it also downtime with gradually downtime can be reduced, could be reduced to only tens of milliseconds, OK?
So the conclusion, to conclude, I presented an availability model of exchange point and using this model, we calculated JPNAP availability. And JPNAP provides high availability to customers by a redundant switch network and optical switches.
So thank you very much and as I said, please ask the detail about such sort of thing ask me or our sales staff is in this room. Thank you very much.
APPLAUSE
GAURAB RAJ UPADHAYA:
OK? Any questions?
SPEAKER FROM THE FLOOR:
Actually, yeah I do. So are you using the same optical switches that AMS-IX is using? And did you, like, consult with AMS-IX or did you just come up with your own engineering ideas on that? Did you work with AMS-IX on designing the optical switch topology or do it all on JPNAP on its own?
KATSUYASU TOYAMA:
No, we are working independently to AMS-IX. So this is because optical switch is...when we use optical switches, not like in AMS-IX. All the customers is from the main two backup is AMS-IX case. But in our configuration, we are using it port by port. So the one customer can have main and backup, so it's that kind of configuration, so it's slightly different.
SPEAKER FROM THE FLOOR:
OK, thank you.
GAURAB RAJ UPADHAYA:
Any other questions?
Thank you.
Equinix AP update
Next we have Raph with the Equinix Asia Pacific exchange point update.
RAPHAEL HO:
Searching. Ah, found. My X term doesn't want to go away. Ah, there you go.
OK, hi, everybody. It's me again. Today I'm going to give a quick update about the Equinix exchange within Asia and also a brief update on the US side. So, um, what's changed in the last year? You may or may not have heard that we've completed the purchase of IX Europe, which will be wrapped under the Equinix family; and also quite recently we've bought another company called Virtue, based in Amsterdam, and they'll be wrapped under the Equinix name going forward, which brings us to over three million feet of floor space worldwide.
OK, I'll give you some details there of the Equinix exchange and the traffic growth in the region and also in the US. So basically in Asia we have three countries where we have exchanges: One in Japan; and actually there's a distributed fabric over three sites; one in Shinigawa, one in Heiwajima and one in Otemachi. In Asia we have Singapore, and in Australia we have one in Sydney and one in Melbourne. In the US, where, you know, the traffic is going to be a lot more, obviously the main site is in Ashburn, Virginia. We also have exchanges in New York, Chicago, Dallas, in the Silicon Valley and LA at various sites.
So this is a bit of traffic profile on the Japan site. We have over 20 peers at Japan and really we've grown very significantly in the past year. I mean one year ago, we were hitting around one gig and today we're hitting around over eight gigs at peak. So, um, also a little bit about our traffic profile. Our customer profile in Japan. Obviously there are very many established exchanges in Japan that are very successful and so we're carving out a little niche, mainly focusing on the foreign carriers and the foreign content as well. So that seems...that strategy seems to be working quite well. We also do have Japanese content as well at our exchange to peer with the foreign guys, so that's looking quite well and we hope...we've gone up about eight times; so if we go up eight times, we'll be 64 gigs, so that would be nice.
In Singapore, we have over 20 peers, and the customer profile there is we're actually very regional in Singapore. I believe there's actually more international people at our Singapore switch than the locals. It seems like the south east Asian is really using Singapore as a peering hub; so that trend would continue and the traffic would grow as well as they grow with the broadband penetration growing in these areas. Again, we're hitting about 800 meg, compared to about 200 megs at the beginning of the year, so there's very healthy growth in the exchange traffic within Asia. Ideally people would exchange more traffic in Asia as opposed to wrapping around the US, as is the case in some places.
Sydney, again, we're growing, except not at such a fast pace. We started off the year at about 150 and we're hitting around 200. We peaked at about 300 and we lost a peer about then but we've over 40 peers. A lot of it is localised content and localised network so, I mean, for the cost reasons a lot of the international carriers aren't really exchanging all the customer routes and are just announcing local routes because AJC and Southern Cross are so criminally expensive. So that's that.
This is a shot of the aggregate peering bandwidth in the US. So we're hitting over 200 gigs regularly and again over the...
OK, so I guess I should, you know, talk. Everybody's speaking for over 15 minutes so I need to drag this out for another 10.
So after hearing about Geoff Huston's doomsday theory and, you know, Randy Bush, in the US we actually do have an IPv6 product for Equinix exchange. In Asia, we do not.
Can I ask a question and show of hands if anybody is interested in exchanging IPv6 traffic at an Equinix facility. Alright, in that case, I think we should go apply for a micro-allocation or four or three.
Alright, well, I mean that's on my to-do list. And, I've run out of things to talk about.
Any questions?
SPEAKER FROM THE FLOOR:
Can you go to your slide about your exchange traffic in Japan? Why the out traffic is so high than the in traffic?
RAPHAEL HO:
It should be the same, but, you know...
LAUGHTER
There is so problem because we do have multiple territories in there and we don't do multicast. Well, I mean, it's a switch-fabric so some people might be doing multicast but I don't think the traffic difference is done much. This is mainly due to the difference in the architecture we're using. We still have some Cisco stuff inside. We've got some foundries, and the way they send out the Netflow data is a bit different; so you've got a mix of SNMP and Netflow in there. So that's probably the reason. We will, we are moving towards a single platform in the future. We're standardising on the MLX and that should clear things up on the graphs.
I hope that answers your question.
Anybody else? We've still got 10 minutes.
OK, well, thank you very much for your time and I'll pass the microphone back to Gaurab.
GAURAB RAJ UPADHAYA:
Thank you.
OK, thank you to all our speakers once again. We have around 10 minutes left if you want to talk about stuff.
I wanted to bring this up so that...I think all of you are here in the room so please take a look. Slight changes from what we had yesterday or what I had this morning because we had some requests to reset you.
We also have two new submissions. I hope I've got the name right. Thomas, is he still here? Yes? OK.
So this is the agenda for tomorrow. The lightning talk schedules have now been published. We've got five speakers and I think Zhoni is now listing two more. I think we can take one more so if you've got something to talk about, you can still talk to me or Zhoni during the afternoon or evening.
Again a reminder about the APNIC social event. I think the buses will leave from the reception area from the car park behind here. So do you know what time the buses will start leaving? OK, between 6:30 and 7:30, OK, so you'll have to get into the front lobby at 6:30 to get on the bus to go to the social event. APNIC social events are generally fun so I hope to see you there. So if there are not any questions or anything you want to raise in the IX SIG...you're happy to say thank you to all of you. A special thank you to Che-Hoo for being on the IX SIG for many years. Thank you very much.
APPLAUSE
So you've got an hour before the buses will start leaving. Thank you.
The slides from today are all on the web except for Raph's that I'll get and, yes, see you tomorrow morning at lightning talks.
[End of session]
