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
