> 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.
Perhaps I will surprise a few but this is not only already in RFC formats - it is also shipping already across vendors for some time now. SR-MPLS (as part of its spec) does exactly that. You do not need to use any SR if you do not want, you still can encapsulate your packets with transport label corresponding to your exit at any ingress and forget about LDP for good. But with that let's not forget that aggregation here is still not spec-ed out well and to the best of my knowledge it is also not shipping yet. I recently proposed an idea how to aggregate SRGBs .. one vendor is analyzing it. Best, R. On Sat, Jun 20, 2020 at 1:33 AM Randy Bush <ra...@psg.com> wrote: > < 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 >
