Hi, Acee:I MUST point out that MP-TLV proposal solves only the slices of two TLVs, by defining the specific keys for each of them.
It’s one bug-fix proposal, not one general solution that covers the slices of other TLVs, because there is no any key definition on current RFC documents, or the MP-TLV itself.
On the other hand, several of the experts within the LSR WG have admitted it is impossible to define specifically the key for each of these amounts IS-IS TLVs, then the bug-fix proposal of MP-TLV is not the direction to solve the problem.
Define one general key, as that in the updated Big-TLV proposal, which is also popular within any existing slice solution is the right direction to solve the problem.
I would also like the IS-IS experts to chime in for the further discussions. Speaking as WG chair:
My recollection is that there were few that wanted the Big-TLV solution as it offered no advantages over the currently deployed multi-part TLV solution.
I don’t see that adding an identifier changes the prior consensus and, if anything, makes the Big-TLV more complex and costly to implement and test.
Since my implementation and deployment experience is primarily in OSPFv(2|3) I’d appreciate those with more IS-IS experience (both implementation and deployment) to chime in.
Thanks, Acee
Hi,Chris:
Please elaborate clearly your technical reviews for the updates of the newly proposed Big-TLV solution.
A new version of Big-TLV document has been posted(https://datatracker.ietf.org/doc/html/draft-wang-lsr-isis-big-tlv), to try to give the community one general way to solve the Big TLV problem.
The main changes from the previous versions are the followings:
1) Add one "Identification" field within the container TLV(type TBD1), to function as the key for any sliced TLV, and is TLV code point independent.
2) Add one "Flag" field, define currently the "F" bit to indicate whether the piece of container is the first piece(F bit is set to 1), or not (F bit is unset)
3) Put all the sliced pieces within the newly defined container TLV(type TBD1).
4) Define some rules for the "Split and Glue" procedures(may be re-optimizer later after the WG discussions)
The updated version erases the necessity of defining the "key" information for every IS-IS (Possible Big) TLV code point, and also the necessity of per-TLV capability announcement.
I would like to hear your detail analysis, especially as the WG chairs, for the above statements. Those changes don't appear to address what the WG already decided against. The view of the WG was that a new Big TLV for doing this was not going to work. Given the name of this work is Big TLV, that doesn't seem to have changed. So why should the WG be spending even more time on a solution they already discussed, debated and discarded?Thanks,Chris.[as wg chair]On Oct 22, 2024, at 06:47, Aijun Wang <[email protected]> wrote:
Hi, Chris:
No, we have made some significant updates.
Please refer to https://mailarchive.ietf.org/arch/msg/lsr/dxK4Gy1WDR7QCXK6p58xgA0MdUc/ for more information.
Aijun Wang
China Telecom
On Oct 22, 2024, at 17:04, 【外部账号】Christian Hopps <[email protected]> wrote:
Is this the same thing that Huaimo has already presented to the WG, that the WG decided was not the way it wanted to go?
Thanks,
Chris.
"Aijun Wang" <[email protected]> writes:
Hi, Yingzhen:
I would like to request 10-15minutes to make the presentation for the
“IS-IS Extension for Big TLV”
The related information are the followings:
Draft Name: IS-IS Extension for Big TLV
Link: https://datatracker.ietf.org/doc/draft-wang-lsr-isis-big-tlv
/
Presenter: Aijun Wang
Desired Slot Length: 10-15minutes.
Best Regards
Aijun Wang
China Telecom
发件人: [email protected]
[mailto:[email protected]] 代表 Yingzhen Qu
发送时间: 2024年10月12日 3:54
收件人: lsr <[email protected]>; lsr-chairs <[email protected]>
主题: [Lsr] IETF 121 LSR Slot Requests
Hi,
The draft agenda for IETF 121 has been posted:
IETF 121 Meeting Agenda
The LSR session is scheduled on Thursday Session I 09:30-11:30, Nov 7th, 2024.
Please send slot requests to [email protected] before the end of the day
Wednesday Oct 23. Please include draft name and link, presenter, desired
slot length including Q&A.
Thanks,
Yingzhen
_______________________________________________ Lsr mailing list -- [email protected]To unsubscribe send an email to [email protected]
|
