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
