Hi Chris, You are 100% correct that today all specifications already define a set of values which are necessary to recognize TLVs to be coming from the same originator (originator can be a node_id or node_id+link_id etc ...).
What seems to be the crux of the matter here is that MP-TLV spec recommends with normative MUST that a *subset* of those values (aka "keys") should be used when fragmenting TLV into chunks and attach to each one of them. It is this lack of definition on what is that *subset* which seems to be missing here. Intuitively, and I think this is highlighted in your and Les's responses that *subset* is what makes the TLV unique ... so values like metric, down/up bits etc ... would not be part of such *subsets*. The issue is that this is nowhere defined. So perhaps instead of asking to create a live document where such subsets are explicitly enumerated for each TLV (which still may be useful and can be done in no time as each IETF WG already have a wiki page) - for this current topic maybe just define in the MP-TLV doc this *subset* as unique set of elements used for identification and we will be done. (Even if for folks working on ISIS for decades this is soooo obvious :). Thx, Robert On Tue, Nov 12, 2024 at 10:29 AM Christian Hopps <[email protected]> wrote: > > Aijun, > > Key values are defined in existing RFCs, the actual use of the word "KEY" > is not necessary to understand what the key data is. Sadly, this has had to > be repeated over and over and over in this discussion to no affect. > > While reading the following text, please just consider regular IS-IS > (i.e., the set of existing standards) > > If the key data wasn't already defined in the existing RFCs then each > router would store exactly 0 or 1 of each TLV code point. You would have 0 > or 1 neighbor TLV, you would have 0 or 1 IP reachable prefix, etc. > > And IS-IS would be utterly broken as a protocol. > > So then ask yourself, how does IS-IS tell these TLVs apart? How do we > support more than 1 neighbor already? Because we have *key* data in each > TLV to identify each neighbor as different from the other! > > If the key data wasn't already defined and understood you literally > couldn't have more than 1 of each of these TLVs in exiting IS-IS. > > [rhetorical] Do you believe that IS-IS currently only supports 1 neighbor, > only 1 IPv4 prefix, only 1 IPv6 prefix? > > Nothing new is being introduced, no new "key"s are being defined, no new > "keys" need to be defined. There can be no confusion on what the key data > is or IS-IS would not work at all. > > Thanks, > Chris. > [as wg-member] > > > "Aijun Wang" <[email protected]> writes: > > > 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)============================================================= > > > > > > > > > > -----邮件原件----- > > 发件人: [email protected] [mailto:[email protected]] > 代表 Christian Hopps > > 发送时间: 2024年11月12日 14:08 > > 收件人: Aijun Wang <[email protected]> > > 抄送: Robert Raszuk <[email protected]>; Les Ginsberg (ginsberg) < > [email protected]>; Acee Lindem <[email protected]>; Christian Hopps < > [email protected]>; Mach Chen <[email protected]>; > Routing ADs <[email protected]>; [email protected]; > [email protected]; lsr <[email protected]>; last-call < > [email protected]> > > 主题: [Lsr] Re: RtgDir Last Call Review: draft-ietf-lsr-multi-tlv-06 > > > > > > Aijun Wang <[email protected]> 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 <[email protected]> > >> 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 < > >> [email protected]> 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 < > >> [email protected]> 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) > >> <[email protected]> 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 <[email protected]> > >> Sent: Monday, November 11, 2024 2:16 PM > >> To: Les Ginsberg (ginsberg) <[email protected]> > >> Cc: Acee Lindem <[email protected]>; Christian > >> Hopps <[email protected]>; Mach Chen <mach.chen= > >> [email protected]>; Routing ADs < > >> [email protected]>; [email protected]; > >> [email protected]; lsr < > >> [email protected]>; last-call <[email protected]> > >> 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 <[email protected]> > >> Sent: Monday, November 11, 2024 1:42 PM > >> To: Robert Raszuk <[email protected]> > >> Cc: Christian Hopps <[email protected]>; Mach > >> Chen <[email protected]>; > >> Routing ADs <[email protected]>; [email protected]; > >> [email protected]; lsr < > >> [email protected]>; last-call <[email protected]> > >> 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 < > >> [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]> 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]> 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]> > >> wrote: > >> > > >> > Mach Chen <mach.chen= > >> [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] > >> > To unsubscribe send an email to > >> [email protected] > >> > >> > >> > >> _______________________________________________ > >> Lsr mailing list -- [email protected] > >> To unsubscribe send an email to [email protected] > >> > >> _______________________________________________ > >> Lsr mailing list -- [email protected] > >> To unsubscribe send an email to [email protected] > >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
