Hi, Chris:
I recommended you read carefully the arguments from Robert
https://mailarchive.ietf.org/arch/msg/lsr/g6r1zwMfcmOPUoKMNYOMidvyqeA/
And also to Les's statement: " But defining encodings that are already fully
specified in existing RFCs is not in scope."--------we are arguing where in
existing RFC gives the information "what constitute a key"?
WHERE? We can limit only to TLV 22 and TLV135, as the examples in your
document.
For your conveniences, I copied the original part(there is no any change) as
the below:
============================Quote Start(Mail from Robert, Nov. 11,
2024)=========================================================
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.
========================= Quote End(Mail from Robert, Nov. 11,
2024)=============================================================
-----邮件原件-----
发件人: [email protected] [mailto:[email protected]] 代表
Christian Hopps
发送时间: 2024年11月12日 14:08
收件人: Aijun Wang <[email protected]>
抄送: Robert Raszuk <[email protected]>; Les Ginsberg (ginsberg)
<[email protected]>; Acee Lindem <[email protected]>; Christian Hopps
<[email protected]>; Mach Chen <[email protected]>; Routing
ADs <[email protected]>; [email protected];
[email protected]; lsr <[email protected]>; last-call
<[email protected]>
主题: [Lsr] Re: RtgDir Last Call Review: draft-ietf-lsr-multi-tlv-06
Aijun Wang <[email protected]> writes:
> Hi, Robert:
>
> Fragments and Glue procedures is one normal, mature process for any
> slicing application. We needn’t another document to standardize it
> again.
>
> The knob for the segmentation is the information “what concerns a
> key”, which is what you mentioned should be in one wiki like online
> form.
>
> If the LSR WG can formalize such “online form”, and this document
> refer to it for the future implementation and interoperability
> guarantee, then I can support its forwarding.
>
> BUT, it seems impossible to define explicitly such “online form”.
>
> And to Chris: if you think “what constitutes a key” is one well-known
> knob for vendors, why the document illustrate explicitly such
> information for TLV 22 and TLV 135?
>
> And how can you assure different vendors will use the same information
> for “what constitutes a key” for each IS-IS code point?
Aijun,
You have asked this many times and been answered repeatedly; however, I will
answer it again, if only to make it clear to the folks reviewing the appeal.
Please stop thinking about Multi-TLV for a minute.
How does IS-IS tell one neighbor TLV (or whatever) from another -- in regular
deployed IS-IS?
That is the "key" data.
The "key" data *has* to already be agreed upon by all implementations or
regular IS-IS would not function -- it would literally not function. There is
nothing new to define.
Thanks,
Chris.
>
> It’s better to answer such question clearly, reasonably than to
> declare in rush that document reaches the WG consensus.
>
>
> Aijun Wang
> China Telecom
>
>
> On Nov 12, 2024, at 08:00, Robert Raszuk <[email protected]>
> wrote:
>
>
> Hi Aijun,
>
> Let's make sure that my observation in respect to key elements
> clarification for each TLV does not equal to the request to
> "ABANDON" this useful document.
>
> I do find the ability to fragment and glue TLVs as a useful
> protocol extension. What should be sent in each fragment perhaps
> is obvious to familgia of long time ISIS developers .. so my only
> hint was to simply publish this in some online form.
>
> Rgs,
> Robert
>
>
> On Tue, Nov 12, 2024 at 12:45 AM Aijun Wang <
> [email protected]> wrote:
>
> Hi, Robert and Mach:
>
> Thanks for your comments on this document.
> It reveals clearly the issues existing within the documents.
>
> The Chairs declare repeatedly this document reached WG
> consensus, apparently it DOESN’T.
>
> I have submitted the appeal to IESG.
> Wish more experts to stand out to ABANDON this error prone,
> pitfall solution being published under the name of LSR, or
> IETF.
>
> Aijun Wang
> China Telecom
>
>
> On Nov 12, 2024, at 06:55, Robert Raszuk <
> [email protected]> wrote:
>
>
> Les,
>
> > Link identifiers are indeed sub-TLVs.
> > That does not disqualify them from being part of “key”
> information.
>
> Oh, it was not clear from the draft. Perhaps you can add
> this detail in the next rev.
>
> - - -
>
> If you have multiple parallel links today they will all
> be listed in the sub-TLVs - so they are ok spec wise
> today.
>
> I am not sure however - assuming you do not include
> "Example" in section 4.1 that everyone would be adding
> them to each TLV fragment.
>
> // But then we have hackathons and interop venus where
> interop bugs can be quickly found and fixed
> // if this is how it should all work out.
>
> That is why I do believe a sort of dictionary would be
> nice to have in either a normative spec or reference to
> such a document or even as a simple wiki page :).
>
> Best,
> Robert
>
>
> On Mon, Nov 11, 2024 at 11:39 PM Les Ginsberg (ginsberg)
> <[email protected]> wrote:
>
>
> Robert –
>
>
>
> Link identifiers are indeed sub-TLVs.
>
> That does not disqualify them from being part of
> “key” information.
>
>
>
> If I have multiple parallel links between two
> routers, this is how the links are uniquely
> identified. Such information is essential to
> correctly identify the link attribute information
> which in turn is essential for applications such as
> RSVP-TE, SR=TE, and flex-algo to operate correctly.
>
>
>
> If you think this is underspecified, I presume you
> think it is not possible for these applications to
> work correctly today – which obviously is not the
> case.
>
>
>
> Les
>
>
>
> From: Robert Raszuk <[email protected]>
> Sent: Monday, November 11, 2024 2:16 PM
> To: Les Ginsberg (ginsberg) <[email protected]>
> Cc: Acee Lindem <[email protected]>; Christian
> Hopps <[email protected]>; Mach Chen <mach.chen=
> [email protected]>; Routing ADs <
> [email protected]>; [email protected];
> [email protected]; lsr <
> [email protected]>; last-call <[email protected]>
> Subject: Re: [Lsr] RtgDir Last Call Review:
> draft-ietf-lsr-multi-tlv-06
>
>
>
> 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 <[email protected]>
> Sent: Monday, November 11, 2024 1:42 PM
> To: Robert Raszuk <[email protected]>
> Cc: Christian Hopps <[email protected]>; Mach
> Chen <[email protected]>;
> Routing ADs <[email protected]>; [email protected];
> [email protected]; lsr <
> [email protected]>; last-call <[email protected]>
> 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 <
> [email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]>
> wrote:
> >
> > Mach Chen <mach.chen=
> [email protected]> 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 -- [email protected]
> > To unsubscribe send an email to
> [email protected]
>
>
>
> _______________________________________________
> Lsr mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
> _______________________________________________
> Lsr mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
