Hi Dave,
To follow you on this tangent ;)
I have come to the conclusion that the question about whether PtP is better or
GPON heavily depends on who is paying.
For a local community like Amsterdam the goal probably was to be able to
accommodate as many possible network topologies as possible so that the ISPs
that were supposed rent the "dark fiber" can implement any topology they
desire. And since it is trivial to use a passive splitter in the CO building to
reduce PtP to PtMP, PtP is the way to go.
For an (incumbent) ISP however, especially a heavily regulated one, the goal is
slightly different: build the cheapest network allowing to sell the desired
speed-grades while makeing sharing as hard as possible.
The cost of the build-out becomes more important (ISPs are typically publicly
traded and have much shorter amortization horizons than a city government (I
blame the short-sightedness of investors and the way management pay typically
is linked to short-term stock performance, but I digress)) and I have seen
numbers that show that GPON gear really is cheaper than AON gear for the same
number of customers (it also is less capable, but that is beside the point).
But the kicker, at least in Germany seems to be that the incumbent really
really wants to avoid to end in a situation where it can be forced to hand over
physical last-mile links to the competition, exactly what is possible with a
PtP set-up (the competitor puts its own fiber ethernet switch into the CO, and
the ISP that build the network only gets a tiny fixed "rent" per month).
Finally the GPON standards are made by ITU and hence by the telco community
while ethernet is in the hands of the ieee and telco's have less standing there
to get their wishes, but I am not sure how important that point really is.
My conclusion is, that it seems immensely sub-optimal to have incumbent ISPs do
the local network build-out as what they will build is not ideally suited to
what the community served actually wants. This conclusion is also backed by the
number of state laws that have cropped up over time making community-initiated
and financed network build-out as hard as possible, indicating that the telco
lobbyists share my assessment about which network ownership (and topology)
actually serves the end-customers best ;)
Best Regards
Sebastian
> On Jul 23, 2018, at 16:56, Dave Taht <[email protected]> wrote:
>
> Great info, thx. Using this opportunity to rant about city-wid
> networks, I'd have done something so different
> than what the governments and ISPs have inflicted on us, substituting
> redundancy for reliability.
>
> I'd have used bog standard ethernet over fiber instead of gpon. The
> only advantages to gpon were that it was a standard normal folk
> (still) can't use, it offered encryption to the co-lo, and the gpon
> splitter at the neighborhood cabinett could be unpowered, and a
> telco-like design could be made telco-level reliable.Theoretically. In
> reality it constrains the market and raises the price of gpon capable
> gear enormously, thus creating a cost for the isp and a healthy profit
> margin for the fiber vendor.
>
> Neighborhood cabinets would be cross connected north, east, west,
> south, uplink1, uplink2, thus rendering the entire network immune to
> fiber cuts and other disruptions of service and allowing competition
> for service from multiple isps. Fiber or copper or wireless (cell) to
> the building from there. Your neighbor would be one hop away. Local
> cellular or wifi would spring out of smaller towers distributed above
> those cabinets.
>
> Lest you think I'm entirely insane, that's how amsterdam's network was
> built out 10+ years ago.
> https://arstechnica.com/tech-policy/2010/03/how-amsterdam-was-wired-for-open-access-fiber/
>
> I'd have avoided MPLS, and gone with something like 64xlat to deal
> with the ipv4 distribution problem. There'd be a secure routing
> protocol holding the city-wide network together. And there'd be
> ponies. Lots of ponies.
> _______________________________________________
> Cake mailing list
> [email protected]
> https://lists.bufferbloat.net/listinfo/cake
_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake