Mach -
Apologies. My mailer sometimes truncates inline replies.
Let me try again - top posting.
We do NOT introduce the "concept of a key".
We introduce the use of a generic term ("key") to refer to those codepoint specific elements which uniquely identify the objects being advertised.
We also do NOT introduce "copying the Key across different MP-TLV parts".
Every TLV is encoded in the same way whether it is a single TLV or a member of an MP-TLV set.
There is no notion of the "first TLV" or the "last TLV".
If we introduced encoding changes we would indeed be obligated to document them, but we do not.
If this is not clear to you then you have not correctly understood the draft.
If you have suggestions as to what wording might make this more clear, I am happy to listen.
But defining encodings that are already fully specified in existing RFCs is not in scope.
As regards some tutorial document/wiki, such a thing might be useful to some - but isn’t in scope for a normative document.
It strikes me as "IS-IS for Beginners". There might be interest - but it isn't part of IETF standards work.
Finally, as regards the new sub-TLV in the Router Capability TLV, I agree with your comments - and note that the draft explicitly states this is for Informational use only.
There was feedback from the WG that this limited information was potentially useful to operators.
If you can convince the WG that this is not needed, I have no objection to removing it.
Extending it to per codepoint is not practical. There are a large number of codepoints, they occur at different levels (i.e., some are top level TLVs, some are sub-TLVs). Any encoding attempt would be very unwieldy - and still could only be used for informational purposes.
Les
> -----Original Message-----
> From: Mach Chen <mach.chen=40huawei.com@xxxxxxxxxxxxxx>
> Sent: Monday, November 11, 2024 11:15 PM
> To: Christian Hopps <chopps@xxxxxxxxxx>
> Cc: rtg-ads@xxxxxxxx; rtg-dir@xxxxxxxx; draft-ietf-lsr-multi-tlv.all@xxxxxxxx; Lsr
> <lsr@xxxxxxxx>; last-call@xxxxxxxx
> Subject: RE: RtgDir Last Call Review: draft-ietf-lsr-multi-tlv-06
>
> Hi Chris,
>
> Please see my reply inline...
>
> > -----Original Message-----
> > From: Christian Hopps <chopps@xxxxxxxxxx>
> > Sent: Monday, November 11, 2024 8:14 PM
> > To: Mach Chen <mach.chen@xxxxxxxxxx>
> > Cc: rtg-ads@xxxxxxxx; rtg-dir@xxxxxxxx; draft-ietf-lsr-multi-tlv.all@xxxxxxxx; Lsr
> > <lsr@xxxxxxxx>; last-call@xxxxxxxx
> > Subject: Re: RtgDir Last Call Review: draft-ietf-lsr-multi-tlv-06
> >
> >
> > 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?
>
> I hadn’t closely followed this topic’s discussion before, but after taking on this
> review task, I read most of the related emails. I remain unconvinced by the
> idea that we should ‘rely on experienced ISIS implementers to understand the
> composition of each MP-TLV Key.’ While this document does not alter the MP-
> TLV encoding, it introduces the concept of a Key and specific operations
> involving it, such as copying the Key across different MP-TLV parts or
> correlating ML-TLV parts by the Key. These operations are not required by the
> original MP-TLV RFCs, so it is this document’s responsibility to define what
> constitutes the MP-TLV Key to ensure these operations can be implemented
> correctly.
>
> Given the authors have already investigated all the existing MP-TLVs, taking a
> further step to document the Key definitions for those TLVs/sub-TLVs in this
> document, in a separate document, or even in a wiki would be valuable to the
> community.
>
> Best regards,
> Mach
>
>
> > 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
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
