why am i in this handbasket? (was Devil's Advocate - Segment Routing, Why?)
mark.tinka at seacom.mu
Sun Jun 21 08:17:14 UTC 2020
On 20/Jun/20 01:32, Randy Bush wrote:
> 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.
This is shipping today with SR-MPLS.
Besides still being brand new and not yet fully field tested by the
community, my other concern is unless you are running a Juniper and have
the energy to pull a "Vijay Gill" and move your entire backbone to
IS-IS, you'll get either no SR-ISISv6 support, no SR-OSPFv3 support, or
both, with all the vendors.
Which brings me back to the same piss-poor attention LDPv6 is getting,
which is, really, poor attention to IPv6.
Kind of hard for operators to take IPv6 seriously at this level if the
vendors, themselves, aren't.
> 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?
I think the forwarding is fine, if you're carrying the payload in MPLS.
The problem is the control plane. It's not insurmountable; the vendors
just want to do less work.
The issue is IPv4 is gone, and trying to keep it around will only lead
to the creation of more hacks, which will further complicate the control
and data plane.
> 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.
Either way, the MPLS or IP problem already has an existing solution. If
you like IP, you can keep it. If you like MPLS, you can keep it.
So I'd be spending less time on the forwarding (of course, if there are
ways to improve that and someone has the time, why not), and as you say,
work on fixing the control plane and the signaling for efficiency and scale.
> 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 :)
The path to SR-MPLS's inherent signaling carried in the IGP is an
optimum solution, that even I have been wanting since inception.
But, it's still too fresh, global deployment is terrible, and there is
still much to be learned about how it behaves outside of the lab.
For me, a graceful approach toward SR via LDPv6 makes sense. But, as
> 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?
This deserves a lot more attention than it's receiving. The problem is
it doesn't sound sexy enough to compile into a PPT that you can project
to suits whom you need to part with cash.
It doesn't have that 5G or SRv6 or Controller or IoT ring to it :-).
It's been a while since vendors that control a large portion of the
market paid real attention to their geeky side. The buffer problem, for
me, would fall into that category. Maybe a smaller, more agile, more
geeky start-up, can take the lead with this one.
> 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
And for today's episode of Jeopardy:
"What used to be the IETF?"
> 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.
Rush it out the factory, fast, even though it's not ready. Get all their
money before they board the ship and sail for Mars.
More information about the NANOG