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.
* sender makes an error by including multiple versions of a TLV
* the 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] <mailto:[email protected]>
>; [email protected] <mailto:[email protected]>
抄送: [email protected]
<mailto:[email protected]> ; [email protected]
<mailto:[email protected]> ; [email protected] <mailto:[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]
