Speaking as WG member: > On Nov 11, 2024, at 15:21, Robert Raszuk <[email protected]> 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] >> > <mailto:[email protected]>> 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 <[email protected] >> > <mailto:[email protected]>> wrote: >> > >> > Mach Chen <[email protected] >> > <mailto:[email protected]>> 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 -- [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]
