(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 <d3e...@gmail.com> > Sent: Thursday, October 31, 2024 2:46 PM > To: Henk Smit <henk.i...@xs4all.nl> > Cc: duzongp...@foxmail.com; Aijun Wang <wangai...@tsinghua.org.cn>; > 【外部账号】Christian Hopps <cho...@chopps.org>; Hannes Gredler > <han...@gredler.at>; Yingzhen Qu <yingzhen.i...@gmail.com>; lsr-chairs <lsr- > cha...@ietf.org>; draft-wang-lsr-isis-big-tlv <draft-wang-lsr-isis-big- > t...@ietf.org>; lsr@ietf.org > 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 > <henk.i...@xs4all.nl<mailto:henk.i...@xs4all.nl>> 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 > d3e...@gmail.com<mailto:d3e...@gmail.com> > > > 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 -- lsr@ietf.org<mailto:lsr@ietf.org> > To unsubscribe send an email to lsr-le...@ietf.org<mailto:lsr-le...@ietf.org>
_______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
