Hi Les,
Thanks for the reminder!
I reviewed the latest version and noticed that the following text from V6 has been removed, which addressed my major concern.
"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."
Therefore, I support moving this document forward.
Best regards,
Mach
> -----Original Message-----
> From: Les Ginsberg (ginsberg) <ginsberg=40cisco.com@xxxxxxxxxxxxxx>
> Sent: Wednesday, February 12, 2025 1:12 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 -
>
> We have now resumed work on the draft - V7 has been posted.
> Please take a look.
>
> Thanx very much.
>
> Les
>
> > -----Original Message-----
> > From: Mach Chen <mach.chen=40huawei.com@xxxxxxxxxxxxxx>
> > Sent: Thursday, November 14, 2024 1:35 AM
> > To: Les Ginsberg (ginsberg) <ginsberg@xxxxxxxxx>; 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 Les,
> >
> > Thanks for the detailed explanation, looking forward to seeing the update.
> >
> > Thanks,
> > Mach
> >
> > > -----Original Message-----
> > > From: Les Ginsberg (ginsberg) <ginsberg=40cisco.com@xxxxxxxxxxxxxx>
> > > Sent: Wednesday, November 13, 2024 2:37 AM
> > > 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 -
> > >
> > > As regards this quote:
> > >
> > > ""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."
> > >
> > > Some context needs to be provided.
> > >
> > > During WG review, there was discussion about the specifics of the IS
> > Neighbor
> > > TLVs where there are multiple link identifiers that may be present.
> > > These
> > > include:
> > >
> > > o IPv4 endpoint addresses
> > > o IPv6 endpoint addresses
> > > o Link IDs
> > >
> > > There was discussion that only one of these needed to match in order
> > > to be able to correctly identify two TLVs as being associated with the same
> link.
> > This
> > > led to the observation that an implementation could try to optimize
> > > the
> > space
> > > required by doing something like:
> > >
> > > TLV #1: System ID A
> > > IPv4 endpoint addresses
> > > Link IDs
> > >
> > > TLV #2: System ID A
> > > Link IDs
> > >
> > > It would still be possible to correctly identify the two TLVs as
> > > associated with the same link and therefore part of an MP-TLV.
> > >
> > > However, it was discussed that this is error prone. An
> > > implementation might
> > > do:
> > >
> > > TLV #1: System ID A
> > > IPv4 endpoint addresses
> > >
> > > TLV #2: System ID A
> > > Link IDs
> > >
> > > And then there would be no way to correlate the two TLVs.
> > >
> > > Earlier versions of the draft used the language "at least one..." of
> > > the link identifiers had to be present in all TLVs, but this was
> > > eventually replaced with the current wording - which is seen as more
> > > robust and simpler - even if less efficient in terms of LSP space consumed.
> > >
> > > While I can understand why this language could lead you to the
> > > conclusion that we are making up special rules for MP-TLVs, this
> > > conclusion is FALSE and unintended.
> > > Authors are currently reviewing an update which will remove this
> > > language and simply say "encoding of TLVs is unchanged by the use of
> > > MP-TLV" (or words to that effect).
> > >
> > > HTH
> > >
> > > Les
> > >
> > > > -----Original Message-----
> > > > From: Mach Chen <mach.chen=40huawei.com@xxxxxxxxxxxxxx>
> > > > Sent: Tuesday, November 12, 2024 12:41 AM
> > > > To: Les Ginsberg (ginsberg) <ginsberg@xxxxxxxxx>; 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 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
