[Cerowrt-devel] 800gige

[Michael Richardson]

Mikael Abrahamsson via Cerowrt-devel wrote:
    > Backbone ISPs today are built with lots of parallel links (20x100GE for
    > instance) and then we do L4 hashing for flows across these. This means

got it. inverse multiplexing of flows across *links*

    > We're now going for 100 gigabit/s per lane (it's been going up from 4x2.5G
    > for 10GE to 1x10G, then we went for lane speeds of 10G, 25G, 50G and now
    > we're at 100G per lane), and it seems the 800GE in your link has 8 lanes of
    > that. This means a single L4 flow can be 800GE even though it's in reality
    > 8x100G lanes, as a single packet bits are being sprayed across all the
    > lanes.

Here you talk about *lanes*, and inverse multiplexing of a single frame across *lanes*.
Your allusion to PCI-E is well taken, but if I am completing the analogy, and
the reference to DWDM, I'm thinking that you are talking about 100 gigabit/s
per lambda, with a single frame being inverse multiplexed across lambdas (as lanes).

Did I understand this correctly?

I understand a bit of "because we can".
I also understand that 20 x 800GE parallel links is better than 20 x 100GE
parallel links across the same long-haul (dark) fiber.

But, what is the reason among ISPs to desire enabling a single L4 flow to use more
than 100GE?  Given that it seems that being able to L3 switch 800GE is harder
than switching 8x flows of already L4 ordered 100GE. (Flowlabel!), why pay
the extra price here?

While I can see L2VPN use cases, I can also see that L2VPNs could generate
multiple flows themselves if they wanted.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20200415/24266035/attachment.sig>