> ... but now you are dictating what technology is used, via the active > aggregation equipment (i.e. ADMs) you installed at your nodes on the > ring. Also, the fiber provider now has to maintain and upgrade that > active aggregation equipment, as opposed to just patching fiber from one > port to another. > > The point of this exercise is to design and implement a fiber plant that > can support _any_ technology, including ones that haven't even been > invented yet. >
Active devices are a requirement, the only question is where they live in the CO or in the plant. Putting them in the plant is the lower cost choice in many/most deployments both in the short AND the long term. Active devices of some type will continue to be a requirement, again the only difference is where they are deployed. Swapping out one active device for another happens every day. > If you're going to dictate SONET ADMs, with a fixed set of downstream > connection types, why _not_ build your ring with one pair of fiber? > Hint: the fiber itself is a tiny fraction of the total cost. > I'm not dictating anything, especially NOT SONET. > > You're optimizing the wrong variable as a result of assuming you can > predict what technology will be used 50+ years in the future. > Designing for a fundamental change sounds like a really nice idea, except predicting the requirements for a fundamental change is impossible. Its entirely possible that in 50 years the fiber we're talking about burying isn't the current standard, fiber is no longer the access method of choice, that putting active electronics in the field becomes a requirement, or something else equally unpredictable happens. > > >>> This wasn't always true because we've only had 40G and 100G Ethernet > for carrier networks for a few years. In the past we were limited by how > big of an etherchannel network we could use for the ring. I'd also point > out that the ring architecture is optimal for redundancy since you have > fewer fiber bundles to get cut in the field and any cut to your ring gets > routed around the ring by ERPS (http://en.wikipedia.org/wiki/ERPS) in > less than 50 milliseconds. > >> I infer from that continuation of your thought that you mean the > second: active optical muxes out in the plant. > >> > >> I'm sure I've made clear why that design limits me in ways I don't want > to be limited when building a fiber plant for a 50 year lifetime, but let's > address your responses below. > > The only limitation you have is a limited supply of total fibers (hint, > this is a big reason why its cheaper to build and run). > > Exactly! Lay enough fiber that you don't _need_ aggregation at the > local level, i.e. enough that you can patch _every_ customer connection > directly to their destination of choice without any active aggregation > equipment at all. Every pair of fiber can be running whatever > technology the customer desires, whether that is SONET, Ethernet, or > something else that hasn't even been invented yet. > But that's wasteful in many/most deployments and is more expensive in the short AND the long run. Basically you're betting on a need that doesn't exist at the current rate of bandwidth growth for much more than 50 years and that's assuming that we don't get higher rates of Ethernet or that we can't run CWDM (which we already can). > > > Most customers will buy from a service provider, who lights the fiber. > The point of dark fiber is that the service provider gets to decide how > to light the fiber to said customers, allowing competition based on > innovation. If the fiber owner puts active aggregation equipment in the > path, though, that means the technologies available are dictated by that > equipment's capabilities--and you have introduced another point of > failure into the system. > The statement on reliability is false, that system WILL be there, its just a question of where it is and who owns. I'd argue that sharing at layer 1 reduces reliability because a given set of plant personnel have to deal with many more technologies. I'd also say it leads to MORE service provider lock in since not only does the business have to potentially change IP's but they may have to change (and pay for) the access device. Doing aggregation at layer 2 does limit the technology choices to businesses, but again what business is choosing something other than Ethernet today? What other technologies can you not encapsulate in a VLAN or VPLS? > > > Why should the fiber owner care what they use it for? It's just dark > fiber, patched from one place to another, so the rental price is the > same whether they light it at 10Mb/s or 10x100Gb/s. > > What you're missing is that in this model, _every_ connection is L1 from > the fiber owner's perspective. Let service providers worry about L2 and > above. > Because the plant owner ends up supporting a ton of technologies they don't know. This isn't a unsolvable problem, its simply not an economical way to run a system for most muni operators. > > > Why would the ISP "have to build and maintain a lot of infrastructure"? > All they need is a fiber-capable Ethernet switch in a colo to turn up > their first customer. That's a lot simpler than trying to turn up their > first customer via an ILEC's DSLAM, for instance. > > There's nothing wrong with the muni operating a L2 (or even L3) carrier > of last resort, just to ensure that _some_ useful service is available > to residents. However, it should (a) be priced high enough to attract > competitors and (b) be a distinct entity, treated by the fiber arm as no > different from any other L1 customer. None of the shenanigans like the > ILECs play, where the wholesale rate to competitors is higher than the > retail rate for the ILEC's own service. > The reality is simply different than this. Most muni operators struggle to work support their own systems and if you, as the muni, tell ISP A that the problem is on their side what do you think the response will be? If everything is Ethernet that becomes better, but what happens when someone runs something more exotic? PON is pretty common, but the testers for it cost several thousand dollars. What about the next technology? Who buys the testers? Who pays for tech training at the muni operator? > > > Its an admirable goal, but you're never going to have CCIEs (probably > > not even CCNAs) doing installs. Installation is, has been, and will in > > all likelihood continue to be done by people with limited skill sets. > > You building your own fiber plant and making it easier for ISPs to > > connect isn't going to change that. > > You're missing the simplicity of dark fiber. The carrier orders a L1 > circuit from a customer to their facility. The L1 provider just patches > one fiber pair to another fiber pair, which can be done by a trained > monkey. Then the carrier connects their own equipment to the fiber at > their own facility and at the customer site, everything lights up and > the spice^Wdata flows. Again, that can be done by a trained monkey. > You don't need a CCIE or even a CCNA to do this. Heck, it's even > simpler than what's required today for DSL, cable or satellite installers. > I hate to say it but if you think its this easy I have a bridge I'd like to sell you...the reality is that fiber installs, especially using multiple technologies, are hard. In many ways they're harder than reusing the existing coax or twisted pair since most homes and businesses today don't have fiber pulled to their NID much less inside the home. > > (Note that inside wiring is a completely separate issue, and carriers > _will_ have to train techs on how to do that since few are familiar with > fiber, but that is an optional service they can charge extra for. The > L1 provider's responsibility ends at the NIU on an outside wall, same as > an ILEC's, so it's not their problem in the first place.) > > If it doesn't work do you really think the muni won't get pulled in? > 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 > > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms --------------------------------