Routed optical networks

Fri May 5 08:13:29 UTC 2023

On 5/5/23 07:57, Vasilenko Eduard via NANOG wrote:

> Disclaimer: Metaverse has not changed Metro traffic yet. Then …
>
> I am puzzled when people talk about 400GE and Tbps in the Mero context.
>
> For historical reasons, Metro is still about 2*2*10GE (one “2” for 
> redundancy, another “2” for capacity) in the majority of cases worldwide.
>
> How many BRASes serve more than 40000/1.5=27k users in the busy hour?
>
> It means that 50GE is the best interface now for the majority of 
> cases. 2*50GE=100Gbps is good room for growth.
>
> Of course, exceptions could be. I know BRAS that handles 86k 
> subscribers (do not recommend anybody to push the limits – it was so 
> painful).
>
> We have just 2 eyes and look at video content about 22h per week (on 
> average). Our eyes do not permit us to see resolution better than 
> particular for chosen distance (4k for typical TV, HD for smartphones, 
> and so on). Color depth 10bits is enough for the majority, 12bits is 
> sure enough for everybody. 120 frames/sec is enough for everybody. It 
> would never change – it is our genetics.
>
> Fortunately for Carriers, the traffic has a limit. You have probably 
> seen that every year traffic growth % is decreasing. The Internet is 
> stabilizing and approaching the plateau.
>
> How much growth is still awaiting us? 1.5? 1.4? It needs separate 
> research. The result would be tailored for whom would pay for the 
> research.
>
> IMHO: It is not mandatory that 100GE would become massive in the 
> metro. (I know that 100GE is already massive in the DC CLOS)
>
> Additionally, who would pay for this traffic growth? It also limits 
> traffic at some point.
>
> I hope it would happen after we would get our 22h/4k/12bit/120hz.
>
> Now, you could argue that Metaverse would jump and multiply traffic by 
> an additional 2x or 3x. Then 400GE may be needed.
>
> Sorry, but it is speculation yet. It is not a trend like the current 
> (declining) traffic growth.
>

So, it depends on what "metro" means to you.

For an ISP selling connectivity to enterprise customers, it can be a 
bunch of Metro-E routers deployed in various commercial buildings within 
a city. For a content provider, it could be DCI. For a telco, it could 
interconnecting their Active-E/GPON/DSLAM/CMTS network.

Whatever the case, the need for 100Gbps is going to be driven by the 
cost of optics over the distance required. Some operators run 2x 10Gbps 
for resilience/redundancy, while some others run 4x 10Gbps for the same. 
It all depends on the platform you are using. At some point, that 
capacity runs out, especially when you account for fibre outages, and 
you need something larger on one side of the ring mainly to provide 
sufficient bandwidth during failure events on the other side of the 
ring, and not necessarily because you are growing by that much.

Also, if the optics are available and are reasonably priced, why muck 
around with 40Gbps when you can just go straight to 100Gbps? The 
equipment usually can support either.

I'm unaware of any popularity around 50Gbps interfaces, but I also 
probably don't pay too much attention to such nuance :-).

So, it's not that we are seeing organic growth that justifies 100Gbps 
over anything smaller. It's more that the optics are available, they are 
cheap, they can go the distance, and the routers/switches can do the 
speed. At least, for us anyway, that is what is driving the next phase 
of our Metro-E network... going straight from 10Gbps to 100Gbps links, 
not because that is the growth we are seeing from an organic traffic 
standpoint, but because the routers can do it, and it offers us peace of 
mind that we can handle any traffic re-route when one half of the ring 
fails, without dropping packets.

The 400Gbps market will be restricted to mainly content folk linking up 
data centres, as well as some large telco's, for the time being. It is 
not likely to be the norm for the majority of operators who run some 
kind of metro network.

Mark.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20230505/c78fc20e/attachment.html>