Hi Chris, Please see my reply inline... > -----Original Message----- > From: Christian Hopps <chopps@xxxxxxxxxx> > Sent: Monday, November 11, 2024 8:14 PM > To: Mach Chen <mach.chen@xxxxxxxxxx> > Cc: rtg-ads@xxxxxxxx; rtg-dir@xxxxxxxx; draft-ietf-lsr-multi-tlv.all@xxxxxxxx; Lsr > <lsr@xxxxxxxx>; last-call@xxxxxxxx > Subject: Re: RtgDir Last Call Review: draft-ietf-lsr-multi-tlv-06 > > > Mach Chen <mach.chen=40huawei.com@xxxxxxxxxxxxxx> writes: > > > Hello， > > > > I have been selected as the Routing Directorate reviewer for this > > draft. The Routing Directorate seeks to review all routing or > > routing-related drafts as they pass through IETF last call and IESG > > review, and sometimes on special request. The purpose of the review is to > provide assistance to the Routing ADs. > > For more information about the Routing Directorate, please see > > https://wiki.ietf.org/en/group/rtg/RtgDir > > > > Although these comments are primarily for the use of the Routing ADs, > > it would be helpful if you could consider them along with any other > > IETF Last Call comments that you receive, and strive to resolve them > > through discussion or by updating the draft. > > > > Document: https://datatracker.ietf.org/doc/draft-ietf-lsr-multi-tlv-06 > > Reviewer: Mach Chen > > Review Date: 2024-11-11 > > IETF LC End Date: > > Intended Status: Standards Track > > > > Summary: > > • I have some major and minor concerns about this document that I think > should be resolved before publication. > > > > Comments: > > • The document is well written and easy to read it. > > > > Major Issues: > > 1. The definitions of the 'Key' for TLVs and sub-TLVs vary, and this > > document does not specify the Key for each MP-TLV. Therefore, it may > > result in interoperability issues if implementations use different > > information to construct the 'Key.' Given Section 8.2 listed all > > existing applicable MP-TLVs, it's essential to specify the Key for > > each of those MP-TLVs, either within this document or in a separate > > document to which this document should provide a normative reference. > > Hi Mach, > > I'm curious if you also followed along on the extensive discussions on this exact > issue on the LSR list or not? > > Understanding your exposure to this would help with how to address any > remaining confusion about this directly in the draft. > > The WG explicitly decided it was inappropriate to have this document re-define > every "key" for every possible TLV as these "key" values are already defined by > the documents that define the TLV; however, documenting that choice and the > reasoning better may still be necessary. > > So my question is this: were you following along with this discussion in the LSR > WG and find yourself disagreeing with the WG decision, or is this entire topic > new to you? I hadn’t closely followed this topic’s discussion before, but after taking on this review task, I read most of the related emails. I remain unconvinced by the idea that we should ‘rely on experienced ISIS implementers to understand the composition of each MP-TLV Key.’ While this document does not alter the MP-TLV encoding, it introduces the concept of a Key and specific operations involving it, such as copying the Key across different MP-TLV parts or correlating ML-TLV parts by the Key. These operations are not required by the original MP-TLV RFCs, so it is this document’s responsibility to define what constitutes the MP-TLV Key to ensure these operations can be implemented correctly. Given the authors have already investigated all the existing MP-TLVs, taking a further step to document the Key definitions for those TLVs/sub-TLVs in this document, in a separate document, or even in a wiki would be valuable to the community. Best regards, Mach > Thanks, > Chris. > > > > > > Minor Issues: > > 1. The MP-TLV Capability Advertisement is defined as a node-based > > capability rather than on a per-codepoint basis, which limits its > > usefulness. In some cases, it may even be misleading if operators just > > rely on this capability to assume MP-TLV support. Therefore, it would > > be preferable to either remove this capability advertisement or redefine it to > operate on a per-codepoint basis. > > > > Best regards, > > Mach -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
