[c-nsp] Devil's Advocate - Segment Routing, Why?

Saku Ytti saku at ytti.fi
Fri Jun 19 08:40:45 UTC 2020


On Fri, 19 Jun 2020 at 11:35, Mark Tinka <mark.tinka at seacom.mu> wrote:


> > So instead of making it easy for software to generate MPLS packets. We
> > are making it easy for hardware teo generate complex IP packets.
> > Bizarre, but somewhat rational if you start from compute looking out
> > to networks, instead of starting from networks.
>
> Which I totally appreciate and, fundamentally, have nothing against.
>
> My concern is when we, service providers, start to get affected because
> equipment manufacturers need to follow the data centre money hard, often
> at our expense. This is not only in the IP world, but also in the
> Transport world, where service providers are having to buy DWDM gear
> formatted for DCI. Yes, it does work, but it's not without its
> eccentricities.
>
> Cycling, over the past decade, between TRILL, OTV, SPB, FabricPath,
> VXLAN, NV-GRE, ACI... and perhaps even EVPN, there is probably a lesson
> to be learned.

Maybe this is fundamental and unavoidable, maybe some systematic bias
in human thinking drives us towards simple software and complex
hardware.

Is there an alternative future, where we went with Itanium? Where we
have simple hardware and an increasingly complex compiler and
increasingly complex runtime making sure the program runs fast on that
simple hardware?
Instead we have two guys in tel aviv waking up in night terror every
night over confusion why does x86 run any code at all, how come it
works. And I'm at home 'hehe new intc make program go fast:)))'

Now that we have comparatively simple compilers and often no runtime
at all, the hardware has to optimise the shitty program for us, but as
we don't get to see how the sausage is made, we think it's probably
something that is well done, robust and correct. If we'd do this in
software, we'd all have to suffer how fragile the compiler and runtime
are and how unapproachable they are.

-- 
  ++ytti



More information about the NANOG mailing list