Muni fiber: L1 or L2?

Sun Feb 10 20:08:24 UTC 2013

On 02-Feb-13 14:07, Scott Helms wrote:
> 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.

It would be more expensive in the short term, yes.  But forcing the use
of SONET, or ATM, or Ethernet, or any other random technology to save
money in the short term will end up costing you more in the long term. 
You will end up locked into a merry-go-round of upgrades every time
someone invents a "better" technology--or locked into an obsolete
technology because (as is often the case with govt in the US) there is
no funding to upgrade.

You're focused on equipment, which has a 3-5 yr depreciation cycle,
rather than the facilities, which have a 30-50 yr depreciation cycle. 
It's a totally different mindset.

> What is about a normal Ethernet deployment that you see as a negative?

Active equipment in the ONS, limited topology, forced uniformity rather
than innovation, etc.

> What problem are you tying to solve?

The goal at hand is an OSP that will last 50+ years without any
significant change.  Considering the rapid evolution of technology over
the last 10-20 years, the only safe bet is home run fiber.  Let service
providers decide what technology is best to light up said fiber in any
given year.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2381 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20130210/f6475e7d/attachment.bin>