Hi Geoff, Dirk, I wanted to add a couple of comments on your excellent points, see inline. (trimmed a little bit of the text)
Ciao L. > On 27 Jan 2022, at 08:51, Dirk Trossen > <[email protected]> wrote: > [snip] > > There is also a second factor, that of sunk cost. Nobody wants to pay to > upgrade existing infrastructure. Nobody. So those who want to change things > build around, over and tunnel through existing infrastructure. In a > deregulated world where piecemeal uncoordinated actions predominate, the > level of coordination and orchestration required to uplift common shared > infrastructure is simply impossible. We say to ourselves that we outgrew flag > days on the Internet many decades ago, and thats true, but at times we appear > not to understand precisely what that implies about today. We have built an > application-based superstructure of encapsulated tunnels in the network > (QUIC) that neatly circumvents the entire question of infrastructure renewal. > Whereas IPv6 has been head-butting against the sunk cost of existing > infrastructure for more than two decades then dramatic rise of QUIC, BBR, > SVCB and HTTPS, and similar application-level technologies attests to the > application world’s extreme distaste to engage with the existing > infrastructure. > This last point is tackled in the current set of documents and also touched in the previous thread (but can certainly be improved upon this thread). I think that we are at the stage that _no_ there is no strong reason yet to upgrade the existing infrastructure (we do not even know to what to upgrade). However, the innovation is there and is happening, raising the question: - Up to what point we can “build on top” without risking to jeopardize the whole? In the long run, up to what point we can continue the way we are solving problems today? Seeing this as a possible risk, I would prefer to discuss now about what can be done (including the “is it worthwhile?” question). Up to us to answer this tough question and engineer an improved architecture that provide sufficient benefits to be adopted in less time that IPv6 adoption. [snip] > > Then, as now, the issue was NOT “What’s the answer?” but “Whats the right > question to ask?” - at least for me. Isn’t what we are trying to do here? ;-) I think that the discussions happening in the INTArea mailing list are very fruitful. We just need to capture the current understanding in the documents, trying to formalize the problem we face. As other already mentioned there is an architectural discussion to be made (and happy that the architecture discuss mailing list is in this thread), but we need to start somewhere and addressing is a good starting point. What we need is to gather the experience each and everyone of us can provide in order to shape something meaningful to move forward….. starting from the addresses ;-) _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
