[160287] in North American Network Operators' Group
Re: Muni fiber: L1 or L2?
daemon@ATHENA.MIT.EDU (Owen DeLong)
Sun Feb 3 14:54:01 2013
From: Owen DeLong <owen@delong.com>
In-Reply-To: <CAMrdfRzkpULVpRiGVruk=ykZj6mQr-WZgqebYo3TssYGTaceXA@mail.gmail.com>
Date: Sun, 3 Feb 2013 11:53:30 -0800
To: Scott Helms <khelms@zcorum.com>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Feb 2, 2013, at 5:06 PM, Scott Helms <khelms@zcorum.com> wrote:
> Owen,
> I think the confusion I have is that you seem to want to create =
solutions for problems that have already been solved. There is no cost =
effective method of sharing a network at layer 1 since DWDM is expensive =
and requires compatible gear on both sides and no one has enough fiber =
(nor is cheap enough in brand new builds) to simply home run every home =
and maintain that. ISPs that would want to use the shared network in =
general (>95% in my experience) don't want to maintain the access gear =
and since there is no clear way to delineate responsibilities when there =
is an issue its hard.
>=20
>=20
??
Who said anything about sharing the network at L1?
Is it more expensive to home-run every home than to put splitters in the =
neighborhood? Yes. Is it enough more expensive that the tradeoffs cannot =
be overcome? I remain unconvinced.
I'm not sure why you think it would be hard to delineate the =
responsibilities=85 You've got a fiber path maintained by the =
municipality with active equipment maintained by the ISP at each end. If =
the light coming out of the equipment at one end doesn't come out of the =
fiber at the other end, you have a problem in the municipality's domain. =
If the light makes it through in tact, you have a problem in the ISP's =
domain.
There is equipment available that can test that fairly easily.
> The long and short of it is lots of people have tried to L1 sharing =
and its not economical and nothing I've seen here or elsewhere changes =
that. The thing you have to remember is that muni networks have to be =
cost effective and that's not just the capital costs. The operational =
cost in the long term is much greater than the cost of initial gear and =
fiber install.
>=20
We can agree to disagree. A muni network needs to be able to recover its =
costs. The costs of building out and maintaining home-run
fiber are not necessarily that much greater than the costs of building =
out and maintaining fiber at the neighborhood. One option, for
example, would be to have neighborhood B-Boxes where the fiber can =
either be fed into provider-specific splitters (same economy
as existing PON deployments) or cross-connected to fiber on the F1 cable =
going back to the MMR (home-run).
The only additional cost in this system over traditional PON is the =
larger number of fibers required in the F1 cable.
Owen
> On Feb 2, 2013 4:54 PM, "Owen DeLong" <owen@delong.com> wrote:
> It seems that you are (deliberately or otherwise) seriously =
misconstruing what I am saying.
>=20
> I'm saying that if you build an L1 dark fiber system as we have =
described, the purchasers can use it to deploy Ethernet, PON, or any =
other technology.
>=20
> I'm not saying it's how I would build out a PON only system. That was =
never the goal.
>=20
> The goal is to provide a municipal L1 service that can be used by ANY =
provider for ANY service, or as close to that as possible.
>=20
> To make the offering more attractive to low-budget providers, the =
system may also incorporate some L2 services.
>=20
> Owen
>=20
> On Feb 2, 2013, at 1:31 PM, Scott Helms <khelms@zcorum.com> wrote:
>=20
>> Owen,
>>=20
>> Cross connecting at layer 1 is what I'm saying isn't feasible. If =
you want to simply hand them a fiber then sell dark fiber or DWDM ports =
but trying to create an architecture around PON or other splitters won't =
work because PON splitters aren't compatible with other protocols.
>>=20
>>=20
>> On Sat, Feb 2, 2013 at 4:26 PM, Owen DeLong <owen@delong.com> wrote:
>>=20
>> On Feb 2, 2013, at 12:07 PM, Scott Helms <khelms@zcorum.com> wrote:
>>=20
>>> Owen,
>>>=20
>>> A layer 1 architecture isn't going to be an economical option for =
the foreseeable future so opining on its value is a waste of time...its =
simple not feasible now or even 5 years from now because of costs. The =
optimal open access network (with current or near future technology) is =
well known. Its called Ethernet and the methods to do triple play and =
open access are well documented not to mention already in wide spread =
use. Trying to enforce a layer 1 approach would be more expensive than =
the attempts to make this work with Packet Over SONET or even ATM.
>>>=20
>>> What is about a normal Ethernet deployment that you see as a =
negative? What problem are you tying to solve?
>>>=20
>>=20
>> Ethernet works just fine in the L1 solution I've proposed, so I'm not =
sure why you say it isn't economically viable to do so.
>>=20
>> Owen
>>=20
>>>=20
>>> On Sat, Feb 2, 2013 at 1:04 PM, Owen DeLong <owen@delong.com> wrote:
>>>=20
>>> On Feb 2, 2013, at 2:19 AM, Eugen Leitl <eugen@leitl.org> wrote:
>>>=20
>>> > On Fri, Feb 01, 2013 at 04:43:56PM -0800, Leo Bicknell wrote:
>>> >
>>> >> The only place PON made any sense to me was extreme rural areas.
>>> >> If you could go 20km to a splitter and then hit 32 homes ~1km =
away
>>> >> (52km fiber pair length total), that was a win. If the homes are
>>> >> 2km from the CO, 32 pair (64km fiber pair length total) of home
>>> >> runs was cheaper than the savings on fiber, and then the cost of
>>> >> GPON splitters and equipment. I'm trying to figure out if my =
assessment
>>> >> is correct or not...
>>> >
>>> > Is there any specific reason why muni networks don't use 1-10 GBit
>>> > fiber mesh, using L3 switches in DSLAMs on every street corner?
>>>=20
>>> Well, one reason is that, IMHO, the goal here is to provide a =
flexible
>>> L1 platform that will allow multiple competing providers a low =
barrier
>>> to entry to provide a multitude of competitive services.
>>>=20
>>> Owen
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> --=20
>>> Scott Helms=20
>>> Vice President of Technology=20
>>> ZCorum=20
>>> (678) 507-5000=20
>>> --------------------------------=20
>>> http://twitter.com/kscotthelms=20
>>> --------------------------------=20
>>=20
>>=20
>>=20
>>=20
>> --=20
>> Scott Helms=20
>> Vice President of Technology=20
>> ZCorum=20
>> (678) 507-5000=20
>> --------------------------------=20
>> http://twitter.com/kscotthelms=20
>> --------------------------------=20
>=20
