Hi Aijun,
> On Nov 26, 2023, at 7:05 PM, Aijun Wang <wangai...@tsinghua.org.cn> wrote: > > Some additional questions: > > The draft say “The contents of a multi-part TLV MUST be processed as if they > were concatenated. If the internals of the TLV contain key information, then > replication of the key information should be taken to indicate that > subsequent data MUST be processed as if the subsequent data were concatenated > after a single copy of the key information.” > > 1) How to deal with the TLV that has no key information? That’s the easiest case: the content between instances is not correlated, so each TLV can be individually processed independently. > 2) And, to support multi-part TLV, the key information (if the TLV has > such information) for each applied TLV must also be standardized, or else, > there will be error. > The draft wants to just avoid to tackle such issues(as stated in draft > “Having inconsistent information in different parts of a MP-TLV is an error > and is out of scope for this document.), but it should be the MUST part of > the solution. I respectfully disagree. Having a single RFC that sorts through all of that is wholly unwieldy and guaranteed to be highly erroneous. It’s far better to write separate documents that can be individually and carefully crafted and reviewed. > > Or else, how to assure the interoperability? Interoperability is never assured by documents. Careful thought, coding, and testing are required. This has not changed. T > > Best Regards > > Aijun Wang > China Telecom > > 发件人: forwardingalgori...@ietf.org <mailto:forwardingalgori...@ietf.org> > [mailto:forwardingalgori...@ietf.org] 代表 Aijun Wang > 发送时间: 2023年11月24日 16:11 > 收件人: 'Yingzhen Qu' <yingzhen.i...@gmail.com > <mailto:yingzhen.i...@gmail.com>>; draft-pkaneria-lsr-multi-...@ietf.org > <mailto:draft-pkaneria-lsr-multi-...@ietf.org>; 'lsr' <lsr@ietf.org > <mailto:lsr@ietf.org>> > 主题: [Lsr] 答复: WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - > 12/09/2023) > > Do not support its adoption. > > The draft just enumerate the requirements of MP-TLV support for relevant > TLVs, it is not the general solution to the issue. > > There is no practical way in the draft to assure the current and future > implementation conforms to the newly defined explicit requirements, because > the MP-TLV Support sub-TLV is not per-TLV basis, and as stated in the draft, > one implementation declares support “MP-TLV” can’t assure it supports all > relevant TLVs. ------“It is understood that in reality, a given > implementation might limit MP-TLV support to particular TLVs based on the > needs of the deployment scenarios in which it is used”-----Will there be many > interoperability issues arises then? And also varies loop accidents within > the network when all of vendors declare they support “MP-TLV” but not all of > the relevant TLVs? > > Best Regards > > Aijun Wang > China Telecom > > 发件人: forwardingalgori...@ietf.org <mailto:forwardingalgori...@ietf.org> > [mailto:forwardingalgori...@ietf.org] 代表 Yingzhen Qu > 发送时间: 2023年11月18日 1:24 > 收件人: draft-pkaneria-lsr-multi-...@ietf.org > <mailto:draft-pkaneria-lsr-multi-...@ietf.org>; lsr <lsr@ietf.org > <mailto:lsr@ietf.org>> > 主题: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - > 12/09/2023) > > Hi, > > This begins a WG adoption call for draft-pkaneria-lsr-multi-tlv: > draft-pkaneria-lsr-multi-tlv-04 - Multi-part TLVs in IS-IS (ietf.org) > <https://datatracker.ietf.org/doc/draft-pkaneria-lsr-multi-tlv/> > > Please send your support or objection to the list before December 9th, 2023. > An extra week is allowed for the US Thanksgiving holiday. > > Thanks, > Yingzhen
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
