Hi, Chris, Les and All:
Based on the ongoing discussions, I must point out the conclusion(I also changed the title of this thread for easy index), that is------Multiple occurrences of one IS-IS TLV is different from MP-TLV.
Here are the reasoning for the above conclusion:
1) There is no need to correlate the multiple occurrences of one single IS-IS TLV code point. According to the existing RFCs, the receivers may just select one of the multiple occurrence IS-IS TLV, or discard the LSP.
But for MP-TLV, the receiver must concatenate the multipart IS-IS TLV into one big TLV, based on the indispensable "key" information.
2) As Les has emphasized several times: there is no encoding change of every individual MP-TLV part, each is one legitimacy, traditional IS-IS TLV.
But, there is EXTRA requirement for these individual MP-TLV parts, if they can be concatenate together-----Each of them must have unique "key" information.
3) As you all declared, "key" is existing in current implementation, for example, to distinguish different links with one neighbor.
But, there is no "key" definition to identify the information from the SAME link.
The example provided by Les below can illustrate the difference effects between "multiple occurrence" and "MP-TLV":
If one neighbor encoding the information for one link as:
TLV #1: System ID A
IPv4 endpoint addresses
TLV #2: System ID A
Link IDs
If TLV #1, TLV #2 encoding also all other optional TLVs to describe the attributes of the link【that is, the total information of the link attributes is less than 255 bytes】, in traditional IS-IS implementation, there will be no error occurrences-------the receiver can select one of TLV#1, TLV#2 to populate the LSDB, the SPF will calculate correctly.
BUT, for MP-TLV【when the total information of the link attributes is larger than 255 bytes】, the TLV#1, TLV#2 carry only part of the attributes of the link, As Les points out, the receiver can't concatenate the TLV#1, TLV#2 together, because they have no common "key" information. The receiver will treat them with the attributes of two different links, then, the LSDB will be broken, and also the SPF process.
So, can we conclude that "what constitute a key" is the "key" part for the MP-TLV proposal, but it doesn't provide?
Aijun Wang
China Telecom
-----邮件原件-----
发件人: forwardingalgorithm@xxxxxxxx [mailto:forwardingalgorithm@xxxxxxxx] 代表 Les Ginsberg (ginsberg)
发送时间: 2024年11月13日 2:37
收件人: Mach Chen <mach.chen=40huawei.com@xxxxxxxxxxxxxx>; Christian Hopps <chopps@xxxxxxxxxx>
抄送: rtg-ads@xxxxxxxx; rtg-dir@xxxxxxxx; draft-ietf-lsr-multi-tlv.all@xxxxxxxx; Lsr <lsr@xxxxxxxx>; last-call@xxxxxxxx
主题: [Lsr] 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=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
_______________________________________________
Lsr mailing list -- lsr@xxxxxxxx
To unsubscribe send an email to lsr-leave@xxxxxxxx
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
