Hi Aijun, Les is on vacation, so you’ll pardon while I pinch-hit.
Your opinions are duly noted. Thank you very much for your comments. Regards, Tony > On Sep 6, 2024, at 6:46 AM, Aijun Wang - wangaijun at tsinghua.org.cn > <[email protected]> wrote: > > Hi, Les: > > I have reviewed again this revised draft, and contrary to your declaration > that "it addressed all the comments/issues", IT IS NOT. > Here are my analysis: > > 1) The document states in several places that the key is necessary for the > right process of MP-TLV, and gives two examples for the TLV 22 and TLV 135, > their respective key definitions, but, there is no key definition for other > code points. > > 2) If you think it is impossible to define the key definition for all the > MP-TLV applicable TLV that you list in the sec 8.1(IANA consideration) in > your document, then this is the WRONG direction to solve the MP-TLV related > problem. > If you can't define such key information, the interoperability problem will > be arose within the operator network. > > 3) Such consideration is same for the MP-TLV Capability Advertisement. In > your solution, MP-TLV capability advertisement is not per-codepoint basis, > then how you require the operator "diligence is still required on the part of > the operator to ensure that configurations which require the sending of > MP-TLV for a given codepoint are not introduced on any node in the network > until all nodes in the network support MP-TLV for the relevant codepoints." ? > By manual? By other OOB methods? > > 4) Based on the above comments, I think your draft should be renamed as > "MP-TLV Key Definition for IS-IS TLV 22 and TLV 135", it is far to be > evaluated as one general solution for MP-TLV problem. > > I can't see other values except the key definition of TLV 22 and TLV 135 from > the current version. > Following such direction, the operator will be busy to coordinate the > vendors, the deployment for the opened Pandora's box > > > Best Regards > > Aijun Wang > China Telecom > > -----邮件原件----- > 发件人: [email protected] <mailto:[email protected]> > [mailto:[email protected]] 代表 [email protected] > <mailto:[email protected]> > 发送时间: 2024年9月6日 1:57 > 收件人: [email protected] <mailto:[email protected]> > 抄送: [email protected] <mailto:[email protected]> > 主题: [Lsr] I-D Action: draft-ietf-lsr-multi-tlv-05.txt > > Internet-Draft draft-ietf-lsr-multi-tlv-05.txt is now available. It is a work > item of the Link State Routing (LSR) WG of the IETF. > > Title: Multi-part TLVs in IS-IS > Authors: Parag Kaneriya > Tony Li > Antoni Przygienda > Shraddha Hegde > Les Ginsberg > Name: draft-ietf-lsr-multi-tlv-05.txt > Pages: 27 > Dates: 2024-09-05 > > Abstract: > > New technologies are adding new information into IS-IS while > deployment scales are simultaneously increasing, causing the contents > of many critical TLVs to exceed the currently supported limit of 255 > octets. Extensions exist that require significant IS-IS changes that > could help address the problem, but a less drastic solution would be > beneficial. This document codifies the common mechanism of extending > the TLV content space through multiple TLVs. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-lsr-multi-tlv/ > > There is also an HTMLized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-multi-tlv-05 > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-multi-tlv-05 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org <http://rsync.ietf.org/>::internet-drafts > > > _______________________________________________ > Lsr mailing list -- [email protected] <mailto:[email protected]> > To unsubscribe send an email to [email protected] > <mailto:[email protected]>_______________________________________________ > 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]
