[AusNOG] Megaport Suspends Accepting New Orders in PIPE DC's

[Alex Samad - Yieldbroker]

Devil's advocate, what if they are not looking to win, but to delay ..


From: AusNOG [mailto:ausnog-bounces at lists.ausnog.net] On Behalf Of Bevan Slattery
Sent: Tuesday, 14 January 2014 3:31 PM
To: Jake Anderson; Luke Iggleden; ausnog at lists.ausnog.net
Subject: Re: [AusNOG] Megaport Suspends Accepting New Orders in PIPE DC's



On 14/01/2014 12:47 pm, "Jake Anderson" <yahoo at vapourforge.com<mailto:yahoo at vapourforge.com>> wrote:

Its the "Schedule 3 to the Telecommunications Act 1997" part.
Basically megaport aren't asking nicely for access to the DC, they are
using that part of the act to compel the DC to allow them access.
TPG is saying that the people renting rack space aren't "occupiers" and
as such megaport can't use that bit of the act to force them to allow
access.

Correct.  But PIPE historically required carriers to issues LAAN's to deliver services into their facilities as it provided protection under the Act.  PIPE also used to do this as this is how the industry issued notices to each other.  This was the "language" we used between carriers to install in DC's and buildings.

But TPG are saying a couple of things IMHO.

1. The Data Centre LAAN "Own Goal"

TPG/PIPE issued several hundreds of LAAN to other data centres around Australia, data centres with which I expect many would have similar clauses in their agreements.   If TPG's argument now is right, PIPE never had the right to install any of those facilities under previous LAAN's.  Think about that.

2. Minimum Equipment "Own Goal"

TPG/PIPE seem to be arguing that Megaport can only install enough cable/terminations for the initial services.  They actually quote this in their response

"For example, it is my understanding that the TIO has not ever given a ruling that indicates that a carrier may in all instances build as much infrastructure as it chooses to prepare for possible future customers. Obviously, this is a matter that will need to
be considered further."

If TPG/PIPE are successful on this with the TIO then when they rollout their FttB network they may only be able to install the equipment as needed to support those customers who have already signed.  Any future customer (PON or VDSL) may require TPG/PIPE to go back to the site and re-install the discrete components required to complete each new customer service.  This could apply to commercial and FttB/residential.

Additionally TPG/PIPE actually fought and won similar arguments which were made by the building owners and I think also in the landmark Land Access Dispute I started back in http://www.austlii.edu.au/au/cases/cth/FCA/2013/444.html  .

This is a common argument by building owners used AGAINST PIPE and the TIO in my time has always found in PIPE's favour based upon "good engineering practices".  Anyone have a Telstra "Site Light" box?  1000 copper pair installed with MDF in the past 10 years?

So remarkably TPG/PIPE have in this single instance effectively "joined" the building owners and now appear to be supporting their arguments, contrary to their previous (and numerous) representations to the TIO otherwise.  They appear to be potentially supporting all building owners against their FttB rollout.  The same people will be arguing this one at the TIO contrary to their previous arguments in the hope to win against themselves.  Kind of "Win Small and Lose Big".

3.  PIPE facilities are no longer neutral

Last year we were made aware that PIPE/TPG decided not to renew a competing carriers colo agreement which forced them to vacate their colo space and find alternative arrangements to service customers in the PIPE DC's.  PIPE declaring their customers are not able to have services delivered over Schedule 3 and now deciding not to renew commercial arrangements with some competing carriers is not good news.  This is simply the (old) AAPT colo situation all over again.

Irony and History Repeating itself.

(i) The PIPE-v-AAPT experience
In 2003 PIPE had a dispute with AAPT on similar grounds (the old AAPT pre-powertel merger which created the new excellent AAPT).  PIPE went to the Federal Court.  In the meantime PIPE was able to relocate about 82 of the 94 services in AAPT data centres.  Over the following 12 months those data centres (123 Eagle Street, 45 Pirie St, 530 Collins St, 187 Thomas St, 30 Ross St) were effectively vacated by the industry and all have since closed.

(ii) The PIPE-v-Soul experience
In around 2006(?) PIPE issued a LAAN to deliver services into 201 Kent Street (was Soul and now TPG data centre).  Ironically the same occupier argument was used  and the TIO found in favour of PIPE. The service was installed. Again if PIPE/TPG succeed then they may find themselves to have knowingly trespassed hundreds of times...

By way of reference the TIO considered that there were two (2) carriers, however PIPE argued that it was one carrier (PIPE) against a building manager (Soul).  The TIO heard this.  If the argument is that it's two (2) carriers then Schedule 1 applies which would mean Facilities Access and that Megaport has every right to obtain access under an Facilities Access.  Interestingly from memory PIPE argued in the landmark case http://www.austlii.edu.au/au/cases/cth/FCA/2013/444.html that even if Schedule 1 did apply it doesn't over rule Schedule 3 when it applies.  The court agreed.  And when I say PIPE I mean PIPE started the argument when I was there and TPG continued the argument after the sale.

I have pleaded with TPG/PIPE on numerous occasions NOT to open the pandoras box that has just been opened.  Calls were not returned.  The box is now open and I can see all the building owners throughout Australia rubbing their hands in disbelief and eagerly awaiting the first opportunity to use TPG/PIPE's arguments against them regardless of outcome.

Let's see what happens in the TIO and we will keep our customers informed in the meantime.

[b]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20140114/6c8eb3c3/attachment.html>