Les, I note that in all of these emails expressing concern no one has provided a > single example > RFC5305 defines Extended IS Reachability TLV as: The proposed extended IS reachability TLV contains a new data structure, consisting of: 7 octets of system ID and pseudonode number 3 octets of default metric 1 octet of length of sub-TLVs Now your draft makes an impression that there are also at the TLV level itself optional link identifiers. 4.1. Example: Extended IS Reachability As an example, consider the Extended IS Reachability TLV (type 22). A neighbor in this TLV is specified by: * 7 octets of system ID and pseudonode number * 3 octets of default metric * Optionally one or more of the following link identifiers: - IPv4 interface address and IPv4 neighbor address as specified in [RFC5305] - IPv6 interface address and IPv6 neighbor address as specified in [RFC6119] - Link Local/Remote Identifiers as specified in [RFC5307] Can you point to the text in RFC5305 where such IPv4 link identifier is defined ? I can only find them to be defined as part of sub-TLVs. Also I do not see them as LSDB keys in FRR ISIS code ... Ref: https://github.com/FRRouting/frr/blob/master/isisd/isisd.c Thx, R. > *From:* Acee Lindem > *Sent:* Monday, November 11, 2024 1:42 PM > *To:* Robert Raszuk > *Cc:* Christian Hopps ; Mach Chen 40huawei.com@dmarc.ietf.org>; Routing ADs ; > rtg-dir@ietf.org; draft-ietf-lsr-multi-tlv.all@ietf.org; lsr ; > last-call > *Subject:* Re: [Lsr] RtgDir Last Call Review: draft-ietf-lsr-multi-tlv-06 > > > > Speaking as WG member: > > > > On Nov 11, 2024, at 15:21, Robert Raszuk wrote: > > > > Dear Christian, > > > > Thank you for your answer. I remain educated that LSR WG born RFCs are > only for those who implement protocol and have years of experience in doing > so. > > > > I was obviously wrong thinking RFCs are designed to also help operators to > run and troubleshoot network problems. Or maybe say wireshark or tcpdump > developers to properly decode stuff which shows up on the wire ... > > > > And if this is so obvious, what is the problem for someone with such > experience to sit down and write down a BCP dict listing what in his > opinions should be used as a key for each TLV listed in section 8.2 ? If > done weeks before we would not have such discussion. > > > > If done correctly, this document would be welcomed. However, it should be > a gating factor on specification of IS-IS MP-TLVs. > > > > Thanks, > > Acee > > > > > > > > > > > > Kind regards, > > Robert > > > > On Mon, Nov 11, 2024 at 9:05 PM Christian Hopps wrote: > > As was pointed out on the list, anyone implementing IS-IS knows exactly > what a key is b/c it’s literally the value they use to differentiate TLVs > from one another — IOW *A KEY VALUE*. You don’t consider 2 neighbor TLVs to > be different neighbors (and allocate a neighbor structure to store in your > DB of neighbors) based on the TLV metric value. This really is obvious when > people stop treating the discussion as some abstraction which is again what > people keep pointing out. > > Thanks, > Chris. > > > On Nov 11, 2024, at 08:13, Robert Raszuk wrote: > > > > Hi Chris, > > > > > 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; > > > > I have followed this discussion on the list. > > > > It seems to be as a side observer that folks questioning the WGLC and > progressing the document do have a valid point. > > > > The document by its title and by section 8.2 creates an impression that > it is a universal spec for all TLVs in respect how to implement MP-TLVs for > them. > > > > Yet we clearly see from examples provided in sections 4.1 and 4.2 that > what constitutes a "key" is TLV dependent and it is really cherry picked > out of the number of values carried in a TLV. > > > > An example from section 4.1: In TLV 22 - 3 octets of def metric is > skipped and not considered as a key > > > > An example from section 4.2: In TLV 135 - 4 octets of metric > information and two bits of control information octet are skipped and not > considered as a key > > > > So if an implementer takes this document and attempts to write up MP-TLV > how is he going to figure out which values for all other listed TLVs in 8.2 > constitute a key and which not ? > > > > IMO this document can proceed however only in respect to TLV 22 and TLV > 135 and both its title and content should reflect this. > > > > Cheers, > > Robert > > > > On Mon, Nov 11, 2024 at 1:27 PM Christian Hopps > wrote: > > > > Mach Chen 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? > > > > 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@ietf.org > > To unsubscribe send an email to lsr-leave@ietf.org > > >