Robert Raszuk <robert@xxxxxxxxxx> writes:
Hi Chris, You are 100% correct that today all specifications already define a set of values which are necessary to recognize TLVs to be coming from the same originator (originator can be a node_id or node_id+link_id etc ...). What seems to be the crux of the matter here is that MP-TLV spec recommends with normative MUST that a *subset* of those values (aka "keys") should be used when fragmenting TLV into chunks and attach to each one of them. It is this lack of definition on what is that *subset* which seems to be missing here. Intuitively, and I think this is highlighted in your and Les's responses that *subset* is what makes the TLV unique ... so values like metric, down/up bits etc ... would not be part of such *subsets*. The issue is that this is nowhere defined.
It's more than intuitive. This key value subset has to be exactly understood or the protocol would not function, you would either be replacing one neighbor with another niehgbor's TLV data (subset too small) or you would be creating multiple fake neighbors for a single actual neighbor (subset too large). The subset has to be exactly understood already or the TLV database would be corrupt on existing IS-IS. This is why Les mentioned if the data is not actually well-defined in the original RFC then we need to fix that RFC b/c IS-IS operation could be corrupted even when no multi-part TLVs were in use. No example of this has been presented yet though.. Thanks, Chris.
So perhaps instead of asking to create a live document where such
subsets are explicitly enumerated for each TLV (which still may be
useful and can be done in no time as each IETF WG already have a wiki
page) - for this current topic maybe just define in the MP-TLV doc
this *subset* as unique set of elements used for identification and
we will be done. (Even if for folks working on ISIS for decades this
is soooo obvious :).
Thx,
Robert
On Tue, Nov 12, 2024 at 10:29 AM Christian Hopps <chopps@xxxxxxxxxx>
wrote:
Aijun,
Key values are defined in existing RFCs, the actual use of the
word "KEY" is not necessary to understand what the key data is.
Sadly, this has had to be repeated over and over and over in this
discussion to no affect.
While reading the following text, please just consider regular
IS-IS (i.e., the set of existing standards)
If the key data wasn't already defined in the existing RFCs then
each router would store exactly 0 or 1 of each TLV code point.
You would have 0 or 1 neighbor TLV, you would have 0 or 1 IP
reachable prefix, etc.
And IS-IS would be utterly broken as a protocol.
So then ask yourself, how does IS-IS tell these TLVs apart? How
do we support more than 1 neighbor already? Because we have *key*
data in each TLV to identify each neighbor as different from the
other!
If the key data wasn't already defined and understood you
literally couldn't have more than 1 of each of these TLVs in
exiting IS-IS.
[rhetorical] Do you believe that IS-IS currently only supports 1
neighbor, only 1 IPv4 prefix, only 1 IPv6 prefix?
Nothing new is being introduced, no new "key"s are being defined,
no new "keys" need to be defined. There can be no confusion on
what the key data is or IS-IS would not work at all.
Thanks,
Chris.
[as wg-member]
"Aijun Wang" <wangaijun@xxxxxxxxxxxxxxx> writes:
> 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)============================================================
=
>
>
>
>
> -----邮件原件-----
> 发件人: forwardingalgorithm@xxxxxxxx [mailto:
forwardingalgorithm@xxxxxxxx] 代表 Christian Hopps
> 发送时间: 2024年11月12日 14:08
> 收件人: Aijun Wang <wangaijun@xxxxxxxxxxxxxxx>
> 抄送: Robert Raszuk <robert@xxxxxxxxxx>; Les Ginsberg
(ginsberg) <ginsberg@xxxxxxxxx>; Acee Lindem <acee.ietf@xxxxxxxxx
>; Christian Hopps <chopps@xxxxxxxxxx>; Mach Chen <mach.chen=
40huawei.com@xxxxxxxxxxxxxx>; Routing ADs <rtg-ads@xxxxxxxx>;
rtg-dir@xxxxxxxx; draft-ietf-lsr-multi-tlv.all@xxxxxxxx; lsr <
lsr@xxxxxxxx>; last-call <last-call@xxxxxxxx>
> 主题: [Lsr] Re: RtgDir Last Call Review:
draft-ietf-lsr-multi-tlv-06
>
>
> Aijun Wang <wangaijun@xxxxxxxxxxxxxxx> 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 <
robert@xxxxxxxxxx>
>> 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 <
>> wangaijun@xxxxxxxxxxxxxxx> 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 <
>> robert@xxxxxxxxxx> 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)
>> <ginsberg@xxxxxxxxx> 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 <robert@xxxxxxxxxx>
>> Sent: Monday, November 11, 2024 2:16 PM
>> To: Les Ginsberg (ginsberg) <
ginsberg@xxxxxxxxx>
>> Cc: Acee Lindem <acee.ietf@xxxxxxxxx>;
Christian
>> Hopps <chopps@xxxxxxxxxx>; Mach Chen
<mach.chen=
>> 40huawei.com@xxxxxxxxxxxxxx>; Routing ADs <
>> rtg-ads@xxxxxxxx>; rtg-dir@xxxxxxxx;
>> draft-ietf-lsr-multi-tlv.all@xxxxxxxx; lsr <
>> lsr@xxxxxxxx>; last-call <last-call@xxxxxxxx>
>> 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 <acee.ietf@xxxxxxxxx>
>> Sent: Monday, November 11, 2024 1:42 PM
>> To: Robert Raszuk <robert@xxxxxxxxxx>
>> Cc: Christian Hopps <chopps@xxxxxxxxxx>;
Mach
>> Chen <mach.chen=
40huawei.com@xxxxxxxxxxxxxx>;
>> Routing ADs <rtg-ads@xxxxxxxx>;
rtg-dir@xxxxxxxx;
>> draft-ietf-lsr-multi-tlv.all@xxxxxxxx; lsr
<
>> lsr@xxxxxxxx>; last-call <
last-call@xxxxxxxx>
>> 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@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx
>
>> wrote:
>> >
>> > 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?
>> >
>> > 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@xxxxxxxx
>> > To unsubscribe send an email to
>> lsr-leave@xxxxxxxx
>>
>>
>>
>> _______________________________________________
>> Lsr mailing list -- lsr@xxxxxxxx
>> To unsubscribe send an email to lsr-leave@xxxxxxxx
>>
>> _______________________________________________
>> Lsr mailing list -- lsr@xxxxxxxx
>> To unsubscribe send an email to lsr-leave@xxxxxxxx
Attachment:
signature.asc
Description: PGP signature
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
