Hi Les,
Some replies inline...
> -----Original Message-----
> From: Les Ginsberg (ginsberg) <ginsberg=40cisco.com@xxxxxxxxxxxxxx>
> Sent: Tuesday, November 12, 2024 4:09 PM
> To: Mach Chen <mach.chen@xxxxxxxxxx>; 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
>
> Mach -
>
> Apologies. My mailer sometimes truncates inline replies.
> Let me try again - top posting.
>
> We do NOT introduce the "concept of a key".
Alright, we'll have to agree to disagree😊
> 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".
Below text is quoted from Section 4:
"If a Multi-part TLV contains information that specifies the
applicability of its contents (i.e., a key), the key information MUST
be replicated in additional TLV instances so that all contents
specific to that key can be identified."
In my view, this constitutes a new requirement introduced by this document, whether termed as 'copy' or 'replicate.'
> 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.
For this point, I will not try to convince the WG if there was an agreement.
>
> 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.
OK.
Best regards,
Mach
>
> 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
