Hi Hannes, How do you deal with MTU of the links if your TLV can grow to 65K octets ? The workarounds to use multiple system IDs or more LSPs seem far from perfect.
Related to the subject - IMO we should aim to shrink not grow in size ISIS LSPs. MP seems to be doing the right thing here in providing the ability to chop the information into chunks. Much better would be to just flood references to the information (not the actual information itself), but I think it will take a long time before LSR or IDR WGs adopt such a model at least for the opaque to real routing stuff. Cheers, R. On Wed, Oct 23, 2024 at 11:20 AM Hannes Gredler <hannes= [email protected]> wrote: > Why are we having this discussion again ? > > My recollection is that we have a “good enough” solution that is deployed > and interoperable. > If you want the “generic solution” then the 16-bit TLVs described in > RFC7356 is the way to go forward and if there is concern about incremental > deployment then we should work on this aspect. > > /hannes > > > On 23.10.2024, at 00:50, Aijun Wang <[email protected]> wrote: > > > Hi,Chris: > > Please elaborate clearly your technical reviews for the updates of the > newly proposed Big-TLV solution. > > I can copy the updates again at here and state their effects clearly.( > https://mailarchive.ietf.org/arch/msg/lsr/dxK4Gy1WDR7QCXK6p58xgA0MdUc/ > <https://mailarchive.ietf.org/arch/msg/lsr/dxK4Gy1WDR7QCXK6p58xgA0MdUc/>)Please > give your analysis before you make any conclusions: > > A new version of Big-TLV document has been > posted(https://datatracker.ietf.org/doc/html/draft-wang-lsr-isis-big-tlv) > <http://posted(https//datatracker.ietf.org/doc/html/draft-wang-lsr-isis-big-tlv)>, > to try to give the community one general way to solve the Big TLV problem. > > The main changes from the previous versions are the followings: > 1) Add one "Identification" field within the container TLV(type TBD1), to > function as the key for any sliced TLV, and is TLV code point independent. > 2) Add one "Flag" field, define currently the "F" bit to indicate whether the > piece of container is the first piece(F bit is set to 1), or not (F bit is > unset) > 3) Put all the sliced pieces within the newly defined container TLV(type > TBD1). > 4) Define some rules for the "Split and Glue" procedures(may be re-optimizer > later after the WG discussions) > > The updated version erases the necessity of defining the "key" information > for every IS-IS (Possible Big) TLV code point, and also the necessity of > per-TLV capability announcement. > > > I would like to hear your detail analysis, especially as the WG chairs, for > the above statements. > > Aijun Wang > China Telecom > > On Oct 22, 2024, at 20:15, 【外部账号】Christian Hopps <[email protected]> > wrote: > > Those changes don't appear to address what the WG already decided > against. The view of the WG was that a new Big TLV for doing this was not > going to work. Given the name of this work is Big TLV, that doesn't seem to > have changed. So why should the WG be spending even more time on a solution > they already discussed, debated and discarded? > > Thanks, > Chris. > [as wg chair] > > > On Oct 22, 2024, at 06:47, Aijun Wang <[email protected]> wrote: > > > Hi, Chris: > > > No, we have made some significant updates. > > Please refer to > https://mailarchive.ietf.org/arch/msg/lsr/dxK4Gy1WDR7QCXK6p58xgA0MdUc/ > for more information. > > > Aijun Wang > > China Telecom > > > On Oct 22, 2024, at 17:04, 【外部账号】Christian Hopps <[email protected]> > wrote: > > > > > Is this the same thing that Huaimo has already presented to the WG, that > the WG decided was not the way it wanted to go? > > > Thanks, > > Chris. > > > "Aijun Wang" <[email protected]> writes: > > > Hi, Yingzhen: > > > > > I would like to request 10-15minutes to make the presentation for the > > “IS-IS Extension for Big TLV” > > > The related information are the followings: > > > > > Draft Name: IS-IS Extension for Big TLV > > > Link: https://datatracker.ietf.org/doc/draft-wang-lsr-isis-big-tlv > > / > > > Presenter: Aijun Wang > > > Desired Slot Length: 10-15minutes. > > > > > > > Best Regards > > > > > Aijun Wang > > > China Telecom > > > > > 发件人: [email protected] > > [mailto:[email protected]] 代表 Yingzhen Qu > > 发送时间: 2024年10月12日 3:54 > > 收件人: lsr <[email protected]>; lsr-chairs <[email protected]> > > 主题: [Lsr] IETF 121 LSR Slot Requests > > > > > Hi, > > > > > The draft agenda for IETF 121 has been posted: > > > IETF 121 Meeting Agenda > > > > > The LSR session is scheduled on Thursday Session I 09:30-11:30, Nov 7th, > 2024. > > > > > Please send slot requests to [email protected] before the end of the day > > > Wednesday Oct 23. Please include draft name and link, presenter, desired > > > slot length including Q&A. > > > > > Thanks, > > > Yingzhen > > > > > > _______________________________________________ > Lsr mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > > _______________________________________________ > Lsr mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
