Hi, Mach: Your comments reminds me to review the update version also. Omit the descriptions of the key information for "Extended IP Reachability" TLV can lead only more chaos for its deployment. It will decrease the usage and application of this standard again. The "undefined key information" problem is still there, it will be no help for us to shunning them. Best Regards Aijun Wang China Telecom -----邮件原件----- 发件人: forwardingalgorithm@xxxxxxxx [mailto:forwardingalgorithm@xxxxxxxx] 代表 Mach Chen 发送时间: 2025年2月12日 15:57 收件人: Les Ginsberg (ginsberg) <ginsberg=40cisco.com@xxxxxxxxxxxxxx>; Christian Hopps <chopps@xxxxxxxxxx> 抄送: rtg-ads@xxxxxxxx; rtg-dir@xxxxxxxx; draft-ietf-lsr-multi-tlv.all@xxxxxxxx; Lsr <lsr@xxxxxxxx>; last-call@xxxxxxxx 主题: [Lsr] Re: RtgDir Last Call Review: draft-ietf-lsr-multi-tlv-06 Hi Les, Thanks for the reminder! I reviewed the latest version and noticed that the following text from V6 has been removed, which addressed my major concern. "If a Multi-part TLV contains information that specifies the applicability of its contents (i.e., a key), the key information MUST be replicated in additional TLV instances so that all contents specific to that key can be identified." Therefore, I support moving this document forward. Best regards, Mach > -----Original Message----- > From: Les Ginsberg (ginsberg) <ginsberg=40cisco.com@xxxxxxxxxxxxxx> > Sent: Wednesday, February 12, 2025 1:12 PM > To: Mach Chen <mach.chen@xxxxxxxxxx>; Christian Hopps > <chopps@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 - > > We have now resumed work on the draft - V7 has been posted. > Please take a look. > > Thanx very much. > > Les > > > -----Original Message----- > > From: Mach Chen <mach.chen=40huawei.com@xxxxxxxxxxxxxx> > > Sent: Thursday, November 14, 2024 1:35 AM > > To: Les Ginsberg (ginsberg) <ginsberg@xxxxxxxxx>; Christian Hopps > > <chopps@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 > > > > Hi Les, > > > > Thanks for the detailed explanation, looking forward to seeing the update. > > > > Thanks, > > Mach > > > > > -----Original Message----- > > > From: Les Ginsberg (ginsberg) > > > <ginsberg=40cisco.com@xxxxxxxxxxxxxx> > > > Sent: Wednesday, November 13, 2024 2:37 AM > > > To: Mach Chen <mach.chen@xxxxxxxxxx>; Christian Hopps > > > <chopps@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 - > > > > > > As regards this quote: > > > > > > ""If a Multi-part TLV contains information that specifies the > > > > applicability of its contents (i.e., a key), the key information MUST > > > > be replicated in additional TLV instances so that all contents > > > > specific to that key can be identified." > > > > > > Some context needs to be provided. > > > > > > During WG review, there was discussion about the specifics of the > > > IS > > Neighbor > > > TLVs where there are multiple link identifiers that may be present. > > > These > > > include: > > > > > > o IPv4 endpoint addresses > > > o IPv6 endpoint addresses > > > o Link IDs > > > > > > There was discussion that only one of these needed to match in > > > order to be able to correctly identify two TLVs as being > > > associated with the same > link. > > This > > > led to the observation that an implementation could try to > > > optimize the > > space > > > required by doing something like: > > > > > > TLV #1: System ID A > > > IPv4 endpoint addresses > > > Link IDs > > > > > > TLV #2: System ID A > > > Link IDs > > > > > > It would still be possible to correctly identify the two TLVs as > > > associated with the same link and therefore part of an MP-TLV. > > > > > > However, it was discussed that this is error prone. An > > > implementation might > > > do: > > > > > > TLV #1: System ID A > > > IPv4 endpoint addresses > > > > > > TLV #2: System ID A > > > Link IDs > > > > > > And then there would be no way to correlate the two TLVs. > > > > > > Earlier versions of the draft used the language "at least one..." > > > of the link identifiers had to be present in all TLVs, but this > > > was eventually replaced with the current wording - which is seen > > > as more robust and simpler - even if less efficient in terms of LSP space consumed. > > > > > > While I can understand why this language could lead you to the > > > conclusion that we are making up special rules for MP-TLVs, this > > > conclusion is FALSE and unintended. > > > Authors are currently reviewing an update which will remove this > > > language and simply say "encoding of TLVs is unchanged by the use > > > of MP-TLV" (or words to that effect). > > > > > > HTH > > > > > > Les > > > > > > > -----Original Message----- > > > > From: Mach Chen <mach.chen=40huawei.com@xxxxxxxxxxxxxx> > > > > Sent: Tuesday, November 12, 2024 12:41 AM > > > > To: Les Ginsberg (ginsberg) <ginsberg@xxxxxxxxx>; Christian > > > > Hopps <chopps@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 > > > > > > > > Hi Les, > > > > > > > > Some replies inline... > > > > > > > > > -----Original Message----- > > > > > From: Les Ginsberg (ginsberg) > > > > > <ginsberg=40cisco.com@xxxxxxxxxxxxxx> > > > > > Sent: Tuesday, November 12, 2024 4:09 PM > > > > > To: Mach Chen <mach.chen@xxxxxxxxxx>; Christian Hopps > > > > > <chopps@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 - > > > > > > > > > > Apologies. My mailer sometimes truncates inline replies. > > > > > Let me try again - top posting. > > > > > > > > > > We do NOT introduce the "concept of a key". > > > > > > > > Alright, we'll have to agree to disagree😊 > > > > > > > > > We introduce the use of a generic term ("key") to refer to > > > > > those codepoint specific elements which uniquely identify the > > > > > objects being > > > advertised. > > > > > We also do NOT introduce "copying the Key across different > > > > > MP-TLV > > parts". > > > > > > > > Below text is quoted from Section 4: > > > > "If a Multi-part TLV contains information that specifies the > > > > applicability of its contents (i.e., a key), the key information MUST > > > > be replicated in additional TLV instances so that all contents > > > > specific to that key can be identified." > > > > > > > > In my view, this constitutes a new requirement introduced by > > > > this document, whether termed as 'copy' or 'replicate.' > > > > > > > > > Every TLV is encoded in the same way whether it is a single > > > > > TLV or a member > > > > of > > > > > an MP-TLV set. > > > > > There is no notion of the "first TLV" or the "last TLV". > > > > > > > > > > If we introduced encoding changes we would indeed be obligated > > > > > to > > > > document > > > > > them, but we do not. > > > > > If this is not clear to you then you have not correctly > > > > > understood the > > draft. > > > > > If you have suggestions as to what wording might make this > > > > > more clear, I am happy to listen. > > > > > But defining encodings that are already fully specified in > > > > > existing RFCs is not > > > > in > > > > > scope. > > > > > > > > > > As regards some tutorial document/wiki, such a thing might be > > > > > useful to > > > > some > > > > > - but isn’t in scope for a normative document. > > > > > It strikes me as "IS-IS for Beginners". There might be > > > > > interest > > > > > - but it isn't part of IETF standards work. > > > > > > > > > > Finally, as regards the new sub-TLV in the Router Capability > > > > > TLV, I agree with your comments - and note that the draft > > > > > explicitly states this is for Informational use only. > > > > > There was feedback from the WG that this limited information > > > > > was > > > > potentially > > > > > useful to operators. > > > > > If you can convince the WG that this is not needed, I have no > > > > > objection to removing it. > > > > > > > > For this point, I will not try to convince the WG if there was an agreement. > > > > > > > > > > > > > > Extending it to per codepoint is not practical. There are a > > > > > large number of codepoints, they occur at different levels > > > > > (i.e., some are top level TLVs, some are sub-TLVs). Any > > > > > encoding attempt would be very unwieldy - and still could only > > > > > be used for > informational purposes. > > > > > > > > OK. > > > > > > > > Best regards, > > > > Mach > > > > > > > > > > > > > > Les > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Mach Chen <mach.chen=40huawei.com@xxxxxxxxxxxxxx> > > > > > > Sent: Monday, November 11, 2024 11:15 PM > > > > > > To: Christian Hopps <chopps@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 > > > > > > > > > > > > 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-tl > > > > > > > > v- > > > > > > > > 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 _______________________________________________ Lsr mailing list -- lsr@xxxxxxxx To unsubscribe send an email to lsr-leave@xxxxxxxx -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
