From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id F1E7A3B29E for ; Fri, 14 Jan 2022 15:32:56 -0500 (EST) Received: by mail-ua1-x932.google.com with SMTP id x33so18952190uad.12 for ; Fri, 14 Jan 2022 12:32:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aenertia.net; s=dkimaenertianet; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eu1o+kG6emNDySJbwkizkPRqnkyZ2239OIJpFPxHxmw=; b=LWQi5gzUqMcYNHogbBLW8FaNEo2tDJ6XdlGOiuhbAOmQa25nQNtUBUCKTpk8hugXBS DHoEEuCLQvGNqT8b1zTJgxosFd0VnwAiRk/BoUSPL1ZYyOLv8M91wdVKc/vRUF6rf8Vr 3FPIXOMafKfCFBPevsAE6bG4jmSp3xavBNFSA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eu1o+kG6emNDySJbwkizkPRqnkyZ2239OIJpFPxHxmw=; b=ei0OMs9Wr3E5q62yxgj+NAxnQgN9TIXTiXmYhgsoz7ZiXkuZbwQx90g9gJ/zSzh/Kx 3gdj4SdM6UrzYelafCJ50QNB57E0EkydmVEeKzfqlpoy1Zij20IqrKs8IAjyBgrGvFpc Y5NipVLwJHAYTK40to4kdGCW1NyE7CU4Y7ae2zM/UMMA1RoWZwztFW+r9Iac6O3qpQvd k1A6I3SIEPamt3dhid/Rn81zOokhJX1bd1qxsU0wgdI19dQyaNPaawtum6CjQ6AEQKjb ENRA3MbujN45yHJoHX82JxplrZzwIQc+IX2slf0cADDfqTSgkx21i4eqGEredeOYcS4a /b3w== X-Gm-Message-State: AOAM531uT/qoI4NrO7Q/NHwGntBfA0zIMF+sxHq362XJ3wRGw6Phs7Y1 YKRhLTe8YDz786aWEy+rij9xGhJrEqzgb415XdDuJw== X-Google-Smtp-Source: ABdhPJxos61YHxMsK00ODzyRAGQYgYBz6E625TOM1qtakVb6tfwmHRndhtmNlM21Da1N0RVG/0UO9Cw/E8JfA55FIOc= X-Received: by 2002:a05:6102:38c9:: with SMTP id k9mr3368589vst.25.1642192376298; Fri, 14 Jan 2022 12:32:56 -0800 (PST) MIME-Version: 1.0 References: <6D533A43-C4E9-4D48-BC9B-26630F1E17F5@gmx.de> <4F3A4139-6703-467C-832D-3E27294707CE@gmx.de> <18327.1642188119@localhost> In-Reply-To: <18327.1642188119@localhost> From: =?UTF-8?Q?Joel_Wir=C4=81mu_Pauling?= Date: Sat, 15 Jan 2022 09:32:45 +1300 Message-ID: To: Michael Richardson Cc: =?UTF-8?Q?Jonas_M=C3=A5rtensson?= , Sebastian Moeller , cerowrt-devel Content-Type: multipart/alternative; boundary="0000000000003e3fda05d590b54b" Subject: Re: [Cerowrt-devel] a smart SFP X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2022 20:32:57 -0000 --0000000000003e3fda05d590b54b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Those are really high split rates. We (as in UFB in NZ) looked at 32:1 splits but it's rare - in practice it's often half that. Splits end up based on contention of regulated L2 plans which are sold to RSP's to on-sell to customers. Based on available backhaul bandwidth rather than any factor. i.e on a 2.5Gbit Duplex GPON port which carries a L2 service to RSP(L3 providers) it's a simple matter of dividing up the Active Optical backhaul to the GPON unit (minimally 2x10Gbit Active Paths to the CO for an old style GPON only node) so that gives you around 66 customers on a 300/300 service without resorting to Teletraffic engineering in the access equipment. Splits per line card port are then distributed based on that metric rather than anything else. There are of course some exceptions to this rule for some nodes in the network but it's uncommon. RSP's are responsible once the L2 is handed to them, so experience varies once it's off the access network. But the entire PON network is engineered without contention at any points, including in the last-mile, it actually works out cheaper than introducing engineering required for massive contention ratios and results in better experience for everyone. The active GPON nodes used in the network mostly have been moved to 2 or 4 * 40gbit or 100Gbit uplinks at the this point to support XPON. On Sat, Jan 15, 2022 at 8:22 AM Michael Richardson wrote= : > > Jonas M=C3=A5rtensson wrote: > >> getting gpon more right has increasingly been on my mind > > > I think more right is to not turn the fiber into a shared medium in > the > > first place but since gpon is so popular, improving it seems like a > > nice goal. > > >> Nobody in their right mind is going to hook up 128 terminalt to on= e > >> OLT > > port, I hope... > > > Well, sharing one OLT port between many terminals is kind of the > (only) > > advantage of PON, although split ratios of 32 or 64 are more > > typical. But often it's the loss budget that limits the ratio. > > And, there are also situations, many of them industrial, where the fiber > allows one to avoid ground loops, and where the bandwidth/latency > requirements are very modest. > it's not all youtube downloads and zoom meetings :-) > > I was involved in a GPON build back in 2010 into a very poorly served > industrial park. (That was for email/web browsing by the industries). > A reason they were so poorly served is that there were two expressways (o= ne > of them the TransCanada) and a river that bordered the area. > There were only eight strands in a single conduit available.... > We considered moving (an) OLT into that area actually... DWDM to the resc= ue > in the end, but that was a bit bleeding edge at the time. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | IoT > architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > --0000000000003e3fda05d590b54b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Those are really high split rates. We (as in UFB in NZ) looked = at 32:1 splits but it's rare - in practice it's often half that. Sp= lits end up based on contention of regulated L2 plans which are sold to RSP= 's to on-sell to customers. Based on available backhaul bandwidth rathe= r than any factor. i.e on a 2.5Gbit Duplex GPON port which carries a L2 ser= vice to RSP(L3 providers) it's a simple matter of dividing up the Activ= e Optical backhaul to the GPON unit (minimally 2x10Gbit Active Paths to the= CO for an old style GPON only node) so that gives you around 66 customers = on a 300/300 service without resorting to Teletraffic engineering in the ac= cess equipment. Splits per line card port are then distributed based on tha= t metric rather than anything else. There are of course some exceptions to = this rule for some nodes in the network but it's uncommon.

RSP= 's are responsible once the L2 is handed to them, so experience varies = once it's off the access network. But the entire PON network is enginee= red without contention at any points, including in the last-mile, it actual= ly works out cheaper than introducing engineering required for massive cont= ention ratios and results in better experience for everyone.=C2=A0

The= active GPON nodes used in the network mostly have been moved to 2 or 4 * 4= 0gbit or 100Gbit uplinks at the this point to support XPON.

=

= On Sat, Jan 15, 2022 at 8:22 AM Michael Richardson <mcr@sandelman.ca> wrote:

Jonas M=C3=A5rtensson <martensson.jonas@gmail.com> wrote:
=C2=A0 =C2=A0 >> getting gpon more right has increasingly been on my = mind

=C2=A0 =C2=A0 > I think more right is to not turn the fiber into a share= d medium in the
=C2=A0 =C2=A0 > first place but since gpon is so popular, improving it s= eems like a
=C2=A0 =C2=A0 > nice goal.

=C2=A0 =C2=A0 >> Nobody in their right mind is going to hook up 128 t= erminalt to one
=C2=A0 =C2=A0 >> OLT
=C2=A0 =C2=A0 > port, I hope...

=C2=A0 =C2=A0 > Well, sharing one OLT port between many terminals is kin= d of the (only)
=C2=A0 =C2=A0 > advantage of PON, although split ratios of 32 or 64 are = more
=C2=A0 =C2=A0 > typical. But often it's the loss budget that limits = the ratio.

And, there are also situations, many of them industrial, where the fiber allows one to avoid ground loops, and where the bandwidth/latency
requirements are very modest.
it's not all youtube downloads and zoom meetings :-)

I was involved in a GPON build back in 2010 into a very poorly served
industrial park.=C2=A0 (That was for email/web browsing by the industries).=
A reason they were so poorly served is that there were two expressways (one=
of them the TransCanada) and a river that bordered the area.
There were only eight strands in a single conduit available....
We considered moving (an) OLT into that area actually... DWDM to the rescue=
in the end, but that was a bit bleeding edge at the time.

--
]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Never tell me the o= dds!=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| ipv6 me= sh networks [
]=C2=A0 =C2=A0Michael Richardson, Sandelman Software Works=C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 IoT architect=C2=A0 =C2=A0[
]=C2=A0 =C2=A0 =C2=A0= mcr@sandelman.ca=C2=A0 http://www.sandelman.ca/=C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0ruby on rails=C2=A0 =C2=A0 [

_______________________________________________
Cerowrt-devel mailing list
Ce= rowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-d= evel
--0000000000003e3fda05d590b54b--