Aijun, may I suggest another way of phrasing what I am hearing people
who disagree with your analysis are asserting? (If I get it wrong, I am
sure they will correct me.)
1) We have working IS-ID
2) In order to function, IS-IS implementations already must recognize
when they receive two conlicting dvertisements
2') That is, for every advertisement that can possibly be duplicated
with variation, there already is a well-defined notion common to all
implementations of the key for those advertisements
3) The multi-tlv effort you are objecting to uses that same keying to
allow for the case where the two variations that are received are to be
combined, instead of merely selecting one.
4) Given that this necessary behavior has been operation for MANY years,
the apparent conclusion is that it is already sufficiently specified.
Yours,
Joel
On 2/19/2025 10:56 PM, Aijun Wang wrote:
Hi, Adrian:
Thanks for your detail analysis and logical deduction!
It help us to understand the arguments of each other. Let me give my
thoughts to your analysis:
First, I must point out that the base of your assumptions is NOT CORRECT:
*There is no such “Fixed part” that can be used as the “key”
information for slicing the large TLV, defined in the related RFCs,
for every possible MP-TLVs that are listed in
draft-ihttps://datatracker.ietf.org/doc/html/draft-ietf-lsr-multi-tlv-09#section-9
<https://datatracker.ietf.org/doc/html/draft-ietf-lsr-multi-tlv-09#section-9>*
We should all know there are fixed fields defined in these
TLVs/sub-TLVs, but that can’t be solely used as the “Fixed part” to
concatenate the several pieces together.
We can take the TLV 22(Extended IS Reachability) as one example(also
in this WGLC document).
For clarity, I extracted the related content from the document
directly(https://datatracker.ietf.org/doc/html/draft-ietf-lsr-multi-tlv-09#section-3.2.1):
As an example, consider the Extended IS Reachability TLV (type 22). A
neighbor in this TLV is specified by:¶
<https://datatracker.ietf.org/doc/html/draft-ietf-lsr-multi-tlv-09#section-3.2.1-1>
·7 octets of system ID and pseudonode number¶
<https://datatracker.ietf.org/doc/html/draft-ietf-lsr-multi-tlv-09#section-3.2.1-2.1.1>
·3 octets of default metric¶
<https://datatracker.ietf.org/doc/html/draft-ietf-lsr-multi-tlv-09#section-3.2.1-2.2.1>
·Optionally one or more of the following link identifiers:¶
<https://datatracker.ietf.org/doc/html/draft-ietf-lsr-multi-tlv-09#section-3.2.1-2.3.1>
oIPv4 interface address and IPv4 neighbor address as specified
in [RFC5305 <https://www.rfc-editor.org/info/rfc5305>]¶
<https://datatracker.ietf.org/doc/html/draft-ietf-lsr-multi-tlv-09#section-3.2.1-2.3.2.1.1>
oIPv6 interface address and IPv6 neighbor address as specified
in [RFC6119 <https://www.rfc-editor.org/info/rfc6119>]¶
<https://datatracker.ietf.org/doc/html/draft-ietf-lsr-multi-tlv-09#section-3.2.1-2.3.2.2.1>
oLink Local/Remote Identifiers as specified in [RFC5307
<https://www.rfc-editor.org/info/rfc5307>]¶
<https://datatracker.ietf.org/doc/html/draft-ietf-lsr-multi-tlv-09#section-3.2.1-2.3.2.3.1>
The key consists of the 7 octets of system ID and pseudonode number
plus the set of link identifiers which are present.
We can check the original definition of RFC for TLV 22----RFC
5305----There is no any “key” definition information in this
RFC----Verify what I have said above that there is no key definition
for every possible MP-TLVs in current RFCs.
What constitutes the key of TLV 22 is only mentioned in this WGLC
document------“The key consists of the 7 octets of system ID and ……”
Even we continuing our discussions based on such key definition
information, *can you tell me what is the “Fixed part” that you
mentioned when slicing the TLV in your example?*
I think you should know, according to the description of this
document, “the set of link identifiers” is optionally.
I can image if the sender/receiver are from one vendor, they can keep
the “Fixed part” in different pieces same, but, how to ensure they are
same if the devices from different vendors?
Comparing to this undefined and ambiguity of “Fixed part”, or “key”
information for each possible MP-TLV, other issues that you
raised(slicing not in the boundary of sub-TLV, temporarily duplicate
of a TLV in two LSPs etc. can be easily mitigated).
I think you admitted the “key” must be represented in every of piece
of the sliced TLV/sub-TLVs(for the “keyed TLV” that you mentioned).
Then, where is “key” definition for each of such TLV/sub-TLVs?
Best Regards
Aijun Wang
China Telecom
*发件人:*[email protected]
[mailto:[email protected]] *代表 *Adrian Farrel
*发送时间:*2025年2月19日19:21
*收件人:*'Aijun Wang' <[email protected]>; 'Les Ginsberg
(ginsberg)' <[email protected]>; [email protected]
*抄送:*[email protected]; [email protected];
[email protected]; 'The IESG' <[email protected]>
*主题:*[Lsr] Re: 【Can you concatenate several pieces together without
one "explicit key" to identify them belong to the same segment】Re:
Rtgdir last call review of draft-ietf-lsr-multi-tlv-08
The correct formation of a TLV includes certain fields that must be
present and other fields (such as sub-TLVs) that may be present and
may recur. All instances of a TLV must be formatted correctly. That
means that when a TLV is repeated as part of an MP-TLV each component
TLV must be correctly formatted.
In other words, t is incorrect to read this document as simply saying
that the “overflow” appears in a second TLV structure with the same
Type, and with the data continuing.
Consider (please enable non-proportional font)
| T=t | L | Fixed part | sub-TLV1 | sub-TLV2 | sub-TLV3 |
1 ... ... 255 ...
There is too much to fit into one TLV structure.
The incorrect MP-TLV would be…
| T=t | L | Fixed part | sub-TLV1 |
| T=t | L | sub-TLV2 | sub-TLV3 |
The correct MP-TLV would be
| T=t | L | Fixed part | sub-TLV1 |
| T=t | L | Fixed part | sub-TLV2 | sub-TLV3 |
Note also, that the separation into component TLVs must happen at a
segmentable boundary. E.g., at a sub-TLV. Thus, another incorrect
MP-TLV would be…
| T=t | L | Fixed part | sub-TLV1 | First part of sub-TLV2 |
| T=t | L | Fixed part | Second part of sub-TLV2 | sub-TLV3 |
There are two cases:
-TLVs that have a key defined
-TLVs that don’t have a key defined
If the TLV has a key, that is usually found in the fixed part.
Thus, the key is found in both component TLVs.
What are the concerns?
1. That for a keyed TLV, the component TLVs will not be correctly
associated.
Not a problem because the key is present in each component TLV.
2. That the component TLVs will not be concatenated in the right order
Not a problem because the sub-TLVs (i.e., the not fixed part) are
allowed to be
present in any order.
3. That fragments of a sub-TLV will be concatenated in the wrong order.
Not a problem because partitioning must be at a sub-TLV boundary
4. That the fixed part will differ in component TLVs.
This is identified as an error.
5. How do I know which fields in the fixed part comprise the key?
If you have implemented support for a TLV, you must understand the
key.
If you have not implemented support for the TLV, you don’t care
because you
ignore the TLV.
6. Your question:
*Can you concatenate several pieces together without one
**“**explicit key**”**to identify them belong to the same segment?*
I say “yes”. Because, without a key you know that the TLV is “one of a
kind”.
The only legitimate duplication of a TLV is when it includes a key.
Note: There are two cases identified in the document where (without
MP-TLV) an un-keyed TLV may be duplicated.
osender makes an error by including multiple versions of a TLV
othe sender is transiting a TLV from one LSP to another (so it appears
in both LSPs)
These are both handled by allowing concatenation to proceed, and the
composed TLV to be discovered to be incorrectly formatted.
For the first case, this will result in the errored composed TLV being
discarded. Good.
For the second case, there will be a transitory case where the errored
composed TLV is discarded, but when the LSP is refreshed, everything
will resolve.
My question back to you would be to ask you to give an example where
this goes wrong?
Thanks,
Adrian
*From:*Aijun Wang <[email protected]>
*Sent:* 19 February 2025 02:40
*To:* [email protected]; 'Les Ginsberg (ginsberg)'
<[email protected]>; [email protected]
*Cc:* [email protected]; [email protected];
[email protected]; 'The IESG' <[email protected]>
*Subject:* 答复: [Lsr] 【Can you concatenate several pieces together
without one "explicit key" to identify them belong to the same
segment】Re: Rtgdir last call review of draft-ietf-lsr-multi-tlv-08
Hi, Adrian:
I have read your Rtgdir reviews and update suggestions on the current
document. Appreciate for your efforts!
But, I don’t know why you ignore the issues that you have concerned
previously also about the “explicit key”definition of each possible
IS-IS TLV/sub-TLV.(Please refer
to:https://mailarchive.ietf.org/arch/msg/lsr/Xga5YrD6ObbNDvFFK_nVDXlipJA/).
Let’s try to don’t loop the past arguments and make the life better.
Then, would you, and also other experts/reviewer that pass this
document answer the following simple, *straightforward*question:
*Can you concatenate several pieces together without one **“**explicit
key**”**to identify them belong to the same segment?*
If the answer is “can”, please tell me how?
If the answer is “can’t”, then, where is necessary “explicit key”in
this document?
And, if there is none of such “explicit key”information, what’s the
value of this document?
Let’s be clear for the further discussion, the implicit negotiations
solution to solve the interoperability is not STANDARD solution.
I copied this discussions also to the IESG mail list for further
evaluations of the IESG experts.
Best Regards
Aijun Wang
China Telecom
*发件人**:*[email protected]
[mailto:[email protected]
<mailto:[email protected]>] *代表 *Adrian Farrel
*发送时间**:*2025年2月14日18:10
*收件人**:*'Les Ginsberg (ginsberg)' <[email protected]>;
[email protected]
*抄送**:*[email protected]; [email protected];
[email protected]
*主题**:*[Lsr] Re: Rtgdir last call review of draft-ietf-lsr-multi-tlv-08
Many thanks for your responsiveness, Les.
V9 addresses all of my nits adequately. I will update the status of my
review in the Datatracker.
As to…
> That said, after posting V9, I thought maybe something like what I
show below
> might be added to Section 4. I am not convinced it is needed – but
let me know
> what you think.
>
> “Each TLV that is part of an MP-TLV MUST be parsable independent of other
> TLVs in the MP-TLV. Breaking of a single sub-TLV or other data unit
across TLVs
> MUST NOT be done.”
I agree with you that this is “not needed.”
I do believe it would be somewhat helpful to avoid people falling into
error.
I leave it to you and your co-authors to decide.
Cheers,
Adrian
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
