Yes please... On a side note, I'm presenting at the Commerce Commission conference on demand issues with regard to the UFB and note the ComCom has decided that peering isn't an issue - any/all input on that matter would be gratefully received. Paul Sent from my iPad On 1/02/2012, at 2:41 AM, "Liam Farr" mailto:liamfarr(a)me.com> wrote: Hi, Would also be interesting for us non conference goers :) -- Liam Farr On Tuesday, 31 January 2012 at 10:47 PM, jamie baddeley wrote: Hey Andy, Thanks for that update on the NZIX exchanges at the conference. There was some good things in there that I felt didn't get all the discussion it necessarily deserved. Do you fancy posting that preso, or perhaps a link to it somewhere in order to provoke further discussion? Cheers Jamie _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nzmailto:NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nzmailto:NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

That's a very good question and one I don't have an answer to... The ComCom has a couple of discussion papers and details on the conference here: http://www.comcom.govt.nz/high-speed-broadband-services-demand-side-study but have said they don't see peering as being an issue in need of discussion with regard to uptake of the UFB. I'm not so sure - keen to understand how peering works today and what plans are in place for changes (good or bad) under UFB (if any at all - it may just be business as usual). Paul ________________________________________ From: nznog-bounces(a)list.waikato.ac.nz [nznog-bounces(a)list.waikato.ac.nz] On Behalf Of Don Gould [don(a)bowenvale.co.nz] Sent: 01 February 2012 09:02 To: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] State of the IX. Is peering, with respect to UFB going to become a new issue? Will the current infrastructure deal with me/whoever showing up and wanting to hand over 40Gb to other .nz providers? ...or is there going to have to be a whole new investment? D On 1/02/2012 6:52 a.m., Paul Brislen wrote:

Yes please...

On a side note, I'm presenting at the Commerce Commission conference on demand issues with regard to the UFB and note the ComCom has decided that peering isn't an issue - any/all input on that matter would be gratefully received.

Paul

Sent from my iPad

On 1/02/2012, at 2:41 AM, "Liam Farr"mailto:liamfarr(a)me.com> wrote:

Hi,

Would also be interesting for us non conference goers :)

-- Liam Farr

On Tuesday, 31 January 2012 at 10:47 PM, jamie baddeley wrote:

Hey Andy,

Thanks for that update on the NZIX exchanges at the conference. There was some good things in there that I felt didn't get all the discussion it necessarily deserved. Do you fancy posting that preso, or perhaps a link to it somewhere in order to provoke further discussion?

Cheers

Jamie _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nzmailto:NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nzmailto:NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

-- Don Gould 31 Acheson Ave Mairehau Christchurch, New Zealand Ph: + 64 3 348 7235 Mobile: + 64 21 114 0699 _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

Joel Wiramu Pauling wrote:

The general attitude towards peering is that:

Peering is an issue for RSPs to deal with in the context of UFB so "is up to the market" to decide.

and as a corollary Transport networks between LFC regions and also "up to the market" to decide.

-

Transport between LFC regions is not among the services an LFC provides. As to whether "current infrastructure" will let you pass 40Gbps to anyone, that will turn out to be a question of where you (and the anyone in question) are. Pieces of fibre capable of carrying 40Gbps (or indeed 100Gbps) or various entertaining aggregations have long been available to those willing to spend money on interfaces. And chassis that will drive interfaces. For reasons including but not limited to latency, I'd expect to see a certain amount of content being hosted close to LFC CO^H^HPOI's. And if that's being done, it may turn out to make sense to put routers into POI's precisely so fibre can be run between parties inside a room. - Donald Neal -- Donald Neal |"Madonna's skill with the camera seems to | extend to her being able to turn it on, High Performance Computing | but not a great deal further." The University of Waikato | - Robbie Collin

On 1/31/2012 1:04 PM, Joel Wiramu Pauling wrote:

The general attitude towards peering is that:

Peering is an issue for RSPs to deal with in the context of UFB so "is up to the market" to decide.

This makes sense. As underwhelmed by the ComCom report as I was, I'm not totally convinced there is a significant peering issue. I'm thinking some kind of statement around market power abuse with regards to peering, but ultimately it is a commercial/market issue and for the most part it seems entirely manageable in New Zealand at this time (and in the immediate-ish future). If someone turned up with 40Gbps of traffic today between two operators, I suspect those two operators would be only two happy to interconnect vigorously. Just think of all that over-cap-charging revenue!

On 1/31/2012 2:31 PM, Jay Daley wrote:

...

I'm thinking some kind of statement around market power abuse with regards to peering, but ultimately it is a commercial/market issue and for the most part it seems entirely manageable in New Zealand at this time (and in the immediate-ish future).

I have an inkling as to why this keeps being raised as an issue. The logic goes like this:

Broadly, I agree with you - hence my comment around (ab)use of market power, but let me add a couple more comments to your explanation. What concerns me around the peering-is-an-issue flag being raised is that it is often raised a serious issue, possibly overshadowing more significant issues. There also seems to be a general lack of understanding about peering, and the current market situation.

Step 2: If the cost of this transit is sufficiently high then the next step is to look at what routes carry the most traffic and see if those routes are local and can be connected to by cheaper means. One way of doing that is with a direct contract with the network that has those routes[1] but the most common way by far is peering with other networks for exchange of *local* traffic.

To be clear, peering often involves contracts.

- We have market segmentation and differential charging between national and international transit, when places like the US and UK just have one product called IP transit that gets you everywhere. - Our transit costs are very high in comparison to the US which is only a cable hop away.

This makes peering potentially a very effective cost reduction strategy in NZ.

Agreed, although from what I understand, peering is less about cost at this point than it is about performance. With the costs of international transit dropping dramatically while apparently domestic transit is not, it can be cheaper to push domestic-transit-destined traffic via international paths -- yet I am not aware of anyone actually doing this, despite it being an oft-repeated myth that domestic traffic can trombone 'via LA' or 'via Australia'.

Recognising this, our ISP/content provider from Step 1 sets out to peer locally to reduce their transit costs and find that in NZ that the market looks like this:

a. Two of the biggest ISPs don't peer, not even with an extremely tight definition of local, though one of them does offer [1] above.

At least one of those operators does peer as far as I can tell. They might not peer openly at the traditional IXPs, but they do peer, on a settlement-free basis. Operators that don't peer, well, short of regulating it, what can you do? I suspect their position in the market might change over time post-UFB.

b. Those same two ISPs are major transit providers in a very small market of suppliers.

In this case I think you mean they're 'major ISPs' rather than 'major transit providers' -- supplying international transit (or not) is not really relevant to domestic peering. Holding a domestic customerbase captive is an issue and we've seen that happen in the past with some of the peering stand-offs that have occurred, and certainly those happen in the global market too.

And hey presto, that's where the problem with peering is.

Yes -- although I'm not sure whether it's really a cost issue, or a performance issue. Or a mix of both. Right now there are options for those operators who want peer with the majority of the NZ marketplace[1].

What should be clear from this though is that peering is a second-order problem and the first-order problem that should be tackled is the high cost of transit and the ridiculous market segmentation. In the US transit costs are so low that many transit buyers don't need to bother with peering.

Agreed for the most part. I don't think it's entirely feasible to draw direct parallels between the US market and NZ. That said international transit doesn't seem to be as significant an issue in recent years than in the past, so progress is definitely being made on that front. aj [1] by prefixes, and probably by traffic.

I've snipped a few bits to make this easier to read. On 1/02/2012, at 11:49 AM, Alastair Johnson wrote:

What concerns me around the peering-is-an-issue flag being raised is that it is often raised a serious issue, possibly overshadowing more significant issues. There also seems to be a general lack of understanding about peering, and the current market situation.

I agree and would suggest that the more significant issue being overshadowed is the cost of transit.

...

Step 2: If the cost of this transit is sufficiently high then the next step is to look at what routes carry the most traffic and see if those routes are local and can be connected to by cheaper means. One way of doing that is with a direct contract with the network that has those routes[1] but the most common way by far is peering with other networks for exchange of *local* traffic.

To be clear, peering often involves contracts.

Yes I should have been clearer that I was differentiating between one party paying and settlement free.

Agreed, although from what I understand, peering is less about cost at this point than it is about performance. With the costs of international transit dropping dramatically while apparently domestic transit is not, it can be cheaper to push domestic-transit-destined traffic via international paths -- yet I am not aware of anyone actually doing this, despite it being an oft-repeated myth that domestic traffic can trombone 'via LA' or 'via Australia'.

Performance is only an issue because of the poor state of the NZ IXs, but with those being tidied up that should cease to be an issue over time. The tromboning you mention does not have to be actively configured, it is the default route for any content hosted in Auckland (so avoiding any national transit) that is pulled by another network where the two networks don't exchange traffic and neither do their NZ-based upstreams. This can only be prevented if all the resellers of SX bandwidth exchange with every other. Does anyone know if that is the case? What I know does happen from speaking to content providers is that some find it sufficiently cheaper to host their content in the US than in NZ, even though that content has originated in NZ.

...

Recognising this, our ISP/content provider from Step 1 sets out to peer locally to reduce their transit costs and find that in NZ that the market looks like this:

a. Two of the biggest ISPs don't peer, not even with an extremely tight definition of local, though one of them does offer [1] above.

At least one of those operators does peer as far as I can tell. They might not peer openly at the traditional IXPs, but they do peer, on a settlement-free basis.

From what I gather, and please correct me if I'm wrong here, if you do peer with them you have to pay their capital costs and so, while it might appear settlement-free it isn't really. Besides which you've had to pay far higher capital costs to get there than them since they basically put the peering points where it suits them the most.

Operators that don't peer, well, short of regulating it, what can you do? I suspect their position in the market might change over time post-UFB.

That would be tackling the wrong problem.

...

b. Those same two ISPs are major transit providers in a very small market of suppliers.

In this case I think you mean they're 'major ISPs' rather than 'major transit providers' -- supplying international transit (or not) is not really relevant to domestic peering. Holding a domestic customerbase captive is an issue and we've seen that happen in the past with some of the peering stand-offs that have occurred, and certainly those happen in the global market too.

I did mean 'major transit providers' but only in the context of the NZ market and I take your point that holding a customerbase captive is another factor at play. cheers Jay -- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840

On 1/02/2012, at 11:31 AM, Jay Daley wrote:

a. Two of the biggest ISPs don't peer, not even with an extremely tight definition of local, though one of them does offer [1] above.

Bzzt. Wrong. Sorry Jay. FX peers with Telecom Wholesale. As does Orcon I believe. http://computerworld.co.nz/news.nsf/news/orcon-to-peer-with-telecom-telstrac... http://www.telecomwholesale.co.nz/local_peering Jamie.

On Wed, 1 Feb 2012, Jamie Baddeley wrote:

On 1/02/2012, at 11:31 AM, Jay Daley wrote:

...

a. Two of the biggest ISPs don't peer, not even with an extremely tight definition of local, though one of them does offer [1] above.

Bzzt. Wrong. Sorry Jay.

FX peers with Telecom Wholesale. As does Orcon I believe.

http://computerworld.co.nz/news.nsf/news/orcon-to-peer-with-telecom-telstrac...

http://www.telecomwholesale.co.nz/local_peering

Note in the PDF which customers are *not* included. Traffic not initially included: Corporate Internet Direct (CID) Global Gateway International (GGI) One Office Remote Office LLU Backhaul Telecom Dial-up Secure Business Internet Telecom Hosted applications School Zone Downstream GGI domestic Any customers with static IP addresses Note the requirement to have a 24x7 NOC. You can get pretty big these days without having one. I suspect there are several in the top 50 largest websites in the world (eg Wikipedia, craigslist, reddit ). -- Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT.

Which catagories of

Isn't the main reason you'd want to peer to enable you to get all traffic? especially when the barrier to entry for local peering is high due to needed your own inter metro capacity? Cheers, Bill On Wed, 1 Feb 2012 13:22:46 +1300, Wayne Kampjes wrote: traffic in that list do you think should be incuded in a local Internet peering?

Cheers Wayne

-----Original Message----- From:

nznog-bounces(a)list.waikato.ac.nz [1] [mailto:nznog-bounces(a)list.waikato.ac.nz [2]] On Behalf Of Simon Lyall

Sent: Wednesday, 1 February 2012 12:39

To: nznog(a)list.waikato.ac.nz [3] Subject: Re: [nznog] State of the IX.

Note in the PDF which customers are *not* included.

Traffic not initially included:

Corporate Internet Direct (CID)

Global Gateway International (GGI)

One Office

Remote Office LLU Backhaul Telecom Dial-up Secure Business Internet Telecom Hosted applications School Zone

Downstream GGI domestic

Any customers with static IP addresses

Note the requirement to have a 24x7 NOC. You can get pretty big these

days without having one. I suspect there are several in the top 50 largest

websites in the world (eg Wikipedia, craigslist, reddit ).

Links: ------ [1] mailto:nznog-bounces(a)list.waikato.ac.nz [2] mailto:nznog-bounces(a)list.waikato.ac.nz [3] mailto:nznog(a)list.waikato.ac.nz

Mostly what Mark says.

From my point of view I have a lot of traffic during the day to business customers. For example the Ministry of Social Development is on 202.27.55.0/24 and is a "Telecom"[1] customer.

I would expect them to be included if I was in a "peering" agreement with Telecom. Seriously this Global Gateway[2] vs Telecom thing may make a lot of sense within Telecom but to the rest of the world it is just another entity and policy that has to be worked though. To encourage providers to host in New Zealand (especially if somebody like Amazon comes into Australia) then it really has to be cheap and simple. You have to be able to say "Pay around $2000/month to somebody to host a rack and then $1000/month for a GE on APE and your reach 99% of New Zealand sites". Each stage you make it harder than that will greatly reduce the number of people who will bother. [1] - As in the originating AS is 4648. [2] - Note the URL - http://www.telecom.co.nz/globalgateway On Wed, 1 Feb 2012, Wayne Kampjes wrote:

I suppose what I was probing was the understanding of the products. CID and SBI are layer 2 products, not sure how you peer layer2 internet access. One office and Remote office aren't 'Internet' products - they are VPNs so I don't think the customers woul be happy to have Telecom 'peer'. GGI (international and domestic) - a story in their own right but wouldn't be covered by the Telecom peering being discussed as it isn't 'Telecom" traffic - it is 'GGI' traffic (a seperate business unit? School Zone - a partial VN, partial Internet access. Maybe too hard? I personally haven't thought about it. Dial-up - sits on a differant platform so was probably not considered worth the effort given the traffic levels. LLU backhaul - how do you 'peer' a backhaul? Layer 2 sent from a DSLAM to the Access Seeker? No idea about Telecom Hosted Applications.   My opinions anyway.   Cheers Wayne

________________________________________________________________________________________________________________________________ From: nznog-bounces(a)list.waikato.ac.nz [mailto:nznog-bounces(a)list.waikato.ac.nz] On Behalf Of Bill Walker Sent: Wednesday, 1 February 2012 01:32 To: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] State of the IX.

Isn't the main reason you'd want to peer to enable you to get all traffic? especially when the barrier to entry for local peering is high due to needed your own inter metro capacity?

Cheers,

Bill

On Wed, 1 Feb 2012 13:22:46 +1300, Wayne Kampjes wrote:

Which catagories of traffic in that list do you think should be incuded in a local Internet peering?

Cheers Wayne

-----Original Message----- From: nznog-bounces(a)list.waikato.ac.nz [mailto:nznog-bounces(a)list.waikato.ac.nz] On Behalf Of Simon Lyall Sent: Wednesday, 1 February 2012 12:39 To: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] State of the IX.

Note in the PDF which customers are *not* included.

Traffic not initially included: Corporate Internet Direct (CID) Global Gateway International (GGI) One Office Remote Office LLU Backhaul Telecom Dial-up Secure Business Internet Telecom Hosted applications School Zone Downstream GGI domestic Any customers with static IP addresses

Note the requirement to have a 24x7 NOC. You can get pretty big these days without having one. I suspect there are several in the top 50 largest websites in the world (eg Wikipedia, craigslist, reddit ).

 

 

-- Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT.

At 04:23 p.m. 1/02/2012, Matthew Moyle-Croft wrote: <snip>

Again, the deep problem is that everytime there is a level of complexity or barrier another party will turn away and deliver you content from outside of NZ thus raising costs for everyone.

FWIW everyone watching the NZNOG conference webcast was watching via servers outside of NZ. We gave up and moved to a global CDN. The ingest point was Sydney. Actually there were 2 CDNs, both outside NZ, if we did mobile phones.....memory fade, or lack of sleep. And a further point is that most events we produce have a global audience. For NZNOG the stats currently show that NZ Viewers were only 37% of the audience, which was from 94 countries. NZ audience was 1400, and large audiences in US , Australia, UK, Ireland, etc. I suspect the folks from Moldova and Iran are stats noise. We think the triathlon folks from the Saturday before, were looking for more content........ We'll dig a little deeper.

On Wed, Feb 01, 2012 at 01:22:46PM +1300, Wayne Kampjes said:

Which catagories of traffic in that list do you think should be incuded in a local Internet peering?

Any customers with static IP addresses

I've no idea if it is still the case, but a couple of years ago the design of the TC Wholesale local peering product meant that customers on static IP's out in DSL land saw your announcements, and so you got packets from them, but Telecom provided no route back to them *via the same service*. So static IP address customers were only *half* excluded - you needed an alternate transit path to be able to give packets back to Telecom, or you risked blackholing a significant number of users. From memory, static IP's made up something like 50% of the traffic for the CBD exchanges, and maybe 30% overall. That path asymmetry was another reason why the local peering service looked OK on paper, but in practice was pretty hard to utilise sanely. There was muttering within TCNZ about sorting out a better solution for the static IP users, I haven't heard if anything came of that. My naive view was that localising a nationwide service didn't look particularly easy without renumbering the punters, or giving up some transit, presumably neither of which were palatable for TCNZ. Cheers Simon (who is bummed that he missed NZNOG, OTOH, I've a nice new baby boy to cuddle :-) -- Simon Blake simon(a)katipo.co.nz Geek for hire

On 1/31/2012 2:54 PM, Matthew Moyle-Croft wrote:

The market though isn't just the inward looking market (ie. within telcos in NZ). The actual market is much broader and important.

NZ is a small market. For an entrant to come into the market from outside they need to be able to access a very high percentage of your broadband services *at a reasonable cost in country* to be able to make the numbers work.

Those are entirely valid points, and not something I had considered til you raised it.

If there's a significant barrier to in-country peering then they will stay out of the country. It's like protectionism. It raises the cost of connectivity for everyone across the board.

So, this means people like Amazon, Google, Limelight, Microsoft etc (ie. the big content players) won't ever setup inside you country. (Think how important they are these days in terms of bandwidth).

Valid points, although indicators have been that those operators are less likely to build directly into New Zealand anyway. As you point out, NZ is a small market and [un]fortunately it is very close to Australia. Building an Australian east coast POP that also serves New Zealand, and -often picks up all the New Zealand routes via peering- in that location is very typical for those operators. They then save on the costs of deploying POPs in New Zealand (power, colo, travel, support, etc), and mostly don't suffer any negative performance consequences to the end user, assuming NZ ISPs aren't congesting their international connectivity, or are able to cost-effectively peer on the Australian east coast.

ie. the market is broader than between domestic ISPs.

I'd argue therefore the report has gotten it wrong as it's not understood what the market is nor why that's important.

Agreed. And that's really good feedback for the report -- I hope the authors are reading and consider that content attraction aspect. I do recall it being discussed inside InternetNZ last year, and some of the points raised by you (and the ones I mention above) were the ones given by those content players.

Yes! Sent from my iPhone On 8/02/2012, at 5:09 PM, "Andy Linton" wrote:

I've posted the slides I used at NZNOG at http://nzix.net/IXes.pdf

In summary:

The current system requires CityLink staff to process the updates posted to the relevant IX Change Routes page e.g. http://wix.nzix.net/cgi-bin/ChangeRoutes.cgi and this also creates work for staff at the ISPs requesting the changes. It also creates a number of updates to this list which are probably ignored by most of you.

We intend to change the scripts that generate the IPv4 Route Server configs as follows:

1) Construct a basic filter list that excludes 'bogons', default and prefixes over /24 e.g.

! Bogon filters made from Team Cymru data ! Retrieved 'http://www.team-cymru.org/Services/Bogons/bogon-bn-agg.txt' (159 by tes) ip prefix-list filtered-routes seq 5 deny 0.0.0.0/8 ip prefix-list filtered-routes seq 10 deny 10.0.0.0/8 ip prefix-list filtered-routes seq 15 deny 127.0.0.0/8 ip prefix-list filtered-routes seq 20 deny 169.254.0.0/16 ip prefix-list filtered-routes seq 25 deny 172.16.0.0/12 ip prefix-list filtered-routes seq 30 deny 192.0.0.0/24 ip prefix-list filtered-routes seq 35 deny 192.0.2.0/24 ip prefix-list filtered-routes seq 40 deny 192.168.0.0/16 ip prefix-list filtered-routes seq 45 deny 198.18.0.0/15 ip prefix-list filtered-routes seq 50 deny 198.51.100.0/24 ip prefix-list filtered-routes seq 55 deny 203.0.113.0/24 ip prefix-list filtered-routes seq 60 deny 224.0.0.0/3 ! ! Don't allow default or prefixes over /24 ! ip prefix-list filtered-routes seq 65 deny 0.0.0.0/32 ip prefix-list filtered-routes seq 70 permit 0.0.0.0/0 le 24

2) Construct a bgp setup for each peer that looks like this:

!++++++++++++++++++++++++++++++++++++++++++++++++++++++ ! BGP setup for 'citylink-corp-wn014-rt1' !++++++++++++++++++++++++++++++++++++++++++++++++++++++ ! router bgp 9439 neighbor 202.7.0.221 remote-as 132040 neighbor 202.7.0.221 description citylink-corp-wn014-rt1 neighbor 202.7.0.221 transparent-nexthop neighbor 202.7.0.221 remove-private-AS neighbor 202.7.0.221 prefix-list filtered-routes in neighbor 202.7.0.221 prefix-list filtered-routes out neighbor 202.7.0.221 maximum-prefix 2000 neighbor 202.7.0.221 passive exit

3) Include AS path filtering to exclude routes that have leaked from the other NZ exchanges.

We'll also be doing similar things with the IPv6 Route Servers using /48 as the relevant prefix size.

What will this mean for you if you peer with the route servers?

1) You won't need to update your filters when you add/change/delete networks. 2) If you advertise prefixes from /25 to /29 to the route servers they won't be accepted. 3) If you've been using longer prefixes to do traffic engineering, you'll need to do something else. 4) You'll need to take more care with what routes you send to the Route Servers and with what routes you accept from them.

Why are we doing this?

To make things more straightforward and save costs.

When do we plan to do this?

Soon. Like this month - so if you've got issues with this then please contact us directly at peering(a)citylink.co.nz

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

On Wed, 8 Feb 2012 17:48:13 +1300, Michael Fincham wrote:

On Wed, 08 Feb 2012 17:08:25 +1300, Andy Linton wrote:

...

4) You'll need to take more care with what routes you send to the Route Servers and with what routes you accept from them.

Are there any plans to operate a mailing list (or something along those lines) for people wishing to announce their intentions to announce additional prefixes?

Oops, looking at the slides PDF I think I've answered my own question.

From the PDF:

"We propose a mailing list for exchange participants only for communication including bilateral peering requests" -- -Michael Fincham System Administrator, Unleash www.unleash.co.nz Phone: 0800 750 250 DDI: 03 978 1223 Mobile: 027 666 4482

On 8/02/12 17:54 , Matthew Moyle-Croft wrote:

On 08/02/2012, at 3:22 PM, Michael Fincham wrote:

...

On Wed, 8 Feb 2012 17:48:13 +1300, Michael Fincham wrote:

...

On Wed, 08 Feb 2012 17:08:25 +1300, Andy Linton wrote:

...

4) You'll need to take more care with what routes you send to the Route Servers and with what routes you accept from them.

Are there any plans to operate a mailing list (or something along those lines) for people wishing to announce their intentions to announce additional prefixes?

Oops, looking at the slides PDF I think I've answered my own question.

From the PDF:

"We propose a mailing list for exchange participants only for communication including bilateral peering requests"

You wouldn't normally ask for bilateral peering on an email list?

You might signal your intention to others there.

On 8/02/2012, at 6:08 PM, Matthew Moyle-Croft wrote:

On 08/02/2012, at 3:36 PM, Andy Linton wrote:

...

On 8/02/12 17:54 , Matthew Moyle-Croft wrote:

...

On 08/02/2012, at 3:22 PM, Michael Fincham wrote:

...

From the PDF:

"We propose a mailing list for exchange participants only for communication including bilateral peering requests"

You wouldn't normally ask for bilateral peering on an email list?

You might signal your intention to others there.

I can see you might ask who to ask for those networks who aren't clueful enough to be in peeringdb.com (*hint*) but I've never asked for bilateral peering on a mailing list (only have experience of 23 peering points on 5 continents though).

You're pretty new to NZ though. We've got a very rich history of lots of local peering and are very much open about it, so someone sending a message saying "Hey anyone want to set up some private peering sessions" isn't at all weird to me. We (as a country, historically) don't really put much effort in to figuring out if someone has lots of prefixes or whatever, if they're there and willing, we peer. As for the value of private peering, that's up to individuals orgs to decide. Personally I believe IX RSs peering is just fine. -- Nathan Ward

On 8/02/2012, at 6:37 PM, Matthew Moyle-Croft wrote:

On 08/02/2012, at 3:50 PM, Nathan Ward wrote:

...

On 8/02/2012, at 6:08 PM, Matthew Moyle-Croft wrote:

...

On 08/02/2012, at 3:36 PM, Andy Linton wrote:

...

On 8/02/12 17:54 , Matthew Moyle-Croft wrote:

...

On 08/02/2012, at 3:22 PM, Michael Fincham wrote:

You're pretty new to NZ though. We've got a very rich history of lots of local peering and are very much open about it, so someone sending a message saying "Hey anyone want to set up some private peering sessions" isn't at all weird to me. We (as a country, historically) don't really put much effort in to figuring out if someone has lots of prefixes or whatever, if they're there and willing, we peer.

Sorry if I came across as rude, wasn't my desire. I have, at previous employers, been connected to APE FWIW. Finding out good information was a tricky issue.

I do see NZ as having a good camaraderie that is lacking in some countries, but I guess my main point is you don't want to be too different, too clubby if you want to encourage outsiders to join. NZ does need to lower barriers to entry (even if perceived) to ensure that others don't bypass your beautiful country.

Totally, and peeringdb vs. ML should be "and" not "or".

...

As for the value of private peering, that's up to individuals orgs to decide. Personally I believe IX RSs peering is just fine.

RSes have their own benefits and problems.

Yep.

On 8/02/12 17:52 , Michael Fincham wrote:

On Wed, 8 Feb 2012 17:48:13 +1300, Michael Fincham wrote:

...

On Wed, 08 Feb 2012 17:08:25 +1300, Andy Linton wrote:

...

4) You'll need to take more care with what routes you send to the Route Servers and with what routes you accept from them.

Are there any plans to operate a mailing list (or something along those lines) for people wishing to announce their intentions to announce additional prefixes?

Oops, looking at the slides PDF I think I've answered my own question.

From the PDF:

"We propose a mailing list for exchange participants only for communication including bilateral peering requests"

We not only propose - we've created: http://lists.citylink.co.nz/mailman/listinfo/nzix-route-announce

On 21/02/12 04:50 , Michael Fincham wrote:

On Wed, 08 Feb 2012 17:08:25 +1300, Andy Linton wrote:

...

4) You'll need to take more care with what routes you send to the Route Servers and with what routes you accept from them.

Is anyone on the list interested in the possibility of an RRDB in any form?

Even if it was operated as a community project outside of Citylink I think I can see value in it for the NZ IXes.

I'd suggest that rather than start operating another RRDB in New Zealand it really makes sense to start using the APNIC database for this. Or alternatively start thinking about how we could use RPKI to authenticate announcements. Either way it means there's a datasource which is updated by the IX participants. I've no problem that such a source could be used to help with IX management.

Slightly related, this was posted only in the last few hours: http://mailman.nanog.org/pipermail/nanog/2012-February/044747.html (Did this inspire your comments Jamie or is it just remarkably coincidental?) This and the followups tell the truth about IRRs, I think; effective when used, but it's only the good players who use them properly. NZ being largely made up of good players, perhaps it would add value, if only when dealing with the US-based types who would be able to use it as another positive reputational move? (still, to this day, finding providers in the USA and Canada who muck with TCP coming out of NZ due to the poor reputations of our more Asian-centric counterparts also taking APNIC delegations). Mark. On 01/02/12 23:30, jamie baddeley wrote:

thanks.

I was pondering the lack of interest expressed by the conference in adopting IRR entries. Back in the day when we deployed the anycast network for the geonet reporting system, we ran into our the geonet prefix not being picked up by US peers. We loaded that prefix into IRR and up things came as the US folks auto build their import filters at the peering points based on what's in the IRR registries.

Got me wondering whether NZ Purchasers of Internet transit to the US are getting the full benefits of their service (i.e. their foreign peers picking up all prefixes) as we'd be relying on the transit providers to create the IRR proxy objects.

Populating IRR for kiwi providers is an extra step, but I do wonder if it'd result in shorter paths stateside (assuming the international transit guys aren't as sharp on proxy objects as we'd like)

I'm not an Ops guy now - there's far smarter guys than me in the team to do that now. But my take is populating the IRR is it is best practice to do so, and every step we take to improve latency is a good thing right?

Isn't the other thing is that populating the IRR is the 1st step towards what seems to be a plan to prevent prefix hijacking with RPKI? Where's that whole initiative at these days?

On 01/02/12 23:49, Matthew Moyle-Croft wrote:

On 01/02/2012, at 9:15 PM, Mark Foster wrote:

...

(still, to this day, finding providers in the USA and Canada who muck with TCP coming out of NZ due to the poor reputations of our more Asian-centric counterparts also taking APNIC delegations). Can you explain this a bit more?

In recent times (and longer ago, and across most of my previous jobs in the last 10 years or so) I have frequently found that American organisations find it easier to block large parts of APNIC in the guise of 'security' and overlook the fact that they do business with .nz and .au. Apparently it's easier to block at the /8 or even /16 than it is to apply other measures to protect ones network. This is particularly fun when you can't email them due to said blocks... I think I'm cynical enough now to think that there's plenty of large North American corporates who simply don't care (or are oblivious) about the collateral damage in terms of lost trade with New Zealand and Australia in particular, because of a perceived threat originating from .cn, .kr, etc. As a result i'm never particularly surprised to wind up revisiting this issue at least annually, and spending disproportionate amounts of time and money (using the likes of hotmail or gmail to bypass the blocks, making toll calls to overseas technical support lines (and then trying to actually find someone with the relevant cloo and clout to fix it)) trying to get the filters relaxed sufficiently that we (my org, or my customers) can correspond or trade with them. Mark.

On 2/02/2012 11:44 a.m., Matthew Moyle-Croft wrote:

On 02/02/2012, at 6:59 AM, Mark Foster wrote:

...

On 01/02/12 23:49, Matthew Moyle-Croft wrote:

...

On 01/02/2012, at 9:15 PM, Mark Foster wrote:

...

(still, to this day, finding providers in the USA and Canada who muck with TCP coming out of NZ due to the poor reputations of our more Asian-centric counterparts also taking APNIC delegations). Can you explain this a bit more?

In recent times (and longer ago, and across most of my previous jobs in the last 10 years or so) I have frequently found that American organisations find it easier to block large parts of APNIC in the guise of 'security' and overlook the fact that they do business with .nz and .au. Apparently it's easier to block at the /8 or even /16 than it is to apply other measures to protect ones network.

Is it specific to email?

We've seen this for general web content - being unable to view files from remote servers from blocking provider, and users within / beyond that provider being unable to access content from things within our numbers. For example, we can't access this image: www.tourtech.ca/pub/SOPMix.JPG [1], the reason given was 'Ahhh, maybe you are on the RIPE or APNIC networks, you can't see the server from there.' [2] [1] From page at http://forum.cockos.com/showpost.php?p=891942&postcount=8 [2] http://forum.cockos.com/showpost.php?p=892075&postcount=12 Cheers, Gerard

Hi Folks, Since we were discussing peering, I had a crack at mapping existing peering and transit arrangements for many of the larger ISPs present at the APE. Many thanks to the nice tools provided by APE and Hurricane Electric. http://nztelco.com/content/?p=442 The diagram is just an illustration - I'm not sure if there's a way to ever make it completely accurate, but I'd appreciate any updates that can be provided for publication. Cheers, Jon

On Tue, Feb 7, 2012 at 12:32 PM, Dean Pemberton wrote:

I might be wrong here but it looks like some lines go UNDER certain blocks rather than terminating on them. If so that makes it a bit confusing to get information from. There are auto graphing tools about which should fix that.

Dean

Don Gould commented on the same issue. I've fixed it, here: http://db.tt/el4WnNFf Cheers...

Good evening all Does anyone here run a wireless network that covers 7,700 (ish) Ohura Road, Taranaki? A client is shifting up from Oamaru and would like to know if there is some alternative to satellite in the area. Contact me off list. Cheers Stan Rivett ------------------ Netspeed Data Ltd PO Box 5691 Dunedin P: +64 3 481 7245 C: +64 21 323 841 ------------------

Very cool work Jonathan, OT: is that gamil address a throw away that you never check? D On 7/02/2012 11:36 a.m., Jonathan Brewer wrote:

Hi Folks,

Since we were discussing peering, I had a crack at mapping existing peering and transit arrangements for many of the larger ISPs present at the APE. Many thanks to the nice tools provided by APE and Hurricane Electric.

http://nztelco.com/content/?p=442

The diagram is just an illustration - I'm not sure if there's a way to ever make it completely accurate, but I'd appreciate any updates that can be provided for publication.

Cheers,

Jon

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

-- Don Gould 31 Acheson Ave Mairehau Christchurch, New Zealand Ph: + 64 3 348 7235 Mobile: + 64 21 114 0699