why am i in this handbasket? (was Devil's Advocate - Segment Routing, Why?)

Fri Jun 19 23:32:46 UTC 2020

< ranting of a curmudgeonly old privileged white male >

>>> MPLS was since day one proposed as enabler for services originally
>>> L3VPNs and RSVP-TE.
>> MPLS day one was mike o'dell wanting to move his city/city traffic
>> matrix from ATM to tag switching and open cascade's hold on tags.
> And IIRC, Tag switching day one was Cisco overreacting to Ipsilon.

i had not thought of it as overreacting; more embrace and devour.  mo
and yakov, aided and abetted by sob and other ietf illuminati, helped
cisco take the ball away from Ipsilon, Force10, ...

but that is water over the damn, and my head is hurting a bit from
thinking on too many levels at once.

there is saku's point of distributing labels in IGP TLVs/LSAs.  i
suspect he is correct, but good luck getting that anywhere in the
internet vendor task force.  and that tells us a lot about whether we
can actually effect useful simplification and change.

is a significant part of the perception that there is a forwarding
problem the result of the vendors, 25 years later, still not
designing for v4/v6 parity?

there is the argument that switching MPLS is faster than IP; when the
pressure points i see are more at routing (BGP/LDP/RSVP/whatever),
recovery, and convergence.

did we really learn so little from IP routing that we need to
recreate analogous complexity and fragility in the MPLS control
plane?  ( sound of steam eminating from saku's ears :)

and then there is buffering; which seems more serious than simple
forwarding rate.  get it there faster so it can wait in a queue?  my
principal impression of the Stanford/Google workshops was the parable
of the blind men and the elephant.  though maybe Matt had the main
point: given scaling 4x, Moore's law can not save us and it will all
become paced protocols.  will we now have a decade+ of BBR evolution
and tuning?  if so, how do we engineer our networks for that?

and up 10,000m, we watch vendor software engineers hand crafting in
an assembler language with if/then/case/for, and running a chain of
checking software to look for horrors in their assembler programs.
it's the bleeping 21st century.  why are the protocol specs not
formal and verified, and the code formally generated and verified?
and don't give me too slow given that the hardware folk seem to be
able to do 10x in the time it takes to run valgrind a few dozen
times.

we're extracting ore with hammers and chisels, and then hammering it
into shiny objects rather than safe and securable network design and
construction tools.

apologies.  i hope you did not read this far.

randy