Last Call Review of draft-ietf-lsr-multi-tlv-08
review-ietf-lsr-multi-tlv-06-rtgdir-lc-chen-2025-01-13-01

Les,

I note that in all of these emails expressing concern no one has provided a
> single example
>

RFC5305 defines Extended IS Reachability TLV as:

   The proposed extended IS reachability TLV contains a new data
   structure, consisting of:

      7 octets of system ID and pseudonode number
      3 octets of default metric
      1 octet of length of sub-TLVs

Now your draft makes an impression that there are also at the TLV level
itself optional link identifiers.

4.1.  Example: Extended IS Reachability

   As an example, consider the Extended IS Reachability TLV (type 22).
   A neighbor in this TLV is specified by:

   *  7 octets of system ID and pseudonode number

   *  3 octets of default metric

   *  Optionally one or more of the following link identifiers:

      -  IPv4 interface address and IPv4 neighbor address as specified
         in [RFC5305]

      -  IPv6 interface address and IPv6 neighbor address as specified
         in [RFC6119]

      -  Link Local/Remote Identifiers as specified in [RFC5307]


Can you point to the text in RFC5305 where such IPv4 link identifier is
defined ?

I can only find them to be defined as part of sub-TLVs.

Also I do not see them as LSDB keys in FRR ISIS code ...
Ref: https://github.com/FRRouting/frr/blob/master/isisd/isisd.c

Thx,
R.


> *From:* Acee Lindem <acee.ietf@gmail.com>
> *Sent:* Monday, November 11, 2024 1:42 PM
> *To:* Robert Raszuk <robert@raszuk.net>
> *Cc:* Christian Hopps <chopps@chopps.org>; Mach Chen <mach.chen=
> 40huawei.com@dmarc.ietf.org>; Routing ADs <rtg-ads@ietf.org>;
> rtg-dir@ietf.org; draft-ietf-lsr-multi-tlv.all@ietf.org; lsr <lsr@ietf.org>;
> last-call <last-call@ietf.org>
> *Subject:* Re: [Lsr] RtgDir Last Call Review: draft-ietf-lsr-multi-tlv-06
>
>
>
> Speaking as WG member:
>
>
>
> On Nov 11, 2024, at 15:21, Robert Raszuk <robert@raszuk.net> wrote:
>
>
>
> Dear Christian,
>
>
>
> Thank you for your answer. I remain educated that LSR WG born RFCs are
> only for those who implement protocol and have years of experience in doing
> so.
>
>
>
> I was obviously wrong thinking RFCs are designed to also help operators to
> run and troubleshoot network problems. Or maybe say wireshark or tcpdump
> developers to properly decode stuff which shows up on the wire ...
>
>
>
> And if this is so obvious, what is the problem for someone with such
> experience to sit down and write down a BCP dict listing what in his
> opinions should be used as a key for each TLV listed in section 8.2 ? If
> done weeks before we would not have such discussion.
>
>
>
> If done correctly, this document would be welcomed. However, it should be
> a gating factor on specification of IS-IS MP-TLVs.
>
>
>
> Thanks,
>
> Acee
>
>
>
>
>
>
>
>
>
>
>
> Kind regards,
>
> Robert
>
>
>
> On Mon, Nov 11, 2024 at 9:05 PM Christian Hopps <chopps@chopps.org> wrote:
>
> As was pointed out on the list, anyone implementing IS-IS knows exactly
> what a key is b/c it’s literally the value they use to differentiate TLVs
> from one another — IOW *A KEY VALUE*. You don’t consider 2 neighbor TLVs to
> be different neighbors (and allocate a neighbor structure to store in your
> DB of neighbors) based on the TLV metric value. This really is obvious when
> people stop treating the discussion as some abstraction which is again what
> people keep pointing out.
>
> Thanks,
> Chris.
>
> > On Nov 11, 2024, at 08:13, Robert Raszuk <robert@raszuk.net> wrote:
> >
> > Hi Chris,
> >
> > > 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;
> >
> > I have followed this discussion on the list.
> >
> > It seems to be as a side observer that folks questioning the WGLC and
> progressing the document do have a valid point.
> >
> > The document by its title and by section 8.2 creates an impression that
> it is a universal spec for all TLVs in respect how to implement MP-TLVs for
> them.
> >
> > Yet we clearly see from examples provided in sections 4.1 and 4.2 that
> what constitutes a "key" is TLV dependent and it is really cherry picked
> out of the number of values carried in a TLV.
> >
> > An example from section 4.1:  In TLV 22 - 3 octets of def metric is
> skipped and not considered as a key
> >
> > An example from section 4.2: In TLV 135 -  4 octets of metric
> information and two bits of control information octet are skipped and not
> considered as a key
> >
> > So if an implementer takes this document and attempts to write up MP-TLV
> how is he going to figure out which values for all other listed TLVs in 8.2
> constitute a key and which not ?
> >
> > IMO this document can proceed however only in respect to TLV 22 and TLV
> 135 and both its title and content should reflect this.
> >
> > Cheers,
> > Robert
> >
> > On Mon, Nov 11, 2024 at 1:27 PM Christian Hopps <chopps@chopps.org>
> wrote:
> >
> > Mach Chen <mach.chen=40huawei.com@dmarc.ietf.org> 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?
> >
> > 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
> >
> > _______________________________________________
> > Lsr mailing list -- lsr@ietf.org
> > To unsubscribe send an email to lsr-leave@ietf.org
>
>
>