Hi, Chris: I recommended you read carefully the arguments from Robert https://mailarchive.ietf.org/arch/msg/lsr/g6r1zwMfcmOPUoKMNYOMidvyqeA/ And also to Les's statement: " But defining encodings that are already fully specified in existing RFCs is not in scope."--------we are arguing where in existing RFC gives the information "what constitute a key"? WHERE? We can limit only to TLV 22 and TLV135, as the examples in your document. For your conveniences, I copied the original part(there is no any change) as the below: ============================Quote Start(Mail from Robert, Nov. 11, 2024)========================================================= 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. ========================= Quote End(Mail from Robert, Nov. 11, 2024)============================================================= -----邮件原件----- 发件人: forwardingalgorithm@xxxxxxxx [mailto:forwardingalgorithm@xxxxxxxx] 代表 Christian Hopps 发送时间: 2024年11月12日 14:08 收件人: Aijun Wang <wangaijun@xxxxxxxxxxxxxxx> 抄送: Robert Raszuk <robert@xxxxxxxxxx>; Les Ginsberg (ginsberg) <ginsberg@xxxxxxxxx>; Acee Lindem <acee.ietf@xxxxxxxxx>; Christian Hopps <chopps@xxxxxxxxxx>; Mach Chen <mach.chen=40huawei.com@xxxxxxxxxxxxxx>; Routing ADs <rtg-ads@xxxxxxxx>; rtg-dir@xxxxxxxx; draft-ietf-lsr-multi-tlv.all@xxxxxxxx; lsr <lsr@xxxxxxxx>; last-call <last-call@xxxxxxxx> 主题: [Lsr] Re: RtgDir Last Call Review: draft-ietf-lsr-multi-tlv-06 Aijun Wang <wangaijun@xxxxxxxxxxxxxxx> writes: > Hi, Robert: > > Fragments and Glue procedures is one normal, mature process for any > slicing application. We needn’t another document to standardize it > again. > > The knob for the segmentation is the information “what concerns a > key”, which is what you mentioned should be in one wiki like online > form. > > If the LSR WG can formalize such “online form”, and this document > refer to it for the future implementation and interoperability > guarantee, then I can support its forwarding. > > BUT, it seems impossible to define explicitly such “online form”. > > And to Chris: if you think “what constitutes a key” is one well-known > knob for vendors, why the document illustrate explicitly such > information for TLV 22 and TLV 135? > > And how can you assure different vendors will use the same information > for “what constitutes a key” for each IS-IS code point? Aijun, You have asked this many times and been answered repeatedly; however, I will answer it again, if only to make it clear to the folks reviewing the appeal. Please stop thinking about Multi-TLV for a minute. How does IS-IS tell one neighbor TLV (or whatever) from another -- in regular deployed IS-IS? That is the "key" data. The "key" data *has* to already be agreed upon by all implementations or regular IS-IS would not function -- it would literally not function. There is nothing new to define. Thanks, Chris. > > It’s better to answer such question clearly, reasonably than to > declare in rush that document reaches the WG consensus. > > > Aijun Wang > China Telecom > > > On Nov 12, 2024, at 08:00, Robert Raszuk <robert@xxxxxxxxxx> > wrote: > > > Hi Aijun, > > Let's make sure that my observation in respect to key elements > clarification for each TLV does not equal to the request to > "ABANDON" this useful document. > > I do find the ability to fragment and glue TLVs as a useful > protocol extension. What should be sent in each fragment perhaps > is obvious to familgia of long time ISIS developers .. so my only > hint was to simply publish this in some online form. > > Rgs, > Robert > > > On Tue, Nov 12, 2024 at 12:45 AM Aijun Wang < > wangaijun@xxxxxxxxxxxxxxx> wrote: > > Hi, Robert and Mach: > > Thanks for your comments on this document. > It reveals clearly the issues existing within the documents. > > The Chairs declare repeatedly this document reached WG > consensus, apparently it DOESN’T. > > I have submitted the appeal to IESG. > Wish more experts to stand out to ABANDON this error prone, > pitfall solution being published under the name of LSR, or > IETF. > > Aijun Wang > China Telecom > > > On Nov 12, 2024, at 06:55, Robert Raszuk < > robert@xxxxxxxxxx> wrote: > > > Les, > > > Link identifiers are indeed sub-TLVs. > > That does not disqualify them from being part of “key” > information. > > Oh, it was not clear from the draft. Perhaps you can add > this detail in the next rev. > > - - - > > If you have multiple parallel links today they will all > be listed in the sub-TLVs - so they are ok spec wise > today. > > I am not sure however - assuming you do not include > "Example" in section 4.1 that everyone would be adding > them to each TLV fragment. > > // But then we have hackathons and interop venus where > interop bugs can be quickly found and fixed > // if this is how it should all work out. > > That is why I do believe a sort of dictionary would be > nice to have in either a normative spec or reference to > such a document or even as a simple wiki page :). > > Best, > Robert > > > On Mon, Nov 11, 2024 at 11:39 PM Les Ginsberg (ginsberg) > <ginsberg@xxxxxxxxx> wrote: > > > Robert – > > > > Link identifiers are indeed sub-TLVs. > > That does not disqualify them from being part of > “key” information. > > > > If I have multiple parallel links between two > routers, this is how the links are uniquely > identified. Such information is essential to > correctly identify the link attribute information > which in turn is essential for applications such as > RSVP-TE, SR=TE, and flex-algo to operate correctly. > > > > If you think this is underspecified, I presume you > think it is not possible for these applications to > work correctly today – which obviously is not the > case. > > > > Les > > > > From: Robert Raszuk <robert@xxxxxxxxxx> > Sent: Monday, November 11, 2024 2:16 PM > To: Les Ginsberg (ginsberg) <ginsberg@xxxxxxxxx> > Cc: Acee Lindem <acee.ietf@xxxxxxxxx>; Christian > Hopps <chopps@xxxxxxxxxx>; Mach Chen <mach.chen= > 40huawei.com@xxxxxxxxxxxxxx>; Routing ADs < > rtg-ads@xxxxxxxx>; rtg-dir@xxxxxxxx; > draft-ietf-lsr-multi-tlv.all@xxxxxxxx; lsr < > lsr@xxxxxxxx>; last-call <last-call@xxxxxxxx> > Subject: Re: [Lsr] RtgDir Last Call Review: > draft-ietf-lsr-multi-tlv-06 > > > > 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 <acee.ietf@xxxxxxxxx> > Sent: Monday, November 11, 2024 1:42 PM > To: Robert Raszuk <robert@xxxxxxxxxx> > Cc: Christian Hopps <chopps@xxxxxxxxxx>; Mach > Chen <mach.chen=40huawei.com@xxxxxxxxxxxxxx>; > Routing ADs <rtg-ads@xxxxxxxx>; rtg-dir@xxxxxxxx; > draft-ietf-lsr-multi-tlv.all@xxxxxxxx; lsr < > lsr@xxxxxxxx>; last-call <last-call@xxxxxxxx> > 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 < > robert@xxxxxxxxxx> 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 <chopps@xxxxxxxxxx> 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 <robert@xxxxxxxxxx> 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 <chopps@xxxxxxxxxx> > wrote: > > > > 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? > > > > 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 > > > > _______________________________________________ > Lsr mailing list -- lsr@xxxxxxxx > To unsubscribe send an email to lsr-leave@xxxxxxxx > > _______________________________________________ > 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
