I think this an excellent point. The draft is simply documenting what has already been deployed in existing IS-IS networks. So, arguments that there are issues with it are completely specious. Sent from my iPhone > On Nov 12, 2024, at 6:43 AM, Christian Hopps <chopps@xxxxxxxxxx> wrote: > > Hi Robert, > > I think perhaps this document is actually presenting something too obvious (multiple vendors have already implemented the functionality w/o any document existing), and so it's causing people to think there is more going on than there is. I believe you can summarize the entire thing this way: > > "Instead of replacing TLV data (legacy) you concatenate (multi-part)." > > Nothing else is being defined here -- it's that simple -- although obviously saying that with normative language has been way harder. > > Thanks, > Chris. > [as wg-member] > > Christian Hopps <chopps@xxxxxxxxxx> writes: > >> [[PGP Signed Part:Good signature from 2E1D830ED7B83025 Christian Hopps <chopps@xxxxxxxxx> (trust ultimate) created at 2024-11-12T06:26:47-0500 using RSA]] >> >> Robert Raszuk <robert@xxxxxxxxxx> writes: >> >>> 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. >> >> It's more than intuitive. This key value subset has to be exactly understood or >> the protocol would not function, you would either be replacing one neighbor with >> another niehgbor's TLV data (subset too small) or you would be creating multiple >> fake neighbors for a single actual neighbor (subset too large). The subset has >> to be exactly understood already or the TLV database would be corrupt on >> existing IS-IS. >> >> This is why Les mentioned if the data is not actually well-defined in the >> original RFC then we need to fix that RFC b/c IS-IS operation could be corrupted >> even when no multi-part TLVs were in use. No example of this has been presented >> yet though.. >> >> Thanks, >> Chris. >> >> >>> >>> 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 <chopps@xxxxxxxxxx> >>> 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" <wangaijun@xxxxxxxxxxxxxxx> 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)============================================================ >>> = >>> > >>> > >>> > >>> > >>> > -----邮件原件----- >>> > 发件人: 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 >>> >> >> [[End of PGP Signed Part]] > > _______________________________________________ > 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