Hi, > That was my point in the email thread “Regaining Focus on SRv6 and SRv6+”; > > • SRH has been around since 5 years with now 22 versions the last call > is done, it’s on its way to become an RFC > • ISIS/SRv6 is out there since 2015 with lots of iterations > > After all these years, why starting something new now and not finish first > what is already started ?
Because many problems are identified in the current work, and I realised I don't like what I see. > If there is more needs/requirements, why wasn’t it raised while we were > riding on SRH 2014-2019+, and net png ? It's not needs/requirements, it's mostly the lack of a KISS approach > Maybe as an IETFer/Vendor I'm an operator > “real deployment” doesn’t seem to impress you, Please elaborate about the real deployment. Where was it deployed? In what kind of networks? On what scale? For which use cases? > but it allows to cycle back and tweak, optimize and enhance 5 years of work > (ex.: uSID which is a building block of the overall SRv6 architecture. I agree. But after 5 years of (re)engineering) it's time to step back and look at the solution again with fresh eyes. https://hackernoon.com/delete-your-code-c5d2dc59f1ff > If we can finish what we started, then we can start something new – such as > your proposal. I don't like the design of the current solution, and you seem to suggest that I have to stall work on what I would like until you have what you would like *. That doesn't work for me. Cheers, Sander *: Especially with the current attitude/language in the drafts that seems to promote the current work as the only true solution, and everything else as secondary. That might not be the intention, but that is how it appears.
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
