[Lsr] Re: Using RFC 7356 to address TLV size limitations

[Aijun Wang]

Hi, Les: From its publication on September 2014, RFC 7356 has been existing 10 years, can you give some examples that which vendor has implemented it, which operator has deployed it? Don’t you think RFC7356 is one failure RFC? Why encourage other persons to solve the problem based on such RFC? MP-TLV proposal has obvious pitfalls that are unsolved( I have raised the technical arguments several times, if you disagree, please response them) Aijun Wang China Telecom Aijun Wang China Telecom On Oct 31, 2024, at 23:12, 【外部账号】 Les Ginsberg (ginsberg) <ginsb...@cisco.com> wrote:  (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> 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 > > > 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 > To unsubscribe send an email to lsr-le...@ietf.org

_______________________________________________
Lsr mailing list -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org