[RTG-DIR]Re: RtgDir Last Call Review: draft-ietf-lsr-multi-tlv-06

["Les Ginsberg (ginsberg)" <[e-mail]>]

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=[e-mail]>
> Sent: Thursday, November 14, 2024 1:35 AM
> To: Les Ginsberg (ginsberg) <[e-mail]>; Christian Hopps
> <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]; Lsr
> <[e-mail]>; [e-mail]
> 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=[e-mail]>
> > Sent: Wednesday, November 13, 2024 2:37 AM
> > To: Mach Chen <[e-mail]>; Christian Hopps
> > <[e-mail]>
> > Cc: [e-mail]; [e-mail]; [e-mail]; Lsr
> > <[e-mail]>; [e-mail]
> > 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=[e-mail]>
> > > Sent: Tuesday, November 12, 2024 12:41 AM
> > > To: Les Ginsberg (ginsberg) <[e-mail]>; Christian Hopps
> > > <[e-mail]>
> > > Cc: [e-mail]; [e-mail];
> > > [e-mail]; Lsr <[e-mail]>;
> > > [e-mail]
> > > Subject: RE: RtgDir Last Call Review: draft-ietf-lsr-multi-tlv-06
> > >
> > > Hi Les,
> > >
> > > Some replies inline...
> > >
> > > > -----Original Message-----
> > > > From: Les Ginsberg (ginsberg) <ginsberg=[e-mail]>
> > > > Sent: Tuesday, November 12, 2024 4:09 PM
> > > > To: Mach Chen <[e-mail]>; Christian Hopps
> > > > <[e-mail]>
> > > > Cc: [e-mail]; [e-mail];
> > > > [e-mail]; Lsr <[e-mail]>;
> > > > [e-mail]
> > > > 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=[e-mail]>
> > > > > Sent: Monday, November 11, 2024 11:15 PM
> > > > > To: Christian Hopps <[e-mail]>
> > > > > Cc: [e-mail]; [e-mail];
> > > > > [e-mail]; Lsr <[e-mail]>;
> > > > > [e-mail]
> > > > > Subject: RE: RtgDir Last Call Review: draft-ietf-lsr-multi-tlv-06
> > > > >
> > > > > Hi Chris,
> > > > >
> > > > > Please see my reply inline...
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Christian Hopps <[e-mail]>
> > > > > > Sent: Monday, November 11, 2024 8:14 PM
> > > > > > To: Mach Chen <[e-mail]>
> > > > > > Cc: [e-mail]; [e-mail];
> > > > > > [e-mail]; Lsr <[e-mail]>;
> > > > > > [e-mail]
> > > > > > Subject: Re: RtgDir Last Call Review:
> > > > > > draft-ietf-lsr-multi-tlv-06
> > > > > >
> > > > > >
> > > > > > Mach Chen <mach.chen=[e-mail]> 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