Hello Donald, TL;DR The point I wanted to make is just that the Big Container TLV serves no practical purpose.
henk. My answer to Donald, not relevant to the topic of Container TLVS: === > I assume you mean 16-bit Length, not Value. ... RFC 7356. No, I actually meant 16 bits for both Type and Length. If we're gonna fix stuff, in a non-backwards-compatible way, we should fix things properly. Imho that means extending both Type and Length to 16 bits. (I could use a few Type values for my own use. Don't care if other vendors implement my ideas. Or whether I get to write an RFC or not. But if TLV space is scarce, I understand I can't get any). If we make rigorous changes, and bump the protocol version, we should fix other things as well. E.g. extending the LSP fragment-number to 16 bits too. I am sure there are more fundamental things we can fix in an IS-IS protocol version 2. I am aware that if a new protocol doesn't have any real advantages, it will never get deployed. So if we bump the version, we should make sure the new protocol has enough benefits that people will want to run it. And even then it will be painful to deploy. (But then again, deploying "Big Container TLVs" would also not be without challenges). > Still uses IS-IS protocol version number 1. I've been out of the industry for over a decade. (Playing World of Warcraft. And doing other dumb things that are more fun than participating in the politics in an IETF WG. :) ) I've also spent a few years working on BGP, not IS-IS. So I am not always familiar with all RFCs written in the last 2 decades. Apologies. I had never before really looked at RFC 7356 in detail. Even if you keep the IS-IS protocol version at 1, but make the LSP packet-format completely incompatible with older IS-IS, that is not much different than bumping the protocol version. But that's a whole different discussion. For another time. The point I wanted to make is just that the Big Container TLV serves no practical purpose. henk. > On 10/31/2024 10:46 PM CET Donald Eastlake <[email protected]> wrote: > > > On Thu, Oct 31, 2024 at 9:28 AM Henk Smit <[email protected]> wrote: > >... > > > > There are two types of problems. > > 1) Short-term problems. Which have to be fixed asap. > > 2) Long-term problems. Which need a proper solution. > > Container TLVs are not a good short-term solution, and not a good long-term > > solution. > > > > The split TLV problem has been solved for the short term. > > The multipart-TLV fix has been implemented by multiple vendors. It has been > > deployed in multiple production networks. > > It works. There is no need for a 2nd short-term solution. > > > > Your 2nd solution also is not backwards compatible. So it has no benefits > > of the multipart-TLV solution. > > I see 0 benefit of having container TLVs over the multipart-TLV solution. > > Neither do most other people here in the working-group. Can you not clearly > > see that when you read the responses? > > > > If we want to think of a better solution, we should fix this properly. > > As Hannes already suggested: the proper fix is to bump the IS-IS protocol > > version, and have 16-bit Type and 16-bit Value TLVs. > > I assume you mean 16-bit Length, not Value. See the E-L1FS and E-L2FS > Extended Flooding Scopes in RFC 7356. Still uses IS-IS protocol > version number 1. > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > [email protected] > > > This is a huge change. And not backwards compatible. > > > > I am a fan of rule #12 in RFC 1925. Keep your protocols simple. > > 16-bit Types and 16-bit Value TLVs are a simple concept. > > They don't change anything to the algorithms or behaviour of IS-IS. > > It's just "a small matter of programming" to implement them. > > > > My countryman Edsger Dijkstra (you might have heard of him) has said this: > > ".Elegance is not a dispensable luxury but a factor that decides between > > success and failure." > > Elegance means: simple and yet effective. > > Multipart TLVs are an ugly hack, imho. But so are container TLVs. > > We already have a (working and deployed) short-term solution. > > If we're gonna have a 2nd solution, it should be elegant. Not yet another > > hack. > > > > Just my own opinion. > > Not my employer's. But I think both my colleagues, as well as most other > > people on this list, agree with me. > > > > Kind regards, > > henk. _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
