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/ )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), 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:
|
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
