(Note I have changed the subject line (previously was " RE: [Lsr] Re: [Further Discussion]It's time to find one general solution to Big-TLV problem Re: IETF 121 LSR Slot Requests".
I did this for two reasons: 1)WG Chairs and WG Members have made it clear that the ongoing discussion of Big TLV is inappropriate. The WG has adopted/last called the multi-tlv solution - so this matter is closed 2)I think it is good for the WG to keep awareness that there is a more robust - but decidedly not backwards compatible - solution defined when the industry decides that the costs of deploying a non-backwards compatible solution can be justified. I think this new thread can - if the WG wishes - be of some value. More below. > -----Original Message----- > From: Donald Eastlake <[email protected]> > Sent: Thursday, October 31, 2024 2:46 PM > To: Henk Smit <[email protected]> > Cc: [email protected]; Aijun Wang <[email protected]>; > 【外部账号】Christian Hopps <[email protected]>; Hannes Gredler > <[email protected]>; Yingzhen Qu <[email protected]>; lsr-chairs <lsr- > [email protected]>; draft-wang-lsr-isis-big-tlv <draft-wang-lsr-isis-big- > [email protected]>; [email protected] > Subject: [Lsr] Re: [Further Discussion]It's time to find one general solution > to > Big-TLV problem Re: IETF 121 LSR Slot Requests > > On Thu, Oct 31, 2024 at 9:28 AM Henk Smit > <[email protected]<mailto:[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. > [LES:] Donald thanx for spotting this inadvertent mistake. I agree that (clearly) "length" (NOT value) was intended. It points up that RFC 7356 addresses at least two major issues - and allows that one or both can be addressed. Issue #1 is the limited LSP space (256 LSPs/node/level) This is addressed by defining new PDUs which use a 16 bit LSP number (currently this is an 8 bit number). This allows up to 65K LSPs/node/level. Issue #2 is the limited size of a single TLV/sub-TLV. This is addressed by using 16 bit type/length fields. Different flooding scopes were defined (as seen in the registry https://www.iana.org/assignments/isis-pdu/isis-pdu.xhtml#lsp-flooding-scoped-id ) Each scope has a tuple defined which can take on one of two values: Extended/Standard - This scope uses 16 bit LSP number with 8 bit TLVs Extended/Extended - This scope uses 16 bit LSP number with 16 bit TLVs NOTE: We could have also defined a scope that used 8 bit LSP number with 16 bit TLVs (Standard/Extended) but as the need to advertise more than 255 bytes/TLV increases the likelihood that more than 256 LSPs might be needed we decided that there wasn't a need to support that. In regards to protocol version, Donald is (yet again 😊) correct that we continue to use "1" as the protocol version. This was done because there are multiple scenarios in which the use of standard L1/L2 LSPs can be used in conjunction with the new flooding scoped LSPs. These scenarios include: * There are flooding scopes (such as link scoped flooding) which can be used in conjunction with existing standard L1/L2 LSPs (TRILL in fact did that) * We saw no need to extend pseudo-node LSPs – and since we have repurposed the pseudo-node ID field in the LSP header to support the 16 bit LSP # - it would have been awkward to do so * To maintain existing rules related to Area Address/LSPDB staleness/Overload Bit we still require the presence of Standard LSP #0 in order for any other LSPs from that node to be considered usable (see https://www.rfc-editor.org/rfc/rfc7356.html#section-9 ) Happy to continue this discussion if the WG is interested. Les > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > [email protected]<mailto:[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]<mailto:[email protected]> > To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
